| Message ID | f7c6bb5b5b2c22a5b929d5a116e1c91220154c29.1464960877.git.viresh.kumar@linaro.org |
|---|---|
| State | New |
| Headers | show |
diff --git a/drivers/cpufreq/maple-cpufreq.c b/drivers/cpufreq/maple-cpufreq.c index d9df89392b84..8ce92ee7dd8d 100644 --- a/drivers/cpufreq/maple-cpufreq.c +++ b/drivers/cpufreq/maple-cpufreq.c @@ -133,6 +133,12 @@ static int maple_scom_query_freq(void) static int maple_cpufreq_target(struct cpufreq_policy *policy, unsigned int index) { + /* + * policy->freq_table may be sorted differently, get the index value we + * are concerned about. + */ + index = policy->freq_table[index].driver_data; + return maple_scom_switch_freq(index); }
Later patches would make changes in cpufreq core, after which policy->freq_table may be reordered by cpufreq core and it wouldn't be safe anymore to use 'index' for any other local arrays. To prepare for that, use policy->freq_table[index].driver_data for other driver specific usage of 'index'. The 'driver_data' fields are already set properly by the driver. Cc: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- drivers/cpufreq/maple-cpufreq.c | 6 ++++++ 1 file changed, 6 insertions(+) -- 2.7.1.410.g6faf27b