1====================
  2How FunctionFS works
  3====================
  4
  5Overview
  6========
  7
  8From kernel point of view it is just a composite function with some
  9unique behaviour.  It may be added to an USB configuration only after
 10the user space driver has registered by writing descriptors and
 11strings (the user space program has to provide the same information
 12that kernel level composite functions provide when they are added to
 13the configuration).
 14
 15This in particular means that the composite initialisation functions
 16may 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 when
 19mounted provides an "ep0" file.  User space driver need to
 20write descriptors and strings to that file.  It does not need
 21to worry about endpoints, interfaces or strings numbers but
 22simply provide descriptors such as if the function was the
 23only one (endpoints and strings numbers starting from one and
 24interface numbers starting from zero).  The FunctionFS changes
 25them as needed also handling situation when numbers differ in
 26different configurations.
 27
 28When descriptors and strings are written "ep#" files appear
 29(one for each declared endpoint) which handle communication on
 30a single endpoint.  Again, FunctionFS takes care of the real
 31numbers and changing of the configuration (which means that
 32"ep1" file may be really mapped to (say) endpoint 3 (and when
 33configuration changes to (say) endpoint 2)).  "ep0" is used
 34for receiving events and handling setup requests.
 35
 36When all files are closed the function disables itself.
 37
 38What I also want to mention is that the FunctionFS is designed in such
 39a way that it is possible to mount it several times so in the end
 40a gadget could use several FunctionFS functions. The idea is that
 41each FunctionFS instance is identified by the device name used
 42when mounting.
 43
 44One can imagine a gadget that has an Ethernet, MTP and HID interfaces
 45where the last two are implemented via FunctionFS.  On user space
 46level it would look like this::
 47
 48  $ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid
 49  $ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp
 50  $ ( cd /dev/ffs-mtp && mtp-daemon ) &
 51  $ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid
 52  $ ( cd /dev/ffs-hid && hid-daemon ) &
 53
 54On kernel level the gadget checks ffs_data->dev_name to identify
 55whether its FunctionFS is designed for MTP ("mtp") or HID ("hid").
 56
 57If no "functions" module parameters is supplied, the driver accepts
 58just one function with any name.
 59
 60When "functions" module parameter is supplied, only functions
 61with listed names are accepted. In particular, if the "functions"
 62parameter's value is just a one-element list, then the behaviour
 63is similar to when there is no "functions" at all; however,
 64only a function with the specified name is accepted.
 65
 66The gadget is registered only after all the declared function
 67filesystems have been mounted and USB descriptors of all functions
 68have been written to their ep0's.
 69
 70Conversely, the gadget is unregistered after the first USB function
 71closes its endpoints.
 72
 73DMABUF interface
 74================
 75
 76FunctionFS additionally supports a DMABUF based interface, where the
 77userspace can attach DMABUF objects (externally created) to an endpoint,
 78and subsequently use them for data transfers.
 79
 80A userspace application can then use this interface to share DMABUF
 81objects between several interfaces, allowing it to transfer data in a
 82zero-copy fashion, for instance between IIO and the USB stack.
 83
 84As part of this interface, three new IOCTLs have been added. These three
 85IOCTLs have to be performed on a data endpoint (ie. not ep0). They are:
 86
 87  ``FUNCTIONFS_DMABUF_ATTACH(int)``
 88    Attach the DMABUF object, identified by its file descriptor, to the
 89    data endpoint. Returns zero on success, and a negative errno value
 90    on error.
 91
 92  ``FUNCTIONFS_DMABUF_DETACH(int)``
 93    Detach the given DMABUF object, identified by its file descriptor,
 94    from the data endpoint. Returns zero on success, and a negative
 95    errno value on error. Note that closing the endpoint's file
 96    descriptor will automatically detach all attached DMABUFs.
 97
 98  ``FUNCTIONFS_DMABUF_TRANSFER(struct usb_ffs_dmabuf_transfer_req *)``
 99    Enqueue the previously attached DMABUF to the transfer queue.
100    The argument is a structure that packs the DMABUF's file descriptor,
101    the size in bytes to transfer (which should generally correspond to
102    the size of the DMABUF), and a 'flags' field which is unused
103    for now. Returns zero on success, and a negative errno value on
104    error.