Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp2330295ybz; Thu, 23 Apr 2020 16:09:16 -0700 (PDT) X-Google-Smtp-Source: APiQypIIprzHRNKBj//i3xvimGS/afG+vKkMvCqLSrVHxkRj5mwBn8wS+qKc9qrGoeziIZjz1Mk9 X-Received: by 2002:a17:906:7f0d:: with SMTP id d13mr4814162ejr.312.1587683356668; Thu, 23 Apr 2020 16:09:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587683356; cv=none; d=google.com; s=arc-20160816; b=qeN/jxzIIb+ZsJqUfXTNATOkleaVxw+pRCSKn5eslK+6bjXrqX8QiDhVq7wGWieR99 TnhrIrFNfFEL0Aask74Z07HgEJdeSzh8uJjFhmBS+gIqxZgdMSoq1VBM2blTb87g1d3C EAAgqeHsINq6UpTWgownBMH9/mOEvvhE6lJFH7xYhow3zY5IPUR6QSS9AmXwbYt6n04K 7kCM1pXgeQl6NWP/p8VkEvBQWetnzyAZmF0VMw7CgeTPeh9uD9RoKxjgW3Jx3EwfA8Tv y8l6YAZbDjS3GDVrdEqhBfDk1R1SZ9RKDqMfeg9hy2Aq3kD2oiTTQsNPSduddAf+EajZ yXOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:subject:message-id:date:cc:to :from:mime-version:content-transfer-encoding:content-disposition; bh=nxxwAgiupnlMYGQ8G72+7h8fZKyHA/6/p5jZ2NSERh4=; b=QETtcZh9msfvTMad5/nvLb9hIni4pdreVtskCuuCTAZ8BPi8nXU4SwqfQe6+cZkg6+ blE+a6mj/1SXapgqjvd1JSZhE7OfJ/FKOgJ/KR9kLVfPhuVuUME53HSZrwBk+NJ5nKro cT+eHD1Mc3t+QlxSdRSaFAxe3549VUkMqKxJxQru2WPBzhi8dfctTfZQ26AcOfSks3+0 tFhAvOyHe3SlAG/kyKRkRTjKLbV0WrnpquztKzznEEDNjT7FmaxFeyjS3LERS5bY2WOV MtTyRbeMMPhwoytcSRT0pgfFM3Uaw0bzloDKecbAg57wGGRyMSY9mZoZqEAPrrXJNuE3 tuYg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-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 u11si2194601eda.41.2020.04.23.16.08.52; Thu, 23 Apr 2020 16:09:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728673AbgDWXG7 (ORCPT + 99 others); Thu, 23 Apr 2020 19:06:59 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:49262 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728316AbgDWXGl (ORCPT ); Thu, 23 Apr 2020 19:06:41 -0400 Received: from [192.168.4.242] (helo=deadeye) by shadbolt.decadent.org.uk with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1jRkvQ-0004fo-5u; Fri, 24 Apr 2020 00:06:32 +0100 Received: from ben by deadeye with local (Exim 4.93) (envelope-from ) id 1jRkvO-00E6me-JQ; Fri, 24 Apr 2020 00:06:30 +0100 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit MIME-Version: 1.0 From: Ben Hutchings To: linux-kernel@vger.kernel.org, stable@vger.kernel.org CC: akpm@linux-foundation.org, Denis Kirjanov , "Mathias Nyman" , "Greg Kroah-Hartman" , "Ard Biesheuvel" , "Eli Billauer" Date: Fri, 24 Apr 2020 00:05:22 +0100 Message-ID: X-Mailer: LinuxStableQueue (scripts by bwh) X-Patchwork-Hint: ignore Subject: [PATCH 3.16 095/245] xhci: handle some XHCI_TRUST_TX_LENGTH quirks cases as default behaviour. In-Reply-To: X-SA-Exim-Connect-IP: 192.168.4.242 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 3.16.83-rc1 review patch. If anyone has any objections, please let me know. ------------------ From: Mathias Nyman commit 7ff11162808cc2ec66353fc012c58bb449c892c3 upstream. xhci driver claims it needs XHCI_TRUST_TX_LENGTH quirk for both Broadcom/Cavium and a Renesas xHC controllers. The quirk was inteded for handling false "success" complete event for transfers that had data left untransferred. These transfers should complete with "short packet" events instead. In these two new cases the false "success" completion is reported after a "short packet" if the TD consists of several TRBs. xHCI specs 4.10.1.1.2 say remaining TRBs should report "short packet" as well after the first short packet in a TD, but this issue seems so common it doesn't make sense to add the quirk for all vendors. Turn these events into short packets automatically instead. This gets rid of the "The WARN Successful completion on short TX for slot 1 ep 1: needs XHCI_TRUST_TX_LENGTH quirk" warning in many cases. Reported-by: Eli Billauer Reported-by: Ard Biesheuvel Tested-by: Eli Billauer Tested-by: Ard Biesheuvel Signed-off-by: Mathias Nyman Link: https://lore.kernel.org/r/20191211142007.8847-6-mathias.nyman@linux.intel.com Signed-off-by: Greg Kroah-Hartman [bwh: Backported to 3.16: adjust context] Signed-off-by: Ben Hutchings --- drivers/usb/host/xhci-ring.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/drivers/usb/host/xhci-ring.c +++ b/drivers/usb/host/xhci-ring.c @@ -2345,7 +2345,8 @@ static int handle_tx_event(struct xhci_h case COMP_SUCCESS: if (EVENT_TRB_LEN(le32_to_cpu(event->transfer_len)) == 0) break; - if (xhci->quirks & XHCI_TRUST_TX_LENGTH) + if (xhci->quirks & XHCI_TRUST_TX_LENGTH || + ep_ring->last_td_was_short) trb_comp_code = COMP_SHORT_TX; else xhci_warn_ratelimited(xhci,