嵌入式Linux驱动开发实战：从字符设备到设备树与并发控制

1. 嵌入式驱动开发到底在做什么

刚入行那会儿，我对“驱动开发”这四个字的理解特别朴素——不就是写代码让硬件动起来吗？后来在项目里摸爬滚打了几年，踩过一堆坑之后才明白，驱动开发真正做的事情，是在硬件寄存器和操作系统内核之间架一座桥。这座桥要足够稳，稳到应用程序调用open、read、write的时候，完全感觉不到底层硬件的存在；同时又要足够灵活，灵活到能适配不同厂商、不同型号的芯片和外设。

嵌入式驱动开发的核心关键词就两个：嵌入式和驱动开发。前者决定了你的代码跑在资源受限的环境里，内存可能只有几十兆，CPU 主频可能不到 1GHz，甚至没有 MMU；后者决定了你必须跟寄存器、中断、DMA、时钟树这些底层玩意儿打交道。两者叠加在一起，就注定了这个方向不是纯写业务逻辑那么轻松。

这篇文章适合谁看？如果你正在学嵌入式 Linux，想从“会点灯”进阶到“能写一个完整的字符设备驱动”；如果你在面试中被问过“platform 总线和 I2C 总线的区别”却答得磕磕巴巴；如果你手里有一块开发板，想跑通从设备树到驱动 probe 的完整链路——那这篇内容就是写给你的。我会从整体设计思路讲到具体实操，把踩过的坑和总结出来的经验都摊开来说。

2. 驱动开发的整体设计思路与架构选型

2.1 为什么驱动要分层：从“一坨代码”到“可维护架构”

我见过不少初学者写驱动，习惯把所有逻辑塞进一个.c文件里：寄存器操作、中断处理、文件操作接口、硬件初始化全混在一起。这种写法在单一设备上确实能跑，但一旦项目里要支持多个相似设备，或者硬件版本迭代了，代码就会变成一坨谁都不敢动的“屎山”。

Linux 内核给出的答案是分层与分离。以字符设备为例，内核把驱动拆成了几个层次：最上层是文件操作接口（file_operations），负责和用户空间交互；中间是设备模型（device、driver、bus），负责设备与驱动的匹配和管理；最下层是硬件操作，直接读写寄存器或调用子系统 API。

这样分层的好处很直接：换硬件时，只需要改最下层的硬件操作部分，上层接口和用户空间程序完全不用动。我做过一个项目，同一套应用代码要跑在三个不同厂商的触摸屏上，正是因为驱动层做了分离，应用层一行代码都没改。

2.2 总线模型的选择：platform、I2C、SPI 还是 USB

选总线模型是驱动开发里第一个关键决策。很多新手会问：我的设备到底该挂在哪条总线上？这里给一个实用的判断逻辑。

platform 总线适合那些“直接映射到内存地址”或者“没有物理总线可枚举”的设备。比如 SoC 内部的 GPIO 控制器、时钟控制器、DMA 控制器，这些设备在芯片内部通过 AHB/AXI 总线连接，不需要热插拔，地址固定。用 platform 总线的好处是，设备信息可以通过设备树描述，驱动和设备的匹配由内核自动完成。

I2C 和 SPI适合外挂的传感器、EEPROM、显示屏等。I2C 两根线能挂多个设备，适合低速、低引脚数的场景；SPI 速度快、全双工，适合需要高吞吐的外设比如 TFT 屏、高速 ADC。选哪个主要看外设本身支持什么接口，以及你的引脚资源够不够。

USB则适合需要热插拔、标准化的设备。但 USB 驱动开发的复杂度明显更高，涉及枚举、端点、URB 等概念，新手不建议一上来就啃。

我个人的建议是：先从 platform 驱动入手，因为它最能帮你理解设备树、probe 机制、资源获取这些核心概念。等 platform 驱动写熟了，再去看 I2C/SPI 驱动，你会发现它们只是在 platform 的基础上多了一层总线通信的封装。

2.3 设备树：驱动和硬件的“合同”

设备树（Device Tree）是嵌入式 Linux 驱动开发绕不开的东西。你可以把它理解成驱动和硬件之间的一份“合同”：硬件工程师在设备树里描述“我有什么设备、地址是多少、中断号是多少、时钟怎么接”，驱动工程师在代码里说“我要什么资源、怎么操作”。

为什么要有设备树？因为 ARM 架构不像 x86 有 ACPI 和 BIOS 来枚举硬件。在设备树出现之前，每个板子的硬件信息都硬编码在内核的board-xxx.c文件里，导致内核里堆满了各种板级代码。设备树把这些信息从内核代码里抽出来，变成独立的.dts文件，编译成.dtb后由 bootloader 传给内核。

写驱动时，你需要关注设备树里的几个关键属性：compatible用于匹配驱动，reg描述寄存器地址范围，interrupts描述中断信息，clocks和pinctrl描述时钟和引脚配置。这些属性在驱动里通过of_系列函数读取，比如of_get_named_gpio、irq_of_parse_and_map。

注意：设备树里的compatible字符串必须和驱动里的of_device_id表完全一致，包括大小写和连字符。我见过有人因为把fsl,imx6q-uart写成了fsl,imx6q_uart，调试了一整天才发现匹配不上。

3. 核心细节解析与实操要点

3.1 字符设备驱动的骨架：从 module_init 到 file_operations

字符设备驱动是最基础也是最常见的驱动类型。它的核心结构可以用一句话概括：注册一个设备号，实现一组文件操作接口，把硬件操作封装在这些接口里。

先看模块的入口和出口。每个驱动模块都需要module_init和module_exit来告诉内核“我什么时候加载、什么时候卸载”。在入口函数里，通常要做三件事：申请设备号、初始化硬件、注册字符设备。

static int __init my_driver_init(void) { int ret; dev_t devno; /* 1. 申请设备号，主设备号设为0表示由内核动态分配 */ ret = alloc_chrdev_region(&devno, 0, 1, "my_device"); if (ret < 0) { pr_err("alloc_chrdev_region failed\n"); return ret; } /* 2. 初始化 cdev 并添加到内核 */ cdev_init(&my_cdev, &my_fops); my_cdev.owner = THIS_MODULE; ret = cdev_add(&my_cdev, devno, 1); if (ret < 0) { unregister_chrdev_region(devno, 1); return ret; } /* 3. 创建设备节点 /dev/my_device */ my_class = class_create(THIS_MODULE, "my_class"); device_create(my_class, NULL, devno, NULL, "my_device"); return 0; }

这里有几个细节值得展开说。alloc_chrdev_region和register_chrdev_region的区别在于前者让内核动态分配主设备号，后者需要你指定一个固定的主设备号。动态分配的好处是不会和其他驱动冲突，但缺点是每次加载主设备号可能不同，所以一定要配合class_create和device_create自动创建设备节点，而不是让用户手动mknod。

file_operations结构体是驱动和用户空间之间的接口定义。最常用的几个成员是open、release、read、write、unlocked_ioctl。其中unlocked_ioctl是控制接口的主力，用来传递命令和参数。注意新内核已经不再使用带 BKL（大内核锁）的ioctl，而是用unlocked_ioctl，你需要自己在驱动里处理并发保护。

3.2 并发与竞态：自旋锁、互斥锁和原子操作怎么选

驱动开发里最容易被忽视、也最容易出问题的就是并发控制。用户空间可能有多个进程同时打开同一个设备，中断处理函数可能随时打断你的代码，内核还支持 SMP 多核并行。如果你的驱动里共享数据没有保护，轻则数据错乱，重则内核崩溃。

Linux 内核提供了几种并发控制机制，选哪种取决于你的场景。

自旋锁（spinlock）适合保护临界区很短的场景，尤其是在中断上下文里。自旋锁的特点是“忙等待”，拿不到锁就原地打转，所以临界区里绝对不能睡眠。我一般用自旋锁保护那些只是读写几个寄存器的操作。

互斥锁（mutex）适合临界区可能睡眠的场景，比如需要拷贝大量数据到用户空间、需要等待硬件响应。互斥锁拿不到锁时会睡眠，让出 CPU 给其他任务。但互斥锁不能在中断上下文里使用，因为中断处理函数不能睡眠。

原子操作（atomic）适合简单的计数器、标志位。比如统计中断次数，用atomic_inc就够了，不需要上锁。

完成量（completion）适合“一个线程等待另一个线程完成某件事”的场景。比如驱动里启动 DMA 传输后，等待 DMA 完成中断来唤醒。

实操心得：我刚开始写驱动时，觉得加锁麻烦，经常偷懒不加。结果在一次压力测试中，两个进程同时读写同一个寄存器，导致设备直接挂死。从那以后，我养成了一个习惯：只要有两个以上的执行路径可能访问同一份数据，就先想清楚用什么锁。

3.3 中断处理：上半部和下半部的分工

中断是驱动开发里另一个核心话题。硬件产生中断后，CPU 会跳转到中断处理函数。但中断处理函数有一个硬性要求：必须尽快返回。因为中断处理期间，当前 CPU 上的其他中断可能被屏蔽，如果处理时间太长，系统响应就会变差。

所以 Linux 把中断处理拆成了两部分：上半部（top half）和下半部（bottom half）。上半部就是中断处理函数本身，它只做最紧急的事情，比如读取中断状态寄存器、清除中断标志、记录数据到缓冲区。下半部则负责耗时的处理，比如解析数据、唤醒等待队列、拷贝数据到用户空间。

下半部的实现方式有几种：softirq、tasklet、工作队列（workqueue）。softirq 性能最高但使用最复杂，一般驱动开发者用不到；tasklet 基于 softirq 实现，运行在中断上下文，不能睡眠；工作队列运行在进程上下文，可以睡眠，适合需要调用可能睡眠的函数的场景。

我一般的选择逻辑是：如果下半部只是简单处理数据，用 tasklet；如果需要调用msleep、mutex_lock或者访问用户空间，用工作队列。

/* 中断处理函数示例 */ static irqreturn_t my_isr(int irq, void *dev_id) { struct my_dev *dev = dev_id; u32 status; /* 读取中断状态 */ status = readl(dev->base + REG_STATUS); if (!(status & IRQ_PENDING)) return IRQ_NONE; /* 清除中断标志 */ writel(status, dev->base + REG_STATUS); /* 调度下半部 */ tasklet_schedule(&dev->my_tasklet); return IRQ_HANDLED; }

注意IRQ_NONE和IRQ_HANDLED的返回值。如果中断不是你的设备产生的，必须返回IRQ_NONE，否则内核会认为中断处理有问题。共享中断线上尤其要注意这一点。

3.4 设备树匹配与 probe 函数的执行流程

platform 驱动的核心是probe函数。当内核启动或者驱动模块加载时，内核会遍历 platform 总线上的设备和驱动，通过compatible属性进行匹配。匹配成功后，调用驱动的probe函数。

probe函数里通常要做这些事：获取设备树中的资源（寄存器地址、中断号、GPIO、时钟），初始化硬件，注册字符设备或其他子系统接口。

static int my_probe(struct platform_device *pdev) { struct my_dev *dev; struct resource *res; /* 分配设备私有数据结构 */ dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; /* 获取寄存器地址 */ res = platform_get_resource(pdev, IORESOURCE_MEM, 0); dev->base = devm_ioremap_resource(&pdev->dev, res); if (IS_ERR(dev->base)) return PTR_ERR(dev->base); /* 获取中断号 */ dev->irq = platform_get_irq(pdev, 0); if (dev->irq < 0) return dev->irq; /* 注册中断处理函数 */ ret = devm_request_irq(&pdev->dev, dev->irq, my_isr, 0, "my_device", dev); if (ret) return ret; platform_set_drvdata(pdev, dev); return 0; }

这里大量使用了devm_前缀的函数，这是内核的“设备资源管理”机制。用devm_申请的资源会在设备卸载或驱动移除时自动释放，省去了手动清理的麻烦，也避免了资源泄漏。我强烈建议在probe函数里优先使用devm_系列函数。

4. 实操过程与核心环节实现

4.1 环境搭建：交叉编译工具链和内核源码准备

动手写驱动之前，环境搭建是第一步。嵌入式开发通常需要交叉编译，因为目标板的 CPU 架构和你的开发机不一样。比如你的开发机是 x86_64，目标板是 ARM Cortex-A7，就需要用arm-linux-gnueabihf-前缀的工具链。

工具链的获取方式有几种：从芯片厂商的 SDK 里拿，用 Buildroot 或 Yocto 自己构建，或者用 Linaro 发布的通用工具链。我一般推荐用厂商 SDK 里的工具链，因为兼容性最有保障。

内核源码的准备同样重要。驱动编译需要内核头文件和配置信息。你需要先获取和目标板运行的内核完全一致的内核源码，然后执行make defconfig或使用厂商提供的defconfig文件，再执行make modules_prepare来准备编译环境。

# 设置交叉编译环境变量 export ARCH=arm export CROSS_COMPILE=arm-linux-gnueabihf- export KERNEL_DIR=/path/to/kernel/source # 准备内核模块编译环境 cd $KERNEL_DIR make imx_v6_v7_defconfig make modules_prepare

驱动模块的 Makefile 写法也有讲究。一个典型的驱动 Makefile 长这样：

obj-m += my_driver.o my_driver-objs := main.o hardware.o KERNEL_DIR ?= /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KERNEL_DIR) M=$(PWD) modules clean: $(MAKE) -C $(KERNEL_DIR) M=$(PWD) clean

obj-m表示编译成可加载模块，my_driver-objs指定模块由哪些目标文件组成。编译时用make -C $(KERNEL_DIR) M=$(PWD) modules，-C切换到内核目录，M=指定模块源码目录。

4.2 一个完整的 GPIO 驱动实例：从设备树到用户空间

下面用一个完整的 GPIO 驱动例子，把前面讲的东西串起来。这个驱动控制一个 LED，用户空间可以通过write来点亮或熄灭。

先看设备树节点：

my_led: my-led { compatible = "mycompany,my-led"; led-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; status = "okay"; };

驱动代码的核心部分：

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/gpio/consumer.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/uaccess.h> struct my_led_dev { struct gpio_desc *led_gpio; struct cdev cdev; dev_t devno; struct class *cls; }; static int my_led_open(struct inode *inode, struct file *filp) { struct my_led_dev *dev = container_of(inode->i_cdev, struct my_led_dev, cdev); filp->private_data = dev; return 0; } static ssize_t my_led_write(struct file *filp, const char __user *buf, size_t count, loff_t *ppos) { struct my_led_dev *dev = filp->private_data; char kbuf[8]; if (count > sizeof(kbuf) - 1) count = sizeof(kbuf) - 1; if (copy_from_user(kbuf, buf, count)) return -EFAULT; kbuf[count] = '\0'; if (kbuf[0] == '1') gpiod_set_value(dev->led_gpio, 1); else if (kbuf[0] == '0') gpiod_set_value(dev->led_gpio, 0); return count; } static const struct file_operations my_led_fops = { .owner = THIS_MODULE, .open = my_led_open, .write = my_led_write, }; static int my_led_probe(struct platform_device *pdev) { struct my_led_dev *dev; int ret; dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; /* 从设备树获取 GPIO */ dev->led_gpio = devm_gpiod_get(&pdev->dev, "led", GPIOD_OUT_LOW); if (IS_ERR(dev->led_gpio)) { dev_err(&pdev->dev, "Failed to get LED GPIO\n"); return PTR_ERR(dev->led_gpio); } /* 申请设备号 */ ret = alloc_chrdev_region(&dev->devno, 0, 1, "my_led"); if (ret) return ret; cdev_init(&dev->cdev, &my_led_fops); dev->cdev.owner = THIS_MODULE; ret = cdev_add(&dev->cdev, dev->devno, 1); if (ret) goto err_cdev; dev->cls = class_create(THIS_MODULE, "my_led_class"); if (IS_ERR(dev->cls)) { ret = PTR_ERR(dev->cls); goto err_class; } device_create(dev->cls, NULL, dev->devno, NULL, "my_led"); platform_set_drvdata(pdev, dev); dev_info(&pdev->dev, "my_led probed successfully\n"); return 0; err_class: cdev_del(&dev->cdev); err_cdev: unregister_chrdev_region(dev->devno, 1); return ret; } static int my_led_remove(struct platform_device *pdev) { struct my_led_dev *dev = platform_get_drvdata(pdev); device_destroy(dev->cls, dev->devno); class_destroy(dev->cls); cdev_del(&dev->cdev); unregister_chrdev_region(dev->devno, 1); return 0; } static const struct of_device_id my_led_of_match[] = { { .compatible = "mycompany,my-led" }, { } }; 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("A simple GPIO LED driver");

这个例子里有几个关键点。devm_gpiod_get的第二个参数"led"对应设备树里的led-gpios属性名。GPIOD_OUT_LOW表示初始化为输出低电平。container_of宏用于从cdev指针反推出包含它的设备结构体指针，这是内核里非常常用的技巧。

用户空间的操作就很简单了：

echo 1 > /dev/my_led # 点亮 LED echo 0 > /dev/my_led # 熄灭 LED

4.3 调试手段：printk、ftrace 和动态调试

驱动调试比应用调试难得多，因为驱动跑在内核空间，不能随便用 gdb 打断点。我常用的调试手段有几种。

printk是最基础的，通过printk或pr_info、dev_dbg等宏输出日志。日志级别从 0 到 7，数字越小优先级越高。dev_dbg默认不会输出，需要开启DEBUG宏或者在运行时通过dynamic_debug控制。

ftrace是内核自带的跟踪工具，可以跟踪函数调用、中断、调度等事件。通过/sys/kernel/debug/tracing/目录下的文件控制。比如想看某个函数的调用栈，可以设置function_graph跟踪器。

动态调试（dynamic debug）可以在运行时开启或关闭某条pr_debug语句，不需要重新编译内核。通过/sys/kernel/debug/dynamic_debug/control文件控制。

# 开启某个文件的动态调试 echo 'file my_driver.c +p' > /sys/kernel/debug/dynamic_debug/control # 使用 ftrace 跟踪函数调用 echo function_graph > /sys/kernel/debug/tracing/current_tracer echo my_probe > /sys/kernel/debug/tracing/set_ftrace_filter echo 1 > /sys/kernel/debug/tracing/tracing_on

踩坑记录：有一次驱动 probe 一直失败，但printk输出的信息太少，看不出问题在哪。后来用devm_ioremap_resource的返回值判断，发现是设备树里的reg属性地址范围写错了，导致ioremap失败。从那以后，我在probe里每个可能失败的步骤后面都加了dev_err输出，方便定位问题。

5. 常见问题与排查技巧实录

5.1 驱动加载失败：从 insmod 报错到问题定位

insmod或modprobe加载驱动失败是最常见的问题。错误信息通常比较隐晦，需要结合dmesg来看。

-EPROBE_DEFER是新手最容易困惑的错误码。它的意思是“我现在还不能初始化，等依赖的资源就绪后再试”。内核会把驱动放到延迟探测队列里，稍后重试。如果你在probe里获取时钟、GPIO、regulator 失败，应该返回-EPROBE_DEFER而不是直接返回错误，否则驱动可能永远无法加载。

5.2 设备树匹配不上：compatible 属性的那些坑

设备树匹配失败是另一个高频问题。现象是驱动加载了，但probe函数根本没被调用。排查步骤是这样的：

首先确认设备树是否被正确编译和加载。在目标板上执行ls /proc/device-tree/，看看你的设备节点是否存在。如果不存在，说明设备树没有编译进去或者 bootloader 没有传递正确的 dtb。

然后确认compatible属性是否匹配。在/proc/device-tree/下找到你的节点，用hexdump -C compatible查看属性值。注意设备树里的字符串是以\0结尾的，比较时要去掉结尾的空字符。

最后确认驱动是否注册到了正确的总线。platform 驱动注册到 platform 总线，I2C 驱动注册到 I2C 总线。如果设备树节点在 I2C 控制器下面，但驱动注册成了 platform 驱动，那肯定匹配不上。

经验之谈：我习惯在probe函数的第一行加一句dev_info(&pdev->dev, "probe called\n")。这样只要probe被调用了，就能在dmesg里看到。如果没看到，说明匹配环节出了问题，不用往下查了。

5.3 内存泄漏与资源释放：devm 机制的正确使用

驱动里的内存泄漏比应用层更危险，因为内核内存是有限的，泄漏多了会导致系统 OOM。常见的泄漏点包括：kmalloc后忘记kfree，ioremap后忘记iounmap，request_irq后忘记free_irq，class_create后忘记class_destroy。

devm_机制就是为解决这个问题而生的。所有devm_前缀的函数申请的资源都会绑定到设备上，设备卸载时自动释放。我现在的习惯是：只要能用devm_的地方，绝不用非devm_版本。

但devm_也不是万能的。有些资源没有devm_版本，比如cdev_add对应的cdev_del，alloc_chrdev_region对应的unregister_chrdev_region。这些还是需要手动在remove函数里释放。另外，devm_资源的释放顺序和申请顺序相反，如果资源之间有依赖关系，需要注意释放顺序是否正确。

5.4 中断不触发：从硬件到软件的排查链路

中断不触发的问题排查起来比较麻烦，因为涉及硬件和软件两个层面。我一般按照以下顺序排查：

先确认硬件是否真的产生了中断。用示波器或逻辑分析仪测量中断引脚，看有没有电平变化。如果硬件没有中断信号，那问题在硬件侧，检查外设配置、中断引脚连接、上拉电阻等。

如果硬件有中断信号，但驱动里没反应，检查中断号是否正确。在设备树里interrupts属性描述的是中断号和触发方式，但中断号需要经过中断控制器映射。用irq_of_parse_and_map或platform_get_irq获取映射后的虚拟中断号。

然后检查request_irq的返回值。如果返回-EBUSY，说明中断线被其他驱动占用了，需要确认是否用了IRQF_SHARED标志。如果返回-EINVAL，说明中断号无效或处理函数为空。

最后检查中断是否被屏蔽。在/proc/interrupts里可以看到每个中断号的触发次数。如果次数一直是 0，说明中断根本没有到达 CPU。如果次数在增加但你的处理函数没执行，说明中断被其他处理函数抢占了，或者你的IRQ_NONE返回值有问题。

6. 驱动开发的进阶方向与学习路线

6.1 从字符设备到子系统：输入、显示、音频框架

字符设备驱动是入门，但实际项目里你更多是跟各种子系统打交道。比如做触摸屏驱动，你需要了解Input 子系统，把触摸事件通过input_report_abs上报；做显示屏驱动，你需要了解DRM 框架或Framebuffer 框架；做音频驱动，你需要了解ASoC 框架，理解 DAI、DAPM、codec 这些概念。

这些子系统的学习曲线比字符设备陡峭得多，但掌握之后你会发现，它们本质上还是“注册设备、实现回调、处理中断”这套逻辑，只是框架帮你处理了很多通用的事情。我的建议是：先精通一个子系统，再横向扩展。比如你先把 Input 子系统吃透，写一个完整的触摸屏驱动，然后再去看 DRM 或 ASoC，会发现很多设计思想是相通的。

6.2 嵌入式 AI 与驱动开发的结合点

最近两年嵌入式 AI 很火，驱动开发和 AI 的结合点主要在异构计算上。比如 SoC 里集成了 NPU（神经网络处理单元），驱动需要负责 NPU 的初始化、内存分配、任务调度、中断处理。这类驱动通常比普通外设驱动复杂，因为涉及 DMA 缓冲区管理、多核通信、固件加载等。

另一个结合点是传感器数据采集。AI 模型需要摄像头、麦克风、IMU 等传感器的数据，这些传感器的驱动质量直接影响数据质量。比如摄像头驱动如果丢帧或者曝光控制不准，再好的模型也跑不出好结果。

如果你有驱动开发基础，想往嵌入式 AI 方向转，我建议先补一下计算机体系结构的知识，理解 DMA、Cache 一致性、内存屏障这些概念，然后找一个带 NPU 的开发板，从跑通官方 demo 开始，逐步深入到驱动层。

6.3 面试中高频出现的驱动开发问题

嵌入式驱动开发的面试，八股文主要集中在几个方向：总线模型（platform、I2C、SPI 的区别和适用场景）、并发控制（自旋锁和互斥锁的区别、中断上下文为什么不能睡眠）、内存管理（kmalloc 和 vmalloc 的区别、DMA 一致性内存）、设备树（compatible 匹配机制、常用属性）。

我整理了一个高频问题速查表：

面试里除了八股，还会问项目经验。我建议准备一两个你真正做过的驱动项目，能说清楚：这个驱动控制什么硬件，用了什么总线，怎么处理中断和并发，遇到了什么问题怎么解决的。面试官更看重你解决实际问题的能力，而不是背了多少概念。

6.4 持续学习：内核源码和开源项目

驱动开发的学习离不开读内核源码。但内核源码几千万行，不可能全读。我的方法是按需阅读：写字符设备驱动时，去看drivers/char/下的简单驱动；写 I2C 驱动时，去看drivers/i2c/下的框架代码和具体芯片驱动；遇到不认识的 API，用grep在内核源码里搜，看别人怎么用的。

开源项目也是很好的学习资源。比如 Linux 内核本身、U-Boot、Buildroot 这些项目里都有大量驱动代码。我经常在 GitHub 上搜platform_driver或i2c_driver，看别人是怎么组织代码的。但要注意，开源项目的代码质量参差不齐，有些驱动写得很规范，有些则是“能跑就行”。读的时候要有判断力，学习好的设计，避免坏的实践。

最后分享一个我个人的习惯：每写一个新驱动，都先找一个内核里类似的驱动作为参考。比如写 GPIO 驱动，就参考drivers/gpio/gpio-*.c；写 I2C 传感器驱动，就参考drivers/iio/下的同类传感器。这样不仅能加快开发速度，还能保证代码风格和内核社区一致，减少被 maintainer 打回的概率。