New: ucsi_acpi actively breaks USB-C PD charging on Lenovo Legion Pro 7 (Arrow Lake)

https://bugzilla.kernel.org/show_bug.cgi?id=221142

Bug ID: 221142
Summary: ucsi_acpi actively breaks USB-C PD charging on Lenovo
Legion Pro 7 (Arrow Lake)
Product: Drivers
Version: 2.5
Hardware: Intel
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

The ucsi_acpi driver actively interferes with USB-C Power Delivery negotiation on the Lenovo Legion Pro 7 16IAX10H (83F5, Intel Arrow Lake, BIOS Q7CN44WW). Blacklisting ucsi_acpi completely fixes the issue — the EC's PD controller negotiates correctly on its own.

SYSTEM:
- Lenovo Legion Pro 7 16IAX10H (product ID 83F5)
- Intel Core Ultra 9 275HX (Arrow Lake)
- BIOS Q7CN44WW (Nov 2025, latest available)
- Kernel 6.18.0

SYMPTOMS WITH ucsi_acpi LOADED:
- USB-C PD chargers connect briefly then drop after 1-3 minutes
- voltage_now always reads 0 in /sys/class/power_supply/ucsi-source-psy-*/
- usb_power_delivery_revision on partner reports 0.0 (should be 3.0)
- No source-capabilities PDO objects ever appear in sysfs
- GET_PDOS appears to return empty data from the EC
- GET_CONNECTOR_STATUS returns incomplete RDO
- Some chargers never establish a PD contract at all (Shargeek 100W: only 1.4W)
- Failed PD negotiations wedge the UCSI PPM — requires full reboot to recover
- ACPI workqueue warnings: "acpi_os_execute_deferred hogged CPU for >10000us"

RESULTS WITH ucsi_acpi BLACKLISTED:
- Shargeek 100W: 1.4W → 40-55W (full PD negotiation at proper voltage)
- Anker 65W: 5W → expected full power
- Barrel jack 330W: unaffected (70W, bypasses USB-C)

The EC's PD controller handles negotiation correctly without OS involvement. The ucsi_acpi driver queries the broken UCSI mailbox and interferes with what would otherwise be a working PD contract.

This is the same class of Lenovo EC firmware bug as:
- ThinkPad T14 Gen 5: https://github.com/fwupd/firmware-lenovo/issues/521
(Lenovo internal ticket LO-4169 — EC returns static/dummy RDO)
- Framework Laptop 16: PDOs read as 0x00000000 despite successful PD negotiation

RELATED KERNEL PATCHES:
- Benson Leung, Dec 2025: Fix voltage_now/current_now for non-PD sources
https://lkml.org/lkml/2025/12/8/912
- Benson Leung, Dec 2025: Fix voltage/current max for non-Fixed PDOs
https://lkml.org/lkml/2025/12/8/913 (commit 6811e0a08bdc) (These fix reporting but don't address the EC returning empty PDO data)

PROPOSED FIX:
The kernel could add a quirk for Lenovo platforms where the UCSI PPM is known to return broken PDO data, either:
1. Skip GET_PDOS calls on affected platforms (let EC handle PD autonomously)
2. Add a module parameter to make ucsi_acpi passive/read-only
3. Detect empty GET_PDOS responses and back off instead of interfering

WORKAROUND:
echo "blacklist ucsi_acpi" > /etc/modprobe.d/blacklist-ucsi.conf

STEPS TO REPRODUCE:
1. Boot Lenovo Legion Pro 7 16IAX10H with kernel 6.18
2. Plug in any USB-C PD charger
3. Observe charging starts briefly then drops (BAT0/status → Discharging)
4. Check /sys/class/power_supply/ucsi-source-psy-*/voltage_now → always 0
5. Blacklist ucsi_acpi, reboot, plug charger → charges at full PD power

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221142

Wei Huang ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Wei Huang ([email protected]) --- Hi Alstergee,

Thanks for the detailed report, and for verifying that blacklisting ucsi_acpi restores normal PD negotiation on this machine.

The cleanest way forward is a DMI quirk for this model in drivers/usb/typec/ucsi/ucsi_acpi.c - there is already a quirk mechanism there, used for a similar EC firmware problem on LG gram laptops. To write the quirk, I need the exact DMI identification strings of the machine, which are not part of the report.

Could you please attach the output of:

sudo dmidecode -t system

Alternatively, the contents of these files:

/sys/class/dmi/id/sys_vendor
/sys/class/dmi/id/product_name
/sys/class/dmi/id/product_version
/sys/class/dmi/id/product_family
/sys/class/dmi/id/product_sku
/sys/class/dmi/id/board_name
/sys/class/dmi/id/board_version

With that information I can prepare a patch and submit it upstream.

Thanks!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221142

--- Comment #2 from Alstergee ([email protected]) --- Hi Wei,

Thanks for picking this up! Here's the DMI information:

sudo dmidecode -t system:

Handle 0x0001, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 83F5
Version: Legion Pro 7 16IAX10H
Serial Number: <redacted>
UUID: <redacted>
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_83F5_BU_idea_FM_Legion Pro 7 16IAX10H
Family: Legion Pro 7 16IAX10H

Contents of the requested /sys/class/dmi/id/ files:

    sys_vendor       = LENOVO
    product_name     = 83F5
    product_version  = Legion Pro 7 16IAX10H
    product_family   = Legion Pro 7 16IAX10H
    product_sku      = LENOVO_MT_83F5_BU_idea_FM_Legion Pro 7 16IAX10H
    board_name       = LNVNB161216
    board_version    = SDK0T76461 WIN

Additional context that may be useful for matching:

    bios_vendor      = LENOVO
    bios_version     = Q7CN78WW
    bios_date        = 04/07/2026
    board_vendor     = LENOVO
    chassis_vendor   = LENOVO
    chassis_type     = 10  (Notebook)

The BIOS has been updated since I filed the report (Q7CN44WW -> Q7CN78WW, April 2026). Symptoms are unchanged — ucsi_acpi still returns empty PDO data and interferes with EC-side PD negotiation; blacklisting ucsi_acpi still fully restores charging.

Also worth noting: the AMD variant of this laptop is DMI product 83RU (Legion Pro 7 16AFR10H, BIOS prefix SMCN). It uses the same EC firmware (ITE IT5508, EC ID 0x5508) and the community reports the same PD negotiation failure there. It might be worth matching both product names in the quirk if that's how the LG gram quirk is structured.

Currently running Ubuntu 26.04.1 LTS, kernel 7.0.0-30-generic.

Thanks,

Alex Bartz
eleso.app
FestivalWiFiGuys.com
Alstergee.com
[image: mobilePhone] +1 (801) 808-1498 <+1%20(801)%20808-1498> [image: emailAddress] [email protected] <[email protected]>

CONFIDENTIAL & PRIVILEGED: This communication and any attachments may contain information that is confidential, privileged, and/or exempt
from disclosure under applicable law. If you are not the intended
recipient, any review, use, dissemination, distribution, or copying is
strictly prohibited. If you received this in error, please notify the
sender immediately and permanently delete all copies.

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=221142

--- Comment #3 from Wei Huang ([email protected]) --- Hi Alstergee,

Thanks for the detailed DMI info - and for the note about the AMD sibling (83RU). I've kept the quirk to 83F5 for now, since the failure is only confirmed on your model; 83RU can be added once someone confirms it there.

A patch has been submitted to the linux-usb mailing list:

usb: typec: ucsi: do not register UCSI on Lenovo Legion Pro 7 16IAX10H

https://lore.kernel.org/linux-usb/[email protected]/

It adds a DMI quirk that makes ucsi_acpi skip binding on this model, which is functionally the same as the blacklist workaround you already verified - the module can stay loaded, but it will not touch the EC's UCSI mailbox.

If you have a chance to test it (build a kernel with the patch applied, make sure ucsi_acpi is no longer blacklisted, and reboot), the confirmation I'd need is:

- a dmesg line like:
ucsi_acpi USBC000:00: UCSI implementation in firmware is broken,
ignoring
- normal PD charging restored (voltage_now non-zero, chargers hold).

If that works, it would help to have a formal Tested-by tag from you, which lets the subsystem maintainer pick the fix up directly. Just reply with:

Thanks again for the quick and thorough help!

You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.