1.. SPDX-License-Identifier: GPL-2.0 2.. include:: <isonum.txt> 3 4========================================= 5Why using ACPI drivers is not a good idea 6========================================= 7 8:Copyright: |copy| 2026, Intel Corporation 9 10:Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> 11 12Even though binding drivers directly to struct acpi_device objects, also 13referred to as "ACPI device nodes", allows basic functionality to be provided 14at least in some cases, there are problems with it, related to general 15consistency, sysfs layout, power management operation ordering, and code 16cleanliness. 17 18First of all, ACPI device nodes represent firmware entities rather than 19hardware and in many cases they provide auxiliary information on devices 20enumerated independently (like PCI devices or CPUs). It is therefore generally 21questionable to assign resources to them because the entities represented by 22them do not decode addresses in the memory or I/O address spaces and do not 23generate interrupts or similar (all of that is done by hardware). 24 25Second, as a general rule, a struct acpi_device can only be a parent of another 26struct acpi_device. If that is not the case, the location of the child device 27in the device hierarchy is at least confusing and it may not be straightforward 28to identify the piece of hardware providing functionality represented by it. 29However, binding a driver directly to an ACPI device node may cause that to 30happen if the given driver registers input devices or wakeup sources under it, 31for example. 32 33Next, using system suspend and resume callbacks directly on ACPI device nodes 34is also questionable because it may cause ordering problems to appear. Namely, 35ACPI device nodes are registered before enumerating hardware corresponding to 36them and they land on the PM list in front of the majority of other device 37objects. Consequently, the execution ordering of their PM callbacks may be 38different from what is generally expected. Also, in general, dependencies 39returned by _DEP objects do not affect ACPI device nodes themselves, but the 40"physical" devices associated with them, which potentially is one more source 41of inconsistency related to treating ACPI device nodes as "real" device 42representation. 43 44All of the above means that binding drivers to ACPI device nodes should 45generally be avoided and so struct acpi_driver objects should not be used. 46 47Moreover, a device ID is necessary to bind a driver directly to an ACPI device 48node, but device IDs are not generally associated with all of them. Some of 49them contain alternative information allowing the corresponding pieces of 50hardware to be identified, for example represeted by an _ADR object return 51value, and device IDs are not used in those cases. In consequence, confusingly 52enough, binding an ACPI driver to an ACPI device node may even be impossible. 53 54When that happens, the piece of hardware corresponding to the given ACPI device 55node is represented by another device object, like a struct pci_dev, and the 56ACPI device node is the "ACPI companion" of that device, accessible through its 57fwnode pointer used by the ACPI_COMPANION() macro. The ACPI companion holds 58additional information on the device configuration and possibly some "recipes" 59on device manipulation in the form of AML (ACPI Machine Language) bytecode 60provided by the platform firmware. Thus the role of the ACPI device node is 61similar to the role of a struct device_node on a system where Device Tree is 62used for platform description. 63 64For consistency, this approach has been extended to the cases in which ACPI 65device IDs are used. Namely, in those cases, an additional device object is 66created to represent the piece of hardware corresponding to a given ACPI device 67node. By default, it is a platform device, but it may also be a PNP device, a 68CPU device, or another type of device, depending on what the given piece of 69hardware actually is. There are even cases in which multiple devices are 70"backed" or "accompanied" by one ACPI device node (e.g. ACPI device nodes 71corresponding to GPUs that may provide firmware interfaces for backlight 72brightness control in addition to GPU configuration information). 73 74This means that it really should never be necessary to bind a driver directly to 75an ACPI device node because there is a "proper" device object representing the 76corresponding piece of hardware that can be bound to by a "proper" driver using 77the given ACPI device node as the device's ACPI companion. Thus, in principle, 78there is no reason to use ACPI drivers and if they all were replaced with other 79driver types (for example, platform drivers), some code could be dropped and 80some complexity would go away. 81