On Wed, May 25, 2011 at 12:26:08PM +0300, Tanya Brokhman wrote: > > > As I mentioned, updating all of the gadget drivers will take a long > > > time and I don't fill confident enough doing since I'm not familiar > > > with all of them and don't have the ability to test each of them > > > properly. I can add SS descriptors to f_mass_storage, g_zero if it > > > helps and of course f_uasp already has them. > > > I'm a bit confused by this actually... We've been discussing this > > > patch series for quite a while now and I got the impression that > > > except for some minor comments you were all for excepting this. Was I > > > wrong or am I misunderstanding the above? > > > In any case, I don't feel that adding SS support for the Gadget > > > framework should be delayed until all gadget drivers add SS > > > descriptors because this patch series will give the developers the > > > ability to test these gadget drivers at SS. Also, several developers > > > addressed me offline with questions on this series so I know people > > > are using it in their work. And of course we do :) > > > > just remove the hunk which changes composite.c speed field and it > > should all be ok :-) > > > > 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 :-) -- balbi
Attachment:
signature.asc
Description: Digital signature
