mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iteration
Subsystems (2)
PATCH v2 5/8 mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iteration
The cpufreq core now supports the cpufreq_for_each_entry macro helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
--- drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
drivers/mfd/db8500-prcmu.c +8 -11
@@ -1734,18 +1734,17 @@ static struct cpufreq_frequency_table db8500_cpufreq_table[] = {static long round_armss_rate (unsigned long rate) { +struct cpufreq_frequency_table *pos;long freq =0 ; -int i =0 ;/* cpufreq table frequencies is in KHz. */ rate = rate /1000 ;/* Find the corresponding arm opp from the cpufreq table. */ -while (db8500_cpufreq_table[i].frequency !=CPUFREQ_TABLE_END ) { - freq = db8500_cpufreq_table[i].frequency; +cpufreq_for_each_entry (pos, db8500_cpufreq_table) { + freq = pos->frequency;if (freq == rate)break ; - i++; }/* Return the last valid value, even if a match was not found. */
@@ -1886,23 +1885,21 @@ static void set_clock_rate(u8 clock, unsigned long rate)static int set_armss_rate (unsigned long rate) { -int i =0 ; +struct cpufreq_frequency_table *pos;/* cpufreq table frequencies is in KHz. */ rate = rate /1000 ;/* Find the corresponding arm opp from the cpufreq table. */ -while (db8500_cpufreq_table[i].frequency !=CPUFREQ_TABLE_END ) { -if (db8500_cpufreq_table[i].frequency == rate) +cpufreq_for_each_entry (pos, db8500_cpufreq_table) +if (pos->frequency == rate)break ; - i++; - } -if (db8500_cpufreq_table[i].frequency != rate) +if (pos->frequency != rate)return -EINVAL ;/* Set the new arm opp. */ -return db8500_prcmu_set_arm_opp (db8500_cpufreq_table[i].driver_data); +return db8500_prcmu_set_arm_opp (pos->driver_data); }static int set_plldsi_rate (unsigned long rate)
Signature · 1 line
1.9.0
Quoted 9 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>--- drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
Applied untested by me.
Linus if you could find the time to do the honours I'd me much obliged.
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 11 lines · Lee Jones
Quoted 9 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>--- drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)Applied untested by me.
Wouldn't build. Let it go via Rafael.
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
Signed-off-by Stratos Karafotis <[email protected]>--- drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)Applied untested by me.
Wouldn't build. Let it go via Rafael.
Rafael, would you mind creating a branch from this patch set that we can both pull from please?
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
PATCH v4 5/8 mfd: db8500-prcmu: Use cpufreq_for_each_entry macro for iteration
In reply to Stratos KarafotisThe cpufreq core now supports the cpufreq_for_each_entry macro helper for iteration over the cpufreq_frequency_table, so use it.
It should have no functional changes.
--- drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
drivers/mfd/db8500-prcmu.c +8 -11
@@ -1734,18 +1734,17 @@ static struct cpufreq_frequency_table db8500_cpufreq_table[] = {static long round_armss_rate (unsigned long rate) { +struct cpufreq_frequency_table *pos;long freq =0 ; -int i =0 ;/* cpufreq table frequencies is in KHz. */ rate = rate /1000 ;/* Find the corresponding arm opp from the cpufreq table. */ -while (db8500_cpufreq_table[i].frequency !=CPUFREQ_TABLE_END ) { - freq = db8500_cpufreq_table[i].frequency; +cpufreq_for_each_entry (pos, db8500_cpufreq_table) { + freq = pos->frequency;if (freq == rate)break ; - i++; }/* Return the last valid value, even if a match was not found. */
@@ -1886,23 +1885,21 @@ static void set_clock_rate(u8 clock, unsigned long rate)static int set_armss_rate (unsigned long rate) { -int i =0 ; +struct cpufreq_frequency_table *pos;/* cpufreq table frequencies is in KHz. */ rate = rate /1000 ;/* Find the corresponding arm opp from the cpufreq table. */ -while (db8500_cpufreq_table[i].frequency !=CPUFREQ_TABLE_END ) { -if (db8500_cpufreq_table[i].frequency == rate) +cpufreq_for_each_entry (pos, db8500_cpufreq_table) +if (pos->frequency == rate)break ; - i++; - } -if (db8500_cpufreq_table[i].frequency != rate) +if (pos->frequency != rate)return -EINVAL ;/* Set the new arm opp. */ -return db8500_prcmu_set_arm_opp (db8500_cpufreq_table[i].driver_data); +return db8500_prcmu_set_arm_opp (pos->driver_data); }static int set_plldsi_rate (unsigned long rate)
Signature · 1 line
1.9.0
Quoted 7 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>---
It would be good to have a changelog which describes the differences between the versions, so we can keep track.
Quoted 2 lines
drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
So it looks like I already applied v2 of this patch to my tree. What changed in v3 and v4? Should I remove that patch from MFD and apply this one instead?
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 11 lines · Lee Jones
Quoted 7 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>---
It would be good to have a changelog which describes the differences between the versions, so we can keep track.
Quoted 6 lines
Quoted 2 lines
drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)So it looks like I already applied v2 of this patch to my tree. What changed in v3 and v4? Should I remove that patch from MFD and apply this one instead?
The reason why v4 was sent is because I asked for it.
And if you applied [5/8] without [1/8], it won't work, because the macro is introduced by that patch.
If that's the case, please drop [5/8] and let me handle the entire series.
Kind regards,
Rafael
Quoted 15 lines · Rafael J. Wysocki
Quoted 14 lines · Lee Jones
Quoted 7 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>---
It would be good to have a changelog which describes the differences between the versions, so we can keep track.
Quoted 2 lines
drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)
Quoted 8 lines
Quoted 3 lines
So it looks like I already applied v2 of this patch to my tree. What changed in v3 and v4? Should I remove that patch from MFD and apply this one instead?
The reason why v4 was sent is because I asked for it.
And if you applied [5/8] without [1/8], it won't work, because the macro is introduced by that patch.
That's right, which is why I mailed you about it:
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Applied untested by me.
Wouldn't build. Let it go via Rafael.
Rafael, would you mind creating a branch from this patch set that we can both pull from please?
If that's the case, please drop [5/8] and let me handle the entire series.
I'm happy for you to apply the series and send me a pull-request for either a) the entire series or b) just the patches which touch MFD and any subsequent decencies. Or I can apply them and send you one.
Signature · 4 lines
Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog
Quoted 32 lines · Lee Jones
Quoted 15 lines · Rafael J. Wysocki
Quoted 14 lines · Lee Jones
Quoted 7 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>---
It would be good to have a changelog which describes the differences between the versions, so we can keep track.
Quoted 2 lines
drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)Quoted 8 lines
Quoted 3 lines
So it looks like I already applied v2 of this patch to my tree. What changed in v3 and v4? Should I remove that patch from MFD and apply this one instead?
The reason why v4 was sent is because I asked for it.
And if you applied [5/8] without [1/8], it won't work, because the macro is introduced by that patch.
That's right, which is why I mailed you about it:
Quoted 4 lines
Quoted 3 lines
Quoted 1 line
Applied untested by me.
Wouldn't build. Let it go via Rafael.
Quoted 8 lines
Quoted 4 lines
Rafael, would you mind creating a branch from this patch set that we can both pull from please?
If that's the case, please drop [5/8] and let me handle the entire series.
I'm happy for you to apply the series and send me a pull-request for either a) the entire series or b) just the patches which touch MFD and any subsequent decencies. Or I can apply them and send you one.
OK, I'll create a separate branch with those patches and will let you know where it is.
Kind regards,
Rafael
Quoted 36 lines · Rafael J. Wysocki
Quoted 35 lines · Lee Jones
Quoted 15 lines · Rafael J. Wysocki
Quoted 14 lines · Lee Jones
Quoted 7 lines
The cpufreq core now supports the
cpufreq_for_each_entrymacro helper for iteration over thecpufreq_frequency_table, so use it.It should have no functional changes.
Signed-off-by Stratos Karafotis <[email protected]>---
It would be good to have a changelog which describes the differences between the versions, so we can keep track.
Quoted 2 lines
drivers/mfd/db8500-prcmu.c | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-)Quoted 8 lines
Quoted 3 lines
So it looks like I already applied v2 of this patch to my tree. What changed in v3 and v4? Should I remove that patch from MFD and apply this one instead?
The reason why v4 was sent is because I asked for it.
And if you applied [5/8] without [1/8], it won't work, because the macro is introduced by that patch.
That's right, which is why I mailed you about it:
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Applied untested by me.
Wouldn't build. Let it go via Rafael.
Rafael, would you mind creating a branch from this patch set that we can both pull from please?
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
If that's the case, please drop [5/8] and let me handle the entire series.
I'm happy for you to apply the series and send me a pull-request for either a) the entire series or b) just the patches which touch MFD and any subsequent decencies. Or I can apply them and send you one.
OK, I'll create a separate branch with those patches and will let you know where it is.
This material is on the cpufreq-macros branch of the linux-pm.git tree now, so
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git cpufreq-macros
will be safe to pull from going forward.
Thanks!
Signature · 2 lines
I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center.