Hi, Krzysztof Opasiak <k.opasiak@xxxxxxxxxxx> writes: >>>>>>> A few advantages over a couple options I've considered are that this mostly >>>>>>> reuses existing functionalities and won't affect users that haven't enabled >>>>>>> it. Please let me know of any feedback on the design or any possible >>>>>>> implementation issues. >>>>>> >>>>>> IMHO, considering the amount of Android users, we can merge this into >>>>>> composite.c itself. Just make the code depend on CONFIG_ANDROID. Or >>>>>> something along the lines of >>>>>> >>>>>> if (IS_ENABLED(CONFIG_ANDROID)) >>>>>> android_audio_accessory_init(); >>>>>> >>>>>> should get the job done. >>>>> >>>>> Huh and what with people that are not android but need to support >>>>> Android accessory in their products? >>>> >>>> Do those really exist? >>>> >>>> Well, if they _really_ exist, we can add a "Enable Support for Android >>>> Audio Accessory" specific to the gadget framework. Then test for: >>>> >>>> if (IS_ENABLED(CONFIG_USB_GADGET_ANDROID_AUDIO_ACCESSORY)) >>>> >>>> or whatever. I'm not certain such devices exist though, need >>>> confirmation. >>>> >>> >>> Yes, they exist. Most of Tizen phones support android accessory. >> >> Fair enough. A specific Kconfig for that is okay. >> > > Let me just mention that if we had a generic interface we could cover > not only android requirements but also do a great job for people who are > fuzzing USB hosts. Such an interface would allow to easily craft some > random requests without all this noise related to using GadgetFS... okay, but we don't... Do you wanna send some patches? -- balbi
Attachment:
signature.asc
Description: PGP signature
