[PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path

[PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path

[Devin Wittmayer]

mt7921e_mac_reset() ignores what mt792xe_mcu_drv_pmctrl() returns. The
probe, suspend and resume paths all check it. The only other caller that
does not is mt7921e_unregister_device(), where the device is going away.

If the driver-own handshake does not complete, __mt792xe_mcu_drv_pmctrl()
gives up after MT792x_DRV_OWN_RETRY_COUNT and returns -EIO without
reinitialising WPDMA or clearing MT76_STATE_PM. The reset continues anyway,
writing interrupt enable registers, cycling NAPI, resetting WPDMA and
downloading firmware to a chip the driver does not own.

On an MT7922 with MT_CONN_ON_LPCTL held asserted, a triggered reset gave 8
ownership failures, each followed by an MCU timeout and a failed firmware
download:

  mt7921e 0000:04:00.0: driver own failed
  mt7921e 0000:04:00.0: Message 00000010 (seq 7) timeout
  mt7921e 0000:04:00.0: Failed to get patch semaphore

With the return checked, 26 ownership failures produced no firmware
download, and mt7921_mac_reset_work() got as far as logging "chip reset
failed", which it never did otherwise.

The call sits before any teardown, so returning early leaves NAPI and the
TX worker alone. This does not fix why the handshake fails.

Reported-by: moosager <moosager90@gmail.com>
Link: https://lore.kernel.org/linux-wireless/anG46qbvCqCHGF-f@fedora.fritz.box/
Fixes: dfc7743de1eb ("mt76: mt7921: refactor mcu.c to be bus independent")
Signed-off-by: Devin Wittmayer <lucid_duck@justthetip.ca>
---
 drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c b/drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c
index 0db7acb3a637..c4261f66f469 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7921/pci_mac.c
@@ -57,7 +57,9 @@ int mt7921e_mac_reset(struct mt792x_dev *dev)
 {
 	int i, err;
 
-	mt792xe_mcu_drv_pmctrl(dev);
+	err = mt792xe_mcu_drv_pmctrl(dev);
+	if (err)
+		return err;
 
 	mt76_connac_free_pending_tx_skbs(&dev->pm, NULL);
 
-- 
2.54.0

Re: [PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path

[moosager]

Hello,

I can confirm the patch works as advertised:

> With the return checked, 26 ownership failures produced no firmware
> download, and mt7921_mac_reset_work() got as far as logging "chip reset
> failed", which it never did otherwise.

I would like to reiterate, though, that a more complete fix should be pursued by 
anyone who has more knowledge of the driver or firmware. Previously, a marginal 
improvement like this one was applied, but the issue persists to this day 
(see [1]).

Thanks in advance.

[1] https://patchwork.kernel.org/project/linux-wireless/patch/727eb5ffd3c7c805245e512da150ecf0a7154020.1659452909.git.deren.wu@mediatek.com/

Re: [PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path

[Devin Wittmayer]

Thanks for testing it, and sorry for the slow reply.

If you're up for it, reply with this line and it'll get picked up:

Tested-by: moosager <moosager90@gmail.com>

Fair point on the 2022 one. The difference is Deren's had to be a goto
because napi was already torn down by then, mine returns before any of that
runs. Still doesn't tell you why the handshake fails though, you're right
there.

On the debugging, I instrumented the same failure on an MT7922 back in July.
Wedged, it read lpctl=0x00000004 and misc=0x00000003, and a scratch write of
0xa5a5a5a5 read back exactly. So on mine the bus is fine and the chip is
alive, it just won't give ownership up.

Yours reads 0xffffffff where mine reads 0x4, and that's the part I'd chase.
The same write test tells you which one you've got, no patch needed, and
nothing on the host side reads that register:

  echo 0x54000120 > /sys/kernel/debug/ieee80211/phy0/mt76/regidx
  echo 0xa5a5a5a5 > /sys/kernel/debug/ieee80211/phy0/mt76/regval
  cat /sys/kernel/debug/ieee80211/phy0/mt76/regval

Comes back 0xa5a5a5a5 and it's alive and latched like mine. Comes back
0xffffffff and it's off the bus, which is a different bug.

Your repro wedges an MT7922 here too, for what it's worth, not just your
laptop.

Devin

On 13 Aug 2026, moosager wrote:

> I would like to reiterate, though, that a more complete fix should be
> pursued by anyone who has more knowledge of the driver or firmware.
> Previously, a marginal improvement like this one was applied, but the
> issue persists to this day (see [1]).

On 4 Aug 2026, moosager wrote:

> and it expects to find 0x00000004 (which is PCIE_LPCR_HOST_OWN_SYNC).
> Instead, when the issue happens, it finds 0xffffffff, which does not
> change even after the driver attempts to write to it.
>
> I would like some guidance as to how I could debug the issue further,
> though ultimately the problem is likely in the firmware.

Re: [PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path

[moosager]

Hello,

I've tested your commands with a vanilla kernel (no patches applied): the 
results differ based on whether the bug is triggered by my orignal script to 
reproduce the issue, or the issue happens naturally.

For reference, this is what i mean by "my original script":
#!/bin/sh
echo 0x7c060010 > /sys/kernel/debug/ieee80211/phy0/mt76/regidx
while true; do echo 0xffffffff > /sys/kernel/debug/ieee80211/phy0/mt76/regval ; done
(to be inturrupted with Ctrl-C after 2-3 seconds)

So, when the issue happens on its own, your script (accessing register 
0x54000120) outputs 0xffffffff, and even me attempting to write 0xa5a5a5a5 in a 
loop won't change anything.

Instead, when the issue is triggered by my original script, your script outputs 
0xffff0002; again, I cannot manage to manually write a different value to the 
register. In addition, with my original script I sometimes get messages in 
dmesg saying:
> mt7921e: MCU is not ready for firmware download

So it would seem that my script does not reproduce the issue identically: 
however, whether the trigger is artificial or not, the issue pops back up 
naturally on subsequent reboots almost immediately.

> Yours reads 0xffffffff where mine reads 0x4

0x4 is the correct value for it to read, and it should correspond to 
PCIE_LPCR_HOST_OWN_SYNC. When I was testing the bug with some dev_info(), 0x4 
was the value read all the time up until the issue happened and it started 
reading 0xffffffff.

> Comes back 0xa5a5a5a5 and it's alive and latched like mine. Comes back
> 0xffffffff and it's off the bus, which is a different bug.

We may be looking at two different issues after all, both mitigated by an error 
check that was missing anyway. I'm still inclined to say that it is not a 
hardware issue, since nothing similar happens on Windows.

> If you're up for it, reply with this line and it'll get picked up:

Tested-by: moosager <moosager90@gmail.com>

Re: [PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path

[Devin Wittmayer]

Thanks, tag will go on.

Interesting though, neither of your readings matches mine. Mine reads
the right value and takes a scratch write; both of yours refuse it. The
all-ones one is the card not answering at all by that point. The other
still has something on the end of it that just will not hand over. Two
different problems like you said, and your script is reproducing the
wrong one.

On the natural one, I would check whether the card is still on the bus
when it hangs. Anything from PCIe in dmesg, and whether lspci can still
see it.

Would not read too much into Windows, different driver, different reset
path.

Devin

On 20 Aug 2026, moosager wrote:

> So, when the issue happens on its own, your script (accessing register
> 0x54000120) outputs 0xffffffff, and even me attempting to write
> 0xa5a5a5a5 in a loop won't change anything.
>
> Instead, when the issue is triggered by my original script, your
> script
> outputs 0xffff0002; again, I cannot manage to manually write a
> different value to the register.
>
> We may be looking at two different issues after all, both mitigated by
> an error check that was missing anyway. I'm still inclined to say that
> it is not a hardware issue, since nothing similar happens on Windows.
>
> Tested-by: moosager <moosager90@gmail.com>