From: Zihuan Zhang <zhangzihuan@kylinos.cn>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J . wysocki" <rafael@kernel.org>,
Saravana Kannan <saravanak@google.com>,
zhenglifeng <zhenglifeng1@huawei.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/3] cpufreq: Always enforce policy limits even without frequency table
Date: Thu, 4 Sep 2025 13:48:00 +0800 [thread overview]
Message-ID: <e91bd1e9-8db4-4923-92fe-52893623487e@kylinos.cn> (raw)
In-Reply-To: <20250904053700.abdkh23zwi5x65do@vireshk-i7>
在 2025/9/4 13:37, Viresh Kumar 写道:
> On 04-09-25, 13:23, Zihuan Zhang wrote:
>> 在 2025/9/4 12:48, Viresh Kumar 写道:
>>> On 04-09-25, 11:22, Zihuan Zhang wrote:
>>>> int cpufreq_generic_frequency_table_verify(struct cpufreq_policy_data *policy)
>>>> {
>>>> + cpufreq_verify_within_cpu_limits(policy);
>>> So if we have a freq-table, we will call this twice now. Why make it
>>> bad for the existing users ?
>>
>> Just to clarify, in the third patch of this series we remove
>> cpufreq_generic_frequency_table_verify() from the table_verify path,
>> so cpufreq_verify_within_cpu_limits() is now only called here. There
>> won’t be any duplicate invocation for drivers that already have a
>> frequency table.
> Maybe I wasn't clear enough.
>
> int cpufreq_frequency_table_verify(...)
> {
> cpufreq_verify_within_cpu_limits(...);
> ...
> }
>
> int cpufreq_generic_frequency_table_verify(...)
> {
> cpufreq_verify_within_cpu_limits(...);
> cpufreq_frequency_table_verify(...);
> ...
> }
>
> For a driver with a valid freq-table, we will call
> cpufreq_verify_within_cpu_limits() unnecessarily, isn't it ?
I understand your point about the potential duplicate call to
cpufreq_verify_within_cpu_limits() for drivers with a valid freq-table.
However, in the third patch of this series, we removed the call to
cpufreq_generic_frequency_table_verify() from the table_verify path.
In the Third patch:
-int cpufreq_frequency_table_verify(struct cpufreq_policy_data *policy)
+static int cpufreq_frequency_table_verify(struct cpufreq_policy_data *policy)
{
struct cpufreq_frequency_table *pos, *table = policy->freq_table;
unsigned int freq, prev_smaller = 0;
@@ -73,8 +73,6 @@ int cpufreq_frequency_table_verify(struct cpufreq_policy_data *policy)
pr_debug("request for verification of policy (%u - %u kHz) for cpu %u\n",
policy->min, policy->max, policy->cpu);
- cpufreq_verify_within_cpu_limits(policy);
-
cpufreq_for_each_valid_entry(pos, table) {
Now, the verification and the CPU limits check are unified in the
generic function, so there is no longer a redundant invocation for
drivers with a frequency table.
Thanks!
next prev parent reply other threads:[~2025-09-04 5:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 3:22 [PATCH v1 0/3] cpufreq: Clean up frequency table handling Zihuan Zhang
2025-09-04 3:22 ` [PATCH v1 1/3] cpufreq: Drop redundant freq_table parameter Zihuan Zhang
2025-09-04 13:31 ` Rafael J. Wysocki
2025-09-05 1:16 ` Zihuan Zhang
2025-09-04 3:22 ` [PATCH v1 2/3] cpufreq: Always enforce policy limits even without frequency table Zihuan Zhang
2025-09-04 4:48 ` Viresh Kumar
2025-09-04 5:23 ` Zihuan Zhang
2025-09-04 5:37 ` Viresh Kumar
2025-09-04 5:48 ` Zihuan Zhang [this message]
2025-09-08 6:13 ` Viresh Kumar
2025-09-08 6:51 ` Zihuan Zhang
2025-09-08 6:55 ` Viresh Kumar
2025-09-08 7:08 ` Zihuan Zhang
2025-09-08 7:19 ` Viresh Kumar
2025-09-08 7:36 ` Zihuan Zhang
2025-09-08 7:44 ` Viresh Kumar
2025-09-04 3:22 ` [PATCH v1 3/3] cpufreq: Make cpufreq_frequency_table_verify() internal Zihuan Zhang
2025-09-04 4:45 ` Viresh Kumar
2025-09-04 5:34 ` Zihuan Zhang
2025-09-08 6:46 ` Viresh Kumar
2025-09-04 4:24 ` [PATCH v1 0/3] cpufreq: Clean up frequency table handling Viresh Kumar
2025-09-04 4:36 ` 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=e91bd1e9-8db4-4923-92fe-52893623487e@kylinos.cn \
--to=zhangzihuan@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=saravanak@google.com \
--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®