Re: [PATCH] wifi: rtw88: usb: stop RX work before unregistering hardware

[Luka Gejak]

Hi Zhao,

Thanks for the fix. One comment below.

October 28, 2026 at 3:19 PM, "Zhao Li" <enderaoelyther@xxxxxxxxx> wrote:

> diff --git a/drivers/net/wireless/realtek/rtw88/usb.c b/drivers/net/wireless/realtek/rtw88/usb.c
> index 64e1c3420e0a..1d2759eb96bf 100644
> --- a/drivers/net/wireless/realtek/rtw88/usb.c
> +++ b/drivers/net/wireless/realtek/rtw88/usb.c
> @@ -1370,7 +1370,10 @@ void rtw_usb_disconnect(struct usb_interface *intf)
>       rtwdev = hw->priv;
>       rtwusb = rtw_get_usb_priv(rtwdev);
>
> +     /* Stop deferred resubmission before killing the active RX URBs. */
> +     disable_work_sync(&rtwusb->rx_urb_work);

As far as I can see, rx_urb_work can't bring an URB back at this point.
rtw88 doesn't set soft_unbind, so the USB core disables the endpoints
before it calls the driver:

        usb_unbind_interface()
          usb_disable_interface()
            usb_disable_endpoint()
              ep->enabled = 0;
          driver->disconnect()
            rtw_usb_disconnect()

After that usb_submit_urb() on the RX pipe fails for the rest of the RX
teardown, and a failed submit only queues the work again on -ENOMEM. So I
think cancel_work_sync() on rx_work alone already closes the race, and
the same change would then work for the older stable trees too.

Keeping disable_work_sync() doesn't hurt, but then the commit message
shouldn't say the work can restart a killed URB. Or did I miss a path
where we get here with the endpoints still enabled?

Best regards,
Luka Gejak