[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110823151105.GP1341@legolas.emea.dhcp.ti.com>
Date: Tue, 23 Aug 2011 18:11:06 +0300
From: Felipe Balbi <balbi@...com>
To: Michal Nazarewicz <mnazarewicz@...gle.com>
Cc: Alan Stern <stern@...land.harvard.edu>,
Felipe Balbi <balbi@...com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
Yang Rui Rui <ruirui.r.yang@...to.com>,
Dave Young <hidave.darkstar@...il.com>,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCHv3 2/4] usb: gadget: replace "is_dualspeed" with
"max_speed"
Hi,
On Tue, Aug 23, 2011 at 05:07:11PM +0200, Michal Nazarewicz wrote:
> On Tue, 23 Aug 2011 16:58:01 +0200, Felipe Balbi <balbi@...com> wrote:
> >I stand with the fact that if they are part of the same configuration,
> >there's no way around it, storage will have to come down to full speed.
> >Unless I'm missing something.
>
> If you look at config_buf() in composite.c, you'll notice that composite
> just skips functions that do not support current speed. This means, that
> if a connection uses high speed but given function can handle only full
> speed, it won't be included in the descriptors.
>
> config_buf() is called from config_desc() which similarly, iterates over
> configurations skipping the ones that do not support given speed.
>
> Configuration is defined to support given speed if at least one function
> that is added to that configuration supports that speed (see
> usb_add_function()).
I'm trying to think if this is really what we want. This might mean
$current_config will be different depending if we connect it to SS, HS
or FS hubs. Do we need USB-IF's help here ? I guess I could drop them a
mail and ask for some clarification. Don't know how long it would take
to get an answer though :-s
--
balbi
Download attachment "signature.asc" of type "application/pgp-signature" (491 bytes)
Powered by blists - more mailing lists