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

Public bug reported:

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

** Affects: hwe-next
Importance: Undecided
Status: New

** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: Invalid

** Affects: linux (Ubuntu Noble)
Importance: Undecided
Status: Invalid

** Affects: linux-oem-6.17 (Ubuntu Noble)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux (Ubuntu Questing)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.17 (Ubuntu Questing)
Importance: Undecided
Status: Invalid

** Affects: linux (Ubuntu Resolute)
Importance: Undecided
Assignee: AceLan Kao (acelankao)
Status: In Progress

** Affects: linux-oem-6.17 (Ubuntu Resolute)
Importance: Undecided
Status: Invalid


** Tags: jira-somerville-4265 oem-priority somerville

** Also affects: linux-oem-6.17 (Ubuntu)
Importance: Undecided
Status: New

** Tags added: jira-somerville-4265 oem-priority somerville

** Also affects: linux (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Questing)
Importance: Undecided
Status: New

** Also affects: linux (Ubuntu Resolute)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Resolute)
Importance: Undecided
Status: New

** Also affects: linux (Ubuntu Noble)
Importance: Undecided
Status: New

** Also affects: linux-oem-6.17 (Ubuntu Noble)
Importance: Undecided
Status: New

** Changed in: linux (Ubuntu Noble)
Status: New => Invalid

** Changed in: linux (Ubuntu Questing)
Status: New => In Progress

** Changed in: linux (Ubuntu Resolute)
Status: New => In Progress

** Changed in: linux-oem-6.17 (Ubuntu Noble)
Status: New => In Progress

** Changed in: linux-oem-6.17 (Ubuntu Questing)
Status: New => Invalid

** Changed in: linux (Ubuntu Questing)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux-oem-6.17 (Ubuntu Resolute)
Status: New => Invalid

** Changed in: linux (Ubuntu Resolute)
Assignee: (unassigned) => AceLan Kao (acelankao)

** Changed in: linux-oem-6.17 (Ubuntu Noble)
Assignee: (unassigned) => AceLan Kao (acelankao)

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