Alan Stern wrote:
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.
Felipe pointed out automated testing. Since a script can't use a different
cable wouldn't it be nice to have a central knob for that?
Alan Stern
Sebastian
--
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
