| Message ID | 651f495d68e8d980cc80aa2247e749504a0de9d4.1519620578.git.viresh.kumar@linaro.org (mailing list archive) |
|---|---|
| State | Deferred |
| Headers | show |
On 26/02/18 05:09, Viresh Kumar wrote: > This isn't used anymore. Remove the helper and update documentation > accordingly. > Just a request, can we merge this patch dropping the function later ? The reason I ask is that I am planning to get scmi-cpufreq.c merged via arm-soc. I am open for other suggestions, but IMO, I can post similar patch to scmi-cpufreq.c once merged and then this can be dropped along with that in order to keep it simple and avoid dependency in linux-next.
On 07-03-18, 16:44, Sudeep Holla wrote: > Just a request, can we merge this patch dropping the function later ? > > The reason I ask is that I am planning to get scmi-cpufreq.c merged via > arm-soc. I am open for other suggestions, but IMO, I can post similar > patch to scmi-cpufreq.c once merged and then this can be dropped along > with that in order to keep it simple and avoid dependency in linux-next. There are two ways here really: - Rafael gives you a branch with the core patch applied, so that you can stop using this routine. But that requires co-ordination during merges, etc. - Second is the way you said, hold this patch for 4.17-rc2 and wait for everything else to get merged. And I am fine with this one.
On 08/03/18 05:05, Viresh Kumar wrote: > On 07-03-18, 16:44, Sudeep Holla wrote: >> Just a request, can we merge this patch dropping the function later ? >> >> The reason I ask is that I am planning to get scmi-cpufreq.c merged via >> arm-soc. I am open for other suggestions, but IMO, I can post similar >> patch to scmi-cpufreq.c once merged and then this can be dropped along >> with that in order to keep it simple and avoid dependency in linux-next. > > There are two ways here really: > > - Rafael gives you a branch with the core patch applied, so that you can stop > using this routine. But that requires co-ordination during merges, etc. > Indeed and hence thought option 2 would be simpler :) > - Second is the way you said, hold this patch for 4.17-rc2 and wait for > everything else to get merged. And I am fine with this one. > Thanks
On Thu, Mar 8, 2018 at 1:22 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 08/03/18 05:05, Viresh Kumar wrote: >> On 07-03-18, 16:44, Sudeep Holla wrote: >>> Just a request, can we merge this patch dropping the function later ? >>> >>> The reason I ask is that I am planning to get scmi-cpufreq.c merged via >>> arm-soc. I am open for other suggestions, but IMO, I can post similar >>> patch to scmi-cpufreq.c once merged and then this can be dropped along >>> with that in order to keep it simple and avoid dependency in linux-next. >> >> There are two ways here really: >> >> - Rafael gives you a branch with the core patch applied, so that you can stop >> using this routine. But that requires co-ordination during merges, etc. >> > > Indeed and hence thought option 2 would be simpler :) > >> - Second is the way you said, hold this patch for 4.17-rc2 and wait for >> everything else to get merged. And I am fine with this one. Option 3: Why can't it be deferred till the 4.18 merge window?
On 08/03/18 12:27, Rafael J. Wysocki wrote: > On Thu, Mar 8, 2018 at 1:22 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: >> >> >> On 08/03/18 05:05, Viresh Kumar wrote: >>> On 07-03-18, 16:44, Sudeep Holla wrote: >>>> Just a request, can we merge this patch dropping the function later ? >>>> >>>> The reason I ask is that I am planning to get scmi-cpufreq.c merged via >>>> arm-soc. I am open for other suggestions, but IMO, I can post similar >>>> patch to scmi-cpufreq.c once merged and then this can be dropped along >>>> with that in order to keep it simple and avoid dependency in linux-next. >>> >>> There are two ways here really: >>> >>> - Rafael gives you a branch with the core patch applied, so that you can stop >>> using this routine. But that requires co-ordination during merges, etc. >>> >> >> Indeed and hence thought option 2 would be simpler :) >> >>> - Second is the way you said, hold this patch for 4.17-rc2 and wait for >>> everything else to get merged. And I am fine with this one. > > Option 3: Why can't it be deferred till the 4.18 merge window? > It can be, just to prevent new drivers relying on it and discover it bit late ? I am fine with it though.
On Thu, Mar 8, 2018 at 1:44 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: > > > On 08/03/18 12:27, Rafael J. Wysocki wrote: >> On Thu, Mar 8, 2018 at 1:22 PM, Sudeep Holla <sudeep.holla@arm.com> wrote: >>> >>> >>> On 08/03/18 05:05, Viresh Kumar wrote: >>>> On 07-03-18, 16:44, Sudeep Holla wrote: >>>>> Just a request, can we merge this patch dropping the function later ? >>>>> >>>>> The reason I ask is that I am planning to get scmi-cpufreq.c merged via >>>>> arm-soc. I am open for other suggestions, but IMO, I can post similar >>>>> patch to scmi-cpufreq.c once merged and then this can be dropped along >>>>> with that in order to keep it simple and avoid dependency in linux-next. >>>> >>>> There are two ways here really: >>>> >>>> - Rafael gives you a branch with the core patch applied, so that you can stop >>>> using this routine. But that requires co-ordination during merges, etc. >>>> >>> >>> Indeed and hence thought option 2 would be simpler :) >>> >>>> - Second is the way you said, hold this patch for 4.17-rc2 and wait for >>>> everything else to get merged. And I am fine with this one. >> >> Option 3: Why can't it be deferred till the 4.18 merge window? >> > It can be, just to prevent new drivers relying on it and discover it bit > late ? Review should catch that IMO. > I am fine with it though. OK
On 08-03-18, 13:27, Rafael J. Wysocki wrote:
> Option 3: Why can't it be deferred till the 4.18 merge window?
That would be fine if that's how you would like to do it.
I would be more interested in getting the other 26 patches in 4.17-rc1 first :)
On Fri, Mar 9, 2018 at 4:37 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 08-03-18, 13:27, Rafael J. Wysocki wrote: >> Option 3: Why can't it be deferred till the 4.18 merge window? > > That would be fine if that's how you would like to do it. > > I would be more interested in getting the other 26 patches in 4.17-rc1 first :) So you basically need to find someone to review them. I can take care of acpi-cpufreq myself, I guess there's a couple of others where nobody cares really, but there are a few where people actively work on stuff.
On 09-03-18, 10:19, Rafael J. Wysocki wrote: > So you basically need to find someone to review them. > > I can take care of acpi-cpufreq myself, I guess there's a couple of > others where nobody cares really, but there are a few where people > actively work on stuff. The relevant people should already be cc'd (with help of get_maintainers.pl) and they should respond if they care. I am not sure who else I ask to review these patches (apart from you of course). 0-day testing hasn't raised any concerns, so the platform it builds (almost all) should be fine compilation-wise and the platform it boots (not all) should be fine too. The next best thing to test it out would be to place it under linux-next for a few weeks and see if someone reports something.
On Fri, Mar 9, 2018 at 10:27 AM, Viresh Kumar <viresh.kumar@linaro.org> wrote: > On 09-03-18, 10:19, Rafael J. Wysocki wrote: >> So you basically need to find someone to review them. >> >> I can take care of acpi-cpufreq myself, I guess there's a couple of >> others where nobody cares really, but there are a few where people >> actively work on stuff. > > The relevant people should already be cc'd (with help of get_maintainers.pl) and > they should respond if they care. I am not sure who else I ask to review these > patches (apart from you of course). Maybe ping the CC list and say "Hey, we will assume no objections or concerns if you don't respond and the series will go into linux-next next week".
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt index 978463a7c81e..073f128af5a7 100644 --- a/Documentation/cpu-freq/core.txt +++ b/Documentation/cpu-freq/core.txt @@ -97,12 +97,10 @@ flags - flags of the cpufreq driver ================================================================== For details about OPP, see Documentation/power/opp.txt -dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with - cpufreq_table_validate_and_show() which is provided with the list of - frequencies that are available for operation. This function provides - a ready to use conversion routine to translate the OPP layer's internal - information about the available frequencies into a format readily - providable to cpufreq. +dev_pm_opp_init_cpufreq_table - + This function provides a ready to use conversion routine to translate + the OPP layer's internal information about the available frequencies + into a format readily providable to cpufreq. WARNING: Do not use this function in interrupt context. @@ -112,7 +110,7 @@ dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with /* Do things */ r = dev_pm_opp_init_cpufreq_table(dev, &freq_table); if (!r) - cpufreq_table_validate_and_show(policy, freq_table); + policy->freq_table = freq_table; /* Do other things */ } diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 61546ac578d6..6e353d00cdc6 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -259,10 +259,8 @@ CPUFREQ_ENTRY_INVALID. The entries don't need to be in sorted in any particular order, but if they are cpufreq core will do DVFS a bit quickly for them as search for best match is faster. -By calling cpufreq_table_validate_and_show(), the cpuinfo.min_freq and -cpuinfo.max_freq values are detected, and policy->min and policy->max -are set to the same values. This is helpful for the per-CPU -initialization stage. +The cpufreq table is verified automatically by the core if the policy contains a +valid pointer in its policy->freq_table field. cpufreq_frequency_table_verify() assures that at least one valid frequency is within policy->min and policy->max, and all other criteria diff --git a/drivers/cpufreq/freq_table.c b/drivers/cpufreq/freq_table.c index 10e119ae66dd..3a8cc99e6815 100644 --- a/drivers/cpufreq/freq_table.c +++ b/drivers/cpufreq/freq_table.c @@ -352,20 +352,6 @@ static int set_freq_table_sorted(struct cpufreq_policy *policy) return 0; } -int cpufreq_table_validate_and_show(struct cpufreq_policy *policy, - struct cpufreq_frequency_table *table) -{ - int ret; - - ret = cpufreq_frequency_table_cpuinfo(policy, table); - if (ret) - return ret; - - policy->freq_table = table; - return 0; -} -EXPORT_SYMBOL_GPL(cpufreq_table_validate_and_show); - int cpufreq_table_validate_and_sort(struct cpufreq_policy *policy) { int ret; diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h index 1fe49724da9e..87f48dd932eb 100644 --- a/include/linux/cpufreq.h +++ b/include/linux/cpufreq.h @@ -960,8 +960,6 @@ extern void arch_set_freq_scale(struct cpumask *cpus, unsigned long cur_freq, extern struct freq_attr cpufreq_freq_attr_scaling_available_freqs; extern struct freq_attr cpufreq_freq_attr_scaling_boost_freqs; extern struct freq_attr *cpufreq_generic_attr[]; -int cpufreq_table_validate_and_show(struct cpufreq_policy *policy, - struct cpufreq_frequency_table *table); int cpufreq_table_validate_and_sort(struct cpufreq_policy *policy); unsigned int cpufreq_generic_get(unsigned int cpu);
This isn't used anymore. Remove the helper and update documentation accordingly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> --- Documentation/cpu-freq/core.txt | 12 +++++------- Documentation/cpu-freq/cpu-drivers.txt | 6 ++---- drivers/cpufreq/freq_table.c | 14 -------------- include/linux/cpufreq.h | 2 -- 4 files changed, 7 insertions(+), 27 deletions(-)