[PATCH 6.18.y 0/3] ACPI: scan: fix the fixed event power button since 6.18.57

[PATCH 6.18.y 0/3] ACPI: scan: fix the fixed event power button since 6.18.57

[Ting-Han Hou]

Since 6.18.57, the ACPI power button is not bound to any driver when it
is a fixed event device (LNXPWRBN), so ACPI power-off requests are
ignored. This was reported for QEMU guests by Wolfgang Walter [1] and
Frederic MARIE-JOSEPH [2], and for Dell servers (power button and iDRAC
graceful shutdown) by Bob Anderson [1]. The ASRock H310CM-HDV report on
linux-acpi [3] (ff_pwr_btn "STS invalid") may be the same problem.

6.18.57 got 52d864019636 ("ACPI: button: Convert the driver to a
platform one") as a dependency of fe80251152fe ("ACPI: button: Fix ACPI
GPE handler leak during removal"), but not ab06eb920401 ("ACPI: scan:
Register platform devices for fixed event buttons"), so fixed event
buttons have no platform device to bind to. Bob found that
ab06eb920401 fixes it, Wolfgang confirmed that, and Sasha queued it for
6.18 [1]. 6.18.59-rc1 also converts the tiny power button driver to a
platform one, so with CONFIG_ACPI_TINY_POWER_BUTTON=y the fixed event
power button stops working in 6.18.59-rc1 as well (it still works in
6.18.58).

ab06eb920401 was then dropped from the 6.18 queue together with its two
upstream follow-up fixes (stable-queue c4d7fb7346 "drop acpi patches"),
with a FAILED report for f234fdaae1ca. With the three patches as they
were queued, drivers/acpi/acpi_platform.c does not build on 6.18.y:

  drivers/acpi/acpi_platform.c:92:21: error: implicit declaration of function '__resource_contains_unbound' [-Wimplicit-function-declaration]

__resource_contains_unbound() comes from edfaa81d5da5 ("resource: Add
__resource_contains_unbound() for internal contains checks"), which is
not in 6.18.y, so patch 3 uses resource_contains() instead; the note in
that patch explains why this is equivalent here. Patches 1 and 2 are
clean cherry-picks. aef7792cddca, which also has
"Fixes: ab06eb920401", only rewords a debug message and is not
included.

The series applies to both v6.18.58 and the current 6.18 queue
(6.18.59-rc1).

Testing: x86_64, QEMU q35 with KVM, an initramfs whose init waits for
the power button and then powers off, and QMP system_powerdown sent
after boot:

                                        without series   with series
  6.18.58,     CONFIG_ACPI_BUTTON=y     ignored          KEY_POWER, off in 0.5s
  6.18.59-rc1, CONFIG_ACPI_BUTTON=y     ignored          KEY_POWER, off in 0.5s
  6.18.59-rc1, ACPI_TINY_POWER_BUTTON   ignored          signal 38 to init, off in 0.5s
  6.18.58,     ACPI_TINY_POWER_BUTTON   works (still an ACPI driver there)

"ignored" means there is no "Power Button" input device, LNXPWRBN:00
has no physical node, and nothing happens until init gives up after 40
seconds. With the series, LNXPWRBN:00 gets a platform device bound to
acpi-button (or acpi-tiny-power-button), and the only new kernel
messages during boot are "input: Power Button as
/devices/platform/LNXPWRBN:00/input/input0" and "ACPI: button: Power
Button [PWRF]". A KASAN + PROVE_LOCKING + DEBUG_ATOMIC_SLEEP +
DEBUG_LIST build of 6.18.59-rc1 with the series boots and powers off
without splats, and there are no new W=1 or sparse warnings in
drivers/acpi/acpi_platform.c and drivers/acpi/scan.c.

Not tested: real hardware, and machines whose _CRS has overlapping
resources (the case patches 2 and 3 are about).

Tool use: most of this work was done with an LLM coding assistant
(Claude Code with Claude Opus 5.5). It found the regression reports and
the dropped queue patches while going through recent stable FAILED
mails, rebuilt 6.18.59-rc1 from stable-queue (its tree matches
linux-stable-rc), made the resource_contains() change in patch 3 and
wrote the notes in patches 1 and 3, wrote the test initramfs and
scripts, ran the builds and QEMU tests listed above, and drafted this
cover letter. Patches 1 and 2 are unmodified upstream code. I reviewed
the series and the test results before sending.

[1] https://lore.kernel.org/all/5fe757e7aa54c38df3525d313598db99@stwm.de/
[2] https://lore.kernel.org/all/20261022162655.231431-1-fredericmariejoseph@protonmail.com/
[3] https://lore.kernel.org/all/CADP5X9+xCTkxXZO1dcTodrwsfW=piV41c5f_zaOq6KsrxD0Hhw@mail.gmail.com/

Rafael J. Wysocki (3):
  ACPI: scan: Register platform devices for fixed event buttons
  ACPI: scan: Avoid registering platform devices with resource overlaps
  ACPI: scan: Do not combine resources that overlap completely

 drivers/acpi/acpi_platform.c | 79 ++++++++++++++++++++++++++++--------
 drivers/acpi/scan.c          |  4 ++
 2 files changed, 66 insertions(+), 17 deletions(-)


base-commit: 2926d88bb7fc4608fd942453d929c39e4e5ec006
-- 
2.53.0

[PATCH 6.18.y 1/3] ACPI: scan: Register platform devices for fixed event buttons

[Ting-Han Hou]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

[ Upstream commit ab06eb9204010c61e754bf4e71ee6f554584714d ]

On platforms using ACPI, power and sleep buttons may be so called "fixed
event devices" in which case they are hooked up directly to the Fixed
Events register in the platform via dedicated lines and there are no
corresponding device objects in the ACPI namespace.  Nevertheless, in
Linux they get corresponding struct acpi_device objects with special
device IDs, either LNXPWRBN or LNXSLPBN, which are then used for driver
binding in a ususal way.

However, the function creating those struct acpi_device objects for
"fixed event device" buttons, acpi_bus_scan_fixed(), does not register
platform devices for them, unlike the generic code handling device
enumeration based on the ACPI namespace.  Consequently, if an ACPI power
or sleep button is represented by a device object in the ACPI namespace,
it will get a corresponding platform device, but if it is a "fixed event
device", it will not get one, which is inconsistent and prevents the
ACPI power button driver from being converted into a platform driver.

For the sake of consistency and to allow the ACPI power button driver to
become a platform one going forward, modify acpi_bus_scan_fixed() to
register platform devices for "fixed event device" buttons and update
ACPI platform device registration code to work with non-device ACPI
object types, so it can handle the buttons in question.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/3731144.R56niFO833@rafael.j.wysocki
[ Ting-Han: 52d864019636 ("ACPI: button: Convert the driver to a platform
  one") was backported to 6.18.57 as a dependency of fe80251152fe
  ("ACPI: button: Fix ACPI GPE handler leak during removal") without this
  prerequisite, so fixed event power buttons (LNXPWRBN, e.g. on QEMU q35)
  have no platform device and are no longer bound to any driver. ]
Signed-off-by: Ting-Han Hou <ue081723@gmail.com>
---
 drivers/acpi/acpi_platform.c | 38 ++++++++++++++++++++----------------
 drivers/acpi/scan.c          |  4 ++++
 2 files changed, 25 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 48d15dd78..52c8d602f 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -114,10 +114,8 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
 	struct platform_device *pdev = NULL;
 	struct platform_device_info pdevinfo;
 	const struct acpi_device_id *match;
-	struct resource_entry *rentry;
-	struct list_head resource_list;
 	struct resource *resources = NULL;
-	int count;
+	int count = 0;
 
 	/* If the ACPI node already has a physical device attached, skip it. */
 	if (adev->physical_node_count)
@@ -137,22 +135,28 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
 		}
 	}
 
-	INIT_LIST_HEAD(&resource_list);
-	count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
-	if (count < 0)
-		return NULL;
-	if (count > 0) {
-		resources = kcalloc(count, sizeof(*resources), GFP_KERNEL);
-		if (!resources) {
+	if (adev->device_type == ACPI_BUS_TYPE_DEVICE) {
+		struct list_head resource_list = LIST_HEAD_INIT(resource_list);
+
+		count = acpi_dev_get_resources(adev, &resource_list, NULL, NULL);
+		if (count < 0)
+			return ERR_PTR(-ENODATA);
+
+		if (count > 0) {
+			struct resource_entry *rentry;
+
+			resources = kcalloc(count, sizeof(*resources), GFP_KERNEL);
+			if (!resources) {
+				acpi_dev_free_resource_list(&resource_list);
+				return ERR_PTR(-ENOMEM);
+			}
+			count = 0;
+			list_for_each_entry(rentry, &resource_list, node)
+				acpi_platform_fill_resource(adev, rentry->res,
+							    &resources[count++]);
+
 			acpi_dev_free_resource_list(&resource_list);
-			return ERR_PTR(-ENOMEM);
 		}
-		count = 0;
-		list_for_each_entry(rentry, &resource_list, node)
-			acpi_platform_fill_resource(adev, rentry->res,
-						    &resources[count++]);
-
-		acpi_dev_free_resource_list(&resource_list);
 	}
 
 	memset(&pdevinfo, 0, sizeof(pdevinfo));
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 7f9dd2704..c382bed50 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -2644,6 +2644,8 @@ static void acpi_bus_scan_fixed(void)
 				device_init_wakeup(&adev->dev, true);
 			else
 				dev_dbg(&adev->dev, "No driver\n");
+
+			acpi_default_enumeration(adev);
 		}
 	}
 
@@ -2656,6 +2658,8 @@ static void acpi_bus_scan_fixed(void)
 			adev->flags.match_driver = true;
 			if (device_attach(&adev->dev) < 0)
 				dev_dbg(&adev->dev, "No driver\n");
+
+			acpi_default_enumeration(adev);
 		}
 	}
 }
-- 
2.53.0

[PATCH 6.18.y 2/3] ACPI: scan: Avoid registering platform devices with resource overlaps

[Ting-Han Hou]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

commit f234fdaae1cad8c39265e7ca0a14633076ec7154 upstream.

If acpi_dev_get_resources() returns overlapping I/O or memory resources,
the subsequent registration of a platform device will fail with -EBUSY
due to a resource conflict.  This is reported to happen on Acer Aspire
ES1-572 [1].

Avoid that by adjusting resources returned by acpi_dev_get_resources()
to eliminate partial overlaps between them.

This has not been regarded as necessary before because putting
overlapping resources into the _CRS of one device is really pointless,
but now that the issue has been reported to actually happen in the
field, it needs to be done.

Fixes: ab06eb920401 ("ACPI: scan: Register platform devices for fixed event buttons")
Fixes: 48fe2cddc85c ("tpm_crb: Convert ACPI driver to a platform one")
Reported-by: Julien <julien82453@gmail.com>
Tested-by: Julien <julien82453@gmail.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Closes: https://lore.kernel.org/linux-integrity/CAJOGg3z6LJPDsdPNBxajgy8_wQxfhYBRxe4EiurZf3kPU5A5Bw@mail.gmail.com/ [1]
Cc: All applicable <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
[ rjw: Tweaked the new message ]
Link: https://patch.msgid.link/12955541.O9o76ZdvQC@rafael.j.wysocki
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Ting-Han Hou <ue081723@gmail.com>
---
 drivers/acpi/acpi_platform.c | 39 ++++++++++++++++++++++++++++++++++--
 1 file changed, 37 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index 52c8d602f..abdd8893e 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -12,6 +12,7 @@
 #include <linux/bits.h>
 #include <linux/device.h>
 #include <linux/err.h>
+#include <linux/ioport.h>
 #include <linux/kernel.h>
 #include <linux/module.h>
 #include <linux/dma-mapping.h>
@@ -71,6 +72,36 @@ static struct notifier_block acpi_platform_notifier = {
 	.notifier_call = acpi_platform_device_remove_notify,
 };
 
+static unsigned int acpi_platform_adjust_resources(struct acpi_device *adev,
+						   struct resource *new_res,
+						   struct resource *resources,
+						   unsigned int count)
+{
+	unsigned int i;
+
+	if (!(new_res->flags & (IORESOURCE_IO | IORESOURCE_MEM)))
+		return count;
+
+	for (i = 0; i < count; ) {
+		struct resource *res = &resources[i];
+
+		if (resource_type(new_res) != resource_type(res) ||
+		    !resource_union(new_res, res, new_res)) {
+			i++;
+			continue;
+		}
+
+		dev_info(&adev->dev, "%pR expanded due to overlap\n", new_res);
+		/*
+		 * Eliminate the previously processed resource that overlapped
+		 * with the new one because it is not necessary any more.
+		 */
+		memmove(res, res + 1, (--count - i) * sizeof(*res));
+	}
+
+	return count;
+}
+
 static void acpi_platform_fill_resource(struct acpi_device *adev,
 	const struct resource *src, struct resource *dest)
 {
@@ -151,10 +182,14 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *adev,
 				return ERR_PTR(-ENOMEM);
 			}
 			count = 0;
-			list_for_each_entry(rentry, &resource_list, node)
+			list_for_each_entry(rentry, &resource_list, node) {
+				count = acpi_platform_adjust_resources(adev,
+								       rentry->res,
+								       resources,
+								       count);
 				acpi_platform_fill_resource(adev, rentry->res,
 							    &resources[count++]);
-
+			}
 			acpi_dev_free_resource_list(&resource_list);
 		}
 	}
-- 
2.53.0

Re: [PATCH 6.18.y 2/3] ACPI: scan: Avoid registering platform devices with resource overlaps

[Sasha Levin]

> Fixes: ab06eb920401 ("ACPI: scan: Register platform devices for fixed event buttons")
> Fixes: 48fe2cddc85c ("tpm_crb: Convert ACPI driver to a platform one")

Queued 1/3 for 6.18, thanks. 2/3 and 3/3 are not needed there.

The problem 2/3 fixes is caused by 48fe2cddc85c ("tpm_crb: Convert ACPI
driver to a platform one"), which 6.18 does not have (it first appeared in
v7.1-rc1), so the Fixes: tag that points at 1/3 is a mis-attribution. On its
own 2/3 also regresses completely overlapping resources (arm-cmn probe fails
with -22), which only 3/3 repairs, so the pair would add risk on 6.18 for no
gain.

-- 
Thanks,
Sasha

[PATCH 6.18.y 3/3] ACPI: scan: Do not combine resources that overlap completely

[Ting-Han Hou]

From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>

[ Upstream commit 7617cc05df28dcae967cca109de74084321eaa62 ]

Commit f234fdaae1ca ("ACPI: scan: Avoid registering platform devices
with resource overlaps") attempted to avoid platform device registration
errors due to overlaps of resources of the same type returned by the
same _CRS object in the ACPI tables.  It did that by combining two or
more overlapping resources into one, but it went too far and also
caused resources that overlap completely to be combined which broke
the arm-cmn driver that expects two MMIO resources to be present for
each device it binds to and it expects those two resources to overlap
completely.

Address this issue by adding checks for completely overlapping
resources to acpi_platform_adjust_resources() and add a comment
explaining what is done there.

Fixes: f234fdaae1ca ("ACPI: scan: Avoid registering platform devices with resource overlaps")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Closes: https://lore.kernel.org/linux-acpi/20260819003752.GA3063251@ax162/
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Jarkko Sakkinen <jarkko@kernel.org>
Link: https://patch.msgid.link/12955564.O9o76ZdvQC@rafael.j.wysocki
[ Ting-Han: __resource_contains_unbound() was added by edfaa81d5da5
  ("resource: Add __resource_contains_unbound() for internal contains
  checks"), which is not in 6.18.y, so use resource_contains() instead.
  The two only differ in the IORESOURCE_UNSET check, and the resources
  returned by acpi_dev_get_resources() never have IORESOURCE_UNSET set:
  it is only set together with IORESOURCE_DISABLED, and disabled
  resources are not added to the list. ]
Signed-off-by: Ting-Han Hou <ue081723@gmail.com>
---
 drivers/acpi/acpi_platform.c | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
index abdd8893e..29b197440 100644
--- a/drivers/acpi/acpi_platform.c
+++ b/drivers/acpi/acpi_platform.c
@@ -85,7 +85,13 @@ static unsigned int acpi_platform_adjust_resources(struct acpi_device *adev,
 	for (i = 0; i < count; ) {
 		struct resource *res = &resources[i];
 
-		if (resource_type(new_res) != resource_type(res) ||
+		/*
+		 * Look for overlaps of resources of the same type that would
+		 * cause resource insertion to fail down the road.
+		 */
+		if (resource_contains(res, new_res) ||
+		    resource_contains(new_res, res) ||
+		    resource_type(new_res) != resource_type(res) ||
 		    !resource_union(new_res, res, new_res)) {
 			i++;
 			continue;
-- 
2.53.0