[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@kernel.org]

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.