linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "R, Durgadoss" <durgadoss.r@intel.com>
Cc: "Guenter Roeck (guenter.roeck@ericsson.com)"
	<guenter.roeck@ericsson.com>,
	"Jean Delvare (khali@linux-fr.org)" <khali@linux-fr.org>,
	"Zhang, Rui" <rui.zhang@intel.com>,
	"lenb@kernel.org" <lenb@kernel.org>,
	"lm-sensors (lm-sensors@lm-sensors.org)"
	<lm-sensors@lm-sensors.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>
Subject: Re: CONFIG_THERMAL_HWMON in thermal_sys.c
Date: Mon, 10 Sep 2012 22:30:14 -0700	[thread overview]
Message-ID: <20120911053014.GA558@roeck-us.net> (raw)
In-Reply-To: <4D68720C2E767A4AA6A8796D42C8EB591B6F8F@BGSMSX101.gar.corp.intel.com>

On Tue, Sep 11, 2012 at 05:07:29AM +0000, R, Durgadoss wrote:
> Hi Jean/Guenter,
> 
> In thermal_sys.c we have a CONFIG_THERMAL_HWMON.
> If enabled, this creates sysfs nodes for thermal zones inside
> hwmon. Do we need this functionality inside thermal_sys.c ?
> Or is it Ok to remove this ?
> 
> I wanted to know your opinion before submitting a patch.
> 
Hi Durga,

question is really what would replace it. From the plumbers conference,
I understand the idea was that drivers would have to register to both hwmon
and the thermal subsystem. Is that going to happen ?

Second question is why you want to remove it in the first place. It only
matters for drivers which _do_ register with both hwmon and thermal - in
other words, none today. This case could be handled with a new thermal API,
which would specifically exclude hwmon registration.

My concern at this point with the thermal plans is that you might end up
duplicating a bunch of temperature sensor drivers in the thermal subsystem.
And if drivers are to support both subsystems, you would end up duplicating
a lot of common code in drivers which support both the thermal subsystem
and hwmon.

I personally don't think that is a good idea, and would prefer a more unified
approach where it would be possible to register a hwmon temperature sensor driver
with the thermal subsystem. Since that would be quite limited in scope, it might
not be too difficult to define an API for it which should both simplify hwmon
temperature sensor drivers and provide an interface to the thermal subsystem.

Thanks,
Guenter

  reply	other threads:[~2012-09-11  5:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11  5:07 CONFIG_THERMAL_HWMON in thermal_sys.c R, Durgadoss
2012-09-11  5:30 ` Guenter Roeck [this message]
2012-09-11  8:40   ` R, Durgadoss
2012-09-11  7:12 ` Jean Delvare
2012-09-11  8:55   ` R, Durgadoss
2012-09-11  9:03     ` Jean Delvare
2012-09-11  9:24       ` R, Durgadoss
2012-09-11  9:49         ` Jean Delvare
2012-09-11 13:45           ` Guenter Roeck
2012-09-11 14:05             ` Jean Delvare
2012-09-11 16:35               ` Guenter Roeck

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=20120911053014.GA558@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=durgadoss.r@intel.com \
    --cc=guenter.roeck@ericsson.com \
    --cc=khali@linux-fr.org \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=rui.zhang@intel.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).