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:	Fri, 19 Aug 2011 10:02:00 +0800
From:	Yang Rui Rui <ruirui.r.yang@...to.com>
To:	Michal Nazarewicz <mnazarewicz@...gle.com>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Sergei Shtylyov <sshtylyov@...sta.com>,
	Felipe Balbi <balbi@...com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Yang Ruirui R <ruirui.r.yang@...toenator.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	"linux-usb@...r.kernel.org" <linux-usb@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED

On 08/19/2011 01:05 AM, Michal Nazarewicz wrote:
> 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.

This is what I means in before reply, musb_gadget_start will check the speed set here.
if it != USB_SPEED_HIGH it will return -EINVAL.

>
> 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 original code, ifndef CONFIG_USB_GADGET_SUPERSPEED and max_speed = USB_SPEED_SUPER
then the result will be:

composite_driver.speed = min(USB_SPEED_HIGH, USB_SPEED_SUPER)

For patched code, composite_driver.speed = USB_SPEED_SUPER

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


-- 
Thanks
Yang Ruirui
--
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/