Re: [RFC/PATCH v2] usb: host: xhci: issue 'Reset Endpoint' for !CONTROL EPs from finish_td()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 12 Nov 2014, Felipe Balbi wrote:

> > By the way, does the same sort of thing happen after a transfer
> > error (such as a CRC mismatch)?  Does the xHCI controller change the 
> > state to EP_STATE_HALTED?  Or does it instead go directly to 
> 
> There are a few conditions in which XHCI will change EP state to
> EP_STATE_HALTED, one of them is a STALL token from the peripheral and
> the others would be really error conditions: Babble, CRC error, etc.
> 
> The spec even has a note about it, which I quote:
> 
> 	"
> 	A Halt condition or USB Transaction error detected on a USB pipe
> 	shall cause a Running Endpoint to transition to the Halted
> 	state. A Reset Endpoint Command shall be used to clear the Halt
> 	condition on the endpoint and transition the endpoint to the
> 	Stopped state. A Stop Endpoint Command received while an
> 	endpoint is in the Halted state shall have no effect and shall
> 	generate a Command Completion Event with the Completion Code set
> 	to Context State Error.
> 	"
> 
> > EP_STATE_STOPPED?  You probably want to treat that case and the STALL 
> > case as similarly as possible.
> 
> There's already code to deal with that, take a look at
> xhci_requires_manual_halt_cleanup() and its callers:

Then shouldn't the recovery from a STALL be exactly the same as the 
recovery from any other sort of transfer error?


> > Right.  In theory you could do it any time up until the completion
> > routine returns.  Doing it when you process the failed TD seems like a
> > good choice -- advance the dequeue pointer and issue the command at the
> > same time.
> 
> My concern here is that this will happen when the first usb_submit_urb()
> completes. I wonder if moving this to when the following
> usb_submit_urb() is about to start would be better ?

No, because there may be some other URBs already on the endpoint queue.  
If no further URBs are submitted then the queue won't get cleaned up.

> I think this has a higher probability of being correct. Class driver
> might not queue any URB to a particular after the first Stall, so why
> would be move the endpoint away from EP_STATE_HALTED prematurely ?

In order to handle the queue.  Of course, if the queue is empty then 
there's no harm in leaving the ep in EP_STATE_HALTED until another URB 
is submitted.

By the same reasoning, when the state is changed to EP_STATE_STOPPED, 
the doorbell should be rung.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]