Hi again,

Felipe Balbi <ba...@kernel.org> writes:
> Krzysztof Opasiak <k.opas...@samsung.com> 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
>>>>>>>         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:
>>>>> 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?

another thing to keep in mind is that we're trying to be a USB-compliant
stack. Gadget Framework was never meant to be a testing ground for the
Host Stack. There are VERY flexible tools designed specifically for that
in market.

Maybe, companies who are investing in Fuzzying, should just invest in
one of those tools instead of rellying on a stack that WANTS to send
compliant USB-packets at all times?


Attachment: signature.asc
Description: PGP signature

Reply via email to