linux/android系统的USB gadget configfs用户空间配置USB HID U盘 adb dcd等模式的使用

USB gadget configfs模式的使用：
即可android或linux在用户空间配置实现设备终端为HID，U盘、Adb以及cdc等功能
1、创建gadgets
每个gadget都必须创建自己相应的目录以及自己的PID和VID
mkdir $CONFIGFS_HOME/usb_gadget/
e.g.:
mkdir $CONFIGFS_HOME/usb_gadget/g1
cd $CONFIGFS_HOME/usb_gadget/g1
echo xxx> idVendor
echo xxx> idProduct
gadget需要有自己的serial number, manufacturer and product strings.
为了有存储它们的地方，必须为每种语言创建一个strings子目录，例如：
mkdir strings/0x409
具体的字符串如下：
echo > strings/0x409/serialnumber
echo > strings/0x409/manufacturer
echo > strings/0x409/product
2、每个gadget都有自己的配置描述符，对应的目录也必须创建
mkdir configs/.
其中可以是文件+对应的配置编号，如下：
mkdir configs/c.1
每个配置需有自己的字符串、子目录必须被创建：
mkdir configs/c.1/strings/0x409
Then the configuration string can be specified:
echo > configs/c.1/strings/0x409/configuration
Some attributes can also be set for a configuration, e.g.:
echo 120 > configs/c.1/MaxPower
3、创建一个functions
gadget将提供一些function，作为每个function相应目录必须创建
mkdir functions/.
其中对应于允许的函数名之一，实例名是文件系统中允许的任意字符串，
mkdir functions/ncm.usb0 # usb_f_ncm.ko gets loaded with request_module()
每个函数都提供其特定的属性集，具有只读或读写访问权限。在适用的情况下，他们需要写在适当的地方。
Please refer to Documentation/ABI//configfs-usb-gadget for more information.
4、将function与功能关联起来
此时创建了许多小工具，每个小工具都指定了许多配置和许多可用功能。
剩下的就是指定哪个功能在哪个配置中可用（同一个功能可以在多个配置中使用）。这是通过创建符号链接实现的：
ln -s functions/. configs/.
e.g.:
ln -s functions/ncm.usb0 configs/c.1
5、使能gadget
以上所有步骤都是为了构造配置和功能的gadget
示例目录结构可能如下所示：
./strings
./strings/0x409
./strings/0x409/serialnumber
./strings/0x409/product
./strings/0x409/manufacturer
./configs
./configs/c.1
./configs/c.1/ncm.usb0 -> …/…/…/…/usb_gadget/g1/functions/ncm.usb0
./configs/c.1/strings
./configs/c.1/strings/0x409
./configs/c.1/strings/0x409/configuration
./configs/c.1/bmAttributes
./configs/c.1/MaxPower
./functions
./functions/ncm.usb0
./functions/ncm.usb0/ifname
./functions/ncm.usb0/qmult
./functions/ncm.usb0/host_addr
./functions/ncm.usb0/dev_addr
./UDC
./bcdUSB
./bcdDevice
./idProduct
./idVendor
./bMaxPacketSize0
./bDeviceProtocol
./bDeviceSubClass
./bDeviceClass
必须最终启用这样的gadget，以便USB主机可以枚举它。
为了启用gadget，它必须绑定到UDC（USB设备控制器）。
echo > UDC
其中一个在/sys/class/udc中找到/*
e.g(RK3399平台)：
echo fe800000.dwc3 > UDC
6、不使能gadget
echo “” > UDC
7、清理(Cleaning up)
从配置中移除功能(Remove functions from configurations)
rm configs/./
哪里。指定配置，是一个符号链接，用于从配置中删除功能，
where . specify the configuration and is a symlink to a function being removed from the configuration, e.g.:
rm configfs/c.1/ncm.usb0
…
…
删除配置中的字符串描述符
rmdir configs/./strings/
…
…
并且移除配置
rmdir configs/.
e.g.:
rmdir configs/c.1
…
…
删除功能（但功能模块不会被卸载，即功能的目录被删除了，但是功能模块驱动不卸载）
rmdir functions/.
e.g.:
rmdir functions/ncm.usb0

移除功能的字符串描述符：
rmdir strings/
e.g.:
rmdir strings/0x409
并且在最后移除gadget
cd …
rmdir
e.g.:
rmdir g1

实施设计:
下面介绍了configfs的工作原理。
在configfs中有项和组，它们都表示为目录。
项目和组之间的区别在于组可以包含其他组。下图中只显示了一个项目。
项和组都可以具有属性，这些属性表示为文件。
用户可以创建和删除目录，但不能删除文件，
它可以是只读的，也可以是读写的，这取决于它们所代表的内容。
configfs的文件系统部分在config_items/groups and
configfs_attributes是通用且类型相同的属性配置的元素
但是，它们是嵌入到特定用法更大的结构中。在下面的图片中有一个“cs”，它包含
一个config_items(项)和一个包含configfs_attribute(属性)的“sa”。
文件系统视图如下所示：
The filesystem view would be like this:
./
./cs (direction)
|
±—sa （file）
|
.
.
每当用户读/写“sa”文件时，就会调用一个函数，它接受struct config_item和configfs_attribute.
在所述功能中，“cs”和“sa”使用井进行检索已知的container_of技术和适当的sa功能（show或store)
调用并传递“cs”和字符缓冲区。
这个show 是显示文件的内容（从cs拷贝数据到缓冲区中）
这个store是修改文件的内容(复制缓冲区数据到cs中)
但是，这两个函数的实现者决定他们实际做什么。
typedef struct configured_structure cs;
typedef struct specific_attribute sa;

文件名由config item/group设计器决定，而目录通常可以随意命名。一个组可以自动创建多个默认子组。
有关configfs的更多信息，请参阅Documentation/filesystems/configfs/*。
上述概念转换为USB gadget，如下所示：
1、一个gadget有它的配置组，它有一些属性（idVendor、idProduct等）和默认子组（configs、functions、string）。
写入属性会导致信息存储在适当的位置。在configs、functions和strings子组中，用户可以创建表示配置的子组，函数和给定语言中的字符串组
2、The user creates configurations and functions, in the configurations
creates symbolic links to functions. This information is used when the
gadget’s UDC attribute is written to, which means binding the gadget
to the UDC. The code in drivers/usb/gadget/configfs.c iterates over
all configurations, and in each configuration it iterates over all
functions and binds them. This way the whole gadget is bound.

3、The file drivers/usb/gadget/configfs.c contains code for

1）gadget’s config_group
2) gadget’s default groups (configs, functions, strings)
3) associating functions with configurations (symlinks)
4、Each USB function naturally has its own view of what it wants
configured, so config_groups for particular functions are defined
in the functions implementation files drivers/usb/gadget/f_*.c.

5、Function’s code is written in such a way that it uses

usb_get_function_instance(), which, in turn, calls request_module.
So, provided that modprobe works, modules for particular functions
are loaded automatically. Please note that the converse is not true:
after a gadget is disabled and torn down, the modules remain loaded.