Re: [PATCH] usb: host: xhci: fix HALTED endpoint handling

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

 



On Tue, 21 Jan 2014, Sarah Sharp wrote:

> On Mon, Jan 20, 2014 at 02:45:11PM -0600, Felipe Balbi wrote:
> > If the HW reports the endpoint as Halted, there's
> > no need to start any URB for that endpoint, we can
> > simply return -EPIPE and this will tell upper layers
> > that the endpoint is, indeed, halted.
> > 
> > This patch fixes usbtest's set/clear halt test #13
> > on xHCI-based hosts.
> 
> It looks like that test assumes that the xHCI driver should not allow
> URBs to be enqueued to the endpoint when the driver needs to call
> usb_clear_halt().  Or is it expecting that the host will attempt the
> transfer, and the device will stall the transfer?

It expects that the computer will attempt the transfer and the device 
will reply with a STALL.

> The reason the driver still queues URBs is because the xHC halts the
> endpoint for events that are outside of stalls.  For instance, it will
> halt the endpoint on a babble error, a transfer error, or a split
> transaction error.  The upper layers don't call usb_clear_halt() for
> those cases, so the xHCI driver handles the halted endpoint internally.
> Look for calls to xhci_requires_manual_halt_cleanup().
> 
> The xHC also halts the endpoint on a control transfer stall.  The upper
> layers don't ever call usb_clear_halt on the control endpoint, because
> the bus spec says the next control transfer will clear the halted
> condition.  Therefore the xHCI driver has to handle the halt manually.

It sounds like there's a little confusion here.  To say that the 
endpoint is halted is somewhat ambiguous; it could refer to a halt on 
the host side or a halt on the device side.

usb_clear_halt() is meant to clear a halt on the device side.  It also 
tells the HCD that it has done so, in case the HCD is keeping track,
but it is not meant for clearing a halt on the host side.  
usb_reset_endpoint() does that (among other things).

> You could try to differentiate between an endpoint halt that requires a
> manual cleanup, and ones that the upper layer should handle, perhaps by
> adding a new EP_HALTED_MANUAL flag.  The driver could accept URBs for
> the manual cleanup case, and reject URBs with -EPIPE for the ones the
> upper layers should handle.

That should not be necessary.  The HCD should always accept URB
submissions.  Nothing will get sent to the device until the HCD clears
any host-side halts, but the upper layers don't worry about that
because the HCD takes care of it automatically.

Contrariwise, the upper layers are responsible for clearing device-side 
halts.  The HCD should ignore that end of things as much as it can.

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]