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

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.