经验分享：怎样去编写RK3288总线设备驱动模型-总线设备驱动这三个实体之间的关系

1.传统方法

使用的引脚，操作引脚，全都写死在代码里。如果需要修改引脚时，那需要重新修改代码，并重新编译。

2.总线设备驱动模型

使用platform_device / platform_driver，将“资源”和“驱动”分离开来。

优点：易于扩展，更换引脚时drv基本不用改，只需要修改dev

缺点：代码稍微复杂，重复和冗余还是比较多，修改引脚时设备端的代码需要重新编译。

3.设备树

因为linux的device非常多，导致linux内核代码非常臃肿。

于是有了DTS文件指定硬件资源的指定，编译后生成dtb文件，传给内核。设备树在内核之外，这样就避免了内核的臃肿。

优点：易于扩展，无冗余代码，修改引脚时只需要修改dts文件，并编译dtb文件，把它传给内核。无需重新编译内核/驱动。

缺点：代码比较复杂，难以理解。

总线设备驱动模型

platform_device内包含资源结构体resource，并且通过name，来匹配platform_device和platform_driver。

platform_device和platform_driver如何联系起来

platform_bus_type结构体

首先linux里有一个platform_bus_type，虚拟总线。他有两个链表，一个是device链表一个是driver链表。

macht函数是用来匹配device和driver的，当device注册进总线或者driver注册进总线。都会调用match来查看是否匹配。

platform_device结构体

dev指的是硬件资源，platform_device有name属性，表示device的名字。还有driver_override表示需要匹配的driver名字。

platform_driver

drv指的是驱动程序,platform_driver的device_driver里面有一个name属性，表示了driver的名字。

同时它还有id_table表示了能支持的设备。

如何匹配

platform_device如何设置了driver_override的话，那么在match函数里，会从链表中找driver.name匹配的名字。

platform_device如何没有设置driver_override的话，那么在driver的id_table里去匹配device的name。

如果1和2都没有找到，那么最后会匹配device的name和driver的name是否一致。

使用2和3的方式比较多。

函数匹配的调用关系 platform_device_register platform_device_add device_add bus_add_device // 放入链表 bus_probe_device // probe 枚举设备，即找到匹配的(dev, drv) device_initial_probe __device_attach bus_for_each_drv(…,__device_attach_driver,…) __device_attach_driver driver_match_device(drv, dev) // 是否匹配 driver_probe_device // 调用 drv 的 probe platform_driver_register __platform_driver_register driver_register bus_add_driver // 放入链表 driver_attach(drv) bus_for_each_dev(drv->bus, NULL, drv, __driver_attach); __driver_attach driver_match_device(drv, dev) // 是否匹配 driver_probe_device // 调用 drv 的 probe

本文转自电子发烧友社区，原作者：习惯就好zz，若有侵权，请联系社区管理员进行删除