版权声明：

本文由电子技术应用博主“cuter”发布。欢迎转载，但不得擅自更改博文内容，也不得用于任何盈利目的。转载时不得删除作者简介和版权声明。如有盗用而不说明出处引起的版权纠纷，由盗用者自负。

博客官方地址：

ChinaAET: http://blog.chinaaet.com/cuter521

EDN China: http://bbs.ednchina.com/BLOG_cuter521_356737.HTM

1 什么是Platform driver，和普通driver有什么区别？

因为我的学习目标是驱动开发，所以自然而然会想到这个问题。

i) Platform driver

Driver必然对应设备这个概念，因为driver的作用就是驱动设备，那么platform driver大概是用来驱动platform device的吧？platform device | driver是Linux 2.6内核引入的一套新的驱动注册和管理机制。Platform device是连接到platform bus（一种虚拟的总线）上的设备的统称，相应的驱动称为platform driver。

ii) 和普通driver的区别

Linux设备驱动可以分为三类：字符设备、块设备以及网络设备。Platform device并非一种新的设备驱动类型，是为了简化驱动开发抽象出来的一个概念，例如Zynq中，把PS内集成的各种控制器（UART、IIC、SPI、GPIO...）都视为platform device，而他们本身就是字符设备。

iii) 优势和缺点

关于这个还没有想太清楚，网上的文章大多都是转来转去，没有找到Linux 2.6引入platform bus的原因，总觉得是有好处的，比如在移植性方面，随着学习的深入再慢慢体会吧；吐槽倒是有，说“这种模式破坏了Linux的简单就是美的哲学”，因为原来的那套驱动机制已经可以囊括所有驱动，何必虚拟出一个bus来混淆视听……

2 Platform driver开发流程

如图所示，Platform设备驱动开发大致可以分为4个步骤，前两步和设备相关，由系统配合设备树完成；后面和驱动相关，需要自行开发。

2.1) 注册platform bus详细过程为：

2.2) 注册platform device详细过程为：

这里面还是有很多细节，就不一一解释了，一个一个函数看进去还是需要一些功夫的，以后在分析Linux启动过程的时候，可以深入看一看这些内容。为了现阶段的学习目标，我们这里先放一放，总而言之系统为我们完成了准备工作。当然，在系统移植的时候就该深入研究各个平台相关的函数，看是否需要修改。

2.3) 注册platform driver详细过程：

第5点也算回答了上篇文章网友的提问，驱动程序是可以支持多个设备的，要不然哪来的万能驱动呢？

MODULE_DEVICE_TABLE一般用在热插拔的设备驱动中。上述myled_of_match[]是此驱动所支持的设备列表。MODULE_DEVICE_TABLE将myled_of_match输出到用户空间，这样模块加载系统在加载模块时，就知道了什么模块对应什么硬件设备。

具体用法：MODULE_DEVICE_TABLE（设备类型，设备表），其中，设备类型，包括USB,PCI等，也可以自己起名字；设备表也是自己定义的，它的最后一项必须是空，用来标识结束。

2.4) 设备操作

将所有设备都抽象成文件进行操作是Linux的一大特色，设备驱动自然也不例外。这里发现一点小问题，初始化proc_myled_opertaions.read时使用了seq_read，但在驱动程序里定义的读函数却是proc_myled_show，在实际使用时，读led状态也是失败的。所以这里的初始化应该是有问题的，下次要改掉测试一下。

3 结束语

将2.3和2.4联合起来看，很容易发现驱动程序可以分为两部分，一是文件操作相关的各个函数，二是驱动本身的成员函数。至此，已经将platform driver开发流程、驱动程序的结构分析清楚，在进行自主设计时，参照该驱动程序的框架结构设计出自己想要的函数就可以了。接下来可以仔细学习驱动程序里各个函数的具体实现，搞清楚前因后果，就算是完成了platform driver的初步学习，接下来就可以自己尝试进行开发了。