[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cec3bcea-4c75-4869-b9b8-efd3412a1e17@kylinos.cn>
Date: Thu, 4 Sep 2025 13:34:01 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J . wysocki" <rafael@...nel.org>,
Saravana Kannan <saravanak@...gle.com>, zhenglifeng
<zhenglifeng1@...wei.com>, linux-pm@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 3/3] cpufreq: Make cpufreq_frequency_table_verify()
internal
在 2025/9/4 12:45, Viresh Kumar 写道:
> On 04-09-25, 11:22, Zihuan Zhang wrote:
>> diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
>> index 642ddb9ea217..ee3fd1e71b90 100644
>> --- a/drivers/cpufreq/sh-cpufreq.c
>> +++ b/drivers/cpufreq/sh-cpufreq.c
>> @@ -90,10 +90,8 @@ static int sh_cpufreq_verify(struct cpufreq_policy_data *policy)
>> {
>> struct clk *cpuclk = &per_cpu(sh_cpuclk, policy->cpu);
>>
>> - if (policy->freq_table)
>> - return cpufreq_frequency_table_verify(policy);
>> -
>> - cpufreq_verify_within_cpu_limits(policy);
>> + if (!cpufreq_generic_frequency_table_verify(policy))
>> + return 0;
>>
>> policy->min = (clk_round_rate(cpuclk, 1) + 500) / 1000;
>> policy->max = (clk_round_rate(cpuclk, ~0UL) + 500) / 1000;
>> diff --git a/drivers/cpufreq/virtual-cpufreq.c b/drivers/cpufreq/virtual-cpufreq.c
>> index 6ffa16d239b2..2498f40cd57e 100644
>> --- a/drivers/cpufreq/virtual-cpufreq.c
>> +++ b/drivers/cpufreq/virtual-cpufreq.c
>> @@ -249,10 +249,7 @@ static int virt_cpufreq_offline(struct cpufreq_policy *policy)
>>
>> static int virt_cpufreq_verify_policy(struct cpufreq_policy_data *policy)
>> {
>> - if (policy->freq_table)
>> - return cpufreq_frequency_table_verify(policy);
>> -
>> - cpufreq_verify_within_cpu_limits(policy);
>> + cpufreq_generic_frequency_table_verify(policy);
>> return 0;
>> }
> You ended up changing the logic of both these files and it isn't the
> same anymore. Earlier if freq_table was there and
> cpufreq_frequency_table_verify() failed, we used to return, but not
> anymore.
>
> And we don't return the error anymore for virtual driver.
Thanks for pointing this out, Viresh.
You are correct — with the current changes, if
cpufreq_generic_frequency_table_verify() fails, we no longer return
an error in these drivers. For drivers that lack a frequency table,
they can still operate, which is why I wasn’t sure whether returning
an error is strictly necessary.
I would appreciate your advice here: should we preserve the old
behavior and return an error on failure, or is it acceptable for
drivers without a table to continue without it?
>
Powered by blists - more mailing lists