Re: ucsi_acpi: intermittent "PPM init failed" at boot is never retried, Type-C event handling stays dead for the session

[Heikki Krogerus <heikki.krogerus@linux.intel.com>]

On Sat, Jul 25, 2026 at 02:31:53PM -0700, Jacob Riff wrote:
> Hi,
> 
> On a Lenovo ThinkPad X1 Carbon Gen 14 (21V7CTO1WW, Panther Lake), UCSI
> initialization intermittently fails at boot, and because the failure is
> never retried, no typec ports are registered for the rest of the
> session. Most visible consequence: after unplugging and replugging the
> USB-C charger (a PD monitor), the machine silently never resumes
> charging. Notably, DisplayPort alt mode on the same port continues to
> work across replugs in this state, and charging does work if the
> charger was already attached at boot (EC autonomous) - it is
> specifically resumption of charging after a replug that is lost, which
> makes the failure easy to miss until the battery is unexpectedly
> drained.
> 
> Failure rate: 5 of 8 boots on one day of testing. Reproduced on two
> firmware versions including the latest (BIOS N4OET49W/1.12 and
> N4OET51W/1.14, EC 1.09 and 1.10). No clear correlation with whether
> anything is attached at boot: two boots one minute apart with the same
> setup split ok/fail.
> 
> Kernel: 7.1.4 (Arch Linux, unpatched in this area)
> 
> Two failure flavors seen:
> 
>   ucsi_acpi USBC000:00: error -ENODEV: PPM init failed
> 
> and:
> 
>   ucsi_acpi USBC000:00: possible UCSI driver bug 2
>   ucsi_acpi USBC000:00: error -EINVAL: PPM init failed
> 
> Both appear ~1s after the typec ports bind. On failed boots
> /sys/class/typec/ stays empty.
> 
> The part that suggests a driver-side improvement: recovery is trivial.
> Reloading the module seconds later has succeeded on every attempt so
> far (double digits by now):
> 
>   modprobe -r ucsi_acpi && sleep 2 && modprobe ucsi_acpi
> 
> after which connectors register and charging renegotiates immediately,
> no replug needed.
> 
> ucsi_init_work() currently only requeues the init work for
> -EPROBE_DEFER (up to UCSI_ROLE_SWITCH_WAIT_COUNT). Given that an
> immediate retry reliably succeeds here, would it be reasonable to also
> retry a few times on other errors (-ENODEV/-EINVAL) before giving up?
> The PPM on these machines appears to simply not be ready to answer
> during a window around when init runs.
> 
> Possibly related prior reports of Lenovo PPMs being slow/unready at
> init: the "usb: typec: ucsi: increase timeout for PPM reset operations"
> RFC (Feb 2025) and Ubuntu bug #2054928 (ThinkPad E490, -ENODEV).
> 
> Happy to test patches on this hardware.

I'm sorry to keep you waiting. I'm just letting you know that this
issue is in my queue, but right now I don't have time. I will try
to take a closer look at this later this month.

Thanks,

-- 
heikki