platform其实就是linux中用来匹配设备和驱动的一种虚拟总线技术。之所以有这么个技术，是为了将驱动和设备分开来，设备负责描述设备信息，驱动负责实现功能逻辑。是一种分层思想下的产物。platform并不是局限于某一类设备，而是整个框架。platform平台，可以理解成：为设备和驱动提供一个互相匹配的平台。platform分为platform_device和platform_driver，就算是用设备树来描述设备信息，内核也会将其转换成platform_device。
对于 Linux 这样一个成熟、庞大、复杂的操作系统，代码的重用性非常重要，否则的话就会在 Linux 内核中存在大量无意义的重复代码。尤其是驱动程序，因为驱动程序占用了 Linux内核代码量的大头，如果不对驱动程序加以管理，任由重复的代码肆意增加，那么用不了多久Linux 内核的文件数量就庞大到无法接受的地步。
接下来详细叙述。
设备和驱动的分离
将设备信息从设备驱动中剥离开来，驱动使用标准方法去获取到设备信息(比如从设备树中获取到设备信息)，然后根据获取到的设备信息来初始化设备。 这样就相当于驱动只负责驱动，设备只负责设备，想办法将两者进行匹配即可。这个就是 Linux 中的总线(bus)、驱动(driver)和设备(device)模型，也就是常说的驱动分离。总线就是驱动和设备信息的月老，负责给两者牵线搭桥，如图 54.1.1.4 所示：
当我们向系统注册一个驱动的时候，总线就会在右侧的设备中查找，看看有没有与之匹配的设备，如果有的话就将两者联系起来。同样的，当向系统中注册一个设备的时候，总线就会在左侧的驱动中查找看有没有与之匹配的设备，有的话也联系起来。Linux 内核中大量的驱动程序都采用总线、驱动和设备模式，我们一会要重点讲解的 platform 驱动就是这一思想下的产物。
接下来我们简单看一下驱动的分层，大家应该听说过网络的 7 层模型，不同的层负责不同的内容。同样的，Linux 下的驱动往往也是分层的，分层的目的也是为了在不同的层处理不同的内容。以其他书籍或者资料常常使用到的input(输入子系统，后面会有专门的章节详细的讲解)为例，简单介绍一下驱动的分层。input 子系统负责管理所有跟输入有关的驱动，包括键盘、鼠标、触摸等，最底层的就是设备原始驱动，负责获取输入设备的原始值，获取到的输入事件上报给 input 核心层。input 核心层会处理各种 IO 模型，并且提供 file_operations 操作集合。我们在编写输入设备驱动的时候只需要处理好输入事件的上报即可，至于如何处理这些上报的输入事件那是上层去考虑的，我们不用管。可以看出借助分层模型可以极大的简化我们的驱动编写，对于驱动编写来说非常的友好。
platform平台驱动模型简介
前面我们讲了设备驱动的分离，并且引出了总线(bus)、驱动(driver)和设备(device)模型，比如 I2C、SPI、USB 等总线。但是在 SOC 中有些外设是没有总线这个概念的，但是又要使用总线、驱动和设备模型该怎么办呢？为了解决此问题，Linux 提出了 platform 这个虚拟总线，相应的就有 platform_driver 和 platform_device。
这里的设备和驱动要怎么理解呢？
设备是硬件设备的抽象表示。每个设备都有一个设备名称和一组功能。设备名称是设备驱动程序通过与硬件交互获得的，而设备功能是设备驱动程序需要使用的，是由操作系统指定的。 在 Linux 系统中，每个设备都由一个设备树形结构来描述，设备树中的节点包括设备的名称、类型、物理地址等信息。设备驱动程序可以使用/sys/devices目录下的文件和函数来访问设备树。
驱动程序是操作系统中连接设备和应用程序的接口。驱动程序必须实现设备与应用之间的交互，并向上层应用程序提供统一的接口。驱动程序也需要实现各种各样的设备特定的功能和命令，以便应用程序可以直接与设备进行交互。 在 Linux 系统中，驱动程序是内核模块，可以通过lsmod命令查看已加载的驱动程序。驱动程序需要实现驱动程序接口，这些接口是标准的Linux系统接口，实现了一组通用的设备驱动程序函数。
platform总线
Linux系统内核使用bus_type 结构体表示总线，此结构体定义在文件 include/linux/device.h，bus_type 结构体内容如下：
示例代码 54.2.1.1 bus_type 结构体代码段 1 struct bus_type { 2 const char *name; /* 总线名字 */ 3 const char *dev_name; 4 struct device *dev_root; 5 struct device_attribute *dev_attrs; 6 const struct attribute_group **bus_groups; /* 总线属性 */ 7 const struct attribute_group **dev_groups; /* 设备属性 */ 8 const struct attribute_group **drv_groups; /* 驱动属性 */ 9 10 int (*match)(struct device *dev, struct device_driver *drv); 11 int (*uevent)(struct device *dev, struct kobj_uevent_env *env); 12 int (*probe)(struct device *dev); 13 int (*remove)(struct device *dev); 14 void (*shutdown)(struct device *dev); 15 16 int (*online)(struct device *dev); 17 int (*offline)(struct device *dev); 18 int (*suspend)(struct device *dev, pm_message_t state); 19 int (*resume)(struct device *dev); 20 const struct dev_pm_ops *pm; 21 const struct iommu_ops *iommu_ops; 22 struct subsys_private *p; 23 struct lock_class_key lock_key; 24 };第 10 行，match 函数，此函数很重要，单词 match 的意思就是“匹配、相配”，因此此函数就是完成设备和驱动之间匹配的，总线就是使用 match 函数来根据注册的设备来查找对应的驱动，或者根据注册的驱动来查找相应的设备，因此每一条总线都必须实现此函数。match 函数有两个参数：dev 和 drv，这两个参数分别为 device 和 device_driver 类型，也就是设备和驱动。
platform 总线是 bus_type 的一个具体实例，定义在文件 drivers/base/platform.c，platform 总线定义如下：
platform_bus_type 就是 platform 平台总线，其中 platform_match 就是匹配函数。我们来看一下驱动和设备是如何匹配的，platform_match 函数定义在文件 drivers/base/platform.c 中，函数内容如下所示：
驱动和设备的匹配有四种方法，我们依次来看一下：
第 11~12 行，第一种匹配方式， OF 类型的匹配，也就是设备树采用的匹配方式，of_driver_match_device 函数定义在文件 include/linux/of_device.h 中。device_driver 结构体(表示设备驱动)中有个名为of_match_table的成员变量，此成员变量保存着驱动的compatible匹配表，设备树中的每个设备节点的 compatible 属性会和 of_match_table 表中的所有成员比较，查看是否有相同的条目，如果有的话就表示设备和此驱动匹配，设备和驱动匹配成功以后 probe 函数就会执行。
第 15~16 行，第二种匹配方式，ACPI 匹配方式。
第 19~20 行，第三种匹配方式，id_table 匹配，每个 platform_driver 结构体有一个 id_table成员变量，顾名思义，保存了很多 id 信息。这些 id 信息存放着这个 platformd 驱动所支持的驱动类型。
第 23 行，第四种匹配方式，如果第三种匹配方式的 id_table 不存在的话就直接比较驱动和设备的 name 字段，看看是不是相等，如果相等的话就匹配成功。
对于支持设备树的 Linux 版本号，一般设备驱动为了兼容性都支持设备树和无设备树两种匹配方式。也就是第一种匹配方式一般都会存在，第三种和第四种只要存在一种就可以，一般用的最多的还是第四种，也就是直接比较驱动和设备的 name 字段，毕竟这种方式最简单了。
platform驱动
platform_driver 结构体表示 platform 驱动，此结构体定义在文件include/linux/platform_device.h 中，内容如下：
第 2 行，probe 函数，当驱动与设备匹配成功以后 probe 函数就会执行，非常重要的函数！！一般驱动的提供者会编写，如果自己要编写一个全新的驱动，那么 probe 就需要自行实现。
第 7 行，driver 成员，为 device_driver 结构体变量，Linux 内核里面大量使用到了面向对象的思维，device_driver 相当于基类，提供了最基础的驱动框架。plaform_driver 继承了这个基类，然后在此基础上又添加了一些特有的成员变量。
这里我要补充下：
所谓继承的思想，在结构体里的体现就是，定义一个结构体A，然后在另一个结构体B里面包含A，这样的话，从继承角度来说，A就是父类，B就是子类，B可以基于A来扩展。
第 8 行，id_table 表，也就是我们上一小节讲解 platform 总线匹配驱动和设备的时候采用的第三种方法，id_table 是个表( 也就是数组) ，每个元素的类型为 platform_device_id，platform_device_id 结构体内容如下：
device_driver 结构体定义在 include/linux/device.h，device_driver 结构体内容如下：
第 10 行，of_match_table 就是采用设备树的时候驱动使用的匹配表，同样是数组，每个匹配项都为 of_device_id 结构体类型，此结构体定义在文件 include/linux/mod_devicetable.h 中，内容如下：
第 4 行的 compatible 非常重要，因为对于设备树而言，就是通过设备节点的 compatible 属性值和 of_match_table 中每个项目的 compatible 成员变量进行比较，如果有相等的就表示设备和此驱动匹配成功。
在编写 platform 驱动的时候，首先定义一个 platform_driver 结构体变量，然后实现结构体中的各个成员变量，重点是实现匹配方法以及 probe 函数。当驱动和设备匹配成功以后 probe函数就会执行，具体的驱动程序在 probe 函数里面编写，比如字符设备驱动等等。
当我们定义并初始化好 platform_driver 结构体变量以后，需要在驱动入口函数里面调用platform_driver_register 函数向 Linux 内核注册一个 platform 驱动，platform_driver_register 函数原型如下所示：
int platform_driver_register (struct platform_driver *driver)函数参数和返回值含义如下：
driver：要注册的 platform 驱动。
返回值：负数，失败；0，成功。
还需要在驱动卸载函数中通过 platform_driver_unregister 函数卸载 platform 驱动，
platform_driver_unregister 函数原型如下：
void platform_driver_unregister(struct platform_driver *drv)函数参数和返回值含义如下：
drv：要卸载的 platform 驱动。
返回值：无。
platform 驱动框架如下所示：
示例代码 54.2.2.5 platform 驱动框架 /* 设备结构体 */ 1 struct xxx_dev{ 2 struct cdev cdev; 3 /* 设备结构体其他具体内容 */ 4 }; 5 6 struct xxx_dev xxxdev; /* 定义个设备结构体变量 */ 7 8 static int xxx_open(struct inode *inode, struct file *filp) 9 { 10 /* 函数具体内容 */ 11 return 0; 12 } 13 14 static ssize_t xxx_write(struct file *filp, const char __user *buf, size_t cnt, loff_t *offt) 15 { 16 /* 函数具体内容 */ 17 return 0; 18 } 19 20 /* 21 * 字符设备驱动操作集 22 */ 23 static struct file_operations xxx_fops = { 24 .owner = THIS_MODULE, 25 .open = xxx_open, 26 .write = xxx_write, 27 }; 28 29 /* 30 * platform 驱动的 probe 函数 31 * 驱动与设备匹配成功以后此函数就会执行 32 */ 33 static int xxx_probe(struct platform_device *dev) 34 { 35 ...... 36 cdev_init(&xxxdev.cdev, &xxx_fops); /* 注册字符设备驱动 */ 37 /* 函数具体内容 */ 38 return 0; 39 } 40 41 static int xxx_remove(struct platform_device *dev) 42 { 43 ...... 44 cdev_del(&xxxdev.cdev);/* 删除 cdev */ 45 /* 函数具体内容 */ 46 return 0; 47 } 48 49 /* 匹配列表 */ 50 static const struct of_device_id xxx_of_match[] = { 51 { .compatible = "xxx-gpio" }, 52 { /* Sentinel */ } 53 }; 54 55 /* 56 * platform 平台驱动结构体 57 */ 58 static struct platform_driver xxx_driver = { 59 .driver = { 60 .name = "xxx", 61 .of_match_table = xxx_of_match, 62 }, 63 .probe = xxx_probe, 64 .remove = xxx_remove, 65 }; 66 67 /* 驱动模块加载 */ 68 static int __init xxxdriver_init(void) 69 { 70 return platform_driver_register(&xxx_driver); 71 } 72 73 /* 驱动模块卸载 */ 74 static void __exit xxxdriver_exit(void) 75 { 76 platform_driver_unregister(&xxx_driver); 77 } 78 79 module_init(xxxdriver_init); 80 module_exit(xxxdriver_exit); 81 MODULE_LICENSE("GPL"); 82 MODULE_AUTHOR("zuozhongkai");第 1~27 行，传统的字符设备驱动，所谓的 platform 驱动并不是独立于字符设备驱动、块设备驱动和网络设备驱动之外的其他种类的驱动。platform 只是为了驱动的分离与分层而提出来的一种框架，其驱动的具体实现还是需要字符设备驱动、块设备驱动或网络设备驱动。
第 33~39 行，xxx_probe 函数，当驱动和设备匹配成功以后此函数就会执行，以前在驱动入口 init 函数里面编写的字符设备驱动程序就全部放到此 probe 函数里面。比如注册字符设备驱动、添加 cdev、创建类等等。
第 41~47 行，xxx_remove 函数，platform_driver 结构体中的 remove 成员变量，当关闭 platform设备驱动的时候此函数就会执行，以前在驱动卸载 exit 函数里面要做的事情就放到此函数中来。比如，使用 iounmap 释放内存、删除 cdev，注销设备号等等。
第 50~53 行，xxx_of_match 匹配表，如果使用设备树的话将通过此匹配表进行驱动和设备的匹配。第 51 行设置了一个匹配项，此匹配项的 compatible 值为“xxx-gpio”，因此当设备树中设备节点的 compatible 属性值为“xxx-gpio”的时候此设备就会与此驱动匹配。第 52 行是一个标记，of_device_id 表最后一个匹配项必须是空的。
第 58~65 行，定义一个 platform_driver 结构体变量 xxx_driver，表示 platform 驱动，第 59~62行设置 paltform_driver 中的 device_driver 成员变量的 name 和 of_match_table 这两个属性。其中name 属性用于传统的驱动与设备匹配，也就是检查驱动和设备的 name 字段是不是相同。of_match_table 属性就是用于设备树下的驱动与设备检查。对于一个完整的驱动程序，必须提供有设备树和无设备树两种匹配方法。最后 63 和 64 这两行设置 probe 和 remove 这两成员变量。
第68~71行，驱动入口函数，调用platform_driver_register函数向Linux内核注册一个platform驱动，也就是上面定义的 xxx_driver 结构体变量。
第 74~77 行，驱动出口函数，调用 platform_driver_unregister 函数卸载前面注册的 platform驱动。
总体来说，platform 驱动还是传统的字符设备驱动、块设备驱动或网络设备驱动，只是套上了一张“platform”的皮，目的是为了使用总线、驱动和设备这个驱动模型来实现驱动的分离与分层。
platform设备
platform 驱动已经准备好了，我们还需要 platform 设备，否则的话单单一个驱动也做不了什么。platform_device 这个结构体表示 platform 设备，这里我们要注意，如果内核支持设备树的话就不要再使用 platform_device 来描述设备了，因为改用设备树去描述了。当然了，你如果一定要用 platform_device 来描述设备信息的话也是可以的。platform_device 结构体定义在文件include/linux/platform_device.h 中，结构体内容如下：
第 23 行，name 表示设备名字，要和所使用的 platform 驱动的 name 字段相同，否则的话设备就无法匹配到对应的驱动。比如对应的 platform 驱动的 name 字段为“xxx-gpio”，那么此 name字段也要设置为“xxx-gpio”。
第 27 行，num_resources 表示资源数量，一般为第 28 行 resource 资源的大小。
第 28 行，resource 表示资源，也就是设备信息，比如外设寄存器等。Linux 内核使用 resource结构体表示资源，resource 结构体内容如下：
start 和 end 分别表示资源的起始和终止信息，对于内存类的资源，就表示内存起始和终止地址，name 表示资源名字，flags 表示资源类型，可选的资源类型都定义在了文件include/linux/ioport.h 里面，如下所示：
在以前不支持设备树的Linux版本中，用户需要编写platform_device变量来描述设备信息，然后使用 platform_device_register 函数将设备信息注册到 Linux 内核中，此函数原型如下所示：
int platform_device_register(struct platform_device *pdev)函数参数和返回值含义如下：
pdev：要注册的 platform 设备。
返回值：负数，失败；0，成功。
如果不再使用 platform 的话可以通过 platform_device_unregister 函数注销掉相应的 platform设备，platform_device_unregister 函数原型如下：
void platform_device_unregister(struct platform_device *pdev)函数参数和返回值含义如下：
pdev：要注销的 platform 设备。
返回值：无。
platform 设备信息框架如下所示：
示例代码 54.2.3.4 platform 设备框架 1 /* 寄存器地址定义*/ 2 #define PERIPH1_REGISTER_BASE (0X20000000) /* 外设 1 寄存器首地址 */ 3 #define PERIPH2_REGISTER_BASE (0X020E0068) /* 外设 2 寄存器首地址 */ 4 #define REGISTER_LENGTH 4 5 6 /* 资源 */ 7 static struct resource xxx_resources[] = { 8 [0] = { 9 .start = PERIPH1_REGISTER_BASE, 10 .end = (PERIPH1_REGISTER_BASE + REGISTER_LENGTH - 1), 11 .flags = IORESOURCE_MEM, 12 }, 13 [1] = { 14 .start = PERIPH2_REGISTER_BASE, 15 .end = (PERIPH2_REGISTER_BASE + REGISTER_LENGTH - 1), 16 .flags = IORESOURCE_MEM, 17 }, 18 }; 19 20 /* platform 设备结构体 */ 21 static struct platform_device xxxdevice = { 22 .name = "xxx-gpio", 23 .id = -1, 24 .num_resources = ARRAY_SIZE(xxx_resources), 25 .resource = xxx_resources, 26 }; 27 28 /* 设备模块加载 */ 29 static int __init xxxdevice_init(void) 30 { 31 return platform_device_register(&xxxdevice); 32 } 33 34 /* 设备模块注销 */ 35 static void __exit xxx_resourcesdevice_exit(void) 36 { 37 platform_device_unregister(&xxxdevice); 38 } 39 40 module_init(xxxdevice_init); 41 module_exit(xxxdevice_exit); 42 MODULE_LICENSE("GPL"); 43 MODULE_AUTHOR("zuozhongkai");第 7~18 行，数组 xxx_resources 表示设备资源，一共有两个资源，分别为设备外设 1 和外设 2 的寄存器信息。因此 flags 都为 IORESOURCE_MEM，表示资源为内存类型的。
第 21~26 行，platform 设备结构体变量，注意 name 字段要和所使用的驱动中的 name 字段一致，否则驱动和设备无法匹配成功。num_resources 表示资源大小，其实就是数组 xxx_resources的元素数量，这里用 ARRAY_SIZE 来测量一个数组的元素个数。
第 29~32 行，设备模块加载函数，在此函数中调用 platform_device_register 向 Linux 内核注册 platform 设备。
第 35~38 行，设备模块卸载函数，在此函数中调用 platform_device_unregister 从 Linux 内核中卸载 platform 设备。
示例代码 54.2.3.4 主要是在不支持设备树的 Linux 版本中使用的，当 Linux 内核支持了设备树以后就不需要用户手动去注册 platform 设备了。因为设备信息都放到了设备树中去描述，Linux 内核启动的时候会从设备树中读取设备信息，然后将其组织成 platform_device 形式，至于设备树到 platform_device 的具体过程就不去详细的追究了，感兴趣的可以去看一下，网上也有很多博客详细的讲解了整个过程。
不使用设备树的platform框架
关于 platform 下的总线、驱动和设备就讲解到这里，我们接下来就使用 platform 驱动框架来编写一个 LED 灯驱动，本章我们不使用设备树来描述设备信息，我们采用自定义platform_device这种“古老”方式来编写LED的设备信息。之后我们来编写设备树下的platform驱动，这样我们就掌握了无设备树和有设备树这两种 platform 驱动的开发方式。
本章实验我们需要编写一个驱动模块和一个设备模块，其中驱动模块是 platform 驱动程序，设备模块是 platform 的设备信息。当这两个模块都加载成功以后就会匹配成功，然后 platform驱动模块中的 probe 函数就会执行，probe 函数中就是传统的字符设备驱动那一套。
新建名为 leddevice.c 和 leddriver.c 这两个文件，这两个文件分别为 LED灯的 platform 设备文件和 LED 灯的 platform 的驱动文件。
platform设备文件
在 leddevice.c 中输入如下所示内容：
示例代码 54.4.1.1 leddevice.c 文件代码段 1 #include <linux/types.h> 2 #include <linux/kernel.h> 3 #include <linux/delay.h> 4 #include <linux/ide.h> 5 #include <linux/init.h> 6 #include <linux/module.h> 7 #include <linux/errno.h> 8 #include <linux/gpio.h> 9 #include <linux/cdev.h> 10 #include <linux/device.h> 11 #include <linux/of_gpio.h> 12 #include <linux/semaphore.h> 13 #include <linux/timer.h> 14 #include <linux/irq.h> 15 #include <linux/wait.h> 16 #include <linux/poll.h> 17 #include <linux/fs.h> 18 #include <linux/fcntl.h> 19 #include <linux/platform_device.h> 20 #include <asm/mach/map.h> 21 #include <asm/uaccess.h> 22 #include <asm/io.h> 23 /*************************************************************** 24 Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved. 25 文件名 : leddevice.c 26 作者 : 左忠凯 27 版本 : V1.0 28 描述 : platform 设备 29 其他 : 无 30 论坛 : www.openedv.com 31 日志 : 初版 V1.0 2019/8/13 左忠凯创建 32 ***************************************************************/ 33 34 /* 35 * 寄存器地址定义 36 */ 37 #define CCM_CCGR1_BASE (0X020C406C) 38 #define SW_MUX_GPIO1_IO03_BASE (0X020E0068) 39 #define SW_PAD_GPIO1_IO03_BASE (0X020E02F4) 40 #define GPIO1_DR_BASE (0X0209C000) 41 #define GPIO1_GDIR_BASE (0X0209C004) 42 #define REGISTER_LENGTH 4 43 44 /* @description : 释放 flatform 设备模块的时候此函数会执行 45 * @param - dev : 要释放的设备 46 * @return : 无 47 */ 48 static void led_release(struct device *dev) 49 { 50 printk("led device released!\r\n"); 51 } 52 53 /* 54 * 设备资源信息，也就是 LED0 所使用的所有寄存器 55 */ 56 static struct resource led_resources[] = { 57 [0] = { 58 .start = CCM_CCGR1_BASE, 59 .end = (CCM_CCGR1_BASE + REGISTER_LENGTH - 1), 60 .flags = IORESOURCE_MEM, 61 }, 62 [1] = { 63 .start = SW_MUX_GPIO1_IO03_BASE, 64 .end = (SW_MUX_GPIO1_IO03_BASE + REGISTER_LENGTH - 1), 65 .flags = IORESOURCE_MEM, 66 }, 67 [2] = { 68 .start = SW_PAD_GPIO1_IO03_BASE, 69 .end = (SW_PAD_GPIO1_IO03_BASE + REGISTER_LENGTH - 1), 70 .flags = IORESOURCE_MEM, 71 }, 72 [3] = { 73 .start = GPIO1_DR_BASE, 74 .end = (GPIO1_DR_BASE + REGISTER_LENGTH - 1), 75 .flags = IORESOURCE_MEM, 76 }, 77 [4] = { 78 .start = GPIO1_GDIR_BASE, 79 .end = (GPIO1_GDIR_BASE + REGISTER_LENGTH - 1), 80 .flags = IORESOURCE_MEM, 81 }, 82 }; 83 84 85 /* 86 * platform 设备结构体 87 */ 88 static struct platform_device leddevice = { 89 .name = "imx6ul-led", 90 .id = -1, 91 .dev = { 92 .release = &led_release, 93 }, 94 .num_resources = ARRAY_SIZE(led_resources), 95 .resource = led_resources, 96 }; 97 98 /* 99 * @description : 设备模块加载 100 * @param : 无 101 * @return : 无 102 */ 103 static int __init leddevice_init(void) 104 { 105 return platform_device_register(&leddevice); 106 } 107 108 /* 109 * @description : 设备模块注销 110 * @param : 无 111 * @return : 无 112 */ 113 static void __exit leddevice_exit(void) 114 { 115 platform_device_unregister(&leddevice); 116 } 117 118 module_init(leddevice_init); 119 module_exit(leddevice_exit); 120 MODULE_LICENSE("GPL"); 121 MODULE_AUTHOR("zuozhongkai");leddevice.c 文件内容就是按照示例代码 54.2.3.4 的 platform 设备模板编写的。
第 56~82 行，led_resources 数组，也就是设备资源，描述了 LED 所要使用到的寄存器信息，也就是 IORESOURCE_MEM 资源。
第 88~96，platform 设备结构体变量 leddevice，这里要注意 name 字段为“imx6ul-led”，所以稍后编写 platform 驱动中的 name 字段也要为“imx6ul-led”，否则设备和驱动匹配失败。
第 103~106 行，设备模块加载函数，在此函数里面通过 platform_device_register 向 Linux 内核注册 leddevice 这个 platform 设备。
第 113~116 行，设备模块卸载函数，在此函数里面通过 platform_device_unregister 从 Linux内核中删除掉 leddevice 这个 platform 设备。
platform驱动文件
leddevice.c 文件编写完成以后就编写 leddriver.c 这个 platform 驱动文件，在 leddriver.c 里面输入如下内容：
示例代码 54.4.1.2 leddriver.c 文件代码段 1 #include <linux/types.h> 2 #include <linux/kernel.h> 3 #include <linux/delay.h> 4 #include <linux/ide.h> 5 #include <linux/init.h> 6 #include <linux/module.h> 7 #include <linux/errno.h> 8 #include <linux/gpio.h> 9 #include <linux/cdev.h> 10 #include <linux/device.h> 11 #include <linux/of_gpio.h> 12 #include <linux/semaphore.h> 13 #include <linux/timer.h> 14 #include <linux/irq.h> 15 #include <linux/wait.h> 16 #include <linux/poll.h> 17 #include <linux/fs.h> 18 #include <linux/fcntl.h> 19 #include <linux/platform_device.h> 20 #include <asm/mach/map.h> 21 #include <asm/uaccess.h> 22 #include <asm/io.h> 23 /*************************************************************** 24 Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved. 25 文件名 : leddriver.c 26 作者 : 左忠凯 27 版本 : V1.0 28 描述 : platform 驱动 29 其他 : 无 30 论坛 : www.openedv.com 31 日志 : 初版 V1.0 2019/8/13 左忠凯创建 32 ***************************************************************/ 33 34 #define LEDDEV_CNT 1 /* 设备号长度 */ 35 #define LEDDEV_NAME "platled" /* 设备名字 */ 36 #define LEDOFF 0 37 #define LEDON 1 38 39 /* 寄存器名 */ 40 static void __iomem *IMX6U_CCM_CCGR1; 41 static void __iomem *SW_MUX_GPIO1_IO03; 42 static void __iomem *SW_PAD_GPIO1_IO03; 43 static void __iomem *GPIO1_DR; 44 static void __iomem *GPIO1_GDIR; 45 46 /* leddev 设备结构体 */ 47 struct leddev_dev{ 48 dev_t devid; /* 设备号 */ 49 struct cdev cdev; /* cdev */ 50 struct class *class; /* 类 */ 51 struct device *device; /* 设备 */ 52 int major; /* 主设备号 */ 53 }; 54 55 struct leddev_dev leddev; /* led 设备 */ 56 57 /* 58 * @description : LED 打开/关闭 59 * @param - sta : LEDON(0) 打开 LED，LEDOFF(1) 关闭 LED 60 * @return : 无 61 */ 62 void led0_switch(u8 sta) 63 { 64 u32 val = 0; 65 if(sta == LEDON){ 66 val = readl(GPIO1_DR); 67 val &= ~(1 << 3); 68 writel(val, GPIO1_DR); 69 }else if(sta == LEDOFF){ 70 val = readl(GPIO1_DR); 71 val|= (1 << 3); 72 writel(val, GPIO1_DR); 73 } 74 } 75 76 /* 77 * @description : 打开设备 78 * @param – inode : 传递给驱动的 inode 79 * @param - filp : 设备文件，file 结构体有个叫做 private_data 的成员变量 80 * 一般在 open 的时候将 private_data 指向设备结构体。 81 * @return : 0 成功;其他 失败 82 */ 83 static int led_open(struct inode *inode, struct file *filp) 84 { 85 filp->private_data = &leddev; /* 设置私有数据 */ 86 return 0; 87 } 88 89 /* 90 * @description : 向设备写数据 91 * @param – filp : 设备文件，表示打开的文件描述符 92 * @param - buf : 要写给设备写入的数据 93 * @param - cnt : 要写入的数据长度 94 * @param - offt : 相对于文件首地址的偏移 95 * @return : 写入的字节数，如果为负值，表示写入失败 96 */ 97 static ssize_t led_write(struct file *filp, const char __user *buf, size_t cnt, loff_t *offt) 98 { 99 int retvalue; 100 unsigned char databuf[1]; 101 unsigned char ledstat; 102 103 retvalue = copy_from_user(databuf, buf, cnt); 104 if(retvalue < 0) { 105 return -EFAULT; 106 } 107 108 ledstat = databuf[0]; /* 获取状态值 */ 109 if(ledstat == LEDON) { 110 led0_switch(LEDON); /* 打开 LED 灯 */ 111 }else if(ledstat == LEDOFF) { 112 led0_switch(LEDOFF); /* 关闭 LED 灯 */ 113 } 114 return 0; 115 } 116 117 /* 设备操作函数 */ 118 static struct file_operations led_fops = { 119 .owner = THIS_MODULE, 120 .open = led_open, 121 .write = led_write, 122 }; 123 124 /* 125 * @description : flatform 驱动的 probe 函数，当驱动与设备 126 * 匹配以后此函数就会执行 127 * @param - dev : platform 设备 128 * @return : 0，成功;其他负值,失败 129 */ 130 static int led_probe(struct platform_device *dev) 131 { 132 int i = 0; 133 int ressize[5]; 134 u32 val = 0; 135 struct resource *ledsource[5]; 136 137 printk("led driver and device has matched!\r\n"); 138 /* 1、获取资源 */ 139 for (i = 0; i < 5; i++) { 140 ledsource[i] = platform_get_resource(dev, IORESOURCE_MEM, i); 141 if (!ledsource[i]) { 142 dev_err(&dev->dev, "No MEM resource for always on\n"); 143 return -ENXIO; 144 } 145 ressize[i] = resource_size(ledsource[i]); 146 } 147 148 /* 2、初始化 LED */ 149 /* 寄存器地址映射 */ 150 IMX6U_CCM_CCGR1 = ioremap(ledsource[0]->start, ressize[0]); 151 SW_MUX_GPIO1_IO03 = ioremap(ledsource[1]->start, ressize[1]); 152 SW_PAD_GPIO1_IO03 = ioremap(ledsource[2]->start, ressize[2]); 153 GPIO1_DR = ioremap(ledsource[3]->start, ressize[3]); 154 GPIO1_GDIR = ioremap(ledsource[4]->start, ressize[4]); 155 156 val = readl(IMX6U_CCM_CCGR1); 157 val &= ~(3 << 26); /* 清除以前的设置 */ 158 val |= (3 << 26); /* 设置新值 */ 159 writel(val, IMX6U_CCM_CCGR1); 160 161 /* 设置 GPIO1_IO03 复用功能，将其复用为 GPIO1_IO03 */ 162 writel(5, SW_MUX_GPIO1_IO03); 163 writel(0x10B0, SW_PAD_GPIO1_IO03); 164 165 /* 设置 GPIO1_IO03 为输出功能 */ 166 val = readl(GPIO1_GDIR); 167 val &= ~(1 << 3); /* 清除以前的设置 */ 168 val |= (1 << 3); /* 设置为输出 */ 169 writel(val, GPIO1_GDIR); 170 171 /* 默认关闭 LED1 */ 172 val = readl(GPIO1_DR); 173 val |= (1 << 3) ; 174 writel(val, GPIO1_DR); 175 176 /* 注册字符设备驱动 */ 177 /*1、创建设备号 */ 178 if (leddev.major) { /* 定义了设备号 */ 179 leddev.devid = MKDEV(leddev.major, 0); 180 register_chrdev_region(leddev.devid, LEDDEV_CNT, LEDDEV_NAME); 181 } else { /* 没有定义设备号 */ 182 alloc_chrdev_region(&leddev.devid, 0, LEDDEV_CNT, LEDDEV_NAME); 183 leddev.major = MAJOR(leddev.devid); 184 } 185 186 /* 2、初始化 cdev */ 187 leddev.cdev.owner = THIS_MODULE; 188 cdev_init(&leddev.cdev, &led_fops); 189 190 /* 3、添加一个 cdev */ 191 cdev_add(&leddev.cdev, leddev.devid, LEDDEV_CNT); 192 193 /* 4、创建类 */ 194 leddev.class = class_create(THIS_MODULE, LEDDEV_NAME); 195 if (IS_ERR(leddev.class)) { 196 return PTR_ERR(leddev.class); 197 } 198 199 /* 5、创建设备 */ 200 leddev.device = device_create(leddev.class, NULL, leddev.devid, NULL, LEDDEV_NAME); 201 if (IS_ERR(leddev.device)) { 202 return PTR_ERR(leddev.device); 203 } 204 205 return 0; 206 } 207 208 /* 209 * @description :移除 platform 驱动的时候此函数会执行 210 * @param - dev : platform 设备 211 * @return : 0，成功;其他负值,失败 212 */ 213 static int led_remove(struct platform_device *dev) 214 { 215 iounmap(IMX6U_CCM_CCGR1); 216 iounmap(SW_MUX_GPIO1_IO03); 217 iounmap(SW_PAD_GPIO1_IO03); 218 iounmap(GPIO1_DR); 219 iounmap(GPIO1_GDIR); 220 221 cdev_del(&leddev.cdev); /* 删除 cdev */ 222 unregister_chrdev_region(leddev.devid, LEDDEV_CNT); 223 device_destroy(leddev.class, leddev.devid); 224 class_destroy(leddev.class); 225 return 0; 226 } 227 228 /* platform 驱动结构体 */ 229 static struct platform_driver led_driver = { 230 .driver = { 231 .name = "imx6ul-led", /* 驱动名字，用于和设备匹配 */ 232 }, 233 .probe = led_probe, 234 .remove = led_remove, 235 }; 236 237 /* 238 * @description : 驱动模块加载函数 239 * @param : 无 240 * @return : 无 241 */ 242 static int __init leddriver_init(void) 243 { 244 return platform_driver_register(&led_driver); 245 } 246 247 /* 248 * @description : 驱动模块卸载函数 249 * @param : 无 250 * @return : 无 251 */ 252 static void __exit leddriver_exit(void) 253 { 254 platform_driver_unregister(&led_driver); 255 } 256 257 module_init(leddriver_init); 258 module_exit(leddriver_exit); 259 MODULE_LICENSE("GPL"); 260 MODULE_AUTHOR("zuozhongkai");leddriver.c 文件内容就是按照示例代码 54.2.2.5 的 platform 驱动模板编写的。
注意：这时候没有使用设备树，驱动里初始化时需要从platform设备里获取resource信息，而不是从设备树。
第 34~122 行，传统的字符设备驱动。
第 130~206 行，probe 函数，当设备和驱动匹配以后此函数就会执行，当匹配成功以后会在终端上输出“led driver and device has matched!”这样语句。在 probe 函数里面初始化 LED、注册字符设备驱动。也就是将原来在驱动加载函数里面做的工作全部放到 probe 函数里面完成。
第 213~226 行，remobe 函数，当卸载 platform 驱动的时候此函数就会执行。在此函数里面释放内存、注销字符设备等。也就是将原来驱动卸载函数里面的工作全部都放到 remove 函数中完成。
第 229~235 行，platform_driver 驱动结构体，注意 name 字段为"imx6ul-led"，和我们在leddevice.c 文件里面设置的设备 name 字段一致。
第 242~245 行，驱动模块加载函数，在此函数里面通过 platform_driver_register 向 Linux 内核注册 led_driver 驱动。
第 252~255 行，驱动模块卸载函数，在此函数里面通过 platform_driver_unregister 从 Linux内核卸载 led_driver 驱动。
注意：设备也是采用和驱动类似的加载和卸载的方式。
最后，会在在/sys/bus/platform/devices/和在/sys/bus/platform/drivers/目录下生成对应的文件，文件名就是匹配时取的name，不过注意，这里面并不是常规dev里的那个设备文件，而是用来进行platform匹配用的。
同时，之前那个dev目录下还是会生成设备节点，还是驱动程序里取的那个名字，这是用来让用户层操作的。
二者并不矛盾。不要搞混了。
看一下linux里的这两个目录
从这里就能看出来，设备和驱动并不是一一对应的，而是互相分离的，设备有没有对应的驱动？匹配到就有，没匹配到就没有。
设备树下的platform驱动
上面我们详细的讲解了 Linux 下的驱动分离与分层，以及总线、设备和驱动这样的驱动框架。基于总线、设备和驱动这样的驱动框架，Linux 内核提出来 platform 这个虚拟总线，相应的也有platform 设备和 platform 驱动。上一章我们讲解了传统的、未采用设备树的 platform 设备和驱动编写方法。最新的 Linux 内核已经支持了设备树，因此在设备树下如何编写 platform驱动就显得尤为重要，本章我们就来学习一下如何在设备树下编写 platform 驱动。
platform 驱动框架分为总线、设备和驱动，其中总线不需要我们这些驱动程序员去管理，这个是 Linux 内核提供的，我们在编写驱动的时候只要关注于设备和驱动的具体实现即可。在没有设备树的 Linux 内核下，我们需要分别编写并注册 platform_device 和 platform_driver，分别代表设备和驱动。在使用设备树的时候，设备的描述被放到了设备树中，因此 platform_device 就不需要我们去编写了，我们只需要实现 platform_driver 即可。在编写基于设备树的 platform 驱动的时候我们需要注意一下几点：
1、在设备树中创建设备节点
毫无疑问，肯定要先在设备树中创建设备节点来描述设备信息，重点是要设置好 compatible属性的值，因为 platform 总线需要通过设备节点的 compatible 属性值来匹配驱动！这点要切记。
比如，我们可以编写如下所示的设备节点来描述我们本章实验要用到的 LED 这个设备：
示例 55.1.1 中的 gpioled 节点其实就是 45.4.1.2 小节中创建的 gpioled 设备节点，我们可以直接拿过来用。注意第 4 行的 compatible 属性值为“atkalpha-gpioled”，因此一会在编写 platform驱动的时候 of_match_table 属性表中要有“atkalpha-gpioled”。
2、编写 platform 驱动的时候要注意兼容属性
上一章已经详细的讲解过了，在使用设备树的时候 platform 驱动会通过 of_match_table 来保存兼容性值，也就是表明此驱动兼容哪些设备。所以，of_match_table 将会尤为重要，比如本例程的 platform 驱动中 platform_driver 就可以按照如下所示设置：
第 1~4 行，of_device_id 表，也就是驱动的兼容表，是一个数组，每个数组元素为 of_device_id类型。每个数组元素都是一个兼容属性，表示兼容的设备，一个驱动可以跟多个设备匹配。这里我们仅仅匹配了一个设备，那就是 55.1.1 中创建的 gpioled 这个设备。第 2 行的 compatible 值为“atkalpha-gpioled”，驱动中的 compatible 属性和设备中的 compatible 属性相匹配，因此驱动中对应的 probe 函数就会执行。注意第 3 行是一个空元素，在编写 of_device_id 的时候最后一个元素一定要为空！
第 6 行，通过 MODULE_DEVICE_TABLE 声明一下 leds_of_match 这个设备匹配表。
第 11 行，设置 platform_driver 中的 of_match_table 匹配表为上面创建的 leds_of_match，至此我们就设置好了 platform 驱动的匹配表了。
3、编写 platform 驱动
基于设备树的 platform 驱动和上一章无设备树的 platform 驱动基本一样，都是当驱动和设备匹配成功以后就会执行 probe 函数。我们需要在 probe 函数里面执行字符设备驱动那一套，当注销驱动模块的时候 remove 函数就会执行，都是大同小异的。
注意，不需要写platform_device设备了。
本章实验我们编写基于设备树的 platform 驱动，所以需要在设备树中添加设备节点，然后我们只需要编写platform 驱动即可。
修改设备树文件
首先修改设备树文件，加上我们需要的设备信息，本章我们就使用到一个 LED 灯，因此可以直接使用gpioled 子节点即可，不需要再重复添加。
platform 驱动程序编写
设备已经准备好了，接下来就要编写相应的 platform 驱动了，新建名为“18_dtsplatform”的文件夹，然后在 18_dtsplatform 文件夹里面创建 vscode 工程，工作区命名为“dtsplatform”。
新建名为 leddriver.c 的驱动文件，在 leddriver.c 中输入如下所示内容：
示例代码 55.3.2.1 leddriver.c 文件代码段 1 #include <linux/types.h> 2 #include <linux/kernel.h> 3 #include <linux/delay.h> 4 #include <linux/ide.h> 5 #include <linux/init.h> 6 #include <linux/module.h> 7 #include <linux/errno.h> 8 #include <linux/gpio.h> 9 #include <linux/cdev.h> 10 #include <linux/device.h> 11 #include <linux/of_gpio.h> 12 #include <linux/semaphore.h> 13 #include <linux/timer.h> 14 #include <linux/irq.h> 15 #include <linux/wait.h> 16 #include <linux/poll.h> 17 #include <linux/fs.h> 18 #include <linux/fcntl.h> 19 #include <linux/platform_device.h> 20 #include <asm/mach/map.h> 21 #include <asm/uaccess.h> 22 #include <asm/io.h> 23 /*************************************************************** 24 Copyright © ALIENTEK Co., Ltd. 1998-2029. All rights reserved. 25 文件名 : leddriver.c 26 作者 : 左忠凯 27 版本 : V1.0 28 描述 : 设备树下的 platform 驱动 29 其他 : 无 30 论坛 : www.openedv.com 31 日志 : 初版 V1.0 2019/8/13 左忠凯创建 32 ***************************************************************/ 33 #define LEDDEV_CNT 1 /* 设备号长度 */ 34 #define LEDDEV_NAME "dtsplatled" /* 设备名字 */ 35 #define LEDOFF 0 36 #define LEDON 1 37 38 /* leddev 设备结构体 */ 39 struct leddev_dev{ 40 dev_t devid; /* 设备号 */ 41 struct cdev cdev; /* cdev */ 42 struct class *class; /* 类 */ 43 struct device *device; /* 设备 */ 44 int major; /* 主设备号 */ 45 struct device_node *node; /* LED 设备节点 */ 46 int led0; /* LED 灯 GPIO 标号 */ 47 }; 48 49 struct leddev_dev leddev; /* led 设备 */ 50 51 /* 52 * @description : LED 打开/关闭 53 * @param - sta : LEDON(0) 打开 LED，LEDOFF(1) 关闭 LED 54 * @return : 无 55 */ 56 void led0_switch(u8 sta) 57 { 58 if (sta == LEDON ) 59 gpio_set_value(leddev.led0, 0); 60 else if (sta == LEDOFF) 61 gpio_set_value(leddev.led0, 1); 62 } 63 64 /* 65 * @description : 打开设备 66 * @param – inode : 传递给驱动的 inode 67 * @param - filp : 设备文件，file 结构体有个叫做 private_data 的成员变量 68 * 一般在 open 的时候将 private_data 指向设备结构体。 69 * @return : 0 成功;其他 失败 70 */ 71 static int led_open(struct inode *inode, struct file *filp) 72 { 73 filp->private_data = &leddev; /* 设置私有数据 */ 74 return 0; 75 } 76 77 /* 78 * @description : 向设备写数据 79 * @param - filp : 设备文件，表示打开的文件描述符 80 * @param - buf : 要写给设备写入的数据 81 * @param - cnt : 要写入的数据长度 82 * @param – offt : 相对于文件首地址的偏移 83 * @return : 写入的字节数，如果为负值，表示写入失败 84 */ 85 static ssize_t led_write(struct file *filp, const char __user *buf, size_t cnt, loff_t *offt) 86 { 87 int retvalue; 88 unsigned char databuf[2]; 89 unsigned char ledstat; 90 91 retvalue = copy_from_user(databuf, buf, cnt); 92 if(retvalue < 0) { 93 94 printk("kernel write failed!\r\n"); 95 return -EFAULT; 96 } 97 98 ledstat = databuf[0]; 99 if (ledstat == LEDON) { 100 led0_switch(LEDON); 101 } else if (ledstat == LEDOFF) { 102 led0_switch(LEDOFF); 103 } 104 return 0; 105 } 106 107 /* 设备操作函数 */ 108 static struct file_operations led_fops = { 109 .owner = THIS_MODULE, 110 .open = led_open, 111 .write = led_write, 112 }; 113 114 /* 115 * @description : flatform 驱动的 probe 函数，当驱动与 116 * 设备匹配以后此函数就会执行 117 * @param - dev : platform 设备 118 * @return : 0，成功;其他负值,失败 119 */ 120 static int led_probe(struct platform_device *dev) 121 { 122 printk("led driver and device was matched!\r\n"); 123 /* 1、设置设备号 */ 124 if (leddev.major) { 125 leddev.devid = MKDEV(leddev.major, 0); 126 register_chrdev_region(leddev.devid, LEDDEV_CNT, LEDDEV_NAME); 127 } else { 128 alloc_chrdev_region(&leddev.devid, 0, LEDDEV_CNT, LEDDEV_NAME); 129 leddev.major = MAJOR(leddev.devid); 130 } 131 132 /* 2、注册设备 */ 133 cdev_init(&leddev.cdev, &led_fops); 134 cdev_add(&leddev.cdev, leddev.devid, LEDDEV_CNT); 135 136 /* 3、创建类 */ 137 leddev.class = class_create(THIS_MODULE, LEDDEV_NAME); 138 if (IS_ERR(leddev.class)) { 139 return PTR_ERR(leddev.class); 140 } 141 142 /* 4、创建设备 */ 143 leddev.device = device_create(leddev.class, NULL, leddev.devid, NULL, LEDDEV_NAME); 144 if (IS_ERR(leddev.device)) { 145 return PTR_ERR(leddev.device); 146 } 147 148 /* 5、初始化 IO */ 149 leddev.node = of_find_node_by_path("/gpioled"); 150 if (leddev.node == NULL){ 151 printk("gpioled node nost find!\r\n"); 152 return -EINVAL; 153 } 154 155 leddev.led0 = of_get_named_gpio(leddev.node, "led-gpio", 0); 156 if (leddev.led0 < 0) { 157 printk("can't get led-gpio\r\n"); 158 return -EINVAL; 159 } 160 161 gpio_request(leddev.led0, "led0"); 162 gpio_direction_output(leddev.led0, 1); /*设置为输出，默认高电平 */ 163 return 0; 164 } 165 166 /* 167 * @description : remove 函数，移除 platform 驱动的时候此函数会执行 168 * @param - dev : platform 设备 169 * @return : 0，成功;其他负值,失败 170 */ 171 static int led_remove(struct platform_device *dev) 172 { 173 gpio_set_value(leddev.led0, 1); /* 卸载驱动的时候关闭 LED */ 174 175 cdev_del(&leddev.cdev); /* 删除 cdev */ 176 unregister_chrdev_region(leddev.devid, LEDDEV_CNT); 177 device_destroy(leddev.class, leddev.devid); 178 class_destroy(leddev.class); 179 return 0; 180 } 181 182 /* 匹配列表 */ 183 static const struct of_device_id led_of_match[] = { 184 { .compatible = "atkalpha-gpioled" }, 185 { /* Sentinel */ } 186 }; 187 188 /* platform 驱动结构体 */ 189 static struct platform_driver led_driver = { 190 .driver = { 191 .name = "imx6ul-led", /* 驱动名字，用于和设备匹配 */ 192 .of_match_table = led_of_match, /* 设备树匹配表 */ 193 }, 194 .probe = led_probe, 195 .remove = led_remove, 196 }; 197 198 /* 199 * @description : 驱动模块加载函数 200 * @param : 无 201 * @return : 无 202 */ 203 static int __init leddriver_init(void) 204 { 205 return platform_driver_register(&led_driver); 206 } 207 208 /* 209 * @description : 驱动模块卸载函数 210 * @param : 无 211 * @return : 无 212 */ 213 static void __exit leddriver_exit(void) 214 { 215 platform_driver_unregister(&led_driver); 216 } 217 218 module_init(leddriver_init); 219 module_exit(leddriver_exit); 220 MODULE_LICENSE("GPL"); 221 MODULE_AUTHOR("zuozhongkai")第 33~112 行，传统的字符设备驱动，没什么要说的。
第 120~164 行，platform 驱动的 probe 函数，当设备树中的设备节点与驱动之间匹配成功以后此函数就会执行，原来在驱动加载函数里面做的工作现在全部放到 probe 函数里面完成。
第 171~180 行，remobe 函数，当卸载 platform 驱动的时候此函数就会执行。在此函数里面释放内存、注销字符设备等，也就是将原来驱动卸载函数里面的工作全部都放到 remove 函数中完成。
第 183~186 行，匹配表，描述了此驱动都和什么样的设备匹配，第 184 行添加了一条值为"atkalpha-gpioled"的 compatible 属性值，当设备树中某个设备节点的 compatible 属性值也为“atkalpha-gpioled”的时候就会与此驱动匹配。
第 189~196 行，platform_driver 驱动结构体，191 行设置这个 platform 驱动的名字为“imx6ulled”，因此，当驱动加载成功以后就会在/sys/bus/platform/drivers/目录下存在一个名为“imx6uled”的文件。 第 192 行设置of_match_table 为上面的 led_of_match。
第 203~206 行，驱动模块加载函数，在此函数里面通过 platform_driver_register 向 Linux 内核注册 led_driver 驱动。
第 213~216 行，驱动模块卸载函数，在此函数里面通过 platform_driver_unregister 从 Linux内核卸载 led_driver 驱动。
驱动模块加载完成以后到/sys/bus/platform/drivers/目录下查看驱动是否存在，我们在leddriver.c 中设置 led_driver (platform_driver 类型)的 name 字段为“imx6ul-led”，因此会在/sys/bus/platform/drivers/目录下存在名为“imx6ul-led”这个文件，结果如图 55.4.2.1 所示：
同理，在/sys/bus/platform/devices/目录下也存在 led 的设备文件，也就是设备树中 gpioled 这个节点，如图55.4.2.2 所示：
注意，这里二者的名字并不一致，因为不是通过name来匹配的，而是通过兼容性来匹配的。这两种也是比较常用的匹配方式。
驱动和模块都存在，当驱动和设备匹配成功以后就会输出如图 55.4.2.3 所示一行语句：
更多待补充。
补充说明
platform主要是Linux内核用来匹配设备和驱动的一个框架？框架内对字符设备、块设备、网络设备等驱动没啥影响，这些驱动该怎么实现还是怎么实现，只是在这些驱动实现上套了一层框架。所以要注意，platform并不仅仅局限于字符设备驱动。
参考：如何理解驱动程序、设备树、platform、device、driver之间的关系_设备树与驱动的关系-CSDN博客
设备树和platform是什么关系？设备树会在系统启动时由内核解析并注册为platform_device。
首先要理解驱动程序模型是分离的，分层的。
所谓分离是指：硬件的资源信息（地址、中断、DMA等），与软件驱动代码是分离的。硬件的资源信息是通过设备树来描述的，设备树由内核在启动时解析并注册为platform_device。
所谓分层是指：分上下两层，device和driver都注册、挂载在bus（总线）下面。
设备device与设备树device tree相关。满足一定条件的compatible时(这些特殊的compatilbe属性为: “simple-bus”,“simple-mfd”,“isa”,"arm,amba-bus ")，设备树被转换并注册成platform_device。
驱动driver代码要重点理解probe函数。因为内核启动时就已经注册device，所以手动insmod是注册driver。也就是说，在利用设备树时，是先注册device，后注册driver。当driver与device的compatible相匹配时，会调用probe。
device与driver相匹配，是通过在drivers/base/dd.c中driver_attach函数来完成。一旦match成功，则调用driver里的probe函数。
对于传统写法，match函数是直接比较name。对于使用设备树的情况下，match函数通过 platform_driver -> driver -> of_match_table -> compatile 来与设备节点做匹配。
无设备树： 使用 xxx_driver.driver.name 进行设备匹配
有设备树： 使用 xxx_driver.driver.of_match_table 进行设备匹配
疑惑：这里的platform驱动和之前没有用platform时候有啥区别？之前没有platform的时候也能读取设备树呀。
网上有一些说法：
字符设备驱动三种开发方式对比
字符设备驱动三种开发方式对比_设备驱动模型和字符设备驱动区别-CSDN博客
驱动编写的三种方式：传统/总线/设备树 - 嵌入式小白— - 博客园 (cnblogs.com)
应该是四种方式吧？
最传统的方式；
改进方式+设备树；
platform_device+platform_driver；
platform_driver+设备树；
没有platform应该也能写驱动吧？
1677
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
