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

[Ping-Ke Shih <pkshih@realtek.com>]

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);
> >