From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751718AbdIKMGd (ORCPT ); Mon, 11 Sep 2017 08:06:33 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:42558 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751482AbdIKMGc (ORCPT ); Mon, 11 Sep 2017 08:06:32 -0400 Date: Mon, 11 Sep 2017 05:06:31 -0700 From: Greg Kroah-Hartman To: yinbo.zhu@nxp.com Cc: Mathias Nyman , "open list:USB XHCI DRIVER" , open list Subject: Re: [PATCH 1/2] usb: host: Implement workaround for Erratum A-009611 Message-ID: <20170911120631.GD16198@kroah.com> References: <20170911094132.38456-1-yinbo.zhu@nxp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170911094132.38456-1-yinbo.zhu@nxp.com> User-Agent: Mutt/1.9.0 (2017-09-02) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 11, 2017 at 05:41:32PM +0800, yinbo.zhu@nxp.com wrote: > From: "yinbo.zhu" Please use your "real" name in the from portion, I don't think you have a "." in your name, right? :) And what hardware is this erratum for? Please put that in the subject line as well, as well as xhci, otherwise it is very vague. > > Description: This is a occasional problem where the software No need for "Description:" in a changelog text, the whole thing is a description. > issues an End Transfer command while a USB transfer is in progress, > resulting in the TxFIFO being flushed when the lower layer is waiting > for data,causing the super speed (SS) transmit to get blocked. > If the End Transfer command is issued on an IN endpoint to > flush out the pending transfers when the same IN endpoint > is doing transfers on the USB, then depending upon the timing > of the End Transfer (and the resulting internal FIFO flush),the > lower layer (U3PTL/U3MAC) could get stuck waiting for data > indefinitely. This blocks the transmission path on the SS, and no > DP/ACK/ERDY/DEVNOTIF packets can be sent from the device. > Impact: If this issue happens and the transmission gets blocked, > then the USB host aborts and resets/re-enumerates the device. > This unblocks the transmitt engine and the device functions normally. > > Workaround: Software must wait for all existing TRBs to complete before > issuing End transfer command. > > Signed-off-by: yinbo.zhu > --- > drivers/usb/host/xhci.c | 23 ++++++++++++++++------- > 1 file changed, 16 insertions(+), 7 deletions(-) > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c > index 2d6a98c1dc12..35f7821bc8b2 100644 > --- a/drivers/usb/host/xhci.c > +++ b/drivers/usb/host/xhci.c > @@ -1501,13 +1501,22 @@ static int xhci_urb_dequeue(struct usb_hcd *hcd, struct urb *urb, int status) > ret = -ENOMEM; > goto done; > } > - ep->ep_state |= EP_STOP_CMD_PENDING; > - ep->stop_cmd_timer.expires = jiffies + > - XHCI_STOP_EP_CMD_TIMEOUT * HZ; > - add_timer(&ep->stop_cmd_timer); > - xhci_queue_stop_endpoint(xhci, command, urb->dev->slot_id, > - ep_index, 0); > - xhci_ring_cmd_db(xhci); > + > + /* > + *A-009611: Issuing an End Transfer command on an IN endpoint. > + *when a transfer is in progress on USB blocks the transmission > + *Workaround: Software must wait for all existing TRBs to > + *complete before issuing End transfer command. > + */ Please properly format your comments. And what is the A-009611: for? And is this really for all xhci controllers? > + if (ep_ring->enqueue == ep_ring->dequeue) { > + ep->ep_state |= EP_STOP_CMD_PENDING; > + ep->stop_cmd_timer.expires = jiffies + > + XHCI_STOP_EP_CMD_TIMEOUT * HZ; > + add_timer(&ep->stop_cmd_timer); > + xhci_queue_stop_endpoint(xhci, command, > + urb->dev->slot_id, ep_index, 0); > + xhci_ring_cmd_db(xhci); > + } > } thanks, greg k-h