[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fecd3bf1-c8a5-4514-b3be-311a09abe5a9@kylinos.cn>
Date: Mon, 8 Sep 2025 15:36:34 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Viresh Kumar <viresh.kumar@...aro.org>
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
在 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.
Powered by blists - more mailing lists