Hi Jerry, W dniu 04.04.2018 o 02:04, Jerry Zhang pisze:
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.
If I understand correctly the purpose of creating a dedicated configuration is to allow linking the functions to it and this way marking these functions "special" (not assigned to a configuration proper).
- 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.
While I understand that engineers should discuss facts rather than feelings, the idea of creating a special configuration doesn't feel right to me, because this way you are creating a configuration which is not meant to be ever selected by the host. I can be convinced with arguments, though. I would like to draw your attention to one fact: a functionfs instance directory in configfs is intentionally empty, since the functionfs delegates actual implementation, including descriptors and strings, to userspace. I would advise to consider (or at least prove wrong) the idea of adding some attribute (file) to functionfs's configfs directory and using it for marking this functionfs instance as special. This would require implementing some exclusion mechanism (if this ffs instance is linked to a configuration, it is impossible to mark it as special and vice versa). Regards, Andrzej -- 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
