linux-stable.git/drivers/cpufreq, branch v6.8.4

cpufreq: dt: always allocate zeroed cpumask

2024-04-03T13:32:24+00:00

[ Upstream commit d2399501c2c081eac703ca9597ceb83c7875a537 ]

Commit 0499a78369ad ("ARM64: Dynamically allocate cpumasks and increase
supported CPUs to 512") changed the handling of cpumasks on ARM 64bit,
what resulted in the strange issues and warnings during cpufreq-dt
initialization on some big.LITTLE platforms.

This was caused by mixing OPPs between big and LITTLE cores, because
OPP-sharing information between big and LITTLE cores is computed on
cpumask, which in turn was not zeroed on allocation. Fix this by
switching to zalloc_cpumask_var() call.

Fixes: dc279ac6e5b4 ("cpufreq: dt: Refactor initialization to handle probe deferral properly")
CC: stable@vger.kernel.org # v5.10+
Signed-off-by: Marek Szyprowski 
Reviewed-by: Christoph Lameter (Ampere) 
Reviewed-by: Dhruva Gole 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: amd-pstate: Fix min_perf assignment in amd_pstate_adjust_perf()

2024-04-03T13:32:04+00:00

[ Upstream commit b26ffbf800ae3c8d01bdf90d9cd8a37e1606ff06 ]

In the function amd_pstate_adjust_perf(), the 'min_perf' variable is set
to 'highest_perf' instead of 'lowest_perf'.

Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State")
Reported-by: Oleksandr Natalenko 
Reviewed-by: Perry Yuan 
Signed-off-by: Tor Vic 
Reviewed-by: Mario Limonciello 
Cc: 6.1+  # 6.1+
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin

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

2024-03-26T22:17:32+00:00

[ Upstream commit f37a4d6b4a2c77414e8b9d25dd5ee31537ce9b00 ]

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 
Signed-off-by: Sasha Levin

cpufreq: qcom-hw: add CONFIG_COMMON_CLK dependency

2024-03-26T22:16:44+00:00

[ Upstream commit 3093fa33539b54db77171d2919352ad4f044a1c5 ]

It is still possible to compile-test a kernel without CONFIG_COMMON_CLK
for some ancient ARM boards or other architectures, but this causes a
link failure in the qcom-cpufreq-hw driver:

ERROR: modpost: "devm_clk_hw_register" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
ERROR: modpost: "devm_of_clk_add_hw_provider" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!
ERROR: modpost: "of_clk_hw_onecell_get" [drivers/cpufreq/qcom-cpufreq-hw.ko] undefined!

Add a Kconfig dependency here to make sure this always work. Apparently
this bug has been in the kernel for a while without me running into it
on randconfig builds as COMMON_CLK is almost always enabled.

I have cross-checked by building an allmodconfig kernel with COMMON_CLK
disabled, which showed no other driver having this problem.

Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek-hw: Don't error out if supply is not found

2024-03-26T22:16:34+00:00

[ Upstream commit eaffb10b51bf74415c9252fd8fb4dd77122501ee ]

devm_regulator_get_optional() returns -ENODEV if no supply can be found.
By introducing its usage, commit 788715b5f21c ("cpufreq: mediatek-hw:
Wait for CPU supplies before probing") caused the driver to fail probe
if no supply was present in any of the CPU DT nodes.

Use devm_regulator_get() instead since the CPUs do require supplies
even if not described in the DT. It will gracefully return a dummy
regulator if none is found in the DT node, allowing probe to succeed.

Fixes: 788715b5f21c ("cpufreq: mediatek-hw: Wait for CPU supplies before probing")
Reported-by: kernelci.org bot 
Closes: https://linux.kernelci.org/test/case/id/65b0b169710edea22852a3fa/
Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: mediatek-hw: Wait for CPU supplies before probing

2024-03-26T22:16:32+00:00

[ Upstream commit 788715b5f21c6455264fe00a1779e61bec407fe2 ]

Before proceeding with the probe and enabling frequency scaling for the
CPUs, make sure that all supplies feeding the CPUs have probed.

This fixes an issue observed on MT8195-Tomato where if the
mediatek-cpufreq-hw driver enabled the hardware (by writing to
REG_FREQ_ENABLE) before the SPMI controller driver (spmi-mtk-pmif),
behind which lies the big CPU supply, probed the platform would hang
shortly after with "rcu: INFO: rcu_preempt detected stalls on
CPUs/tasks" being printed in the log.

Fixes: 4855e26bcf4d ("cpufreq: mediatek-hw: Add support for CPUFREQ HW")
Signed-off-by: Nícolas F. R. A. Prado 
Reviewed-by: AngeloGioacchino Del Regno 
Reviewed-by: Matthias Brugger 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value

2024-03-26T22:16:32+00:00

[ Upstream commit f661017e6d326ee187db24194cabb013d81bc2a6 ]

cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: de322e085995 ("cpufreq: brcmstb-avs-cpufreq: AVS CPUfreq driver for Broadcom STB SoCs")
Signed-off-by: Anastasia Belova 
Signed-off-by: Viresh Kumar 
Signed-off-by: Sasha Levin

cpufreq: intel_pstate: fix pstate limits enforcement for adjust_perf call back

2024-02-24T14:01:59+00:00

There is a loophole in pstate limit clamping for the intel_cpufreq CPU
frequency scaling driver (intel_pstate in passive mode), schedutil CPU
frequency scaling governor, HWP (HardWare Pstate) control enabled, when
the adjust_perf call back path is used.

Fix it.

Fixes: a365ab6b9dfb cpufreq: intel_pstate: Implement the ->adjust_perf() callback
Signed-off-by: Doug Smythies 
Signed-off-by: Rafael J. Wysocki

cpufreq/amd-pstate: Fix setting scaling max/min freq values

2024-01-22T19:35:58+00:00

Scaling min/max freq values were being cached and lagging a setting
each time.  Fix the ordering of the clamp call to ensure they work.

Closes: https://bugzilla.kernel.org/show_bug.cgi?id=217931
Fixes: febab20caeba ("cpufreq/amd-pstate: Fix scaling_min_freq and scaling_max_freq update")
Signed-off-by: Mario Limonciello 
Reviewed-by: Wyes Karny 
Signed-off-by: Rafael J. Wysocki

cpufreq: intel_pstate: Refine computation of P-state for given frequency

2024-01-22T14:18:11+00:00

On systems using HWP, if a given frequency is equal to the maximum turbo
frequency or the maximum non-turbo frequency, the HWP performance level
corresponding to it is already known and can be used directly without
any computation.

Accordingly, adjust the code to use the known HWP performance levels in
the cases mentioned above.

This also helps to avoid limiting CPU capacity artificially in some
cases when the BIOS produces the HWP_CAP numbers using a different
E-core-to-P-core performance scaling factor than expected by the kernel.

Fixes: f5c8cf2a4992 ("cpufreq: intel_pstate: hybrid: Use known scaling factor for P-cores")
Cc: 6.1+  # 6.1+
Tested-by: Srinivas Pandruvada 
Signed-off-by: Rafael J. Wysocki