linux-kernel - Re: [PATCH v2] ACPI: Documentation: driver-api: Disapprove of using ACPI drivers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0ihuu_9G7N5UkHAGwRq=BN1spkXmdOuUTxRFwn3acdfbw@mail.gmail.com>
Date: Wed, 7 Jan 2026 13:22:47 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Mario Limonciello (AMD) (kernel.org)" <superm1@...nel.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>, Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v2] ACPI: Documentation: driver-api: Disapprove of using
 ACPI drivers

On Tue, Jan 6, 2026 at 4:47 PM Mario Limonciello (AMD) (kernel.org)
<superm1@...nel.org> wrote:
>
>
>
> On 1/6/2026 6:27 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> >
> > Sadly, there is quite a bit of technical debt related to the
> > kernel's ACPI support subsystem and one of the most significant
> > pieces of it is the existence and use of ACPI drivers represented
> > by struct acpi_driver objects.
> >
> > Those drivers are bound directly to struct acpi_device objects, also
> > referred to as "ACPI device nodes", representing device objects in the
> > ACPI namespace defined as:
> >
> >   A hierarchical tree structure in OS-controlled memory that contains
> >   named objects. These objects may be data objects, control method
> >   objects, bus/device package objects, and so on.
> >
> > according to the ACPI specification [1].
> >
> > The above definition implies, although rather indirectly, that the
> > objects in question don't really represent hardware.  They are just
> > "device package objects" containing some information on the devices
> > present in the given platform that is known to the platform firmware.
> >
> > Although the platform firmware can be the only source of information on
> > some devices, the information provided by it alone may be insufficient
> > for device enumeration in general.  If that is the case, binding a
> > driver directly to a given ACPI device node clearly doesn't make sense.
> > If the device in question is enumerated through a hardware interface, it
> > will be represented by a device object matching that interface, like
> > a struct pci_dev, and the ACPI device node corresponding to it will be
> > treated as its "ACPI companions" whose role is to amend the "native"
> > enumeratiom mechanism.
> >
> > For the sake of consistency and confusion avoidance, it is better to
> > treat ACPI device nodes in general as ACPI companions of other device
> > objects representing hardware.  In some cases though it appeared easier
> > to take a shortcut and use an ACPI driver binding directly to an ACPI
> > device node.  Moreover, there were corner cases in which that was the
> > only choice, but they all have been addressed now.
> >
> > In all cases in which an ACPI driver might be used, the ACPI device
> > node it might bind to is an ACPI companion of another device object
> > representing a piece of hardware.  It is thus better to use a driver
> > binding to the latter than to use an ACPI driver and leave the other
> > device object alone, not just because doing so is more consistent and
> > less confusing, but also because using ACPI drivers may lead to
> > potential functional deficiencies, like possible ordering issues
> > related to power management.
> >
> > Unfortunately, there are quite a few ACPI drivers in use and, as a rule,
> > they bind to ACPI device nodes that are ACPI companions of platform
> > devices, so in fact they play the role of platform drivers although in
> > a kind of convoluted way.  An effort has been under way to replace them
> > with platform drivers, which is relatively straightforward in the vast
> > majority of cases, but it has not been pursued very aggressively so far,
> > mostly due to the existence of the corner cases mentioned above.
>
> This is the same as Danilo's comment; but could you leave a few examples
> of conversions that have been done successfully?  Commit hashes that can
> demonstrate what it actually takes to convert an acpi driver to a
> platform driver and might make it easier for people to reference when
> this comes up.

The purpose of this posting and the new document is to grow awareness
rather than to tell people how to convert drivers.

I'll start posting driver conversion patches at one point and the
motivation for all of them is basically the same, so I thought it
would be better to document it in on place and then refer to it
instead of repeating the same information every time a conversion
patch is posted.