On Fri, Jan 02, 2009 at 01:52:18PM +0000, David Vrabel wrote: > Sarah Sharp wrote: > > > > 2. USB 3.0 devices have a new "Endpoint Companion Descriptor". This > > specifies some new characteristics for each USB 3.0 endpoint. For > > example, the EP companion descriptor specifies how many "bursts" of the > > maximum packet size a bulk endpoint can receive before it must wait for > > an explicit acknowledgment of the first packet. > > Please refer to this descriptor as the "SuperSpeed Endpoint Companion > Descriptor" to distinguish it from the similar "Wireless Endpoint > Companion Descriptor" as used in Certified Wireless USB. Will do. > The wireless USB host drivers simply look in ep->extra. See > qset_fill_qh() in drivers/usb/host/whci/qset.c for an example. Ok, I'll take a look at that. I did write some parsing code already that added a pointer to a SuperSpeed Endpoint Companion Descriptor structure in struct usb_host_endpoint. I did this because I noticed the endpoint descriptor parsing did some checking to ensure the field values were following the specification rules, and I thought doing similar checking for the endpoint companion descriptor fields once would be more efficient than doing them every time I use them. I didn't change lsusb to parse the endpoint companion descriptors, so it just printed out the individual bytes. I think lsusb also hung on the last endpoint of the last interface of the last config, but I can't remember if that had anything to do with the bugs I was seeing on the host controller or prototype device at the time. > Do you also have to parse BOS descriptors? The BOS code in wusbcore > could do with being made more generic. I will eventually need some fields out of the SuperSpeed USB Device Capability descriptor in the BOS descriptor, so it would be nice to break out the BOS parsing code in wusbcore. No rush on it; my current code doesn't use the BOS descriptor. The U1 and U2 exit latencies are worth digging out, once we add support for link power management. All USB 3.0 devices must support LPM. If Linux doesn't support link power management right away, people's battery life will be impacted, but devices will still just work. I would still like to get this functionality in early, so I can test early prototypes' power management capabilities and we can avoid a repeat of the autosuspend disaster. The Latency Tolerance Messaging (LTM) support field might be looking at. Since there are no start-of-frame symbols on the USB 3.0 wires, isoc endpoints need a way to sync with the host clock. I haven't heard of any vendors who want to use this functionality yet, so it's low on my todo list. The wSpeedSupported field indicates all the speeds that the USB 3.0 device can run at. I think it's only useful if we want the kernel to spit out a warning message when a user plugs a USB 3.0 device into a USB 2.0 port. It might be useful for debugging purposes to see if a device still misbehaves at low, full, or high speed. The field is really there for the USB-IF to add speeds past 5.0 Gbps. ;) Then there's the bFunctionalitySupport field. They were trying to have device vendors indicate what speed their device works best at (e.g. you can run a USB 3.0 video camcorder at high speed, but the user won't get the best video quality). It's not very useful IMHO. Sarah Sharp -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
