先来回顾下传统字符设备的写法，然后与接下来章节要学习的设备树做下对比，进而引入设备树的学习。
我们先来回顾下，怎么写驱动？

• 1. 看原理图；
• 2. 写驱动；
• 3. 写测试程序；

以点灯为例，来讲解；

• 1.看原理图：
  • a. 确定引脚；
  • b. 看芯片手册，确定如何操作引脚。

      对于写驱动程序的人，需要去看原理图，看芯片手册；对于写应用程序的人，并不知道怎么去看原理图，也不会看芯片手册，只知道如何写应用程序，怎么实现业务的各种逻辑，并不想去涉及硬件。这也就是我们要写驱动程序的原因，让驱动程序来干这些活，为应用程序提供统一接口，让应用程序开发者专心做他们擅长的活。可以这么说，这个驱动程序起的一个封装的作用。
      那么，如何封装？
看这么一幅图：

      应用程序调用统一的接口 open/read/write ... 来操作硬件设备；相对应我们在驱动程序中实现 open/read/write ... 的具体硬件操作接口。使得应用程序对硬件的操作变得简单，屏蔽了硬件操作的复杂部分。所以，写驱动程序，需要实现驱动程序中的 open/read/write ... 的具体硬件操作接口。

接下来，我们来看下写驱动程序的一般步骤：

问：在驱动程序中如何指定引脚？
我们通过看原理图，可以确定引脚，在驱动程序中指定引脚的方式有三种：

      在这三种方式中，核心不变，他们都需要去分配、设置、注册一个file_operations结构体；差别在于如何指定硬件资源。
那么这三种写法有何优缺点？假设如下使用场景：
      公司用同一款芯片做了两个产品：TV和Camera，需要实现产品状态指示灯的控制。

这种办法的优缺点是：
      简单，但是不易扩展，需要重新编译，重做一个版本；

      有什么改变办法？这两款产品用同一款芯片平台，这引脚的操作是类似的，也就是说led_drv.c是类似的；那么我们可以将这些引脚给抽出来，通过其他方式来指定，也就是我们接下来介绍的第二种方法：总线设备驱动模型。

      总线设备驱动模型将传统的驱动写法分成设备和驱动两部分，然后挂载到platform总线下。

这种办法的优缺点是：
      稍复杂，易扩展，但冗余代码太多，需要重新编译(通过C文件指定资源)；

第三种方法，也就是我们接下来章节的主角：设备树。

      使用设备树，对于我们的虚拟情景，不需要重新编译内核、重新编译驱动了，只需提供不同的设备树文件。

他的优缺点：
      稍复杂，易扩展，无冗余代码，不需要重新编译内核或者驱动；只需要提供不一样的设备树文件