Re: mt7921e: failure to reset causes network drop

[Devin Wittmayer <lucid_duck@justthetip.ca>]

moosager,

Thanks for confirming the ruling-out list, and the Bluetooth detail is
worth having on the thread.

On which tree. Patchwork says accepted, which means a maintainer took it
and says nothing about mainline. That is why you could not find it.

	openwrt/mt76   8e856ad93d3a   mt7921, applied 27 August
	               4f2aa9910e0c   mt7925, applied 27 August
	mainline       neither, checked today

Mainline still ignores the return in both of those resets, and I would
not put a date on when that changes.

Your Tested-by went on the mt7921 one.

Devin

On Sat, 12 Sep 2026, moosager wrote:

> Hi Devin,
>
> > On debugging further, I had the same ownership handshake fail on a mini PC
> > here. What that ruled out, so you can skip them: in-tree against out-of-tree
> > builds, a PCI bus reset, remove and rescan, and a cold boot. The Bluetooth
> > half of the same chip kept working throughout, so the silicon was alive and
> > only the WiFi side was stuck.
>
> I can confirm these are the things I've had to rule out with my testing as well.
> I can also attest to the fact that the Bluetooth half of the chip works
> regardless of the Wi-Fi's state (I should've mentioned that earlier): I've used
> my laptop for a while with mt7921e unloaded, all the while Bluetooth was working
> the whole time.
>
> > There is a patch for it that the maintainer has taken
>
> Good, though I don't see which tree it has been merged in, I'm sure I'll see it
> soon in a future release.
>
> > It sits downstream of your bad read though, so it will not stop the
> > register going wrong in the first place.
>
> True, I will stress that the root cause has not been found yet and this chip is
> still unusable for me (and others).
>
> Sorry for the late reply, I'll test the output of lspci as well when I get the
> chance to debug this further.