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 Wed, Aug 05, 2026 at 02:11:43PM +0200, Heikki Krogerus wrote:
> 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.

Can you check does this improve the situation:
https://lore.kernel.org/linux-usb/20260805085725.389761-1-huangwei@kylinos.cn/

Thanks,

-- 
heikki