linux-stable.git/drivers/cpufreq, branch v6.14.2 Linux kernel stable tree cpufreq: Init cpufreq only for present CPUs 2025-04-10T12:43:58+00:00 Jacky Bai ping.bai@nxp.com 2025-03-13T01:39:28+00:00 de2530c4133fbeff459e4d9407c64067779a37a6 [ Upstream commit 45f589b7167f36290d29c79e3a442dc0b13c086a ] for_each_possible_cpu() is currently used to initialize cpufreq. However, in cpu_dev_register_generic(), for_each_present_cpu() is used to register CPU devices which means the CPU devices are only registered for present CPUs and not all possible CPUs. With nosmp or maxcpus=0, only the boot CPU is present, lead to the cpufreq probe failure or defer probe due to no cpu device available for not present CPUs. Change for_each_possible_cpu() to for_each_present_cpu() in the above cpufreq drivers to ensure it only registers cpufreq for CPUs that are actually present. Fixes: b0c69e1214bc ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES") Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 45f589b7167f36290d29c79e3a442dc0b13c086a ]

for_each_possible_cpu() is currently used to initialize cpufreq.
However, in cpu_dev_register_generic(), for_each_present_cpu()
is used to register CPU devices which means the CPU devices are
only registered for present CPUs and not all possible CPUs.

With nosmp or maxcpus=0, only the boot CPU is present, lead
to the cpufreq probe failure or defer probe due to no cpu device
available for not present CPUs.

Change for_each_possible_cpu() to for_each_present_cpu() in the
above cpufreq drivers to ensure it only registers cpufreq for
CPUs that are actually present.

Fixes: b0c69e1214bc ("drivers: base: Use present CPUs in GENERIC_CPU_DEVICES")
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq: tegra194: Allow building for Tegra234 2025-04-10T12:43:57+00:00 Aaron Kling webgeek1234@gmail.com 2025-02-26T18:51:59+00:00 59f637a90ed29ba074e1e6df3f32f00b025948de [ Upstream commit 4a1e3bf61fc78ad100018adb573355303915dca3 ] Support was added for Tegra234 in the referenced commit, but the Kconfig was not updated to allow building for the arch. Fixes: 273bc890a2a8 ("cpufreq: tegra194: Add support for Tegra234") Signed-off-by: Aaron Kling <webgeek1234@gmail.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4a1e3bf61fc78ad100018adb573355303915dca3 ]

Support was added for Tegra234 in the referenced commit, but the Kconfig
was not updated to allow building for the arch.

Fixes: 273bc890a2a8 ("cpufreq: tegra194: Add support for Tegra234")
Signed-off-by: Aaron Kling <webgeek1234@gmail.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update 2025-04-10T12:43:56+00:00 Dhananjay Ugwekar dhananjay.ugwekar@amd.com 2025-02-05T11:25:21+00:00 b99c1c63d88c75a4dc5487c3696cda38697b8d35 [ Upstream commit 426db24d4db2e4f0d6720aeb7795eafcb9e82640 ] Check if policy is NULL before dereferencing it in amd_pstate_update. Fixes: e8f555daacd3 ("cpufreq/amd-pstate: fix setting policy current frequency value") Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20250205112523.201101-11-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 426db24d4db2e4f0d6720aeb7795eafcb9e82640 ]

Check if policy is NULL before dereferencing it in amd_pstate_update.

Fixes: e8f555daacd3 ("cpufreq/amd-pstate: fix setting policy current frequency value")
Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Link: https://lore.kernel.org/r/20250205112523.201101-11-dhananjay.ugwekar@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq/amd-pstate: Convert all perf values to u8 2025-04-10T12:43:56+00:00 Dhananjay Ugwekar dhananjay.ugwekar@amd.com 2025-02-05T11:25:17+00:00 1c4dbe5e1dc8090a61e985dd8701831dbdd261dc [ Upstream commit 555bbe67a622b297405e246d1868dbda3284bde8 ] All perf values are always within 0-255 range, hence convert their datatype to u8 everywhere. Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20250205112523.201101-7-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 555bbe67a622b297405e246d1868dbda3284bde8 ]

All perf values are always within 0-255 range, hence convert their
datatype to u8 everywhere.

Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Link: https://lore.kernel.org/r/20250205112523.201101-7-dhananjay.ugwekar@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update")
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq/amd-pstate: Pass min/max_limit_perf as min/max_perf to amd_pstate_update 2025-04-10T12:43:56+00:00 Dhananjay Ugwekar dhananjay.ugwekar@amd.com 2025-02-05T11:25:16+00:00 83767dbe6f93916ceead3bee54cf5eddd9b085f9 [ Upstream commit e9869c836b2a460c48e2d69ae79d786303dbffda ] Currently, amd_pstate_update_freq passes the hardware perf limits as min/max_perf to amd_pstate_update, which eventually gets programmed into the min/max_perf fields of the CPPC_REQ register. Instead pass the effective perf limits i.e. min/max_limit_perf values to amd_pstate_update as min/max_perf. Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20250205112523.201101-6-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit e9869c836b2a460c48e2d69ae79d786303dbffda ]

Currently, amd_pstate_update_freq passes the hardware perf limits as
min/max_perf to amd_pstate_update, which eventually gets programmed into
the min/max_perf fields of the CPPC_REQ register.

Instead pass the effective perf limits i.e. min/max_limit_perf values to
amd_pstate_update as min/max_perf.

Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Link: https://lore.kernel.org/r/20250205112523.201101-6-dhananjay.ugwekar@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update")
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq/amd-pstate: Modify the min_perf calculation in adjust_perf callback 2025-04-10T12:43:56+00:00 Dhananjay Ugwekar dhananjay.ugwekar@amd.com 2025-02-05T11:25:14+00:00 95a3068fb2f6203655b065aaa9f1f29f2bffddb0 [ Upstream commit 6ceb877d5cecd5417d63239bf833a1cd5f8f271c ] Instead of setting a fixed floor at lowest_nonlinear_perf, use the min_limit_perf value, so that it gives the user the freedom to lower the floor further. There are two minimum frequency/perf limits that we need to consider in the adjust_perf callback. One provided by schedutil i.e. the sg_cpu->bw_min value passed in _min_perf arg, another is the effective value of min_freq_qos request that is updated in cpudata->min_limit_perf. Modify the code to use the bigger of these two values. Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com> Link: https://lore.kernel.org/r/20250205112523.201101-4-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update") Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 6ceb877d5cecd5417d63239bf833a1cd5f8f271c ]

Instead of setting a fixed floor at lowest_nonlinear_perf, use the
min_limit_perf value, so that it gives the user the freedom to lower the
floor further.

There are two minimum frequency/perf limits that we need to consider in
the adjust_perf callback. One provided by schedutil i.e. the sg_cpu->bw_min
value passed in _min_perf arg, another is the effective value of
min_freq_qos request that is updated in cpudata->min_limit_perf. Modify the
code to use the bigger of these two values.

Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Reviewed-by: Gautham R. Shenoy <gautham.shenoy@amd.com>
Link: https://lore.kernel.org/r/20250205112523.201101-4-dhananjay.ugwekar@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Stable-dep-of: 426db24d4db2 ("cpufreq/amd-pstate: Add missing NULL ptr check in amd_pstate_update")
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq: governor: Fix negative 'idle_time' handling in dbs_update() 2025-04-10T12:43:55+00:00 Jie Zhan zhanjie9@hisilicon.com 2025-02-13T03:55:10+00:00 42e37ff839b639f2a3f01bfd65e8ce125de99c5c [ Upstream commit 3698dd6b139dc37b35a9ad83d9330c1f99666c02 ] We observed an issue that the CPU frequency can't raise up with a 100% CPU load when NOHZ is off and the 'conservative' governor is selected. 'idle_time' can be negative if it's obtained from get_cpu_idle_time_jiffy() when NOHZ is off. This was found and explained in commit 9485e4ca0b48 ("cpufreq: governor: Fix handling of special cases in dbs_update()"). However, commit 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation") introduced a comparison between 'idle_time' and 'samling_rate' to detect a long idle interval. While 'idle_time' is converted to int before comparison, it's actually promoted to unsigned again when compared with an unsigned 'sampling_rate'. Hence, this leads to wrong idle interval detection when it's in fact 100% busy and sets policy_dbs->idle_periods to a very large value. 'conservative' adjusts the frequency to minimum because of the large 'idle_periods', such that the frequency can't raise up. 'Ondemand' doesn't use policy_dbs->idle_periods so it fortunately avoids the issue. Correct negative 'idle_time' to 0 before any use of it in dbs_update(). Fixes: 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation") Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com> Reviewed-by: Chen Yu <yu.c.chen@intel.com> Link: https://patch.msgid.link/20250213035510.2402076-1-zhanjie9@hisilicon.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 3698dd6b139dc37b35a9ad83d9330c1f99666c02 ]

We observed an issue that the CPU frequency can't raise up with a 100% CPU
load when NOHZ is off and the 'conservative' governor is selected.

'idle_time' can be negative if it's obtained from get_cpu_idle_time_jiffy()
when NOHZ is off.  This was found and explained in commit 9485e4ca0b48
("cpufreq: governor: Fix handling of special cases in dbs_update()").

However, commit 7592019634f8 ("cpufreq: governors: Fix long idle detection
logic in load calculation") introduced a comparison between 'idle_time' and
'samling_rate' to detect a long idle interval.  While 'idle_time' is
converted to int before comparison, it's actually promoted to unsigned
again when compared with an unsigned 'sampling_rate'.  Hence, this leads to
wrong idle interval detection when it's in fact 100% busy and sets
policy_dbs->idle_periods to a very large value.  'conservative' adjusts the
frequency to minimum because of the large 'idle_periods', such that the
frequency can't raise up.  'Ondemand' doesn't use policy_dbs->idle_periods
so it fortunately avoids the issue.

Correct negative 'idle_time' to 0 before any use of it in dbs_update().

Fixes: 7592019634f8 ("cpufreq: governors: Fix long idle detection logic in load calculation")
Signed-off-by: Jie Zhan <zhanjie9@hisilicon.com>
Reviewed-by: Chen Yu <yu.c.chen@intel.com>
Link: https://patch.msgid.link/20250213035510.2402076-1-zhanjie9@hisilicon.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq: scpi: compare kHz instead of Hz 2025-04-10T12:43:55+00:00 zuoqian zuoqian113@gmail.com 2025-01-25T08:49:49+00:00 11769835a5da88572f0d5c26e9de803f7932e305 [ Upstream commit 4742da9774a416908ef8e3916164192c15c0e2d1 ] The CPU rate from clk_get_rate() may not be divisible by 1000 (e.g., 133333333). But the rate calculated from frequency(kHz) is always divisible by 1000 (e.g., 133333000). Comparing the rate causes a warning during CPU scaling: "cpufreq: __target_index: Failed to change cpu frequency: -5". When we choose to compare kHz here, the issue does not occur. Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency") Signed-off-by: zuoqian <zuoqian113@gmail.com> Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 4742da9774a416908ef8e3916164192c15c0e2d1 ]

The CPU rate from clk_get_rate() may not be divisible by 1000
(e.g., 133333333). But the rate calculated from frequency(kHz) is
always divisible by 1000 (e.g., 133333000).
Comparing the rate causes a warning during CPU scaling:
"cpufreq: __target_index: Failed to change cpu frequency: -5".
When we choose to compare kHz here, the issue does not occur.

Fixes: 343a8d17fa8d ("cpufreq: scpi: remove arm_big_little dependency")
Signed-off-by: zuoqian <zuoqian113@gmail.com>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
Merge tag 'amd-pstate-v6.14-2025-02-06' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux 2025-02-06T19:39:43+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-02-06T19:39:43+00:00 b3cc5afc4d972ca30dc5d25ed5e1056e62b5efa8 Merge amd-pstate driver fixes for 6.14-rc2 from Mario Limonciello: "* Fix some error cleanup paths with mutex use and boost * Fix a ref counting issue * Fix a schedutil issue" * tag 'amd-pstate-v6.14-2025-02-06' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux: cpufreq/amd-pstate: Fix cpufreq_policy ref counting cpufreq/amd-pstate: Fix max_perf updation with schedutil cpufreq/amd-pstate: Remove the goto label in amd_pstate_update_limits cpufreq/amd-pstate: Fix per-policy boost flag incorrect when fail 
Merge amd-pstate driver fixes for 6.14-rc2 from Mario Limonciello:

"* Fix some error cleanup paths with mutex use and boost
 * Fix a ref counting issue
 * Fix a schedutil issue"

* tag 'amd-pstate-v6.14-2025-02-06' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/superm1/linux:
  cpufreq/amd-pstate: Fix cpufreq_policy ref counting
  cpufreq/amd-pstate: Fix max_perf updation with schedutil
  cpufreq/amd-pstate: Remove the goto label in amd_pstate_update_limits
  cpufreq/amd-pstate: Fix per-policy boost flag incorrect when fail
cpufreq/amd-pstate: Fix cpufreq_policy ref counting 2025-02-06T19:19:36+00:00 Dhananjay Ugwekar dhananjay.ugwekar@amd.com 2025-02-05T11:25:20+00:00 3ace20038e19f23fe73259513f1f08d4bf1a3c83 amd_pstate_update_limits() takes a cpufreq_policy reference but doesn't decrement the refcount in one of the exit paths, fix that. Fixes: 45722e777fd9 ("cpufreq: amd-pstate: Optimize amd_pstate_update_limits()") Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://lore.kernel.org/r/20250205112523.201101-10-dhananjay.ugwekar@amd.com Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> 
amd_pstate_update_limits() takes a cpufreq_policy reference but doesn't
decrement the refcount in one of the exit paths, fix that.

Fixes: 45722e777fd9 ("cpufreq: amd-pstate: Optimize amd_pstate_update_limits()")
Signed-off-by: Dhananjay Ugwekar <dhananjay.ugwekar@amd.com>
Reviewed-by: Mario Limonciello <mario.limonciello@amd.com>
Link: https://lore.kernel.org/r/20250205112523.201101-10-dhananjay.ugwekar@amd.com
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>