> > But that's why we added the feature flag. Isn't leaving it FALSE the > > same as removing the part that updates gadget speed? It is protected > with #ifdef. > > you mean the module parameter ? This will mean that users will have to > remember another module parameter otherwise it will not work in some > situations :-) > > the module should work without that parameter :-) > No, I'm afraid we're talking about different things here. As far as dummy_hcd is concerned: Dummy_hcd has a new module parameter that should be set to true if the developer wishes the gadget driver to be connected to a SS root hub. Since at the moment most of the gadget drivers woun't work at SS connection (lack of SS descriptors) the default of this parameter is true and thus the connected gadget driver will be enumerated over a HS root hub. Users don't have to remember t set anything in order to be able to work with dummy_hcd and the existing gadget drivers just as they did up until now. We did add a new feature flag (CONFIG_USB_GADGET_SUPERSPEED) that is set during compilation. If that flag is defined, then (and only then!) will the driver->speed be set to SS by composite_bind. Please keep in mind the following: 1. if CONFIG_USB_GADGET_SUPERSPEED=true, existing gadget drivers are still functional with dummy_hcd since as I already mentioned, they will be enumerated through HS root hub and thus the gadget.speed will be set to HS. This is true for all gadget drivers, including the once that don't define SS descriptors. 2. if CONFIG_USB_GADGET_SUPERSPEED=false (which is the default) then all the code that is added by this patch series will never be executed since driver->speed won't be updated (and will remain HS). This is basically a way to disable SS support in the gadget framework. Hope this clears the confusion :) 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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
