[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <op.v0fef7e2vgw7ix@mnazarewicz-glaptop>
Date: Thu, 18 Aug 2011 22:13:09 +0200
From: "Michal Nazarewicz" <mnazarewicz@...gle.com>
To: "Alan Stern" <stern@...land.harvard.edu>
Cc: "Sergei Shtylyov" <sshtylyov@...sta.com>,
"Felipe Balbi" <balbi@...com>,
"Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
"Yang Rui Rui" <ruirui.r.yang@...to.com>,
"Greg Kroah-Hartman" <gregkh@...e.de>, linux-usb@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and
USB_GADGET_SUPERSPEED
On Thu, 18 Aug 2011 19:27:21 +0200, Alan Stern <stern@...land.harvard.edu>
wrote:
> On Thu, 18 Aug 2011, Michal Nazarewicz wrote:
>
>> For the most part, usb_composite_probe() is called only once in module's
>> init function. As far as I know, only g_ffs calls it several times. So
>> in all cases expect for g_ffs, composite_driver.speed =
>> min(composite_driver.speed,
>> driver->max_speed) should have the same effect as composite_driver.speed
>> = driver->max_speed.
>>
>> > For example, if you have a composite gadget where one of the function
>> > drivers can handle SuperSpeed and the other can't go beyond high
>> speed,
>> > the overall gadget must never run faster than high speed.
>>
>> Shouldn't that be dealt in usb_add_function()? I cannot see any code
>> that would do that here atm though.
> Maybe you're right. But isn't that too late? The UDC driver has to
> know the gadget driver's limitations before it can connect to the host.
usb_add_function() is called before usb_composite_probe() which only then
calls usb_gadget_probe_driver().
What's more, if I understand it correctly, comment in usb_add_function()
says that we support all the speeds usb_composite_driver structure claims
we do but then return different sets of functions depending on speed. Ie.
if a function is only full speed and host requests high speed,
configuration
will lack that function. The comment in question is:
/* We allow configurations that don't work at both speeds.
* If we run into a lowspeed Linux system, treat it the same
* as full speed ... it's the function drivers that will need
* to avoid bulk and ISO transfers. */
usb_add_function() then proceeds to set config->fullspeed,
config->highspeed
and config->superspeed depending on what descriptors function provides.
Those are later used in config_desc() where it iterates over all
configurations checking which have functions supporting given speed:
list_for_each_entry(c, &cdev->configs, list) {
switch (speed) {
case USB_SPEED_SUPER: if (!c->superspeed) continue; break;
case USB_SPEED_HIGH: if (!c->highspeed) continue; break;
default: if (!c->fullspeed) continue;
}
if (w_value == 0)
return config_buf(c, speed, cdev->req->buf, type);
w_value--;
}
config_buf() at the same time, iterates over all functions and skips the
ones
that do not provide descriptors for given speed:
list_for_each_entry(f, &config->functions, list) {
switch (speed) {
case USB_SPEED_SUPER: descriptors = f->ss_descriptors; break;
case USB_SPEED_HIGH: descriptors = f->hs_descriptors; break;
default: descriptors = f->descriptors;
}
if (!descriptors)
continue;
[...]
}
So I think that your suggestion to use composite_driver.speed =
driver->max_speed was by all means correct.
--
Best regards, _ _
.o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
..o | Computer Science, Michal "mina86" Nazarewicz (o o)
ooo +-----<email/xmpp: mnazarewicz@...gle.com>-----ooO--(_)--Ooo--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists