[PATCH] PM / OPP: Remove ARCH_HAS_OPP

Magnus Damm magnus.damm at gmail.com
Fri Jun 6 06:01:05 PDT 2014


On Fri, Jun 6, 2014 at 9:50 PM, Simon Horman <horms at verge.net.au> wrote:
> On Fri, Jun 06, 2014 at 09:14:01PM +0900, Magnus Damm wrote:
>> On Fri, Jun 6, 2014 at 8:14 PM, Simon Horman <horms at verge.net.au> wrote:
>> > On Fri, Jun 06, 2014 at 11:36:56AM +0100, Mark Brown wrote:
>> >> From: Mark Brown <broonie at linaro.org>
>> >>
>> >> Since the OPP layer is a kernel library which has been converted to be
>> >> directly selectable by its callers rather than user selectable and
>> >> requiring architectures to enable it explicitly the ARCH_HAS_OPP symbol
>> >> has become redundant and can be removed. Do so.
>> >>
>> >> Signed-off-by: Mark Brown <broonie at linaro.org>
>> >> ---
>> >>  Documentation/power/opp.txt    | 3 ---
>> >>  arch/arm/mach-exynos/Kconfig   | 1 -
>> >>  arch/arm/mach-highbank/Kconfig | 1 -
>> >>  arch/arm/mach-imx/Kconfig      | 1 -
>> >>  arch/arm/mach-omap2/Kconfig    | 1 -
>> >>  arch/arm/mach-shmobile/Kconfig | 2 --
>> >>  arch/arm/mach-vexpress/Kconfig | 1 -
>> >>  arch/arm/mach-zynq/Kconfig     | 1 -
>> >>  drivers/devfreq/Kconfig        | 1 -
>> >>  kernel/power/Kconfig           | 3 ---
>> >>  10 files changed, 15 deletions(-)
>> >
>> > shmobile portion:
>> >
>> > Acked-by: Simon Horman <horms+renesas at verge.net.au>
>>
>> Hi Simon, Mark,
>>
>> Nice to see cleanups in this area. Reducing the number of Kconfig
>> symbols must be a good thing.
>>
>> I'm not sure about the expected merge order for this kind of change vs
>> queued up stuff in the renesas git tree, but I believe the following
>> patch selects ARCH_HAS_OPP:
>>
>> [PATCH v3] ARM: shmobile: Mark all SoCs in shmobile as CPUFreq, capable
>
> I propose that we fix that up by adding an incremental patch to
> mach-shmobile via my renesas tree once the dependency (assuming there is
> one) is in Linus's tree.

Sounds good. Thanks!

/ magnus



More information about the linux-arm-kernel mailing list