3. 存储与IO子系统架构：Linux块设备层、MMC子系统、SDIO子系统、设备模型（bus/device/driver）的层次关系
在嵌入式Linux系统中，eMMC与SDIO设备（如WiFi模组、蓝牙控制器）的驱动开发，首先要求开发者对存储与IO子系统的整体架构有清晰认知。许多驱动问题——例如设备无法枚举、块设备读写超时、中断风暴——其根源往往不在于具体的寄存器配置错误，而在于对Linux设备模型与子系统间数据流、控制流的层次关系理解错位。本章将系统梳理从应用层到硬件层的完整链路，重点剖析块设备层、MMC子系统、SDIO子系统以及设备模型（bus/device/driver）之间的协作机制与边界职责。
上图展示了从应用层到物理设备的完整层次链路。理解该图的关键在于：块设备层与MMC子系统之间通过mmc_blk驱动进行桥接，而MMC子系统与设备模型之间则通过mmc_bus_type和sdio_bus_type实现标准化的设备-驱动匹配。下面我们将逐层深入，剖析每一层的核心职责与交互方式。
3.1 核心原理：各层次职责与数据流
Linux存储IO子系统的设计哲学是分层解耦。每一层只关注特定粒度的抽象，通过标准接口向上层提供服务，向下层屏蔽实现细节。对于eMMC和SDIO设备，其核心层次可归纳为以下四层：
| 层次 | 核心数据结构 | 主要职责 | 关键接口/函数 |
|---|---|---|---|
| 块设备层 | request_queue, bio, request | IO调度、合并、排序；向上提供通用块设备接口 | blk_init_queue, blk_fetch_request |
| MMC子系统 | mmc_host, mmc_card, mmc_command | 协议解析（MMC/SD/SDIO）、命令发送、卡状态管理 | mmc_wait_for_cmd, mmc_start_request |
| 设备模型 | bus_type, device, driver | 设备枚举、驱动匹配、电源管理、属性文件 | bus_add_device, driver_register |
| 主机控制器驱动 | sdhci_host, mmc_host_ops | 寄存器操作、DMA传输、中断处理、时钟管理 | sdhci_request, sdhci_irq |
数据流路径为：应用层read/write → VFS → 文件系统 → 块设备层（生成bio） → IO调度器（合并/排序） → mmc_blk驱动 → mmc子系统（封装为CMD） → 主机控制器驱动（写寄存器） → 硬件。控制流路径则不同：设备插入/上电时，主机控制器驱动通过设备模型注册mmc_host，MMC子系统扫描总线，创建mmc_card或sdio_func设备，再通过bus_type匹配对应驱动。
3.2 判断方法：如何定位驱动开发中的层次归属
在实际开发中，一个常见的困惑是：当出现问题时，应该修改哪一层？以下是基于现象判断层次归属的实用方法：
- 现象：应用层读写返回EIO，但dmesg无MMC错误 → 问题可能在块设备层或文件系统层，检查IO调度器配置、块设备容量、分区表。
- 现象：dmesg出现“mmc0: Timeout waiting for hardware interrupt” → 问题在主机控制器驱动层，检查寄存器配置、时钟频率、DMA描述符。
- 现象：设备无法枚举，/sys/bus/mmc/devices/为空 → 问题在设备模型或MMC子系统初始化阶段，检查mmc_host注册、卡检测机制（GPIO中断或轮询）。
- 现象：SDIO WiFi能枚举但无法收发数据 → 问题在SDIO协议层或具体功能驱动，检查sdio_func的IRQ注册、FBR（Function Base Register）配置。
mmc-utils 工具（如 mmc extcsd read）和 cat /sys/kernel/debug/mmc0/ios 查看当前总线状态（时钟、电压、总线宽度）。这能快速区分是协议层问题还是硬件层问题。
3.3 案例拆解：eMMC设备无法识别为块设备的完整排查
某嵌入式平台（i.MX8M Mini + eMMC 5.1）在Linux 5.10内核下，eMMC无法在/dev/下生成mmcblk0节点。以下是完整排查过程：
初始现象：系统启动后，ls /dev/mmcblk*无输出，dmesg | grep mmc显示“mmc0: new high speed SDIO card at address 0001”，但未出现eMMC相关日志。
关键输入数据：
# dmesg | grep -i mmc
[ 2.345] mmc0: SDHCI controller on 30b40000.mmc [30b40000.mmc] using ADMA
[ 2.352] mmc0: new high speed SDIO card at address 0001
[ 2.358] mmc0: SDIO IRQ enabled, func0: 0001, func1: 0001
# cat /sys/bus/mmc/devices/mmc0:0001/type
SDIO
分析判断过程：系统将mmc0识别为SDIO卡而非eMMC。检查设备树，发现eMMC连接在&sdhc1节点，而SDIO WiFi连接在&sdhc2。但dmesg只显示了mmc0（对应sdhc1）被识别为SDIO，说明设备树中sdhc1的bus-width或non-removable属性配置错误，导致MMC子系统误判卡类型。
实际操作步骤：
- 检查设备树：
&sdhc1 { bus-width = <8>; non-removable; status = "okay"; };发现缺少mmc-hs200-1_8v属性，但这不是关键。 - 进一步检查：发现
sdhc1节点被错误地设置了sdio标志（sdio = <1>），这导致MMC子系统强制将卡类型识别为SDIO。 - 移除该标志，重新编译设备树并烧录。
结果对比：重启后，dmesg显示“mmc0: new HS200 MMC card at address 0001”，/dev/mmcblk0正常生成，读写测试通过。
风险与代价：修改设备树需重新编译并烧录，若bootloader未正确加载新DTB可能导致启动失败。复盘经验：设备树中的卡类型标志（sdio/mmc/sd）是MMC子系统判断设备类型的首要依据，务必与硬件实际连接一致。
3.4 常见误区与总结复盘
以下是本章节的核心总结：
- 层次边界必须清晰：块设备层只处理逻辑块，不关心MMC协议；MMC子系统只处理命令/响应，不关心块合并；主机控制器驱动只操作寄存器，不关心卡类型。
- 设备模型是粘合剂：mmc_bus_type负责匹配mmc_card与mmc_driver，sdio_bus_type负责匹配sdio_func与sdio_driver。驱动开发的核心工作之一就是正确注册bus、device、driver并实现match函数。
- 调试入口：优先使用sysfs（/sys/bus/mmc/devices/）、debugfs（/sys/kernel/debug/mmc0/）和mmc-utils，而非直接加printk。
- 性能瓶颈：块设备层的IO调度器（如mq-deadline）与MMC子系统的命令队列（Command Queue）协同工作，若配置不当（如调度器与硬件队列不匹配），会导致吞吐量下降50%以上。