企业官网建设流程全解析

做i.MX6ULL的Linux驱动开发，很多人第一次接触Platform总线时都是一头雾水：明明照着教程写完了一个platform_driver，insmod也成功了，但probe函数就是不执行，设备号也申请不到，折腾一整天最后发现是设备树里compatible字段和驱动里的of_match_table没有对上。这个坑我踩过，带过的不少新同事也踩过，所以我想把i.MX6ULL平台下这套设备与驱动匹配机制彻底讲透，从内核为什么要搞Platform这一套东西，到匹配流程内部到底发生了什么事，再到怎么自己写一个能被正常probe的驱动、怎么排查匹配失败的问题，一次说清楚。

这篇文章适合正在学嵌入式Linux驱动开发、尤其是用i.MX6ULL或者类似Cortex-A7核心板做项目的朋友阅读，不管你是刚看完字符设备驱动、准备往设备树和Platform模型过渡，还是已经写了不少驱动但一直没认真搞明白匹配原理，都能从里面得到能直接拿去用的东西。

1. 先搞清楚：Platform机制到底解决了什么问题

1.1 早期字符设备驱动写法为什么撑不住了

咱们先把时间拉回到Linux 2.6之前。早期写驱动，最常见的方式就是把板子上的硬件资源写死在驱动代码里。比如你要操作一个LED对应的GPIO寄存器，直接在驱动里硬编码物理地址，ioremap之后对着寄存器地址写值；如果要注册一个中断，也是直接写死中断号。这种方式在嵌入式开发早期确实简单粗暴能用，但问题很快就暴露出来了。

首先是资源冲突。同一个芯片可能被用在几十种板卡上，A板子LED接在GPIO1_IO03，B板子LED接在GPIO1_IO05，同一份驱动代码在两块板子上就没法通用。其次是设备变更带来的维护地狱，硬件工程师说改一下引脚连接，驱动开发就得跟着改源码重新编译，版本管理一混乱，哪天改错了哪个地址，排查起来极其痛苦。

这就引出了Linux设备模型里最重要的思路：驱动是驱动，设备是设备，两者分开维护，通过一种统一的机制在运行时完成匹配和绑定。驱动只负责描述“我能操作什么类型的外设、怎么操作”，设备则描述“这块板子上实际有哪些外设、外设的资源（寄存器地址、中断号、GPIO等）在哪里”。谁也不要写死谁。

1.2 总线、设备、驱动三角色如何分工

Linux为了解决上面的问题，抽象出了总线（bus）、设备（device）、驱动（driver）三个角色。PCI设备有PCI总线，USB设备有USB总线，它们都是真实存在的物理总线，设备和驱动都挂在这种总线上，由总线子系统负责匹配。

问题来了，SoC内部的很多外设控制器，比如I2C控制器、SPI控制器、UART、GPIO控制器、以太网MAC，它们并不是挂在PCI或者USB这种物理枚举总线上面的。系统启动时，这些设备是固定存在的，不需要像USB设备那样去扫描发现。为了让这些“天生就存在”的片上外设也能套用总线-设备-驱动模型，内核提供了一个虚拟总线，叫platform_bus，也就是咱们常说的Platform总线。

Platform总线上挂的“设备”，叫platform_device，可以是芯片内部集成的外设控制器，也可以是指定为platform_device的外部设备。在Device Tree（设备树）普及之后，内核在启动阶段会解析设备树，把其中匹配到的节点一个一个转换成platform_device，挂到platform总线上。驱动这边，只要你写的是platform_driver，注册时就会挂到同一条虚拟总线上。

总线负责撮合：新来了一个platform_device，总线就去看看现有的platform_driver有没有能匹配上它的；新注册了一个platform_driver，总线又会反过来扫描现有的platform_device。一旦匹配成功，总线就会调用driver里的probe函数，把设备相关的资源信息交给你，你的驱动从这一刻才开始真正初始化硬件。

1.3 i.MX6ULL上哪些资源依赖这套机制

i.MX6ULL是NXP基于Cortex-A7内核设计的低功耗应用处理器，内部集成了大量的外设控制器。可以这么说，除了内存控制器等极少数基础组件，芯片上几乎你能用到的所有外设控制器，在Linux内核里都是以platform_device的形式存在或者由设备树节点转换而来的。

举个例子你就会明白：设备树里经常看到类似这样的节点：

&i2c1 { clock-frequency = <100000>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_i2c1>; status = "okay"; };

这个i2c1节点在内核启动阶段会被转换成platform_device，然后去匹配I2C控制器驱动里的platform_driver，匹配成功进入probe之后，驱动才会去初始化i2c适配器、注册i2c总线。之后再发现挂在这条i2c总线上的客户端设备，就又是另一套i2c_client的匹配逻辑了。

搞懂这个流程，你就能明白为什么很多时候我们给某个外设控制器写驱动，第一个函数入口不是file_operations里的open/release，而是probe函数。因为你的驱动首先要被“系统认识”，通过Platform匹配机制绑定到对应设备上，才有资格去操作硬件资源。

2. 匹配机制全解析：一条probe是怎么被叫醒的

2.1 驱动和设备在什么时机相互打量

一个platform_driver从注册到它的probe被调用，中间经历的过程非常关键。很多人只知道写驱动时要注册platform_driver，但不知道probe调用的完整时机。

当你在驱动里调用platform_driver_register的时候，内核会把driver挂到platform_bus_type这根虚拟总线上，然后立刻执行一次总线对已有设备的扫描。内核会遍历platform bus上所有的device，对每一个设备调用platform_match函数，看看你的driver跟哪个设备能配对。只要找到一个配对的设备，立刻执行probe。

反过来，设备是怎么来的？有两种常见来源。传统方式是通过platform_device_register主动注册，平台代码里构造platform_device结构体然后塞给内核，这在老内核或者不使用设备树的场景中很常见。现在的主流方式则是设备树：内核在启动时用of_platform_default_populate_init遍历设备树根节点下的所有节点，把 compatible 属性匹配的节点变成platform_device，随后扫描驱动列表完成匹配。

所以probe被调用的时机其实有两种典型场景：

• 如果你先加载驱动，后注册设备（比如设备树节点本来就在，但驱动是后面insmod的），那么在platform_driver_register内部扫描设备时就会触发probe。
• 如果设备在你驱动的probe执行过程中又创建了子设备，比如MFD（多功能设备）驱动创建子平台设备，那是设备注册时反向扫描驱动触发probe。

理解这个双向扫描逻辑，后面排查“为什么probe没跑”时就能有个清晰的方向：到底是设备始终没被创建，还是设备与驱动的匹配条件不满足。

2.2 内核源码里platform_match的匹配顺序

要真正理解匹配机制，不能只看概念，我建议你打开内核源码里drivers/base/platform.c，找到platform_match函数。不同内核版本可能会有细微差别，但核心逻辑基本稳定。整个匹配过程大概分这么几步：

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

需要注意的是，在没有使能ACPI的嵌入式ARM平台上，第二步通常不会生效，关键的匹配路径就是设备树compatible匹配、id_table匹配和名字匹配三路。

最初级的匹配方法是驱动程序名和设备名相同。早期platform驱动在driver结构体和platform_device结构体的name字段直接保持一致即可。这种匹配路线现在仍然存在，但更多是兜底逻辑。设备树普及之后，绝大多数场景走的是第一条of_driver_match_device。

设备树匹配的核心是compatible属性。设备树里的每个节点，只要是代表一个真实的设备，基本都要写compatible属性。比如某个外设节点长得这样：

mydevice: mydevice@020c406c { compatible = "myvendor,mydevice"; reg = <0x020c406c 0x4>; ... };

驱动侧就要在of_device_id数组里提供一个同样的compatible字符串：

static const struct of_device_id mydevice_of_match[] = { { .compatible = "myvendor,mydevice", }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, mydevice_of_match); static struct platform_driver mydevice_driver = { .probe = mydevice_probe, .remove = mydevice_remove, .driver = { .name = "mydevice", .of_match_table = mydevice_of_match, }, }; module_platform_driver(mydevice_driver);

匹配时，内核拿设备树节点的compatible属性字符串和of_match_table数组里所有compatible字段逐一比较，只要有一个相等，就算匹配成功。

2.3 of_device_id里藏的小秘密：data指针

很多基础教程在讲of_device_id时，只强调compatible字段必须对齐，却忽略了一个很实用的字段：data。我在这儿重点说一下。

of_device_id结构体的data成员是一个void指针，用于在驱动侧携带与某个compatible关联的私有数据。比如同一颗芯片上可能有多个功能相近但寄存器细节不同的IP核，驱动里可以共用同一个probe函数，但在of_device_id里通过data来区分IP版本，probe时用of_match_device取出当前匹配到的of_device_id，然后强转data拿到不同的硬件信息。

我给你一个实际场景。假设板子上有两个LED控制器，一个老版本寄存器地址偏移不同，一个新版本，两者的compatible分别是“myvendor,led-v1”和“myvendor,led-v2”。如果用两套of_match_table分别写两个驱动，显然很蠢。更聪明的做法是一个驱动，of_match_table里放两个条目，data分别指向不同的led_hw_cfg结构体：

static struct led_hw_cfg led_v1_cfg = { .reg_offset = 0x00, .max_brightness = 255, }; static struct led_hw_cfg led_v2_cfg = { .reg_offset = 0x10, .max_brightness = 1023, }; static const struct of_device_id myled_of_match[] = { { .compatible = "myvendor,led-v1", .data = &led_v1_cfg }, { .compatible = "myvendor,led-v2", .data = &led_v2_cfg }, { /* sentinel */ }, }; static int myled_probe(struct platform_device *pdev) { const struct of_device_id *match; struct led_hw_cfg *cfg; match = of_match_device(myled_of_match, &pdev->dev); if (match) cfg = (struct led_hw_cfg *)match->data; ... }

这个用法在NXP官方内核以及很多主流驱动里都能看到，做好之后，板级差异就被压缩到一个结构体数据里，驱动代码的复用性明显提升。

2.4 匹配成功后内核额外做的几件事

匹配成功后，内核会自动补齐一些基础信息，接着才会调用你的probe。首先是dev_set_drvdata一类内部关联操作，让设备与驱动之间建立关联，之后你在probe内部用的dev_get_drvdata才有效。其次是sysfs文件系统视角下，/sys/bus/platform/devices目录下的设备会出现一个driver符号链接，指向/sys/bus/platform/drivers下面你的驱动目录。

还有一点很多刚入门的新人会困惑：为什么probe里已经用misc_register注册了字符设备，但insmod之后/dev下并没有立刻出现对应节点？这跟Platform匹配机制无关，但发生场景经常重合。insmod执行后probe成功调用了，设备注册动作在probe里也完成了，但用户空间的udev或者mdev（嵌入式环境常用busybox mdev）需要在收到uevent事件后去创建/dev节点。如果你的系统里没有配置udev/mdev自动处理，那/dev下确实不会自动出现设备节点。这一点在之后的调试过程中非常常见，别把板子本身的问题和匹配机制混为一谈。

另外，如果设备节点被设置为status = "disabled"，那么内核扫描设备树时一般不会为该节点创建platform_device。注意，是“一般不会”。有些场合下节点会被创建但驱动会被禁止绑定，具体取决于内核的配置。在i.MX6ULL这种主流BSP中，disabled节点基本不会生成platform_device，因此你的驱动永远得不到probe的机会。这是一个非常隐蔽的坑，后面排查部分我会专门提到。

3. 在i.MX6ULL上实操：写一个能匹配上的Platform驱动

3.1 环境准备与基础工程建议

咱们动手写一个完整的Platform驱动，别空谈理论。我用的是i.MX6ULL开发板，内核版本以4.1.15或者4.9.x为主，这也是目前市面上不少i.MX6ULL开发板BSP的常见内核版本。交叉编译工具链一般是arm-linux-gnueabihf-，根据你自己开发板配套的SDK来定。

写驱动之前，我建议先确认三件事：

• 内核源码目录已经准备好，并且编译过一遍，生成了Module.symvers。
• 开发板内核里设备树已经支持你将要修改的节点，或者你知道怎么把新的dtb烧进去。
• 板子上的文件系统能够加载内核模块，比如insmod/modprobe命令可用。

写驱动文件之前，先在板子上执行下面这条命令，看看当前系统里platform设备的大致情况：

ls /sys/bus/platform/devices/

你会看到很多设备，比如soc、1001000.uart、2000000.spi之类，名字一般是“寄存器地址.设备名”的格式，这些就是内核从设备树里解析出来后挂到platform总线上的设备。等下咱们自己通过设备树创建的设备也会以类似的形式出现在这个目录。

3.2 设备树中定义自己的平台设备节点

我们的目标是创建一个叫“myled”的平台设备，然后让驱动程序通过compatible匹配到它，进入probe，最后操作一个GPIO点灯。

你需要在设备树源文件里找到根节点或者合适的父节点，添加以下这个节点。很多i.MX6ULL开发板的设备树顶层是板级dts文件（如imx6ull-14x14-evk.dts），里面有根节点“/”，往根节点里加就行了。有些为了方便管理，会放在根节点的某个子节点中，只要能被内核正常解析到就行，放在根下最直观。

/ { myled { compatible = "myvendor,myled"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_myled>; led-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>; status = "okay"; }; };

注意这个节点里我引用了pinctrl_myled，你必须在设备树里对应的iomuxc节点下添加这个引脚复用配置。以i.MX6ULL为例，通常在设备树中可以找到类似这么一段：

&iomuxc { pinctrl_myled: myledgrp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x10b0 >; }; };

引脚的宏定义MX6UL_PAD_GPIO1_IO03__GPIO1_IO03在设备树头文件里已经定义好，不同开发板这个宏可能不一样，具体看你的BSP设备树。我这里只是给你一个示例，实际操作时必须以自己板卡上的引脚为依据。

改完设备树之后，重新编译dtb，然后烧录或者通过tftp/nfs方式加载到板子上启动。启动后在板子上执行：

ls /sys/bus/platform/devices/myled

如果设备树解析正常，你应该能看到这个目录存在。到这一步，你的“平台设备”已经创建成功，内核里已经存在一个platform_device，就等着驱动来匹配了。如果看不到设备目录，优先检查设备树有没有被正确编译加载，compatible、status属性有没有问题。

3.3 编写Platform驱动并正确注册

接下来写驱动。为了把注意力集中在Platform机制上，我直接用一个最简单的点灯驱动示例，通过miscdevice注册字符设备，用户程序用ioctl控制亮灭极简版。完整代码示例：

#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/miscdevice.h> #include <linux/uaccess.h> #include <linux/fs.h> #define MYLED_ON 0x01 #define MYLED_OFF 0x00 struct myled_dev { struct gpio_desc *led_gpio; }; static struct myled_dev *myled_data; static long myled_ioctl(struct file *file, unsigned int cmd, unsigned long arg) { switch (cmd) { case MYLED_ON: gpiod_set_value(myled_data->led_gpio, 1); break; case MYLED_OFF: gpiod_set_value(myled_data->led_gpio, 0); break; default: return -EINVAL; } return 0; } static const struct file_operations myled_fops = { .owner = THIS_MODULE, .unlocked_ioctl = myled_ioctl, }; static struct miscdevice myled_miscdev = { .minor = MISC_DYNAMIC_MINOR, .name = "myled", .fops = &myled_fops, }; static int myled_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; int ret; dev_info(dev, "myled probe success\n"); myled_data = devm_kzalloc(dev, sizeof(*myled_data), GFP_KERNEL); if (!myled_data) return -ENOMEM; myled_data->led_gpio = devm_gpiod_get(dev, "led", GPIOD_OUT_LOW); if (IS_ERR(myled_data->led_gpio)) { ret = PTR_ERR(myled_data->led_gpio); dev_err(dev, "failed to get led gpio: %d\n", ret); return ret; } gpiod_set_consumer_name(myled_data->led_gpio, "myled"); ret = misc_register(&myled_miscdev); if (ret) { dev_err(dev, "failed to register misc device\n"); return ret; } return 0; } static int myled_remove(struct platform_device *pdev) { misc_deregister(&myled_miscdev); return 0; } static const struct of_device_id myled_of_match[] = { { .compatible = "myvendor,myled", }, { /* sentinel */ }, }; MODULE_DEVICE_TABLE(of, myled_of_match); static struct platform_driver myled_driver = { .probe = myled_probe, .remove = myled_remove, .driver = { .name = "myled", .of_match_table = myled_of_match, }, }; module_platform_driver(myled_driver); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("i.MX6ULL platform device match demo");

这个驱动用module_platform_driver宏完成platform_driver_register和platform_driver_unregister的封装。加载时注册驱动，总线扫描设备后如果匹配成功，probe就会被调用。

3.4 编译、加载与查看匹配效果

对应的Makefile非常简单：

obj-m := myled.o KERNELDIR := /path/to/your/kernel CROSS_COMPILE := arm-linux-gnueabihf- CC := $(CROSS_COMPILE)gcc 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

编译之后得到myled.ko，拷贝到板子上，insmod加载：

insmod myled.ko

正常的话，dmesg里能看到：

myled myled: myled probe success

此时查看platform总线的设备与驱动绑定关系：

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

如果驱动已经成功绑定，这个符号链接会指向drivers目录下的myled驱动。

再用设备名匹配方式来验证一下纯名字匹配路径的优先级问题：如果设备树里没有compatible，而你的platform_device是内核代码直接注册的，driver结构体里的name字段和设备name相同也可能匹配成功。这一点虽然老派，在兼容旧代码时很有用。

3.5 GPIO子系统在Platform机制中扮演的辅助角色

在刚才的驱动里，我用到了devm_gpiod_get和gpiod_set_value，这是内核GPIO子系统提供的基于描述符的接口。你可能会疑惑，这跟Platform匹配机制有什么关系？

关系其实不直接，但属于Platform设备操作最典型的资源获取方式。传统开发中，要操作GPIO需要ioremap并配置引脚复用寄存器，很繁琐。现在的推荐姿势是：在设备树节点里通过led-gpio这样的属性描述“我需要哪个引脚”，驱动中通过devm_gpiod_get获取GPIO描述符。这个API能正常工作，前提是你传入了指向struct device的指针，也就是platform_device里的&pdev->dev。设备树、GPIO子系统、Platform驱动模型，这三者是紧密配合的。

Platform总线匹配只是给你一个“入场券”，入场之后怎么拿资源、怎么使用硬件，又注册了另一套内核API。很多教程把这几个维度混在一起，新手就容易懵。我建议你在实验时把这条链路拆开理解：

• 设备树节点 = 设备说明书，描述有什么资源。
• Platform驱动匹配 = 验证“这个驱动能管这个设备”。
• probe函数 = 驱动读取说明书，实际操作资源。
• misc或者字符设备框架 = 把操作能力暴露给用户空间。

3.6 id_table匹配方式与非设备树场景

聊完设备树方式，咱们也花点时间说说id_table匹配。毕竟并非所有内核和所有平台都使用设备树，而老平台代码里大量存在platform_device_id的使用方式。

如果你有一个平台设备，它不是从设备树生成的，而是通过platform_device_register注册的，例如内核板级文件里这么写：

static struct resource myled_resources[] = { { .start = 0x020c406c, .end = 0x020c406f, .flags = IORESOURCE_MEM, }, }; static struct platform_device myled_device = { .name = "myled", .id = -1, .num_resources = ARRAY_SIZE(myled_resources), .resource = myled_resources, }; static int __init myled_device_init(void) { return platform_device_register(&myled_device); }

你的驱动需要通过platform_driver里的id_table来匹配，而不只是名字。使用示例：

static const struct platform_device_id myled_id_table[] = { { "myled", 0 }, { }, }; MODULE_DEVICE_TABLE(platform, myled_id_table); static struct platform_driver myled_driver = { .probe = myled_probe, .remove = myled_remove, .driver = { .name = "myled", }, .id_table = myled_id_table, };

platform_match内部执行顺序是先查of_match_table，再查ACPI，再查id_table，最后才是driver name与device name直接比较。但这里有个细节：如果驱动同时配置了of_match_table和id_table，设备树匹配又是首要路径，许多时候驱动作者会把compatible匹配的设备也放进id_table里，主要是为了MODULE_DEVICE_TABLE生成模块别名，方便modprobe自动加载模块。

“为什么我明明把驱动编译成模块放到文件系统了，modprobe能识别到模块，却还是会找不到设备？”这类问题，经常就是模块别名机制的问题。modprobe在加载模块前要根据设备uevent里的MODALIAS环境变量去寻找对应的模块，MODALIAS内容与设备树compatible相关，而模块中通过MODULE_DEVICE_TABLE导出的表决定了内核知道这个模块能支持哪些设备。如果你只写了of_match_table，没有同步MODULE_DEVICE_TABLE，自动加载时可能就会出问题。这个知识点一般很少人讲透，遇到了先检查这里不会错。

4. 匹配失败排查与调试经验

4.1 最常见的匹配失败原因

匹配失败是驱动开发里最磨人的问题之一。根据我带项目的经验，下面这些原因几乎覆盖了八成以上的失败场景，你排查时不妨按顺序过一遍。

compatible字符串不一致，这是头号问题。设备树里写着"myvendor,myled"，驱动of_match_table里写的是"myvendor,myled "，多了个空格或者大小写不一致，都匹配不上。排查方法很简单，在板子上执行：

cat /sys/bus/platform/devices/myled/uevent

看输出的MODALIAS字段：

OF_NAME=myled OF_FULLNAME=/myled OF_COMPATIBLE_0=myvendor,myled MODALIAS=of:NmyledT<NULL>Cmyvendor,myled

然后对比驱动模块中由of_match_table生成的模块别名。也可以直接看/proc/device-tree下设备树节点里的属性是否和你期望的一致。

设备树没过。这个问题尤其隐蔽，因为很多开发板启动时用的不是最新编译的dtb，你改了dts但忘了重新编译，或者编译了没有传到板子对应的启动分区。排查方法很直接：在板子上重新查看设备树里你添加的节点是否存在，例如：

ls /proc/device-tree/myled/ cat /proc/device-tree/myled/compatible

status属性被设成disabled。如前所述，disabled状态可能导致platform_device根本不创建。检查节点status是否为okay，或者干脆去掉status属性。有些BSP中，特定父节点下的status控制逻辑还会有差异，需要具体问题具体分析，但第一怀疑对象一定是这里。

pinctrl配置出错。节点里的pinctrl-0引用了不存在的pinctrl_myled节点，或者引用的引脚宏跟iomuxc里实际配置不一致，虽然不直接影响Platform匹配，但probe里GPIO请求时会失败，导致probe返回错误码，驱动被卸载，现象看起来跟匹配失败一样。排查时可以先用以下命令确认这个设备是否绑定过驱动：

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

如果driver链接存在，说明匹配成功过，probe里报错的可能性更大；如果不存在，才说明匹配阶段都没走通。

GPIO号冲突或者重复申请。i.MX6ULL的GPIO资源管理通过GPIO子系统完成，如果你在设备树里把同一个引脚用在两个不同节点，或者驱动里重复请求了同一个GPIO，devm_gpiod_get会返回错误。典型报错是EBUSY或者EINVAL，同样会让probe失败。这类问题和Platform匹配本身无关，但极易干扰判断，建议出现probe失败时先把dmesg完整拉出来看最终错误码，而不是只盯着最前面的日志。

拿不到寄存器资源。如果节点里声明了reg属性，驱动用platform_get_resource和devm_ioremap_resource去获取，但寄存器地址范围跟别的设备重叠，devm_ioremap_resource也会返回错误。很多人在probe失败时只看到return -EBUSY，却不会想到是物理地址资源冲突。

4.2 如何快速定位匹配路径到底走到哪一步

匹配失败时，核心问题是搞清楚内核到底在哪个环节放弃了。我常用的办法有以下几步：

第一步，打开内核的驱动调试信息。在cmdline里加上ignore_loglevel和dyndbg，或者简单点使用dmesg -n 8。由于Platform总线匹配在出错时不一定都有日志输出，这个方法有时不够直观，但先把日志级别放到最高没坏处。

第二步，在驱动里加打印。如果你不确定自己的probe是否被调用过，直接在probe入口加一条dev_info或者pr_info。很多人会嫌打印土，但实际调试中这永远是最直接有效的办法。注意probe里返回错误码时，内核会打印类似“myled: probe of myled failed with error -16”的消息，看到这类log就知道驱动和设备已经匹配成功，是probe内部处理出了问题。

第三步，利用sysfs节点检查匹配状态。这是最高效的方式：

# 查看设备是否绑定驱动 ls -l /sys/bus/platform/devices/myled/driver # 查看驱动的名字和它支持的设备id cat /sys/bus/platform/drivers/myled/uevent ls /sys/bus/platform/drivers/myled/

如果设备下driver链接指向了你的驱动，说明已经绑定成功，probe被调用过。如果驱动目录完全是空的，说明设备树里根本没有符合条件的设备，或者设备的compatible和你驱动里的of_match_table不一致。走到这一步，匹配路径基本就能定位出来。

第四步，抓总线级调试日志。内核的驱动模型在drivers/base/dd.c里提供了许多调试信息输出，需要把CONFIG_DEBUG_DRIVER打开，编译内核时启用这个选项，然后dmesg里会出现“matched device”之类的日志。这类信息量很大，但如果你怀疑是匹配逻辑本身出了问题，它是最权威的排查工具。

4.3 一个真实的踩坑案例：设备树改名引发的诡异问题

我之前在一个项目里调试一款外设驱动，遇到过一个特别迷惑的现象：驱动模块加载没报错，但probe就是不执行。设备树节点添加到dts里了，也确认过dtb烧录成功，/sys/bus/platform/devices目录下能看到设备的目录，名字也跟我预期的一样。

按照常规排查，compatible我也对比过，两者看起来一模一样。最后我实在没办法，把两个字符串逐个字符用十六进制打了出来，这才发现问题：设备树里写了“myvendor,my-led”，但驱动里of_device_id写的是“myvendor,myled”，中间少了一个连字符“-”，肉眼看久了确实很难发现。这就是为什么我强烈建议用uevent里的MODALIAS字段做严格比对，而不是凭肉眼去检查dts和代码。

还有一次是同事反馈说insmod之后probe没执行，我过去查看发现，/sys/bus/platform/devices下设备目录能看到了，但内核日志里没有任何关于这个设备probe失败的记录。通过对比dtb和dts源码，才发现板子实际加载的dtb是一份旧的备份文件，压根没有他改的这个节点，目录虽然能看到，但那是另一份设备树里本来就有的同名设备，compatible和寄存器地址都不同。这种环境问题最容易浪费时间，排查时一定先确认板子真正加载的设备树是不是你改的那个。

4.4 probe成功后却被移除的常见原因

定位到probe被调用了，但执行到一半驱动就被移除了，这类问题也很典型。最常见的原因是probe返回了错误码。例如我让你看内核在probe失败时打印的那行信息：

myled: probe of myled failed with error -16

这个-16对应- EBUSY。它可能来自platform_get_resource返回NULL后你直接return -EINVAL，也可能来自gpiod_get返回错误。需要注意的是，probe一旦返回非零，内核的driver core会认为驱动绑定失败，之后会自动执行清理操作，驱动和设备会被解除关联，看起来就像模块被卸载了一样。

所以，当dmesg里能看到probe被调用但随后设备driver链接消失，不要盯着Platform匹配机制看，问题基本都在probe内部逻辑里。要做的就是把probe里每一步可能的错误码都打印出来，确定是哪一步返回的，再去排查对应子系统的问题。

很多人不知道一个小细节：如果probe在某个子系统返回EPROBE_DEFER（延迟探测），内核不会立刻判定失败，而是把设备挂到一个等待队列，等对应依赖的驱动加载完成后再重新触发probe。这在多驱动依赖场景里非常重要。在i.MX6ULL的驱动开发中，如果设备树里引用的某个时钟或中断控制器对应的驱动还没就绪，你的驱动probe可能会被反复推迟执行。dmesg里看到“deferred probe”相关的字眼，别慌，这是内核的合理等待机制，你需要回头检查自己依赖的外设驱动有没有加载成功。

4.5 使用内核deferred probe机制

多说一句EPROBE_DEFER，因为我发现很多新手第一次遇到它都会误判成匹配失败。在你的probe函数中，当你请求某个资源但该资源对应的设备驱动还没准备好时，比如调用clk_get、regulator_get、gpiod_get时返回了-EPROBE_DEFER，你应该直接把这个错误码原样返回给内核。

内核的driver core看到返回-EPROBE_DEFER，会把你的设备放到一个延迟列表中，后续每当有新的driver注册，都会重新尝试对这些设备进行绑定和probe。这个机制保证了设备之间的依赖关系可以通过“你等我一会”的方式动态解决，而不是简单在probe里死循环等待资源就绪。

实际调试时，你可以在内核cmdline中添加：

deferred_probe_timeout=2

这样系统启动后如果还存在EPROBE_DEFER的设备，会在超时后打印详细信息，提示你到底在等待哪个资源。这个功能在排查启动早期驱动顺序问题时几乎是救命稻草。

4.6 常见问题速查表

我把上面所有问题整理成一张速查表，方便你日后直接对照排查。

这张表你保存下来，遇到问题时先对号入座。别小看这些检查项，很多资深工程师排查这类问题，也基本走的是这套流程，只不过他们已经把每一步都内化成了肌肉记忆。

5. 升级认知：从一套机制到整个设备模型思维

5.1 Platform只是Linux设备模型里的一个缩影

如果你只是想在i.MX6ULL上调通一个点灯驱动，其实上面4节内容已经足够。但如果你想把Linux驱动的知识体系搭得更完整，我建议你从Platform这套机制中跳出来，思考一下它背后统一的Linux内核设备模型。

Platform总线设备驱动模型本质上只是Linux通用设备模型的一个应用。Linux内核维护了一个设备模型的骨架，包括kobject、kset、uevent、sysfs等底层设施，在这个骨架上衍生出不同类型的总线。不管是platform_bus_type、i2c_bus_type、spi_bus_type还是pci_bus_type，它们都有共同的语义：设备注册、驱动注册、总线匹配、probe调用、电源管理回调等。

你在这篇文章里学到的compatible匹配、driver绑定、sysfs节点检查，这些技能在后续接触I2C客户端驱动、SPI设备驱动时同样适用，区别只是总线类型和匹配函数不一样。I2C设备的client与driver通过id_table或者设备树compatible匹配，SPI设备也是类似逻辑。

很多讲Platform总线的教程喜欢铺陈各种概念，但我觉得内核设备模型背后的核心设计思想才是真正值得玩味的东西：把易变的、板级相关的设备描述从稳定的驱动逻辑中剥离出来。设备树解决了设备描述“写在哪”的问题，Platform总线解决了设备与驱动“怎么见面”的问题，而GPIO、时钟、中断等内核子系统则解决了资源“怎么共享不冲突”的问题。

5.2 理解匹配机制对日常开发的实际影响

哪怕你已经能熟练地照着别人的驱动模板抄代码，我也建议你花时间把匹配机制吃透。因为不理解匹配机制，你在调试时会缺少一个方向感，只知道代码写出来没反应，抓不住“系统如何认识我的设备”这条主线。

举个例子。设备树里如果出现这个节点：

&uart1 { status = "okay"; };

按我们前面说的流程，内核会把uart1节点转换成platform_device，去匹配IMX6ULL的uart驱动。如果你哪天发现一个串口设备死活打不开，第一步就应该去确认uart1节点是否成功创建了platform_device，然后再看uart驱动有没有绑定到这个设备、probe有没有执行。理解了这套机制之后，你排查硬件驱动的顺序就会变得很清晰：从设备树到平台设备，再到驱动绑定，最后才是驱动内部硬件初始化的逻辑。

另一个常见场景是外设的时钟和电源管理。Platform驱动在probe里拿到设备之后，往往要操作clk和regulator子系统，比如打开外设时钟、调节电压。这些资源同样可以在设备树节点中描述。如果资源描述不正确，probe里clk_prepare_enable就会失败。你只有理解了整个链条，才能在设备树、驱动代码、内核日志三个视角之间来回切换定位问题，而不是逮着compatible死磕。

5.3 如何继续深入学习Platform相关技术

如果你想在这个方向上有更扎实的积累，我给几条具体建议。

第一条，翻内核源码时别只看platform.c，还要看device.h、platform_device.h、of_device.h这几个头文件，把platform_device、platform_driver、of_device_id这几个结构体的字段都弄明白，尤其是resource结构体，理解IORESOURCE_MEM、IORESOURCE_IRQ的用法。probe里那些platform_get_resource、platform_get_irq之类的API其实都是在操作resource结构体，明白了数据结构你再去看接口函数，不会觉得它们散乱。

第二条，自己独立完成一次从设备树建节点到用户空间应用程序调用完整链路的实验。别只抄教程，看完文章后关掉网页，自己凭理解写一版，踩过的坑记得越牢，成长越快。实验时可以刻意制造几个错误，比如把compatible故意写错、把status设为disabled，观察probe失败的具体表现，然后再修正回来。这种做法比重复抄代码有用得多。

第三条，条件允许的话，用QEMU或者虚拟平台去读内核源码里更多总线模型的实现。i.MX6ULL开发板适合做真实的硬件对接，但如果你想在更深层面理解Linux设备模型，比如分析bus_type结构体的match、uevent、probe回调在driver core里如何被调度，一台能编译内核的Linux主机配合QEMU的virt平台调试，效率可能比反复烧录板子更高。

6. 最后再分享几个调试小技巧

调试Platform驱动时，有几条经验我觉得很有用，分享给你们。

第一，dmesg一定要养成随手清空的习惯。开发板长期运行，内核日志缓冲区会被各种无关消息占满，容易把关键日志冲掉。每次insmod之前先dmesg -c把旧日志清掉，加载之后再看dmesg输出，这样probe里打印的信息一目了然，不会遗漏。

第二，多利用sysfs，少依赖暴力加打印。sysfs是内核设备模型的实时投影，/sys/bus/platform/devices目录下的每个符号链接和uevent文件都是判断设备状态的最可靠依据。很多问题看一眼驱动链接、cat一下uevent就能定位，完全不需要重新编译模块加打印。虽然加打印在调试probe内部逻辑时仍然必要，但先通过sysfs确认匹配状态，能帮你少走很多弯路。

第三，改设备树之后一定要确认板子加载的是你编译的新dtb。嵌入式开发中，启动流程各有差异，有的从SD卡读dtb，有的从EMMC指定分区读，有的通过u-boot环境变量指定tftp加载。改完设备树却忘记更新对应位置的dtb，是我见过最频繁的低级错误。调试设备树相关问题时，先在板子上执行ls /proc/device-tree/看看节点是否真实存在，再往下排查，能省掉大量无意义的工作。

第四，合理使用devm系列的资源管理API。我在示例驱动里大量使用了devm_kzalloc、devm_gpiod_get，这些devm前缀的函数本质上是把资源释放的责任挂在struct device的生命周期上。probe成功之后，设备与驱动解除绑定时，内核会自动帮你释放这些资源。这能有效避免probe失败时忘记释放之前申请的资源导致的问题。不夸张地说，内核里devm系列API的出现，让驱动资源管理的出错率降低了一个量级。

第五，也是我觉得最重要的一点，不要急着一次写完整个驱动。你可以先把probe函数只留一条打印，确认匹配链路通顺，再一步步加上GPIO申请、寄存器映射、设备注册等逻辑。每一次小步验证，都能让问题边界变得非常清晰。真按这种方式做，大多数Platform匹配类问题在半个小时内就能定位，远比你一股脑写完两百行驱动再调半天高效得多。

我在实际项目里用这套方法解决过的问题不计其数，甚至有时候不是i.MX6ULL平台，换成其它ARM SoC或者RISC-V芯片，只要内核还是Linux，这套Platform设备与驱动匹配机制基本不会变，调试思路也是相通的。这就是花时间把机制理解透的价值。