[PATCH] rtw88: usb: retry control message on -EPROTO error

[PATCH] rtw88: usb: retry control message on -EPROTO error

[VolcomIlluminated]

[-- Attachment #1.1: Type: text/plain, Size: 75 bytes --]

Patch Attached!
-- 
 Secured with Tuta Mail: 
 https://tuta.com/free-email

[-- Attachment #1.2: Type: text/html, Size: 406 bytes --]

[-- Attachment #2: 0002-rtw88-usb-retry-on-EPROTO-error.patch --]
[-- Type: application/octet-stream, Size: 1462 bytes --]

From: VolcomIlluminated <volcomilluminated@tuta.com>
Date: Wed, 28 May 2026 00:00:00 +0000
Subject: [PATCH] rtw88: usb: retry control message on -EPROTO error

USB control messages can transiently fail with -EPROTO (-71) during
device probe on some USB host controllers. This manifests as repeated
"write register failed with -71" errors during driver initialization.

Add a retry loop of up to 3 attempts with 10ms delay when -EPROTO is
returned from usb_control_msg. This recovers the transient error and
allows the driver to initialize cleanly.

Tested on RTL8822BU (Edimax EW-7822ULC) with clean boot and zero
probe errors.

Signed-off-by: VolcomIlluminated <volcomilluminated@tuta.com>
---
--- /tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c	2025-11-30 17:42:10.000000000 -0500
+++ /home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c	2026-05-24 20:06:27.798337237 -0400
@@ -140,6 +140,16 @@
 	ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
 			      RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
 			      addr, 0, data, len, 500);
+	if (ret == -EPROTO) {
+		int retry;
+
+		for (retry = 0; retry < 3 && ret == -EPROTO; retry++) {
+			msleep(10);
+			ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
+					      RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
+					      addr, 0, data, len, 500);
+		}
+	}
 	if (ret < 0 && ret != -ENODEV && count++ < 4)
 		rtw_err(rtwdev, "write register 0x%x failed with %d\n",
 			addr, ret);

RE: [PATCH] rtw88: usb: retry control message on -EPROTO error

[Ping-Ke Shih]

VolcomIlluminated <volcomilluminated@tuta.com> wrote:
> --- /tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c	2025-11-30 17:42:10.000000000 -0500
> +++ /home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c	2026-05-24 20:06:27.798337237 -0400

Your git repository looks weird.

Please clone https://github.com/pkshih/rtw.git and switch to rtw-next branch.

By the way, the subject prefix should be "[PATCH rtw-next] wifi: rtw88: ...".

> @@ -140,6 +140,16 @@
>  	ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
>  			      RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
>  			      addr, 0, data, len, 500);
> +	if (ret == -EPROTO) {
> +		int retry;
> +
> +		for (retry = 0; retry < 3 && ret == -EPROTO; retry++) {
> +			msleep(10);
> +			ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> +					      RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
> +					      addr, 0, data, len, 500);

Don't duplicate the code of identical usb_control_msg(...).

Just 

for (retry = 0; retry < 3; retry++) {
	ret = usb_control_msg(...);
    if (ret != -EPROTO)
		break;

	msleep(10); /* delay before retrying */
}

Bitterblue, could you have some inputs about this retry, since I don't have
much knowledge about USB?

> +		}
> +	}
>  	if (ret < 0 && ret != -ENODEV && count++ < 4)
>  		rtw_err(rtwdev, "write register 0x%x failed with %d\n",
>  			addr, ret);

Re: [PATCH] rtw88: usb: retry control message on -EPROTO error

[Bitterblue Smith]

On 29/05/2026 04:09, Ping-Ke Shih wrote:
> 
> VolcomIlluminated <volcomilluminated@tuta.com> wrote:
>> --- /tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c	2025-11-30 17:42:10.000000000 -0500
>> +++ /home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c	2026-05-24 20:06:27.798337237 -0400
> 
> Your git repository looks weird.
> 
> Please clone https://github.com/pkshih/rtw.git and switch to rtw-next branch.
> 
> By the way, the subject prefix should be "[PATCH rtw-next] wifi: rtw88: ...".
> 
>> @@ -140,6 +140,16 @@
>>  	ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
>>  			      RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
>>  			      addr, 0, data, len, 500);
>> +	if (ret == -EPROTO) {
>> +		int retry;
>> +
>> +		for (retry = 0; retry < 3 && ret == -EPROTO; retry++) {
>> +			msleep(10);
>> +			ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
>> +					      RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
>> +					      addr, 0, data, len, 500);
> 
> Don't duplicate the code of identical usb_control_msg(...).
> 
> Just 
> 
> for (retry = 0; retry < 3; retry++) {
> 	ret = usb_control_msg(...);
>     if (ret != -EPROTO)
> 		break;
> 
> 	msleep(10); /* delay before retrying */
> }
> 
> Bitterblue, could you have some inputs about this retry, since I don't have
> much knowledge about USB?
> 

I think it's a good idea to retry in case of errors. The vendor drivers
try the control messages up to 10 times, both reads and writes, and not
just in case of -EPROTO.

Except when writing the firmware for the 8051 chips (address range
0x1000..0x1fff). Those writes are not retried, instead the entire
firmware download process is retried if it fails.

Also, they don't sleep between attempts.

But I would like to know more about the problem fixed by this patch.
What register writes fail with -EPROTO? How often does it happen?
How many times was this patch tested?

I wonder if the problem is simply the write to register 0xc4
(REG_PAD_CTRL2) which triggers the switch to USB 3? Like with the
wifi 6 and 7 chips, that call to usb_control_msg() always returns
-EPROTO. I assume it's because it makes the USB device disappear.

>> +		}
>> +	}
>>  	if (ret < 0 && ret != -ENODEV && count++ < 4)
>>  		rtw_err(rtwdev, "write register 0x%x failed with %d\n",
>>  			addr, ret);
> 

RE: [PATCH] rtw88: usb: retry control message on -EPROTO error

[Ping-Ke Shih]

Bitterblue Smith <rtl8821cerfe2@gmail.com> wrote:
> On 29/05/2026 04:09, Ping-Ke Shih wrote:
> >
> > VolcomIlluminated <volcomilluminated@tuta.com> wrote:
> >> --- /tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2025-11-30 17:42:10.000000000 -0500
> >> +++ /home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c  2026-05-24
> 20:06:27.798337237 -0400
> >
> > Your git repository looks weird.
> >
> > Please clone https://github.com/pkshih/rtw.git and switch to rtw-next branch.
> >
> > By the way, the subject prefix should be "[PATCH rtw-next] wifi: rtw88: ...".
> >
> >> @@ -140,6 +140,16 @@
> >>      ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> >>                            RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
> >>                            addr, 0, data, len, 500);
> >> +    if (ret == -EPROTO) {
> >> +            int retry;
> >> +
> >> +            for (retry = 0; retry < 3 && ret == -EPROTO; retry++) {
> >> +                    msleep(10);
> >> +                    ret = usb_control_msg(udev, usb_sndctrlpipe(udev, 0),
> >> +                                          RTW_USB_CMD_REQ, RTW_USB_CMD_WRITE,
> >> +                                          addr, 0, data, len, 500);
> >
> > Don't duplicate the code of identical usb_control_msg(...).
> >
> > Just
> >
> > for (retry = 0; retry < 3; retry++) {
> >       ret = usb_control_msg(...);
> >     if (ret != -EPROTO)
> >               break;
> >
> >       msleep(10); /* delay before retrying */
> > }
> >
> > Bitterblue, could you have some inputs about this retry, since I don't have
> > much knowledge about USB?
> >
> 
> I think it's a good idea to retry in case of errors. The vendor drivers
> try the control messages up to 10 times, both reads and writes, and not
> just in case of -EPROTO.
> 
> Except when writing the firmware for the 8051 chips (address range
> 0x1000..0x1fff). Those writes are not retried, instead the entire
> firmware download process is retried if it fails.
> 
> Also, they don't sleep between attempts.

Thanks for the info. 

VolcomIlluminated, please follow Bitterblue's suggestions as vendor driver does.

> 
> But I would like to know more about the problem fixed by this patch.
> What register writes fail with -EPROTO? How often does it happen?
> How many times was this patch tested?
> 
> I wonder if the problem is simply the write to register 0xc4
> (REG_PAD_CTRL2) which triggers the switch to USB 3? Like with the
> wifi 6 and 7 chips, that call to usb_control_msg() always returns
> -EPROTO. I assume it's because it makes the USB device disappear.

The commit message of original patch doesn't point out "write register 0x%x".
VolcomIlluminated, please share this info too. 

> 
> >> +            }
> >> +    }
> >>      if (ret < 0 && ret != -ENODEV && count++ < 4)
> >>              rtw_err(rtwdev, "write register 0x%x failed with %d\n",
> >>                      addr, ret);
> >