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).


To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to