从零拆解Linux设备驱动模型：platform_bus注册到probe调用，每一步都给你画清楚

开场白

如果你写过Linux驱动，一定见过module_platform_driver这个宏。八成你也遇到过来回翻 dmesg 就是看不到 probe 被调用的尴尬——insmod 完一点反应都没有，设备树配了跟没配一样，调试了一整天才发现是 compatible 字符串少打了个逗号。

我不打算讲那种"platform 驱动是 Linux 设备模型的一种抽象"的废话。今天直接从内核源码入手，把platform_driver_register()和platform_device_register()这两条调用链上的每一个节点都扒开来看，配合 Mermaid 流程图，一次性讲清楚设备注册到 probe 调用的完整生命周期。

1. 一切的起点：platform_bus_type

先说一个很多人不知道的事：platform bus 并不是硬件意义上的总线——它不像 PCI 或者 USB 那样有物理电气信号。它本质上是一棵虚拟的树，用来挂载那些"没有真实总线"的设备。SoC 上的 UART、I2C、SPI 控制器，绝大多数都属于 platform device。

platform bus 的核心定义在drivers/base/platform.c里，我们来直接看这段代码：

structbus_typeplatform_bus_type={.name="platform",.dev_groups=platform_dev_groups,.match=platform_match,.uevent=platform_uevent,.dma_configure=platform_dma_configure,.pm=&platform_dev_pm_ops,};

每个 bus_type 最关键的就是.match指针——内核用它在总线上遍历已注册的驱动和设备，找到合适的配对。platform_match的优先级顺序如下：

1. OF (Device Tree) 匹配：用 compatible 字符串配
2. ACPI 匹配：用 ACPI ID 配
3. ID table (platform_device_id) 匹配：传统方式
4. name 直接匹配：驱动名和设备名直接比较

大部分现代 ARM/ RISC-V 嵌入式开发走的是第一种——设备树匹配。

2. platform_driver_register() 完整调用链：一条通向 probe 的公路

这个是今天的主角。让我先给你一张全局图，然后再逐段分析。