wifi: mt76: mt7925: fix rmmod hang and token idr race in unregister

[Ashcal9669]

Supersedes #70 (closed after review found a real race in that version).

@Lucid-Duck found that the napi_disable() loop removed in #70 wasn't
redundant: it was accidentally quiescing NAPI before
mt7925_tx_token_put()'s idr_destroy(). Without it, a still in-flight
RX NAPI poll can reach PKT_TYPE_TXRX_NOTIFY -> mt76_token_release() -> idr_remove() on the same idr concurrently with that idr_destroy().

This version:

• Restores a single napi_disable()/napi_enable() pair around
  mt7925_tx_token_put() — napi_disable() synchronously waits out any
  in-flight poll, closing the race before idr_destroy() runs.
• Keeps the original double-napi_disable() hang fixed by adding
  MT76_REMOVED early-exits to mt792x_irq_tasklet(), mt792x_poll_tx(),
  mt792x_poll_rx() (mt792x_dma.c), matching the pattern already used by
  the non-PCI bus types in this driver family. napi_enable()'s re-open
  window is inert because of these guards, so mt792x_dma_cleanup()'s
  later napi_disable() is always a fresh, terminating one.
• Adds a second __mt792x_mcu_drv_pmctrl() call right before
  mt792x_dma_cleanup()/mt792x_wfsys_reset(): those do raw WFDMA/WFSYS
  register I/O and need driver ownership, but mt76_unregister_device()'s
  vif teardown can queue pm->ps_work and hand ownership back to firmware
  before cancel_delayed_work_sync(&pm->ps_work) catches it. The
  pre-existing call before mt76_unregister_device() is kept since that
  teardown itself needs ownership too.

Full mechanism and the double-disable history (4ab8f2122dcb →
f5f14a017454 revert → 332bbe9b2784 reintroduction) are in the commit
message.

Verified: all tests/mt7927/*.sh source contracts covering this
function pass, clean build against 7.2.0-rc1-mt7927-monitor-v3, and 8
consecutive real modprobe/modprobe -r cycles on physical MT7927
hardware with zero hangs and zero dmesg warnings.

Out of scope, flagged not missed: mt7921e_unregister_device()
(mt7921/pci.c) has the identical double-napi_disable() pattern, and
mt7921_pci_remove() sets MT76_REMOVED after calling unregister
(mt7925_pci_remove() sets it before), so the shared guards added here
don't protect mt7921e. Happy to follow up there if wanted.

[Lucid-Duck]

@Ashcal9669 I've opened #72, a revert of the commit that added the second disable, which changes what this one should be.

Once that lands, the napi_enable here leaves receive NAPI on when the queues get deleted, and that brings back the warnings the original commit was written to stop. Enabling clears the bit that both netif_napi_del and the page pool teardown warn on.

The MT76_REMOVED checks are a different story and worth keeping either way. They close a real window and they hold with or without the revert.

If you narrow this to just those, I'll merge it.

[Ashcal9669]

@Lucid-Duck on it. Thank you for reviewing it. I'll report back asap.

[Ashcal9669]

Narrowed to just the MT76_REMOVED guards + napi_disable() (no re-enable), as requested — force-pushed. Also folded in a separate, related bug: tasklet_kill() was missing from mt7925_pci_remove() (only present in the suspend path), which Mikhail Gavrilov flagged in the same upstream thread as a potential use-after-free if a tasklet is still pending when mt76_free_device() frees the memory it points into. Added tasklet_kill(&dev->mt76.irq_tasklet) there.

Verified: contracts pass, clean build, 4 consecutive modprobe/modprobe -r cycles on physical MT7927 hardware immediately after a fresh reboot, zero hangs/warnings.

[Lucid-Duck]

@Ashcal9669 Good catch folding in the tasklet_kill, that gap is real.

One thing about tasklet_kill that caught me out when I went looking: it waits on TASKLET_STATE_SCHED, and a disabled tasklet gets requeued without ever clearing that bit, so a kill on a disabled one spins instead of returning. unregister_device disables irq_tasklet and nothing re-enables it, so remove arrives with the count still up. The suspend path sidesteps it by doing synchronize_irq then kill with nothing disabled. Might be simplest to drop the tasklet_disable and let kill cover both jobs, since your MT76_REMOVED guard already keeps it off the hardware.

One I could not follow: the message calls the pmctrl before mt76_unregister_device the pre-existing one, but on main the only one is after tx_token_put. Which did you mean?

Worth knowing an idle unload will not show this either way. It needs a tasklet actually pending, so traffic in flight when remove runs. I can put that through here if it would help.

[Ashcal9669]

@Lucid-Duck Both real, force-pushed a fix for both.

tasklet_kill spin: you're right, and I found the mechanism you're describing confirmed in mt792x_irq_handler() — it already checks MT76_REMOVED before tasklet_schedule(), so no new scheduling happens once that's set regardless of tasklet_disable(). Dropped the tasklet_disable() call in mt7925e_unregister_device() entirely; tasklet_kill() in mt7925_pci_remove() now does the whole job on its own, relying on mt792x_irq_tasklet()'s own MT76_REMOVED guard to stay inert if it does run once more. Tested idle (4x clean) and with active RX traffic in flight during unload (5x clean, tcpdump running concurrently) — didn't hit the spin, but I'll take the offer if you're able to put real traffic through it on your end, the window's inherently narrow and I'd rather have your confirmation than just mine.

pmctrl wording: my mistake, not yours — checked the actual pre-PR base (c1455af3) and there was never a call before mt76_unregister_device(), only the one after tx_token_put() that's still there unchanged. I misdescribed the first one as "pre-existing" when it's new. Commit message corrected.