diff mbox series

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

Message ID 1E6ABDEA91ADAB1A+20241218090833.140045-1-wangyuli@uniontech.com (mailing list archive)
State New
Delegated to: Felix Fietkau
Headers show
Series [RESEND.] mt76: mt76u_vendor_request: Do not print error messages when -EPROTO | expand

Commit Message

WangYuli Dec. 18, 2024, 9:08 a.m. UTC
When initializing the network card, unplugging the device will
trigger an -EPROTO error, resulting in a flood of error messages
being printed frantically.

Co-developed-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Signed-off-by: WangYuli <wangyuli@uniontech.com>
---
 drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Comments

Alexander Lobakin Dec. 18, 2024, 4:10 p.m. UTC | #1
From: Wangyuli <wangyuli@uniontech.com>
Date: Wed, 18 Dec 2024 17:08:33 +0800

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

Is it a fix or an improvement?
You need to specify the target tree, either 'PATCH net' (fixes) or
'PATCH net-next' (improvements).

The '.' after 'RESEND' is not needed.

> When initializing the network card, unplugging the device will
> trigger an -EPROTO error, resulting in a flood of error messages
> being printed frantically.
> 

If it's a fix, you need to have a 'Fixes:' tag here.

> Co-developed-by: Xu Rao <raoxu@uniontech.com>
> Signed-off-by: Xu Rao <raoxu@uniontech.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.com>
> ---
>  drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
> index 58ff06823389..f9e67b8c3b3c 100644
> --- a/drivers/net/wireless/mediatek/mt76/usb.c
> +++ b/drivers/net/wireless/mediatek/mt76/usb.c
> @@ -33,9 +33,9 @@ int __mt76u_vendor_request(struct mt76_dev *dev, u8 req, u8 req_type,
>  
>  		ret = usb_control_msg(udev, pipe, req, req_type, val,
>  				      offset, buf, len, MT_VEND_REQ_TOUT_MS);
> -		if (ret == -ENODEV)
> +		if (ret == -ENODEV || ret == -EPROTO)
>  			set_bit(MT76_REMOVED, &dev->phy.state);
> -		if (ret >= 0 || ret == -ENODEV)
> +		if (ret >= 0 || ret == -ENODEV || ret == -EPROTO)
>  			return ret;
>  		usleep_range(5000, 10000);

How do other drivers handle this?
Can -EPROTO happen in other cases, not only unplugging, which this patch
would break?

Thanks,
Olek
Kalle Valo Dec. 18, 2024, 4:50 p.m. UTC | #2
Alexander Lobakin <aleksander.lobakin@intel.com> writes:

> From: Wangyuli <wangyuli@uniontech.com>
> Date: Wed, 18 Dec 2024 17:08:33 +0800
>
>> [RESEND. PATCH] mt76: mt76u_vendor_request: Do not print error messages when -EPROTO
>
> Is it a fix or an improvement?
> You need to specify the target tree, either 'PATCH net' (fixes) or
> 'PATCH net-next' (improvements).

Actually this is a wireless driver so the options are either wireless
tree or Felix' tree (for -next). And please add 'wifi:' to subject.
WangYuli Dec. 19, 2024, 7:11 a.m. UTC | #3
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.
> 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.

Just do not vendor request again for urb marked with status set -EPROTO .


Thanks,
diff mbox series

Patch

diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 58ff06823389..f9e67b8c3b3c 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -33,9 +33,9 @@  int __mt76u_vendor_request(struct mt76_dev *dev, u8 req, u8 req_type,
 
 		ret = usb_control_msg(udev, pipe, req, req_type, val,
 				      offset, buf, len, MT_VEND_REQ_TOUT_MS);
-		if (ret == -ENODEV)
+		if (ret == -ENODEV || ret == -EPROTO)
 			set_bit(MT76_REMOVED, &dev->phy.state);
-		if (ret >= 0 || ret == -ENODEV)
+		if (ret >= 0 || ret == -ENODEV || ret == -EPROTO)
 			return ret;
 		usleep_range(5000, 10000);
 	}