linux-kernel - RE: [PATCH v14 4/9] usb: Add max_speed to usb_composite

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:	Mon, 6 Jun 2011 14:33:32 +0300
From:	"Tanya Brokhman" <tlinder@...eaurora.org>
To:	<balbi@...com>
Cc:	<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 v14 4/9] usb: Add max_speed to usb_composite_driver structure

Hi Felipe,

> On Tue, May 31, 2011 at 04:18:24PM +0300, Tatyana Brokhman wrote:
> > This field is used by the Gadget drivers to specify the maximum speed
> > they support, meaning: the maximum speed they can provide descriptors
> for.
> >
> > The driver speed will be set in consideration of this value.
> >
> > Signed-off-by: Tatyana Brokhman <tlinder@...eaurora.org>
> 
> personally, I don't think this is good enough. The gadget speed is
> actually the min() of the f_* speeds. So, IMHO this should be coming
> from f_* and during bind you would:
> 
> gadget->speed = min(f->speed, gadget->speed);
> 
> for all functions. Also, both this patch and what I described above,
> only works considering nobody touches that enum, so we might want to be
> careful and add some comments to the enum to avoid anyone from touching
> that :-)

You're right, the full and best solution would be to set driver speed as the
minimum of all the speeds its functions support. (Please note that it's the
usb_composite_driver speed we're talking about and not the speed of the
gadget).
Unfortunately, we need to determine the driver speed before any of the
functions binded to it so the above solution isn't possible.
In any case, gadget->speed is determined upon real connection to the host
that can occur long after the f-> bind() and it depends on whether for
example SS HW negotiation protocol succeeded or failed.

Thanks,
Tanya Brokhman
---
Sent by an consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.



 


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