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

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.