New: ucsi_acpi PPM init failed (-ETIMEDOUT) on ThinkPad E14 Gen 7 (AMD) — blocks USB-C dock enumeration

https://bugzilla.kernel.org/show_bug.cgi?id=221740

Bug ID: 221740
Summary: ucsi_acpi PPM init failed (-ETIMEDOUT) on ThinkPad E14
Gen 7 (AMD) — blocks USB-C dock enumeration
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status: NEW
Severity: blocking
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

Description, include:

journalctl line: ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed usb_power_delivery_revision: 0.0 (confirms PD negotiation never completes)
DMI: LENOVO 21T0CTO1WW, BIOS R2ZET34W (1.23), model ThinkPad E14 Gen 7 Kernels tested and both affected: 6.19.10-300.fc44 and 7.1.3-200.fc44 Note it works correctly on Windows with the same hardware/dock/cable Attach the relevant dmesg enumeration failure log (the "device descriptor read/64, error -71" sequence)

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221740

Wei Huang ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Wei Huang ([email protected]) --- Created attachment 310566
--> https://bugzilla.kernel.org/attachment.cgi?id=310566&action=edit
0001-usb-typec-ucsi-use-UCSI_TIMEOUT_MS-for-sync-command-.patch

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221740

--- Comment #2 from Wei Huang ([email protected]) --- Hi Shofiq,

Thanks for the detailed report, and for noting that it works on Windows — that's a useful data point ruling out the dock/cable/hardware.

I've been looking into this and I believe the UCSI driver's command completion timeout is too short on machines where the EC is slow during boot. I've prepared a patch, submitted it upstream [1], and would appreciate your help testing it.

[1]
https://lore.kernel.org/linux-usb/[email protected]/

== What I've found ==

The UCSI driver has two paths to talk to the platform firmware (PPM):

1. ucsi_reset_ppm() — polls, 10-second timeout
2. ucsi_sync_control_common() — waits for an ACPI notification,
currently hardcoded to 5 seconds

A previous fix [2] raised path (1) from 5s to 10s, but path (2) was left at 5 seconds. Since your log shows "PPM init failed" WITHOUT "failed to reset PPM!", the reset itself likely succeeded — the timeout is hitting a command sent right after it (e.g. SET_NOTIFICATION_ENABLE, GET_CAPABILITY). That's exactly path (2).

Once UCSI init aborts, USB-C PD negotiation never completes (usb_power_delivery_revision: 0.0), which blocks dock enumeration since the dock depends on a PD contract. This matches the symptoms you described.

The patch replaces the hardcoded 5-second timeout in path (2) with msecs_to_jiffies(UCSI_TIMEOUT_MS), so both paths use the same 10-second value.

[2] commit bf4f9ae1cb08c ("usb: typec: ucsi: increase timeout for PPM reset operations")

== Before testing — a quick check ==

To confirm the diagnosis, could you run and paste the output of:

sudo dmesg | grep -i ucsi

I'd like to verify that there is NO "failed to reset PPM!" line, and that "PPM init failed" is the only ucsi error. (If "failed to reset PPM!" IS present, the fix is different and I'll adjust.)

== How to test ==

The raw patch is available at the lore link [1] above. The simplest way on Fedora is to apply it against a matching kernel source tree and rebuild just the typec_ucsi module:

    # prerequisites
    sudo dnf install kernel-devel-$(uname -r) kernel-headers gcc make

    # get source matching your kernel
    sudo dnf download --source kernel
    rpm2cpio kernel-*.src.rpm | cpio -idmv
    tar xf linux-*.tar.xz && cd linux-*/
    patch -p1 < /path/to/the-patch-from-lore

    # build only the affected module
    cp /lib/modules/$(uname -r)/build/.config .config
    make olddefconfig
    make M=drivers/usb/typec/ucsi modules

    # install and reload
    sudo cp drivers/usb/typec/ucsi/typec_ucsi.ko \
         /lib/modules/$(uname -r)/extra/
    sudo depmod -a
    sudo modprobe -r typec_ucsi && sudo modprobe typec_ucsi
    # or simply reboot

== What to report back ==

1. The dmesg | grep -i ucsi output after applying the patch.
2. Whether the USB-C dock enumerates (dmesg should show the USB devices).
3. These values after connecting the dock:

cat /sys/class/typec/port0/power_role
cat /sys/class/typec/port0/usb_power_delivery_revision

If 10 seconds is still not enough, please also run:

sudo acpidbg -b "examine USBC000:00"

so I can investigate whether the ACPI/EC notification path itself is broken (in which case no timeout increase will help, and we'd need a different fix).

(I've also attached the patch directly to this bug for convenience.)

Thank you!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221740

--- Comment #3 from Wei Huang ([email protected]) --- Hi Shofiq,

Good news - the patch discussed above has been accepted upstream.

It was reviewed by the USB Type-C subsystem maintainer (Heikki Krogerus) and merged into the mainline kernel during the 7.3 merge window:

usb: typec: ucsi: use UCSI_TIMEOUT_MS for sync command completion

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=eb4573cf2fd8

What this means for you:

- The fix is included in v7.3-rc1 and will be part of the final 7.3 release.
- The patch is also queued for backport to the supported stable series (it carries a Cc: stable tag), so it should reach distribution kernels in due course.

Once you get a chance to run a 7.3-rc1 or newer kernel (or a stable release containing the backport) with your dock, it would be great if you could confirm that UCSI initializes and the dock enumerates correctly. If everything works, this bug can be closed as RESOLVED CODE_FIX.

Thanks again for the thorough report - it made diagnosing this much easier.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.