Re: [PATCH 2/2] cpufreq: simplify cpufreq_set_policy() interface
From: Zihuan Zhang
Date: Wed Aug 20 2025 - 01:42:44 EST
在 2025/8/19 18:59, Viresh Kumar 写道:
On 19-08-25, 18:39, Zihuan Zhang wrote:
static int cpufreq_set_policy(struct cpufreq_policy *policy,
- struct cpufreq_governor *new_gov,
- unsigned int new_pol);
+ struct cpufreq_governor *new_gov);
A driver will either support the policy or the governor. If we are
keeping `new_gov` around, I don't see why `new_pol` should be dropped.
Thanks for the reminder.
If we remove new_pol, then new_gov should indeed be removed as well.
And changing the policy for a `setpolicy` driver should happen from
within cpufreq_set_policy() instead of the caller. Also there is at
least one case (verify()) where we may end up returning early, before
changing the policy.
You’re right, we didn’t really consider that case before.
The interface of cpufreq_set_policy() does look a bit odd:
- drivers using governors don’t really need the new_pol parameter
- while drivers using the setpolicy method don’t need the new_gov one.
I guess this might be due to some historical reasons.
The question is whether it’s worth modifying this function, or if we
should just keep it as it is.