Re: [REGRESSION] usb: xhci port capability storage change broke fastboot android bootloader utility

On Tue, 7 Jan 2025 14:29:35 +0200, Mathias Nyman wrote:

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.

That fixed my test case on Debian kernel 6.12.8-amd64, which is among those
that have been failing.

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

That did not fix it. Maybe it's too late once the device is connected and
enumerated?

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)

# cd /sys/kernel/debug/usb/xhci/0000:0c:00.0/
# grep . reg-ext-protocol:*
reg-ext-protocol:00:EXTCAP_REVISION = 0x03200802
reg-ext-protocol:00:EXTCAP_NAME = 0x20425355
reg-ext-protocol:00:EXTCAP_PORTINFO = 0x40000101
reg-ext-protocol:00:EXTCAP_PORTTYPE = 0x00000000
reg-ext-protocol:00:EXTCAP_MANTISSA1 = 0x00050134
reg-ext-protocol:00:EXTCAP_MANTISSA2 = 0x000a4135
reg-ext-protocol:00:EXTCAP_MANTISSA3 = 0x000a4136
reg-ext-protocol:00:EXTCAP_MANTISSA4 = 0x00144137
reg-ext-protocol:01:EXTCAP_REVISION = 0x03100802
reg-ext-protocol:01:EXTCAP_NAME = 0x20425355
reg-ext-protocol:01:EXTCAP_PORTINFO = 0x20000402
reg-ext-protocol:01:EXTCAP_PORTTYPE = 0x00000000
reg-ext-protocol:01:EXTCAP_MANTISSA1 = 0x00050134
reg-ext-protocol:01:EXTCAP_MANTISSA2 = 0x000a4135
reg-ext-protocol:02:EXTCAP_REVISION = 0x02000802
reg-ext-protocol:02:EXTCAP_NAME = 0x20425355
reg-ext-protocol:02:EXTCAP_PORTINFO = 0x00190c06
reg-ext-protocol:02:EXTCAP_PORTTYPE = 0x00000000

# grep EXTCAP_PORTINFO reg-ext-protocol:*
reg-ext-protocol:00:EXTCAP_PORTINFO = 0x40000101
reg-ext-protocol:01:EXTCAP_PORTINFO = 0x20000402
reg-ext-protocol:02:EXTCAP_PORTINFO = 0x00190c06

quoted

quoted

bool(0x40000101 & 1 << 19)

False

quoted

quoted

bool(0x20000402 & 1 << 19)

False

quoted

quoted

bool(0x00190c06 & 1 << 19)

True

Device USB2 LPM capability can be checked from the devices BOS descriptor,
visible (as sudo/root) with lsusb -v -d 0fce:0dde

# lsusb -v -d 0fce:0dde |grep -B 5 LPM
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x00000006
      BESL Link Power Management (LPM) Supported

I think that says the device claims support for LPM, yes?

Maybe relevant: The failing test and lsusb were both run with the device in
fastboot mode, which allows talking to the bootloader. Is it possible that a
device would support LPM in normal operating modes, but not in bootloader
mode, yet present the same capabilities data structure in both modes?