Message-ID: <CAJZ5v0iYCVW09z0P2UUS6bGiYV6R5ajPaxVfDZeBKwF4Q+Fhkw@mail.gmail.com>
Date: Mon, 15 Dec 2025 15:46:29 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: "Rafael J. Wysocki" <rafael@...nel.org>
Cc: Linux ACPI <linux-acpi@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Linux PM <linux-pm@...r.kernel.org>, Thomas Weißschuh <linux@...ssschuh.net>, 
	Armin Wolf <w_armin@....de>, Hans de Goede <hansg@...nel.org>
Subject: Re: [PATCH v2 00/10] ACPI: Convert button and battery drivers to
 platform ones

On Mon, Dec 15, 2025 at 3:04 PM Rafael J. Wysocki <rafael@...nel.org> wrote:
>
> Hi All,
>
> This is a v2 of
>
> https://lore.kernel.org/linux-acpi/2339822.iZASKD2KPV@rafael.j.wysocki/
>
> with the majority of patches unchanged and some of them updated, mostly
> for cleanliness.
>
> The following intro still applies.
>
> While binding drivers directly to struct acpi_device objects allows
> basic functionality to be provided, at least in the majority of cases,
> there are some problems with it, related to general consistency, sysfs
> layout, power management operation ordering, and code cleanliness.
>
> First of all, struct acpi_device objects represent firmware entities
> rather than hardware and in many cases they provide auxiliary information
> on devices enumerated independently (like PCI devices or CPUs).  It is
> therefore generally questionable to assign resources to them or create
> class devices and similar under them because they don't provide
> functionality associated with those entities by themselves (for example,
> they don't generate wakeup or input events).
>
> As a general rule, a struct acpi_device can only be a parent of another
> struct acpi_device.  If that's not the case, the location of the child
> device in the device hierarchy is at least confusing and it may not be
> straightforward to identify the piece of hardware corresponding to that
> device.
>
> Using system suspend and resume callbacks directly with struct acpi_device
> objects is questionable either because it may cause ordering problems to
> happen.  Namely, struct acpi_device objects are registered before any
> devices corresponded to by them and they land on the PM list before all
> of those devices.  Consequently, the execution ordering of their PM
> callbacks may be different from what is generally expected.  Moreover,
> dependencies returned by _DEP objects don't generally affect struct
> acpi_device objects themselves, only the "physical" device objects
> associated with them, which potentially is one more source of inconsistency.
>
> All of the above means that binding drivers to struct acpi_device "devices"
> should generally be avoided and so this series converts three generic ACPI
> device drivers, the button driver, the tiny power button driver, and the
> battery driver, to platform drivers.
>
> Patches [01-03/10] are preliminary for the button driver conversions.  Patch
> [01/10] causes platform devices to be registered for "fixed event device"
> buttons, patch [02/10] cleans up the "fixed event device" registration code,
> and patch [03/10] rearranges the notification handling code in the button
> driver to use internal "button" structures for passing data instead of
> struct acpi_device objects.
>
> Patches [04-05/10] convert the two button drivers to platform ones and
> patches [06-07/10] do some cleanups on top of them.
>
> Patches [08-09/10] are preliminary for the battery driver conversion which
> is carried out in patch [10/10].

This series is now present in the acpi-queue branch in my tree:

git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
acpi-queue

along with some other material (mostly related to driver conversions)
posted recently.

Thanks!

Powered by blists - more mailing lists