All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eduardo Valentin <eduardo.valentin@ti.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	<linux-next@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	Frodo Looijaard <frodol@dds.nl>, <lm-sensors@lm-sensors.org>,
	Zhang Rui <rui.zhang@intel.com>,
	Eduardo Valentin <eduardo.valentin@ti.com>,
	<linux-pm@vger.kernel.org>
Subject: Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies
Date: Tue, 7 Jan 2014 08:23:43 -0400	[thread overview]
Message-ID: <52CBF1CF.2000603@ti.com> (raw)
In-Reply-To: <20140107130401.23bffcd2@endymion.delvare>

[-- Attachment #1: Type: text/plain, Size: 5362 bytes --]

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@infradead.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@infradead.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@ti.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@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Valentin <eduardo.valentin@ti.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Frodo Looijaard <frodol@dds.nl>,
	lm-sensors@lm-sensors.org, Zhang Rui <rui.zhang@intel.com>,
	Eduardo Valentin <eduardo.valentin@ti.com>,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies
Date: Tue, 7 Jan 2014 08:23:43 -0400	[thread overview]
Message-ID: <52CBF1CF.2000603@ti.com> (raw)
In-Reply-To: <20140107130401.23bffcd2@endymion.delvare>

[-- Attachment #1: Type: text/plain, Size: 5362 bytes --]

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@infradead.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@infradead.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@ti.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@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Eduardo Valentin <eduardo.valentin@ti.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: Guenter Roeck <linux@roeck-us.net>,
	Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Frodo Looijaard <frodol@dds.nl>,
	lm-sensors@lm-sensors.org, Zhang Rui <rui.zhang@intel.com>,
	Eduardo Valentin <eduardo.valentin@ti.com>,
	linux-pm@vger.kernel.org
Subject: Re: [lm-sensors] [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies
Date: Tue, 07 Jan 2014 12:23:43 +0000	[thread overview]
Message-ID: <52CBF1CF.2000603@ti.com> (raw)
In-Reply-To: <20140107130401.23bffcd2@endymion.delvare>


[-- Attachment #1.1: Type: text/plain, Size: 5362 bytes --]

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@infradead.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@infradead.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@ti.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@intel.com>
Cc: linux-pm@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.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


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 295 bytes --]

[-- Attachment #2: Type: text/plain, Size: 153 bytes --]

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

  reply	other threads:[~2014-01-07 12:26 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-06  9:40 linux-next: Tree for Jan 06 Stephen Rothwell
2014-01-06  9:40 ` Stephen Rothwell
2014-01-06 19:51 ` linux-next: Tree for Jan 06 (hwmon/lm75.c) Randy Dunlap
2014-01-06 19:51   ` [lm-sensors] " Randy Dunlap
2014-01-06 20:32   ` Guenter Roeck
2014-01-06 20:32     ` [lm-sensors] " Guenter Roeck
2014-01-07  1:09     ` [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies Randy Dunlap
2014-01-07  1:09       ` [lm-sensors] " Randy Dunlap
2014-01-07  2:26       ` Guenter Roeck
2014-01-07  2:26         ` [lm-sensors] " Guenter Roeck
2014-01-07 11:35         ` Eduardo Valentin
2014-01-07 11:35           ` [lm-sensors] " Eduardo Valentin
2014-01-07 11:35           ` Eduardo Valentin
2014-01-07 12:04         ` Jean Delvare
2014-01-07 12:04           ` [lm-sensors] " Jean Delvare
2014-01-07 12:23           ` Eduardo Valentin [this message]
2014-01-07 12:23             ` Eduardo Valentin
2014-01-07 12:23             ` Eduardo Valentin
2014-01-07 12:44             ` [PATCH 1/1] thermal: fix compilation issue on CONFIG_THERMAL_OF dependencies Eduardo Valentin
2014-01-07 12:44               ` Eduardo Valentin
2014-01-07 14:33               ` Guenter Roeck
2014-01-07 14:56                 ` Eduardo Valentin
2014-01-07 14:56                   ` Eduardo Valentin
2014-01-07 15:03                 ` Jean Delvare
2014-01-07 14:05             ` [PATCH] hwmon/sensors: fix SENSORS_LM75 dependencies Zhang, Rui
2014-01-07 14:05               ` [lm-sensors] " Zhang, Rui
2014-01-07 14:57               ` Eduardo Valentin
2014-01-07 14:57                 ` [lm-sensors] " Eduardo Valentin
2014-01-07 15:07                 ` Jean Delvare
2014-01-07 15:07                   ` [lm-sensors] " Jean Delvare
2014-01-07 15:28                   ` Eduardo Valentin
2014-01-07 15:28                     ` [lm-sensors] " Eduardo Valentin
2014-01-07 15:28                     ` Eduardo Valentin
2014-01-07 16:10                   ` Guenter Roeck
2014-01-07 16:10                     ` [lm-sensors] " Guenter Roeck
2014-01-07 14:21             ` Jean Delvare
2014-01-07 14:21               ` [lm-sensors] " Jean Delvare
2014-01-07 14:21               ` Jean Delvare
2014-01-07 16:33               ` Eduardo Valentin
2014-01-07 16:33                 ` [lm-sensors] " Eduardo Valentin
2014-01-07 16:33                 ` Eduardo Valentin
2014-01-08  1:50                 ` Guenter Roeck
2014-01-08  1:50                   ` [lm-sensors] " Guenter Roeck
2014-01-07 18:06               ` Randy Dunlap
2014-01-07 18:06                 ` [lm-sensors] " Randy Dunlap
2014-01-08  2:02               ` Zhang Rui
2014-01-08  2:02                 ` [lm-sensors] " Zhang Rui
2014-01-07 16:02           ` Guenter Roeck
2014-01-07 16:02             ` [lm-sensors] " Guenter Roeck
2014-01-07 11:33     ` linux-next: Tree for Jan 06 (hwmon/lm75.c) Eduardo Valentin
2014-01-07 11:33       ` [lm-sensors] " Eduardo Valentin
2014-01-07 11:33       ` Eduardo Valentin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52CBF1CF.2000603@ti.com \
    --to=eduardo.valentin@ti.com \
    --cc=frodol@dds.nl \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rdunlap@infradead.org \
    --cc=rui.zhang@intel.com \
    --cc=sfr@canb.auug.org.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.