总线、设备发现与驱动匹配
这页讲的是：设备为什么不是“驱动写好就能直接用”，而要先被发现、被识别、被挂到某条总线上，再和合适驱动匹配起来。学这页的重点，是理解设备接入系统不是一跳完成，而是有明确组织过程。
这块是什么
总线、设备发现与驱动匹配，讲的是硬件如何先被系统识别，再被放进总线和设备模型这套组织体系里，最后找到真正能接管它的驱动。设备不是一段裸寄存器地址，而是要先成为“系统承认的设备对象”，驱动才知道怎么接手。
可以把它理解成：不是司机自己满街找乘客，而是先有站台、路线和调度中心，再让司机和乘客正确配对。
它负责什么
发现设备
- 识别系统里出现了哪些硬件
- 知道它们属于哪类连接方式
- 把硬件从“存在”变成“可管理对象”
- 为后续驱动接管做准备
组织总线关系
- 把设备放进对应总线世界观
- 管理设备与驱动的相遇规则
- 让不同类型硬件遵循不同组织方式
- 把硬件生态整理得更有秩序
完成匹配与接管
- 找到适合的驱动
- 触发 probe 之类接管流程
- 让设备真正变成系统能力的一部分
- 避免设备和驱动“各自存在却互相找不到”
为什么需要总线和匹配机制
| 如果没有这层 | 会怎样 | 这套机制的价值 |
|---|
| 驱动自己硬编码找设备 | 系统组织混乱，可扩展性差。 | 总线模型让设备发现和驱动接管有统一秩序。 |
| 所有设备都按同一种方式接入 | 无法适应 PCI、USB、I2C、platform 等差异。 | 不同总线能表达不同设备生态和接入规则。 |
| 设备和驱动随意绑定 | 容易错误接管或管理失控。 | 匹配规则帮助系统找到更正确的对应关系。 |
| 设备对象不统一 | 上层很难稳定地观察和管理硬件。 | 设备模型让整个硬件世界更可见、更可治理。 |
关键概念
| 概念 | 现在怎么理解 |
|---|
| 总线 | 组织设备与驱动相遇规则的一层世界观，不只是物理连线名词。 |
| 设备发现 | 系统识别出某个硬件存在并把它登记为可管理对象的过程。 |
| 匹配 | 系统判断某个驱动是否适合接管某个设备的过程。 |
| probe | 驱动真正开始接手设备、建立可用能力的关键入口。 |
| platform 设备 | 不像 PCI/USB 那样靠外部枚举机制，常见于 SoC 和板级固定资源组织。 |
为什么重要
- 它把“设备模型与驱动框架”那一页进一步拆细到真正关键的接入路径上。
- 很多驱动阅读难点，不在寄存器本身，而在“这个设备为什么会在这个时刻被这个驱动接管”。
- 理解总线与匹配后，你会更清楚不同硬件类型为什么呈现出不一样的接入习惯。
- 这层是设备世界从“杂乱硬件集合”变成“可管理系统对象”的关键。
常见误解
- 误解一：总线只是硬件课里的名词。实际上在 Linux 里它还是软件组织和匹配规则的一部分。
- 误解二：驱动自己决定接管谁。实际上很多时候是总线和设备模型在中间做组织与匹配。
- 误解三：设备发现就是驱动初始化。实际上发现、登记、匹配、probe 是不同阶段。
它不负责什么
- 它不等于具体驱动实现，但决定了驱动如何与设备相遇。
- 它不直接完成 DMA、缓冲区管理等更底层数据路径工作，那是后续能力。
- 它不替代安全和权限系统，但设备接入方式会影响整个系统暴露出的能力边界。
和其他模块的关系
| 相关模块 | 关系 |
|---|
| 设备模型与驱动框架 | 这页是那一页里“设备怎么被找到并和驱动配对”这部分的细化展开。 |
| Core API | 很多设备对象和生命周期管理都要靠公共对象模型支撑。 |
| 驱动 | 驱动的真正起点往往不是文件被编出来，而是匹配成功后的 probe 流程。 |
| 中断 / DMA | 设备真正开始工作后，后续数据交互和事件处理又会牵出更多底层机制。 |
读完这页后，你应该能回答
- 为什么设备接入不是“驱动在那儿就行”，而要经历发现、登记、匹配和接管？
- 为什么总线不仅是硬件概念，也是软件组织方式？
- 为什么 probe 之前和 probe 之后，设备在系统里的地位完全不同？
后面适合继续问：PCI/USB 和 platform 设备在接入思路上最关键的差别是什么？系统到底根据什么判断“这个驱动适合这个设备”？为什么很多阅读驱动代码前最好先看总线与匹配路径？