Re: [RFC 3/4] Intel xhci: Ignore spurious successful event.

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

 



On Thu, May 26, 2011 at 10:24:06AM -0400, Alan Stern wrote:
> On Wed, 25 May 2011, Sarah Sharp wrote:
> 
> > The xHCI host controller in the Panther Point chipset sometimes produces
> > spurious events on the event ring.  If it receives a short packet, it
> > first puts a Transfer Event with a short transfer completion code on the
> > event ring.  Then it puts a Transfer Event with a successful completion
> > code on the ring for the same TD.  The xHCI driver correctly processes the
> > short transfer completion code, gives the URB back to the driver, and then
> > prints a warning in dmesg about the spurious event.  These warning
> > messages really fill up dmesg when an HD webcam is plugged into xHCI.
> > 
> > This spurious successful event behavior isn't technically disallowed by
> > the xHCI specification, so make the xHCI driver just ignore the spurious
> > completion event.
> > 
> > Signed-off-by: Sarah Sharp <sarah.a.sharp@xxxxxxxxxxxxxxx>
> 
> ...
> 
> > --- a/drivers/usb/host/xhci-ring.c
> > +++ b/drivers/usb/host/xhci-ring.c
> > @@ -2061,6 +2061,16 @@ static int handle_tx_event(struct xhci_hcd *xhci,
> >  		if (!event_seg) {
> >  			if (!ep->skip ||
> >  			    !usb_endpoint_xfer_isoc(&td->urb->ep->desc)) {
> > +				/* Some host controllers give a spurious
> > +				 * successful event after a short transfer.
> > +				 * Ignore it.
> > +				 */
> > +				if ((xhci->quirks & XHCI_SPURIOUS_SUCCESS) && 
> > +						ep_ring->last_td_was_short) {
> > +					ep_ring->last_td_was_short = false;
> > +					ret = 0;
> > +					goto cleanup;
> > +				}
> 
> If, as you say, the spurious events are allowed (or at least, not
> disallowed) by the xHCI spec, then why bother to test an
> XHCI_SPURIOUS_SUCCESS flag?  You might as well assume that any
> controller can generate these events.

It's a twisted interpretation of the spec that makes this behavior not
disallowed, so I think it's pretty unlikely that any other xHCI host
controller will do this.  At least, I haven't seen this behavior on any
of the other host controllers I've tested on.  I'd rather have hardware
developers who are testing new host controllers see the spew of messages
and realize they're doing something kind of stupid.  We can add a new
quirk for them if they still decide to ship their hardware.

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


[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux