platform device、platform driver 与板级设备
这页讲的是：很多片上设备并不像 PCI 那样有一套非常显眼的自描述枚举流程，它们更常通过板级信息、固件描述和平台总线视角进入内核。学这页的重点，是理解 platform 世界不是“特殊例外”，而是 Linux 在 SoC 和板级设备场景下组织驱动接入的一种常态方式。
这块是什么
platform device、platform driver 与板级设备，讲的是那些没有复杂自枚举能力、却又必须被系统纳入统一驱动框架的设备，怎样以平台设备的方式被描述、实例化、匹配并交给相应驱动接手。它常见于 SoC 片上外设、板级控制器和一些依赖 Device Tree/ACPI 提供资源信息的设备。
可以把它理解成：有些设备不是“自己带身份证走进大厅登记”，而是系统先拿着楼层平面图和住户名单，把这些固定安装在楼里的设备一个个登记出来，再通知对应管理员去接手。
它负责什么
承接板级和片上设备
- 把很多 SoC 内建设备纳入统一对象模型
- 让没有强自描述能力的设备也能进入驱动匹配路径
- 承接串口、控制器、GPIO、定时器等常见平台设备
- 让板级世界不必靠零散私有代码硬接
衔接硬件描述与驱动
- 把 Device Tree、ACPI 或平台信息里的资源转成设备对象
- 让驱动在 probe 时能有统一入口拿寄存器、中断等资源
- 把板级差异尽量留在描述层而不是驱动主逻辑里
- 让平台描述和驱动接手真正接上
纳入统一生命周期
- 平台设备也要经历匹配、probe、remove、电源管理等过程
- 同样要接受引用关系、资源清理和用户可见接口约束
- 让“板子上焊死的设备”也服从系统规则
- 把特殊硬件场景放进统一内核秩序里
为什么它不是“没有总线时的凑合方案”
| 如果想得太简单 | 会怎样 | 真正关键在哪 |
|---|
| 觉得 platform 只是没有别的办法时临时用的 | 会低估它在 SoC 和嵌入式系统里的普遍性。 | 很多平台设备本来就天然属于这类组织方式。 |
| 觉得它没有匹配和生命周期可言 | 容易忽略 probe、remove、电源管理和资源获取仍然完整存在。 | 它只是枚举与描述方式不同，不代表运行规则不同。 |
| 把所有板级差异都塞进驱动 | 驱动会越来越依赖具体板子，复用性变差。 | 平台描述层存在的重要原因之一就是隔离板级差异。 |
| 觉得片上设备不需要系统对象模型 | 会让后续资源管理、sysfs 暴露和生命周期处理变得混乱。 | 固定焊在板上的设备，同样需要被统一管理。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| platform device | 一类基于平台描述被实例化出来的设备对象，常代表片上或板级设备。 |
| platform driver | 接手这类平台设备的驱动入口，与普通驱动一样也要匹配、probe 和清理。 |
| 板级设备 | 更贴近具体 SoC/开发板布局和资源关系的一类设备世界。 |
| 资源获取 | 驱动在 probe 时根据平台描述取寄存器、中断、时钟、电源等条件。 |
| 平台总线视角 | 用统一框架接住那些不靠典型热插拔枚举出现的设备。 |
为什么重要
- 它解释了为什么很多嵌入式和 SoC 驱动一开始就在和 Device Tree/ACPI 资源打交道。
- 很多“这个设备明明焊在板上，为什么还要匹配和 probe”之类的疑问，根子都在这里。
- 理解这层后，你会更容易把硬件描述、设备对象和驱动接手串成一条真正可运行的路径。
- 它让你看到“设备是固定存在的”并不等于“系统可以跳过对象模型和生命周期管理”。
常见误解
- 误解一：platform 只是旧设备遗留。实际上它在很多现代 SoC 平台上仍然非常核心。
- 误解二：没有显眼总线枚举就没有正式驱动框架。实际上 platform 恰恰是在把这类设备纳入正式框架。
- 误解三：板级设备天然稳定，不必太在乎 remove 或电源管理。实际上生命周期和功耗问题同样存在。
它不负责什么
- 它不替代硬件描述；Device Tree、ACPI 等仍负责提供设备资源和依赖信息。
- 它不让驱动摆脱公共规则；引用计数、资源清理、异步退出和用户态接口仍照常需要认真处理。
- 它不等于所有驱动世界，只是 Linux 接住一大类板级设备的关键路径。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| Device Tree、ACPI 与硬件描述 | 那页讲设备先怎么被描述，这页讲描述好的设备如何以平台对象形式进入驱动接手。 |
| 总线、设备发现与驱动匹配 | platform 世界是设备发现与匹配的一种重要具体落地方式。 |
| probe、remove 与资源清理 | 平台驱动在真正接手和撤场时，仍然完整经历这些生命周期阶段。 |
| sysfs / 电源管理 | 平台设备进入系统后，同样会参与对象暴露、属性管理和功耗状态切换。 |
读完这页后，你应该能回答
- 为什么很多片上设备即使不热插拔，也仍要进入正式的设备对象和驱动匹配路径？
- 为什么 platform 设备最自然地和 Device Tree、ACPI 这类描述方式一起出现？
- 为什么“固定焊在板子上”不等于可以跳过生命周期和资源管理？
后面适合继续问：platform device 和普通总线设备最容易混在哪？为什么很多驱动代码第一步就是从平台资源里拿寄存器和中断？板级差异如果没被描述层隔开，驱动通常会烂在哪？