Re: [RESEND. PATCH] mt76: mt76u_vendor_request: Do not print error messages when -EPROTO

[Alexander Lobakin <aleksander.lobakin@intel.com>]

From: Wangyuli <wangyuli@uniontech.com>
Date: Thu, 19 Dec 2024 15:11:24 +0800

> On 2024/12/19 00:10, Alexander Lobakin wrote:
> 
>> Is it a fix or an improvement?
>> You need to specify the target tree, either 'PATCH net' (fixes) or
>> 'PATCH net-next' (improvements).
>  It is a fix not an improvement.

So you need to add the correct tree and/or subject prefix and specify
"Fixes:" tag with the commit this change fixes.

>> How do other drivers handle this?
>> Can -EPROTO happen in other cases, not only unplugging, which this patch
>> would break?
>>
> When initializing the network card, unplugging the device will trigger
> an -EPROTO error.
> 
> The exception is printed as follows：
> 
>         
>         mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71
>         mt76x2u 2-2.4:1.0: vendor request req:47 off:9018 failed:-71
>         ...
>         
> 
> It will continue to print more than 2000 times for about 5 minutes,
> causing the usb device to be unable to be disconnected.  During this
> period, the usb port cannot recognize the new device because the old
> device has not disconnected.
> 
> There may be other operating methods that cause -EPROTO, but -EPROTO is
> a low-level hardware error. It is unwise to repeat vendor requests
> expecting to read correct data. It is a better choice to treat -EPROTO
> and -ENODEV the same way.
> 
> Similar to commit （mt76: usb: process URBs with status EPROTO
> properly）do no schedule rx_worker for urb marked with status set -
> EPROTO. I also reproduced this situation when plugging and unplugging
> the device, and this patch is effective.

I'm not a wireless expert, from my PoV sounds good. Just describe
everything in details in the commit message, so that it will be clear
for everyone.

> 
> Just do not vendor request again for urb marked with status set -EPROTO .
> 
> 
> Thanks,
> 
> -- 
> WangYuli

Thanks,
Olek