On Thu, 7 Apr 2011, Tanya Brokhman wrote: > > > 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. Right, that's what I thought. ... > 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) Those tests should not have failed. Do they pass when you run at high speed instead of SuperSpeed? Do they pass if you use g_file_storage instead of g_mass_storage? Just in the last few days there has been one or more patches posted to fix USBCV failures in g_mass_storage. 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
