Re: [PATCH v1 1/1] cpufreq: fix the target freq not in the range of policy->min & max
From: "Rafael J. Wysocki" <rafael@kernel.org>
Date: 2021-06-25 14:13:57
Also in:
linux-mediatek, linux-pm, lkml
On Fri, Jun 25, 2021 at 3:41 PM TungChen Shih [off-list ref] wrote:
In cpufreq_frequency_table_target(), this function will try to find
an index for @target_freq in freq_table, and the frequency of selected
index should be in the range [policy->min, policy->max], which means:
policy->min <= policy->freq_table[idx].frequency <= policy->max
Though "clamp_val(target_freq, policy->min, policy->max);" would
have been called to check this condition, when policy->max or min is
not exactly one of the frequency in the frequency table,
policy->freq_table[idx].frequency may still go out of the range
For example, if our sorted freq_table is [3000, 2000, 1000], and
suppose we have:
@target_freq = 2500
@policy->min = 2000
@policy->max = 2200
@relation = CPUFREQ_RELATION_L
1. After clamp_val(target_freq, policy->min, policy->max); @target_freq
becomes 2200
2. Since we use CPUFREQ_REALTION_L, final selected freq will be 3000 which
beyonds policy->maxAs you accurately observed, the policy limits affect the target, not the frequency that will be used, and "RELATION_L" means "the closest frequency equal to or above the target". You are not fixing a bug here IMO, you're changing the documented behavior.
quoted hunk ↗ jump to hunk
Signed-off-by: TungChen Shih <redacted> --- include/linux/cpufreq.h | 25 ++++++++++++++++++++++--- 1 file changed, 22 insertions(+), 3 deletions(-)diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 353969c7acd3..60cb15740fdf 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h@@ -975,21 +975,40 @@ static inline int cpufreq_frequency_table_target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation) { + int idx = 0; if (unlikely(policy->freq_table_sorted == CPUFREQ_TABLE_UNSORTED)) return cpufreq_table_index_unsorted(policy, target_freq, relation); switch (relation) { case CPUFREQ_RELATION_L: - return cpufreq_table_find_index_l(policy, target_freq); + idx = cpufreq_table_find_index_l(policy, target_freq); + break; case CPUFREQ_RELATION_H: - return cpufreq_table_find_index_h(policy, target_freq); + idx = cpufreq_table_find_index_h(policy, target_freq); + break; case CPUFREQ_RELATION_C: - return cpufreq_table_find_index_c(policy, target_freq); + idx = cpufreq_table_find_index_c(policy, target_freq); + break; default: WARN_ON_ONCE(1); return 0; } + + /* target index verification */ + if (policy->freq_table[idx].frequency > policy->max) { + if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING) + idx--; + else + idx++; + } else if (policy->freq_table[idx].frequency < policy->min) { + if (policy->freq_table_sorted == CPUFREQ_TABLE_SORTED_ASCENDING) + idx++; + else + idx--; + } + + return idx; } static inline int cpufreq_table_count_valid_entries(const struct cpufreq_policy *policy) --2.18.0
_______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel