diff mbox

[v2] cpufreq: Kconfig.arm: Fix unmet direct dependencies

Message ID CAOMZO5BvaTm7BfS_+0pwCUyOJTpCOtsinjfs9fJ-SR9dURHEzg@mail.gmail.com (mailing list archive)
State Superseded, archived
Headers show

Commit Message

Fabio Estevam Feb. 18, 2014, 1:07 p.m. UTC 
On Tue, Feb 18, 2014 at 9:57 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> On Tuesday, February 18, 2014 09:35:51 AM Fabio Estevam wrote:
>> Currently the following warning is generated when building multi_v7_defconfig:
>>
>> $ make multi_v7_defconfig
>> warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL)
>> # configuration written to .config
>>
>> Instead of forcing the selection of GENERIC_CPUFREQ_CPU0 and REGULATOR, change
>> it to 'depends on' instead.
>
> OK
>
> Any objections here?

Thinking more about it I think the correct fix would be:


Because we have:

config GENERIC_CPUFREQ_CPU0
    tristate "Generic CPU0 cpufreq driver"
    depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
    select PM_OPP
    help
      This adds a generic cpufreq driver for CPU0 frequency management.
      It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
      systems which share clock and voltage across all CPUs.

If everyone agrees I would send a v3 with such fix.

Thanks,

Fabio Estevam
--
To unsubscribe from this list: send the line "unsubscribe linux-pm" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Rafael J. Wysocki Feb. 18, 2014, 1:27 p.m. UTC | #1 
On Tuesday, February 18, 2014 10:07:16 AM Fabio Estevam wrote:
> On Tue, Feb 18, 2014 at 9:57 AM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > On Tuesday, February 18, 2014 09:35:51 AM Fabio Estevam wrote:
> >> Currently the following warning is generated when building multi_v7_defconfig:
> >>
> >> $ make multi_v7_defconfig
> >> warning: (ARM_HIGHBANK_CPUFREQ) selects GENERIC_CPUFREQ_CPU0 which has unmet direct dependencies (ARCH_HAS_CPUFREQ && CPU_FREQ && HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL)
> >> # configuration written to .config
> >>
> >> Instead of forcing the selection of GENERIC_CPUFREQ_CPU0 and REGULATOR, change
> >> it to 'depends on' instead.
> >
> > OK
> >
> > Any objections here?
> 
> Thinking more about it I think the correct fix would be:
> 
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> @@ -84,9 +84,7 @@ config ARM_EXYNOS_CPU_FREQ_BOOST_SW
>  config ARM_HIGHBANK_CPUFREQ
>         tristate "Calxeda Highbank-based"
>         depends on ARCH_HIGHBANK
> -       select GENERIC_CPUFREQ_CPU0
> -       select PM_OPP
> -       select REGULATOR
> +       depends on GENERIC_CPUFREQ_CPU0
> 
>         default m
>         help
> 
> Because we have:
> 
> config GENERIC_CPUFREQ_CPU0
>     tristate "Generic CPU0 cpufreq driver"
>     depends on HAVE_CLK && REGULATOR && OF && THERMAL && CPU_THERMAL
>     select PM_OPP
>     help
>       This adds a generic cpufreq driver for CPU0 frequency management.
>       It supports both uniprocessor (UP) and symmetric multiprocessor (SMP)
>       systems which share clock and voltage across all CPUs.
> 
> If everyone agrees I would send a v3 with such fix.

Yes, please.

Thanks!
diff mbox

Patch

--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -84,9 +84,7 @@  config ARM_EXYNOS_CPU_FREQ_BOOST_SW
 config ARM_HIGHBANK_CPUFREQ
        tristate "Calxeda Highbank-based"
        depends on ARCH_HIGHBANK
-       select GENERIC_CPUFREQ_CPU0
-       select PM_OPP
-       select REGULATOR
+       depends on GENERIC_CPUFREQ_CPU0

        default m
        help