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] [thread-next>] [day] [month] [year] [list]

Message-Id: <DFICQ5UQZLVB.24RQQD89L7F3R@kernel.org>
Date: Wed, 07 Jan 2026 13:21:49 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: "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>, "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 CET, Rafael J. Wysocki 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.

Ok, sounds good then. With or without rephrasing the last sentence,

Reviewed-by: Danilo Krummrich <dakr@...nel.org>