From: Zihuan Zhang <zhangzihuan@kylinos.cn>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: "Rafael J . wysocki" <rafael@kernel.org>,
Saravana Kannan <saravanak@google.com>,
zhenglifeng <zhenglifeng1@huawei.com>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/3] cpufreq: Always enforce policy limits even without frequency table
Date: Mon, 8 Sep 2025 15:36:34 +0800 [thread overview]
Message-ID: <fecd3bf1-c8a5-4514-b3be-311a09abe5a9@kylinos.cn> (raw)
In-Reply-To: <20250908071920.f6ppfr7shy2cb2wg@vireshk-i7>
在 2025/9/8 15:19, Viresh Kumar 写道:
> On 08-09-25, 15:08, Zihuan Zhang wrote:
>> One idea we are considering is to check whether driver->verify points to
>> cpufreq_generic_frequency_table_verify and use that as a heuristic to
>> enforce the presence of target_index():
>>
>> ((driver_data->verify == cpufreq_generic_frequency_table_verify) !=
>> !!driver_data->target_index)
>>
>> I haven’t tested this approach yet, so I’m not sure if it will be fully
>> reliable.
> I don't this is a good idea. It isn't necessary for any driver to use
> the generic functions.
>
Understood, I thinks there is some reason that the two separate
verification functions exist.
By the way, Do you think it’s necessary to add some defensive checks
during driver registration?
For instance, we could enforce that a driver cannot implement both
has_target and has_target_index at the same time.
next prev parent reply other threads:[~2025-09-08 7:36 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-04 3:22 [PATCH v1 0/3] cpufreq: Clean up frequency table handling Zihuan Zhang
2025-09-04 3:22 ` [PATCH v1 1/3] cpufreq: Drop redundant freq_table parameter Zihuan Zhang
2025-09-04 13:31 ` Rafael J. Wysocki
2025-09-05 1:16 ` Zihuan Zhang
2025-09-04 3:22 ` [PATCH v1 2/3] cpufreq: Always enforce policy limits even without frequency table Zihuan Zhang
2025-09-04 4:48 ` Viresh Kumar
2025-09-04 5:23 ` Zihuan Zhang
2025-09-04 5:37 ` Viresh Kumar
2025-09-04 5:48 ` Zihuan Zhang
2025-09-08 6:13 ` Viresh Kumar
2025-09-08 6:51 ` Zihuan Zhang
2025-09-08 6:55 ` Viresh Kumar
2025-09-08 7:08 ` Zihuan Zhang
2025-09-08 7:19 ` Viresh Kumar
2025-09-08 7:36 ` Zihuan Zhang [this message]
2025-09-08 7:44 ` Viresh Kumar
2025-09-04 3:22 ` [PATCH v1 3/3] cpufreq: Make cpufreq_frequency_table_verify() internal Zihuan Zhang
2025-09-04 4:45 ` Viresh Kumar
2025-09-04 5:34 ` Zihuan Zhang
2025-09-08 6:46 ` Viresh Kumar
2025-09-04 4:24 ` [PATCH v1 0/3] cpufreq: Clean up frequency table handling Viresh Kumar
2025-09-04 4:36 ` Zihuan Zhang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=fecd3bf1-c8a5-4514-b3be-311a09abe5a9@kylinos.cn \
--to=zhangzihuan@kylinos.cn \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=saravanak@google.com \
--cc=viresh.kumar@linaro.org \
--cc=zhenglifeng1@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®