usb驱动开发18——设备生命线

现在已经使用GET_DESCRIPTOR请求取到了包含一个配置里所有相关描述符内容的一堆数据，这些数据是raw的，即原始的，所有数据不管是配置描述符、接口描述符还是端点描述符都挤在一起，所以得想办法将它们给分开。，于是usb_parse_configuration()就做这些事：

static int usb_parse_configuration(struct device *ddev, int cfgidx,struct usb_host_config *config, unsigned char *buffer, int size)
{unsigned char *buffer0 = buffer;int cfgno;int nintf, nintf_orig;int i, j, n;struct usb_interface_cache *intfc;unsigned char *buffer2;int size2;struct usb_descriptor_header *header;int len, retval;u8 inums[USB_MAXINTERFACES], nalts[USB_MAXINTERFACES];memcpy(&config->desc, buffer, USB_DT_CONFIG_SIZE);if (config->desc.bDescriptorType != USB_DT_CONFIG ||config->desc.bLength < USB_DT_CONFIG_SIZE) {dev_err(ddev, "invalid descriptor for config index %d: ""type = 0x%X, length = %d\n", cfgidx,config->desc.bDescriptorType, config->desc.bLength);return -EINVAL;}cfgno = config->desc.bConfigurationValue;buffer += config->desc.bLength;size -= config->desc.bLength;nintf = nintf_orig = config->desc.bNumInterfaces;if (nintf > USB_MAXINTERFACES) {dev_warn(ddev, "config %d has too many interfaces: %d, ""using maximum allowed: %d\n",cfgno, nintf, USB_MAXINTERFACES);nintf = USB_MAXINTERFACES;}/* Go through the descriptors, checking their length and counting the* number of altsettings for each interface */n = 0;for ((buffer2 = buffer, size2 = size);size2 > 0;(buffer2 += header->bLength, size2 -= header->bLength)) {if (size2 < sizeof(struct usb_descriptor_header)) {dev_warn(ddev, "config %d descriptor has %d excess ""byte%s, ignoring\n",cfgno, size2, plural(size2));break;}header = (struct usb_descriptor_header *) buffer2;if ((header->bLength > size2) || (header->bLength < 2)) {dev_warn(ddev, "config %d has an invalid descriptor ""of length %d, skipping remainder of the config\n",cfgno, header->bLength);break;}if (header->bDescriptorType == USB_DT_INTERFACE) {struct usb_interface_descriptor *d;int inum;d = (struct usb_interface_descriptor *) header;if (d->bLength < USB_DT_INTERFACE_SIZE) {dev_warn(ddev, "config %d has an invalid ""interface descriptor of length %d, ""skipping\n", cfgno, d->bLength);continue;}inum = d->bInterfaceNumber;if (inum >= nintf_orig)dev_warn(ddev, "config %d has an invalid ""interface number: %d but max is %d\n",cfgno, inum, nintf_orig - 1);/* Have we already encountered this interface?* Count its altsettings */for (i = 0; i < n; ++i) {if (inums[i] == inum)break;}if (i < n) {if (nalts[i] < 255)++nalts[i];} else if (n < USB_MAXINTERFACES) {inums[n] = inum;nalts[n] = 1;++n;}} else if (header->bDescriptorType == USB_DT_DEVICE ||header->bDescriptorType == USB_DT_CONFIG)dev_warn(ddev, "config %d contains an unexpected ""descriptor of type 0x%X, skipping\n",cfgno, header->bDescriptorType);}    /* for ((buffer2 = buffer, size2 = size); ...) */size = buffer2 - buffer;config->desc.wTotalLength = cpu_to_le16(buffer2 - buffer0);if (n != nintf)dev_warn(ddev, "config %d has %d interface%s, different from ""the descriptor's value: %d\n",cfgno, n, plural(n), nintf_orig);else if (n == 0)dev_warn(ddev, "config %d has no interfaces?\n", cfgno);config->desc.bNumInterfaces = nintf = n;/* Check for missing interface numbers */for (i = 0; i < nintf; ++i) {for (j = 0; j < nintf; ++j) {if (inums[j] == i)break;}if (j >= nintf)dev_warn(ddev, "config %d has no interface number ""%d\n", cfgno, i);}/* Allocate the usb_interface_caches and altsetting arrays */for (i = 0; i < nintf; ++i) {j = nalts[i];if (j > USB_MAXALTSETTING) {dev_warn(ddev, "too many alternate settings for ""config %d interface %d: %d, ""using maximum allowed: %d\n",cfgno, inums[i], j, USB_MAXALTSETTING);nalts[i] = j = USB_MAXALTSETTING;}len = sizeof(*intfc) + sizeof(struct usb_host_interface) * j;config->intf_cache[i] = intfc = kzalloc(len, GFP_KERNEL);if (!intfc)return -ENOMEM;kref_init(&intfc->ref);}/* Skip over any Class Specific or Vendor Specific descriptors;* find the first interface descriptor */config->extra = buffer;i = find_next_descriptor(buffer, size, USB_DT_INTERFACE,USB_DT_INTERFACE, &n);config->extralen = i;if (n > 0)dev_dbg(ddev, "skipped %d descriptor%s after %s\n",n, plural(n), "configuration");buffer += i;size -= i;/* Parse all the interface/altsetting descriptors */while (size > 0) {retval = usb_parse_interface(ddev, cfgno, config,buffer, size, inums, nalts);if (retval < 0)return retval;buffer += retval;size -= retval;}/* Check for missing altsettings */for (i = 0; i < nintf; ++i) {intfc = config->intf_cache[i];for (j = 0; j < intfc->num_altsetting; ++j) {for (n = 0; n < intfc->num_altsetting; ++n) {if (intfc->altsetting[n].desc.bAlternateSetting == j)break;}if (n >= intfc->num_altsetting)dev_warn(ddev, "config %d interface %d has no ""altsetting %d\n", cfgno, inums[i], j);}}return 0;
}

代码太长，还是先说点理论垫垫底儿吧。其实使用GET_DESCRIPTOR请求时，得到的数据并不是杂乱无序的，而是有规可循的，一般来说，配置描述符后面跟的是第一个接口的接口描述符，接着是这个接口里第一个端点的端点描述符，如果有class-和vendor-specific描述符的话，会紧跟在对应的标准描述符后面，不管接口有多少端点都是按照这个规律顺序排列。当然有些厂商会特立独行一些，非要先返回第二个接口然后再返回第一个接口，但配置描述符后面总归先是接口描述符再是端点描述符。

函数的参数buffer里保存的就是GET_DESCRIPTOR请求获得的那堆数据，要解析这些数据，不可避免的要对buffer指针进行操作，这里先将它备份一下给buffer0。

函数的参数config是设备struct usb_device结构体里的struct usb_host_config结构体数组config中的一员（不信？你去看看usb_get_configuration函数）。不出意外的话buffer的前USB_DT_CONFIG_SIZE个字节对应的就是配置描述符，那么这里的意思就很明显了。然后做些检验，看看这USB_DT_CONFIG_SIZE字节的内容究竟是不是正如我们所期待的那样是个配置描述符，如果不是，那buffer里的数据问题可就大了，没什么利用价值了，还是返回吧，不必要再接着解析了。

buffer的前USB_DT_CONFIG_SIZE个字节已经理清了，接下来该解析剩下的数据了，同时修改buffer位置和长度，获得这个配置所拥有的接口数目，接口数目不能简单一赋值就完事儿了，得知道系统里对这个数目是有个USB_MAXINTERFACES这样的限制的。如果数目比这个限制还大，就改为USB_MAXINTERFACES。

接下来的for循环完成的事情却很单一，就是统计记录一下这个配置里每个接口所拥有的设置数目。提醒一下这个循环里使用的是buffer2和size2。

在这个循环里遇到一个新的结构struct usb_descriptor_header，在include/linux/usb/ch9.h里定义。这个结构就包括了两个成员，你研究一下所有的那些标准描述符，会兴奋的发现它们的前两个字节都是一样的，一个表示描述符的长度，一个表示描述符的类型。那么为什么要专门搞这么一个结构？试想一下，有块数据缓冲区，让你判断一下里面保存的是哪个描述符，或者是其它什么东西，你怎么做？你当然可以直接将它的前两个字节内容读出来，判断判断bDescriptorType，再判断判断bLength，不过我们这儿完全没必要这么做。通过这样一个结构体，使用强制类型转换把buffer2指针转化为struct usb_descriptor_header的结构体指针，然后就可以使用‘->’来取出bLength和bDescriptorType。现在能够明白header->bLength < 2判断的值为什么是2了吗？

if (header->bDescriptorType == USB_DT_INTERFACE)行，如果这是个接口描述符就说明这个配置的某个接口拥有一个设置，这里是没有所谓的设置描述符的，一个接口描述符就代表了存在一个设置，接口描述里的bInterfaceNumber会指出这个设置隶属于哪个接口。那么这里除了是接口描述符还有可能是什么？还有可能是class-和vendor-specific描述符。既然判断这是个接口描述符，就把这个指针转化为struct usb_interface_descriptor结构体指针。

光是判断bDescriptorType等于USB_DT_INTERFACE并不说明它就一定是接口描述符了，它的bLength还必须要等于USB_DT_INTERFACE_SIZE。bLength和bDescriptorType一起才能决定一个描述符。我知道了你是个接口描述符，那么总要对你做点啥吧？注释说的很好，精简到位。

/* Have we already encountered this interface?

Count its altsettings */

首先要明白n、inums和nalts这几个变量表示什么？n记录的是接口的数目，数组inums里的每一项都表示一个接口号，数组nalts里的每一项记录的是每个接口拥有的设置数目，inums和nalts两个数组里的元素是一一对应的，inums[0]就对应nalts[0]，inums[1]就对应nalts[1]。其次还要谨记一个事实，发送GET_DESCRIPTOR请求时，设备并不一定会按照接口1，接口2这样的顺序循规蹈矩的返回数据，虽说协议里是这么要求的。

经过这样一个大循环后，buffer的最后边儿可能会有些垃圾数据，这里需要将size和配置描述符里的那个wTotalLength修正一下。同时如果统计得到的接口数目和配置描述符里的bNumInterfaces不符，或者干脆就没有发现配置里有什么接口，就警告一下。

下面又一个for循环，注释给俺说的很清楚，检查是不是遗漏了哪个接口号，比如说配置6个接口，每个接口号都应该对应数组inums里的一项，如果在inums里面没有发现这个接口号，就要警告一下。

再一个for循环，struct usb_interface_caches以前说过，USB_MAXALTSETTING的定义在config.c里

#define USB_MAXALTSETTING 128 /* Hard limit */

一个接口最多可以有128个设置，足够了。然后根据每个接口拥有的设置数目为对应的intf_cache数组项申请内存。

配置描述符后面紧跟的不一定就是接口描述符，还可能是class-和vendor-specific描述符，如果有的话。不管有没有，先把buffer的地址赋给extra，如果没有扩展的描述符，则404行返回的i就等于0，extralen也就为0。

调用find_next_descriptor()在buffer里寻找配置描述符后面跟着的第一个接口描述符。它也在config.c里定义，进去看看：

static int find_next_descriptor(unsigned char *buffer, int size,int dt1, int dt2, int *num_skipped)
{struct usb_descriptor_header *h;int n = 0;unsigned char *buffer0 = buffer;/* Find the next descriptor of type dt1 or dt2 */while (size > 0) {h = (struct usb_descriptor_header *) buffer;if (h->bDescriptorType == dt1 || h->bDescriptorType == dt2)break;buffer += h->bLength;size -= h->bLength;++n;}/* Store the number of descriptors skipped and return the* number of bytes skipped */if (num_skipped)*num_skipped = n;return buffer - buffer0;
}

这个函数需要传递两个描述符类型的参数，它不是去寻找一种描述符，而是去寻找两种描述符，比如你指定dt1为USB_DT_INTERFACE，dt2为USB_DT_ENDPOINT时，只要能够找到接口描述符或端点描述符中的一个，这个函数就返回。而usb_parse_configuration函数的两个描述符类型参数一样，只需要寻找下一个接口描述符，所以dt1和dt2都设置为USB_DT_INTERFACE。这个函数结束后，num_skipped里记录的是搜索过程中忽略的dt1和dt2之外其它描述符的数目，返回值表示搜索结束时buffer的位置比搜索开始时前进的字节数。

还是回到usb_parse_configuration函数。根据find_next_descriptor的结果修正buffer和size。

for循环之后迎来一个while循环，如果size大于0，就说明配置描述符后面找到了一个接口描述符，根据这个接口描述符的长度，已经可以解析出一个完整的接口描述符了，但是这个接口描述符后面还会跟着一群端点描述符，再然后还会有其它的接口描述符，所以我们又迎来了另一个变态函数usb_parse_interface，先不管这个函数，暂时只需要知道它返回的时候，buffer的位置已经在下一个接口描述符那里了，还是那个理儿，对buffer地址本身来说是按值传递的，所以下面还是要对这个位置和长度进行下调整以适应新形势。那么这个while循环的意思就很明显了，对buffer一段一段的解析，直到再也找不到接口描述符了。

最后这个for循环没啥实质性的内容，就是找一下每个接口是不是有哪个设置编号给漏过去了，只要有耐心，你就能看得懂。

咱们接下来还是看config.c里的那个usb_parse_interface()。

首先呢，传递过来的buffer开头儿那部分只能是一个接口描述符，没有什么可质疑的，所以这里将地址转化为struct usb_interface_descriptor结构体指针，然后调整buffer的位置和size。但是还要判断一下，只有bLength等于USB_DT_INTERFACE_SIZE才说明开头儿的USB_DT_INTERFACE_SIZE字节确实是个接口描述符。否则就没必要再对这些数据进行什么处理了，直接跳到最后吧。先看看这个函数的最后都发生了什么，从新的位置开始再次调用find_next_descriptor()在buffer里寻找下一个接口描述符。

因为数组inums并不一定是按照接口的顺序来保存接口号的，inums[1]对应的可能是接口1也可能是接口0，所以这里要用for循环来寻找这个接口对应着inums里的哪一项，从而根据在数组里的位置获得接口对应的struct usb_interface_cache结构体。usb_parse_configuration()已经告诉了我们，同一个接口在inums和intf_cache这两个数组里的位置是一样的。

asnum获得这个接口描述符对应的设置编号，然后根据这个编号从接口的cache里搜索看这个设置是不是已经遇到过了，如果已经遇到过，就没必要再对这个接口描述符进行处理，直接跳到最后，否则意味着发现了一个新的设置，要将它添加到cache里，并cache里的设置数目num_altsetting加1。要记住，设置是用struct usb_host_interface结构来表示的，一个接口描述符就对应一个设置。

现在buffer开头儿的那个接口描述符已经理清了，要解析它后面的那些数据了。先把位置赋给这个刚解析出来的接口描述符的extra，然后再从这个位置开始去寻找下一个距离最近的一个接口描述符或端点描述符。如果这个接口描述符后面还跟有class-或vendor-specific描述符，则find_next_descriptor的返回值会大于0，buffer的位置和size也要进行相应的调整，来指向新找到的接口描述符或端点描述符。

这里find_next_descriptor的dt1参数和dt2参数就不再一样了，因为如果一个接口只用到端点0，它的接口描述符后边儿是不会跟有端点描述符的。

然后获得这个设置使用的端点数目，然后将相应接口描述符里的bNumEndpoints置0，为什么？你要往下看。接下来判断num_ep端点数是否大于USB_MAXENDPOINTS？然后根据端点数为接口描述符里的endpoint数组申请内存。

走到这里，buffer开头儿的那个接口描述符已经理清了，而且也找到了下一个接口描述符或端点描述符的位置，该从这个新的位置开始解析了，于是又遇到了一个似曾相识的while循环。

先判断一下前面找到的是接口描述符还是端点描述符，如果是接口描述符就中断这个while循环，返回与下一个接口描述符的距离。否则说明在buffer当前的位置上待着的是一个端点描述符，因此就要迎来另一个函数usb_parse_endpoint对面紧接着的数据进行解析。usb_parse_endpoint()返回的时候，buffer的位置已经在下一个端点描述符那里了，继续调整buffer的位置长度。这个while循环已经很明显，就是对buffer一段一段的解析，直到遇到下一个接口描述符或者已经走到buffer结尾。

现在看看config.c里定义的usb_parse_endpoint函数：

static int usb_parse_endpoint(struct device *ddev, int cfgno, int inum,int asnum, struct usb_host_interface *ifp, int num_ep,unsigned char *buffer, int size)
{unsigned char *buffer0 = buffer;struct usb_endpoint_descriptor *d;struct usb_host_endpoint *endpoint;int n, i, j;d = (struct usb_endpoint_descriptor *) buffer;buffer += d->bLength;size -= d->bLength;if (d->bLength >= USB_DT_ENDPOINT_AUDIO_SIZE)n = USB_DT_ENDPOINT_AUDIO_SIZE;else if (d->bLength >= USB_DT_ENDPOINT_SIZE)n = USB_DT_ENDPOINT_SIZE;else {dev_warn(ddev, "config %d interface %d altsetting %d has an ""invalid endpoint descriptor of length %d, skipping\n",cfgno, inum, asnum, d->bLength);goto skip_to_next_endpoint_or_interface_descriptor;}i = d->bEndpointAddress & ~USB_ENDPOINT_DIR_MASK;if (i >= 16 || i == 0) {dev_warn(ddev, "config %d interface %d altsetting %d has an ""invalid endpoint with address 0x%X, skipping\n",cfgno, inum, asnum, d->bEndpointAddress);goto skip_to_next_endpoint_or_interface_descriptor;}/* Only store as many endpoints as we have room for */if (ifp->desc.bNumEndpoints >= num_ep)goto skip_to_next_endpoint_or_interface_descriptor;endpoint = &ifp->endpoint[ifp->desc.bNumEndpoints];++ifp->desc.bNumEndpoints;memcpy(&endpoint->desc, d, n);INIT_LIST_HEAD(&endpoint->urb_list);/* If the bInterval value is outside the legal range,* set it to a default value: 32 ms */i = 0;      /* i = min, j = max, n = default */j = 255;if (usb_endpoint_xfer_int(d)) {i = 1;switch (to_usb_device(ddev)->speed) {case USB_SPEED_HIGH:n = 9;        /* 32 ms = 2^(9-1) uframes */j = 16;break;default:        /* USB_SPEED_FULL or _LOW *//* For low-speed, 10 ms is the official minimum.* But some "overclocked" devices might want faster* polling so we'll allow it. */n = 32;break;}} else if (usb_endpoint_xfer_isoc(d)) {i = 1;j = 16;switch (to_usb_device(ddev)->speed) {case USB_SPEED_HIGH:n = 9;        /* 32 ms = 2^(9-1) uframes */break;default:        /* USB_SPEED_FULL */n = 6;     /* 32 ms = 2^(6-1) frames */break;}}if (d->bInterval < i || d->bInterval > j) {dev_warn(ddev, "config %d interface %d altsetting %d ""endpoint 0x%X has an invalid bInterval %d, ""changing to %d\n",cfgno, inum, asnum,d->bEndpointAddress, d->bInterval, n);endpoint->desc.bInterval = n;}/* Skip over any Class Specific or Vendor Specific descriptors;* find the next endpoint or interface descriptor */endpoint->extra = buffer;i = find_next_descriptor(buffer, size, USB_DT_ENDPOINT,USB_DT_INTERFACE, &n);endpoint->extralen = i;if (n > 0)dev_dbg(ddev, "skipped %d descriptor%s after %s\n",n, plural(n), "endpoint");return buffer - buffer0 + i;skip_to_next_endpoint_or_interface_descriptor:i = find_next_descriptor(buffer, size, USB_DT_ENDPOINT,USB_DT_INTERFACE, NULL);return buffer - buffer0 + i;
}

和前面分析一样，buffer开头儿只能是一个端点描述符，所以这里将地址转化为struct usb_endpoint_descriptor结构体指针，然后调整buffer的位置和size。

这里要明白的是端点描述符与配置描述符、接口描述符不一样，它是可能有两种大小的，分别是USB_DT_ENDPOINT_AUDIO_SIZE和USB_DT_ENDPOINT_SIZE。

然后得到端点号d->bEndpointAddress & ~USB_ENDPOINT_DIR_MASK;这里的端点号不能为0，因为端点0是没有描述符的，也不能大于16，为什么？协议里规定的。

然后判断接口描述符中的bNumEndpoints值是否大于 num_e，要注意bNumEndpoints在usb_parse_interface()的是被赋为0了的（不信？自己去看看alt->desc.bNumEndpoints = 0;// Use as a counter）。接着看，要知道这个endpoint数组在usb_parse_interface()的是已经申请好内存了的（alt->endpoint = kzalloc(len, GFP_KERNEL);）。从这里你应该明白bNumEndpoints是被当成了一个计数器，发现一个端点描述符，它就加1，并把找到的端点描述符copy到设置的endpoint数组里。然后初始化端点的urb队列urb_list。

接下来的一段代码的目的是处理端点的bInterval，你要想不被它们给忽悠了，得明白几个问题。

第一个就是，i，j，n分别表示什么。i和j限定了bInterval的一个范围，bInterval如果超出了这个范围，它就是非法的，就要修理修理它，那么n表示的就是bInterval的一个默认值。i和j的默认值分别为0和255，也就是说合法的范围默认是0_{255，对于批量端点和控制端点，bInterval对你我来说并没有太大的用处，不过协议里还是规定了，这个范围只能为0}255。对于中断端点和等时端点，bInterval表演的舞台就很大了，对这个范围也要做一些调整。

第二个问题就是如何判断端点是中断的还是等时的。这涉及到两个函数usb_endpoint_xfer_int和usb_endpoint_xfer_isoc，它们都在include/linux/usb.h里：

/*** usb_endpoint_xfer_int - check if the endpoint has interrupt transfer type* @epd: endpoint to be checked** Returns true if the endpoint is of type interrupt, otherwise it returns* false.*/
static inline int usb_endpoint_xfer_int(const struct usb_endpoint_descriptor *epd)
{return ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==USB_ENDPOINT_XFER_INT);
}/*** usb_endpoint_xfer_isoc - check if the endpoint has isochronous transfer type* @epd: endpoint to be checked** Returns true if the endpoint is of type isochronous, otherwise it returns* false.*/
static inline int usb_endpoint_xfer_isoc(const struct usb_endpoint_descriptor *epd)
{return ((epd->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) ==USB_ENDPOINT_XFER_ISOC);
}

第三个问题是to_usb_device。usb_parse_endpoint()的参数是struct device结构体，要获得设备的速度就需要使用to_usb_device将它转化为struct usb_device结构体。

OK，接着继续看usb_parse_endpoint函数下面应该很明白了，就是接着在buffer里寻找下一个端点描述符或者接口描述符。

经过usb_parse_configuration、usb_parse_interface和usb_parse_endpoint这三个函数推进，通过GET_DESCRIPTOR请求所获得那堆数据现在已经解析的清清白白。现在，设备的各个配置信息已经了然于胸，那接下来设备的那条生命线该怎么去走？它已经可以进入Configured状态了么？事情没这么简单，光是获得设备各个配置信息没用，要进入Configured状态，你还得有选择有目的有步骤有计划的去配置设备，那怎么去有选择有目的有步骤有计划？这好像就不是core能够答复的问题了，毕竟它并不知道你希望你的设备采用哪种配置，只有你的设备的驱动才知道，所以接下来设备要做的是去在设备模型的茫茫人海中寻找属于自己的驱动。

再次提醒，绝对不能忘记设备的那个struct usb_device结构体在出生的时候就带有usb_bus_type和usb_device_type这样的胎记，Linux设备模型根据总线类型usb_bus_type将设备添加到usb总线的那条有名的设备链表里，然后去轮询usb总线的另外一条有名的驱动链表，针对每个找到的驱动去调用usb总线的match函数，也就是usb_device_match()，去为设备寻找另一伴。match函数会根据设备的自身条件和类型usb_device_type安排设备走设备那条路，从而匹配到那个对所有usb_device_type类型的设备都来者不拒的花心大萝卜，他就是usb世界里唯一的那个usb设备驱动（不是usb接口驱动）struct device_driver结构体对象usb_generic_driver。

usb驱动开发18——设备生命线相关推荐

usb驱动开发16——设备生命线
回到struct usb_hcd,继续努力的往下看. kref,usb主机控制器的引用计数.struct usb_hcd也有自己专用的引用计数函数,看hcd.c文件: static void hcd_ ...
usb驱动开发15——设备生命线
总算是进入了HCD的片儿区,既然来到一个片区,怎么都要去拜会一下山头几个大哥吧.,先回忆一些我们怎么到这里的?给你列举一个调用函数过程usb_control_msg->usb_internal_ ...
usb驱动开发12——设备生命线
函数usb_control_msg完成一些初始化后调用了usb_internal_control_msg之后就free urb.剩下的活,全部留给usb_internal_control_msg去做了 ...
usb驱动开发11——设备生命线
暂时先告别媒人,我们去分析各自的生命旅程,最后还会回到usb_device_match函数. 首先当你将usb设备连接在hub的某个端口上,hub检测到有设备连接了进来,它会为设备分配一个struct ...
MF Porting之USB驱动开发
花费了近三个礼拜的时间,终于完成了TI开发板的USB驱动开发,现在回头想一想,其实也没有什么,具体硬件方面的通信由DM355实现了,软件层面的数据交互由MF Porting实现了,所做的也就是熟悉了解 ...
linux 下usb驱动开发,LINUX_ARM下的USB驱动开发.pdf
LINUX_ARM下的USB驱动开发 CN 431258 / TP 计算机工程与科学 2006年第 28卷第 3期 ISSN 1007130X COM PU TER EN GIN EER IN G & ...
Linux USB 驱动开发（五）—— USB驱动程序开发过程简单总结
http://blog.csdn.net/zqixiao_09/article/details/51057086 设备驱动程序是操作系统内核和机器硬件之间的接口,由一组函数和一些私有数据组成,是应用程 ...
Linux USB 驱动开发实例（七）—— 基于USB 总线的无线网卡浅析
回顾一下USB的相关知识 USB(Universal Serial Bus)总线又叫通用串行外部总线, 它是20世纪90年代发展起来的.USB接口现在得到了广泛的应用和普及,现在的PC机中都带有大量的 ...
c语言+usb驱动开发,usb驱动程序分析
usb驱动是linux内核中比较复杂的驱动之一,因此,大多数usb教程建议从usb-skeleton开始学习usb驱动.个人认为这是相当正确的,usb-sekelton提供了一个usb驱动开发的模板, ...

usb驱动开发18——设备生命线

usb驱动开发18——设备生命线相关推荐

最新文章

热门文章