public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Linux ACPI <linux-acpi@vger.kernel.org>
Cc: "Hans de Goede" <hdegoede@redhat.com>,
	LKML <linux-kernel@vger.kernel.org>,
	"Linux PM" <linux-pm@vger.kernel.org>,
	"Thomas Weißschuh" <linux@weissschuh.net>,
	"Armin Wolf" <w_armin@gmx.de>
Subject: [PATCH v1 10/10] ACPI: Convert button and battery drivers to platform ones
Date: Tue, 09 Dec 2025 14:49:38 +0100	[thread overview]
Message-ID: <2339822.iZASKD2KPV@rafael.j.wysocki> (raw)

Hi All,

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].

Thanks!






             reply	other threads:[~2025-12-09 14:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-09 13:49 Rafael J. Wysocki [this message]
2025-12-09 13:53 ` [PATCH v1 01/10] ACPI: scan: Register platform devices for fixed event buttons Rafael J. Wysocki
2025-12-09 13:53 ` [PATCH v1 02/10] ACPI: scan: Reduce code duplication related to fixed event devices Rafael J. Wysocki
2025-12-09 13:53 ` [PATCH v1 03/10] ACPI: button: Adjust event notification routines Rafael J. Wysocki
2025-12-09 13:54 ` [PATCH v1 04/10] ACPI: button: Convert the driver to a platform one Rafael J. Wysocki
2025-12-09 13:55 ` [PATCH v1 05/10] ACPI: tiny-power-button: " Rafael J. Wysocki
2025-12-09 13:56 ` [PATCH v1 06/10] ACPI: scan: Do not bind ACPI drivers to fixed event buttons Rafael J. Wysocki
2025-12-09 13:56 ` [PATCH v1 07/10] ACPI: scan: Do not mark button ACPI devices as wakeup-capable Rafael J. Wysocki
2025-12-09 13:57 ` [PATCH v1 08/10] ACPI: battery: Adjust event notification routine Rafael J. Wysocki
2025-12-09 13:58 ` [PATCH v1 09/10] ACPI: battery: Reduce code duplication related to cleanup Rafael J. Wysocki
2025-12-09 13:59 ` [PATCH v1 10/10] ACPI: battery: Convert the driver to a platform one Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2339822.iZASKD2KPV@rafael.j.wysocki \
    --to=rafael@kernel.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@weissschuh.net \
    --cc=w_armin@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox