From: Rong Zhang Date: Tue, 2 Jun 2026 18:38:10 +0000 (+0800) Subject: Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=e31d761628ad7e96490fc78105ed0a064ec1c1d9;p=thirdparty%2Fkernel%2Flinux.git Bluetooth: btmtk: Disable remote wakeup for MT7922/MT7925 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 Signed-off-by: Luiz Augusto von Dentz --- diff --git a/drivers/bluetooth/btmtk.c b/drivers/bluetooth/btmtk.c index 53cba71cb07f5..d7aa5aded6493 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: