On Tue, 21 Jun 2011, Sebastian Andrzej Siewior wrote: > Tanya Brokhman wrote: > > Hi Sebastian, > > Hi Tanya, > > >> Let create both udcs 2.0 and 3.0. So if we have a 3.0 gadget it can > >> passed to the 3.0 hcd and and 2.0 and the 2.0 hcd. > >> > > > > Actually, the changes in this patch is what I've done in one of the > > dummy_hcd patch versions. But then I had a long discussion with Alan who > > convinced me _not_ to register SS HCD always. If I remember correctly the > > main motivation was that there is no need to register SS HCD if it's not > > used and if the is_super_speed module parameter is false - SS HCD won't be > > used. I've already explained why I would prefer not to remove the > > is_super_speed module parameteron the patch that removes it. > > > > I've deleted those conversations from my mailbox but I can search for them > > if you want me too. Anyway - Alan will object to this patch. He already did > > when I uploaded this code and I tend to agree with him :) > > I don't get this. It is exact the same behavior like we have for real > hardware. It tries to connect at the highest possible speed. You can > argue about enable/disable SS/HS for debugging / developing & testing. But > it should be the default behavior to bind an SS gadget to 3.0 hcd since > this is the what happens on 3.0 hardware. Without additional hacks i.e. > module arguments. But dummy-hcd isn't real hardware. With real hardware, if you own a USB-2 UDC and then you upgrade to a USB-3 UDC, you still have the old USB-2 UDC available as a backup and for testing. Unless something like the module parameter is present, with dummy-hcd you don't have that capability. Furthermore, with real hardware you can connect a USB-3 device via a USB-2 cable and thus force it to run at high speed instead of SuperSpeed. With dummy-hcd, the analogous action requires the module parameter. 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
