All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <j.w.r.degoede@hhs.nl>
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Proposal /sys/bus/class/hwmon/hwmon#/device/foo#_label
Date: Sun, 08 Apr 2007 13:51:02 +0000	[thread overview]
Message-ID: <4618F346.3000404@hhs.nl> (raw)

Hi all,

The abituguru3 driver, of which I've just submitted a second version for 
review, has a new feature / sysfs file, which I would like to discuss, before 
people think I'm trying to keep this new sysfs entry below the radar.

The abituguru3 has a register which contains a motherboard ID. The current 
driver uses this ID, to look up info about the motherboard in a somewhat lenght 
table in the driver. This is done this way because the uguru3 has 48 sensors, 
and the only way to know which one are actually connected and wether they are 
connected to voltage / temp / fan is by using this table. The added advantage 
of this is that since we know exactly on which motherboard the driver is 
running, additional stuff can be don. Like always correct values in mV / milli 
degress celcius / RPM at the sysfs level without libsensors needing todo any 
conversion. An other additional feature this enables, is telling userspace 
which voltage / temp / fan is actually being monitored. So the abituguru3 
driver has sysfs entries like:
/sys/class/hwmon/hwmon0/in0_label

Catting this file will result (depependend on motherboard) in for example:
CPU Core
being returned

I personally like this, as with proper userspace support this makes the end 
user experience pretty plug and play. so what do you think, good or bad?

Currently libsensors cannot handle this, but I don't think that is an argument 
either way.

Regards,

Hans

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

                 reply	other threads:[~2007-04-08 13:51 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=4618F346.3000404@hhs.nl \
    --to=j.w.r.degoede@hhs.nl \
    --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.