做嵌入式开发这些年，我面试过不少转行做Linux驱动的人，几乎每个人第一句都会说：“我想学Linux驱动开发。”但你再追问一句“接触过什么？”答案就五花八门了——有说看过内核源码的，有说会写Makefile的，也有说能配置设备树的。可真正动手写过、编译过、跑起来过的，十个里最多两三个。
如果你也想入门Linux驱动，我正在用的办法很朴素：从一颗LED灯开始。LED是硬件上最简单的外设，一个GPIO引脚就能搞定，但它背后涉及的字符设备框架、file_operations、设备树、GPIO子系统、内核模块编译、应用层交互，几乎覆盖了Linux驱动开发的全部主干内容。这篇文章就把这套“点灯”流程完完整整走一遍，包括代码、设备树、Makefile、加载测试、踩坑排查。适合零基础起步的初学者，也适合从STM32裸机开发往Linux方向转的朋友——你会发现很多概念其实是相通的，只是换了一套“容器”。
1. 为什么学Linux驱动，首选是从点亮一颗LED灯开始
1.1 一个简单外设串联起整个驱动开发链路
我第一次带新人做Linux驱动培训的时候，也犹豫过要不要搞个复杂点的硬件，比如网卡、USB控制器之类的。后来发现完全没必要。LED灯这个外设虽然功能简单，但驱动开发的“骨架”它一样都不缺。
一个完整的Linux设备驱动，需要解决的事情包括：设备怎么被内核发现、驱动怎么和设备匹配、硬件资源（GPIO）怎么申请和使用、应用层用什么方式访问这个设备、数据在内核态和用户态之间怎么传递。这些环节，用LED驱动全都能走一遍。你写一个网卡驱动，核心逻辑可能有一大半在协议栈里，被框架层层包裹，反而看不清“驱动”本身的轮廓。但LED驱动没有这些干扰，你往代码里一站，每一行都是驱动最核心的东西。
而且LED驱动有一个天然优势：调试反馈极快。你写完驱动，加载模块，echo一个1到设备节点，灯亮了，程序就是对了；灯不亮，马上就知道还有问题。这种即时反馈对学习阶段的信心建立非常重要。
1.2 从零到一需要走完的完整开发链条
网上很多教程喜欢只讲代码本身，讲完hello world就算精神胜利。但真实的驱动开发不是写完代码就结束的，它是一个完整的链路：
硬件电路搭建 → 内核源码准备 → 设备树配置 → 驱动代码编写 → 交叉编译（或本地编译）→ 模块加载 → 设备节点确认 → 应用层测试
任何一步出了问题，灯都点不亮。比如设备树的compatible字符串和驱动里的of_match_table对不上，驱动模块即使加载成功也不会执行probe函数；再比如GPIO被其他驱动占用了，你申请时会直接报错。这些“隐形的坑”，恰恰是驱动开发真正值钱的经验。这篇文章后面会把这些环节逐一拆开来讲，保证你照着做一遍就能跑通。
1.3 开发环境准备：硬件、工具链与内核源码
在动手之前，先把环境备齐。硬件方面你需要一块能跑Linux的开发板，常见的比如i.MX6ULL、全志V3s、树莓派都行。我这边演示用的是i.MX6ULL，原因是这颗芯片的寄存器手册公开资料多，设备树也非常典型，很适合做教学平台。核心板上面找一个空闲的GPIO，通过杜邦线接一个LED灯珠，记得串一个330Ω的限流电阻，正极接GPIO，负极接地。
软件方面，三个东西不能少：
交叉编译工具链。如果目标板是ARM架构，你需要在PC上使用arm-linux-gnueabihf-gcc这类交叉编译工具。安装方法很简单，Ubuntu下直接apt install gcc-arm-linux-gnueabihf就行。
内核源码。这里有个非常关键的知识点：驱动模块必须与目标内核版本完全匹配。很多人编译模块时报“version magic‘...’ should be '...'”错误，就是因为内核源码版本和目标板上跑的镜像版本不一致。最稳妥的做法是，开发板出厂提供哪个版本的内核源码，就用哪个版本编译，不要随便从网上下一个。
根文件系统工具。比如busybox或者buildroot制作好的根文件系统，这个一般开发板出厂就带，你只需要通过NFS或者TFTP挂载就行。
2. 字符设备驱动框架：先理解驱动与应用的“接口层”
2.1 file_operations：内核态与应用态之间的桥梁
Linux下一切皆文件，这个设计哲学在设备驱动里体现得淋漓尽致。应用层操作一个LED设备，本质上就是打开一个文件、读写这个文件。
比如下面这段最简单的应用层代码你要运行：
int fd = open("/dev/myled", O_WRONLY); write(fd, "1", 1); close(fd);open和write这两个系统调用，最终会通过虚拟文件系统（VFS）找到你驱动里注册的open函数指针和write函数指针，跳转到内核态执行。这个“跳转表”就是struct file_operations。
static const struct file_operations myled_fops = { .owner = THIS_MODULE, .open = myled_open, .write = myled_write, .release = myled_release, };你不需要实现所有函数指针。比如一个纯输出的LED设备，没人在它上面读数据，那read不实现也没关系，open、write、release这几个是最基础的。初学者最容易犯的错是写了一个函数，但忘了在file_operations里面挂接，结果应用层open成功、write却返回-EINVAL，排查半天都找不到原因。
2.2 设备号、设备节点与自动创建设备节点
应用层能打开/dev/myled这个节点，背后其实是两个编号在起作用：主设备号和次设备号。主设备号标识设备对应的驱动程序，次设备号标识同一个驱动管理下的不同设备。在Linux里，现代的写法是用alloc_chrdev_region()动态申请主设备号，而不是自己指定一个乱写的数字，因为动态分配能避免和已有设备冲突。
设备节点怎么创建？早期做法是手动mknod /dev/myled c 240 0，这个命令现在很多教程还在讲，但实际项目里早就淘汰了。因为设备节点的创建和删除，应当由内核在设备出现和消失时自动完成。整体机制是：驱动里注册class，然后创建device，内核的udev（或busybox的mdev）监视到新设备事件后，自动在/dev下面生成对应的节点。
不过这里我推荐一个更偷懒的写法：使用miscdevice机制。miscdevice是一种特殊的字符设备，它使用系统预留的10号主设备号，次设备号动态分配。对于LED这种功能简单的设备，miscdevice省去了手动分配设备号、创建class、创建device这一大堆样板代码。一个misc_register()调用就能完成所有注册工作，设备节点自动出现在/dev/myled。这个技巧在实际项目中被广泛使用，很多传感器驱动、小外设驱动都用它来实现。
2.3 老式手动配置与新式设备树+平台模型的选择
如果你看过一些2005年前后的老书，会发现驱动代码里直接写gpio_request(103, "led")，然后硬编码引脚号。这在老内核里确实工作正常，但今天是行不通的，至少在产品项目里不推荐。原因很简单：同一个驱动，换一个板子，引脚就变了。如果引脚写在代码里，你就得为每个硬件版本重新编译一次内核模块，维护成本极高。
现代Linux驱动的做法是引入设备树（Device Tree）和平台设备模型。硬件资源（GPIO编号、极性、中断号等）全部在设备树里描述，驱动只负责从设备树中解析资源。同样是LED驱动，内核启动阶段加载设备树后，会生成一个platform_device；你的驱动以platform_driver的形式注册到内核，内核通过compatible字符串把两者匹配起来，然后调用驱动的probe函数。
这套机制的好处是，硬件变了只需要改设备树，驱动代码一个字都不用动。而且probe函数将“设备与驱动匹配成功”作为运行起点，模块加载成功不等于驱动生效，只有probe执行了才说明驱动真正找到了它的设备。理解了这一点，你就理解了一半的Linux驱动模型。
3. GPIO硬件原理与Linux GPIO子系统：别小看一个引脚
3.1 GPIO的8种工作模式：从STM32裸机到Linux的认知转换
很多做单片机的朋友对“GPIO的8种工作模式”非常熟悉。STM32的GPIO有输入浮空、输入上拉、输入下拉、模拟输入、开漏输出、推挽输出、推挽复用、开漏复用这8种。这套硬件模式在Linux底下也是真实存在的，只不过Linux内核通过gpiolib抽象成了更上层、更简单的接口。
举个例子，STM32中的推挽输出模式，对应到Linux里就是你调用gpiod_direction_output()时，gpiolib底层的pinctrl子系统会把引脚配置成推挽输出；输入上拉模式，对应的是gpiod_direction_input()加上gpiod_set_value()设置上拉。复用功能则交给pinctrl子系统管理，不是普通GPIO接口的事。
所以从底层机制上看，不是Linux不关心8种模式，而是它把模式配置的复杂性向下“兜住”了。你写驱动的时候，只需要告诉gpiolib“我要把这个引脚配成输出”或“我要读这个引脚的电平”，具体的物理模式配置由SoC厂商提供的pinctrl驱动来完成。
3.2 gpiolib与gpiod接口：现代内核推荐的GPIO操作方式
在Linux内核里操作GPIO，目前推荐的是gpiod系列接口。这个接口有几个明显优势：第一，API设计基于描述符（struct gpio_desc *），而不是整数编号，更安全也更清晰；第二，支持设备树中的GPIO极性属性，硬件上是低电平点亮还是高电平点亮，驱动里不用关心；第三，支持自动资源管理，配合devm函数族使用，probe失败时内核自动释放GPIO，不用写一堆错误处理。
我实际用的接口主要有这几个：
devm_gpiod_get(struct device *dev, const char *con_id, enum gpiod_flags flags) gpiod_direction_output(struct gpio_desc *desc, int value) gpiod_set_value(struct gpio_desc *desc, int value) gpiod_direction_input(struct gpio_desc *desc) gpiod_get_value(struct gpio_desc *desc)devm_gpiod_get里的con_id参数是个关键点。它对应设备树节点里GPIO属性的名字。比如设备树里写led-gpios，那你获取这个GPIO时就要写devm_gpiod_get(dev, "led", GPIOD_OUT_LOW)。这个名字对应关系非常容易写错，写错了probe会返回-ENOENT，而且日志提示往往不够直观，需要反复确认设备树属性和代码参数是否一致。
3.3 LED硬件电路设计与常见引脚复用冲突
LED灯电路本身很简单，但几个细节仍然值得注意。
限流电阻不能省。LED工作电流通常是5~20mA，如果直接用GPIO输出3.3V去接一个没有限流电阻的LED，电流可能高达几十毫安，虽然不至于马上烧坏引脚，但长期工作会缩短芯片寿命。串一个330Ω或1kΩ的电阻，电流控制在3~10mA，既能看到明显亮度，又不会对GPIO造成过冲。
极性接法会影响设备树里GPIO_ACTIVE_HIGH和GPIO_ACTIVE_LOW的配置。如果LED正极接GPIO，负极接地，那么GPIO输出高电平灯亮，这时设备树里应该写GPIO_ACTIVE_HIGH。如果反过来，LED正极接电源，负极接GPIO，GPIO输出低电平灯亮，就应该写GPIO_ACTIVE_LOW。
更隐蔽的问题是引脚复用冲突。很多SoC的GPIO引脚同时具有UART、I2C、PWM等复用功能。比如你选了一个GPIO，它在设备树里已经被UART节点占用了，启动时引脚被复用成了串口功能，你的GPIO驱动即使probe成功，拉高拉低也无效。排查方法是在设备树检查该引脚是否被别的节点引用，或者通过内核日志查看pinctrl是否有冲突警告。这个坑在裸机开发里几乎不存在，但在Linux下非常常见。
4. 实操：基于设备树的最小LED驱动从零实现
4.1 设备树添加节点：compatible与led-gpios的写法
接下来进入正题。我的目标板是i.MX6ULL，GPIO1的IO03引脚上接了一个LED，硬件上LED正极接GPIO，负极接地，高电平点亮。
在设备树中，我新加一个平台设备节点。如果你对设备树不熟，先记住一句话：设备树就是描述硬件拓扑信息的一棵“树”，每个节点代表一个硬件设备，节点里的属性描述设备的具体配置。
&iomuxc { pinctrl_myled: myledgrp { fsl,pins = < MX6UL_PAD_GPIO1_IO03__GPIO1_IO03 0x10b0 >; }; }; / { myled { compatible = "myled,test"; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_myled>; led-gpios = <&gpio1 3 GPIO_ACTIVE_HIGH>; status = "okay"; }; };第一段在IOMUX节点下配置引脚复用，把GPIO1_IO03这个引脚复用为GPIO功能，0x10b0是电气属性配置，包含上下拉、施密特触发、速度等参数。第二段在根节点下添加了自己的设备节点。compatible属性的值是一个字符串，格式是“厂商名,设备名”，这个字符串必须和驱动里的of_match_table完全一致，不能有任何大小写或标点差异。
led-gpios属性的语法是：<&gpio1 3 GPIO_ACTIVE_HIGH>表示使用gpio1控制器下的3号引脚，有效电平是高电平。注意，GPIO控制的编号和芯片数据手册上的引脚编号不一定一样，有时会存在偏移，需要通过看SoC的GPIO寄存器定义确认，这个在i.MX系列上经常让人踩坑。
4.2 驱动代码拆解：probe、gpiod与miscdevice
设备树配好了，接下来写驱动。我用的是platform_driver模型加miscdevice，代码尽量精简，但每个部分都值得仔细看。
#include <linux/module.h> #include <linux/platform_device.h> #include <linux/gpio/consumer.h> #include <linux/miscdevice.h> #include <linux/fs.h> #include <linux/uaccess.h> #define DRIVER_NAME "myled" struct myled_dev { struct gpio_desc *led_gpio; struct miscdevice mdev; }; static int myled_open(struct inode *inode, struct file *file) { return 0; } static ssize_t myled_write(struct file *file, const char __user *buf, size_t count, loff_t *ppos) { struct myled_dev *dev = container_of(file->private_data, struct myled_dev, mdev); char kbuf; if (count < 1) return -EINVAL; if (copy_from_user(&kbuf, buf, 1)) return -EFAULT; if (kbuf == '1') gpiod_set_value(dev->led_gpio, 1); else if (kbuf == '0') gpiod_set_value(dev->led_gpio, 0); else return -EINVAL; return count; } static const struct file_operations myled_fops = { .owner = THIS_MODULE, .open = myled_open, .write = myled_write, }; static int myled_probe(struct platform_device *pdev) { struct myled_dev *dev; int ret; dev = devm_kzalloc(&pdev->dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; 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); } dev->mdev.minor = MISC_DYNAMIC_MINOR; dev->mdev.name = "myled"; dev->mdev.fops = &myled_fops; dev->mdev.parent = &pdev->dev; ret = misc_register(&dev->mdev); if (ret) { dev_err(&pdev->dev, "misc register failed\n"); return ret; } platform_set_drvdata(pdev, dev); dev_info(&pdev->dev, "myled probed successfully\n"); return 0; } static void myled_remove(struct platform_device *pdev) { struct myled_dev *dev = platform_get_drvdata(pdev); misc_deregister(&dev->mdev); gpiod_set_value(dev->led_gpio, 0); } static const struct of_device_id myled_of_match[] = { { .compatible = "myled,test", }, { } }; MODULE_DEVICE_TABLE(of, myled_of_match); static struct platform_driver myled_driver = { .probe = myled_probe, .remove = myled_remove, .driver = { .name = DRIVER_NAME, .of_match_table = myled_of_match, }, }; module_platform_driver(myled_driver); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Embedded Coder"); MODULE_DESCRIPTION("A simple GPIO LED driver");这段代码有几个地方要说透。
myled_open里什么都没做，返回0。有些人会问，空的open函数也注册它干嘛？实际上，对于miscdevice，如果file_operations里没有显式提供open，内核默认也能处理。但注册一个open函数有个隐藏作用：它是驱动“层叠”机制的一部分，比如后面要加电源管理、加互斥锁，直接在open里加就行。真实项目里一个空的open函数比你想的更常见。
myled_write里的container_of是一个非常高频的内核宏。file->private_data其实指向的是我们注册的miscdevice结构体，container_of通过这个结构的成员指针反推出包含它的struct myled_dev结构体的首地址，拿到之前保存的GPIO描述符。这个宏看着别扭，但你会在内核代码里反复见到它，建议死记硬背下来。
devm_gpiod_get的第三个参数GPIOD_OUT_LOW表示获取GPIO后马上把电平置为低。这个设计很贴心，避免驱动加载瞬间LED闪一下——但如果你的硬件是低电平点亮，这个参数就要改成GPIOD_OUT_HIGH，否则probe后LED会处于亮的状态，和预期不符。
module_platform_driver是一个封装宏，相当于把module_init和module_exit都做好了。如果你看到老代码里手动写module_init(myled_init)然后在init函数里调platform_driver_register，原理是一样的，现代代码用这个宏更简洁。
4.3 Makefile编写与本地/交叉编译
驱动代码写好后，编译这一步也容易出问题。Makefile我推荐写成下面这样通用性强的版本：
# 如果目标板不是本机，指定ARCH和CROSS_COMPILE ARCH ?= arm CROSS_COMPILE ?= arm-linux-gnueabihf- # 内核源码路径，按实际路径修改 KDIR ?= /home/user/linux-imx # 当前目录 PWD := $(shell pwd) obj-m := myled.o all: $(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KDIR) M=$(PWD) modules clean: $(MAKE) ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KDIR) M=$(PWD) cleanKDIR指向的是内核源码树的顶层目录，注意它不是你内核源码里的某个子目录，就是源码根目录。编译时-C先切到源码目录，读取内核顶层Makefile，然后再通过M=$(PWD)切回来编译你的模块。模块的编译产物是myled.ko，这个文件就是要拷贝到开发板的模块文件。
编译过程中最常见的错误是Cannot use CONFIG_CC_STACKPROTECTOR_STRONG这类提示，原因是工具链与内核配置不匹配。解决办法是更新交叉编译器，或者在内核配置中关掉这个选项重新编译内核，不建议为了编译模块乱改内核配置，因为可能影响其他模块。
编译前还要确认内核源码已经完成了基础配置，至少生成了.config文件和Module.symvers文件。如果直接拿一份刚解压、没配置过的源码编译模块，大概率会报各种莫名其妙的错误。解决办法是先把内核完整配置并编译一遍。这一步耗时很长，但值得做。很多初学者第一次编译内核就卡了半小时，这是正常的过程，不要怕。
5. 模块加载、应用测试与故障排查
5.1 加载模块并确认设备节点
把交叉编译好的myled.ko拷贝到开发板上，比如放到/root目录。然后在开发板的终端上执行：
insmod myled.ko如果没有报错，用dmesg查看内核日志，应该能看到类似下面的输出：
myled myled: myled probed successfully同时检查设备节点是否已经生成：
ls -l /dev/myled输出应该是类似crw------- 1 root root 10, 56 Jan 1 00:00 /dev/myled这样。主设备号10就是miscdevice使用的“混设备”主设备号，次设备号是动态分配的。
如果insmod报insmod: can't insert 'myled.ko': unknown symbol in module之类的错误，先不要慌，这通常是两个原因：一是Module.symvers里没有对应导出符号，二是模块编译时的内核版本和你运行时内核版本不一致。确认一下uname -r和编译时用的源码版本是否一致。
如果你更喜欢用modprobe来加载，需要先把myled.ko放到/lib/modules/$(uname -r)/目录下，然后执行depmod -a生成依赖信息，再执行modprobe myled。modprobe的好处是能自动加载依赖模块，但调试驱动阶段我一般还是用insmod，因为省事，不用管依赖和路径问题。
5.2 应用层控制LED：从shell命令到C程序
设备节点已经出现了，现在测试是否能正常控制LED。先试最简单的shell命令：
echo 1 > /dev/myled正常情况，LED应该亮起来。
echo 0 > /dev/myled灯应该熄灭。
如果上面成功了，整个驱动的主干流程——设备树匹配、GPIO申请、miscdevice注册、应用层写入、GPIO输出——已经全部打通了。接下来再写一个C程序做更接近真实项目结构的测试。
#include <stdio.h> #include <stdlib.h> #include <fcntl.h> #include <unistd.h> #include <string.h> int main(int argc, char *argv[]) { int fd; char cmd; if (argc < 2) { fprintf(stderr, "Usage: %s <0|1>\n", argv[0]); return -1; } cmd = argv[1][0]; fd = open("/dev/myled", O_WRONLY); if (fd < 0) { perror("open /dev/myled failed"); return -1; } if (write(fd, &cmd, 1) < 0) perror("write failed"); close(fd); return 0; }编译加运行：
arm-linux-gnueabihf-gcc -o myled_test myled_test.c ./myled_test 1这个测试程序虽然简单，但它完整走了一个“应用层-设备节点-驱动”的通路。我建议你在测试时留意绝对路径和相对路径的问题，有些环境/dev的权限设置很严格，普通用户可能没有写权限，需要root身份执行，或者配置udev规则允许指定用户组访问。
5.3 实测中常见的6个问题与排查方法
把我在测试这套驱动时遇到过的真实问题整理成一个速查表，每一个我都踩过，排查步骤也是真实有效的。
问题一：模块加载成功，但设备节点没出现。大概率是misc_register没有执行到，或者执行失败了。先看dmesg，确认probe是否被调用。如果probe都没执行，去检查设备树的compatible和驱动of_match_table是否一致。如果probe执行了但misc注册失败，很可能是同名的设备节点已经存在，检查一下/dev/myled是否被别的模块占用了，换个miscdevice名字就行。
问题二：echo 1 > /dev/myled 报Permission denied。看一下设备节点权限，miscdevice创建的节点默认权限是0600，所有者是root。如果你用普通用户测试，就会出现这个错误。临时解决方案是chmod 666 /dev/myled，正规方案是写udev规则为设备设置组权限。对学习阶段来说，直接用root执行echo更快。
问题三：GPIO电平测到了，但LED死活不亮。先检查硬件接线：LED极性有无接反？限流电阻是否太大或太小？再用万用表量一下GPIO引脚的电压，确认输出的是不是预期电平。还有一点被很多人忽略——你拿到的GPIO编号在设备树映射的iomux节点上，可能被重复配置了。比如设备树里既有uart节点用了这个引脚，又有你新增的节点引用了它，linux的pinctrl子系统可能选择其中一个生效，但不会明显报错。
问题四：probe函数根本没执行，dmesg也没有任何输出。先确认模块加载成功了没有报错。然后查设备树节点有没有被内核“看到”，可以用ls /proc/device-tree找到你的节点。如果节点存在，再去检查compatible字符串是否完全一致，包括大小写和空格。设备树编译时可以dtc -I dtb -O dts xxx.dtb反编译来看，非常直观。
问题五：闪烁一下又灭了，或者上电就亮一下。这个现象多半是GPIO的默认状态造成的。如果设备树没配置GPIOD_OUT_LOW，GPIO可能保持系统默认的上拉状态，LED在上电瞬间是亮的。用户态程序还没跑，灯就亮了，看起来像“不受控”。解决办法是获取GPIO时就明确初始状态，比如devm_gpiod_get的flags参数用GPIOD_OUT_LOW。初始状态的值要结合“有效电平”属性想清楚——同一份代码配合不同极性的硬件电路，表现会完全相反。
问题六：insmod时立刻panic，整个系统崩溃。这个最严重，多半是驱动里非法访问了内存地址，或者GPIO描述符是NULL却直接调用gpiod_set_value。开发阶段我习惯在申请GPIO后马上判断IS_ERR，确保后续逻辑不会用错指针。另外，尽量先在内核日志中逐行跟踪probe执行情况，再逐步添加业务逻辑，不要一上来就写一大段功能代码。
6. 从LED驱动继续深入：后续学习路线与扩展方向
6.1 从GPIO到更多外设的理解迁移
把LED驱动完整跑通之后，你已经具备了一个嵌入式Linux驱动开发者的基本思维框架。后续遇到更复杂的设备，你会发现套路是类似的。
比如你要写一个按键驱动。硬件上按键接在另一个GPIO上，驱动流程依然是设备树配置GPIO引脚 → probe获取GPIO → 申请中断 → 注册input子系统 → 应用层通过/dev/input/eventX读取键值。和LED驱动的区别只在于数据流方向反过来，并且从“写调用”变成了“中断上下文上报”，但驱动的骨架、匹配机制、资源管理方式一模一样。
比如你要写一个I2C温湿度传感器驱动。I2C控制器驱动已经由SoC厂商提供好了，你的工作重点变成：注册一个i2c_driver，在probe里调用i2c_smbus_read_byte_data这类API去读传感器寄存器，然后把数据上报给Linux的工业IO子系统（IIO）。对设备树匹配和驱动模型的理解，依然是这一切的基础。
再比如你要做PWM调光LED背光，内核里已经有现成的led-class框架和pwm-backlight驱动，你只需要配置设备树节点，并把背光控制的pwm节点接到LED节点上。从“自己造轮子”到“学会用好现成框架”，是驱动开发水平提升的明显标志。
6.2 关于学习路径的个人建议
有朋友问我，是不是直接学Linux内核源码就能快速成为驱动高手？我的看法是，源码当然要看，但要把顺序安排对。我建议的路径是：先用这篇文章的LED驱动跑通全流程，建立“设备树—驱动模型—GPIO—应用层”的闭环认知；然后花两周时间读内核源码里drivers/gpio、drivers/misc下面几个简单驱动的代码，边读边改边测；再往后可以尝试把同一个LED驱动改成用led-class接口实现，理解内核为什么对同类设备要提供统一抽象；接着做个按键驱动，接触中断和input子系统；再到I2C/SPI总线和设备驱动。每走一步，都回头想想“如果硬件引脚换了，我要改几处？”这个问题的答案越少，说明你的驱动写得越符合现代Linux的设计哲学。
我个人在教人的时候，永远让新人把LED驱动从头到尾写三遍。第一遍照抄，第二遍盲写，第三遍改需求（比如改成GPIO低电平点亮、改成两个LED交替闪烁），直到能不看任何参考写出来为止。点灯这件事看着简单，但能把它写进骨子里，后面的路就好走了。
最后再分享一个小技巧：碰到GPIO相关的疑难问题，不要只看内核日志，还要养成用/sys/kernel/debug/gpio查看GPIO状态的调试习惯。这个debugfs节点会清晰列出每个GPIO的占用者、方向、当前电平和请求该GPIO的驱动名。一个引脚是否被占用、有没有配置成功，在这里一目了然，能看到很多dmesg里根本不显示的隐藏信息。
