Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13 |
|
#
450316dc |
| 13-Dec-2022 |
Richard Fitzgerald <rf@opensource.cirrus.com> |
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 <rf@opensource.cirrus.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
db8f5086 |
| 12-Jan-2023 |
Peter Zijlstra <peterz@infradead.org> |
cpuidle, ARM: OMAP2+: powerdomain: Remove trace_.*_rcuidle()
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.or
cpuidle, ARM: OMAP2+: powerdomain: Remove trace_.*_rcuidle()
OMAP was the one and only user.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Tested-by: Tony Lindgren <tony@atomide.com> Tested-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Frederic Weisbecker <frederic@kernel.org> Link: https://lore.kernel.org/r/20230112195541.782536366@infradead.org
show more ...
|
Revision tags: v6.1, v6.0.12 |
|
#
dbfa4478 |
| 05-Dec-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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 <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.0.11 |
|
#
0307f4e8 |
| 02-Dec-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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 <rafael.j.wysocki@intel.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
show more ...
|
#
bc80c2e4 |
| 02-Dec-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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/36aed941-a73e-d937-2721-4f0decd61ce0@quicinc.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Adrian Hunter <adrian.hunter@intel.com>
show more ...
|
Revision tags: v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70 |
|
#
e66332a4 |
| 22-Sep-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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 <rafael.j.wysocki@intel.com> Acked-by: Alan Stern <stern@rowland.harvard.edu> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46 |
|
#
c46a0d5a |
| 08-Jun-2022 |
Ulf Hansson <ulf.hansson@linaro.org> |
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 <ulf.hansson@linaro.org> Reviewed-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
88737106 |
| 30-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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 <peter.wang@mediatek.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Peter Wang <peter.wang@mediatek.com> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
show more ...
|
#
07358194 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+
show more ...
|
Revision tags: v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
13966517 |
| 01-Apr-2022 |
Ulf Hansson <ulf.hansson@linaro.org> |
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 <ulf.hansson@linaro.org> Tested-by: Maulik Shah <quic_mkshah@quicinc.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
82586a72 |
| 13-Apr-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
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 <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26 |
|
#
b4060db9 |
| 23-Feb-2022 |
Douglas Anderson <dianders@chromium.org> |
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 <laurent.pinchart@ideasonboard.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16 |
|
#
50a46066 |
| 17-Dec-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Simplify locking in pm_runtime_put_suppliers()
Notice that pm_runtime_put_suppliers() cannot be called with disabled interrupts, because it may sleep (due to the device links read locki
PM: runtime: Simplify locking in pm_runtime_put_suppliers()
Notice that pm_runtime_put_suppliers() cannot be called with disabled interrupts, because it may sleep (due to the device links read locking in the non-SRCU case), and so it can use spin_lock_irq() and spin_unlock_irq() for the locking.
Update the function accordingly and while at it move the "put" local variable in it into the inner block where it is used.
This change is not expected to have any visible functional impact.
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
show more ...
|
Revision tags: v5.15.10, v5.15.9, v5.15.8 |
|
#
d1579e61 |
| 10-Dec-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Add safety net to supplier device release
Because refcount_dec_not_one() returns true if the target refcount becomes saturated, it is generally unsafe to use its return value as a loop
PM: runtime: Add safety net to supplier device release
Because refcount_dec_not_one() returns true if the target refcount becomes saturated, it is generally unsafe to use its return value as a loop termination condition, but that is what happens when a device link's supplier device is released during runtime PM suspend operations and on device link removal.
To address this, introduce pm_runtime_release_supplier() to be used in the above cases which will check the supplier device's runtime PM usage counter in addition to the refcount_dec_not_one() return value, so the loop can be terminated in case the rpm_active refcount value becomes invalid, and update the code in question to use it as appropriate.
This change is not expected to have any visible functional impact.
Reported-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
show more ...
|
Revision tags: v5.15.7 |
|
#
c24efa67 |
| 07-Dec-2021 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Capture device status before disabling runtime PM
In some cases (for example, during system-wide suspend and resume of devices) it is useful to know whether or not runtime PM has ever b
PM: runtime: Capture device status before disabling runtime PM
In some cases (for example, during system-wide suspend and resume of devices) it is useful to know whether or not runtime PM has ever been enabled for a given device and, if so, what the runtime PM status of it had been right before runtime PM was disabled for it last time.
For this reason, introduce a new struct dev_pm_info field called last_status that will be used for capturing the runtime PM status of the device when its power.disable_depth counter changes from 0 to 1.
The new field will be set to RPM_INVALID to start with and whenever power.disable_depth changes from 1 to 0, so it will be valid only when runtime PM of the device is currently disabled, but it has been enabled at least once.
Immediately use power.last_status in rpm_resume() to make it handle the case when PM runtime is disabled for the device, but its runtime PM status is RPM_ACTIVE more consistently. Namely, make it return 1 if power.last_status is also equal to RPM_ACTIVE in that case (the idea being that if the status was RPM_ACTIVE last time when power.disable_depth was changing from 0 to 1 and it is still RPM_ACTIVE, it can be assumed to reflect what happened to the device last time when it was using runtime PM) and -EACCES otherwise.
Update the documentation to provide a description of last_status and change the description of pm_runtime_resume() in it to reflect the new behavior of rpm_active().
While at it, rearrange the code in pm_runtime_enable() to be more straightforward and replace the WARN() macro in it with a pr_warn() invocation which is less disruptive.
Link: https://lore.kernel.org/linux-pm/20211026222626.39222-1-ulf.hansson@linaro.org/t/#u Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15 |
|
#
25971410 |
| 25-Oct-2021 |
Chunfeng Yun <chunfeng.yun@mediatek.com> |
PM / wakeirq: support enabling wake-up irq after runtime_suspend called
When the dedicated wake IRQ is level trigger, and it uses the device's low-power status as the wakeup source, that means if th
PM / wakeirq: support enabling wake-up irq after runtime_suspend called
When the dedicated wake IRQ is level trigger, and it uses the device's low-power status as the wakeup source, that means if the device is not in low-power state, the wake IRQ will be triggered if enabled; For this case, need enable the wake IRQ after running the device's ->runtime_suspend() which make it enter low-power state.
e.g. Assume the wake IRQ is a low level trigger type, and the wakeup signal comes from the low-power status of the device. The wakeup signal is low level at running time (0), and becomes high level when the device enters low-power state (runtime_suspend (1) is called), a wakeup event at (2) make the device exit low-power state, then the wakeup signal also becomes low level.
------------------ | ^ ^| ---------------- | | -------------- |<---(0)--->|<--(1)--| (3) (2) (4)
if enable the wake IRQ before running runtime_suspend during (0), a wake IRQ will arise, it causes resume immediately; it works if enable wake IRQ ( e.g. at (3) or (4)) after running ->runtime_suspend().
This patch introduces a new status WAKE_IRQ_DEDICATED_REVERSE to optionally support enabling wake IRQ after running ->runtime_suspend().
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Chunfeng Yun <chunfeng.yun@mediatek.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
79827e53 |
| 27-Jun-2022 |
Rafael J. Wysocki <rafael.j.wysocki@intel.com> |
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
Instead of passing an extra bool argument to pm_runtime_release_supplier(), make its ca
PM: runtime: Redefine pm_runtime_release_supplier()
commit 07358194badf73e267289b40b761f5dc56928eab upstream.
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 <gregkh@linuxfoundation.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: 5.1+ <stable@vger.kernel.org> # 5.1+ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|