From: Zihuan Zhang <zhangzihuan@kylinos.cn>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "rafael J . wysocki" <rafael@kernel.org>,
zhenglifeng <zhenglifeng1@huawei.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] cpufreq: simplify cpufreq_set_policy() interface
Date: Wed, 20 Aug 2025 13:42:20 +0800 [thread overview]
Message-ID: <ffe2344d-e825-44c0-ad2b-9544b123079f@kylinos.cn> (raw)
In-Reply-To: <20250819105925.34o5f5attd5rboh7@vireshk-i7>
在 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.
next prev parent reply other threads:[~2025-08-20 5:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-19 10:39 [PATCH 0/2] cpufreq: minor cleanups around policy parsing and API Zihuan Zhang
2025-08-19 10:39 ` [PATCH 1/2] cpufreq: use strlen() for governor name comparison Zihuan Zhang
2025-08-19 10:55 ` Viresh Kumar
2025-08-19 10:39 ` [PATCH 2/2] cpufreq: simplify cpufreq_set_policy() interface Zihuan Zhang
2025-08-19 10:59 ` Viresh Kumar
2025-08-20 5:42 ` Zihuan Zhang [this message]
2025-08-20 5:47 ` Viresh Kumar
2025-08-21 8:17 ` Zihuan Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ffe2344d-e825-44c0-ad2b-9544b123079f@kylinos.cn \
--to=zhangzihuan@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=viresh.kumar@linaro.org \
--cc=zhenglifeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®