Hi Jerry, Jerry Zhang <zhangjerry@xxxxxxxxxx> writes: > Hi all, > > I've been looking for a way to handle custom device targeted control > requests from userspace. This would allow us to move away from needing > kernel patches to implement > https://source.android.com/devices/accessories/aoa. It seems like we are > close to being able to do this. With the flag FUNCTIONFS_ALL_CTRL_RECIP, an > f_fs function can handle all requests (device, interface, etc.) that are > not otherwise claimed, and functionfs already implements a pretty good > interface for userspace control requests through ep0. The issue is that > currently the function must be in the config in order to handle requests. > However, at any point in time we don't know which functionfs function is in > the config, or even that the config contains any ffs functions at all. > > Here are my (early) thoughts on how to implement this feature. The goal is > to allow a function not in a configuration to handle control requests. > > - Each configfs gadget contains a special config_desc called > "control_config". This acts as a normal config_desc except it is not added > back to cdev and instead is a new field in struct gadget_info. > > - Functions can be linked into control_config. This is the same as a normal > usb_cfg_link. Functions linked this way can't be used in a normal config > since each function only has one list item. > > - On configfs_bind, all functions in control_config are also bound. On > configfs_unbind, all functions in control_config are also unbound. Because > they aren't in cdev they don't appear in descriptors. > > - Configfs will now have configfs_setup, which first attempts > composite_setup. If that fails, it will go through functions in > control_config and do the normal req_match / setup procedure. Since each > function here is bound and has a reference to cdev, it can successfully > match and handle control requests. > > Thus a user that wants to handle all control requests can make a functionfs > instance "ctrlf" with dummy descriptors, and include the flag > ALL_CTRL_RECIP. Then they can link functions/ffs.ctrlf g1/control_config/f1 > and handle control requests at /dev/usb-ffs/ctrlf/ep0. > > 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. -- balbi
Attachment:
signature.asc
Description: PGP signature
