regulator: max8973: add THERMAL_OF dependency

Commit Message

Arnd Bergmann Jan. 8, 2016, 8:06 p.m. UTC

From 9f5ddfc667eb45dc2c5459e5acc5de45572456cd Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <[e-mail]>
Date: Fri, 8 Jan 2016 20:59:29 +0100
Subject: [PATCH] regulator: max8973: add THERMAL_OF dependency

The max8973 regulator driver has gained thermal support, but it
now fails to link when the driver is built-in and CONFIG_THERMAL=m:

drivers/built-in.o: In function `max8973_remove':
console.c:(.text+0x94ac4): undefined reference to `thermal_zone_of_sensor_unregister'
drivers/built-in.o: In function `max8973_probe':
console.c:(.text+0x95710): undefined reference to `thermal_zone_of_sensor_register'

This adds a dependency "depends on THERMAL || !THERMAL_OF" to ensure
that the driver cannot be built-in when THERMAL=m but is forced to
be a module as well, unless THERMAL_OF is disabled.

Signed-off-by: Arnd Bergmann <[e-mail]>
Fixes: 1b7a4c6a9eea ("regulator: max8973: add support for junction thermal warning")
---
I've run into the same problem a couple of times now, with every driver
that calls thermal_zone_of_sensor_register(). I think we need a better
solution in general, but this fixes the immediate build error for now.

Maybe we should replace the "#ifdef CONFIG_THERMAL_OF" with "#if
IS_REACHABLE(CONFIG_THERMAL) && IS_ENABLED(CONFIG_THERMAL_OF)"?
The disadvantage of that is that the thermal management would be
silently disabled rather than cause a link error, and that may also
not be desired.


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

Comments

Mark Brown Jan. 11, 2016, 4:47 p.m. UTC | #1

On Fri, Jan 08, 2016 at 09:06:43PM +0100, Arnd Bergmann wrote:

> I've run into the same problem a couple of times now, with every driver
> that calls thermal_zone_of_sensor_register(). I think we need a better
> solution in general, but this fixes the immediate build error for now.

Yes, this doesn't feel very clever especially in this use case where
we're mostly providing data into the thermal framework and not really
relying on it for anything.

> Maybe we should replace the "#ifdef CONFIG_THERMAL_OF" with "#if
> IS_REACHABLE(CONFIG_THERMAL) && IS_ENABLED(CONFIG_THERMAL_OF)"?
> The disadvantage of that is that the thermal management would be
> silently disabled rather than cause a link error, and that may also
> not be desired.

Perhaps we should ensure that at least some glue code is bool rather
than modular?  That's got downsides too, it increases the amount of code
that gets built into the kernel but perhaps that's an acceptable
tradeoff here.

Patch

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 8155e80dd3f8..7df9da82f592 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -383,6 +383,7 @@  config REGULATOR_MAX8952
 config REGULATOR_MAX8973
 	tristate "Maxim MAX8973 voltage regulator "
 	depends on I2C
+	depends on THERMAL || !THERMAL_OF
 	select REGMAP_I2C
 	help
 	  The MAXIM MAX8973 high-efficiency. three phase, DC-DC step-down