Message-ID: <CAJZ5v0heEwzVx39wz3qNThpniG3kPfEkk87Y2xTXBbmNaiEKrQ@mail.gmail.com>
Date: Tue, 13 Jan 2026 23:02:09 +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 13, 2026 at 10:58 PM Mario Limonciello (AMD) (kernel.org)
<superm1@...nel.org> wrote:
>
>
>
> On 1/7/2026 6:22 AM, Rafael J. Wysocki wrote:
> > 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.
>
> Thanks for explaining.  Makes sense to me.  If you didn't already commit
> feel free to add my tag (no need to spin it if you already did).
>
> Reviewed-by: Mario Limonciello (AMD) <superm1@...nel.org>

I did, but adding a tag to it is not a big deal, thanks!

Powered by blists - more mailing lists