From: Guenter Roeck <guenter.roeck@ericsson.com>
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] powerX_alarm sysfs attribute
Date: Thu, 09 Dec 2010 16:58:58 +0000 [thread overview]
Message-ID: <20101209165858.GA521@ericsson.com> (raw)
Hi all,
I am looking through libsensors and the hwmon sysfs ABI to identify and fix
inconsistencies.
One problem I noticed is powerX_alarm, which is defined as "system is drawing
more power than the cap allows".
powerX_cap is defined as " ... The *_cap files only appear if the cap is known
to be enforced by hardware".
Now there are conditions where power limits are defined and supported,
but the hardware does not enforce it. Similar, there are devices reporting power
alarms not associated with cap enforcement. Examples are ltc4215 and PMBus devices.
powerX_alarm is supported by the ltc4215 driver, but there is no _cap attribute,
and the alarm is not associated with a maximum, thus a reported alarm doesn't
really reflect the ABI.
I see a number of options:
1) Introduce powerX_max as unenforced "max" attribute, in addition to powerX_cap.
1a) Introduce powerX_cap_alarm to reflect alarms associated with powerX_cap,
introduce powerX_max_alarm, and redefine the semantics of powerX_alarm
to include all possible alarms
1b) Redefine semantics of powerX_alarm to include all possible reasons for
power alarms.
2) Redefine the semantics of powerX_cap to include unenforced maximum power.
Redefine powerX_alarm to include all possible reasons for alarms.
My preferred solution would be 1) with 1b), though 2) would be fine for me as well.
Any thoughts / comments ?
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
next reply other threads:[~2010-12-09 16:58 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-09 16:58 Guenter Roeck [this message]
2010-12-09 21:26 ` [lm-sensors] powerX_alarm sysfs attribute Ira W. Snyder
2010-12-09 21:48 ` Guenter Roeck
2010-12-10 0:07 ` Ira W. Snyder
2010-12-10 14:36 ` Jean Delvare
2010-12-10 14:37 ` Jean Delvare
2010-12-10 15:12 ` Guenter Roeck
2010-12-10 15:15 ` Guenter Roeck
2010-12-10 16:00 ` Jean Delvare
2010-12-10 16:18 ` Guenter Roeck
2010-12-10 16:30 ` Jean Delvare
2010-12-10 16:56 ` Guenter Roeck
2010-12-10 19:07 ` Guenter Roeck
2010-12-12 17:10 ` Jean Delvare
2010-12-12 19:49 ` Guenter Roeck
2010-12-12 20:17 ` Jean Delvare
2010-12-12 21:04 ` Guenter Roeck
2010-12-12 21:20 ` Jean Delvare
2010-12-12 23:11 ` 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=20101209165858.GA521@ericsson.com \
--to=guenter.roeck@ericsson.com \
--cc=lm-sensors@vger.kernel.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.