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

thermal: cpu_cooling: Fix wrong comment call function name

2016-09-27T01:38:17Z

The last_load is updated not cpufreq_get_actual_power() function call but cpufreq_get_requested_power() function call. Signed-off-by: Inhyuk Kang Acked-by: Viresh Kumar Acked-by: Javi Merino Acked-by: Javi Merino Signed-off-by: Zhang Rui

thermal: cpu_cooling: Fix NULL dereference in cpufreq_state2power

2016-08-19T13:32:18Z

Currently all CPU cooling devices share a `struct thermal_cooling_device_ops` instance. The thermal core uses the presence of functions in this struct to determine if a cooling device has a power model (see cdev_is_power_actor). cpu_cooling.c adds the power model functions to the shared struct when a device is registered with a power model. Therefore, if a CPU cooling device is registered using [of_]cpufreq_power_cooling_register, _all_ devices will be determined to have a power model, including any registered with [of_]cpufreq_cooling_register. This can result in cpufreq_state2power being called on a device where dyn_power_table is NULL. With this commit, instead of having a shared thermal_cooling_device_ops which is mutated, we have two versions: one with the power functions and one without. Signed-off-by: Brendan Jackman Cc: Amit Daniel Kachhap Cc: Viresh Kumar Cc: Javi Merino Acked-by: Viresh Kumar Acked-by: Javi Merino Signed-off-by: Zhang Rui

Merge back earlier cpufreq changes for v4.8.

2016-06-13T21:33:17Z

cpufreq: Remove cpufreq_frequency_get_table()

2016-06-08T22:58:05Z

Most of the callers of cpufreq_frequency_get_table() already have the pointer to a valid 'policy' structure and they don't really need to go through the per-cpu variable first and then a check to validate the frequency, in order to find the freq-table for the policy. Directly use the policy->freq_table field instead for them. Only one user of that API is left after above changes, cpu_cooling.c and it accesses the freq_table in a racy way as the policy can get freed in between. Fix it by using cpufreq_cpu_get() properly. Since there are no more users of cpufreq_frequency_get_table() left, get rid of it. Signed-off-by: Viresh Kumar Acked-by: Javi Merino (cpu_cooling.c) Signed-off-by: Rafael J. Wysocki

thermal: cpu_cooling: fix improper order during initialization

2016-06-01T14:21:19Z

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 Cc: # 3.19+ 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

thermal: cpu_cooling: fix out of bounds access in time_in_idle

2016-02-11T15:13:29Z

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

thermal: cpu_cooling: Remove usage of devm functions

2015-10-10T03:32:21Z

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:05Z

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:17Z

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:23Z

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