做i.MX6ULL驱动开发的人十个里有九个都卡过这种问题设备树节点明明写好了驱动代码也register了但probe函数就是死活不执行dmesg里一片安静。我最初在公司项目里移植一个外设驱动时就栽在这上面折腾了整整两天最后发现是compatible字符串拼写不一致。这背后涉及的就是Linux驱动开发里最基础也最容易被轻视的Platform设备与驱动匹配机制。先说结论Platform总线是Linux设备驱动模型中最重要的一个虚拟总线它要解决的核心问题就是——设备信息与驱动代码如何高效、准确地对上号。i.MX6ULL这类SoC内部有大量无法通过物理总线如PCI、USB枚举的集成外设GPIO控制器、UART、I2C、SPI全都挂在Platform总线上。搞懂这套匹配机制你才能理解为什么设备树写错一个字符串驱动就不加载才能学会怎么让设备树和驱动代码“完美对上暗号”。这篇文章我会从设计原理讲到实际代码再用i.MX6ULL开发板上的真实调试经历收尾。适合正在入门嵌入式Linux驱动开发、或者已经被probe函数不执行折磨过的朋友看完你就能自己排查这类问题了。1. Platform机制到底解决了一个什么问题1.1 没有物理总线的“孤儿设备”怎么管理Linux的设备模型是按照“总线-设备-驱动”三层结构来组织的。像USB设备、PCI设备它们天生挂在USB控制器、PCI控制器下面可以通过协议去枚举、识别设备的热插拔也能被自动感知。但SoC内部集成的大多数外设不具备这种能力它们没有枚举过程CPU只能通过固定地址访问它们的寄存器中断号也是硬件上写死的。如果让这些设备驱动直接使用module_init注册一个字符设备然后内部写死基地址、硬编码中断号会带来两个非常现实的问题。第一代码无法复用。同样是GPIO控制器在A开发板上寄存器基址是0x020C0000到了B开发板上变成0x021A0000直接硬编码的话就得改驱动源码重新编译要是驱动还同时支持几个不同型号的芯片代码就会变得非常臃肿。第二资源管理变成一团乱麻。驱动的request_irq、request_mem_region必须在探针阶段做好但如果没有统一框架谁负责申请、谁负责释放、什么时候调用这些函数全凭开发者自觉很容易出现资源泄漏或者重复申请。Platform机制就是为了解决这两件事。它把“硬件长什么样”和“驱动怎么操作硬件”彻底拆开。硬件信息放在设备侧驱动侧只声明自己支持哪些设备、匹配成功后如何初始化两者在Platform总线上完成配对配对成功就自动调用驱动里的probe函数。1.2 从板级文件到设备树的演进在Linux 2.6时代设备侧的信息用板级文件来描述开发者在arch/arm/mach-xxx/目录下定义一个platform_device结构体指定资源、挂到平台上然后调用platform_device_register注册进内核。这套机制在当时没有问题但它有一个根本性的弱点硬件一旦改动必须重新编译整个内核。i.MX6ULL这类ARM SoC大量使用设备树Device Tree之后事情变得优雅了很多。设备树把硬件描述从内核源码中抽离变成一份独立的dts源文件由bootloader传给内核。内核在启动阶段扫描设备树把每个带compatible属性的节点自动转换成platform_device挂在Platform总线上。驱动开发者的工作流也彻底变了改硬件配置改设备树改驱动逻辑才改C代码两边解耦不再需要为每块新板子重新编译内核。这里有个关键点需要理解内核启动时of_platform_default_populate_init会遍历设备树中所有节点为可用的节点创建platform_device这是Platform总线“设备侧”的主要来源。而驱动侧则通过module_platform_driver注册platform_driver。两边的信息在总线上相遇接下来就看匹配机制怎么工作了。2. 设备与驱动如何匹配四条路线一次看懂2.1 最主流设备树compatible匹配在设备树时代绝大多数设备节点都带有一个compatible属性这是一个字符串数组用于告诉内核这个设备“兼容哪些规范”。比如i.MX6ULL内部看门狗的节点通常长这样wdog1: wdog020bc000 { compatible fsl,imx6ul-wdt, fsl,imx21-wdt; reg 0x020bc000 0x4000; interrupts GIC_SPI 80 IRQ_TYPE_LEVEL_HIGH; clocks clks IMX6UL_CLK_WDOG1; };字符串数组中的每个元素按优先级从高到低排列第一个是最精确的型号后面的表示兼容性更宽泛的旧型号。驱动侧的of_match_table会把驱动支持的兼容字符串列出来static const struct of_device_id mydriver_of_match[] { { .compatible fsl,imx6ul-wdt, }, { .compatible fsl,imx21-wdt, }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, mydriver_of_match);匹配时内核会比较设备节点compatible属性中的每一项和of_match_table中列出的每一项只要有一个字符串相等就认为匹配成功。注意设备树里的compatible顺序不重要重要的是驱动表的compatible值必须和设备节点中的某个值完全一致哪怕差一个空格都不行。2.2 老派做法id_table和name匹配在没有设备树的时代或某些特殊情况设备侧通过platform_device.name标识身份驱动侧则靠id_table和driver.name来认领设备。这种匹配方式更直接就是字符串比较。static const struct platform_device_id mydriver_ids[] { { .name imx6ul-wdt, }, { }, }; MODULE_DEVICE_TABLE(platform, mydriver_ids); static struct platform_driver mydriver { .probe mydriver_probe, .remove mydriver_remove, .driver { .name imx6ul-wdt, .owner THIS_MODULE, }, .id_table mydriver_ids, };匹配时内核优先遍历id_table检查platform_device.name和id_table[i].name是否相等。如果id_table为空则会退回去比较platform_device.name和driver.name。这套机制在内核源码里仍然保留很多老驱动和部分特定场景比如MFD子设备还在使用但新写的驱动一般直接走设备树匹配。2.3 完整的匹配优先级Linux源码中platform_match函数定义了最终的匹配顺序大致是这样如果设备有of_node即来自设备树优先使用of_driver_match_device通过设备树compatible属性匹配。如果上一步失败尝试ACPI匹配i.MX6ULL一般不涉及。如果驱动定义了id_table遍历它与设备name比较。最后再比较platform_device.name和driver.name。这里有几个容易忽略的细节。即使设备树中有节点如果of_match_table匹配失败内核仍有机会通过id_table或driver.name来匹配。所以一个驱动如果同时指定了of_match_table和driver.name有时会遇到“compatible不一致但name碰巧一样probe还是被调用了”的情况这反而掩盖了compatible写错的问题排查时要特别小心。另一个细节是MODULE_DEVICE_TABLE宏。它在编译时生成模块的别名信息让modprobe可以根据设备树自动加载对应驱动模块。如果你开发时把驱动编成模块但漏写了这个宏就会发现手动加载模块没问题一按设备树自动加载就失效非常隐蔽。3. i.MX6ULL实操从设备树到probe完整走一遍3.1 设备树节点的“身份证”设计我在i.MX6ULL开发板上做实验时习惯先创建一个最小化的测试节点用来验证整套Platform匹配流程。假设我们要驱动一个挂在SoC内部的中断控制器或简单外设首先在arch/arm/boot/dts/imx6ull-myboard.dts或对应的dtsi文件中追加节点iomuxc { /* 引脚复用配置涉及pinctrl子系统 */ }; mydev: mydev020c4000 { compatible mycompany,imx6ull-mydev; reg 0x020c4000 0x4000; interrupts GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH; status okay; };节点名mydev020c4000中的mydev只是给读者看的标签真正起匹配作用的是compatible属性。reg描述寄存器基地址和长度interrupts描述中断号内核会把这二者解析为platform_device中的resources数组。写设备树时有几个注意事项。第一compatible字符串建议采用“厂商,型号”的格式这是内核社区的惯例。第二status属性默认值就是okay但如果你从某个dtsi文件拷贝节点过来一定要确认它不是disabled否则节点会被内核跳过probe自然不会被调用。第三reg和interrupts必须与i.MX6ULL参考手册上的地址和中断号一致我见过太多人把SPI中断号多算一个或少算一个导致request_irq失败。3.2 驱动代码骨架与关键接口有了设备树节点还需要一份能跟它对上暗号的驱动。下面是我整理的一个非常精简、但覆盖核心流程的驱动模板#include linux/module.h #include linux/platform_device.h #include linux/of.h #include linux/of_device.h #include linux/of_address.h #include linux/interrupt.h #include linux/slab.h struct mydev_data { void __iomem *base; int irq; }; static irqreturn_t mydev_isr(int irq, void *dev_id) { struct mydev_data *data dev_id; /* 读取寄存器清除中断标志处理业务 */ pr_info(mydev interrupt handled\n); return IRQ_HANDLED; } static int mydev_probe(struct platform_device *pdev) { struct mydev_data *data; struct resource *res; int ret; data devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL); if (!data) return -ENOMEM; /* 获取寄存器资源并做内存映射推荐使用devm系列接口 */ res platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(pdev-dev, no memory resource found\n); return -ENXIO; } >ls /sys/bus/platform/devices/如果设备树节点解析成功这个目录下应该能看到类似mydev020c4000的目录。看不到的话问题出在设备树要么节点被status disabled禁用了要么DTC编译时就没把这个节点编入实际加载的dtb。驱动侧执行lsmod确认驱动是否加载或者cat /proc/devices看设备号。模块加载后驱动会出现在总线上但不会出现在设备列表里。如果两边都出现了但probe还是没执行重点检查compatible字符串。最容易犯的错误包括驱动里写了mycompany,imx6ull-mydev设备树里却写成mycompany,imx6ull-mydev1差一个字符都匹配不上。这时可以在内核中开启CONFIG_OF_DEBUG或者使用动态调试功能echo file drivers/base/platform.c p /sys/kernel/debug/dynamic_debug/control排查过程中会看到platform_match返回0的具体信息非常直观。还有一种常见情况of_match_table忘记加哨兵条目{ /* sentinel */ }。匹配函数不知道数组边界在哪可能读到随机数据导致匹配结果不可预测。这个问题看起来低级但代码量大时很容易漏掉建议每次写完都检查。4.2 sysfs、dmesg和中断号相关的坑驱动开发里最能证明匹配成功的标志是probe里的打印。我用dev_info输出这样日志会带上设备名dmesg里看得很清楚。有些喜欢用pr_info的老代码日志里看不到设备名多人协作查问题时容易分不清是哪块板在外设报错。中断这块也是重灾区。i.MX6ULL使用GIC中断控制器设备树里的interrupts属性一般写成GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH。这里面38是硬件中断号而不是Linux内核中的IRQ编号。实际注册到内核的irq号会在GIC驱动处理时自动映射开发者只需在platform_get_irq返回后直接用即可。但硬件中断号千万不能错错了就会导致中断始终触发不了或者别的驱动把同一个中断给占了。另外建议在probe里主动判断platform_get_irq的返回值。老驱动喜欢判断是否小于0新内核中platform_get_irq成功时返回正数失败返回负错误码判断逻辑别写反。4.3 实测案例一个反复触发的匹配陷阱我在项目里遇到过一个很有意思的坑值得一提。当时我在开发一个基于i.MX6ULL的工控板需要在设备树里描述一个自定义外设。设备树写完、驱动编成模块加载dmesg里始终看不到probe日志但/sys/bus/platform/devices/目录里设备明明存在。排查了一轮下来发现驱动模块编译时链接的还是旧版头文件struct of_device_id的内存布局跟内核不兼容导致compatible比较时读的是错误偏移量。重新编译内核源码树配套的模块后问题消失。这个经历给我的教训是设备树和内核版本、模块编译工具链必须严格对应。如果你从其他开发板或者教程里拷贝驱动代码一定要用当前内核源码树重新编译不要迷信资料里“拿过去直接能用”的说法。尤其是i.MX6ULL这种芯片不同BSP包的设备树写法差异非常大哪怕同一款芯片不同厂商的核心板也有不同的pinctrl配置照搬代码不如理解机制来得踏实。5. 写在最后的个人经验Platform设备与驱动匹配机制我后来带过好几个新同事我都是让他们先把这条匹配链路看懂再动手写驱动。很多问题之所以排查慢不是因为不会写语法而是不理解内核到底按照什么顺序、在哪里比对了什么字符串。我建议你在实际开发中也养成这样的习惯拿到一块新板子先去/sys/bus/platform/devices/里看看有哪些设备再想哪些驱动是匹配它们的写Probe之前先用文档工具查一下of_match_table的格式规范遇到probe不执行先查compatible、再查status、最后查资源类型。这类问题90%以上都是这三个原因。i.MX6ULL作为一颗Cortex-A7内核、性价比极高的工业级处理器其Platform机制和所有现代ARM SoC保持一致你在NXP芯片上吃透的这些经验换到瑞芯微、全志、ST的芯片上同样适用。掌握了这套机制你就不只是在“调代码”而是真的在理解Linux的设备驱动模型。
核心机制与工程实践详解)
