linux-kernel - Re: [PATCH v1 3/3] cpufreq: Make cpufreq_frequency_table

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: <20250908064649.5kk44m5ihdspyair@vireshk-i7>
Date: Mon, 8 Sep 2025 12:16:49 +0530
From: Viresh Kumar <viresh.kumar@...aro.org>
To: Zihuan Zhang <zhangzihuan@...inos.cn>
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

On 04-09-25, 13:34, Zihuan Zhang wrote:
> 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?

I looked at the code again, and it feels like the current code is
doing the right thing right now and making the suggested changes will
only make it less readable. The two function have different purpose
and it looks better if the callers call them explicitly.

So, I would suggest dropping patches 2 and 3.

-- 
viresh