目录第1章 为什么现代驱动必须用设备树本章目标一、先看一个真实场景同一个LED驱动的两种命运1. 老式驱动的写法硬编码硬件参数2. 设备树驱动的写法硬件信息抽离二、老式硬编码驱动的三大核心痛点1. 移植性极差2. 代码冗余极高3. 主线内核无法维护三、设备树的本质硬件的标准化描述文件四、核心设计思想软硬分离什么是软硬分离分离的核心优势五、现代驱动的三层架构模型各层的协作流程六、常见认知误区误区1设备树是ARM架构特有的误区2简单驱动不需要用设备树误区3设备树只是把宏定义搬到了外面本章总结第1章 为什么现代驱动必须用设备树本章目标理解老式硬编码驱动的核心痛点掌握设备树的本质与核心价值建立「软硬分离」的驱动设计思想了解现代驱动的三层架构体系一、先看一个真实场景同一个LED驱动的两种命运我们用最常见的LED控制驱动举例直观感受两种开发模式的区别。假设公司做两款产品产品ALED接在GPIO1_0引脚产品BLED接在GPIO3_5引脚两款产品的LED功能完全一致亮、灭、闪烁1. 老式驱动的写法硬编码硬件参数老式驱动会直接把硬件引脚写死在代码里通常用宏定义/* 产品A的驱动代码 */ #define LED_GPIO_PIN 0 // 硬编码GPIO引脚号 #define LED_GPIO_PORT 1 // 硬编码GPIO端口 static int led_init(void) { gpio_set_direction(LED_GPIO_PORT, LED_GPIO_PIN, OUTPUT); return 0; }当切换到产品B时必须修改驱动源码里的宏定义重新编译整个驱动才能正常使用。如果后续再有产品C、产品D就要维护多份几乎一样的驱动代码。2. 设备树驱动的写法硬件信息抽离设备树模式下硬件引脚信息不会出现在驱动代码里而是单独写在设备树文件中/* 产品A的设备树片段 */ led { compatible myboard,user-led; gpios gpio1 0 GPIO_ACTIVE_HIGH; };/* 产品B的设备树片段 */ led { compatible myboard,user-led; gpios gpio3 5 GPIO_ACTIVE_HIGH; };而驱动代码全程不出现具体的引脚号只需要通过标准接口从设备树中读取引脚配置static int led_probe(struct platform_device *pdev) { /* 从设备树自动获取GPIO引脚代码里没有任何硬编码 */ struct gpio_desc *led_gpio devm_gpiod_get(pdev-dev, NULL, GPIOD_OUT_LOW); return 0; }两款产品共用同一份驱动代码换硬件只需要修改设备树文件驱动源码一行不动也不需要重新编译驱动。二、老式硬编码驱动的三大核心痛点上面的LED例子虽小却暴露了老式驱动所有的本质问题。1. 移植性极差硬件参数和驱动逻辑强绑定只要硬件稍有变动引脚换了、地址变了、中断改了就必须修改驱动源码、重新编译、重新测试。同一款芯片的不同开发板驱动无法直接复用产品迭代改硬件驱动就要跟着改牵一发而动全身2. 代码冗余极高同一种功能的驱动不同板子各写一份逻辑完全重复只是硬件参数不同。 内核发展早期大量板级支持文件涌入内核源码同一款芯片的十个板子就有十份类似的板级代码造成了大量的重复劳动和维护成本。3. 主线内核无法维护Linux内核主线社区很早就明确拒绝硬编码的板级驱动。如果每个厂商都把自己板子的硬件参数写进驱动内核代码会无限膨胀且无法通用化。 设备树就是内核社区为了解决这个问题推出的标准化方案。三、设备树的本质硬件的标准化描述文件设备树Device Tree简称DT的本质是一份用树状结构描述硬件配置的标准化文件。它的核心作用只有一个把所有硬件相关的信息从驱动代码里彻底剥离出来。角色负责内容举例设备树描述「硬件是什么、参数是什么」LED接在GPIO3_5引脚、低电平点亮驱动代码实现「硬件怎么用、功能怎么实现」LED亮、灭、闪烁的控制逻辑简单说设备树告诉内核板子上有什么驱动告诉内核这个东西怎么工作。四、核心设计思想软硬分离设备树带来的不只是语法变化更是整个驱动设计思想的转变——软硬分离。什么是软硬分离硬件相关的部分寄存器地址、中断号、GPIO引脚、时钟频率、设备参数等所有和具体板子相关的信息全部写入设备树逻辑相关的部分设备初始化、数据读写、功能控制、中断处理等所有通用功能逻辑全部留在驱动代码中分离的核心优势驱动通用化一份驱动可以适配任意多块板子只要设备树描述正确硬件变更成本低改硬件只改设备树驱动逻辑不受影响不用重新编译驱动可维护性强硬件信息集中管理驱动逻辑专注功能边界清晰符合内核规范主线内核所有新驱动都必须采用设备树方案硬编码驱动无法进入主线五、现代驱动的三层架构模型基于设备树的现代驱动形成了标准的三层架构每层职责明确边界清晰。我们继续用LED驱动举例对应层级名称职责LED例子中的对应内容谁来维护第一层硬件描述层设备树描述板子的硬件拓扑与参数led节点里的gpio引脚、极性、状态板级硬件工程师第二层总线核心层内核内置负责设备与驱动的匹配、资源管理GPIO子系统、平台总线、设备树解析器内核官方第三层驱动逻辑层驱动代码实现设备的具体功能逻辑控制LED亮灭闪烁的逻辑代码驱动开发者各层的协作流程内核启动时解析设备树生成对应的硬件设备节点注册到对应总线上驱动加载时向总线注册自己的驱动总线通过compatible属性将设备和驱动匹配起来匹配成功后调用驱动的初始化函数驱动从设备树获取资源并开始工作整个过程完全由内核总线框架自动完成驱动开发者只需要专注于第三层的功能逻辑实现。六、常见认知误区误区1设备树是ARM架构特有的设备树最早用于PowerPC架构后来推广到ARM现在x86、RISC-V等所有主流架构都在使用设备树描述硬件。它是Linux驱动的通用标准和架构无关。误区2简单驱动不需要用设备树哪怕是最简单的LED驱动只要是产品级开发都应该遵循设备树范式。今天是简单的GPIO明天可能要加定时器、加中断早用标准架构后续扩展成本极低。误区3设备树只是把宏定义搬到了外面设备树不只是替换了宏定义它带来的是总线匹配、资源自动管理、标准接口统一等一整套体系是整个驱动开发模式的升级。本章总结老式硬编码驱动存在移植性差、代码冗余、维护困难三大核心痛点已经被内核主线淘汰设备树的本质是硬件的标准化描述文件核心作用是将硬件信息从驱动代码中剥离现代驱动遵循「软硬分离」的设计思想驱动只负责逻辑硬件参数全部由设备树描述现代驱动分为设备树层、总线核心层、驱动逻辑层三层架构每层职责明确边界清晰设备树是Linux工业级驱动的标准范式也是所有现代驱动开发的基础下一章我们将深入设备树本身讲解它的树状结构、核心属性与语法规范。