linux.git/drivers/devfreq, branch v5.4.51

PM / devfreq: Add missing locking while setting suspend_freq

2020-05-10T08:31:34+00:00

commit e1e047ace8cef6d143f38c7d769753f133becbe6 upstream.

Commit 2abb0d5268ae ("PM / devfreq: Lock devfreq in trans_stat_show")
revealed a missing locking while calling devfreq_update_status() function
during suspend/resume cycle.

Code analysis revealed that devfreq_set_target() function was called
without needed locks held for setting device specific suspend_freq if such
has been defined. This patch fixes that by adding the needed locking, what
fixes following kernel warning on Exynos4412-based OdroidU3 board during
system suspend:

PM: suspend entry (deep)
Filesystems sync: 0.002 seconds
Freezing user space processes ... (elapsed 0.001 seconds) done.
OOM killer disabled.
Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
------------[ cut here ]------------
WARNING: CPU: 2 PID: 1385 at drivers/devfreq/devfreq.c:204 devfreq_update_status+0xc0/0x188
Modules linked in:
CPU: 2 PID: 1385 Comm: rtcwake Not tainted 5.4.0-rc6-next-20191111 #6848
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb4/0xe0)
[] (dump_stack) from [] (__warn+0xf4/0x10c)
[] (__warn) from [] (warn_slowpath_fmt+0xb0/0xb8)
[] (warn_slowpath_fmt) from [] (devfreq_update_status+0xc0/0x188)
[] (devfreq_update_status) from [] (devfreq_set_target+0xb0/0x15c)
[] (devfreq_set_target) from [] (devfreq_suspend+0x2c/0x64)
[] (devfreq_suspend) from [] (dpm_suspend+0xa4/0x57c)
[] (dpm_suspend) from [] (dpm_suspend_start+0x98/0xa0)
[] (dpm_suspend_start) from [] (suspend_devices_and_enter+0xec/0xc74)
[] (suspend_devices_and_enter) from [] (pm_suspend+0x340/0x410)
[] (pm_suspend) from [] (state_store+0x6c/0xc8)
[] (state_store) from [] (kernfs_fop_write+0x10c/0x228)
[] (kernfs_fop_write) from [] (__vfs_write+0x30/0x1d0)
[] (__vfs_write) from [] (vfs_write+0xa4/0x180)
[] (vfs_write) from [] (ksys_write+0x60/0xd8)
[] (ksys_write) from [] (ret_fast_syscall+0x0/0x28)
Exception stack(0xed3d7fa8 to 0xed3d7ff0)
...
irq event stamp: 9667
hardirqs last  enabled at (9679): [] _raw_spin_unlock_irq+0x20/0x58
hardirqs last disabled at (9698): [] __schedule+0xd8/0x818
softirqs last  enabled at (9694): [] __do_softirq+0x4fc/0x5fc
softirqs last disabled at (9719): [] irq_exit+0x16c/0x170
---[ end trace 41ac5b57d046bdbc ]---
------------[ cut here ]------------

Signed-off-by: Marek Szyprowski 
Acked-by: Chanwoo Choi 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

Revert "PM / devfreq: Modify the device name as devfreq(X) for sysfs"

2020-03-05T15:43:43+00:00

commit 66d0e797bf095d407479c89952d42b1d96ef0a7f upstream.

This reverts commit 4585fbcb5331fc910b7e553ad3efd0dd7b320d14.

The name changing as devfreq(X) breaks some user space applications,
such as Android HAL from Unisoc and Hikey [1].
The device name will be changed unexpectly after every boot depending
on module init sequence. It will make trouble to setup some system
configuration like selinux for Android.

So we'd like to revert it back to old naming rule before any better
way being found.

[1] https://lkml.org/lkml/2018/5/8/1042

Cc: John Stultz 
Cc: Greg Kroah-Hartman 
Cc: stable@vger.kernel.org
Signed-off-by: Orson Zhai 
Acked-by: Greg Kroah-Hartman 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

PM / devfreq: rk3399_dmc: Add COMPILE_TEST and HAVE_ARM_SMCCC dependency

2020-02-24T07:36:41+00:00

[ Upstream commit eff5d31f7407fa9d31fb840106f1593399457298 ]

To build test, add COMPILE_TEST depedency to both ARM_RK3399_DMC_DEVFREQ
and DEVFREQ_EVENT_ROCKCHIP_DFI configuration. And ARM_RK3399_DMC_DEVFREQ
used the SMCCC interface so that add HAVE_ARM_SMCCC dependency to prevent
the build break.

Reported-by: kbuild test robot 
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: exynos-ppmu: Fix excessive stack usage

2020-02-24T07:36:41+00:00

[ Upstream commit d4556f5e99d5f603913bac01adaff8670cb2d08b ]

Putting a 'struct devfreq_event_dev' object on the stack is generally
a bad idea and here it leads to a warnig about potential stack overflow:

drivers/devfreq/event/exynos-ppmu.c:643:12: error: stack frame size of 1040 bytes in function 'exynos_ppmu_probe' [-Werror,-Wframe-larger-than=]

There is no real need for the device structure, only the string inside
it, so add an internal helper function that simply takes the string
as its argument and remove the device structure.

Fixes: 1dd62c66d345 ("PM / devfreq: events: extend events by type of counted data")
Signed-off-by: Arnd Bergmann 
[cw00.choi: Fix the issue from 'desc->name' to 'desc[j].name']
Signed-off-by: Chanwoo Choi 
Signed-off-by: Sasha Levin

PM / devfreq: Add new name attribute for sysfs

2020-02-05T21:22:40+00:00

commit 2fee1a7cc6b1ce6634bb0f025be2c94a58dfa34d upstream.

The commit 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for
sysfs") changed the node name to devfreq(x). After this commit, it is not
possible to get the device name through /sys/class/devfreq/devfreq(X)/*.

Add new name attribute in order to get device name.

Cc: stable@vger.kernel.org
Fixes: 4585fbcb5331 ("PM / devfreq: Modify the device name as devfreq(X) for sysfs")
Signed-off-by: Chanwoo Choi 
Signed-off-by: Greg Kroah-Hartman

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