Re: [RFC 1/2] wifi: mt76: disable NAPI before deleting in dma_cleanup

[Ben Greear <greearb@candelatech.com>]

On 9/19/26 20:49, Devin Wittmayer wrote:
> On 9/16/26 13:47, Ben Greear wrote:
>> +		napi_disable(&dev->napi[i]);
>>   		netif_napi_del(&dev->napi[i]);
> 
> Ben,
> 
> The warning and the softirqd spin are both real, and your 2/2 looks like
> the right place for them.
> 
> On 1/2 there is a snag. mt7921e and mt7925e already stop RX themselves,
> and they do it early:
> 
> 	mt76_unregister_device()
> 	napi_disable() on each rx queue
> 	tx_token_put()
> 	mt792x_dma_cleanup()
> 
> It has to be early. A poll still in flight can come back with a transmit
> status and take an entry out of the table tx_token_put() is tearing
> down. By the time the shared cleanup runs RX is already stopped, so a
> second disable there just sits:
> 
> 	task in D state, refcount -1
> 	napi_disable_locked <- mt76_dma_cleanup <- mt7925_pci_remove
> 
> That was on MT7927. The USB parts tear down a different way and never
> arrive, which is probably why this is easy to miss.
> 
> Would putting the disable next to the IRQ and tasklet work in your 2/2
> cover mt7996? That keeps it where the driver already knows whether it
> has stopped RX.

I have a hard time figuring out exactly how to safely tear down
the mt7996 driver, especially without breaking other mt76 drivers.

But instead of just playing whack-a-mole with this,
we should figure out if sub-driver or mt76 core should be handling this,
and add some comments of expected behaviour so we don't keep fixing one chipset
and breaking another.

Maybe Felix has an opinion on correct path forward?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com