On 11/22/2012 09:59 PM, Michal Nazarewicz wrote:
echo MassStorage> /cfg/usb-function-gadget/G1/C1/F1/name
Why not
mkdir /cfg/usb-function-gadget/G1/C1/F1/MassStorage
?
Let me add what I have in my head + what Michał said in other mail:
Lets assume we start at /sys/kernel/config/gadget and I don't mention
it here because I save keystrokes.
First we need a folder where we have a list of available UDCs:
/udcs/udc0
/udcs/udc1
And proper name of udc0 can be decided later on…
Step two is a folder where we setup individual configuration of a function.
/functions/ttyS0
/functions/ttyS1
/functions/storage
each one of the function folder has the file called "name". So for the
folder ttyS0 the file name contains "acm" because we use the ACM
function. The same is true for ttyS1 and for storage we write
"mass_storage" if that is what function will be called.
Alternative (my favorite): function_common-name
that would be
/functions/acm_ttyS0
/functions/acm_ttyS1
/functions/mass_storage_storage
So we avoid the _name_ file and it will be parsed from the directory
name. That is what target/tcm does. You have
rd_mcp_X for a ramdisk and fileio_X for a file as backend.
After name is written it will request the module and special
configuration related files pop up. For ACM it will be almost nothing
while for storage we get nofua or something like that and we will be
able to create the lunX folder.
Step three ladies and gentleman.
/gadgets/gadget1/default-configuration
/gadgets/gadget1/hi-power-configuration
So what do we do here? Each directory created as a child of gadget1
(default-configuration in this example) will represent a configuration
descriptor. Within the configuration folder I would keep a file named
bConfigurationValue _or_ something else (like pre- or post fix for
default-configuration, note postfix here is my favorite again) so we
know how to sort configs IMHO this is important as the first config is
the default one.
In order to get any functions in here, we will symlink the ttyS0
function and others into "default-configuration" and /or hi-power-
configuration.
So we can have more than one function of one kind (i.e. multiple UART
ports) and we can distinguish between between those two.
Step four, link gadget1 to udc1
After that, we should be ready. So we could maybe avoid the avoid the
"ready" file. Obex has something like that where it disables the
function until userland is ready. Maybe we could remove ready and make
sure gadget1 is not linked to udc1 until user land is ready.
anyone?
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
