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: <op.v0gtmri13l0zgt@mnazarewicz-glaptop>
Date:	Fri, 19 Aug 2011 16:38:41 +0200
From:	"Michal Nazarewicz" <mina86@...a86.com>
To:	"Alan Stern" <stern@...land.harvard.edu>
Cc:	"Sebastian Andrzej Siewior" <bigeasy@...utronix.de>,
	"Sergei Shtylyov" <sshtylyov@...sta.com>,
	"Felipe Balbi" <balbi@...com>,
	"Yang Rui Rui" <ruirui.r.yang@...to.com>,
	"Greg Kroah-Hartman" <gregkh@...e.de>,
	"USB list" <linux-usb@...r.kernel.org>,
	"Kernel development list" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and
 USB_GADGET_SUPERSPEED

> On Fri, 19 Aug 2011, Michal Nazarewicz wrote:
>> OK, I see my mistake.  I misinterpreted gadget->speed as the max speed
>> gadget supports.
>>
>> So in the end, it would seem to me that we need to do the following is
>> usb_gadget_probe_direvr() before passing the usb_gadget_driver to the
>> usb_gadegt's bind:
>>
>> if (driver->speed == USB_SPEED_SUPER &&  
>> !gadget_is_superspeed(udc->gadget))
>> 	driver->speed = USB_SPEED_HIGH;
>> if (driver->speed == USB_SPEED_HIGH &&  
>> !gadget_is_dualspeed(udc->gadget))
>> 	driver->speed = USB_SPEED_FULL;

On Fri, 19 Aug 2011 16:29:15 +0200, Alan Stern <stern@...land.harvard.edu>  
wrote:
> No, the usb_gadget_driver structure is read-only to the UDC driver
> (except for the .driver field).  .speed is the maximum speed supported
> by the gadget driver -- it doesn't change at runtime.  If the driver
> was written to support speeds up to high speed, then those are the
> speeds it supports, regardless of the UDC's capabilities.

OK.

> Maybe if would help if the .speed field in struct usb_gadget_driver was
> renamed to max_speed.

I'll take a look at how much work that would require.

>> (Although I'm not sure about USB_SPEED_FULL vs. USB_SPEED_LOW.)
>>
>> Either than, or make sure that all UDC drivers handle correctly gadgets
>> that declare speed as highest of what the UDC can handle.

> I don't quite understand that sentence.  However, it is definitely true
> that all UDC drivers _must_ avoid connecting at speeds that are faster
> than the usb_gadget_driver's .speed field.

Yang has brought up an issue that musb_gadget_start() checks if  
driver->speed
equals USB_SPEED_HIGH.  This means that if a gadget driver supports super  
speed
it'll set driver->speed to USB_SPEED_SUPER and musb_gadget_start() will  
complain.

My understanding is that this is a bug in musb driver as it should allow  
the
gadget driver to start but never set super speed.

>> At the moment however, gadget_is_superspeed() is implemented using  
>> #ifdefs (which I missed before) so we need to add a is_superspeed
>> to usb_gadget structure.  Or maybe better yet get rid of
>> is_dualspeed and add max_speed?

> Either one would be okay.  max_speed is simpler, although it would
> require some work to change the existing usages of is_dualspeed.

I'm on it already. ;)

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