Linux那些事儿 之 戏说USB(23)设备的生命线(二)
现在设备的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行，这是引领咱们往深处走了，不过不怕，路有多远，咱们看下去的决心就有多远。