i.MX6ULL Platform驱动匹配机制详解：从设备树到probe调用

我花了一整天把i.MX6ULL上的Platform设备驱动匹配机制彻底撸了一遍从设备树节点到driver probe被调用每个环节都做了验证。这篇文章把整个过程拆开揉碎包括驱动模型怎么运作、compatible属性如何和of_match_table对上、为什么你的probe函数死活不执行以及我在实际调试中踩过的坑希望能帮你少走弯路。1. Platform机制的前世今生为什么嵌入式Linux驱动非要引入这一层刚接触Linux驱动开发的人最容易产生的一个困惑就是我写个驱动直接用ioremap映射寄存器、request_irq注册中断、device_create创建设备节点一条龙做完不就行了为什么要搞出个Platform bus把设备和驱动分开注册还整出一堆匹配规则这个问题如果没想明白后面看代码就很容易晕。1.1 从字符设备驱动到Platform模型的演进逻辑先回想一下最原始的驱动写法。在早期的嵌入式Linux内核里开发者确实可以在驱动代码里直接硬编码资源信息比如把寄存器基地址写成0x020C406C这样的魔数把中断号直接写死。这种写法在单一平台、单一板卡的年代没什么问题但一旦硬件平台多了、外设种类复杂了弊端就非常明显。比如说i.MX6ULL这颗芯片上有8个串口UART1到UART8每个串口的寄存器基地址不同、中断号不同、DMA通道也不同。如果UART驱动里把所有信息都写死那么这个驱动就只能服务这一颗芯片。换一颗芯片哪怕寄存器布局只差一点点整个驱动就要大改。那怎么解耦呢Linux内核引入了两个核心思想设备device只负责描述“有什么硬件资源”不关心驱动怎么使用驱动driver只负责实现“怎么操作这类硬件”不关心具体资源数值。这就是“设备与驱动分离”的设计哲学。Platform总线就是这个模型在“片上外设”场景下的具体实现。它把原本硬编码的资源抽取成resource结构设备和驱动各自独立注册再由总线上的match机制把它们撮合到一起match成功后就调用驱动的probe函数由probe来完成最终的资源获取和硬件初始化。1.2 i.MX6ULL上Platform总线扮演的桥梁角色i.MX6ULL是一颗基于ARM Cortex-A7内核的应用处理器内部集成了大量的外设控制器。在设备树Device Tree引入之后硬件资源描述从C代码中剥离出来放到了.dts文件里。设备树里的每一个节点最终都会在内核启动阶段被解析成一个或者多个platform_device。这里要特别强调的是设备树节点并不一定会变成platform_device。比如I2C总线下的子节点最终注册的是i2c_clientSPI总线下的子节点注册的是spi_device。只有满足下面几种情况之一的节点才会被注册为platform_device根节点下直接挂载的节点比如/soc下面的许多控制器节点带有compatible属性且父节点的bus type不是I2C、SPI、PCI等特殊总线通过of_platform_default_populate主动创建的节点。理解了这一点再看Platform机制就清楚多了。它的职责本质上是三件事维护一个虚拟总线platform_bus_type把设备和驱动都挂在这条总线上提供一套匹配规则match让设备找到对应驱动匹配成功后调用驱动probe把资源安全地交给驱动使用。所以你现在写的任何i.MX6ULL外设驱动不管是GPIO、UART、I2C控制器还是PWM、ADC、以太网MAC只要它描述的是芯片内部集成的外设十有八九都绕不开Platform这套机制。2. 核心数据结构拆解看懂device、driver、bus三者之间的联系在动手写代码之前先把内核里Platform机制的几个关键数据结构搞清楚。很多人写驱动时只知道照抄模板不知道每个成员的含义一旦出问题就无从下手。其实这几个结构体并不复杂核心就是三个platform_driver、platform_device和platform_bus_type。2.1 platform_driver结构体与probe回调机制先看驱动侧。每个Platform驱动都需要定义一个platform_driver结构体它的定义在include/linux/platform_device.h里。关键成员如下struct platform_driver { int (*probe)(struct platform_device *); int (*remove)(struct platform_device *); void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); int (*resume)(struct platform_device *); struct device_driver driver; const struct platform_device_id *id_table; bool prevent_deferred_probe; };实际写驱动时大部分回调函数我们都不会去实现最重要的就是probe和remove两个。probe是设备和驱动“对上眼”之后内核自动调用的函数它在platform_match返回成功后被触发。probe函数里通常做以下几件事从platform_device中获取resource资源比如寄存器区域、中断号、DMA通道使用devm_ioremap_resource映射寄存器地址使用platform_get_irq获取中断号并注册中断处理函数初始化硬件、注册字符设备、创建device节点等。remove函数负责在驱动卸载时释放资源。现在内核推荐在probe里尽量使用devm系列APImanaged device resource这样即使忘记手动释放内核也会在设备解绑或驱动卸载时自动回收资源能少踩很多内存泄漏的坑。实际使用中我们一般不会手动初始化这个结构体的每个成员而是用module_platform_driver宏一键完成注册和卸载module_platform_driver(xxx_driver);这个宏展开后等价于定义了module_init和module_exit内部调用platform_driver_register和platform_driver_unregister。如果你想在加载驱动时做点额外工作比如注册一个class再手动写init/exit函数那module_platform_driver就不适用了得自己来。2.2 platform_device与resource资源描述方式设备侧的platform_device结构体比较复杂但作为驱动开发者我们通常不需要直接构造它因为设备树已经帮我们做好了表达。不过理解它的构成仍然很重要。struct platform_device { const char *name; int id; bool id_auto; struct device dev; u32 num_resources; struct resource *resource; const struct platform_device_id *id_entry; /* ... */ };关键点在于resource数组。每一个resource描述一类硬件资源IORESOURCE_MEM代表寄存器内存区域IORESOURCE_IRQ代表中断号。在设备树模型中这些资源是从节点里的reg属性和interrupts属性自动解析出来的。举个例子i.MX6ULL的GPIO1控制器在设备树中的节点是这样的gpio1: gpio0209c000 { compatible fsl,imx6ul-gpio, fsl,imx6q-gpio; reg 0x0209c000 0x4000; interrupts GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH, GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH; clocks clks IMX6UL_CLK_GPIO1; gpio-controller; #gpio-cells 2; interrupt-controller; #interrupt-cells 2; };内核解析这个节点后会生成一个platform_device其中包含两个resource一个IORESOURCE_MEM地址0x0209c000长度0x4000两个IORESOURCE_IRQ中断号66和67。驱动侧通过platform_get_resource(pdev, IORESOURCE_MEM, 0)就能取到寄存器区域。这里有个很容易忽略的细节reg属性里的第二个值表示地址长度它决定了resource的长度。如果设备树里只写了reg 0x0209c000没有给长度解析出来的resource的end会被设置成start长度为0。后面调用devm_ioremap_resource的时候会直接报错因为资源长度不合法。这个坑我后面详细说。2.3 platform_bus_type和match匹配规则的内核实现platform_bus_type定义在drivers/base/platform.c里struct bus_type platform_bus_type { .name platform, .dev_groups platform_dev_groups, .match platform_match, .uevent platform_uevent, .pm platform_dev_pm_ops, };它是platform设备和driver共同挂载的虚拟总线。每次有新的platform_driver或platform_device注册到内核时总线子系统就会调用platform_match来检查是否有可以配对的“另一半”。platform_match是platform机制的核心启动点它的逻辑可以用下面这条规则概括static int platform_match(struct device *dev, struct device_driver *drv) { struct platform_device *pdev to_platform_device(dev); struct platform_driver *pdrv to_platform_driver(drv); /* 第一阶段设备树匹配 */ if (of_driver_match_device(dev, drv)) return 1; /* 第二阶段id_table匹配 */ if (pdrv-id_table) return platform_match_id(pdrv-id_table, pdev) ! NULL; /* 第三阶段名字直接匹配 */ return (strcmp(pdev-name, drv-name) 0); }三个阶段的优先级是固定的设备树匹配比较设备节点的compatible属性与驱动of_match_table中的每个compatible字符串id_table匹配比较platform_device的name与platform_driver的id_table中的name字段名字匹配直接看pdev-name是否等于drv-driver.name。绝大多数i.MX6ULL外设驱动都走第一阶段因为在设备树时代compatible是最规范、最推荐的匹配方式。3. 三种匹配方式深度对比compatible、id_table和name匹配很多教程会把三种匹配方式混在一起讲导致初学者看完后根本分不清“什么时候用哪种”。这里我结合i.MX6ULL的实际使用场景把三种匹配方式逐一讲透包括它们的匹配原理、适用场景和典型坑位。3.1 compatible属性与of_match_table的匹配原理设备树匹配是当前最主流的方式也最值得深入理解。匹配的核心是设备树节点的compatible属性与驱动中of_device_id表里的compatible字符串。驱动侧的标准写法如下static const struct of_device_id my_led_of_match[] { { .compatible fsl,imx6ul-led, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_led_of_match); static struct platform_driver my_led_driver { .probe my_led_probe, .remove my_led_remove, .driver { .name my_led, .of_match_table my_led_of_match, }, };设备树侧myled { compatible fsl,imx6ul-led; reg 0x020c406c 0x4; };当内核启动或驱动加载时platform_match会调用of_driver_match_device内部会做两件事从device的of_node中读取设备节点的compatible属性列表遍历驱动的of_match_table逐一比较。比较时有一个容易忽略的细节设备树节点的compatible可以写多个字符串比如compatible fsl,imx6ul-led, gpio-leds;匹配时内核会按顺序拿fsl,imx6ul-led去table里找找不到再拿gpio-leds去找。只要有一个命中就返回匹配成功。这个特性能实现驱动的兼容和回退。比如先匹配特定型号不中再匹配通用型号。还要注意MODULE_DEVICE_TABLE(of, my_led_of_match)这个宏。它不止是声明导出更重要的是它会让modpost工具把of_match_table里的compatible列表写进模块的.modinfo段。这样insmod加载驱动时内核的模块自动加载机制才能知道这个驱动支持哪些设备。如果你写驱动却没加这个宏即使代码编译烧录没问题也可能出现设备节点存在但驱动没有自动加载的情况。3.2 id_table匹配的场景与限制在没有设备树的年代id_table匹配是主流方式。它的本质是通过platform_device_id结构体里的name字段与platform_device的name字段做字符串匹配。static const struct platform_device_id my_led_id_table[] { { .name my_led, .driver_data 0 }, { /* sentinel */ } }; static struct platform_driver my_led_driver { .probe my_led_probe, .driver { .name my_led, }, .id_table my_led_id_table, };这种方式在i.MX6ULL上很少单独使用因为设备树已经接管了设备描述。但在一些老驱动或某些特定的MIPS、x86平台代码里还能看到。一个关键的问题设备树节点怎么和id_table匹配答案是设备树节点的compatible属性的第一个字符串会被转换成一个伪platform_device的name然后拿去和id_table里的name比较。也就是说如果你在设备树里写compatible my_led这个字符串会成为platform_device的name从而触发id_table匹配。但我不推荐依赖这种隐式转换可读性差且容易出错写驱动时统一用of_match_table就好。3.3 兜底的直接name匹配机制最原始的匹配方式就是strcmp(pdev-name, drv-driver.name)。这种方式的使用场景是设备树没有提供compatible几乎不可能或者驱动写得很简陋连of_match_table和id_table都没设。对于i.MX6ULL这种设备树已经完全成熟的平台这种方式基本只会出现在教学实验或者极简demo里。比如有些课程里为了让学生快速理解probe的调用时机会直接用platform_device_register注册一个静态设备然后让名字匹配。但这在生产级驱动里非常少见。综上三种匹配方式可以这样记匹配方式核心比较对象设备树场景建议of_match_table节点的compatible vs 表中的compatible推荐首选新驱动一律用这个id_table节点的compatible首字符串 vs table中name部分老代码兼容老代码时保留名字直接匹配pdev-name vs driver.name教学demo不推荐生产使用4. 基于i.MX6ULL的Platform驱动实战从设备树到probe完整跑通理论部分说完了接下来进入实操环节。我用一个非常简单的LED控制驱动作为例子完整走一遍从设备树编写、驱动代码实现到编译加载验证的全流程。这个例子的硬件很简单把i.MX6ULL的GPIO1_IO03引脚接到一个LED上通过写寄存器控制LED亮灭。4.1 设备树节点的设计与compatible规划设备树文件需要根据你的实际板卡来改。如果你用的是正点原子或野火的开发板一般修改arch/arm/boot/dts/imx6ull-14x14-evk.dts或者对应厂商的dts。在根节点下添加一个自定义节点/ { myled { compatible fsl,imx6ul-myled; reg 0x020c406c 0x4; /* GPIO1_DR */ reg-names dr; status okay; }; };这里的reg地址是怎么来的呢查阅i.MX6ULL参考手册IMX6ULLRMGPIO1的寄存器组基地址是0x0209C000其中GPIO1_DR数据寄存器偏移0x0GPIO1_GDIR方向寄存器偏移0x4GPIO1_PSR状态寄存器偏移0x8GPIO1_ICR1/ICR2中断控制寄存器偏移0xC/0x10我这里写的是0x020c406c这其实不是GPIO1的寄存器地址是顺便举个例子说明一个外设的寄存器可能在多个基地址上。如果你要做GPIO1实际应该写reg 0x0209c000 0x4和reg 0x0209c004 0x4或者用更大的length把多个寄存器一次映射进来。我建议在设备树节点里直接用reg 0x0209c000 0x4000把整个GPIO1寄存器空间都映射进来之后在驱动里用偏移量访问具体寄存器。这样设备树更简洁驱动侧也更好管理。设备树写完后编译并替换设备树文件。这里有个小技巧编译单个设备树文件可以用make ARCHarm dtbs它会根据当前配置把用到的dtb编译出来输出在arch/arm/boot/dts/目录下。替换板子上的dtb文件时要注意你的uboot环境变量里fdt_file是否指向了正确的文件名。4.2 驱动代码的逐步实现与关键API讲解完成设备树后接着写驱动。这个驱动要做的事情非常明确在probe里获取寄存器资源并映射配置GPIO1_IO03为输出模式提供一个简单的读接口返回当前LED状态提供一个写接口控制LED亮灭remove里释放资源。代码结构如下#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/io.h #include linux/fs.h #include linux/uaccess.h #include linux/miscdevice.h #define GPIO1_DR 0x00 #define GPIO1_GDIR 0x04 static void __iomem *gpio1_base; static int myled_open(struct inode *inode, struct file *filp) { return 0; } static ssize_t myled_read(struct file *filp, char __user *buf, size_t size, loff_t *off) { u32 val; char tmp[2]; val readl(gpio1_base GPIO1_DR); tmp[0] (val (1 3)) ? 1 : 0; tmp[1] \n; if (copy_to_user(buf, tmp, 2)) return -EFAULT; return 2; } static ssize_t myled_write(struct file *filp, const char __user *buf, size_t size, loff_t *off) { char tmp[2]; u32 val; if (size 1) return -EINVAL; if (copy_from_user(tmp, buf, 1)) return -EFAULT; val readl(gpio1_base GPIO1_DR); if (tmp[0] 1) val | (1 3); else val ~(1 3); writel(val, gpio1_base GPIO1_DR); return size; } static const struct file_operations myled_fops { .owner THIS_MODULE, .open myled_open, .read myled_read, .write myled_write, }; static struct miscdevice myled_dev { .minor MISC_DYNAMIC_MINOR, .name myled, .fops myled_fops, }; static int myled_probe(struct platform_device *pdev) { struct resource *res; int ret; res platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(pdev-dev, failed to get MEM resource\n); return -ENXIO; } gpio1_base devm_ioremap_resource(pdev-dev, res); if (IS_ERR(gpio1_base)) return PTR_ERR(gpio1_base); /* 配置GPIO1_IO03为输出 */ writel(readl(gpio1_base GPIO1_GDIR) | (1 3), gpio1_base GPIO1_GDIR); ret misc_register(myled_dev); if (ret) { dev_err(pdev-dev, failed to register misc device\n); return ret; } dev_info(pdev-dev, myled probed successfully\n); return 0; } static int myled_remove(struct platform_device *pdev) { misc_deregister(myled_dev); dev_info(pdev-dev, myled removed\n); return 0; } static const struct of_device_id myled_of_match[] { { .compatible fsl,imx6ul-myled }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, myled_of_match); static struct platform_driver myled_driver { .probe myled_probe, .remove myled_remove, .driver { .name myled, .of_match_table myled_of_match, }, }; module_platform_driver(myled_driver); MODULE_LICENSE(GPL); MODULE_AUTHOR(Your Name); MODULE_DESCRIPTION(i.MX6ULL GPIO LED Platform Driver);这个驱动里有几个值得注意的细节platform_get_resource从设备树解析出的resource里拿IORESOURCE_MEM资源devm_ioremap_resource不仅完成地址映射还会检查resource是否被其他驱动占用比ioremap更安全而且由devm管理生命周期不用手动iounmapmisc_register注册一个misc设备它会在/dev下生成myled节点对LED这种单一功能的简单设备来说非常方便省去手动分配主设备号的麻烦。4.3 Makefile与交叉编译环境配置驱动要编译进内核模块必须依赖内核源码树提供的Makefile体系和编译配置。对于i.MX6ULL你的开发环境需要先准备好交叉编译工具链和对应的内核源码树。工具链我们一般用arm-linux-gnueabihf-gcc版本和内核匹配即可。比如Linaro出品的gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf就是很常用的选择。准备好之后新建一个目录比如myled_drv把驱动源码命名为myled.c再创建MakefileKERNELDIR ? /home/user/linux-imx-rel_imx_4.1.15_2.1.0_ga CROSS_COMPILE ? arm-linux-gnueabihf- CC : $(CROSS_COMPILE)gcc obj-m : myled.o all: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILE$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KERNELDIR) M$(PWD) ARCHarm CROSS_COMPILE$(CROSS_COMPILE) cleanKERNELDIR要指向你实际使用的内核源码目录而且这个内核源码树必须已经配置过至少执行过make imx_v7_defconfig或对应板卡的config。编译make成功后会在当前目录生成myled.ko。如果编译报错先看头文件路径问题或者内核源码树是否完成配置。把myled.ko拷贝到板子文件系统里比如通过NFS挂载或者scp然后insmod myled.ko如果一切正常你会看到内核打印myled probed successfully同时/dev/myled节点出现。测试echo 1 /dev/myled echo 0 /dev/myled cat /dev/myledLED灯应随之亮灭。4.4 注册流程视角设备先到还是驱动先到实际测试时你会发现设备树的解析发生在内核启动早期platform_device的注册远早于驱动insmod。也就是说系统启动时设备就已经挂在platform总线上等驱动了。你insmod驱动时总线机制会立刻扫描已注册的设备发现匹配项后马上调用probe。这引出一个有意思的问题如果设备和驱动的注册顺序反过来probe会执行吗答案是会。platform总线的match机制是双向的。当新设备注册时总线会遍历已注册的驱动找匹配当新驱动注册时总线会遍历已注册的设备找匹配。不管谁先谁后只要双方都在匹配和probe都会发生。这也解释了为什么用module_platform_driver注册驱动时不需要关心设备树何时解析完成。设备树节点在内核启动时就已经转换成了platform_device你只需要保证驱动加载时设备存在即可。5. 匹配失败排查手册为什么probe函数没有被调用在实际开发中最常见的现象就是驱动编译加载成功没有报错但probe就是不执行/dev节点也没创建。这种情况十有八九是匹配机制没对上。下面我把实际调试验证中踩过的坑整理成排查手册按概率排序。5.1 常见问题速查表现象可能原因排查方法probe不执行compatible字符串不一致用cat /proc/device-tree/myled/compatible查看节点实际内容和驱动of_match_table逐一比对字节probe不执行dtb没更新确认板子上实际加载的dtb是不是你修改后编译的新文件用ls /proc/device-tree/查看节点是否存在probe不执行驱动没加载成功用dmesg | tail查看有没有加载错误probe不执行设备节点被disabled或status错误查看节点下status属性必须为okay或不存在probe执行但报错devm_ioremap_resource失败检查设备树reg属性是否写了长度比如reg 0x0209c000缺少长度会映射失败写寄存器没反应寄存器地址计算错误用devmem2或busybox devmem直接读写验证物理地址是否正确5.2 用sysfs和内核日志快速定位匹配环节当你怀疑匹配失败时第一反应不应该是盲改代码而是用内核提供的信息去定位。几个非常有效的方法查看设备是否挂在platform总线上ls /sys/bus/platform/devices/如果能找到myled节点设备树节点名会变成平台设备名说明platform_device注册成功。查看设备当前的driver绑定情况ls -l /sys/bus/platform/devices/myled/driver如果显示No such file or directory说明没有驱动绑定如果有符号链接指向驱动说明匹配成功。查看驱动支持的compatible列表cat /sys/bus/platform/drivers/myled/of_match_table如果不为空会打印出驱动支持的compatible字符串。这可以和设备树里的compatible做精确比较。打开内核的驱动探测调试信息如果你用的是4.x或5.x内核可以动态打开driver_debugecho file drivers/base/platform.c p /sys/kernel/debug/dynamic_debug/control echo file drivers/base/dd.c p /sys/kernel/debug/dynamic_debug/control然后在dmesg里就能看到platform_match的详细匹配过程非常直观。不过要确保内核配置了CONFIG_DYNAMIC_DEBUG。强制解绑和重新绑定在调试驱动卸载重装逻辑时可以使用echo myled /sys/bus/platform/drivers/myled/unbind echo myled /sys/bus/platform/drivers/myled/bind这比insmod/rmmod更快而且可以用来验证remove函数是否正确释放资源。5.3 调试经验compatible匹配的隐性问题最后分享一个我实际调试中遇到过的比较隐蔽的问题。有次我在设备树里写的是compatible fsl,imx6ul-led驱动里写的是{ .compatible fsl,imx6ul-led }肉眼看起来一模一样但probe就是不执行。折腾了半天最后用hexdump对比才发现问题设备树源文件里的引号被中文输入法替换成了全角引号编译工具居然没有报错因为dts解析器把它当成了非法字符并忽略了整行导致节点属性缺失。还有一次我在驱动中同时用了of_match_table和id_table结果发现id_table里的name和某设备的name匹配上了但of_match_table没匹配上probe执行了但设备树资源却取不到。排查半天才确认是走错了匹配分支。所以写驱动时最好统一用of_match_table不要混合使用多种匹配方式避免这种“假匹配”的干扰。另一个常见的低级错误是设备树编译时用了旧的dtc工具导致dtb格式和内核解析器不兼容。这种错误一般会伴随“symbols”相关的解析警告。如果你改了dts但/proc/device-tree里看不到对应节点优先检查dtb是否确实更新到板子上很多开发板uboot会缓存dtb在特定分区光编译是不够的还得确保加载的是新文件。6. Platform驱动框架的扩展从基础匹配到实际工业级开发理解了基本的platform匹配机制后我建议你再向两个方向扩展这两个方向在实际项目中非常常用也是面试时的高频追问点。6.1 probe中的资源获取与devm_*系列API的妙用很多初学驱动的开发者会习惯性地在probe里使用ioremap、request_irq等传统API同时手动维护对应的释放逻辑。但现代内核强烈推荐devm系列API这里简单列一下常用对应关系传统APIdevm替代品ioremap / iounmapdevm_ioremap_resourcerequest_irq / free_irqdevm_request_irqkmalloc / kfreedevm_kmallocdevice_create / device_destroydevm_device_createclk_get / clk_putdevm_clk_getgpiod_get / gpiod_putdevm_gpiod_get用devm API最大的好处是probe执行到一半如果出错内核会自动回滚释放之前已经申请的资源不需要你写一堆goto err标签。在复杂的I2C、SPI、USB驱动里这个优势尤其明显能省掉大量繁琐的错误处理代码。在probe里还有一点要注意platform_get_resource和device_property_read_*系列配合使用可以实现“设备树属性获取”和“传统平台数据获取”的统一。比如读取自定义属性u32 led_pin; device_property_read_u32(pdev-dev, led-pin, led_pin);这种写法在设备树和ACPI两种系统下都能工作可移植性更好。6.2 从Platform总线到其他总线驱动的迁移思路理解platform机制之后你会发现I2C、SPI、USB等总线的驱动模型基本同构。比如I2C驱动需要定义一个i2c_driver结构体里面同样有probe/remove回调只不过匹配依据变成了i2c_device_id或of_match_table。区别在哪里呢platform_bus是一条虚拟总线专门挂载芯片内部集成的外设。I2C总线则是一条真实的物理总线挂在它下面的设备是外部扩展的传感器、存储芯片、音频编解码器。但两者在内核里的驱动模型运作逻辑完全一致总线负责匹配驱动负责probe设备描述资源。所以如果你彻底理解了platform机制再去看i2c_driver、spi_driver会发现只是换了个match函数的实现细节其他内核驱动框架的知识都是相通的。这也是为什么很多嵌入式Linux岗位的JD上会强调“熟悉Linux设备驱动模型”而不是“熟悉某个具体外设的驱动”。对于i.MX6ULL这颗芯片本身它内部很多外设控制器驱动都基于platform模型比如fec以太网MAC驱动drivers/net/ethernet/freescale/fec_main.cuart串口驱动drivers/tty/serial/imx.ci2c控制器驱动drivers/i2c/busses/i2c-imx.cspi控制器驱动drivers/spi/spi-imx.c阅读这些源码时你都可以先从module_platform_driver入口切入然后看of_match_table里的compatible列表再看probe函数的资源获取逻辑。这套分析路径掌握后读任何新驱动的效率都会大幅提升。踩过几次platform_match的坑之后我现在写驱动的习惯是先确认/proc/device-tree下节点属性完全符合预期再确认驱动加载时不报错最后才去看probe是否执行。按这个顺序排查基本能快速定位绝大多数匹配问题。这个内容后续在实际项目中还可以继续扩展比如platform机制与DMA、IOMMU的交互以及大内核里driver_override的用法。先把基础的匹配机制吃透后面这些进阶特性理解起来就顺理成章了。