linux-stable.git/drivers/devfreq, branch v5.4.13

PM / devfreq: tegra: Add COMMON_CLK dependency

2020-01-17T18:48:22+00:00

commit 5fdb0684b5b0f41402161f068d3d84bf6ed1c3f4 upstream.

Compile-testing this driver fails if CONFIG_COMMON_CLK is not set:

drivers/devfreq/tegra30-devfreq.o: In function `tegra_devfreq_target':
tegra30-devfreq.c:(.text+0x164): undefined reference to `clk_set_min_rate'

Fixes: 35f8dbc72721 ("PM / devfreq: tegra: Enable COMPILE_TEST for the driver")
Signed-off-by: Arnd Bergmann 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: Check NULL governor in available_governors_show

2020-01-09T09:20:01+00:00

commit d68adc8f85cd757bd33c8d7b2660ad6f16f7f3dc upstream.

The governor is initialized after sysfs attributes become visible so in
theory the governor field can be NULL here.

Fixes: bcf23c79c4e46 ("PM / devfreq: Fix available_governor sysfs")
Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: Don't fail devfreq_dev_release if not in list

2020-01-09T09:19:43+00:00

[ Upstream commit 42a6b25e67df6ee6675e8d1eaf18065bd73328ba ]

Right now devfreq_dev_release will print a warning and abort the rest of
the cleanup if the devfreq instance is not part of the global
devfreq_list. But this is a valid scenario, for example it can happen if
the governor can't be found or on any other init error that happens
after device_register.

Initialize devfreq->node to an empty list head in devfreq_add_device so
that list_del becomes a safe noop inside devfreq_dev_release and we can
continue the rest of the cleanup.

Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Set scaling_max_freq to max on OPP notifier error

2020-01-09T09:19:43+00:00

[ Upstream commit e7cc792d00049c874010b398a27c3cc7bc8fef34 ]

The devfreq_notifier_call functions will update scaling_min_freq and
scaling_max_freq when the OPP table is updated.

If fetching the maximum frequency fails then scaling_max_freq remains
set to zero which is confusing. Set to ULONG_MAX instead so we don't
need special handling for this case in other places.

Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Fix devfreq_notifier_call returning errno

2020-01-09T09:19:43+00:00

[ Upstream commit e876e710ede23f670494331e062d643928e4142a ]

Notifier callbacks shouldn't return negative errno but one of the
NOTIFY_OK/DONE/BAD values.

The OPP core will ignore return values from notifiers but returning a
value that matches NOTIFY_STOP_MASK will stop the notification chain.

Fix by always returning NOTIFY_OK.

Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Lock devfreq in trans_stat_show

2019-12-17T18:56:26+00:00

commit 2abb0d5268ae7b5ddf82099b1f8d5aa8414637d4 upstream.

There is no locking in this sysfs show function so stats printing can
race with a devfreq_update_status called as part of freq switching or
with initialization.

Also add an assert in devfreq_update_status to make it clear that lock
must be held by caller.

Fixes: 39688ce6facd ("PM / devfreq: account suspend/resume for stats")
Cc: stable@vger.kernel.org
Signed-off-by: Leonard Crestez 
Reviewed-by: Matthias Kaehlcke 
Reviewed-by: Chanwoo Choi 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: passive: fix compiler warning

2019-08-26T12:37:37+00:00

The recent commit of
PM / devfreq: passive: Use non-devm notifiers
had incurred compiler warning, "unused variable 'dev'".

Reported-by: Stephen Rothwell 
Signed-off-by: MyungJoo Ham

PM / devfreq: passive: Use non-devm notifiers

2019-08-25T03:47:31+00:00

The devfreq passive governor registers and unregisters devfreq
transition notifiers on DEVFREQ_GOV_START/GOV_STOP using devm wrappers.

If devfreq itself is registered with devm then a warning is triggered on
rmmod from devm_devfreq_unregister_notifier. Call stack looks like this:

	devm_devfreq_unregister_notifier+0x30/0x40
	devfreq_passive_event_handler+0x4c/0x88
	devfreq_remove_device.part.8+0x6c/0x9c
	devm_devfreq_dev_release+0x18/0x20
	release_nodes+0x1b0/0x220
	devres_release_all+0x78/0x84
	device_release_driver_internal+0x100/0x1c0
	driver_detach+0x4c/0x90
	bus_remove_driver+0x7c/0xd0
	driver_unregister+0x2c/0x58
	platform_driver_unregister+0x10/0x18
	imx_devfreq_platdrv_exit+0x14/0xd40 [imx_devfreq]

This happens because devres_release_all will first remove all the nodes
into a separate todo list so the nested devres_release from
devm_devfreq_unregister_notifier won't find anything.

Fix the warning by calling the non-devm APIS for frequency notification.
Using devm wrappers is not actually useful for a governor anyway: it
relies on the devfreq core to correctly match the GOV_START/GOV_STOP
notifications.

Fixes: 996133119f57 ("PM / devfreq: Add new passive governor")
Signed-off-by: Leonard Crestez 
Acked-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham

PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate()

2019-08-25T03:46:48+00:00

Reuse opp core code for setting bus clock and voltage. As a side
effect this allow usage of coupled regulators feature (required
for boards using Exynos5422/5800 SoCs) because dev_pm_opp_set_rate()
uses regulator_set_voltage_triplet() for setting regulator voltage
while the old code used regulator_set_voltage_tol() with fixed
tolerance. This patch also removes no longer needed parsing of DT
property "exynos,voltage-tolerance" (no Exynos devfreq DT node uses
it). After applying changes both functions exynos_bus_passive_target()
and exynos_bus_target() have the same code, so remove
exynos_bus_passive_target(). In exynos_bus_probe() replace it with
exynos_bus_target.

Signed-off-by: Kamil Konieczny 
Acked-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham

PM / devfreq: exynos-bus: Correct clock enable sequence

2019-08-25T03:46:07+00:00

Regulators should be enabled before clocks to avoid h/w hang. This
require change in exynos_bus_probe() to move exynos_bus_parse_of()
after exynos_bus_parent_parse_of() and change in error handling.
Similar change is needed in exynos_bus_exit() where clock should be
disabled before regulators.

Signed-off-by: Kamil Konieczny 
Acked-by: Chanwoo Choi 
Signed-off-by: MyungJoo Ham