From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: [lm-sensors] Answer Epox - EPoX EP1308 sensor-chip
Date: Wed, 04 Oct 2006 14:43:44 +0000 [thread overview]
Message-ID: <20061004164344.b7653473.khali@linux-fr.org> (raw)
In-Reply-To: <450B14DB.2090505@sh.cvut.cz>
Hi Hans,
> Jean Delvare wrote:
> > Note that I am unlikely to accept undocumented fan control functions in
> > the mainline kernel anyway. I don't want to put the user's system at
> > risk, and I don't want to encourage manufacturers to keep their
> > documentation secret.
>
> Define undocumented, if undocumented means the chip can do it, but the
> motherboard manufacturer didn't implement this in its drivers for other
> OS and BIOS, then I agree with you. However here the settings can be
> controlled through the bios, thus I believe we should allow modifying
> them from lm-sensors too (to the limits the bios allows and no more).
> This ofcourse assumes we manage to find out exactly how these work, to
> the point where we can say this setting in the BIOs matches that and
> that byte in X increment units. If it stays as vague as this setting
> influences those bytes, then I fully agree with you.
Hehe, I agree expected some reaction from you ;)
If we can use the BIOS to find out additional chip features, and these
are straightforward enough for me to feel safe, why not. However Hans
Edgington's investigation didn't really sound as "things are easy to
understand" to me. Furthermore, I'm ready to take some (limited) risk
with extra monitoring functions, but fan speed control is something
different. If you get it wrong you can kill the hardware, so we can't
just implement it and wait for users to report. We've seen enough odd
things happen even with documented chips to imagine how bad it can get
without documentation.
Put in short, I have two objectives:
* Make it safe for the users.
* No increase to my maintenance workload.
If I feel both objectives are fulfilled, I won't object.
--
Jean Delvare
prev parent reply other threads:[~2006-10-04 14:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-15 21:02 [lm-sensors] Answer Epox - EPoX EP1308 sensor-chip Rudolf Marek
2006-09-28 10:06 ` Hans Edgington
2006-09-28 16:21 ` Hans de Goede
2006-09-28 21:20 ` Rudolf Marek
2006-09-28 21:39 ` Jean Delvare
2006-09-28 21:43 ` Jean Delvare
2006-09-28 23:42 ` Hans Edgington
2006-09-29 7:37 ` Jean Delvare
2006-09-29 7:45 ` Hans de Goede
2006-09-29 7:50 ` Jean Delvare
2006-09-29 8:03 ` Jean Delvare
2006-09-29 10:32 ` Hans Edgington
2006-09-29 11:27 ` Jean Delvare
2006-10-02 20:46 ` Hans Edgington
2006-10-04 12:08 ` Jean Delvare
2006-10-04 14:01 ` Hans de Goede
2006-10-04 14:43 ` Jean Delvare [this message]
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=20061004164344.b7653473.khali@linux-fr.org \
--to=khali@linux-fr.org \
--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.