arm-linux下usb驱动的结构和相关函数

几个重要的结构
struct--接口

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 */

         int minor;                      /* minor number this interface is
                                          * bound to */
         enum usb_interface_condition condition;         /* state of binding */
         unsigned is_active:1;           /* the interface is not suspended */
         unsigned needs_remote_wakeup:1; /* driver requires remote wakeup */

         struct device dev;              /* interface specific device info */
         struct device *usb_dev;         /* pointer to the usb class's device, if any */
         int pm_usage_cnt;               /* usage counter for autosuspend */
};
结构体struct usb_host_interface就代表一个设置

struct usb_interface中的struct usb_host_interface *cur_altsetting成员，表示当前正在使用的设置

struct--设置

struct usb_host_interface
{
         struct usb_interface_descriptor desc;//usb描述符，主要有四种usb描述符，设备描述符，配置描述符，接口描述符和端点描述符，协议里规定一个usb设备是必须支持这四大描述符的。
                                 //usb描述符放在usb设备的eeprom里边
         /* array of desc.bNumEndpoint endpoints associated with this
          * interface setting. these will be in no particular order.
          */
         struct usb_host_endpoint *endpoint;//这个设置所使用的端点

         char *string;           /* iInterface string, if present */
         unsigned char *extra;   /* Extra descriptors */关于额外描述符
         int extralen;
};
具体到接口描述符，它当然就是描述接口本身的信息的。一个接口可以有多个设置，使用不同的设置，描述接口的信息会有些不同，所以接口描述符并没有放在struct usb_interface结构里，而是放在表示接口设置的struct usb_host_interface结构里。

struct--接口描述符

struct usb_interface_descriptor
{
         __u8  bLength;//接口描述符长度
         __u8 bDescriptorType;//接口描述符类型

         __u8 bInterfaceNumber;//接口号。每个配置可以包含多个接口，这个值就是它们的索引值。
         __u8 bAlternateSetting;//接口使用的是哪个可选设置。协议里规定，接口默认使用的设置总为0号设置。
         __u8 bNumEndpoints;//接口拥有的端点数量。这里并不包括端点0，因为端点0是控制传输，是所有的设备都必须提供的，所以这里就没必要多此一举的包括它了。对于hub，因为它的传输是中断传输，所以此值为1（不包括端点0）
         __u8 bInterfaceClass;
         __u8 bInterfaceSubClass;//对于hub，这个值是零
         __u8 bInterfaceProtocol;
         __u8 iInterface;
} __attribute__ ((packed));

struct--端点

struct usb_host_endpoint
{
         struct usb_endpoint_descriptor desc;
         struct list_head                urb_list;//端点要处理的urb队列.urb是usb通信的主角，设备中的每个端点都可以处理一个urb队列.要想和你的usb通信，就得创建一个urb，并且为它赋好值，
                                   //交给咱们的usb core，它会找到合适的host controller，从而进行具体的数据传输
         void                            *hcpriv;//这是提供给HCD（host controller driver）用的
         struct ep_device                *ep_dev;        /* For sysfs info */

         unsigned char *extra;   /* Extra descriptors */
         int extralen;
};

struct--端点描述符

struct usb_endpoint_descriptor {
         __u8 bLength;
         __u8 bDescriptorType;//接口类型

         __u8 bEndpointAddress;//它的bits 0~3表示的就是端点号，USB_ENDPOINT_NUMBER_MASK；bit7是方向，USB_ENDPOINT_DIR_MASK
         __u8 bmAttributes;//bmAttributes，属性，总共8位，其中bit1和bit0 共同称为Transfer Type,即传输类型， 00 表示控制，01 表示等时，10 表示批量，11 表示中断。USB_ENDPOINT_XFERTYPE_MASK
         __le16 wMaxPacketSize;//端点一次可以处理的最大字节数，如果你发送的数据量大于端点的这个值，也会分成多次一次一次来传输
         __u8 bInterval;//USB是轮询式的总线，这个值表达了端点一种美好的期待，希望主机轮询自己的时间间隔，但实际上批准不批准就是host的事了

         /* NOTE: these two are _only_ in audio endpoints. */
         /* use USB_DT_ENDPOINT*_SIZE in bLength, not sizeof. */
         __u8 bRefresh;
         __u8 bSynchAddress;
} __attribute__ ((packed));
注：0号端点没有自己的端点描述符

struct--设备

struct usb_device {
337         int             devnum;         //devnum只是usb设备在一条usb总线上的编号.一条usb_bus_type类型的总线上最多可以连上128个设备
338         char            devpath [16];   /* Use in messages: /port/port/...*/  //对于root hub.会将dev->devpath[0]=’0’
339         enum usb_device_state   state;  //设备的状态Attached，Powered，Default，Address，Configured，Suspended；
                               //Attached表示设备已经连接到usb接口上了，是hub检测到设备时的初始状态。那么这里所谓的USB_STATE_NOTATTACHED就是表示设备并没有Attached。
                               //Address状态表示主机分配了一个唯一的地址给设备，此时设备可以使用缺省管道响应主机的请求
                               //Configured状态表示设备已经被主机配置过了，也就是协议里说的处理了一个带有非0值的SetConfiguration()请求，此时主机可以使用设备提供的所有功能
                               //Suspended挂起状态，为了省电，设备在指定的时间内，3ms吧，如果没有发生总线传输，就要进入挂起状态。此时，usb设备要自己维护包括地址、配置在内的信息             

340         enum usb_device_speed   speed;  /* high/full/low (or error) */
341
342         struct usb_tt   *tt;            //如果一个高速设备里有这么一个TT，那么就可以连接低速/全速设备，如不然，那低速/全速设备没法用，只能连接到OHCI/UHCI那边出来的hub口里。
343         int             ttport;         //如果一个高速设备里有这么一个TT，那么就可以连接低速/全速设备，如不然，那低速/全速设备没法用，只能连接到OHCI/UHCI那边出来的hub口里。
344
345         unsigned int toggle[2];         /* one bit for each endpoint     //他实际上就是一个位图.IN方向的是toggle[0].OUT方向的是toggle[1].其实,这个数组中的每一位表示ep的toggle值
346                                          * ([0] = IN, [1] = OUT) */它里面的每一位表示的就是每个端点当前发送或接收的数据包是DATA0还是DATA1
347
348         struct usb_device *parent;      /* our hub, unless we're the root */
                              //USB设备是从Root Hub开始，一个一个往外面连的，比如Root Hub有4个口，每个口连一个USB设备，比如其中有一个是Hub，那么这个Hub有可以继续有多个口，于是一级一级的往下连，
                               //最终连成了一棵树。
349         struct usb_bus *bus;            /* Bus we're part of */设备所在的总线
350         struct usb_host_endpoint ep0;   //端点0的特殊地位决定了她必将受到特殊的待遇，在struct usb_device对象产生的时候它就要初始化
351
352         struct device dev;              /* Generic device interface */嵌入到struct usb_device结构里的struct device结构
353
354         struct usb_device_descriptor descriptor;/* Descriptor */设备描述符，此结构体的bMaxPacketSize0 filed保存了端点0的maximum packet size
355         struct usb_host_config *config; //设备拥有的所有配置
356
357         struct usb_host_config *actconfig;//设备正在使用的配置
358         struct usb_host_endpoint *ep_in[16];//ep_in[16]，359行，ep_out[16]，除了端点0，一个设备即使在高速模式下也最多只能再有15个IN端点和15个OUT端点，端点0太特殊了，
359         struct usb_host_endpoint *ep_out[16];//对应的管道是Message管道，又能进又能出特能屈能伸的那种，所以这里的ep_in和ep_out数组都有16个值
360
361         char **rawdescriptors;          /* Raw descriptors for each config */
362
363         unsigned short bus_mA;          /* Current available from the bus */这个值是在host controller的驱动程序中设置的，通常来讲，计算机的usb端口可以提供500mA的电流
364         u8 portnum;                     //不管是root hub还是一般的hub，你的USB设备总归要插在一个hub的端口上才能用，portnum就是那个端口号。
365         u8 level;                       //层次，也可以说是级别，表征usb设备树的级连关系。Root Hub的level当然就是0，其下面一层就是level 1，再下面一层就是level 2，依此类推
366
367         unsigned discon_suspended:1;    /* Disconnected while suspended */
368         unsigned have_langid:1;         /* whether string_langid is valid */
369         int string_langid;              /* language ID for strings */
370
371         /* static strings from the device */
372         char *product;                  /* iProduct string, if present */
373         char *manufacturer;             /* iManufacturer string, if present */
374         char *serial;                   /* iSerialNumber string, if present */
375                                 //分别用来保存产品、厂商和序列号对应的字符串描述符信息
376         struct list_head filelist;
377 #ifdef CONFIG_USB_DEVICE_CLASS
378         struct device *usb_classdev;
379 #endif
380 #ifdef CONFIG_USB_DEVICEFS
381         struct dentry *usbfs_dentry;    /* usbfs dentry entry for the device */
382 #endif
383         /*
384          * Child devices - these can be either new devices
385          * (if this is a hub device), or different instances
386          * of this same device.
387          *
388          * Each instance needs its own set of data structures.
389          */
390
391         int maxchild;                   /* Number of ports if hub */
392         struct usb_device *children[USB_MAXCHILDREN];
393
394         int pm_usage_cnt;               /* usage counter for autosuspend */
395         u32 quirks;                     //quirk就是用来判断这些有毛病的产品啥毛病的
396
397 #ifdef CONFIG_PM
398         struct delayed_work autosuspend; /* for delayed autosuspends */
399         struct mutex pm_mutex;          /* protects PM operations */
400
401         unsigned long last_busy;        /* time of last use */
402         int autosuspend_delay;          /* in jiffies */
403
404         unsigned auto_pm:1;             /* autosuspend/resume in progress */
405         unsigned do_remote_wakeup:1;    /* remote wakeup should be enabled */
406         unsigned autosuspend_disabled:1; /* autosuspend and autoresume */
407         unsigned autoresume_disabled:1;  /*  disabled by the user */
408 #endif
409 };

struct--设备描述符

struct usb_device_descriptor {
205         __u8  bLength;       
206         __u8  bDescriptorType;
207
208         __le16 bcdUSB;            //USB spec的版本号，一个设备如果能够进行高速传输，那么它设备描述符里的bcdUSB这一项就应该为0200H。
209         __u8  bDeviceClass;            //
210         __u8  bDeviceSubClass;
211         __u8  bDeviceProtocol;        //为了设置tt。full/low speed的hub的bDeviceProtocol是0；对于high speed的hub,其bDeviceProtocol为1表示是single tt，为2表示是multiple tt；
212         __u8  bMaxPacketSize0;        //端点0一次可以处理的最大字节数
213         __le16 idVendor;            //厂商id
214         __le16 idProduct;            //产品id
215         __le16 bcdDevice;            //设备版本号
216         __u8  iManufacturer;
217         __u8  iProduct;
218         __u8  iSerialNumber;
219         __u8  bNumConfigurations;    //设备当前速度模式下支持的配置数量。有的设备可以在多个速度模式下操作，这里包括的只是当前速度模式下的配置数目，不是总的配置数目
220 } __attribute__ ((packed));
221
222 #define USB_DT_DEVICE_SIZE              18
注：为什么端点0的属性bMaxPacketSize0要放到设备描述符里边呢 ？
首先表明了这是一个共性的东西。
前面说端点的时候说了端点0并没有一个专门的端点描述符，因为不需要，基本上它所有的特性都在spec里规定好了的，然而，别忘了这里说的是“基本上”，有一个特性则是不一样的，这叫做maximum packet size，每个端点都有这么一个特性，即告诉你该端点能够发送或者接收的包的最大值。对于通常的端点来说，这个值被保存在该端点描述符中的wMaxPacketSize这一个field，而对于端点0就不一样了，由于它自己没有一个描述符，而每个设备又都有这么一个端点，所以这个信息被保存在了设备描述符里，所以我们在设备描述符里可以看到这么一项，bMaxPacketSize0。而且spec还规定了，这个值只能是8，16，32或者64这四者之一，如果一个设备工作在高速模式，这个值还只能是64，如果是工作在低速模式，则只能是8，取别的值都不行。

struct--配置

struct usb_host_config {
245         struct usb_config_descriptor    desc;
246
247         char *string;           /* iConfiguration string, if present */
248         /* the interfaces associated with this configuration,
249          * stored in no particular order */
250         struct usb_interface *interface[USB_MAXINTERFACES];            //配置所包含的接口，这个数组的顺序未必是按照配置里接口号的顺序
251
252         /* Interface information available even when this is not the
253          * active configuration */
254         struct usb_interface_cache *intf_cache[USB_MAXINTERFACES];        //usb接口的缓存
255
256         unsigned char *extra;   /* Extra descriptors */
257         int extralen;
258 };

struct--配置描述符

258 struct usb_config_descriptor {
259         __u8  bLength;
260         __u8  bDescriptorType;        //这里的值并不仅仅可以为USB_DT_CONFIG，还可以为USB_DT_OTHER_SPEED_CONFIG
261
262         __le16 wTotalLength;        //使用GET_DESCRIPTOR请求从设备里获得配置描述符信息时，返回的数据长度
263         __u8  bNumInterfaces;        //这个配置包含的接口数量
264         __u8  bConfigurationValue;    //对于拥有多个配置的幸运设备来说，可以拿这个值为参数，使用SET_CONFIGURATION请求来改变正在被使用的 USB配置，bConfigurationValue就指明了将要激活哪个配置。
                            //咱们的设备虽然可以有多个配置，但同一时间却也只能有一个配置被激活。捎带着提一下，SET_CONFIGURATION请求也是标准的设备请求之一，专门用来设置设备的配置。
265         __u8  iConfiguration;        //描述配置信息的字符串描述符的索引值
266         __u8  bmAttributes;        //这个字段表征了配置的一些特点，比如bit 6为1表示self-powered，bit 5为1表示这个配置支持远程唤醒。另外，它的bit 7必须为1
267         __u8  bMaxPower;            //设备正常运转时，从总线那里分得的最大电流值，以2mA为单位。设备可以使用这个字段向hub表明自己需要的的电流，但如果设备需求过于旺盛，请求的超出了hub所能给予的，hub就会直接拒绝
                            //还记得struct usb_device结构里的bus_mA吗？它就表示hub所能够给予的。计算机的usb端口可以提供最多500mA的电流
268 } __attribute__ ((packed));

struct--usb接口的缓存

struct usb_interface_cache {
194         unsigned num_altsetting;        /* number of alternate settings */
195         struct kref ref;                /* reference counter */
196
197         /* variable-length array of alternate settings for this interface,
198          * stored in no particular order */
199         struct usb_host_interface altsetting[0];
200 };


struct--hub描述符

struct usb_hub_descriptor {
    __u8  bDescLength;
    __u8  bDescriptorType;
    __u8  bNbrPorts;        //Number of downstream facing ports that this hub supports,就是说这个hub所支持的下行端口，这个值不能比31大
    __le16 wHubCharacteristics;    //它记录了很多信息
    __u8  bPwrOn2PwrGood;
    __u8  bHubContrCurrent;        //bHubContrCurrent是Hub控制器的最大电流需求
        /* add 1 bit for hub status change; round to bytes */
    __u8  DeviceRemovable[(USB_MAXCHILDREN + 1 + 7) / 8];//用来判断这个端口连接的设备是否是可以移除的,每一个bit代表一个端口,如果该bit为0,则说明可以被移除,为1,就说明不可以移除
    __u8  PortPwrCtrlMask[(USB_MAXCHILDREN + 1 + 7) / 8];
} __attribute__ ((packed));

struct--hub结构体

struct usb_hub {
    struct device        *intfdev;    /* the "interface" device */
    struct usb_device    *hdev;
    struct kref        kref;
    struct urb        *urb;        /* for interrupt polling pipe */

    /* buffer for urb ... with extra space in case of babble */
    char            (*buffer)[8];
    dma_addr_t        buffer_dma;    /* DMA address for buffer */
    union {
        struct usb_hub_status    hub;
        struct usb_port_status    port;
    }            *status;    /* buffer for status reports */
    struct mutex        status_mutex;    /* for the status buffer */

    int            error;        /* last reported error */
    int            nerrors;    /* track consecutive errors */

    struct list_head    event_list;    /* hubs w/data or errs ready */
    unsigned long        event_bits[1];    /* status change bitmask */
    unsigned long        change_bits[1];    /* ports with logical connect status change */
    unsigned long        busy_bits[1];    /* ports being reset or
                        //resumed */这个flag只有在reset和resume的函数内部才会设置，所以可以通过测试busy_bits的相应位来检测某个端口是否在执行reset或resume操作。
#if USB_MAXCHILDREN > 31 /* 8*sizeof(unsigned long) - 1 */
#error event_bits[] is too short!
#endif

    struct usb_hub_descriptor *descriptor;    /* class descriptor */
    struct usb_tt        tt;        /* Transaction Translator */

    unsigned        mA_per_port;     //提供给每一个port的电流，一般为500mA，但可能会因为hub提供不了这么大的电流或者host controller那边提供不了这么大的电流，而导致不足500mA

    unsigned        limited_power:1; //对于host controller那边限制了电流的情况下，这个值被设置为1
    unsigned        quiescing:1;    //quiescing是停止的意思,在reset的时候我们会设置它为1,在suspend的时候我们也会把它设置为1,一旦把它设置成了1,那么hub驱动程序就不会再提交任何URB
    unsigned        activating:1;    //如果activating为1,那么hub驱动程序就会给每个端口发送一个叫做Get Port Status的请求,通常情况下,hub驱动只有在一个端口发生了状态变化的情况下才会去发送
                         //Get Port Status从而去获得端口的状态。正常情况下，quiescing和activating都应该为0.
    unsigned        disconnected:1;

    unsigned        has_indicators:1;
    u8            indicator[USB_MAXCHILDREN];
    struct delayed_work    leds;
};


struct--usb_bus结构体

struct usb_bus {
    struct device *controller;    /* host/master side hardware */
    int busnum;            /* Bus number (in order of reg) */
    char *bus_name;            /* stable id (PCI slot_name etc) */
    u8 uses_dma;            /* Does the host controller use DMA? */
    u8 otg_port;            /* 0, or number of OTG/HNP port */
    unsigned is_b_host:1;        /* true during some HNP roleswitches */
    unsigned b_hnp_enable:1;    /* OTG: did A-Host enable HNP? */

    int devnum_next;        /* Next open device number in //          在总线初始化的时候,其devnum_next被设置为1
                     * round-robin allocation */

    struct usb_devmap devmap;    /* device address allocation map */ 每条总线设有一个地址映射表
    struct usb_device *root_hub;    /* Root hub */
    struct list_head bus_list;    /* list of busses */

    int bandwidth_allocated;    /* on this bus: how much of the time
                     * reserved for periodic (intr/iso)
                     * requests is used, on average?
                     * Units: microseconds/frame.
                     * Limits: Full/low speed reserve 90%,
                     * while high speed reserves 80%.
                     */
    int bandwidth_int_reqs;        /* number of Interrupt requests */
    int bandwidth_isoc_reqs;    /* number of Isoc. requests */

#ifdef CONFIG_USB_DEVICEFS
    struct dentry *usbfs_dentry;    /* usbfs dentry entry for the bus */
#endif
    struct device *dev;        /* device for this bus */

#if defined(CONFIG_USB_MON)
    struct mon_bus *mon_bus;    /* non-null when associated */
    int monitored;            /* non-zero when monitored */
#endif
};

struct--usb_devmap

struct usb_devmap {
    unsigned long devicemap[128 / (8*sizeof(unsigned long))];
};


几个重要的函数分析

usb_hub_init所做的工作：
代码原型：
    ...
    khubd_task = kthread_run(hub_thread, NULL, "khubd");
    ...
建立一个内核级线程:hub_thread

hub_thread所做的工作：
代码原型：
    do {
        hub_events();
        wait_event_freezable(khubd_wait,
                !list_empty(&hub_event_list) ||
                kthread_should_stop());    //一般来说，只要hub_event_list不为空，就会一直调用hub_events()函数,hub_event_list将所有的usb_hub的list_head类型的event_list对象连在一起
        } while (!kthread_should_stop() || !list_empty(&hub_event_list));

调用规则：
hub_events函数所做的工作：
对每个端口号（共计bNbrPorts个端口，bNbrPorts这个值从hub描述符里边得到，因为此值描述了hub所用用的端口的情况），假如满足下列条件则调用hub_port_connect_change:
1.连接有变化
2.端口本身重新使能,即所谓的enable,这种情况通常就是为了对付电磁干扰的,正如我们前面的判断中所说的那样
3.在复位一个设备的时候发现其描述符变了,这通常对应的是硬件本身有了升级.很显然,第一种情况是真正的物理变化,后两者就算是逻辑变化
代码模型如下：
    for (i = 1; i <= hub->descriptor->bNbrPorts; i++) {
        ...
        if (connect_change) //表示满足如上条件之一
                hub_port_connect_change(hub, i,
                        portstatus, portchange);
        ...   
    ｝
个人感觉，此处的i没有什么实际意义，只是为了保证有“几个端口，才能接几个设备”这样的一个逻辑。虽然说usb_bus最多可以接128个设备，hub最多可以接31个设备，但是，假如hub没有那么多的端口，你怎么接设备？

hub_port_connect_change的调用规则：
代码模型：
    for (i = 0; i < SET_CONFIG_TRIES; i++)            //在此驱动里边，SET_CONFIG_TRIES=4，新策略尝试两次，旧策略尝试两次
    {   
        ...
        udev = usb_alloc_dev(hdev, hdev->bus, port1);
        udev->speed = USB_SPEED_UNKNOWN;
        //进行一些必要的设置
        choose_address(udev);                        //设置了udev->devnum
        //错误判断
        status = hub_port_init(hub, udev, port1, i);        //先进行两次新的策略(i=0和=1时),如果不行就再进行两次旧的策略(i=2和i=3时).所有这一切只有一个目的,就是为了获得设备的描述符
                                            //设置了udev->tt、udev->ttport和udev->ep0.desc.wMaxPacketSize,设置udev->status= USB_STATE_ADDRESS
        ...   
    ｝

hub_port_init功能：
    hub_port_init里边为udev->tt和udev->ttport和udev->ep0.desc.wMaxPacketSize赋了值,设置udev->status= USB_STATE_ADDRESS.
    它的长篇大论只是为了讨论如何确定赋给udev->ep0.desc.wMaxPacketSize的值,这个值是由设备描述符的bMaxPacketSize0字段确定的.每调用一次hub_port_init，使用一种策略。
hub_port_init的原型：
    static int  hub_port_init (struct usb_hub *hub, struct usb_device *udev, int port1,int retry_counter)
    ｛
    ...
    retval = hub_port_reset(hub, port1, udev, delay);            //将hub hub上的udev设备重启，并设置udev->speed的值
    ...
    //根据udev->speed的值设置udev->ep0.desc.wMaxPacketSize的值,但此处的值仅仅是个猜测,最终端点0的maxinum packet size的值要根据设备描述符的bMaxPacketSize0字段得到
    //设置udev->tt和udev->ttport的值
    for (i = 0; i < GET_DESCRIPTOR_TRIES; (++i, msleep(100)))        //GET_DESCRIPTOR_TRIES=2，是为了多执行几次保证正确
    {
        if (USE_NEW_SCHEME(retry_counter))                     //USE_NEW_SCHEME判断使用什么策略，USB_NEW_SCHEME(i)将在i为0和1的时候为1,在i为2和3的时候为0
        {                                        //当retry_counter=0,1时，USE_NEW_SCHEME(retry_counter)=1，表示使用新策略；
                                                //当retry_counter=2，3时，USE_NEW_SCHEME(retry_counter)=0，表示使用旧策略
#define GET_DESCRIPTOR_BUFSIZE    64                           
            buf = kmalloc(GET_DESCRIPTOR_BUFSIZE, GFP_NOIO);    //首先定义一个struct usb_device_descriptor的指针buf，然后申请64个字节的空间
            for (j = 0; j < 3; ++j) {
                buf->bMaxPacketSize0 = 0;
                r = usb_control_msg(udev, usb_rcvaddr0pipe(),    //发送一个64字节的控制传输的请求
                    USB_REQ_GET_DESCRIPTOR, USB_DIR_IN,
                    USB_DT_DEVICE << 8, 0,
                    buf, GET_DESCRIPTOR_BUFSIZE,
                    USB_CTRL_GET_TIMEOUT);
                switch (buf->bMaxPacketSize0) {
                case 8: case 16: case 32: case 64: case 255:
                    if (buf->bDescriptorType ==
                            USB_DT_DEVICE) {
                        r = 0;
                        break;
                    }
                    /* FALL THROUGH */
                default:
                    if (r == 0)
                        r = -EPROTO;
                    break;
                }
                if (r == 0)
                    break;
            }
            udev->descriptor.bMaxPacketSize0 = buf->bMaxPacketSize0;//得到udev->descriptor.bMaxPacketSize0
            kfree(buf);
            retval = hub_port_reset(hub, port1, udev, delay);    //将hub hub上的udev设备重启，并设置udev->speed的值
#undef GET_DESCRIPTOR_BUFSIZE
        }
        for (j = 0; j < SET_ADDRESS_TRIES; ++j) {                //SET_ADDRESS_TRIES=2，多试几次
            retval = hub_set_address(udev, devnum);            //告知设备它的总线地址，设置udev->status= USB_STATE_ADDRESS
            if (retval >= 0)                            //表示正确，退出循环
                break;
            msleep(200);
        }
        if (retval < 0) {
            dev_err(&udev->dev,
                "device not accepting address %d, error %d\n",    //我的驱动打印出了这个信息，表示hub_set_address函数出错了
                devnum, retval);
            goto fail;
        }
        if (USE_NEW_SCHEME(retry_counter))                //假如这是新策略，执行到这里，表示得到了正确的设备描述符，退出大循环
            break;
        retval = usb_get_device_descriptor(udev, 8);            //执行到这里，说明使用的是旧策略，先一次读取8个字节
        ...                                        //假如返回出错，那么go to fail吧，两种策略都失败了
           
    ｝                                            //到此为止，应该成功读取到了设备描述符，并可以从中得到bMaxPacketSize0的值
    //根据bMaxPacketSize0的值重新设置udev->ep0.desc.wMaxPacketSize的值
    retval = usb_get_device_descriptor(udev, USB_DT_DEVICE_SIZE);     //再一次读取设备描述符来测试可不可以正确读取，注意这次读取的长度为USB_DT_DEVICE_SIZE
                                                //由于知道了endpoint 0的max packet size，所以可以进行正常的控制传输了
    //假如retval == sizeof(udev->descriptor),那么说明控制传输ok了，也验证了端点0的maxinum packet size的值是正确的，那么happy的返回把
    }










hub_port_reset功能：

hub_port_reset的原型：
static int hub_port_reset(struct usb_hub *hub, int port1,
                struct usb_device *udev, unsigned int delay)
{
    int i, status;

    /* Block EHCI CF initialization during the port reset.
     * Some companion controllers don't like it when they mix.
     */
    down_read(&ehci_cf_port_reset_rwsem);

    /* Reset the port */
    for (i = 0; i < PORT_RESET_TRIES; i++) {                         //PORT_RESET_TRIES=5
        status = set_port_feature(hub->hdev,                    //发送一个hub类型的控制请求,设置一个feature，传递进来的feature是USB_PORT_FEAT_RESET，即对应于usb spec中的reset
                port1, USB_PORT_FEAT_RESET);
        if (status)
            dev_err(hub->intfdev,
                    "cannot reset port %d (err = %d)\n",
                    port1, status);
        else {
            status = hub_port_wait_reset(hub, port1, udev, delay);    //取得端口的状态，然后判断reset是否成功，如果成功，则根据端口的状态字设置udev->speed的值,否则，出错
            if (status && status != -ENOTCONN)
                dev_dbg(hub->intfdev,
                        "port_wait_reset: err = %d\n",
                        status);
        }
                                                    //在我的例子理，hub_port_wait_reset返回了-110
        /* return on disconnect or reset */
        switch (status) {
        case 0:
            /* TRSTRCY = 10 ms; plus some extra */
            msleep(10 + 40);
              udev->devnum = 0;    /* Device now at address 0 */
            /* FALL THROUGH */
        case -ENOTCONN:                                    //ENOTCONN=107,transport endpoint is not connected
        case -ENODEV:                                    //ENODEV=19,no such device
            clear_port_feature(hub->hdev,                        //status的值为0,-107,-19的时候才会执行clear_port_feature和usb_set_device
                port1, USB_PORT_FEAT_C_RESET);
            /* FIXME need disconnect() for NOTATTACHED device */   
            usb_set_device_state(udev, status                    //status为0的情况,属于正常情况,从这时候开始,struct usb_device结构体的状态就将记录为USB_STATE_DEFAULT
                    ? USB_STATE_NOTATTACHED
                    : USB_STATE_DEFAULT);                   
            goto done;                                   
        }

        dev_dbg (hub->intfdev,                                //status的值不为0,-107,-19的时候才会执行到这里，比如，我的驱动里为-110
            "port %d not enabled, trying reset again...\n",
            port1);
        delay = HUB_LONG_RESET_TIME;                           
    }

    dev_err (hub->intfdev,                                    //假如执行到这里，说明几次尝试重启都失败了
        "Cannot enable port %i.  Maybe the USB cable is bad?\n",
        port1);

 done:
    up_read(&ehci_cf_port_reset_rwsem);
    return status;
}


hub_port_wait_reset功能：
取得端口的状态，然后判断reset是否成功，如果成功，则根据端口的状态字设置udev->speed的值,否则，出错
hub_port_wait_reset函数原型：
static int hub_port_wait_reset(struct usb_hub *hub, int port1,
                struct usb_device *udev, unsigned int delay)
{
        //超时重试控制
        ret = hub_port_status(hub, port1, &portstatus, &portchange);    //得到端口的状态
        ..
        if (!(portstatus & USB_PORT_STAT_CONNECTION))                //如果在reset期间设备都被撤掉了,那就返回吧
            return -ENOTCONN;
        if ((portchange & USB_PORT_STAT_C_CONNECTION))                //如果又一次汇报说有设备插入,那就是见鬼了.返回错误
            return -ENOTCONN;

        if (!(portstatus & USB_PORT_STAT_RESET) &&
            (portstatus & USB_PORT_STAT_ENABLE)) {                //reset真正完成以后,status就应该是enabled，所以if如果满足就说明reset好了
            if (hub_is_wusb(hub))
                udev->speed = USB_SPEED_VARIABLE;
            else if (portstatus & USB_PORT_STAT_HIGH_SPEED)
                udev->speed = USB_SPEED_HIGH;
            else if (portstatus & USB_PORT_STAT_LOW_SPEED)
                udev->speed = USB_SPEED_LOW;
            else
                udev->speed = USB_SPEED_FULL;
            return 0;                                    //reset好了以后，设置udev->speed字段，然后返回
                                                    //问题：怎么能从端口的状态里边得到设备的speed字段呢？有点疑惑
        }
        //超时重试控制
}
hub_port_status其实就是调用了get_port_status(hub->hdev, port1, &hub->status->port);
get_port_status的实现如下：
static int get_port_status(struct usb_device *hdev, int port1,
        struct usb_port_status *data)
{
    int i, status = -ETIMEDOUT;         //ETIMEDOUT=110

    for (i = 0; i < USB_STS_RETRIES && status == -ETIMEDOUT; i++) {
        status = usb_control_msg(hdev, usb_rcvctrlpipe(hdev, 0),
            USB_REQ_GET_STATUS, USB_DIR_IN | USB_RT_PORT, 0, port1,
            data, sizeof(*data), USB_STS_TIMEOUT);
    }
    return status;
}
在我的驱动里边，这个函数出错，返回值是-110,

关于usb驱动的若干基本知识：

1.什么是tt电路？
知道tt干嘛的吗?tt叫做transaction translator.你可以把它想成一块特殊的电路,是hub里面的电路,确切的说是高速hub中的电路,我们知道usb设备有三种速度的,分别是low speed,full speed,high speed.即所谓的低速/全速/高速,抗日战争那会儿,这个世界上只有low speed/full speed的设备,没有high speed的设备,后来解放后,国民生产力的大幅度提升催生了一种high speed的设备,包括主机控制器,以前只有两种接口的,OHCI/UHCI,这都是在usb spec 1.0的时候,后来2.0推出了EHCI,高速设备应运而生.Hub也有高速hub和过去的hub,但是这里就有一个兼容性问题了,高速的hub是否能够支持低速/全速的设备呢?一般来说是不支持的,于是有了一个叫做TT的电路,它就负责高速和低速/全速的数据转换,于是,如果一个高速设备里有这么一个TT,那么就可以连接低速/全速设备,如不然,那低速/全速设备没法用,只能连接到OHCI/UHCI那边出来的hub口里。tt有两种,一种是single tt,一种是multi tt.前者表示整个hub就是一个TT,而multi tt表示每个端口都配了一个TT.大多数hub是single TT,因为一个hub一个TT就够了,国家资源那么紧张,何必铺张浪费.使用single TT就是支持国家反腐倡廉!
2.
我们知道usb-storage里面最常见的传输方式就是control/bulk传输,而对于hub,它的传输方式就是control/interrupt,而最有特色的正是它的中断传输.
3.
USB_PORT_STAT_CONNECTION的意思的确是表征是否有设备连接在这个端口上,我们不妨假设有,那么portstatus和它相与的结果就是1,在usb spec里面,这一位叫做Current Connect Status位,于是这里我们会看到connect_change被设置成了1.而接下来,USB_PORT_STAT_C_CONNECTION则是表征这个端口的Current Connect Status位是否有变化,如果有变化,那么portchange和USB_PORT_STAT_C_CONNECTION相与的结果就是1,对于这种情况,我们需要发送另一个请求以清除这个flag,并且将connect_change也设置为1.这个请求叫做Clear Port Feature.这个请求也是Hub的标准请求。
usb的接口驱动的数据结构为：struct usb_drive，它和usb接口对等；
usb设备驱动的数据结构为：struct usb_device_driver,它和整个usb设备对等
4.配置和设置的区别：
配置还有设置有什么区别，起码我平时即使是再无聊也不会去想这个，但老外不一样，他们不知道老子也不知道郑板桥，所以说他们挺较真儿这个，还分了两个词，配置是configuration，设置是setting。先说配置，一个手机可以有多种配置，比如可以摄像，可以接在电脑里当做一个U盘，那么这两种情况就属于不同的配置，在手机里面有相应的选择菜单，你选择了哪种它就按哪种配置进行工作，供你选择的这个就叫做配置。很显然,当你摄像的时候你不可以访问这块U盘，当你访问这块U盘的时候你不可以摄像，因为你做了选择。第二，既然一个配置代表一种不同的功能，那么很显然，不同的配置可能需要的接口就不一样，我假设你的手机里从硬件上来说一共有5个接口，那么可能当你配置成U盘的时候它只需要用到某一个接口，当你配置成摄像的时候，它可能只需要用到另外两个接口，可能你还有别的配置，然后你可能就会用到剩下那两个接口，也就是说一个配置可能包括到若干个接口
再说说设置，一个手机可能各种配置都确定了，是振动还是铃声已经确定了，各种功能都确定了，但是声音的大小还可以变吧，通常手机的音量是一格一格的变动，大概也就5、6格，那么这个可以算一个setting吧。
5.端点、接口、设置、配置
•  设备通常有一个或多个配置.
•  配置常常有一个或多个接口
•  接口常常有一个或多个设置.
•  接口有零或多个端点.
6.一般来说，主设备号表明了设备的种类，也表明了设备对应着哪个驱动程序，而次设备号则是因为一个驱动程序要支持多个设备而为了让驱动程序区分它们而设置的。也就是说，主设备号用来帮你找到对应的驱动程序，次设备号给你的驱动用来决定对哪个设备进行操作
7.
每个端点都有一个叫做maximum packet size的filed，即告诉你该端点能够发送或者接收的包的最大值.对于通常的端点来说,这个值被保存在该端点描述符中的wMaxPacketSize这一个field,而对于端点0就不一样了,由于它自己没有一个描述符,而每个设备又都有这么一个端点,所以这个信息被保存在了设备描述符里,所以我们在设备描述符里可以看到这么一项,bMaxPacketSize0,而且spec还规定了,这个值只能是8,16,32或者64这四者之一,而且,如果一个设备工作在高速模式,这个值还只能是64,取别的值都不行
8.
在usb_hcd_submit_urt()中，Root Hub, rh_urb_enqueue会被执行,对于非Root Hub,即一般的Hub,driver->urb_enqueue会被执行,对于uhci来说,就是uhci_urb_enqueue会被执行.
对于一般的hub，会执行usb/host/ixp4xx_ehci_hcd.c中的ehci_urb_enqueue(),而ehci_urb_enqueue()则会调用submit_async()(对于设备请求，调用到了这里)
对于一般的hub
ehci_watchdog->    ehci_work()出现ehci_work(),就开始返回了
给出一个请求，会执行如下过程：rh_timer_func->    usb_hcd_poll_rh_status->    usb_hcd_giveback_urb->    urb->complete
9.对于root hub的情况,为什么不用对传输缓存区进行DMA映射呢?
在后面的处理中我们可以看到,其实对于root hub ,它不需要进行实际的物理传输,linux按照spec上的规定,将它静态放置在内存中,在进行相关操作的时候,只要直接copy过去就可以了.
usb_hcd_giveback_urb函数里边会调用urb->complete(urb);
10.urb发送处理过程
(1).假如一个usb_control_msg函数被调用
(2).usb_control_msg会调用usb_internal_control_msg函数
(3).usb_internal_control_msg会调用usb_alloc_urb分配一个urb结构，然后调用usb_fill_control_urb函数来填充这个urb结构，然后调用usb_start_wait_urb函数
(4).usb_start_wait_urb会调用usb_submit_urb（urb,GFP_NOIP）将这个urb发送给usb core，完成过程如下：
(4.1).usb_submit_urb对urb进行一些设置，然后交给usb主控制器驱动来出作进一步的处理，调用的函数为usb_hcd_submit_urb
(4.2).在usb_hcd_submit_urb函数中，判断urb要发送到的设备，假如此设备为 root hub，那么调用rh_urb_enqueue(hcd, urb)，否则，调用hcd->driver->urb_enqueue(hcd, urb, mem_flags);
在我的主控制器驱动里注册的urb_enqueue函数为ehci_urb_enqueue
    if (is_root_hub(urb->dev))
        status = rh_urb_enqueue(hcd, urb);
    else
        //如果是一般的设备
        status = hcd->driver->urb_enqueue(hcd, urb, mem_flags);
因为我分析的是一个普通的usb设备，所以调用ehci_urb_enqueue
(4.3).ehci_urb_enqueue将来自usbcore层的urb的传输请求转换成ehci 可识别的传输描述结构(iTD,siTD,qTD等),然后安排到echi的periodic schedule list或者asynchronous schedule list的合适位置。
对于urb 所要发送到endpoint的类型的control的情况下，此函数将依次调用两个函数：qh_urb_transaction (ehci, urb, &qtd_list, mem_flags)和submit_async (ehci, ep, urb, &qtd_list, mem_flags)
(4.4).调用qh_urb_transaction (ehci, urb, &qtd_list, mem_flags)从urb生成一系列qTD结构,并将这些结构连接到qtd_list;
(4.5).调用submit_async (ehci, ep, urb, &qtd_list, mem_flags)将qtd_list链接的qTD结构分配到ep对应的QH, 将该QH安排到ehci asynchronous schedule list中;
(5)usb_start_wait_urb调用usb_submit_urb将urb最终发送给主控制器驱动之后，它开始满怀信息的等待usb core给它的结果。而它呢,在usb core给它结果以前，它没什么事情可干了把。于是，它调用wait_for_completion_timeout进行非中断的等待（休眠了自己）。
11.urb的完成
(1).在usb_create_hcd函数内有一句：
hcd->rh_timer.function = rh_timer_func;
(2).rh_timer_func函数实现如下:
static void rh_timer_func (unsigned long _hcd)
{
    usb_hcd_poll_rh_status((struct usb_hcd *) _hcd);
}
(3).usb_hcd_poll_rh_status函数实现如下:
root hub的中断传输使用polling方式（使用一个定时器），当驱动请求它的时候。也就是说，当有事件发生的时候，驱动负责调用usb_hcd_poll_rh_status
void usb_hcd_poll_rh_status(struct usb_hcd *hcd)
{
     struct urb *urb;
     int length;
     unsigned long flags;
     char buffer[4]; /* Any root hubs with > 31 ports? */
     //检测主机控制器驱动是否已经注册
     if (unlikely(!hcd->rh_registered))
          return;
     if (!hcd->uses_new_polling && !hcd->status_urb)
          return;
     //负责检测端口和td队列的状态
     length = hcd->driver->hub_status_data(hcd, buffer);
     //端口有设备
     if (length > 0)
     {
          /* try to complete the status urb */
          spin_lock_irqsave(&hcd_root_hub_lock, flags);
          urb = hcd->status_urb;
          //检测urb是否存在
          if (urb)
          {
               hcd->poll_pending = 0;
               //清除hcd的状态urb
               hcd->status_urb = NULL;
               //置实际传输长度为1
               urb->actual_length = length;
               //拷贝端口状态描述组到urb中
               memcpy(urb->transfer_buffer, buffer, length);
               //卸载urb与节点的连接
               usb_hcd_unlink_urb_from_ep(hcd, urb);
               spin_unlock(&hcd_root_hub_lock);
              //返回urb给驱动程序
               usb_hcd_giveback_urb(hcd, urb, 0);
               spin_lock(&hcd_root_hub_lock);
          }
          else
          {
               length = 0;
               hcd->poll_pending = 1;
          }
      spin_unlock_irqrestore(&hcd_root_hub_lock, flags);
     }
     /* The USB 2.0 spec says 256 ms. This is close enough and won't
      * exceed that limit if HZ is 100. The math is more clunky than
      * maybe expected, this is to make sure that all timers for USB devices
      * fire at the same time to give the CPU a break inbetween */
     //每间隔HZ/4就执行一次hcd->rh_timer中指定的函数
     if (hcd->uses_new_polling ? hcd->poll_rh :(length == 0 && hcd->status_urb != NULL))
          mod_timer (&hcd->rh_timer, (jiffies/(HZ/4) + 1) * (HZ/4));
}
usb_hcd_poll_rh_status首先调用hcd->driver->hub_status_data(hcd, buffer);在我的ehci中为ehci_hub_status_data
ehci_hub_status_data负责检测端口和td队列的状态。假如ehci_hub_status_data返回值大于0，表明存在已经完成的urb,判断hcd->status_urb是否为空，
假如非空，那么设置hcd结构，然后调用usb_hcd_giveback_urb.
(4).usb_hcd_giveback_urb设置urb->status，然后调用urb->complete，这将导致urb的完成处理函数被执行。
(5).在urb的完成处理函数中会调用complete(&ctx->done)或类似的函数。
(6).complete(&ctx->done)将会唤醒usb_start_wait_urb函数.从usb_start_wait_urb函数的wait_for_completion_timeout处继续执行。
如果超时，也会返回usb_start_wait_urb，然后进行错误处理；如果一切正常，那么恭喜，此次通信圆满成功。
12.
ehci_irq
ehci_work
scan_saync
qh_completions
在qh_competions函数里，urb->status的值在此函数里发生了变化，qh_competions函数的实现如下：
一篇好文章：http://read.newbooks.com.cn/info/156342.html
ehci_urb_done
usb_hcd_giveback_urb
13.
系统中断入口：
asm_do_IRQ...
handle_level_irq...
handle_IRQ_event...
usb控制器中断
usb_hcd_irq...
ehci_irq...
ehci_wrok...
scan_async...
qh_completions...
qtd_copy_status...
consistent_asny...

/************************************************分割线*********************************************************/

linux USB请求块（URB）（USB驱动收发数据部分简介） 

 

参考：http://book.51cto.com/art/200803/66930.htm

http://bbs.chinaunix.net/thread-2014982-1-1.html
Linux USB驱动框架分析
http://helloyesyes.iteye.com/blog/1072537
怎样写linux下的USB设备驱动程序
http://book.51cto.com/art/200912/169140.htm

————————————————————————————————————————————

urb结构体

     USB请求块（USB request block，urb）是USB设备驱动中用来描述与USB设备通信所用的基本载体和核心数据结构，非常类似于网络设备驱动中的sk_buff结构体，是USB主机与设备通信的“电波”。

urb处理流程

     USB设备中的每个端点都处理一个urb队列，在队列被清空之前，一个urb的典型生命周期如下：

（1）被一个 USB 设备驱动创建。

创建urb结构体的函数为：

struct urb *usb_alloc_urb(int iso_packets, int mem_flags);

iso_packets是这个urb应当包含的等时数据包的数目，若为0表示不创建等时数据包。 mem_flags参数是分配内存的标志，和kmalloc()函数的分配标志参数含义相同。如果分配成功，该函数返回一个urb结构体指针，否则返回0。

urb结构体在驱动中不能静态创建，因为这可能破坏USB核心给urb使用的引用计数方法。

usb_alloc_urb()的“反函数”为：

                      void usb_free_urb(struct urb *urb);

该函数用于释放由usb_alloc_urb()分配的urb结构体。

（2）初始化，被安排给一个特定USB设备的特定端点。

对于中断urb，使用usb_fill_int_urb()函数来初始化urb，如下所示：

     void 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);

    urb参数指向要被初始化的urb的指针；dev指向这个urb要被发送到的USB设备；pipe是这个urb要被发送到的USB设备的特定端点；transfer_buffer是指向发送数据或接收数据的缓冲区的指针，和urb一样，它也不能是静态缓冲区，必须使用kmalloc()来分配；buffer_length是transfer_buffer指针所指向缓冲区的大小；complete指针指向当这个 urb完成时被调用的完成处理函数；context是完成处理函数的“上下文”；interval是这个urb应当被调度的间隔。

上述函数参数中的pipe使用usb_sndintpipe()或usb_rcvintpipe()创建。

对于批量urb，使用usb_fill_bulk_urb()函数来初始化urb，如下所示：

void usb_fill_bulk_urb(struct urb *urb, struct usb_device *dev, unsigned int pipe, void *transfer_buffer, int buffer_length, usb_complete_t complete, void *context);

除了没有对应于调度间隔的interval参数以外，该函数的参数和usb_fill_int_urb()函数的参数含义相同。

上述函数参数中的pipe使用usb_sndbulkpipe()或者usb_rcvbulkpipe()函数来创建。

对于控制 urb，使用usb_fill_control_urb()函数来初始化urb，如下所示：

void usb_fill_control_urb(struct urb *urb, struct usb_device *dev, unsigned int pipe, unsigned char *setup_packet, void *transfer_buffer, int buffer_length, usb_complete_t complete, void *context);

除了增加了新的setup_packet参数以外，该函数的参数和usb_fill_bulk_urb()函数的参数含义相同。setup_packet参数指向即将被发送到端点的设置数据包。

上述函数参数中的pipe使用usb_sndctrlpipe()或usb_rcvictrlpipe()函数来创建。

等时urb没有像中断、控制和批量urb的初始化函数，我们只能手动地初始化urb，而后才能提交给USB核心。代码清单20.14给出了初始化等时urb的例子，它来自drivers/usb/media/usbvideo.c文件。

（3）被USB设备驱动提交给USB 核心。

在完成第（1）、（2）步的创建和初始化urb后，urb便可以提交给USB核心，通过usb_submit_urb()函数来完成，如下所示：

int usb_submit_urb(struct urb *urb, int mem_flags);

urb参数是指向urb的指针，mem_flags参数与传递给kmalloc()函数参数的意义相同，它用于告知USB核心如何在此时分配内存缓冲区。

在提交urb到USB核心后，直到完成函数被调用之前，不要访问urb中的任何成员。

usb_submit_urb()在原子上下文和进程上下文中都可以被调用，mem_flags变量需根据调用环境进行相应的设置，如下所示。

l GFP_ATOMIC：在中断处理函数、底半部、tasklet、定时器处理函数以及urb完成函数中，在调用者持有自旋锁或者读写锁时以及当驱动将current->state修改为非 TASK_ RUNNING时，应使用此标志。

l GFP_NOIO：在存储设备的块I/O和错误处理路径中，应使用此标志；

l GFP_KERNEL：如果没有任何理由使用GFP_ATOMIC和GFP_NOIO，就使用GFP_ KERNEL。

如果usb_submit_urb()调用成功，即urb的控制权被移交给USB核心，该函数返回0；否则，返回错误号。

（4）提交由USB核心指定的USB主机控制器驱动。

（5）被USB主机控制器处理，进行一次到USB设备的传送。

第（4）～（5）步由USB核心和主机控制器完成，不受USB设备驱动的控制。

（6）当urb完成，USB主机控制器驱动通知USB设备驱动。

在如下3种情况下，urb将结束，urb完成函数将被调用。

l urb 被成功发送给设备，并且设备返回正确的确认。如果urb->status为0，意味着对于一个输出urb，数据被成功发送；对于一个输入urb，请求的数据被成功收到。

l 如果发送数据到设备或从设备接收数据时发生了错误，urb->status将记录错误值。

l urb 被从USB 核心“去除连接”，这发生在驱动通过usb_unlink_urb()或usb_kill_urb()函数取消urb，或urb虽已提交，而USB设备被拔出的情况下。

usb_unlink_urb()和usb_kill_urb()这两个函数用于取消已提交的urb，其参数为要被取消的urb指针。对usb_unlink_urb()而言，如果urb结构体中的URB_ASYNC_UNLINK（即异步unlink）的标志被置位，则对该urb的usb_unlink_urb()调用将立即返回，具体的unlink动作将在后台进行。否则，此函数一直等到urb被解开链接或结束时才返回。usb_kill_urb()会彻底终止urb的生命周期，它通常在设备的disconnect()函数中被调用。

当urb生命结束时（处理完成或被解除链接），通过urb结构体的status成员可以获知其原因，如0表示传输成功，-ENOENT表示被usb_kill_urb()杀死，-ECONNRESET表示被usb_unlink_urb()杀死，-EPROTO表示传输中发生了bitstuff错误或者硬件未能及时收到响应数据包，-ENODEV表示USB设备已被移除，-EXDEV表示等时传输仅完成了一部分等。

对以上urb的处理步骤进行一个总结，图20.5给出了一个urb的整个处理流程，虚线框的usb_unlink_urb()和usb_kill_urb()并非一定会发生，它只是在urb正在被USB核心和主机控制器处理时，被驱动程序取消的情况下才发生。

3．简单的批量与控制URB（另一种简单的传输途径）

    有时USB驱动程序只是从USB设备上接收或向USB设备发送一些简单的数据，这时候，没有必要将urb创建、初始化、提交、完成处理的整个流程走一遍，而可以使用两个更简单的函数，如下所示。

（1）usb_bulk_msg()。

usb_bulk_msg()函数创建一个USB批量urb 并将它发送到特定设备，这个函数是同步的，它一直等待urb完成后才返回。usb_bulk_msg()函数的原型为：

int usb_bulk_msg(struct usb_device *usb_dev, unsigned int pipe, void *data, int len, int *actual_length, int timeout);

usb_dev参数为批量消息要发送的USB 设备的指针，pipe为批量消息要发送到的USB设备的端点，data参数为指向要发送或接收的数据缓冲区的指针，len参数为data参数所指向的缓冲区的长度，actual_length用于返回实际发送或接收的字节数，timeout是发送超时，以jiffies为单位，0意味着永远等待。

如果函数调用成功，返回0；否则，返回1个负的错误值。

（2）usb_control_msg()函数。

usb_control_msg()函数与usb_bulk_msg()函数类似，不过它提供驱动发送和结束USB控制信息而非批量信息的能力，该函数的原型为：

int usb_control_msg(struct usb_device *dev, unsigned int pipe, _ _u8 request, _ _u8 requesttype, _ _u16 value, _ _u16 index, void *data, _ _u16 size, int timeout);

dev指向控制消息发往的USB设备，pipe是控制消息要发往的USB设备的端点，request是这个控制消息的USB请求值，requesttype是这个控制消息的USB请求类型，value是这个控制消息的USB消息值，index是这个控制消息的USB消息索引值，data指向要发送或接收的数据缓冲区，size是data参数所指向的缓冲区的大小，timeout是发送超时，以jiffies为单位，0意味着永远等待。

参数request、requesttype、value和index与USB规范中定义的USB控制消息直接对应。

如果函数调用成功，该函数返回发送到设备或从设备接收到的字节数；否则，返回一个负的错误值。

对usb_bulk_msg()和usb_control_msg()函数的使用要特别慎重，由于它们是同步的，因此不能在中断上下文和持有自旋锁的情况下使用。而且，该函数也不能被任何其他函数取消，因此，务必要使得驱动程序的disconnect()函数掌握足够的信息，以判断和等待该调用的结束。

(值得说明的是，由于USB协议的端点缓存的额限制，一般情况下，一次只能发送或者接收最多64字节的数据，如果大于64字节的话就需要多次收发，可以参考115网盘上修改自linux源码中的usb-skeleton.c文件的USB驱动)。

 

 

 

本文转载之：http://blog.csdn.net/ken831001/article/details/7339701