Re: [PATCH v1] USB:gadget: Fix a warning while loading g_mass_storage
From: Andrzej Pietrasiewicz
Date: Thu Jun 05 2014 - 06:00:33 EST
W dniu 04.06.2014 17:26, Alan Stern pisze:
On Wed, 4 Jun 2014, Andrzej Pietrasiewicz wrote:
<snip>
What is the difference in purpose between usb_function and
usb_function_instance? I can't tell just by reading the header file.
Does one of them get created dynamically when the host sets the
appropriate config?
Please see below.
<snip>
Among traditional gadgets there is no gadget which uses mass storage function
more than once. On the other hand, when gadgets are created with configfs
it is forbidden to link a given function more than once into a given
config,
What is the reason for this restriction?
Please see below.
that is a struct usb_function_instance can be referenced by more
than one config, but can be referenced only once in a given config;
each symbolic link corresponds to an instance of struct usb_function
(don't confuse with struct usb_function_instance).
It's extremely easy to confuse them, since I don't understand the
differences between them. It even seems like you confused them in this
description: You mentioned "link a given function", "link corresponds
to an instance of struct usb_function", and "struct
usb_function_instance can be referenced by more than one config".
What's the difference between linking a usb_function and referencing a
usb_function_instance? Normally "linking" and "referencing" mean more
or less the same thing.
As I said, I didn't like the naming here. I got used to it, though,
but understand (and agree) that it is confusing. As far as explaining
the difference is concerned, being a non-native speaker of English
has its influence, too, so let me do it again.
I think it is easier to tell the purpose of the two structures taking
gadgets composed with configfs as example.
In each gadget there is "functions" directory. Function directories
are created there:
$ cd $CONFIGFS_ROOT/usb_gadget/our_gadget
$ mkdir functions/mass_storage.0
mass_storage.0 is internally represented as an instance of
struct usb_function_instance, which has its associated
struct fsg_common (the fsg_common is a member of
container_of(struct usb_function_instance)).
It can be referenced from multiple configurations.
$ ln -s functions/mass_storage.0 configs/config.1
$ ln -s functions/mass_storage.0 configs/config.2
Each reference (symbolic link) is internally represented as
an instance of struct usb_function. The struct usb_function here
has its associated struct fsg_dev (the fsg_dev is a
container_of(struct usb_function)).
By the very nature of any file system one cannot do:
$ ln -s functions/mass_storage.0 configs/config.1
$ ln -s functions/mass_storage.0 configs/config.1 => -EEXIST
By design of how configfs is applied to any usb gadget on cannot even do:
$ ln -s functions/mass_storage.0 configs/config.1/my_mass_storage.0
$ ln -s functions/mass_storage.0 configs/config.1/the_same_mass_storage.0 => -EEXIST
However, there should be no problem with this:
$ mkdir functions/mass_storage.0
$ mkdir functions/mass_storage.1
$ ln -s functions/mass_storage.0 configs/config.1
$ ln -s functions/mass_storage.1 configs/config.1
Legacy gadgets (g_mass_storage, g_acm_ms, g_multi) in fact operate in
a somewhat similar manner, the difference is that instead of creating directories
and making symbolic links, usb_get_function_instance() and usb_get_function()
are called, respectively, and composing a gadget happens from beginning to end
at module init.
I hope this clarifies things a bit.
AP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/