linux-stable.git/drivers/cpufreq/cpufreq.c, branch linux-rolling-lts

cpufreq: Pass the policy to cpufreq_driver->adjust_perf()

2026-05-23T11:06:24+00:00

[ Upstream commit c03791085adcd61fa9b766ab303c7d0941d7378d ]

cpufreq_cpu_get() can sleep on PREEMPT_RT in presence of concurrent
writer(s), however amd-pstate depends on fetching the cpudata via the
policy's driver data which necessitates grabbing the reference.

Since schedutil governor can call "cpufreq_driver->update_perf()"
during sched_tick/enqueue/dequeue with rq_lock held and IRQs disabled,
fetching the policy object using the cpufreq_cpu_get() helper in the
scheduler fast-path leads to "BUG: scheduling while atomic" on
PREEMPT_RT [1].

Pass the cached cpufreq policy object in sg_policy to the update_perf()
instead of just the CPU. The CPU can be inferred using "policy->cpu".

The lifetime of cpufreq_policy object outlasts that of the governor and
the cpufreq driver (allocated when the CPU is onlined and only reclaimed
when the CPU is offlined / the CPU device is removed) which makes it
safe to be referenced throughout the governor's lifetime.

Closes:https://lore.kernel.org/all/20250731092316.3191-1-spasswolf@web.de/ [1]

Fixes: 1d215f0319c2 ("cpufreq: amd-pstate: Add fast switch function for AMD P-State")
Reported-by: Bert Karwatzki 
Acked-by: Viresh Kumar 
Signed-off-by: K Prateek Nayak 
Acked-by: Gary Guo  # Rust
Reviewed-by: Gautham R. Shenoy 
Reviewed-by: Zhongqiu Han 
Link: https://lore.kernel.org/r/20260316081849.19368-3-kprateek.nayak@amd.com
Signed-off-by: Mario Limonciello (AMD) 
Signed-off-by: Sasha Levin

Merge back earlier cpufreq material for 6.18

2025-09-24T19:32:28+00:00

cpufreq: Initialize cpufreq-based invariance before subsys

2025-09-20T11:00:20+00:00

commit 2a6c72738706 ("cpufreq: Initialize cpufreq-based
frequency-invariance later") postponed the frequency invariance
initialization to avoid disabling it in the error case.
This isn't locking safe, instead move the initialization up before
the subsys interface is registered (which will rebuild the
sched_domains) and add the corresponding disable on the error path.

Observed lockdep without this patch:
[    0.989686] ======================================================
[    0.989688] WARNING: possible circular locking dependency detected
[    0.989690] 6.17.0-rc4-cix-build+ #31 Tainted: G S
[    0.989691] ------------------------------------------------------
[    0.989692] swapper/0/1 is trying to acquire lock:
[    0.989693] ffff800082ada7f8 (sched_energy_mutex){+.+.}-{4:4}, at: rebuild_sched_domains_energy+0x30/0x58
[    0.989705]
               but task is already holding lock:
[    0.989706] ffff000088c89bc8 (&policy->rwsem){+.+.}-{4:4}, at: cpufreq_online+0x7f8/0xbe0
[    0.989713]
               which lock already depends on the new lock.

Fixes: 2a6c72738706 ("cpufreq: Initialize cpufreq-based frequency-invariance later")
Signed-off-by: Christian Loehle 
Signed-off-by: Rafael J. Wysocki

cpufreq: Add defensive check during driver registration

2025-09-19T21:11:44+00:00

Currently, cpufreq allows drivers to implement both ->target() and
->target_index() callbacks, but that can lead to ambiguous or incorrect
behavior.

For this reason, prevent cpufreq drivers implementing both ->target()
and ->target_index() at the same time from registering.

This check can help to catch driver implementation mistakes early and
improve overall robustness, without affecting existing valid drivers.

Signed-off-by: Zihuan Zhang 
Link: https://patch.msgid.link/20250908085738.31602-1-zhangzihuan@kylinos.cn
[ rjw: Subject adjustment and changelog rewrite ]
Signed-off-by: Rafael J. Wysocki

cpufreq: core: Rearrange variable declarations involving __free()

2025-09-05T18:46:05+00:00

Follow cleanup.h recommendations and always define and assign variables
in one statement when __free() is used.

No intentional functional impact.

Signed-off-by: Rafael J. Wysocki 
Reviewed-by: Krzysztof Kozlowski 
Acked-by: Viresh Kumar 
Link: https://patch.msgid.link/4691667.LvFx2qVVIh@rafael.j.wysocki

cpufreq: Use int type to store negative error codes

2025-09-05T18:28:46+00:00

Change the 'ret' variable in store_scaling_setspeed() from unsigned int to
int, as it needs to store either negative error codes or zero returned
by kstrtouint().

No effect on runtime.

Signed-off-by: Qianfeng Rong 
Acked-by: Viresh Kumar 
Link: https://patch.msgid.link/20250902114545.651661-2-rongqianfeng@vivo.com
Signed-off-by: Rafael J. Wysocki

cpufreq: Drop redundant freq_table parameter

2025-09-05T18:16:55+00:00

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: simplify setpolicy/target check in driver verification

2025-08-22T19:33:22+00:00

cpufreq drivers are supposed to use either ->setpolicy() or
->target()/->target_index().

Simplify the existing check by collapsing it into a single boolean
expression:

    (!!driver->setpolicy == (driver->target_index || driver->target))

This is a readability/maintainability cleanup and keeps the semantics
unchanged.

No functional change intended.

Signed-off-by: Zihuan Zhang 
Acked-by: Viresh Kumar 
Link: https://patch.msgid.link/20250822070424.166795-3-zhangzihuan@kylinos.cn
Signed-off-by: Rafael J. Wysocki

cpufreq: use strlen() for governor name comparison

2025-08-22T19:33:22+00:00

Most kernel code using strncasecmp()/strncmp() passes strlen("xxx")
as the length argument. cpufreq_parse_policy() previously used
CPUFREQ_NAME_LEN (16), which is longer than the actual strings
("performance" is 11 chars, "powersave" is 9 chars).

This patch switches to strlen() for the comparison, making the
matching slightly more permissive (e.g., "powersavexxx" will now
also match "powersave"). While this is unlikely to cause functional
issues, it aligns cpufreq with common kernel style and makes the
behavior more intuitive.

Signed-off-by: Zihuan Zhang 
Acked-by: Viresh Kumar 
Link: https://patch.msgid.link/20250822070424.166795-2-zhangzihuan@kylinos.cn
Signed-off-by: Rafael J. Wysocki

cpufreq: Avoid calling get_governor() for first policy

2025-08-19T19:13:12+00:00

When a cpufreq driver registers the first policy, it may attempt to
initialize the policy governor from `last_governor`. However, this is
meaningless for the first policy instance, because `last_governor` is
only updated when policies are removed (e.g. during CPU offline).

The `last_governor` mechanism is intended to restore the previously
used governor across CPU hotplug events. For the very first policy,
there is no "previous governor" to restore, so calling
get_governor(last_governor) is unnecessary and potentially confusing.

Skip looking up `last_governor` when registering the first policy.
Instead, it directly uses the default governor after all governors
have been registered and are available.

This avoids meaningless lookups, reduces unnecessary module reference
handling, and simplifies the initial policy path.

Signed-off-by: Zihuan Zhang 
Acked-by: Viresh Kumar 
Reviewed-by: Lifeng Zheng 
Link: https://patch.msgid.link/20250725041450.68754-1-zhangzihuan@kylinos.cn
[ rjw: Subject and changelog edits ]
Signed-off-by: Rafael J. Wysocki