platform驱动注册时不同态

非常棒的问题，龙，这说明你已经走到驱动命名机制的深水区了 💡。
你现在发现的 "led_platform" 和 "led_demo" 混用现象——其实非常常见，
根本原因在于：Linux 驱动体系中不同的名字服务于不同层次。

下面我来带你彻底“拆解”这两个名字各自属于哪个层、怎么决定、什么时候用哪个。

🧩 一、先看你代码里的两个名字

在你的驱动中出现了两种“名字”：

#define DEV_NAME "led_demo"           // ← 应用层暴露的设备名
.driver = {.name = "led_platform",           // ← 驱动在内核注册的名字.of_match_table = led_of_match,
},

🧠 二、这两个名字属于不同的“命名空间”

名字	所属层级	用途	对应表现
`.driver.name = "led_platform"`	内核驱动注册层（platform_driver）	这是内核在 `/sys/bus/platform/drivers/` 里注册的驱动名字，用于驱动与设备的绑定	出现在 `/sys/bus/platform/drivers/led_platform/`
`DEV_NAME = "led_demo"`	字符设备 + sysfs 层	这是设备节点、类(class)、sysfs 目录等暴露给用户空间的名字	出现在 `/sys/class/led_demo/`、`/dev/led_demo`
`compatible = "long,led-demo"`	设备树层	用于设备匹配，与 `of_match_table` 的 `.compatible` 完全对应	出现在 `/sys/bus/platform/devices/led_demo@0`

⚙️ 三、匹配和命名的真实关系

Linux 的匹配逻辑如下👇：

1️⃣ 内核启动 / overlay 加载时：

设备树创建一个 platform_device：
名字来源于 .compatible → "long,led-demo"。
设备路径如：/sys/bus/platform/devices/led_demo@0。

2️⃣ 驱动模块加载时：

内核根据 struct platform_driver 中的 .of_match_table 找匹配项；
匹配后回调你的 led_probe()。

3️⃣ 驱动注册成功后：

.driver.name 成为驱动在系统中的标识：
/sys/bus/platform/drivers/led_platform/。

4️⃣ 你自己在 probe() 里注册的字符设备 / class 名称

class_create(DEV_NAME) → 生成 /sys/class/led_demo/；
device_create(..., DEV_NAME) → 生成 /dev/led_demo。

🧱 四、所以：

层级	谁决定名字	你代码对应字段	系统中显示在哪里
设备树 (DTS)	`compatible`	`"long,led-demo"`	`/sys/bus/platform/devices/led_demo@0`
驱动注册层	`.driver.name`	`"led_platform"`	`/sys/bus/platform/drivers/led_platform/`
字符设备层	`class_create()` / `device_create()`	`"led_demo"`	`/sys/class/led_demo/`, `/dev/led_demo`

💡 五、那我应该怎么统一命名？

有两种策略：

✅ 【策略 1】保持分层清晰（推荐）

名称	建议
DTS compatible	`"long,led-demo"`
.driver.name	`"led_platform"`
用户接口	`"led_demo"`

这样命名最符合 Linux 惯例：
平台驱动名体现“类型”，设备名体现“用途”。

例如：

驱动名 i2c_gpio、spi_display、led_platform
设备名 led_demo、camera0、temp_sensor

✅ 【策略 2】完全统一（教学/实验更直观）

想简单一点也可以：

.driver = {.name = "led_demo",.of_match_table = led_of_match,
};

设备树：

compatible = "long,led-demo";

这样在 /sys/bus/platform/drivers/led_demo/、/dev/led_demo/、/sys/class/led_demo/ 都是统一名。

缺点：如果以后同类驱动（多个 LED）共存，会名字冲突；
优点：更直观易理解。

🧩 六、想验证谁在生效？

加载模块后：

# 驱动名字（由 .driver.name 决定）
ls /sys/bus/platform/drivers/ | grep led# 设备名字（由设备树 compatible 决定）
ls /sys/bus/platform/devices/ | grep led# 用户节点（由 class_create/device_create 决定）
ls /sys/class/ | grep led