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