linux-kernel - Re: [PATCH v2] cpufreq: Replace pointer subtraction with iteration macros

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: <20250923090910.6ojsyi333ijyjmmo@lcpd911>
Date: Tue, 23 Sep 2025 14:39:10 +0530
From: Dhruva Gole <d-gole@...com>
To: Zihuan Zhang <zhangzihuan@...inos.cn>
CC: "Rafael J . wysocki" <rafael@...nel.org>,
        Viresh Kumar
	<viresh.kumar@...aro.org>,
        zhenglifeng <zhenglifeng1@...wei.com>, <linux-pm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2] cpufreq: Replace pointer subtraction with iteration
 macros

On Sep 23, 2025 at 15:55:53 +0800, Zihuan Zhang wrote:
> The cpufreq documentation suggests avoiding direct pointer subtraction
> when working with entries in driver_freq_table, as it is relatively
> costly. Instead, the recommended approach is to use the provided
> iteration macros:

Thanks for the patch,
Just say "macro" not "macros".

> 
> - cpufreq_for_each_valid_entry_idx()
> 
> Replace pointer subtraction in freq_table.c with the macros
> cpufreq_for_each_entry_idx() and cpufreq_for_each_valid_entry_idx(), as

Where is "cpufreq_for_each_entry_idx" in this entire patch?
Please drop this reference, why confuse people?

> the index does not need initialization, avoiding unnecessary
> computation. This improves code clarity and follows the established
> cpufreq coding style.

You don't need to add all this to the commit message about the
unnecessary computation, code clarity, etc..
Please keep it to the point.

> 
> No functional change intended.
> 
> Signed-off-by: Zihuan Zhang <zhangzihuan@...inos.cn>
> 
> V2:
>  - Remove unnecessary initialization for current and remaining follow Rafael's suggestion

You didn't fix Rafael's first comment [1] about the $subject, and also please
add links to previous revisions for ease of review.

[1] > In the subject, this is just one macro, not multiple macros.


> ---
>  drivers/cpufreq/freq_table.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c
> index d5111ee56e38..408fd8fee2e3 100644
> --- a/drivers/cpufreq/freq_table.c
> +++ b/drivers/cpufreq/freq_table.c
> @@ -33,16 +33,17 @@ int cpufreq_frequency_table_cpuinfo(struct cpufreq_policy *policy)
>  	struct cpufreq_frequency_table *pos, *table = policy->freq_table;
>  	unsigned int min_freq = ~0;
>  	unsigned int max_freq = 0;
> +	unsigned int i;
>  	unsigned int freq;
>  
> -	cpufreq_for_each_valid_entry(pos, table) {
> +	cpufreq_for_each_valid_entry_idx(pos, table, i) {
>  		freq = pos->frequency;
>  
>  		if ((!cpufreq_boost_enabled() || !policy->boost_enabled)
>  		    && (pos->flags & CPUFREQ_BOOST_FREQ))
>  			continue;
>  
> -		pr_debug("table entry %u: %u kHz\n", (int)(pos - table), freq);
> +		pr_debug("table entry %u: %u kHz\n", i, freq);
>  		if (freq < min_freq)
>  			min_freq = freq;
>  		if (freq > max_freq)
> @@ -126,7 +127,7 @@ int cpufreq_table_index_unsorted(struct cpufreq_policy *policy,
>  	};
>  	struct cpufreq_frequency_table *pos;
>  	struct cpufreq_frequency_table *table = policy->freq_table;
> -	unsigned int freq, diff, i = 0;
> +	unsigned int freq, diff, i;
>  	int index;

Usually, it isn't advised to touch code that's not strictly relevant to
your patch. However since this seems like a minor fixup it's fine by
me... Upto Rafael whether he prefers to have/not have this unrelated change.

But atleast mention in your commit message that you're also removing the
initialization from cpufreq_table_index_unsorted as part of some minor cleanup
(which seems kinda unnecessary to me TBH in the first place)

-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated