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.
Thanks,
Tanya Brokhman
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
