Hi, On Thu, May 19, 2011 at 02:43:25PM +0300, Tatyana Brokhman wrote: > It was tested in the following ways: > 1. Dummy_hcd and g_zero gadget with our internally developed unittest. > (See bellow) > 2. Our DCD (that is not ready for upstreaming yet but we're working on > it) and g_mass_storage gadget. With this setup we passed USBCV 2.0 and 3.0. > 3. We developed a UAS gadget driver that is also working with this > implementation over our DCD and the UAS Linux host driver. Its operational > both in SS and in HS mode. Was released to the community in another patch series. > 4. All of the other existing gadget drivers were minimally testes on > the dummy_hcd setup as well (successful enumeration). > > The unittest framework that was used for testing can be downloaded from > git://codeaurora.org/quic/usb3/ut/.git > Please use the upstream branch. > See https://www.codeaurora.org/gitweb/quic/usb3/?p=ut/.git;a=summary for more > details. > > Tatyana Brokhman (7): > usb: Add usb_endpoint_descriptor to be part of the struct usb_ep > usb: Configure endpoint according to gadget speed. > usb: Modify existing gadget drivers to use config_ep_by_speed() > instead of ep_choose. > usb:gadget: Add SuperSpeed support to the Gadget Framework > usb: Add streams support to the gadget framework > usb:dummy_hcd: use the shared_hcd infrustructure > usb: Adding SuperSpeed support to dummy_hcd Superspeed dummy_hcd doesn't like high-speed gadget drivers. I just tested without your autogeneration of usb3 descriptors and dummy_hcd doesn't hand the port over to the "companion" USB2 dummy_hcd controller making the gadget driver impossible to get enumerated and we want that to work seamlessly. I would really like to see this in 2.6.40 as it would help my own development, but the way things looks I can't simply introduce such a big bug on kernel. If you manage to fix this in the upcoming few days, I can still push myself to test it on monday and get the pull request for Greg on tuesday. Thanks -- balbi