All of lore.kernel.org
 help / color / mirror / Atom feed
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>

  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.