[Bug 2146401] Re: MT7925 Bluetooth fails to enumerate on Dell systems, requires G3 cycle to recover

*** This bug is a duplicate of bug 2145164 ***
https://bugs.launchpad.net/bugs/2145164

** This bug has been marked a duplicate of bug 2145164
Bluetooth device (MT7925) not detected on USB bus with linux-oem-6.17

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/2146401

Title:
MT7925 Bluetooth fails to enumerate on Dell systems, requires G3 cycle
to recover

Status in HWE Next:
New
Status in linux package in Ubuntu:
In Progress
Status in linux-oem-6.17 package in Ubuntu:
Invalid
Status in linux source package in Noble:
Invalid
Status in linux-oem-6.17 source package in Noble:
In Progress
Status in linux source package in Questing:
In Progress
Status in linux-oem-6.17 source package in Questing:
Invalid
Status in linux source package in Resolute:
In Progress
Status in linux-oem-6.17 source package in Resolute:
Invalid

Bug description:
[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.

Not yet upstream. Patch submitted for upstream review.

[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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/hwe-next/+bug/2146401/+subscriptions