> > 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. Auto configuration isn't complicated. That's what we did in our implementation of the "SS support to the Gadget Framework" patch series. > > 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. The only changes required for existing gadget drivers to operate in SS are: 1. adding the SS descriptors - can be done automatically by create_ss_descriptors() implemented in our patch series. 2. choosing the SS descriptors when operating in SS mode. So the changes are indeed not that serious. > > > 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. Which isn't really an issue if a gadget driver wishes to use default values for SS descriptors (use create_ss_descriptors()) > > 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. For example, we tested the existing g_mass_storage gadget and activated it over SS port. We generated the missing SS descriptors for it automatically and no additional changes were needed to the MS gadget. It worked just fine. We also run USBCV tests on it: - ch9 test suite passed - MS test suite: 3 tests failed (Interface descriptor test - Device Addressed, Interface descriptor test - Device Configured, Error recovery test - device configured) Best regards, Tanya Brokhman Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- 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
