linux驱动分离值platform模型

在上篇我们引入了驱动分离的思想，那么在Linux内核是如何使用代码实现的呢？

由上图可知，linux内核已经帮我们实现了很多，它把总线、设备、驱动都抽像成一个结构体，使用链表等数据结构将它们管理起来。按照上图的流程当我们加载对应的模块的时候就会通过总线的match函数区匹配driver和device，匹配成功之后就会调用driver结构体里面的probe函数如下图所示。这样我们就可以在probe函数里面做我们以前写字符设备的那一套流程了。

到这里如果你这样的疑问：就写一个点灯的代码有必要搞那么复杂吗？跟我们以前那一套字符设备流程差别在哪里？注意：有疑问是好的，证明你开始思考这个机制的作用了。我们将驱动分离为两个.c文件，并且内核在代码实现上将它们抽象为总线、设备、驱动等结构体的形式表现出来，那么我们肯定希望跟硬件引脚资源相关的定义放在device.c上，在driver.c上希望能够读取device.c定义好的引脚资源，进而编写驱动程序（这里可能还有一些新手朋友不太理解，说白了就是在device.c上定义引脚变量，在driver.c调用这个变量的意思）。这样一旦我需要将点灯代码改为控制蜂鸣器的代码，我就不用改动driver.c中的代码，只需要改动devic.c的代码即可，这样就大大提高了驱动的可移植性。

匹配过程如下图所示：

不管是先加载驱动还是先加载设备都没有关系，因为他们之间是“相爱”的！（这里开个玩笑哈哈），实际它们在加载的时候都会匹配对方的链表上的driver/device看能不能匹配上。如果到这里还是不能够理解driver.c如何获取devic.c的引脚资源，那还是直接上代码吧。

使用platform步骤如下图所示：

以前的驱动写法：

分析platform被注册驱动的的过程：

先加载device的匹配过程如下：会一一匹配driver，但在匹配每一个驱动之前先判断该设备是否有匹配过，如果没有就进行匹配，然后直接执行driver的probe，否则就直接返回，因为一个设备只能对应一个驱动。

如实先加载driver，会一一匹配所有的dev，因为一个driver支持多个设备，如下图所示：

match匹配方法有5种如下所示：

最后还有一个有关私有数据的使用，在driver结构体、和device结构体中都有一个存放私有数据的成员。使用它通常可以避免使用全局变量。

至此整个linux驱动中的平台总线就讲解到这里，更多知识请关注笔者！！！