From: moosager <moosager90@gmail.com>
To: Devin Wittmayer <lucid_duck@justthetip.ca>
Cc: Felix Fietkau <nbd@nbd.name>,
Lorenzo Bianconi <lorenzo@kernel.org>,
linux-wireless@vger.kernel.org,
linux-mediatek@lists.infradead.org,
Ryder Lee <ryder.lee@mediatek.com>,
Shayne Chen <shayne.chen@mediatek.com>,
Sean Wang <sean.wang@mediatek.com>,
Deren Wu <deren.wu@mediatek.com>
Subject: Re: [PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path
Date: Thu, 20 Aug 2026 18:01:26 +0200 [thread overview]
Message-ID: <aocbq-_gRsXgFV94@fedora.fritz.box> (raw)
In-Reply-To: <20260819171454.21329-1-lucid_duck@justthetip.ca>
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>
next prev parent reply other threads:[~2026-08-20 16:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 1:23 [PATCH wireless] wifi: mt76: mt7921: check drv_pmctrl return in the PCIe reset path Devin Wittmayer
2026-08-13 12:37 ` moosager
2026-08-19 17:14 ` Devin Wittmayer
2026-08-20 16:01 ` moosager [this message]
2026-08-22 4:16 ` Devin Wittmayer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aocbq-_gRsXgFV94@fedora.fritz.box \
--to=moosager90@gmail.com \
--cc=deren.wu@mediatek.com \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-wireless@vger.kernel.org \
--cc=lorenzo@kernel.org \
--cc=lucid_duck@justthetip.ca \
--cc=nbd@nbd.name \
--cc=ryder.lee@mediatek.com \
--cc=sean.wang@mediatek.com \
--cc=shayne.chen@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.