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