📚 课程目录第3章 Linux USB子系统

3、Linux USB子系统：USB核心框架、usb_driver结构、probe/disconnect回调、urb（USB请求块）机制

USB摄像头的驱动开发，本质上是在Linux USB子系统的框架内，完成对USB设备（摄像头）的枚举、配置、通信与数据流控制。理解USB核心框架是开发UVC（USB Video Class）驱动或自定义扩展的前提。本章将深入剖析Linux USB子系统的分层架构、核心数据结构usb_driver、设备生命周期中的probe/disconnect回调机制，以及异步通信的核心——URB（USB Request Block）。只有透彻理解这些底层机制，才能正确编写出稳定、高效的摄像头驱动。

上图展示了Linux USB子系统的整体分层架构。从用户空间的V4L2设备节点，到内核空间的V4L2子系统、UVC驱动、USB核心框架，再到硬件层的USB控制器与物理设备，每一层都有明确的职责边界。UVC驱动作为中间层，向上通过V4L2接口向用户空间提供标准视频设备接口，向下通过USB核心框架与硬件通信。理解这个分层模型，是掌握后续所有驱动开发技巧的基础。

3.1 USB核心框架：分层架构与职责划分

核心原理：USB子系统的三层模型

Linux USB子系统采用严格的分层设计，主要分为三个层次：USB核心（USB Core）、主机控制器驱动（HCD）和设备驱动（Device Driver）。USB核心是整个子系统的中枢，负责管理USB总线、设备枚举、配置选择、带宽分配以及URB的调度。HCD则直接与硬件控制器（如DWC2、DWC3、EHCI、XHCI）交互，屏蔽了不同控制器之间的硬件差异。设备驱动（如UVC驱动）则专注于特定类型设备的逻辑控制。

对于摄像头驱动开发者而言，主要工作集中在设备驱动层，但必须理解USB核心提供的服务接口。USB核心通过usb_device结构体抽象一个物理USB设备，通过usb_interface抽象设备上的一个功能接口。UVC摄像头通常只有一个接口（接口0），但复合设备可能包含多个接口，每个接口对应一个独立的驱动。

关键数据结构关系：

usb_device：代表整个USB设备，包含设备描述符、配置描述符、端点信息等。
usb_interface：代表设备上的一个接口，是驱动绑定的基本单位。
usb_host_endpoint：描述接口下的端点，包括端点地址、传输类型、最大包大小等。

判断方法：如何确定驱动绑定的接口

在编写UVC驱动时，需要明确驱动绑定到哪个接口。通过usb_interface_descriptor中的bInterfaceClass字段判断接口类型。UVC设备的接口类为USB_CLASS_VIDEO（0x0E），接口子类包括视频控制（VC，0x01）和视频流（VS，0x02）。驱动通过usb_driver结构中的id_table指定匹配规则，USB核心在设备枚举时自动完成匹配。

// UVC驱动中id_table的典型定义
static const struct usb_device_id uvc_ids[] = {
    { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 1, 0) },  // Video Control
    { USB_INTERFACE_INFO(USB_CLASS_VIDEO, 2, 0) },  // Video Streaming
    {}
};
MODULE_DEVICE_TABLE(usb, uvc_ids);

案例拆解：USB摄像头枚举过程

当USB摄像头插入主机时，USB核心执行以下枚举流程：

设备复位与地址分配：USB核心检测到设备插入，发送复位信号，分配地址0，读取设备描述符。
配置选择：读取配置描述符，选择第一个配置（通常为默认配置）。
接口发现：解析配置描述符中的接口信息，创建usb_interface实例。
驱动匹配：遍历已注册的usb_driver，调用usb_match_id()进行匹配。
probe调用：匹配成功后，USB核心调用驱动的probe回调，传入usb_interface指针。

在probe中，UVC驱动会进一步解析视频控制接口中的终端（Terminal）和单元（Unit）描述符，建立内部的UVC控制结构，并注册V4L2设备。

常见误区与总结

误区1：认为usb_device是驱动绑定的目标。实际上，驱动绑定的是usb_interface，而非usb_device。一个设备可以有多个接口，每个接口可以绑定不同的驱动。

误区2：忽略接口描述符中的bAlternateSetting。UVC视频流接口通常有多个备用设置（Alternate Setting），用于调整带宽占用。驱动必须正确选择备用设置，否则无法获取视频数据。

3.2 usb_driver结构：驱动注册与设备匹配

核心原理：usb_driver结构体解析

usb_driver是USB设备驱动的核心结构体，定义在include/linux/usb.h中。它继承了device_driver的通用属性，并增加了USB特有的字段。主要成员包括：

字段名	类型	作用说明
`name`	const char *	驱动名称，显示在sysfs中
`probe`	int ()(struct usb_interface )	设备匹配成功后的初始化回调
`disconnect`	void ()(struct usb_interface )	设备拔出或驱动卸载时的清理回调
`id_table`	const struct usb_device_id *	设备匹配规则表
`suspend`/`resume`	int ()(struct usb_interface , pm_message_t)	电源管理回调，用于挂起/恢复

驱动注册通过usb_register()宏完成，内部调用usb_register_driver()。注销则使用usb_deregister()。

操作流程：probe回调的标准实现步骤

在UVC驱动中，probe回调通常执行以下操作：

接口验证：检查接口类/子类是否符合预期。
端点扫描：遍历接口的端点列表，找到批量输入端点（用于视频流）和中断端点（用于事件通知）。
内存分配：为驱动私有数据结构分配内存（如uvc_device）。
控制初始化：解析UVC描述符，建立控制单元映射。
V4L2注册：初始化并注册V4L2设备，设置ioctl回调。
URB准备：分配并初始化用于视频流传输的URB。

static int uvc_probe(struct usb_interface *intf,
                     const struct usb_device_id *id)
{
    struct usb_device *udev = interface_to_usbdev(intf);
    struct uvc_device *dev;
    int ret;

    // 1. 分配私有数据结构
    dev = kzalloc(sizeof(*dev), GFP_KERNEL);
    if (!dev)
        return -ENOMEM;

    // 2. 初始化互斥锁、工作队列等
    mutex_init(&dev->lock);
    INIT_WORK(&dev->irq_work, uvc_irq_work);

    // 3. 解析UVC描述符
    ret = uvc_parse_streaming_interface(dev, intf);
    if (ret < 0) {
        kfree(dev);
        return ret;
    }

    // 4. 注册V4L2设备
    ret = uvc_register_video_device(dev);
    if (ret < 0) {
        uvc_unregister_video_device(dev);
        kfree(dev);
        return ret;
    }

    // 5. 保存驱动数据到接口
    usb_set_intfdata(intf, dev);
    return 0;
}

案例拆解：多接口UVC设备的probe处理

某些UVC摄像头将视频控制和视频流分为两个接口。此时，id_table会匹配两个接口，probe会被调用两次。驱动需要区分当前probe的是哪个接口：

static int uvc_probe(struct usb_interface *intf,
                     const struct usb_device_id *id)
{
    struct usb_host_interface *alts = intf->cur_altsetting;
    
    if (alts->desc.bInterfaceSubClass == 1) {
        // Video Control 接口
        return uvc_probe_control(intf);
    } else if (alts->desc.bInterfaceSubClass == 2) {
        // Video Streaming 接口
        return uvc_probe_streaming(intf);
    }
    return -ENODEV;
}

这种设计使得控制路径和数据路径分离，便于独立管理。控制接口负责处理摄像头属性设置（如亮度、对比度），数据接口负责传输视频帧。

常见误区与总结

经验提醒：在probe中不要执行耗时操作（如固件下载），否则会阻塞USB核心的枚举线程。如果必须执行耗时操作，应使用工作队列或异步机制。

风险提示：disconnect回调可能在URB传输过程中被调用，必须确保在释放URB之前取消所有未完成的传输，否则会导致内核崩溃。

3.3 probe/disconnect回调：设备生命周期管理

核心原理：设备热插拔与生命周期状态机

USB设备支持热插拔，因此驱动的probe和disconnect回调是设备生命周期的关键节点。设备插入时，USB核心调用probe；设备拔出或驱动卸载时，调用disconnect。这两个回调必须成对实现，确保资源正确分配和释放。

设备生命周期状态包括：已连接（Attached）、已枚举（Enumerated）、已配置（Configured）、已绑定（Bound）和已断开（Disconnected）。驱动主要在“已绑定”状态下工作，负责处理I/O请求。

操作流程：disconnect回调的标准清理步骤

停止数据流：停止所有正在进行的URB传输，等待回调完成。
注销V4L2设备：调用video_unregister_device()，确保用户空间不再能访问设备节点。
释放URB：使用usb_free_urb()释放所有分配的URB。
释放缓冲区：释放视频帧缓冲区（videobuf2队列）。
释放私有数据：调用kfree()释放驱动私有结构体。

static void uvc_disconnect(struct usb_interface *intf)
{
    struct uvc_device *dev = usb_get_intfdata(intf);

    // 1. 标记设备为断开状态
    dev->disconnected = 1;

    // 2. 注销V4L2设备
    video_unregister_device(dev->video);

    // 3. 取消所有URB
    uvc_kill_urbs(dev);

    // 4. 释放URB和缓冲区
    uvc_free_urbs(dev);
    uvc_free_buffers(dev);

    // 5. 释放私有数据
    usb_set_intfdata(intf, NULL);
    kfree(dev);
}

案例拆解：异常拔出时的资源竞争处理

考虑一个实际场景：用户正在使用摄像头进行视频通话，突然拔掉USB线。此时，内核可能正在处理一个URB回调。如果disconnect直接释放URB，而URB回调还在执行，就会导致悬空指针访问。

解决方案是使用引用计数或互斥锁保护。UVC驱动采用dev->disconnected标志位，在URB回调中检查该标志，如果设备已断开则直接返回，不进行后续处理。同时，在disconnect中先设置标志，再注销设备，最后释放资源，确保不会出现竞态条件。

关键点：在disconnect中，不能直接调用kfree(dev)，因为可能还有其他线程持有dev的引用。应使用kref_put()或延迟释放机制（如工作队列）。

常见误区与总结

误区：在probe中注册中断处理函数，但在disconnect中忘记注销。
误区：假设disconnect一定在进程上下文调用。实际上，它可能在中断上下文或软中断上下文被调用，因此不能使用可能睡眠的锁。
总结：probe/disconnect是驱动与设备生命周期的绑定点，必须保证资源分配与释放的对称性。

3.4 URB机制：USB请求块与异步I/O

核心原理：URB的结构与传输类型

URB（USB Request Block）是Linux USB子系统用于描述一次USB传输的核心数据结构。它类似于网络子系统的sk_buff，封装了传输的目标端点、数据缓冲区、传输长度、回调函数等信息。URB支持四种传输类型：

传输类型	典型用途	特点
控制传输（Control）	设备配置、命令发送	双向、可靠性高、数据量小
批量传输（Bulk）	视频流数据、大块数据	单向、保证传输、无带宽保证
中断传输（Interrupt）	事件通知、状态查询	低延迟、有带宽保证
等时传输（Isochronous）	音频流、实时视频	带宽保证、无重传、允许丢包

UVC摄像头通常使用批量传输（USB 2.0）或等时传输（USB 1.1）来传输视频流。批量传输适合高带宽、非实时的场景，而等时传输适合对延迟敏感的场景。

操作流程：URB的分配、填充与提交

// 1. 分配URB
struct urb *urb = usb_alloc_urb(0, GFP_KERNEL);
if (!urb)
    return -ENOMEM;

// 2. 填充URB（以批量传输为例）
usb_fill_bulk_urb(urb, udev,
                  usb_rcvbulkpipe(udev, endpoint_addr),
                  buffer, buffer_size,
                  uvc_video_complete,  // 回调函数
                  dev);                // 上下文数据

// 3. 提交URB（异步）
ret = usb_submit_urb(urb, GFP_KERNEL);
if (ret) {
    usb_free_urb(urb);
    return ret;
}

URB回调函数在传输完成时被调用，无论成功还是失败。回调函数运行在中断上下文，因此不能执行可能睡眠的操作。回调中通常检查urb->status判断传输结果，并决定是否重新提交URB以持续接收数据。

案例拆解：UVC视频流URB的循环提交

UVC驱动在启动视频流时，会分配多个URB（通常4-8个）并同时提交，以提高吞吐量。每个URB的回调函数中，将数据复制到videobuf2缓冲区，然后重新提交URB，形成持续的数据流。

static void uvc_video_complete(struct urb *urb)
{
    struct uvc_streaming *stream = urb->context;
    int ret;

    if (urb->status == 0) {
        // 将数据复制到V4L2缓冲区
        uvc_video_copy_data(stream, urb->transfer_buffer,
                            urb->actual_length);
    }

    // 重新提交URB
    ret = usb_submit_urb(urb, GFP_ATOMIC);
    if (ret < 0)
        dev_err(&urb->dev->dev, "URB re-submit failed: %d\n", ret);
}

这种设计保证了视频数据的连续传输。需要注意的是，GFP_ATOMIC标志用于中断上下文的内存分配，不能使用GFP_KERNEL。

常见误区与总结

经验提醒：URB的transfer_buffer必须使用usb_alloc_coherent()或kmalloc()分配，不能使用栈内存或静态数组，因为DMA操作需要物理连续内存。

风险提示：在URB回调中重新提交URB时，必须检查设备是否已断开（通过dev->disconnected标志），否则会导致空指针访问。

URB机制是USB驱动开发的核心，掌握其生命周期管理（分配→填充→提交→回调→释放）是编写稳定驱动的关键。UVC驱动通过精心设计的URB池，实现了高效、可靠的视频流传输。