，总结浅谈Linux驱动到设备模型再到设备树

1.最初Linux驱动架构

　　Linux驱动会在初始化函数中向内核注册file_operations结构体，结构体里面就包含一些基本的open,close函数。Linux驱动中也会去实现这些函数。并且相对应的硬件信息也在这个驱动中。以LED为例，驱动程序中会将LED的引脚地址映射成虚拟地址，然后在open函数里面进行写操作。

　　当APP调用open函数的时候，就会通过一系列转换，最后调用到驱动中的open函数。（这边就不具体描述APP怎么调用到驱动中的open函数）。

弊端：　　

　　可以发现这种驱动，设备和驱动没有分离。也就是说，设备的信息是硬编码在驱动代码中的，会给驱动程序造成极大的限制。如果硬件有改动，那么必然要修改驱动代码，驱动的通用性将会非常的差。

2.总线、设备和驱动

　　以USB总线为例：当接入一个USB设备时，USB总线会立即感知到这件事，并去遍历所有注册在USB总线上的驱动，然后调用驱动中的一段代码来测探是否能够驱动刚插入的USB设备，如果可以，那么总线完成驱动和设备之间的绑定。

　　Linux设备模型为这三种对象各自定义了对应的类：

• 　　struct bus_type代表总线
• 　　srtuct device代表设备
• 　　struct device_driver代表驱动

　　这样就将设备的硬件信息和驱动分离开来。设备专门用来描述硬件相关的信息，而驱动和设备绑定成功后，驱动负责从设备中动态获取这些资源信息，当设备的资源改变后，只是设备改变而已，驱动的代码可以不做任何修改，这就大大提高了驱动代码的通用性。

　　通常情况下，总线已经在内核中实现好，我们只需要写对应总线的驱动，有时候还会编写相应的设备注册代码。

3.平台设备及其驱动

　　platform总线：有的设备并没有对应的物理总线，比如LED、RTC和蜂鸣器等。为此，内核专门开发一种虚拟总线——platform总线，用来连接这些没有物理总线的设备或者一些不支持热插拔的设备。

　　平台设备是用struct platform_device结构来表示的。

4.Linux设备树

　　在Linux内核源码的ARM体系结构引入设备树之前，相关的BSP代码中充斥了大量的平台设备（Platform Device）代码，而这些代码大多数都是重复的。之前的内核移植工作有很大一部分工作就是在复制一份BSP代码，并修改BSP代码中和目标板中与特定硬件相关的平台设备信息。

　　设备树是一个描述硬件的数据结构。它只是提供了一种语言，将硬件配置从Linux内核源码中提取出来。