On 19.12.2017 12:16, yinbo.zhu@xxxxxxx wrote:
From: yinbo.zhu <yinbo.zhu@xxxxxxx>
This issue is observed in USB 2.0 mode when the USB 3.0 host
controller is connected to a FS/LS device via a hub. The
host controller issues start-split (SSPLIT) and (CSPLIT)
tokens to accomplish a split-transaction. A
split-transaction consists of a SSPLIT token, token/data
consists of a SSPLIT token, token/data packets, CSPLIT token
and token/data/handshake packets. A SSPLIT token is issued
by the host controller to the hub followed by token/data/
handshake packets. The hub then relays the token/data/
handshake packets to the FS /LS device. Sometime later, the
host controller issues a CSPLIT token followed by the same
token/data/handshake packets to the hub to complete the
split-transaction. As an example scenario, when the xHCI
driver issues an Address device command with BSR=0, the
host controller sends SETUP(SET_ADDRESS) tokens on the USB
as part of splittransactions. If the host controller
receives a NYET response from the hub for the CSPLIT SETUP,
it means that the split-transaction has not yet been
completed or the hub is not able to handle the split
transaction. In such a case, the host controller keeps
retrying the splittransactions until such time an ACK
response is received from the hub for the CSPLIT SETUP token
. If the split-transactions do not complete in a time bound
manner, the xHCI driver may issue a Stop Endpoint Command.
The host controller does not service the Stop Endpoint
Command and eventually the xHCI driver times out waiting for
the Stop Endpoint Command to complete.
Impact: Stop Endpoint Command does not complete.
Workaround: Instead of issuing a Stop Endpoint Command,
issue a Disable Slot Command with the corresponding slot
ID. Alternately, you can issue an Address Device Command
with BSR=1.
Configs Affected:
LS1012A-R1.0, LS1012A-R2.0, LS1021-20-22A-R1.0,
LS1021-20-22A-R2.0, LS1043-23A-R1.0, LS1043-23A-R1.1,
LS1046-26A-R1.0, LS1088-48A-R1.0, LS2080-40A-R1.0,
LS2081A-R1.1, LS2085-45A-R1.0, LS2088-48A-R1.0,
LS2088-48A-R1.1, LX2160-2120-2080A-R1.0.
Signed-off-by: yinbo zhu <yinbo.zhu@xxxxxxx>
---
Change in v4:
Remove the point in "yinbo.zhu"
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 5141856..20c9af4 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1521,6 +1521,18 @@ static int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
xhci_ring_cmd_db(xhci);
}
+ /*
+ *erratum A-009668: Stop Endpoint Command does not complete.
+ *Workaround: Instead of issuing a Stop Endpoint Command,
+ *issue a Disable Slot Command with the corresponding slot ID.
+ *Alternately, you can issue an Address Device Command with
+ *BSR=1
+ */
+ if ((urb->dev->speed <= USB_SPEED_HIGH) &&
+ (xhci->quirks & XHCI_STOP_EP_IN_U1)) {
+ xhci_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
+ urb->dev->slot_id);
+ }
Address device in xHCI is done with a address device command on the command ring,
if it times out then xhci_handle_command_timeout() will be called. No stop endpoint command
should be involved (if I remember correctly)
xhci_urb_dequeue() may be called in other cases for LS/FS URBs that timed out,
due to your split transaction hang errata, but a disable slot command can't just be bluntly
issued before first properly stopping all slot endpoints, and giving back all the other pending URBs
-Mathias
--
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
