[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 at 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.