New: ucsi_acpi PPM_RESET timeout on ASUS Zenbook UX425UA/UM425UA (AMD Renoir) - not fixed by poll_cci or timeout increase, tested extensively

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

Bug ID: 221977
Summary: ucsi_acpi PPM_RESET timeout on ASUS Zenbook
UX425UA/UM425UA (AMD Renoir) - not fixed by poll_cci or timeout increase, tested extensively
Product: Drivers
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: USB
Assignee: [email protected]
Reporter: [email protected]
Regression: No

SYSTEM
------
ASUS Zenbook 14 UX425UA/UM425UA, AMD Ryzen 7 5700U (Renoir), BIOS UX425UA.301 (2021, latest available). Ubuntu 24.04, kernel 6.8.0-124-generic. Dual-boot with Windows 10 (works correctly there, see below).

ERROR
-----
Every boot, and every subsequent module reload:

ucsi_acpi USBC000:00: error -ETIMEDOUT: PPM init failed

/sys/class/typec/ never populates. USB-C charging itself works fine (confirmed via direct wattage logging) - this only affects PD telemetry, alt-mode, and role-switching.

WHAT I'VE ALREADY TESTED (all negative)
----------------------------------------
1. Timeout increase: built a signed DKMS module with UCSI_TIMEOUT_MS patched 5000 -> 30000 (6x default, 3x the merged 10000 fix). Confirmed via source inspection that -ETIMEDOUT is only ever set after the real elapsed-time check in ucsi_reset_ppm() fires, so this is a genuine 30-second wait, not an early bail-out. Still times out identically.

2. Polling frequency, isolated as its own variable: same 30s budget, but msleep(20) -> msleep(200) in the ucsi_reset_ppm() loop (~150 EC/_DSM hits instead of ~1500), to test whether rapid _DSM/EC-mutex polling itself was the blocker rather than total patience. Still times out identically.

3. Current mainline behavior: diffed 6.8's ucsi.c/ucsi_acpi.c against current master. The poll_cci() rewrite (976e7e9bdc77) and timeout increase (bf4f9ae1cb08) are both present there. For the ACPI backend specifically, ucsi_acpi_poll_cci() still forces a _DSM read on every call during PPM_RESET - functionally identical to what I already tested in #1. So current mainline would not behave differently here.

4. The old ASUS Zenbook quirk (ucsi_zenbook_ops, for the near-identical "UX325UA_UM325UA" model): checked in source - during PPM_RESET specifically, the quirked and generic read paths are identical (both force _DSM every read), so this was never going to apply regardless of the DMI mismatch. (Also since removed upstream, folded into the poll_cci rewrite.)

5. Boot path: tested booting via two different methods into the OS, in case boot-manager timing mattered. No difference.

6. Device presence: tested with the charger completely unplugged from WINDOWS COMPARISON
-------------------
Booting the same machine into Windows 10, Device Manager shows the identical \_SB.UBTC ACPI object (confirmed via DEVPKEY_Device_ BiosDeviceName) healthy, ProblemCode 0, using Microsoft's generic in-box UcmUcsiAcpiClient.sys (not an OEM driver). I compared its public reference sample source (microsoft/Windows-driver-samples, UcmUcsiAcpiSample) against ucsi_acpi.c's low-level read/write code - both call _DSM before every register access, in the same order. No structural difference found at that layer. The actual retry/ completion logic that must differ lives in the closed-source UcmUcsiCx.sys class extension, which I have no visibility into.

RELATED
-------
This looks like the same class of failure as Bug 219590, where the reporting maintainer's own affected laptop was also not fixed by either of the two 2025 patches ("in my case it unfortunately didn't help" - comment #9). Reporting this as what looks like a second, independently-confirmed case of the same "not fixed by known fixes" outcome, with a slightly wider set of variables tested (specifically the polling-frequency isolation in #2, which I haven't seen tested elsewhere).

Happy to run further diagnostics if anyone has a specific next test in mind - I've documented the exact ACPI tables and mechanism (_DSM UUID 6f8398c2-7ca4-11e4-ad36-631042b5008f, \_SB.UBTC device, 48-byte SystemMemory OperationRegion mailbox) and can reproduce any test reliably given the DKMS/MOK pipeline is already set up on this machine.

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

--- Comment #1 from [email protected] ---
Root cause found and a fix verified on the ASUS ZenBook UX425UA_UM425UA (BIOS
UX425UA.301, Ryzen 7 5700U). Kernel used for the tests: Ubuntu 6.8.0-124 (Ubuntu's UCSI code is a backported variant of 6.8); the same fix also worked with
the upstream v6.8 ucsi and ucsi_acpi modules.

Summary: the firmware clears the EC's CCI register when it is read, so
ucsi_acpi's init does not fail at the PPM reset (that works) but at SET_NOTIFICATION_ENABLE. The existing ucsi_zenbook_ops quirk, used for the ZenBook
UX325UA_UM325UA, fixes it; only this model's DMI name is missing from
ucsi_acpi_quirks[].

Details:

- ACPI: the UCSI device is USBC000 (SSDT with OEM table id "AmdTable"), the
PPM lives in the ASUS EC. The _DSM function 2 (read) copies the EC's VER/CCI/MESSAGE_IN into the memory mailbox and then writes zero into the EC's CCI byte 0
and byte 3. The EC event handler _Q79 does the same (copy, clear CCI0 and
CCI3, then Notify (UBTC, 0x80)). Decompiled tables attached.
- The generic ucsi_acpi_read() runs _DSM function 2 on every CCI read,
including from ucsi_acpi_notify(). So when the Notify arrives, _Q79 has already put "command complete" in the mailbox and cleared the EC copy, and the notify
handler's own _DSM read overwrites the mailbox CCI with zeros.
- Instrumented log (seconds since boot): PPM_RESET written at 1329.189; CCI
reads 0x00000000 at .194 and 0x08000000 (RESET_COMPLETE) at .218, so the reset works; SET_NOTIFICATION_ENABLE (0x80010005) written at .240; Notify 0x80
arrives at .261; the handler reads CCI 0x00000000; nothing completes the
wait, ucsi_acpi_sync_write() times out after its 5 * HZ and the init fails with "error -ETIMEDOUT: PPM init failed". Raising UCSI_TIMEOUT_MS or slowing the poll
loop changes nothing, because neither is the wait that expires (I tried 30 s
and a 200 ms poll interval).
- Checked and ruled out: the mailbox address from _CRS equals the
OperationRegion address used by _DSM (0xcc4ddca6), the EC handler is installed long before the probe, no OS-version gating in the UCSI methods.

Patch (against v6.8 ucsi_acpi.c, applies cleanly; newer trees have reworked
this file, I can retest on request):

--- a/drivers/usb/typec/ucsi/ucsi_acpi.c
+++ b/drivers/usb/typec/ucsi/ucsi_acpi.c
@@ -192,6 +192,13 @@

        },
        {
                .matches = {
  +                     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
  +                     DMI_MATCH(DMI_PRODUCT_NAME, "ZenBook UX425UA_UM425UA"),
  +             },
  +             .driver_data = (void *)&ucsi_zenbook_ops,
  +     },
  +     {
  +             .matches = {
                        DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
                },
                .driver_data = (void *)&ucsi_dell_ops,

Test result with this entry added (Ubuntu 6.8.0-124 ucsi_acpi.c, loaded live
and then permanently, surviving reboots, module loaded about 1 s into boot):
init completes, /sys/class/typec/port0 and port1 appear (port0 with the charger
as partner, USB PD 3.0), the ucsi-source-psy supplies register, no oops, no
other regressions. The connector status Request Data Object shows the real
contract: object position 4, 3250 mA, i.e. the 20 V 3.25 A PDO of the 65 W charger.

One more observation, probably an EC firmware limit: GET_PDOS for the partner
source capabilities returns only one PDO (fixed 5 V 3 A, 4 bytes) although the charger offers 5/9/15/20 V, so the power_supply attributes and
usb_power_delivery sysfs show 5 V while the actual contract is 20 V.

Could the entry be added upstream? I can send it as a proper patch to
linux-usb if that is preferred, and I can test other kernels or trees.

You may reply to this email to add a comment.

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