驱动是什么#

应用想点亮一颗 LED。它写下的代码只有一行:

1
write(fd, buf, 1);

这行代码走到硬件,要经过这样一条路:

1
应用 write() → 系统调用 → 内核核心 → 驱动 → 寄存器 → 引脚电平翻转

内核核心认识”字符设备""网络设备”这些类别,认识 open、read、write 这些动作。它唯独不认识”这颗 LED 接在 GPIO 17,高电平点亮,写 1 之前要先解复用引脚”。认识这些的是驱动:内核里操作具体硬件的那段代码。寄存器地址、时序、协议细节,全部封装在驱动里。

把硬件写死在内核里,每支持一种新芯片就要重编一次。内核源码里,drivers/ 目录的行数超过总量的一半,每块新板子还会带来新芯片。驱动模型给出的出路:硬件描述(设备树)和代码(驱动模块)各自独立提交,内核负责让它们相遇。

把驱动装进内核只是第一步。modprobe 成功不等于硬件动起来,你可能遇到过:模块加载了,设备没反应。模型在中间管三件事:

1. 登记。内核里存在哪些设备、哪些驱动,各自挂在哪条总线。
2. 撮合。哪段代码服务哪个设备,由总线按规则裁决。
3. 表现。每个对象在 /sys 里有一个目录,用户态能看见、能查询、能干预。

设备、总线、驱动#

模型的核心只有三个对象:

• 设备(device):系统里一份硬件实例。LED、UART 控制器、I2C 控制器,各占一个。
• 驱动(driver):一段代码,加一张它认识哪些设备的声明表。
• 总线(bus):登记处。设备和驱动都挂在某条总线上,总线拿着撮合规则。

三个结构体的骨架长这样,完整定义在 include/linux/device/ 下:

1
/* 教学简化:字段做了删减,只为说明关系 */
2
struct device {
3
    const char *name;
4
    struct bus_type *bus;           /* 我挂在哪条总线 */
5
    struct device_driver *driver;   /* 正在驱动我的代码 */
6
    void *driver_data;              /* 驱动放在我身上的私有数据 */
7
    struct kobject kobj;            /* 对应 /sys 里的一个目录 */
8
};
9

10
struct device_driver {
11
    const char *name;               /* 总线上的登记名 */
12
    const struct of_device_id *of_match_table;  /* 设备树匹配表 */
13
    int (*probe)(struct device *dev);   /* 匹配成功后被调用 */
14
    void (*remove)(struct device *dev);
15
    struct bus_type *bus;
16
};
17

18
struct bus_type {
19
    const char *name;               /* "platform"、"i2c"、"usb" */
20
    int (*match)(struct device *dev, struct device_driver *drv);
2 collapsed lines
21
    int (*probe)(struct device *dev);   /* 总线级包装,最终调用驱动 probe */
22
};

设备知道自己的总线,驱动知道自己认哪些设备,总线认识所有人,并裁决谁配谁。

1
/sys/bus/platform/
2
├── devices/     ← 挂在这条总线上的设备(软链接,指向 /sys/devices 下的真实层级)
3
└── drivers/     ← 挂在这条总线上的驱动

1
ls /sys/bus/platform/devices/
2
# 9010000.pl031  a000000.virtio_mmio  42820000.demo-led ...
3
# (示意输出,条目随板子不同)
4

5
ls /sys/bus/platform/drivers/
6
# rtc-pl031  virtio_mmio  demo-led ...

总线怎么撮合#

登记入口只有两个,分别对应设备侧和驱动侧:

• device_register():设备登记。挂上总线的设备链表,然后请总线扫一遍现有驱动。
• driver_register():驱动登记。挂上驱动链表,然后扫一遍总线上还没配到驱动的设备。

两边注册都会触发一次向对方的扫描,所以先后顺序无关紧要。USB 盘插进已经跑着的系统,是设备后到;insmod 一个模块去匹配启动时就存在的设备,是驱动后到。热插拔和模块加载走的是同一段代码。

撮合规则写在 bus_type 的 match 函数指针里,每种总线自带一套:

另外,platform 设备有一个调试后门 driver_override:设置之后只认这个名字的驱动。

匹配通过后,内核沿这条调用链走进你的代码:

1
driver_register()
2
 └─ bus_add_driver()                  drivers/base/bus.c
3
     └─ driver_attach()               drivers/base/dd.c
4
         └─ __driver_attach()
5
             ├─ bus->match(dev, drv)    规则:compatible 相等?
6
             └─ driver_probe_device()
7
                 └─ really_probe()
8
                     └─ bus->probe() → drv->probe(dev)   你的代码

probe 的返回值有明确含义。返回 0,接管成功,device.driver 指向这个驱动,sysfs 里出现双向链接;返回负数,这次撮合作废,设备回到无驱动状态,内核可以继续找下一个候选。

把这条链放进时间线跑一遍会看得更清楚。下面的实验准备了两台设备、一个驱动和三种 probe 返回值:

实验里的两台设备值得再看一眼 有匹配的驱动,温度传感器没有。切换两种注册顺序,撮合代码完全相同,差别只在谁先登记;切换 probe 返回值,设备分别走向绑定、无驱动和排队重试。正文里的调用链,展开后就是日志里这几行。

platform 总线:没有物理总线的设备#

I2C 设备挂在 I2C 总线上,USB 设备挂在 USB 总线上,总线硬件自带发现机制 控制器按地址探测,USB 主机枚举插入的设备。SoC 内部的 GPIO 控制器、看门狗、LED 没有这种总线可挂,它们直接接在 CPU 的内存总线上,但同样需要设备与驱动分离。内核为此准备了一条虚拟总线。

platform 设备的主流来源是设备树。内核启动时展开设备树,把每个带 compatible 的节点变成一个 platform_device:

1
/ {
2
    demo_led: demo-led@42820000 {
3
        compatible = "mycompany,demo-led";
4
        reg = <0x42820000 0x100>;
5
    };
6
};

驱动侧用 of_match_table 声明自己认识的 compatible:

1
static const struct of_device_id demo_led_of_match[] = {
2
    { .compatible = "mycompany,demo-led" },
3
    { /* 哨兵,必须留空结尾 */ }
4
};

match 拿设备节点的 compatible 与表项逐一整串比较,相等即命中。compatible 没命中时还有两级回退:先比 id_table(若有),再比驱动登记名与节点名。名字回退是最后防线,规范写法仍是保持 compatible 一致。

整串比较意味着一个字符的差别就会被判出局。下面的实验把 platform_match() 的三级判定摆在一起,你可以亲手把 compatible 改错:

把登记名换成与节点名不同的 demo-led-drv,再选一个打错的 compatible:三级全部未命中,模块加载成功,dmesg 没有任何输出,驱动目录下没有设备链接。这就是下一节三种典型失败里最隐蔽的一种。

一个最小的 platform 驱动#

把上面的对象拼成一份完整代码,大约三十行:

1
#include <linux/module.h>
2
#include <linux/platform_device.h>
3
#include <linux/mod_devicetable.h>
4

5
static int demo_led_probe(struct platform_device *pdev)
6
{
7
    /* 通常在这里:取资源、映射寄存器、申请时钟与中断 */
8
    dev_info(&pdev->dev, "设备 %s 找到了驱动\n", pdev->name);
9
    return 0;
10
}
11

12
static void demo_led_remove(struct platform_device *pdev)
13
{
14
    /* 6.x 起 remove 返回 void,旧内核返回 int */
15
    dev_info(&pdev->dev, "驱动离开,设备交还内核\n");
16
}
17

18
static const struct of_device_id demo_led_of_match[] = {
19
    { .compatible = "mycompany,demo-led" },
20
    { }
15 collapsed lines
21
};
22
MODULE_DEVICE_TABLE(of, demo_led_of_match);
23

24
static struct platform_driver demo_led_driver = {
25
    .probe  = demo_led_probe,
26
    .remove = demo_led_remove,
27
    .driver = {
28
        .name           = "demo-led",
29
        .of_match_table = demo_led_of_match,
30
    },
31
};
32
module_platform_driver(demo_led_driver);
33

34
MODULE_LICENSE("GPL");
35
MODULE_DESCRIPTION("A minimal platform driver");

逐段对应到模型:

• demo_led_of_match:驱动的声明表,match 的比较对象。
• .driver.name = "demo-led":总线上的登记名,也是 /sys 里驱动目录的名字。
• module_platform_driver():宏展开成 module_init 和 module_exit,装载时调用 platform_driver_register(),走上一节的调用链。
• probe:撮合成功后内核调用它。真实驱动在这里取内存资源(platform_get_resource()、devm_platform_ioremap_resource())、拿中断号(platform_get_irq()),然后把自己注册到某个子系统。本文只打印一行,资源部分留给下一篇。
• 返回 0:接管成功。装载后 dmesg 里会出现:

1
[   12.345678] demo-led 42820000.demo-led: 设备 42820000.demo-led 找到了驱动

1
clk = devm_clk_get(&pdev->dev, NULL);
2
if (IS_ERR(clk))
3
    return dev_err_probe(&pdev->dev, PTR_ERR(clk), "拿不到时钟");

在 /sys 里验证#

选一块你能拿到 shell 的板子,QEMU 也行。装载驱动后:

1
sudo insmod demo-led.ko
2

3
ls /sys/bus/platform/drivers/demo-led/
4
# 42820000.demo-led  bind  module  uevent  unbind

42820000.demo-led 这个软链接出现,说明 match 通过、probe 已经跑过。设备目录和驱动目录互相挂着链接:设备知道自己被谁驱动,驱动知道自己管着谁。

总线还留了一对操作接口,让你手动拆开撮合:

1
echo 42820000.demo-led | sudo tee /sys/bus/platform/drivers/demo-led/unbind
2
dmesg | tail -1
3
# demo-led 42820000.demo-led: 驱动离开,设备交还内核
4

5
echo 42820000.demo-led | sudo tee /sys/bus/platform/drivers/demo-led/bind

unbind 之后设备还在,只是回到”没人管”的状态;bind 让总线重新执行一遍 match 加 probe。谁驱动谁由模型维护,你可以干预。

模型之外#

本文回答的是:对象怎么登记,总线怎么撮合,probe 何时被调。驱动接管设备之后的事,另有一条线:字符设备接口把硬件能力交给用户态,中断处理响应硬件事件,DMA 负责搬数据。电源管理回调同样挂在 device_driver 上,内核沿设备树逐层挂起和恢复,策略细节本文没有展开。

设备树里 compatible、reg、interrupts 的语法,以及 pinctrl、regulator 这些资源子系统,属于设备描述层,可以单独学习。

下次装载模块没反应,先去 /sys/bus 查:驱动目录在不在?目录里有没有设备链接?没有链接,说明 match 没通过,问题范围缩小一半;有链接但设备不工作,才轮到查 probe 里的代码。