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: <CAJZ5v0h+xwRJg9=-FYnHy5O=o=YzX_u6Qpt3WQ-3XCbnJyh=vA@mail.gmail.com>
Date: Tue, 27 Jan 2026 19:50:51 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Linux ACPI <linux-acpi@...r.kernel.org>
Cc: Danilo Krummrich <dakr@...nel.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>, Ilpo Jarvinen <ilpo.jarvinen@...ux.intel.com>, 
	Mario Limonciello <mario.limonciello@....com>, Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v2] ACPI: Documentation: driver-api: Disapprove of using
 ACPI drivers

On Wed, Jan 7, 2026 at 1:14 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> On Tue, Jan 6, 2026 at 3:01 PM Danilo Krummrich <dakr@...nel.org> wrote:
> >
> > On Tue Jan 6, 2026 at 1:27 PM CET, Rafael J. Wysocki wrote:
> > > +This means that it really should never be necessary to bind a driver directly to
> > > +an ACPI device node because there is a "proper" device object representing the
> > > +corresponding piece of hardware that can be bound to by a "proper" driver using
> > > +the given ACPI device node as the device's ACPI companion.  Thus, in principle,
> > > +there is no reason to use ACPI drivers and if they all were replaced with other
> > > +driver types (for example, platform drivers), some code could be dropped and
> > > +some complexity would go away.
> >
> > I think it would be good to explicitly encourage people to convert existing
> > drivers (maybe even list some of those) and rephrase the last sentence to list
> > what exact infrastructure, complexity, etc. can go away once that happened.
>
> I can rephrase the last sentence, but the purpose of this document is
> to explain the motivation for the change rather than to make a call to
> action.
>
> > I think this would make it more likely to receive some contributions towards
> > this goal.
>
> I have prototype driver conversion patches for almost 50% of the cases
> right now and I'm expecting to have them for all of the cases by the
> end of the current development cycle, so I'm not sure how much there
> is to gain.
>
> I want people to not be surprised when they see those patches though.

Actually, all of this work is almost ready to be submitted, but in the
meantime I put the patches on an experimental branch here:

https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git/log/?h=experimental/acpi-driver-conversion

It includes some material already queued up for 6.20/7.0 and a fix
that has been posted.

The changelogs are a bit rudimentary and need some more work, but the
code changes should be complete (famous last words).