写驱动这东西，我一开始也绕了不少弯路。尤其在 i.MX6ULL 这种 Cortex-A7 内核的板子上，网上资料虽然多，但大多是给你扔一个 GPIO 点灯例程，照着抄完能跑，却不知道自己到底在干什么。一旦换一颗芯片，或者换一个外设，立刻傻眼。后来把 Linux 的 Platform 驱动模型彻底搞明白之后，再看那些例程，才发现很多所谓的“平台驱动”其实只是套了个壳，真正核心的匹配机制根本没讲清楚。
这篇文章我就从 i.MX6ULL 的实际开发场景出发，把 Platform 设备与驱动的匹配机制掰开揉碎地讲一遍。不管你是刚接触嵌入式 Linux 驱动开发，还是已经写过几个字符设备驱动但总觉得隔着层窗户纸，这篇内容应该都能帮你把那层膜捅破。我们不光说“是什么”，更要讲清楚“为什么是这么设计的”，以及在实际板子上调试时会遇到哪些坑。
1. 先搞清楚：为什么 Linux 需要 Platform 总线
1.1 从硬件拓扑说起
要理解 Platform 驱动模型，得先回到硬件层面。i.MX6ULL 这颗芯片内部有大量的控制器：GPIO、UART、I2C、SPI、PWM、SDIO、LCD 控制器等等。这些外设大部分都挂在 SoC 内部的 AMBA 总线或者 SoC 内部总线上，它们不像 PCI 设备那样有规范的枚举机制，也不像 USB 设备那样有标准的描述符。在系统启动时，Linux 不可能靠“扫描”的方式自动发现这些设备，因为它们的地址、中断号、时钟等信息都固化在芯片设计里，甚至有些引脚功能是由板级设计决定的。
这时候就需要一种机制，让内核知道“这个 SoC 上有什么设备、它们的资源是什么、应该由哪个驱动来接管”。Platform 总线（平台总线）就是 Linux 为了解决这个问题而设计的虚拟总线。说它“虚拟”，是因为它对应的不是真实的物理总线，而是一套软件抽象层，专门用来管理那些直接集成在 SoC 上、或者连接在板卡上但没有标准热插拔总线的设备。
i.MX6ULL 上跑 Linux，几乎 99% 的外设驱动都是 Platform 驱动，这一点都不夸张。哪怕你用的是内核里自带的 GPIO LED 驱动，它底层注册到的也是 Platform 总线。所以搞明白这套模型，就等于拿到了 i.MX6ULL 驱动开发的大门钥匙。
1.2 设备、驱动、总线三者的关系
Linux 设备模型的核心就三样东西：设备（device）、驱动（driver）、总线（bus）。总线负责匹配设备和驱动，驱动通过 probe 函数来声明“我能管理这个设备”，设备则通过自身携带的属性来表明“我是什么”。
在整个 Linux 设备模型里，注册一个设备会把它挂到总线上，注册一个驱动也会把它挂到总线上。总线会维护两条链表，一条是设备链表，一条是驱动链表。每当新的设备或驱动注册进来，总线就会执行一次“配对检查”，看看有没有合适的双方能组合在一起。如果匹配上了，总线就会调用驱动的 probe 接口，把这个设备真正“激活”。
Platform 总线是 Linux 设备模型这套机制的最典型实例。它没有硬件上的总线控制器，纯粹靠软件规则来判断匹配，但这套规则恰好和 i.MX6ULL 这种固定外设资源的 SoC 配合得极好。它的核心价值在于分离：驱动只关心“我能干什么”，设备只声明“我是什么”，两者通过总线上的匹配规则自动结合。
2. 匹配机制的本质：谁来决定驱动和设备是对的一对
2.1 四种匹配方式，compatible 是主角
Platform 总线的匹配逻辑在内核源码里，函数名叫platform_match，位于drivers/base/platform.c。每次有新的 platform device 或者 platform driver 注册时，总线都会调用这个函数进行比对。它的匹配顺序其实是有优先级设计的，我先把四种方式列出来：
| 匹配方式 | 判断依据 | 典型场景 |
|---|---|---|
| compatible 匹配 | 设备树节点的compatible属性与驱动of_match_table中的字符串 | 设备树使用场景（i.MX6ULL 基本都是这种情况） |
| 设备树节点名匹配 | 驱动id_table中的name字段与设备树节点name | 早期设备树过渡方案，现在很少单独用 |
| 平台设备名字匹配 | 驱动id_table里的name字段与 platform device 的name字段 | 不使用设备树，用板级文件注册设备的旧方法 |
| ACPI/HID 匹配 | ACPI 表匹配 | x86 平台为主，ARM 上基本忽略 |
对于 i.MX6ULL 开发来说，我们绝大多数情况下使用的都是第一种：compatible匹配。设备树里的一个节点通过compatible属性声明“我是谁”，驱动通过of_match_table声明“我能认领谁”，两边字符串完全一致时，总线就认为这是一对。
2.2 compatible 的命名规范与匹配细节
compatible属性的写法有讲究。通常遵循“厂商,型号”的格式，例如fsl,imx6ull-gpio、fsl,imx6ull-uart。这个命名规范不是随便定的，它实际上是一种层次化的匹配思想：前面的厂商字符串用来区分不同供应商的同类型设备，后面的型号用来对应具体的 IP 版本。
有一个非常容易被忽视的细节：compatible属性可以包含多个字符串。设备树节点里写：
compatible = "myvendor,mydevice", "fsl,imx6ull";这表示设备既可以是“myvendor,mydevice”这个具体型号，也兼容“fsl,imx6ull”这个通用型号。内核在匹配时，会按顺序拿驱动of_match_table里的每个条目去对比，只要有一个匹配上就算成功。这个机制在实际项目里用途很大：比如你基于 i.MX6ULL 做了一款产品，驱动可以先匹配你自己的型号字符串，如果要复用 NXP 官方驱动或者兼容其他板卡，再往后写一个fsl,imx6ull作为次要选择。
实操提示：驱动里
of_match_table的最后一个条目建议以{ /* sentinel */ }结尾，这是必须的，否则内核不知道这个表有多长，匹配时可能越界访问导致内核崩溃。
2.3 驱动侧怎么声明“我能认领谁”
驱动侧声明匹配关系的核心结构体是of_device_id。它的定义在include/linux/mod_devicetable.h里，其中最关键的两个字段是.compatible和.data：
static const struct of_device_id my_of_match[] = { { .compatible = "myvendor,mydevice", .data = &my_device_config }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, my_of_match);.data字段是一个 void 指针，可以指向一个配置结构体。这招在项目里非常实用：同一颗 SoC 的不同版本，或者同系列的不同芯片，如果寄存器布局稍有差异，你可以把差异化的配置数据放进去。probe 时通过of_match_device()拿到匹配到的条目，然后取出对应的配置指针，驱动代码里就可以针对不同硬件版本做不同初始化，而不需要写一堆 if-else 判断。
这里我自己的习惯是：哪怕只有一个设备型号，也会把配置结构体建起来，而不是把各种参数散落在驱动代码里。后期要支持同系列新芯片时，只需要添加一个of_device_id条目和一份配置数据，驱动的主体逻辑完全不用动。
3. i.MX6ULL 上的实操：从零写一个 Platform 驱动
3.1 先搭设备树节点
在 i.MX6ULL 上做 Platform 驱动开发，第一步往往不是写 C 代码，而是先改设备树。设备树是描述硬件资源的“数据文件”，驱动则是“处理逻辑”。只有设备树里先声明了设备，驱动才有了“猎物”。
假设我们要控制 i.MX6ULL 的一个 GPIO 作为 LED 指示灯，设备树节点可以这样写：
/ { myled { compatible = "myvendor,my-led"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_myled>; led-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>; status = "okay"; }; };这个节点挂在根节点/下，内核会把它注册为一个 platform device。.compatible是驱动的“身份证”，必须和驱动里of_match_table中的字符串保持一致。led-gpio是自定义属性名，用来传 GPIO 编号。pinctrl-names和pinctrl-0是 pinctrl 子系统的标准属性，驱动里不需要手动处理引脚复用，因为内核在 probe 之前会自动应用default状态下配置的引脚功能。
如果你不想自己定义 GPIO 属性名，也可以用标准的gpios属性。但我的经验是，在设备树里用带前缀的属性名（比如led-gpio）可读性更好，而且能避免和内核某些子系统默认解析的属性名冲突。
3.2 驱动骨架：probe 和 remove 是主角
Platform 驱动的主体框架其实就是一套模板，核心是struct platform_driver这个结构体。看代码：
#include <linux/module.h> #include <linux/platform_device.h> #include <linux/of.h> #include <linux/of_gpio.h> #include <linux/gpio/consumer.h> #include <linux/leds.h> static int my_led_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct gpio_desc *led_gpio; int ret; /* 从设备树获取 GPIO 描述符 */ led_gpio = devm_gpiod_get(dev, "led", GPIOD_OUT_LOW); if (IS_ERR(led_gpio)) { dev_err(dev, "failed to get led gpio, err = %ld\n", PTR_ERR(led_gpio)); return PTR_ERR(led_gpio); } gpiod_set_value(led_gpio, 1); dev_info(dev, "my led driver probed successfully\n"); return 0; } static void my_led_remove(struct platform_device *pdev) { struct device *dev = &pdev->dev; dev_info(dev, "my led driver removed\n"); } static const struct of_device_id my_led_of_match[] = { { .compatible = "myvendor,my-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, }, }; module_platform_driver(my_led_driver); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("i.MX6ULL Platform LED Driver");这段代码有几点值得展开说：
devm_gpiod_get()是 managed 版本 API。它申请的资源在驱动卸载或者 probe 失败时会自动释放，不需要手动gpiod_put()。这类devm_前缀的 API 在现代内核驱动里是主流做法，省去了一大堆错误处理路径。probe 函数里的
dev_err()、dev_info()是内核推荐的打印方式。它会自动把设备名带上，内核日志里能清楚地看到是哪条消息来自哪个设备，省得打印信息满天飞却不知道来自哪个驱动。module_platform_driver()是一个宏，它帮你把 module_init 和 module_exit 都定义好了。如果你的驱动不需要在 init 里做什么额外的事情，直接用这个宏最省事。如果需要额外的初始化逻辑，那就得手动写platform_driver_register()和platform_driver_unregister()。
3.3 编译验证与加载流程
在 i.MX6ULL 上编译驱动有两种常见方式：编进内核镜像，或者编成内核模块。调试阶段强烈建议编成模块（.ko文件），这样改代码后只需要重新编译模块并拷贝到板子上加载，不需要反复烧写整个内核镜像。
Makefile 的写法是 Linux 内核模块开发的标准套路：
obj-m := my_led.o KDIR := /path/to/your/kernel/source ARCH := arm CROSS_COMPILE := arm-linux-gnueabihf- all: $(MAKE) -C $(KDIR) M=$(PWD) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) cleanKDIR 指向你编译内核时使用的源码目录，注意要和板子上运行的内核版本保持一致。ARCH=arm和CROSS_COMPILE指定交叉编译工具链，这个要根据你的实际开发环境来。如果工具链路径不在默认搜索路径里，最好写全路径。
编译出my_led.ko后，传到板子上，依次执行：
insmod my_led.ko如果一切正常，内核日志里应该能看到my led driver probed successfully。然后可以用lsmod确认模块已加载，用rmmod my_led卸载模块，触发 remove 函数。
需要特别注意的是：如果设备树里没有对应的节点，insmod 不会报错，但 probe 函数也不会被调用。这是新手最容易困惑的地方。模块加载成功了，却感觉“什么都没发生”。这实际上说明了 Platform 模型的设计逻辑：驱动只是“报名参赛”，但如果没有对应的设备，它就只能等着。
3.4 通过 sysfs 验证匹配结果
Linux 内核的设备模型会在 sysfs 里把设备和驱动的匹配结果暴露出来。这些信息在调试时非常好用：
# 查看设备节点 ls /sys/bus/platform/devices/ # 查看驱动绑定的设备 ls /sys/bus/platform/drivers/my_led/ # 查看某个设备绑定的驱动 cat /sys/bus/platform/devices/myled/driver/name/sys/bus/platform/devices/ 下面会有一个名为myled的目录（设备树里节点的名字），进入后能看到driver这个符号链接。如果这个链接存在且指向你的驱动目录，就说明匹配成功、绑定关系已经建立。如果节点存在但 driver 链接不存在，说明设备注册了但没有驱动能匹配上。
还有一个非常有意思的调试手段：手动解绑和重新绑定。
# 解绑 echo myled > /sys/bus/platform/drivers/my_led/unbind # 重新绑定 echo myled > /sys/bus/platform/drivers/my_led/bind这在调试 probe 函数时太有用了。改一行代码、重新编译、拷到板子上、解绑再绑定，几秒钟就能验证一次，完全不用重启系统。
4. 设备树资源获取：驱动和硬件之间的数据通道
4.1 核心 API 与使用要点
probe 函数拿到struct platform_device *pdev后，最重要的事情就是从设备树里拿到硬件资源。i.MX6ULL 开发中，我用得最多的几个 API 是：
platform_get_resource()：获取 IO 内存地址、中断号、DMA 通道等标准资源。platform_get_irq()：专门获取中断号，返回值可以直接传给request_irq()。devm_ioremap_resource()：将物理地址映射为虚拟地址，同时检查资源是否合法。of_property_read_u32()/of_property_read_string()：读取自定义属性。devm_gpiod_get()/devm_clk_get()：获取 GPIO 和时钟。
这里要特别强调一下地址资源的处理。设备树里reg属性定义的是物理地址，CPU 不能直接访问物理地址，必须通过 MMU 页表映射成虚拟地址。devm_ioremap_resource()就是干这个的，而且它的错误处理做得比较好，会检查资源是否已经被占用、地址范围是否合法，失败时返回的错误码可以直接向上传递。
4.2 一个更完整的例子：带中断和寄存器的设备
为了演示资源获取的综合使用，我写了一个稍微复杂点的虚拟设备驱动。这个设备有一组寄存器（物理地址 0x020C0000，长度 0x1000），还有一个外部中断引脚。设备树节点这样描述：
mydevice: mydevice@020c0000 { compatible = "myvendor,my-device"; reg = <0x020c0000 0x1000>; interrupts = <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>; clocks = <&clks IMX6UL_CLK_UART4>; clock-names = "ipg"; status = "okay"; };驱动里获取资源的典型代码：
static int my_device_probe(struct platform_device *pdev) { struct resource *res; struct device *dev = &pdev->dev; void __iomem *base; int irq; struct clk *clk; int ret; /* 获取 IO 内存资源 */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); if (!res) { dev_err(dev, "failed to get memory resource\n"); return -ENODEV; } /* 请求并映射 IO 内存 */ base = devm_ioremap_resource(dev, res); if (IS_ERR(base)) { dev_err(dev, "failed to ioremap resource\n"); return PTR_ERR(base); } /* 获取中断号 */ irq = platform_get_irq(pdev, 0); if (irq < 0) { dev_err(dev, "failed to get irq\n"); return irq; } /* 获取时钟 */ clk = devm_clk_get(dev, "ipg"); if (IS_ERR(clk)) { dev_err(dev, "failed to get clock\n"); return PTR_ERR(clk); } ret = clk_prepare_enable(clk); if (ret) { dev_err(dev, "failed to enable clock\n"); return ret; } /* 读取设备寄存器，验证映射是否成功 */ u32 val = readl(base); dev_info(dev, "device reg value: 0x%08x\n", val); return 0; }这段代码有几点特别值得注意：
第一，devm_ioremap_resource()内部会先调用devm_request_mem_region()申请资源，再做映射。这意味着你不必手动release_mem_region()，remove 时资源会自动释放。如果你发现自己还在手动调用request_mem_region+ioremap+iounmap+release_mem_region这一整套，说明你用的 API 版本偏老，可以升级到 devm 系列了。
第二，中断号从设备树里读出来后，request_irq(irq, handler, IRQF_TRIGGER_NONE, "mydevice", dev_id)的第三个触发标志直接传 0 就好。因为设备树里interrupts属性已经声明了触发类型（IRQ_TYPE_LEVEL_HIGH），内核的中断控制器驱动在初始化时会根据这个配置好硬件寄存器，驱动里不需要重复设置。如果传了冲突的标志，反而可能导致中断无法触发。
第三，时钟的获取。i.MX6ULL 的每个外设都有自己的时钟门控，如果时钟没有打开，访问外设寄存器就会导致系统挂起（bus hang）。所以凡是设备树里声明了clocks属性的设备，驱动里一定要在访问硬件之前把时钟打开。
4.3 pinctrl 的自动处理机制
i.MX6ULL 的引脚复用是很多新手栽跟头的地方。GPIO 不工作、UART 没输出、I2C 读不到设备，排查到最后往往就是引脚复用没配置对。
在设备树里，pinctrl-0属性引用了 pin controller 子节点里的一段配置。内核在注册 platform device 时，如果发现设备树里有pinctrl-0属性，会自动去应用这段引脚配置。这个过程发生在驱动 probe 之前，也就是说你的 probe 函数被调用时，引脚已经配置成期望的功能了。
驱动代码里通常不需要显式去配置 pinctrl，除非你要在运行时动态切换引脚功能。i.MX6ULL 的设备树里，pinctrl 配置通常长这样：
&iomuxc { pinctrl_myled: myledgrp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x10B0 >; }; };MX6UL_PAD_GPIO1_IO03__GPIO1_IO03这个宏是 i.MX6ULL 特有的，它展开后是一个 32 位的值，包含引脚号和复用功能号。后面的0x10B0是引脚配置寄存器的值，包括上下拉、驱动强度、压摆率、HYS 等电气属性。
0x10B0 这个值不是随便写的。它的 bit 含义在 i.MX6ULL 参考手册的 IOMUXC 章节里有详细定义。在实际项目里，如果遇到信号质量不好（比如 I2C 波形边沿太缓、UART 通信有误码），就需要回头调整这个电气属性值。
5. 常见问题与排查技巧实录
5.1 compatible 写对了为什么还是匹配不上
这是我在 i.MX6ULL 开发中被问得最多的问题。设备树里 compatible 字符串和驱动of_match_table里的字符串明明一模一样，看代码逻辑也没问题，但 probe 就是没被调用，设备树节点也确认注册了。
排查这个问题的第一件事，是确认设备树里的节点有没有被内核正确解析。很多情况下，你改的是设备树源文件（.dts），但板子上实际运行的是编译后的.dtb。如果只改了源码没重新编译、没重新烧写 dtb，那一切都是白搭。
验证方法很简单：
# 在板子上查看当前使用的设备树 ls /proc/device-tree/如果myled节点在里面，说明设备树已经生效。还可以直接查看节点的 compatible 属性：
cat /proc/device-tree/myled/compatible正常会输出myvendor,my-led和一个空字节结尾。这里会看到一个比较隐蔽的问题：设备树编译工具dtc会在字符串数组的每个字符串后面自动加一个\0，cat命令显示的时候这点不明显，但如果你用 hexdump 查看，就能看到字符串后面确实有 00 结尾。这也就是为什么驱动里匹配用of_match_table时字符串不需要（也不能）带\0的原因，内核会自动处理。
如果确认设备树生效、compatible 一致但还是匹配不上，那就检查驱动模块是否真的加载成功。用dmesg | tail看看有没有加载错误。还有一种情况：驱动已经通过of_match_table匹配过一遍了，但因为某种原因 probe 失败，内核会把设备标记为“尝试过但失败”，后续再insmod的时候不会重新匹配。
碰到这种“僵尸状态”，最简单的做法是重启板子重新加载驱动。如果想避免这一层麻烦，就在设备树里把status属性设为"disabled"，等驱动真正就绪后再把它改为"okay"重新编译部署。
5.2 probe 进去了但 probe 内部报错怎么办
probe 里报错的情况五花八门，但我在 i.MX6ULL 上总结下来，高频出现的问题集中在三个方面。
GPIO 获取失败。要么是设备树里 GPIO 属性写法不对，要么是引脚已经被其他设备占用。内核会严格检查 GPIO 是否可用。一个非常典型的坑：i.MX6ULL 内部有些引脚是“共享”的，同一个引脚可以复用作多种功能。如果你在 pinctrl 里把它配成了 GPIO 功能，但设备树里又有另一个节点把这个引脚用作其它功能，就可能导致冲突。内核日志里会明确提示该 GPIO 已经被占用，这时翻 dmesg 就能看到。
时钟相关错误。devm_clk_get()返回-ENOENT通常有两个原因：设备树里clocks属性拼写的时钟名不对，或者对应的 clock 节点在设备树里被 disable 了。i.MX6ULL 的时钟树非常复杂，对外设时钟的引用一般通过&clks IMX6UL_CLK_XXX这种形式。这个宏定义在内核头文件里，如果设备树编译时找不到这个宏，说明编译环境的内核头文件版本和实际内核不匹配。
devm_ioremap_resource()返回-EBUSY。这说明物理地址区域已经被其他设备申请了。设备树里reg属性写的地址范围重叠了。检查一下有没有多个节点的 reg 指向了同一段物理内存。
调试心得：写 Platform 驱动时，我不太建议在每一步都用 BUG_ON 或者 panic，那样会把系统搞死，反而丢失了现场。更好的做法是每个失败分支都打一条
dev_err，打印返回值和预期值。出错后不要急着改代码，先翻 dmesg，大多数情况下硬件和内核已经把失败原因说得明明白白了。
5.3 模块加载成功但设备树里节点状态异常
有时候你会遇到“驱动加载了，设备树也看了，两者都对，但设备就是没反应”的情况。这时候别急着怀疑驱动逻辑，先回到设备树本身。
我遇到过的最令人抓狂的问题之一，是设备树里某个父节点被标记为status = "disabled"。比如你要用的 I2C 控制器节点，因为板级设计没有使用而被默认禁用了，你在它下面新建的子设备节点再怎么写，内核也不会去枚举它，因为父节点都处于 disabled 状态，子节点自然不会注册成 platform device。
还有一个容易被忽视的地方：某些老的设备树源文件里，GPIO 控制器、时钟控制器等基础节点也可能被错误地 added disabled 状态。i.MX6ULL 的内核设备树一般不会有这个问题，但从其他渠道拿到的设备树（比如别家 BSP 里导出的）就不好说了。
排查方法：
# 查看所有 platform 设备 ls /sys/bus/platform/devices/ # 过滤出你的目标设备 ls /sys/bus/platform/devices/ | grep myled如果设备列表里根本没有 myled 节点，说明设备树解析阶段就没把它注册为 platform device。这时候去检查父节点的status属性。还有一种情况：设备树节点的compatible属性本身合法但不匹配任何 platform 驱动注册表，这种情况设备还是会被注册，只是没有驱动绑定，表现就是前面说的“probe 没调用”。
5.4 中断号对不上：GIC SPI 与硬件中断号的换算
i.MX6ULL 使用 GIC（Generic Interrupt Controller）中断控制器。设备树里写中断号时，要区分GIC_SPI和GIC_PPI。SPI 是共享外设中断，PPI 是私有外设中断。
i.MX6ULL 参考手册里给出的中断号和设备树里写的不一定完全一样。手册里可能告诉你“UART4 的中断号是 34”，但设备树里要写GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH。这个 34 是 GIC 全局中断号。有些情况下你需要减去 32 或者做其他换算，具体要看 BSP 对中断控制器的封装。NXP 官方 BSP 里的设备树，这个值通常是直接可用的，但如果是从头移植内核，就要去核对arch/arm/boot/dts/imx6ull.dtsi里 interrupt controller 节点的配置了。
在驱动里拿到中断号后，Linux 实际使用的中断编号可能又经过了 irq domain 的映射，和物理中断号不是一个东西。所以调试时不要拿驱动里打印的 irq 值和参考手册里的中断号直接比对，那会让你绕一大圈。正确的方式是看/proc/interrupts里的编号。
cat /proc/interrupts这个文件会列出每个中断号对应的设备名和触发次数。如果驱动注册了中断但一直没触发，重点看记录次数是否在增长。如果增长说不断增长，说明是你的中断触发类型配置问题（电平触发和边沿触发搞混了）。
6. 从匹配机制到实际开发经验的几条总结
6.1 设备树才是真正的“上帝视角”
写到这，我想强调一个经验：Linux Platform 驱动框架虽然写起来像模板一样机械，真正考验人的反而是“信息从设备树到驱动”的链路顺畅程度。
在 i.MX6ULL 项目上，驱动代码本身往往就一两百行，把 probe 里面那一套流程走完就完事了。但设备树动辄几千行，点击、中断、时钟、引脚复用，每个环节都能成为问题源。你不光要会写 C 代码，还得能读懂 SoC 参考手册，理解芯片内部资源的分配逻辑。
所以我给团队新人的建议是：不要一上来就抄内里的例程改，花一个下午的时间把你手上的板子对应的完整设备树文件从头到尾翻一遍，搞清楚imx6ull.dtsi、板级 dts、iomuxc 节点、clks 节点之间的关系。这个功夫下完了，后面写驱动时犯错的概率能降一半。
6.2 开发调试时如何减少“试错循环”时间
我自己在 i.MX6ULL 上调试驱动时，有一套固定的高效流程。
第一，驱动的开发阶段坚决用模块方式加载，不要编进内核。编进内核带来的问题是，改一次代码就要重新编译整个内核，烧写镜像，启动系统，一个来回可能五分钟十分钟就没了。用模块方式，编译一次 .ko 只需要十几秒，然后 scp 到板子（或者用 NFS 挂载），insmod 就能验证。
第二，用好 sysfs 的手动绑定机制。前面已经提到过：
echo myled > /sys/bus/platform/drivers/my_led/unbind echo myled > /sys/bus/platform/drivers/my_led/bind这两个命令能省掉无数次重启。前提是你的驱动模块已经加载，而且设备树里节点存在。很多驱动问题不需要重启，解绑再绑定一次就能触发新的初始化流程。
第三，日志要及时打到位。probe 每个关键步骤的前后都打一条 dev_dbg 或 dev_info 级别的日志（具体用哪个取决于你当前的调试阶段）。等调试完了，再把多余的日志删掉或者降级为 dev_dbg。这样做的代价只是多敲几行代码，但回报是出错时能迅速定位问题发生的阶段。
6.3 匹配机制的扩展应用：实现多版本兼容
最后分享一个我在实际项目中用到过的技巧。由于of_device_id的.data字段可以挂任意指针，我们可以实现同一套驱动兼容多种硬件版本。
有一个实际案例：我做过一个网关设备，硬件有 V1.0 和 V2.0 两个版本。V1.0 用的音频编解码芯片是芯片 A，V2.0 换了芯片 B 但接口信号基本兼容。两个版本最大的差别是复位引脚 GPIO 编号和控制时序不同。
驱动里定义两个配置结构体：
static const struct codec_config codec_v1 = { .reset_gpio = 5, .needs_delay = true, }; static const struct codec_config codec_v2 = { .reset_gpio = 17, .needs_delay = false, }; static const struct of_device_id codec_of_match[] = { { .compatible = "myvendor,audio-codec-v1", .data = &codec_v1 }, { .compatible = "myvendor,audio-codec-v2", .data = &codec_v2 }, { /* sentinel */ } };probe 里通过of_match_device()取出匹配条目，再做类型转换：
const struct of_device_id *match; const struct codec_config *config; match = of_match_device(codec_of_match, dev); if (match && match->data) { config = (const struct codec_config *)match->data; gpio_set_value(config->reset_gpio, 0); if (config->needs_delay) usleep_range(10000, 20000); gpio_set_value(config->reset_gpio, 1); }这样驱动的主逻辑完全不用改，只需要在设备树里换一个 compatible 字符串，就能匹配不同的硬件版本。内核源码里大量使用这种模式，比如 NXP 的 fec 网络驱动、dwc2 USB 驱动等，都是这种思路。掌握了这个套路，你在面对板级差异时就不会手忙脚乱了。
Platform 驱动模型的匹配机制，说到底就是设备树和 C 结构体之间的一场“对暗号”。i.MX6ULL 这类嵌入式 SoC 上，设备树是硬件留给人看的“说明书”，驱动则是人写给内核的“处理规则”。compatible 就是暗号，of_match_table就是暗号表，对上号，probe 走起；对不上，一切免谈。
我见过太多人在这个模型上栽跟头，绕来绕去，最后发现不是驱动写得不对，而是设备树和驱动代码里的字符串差了那么一个字母。调试技巧再花哨，也不如写代码时多核对一眼 compatible 是否一致来得实在。做嵌入式驱动开发，稳扎稳打比炫技重要得多。希望这篇文章能帮你少走一些弯路，把 Linux 设备模型这块地基打得扎实一些。
