Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED

From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Michal Nazarewicz <mina86@mina86.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
	Sergei Shtylyov <sshtylyov@mvista.com>,
	Felipe Balbi <balbi@ti.com>,
	Yang Rui Rui <ruirui.r.yang@tieto.com>,
	Greg Kroah-Hartman <gregkh@suse.de>,
	linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCHv2] usb: gadget: get rid of USB_GADGET_DUALSPEED and USB_GADGET_SUPERSPEED
Date: Fri, 19 Aug 2011 13:13:41 +0200	[thread overview]
Message-ID: <4E4E4565.70902@linutronix.de> (raw)
In-Reply-To: <op.v0gi7koy3l0zgt@mnazarewicz-glaptop>

Michal Nazarewicz wrote:
> On Thu, 18 Aug 2011 22:30:14 +0200, Alan Stern 
> <stern@rowland.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