Re: [PATCH mt76] wifi: mt76: mt792x: drop redundant napi_disable() in unregister path

On Wed, Jul 29, 2026 at 11:17 AM Devin Wittmayer
<[email protected]> wrote:
>
> Tested-by: Devin Wittmayer <[email protected]>
>
> Confirmed on two more cards here, one of them an MT7927, which I do not think
> has come up in this thread yet.
>
> This one cost me both machines today, mid driver work. Each went to garbled
> colour and froze hard on the way down, power button only.
>
> Same base commit either side, nothing else changed between the two builds:
>
>   MT7927 / mt7925e, kernel 7.1.5    stock: rmmod hangs    patched: returns in 0s
>   MT7922 / mt7921e, kernel 7.0.5    stock: rmmod hangs    patched: returns in 0s
>
> Stock leaves the task in D and the module at refcount -1:
>
>   napi_disable_locked+0xdd/0xf0
>   napi_disable+0x25/0x40
>   mt76_dma_cleanup+0x16a/0x340 [mt76_git]
>   mt7925_pci_remove+0xe5/0x1a0 [mt7925e_git]
>
> Patched, rmmod returns immediately and the card comes back on a reload. sysrq-w
> puts usleep_range_state right above napi_disable_locked on both, and nothing
> warns while it is stuck, no hung task and no lockup.
>
> How I tested, since it was not a mainline tree. Both kernels predate
> 13b7e6a96a00 so their in-tree mt76 is clean, and I used the out-of-tree build
> instead, morrownr at 905c0d79, which is where the _git suffix comes from. Your
> mt7921 hunk applied verbatim. The mt7925 one did not, only because that tree
> carries an mlo_pm_work cancel that is not upstream yet, so I took out the same
> three lines by hand. Mainline matches your base exactly, so nothing needs
> rebasing on your end.
>
> Two things from reading around it. These two sites look like the only ones that
> double up, since every other napi_disable in the tree is a suspend or a reset
> that turns it back on straight after. And USB looks clear, because
> mt792xu_cleanup goes via mt76u_queues_deinit and never reaches
> mt76_dma_cleanup, so this may well be PCIe only.

Thanks for testing, and for the MT7927 data point - it shares
mt7925e_unregister_device(), so it is covered by the same hunk.

Both of your observations match what I found: these two are the only
sites that double up, every other napi_disable() in the tree is a
suspend or reset paired with a napi_enable(), and the USB path goes
mt792xu_cleanup() -> mt76u_queues_deinit() without ever reaching
mt76_dma_cleanup(), so this is PCIe only.

For the record, since you tested an out-of-tree build: Bert has
confirmed the patch as posted on next-20260727 with mt7925, so both
sides are covered.

-- 
Thanks,
Mikhail