Linux那些事儿之戏说USB(19)设备的生命线(二)

现在设备的struct usb_device结构体已经准备好了&＃xff0c;只是还不怎么饱满&＃xff0c;hub接下来就会给它做做整容手术&＃xff0c;往里边儿塞点什么&＃xff0c;充实一些内容&＃xff0c;比如&＃xff1a;将设备的状态设置为Powered&＃xff0c;也就是加电状态&＃xff1b;因为此时还不知道设备支持的速度&＃xff0c;于是将设备的speed成员暂时先设置为USB_SPEED_UNKNOWN&＃xff1b;设备的级别level当然会被设置为hub的level加上1了&＃xff1b;还有为设备能够从hub那里获得的电流赋值&＃xff1b;为了保证通信畅通&＃xff0c;hub还会为设备在总上选择一个独一无二的地址。

给张表吧&＃xff0c;集中列了下到目前为止&＃xff0c;设备结构体里成员的状况。里面的taken只是表示赋过值了&＃xff0c;好像期末考试前你去突击自习&＃xff0c;这时一个ppmm走到你旁边&＃xff0c;用一个美妙的声音问你“Is this seat taken?”&＃xff0c;你怎么回答&＃xff1f;当然是“No, No, please.”对头&＃xff0c;taken就是这个意思。

devnum	taken
devpath[16]	taken
state	USB_STATE_POWERED
speed	USB_SPEED_UNKNOWN
parent	设备连接的那个hub
bus	设备连接的那条总线
ep0	ep0.urb_list&＃xff0c;描述符长度/类型
dev	dev.bus&＃xff0c;dev.type&＃xff0c;dev.dma_mask,&＃xff0c;dev.parent&＃xff0c;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 &＃43; 1
filelist	taken
pm_mutex	taken
autosuspend	taken
autosuspend_delay	2 * HZ

你的设备现在已经处在了Powered状态。前面讲过的&＃xff0c;设备要想从Powered状态发展到下一个状态Default&＃xff0c;必须收到一个复位信号并成功复位。那hub接下来的动作就很明显了&＃xff0c;复位设备&＃xff0c;复位成功后&＃xff0c;设备就会进入Default状态。
设备复位顺利的话也就那么几十毫秒的功夫&＃xff0c;不顺利的话&＃xff0c;它会多尝试几次。不过如果试了几次都复位不成&＃xff0c;那就不用试了&＃xff0c;这条设备的生命线就算提前玩完儿了。
现在就算设备成功复位了&＃xff0c;大步迈进了Default状态&＃xff0c;同时&＃xff0c;hub也会获得设备真正的速度&＃xff0c;低速、全速也好&＃xff0c;高速也罢&＃xff0c;总算是浮出水面了&＃xff0c;speed也终于知道了自己的真正身份&＃xff0c;不用再是UNKNOWN了。那根据这个速度&＃xff0c;咱们能知道些什么&＃xff1f;起码能够知道端点0一次能够处理的最大数据长度啊&＃xff0c;协议里说&＃xff0c;对于高速设备&＃xff0c;这个值为为64字节&＃xff0c;对于低速设备为8字节&＃xff0c;而对于全速设备可能为8&＃xff0c;16&＃xff0c;32&＃xff0c;64其中的一个。所以hub还要通过一个蜿蜒曲折的过程去获得这个确定的值。
hub也辛苦的蛮久了&＃xff0c;设备也该进入Address状态了。
只要hub使用core里定义的一个函数usb_control_msg&＃xff0c;发送SET_ADDRESS请求给设备&＃xff0c;设备就兴高采烈的迈进Address了。那么设备的这个address是什么&＃xff0c;就是上面的devnum啊。
那现在咱就来说说这个usb_control_msg函数&＃xff0c;它在drivers/usb/core/message.c里定义

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)
{struct usb_ctrlrequest *dr;int ret;dr &＃61; kmalloc(sizeof(struct usb_ctrlrequest), GFP_NOIO);if (!dr)return -ENOMEM;dr->bRequestType &＃61; requesttype;dr->bRequest &＃61; request;dr->wValue &＃61; cpu_to_le16(value);dr->wIndex &＃61; cpu_to_le16(index);dr->wLength &＃61; cpu_to_le16(size);ret &＃61; usb_internal_control_msg(dev, pipe, dr, data, size, timeout);kfree(dr);return ret;
}这个函数主要目的是创建一个控制urb&＃xff0c;并把它发送给usb设备&＃xff0c;然后等待它完成。urb是什么&＃xff1f;忘了么&＃xff0c;前面提到过的&＃xff0c;你要想和你的usb通信&＃xff0c;就得创建一个urb&＃xff0c;并且为它赋好值&＃xff0c;交给usb core&＃xff0c;它会找到合适的host controller&＃xff0c;从而进行具体的数据传输。

8行&＃xff0c;为一个struct usb_ctrlrequest结构体申请了内存。它在include/uapi/linux/usb/ch9.h文件里定义

struct usb_ctrlrequest {__u8 bRequestType;__u8 bRequest;__le16 wValue;__le16 wIndex;__le16 wLength;
} __attribute__ ((packed));这个结构完全对应于spec里的Table 9-2&＃xff0c;描述了主机通过控制传输发送给设备的请求&＃xff08;Device Requests&＃xff09;。主机向设备请求些信息必须得按照协议里规定好的格式&＃xff0c;不然设备就会不明白主机是嘛意思。

这个结构描述的request都在Setup包里发送&＃xff0c;Setup包是前面某处说到的Token PID类型中的一种&＃xff0c;为了你好理解&＃xff0c;这里细说一下控制传输底层的packet情况。控制传输最少要有两个阶段的transaction&＃xff0c;SETUP和STATUS&＃xff0c;SETUP和STATUS中间的那个DATA阶段是可有可无的。Transaction这个词儿在很多地方都有&＃xff0c;在这里你称它为事务也好&＃xff0c;会话也罢&＃xff0c;我还是直呼它的原名transaction&＃xff0c;可以理解为主机和设备之间形成的一次完整的交流&＃xff0c;比如2004中华小姐环球大赛总决赛上评委蔡澜和陕西选手姚佳雯之间的对话&＃xff1a;

要老公还是要钱&＃xff1f;要钱。

这就可以算是一次transaction&＃xff0c;usb的transaction要比上面的对话复杂&＃xff0c;起码要过过脑子&＃xff0c;它可以包括一个Token包、一个Data包和一个Handshake包。

Token、Data和Handshake都属于四种PID类型中的&＃xff0c;前面说到时提到的一个包里的那些部分&＃xff0c;如SYNC、PID、地址域、DATA、CRC&＃xff0c;并不是所有PID类型的包都会全部包括的。Token包只包括SYNC、PID、地址域、CRC&＃xff0c;并没有DATA字段&＃xff0c;它的名字起的很形象&＃xff0c;就是用来标记所在transaction里接下来动作的&＃xff0c;对于Out和Setup Token包&＃xff0c;里面的地址域指明了接下来要接收Data包的端点&＃xff0c;对于In Token包&＃xff0c;地址域指明了接下来哪个端点要发送Data包。还有&＃xff0c;只有主机才有权利发送Token包&＃xff0c;协议里就这么规定的。

与Token包相比&＃xff0c;Data包里没了地址域&＃xff0c;多了Data字段&＃xff0c;这个Data字段对于低速设备最大为8字节&＃xff0c;对于全速设备最大为1023字节&＃xff0c;对于高速设备最大为1024字节。里里外外看过去&＃xff0c;它就是躲在Token后边儿用来传输数据的。Handshake包的成分就非常的简单了&＃xff0c;简直和那位姚佳雯的回答一样简单&＃xff0c;除了SYNC&＃xff0c;它就只包含了一个PID&＃xff0c;通过PID取不同的值来报告一个transaction的状态&＃xff0c;比如数据已经成功接收了等。

控制传输的SETUP transaction一般来说也有三个阶段&＃xff0c;就是主机向设备发送Setup Token包、然后发送Data0包&＃xff0c;如果一切顺利&＃xff0c;设备回应ACK Handshake包表示OK&＃xff0c;为什么加上一般&＃xff1f;如果中间的那个Data0包由于某种不可知因素被损坏了&＃xff0c;设备就什么都不会回应&＃xff0c;这时就成俩阶段了。SETUP transaction之后&＃xff0c;接下来如果控制传输有DATA transaction的话&＃xff0c;那就Data0、Data1这样交叉的发送数据包&＃xff0c;前面说过这是为了实现data toggle。最后是STATUS transaction&＃xff0c;向主机汇报前面SETUP和DATA阶段的结果&＃xff0c;比如表示主机下达的命令已经完成了&＃xff0c;或者主机下达的命令没有完成&＃xff0c;或者设备正忙着那没功夫去理会主机的那些命令。

这样经过SETUP、DATA、STATUS这三个transaction阶段&＃xff0c;一个完整的控制传输完成了。主机接下来可以规划下一次的控制传输。

现在对隐藏在控制传输背后的是是非非摸了个底儿&＃xff0c;群众的眼睛是雪亮的&＃xff0c;咱们现在应该可以看出之前说requests都在Setup包里发送是有问题的&＃xff0c;因为Setup包本身并没有数据字段&＃xff0c;严格来说它们应该都是在SETUP transaction阶段里Setup包后的Data0包里发送的。



bRequestType&＃xff0c;它的bit7就表示了控制传输中DATA transaction阶段的方向&＃xff0c;当然&＃xff0c;如果有DATA阶段的话。bit5~6表示request的类型&＃xff0c;是标准的&＃xff0c;class-specific的还是vendor-specific的。bit0~4表示了这个请求针对的是设备&＃xff0c;接口&＃xff0c;还是端点。内核为它们专门量身定做了一批掩码&＃xff0c;也在ch9.h文件里&＃xff0c;

/** USB directions** This bit flag is used in endpoint descriptors&＃39; bEndpointAddress field.* It&＃39;s also one of three fields in control requests bRequestType.*/
#define USB_DIR_OUT 0 /* to device */
#define USB_DIR_IN 0x80 /* to host *//** USB types, the second of three bRequestType fields*/
#define USB_TYPE_MASK (0x03 <<5)
#define USB_TYPE_STANDARD (0x00 <<5)
#define USB_TYPE_CLASS (0x01 <<5)
#define USB_TYPE_VENDOR (0x02 <<5)
#define USB_TYPE_RESERVED (0x03 <<5)/** USB recipients, the third of three bRequestType fields*/
#define USB_RECIP_MASK 0x1f
#define USB_RECIP_DEVICE 0x00
#define USB_RECIP_INTERFACE 0x01
#define USB_RECIP_ENDPOINT 0x02
#define USB_RECIP_OTHER 0x03
/* From Wireless USB 1.0 */
#define USB_RECIP_PORT 0x04
#define USB_RECIP_RPIPE 0x05bRequest&＃xff0c;表示具体是哪个request。

wValue&＃xff0c;这个字段是request的参数&＃xff0c;request不同&＃xff0c;wValue就不同。

wIndex&＃xff0c;也是request的参数&＃xff0c;bRequestType指明request针对的是设备上的某个接口或端点的时候&＃xff0c;wIndex就用来指明是哪个接口或端点。

wLength&＃xff0c;控制传输中DATA transaction阶段的长度&＃xff0c;方向已经在bRequestType那儿指明了。如果这个值为0&＃xff0c;就表示没有DATA transaction阶段&＃xff0c;bRequestType的方向位也就无效了。

和 struct usb_ctrlrequest 的约会暂时就到这里&＃xff0c;回到usb_control_msg函数里。很明显要进行控制传输&＃xff0c;得首先创建一个struct usb_ctrlrequest结构体&＃xff0c;填上请求的内容。12到16行就是来使用传递过来的参数初始化这个结构体的。对于刚开始提到的SET_ADDRESS来说&＃xff0c;bRequest的值就是USB_REQ_SET_ADDRESS&＃xff0c;标准请求之一&＃xff0c;ch9.h里定义有。因为SET_ADDRESS请求并不需要DATA阶段&＃xff0c;所以wLength为0&＃xff0c;而且这个请求是针对设备的&＃xff0c;所以wIndex也为0。这么一来&＃xff0c;bRequestType的值也只能为0了。因为是设置设备地址的&＃xff0c;总得把要设置的地址发给设备&＃xff0c;不然设备会比咱们还一头雾水不知道主机是嘛个意思&＃xff0c;所以请求的参数wValue就是之前hub已经你的设备指定好的devnum。其实SET_ADDRESS请求各个部分的值spec 9.4.6里都有规定&＃xff0c;就和我这里说的一样&＃xff0c;不信你去看看。

接下来先看20行&＃xff0c;走到这儿就表示成也好败也好&＃xff0c;总之这次通信已经完成了&＃xff0c;那么struct usb_ctrlrequest结构体也就没用了&＃xff0c;没用的东西要好不犹豫的精简掉。

回头看18行&＃xff0c;这是引领咱们往深处走了&＃xff0c;不过不怕&＃xff0c;路有多远&＃xff0c;咱们看下去的决心就有多远。