Re: [BUG] usb: typec: ucsi: Lenovo ThinkPad E14 Gen 5 AMD reports UCSI version 0

Re: [BUG] usb: typec: ucsi: Lenovo ThinkPad E14 Gen 5 AMD reports UCSI version 0

[Mark Pearson]

On Fri, Nov 13, 2026, at 2:45 PM, Илья Соколов wrote:
> Hello,
>
> I would like to report a UCSI firmware/driver initialization issue on the
> Lenovo ThinkPad E14 Gen 5 AMD.
>
> The issue appears similar to the recently reported UCSI zero-version
> problem on the ThinkPad T14 Gen 2a, for which a workaround was proposed:
>
> https://lore.kernel.org/linux-usb/20261103-ucsi-lenovo-t14g2a-v2-0-e85c659b56a2@resetko.pl/
>
> *System information*
>
>    -
>
>    Device: Lenovo ThinkPad E14 Gen 5 AMD
>    -
>
>    DMI board vendor: LENOVO
>    -
>
>    DMI board name: 21JSS0Y500
>    -
>
>    BIOS: R2CET50W (1.32)
>    -
>
>    CPU: AMD Ryzen 7 7730U
>    -
>
>    OS: Ubuntu 24.04 LTS
>    -
>
>    Kernel: 7.0.0-43-generic
>    -
>
>    Driver: ucsi_acpi
>
> *Problem*
>
> The UCSI ACPI device is detected, but the ucsi_acpi driver fails to bind to
> it.
>
> The device exposes the following ACPI identifiers:
>
> HID: USBC000
> CID: PNP0CA0
> Status: 15
>
> The driver matches the device but initialization fails:
>
> platform USBC000:00: __driver_probe_device:
>     matched device with driver ucsi_acpi
>
> platform USBC000:00: really_probe:
>     probing driver ucsi_acpi with device
>
> ucsi_acpi USBC000:00:
>     probe with driver ucsi_acpi rejects match -19
>
> As a result, /sys/class/typec/ remains empty.
>
> I used the kernel function graph tracer to investigate the failure. The
> relevant results were:
>
> ucsi_acpi_dsm()          ret=0
> ucsi_acpi_read_version() ret=0
> ucsi_register()          ret=-19
> ucsi_acpi_probe()        ret=-19
>
> This suggests that the firmware returns UCSI VERSION = 0, causing
> ucsi_register() to return -ENODEV.
>
> *Experimental workaround*
>
> I built a modified ucsi_acpi module using the source corresponding to
> Ubuntu kernel 7.0.0-43.
>
> I added a DMI entry matching:
>
> DMI_BOARD_VENDOR = "LENOVO"
> DMI_BOARD_NAME   = "21JSS0Y500"
>
> The entry reuses the existing ucsi_acer_ops, which assumes UCSI 1.2 when
> the firmware reports a zero version.
>
> After loading the modified module, the kernel reported:
>
> ucsi_acpi USBC000:00:
>     UCSI version is zero, assuming 1.2
>
> typec port0: bound usb1-port1
> typec port0: bound usb2-port1
>
> The driver successfully bound to USBC000:00, and /sys/class/typec/port0
> appeared.
>
> Connecting a USB-C device also created:
>
> port0-cable
> port0-partner
>
> This confirms that the zero-version workaround allows the UCSI controller
> to register successfully.
>
> However, only one logical UCSI port was registered, although the laptop has
> two physical USB-C connectors.
>
> *DisplayPort issue*
>
> I initially investigated this because native USB-C-to-DisplayPort output
> does not work on this ThinkPad.
>
> The AMDGPU driver repeatedly reports:
>
> DP AUX transfer fail:3
>
> AMDGPU DM aux hw bus 3:
>     Too many retries, giving up.
>     First error: -110
>
> wake_up_aux_channel: Failed to power up sink
>
> Both USB-C ports work with an active USB-C-to-HDMI adapter.
>
> The USB-C-to-DisplayPort cable and monitor work correctly at 2560x1440@200Hz
> on another AMD laptop under both Windows 10 and Fedora Linux.
>
> Unfortunately, the UCSI zero-version workaround does not resolve the
> DisplayPort problem on the E14 Gen 5.
>
> With the modified driver, UCSI detects the cable and partner, but the
> monitor remains disconnected. The kernel also occasionally reports:
>
> ucsi_acpi USBC000:00:
>     GET_CURRENT_CAM command failed
>
> Neither the working USB-C-to-HDMI adapter nor the native DisplayPort cable
> exposes registered alternate modes through the UCSI sysfs interface.
>
> Therefore, I cannot confirm that the two issues are directly related.
>
> *Questions*
>
>    1.
>
>    Would extending the existing UCSI zero-version DMI quirk to the ThinkPad
>    E14 Gen 5 AMD be appropriate?

This platform wasn't in the Linux program so chances of me getting the FW team to fix this are pretty close to zero. I've created internal ticket LO-4776 to ask them - you never know. 
So yeah, it might be a good candidate for a patch, though as you have other issues I'm not convinced it's a great idea. I can't confirm or test if there are any issues with it as I don't have the HW I'm afraid - especially as it doesn't actually solve your issue.

>    2.
>
>    Is there any additional testing needed to verify that assuming UCSI 1.2
>    is safe for this platform?

Bit worried it only shows 1 connector and the CAM command failure....but that might be buried in the mysteries of the PD controller unfortunately.

>    3.
>
>    Could the failure to initialize UCSI be related to the native
>    DisplayPort AUX timeouts, even though registering the UCSI controller does
>    not resolve them?
>
My guess is not and it's somethng else. Have you tried a ticket on the AMD DRM forums? https://gitlab.freedesktop.org/drm/amd
You can also post something on forums.lenovo.com/linux - but less likely to get an expert comment there I'm afraid.

Mark