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 set properly by the driver now. Signed-off-by: Viresh Kumar <viresh.ku...@linaro.org> --- drivers/cpufreq/ia64-acpi-cpufreq.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/cpufreq/ia64-acpi-cpufreq.c b/drivers/cpufreq/ia64-acpi-cpufreq.c index 759612da4fdc..cc8bb1e5ac50 100644 --- a/drivers/cpufreq/ia64-acpi-cpufreq.c +++ b/drivers/cpufreq/ia64-acpi-cpufreq.c @@ -210,7 +210,12 @@ acpi_cpufreq_target ( struct cpufreq_policy *policy, unsigned int index) { - return processor_set_freq(acpi_io_data[policy->cpu], policy, index); + /* + * policy->freq_table may be sorted differently, get the index value we + * are concerned about. + */ + return processor_set_freq(acpi_io_data[policy->cpu], policy, + policy->freq_table[index].driver_data); } static int @@ -282,6 +287,8 @@ acpi_cpufreq_cpu_init ( } else { freq_table[i].frequency = CPUFREQ_TABLE_END; } + + freq_table[i].driver_data = i; } result = cpufreq_table_validate_and_show(policy, freq_table); -- 2.7.1.410.g6faf27b