Handling custom device control requests in userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux