Hi Felipe > > Yes :) The driver->speed is updated in usb_composite_probe() if > > CONFIG_USB_GADGET_SUPERSPEED is defined. > > > > So, are we ok with this solution? The module parameter I mean? > > Are you going to try the v13 in your branch? Please let me know how > it > > goes and of course if you have any comments. > > I think it still gives the possibility for failure. I would rather not > take that until all gadget drivers are fixed. We can help you doing > that and we only change driver->speed after all gadget drivers have > their "sensible defaults" SuperSpeed descriptors. By "until all gadget drivers are fixed" you mean until all gadget drivers provide SS descriptors? This will take for ever... I wasn't about to modify all gadget drivers and to add SS descriptors for them. I can add default values (as generate_ss_descriptors() did if you remember) but I don't think this is the right approach because as you said - different gadget drivers might have different SS descriptors and I don't feel confident enough to set these values. Nor do I have the ability to test each of the gadget drivers the way I would like to after this change. The only gadget driver I felt confident adding SS descriptors for is UASP, which I tested properly. Actually if the CONFIG_USB_GADGET_SUPERSPEED is turned off, which is the default of it, the speed won't be updated and all these series won't be functional so I don't see any possibilities for failure in such configuration. Or am I missing something? Best regards, Tanya Brokhman Consultant for Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
