cpufreq: cpufreq-cpu0: fix CPU_THERMAL dependency
diff mbox

Message ID 9629532.nBvvttN1Sz@wuerfel
State Accepted, archived
Headers show

Commit Message

Arnd Bergmann June 13, 2014, 8:40 a.m. UTC
5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and
REGULATOR") was a little too quick in completely removing the dependency
on the THERMAL driver.

The problem is that while there are inline wrappers to turn the thermal
API calls into empty functions, those do not help if the cpu-thermal
driver is a loadable module and cpufreq-cpu0 is builtin.

Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu
code is built into the thermal module or not, we have to use a dependency
on the thermal driver itself. However, if CPU_THERMAL is disabled, we
don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL'
construct.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>


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

Viresh Kumar June 13, 2014, 9:23 a.m. UTC | #1
On 13 June 2014 14:10, Arnd Bergmann <arnd@arndb.de> wrote:
> 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and
> REGULATOR") was a little too quick in completely removing the dependency
> on the THERMAL driver.

Sigh

> The problem is that while there are inline wrappers to turn the thermal
> API calls into empty functions, those do not help if the cpu-thermal
> driver is a loadable module and cpufreq-cpu0 is builtin.
>
> Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu
> code is built into the thermal module or not, we have to use a dependency
> on the thermal driver itself. However, if CPU_THERMAL is disabled, we
> don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL'
> construct.

Yeah, it took me few minutes to make sure its perfectly fine :)

> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
> index e473d65..ffe350f 100644
> --- a/drivers/cpufreq/Kconfig
> +++ b/drivers/cpufreq/Kconfig
> @@ -186,6 +186,8 @@ config CPU_FREQ_GOV_CONSERVATIVE
>  config GENERIC_CPUFREQ_CPU0
>         tristate "Generic CPU0 cpufreq driver"
>         depends on HAVE_CLK && OF
> +       # if CPU_THERMAL is on and THERMAL=m, CPU0 cannot be =y:
> +       depends on !CPU_THERMAL || THERMAL
>         select PM_OPP
>         help
>           This adds a generic cpufreq driver for CPU0 frequency management.

Since that was a corner case which I couldn't think of, can I be forgiven
for my incomplete patch ? :)

Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
--
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
Viresh Kumar June 13, 2014, 9:26 a.m. UTC | #2
On 13 June 2014 14:53, Viresh Kumar <viresh.kumar@linaro.org> wrote:
> On 13 June 2014 14:10, Arnd Bergmann <arnd@arndb.de> wrote:
>> 5fbfbcd3e842d ("cpufreq: cpufreq-cpu0: remove dependency on THERMAL and
>> REGULATOR") was a little too quick in completely removing the dependency
>> on the THERMAL driver.
>
> Sigh
>
>> The problem is that while there are inline wrappers to turn the thermal
>> API calls into empty functions, those do not help if the cpu-thermal
>> driver is a loadable module and cpufreq-cpu0 is builtin.
>>
>> Since CONFIG_CPU_THERMAL is a bool option that decides whether the cpu
>> code is built into the thermal module or not, we have to use a dependency
>> on the thermal driver itself. However, if CPU_THERMAL is disabled, we
>> don't need the dependency, hence the strange '!CPU_THERMAL || THERMAL'
>> construct.
>
> Yeah, it took me few minutes to make sure its perfectly fine :)
>
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>>
>> diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
>> index e473d65..ffe350f 100644
>> --- a/drivers/cpufreq/Kconfig
>> +++ b/drivers/cpufreq/Kconfig
>> @@ -186,6 +186,8 @@ config CPU_FREQ_GOV_CONSERVATIVE
>>  config GENERIC_CPUFREQ_CPU0
>>         tristate "Generic CPU0 cpufreq driver"
>>         depends on HAVE_CLK && OF
>> +       # if CPU_THERMAL is on and THERMAL=m, CPU0 cannot be =y:
>> +       depends on !CPU_THERMAL || THERMAL
>>         select PM_OPP
>>         help
>>           This adds a generic cpufreq driver for CPU0 frequency management.
>
> Since that was a corner case which I couldn't think of, can I be forgiven
> for my incomplete patch ? :)
>
> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>

Wait, I have tested it as well :)

Acked-and-tested-by: Viresh Kumar <viresh.kumar@linaro.org>
--
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

Patch
diff mbox

diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index e473d65..ffe350f 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -186,6 +186,8 @@  config CPU_FREQ_GOV_CONSERVATIVE
 config GENERIC_CPUFREQ_CPU0
 	tristate "Generic CPU0 cpufreq driver"
 	depends on HAVE_CLK && OF
+	# if CPU_THERMAL is on and THERMAL=m, CPU0 cannot be =y:
+	depends on !CPU_THERMAL || THERMAL
 	select PM_OPP
 	help
 	  This adds a generic cpufreq driver for CPU0 frequency management.