From: Wangyuli <wangyuli@xxxxxxxxxxxxx> 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
