kernel/drivers/cpufreq/freq_table.c, branch linux-rolling-stable

cpufreq: Replace pointer subtraction with iteration macro

2025-09-23T15:16:56Z

The cpufreq documentation suggests avoiding direct pointer subtraction when working with entries in driver_freq_table, as it is relatively costly. Instead, the recommended approach is to use the provided iteration macros, like cpufreq_for_each_valid_entry_idx(). Use cpufreq_for_each_entry_idx() instead of pointer subtraction in cpufreq_frequency_table_cpuinfo() which improves code clarity and follows the established cpufreq coding style. While at it, remove redundant local variable initialization from cpufreq_table_index_unsorted(). No functional change intended. Signed-off-by: Zihuan Zhang Link: https://patch.msgid.link/20250923075553.45532-1-zhangzihuan@kylinos.cn [ rjw: Subject tweak, changelog edits, local variable definition tweak ] Signed-off-by: Rafael J. Wysocki

cpufreq: Drop redundant freq_table parameter

2025-09-05T18:16:55Z

Since commit e0b3165ba521 ("cpufreq: add 'freq_table' in struct cpufreq_policy"), freq_table has been stored in struct cpufreq_policy instead of being maintained separately. However, several helpers in freq_table.c still take both policy and freq_table as parameters, even though policy->freq_table can always be used. This leads to redundant function arguments and increases the chance of inconsistencies. This patch removes the unnecessary freq_table argument from these functions and updates their callers to only pass policy. This makes the code simpler, more consistent, and avoids duplication. Signed-off-by: Zihuan Zhang Acked-by: Viresh Kumar Link: https://patch.msgid.link/20250902073323.48330-1-zhangzihuan@kylinos.cn Signed-off-by: Rafael J. Wysocki

cpufreq: Fix setting policy limits when frequency tables are used

2025-04-28T12:36:41Z

Commit 7491cdf46b5c ("cpufreq: Avoid using inconsistent policy->min and policy->max") overlooked the fact that policy->min and policy->max were accessed directly in cpufreq_frequency_table_target() and in the functions called by it. Consequently, the changes made by that commit led to problems with setting policy limits. Address this by passing the target frequency limits to __resolve_freq() and cpufreq_frequency_table_target() and propagating them to the functions called by the latter. Fixes: 7491cdf46b5c ("cpufreq: Avoid using inconsistent policy->min and policy->max") Cc: 5.16+ # 5.16+ Closes: https://lore.kernel.org/linux-pm/aAplED3IA_J0eZN0@linaro.org/ Reported-by: Stephan Gerhold Signed-off-by: Rafael J. Wysocki Tested-by: Stephan Gerhold Reviewed-by: Lifeng Zheng Link: https://patch.msgid.link/5896780.DvuYhMxLoT@rjwysocki.net

cpufreq: staticize policy_has_boost_freq()

2025-02-07T04:15:16Z

policy_has_boost_freq() isn't used outside of freq_table.c now, mark it static. Signed-off-by: Viresh Kumar

cpufreq: Introduce policy->boost_supported flag

2025-02-07T04:15:14Z

It is possible to have a scenario where not all cpufreq policies support boost frequencies. And letting sysfs (or other parts of the kernel) enable boost feature for that policy isn't correct. Add a new flag, boost_supported, which will be set to true by the cpufreq core only if the freq table contains valid boost frequencies. Some cpufreq drivers though don't have boost frequencies in the freq-table, they can set this flag from their ->init() callbacks. Once all the drivers are updated to set the flag correctly, we can check it before enabling boost feature for a policy. Signed-off-by: Viresh Kumar

cpufreq: Remove cpufreq_generic_attrs

2025-02-07T04:15:14Z

All users of cpufreq_generic_attr are migrated now, remove it. While at it, also stop exporting attributes for available and boost frequencies as they are only used by cpufreq core now. Signed-off-by: Viresh Kumar Acked-by: Rafael J. Wysocki

cpufreq: Fix up printing large CPU numbers and frequency values

2024-04-30T10:55:01Z

A negative CPU number or frequency value may be printed if they are really large (which is unlikely, though). Signed-off-by: Joshua Yeong Reviewed-by: Thorsten Blum Acked-by: Viresh Kumar [ rjw: Subject and changelog edits. ] Signed-off-by: Rafael J. Wysocki

cpufreq: Use a smaller freq for the policy->max when verify

2024-03-27T15:19:39Z

When driver use the cpufreq_frequency_table_verify() as the cpufreq_driver->verify's callback. It may cause the policy->max bigger than the freq_qos's max freq. Just as follow: unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_available_frequencies 614400 768000 988000 1228800 1469000 1586000 1690000 1833000 2002000 2093000 unisoc:/sys/devices/system/cpu/cpufreq/policy0 # echo 1900000 > scaling_max_freq unisoc:/sys/devices/system/cpu/cpufreq/policy0 # echo 1900000 > scaling_min_freq unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_max_freq 2002000 unisoc:/sys/devices/system/cpu/cpufreq/policy0 # cat scaling_min_freq 2002000 When user set the qos_min and qos_max as the same value, and the value is not in the freq-table, the above scenario will occur. This is because in cpufreq_frequency_table_verify() func, when it can not find the freq in table, it will change the policy->max to be a bigger freq, as above, because there is no 1.9G in the freq-table, the policy->max would be set to 2.002G. As a result, the cpufreq_policy->max is bigger than the user's qos_max. This is unreasonable. So use a smaller freq when can not find the freq in fre-table, to prevent the policy->max exceed the qos's max freq. Signed-off-by: Xuewen Yan Acked-by: Viresh Kumar Reviewed-by: Dhruva Gole Signed-off-by: Rafael J. Wysocki

cpufreq: Fix per-policy boost behavior on SoCs using cpufreq_boost_set_sw()

2024-03-13T19:57:00Z

In the existing code, per-policy flags don't have any impact i.e. if cpufreq_driver boost is enabled and boost is disabled for one or more of the policies, the cpufreq driver will behave as if boost is enabled. Fix this by incorporating per-policy boost flag in the policy->max computation used in cpufreq_frequency_table_cpuinfo and setting the default per-policy boost to mirror the cpufreq_driver boost flag. Fixes: 218a06a79d9a ("cpufreq: Support per-policy performance boost") Reported-by: Dietmar Eggemann Reviewed-by: Viresh Kumar Reviewed-by: Dhruva Gole Signed-off-by: Sibi Sankar Tested-by:Yipeng Zou Reviewed-by: Yipeng Zou Signed-off-by: Rafael J. Wysocki

Merge tag 'cpufreq-arm-updates-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm

2023-04-20T17:30:01Z

Pull cpufreq/ARM updates for 6.4 from Viresh Kumar: "- Add opp and bandwidth support to tegra194 cpufreq driver (Sumit Gupta). - Use of_property_present() for testing DT property presence (Rob Herring). - Remove MODULE_LICENSE in non-modules (Nick Alcock). - Add SM7225 to cpufreq-dt-platdev blocklist (Luca Weiss). - Optimizations and fixes for qcom-cpufreq-hw driver (Krzysztof Kozlowski, Konrad Dybcio, and Bjorn Andersson). - DT binding updates for qcom-cpufreq-hw driver (Konrad Dybcio and Bartosz Golaszewski). - Updates and fixes for mediatek driver (Jia-Wei Chang and AngeloGioacchino Del Regno)."