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

Hi Heikki,

I tested Huang Wei's patch on the affected machine (applied to 7.1.4's
ucsi.c, confirmed active via srcversion): no improvement.

8 boots with the patch: 4x "PPM init failed", 4 ok. That is the same
~50-60% failure rate as the unpatched baseline (5 of 8).

That matches what the error flavors suggest: this doesn't look like a
slow PPM. The -ENODEV case is GET_CAPABILITY completing but reporting
zero connectors, and the -EINVAL case comes with "possible UCSI driver
bug 2", i.e. the PPM rejecting a standard command. These are prompt
wrong answers rather than missing ones, so a longer completion wait
doesn't change the outcome.

One additional data point from this round: all 8 test boots had
nothing attached to any Type-C port, and the failure rate was
unchanged. So it doesn't appear related to PD contract negotiation
racing the handshake either. The PPM simply seems not ready to answer
correctly for a window during boot.

Which still leaves the observation from my original mail: reloading
ucsi_acpi a couple of seconds later has succeeded on every attempt
(well into double digits now), and the machine then behaves fully
normally. Would retrying ucsi_init() a few times on -ENODEV/-EINVAL,
similar to the existing -EPROBE_DEFER requeue, be an acceptable
direction? Happy to test such a patch on this hardware.

- Jacob Riff
Mobile: 760-840-6060

On Wed, Aug 5, 2026 at 5:46 AM Heikki Krogerus
<[email protected]> wrote:
>
> 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/[email protected]/
>
> Thanks,
>
> --
> heikki