linux-kernel - Re: [PATCHv3 2/4] usb: gadget: replace "is_dualspeed" with "max

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 23 Aug 2011 17:26:24 +0200
From:	"Michal Nazarewicz" <mnazarewicz@...gle.com>
To:	"Felipe Balbi" <balbi@...com>
Cc:	"Alan Stern" <stern@...land.harvard.edu>,
	"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"

> On Tue, Aug 23, 2011 at 05:07:11PM +0200, Michal Nazarewicz wrote:
>> 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()).

On Tue, 23 Aug 2011 17:11:06 +0200, Felipe Balbi <balbi@...com> wrote:
> 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.

What do you mean by $current_config?  The bConfigurationValue will be
the same for "the same" configuration regardless of speed but different
configurations may be available for different speeds and "the same"
configuration in various speeds might have different functions.

So just for the sake of having something concrete, let's say we have:

Configuration #1 with
   function A supporting FS and HS and
   function B supporting FS only.
Configuration #2 with
   function B supporting FS only.
Configuration #3 with
   function A supporting FS and HS and
   function C supporting HS only (dunno if that makes sense).

When connected to FS hub, we will return the following:

Configuration #1: A, B
Configuration #2: B
Configuration #3: A

When connect to HS hub, we will return the following:

Configuration #1: A
Configuration #3: A, C

And similarly to bConfigurationValue, the interface IDs may have holes in
them.

Whether that's what we want, I don't know...  But if I understand
composite.c correctly, that's how it is implemented now.

-- 
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/