treewide: Switch/rename to timer_delete[_sync]()

timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with c

treewide: Switch/rename to timer_delete[_sync]()

timer_delete[_sync]() replaces del_timer[_sync](). Convert the whole tree
over and remove the historical wrapper inlines.

Conversion was done with coccinelle plus manual fixups where necessary.

Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>

show more ...

PM: sleep: Fix bit masking operation

The mask operation link->flags | DL_FLAG_PM_RUNTIME is always true which
is incorrect. The mask operation should be using the bit-wise &
operator. Fix this.

Fix

PM: sleep: Fix bit masking operation

The mask operation link->flags | DL_FLAG_PM_RUNTIME is always true which
is incorrect. The mask operation should be using the bit-wise &
operator. Fix this.

Fixes: bca84a7b93fd ("PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally")
Signed-off-by: Colin Ian King <[email protected]>
Link: https://patch.msgid.link/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: sleep: Fix handling devices with direct_complete set on errors

When dpm_suspend() fails, some devices with power.direct_complete set
may not have been handled by device_suspend() yet, so runtime

PM: sleep: Fix handling devices with direct_complete set on errors

When dpm_suspend() fails, some devices with power.direct_complete set
may not have been handled by device_suspend() yet, so runtime PM has
not been disabled for them yet even though power.direct_complete is set.

Since device_resume() expects that runtime PM has been disabled for all
devices with power.direct_complete set, it will attempt to reenable
runtime PM for the devices that have not been processed by device_suspend()
which does not make sense. Had those devices had runtime PM disabled
before device_suspend() had run, device_resume() would have inadvertently
enable runtime PM for them, but this is not expected to happen because
it would require ->prepare() callbacks to return positive values for
devices with runtime PM disabled, which would be invalid.

In practice, this issue is most likely benign because pm_runtime_enable()
will not allow the "disable depth" counter to underflow, but it causes a
warning message to be printed for each affected device.

To allow device_resume() to distinguish the "direct complete" devices
that have been processed by device_suspend() from those which have not
been handled by it, make device_suspend() set power.is_suspended for
"direct complete" devices.

Next, move the power.is_suspended check in device_resume() before the
power.direct_complete check in it to make it skip the "direct complete"
devices that have not been handled by device_suspend().

This change is based on a preliminary patch from Saravana Kannan.

Fixes: aae4518b3124 ("PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily")
Link: https://lore.kernel.org/linux-pm/[email protected]/
Reported-by: Saravana Kannan <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Saravana Kannan <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: core: Fix indentation in dpm_wait_for_children()

The body of dpm_wait_for_children() is indented by 7 spaces instead of a
single TAB.

Signed-off-by: Geert Uytterhoeven <geert+renesas@gli

PM: sleep: core: Fix indentation in dpm_wait_for_children()

The body of dpm_wait_for_children() is indented by 7 spaces instead of a
single TAB.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://patch.msgid.link/9c8ff2b103c3ba7b0d27bdc8248b05e3b1dc9551.1741776430.git.geert+renesas@glider.be
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: sleep: Rearrange dpm_async_fn() and async state clearing

In preparation for subsequent changes, move the power.completion
reinitialization along with clearing power.work_in_progress into a
separ

PM: sleep: Rearrange dpm_async_fn() and async state clearing

In preparation for subsequent changes, move the power.completion
reinitialization along with clearing power.work_in_progress into a
separate function called dpm_clear_async_state() and rearrange
dpm_async_fn() to get rid of unnecessary indentation.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Rename power.async_in_progress to power.work_in_progress

Rename the async_in_progress field in struct dev_pm_info to
work_in_progress as after subsequent changes it will mean work in
gene

PM: sleep: Rename power.async_in_progress to power.work_in_progress

Rename the async_in_progress field in struct dev_pm_info to
work_in_progress as after subsequent changes it will mean work in
general rather than just async work.

No functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: core: Tweak pm_runtime_block_if_disabled() return value

Modify pm_runtime_block_if_disabled() to return true when runtime PM
is disabled for the device, regardless of the power.last_status value

PM: core: Tweak pm_runtime_block_if_disabled() return value

Modify pm_runtime_block_if_disabled() to return true when runtime PM
is disabled for the device, regardless of the power.last_status value.

This effectively prevents "smart suspend" from being enabled for
devices with runtime PM disabled in device_prepare(), even transiently,
so update the related comment in that function accordingly.

If a device has runtime PM disabled in device_prepare(), it is not
actually known whether or not runtime PM will be enabled for that
device going forward, so it is more appropriate to postpone the
"smart suspend" optimization for the device in the given system
suspend-resume cycle than to enable it and get confused going
forward.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Update power.smart_suspend under PM spinlock

Put the update of the power.smart_suspend device flag under the PM
spinlock of the device in case multiple bit fields in struct dev_pm_info
oc

PM: sleep: Update power.smart_suspend under PM spinlock

Put the update of the power.smart_suspend device flag under the PM
spinlock of the device in case multiple bit fields in struct dev_pm_info
occupy one memory location which needs to be updated via RMW every time
any of these bit fields is updated.

The lock in question is already held around the power.direct_complete
flag update in device_prepare() for the same reason, so this change does
not add locking-related overhead to the code.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Adjust check before setting power.must_resume

The check before setting power.must_resume in device_suspend_noirq()
does not take power.child_count into account, but it should do that, so

PM: sleep: Adjust check before setting power.must_resume

The check before setting power.must_resume in device_suspend_noirq()
does not take power.child_count into account, but it should do that, so
use pm_runtime_need_not_resume() in it for this purpose and adjust the
comment next to it accordingly.

Fixes: 107d47b2b95e ("PM: sleep: core: Simplify the SMART_SUSPEND flag handling")
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Suppress sleeping parent warning in special case

Currently, if power.no_callbacks is set, device_prepare() will also set
power.direct_complete for the device. If power.direct_complete is

PM: sleep: Suppress sleeping parent warning in special case

Currently, if power.no_callbacks is set, device_prepare() will also set
power.direct_complete for the device. If power.direct_complete is set
in device_resume(), the clearing of power.is_prepared will be skipped
and if new children appear under the device at that point, a warning
will be printed.

After commit (f76b168b6f11 PM: Rename dev_pm_info.in_suspend to
is_prepared), power.is_prepared is generally cleared in device_resume()
before invoking the resume callback for the device which allows that
callback to add new children without triggering the warning, but this
does not happen for devices with power.direct_complete set.

This problem is visible in USB where usb_set_interface() can be called
before device_complete() clears power.is_prepared for interface devices
and since ep devices are added then, the warning is printed:

usb 1-1: reset high-speed USB device number 3 using ci_hdrc
ep_81: PM: parent 1-1:1.1 should not be sleeping
PM: resume devices took 0.936 seconds

Since it is legitimate to add the ep devices at that point, the
warning above is not particularly useful, so get rid of it by
clearing power.is_prepared in device_resume() for devices with
power.direct_complete set if they have no PM callbacks, in which
case they need not actually resume for the new children to work.

Suggested-by: Rafael J. Wysocki <[email protected]>
Signed-off-by: Xu Yang <[email protected]>
Link: https://patch.msgid.link/[email protected]
[ rjw: New subject, changelog edits, rephrased new code comment ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: sleep: Avoid unnecessary checks in device_prepare_smart_suspend()

Add an optimization (on top of previous changes) to avoid calling
pm_runtime_blocked(), which involves acquiring the device's PM

PM: sleep: Avoid unnecessary checks in device_prepare_smart_suspend()

Add an optimization (on top of previous changes) to avoid calling
pm_runtime_blocked(), which involves acquiring the device's PM spinlock,
for devices with no PM callbacks and runtime PM "blocked".

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally

A recent discussion has revealed that using DPM_FLAG_SMART_SUSPEND
unconditionally is generally problematic because it may lead to
situations in w

PM: sleep: Use DPM_FLAG_SMART_SUSPEND conditionally

A recent discussion has revealed that using DPM_FLAG_SMART_SUSPEND
unconditionally is generally problematic because it may lead to
situations in which the device's runtime PM information is internally
inconsistent or does not reflect its real state [1].

For this reason, change the handling of DPM_FLAG_SMART_SUSPEND so that
it is only taken into account if it is consistently set by the drivers
of all devices having any PM callbacks throughout dependency graphs in
accordance with the following rules:

- The "smart suspend" feature is only enabled for devices whose drivers
ask for it (that is, set DPM_FLAG_SMART_SUSPEND) and for devices
without PM callbacks unless they have never had runtime PM enabled.

- The "smart suspend" feature is not enabled for a device if it has not
been enabled for the device's parent unless the parent does not take
children into account or it has never had runtime PM enabled.

- The "smart suspend" feature is not enabled for a device if it has not
been enabled for one of the device's suppliers taking runtime PM into
account unless that supplier has never had runtime PM enabled.

Namely, introduce a new device PM flag called smart_suspend that is only
set if the above conditions are met and update all DPM_FLAG_SMART_SUSPEND
users to check power.smart_suspend instead of directly checking the
latter.

At the same time, drop the power.set_active flage introduced recently
in commit 3775fc538f53 ("PM: sleep: core: Synchronize runtime PM status
of parents and children") because it is now sufficient to check
power.smart_suspend along with the dev_pm_skip_resume() return value
to decide whether or not pm_runtime_set_active() needs to be called
for the device.

Link: https://lore.kernel.org/linux-pm/CAPDyKFroyU3YDSfw_Y6k3giVfajg3NQGwNWeteJWqpW29BojhQ@mail.gmail.com/ [1]
Fixes: 7585946243d6 ("PM: sleep: core: Restrict power.set_active propagation")
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]> # drivers/pci
Link: https://patch.msgid.link/[email protected]

show more ...

PM: Block enabling of runtime PM during system suspend

If device_prepare() runs on a device that has never had runtime
PM enabled so far, it may reasonably assume that runtime PM will
not be enabled

PM: Block enabling of runtime PM during system suspend

If device_prepare() runs on a device that has never had runtime
PM enabled so far, it may reasonably assume that runtime PM will
not be enabled for that device during the system suspend-resume
cycle currently in progress, but this has never been guaranteed.

To verify this assumption, make device_prepare() arrange for
triggering a device warning accompanied by a call trace dump if
runtime PM is enabled for such a device after it has returned.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: Rearrange documentation related to __pm_runtime_disable()

There are only two callers of __pm_runtime_disable(), one of which is
device_suspend_late() and the other is pm_runtime_disable() that h

PM: Rearrange documentation related to __pm_runtime_disable()

There are only two callers of __pm_runtime_disable(), one of which is
device_suspend_late() and the other is pm_runtime_disable() that has
its own kerneldoc comment and there are no plans to add any more of
them. Since they use different values of the __pm_runtime_disable()
second parameter, the actual code behavior is different in each case,
but it is all documented in the __pm_runtime_disable() kerneldoc comment
which is not particularly straightforward.

For this reason, move the information from the __pm_runtime_disable()
kerneldoc comment to the pm_runtime_disable() one and into a separate
comment in device_suspend_late() and remove the __pm_runtime_disable()
kerneldoc comment altogether.

No functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: core: Restrict power.set_active propagation

Commit 3775fc538f53 ("PM: sleep: core: Synchronize runtime PM status of
parents and children") exposed an issue related to simple_pm_bus_pm_ops

PM: sleep: core: Restrict power.set_active propagation

Commit 3775fc538f53 ("PM: sleep: core: Synchronize runtime PM status of
parents and children") exposed an issue related to simple_pm_bus_pm_ops
that uses pm_runtime_force_suspend() and pm_runtime_force_resume() as
bus type PM callbacks for the noirq phases of system-wide suspend and
resume.

The problem is that pm_runtime_force_suspend() does not distinguish
runtime-suspended devices from devices for which runtime PM has never
been enabled, so if it sees a device with runtime PM status set to
RPM_ACTIVE, it will assume that runtime PM is enabled for that device
and so it will attempt to suspend it with the help of its runtime PM
callbacks which may not be ready for that. As it turns out, this
causes simple_pm_bus_runtime_suspend() to crash due to a NULL pointer
dereference.

Another problem related to the above commit and simple_pm_bus_pm_ops is
that setting runtime PM status of a device handled by the latter to
RPM_ACTIVE will actually prevent it from being resumed because
pm_runtime_force_resume() only resumes devices with runtime PM status
set to RPM_SUSPENDED.

To mitigate these issues, do not allow power.set_active to propagate
beyond the parent of the device with DPM_FLAG_SMART_SUSPEND set that
will need to be resumed, which should be a sufficient stop-gap for the
time being, but they will need to be properly addressed in the future
because in general during system-wide resume it is necessary to resume
all devices in a dependency chain in which at least one device is going
to be resumed.

Fixes: 3775fc538f53 ("PM: sleep: core: Synchronize runtime PM status of parents and children")
Closes: https://lore.kernel.org/linux-pm/[email protected]/
Reported-by: Jon Hunter <[email protected]>
Tested-by: Johan Hovold <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: core: Synchronize runtime PM status of parents and children

Commit 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the
resume phase") overlooked the case in which the parent of a

PM: sleep: core: Synchronize runtime PM status of parents and children

Commit 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the
resume phase") overlooked the case in which the parent of a device with
DPM_FLAG_SMART_SUSPEND set did not use that flag and could be runtime-
suspended before a transition into a system-wide sleep state. In that
case, if the child is resumed during the subsequent transition from
that state into the working state, its runtime PM status will be set to
RPM_ACTIVE, but the runtime PM status of the parent will not be updated
accordingly, even though the parent will be resumed too, because of the
dev_pm_skip_suspend() check in device_resume_noirq().

Address this problem by tracking the need to set the runtime PM status
to RPM_ACTIVE during system-wide resume transitions for devices with
DPM_FLAG_SMART_SUSPEND set and all of the devices depended on by them.

Fixes: 6e176bf8d461 ("PM: sleep: core: Do not skip callbacks in the resume phase")
Closes: https://lore.kernel.org/linux-pm/[email protected]/
Reported-by: Johan Hovold <[email protected]>
Tested-by: Manivannan Sadhasivam <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Johan Hovold <[email protected]>
Tested-by: Johan Hovold <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Allow configuring the DPM watchdog to warn earlier than panic

Allow configuring the DPM watchdog to warn about slow suspend/resume
functions without causing a system panic(). This allows

PM: sleep: Allow configuring the DPM watchdog to warn earlier than panic

Allow configuring the DPM watchdog to warn about slow suspend/resume
functions without causing a system panic(). This allows you to set the
DPM_WATCHDOG_WARNING_TIMEOUT to something like 5 or 10 seconds to get
warnings about slow suspend/resume functions that eventually succeed.

Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Tomasz Figa <[email protected]>
Link: https://patch.msgid.link/20250109125957.v2.1.I4554f931b8da97948f308ecc651b124338ee9603@changeid
[ rjw: Subject edit ]
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: sleep: Update stale comment in device_resume()

There is no function called __device_suspend() any more and it is still
mentioned in a comment in device_resume(), so update that comment.

Signed-

PM: sleep: Update stale comment in device_resume()

There is no function called __device_suspend() any more and it is still
mentioned in a comment in device_resume(), so update that comment.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://patch.msgid.link/[email protected]

show more ...

PM: sleep: Take advantage of %ps to simplify debug output

initcall_debug previous and new output:

...PM: calling pci_pm_suspend+0x0/0x1b0 @ 3233, parent: pci0000:00

...PM: calling pci_pm_suspend @

PM: sleep: Take advantage of %ps to simplify debug output

initcall_debug previous and new output:

...PM: calling pci_pm_suspend+0x0/0x1b0 @ 3233, parent: pci0000:00

...PM: calling pci_pm_suspend @ 3233, parent: pci0000:00

Signed-off-by: Len Brown <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: sleep: Call dpm_async_fn() directly in each suspend phase

Simplify the system-wide suspend of devices by invoking dpm_async_fn()
directly from the main loop in each suspend phase instead of usin

PM: sleep: Call dpm_async_fn() directly in each suspend phase

Simplify the system-wide suspend of devices by invoking dpm_async_fn()
directly from the main loop in each suspend phase instead of using an
additional wrapper function for running it.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

PM: sleep: Move devices to new lists earlier in each suspend phase

During a system-wide suspend of devices, dpm_noirq_suspend_devices(),
dpm_suspend_late() and dpm_suspend() move devices from one li

PM: sleep: Move devices to new lists earlier in each suspend phase

During a system-wide suspend of devices, dpm_noirq_suspend_devices(),
dpm_suspend_late() and dpm_suspend() move devices from one list to
another. They do it with each device after its PM callback in the
given suspend phase has run or has been scheduled for asynchronous
execution, in case it is deleted from the current list in the
meantime.

However, devices can be moved to a new list before invoking their PM
callbacks (which usually is the case for the devices whose callbacks
are executed asynchronously anyway), because doing so does not affect
the ordering of that list. In either case, each device is moved to
the new list after the previous device has been moved to it or gone
away, and if a device is removed, it does not matter which list it is
in at that point, because deleting an entry from a list does not change
the ordering of the other entries in it.

Accordingly, modify the functions mentioned above to move devices to
new lists without waiting for their PM callbacks to run regardless of
whether or not they run asynchronously.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

PM: sleep: Move some assignments from under a lock

The async_error and pm_transition variables are set under dpm_list_mtx
in multiple places in the system-wide device PM core code, which is
unnecess

PM: sleep: Move some assignments from under a lock

The async_error and pm_transition variables are set under dpm_list_mtx
in multiple places in the system-wide device PM core code, which is
unnecessary and confusing, so rearrange the code so that the variables
in question are set before acquiring the lock.

While at it, add some empty code lines around locking to improve the
consistency of the code.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

PM: sleep: stats: Log errors right after running suspend callbacks

The error logging and failure statistics updates are carried out in two
places in each system-wide device suspend phase, which is u

PM: sleep: stats: Log errors right after running suspend callbacks

The error logging and failure statistics updates are carried out in two
places in each system-wide device suspend phase, which is unnecessary
code duplication, so do that in one place in each phase, right after
invoking device suspend callbacks.

While at it, add "noirq" or "late" to the "async" string printed when
the failing device callback in the "noirq" or "late" suspend phase,
respectively, was run asynchronously.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

PM: sleep: stats: Call dpm_save_failed_step() at most once per phase

If the handling of two or more devices fails in one suspend-resume
phase, it should be counted once in the statistics which is no

PM: sleep: stats: Call dpm_save_failed_step() at most once per phase

If the handling of two or more devices fails in one suspend-resume
phase, it should be counted once in the statistics which is not
guaranteed to happen during system-wide resume of devices due to
the possible asynchronous execution of device callbacks.

Address this by using the async_error static variable during system-wide
device resume to indicate that there has been a device resume error and
the given suspend-resume phase should be counted as failing.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Stanislaw Gruszka <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

PM: sleep: stats: Define suspend_stats next to the code using it

It is not necessary to define struct suspend_stats in a header file and the
suspend_stats variable in the core device system-wide PM

PM: sleep: stats: Define suspend_stats next to the code using it

It is not necessary to define struct suspend_stats in a header file and the
suspend_stats variable in the core device system-wide PM code. They both
can be defined in kernel/power/main.c, next to the sysfs and debugfs code
accessing suspend_stats, which can be static.

Modify the code in question in accordance with the above observation and
replace the static inline functions manipulating suspend_stats with
regular ones defined in kernel/power/main.c.

While at it, move the enum suspend_stat_step to the end of suspend.h which
is a more suitable place for it.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...