Message-ID: <CAJZ5v0hKNhspV9Rz4fydW0xu3SirYOOc_KZKEdATDA69PQ1F2w@mail.gmail.com>
Date: Mon, 5 Jan 2026 20:59:44 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Randy Dunlap <rdunlap@...radead.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux ACPI <linux-acpi@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, Bjorn Helgaas <helgaas@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Hans de Goede <hansg@...nel.org>, 
	Linux Documentation <linux-doc@...r.kernel.org>, 
	Mika Westerberg <mika.westerberg@...ux.intel.com>, Zhang Rui <rui.zhang@...el.com>, 
	Armin Wolf <w_armin@....de>, Danilo Krummrich <dakr@...nel.org>, 
	Ilpo Jarvinen <ilpo.jarvinen@...ux.intel.com>
Subject: Re: [PATCH v1] ACPI: Documentation: driver-api: Disapprove of using
 ACPI drivers

On Mon, Jan 5, 2026 at 8:40 PM Randy Dunlap <rdunlap@...radead.org> wrote:
>
>
>
> On 1/5/26 3:25 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> [snip]
> >
> > Link: https://uefi.org/specs/ACPI/6.6/02_Definition_of_Terms.html#term-ACPI-Namespace [1]
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > ---
> >
> > Although this patch can be applied independently, it actually depends on
> > some ACPI changes in linux-next and on
> >
> > https://lore.kernel.org/linux-acpi/12824456.O9o76ZdvQC@rafael.j.wysocki/
> >
> > so it is better to handle it along with that material.
> >
> > ---
> >  Documentation/driver-api/acpi/acpi-drivers.rst |   80 +++++++++++++++++++++++++
> >  Documentation/driver-api/acpi/index.rst        |    1
> >  2 files changed, 81 insertions(+)
> >
> > --- /dev/null
> > +++ b/Documentation/driver-api/acpi/acpi-drivers.rst
> > @@ -0,0 +1,80 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +.. include:: <isonum.txt>
> > +
> > +=========================================
> > +Why using ACPI drivers is not a good idea
> > +=========================================
> > +
> > +:Copyright: |copy| 2026, Intel Corporation
> > +
> > +:Author: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > +
> > +Even though binding drivers directly to struct acpi_device objects, also
> > +referred to as "ACPI device nodes", allows basic functionality to be provided
> > +at least in some cases, there are problems with it, related to general
> > +consistency, sysfs layout, power management operation ordering, and code
> > +cleanliness.
> > +
> > +First of all, ACPI device nodes represent firmware entities rather than
> > +hardware and in many cases they provide auxiliary information on devices
> > +enumerated independently (like PCI devices or CPUs).  It is therefore generally
> > +questionable to assign resources to them because the entities represented by
> > +them do not decode addresses in the memory or I/O address spaces and do not
> > +generate interrupts or similar (all of that is done by hardware).
> > +
> > +Second, as a general rule, a struct acpi_device can only be a parent of another
> > +struct acpi_device.  If that is not the case, the location of the child device
> > +in the device hierarchy is at least confusing and it may not be straightforward
> > +to identify the piece of hardware providing functionality represented by it.
> > +However, binding a driver directly to an ACPI device node may cause that to
> > +happen if the given driver registers input devices or wakeup sources under it,
> > +for example.
> > +
> > +Next, using system suspend and resume callbacks directly on ACPI device nodes
> > +is questionable either because it may cause ordering problems to appear.
>
> Missing the "or ..." following "either because ...".
> Or did you mean something like "also" instead of "either"?

Yes, I'll change it into "is also questionable".

>
> > +Namely, ACPI device nodes are registered before enumerating hardware
> > +corresponding to them and they land on the PM list in front of the majority
> > +of other device objects.  Consequently, the execution ordering of their PM
> > +callbacks may be different from what is generally expected.  Also, in general,
> > +dependencies returned by _DEP objects do not affect ACPI device nodes
> > +themselves, but the "physical" devices associated with them, which potentially
> > +is one more source of inconsistency related to treating ACPI device nodes as
> > +"real" device representation.
> > +
> > +All of the above means that binding drivers to ACPI device nodes should
> > +generally be avoided and so struct acpi_driver objects should not be used.
> > +
> > +Moreover, a device ID is necessary to bind a driver directly to an ACPI device
> > +node, but device IDs are not generally associated with all of them.  Some of
> > +them contain alternative information allowing the corresponding pieces of
> > +hardware to be identified, for example represented by an _ADR object return
> > +value, and device IDs are not used in those cases.  In consequence, confusingly
> > +enough, binding an ACPI driver to an ACPI device node may even be impossible.
> > +
> > +When that happens, the piece of hardware corresponding to the given ACPI device
> > +node is represented by another device object, like a struct pci_dev, and the
> > +ACPI device node is the "ACPI companion" of that device, accessible through its
> > +fwnode pointer used by the ACPI_COMPANION() macro.  The ACPI companion holds
> > +additional information on the device configuration and possibly some "recipes"
> > +on device manipulation in the form of AML (ACPI Machine Language) byte code
> > +provided by the platform firmware.  Thus the role of the ACPI device node is
> > +similar to the role of a struct device_node on a system where Device Tree is
> > +used for platform description.
> > +
> > +For consistency, this approach has been extended to the cases in which ACPI
> > +device IDs are used.  Namely, in those cases, an additional device object is
> > +created to represent the piece of hardware corresponding to a given ACPI device
> > +node.  By default, it is a platform device, but it may also be a PNP device, a
> > +CPU device, or another type of device, depending on what the given piece of
> > +hardware actually is.  There are even cases in which multiple devices are
> > +"backed" or "accompanied" by one ACPI device node (eg. ACPI device nodes
>
>                                                       e.g.

OK

Powered by blists - more mailing lists