[PATCH v3 0/9] PM: Reconcile different driver options for runtime PM integration with system sleep

[PATCH v3 0/9] PM: Reconcile different driver options for runtime PM integration with system sleep

[Rafael J. Wysocki]

Hi Everyone,

This is an update of the series the v2 of which was posted yesterday:

https://lore.kernel.org/linux-pm/5015172.GXAFRqVoOG@rjwysocki.net/

and the v1 is here:

https://lore.kernel.org/linux-pm/22759968.EfDdHjke4D@rjwysocki.net/

This update reorders the patches (again), updates the changelogs of some of
them and changes the subject of one patch slightly.  It also adds a kerneldoc
comment to a new function in patch [5/9].

This part of the cover letter still applies:

"This series addresses a couple of issues related to the integration of runtime
PM with system sleep I was talking about at the OSMP-summit 2025:

https://lwn.net/Articles/1021332/

Most importantly, DPM_FLAG_SMART_SUSPEND cannot be used along with
pm_runtime_force_suspend/resume() due to some conflicting expectations
about the handling of device runtime PM status between these functions
and the PM core.

Also pm_runtime_force_suspend/resume() currently cannot be used in PCI
drivers and in drivers that collaborate with the general ACPI PM domain
because they both don't expect their mid-layer runtime PM callbacks to
be invoked during system-wide suspend and resume.

Patch [1/9] is a preparatory cleanup changing the code to use 'true' and
'false' as needs_force_resume flag values for consistency."

Patch [2/9] (which was [3/9] in v2) puts pm_runtime_force_resume() and one
other function that is only used during system sleep transitions under
CONFIG_PM_SLEEP.

Patch [3/9] (which was [5/9] in v2) causes the smart_suspend flag to be taken
into account by pm_runtime_force_resume() which allows it to resume devices
with smart_suspend set whose runtime PM status has been changed to RPM_ACTIVE
by the PM core at the beginning of system resume.  After this patch, drivers
that use pm_runtime_force_suspend/resume() can also set DPM_FLAG_SMART_SUSPEND
which may be useful, for example, if devices handled by them are involved in
dependency chains with other devices setting DPM_FLAG_SMART_SUSPEND.

Since patches [1,3/9] have been reviewed already and patch [2/9] should not
be particularly controversial, I think that patches [1-3/9] are good to go.

Patch [4/9] (which was [2/9] in v2), makes pm_runtime_reinit() clear
needs_force_resume in case it was set during driver remove.

Patch [5/9] (which was [4/9] in v2) makes pm_runtime_force_suspend() check
needs_force_resume along with the device's runtime PM status upfront, and bail
out if it is set, which allows runtime PM status updates to be eliminated from
both that function and pm_runtime_force_resume().  I recalled too late that
it was actually necessary for the PCI PM and ACPI PM to work with
pm_runtime_force_suspend() correctly after the subsequent changes and that
patch [3/9] did not depend on it.  I have also realized that patch [5/9]
potentially unbreaks drivers that call pm_runtime_force_suspend() from their
"remove" callbacks (see the patch changelog for a bit of an explanation).

Patch [6/9] (which has not been changed since v2) makes the code for getting a
runtime PM callback for a device a bit more straightforward, in preparation for
the subsequent changes.

Patch [7/9] introduces a new device PM flag called strict_midlayer that
can be set by middle layer code which doesn't want its runtime PM
callbacks to be used during system-wide PM transitions, like the PCI bus
type and the ACPI PM domain, and updates pm_runtime_force_suspend/resume()
to take that flag into account.  Its changelog has been updated since v2 and
there is a new kerneldoc comment for dev_pm_set_strict_midlayer().

Patch [8/9] modifies the ACPI PM "prepare" and "complete" callback functions,
used by the general ACPI PM domain and by the ACPI LPSS PM domain, to set and
clear strict_midlayer, respectively, which allows drivers collaborating with it
to use pm_runtime_force_suspend/resume().  The changelog of this patch has been
made a bit more precise since v2.

That may be useful if such a driver wants to be able to work with different
PM domains on different systems.  It may want to work with the general ACPI PM
domain on systems using ACPI, or with another PM domain (or even multiple PM
domains at the same time) on systems without ACPI, and it may want to use
pm_runtime_force_suspend/resume() as its system-wide PM callbacks.

Patch [9/9] updates the PCI bus type to set and clear, respectively, strict_midlayer
for all PCI devices in its "prepare" and "complete" PM callbacks, in case some
PCI drivers want to use pm_runtime_force_suspend/resume() in the future.  They
will still need to set DPM_FLAG_SMART_SUSPEND to avoid resuming their devices during
system suspend, but now they may also use pm_runtime_force_suspend/resume() as
suspend callbacks for the "regular suspend" phase of device suspend (or invoke
these functions from their suspend callbacks).  The changelog of this patch has
been made a bit more precise since v2, like the changelog of patch [8/9].

As usual, please refer to individual patch changelogs for more details.

Thanks!

[PATCH v3 1/9] PM: Use true/false as power.needs_force_resume values

[Rafael J. Wysocki]

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

Since power.needs_force_resume is a bool field, use true/false
as its values instead of 1/0, respectively.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
---

v2 -> v3: No changes.

v1 -> v2: Added R-by from Ulf.

---
 drivers/base/power/runtime.c |    6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1827,7 +1827,7 @@
 	dev->power.request_pending = false;
 	dev->power.request = RPM_REQ_NONE;
 	dev->power.deferred_resume = false;
-	dev->power.needs_force_resume = 0;
+	dev->power.needs_force_resume = false;
 	INIT_WORK(&dev->power.work, pm_runtime_work);
 
 	dev->power.timer_expires = 0;
@@ -1997,7 +1997,7 @@
 		pm_runtime_set_suspended(dev);
 	} else {
 		__update_runtime_status(dev, RPM_SUSPENDED);
-		dev->power.needs_force_resume = 1;
+		dev->power.needs_force_resume = true;
 	}
 
 	return 0;
@@ -2047,7 +2047,7 @@
 
 	pm_runtime_mark_last_busy(dev);
 out:
-	dev->power.needs_force_resume = 0;
+	dev->power.needs_force_resume = false;
 	pm_runtime_enable(dev);
 	return ret;
 }

[PATCH v3 2/9] PM: Move two sleep-related functions under CONFIG_PM_SLEEP

[Rafael J. Wysocki]

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

Since pm_runtime_force_resume() and pm_runtime_need_not_resume() are only
needed for handling system-wide PM transitions, there is no reason to
compile them in if CONFIG_PM_SLEEP is unset.

Accordingly, move them under CONFIG_PM_SLEEP and make the static
inline stub for pm_runtime_force_resume() return an error to indicate
that it should not be used outside CONFIG_PM_SLEEP.

Putting pm_runtime_force_resume() also allows subsequent changes to
be more straightforward because this function is going to access a
device PM flag that is only defined when CONFIG_PM_SLEEP is set.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v2 -> v3: Reorder (previosly it was patch [3/9].

v1 -> v2:
   * Keep pm_runtime_force_suspend() under CONFIG_PM (Ulf).
   * Update changelog.
   * Corresponds to patch [4/9] in v1.

---
 drivers/base/power/runtime.c |   18 +++++++++++-------
 include/linux/pm_runtime.h   |   16 ++++++++++++----
 2 files changed, 23 insertions(+), 11 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1946,13 +1946,6 @@
 	pm_request_idle(link->supplier);
 }
 
-bool pm_runtime_need_not_resume(struct device *dev)
-{
-	return atomic_read(&dev->power.usage_count) <= 1 &&
-		(atomic_read(&dev->power.child_count) == 0 ||
-		 dev->power.ignore_children);
-}
-
 /**
  * pm_runtime_force_suspend - Force a device into suspend state if needed.
  * @dev: Device to suspend.
@@ -2014,6 +2007,8 @@
 }
 EXPORT_SYMBOL_GPL(pm_runtime_force_suspend);
 
+#ifdef CONFIG_PM_SLEEP
+
 /**
  * pm_runtime_force_resume - Force a device into resume state if needed.
  * @dev: Device to resume.
@@ -2057,3 +2052,12 @@
 	return ret;
 }
 EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
+
+bool pm_runtime_need_not_resume(struct device *dev)
+{
+	return atomic_read(&dev->power.usage_count) <= 1 &&
+		(atomic_read(&dev->power.child_count) == 0 ||
+		 dev->power.ignore_children);
+}
+
+#endif /* CONFIG_PM_SLEEP */
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -66,9 +66,7 @@
 
 extern int pm_generic_runtime_suspend(struct device *dev);
 extern int pm_generic_runtime_resume(struct device *dev);
-extern bool pm_runtime_need_not_resume(struct device *dev);
 extern int pm_runtime_force_suspend(struct device *dev);
-extern int pm_runtime_force_resume(struct device *dev);
 
 extern int __pm_runtime_idle(struct device *dev, int rpmflags);
 extern int __pm_runtime_suspend(struct device *dev, int rpmflags);
@@ -257,9 +255,7 @@
 
 static inline int pm_generic_runtime_suspend(struct device *dev) { return 0; }
 static inline int pm_generic_runtime_resume(struct device *dev) { return 0; }
-static inline bool pm_runtime_need_not_resume(struct device *dev) {return true; }
 static inline int pm_runtime_force_suspend(struct device *dev) { return 0; }
-static inline int pm_runtime_force_resume(struct device *dev) { return 0; }
 
 static inline int __pm_runtime_idle(struct device *dev, int rpmflags)
 {
@@ -330,6 +326,18 @@
 
 #endif /* !CONFIG_PM */
 
+#ifdef CONFIG_PM_SLEEP
+
+bool pm_runtime_need_not_resume(struct device *dev);
+int pm_runtime_force_resume(struct device *dev);
+
+#else /* !CONFIG_PM_SLEEP */
+
+static inline bool pm_runtime_need_not_resume(struct device *dev) {return true; }
+static inline int pm_runtime_force_resume(struct device *dev) { return -ENXIO; }
+
+#endif /* CONFIG_PM_SLEEP */
+
 /**
  * pm_runtime_idle - Conditionally set up autosuspend of a device or suspend it.
  * @dev: Target device.

[PATCH v3 3/9] PM: Make pm_runtime_force_resume() work with DPM_FLAG_SMART_SUSPEND

[Rafael J. Wysocki]

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

Curently, drivers using pm_runtime_force_suspend/resume() cannot set
DPM_FLAG_SMART_SUSPEND because the devices with that flag set may need
to be resumed during system-wide resume regardless of whether or not
they have power.needs_force_resume set.  That can happen due to a
dependency resolved at the beginning of a system-wide resume transition
(for instance, a bus type or PM domain has decided to resume a
subordinate device with DPM_FLAG_SMART_SUSPEND and its parent and
suppliers also need to be resumed).

To overcome this limitation, modify pm_runtime_force_resume() to check
the device's power.smart_suspend flag (which is set for devices with
DPM_FLAG_SMART_SUSPEND set that meet some additional requirements) and
the device's runtime PM status in addition to power.needs_force_resume.
Also change it to clear power.smart_suspend to ensure that it will not
handle the same device twice during one transition.

The underlying observation is that there are two cases in which the
device needs to be resumed by pm_runtime_force_resume().  One of them
is when the device has power.needs_force_resume set, which means that
pm_runtime_force_suspend() has suspended it and decided that it should
be resumed during the subsequent system resume.  The other one is when
power.smart_suspend is set and the device's runtume PM status is
RPM_ACTIVE.

Update kerneldoc comments in accordance with the code changes.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
---

v2 -> v3: Reorder (it was patch [5/9] in v2).

v1 -> v2:
   * Added R-by from Ulf.
   * Corresponds to patch [3/9] in v1.

---
 drivers/base/power/runtime.c |   38 +++++++++++++++++++++++++++-----------
 1 file changed, 27 insertions(+), 11 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1957,10 +1957,6 @@
  * sure the device is put into low power state and it should only be used during
  * system-wide PM transitions to sleep states.  It assumes that the analogous
  * pm_runtime_force_resume() will be used to resume the device.
- *
- * Do not use with DPM_FLAG_SMART_SUSPEND as this can lead to an inconsistent
- * state where this function has called the ->runtime_suspend callback but the
- * PM core marks the driver as runtime active.
  */
 int pm_runtime_force_suspend(struct device *dev)
 {
@@ -2008,20 +2004,28 @@
  * pm_runtime_force_resume - Force a device into resume state if needed.
  * @dev: Device to resume.
  *
- * Prior invoking this function we expect the user to have brought the device
- * into low power state by a call to pm_runtime_force_suspend(). Here we reverse
- * those actions and bring the device into full power, if it is expected to be
- * used on system resume.  In the other case, we defer the resume to be managed
- * via runtime PM.
+ * This function expects that either pm_runtime_force_suspend() has put the
+ * device into a low-power state prior to calling it, or the device had been
+ * runtime-suspended before the preceding system-wide suspend transition and it
+ * was left in suspend during that transition.
+ *
+ * The actions carried out by pm_runtime_force_suspend(), or by a runtime
+ * suspend in general, are reversed and the device is brought back into full
+ * power if it is expected to be used on system resume, which is the case when
+ * its needs_force_resume flag is set or when its smart_suspend flag is set and
+ * its runtime PM status is "active".
+ *
+ * In other cases, the resume is deferred to be managed via runtime PM.
  *
- * Typically this function may be invoked from a system resume callback.
+ * Typically, this function may be invoked from a system resume callback.
  */
 int pm_runtime_force_resume(struct device *dev)
 {
 	int (*callback)(struct device *);
 	int ret = 0;
 
-	if (!dev->power.needs_force_resume)
+	if (!dev->power.needs_force_resume && (!dev_pm_smart_suspend(dev) ||
+	    pm_runtime_status_suspended(dev)))
 		goto out;
 
 	/*
@@ -2041,8 +2045,20 @@
 	}
 
 	pm_runtime_mark_last_busy(dev);
+
 out:
+	/*
+	 * The smart_suspend flag can be cleared here because it is not going
+	 * to be necessary until the next system-wide suspend transition that
+	 * will update it again.
+	 */
+	dev->power.smart_suspend = false;
+	/*
+	 * Also clear needs_force_resume to make this function skip devices that
+	 * have been seen by it once.
+	 */
 	dev->power.needs_force_resume = false;
+
 	pm_runtime_enable(dev);
 	return ret;
 }

[PATCH v3 4/9] PM: runtime: Clear power.needs_force_resume in pm_runtime_reinit()

[Rafael J. Wysocki]

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

Clear power.needs_force_resume in pm_runtime_reinit() in case it has
been set by pm_runtime_force_suspend() invoked from a driver remove
callback.

Suggested-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v2 -> v3: Reorder (it was [2/9] previously).

v1 -> v2: New patch.

---
 drivers/base/power/runtime.c |    5 +++++
 1 file changed, 5 insertions(+)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1854,6 +1854,11 @@
 				pm_runtime_put(dev->parent);
 		}
 	}
+	/*
+	 * Clear power.needs_force_resume in case it has been set by
+	 * pm_runtime_force_suspend() invoked from a driver remove callback.
+	 */
+	dev->power.needs_force_resume = false;
 }
 
 /**

[PATCH v3 5/9] PM: Check power.needs_force_resume in pm_runtime_force_suspend()

[Rafael J. Wysocki]

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

Add a power.needs_force_resume check to pm_runtime_force_suspend() so
it need not rely on the runtime PM status of the device when deciding
whether or not to return early.

With the new check in place, pm_runtime_force_suspend() will also skip
devices with the runtime PM status equal to RPM_ACTIVE if they have
power.needs_force_resume set, so it won't need to change the RPM
status of the device to RPM_SUSPENDED in addition to setting
power.needs_force_resume in the case when pm_runtime_need_not_resume()
return false.

That allows the runtime PM status update to be removed from
pm_runtime_force_resume(), so the runtime PM status remains unchanged
between the pm_runtime_force_suspend() and pm_runtime_force_resume()
calls.

This change potentially unbreaks drivers that call pm_runtime_force_suspend()
from their ->remove() callbacks because currently, if the device being
unbound from its driver has a parent with enabled runtime PM and/or
(possibly) device links respecting runtime PM to suppliers, and it is
RPM_ACTIVE when the remove takes place, pm_runtime_force_suspend() will
not drop the parent's child count and the suppliers' runtime PM usage
counters after force-suspending the device unless pm_runtime_need_not_resume()
returns 'true' for it.  Moreover, because pm_runtime_force_suspend()
changes the device's runtime PM status to RPM_SUSPENDED, in the above
case pm_runtime_reinit() will not cause those counters to drop, so they
will remain nonzero forever effectively preventing the devices in
question from runtime-suspending going forward.

This change is also needed for pm_runtime_force_suspend() to work
with PCI PM and ACPI PM after subsequent changes.  Namely, say
DPM_FLAG_SMART_SUSPEND is set for a PCI device and its driver uses
pm_runtime_force_suspend() as its ->suspend() callback.  If
pm_runtime_force_suspend() changed the runtime PM status of the
device to RPM_SUSPENDED, pci_pm_suspend_noirq() would skip the
device due to the dev_pm_skip_suspend() check.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v2 -> v3:
   * Update changelog (explanation why it potentially unbreaks some drivers and
     why the subsequent changes depend on it).
   * Reorder (it was [4/9] previously).

v1 -> v2: Corresponds to patch [2/9] (that was posted as [0/9] by mistake) in v1.

---
 drivers/base/power/runtime.c |   21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1969,7 +1969,7 @@
 	int ret;
 
 	pm_runtime_disable(dev);
-	if (pm_runtime_status_suspended(dev))
+	if (pm_runtime_status_suspended(dev) || dev->power.needs_force_resume)
 		return 0;
 
 	callback = RPM_GET_CALLBACK(dev, runtime_suspend);
@@ -1984,15 +1984,16 @@
 	/*
 	 * If the device can stay in suspend after the system-wide transition
 	 * to the working state that will follow, drop the children counter of
-	 * its parent, but set its status to RPM_SUSPENDED anyway in case this
-	 * function will be called again for it in the meantime.
+	 * its parent and the usage counters of its suppliers.  Otherwise, set
+	 * power.needs_force_resume to let pm_runtime_force_resume() know that
+	 * the device needs to be taken care of and to prevent this function
+	 * from handling the device again in case the device is passed to it
+	 * once more subsequently.
 	 */
-	if (pm_runtime_need_not_resume(dev)) {
+	if (pm_runtime_need_not_resume(dev))
 		pm_runtime_set_suspended(dev);
-	} else {
-		__update_runtime_status(dev, RPM_SUSPENDED);
+	else
 		dev->power.needs_force_resume = true;
-	}
 
 	return 0;
 
@@ -2033,12 +2034,6 @@
 	    pm_runtime_status_suspended(dev)))
 		goto out;
 
-	/*
-	 * The value of the parent's children counter is correct already, so
-	 * just update the status of the device.
-	 */
-	__update_runtime_status(dev, RPM_ACTIVE);
-
 	callback = RPM_GET_CALLBACK(dev, runtime_resume);
 
 	dev_pm_disable_wake_irq_check(dev, false);

[PATCH v3 6/9] PM: runtime: Introduce __rpm_get_driver_callback()

[Rafael J. Wysocki]

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

Add a special function for computing the address of the runtime PM
callback given by an offset relative to the start of the device
driver's struct dev_pm_ops and use it to obtain the driver callback
in __rpm_get_callback().

Also put the shared part of the callback address computation into a
separate helper function to avoid code duplication and explicit
pointer type casts.

The new __rpm_get_driver_callback() will be used subsequently for
implementing callback lookup in pm_runtime_force_suspend/resume().

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v2 -> v3: No changes.

v1 -> v2: New patch (not actually posted in v1 by mistake).

---
 drivers/base/power/runtime.c |   24 ++++++++++++++++++------
 1 file changed, 18 insertions(+), 6 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -19,10 +19,24 @@
 
 typedef int (*pm_callback_t)(struct device *);
 
+static inline pm_callback_t get_callback_ptr(const void *start, size_t offset)
+{
+	return *(pm_callback_t *)(start + offset);
+}
+
+static pm_callback_t __rpm_get_driver_callback(struct device *dev,
+					       size_t cb_offset)
+{
+	if (dev->driver && dev->driver->pm)
+		return get_callback_ptr(dev->driver->pm, cb_offset);
+
+	return NULL;
+}
+
 static pm_callback_t __rpm_get_callback(struct device *dev, size_t cb_offset)
 {
-	pm_callback_t cb;
 	const struct dev_pm_ops *ops;
+	pm_callback_t cb = NULL;
 
 	if (dev->pm_domain)
 		ops = &dev->pm_domain->ops;
@@ -36,12 +50,10 @@
 		ops = NULL;
 
 	if (ops)
-		cb = *(pm_callback_t *)((void *)ops + cb_offset);
-	else
-		cb = NULL;
+		cb = get_callback_ptr(ops, cb_offset);
 
-	if (!cb && dev->driver && dev->driver->pm)
-		cb = *(pm_callback_t *)((void *)dev->driver->pm + cb_offset);
+	if (!cb)
+		cb = __rpm_get_driver_callback(dev, cb_offset);
 
 	return cb;
 }

[PATCH v3 7/9] PM: sleep: Add strict_midlayer flag to struct dev_pm_info

[Rafael J. Wysocki]

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

Add a new flag, called strict_midlayer, to struct dev_pm_info, along
with helper functions for updating and reading its value, to allow
middle layer code that provides proper callbacks for device suspend-
resume during system-wide PM transitions to let pm_runtime_force_suspend()
and and pm_runtime_force_resume() know that they should only invoke
runtime PM callbacks coming from the device's driver.

Namely, if this flag is set, pm_runtime_force_suspend() and
and pm_runtime_force_resume() will invoke runtime PM callbacks
provided by the device's driver directly with the assumption that
they have been called via a middle layer callback for device suspend
or resume, respectively.

For instance, acpi_general_pm_domain provides specific
callback functions for system suspend, acpi_subsys_suspend(),
acpi_subsys_suspend_late() and acpi_subsys_suspend_noirq(), and
it does not expect its runtime suspend callback function,
acpi_subsys_runtime_suspend(), to be invoked at any point during
system suspend. In particular, it does not expect that function
to be called from within any of the system suspend callback functions
mentioned above which would happen if a device driver collaborating
with acpi_general_pm_domain used pm_runtime_force_suspend() as its
callback function for any system suspend phase later than "prepare".

The new flag allows this expectation of acpi_general_pm_domain to
be formally expressed, which is going to be done subsequently.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v2 -> v3:
   * Add a kerneldoc comment for dev_pm_set_strict_midlayer() (Bjorn).
   * Update changelog (minor tweaks).

v1 -> v2:
   * Rename dev_pm_strict_midlayer() to dev_pm_set_strict_midlayer().
   * Add dev_pm_strict_midlayer_is_set() and use it in get_callback()
     because pm_runtime_force_suspend() can be used in driver remove
     callbacks and so it needs to work with CONFIG_PM_SLEEP unset.

---
 drivers/base/power/runtime.c |   21 +++++++++++++++++++--
 include/linux/device.h       |   27 +++++++++++++++++++++++++++
 include/linux/pm.h           |    1 +
 3 files changed, 47 insertions(+), 2 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1958,6 +1958,23 @@
 	pm_request_idle(link->supplier);
 }
 
+static pm_callback_t get_callback(struct device *dev, size_t cb_offset)
+{
+	/*
+	 * Setting power.strict_midlayer means that the middle layer
+	 * code does not want its runtime PM callbacks to be invoked via
+	 * pm_runtime_force_suspend() and pm_runtime_force_resume(), so
+	 * return a direct pointer to the driver callback in that case.
+	 */
+	if (dev_pm_strict_midlayer_is_set(dev))
+		return __rpm_get_driver_callback(dev, cb_offset);
+
+	return __rpm_get_callback(dev, cb_offset);
+}
+
+#define GET_CALLBACK(dev, callback) \
+		get_callback(dev, offsetof(struct dev_pm_ops, callback))
+
 /**
  * pm_runtime_force_suspend - Force a device into suspend state if needed.
  * @dev: Device to suspend.
@@ -1984,7 +2001,7 @@
 	if (pm_runtime_status_suspended(dev) || dev->power.needs_force_resume)
 		return 0;
 
-	callback = RPM_GET_CALLBACK(dev, runtime_suspend);
+	callback = GET_CALLBACK(dev, runtime_suspend);
 
 	dev_pm_enable_wake_irq_check(dev, true);
 	ret = callback ? callback(dev) : 0;
@@ -2046,7 +2063,7 @@
 	    pm_runtime_status_suspended(dev)))
 		goto out;
 
-	callback = RPM_GET_CALLBACK(dev, runtime_resume);
+	callback = GET_CALLBACK(dev, runtime_resume);
 
 	dev_pm_disable_wake_irq_check(dev, false);
 	ret = callback ? callback(dev) : 0;
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -879,6 +879,33 @@
 #endif
 }
 
+/*
+ * dev_pm_set_strict_midlayer - Update the device's power.strict_midlayer flag
+ * @dev: Target device.
+ * @val: New flag value.
+ *
+ * When set, power.strict_midlayer means that the middle layer power management
+ * code (typically, a bus type or a PM domain) does not expect its runtime PM
+ * suspend callback to be invoked at all during system-wide PM transitions and
+ * it does not expect its runtime PM resume callback to be invoked at any point
+ * when runtime PM is disabled for the device during system-wide PM transitions.
+ */
+static inline void dev_pm_set_strict_midlayer(struct device *dev, bool val)
+{
+#ifdef CONFIG_PM_SLEEP
+	dev->power.strict_midlayer = val;
+#endif
+}
+
+static inline bool dev_pm_strict_midlayer_is_set(struct device *dev)
+{
+#ifdef CONFIG_PM_SLEEP
+	return dev->power.strict_midlayer;
+#else
+	return false;
+#endif
+}
+
 static inline void device_lock(struct device *dev)
 {
 	mutex_lock(&dev->mutex);
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -683,6 +683,7 @@
 	bool			smart_suspend:1;	/* Owned by the PM core */
 	bool			must_resume:1;		/* Owned by the PM core */
 	bool			may_skip_resume:1;	/* Set by subsystems */
+	bool			strict_midlayer:1;
 #else
 	bool			should_wakeup:1;
 #endif

[PATCH v3 8/9] ACPI: PM: Set/clear power.strict_midlayer in prepare/complete

[Rafael J. Wysocki]

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

The ACPI general PM domain and the LPSS PM domain do not expect their
mid-layer runtime PM suspend callbacks to be invoked at all during
system-wide suspend and resume and they do not expect their runtime
resume callbacks to be invoked at any point when runtime PM is disabled
for the given device during system suspend and resume, so make
acpi_subsys_prepare() set power.strict_midlayer for the given device
to express that expectation and make acpi_subsys_complete() clear it.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---

v2 -> v3: Update the changelog to be more precise.

v1 -> v2:
   * Set and clear the new flag in "prepare" and "complete" instead of
     "attach" and "detach", respectively, to (1) cover the LPSS PM domain as
     well as the general ACPI PM domain and (2) allow pm_runtime_force_suspend()
     invoked from driver remove callbacks to work.
   * Update subject and changelog.

---
 drivers/acpi/device_pm.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -1119,6 +1119,8 @@
 {
 	struct acpi_device *adev = ACPI_COMPANION(dev);
 
+	dev_pm_set_strict_midlayer(dev, true);
+
 	if (dev->driver && dev->driver->pm && dev->driver->pm->prepare) {
 		int ret = dev->driver->pm->prepare(dev);
 
@@ -1147,6 +1149,8 @@
 	 */
 	if (pm_runtime_suspended(dev) && pm_resume_via_firmware())
 		pm_request_resume(dev);
+
+	dev_pm_set_strict_midlayer(dev, false);
 }
 EXPORT_SYMBOL_GPL(acpi_subsys_complete);
 

[PATCH v3 9/9] PCI/PM: Set power.strict_midlayer in pci_pm_init()

[Rafael J. Wysocki]

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

The PCI bus type does not expect its runtime PM suspend callback
function, pci_pm_runtime_suspend(), to be invoked at all during system-
wide suspend and resume, and it does not expect its runtime resume
callback function, pci_pm_runtime_resume(), to be invoked at any point
when runtime PM is disabled for the given device during system-wide
suspend and resume, so make it express that expectation by setting
power.strict_midlayer for all PCI devices in pci_pm_prepare() and
clear it in pci_pm_complete().

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
---

v2 -> v3:
   * Update subject prefix (Bjorn).
   * Update the changelog to be more precise.
   * Add Acked-by from Bjorn.

v1 -> v2:
   * Set and clear the new flag in "prepare" and "complete" to allow
     pm_runtime_force_suspend() invoked from driver remove callbacks to
     work.
   * Update subject and changelog.

---
 drivers/pci/pci-driver.c |    4 ++++
 1 file changed, 4 insertions(+)

--- a/drivers/pci/pci-driver.c
+++ b/drivers/pci/pci-driver.c
@@ -708,6 +708,8 @@
 	struct pci_dev *pci_dev = to_pci_dev(dev);
 	const struct dev_pm_ops *pm = dev->driver ? dev->driver->pm : NULL;
 
+	dev_pm_set_strict_midlayer(dev, true);
+
 	if (pm && pm->prepare) {
 		int error = pm->prepare(dev);
 		if (error < 0)
@@ -749,6 +751,8 @@
 		if (pci_dev->current_state < pre_sleep_state)
 			pm_request_resume(dev);
 	}
+
+	dev_pm_set_strict_midlayer(dev, false);
 }
 
 #else /* !CONFIG_PM_SLEEP */

Re: [PATCH v3 0/9] PM: Reconcile different driver options for runtime PM integration with system sleep

[Ulf Hansson]

On Fri, 27 Jun 2025 at 21:29, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> Hi Everyone,
>
> This is an update of the series the v2 of which was posted yesterday:
>
> https://lore.kernel.org/linux-pm/5015172.GXAFRqVoOG@rjwysocki.net/
>
> and the v1 is here:
>
> https://lore.kernel.org/linux-pm/22759968.EfDdHjke4D@rjwysocki.net/
>
> This update reorders the patches (again), updates the changelogs of some of
> them and changes the subject of one patch slightly.  It also adds a kerneldoc
> comment to a new function in patch [5/9].
>
> This part of the cover letter still applies:
>
> "This series addresses a couple of issues related to the integration of runtime
> PM with system sleep I was talking about at the OSMP-summit 2025:
>
> https://lwn.net/Articles/1021332/
>
> Most importantly, DPM_FLAG_SMART_SUSPEND cannot be used along with
> pm_runtime_force_suspend/resume() due to some conflicting expectations
> about the handling of device runtime PM status between these functions
> and the PM core.
>
> Also pm_runtime_force_suspend/resume() currently cannot be used in PCI
> drivers and in drivers that collaborate with the general ACPI PM domain
> because they both don't expect their mid-layer runtime PM callbacks to
> be invoked during system-wide suspend and resume.
>
> Patch [1/9] is a preparatory cleanup changing the code to use 'true' and
> 'false' as needs_force_resume flag values for consistency."
>
> Patch [2/9] (which was [3/9] in v2) puts pm_runtime_force_resume() and one
> other function that is only used during system sleep transitions under
> CONFIG_PM_SLEEP.
>
> Patch [3/9] (which was [5/9] in v2) causes the smart_suspend flag to be taken
> into account by pm_runtime_force_resume() which allows it to resume devices
> with smart_suspend set whose runtime PM status has been changed to RPM_ACTIVE
> by the PM core at the beginning of system resume.  After this patch, drivers
> that use pm_runtime_force_suspend/resume() can also set DPM_FLAG_SMART_SUSPEND
> which may be useful, for example, if devices handled by them are involved in
> dependency chains with other devices setting DPM_FLAG_SMART_SUSPEND.
>
> Since patches [1,3/9] have been reviewed already and patch [2/9] should not
> be particularly controversial, I think that patches [1-3/9] are good to go.
>
> Patch [4/9] (which was [2/9] in v2), makes pm_runtime_reinit() clear
> needs_force_resume in case it was set during driver remove.
>
> Patch [5/9] (which was [4/9] in v2) makes pm_runtime_force_suspend() check
> needs_force_resume along with the device's runtime PM status upfront, and bail
> out if it is set, which allows runtime PM status updates to be eliminated from
> both that function and pm_runtime_force_resume().  I recalled too late that
> it was actually necessary for the PCI PM and ACPI PM to work with
> pm_runtime_force_suspend() correctly after the subsequent changes and that
> patch [3/9] did not depend on it.  I have also realized that patch [5/9]
> potentially unbreaks drivers that call pm_runtime_force_suspend() from their
> "remove" callbacks (see the patch changelog for a bit of an explanation).
>
> Patch [6/9] (which has not been changed since v2) makes the code for getting a
> runtime PM callback for a device a bit more straightforward, in preparation for
> the subsequent changes.
>
> Patch [7/9] introduces a new device PM flag called strict_midlayer that
> can be set by middle layer code which doesn't want its runtime PM
> callbacks to be used during system-wide PM transitions, like the PCI bus
> type and the ACPI PM domain, and updates pm_runtime_force_suspend/resume()
> to take that flag into account.  Its changelog has been updated since v2 and
> there is a new kerneldoc comment for dev_pm_set_strict_midlayer().
>
> Patch [8/9] modifies the ACPI PM "prepare" and "complete" callback functions,
> used by the general ACPI PM domain and by the ACPI LPSS PM domain, to set and
> clear strict_midlayer, respectively, which allows drivers collaborating with it
> to use pm_runtime_force_suspend/resume().  The changelog of this patch has been
> made a bit more precise since v2.
>
> That may be useful if such a driver wants to be able to work with different
> PM domains on different systems.  It may want to work with the general ACPI PM
> domain on systems using ACPI, or with another PM domain (or even multiple PM
> domains at the same time) on systems without ACPI, and it may want to use
> pm_runtime_force_suspend/resume() as its system-wide PM callbacks.
>
> Patch [9/9] updates the PCI bus type to set and clear, respectively, strict_midlayer
> for all PCI devices in its "prepare" and "complete" PM callbacks, in case some
> PCI drivers want to use pm_runtime_force_suspend/resume() in the future.  They
> will still need to set DPM_FLAG_SMART_SUSPEND to avoid resuming their devices during
> system suspend, but now they may also use pm_runtime_force_suspend/resume() as
> suspend callbacks for the "regular suspend" phase of device suspend (or invoke
> these functions from their suspend callbacks).  The changelog of this patch has
> been made a bit more precise since v2, like the changelog of patch [8/9].
>
> As usual, please refer to individual patch changelogs for more details.
>
> Thanks!
>

For the v3 series, please add:
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

Re: [PATCH v3 0/9] PM: Reconcile different driver options for runtime PM integration with system sleep

[Rafael J. Wysocki]

On Wed, Jul 2, 2025 at 4:12 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Fri, 27 Jun 2025 at 21:29, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > Hi Everyone,
> >
> > This is an update of the series the v2 of which was posted yesterday:
> >
> > https://lore.kernel.org/linux-pm/5015172.GXAFRqVoOG@rjwysocki.net/
> >
> > and the v1 is here:
> >
> > https://lore.kernel.org/linux-pm/22759968.EfDdHjke4D@rjwysocki.net/
> >
> > This update reorders the patches (again), updates the changelogs of some of
> > them and changes the subject of one patch slightly.  It also adds a kerneldoc
> > comment to a new function in patch [5/9].
> >
> > This part of the cover letter still applies:
> >
> > "This series addresses a couple of issues related to the integration of runtime
> > PM with system sleep I was talking about at the OSMP-summit 2025:
> >
> > https://lwn.net/Articles/1021332/
> >
> > Most importantly, DPM_FLAG_SMART_SUSPEND cannot be used along with
> > pm_runtime_force_suspend/resume() due to some conflicting expectations
> > about the handling of device runtime PM status between these functions
> > and the PM core.
> >
> > Also pm_runtime_force_suspend/resume() currently cannot be used in PCI
> > drivers and in drivers that collaborate with the general ACPI PM domain
> > because they both don't expect their mid-layer runtime PM callbacks to
> > be invoked during system-wide suspend and resume.
> >
> > Patch [1/9] is a preparatory cleanup changing the code to use 'true' and
> > 'false' as needs_force_resume flag values for consistency."
> >
> > Patch [2/9] (which was [3/9] in v2) puts pm_runtime_force_resume() and one
> > other function that is only used during system sleep transitions under
> > CONFIG_PM_SLEEP.
> >
> > Patch [3/9] (which was [5/9] in v2) causes the smart_suspend flag to be taken
> > into account by pm_runtime_force_resume() which allows it to resume devices
> > with smart_suspend set whose runtime PM status has been changed to RPM_ACTIVE
> > by the PM core at the beginning of system resume.  After this patch, drivers
> > that use pm_runtime_force_suspend/resume() can also set DPM_FLAG_SMART_SUSPEND
> > which may be useful, for example, if devices handled by them are involved in
> > dependency chains with other devices setting DPM_FLAG_SMART_SUSPEND.
> >
> > Since patches [1,3/9] have been reviewed already and patch [2/9] should not
> > be particularly controversial, I think that patches [1-3/9] are good to go.
> >
> > Patch [4/9] (which was [2/9] in v2), makes pm_runtime_reinit() clear
> > needs_force_resume in case it was set during driver remove.
> >
> > Patch [5/9] (which was [4/9] in v2) makes pm_runtime_force_suspend() check
> > needs_force_resume along with the device's runtime PM status upfront, and bail
> > out if it is set, which allows runtime PM status updates to be eliminated from
> > both that function and pm_runtime_force_resume().  I recalled too late that
> > it was actually necessary for the PCI PM and ACPI PM to work with
> > pm_runtime_force_suspend() correctly after the subsequent changes and that
> > patch [3/9] did not depend on it.  I have also realized that patch [5/9]
> > potentially unbreaks drivers that call pm_runtime_force_suspend() from their
> > "remove" callbacks (see the patch changelog for a bit of an explanation).
> >
> > Patch [6/9] (which has not been changed since v2) makes the code for getting a
> > runtime PM callback for a device a bit more straightforward, in preparation for
> > the subsequent changes.
> >
> > Patch [7/9] introduces a new device PM flag called strict_midlayer that
> > can be set by middle layer code which doesn't want its runtime PM
> > callbacks to be used during system-wide PM transitions, like the PCI bus
> > type and the ACPI PM domain, and updates pm_runtime_force_suspend/resume()
> > to take that flag into account.  Its changelog has been updated since v2 and
> > there is a new kerneldoc comment for dev_pm_set_strict_midlayer().
> >
> > Patch [8/9] modifies the ACPI PM "prepare" and "complete" callback functions,
> > used by the general ACPI PM domain and by the ACPI LPSS PM domain, to set and
> > clear strict_midlayer, respectively, which allows drivers collaborating with it
> > to use pm_runtime_force_suspend/resume().  The changelog of this patch has been
> > made a bit more precise since v2.
> >
> > That may be useful if such a driver wants to be able to work with different
> > PM domains on different systems.  It may want to work with the general ACPI PM
> > domain on systems using ACPI, or with another PM domain (or even multiple PM
> > domains at the same time) on systems without ACPI, and it may want to use
> > pm_runtime_force_suspend/resume() as its system-wide PM callbacks.
> >
> > Patch [9/9] updates the PCI bus type to set and clear, respectively, strict_midlayer
> > for all PCI devices in its "prepare" and "complete" PM callbacks, in case some
> > PCI drivers want to use pm_runtime_force_suspend/resume() in the future.  They
> > will still need to set DPM_FLAG_SMART_SUSPEND to avoid resuming their devices during
> > system suspend, but now they may also use pm_runtime_force_suspend/resume() as
> > suspend callbacks for the "regular suspend" phase of device suspend (or invoke
> > these functions from their suspend callbacks).  The changelog of this patch has
> > been made a bit more precise since v2, like the changelog of patch [8/9].
> >
> > As usual, please refer to individual patch changelogs for more details.
> >
> > Thanks!
> >
>
> For the v3 series, please add:
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Thank you!