[27/27] cpufreq: Drop cpufreq_table_validate_and_show()

Message ID 651f495d68e8d980cc80aa2247e749504a0de9d4.1519620578.git.viresh.kumar@linaro.org
State Superseded
Headers show
Series
  • cpufreq: Stop validating cpufreq table in drivers
Related show

Commit Message

Viresh Kumar Feb. 26, 2018, 5:09 a.m.
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(-)

-- 
2.15.0.194.g9af6a3dea062

Comments

Sudeep Holla March 7, 2018, 4:44 p.m. | #1
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.

-- 
Regards,
Sudeep
Viresh Kumar March 8, 2018, 5:05 a.m. | #2
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.

-- 
viresh
Sudeep Holla March 8, 2018, 12:22 p.m. | #3
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

-- 
Regards,
Sudeep
Rafael J. Wysocki March 8, 2018, 12:27 p.m. | #4
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?
Sudeep Holla March 8, 2018, 12:44 p.m. | #5
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.

-- 
Regards,
Sudeep
Rafael J. Wysocki March 8, 2018, 12:46 p.m. | #6
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
Viresh Kumar March 9, 2018, 3:37 a.m. | #7
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 :)

-- 
viresh
Rafael J. Wysocki March 9, 2018, 9:19 a.m. | #8
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.
Viresh Kumar March 9, 2018, 9:27 a.m. | #9
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.

-- 
viresh
Rafael J. Wysocki March 9, 2018, 9:55 a.m. | #10
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".

Patch

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);