linux-kernel - RE: [PATCH v12 7/8] usb: Adding SuperSpeed support to dummy

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.1105261028040.1960-100000@iolanthe.rowland.org>
Date:	Thu, 26 May 2011 10:31:47 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tanya Brokhman <tlinder@...eaurora.org>
cc:	balbi@...com, 'Sarah Sharp' <sarah.a.sharp@...ux.intel.com>,
	<greg@...ah.com>, <linux-usb@...r.kernel.org>,
	<linux-arm-msm@...r.kernel.org>, <ablay@...eaurora.org>,
	'open list' <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v12 7/8] usb: Adding SuperSpeed support to dummy_hcd

On Thu, 26 May 2011, Tanya Brokhman wrote:

> > > Right, but at this point there is no way of knowing what function
> > drivers
> > > will bind to it and what descriptors they will provide. Most of the
> > > function drivers allocate their descriptors at bind() that occurs
> > after
> > > the UDC already registers.
> > 
> > Well, there must be an appropriate spot to do this.
> 
> Unfortunately in the current implementation there isn't.

Sure there is.  You describe a good possibility later on in your 
email...

> > It looks like you need to add a "max_speed" field to struct
> > usb_composite_driver.  Each driver will initialize this to the highest
> > speed it supports, and it must guarantee that the necessary descriptors
> > are available.
> 
> I also thought of that. This can be done...
> Just to make sure we're on the same page:
> We can add a "max_sup_speed" field to struct usb_composite_driver. Each of
> the Gadget drivers will set this field prior to calling
> usb_composite_probe(). Then, in usb_composite_probe(), we'll update the
> composite_driver.speed as follows:
> 
> 	composite_driver.speed = min(composite_driver.speed,
> driver->max_sup_speed);

Just call it max_speed.  You can mention in the kerneldoc that it is 
the maximum speed supported by the driver.

> Of course for SS we'll update the composite_driver.speed @ static struct
> usb_gadget_driver composite_driver, as we agreed with Felipe.
> 
> How does that sound? Felipe - it seems to me that these should cover your
> hesitations about updating the driver speed :)
> 
> Now that I think about it, the above will be true for HS as well. I mean the
> current speed of composite_driver is set always to HS but if there is a
> function driver that supports only FS then the above will update
> composite_driver.speed to FS.

That's right.  The same solution will work for both cases.

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/