kernel/git/stable/linux.git/drivers/base/power/main.c, branch master

PM: sleep: Unblock runtime PM when device prepare fails

2026-08-20T21:18:15+00:00

device_prepare() blocks runtime PM for a device with runtime PM disabled before invoking its system-sleep ->prepare() callback. For a device that has never enabled runtime PM, this changes dev->power.last_status from RPM_INVALID to RPM_BLOCKED. If the callback returns an error, dpm_prepare() does not move the device to dpm_prepared_list. Consequently, the recovery path through dpm_complete() never calls device_complete() for the failing device. The error path drops the runtime PM usage reference, but does not clear RPM_BLOCKED. A later legitimate pm_runtime_enable() then reports: Attempt to enable runtime PM when it is blocked before clearing the stale state. Call pm_runtime_unblock() on the prepare error path before dropping the runtime PM reference, matching the cleanup performed by device_complete(). The issue was reproduced with a platform test device whose ->prepare() callback returns -EIO while runtime PM has never been enabled. Before the fix, last_status remained RPM_BLOCKED after the failed suspend and the first pm_runtime_enable() produced the warning above. With the fix, last_status is restored to RPM_INVALID and the warning is absent. Fixes: 3e5eee147b7b ("PM: Block enabling of runtime PM during system suspend") Cc: All applicable Signed-off-by: Shibo Zhu <3499129952@qq.com> Link: https://patch.msgid.link/tencent_C5AC0A02FC01F700E764F8C2E3ECE4F41009@qq.com Signed-off-by: Rafael J. Wysocki

PM: sleep: Allow disabling DPM watchdog by default

2026-07-23T13:46:34+00:00

Introduce the "dpm_watchdog_enabled" module parameter to allow the DPM watchdog to be enabled or disabled at boot time and runtime. Additionally, introduce the CONFIG_DPM_WATCHDOG_ENABLED Kconfig option to set the default value of the module parameter at compile time. The primary motivation for this configurability resolves around Android GKI (Generic Kernel Image). We want to enable CONFIG_DPM_WATCHDOG in the GKI so the feature is available. However, because the GKI is shared across many different devices, we don't want to inadvertently affect devices that are unaware of this feature. This provides a way to compile it in, but keep it disabled by default for those devices via the kernel command line or module parameters. To maintain backward compatibility, CONFIG_DPM_WATCHDOG_ENABLED relies on `default y`. Previously, the DPM watchdog was always active if CONFIG_DPM_WATCHDOG was set. Defaulting this new option to 'y' ensures that the behavior remains unchanged for existing users and defconfigs when they upgrade. Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260720030821.2780257-3-tzungbi@kernel.org Signed-off-by: Rafael J. Wysocki

PM: sleep: Rename module parameters prefix to "pm"

2026-07-23T13:46:34+00:00

Currently, the module parameters defined in drivers/base/power/main.c use the default prefix "main" (derived from the filename). The prefix is too generic and non-descriptive. Redefine MODULE_PARAM_PREFIX to "pm." to group the module parameters under the namespace instead. This makes the parameters more descriptive. Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260720030821.2780257-2-tzungbi@kernel.org Signed-off-by: Rafael J. Wysocki

PM: dpm_watchdog: Add sysctl interface for DPM watchdog timeouts

2026-06-11T19:38:29+00:00

Introduce sysctl knobs to allow configuring DPM watchdog timeouts at runtime. Currently, these timeouts are fixed at compile time via CONFIG_DPM_WATCHDOG_TIMEOUT and CONFIG_DPM_WATCHDOG_WARNING_TIMEOUT. This limits flexibility if the timeouts need to be adjusted for different testing scenarios or hardware behaviors without rebuilding the kernel. Add the following sysctl files under /proc/sys/kernel/: - dpm_watchdog_timeout_secs: The total timeout before panic. The maximum value is capped at CONFIG_DPM_WATCHDOG_TIMEOUT to prevent unreasonably large timeouts. - dpm_watchdog_warning_timeout_secs: The warning timeout. The maximum value is capped at the current dpm_watchdog_timeout_secs. Both sysctls have a minimum value of 1. Signed-off-by: Tzung-Bi Shih Link: https://patch.msgid.link/20260608021526.1023248-4-tzungbi@kernel.org Signed-off-by: Rafael J. Wysocki

PM: sleep: Use complete() in device_pm_sleep_init()

2026-05-26T11:02:34+00:00

Replace complete_all() with complete() in device_pm_sleep_init() to allow it to be called in atomic contexts without triggering a false-positive WARNING from lockdep_assert_RT_in_threaded_ctx() when CONFIG_PROVE_RAW_LOCK_NESTING is enabled. device_pm_sleep_init() may be called during device initialization while holding a raw_spinlock (e.g., from within device_initialize()), and complete_all() is unsafe in atomic contexts on PREEMPT_RT kernels. complete(), which is safe to call from any context, is sufficient here. complete_all() sets the completion count to UINT_MAX/2 (permanently signaled), while complete() increments it by 1. Since no threads can be waiting during device initialization, both are functionally equivalent. The completion is always reinitialized via reinit_completion() in dpm_clear_async_state() before each suspend/resume cycle. However, changing to complete() introduces a potential deadlock for devices with no PM support (dev->power.no_pm = true). Such devices are never added to the dpm_list and never go through dpm_clear_async_state(), so their completion is never reinitialized. A parent device waiting on a no_pm child across multiple suspend phases would consume the single-use token in the first phase and block forever in the second. Fix this by adding an early return in dpm_wait() when dev->power.no_pm is set, since no_pm devices do not participate in system suspend/resume. Fixes: 152e1d592071 ("PM: Prevent waiting forever on asynchronous resume after failing suspend") Signed-off-by: Jiakai Xu [ rjw: Subject adjustment ] Link: https://patch.msgid.link/20260523022314.2657232-1-xujiakai24@mails.ucas.ac.cn Signed-off-by: Rafael J. Wysocki

thermal: core: Suspend thermal zones later and resume them earlier

2026-04-08T10:30:31+00:00

To avoid some undesirable interactions between thermal zone suspend and resume with user space that is running when those operations are carried out, move them closer to the suspend and resume of devices, respectively, by updating dpm_prepare() to carry out thermal zone suspend and dpm_complete() to start thermal zone resume (that will continue asynchronously). This also makes the code easier to follow by removing one, arguably redundant, level of indirection represented by the thermal PM notifier. Signed-off-by: Rafael J. Wysocki Reviewed-by: Armin Wolf Link: https://patch.msgid.link/2036875.PYKUYFuaPT@rafael.j.wysocki

PM: sleep: Do not flag runtime PM workqueue as freezable

2025-12-15T11:20:02+00:00

Till now, the runtime PM workqueue has been flagged as freezable, so it does not process work items during system-wide PM transitions like system suspend and resume. The original reason to do that was to reduce the likelihood of runtime PM getting in the way of system-wide PM processing, but now it is mostly an optimization because (1) runtime suspend of devices is prevented by bumping up their runtime PM usage counters in device_prepare() and (2) device drivers are expected to disable runtime PM for the devices handled by them before they embark on system-wide PM activities that may change the state of the hardware or otherwise interfere with runtime PM. However, it prevents asynchronous runtime resume of devices from working during system-wide PM transitions, which is confusing because synchronous runtime resume is not prevented at the same time, and it also sometimes turns out to be problematic. For example, it has been reported that blk_queue_enter() may deadlock during a system suspend transition because of the pm_request_resume() usage in it [1]. It may also deadlock during a system resume transition in a similar way. That happens because the asynchronous runtime resume of the given device is not processed due to the freezing of the runtime PM workqueue. While it may be better to address this particular issue in the block layer, the very presence of it means that similar problems may be expected to occur elsewhere. For this reason, remove the WQ_FREEZABLE flag from the runtime PM workqueue and make device_suspend_late() use the generic variant of pm_runtime_disable() that will carry out runtime PM of the device synchronously if there is pending resume work for it. Also update the comment before the pm_runtime_disable() call in device_suspend_late(), to document the fact that the runtime PM should not be expected to work for the device until the end of device_resume_early(), and update the related documentation. This change may, even though it is not expected to, uncover some latent issues related to queuing up asynchronous runtime resume work items during system suspend or hibernation. However, they should be limited to the interference between runtime resume and system-wide PM callbacks in the cases when device drivers start to handle system-wide PM before disabling runtime PM as described above. Link: https://lore.kernel.org/linux-pm/20251126101636.205505-2-yang.yang@vivo.com/ Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Link: https://patch.msgid.link/12794222.O9o76ZdvQC@rafael.j.wysocki

Merge tag 'pmdomain-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm

2025-12-04T21:50:39+00:00

Pull pmdomain updates from Ulf Hansson: "pmdomain core: - Allow power-off for out-of-band wakeup-capable devices - Drop the redundant call to dev_pm_domain_detach() for the amba bus - Extend the genpd governor for CPUs to account for IPIs pmdomain providers: - bcm: Add support for BCM2712 - mediatek: Add support for MFlexGraphics power domains - mediatek: Add support for MT8196 power domains - qcom: Add RPMh power domain support for Kaanapali - rockchip: Add support for RV1126B pmdomain consumers: - usb: dwc3: Enable out of band wakeup for i.MX95 - usb: chipidea: Enable out of band wakeup for i.MX95" * tag 'pmdomain-v6.19' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: (26 commits) pmdomain: Extend the genpd governor for CPUs to account for IPIs smp: Introduce a helper function to check for pending IPIs pmdomain: mediatek: convert from clk round_rate() to determine_rate() amba: bus: Drop dev_pm_domain_detach() call pmdomain: bcm: bcm2835-power: Prepare to support BCM2712 pmdomain: mediatek: mtk-mfg: select MAILBOX in Kconfig pmdomain: mediatek: Add support for MFlexGraphics pmdomain: mediatek: Fix build-errors cpuidle: psci: Replace deprecated strcpy in psci_idle_init_cpu pmdomain: rockchip: Add support for RV1126B pmdomain: mediatek: Add support for MT8196 HFRPSYS power domains pmdomain: mediatek: Add support for MT8196 SCPSYS power domains pmdomain: mediatek: Add support for secure HWCCF infra power on pmdomain: mediatek: Add support for Hardware Voter power domains pmdomain: qcom: rpmhpd: Add RPMh power domain support for Kaanapali usb: dwc3: imx8mp: Set out of band wakeup for i.MX95 usb: chipidea: ci_hdrc_imx: Set out of band wakeup for i.MX95 usb: chipidea: core: detach power domain for ci_hdrc platform device pmdomain: core: Allow power-off for out-of-band wakeup-capable devices PM: wakeup: Add out-of-band system wakeup support for devices ...

Merge back material related to system sleep for 6.19

2025-11-20T21:28:23+00:00

PM: wakeup: Add out-of-band system wakeup support for devices

2025-11-19T17:06:49+00:00

Some devices can wake up the system from suspend even when their power domains are turned off. This is possible because their system-wakeup logic resides in an always-on power domain - indicating that they support out-of-band system wakeup. Currently, PM domain core doesn't power off such devices if they are marked as system wakeup sources. To better represent devices with out-of-band wakeup capability, this patch introduces a new flag out_band_wakeup in 'struct dev_pm_info'. Two helper APIs are added: - device_set_out_band_wakeup() - to mark a device as having out-of-band wakeup capability. - device_out_band_wakeup() - to query the flag. Allow the PM core and drivers to distinguish between regular and out-of-band wakeup sources, enable more accurate power management decision. Signed-off-by: Peng Fan Reviewed-by: Dhruva Gole Signed-off-by: Ulf Hansson