科创园

科创园地,分享技术知识,为科技助力发展,贡献一己之力。
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

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

Posted on 2014-04-01 10:45  科创园  阅读(1895)  评论(1编辑  收藏  举报

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

 

代码太长,还是先说点理论垫垫底儿吧。其实使用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里定义,进去看看

 

这个函数需要传递两个描述符类型的参数,它不是去寻找一种描述符,而是去寻找两种描述符,比如你指定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函数。

 

和前面分析一样,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里定义

 

第三个问题是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。