kernel/linux.git/drivers/cpufreq, branch v6.6.39

Revert "cpufreq: amd-pstate: Fix the inconsistency in max frequency units"

2024-07-05T07:34:05+00:00

This reverts commit 8f893e52b9e030a25ea62e31271bf930b01f2f07 which is commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream. It causes a regression in kernels older than 6.9.y, so drop it from here. Link: https://lore.kernel.org/r/18882bfe-4ca5-495c-ace5-b9bcab796ae5@amd.com Reported-by: Lars Wendler Cc: Dhananjay Ugwekar Cc: Mario Limonciello Cc: Gautham R. Shenoy Cc: Peter Jung Cc: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: intel_pstate: Use HWP to initialize ITMT if CPPC is missing

2024-07-05T07:34:01+00:00

commit a1ff59784b277795a613beaa5d3dd9c5595c69a7 upstream. It is reported that single-thread performance on some hybrid systems dropped significantly after commit 7feec7430edd ("ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked") which prevented _CPC from being used if the support for it had not been confirmed by the platform firmware. The problem is that if the platform firmware does not confirm CPPC v2 support, cppc_get_perf_caps() returns an error which prevents the intel_pstate driver from enabling ITMT. Consequently, the scheduler does not get any hints on CPU performance differences, so in a hybrid system some tasks may run on CPUs with lower capacity even though they should be running on high-capacity CPUs. To address this, modify intel_pstate to use the information from MSR_HWP_CAPABILITIES to enable ITMT if CPPC is not available (which is done already if the highest performance number coming from CPPC is not realistic). Fixes: 7feec7430edd ("ACPI: CPPC: Only probe for _CPC if CPPC v2 is acked") Closes: https://lore.kernel.org/linux-acpi/d01b0a1f-bd33-47fe-ab41-43843d8a374f@kfocus.org Link: https://lore.kernel.org/linux-acpi/ZnD22b3Br1ng7alf@kf-XE Reported-by: Aaron Rainbolt Tested-by: Aaron Rainbolt Cc: 5.19+ # 5.19+ Link: https://patch.msgid.link/12460110.O9o76ZdvQC@rjwysocki.net Signed-off-by: Rafael J. Wysocki Reviewed-by: Mario Limonciello Signed-off-by: Greg Kroah-Hartman

cpufreq: amd-pstate: fix memory leak on CPU EPP exit

2024-06-27T11:49:05+00:00

[ Upstream commit cea04f3d9aeebda9d9c063c0dfa71e739c322c81 ] The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is not freed in the analogous exit function, so fix that. Signed-off-by: Peng Ma Acked-by: Mario Limonciello Reviewed-by: Perry Yuan [ rjw: Subject and changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: amd-pstate: Fix the inconsistency in max frequency units

2024-06-16T11:47:41+00:00

commit e4731baaf29438508197d3a8a6d4f5a8c51663f8 upstream. The nominal frequency in cpudata is maintained in MHz whereas all other frequencies are in KHz. This means we have to convert nominal frequency value to KHz before we do any interaction with other frequency values. In amd_pstate_set_boost(), this conversion from MHz to KHz is missed, fix that. Tested on a AMD Zen4 EPYC server Before: $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq 2151 $ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq 400000 $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq 2151 409422 After: $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq | uniq 2151000 $ cat /sys/devices/system/cpu/cpufreq/policy*/cpuinfo_min_freq | uniq 400000 $ cat /sys/devices/system/cpu/cpufreq/policy*/scaling_cur_freq | uniq 2151000 1799527 Fixes: ec437d71db77 ("cpufreq: amd-pstate: Introduce a new AMD P-State driver to support future processors") Signed-off-by: Dhananjay Ugwekar Acked-by: Mario Limonciello Acked-by: Gautham R. Shenoy Tested-by: Peter Jung Cc: 5.17+ # 5.17+ Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

cpufreq: brcmstb-avs-cpufreq: ISO C90 forbids mixed declarations

2024-06-12T09:11:45+00:00

[ Upstream commit fa7bd98f3c8b33fb68c6b2bc69cff32b63db69f8 ] There is a compile warning because a NULL pointer check was added before a struct was declared. This moves the NULL pointer check to after the struct is declared and moves the struct assignment to after the NULL pointer check. Fixes: f661017e6d32 ("cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value") Signed-off-by: Portia Stephens Acked-by: Florian Fainelli Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cppc_cpufreq: Fix possible null pointer dereference

2024-06-12T09:11:42+00:00

[ Upstream commit cf7de25878a1f4508c69dc9f6819c21ba177dbfe ] cppc_cpufreq_get_rate() and hisi_cppc_cpufreq_get_rate() can be called from different places with various parameters. So cpufreq_cpu_get() can return null as 'policy' in some circumstances. Fix this bug by adding null return check. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: a28b2bfc099c ("cppc_cpufreq: replace per-cpu data array with a list") Signed-off-by: Aleksandr Mishin Signed-off-by: Viresh Kumar Signed-off-by: Sasha Levin

cpufreq: exit() callback is optional

2024-06-12T09:11:41+00:00

[ Upstream commit b8f85833c05730d631576008daaa34096bc7f3ce ] The exit() callback is optional and shouldn't be called without checking a valid pointer first. Also, we must clear freq_table pointer even if the exit() callback isn't present. Signed-off-by: Viresh Kumar Fixes: 91a12e91dc39 ("cpufreq: Allow light-weight tear down and bring up of CPUs") Fixes: f339f3541701 ("cpufreq: Rearrange locking in cpufreq_remove_dev()") Reported-by: Lizhe Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: Don't unregister cpufreq cooling on CPU hotplug

2024-04-13T11:07:32+00:00

[ Upstream commit c4d61a529db788d2e52654f5b02c8d1de4952c5b ] Offlining a CPU and bringing it back online is a common operation and it happens frequently during system suspend/resume, where the non-boot CPUs are hotplugged out during suspend and brought back at resume. The cpufreq core already tries to make this path as fast as possible as the changes are only temporary in nature and full cleanup of resources isn't required in this case. For example the drivers can implement online()/offline() callbacks to avoid a lot of tear down of resources. On similar lines, there is no need to unregister the cpufreq cooling device during suspend / resume, but only while the policy is getting removed. Moreover, unregistering the cpufreq cooling device is resulting in an unwanted outcome, where the system suspend is eventually aborted in the process. Currently, during system suspend the cpufreq core unregisters the cooling device, which in turn removes a kobject using device_del() and that generates a notification to the userspace via uevent broadcast. This causes system suspend to abort in some setups. This was also earlier reported (indirectly) by Roman [1]. Maybe there is another way around to fixing that problem properly, but this change makes sense anyways. Move the registering and unregistering of the cooling device to policy creation and removal times onlyy. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218521 Reported-by: Manaf Meethalavalappu Pallikunhi Reported-by: Roman Stratiienko Link: https://patchwork.kernel.org/project/linux-pm/patch/20220710164026.541466-1-r.stratiienko@gmail.com/ [1] Tested-by: Manaf Meethalavalappu Pallikunhi Signed-off-by: Viresh Kumar Reviewed-by: Dhruva Gole Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

cpufreq: dt: always allocate zeroed cpumask

2024-04-03T13:28:35+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:28:18+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