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

[Yufeng Gao]

On 8/4/26 10:28, AceLan Kao wrote:
> 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(+)
>
Acked-by: Yufeng Gao <yufeng.gao at canonical.com>