wdfk-prog的个人博客

[toc] include/linux/mmc/sdio.hSDIO协议核心定义：命令、响应及寄存器映射本文件是Linux内核中用于支持SDIO（Secure Digital Input/Output）卡的核心头文件。它不包含可执行代码，而是完全由C预处理器宏（#define）构成。其核心功能是将SDIO物理规范中定义的命令码、寄存器地址、响应格式以及寄存器内的位域（bit fields）等数值，翻译成一组具有明确语义的符号常量。这为上层的SDIO核心逻辑和底层的主机控制器驱动提供了一个标准、可读且与具体数值无关的编程接口，是内核中所有SDIO相关操作的基础。 实现原理分析该文件的实现原理是典型的“规范到代码”的直接映射，是硬件编程中的一种基础实践。 符号化常量: 文件使用 #define 将SDIO规范中定义的魔法数字（Magic Numbers）替换为人类可读的名称。例如，将SDIO的“读写直接命令”的操作码52定义为SD_IO_RW_DIRECT。这样做极大地提高了代码的可读性和可维护性，当规范更新时，只需修改一处定义即可。 ...

[TOC] drivers/mmc/core/sd_ops.c1234567891011121314int mmc_send_ext_addr(struct mmc_host *host, u32 addr){ struct mmc_command cmd = { .opcode = SD_ADDR_EXT, .arg = addr, .flags = MMC_RSP_R1 | MMC_CMD_AC, }; if (!mmc_card_ult_capacity(host->card)) return 0; return mmc_wait_for_cmd(host, &cmd, 0);} drivers/mmc/core/sd_uhs2.c SD UHS-II总线管理(SD UHS-II Bus Management) 实现UHS-II卡初始化与信号调整历史与背景这项技术是为了解决什么特定问题而诞生的？这项技术是为了支持 SD UHS-II（Ultra ...

[TOC] Linux I2C 控制器驱动目录解析[drivers/i2c/busses] [I2C 总线控制器（Adapter）驱动集合] [为不同 SoC/控制器实现 I2C 主控/从控能力，并向 i2c-core 注册 i2c_adapter]介绍drivers/i2c/busses/ 是 I2C 控制器（bus controller / host controller）驱动的集中目录： 每个文件（或一组文件）通常对应一种硬件 I2C 控制器 IP（例如某 SoC 内置 I2C、某 PCI/ACPI I2C 控制器、某外设桥接控制器）。 这些驱动的共同目标是：把硬件能力抽象成一个 i2c_adapter，并通过 i2c-core 让上层设备驱动（i2c_client 驱动）能用统一接口读写从设备。 历史与背景为了解决什么问题而诞生Linux 需要把“不同厂家的 I2C 控制器寄存器/时序/中断/DMA差异”屏蔽掉，让上层设备驱动只关心“在某条 I2C 总线上读写某地址的寄存...

[TOC] drivers/i2c/i2c-core-smbus.c I2C/SMBus核心协议(I2C/SMBus Core Protocol) 实现SMBus事务处理历史与背景这项技术是为了解决什么特定问题而诞生的？drivers/i2c/i2c-core-smbus.c 文件实现了对**系统管理总线（System Management Bus, SMBus）**协议的支持。SMBus是基于I2C（Inter-Integrated Circuit）协议演变而来的一种子集或变体，专为系统和电源管理而设计。这项技术旨在解决以下问题： 标准化系统管理：为计算机系统中的各种低速设备（如电池、温度传感器、风扇控制器、电源管理芯片）提供一个标准的、低速、两线式的通信接口。 事务可靠性：SMBus在I2C的基础上增加了协议层面的可靠性检查，例如，大多数SMBus命令都包含**PEC（Packet Error Checking，数据包错误校验）**机制，以确保数据传输的完整性。 简化驱动开发：提供了一套预定义的、原子性的事务类型（如快速命令、读...

[TOC] Linux i2c-dev 字符设备接口解析[drivers/i2c/i2c-dev.c] [I2C 用户态访问接口（/dev/i2c-X）] [把 I2C/SMBus 适配器以字符设备形式暴露给用户态，通过 read/write/ioctl 执行传输] 介绍i2c-dev.c 的核心作用是：为每个 I2C adapter 创建一个字符设备节点 /dev/i2c-N，让用户态可以不写内核驱动也能直接做 I2C/SMBus 访问。它通常被 i2c-tools（如 i2cdetect/i2cget/i2cset/i2ctransfer）等工具使用，也常用于板级 bring-up、调试、产测脚本、以及临时验证寄存器读写。 历史与背景诞生为了解决什么问题？ 调试与快速验证：很多时候只想验证总线是否通、寄存器是否可读写，不希望立刻写完整内核驱动。 用户态工具生态：把“原始 I2C 事务”能力开放给用户态，便于通用工具工作。 重要迭代特征（从当前设计可推断的演进方向） 从“只支持简单 rea...

[toc] Linux 内核 BCD 转换工具解析[lib/bcd.c] [BCD 转换（bcd2bin/bin2bcd）] [提供 1 字节 BCD 与二进制数之间的高效互转实现，并导出为内核通用符号]介绍lib/bcd.c 只有两件事：实现并导出两个函数 _bcd2bin() 与 _bin2bcd()。它们通常通过 include/linux/bcd.h 里的宏 bcd2bin() / bin2bcd() 被驱动代码调用： 常量参数：走 const_* 宏，编译期直接折叠； 非编译期常量：走 _bcd2bin/_bin2bcd，运行期完成转换，同时尽量避免代价更高的除法/取模路径。 BCD（Binary-Coded Decimal，二进制编码十进制）就是：用 4 个二进制位表示 1 个十进制数字（0~9）。常见是把一个字节拆成两个“半字节”（nibble）： 高 4 位：十位数字 低 4 位：个位数字 例子 十进制 45 十位是 4 → 二进制 0100 个位是 5 → 二进制 0101 合在一起：0x45（也就是 01...

[TOC] Linux 内核 seq_buf 实现解析（lib/seq_buf.c）[lib/seq_buf.c] [seq_buf：序列化缓冲区工具] [在固定大小缓冲区内安全地累积格式化输出，并支持“分段读出”给用户态]介绍seq_buf 可以理解为一个**“带状态的 snprintf 追加器”：你给它一个固定大小的 char buffer[]，然后不断 printf/puts/putc 追加内容。它会维护当前写入位置、是否溢出等状态，保证不越界写**，并且常配套提供“按 readpos 分段把数据拷给用户态”的能力，常用于各种 debug 输出路径（尤其是实现 proc/debugfs/sysfs 的 show/read 辅助逻辑）。 历史与背景为了解决什么问题而诞生？内核里经常需要拼接字符串输出（调试信息、统计信息、状态信息）： 只用 snprintf/scnprintf：每次都要手动管理“剩余长度、当前偏移”，代码重复且容易写错。 只用 seq_file：能力强但更重，必须走 start/next/...

[toc] bust_spinlocks：在 oops/panic 等路径放宽“控制台/日志相关锁约束”，保证关键日志可达作用与实现原理 yes != 0：进入 oops/panic 类路径，递增 oops_in_progress，表示系统正处在异常打印阶段。 yes == 0：退出异常打印阶段，调用 console_unblank() 尝试唤醒/点亮控制台；递减 oops_in_progress，当其回到 0 时唤醒日志守护线程（传统实现中为 klogd 相关等待队列）。 该函数名中的 “bust spinlocks” 的含义是：异常阶段可能有锁/状态阻止日志输出，该函数通过提升 oops_in_progress 等全局状态让相关路径避免在锁上阻塞或放宽某些限制，从而提高“panic/oops 信息可达性”。 bust_spinlocks123456789101112131415161718/** * @brief 在 oops/panic 等异常路径中切换“允许输出关键日志”的模式。 * * @param...

[toc] [kernel/panic.c] [内核 Panic/Oops 终止路径] [在不可恢复错误时完成“停止系统/通知/转储/重启”等收尾流程]介绍kernel/panic.c 主要实现内核在致命错误时的统一收尾路径： panic()：不可继续运行时进入的终止流程（通常不返回）。 与 Oops/BUG/WARN 的策略联动：例如 “Oops 是否升级为 panic”、是否自动重启、是否触发 kdump 等。 提供 panic notifier、kmsg dump、停止其它 CPU、控制台输出解锁（bust spinlocks）等机制，尽量在系统已不稳定时仍完成关键动作。 历史与背景诞生解决的问题 内核遇到不可恢复错误时，继续运行可能导致数据破坏扩大；需要统一路径完成： 记录信息（console/printk、dumpers） 通知相关子系统（notifier） 尝试转储（kdump/kmsg_dump/pstore 等） 停止并发扰动（停其它 CPU...

@[toc] Git实战指南：如何从另一个分支同步文件时完整保留Commit提交历史本文将深入解析Git中两种截然不同的文件同步方式，重点解决一个核心问题：如何从另一个分支获取文件，同时不丢失原作者、提交时间和提交说明等历史记录。我们将对“仅复制文件内容”与“移植提交记录”进行对比，并详细拆解“手动修改触发Cherry-Pick”这一高阶技巧的底层逻辑。 1. 为什么普通复制会丢失历史记录？在Git中，最直观的同步方式是直接把文件“拿过来”。这种方式对应命令 git restore 或 git checkout。它的本质是将文件的当前状态复制到你的工作区，但不包含该文件之前的任何演变过程。 1.1 git restore/checkout 的工作原理当执行这两个命令时，Git仅仅是读取了源分支里该文件的内容（Blob数据），然后用这些内容覆盖你当前分支的文件。 结果：你得到了最新的文件代码。 代价：当你提交（commit）时，Git会把这当作是你刚刚创建的一次全新修改。原作者的名字、原来的提交时间、原来的Commit Message（提交说明）全部消失，变成了当前操作者的...