ACPI, is it worth it?

Supporting ACPI replaces Linux kernel drivers and hardware descriptions with lower quality and infrequently updated non-community drivers and hardware descriptions. x86 is a lost cause, but there is still hope for aarch64.

The ACPI specification defines a hardware description and runtime interface to hardware. It is common among x86 PCs and servers where hardware is fairly homogeneous. Motherboard vendors contract or implement those descriptions as well as the drivers necessary for their hardware.

Intel maintains a reference implementation on Github named ACPI Component Architecture (ACPICA).

On platforms not supporting ACPI this is implemented typically through devicetree and kernel drivers.

Classically on x86 all ACPI runtime code executed in a privileged environment (i.e. SMM) that required blocking the operating system. On ARM systems it executes in the operating context, which is increasingly possible on x86 with ACPI 6.4 around 2021.

/*
 * On some machines all fan related SMM functions implemented by Dell BIOS
 * firmware freeze kernel for about 500ms. Until Dell fixes these problems fan
 * support for affected blacklisted Dell machines stay disabled.
 * See bug: https://bugzilla.kernel.org/show_bug.cgi?id=195751
 */

linux/drivers/hwmon/dell-smm-hwmon.c

ACPI implementations are nearly all closed source, not consistently updated and receive very little investment (i.e. low cost).

ACPI on Arm systems on docs.kernel.org states that the Linux community now has a seat at the table with hardware vendors and other OS vendors, however …

Linux could potentially get there with DT, but doing so really just duplicates something that already works. ACPI already does what the hardware vendors need, Microsoft won’t collaborate on DT, and hardware vendors would still end up providing two completely separate firmware interfaces – one for Linux and one for Windows.

• The hardware or IP that ACPI abstracts is generally simpler and changes significantly less than the hardware or IP that isn’t abstracted
  • Discrete hardware: EEPROM, temperature sensors, SPI flash, PWM fan controller
  • IP: I2C controller, SPI controller
• The hardware or IP required to support new platforms that is abstracted by ACPI is a very small part of the overall effort
• The standardized hardware used in systems that use ACPI
• Removing the requirement of an operating system to implement certain drivers only allows those resources to go to supporting other hardware in the context of a business. In an open source community the folks writing I2C controller or device drivers are not typically freed up to work on other subsystems
• The drivers and subsystems for controlling hardware in Linux are better than those provided by vendors for ACPI. Also using ACPI prevents the kernel implementations from being used.
• If the goal was to reduce the effort for smaller or less mature operating systems then it would be better to implement a generic library that can be linked at build time and be updated with the operating system
• The number of systems that need to boot multiple operating systems is increasingly small
• The subsystems and drivers abstracted by ACPI still need to be implemented in embedded anyway. Although the hardware may differ slightly with PCs and servers there is significant overlap
• What features does the kernel thermal subsystem provide when controlling hardware that is not possible or poorly implemented through ACPI?
• devicetree is implemented in fairly intuitive text files accessible in the kernel source vs. ACPI tables that can only be read from a running system
• devicetree is also used in U-Boot, Zephyr, …