All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] Adding critical/fault limits to hwmon sysfs API
Date: Wed, 23 Jun 2010 13:31:47 +0000	[thread overview]
Message-ID: <20100623133147.GA19143@ericsson.com> (raw)
In-Reply-To: <20100623144346.10acd898@hyperion.delvare>

On Wed, Jun 23, 2010 at 08:43:46AM -0400, Jean Delvare wrote:
> Hi Guenter,
> 
> On Sun, 20 Jun 2010 09:37:59 -0700, Guenter Roeck wrote:
> > the current hwmon sysfs API does not specify critical or fault limits for voltage
> > and current readings.
> > 
> > Many recent power controller/monitoring chips have support for such limits in addition
> > to alarm limits. Typical action, when a the critical or fault limit is reached,
> > may be a board reset or power shutdown, or to report the fault condition.
> > 
> > Examples for chips supporting critical/fault limits are SMM665 and variants as well
> > as many PMBus devices, such as MAX8688, MAX16064, LTC2978, and others.
> > 
> > I think it would make sense to add critical/fault limits to the hwmon sysfs API,
> > to be able to report those limits if supported by a chip.
> > 
> > Any thoughts on this ?
> 
> I agree it would be good to have standard names (and libsensors
> support) if these features are popular. It might be a little difficult
> to come up with the right attribute names though.
> 
> For temperatures, we have temp[1-*]_crit, for the critical limit on the
> high end. We don't have a name for the critical limit on the low end,
> because no chip ever implemented that. The name we chose doesn't offer
> much possibilities for a nice name while staying consistent. Maybe
> "lcrit" would be acceptable for the low end critical limit, and we keep
> "crit" for the high end critical limit?
> 
How about {curr|in|temp}[1-*]_[min_]crit ?

In other words, keep _crit for the upper limit and introduce min_crit for the lower limit.
This would be a bit better aligned with the existing _min while maintaining _crit for the 
upper limit.

Guenter

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

WARNING: multiple messages have this Message-ID (diff)
From: Guenter Roeck <guenter.roeck@ericsson.com>
To: Jean Delvare <khali@linux-fr.org>
Cc: "lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [lm-sensors] Adding critical/fault limits to hwmon sysfs API
Date: Wed, 23 Jun 2010 06:31:47 -0700	[thread overview]
Message-ID: <20100623133147.GA19143@ericsson.com> (raw)
In-Reply-To: <20100623144346.10acd898@hyperion.delvare>

On Wed, Jun 23, 2010 at 08:43:46AM -0400, Jean Delvare wrote:
> Hi Guenter,
> 
> On Sun, 20 Jun 2010 09:37:59 -0700, Guenter Roeck wrote:
> > the current hwmon sysfs API does not specify critical or fault limits for voltage
> > and current readings.
> > 
> > Many recent power controller/monitoring chips have support for such limits in addition
> > to alarm limits. Typical action, when a the critical or fault limit is reached,
> > may be a board reset or power shutdown, or to report the fault condition.
> > 
> > Examples for chips supporting critical/fault limits are SMM665 and variants as well
> > as many PMBus devices, such as MAX8688, MAX16064, LTC2978, and others.
> > 
> > I think it would make sense to add critical/fault limits to the hwmon sysfs API,
> > to be able to report those limits if supported by a chip.
> > 
> > Any thoughts on this ?
> 
> I agree it would be good to have standard names (and libsensors
> support) if these features are popular. It might be a little difficult
> to come up with the right attribute names though.
> 
> For temperatures, we have temp[1-*]_crit, for the critical limit on the
> high end. We don't have a name for the critical limit on the low end,
> because no chip ever implemented that. The name we chose doesn't offer
> much possibilities for a nice name while staying consistent. Maybe
> "lcrit" would be acceptable for the low end critical limit, and we keep
> "crit" for the high end critical limit?
> 
How about {curr|in|temp}[1-*]_[min_]crit ?

In other words, keep _crit for the upper limit and introduce min_crit for the lower limit.
This would be a bit better aligned with the existing _min while maintaining _crit for the 
upper limit.

Guenter

  reply	other threads:[~2010-06-23 13:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-20 16:37 [lm-sensors] Adding critical/fault limits to hwmon sysfs API Guenter Roeck
2010-06-20 16:37 ` Guenter Roeck
2010-06-23 12:43 ` [lm-sensors] " Jean Delvare
2010-06-23 12:43   ` Jean Delvare
2010-06-23 13:31   ` Guenter Roeck [this message]
2010-06-23 13:31     ` Guenter Roeck
2010-06-23 14:29     ` Jean Delvare
2010-06-23 14:29       ` Jean Delvare
2010-06-23 15:03       ` Guenter Roeck
2010-06-23 15:03         ` Guenter Roeck
2010-06-23 16:34         ` Jean Delvare
2010-06-23 16:34           ` Jean Delvare
2010-06-23 17:21           ` Guenter Roeck
2010-06-23 17:21             ` Guenter Roeck
2010-06-24  0:09   ` Mark Brown
2010-06-24  0:09     ` Mark Brown
2010-06-24  6:34     ` Jean Delvare
2010-06-24  6:34       ` Jean Delvare

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=20100623133147.GA19143@ericsson.com \
    --to=guenter.roeck@ericsson.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    /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.