public inbox for linux-acpi@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Hans de Goede <j.w.r.degoede@hhs.nl>
Cc: "Zhang, Rui" <rui.zhang@intel.com>,
	linux-acpi <linux-acpi@vger.kernel.org>,
	lm-sensors <lm-sensors@lm-sensors.org>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	Thomas Renninger <trenn@suse.de>,
	"Thomas, Sujith" <sujith.thomas@intel.com>,
	"Mark M. Hoffman" <mhoffman@lightlink.com>,
	Henrique de Moraes Holschuh <hmh@hmh.eng.br>,
	Len Brown <lenb@kernel.org>, Richard Hughes <hughsient@gmail.com>
Subject: Re: [PATCH 1/2] thermal: add hwmon sys I/F for thermal device
Date: Mon, 17 Mar 2008 13:37:32 +0100	[thread overview]
Message-ID: <20080317133732.05b79f4d@hyperion.delvare> (raw)
In-Reply-To: <47C3D04E.6090609@hhs.nl>

Hi Hans,

On Tue, 26 Feb 2008 09:39:42 +0100, Hans de Goede wrote:
> Zhang, Rui wrote:
> > Add hwmon sys I/F for the generic thermal device.
> > 
> 
> Great!
> 
> But I have several remarks:
> 1) Looking at the new code, you only add temp1_input, so I'm guessing that you
> are registering a seperate hwmon class entry per zone? Please don't do that, 
> please register one hwmon class entry, and add multiple temp#_input attr to it 
> (and the same for crit).

I am sorry that I did not notice when you suggested this. I disagree,
but now Rui's code is upstream so I guess it's too late to complain.
Still here are my reasons:

One of the great things about libsensors is that it gives unique names
to hardware monitoring devices, and for each device, each feature has a
unique name as well. This makes it possible to ignore or label a
specific feature in /etc/sensors.conf in a way that is stable over
reboot and addition of new hardware.

By going with a single virtual device for all thermal zones, you break
this model. Depending on which thermal zone drivers are loaded and in
which order they are loaded, there will be more or less temp* files in
the hwmon directory and you also can't predict their order. The
labelling issue could be solved by adding temp*_label files, but this
still prevents the user from overriding a label. And there's no way to
reliably ignore a specific thermal zone or to ask for information about
a specific thermal zone with the current model.

For this reason, I think it would be much better to have one hwmon
class device for each _type_ of thermal zone. For example, all ACPI
thermal zones would be listed as one hwmon class device. If we later
add support for another type of thermal zones, all thermal zones of
this type would be listed as one (different) hwmon class device. This
makes each specific thermal zone driver responsible for the stability
of the numbering of the various thermal zones of a given type. This
would also let us give names to the different thermal zone types (e.g.
"acpitz" for ACPI thermal zones) so that the users and supporters have
an idea who is providing these temperature values and limits.

-- 
Jean Delvare

  parent reply	other threads:[~2008-03-17 12:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-25 21:31 [PATCH 1/2] thermal: add hwmon sys I/F for thermal device Zhang, Rui
2008-02-26  8:39 ` Hans de Goede
2008-02-26 21:40   ` Zhang, Rui
2008-02-27  8:32     ` Hans de Goede
2008-03-17 12:37   ` Jean Delvare [this message]
2008-03-17 12:55     ` Hans de Goede
2008-03-17 13:48       ` Jean Delvare
2008-03-18  3:45         ` Zhang, Rui
2008-03-18 10:06           ` Jean Delvare
2008-03-20 14:58             ` Henrique de Moraes Holschuh
2008-03-18  5:12         ` Len Brown
2008-03-18  9:44           ` Jean Delvare
2008-03-18  3:11       ` Zhang, Rui
2008-03-18  1:59     ` Zhang, Rui
2008-03-18  9:25       ` Hans de Goede
2008-03-18  9:40       ` Jean Delvare
  -- strict thread matches above, loose matches on Subject: below --
2008-02-27  0:37 Zhang, Rui
2008-03-12  4:29 ` Len Brown
2008-03-13  5:09   ` Len Brown
2008-03-13  8:46     ` Zhang, Rui
2008-03-18  4:59       ` Len Brown
2008-03-13 10:59     ` Thomas Renninger
2008-03-13 23:09       ` Henrique de Moraes Holschuh
2008-03-14  9:03         ` Thomas Renninger

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=20080317133732.05b79f4d@hyperion.delvare \
    --to=khali@linux-fr.org \
    --cc=hmh@hmh.eng.br \
    --cc=hughsient@gmail.com \
    --cc=j.w.r.degoede@hhs.nl \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    --cc=mhoffman@lightlink.com \
    --cc=mjg59@srcf.ucam.org \
    --cc=rui.zhang@intel.com \
    --cc=sujith.thomas@intel.com \
    --cc=trenn@suse.de \
    /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