On Wed, Jan 20, 2010 at 09:08:23PM +0100, ext Alan Stern wrote:
On Thu, 21 Jan 2010, sai pavan wrote:
This approach may not work if two configurations has common functions. say
config 1: mass storage + CDC-ACM
config 2: mass storage
The composite driver adds 1st configuration by calling usb_add_config,
which in turn would call mass storage bind method. The same bind
method would get called when 2nd configuration added. This duplicates
all buffers used in gadget function driver.
Does this mean we can not have a common function across multiple
configurations?
I don't know; I'm not familiar with the composite framework.
Can't you fix it so that it calls each bind function only once, even if
a driver appears in more than one configuration?
this is a problem many device manufacturers might have. The problem
grows bigger when we have to pass USB Certification. Because the
certification is done under windows and we have the "interoperability"
certification requirement, unless we make a hack for such issues, we
won't pass certification.
Imagine a device with two configurations, one with 500mA (for USB
charging) and one with 100mA bMaxPower. If we connect to windows behind
a bus powered hub, windows will never enumerate our device. Since it has
a big flaw where it doesn't fetch all usb configurations.
Funny thing is that USB-IF claims the OS is not "required" to get all
configuration descriptors. Even though the USB 2.0 Spec says in 9.4.3:
"The descriptor index is used to select a specific descriptor (only for
configuration and string descriptors) when several descriptors of the
same type are implemented in a device."
And in 9.1.2 - Bus enumeration, the Spec is clear about host reading all
descriptors of same type (step 7):
"The host reads the configuration information from the device by reading
each configuration zero to n-1, where n is the number of configurations.
This process may take several milliseconds to complete."
Anyways, would be nice to have some generic way implemented in
composite.c to try out the next configuration if we didn't choose any
and got a bus suspend.
The Maemo kernel have a hackish way of acomplishing that which we could
send as RFC, but it's far from ready for mainline.
--
balbi
--
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
