From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 3DCABC433F5 for ; Fri, 1 Oct 2021 15:24:34 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0C7396115A for ; Fri, 1 Oct 2021 15:24:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 0C7396115A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=rowland.harvard.edu Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=gW+RgRCPetV6umjIHqTNc63TlTGVzgLUB5uDsDwVreQ=; b=PuEIwoygGFQXBp Fb2IJbIaHx8mt/YGH5TKY/KSuC++RAGcgMSMtU6w/RL+Tept9GVKVUMHmrTTaZV71TGakaacc1D4I 2v09rwqS7ZQPnTeCwBz7gYFQuhmNlCXWyOHAZ7fGCzhaQqig6dDhei+/t2P296Z7o9TVyFHiSo//w JJcUnajUny7HsMpBhxuClw3yG1F9kqgeHTO9QOQPZn31eESgI+/GqdgcSY9tWhF7PnUFdne2O2l9Y YkcmKANlnF3Cc7TBh2gM2n3adKgCR1crMP+vCWHVN/riAFmrBnRIjyFQP38uYyWZJxFQVfEDn5i0i BALpWqOU+PgkDcbB/dgw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWKMu-000iQh-AB; Fri, 01 Oct 2021 15:22:36 +0000 Received: from netrider.rowland.org ([192.131.102.5]) by bombadil.infradead.org with smtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mWKMq-000iNd-8F for linux-arm-kernel@lists.infradead.org; Fri, 01 Oct 2021 15:22:33 +0000 Received: (qmail 506376 invoked by uid 1000); 1 Oct 2021 11:22:26 -0400 Date: Fri, 1 Oct 2021 11:22:26 -0400 From: Alan Stern To: Hayes Wang Cc: Oliver Neukum , Jason-ch Chen , "matthias.bgg@gmail.com" , "linux-usb@vger.kernel.org" , "netdev@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , "linux-mediatek@lists.infradead.org" , "Project_Global_Chrome_Upstream_Group@mediatek.com" , "hsinyi@google.com" , nic_swsd Subject: Re: [PATCH] r8152: stop submitting rx for -EPROTO Message-ID: <20211001152226.GA505557@rowland.harvard.edu> References: <20210929051812.3107-1-jason-ch.chen@mediatek.com> <4c2ad5e4a9747c59a55d92a8fa0c95df5821188f.camel@mediatek.com> <274ec862-86cf-9d83-7ea7-5786e30ca4a7@suse.com> <20210930151819.GC464826@rowland.harvard.edu> <3694347f29ed431e9f8f2c065b8df0a7@realtek.com> <5f56b21575dd4f64a3b46aac21151667@realtek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <5f56b21575dd4f64a3b46aac21151667@realtek.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211001_082232_489853_B0127C12 X-CRM114-Status: GOOD ( 18.17 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 01, 2021 at 03:26:48AM +0000, Hayes Wang wrote: > > Alan Stern > > [...] > > > There has been some discussion about this in the past. > > > > > > In general, -EPROTO is almost always a non-recoverable error. > > > > Excuse me. I am confused about the above description. > > I got -EPROTO before, when I debugged another issue. > > However, the bulk transfer still worked after I resubmitted > > the transfer. I didn't do anything to recover it. That is why > > I do resubmission for -EPROTO. > > I check the Linux driver and the xHCI spec. > The driver gets -EPROTO for bulk transfer, when the host > returns COMP_USB_TRANSACTION_ERROR. > According to the spec of xHCI, USB TRANSACTION ERROR > means the host did not receive a valid response from the > device (Timeout, CRC, Bad PID, unexpected NYET, etc.). That's right. If the device and cable are working properly, this should never happen. Or only extremely rarely (for example, caused by external electromagnetic interference). > It seems to be reasonable why resubmission sometimes works. Did you ever track down the reason why you got the -EPROTO error while debugging that other issue? Can you reproduce it? Alan Stern _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel