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]

Message-ID: <Pine.LNX.4.44L0.1108181055240.1912-100000@iolanthe.rowland.org>
Date:	Thu, 18 Aug 2011 10:59:28 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Michal Nazarewicz <mnazarewicz@...gle.com>
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:

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

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.

Alan Stern

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