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 v2 1/6] ACPI: PM: Drop parent state update from acpi_device_get_power()
Date: Wed, 02 Sep 2026 21:24:43 +0200 [thread overview]
Message-ID: <2292173.irdbgypaU6@rafael.j.wysocki> (raw)
In-Reply-To: <5144065.31r3eYUQgx@rafael.j.wysocki>
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
The parent state update in acpi_device_get_power(), that occurs when the
child device turns out to be in D0 and the parent's power state is still
unknown, is highly questionable because it may cause the reference
counters of the power resources used by the parent in D0 (if any) to
underflow when the parent goes into a low-power state later. Moreover,
there is no reason to do it on reads from the real_power_state sysfs
attribute of the child.
That check had been added by commit 8f7412a792bc ("ACPI / PM: Infer
parent power state from child if unknown, v2") before starting to
handle the "missing _PSC and no power resources" case directly in
acpi_bus_init_power(), as of commit b3785492268f ("ACPI / PM: Do not
power manage devices in unknown initial states"). It is not necessary
any more and commit b3785492268f should have removed it.
Drop it now.
Fixes: b3785492268f ("ACPI / PM: Do not power manage devices in unknown initial states")
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
New patch in v2.
---
drivers/acpi/device_pm.c | 15 ++-------------
1 file changed, 2 insertions(+), 13 deletions(-)
diff --git a/drivers/acpi/device_pm.c b/drivers/acpi/device_pm.c
index aa55ecfc2923..4269735aadde 100644
--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -75,15 +75,14 @@ static int acpi_dev_pm_explicit_get(struct acpi_device *device, int *state)
int acpi_device_get_power(struct acpi_device *device, int *state)
{
int result = ACPI_STATE_UNKNOWN;
- struct acpi_device *parent;
int error;
if (!device || !state)
return -EINVAL;
- parent = acpi_dev_parent(device);
-
if (!device->flags.power_manageable) {
+ struct acpi_device *parent = acpi_dev_parent(device);
+
/* TBD: Non-recursive algorithm for walking up hierarchy. */
*state = parent ? parent->power.state : ACPI_STATE_D0;
goto out;
@@ -119,16 +118,6 @@ int acpi_device_get_power(struct acpi_device *device, int *state)
result = psc > ACPI_STATE_D2 ? ACPI_STATE_D3_HOT : psc;
}
- /*
- * If we were unsure about the device parent's power state up to this
- * point, the fact that the device is in D0 implies that the parent has
- * to be in D0 too, except if ignore_parent is set.
- */
- if (!device->power.flags.ignore_parent && parent &&
- parent->power.state == ACPI_STATE_UNKNOWN &&
- result == ACPI_STATE_D0)
- parent->power.state = ACPI_STATE_D0;
-
*state = result;
out:
--
2.51.0
next prev parent reply other threads:[~2026-09-02 19:37 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 19:21 [PATCH v2 0/6] ACPI: scan: Adjust power management initialization and PCI devices handling Rafael J. Wysocki
2026-09-02 19:24 ` Rafael J. Wysocki [this message]
2026-09-02 19:26 ` [PATCH v2 2/6] ACPI: scan: Stop calling acpi_bus_init_power() early Rafael J. Wysocki
2026-09-02 19:30 ` [PATCH v2 3/6] ACPI: scan: Combine two conditionals in acpi_bus_attach() Rafael J. Wysocki
2026-09-03 7:27 ` Andy Shevchenko
2026-09-02 19:33 ` [PATCH v2 4/6] ACPI: scan: Add ACPI device enumerated marker Rafael J. Wysocki
2026-09-02 19:35 ` [PATCH v2 5/6] ACPI: scan: Adjust and rename acpi_bus_attach() Rafael J. Wysocki
2026-09-02 19:36 ` [PATCH v2 6/6] ACPI: scan: Take PCI device enumeration into account directly Rafael J. Wysocki
2026-09-03 8:12 ` Andy Shevchenko
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=2292173.irdbgypaU6@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