[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170911094327.38520-1-yinbo.zhu@nxp.com>
Date: Mon, 11 Sep 2017 17:43:27 +0800
From: <yinbo.zhu@....com>
To: <yinbo.zhu@....com>
CC: Mathias Nyman <mathias.nyman@...el.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"open list:USB XHCI DRIVER" <linux-usb@...r.kernel.org>,
open list <linux-kernel@...r.kernel.org>
Subject: [PATCH 2/2] usb: host: Implement workaround for Erratum A-009668
From: "yinbo.zhu" <yinbo.zhu@....com>
Description: 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
complete-split (CSPLIT) tokens to
accomplish a split-transaction. A split-transaction
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 token, 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.
Signed-off-by: yinbo.zhu <yinbo.zhu@....com>
---
drivers/usb/host/xhci.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
index 35f7821bc8b2..62d6135ad428 100644
--- a/drivers/usb/host/xhci.c
+++ b/drivers/usb/host/xhci.c
@@ -1517,6 +1517,18 @@ static int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status)
urb->dev->slot_id, ep_index, 0);
xhci_ring_cmd_db(xhci);
}
+
+ /*
+ *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_queue_slot_control(xhci, command, TRB_DISABLE_SLOT,
+ urb->dev->slot_id);
+ }
}
done:
spin_unlock_irqrestore(&xhci->lock, flags);
--
2.14.1
Powered by blists - more mailing lists