Hi Sebastian, > > 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. > Agreed, but the above should be accomplished by setting the is_super_speed parameter default value to TRUE, not by always registering SS hcd. It seems a bit difficult to argue with the fact that if is_super_speed=false SS HCD will never be used :) thus it seems logical not to register it as well. Right now the default value of is_super_speed parameter is FALSE because at the moment most of the existing gadget drivers don't support superspeed. I think that changing it to TRUE won't cause any harm since now gadget drivers report their maximum_supprted_speed and are enumerated according to that. But it's up to Felipe to decide if this change is ok at this point. Thanks, Tanya Brokhman --- Sent by an consultant of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. -- 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
