Linux 内核 USB 子系统基础架构与 USB 2.0 原理

一、背景介绍

USB（Universal Serial Bus）是现代嵌入式系统和移动设备中最为普遍的总线协议之一。对于 Android 系统的软件工程师而言，无论是做驱动开发、HAL 层适配、框架层功能扩展，还是在现场对 ADB 无法连接、MTP 传输失败、充电异常等问题进行故障分析，都绕不开对 USB 软件栈的理解。

Android 的 USB 支持并非从零构建，而是建立在 Linux 内核原生 USB 子系统之上，并在 HAL 层、Framework 层、应用层分别做了大量的封装和扩展。理解整个 USB 软件栈，需要从最底层的 Linux USB Core 开始，逐层向上拆解。

本系列文章共规划六篇，本篇（第一篇）聚焦于 Linux 内核 USB 子系统的基础架构，以 USB 2.0 为基准，厘清内核态的分层模型、核心数据结构、控制流与数据流，为后续理解 USB 3.x 演进和 Android 扩展打下基础。

本篇的核心问题：
- Linux 内核 USB 子系统由哪些层次构成？
- USB 2.0 下，Host 模式的请求是如何从驱动层流向硬件的？
- 核心数据结构之间是什么关系？
- 系统运行时可以从哪些调试节点获取 USB 状态信息？

二、知识边界说明

三、Linux USB 子系统整体分层架构

Linux 内核将 USB 支持划分为清晰的垂直层次，从上到下依次是：USB 设备驱动层 → USB Core → HCD（Host Controller Driver）→ USB 硬件控制器 → PHY。

每一层都有明确的职责边界，层与层之间通过标准接口通信，这使得新增一种 USB 设备驱动或适配一块新的 USB 控制器芯片，都只需在对应层实现标准接口，而无需修改其他层。

3.1 各层职责

USB 设备驱动层（Class/Function Driver）
这一层是面向具体 USB 设备功能的驱动，例如 USB 键盘驱动（usbhid）、USB 存储驱动（usb-storage）、USB 网卡驱动（cdc_ether）等。这些驱动通过 USB Core 提供的 API 注册自己关心的设备（通过 usb_device_id 表声明匹配规则），并使用 URB（USB Request Block）向 Core 提交 I/O 请求。设备驱动层与硬件完全解耦，它不知道也不关心底层用的是 EHCI 还是 XHCI 控制器。

USB Core
USB Core 是整个子系统的中枢，承担以下职责：
- 设备枚举：在设备插入时，负责读取设备描述符、配置描述符、接口描述符，完成设备识别；
- 驱动匹配：将枚举到的设备/接口与已注册的设备驱动进行匹配绑定；
- URB 管理：接收来自设备驱动的 URB，路由给对应的 HCD；
- 电源管理：协调 USB 设备的挂起/唤醒（USB autosuspend）；
- sysfs/debugfs 节点管理：向用户空间暴露设备信息。

HCD（Host Controller Driver）
HCD 是连接 USB Core 与具体硬件控制器的桥梁。不同的 USB 版本对应不同的 HCD 实现：
- USB 1.1：UHCI（Intel 风格）、OHCI（非 Intel 风格）
- USB 2.0：EHCI（Enhanced Host Controller Interface）
- USB 3.x：XHCI（eXtensible Host Controller Interface，向下兼容 2.0）

HCD 负责将 URB 翻译成硬件控制器能理解的传输描述符（TD/TRB），并驱动 DMA 完成实际的数据搬移。

USB 硬件控制器 + PHY
硬件控制器负责执行协议层的帧调度、令牌包发送/接收、CRC 校验等。PHY（Physical Layer）芯片负责信号的模拟收发，将数字信号转换为 USB 差分信号（D+/D-），或在 USB 3.x 下转换为 SuperSpeed 信号对（SSTX/SSRX）。

四、USB 2.0 协议要点与内核映射

4.1 USB 2.0 传输速度与模式

USB 2.0 定义了三种速率：
- LS（Low Speed）：1.5 Mbps，用于 HID 设备（键盘、鼠标）
- FS（Full Speed）：12 Mbps，用于通用设备
- HS（High Speed）：480 Mbps，USB 2.0 的主要卖点

在 Linux 内核中，usb_device 结构体的 speed 字段（类型为 enum usb_device_speed）记录了设备协商后的实际速率，枚举值包括 USB_SPEED_LOW、USB_SPEED_FULL、USB_SPEED_HIGH 等。

4.2 USB 描述符体系

USB 协议使用层次化描述符来描述设备的能力，这是枚举过程的核心。理解描述符层次是理解枚举流程、驱动匹配逻辑的前提。

描述符从外到内依次嵌套：

• 设备描述符（Device Descriptor）
  ：一个设备只有一个，包含 VID（厂商 ID）、PID（产品 ID）、USB 版本号、设备类/子类/协议码。
• 配置描述符（Configuration Descriptor）
  ：一个设备可以有多个配置，每次只能激活一个。Android 设备通常只有一个配置。
• 接口描述符（Interface Descriptor）
  ：一个配置中可有多个接口，每个接口代表一个独立的功能。例如，一个 USB 耳机设备可能有音频接口和 HID（音量控制）接口。
• 端点描述符（Endpoint Descriptor）
  ：每个接口有若干端点，端点是数据传输的实际通道。端点 0（EP0）是控制端点，始终存在，其他端点由驱动申请使用。

在 Linux 内核中，这些描述符分别对应：usb_device_descriptor、usb_config_descriptor、usb_interface_descriptor、usb_endpoint_descriptor。它们最终被组织在 usb_device 和 usb_interface 数据结构中。

4.3 四种传输类型

USB 2.0 定义了四种传输类型，面向不同特性的数据：

在 Linux 内核中，URB 的 transfer_flags 和 pipe 字段共同决定了传输类型和方向。usb_fill_bulk_urb()、usb_fill_int_urb()、usb_fill_control_urb() 是常用的 URB 初始化辅助函数。

五、URB 机制：USB 请求的核心载体

5.1 URB 是什么

URB（USB Request Block）是 Linux USB Core 中用于描述一次 USB 传输请求的数据结构，类似于块设备栈中的 bio，或网络栈中的 skb。所有的数据传输（读写）都必须封装成 URB 提交给 USB Core，由 Core 再转交给 HCD 执行。

5.2 URB 生命周期与控制流

URB 的生命周期是 USB 驱动开发中最重要的概念之一。一个典型的 URB 从分配到完成，需要经过以下阶段：

第一阶段：分配
驱动调用 usb_alloc_urb(iso_packets, GFP_KERNEL) 分配 URB。对于 Isochronous 传输，iso_packets 指定包数量；对于其他类型，传 0。

第二阶段：初始化
根据传输类型，使用对应的辅助函数填充 URB 字段：
- usb_fill_bulk_urb() → Bulk 传输
- usb_fill_int_urb() → Interrupt 传输
- usb_fill_control_urb() → Control 传输

第三阶段：提交
驱动调用 usb_submit_urb(urb, GFP_ATOMIC/GFP_KERNEL) 将 URB 提交给 USB Core。此调用是异步的，函数立即返回，不等待传输完成。USB Core 将 URB 排入 HCD 的传输队列。

第四阶段：硬件执行
HCD 将 URB 翻译成硬件传输描述符（EHCI 下是 QH/TD 链表），通过 DMA 搬运数据，并在完成后触发中断。

第五阶段：完成回调
HCD 中断处理程序在完成传输后，调用 usb_hcd_giveback_urb()，最终触发 URB 中指定的 complete 回调函数。该回调运行在中断上下文（或 tasklet 上下文），因此回调中不能睡眠，通常只做简单处理后唤醒等待线程或提交下一个 URB。

第六阶段：释放
传输完成且 URB 不再使用时，调用 usb_free_urb() 释放。

六、设备枚举流程详解

USB 设备枚举是 USB Core 最核心的工作之一。当一个 USB 设备插入 Hub 端口时，Hub 检测到连接事件（D+ 或 D- 被上拉），通过 Interrupt 端点上报给主机，主机的 Hub 驱动触发枚举流程。

枚举的完整步骤如下：

步骤 1：复位
Hub 驱动对设备所在端口发出 USB Reset 信号（SE0 状态维持至少 10ms）。复位后，设备进入 Default 状态，此时设备地址为 0，只能响应地址为 0 的控制传输。

步骤 2：获取部分设备描述符
主机向地址 0 的 EP0 发送 GET_DESCRIPTOR 控制请求，先只读取设备描述符的前 8 字节，目的是获取 bMaxPacketSize0（EP0 最大包长，低速设备为 8，全速设备为 8/16/32/64，高速设备固定为 64）。

步骤 3：分配地址
主机向设备发送 SET_ADDRESS 请求，为设备分配一个 1～127 范围内唯一的总线地址。之后所有通信使用该新地址。

步骤 4：读取完整描述符
依次读取：完整的设备描述符 → 配置描述符（含所有接口和端点描述符）→ 字符串描述符（厂商名、产品名、序列号）。

步骤 5：选择配置
主机发送 SET_CONFIGURATION 请求激活配置，设备进入 Configured 状态，端点开始正常工作。

步骤 6：驱动匹配与绑定
USB Core 根据读取到的 VID/PID 和接口类码，在已注册的驱动中查找匹配项（遍历 usb_device_id 表），找到后调用驱动的 probe() 函数完成绑定。

七、运行时调试信息与观测手段

这一部分是工程实践中故障分析的重要基础。Linux 内核为 USB 子系统提供了丰富的调试接口。

7.1 sysfs 节点

USB 设备插入后，USB Core 会在 sysfs 中创建对应节点，路径格式如下：

/sys/bus/usb/devices/
  ├── 1-0:1.0/          # Root Hub 的接口
  ├── 1-1/              # Bus 1, Port 1 的设备
  │   ├── idVendor      # VID（十六进制）
  │   ├── idProduct     # PID（十六进制）
  │   ├── manufacturer  # 厂商字符串
  │   ├── product       # 产品字符串
  │   ├── serial        # 序列号
  │   ├── speed         # 实际速率（如 "480"）
  │   ├── bConfigurationValue   # 当前激活的配置
  │   └── power/        # 电源管理相关

通过读取这些节点，可以快速确认设备是否被正确枚举、协商速率是否符合预期（例如期望 480M 但实际是 12M，说明 HS 协商失败，可能是 PHY 或线材问题）。

7.2 /sys/kernel/debug/usb/

需要挂载 debugfs（mount -t debugfs none /sys/kernel/debug）后访问。

7.3 usbmon：USB 数据包抓包 

usbmon是 Linux 内核内置的 USB 数据包捕获模块，类似网络栈中的 tcpdump。使用方法：

# 加载模块（部分发行版默认不加载）
modprobe usbmon

# 查看 Bus 1 的流量（文本格式）
cat /sys/kernel/debug/usb/usbmon/1u

# 配合 tcpdump 抓 pcap 格式，用 Wireshark 分析
tcpdump -i usbmon1 -w usb_capture.pcap

通过 usbmon 抓包，可以看到每一个 URB 的提交和完成情况，包括传输类型、端点、数据长度、状态码，对于分析枚举失败、传输错误等问题极为有效。

7.4 Android 特有观测手段

在 Android 系统中（需要 adb shell 权限）：

# 查看 USB 设备列表（需 root 或特定权限）
adb shell cat /sys/kernel/debug/usb/devices

# 查看 USB 相关的内核日志
adb shell dmesg | grep -i usb

# 查看 Android USB 配置状态
adb shell getprop sys.usb.state
adb shell getprop sys.usb.config

# 查看 USB gadget 配置（Device 模式，下篇详述）
adb shell ls /config/usb_gadget/g1/

八、EHCI（USB 2.0）内部数据结构简析

EHCI（Enhanced Host Controller Interface）是 USB 2.0 的标准主机控制器接口规范，定义了主机控制器的寄存器布局和内存数据结构。理解 EHCI 数据结构，对于分析 HCD 层的 bug 或性能问题非常有帮助。

EHCI 使用以下核心数据结构来管理传输：

Periodic Frame List（周期帧列表）
一个包含 1024 个指针的数组，每个指针对应一个微帧（125μs），用于安排 Interrupt 和 Isochronous 传输。控制器每 125μs 扫描一次对应指针，执行调度的传输。

Queue Head（QH）
队列头，代表一个端点的传输队列。QH 中存储了端点的配置信息（设备地址、端点号、最大包长、速率等），并链接一个 Transfer Descriptor（TD）链表。Bulk 和 Control 传输通过 QH 异步调度。

Transfer Descriptor（TD）
传输描述符，描述一次具体的 USB 包传输。每个 TD 可以传输最多 20KB 的数据（通过 4 个 Buffer 指针，每个 4KB），并记录传输状态（Active/Halted/完成）。

九、本篇小结与知识图谱

本篇覆盖了 Linux USB 子系统的基础骨架，以下是本篇知识点的核心结论：

1. 分层架构：Linux USB 子系统从上到下分为 设备驱动层、USB Core、HCD、硬件 四层，层间通过标准接口解耦，驱动开发只需关注自身所在层。

2. 描述符体系：USB 设备通过 设备→配置→接口→端点 的层次描述符向主机声明自身能力，驱动匹配基于 VID/PID 或接口类码。

3. URB 机制：所有 USB I/O 均通过 URB 承载，URB 的生命周期为 分配→初始化→提交→硬件执行→完成回调→释放，完成回调在中断上下文执行。

4. 枚举流程：枚举是 USB Core 的核心职责，经过 复位→获取描述符→分配地址→选择配置→驱动匹配 等步骤完成设备就绪。

5. EHCI 数据结构：EHCI 通过 QH+TD 链表组织 Bulk/Control 传输，通过 Periodic Frame List 组织 Interrupt/Iso 传输。

6. 调试手段：sysfs 节点用于查看设备配置信息，usbmon 用于抓包分析，debugfs 节点用于查看控制器内部状态，Android 上可通过 adb shell + getprop / dmesg 快速定位问题。