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. Thanks, Jerry -- 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
