前言

（1）前面已经已经详细介绍了LED驱动如何进行编写的代码。如果韦东山Linux驱动入门实验班（4）LED驱动已经看懂了，驱动入门实验班后面的那些模块实验，其实和单片机操作差不太多了。我就不再浪费时间进行讲解了。

（2）本文主要进行讲解驱动的分层和分离，平台总线模型。

（3）对于韦东山老师的代码，我进行了微调，因为他代码写的比较着急，所以我感觉有些地方感觉有点冗余了就自作主张的进行了调整。但是原来他的部分没有删除，如果你认为韦东山老师的比我的好就可以注释掉我微调的部分。（微调部分我会进行说明）

（4）代码仓库：gitee仓库；github仓库

（5）注意：大家下载我仓库里面的代码再阅读本文会跟好理解一点。我仓库里面的代码依旧加上了详细的注释，觉得本文过于冗余。可以看我仓库代码和正点原子的文档学习

驱动分层

什么是驱动分层

（1）通过前面的学习，我们会发现，Linux开发将一个程序分成了两个层，应用层和驱动层。但是我们在编写驱动层程序的时候，会发现，驱动还是和指定的引脚以及开发板有关。

（2）这时候肯定会有人说了，我只需要你改一下哪个数组就可以了啊，这有什么难的吗？

（3）不难，但是对于 Linux 这样一个成熟、庞大、复杂的操作系统，代码的重用性非常重要，否则的话就会在 Linux 内核中存在大量无意义的重复代码。尤其是驱动程序，因为驱动程序占用了 Linux内核代码量的大头，如果不对驱动程序加以管理，任由重复的代码肆意增加，那么用不了多久Linux 内核的文件数量就庞大到无法接受的地步。

（4）可能有些人会说了，我之前编写的程序，也没有重复啊。不过就只是要改一下驱动程序的gpios[]结构体的定义。但是，你要知道，在开发大型项目的时候，你将设备信息存入驱动程序中。每次调整都需要打开对应的驱动程序，如果我们不小心动了驱动程序的某个地方，产生了bug，排查是非常麻烦的。所以说，为了让Linux系统不变的臃肿，同时，为了安全性，于是Linux决定将驱动程序拆分成驱动程序和硬件描述程序，驱动程序一旦编写了，基本就不再需要再打开了。

（5）现在我们知道了，驱动程序与硬件描述程序的剥离之后。Linux于是提出了平台总线模型。我们将驱动程序和硬件描述信息都挂载在这个总线上面。

（6）有了这个总线，我们就可以先把我们设备上的一些信息挂载在总线上。然后给这些设备命一个名字。

（7）当我们需要使用指定设备的时候，驱动就可以通过给设备命的名字来找到设备信息。一旦驱动和设备匹配上，就可以执行指定的程序了。

（8）这样做有什么好处？这样我们的驱动程序可以直接进行移植，不需要受限于任何设备。而我们拿到一块开发板之后，可以直接把驱动移植过来，然后再编写设备描述信息即可，驱动代码几乎不再需要进行什么调整。

设备如何挂载在平台总线上

上面我们说了，Linux发明了平台总线，我们只需要将设备和驱动挂载在总线上，如果匹配上了，就会自动执行程序。那么设备是如何挂载在平台总线上。

platform_device_register()

（1）platform_device_register()这个函数可以将设备信息挂载在平台总线上。我们只需要传入struct platform_device结构体类型指针。

（2）如下是platform_device()结构体的定义，虽然参数很多，但是真正需要关注的只有name，id，resource，num_resources，dev。

<1>name：设备的名字， 用来和驱动相匹配。 名字相同才能匹配成功

<2>id：ID 是用来区分如果设备名字相同的时候(通过在后面添加一个数字来代表不同的设备， 因为有时候有这种需求)

<3>resource：资源结构体数组。我们需要写的设备信息写在这个数组里面。

<4>num_resources：资源结构体数量。表明这个设备结构体有多少个，其实就是一个宏定义#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))

<5>dev：与平台设备相关联的设备对象。这个只需要知道要给.release参数传入一个函数指针即可。当设备被卸载的时候，会调用这个函数。

// platform 设备结构体
struct platform_device led_device = {
  .name = "led_device",  //platform 设备的名字， 用来和 platform 驱动相匹配。 名字相同才能匹配成功
  .id = -1,   // ID 是用来区分如果设备名字相同的时候(通过在后面添加一个数字来代表不同的设备， 因为有时候有这种需求)
  .resource = led_resource,  //指向一个资源结构体数组。 一般包含设备信息
  .num_resources = ARRAY_SIZE(led_resource),  //资源结构体数量
  .dev = {
    .release = LED_release,
    }
};

platform_device_unregister()

（1）这个用于将设备从平台总线上卸载。当这个设备不需要的时候，我们就可以对他进行卸载。

（2）与platform_device_register()相同，也是只需要传入struct platform_device结构体类型指针。

设备程序的入口和出口

（1）设备程序和驱动程序一样，都是使用insmod和rmmod进行装载和卸载。程序入口都是使用module_init()宏来进行定义，程序出口也都是使用module_exit()来定义。

（2）他也必须使用调用MODULE_LICENSE(“GPL”);指定模块为GPL协议

驱动如何挂载在平台总线上

platform_driver_register()

（1）这个函数只需要传入一个static struct platform_driver类型结构体指针。

（2）这个驱动的结构体，比设备的那个结构体还是好理解很多的。

<1>我们只需要知道platform_driver结构体".driver"中的".name"和platform_device结构体中的".name"一模一样就可以了。

<2>当设备和驱动匹配上了之后，我们就会执行probe函数。如果设备和驱动一旦断开联系了，就执行remove函数。你可以这么理解，一对男女，男生和女生结婚了，那么就会颁发结婚证（执行probe函数）。有一天，他们俩因为一些事情，感情破裂了，就会给他们一个离婚证（执行remove函数）。

static struct platform_driver led_driver = {
  .driver   = {
    .name = "led_device",   //根据这个名字，找到设备
    .owner = THIS_MODULE,
  },
  .probe    = led_drver_probe,   //注册平台之后，内核如果发现支持某一个平台设备，这个函数就会被调用。入口函数
  .remove   = led_drver_remove,  //出口函数
};

platform_driver_unregister()

这个是用于在平台上卸载驱动的。和platform_driver_register()一样，都是传入一个static struct platform_driver结构体指针。

和上一篇博客的区别

硬件信息不同

（1）这里主要就是把原来放在gpios[] 数组中的硬件描述信息，放在另外一个文件中。让驱动程序与硬件平台剥离。

（2）原来的硬件描述是存放在一个数组中，而现在的硬件描述是放在一个结构体指针里面，然后通过Linux中的平台总线获得设备信息。

/**********   原来的硬件描述  **********/
static struct gpio_desc gpios[] = {
    {131, "led0" },  //引脚编号，名字
};
/**********   现在的硬件描述  **********/
static struct gpio_desc *gpios;   //描述gpio

初始化程序不同

（1）在上一篇博客中，我们的驱动初始化函数都是放在module_init()这个宏里面。

（2）但是现在不一样了，module_init()这个宏里面的那个函数，只做一件事情，就是将static struct platform_driver结构体注册到平台总线上。

/**********   原来的module_init()中的函数任务  **********/
static int __init gpio_drv_init(void)
{
  //申请GPIO
  //将GPIO设置为输出
  //注册字符驱动程序
  //创建类
  //创建设备名/dev目录下的设备名
}
/**********   现在的module_init()中的函数任务  **********/
//注册时候的入口函数
static int __init led_drver_init(void)
{
  int ret = 0;
  // platform驱动注册到 Linux 内核
  ret = platform_driver_register(&led_driver);  //注意，这里是driver表示是驱动
  if(ret<0)
  {
    printk("platform_driver_register error \n");
    return ret;
  }
  printk("platform_driver_register ok \n");
  return ret;
}

初始化程序执行条件不同

（1）原来，我们初始化程序，只需要装载驱动程序即可。

（2）现在不一样了，我们需要注册相互匹配的设备程序和驱动程序，初始化程序probe函数才会执行。

（3）注意，设备程序和驱动程序的注册没有顺序。随便你先注册谁。

获取GPIO数量信息不同

（1）下面这里有些人可能对pdev有疑问，这个是啥玩意？这个东西很简单，pdev就是被匹配上的设备struct platform_device结构体指针。

（2）当驱动和设备匹配上之后，执行probe函数。而这个函数的传入值struct platform_device *pdev就是被匹配上的设备struct platform_device结构体指针。

（3）因为struct platform_device结构体的num_resources记录了资源结构体的数量。所以可以通过pdev -> num_resources获取GPIO数量。

（4）我们看韦东山老师的代码，会发现好长，好麻烦。一开始我也是这么想的，命名一条指令就可以解决，搞这么长干嘛？后面简单的思考了一下。代码些这么长，还是一定作用的。

（5）我们来看platform_get_resource()这个函数，就是用于返回struct platform_device结构体中资源resource中flags被标记为IORESOURCE_IRQ的GPIO的GPIO信息。当我们这个GPIO的flags被标记为IORESOURCE_IRQ，就会返回一个指针指向这里。

（6）如果我们的设备，有些GPIO的flags没有被标记为了IORESOURCE_IRQ，那么就不会被count统计在内。

/**********   原来获取GPIO数量  **********/
int count = sizeof(gpios)/sizeof(gpios[0]);  //统计有多少个GPIO
/**********   现在获取GPIO数量（作者的方法）  **********/
count = pdev -> num_resources;
/**********   现在获取GPIO数量（韦东山老师的方法）  **********/
while (1)
{
  /* 下面这9行，是用于统计有多少个GPIO的
   * dev：一个指向 platform_device 结构的指针，表示要获取资源信息的设备。
   * type：一个无符号整数，表示要获取的资源类型。在 Linux 内核中，资源类型使用常量来表示，
          例如 IORESOURCE_MEM 表示内存资源，IORESOURCE_IRQ 表示中断资源等。你可以根据需要选择适当的资源类型。
   * num：一个无符号整数，表示要获取的资源的索引号。在一个设备中可能存在多个相同类型的资源，通过索引号可以区分它们。
   * 返回值：返回一个指向 resource 结构的指针，表示获取到的资源信息。
             resource 结构包含了资源的起始地址、大小等信息。如果没有找到指定的资源，函数将返回 NULL。
  */
  led_resource = platform_get_resource(pdev, IORESOURCE_IRQ, count);
  if (led_resource)
  {
    count++;
  }
  else
  {
    break;
  }
}

设备结构体gpios空间分配不同

（1）在原来的代码里面，我们的gpios被定义成了一个数组gpios[]。所以当我们在这个数组里面写入设备信息的时候，这个数组会自动改变空间大小。

（2）但是这里的设备信息不在驱动文件里面了，因此我们需要使用内存的动态分配了。我们知道GPIO有多少个之后，调用内存动态分配函数获取一个空间，然后把这个空间的首地址指针返回给gpios。

（3）需要注意的一点是，驱动的动态内存分配不能使用malloc，而是需要使用kmalloc。这个和驱动不能使用printf函数，只能使用printk函数是一个道理。

/**********   原来gpios空间分配  **********/
static struct gpio_desc gpios[] = {
    {131, "led0" },  //引脚编号，名字
};
/**********   现在gpios空间分配  **********/
static struct gpio_desc *gpios;   //描述gpio
/* 作用 ：  kmalloc是Linux内核中的一个内存分配函数，用于在内核空间中动态分配内存。
 *        它类似于C语言中的malloc函数，但是在内核中使用kmalloc而不是 malloc，因为内核空间和用户空间有不同的内存管理机制。
 * size ： 要分配的内存大小，以字节为单位。
 * flags ： 分配内存时的标志，表示内存的类型和分配策略，是一个 gfp_t 类型的值。常常采用GFP_KERNEL
 *          GFP_KERNEL是内存分配的标志之一，它表示在内核中以普通的内核上下文进行内存分配。
 * 返回值 ： 如果内存分配成功，返回指向分配内存区域的指针。如果内存分配失败（例如内存不足），返回NULL。
*/
gpios = kmalloc(count * sizeof(struct gpio_desc), GFP_KERNEL); 

设备结构体gpios硬件信息获取不同

（1）原来，我们直接向gpios[]数组里面写入硬件信息就可以了。

（2）因为现在我们将硬件信息写入了设备程序里面了，所以需要其他办法获得。从设备程序中获得硬件信息有两种方法。

<1>通过pedv指针直接获得硬件信息。

<2>通过platform_get_resource()函数获得。

（3）

<1>我们对比下面的代码会发现，led_resource和pdev->resource[i]是一个东西啊。

<2>可以这么说，但是还是有一定的区别。如果pdev->resource[i]的flags不是IORESOURCE_IRQ，那么就不会被提取出来成led_resource。

/**********   原来gpios获得硬件信息  **********/
static struct gpio_desc gpios[] = {
    {131, "led0" },  //引脚编号，名字
};
/**********   现在gpios获得硬件信息  **********/
//通过pedv指针直接获得硬件信息。
gpios[i].gpio = pdev->resource[i].start;
sprintf(gpios[i].name, "%s", pdev->resource[i].name);   //将platform_device.resource.name传递给gpios[i].name
//通过platform_get_resource()函数获得。
struct resource *led_resource;
led_resource = platform_get_resource(pdev, IORESOURCE_IRQ, i);  //从节点里面取出第i项  
gpios[i].gpio = led_resource->start;               //将需要操作的IO号传递给gpios[i].gpio
sprintf(gpios[i].name, "%s", led_resource->name);   //将platform_device.resource.name传递给gpios[i].name