wdfk-prog的个人博客

[TOC] fdtdec 扁平设备树解析 devicetree devicetree-specification devicetree-specification.pdf 设备树BLLOB结构 123456789101112131415161718struct fdt_header { fdt32_t magic; /* magic word FDT_MAGIC */ fdt32_t totalsize; /* total size of DT block */ fdt32_t off_dt_struct; /* offset to structure */ fdt32_t off_dt_strings; /* offset to strings */ fdt32_t off_mem_rsvmap; /* offset to memory reserve map */ fdt32_t version; /* format version */ fdt32_t last_comp_version; /* last compatible ver...

[toc] drivers/input/input.c 输入子系统核心(Input Subsystem Core) 统一所有输入设备的事件处理框架历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术以及它所构建的整个输入子系统，是为了解决在Linux早期一个极其混乱的问题：缺乏一个统一的、标准化的方式来处理各种各樣的输入设备。 接口不统一：在输入子系统出现之前，每一种输入设备（PS/2鼠标、串口鼠标、AT键盘等）都有其自己独特的驱动程序，这些驱动会创建各自不同的设备文件（如/dev/psaux, /dev/mouse），并使用自己私有的数据协议。 应用程序复杂性：这意味着用户空间的应用程序（尤其是X Window System）必须编写大量复杂的、针对特定硬件的代码，才能从这些不同的设备文件中读取和解析输入数据。更换一个鼠标，就可能需要重新配置X Window。 可扩展性差：每当出现一种新的输入设备，不仅需要编写内核驱动，还需要修改上层的应用程序才能支持它。 输入子系统（由Vojtech Pavlik创建）的诞生，就是为了彻底解决这个乱...

[TOC] drivers/i2c I2C总线子系统(I2C Bus Subsystem) 管理I2C总线控制器与设备历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/i2c 目录中的代码实现了Linux内核的I2C（Inter-Integrated Circuit）总线子系统。这项技术的诞生是为了解决在Linux系统中管理和访问大量通过I2C总线连接的外设时面临的代码冗余、缺乏抽象和可移植性差的问题。 I2C是一种简单、低速的两线（SDA -串行数据线, SCL -串行时钟线）串行总线，广泛用于连接微控制器和各种外围芯片（如传感器、EEPROM、RTC、PMIC等）。在没有统一子系统的情况下： 驱动与硬件耦合：每个需要访问I2C设备的驱动程序，都必须包含直接操作特定I2C控制器硬件（即“总线主控器”）的代码。这意味着为一个I2C传感器编写的驱动，在更换了主控芯片（如从NXP的SoC换到Broadcom的SoC）后就无法工作，必须重写。 代码重复：访问I2C总线的基本协议（起始/停止信号、发送地址、读写数据、ACK/NACK）是标准...

[toc] drivers/iio 工业I/O子系统(Industrial I/O) 统一的传感器数据采集框架历史与背景这项技术是为了解决什么特定问题而诞生的？IIO（Industrial I/O）子系统的诞生是为了解决Linux内核中一个长期存在的混乱问题：缺乏一个标准的、统一的框架来处理各种传感器和数据转换器（ADC/DAC）。 在此框架出现之前，这类设备的驱动程序散落在内核的各个角落，缺乏一致性： 滥用其他子系统：一些加速度计驱动程序为了方便，将自己伪装成一个input设备（如摇杆），但这在语义上是不正确的。input子系统是为用户输入事件（如按键、鼠标移动）设计的，而不是为了测量物理世界的数据。 使用私有的字符设备：许多驱动创建自己独特的字符设备接口，使用自定义的ioctl命令。这导致用户空间的应用程序必须为每一种不同的传感器编写特定的支持代码，无法通用。 滥用sysfs：一些驱动直接通过sysfs文件来暴露连续的数据流。Sysfs的设计初衷是用于传递少量、低频的配置信息或状态值（“一文件一值”），用它来读取高速的数据流...

[toc] drivers/nvmem/core.c NVMEM核心(NVMEM Core) 非易失性内存的统一访问框架历史与背景这项技术是为了解决什么特定问题而诞生的？NVMEM（Non-Volatile Memory）子系统的诞生是为了解决一个在嵌入式系统中普遍存在的问题：如何以一种标准的、统一的方式来访问各种小型、非易失性存储设备中的原始数据。 在此框架出现之前，内核中没有一个专门的子系统来处理这类需求，导致了实现上的混乱： 缺乏统一接口：一个以太网驱动需要从板载的I2C EEPROM中读取MAC地址，而一个无线网卡驱动可能需要从SoC内部的EFUSE（电子熔丝）中读取校准数据。这些驱动不得不自己去实现与特定存储芯片（EEPROM, EFUSE, OTP等）的交互逻辑，或者依赖于特定平台的私有接口。 驱动间强耦合：设备驱动（消费者）被迫要知道提供数据的存储芯片（生产者）的具体细节。如果硬件设计发生变化，例如将MAC地址从EEPROM移到了SPI Flash的一个分区中，那么设备驱动的代码就需要进行重大修改。 代码重复与不可移植：每个需要读取配置数据的驱...

[TOC] drivers/mfd 多功能设备驱动核心(Multi-Function Devices Core) 管理集成多种功能的复合芯片历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术是为了解决现代集成电路（IC）日益增长的功能集成度所带来的驱动程序开发和管理难题。许多现代芯片，特别是电源管理集成电路（PMIC）、音频编解码器（Audio Codec）、系统控制器等，不再是单一功能的设备。它们在一个物理芯片上集成了多个可以独立工作的硬件模块。例如，一个PMIC可能同时包含： 多个直流-直流（DC-DC）转换器和低压差线性稳压器（LDO） 一个实时时钟（RTC） 一个GPIO控制器 一个中断控制器 一个看门狗定时器（Watchdog） 一个ADC（模数转换器） 如果没有MFD框架，开发者可能会编写一个巨大的、单一的“巨石型”（Monolithic）驱动程序来管理所有这些功能。这种做法会导致以下问题： 代码臃肿且难以维护：一个驱动文件包含所有功能的逻辑，违反了单一职责原则，代码耦合度高。 缺乏模块化和重用性：RTC功能部分的代码无法被内核标准的RTC子系...

[TOC] drivers/leds LED子系统(LED Subsystem) 内核统一的LED设备控制框架历史与背景这项技术是为了解决什么特定问题而诞生的？LED子系统的诞生是为了解决在Linux内核中缺乏一个统一、抽象的LED管理方式的问题。在此框架出现之前，对LED的控制是零散且混乱的： 驱动代码重复：每个需要控制LED的驱动程序（例如，网卡驱动、SD卡驱动）都必须自己去实现操作GPIO或特定硬件寄存器的代码，导致大量功能相似的代码被重复编写。 缺乏统一的用户接口：用户无法以一种标准的方式来查看系统中有哪些LED，也无法在运行时改变它们的行为。控制LED的逻辑被硬编码在各自的驱动中。 逻辑与硬件强耦合：LED的“物理”控制（如何点亮它）和“逻辑”行为（为什么点亮它，例如因为网络活动）被混杂在一起。这使得更换LED硬件或改变其用途变得非常困难。 LED子系统的核心目标就是创建一个清晰的框架，将LED的物理控制与触发其亮灭的系统事件彻底解耦，并为用户空间提供一个标准的控制接口。 它的发展经历了哪些重要的里程碑或版本迭代？LED子系统的发展核心是触发器（Tr...

[toc] drivers/mmc 多媒体卡(MultiMediaCard)子系统 SD/eMMC/SDIO设备驱动框架历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/mmc 子系统是为了给Linux内核提供一个统一的、可扩展的框架来支持一整类基于**多媒体卡（MultiMediaCard）**规范及其衍生协议的设备而诞生的。这些设备包括： MMC (MultiMediaCard)：一种早期的闪存卡标准。 SD (Secure Digital) Card：在MMC基础上发展而来的、目前最普及的移动存储卡，增加了安全特性和更高的性能。 eMMC (embedded MMC)：将MMC控制器和NAND闪存封装在同一个BGA芯片中，作为一种“嵌入式”存储解决方案，被广泛用作智能手机、平板电脑和许多嵌入式设备的“硬盘”。 SDIO (Secure Digital Input/Output)：一种扩展规范，允许SD插槽除了支持存储卡外，还能连接I/O设备，如Wi-Fi模块、蓝牙模块、GPS接收器等。 在没有这个统一框架...

[TOC] drivers/pinctrl Pin Control子系统(Pin Control Subsystem) 管理引脚复用与电气配置的框架历史与背景这项技术是为了解决什么特定问题而诞生的？Pinctrl（Pin Control）子系统的诞生是为了解决现代SoC（片上系统）中一个极其普遍且复杂的问题：物理引脚（Pin）的管理。在此框架出现之前，引脚配置是Linux内核中一个混乱的领域。 它主要解决了三大核心问题： 引脚复用（Pin Multiplexing）：现代SoC的物理引脚通常具有多种功能。例如，同一个物理引脚可能既可以作为通用的GPIO，也可以作为UART的发送端（TX），或者I2C的时钟线（SCL）。内核需要一个机制来在这些功能之间进行选择和切换。 引脚配置（Pin Configuration）：除了功能选择，引脚的电气特性也需要配置。这包括设置上拉/下拉电阻、驱动强度、转换速率（Slew Rate）、开漏/推挽模式等。 代码的混乱与不可移植性：在Pinctrl子系统出现之前，上述所有的配置逻辑都散落在各个角落： 硬编码在板级文件...

[TOC] drivers/char 字符设备(Character Devices) 面向字节流的设备驱动模型历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/char 目录及其实现的字符设备（Character Device）模型是Linux乃至整个UNIX家族中最古老、最基础的驱动模型之一。它的诞生源于UNIX的设计哲学——“一切皆文件”（Everything is a file）。 这项技术的核心目标是为那些不以固定大小的数据块（block）进行I/O，而是以连续的字节流（byte stream）方式进行通信的硬件设备提供一个统一、标准的抽象接口。在早期，这主要包括： 终端和串口（TTYs and Serial Ports）：用户通过键盘输入字符，屏幕显示字符，这些都是典型的字节流操作。 打印机：向打印机发送要打印的数据流。 磁带机：顺序地读取或写入数据。 通过将这些硬件抽象成文件系统中的一个节点（如 /dev/ttyS0），用户空间的应用程序就可以使用标准的文件I/O系统调用（open, read, write, c...