diff options
author | 2022-06-30 21:16:41 +0200 | |
---|---|---|
committer | 2022-07-01 21:04:15 +0200 | |
commit | 887371066039011144b4a94af97d9328df6869a2 (patch) | |
tree | d5e2d98d1beb583bc4276618c5af4e493a759c10 /drivers/base/core.c | |
parent | PM: runtime: Redefine pm_runtime_release_supplier() (diff) | |
download | linux-887371066039011144b4a94af97d9328df6869a2.tar.gz linux-887371066039011144b4a94af97d9328df6869a2.tar.bz2 linux-887371066039011144b4a94af97d9328df6869a2.zip |
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+
Diffstat (limited to 'drivers/base/core.c')
-rw-r--r-- | drivers/base/core.c | 10 |
1 files changed, 10 insertions, 0 deletions
diff --git a/drivers/base/core.c b/drivers/base/core.c index 58aa49527d3a..460d6f163e41 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -487,6 +487,16 @@ static void device_link_release_fn(struct work_struct *work) device_link_synchronize_removal(); pm_runtime_release_supplier(link); + /* + * If supplier_preactivated is set, the link has been dropped between + * the pm_runtime_get_suppliers() and pm_runtime_put_suppliers() calls + * in __driver_probe_device(). In that case, drop the supplier's + * PM-runtime usage counter to remove the reference taken by + * pm_runtime_get_suppliers(). + */ + if (link->supplier_preactivated) + pm_runtime_put_noidle(link->supplier); + pm_request_idle(link->supplier); put_device(link->consumer); |