functionfs.rst 3.0 KB

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