Hi Jerry,

Jerry Zhang <zhangje...@google.com> 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


should get the job done.


Attachment: signature.asc
Description: PGP signature

Reply via email to