Re: ucsi_acpi: PPM init fails at boot but succeeds on manual reload; DP alt mode cannot be entered

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

Hi Ola,

Sorry to keep you waiting. I was on vacation.

On Mon, Oct 05, 2026 at 03:44:03AM -0500, Ola Cewers wrote:
> (Resending as plain text; my previous copy was HTML and the list
> rejected it. Sorry for the duplicate.)
> 
> Hi Heikki,
> 
> Thanks for the reply, and sorry it took me so long to answer. My first
> mail never reached the list (it was rejected as HTML). I resent a
> revised version on 15 Sep as a separate thread ("ThinkPad X1 Carbon
> Gen 14: DP reconnect fails with Type-C ports registered; connector
> reset does not recover"), and the explanation below covers that thread
> too. I missed your reply until today.
> 
> On Tue, Sep 22, 2026 at 12:46:55PM +0200, Heikki Krogerus wrote:
> > UCSI should not have any impact on the actual USB Power Delivery (PD)
> > negotiation which is also used with the alternate modes. UCSI is just
> > a status interface with a minimal level of (optional) control. The
> > actual USB PD negotiation is all handled in the firmware on UCSI
> > systems, the USB PD controller firmware of the Embedded Controller
> > (EC) firmware.
> 
> You were right, and part 2 of my report should be withdrawn. The lost
> display after a replug was not caused by UCSI. It was a regression in
> the compositor backend, aquamarine 0.15.0 (Hyprland), tracked as
> hyprwm/aquamarine#386. When a connector goes away, 0.15.0 never
> disables its CRTC in the kernel. Reports in that issue show that on
> Type-C ports the connector then stays disconnected after a replug.
> That version arrived on this machine on 9 September, in the same
> update as kernel 7.2.3. aquamarine 0.15.1 fixes it here.
> 
> I also need to retract one conclusion in my report. I ruled out the
> compositor because it never saw a connected output. The connector did
> stay disconnected, but the failure started in the compositor, which had
> left the old CRTC enabled.
> 
> > Please confirm this by disabling the UCSI driver completely for
> > example by blacklisting it and then reproducing the issue.
> 
> I have not run the blacklist test yet. The closest result I have is
> from today (kernel 7.2.5-3-omarchy, a distro build; aquamarine 0.15.1).
> PPM init had failed at boot and /sys/class/typec was empty, so the UCSI
> driver was loaded but had registered no ports. In that state I did
> three unplug/replug cycles with the lid open, using both USB-C ports
> and two Dell monitors, each on a direct USB-C cable. The display came
> back every time. So the EC re-enters DP alt mode by itself, as you
> described. I can still run the actual blacklist test if that would be
> useful.

Probable not necessary any more then.

> > Please report the issue to Lenovo in any case,
> 
> That report is fwupd/firmware-lenovo#628. I have added a correction
> there as well:
> https://www.google.com/url?q=https://github.com/fwupd/firmware-lenovo/issues/628%23issuecomment-5990786692&source=gmail&ust=1791276243291000&sa=E

Thanks!

> > The other problem, where the ucsi fails to probe, may be solved
> > already with a workaround where the interface is attempted to be
> > detected multiple times instead of failing immediately.
> 
> That would help here. PPM init still fails on 4 of the 6 boots I have
> had on 7.2.5-3-omarchy, either with -EINVAL after "possible UCSI driver
> bug 2" or with -ENODEV. Could you point me to the patch or the tree it
> is in? I am happy to test it on this machine.

It's this one:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2542613815381e090d5036d5751ab5e2fd9f8b07

Br,

-- 
heikki