From: khali@linux-fr.org (Jean Delvare)
To: lm-sensors@vger.kernel.org
Subject: fan speed for it87?? chips added
Date: Thu, 19 May 2005 06:24:19 +0000 [thread overview]
Message-ID: <20030924231030.5c45007e.khali@linux-fr.org> (raw)
In-Reply-To: <200309232035.29480.michael.hufer@freenet.de>
> > 2* Should we provide a init=0 parameter? I think yes. Should it be
> > the default? Not too sure. (But actually, some things *need* to be
> > initialized, while some others do not need to. Especially,
> > temperature and voltage limits belong to userspace, as it has
> > already been discussed). Greg, what's your policy in 2.6 (if you
> > have one)?
>
> I don't have one, yet. Haven't thought that much about it. Any good
> proposals for one?
So far, most of our drivers are reinitializing chipsets and setting
limits. Some drivers have the init=0 module parameter to prevent that.
But it has been discussed recently that init=0 should be the default, or
even that most of the initialization (limits) could go away from the
driver code since it belongs to userspace.
My position is that the driver should change as few things as possible.
Hardware monitoring chips are a sensible realm. Enabling or disabling an
interrupt line or the like can cause the hardware to react (fan to full
speed or even shutdown) and we have had many reports that this happened.
So I think that the chip drivers should, by default, consider that the
chip is well configured for the hardware/bios settings, and initialize
very few things. My drivers work that way (not for the limits yet, but
for the rest).
The problem, as far as Linux 2.6 is concerned, is that libsensors isn't
ready yet, so removing all limit settings may be kind of suicidal
action. Still the point needs to be discussed for later.
--
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/
next prev parent reply other threads:[~2005-05-19 6:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-05-19 6:24 fan speed for it87?? chips added Michael Hufer
2005-05-19 6:24 ` Michael Hufer
2005-05-19 6:24 ` Greg KH
2005-05-19 6:24 ` Michael Hufer
2005-05-19 6:24 ` Michael Hufer
2005-05-19 6:24 ` Michael Hufer
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare [this message]
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Greg KH
2005-05-19 6:24 ` Michael Hufer
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Greg KH
2005-05-19 6:24 ` Philip Pokorny
2005-05-19 6:24 ` Greg KH
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Jean Delvare
2005-05-19 6:24 ` Greg KH
2005-05-19 6:24 ` Mark Studebaker
2005-05-19 6:24 ` Mark Studebaker
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=20030924231030.5c45007e.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.