Linux设备驱动开发实战：字符设备框架、设备树与中断处理详解

做Linux驱动开发这行也有十几年了，从最早的2.6内核一路折腾到现在的6.x，踩过的坑比我写过的代码还多。最近带了好几个新人，发现大家拿到“Linux设备驱动开发”这个题目，第一反应都是去啃《Linux设备驱动开发详解》那本大部头，结果看一个月还在字符设备那章打转。这篇文章我换个思路，不按教科书来，直接从实际项目里最常用到的字符设备框架、设备树配置、中断处理、I2C驱动这几块入手，把底层原理和实操步骤揉碎了讲清楚。不管你是在做嵌入式、工控板卡，还是ZYNQ这类带硬核ARM的FPGA平台，这套东西都是绕不开的底座。全文会贴大量可直接用的代码和配置，也会把我这些年调试过程中踩过的坑、总结的排查思路一并放出来，适合刚入门驱动开发、或者已经写了一些驱动但总感觉哪里没吃透的朋友。

1. 先搞明白设备驱动在Linux里到底承担什么角色

1.1 驱动不是“写代码”，而是“填接口”

很多新人刚接触驱动开发，最容易犯的错是把驱动当成普通的应用层程序来写。实际上，驱动工作在Linux内核态，它没有main函数，也不归你主动调用，而是被动地等待内核来调用你注册的那些回调函数。用生活里的例子类比，驱动就像酒店的客房服务电话——客人（应用程序）拨某个分机号（设备文件），前台（VFS虚拟文件系统）接通后转给对应的服务员（驱动），服务员按流程执行打扫（read）、送餐（write）、调配（ioctl）这些动作。你要做的，就是把这个服务员培训到位，也就是实现一组标准接口。

这组标准接口在Linux内核里对应一个关键结构体：struct file_operations。它定义了open、release、read、write、unlocked_ioctl、mmap、poll等一堆函数指针，你的驱动只需要填充自己需要的那几个，不需要的全部置NULL就行。内核在运行时通过设备文件的主设备号和次设备号找到对应的cdev结构体，再通过cdev拿到你填充好的file_operations，从而完成从“用户打开/dev/xxx”到“执行你的驱动代码”的完整链路。

理解这个链路特别重要。你去看网上的字符设备驱动教程，几乎都会贴一个初始化函数、一个注册cdev的函数、一组file_operations回调，看起来好像是固定模板，其实背后就是这条链路在起作用。一旦你明白了“应用层open → VFS → cdev → file_operations”这条调用链，再去读任何驱动源码，都不会觉得是看天书。

1.2 字符设备、块设备、网络设备怎么选

Linux设备驱动大体分三类：字符设备、块设备、网络设备。它们的区别不在于硬件本身，而在于数据的组织方式和访问模式。

• 字符设备：数据按字节流顺序读写，没有缓冲区，没有随机访问的概念。串口、GPIO、I2C、SPI、帧缓冲（LCD）都属于这一类。绝大多数入门驱动的教程都拿字符设备开刀，因为它最简单，从用户态open之后，read/write天然就是顺序的。
• 块设备：数据按固定大小的块读写，内核和硬件之间还有page cache这层缓冲。硬盘、eMMC、SD卡都是典型的块设备。块设备驱动比字符设备复杂得多，因为要处理请求队列、I/O调度、分区表，新手不建议先碰。
• 网络设备：它不走/dev下的设备节点，而是通过net_device结构体和socket接口交互。数据以sk_buff为单位传递，涉及协议栈、NAPI、DMA环形队列等等，是三类里面最抽象、最难上手的。

实际项目里，90%以上的板级外设驱动都属于字符设备类。所以这篇文章后面的内容，我会把重心放在字符设备驱动和它周边的设备树、中断、并发控制上。把这些吃透了，你再去啃块设备和网络设备，至少有个对照坐标，不会两眼一抹黑。

2. 字符设备驱动框架：先把底座打牢

2.1 设备号与cdev注册的全流程

写字符设备驱动，第一步是拿到设备号。设备号由主设备号和次设备号组成，主设备号标识驱动类型，次设备号标识同类型下的具体设备实例。内核里可以用register_chrdev_region静态申请已知的设备号，也可以用alloc_chrdev_region让内核动态分配主设备号。实践中我几乎都是用动态分配，因为静态指定主设备号很容易跟其他驱动冲突，而且维护麻烦。

第二步是初始化cdev结构体并添加到内核。标准流程是：

1. cdev_init(&cdev, &fops)，把cdev和file_operations绑定；
2. cdev_add(&cdev, devno, count)，把cdev注册进内核，指定从devno开始的count个设备号。

第三步是创建设备类和设备节点。只做前两步的话，应用层还需要手动mknod /dev/xxx c 主设备号 次设备号才能访问，这在实际交付时显然不现实。更规范的做法是使用class_create和device_create，这样当驱动加载时，内核会自动在/dev下创建对应的设备节点，应用层直接打开就行。

这三步的顺序千万不要搞反。我之前见过有人先cdev_add再创建class，结果设备节点创建好了但cdev还没注册，应用层一打开就报“No such device”，排查了半天才发现是注册顺序问题。内核在device_create的时候会尝试找对应的cdev，找不到就报错，所以顺序一定是：设备号 → cdev_add → class → device。

2.2 file_operations里最常用的几个回调

struct file_operations定义在内核头文件linux/fs.h里，字段非常多，但实际项目里如果只做基础读写控制，绝大多数时候只需要实现下面几个：

这里有个细节值得注意：新版内核里ioctl已经改成了unlocked_ioctl，因为内核在调用ioctl时会持有大内核锁（BKL），而BKL在新内核中被逐步移除，所以驱动里应该实现unlocked_ioctl而不是ioctl。很多老教程还在用ioctl，在4.x以上的内核里编译会直接报错或行为异常。

read/write回调还有个经典难点：用户空间地址不能直接访问。驱动运行在内核态，但用户传入的buf指针是用户空间的虚拟地址，直接在内核态解引用用户空间指针是违法的，轻则触发page fault，重则导致内核崩溃。正确的做法是用copy_to_user和copy_from_user这两个内核API做数据拷贝，它们内部会处理地址合法性检查和缺页处理。新手最容易踩的坑就是图省事直接memcpy，结果一加载驱动就报“BUG: unable to handle kernel paging request”，看了半天不知道问题出在哪。

2.3 一个最小的字符设备驱动模板

把上面这些知识点串起来，就是一个能直接用的最小模板。这个模板我一直在用，改改名字和回调函数就能适配大部分简单外设：

#include <linux/module.h> #include <linux/fs.h> #include <linux/cdev.h> #include <linux/device.h> #include <linux/uaccess.h> #define DEVICE_NAME "mydemo" #define CLASS_NAME "mydemo_class" static int major; static struct class *demo_class; static struct device *demo_device; static struct cdev demo_cdev; static int demo_open(struct inode *inode, struct file *filp) { printk(KERN_INFO "demo: device opened\n"); return 0; } static int demo_release(struct inode *inode, struct file *filp) { printk(KERN_INFO "demo: device closed\n"); return 0; } static ssize_t demo_read(struct file *filp, char __user *buf, size_t count, loff_t *offset) { char kernel_buf[64] = "hello from driver\n"; size_t len = strlen(kernel_buf); if (count < len) return -EINVAL; if (copy_to_user(buf, kernel_buf, len)) return -EFAULT; return len; } static ssize_t demo_write(struct file *filp, const char __user *buf, size_t count, loff_t *offset) { char kernel_buf[128]; if (count > sizeof(kernel_buf)) return -EINVAL; if (copy_from_user(kernel_buf, buf, count)) return -EFAULT; kernel_buf[count] = '\0'; printk(KERN_INFO "demo: received %s\n", kernel_buf); return count; } static const struct file_operations demo_fops = { .owner = THIS_MODULE, .open = demo_open, .release = demo_release, .read = demo_read, .write = demo_write, }; static int __init demo_init(void) { dev_t devno; if (alloc_chrdev_region(&devno, 0, 1, DEVICE_NAME)) { pr_err("demo: failed to allocate chrdev region\n"); return -ENODEV; } major = MAJOR(devno); cdev_init(&demo_cdev, &demo_fops); if (cdev_add(&demo_cdev, devno, 1)) { pr_err("demo: cdev_add failed\n"); unregister_chrdev_region(devno, 1); return -ENODEV; } demo_class = class_create(CLASS_NAME); if (IS_ERR(demo_class)) { cdev_del(&demo_cdev); unregister_chrdev_region(devno, 1); return PTR_ERR(demo_class); } demo_device = device_create(demo_class, NULL, devno, NULL, DEVICE_NAME); if (IS_ERR(demo_device)) { class_destroy(demo_class); cdev_del(&demo_cdev); unregister_chrdev_region(devno, 1); return PTR_ERR(demo_device); } pr_info("demo: driver registered, major=%d\n", major); return 0; } static void __exit demo_exit(void) { dev_t devno = MKDEV(major, 0); device_destroy(demo_class, devno); class_destroy(demo_class); cdev_del(&demo_cdev); unregister_chrdev_region(devno, 1); pr_info("demo: driver unregistered\n"); } module_init(demo_init); module_exit(demo_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("A minimal character device driver");

配套的Makefile也是老规矩：

obj-m := mydemo.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) all: $(MAKE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) -C $(KDIR) M=$(PWD) clean

编译好之后，insmod mydemo.ko，然后用dmesg看内核日志，如果能看到“demo: driver registered”，说明加载成功。接着写个简单的应用层测试程序，open/dev/mydemo，read一下，能看到“hello from driver”就是真正跑通了。

注意：内核打印不要用printf，要用printk或pr_info。另外MODULE_LICENSE("GPL")尽量写上，否则某些内核API会以“符号不可用”的方式间接惩罚你，报错信息往往还很隐晦。

3. 设备树配置：让驱动和硬件解耦的核心手段

3.1 为什么要用设备树

老一代的ARM Linux驱动，硬件信息都是硬编码在源码里的。换一个GPIO引脚、改一个中断号，就得改驱动代码重新编译，内核里充斥着各种板级文件，维护成本极高。设备树（Device Tree）出现后，硬件拓扑信息被抽离出来，变成一棵独立的树形描述，驱动只需要通过设备树API去读取自己关心的属性，就能实现“一套驱动，多板通用”。

设备树本质是一个描述硬件资源的文本文件（.dts），通过编译器dtc编译成二进制的dtb文件，内核启动时解析dtb，构建出platform_device的列表，然后和驱动列表做匹配。匹配成功就触发驱动的probe函数，在probe里你可以通过device_property_read_*或of_*系列API，拿到你在设备树里填写的寄存器地址、中断号、GPIO编号等资源。

这种“硬件描述与驱动逻辑分离”的思路，带来的实际好处非常明显。我在ZYNQ平台上做过一个项目，同一块板卡出了三个硬件版本，每个版本的ADC使能引脚都不一样。如果把引脚配置写在驱动里，就要维护三套代码。改成设备树之后，驱动代码完全不变，只改dts文件，重新编译设备树再烧写，三句话的事。

3.2 设备树节点如何与驱动匹配

设备树中每个设备节点都有一个compatible属性，这个属性就是驱动和设备节点之间的“暗号”。驱动在of_device_id表里声明自己支持哪些compatible字符串，内核匹配时会把设备节点的compatible与驱动的of_device_id列表逐一比对，匹配成功就调probe。

举个例子，假设你的硬件上有一颗I2C温度传感器，设备树节点可能长这样：

&i2c1 { status = "okay"; tmp102@49 { compatible = "ti,tmp102"; reg = <0x49>; interrupt-parent = <&gpio1>; interrupts = <13 IRQ_TYPE_EDGE_FALLING>; }; };

驱动侧则在module_i2c_driver的id_table里声明：

static const struct i2c_device_id tmp102_id[] = { { "tmp102", 0 }, { } }; MODULE_DEVICE_TABLE(i2c, tmp102_id); static struct i2c_driver tmp102_driver = { .driver = { .name = "tmp102", .of_match_table = tmp102_of_match, }, .probe = tmp102_probe, .remove = tmp102_remove, .id_table = tmp102_id, }; module_i2c_driver(tmp102_driver);

匹配流程是：I2C总线在扫描设备时，先看设备树里这个I2C子节点的compatible能否匹配tmp102_of_match里的条目，匹配成功的再调probe。probe参数里的struct i2c_client *client结构体包含了设备地址、中断号、平台数据等关键信息，驱动在probe里就可以直接使用，无需再自己解析设备树——I2C子系统已经把脏活累活干完了。

3.3 常见的设备树配置错误

设备树开发调试过程中，我在不同项目里反复踩过下面几个坑，列出来给大家省点时间：

• 忘加status = "okay"。很多SoC引出的外设控制器在设备树里默认是disabled状态，你要用的那个I2C控制器、SPI控制器如果没显式改成okay，子节点写得再完整也不会被枚举。
• reg地址写错。I2C子节点的reg是7位从机地址，不带读写位；很多人照抄芯片手册里的8位地址（带了R/W位），结果设备地址直接翻倍，怎么扫都扫不到。
• 忘写interrupt-parent。中断属性里的数字是相对中断控制器的，如果不指明parent，内核可能默认找根节点绑定的中断控制器，一旦有多个GIC或者GPIO控制器做中断源，就会找不到正确的interrupt domain，中断申请直接失败。
• 设备树和驱动属性名不一致。比如驱动读的是rockchip,clk-rate，你在dts里写的是clock-frequency，probe里拿回来永远是0，还找不出毛病。这是最隐蔽的一类问题，建议驱动解析属性的代码和设备树放一起review。

经验之谈：调试设备树问题，先看内核启动日志里有没有“OF: fdt: Machine model”以及probe失败时的-ENODEV、-EINVAL记录。内核里加of相关的动态调试，能打印出设备树解析的中途状态，比瞎猜强得多。

4. 实操：从零写一个带中断的按键驱动

4.1 需求场景描述

理论知识讲完，来一个完整的实操项目。需求非常典型：板子上有一颗按键，按下时产生下降沿中断，驱动负责申请GPIO中断，并在中断里通过workqueue延后处理，把按键事件上报给用户态。用户态程序通过read阻塞等待事件，一旦读到数据就打印按键状态。

我选择这个例子的原因有三个：第一，中断申请和workqueue是驱动开发的高频考点，几乎所有带外设交互的驱动都用得上；第二，这个例子能完整展示request_irq、gpiod_get、schedule_work这套标准流程；第三，按键驱动调试起来直观，不需要额外示波器，一个LED灯就能验证。

4.2 驱动代码实现与说明

先看完整的驱动代码，我逐步解释每个关键部分：

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/gpio/consumer.h> #include <linux/interrupt.h> #include <linux/workqueue.h> #include <linux/miscdevice.h> #include <linux/uaccess.h> #include <linux/wait.h> #include <linux/slab.h> #include <linux/of.h> #define DRIVER_NAME "key_driver" struct key_dev { struct gpio_desc *key_gpio; int irq; struct work_struct work; struct mutex lock; wait_queue_head_t wq; int event; int key_state; }; static struct key_dev *g_key; static void key_work_handler(struct work_struct *work) { struct key_dev *dev = container_of(work, struct key_dev, work); dev->key_state = gpiod_get_value(dev->key_gpio); dev->event = 1; wake_up_interruptible(&dev->wq); } static irqreturn_t key_irq_handler(int irq, void *data) { struct key_dev *dev = data; schedule_work(&dev->work); return IRQ_HANDLED; } static ssize_t key_read(struct file *filp, char __user *buf, size_t count, loff_t *offset) { struct key_dev *dev = g_key; int ret; if (count < sizeof(int)) return -EINVAL; if (wait_event_interruptible(dev->wq, dev->event != 0)) return -ERESTARTSYS; mutex_lock(&dev->lock); dev->event = 0; ret = copy_to_user(buf, &dev->key_state, sizeof(int)); mutex_unlock(&dev->lock); return ret ? -EFAULT : sizeof(int); } static const struct file_operations key_fops = { .owner = THIS_MODULE, .read = key_read, }; static struct miscdevice key_miscdev = { .minor = MISC_DYNAMIC_MINOR, .name = DRIVER_NAME, .fops = &key_fops, }; static int key_probe(struct platform_device *pdev) { struct device *dev = &pdev->dev; int ret; g_key = devm_kzalloc(dev, sizeof(*g_key), GFP_KERNEL); if (!g_key) return -ENOMEM; g_key->key_gpio = devm_gpiod_get(dev, "key", GPIOD_IN); if (IS_ERR(g_key->key_gpio)) { dev_err(dev, "failed to get key gpio\n"); return PTR_ERR(g_key->key_gpio); } g_key->irq = gpiod_to_irq(g_key->key_gpio); if (g_key->irq < 0) { dev_err(dev, "failed to get irq\n"); return g_key->irq; } INIT_WORK(&g_key->work, key_work_handler); init_waitqueue_head(&g_key->wq); mutex_init(&g_key->lock); ret = devm_request_irq(dev, g_key->irq, key_irq_handler, IRQF_TRIGGER_FALLING | IRQF_SHARED, DRIVER_NAME, g_key); if (ret) { dev_err(dev, "failed to request irq %d\n", g_key->irq); return ret; } ret = misc_register(&key_miscdev); if (ret) { dev_err(dev, "failed to register misc device\n"); return ret; } dev_info(dev, "key driver probed, irq=%d\n", g_key->irq); return 0; } static int key_remove(struct platform_device *pdev) { misc_deregister(&key_miscdev); return 0; } static const struct of_device_id key_of_match[] = { { .compatible = "example,key-driver" }, { } }; MODULE_DEVICE_TABLE(of, key_of_match); static struct platform_driver key_driver = { .probe = key_probe, .remove = key_remove, .driver = { .name = DRIVER_NAME, .of_match_table = key_of_match, }, }; module_platform_driver(key_driver); MODULE_LICENSE("GPL"); MODULE_DESCRIPTION("Example key driver with interrupt and workqueue");

代码里有几个点值得重点说明：

devm_gpiod_get和devm_request_irq是devres管理的资源申请API，好处是驱动卸载或者probe失败时，内核会自动释放资源，不用你手动写一堆清理代码。这能省掉很多因为异常分支忘记释放资源导致的“memory leak”和“irq already free”问题。

工作队列work_struct的使用是因为中断上下文不能调用可能导致睡眠的函数。GPIO读值本身在大多数平台上不会睡眠，但规矩还是得守——中断里干活要快，复杂逻辑一律丢到process context。schedule_work会把work挂到系统默认的工作队列，由内核线程去执行key_work_handler，这样即使work函数里调用带锁的、耗时的操作，也不会卡死中断路径。

miscdevice是个偷懒利器。它自动分配主设备号（10），次设备号用MISC_DYNAMIC_MINOR动态分配，省去class_create、device_create那一套繁琐流程，非常适合按键、LED、RTC这类小设备。一个驱动里甚至可以注册多个misc设备。

对应配套的设备树节点写在根节点下就行：

/ { key_drv: key-driver { compatible = "example,key-driver"; key-gpios = <&gpio1 13 GPIO_ACTIVE_LOW>; status = "okay"; }; };

注意key-gpios里的key前缀对应devm_gpiod_get(dev, "key", ...)里的第二个参数，gpiod子系统会把它翻译成suffix-gpios这个属性。这是用gpiod API时最容易混淆的地方，我记得第一次用的时候在这里卡了半小时，最后看内核文档才明白命名规律。

4.3 编译加载与应用层测试

编译的Makefile和之前类似，把obj-m改成key.o就行。加载驱动后先用dmesg确认probe成功，再检查设备节点：

insmod key.ko dmesg | tail -20 ls -l /dev/key_driver

如果一切正常，可以看到/dev/key_driver节点已经出现。应用层验证代码很简单，用一个wiringPi风格的按键读取程序验证：

#include <stdio.h> #include <fcntl.h> #include <unistd.h> #include <stdlib.h> int main(void) { int fd = open("/dev/key_driver", O_RDWR); int state; if (fd < 0) { perror("open"); return -1; } while (1) { if (read(fd, &state, sizeof(state)) == sizeof(state)) printf("key state: %d\n", state); } close(fd); return 0; }

编译运行后，每按一次按键，终端就打印一次key state: 0（按下）或key state: 1（释放）。因为驱动注册的是下降沿中断，理论上只有按下动作会触发，但如果你接了上拉电阻，释放时可能产生抖动，所以实际项目中按键一定要加消抖逻辑，后面我在常见问题里细说。

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

5.1 insmod报错的几种典型情况

驱动开发调试期，insmod失败是家常便饭。下面这张表把我这些年遇到的高频问题整理了一下：

最值得说的是“Unknown symbol”的问题。它通常出现在你用了EXPORT_SYMBOL导出的API，但编译模块时用的内核头文件版本和运行内核不一致，或者某个符号本来就是GPL-only的，而你的模块声明的是非GPL许可。前者通过重新编译内核头文件解决，后者把MODULE_LICENSE("GPL")写上就好。

5.2 中断相关的坑

中断申请是驱动开发里最容易翻车的环节，我挑三个高频问题讲。

第一个是中断号资源被占用。devm_request_irq返回-EBUSY，说明这个中断号已经被其他驱动申请了。常见原因是设备树里同一个GPIO被两个节点引用，或者GPIO控制器本身的级联中断没配好。排查方法是在设备树里去掉多余的节点，一个个排除。

第二个是IRQF_TRIGGER_FALLING和实际硬件电平不匹配。如果你的按键电路是按下接地，那应该是下降沿触发；但如果外部有RC滤波或者你用的是高有效电平，触发条件就对不上。我遇到过最离奇的案例是GPIO内部上拉没配置，按键浮空，中断疯狂触发，中断处理函数里读到的引脚状态是乱跳的。用gpiod_get_value在probe里打一次初始值，能快速确认引脚电平状态是否符合预期。

第三个是IRQF_SHARED共享中断里，中断处理函数必须检查自己的设备是否有中断发生。如果不检查就返回IRQ_HANDLED，会导致其他共享该中断的驱动饿死。正确写法是读取设备的状态寄存器，确认是自己的中断源再处理。

5.3 调试手段与内核打印技巧

驱动开发调试和纯应用开发最大的区别是：没有gdb能用（KGDB配置成本高，不推荐新手一上来就搞），printf也不能用。我实际用得最多的调试手段是这几招：

• printk分级打印，用dmesg -n 8让所有级别的内核日志都输出到console，方便边跑边看。
• /sys/kernel/debug下的debugfs接口，在驱动里注册一个debugfs文件，读接口时把关键变量的值dump出来，比printk更灵活。
• trace-cmd和perf看中断频率、函数调用栈，定位“中断风暴”特别管用。
• 买一个逻辑分析仪或者USB转GPIO工具，从硬件侧确认信号波形。很多时候驱动看起来没问题，实际上是硬件那边引脚虚焊或者电平转换芯片没工作。

内核打印这里有个细节：printk的日志级别用pr_info、pr_err这些宏比直接写printk(KERN_INFO, ...)更简洁，而且编译期会根据CONFIG_DYNAMIC_DEBUG决定是否保留日志，线上排查时能用动态调试动态开关某段日志，非常实用。

5.4 按键消抖的经典方案

按键驱动如果没有消抖，按一次可能触发三四次中断，应用层读到一堆重复事件。正规做法有两种。

硬件消抖：在按键两端并联100nF电容，RC时间常数约1~10ms。这是最简单可靠的办法，前提是你还能改电路板。

软件消抖：在work queue的延迟函数里加msleep或者用hrtimer延迟10ms再读引脚。如果引脚状态和中断时刻一致，就认为是一次有效按键。我以前写过一套折中方案：把schedule_work换成schedule_delayed_work，延时20ms执行，在work函数里重新读GPIO值确认电平：

static void key_work_handler(struct work_struct *work) { struct key_dev *dev = container_of(work, struct key_dev, work.work); if (gpiod_get_value(dev->key_gpio) == 0) { dev->event = 1; dev->key_state = 1; wake_up_interruptible(&dev->wq); } }

这样在按下瞬间产生的多次抖动中断里，只有最后一次状态稳定后的work执行才会真正上报事件，实测防抖效果很好。

6. 进阶：I2C设备驱动、并发控制与性能优化要点

6.1 I2C设备驱动的整体架构

字符设备驱动讲清楚了，再往上一层就是I2C、SPI这类总线设备驱动。I2C驱动的核心思路是：总线驱动已经由SoC厂商写好了，你需要做的只是写一个“客户设备驱动”，通过i2c_transfer或者regmap API往总线上发数据。

I2C设备驱动最核心的几个API：

• i2c_master_send(client, buf, len)：向从设备发送数据，自动处理START、地址、ACK；
• i2c_master_recv(client, buf, len)：从从设备接收数据；
• i2c_transfer(adapter, msgs, num)：更底层的接口，可以组合写读操作，比如先写寄存器地址再读数据，这是读传感器寄存器的标准姿势，一个transaction完成，避免总线上其他设备插入导致地址错位。

一个典型的工作流：probe里用i2c_register_driver注册，然后在应用层通过/dev/i2c-N节点直接访问，或者用工业标准的方式——在驱动里创建/dev/下的专属节点，通过read/write控制传感器。前者适合调试，后者适合产品化。

如果你用regmap API来写I2C驱动，代码会简洁很多。regmap帮你做了缓存、lock、格式转换，很多现代SoC厂商的MFD框架都跑了regmap，它让I2C驱动的代码量能减少一半以上。我强烈建议新人在I2C驱动上优先用devm_regmap_init_i2c。

6.2 并发控制：驱动里最容易被忽视的雷区

驱动一旦进入生产环境，并发问题就是最隐蔽的杀手。多个应用程序同时open你的设备节点，两个线程同时read同一个buffer，中断和work queue并发访问同一份寄存器映射，任何一个没有加锁都有可能导致内核崩溃或者数据错乱。

Linux内核为驱动开发者准备了多种并发控制手段，我按使用频率排个序：

• 互斥锁mutex：适合process context的互斥访问，持锁时间可以较长，可以睡眠。
• 自旋锁spinlock：适合中断上下文或者持锁时间极短的临界区，不能睡眠，否则整个系统会死锁。
• 原子操作atomic_t：适合简单的计数器、标志位。
• 读写锁rwlock：多个读者一个写者的场景，但实际性能在大多数ARM平台上并不理想，能用mutex就尽量用mutex。

在选择锁类型时，我的原则是：能睡就用mutex，不能睡就用spinlock，实在拿不准就用原子变量。不要为了追求所谓的“高性能”去写复杂的无锁算法，驱动里这类优化通常收益很小，出问题很难排查，性价比非常低。

6.3 中断上下半部与线程化中断的选择

中断处理分为上半部（hardirq）和下半部（softirq/tasklet/workqueue）。硬中断上下文里不能调任何可能睡眠的函数，比如kmalloc带GFP_KERNEL、mutex_lock、copy_to_user都是禁区。所以我的建议是：

• 如果中断处理只需要几十个周期就能完成，比如读一个寄存器、置一个标志位，那就全部在上半部处理，不用下半部。
• 如果中断处理里需要操作I2C总线、等待DMA完成、通知用户态，这些操作必须放到下半部。优先用workqueue，因为tasklet在SMP上的行为比较微妙，且workqueue可以被调度器平滑管理，不容易出现优先级反转问题。
• 如果中断频率不高，但每次处理时间较长，可以直接用request_threaded_irq申请线程化中断，内核自动帮你建立一个内核线程来处理中断下半部，代码更简单。

request_threaded_irq的用法和request_irq几乎一样，只是多传了一个thread_fn回调：

ret = request_threaded_irq(irq, NULL, key_thread_fn, IRQF_TRIGGER_FALLING, DRIVER_NAME, dev);

第一个handler传NULL时，内核会使用默认的irq_default_primary_handler，直接把中断处理全部交给thread_fn在进程上下文执行。这样你在thread_fn里就可以放心调用i2c_master_send、mutex_lock这些会睡眠的API。

6.4 系统裁剪与性能调优的个人经验

最后补一段和驱动强相关的系统级优化经验。我在做嵌入式产品时，经常需要裁剪内核和调优系统性能。围绕驱动的部分，有几个容易被忽略但收益明显的点：

• 关闭内核的debug选项。CONFIG_DEBUG_KERNEL、CONFIG_DEBUG_SPINLOCK、CONFIG_DEBUG_MUTEXES、CONFIG_DEBUG_ATOMIC_SLEEP这些选项在产品发布时全部关掉，能显著降低内核体积，并减少运行时开销。但在开发阶段千万别关，尤其是在排查死锁和原子上下文睡眠问题时，这些选项的告警日志能帮你精确定位到源码行号。
• 检查并关闭不需要的驱动编译进内核。很多人图省事，把所有驱动都编进内核，导致启动时间被拖慢。建议用模块化加载，只把必须要在rootfs挂载前启动的设备比如eMMC控制器、串口编进内核，其余全部做成可加载模块。之前一个项目，只做这一步，启动时间从7秒降到3.2秒。
• 中断和workqueue的CPU亲和性调优。在SMP平台上，可以用irq_set_affinity_hint把高频中断绑定到指定CPU核，避免中断在多个核之间迁移导致cache抖动。workqueue也可以通过alloc_workqueue指定WQ_UNBOUND和WQ_CPU_INTENSIVE标志来适配不同的负载类型。

这些优化看着零散，但在实际嵌入式产品里每一项都实打实影响用户体验。有一次客户反馈开机画面出得太慢，我排查到最后发现是GPU驱动被编译成模块，加载顺序排到了很后面，改成内核内置后，画面提前了整整1.5秒。

我个人在实际项目里体会到，驱动开发这件事，框架和API只是门槛，真正拉开差距的是对并发模型、资源生命周期、硬件时序的理解。就像写字符设备驱动，模板谁都会抄，但能不能在probe失败时把所有资源都正确释放、能不能在中断风暴下保证系统不卡死、能不能在设计阶段就为后续的电源管理预留好接口，这些才是驱动工程师的核心竞争力。如果你正卡在某个驱动问题上，建议回到“调用链+资源管理+并发安全”这三个基本面上重新审视一遍，多半能找到突破口。