Hello Michal,
W dniu 05.05.2014 20:41, Michal Nazarewicz pisze:
On Mon, May 05 2014, Andrzej Pietrasiewicz wrote:
When a gadget is composed with configfs the usb_add_config() is invoked
each time a configuration's directory is created, so this way configurations'
indices are determined. If we were to rearrange the configurations if
one of them becomes "special" then we loose the information about the original
sequence of configurations (i.e. which was index 0, index 1 etc). If the user
then decides that they don't want to use "OS descriptors" (=> no "special"
configuration) than we end up with configurations presented to the host in
different order than they were created.
What I'm worried about is situation where configuration number visible
on the device disagrees with what host sees. This may cause confusion
or bugs at configfs level as well as in the code. I.e. the
bConfigurationValue for the special configuration will be zero when
accessed by the host, but might be non-zero when read via configfs or
directly by the composite function driver.
Isn't bConfigurationValue a label only? The host accesses configurations
by index (which is effectively generated at the gadget side by iterating
over a list of configurations and incrementing a counter), which is a different
thing that bConfigurationValue.
Consider for example the serial gadget (serial.c before applying the discussed
patch series): it defines 3 configurations,
but it registers only one, depending on module parameters.
Yet bConfigurationValue is eiter 1, 2 or 3 and is defined statically, so
for example when ACM is chosen, the only configuration presented to the host
has bConfigurationValue equal 2 even though it is reported at index 0.
AP
--
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
