linux驱动移植-USB驱动基础
一、USB总线介绍
1.1 简介
我们之前接触过的通信协议有串口、I2C、SPI以及CAN总线，这里我们又去学习USB总线，那USB和之前我们介绍过那些总线有什么区别呢。
通用串行总线（英语：Universal Serial Bus，缩写：USB）是连接计算机系统与外部设备的一种串口总线标准，也是一种输入输出接口的技术规范，被广泛地应用于个人电脑和移动设备等信息通讯产品，并扩展至摄影器材、数字电视（机顶盒）、游戏机等其它相关领域。
在USB总线出现之前，计算机与键盘、鼠标、扫描仪、打印机等的设备连接都使用专用的接口连接，不同的设备的接口不能互用，扩展性很差，每次插拔设备都要关闭计算机，不支持热插拔，且通信速率很低。
为了解决上述问题，USB总线诞生了。USB总线就好像一条管道，管道里流过的东西只要符合USB协议，至于具体流的是什么东西，USB总线并不关心。对应具体的设备上，只要是支持USB协议的设备，都可以连接计算机，如USB键盘、USB鼠标、USB摄像头、USB音箱等。USB的出现简化了计算机与外围设备的连接，增强了扩展性，支持热插拔，且通信速度很快。
1.2 USB协议版本
从USB协议诞生至今，出现了多个USB协议版本，如USB1.0、USB1.1、USB2.0、USB3.0、USB3.1、USB3.2。最新的是USB4.0协议，可直连CPU的PCIe总线，最大速度可达40Gbps，使用Type-C接口，兼容DP视频协议、PD快充协议等，最高支持100W供电。
| USB协议版本 | 速率称号 | 最大速率 | 电源 | 类型 | 推出时间 |
|---|---|---|---|---|---|
| USB1.0 | 低速(Low-Speed) | 1.5Mbps | 5V/500mA | 半双工 | 1996年1月 |
| USB1.1 | 全速(Full-Speed) | 12Mbps | 5V/500mA | 半双工 | 1998年9月 |
| USB2.0 | 高速(High-Speed) | 480Mbps | 5V/500mA | 半双工 | 2000年4月 |
| USB3.0(USB3.2 Gen1) | 超高速(SuperSpeed USB) | 5Gbps | 5V/900mA | 全双工 | 2008年月11月 |
| USB3.1(USB3.2 Gen2) | SuperSpeed USB 10Gbps | 10Gbps | 20V/5A | 全双工 | 2013年月7月 |
| USB3.2(USB3.2 Gen2×2) | SuperSpeed USB 20Gps | 20Gbps | 20V/5A | dual-lane | 2017年月9月 |
| USB4.0(Gen3×2) | ---- | 40Gbps | 100瓦 | single-lane或dual-lane，兼容Thunderbolt3 | 2019年月8月 |
注：USB3.2推出时，USB-IF公布了新的命名规范，将USB3.0改名为USB3.2 Gen1，USB3.1改名为USB3.2 Gen2，而将能够使用两个USB Type-C Rx/Tx针脚的USB3.2改名为USB3.2 Gen2×2。
下图是各个版本USB协议使用的标志及接口，USB3.2以后，只使用Type-C接口，包括图中未画出的USB4.0和Thunderbolt3。
伴随着USB的版本迭代，USB又产生了多种连接器类型规范，比如Type A、Type B、Type-C。
下图是USB3.2协议使用的标志，此标志是USB-IF网站上最新的。
下图是USB4.0协议使用的标志，USB4.0使用Gen3 lane，single-lane可达到20Gps，dual-lane为40Gps。USB4™ 20Gbps使用single-lane，USB4™ 40Gbps使用dual-lane。
二、USB总线特点
2.1 主从模式
USB是主从模式的总线，主机称为Host，丛机称为Device(设备)。从机与从机之间、主机与主机之间(不包括USB4.0)，不能互联。每次通信都是由主机发起，从机不能主动发起通信，只能被动的应答主机的请求。
USB3.0及以后的USB协议，主机也可以和集线器(Hub)通信。为了增加灵活性，又出现了USB OTG(On The Go)，USB OTG支持主从切换，同一个设备，在不同场合下，可以在主机和从机之间切换。
USB OTG线中增加了一根USB ID线，当USB ID线上拉时，处于从机模式，当USB ID线接地时，处于主机模式。
2.2 总线结构
在有些场景下，我们期望将一个USB接口扩展为多个USB接口，这时我们就会使用到一个装置，也就是USB Hub，如下图所示：
因此，USB总线可能呈现出树状的拓扑接口吗，USB标准上说USB总线拓扑是一种分层星型结构，如下图所示：
从树结构我们可以看到：
- 树的根节点是USB Host控制器（上图没有画出来），连接在USB Host控制器上的是USB根集线器(Root Hub)；
- USB集线器(Hub)可以将一个USB接口扩展成多个USB接口，扩展出的USB接口又可以通过USB集线器(Hub)扩展，每个USB接口都可以接USB设备；
- 集线器只能扩展出更多的USB接口，而不能扩展出更多的带宽，所有USB设备共享USB Host控制器的带宽，当有多个USB设备需要较大带宽时，可以考虑将他们接到不同USB Host控制器上的根集线器上，以避免带宽不足；
- 集线器级联最多5层，因此最大为7层星型结构；这个最大7层星形结构，代表的是一条USB总线，一个USB分层星型结构有且仅有一个USB主机控制器，但并不是说一台计算机就只有一个USB总线；
比如我的计算机内部就是1个USB主控制器+Root Hub，从Windows设备管理器可以看到，下图是其中一条USB总线：
2.3 电气特性
下图是USB3.2线缆的示意图，同时兼容USB2.0：
USB使用差分信号传输数据，图中的D+和D-是一对差分线，SSTX+和SSTX-是一对差分线，SSRX+和SSRX-是一对差分线:
- USB2.0只有一对差分线，即下图中的D+、D-，因此USB2.0是半双工的，不能同时收发数据;
- USB3.2拥有两对差分线，即SSTX+和SSTX-及SSRX+和SSRX-，因此USB3.2是全双工的，可同时收发数据；
USB3.2和USB2.0使用不同的差分线传输数据，两者互不干扰，可同时工作。USB3.2线缆中保留了USB2.0的数据传输通道，实现了对USB2.0的兼容。USB主机可通过$V_{BUS}$线向设备供电，最大可输出20V/5A，GND是地线。
2.4 热插拔
当一个USB设备插入PC机，PC机怎么知道有设备插入?
如下图所示，USB2.0接口只有4条线：$V_{BUS}$（5V），GND，D-，D+。
USB低速设备硬件接线图
USB全速（高速）设备硬件接线图
注意：上图中VCC同$V_{BUS}$。
PC机的USB插孔的D-和D+数据线均连接15K欧姆的下拉电阻。而USB设备端的D-或D+数据线连接1.5K欧姆的上拉电阻。当设备插入PC机的时候，会将PC机的D-或D+端的电压拉高，当PC机在D-或D+端检测到高电平时，就知道有设备插入了。
如果是PC机D-端被拉高，接入的则是USB低速设备；如果是PC机D+端被拉高，接入的则是USB全速或高速设备，具体是全速设备还是高速设备，会由PC机和USB设备发包握手确定。
三、USB传输基础
3.1 传输类型
USB架构包含四种基本类型的数据传输：
- 控制传输：控制传输用于配置设备、获取设备信息、发送命令到设备、获取设备的状态。每个USB设备都有端点0的控制端点，当USB设备插入到USB主机拓扑网络中时，USB主机就通过端点0与USB设备通信，对USB设备进行配置，便于后续的数据传输。USB协议保证控制传输有足够的带宽。控制传输可靠，时间有保证，但传输的数据量不大。如USB设备的枚举过程就采用的是控制传输；
- 中断传输：当USB主机请求USB设备传输数据时，中断传输以一个固定的速率传送少量的数据。中断端点的数据传输方式为中断传输，数据传输可靠，实时性高，这里的中断并不是USB设备产生中断，而是USB主机每隔一个固定的时间主动查询USB设备是否有数据要传输，以轮询的方式提高实时性。如USB鼠标采用的是中断传输；
- 批量传输：批量传输用于传输大量数据。USB协议不保证这些数据传输可以在特定的时间内完成，但保证数据的准确性。如果总线上的带宽不足以发送整个批量包，则将数据拆分为多个包传输。批量传输数据可靠，但实时性较低。如USB硬盘、打印机等设备就采用的是批量传输方式；
- 等时传输：等时传输也可以传输大量数据，但数据的可靠性无法保证。采用等时传输的USB设备更加注重保持一个恒定的数据传输速度，对数据的可靠性要求不高。如USB摄像头就使用的是等时传输方式；
下表是这四类传输在不同速度模式下支持的最大包长度：
| 速度模式 | 低速 | 全速 | 高速 |
| 控制传输 | 8 | 8/16/32/64 | 64 |
| 同步传输 | 不支持 | 1023 | 1024 |
| 中断传输 | 0~8 | 0~64 | 0~1024 |
| 批量传输 | 不支持 | 8/16/32/64 | 512 |
3.2 传输要素
USB2.0主机控制器通过把时间在低速、全速模式下分成1毫秒宽的帧（frame），在高速模式下分成125微妙宽的微帧（microfranme），以此来管理传输。主机控制器将每个帧或微帧的一部分分配给各个传输。每个帧（或微帧）以带有时序参考的帧（Start-of-Frame，SOF）开始。超高速总线不使用SOF，但主机控制器仍可以在125微妙的总线时间内安排超高速传输。
USB传输可以安排在1个或多个帧或微帧中，每个传输包含多个事务，每个事务又进一步含有多个信息包（packets）。信息包必须在一个帧或微帧中传输完毕，不能跨帧或微帧。信息包分为4类，令牌类信息包确认事务类型，数据类信息包携带数据和状态代码，握手类信息包携带状态代码，最后一种是特殊类信息包。
USB传输由一个或多个事务（transaction）组成，这些事务可将数据载入端点或从端点取出。USB2.0事务开始于主机在总线上发送的令牌信息包（token packet）。令牌信息包含有目标端点号和方向。IN令牌信息包表示向端点请求数据信息包。OUT令牌信息包则是主机派发数据信息包的先行信息。除了数据，每个数据包还含有错误检查位和一个带有数据顺序值的信息包ID（PID）。许多事务还拥有握手信息包（handshake packet），数据的接收端用它来报告事务成功或失败。对于超高速传输事务，信息包类型和协议有所不同，但却含有相同的地址、错误检查和与数据相配合的数据顺序值。
| 信息包类型 | PID名字 | 取值(二进制) | 传输类型 | 来源 | 说明 |
|---|---|---|---|---|---|
| 令牌 | OUT | 0001 | 全部 | 主机 | IN事务中需要的设备和端点地址 |
| 令牌 | IN | 1001 | 全部 | 主机 | IN事务中需要的设备和端点地址 |
| 令牌 | SOF | 0101 | 帧开始 | 主机 | SOF标识符和帧号 |
| 令牌 | SETUP | 1101 | 控制 | 主机 | 用于Setup事务的设备和端点地址 |
| 数据 | DATA0 | 0011 | 全部 | 主机、设备 | 数据交替或数据PID序列 |
| 数据 | DATA1 | 1011 | 全部 | 主机、设备 | 数据交替或数据PID序列 |
| 数据 | DATA2 | 0111 | 等时 | 主机、设备 | 数据PID序列 |
| 数据 | MDATA | 1111 | 等时、分割事务 | 主机、设备 | 数据PID序列 |
| 握手 | ACK | 0010 | 控制、批量、中断 | 主机、设备 | 接收端接收到正确的数据信息包 |
| 握手 | NAK | 1010 | 控制、批量、中断 | 设备 | 接收端不能接收数据，或者发送端无法发送数据或无数据要发送 |
| 握手 | STALL | 1110 | 控制、批量、中断 | 设备 | 控制请求不被支持或端点被停止 |
| 握手 | NYET | 0110 | 控制写、批量、OUT、分割事务 | 设备 | 正确的接收了数据信息包，但还没准备好接收下一个，或集线器还没有将数据信息包分割完成 |
| 特殊 | PRE | 1100 | 控制、中断 | 主机 | 主机发出的先行信号 |
| 特殊 | ERR | 1100 | 全部 | 集线器 | 由集线器返回的错误 |
| 特殊 | SPLIT | 1000 | 全部 | 主机 | 分割事务 |
| 特殊 | PING | 0100 | 控制写、批量、OUT | 主机 | PING测试 |
| 特殊 | EXT | 0000 | 无 | 主机 | 扩展，未使用 |
更多细节参考：USB协议详解。
四、USB驱动分析
4.1 驱动分类
USB的驱动可以分为3类：
- USB主机控制器驱动，主要包括：
- usb主机控制器驱动的创建；
- 根hub设备的创建和注册；
- 主机端USB设备驱动(更准确的说是usb接口驱动)；
- 设备端USB Gadget驱动(专业术语，用于描述连接到计算机的USB的设备的驱动)；
通常，对于USB这种标准化的设备，内核已经将USB主机控制器驱动编写好了，设备端Gadget驱动通常只运行固件程序而不是基于Linux, 所以驱动工程师的主要工作就是编写主机端USB设备驱动。
4.2 USB驱动框架
USB驱动框架结构图如下：
USB总线驱动程序包括USB Core和USB HCD两部分，其作用如下：
- 识别USB设备：
- 分配地址；
- 并告诉USB设备；
- 发出命令获取描述符；
- 查找并安装对应的USB设备驱动程序(更准确的说是usb接口驱动)；；
- 提供USB读写函数；
USB总线上的所有通信都是由主机发起的，所以本质上，USB都是采用轮询的方式进行的：
- 主机会使用轮询的方式不断检测总线上是否有设备接入，如果有设备接入相应的D+、D-就会有电平变化；
- 然后USB总线就会按照USB规定的协议与设备进行通信，设备将存储在自身的设备信息依次交给主机；
- 主机将这些信息组织起来，上报到内核，内核中的USB子系统再去匹配相应的设备驱动；
上面所说的主机具体指的是USB主机控制器。
4.3 USB Core
USB Core这个模块是纯软件部分，并不代表一个设备，是独立于硬件的协议栈，它是所有USB设备赖以生存的模块，即USB子系统的核心。代码位于kernel/driver/usb/core目录下。
USB核心层向上为USB设备驱动提供编程接口，向下为USB主机控制器驱动提供编程接口，维护整个系统的USB设备信息，完成设备热插拔控制、总线数据传输控制等。
USB核心层将用户的请求映射到相关的USB HCD，用户不能直接访问USB HCD，USB核心层就是USB HCD和USB设备的桥梁。
4.4 USB HCD(Host Controller Driver)
硬件主机控制器HOST Contrller之上运行的是USB HCD，是对USB主机控制器的一个抽象，实现USB核心层与主机控制器之间的对话接口。代码位于drivers/usb/host目录下，比如ohci-s3c2410.c文件。
USB主机控制器包含多种不同的类型，即OHCI和UHCI，EHCI，和xHCI，不同类型的USB主机控制器的区别和联系如下：
4.5 USB Devices Driver
USB设备驱动框架如下图所示：
为了更好地描述USB设备的特征，USB提出了设备架构的概念。从这个角度来看，可以认为USB设备是由一些配置(configuration)、接口(interface)和端点(endpoint)组成，即一个USB设备可以含有一个或多个配置，在每个配置中可含有一个或多个接口，在每个接口中可含有若干个端点。其中：
- 配置和接口是对USB设备功能的抽象；
- 实际的数据传输由端点来完成；
- 每个USB设备，都可能有多个接口，每个接口都实现了一个功能。在linux，每个USB设备都是一个device(具体是struct usb_device)、每一个接口也是一个device(具体是struct usb_interface，代表一个逻辑上的设备)。不管是USB设备还是USB接口，都会被注册到同一个总线上，也就是usb_bus_type，其之间的区别会在match函数中区分，之后再去绑定不同的driver。
- 所有的USB设备都会和usb_generic_driver设备驱动匹配，当一个USB设备被插入的时候，USB设备驱动，也就是usb_generic_driver会跟USB设备交互，得到其所有的各种描述符，并为每个接口都定义成为一个device，之后再加载到usb_bus上，让其去匹配其对应的接口驱动程序。
任何USB设备都包含设备描述符，主要用与说明设备树形（设备描述符，配置描述符，接口描述符，端点描述符之间的关系），通常都被固话在设备内部，当主机检测到有设备插入的时候，就会通过控制传输模式将设备描述信息读出来，这个步骤一般是在设备接入主机时设备进行枚举时完成的。
4.6 USB设备地址和端点
每个USB设备都有唯一的设备地址，比如root hub的设备地址为1，设备地址是usb设备连接上主机时由usb主机控制器分配的，usb主机控制器主要依靠这个设备地址对usb设备进行访问。
但是在usb设备内部地址会被分的更细，设备会分出一些端点来，每个端点在设备都会有一个端点号，这个端点号是设备生产时给设定的。如端点0、端点1等，一个usb设备最多可以包含16个端点，每个端点的地址为0~15。
其中每个端点地址对应一个方向。例如端点3-IN，端点3-OUT，这另个含义不同。但是需要注意的是有一个特殊端点-端点0，每个usb必须要有一个端点0，其作用为对设备枚举和对设备进行一些基本的控制功能，端点0也被称作控制端点，并且它与其他的端点还有一个不同之处在于端点0的数据传输方向是双向的，即端点0既可以给主机发送数据，也可以接收主机发送过来的数据，而其他端点都是单向的。
虽然有16个端点，单通常我们只用到3个如下：
- EP0：传输配置和控制信息；
- EP1：数据输入IN_EP；
- EP2：数据输出OUT_EP；
除了端点0，其余的端点在设备配置之前不能与主机通信，只有向主机报告这些端点的特性并确认后才能被激活。
五、USB设备驱动架构中的描述符
USB设备使用各种描述符来说明其设备架构，包括设备描述符、配置描述符、接口描述符、端点描述符。
5.1 端点
USB通信最基本的形式是通过端点的东西。USB端点只能往一个方向传送数据，从主机到设备(称为输出端点out)或者从设备到主机(称为输入端点in)，端点可以看作是单向的管道。
USB端点有四种不同的类型，分别具有不同的传送数据的方式：对应着我们之前介绍的四种基本类型的数据传输：控制、中断、批量、等时。
内核中使用struct usb_host_endpoint结构体来描述USB端点，其定义在include/linux/usb.h：
/** * struct usb_host_endpoint - host-side endpoint descriptor and queue * @desc: descriptor for this endpoint, wMaxPacketSize in native byteorder * @ss_ep_comp: SuperSpeed companion descriptor for this endpoint * @ssp_isoc_ep_comp: SuperSpeedPlus isoc companion descriptor for this endpoint * @urb_list: urbs queued to this endpoint; maintained by usbcore * @hcpriv: for use by HCD; typically holds hardware dma queue head (QH) * with one or more transfer descriptors (TDs) per urb * @ep_dev: ep_device for sysfs info * @extra: descriptors following this endpoint in the configuration * @extralen: how many bytes of "extra" are valid * @enabled: URBs may be submitted to this endpoint * @streams: number of USB-3 streams allocated on the endpoint * * USB requests are always queued to a given endpoint, identified by a * descriptor within an active interface in a given USB configuration. */ struct usb_host_endpoint { struct usb_endpoint_descriptor desc; struct usb_ss_ep_comp_descriptor ss_ep_comp; struct usb_ssp_isoc_ep_comp_descriptor ssp_isoc_ep_comp; struct list_head urb_list; void *hcpriv; struct ep_device *ep_dev; /* For sysfs info */ unsigned char *extra; /* Extra descriptors */ int extralen; int enabled; int streams; };
其中部分参数含义如下：
- desc：端点描述符；
- ss_ep_comp：超快速端点描述符；
- urb_list：本端口对应的urb链表；
- enabled：使能的话urb才能被提交到此端口；
usb_host_endpoint 结构体在另一个名为struct usb_endpoint_descriptor的结构体中包含真正的端点信息，其定义在include/uapi/linux/usb/ch9.h：
/* USB_DT_ENDPOINT: Endpoint descriptor */ struct usb_endpoint_descriptor { __u8 bLength; __u8 bDescriptorType; __u8 bEndpointAddress; __u8 bmAttributes; __le16 wMaxPacketSize; __u8 bInterval; /* NOTE: these two are _only_ in audio endpoints. */ /* use USB_DT_ENDPOINT*_SIZE in bLength, not sizeof. */ __u8 bRefresh; __u8 bSynchAddress; } __attribute__ ((packed));
其中部分参数含义如下：
- bLength：描述符长度；
- bDescriptorType：描述符类型， 端点描述符类型值是5；
- bEndpointAddress：端点地址：位[3:0]表示端点号，第7位是方向：0位输出、1为输入；
- bmAttributes：端点属性：位[1:0]值00表示控制、01表示等时、10表示批量、11表示中断；
- wMaxPacketSize：本端点接受或发送的最大信息包的大小；
- bInterval：轮询数据传输端点的时间间隔，用在中断传输上,比如间隔时间查询鼠标的数据;
5.2 接口
USB端口被捆绑为接口，USB接口只处理一种USB逻辑，一个USB接口代表一个逻辑上的设备，比如声卡驱动，就有两个接口：录音接口和播放接口。
内核使用struct usb_interface结构体来描述USB接口。USB核心把该结构体传递给USB设备驱动程序，之后由USB设备驱动程序来负责控制该结构体，该结构定义在include/linux/usb.h：
/** * struct usb_interface - what usb device drivers talk to * @altsetting: array of interface structures, one for each alternate * setting that may be selected. Each one includes a set of * endpoint configurations. They will be in no particular order. * @cur_altsetting: the current altsetting. * @num_altsetting: number of altsettings defined. * @intf_assoc: interface association descriptor * @minor: the minor number assigned to this interface, if this * interface is bound to a driver that uses the USB major number. * If this interface does not use the USB major, this field should * be unused. The driver should set this value in the probe() * function of the driver, after it has been assigned a minor * number from the USB core by calling usb_register_dev(). * @condition: binding state of the interface: not bound, binding * (in probe()), bound to a driver, or unbinding (in disconnect()) * @sysfs_files_created: sysfs attributes exist * @ep_devs_created: endpoint child pseudo-devices exist * @unregistering: flag set when the interface is being unregistered * @needs_remote_wakeup: flag set when the driver requires remote-wakeup * capability during autosuspend. * @needs_altsetting0: flag set when a set-interface request for altsetting 0 * has been deferred. * @needs_binding: flag set when the driver should be re-probed or unbound * following a reset or suspend operation it doesn't support. * @authorized: This allows to (de)authorize individual interfaces instead * a whole device in contrast to the device authorization. * @dev: driver model's view of this device * @usb_dev: if an interface is bound to the USB major, this will point * to the sysfs representation for that device. * @reset_ws: Used for scheduling resets from atomic context. * @resetting_device: USB core reset the device, so use alt setting 0 as * current; needs bandwidth alloc after reset. * * USB device drivers attach to interfaces on a physical device. Each * interface encapsulates a single high level function, such as feeding * an audio stream to a speaker or reporting a change in a volume control. * Many USB devices only have one interface. The protocol used to talk to * an interface's endpoints can be defined in a usb "class" specification, * or by a product's vendor. The (default) control endpoint is part of * every interface, but is never listed among the interface's descriptors. * * The driver that is bound to the interface can use standard driver model * calls such as dev_get_drvdata() on the dev member of this structure. * * Each interface may have alternate settings. The initial configuration * of a device sets altsetting 0, but the device driver can change * that setting using usb_set_interface(). Alternate settings are often * used to control the use of periodic endpoints, such as by having * different endpoints use different amounts of reserved USB bandwidth. * All standards-conformant USB devices that use isochronous endpoints * will use them in non-default settings. * * The USB specification says that alternate setting numbers must run from * 0 to one less than the total number of alternate settings. But some * devices manage to mess this up, and the structures aren't necessarily * stored in numerical order anyhow. Use usb_altnum_to_altsetting() to * look up an alternate setting in the altsetting array based on its number. */ struct usb_interface { /* array of alternate settings for this interface, * stored in no particular order */ struct usb_host_interface *altsetting; struct usb_host_interface *cur_altsetting; /* the currently * active alternate setting */ unsigned num_altsetting; /* number of alternate settings */ /* If there is an interface association descriptor then it will list * the associated interfaces */ struct usb_interface_assoc_descriptor *intf_assoc; int minor; /* minor number this interface is * bound to */ enum usb_interface_condition condition; /* state of binding */ unsigned sysfs_files_created:1; /* the sysfs attributes exist */ unsigned ep_devs_created:1; /* endpoint "devices" exist */ unsigned unregistering:1; /* unregistration is in progress */ unsigned needs_remote_wakeup:1; /* driver requires remote wakeup */ unsigned needs_altsetting0:1; /* switch to altsetting 0 is pending */ unsigned needs_binding:1; /* needs delayed unbind/rebind */ unsigned resetting_device:1; /* true: bandwidth alloc after reset */ unsigned authorized:1; /* used for interface authorization */ struct device dev; /* interface specific device info */ struct device *usb_dev; struct work_struct reset_ws; /* for resets in atomic context */ };
其中部分参数含义如下：
- altsetting：包含所有可用于该接口的可选设置的接口结构数组。每个 struct usb_host_interface 包含一套端点配置，即struct usb_host_endpoint结构所定义的端点配置。这些接口结构没有特别的顺序；
- cur_altsetting： 指向altsetting内部的指针，表示当前激活的接口配置；
- num_altsetting：可选设置的数量；
- minor：如果绑定到这个接口的 USB 驱动使用USB主设备号, 这个变量包含由USB核心分配给接口的次设备号. 这只在一个成功的调用 usb_register_dev后才有效；
其中usb_host_interface 结构定义如下：
/* host-side wrapper for one interface setting's parsed descriptors */ struct usb_host_interface { struct usb_interface_descriptor desc; int extralen; unsigned char *extra; /* Extra descriptors */ /* array of desc.bNumEndpoints endpoints associated with this * interface setting. these will be in no particular order. */ struct usb_host_endpoint *endpoint; char *string; /* iInterface string, if present */ };
可以看到该结构成员包含了：
- desc：接口描述符；
- endpoint：这个接口包含的所有端点；
- extra：额外的描述符；
我们重点看一下接口描述符usb_interface_descriptor ，其定义在include/uapi/linux/usb/ch9.h：
/* USB_DT_INTERFACE: Interface descriptor */ struct usb_interface_descriptor { __u8 bLength; __u8 bDescriptorType; __u8 bInterfaceNumber; __u8 bAlternateSetting; __u8 bNumEndpoints; __u8 bInterfaceClass; __u8 bInterfaceSubClass; __u8 bInterfaceProtocol; __u8 iInterface; } __attribute__ ((packed));
其中部分参数含义如下：
- bLength：描述符长度；
- bDescriptorType：描述符类型，接口描述符类型值是4；
- bInterfaceNumber：接口的编号，相同的编号代表相同的功能接口；
- bAlternateSetting：接口的设置的编号，同一个接口可以有一个或者多个设置代表该接口下不同的参数；
- bNumEndpoints：要使用的端点个数(不包括端点0), 表示有多少个端点描述符，比如鼠标就只有一个端点；
- bInterfaceClass：接口类型；
- bInterfaceSubClass：接口子类型；
- bInterfaceProtocol：接口所遵循的协议；
- iInterface：描述该接口的字符串索引值；
5.3 配置
USB接口被捆绑为配置。一个USB设备可以有多个配置，而且可以在配置之间切换以改变设备的状态。例如，一些允许下载固件到其上的设备包含多个配置以完成这个工作，而一个时刻只能激活一个配置。
内核使用usb_host_config来描述USB设备的配置，定义在include/linux/usb.h：
/** * struct usb_host_config - representation of a device's configuration * @desc: the device's configuration descriptor. * @string: pointer to the cached version of the iConfiguration string, if * present for this configuration. * @intf_assoc: list of any interface association descriptors in this config * @interface: array of pointers to usb_interface structures, one for each * interface in the configuration. The number of interfaces is stored * in desc.bNumInterfaces. These pointers are valid only while the * the configuration is active. * @intf_cache: array of pointers to usb_interface_cache structures, one * for each interface in the configuration. These structures exist * for the entire life of the device. * @extra: pointer to buffer containing all extra descriptors associated * with this configuration (those preceding the first interface * descriptor). * @extralen: length of the extra descriptors buffer. * * USB devices may have multiple configurations, but only one can be active * at any time. Each encapsulates a different operational environment; * for example, a dual-speed device would have separate configurations for * full-speed and high-speed operation. The number of configurations * available is stored in the device descriptor as bNumConfigurations. * * A configuration can contain multiple interfaces. Each corresponds to * a different function of the USB device, and all are available whenever * the configuration is active. The USB standard says that interfaces * are supposed to be numbered from 0 to desc.bNumInterfaces-1, but a lot * of devices get this wrong. In addition, the interface array is not * guaranteed to be sorted in numerical order. Use usb_ifnum_to_if() to * look up an interface entry based on its number. * * Device drivers should not attempt to activate configurations. The choice * of which configuration to install is a policy decision based on such * considerations as available power, functionality provided, and the user's * desires (expressed through userspace tools). However, drivers can call * usb_reset_configuration() to reinitialize the current configuration and * all its interfaces. */ struct usb_host_config { struct usb_config_descriptor desc; char *string; /* iConfiguration string, if present */ /* List of any Interface Association Descriptors in this * configuration. */ struct usb_interface_assoc_descriptor *intf_assoc[USB_MAXIADS]; /* the interfaces associated with this configuration, * stored in no particular order */ struct usb_interface *interface[USB_MAXINTERFACES]; /* Interface information available even when this is not the * active configuration */ struct usb_interface_cache *intf_cache[USB_MAXINTERFACES]; unsigned char *extra; /* Extra descriptors */ int extralen; };
其中部分参数含义如下：
- desc：配置描述符；
- interface：这个配置包含的所有接口；
- extra：额外的描述符；
其中struct usb_config_descriptor 结构体定义在include/uapi/linux/usb/ch9.h：
/* USB_DT_CONFIG: Configuration descriptor information. * * USB_DT_OTHER_SPEED_CONFIG is the same descriptor, except that the * descriptor type is different. Highspeed-capable devices can look * different depending on what speed they're currently running. Only * devices with a USB_DT_DEVICE_QUALIFIER have any OTHER_SPEED_CONFIG * descriptors. */ struct usb_config_descriptor { __u8 bLength; __u8 bDescriptorType; __le16 wTotalLength; __u8 bNumInterfaces; __u8 bConfigurationValue; __u8 iConfiguration; __u8 bmAttributes; __u8 bMaxPower; } __attribute__ ((packed));
其中部分参数含义如下：
- bLength：描述符长度；
- bDescriptorType：描述符类型，配置描述符类型值是2；
- wTotalLength：配置下面所有描述符的长度，包括这个配置描述符；
- bNumInterfaces：配置所支持的接口数；
- bConfigurationValue：配置值，实际上存的就是当前配置在usb_device->config数组中的索引；
- iConfiguration：描述该配置的字符串的索引值；
- bmAttributes：供电模式的选择；
- bMaxPower：设备从总线提取的最大电流；
5.4 设备
一个设备里包含了不同级别的配置，可以有一个或者多个配置。在linux中，结构体usb_device 对应着USB设备，定义在include/linux/usb.h：
/** * struct usb_device - kernel's representation of a USB device * @devnum: device number; address on a USB bus * @devpath: device ID string for use in messages (e.g., /port/...) * @route: tree topology hex string for use with xHCI * @state: device state: configured, not attached, etc. * @speed: device speed: high/full/low (or error) * @rx_lanes: number of rx lanes in use, USB 3.2 adds dual-lane support * @tx_lanes: number of tx lanes in use, USB 3.2 adds dual-lane support * @tt: Transaction Translator info; used with low/full speed dev, highspeed hub * @ttport: device port on that tt hub * @toggle: one bit for each endpoint, with ([0] = IN, [1] = OUT) endpoints * @parent: our hub, unless we're the root * @bus: bus we're part of * @ep0: endpoint 0 data (default control pipe) * @dev: generic device interface * @descriptor: USB device descriptor * @bos: USB device BOS descriptor set * @config: all of the device's configs * @actconfig: the active configuration * @ep_in: array of IN endpoints * @ep_out: array of OUT endpoints * @rawdescriptors: raw descriptors for each config * @bus_mA: Current available from the bus * @portnum: parent port number (origin 1) * @level: number of USB hub ancestors * @can_submit: URBs may be submitted * @persist_enabled: USB_PERSIST enabled for this device * @have_langid: whether string_langid is valid * @authorized: policy has said we can use it; * (user space) policy determines if we authorize this device to be * used or not. By default, wired USB devices are authorized. * WUSB devices are not, until we authorize them from user space. * FIXME -- complete doc * @authenticated: Crypto authentication passed * @wusb: device is Wireless USB * @lpm_capable: device supports LPM * @usb2_hw_lpm_capable: device can perform USB2 hardware LPM * @usb2_hw_lpm_besl_capable: device can perform USB2 hardware BESL LPM * @usb2_hw_lpm_enabled: USB2 hardware LPM is enabled * @usb2_hw_lpm_allowed: Userspace allows USB 2.0 LPM to be enabled * @usb3_lpm_u1_enabled: USB3 hardware U1 LPM enabled * @usb3_lpm_u2_enabled: USB3 hardware U2 LPM enabled * @string_langid: language ID for strings * @product: iProduct string, if present (static) * @manufacturer: iManufacturer string, if present (static) * @serial: iSerialNumber string, if present (static) * @filelist: usbfs files that are open to this device * @maxchild: number of ports if hub * @quirks: quirks of the whole device * @urbnum: number of URBs submitted for the whole device * @active_duration: total time device is not suspended * @connect_time: time device was first connected * @do_remote_wakeup: remote wakeup should be enabled * @reset_resume: needs reset instead of resume * @port_is_suspended: the upstream port is suspended (L2 or U3) * @wusb_dev: if this is a Wireless USB device, link to the WUSB * specific data for the device. * @slot_id: Slot ID assigned by xHCI * @removable: Device can be physically removed from this port * @l1_params: best effor service latency for USB2 L1 LPM state, and L1 timeout. * @u1_params: exit latencies for USB3 U1 LPM state, and hub-initiated timeout. * @u2_params: exit latencies for USB3 U2 LPM state, and hub-initiated timeout. * @lpm_disable_count: Ref count used by usb_disable_lpm() and usb_enable_lpm() * to keep track of the number of functions that require USB 3.0 Link Power * Management to be disabled for this usb_device. This count should only * be manipulated by those functions, with the bandwidth_mutex is held. * @hub_delay: cached value consisting of: * parent->hub_delay + wHubDelay + tTPTransmissionDelay (40ns) * * Will be used as wValue for SetIsochDelay requests. * * Notes: * Usbcore drivers should not set usbdev->state directly. Instead use * usb_set_device_state(). */ struct usb_device { int devnum; char devpath[16]; u32 route; enum usb_device_state state; enum usb_device_speed speed; unsigned int rx_lanes; unsigned int tx_lanes; struct usb_tt *tt; int ttport; unsigned int toggle[2]; struct usb_device *parent; struct usb_bus *bus; struct usb_host_endpoint ep0; struct device dev; struct usb_device_descriptor descriptor; struct usb_host_bos *bos; struct usb_host_config *config; struct usb_host_config *actconfig; struct usb_host_endpoint *ep_in[16]; struct usb_host_endpoint *ep_out[16]; char **rawdescriptors; unsigned short bus_mA; u8 portnum; u8 level; unsigned can_submit:1; unsigned persist_enabled:1; unsigned have_langid:1; unsigned authorized:1; unsigned authenticated:1; unsigned wusb:1; unsigned lpm_capable:1; unsigned usb2_hw_lpm_capable:1; unsigned usb2_hw_lpm_besl_capable:1; unsigned usb2_hw_lpm_enabled:1; unsigned usb2_hw_lpm_allowed:1; unsigned usb3_lpm_u1_enabled:1; unsigned usb3_lpm_u2_enabled:1; int string_langid; /* static strings from the device */ char *product; char *manufacturer; char *serial; struct list_head filelist; int maxchild; u32 quirks; atomic_t urbnum; unsigned long active_duration; #ifdef CONFIG_PM unsigned long connect_time; unsigned do_remote_wakeup:1; unsigned reset_resume:1; unsigned port_is_suspended:1; #endif struct wusb_dev *wusb_dev; int slot_id; enum usb_device_removable removable; struct usb2_lpm_parameters l1_params; struct usb3_lpm_parameters u1_params; struct usb3_lpm_parameters u2_params; unsigned lpm_disable_count; u16 hub_delay; };
其中部分参数含义如下：
- devnum; 设备号，是在USB总线的地址；
- devpath ：用于消息的设备ID字符串；
- route:用于 xHCI 的树拓扑十六进制字符串;
- state：设备状态：已配置、未连接等等；
- speed：设备速度：高速、全速、低速或错误；
- rx_lanes:正在使用的rx lanes数，USB 3.2 增加了dual-lane支持；
- tx_lanes:正在使用的tx lanes数，USB 3.2 增加了dual-lane支持；
- tt：处理传输者信息；用于低速、全速设备和高速HUB；
- ttport：位于tt HUB的设备口；
- toggle：每个端点的占一位，表明端点的方向([0] = IN, [1] = OUT)；
- parent：上一级HUB指针，除非是根节点；
- bus：总线指针；
- ep0：端点0，需要注意的是端点0是单独存放在usb_device中的；
- dev：一般的设备接口数据结构 ；
- descriptor：USB设备描述符,
- config：设备的所有配置，配置结构体里包含了配置描述符；
- actconfig：被激活的设备配置；
- ep_in：所有的USB输入端点数组；
- ep_ou：所有的USB输出端点数组；
- rawdescriptors：每个配置的raw描述符；
- bus_mA：可使用的总线电流；
- portnum：父端口号；
- level：USB HUB的层数；
- can_submit:URB可被提交标志；
- persist_enabled：USB_PERSIST使能标志；
- have_langid：string_langid存在标志；
- authorized：授权策略；
- authenticated：加密认证通过；
- discon_suspended：暂停时断开标志；
- wusb：无线USB标志；
- lpm_capable：设备支持LPM标志位；
- usb2_hw_lpm_capable：device can perform USB2 hardware LPM；
- usb2_hw_lpm_besl_capable: device can perform USB2 hardware BESL LPM；
- usb2_hw_lpm_enabled: USB2 hardware LPM is enabled ；
- usb2_hw_lpm_allowed: Userspace allows USB 2.0 LPM to be enabled；
- usb3_lpm_u1_enabled: USB3 hardware U1 LPM enabled；
- usb3_lpm_u2_enabled: USB3 hardware U2 LPM enabled；
- string_langid：字符串语言ID；
- product：产品名；
- manufacturer：厂商名；
- serial：产品串号；
- filelist：此设备打开的usbfs文件；
- maxchild; （若为HUB）接口数；
- quirks: quirks of the whole device；
- urbnum: 为整个设备提交的URBs数量；
- active_duration:设备未挂起的总时间；
- connect_time：设备首次连接的时间；
- do_remote_wakeup：远程唤醒 ；
- reset_resume:使用复位替代唤醒；
- port_is_suspended：上游端口被挂起（L2 或 U3）；
- wusb_dev：（如果为无线USB）连接到WUSB特定的数据结构；
- slot_id：xHCI 分配的槽位 ID；
- removable: Device can be physically removed from this port；
- ......
usb_device_descriptor对应于协议中的设备描述符，其定义在include/uapi/linux/usb/ch9.h：
/* USB_DT_DEVICE: Device descriptor */ struct usb_device_descriptor { __u8 bLength; __u8 bDescriptorType; __le16 bcdUSB; __u8 bDeviceClass; __u8 bDeviceSubClass; __u8 bDeviceProtocol; __u8 bMaxPacketSize0; __le16 idVendor; __le16 idProduct; __le16 bcdDevice; __u8 iManufacturer; __u8 iProduct; __u8 iSerialNumber; __u8 bNumConfigurations; } __attribute__ ((packed));
其中部分参数含义如下：
- bLength：描述符的长度；
- bDescriptorType：描述符的类型，设备描述符类型值为1；
- bcdUSB：usb版本号，比如usb2.0；
- bDeviceClass：USB分配的设备类code；
- bDeviceSubClass：USB分配的设备子类code；
- bDeviceProtocol：USB分配的协议code；
- bMaxPacketSize0：端点0最大包大小；
- idVendor：厂商编号；
- idProduct：产品编号；
- bcdDevice：设备出厂编号；
- iManufacturer：描述厂商字符串的索引；
- iProduct：描述产品字符串的索引；
- iSerialNumber：描述设备序列号字符串的索引；
- bNumConfigurations：配置描述符的个数，表示有多少个配置描述符；
5.5 URB(USB Request Block)
linux内核通过一个称为urb(usb请求块)的东西和所有的USB设备通信，urb是USB设备驱动中用来描述与USB设备通信所用的基本载体和核心数据结构，这个请求块使用struct urb结构体来形容，定义在include/linux/usb.h：
/** * struct urb - USB Request Block * @urb_list: For use by current owner of the URB. * @anchor_list: membership in the list of an anchor * @anchor: to anchor URBs to a common mooring * @ep: Points to the endpoint's data structure. Will eventually * replace @pipe. * @pipe: Holds endpoint number, direction, type, and more. * Create these values with the eight macros available; * usb_{snd,rcv}TYPEpipe(dev,endpoint), where the TYPE is "ctrl" * (control), "bulk", "int" (interrupt), or "iso" (isochronous). * For example usb_sndbulkpipe() or usb_rcvintpipe(). Endpoint * numbers range from zero to fifteen. Note that "in" endpoint two * is a different endpoint (and pipe) from "out" endpoint two. * The current configuration controls the existence, type, and * maximum packet size of any given endpoint. * @stream_id: the endpoint's stream ID for bulk streams * @dev: Identifies the USB device to perform the request. * @status: This is read in non-iso completion functions to get the * status of the particular request. ISO requests only use it * to tell whether the URB was unlinked; detailed status for * each frame is in the fields of the iso_frame-desc. * @transfer_flags: A variety of flags may be used to affect how URB * submission, unlinking, or operation are handled. Different * kinds of URB can use different flags. * @transfer_buffer: This identifies the buffer to (or from) which the I/O * request will be performed unless URB_NO_TRANSFER_DMA_MAP is set * (however, do not leave garbage in transfer_buffer even then). * This buffer must be suitable for DMA; allocate it with * kmalloc() or equivalent. For transfers to "in" endpoints, contents * of this buffer will be modified. This buffer is used for the data * stage of control transfers. * @transfer_dma: When transfer_flags includes URB_NO_TRANSFER_DMA_MAP, * the device driver is saying that it provided this DMA address, * which the host controller driver should use in preference to the * transfer_buffer. * @sg: scatter gather buffer list, the buffer size of each element in * the list (except the last) must be divisible by the endpoint's * max packet size if no_sg_constraint isn't set in 'struct usb_bus' * @num_mapped_sgs: (internal) number of mapped sg entries * @num_sgs: number of entries in the sg list * @transfer_buffer_length: How big is transfer_buffer. The transfer may * be broken up into chunks according to the current maximum packet * size for the endpoint, which is a function of the configuration * and is encoded in the pipe. When the length is zero, neither * transfer_buffer nor transfer_dma is used. * @actual_length: This is read in non-iso completion functions, and * it tells how many bytes (out of transfer_buffer_length) were * transferred. It will normally be the same as requested, unless * either an error was reported or a short read was performed. * The URB_SHORT_NOT_OK transfer flag may be used to make such * short reads be reported as errors. * @setup_packet: Only used for control transfers, this points to eight bytes * of setup data. Control transfers always start by sending this data * to the device. Then transfer_buffer is read or written, if needed. * @setup_dma: DMA pointer for the setup packet. The caller must not use * this field; setup_packet must point to a valid buffer. * @start_frame: Returns the initial frame for isochronous transfers. * @number_of_packets: Lists the number of ISO transfer buffers. * @interval: Specifies the polling interval for interrupt or isochronous * transfers. The units are frames (milliseconds) for full and low * speed devices, and microframes (1/8 millisecond) for highspeed * and SuperSpeed devices. * @error_count: Returns the number of ISO transfers that reported errors. * @context: For use in completion functions. This normally points to * request-specific driver context. * @complete: Completion handler. This URB is passed as the parameter to the * completion function. The completion function may then do what * it likes with the URB, including resubmitting or freeing it. * @iso_frame_desc: Used to provide arrays of ISO transfer buffers and to collect the transfer status for each buffer. * * This structure identifies USB transfer requests. URBs must be allocated by * calling usb_alloc_urb() and freed with a call to usb_free_urb(). * Initialization may be done using various usb_fill_*_urb() functions. URBs * are submitted using usb_submit_urb(), and pending requests may be canceled * using usb_unlink_urb() or usb_kill_urb(). * * Data Transfer Buffers: * * Normally drivers provide I/O buffers allocated with kmalloc() or otherwise * taken from the general page pool. That is provided by transfer_buffer * (control requests also use setup_packet), and host controller drivers * perform a dma mapping (and unmapping) for each buffer transferred. Those * mapping operations can be expensive on some platforms (perhaps using a dma * bounce buffer or talking to an IOMMU), * although they're cheap on commodity x86 and ppc hardware. * * Alternatively, drivers may pass the URB_NO_TRANSFER_DMA_MAP transfer flag, * which tells the host controller driver that no such mapping is needed for * the transfer_buffer since * the device driver is DMA-aware. For example, a device driver might * allocate a DMA buffer with usb_alloc_coherent() or call usb_buffer_map(). * When this transfer flag is provided, host controller drivers will * attempt to use the dma address found in the transfer_dma * field rather than determining a dma address themselves. * * Note that transfer_buffer must still be set if the controller * does not support DMA (as indicated by bus.uses_dma) and when talking * to root hub. If you have to trasfer between highmem zone and the device * on such controller, create a bounce buffer or bail out with an error. * If transfer_buffer cannot be set (is in highmem) and the controller is DMA * capable, assign NULL to it, so that usbmon knows not to use the value. * The setup_packet must always be set, so it cannot be located in highmem. * * Initialization: * * All URBs submitted must initialize the dev, pipe, transfer_flags (may be * zero), and complete fields. All URBs must also initialize * transfer_buffer and transfer_buffer_length. They may provide the * URB_SHORT_NOT_OK transfer flag, indicating that short reads are * to be treated as errors; that flag is invalid for write requests. * * Bulk URBs may * use the URB_ZERO_PACKET transfer flag, indicating that bulk OUT transfers * should always terminate with a short packet, even if it means adding an * extra zero length packet. * * Control URBs must provide a valid pointer in the setup_packet field. * Unlike the transfer_buffer, the setup_packet may not be mapped for DMA * beforehand. * * Interrupt URBs must provide an interval, saying how often (in milliseconds * or, for highspeed devices, 125 microsecond units) * to poll for transfers. After the URB has been submitted, the interval * field reflects how the transfer was actually scheduled. * The polling interval may be more frequent than requested. * For example, some controllers have a maximum interval of 32 milliseconds, * while others support intervals of up to 1024 milliseconds. * Isochronous URBs also have transfer intervals. (Note that for isochronous * endpoints, as well as high speed interrupt endpoints, the encoding of * the transfer interval in the endpoint descriptor is logarithmic. * Device drivers must convert that value to linear units themselves.) * * If an isochronous endpoint queue isn't already running, the host * controller will schedule a new URB to start as soon as bandwidth * utilization allows. If the queue is running then a new URB will be * scheduled to start in the first transfer slot following the end of the * preceding URB, if that slot has not already expired. If the slot has * expired (which can happen when IRQ delivery is delayed for a long time), * the scheduling behavior depends on the URB_ISO_ASAP flag. If the flag * is clear then the URB will be scheduled to start in the expired slot, * implying that some of its packets will not be transferred; if the flag * is set then the URB will be scheduled in the first unexpired slot, * breaking the queue's synchronization. Upon URB completion, the * start_frame field will be set to the (micro)frame number in which the * transfer was scheduled. Ranges for frame counter values are HC-specific * and can go from as low as 256 to as high as 65536 frames. * * Isochronous URBs have a different data transfer model, in part because * the quality of service is only "best effort". Callers provide specially * allocated URBs, with number_of_packets worth of iso_frame_desc structures * at the end. Each such packet is an individual ISO transfer. Isochronous * URBs are normally queued, submitted by drivers to arrange that * transfers are at least double buffered, and then explicitly resubmitted * in completion handlers, so * that data (such as audio or video) streams at as constant a rate as the * host controller scheduler can support. * * Completion Callbacks: * * The completion callback is made in_interrupt(), and one of the first * things that a completion handler should do is check the status field. * The status field is provided for all URBs. It is used to report * unlinked URBs, and status for all non-ISO transfers. It should not * be examined before the URB is returned to the completion handler. * * The context field is normally used to link URBs back to the relevant * driver or request state. * * When the completion callback is invoked for non-isochronous URBs, the * actual_length field tells how many bytes were transferred. This field * is updated even when the URB terminated with an error or was unlinked. * * ISO transfer status is reported in the status and actual_length fields * of the iso_frame_desc array, and the number of errors is reported in * error_count. Completion callbacks for ISO transfers will normally * (re)submit URBs to ensure a constant transfer rate. * * Note that even fields marked "public" should not be touched by the driver * when the urb is owned by the hcd, that is, since the call to * usb_submit_urb() till the entry into the completion routine. */ struct urb { /* private: usb core and host controller only fields in the urb */ struct kref kref; /* reference count of the URB */ int unlinked; /* unlink error code */ void *hcpriv; /* private data for host controller */ atomic_t use_count; /* concurrent submissions counter */ atomic_t reject; /* submissions will fail */ /* public: documented fields in the urb that can be used by drivers */ struct list_head urb_list; /* list head for use by the urb's * current owner */ struct list_head anchor_list; /* the URB may be anchored */ struct usb_anchor *anchor; struct usb_device *dev; /* (in) pointer to associated device */ struct usb_host_endpoint *ep; /* (internal) pointer to endpoint */ unsigned int pipe; /* (in) pipe information */ unsigned int stream_id; /* (in) stream ID */ int status; /* (return) non-ISO status */ unsigned int transfer_flags; /* (in) URB_SHORT_NOT_OK | ...*/ void *transfer_buffer; /* (in) associated data buffer */ dma_addr_t transfer_dma; /* (in) dma addr for transfer_buffer */ struct scatterlist *sg; /* (in) scatter gather buffer list */ int num_mapped_sgs; /* (internal) mapped sg entries */ int num_sgs; /* (in) number of entries in the sg list */ u32 transfer_buffer_length; /* (in) data buffer length */ u32 actual_length; /* (return) actual transfer length */ unsigned char *setup_packet; /* (in) setup packet (control only) */ dma_addr_t setup_dma; /* (in) dma addr for setup_packet */ int start_frame; /* (modify) start frame (ISO) */ int number_of_packets; /* (in) number of ISO packets */ int interval; /* (modify) transfer interval * (INT/ISO) */ int error_count; /* (return) number of ISO errors */ void *context; /* (in) context for completion */ usb_complete_t complete; /* (in) completion routine */ struct usb_iso_packet_descriptor iso_frame_desc[0]; /* (in) ISO ONLY */ };
其中：
- kref：urb引用计数；
- hcpriv：主机控制器私有数据；
- use_count：并发传输计数；
- reject：传输将失效；
- urb_list：链表头；
- dev：关联的usb设备；
- ep：指向端点的数据结构；
- pipe：指向端点管道；
- status：urb的当前状态；当status=0时，表示数据被成功的收到/发送；
- transfer_buffer：发送到设备或从设备接收数据的缓冲区；
- transfer_dma：用来以DMA方式向设备传输数据的缓冲区；
- actual_length：urb结束后，发送或接收数据的实际长度；
- setup_package：指向控制urb设置数据包的指针；
- setup_dma：控制urb的设置数据包的DMA缓冲区；
- start_frame：等待传输中用于设置或返回初始帧；
- number_of_package：等时传输找那个等时缓冲区数量；
- interval：urb被轮询到的事件间隔（对中断和等时urb有效）；
- error_count：等时传输错误数量：
- context：complete函数上下文；
- complete：当urb被完全传输或发生错误时，被调用；
- iso_frame_desc：单个urb一次可定义多个等时传输时，描述各个等时传输。
urb典型的生命周期如下：
- usb设备驱动程序创建并初始化一个访问特定usb设备特定端点的urb，并提交给usb core；
- usb core 提交该urb到usb主控制器驱动程序；
- usb主控制器驱动程序根据 urb 描述的信息，来访问usb设备；
- 当设备访问结束后，usb主控制器驱动程序通知 usb core（调用这个函数usb_complete_t complete;）然后其再通知usb设备驱动程序。
六、开发板启动
由于内核自带了USB驱动，所以我们在开发板上接一个USB鼠标，然后启动开发板，串口就会输出如下信息：
usb 1-1: new low-speed USB device number 2 using s3c2410-ohci
可以看到linux内核已经识别到我们的USB鼠标设备了，那linux内核是如何设备到我们的USB设备的呢，这将在后面章节介绍。
参考文章
[4]常见硬件通信(SPI、I2C、CAN、USB、UART)协议介绍
[5]USART(RS232/422/485）、I2C、SPI、CAN、USB总线
[6]USB总线-USB协议简介（一）(转载)
[7]图解USB标准之架构概览
[8]USB驱动框架
[9]USB_4大描述符
