On 6.1.2025 1.42, Forest wrote:
On Thu, 2 Jan 2025 16:13:34 +0200, Mathias Nyman wrote:
It's not clear to me why this patch would cause regression.
Could you enable xhci and usb core dynamic debug before connecting the
device, and then share dmesg after the issue is triggered.
dmesg of a working case would also be good to have for comparison.
I booted kernel 9b780c845fb6 (the last good one), logged in to my desktop,
waited a couple of minutes to let things settle, and then ran 'fastboot
getvar kernel' twice with the android device in bootloader mode.
Here's the dmesg output:
Thanks for the logs.
Looks like we enable USB2 Link Power Management (LPM) in the failing case
[ 226.002756] xhci_hcd 0000:0c:00.0: enable port 3 USB2 hardware LPM
[ 226.002765] xhci_hcd 0000:0c:00.0: Set up evaluate context for LPM MEL change.
Does disabling USB2 hardware LPM for the device make it work again?
Adding USB_QUIRK_NO_LPM quirk "k" for your device vid:pid should do it.
i.e. add "usbcore.quirks=0fce:0dde:k" parameter to your kernel cmdline.
Or alternatively disable usb2 lpm during runtime via sysfs
(after enumeration, assuming device is "1-3" as in the log):
# echo 0 > /sys/bus/usb/devices/1-3/power/usb2_hardware_lpm
If those work then we need to figure out if we incorrectly try to enable
USB2 hardware LPM, or if device just can't handle LPM even if it claims
to be LPM capable.
Host hardware LPM capability can be checked from xhci reg-ext-protocol
fields from debugfs.
cat /sys/kernel/debug/usb/xhci/0000:0c:00.0/reg-ext-protocol:*
(please print content of _all_ reg_ext_protocol* files, LPM capability is
bit 19 of EXTCAP_PORTINFO)
Device USB2 LPM capability can be checked from the devices BOS descriptor,
visible (as sudo/root) with lsusb -v -d 0fce:0dde
Thanks
Mathias
