[BUG] ACPI: s2idle: Microsoft LPS0 _DSM revision mismatch prevents EC standby on Acer PHN16S-71

[Sneako]

Hello,

I would like to report a reproducible ACPI suspend-to-idle problem on
the Acer Predator PHN16S-71, for which I have identified and
experimentally verified a specific firmware compatibility issue in
drivers/acpi/x86/s2idle.c.

Hardware and software

Acer Predator PHN16S-71, Intel Core Ultra 9 275HX (Arrow Lake-HX)

Acer/Insyde BIOS version 1.28

CachyOS kernel 7.2.11-1-cachyos

Suspend-to-idle (S0ix); no ACPI S3 support

Problem

On Linux, suspend blanks the display but leaves the fans, power
indicator and performance-mode lighting active. Windows correctly
shuts these components down.

The Microsoft Modern Standby _DSM interface (UUID
11e00d56-ce64-47ce-837b-1f898f9aa461) is detected, and the kernel
reports successful sleep-entry and sleep-exit notifications.

However, kprobe traces of acpi_evaluate_dsm() show:

revision=1 function=7  (sleep entry)
revision=1 function=8  (sleep exit)

Simultaneous tracing of acpi_os_write_port() shows none of the
expected EC commands during these callbacks.

Firmware investigation

I extracted and decompiled the laptop's BIOS 1.28 DSDT.

The Microsoft _DSM implementation executes its function dispatch only
when ToInteger(Arg1) == Zero.

Function 7 performs:

EC0.E3CS(0xEC)
PGPI.SGOV(0x00160C8B, 0)
EC0.E3CS(0xE4)

Function 8 reverses the GPIO state and calls EC0.E3CS(0xE5).

E3CS writes to an ACPI SystemIO region at physical port 0x6E.

Suspected kernel issue

In lps0_device_attach(), the Microsoft _DSM is probed using revision
0. However, the shared rev_id variable is subsequently set to 1 for
Intel's separate LPS0 interface.

acpi_sleep_run_lps0_dsm() uses this same variable when invoking both interfaces.

Microsoft's Modern Standby firmware notification documentation
explicitly specifies revision 0 for functions 3 through 9.

Consequently, Acer's Microsoft _DSM receives revision 1 and returns
without executing its EC sleep commands.

Experimental confirmation

I constructed a temporary Linux early-initramfs DSDT override,
changing only the Microsoft _DSM revision condition to accept
revisions 0 and 1.

With that override:

All affected fans and lights shut off during suspend.

The system wakes normally and the fans and lighting restore correctly.

The same machine, without the override, retains the original faulty
physical standby behavior.

No BIOS flash, direct EC commands, or fan-control manipulation was involved.

This provides strong evidence that the revision mismatch is
responsible for the missing platform standby behavior.

Proposed fix

Use revision 0 when invoking the Microsoft platform-agnostic _DSM,
while retaining the existing revision selection for Intel- and
AMD-specific _DSM interfaces.

I believe a generic UUID-specific fix may be preferable to a
machine-specific DMI quirk, since the Microsoft interface documents
revision 0. I would appreciate the maintainers' assessment of
compatibility implications.

Separate NVMe issue

This laptop independently requires nvme.noacpi=1 to accumulate Intel
S0ix residency. With the DSDT override but without that parameter,
fans and lights correctly turn off, but S0ix residency remains
essentially zero. With both changes, physical standby behavior and
Intel S0ix residency work.

I am treating the NVMe issue separately; the proposed _DSM fix is not
claimed to resolve it.

I can provide the original ACPI tables, kprobe traces, before/after
Intel PMC captures, and the precise DSDT override.

The issue was reproduced with a CachyOS kernel, and the revision
mismatch was independently confirmed in upstream source. I have not
yet boot-tested a kernel rebuilt with the proposed source change.

Microsoft specification:
https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby-firmware-notifications

Thank you for your consideration.