驱动进化之路：总线设备驱动模型

文章目录

1 驱动编写的3种方法
- 1.1 传统写法
- 1.2 总线设备驱动模型
- 1.3 设备树
2 在 Linux 中实现“分离”：Bus/Dev/Drv 模型
- 2.1 模型
- 2.2 driver和device的匹配规则
- 2.3 函数调用关系
- 2.4 常用函数
- 2.5 如何写程序

1 驱动编写的3种方法

以 LED 驱动为例：

1.1 传统写法

特点如下：

使用哪个引脚，怎么操作引脚，都写死在代码中。
最简单，不考虑扩展性，可以快速实现功能。
修改引脚时，需要重新编译。

1.2 总线设备驱动模型

先看一下相关结构体定义：

特点如下：

引入 platform_device/platform_driver，将“资源”与“驱动”分离开来。
代码稍微复杂，但是易于扩展。
冗余代码太多，修改引脚时设备端的代码需要重新编译。
更换引脚时，上图中的 led_drv.c 基本不用改，但是需要修改 led_dev.c

1.3 设备树

特点如下：

通过配置文件──设备树来定义“资源”。
代码稍微复杂，但是易于扩展。
无冗余代码，修改引脚时只需要修改 dts 文件并编译得到 dtb 文件，把它传给内核。
无需重新编译内核/驱动。

2 在 Linux 中实现“分离”：Bus/Dev/Drv 模型

2.1 模型

2.2 driver和device的匹配规则

最先比较： platform_device. driver_override 和和 platform_driver.driver.name。可以设置 platform_device 的 driver_override，强制选择某个 platform_driver。

然后比较： platform_device. name 和和 platform_driver.id_table[i].name，
Platform_driver.id_table 是“platform_device_id”指针，表示该 drv 支持若干个 device，它里面列出了各个 device 的{.name, .driver_data}，其中的“name”表示该 drv 支持的设备的名字，driver_data是些提供给该 device 的私有数据。

最后比较： platform_device.name 和platform_driver.driver.name, platform_driver.id_table 可能为空，这时可以根据 platform_driver.driver.name 来寻找同名的 platform_device。

2.3 函数调用关系

2.4 常用函数

这些函数可查看内核源码：drivers/base/platform.c，根据函数名即可知道其含义。下面摘取常用的几个函数。

注册和反注册：
platform_device_register/ platform_device_unregister
platform_driver_register/ platform_driver_unregister
platform_add_devices // 注册多个 device

获得资源：

2.5 如何写程序

分配/ 设置/ 注册 platform_device 结构体：
在里面定义所用资源，指定设备名字。

分配/ 设置/ 注册 platform_driver 结构体：
在其中的 probe 函数里，分配/设置/注册 file_operations 结构体，并从 platform_device 中确实所用硬件资源。指定 platform_driver 的名字。