linux-kernel - Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET

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:	Thu, 18 Aug 2011 22:44:59 +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, Michal Nazarewicz wrote:
>> 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.

On Thu, 18 Aug 2011 22:30:14 +0200, Alan Stern wrote:
> Have you misinterpreted that comment?

Might be. ;)

[...]

>> So I think that your suggestion to use composite_driver.speed =
>> driver->max_speed was by all means correct.

> Okay, that line was probably all right, but it seems that something
> else needs to be changed.  In a composite gadget, if none of the
> function drivers support SuperSpeed then we don't want
> composite_driver.speed to be set to USB_SPEED_SUPER.  It would be
> foolish to allow the UDC to connect at a speed which would make the
> gadget useless.

My understanding is that that's the purpose of driver->max_speed.
Composite gadget's author is supposed to set it to the maximum speed
he intends his gadget to run with.

This have some consequences of course: driver->max_speed may be set
to super speed where no function actually supports super speed so
if host chooses this speed we will return no configuration (which
I don't know if it's even legal).

At the same time, author may consciously decide to set
driver->max_speed to some value that not all functions support
aware that depending on speed host chooses, different functions
will be available.

The best composite layer can do, is try to check whether there
is at least one configuration supporting the speed
driver->max_speed declares and if not, decrease it or return
with error.

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