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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0g4Q+cqMKNnBDaFsnj4zSH_iKV+EDz9BnfF23cATkczYA@mail.gmail.com>
Date: Thu, 26 Jun 2025 12:59:25 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Ulf Hansson <ulf.hansson@...aro.org>
Cc: "Rafael J. Wysocki" <rafael@...nel.org>, "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 v1 0/9] PM: Reconcile different driver options for runtime
 PM integration with system sleep

On Thu, Jun 26, 2025 at 12:41 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
>
> On Thu, 26 Jun 2025 at 12:34, Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Thu, Jun 26, 2025 at 12:31 PM Ulf Hansson <ulf.hansson@...aro.org> wrote:
> > >
> > > On Wed, 25 Jun 2025 at 21:25, Rafael J. Wysocki <rjw@...ysocki.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