Incompatible ACPI

Posted Aug 26, 2025 13:15 UTC (Tue) by tobhe (subscriber, #157486)
In reply to: Incompatible ACPI by qwertyface
Parent article: Adding stubble to Ubuntu's generic Arm64 Desktop ISOs

> Does anyone have a link to something I could read about what makes the ACPI implementation incompatible? Does it deviate from the standard in some way?

It does deviate quite a bit. They make heavy use of something called PEP (https://learn.microsoft.com/en-us/windows-hardware/driver...)

Quoting from the link above:
> PEPs provide dynamic, runtime ACPI methods. The static tables (FADT, MADT, DBG2, etc.) must be implemented in the ACPI firmware, as well as the DSDT/SSDT device hierarchy.

In a way this is similar to how device trees work but implemented in ACPI. The tables only contain static device hierarchy information, the logic moves into the Windows driver and can't be used in Linux. There also isn't any PEP support in Linux at the moment so instead of reusing the static ACPI tables we are "translating" them to DTs.

I am not aware of any good written source but Linaro engineers have talked about it previously, for example in https://fosdem.org/2025/schedule/event/fosdem-2025-6224-w... starting at 0:50

Incompatible ACPI

Posted Aug 26, 2025 15:07 UTC (Tue) by pizza (subscriber, #46) [Link] (3 responses)

> In a way this is similar to how device trees work but implemented in ACPI. The tables only contain static device hierarchy information, the logic moves into the Windows driver and can't be used in Linux. There also isn't any PEP support in Linux at the moment so instead of reusing the static ACPI tables we are "translating" them to DTs.

WTF was MSFT+QCOM smoking?

This "solution" combines the worst parts of all worlds, with none of the benefits.

...The entire *point* of ACPI is to avoid needing board-specific drivers.

Incompatible ACPI

Posted Aug 26, 2025 16:12 UTC (Tue) by tobhe (subscriber, #157486) [Link] (2 responses)

> This "solution" combines the worst parts of all worlds, with none of the benefits.

I too would prefer proper ACPI but I don't think "no benefits" is entirely true. PEPs like device trees do have one advantage:
The logic is much easier to update as part of the kernel.

Neither Microsoft nor Qualcomm can easily push firmware updates on those devices, that would have to go through the OEMs and have to be signed with their keys. Splitting structure and logic does make some sense in that context. The hierarchy is static and ideally doesn't ever need to be updated while the code can be maintained and updated like any other piece of software (vs hard to update firmware).

Incompatible ACPI

Posted Aug 29, 2025 12:16 UTC (Fri) by pizza (subscriber, #46) [Link] (1 responses)

> PEPs like device trees do have one advantage: The logic is much easier to update as part of the kernel.

That's the sliver lining of what is otherwise a massive downside: The kernel has to still be specifically aware of the nuances of *that particular system* for it to function properly.

> Neither Microsoft nor Qualcomm can easily push firmware updates on those devices, that would have to go through the OEMs and have to be signed with their keys

How exactly is this any different from how PCs with UEFI have worked for the past decade? (Or over 2 decades if you include pre-UEFI ACPI)

Incompatible ACPI

Posted Aug 29, 2025 20:44 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

> How exactly is this any different from how PCs with UEFI have worked for the past decade? (Or over 2 decades if you include pre-UEFI ACPI)

UEFI/ACPI both have been insufficient for anything complicated or custom. So we got drivers based on WMI (Windows Management Instrumentation) for things like backlight control. They are mostly trivial, though. I'm not sure that writing a custom driver is much worse than having to deal with per-device quirks and opaque firmware updates that might not be tested with Linux.

Incompatible ACPI

Posted Aug 26, 2025 17:04 UTC (Tue) by qwertyface (subscriber, #84167) [Link]

Thanks very much!