[Bug 221740] 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

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