ACPI SystemIO range conflicts signal driver access issues, not firmware faults

The Advanced Configuration and Power Interface (ACPI) provides hardware abstraction by exposing Operation Regions defined in ASL bytecode that the OS interprets at runtime. An Operation Region maps a range of IO ports to named fields, allowing firmware methods to read or write hardware registers through those fields. The example in the material shows a two-byte region at port 0x400 with an index register and a data register accessed via INDX and DATA. Methods that manipulate INDX and DATA must serialize access to avoid corrupting concurrent operations.

If a Linux driver accesses the same IO ports directly, without knowledge of the ACPI method, it can race with firmware that is simultaneously updating the index or data register. The material illustrates a scenario where a read method resets the index while a write method is halfway through, causing the write to target the wrong register. Such a race can produce bogus values, such as interpreting a status flag as a temperature reading, leading to incorrect thermal management. The kernel has no way to know whether the firmware access is safe, so it treats the overlap as potentially hazardous.

When the kernel detects that a driver is trying to allocate an IO range that overlaps an existing ACPI Operation Region, it prints a warning like "ACPI Warning: SystemIO range … conflicts with OpRegion …". The warning is followed by a note advising that, if an ACPI driver exists for the device, it should be used instead of the native driver. By blocking the driver from loading, the kernel prevents the possible hardware-damaging race condition described earlier. This mechanism shifts the responsibility from assuming a firmware bug to checking whether the driver should defer to the ACPI-provided interface.

For engineers, the key takeaway is that these warnings do not indicate a flaw in the motherboard firmware but rather a potential conflict between driver and firmware access patterns. Addressing the issue involves either using the available ACPI driver, adding proper locking in the driver, or avoiding direct IO port access when an ACPI region covers the same addresses. If no ACPI driver is provided and the firmware does not expose a safe interface, the kernel’s block may leave the device without a functional driver, limiting functionality. Thus, understanding the ACPI-IO relationship helps avoid misdiagnosis and guides appropriate driver design or device selection.