code:
.. SPDX-License-Identifier: GPL-2.0

Kernel driver drivetemp
=======================

References
----------

ANS T13/1699-D
Information technology - AT Attachment 8 - ATA/ATAPI Command Set (ATA8-ACS)

ANS Project T10/BSR INCITS 513
Information technology - SCSI Primary Commands - 4 (SPC-4)

ANS Project INCITS 557
Information technology - SCSI / ATA Translation - 5 (SAT-5)

Description
-----------

This driver supports reporting the temperature of disk and solid state
drives with temperature sensors.

If supported, it uses the ATA SCT Command Transport feature to read
the current drive temperature and, if available, temperature limits
as well as historic minimum and maximum temperatures. If SCT Command
Transport is not supported, the driver uses SMART attributes to read
the drive temperature.

Usage Note
----------

Reading the drive temperature may reset the spin down timer on some drives.
This has been observed with WD120EFAX drives, but may be seen with other
drives as well. The same behavior is observed if the 'hdtemp' or 'smartd'
tools are used to access the drive.
With the WD120EFAX drive, reading the drive temperature using the drivetemp
driver is still possible _after_ it transitioned to standby mode, and
reading the drive temperature in this mode will not cause the drive to
change its mode (meaning the drive will not spin up). It is unknown if other
drives experience similar behavior.

A known workaround for WD120EFAX drives is to read the drive temperature at
intervals larger than twice the spin-down time. Otherwise affected drives
will never spin down.

Sysfs entries
-------------

Only the temp1_input attribute is always available. Other attributes are
available only if reported by the drive. All temperatures are reported in
milli-degrees Celsius.

=======================	=====================================================
temp1_input		Current drive temperature
temp1_lcrit		Minimum temperature limit. Operating the device below
			this temperature may cause physical damage to the
			device.
temp1_min		Minimum recommended continuous operating limit
temp1_max		Maximum recommended continuous operating temperature
temp1_crit		Maximum temperature limit. Operating the device above
			this temperature may cause physical damage to the
			device.
temp1_lowest		Minimum temperature seen this power cycle
temp1_highest		Maximum temperature seen this power cycle
=======================	=====================================================


code:
Kernel driver ds1621
====================

Supported chips:

  * Dallas Semiconductor / Maxim Integrated DS1621

    Prefix: 'ds1621'

    Addresses scanned: none

    Datasheet: Publicly available from www.maximintegrated.com

  * Dallas Semiconductor DS1625

    Prefix: 'ds1625'

    Addresses scanned: none

    Datasheet: Publicly available from www.datasheetarchive.com

  * Maxim Integrated DS1631

    Prefix: 'ds1631'

    Addresses scanned: none

    Datasheet: Publicly available from www.maximintegrated.com

  * Maxim Integrated DS1721

    Prefix: 'ds1721'

    Addresses scanned: none

    Datasheet: Publicly available from www.maximintegrated.com

  * Maxim Integrated DS1731

    Prefix: 'ds1731'

    Addresses scanned: none

    Datasheet: Publicly available from www.maximintegrated.com

Authors:
      - Christian W. Zuckschwerdt <zany@triq.net>
      - valuable contributions by Jan M. Sendler <sendler@sendler.de>
      - ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net>
	with the help of Jean Delvare <jdelvare@suse.de>

Module Parameters
------------------

* polarity int
  Output's polarity:

  * 0 = active high,
  * 1 = active low

Description
-----------

The DS1621 is a (one instance) digital thermometer and thermostat. It has
both high and low temperature limits which can be user defined (i.e.
programmed into non-volatile on-chip registers). Temperature range is -55
degree Celsius to +125 in 0.5 increments. You may convert this into a
Fahrenheit range of -67 to +257 degrees with 0.9 steps. If polarity
parameter is not provided, original value is used.

As for the thermostat, behavior can also be programmed using the polarity
toggle. On the one hand ("heater"), the thermostat output of the chip,
Tout, will trigger when the low limit temperature is met or underrun and
stays high until the high limit is met or exceeded. On the other hand
("cooler"), vice versa. That way "heater" equals "active low", whereas
"conditioner" equals "active high". Please note that the DS1621 data sheet
is somewhat misleading in this point since setting the polarity bit does
not simply invert Tout.

A second thing is that, during extensive testing, Tout showed a tolerance
of up to +/- 0.5 degrees even when compared against precise temperature
readings. Be sure to have a high vs. low temperature limit gap of al least
1.0 degree Celsius to avoid Tout "bouncing", though!

The alarm bits are set when the high or low limits are met or exceeded and
are reset by the module as soon as the respective temperature ranges are
left.

The alarm registers are in no way suitable to find out about the actual
status of Tout. They will only tell you about its history, whether or not
any of the limits have ever been met or exceeded since last power-up or
reset. Be aware: When testing, it showed that the status of Tout can change
with neither of the alarms set.

Since there is no version or vendor identification register, there is
no unique identification for these devices. Therefore, explicit device
instantiation is required for correct device identification and functionality
(one device per address in this address range: 0x48..0x4f).

The DS1625 is pin compatible and functionally equivalent with the DS1621,
but the DS1621 is meant to replace it. The DS1631, DS1721, and DS1731 are
also pin compatible with the DS1621 and provide multi-resolution support.

Additionally, the DS1721 data sheet says the temperature flags (THF and TLF)
are used internally, however, these flags do get set and cleared as the actual
temperature crosses the min or max settings (which by default are set to 75
and 80 degrees respectively).

Temperature Conversion
----------------------

- DS1621 - 750ms (older devices may take up to 1000ms)
- DS1625 - 500ms
- DS1631 - 93ms..750ms for 9..12 bits resolution, respectively.
- DS1721 - 93ms..750ms for 9..12 bits resolution, respectively.
- DS1731 - 93ms..750ms for 9..12 bits resolution, respectively.

Note:
On the DS1621, internal access to non-volatile registers may last for 10ms
or less (unverified on the other devices).

Temperature Accuracy
--------------------

- DS1621: +/- 0.5 degree Celsius (from 0 to +70 degrees)
- DS1625: +/- 0.5 degree Celsius (from 0 to +70 degrees)
- DS1631: +/- 0.5 degree Celsius (from 0 to +70 degrees)
- DS1721: +/- 1.0 degree Celsius (from -10 to +85 degrees)
- DS1731: +/- 1.0 degree Celsius (from -10 to +85 degrees)

.. Note::

   Please refer to the device datasheets for accuracy at other temperatures.

Temperature Resolution:
-----------------------
As mentioned above, the DS1631, DS1721, and DS1731 provide multi-resolution
support, which is achieved via the R0 and R1 config register bits, where:

R0..R1
------

== ==  ===============================
R0 R1
== ==  ===============================
 0  0  9 bits, 0.5 degrees Celsius
 1  0  10 bits, 0.25 degrees Celsius
 0  1  11 bits, 0.125 degrees Celsius
 1  1  12 bits, 0.0625 degrees Celsius
== ==  ===============================

.. Note::

   At initial device power-on, the default resolution is set to 12-bits.

The resolution mode for the DS1631, DS1721, or DS1731 can be changed from
userspace, via the device 'update_interval' sysfs attribute. This attribute
will normalize the range of input values to the device maximum resolution
values defined in the datasheet as follows:

============= ================== ===============
Resolution    Conversion Time    Input Range
 (C/LSB)       (msec)             (msec)
============= ================== ===============
0.5             93.75              0....94
0.25            187.5              95...187
0.125           375                188..375
0.0625          750                376..infinity
============= ================== ===============

The following examples show how the 'update_interval' attribute can be
used to change the conversion time::

  $ cat update_interval
  750
  $ cat temp1_input
  22062
  $
  $ echo 300 > update_interval
  $ cat update_interval
  375
  $ cat temp1_input
  22125
  $
  $ echo 150 > update_interval
  $ cat update_interval
  188
  $ cat temp1_input
  22250
  $
  $ echo 1 > update_interval
  $ cat update_interval
  94
  $ cat temp1_input
  22000
  $
  $ echo 1000 > update_interval
  $ cat update_interval
  750
  $ cat temp1_input
  22062
  $

As shown, the ds1621 driver automatically adjusts the 'update_interval'
user input, via a step function. Reading back the 'update_interval' value
after a write operation provides the conversion time used by the device.

Mathematically, the resolution can be derived from the conversion time
via the following function:

   g(x) = 0.5 * [minimum_conversion_time/x]

where:

 - 'x' = the output from 'update_interval'
 - 'g(x)' = the resolution in degrees C per LSB.
 - 93.75ms = minimum conversion time

repo_name: angery/linux


code:
Kernel driver ds620
===================

Supported chips:

  * Dallas Semiconductor DS620

    Prefix: 'ds620'

    Datasheet: Publicly available at the Dallas Semiconductor website

	       http://www.dalsemi.com/

Authors:
	Roland Stigge <stigge@antcom.de>
	based on ds1621.c by
	Christian W. Zuckschwerdt <zany@triq.net>

Description
-----------

The DS620 is a (one instance) digital thermometer and thermostat. It has both
high and low temperature limits which can be user defined (i.e.  programmed
into non-volatile on-chip registers). Temperature range is -55 degree Celsius
to +125. Between 0 and 70 degree Celsius, accuracy is 0.5 Kelvin. The value
returned via sysfs displays post decimal positions.

The thermostat function works as follows: When configured via platform_data
(struct ds620_platform_data) .pomode == 0 (default), the thermostat output pin
PO is always low. If .pomode == 1, the thermostat is in PO_LOW mode. I.e., the
output pin PO becomes active when the temperature falls below temp1_min and
stays active until the temperature goes above temp1_max.

Likewise, with .pomode == 2, the thermostat is in PO_HIGH mode. I.e., the PO
output pin becomes active when the temperature goes above temp1_max and stays
active until the temperature falls below temp1_min.

The PO output pin of the DS620 operates active-low.


code:
Kernel driver emc1403
=====================

Supported chips:

  * SMSC / Microchip EMC1402, EMC1412

    Addresses scanned: I2C 0x18, 0x1c, 0x29, 0x4c, 0x4d, 0x5c

    Prefix: 'emc1402'

    Datasheets:

	- http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf
	- https://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf

  * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414

    Addresses scanned: I2C 0x18, 0x29, 0x4c, 0x4d

    Prefix: 'emc1403', 'emc1404'

    Datasheets:

	- http://ww1.microchip.com/downloads/en/DeviceDoc/1403_1404.pdf
	- http://ww1.microchip.com/downloads/en/DeviceDoc/1413_1414.pdf

  * SMSC / Microchip EMC1422

    Addresses scanned: I2C 0x4c

    Prefix: 'emc1422'

    Datasheet:

	- https://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf

  * SMSC / Microchip EMC1423, EMC1424

    Addresses scanned: I2C 0x4c

    Prefix: 'emc1423', 'emc1424'

    Datasheet:

	- https://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf

Author:
    Kalhan Trisal <kalhan.trisal@intel.com

Description
-----------

The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips
contain up to four temperature sensors. EMC14x2 support two sensors
(one internal, one external). EMC14x3 support three sensors (one internal,
two external), and EMC14x4 support four sensors (one internal, three
external).

The chips implement three limits for each sensor: low (tempX_min), high
(tempX_max) and critical (tempX_crit.) The chips also implement an
hysteresis mechanism which applies to all limits. The relative difference
is stored in a single register on the chip, which means that the relative
difference between the limit and its hysteresis is always the same for
all three limits.

This implementation detail implies the following:

* When setting a limit, its hysteresis will automatically follow, the
  difference staying unchanged. For example, if the old critical limit
  was 80 degrees C, and the hysteresis was 75 degrees C, and you change
  the critical limit to 90 degrees C, then the hysteresis will
  automatically change to 85 degrees C.
* The hysteresis values can't be set independently. We decided to make
  only temp1_crit_hyst writable, while all other hysteresis attributes
  are read-only. Setting temp1_crit_hyst writes the difference between
  temp1_crit_hyst and temp1_crit into the chip, and the same relative
  hysteresis applies automatically to all other limits.
* The limits should be set before the hysteresis.


code:
Kernel driver emc2103
======================

Supported chips:

  * SMSC EMC2103

    Addresses scanned: I2C 0x2e

    Prefix: 'emc2103'

    Datasheet: Not public

Authors:
	Steve Glendinning <steve.glendinning@smsc.com>

Description
-----------

The Standard Microsystems Corporation (SMSC) EMC2103 chips
contain up to 4 temperature sensors and a single fan controller.

Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. Fan
readings can be divided by a programmable divider (1, 2, 4 or 8) to give
the readings more range or accuracy. Not all RPM values can accurately be
represented, so some rounding is done. With a divider of 1, the lowest
representable value is 480 RPM.

This driver supports RPM based control, to use this a fan target
should be written to fan1_target and pwm1_enable should be set to 3.

The 2103-2 and 2103-4 variants have a third temperature sensor, which can
be connected to two anti-parallel diodes.  These values can be read
as temp3 and temp4.  If only one diode is attached to this channel, temp4
will show as "fault".  The module parameter "apd=0" can be used to suppress
this 4th channel when anti-parallel diodes are not fitted.


code:
.. SPDX-License-Identifier: GPL-2.0

Kernel driver emc2305
=====================

Supported chips:
   Microchip EMC2305, EMC2303, EMC2302, EMC2301

   Addresses scanned: I2C 0x27, 0x2c, 0x2d, 0x2e, 0x2f, 0x4c, 0x4d
   Prefixes: 'emc2305'

   Datasheet: Publicly available at the Microchip website :
      https://www.microchip.com/en-us/product/EMC2305

Description:
------------
This driver implements support for Microchip EMC2301/2/3/5 RPM-based PWM Fan Controller.
The EMC2305 Fan Controller supports up to 5 independently controlled PWM fan drives.
Fan rotation speeds are reported in RPM.
The driver supports the RPM-based PWM control to keep a fan at the desired speed.
The driver provides the possibility to have one common PWM interface for all FANs
or up to the maximum available or configured independent PWMs.

The driver provides the following sysfs interfaces in hwmon subsystem:

================= == ===================================================
fan[1-5]_fault    RO files for tachometers TACH1-TACH5 fault indication
fan[1-5]_input    RO files for tachometers TACH1-TACH5 input (in RPM)
pwm[1-5]          RW file for fan[1-5] target duty cycle (0..255)
================= == ===================================================

sysfs interfaces in thermal subsystem:

================= == ========================================================================
cur_state         RW file for the current cooling state of the cooling device (0..max_state)
max_state         RO file for the maximum cooling state of the cooling device
================= == ========================================================================


code:
Kernel driver emc6w201
======================

Supported chips:

  * SMSC EMC6W201

    Prefix: 'emc6w201'

    Addresses scanned: I2C 0x2c, 0x2d, 0x2e

    Datasheet: Not public

Author: Jean Delvare <jdelvare@suse.de>

Description
-----------

From the datasheet:

"The EMC6W201 is an environmental monitoring device with automatic fan
control capability and enhanced system acoustics for noise suppression.
This ACPI compliant device provides hardware monitoring for up to six
voltages (including its own VCC) and five external thermal sensors,
measures the speed of up to five fans, and controls the speed of
multiple DC fans using three Pulse Width Modulator (PWM) outputs. Note
that it is possible to control more than three fans by connecting two
fans to one PWM output. The EMC6W201 will be available in a 36-pin
QFN package."

The device is functionally close to the EMC6D100 series, but is
register-incompatible.

The driver currently only supports the monitoring of the voltages,
temperatures and fan speeds. Limits can be changed. Alarms are not
supported, and neither is fan speed control.

Known Systems With EMC6W201
---------------------------

The EMC6W201 is a rare device, only found on a few systems, made in
2005 and 2006. Known systems with this device:

* Dell Precision 670 workstation
* Gigabyte 2CEWH mainboard


code:
Kernel driver f71805f
=====================

Supported chips:

  * Fintek F71805F/FG

    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

    Datasheet: Available from the Fintek website

Author: Jean Delvare <jdelvare@suse.de>

Thanks to Denis Kieft from Barracuda Networks for the donation of a
test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and
for providing initial documentation.

Thanks to Kris Chen and Aaron Huang from Fintek for answering technical
questions and providing additional documentation.

Thanks to Chris Lin from Jetway for providing wiring schematics and
answering technical questions.

Description
-----------

The Fintek F71805F/FG Super I/O chip includes complete hardware monitoring
capabilities. It can monitor up to 9 voltages (counting its own power
source), 3 fans and 3 temperature sensors.

This chip also has fan controlling features, using either DC or PWM, in
three different modes (one manual, two automatic).

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.

Voltage Monitoring
------------------

Voltages are sampled by an 8-bit ADC with a LSB of 8 mV. The supported
range is thus from 0 to 2.040 V. Voltage values outside of this range
need external resistors. An exception is in0, which is used to monitor
the chip's own power source (+3.3V), and is divided internally by a
factor 2. For the F71872F/FG, in9 (VSB) and in10 (battery) are also
divided internally by a factor 2.

The two LSB of the voltage limit registers are not used (always 0), so
you can only set the limits in steps of 32 mV (before scaling).

The wirings and resistor values suggested by Fintek are as follow:

======= ======= =========== ==== ======= ============ ==============
in      pin                                           expected
	name    use           R1      R2     divider  raw val.
======= ======= =========== ==== ======= ============ ==============
in0     VCC     VCC3.3V     int.    int.        2.00    1.65 V
in1     VIN1    VTT1.2V      10K       -        1.00    1.20 V
in2     VIN2    VRAM        100K    100K        2.00   ~1.25 V [1]_
in3     VIN3    VCHIPSET     47K    100K        1.47    2.24 V [2]_
in4     VIN4    VCC5V       200K     47K        5.25    0.95 V
in5     VIN5    +12V        200K     20K       11.00    1.05 V
in6     VIN6    VCC1.5V      10K       -        1.00    1.50 V
in7     VIN7    VCORE        10K       -        1.00   ~1.40 V [1]_
in8     VIN8    VSB5V       200K     47K        1.00    0.95 V
in10    VSB     VSB3.3V     int.    int.        2.00    1.65 V [3]_
in9     VBAT    VBATTERY    int.    int.        2.00    1.50 V [3]_
======= ======= =========== ==== ======= ============ ==============

.. [1] Depends on your hardware setup.
.. [2] Obviously not correct, swapping R1 and R2 would make more sense.
.. [3] F71872F/FG only.

These values can be used as hints at best, as motherboard manufacturers
are free to use a completely different setup. As a matter of fact, the
Jetway K8M8MS uses a significantly different setup. You will have to
find out documentation about your own motherboard, and edit sensors.conf
accordingly.

Each voltage measured has associated low and high limits, each of which
triggers an alarm when crossed.

Fan Monitoring
--------------

Fan rotation speeds are reported as 12-bit values from a gated clock
signal. Speeds down to 366 RPM can be measured. There is no theoretical
high limit, but values over 6000 RPM seem to cause problem. The effective
resolution is much lower than you would expect, the step between different
register values being 10 rather than 1.

The chip assumes 2 pulse-per-revolution fans.

An alarm is triggered if the rotation speed drops below a programmable
limit or is too low to be measured.

Temperature Monitoring
----------------------

Temperatures are reported in degrees Celsius. Each temperature measured
has a high limit, those crossing triggers an alarm. There is an associated
hysteresis value, below which the temperature has to drop before the
alarm is cleared.

All temperature channels are external, there is no embedded temperature
sensor. Each channel can be used for connecting either a thermal diode
or a thermistor. The driver reports the currently selected mode, but
doesn't allow changing it. In theory, the BIOS should have configured
everything properly.

Fan Control
-----------

Both PWM (pulse-width modulation) and DC fan speed control methods are
supported. The right one to use depends on external circuitry on the
motherboard, so the driver assumes that the BIOS set the method
properly. The driver will report the method, but won't let you change
it.

When the PWM method is used, you can select the operating frequency,
from 187.5 kHz (default) to 31 Hz. The best frequency depends on the
fan model. As a rule of thumb, lower frequencies seem to give better
control, but may generate annoying high-pitch noise. So a frequency just
above the audible range, such as 25 kHz, may be a good choice; if this
doesn't give you good linear control, try reducing it. Fintek recommends
not going below 1 kHz, as the fan tachometers get confused by lower
frequencies as well.

When the DC method is used, Fintek recommends not going below 5 V, which
corresponds to a pwm value of 106 for the driver. The driver doesn't
enforce this limit though.

Three different fan control modes are supported; the mode number is written
to the pwm<n>_enable file.

* 1: Manual mode
  You ask for a specific PWM duty cycle or DC voltage by writing to the
  pwm<n> file.

* 2: Temperature mode
  You define 3 temperature/fan speed trip points using the
  pwm<n>_auto_point<m>_temp and _fan files. These define a staircase
  relationship between temperature and fan speed with two additional points
  interpolated between the values that you define. When the temperature
  is below auto_point1_temp the fan is switched off.

* 3: Fan speed mode
  You ask for a specific fan speed by writing to the fan<n>_target file.

Both of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
fan2 and pwm3 to fan3. Temperature mode also requires that temp1 corresponds
to pwm1 and fan1, etc.


code:
Kernel driver f71882fg
======================

Supported chips:

  * Fintek F71808E

    Prefix: 'f71808e'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Not public

  * Fintek F71808A

    Prefix: 'f71808a'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Not public

  * Fintek F71858FG

    Prefix: 'f71858fg'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Available from the Fintek website

  * Fintek F71862FG and F71863FG

    Prefix: 'f71862fg'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Available from the Fintek website

  * Fintek F71869F and F71869E

    Prefix: 'f71869'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Available from the Fintek website

  * Fintek F71869A

    Prefix: 'f71869a'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Not public

  * Fintek F71882FG and F71883FG

    Prefix: 'f71882fg'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Available from the Fintek website

  * Fintek F71889FG

    Prefix: 'f71889fg'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Available from the Fintek website

  * Fintek F71889ED

    Prefix: 'f71889ed'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Should become available on the Fintek website soon

  * Fintek F71889A

    Prefix: 'f71889a'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Should become available on the Fintek website soon

  * Fintek F8000

    Prefix: 'f8000'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Not public

  * Fintek F81801U

    Prefix: 'f71889fg'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Not public

    Note:
	  This is the 64-pin variant of the F71889FG, they have the
	  same device ID and are fully compatible as far as hardware
	  monitoring is concerned.

  * Fintek F81865F

    Prefix: 'f81865f'

    Addresses scanned: none, address read from Super I/O config space

    Datasheet: Available from the Fintek website

Author: Hans de Goede <hdegoede@redhat.com>

Description
-----------

Fintek F718xx/F8000 Super I/O chips include complete hardware monitoring
capabilities. They can monitor up to 9 voltages, 4 fans and 3 temperature
sensors.

These chips also have fan controlling features, using either DC or PWM, in
three different modes (one manual, two automatic).

The driver assumes that no more than one chip is present, which seems
reasonable.

Monitoring
----------

The Voltage, Fan and Temperature Monitoring uses the standard sysfs
interface as documented in sysfs-interface, without any exceptions.

Fan Control
-----------

Both PWM (pulse-width modulation) and DC fan speed control methods are
supported. The right one to use depends on external circuitry on the
motherboard, so the driver assumes that the BIOS set the method
properly.

Note that the lowest numbered temperature zone trip point corresponds to
the border between the highest and one but highest temperature zones, and
vica versa. So the temperature zone trip points 1-4 (or 1-2) go from high temp
to low temp! This is how things are implemented in the IC, and the driver
mimics this.

There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
mode where the actual RPM of the fan (as measured) is controlled and the speed
gets specified as 0-100% of the fan#_full_speed file.

Since both modes work in a 0-100% (mapped to 0-255) scale, there isn't a
whole lot of a difference when modifying fan control settings. The only
important difference is that in RPM mode the 0-100% controls the fan speed
between 0-100% of fan#_full_speed. It is assumed that if the BIOS programs
RPM mode, it will also set fan#_full_speed properly, if it does not then
fan control will not work properly, unless you set a sane fan#_full_speed
value yourself.

Switching between these modes requires re-initializing a whole bunch of
registers, so the mode which the BIOS has set is kept. The mode is
printed when loading the driver.

Three different fan control modes are supported; the mode number is written
to the pwm#_enable file. Note that not all modes are supported on all
chips, and some modes may only be available in RPM / PWM mode.
Writing an unsupported mode will result in an invalid parameter error.

* 1: Manual mode
  You ask for a specific PWM duty cycle / DC voltage or a specific % of
  fan#_full_speed by writing to the pwm# file. This mode is only
  available on the F71858FG / F8000 if the fan channel is in RPM mode.

* 2: Normal auto mode
  You can define a number of temperature/fan speed trip points, which % the
  fan should run at at this temp and which temp a fan should follow using the
  standard sysfs interface. The number and type of trip points is chip
  depended, see which files are available in sysfs.
  Fan/PWM channel 3 of the F8000 is always in this mode!

* 3: Thermostat mode (Only available on the F8000 when in duty cycle mode)
  The fan speed is regulated to keep the temp the fan is mapped to between
  temp#_auto_point2_temp and temp#_auto_point3_temp.

All of the automatic modes require that pwm1 corresponds to fan1, pwm2 to
fan2 and pwm3 to fan3.


code:
Kernel driver fam15h_power
==========================

Supported chips:

* AMD Family 15h Processors

* AMD Family 16h Processors

  Prefix: 'fam15h_power'

  Addresses scanned: PCI space

  Datasheets:

  - BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
  - BIOS and Kernel Developer's Guide (BKDG) For AMD Family 16h Processors
  - AMD64 Architecture Programmer's Manual Volume 2: System Programming

Author: Andreas Herrmann <herrmann.der.user@googlemail.com>

Description
-----------

1) Processor TDP (Thermal design power)

Given a fixed frequency and voltage, the power consumption of a
processor varies based on the workload being executed. Derated power
is the power consumed when running a specific application. Thermal
design power (TDP) is an example of derated power.

This driver permits reading of registers providing power information
of AMD Family 15h and 16h processors via TDP algorithm.

For AMD Family 15h and 16h processors the following power values can
be calculated using different processor northbridge function
registers:

* BasePwrWatts:
    Specifies in watts the maximum amount of power
    consumed by the processor for NB and logic external to the core.

* ProcessorPwrWatts:
    Specifies in watts the maximum amount of power
    the processor can support.
* CurrPwrWatts:
    Specifies in watts the current amount of power being
    consumed by the processor.

This driver provides ProcessorPwrWatts and CurrPwrWatts:

* power1_crit (ProcessorPwrWatts)
* power1_input (CurrPwrWatts)

On multi-node processors the calculated value is for the entire
package and not for a single node. Thus the driver creates sysfs
attributes only for internal node0 of a multi-node processor.

2) Accumulated Power Mechanism

This driver also introduces an algorithm that should be used to
calculate the average power consumed by a processor during a
measurement interval Tm. The feature of accumulated power mechanism is
indicated by CPUID Fn8000_0007_EDX[12].

* Tsample:
	compute unit power accumulator sample period

* Tref:
	the PTSC counter period

* PTSC:
	performance timestamp counter

* N:
	the ratio of compute unit power accumulator sample period to the
	PTSC period

* Jmax:
	max compute unit accumulated power which is indicated by
	MaxCpuSwPwrAcc MSR C001007b

* Jx/Jy:
	compute unit accumulated power which is indicated by
	CpuSwPwrAcc MSR C001007a
* Tx/Ty:
	the value of performance timestamp counter which is indicated
	by CU_PTSC MSR C0010280

* PwrCPUave:
	CPU average power

i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007.

	N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]].

ii. Read the full range of the cumulative energy value from the new
    MSR MaxCpuSwPwrAcc.

	Jmax = value returned.

iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC.

	Jx = value read from CpuSwPwrAcc and Tx = value read from PTSC.

iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC.

	Jy = value read from CpuSwPwrAcc and Ty = value read from PTSC.

v. Calculate the average power consumption for a compute unit over
   time period (y-x). Unit of result is uWatt::

	if (Jy < Jx) // Rollover has occurred
		Jdelta = (Jy + Jmax) - Jx
	else
		Jdelta = Jy - Jx
	PwrCPUave = N * Jdelta * 1000 / (Ty - Tx)

This driver provides PwrCPUave and interval(default is 10 millisecond
and maximum is 1 second):

* power1_average (PwrCPUave)
* power1_average_interval (Interval)

The power1_average_interval can be updated at /etc/sensors3.conf file
as below:

chip `fam15h_power-*`
	set power1_average_interval 0.01

Then save it with "sensors -s".


code:
.. SPDX-License-Identifier: GPL-2.0

Kernel driver fsp3y
======================
Supported devices:
  * 3Y POWER YH-5151E
  * 3Y POWER YM-2151E

Author: Václav Kubernát <kubernat@cesnet.cz>

Description
-----------
This driver implements limited support for two 3Y POWER devices.

Sysfs entries
-------------
  * in1_input            input voltage
  * in2_input            12V output voltage
  * in3_input            5V output voltage
  * curr1_input          input current
  * curr2_input          12V output current
  * curr3_input          5V output current
  * fan1_input           fan rpm
  * temp1_input          temperature 1
  * temp2_input          temperature 2
  * temp3_input          temperature 3
  * power1_input         input power
  * power2_input         output power


code:
Kernel driver ftsteutates
=========================

Supported chips:

  * FTS Teutates

    Prefix: 'ftsteutates'

    Addresses scanned: I2C 0x73 (7-Bit)

Author: Thilo Cestonaro <thilo.cestonaro@ts.fujitsu.com>

Description
-----------

The BMC Teutates is the Eleventh generation of Superior System
monitoring and thermal management solution. It is builds on the basic
functionality of the BMC Theseus and contains several new features and
enhancements. It can monitor up to 4 voltages, 16 temperatures and
8 fans. It also contains an integrated watchdog which is currently
implemented in this driver.

To clear a temperature or fan alarm, execute the following command with the
correct path to the alarm file::

	echo 0 >XXXX_alarm

Specification of the chip can be found here:

- ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf
- ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf


code:
Kernel driver g760a
===================

Supported chips:

  * Global Mixed-mode Technology Inc. G760A

    Prefix: 'g760a'

    Datasheet: Publicly available at the GMT website

      http://www.gmt.com.tw/product/datasheet/EDS-760A.pdf

Author: Herbert Valerio Riedel <hvr@gnu.org>

Description
-----------

The GMT G760A Fan Speed PWM Controller is connected directly to a fan
and performs closed-loop control of the fan speed.

The fan speed is programmed by setting the period via 'pwm1' of two
consecutive speed pulses. The period is defined in terms of clock
cycle counts of an assumed 32kHz clock source.

Setting a period of 0 stops the fan; setting the period to 255 sets
fan to maximum speed.

The measured fan rotation speed returned via 'fan1_input' is derived
from the measured speed pulse period by assuming again a 32kHz clock
source and a 2 pulse-per-revolution fan.

The 'alarms' file provides access to the two alarm bits provided by
the G760A chip's status register: Bit 0 is set when the actual fan
speed differs more than 20% with respect to the programmed fan speed;
bit 1 is set when fan speed is below 1920 RPM.

The g760a driver will not update its values more frequently than every
other second; reading them more often will do no harm, but will return
'old' values.


code:
Kernel driver g762
==================

The GMT G762 Fan Speed PWM Controller is connected directly to a fan
and performs closed-loop or open-loop control of the fan speed. Two
modes - PWM or DC - are supported by the device.

For additional information, a detailed datasheet is available at
http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf. sysfs
bindings are described in Documentation/hwmon/sysfs-interface.rst.

The following entries are available to the user in a subdirectory of
/sys/bus/i2c/drivers/g762/ to control the operation of the device.
This can be done manually using the following entries but is usually
done via a userland daemon like fancontrol.

Note that those entries do not provide ways to setup the specific
hardware characteristics of the system (reference clock, pulses per
fan revolution, ...); Those can be modified via devicetree bindings
documented in Documentation/devicetree/bindings/hwmon/g762.txt or
using a specific platform_data structure in board initialization
file (see include/linux/platform_data/g762.h).

  fan1_target:
	    set desired fan speed. This only makes sense in closed-loop
	    fan speed control (i.e. when pwm1_enable is set to 2).

  fan1_input:
	    provide current fan rotation value in RPM as reported by
	    the fan to the device.

  fan1_div:
	    fan clock divisor. Supported value are 1, 2, 4 and 8.

  fan1_pulses:
	    number of pulses per fan revolution. Supported values
	    are 2 and 4.

  fan1_fault:
	    reports fan failure, i.e. no transition on fan gear pin for
	    about 0.7s (if the fan is not voluntarily set off).

  fan1_alarm:
	    in closed-loop control mode, if fan RPM value is 25% out
	    of the programmed value for over 6 seconds 'fan1_alarm' is
	    set to 1.

  pwm1_enable:
	    set current fan speed control mode i.e. 1 for manual fan
	    speed control (open-loop) via pwm1 described below, 2 for
	    automatic fan speed control (closed-loop) via fan1_target
	    above.

  pwm1_mode:
	    set or get fan driving mode: 1 for PWM mode, 0 for DC mode.

  pwm1:
	    get or set PWM fan control value in open-loop mode. This is an
	    integer value between 0 and 255. 0 stops the fan, 255 makes
	    it run at full speed.

Both in PWM mode ('pwm1_mode' set to 1) and DC mode ('pwm1_mode' set to 0),
when current fan speed control mode is open-loop ('pwm1_enable' set to 1),
the fan speed is programmed by setting a value between 0 and 255 via 'pwm1'
entry (0 stops the fan, 255 makes it run at full speed). In closed-loop mode
('pwm1_enable' set to 2), the expected rotation speed in RPM can be passed to
the chip via 'fan1_target'. In closed-loop mode, the target speed is compared
with current speed (available via 'fan1_input') by the device and a feedback
is performed to match that target value. The fan speed value is computed
based on the parameters associated with the physical characteristics of the
system: a reference clock source frequency, a number of pulses per fan
revolution, etc.

Note that the driver will update its values at most once per second.


code:
Kernel driver gl518sm
=====================

Supported chips:

  * Genesys Logic GL518SM release 0x00

    Prefix: 'gl518sm'

    Addresses scanned: I2C 0x2c and 0x2d

  * Genesys Logic GL518SM release 0x80

    Prefix: 'gl518sm'

    Addresses scanned: I2C 0x2c and 0x2d

    Datasheet: http://www.genesyslogic.com/

Authors:
       - Frodo Looijaard <frodol@dds.nl>,
       - Kyösti Mälkki <kmalkki@cc.hut.fi>
       - Hong-Gunn Chew <hglinux@gunnet.org>
       - Jean Delvare <jdelvare@suse.de>

Description
-----------

.. important::

   For the revision 0x00 chip, the in0, in1, and in2  values (+5V, +3V,
   and +12V) CANNOT be read. This is a limitation of the chip, not the driver.

This driver supports the Genesys Logic GL518SM chip. There are at least
two revision of this chip, which we call revision 0x00 and 0x80. Revision
0x80 chips support the reading of all voltages and revision 0x00 only
for VIN3.

The GL518SM implements one temperature sensor, two fan rotation speed
sensors, and four voltage sensors. It can report alarms through the
computer speakers.

Temperatures are measured in degrees Celsius. An alarm goes off while the
temperature is above the over temperature limit, and has not yet dropped
below the hysteresis limit. The alarm always reflects the current
situation. Measurements are guaranteed between -10 degrees and +110
degrees, with a accuracy of +/-3 degrees.

Rotation speeds are reported in RPM (rotations per minute). An alarm is
triggered if the rotation speed has dropped below a programmable limit. In
case when you have selected to turn fan1 off, no fan1 alarm is triggered.

Fan readings can be divided by a programmable divider (1, 2, 4 or 8) to
give the readings more range or accuracy.  Not all RPM values can
accurately be represented, so some rounding is done. With a divider
of 2, the lowest representable value is around 1900 RPM.

Voltage sensors (also known as VIN sensors) report their values in volts.
An alarm is triggered if the voltage has crossed a programmable minimum or
maximum limit. Note that minimum in this case always means 'closest to
zero'; this is important for negative voltage measurements. The VDD input
measures voltages between 0.000 and 5.865 volt, with a resolution of 0.023
volt. The other inputs measure voltages between 0.000 and 4.845 volt, with
a resolution of 0.019 volt. Note that revision 0x00 chips do not support
reading the current voltage of any input except for VIN3; limit setting and
alarms work fine, though.

When an alarm is triggered, 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.

If an alarm triggers, it will remain triggered until the hardware register
is read at least once (except for temperature alarms). This means that the
cause for the alarm may already have disappeared! Note that in the current
implementation, all hardware registers are read whenever any data is read
(unless it is less than 1.5 seconds since the last update). This means that
you can easily miss once-only alarms.

The GL518SM only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.


code:
.. SPDX-License-Identifier: GPL-2.0

Kernel driver gsc-hwmon
=======================

Supported chips: Gateworks GSC
Datasheet: http://trac.gateworks.com/wiki/gsc
Author: Tim Harvey <tharvey@gateworks.com>

Description:
------------

This driver supports hardware monitoring for the temperature sensor,
various ADC's connected to the GSC, and optional FAN controller available
on some boards.

Voltage Monitoring
------------------

The voltage inputs are scaled either internally or by the driver depending
on the GSC version and firmware. The values returned by the driver do not need
further scaling. The voltage input labels provide the voltage rail name:

inX_input                  Measured voltage (mV).
inX_label                  Name of voltage rail.

Temperature Monitoring
----------------------

Temperatures are measured with 12-bit or 10-bit resolution and are scaled
either internally or by the driver depending on the GSC version and firmware.
The values returned by the driver reflect millidegree Celcius:

tempX_input                Measured temperature.
tempX_label                Name of temperature input.

PWM Output Control
------------------

The GSC features 1 PWM output that operates in automatic mode where the
PWM value will be scalled depending on 6 temperature boundaries.
The tempeature boundaries are read-write and in millidegree Celcius and the
read-only PWM values range from 0 (off) to 255 (full speed).
Fan speed will be set to minimum (off) when the temperature sensor reads
less than pwm1_auto_point1_temp and maximum when the temperature sensor
equals or exceeds pwm1_auto_point6_temp.

pwm1_auto_point[1-6]_pwm       PWM value.
pwm1_auto_point[1-6]_temp      Temperature boundary.


code:
Kernel driver hih6130
=====================

Supported chips:

  * Honeywell HIH-6130 / HIH-6131

    Prefix: 'hih6130'

    Addresses scanned: none

    Datasheet: Publicly available at the Honeywell website

	http://sensing.honeywell.com/index.php?ci_id=3106&la_id=1&defId=44872

Author:
  Iain Paton <ipaton0@gmail.com>

Description
-----------

The HIH-6130 & HIH-6131 are humidity and temperature sensors in a SO8 package.
The difference between the two devices is that the HIH-6131 has a condensation
filter.

The devices communicate with the I2C protocol. All sensors are set to the same
I2C address 0x27 by default, so an entry with I2C_BOARD_INFO("hih6130", 0x27)
can be used in the board setup code.

Please see Documentation/i2c/instantiating-devices.rst for details on how to
instantiate I2C devices.

sysfs-Interface
---------------

temp1_input
	temperature input

humidity1_input
	humidity input

Notes
-----

Command mode and alarms are not currently supported.


code:
The Linux Hardware Monitoring kernel API
========================================

Guenter Roeck

Introduction
------------

This document describes the API that can be used by hardware monitoring
drivers that want to use the hardware monitoring framework.

This document does not describe what a hardware monitoring (hwmon) Driver or
Device is. It also does not describe the API which can be used by user space
to communicate with a hardware monitoring device. If you want to know this
then please read the following file: Documentation/hwmon/sysfs-interface.rst.

For additional guidelines on how to write and improve hwmon drivers, please
also read Documentation/hwmon/submitting-patches.rst.

The API
-------
Each hardware monitoring driver must #include <linux/hwmon.h> and, in most
cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following
register/unregister functions::

  struct device *
  hwmon_device_register_with_groups(struct device *dev, const char *name,
				    void *drvdata,
				    const struct attribute_group **groups);

  struct device *
  devm_hwmon_device_register_with_groups(struct device *dev,
					 const char *name, void *drvdata,
					 const struct attribute_group **groups);

  struct device *
  hwmon_device_register_with_info(struct device *dev,
				  const char *name, void *drvdata,
				  const struct hwmon_chip_info *info,
				  const struct attribute_group **extra_groups);

  struct device *
  devm_hwmon_device_register_with_info(struct device *dev,
				       const char *name,
				       void *drvdata,
				       const struct hwmon_chip_info *info,
				       const struct attribute_group **extra_groups);

  void hwmon_device_unregister(struct device *dev);

  void devm_hwmon_device_unregister(struct device *dev);

  char *hwmon_sanitize_name(const char *name);

  char *devm_hwmon_sanitize_name(struct device *dev, const char *name);

hwmon_device_register_with_groups registers a hardware monitoring device.
The first parameter of this function is a pointer to the parent device.
The name parameter is a pointer to the hwmon device name. The registration
function wil create a name sysfs attribute pointing to this name.
The drvdata parameter is the pointer to the local driver data.
hwmon_device_register_with_groups will attach this pointer to the newly
allocated hwmon device. The pointer can be retrieved by the driver using
dev_get_drvdata() on the hwmon device pointer. The groups parameter is
a pointer to a list of sysfs attribute groups. The list must be NULL terminated.
hwmon_device_register_with_groups creates the hwmon device with name attribute
as well as all sysfs attributes attached to the hwmon device.
This function returns a pointer to the newly created hardware monitoring device
or PTR_ERR for failure.

devm_hwmon_device_register_with_groups is similar to
hwmon_device_register_with_groups. However, it is device managed, meaning the
hwmon device does not have to be removed explicitly by the removal function.

hwmon_device_register_with_info is the most comprehensive and preferred means
to register a hardware monitoring device. It creates the standard sysfs
attributes in the hardware monitoring core, letting the driver focus on reading
from and writing to the chip instead of having to bother with sysfs attributes.
The parent device parameter as well as the chip parameter must not be NULL. Its
parameters are described in more detail below.

devm_hwmon_device_register_with_info is similar to
hwmon_device_register_with_info. However, it is device managed, meaning the
hwmon device does not have to be removed explicitly by the removal function.

hwmon_device_unregister deregisters a registered hardware monitoring device.
The parameter of this function is the pointer to the registered hardware
monitoring device structure. This function must be called from the driver
remove function if the hardware monitoring device was registered with
hwmon_device_register_with_groups or hwmon_device_register_with_info.

devm_hwmon_device_unregister does not normally have to be called. It is only
needed for error handling, and only needed if the driver probe fails after
the call to devm_hwmon_device_register_with_groups or
hwmon_device_register_with_info and if the automatic (device managed)
removal would be too late.

All supported hwmon device registration functions only accept valid device
names. Device names including invalid characters (whitespace, '*', or '-')
will be rejected. The 'name' parameter is mandatory.

If the driver doesn't use a static device name (for example it uses
dev_name()), and therefore cannot make sure the name only contains valid
characters, hwmon_sanitize_name can be used. This convenience function
will duplicate the string and replace any invalid characters with an
underscore. It will allocate memory for the new string and it is the
responsibility of the caller to release the memory when the device is
removed.

devm_hwmon_sanitize_name is the resource managed version of
hwmon_sanitize_name; the memory will be freed automatically on device
removal.

Using devm_hwmon_device_register_with_info()
--------------------------------------------

hwmon_device_register_with_info() registers a hardware monitoring device.
The parameters to this function are

=============================================== ===============================================
`struct device *dev`				Pointer to parent device
`const char *name`				Device name
`void *drvdata`					Driver private data
`const struct hwmon_chip_info *info`		Pointer to chip description.
`const struct attribute_group **extra_groups` 	Null-terminated list of additional non-standard
						sysfs attribute groups.
=============================================== ===============================================

This function returns a pointer to the created hardware monitoring device
on success and a negative error code for failure.

The hwmon_chip_info structure looks as follows::

	struct hwmon_chip_info {
		const struct hwmon_ops *ops;
		const struct hwmon_channel_info **info;
	};

It contains the following fields:

* ops:
	Pointer to device operations.
* info:
	NULL-terminated list of device channel descriptors.

The list of hwmon operations is defined as::

  struct hwmon_ops {
	umode_t (*is_visible)(const void *, enum hwmon_sensor_types type,
			      u32 attr, int);
	int (*read)(struct device *, enum hwmon_sensor_types type,
		    u32 attr, int, long *);
	int (*write)(struct device *, enum hwmon_sensor_types type,
		     u32 attr, int, long);
  };

It defines the following operations.

* is_visible:
    Pointer to a function to return the file mode for each supported
    attribute. This function is mandatory.

* read:
    Pointer to a function for reading a value from the chip. This function
    is optional, but must be provided if any readable attributes exist.

* write:
    Pointer to a function for writing a value to the chip. This function is
    optional, but must be provided if any writeable attributes exist.

Each sensor channel is described with struct hwmon_channel_info, which is
defined as follows::

	struct hwmon_channel_info {
		enum hwmon_sensor_types type;
		u32 *config;
	};

It contains following fields:

* type:
    The hardware monitoring sensor type.

    Supported sensor types are

     ================== ==================================================
     hwmon_chip		A virtual sensor type, used to describe attributes
			which are not bound to a specific input or output
     hwmon_temp		Temperature sensor
     hwmon_in		Voltage sensor
     hwmon_curr		Current sensor
     hwmon_power		Power sensor
     hwmon_energy	Energy sensor
     hwmon_humidity	Humidity sensor
     hwmon_fan		Fan speed sensor
     hwmon_pwm		PWM control
     ================== ==================================================

* config:
    Pointer to a 0-terminated list of configuration values for each
    sensor of the given type. Each value is a combination of bit values
    describing the attributes supposed by a single sensor.

As an example, here is the complete description file for a LM75 compatible
sensor chip. The chip has a single temperature sensor. The driver wants to
register with the thermal subsystem (HWMON_C_REGISTER_TZ), and it supports
the update_interval attribute (HWMON_C_UPDATE_INTERVAL). The chip supports
reading the temperature (HWMON_T_INPUT), it has a maximum temperature
register (HWMON_T_MAX) as well as a maximum temperature hysteresis register
(HWMON_T_MAX_HYST)::

	static const u32 lm75_chip_config[] = {
		HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL,
		0
	};

	static const struct hwmon_channel_info lm75_chip = {
		.type = hwmon_chip,
		.config = lm75_chip_config,
	};

	static const u32 lm75_temp_config[] = {
		HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST,
		0
	};

	static const struct hwmon_channel_info lm75_temp = {
		.type = hwmon_temp,
		.config = lm75_temp_config,
	};

	static const struct hwmon_channel_info *lm75_info[] = {
		&lm75_chip,
		&lm75_temp,
		NULL
	};

	The HWMON_CHANNEL_INFO() macro can and should be used when possible.
	With this macro, the above example can be simplified to

	static const struct hwmon_channel_info *lm75_info[] = {
		HWMON_CHANNEL_INFO(chip,
				HWMON_C_REGISTER_TZ | HWMON_C_UPDATE_INTERVAL),
		HWMON_CHANNEL_INFO(temp,
				HWMON_T_INPUT | HWMON_T_MAX | HWMON_T_MAX_HYST),
		NULL
	};

	The remaining declarations are as follows.

	static const struct hwmon_ops lm75_hwmon_ops = {
		.is_visible = lm75_is_visible,
		.read = lm75_read,
		.write = lm75_write,
	};

	static const struct hwmon_chip_info lm75_chip_info = {
		.ops = &lm75_hwmon_ops,
		.info = lm75_info,
	};

A complete list of bit values indicating individual attribute support
is defined in include/linux/hwmon.h. Definition prefixes are as follows.

=============== =================================================
HWMON_C_xxxx	Chip attributes, for use with hwmon_chip.
HWMON_T_xxxx	Temperature attributes, for use with hwmon_temp.
HWMON_I_xxxx	Voltage attributes, for use with hwmon_in.
HWMON_C_xxxx	Current attributes, for use with hwmon_curr.
		Notice the prefix overlap with chip attributes.
HWMON_P_xxxx	Power attributes, for use with hwmon_power.
HWMON_E_xxxx	Energy attributes, for use with hwmon_energy.
HWMON_H_xxxx	Humidity attributes, for use with hwmon_humidity.
HWMON_F_xxxx	Fan speed attributes, for use with hwmon_fan.
HWMON_PWM_xxxx	PWM control attributes, for use with hwmon_pwm.
=============== =================================================

Driver callback functions
-------------------------

Each driver provides is_visible, read, and write functions. Parameters
and return values for those functions are as follows::

  umode_t is_visible_func(const void *data, enum hwmon_sensor_types type,
			  u32 attr, int channel)

Parameters:
	data:
		Pointer to device private data structure.
	type:
		The sensor type.
	attr:
		Attribute identifier associated with a specific attribute.
		For example, the attribute value for HWMON_T_INPUT would be
		hwmon_temp_input. For complete mappings of bit fields to
		attribute values please see include/linux/hwmon.h.
	channel:
		The sensor channel number.

Return value:
	The file mode for this attribute. Typically, this will be 0 (the
	attribute will not be created), S_IRUGO, or 'S_IRUGO | S_IWUSR'.

::

	int read_func(struct device *dev, enum hwmon_sensor_types type,
		      u32 attr, int channel, long *val)

Parameters:
	dev:
		Pointer to the hardware monitoring device.
	type:
		The sensor type.
	attr:
		Attribute identifier associated with a specific attribute.
		For example, the attribute value for HWMON_T_INPUT would be
		hwmon_temp_input. For complete mappings please see
		include/linux/hwmon.h.
	channel:
		The sensor channel number.
	val:
		Pointer to attribute value.

Return value:
	0 on success, a negative error number otherwise.

::

	int write_func(struct device *dev, enum hwmon_sensor_types type,
		       u32 attr, int channel, long val)

Parameters:
	dev:
		Pointer to the hardware monitoring device.
	type:
		The sensor type.
	attr:
		Attribute identifier associated with a specific attribute.
		For example, the attribute value for HWMON_T_INPUT would be
		hwmon_temp_input. For complete mappings please see
		include/linux/hwmon.h.
	channel:
		The sensor channel number.
	val:
		The value to write to the chip.

Return value:
	0 on success, a negative error number otherwise.

Driver-provided sysfs attributes
--------------------------------

If the hardware monitoring device is registered with
hwmon_device_register_with_info or devm_hwmon_device_register_with_info,
it is most likely not necessary to provide sysfs attributes. Only additional
non-standard sysfs attributes need to be provided when one of those registration
functions is used.

The header file linux/hwmon-sysfs.h provides a number of useful macros to
declare and use hardware monitoring sysfs attributes.

In many cases, you can use the exsting define DEVICE_ATTR or its variants
DEVICE_ATTR_{RW,RO,WO} to declare such attributes. This is feasible if an
attribute has no additional context. However, in many cases there will be
additional information such as a sensor index which will need to be passed
to the sysfs attribute handling function.

SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes
which need such additional context information. SENSOR_DEVICE_ATTR requires
one additional argument, SENSOR_DEVICE_ATTR_2 requires two.

Simplified variants of SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 are available
and should be used if standard attribute permissions and function names are
feasible. Standard permissions are 0644 for SENSOR_DEVICE_ATTR[_2]_RW,
0444 for SENSOR_DEVICE_ATTR[_2]_RO, and 0200 for SENSOR_DEVICE_ATTR[_2]_WO.
Standard functions, similar to DEVICE_ATTR_{RW,RO,WO}, have _show and _store
appended to the provided function name.

SENSOR_DEVICE_ATTR and its variants define a struct sensor_device_attribute
variable. This structure has the following fields::

	struct sensor_device_attribute {
		struct device_attribute dev_attr;
		int index;
	};

You can use to_sensor_dev_attr to get the pointer to this structure from the
attribute read or write function. Its parameter is the device to which the
attribute is attached.

SENSOR_DEVICE_ATTR_2 and its variants define a struct sensor_device_attribute_2
variable, which is defined as follows::

	struct sensor_device_attribute_2 {
		struct device_attribute dev_attr;
		u8 index;
		u8 nr;
	};

Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter
is the device to which the attribute is attached.


code:
Kernel driver ibm-cffps
=======================

Supported chips:

  * IBM Common Form Factor power supply

Author: Eddie James <eajames@us.ibm.com>

Description
-----------

This driver supports IBM Common Form Factor (CFF) power supplies. This driver
is a client to the core PMBus driver.

Usage Notes
-----------

This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
details.

Sysfs entries
-------------

The following attributes are supported:

======================= ======================================================
curr1_alarm		Output current over-current alarm.
curr1_input		Measured output current in mA.
curr1_label		"iout1"

fan1_alarm		Fan 1 warning.
fan1_fault		Fan 1 fault.
fan1_input		Fan 1 speed in RPM.
fan2_alarm		Fan 2 warning.
fan2_fault		Fan 2 fault.
fan2_input		Fan 2 speed in RPM.

in1_alarm		Input voltage under-voltage alarm.
in1_input		Measured input voltage in mV.
in1_label		"vin"
in2_alarm		Output voltage over-voltage alarm.
in2_input		Measured output voltage in mV.
in2_label		"vout1"

power1_alarm		Input fault or alarm.
power1_input		Measured input power in uW.
power1_label		"pin"

temp1_alarm		PSU inlet ambient temperature over-temperature alarm.
temp1_input		Measured PSU inlet ambient temp in millidegrees C.
temp2_alarm		Secondary rectifier temp over-temperature alarm.
temp2_input		Measured secondary rectifier temp in millidegrees C.
temp3_alarm		ORing FET temperature over-temperature alarm.
temp3_input		Measured ORing FET temperature in millidegrees C.
======================= ======================================================


code:
Kernel driver ibmaem
====================

This driver talks to the IBM Systems Director Active Energy Manager, known
henceforth as AEM.

Supported systems:

  * Any recent IBM System X server with AEM support.

    This includes the x3350, x3550, x3650, x3655, x3755, x3850 M2,
    x3950 M2, and certain HC10/HS2x/LS2x/QS2x blades.

    The IPMI host interface
    driver ("ipmi-si") needs to be loaded for this driver to do anything.

    Prefix: 'ibmaem'

    Datasheet: Not available

Author: Darrick J. Wong

Description
-----------

This driver implements sensor reading support for the energy and power meters
available on various IBM System X hardware through the BMC.  All sensor banks
will be exported as platform devices; this driver can talk to both v1 and v2
interfaces.  This driver is completely separate from the older ibmpex driver.

The v1 AEM interface has a simple set of features to monitor energy use.  There
is a register that displays an estimate of raw energy consumption since the
last BMC reset, and a power sensor that returns average power use over a
configurable interval.

The v2 AEM interface is a bit more sophisticated, being able to present a wider
range of energy and power use registers, the power cap as set by the AEM
software, and temperature sensors.

Special Features
----------------

The "power_cap" value displays the current system power cap, as set by the AEM
software.  Setting the power cap from the host is not currently supported.


code:
Kernel Driver IBMPOWERNV
========================

Supported systems:

  * Any recent IBM P servers based on POWERNV platform

Author: Neelesh Gupta

Description
-----------

This driver implements reading the platform sensors data like temperature/fan/
voltage/power for 'POWERNV' platform.

The driver uses the platform device infrastructure. It probes the device tree
for sensor devices during the __init phase and registers them with the 'hwmon'.
'hwmon' populates the 'sysfs' tree having attribute files, each for a given
sensor type and its attribute data.

All the nodes in the DT appear under "/ibm,opal/sensors" and each valid node in
the DT maps to an attribute file in 'sysfs'. The node exports unique 'sensor-id'
which the driver uses to make an OPAL call to the firmware.

Usage notes
-----------
The driver is built statically with the kernel by enabling the config
CONFIG_SENSORS_IBMPOWERNV. It can also be built as module 'ibmpowernv'.

Sysfs attributes
----------------

======================= =======================================================
fanX_input		Measured RPM value.
fanX_min		Threshold RPM for alert generation.
fanX_fault		- 0: No fail condition
			- 1: Failing fan

tempX_input		Measured ambient temperature.
tempX_max		Threshold ambient temperature for alert generation.
tempX_highest		Historical maximum temperature
tempX_lowest		Historical minimum temperature
tempX_enable		Enable/disable all temperature sensors belonging to the
			sub-group. In POWER9, this attribute corresponds to
			each OCC. Using this attribute each OCC can be asked to
			disable/enable all of its temperature sensors.

			- 1: Enable
			- 0: Disable

inX_input		Measured power supply voltage (millivolt)
inX_fault		- 0: No fail condition.
			- 1: Failing power supply.
inX_highest		Historical maximum voltage
inX_lowest		Historical minimum voltage
inX_enable		Enable/disable all voltage sensors belonging to the
			sub-group. In POWER9, this attribute corresponds to
			each OCC. Using this attribute each OCC can be asked to
			disable/enable all of its voltage sensors.

			- 1: Enable
			- 0: Disable

powerX_input		Power consumption (microWatt)
powerX_input_highest	Historical maximum power
powerX_input_lowest	Historical minimum power
powerX_enable		Enable/disable all power sensors belonging to the
			sub-group. In POWER9, this attribute corresponds to
			each OCC. Using this attribute each OCC can be asked to
			disable/enable all of its power sensors.

			- 1: Enable
			- 0: Disable

currX_input		Measured current (milliampere)
currX_highest		Historical maximum current
currX_lowest		Historical minimum current
currX_enable		Enable/disable all current sensors belonging to the
			sub-group. In POWER9, this attribute corresponds to
			each OCC. Using this attribute each OCC can be asked to
			disable/enable all of its current sensors.

			- 1: Enable
			- 0: Disable

energyX_input		Cumulative energy (microJoule)
======================= =======================================================


code:
Kernel driver ina209
====================

Supported chips:

  * Burr-Brown / Texas Instruments INA209

    Prefix: 'ina209'

    Addresses scanned: -

    Datasheet:
	https://www.ti.com/lit/gpn/ina209

Author:
	- Paul Hays <Paul.Hays@cattail.ca>
	- Ira W. Snyder <iws@ovro.caltech.edu>
	- Guenter Roeck <linux@roeck-us.net>

Description
-----------

The TI / Burr-Brown INA209 monitors voltage, current, and power on the high side
of a D.C. power supply. It can perform measurements and calculations in the
background to supply readings at any time. It includes a programmable
calibration multiplier to scale the displayed current and power values.

Sysfs entries
-------------

The INA209 chip is highly configurable both via hardwiring and via
the I2C bus. See the datasheet for details.

This tries to expose most monitoring features of the hardware via
sysfs. It does not support every feature of this chip.

======================= =======================================================
in0_input		shunt voltage (mV)
in0_input_highest	shunt voltage historical maximum reading (mV)
in0_input_lowest	shunt voltage historical minimum reading (mV)
in0_reset_history	reset shunt voltage history
in0_max			shunt voltage max alarm limit (mV)
in0_min			shunt voltage min alarm limit (mV)
in0_crit_max		shunt voltage crit max alarm limit (mV)
in0_crit_min		shunt voltage crit min alarm limit (mV)
in0_max_alarm		shunt voltage max alarm limit exceeded
in0_min_alarm		shunt voltage min alarm limit exceeded
in0_crit_max_alarm	shunt voltage crit max alarm limit exceeded
in0_crit_min_alarm	shunt voltage crit min alarm limit exceeded

in1_input		bus voltage (mV)
in1_input_highest	bus voltage historical maximum reading (mV)
in1_input_lowest	bus voltage historical minimum reading (mV)
in1_reset_history	reset bus voltage history
in1_max			bus voltage max alarm limit (mV)
in1_min			bus voltage min alarm limit (mV)
in1_crit_max		bus voltage crit max alarm limit (mV)
in1_crit_min		bus voltage crit min alarm limit (mV)
in1_max_alarm		bus voltage max alarm limit exceeded
in1_min_alarm		bus voltage min alarm limit exceeded
in1_crit_max_alarm	bus voltage crit max alarm limit exceeded
in1_crit_min_alarm	bus voltage crit min alarm limit exceeded

power1_input		power measurement (uW)
power1_input_highest	power historical maximum reading (uW)
power1_reset_history	reset power history
power1_max		power max alarm limit (uW)
power1_crit		power crit alarm limit (uW)
power1_max_alarm	power max alarm limit exceeded
power1_crit_alarm	power crit alarm limit exceeded

curr1_input		current measurement (mA)

update_interval		data conversion time; affects number of samples used
			to average results for shunt and bus voltages.
======================= =======================================================

General Remarks
---------------

The power and current registers in this chip require that the calibration
register is programmed correctly before they are used. Normally this is expected
to be done in the BIOS. In the absence of BIOS programming, the shunt resistor
voltage can be provided using platform data. The driver uses platform data from
the ina2xx driver for this purpose. If calibration register data is not provided
via platform data, the driver checks if the calibration register has been
programmed (ie has a value not equal to zero). If so, this value is retained.
Otherwise, a default value reflecting a shunt resistor value of 10 mOhm is
programmed into the calibration register.

Output Pins
-----------

Output pin programming is a board feature which depends on the BIOS. It is
outside the scope of a hardware monitoring driver to enable or disable output
pins.


code:
.. SPDX-License-Identifier: GPL-2.0-only

Kernel driver ina238
====================

Supported chips:

  * Texas Instruments INA238

    Prefix: 'ina238'

    Addresses: I2C 0x40 - 0x4f

    Datasheet:
	https://www.ti.com/lit/gpn/ina238

Author: Nathan Rossi <nathan.rossi@digi.com>

Description
-----------

The INA238 is a current shunt, power and temperature monitor with an I2C
interface. It includes a number of programmable functions including alerts,
conversion rate, sample averaging and selectable shunt voltage accuracy.

The shunt value in micro-ohms can be set via platform data or device tree at
compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
refer to the Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for bindings
if the device tree is used.

Sysfs entries
-------------

======================= =======================================================
in0_input		Shunt voltage (mV)
in0_min			Minimum shunt voltage threshold (mV)
in0_min_alarm		Minimum shunt voltage alarm
in0_max			Maximum shunt voltage threshold (mV)
in0_max_alarm		Maximum shunt voltage alarm

in1_input		Bus voltage (mV)
in1_min			Minimum bus voltage threshold (mV)
in1_min_alarm		Minimum shunt voltage alarm
in1_max			Maximum bus voltage threshold (mV)
in1_max_alarm		Maximum shunt voltage alarm

power1_input		Power measurement (uW)
power1_max		Maximum power threshold (uW)
power1_max_alarm	Maximum power alarm

curr1_input		Current measurement (mA)

temp1_input		Die temperature measurement (mC)
temp1_max		Maximum die temperature threshold (mC)
temp1_max_alarm		Maximum die temperature alarm
======================= =======================================================


code:
Kernel driver ina2xx
====================

Supported chips:

  * Texas Instruments INA219

    Prefix: 'ina219'
    Addresses: I2C 0x40 - 0x4f

    Datasheet: Publicly available at the Texas Instruments website

	       https://www.ti.com/

  * Texas Instruments INA220

    Prefix: 'ina220'

    Addresses: I2C 0x40 - 0x4f

    Datasheet: Publicly available at the Texas Instruments website

	       https://www.ti.com/

  * Texas Instruments INA226

    Prefix: 'ina226'

    Addresses: I2C 0x40 - 0x4f

    Datasheet: Publicly available at the Texas Instruments website

	       https://www.ti.com/

  * Texas Instruments INA230

    Prefix: 'ina230'

    Addresses: I2C 0x40 - 0x4f

    Datasheet: Publicly available at the Texas Instruments website

	       https://www.ti.com/

  * Texas Instruments INA231

    Prefix: 'ina231'

    Addresses: I2C 0x40 - 0x4f

    Datasheet: Publicly available at the Texas Instruments website

	       https://www.ti.com/

Author: Lothar Felten <lothar.felten@gmail.com>

Description
-----------

The INA219 is a high-side current shunt and power monitor with an I2C
interface. The INA219 monitors both shunt drop and supply voltage, with
programmable conversion times and filtering.

The INA220 is a high or low side current shunt and power monitor with an I2C
interface. The INA220 monitors both shunt drop and supply voltage.

The INA226 is a current shunt and power monitor with an I2C interface.
The INA226 monitors both a shunt voltage drop and bus supply voltage.

INA230 and INA231 are high or low side current shunt and power monitors
with an I2C interface. The chips monitor both a shunt voltage drop and
bus supply voltage.

The shunt value in micro-ohms can be set via platform data or device tree at
compile-time or via the shunt_resistor attribute in sysfs at run-time. Please
refer to the Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml for bindings
if the device tree is used.

Additionally ina226 supports update_interval attribute as described in
Documentation/hwmon/sysfs-interface.rst. Internally the interval is the sum of
bus and shunt voltage conversion times multiplied by the averaging rate. We
don't touch the conversion times and only modify the number of averages. The
lower limit of the update_interval is 2 ms, the upper limit is 2253 ms.
The actual programmed interval may vary from the desired value.

General sysfs entries
---------------------

======================= ===============================
in0_input		Shunt voltage(mV) channel
in1_input		Bus voltage(mV) channel
curr1_input		Current(mA) measurement channel
power1_input		Power(uW) measurement channel
shunt_resistor		Shunt resistance(uOhm) channel
======================= ===============================

Sysfs entries for ina226, ina230 and ina231 only
------------------------------------------------

======================= ====================================================
in0_lcrit		Critical low shunt voltage
in0_crit		Critical high shunt voltage
in0_lcrit_alarm		Shunt voltage critical low alarm
in0_crit_alarm		Shunt voltage critical high alarm
in1_lcrit		Critical low bus voltage
in1_crit		Critical high bus voltage
in1_lcrit_alarm		Bus voltage critical low alarm
in1_crit_alarm		Bus voltage critical high alarm
power1_crit		Critical high power
power1_crit_alarm	Power critical high alarm
update_interval		data conversion time; affects number of samples used
			to average results for shunt and bus voltages.
======================= ====================================================

.. note::

   - Configure `shunt_resistor` before configure `power1_crit`, because power
     value is calculated based on `shunt_resistor` set.
   - Because of the underlying register implementation, only one `*crit` setting
     and its `alarm` can be active. Writing to one `*crit` setting clears other
     `*crit` settings and alarms. Writing 0 to any `*crit` setting clears all
     `*crit` settings and alarms.


code:
Kernel driver ina3221
=====================

Supported chips:

  * Texas Instruments INA3221

    Prefix: 'ina3221'

    Addresses: I2C 0x40 - 0x43

    Datasheet: Publicly available at the Texas Instruments website

	       https://www.ti.com/

Author: Andrew F. Davis <afd@ti.com>

Description
-----------

The Texas Instruments INA3221 monitors voltage, current, and power on the high
side of up to three D.C. power supplies. The INA3221 monitors both shunt drop
and supply voltage, with programmable conversion times and averaging, current
and power are calculated host-side from these.

Sysfs entries
-------------

======================= =======================================================
in[123]_label           Voltage channel labels
in[123]_enable          Voltage channel enable controls
in[123]_input           Bus voltage(mV) channels
curr[123]_input         Current(mA) measurement channels
shunt[123]_resistor     Shunt resistance(uOhm) channels
curr[123]_crit          Critical alert current(mA) setting, activates the
			corresponding alarm when the respective current
			is above this value
curr[123]_crit_alarm    Critical alert current limit exceeded
curr[123]_max           Warning alert current(mA) setting, activates the
			corresponding alarm when the respective current
			average is above this value.
curr[123]_max_alarm     Warning alert current limit exceeded
in[456]_input           Shunt voltage(uV) for channels 1, 2, and 3 respectively
in7_input               Sum of shunt voltage(uV) channels
in7_label               Channel label for sum of shunt voltage
curr4_input             Sum of current(mA) measurement channels,
                        (only available when all channels use the same resistor
                        value for their shunt resistors)
curr4_crit              Critical alert current(mA) setting for sum of current
                        measurements, activates the corresponding alarm
                        when the respective current is above this value
                        (only effective when all channels use the same resistor
                        value for their shunt resistors)
curr4_crit_alarm        Critical alert current limit exceeded for sum of
                        current measurements.
samples                 Number of samples using in the averaging mode.

                        Supports the list of number of samples:

                          1, 4, 16, 64, 128, 256, 512, 1024

update_interval         Data conversion time in millisecond, following:

                          update_interval = C x S x (BC + SC)

                          * C:	number of enabled channels
                          * S:	number of samples
                          * BC:	bus-voltage conversion time in millisecond
                          * SC:	shunt-voltage conversion time in millisecond

                        Affects both Bus- and Shunt-voltage conversion time.
                        Note that setting update_interval to 0ms sets both BC
                        and SC to 140 us (minimum conversion time).
======================= =======================================================


code:
=========================
Linux Hardware Monitoring
=========================

.. toctree::
   :maxdepth: 1

   hwmon-kernel-api
   pmbus-core
   inspur-ipsps1
   submitting-patches
   sysfs-interface
   userspace-tools

Hardware Monitoring Kernel Drivers
==================================

.. toctree::
   :maxdepth: 1

   abituguru
   abituguru3
   acpi_power_meter
   ad7314
   adc128d818
   adm1021
   adm1025
   adm1026
   adm1031
   adm1177
   adm1266
   adm1275
   adm9240
   ads7828
   adt7410
   adt7411
   adt7462
   adt7470
   adt7475
   aht10
   amc6821
   aquacomputer_d5next
   asb100
   asc7621
   aspeed-pwm-tacho
   asus_ec_sensors
   asus_wmi_sensors
   bcm54140
   bel-pfe
   bpa-rs600
   bt1-pvt
   coretemp
   corsair-cpro
   corsair-psu
   da9052
   da9055
   dell-smm-hwmon
   dme1737
   dps920ab
   drivetemp
   ds1621
   ds620
   emc1403
   emc2103
   emc2305
   emc6w201
   f71805f
   f71882fg
   fam15h_power
   fsp-3y
   ftsteutates
   g760a
   g762
   gsc-hwmon
   gl518sm
   hih6130
   ibmaem
   ibm-cffps
   ibmpowernv
   ina209
   ina2xx
   ina238
   ina3221
   intel-m10-bmc-hwmon
   ir35221
   ir38064
   ir36021
   isl68137
   it87
   jc42
   k10temp
   k8temp
   lan966x
   lineage-pem
   lm25066
   lm63
   lm70
   lm73
   lm75
   lm77
   lm78
   lm80
   lm83
   lm85
   lm87
   lm90
   lm92
   lm93
   lm95234
   lm95245
   lochnagar
   lt7182s
   ltc2992
   ltc2945
   ltc2947
   ltc2978
   ltc2990
   ltc3815
   ltc4151
   ltc4215
   ltc4245
   ltc4260
   ltc4261
   max127
   max15301
   max16064
   max16065
   max1619
   max16601
   max1668
   max197
   max20730
   max20751
   max31722
   max31730
   max31760
   max31785
   max31790
   max34440
   max6620
   max6639
   max6642
   max6650
   max6697
   max8688
   mc13783-adc
   mcp3021
   menf21bmc
   mlxreg-fan
   mp2888
   mp2975
   mp5023
   nct6683
   nct6775
   nct7802
   nct7904
   npcm750-pwm-fan
   nsa320
   ntc_thermistor
   nzxt-kraken2
   nzxt-smart2
   occ
   oxp-sensors
   pc87360
   pc87427
   pcf8591
   pim4328
   pli1209bc
   pm6764tr
   peci-cputemp
   peci-dimmtemp
   pmbus
   powr1220
   pxe1610
   pwm-fan
   q54sj108a2
   raspberrypi-hwmon
   sbrmi
   sbtsi_temp
   sch5627
   sch5636
   scpi-hwmon
   sht15
   sht21
   sht3x
   sht4x
   shtc1
   sis5595
   sl28cpld
   smm665
   smpro-hwmon
   smsc47b397
   smsc47m192
   smsc47m1
   sparx5-temp
   stpddc60
   sy7636a-hwmon
   tc654
   tc74
   thmc50
   tmp102
   tmp103
   tmp108
   tmp401
   tmp421
   tmp464
   tmp513
   tps23861
   tps40422
   tps53679
   tps546d24
   twl4030-madc-hwmon
   ucd9000
   ucd9200
   vexpress
   via686a
   vt1211
   w83627ehf
   w83627hf
   w83773g
   w83781d
   w83791d
   w83792d
   w83793
   w83795
   w83l785ts
   w83l786ng
   wm831x
   wm8350
   xgene-hwmon
   xdpe12284
   xdpe152c4
   zl6100

.. only::  subproject and html

   Indices
   =======

   * :ref:`genindex`


code:
Kernel driver inspur-ipsps1
===========================

Supported chips:

  * Inspur Power System power supply unit

Author: John Wang <wangzqbj@inspur.com>

Description
-----------

This driver supports Inspur Power System power supplies. This driver
is a client to the core PMBus driver.

Usage Notes
-----------

This driver does not auto-detect devices. You will have to instantiate the
devices explicitly. Please see Documentation/i2c/instantiating-devices.rst for
details.

Sysfs entries
-------------

The following attributes are supported:

======================= ======================================================
curr1_input		Measured input current
curr1_label		"iin"
curr1_max		Maximum current
curr1_max_alarm		Current high alarm
curr2_input		Measured output current in mA.
curr2_label		"iout1"
curr2_crit		Critical maximum current
curr2_crit_alarm	Current critical high alarm
curr2_max		Maximum current
curr2_max_alarm		Current high alarm

fan1_alarm		Fan 1 warning.
fan1_fault		Fan 1 fault.
fan1_input		Fan 1 speed in RPM.

in1_alarm		Input voltage under-voltage alarm.
in1_input		Measured input voltage in mV.
in1_label		"vin"
in2_input		Measured output voltage in mV.
in2_label		"vout1"
in2_lcrit		Critical minimum output voltage
in2_lcrit_alarm		Output voltage critical low alarm
in2_max			Maximum output voltage
in2_max_alarm		Output voltage high alarm
in2_min			Minimum output voltage
in2_min_alarm		Output voltage low alarm

power1_alarm		Input fault or alarm.
power1_input		Measured input power in uW.
power1_label		"pin"
power1_max		Input power limit
power2_max_alarm	Output power high alarm
power2_max		Output power limit
power2_input		Measured output power in uW.
power2_label		"pout"

temp[1-3]_input		Measured temperature
temp[1-2]_max		Maximum temperature
temp[1-3]_max_alarm	Temperature high alarm

vendor			Manufacturer name
model			Product model
part_number		Product part number
serial_number		Product serial number
fw_version		Firmware version
hw_version		Hardware version
mode			Work mode. Can be set to active or
			standby, when set to standby, PSU will
			automatically switch between standby
			and redundancy mode.
======================= ======================================================


code:
.. SPDX-License-Identifier: GPL-2.0

Kernel driver intel-m10-bmc-hwmon
=================================

Supported chips:

 * Intel MAX 10 BMC for Intel PAC N3000

   Prefix: 'n3000bmc-hwmon'

Author: Xu Yilun <yilun.xu@intel.com>

Description
-----------

This driver adds the temperature, voltage, current and power reading
support for the Intel MAX 10 Board Management Controller (BMC) chip.
The BMC chip is integrated in some Intel Programmable Acceleration
Cards (PAC). It connects to a set of sensor chips to monitor the
sensor data of different components on the board. The BMC firmware is
responsible for sensor data sampling and recording in shared
registers. The host driver reads the sensor data from these shared
registers and exposes them to users as hwmon interfaces.

The BMC chip is implemented using the Intel MAX 10 CPLD. It could be
reprogramed to some variants in order to support different Intel
PACs. The driver is designed to be able to distinguish between the
variants, but now it only supports the BMC for Intel PAC N3000.

Sysfs attributes
----------------

The following attributes are supported:

- Intel MAX 10 BMC for Intel PAC N3000:

======================= =======================================================
tempX_input             Temperature of the component (specified by tempX_label)
tempX_max               Temperature maximum setpoint of the component
tempX_crit              Temperature critical setpoint of the component
tempX_max_hyst          Hysteresis for temperature maximum of the component
tempX_crit_hyst         Hysteresis for temperature critical of the component
temp1_label             "Board Temperature"
temp2_label             "FPGA Die Temperature"
temp3_label             "QSFP0 Temperature"
temp4_label             "QSFP1 Temperature"
temp5_label             "Retimer A Temperature"
temp6_label             "Retimer A SerDes Temperature"
temp7_label             "Retimer B Temperature"
temp8_label             "Retimer B SerDes Temperature"

inX_input               Measured voltage of the component (specified by
                        inX_label)
in0_label               "QSFP0 Supply Voltage"
in1_label               "QSFP1 Supply Voltage"
in2_label               "FPGA Core Voltage"
in3_label               "12V Backplane Voltage"
in4_label               "1.2V Voltage"
in5_label               "12V AUX Voltage"
in6_label               "1.8V Voltage"
in7_label               "3.3V Voltage"

currX_input             Measured current of the component (specified by
                        currX_label)
curr1_label             "FPGA Core Current"
curr2_label             "12V Backplane Current"
curr3_label             "12V AUX Current"

powerX_input            Measured power of the component (specified by
                        powerX_label)
power1_label            "Board Power"

======================= =======================================================

All the attributes are read-only.


code:
Kernel driver ir35221
=====================

Supported chips:
  * Infineon IR35221

    Prefix: 'ir35221'

    Addresses scanned: -

    Datasheet: Datasheet is not publicly available.

Author: Samuel Mendoza-Jonas <sam@mendozajonas.com>

Description
-----------

IR35221 is a Digital DC-DC Multiphase Converter

Usage Notes
-----------

This driver does not probe for PMBus devices. You will have to instantiate
devices explicitly.

Example: the following commands will load the driver for an IR35221
at address 0x70 on I2C bus #4::

	# modprobe ir35221
	# echo ir35221 0x70 > /sys/bus/i2c/devices/i2c-4/new_device

Sysfs attributes
----------------

======================= =======================================================
curr1_label		"iin"
curr1_input		Measured input current
curr1_max		Maximum current
curr1_max_alarm		Current high alarm

curr[2-3]_label		"iout[1-2]"
curr[2-3]_input		Measured output current
curr[2-3]_crit		Critical maximum current
curr[2-3]_crit_alarm	Current critical high alarm
curr[2-3]_highest	Highest output current
curr[2-3]_lowest	Lowest output current
curr[2-3]_max		Maximum current
curr[2-3]_max_alarm	Current high alarm

in1_label		"vin"
in1_input		Measured input voltage
in1_crit		Critical maximum input voltage
in1_crit_alarm		Input voltage critical high alarm
in1_highest		Highest input voltage
in1_lowest		Lowest input voltage
in1_min			Minimum input voltage
in1_min_alarm		Input voltage low alarm

in[2-3]_label		"vout[1-2]"
in[2-3]_input		Measured output voltage
in[2-3]_lcrit		Critical minimum output voltage
in[2-3]_lcrit_alarm	Output voltage critical low alarm
in[2-3]_crit		Critical maximum output voltage
in[2-3]_crit_alarm	Output voltage critical high alarm
in[2-3]_highest		Highest output voltage
in[2-3]_lowest		Lowest output voltage
in[2-3]_max		Maximum output voltage
in[2-3]_max_alarm	Output voltage high alarm
in[2-3]_min		Minimum output voltage
in[2-3]_min_alarm	Output voltage low alarm

power1_label		"pin"
power1_input		Measured input power
power1_alarm		Input power high alarm
power1_max		Input power limit

power[2-3]_label	"pout[1-2]"
power[2-3]_input	Measured output power
power[2-3]_max		Output power limit
power[2-3]_max_alarm	Output power high alarm

temp[1-2]_input		Measured temperature
temp[1-2]_crit		Critical high temperature
temp[1-2]_crit_alarm	Chip temperature critical high alarm
temp[1-2]_highest	Highest temperature
temp[1-2]_lowest	Lowest temperature
temp[1-2]_max		Maximum temperature
temp[1-2]_max_alarm	Chip temperature high alarm
======================= =======================================================


code:
.. SPDX-License-Identifier: GPL-2.0

Kernel driver ir36021
=====================

Supported chips:

  * Infineon IR36021

    Prefix: ir36021
    Addresses scanned: -

    Datasheet: Publicly available at the Infineon website
      https://www.infineon.com/dgdl/ir36021.pdf?fileId=5546d462533600a4015355d0aa2d1775

Authors:
      - Chris Packham <chris.packham@alliedtelesis.co.nz>

Description
-----------

The IR36021 is a dual-loop digital multi-phase buck controller designed for
point of load applications.

Usage Notes
-----------

This driver does not probe for PMBus devices. You will have to instantiate
devices explicitly.

Sysfs attributes
----------------

======================= ===========================
curr1_label             "iin"
curr1_input             Measured input current
curr1_alarm             Input fault alarm

curr2_label             "iout1"
curr2_input             Measured output current
curr2_alarm             Output over-current alarm

in1_label               "vin"
in1_input               Measured input voltage
in1_alarm               Input under-voltage alarm

in2_label               "vout1"
in2_input               Measured output voltage
in2_alarm               Output over-voltage alarm

power1_label            "pin"
power1_input            Measured input power
power1_alarm            Input under-voltage alarm

power2_label            "pout1"
power2_input            Measured output power

temp1_input             Measured temperature
temp1_alarm             Temperature alarm

temp2_input             Measured other loop temperature
temp2_alarm             Temperature alarm
======================= ===========================


code:
Kernel driver ir38064
=====================

Supported chips:

  * Infineon IR38060

    Prefix: 'IR38060'
    Addresses scanned: -

    Datasheet: Publicly available at the Infineon website
      https://www.infineon.com/dgdl/Infineon-IR38060M-DS-v03_16-EN.pdf?fileId=5546d4625c167129015c3291ea9a4cee

  * Infineon IR38064

    Prefix: 'ir38064'
    Addresses scanned: -

    Datasheet: Publicly available at the Infineon website
      https://www.infineon.com/dgdl/Infineon-IR38064MTRPBF-DS-v03_07-EN.pdf?fileId=5546d462584d1d4a0158db0d9efb67ca

  * Infineon IR38164

    Prefix: 'ir38164'
    Addresses scanned: -

    Datasheet: Publicly available at the Infineon website
      https://www.infineon.com/dgdl/Infineon-IR38164M-DS-v02_02-EN.pdf?fileId=5546d462636cc8fb01640046efea1248

  * Infineon ir38263

    Prefix: 'ir38263'
    Addresses scanned: -

    Datasheet:  Publicly available at the Infineon website
      https://www.infineon.com/dgdl/Infineon-IR38263M-DataSheet-v03_05-EN.pdf?fileId=5546d4625b62cd8a015bcf81f90a6e52

Authors:
      - Maxim Sloyko <maxims@google.com>
      - Patrick Venture <venture@google.com>

Description
-----------

IR38x6x are a Single-input Voltage, Synchronous Buck Regulator, DC-DC Converter.

Usage Notes
-----------

This driver does not probe for PMBus devices. You will have to instantiate
devices explicitly.

Sysfs attributes
----------------

======================= ===========================
curr1_label		"iout1"
curr1_input		Measured output current
curr1_crit		Critical maximum current
curr1_crit_alarm	Current critical high alarm
curr1_max		Maximum current
curr1_max_alarm		Current high alarm

in1_label		"vin"
in1_input		Measured input voltage
in1_crit		Critical maximum input voltage
in1_crit_alarm		Input voltage critical high alarm
in1_min			Minimum input voltage
in1_min_alarm		Input voltage low alarm

in2_label		"vout1"
in2_input		Measured output voltage
in2_lcrit		Critical minimum output voltage
in2_lcrit_alarm		Output voltage critical low alarm
in2_crit		Critical maximum output voltage
in2_crit_alarm		Output voltage critical high alarm
in2_max			Maximum output voltage
in2_max_alarm		Output voltage high alarm
in2_min			Minimum output voltage
in2_min_alarm		Output voltage low alarm

power1_label		"pout1"
power1_input		Measured output power

temp1_input		Measured temperature
temp1_crit		Critical high temperature
temp1_crit_alarm	Chip temperature critical high alarm
temp1_max		Maximum temperature
temp1_max_alarm		Chip temperature high alarm
======================= ===========================