搞i.MX6ULL驱动开发的，十有八九都会在Platform机制上卡过一阵子。明明驱动代码写了，设备树也配了，结果probe就是不进，或者模块加载了一堆报错，不知道从哪查起。这篇文章我把自己在i.MX6ULL上折腾Platform设备与驱动匹配机制的完整经验整理出来，从数据结构、匹配优先级、源码分析，到设备树如何和驱动对上号，再到实际调试中的坑，一次性说清楚。无论你是刚接触嵌入式Linux驱动的新手，还是已经写过几个字符设备、想搞明白“设备是怎么找到驱动的”这层逻辑的开发者，这篇内容都能给你一个可以直接抄作业的参考。
我始终觉得，嵌入式Linux驱动这行，不怕不会写代码，就怕不懂机制。你盯着platform_driver_register看了半天，不如先把platform_match这个匹配函数看明白。所以我不会只丢给你一个“照着写就能跑”的模板，而是把背后的设计思路、调用链、常见翻车点全部拆开讲，这样你换一颗芯片、换一块开发板，依然能靠这套方法论把驱动调通。
1. 为什么i.MX6ULL驱动开发绕不开Platform机制
1.1 从“设备挂在总线上”这个基本概念说起
很多人刚开始学Linux驱动，脑子里只有“编写file_operations、注册字符设备”这一套，但实际到了i.MX6ULL这种SoC上，你会发现事情远不止如此。Linux设备模型里的核心思想是“设备-总线-驱动”三者的关系：设备要和驱动匹配，总得有一条“总线”来牵线搭桥。PCI设备有PCI总线，USB设备有USB总线，它们都有标准的枚举协议，硬件上电之后总线自己就能扫描出设备。但是i.MX6ULL这种ARM SoC内部的UART、I2C、SPI、GPIO、ECSPI等等外设，根本没有自枚举能力，不可能像PCI那样“插上就发现”。
那怎么办？Linux内核给出的答案就是Platform总线，也叫平台总线，它是一条虚拟总线，专门用来管理那些“直接挂在CPU总线上、没有标准枚举机制”的设备。你可以把Platform总线理解成一张“登记表”：设备侧往表上登记一条记录，驱动侧也往表上登记一条记录，然后由内核定期（准确说是每次有新的设备或者新的驱动注册时）去匹配这两类记录，对上了就调用驱动的probe函数，完成设备初始化。
在i.MX6ULL开发中，几乎所有片内外设驱动都挂在Platform总线上。哪怕你用的是GPIO子系统、regmap这类封装好的框架，底层一样离不开Platform设备与驱动的匹配过程。搞懂这一层，你才算真正摸到了Linux驱动开发的命门。
1.2 i.MX6ULL的硬件拓扑与设备树之间的关系
在设备树（Device Tree）普及之后，i.MX6ULL上的Platform设备不再是驱动代码里手动platform_device_register一个个注册的，而是由内核在启动阶段解析设备树（.dtb文件），自动为设备树里的每个节点创建对应的platform_device。这个过程是of_platform_default_populate_init之类的函数完成的，它遍历设备树，凡是符合条件的节点都会被“翻译”成一个platform_device挂到Platform总线上。
这就带来一个很关键的认知转变：在旧内核（比如2.6时代）里，你想加一个Platform设备，需要修改板级文件，手动构造platform_device结构体并注册。而在现代i.MX6ULL的内核（4.x、5.x、6.x）里，绝大多数情况下你只需要改设备树，添加一个节点，指定好compatible属性，内核启动后对应的platform_device就自动存在了。驱动侧的工作，就是填写of_match_table，声明自己支持哪个compatible，然后等内核来匹配。
所以i.MX6ULL上“写Platform驱动”这件事，实际上变成了两件事：一是写设备树节点，二是写驱动里的匹配表。这两者必须对得上，否则驱动永远不会被触发。
1.3 Platform机制能解决什么问题
从工程角度看，Platform总线至少解决了三个实际问题。第一，解耦。设备的硬件资源（寄存器地址、中断号、DMA通道）在设备树里描述，驱动代码只负责拿到这些资源并使用，同一份驱动代码可以在不同芯片、不同板卡上通过修改设备树来复用，不用改C代码。第二，标准化匹配流程。不管你是什么外设，只要挂在Platform总线上，匹配规则都是同一套，学一次就能用一辈子。第三，热插拔支持。虽然SoC内部设备一般不会热插拔，但Platform总线也支持模块按需加载，当设备存在时自动触发驱动加载，设备移除时触发remove，这对模块化开发、内核裁剪都非常友好。
说白了，Platform机制就是Linux设备模型的一个具体实现。你理解了它，后面看I2C、SPI、USB这些子系统驱动的匹配逻辑，会发现它们都是同一个思路的变体，只不过各自的bus结构体里实现了不同的match函数而已。
2. Platform核心数据结构与匹配机制原理
2.1 三个核心结构体需要先记住
Platform机制涉及的核心结构体有三个：platform_device、platform_driver、device_driver。在Linux内核源码里，platform_device定义在include/linux/platform_device.h，它描述一个具体的Platform设备，包含设备的名称、编号、资源（resource）列表等。platform_driver则描述一个Platform驱动，里面最重要的是probe和remove函数指针，以及一个内嵌的struct device_driver driver成员。
这里有个容易混淆的点：platform_driver里的driver成员类型是struct device_driver，而platform_device里的dev成员类型是struct device。真正参与匹配时，内核比较的是platform_device->dev和platform_driver->driver这两个成员。所以你在驱动代码里看到的of_match_table、name这些字段，都是挂在driver这个内嵌结构体上的，而不是直接挂在platform_driver本身上。
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; };platform_device的结构相对复杂一些，但最关键的两个字段是name（设备名）和num_resources/resource（资源数组）。设备树方式下，name一般取自设备树节点的name属性，资源则从节点的reg、interrupts等属性解析而来。
2.2 匹配入口platform_match的优先级规则
Platform设备与驱动的匹配，最终由platform_match函数完成，它定义在drivers/base/platform.c中。这个函数的逻辑就是整个匹配机制的核心，我直接给你列出它的判断顺序：
| 优先级 | 匹配方式 | 说明 |
|---|---|---|
| 1 | of_driver_match_device(dev, drv) | 设备树匹配，比较驱动of_match_table与设备节点的compatible等属性 |
| 2 | acpi_driver_match_device(dev, drv) | ACPI匹配，x86/ARM64等平台使用，i.MX6ULL一般不涉及 |
| 3 | platform_match_id(drv->id_table, pdev) | 匹配驱动id_table与设备name |
| 4 | strcmp(pdev->name, drv->driver.name) | 直接比较设备name与驱动name |
这里要特别提醒：只要驱动指定了id_table，第三步失败之后，即使设备name和驱动name字符串相同，第四步的strcmp也不会执行。换句话说，第四步匹配是有前提条件的——驱动没有设置id_table。这个细节是很多驱动“莫名不probe”的元凶。
对于i.MX6ULL这种设备树平台来说，最常用的是第一级匹配。of_driver_match_device内部会遍历驱动的of_match_table，逐个与设备节点的compatible、type、name属性比较，只要有一个of_device_id匹配成功，函数就返回true。如果你驱动里连of_match_table都没设置，那第一级直接跳过，落到后面的id_table或name字符串比较。
2.3 设备树匹配的幕后：of_driver_match_device
展开看一下of_driver_match_device的流程。它首先检查驱动of_match_table是否为NULL，如果为空就直接返回0（不匹配）。然后调用of_match_device，这个函数遍历matches数组，对每个of_device_id与设备节点的属性做比较。
const struct of_device_id *of_match_device(const struct of_device_id *matches, const struct device *dev) { if (!matches) return NULL; return of_match_node(matches, dev->of_node); }of_match_node的逻辑值得你仔细看。它会对同一个设备树节点，依次尝试匹配matches数组中的每一项。每一项of_device_id里可以定义compatible、type、name三个字段，匹配时这三个字段是“或”的关系，只要其中一个能对上就算匹配成功。但在实际项目中，大家几乎只用compatible字段，type和name很少用。
设备树节点可以指定多个compatible字符串，比如：
compatible = "mycompany,myplatdev", "simple-mfd";此时of_device_is_compatible会从第一个字符串开始逐一遍历，只要驱动的compatible与其中任何一个相同，就返回匹配。这给了驱动很大的兼容性空间：同一个驱动，可以兼容多个厂商的硬件，只需在of_match_table里列全即可。
3. 在i.MX6ULL上编写Platform驱动（实操）
3.1 环境与最小驱动框架
我这边的环境是：i.MX6ULL开发板，内核版本用的5.4（NXP的官方BSP或者社区主线都可以），主机是Ubuntu 20.04，交叉编译工具链为arm-linux-gnueabihf-。下面的驱动代码不依赖具体板级硬件，我设计了一个简单的“虚拟外设”来演示匹配流程，但它用到的资源读取方式和真实外设完全一致，你换成实际的GPIO、UART、SPI外设后思路不用变。
驱动代码整体框架如下：定义of_match_table、实现probe和remove、构造platform_driver、通过module_platform_driver注册。这里的probe就是驱动与设备匹配成功后内核回调我们的入口函数。
#include <linux/init.h> #include <linux/module.h> #include <linux/platform_device.h> #include <linux/of.h> #include <linux/of_device.h> #include <linux/resource.h> #include <linux/io.h> static int myplatdev_probe(struct platform_device *pdev) { struct resource *res; void __iomem *base; dev_info(&pdev->dev, "myplatdev probe success\n"); res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (res) { dev_info(&pdev->dev, "reg: start=0x%llx, end=0x%llx\n", (unsigned long long)res->start, (unsigned long long)res->end); } res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); if (res) { dev_info(&pdev->dev, "irq: %d\n", (int)res->start); } /* 映射寄存器地址（示例） */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (res) { base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(base)) { return PTR_ERR(base); } dev_info(&pdev->dev, "remapped base=%px\n", base); } return 0; } static int myplatdev_remove(struct platform_device *pdev) { dev_info(&pdev->dev, "myplatdev remove\n"); return 0; } static const struct of_device_id myplatdev_of_match[] = { { .compatible = "mycompany,myplatdev", }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, myplatdev_of_match); static struct platform_driver myplatdev_driver = { .probe = myplatdev_probe, .remove = myplatdev_remove, .driver = { .name = "myplatdev", .of_match_table = myplatdev_of_match, }, }; module_platform_driver(myplatdev_driver); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("i.MX6ULL platform device match demo");3.2 设备树节点设计
在i.MX6ULL的设备树源文件（比如imx6ull.dtsi或你自己的板级dts）里，添加一个节点。注意两个地方：一是compatible必须和驱动里的of_match_table完全一致；二是节点要放在合适的父节点下，通常放在根节点或simple-bus兼容的节点下，这样内核启动时才会自动为它创建platform_device。
/ { myplatdev { compatible = "mycompany,myplatdev"; reg = <0x020c4000 0x1000>; interrupts = <32 4>; status = "okay"; }; };这里reg地址我随便写了一段i.MX6ULL的寄存器区域（如IOMUXC相关的地址空间），实际项目里换成你外设的真实寄存器基地址和长度即可。interrupts属性里，32是中断号，4是触发类型（IRQ_TYPE_LEVEL_HIGH），具体数值要参考i.MX6ULL手册里的中断号编排。
设备树节点的名字其实不太重要，因为匹配主要靠compatible。但按照惯例，节点名应该体现设备类型，比如uart4、i2c2之类。一个常见误区是：有人觉得节点名必须和驱动driver.name一样，这其实是旧时代的思维，设备树方式下并不要求节点名和驱动名一致。
3.3 驱动加载与匹配过程分析
设备树改好后，重新编译dtb，烧录到开发板。启动后插入模块（或者直接把驱动编进内核），在/sys/bus/platform/devices/目录下你就能看到myplatdev这个设备目录，说明设备树节点已经被成功解析为platform_device了。
模块加载时，module_platform_driver宏会展开为platform_driver_register，这个注册过程会触发内核去遍历当前总线上所有的设备，逐个调用platform_match。由于我们设置了of_match_table，并且设备和驱动的compatible一致，匹配成功，内核会调用myplatdev_probe。
probe里我用了platform_get_resource来获取设备树里的reg和interrupts信息，这是i.MX6ULL驱动开发中最常用的资源获取方式之一。devm_ioremap_resource则是把物理地址映射为内核虚拟地址，之后驱动就可以直接对寄存器进行读写操作了。这套代码跑起来后，串口终端应该能看到类似这样的输出：
myplatdev myplatdev: myplatdev probe success myplatdev myplatdev: reg: start=0x20c4000, end=0x20c4fff myplatdev myplatdev: irq: 32 myplatdev myplatdev: remapped base=00000000c1234000看到这几行，就说明Platform设备与驱动的匹配机制已经完全打通了。
3.4 编译与加载验证
交叉编译这个模块的命令很简单，但要注意指定内核头文件和ARCH、CROSS_COMPILE环境变量。我习惯写一个简单的Makefile，避免每次敲一大串命令：
KERNELDIR := /home/user/linux-5.4 CROSS_COMPILE := arm-linux-gnueabihf- obj-m := myplatdev.o all: $(MAKE) -C $(KERNELDIR) M=$(PWD) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KERNELDIR) M=$(PWD) ARCH=arm CROSS_COMPILE=$(CROSS_COMPILE) clean编译完成后，把myplatdev.ko拷贝到开发板文件系统，执行insmod myplatdev.ko，再执行rmmod myplatdev观察remove回调是否执行。/sys/kernel/debug/下如果挂了debugfs，也可以用cat /sys/kernel/debug/devices_debug来查看设备状态，但i.MX6ULL的默认BSP不一定开这个选项，一般看dmesg日志就足够了。
4. 常见问题与排查技巧实录
4.1 probe没有被调用怎么办
这是Platform驱动开发里出现频率最高的问题。遇到后先不要慌，按照下面的顺序依次检查。第一步，确认设备树里compatible和驱动of_match_table里的字符串完全一致，这个一致指的是包括厂商前缀在内的完整字符串，大小写、连字符都不能错。第二步，确认dtb真的更新了，有些时候你改了dts，编译也通过了，但U-Boot加载的还是旧dtb，用ls /sys/firmware/devicetree/base/看看有没有你的节点。第三步，确认驱动确实注册到了Platform总线上，/sys/bus/platform/drivers/下应该有一个以driver.name命名的目录。第四步，如果以上都没问题，看看是否有probe被调用但中途失败了，用dmesg查看是否有报错信息。
我踩过最离谱的一次坑是of_match_table数组忘记加最后的哨兵{ /* sentinel */ }，结果内核在遍历匹配表时越界访问，匹配行为变得不可预测，有时候probe能进，有时候不能。这个细节务必记住。
4.2 匹配上了但资源获取失败
probe成功进入，但platform_get_resource返回NULL，这通常是设备树reg或interrupts属性写得不规范。比如有些新手把reg写成了reg = <0x020c4000>，后面少了长度值，虽然语法上设备树解析不报错，但resource的长度为0，devm_ioremap_resource就会因为“resource size is zero”而失败。
另一个常见问题是：把interrupts属性直接写到了普通外设节点下，但该节点没有被指定interrupt-parent，或者中断控制器路径不对，导致platform_get_resource(pdev, IORESOURCE_IRQ, 0)拿不到中断资源。检查设备树里是否声明了正确的interrupt-parent，i.MX6ULL上一般是&gpc或者某个GPIO控制器，具体要看你的中断接在哪个控制器上。
4.3 设备树节点没有生成platform_device
如果你发现/sys/bus/platform/devices/下根本找不到设备目录，那就是设备树节点没有被内核解析成platform_device。最常见的原因是节点挂在了一个没有simple-bus兼容属性的父节点下。内核在of_platform_default_populate_init时，默认只会为满足特定条件的节点创建platform_device：从根节点开始遍历，遇到compatible为simple-bus的节点会继续深入，遇到普通外设节点就创建platform_device并把其子节点也考虑进去。
如果你的节点放在了一个自定义的总线节点下，但这个节点没有声明simple-bus兼容，那内核就不会自动展开它下面的外设节点。解决方法有两种：一是给你的父节点加上compatible = "simple-bus"；二是手动调用of_platform_populate在驱动里去创建子设备。对i.MX6ULL开发来说，首选第一种，直接把外设节点挂在根节点下或者某个标准的simple-bus节点下最省事。
4.4 几个实用调试手段
调试Platform匹配问题，我常用的几个手段分享给你。第一，打开内核的device model调试信息，在启动参数或内核配置里开启CONFIG_DEBUG_DRIVER，然后dmesg里就能看到platform_match相关的详细日志，能直接告诉你匹配到哪一步失败了。第二，查看sysfs，/sys/bus/platform/devices/列出所有设备，/sys/bus/platform/drivers/列出所有驱动，两者对照基本能定位问题。第三，在驱动里临时加dev_info打印，输出pdev->name和pdev->dev.of_node的信息，确认设备节点有没有正确挂在device上。第四，如果怀疑是compatible不匹配，可以在板子上直接执行cat /proc/device-tree/myplatdev/compatible，看看实际生效的设备树里compatible到底是什么内容。
5. 从Platform机制到Linux设备模型设计思想
5.1 匹配方式的选型建议
在i.MX6ULL上编写Platform驱动时，匹配方式的选择其实很明确：优先使用设备树compatible匹配，这是现代内核推荐的方式，也是NXP官方BSP和各种开发板默认的方式。id_table匹配多见于一些老驱动或者需要兼容多种芯片的平台，它可以在不修改设备树的前提下，让一个驱动支持多个不同名字的设备。纯name字符串匹配则基本属于历史遗留方式，在设备树平台下尽量避免使用，因为设备树节点的name属性往往被规范为“节点名@地址”的格式，直接比较字符串很容易失配。
我在实际项目中，有时候会用id_table配合设备树来做一些特殊处理，比如在platform_driver中同时设置of_match_table和id_table，这样既能用设备树的compatible匹配，又能保留老式的name匹配能力，兼容旧板卡。但要记住前面说的优先级规则：只要驱动有id_table，第四级的strcmp就被跳过，如果你还依赖name匹配，务必把对应的platform_device_id也写进id_table里。
5.2 从一处通到处通：其他总线的匹配机制
理解了Platform总线的匹配逻辑之后，去看I2C、SPI这些子系统的驱动，你会发现思路高度相似。I2C总线的i2c_device_match同样会先尝试of_driver_match_device（设备树compatible匹配），然后尝试acpi_driver_match_device，最后再用i2c_match_id去匹配i2c_device_id表。SPI总线也是如此。所以你在i.MX6ULL上写I2C驱动时，of_match_table照样是关键，写法上唯一的差异只是驱动结构体从platform_driver换成了i2c_driver，注册函数从module_platform_driver换成了module_i2c_driver。
这就是Linux设备模型的魅力：一条总线一套机制，学透一条，其他都能融会贯通。对你后续接触USB、PCIe、MDIO等更复杂的总线驱动开发，这个基础会发挥非常大的作用。
5.3 理清设备树的资源描述与驱动获取之间的关系
设备树里的reg属性描述了外设的寄存器地址空间，interrupts描述了中断信息。这些属性在设备树解析阶段被转换成了struct resource，存储在platform_device的resource数组中。驱动侧通过platform_get_resource、platform_get_irq等接口按索引获取相应资源。这个设计的意义在于，硬件资源的具体数值、地址、中断号，全部从驱动代码中剥离出去，交给设备树去描述。驱动代码只需要关心“我要第0个内存资源”“我要第0个中断”，至于具体是多少，由板级配置决定。
这种做法对产品化开发极其有利。比如同一个IP核，在A板卡上挂在地址0x1000，在B板卡上挂在地址0x2000，驱动代码一行不用改，设备树各写各的就行。我在i.MX6ULL和后续的i.MX8M、i.MX93项目里都受益于这套机制，硬件改版后驱动几乎不动的体验，只有经历过的人才懂。
我个人在实际开发中，始终建议把“设备树-Platform总线-驱动”这三者的关系理顺再动手写代码。别急着搜一个驱动模板就改，先花半小时确认：设备树节点会生成platform_device吗？compatible字符串对上了吗？probe里的资源获取能顺利拿到吗？这三个问题确认完，你的驱动基本已经成功了一半。后面就算遇到问题，也能快速定位到是设备树的问题、匹配的问题，还是probe内部的问题，而不是一头扎进代码里乱试。这套排查思路，比任何一个现成驱动模板都值钱。
