3. Linux 内核 USB 子系统：usbcore、usb_storage、uvcvideo 驱动框架
好，咱们今天聊聊 Linux 内核里的 USB 子系统。这东西，说白了就是摄像头和主机之间的“高速公路”。你摄像头插上去，数据怎么走？谁来管？出了问题找谁？全看这套框架。
我个人习惯，把 USB 子系统分成三层来看。这样思路特别清楚。你想想看，从最底层的硬件，到最上层的应用，中间隔了好几层“翻译官”。
3.1 三层架构：从硬件到应用
这三层分别是：
- USB 主机控制器驱动（HCD）：最底层，直接跟硬件寄存器打交道。比如你的 xHCI、EHCI 控制器。
- USB 核心（usbcore）：中间层，负责协议解析、设备枚举、总线管理。这是“交通枢纽”。
- USB 设备驱动：最上层，比如咱们今天要讲的
uvcvideo和usb_storage。它们知道怎么跟具体的设备类型对话。
我画了张图，你看一眼就明白了。
嗯，这里要注意。你写驱动，大部分时间是在最上面那层。但如果不理解中间 usbcore 在干什么，出了问题你根本不知道从哪查起。
3.2 usbcore：USB 子系统的心脏
usbcore 是内核里最核心的 USB 代码。它不直接跟硬件说话，但它管理着所有 USB 设备的“户口”。
它的主要工作，我总结了一下：
| 功能模块 | 职责描述 |
|---|---|
| 设备枚举 | 检测设备插入，读取描述符，分配地址 |
| 总线管理 | 管理 USB 总线状态、电源管理、带宽分配 |
| 驱动匹配 | 根据 VID/PID 或接口类代码，找到合适的驱动 |
| URB 传输 | 提供统一的 URB（USB Request Block）接口 |
| 协议解析 | 处理标准请求（如 Get Descriptor、Set Configuration） |
URB 这个东西，你得记住。它是 USB 子系统里最核心的数据结构。所有数据交换，都是通过 URB 来完成的。我刚开始学的时候，总觉得 URB 很抽象。后来调试一个 UVC 摄像头，发现图像数据断断续续，一查，原来是 URB 的缓冲区大小没设对。从那以后，我对 URB 就特别敏感。
3.3 usb_storage：大容量存储驱动
这个驱动，咱们做摄像头的人，其实不太直接用它。但为什么我要讲？因为它的框架非常经典，是理解 USB 设备驱动的“样板房”。
usb_storage 驱动，处理的是 USB 大容量存储设备，比如 U 盘、移动硬盘。它的工作流程是这样的：
- 探测（probe）：当
usbcore匹配到设备时，调用usb_stor_probe()。 - 初始化：发送一系列 SCSI 命令，比如 INQUIRY、READ CAPACITY，了解设备信息。
- 注册：向 SCSI 子系统注册一个虚拟的磁盘设备（如
/dev/sda）。 - 数据传输：通过 Bulk-Only 传输协议，用 URB 搬运数据。
你看，它把 USB 协议转换成了 SCSI 协议。这种“协议转换”的思路，在嵌入式系统里特别常见。UVC 摄像头也是类似的思路，只不过它转换的是视频流协议。
dmesg 里出现了 usb_storage 相关的错误，别慌。那通常不是摄像头的问题，而是 USB 总线层面出了状况。比如供电不足，或者 USB 控制器挂了。先查硬件，再查软件。
3.4 uvcvideo：摄像头驱动的“扛把子”
终于到咱们的主角了。uvcvideo 驱动，是 Linux 内核里处理 USB 视频类（UVC）设备的官方驱动。市面上绝大多数 USB 摄像头，都走这个驱动。
它的框架，我拆成几个关键部分：
- UVC 设备结构体：
struct uvc_device，管理整个设备的状态。 - 视频流接口：
struct uvc_streaming，负责处理视频数据流。 - V4L2 接口：向用户空间暴露标准的 Video4Linux2 接口。
- 控制接口：处理摄像头控制，比如亮度、对比度、自动对焦。
驱动加载后，它会做这么几件事：
- 枚举接口：找到视频控制接口（VC）和视频流接口（VS）。
- 解析描述符：读取摄像头的分辨率、帧率、格式等信息。
- 注册 V4L2 设备：生成
/dev/video0节点。 - 启动流传输：通过 ISOCHRONOUS 或 BULK 传输，把图像数据送上来。
这里有个坑，我踩过。有些摄像头，它的描述符写得不太规范。比如它声称支持 1920x1080 @ 30fps，但实际硬件根本跑不动。这时候，uvcvideo 驱动会尝试协商，如果协商失败，它可能会回退到低分辨率。我曾经遇到过一款工业摄像头，就是描述符写错了，导致在 Linux 下只能跑 640x480。后来我手动改了驱动的解析逻辑，才搞定。
uvcvideo 驱动的 probe() 函数必须快速返回。如果它卡住了，整个 USB 总线都会被拖慢。我建议你在 probe 里不要做太重的初始化，比如分配大块内存或者启动流传输。这些事，放到用户空间打开设备时再做。
3.5 驱动匹配与热插拔流程
咱们把整个流程串起来，看看摄像头插上去后，内核到底干了什么。
- 硬件检测：USB 主机控制器检测到电平变化，触发中断。
- usbcore 枚举：读取设备描述符，分配地址。
- 配置选择：读取配置描述符，选择默认配置。
- 接口发现：发现视频控制接口和视频流接口。
- 驱动匹配：
usbcore根据接口类代码（0x0E 视频类），匹配到uvcvideo驱动。 - probe 调用：
uvcvideo的probe()被调用，初始化设备。 - 设备注册：向 V4L2 框架注册
/dev/videoX节点。 - 用户空间通知：通过 udev 或 netlink 通知用户空间，有新设备了。
你看，从硬件到应用，每一步都有明确的分工。这就是 Linux 内核设计的精妙之处。
uvcvideo 驱动在移除时没有正确释放资源，下次插上同一个摄像头，可能会崩溃。我建议你在驱动里，对 disconnect() 函数做充分的测试。
3.6 小结
这一章，咱们把 USB 子系统的三层架构捋了一遍。从 usbcore 的“户口管理”，到 usb_storage 的“协议转换”，再到 uvcvideo 的“视频流处理”。每一层都有自己的职责，也都有自己的坑。
我个人觉得，理解这套框架，比背代码更重要。框架懂了，遇到问题你才知道该去查哪一层。比如摄像头不出图，你先看 dmesg 里有没有 uvcvideo 的 probe 信息。如果没有，那就是 usbcore 层或者硬件层的问题。如果有，那就查 V4L2 层或者应用层。