Linux菜鸟专题-驱动框架:驱动、总线与设备的三角模型

    “照猫画虎”是许多驱动工程师入门的常态：参照现有模板修改代码，即便驱动跑通，对框架背后的运行逻辑依然一知半解。然而，当面对异构硬件平台移植、驱动热插拔或复杂的电源管理时，缺乏对框架本质的理解将成为瓶颈。

    本文将跳出具体的代码细节，回归到Linux驱动框架的本源。我们将通过复盘开发中常见的疑难杂症，文章将采用问题驱动（Question-Driven）的方式，从BUS、DEVICE、DRIVER三个维度系统性地梳理Linux设备驱动模型。旨在阐明：框架并非束缚，而是为了更好地管理硬件资源、降低耦合度。通过本文，读者将理解内核如何利用这一套精密的架构体系，高效地协调硬件与软件的交互。

系列问题

Q1：关于驱动什么时候出现在内核的驱动列表里？

Q2：说明一下这个驱动注册到总线列表里面是什么意思？ko的和加载到内核镜像中的都要注册到总线里面吗？以及总线是不是分为platform、spi、i2c总线等，这样分的意义是什么？

Q3：USB设备插入后，需要重新配置dts吗？内核直接可以识别并调用probe？

Q4：解析设备或者热插拔识别设备创建的device对象是什么？创建后加载到总线的虚拟地址中进行记录吗？

Q5：在总线注册设备时候，会将设备分为SPI、I2C、PCI以及Platform设备等，具体什么才是Platform设备？

Q6:在 DTS 中 &i2c1下写了 compatible设备后，和 i2c1 总线上注册流程是什么？总线和总线上设备列表之间是什么关系？

Q7：dts中&i2c1是什么意思？它是要 I2C控制器注册之后才有吗？

&i2c1 {    temp_sensor@40 {        compatible = "mycompany,temp-sensor";        reg = <0x40>;    };};

    在回答以上问题之前，先说明一下内核启动解析设备树和驱动的过程，具体如下：

【系统启动】    ↓【设备树被加载并解析】→ 内核扫描rk3588-orangepi-5-plus.dtb    ↓    ├─ Device 1: gpio-leds, compatible = "gpio-leds"    ├─ Device 2: pwm-fan, compatible = "pwm-fan"    ├─ Device 3: sfc (SPI Flash), compatible = "jedec,spi-nor"    ├─ Device 4: remotectl, compatible = "rockchip,remotectl-pwm"    └─ Device 5: GPIO3, compatible = "rockchip,rk3588-gpio"    ↓【内核驱动模块被加载】→ 驱动注册自己到内核    ↓    ├─ Driver A: compatible = "gpio-leds"    ├─ Driver B: compatible = "pwm-fan"    ├─ Driver C: compatible = "jedec,spi-nor"    ├─ Driver D: compatible = "rockchip,remotectl-pwm"    └─ Driver E: compatible = "rockchip,rk3588-gpio"    ↓【内核进行配对】→ 匹配 compatible 字符串    ↓    ├─ gpio-leds device + gpio-leds driver ✓ 匹配！→ 调用 probe()    ├─ pwm-fan device + pwm-fan driver ✓ 匹配！→ 调用 probe()    ├─ spi-nor device + jedec-spi-nor driver ✓ 匹配！→ 调用 probe()    └─ ... 其他设备    ↓【驱动 probe() 执行】→ 驱动被激活，硬件被初始化    ↓【驱动开始工作】

整个过程的核心是字符串匹配！

    设备树里说：“我的compatible是gpio-leds”，驱动说：“我的of_match_table里包括gpio-leds”，内核里就说："你们配对成功就，就开始工作吧"。

    总而言之，内核启动时会解析设备树+遍历驱动，通过compatible和of_match_table做匹配。匹配成功后加载probe函数完成设备的初始化，这是linux设备树驱动模型的核心逻辑，所有基于设备树硬件驱动（LED、GPIO、I2C等）都遵循这个流程。

Q1：关于驱动什么时候出现在内核的驱动列表里？

情况1：编译进内核镜像的驱动（built-in）

加载时间：内核启动最早阶段，甚至早于根文件系统挂载，具体是在start_kernel() -->do_basic_setup()--->driver_init()-->platform_bus_init()之后，内核会调用所有内置驱动的__init函数，把驱动注册到总线的驱动列表里面。

    这类驱动不是“加载”(load)，而是编译时直接嵌进内核镜像，内核启动时自动执行驱动的注册代码，不需要额外的加载动作。

情况2：编译成ko模块的驱动（可加载）。

加载时间：

1、手动执行insmod/modprobe指令（用户态）

2、内核启动后期，通过.etc/modprobe.d等配置自动加载。

3、设备匹配时候，按需加载，注册到驱动列表里面。

驱动代码独立成.ko文件，不占用内核镜像空间，加载后和内置驱动的待遇完全一样。

Q2：说明一下这个驱动注册到总线列表里面是什么意思？ko的和加载到内核镜像中的都要注册到总线里面吗？以及总线是不是分为platform、spi、i2c总线等，这样分的意义是什么？

    在回答该问题之前，首先要来介绍：内核里的“总线—设备—驱动”模型。

linux内核把所有的设备抽象成为struct device，把所有驱动抽象为struct device_driver，而总线（struct bus_type）就是他们之间的管理者，每个总线需要维护两个链表：

设备链表：挂在该总线上的所有设备（klist_devices）；

驱动链表：注册到该总线的所有驱动（klist_drivers）。

驱动注册到总线列表的过程如下：

    当一个驱动被加载（无论是被编译进内核镜像，还是作为ko模块加载 ），他会：

1、初始化自己的struct device_driver结构体，并调用driver_register进行注册，比如：

static struct platform_driver my_driver = {    .probe  = my_probe,    .remove = my_remove,    .driver = {        .name = "my-device",        .of_match_table = of_match_ptr(my_of_match),    },};

    当内核解析 DTS 时，发现某个设备的 compatible是 "mycompany,my-device"，就会在总线的驱动列表中找 of_match_table包含该字符串的驱动，匹配成功则调用 probe。

2、调用总线提供的注册函数，比如：

*Platform总线：Platform_driver_register(&my_driver);

*I2C总线：i2c_add_driver(&my_driver);

*USB总线：usb_register_driver(&my_driver);

    内核把这个驱动结构体添加到对应总线的驱动列表中。注册到总线中后，这个驱动就到了总线中的驱动候选池，以后只要总线上出现匹配的设备，总线就会自动调用驱动的probe函数。

ko模块和编译进内核镜像的驱动，都要注册到总线，区别是加载时机不同：

// 驱动的初始化函数static int __init my_driver_init(void){    printk("my_driver: init\n");    return platform_driver_register(&my_driver);  // 注册到 Platform 总线}// 驱动的退出函数static void __exit my_driver_exit(void){    platform_driver_unregister(&my_driver);  // 从总线注销    printk("my_driver: exit\n");}module_init(my_driver_init);   // ko 模块加载时执行module_exit(my_driver_exit);   // ko 模块卸载时执行

总线分类：

Q3：USB设备插入后，需要重新配置dts吗？内核直接可以识别并调用probe？

    回答这个问题之前，需要搞清楚什么是DTS静态设备和热插拔设备。

DTS静态设备

·设备物理固定在硬件上（如板载I2C传感器、SoC内置UART），不支持插拔，开机就存在。依赖DTS（Device Tree）或ACPI表描述：内核通过解析这些静态配置文件“知道”设备存在（如地址、compatible属性）。如：ARM开发板的I2C温湿度传感器、SoC内置的GPIO控制器、x86服务器的板载网卡（非PCIe）。

热插拔设备

·设备支持运行时动态插拔（如USB鼠标、U盘、PCIe显卡），可随时连接/断开。不需要DTS/ACPI描述：设备通过总线协议（如USB的枚举协议）自描述，内核直接读取设备自身的标识信息（如VID/PID、Class Code）。USB键盘/鼠标、U盘、PCIe显卡、Thunderbolt显示器。

静态设备和热插拔设备的识别流程：

    无论是静态设备还是热插拔设备，内核最终都会把他们抽象成为struct device(或子类，如usb_device,pci_dev,platform_device等)，然后挂载到对应的总线上面。区别在于：设备是怎么被发现的，以及如何被创建并挂载到总线上面的。

一、静态设备和热插拔设备的统一流程：

不管是哪种设备，最终都要经历：

发现设备--->创建device对象 ---->挂载到对应总线---->总线匹配驱动----->调用probe

只不过，发现设备这一步的实现方式不一样：

二、静态设备的具体实现流程

以ARM开发板上的I2C为例：

1、硬件层面

·传感器焊死在板子上，连接到soc的i2c控制器上面：地址固定，比如0x40，不支持热插拔

2、软件层面（DTS的作用）

·在DTS文件中这样描述

&i2c1{    temp_sensor@40{        compatible = "mycompany, temp-sensor";        reg = <0x40>;    };};

内核启动时：

1、解析DTS，发现i2c1总线上面有一个compatible为“mycompany, temp-sensor”，地址为0x40的设备。

2、调用of_platform_populate()或类似函数，创建i2c_client结构体（本质是struct device）的子类

3、把这个i2c_client对象挂载到i2C总线的设备列表上。

3、驱动匹配

·内核中已经注册了一个I2C驱动，其id_table或of_match_table包含“mycompany, temp-sensor”；

·I2C总线遍历设备，发现刚创建的i2c_client和该驱动匹配；

·调用驱动的probe函数，初始化传感器。

DTS静态设备和 USB 热插拔的对比

    可以看到，除了“发现设备”的方式不同，后续的流程是完全一致的：都是创建 device对象 → 挂到总线 → 匹配驱动 → 调用 probe。

Q4：解析设备或者热插拔识别设备创建的device对象是什么？创建后加载到总线的虚拟地址中进行记录吗？

A：device本质是一个C语言结构体在linux内核中，所有设备都被抽象为了一个叫做struct device的数据结构，他就像是一个设备的身份证，记录了：设备名称、设备所在的总线类型、设备资源（寄存器地址，中断号）、指向父设备、驱动、总线等指针、设备状态（是否注册，是否匹配到驱动等）

struct device {    const char        *init_name;  // 设备名    struct bus_type   *bus;        // 所属总线    struct device_driver *driver;  // 绑定的驱动    void              *platform_data; // 平台私有数据    // ... 还有很多字段};

    当内核发现这个设备时候，会调用kzalloc()分配一块内存，大小等于struct device(或其他的子类，如Platform_device\i2c client)、并且填充结构体里面的字段，比如总线指针、设备明、compatible等，并把这个结构体注册到内核的设备模型当中去。

    内核中有一个全局的总线列表(bus_type结构体链表)；每个总线结构体里有一个设备链表（struct device *klist_devices），用来存放挂在该总线上的所有设备。当创建一个device并设置好他的bus指针后，内核会把他的指针加入到总线的设备列表内。

Q5：Platform 设备具体指的是哪些设备？

A：Platform设备的定义Platform设备是linux内核中一种特殊的设备类型，专门用于描述集成在SoC内部的，非总线型的片上外设。

特点：

1、直接挂载Soc的内部总线上，不是PCI、USB、I2C这种外部总线。

2、通常通过内存映射寄存器（MMIO）访问；

3、可能有固定的中断号

4、不支持热插拔的设备，开机就有，关机才消失类型。

Platform设备的典型案例：

Q6：在 DTS 中 &i2c1下写了 compatible设备后，就是在 i2c1 总线上注册设备了吗？总线和总线上设备列表之间是什么关系？

A：

&i2c1 {    temp_sensor@40 {        compatible = "mycompany,temp-sensor";        reg = <0x40>;    };};

内核做的事情包括：

1、内核解析到i2c1这个i2C控制器节点；

2、发现i2c控制器节点下有一个子节点，设备是temp_sensor@40;

3、根据reg=<0x40>知道设备在i2C总线上的地址是0x40；

4、根据compatible知道设备的类型，并创建设备结构体i2c_client，本质上是struct device的子类

5、设置他的bus指针指向i2c_bus_type；

6、把这个i2c_client添加到I2C总线的链表中

从而，在I2C总线上注册了一个设备。

总线和总线上设备列表之间的关系：

1、总线结构体(struct bus_type)

每个总线类型(如I2C、USB、Platform)都有一个bus_type结构体，比如：

-I2C总线：i2c_bus_type

-Platform总线:platform_bus_type

-USB总线：usb_bus_type

这个结构体里包含的：

    总线名称、设备匹配函数、设备链表（klist_devices）、驱动链表(klist_drivers)每个总线结构体中都有一个设备链表，用于存放总线上面的所有设备。并且还有要一个驱动列表，用于存放注册到总线上的所有驱动，当设备和驱动都在同一个总线上面，总线会遍历两个列表，调用match来看是否匹配。

Q7：dts中&i2c1是什么意思？它是要 I2C控制器注册之后才有吗？

&i2c1{    temp_sensor@40{        compatible = "mycompany, temp-sensor";        reg = <0x40>;    };}

A：在DTS中：

*i2c1：i2c@12340000{ ... }定义了一个I2C控制前节点，并给它起了一标签叫做i2c1;

*i2c1表示“引用前面定义的i2c1这个节点”，也就是给I2C控制器添加子设备，注意：此刻i2c1是I2C控制器本身，他是一个Platform设备，在DTS中通常定义：

i2c1: i2c@12340000 {    compatible = "vendor,i2c-controller";    reg = <0x12340000 0x1000>;    interrupts = <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>;    #address-cells = <1>;    #size-cells = <0>;    status = "okay";};

    这个节点描述的I2C控制器硬件本身，他会被内核解析后：

1、创建一个platform_device对象（因为I2C控制器是SoC内部的外设，属于Platform设备）；

2、注册到Platform总线上；

3、匹配到对应的I2C控制器驱动

4、调用驱动的probe函数，初始化这个I2C控制器。

时序关系：

+---------------------+|      内核启动        |+---------------------+          ↓[解析 DTS → 创建 platform_device(i2c1)]          ↓[Platform 总线匹配驱动 → 调用 I2C 控制器的 probe()]          ↓[I2C 控制器初始化 → 创建 i2c_adapter → 注册到 i2c_bus_type]          ↓[继续解析 DTS → 发现 i2c1 的子设备 temp_sensor]          ↓[创建 i2c_client(device) → 加入 i2c_bus_type 的设备链表]          ↓[i2c_bus_type 遍历驱动链表 → 调用 match() 匹配]          ↓[匹配成功 → 调用驱动的 probe()]

注意：

    &i2C1引用的节点是先于他的子设备被解析，I2C控制器probe后，他才能成为一个可用的I2C总线，之后他的子设备才会被注册到这条总线上。