现在设备的struct usb_device结构体已经准备好了,只是还不怎么饱满,hub接下来就会给它做做整容手术,往里边儿塞点什么,充实一些内容,比如:将设备的状态设置为Powered,也就是加电状态;因为此时还不知道设备支持的速度,于是将设备的speed成员暂时先设置为USB_SPEED_UNKNOWN;设备的级别level当然会被设置为hub的level加上1了;还有为设备能够从hub那里获得的电流赋值;为了保证通信畅通,hub还会为设备在总上选择一个独一无二的地址。
经历了几千里路的云和月,属于设备的那个struct usb_device结构体现在又有了多少的功名尘与土?给张表吧,集中列了下到目前为止,设备结构体里成员的状况,这里不用藏着掖着,整就整了,不都是为了生活么。里面的taken只是表示赋过值了,好像期末考试前你去突击自习,这时一个ppmm走到你旁边,用一个美妙的声音问你“Is this seat taken?”,你怎么回答?当然是“No, No, please.”,那如果星爷片子里面的如花过来问你那?你回答什么?对头,taken就是这个意思。那赋了什么值?没必要知道的那么详细,给别人留点自尊,歌里唱的好,人人都需要一点隐私。
devnum | taken |
devpath[16] | taken |
state | USB_STATE_POWERED |
speed | USB_SPEED_UNKNOWN |
parent | 设备连接的那个hub |
bus | 设备连接的那条总线 |
ep0 | ep0.urb_list,描述符长度/类型 |
dev | dev.bus,dev.type,dev.dma_mask,,dev.parent,dev.bus_id |
ep_in[16] | ep_in[0] |
ep_out[16] | ep_out[0] |
bus_mA | hub->mA_per_port |
portnum | 设备连接在hub上的那个端口 |
level | hdev->level + 1 |
filelist | taken |
pm_mutex | taken |
autosuspend | taken |
autosuspend_delay | 2 * HZ |
还记不记得无间道里的那个傻强?“我是傻强,我是傻的。”这种经典的台词儿也不是什么时候都有的。那即使是傻强过来瞅瞅,也知道你的设备现在已经处在了Powered状态。前面讲过的,设备要想从Powered状态发展到下一个状态Default,必须收到一个复位信号并成功复位。就好像你要想和你mm从暧昧关系发展到你梦寐以求的以身相许的地步,不是随随便便就可以的,情调、money一个都不能少。那hub接下来的动作就很明显了,复位设备,复位成功后,设备就会进入Default状态。
白天停水,晚上停电,发不出工资,买不起面,打开邓选找到答案,原来是社会主义初级阶段,翻到最后,我靠,一百年不变。设备复位不需要一百年那么久,咱们也等不起,顺利的话也就那么几十毫秒的功夫,都不值得秒针动一下。不顺利的话,它会多尝试几次,难道你追mm时,表白一次不成功就撤退了?那也忒……了些,白受了这么多年教育。不过如果试了几次都复位不成,那就不用试了,这条设备的生命线就算提前玩完儿了。同样的道理,如果你表白了很多次都不成,那还是换个目标吧,虽说失败是成功他妈,挫折本身并不可怕,但可怕的是成功他妈也太多了些了。
现在就算设备成功复位了,大步迈进了Default状态,同时,hub也会获得设备真正的速度,低速、全速也好,高速也罢,总算是浮出水面了,speed也终于知道了自己的真正身份,不用再是UNKNOWN了。那根据这个速度,咱们能知道些什么?起码能够知道端点0一次能够处理的最大数据长度啊,协议里说,对于高速设备,这个值为为64字节,对于低速设备为8字节,而对于全速设备可能为8,16,32,64其中的一个。遇到这种模棱两可的答案,写代码的哥们儿不会满足,咱们也不会满足,所以hub还要通过一个蜿蜒曲折的过程去获得这个确定的值,至于怎么个曲折法儿,此处省略2008字。
hub也辛苦的蛮久了,设备也该进入Address状态了,也要知恩图报啊。好像任小强们辛苦了那么久盖了那么多的房子之后,给咱们说,你们快进入Address吧,不然兄弟们撑不下去了,那你怎么办,上下三四代,左右五六家的凑呗,于是21世纪的奇观房奴大军形成了。
咱们的设备要想进入Address状态没那么费劲儿,只要hub使用core里定义的一个函数usb_control_msg,发送SET_ADDRESS请求给设备,设备就兴高采烈的迈进Address了。那么设备的这个address是什么,就是上面的devnum啊,说过的。不用羡慕它们太久,经过了10年,百年,千年,咱们也会Address的。
那现在咱就来说说这个usb_control_msg函数,它在drivers/usb/core/message.c里定义
这个函数主要目的是创建一个控制urb,并把它发送给usb设备,然后等待它完成。urb是什么?忘了么,前面提到过的,你要想和你的usb通信,就得创建一个urb,并且为它赋好值,交给usb core,它会找到合适的host controller,从而进行具体的数据传输。而且我还说会挑选一个黄道吉日,对它大书特书。那现在是不是那个黄道吉日?甭着急,现在还不是,一步一步来,到了我会说的,俺可是一诺千斤石头的,对自己的rp有信心。题外话,你知道最差的rp是什么?最差的rp莫过于痴痴地盯着一个丑女看半晌,然后叹口气说:“靠,这恐龙做得太像真的了……”
123行,为一个struct usb_ctrlrequest结构体申请了内存,这里又出现了一个新生事物,郭天王早提醒我们了,这里的结构说不完。它在include/linux/usb/ch9.h文件里定义
这个结构完全对应于spec里的Table 9-2,描述了主机通过控制传输发送给设备的请求(Device Requests)。一直都在羡慕它们,这会儿到体现出咱们的优越了,主机向设备请求些信息必须得按照协议里规定好的格式,不然设备就会不明白主机是嘛意思,而咱们就不一样了,不用填这个值那个值,你只要唱一句你是风儿我是沙,你mm就明明白白你的心了。不过还是要感慨一下,要是爱情也有固定的格式该多好,这样世界上就少了许多无谓的误会和争吵,把这种精力转化到生产力上,国民生产总值又要提高多少个百分点,绝对比房地产这根柱子的贡献大多了。
这个结构描述的request都在Setup包里发送,Setup包是前面某处说到的Token PID类型中的一种,为了你好理解,这里细说一下控制传输底层的packet情况。控制传输最少要有两个阶段的transaction,SETUP和STATUS,SETUP和STATUS中间的那个DATA阶段是可有可无的。Transaction这个词儿在很多地方都有,也算是个跨地区跨学科的热门词汇了,在这里你称它为事务也好,会话也罢,我还是直呼它的原名transaction,可以理解为主机和设备之间形成的一次完整的交流,比如2004中 华 小姐环球大赛总决赛上评委蔡澜和陕西选手姚佳雯之间的对话:
要老公还是要钱?要钱。
这就可以算是一次transaction,还有
要父母还是要钱?要父母。
要国家还是要钱?要钱。
这些也都算是transactions,usb的transaction要比上面的对话复杂,起码要过过脑子,它可以包括一个Token包、一个Data包和一个Handshake包。
Token、Data和Handshake都属于四种PID类型中的,前面说到时提到的一个包里的那些部分,如SYNC、PID、地址域、DATA、CRC,并不是所有PID类型的包都会全部包括的。Token包只包括SYNC、PID、地址域、CRC,并没有DATA字段,它的名字起的很形象,就是用来标记所在transaction里接下来动作的,对于Out和Setup Token包,里面的地址域指明了接下来要接收Data包的端点,对于In Token包,地址域指明了接下来哪个端点要发送Data包。还有,只有主机才有权利发送Token包,协议里就这么规定的。别嫌spec规定太多,又管这儿又管那儿的,没有规矩不成方圆,连咱们首都机场的的边检民警们都规定了,微笑服务必须露出8颗牙齿,上边儿四颗下边儿四颗,多一颗少一颗都不合格直接kick,那嘴小的看不到8颗咋办?嘴巴剪大点,嘴大的露的太多咋办?那就缝住,那虎牙咋办?这可是技术难题,不好解决啊,不是中科院、自然科学基金等这几家正在征募10000科学难题么,你可以拿它去申报一下,不定还能拿点资助什么的。
与Token包相比,Data包里没了地址域,多了Data字段,这个Data字段对于低速设备最大为8字节,对于全速设备最大为1023字节,对于高速设备最大为1024字节。里里外外看过去,它就是躲在Token后边儿用来传输数据的。Handshake包的成分就非常的简单了,简直和那位姚佳雯的回答一样简单,除了SYNC,它就只包含了一个PID,通过PID取不同的值来报告一个transaction的状态,比如数据已经成功接收了等。
俗话说,兔有三窟,人有三急,控制传输的SETUP transaction一般来说也有三个阶段,就是主机向设备发送Setup Token包、然后发送Data0包,如果一切顺利,设备回应ACK Handshake包表示OK,为什么加上一般?如果中间的那个Data0包由于某种不可知因素被损坏了,设备就什么都不会回应,这时就成俩阶段了。SETUP transaction之后,接下来如果控制传输有DATA transaction的话,那就Data0、Data1这样交叉的发送数据包,前面说过这是为了实现data toggle。最后是STATUS transaction,向主机汇报前面SETUP和DATA阶段的结果,比如表示主机下达的命令已经完成了,或者主机下达的命令没有完成,或者设备正忙着那没功夫去理会主机的那些命令。
这样经过SETUP、DATA、STATUS这三个transaction阶段,一个完整的控制传输完成了。主机接下来可以规划下一次的控制传输。
现在对隐藏在控制传输背后的是是非非摸了个底儿,群众的眼睛是雪亮的,咱们现在应该可以看出之前说requests都在Setup包里发送是有问题的,因为Setup包本身并没有数据字段,严格来说它们应该都是在SETUP transaction阶段里Setup包后的Data0包里发送的。还有点糊涂?唉,女人之美,在于蠢得无怨无悔;男人之美,在于说得白日见鬼;诗歌之美,在于煽动男女出轨;学问之美,在于使人一头雾水。那就带着雾水向下看吧,可能会有那么云开雾明的一天。
141行,bRequestType,这个字段别看就一个字节,内容很丰富的,大道理往往都包含这种在小地方。它的bit7就表示了控制传输中DATA transaction阶段的方向,当然,如果有DATA阶段的话。bit5~6表示request的类型,是标准的,class-specific的还是vendor-specific的。bit0~4表示了这个请求针对的是设备,接口,还是端点。内核为它们专门量身定做了一批掩码,也在ch9.h文件里,
142行,bRequest,表示具体是哪个request。
143行,wValue,这个字段是request的参数,request不同,wValue就不同。
144行,wIndex,也是request的参数,bRequestType指明request针对的是设备上的某个接口或端点的时候,wIndex就用来指明是哪个接口或端点。
145行,wLength,控制传输中DATA transaction阶段的长度,方向已经在bRequestType那儿指明了。如果这个值为0,就表示没有DATA transaction阶段,bRequestType的方向位也就无效了。
和struct usb_ctrlrequest的约会暂时就到这里,回到usb_control_msg函数里。很明显要进行控制传输,得首先创建一个struct usb_ctrlrequest结构体,填上请求的内容。129到133行就是来使用传递过来的参数初始化这个结构体的。对于刚开始提到的SET_ADDRESS来说,bRequest的值就是USB_REQ_SET_ADDRESS,标准请求之一,ch9.h里定义有。因为SET_ADDRESS请求并不需要DATA阶段,所以wLength为0,而且这个请求是针对设备的,所以wIndex也为0。这么一来,bRequestType的值也只能为0了。因为是设置设备地址的,总得把要设置的地址发给设备,不然设备会比咱们还一头雾水不知道主机是嘛个意思,所以请求的参数wValue就是之前hub已经你的设备指定好的devnum。其实SET_ADDRESS请求各个部分的值spec 9.4.6 里都有规定,就和我这里说的一样,不信你去看看。
接下来先看139行,走到这儿就表示成也好败也好,总之这次通信已经完成了,那么struct usb_ctrlrequest结构体也就没用了,没用的东西要好不犹豫的精简掉。
回头看137行,这是引领咱们往深处走了,不过不怕,路有多远,咱们看下去的决心就有多远。