107 lines · plain
1====================2How FunctionFS works3====================4 5Overview6========7 8From kernel point of view it is just a composite function with some9unique behaviour. It may be added to an USB configuration only after10the user space driver has registered by writing descriptors and11strings (the user space program has to provide the same information12that kernel level composite functions provide when they are added to13the configuration).14 15This in particular means that the composite initialisation functions16may not be in init section (ie. may not use the __init tag).17 18From user space point of view it is a file system which when19mounted provides an "ep0" file. User space driver need to20write descriptors and strings to that file. It does not need21to worry about endpoints, interfaces or strings numbers but22simply provide descriptors such as if the function was the23only one (endpoints and strings numbers starting from one and24interface numbers starting from zero). The FunctionFS changes25them as needed also handling situation when numbers differ in26different configurations.27 28For more information about FunctionFS descriptors see :doc:`functionfs-desc`29 30When descriptors and strings are written "ep#" files appear31(one for each declared endpoint) which handle communication on32a single endpoint. Again, FunctionFS takes care of the real33numbers and changing of the configuration (which means that34"ep1" file may be really mapped to (say) endpoint 3 (and when35configuration changes to (say) endpoint 2)). "ep0" is used36for receiving events and handling setup requests.37 38When all files are closed the function disables itself.39 40What I also want to mention is that the FunctionFS is designed in such41a way that it is possible to mount it several times so in the end42a gadget could use several FunctionFS functions. The idea is that43each FunctionFS instance is identified by the device name used44when mounting.45 46One can imagine a gadget that has an Ethernet, MTP and HID interfaces47where the last two are implemented via FunctionFS. On user space48level it would look like this::49 50 $ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid51 $ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp52 $ ( cd /dev/ffs-mtp && mtp-daemon ) &53 $ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid54 $ ( cd /dev/ffs-hid && hid-daemon ) &55 56On kernel level the gadget checks ffs_data->dev_name to identify57whether its FunctionFS is designed for MTP ("mtp") or HID ("hid").58 59If no "functions" module parameters is supplied, the driver accepts60just one function with any name.61 62When "functions" module parameter is supplied, only functions63with listed names are accepted. In particular, if the "functions"64parameter's value is just a one-element list, then the behaviour65is similar to when there is no "functions" at all; however,66only a function with the specified name is accepted.67 68The gadget is registered only after all the declared function69filesystems have been mounted and USB descriptors of all functions70have been written to their ep0's.71 72Conversely, the gadget is unregistered after the first USB function73closes its endpoints.74 75DMABUF interface76================77 78FunctionFS additionally supports a DMABUF based interface, where the79userspace can attach DMABUF objects (externally created) to an endpoint,80and subsequently use them for data transfers.81 82A userspace application can then use this interface to share DMABUF83objects between several interfaces, allowing it to transfer data in a84zero-copy fashion, for instance between IIO and the USB stack.85 86As part of this interface, three new IOCTLs have been added. These three87IOCTLs have to be performed on a data endpoint (ie. not ep0). They are:88 89 ``FUNCTIONFS_DMABUF_ATTACH(int)``90 Attach the DMABUF object, identified by its file descriptor, to the91 data endpoint. Returns zero on success, and a negative errno value92 on error.93 94 ``FUNCTIONFS_DMABUF_DETACH(int)``95 Detach the given DMABUF object, identified by its file descriptor,96 from the data endpoint. Returns zero on success, and a negative97 errno value on error. Note that closing the endpoint's file98 descriptor will automatically detach all attached DMABUFs.99 100 ``FUNCTIONFS_DMABUF_TRANSFER(struct usb_ffs_dmabuf_transfer_req *)``101 Enqueue the previously attached DMABUF to the transfer queue.102 The argument is a structure that packs the DMABUF's file descriptor,103 the size in bytes to transfer (which should generally correspond to104 the size of the DMABUF), and a 'flags' field which is unused105 for now. Returns zero on success, and a negative errno value on106 error.107