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 <dbarysh...@gmail.com>
Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org>
---
drivers/cpufreq/maple-cpufreq.c | 6 ++++++
1 file changed, 6 insertions(+)
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);
}
--
2.7.1.410.g6faf27b
