[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jun 2016 14:57:47 +0200
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Viresh Kumar <viresh.kumar@...aro.org>
Cc: "Rafael J. Wysocki" <rjw@...ysocki.net>,
Steve Muckle <steve.muckle@...aro.org>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Michael Ellerman <mpe@...erman.id.au>,
Linaro Kernel Mailman List <linaro-kernel@...ts.linaro.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
Dmitry Eremin-Solenikov <dbaryshkov@...il.com>,
Krzysztof Kozlowski <k.kozlowski@...sung.com>,
Kukjin Kim <kgene@...nel.org>,
Shawn Guo <shawn.guo@...escale.com>,
Steven Miao <realmz6@...il.com>
Subject: Re: [PATCH V3 8/9] cpufreq: Keep policy->freq_table sorted in
ascending order
On Mon, Jun 6, 2016 at 2:24 PM, Viresh Kumar <viresh.kumar@...aro.org> wrote:
> On 6 June 2016 at 17:40, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
>> On Monday, June 06, 2016 09:22:31 AM Viresh Kumar wrote:
>
>>> I agree with that, though that requires larger changes across multiple
>>> sites.
>>
>> What changes and where?
>
> s/larger/some :)
>
> So we can change all the callers of cpufreq_frequency_table_target(),
But why?
It just works as a static inline wrapper around cpufreq_find_index_l()
for the code in question after this patch, doesn't it?
So if the caller knows it will always ask for RELATION_L, why bother
with using the wrapper?
Also I'm wondering about the cpufreq_for_each_valid_entry() used all
over. Can't the things be arranged so all of the entries are valid?
Powered by blists - more mailing lists