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 on the CC list for the bug. _______________________________________________ acpi-bugzilla mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
