Re: Virtual hub, resets etc...

[Alan Stern <stern@rowland.harvard.edu>]

On Fri, 5 Jul 2019, Benjamin Herrenschmidt wrote:

> On Fri, 2019-07-05 at 07:44 +1000, Benjamin Herrenschmidt wrote:
> > > >    - At some point I had code to reject EP queue() if the device
> > > > is
> > > > suspended with -ESHUTDOWN. The end result was bad ...
> > > > f_mass_storage
> > > > goes into an infinite loop of trying to queue the same stuff in
> > > > start_out_transfer() when that happens. It looks like it's not
> > > > really
> > > > handling errors from queue() in a particularily useful way.
> > > 
> > > Don't reject EP queue requests.  Accept them as you would at any
> > > time;
> > > they will complete after the port is resumed.
> >
> > Except the suspend on a bus reset clears the port enable. You can't
> > resume from that, only reset the port no ? Or am I missing something
> > ?
> 
> Talking of which... do we need this ?
> 
> --- a/drivers/usb/gadget/composite.c
> +++ b/drivers/usb/gadget/composite.c
> @@ -1976,6 +1976,7 @@ void composite_disconnect(struct usb_gadget *gadget)
>  	 * disconnect callbacks?
>  	 */
>  	spin_lock_irqsave(&cdev->lock, flags);
> +	cdev->suspended = 0;
>  	if (cdev->config)
>  		reset_config(cdev);
>  	if (cdev->driver->disconnect)
> 
> Otherwise with my vhub or with dummy_hcd, a suspend followed by a reset
> will keep that stale suspended flag to 1 (which has no effect at the moment
> but still...)
> 
> If yes, I'll submit a patch accordingly...

According to the USB spec, a host is not supposed to reset a suspended 
port (it's supposed to resume the port and then do the reset).  But of 
course this can happen anyway, so we should handle it properly.

Alan Stern