Hi, On Wed, May 25, 2011 at 12:43:10PM +0300, Tanya Brokhman wrote: > > > 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 and that's the only thing I'm asking you to remove :-) we should be to compile dummy_hcd in SuperSpeed and still have high-speed gadget drivers :-) > 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. only due the module parameter, right ? -- balbi
Attachment:
signature.asc
Description: Digital signature
