1*How FunctionFS works*
   3From kernel point of view it is just a composite function with some
   4unique behaviour.  It may be added to an USB configuration only after
   5the user space driver has registered by writing descriptors and
   6strings (the user space program has to provide the same information
   7that kernel level composite functions provide when they are added to
   8the configuration).
  10This in particular means that the composite initialisation functions
  11may not be in init section (ie. may not use the __init tag).
  13From user space point of view it is a file system which when
  14mounted provides an "ep0" file.  User space driver need to
  15write descriptors and strings to that file.  It does not need
  16to worry about endpoints, interfaces or strings numbers but
  17simply provide descriptors such as if the function was the
  18only one (endpoints and strings numbers starting from one and
  19interface numbers starting from zero).  The FunctionFS changes
  20them as needed also handling situation when numbers differ in
  21different configurations.
  23When descriptors and strings are written "ep#" files appear
  24(one for each declared endpoint) which handle communication on
  25a single endpoint.  Again, FunctionFS takes care of the real
  26numbers and changing of the configuration (which means that
  27"ep1" file may be really mapped to (say) endpoint 3 (and when
  28configuration changes to (say) endpoint 2)).  "ep0" is used
  29for receiving events and handling setup requests.
  31When all files are closed the function disables itself.
  33What I also want to mention is that the FunctionFS is designed in such
  34a way that it is possible to mount it several times so in the end
  35a gadget could use several FunctionFS functions. The idea is that
  36each FunctionFS instance is identified by the device name used
  37when mounting.
  39One can imagine a gadget that has an Ethernet, MTP and HID interfaces
  40where the last two are implemented via FunctionFS.  On user space
  41level it would look like this:
  43$ insmod g_ffs.ko idVendor=<ID> iSerialNumber=<string> functions=mtp,hid
  44$ mkdir /dev/ffs-mtp && mount -t functionfs mtp /dev/ffs-mtp
  45$ ( cd /dev/ffs-mtp && mtp-daemon ) &
  46$ mkdir /dev/ffs-hid && mount -t functionfs hid /dev/ffs-hid
  47$ ( cd /dev/ffs-hid && hid-daemon ) &
  49On kernel level the gadget checks ffs_data->dev_name to identify
  50whether it's FunctionFS designed for MTP ("mtp") or HID ("hid").
  52If no "functions" module parameters is supplied, the driver accepts
  53just one function with any name.
  55When "functions" module parameter is supplied, only functions
  56with listed names are accepted. In particular, if the "functions"
  57parameter's value is just a one-element list, then the behaviour
  58is similar to when there is no "functions" at all; however,
  59only a function with the specified name is accepted.
  61The gadget is registered only after all the declared function
  62filesystems have been mounted and USB descriptors of all functions
  63have been written to their ep0's.
  65Conversely, the gadget is unregistered after the first USB function
  66closes its endpoints.