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-next>] [day] [month] [year] [list]
Message-ID: <22759968.EfDdHjke4D@rjwysocki.net>
Date: Wed, 25 Jun 2025 21:14:49 +0200
From: "Rafael J. Wysocki" <rjw@...ysocki.net>
To: Linux PM <linux-pm@...r.kernel.org>
Cc: LKML <linux-kernel@...r.kernel.org>,
 Linux ACPI <linux-acpi@...r.kernel.org>,
 Linux PCI <linux-pci@...r.kernel.org>, Ulf Hansson <ulf.hansson@...aro.org>,
 Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject:
 [PATCH v1 0/9] PM: Reconcile different driver options for runtime PM
 integration with system sleep

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!




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ