$ echo 1> /cfg/usb-function-gadget/G1/connect
$ file.img> /cfg/usb-function-gadget/G1/C1/F1/f_mass_storage/lun0/file
Each function, after creating its corresponding directory
(/cfg/usb-function-gadget/G1/C1/F1), must be "personalized" by storing
its name in the "name" attribute. After that it is possible to create
a child item of the same name ("f_mass_storage" here). The common code
handles everything from top of the hierarchy up to the function directory.
Under the function directory a function-specific stuff provided by each
function is used. The function-specific code is abstracted by the above
mentioned struct ufg_fn. In the example, the mass storage function is
supplied with one LUN.
The "connect" attribute's store method calls the ufg_gadget_bind function,
which registers the composite gadget, then walks the configfs hierarchy
rooted at the above mentioned subsystem and does USB configurations and
functions registration.
This is a work in progress. There might be issues.In the big picture I think, yes. I think you should start a little
I would like to ask some questions. All answers in general, and answers
from linux-usb and Felipe and Greg KH in particular, are welcome.
1. Generally, is this the right way to go?
2. Using configfs like this calls for an interface between the genericWe have for udc level some things like connect, power level and Felipe
configfs-related code and function-specific code. I suggested the
struct ufg_fn. What do you think?
3. Should some parameters still be available through sysfs?
4. Do we need module parameters for USB descriptors like iManufacturerNo. No modules parameters at all. With one exception: Currently we set
and similar?
5. I assumed that the configfs entities are contained in the structures
used for configuring the USB functions, e.g. a struct config_group in
struct fsg_common, or a struct config_item in a struct fsg_lun. This
has implications that the lifetime of the structures is controlled by
userspace through configfs, which, in turn, has influence on how
the USB functions are implemented. Even though it seems natural,
there are some issues. For example an extension to configfs was required
in order to disable deleting the luns while the gadget is connected.
Is this the right approach? If not, then are there any alternatives?