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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ