From: bugzilla-daemon@kernel.org
To: linux-usb@vger.kernel.org
Subject: [Bug 221142] New: ucsi_acpi actively breaks USB-C PD charging on Lenovo Legion Pro 7 (Arrow Lake)
Date: Wed, 25 Feb 2026 23:03:15 +0000 [thread overview]
Message-ID: <bug-221142-208809@https.bugzilla.kernel.org/> (raw)
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: drivers_usb@kernel-bugs.kernel.org
Reporter: alex@alstergee.com
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.
reply other threads:[~2026-02-25 23:03 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-221142-208809@https.bugzilla.kernel.org/ \
--to=bugzilla-daemon@kernel.org \
--cc=linux-usb@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox