Message-ID: <CAJZ5v0iDGb5KgE0pWKME5sL6wGE-nVOswqcs6K1uTTXB6zZBng@mail.gmail.com>
Date: Wed, 2 Jul 2025 16:14:40 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>, 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 Wed, Jul 2, 2025 at 4:12 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> 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>

Thank you!

Powered by blists - more mailing lists