| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID: <52CC15F0.6020209@ti.com>
Date: Tue, 7 Jan 2014 10:57:52 -0400
From: Eduardo Valentin <eduardo.valentin@...com>
To: "Zhang, Rui" <rui.zhang@...el.com>
CC: Eduardo Valentin <eduardo.valentin@...com>,
Jean Delvare <khali@...ux-fr.org>,
Guenter Roeck <linux@...ck-us.net>,
Randy Dunlap <rdunlap@...radead.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-next@...r.kernel.org" <linux-next@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Frodo Looijaard <frodol@....nl>,
"lm-sensors@...sensors.org" <lm-sensors@...sensors.org>,
"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>
Subject: Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies
On 07-01-2014 10:05, Zhang, Rui wrote:
>
>
>> -----Original Message-----
>> From: Eduardo Valentin [mailto:eduardo.valentin@...com]
>> Sent: Tuesday, January 07, 2014 8:24 PM
>> To: Jean Delvare
>> Cc: Guenter Roeck; Randy Dunlap; Stephen Rothwell; linux-
>> next@...r.kernel.org; linux-kernel@...r.kernel.org; Frodo Looijaard;
>> lm-sensors@...sensors.org; Zhang, Rui; Eduardo Valentin; linux-
>> pm@...r.kernel.org
>> Subject: Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies
>> Importance: High
>>
>> 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?
>>
> The patch looks good to me, will apply it after it has been verified to fix the problem.
> BTW, I've been thinking of make CONFIG_THERMAL a bool since long time ago, the only thing that blocks me is that Thermal subsystem needs to register a hwmon device for each thermal zone and CONFIG_HWMON is a tristate.
>
I agree with the move of having CONFIG_THERMAL as bool. Unless you have
use cases where users are dynamically loading and unloading thermal per
user demand, which I doubt.
> Thanks,
> rui
>> --
>> You have got to be excited about what you are doing. (L. Lamport)
>>
>> Eduardo Valentin
>
>
>
--
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