> > 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. 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
