驱动进化之路：总线设备驱动模型
文章目录
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 的名字。