Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925

From: Rong Zhang

Date: Mon Aug 10 2026 - 16:09:40 EST


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@xxxxxxxxxx/T/#u

I believe the proper fix of autopm failure during initialization is
https://lore.kernel.org/linux-bluetooth/20250319231235.812700-1-sean.wang@xxxxxxxxxx/

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