linux-kernel - Re: [PATCH v1] 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0idtXwyQHEEL=NhJyDTa3m0pUuZgmVaHEOcGo_pGqeJOw@mail.gmail.com>
Date: Mon, 5 Jan 2026 19:44:47 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, Linux ACPI <linux-acpi@...r.kernel.org>, 
	LKML <linux-kernel@...r.kernel.org>, 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 4:45 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Mon, Jan 05, 2026 at 12:25:04PM +0100, Rafael J. Wysocki wrote:
>
> > 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, bindig a driver
>
> binding

Fixed, thanks!

> > 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"
> > enumeration 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.
> > However, since those corner cases are gone now, it makes sense to spend
> > more time on driver conversions with the ultimate goal to get rid of
> > struct acpi_driver and the related code from the kernel.
> >
> > To that end, add a document explaining why using ACPI drivers is not
> > a good idea, so it need not be explained from scratch on every attempt
> > to convert an ACPI driver to a platform one.
>
> Reviewed-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
>
> I have read it in full and found quite useful. Also it would be probably good
> to have a pointer somewhere on the example how to convert the driver from ACPI
> driver to a platform one. Maybe in a form of the existing commit(s), dunno...

I'm going to post a few of these in the near future, so there should
be examples readily available going forward.