linux-kernel - Re: [PATCHv3 3/4] usb: gadget: rename usb_gadget_driver::speed to max

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.1108192225120.18944-100000@netrider.rowland.org>
Date:	Fri, 19 Aug 2011 22:34:29 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Felipe Balbi <balbi@...com>
cc:	Michal Nazarewicz <mnazarewicz@...gle.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Yang Rui Rui <ruirui.r.yang@...to.com>,
	Dave Young <hidave.darkstar@...il.com>,
	<linux-usb@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCHv3 3/4] usb: gadget: rename usb_gadget_driver::speed to
 max_speed

On Sat, 20 Aug 2011, Felipe Balbi wrote:

> On Sat, Aug 20, 2011 at 12:33:01AM +0200, Michal Nazarewicz wrote:
> > From: Michal Nazarewicz <mina86@...a86.com>
> > 
> > This commit renames the “speed”	field of the usb_gadget_driver
> > structure to “max_speed”.  This is so that to make it more
> > apparent that the field represents the maximum speed gadget
> > driver can support.
> > 
> > This also make the field look more like fields with the same
> > name in usb_gadget and usb_composite_driver structures.  All
> > of those represent the *maximal* speed given entity supports.
> > 
> > After this commit, there are the following fields in various
> > structures:
> > * usb_gadget::speed - the current connection speed,
> > * usb_gadget::max_speed - maximal speed UDC supports,
> 
> this will be handled inside the UDC itself, so why do you need to expose
> it ?

I wondered about this too.  It turns out that sometimes the gadget
driver really does need to know about the maximum speed supported by
the UDC hardware and driver.

For example, suppose the gadget driver and the UDC both support high
speed, but the gadget is currently plugged into a USB-1.1 controller
and therefore running only at full speed.  Then the gadget driver has
to respond to the Get-Device-Qualifier and Get-Other-Speed-Config
requests by sending the appropriate descriptors.  But if the UDC
doesn't support high speed operation then the gadget driver has to
respond to those requests with a STALL.

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/