From: Jonghwa Lee <jonghwa3.lee@xxxxxxxxxxx> The policy might have been changed since last call of target(). Thus, using cpufreq_frequency_table_target(), which depends on policy to find the corresponding index from a frequency, may return inconsistent index for freqs.old. Thus, old_index should be calculated not based on the current policy. We have been observing such issue when scaling_min/max_freq were updated and sometimes cuased system lockups deu to incorrectly configured voltages. Signed-off-by: MyungJoo Ham <myungjoo.ham@xxxxxxxxxxx> --- drivers/cpufreq/exynos-cpufreq.c | 14 ++++++++++++-- 1 files changed, 12 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c index b243a7e..af2d81e 100644 --- a/drivers/cpufreq/exynos-cpufreq.c +++ b/drivers/cpufreq/exynos-cpufreq.c @@ -62,8 +62,18 @@ static int exynos_target(struct cpufreq_policy *policy, goto out; } - if (cpufreq_frequency_table_target(policy, freq_table, - freqs.old, relation, &old_index)) { + /* + * The policy max have been changed so that we cannot get proper + * old_index with cpufreq_frequency_table_target(). Thus, ignore + * policy and get the index from the raw freqeuncy table. + */ + for (old_index = 0; + freq_table[old_index].frequency != CPUFREQ_TABLE_END; + old_index++) + if (freq_table[old_index].frequency == freqs.old) + break; + + if (freq_table[old_index].frequency == CPUFREQ_TABLE_END) { ret = -EINVAL; goto out; } -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html