All of lore.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.