[SRU][R][PATCH 0/1] Bluetooth device (MT7925) not detected on USB bus with linux-oem-6.17

[AceLan Kao]

From: "Chia-Lin Kao (AceLan)" <acelan.kao at canonical.com>

BugLink: https://bugs.launchpad.net/bugs/2145164

[Impact]
MT7925 Bluetooth on Dell systems fails to enumerate at boot when the
BT_RST GPIO is stuck low. The device never comes up and Bluetooth is
unavailable. The only recovery is a full mechanical power-off (G3 cycle).

Error log:
[ 6.813942] usb 3-10: device descriptor read/64, error -110
[ 22.685978] usb 3-10: device descriptor read/64, error -110
[ 28.317963] usb 3-10: device descriptor read/64, error -110
[ 44.189949] usb 3-10: device descriptor read/64, error -110
[ 44.189960] usb usb3-port10: unable to enumerate USB device

Warm reboots and S5 sleep do not clear the stuck GPIO state. Hits 100%
on affected hardware once the GPIO is stuck.

[Fix]
Add usb_acpi_port_prr_reset() to drivers/usb/core/usb-acpi.c. When a
USB port has an ACPI _PRR method, the function calls _RST on the
returned power resource to toggle the hardware reset line.

Wire it into hub_port_connect() during the mid-retry VBUS power-cycle:
call _PRR._RST while VBUS is off so the GPIO pulse completes before the
device gets power. After VBUS comes back on, sleep 100 ms (per USB 2.0
spec §7.1.7.3 Fig. 7-29) when _RST succeeded, because
hub_power_on_good_delay() has no minimum floor and can return as little
as 20 ms on xHCI root hubs.

https://lore.kernel.org/lkml/20260326011708.1128840-1-acelan.kao@canonical.com/T/#u

[Test Plan]
Trigger the stuck-GPIO condition (G3 cycle on affected Dell hardware to
put the system in a normal state, then warm reboot to reproduce).

Without patch:
- dmesg shows repeated "device descriptor read/64, error -110"
- Bluetooth unavailable; recovery requires G3 cycle

With patch:
- dmesg shows "attempt power cycle" followed by successful enumeration
- Bluetooth comes up without any manual intervention

Expected dmesg with patch:
[ 44.294065] usb usb3-port10: attempt power cycle
[ 44.872709] usb 3-10: new high-speed USB device number 6 using xhci_hcd
[ 44.888293] usb 3-10: New USB device found, idVendor=0489, idProduct=e139, bcdDevice= 1.00
[ 44.888318] usb 3-10: Manufacturer: MediaTek Inc.

[Where problems could occur]
Could affect USB hub port handling in drivers/usb/core/hub.c and
usb-acpi.c.

usb_acpi_port_prr_reset() is a no-op on ports with no ACPI _PRR method,
so non-affected hardware should be unaffected. If the ACPI method
evaluation returns an unexpected object type or the _RST call hangs, the
hub_port_connect() retry loop could stall or log spurious errors.

The 100 ms sleep is conditional on _RST succeeding (prr_reset == 0), so
it does not add latency to ports without _PRR.

Chia-Lin Kao (AceLan) (1):
  UBUNTU: SAUCE: USB: hub: call ACPI _PRR reset during port power-cycle
    on enumeration failure

 drivers/usb/core/hub.c      | 14 ++++++++
 drivers/usb/core/usb-acpi.c | 68 +++++++++++++++++++++++++++++++++++++
 drivers/usb/core/usb.h      |  3 ++
 3 files changed, 85 insertions(+)

-- 
2.53.0