On Tue, 5 Apr 2011, Sarah Sharp wrote: > On Sat, Mar 19, 2011 at 12:27:45PM -0400, Alan Stern wrote: > > The exact requirement, as stated in the USB 3.0 specification, is this: > > > > The device descriptor of a SuperSpeed capable device has > > a version number of 3.0 (0300H). > > > > It seems pretty clear that the bcdUSB value doesn't depend on the > > device's current speed; it depends only on whether the device is > > capable of running at SuperSpeed. > > But these gadgets won't work at USB 3.0 speeds when plugged into a USB > 3.0 host, correct? I don't know about that. Obviously the gadget would need to have descriptors appropriate for SuperSpeed operation, but with autoconfiguration this doesn't have to be too hard. However you're asking about the gadgets' operation. Obviously the device controller would have to support SuperSpeed. Apart from that, however, I don't think much change in the gadget drivers would be needed. > Why change that now, instead of later when the > devices actually do support SuperSpeed? In what sense don't they support SuperSpeed now? Yes, there's a bug in g_file_storage caused by the assumption that a bulk endpoint's maxpacket size will always divide 512, but a patch to fix that has already been posted. Other gadgets might require similar minor changes, but it shouldn't be a big deal. The worst problem will probably be adding the extra descriptors used by USB-3. > I don't know if it even makes sense for all these gadgets to be > SuperSpeed devices later. USB 3.0 is still fairly new, and the USB > device class specifications haven't been updated for that yet. Doesn't matter -- the gadgets already comply with the existing class specifications. AFAIK, those specifications do _not_ say that they apply only to USB-1.1 or USB-2. > For > example, how is a USB 3.0 webcam supposed to work, now that there are > additional isochronous transfer opportunities per frame (over USB 2.0 > isoc devices). We don't know yet. As a reasonable first attempt, it could work exactly the same as it does at high speed. Nothing says it has to make use of all the available isochronous transfer opportunities. > There are some devices that I doubt will ever be marketable as USB 3.0 > devices. A USB 3.0 to serial adapter? A USB 3.0 mouse? (Maybe for the > power savings, but I doubt any company will want the added expense for > the USB 3.0 PHY.) Who says Linux-based gadgets have to be marketable? I've never heard of a high-speed mouse, but if somebody implemented a mouse gadget, there wouldn't be anything to stop it from running at high speed. (Apart from the cabling issue perhaps -- low-speed cables are allowed to be more flexible than full- or high-speed cables, which usually doesn't matter much but is important for a mouse.) > So why change the bcdUSB value prematurely for all > gadget drivers? Why not add support to the gadget interface and then > see which gadget drivers really need USB 3.0 support? As has been pointed out, the bcdUSB value should depend on the UDC's capabilities. It should also depend on the available of SuperSpeed descriptors in the gadget driver. Beyond that, I see no reason for any limitations. Alan Stern -- 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
