Message-ID: <52CBF1CF.2000603@ti.com>
Date:	Tue, 7 Jan 2014 08:23:43 -0400
From:	Eduardo Valentin <eduardo.valentin@...com>
To:	Jean Delvare <khali@...ux-fr.org>
CC:	Guenter Roeck <linux@...ck-us.net>,
	Randy Dunlap <rdunlap@...radead.org>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	<linux-next@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	Frodo Looijaard <frodol@....nl>, <lm-sensors@...sensors.org>,
	Zhang Rui <rui.zhang@...el.com>,
	Eduardo Valentin <eduardo.valentin@...com>,
	<linux-pm@...r.kernel.org>
Subject: Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies

On 07-01-2014 08:04, Jean Delvare wrote:
> Hi Guenter, Randy,
> 
> On Mon, 06 Jan 2014 18:26:34 -0800, Guenter Roeck wrote:
>> On 01/06/2014 05:09 PM, Randy Dunlap wrote:
>>> From: Randy Dunlap <rdunlap@...radead.org>
>>>
>>> Fix SENSORS_LM75 dependencies to eliminate build errors:
>>>
>>> drivers/built-in.o: In function `lm75_remove':
>>> lm75.c:(.text+0x12bd8c): undefined reference to `thermal_zone_of_sensor_unregister'
>>> drivers/built-in.o: In function `lm75_probe':
>>> lm75.c:(.text+0x12c123): undefined reference to `thermal_zone_of_sensor_register'
>>>
>>> Add depends on THERMAL_OF since that is what provides the
>>> register/unregister functions above.
>>>
>>> Add depends on THERMAL since THERMAL is a tristate (while THERMAL_OF
>>> is a bool) and SENSORS_LM75 (tristate) needs to be limited to modular
>>> builds when THERMAL=m.
>>>
>>> Signed-off-by: Randy Dunlap <rdunlap@...radead.org>
>>> ---
>>>   drivers/hwmon/Kconfig |    2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> --- linux-next-20140106.orig/drivers/hwmon/Kconfig
>>> +++ linux-next-20140106/drivers/hwmon/Kconfig
>>> @@ -650,6 +650,8 @@ config SENSORS_LM73
>>>   config SENSORS_LM75
>>>   	tristate "National Semiconductor LM75 and compatibles"
>>>   	depends on I2C
>>> +	depends on THERMAL
>>> +	depends on THERMAL_OF
>>>   	help
>>>   	  If you say yes here you get support for one common type of
>>>   	  temperature sensor chip, with models including:
>>>
>>>
>> NACK. The driver does not and must not depend on THERMAL.
> 
> Correct.
> 
>> This needs to be addressed
>> in the thermal code, for example with dummy declarations if THERMAL=m but
>> SENSORS_LM75=y. The functions are already declared as dummies if THERMAL_OF=n.
> 
> This won't fly I'm afraid, the number of hwmon drivers affected will
> grow in the future and you certainly don't want to have to change the
> generic thermal code every time a new driver is added/converted.

Agreed

> 
> I've looked at the problem this morning and I will admit I do not even
> understand what the problem is. In Randy's config, CONFIG_THERMAL_OF=y
> so both thermal_zone_of_sensor_unregister and
> thermal_zone_of_sensor_register are built-in. SENSORS_LM75=y so the
> calls to these functions are built-in too. I just can't see how this
> can be a problem at link time. Can anyone enlighten me?
> 


I believe the problem is more in the fact that THERMAL_OF is a bool, but
the way it is in thermal Kconfig, it will link to the thermal module, in
case CONFIG_THERMAL=m. Thus I am proposing the following,
which limits the user to have THERMAL_OF only as builtin and whenever
is selected, it will select THERMAL too. That is:


From b643aa260ed4f3514d1ca51b1ecbe4be7652a8d0 Mon Sep 17 00:00:00 2001
From: Eduardo Valentin <eduardo.valentin@...com>
Date: Tue, 7 Jan 2014 08:04:02 -0400
Subject: [PATCH 1/1] thermal: fix compilation issue on CONFIG_THERMAL_OF
 dependencies

Users of API provided by THERMAL_OF config may suffer when
CONFIG_THERMAL=y, causing linking issues, such as:

drivers/built-in.o: In function `lm75_remove':
lm75.c:(.text+0x12bd8c): undefined reference to
`thermal_zone_of_sensor_unregister'
drivers/built-in.o: In function `lm75_probe':
lm75.c:(.text+0x12c123): undefined reference to
`thermal_zone_of_sensor_register'

Therefore, this patch limits the compilation build to always
have THERMAL=y, whenever THERMAL_OF=y. In this way, whenever
the API user is built, if THERMAL_OF=y, the build shall have
the full thermal support, otherwise, the thermal API will provide
stubs.

Cc: Zhang Rui <rui.zhang@...el.com>
Cc: linux-pm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@...com>
---
 drivers/thermal/Kconfig | 29 ++++++++++++++++-------------
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 58f98bd..dc315e9 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -29,19 +29,6 @@ config THERMAL_HWMON
 	  Say 'Y' here if you want all thermal sensors to
 	  have hwmon sysfs interface too.

-config THERMAL_OF
-	bool
-	prompt "APIs to parse thermal data out of device tree"
-	depends on OF
-	default y
-	help
-	  This options provides helpers to add the support to
-	  read and parse thermal data definitions out of the
-	  device tree blob.
-
-	  Say 'Y' here if you need to build thermal infrastructure
-	  based on device tree.
-
 choice
 	prompt "Default Thermal governor"
 	default THERMAL_DEFAULT_GOV_STEP_WISE
@@ -235,3 +222,19 @@ source "drivers/thermal/samsung/Kconfig"
 endmenu

 endif
+
+menuconfig THERMAL_OF
+	bool
+	prompt "APIs to parse thermal data out of device tree"
+	depends on OF
+	select THERMAL
+	default y
+	help
+	  This options enables DT thermal API which adds support to
+	  read and parse thermal data definitions out of the
+	  device tree blob. This option is mostly used by embedded
+	  thermal drivers.
+
+	  Say 'Y' here if you need to build thermal infrastructure
+	  based on device tree.
+
-- 
1.8.2.1.342.gfa7285d

Randy, can you please confirm if this fix the issue for you?

-- 
You have got to be excited about what you are doing. (L. Lamport)

Eduardo Valentin


Download attachment "signature.asc" of type "application/pgp-signature" (296 bytes)

Powered by blists - more mailing lists