5.1《深入浅出Linux 设备驱动框架》

设备驱动框架概述：从混乱到秩序

深夜两点，示波器上的波形还在跳动。我盯着屏幕上一串毫无规律的SPI时序，揉了揉发酸的眼睛。这已经是第三版硬件了，每次换平台，同样的外设驱动都要重写一遍——i.MX6上能跑，换到RK3399就死活不出时钟。更头疼的是，同事改了我的驱动去适配新项目，三个月后故障像地雷一样在客户现场炸开。那一刻我突然意识到：没有框架的驱动代码，就像没有地基的房子。

混乱的代价

早期的Linux驱动开发是什么样子？打开一个经典的字符设备驱动文件，你会看到近千行代码挤在一个文件里：硬件寄存器操作、文件操作接口、中断处理、电源管理、调试信息全部揉在一起。更可怕的是，每个工程师都有自己的“风格”——有人喜欢用位域操作寄存器，有人偏爱宏定义；中断处理里可能直接调度工作队列，也可能悄悄启动一个内核线程。

这种混乱导致的问题很现实：驱动A在ARMv7上稳定运行两年，移植到ARMv8就因为内存屏障使用不当出现偶发数据错误；驱动B的开发者离职后，没人敢动那充满“魔法数字”的寄存器配置代码。更常见的是，同一个公司的不同项目组，为相似的外设写了三套完全不同的驱动，每套都有自己埋的坑。

框架的浮现

Linux社区早就意识到了这个问题。你看2.6时代的内核，各种子系统开始成形：input子系统统一了键盘、鼠标、触摸屏；IIO为传感器提供了标准接口；V4L2让视频设备有了共同语言。到了3.x时代，设备树（Device Tree）的出现把硬件描述从代码中剥离，同一份驱动突然可以适配不同板卡。

但真正的转折点是设备模型（Device Model）的成熟。struct