Something went wrong. Try again.
(I'm so sorry!) Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux
Something went wrong. Try again.
8.8 kB · 186 lines
at master
123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187====================How FunctionFS works====================
Overview========
From kernel point of view it is just a composite function with someunique behaviour. It may be added to an USB configuration only afterthe user space driver has registered by writing descriptors andstrings (the user space program has to provide the same informationthat kernel level composite functions provide when they are added tothe configuration).
This in particular means that the composite initialisation functionsmay not be in init section (ie. may not use the __init tag).
From user space point of view it is a file system which whenmounted provides an "ep0" file. User space driver need towrite descriptors and strings to that file. It does not needto worry about endpoints, interfaces or strings numbers butsimply provide descriptors such as if the function was theonly one (endpoints and strings numbers starting from one andinterface numbers starting from zero). The FunctionFS changesthem as needed also handling situation when numbers differ indifferent configurations.
For more information about FunctionFS descriptors see :doc:`functionfs-desc`
When descriptors and strings are written "ep#" files appear(one for each declared endpoint) which handle communication ona single endpoint. Again, FunctionFS takes care of the realnumbers and changing of the configuration (which means that"ep1" file may be really mapped to (say) endpoint 3 (and whenconfiguration changes to (say) endpoint 2)). "ep0" is usedfor receiving events and handling setup requests.
When all files are closed the function disables itself.
What I also want to mention is that the FunctionFS is designed in sucha way that it is possible to mount it several times so in the enda gadget could use several FunctionFS functions. The idea is thateach FunctionFS instance is identified by the device name usedwhen mounting.
One can imagine a gadget that has an Ethernet, MTP and HID interfaceswhere the last two are implemented via FunctionFS. On user spacelevel it would look like this::
$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid $ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp $ ( cd /dev/ffs-mtp && mtp-daemon ) & $ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid $ ( cd /dev/ffs-hid && hid-daemon ) &
On kernel level the gadget checks ffs_data->dev_name to identifywhether its FunctionFS is designed for MTP ("mtp") or HID ("hid").
If no "functions" module parameters is supplied, the driver acceptsjust one function with any name.
When "functions" module parameter is supplied, only functionswith listed names are accepted. In particular, if the "functions"parameter's value is just a one-element list, then the behaviouris similar to when there is no "functions" at all; however,only a function with the specified name is accepted.
The gadget is registered only after all the declared functionfilesystems have been mounted and USB descriptors of all functionshave been written to their ep0's.
Conversely, the gadget is unregistered after the first USB functioncloses its endpoints.
Endpoint IOCTLs===============
FunctionFS supports additional IOCTLs that can be performed on data endpoints(ie. not ep0). For a full list of these IOCTLs, please refer to the documentationin ``include/uapi/linux/usb/functionfs.h``.
One such IOCTL is:
``FUNCTIONFS_ENDPOINT_ENABLE_ZLP(__u32 *)`` Enable or disable automatic zero-length packet (ZLP) appending for the endpoint. The argument is a pointer to a __u32: 0 to disable, non-zero to enable. When enabled, the kernel will automatically append a ZLP at the end of a transfer if the payload length is an exact multiple of the endpoint's max packet size. This is useful for compatibility with legacy protocols which require automatic ZLP appending to data written from userspace. This IOCTL can only be used on IN endpoints. It can be called at any time after the FunctionFS instance is active, even before the host has connected or enabled the endpoint. Returns zero on success, or a negative errno value on error:
* ``-ENODEV``: The FunctionFS instance is not active. * ``-EINVAL``: The endpoint is not an IN endpoint. * ``-EFAULT``: Invalid user space pointer for the argument.
RW Proxy Endpoints==================
If the ``FUNCTIONFS_RW_PROXY_EPS`` flag is passed in the descriptor header(requires ``FUNCTIONFS_DESCRIPTORS_MAGIC_V2``), FunctionFS will provision abidirectional rw_proxy file descriptor (e.g., "ep1_rw") alongside each pairof IN and OUT endpoints. The rw_proxy file aliases the underlying hardwareendpoints, allowing userspace to use a single file descriptor for both reading(OUT) and writing (IN).
This flag requires the total number of hardware endpoints to be an even number.FunctionFS will automatically walk the provided endpoints and group them intoadjacent pairs (e.g., ep1 and ep2 form the first pair, ep3 and ep4 form thesecond pair). Each pair must consist of exactly one IN endpoint and one OUTendpoint.
For each valid pair, a rw_proxy file is created and named after the firstendpoint in the pair with a "_rw" suffix. For example, if ep1 and ep2 arepaired, a rw_proxy file named "ep1_rw" is created. If ep3 and ep4 are paired,"ep3_rw" is created.
If the ``FUNCTIONFS_VIRTUAL_ADDR`` flag is also enabled, the endpoints will benamed using their physical endpoint address in hexadecimal instead of theirindex. RW proxy files will inherit this naming convention. For example, if thefirst endpoint of a pair maps to address 0x02, the rw_proxy file will benamed "ep02_rw".
When this flag is enabled, userspace has the choice of performing data transfersvia the single rw_proxy file descriptor or the two base file descriptors. Therw_proxy file descriptor acts as a pure VFS alias that proxies all operationsdirectly to the underlying base file descriptors.
Because it is a pure proxy, there are no data races or buffer corruptions ifuserspace uses both the rw_proxy endpoint and the base endpoints concurrently.The native mutexes of the base endpoints perfectly serialize all concurrenttransfers. However, userspace should generally pick one method and stick to itto avoid interleaving its own data stream.
- **IOCTLs (Clear Halt, etc.):** RW proxy endpoints do not support IOCTLs and will return ``-ENOTTY``. To clear a host-initiated halt, userspace must issue the ``FUNCTIONFS_CLEAR_HALT`` ioctl directly on the corresponding base endpoint file descriptor.- **Intentional Stalls:** The traditional mechanism for intentionally halting an endpoint by issuing a reverse-direction data operation (e.g., attempting to read from an IN endpoint) continues to work, but it must be issued on the base endpoint. RW proxy endpoints cannot be used to trigger a stall because they are fully bidirectional.
Note that DMABUF data transfers (``FUNCTIONFS_DMABUF_TRANSFER``) are unsupportedvia the rw_proxy endpoint because it does not support IOCTLs. If DMABUFtransfers are required, users must use the standard base endpoints.DMABUF interface================
FunctionFS additionally supports a DMABUF based interface, where theuserspace can attach DMABUF objects (externally created) to an endpoint,and subsequently use them for data transfers.
Note: The DMABUF interface is unsupported on rw_proxy endpoints. Seethe RW Proxy Endpoints section for details on using DMABUF alongsidethe ``FUNCTIONFS_RW_PROXY_EPS`` flag.
A userspace application can then use this interface to share DMABUFobjects between several interfaces, allowing it to transfer data in azero-copy fashion, for instance between IIO and the USB stack.
As part of this interface, three new IOCTLs have been added. These threeIOCTLs have to be performed on a data endpoint (ie. not ep0). They are:
``FUNCTIONFS_DMABUF_ATTACH(int)`` Attach the DMABUF object, identified by its file descriptor, to the data endpoint. Returns zero on success, and a negative errno value on error.
``FUNCTIONFS_DMABUF_DETACH(int)`` Detach the given DMABUF object, identified by its file descriptor, from the data endpoint. Returns zero on success, and a negative errno value on error. Note that closing the endpoint's file descriptor will automatically detach all attached DMABUFs.
``FUNCTIONFS_DMABUF_TRANSFER(struct usb_ffs_dmabuf_transfer_req *)`` Enqueue the previously attached DMABUF to the transfer queue. The argument is a structure that packs the DMABUF's file descriptor, the size in bytes to transfer (which should generally correspond to the size of the DMABUF), and a 'flags' field which is unused for now. Returns zero on success, and a negative errno value on error.