New: HP OmniBook X Flip - Broken UCSI firmware / Slow charging

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

            Bug ID: 221776
           Summary: HP OmniBook X Flip - Broken UCSI firmware / Slow
                    charging
           Product: Drivers
           Version: 2.5
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: USB
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

The HP OmniBook X Flip has a non-compliant UCSI firmware in its Embedded Controller. The EC accepts only read-only UCSI commands (GET_VERSION, GET_CONNECTOR_STATUS) but rejects all control/write commands (SET_NOTIFICATION_ENABLE, PPM_RESET, CONNECTOR_RESET, and any _DSM WRITE function calls).

When the ucsi_acpi driver loads and attempts to use UCSI for USB PD negotiation, the EC state eventually becomes corrupted. This causes USB PD to drop from 20V (65W) to 5V (~2W to battery), severely limiting charging speed.

The corruption persists across reboots and even warm reboots. Only a full EC reset (shutdown + unplug + 30s power drain + replug) restores normal PD negotiation.

WORKAROUND:
Blacklist ucsi_acpi (module_blacklist=ucsi_acpi on kernel cmdline). Without UCSI, Linux doesn't talk to the broken EC firmware, the charger negotiates PD directly, and charging works at 25-30W (expected "normal speed" with system running).

REPRODUCE:
1. Boot with ucsi_acpi loaded (default)
2. Plug in the 65W USB-C PD charger
3. Wait 30-60 seconds
4. Observe charging current drop from ~25W to ~2W via /sys/class/power_supply/BAT0/power_now
5. After that, pd voltage locked at 5V (visible via /sys/class/typec/port0/pd_data)

ROOT CAUSE:
The EC UCSI firmware at ACPI path PNP0CA0 implements the _DSM (UCSI DSM UUID: 6f8398c2-7ca4-11e4-ad36-631042b5008f) but returns error for function 1 (WRITE). The ucsi_acpi driver's ucsi_acpi_async_control() calls _DSM WRITE to send UCSI commands to the EC mailbox, but these writes either fail or silently corrupt the EC's internal state.

DIAGNOSTIC EVIDENCE:
- acpi_call test: _DSM function 1 (WRITE) fails with error
- UCSI debugfs GET_CONNECTOR_STATUS succeeds
- UCSI debugfs PPM_RESET/CONNECTOR_RESET returns EOPNOTSUPP
- After ucsi_acpi loads, /sys/class/typec/port0/power_role shows "sink" even though charger is capable of sourcing
- After corruption, /sys/kernel/debug/usb/ucsi/*/status shows PD contract at 5V/3A instead of 20V/3.25A
- Blacklisting ucsi_acpi + EC reset restores proper PD negotiation

PROPOSED FIX:
Add DMI quirk to ucsi_acpi.c to skip the driver on this hardware:

@@ -79,6 +79,17 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
                        DMI_MATCH(DMI_PRODUCT_NAME, "90Q"),
                },
                .driver_data = (void *)&ucsi_gram_ops,
+       },
+       {
+               /*
+                * HP OmniBook X Flip has broken UCSI firmware that rejects all
+                * control commands (SET_NOTIFICATION_ENABLE, PPM_RESET, etc.).
+                * Skip UCSI to avoid corrupting EC state and losing PD

negotiation.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP OmniBook X Flip Laptop
16-ar0xxx"),
+ },

        },
        { }
 };
@@ -213,6 +224,11 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
        ua->dev = &pdev->dev;

        id = dmi_first_match(ucsi_acpi_quirks);

+ if (id && !id->driver_data) {
+ dev_info(&pdev->dev, "broken UCSI firmware, skipping
driver\n");
+ return -ENODEV;
+ }

        if (id)
                ops = id->driver_data;

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=221776

--- Comment #1 from David Del Sol ([email protected]) ---
From: David <david@david-desktop>
Date: Tue, 21 Jul 2026 11:30:00 -0500
Subject: [PATCH] usb: typec: ucsi: Skip UCSI on HP OmniBook X Flip (broken EC firmware)

The HP OmniBook X Flip (Ryzen AI 5 340) has a non-compliant UCSI firmware in the embedded controller. The EC rejects all write/control UCSI commands (SET_NOTIFICATION_ENABLE, PPM_RESET, etc.) while accepting only read-only commands (GET_*). This causes the UCSI subsystem to eventually corrupt the EC state, resulting in USB PD negotiation falling back to 5V (only ~2W charging instead of 65W).

Add a DMI-based quirk to prevent the ucsi_acpi driver from binding to this hardware. Use NULL driver_data to signal "broken firmware, skip UCSI entirely".

The user-visible symptom is that with a 65W USB-C PD charger, the battery charges at 2W instead of 25-30W after the first UCSI command exchange. The workaround (removing this driver) has been verified on multiple charge cycles.

---

b/drivers/usb/typec/ucsi/ucsi_acpi.c
index 5b7d00907e39..c9bdeb110974 100644

@@ -79,6 +79,17 @@ static const struct dmi_system_id ucsi_acpi_quirks[] = {
                        DMI_MATCH(DMI_PRODUCT_NAME, "90Q"),
                },
                .driver_data = (void *)&ucsi_gram_ops,
+       },
+       {
+               /*
+                * HP OmniBook X Flip has broken UCSI firmware that rejects all
+                * control commands (SET_NOTIFICATION_ENABLE, PPM_RESET, etc.).
+                * Skip UCSI to avoid corrupting EC state and losing PD

negotiation.
+ */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "HP OmniBook X Flip Laptop
16-ar0xxx"),
+ },

        },
        { }
 };
@@ -213,6 +224,11 @@ static int ucsi_acpi_probe(struct platform_device *pdev)
        ua->dev = &pdev->dev;

        id = dmi_first_match(ucsi_acpi_quirks);

+ if (id && !id->driver_data) {
+ dev_info(&pdev->dev, "broken UCSI firmware, skipping
driver\n");
+ return -ENODEV;
+ }

        if (id)
                ops = id->driver_data;

You may reply to this email to add a comment.

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

Please send this to the linux-usb mailing list, with a proper name, and we will be glad to review it there.

thanks,

greg k-h

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

--- Comment #2 from Greg Kroah-Hartman ([email protected]) ---

Please send this to the linux-usb mailing list, with a proper name, and we will be glad to review it there.

thanks,

greg k-h

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=221776

--- Comment #3 from David Del Sol ([email protected]) --- Updating this report with the verified root cause, found since the original filing.

The slow-charging issue is NOT UCSI firmware corruption. Root cause: the EC only enables normal charging when the OS claims _OSI("Windows 2022"). Verified:
- DSDT/SSDT (via strings on /sys/firmware/acpi/tables/*) contain OSI checks only up to "Windows 2022"; the kernel's default claimed OSI strings stop before that.
- Adding acpi_osi=! acpi_osi="Windows 2022" to the kernel cmdline restores 31-33 W charging immediately, reproducibly, on kernels 7.1.6 and 6.18.42-LTS, across multiple charge cycles (currently 27.8 W, battery 79%).
- This works with ucsi_acpi loaded -- the driver does not need to be blacklisted, so the proposed ucsi_acpi.c DMI quirk in Comment 1 is unnecessary and is withdrawn.

Per Greg's note: the correct upstream fix is a DMI-scoped OSI quirk in drivers/acpi/osi.c (linux-acpi mailing list). Filed as a new report with full evidence and EC RAM attachments:
https://bugzilla.kernel.org/show_bug.cgi?id=221866

Separate, intermittent issue (still open, tracked in 221866): on ~1 in 4 plug/unplug events the 65 W charger's PD contract occasionally sticks at 5 V / 3 A (~0.2 W to battery) until reboot. UCSI driver reload and suspend/resume did not recover it. Not reproduced in later cycles; appears to be a PD renegotiation race.

Closing this bug as resolved-by-workaround: acpi_osi=! acpi_osi="Windows 2022" on the kernel command line.

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=221776

David Del Sol ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
         Resolution|---                         |ANSWERED
            Summary|HP OmniBook X Flip - Broken |HP OmniBook X Flip - Slow
                   |UCSI firmware / Slow        |charging root cause: EC
                   |charging                    |gates charging on
                   |                            |_OSI("Windows 2022")

You may reply to this email to add a comment.

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