linux-kernel - Re: [PATCH v1 2/3] cpufreq: Always enforce policy limits even without 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: <20250908065551.d5jhp5ejix4fzgd2@vireshk-i7>
Date: Mon, 8 Sep 2025 12:25:51 +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 2/3] cpufreq: Always enforce policy limits even
 without frequency table

On 08-09-25, 14:51, Zihuan Zhang wrote:
> We are currently considering moving the check that ensures a driver
> providing a freq_table also implements target_index() into the driver
> registration path.

That won't work AFAIU. The freq table is initialized during
policy->init and that's not done at the time of registration.

> This way, freq_table.c no longer needs to defensively check for NULL
> pointers.
> 
> Additionally, we are thinking about merging the two related APIs into a
> single one. Do you think this is a good idea?

Which ones ? target/target_index ? I am not sure if that can be done.

We are fine with improvements generally, but please make sure whatever
you send doesn't break existing users. That will help saving some of
our review time.

-- 
viresh