kernel/linux.git/drivers/thermal/cpu_cooling.c, branch linux-4.4.y

thermal: cpu_cooling: Actually trace CPU load in thermal_power_cpu_get_power

2020-01-29T09:21:44+00:00

[ Upstream commit bf45ac18b78038e43af3c1a273cae4ab5704d2ce ] The CPU load values passed to the thermal_power_cpu_get_power tracepoint are zero for all CPUs, unless, unless the thermal_power_cpu_limit tracepoint is enabled too: irq/41-rockchip-98 [000] .... 290.972410: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x0,0x0,0x0,0x0}} dynamic_power=4815 vs irq/41-rockchip-96 [000] .... 95.773585: thermal_power_cpu_get_power: cpus=0000000f freq=1800000 load={{0x56,0x64,0x64,0x5e}} dynamic_power=4959 irq/41-rockchip-96 [000] .... 95.773596: thermal_power_cpu_limit: cpus=0000000f freq=408000 cdev_state=10 power=416 There seems to be no good reason for omitting the CPU load information depending on another tracepoint. My guess is that the intention was to check whether thermal_power_cpu_get_power is (still) enabled, however 'load_cpu != NULL' already indicates that it was at least enabled when cpufreq_get_requested_power() was entered, there seems little gain from omitting the assignment if the tracepoint was just disabled, so just remove the check. Fixes: 6828a4711f99 ("thermal: add trace events to the power allocator governor") Signed-off-by: Matthias Kaehlcke Reviewed-by: Daniel Lezcano Acked-by: Javi Merino Acked-by: Viresh Kumar Signed-off-by: Eduardo Valentin Signed-off-by: Sasha Levin

thermal: cpu_cooling: Avoid accessing potentially freed structures

2017-07-27T22:06:02+00:00

commit 289d72afddf83440117c35d864bf0c6309c1d011 upstream. After the lock is dropped, it is possible that the cpufreq_dev gets freed before we call get_level() and that can cause kernel to crash. Drop the lock after we are done using the structure. Fixes: 02373d7c69b4 ("thermal: cpu_cooling: fix lockdep problems in cpu_cooling") Signed-off-by: Viresh Kumar Reviewed-by: Lukasz Luba Tested-by: Lukasz Luba Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman

thermal: cpu_cooling: fix improper order during initialization

2016-07-27T16:47:29+00:00

commit f840ab18bdf2e415dac21d09fbbbd2873111bd48 upstream. The freq_table array is not populated before calling thermal_of_cooling_register. The code which populates the freq table was introduced in commit f6859014. This should be done before registering new thermal cooling device. The log shows effects of this wrong decision. [ 2.172614] cpu cpu1: Failed to get voltage for frequency 1984518656000: -34 [ 2.220863] cpu cpu0: Failed to get voltage for frequency 1984524416000: -34 Fixes: f6859014c7e7 ("thermal: cpu_cooling: Store frequencies in descending order") Signed-off-by: Lukasz Luba Acked-by: Javi Merino Acked-by: Viresh Kumar Signed-off-by: Zhang Rui Signed-off-by: Greg Kroah-Hartman

thermal: cpu_cooling: fix out of bounds access in time_in_idle

2016-03-09T23:34:56+00:00

commit a53b8394ec3c67255928df6ee9cc99dd1cd452e3 upstream. In __cpufreq_cooling_register() we allocate the arrays for time_in_idle and time_in_idle_timestamp to be as big as the number of cpus in this cpufreq device. However, in get_load() we access this array using the cpu number as index, which can result in an out of bound access. Index time_in_idle{,_timestamp} using the index in the cpufreq_device's allowed_cpus mask, as we do for the load_cpu array in cpufreq_get_requested_power() Reported-by: Nicolas Boichat Cc: Amit Daniel Kachhap Cc: Zhang Rui Cc: Eduardo Valentin Tested-by: Nicolas Boichat Acked-by: Viresh Kumar Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin Signed-off-by: Greg Kroah-Hartman

thermal: cpu_cooling: Remove usage of devm functions

2015-10-10T03:32:21+00:00

In the function cpufreq_get_requested_power, the memory allocated for load_cpu is live within the function only. And after the allocation it is immediately freed with devm_kfree. There is no need to allocate memory for load_cpu with devm function so replace devm_kcalloc with kcalloc and devm_kfree with kfree. Signed-off-by: Vaishali Thakkar Acked-by: Viresh Kumar Acked-by: Javi Merino Signed-off-by: Zhang Rui

thermal: cpu_cooling: free power table on error or when unregistering

2015-09-14T03:34:05+00:00

The power table is not being freed on error from cpufreq_cooling register or when unregistering. Free it. Fixes: c36cf0717631 ("thermal: cpu_cooling: implement the power cooling device API") Cc: Zhang Rui Cc: Eduardo Valentin Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin

thermal: cpu_cooling: don't call kcalloc() under rcu_read_lock

2015-09-14T03:33:17+00:00

build_dyn_power_table() allocates the power table while holding rcu_read_lock. kcalloc using GFP_KERNEL may sleep, so it can't be called in an RCU read-side path. Move the rcu protection to the part of the function that really needs it: the part that handles the dev_pm_opp pointer received from dev_pm_opp_find_freq_ceil(). In the unlikely case that there is an OPP added to the cpu while this function is running, return -EAGAIN. Fixes: c36cf0717631 ("thermal: cpu_cooling: implement the power cooling device API") Cc: Zhang Rui Cc: Eduardo Valentin Signed-off-by: Javi Merino Signed-off-by: Eduardo Valentin

thermal/cpu_cooling: update policy limits if clipped_freq < policy->max

2015-08-15T01:26:23+00:00

policy->max is the maximum allowed frequency defined by user and clipped_freq is the maximum that thermal constraints allow. If clipped_freq is lower than policy->max, then we need to readjust policy->max. But, if clipped_freq is greater than policy->max, we don't need to do anything. We used to call cpufreq_verify_within_limits() in this case, but it doesn't change anything in this case. Lets skip this unnecessary call and write a comment that explains this. Signed-off-by: Viresh Kumar Signed-off-by: Eduardo Valentin

thermal/cpu_cooling: rename max_freq as clipped_freq in notifier

2015-08-15T01:26:23+00:00

That's what it is for, lets name it properly. Signed-off-by: Viresh Kumar Signed-off-by: Eduardo Valentin

thermal/cpu_cooling: rename cpufreq_val as clipped_freq

2015-08-15T01:26:22+00:00

That's what it is for, lets name it properly. Signed-off-by: Viresh Kumar Signed-off-by: Eduardo Valentin