Skip to contentSkip to conversation

rtw88: usb: retry control message on -EPROTO error

PATCH In review VolcomIlluminated 3 participants 4 messages May 28 – Jun 1

lore
Share & tools
lore

VolcomIlluminated

author
#0 lore raw

PATCH 1/1 rtw88: usb: retry control message on -EPROTO error

Patch Attached!

Signature · 2 lines
 Secured with Tuta Mail: 
 https://tuta.com/free-email

From: VolcomIlluminated <[email protected]>
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 <[email protected]>

---

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +10 -0
@@ -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);
#1 lore raw

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c

Quoted 2 lines · VolcomIlluminated
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +0 -0

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: ...".

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c line 150

Quoted 12 lines
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +8 -0
@@ -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?

Quoted 5 lines
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +2 -0
+		}
+	}
 	if (ret < 0 && ret != -ENODEV && count++ < 4)
 		rtw_err(rtwdev, "write register 0x%x failed with %d\n",
 			addr, ret);
#2 lore raw
Quoted 36 lines · Ping-Ke Shih

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c

Quoted 2 lines · VolcomIlluminated
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +0 -0

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: ...".

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c line 150

Quoted 12 lines
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +8 -0
@@ -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 */
}
Quoted 3 lines

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.

Quoted 6 lines
Quoted 5 lines
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c +2 -0
+		}
+	}
 	if (ret < 0 && ret != -ENODEV && count++ < 4)
 		rtw_err(rtwdev, "write register 0x%x failed with %d\n",
 			addr, ret);
#3 lore raw
Quoted 46 lines · Bitterblue Smith
Quoted 4 lines · Ping-Ke Shih

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2026-05-24

Quoted 2 lines · VolcomIlluminated
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2026-05-24 renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2025-11-30 17:42:10.000000000 -0500 +0 -0

20:06:27.798337237 -0400

Quoted 32 lines

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: ...".

home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2026-05-24 line 150

Quoted 12 lines
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2026-05-24 renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2025-11-30 17:42:10.000000000 -0500 +8 -0
@@ -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 */
}
Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 9 lines

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.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
home/ptpx86mm1/kernelbuild/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2026-05-24 renamed from tmp/linux-6.18/drivers/net/wireless/realtek/rtw88/usb.c 2025-11-30 17:42:10.000000000 -0500 +2 -0
+            }
+    }
     if (ret < 0 && ret != -ENODEV && count++ < 4)
             rtw_err(rtwdev, "write register 0x%x failed with %d\n",
                     addr, ret);