Commit 4fa43501 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6

* 'release' of git://lm-sensors.org/kernel/mhoffman/hwmon-2.6: (53 commits)
  hwmon: (vt8231) fix sparse warning
  hwmon: (sis5595) fix sparse warning
  hwmon: (w83627hf) don't assume bank 0
  hwmon: (w83627hf) Fix setting fan min right after driver load
  hwmon: (w83627hf) De-macro sysfs callback functions
  hwmon: Add new combined driver for FSC chips
  hwmon: (ibmpex) Release IPMI user if hwmon registration fails
  hwmon: (dme1737) Add sch311x support
  hwmon: (dme1737) group functions logically
  hwmon: (dme1737) cleanups
  hwmon: IBM power meter driver
  hwmon: (coretemp) Add support for Celeron 4xx
  hwmon: (lm87) Disable VID when it should be
  hwmon: (w83781d) Add individual alarm and beep files
  hwmon: VRM is not read from registers
  MAINTAINERS: update hwmon subsystem git trees
  hwmon: Fix the code examples in documentation
  hwmon: update sysfs interface document - error handling
  hwmon: (thmc50) Fix a debug message
  hwmon: (thmc50) Don't create temp3 if not enabled
  ...
parents 7441dd12 a022fef5
......@@ -4,7 +4,7 @@ Kernel driver coretemp
Supported chips:
* All Intel Core family
Prefix: 'coretemp'
CPUID: family 0x6, models 0xe, 0xf
CPUID: family 0x6, models 0xe, 0xf, 0x16
Datasheet: Intel 64 and IA-32 Architectures Software Developer's Manual
Volume 3A: System Programming Guide
......
......@@ -6,6 +6,10 @@ Supported chips:
Prefix: 'dme1737'
Addresses scanned: I2C 0x2c, 0x2d, 0x2e
Datasheet: Provided by SMSC upon request and under NDA
* SMSC SCH3112, SCH3114, SCH3116
Prefix: 'sch311x'
Addresses scanned: none, address read from Super-I/O config space
Datasheet: http://www.nuhorizons.com/FeaturedProducts/Volume1/SMSC/311x.pdf
Authors:
Juerg Haefliger <juergh@gmail.com>
......@@ -27,16 +31,25 @@ Description
-----------
This driver implements support for the hardware monitoring capabilities of the
SMSC DME1737 and Asus A8000 (which are the same) Super-I/O chips. This chip
features monitoring of 3 temp sensors temp[1-3] (2 remote diodes and 1
internal), 7 voltages in[0-6] (6 external and 1 internal) and 6 fan speeds
fan[1-6]. Additionally, the chip implements 5 PWM outputs pwm[1-3,5-6] for
controlling fan speeds both manually and automatically.
Fan[3-6] and pwm[3,5-6] are optional features and their availability is
dependent on the configuration of the chip. The driver will detect which
features are present during initialization and create the sysfs attributes
accordingly.
SMSC DME1737 and Asus A8000 (which are the same) and SMSC SCH311x Super-I/O
chips. These chips feature monitoring of 3 temp sensors temp[1-3] (2 remote
diodes and 1 internal), 7 voltages in[0-6] (6 external and 1 internal) and up
to 6 fan speeds fan[1-6]. Additionally, the chips implement up to 5 PWM
outputs pwm[1-3,5-6] for controlling fan speeds both manually and
automatically.
For the DME1737 and A8000, fan[1-2] and pwm[1-2] are always present. Fan[3-6]
and pwm[3,5-6] are optional features and their availability depends on the
configuration of the chip. The driver will detect which features are present
during initialization and create the sysfs attributes accordingly.
For the SCH311x, fan[1-3] and pwm[1-3] are always present and fan[4-6] and
pwm[5-6] don't exist.
The hardware monitoring features of the DME1737 and A8000 are only accessible
via SMBus, while the SCH311x only provides access via the ISA bus. The driver
will therefore register itself as an I2C client driver if it detects a DME1737
or A8000 and as a platform driver if it detects a SCH311x chip.
Voltage Monitoring
......
......@@ -6,6 +6,10 @@ Supported chips:
Prefix: 'f71805f'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71806F/FG
Prefix: 'f71872f'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71872F/FG
Prefix: 'f71872f'
Addresses scanned: none, address read from Super I/O config space
......@@ -38,6 +42,9 @@ The Fintek F71872F/FG Super I/O chip is almost the same, with two
additional internal voltages monitored (VSB and battery). It also features
6 VID inputs. The VID inputs are not yet supported by this driver.
The Fintek F71806F/FG Super-I/O chip is essentially the same as the
F71872F/FG, and is undistinguishable therefrom.
The driver assumes that no more than one chip is present, which seems
reasonable.
......
......@@ -90,7 +90,8 @@ upper VID bits share their pins with voltage inputs (in5 and in6) so you
can't have both on a given board.
The IT8716F, IT8718F and later IT8712F revisions have support for
2 additional fans. They are not yet supported by the driver.
2 additional fans. They are supported by the driver for the IT8716F and
IT8718F but not for the IT8712F
The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional
16-bit tachometer counters for fans 1 to 3. This is better (no more fan
......
......@@ -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
......
......@@ -7,7 +7,7 @@ Supported chips:
Addresses scanned: I2C 0x2c-0x2e
Datasheet: http://www.national.com/ds.cgi/LM/LM93.pdf
Author:
Authors:
Mark M. Hoffman <mhoffman@lightlink.com>
Ported to 2.6 by Eric J. Bowersox <ericb@aspsys.com>
Adapted to 2.6.20 by Carsten Emde <ce@osadl.org>
......@@ -16,7 +16,6 @@ Author:
Module Parameters
-----------------
(specific to LM93)
* init: integer
Set to non-zero to force some initializations (default is 0).
* disable_block: integer
......@@ -37,30 +36,13 @@ Module Parameters
I.e. this parameter controls the VID pin input thresholds; if your VID
inputs are not working, try changing this. The default value is "0".
(common among sensor drivers)
* force: short array (min = 1, max = 48)
List of adapter,address pairs to assume to be present. Autodetection
of the target device will still be attempted. Use one of the more
specific force directives below if this doesn't detect the device.
* force_lm93: short array (min = 1, max = 48)
List of adapter,address pairs which are unquestionably assumed to contain
a 'lm93' chip
* ignore: short array (min = 1, max = 48)
List of adapter,address pairs not to scan
* ignore_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples not to scan
* probe: short array (min = 1, max = 48)
List of adapter,address pairs to scan additionally
* probe_range: short array (min = 1, max = 48)
List of adapter,start-addr,end-addr triples to scan additionally
Hardware Description
--------------------
(from the datasheet)
The LM93, hardware monitor, has a two wire digital interface compatible with
The LM93 hardware monitor has a two wire digital interface compatible with
SMBus 2.0. Using an 8-bit ADC, the LM93 measures the temperature of two remote
diode connected transistors as well as its own die and 16 power supply
voltages. To set fan speed, the LM93 has two PWM outputs that are each
......@@ -69,18 +51,12 @@ table based. The LM93 includes a digital filter that can be invoked to smooth
temperature readings for better control of fan speed. The LM93 has four
tachometer inputs to measure fan speed. Limit and status registers for all
measured values are included. The LM93 builds upon the functionality of
previous motherboard management ASICs and uses some of the LM85 s features
previous motherboard management ASICs and uses some of the LM85's features
(i.e. smart tachometer mode). It also adds measurement and control support
for dynamic Vccp monitoring and PROCHOT. It is designed to monitor a dual
processor Xeon class motherboard with a minimum of external components.
Driver Description
------------------
This driver implements support for the National Semiconductor LM93.
User Interface
--------------
......@@ -101,7 +77,7 @@ These intervals can be found in the sysfs files prochot1_interval and
prochot2_interval. The values in these files specify the intervals for
#P1_PROCHOT and #P2_PROCHOT, respectively. Selecting a value not in this
list will cause the driver to use the next largest interval. The available
intervals are:
intervals are (in seconds):
#PROCHOT intervals: 0.73, 1.46, 2.9, 5.8, 11.7, 23.3, 46.6, 93.2, 186, 372
......@@ -111,12 +87,12 @@ assert #P2_PROCHOT, and vice-versa. This mode is enabled by writing a
non-zero integer to the sysfs file prochot_short.
The LM93 can also override the #PROCHOT pins by driving a PWM signal onto
one or both of them. When overridden, the signal has a period of 3.56 mS,
one or both of them. When overridden, the signal has a period of 3.56 ms,
a minimum pulse width of 5 clocks (at 22.5kHz => 6.25% duty cycle), and
a maximum pulse width of 80 clocks (at 22.5kHz => 99.88% duty cycle).
The sysfs files prochot1_override and prochot2_override contain boolean
intgers which enable or disable the override function for #P1_PROCHOT and
integers which enable or disable the override function for #P1_PROCHOT and
#P2_PROCHOT, respectively. The sysfs file prochot_override_duty_cycle
contains a value controlling the duty cycle for the PWM signal used when
the override function is enabled. This value ranges from 0 to 15, with 0
......@@ -166,7 +142,7 @@ frequency values are constrained by the hardware. Selecting a value which is
not available will cause the driver to use the next largest value. Also note
that this parameter has implications for the Smart Tach Mode (see above).
PWM Output Frequencies: 12, 36, 48, 60, 72, 84, 96, 22500 (h/w default)
PWM Output Frequencies (in Hz): 12, 36, 48, 60, 72, 84, 96, 22500 (default)
Automatic PWM:
......@@ -178,7 +154,7 @@ individual control sources to which the PWM output is bound.
The eight control sources are: temp1-temp4 (aka "zones" in the datasheet),
#PROCHOT 1 & 2, and #VRDHOT 1 & 2. The bindings are expressed as a bitmask
in the sysfs files pwm<n>_auto_channels, where a "1" enables the binding, and
a "0" disables it. The h/w default is 0x0f (all temperatures bound).
a "0" disables it. The h/w default is 0x0f (all temperatures bound).
0x01 - Temp 1
0x02 - Temp 2
......@@ -324,89 +300,3 @@ LM93 Unique sysfs Files
gpio input state of 8 GPIO pins; read-only
Sample Configuration File
-------------------------
Here is a sample LM93 chip config for sensors.conf:
---------- cut here ----------
chip "lm93-*"
# VOLTAGE INPUTS
# labels and scaling based on datasheet recommendations
label in1 "+12V1"
compute in1 @ * 12.945, @ / 12.945
set in1_min 12 * 0.90
set in1_max 12 * 1.10
label in2 "+12V2"
compute in2 @ * 12.945, @ / 12.945
set in2_min 12 * 0.90
set in2_max 12 * 1.10
label in3 "+12V3"
compute in3 @ * 12.945, @ / 12.945
set in3_min 12 * 0.90
set in3_max 12 * 1.10
label in4 "FSB_Vtt"
label in5 "3GIO"
label in6 "ICH_Core"
label in7 "Vccp1"
label in8 "Vccp2"
label in9 "+3.3V"
set in9_min 3.3 * 0.90
set in9_max 3.3 * 1.10
label in10 "+5V"
set in10_min 5.0 * 0.90
set in10_max 5.0 * 1.10
label in11 "SCSI_Core"
label in12 "Mem_Core"
label in13 "Mem_Vtt"
label in14 "Gbit_Core"
# Assuming R1/R2 = 4.1143, and 3.3V reference
# -12V = (4.1143 + 1) * (@ - 3.3) + 3.3
label in15 "-12V"
compute in15 @ * 5.1143 - 13.57719, (@ + 13.57719) / 5.1143
set in15_min -12 * 0.90
set in15_max -12 * 1.10
label in16 "+3.3VSB"
set in16_min 3.3 * 0.90
set in16_max 3.3 * 1.10
# TEMPERATURE INPUTS
label temp1 "CPU1"
label temp2 "CPU2"
label temp3 "LM93"
# TACHOMETER INPUTS
label fan1 "Fan1"
set fan1_min 3000
label fan2 "Fan2"
set fan2_min 3000
label fan3 "Fan3"
set fan3_min 3000
label fan4 "Fan4"
set fan4_min 3000
# PWM OUTPUTS
label pwm1 "CPU1"
label pwm2 "CPU2"
......@@ -67,6 +67,10 @@ between readings to be caught and alarmed. The exact definition of an
alarm (for example, whether a threshold must be met or must be exceeded
to cause an alarm) is chip-dependent.
When setting values of hwmon sysfs attributes, the string representation of
the desired value must be written, note that strings which are not a number
are interpreted as 0! For more on how written strings are interpreted see the
"sysfs attribute writes interpretation" section at the end of this file.
-------------------------------------------------------------------------
......@@ -78,8 +82,21 @@ RW read/write value
Read/write values may be read-only for some chips, depending on the
hardware implementation.
All entries are optional, and should only be created in a given driver
if the chip has the feature.
All entries (except name) are optional, and should only be created in a
given driver if the chip has the feature.
********
* Name *
********
name The chip name.
This should be a short, lowercase string, not containing
spaces nor dashes, representing the chip name. This is
the only mandatory attribute.
I2C devices get this attribute created automatically.
RO
************
* Voltages *
......@@ -104,18 +121,17 @@ in[0-*]_input Voltage input value.
by the chip driver, and must be done by the application.
However, some drivers (notably lm87 and via686a)
do scale, because of internal resistors built into a chip.
These drivers will output the actual voltage.
Typical usage:
in0_* CPU #1 voltage (not scaled)
in1_* CPU #2 voltage (not scaled)
in2_* 3.3V nominal (not scaled)
in3_* 5.0V nominal (scaled)
in4_* 12.0V nominal (scaled)
in5_* -12.0V nominal (scaled)
in6_* -5.0V nominal (scaled)
in7_* varies
in8_* varies
These drivers will output the actual voltage. Rule of
thumb: drivers should report the voltage values at the
"pins" of the chip.
in[0-*]_label Suggested voltage channel label.
Text string
Should only be created if the driver has hints about what
this voltage channel is being used for, and user-space
doesn't. In all other cases, the label is provided by
user-space.
RO
cpu[0-*]_vid CPU core reference voltage.
Unit: millivolt
......@@ -159,6 +175,13 @@ fan[1-*]_target
Only makes sense if the chip supports closed-loop fan speed
control based on the measured fan speed.
fan[1-*]_label Suggested fan channel label.
Text string
Should only be created if the driver has hints about what
this fan channel is being used for, and user-space doesn't.
In all other cases, the label is provided by user-space.
RO
Also see the Alarms section for status flags associated with fans.
......@@ -219,12 +242,12 @@ temp[1-*]_auto_point[1-*]_temp_hyst
****************
temp[1-*]_type Sensor type selection.
Integers 1 to 6 or thermistor Beta value (typically 3435)
Integers 1 to 6
RW
1: PII/Celeron Diode
2: 3904 transistor
3: thermal diode
4: thermistor (default/unknown Beta)
4: thermistor
5: AMD AMDSI
6: Intel PECI
Not all types are supported by all chips
......@@ -260,18 +283,19 @@ temp[1-*]_crit_hyst
from the critical value.
RW
temp[1-4]_offset
temp[1-*]_offset
Temperature offset which is added to the temperature reading
by the chip.
Unit: millidegree Celsius
Read/Write value.
If there are multiple temperature sensors, temp1_* is
generally the sensor inside the chip itself,
reported as "motherboard temperature". temp2_* to
temp4_* are generally sensors external to the chip
itself, for example the thermal diode inside the CPU or
a thermistor nearby.
temp[1-*]_label Suggested temperature channel label.
Text string
Should only be created if the driver has hints about what
this temperature channel is being used for, and user-space
doesn't. In all other cases, the label is provided by
user-space.
RO
Some chips measure temperature using external thermistors and an ADC, and
report the temperature measurement as a voltage. Converting this voltage
......@@ -393,14 +417,53 @@ beep_mask Bitmask for beep.
RW
*********
* Other *
*********
eeprom Raw EEPROM data in binary form.
RO
pec Enable or disable PEC (SMBus only)
0: disable
1: enable
RW
sysfs attribute writes interpretation
-------------------------------------
hwmon sysfs attributes always contain numbers, so the first thing to do is to
convert the input to a number, there are 2 ways todo this depending whether
the number can be negative or not:
unsigned long u = simple_strtoul(buf, NULL, 10);
long s = simple_strtol(buf, NULL, 10);
With buf being the buffer with the user input being passed by the kernel.
Notice that we do not use the second argument of strto[u]l, and thus cannot
tell when 0 is returned, if this was really 0 or is caused by invalid input.
This is done deliberately as checking this everywhere would add a lot of
code to the kernel.
Notice that it is important to always store the converted value in an
unsigned long or long, so that no wrap around can happen before any further
checking.
After the input string is converted to an (unsigned) long, the value should be
checked if its acceptable. Be careful with further conversions on the value
before checking it for validity, as these conversions could still cause a wrap
around before the check. For example do not multiply the result, and only
add/subtract if it has been divided before the add/subtract.
What to do if a value is found to be invalid, depends on the type of the
sysfs attribute that is being set. If it is a continuous setting like a
tempX_max or inX_max attribute, then the value should be clamped to its
limits using SENSORS_LIMIT(value, min_limit, max_limit). If it is not
continuous like for example a tempX_type, then when an invalid value is
written, -EINVAL should be returned.
Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees):
long v = simple_strtol(buf, NULL, 10) / 1000;
v = SENSORS_LIMIT(v, -128, 127);
/* write v to register */
Example2, fan divider setting, valid values 2, 4 and 8:
unsigned long v = simple_strtoul(buf, NULL, 10);
switch (v) {
case 2: v = 1; break;
case 4: v = 2; break;
case 8: v = 3; break;
default:
return -EINVAL;
}
/* write v to register */
......@@ -75,46 +75,64 @@ Voltage sensors (also known as IN sensors) report their values in millivolts.
An alarm is triggered if the voltage has crossed a programmable minimum
or maximum limit.
The bit ordering for the alarm "realtime status register" and the
"beep enable registers" are different.
in0 (VCORE) : alarms: 0x000001 beep_enable: 0x000001
in1 (VINR0) : alarms: 0x000002 beep_enable: 0x002000 <== mismatch
in2 (+3.3VIN): alarms: 0x000004 beep_enable: 0x000004
in3 (5VDD) : alarms: 0x000008 beep_enable: 0x000008
in4 (+12VIN) : alarms: 0x000100 beep_enable: 0x000100
in5 (-12VIN) : alarms: 0x000200 beep_enable: 0x000200
in6 (-5VIN) : alarms: 0x000400 beep_enable: 0x000400
in7 (VSB) : alarms: 0x080000 beep_enable: 0x010000 <== mismatch
in8 (VBAT) : alarms: 0x100000 beep_enable: 0x020000 <== mismatch
in9 (VINR1) : alarms: 0x004000 beep_enable: 0x004000
temp1 : alarms: 0x000010 beep_enable: 0x000010
temp2 : alarms: 0x000020 beep_enable: 0x000020
temp3 : alarms: 0x002000 beep_enable: 0x000002 <== mismatch
fan1 : alarms: 0x000040 beep_enable: 0x000040
fan2 : alarms: 0x000080 beep_enable: 0x000080
fan3 : alarms: 0x000800 beep_enable: 0x000800
fan4 : alarms: 0x200000 beep_enable: 0x200000
fan5 : alarms: 0x400000 beep_enable: 0x400000
tart1 : alarms: 0x010000 beep_enable: 0x040000 <== mismatch
tart2 : alarms: 0x020000 beep_enable: 0x080000 <== mismatch
tart3 : alarms: 0x040000 beep_enable: 0x100000 <== mismatch
case_open : alarms: 0x001000 beep_enable: 0x001000
user_enable : alarms: -------- beep_enable: 0x800000
*** NOTE: It is the responsibility of user-space code to handle the fact
that the beep enable and alarm bits are in different positions when using that
feature of the chip.
When an alarm goes off, you can be warned by a beeping signal through your
computer speaker. It is possible to enable all beeping globally, or only
the beeping for some alarms.
The driver only reads the chip values each 3 seconds; reading them more
often will do no harm, but will return 'old' values.
The w83791d has a global bit used to enable beeping from the speaker when an
alarm is triggered as well as a bitmask to enable or disable the beep for
specific alarms. You need both the global beep enable bit and the
corresponding beep bit to be on for a triggered alarm to sound a beep.
The sysfs interface to the gloabal enable is via the sysfs beep_enable file.
This file is used for both legacy and new code.
The sysfs interface to the beep bitmask has migrated from the original legacy
method of a single sysfs beep_mask file to a newer method using multiple
*_beep files as described in .../Documentation/hwmon/sysfs-interface.
A similar change has occured for the bitmap corresponding to the alarms. The
original legacy method used a single sysfs alarms file containing a bitmap
of triggered alarms. The newer method uses multiple sysfs *_alarm files
(again following the pattern described in sysfs-interface).
Since both methods read and write the underlying hardware, they can be used
interchangeably and changes in one will automatically be reflected by
the other. If you use the legacy bitmask method, your user-space code is
responsible for handling the fact that the alarms and beep_mask bitmaps
are not the same (see the table below).
NOTE: All new code should be written to use the newer sysfs-interface
specification as that avoids bitmap problems and is the preferred interface
going forward.
The driver reads the hardware chip values at most once every three seconds.
User mode code requesting values more often will receive cached values.
Alarms bitmap vs. beep_mask bitmask
------------------------------------
For legacy code using the alarms and beep_mask files:
in0 (VCORE) : alarms: 0x000001 beep_mask: 0x000001
in1 (VINR0) : alarms: 0x000002 beep_mask: 0x002000 <== mismatch
in2 (+3.3VIN): alarms: 0x000004 beep_mask: 0x000004
in3 (5VDD) : alarms: 0x000008 beep_mask: 0x000008
in4 (+12VIN) : alarms: 0x000100 beep_mask: 0x000100
in5 (-12VIN) : alarms: 0x000200 beep_mask: 0x000200
in6 (-5VIN) : alarms: 0x000400 beep_mask: 0x000400
in7 (VSB) : alarms: 0x080000 beep_mask: 0x010000 <== mismatch
in8 (VBAT) : alarms: 0x100000 beep_mask: 0x020000 <== mismatch
in9 (VINR1) : alarms: 0x004000 beep_mask: 0x004000
temp1 : alarms: 0x000010 beep_mask: 0x000010
temp2 : alarms: 0x000020 beep_mask: 0x000020
temp3 : alarms: 0x002000 beep_mask: 0x000002 <== mismatch
fan1 : alarms: 0x000040 beep_mask: 0x000040
fan2 : alarms: 0x000080 beep_mask: 0x000080
fan3 : alarms: 0x000800 beep_mask: 0x000800
fan4 : alarms: 0x200000 beep_mask: 0x200000
fan5 : alarms: 0x400000 beep_mask: 0x400000
tart1 : alarms: 0x010000 beep_mask: 0x040000 <== mismatch
tart2 : alarms: 0x020000 beep_mask: 0x080000 <== mismatch
tart3 : alarms: 0x040000 beep_mask: 0x100000 <== mismatch
case_open : alarms: 0x001000 beep_mask: 0x001000
global_enable: alarms: -------- beep_mask: 0x800000 (modified via beep_enable)
W83791D TODO:
---------------
Provide a patch for per-file alarms and beep enables as defined in the hwmon
documentation (Documentation/hwmon/sysfs-interface)
Provide a patch for smart-fan control (still need appropriate motherboard/fans)
......@@ -1660,7 +1660,8 @@ P: Mark M. Hoffman
M: mhoffman@lightlink.com
L: lm-sensors@lm-sensors.org
W: http://www.lm-sensors.org/
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git testing
T: git lm-sensors.org:/kernel/mhoffman/hwmon-2.6.git release
S: Maintained
HARDWARE RANDOM NUMBER GENERATOR CORE
......@@ -4177,7 +4178,7 @@ W83791D HARDWARE MONITORING DRIVER
P: Charles Spirakis
M: bezaur@gmail.com
L: lm-sensors@lm-sensors.org
S: Maintained
S: Odd Fixes
W83793 HARDWARE MONITORING DRIVER
P: Rudolf Marek
......
......@@ -30,7 +30,7 @@ config HWMON_VID
config SENSORS_ABITUGURU
tristate "Abit uGuru (rev 1 & 2)"
depends on EXPERIMENTAL
depends on X86 && EXPERIMENTAL
help
If you say yes here you get support for the sensor part of the first
and second revision of the Abit uGuru chip. The voltage and frequency
......@@ -45,7 +45,7 @@ config SENSORS_ABITUGURU
config SENSORS_ABITUGURU3
tristate "Abit uGuru (rev 3)"
depends on HWMON && EXPERIMENTAL
depends on X86 && EXPERIMENTAL
help
If you say yes here you get support for the sensor part of the
third revision of the Abit uGuru chip. Only reading the sensors
......@@ -133,6 +133,16 @@ config SENSORS_ADM9240
This driver can also be built as a module. If so, the module
will be called adm9240.
config SENSORS_ADT7470
tristate "Analog Devices ADT7470"
depends on I2C && EXPERIMENTAL
help
If you say yes here you get support for the Analog Devices
ADT7470 temperature monitoring chips.
This driver can also be built as a module. If so, the module
will be called adt7470.
config SENSORS_K8TEMP
tristate "AMD Athlon64/FX or Opteron temperature sensor"
depends on X86 && PCI && EXPERIMENTAL
......@@ -172,7 +182,7 @@ config SENSORS_AMS_I2C
config SENSORS_ASB100
tristate "Asus ASB100 Bach"
depends on I2C && EXPERIMENTAL
depends on <