USB驱动程序编写.pdf

《USB驱动程序编写.pdf》由会员分享，可在线阅读，更多相关《USB驱动程序编写.pdf（35页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、324第十三章USB驱动程序通用串行总线（USB）是主机和外围设备之间的一种连接。USB最初是为了替代许多不同的低速总线（包括并行、串行和键盘连接）而设计的，它以单一类型的总线连接各种不同类型的设备（注1）。USB的发展已经超越了这些低速的连接方式，它现在可以支持几乎所有可以连接到 PC 上的设备。最新的 USB 规范修订增加了理论上高达 480 Mbps的高速连接。从拓扑上来看，一个USB子系统并不是以总线的方式来布置的；它是一棵由几个点对点的连接构建而成的树。这些连接是连接设备和集线器（hub）的四线电缆（地线、电源线和两根信号线），这和以太网双绞线类似。USB 主控制器（host con

2、troller）负责询问每一个 USB 设备是否有数据需要发送。因为这种拓扑布局的原因，一个 USB 设备在没有主控制器要求的情况下是不能发送数据的。这种配置便于搭建一个非常简易的即插即用类型的系统，藉此，设备可以由主机自动地配置。USB总线在技术层面上是非常简单的，因为它是一个单主方式的实现，在此方式下，主机轮询各种不同的外围设备。尽管存在这种内在的局限性，USB总线有一些吸引人的特性，例如设备具有要求一个固定的数据传输带宽的能力，以可靠地支持视频和音频I/O。USB另一个重要的特性是它只担当设备和主控制器之间通信通道的角色，对它所发送的数据没有任何特殊的内容和结构上的要求（注 2）。USB

3、协议规范定义了一套任何特定类型的设备都可以遵循的标准。如果一个设备遵循该标准，就不需要一个特殊的驱动程序。这些不同的特定类型称为类（class），包括存储注 1：本章部分内容基于 Linux 内核 USB 代码的内核文档，这些文档由内核的 USB 开发者编写，并且按照 GPL 条款发布。注 2：实际上，还是存在一些结构，但通常被降低为满足某几个预定义类之一的通信需求：例如，键盘不需要分配带宽，而某些摄像头需要。325USB 驱动程序设备、键盘、鼠标、游戏杆、网络设备和调制解调器。对于不符合这些类的其他类型的设备，需要针对特定的设备编写一个特定于供货商的驱动程序。视频设备和USB到串口转换设备是

4、一个很好的例子，对于它们没有已定义的标准，来自不同制造商的每一种不同的设备都需要对应的驱动程序。这些特性，加上设计上与生俱来的热插拔能力，使得 USB 成为一个便利和低成本的机制，它可以连接多个设备到计算机，而不需要关闭系统、打开机箱、拧螺丝钉和插拔电线。Linux内核支持两种主要类型的 USB 驱动程序：宿主（host）系统上的驱动程序和设备（device）上的驱动程序。从宿主的观点来看（一个普通的USB宿主是一个桌面计算机），宿主系统的USB驱动程序控制插入其中的USB设备，而USB设备的驱动程序控制该设备如何作为一个 USB 设备和主机通信。由于术语“USB 设备驱动程序”（USB de

5、vicedrivers）非常易于混淆，USB 开发者创建了术语“USB 器件驱动程序”（USB gadgetdrivers）来描述控制连接到计算机（不要忘了 Linux 还运行于很多小型嵌入式设备上）的 USB 设备的驱动程序。本章将详细介绍运行于桌面计算机上的USB 系统是如何运作的。USB 器件驱动程序此刻还未列入本书的内容范围。如图13-1所示，USB驱动程序存在于不同的内核子系统（块设备、网络设备、字符设备等等）和USB 硬件控制器之中。USB 核心为 USB 驱动程序提供了一个用于访问和控制USB 硬件的接口，而不必考虑系统当前存在的各种不同类型的 USB 硬件控制器。硬件用户USB

6、 主控制器USB 核心USB 设备驱动程序VFS层块设备层网络设备层字符设备层TTY层内核.图 13-1：USB 驱动程序概观第十三章326USB 设备基础USB 设备是一个非常复杂的东西，官方USB 文档（可由 http:/www.usb.org获取）中有详细的描述。幸运的是，Linux内核提供了一个称为 USB 核心（USB core）的子系统来处理大部分的复杂性。本章描述驱动程序和 USB 核心之间的接口。图 13-2展示了 USB设备的构成，包括配置、接口和端点，以及 USB 驱动程序如何绑定到 USB 接口上，而不是整个 USB 设备。DeviceConfigEndpointEndp

7、ointEndpointInterfaceEndpointEndpointEndpointInterfaceUSBdriverUSBdriver图 13-2：USB 设备概观端点USB通信最基本的形式是通过一个名为端点（endpoint）的东西。USB端点只能往一个方向传送数据，从主机到设备（称为输出端点）或者从设备到主机（称为输入端点）。端点可以看作是单向的管道。USB 端点有四种不同的类型，分别具有不同的传送数据的方式：控制控制端点用来控制对 USB 设备不同部分的访问。它们通常用于配置设备、获取设备信息、发送命令到设备，或者获取设备的状态报告。这些端点一般体积较小。每个 USB 设备都有

8、一个名为“端点 0”的控制端点，USB 核心使用该端点在插入时进行设备的配置。USB 协议保证这些传输始终有足够的保留带宽以传送数据到设备。327USB 驱动程序中断每当 USB 宿主要求设备传输数据时，中断端点就以一个固定的速率来传送少量的数据。这些端点是 USB 键盘和鼠标所使用的主要传输方式。它们通常还用于发送数据到 USB 设备以控制设备，不过一般不用来传输大量的数据。USB 协议保证这些传输始终有足够的保留带宽以传送数据。批量批量（bulk）端点传输大批量的数据。这些端点通常比中断端点大得多（它们可以一次持有更多的字符）。它们常见于需要确保没有数据丢失的传输的设备。USB协议不保证这

9、些传输始终可以在特定的时间内完成。如果总线上的空间不足以发送整个批量包，它将被分割为多个包进行传输。这些端点通常出现在打印机、存储设备和网络设备上。等时等时（isochronous）端点同样可以传送大批量的数据，但数据是否到达是没有保证的。这些端点用于可以应付数据丢失情况的设备，这类设备更注重于保持一个恒定的数据流。实时的数据收集（例如音频和视频设备）几乎毫无例外都使用这类端点。控制和批量端点用于异步的数据传输，只要驱动程序决定使用它们。中断和等时端点是周期性的。也就是说，这些端点被设置为在固定的时段连续地传输数据，基于此，USB核心为它们保留了相应的带宽。内核中使用 struct usb_h

10、ost_endpoint结构体来描述 USB 端点。该结构体在另一个名为 struct usb_endpoint_descriptor的结构体中包含了真正的端点信息。后一个结构体包含了所有的USB特定的数据，这些数据的格式是由设备自己定义的。该结构体中驱动程序需要关心的字段有：bEndpointAddress这是特定端点的 USB 地址。这个 8 位的值中还包含了端点的方向。该字段可以结合位掩码USB_DIR_OUT和 USB_DIR_IN来使用，以确定该端点的数据是传向设备还是主机。bmAttributes这是端点的类型。该值可以结合位掩码 USB_ENDPOINT_XFERTYPE_MAS

11、K来使用，以确定此端点的类型是 USB_ENDPOINT_XFER_ISOC、USB_ENDPOINT_XFER_BULK还是USB_ENDPOINT_XFER_INT。这些宏分别表示等时、批量和中断端点。wMaxPacketSize这是该端点一次可以处理的最大字节数。注意，驱动程序可以发送数量大于此值的第十三章328数据到端点，但是在实际传输到设备的时候，数据将被分割为wMaxPacketSize大小的块。对于高速设备，通过使用高位中一些额外的位，该字段可以用来支持端点的高带宽模式。请参考 USB 规范以了解具体实现的详情。bInterval如果端点是中断类型，该值是端点的间隔设置 也就是说

12、，端点的中断请求间隔时间。该值以毫秒为单位。该结构体的字段并没有采用“传统的”Linux 内核命名方案。这是因为这些字段直接对应于USB规范中的字段名字。USB内核程序员认为使用规范指定的名字比使用Linux程序员熟悉的变量命名方式更加重要，因为这样便于规范的阅读。接口USB 端点被捆绑为接口。USB 接口只处理一种 USB 逻辑连接，例如鼠标、键盘或者音频流。一些USB 设备具有多个接口，例如 USB扬声器可以包括两个接口：一个USB 键盘用于按键和一个 USB音频流。因为一个 USB 接口代表了一个基本功能，而每个 USB驱动程序控制一个接口，因此，以扬声器为例，Linux 需要两个不同的

13、驱动程序来处理一个硬件设备。USB接口可以有其他的设置，这些是和接口的参数不同的选择。接口的最初状态是在第一个设置，编号为 0。其他的设置可以用来以不同的方式控制端点，例如为设备保留大小不同的 USB 带宽。每个带有等时端点的设备对同一个接口使用不同的设置。内核使用 struct usb_interface结构体来描述 USB 接口。USB 核心把该结构体传递给 USB 驱动程序，之后由 USB 驱动程序来负责控制该结构体。该结构体中的重要字段有：struct usb_host_interface*altsetting一个接口结构体数组，包含了所有可能用于该接口的可选设置。每个 structu

14、sb_host_interface结构体包含一套由上述struct usb_host_endpoint结构体定义的端点配置。注意，这些接口结构体没有特定的次序。unsigned num_altsettingaltsetting 指针所指的可选设置的数量。struct usb_host_interface*cur_altsetting指向 altsetting 数组内部的指针，表示该接口的当前活动设置。329USB 驱动程序int minor如果捆绑到该接口的USB驱动程序使用USB主设备号，这个变量包含USB核心分配给该接口的次设备号。这仅在一个成功的 usb_register_dev 调用之

15、后才有效（在本章稍后描述）。struct usb_interface结构体中还有其他的字段，不过USB驱动程序不需要考虑它们。配置USB 接口本身被捆绑为配置。一个 USB 设备可以有多个配置，而且可以在配置之间切换以改变设备的状态。例如，一些允许下载固件到其上的设备包含多个配置以完成这个工作，而一个时刻只能激活一个配置。Linux 对多个配置的 USB 设备处理得不是很好，不过，幸好这种情况很少发生。Linux 使用 struct usb_host_config 结构体来描述 USB 配置，使用 structusb_device结构体来描述整个USB设备。USB设备驱动程序通常不需要读取或者

16、写入这些结构体中的任何值，因此这里就不详述它们了。想要深入探究的读者可以在内核源代码树的 include/linux/usb.h 文件中找到对它们的描述。USB设备驱动程序通常需要把一个给定的struct usb_interface结构体的数据转换为一个 struct usb_device 结构体，USB 核心在很多函数调用中都需要该结构体。interface_to_usbdev就是用于该转换功能的函数。可以期待的是，当前需要 struct usb_device结构体的所有 USB调用将来会变为使用一个 struct usb_interface参数，而且驱动程序不再需要去做转换的工作。概言之，

17、USB设备是非常复杂的，它由许多不同的逻辑单元组成。这些逻辑单元之间的关系可以简单地描述如下：设备通常具有一个或者更多的配置配置经常具有一个或者更多的接口接口通常具有一个或者更多的设置接口没有或者具有一个以上的端点USB 和 Sysfs由于单个USB 物理设备的复杂性，在sysfs 中表示该设备也相当复杂。无论是物理USB第十三章330设备（用struct usb_device表示）还是单独的USB接口（用struct usb_interface表示），在 sysfs 中均表示为单独的设备（这是因为这些结构体都包含一个 structdevice结构体）。以仅包含一个 USB接口的简易 USB

18、鼠标为例，下面是该设备的sysfs目录树：/sys/devices/pci0000:00/0000:00:09.0/usb2/2-1|-2-1:1.0|-bAlternateSetting|-bInterfaceClass|-bInterfaceNumber|-bInterfaceProtocol|-bInterfaceSubClass|-bNumEndpoints|-detach_state|-iInterface|-power|-state|-bConfigurationValue|-bDeviceClass|-bDeviceProtocol|-bDeviceSubClass|-bMaxP

19、ower|-bNumConfigurations|-bNumInterfaces|-bcdDevice|-bmAttributes|-detach_state|-devnum|-idProduct|-idVendor|-maxchild|-power|-state|-speed-versionstruct usb_device 表示为目录树中的：/sys/devices/pci0000:00/0000:00:09.0/usb2/2-1而鼠标的 USB 接口（USB 鼠标驱动程序所绑定的接口）位于如下目录：/sys/devices/pci0000:00/0000:00:09.0/usb2/2-1

20、/2-1:1.0我们将描述内核如何分类 USB 设备，以帮助理解上面这些长长的设备路径名的含义。第一个 USB 设备是一个根集线器（root hub）。这是一个 USB 控制器，通常包含在一个PCI 设备中。之所以这样命名该控制器，是因为它控制着连接到其上的整个 USB 总线。该控制器是连接 PCI 总线和 USB 总线的桥，也是该总线上的第一个 USB 设备。331USB 驱动程序所有的根集线器都由USB核心分配了一个独特的编号。在我们的例子中，根集线器名为usb2，因为它是注册到USB 核心的第二个根集线器。单个系统中可以包含的根集线器的编号在任何时候都是没有限制的。USB总线上的每个设备

21、都以根集线器的编号作为其名字中的第一个号码。该号码随后是一个横杠字符和设备所插入的端口号。因为我们例子中的设备插入到第一个端口，1 被添加到了名字中。因此，主 USB 鼠标设备的设备名是 2-1。因为该 USB 设备包含一个接口，导致了树中的另一个设备被添加到 sysfs 路径中。USB 接口的命名方案是设备名直到该接口为止：在我们的例子中，是 2-1 后面加一个冒号和 USB 配置的编号，然后是一个句点和接口的编号。因此对于本例而言，设备名是2-1:1.0，因为它是第一个配置，具有接口编号零。概言之，USB sysfs 设备命名方案为：根集线器-集线器端口号:配置.接口随着设备更深地进入 U

22、SB 树，和越来越多的 USB 集线器的使用，集线器的端口号被添加到跟随着链中前一个集线器端口号的字符串中。对于一个两层的树，其设备名类似于：根集线器-集线器端口号-集线器端口号:配置.接口从前面的USB设备和接口的目录列表可以看到，所有的USB特定信息都可以从sysfs直接获得（例如，idVendor、idProduct 和 bMaxPower 信息）。这些文件中的一个，即bConfigurationValue，可以被写入以改变当前使用的活动USB配置。当内核不能够确定选择哪一个配置以恰当地操作设备时，这对于具有多个配置的设备很有用。许多USB调制解调器需要向该文件中写入适当的配置值，以便把

23、恰当的USB驱动程序绑定到该设备。sysfs 并没有展示 USB 设备所有的不同部分，它只限于接口级别。设备可能包含的任何可选配置都没有显示，还有和接口相关联的端点的细节。这个信息可以从 usbfs 文件系统找到，该文件系统被挂装到系统的/proc/bus/usb/目录。/proc/bus/usb/devices 文件确实显示了和sysfs 所展示的所有信息相同的信息，还有系统中存在的所有 USB设备的可选配置和端点信息。usbfs 还允许用户空间的程序直接访问 USB 设备，这使得许多内核驱动程序可以迁移到用户空间，从而更加容易维护和调试。USB扫描仪是一个很好的例子，它不再存在于内核中，因

24、为它的功能现在包含在了用户空间的 SANE 库程序中。USB urbLinux内核中的 USB代码通过一个称为urb（USB 请求块）的东西和所有的 USB设备通信。这个请求块使用struct urb结构体来描述，可以从include/linux/usb.h文件中找到。第十三章332urb被用来以一种异步的方式往/从特定的USB 设备上的特定USB端点发送/接收数据。它的使用和文件系统异步I/O代码中的kiocb结构体以及网络代码中的struct skbuff很类似。USB 设备驱动程序可能会为单个端点分配许多urb，也可能对许多不同的端点重用单个的 urb，这取决于驱动程序的需要。设备中的每

25、个端点都可以处理一个 urb 队列，所以多个 urb 可以在队列为空之前发送到同一个端点。一个 urb的典型生命周期如下：由 USB 设备驱动程序创建。分配给一个特定 USB 设备的特定端点。由 USB 设备驱动程序递交到 USB 核心。由 USB 核心递交到特定设备的特定 USB 主控制器驱动程序。由 USB 主控制器驱动程序处理，它从设备进行 USB 传送。当 urb 结束之后，USB 主控制器驱动程序通知 USB 设备驱动程序。urb可以在任何时刻被递交该 urb 的驱动程序取消掉，或者被 USB 核心取消，如果该设备已从系统中移除。urb 被动态地创建，它包含一个内部引用计数，使得它们

26、可以在最后一个使用者释放它们时自动地销毁。本章描述的处理 urb的过程是很有用的，因为它使得流处理和其他复杂的、重叠的通信成为可能，而这使驱动程序可以获得最高可能的数据传输速度。不过如果只是想要发送单独的数据块或者控制消息，而不关心数据的吞吐率，过程就不必如此繁琐。（请参考“不使用 urb 的 USB 传输”一节）。struct urbstruct urb 结构体中 USB 设备驱动程序需要关心的字段有：struct usb_device*devurb 所发送的目标 struct usb_device指针。该变量在 urb 可以被发送到 USB 核心之前必须由 USB 驱动程序初始化。unsi

27、gned int pipeurb所要发送的特定目标struct usb_device的端点信息。该变量在urb可以被发送到 USB 核心之前必须由 USB 驱动程序初始化。驱动程序必须使用下列恰当的函数来设置该结构体的字段，具体取决于传输的方向。注意每个端点只能属于一种类型。333USB 驱动程序unsigned int usb_sndctrlpipe(struct usb_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个控制 OUT 端点。unsigned int usb_rcvctrlpipe(struct usb_device*

28、dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个控制 IN 端点。unsigned int usb_sndbulkpipe(struct usb_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个批量 OUT 端点。unsigned int usb_rcvbulkpipe(struct usb_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个批量 IN 端点。unsigned int usb_sndintpipe(struct us

29、b_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个中断 OUT 端点。unsigned int usb_rcvintpipe(struct usb_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个中断 IN 端点。unsigned int usb_sndisocpipe(struct usb_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个等时 OUT 端点。unsigned int usb_rcvisocpipe

30、(struct usb_device*dev,unsigned int endpoint)把指定 USB 设备的指定端点号设置为一个等时 IN 端点。unsigned int transfer_flags该变量可以被设置为许多不同的位值，取决于USB驱动程序对urb的具体操作。可用的值包括：URB_SHORT_NOT_OK如果被设置，该值说明任何可能发生的对IN 端点的简短读取应该被USB 核心当作是一个错误。该值只对从 USB 设备读取的 urb有用，对用于写入的 urb没意义。URB_ISO_ASAP如果该 urb 是等时的，当驱动程序想要该 urb 被调度时可以设置这个位，只要第十三章3

31、34带宽的利用允许它这么做，而且想要在此时设置 urb 中的 start_frame变量。如果一个等时的 urb没有设置该位，驱动程序必须指定start_frame的值，如果传输在当时不能启动的话必须能够正确地恢复。详情请参阅下一节的等时urb 部分。URB_NO_TRANSFER_DMA_MAP当 urb 包含一个即将传输的 DMA 缓冲区时应该设置该位。USB 核心使用transfer_dma变量所指向的缓冲区，而不是transfer_buffer变量所指向的。URB_NO_SETUP_DMA_MAP和URB_NO_TRANSFER_DMA_MAP位类似，该位用于控制带有已设置好的DMA缓

32、冲区的 urb。如果它被设置，USB 核心使用 setup_dma变量所指向的缓冲区，而不是 setup_packet 变量。URB_ASYNC_UNLINK如果被设置，对该 urb 的 usb_unlink_urb 调用几乎立即返回，该 urb 的链接在后台被解开。否则，此函数一直等到 urb被完全解开链接和结束才返回。使用该位时要小心，因为它可能会造成非常难以调试的同步问题。URB_NO_FSBR仅由 UHCI USB 主控制器驱动程序使用，指示它不要企图使用前端总线回收（Front Side Bus Reclamation）逻辑。该位通常不应该被设置，因为带有UHCI主控制器的机器会导致

33、大量的CPU负荷，而PCI总线忙于等待一个设置了该位的 urb。URB_ZERO_PACKET如果被设置，一个批量输出 urb 以发送一个不包含数据的小数据包来结束，这时数据对齐到一个端点数据包边界。一些断线的 USB 设备（例如许多 USB 到IR 设备）需要该位才能正确地工作。URB_NO_INTERRUPT如果被设置，当 urb 结束时，硬件可能不会产生一个中断。对该位的使用应当小心谨慎，只有把多个 urb排队到同一个端点时才使用。USB核心的函数使用该位来进行 DMA 缓冲区传输。void*transfer_buffer指向用于发送数据到设备（OUT urb）或者从设备接收数据（IN

34、urb）的缓冲区的指针。为了使主控制器正确地访问该缓冲区，必须使用kmalloc 来创建它，而不是在栈中或者静态内存中。对于控制端点，该缓冲区用于传输数据的中转。dma_addr_t transfer_dma用于以 DMA 方式传输数据到 USB 设备的缓冲区。335USB 驱动程序int transfer_buffer_lengthtransfer_buffer或者 transfer_dma变量所指向的缓冲区的大小（因为一个 urb只能使用其中一个）。如果该值为 0，两个传输缓冲区都没有被 USB 核心使用。对于一个OUT 端点，如果端点的最大尺寸小于该变量所指定的值，到 USB设备的传输将

35、被分解为更小的数据块以便正确地传输数据。这种大数据量的传输以连续的USB 帧的方式进行。在一个 urb 中提交一个大数据块然后让 USB 主控制器把它分割为更小的块，比以连续的次序发送更小的缓冲区的速度快得多。unsigned char*setup_packet指向控制urb的设置数据包的指针。它在传输缓冲区中的数据之前被传送。该变量只对控制 urb 有效。dma_addr_t setup_dma控制 urb用于设置数据包的 DMA缓冲区。它在普通传输缓冲区中的数据之前被传送。该变量只对控制 urb 有效。usb_complete_t complete指向一个结束处理例程的指针，当urb被完全

36、传输或者发生错误时，USB核心将调用该函数。在该函数内，USB 驱动程序可以检查 urb，释放它，或者把它重新提交到另一个传输中去。（有关结束处理例程的详情请参阅“结束urb：结束回调处理例程”一节）。usb_complete_t 的类型定义为：typedef void(*usb_complete_t)(struct urb*,struct pt_regs*);void*context指向一个可以被USB驱动程序设置的数据块。它可以在结束处理例程中当urb被返回到驱动程序时使用。有关该变量的详情请参阅随后的小节。int actual_length当 urb 结束之后，该变量被设置为 urb 所

37、发送的数据（OUT urb）或者 urb 所接收的数据（IN urb）的实际长度。对于 IN urb，必须使用该变量而不是 transfer_buffer_length变量，因为所接收的数据可能小于整个缓冲区的尺寸。int status当 urb 结束之后，或者正在被 USB 核心处理时，该变量被设置为 urb 的当前状态。USB驱动程序可以安全地访问该变量的唯一时刻是在urb结束处理例程中（在“结束 urb：结束回调处理例程”一节中描述）。该限制是为了防止当 urb 正在被 USB核心处理时竞态的发生。对于等时urb，该变量的一个成功值（0）只表示urb是否已经被解开链接。如果要获取等时ur

38、b 的详细状态，应该检查 iso_frame_desc变量。第十三章336该变量的有效值包括：0urb 传输成功。-ENOENTurb 被 usb_kill_urb 调用终止。-ECONNRESETurb被usb_unlink_urb调用解开链接，urb的transfer_flags变量被设置为URB_ASYNC_UNLINK。-EINPROGRESSurb仍然在被 USB主控制器处理。如果驱动程序中检查到该值，说明存在代码缺陷。-EPROTOurb 发生了下列错误之一：在传输中发生了 bitstuff 错误。硬件没有及时接收到响应数据包。-EILSEQurb 传输中发生了 CRC 校验不匹配

39、。-EPIPE端点被中止。如果涉及的端点不是控制端点，可以调用 usb_clear_halt函数来清除该错误。-ECOMM传输时数据的接收速度比把它写到系统内存的速度快。该错误值仅发生在 INurb 上。-ENOSR传输时从系统内存获取数据的速度不够快，跟不上所要求的USB数据速率。该错误值仅发生在 OUT urb 上。-EOVERFLOWurb发生了“串扰（babble）”错误。“串扰”错误发生在端点接收了超过端点指定最大数据包尺寸的数据时。-EREMOTEIO仅发生在 urb 的 transfer_flags变量被设置 URB_SHORT_NOT_OK标志时，表示 urb 没有接收到所要求

40、的全部数据量。337USB 驱动程序-ENODEVUSB 设备已从系统移除。-EXDEV仅发生在等时 urb 上，表示传输仅部分完成。为了确定所传输的内容，驱动程序必须查看单个帧的状态。-EINVALurb 发生了很糟糕的事情。USB 内核文档描述了该值的含义：等时错乱，如果发生这种情况：退出系统然后回家如果urb结构体中的某一个参数没有被正确地设置或者usb_submit_urb调用中的不正确函数参数把 urb 提交到了 USB 核心，也可能发生这个错误。-ESHUTDOWNUSB 主控制器驱动程序发生了严重的错误；设备已经被禁止，或者从系统脱离，而 urb在设备被移除之后提交。如果当 ur

41、b 被提交到设备时设备的配置被改变，也可能发生这个错误。一般来说，错误值-EPROTO、-EILSEQ 和-EOVERFLOW 表示设备、设备的固件或者把设备连接到计算机的电缆发生了硬件故障。int start_frame设置或者返回初始的帧数量，用于等时传输。int intervalurb 被轮询的时间间隔。仅对中断或者等时 urb有效。该值的单位随着设备速度的不同而不同。对于低速和满速的设备，单位是帧，相当于毫秒。对于其他设备，单位是微帧（microframe），相当于毫秒的 1/8。对于等时或者中断 urb，在 urb 被发送到 USB 核心之前，USB 驱动程序必须设置该值。int n

42、umber_of_packets仅对等时urb有效，指定该urb所处理的等时传输缓冲区的数量。对于等时 urb，在urb 被发送到 USB 核心之前，USB 驱动程序必须设置该值。int error_count由USB核心设置，仅用于等时urb结束之后。它表示报告了任何一种类型错误的等时传输的数量。struct usb_iso_packet_descriptor iso_frame_desc0仅对等时 urb 有效。该变量是一个 struct usb_iso_packet_descriptor结构体数组。该结构体允许单个urb一次定义许多等时传输。它还用于收集每个单独传输的传输状态。第十三章3

43、38struct usb_iso_packet_descriptor由下列字段组成：unsigned int offset该数据包的数据在传输缓冲区中的偏移量（第一个字节为 0）。unsigned int length该数据包的传输缓冲区大小。unsigned int actual_length该等时数据包接收到传输缓冲区中的数据长度。unsigned int status该数据包的单个等时传输的状态。它可以把相同的返回值作为主struct urb结构体的状态变量。创建和销毁 urbstruct urb 结构体不能在驱动程序中或者另一个结构体中静态地创建，因为这样会破坏USB核心对urb所使用

44、的引用计数机制。它必须使用usb_alloc_urb函数来创建。该函数原型如下：struct urb*usb_alloc_urb(int iso_packets,int mem_flags);第一个参数，iso_packets，是该 urb 应该包含的等时数据包的数量。如果不打算创建等时 urb，该值应该设置为 0。第二个参数，mem_flags，和传递给用于从内核分配内存的 kmalloc 函数（这些标志的详情参见第八章的“标志参数”一节）的标志有相同的类型。如果该函数成功地为 urb 分配了足够的内存空间，指向该 urb的指针将被返回给调用函数。如果返回值为 NULL，说明 USB核心内发

45、生了错误，驱动程序需要进行适当的清理。当一个urb被创建之后，在它可以被USB核心使用之前必须被正确地初始化。关于如何初始化不同类型的 urb，参见随后的小节。驱动程序必须调用usb_free_urb 函数来告诉USB核心驱动程序已经使用完urb。该函数只有一个参数：void usb_free_urb(struct urb*urb);这个参数是指向所需释放的struct urb的指针。在该函数被调用之后，urb结构体就消失了，驱动程序不能再访问它。339USB 驱动程序中断 urbusb_fill_int_urb是一个辅助函数，用来正确地初始化即将被发送到USB设备的中断端点的 urb：voi

46、d usb_fill_int_urb(struct urb*urb,struct usb_device*dev,unsigned int pipe,void*transfer_buffer,int buffer_length,usb_complete_t complete,void*context,int interval);该函数包含很多的参数：struct urb*urb指向需初始化的 urb 的指针。struct usb_device*dev该 urb 所发送的目标 USB 设备。unsigned int pipe该 urb 所发送的目标 USB 设备的特定端点。该值是使用前述 usb_

47、sndintpipe 或usb_rcvintpipe 函数来创建的。void*transfer_buffer用于保存外发数据或者接收数据的缓冲区的指针。注意它不能是一个静态的缓冲区，必须使用 kmalloc 调用来创建。int buffer_lengthtransfer_buffer 指针所指向的缓冲区的大小。usb_complete_t complete指向当该 urb 结束之后调用的结束处理例程的指针。void*context指向一个小数据块，该块被添加到 urb 结构体中以便进行结束处理例程后面的查找。int interval该 urb应该被调度的间隔。有关该值的正确单位，请参考前面对

48、struct urb 结构体的描述。批量 urb批量urb的初始化和中断urb很相似。所使用的相关函数是usb_fill_bulk_urb，原型如下：void usb_fill_bulk_urb(struct urb*urb,struct usb_device*dev,unsigned int pipe,void*transfer_buffer,第十三章340 int buffer_length,usb_complete_t complete,void*context);该函数的参数和 usb_fill_int_urb 函数完全一样。不过，没有时间间隔参数，因为批量urb 没有时间间隔值。请注

49、意，无符号整型 pipe 变量必须使用 usb_sndbulkpipe 或usb_rcvbulkpipe 函数来初始化。usb_fill_int_urb 函数不在 urb中设置 transfer_flags 变量，因此，驱动程序必须自己来修改该字段。控制 urb控制 urb 的初始化方法和批量 urb 几乎一样，调用 usb_fill_control_urb 函数。void usb_fill_control_urb(struct urb*urb,struct usb_device*dev,unsigned int pipe,unsigned char*setup_packet,void*tra

50、nsfer_buffer,int buffer_length,usb_complete_t complete,void*context);函数参数和 usb_fill_bulk_urb 函数完全一样，除了一个新的参数，即 unsigned char*setup_packet，它指向即将被发送到端点的设置数据包的数据。同样，无符号整型pipe变量必须使用 usb_sndctrlpipe 或 usb_rcvictrlpipe 函数来初始化。usb_fill_control_urb 函数不设置 urb 中的 transfer_flags变量，因此驱动程序必须自己修改该字段。大部分的驱动程序不使用该函