1. 课程导入

欢迎进入《Linux驱动综合项目交付工程》。这不是一门只讲“如何写一个字符设备驱动”的入门课，而是一门面向真实产品交付的工程化课程。它关注的不是单个驱动能否编译通过，而是从需求分析、硬件确认、驱动实现、内核适配、调试验证，到版本管理、文档交付、量产维护的完整闭环。换句话说，本课程的目标是让你具备“把驱动代码变成可交付产品”的能力。

一、学习目标：从“会写驱动”到“能交付项目”

本课程的学习目标可以拆成四个层次。第一层是技术能力：掌握字符设备、平台设备、设备树、GPIO、I2C、SPI、中断、DMA、输入子系统、LED 子系统等常见驱动框架，并能根据硬件手册完成驱动移植与适配。第二层是调试能力：熟练使用 dmesg、printk、ftrace、perf、gpioinfo、i2cdetect、逻辑分析仪和示波器定位问题。第三层是工程能力：理解内核版本管理、补丁生成、代码评审、持续集成和交叉编译工具链。第四层是交付能力：能输出驱动源码、设备树、配置片段、测试报告、接口文档和升级说明，使项目可维护、可复现、可量产。

很多初学者把驱动开发等同于“写一个 file_operations 结构体”，但真实项目中，驱动只是整个交付物的一部分。一个没有设备树配置、没有测试记录、没有版本说明的驱动，即使功能正常，也无法通过项目验收。因此，本课程会反复强调“交付物思维”。

二、核心概念：驱动、设备、总线与交付基线

Linux 驱动模型的核心是“总线—设备—驱动”三者匹配。总线负责匹配，设备描述硬件资源，驱动负责操作硬件。以平台设备为例，设备树中的节点描述寄存器地址、中断号、时钟和 GPIO，驱动通过 of_match_table 与设备匹配，匹配成功后执行 probe 函数完成初始化。

static const struct of_device_id demo_of_match[] = {
    { .compatible = "vendor,demo-device" },
    { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, demo_of_match);

static struct platform_driver demo_driver = {
    .probe  = demo_probe,
    .remove = demo_remove,
    .driver = {
        .name           = "demo-driver",
        .of_match_table = demo_of_match,
    },
};
module_platform_driver(demo_driver);

除了代码本身，交付基线还包括：内核版本、编译器版本、根文件系统版本、设备树版本、测试用例版本和硬件版本。任何一项变化都可能导致驱动行为不同。因此，工程上常用“配置清单”来锁定交付基线。

三、整体框架：从硬件到应用的五层结构

为了看清驱动在系统中的位置，可以用下面的结构图理解。硬件层提供寄存器、中断和时钟；内核驱动层完成资源申请、设备注册和数据处理；内核子系统层提供统一接口；用户空间通过设备节点、sysfs 或 ioctl 访问；应用层完成业务逻辑。驱动工程师的工作重点在中间两层，但必须理解上下层的约束。

四、交付流程：六个阶段与关键产物

真实项目的交付流程通常分为六个阶段。每个阶段都有明确的输入、输出和评审点。下表给出一个可落地的流程清单。

五、案例场景：一个 GPIO 按键驱动的交付路径

假设项目需求是“通过 GPIO 按键触发系统休眠，并在 sysfs 中上报按键次数”。初学者可能直接写一个字符设备，在 read 中轮询 GPIO。但工程化做法是：先确认按键连接的 GPIO 编号、上拉方式、去抖时间；然后在设备树中定义按键节点，使用 gpio-keys 或输入子系统；驱动中申请中断，使用 request_threaded_irq 处理去抖；通过 sysfs 暴露统计值；最后编写测试脚本，模拟 1000 次按键并检查计数一致性。

# 查看按键事件
evtest /dev/input/event2

# 查看 GPIO 状态
gpioinfo | grep -i key

# 查看内核日志
dmesg | tail -n 30

这个案例说明：驱动代码只是交付链中的一环。设备树、测试脚本、日志和文档同样重要。缺少任何一项，项目都可能无法通过验收。

六、常见误区与复盘