[PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
Rong Zhang
i at rong.moe
Mon Aug 10 13:03:38 PDT 2026
Hi Michal,
Thanks for your insight.
On Sun, 2026-08-09 at 22:33 +0200, Michal Pecio wrote:
> On Mon, 29 Jun 2026 03:01:19 +0000, Chris Lu (陸稚泓) wrote:
> > Hi Rong,
> >
> > Thanks for your understanding. We hope to find a better way to handle
> > this issue.
> >
> >
> > Hi Luiz,
> >
> > Regarding this issue, MediaTek Bluetooth team has already initialed an
> > internal investigation for problematic combination and will seek
> > assistance from AMD SOC team to investigate the root cause of this
> > issue.
>
> Hi,
>
> I have seen multiple reports on Arch Linux forum of MTK Bluetooth chips
> sporadically locking up and no longer enumerating on AMD systems, also
> desktops, which had to be unplugged from power to restore operation.
>
> I have also seen claims that auto power management is broken in btusb:
> https://lore.kernel.org/linux-bluetooth/cover.1774348119.git.berto@igalia.com/T/#u
I believe the proper fix of autopm failure during initialization is
https://lore.kernel.org/linux-bluetooth/20250319231235.812700-1-sean.wang@kernel.org/
Some time earlier this year I was planing to pick it up and push it
forward, but it turned out I was too busy. Maybe I will find some time...
That being said, the bug I encountered has nothing to with the device
initialization though.
>
> This, if true, offers a plausible theory because:
> - URBs issued to suspended devices may fail, drivers may not notice,
> make wrong assumptions about their HW state and confuse the chip
> - USB core doesn't reliably block submission of such URBs
Not the case of my devices. Autosuspend and (non-remote) autowakeup
always work fine. The only thing that triggers the bug is a random[1]
remote wakeup.
Usbmon always shows no URB between the autosuspend and the subsequent
remote wakeup, expect for the interrupt from the root hub.
[1]: it happens when no Bluetooth device is trying to establish a
connection.
> - they were also seen to break some xHCI controllers, in theory this
> might be an HC problem - power cycling resets both device and HC
I also think this might be one of the reasons.
Thanks,
Rong
>
> Regards,
> Michal
More information about the linux-arm-kernel
mailing list