summaryrefslogtreecommitdiff
path: root/Documentation
diff options
context:
space:
mode:
authorJean Delvare <khali@linux-fr.org>2007-09-04 23:25:33 +0200
committerMark M. Hoffman <mhoffman@lightlink.com>2007-10-09 22:56:31 -0400
commit428a7039c5717695935b946af9413e59f68928a4 (patch)
treed59028911c185b076401929178f11d7f7e0c5c34 /Documentation
parent69f2f96d9c189070ed5e40ec186b755ef697288d (diff)
downloadlinux-3.10-428a7039c5717695935b946af9413e59f68928a4.tar.gz
linux-3.10-428a7039c5717695935b946af9413e59f68928a4.tar.bz2
linux-3.10-428a7039c5717695935b946af9413e59f68928a4.zip
hwmon: (lm78) Add individual alarm files
Add individual alarm files to the lm78 driver, these are needed by the next version of libsensors. Signed-off-by: Jean Delvare <khali@linux-fr.org> Acked-by: Hans de Goede <j.w.r.degoede@hhs.nl> Signed-off-by: Mark M. Hoffman <mhoffman@lightlink.com>
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/hwmon/lm7810
1 files changed, 0 insertions, 10 deletions
diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78
index fd5dc7a19f0..dfc318a60fd 100644
--- a/Documentation/hwmon/lm78
+++ b/Documentation/hwmon/lm78
@@ -56,16 +56,6 @@ should work with. This is hardcoded by the mainboard and/or processor itself.
It is a value in volts. When it is unconnected, you will often find the
value 3.50 V here.
-In addition to the alarms described above, there are a couple of additional
-ones. There is a BTI alarm, which gets triggered when an external chip has
-crossed its limits. Usually, this is connected to all LM75 chips; if at
-least one crosses its limits, this bit gets set. The CHAS alarm triggers
-if your computer case is open. The FIFO alarms should never trigger; it
-indicates an internal error. The SMI_IN alarm indicates some other chip
-has triggered an SMI interrupt. As we do not use SMI interrupts at all,
-this condition usually indicates there is a problem with some other
-device.
-
If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may
already have disappeared! Note that in the current implementation, all