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.
Alan Stern
--
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
