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

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

[bugzilla-daemon]

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: drivers_usb@kernel-bugs.kernel.org
          Reporter: sax69sax420@gmail.com
        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.

[Bug 221977] ucsi_acpi PPM_RESET timeout on ASUS Zenbook UX425UA/UM425UA (AMD Renoir) - not fixed by poll_cci or timeout increase, tested extensively

[bugzilla-daemon]

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

--- Comment #1 from sax69sax420@gmail.com ---
  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.