企业官网建设流程全解析

1. 从零认识i.MX6ULL的Platform机制

1.1 为什么驱动开发绕不开Platform总线

做嵌入式Linux开发的人都有体会，GPU、VPU、Codec这些复杂外设驱动难啃，但真正卡住新手的往往是基础框架——设备是怎么找到驱动的？驱动又是怎么知道该初始化谁的？在i.MX6ULL这颗Cortex-A7内核的MPU上，答案几乎都指向同一个东西：Platform总线。

我最早接触i.MX6ULL时，第一反应是翻芯片手册看寄存器、搞GPIO、调时钟，结果写出来的驱动要么insmod时报“Device or resource busy”，要么probe函数压根不执行。后来才明白，Linux内核从设备树（Device Tree）时代开始，硬件描述和驱动代码已经彻底分离，而Platform总线就是连接两者的桥梁。简单说，设备树里写的每个节点是“硬件清单”，Platform驱动就是“服务程序”，总线负责把清单里的每一项派发给对应的服务程序去处理。

那有人会问，传统写法里直接把硬件地址写死在驱动里不行吗？行，但仅限于你一个人玩。一旦要换板子换引脚、换Flash型号、换外设配置，改驱动重新编译就变成噩梦。Platform机制的意义在于：驱动代码只关心“我负责哪类设备”，具体硬件参数从设备树里解析，一套驱动源码可以适配多种板卡，这正是i.MX6ULL开发中最关键的工程化思维。

1.2 i.MX6ULL平台上Platform的典型应用场景

i.MX6ULL这颗芯片定位是低成本、低功耗的工业级应用处理器，常见于IoT网关、HMI人机界面、工业控制板等场景。它的外设资源非常丰富，比如I2C、SPI、UART、PWM、ADC、LCD控制器、以太网MAC等，而这些外设在Linux内核里大多数都是通过Platform驱动来管理的。

以GPIO为例，i.MX6ULL的GPIO控制器本身是一个Platform设备，设备树里会有类似gpio-controller@0209c000的节点，对应驱动是gpio-mxc.c。当你写一个LED驱动或者按键驱动时，用的不是直接操作寄存器，而是通过GPIO子系统API去控制。这个过程中，你的驱动也会注册成一个Platform驱动，设备树里再加一个自定义节点，描述LED接在哪个引脚、默认电平是什么。一旦设备树节点和驱动匹配成功，probe函数自动调用，你在probe里申请GPIO、注册字符设备、创建sysfs接口，一切都顺理成章。

可以说，i.MX6ULL上几乎80%以上的外设驱动都属于Platform驱动框架，无论你是写简单的GPIO输入输出，还是挂一个外部I2C传感器芯片，都离不开这套匹配机制。掌握它，等于拿到了嵌入式Linux驱动开发的第一把钥匙。

2. 深入拆解Platform设备与驱动的匹配原理

2.1 匹配机制的核心逻辑：谁在找谁

Platform总线的工作方式可以类比成“房屋中介”。设备（Device）是房主，他要出租房子；驱动（Driver）是租客，他要找房子住。中介手里有两份名单，房主登记了房源信息（设备树节点），租客登记了需求信息（驱动支持的设备列表）。一旦某个房源信息符合租客的需求，中介就撮合双方签约（调用probe函数）。

在Linux内核源码中，这条总线的匹配操作在drivers/base/platform.c的platform_match()函数里完成。每次系统启动时，内核会遍历注册到Platform总线上的所有设备和所有驱动，逐一调用platform_match()判断是否匹配。判断顺序依次是：

1. of_match_table匹配：如果驱动里定义了of_match_table，就与设备树节点的compatible属性进行匹配。
2. ACPI匹配：ACPI是x86平台常用的高级配置与电源接口标准，ARM平台基本用不到，但内核也保留了这个匹配分支。
3. id_table匹配：如果驱动定义了id_table，就与设备的name字段进行匹配。
4. 平台驱动名称匹配：如果驱动名称与设备名称完全一致，也算匹配成功。

把这四种匹配方式搞清楚，你就能理解为什么有时候驱动烧进去没反应，多半是这四种方式一个都没对上。

2.2 匹配顺序与设备树compatible属性的关系

实际i.MX6ULL开发中，90%的场景用的都是第一种：of_match_table匹配设备树compatible属性。这是设备树体系下的标准做法，也是我推荐新手优先掌握的。

设备树节点中常见这样的写法：

led_test { compatible = "mycompany,led-test"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_led>; led-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>; status = "okay"; };

驱动侧对应注册方式：

static const struct of_device_id led_test_of_match[] = { { .compatible = "mycompany,led-test" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, led_test_of_match); static struct platform_driver led_test_driver = { .probe = led_test_probe, .remove = led_test_remove, .driver = { .name = "led_test", .of_match_table = led_test_of_match, }, }; module_platform_driver(led_test_driver);

这里的compatible字符串是全系统唯一的标识，类似身份证号。设备树节点说“我是mycompany,led-test”，驱动声明“我支持mycompany,led-test”，两边对上，内核就把设备和驱动绑定，probe函数随即被调用。

需要注意，compatible的命名规范是“厂商名,设备型号”或者“厂商名,设备类别”，中间用逗号隔开，但逗号前后不能有空格。我在实际工作中遇到过因为多打了一个空格导致匹配失败的情况，排查了很久才找到问题，这种细节极其坑人。

2.3 of_match_table与MODULE_DEVICE_TABLE的作用

很多新手会疑惑：of_match_table已经定义了支持列表，为什么还要加MODULE_DEVICE_TABLE？这行宏的作用是，当你把驱动编译成模块（.ko文件）时，它会把of_match_table里的信息导出到模块的.modinfo段中。这样做的意义有两点：

第一，系统热插拔时，udev等机制可以读取模块的别名信息，自动加载对应的驱动模块。假如你插入一个USB转串口设备，内核或者udev看到设备信息后，要确定加载哪个驱动，就需要通过模块别名来寻找。

第二，它让内核的模块自动加载机制成为可能。如果你的平台启动脚本不支持完整udev，可能感受不明显，但在完整桌面Linux系统上，这一行直接决定了modprobe能不能找到正确的驱动。

还有一个容易忽略的小知识点：of_device_id结构体末尾必须有一个全零的哨兵项，我常常用{ /* sentinel */ }来标识。这个哨兵项不是可选项，而是必须项。因为内核在使用这个数组时没有显式的长度参数，它靠哨兵项来判断数组是否结束。如果漏了哨兵项，内核就会越界数组读取不确定的内容，轻则匹配失败，重则内核崩溃。

3. 五种匹配方式深度对比：从could到实际选择

3.1 name字段、id_table和of_match_table的优先级

有时候你会看到老的Linux驱动教材里，Platform驱动匹配用的是id_table。比如：

static struct platform_device_id led_test_ids[] = { { .name = "my-led", }, { } }; static struct platform_driver led_test_driver = { .probe = led_test_probe, .driver = { .name = "my-led", }, .id_table = led_test_ids, };

这种写法的匹配依据是设备注册时的名称。在没有设备树的年代，嵌入式Linux驱动开发就是通过platform_device_register()在代码里硬注册平台设备，设备名写在C文件里，驱动名写在另一个C文件里，两边一致即可。这种方式的问题是硬编码，设备信息没有独立出来，不便于复用，也不利于产品系列化开发。

而of_match_table是从设备树时代开始主推的方式。因为设备树的compatible属性天然就是一个“表”，同一个驱动可以支持多种兼容设备。比如一个LCD驱动，可以同时声明支持：

static const struct of_device_id my_lcd_of_match[] = { { .compatible = "mycompany,lcd480" }, { .compatible = "mycompany,lcd800" }, { .compatible = "mycompany,lcd1024" }, { /* sentinel */ } };

这样一套驱动代码就能兼容三种分辨率的屏，设备树里写成哪种，probe里通过of_device_is_compatible()等API做分支处理就行了。这是id_table方案完全做不到的。

从优先级来说，内核的platform_match()函数依次执行上述四种判断，只要前一种匹配成功，直接返回匹配结果，不再继续后续流程。因此，如果你的驱动同时配置了of_match_table和id_table，设备树节点上的compatible会优先生效。我建议在新项目里统一用of_match_table，老代码里如果既有设备树又有传统平台设备注册，才需要关注id_table。

3.2 匹配失败时如何排查是设备还是驱动的问题

匹配失败是嵌入式驱动开发中最常见的卡壳点，而且表现很迷惑：insmod执行了没报错，但probe就是不跑；或者probe跑了一半就退出了，各种报错混杂在一起。根据我的经验，系统地从设备侧和驱动侧分开排查，效率最高。

设备侧排查：

• 确认设备树节点是否真的被编译进内核。用fdtdump或者dtc工具反编译dtb文件，找到你的节点。
• 确认节点status属性是否为“okay”。默认情况如果没有写status属性，设备也是使能的，但如果写了“disabled”，即使compatible匹配了也不会probe。
• 确认设备树节点中的compatible字符串是否有隐藏字符。建议用十六进制查看确认。

驱动侧排查：

• 确认驱动有没有被编译进内核或正确加载。如果是模块方式，先depmod更新依赖，再modprobe加载。
• 在of_match_table前后加打印，确认probe到底有没有被调用。
• 检查驱动的.name是否与系统内其他驱动冲突。同一总线上，驱动名称相同会导致注册失败。

如果设备树和驱动看起来都没问题，还有一种可能性：设备没有被注册到Platform总线上。比如你的设备树节点挂在某个I2C控制器的子节点下，而I2C控制器本身没有正确枚举，那么子设备就不会被创建。这种间接依赖问题，需要往父设备的probe方向排查。

3.3 匹配成功之后发生了什么：probe到remove的完整生命周期

匹配成功只是开始。probe函数执行成功后，设备和驱动进入绑定状态。我建议新手把整个生命周期在心里画出一条线：设备树解析→匹配→probe→驱动业务初始化→设备使用→remove→资源释放。

probe函数里通常会做以下几件事：

static int led_test_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct led_test_priv *priv; struct gpio_desc *desc; int ret; priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; desc = devm_gpiod_get(dev, "led", GPIOD_OUT_LOW); if (IS_ERR(desc)) { dev_err(dev, "failed to get led gpio\n"); return PTR_ERR(desc); } priv->desc = desc; ret = misc_register(&priv->miscdev); if (ret) { dev_err(dev, "failed to register misc device\n"); return ret; } platform_set_drvdata(pdev, priv); return 0; }

代码里出现了devm_前缀的API，这是一个非常重要的经验。devm是“device managed”的缩写，意思是资源随设备生命周期自动管理，不需要在remove里手动释放。比如devm_kzalloc分配的内存，设备卸载时内核自动释放；devm_gpiod_get申请的GPIO，设备解绑时会自动释放。这能显著减少内存泄漏和资源泄漏问题。早期的驱动写法是手动kfree、gpio_free、misc_deregister，一旦某个分支忘记释放，问题就埋伏下了。

remove函数相对简单，核心就是做清理。用了devm_系列函数之后，remove里往往只需要注销主设备号、删除cdev或misc设备，其余交给内核。

这里我踩过一个很大的坑：在probe里用了request_irq申请中断，但没注意devm_request_irq也一样有托管版本。后来出现模块反复加载卸载后，中断无法再次申请的问题。换用devm_request_irq之后，这类问题彻底消失。教训就是：能用devm_就用devm_，别让手动清理负担过重。

4. 手写一个完整的i.MX6ULL Platform LED驱动

4.1 设备树节点的完整编写

以正点原子或野火的i.MX6ULL开发板为例，使用GPIO1_IO03控制一个LED，完整设备树节点如下：

&iomuxc { pinctrl_led: ledgrp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x10b0 >; }; }; led_test { compatible = "mycompany,led-test"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_led>; led-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>; status = "okay"; };

节点led_test是顶层节点，它引用了pinctrl_led这个pinmux配置组。0x10b0是IOMUX控制寄存器里的配置值，包含了上下拉、驱动能力、施密特触发器等参数。这里的&gpio1 3表示GPIO1组的第3号引脚，对应GPIO1_IO03。GPIO_ACTIVE_LOW告诉内核这个LED是低电平点亮，后面驱动代码里用gpiod_set_value输出1时，硬件电平实际是0。

有一点要特别提醒：MX6UL_PAD_GPIO1_IO03__GPIO1_IO03这样的宏定义来自NXP提供的imx6ul-pinfunc.h头文件，它把引脚的mux mode和寄存器的偏移地址定义好了。如果你移植到自己的板卡，要根据原理图确认每个外设复用到哪个引脚，选对mux mode，否则硬件不工作。

4.2 驱动侧代码框架与实现细节

驱动代码可以非常简洁，核心结构如下：

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/gpio/consumer.h> #include <linux/miscdevice.h> #include <linux/uaccess.h> #include <linux/of.h> #include <linux/of_gpio.h> struct led_test_priv { struct gpio_desc *led_gpio; struct miscdevice miscdev; }; static ssize_t led_test_read(struct file *file, char __user *buf, size_t count, loff_t *ppos) { // 简化处理：返回当前LED亮灭状态 return 0; } static ssize_t led_test_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { struct led_test_priv *priv = file->private_data; char kbuf[8] = {0}; int val; if (copy_from_user(kbuf, buf, min(count, sizeof(kbuf)-1))) return -EFAULT; if (kstrtoint(kbuf, 10, &val)) return -EINVAL; gpiod_set_value(priv->led_gpio, val); return count; } static int led_test_open(struct inode *inode, struct file *file) { struct led_test_priv *priv = container_of(inode->i_cdev, struct led_test_priv, miscdev); file->private_data = priv; return 0; } static const struct file_operations led_test_fops = { .owner = THIS_MODULE, .open = led_test_open, .read = led_test_read, .write = led_test_write, }; static int led_test_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; struct led_test_priv *priv; int ret; priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; priv->led_gpio = devm_gpiod_get(dev, "led", GPIOD_OUT_LOW); if (IS_ERR(priv->led_gpio)) return PTR_ERR(priv->led_gpio); priv->miscdev.minor = MISC_DYNAMIC_MINOR; priv->miscdev.name = "led_test"; priv->miscdev.fops = &led_test_fops; ret = misc_register(&priv->miscdev); if (ret) return ret; platform_set_drvdata(pdev, priv); dev_info(dev, "led test probed\n"); return 0; } static int led_test_remove(struct platform_device *pdev) { misc_deregister(&pdev->dev.platform_data); return 0; } static const struct of_device_id led_test_of_match[] = { { .compatible = "mycompany,led-test" }, { /* sentinel */ } }; MODULE_DEVICE_TABLE(of, led_test_of_match); static struct platform_driver led_test_driver = { .probe = led_test_probe, .remove = led_test_remove, .driver = { .name = "led_test", .of_match_table = led_test_of_match, }, }; module_platform_driver(led_test_driver); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("i.MX6ULL Platform LED Test Driver");

4.3 关键API与参数为什么这么选

代码里有几个API的选择值得展开说。

devm_gpiod_get的第二个参数是"led"，它会解析设备树节点中的led-gpio属性。为什么名字正好能对应上？原因是devm_gpiod_get(dev, "led", ...)会查找节点下名为led-gpio的属性。gpiod消费类API的函数名后缀和属性名的关系是：去掉-gpio或-gpios后缀后剩下的部分就是API里的conid参数。这里我们用"led"对应led-gpio，如果你在设备树里写power-gpio，API里就要写"power"。

misc_register是Linux内核中用来注册杂项设备的最简单方式，主设备号固定为10，次设备号动态分配。这个API非常适合字符设备比较简单的场景，不需要手动分配主设备号，也不需要创建cdev和device_create等一系列操作，大大简化了代码。

GPIOD_OUT_LOW表示初始化GPIO方向为输出，并输出低电平。这个参数和GPIO_ACTIVE_LOW组合在一起时，语义上有一点绕：设备树里声明了这个GPIO是低有效，那么GPIOD_OUT_LOW逻辑上表示“输出0”，反映到物理引脚上就是高电平。如果板子上LED是低电平点亮，这个状态下LED是灭的。新手容易在这里被绕晕。我的建议是记住：gpiod系列API操作的是逻辑电平，不是物理电平。有效电平的关系已经由设备树属性帮你处理了。

4.4 编译和加载验证的完整流程

在i.MX6ULL的Linux内核源码树中，把驱动文件放到drivers/misc/目录下，并修改drivers/misc/Makefile：

obj-$(CONFIG_LED_TEST) += led_test.o

在drivers/misc/Kconfig中添加：

config LED_TEST tristate "i.MX6ULL Platform LED test driver" depends on OF help This is a simple platform LED test driver for i.MX6ULL.

然后在内核配置界面里选中这个驱动，可以编成模块（M）或者直接编进内核（Y）。推荐先编成模块，方便反复加载测试。

在开发板上操作：

# 将内核和dtb更新到开发板 # 加载模块 insmod led_test.ko # 查看驱动是否绑定设备 ls /sys/bus/platform/drivers/led_test/ # 查看设备是否匹配成功 cat /sys/bus/platform/drivers/led_test/led_test # 控制LED点亮 echo 1 > /dev/led_test # 控制LED熄灭 echo 0 > /dev/led_test # 卸载模块 rmmod led_test

如果在/sys/bus/platform/drivers/led_test/目录下能看到设备名称的软链接，就说明匹配成功，probe已经被执行过。如果看不到，则需要按第三节的方法排查。

我强烈建议在调试阶段打开内核的CONFIG_DYNAMIC_DEBUG功能，然后动态开启dev_dbg打印：

echo 'file led_test.c +p' > /sys/kernel/debug/dynamic_debug/control

这种调试方式可以在系统运行期间灵活开启和关闭打印，完全不需要重新编译内核，非常实用。我的经验是，写驱动时多用dev_dbg和dev_info，不要只依赖printk，因为动态调试的灵活性能节省大量重新编译的时间。

5. 匹配常见问题排查与避坑指南

5.1 遇到最多的匹配失败原因

我整理了日常开发中最高频的几种匹配失败原因，做成速查表，方便你快速定位：

很多刚入门的开发者习惯在驱动里堆printk，然后重新编译、烧录、运行、看串口日志。这套流程在简单场景下没问题，但一旦驱动复杂起来，每加一个打印都要重新编译，效率极低。

Linux内核提供了完善的动态调试框架，使用pr_debug、dev_dbg替代printk，配合动态调试控制接口，可以在系统运行期间决定哪些打印要输出、哪些不要。

具体操作步骤：

# 在启动参数中加上dyndbg="file led_test.c +p" # 或者系统起来之后动态开启 echo 'module led_test +p' > /sys/kernel/debug/dynamic_debug/control

这样，只有led_test模块相关的调试打印会被输出，其他模块的pr_debug仍然静默，日志干净又精准。这套方法在内核代码量大的项目里尤其好用。

5.3 资源泄漏与devm机制的使用边界

前面多次提到devm_系列API，但很多新手没理解它的边界。devm_不仅仅服务于Platform设备，它几乎适用于所有基于struct device的内核子系统，比如I2C客户端设备、SPI设备、PCI设备等。只要你能拿到一个struct device *指针，就可以使用对应的devm_函数。

但有一点必须注意：devm_管理的是设备生命周期内的资源，如果设备一直存在，这些资源就不会释放。这也是为什么大多数驱动里，申请的中断、GPIO、DMA缓冲、时钟全部用devm_，但设备节点或某些需要在设备移除前主动关闭的业务资源，仍然需要手动管理。

举个例子，你在probe里注册了一个input_dev，用devm_input_allocate_device分配内存，但如果后续某个初始化步骤失败需要回滚，你不能只靠devm_延迟释放，因为此时可能还有其他模块引用了这个input设备。合理的做法是在probe的错误分支里调用input_unregister_device，然后让devm_处理最终释放。

5.4 从dts文件到sysfs：验证匹配链路的最快捷径

当你想快速验证自己的驱动和设备树是否正确匹配，不用每次写一堆用户态测试程序，直接看sysfs里的信息是最直观的。

ls /sys/bus/platform/devices/

这个目录下列出了所有注册到Platform总线上的设备。找到你的设备名，比如led_test，然后：

ls -l /sys/bus/platform/devices/led_test/driver

如果driver有指向驱动的符号链接，说明设备和驱动已经完成绑定。再看：

cat /sys/bus/platform/devices/led_test/of_node/compatible

这会直接输出设备树节点里的compatible字符串。你可以和驱动中of_match_table里的字符串逐字符对比，一眼看出问题。

这套基于sysfs的验证路径不需要写代码、不需要编译，非常适合快速定位匹配相关问题，我把它作为排查流程的第一站。

6. 从Platform机制到字符设备框架的一体化设计

6.1 为什么要同时掌握Platform和字符设备框架

很多驱动初学者问：我是不是只需要学会Platform匹配，就能写出完整驱动了？其实还不够。Platform机制解决的是“设备和驱动如何绑定”的问题，但驱动本身对外提供的功能接口，通常还要借助字符设备框架来实现，比如读写、控制、打开关闭等操作。

最典型的例子就是LED驱动。通过Platform机制让驱动找到设备树中的LED引脚信息，然后通过字符设备提供/dev/led_test节点，用户程序往节点里写1或0就能控制灯亮灭。这两件事是一个驱动里不可分割的两半。

所以我的建议是：不要把Platform机制当成孤立知识点，它是整个驱动开发流程的骨架。配齐了骨架，才能在上面长肉——字符设备是肉，平台驱动是骨架，设备树是灵魂。

6.2 一个完整驱动的分层结构

从工程化角度看，我会把一个完整Linux驱动拆成三层：

• 设备树层：描述硬件资源，比如GPIO管脚、中断号、时钟频率、DMA通道等。
• 平台驱动层：负责匹配硬件设备和驱动代码，在probe里初始化硬件资源，在remove里做清理。
• 业务功能层：通过字符设备、netlink、sysfs、proc等接口向用户空间提供服务。

这种分层设计的好处是，每一层独立可测。设备树可以用dtc反编译验证语法；平台驱动可以只测试match和probe是否执行；业务功能层可以用用户态程序单独打点测试。

我在做项目时，通常先把底层资源全部在probe里调通，打印出资源信息，确认无误后再往上写业务逻辑。这样可以避免把硬件问题、匹配问题和业务逻辑问题混在一起排查，省下大量时间。

6.3 未来扩展：设备树叠加层与驱动热插拔

当你掌握了基础的Platform驱动开发后，可以再研究一下设备树叠加层（Device Tree Overlay）的用法。i.MX6ULL本身不支持设备树热插拔的标准用法那么丰富，但这个能力在树莓派等平台上已经非常成熟，而且NXP的Yocto BSP也开始支持overlay机制。

设备树叠加层的核心价值在于，不用重新编译整个设备树，只需在系统运行期间动态加载一个overlay dtbo文件，就能让新的platform设备出现，进而触发对应的驱动probe。这在产品需要灵活配置不同外设的场合非常有用，比如同一块主板可选配不同型号的触摸屏、传感器模块，每种选配对应一个overlay文件，系统起来后按配置加载即可。

另外，内核的driver_override机制也值得了解。在sysfs里，你可以强制指定一个平台设备使用某个驱动：

echo my_driver > /sys/bus/platform/devices/led_test/driver_override echo led_test > /sys/bus/platform/drivers/led_test/bind

这在调试多个驱动同时声明支持同一设备时特别有用，可以快速切换验证。

7. 总结：把Platform匹配机制内化成肌肉记忆

说实话，我第一次接触Platform设备与驱动匹配机制时，也被那一堆结构体、回调函数搞得很懵。但随着项目推进，我越来越发现，这套机制本质上是一种“声明式编程”的思维：我把硬件资源声明在设备树里，把能力声明在驱动里，剩下的事情交给内核总线框架去协调。

这套机制的好处在于，不管厂商的BSP怎么升级，设备树怎么改，驱动代码的相对稳定性都很高。我在不同i.MX6ULL板卡之间移植驱动时，往往只需要修改设备树，驱动代码改动量很小，甚至完全不动。这种模式带来的工程效率提升，可以说是肉眼可见的。

如果你正在学习i.MX6ULL或者类似的ARM Linux平台驱动开发，我强烈建议你用一块实际开发板，从最简单的LED驱动开始，走一遍设备树编写、驱动编写、编译加载、sysfs验证的完整流程。一次跑通，后续再做复杂外设驱动时，你对整个系统的理解会完全不同。

最后再分享一个小技巧：遇到匹配不上的问题，永远先查设备树是否生效，再查compatible是否一致，最后查资源和驱动代码逻辑。按照这个顺序排查，通常能少走很多弯路。