目录一、新手容易踩的认知坑二、历史演变从硬编码到子系统设备树的转变1原始裸奔时代无结构体、无设备树、无总线架构2结构体封装时代有结构体、无设备树、有总线架构3子系统设备树时代现代标准架构三、从源代码角度分析通用驱动 compatible 匹配如何实现自动化驱动1第一步设备树DTS—— 硬件信息的 “说明书”2第二步驱动源码leds-gpio.c—— 通用驱动的核心实现3第三步probe中调用深层函数真正写入寄存器四、通用驱动不是万能的驱动工程师的核心价值与兜底场景五、日常开发中如何写寄存器1设备树怎么查、怎么写​2如何在运行中动态修改寄存器一、新手容易踩的认知坑相信很多从STM32转Linux驱动开发的新手小白都会有一个根深蒂固的思维误区我以为Linux驱动中说的子系统就是类似STM32的HAL库函数是一堆可以直接调用的寄存器操作函数。而我们写驱动开发就是换了个地方写HAL库。但当真正上手Linux后发现并不是这么回事写个 LED 控制居然不用自己写寄存器操作函数为什么只在设备树里加几行配置灯就自己亮了所谓的 “子系统”到底是个什么东西那么本篇文章就用最直白的逻辑把“库函数思维”到“子系统思维”的完整转变讲透帮助大家彻底明白子系统到底干了啥。二、历史演变从硬编码到子系统设备树的转变Linux驱动开发大体分为几个阶段。但用一句话总结就是从 “人写代码硬操作寄存器” → “人写结构体封装硬件信息人读取结构体并硬操作寄存器” → “人写设备树描述硬件子系统自动匹配通用驱动自动操作硬件”。1原始裸奔时代无结构体、无设备树、无总线架构早期Linux刚刚诞生的时候内核2.4之前驱动开发其实和STM裸机开发并无本质区别都是工程师直接对着硬件手册、开发板使用说明书直接硬编码寄存器地址、硬编码寄存器配置函数。这意味着代码和开发板强绑定换个芯片、开发板寄存器地址可能就变了就得重新编写所有代码。而且没有任何封装概念代码的健壮性、复用性全看工程师的个人能力。2结构体封装时代有结构体、无设备树、有总线架构随着使用的硬件越来越多一些大佬逐渐发现了上述原始阶段的弊端开始尝试解耦把硬件信息地址、中断、GPIO封装成 C 语言结构体struct resource、struct platform_device驱动只读取结构体不写死硬件地址换板子只改结构体不用改驱动。让软件工程师和硬件工程师可以更好的协作配合。这就是早期的 platform 总线架构实现了 “硬件信息” 和 “驱动逻辑” 的初步分离。后来很多大佬觉得这样还是不好用能不能我写好一份通用驱动以后直接让别人匹配绑定呢这其实就是compatible字段、子系统的由来。这一点我们以后在讲解platform总线的时候再详细分析。目前我们只需要有驱动、硬件描述结构体匹配的概念即可。3子系统设备树时代现代标准架构虽然在上一个时代已经将配置信息与寄存器等硬件地址的强绑定进行了解耦但还是有一些不足的同一款芯片不同板子由于寄存器配置信息不同需要维护 N 份结构体代码内核越来越臃肿。改硬件配置要改 C 代码、重新编译内核非常麻烦。于是 Linux 引入了设备树Device Tree把结构体进一步抽象成文本配置文件硬件信息从 C 代码迁移到 DTS 文件彻底和内核代码分离。子系统负责解析设备树、自动构建设备、匹配驱动。这就是我们上个时代末尾提出的观点改硬件配置只需要改 DTS不用重新编译内核真正实现了 “配置即驱动”。在启动的时候内核自动读取DTS进行自动化配置。三、从源代码角度分析通用驱动 compatible 匹配如何实现自动化驱动关于下面的步骤不是研究内核的人可能很难掌握的很好。不过没有关系我们仅仅是想从源码的角度看看子系统到底如何实现自动匹配自动初始化的。这一块我们会在platform中更详细的分析。最后发现子系统这一套就是总线架构的实现即总线架构是一种设计思想而子系统是一个实现该思想的实例。它一直遵循着设备、驱动的解耦与匹配。1第一步设备树DTS—— 硬件信息的 “说明书”我们先在设备树中描述 LED 硬件核心是compatible属性告诉内核用哪个驱动2第二步驱动源码leds-gpio.c—— 通用驱动的核心实现我们简化源码只保留核心逻辑3第三步probe中调用深层函数真正写入寄存器四、通用驱动不是万能的驱动工程师的核心价值与兜底场景尽管通过刚刚的分析我们明白了一般情况下不需要驱动工程师直接写寄存器级别的操作函数这是因为内核中已经包含了市面上绝大多数外设的通用驱动在你裁剪内核的时候加入选项选择是否需要裁剪所以日常开发中只需要知道这个外设用的什么驱动然后对compatible属性赋值即可。不过如果出现一种新的外设比如你在芯片原厂工作那么这个probe函数就得你手动完成了。即所谓的子系统就是probe中的函数调用而这一切现在只能靠你自己写了。不过一般我们只要不是在芯片原厂工作则不会涉及到上述繁琐步骤在日常开发中选择提供了标准子系统的厂商即可。五、日常开发中如何写寄存器1设备树怎么查、怎么写驱动工程师的日常工作本质上就是通过设备树描述硬件把寄存器级的配置操作完全交给子系统自动完成。而设备树的编写核心只有一件事查 Binding 文档。在你的 Linux 内核源码中路径Documentation/devicetree/bindings/下存放着海量由半导体厂商、外设厂商贡献的.txt/.yaml文件它们就是设备树的官方使用说明书规范了每一款硬件的 DTS 写法。比如下图就是 Atmel 公司 GPIO 控制器的 Binding 文档里面清晰标注了必选属性Required propertiescompatible、reg、#gpio-cells、gpio-controller等是写 DTS 时必须严格遵守的规范属性含义说明每个字段的作用、格式要求完整 DTS 示例直接可以参考复用的配置模板。补充说明早期内核以.txt格式的 Binding 文档为主内容相对精简现代内核比如我用的Linux 6.8已全面转向.yaml格式不仅规范更严格还附带详细的使用手册链接、校验规则可查阅的信息更完善全面。不过这个使用文档通常不是很全面多以.txt文件为主。现代的厂家一般会提供.yaml格式文件并附带设备树使用手册的网页链接点进去可以详细看到更多使用方法更加完善全面。https://www.devicetree.org/这个是Linux提供的设备树公共手册可以查询到市面上几乎所有的硬件。2如何在运行中动态修改寄存器设备树是静态配置只会在初始化的时候配置一次寄存器但运行环境可能千变万化。不说修改外设的工作模式单单一个GPIO高低电平控制就是非常容易改变的那么我们如何在运行中动态修改寄存器的配置呢答案就在路径/home/hmy/linux-mini/linux-6.8/include/linux/gpio/下的consumer.h文件中consumer直译就是「消费者」代表使用 GPIO 的上层外设驱动工程师区别于提供 GPIO 控制器的芯片原厂工程师这个头文件里封装了 GPIO 子系统对外的标准通用 API比如gpiod_set_value、gpiod_direction_output等就是你在驱动中动态修改寄存器的唯一入口。比如下面就是gpio通用的一些函数这些 API 本质上就是Linux 版的「标准化 HAL 库」它屏蔽了不同厂商 GPIO 控制器的寄存器差异跨平台通用上层驱动只需要调用这些 API无需关心底层writel操作寄存器的细节所有寄存器修改都会通过 GPIO 子系统转发到底层厂商驱动完成彻底解耦硬件与业务逻辑。我们以后在写驱动代码的时候首先通过设备树静态配置外设的工作模式等属性然后在运行中利用consumer.h中提供的库函数动态修改即可。