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.1105251443040.1987-100000@iolanthe.rowland.org>
Date:	Wed, 25 May 2011 14:59:00 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Brokhman Tatyana <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 Wed, 25 May 2011, Brokhman Tatyana wrote:

> 
>  composite_driver.speed to USB_SPEED_SUPER.
> >>
> >> Not sure how to verify this. I need to know whether the driver that is
> >> registered with the UDC is SS or not. This is before the function
> >> drivers
> >> are binded to it. So how can I verify at that point that the function
> >> drivers that will bind to this driver will provide SS descriptors?
> >> (I'm sorry, I don't have the ability to view the code at the moment and
> >> due to the time differences between us I don't want to leave this
> >> question
> >> for tomorrow and loose another day...)
> >
> > I'm not sure about this either.  I have never used the composite
> > framework so I'm not familiar with its details.  This has to be decided
> > before the composite gadget driver registers with the UDC driver ...
> 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.

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.

Since these structures are passed to usb_composite_probe() before the 
gadget driver is registered, the necessary calculations can be done 
there.

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/