linux-kernel - Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET

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 13:13:41 +0200
From:	Sebastian Andrzej Siewior <bigeasy@...utronix.de>
To:	Michal Nazarewicz <mina86@...a86.com>
CC:	Alan Stern <stern@...land.harvard.edu>,
	Sergei Shtylyov <sshtylyov@...sta.com>,
	Felipe Balbi <balbi@...com>,
	Yang Rui Rui <ruirui.r.yang@...to.com>,
	Greg Kroah-Hartman <gregkh@...e.de>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED

Michal Nazarewicz wrote:
> On Thu, 18 Aug 2011 22:30:14 +0200, Alan Stern 
> <stern@...land.harvard.edu> wrote:
>> Okay, that line was probably all right, but it seems that something
>> else needs to be changed.  In a composite gadget, if none of the
>> function drivers support SuperSpeed then we don't want
>> composite_driver.speed to be set to USB_SPEED_SUPER.  It would be
>> foolish to allow the UDC to connect at a speed which would make the
>> gadget useless.
> 
> OK, so it seems I was misunderstanding your comment all along, but
> that was nothing a good night sleep couldn't fix. :P
> 
> So, what you are saying is that when passed to the UDC driver (ie.
> by calling usb_gadget_probe_driver()) the usb_gadget_driver structure
> must have speed no higher then what the UDC supports, right?  And in
> that case, it's not composite specific but affects all the gadgets.
> 
> In that case, I think that usb_gadget_probe_driver() itself needs to be
> changed since prior to this function we don't know which gadget the
> gadget driver will be bound to.  Ie. something as follows could be added
> somewhere there:
> 
>   driver->speed = min(driver->speed, udc->gadget->speed)
> 
> Does that sound like it makes sense?
> 
> At this point though, gadget drivers need to be aware that
> usb_gadget_probe_driver() may change the speed field.  It should not
> be a problem since, as far as I can tell, all gadgets expect for g_ffs
> call usb_gadget_probe_driver() only once and in case of g_ffs this can
> be solved at composite level.

There are three speeds:
- the max speed the UDC supports i.e. HS (no field for that?)
- the max speed the gadget / function driver support i.e. SS
   (driver->max_speed ?)
- the speed the UDC is connected at the moment i.e. FS. (gadget->speed)

So in this case you have to go down and use FS descriptors. The FS speed
is represented by gadget->speed right? So for now we do FS. On the next
re-plug the user places OHCI controller with XHCI so you can use HS
descriptors now. So changing dirver->speed wouldn't allow you go beyond FS
once you to FS right?

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