Message-ID: <CAPDyKFp35SjpQmEQ02u7ZbsaFftaett_rBBf-7hbsBpGWH08hw@mail.gmail.com>
Date: Wed, 2 Jul 2025 16:11:30 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc: Linux PM <linux-pm@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>, 
	Linux ACPI <linux-acpi@...r.kernel.org>, Linux PCI <linux-pci@...r.kernel.org>, 
	Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: [PATCH v3 0/9] PM: Reconcile different driver options for runtime
 PM integration with system sleep

On Fri, 27 Jun 2025 at 21:29, Rafael J. Wysocki <rjw@...ysocki.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@...aro.org>

Kind regards
Uffe

Powered by blists - more mailing lists