PM: runtime: Unify error handling during suspend and resume

There is a confusing difference in error handling between rpm_suspend()
and rpm_resume() related to the special way in which -EAGAIN and -

PM: runtime: Unify error handling during suspend and resume

There is a confusing difference in error handling between rpm_suspend()
and rpm_resume() related to the special way in which -EAGAIN and -EBUSY
error values are treated by the former. Also, converting -EACCES coming
from the callback to I/O error, which it quite likely is not, may
confuse runtime PM users.

To address the above, modify rpm_callback() to convert -EACCES coming
from the driver to -EAGAIN and to set power.runtime_error only if the
return value is not -EAGAIN or -EBUSY.

This will cause the error handling in rpm_resume() and rpm_suspend() to
work consistently, so drop the no longer needed -EAGAIN or -EBUSY
special case from the latter and make it retry autosuspend if
power.runtime_error is unset.

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: runtime: Convert pm_runtime_blocked() to static inline

The comment in pm_runtime_blocked() is acutally wrong: power.last_status
is not a bit field. Its data type is an enum and so one can reaso

PM: runtime: Convert pm_runtime_blocked() to static inline

The comment in pm_runtime_blocked() is acutally wrong: power.last_status
is not a bit field. Its data type is an enum and so one can reasonably
assume that partial updates of it will not be observed.

Accordingly, pm_runtime_blocked() can be converted to a static inline
function and the related locking overhead can be eliminated, so long
as it is only used in system suspend/resume code paths because
power.last_status is not expected to be updated concurrently while
that code is running.

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: runtime: Drop status check from pm_runtime_force_resume()

Since pm_runtime_force_resume() requires pm_runtime_force_suspend() to
be called before it on the same device, the runtime PM status of

PM: runtime: Drop status check from pm_runtime_force_resume()

Since pm_runtime_force_resume() requires pm_runtime_force_suspend() to
be called before it on the same device, the runtime PM status of the
device is RPM_SUSPENDED when it is called unless the device's runtime
PM status is changed somewhere else in the meantime.

However, even if that happens, the power.needs_force_resume
check is still required to pass and that flag is only set by
pm_runtime_force_suspend() once and it is cleared at the end of
pm_runtime_force_resume(), so it cannot be taken into account
twice in a row.

According to the above, the pm_runtime_status_suspended(dev) check in
pm_runtime_force_resume() is redundant, so drop it.

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: 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: runtime: Introduce pm_runtime_blocked()

Introduce a new helper function called pm_runtime_blocked()
for checking the power.last_status value indicating whether or not
enabling runtime PM for the

PM: runtime: Introduce pm_runtime_blocked()

Introduce a new helper function called pm_runtime_blocked()
for checking the power.last_status value indicating whether or not
enabling runtime PM for the given device has been blocked (which
happens in the "prepare" phase of system-wide suspend if runtime
PM is disabled for the given device at that point).

Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
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: runtime: Switch to use hrtimer_setup()

hrtimer_setup() takes the callback function pointer as argument and
initializes the timer completely.

Replace hrtimer_init() and the open coded initializa

PM: runtime: Switch to use hrtimer_setup()

hrtimer_setup() takes the callback function pointer as argument and
initializes the timer completely.

Replace hrtimer_init() and the open coded initialization of
hrtimer::function with the new setup mechanism.

Patch was created by using Coccinelle.

Signed-off-by: Nam Cao <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Link: https://lore.kernel.org/all/8d1ce108b043896733ce08d3deea6e84941d499b.1738746821.git.namcao@linutronix.de

show more ...

PM: runtime: add tracepoint for runtime_status changes

Existing runtime PM ftrace events (`rpm_suspend`, `rpm_resume`,
`rpm_return_int`) offer limited visibility into the exact timing of device
runt

PM: runtime: add tracepoint for runtime_status changes

Existing runtime PM ftrace events (`rpm_suspend`, `rpm_resume`,
`rpm_return_int`) offer limited visibility into the exact timing of device
runtime power state transitions, particularly when asynchronous operations
are involved. When the `rpm_suspend` or `rpm_resume` functions are invoked
with the `RPM_ASYNC` flag, a return value of 0 i.e., success merely
indicates that the device power state request has been queued, not that
the device has yet transitioned.

A new ftrace event, `rpm_status`, is introduced. This event directly logs
the `power.runtime_status` value of a device whenever it changes providing
granular tracking of runtime power state transitions regardless of
synchronous or asynchronous `rpm_suspend` / `rpm_resume` usage.

Signed-off-by: Vilas Bhat <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: runtime: Simplify pm_runtime_get_if_active() usage

There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_ge

PM: runtime: Simplify pm_runtime_get_if_active() usage

There are two ways to opportunistically increment a device's runtime PM
usage count, calling either pm_runtime_get_if_active() or
pm_runtime_get_if_in_use(). The former has an argument to tell whether to
ignore the usage count or not, and the latter simply calls the former with
ign_usage_count set to false. The other users that want to ignore the
usage_count will have to explicitly set that argument to true which is a
bit cumbersome.

To make this function more practical to use, remove the ign_usage_count
argument from the function. The main implementation is in a static
function called pm_runtime_get_conditional() and implementations of
pm_runtime_get_if_active() and pm_runtime_get_if_in_use() are moved to
runtime.c.

Signed-off-by: Sakari Ailus <[email protected]>
Reviewed-by: Alex Elder <[email protected]>
Reviewed-by: Laurent Pinchart <[email protected]>
Acked-by: Takashi Iwai <[email protected]> # sound/
Reviewed-by: Jacek Lawrynowicz <[email protected]> # drivers/accel/ivpu/
Acked-by: Rodrigo Vivi <[email protected]> # drivers/gpu/drm/i915/
Reviewed-by: Rodrigo Vivi <[email protected]>
Acked-by: Bjorn Helgaas <[email protected]> # drivers/pci/
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

PM: fix missing rculist.h dependency

Signed-off-by: Kent Overstreet <[email protected]>

PM: runtime: Document that force_suspend() is incompatible with SMART_SUSPEND

pm_runtime_force_suspend() cannot be used with DPM_FLAG_SMART_SUSPEND, so
note this in the kerneldoc.

If DPM_FLAG_SMART

PM: runtime: Document that force_suspend() is incompatible with SMART_SUSPEND

pm_runtime_force_suspend() cannot be used with DPM_FLAG_SMART_SUSPEND, so
note this in the kerneldoc.

If DPM_FLAG_SMART_SUSPEND is set and the PM core cannot skip system resume
it will call pm_runtime_active() on the driver. This can lead to an
inconsistent state where:

pm_runtime_force_suspend() called ->runtime_suspend

but

device_resume_noirq() called pm_runtime_set_active()

This leaves the driver actually suspended but marked as active.

Signed-off-by: Richard Fitzgerald <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...

cpuidle, ARM: OMAP2+: powerdomain: Remove trace_.*_rcuidle()

OMAP was the one and only user.

Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]

cpuidle, ARM: OMAP2+: powerdomain: Remove trace_.*_rcuidle()

OMAP was the one and only user.

Signed-off-by: Peter Zijlstra (Intel) <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Tested-by: Tony Lindgren <[email protected]>
Tested-by: Ulf Hansson <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Frederic Weisbecker <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

PM: runtime: Adjust white space in the core code

Some inconsistent usage of white space in the PM-runtime core code
causes that code to be somewhat harder to read that it would have
been otherwise,

PM: runtime: Adjust white space in the core code

Some inconsistent usage of white space in the PM-runtime core code
causes that code to be somewhat harder to read that it would have
been otherwise, so adjust the white space in there to be more
consistent with the rest of the code.

No expected functional impact.

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

show more ...

PM: runtime: Relocate rpm_callback() right after __rpm_callback()

Because rpm_callback() is a wrapper around __rpm_callback(), and the
only caller of it after the change eliminating an invocation of

PM: runtime: Relocate rpm_callback() right after __rpm_callback()

Because rpm_callback() is a wrapper around __rpm_callback(), and the
only caller of it after the change eliminating an invocation of it
from rpm_idle(), move the former next to the latter to make the code
a bit easier to follow.

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

show more ...

PM: runtime: Do not call __rpm_callback() from rpm_idle()

Calling __rpm_callback() from rpm_idle() after adding device links
support to the former is a clear mistake.

Not only it causes rpm_idle()

PM: runtime: Do not call __rpm_callback() from rpm_idle()

Calling __rpm_callback() from rpm_idle() after adding device links
support to the former is a clear mistake.

Not only it causes rpm_idle() to carry out unnecessary actions, but it
is also against the assumption regarding the stability of PM-runtime
status across __rpm_callback() invocations, because rpm_suspend() and
rpm_resume() may run in parallel with __rpm_callback() when it is called
by rpm_idle() and the device's PM-runtime status can be updated by any
of them.

Fixes: 21d5c57b3726 ("PM / runtime: Use device links")
Link: https://lore.kernel.org/linux-pm/[email protected]
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Adrian Hunter <[email protected]>

show more ...

PM: runtime: Return -EINPROGRESS from rpm_resume() in the RPM_NOWAIT case

The prospective callers of rpm_resume() passing RPM_NOWAIT to it may
be confused when it returns 0 without actually resuming

PM: runtime: Return -EINPROGRESS from rpm_resume() in the RPM_NOWAIT case

The prospective callers of rpm_resume() passing RPM_NOWAIT to it may
be confused when it returns 0 without actually resuming the device
which may happen if the device is suspending at the given time and it
will only resume when the suspend in progress has completed. To avoid
that confusion, return -EINPROGRESS from rpm_resume() in that case.

Since none of the current callers passing RPM_NOWAIT to rpm_resume()
check its return value, this change has no functional impact.

Signed-off-by: Rafael J. Wysocki <[email protected]>
Acked-by: Alan Stern <[email protected]>
Reviewed-by: Douglas Anderson <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>

show more ...

PM: runtime: Extend support for wakeirq for force_suspend|resume

A driver that makes use of pm_runtime_force_suspend|resume() to support
system suspend/resume, currently needs to manage the wakeirq

PM: runtime: Extend support for wakeirq for force_suspend|resume

A driver that makes use of pm_runtime_force_suspend|resume() to support
system suspend/resume, currently needs to manage the wakeirq support
itself. To avoid the boilerplate code in the driver's system suspend/resume
callbacks in particular, let's extend pm_runtime_force_suspend|resume() to
deal with the wakeirq.

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

show more ...

PM: runtime: Fix supplier device management during consumer probe

Because pm_runtime_get_suppliers() bumps up the rpm_active counter
of each device link to a supplier of the given device in addition

PM: runtime: Fix supplier device management during consumer probe

Because pm_runtime_get_suppliers() bumps up the rpm_active counter
of each device link to a supplier of the given device in addition
to bumping up the supplier's PM-runtime usage counter, a runtime
suspend of the consumer device may case the latter to go down to 0
when pm_runtime_put_suppliers() is running on a remote CPU. If that
happens after pm_runtime_put_suppliers() has released power.lock for
the consumer device, and a runtime resume of that device takes place
immediately after it, before pm_runtime_put() is called for the
supplier, that pm_runtime_put() call may cause the supplier to be
suspended even though the consumer is active.

To prevent that from happening, modify pm_runtime_get_suppliers() to
call pm_runtime_get_sync() for the given device's suppliers without
touching the rpm_active counters of the involved device links
Accordingly, modify pm_runtime_put_suppliers() to call pm_runtime_put()
for the given device's suppliers without looking at the rpm_active
counters of the device links at hand. [This is analogous to what
happened before commit 4c06c4e6cf63 ("driver core: Fix possible
supplier PM-usage counter imbalance").]

Since pm_runtime_get_suppliers() sets supplier_preactivated for each
device link where the supplier's PM-runtime usage counter has been
incremented and pm_runtime_put_suppliers() calls pm_runtime_put() for
the suppliers whose device links have supplier_preactivated set, the
PM-runtime usage counter is balanced for each supplier and this is
independent of the runtime suspend and resume of the consumer device.

However, in case a device link with DL_FLAG_PM_RUNTIME set is dropped
during the consumer device probe, so pm_runtime_get_suppliers() bumps
up the supplier's PM-runtime usage counter, but it cannot be dropped by
pm_runtime_put_suppliers(), make device_link_release_fn() take care of
that.

Fixes: 4c06c4e6cf63 ("driver core: Fix possible supplier PM-usage counter imbalance")
Reported-by: Peter Wang <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Reviewed-by: Peter Wang <[email protected]>
Cc: 5.1+ <[email protected]> # 5.1+

show more ...

PM: runtime: Redefine pm_runtime_release_supplier()

Instead of passing an extra bool argument to pm_runtime_release_supplier(),
make its callers take care of triggering a runtime-suspend of the
supp

PM: runtime: Redefine pm_runtime_release_supplier()

Instead of passing an extra bool argument to pm_runtime_release_supplier(),
make its callers take care of triggering a runtime-suspend of the
supplier device as needed.

No expected functional impact.

Suggested-by: Greg Kroah-Hartman <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>
Reviewed-by: Greg Kroah-Hartman <[email protected]>
Cc: 5.1+ <[email protected]> # 5.1+

show more ...

PM: runtime: Allow to call __pm_runtime_set_status() from atomic context

The only two users of __pm_runtime_set_status() are pm_runtime_set_active()
and pm_runtime_set_suspended(). These are widely

PM: runtime: Allow to call __pm_runtime_set_status() from atomic context

The only two users of __pm_runtime_set_status() are pm_runtime_set_active()
and pm_runtime_set_suspended(). These are widely used and should be called
from non-atomic context to work as expected. However, it would be
convenient to allow them be called from atomic context too, as shown from a
subsequent change, so let's add support for this.

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

show more ...

PM: runtime: Avoid device usage count underflows

A PM-runtime device usage count underflow is potentially critical,
because it may cause a device to be suspended when it is expected to
be operationa

PM: runtime: Avoid device usage count underflows

A PM-runtime device usage count underflow is potentially critical,
because it may cause a device to be suspended when it is expected to
be operational. It is also a programming problem that would be good
to catch and warn about.

For this reason, (1) make rpm_check_suspend_allowed() return an error
when the device usage count is negative to prevent devices from being
suspended in that case, (2) introduce rpm_drop_usage_count() that will
detect device usage count underflows, warn about them and fix them up,
and (3) use it to drop the usage count in a few places instead of
atomic_dec_and_test().

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

show more ...

PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()

The PM Runtime docs say:

Drivers in ->remove() callback should undo the runtime PM changes done
in ->probe().

PM: runtime: Have devm_pm_runtime_enable() handle pm_runtime_dont_use_autosuspend()

The PM Runtime docs say:

Drivers in ->remove() callback should undo the runtime PM changes done
in ->probe(). Usually this means calling pm_runtime_disable(),
pm_runtime_dont_use_autosuspend() etc.

From grepping code, it's clear that many people aren't aware of the
need to call pm_runtime_dont_use_autosuspend().

When brainstorming solutions, one idea that came up was to leverage
the new-ish devm_pm_runtime_enable() function. The idea here is that:

* When the devm action is called we know that the driver is being
removed. It's the perfect time to undo the use_autosuspend.

* The code of pm_runtime_dont_use_autosuspend() already handles the
case of being called when autosuspend wasn't enabled.

Suggested-by: Laurent Pinchart <[email protected]>
Signed-off-by: Douglas Anderson <[email protected]>
Reviewed-by: Ulf Hansson <[email protected]>
Signed-off-by: Rafael J. Wysocki <[email protected]>

show more ...