kernel/linux.git/drivers/base/power, branch v4.19.39

PM / Domains: Avoid a potential deadlock

2019-04-20T07:15:58+00:00

[ Upstream commit 2071ac985d37efe496782c34318dbead93beb02f ] Lockdep warns that prepare_lock and genpd->mlock can cause a deadlock the deadlock scenario is like following: First thread is probing cs2000 cs2000_probe() clk_register() __clk_core_init() clk_prepare_lock() ----> acquires prepare_lock cs2000_recalc_rate() i2c_smbus_read_byte_data() rcar_i2c_master_xfer() dma_request_chan() rcar_dmac_of_xlate() rcar_dmac_alloc_chan_resources() pm_runtime_get_sync() __pm_runtime_resume() rpm_resume() rpm_callback() genpd_runtime_resume() ----> acquires genpd->mlock Second thread is attaching any device to the same PM domain genpd_add_device() genpd_lock() ----> acquires genpd->mlock cpg_mssr_attach_dev() of_clk_get_from_provider() __of_clk_get_from_provider() __clk_create_clk() clk_prepare_lock() ----> acquires prepare_lock Since currently no PM provider access genpd's critical section in .attach_dev, and .detach_dev callbacks, so there is no need to protect these two callbacks with genpd->mlock. This patch avoids a potential deadlock by moving out .attach_dev and .detach_dev from genpd->mlock, so that genpd->mlock won't be held when prepare_lock is acquired in .attach_dev and .detach_dev Signed-off-by: Jiada Wang Reviewed-by: Ulf Hansson Tested-by: Geert Uytterhoeven Reviewed-by: Geert Uytterhoeven Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

PM / wakeup: Rework wakeup source timer cancellation

2019-03-23T19:10:10+00:00

commit 1fad17fb1bbcd73159c2b992668a6957ecc5af8a upstream. If wakeup_source_add() is called right after wakeup_source_remove() for the same wakeup source, timer_setup() may be called for a potentially scheduled timer which is incorrect. To avoid that, move the wakeup source timer cancellation from wakeup_source_drop() to wakeup_source_remove(). Moreover, make wakeup_source_remove() clear the timer function after canceling the timer to let wakeup_source_not_registered() treat unregistered wakeup sources in the same way as the ones that have never been registered. Signed-off-by: Viresh Kumar Cc: 4.4+ # 4.4+ [ rjw: Subject, changelog, merged two patches together ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

PM / core: Clear the direct_complete flag on errors

2018-10-04T17:39:31+00:00

If __device_suspend() runs asynchronously (in which case the device passed to it is in dpm_suspended_list at that point) and it returns early on an error or pending wakeup, and the power.direct_complete flag has been set for the device already, the subsequent device_resume() will be confused by that and it will call pm_runtime_enable() incorrectly, as runtime PM has not been disabled for the device by __device_suspend(). To avoid that, clear power.direct_complete if __device_suspend() is not going to disable runtime PM for the device before returning. Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily) Reported-by: Al Cooper Tested-by: Al Cooper Reviewed-by: Ulf Hansson Cc: 3.16+ # 3.16+ Signed-off-by: Rafael J. Wysocki

PM / clk: signedness bug in of_pm_clk_add_clks()

2018-08-24T09:52:34+00:00

"count" needs to be signed for the error handling to work. I made "i" signed as well so they match. Fixes: 02113ba93ea4 (PM / clk: Add support for obtaining clocks from device-tree) Cc: 4.6+ # 4.6+ Signed-off-by: Dan Carpenter Signed-off-by: Rafael J. Wysocki

Merge tag 'driver-core-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core

2018-08-18T18:44:53+00:00

Pull driver core updates from Greg KH: "Here are all of the driver core and related patches for 4.19-rc1. Nothing huge here, just a number of small cleanups and the ability to now stop the deferred probing after init happens. All of these have been in linux-next for a while with only a merge issue reported" * tag 'driver-core-4.19-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (21 commits) base: core: Remove WARN_ON from link dependencies check drivers/base: stop new probing during shutdown drivers: core: Remove glue dirs from sysfs earlier driver core: remove unnecessary function extern declare sysfs.h: fix non-kernel-doc comment PM / Domains: Stop deferring probe at the end of initcall iommu: Remove IOMMU_OF_DECLARE iommu: Stop deferring probe at end of initcalls pinctrl: Support stopping deferred probe after initcalls dt-bindings: pinctrl: add a 'pinctrl-use-default' property driver core: allow stopping deferred probe after init driver core: add a debugfs entry to show deferred devices sysfs: Fix internal_create_group() for named group updates base: fix order of OF initialization linux/device.h: fix kernel-doc notation warning Documentation: update firmware loader fallback reference kobject: Replace strncpy with memcpy drivers: base: cacheinfo: use OF property_read_u32 instead of get_property,read_number kernfs: Replace strncpy with memcpy device: Add #define dev_fmt similar to #define pr_fmt ...

Merge 4.18-rc7 into driver-core-next

2018-07-30T08:08:09+00:00

We need the driver core changes in here as well for testing. Signed-off-by: Greg Kroah-Hartman

PM / Domains: Stop deferring probe at the end of initcall

2018-07-10T15:22:35+00:00

All PM domain drivers must be built-in (at least those using DT), so there is no point deferring probe after initcalls are done. Continuing to defer probe may prevent booting successfully even if managing PM domains is not required. This can happen if the user failed to enable the driver or if power-domains are added to a platform's DT, but there is not yet a driver (e.g. a new DTB with an old kernel). Call the driver core function driver_deferred_probe_check_init_done() instead of just returning -EPROBE_DEFER to stop deferring probe when initcalls are done. Acked-by: "Rafael J. Wysocki" Cc: Kevin Hilman Cc: Ulf Hansson Cc: Pavel Machek Cc: Len Brown Cc: Greg Kroah-Hartman Cc: linux-pm@vger.kernel.org Signed-off-by: Rob Herring Signed-off-by: Greg Kroah-Hartman

PM / Domains: Introduce dev_pm_domain_attach_by_name()

2018-07-09T10:11:02+00:00

For the multiple PM domain case, let's introduce a new API called dev_pm_domain_attach_by_name(). This allows a consumer driver to associate its device with one of its PM domains, by using a name based lookup. Do note that, currently it's only genpd that supports multiple PM domains per device, but dev_pm_domain_attach_by_name() can easily by extended to cover other PM domain types, if/when needed. Signed-off-by: Ulf Hansson Tested-by: Rajendra Nayak Reviewed-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

PM / Domains: Introduce option to attach a device by name to genpd

2018-07-09T10:11:02+00:00

For the multiple PM domain case, let's introduce a new function called genpd_dev_pm_attach_by_name(). This allows a device to be associated with its PM domain through genpd, by using a name based lookup. Note that, genpd_dev_pm_attach_by_name() shall only be called by the driver core / PM core, similar to how the existing dev_pm_domain_attach_by_id() makes use of genpd_dev_pm_attach_by_id(). However, this is implemented by following changes on top. Signed-off-by: Ulf Hansson Tested-by: Rajendra Nayak Reviewed-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

PM / Domains: Don't power on at attach for the multi PM domain case

2018-07-03T14:42:51+00:00

There are no legacy behavior in drivers to consider while attaching a device to genpd - for the multiple PM domain case. For that reason, let's instead require the driver to runtime resume the device, via calling pm_runtime_get_sync() for example, when it needs to power on the corresponding PM domain. This allows us to improve the situation during attach. Instead of always power on the PM domain, which may be unnecessary, let's leave it in its current state. Additionally, to avoid the PM domain to stay powered on, let's schedule a power off work. Fixes: 3c095f32a92b (PM / Domains: Add support for multi PM domains ...) Signed-off-by: Ulf Hansson Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki