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;
Subject: Re: [PATCH] r8152: stop submitting rx for -EPROTO
To:     Alan Stern <stern@rowland.harvard.edu>,
        Hayes Wang <hayeswang@realtek.com>
CC:     Oliver Neukum <oneukum@suse.com>,
        Jason-ch Chen <jason-ch.chen@mediatek.com>,
        "matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
        "linux-usb@vger.kernel.org" <linux-usb@vger.kernel.org>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "linux-mediatek@lists.infradead.org" 
        <linux-mediatek@lists.infradead.org>,
        "Project_Global_Chrome_Upstream_Group@mediatek.com" 
        <Project_Global_Chrome_Upstream_Group@mediatek.com>,
        "hsinyi@google.com" <hsinyi@google.com>,
        nic_swsd <nic_swsd@realtek.com>
References: <20210929051812.3107-1-jason-ch.chen@mediatek.com>
 <cbd1591fc03f480c9f08cc55585e2e35@realtek.com>
 <4c2ad5e4a9747c59a55d92a8fa0c95df5821188f.camel@mediatek.com>
 <274ec862-86cf-9d83-7ea7-5786e30ca4a7@suse.com>
 <20210930151819.GC464826@rowland.harvard.edu>
 <3694347f29ed431e9f8f2c065b8df0a7@realtek.com>
 <5f56b21575dd4f64a3b46aac21151667@realtek.com>
 <20211001152226.GA505557@rowland.harvard.edu>
From:   Oliver Neukum <oneukum@suse.com>
Message-ID: <72573b91-11d7-55a0-0cd8-5afbc289b38c@suse.com>
Date:   Mon, 4 Oct 2021 13:44:54 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.12.0
In-Reply-To: <20211001152226.GA505557@rowland.harvard.edu>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?uKPzfWzrP0Vnduti6RA2fdraCTibW4wCH9MnwaoZTGuyksHIZ/lIRrEcEfhq?=
 =?us-ascii?Q?WxLHmAhY7thAlI1qHfLFD764CkdTS2swJHBbOBnXjCpHMm3uKBXwu2cCpNgI?=
 =?us-ascii?Q?kgdYmBotWghCmxvMUfFjSjOu1+F80k4q+qDx3IPDsMAWMwN3UEH+BZVq/R8s?=
 =?us-ascii?Q?XXrHWw9zsAkKDJFp4uJJS2SqkFKWOXVan9Zr0GmvM1+UpSLW1NSXrJe3sFEj?=
 =?us-ascii?Q?s7I5+kVJoDfsEIX7UBbF98EQfh3K05eaJ5LeSMKkA+zsIC9IFIFCayEqQMqQ?=
 =?us-ascii?Q?dTOhM65D+YRsKi7WQKnBKxAjLFPII6AB7tq/Egv0bUPfvYpDi+Rdbh+1PZ1R?=
 =?us-ascii?Q?dGLGIPl29aX+mJ9WY9fodlxhnJcmvmRue71PDDzVMVbAXh8L7QqS3PotQC1L?=
 =?us-ascii?Q?gVt+Ahl/bWLm6NVr4H4NlGQbr9IDhbZw82dwdKzw1XVQPIIPh4v5QsB9OjTt?=
 =?us-ascii?Q?CorkvM01LlVuZCKM9Z9ytjTeIU22iojBzhX3Cvt6M8b1a/e6DCWXKq42q2qS?=
 =?us-ascii?Q?+sURLxXSByi0EUhjspiSvo1LXMp2dyEgaMUJTFaUxaMajsWn57KvNUNggJNf?=
 =?us-ascii?Q?66bKPA6DInDZpq9ZqXGLiaY/zzQOSYWJi+K9F+fH6AsAdAYAI1dblW+AK3Xz?=
 =?us-ascii?Q?rXfYqRboQURdByj75vSesytGS78glVm/f+Vbvrm+dlPN9iyD7nVDuDzNFY5C?=
 =?us-ascii?Q?roVYwS39A4kB2K0q8R28f/fW8hvGE6DnkOKvIY1S8dqpY/jKAfxJkAEpQg0U?=
 =?us-ascii?Q?kSIE0ZHCiTqsSqWvY6Q6opUCkZItps3LnRvZVvUrLXof0tXVotrR0NpeAxMF?=
 =?us-ascii?Q?+52HZGg9V6vY4/U+PD5D0NyznKsgbJpulO4wYrAVGP6WV6QxcUZo0TRVXkQq?=
 =?us-ascii?Q?lR4t8L5ANTAqXtHxrI45ntL0a7VVy7Hhk+11VUufTGWHAbs5wPp8fJ92svxQ?=
 =?us-ascii?Q?1xVl9An0RypUzehunBuTflAhY/rKn/wuKD1IJbiB2Mw7gD+9tVRsyNLXbsH2?=
 =?us-ascii?Q?TM01ivee4axvy/2TirdyJXMHd1+IRhjyhMiogT7nl3ild4Y5fvx9B/Rm7kjr?=
 =?us-ascii?Q?L7+RdhCe5AyWGagPGoVNIPTGO2P3t+YQDhXqhIwIHFqlU8iGkqf7ZyS9PVsP?=
 =?us-ascii?Q?c09rxxN6BMywt1an/GzTX1trZZB2CtbFhV8Myg5vDbh6eZU7y3Q//b12JARW?=
 =?us-ascii?Q?WaeO3XMeIjZ4b1hmJwXNh2G5fFNwXimj8BU/jRUjB/qwdm6ulhFGdoF6QF70?=
 =?us-ascii?Q?0kho9fI5mXEujTTGPF3F17MYfMUUSQB2QVyllUtmr6dAGFHJJSyGyq/fO6Fe?=
 =?us-ascii?Q?EPR6QeyD4DkDk3LLLkHgl5Fyt3Avu6j1xynvMRvFKGOy68FehCGog6RgMs35?=
 =?us-ascii?Q?Rw4CZCnnWh9d2ufdMyHqdmrDg4WD?=
X-OriginatorOrg: suse.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 03850ac4-310b-413d-2cdb-08d9872c6351
X-MS-Exchange-CrossTenant-AuthSource: DB7PR04MB5050.eurprd04.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Oct 2021 11:44:56.5919
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f7a17af6-1c5c-4a36-aa8b-f5be247aa4ba
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ogf5DAn4WV6+hRBj3A0WBBPCdi7PAtNaFAO9bDltvYnhpVfop20cyHroNluiwqNpLtCq/UpCjMYNM3VEby5Q9g==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR04MB4537
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


On 01.10.21 17:22, Alan Stern wrote:
> On Fri, Oct 01, 2021 at 03:26:48AM +0000, Hayes Wang wrote:
>>> Alan Stern <stern@rowland.harvard.edu>
>>> [...]
>>>> 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=20
> should never happen.  Or only extremely rarely (for example, caused=20
> by external electromagnetic interference).
And the device. I am afraid the condition in your conditional statement
is not as likely to be true as would be desirable for quite a lot setups.
>
>> It seems to be reasonable why resubmission sometimes works.
> Did you ever track down the reason why you got the -EPROTO error=20
> while debugging that other issue?  Can you reproduce it?

Is that really the issue though? We are seeing this issue with EPROTO.
But wouldn't we see it with any recoverable error?

AFAICT we are running into a situation without progress because drivers
retry

* forever
* immediately

If we broke any of these conditions the system would proceed and the
hotplug event be eventually be processed. We may ask whether drivers should
retry forever, but I don't see that you can blame it on error codes.

=C2=A0=C2=A0=C2=A0 Regards
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Oliver