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