public inbox for linux-usb@vger.kernel.org
 help / color / mirror / Atom feed
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