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

[Zhao Li <enderaoelyther@gmail.com>]

Hi Luka,

On Fri, Oct 30, 2026 at 02:51:43PM +0000, Luka Gejak wrote:
> 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?

You didn't miss one. usb_unbind_interface() is the only caller of an
interface driver's ->disconnect(), and none of the rtw88 USB drivers
sets soft_unbind. Before rtw_usb_disconnect() returns, only its own
usb_reset_device() enables the endpoints again, and that runs after
rtw_usb_deinit_rx() has destroyed rxwq.

rx_urb_work can still run until then after an allocation failure, but
its submit fails on the disabled endpoint. The commit message was wrong
about that.

I'll send a v2 that only adds cancel_work_sync(&rtwusb->rx_work) after
rtw_usb_cancel_rx_bufs(), with a corrected message and without the
3e3aa566dd18 Fixes tag. It applies unchanged to 6.6.y and later.

Thanks,
Zhao