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

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

[Jacob Riff]

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.

Thanks,
Jacob Riff

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

[Heikki Krogerus]

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

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

[Heikki Krogerus]

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

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

[Jacob Riff]

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
<heikki.krogerus@linux.intel.com> 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/20260805085725.389761-1-huangwei@kylinos.cn/
>
> Thanks,
>
> --
> heikki