Linux驱动开发三种方法对比：从传统到设备树的演进与实践

1. 从点亮一颗LED说起：Linux驱动开发的三种范式

作为一个喜欢折腾硬件的DIYer，点亮一颗LED往往是踏入嵌入式Linux世界的第一步。这看似简单的操作，背后却串联起了Linux驱动开发的核心脉络。很多朋友，包括我自己刚开始接触时，都会对“设备树”、“总线”、“驱动”这些概念感到困惑，尤其是设备树出现后，感觉驱动开发变得更“玄乎”了。其实，内核从3.0版本引入设备树，是为了解决一个根本问题：如何让同一份驱动代码，能更优雅地适配不同的硬件平台。今天，我就结合自己倒腾LED驱动的经历，把这三种主流开发方法——传统方法、总线方法、设备树方法——掰开揉碎了讲清楚。无论你是刚入门的嵌入式爱好者，还是想系统梳理驱动知识的开发者，这篇文章都能帮你建立起清晰的认知框架，并附上可直接“抄作业”的代码和避坑指南。

2. 驱动开发的核心流程与统一骨架

在深入三种方法之前，我们必须先理解一个不变的真理：无论方法如何演变，一个字符设备驱动（比如我们的LED驱动）的核心流程骨架是基本一致的。理解了这个骨架，再看各种方法就像有了地图，不会迷路。

2.1 驱动程序的五个基本组成部分

一个完整的驱动，尤其是像LED这样的字符设备驱动，其生命周期可以清晰地划分为五个部分。我习惯把这五个部分看作驱动程序的“五脏六腑”，缺一不可。

1. 分配资源：这是驱动的“出生证明”阶段。核心任务是向内核申请一个独一无二的设备号。设备号就像是驱动的身份证，由主设备号和次设备号组成。应用程序通过这个号码在/dev目录下找到对应的设备节点。常用的函数是alloc_chrdev_region或register_chrdev（后者是老式但更简单的做法）。

2. 设置与初始化：这是驱动的“身体构造”阶段。你需要定义这个驱动能做什么，也就是实现具体的操作函数。最关键的是定义一个struct file_operations结构体，里面填充一系列的函数指针，比如open、read、write、release（对应close）等。对于LED驱动，我们主要实现open（初始化GPIO）、write（控制亮灭）和release（可能清理GPIO）就够了。同时，这里也需要完成硬件相关的初始化，比如通过ioremap映射GPIO寄存器地址，或者配置GPIO的方向。

3. 注册操作集合：这是驱动的“能力注册”阶段。将上一步设置好的file_operations结构体，与申请到的设备号关联起来，并告诉内核。通常通过cdev_init和cdev_add函数完成。这一步之后，内核就知道：“哦，有一个设备号是XXX的驱动，它提供了这些操作函数。”

4. 创建设备节点（入口函数）：这是驱动的“亮相”阶段。为了让用户空间的应用层程序能够方便地访问，我们需要在/dev目录下创建一个看得见、摸得着的设备文件。这通常通过device_create或mknod命令（在驱动中自动创建）来完成。同时，为了管理的便利，我们还会创建一个设备类（class_create）。所有这些工作，通常都放在驱动的初始化函数（module_init指定的函数）中完成。

5. 清理与注销（出口函数）：这是驱动的“善后”阶段。当驱动模块被卸载时，必须反向执行上述所有操作：销毁设备节点（device_destroy）、注销设备类（class_destroy）、从内核移除操作集合（cdev_del）、释放设备号（unregister_chrdev_region）。这个函数由module_exit指定。

注意：这五个部分在代码中并非严格按顺序排列的五个独立函数，而是逻辑上的五个步骤。它们通常被组织在驱动的入口（init）和出口（exit）函数中，以及file_operations的方法实现里。

2.2 用户空间如何与驱动交互

理解了驱动的骨架，再从应用层角度看就很简单了。假设我们最终在/dev下创建了一个叫my_led的设备节点。

• 用户程序调用open(“/dev/my_led”, O_RDWR)，这个系统调用会穿透到内核，最终执行我们驱动里file_operations中的.open方法。
• 用户程序调用write(fd, “1”, 1)想点亮LED，内核就会调用我们驱动里的.write方法，我们在这个方法里解析写入的字符‘1’，然后去操作硬件寄存器将对应的GPIO拉高。
• 调用close(fd)时，内核会执行驱动的.release方法。

实操心得：在开始写任何驱动之前，先在纸上或脑子里把这五个步骤过一遍，把数据流（应用层 -> VFS -> 驱动 -> 硬件）想清楚。这会让你在编码时思路异常清晰，调试时也能快速定位问题出在哪个环节。很多初学者卡住，就是因为某个环节（比如设备号申请失败、cdev_add没做、设备节点没创建）被遗漏了。

3. 方法一：传统方法——简单粗暴的“全家桶”

传统方法，我称之为“全家桶”式开发。它把所有东西——硬件信息（GPIO引脚号）、驱动操作逻辑、注册注销流程——全部塞进一个C文件（比如led_drv.c）里。这是最古老、最直接，也是理解驱动本质最好的起点。

3.1 代码结构深度解析

我们以一个控制连接在GPIO 5上的LED为例，来看一个极简的传统驱动框架。

#include <linux/module.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/device.h> #include <linux/uaccess.h> #include <linux/io.h> #define LED_GPIO 5 // 硬件信息硬编码在此！ static void __iomem *gpio_base; static int led_open(struct inode *inode, struct file *filp) { // 1. 映射GPIO控制器的物理地址到内核虚拟地址 gpio_base = ioremap(0xFE200000, 4096); // BCM2835 GPIO基地址，示例 if (!gpio_base) return -ENOMEM; // 2. 配置GPIO 5为输出模式 (通过写对应的寄存器位) // 假设寄存器偏移量，具体看芯片手册 iowrite32((ioread32(gpio_base + 0x00) & ~(7 << 15)) | (1 << 15), gpio_base + 0x00); printk(KERN_INFO “LED driver opened.\n”); return 0; } static ssize_t led_write(struct file *filp, const char __user *buf, size_t count, loff_t *f_pos) { char val; if (copy_from_user(&val, buf, 1)) // 从用户空间拷贝一个字节 return -EFAULT; // 根据用户写入的值（‘1’或‘0’）控制GPIO if (val == ‘1’) { iowrite32(1 << 5, gpio_base + 0x1C); // Set GPIO 5 } else if (val == ‘0’) { iowrite32(1 << 5, gpio_base + 0x28); // Clear GPIO 5 } return 1; } static int led_release(struct inode *inode, struct file *filp) { iounmap(gpio_base); // 释放映射 printk(KERN_INFO “LED driver closed.\n”); return 0; } static struct file_operations led_fops = { .owner = THIS_MODULE, .open = led_open, .write = led_write, .release = led_release, }; static int major_num; static struct class *led_class; static struct device *led_device; static int __init led_init(void) { // 1. 分配：动态申请一个主设备号 major_num = register_chrdev(0, “my_led”, &led_fops); if (major_num < 0) { printk(KERN_ALERT “Failed to register char device.\n”); return major_num; } // 2. 创建设备类 led_class = class_create(THIS_MODULE, “led_class”); if (IS_ERR(led_class)) { unregister_chrdev(major_num, “my_led”); return PTR_ERR(led_class); } // 3. 创建设备节点 /dev/my_led led_device = device_create(led_class, NULL, MKDEV(major_num, 0), NULL, “my_led”); if (IS_ERR(led_device)) { class_destroy(led_class); unregister_chrdev(major_num, “my_led”); return PTR_ERR(led_device); } printk(KERN_INFO “LED driver loaded with major number %d\n”, major_num); return 0; } static void __exit led_exit(void) { // 出口函数：按创建的反顺序销毁一切 device_destroy(led_class, MKDEV(major_num, 0)); class_destroy(led_class); unregister_chrdev(major_num, “my_led”); printk(KERN_INFO “LED driver unloaded.\n”); } module_init(led_init); module_exit(led_exit); MODULE_LICENSE(“GPL”);

3.2 传统方法的优缺点与适用场景

优点：

• 直观简单：所有代码都在一个文件，逻辑线性，非常适合学习和理解驱动的基本运作原理。你不需要理解复杂的框架，就能让一个设备跑起来。
• 编译直接：一个Makefile，一个.c文件，make一下生成.ko文件，insmod加载即可。

缺点：

• 紧耦合，难维护：硬件信息（LED_GPIO 5， 基地址0xFE200000）直接硬编码在驱动代码中。如果明天LED换到了GPIO 6，你必须修改led_drv.c，然后重新编译整个驱动模块。
• 无法扩展：想象一下，你的板子上有10个LED，难道要写10个几乎一样的驱动文件，只改一个GPIO号吗？或者在一个驱动里写10套open/write函数？代码会变得臃肿且难以管理。
• 不通用：这份驱动只能用于你这块特定GPIO的板子。换一个不同GPIO控制器或不同引脚定义的板子，代码就无法重用。

实操心得：传统方法就像用汇编语言写程序，虽然效率高、控制力强，但生产力低下。它只适用于以下几种情况：1）快速验证一个驱动想法或硬件功能；2）目标硬件永远固定不变；3）作为学习驱动原理的“Hello World”。在实际产品开发中，几乎不会使用这种方法。

4. 方法二：总线方法——引入“媒人”的解耦之道

为了解决传统方法的紧耦合问题，Linux内核引入了“总线-设备-驱动”模型。你可以把这个模型想象成一个“婚介所”（总线），它管理着很多“小伙子”（驱动）和“姑娘”（设备）的信息。当一个小伙子的条件（驱动）和一个姑娘的要求（设备）匹配时，婚介所就安排他们见面（匹配成功），然后他们就可以一起生活（驱动设备）了。对于像GPIO、I2C、SPI这些挂在系统总线上的设备，最常用的就是platform总线，它是一种虚拟总线，用于管理那些直接集成在SoC内部的控制器或没有物理总线的设备。

4.1 核心结构体与匹配机制

总线方法的核心是将“设备信息”和“驱动逻辑”分离成两个独立的部分。

设备端 (led_device.c)：

• struct platform_device：描述一个平台设备。它包含设备的名字、ID、资源（如内存地址、中断号）等信息。关键是要填充一个struct resource数组，用来描述这个设备占用的硬件资源（比如GPIO编号、寄存器物理地址范围）。
• platform_device_register()：在系统启动时（或模块加载时），将这个设备结构体注册到platform总线上，相当于在“婚介所”登记了姑娘的信息。

驱动端 (led_driver.c)：

• struct platform_driver：描述一个平台驱动。它包含驱动名字、一个probe函数指针、一个remove函数指针，以及一个id_table（用于匹配）。
• struct device_driver：是platform_driver的一个内嵌成员，包含更基础的驱动信息。
• platform_driver_register()：将驱动注册到总线，相当于登记小伙子信息。

匹配过程：当设备和驱动都向总线注册后，内核的总线核心会调用一个match函数。对于platform总线，其匹配规则是：优先检查驱动的id_table是否包含设备的名字；如果不匹配，则直接比较驱动名字 (driver.name) 和设备名字 (device.name) 是否一致。一旦匹配成功，总线核心就会调用驱动结构体里你事先写好的probe函数，并将匹配到的platform_device结构体指针传递给它。

4.2 代码拆分与实现详解

现在我们把传统方法的“全家桶”拆成“设备”和“驱动”两份文件。

设备文件led_device.c:

#include <linux/module.h> #include <linux/platform_device.h> // 定义设备所使用的资源：这里我们定义GPIO编号为5 #define LED_GPIO 5 static struct resource led_resources[] = { { .start = LED_GPIO, // 资源的起始值，这里就是GPIO号 .end = LED_GPIO, // 资源的结束值，和start一样表示单个资源 .flags = IORESOURCE_IRQ, // 标志位，这里我们“借用”IRQ标志，实际中GPIO可能有特定类型，这里为简化演示 .name = “led_gpio”, }, }; static void led_device_release(struct device *dev) { // 设备释放函数，可以为空但不能没有 printk(KERN_INFO “LED device released.\n”); } static struct platform_device led_platform_device = { .name = “my_platform_led”, // 设备名，用于和驱动匹配的关键！ .id = -1, .num_resources = ARRAY_SIZE(led_resources), .resource = led_resources, .dev = { .release = led_device_release, }, }; static int __init led_device_init(void) { return platform_device_register(&led_platform_device); } static void __exit led_device_exit(void) { platform_device_unregister(&led_platform_device); } module_init(led_device_init); module_exit(led_device_exit); MODULE_LICENSE(“GPL”);

驱动文件led_driver.c:

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/device.h> #include <linux/uaccess.h> #include <linux/io.h> static int major_num; static struct class *led_class; static struct device *led_device; static void __iomem *gpio_base; static int led_gpio; // 不再硬编码，从设备资源获取 static int led_open(struct inode *inode, struct file *filp) { // 配置GPIO为输出，gpio_base和led_gpio已在probe中设置好 // ... 配置代码，依赖于具体硬件 ... printk(KERN_INFO “LED driver opened, GPIO %d.\n”, led_gpio); return 0; } // write和release函数与传统方法类似，略... static struct file_operations led_fops = { .owner = THIS_MODULE, .open = led_open, .write = led_write, .release = led_release, }; // 关键的probe函数：匹配成功后自动调用 static int led_probe(struct platform_device *pdev) { struct resource *res; // 1. 从平台设备中获取资源 res = platform_get_resource(pdev, IORESOURCE_IRQ, 0); // 获取第一个资源 if (!res) { dev_err(&pdev->dev, “No GPIO resource found.\n”); return -ENXIO; } led_gpio = res->start; // 这里就拿到了设备文件中定义的GPIO 5！ printk(KERN_INFO “Probe: Got GPIO %d for LED.\n”, led_gpio); // 2. 映射硬件寄存器（这里简化，实际地址可能也从资源获取） gpio_base = ioremap(0xFE200000, 4096); // 3. 执行传统方法中init函数的工作：注册字符设备 major_num = register_chrdev(0, “my_led”, &led_fops); led_class = class_create(THIS_MODULE, “led_class”); led_device = device_create(led_class, NULL, MKDEV(major_num, 0), NULL, “my_led”); return 0; } // remove函数：模块卸载或设备移除时调用 static int led_remove(struct platform_device *pdev) { // 执行传统方法中exit函数的工作 device_destroy(led_class, MKDEV(major_num, 0)); class_destroy(led_class); unregister_chrdev(major_num, “my_led”); iounmap(gpio_base); printk(KERN_INFO “LED driver removed.\n”); return 0; } static struct platform_driver led_platform_driver = { .probe = led_probe, .remove = led_remove, .driver = { .name = “my_platform_led”, // 驱动名，必须与设备名一致才能匹配！ .owner = THIS_MODULE, }, }; static int __init led_driver_init(void) { // 注册的是platform_driver，不再是字符设备 return platform_driver_register(&led_platform_driver); } static void __exit led_driver_exit(void) { platform_driver_unregister(&led_platform_driver); } module_init(led_driver_init); module_exit(led_driver_exit); MODULE_LICENSE(“GPL”);

4.3 总线方法的优缺点分析

优点：

• 解耦与扩展性：这是最大的进步。现在，硬件信息（GPIO号）在led_device.c里，驱动逻辑在led_driver.c里。如果我要换一个GPIO，只需要修改led_device.c中的LED_GPIO定义，然后重新编译设备模块即可，驱动模块无需改动。这为支持多种硬件变体提供了可能。
• 更符合Linux内核设计哲学：分离关注点，使代码结构更清晰，更易于维护和协作。

缺点：

• 代码冗余：注意看，我们的硬件信息（GPIO 5）仍然以C代码的形式写死在led_device.c中。对于有几十个、上百个引脚定义的大型SoC，为每一个引脚都写一个这样的C文件是巨大的工作量，而且这些.c文件最终都要编译进内核，导致内核镜像膨胀。
• 仍需编译内核：修改设备信息（led_device.c）后，你需要重新编译这个模块（如果它被静态链接进内核，则需要重新编译内核）。对于产品迭代和现场调试，这仍然不够灵活。

实操心得：总线方法是理解Linux设备模型的关键一步。probe函数是驱动的“真正入口”，它取代了传统方法中的module_init。在probe里，你通过platform_get_resource等接口拿到硬件信息，然后完成设备的初始化。这种“匹配后初始化”的机制，是驱动动态加载和设备热插拔的基础。调试时，一定要用dmesg查看probe函数是否被成功调用，这是判断设备和驱动是否匹配成功的金标准。

5. 方法三：设备树方法——终极的硬件抽象

设备树（Device Tree）的出现，就是为了彻底解决总线方法中“设备信息硬编码在C文件”导致的冗余和僵化问题。它的思想非常巧妙：用一份结构化的文本文件（.dts或.dtsi）来描述整个系统的硬件拓扑和资源信息，在系统启动时由Bootloader（如U-Boot）传递给内核。内核解析这份文件，在内存中生成设备节点，然后依然通过总线模型（如platform总线）去匹配和加载驱动。

简单说，设备树取代了原来的led_device.c文件。硬件工程师或系统工程师修改.dts文件，而驱动工程师的led_driver.c几乎不用变，只需要学会如何从设备树节点中读取资源即可。

5.1 设备树语法与LED节点示例

设备树语法像一种描述硬件的数据结构。我们为LED在设备树中创建一个节点。

// 在板级设备树文件（如 my-board.dts）中添加 / { compatible = “my-company,my-board”; // ... 其他节点 ... led_device { compatible = “my-company,my-platform-led”; // 这是匹配驱动的关键属性！ status = “okay”; led-gpio = <&gpio 5 0>; // 指定使用GPIO控制器下的第5号引脚，0通常代表默认状态（如低电平有效） }; };

解释一下关键属性：

• compatible：这是最重要的属性，它是一个字符串列表。内核在匹配时，会拿驱动中定义的compatible值，与设备节点中的这个值进行比较。两者一致，则匹配成功。格式通常是“制造商,型号”。
• status：设为 “okay” 表示启用该设备，“disabled” 表示禁用。
• led-gpio：这是一个自定义属性，用来指定LED连接的GPIO。<&gpio 5 0>是phandle的写法，表示引用一个标签为gpio的节点（即GPIO控制器），使用其下的第5个引脚，0是标志位（如GPIO_ACTIVE_HIGH/LOW）。

5.2 驱动如何适配设备树

驱动端 (led_driver.c) 需要做关键修改：在probe函数中，不再使用platform_get_resource，而是使用设备树专用的API来获取属性。

首先，更新platform_driver的compatible列表，使其与设备树节点匹配：

static const struct of_device_id led_of_match[] = { { .compatible = “my-company,my-platform-led” }, // 必须与设备树中的compatible一致 { }, }; MODULE_DEVICE_TABLE(of, led_of_match); static struct platform_driver led_platform_driver = { .probe = led_probe, .remove = led_remove, .driver = { .name = “my_platform_led”, .owner = THIS_MODULE, .of_match_table = led_of_match, // 指定匹配表 }, };

然后，修改probe函数，从设备树节点读取属性：

#include <linux/of.h> #include <linux/of_gpio.h> // 使用GPIO专用API static int led_probe(struct platform_device *pdev) { struct device_node *np = pdev->dev.of_node; // 获取设备树节点指针 int gpio_num, ret; enum of_gpio_flags flags; if (!np) { dev_err(&pdev->dev, “No device tree node found.\n”); return -EINVAL; } // 方法1：使用GPIO子系统API（推荐） gpio_num = of_get_named_gpio_flags(np, “led-gpio”, 0, &flags); if (gpio_num < 0) { dev_err(&pdev->dev, “Failed to get ‘led-gpio’ property.\n”); return gpio_num; } led_gpio = gpio_num; // 例如得到 5 dev_info(&pdev->dev, “Probe: Got GPIO %d from DT.\n”, led_gpio); // 方法2：使用通用属性读取函数（适用于非GPIO属性） // u32 value; // ret = of_property_read_u32(np, “my-custom-value”, &value); // 后续的GPIO申请、配置、字符设备注册等与传统方法一致... ret = gpio_request(led_gpio, “my-led”); if (ret) { ... } gpio_direction_output(led_gpio, 0); // 初始化为输出低电平 // ... 注册字符设备等 ... return 0; }

5.3 设备树方法的巨大优势与工作流

优点：

• 彻底解耦，高度灵活：硬件描述（设备树）和驱动代码完全分离。更换硬件（如LED接到GPIO 6）时，只需修改设备树源文件（.dts），重新编译生成设备树二进制文件（.dtb），替换掉Bootloader加载的dtb文件即可。驱动模块（.ko）完全不需要重新编译。这极大地提高了产品定制和现场升级的灵活性。
• 消除冗余：一个.dts文件可以清晰描述整个板子的所有设备，无需为每个设备编写一个C文件，内核镜像更精简。
• 标准化与可读性：设备树是一种标准格式，不同架构的Linux内核都能理解，提高了代码的可移植性。硬件配置以文本形式呈现，一目了然。

工作流程：

1. 硬件工程师提供硬件原理图或配置。
2. 系统工程师根据硬件，修改或编写对应的设备树源文件（.dts）。
3. 使用设备树编译器（DTC）将.dts编译成二进制文件.dtb。
4. Bootloader（如U-Boot）在启动内核时，将.dtb的地址传递给内核。
5. 内核启动早期，解析.dtb文件，在内存中构建出设备树结构。
6. 驱动加载时，其of_match_table中的compatible字符串与设备树节点中的compatible进行比对。
7. 匹配成功，调用驱动的probe函数，驱动通过OF（Open Firmware）API从设备树节点中提取所需的硬件资源（如GPIO号、寄存器地址、中断号等）。
8. 驱动完成初始化，设备正常工作。

实操心得：切换到设备树方法后，驱动开发者的核心技能之一变成了“熟练阅读设备树绑定文档（Binding Document）”和“熟练使用OF API”。绑定文档描述了某个设备节点应该有哪些属性、什么格式。例如，GPIO属性通常推荐使用-gpios后缀（如led-gpios），并使用of_get_named_gpio来获取。务必在probe函数中做好错误检查，因为设备树可能被错误配置。使用dev_info/dev_err等带设备信息的打印函数，能让你在系统日志中更清晰地定位是哪个设备出了问题。

6. 三种方法对比与演进思考

为了更直观地理解这三种方法的区别和演进，我整理了一个对比表格：

从这张表可以清晰地看到Linux驱动开发演进的脉络：从“怎么做”到“怎么更好地做”。传统方法教会我们驱动的基本骨架；总线方法引入了“分离”和“匹配”的设计思想，这是理解Linux设备模型的关键；设备树方法则将这种思想发挥到极致，通过一份外部配置文件实现了极致的硬件抽象和灵活性。

我个人在实际迁移项目中的体会是：当你从旧的总线方法转向设备树方法时，初期会有些阵痛，需要花时间学习新的语法和API。但一旦掌握，你会发现开发和维护效率大大提升。特别是当需要为同一款SoC适配不同客户的不同底板时，设备树的优势无可比拟——我只需要准备不同的.dts文件，而驱动代码是通用的。这真正实现了“一个内核，多种硬件”的愿景。

7. 实战避坑指南与高级技巧

理论讲完了，最后分享一些我踩过坑才总结出来的实战经验，这些在官方文档里往往不会写得这么直白。

7.1 设备树匹配失败的常见原因

这是设备树驱动调试中最常见的问题，probe函数就是不执行。按以下顺序排查：

1. 检查兼容性字符串：这是第一要务。用cat /proc/device-tree/led_device/compatible命令（假设节点路径是/led_device）查看内核实际解析到的compatible值。必须与驱动中of_match_table里定义的字符串完全一致，包括大小写和标点。一个空格或逗号的差异都会导致匹配失败。
2. 检查节点状态：确保设备树节点中status = “okay”;。如果设为“disabled”，内核会忽略该节点。
3. 检查节点路径与别名：确保设备树节点放在正确的父节点下。有时会使用aliases节点给设备起一个短名，确保驱动查找的路径正确。
4. 检查内核配置：确认驱动是否被编译进内核（*）或编译为模块（M）。如果编译为模块，需要手动insmod。
5. 查看内核日志：使用dmesg | grep -i “led”或dmesg | grep -E “probe|match”查看相关日志。内核在匹配过程中通常会打印信息。

7.2 资源获取与内存映射的注意事项

1. GPIO使用：强烈建议使用GPIO子系统（gpio_request,gpio_direction_output,gpio_set_value）而不是直接操作寄存器。GPIO子系统会帮你管理GPIO的申请和冲突，更安全。通过设备树获取GPIO号后，一定要检查返回值是否为负数（错误）。
2. 寄存器地址映射：如果设备树中定义了reg属性（内存区域），应该使用platform_get_resource获取res，然后用devm_ioremap_resource(&pdev->dev, res)来映射。这个函数是“托管”版本的，它会自动在设备移除时释放映射，避免内存泄漏，并且会进行必要的安全检查。
3. 中断处理：如果设备树中定义了interrupts属性，使用platform_get_irq来获取中断号。同样，建议使用devm_request_irq这类托管函数申请中断。

7.3 驱动调试技巧

1. 善用printk和dev_*系列函数：在驱动的关键路径（如init,probe,open,write）加入打印信息。优先使用dev_info(&pdev->dev, “…” )、dev_err等，它们会自动附加设备信息，便于过滤日志。
2. 使用动态调试：在代码中加入pr_debug，然后通过echo ‘file led_driver.c +p’ > /sys/kernel/debug/dynamic_debug/control来动态开启/关闭该文件的调试信息，无需重新编译。
3. 查看 sysfs 信息：成功加载后，在/sys/class/led_class/（你创建的类）和/sys/devices/platform/下可以找到你的设备信息，这是验证设备是否成功注册的好方法。
4. 用户空间测试工具：除了自己写C测试程序，可以用echo 1 > /dev/my_led和cat /dev/my_led（如果实现了read）进行快速测试。用strace命令跟踪系统调用，可以确认open、write是否成功进入内核。

7.4 从传统/总线方法向设备树方法迁移的步骤

如果你有一个旧的总线方法驱动，想改为设备树方法，可以遵循以下步骤：

1. 驱动侧修改：
   • 在驱动结构中添加of_match_table。
   • 修改probe函数，将platform_get_resource等调用改为of_get_named_gpio、of_property_read_u32等OF API。
   • 确保remove函数正确释放资源（或使用devm_*系列函数自动管理）。
   • 将驱动中的platform_driver.driver.name保留，但匹配主要依靠of_match_table。
2. 设备树侧添加：
   • 在板级.dts文件中添加对应的设备节点。
   • 根据硬件手册，正确填写compatible、reg、interrupts、GPIO等属性。
   • 参考内核源码中的Documentation/devicetree/bindings/目录下的对应绑定文档，确保格式正确。
3. 测试与验证：
   • 编译新的设备树 (make dtbs)。
   • 更新Bootloader加载的dtb文件。
   • 加载驱动模块，观察dmesg日志，确认probe被调用且资源获取成功。

驱动开发是一个需要大量动手实践的领域。从点亮一颗LED开始，理解这三种方法的演进，你就掌握了Linux驱动开发的骨架和灵魂。剩下的，就是在具体的硬件和协议（如I2C、SPI、USB）中不断填充血肉。记住，多写代码，多查内核源码（include/linux/of*.h是设备树API的好去处），多分析日志，你就能从一个点灯的新手，逐渐成长为能驾驭复杂驱动的老手。