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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

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!