From: "Rafael J. Wysocki" <rafael@kernel.org>
To: Linux ACPI <linux-acpi@vger.kernel.org>
Cc: "Linux PM" <linux-pm@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"Peixin Xie" <peixin.xie@linux.spacemit.com>,
"Sakari Ailus" <sakari.ailus@linux.intel.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Linux PCI" <linux-pci@vger.kernel.org>,
"Bjorn Helgaas" <helgaas@kernel.org>,
"Hans de Goede" <hansg@kernel.org>,
"Andy Shevchenko" <andriy.shevchenko@linux.intel.com>
Subject: [PATCH v1 5/7] ACPI: scan: Add ACPI device "enumerated" marker
Date: Mon, 31 Aug 2026 19:59:38 +0200 [thread overview]
Message-ID: <48339705.fMDQidcC6G@rafael.j.wysocki> (raw)
In-Reply-To: <3435655.aeNJFYEL58@rafael.j.wysocki>
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Currently, the "visited" flag of ACPI device objects has two roles.
One of them is to indicate that the given ACPI device object has been
enumerated, which basically means that either it has been associated
with a "physical" device representation, or there is no matching
"physical" device representation for it. The other one is to
indicate that acpi_bus_attach() has processed the device. That dual
purpose leads to some confusion regarding when that flag should be set
and cleared and by whom.
To address that confusion, add a new bool field called "enumerated"
to struct acpi_device for the purpose of indicating whether or not
the given ACPI device object has been enumerated. Accordingly, switch
over acpi_device_enumerated() and acpi_device_set/clear_enumerated() to
operate on that field and the "visited" flag will now be only used
internally by the core ACPI device enumeration code.
Namely, acpi_bus_attach() will set flags.visited for a given ACPI
device object after it has been completely processed by that function
and regardless of its current status it needs to be "unattached", for
example by acpi_scan_check_and_detach(), so that acpi_bus_attach() can
process it again.
The rule regarding flags.visited and the "enumerated" field is that the
latter cannot be set until the former has been set and they need to be
cleared in reverse order.
This allows a couple of checks to be dropped from acpi_bus_attach()
and its first_pass argument is not needed any more.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
drivers/acpi/scan.c | 28 +++++++++++++---------------
include/acpi/acpi_bus.h | 3 ++-
include/linux/acpi.h | 4 ++--
3 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 8c5a2fcef582..153c66ca9217 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -266,8 +266,8 @@ static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
if (acpi_device_is_enabled(adev))
return 0;
- /* Skip device that have not been enumerated. */
- if (!acpi_device_enumerated(adev)) {
+ /* Skip device that have not been prepared for enumeration. */
+ if (!adev->flags.visited) {
dev_dbg(&adev->dev, "Still not enumerated\n");
return 0;
}
@@ -286,6 +286,7 @@ static int acpi_scan_check_and_detach(struct acpi_device *adev, void *p)
if (!(flags & ACPI_SCAN_CHECK_FLAG_EJECT)) {
adev->handler = NULL;
acpi_device_clear_enumerated(adev);
+ adev->flags.visited = 0;
}
return 0;
}
@@ -304,6 +305,7 @@ static int acpi_bus_post_eject(struct acpi_device *adev, void *not_used)
}
acpi_device_clear_enumerated(adev);
+ adev->flags.visited = 0;
return 0;
}
@@ -2336,26 +2338,23 @@ static int acpi_scan_attach_handler(struct acpi_device *device)
return ret;
}
-static int acpi_bus_attach(struct acpi_device *device, void *first_pass)
+static int acpi_bus_attach(struct acpi_device *device, void *not_used)
{
- bool skip = !first_pass && device->flags.visited;
acpi_handle ejd;
+ bool skip;
int ret;
+ skip = !!device->flags.visited;
if (skip)
- goto ok;
+ goto children;
if (ACPI_SUCCESS(acpi_bus_get_ejd(device->handle, &ejd)))
register_dock_dependent_device(device, ejd);
acpi_bus_get_status(device);
/* Skip devices that are not ready for enumeration (e.g. not present) */
- if (!acpi_dev_ready_for_enumeration(device)) {
- acpi_device_clear_enumerated(device);
+ if (!acpi_dev_ready_for_enumeration(device))
return 0;
- }
- if (device->handler)
- goto ok;
acpi_ec_register_opregions(device);
@@ -2363,21 +2362,20 @@ static int acpi_bus_attach(struct acpi_device *device, void *first_pass)
device->power.state == ACPI_STATE_UNKNOWN)
acpi_device_init_power(device);
- if (device->flags.visited)
- goto ok;
-
ret = acpi_scan_attach_handler(device);
if (ret < 0)
return 0;
+ device->flags.visited = 1;
+
if (!device->flags.enumeration_by_parent && (ret > 0 ||
(!device->pnp.type.platform_id && !device->pnp.type.backlight)))
acpi_device_set_enumerated(device);
else
acpi_default_enumeration(device);
-ok:
- acpi_dev_for_each_child(device, acpi_bus_attach, first_pass);
+children:
+ acpi_dev_for_each_child(device, acpi_bus_attach, NULL);
if (!skip && device->handler && device->handler->hotplug.notify_online)
device->handler->hotplug.notify_online(device);
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index 596fbd748e88..4392e3d6cd7a 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -467,6 +467,7 @@ struct acpi_device {
struct list_head physical_node_list;
struct mutex physical_node_lock;
void (*remove)(struct acpi_device *);
+ bool enumerated;
};
/* Non-device subnode */
@@ -653,7 +654,7 @@ void acpi_set_modalias(struct acpi_device *adev, const char *default_id,
static inline bool acpi_device_enumerated(struct acpi_device *adev)
{
- return adev && adev->flags.visited;
+ return adev && adev->enumerated;
}
/*
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index ddacac812094..2e9e49e2e665 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -782,12 +782,12 @@ struct platform_device *acpi_create_platform_device(struct acpi_device *,
static inline void acpi_device_set_enumerated(struct acpi_device *adev)
{
- adev->flags.visited = true;
+ adev->enumerated = true;
}
static inline void acpi_device_clear_enumerated(struct acpi_device *adev)
{
- adev->flags.visited = false;
+ adev->enumerated = false;
}
enum acpi_reconfig_event {
--
2.51.0
next prev parent reply other threads:[~2026-08-31 18:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 16:20 [PATCH v1 0/7] ACPI: scan: Address power management initialization and PCI devices handling Rafael J. Wysocki
2026-08-31 16:24 ` [PATCH v1 1/7] ACPI: scan: Stop calling acpi_bus_init_power() early Rafael J. Wysocki
2026-08-31 20:14 ` sashiko-bot
2026-09-01 17:31 ` Rafael J. Wysocki (Intel)
2026-09-01 8:27 ` Andy Shevchenko
2026-08-31 16:25 ` [PATCH v1 2/7] ACPI: PM: Introduce acpi_device_init_power() Rafael J. Wysocki
2026-08-31 20:25 ` sashiko-bot
2026-09-01 8:29 ` Andy Shevchenko
2026-09-01 16:38 ` Rafael J. Wysocki (Intel)
2026-08-31 17:59 ` [PATCH v1 3/7] ACPI: bus: Drop initialized flag from struct acpi_device_flags Rafael J. Wysocki
2026-08-31 21:03 ` sashiko-bot
2026-08-31 17:59 ` [PATCH v1 4/7] ACPI: scan: Combine two conditionals in acpi_bus_attach() Rafael J. Wysocki
2026-08-31 21:05 ` sashiko-bot
2026-09-01 8:40 ` Andy Shevchenko
2026-09-01 19:11 ` Rafael J. Wysocki (Intel)
2026-08-31 17:59 ` Rafael J. Wysocki [this message]
2026-08-31 21:14 ` [PATCH v1 5/7] ACPI: scan: Add ACPI device "enumerated" marker sashiko-bot
2026-08-31 17:59 ` [PATCH v1 6/7] ACPI: scan: Adjust and rename acpi_bus_attach() Rafael J. Wysocki
2026-08-31 21:17 ` sashiko-bot
2026-08-31 17:59 ` [PATCH v1 7/7] ACPI: scan: Take PCI device enumeration into account directly Rafael J. Wysocki
2026-08-31 21:23 ` sashiko-bot
2026-09-01 8:44 ` Andy Shevchenko
2026-09-01 19:14 ` Rafael J. Wysocki (Intel)
2026-09-02 12:42 ` [PATCH v1 0/7] ACPI: scan: Address power management initialization and PCI devices handling Peixin Xie
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=48339705.fMDQidcC6G@rafael.j.wysocki \
--to=rafael@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=hansg@kernel.org \
--cc=helgaas@kernel.org \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mika.westerberg@linux.intel.com \
--cc=peixin.xie@linux.spacemit.com \
--cc=sakari.ailus@linux.intel.com \
/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