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 19:05:20 +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 16:59:28 +0200, Alan Stern <stern@...land.harvard.edu>  
wrote:

> On Thu, 18 Aug 2011, Michal Nazarewicz wrote:
>
>> On Wed, 17 Aug 2011 23:09:37 +0200, Alan Stern  
>> <stern@...land.harvard.edu>
>> wrote:
>> > I see what's going on here.  Your original patch was wrong and then my
>> > correction was wrong as well.
>> >
>> > This line has to remain the way it was (although those (u8) typecasts
>> > don't seem to be necessary).  Above, you have to initialize
>> > composite_driver.speed to an appropriate value, probably
>> > USB_SPEED_SUPER.
>> >
>> > What you didn't realize in your original patch is that
>> > usb_composite_probe() gets called more than once.  Each time it is
>> > called, it has to adjust composite_driver.speed.
>>
>> That's sneaky of composite.c...  But is it desired behaviour?
>
> Yes, it is.
>
>>  I cannot
>> came up with a situation where that's what we want.  I would imagine  
>> that
>> usb_composite_probe() should assume the same speed for given
>> usb_composite_driver regardless if some other slower  
>> usb_composite_driver
>> was loaded.
>
> The speed being calculated isn't the speed of the usb_composite_driver;
> it's the speed of the usb_gadget_driver.  The gadget itself cannot be
> allowed to run faster than its internal drivers can handle.

Yeah, that's why you set usb_gadget_driver's speed to the speed declared
in usb_composite_driver.

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.

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