i.MX6ULL平台Linux驱动：Platform机制与设备树匹配全解析

1. 先聊聊为什么Linux驱动必须搞懂Platform机制

做了几个月的裸机驱动，或者刚写完几个字符设备驱动的新手，大概率会遇到一个困惑：我在x86的虚拟机上写的hello驱动，怎么换到i.MX6ULL这种ARM板卡上就跑不通？原因当然不只是架构差异，更关键的是，ARM Linux的设备管理方式，和你最初学的“驱动自己找硬件地址、自己申请资源”那套完全不一样。

我最早接触i.MX6ULL驱动时也干过一件蠢事：在驱动里硬编码GPIO寄存器地址，然后直接ioremap，板子一换，灯不闪了，按键没反应了。后来才意识到，硬件拓扑、地址、中断这些信息，在设备树年代不该写死在驱动里，而该由内核通过Platform机制，把“设备信息”和“驱动逻辑”撮合到一起。

Platform机制，简单说就是Linux内核为了管理那些“不挂在USB、PCI这些标准热插拔总线上”的片上外设，抽象出来的一条虚拟总线。CPU集成的GPIO控制器、UART、I2C控制器、SPI控制器、看门狗、RTC，这些都属于典型的Platform设备。在i.MX6ULL上，几乎你用得上的每个外设，最终都会以Platform设备的形式注册到内核，再与对应的platform_driver完成匹配。

这篇博文不从“Hello World”讲起，就直接围绕i.MX6ULL这个具体平台，把Platform设备与驱动注册、匹配整条链路讲透。目标读者是那种已经在设备树、U-Boot、内核编译上转过一圈，但回头看内核日志里probe不出来、match不上，一脸懵的Linux驱动开发新手。读完你至少能做到三件事：看懂设备树里的节点是怎么变成platform_device的；知道platform_driver注册后内核按什么规则找设备；出了匹配问题，知道去哪个源码函数、哪条内核消息里排查。

2. 理解Platform总线：一条看不见的“适配总线”

2.1 为什么ARM Linux不直接用“驱动读固定地址”的玩法

早年ARM Linux驱动有个特点：驱动里直接定义外设基址，request_mem_region后ioremap，拿到虚拟地址就用，中断号直接硬编码。单个项目这样干没问题，顶多改起来烦。可一旦要把同一份内核适配多个板卡，哪怕都是i.MX6ULL，A厂商把UART4放在了某个引脚，B厂商换成了UART2，这种“地址写死”的驱动就得反复改源码，改一次编译一次，维护成本直线上升。

Linux内核引入Platform设备模型的初衷就是把变化的部分从驱动里拆出去。驱动只负责“我能做哪些操作、我需要哪些资源”，至于这些资源具体在哪，由设备节点提供。设备节点可以来自设备树，也可以来自板级文件里的platform_device结构体。驱动代码保持稳定，不同板卡只需改设备描述。这套思路如果用一句话概括，就是：**“驱动告诉内核我是干什么的，设备告诉内核我在哪里。”**两者对上，probe就执行；对不上，相安无事。

2.2 Platform总线在i.MX6ULL内核中的位置

看一下i.MX6ULL使用的4.1.15或5.4.x内核源码，drivers/base/platform.c就是这条总线的核心实现。它在系统启动早期通过bus_register(&platform_bus_type)完成注册，这条总线没有物理电气属性，纯粹是一套软件抽象，但它承接的设备数量在ARM平台上是最多的。

常见挂在Platform总线上的设备有这么几类：

有些新手会有个误区，以为I2C设备、SPI设备也是Platform设备。严格说，I2C控制器、SPI控制器本身是Platform设备，但挂在控制器下面的具体外设（比如AT24C02、SPI Flash）归属i2c总线或spi总线管理，它们走的是另一套匹配流程，别混在一起。

3. 设备树节点如何“投胎”成platform_device

3.1 i.MX6ULL启动流程中的自动枚举

在设备树时代，绝大多数Platform设备不需要你手动调用platform_device_register()。内核在启动过程中会做一件非常关键的事：解析整个设备树，把合适的节点自动转换成platform_device。这条链路的入口在drivers/of/platform.c，核心函数是of_platform_default_populate()。

i.MX6ULL启动时，内核初始化到init_machine或者init_irq阶段之后，会依次调用：

of_platform_default_populate_init() -> of_platform_default_populate(NULL, NULL, NULL) -> of_platform_bus_create(root, ...) -> of_platform_device_create_pdata(np, ...) -> of_device_add(dev)

of_platform_default_populate()遍历设备树根节点，遇到platform_bus的子节点或符合特定条件的节点，就创建一个struct platform_device。在i.MX6ULL的imx6ull.dtsi里，根节点下挂着soc节点，soc节点的compatible是simple-bus，这等于告诉内核：“我下面的子节点，只要不是特殊总线，都可以直接创建为platform_device。”这就是为什么你在dtsi里看到的aips1、aips2、aips3这些总线容器节点下的外设节点，启动后都能变成platform_device。

3.2 什么样的节点不会被转成platform_device

并不是设备树里所有节点都会成为platform_device。有一个典型特例：节点带有device_type = "memory"，比如：

memory@80000000 { device_type = "memory"; reg = <0x80000000 0x20000000>; };

这个节点不会被转换为platform_device，因为内存在内核中属于/memory资源管理，由early_init_dt_scan_memory()直接处理。还有根节点下的chosen、aliases、cpus这类节点，也不会走Platform流程。

再看一个实际例子。i.MX6ULL的GPIO1控制器在dtsi中的节点：

gpio1: gpio@0209c000 { compatible = "fsl,imx6ul-gpio", "fsl,imx6ull-gpio"; reg = <0x0209c000 0x4000>; interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; gpio-controller; #gpio-cells = <2>; interrupt-controller; #interrupt-cells = <2>; };

这个节点compatible不以simple-bus标识，也不会被当作特殊控制器单独跳过，最终由of_platform_bus_create()遍历时创建为platform_device，然后驱动drivers/gpio/gpio-mxc.c里of_device_id中匹配fsl,imx6ul-gpio或fsl,imx6ull-gpio的项，两边对上，就会触发probe。

3.3 板级dts新增节点后的“注册时点”

在i.MX6ULL实际开发中，你自己新增一个按键节点或LED节点，通常写在板级dts（比如100ask_imx6ull-14x14.dts）的根节点下：

/ { mykey { compatible = "mydev,key"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_key>; gpios = <&gpio5 1 GPIO_ACTIVE_LOW>; status = "okay"; }; };

内核在解析设备树时，这个mykey节点没有特殊总线标识，也没有device_type拦截，所以一样会被挂到Platform总线上。驱动加载后，平台总线会遍历设备列表寻找匹配项；如果驱动编译进内核，那么在设备创建时也会反向找驱动。整个匹配流程不依赖模块加载顺序，这也是Platform机制让开发省心的地方。

4. platform_driver注册后，内核到底做了什么

4.1 从module_init到probe的全链路

先看i.MX6ULL驱动开发中最常见的驱动入口写法：

static const struct of_device_id mykey_of_match[] = { { .compatible = "mydev,key" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mykey_of_match); static struct platform_driver mykey_driver = { .probe = mykey_probe, .remove = mykey_remove, .driver = { .name = "mykey", .of_match_table = mykey_of_match, }, }; module_platform_driver(mykey_driver);

module_platform_driver展开后实际上做两件事：调用platform_driver_register()，再把driver_register()注册到总线。关键调用链如下：

platform_driver_register(drv) -> drv->driver.bus = &platform_bus_type -> driver_register(&drv->driver) -> bus_add_driver(drv->driver) -> driver_attach(drv->driver) -> bus_for_each_dev(platform_bus_type, NULL, drv, __driver_attach)

bus_for_each_dev遍历Platform总线上已经注册的每一个设备，挨个调用__driver_attach()。这个函数内部会执行：

driver_match_device(drv, dev);

driver_match_device再调用drv->bus->match，也就是platform_match()。一旦匹配成功，内核就会把驱动绑定到设备，然后调用really_probe()，最终执行你写在probe回调里的函数。看到probe里打印的日志，说明设备和驱动已经完成“相亲”了。

4.2 设备先注册、驱动后注册的情况怎么处理

设备树展开发生在内核启动早期，此时驱动可能还没加载。以i.MX6ULL为例，GPIO驱动如果编译成模块，设备节点在启动时已经创建为platform_device，但驱动模块是后面通过modprobe加载的。这种情况下，驱动注册时走的是bus_for_each_dev，能搜到已存在的设备。

反过来也一样：驱动先注册，设备后添加时。device_add()走到bus_probe_device()，同样会执行driver_attach的反向扫描，具体路径是：

device_add(dev) -> bus_probe_device(dev) -> device_initial_probe(dev) -> __device_attach(dev, ...) -> bus_for_each_drv(platform_bus_type, NULL, dev, __device_attach_driver)

这就是Platform机制的对称性。无论设备和驱动谁先到，只要都在总线上，最终都会配对成功。我在调试时一度以为“必须先加载驱动再触发设备创建”，后来翻到drivers/base/dd.c才发现内核早就把顺逆向都考虑周全了。

5. platform_match匹配优先级的源码级拆解

5.1 匹配规则的内在顺序

drivers/base/platform.c里的platform_match()函数是整篇文章的核心。Linux 4.1.15内核源码中它的逻辑大致为：

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); /* 1. 设备树匹配：优先尝试 compatible 匹配 */ if (of_driver_match_device(dev, drv)) return 1; /* 2. ACPI匹配 */ if (acpi_driver_match_device(dev, drv)) return 1; /* 3. id_table匹配 */ if (pdrv->id_table) return platform_match_id(pdrv->id_table, pdev) != NULL; /* 4. 驱动名与设备名匹配 */ return (strcmp(pdev->name, drv->name) == 0); }

这个顺序对i.MX6ULL开发非常关键。只要设备树节点中compatible字段与驱动of_device_id表里任一字符串完全一致，of_driver_match_device()立刻命中，后面的ACPI、id_table、名字匹配全部跳过。

5.2 compatible精确匹配的内部细节

of_driver_match_device()最终会调用of_device_match()，在drivers/of/device.c中：

static int of_device_match(struct device *dev, const struct device_driver *drv) { const struct of_device_id *matches = drv->of_match_table; if (!matches) return 0; return of_match_device(matches, dev) != NULL; }

of_match_device()会逐个遍历matches数组中的compatible字符串，与设备树节点的compatible属性进行精确字符串比较。这里有两个实际操作中经常踩的坑。

第一个坑是大小写和标点差异。设备树中写compatible = "mydev,key"，驱动of_device_id里写成"mydev,Key"，理论上是完全两回事，匹配必然失败。第二个坑是同一个节点多个compatible字符串时的顺序问题。比如i.MX6ULL的GPIO节点：

compatible = "fsl,imx6ul-gpio", "fsl,imx6ull-gpio";

驱动of_match_table中只需命中其一即可。但如果驱动表中只有fsl,imx6ull-gpio，而节点把fsl,imx6ul-gpio写在前面，只要驱动能配到后面这条，依然能成功，因为of_match_device会对节点中多个compatible逐条扫描。

5.3 id_table匹配在i.MX6ULL中的使用场景

设备树匹配出现后，纯id_table匹配的场合并不多，但在部分传统驱动里仍然存在。i.MX6ULL的有些驱动，比如drivers/watchdog/imx2_wdt.c在早期版本也用过platform_device_id表。id_table匹配的规则是比对platform_device_id中的name字段与platform_device的name字段。这个name来自哪？来自设备树节点去掉单位地址后的名字，比如gpio@0209c000的name是gpio。

static const struct platform_device_id imx2_wdt_devtype[] = { { .name = "imx2-wdt", .driver_data = IMX2_WDT }, { /* sentinel */ } };

这种匹配不需要compatible一致，只看设备名是否等于id_table中的name。在设备树年代，这种方式不太推荐新驱动使用，因为设备树的compatible表达力更强、更容易做板级区分。不过遇到老驱动还是要能看懂。

5.4 名字匹配和driver_override的边角情况

platform_match的最后一步是把pdev->name和drv->driver.name做比较。有些人会依赖这个规则，驱动注册时不指定of_match_table，直接靠driver.name等于设备节点名来匹配。在i.MX6ULL上这不是个好习惯，一旦dts把节点改名，驱动就失灵了，毫无灵活性。还有driver_override这个额外机制，几乎不会在正常驱动开发中出现，知道有它就行，遇到再查。

6. i.MX6ULL上匹配成功的关键细节与常见失败场景

6.1 status = "disabled" 与 “孤儿节点”

设备树中一个节点即使compatible和驱动完全一致，如果status属性为disabled，内核在of_platform_bus_create()遍历到该节点时根本不会创建platform_device，自然也就没有匹配机会。常见做法是先在dtsi里把节点默认disabled，然后在板级dts里重新status = "okay"。i.MX6ULL的UART节点就是这种模式：

&uart1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart1>; status = "okay"; };

如果你看到/sys/bus/platform/devices/下面找不到对应设备，先查status。这个最隐蔽，因为编译设备树时不会报错，只有启动日志里该节点被静默跳过。

6.2 compatible字符串不一致导致的probe失败

这是我实际调试中遇到最多的问题。驱动代码里写：

static const struct of_device_id mykey_of_match[] = { { .compatible = "mydev,key" }, { } };

设备树写成：

compatible = "mydev,key1";

此时内核日志里看dmesg | grep mydev，只有设备树传参的信息，完全没有驱动probe的打印。排查手法很直接：挂载debugfs后检查匹配关系，或者直接在驱动里加#define DEBUG打开dev_dbg。更快速的办法是看/sys/bus/platform/devices/mykey/driver_override和/sys/bus/platform/drivers/mykey/目录下有哪些设备符号链接。

6.3 同名节点与设备号冲突

在板级dts里，如果你新增一个根节点叫mykey，但内核其他地方已经有一个同名platform_device，设备注册时会报platform mykey: duplicate device name。此时后注册的设备会被拒绝。i.MX6ULL默认dts里没有重名的话一般没事，但多人协作拷贝dts时容易发生。遇到这个错误，改名是最快的出路，没必要纠结保留原名。

6.4 probe没有被调用，但节点和字符串明明都对

这种问题往往藏在编译顺序。驱动模块用modprobe加载，但设备树节点展开时，内核里没编入该驱动的支持，也没编入自动模块加载所需的MODULE_DEVICE_TABLE(of, ...)导出信息。还要注意，module_platform_driver展开后入口函数是initcall级别，如果驱动编成了模块，它得等文件系统就绪后手动加载或通过udev自动加载。如果驱动是编译进内核的，还需要确认它没有被make menuconfig里某个依赖关闭。

另一个隐蔽因素是没有把of_match_table正确填入platform_driver.driver。有人习惯只在platform_driver里填.probe和.remove，没有初始化.driver.of_match_table，此时of_driver_match_device()直接返回0，而id_table又为空，只能走最后的名字匹配。名字匹配一旦失败，probe死活不执行。

7. 实践验证：在i.MX6ULL上手动观察匹配结果

理论讲完，动手验证一遍比看十遍源码更管用。i.MX6ULL开发板系统起来后，源码编译内核并加载一个测试模块的执行路径如下。

先确认设备存在：

ls /sys/bus/platform/devices/ | grep mykey

正常情况下可以看到mykey目录。如果没有，说明设备树节点没有被展开成设备，回头检查设备树编译和启动日志。然后加载驱动：

insmod mykey.ko

内核日志中应当出现你在probe里加的打印。如果想确认drv和dev当前的绑定关系：

ls -l /sys/bus/platform/drivers/mykey/

目录下会有一个指向设备的符号链接，例如mykey -> ../../../devices/platform/soc/.../mykey。这个符号链接的出现，就是匹配成功、驱动绑定设备的最直观证据。解除绑定可以写：

echo mykey > /sys/bus/platform/drivers/mykey/unbind

再恢复绑定：

echo mykey > /sys/bus/platform/drivers/mykey/bind

你会在日志里看到remove和probe被再次调用。开发调试时这种手动解绑、重绑非常实用，不用反复卸载加载模块就能验证probe/remove的健壮性。

查看当前内核中与该驱动匹配的ID表，可以读取：

cat /sys/bus/platform/drivers/mykey/of_match_table

7.1 一个反直觉的现象：probe返回值的影响

probe返回0才表示成功，返回负数比如-ENODEV或-EIO，内核会认为设备与驱动绑定失败。这个失败不会导致系统崩溃，但/sys/bus/platform/drivers/mykey/下的符号链接不会建立。我遇到过probe前半段正常获取GPIO、后半段注册miscdevice失败导致整个probe报错的情况，排查半天，最后发现是设备号申请区段不足。所以在probe里每申请一项资源后，最好都用goto error的方式逐级清理，否则一旦中途失败，之前已经申请的中断、内存、时钟就全泄漏了。

8. 在内核源码中快速定位Platform匹配相关函数

给新手列一份i.MX6ULL内核源码速查表，遇到问题知道去哪里找。基于NXP官方发布的linux-imx内核，文件路径如下：

调试时，dmesg里搜platform关键字能看到设备注册和driver绑定痕迹；打开CONFIG_DEBUG_DRIVER后，drivers/base/dd.c中的大量调试信息会打印出来，匹配失败时它给出的线索比我凭经验猜要直接得多。

从整个框架来看，Platform设备与驱动匹配机制本质上是把“硬件描述”和“驱动能力”解耦的一张协议网。i.MX6ULL这种量级的学习板最适合拿来做实验，因为它的设备树结构不复杂，源码和文档也好找，一旦把compatible、of_match_table、probe这条链路跑通，你对其他ARM Linux平台的驱动开发就全都通了。