linux-kernel - Re: [PATCH v1 2/3] cpufreq: sh: drop redundant freq

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <34092883-c04d-4dbb-a756-eac89fbe6f3e@kylinos.cn>
Date: Tue, 2 Sep 2025 14:06:39 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J . wysocki" <rafael@...nel.org>,
 zhenglifeng <zhenglifeng1@...wei.com>, linux-pm@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 2/3] cpufreq: sh: drop redundant freq_table argument

在 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@...inos.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