[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250129183109.10770-1-jglotzer@gmail.com>
Date: Wed, 29 Jan 2025 12:31:09 -0600
From: John Glotzer <jglotzer@...il.com>
To: rtl8821cerfe2@...il.com
Cc: Aaron.Hou@...iatek.com,
Chris.Lu@...iatek.com,
Deren.Wu@...iatek.com,
Hao.Qin@...iatek.com,
Sean.Wang@...iatek.com,
jglotzer@...il.com,
johan.hedberg@...il.com,
linux-bluetooth@...r.kernel.org,
linux-kernel@...r.kernel.org,
linux-mediatek@...ts.infradead.org,
luiz.dentz@...il.com,
marc.payne@...sys.co.uk,
marcel@...tmann.org,
regressions@...ts.linux.dev,
sergio.callegari@...bo.it,
steve.lee@...iatek.com,
tiwai@...e.de
Subject: Re: [PATCH] Bluetooth: btmtk: Remove resetting mt7921 before downloading the fw
Good news/TLDR
Yes, so far I have resumed from sleep 2x without any issues
with both of my workarounds disabled (kernel command line/systemd rfkill on sleep).
What I don't yet understand
This commit
(https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/diff/drivers/bluetooth/btusb.c?id=v6.12.8&id2=v6.12.7)
was a pure USB fix. My mt7922 device (not a USB dongle but built into the motherboard)
seems to be both a bluetooth device (bound to btusb driver) *and* a Wifi device (bound to mt7921e driver).
I remain puzzled as to how is it that the issue that is on the USB side was *also* fixed by
adding mt7921e.disable_aspm=y to the kernel command line (since that would act on the wifi/pci pathway)?
Powered by blists - more mailing lists