* [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
@ 2026-06-02 18:38 Rong Zhang
2026-06-03 17:50 ` patchwork-bot+bluetooth
0 siblings, 1 reply; 2+ messages in thread
From: Rong Zhang @ 2026-06-02 18:38 UTC (permalink / raw)
To: Marcel Holtmann, Luiz Augusto von Dentz, Matthias Brugger,
AngeloGioacchino Del Regno
Cc: linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek,
Rong Zhang
These NICs are often reported to lose their Bluetooth interfaces, i.e,
their USB interfaces suddenly become completely unresponsive, causing
the USB core to reset them, only to find that they are no longer
accessible. A power cycle is required to make the Bluetooth interfaces
recover.
After some investigations, I found that their USB autosuspend remote
wakeup capabilities are so broken that they are precisely the culprit
behind the issue:
[27452.608056] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020
[27452.702018] usb 3-5: usb wakeup-resume
[27452.716038] usb 3-5: Waited 0ms for CONNECT
[27452.716642] usb 3-5: finish resume
/* usbmon showed that the device was completely unresponsive to any
URBs after the remote wakeup */
[27457.836030] usb 3-5: retry with reset-resume
[27457.956046] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
[27463.332047] usb 3-5: device descriptor read/64, error -110
[27478.948117] usb 3-5: device descriptor read/64, error -110
[27479.172430] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
[27484.332035] usb 3-5: device descriptor read/64, error -110
[27499.940039] usb 3-5: device descriptor read/64, error -110
[27500.164060] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
[27505.196142] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27510.576045] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27510.784038] usb 3-5: device not accepting address 4, error -62
[27510.912215] usb 3-5: reset high-speed USB device number 4 using xhci_hcd
[27515.948307] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27521.324380] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27521.525107] usb 3-5: device not accepting address 4, error -62
[27521.525928] usb usb3-port5: logical disconnect
[27521.525996] usb 3-5: gone after usb resume? status -19
[27521.526230] usb 3-5: can't resume, status -19
[27521.526434] usb usb3-port5: logical disconnect
[27521.526469] usb usb3-port5: resume, status -19
[27521.526493] usb usb3-port5: status 0503, change 0004, 480 Mb/s
[27521.526528] usb 3-5: USB disconnect, device number 4
[27521.526736] usb 3-5: unregistering device
[27521.804029] usb 3-5: new high-speed USB device number 5 using xhci_hcd
[27527.076067] usb 3-5: device descriptor read/64, error -110
[27542.692027] usb 3-5: device descriptor read/64, error -110
[27542.916047] usb 3-5: new high-speed USB device number 6 using xhci_hcd
[27548.068043] usb 3-5: device descriptor read/64, error -110
[27563.684073] usb 3-5: device descriptor read/64, error -110
[27563.792133] usb usb3-port5: attempt power cycle
[27563.924381] hub 3-0:1.0: port_wait_reset: err = -11
[27563.925213] usb usb3-port5: not enabled, trying reset again...
[27564.184398] usb 3-5: new high-speed USB device number 7 using xhci_hcd
[27569.196322] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27574.572040] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27574.776053] usb 3-5: device not accepting address 7, error -62
[27574.900165] usb 3-5: new high-speed USB device number 8 using xhci_hcd
[27579.948039] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27585.324331] xhci_hcd 0000:67:00.0: Timeout while waiting for setup device command
[27585.528040] usb 3-5: device not accepting address 8, error -62
[27585.528389] usb usb3-port5: unable to enumerate USB device
[27585.528424] hub 3-0:1.0: state 7 ports 5 chg 0000 evt 0020
To reproduce the issue, these conditions must be met:
- a noisy radio environment (cafe or office) to cause frequent remote
wakeup events
- no Bluetooth device is connected, so autosuspend is not prohibited
- the Bluetooth interface is opened, so remote wakeup is enabled when
the device runs into autosuspend
Then I can reproduce the issue within sereval hours each time.
Increasing TRSMRCY or setting USB_QUIRK_RESET doesn't help at all.
Since the remote wakeup capability is super broken, just disable it to
get rid of the troubles. The device can still be autosuspended when
the bluetooth interface is closed, which won't break the device as
remote wakeup is unneeded in this case.
Link: https://bbs.archlinux.org/viewtopic.php?id=308169
Link: https://bbs.bee-link.com/d/7694-gtr9-pro-ai-max-395-usb-issues
Signed-off-by: Rong Zhang <i@rong•moe>
---
drivers/bluetooth/btmtk.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c
index 8ff66b276af0..3d2a8598892b 100644
--- a/drivers/bluetooth/btmtk.c
+++ b/drivers/bluetooth/btmtk.c
@@ -1379,6 +1379,16 @@ int btmtk_usb_setup(struct hci_dev *hdev)
break;
case 0x7922:
case 0x7925:
+ /*
+ * A remote wakeup could cause the device completely unresponsive, and
+ * recovering from such a state needs a power cycle.
+ *
+ * Since the remote wakeup capability is super broken, just disable it
+ * to get rid of the troubles. The device can still be autosuspended
+ * when the bluetooth interface is closed.
+ */
+ device_set_wakeup_capable(&btmtk_data->udev->dev, false);
+ fallthrough;
case 0x7961:
case 0x7902:
case 0x6639:
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: a4222333-btmtk-remote-wakeup-494f4c97af88
Thanks,
Rong
^ permalink raw reply related [flat|nested] 2+ messages in thread
* Re: [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
2026-06-02 18:38 [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925 Rong Zhang
@ 2026-06-03 17:50 ` patchwork-bot+bluetooth
0 siblings, 0 replies; 2+ messages in thread
From: patchwork-bot+bluetooth @ 2026-06-03 17:50 UTC (permalink / raw)
To: Rong Zhang
Cc: marcel, luiz.dentz, matthias.bgg, angelogioacchino.delregno,
linux-bluetooth, linux-kernel, linux-arm-kernel, linux-mediatek
Hello:
This patch was applied to bluetooth/bluetooth-next.git (master)
by Luiz Augusto von Dentz <luiz.von.dentz@intel•com>:
On Wed, 03 Jun 2026 02:38:10 +0800 you wrote:
> These NICs are often reported to lose their Bluetooth interfaces, i.e,
> their USB interfaces suddenly become completely unresponsive, causing
> the USB core to reset them, only to find that they are no longer
> accessible. A power cycle is required to make the Bluetooth interfaces
> recover.
>
> After some investigations, I found that their USB autosuspend remote
> wakeup capabilities are so broken that they are precisely the culprit
> behind the issue:
>
> [...]
Here is the summary with links:
- Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925
https://git.kernel.org/bluetooth/bluetooth-next/c/247570151789
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2026-06-03 17:50 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-06-02 18:38 [PATCH] Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925 Rong Zhang
2026-06-03 17:50 ` patchwork-bot+bluetooth
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox