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

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

[Rafael J. Wysocki]

Hi Everyone,

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

Patch [3/9] 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.

The next two patches, [4-5/9], put pm_runtime_force_suspend/resume()
and needs_force_resume under CONFIG_PM_SLEEP for consistency and also
because using them outside system-wide PM transitions really doesn't make
sense.

Patch [6/9] 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.

Patch [8/9] modifies the general ACPI PM domain to use strict_midlayer
which allows drivers collaborating with it to use pm_runtime_force_suspend/resume().
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 strict_midlayer for all PCI devices
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).

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

Thanks!

[PATCH v1 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>
---
 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 v1 0/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.

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

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 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
@@ -1975,7 +1975,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);
@@ -1990,15 +1990,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;
 
@@ -2029,12 +2030,6 @@
 	if (!dev->power.needs_force_resume)
 		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 v1 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>
---
 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
@@ -1964,10 +1964,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)
 {
@@ -2014,20 +2010,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;
 
 	callback = RPM_GET_CALLBACK(dev, runtime_resume);
@@ -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 v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP

[Rafael J. Wysocki]

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

Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume()
are only used during system-wide PM transitions, there is no reason to
compile them in if CONFIG_PM_SLEEP is unset.

Accordingly, move them all under CONFIG_PM_SLEEP and make the static
inline stubs for pm_runtime_force_suspend/resume() return an error
to indicate that they should not be used outside CONFIG_PM_SLEEP.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/base/power/runtime.c |    4 ++++
 include/linux/pm_runtime.h   |   20 ++++++++++++++------
 2 files changed, 18 insertions(+), 6 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1941,6 +1941,8 @@
 	pm_request_idle(link->supplier);
 }
 
+#ifdef CONFIG_PM_SLEEP
+
 bool pm_runtime_need_not_resume(struct device *dev)
 {
 	return atomic_read(&dev->power.usage_count) <= 1 &&
@@ -2063,3 +2065,5 @@
 	return ret;
 }
 EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
+
+#endif /* CONFIG_PM_SLEEP */
--- a/include/linux/pm_runtime.h
+++ b/include/linux/pm_runtime.h
@@ -66,9 +66,6 @@
 
 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 +254,6 @@
 
 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 +324,20 @@
 
 #endif /* !CONFIG_PM */
 
+#ifdef CONFIG_PM_SLEEP
+
+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);
+
+#else /* !CONFIG_PM_SLEEP */
+
+static inline bool pm_runtime_need_not_resume(struct device *dev) {return true; }
+static inline int pm_runtime_force_suspend(struct device *dev) { return -ENXIO; }
+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 v1 5/9] PM: Move needs_force_resume under CONFIG_PM_SLEEP

[Rafael J. Wysocki]

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

All of the code using the needs_force_resume flag in struct dev_pm_info
is under CONFIG_PM_SLEEP now, so move that flag under CONFIG_PM_SLEEP
too.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 include/linux/pm.h |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- 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			needs_force_resume:1;
 #else
 	bool			should_wakeup:1;
 #endif
@@ -698,7 +699,6 @@
 	bool			idle_notification:1;
 	bool			request_pending:1;
 	bool			deferred_resume:1;
-	bool			needs_force_resume:1;
 	bool			runtime_auto:1;
 	bool			ignore_children:1;
 	bool			no_callbacks:1;

[PATCH v1 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 a helper function for changing 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>
---
 drivers/base/power/runtime.c |   21 +++++++++++++++++++--
 include/linux/device.h       |    7 +++++++
 include/linux/pm.h           |    1 +
 3 files changed, 27 insertions(+), 2 deletions(-)

--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1962,6 +1962,23 @@
 		 dev->power.ignore_children);
 }
 
+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->power.strict_midlayer)
+		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.
@@ -1988,7 +2005,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;
@@ -2048,7 +2065,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,13 @@
 #endif
 }
 
+static inline void dev_pm_strict_midlayer(struct device *dev, bool val)
+{
+#ifdef CONFIG_PM_SLEEP
+	dev->power.strict_midlayer = val;
+#endif
+}
+
 static inline void device_lock(struct device *dev)
 {
 	mutex_lock(&dev->mutex);
--- a/include/linux/pm.h
+++ b/include/linux/pm.h
@@ -684,6 +684,7 @@
 	bool			must_resume:1;		/* Owned by the PM core */
 	bool			may_skip_resume:1;	/* Set by subsystems */
 	bool			needs_force_resume:1;
+	bool			strict_midlayer:1;
 #else
 	bool			should_wakeup:1;
 #endif

[PATCH v1 8/9] ACPI: PM: Set/clear power.strict_midlayer during attach/detach

[Rafael J. Wysocki]

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

The ACPI general PM domain does not expect its runtime PM callbacks,
acpi_subsys_runtime_suspend() and acpi_subsys_runtime_resume(), to
be invoked at any point during system-wide suspend and resume, so
make it express that expectation by setting power.strict_midlayer
for devices that it is attached to.  Also make it clear that flag
when it detaches from those devices.

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

This depends on

https://lore.kernel.org/linux-acpi/4665476.LvFx2qVVIh@rjwysocki.net/

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

--- a/drivers/acpi/device_pm.c
+++ b/drivers/acpi/device_pm.c
@@ -1404,6 +1404,7 @@
 	struct acpi_device *adev = ACPI_COMPANION(dev);
 
 	if (adev && dev->pm_domain == &acpi_general_pm_domain) {
+		dev_pm_strict_midlayer(dev, false);
 		dev_pm_domain_set(dev, NULL);
 		acpi_remove_pm_notifier(adev);
 		if (power_off) {
@@ -1463,6 +1464,7 @@
 
 	acpi_add_pm_notifier(adev, dev, acpi_pm_notify_work_func);
 	dev_pm_domain_set(dev, &acpi_general_pm_domain);
+	dev_pm_strict_midlayer(dev, true);
 	if (power_on) {
 		acpi_dev_pm_full_power(adev);
 		acpi_device_wakeup_disable(adev);

[PATCH v1 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 callbacks,
pci_pm_runtime_suspend() and pci_pm_runtime_resume(), to be invoked at
any point during system-wide suspend and resume, so make it express
that expectation by setting power.strict_midlayer for all PCI devices.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
---
 drivers/pci/pci.c |    2 ++
 1 file changed, 2 insertions(+)

--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3208,6 +3208,8 @@
 	u16 status;
 	u16 pmc;
 
+	dev_pm_strict_midlayer(&dev->dev, true);
+
 	device_enable_async_suspend(&dev->dev);
 	dev->wakeup_prepared = false;
 

Re: [PATCH v1 0/9] PM: Check power.needs_force_resume in pm_runtime_force_suspend()

[Rafael J. Wysocki]

This should be [PATCH v1 2/9], but it obviously doesn't apply without
the [1/9], so please regard it as the second one in the series.

Sorry about the confusion.

On Wed, Jun 25, 2025 at 9:25 PM Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> 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.
>
> This 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.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  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
> @@ -1975,7 +1975,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);
> @@ -1990,15 +1990,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;
>
> @@ -2029,12 +2030,6 @@
>         if (!dev->power.needs_force_resume)
>                 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);
>
>
>
>

Re: [PATCH v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP

[Ulf Hansson]

On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>
> Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume()
> are only used during system-wide PM transitions, there is no reason to
> compile them in if CONFIG_PM_SLEEP is unset.
>
> Accordingly, move them all under CONFIG_PM_SLEEP and make the static
> inline stubs for pm_runtime_force_suspend/resume() return an error
> to indicate that they should not be used outside CONFIG_PM_SLEEP.
>

Just realized that there seems to be some drivers that actually make
use of pm_runtime_force_suspend() from their ->remove() callbacks.

To not break them, we probably need to leave this code to stay under CONFIG_PM.

Kind regards
Uffe

> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  drivers/base/power/runtime.c |    4 ++++
>  include/linux/pm_runtime.h   |   20 ++++++++++++++------
>  2 files changed, 18 insertions(+), 6 deletions(-)
>
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -1941,6 +1941,8 @@
>         pm_request_idle(link->supplier);
>  }
>
> +#ifdef CONFIG_PM_SLEEP
> +
>  bool pm_runtime_need_not_resume(struct device *dev)
>  {
>         return atomic_read(&dev->power.usage_count) <= 1 &&
> @@ -2063,3 +2065,5 @@
>         return ret;
>  }
>  EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
> +
> +#endif /* CONFIG_PM_SLEEP */
> --- a/include/linux/pm_runtime.h
> +++ b/include/linux/pm_runtime.h
> @@ -66,9 +66,6 @@
>
>  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 +254,6 @@
>
>  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 +324,20 @@
>
>  #endif /* !CONFIG_PM */
>
> +#ifdef CONFIG_PM_SLEEP
> +
> +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);
> +
> +#else /* !CONFIG_PM_SLEEP */
> +
> +static inline bool pm_runtime_need_not_resume(struct device *dev) {return true; }
> +static inline int pm_runtime_force_suspend(struct device *dev) { return -ENXIO; }
> +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.
>
>
>

Re: [PATCH v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP

[Rafael J. Wysocki]

On Thu, Jun 26, 2025 at 11:38 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> >
> > Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume()
> > are only used during system-wide PM transitions, there is no reason to
> > compile them in if CONFIG_PM_SLEEP is unset.
> >
> > Accordingly, move them all under CONFIG_PM_SLEEP and make the static
> > inline stubs for pm_runtime_force_suspend/resume() return an error
> > to indicate that they should not be used outside CONFIG_PM_SLEEP.
> >
>
> Just realized that there seems to be some drivers that actually make
> use of pm_runtime_force_suspend() from their ->remove() callbacks.
>
> To not break them, we probably need to leave this code to stay under CONFIG_PM.

OK, pm_runtime_force_suspend() need not be under CONFIG_PM_SLEEP.
That's not the case for the other two functions though AFAICS.

> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >  drivers/base/power/runtime.c |    4 ++++
> >  include/linux/pm_runtime.h   |   20 ++++++++++++++------
> >  2 files changed, 18 insertions(+), 6 deletions(-)
> >
> > --- a/drivers/base/power/runtime.c
> > +++ b/drivers/base/power/runtime.c
> > @@ -1941,6 +1941,8 @@
> >         pm_request_idle(link->supplier);
> >  }
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +
> >  bool pm_runtime_need_not_resume(struct device *dev)
> >  {
> >         return atomic_read(&dev->power.usage_count) <= 1 &&
> > @@ -2063,3 +2065,5 @@
> >         return ret;
> >  }
> >  EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
> > +
> > +#endif /* CONFIG_PM_SLEEP */
> > --- a/include/linux/pm_runtime.h
> > +++ b/include/linux/pm_runtime.h
> > @@ -66,9 +66,6 @@
> >
> >  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 +254,6 @@
> >
> >  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 +324,20 @@
> >
> >  #endif /* !CONFIG_PM */
> >
> > +#ifdef CONFIG_PM_SLEEP
> > +
> > +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);
> > +
> > +#else /* !CONFIG_PM_SLEEP */
> > +
> > +static inline bool pm_runtime_need_not_resume(struct device *dev) {return true; }
> > +static inline int pm_runtime_force_suspend(struct device *dev) { return -ENXIO; }
> > +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.
> >
> >
> >
>

Re: [PATCH v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP

[Ulf Hansson]

On Thu, 26 Jun 2025 at 11:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Jun 26, 2025 at 11:38 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >
> > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > >
> > > Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume()
> > > are only used during system-wide PM transitions, there is no reason to
> > > compile them in if CONFIG_PM_SLEEP is unset.
> > >
> > > Accordingly, move them all under CONFIG_PM_SLEEP and make the static
> > > inline stubs for pm_runtime_force_suspend/resume() return an error
> > > to indicate that they should not be used outside CONFIG_PM_SLEEP.
> > >
> >
> > Just realized that there seems to be some drivers that actually make
> > use of pm_runtime_force_suspend() from their ->remove() callbacks.
> >
> > To not break them, we probably need to leave this code to stay under CONFIG_PM.
>
> OK, pm_runtime_force_suspend() need not be under CONFIG_PM_SLEEP.
> That's not the case for the other two functions though AFAICS.

Right, but maybe better to keep them to avoid confusion? At least the
corresponding flag is needed.

Kind regards
Uffe

>
> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > ---
> > >  drivers/base/power/runtime.c |    4 ++++
> > >  include/linux/pm_runtime.h   |   20 ++++++++++++++------
> > >  2 files changed, 18 insertions(+), 6 deletions(-)
> > >
> > > --- a/drivers/base/power/runtime.c
> > > +++ b/drivers/base/power/runtime.c
> > > @@ -1941,6 +1941,8 @@
> > >         pm_request_idle(link->supplier);
> > >  }
> > >
> > > +#ifdef CONFIG_PM_SLEEP
> > > +
> > >  bool pm_runtime_need_not_resume(struct device *dev)
> > >  {
> > >         return atomic_read(&dev->power.usage_count) <= 1 &&
> > > @@ -2063,3 +2065,5 @@
> > >         return ret;
> > >  }
> > >  EXPORT_SYMBOL_GPL(pm_runtime_force_resume);
> > > +
> > > +#endif /* CONFIG_PM_SLEEP */
> > > --- a/include/linux/pm_runtime.h
> > > +++ b/include/linux/pm_runtime.h
> > > @@ -66,9 +66,6 @@
> > >
> > >  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 +254,6 @@
> > >
> > >  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 +324,20 @@
> > >
> > >  #endif /* !CONFIG_PM */
> > >
> > > +#ifdef CONFIG_PM_SLEEP
> > > +
> > > +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);
> > > +
> > > +#else /* !CONFIG_PM_SLEEP */
> > > +
> > > +static inline bool pm_runtime_need_not_resume(struct device *dev) {return true; }
> > > +static inline int pm_runtime_force_suspend(struct device *dev) { return -ENXIO; }
> > > +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.
> > >
> > >
> > >
> >

Re: [PATCH v1 0/9] PM: Check power.needs_force_resume in pm_runtime_force_suspend()

[Ulf Hansson]

On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> 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.
>
> This 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.
>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  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
> @@ -1975,7 +1975,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);
> @@ -1990,15 +1990,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;
>
> @@ -2029,12 +2030,6 @@
>         if (!dev->power.needs_force_resume)
>                 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);
>

As I mentioned for patch4, pm_runtime_force_suspend() is being used
from driver's ->remove() callback too.

If such a driver/device gets probed again, we need a fresh start. It
seems like we need to clear the needs_force_resume flag in
pm_runtime_reinit(). In fact, that looks like an existing bug, even
before $subject patch, right?

Kind regards
Uffe

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

[Ulf Hansson]

On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> 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>

Kind regards
Uffe


> ---
>  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;
>  }
>
>
>

Re: [PATCH v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP

[Rafael J. Wysocki]

On Thu, Jun 26, 2025 at 12:05 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Thu, 26 Jun 2025 at 11:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Jun 26, 2025 at 11:38 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > >
> > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > >
> > > > Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume()
> > > > are only used during system-wide PM transitions, there is no reason to
> > > > compile them in if CONFIG_PM_SLEEP is unset.
> > > >
> > > > Accordingly, move them all under CONFIG_PM_SLEEP and make the static
> > > > inline stubs for pm_runtime_force_suspend/resume() return an error
> > > > to indicate that they should not be used outside CONFIG_PM_SLEEP.
> > > >
> > >
> > > Just realized that there seems to be some drivers that actually make
> > > use of pm_runtime_force_suspend() from their ->remove() callbacks.
> > >
> > > To not break them, we probably need to leave this code to stay under CONFIG_PM.
> >
> > OK, pm_runtime_force_suspend() need not be under CONFIG_PM_SLEEP.
> > That's not the case for the other two functions though AFAICS.
>
> Right, but maybe better to keep them to avoid confusion?

There really is no point holding pm_runtime_need_not_resume() outside
CONFIG_PM_SLEEP and pm_runtime_force_resume() really should not be
used anywhere outside system resume flows.

> At least the corresponding flag is needed.

What flag do you mean?  If pm_runtime_force_suspend() does not go
under CONFIG_PM_SLEEP, needs_force_resume will not go under it either
(so I'll drop the next patch altogether).

Cheers, Rafael

Re: [PATCH v1 0/9] PM: Check power.needs_force_resume in pm_runtime_force_suspend()

[Rafael J. Wysocki]

On Thu, Jun 26, 2025 at 12:10 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > 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.
> >
> > This 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.
> >
> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > ---
> >  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
> > @@ -1975,7 +1975,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);
> > @@ -1990,15 +1990,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;
> >
> > @@ -2029,12 +2030,6 @@
> >         if (!dev->power.needs_force_resume)
> >                 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);
> >
>
> As I mentioned for patch4, pm_runtime_force_suspend() is being used
> from driver's ->remove() callback too.
>
> If such a driver/device gets probed again, we need a fresh start. It
> seems like we need to clear the needs_force_resume flag in
> pm_runtime_reinit(). In fact, that looks like an existing bug, even
> before $subject patch, right?

If it is used in ->remove(), then yes, it needs to be cleared in
_reinit(), at least in principle.

Re: [PATCH v1 4/9] PM: Move pm_runtime_force_suspend/resume() under CONFIG_PM_SLEEP

[Ulf Hansson]

On Thu, 26 Jun 2025 at 12:13, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Jun 26, 2025 at 12:05 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Thu, 26 Jun 2025 at 11:41, Rafael J. Wysocki <rafael@kernel.org> wrote:
> > >
> > > On Thu, Jun 26, 2025 at 11:38 AM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > > >
> > > > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > > >
> > > > > From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> > > > >
> > > > > Since pm_runtime_force_suspend/resume() and pm_runtime_need_not_resume()
> > > > > are only used during system-wide PM transitions, there is no reason to
> > > > > compile them in if CONFIG_PM_SLEEP is unset.
> > > > >
> > > > > Accordingly, move them all under CONFIG_PM_SLEEP and make the static
> > > > > inline stubs for pm_runtime_force_suspend/resume() return an error
> > > > > to indicate that they should not be used outside CONFIG_PM_SLEEP.
> > > > >
> > > >
> > > > Just realized that there seems to be some drivers that actually make
> > > > use of pm_runtime_force_suspend() from their ->remove() callbacks.
> > > >
> > > > To not break them, we probably need to leave this code to stay under CONFIG_PM.
> > >
> > > OK, pm_runtime_force_suspend() need not be under CONFIG_PM_SLEEP.
> > > That's not the case for the other two functions though AFAICS.
> >
> > Right, but maybe better to keep them to avoid confusion?
>
> There really is no point holding pm_runtime_need_not_resume() outside
> CONFIG_PM_SLEEP and pm_runtime_force_resume() really should not be
> used anywhere outside system resume flows.

Right, I am fine moving it if you insist.

>
> > At least the corresponding flag is needed.
>
> What flag do you mean?  If pm_runtime_force_suspend() does not go
> under CONFIG_PM_SLEEP, needs_force_resume will not go under it either
> (so I'll drop the next patch altogether).

Yes, that's my point. needs_force_resume needs to stay within CONFIG_PM.

Kind regards
Uffe

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

[Ulf Hansson]

On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> 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>

Looks good to me!

Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>

Kind regards
Uffe

> ---
>  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
> @@ -1964,10 +1964,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)
>  {
> @@ -2014,20 +2010,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;
>
>         callback = RPM_GET_CALLBACK(dev, runtime_resume);
> @@ -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;
>  }
>
>
>

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

[Ulf Hansson]

On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
>
> Hi Everyone,
>
> 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] 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().
>
> Patch [3/9] 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.
>
> The next two patches, [4-5/9], put pm_runtime_force_suspend/resume()
> and needs_force_resume under CONFIG_PM_SLEEP for consistency and also
> because using them outside system-wide PM transitions really doesn't make
> sense.
>
> Patch [6/9] makes the code for getting a runtime PM callback for a device
> a bit more straightforward in preparation for the subsequent changes.

I can't find this one. Seems like you did not submit it.

Perhaps make a resend and fixup the patch-numbering too?

[...]

Kind regards
Uffe

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

[Rafael J. Wysocki]

On Thu, Jun 26, 2025 at 12:31 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> >
> > Hi Everyone,
> >
> > 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] 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().
> >
> > Patch [3/9] 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.
> >
> > The next two patches, [4-5/9], put pm_runtime_force_suspend/resume()
> > and needs_force_resume under CONFIG_PM_SLEEP for consistency and also
> > because using them outside system-wide PM transitions really doesn't make
> > sense.
> >
> > Patch [6/9] makes the code for getting a runtime PM callback for a device
> > a bit more straightforward in preparation for the subsequent changes.
>
> I can't find this one. Seems like you did not submit it.
>
> Perhaps make a resend and fixup the patch-numbering too?

I'm going to send a v2, but the patch in question is here (wrong number):

https://lore.kernel.org/linux-acpi/3306233.5fSG56mABF@rjwysocki.net/

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

[Ulf Hansson]

On Thu, 26 Jun 2025 at 12:34, Rafael J. Wysocki <rafael@kernel.org> wrote:
>
> On Thu, Jun 26, 2025 at 12:31 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> >
> > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >
> > > Hi Everyone,
> > >
> > > 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] 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().
> > >
> > > Patch [3/9] 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.
> > >
> > > The next two patches, [4-5/9], put pm_runtime_force_suspend/resume()
> > > and needs_force_resume under CONFIG_PM_SLEEP for consistency and also
> > > because using them outside system-wide PM transitions really doesn't make
> > > sense.
> > >
> > > Patch [6/9] makes the code for getting a runtime PM callback for a device
> > > a bit more straightforward in preparation for the subsequent changes.
> >
> > I can't find this one. Seems like you did not submit it.
> >
> > Perhaps make a resend and fixup the patch-numbering too?
>
> I'm going to send a v2, but the patch in question is here (wrong number):
>
> https://lore.kernel.org/linux-acpi/3306233.5fSG56mABF@rjwysocki.net/

No, that's patch2 (which was named pacth0). :-) Nevermind, I think we
made some progress so I am awaiting a v2 before continuing my reviews.

Kind regards
Uffe

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

[Rafael J. Wysocki]

On Thu, Jun 26, 2025 at 12:41 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
>
> On Thu, 26 Jun 2025 at 12:34, Rafael J. Wysocki <rafael@kernel.org> wrote:
> >
> > On Thu, Jun 26, 2025 at 12:31 PM Ulf Hansson <ulf.hansson@linaro.org> wrote:
> > >
> > > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > > >
> > > > Hi Everyone,
> > > >
> > > > 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] 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().
> > > >
> > > > Patch [3/9] 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.
> > > >
> > > > The next two patches, [4-5/9], put pm_runtime_force_suspend/resume()
> > > > and needs_force_resume under CONFIG_PM_SLEEP for consistency and also
> > > > because using them outside system-wide PM transitions really doesn't make
> > > > sense.
> > > >
> > > > Patch [6/9] makes the code for getting a runtime PM callback for a device
> > > > a bit more straightforward in preparation for the subsequent changes.
> > >
> > > I can't find this one. Seems like you did not submit it.
> > >
> > > Perhaps make a resend and fixup the patch-numbering too?
> >
> > I'm going to send a v2, but the patch in question is here (wrong number):
> >
> > https://lore.kernel.org/linux-acpi/3306233.5fSG56mABF@rjwysocki.net/
>
> No, that's patch2 (which was named pacth0). :-) Nevermind, I think we
> made some progress so I am awaiting a v2 before continuing my reviews.

OK