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_ini
tial_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
举报
