On 2024/12/19 00:10, Alexander Lobakin wrote:
It is a fix not an improvement.Is it a fix or an improvement? You need to specify the target tree, either 'PATCH net' (fixes) or 'PATCH net-next' (improvements).
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,
WangYuli
Attachment:
OpenPGP_0xC5DA1F3046F40BEE.asc
Description: OpenPGP public key
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
