Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp965717pxb; Fri, 22 Jan 2021 03:59:38 -0800 (PST) X-Google-Smtp-Source: ABdhPJxNSIYfgBqYqhyuNQ42MsAHfUoSPcxDQa7vMi8RmN41RjyoLiN7wMQdA3X8hV6CuS18ydNj X-Received: by 2002:a17:906:95cf:: with SMTP id n15mr2825759ejy.178.1611316777976; Fri, 22 Jan 2021 03:59:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611316777; cv=none; d=google.com; s=arc-20160816; b=qJLDG98tpEnKfScxALiNW0nG8VTJ7rD0zQvG6nm7d9I44z7x3FtCLE31vl7l7/mswE /IfkRHY/cbuiSnbPevgEn8UpkHgbJJ2fbw8bSqWAoJSnJVJRG7Joi1POIK/BtA4OQfGU JZOJ3UGEi1Yt4VXHL96SnNvEuNIJCAc7P0BIhEHpIjSyLgFZy+R+tX1XEsHUnoHlEv6L l3h3QXSiePEBFIgjv/uIk/sdvu0N57u2BWWpF9a66jSmwBihEudQPv+eJLGFle5qnzed HOMmtdb+4Lw0QWTEo7NXdPumQHGZ0j9hzfFDyVtAKE5mikK5RY8y4kPhabAROdkfWHIE 6Hzw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=s5zUnZIga8YCsxtkCuU8+h7RKOPgKeLXxz7i8hp47Tw=; b=ViYZCzRBpNsdabLOVte4HM+qYicFQUwjaxCh80e9zrZjcnO8or72tEimkOXmYXcpqh Bzao8Rqsxn7tcdvAp10mtbQnWL9AblufilbTkgYII5Q+19RbQUKQs4A7tkS+lwDbIFxd eRo7ttHNJBfVV0oV8mafnm3RNz/fTgxnww47r6YfrcUMh9Laiao8txih5YqwixrAD7AF v2ydsDDTmAiECJpeIW83sm8jrlUNbgcDi7WFsinxTvogsYWCT2TQUdw5deb1PNfA+Lps JYXgkh0PI9H3lq6cTk/88XKkcGdozNxq/Ayz+Hfwb0v2SblLlnIbNX457+3PO301NQSV Qpjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kroah.com header.s=fm2 header.b=u3sYz1KD; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=SGWWzpFw; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id h18si3509454eds.65.2021.01.22.03.59.13; Fri, 22 Jan 2021 03:59:37 -0800 (PST) Received-SPF: pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kroah.com header.s=fm2 header.b=u3sYz1KD; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=SGWWzpFw; spf=pass (google.com: domain of linux-wireless-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-wireless-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbhAVL6k (ORCPT + 99 others); Fri, 22 Jan 2021 06:58:40 -0500 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:43797 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727410AbhAVL5j (ORCPT ); Fri, 22 Jan 2021 06:57:39 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 923885C00FF; Fri, 22 Jan 2021 06:56:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 22 Jan 2021 06:56:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=s5zUnZIga8YCsxtkCuU8+h7RKOP gKeLXxz7i8hp47Tw=; b=u3sYz1KDMTYFbEyeRuRyc9DDE0BL1+tHrf0hTyHkwbJ OMT0G1tdavoYXzY8XYCMysbO3dU53BTBOHYNjhTKaWZCoKpqBuasX+U/YGGKFS9g 10Ezlgzn2mJQUEDkhI7+FUoTGDOa3iFFVzJ9xN9CmiumRfD98qGhI1yMPTb6Tn1D CllR7QQaEslx3m1FXuEiiWagraEFlWgtR7oi/3Fw3ylqemQTjvD5qC2QPg4/a6JM rd7PeXQREkp+u1AOZ7IP9s8/7wVLSPBt0RwW9uVwtA7D6ju9e11/Ux6gd59Nq081 AHnAi5FkhG9LwJ06tY3tdzrtXQkdpgAedwmC1xE50Zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=s5zUnZ Iga8YCsxtkCuU8+h7RKOPgKeLXxz7i8hp47Tw=; b=SGWWzpFwuWLwDF2fV5Q584 91wl4EOuI0qwRFdbCyor75KKCQNJASXnsbwJ4lY8mYfDRCCaqIZNz3bLVkIluYLj DMnQTTOlEFPyMtsmVNzOoZuiDV+eLqOYCR5h61yPcpGRx/wRdeFnxl2r4F1HMeMk PDscgV1K+C5hFWuGJBpKNeqxVEHE81ByXGqGC/txw+u54qYmjM2VFxMD2bZZT/Fb GhGS3DaUtLNYdOzxPKJ4Q0RYj0SiU6/f9ZhvmtXWYyKZ9vjF/NYxKD0MR+mlbu79 vxGMxay8BBde7kFEye/l5MEPrq8vSC824mcmIdHG0z7lV+zyTRGvFE/uDnZ0eTGw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeigdefkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepifhrvghgucfm jfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepueelledthe ekleethfeludduvdfhffeuvdffudevgeehkeegieffveehgeeftefgnecuffhomhgrihhn pehkvghrnhgvlhdrohhrghenucfkphepkeefrdekiedrjeegrdeigeenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehgrhgvgheskhhrohgrhhdr tghomh X-ME-Proxy: Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) by mail.messagingengine.com (Postfix) with ESMTPA id C3CEB24005A; Fri, 22 Jan 2021 06:56:31 -0500 (EST) Date: Fri, 22 Jan 2021 12:56:30 +0100 From: Greg KH To: stf_xl@wp.pl Cc: linux-usb@vger.kernel.org, linux-wireless@vger.kernel.org, Mathias Nyman , Bernhard Subject: Re: [PATCH] usb, xhci, rt2800usb: do not perform Soft Retry Message-ID: References: <20210122104342.12451-1-stf_xl@wp.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210122104342.12451-1-stf_xl@wp.pl> Precedence: bulk List-ID: X-Mailing-List: linux-wireless@vger.kernel.org On Fri, Jan 22, 2021 at 11:43:42AM +0100, stf_xl@wp.pl wrote: > From: Stanislaw Gruszka > > Since f8f80be501aa ("xhci: Use soft retry to recover faster from transaction > errors") on some systems rt2800usb devices are unable to operate. Looks > that due to firmware or hardware limitations of those devices, they > require full recovery from USB Transaction Errors. > > To avoid the problem add URB transfer flag, that restore pre f8f80be501aa > xhci behaviour when the flag is set. For now only add it only to rt2800usb > driver. This feels like a really heavy hammer, to add a xhci flag for a single broken device. Are you sure this is really needed? What does this device do on other operating systems, do they have such a quirk for their host controller driver? Or is this due to the specific host controller device hardware? Should this be a xhci quirk for a specific pci device instead? > > Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202541 > Fixes: f8f80be501aa ("xhci: Use soft retry to recover faster from transaction errors") > Reported-and-tested-by: Bernhard > Bisected-by: Bernhard > Signed-off-by: Stanislaw Gruszka > --- > drivers/net/wireless/ralink/rt2x00/rt2x00usb.c | 3 +++ > drivers/usb/core/urb.c | 2 +- > drivers/usb/host/xhci-ring.c | 3 ++- > include/linux/usb.h | 1 + > 4 files changed, 7 insertions(+), 2 deletions(-) > > diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > index e4473a551241..f1d82b3e6bba 100644 > --- a/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c > @@ -214,6 +214,7 @@ void rt2x00usb_register_read_async(struct rt2x00_dev *rt2x00dev, > usb_fill_control_urb(urb, usb_dev, usb_rcvctrlpipe(usb_dev, 0), > (unsigned char *)(&rd->cr), &rd->reg, sizeof(rd->reg), > rt2x00usb_register_read_async_cb, rd); > + urb->transfer_flags |= URB_SOFT_RETRY_NOT_OK; > usb_anchor_urb(urb, rt2x00dev->anchor); > if (usb_submit_urb(urb, GFP_ATOMIC) < 0) { > usb_unanchor_urb(urb); > @@ -323,6 +324,7 @@ static bool rt2x00usb_kick_tx_entry(struct queue_entry *entry, void *data) > usb_sndbulkpipe(usb_dev, entry->queue->usb_endpoint), > entry->skb->data, length, > rt2x00usb_interrupt_txdone, entry); > + entry_priv->urb->transfer_flags |= URB_SOFT_RETRY_NOT_OK; > > status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC); > if (status) { > @@ -409,6 +411,7 @@ static bool rt2x00usb_kick_rx_entry(struct queue_entry *entry, void *data) > usb_rcvbulkpipe(usb_dev, entry->queue->usb_endpoint), > entry->skb->data, entry->skb->len, > rt2x00usb_interrupt_rxdone, entry); > + entry_priv->urb->transfer_flags |= URB_SOFT_RETRY_NOT_OK; > > status = usb_submit_urb(entry_priv->urb, GFP_ATOMIC); > if (status) { > diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c > index 357b149b20d3..140bac59dc32 100644 > --- a/drivers/usb/core/urb.c > +++ b/drivers/usb/core/urb.c > @@ -495,7 +495,7 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags) > > /* Check against a simple/standard policy */ > allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK | > - URB_FREE_BUFFER); > + URB_SOFT_RETRY_NOT_OK | URB_FREE_BUFFER); > switch (xfertype) { > case USB_ENDPOINT_XFER_BULK: > case USB_ENDPOINT_XFER_INT: > diff --git a/drivers/usb/host/xhci-ring.c b/drivers/usb/host/xhci-ring.c > index 5677b81c0915..6712e1a7735c 100644 > --- a/drivers/usb/host/xhci-ring.c > +++ b/drivers/usb/host/xhci-ring.c > @@ -2302,7 +2302,8 @@ static int process_bulk_intr_td(struct xhci_hcd *xhci, struct xhci_td *td, > remaining = 0; > break; > case COMP_USB_TRANSACTION_ERROR: > - if ((ep_ring->err_count++ > MAX_SOFT_RETRY) || > + if (td->urb->transfer_flags & URB_SOFT_RETRY_NOT_OK || > + (ep_ring->err_count++ > MAX_SOFT_RETRY) || > le32_to_cpu(slot_ctx->tt_info) & TT_SLOT) > break; > *status = 0; > diff --git a/include/linux/usb.h b/include/linux/usb.h > index 7d72c4e0713c..dcdac2f03263 100644 > --- a/include/linux/usb.h > +++ b/include/linux/usb.h > @@ -1329,6 +1329,7 @@ extern int usb_disabled(void); > #define URB_ISO_ASAP 0x0002 /* iso-only; use the first unexpired > * slot in the schedule */ > #define URB_NO_TRANSFER_DMA_MAP 0x0004 /* urb->transfer_dma valid on submit */ > +#define URB_SOFT_RETRY_NOT_OK 0x0008 /* Avoid XHCI Soft Retry */ To match other flags here, how about "URB_NO_SOFT_RETRY"? thanks, greg k-h