Previously, some cpufreq core helper functions accepted a separate
'freq_table' argument even though the frequency table is now stored
inside struct cpufreq_policy.

This patch updates all cpufreq core calls to remove the redundant
argument and use policy directly.

Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
---
 drivers/cpufreq/sh-cpufreq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
index 9c0b01e00508..75d224ba56ba 100644
--- a/drivers/cpufreq/sh-cpufreq.c
+++ b/drivers/cpufreq/sh-cpufreq.c
@@ -93,7 +93,7 @@ static int sh_cpufreq_verify(struct cpufreq_policy_data *policy)
 
 	freq_table = cpuclk->nr_freqs ? cpuclk->freq_table : NULL;
 	if (freq_table)
-		return cpufreq_frequency_table_verify(policy, freq_table);
+		return cpufreq_frequency_table_verify(policy);
 
 	cpufreq_verify_within_cpu_limits(policy);
 
-- 
2.25.1

On 01-09-25, 19:25, Zihuan Zhang wrote:
> Previously, some cpufreq core helper functions accepted a separate
> 'freq_table' argument even though the frequency table is now stored
> inside struct cpufreq_policy.
> 
> This patch updates all cpufreq core calls to remove the redundant
> argument and use policy directly.
> 
> Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
> ---
>  drivers/cpufreq/sh-cpufreq.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
> index 9c0b01e00508..75d224ba56ba 100644
> --- a/drivers/cpufreq/sh-cpufreq.c
> +++ b/drivers/cpufreq/sh-cpufreq.c
> @@ -93,7 +93,7 @@ static int sh_cpufreq_verify(struct cpufreq_policy_data *policy)
>  
>  	freq_table = cpuclk->nr_freqs ? cpuclk->freq_table : NULL;
>  	if (freq_table)

Instead of above, you can now simply check if policy->freq_table is
valid or not.

> -		return cpufreq_frequency_table_verify(policy, freq_table);
> +		return cpufreq_frequency_table_verify(policy);
>  
>  	cpufreq_verify_within_cpu_limits(policy);
>  
> -- 
> 2.25.1

-- 
viresh

在 2025/9/2 13:40, Viresh Kumar 写道:
> On 01-09-25, 19:25, Zihuan Zhang wrote:
>> Previously, some cpufreq core helper functions accepted a separate
>> 'freq_table' argument even though the frequency table is now stored
>> inside struct cpufreq_policy.
>>
>> This patch updates all cpufreq core calls to remove the redundant
>> argument and use policy directly.
>>
>> Signed-off-by: Zihuan Zhang <zhangzihuan@kylinos.cn>
>> ---
>>   drivers/cpufreq/sh-cpufreq.c | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/cpufreq/sh-cpufreq.c b/drivers/cpufreq/sh-cpufreq.c
>> index 9c0b01e00508..75d224ba56ba 100644
>> --- a/drivers/cpufreq/sh-cpufreq.c
>> +++ b/drivers/cpufreq/sh-cpufreq.c
>> @@ -93,7 +93,7 @@ static int sh_cpufreq_verify(struct cpufreq_policy_data *policy)
>>   
>>   	freq_table = cpuclk->nr_freqs ? cpuclk->freq_table : NULL;
>>   	if (freq_table)
> Instead of above, you can now simply check if policy->freq_table is
> valid or not.


I also noticed that in some drivers like acpi-cpufreq.c, if freq_table 
allocation fails, the driver won’t be registered at all.

In such cases,

should the NULL check be done inside the core helper functions, or 
should it be left to the drivers?

>> -		return cpufreq_frequency_table_verify(policy, freq_table);
>> +		return cpufreq_frequency_table_verify(policy);
>>   
>>   	cpufreq_verify_within_cpu_limits(policy);
>>   
>> -- 
>> 2.25.1

On 02-09-25, 14:06, Zihuan Zhang wrote:
> I also noticed that in some drivers like acpi-cpufreq.c, if freq_table
> allocation fails, the driver won’t be registered at all.
> 
> In such cases,
> 
> should the NULL check be done inside the core helper functions, or should it
> be left to the drivers?

Not all drivers need a freq-table and so it is fine for them to not
have one. This driver looks like can work without a freq table too.

-- 
viresh

在 2025/9/2 14:23, Viresh Kumar 写道:
> On 02-09-25, 14:06, Zihuan Zhang wrote:
>> I also noticed that in some drivers like acpi-cpufreq.c, if freq_table
>> allocation fails, the driver won’t be registered at all.
>>
>> In such cases,
>>
>> should the NULL check be done inside the core helper functions, or should it
>> be left to the drivers?
> Not all drivers need a freq-table and so it is fine for them to not
> have one. This driver looks like can work without a freq table too.
>
Understood, Thanks!