code:
Kernel driver pwm-fan
=====================

This driver enables the use of a PWM module to drive a fan. It uses the
generic PWM interface thus it is hardware independent. It can be used on
many SoCs, as long as the SoC supplies a PWM line driver that exposes
the generic PWM API.

Author: Kamil Debski <k.debski@samsung.com>

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

The driver implements a simple interface for driving a fan connected to
a PWM output. It uses the generic PWM interface, thus it can be used with
a range of SoCs. The driver exposes the fan to the user space through
the hwmon's sysfs interface.

The fan rotation speed returned via the optional 'fan1_input' is extrapolated
from the sampled interrupts from the tachometer signal within 1 second.

The driver provides the following sensor accesses in sysfs:

=============== ======= =======================================================
fan1_input	ro	fan tachometer speed in RPM
pwm1_enable	rw	keep enable mode, defines behaviour when pwm1=0
			0 -> disable pwm and regulator
			1 -> enable pwm; if pwm==0, disable pwm, keep regulator enabled
			2 -> enable pwm; if pwm==0, keep pwm and regulator enabled
			3 -> enable pwm; if pwm==0, disable pwm and regulator
pwm1		rw	relative speed (0-255), 255=max. speed.
=============== ======= =======================================================


code:
Kernel driver pxe1610
=====================

Supported chips:

  * Infineon PXE1610

    Prefix: 'pxe1610'

    Addresses scanned: -

    Datasheet: Datasheet is not publicly available.

  * Infineon PXE1110

    Prefix: 'pxe1110'

    Addresses scanned: -

    Datasheet: Datasheet is not publicly available.

  * Infineon PXM1310

    Prefix: 'pxm1310'

    Addresses scanned: -

    Datasheet: Datasheet is not publicly available.

Author: Vijay Khemka <vijaykhemka@fb.com>

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

PXE1610/PXE1110 are Multi-rail/Multiphase Digital Controllers
and compliant to

	- Intel VR13 DC-DC converter specifications.
	- Intel SVID protocol.

Used for Vcore power regulation for Intel VR13 based microprocessors

	- Servers, Workstations, and High-end desktops

PXM1310 is a Multi-rail Controller and it is compliant to

	- Intel VR13 DC-DC converter specifications.
	- Intel SVID protocol.

Used for DDR3/DDR4 Memory power regulation for Intel VR13 and
IMVP8 based systems

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 PXE1610
at address 0x70 on I2C bus #4::

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

It can also be instantiated by declaring in device tree

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

======================  ====================================
curr1_label		"iin"
curr1_input		Measured input current
curr1_alarm		Current high alarm

curr[2-4]_label		"iout[1-3]"
curr[2-4]_input		Measured output current
curr[2-4]_crit		Critical maximum current
curr[2-4]_crit_alarm	Current critical high alarm

in1_label		"vin"
in1_input		Measured input voltage
in1_crit		Critical maximum input voltage
in1_crit_alarm		Input voltage critical high alarm

in[2-4]_label		"vout[1-3]"
in[2-4]_input		Measured output voltage
in[2-4]_lcrit		Critical minimum output voltage
in[2-4]_lcrit_alarm	Output voltage critical low alarm
in[2-4]_crit		Critical maximum output voltage
in[2-4]_crit_alarm	Output voltage critical high alarm

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

power[2-4]_label	"pout[1-3]"
power[2-4]_input	Measured output power

temp[1-3]_input		Measured temperature
temp[1-3]_crit		Critical high temperature
temp[1-3]_crit_alarm	Chip temperature critical high alarm
temp[1-3]_max		Maximum temperature
temp[1-3]_max_alarm	Chip temperature high alarm
======================  ====================================

repo_name: angery/linux


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

Kernel driver q54sj108a2
========================

Supported chips:

  * DELTA Q54SJ108A2NCAH, Q54SJ108A2NCDH, Q54SJ108A2NCPG, Q54SJ108A2NCPH

    Prefix: 'q54sj108a2'

    Addresses scanned: -

    Datasheet: https://filecenter.delta-china.com.cn/products/download/01/0102/datasheet/DS_Q54SJ108A2.pdf

Authors:
    Xiao.ma <xiao.mx.ma@deltaww.com>

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

This driver implements support for DELTA Q54SJ108A2NCAH, Q54SJ108A2NCDH,
Q54SJ108A2NCPG, and Q54SJ108A2NCPH 1/4 Brick DC/DC Regulated Power Module
with PMBus support.

The driver is a client driver to the core PMBus driver.
Please see Documentation/hwmon/pmbus.rst for details on PMBus client drivers.

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
-------------

===================== ===== ==================================================
curr1_alarm           RO    Output current alarm
curr1_input           RO    Output current
curr1_label           RO    'iout1'
in1_alarm             RO    Input voltage alarm
in1_input             RO    Input voltage
in1_label             RO    'vin'
in2_alarm             RO    Output voltage alarm
in2_input             RO    Output voltage
in2_label             RO    'vout1'
temp1_alarm           RO    Temperature alarm
temp1_input           RO    Chip temperature
===================== ===== ==================================================


code:
Kernel driver raspberrypi-hwmon
===============================

Supported boards:

  * Raspberry Pi A+ (via GPIO on SoC)
  * Raspberry Pi B+ (via GPIO on SoC)
  * Raspberry Pi 2 B (via GPIO on SoC)
  * Raspberry Pi 3 B (via GPIO on port expander)
  * Raspberry Pi 3 B+ (via PMIC)

Author: Stefan Wahren <stefan.wahren@i2se.com>

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

This driver periodically polls a mailbox property of the VC4 firmware to detect
undervoltage conditions.

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

======================= ==================
in0_lcrit_alarm		Undervoltage alarm
======================= ==================


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

Kernel driver sbrmi
===================

Supported hardware:

  * Sideband Remote Management Interface (SB-RMI) compliant AMD SoC
    device connected to the BMC via the APML.

    Prefix: 'sbrmi'

    Addresses scanned: This driver doesn't support address scanning.

    To instantiate this driver on an AMD CPU with SB-RMI
    support, the i2c bus number would be the bus connected from the board
    management controller (BMC) to the CPU.
    The SMBus address is really 7 bits. Some vendors and the SMBus
    specification show the address as 8 bits, left justified with the R/W
    bit as a write (0) making bit 0. Some vendors use only the 7 bits
    to describe the address.
    As mentioned in AMD's APML specification, The SB-RMI address is
    normally 78h(0111 100W) or 3Ch(011 1100) for socket 0 and 70h(0111 000W)
    or 38h(011 1000) for socket 1, but it could vary based on hardware
    address select pins.

    Datasheet: The SB-RMI interface and protocol along with the Advanced
               Platform Management Link (APML) Specification is available
               as part of the open source SoC register reference at:

               https://www.amd.com/en/support/tech-docs?keyword=55898

Author: Akshay Gupta <akshay.gupta@amd.com>

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

The APML provides a way to communicate with the SB Remote Management interface
(SB-RMI) module from the external SMBus master that can be used to report socket
power on AMD platforms using mailbox command and resembles a typical 8-pin remote
power sensor's I2C interface to BMC.

This driver implements current power with power cap and power cap max.

sysfs-Interface
---------------
Power sensors can be queried and set via the standard ``hwmon`` interface
on ``sysfs``, under the directory ``/sys/class/hwmon/hwmonX`` for some value
of ``X`` (search for the ``X`` such that ``/sys/class/hwmon/hwmonX/name`` has
content ``sbrmi``)

================ ===== ========================================================
Name             Perm   Description
================ ===== ========================================================
power1_input     RO    Current Power consumed
power1_cap       RW    Power limit can be set between 0 and power1_cap_max
power1_cap_max   RO    Maximum powerlimit calculated and reported by the SMU FW
================ ===== ========================================================

The following example show how the 'Power' attribute from the i2c-addresses
can be monitored using the userspace utilities like ``sensors`` binary::

  # sensors
  sbrmi-i2c-1-38
  Adapter: bcm2835 I2C adapter
  power1:       61.00 W (cap = 225.00 W)

  sbrmi-i2c-1-3c
  Adapter: bcm2835 I2C adapter
  power1:       28.39 W (cap = 224.77 W)
  #

Also, Below shows how get and set the values from sysfs entries individually::
  # cat /sys/class/hwmon/hwmon1/power1_cap_max
  225000000

  # echo 180000000 > /sys/class/hwmon/hwmon1/power1_cap
  # cat /sys/class/hwmon/hwmon1/power1_cap
  180000000


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

Kernel driver sbtsi_temp
========================

Supported hardware:

  * Sideband interface (SBI) Temperature Sensor Interface (SB-TSI)
    compliant AMD SoC temperature device.

    Prefix: 'sbtsi_temp'

    Addresses scanned: This driver doesn't support address scanning.

    To instantiate this driver on an AMD CPU with SB-TSI
    support, the i2c bus number would be the bus connected from the board
    management controller (BMC) to the CPU. The i2c address is specified in
    Section 6.3.1 of the SoC register reference: The SB-TSI address is normally
    98h for socket 0 and 90h for socket 1, but it could vary based on hardware
    address select pins.

    Datasheet: The SB-TSI interface and protocol is available as part of
               the open source SoC register reference at:

	       https://www.amd.com/system/files/TechDocs/56255_OSRR.pdf

               The Advanced Platform Management Link (APML) Specification is
               available at:

	       http://developer.amd.com/wordpress/media/2012/10/41918.pdf

Author: Kun Yi <kunyi@google.com>

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

The SBI temperature sensor interface (SB-TSI) is an emulation of the software
and physical interface of a typical 8-pin remote temperature sensor (RTS) on
AMD SoCs. It implements one temperature sensor with readings and limit
registers encode the temperature in increments of 0.125 from 0 to 255.875.
Limits can be set through the writable thresholds, and if reached will trigger
corresponding alert signals.


code:
Kernel driver sch5627
=====================

Supported chips:

  * SMSC SCH5627

    Prefix: 'sch5627'

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

    Datasheet: Application Note available upon request

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

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

SMSC SCH5627 Super I/O chips include complete hardware monitoring
capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures.

In addition, the SCH5627 exports data describing which temperature sensors
affect the speed of each fan. Setting pwmX_auto_channels_temp to 0 forces
the corresponding fan to full speed until another value is written.

The SMSC SCH5627 hardware monitoring part also contains an integrated
watchdog. In order for this watchdog to function some motherboard specific
initialization most be done by the BIOS, so if the watchdog is not enabled
by the BIOS the sch5627 driver will not register a watchdog device.

The hardware monitoring part of the SMSC SCH5627 is accessed by talking
through an embedded microcontroller. An application note describing the
protocol for communicating with the microcontroller is available upon
request. Please mail me if you want a copy.


code:
Kernel driver sch5636
=====================

Supported chips:

  * SMSC SCH5636

    Prefix: 'sch5636'

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

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

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

SMSC SCH5636 Super I/O chips include an embedded microcontroller for
hardware monitoring solutions, allowing motherboard manufacturers to create
their own custom hwmon solution based upon the SCH5636.

Currently the sch5636 driver only supports the Fujitsu Theseus SCH5636 based
hwmon solution. The sch5636 driver runs a sanity check on loading to ensure
it is dealing with a Fujitsu Theseus and not with another custom SCH5636 based
hwmon solution.

The Fujitsu Theseus can monitor up to 5 voltages, 8 fans and 16
temperatures. Note that the driver detects how many fan headers /
temperature sensors are actually implemented on the motherboard, so you will
likely see fewer temperature and fan inputs.

The Fujitsu Theseus hwmon solution also contains an integrated watchdog.
This watchdog is fully supported by the sch5636 driver.

An application note describing the Theseus' registers, as well as an
application note describing the protocol for communicating with the
microcontroller is available upon request. Please mail me if you want a copy.


code:
Kernel driver scpi-hwmon
========================

Supported chips:

 * Chips based on ARM System Control Processor Interface

   Addresses scanned: -

   Datasheet: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/index.html

Author: Punit Agrawal <punit.agrawal@arm.com>

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

This driver supports hardware monitoring for SoC's based on the ARM
System Control Processor (SCP) implementing the System Control
Processor Interface (SCPI). The following sensor types are supported
by the SCP:

  * temperature
  * voltage
  * current
  * power

The SCP interface provides an API to query the available sensors and
their values which are then exported to userspace by this driver.

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

The driver relies on device tree node to indicate the presence of SCPI
support in the kernel. See
Documentation/devicetree/bindings/firmware/arm,scpi.yaml for details of the
devicetree node.


code:
Kernel driver sht15
===================

Authors:

  * Wouter Horre
  * Jonathan Cameron
  * Vivien Didelot <vivien.didelot@savoirfairelinux.com>
  * Jerome Oufella <jerome.oufella@savoirfairelinux.com>

Supported chips:

  * Sensirion SHT10

    Prefix: 'sht10'

  * Sensirion SHT11

    Prefix: 'sht11'

  * Sensirion SHT15

    Prefix: 'sht15'

  * Sensirion SHT71

    Prefix: 'sht71'

  * Sensirion SHT75

    Prefix: 'sht75'

Datasheet: Publicly available at the Sensirion website

	http://www.sensirion.ch/en/pdf/product_information/Datasheet-humidity-sensor-SHT1x.pdf

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

The SHT10, SHT11, SHT15, SHT71, and SHT75 are humidity and temperature
sensors.

The devices communicate using two GPIO lines.

Supported resolutions for the measurements are 14 bits for temperature and 12
bits for humidity, or 12 bits for temperature and 8 bits for humidity.

The humidity calibration coefficients are programmed into an OTP memory on the
chip. These coefficients are used to internally calibrate the signals from the
sensors. Disabling the reload of those coefficients allows saving 10ms for each
measurement and decrease power consumption, while losing on precision.

Some options may be set via sysfs attributes.

Notes:
  * The regulator supply name is set to "vcc".
  * If a CRC validation fails, a soft reset command is sent, which resets
    status register to its hardware default value, but the driver will try to
    restore the previous device configuration.

Platform data
-------------

* checksum:
  set it to true to enable CRC validation of the readings (default to false).
* no_otp_reload:
  flag to indicate not to reload from OTP (default to false).
* low_resolution:
  flag to indicate the temp/humidity resolution to use (default to false).

Sysfs interface
---------------

================== ==========================================================
temp1_input        temperature input
humidity1_input    humidity input
heater_enable      write 1 in this attribute to enable the on-chip heater,
		   0 to disable it. Be careful not to enable the heater
		   for too long.
temp1_fault        if 1, this means that the voltage is low (below 2.47V) and
		   measurement may be invalid.
humidity1_fault    same as temp1_fault.
================== ==========================================================


code:
Kernel driver sht21
===================

Supported chips:

  * Sensirion SHT21

    Prefix: 'sht21'

    Addresses scanned: none

    Datasheet: Publicly available at the Sensirion website

    https://www.sensirion.com/file/datasheet_sht21

  * Sensirion SHT25

    Prefix: 'sht25'

    Addresses scanned: none

    Datasheet: Publicly available at the Sensirion website

    https://www.sensirion.com/file/datasheet_sht25

Author:

  Urs Fleisch <urs.fleisch@sensirion.com>

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

The SHT21 and SHT25 are humidity and temperature sensors in a DFN package of
only 3 x 3 mm footprint and 1.1 mm height. The difference between the two
devices is the higher level of precision of the SHT25 (1.8% relative humidity,
0.2 degree Celsius) compared with the SHT21 (2.0% relative humidity,
0.3 degree Celsius).

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

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

temp1_input
	- temperature input

humidity1_input
	- humidity input
eic
	- Electronic Identification Code

Notes
-----

The driver uses the default resolution settings of 12 bit for humidity and 14
bit for temperature, which results in typical measurement times of 22 ms for
humidity and 66 ms for temperature. To keep self heating below 0.1 degree
Celsius, the device should not be active for more than 10% of the time,
e.g. maximum two measurements per second at the given resolution.

Different resolutions, the on-chip heater, and using the CRC checksum
are not supported yet.


code:
Kernel driver sht3x
===================

Supported chips:

  * Sensirion SHT3x-DIS

    Prefix: 'sht3x'

    Addresses scanned: none

    Datasheet: https://www.sensirion.com/file/datasheet_sht3x_digital

Author:

  - David Frey <david.frey@sensirion.com>
  - Pascal Sachs <pascal.sachs@sensirion.com>

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

This driver implements support for the Sensirion SHT3x-DIS chip, a humidity
and temperature sensor. Temperature is measured in degrees celsius, relative
humidity is expressed as a percentage. In the sysfs interface, all values are
scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.

The device communicates with the I2C protocol. Sensors can have the I2C
addresses 0x44 or 0x45, depending on the wiring. See
Documentation/i2c/instantiating-devices.rst for methods to instantiate the device.

There are two options configurable by means of sht3x_platform_data:

1. blocking (pull the I2C clock line down while performing the measurement) or
   non-blocking mode. Blocking mode will guarantee the fastest result but
   the I2C bus will be busy during that time. By default, non-blocking mode
   is used. Make sure clock-stretching works properly on your device if you
   want to use blocking mode.
2. high or low accuracy. High accuracy is used by default and using it is
   strongly recommended.

The sht3x sensor supports a single shot mode as well as 5 periodic measure
modes, which can be controlled with the update_interval sysfs interface.
The allowed update_interval in milliseconds are as follows:

    ===== ======= ====================
       0          single shot mode
    2000   0.5 Hz periodic measurement
    1000   1   Hz periodic measurement
     500   2   Hz periodic measurement
     250   4   Hz periodic measurement
     100  10   Hz periodic measurement
    ===== ======= ====================

In the periodic measure mode, the sensor automatically triggers a measurement
with the configured update interval on the chip. When a temperature or humidity
reading exceeds the configured limits, the alert attribute is set to 1 and
the alert pin on the sensor is set to high.
When the temperature and humidity readings move back between the hysteresis
values, the alert bit is set to 0 and the alert pin on the sensor is set to
low.

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

=================== ============================================================
temp1_input:        temperature input
humidity1_input:    humidity input
temp1_max:          temperature max value
temp1_max_hyst:     temperature hysteresis value for max limit
humidity1_max:      humidity max value
humidity1_max_hyst: humidity hysteresis value for max limit
temp1_min:          temperature min value
temp1_min_hyst:     temperature hysteresis value for min limit
humidity1_min:      humidity min value
humidity1_min_hyst: humidity hysteresis value for min limit
temp1_alarm:        alarm flag is set to 1 if the temperature is outside the
		    configured limits. Alarm only works in periodic measure mode
humidity1_alarm:    alarm flag is set to 1 if the humidity is outside the
		    configured limits. Alarm only works in periodic measure mode
heater_enable:      heater enable, heating element removes excess humidity from
		    sensor:

			- 0: turned off
			- 1: turned on
update_interval:    update interval, 0 for single shot, interval in msec
		    for periodic measurement. If the interval is not supported
		    by the sensor, the next faster interval is chosen
=================== ============================================================


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

Kernel driver sht4x
===================

Supported Chips:

  * Sensirion SHT4X

    Prefix: 'sht4x'

    Addresses scanned: None

    Datasheet:

      English: https://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/2_Humidity_Sensors/Datasheets/Sensirion_Humidity_Sensors_SHT4x_Datasheet.pdf

Author: Navin Sankar Velliangiri <navin@linumiz.com>

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

This driver implements support for the Sensirion SHT4x chip, a humidity
and temperature sensor. Temperature is measured in degree celsius, relative
humidity is expressed as a percentage. In sysfs interface, all values are
scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.

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

The device communicates with the I2C protocol. Sensors can have the I2C
address 0x44. See Documentation/i2c/instantiating-devices.rst for methods
to instantiate the device.

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

=============== ============================================
temp1_input     Measured temperature in millidegrees Celcius
humidity1_input Measured humidity in %H
update_interval The minimum interval for polling the sensor,
                in milliseconds. Writable. Must be at least
                2000.
=============== ============================================


code:
Kernel driver shtc1
===================

Supported chips:

  * Sensirion SHTC1

    Prefix: 'shtc1'

    Addresses scanned: none

    Datasheet: https://www.sensirion.com/file/datasheet_shtc1

  * Sensirion SHTW1

    Prefix: 'shtw1'

    Addresses scanned: none

    Datasheet: https://www.sensirion.com/file/datasheet_shtw1

  * Sensirion SHTC3

    Prefix: 'shtc3'

    Addresses scanned: none

    Datasheet: https://www.sensirion.com/file/datasheet_shtc3

Author:

  Johannes Winkelmann <johannes.winkelmann@sensirion.com>

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

This driver implements support for the Sensirion SHTC1, SHTW1, and SHTC3
chips, a humidity and temperature sensor. Temperature is measured in degrees
celsius, relative humidity is expressed as a percentage.

The device communicates with the I2C protocol. All sensors are set to I2C
address 0x70. See Documentation/i2c/instantiating-devices.rst for methods to
instantiate the device.

There are two options configurable by means of shtc1_platform_data:

1. blocking (pull the I2C clock line down while performing the measurement) or
   non-blocking mode. Blocking mode will guarantee the fastest result but
   the I2C bus will be busy during that time. By default, non-blocking mode
   is used. Make sure clock-stretching works properly on your device if you
   want to use blocking mode.
2. high or low accuracy. High accuracy is used by default and using it is
   strongly recommended.

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

temp1_input
	- temperature input
humidity1_input
	- humidity input


code:
Kernel driver sis5595
=====================

Supported chips:

  * Silicon Integrated Systems Corp. SiS5595 Southbridge Hardware Monitor

    Prefix: 'sis5595'

    Addresses scanned: ISA in PCI-space encoded address

    Datasheet: Publicly available at the Silicon Integrated Systems Corp. site.

Authors:

      - Kyösti Mälkki <kmalkki@cc.hut.fi>,
      - Mark D. Studebaker <mdsxyz123@yahoo.com>,
      - Aurelien Jarno <aurelien@aurel32.net> 2.6 port

   SiS southbridge has a LM78-like chip integrated on the same IC.
   This driver is a customized copy of lm78.c

   Supports following revisions:

       =============== =============== ==============
       Version         PCI ID          PCI Revision
       =============== =============== ==============
       1               1039/0008       AF or less
       2               1039/0008       B0 or greater
       =============== =============== ==============

   Note: these chips contain a 0008 device which is incompatible with the
	5595. We recognize these by the presence of the listed
	"blacklist" PCI ID and refuse to load.

   =================== =============== ================
   NOT SUPPORTED       PCI ID          BLACKLIST PCI ID
   =================== =============== ================
	540            0008            0540
	550            0008            0550
       5513            0008            5511
       5581            0008            5597
       5582            0008            5597
       5597            0008            5597
	630            0008            0630
	645            0008            0645
	730            0008            0730
	735            0008            0735
   =================== =============== ================

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

======================= =====================================================
force_addr=0xaddr	Set the I/O base address. Useful for boards
			that don't set the address in the BIOS. Does not do a
			PCI force; the device must still be present in lspci.
			Don't use this unless the driver complains that the
			base address is not set.

			Example: 'modprobe sis5595 force_addr=0x290'
======================= =====================================================

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

The SiS5595 southbridge has integrated hardware monitor functions. It also
has an I2C bus, but this driver only supports the hardware monitor. For the
I2C bus driver see i2c-sis5595.

The SiS5595 implements zero or one temperature sensor, two fan speed
sensors, four or five voltage sensors, and alarms.

On the first version of the chip, there are four voltage sensors and one
temperature sensor.

On the second version of the chip, the temperature sensor (temp) and the
fifth voltage sensor (in4) share a pin which is configurable, but not
through the driver. Sorry. The driver senses the configuration of the pin,
which was hopefully set by the BIOS.

Temperatures are measured in degrees Celsius. An alarm is triggered once
when the max is crossed; it is also triggered when it drops below the min
value. Measurements are guaranteed between -55 and +125 degrees, with a
resolution of 1 degree.

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 2, the lowest
representable value is around 2600 RPM.

Voltage sensors (also known as IN 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. All voltage
inputs can measure voltages between 0 and 4.08 volts, with a resolution of
0.016 volt.

In addition to the alarms described above, there is a BTI alarm, which gets
triggered when an external chip has crossed its limits. Usually, this is
connected to some LM75-like chip; if at least one crosses its limits, this
bit gets set.

If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may already
have disappeared! Note that in the current implementation, all 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 SiS5595 only updates its values each 1.5 seconds; reading it more often
will do no harm, but will return 'old' values.

Problems
--------
Some chips refuse to be enabled. We don't know why.
The driver will recognize this and print a message in dmesg.


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

Kernel driver sl28cpld
======================

Supported chips:

   * Kontron sl28cpld

     Prefix: 'sl28cpld'

     Datasheet: not available

Authors: Michael Walle <michael@walle.cc>

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

The sl28cpld is a board management controller which also exposes a hardware
monitoring controller. At the moment this controller supports a single fan
supervisor. In the future there might be other flavours and additional
hardware monitoring might be supported.

The fan supervisor has a 7 bit counter register and a counter period of 1
second. If the 7 bit counter overflows, the supervisor will automatically
switch to x8 mode to support a wider input range at the loss of
granularity.

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

The following attributes are supported.

======================= ========================================================
fan1_input		Fan RPM. Assuming 2 pulses per revolution.
======================= ========================================================


code:
Kernel driver smm665
====================

Supported chips:

  * Summit Microelectronics SMM465

    Prefix: 'smm465'

    Addresses scanned: -

    Datasheet:

      http://www.summitmicro.com/prod_select/summary/SMM465/SMM465DS.pdf

  * Summit Microelectronics SMM665, SMM665B

    Prefix: 'smm665'

    Addresses scanned: -

    Datasheet:

      http://www.summitmicro.com/prod_select/summary/SMM665/SMM665B_2089_20.pdf

  * Summit Microelectronics SMM665C

    Prefix: 'smm665c'

    Addresses scanned: -

    Datasheet:

      http://www.summitmicro.com/prod_select/summary/SMM665C/SMM665C_2125.pdf

  * Summit Microelectronics SMM764

    Prefix: 'smm764'

    Addresses scanned: -

    Datasheet:

      http://www.summitmicro.com/prod_select/summary/SMM764/SMM764_2098.pdf

  * Summit Microelectronics SMM766, SMM766B

    Prefix: 'smm766'

    Addresses scanned: -

    Datasheets:

      http://www.summitmicro.com/prod_select/summary/SMM766/SMM766_2086.pdf

      http://www.summitmicro.com/prod_select/summary/SMM766B/SMM766B_2122.pdf

Author: Guenter Roeck <linux@roeck-us.net>

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

* vref: int
    Default: 1250 (mV)

    Reference voltage on VREF_ADC pin in mV. It should not be necessary to set
    this parameter unless a non-default reference voltage is used.

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

[From datasheet] The SMM665 is an Active DC Output power supply Controller
that monitors, margins and cascade sequences power. The part monitors six
power supply channels as well as VDD, 12V input, two general-purpose analog
inputs and an internal temperature sensor using a 10-bit ADC.

Each monitored channel has its own high and low limits, plus a critical
limit.

Support for SMM465, SMM764, and SMM766 has been implemented but is untested.

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

This driver does not probe for devices, since there is no register which
can be safely used to identify the chip. You will have to instantiate
the devices explicitly. When instantiating the device, you have to specify
its configuration register address.

Example: the following will load the driver for an SMM665 at address 0x57
on I2C bus #1::

	$ modprobe smm665
	$ echo smm665 0x57 > /sys/bus/i2c/devices/i2c-1/new_device

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

This driver uses the values in the datasheet to convert ADC register values
into the values specified in the sysfs-interface document. All attributes are
read only.

Min, max, lcrit, and crit values are used by the chip to trigger external signals
and/or other activity. Triggered signals can include HEALTHY, RST, Power Off,
or Fault depending on the chip configuration. The driver reports values as lcrit
or crit if exceeding the limits triggers RST, Power Off, or Fault, and as min or
max otherwise. For details please see the SMM665 datasheet.

For SMM465 and SMM764, values for Channel E and F are reported but undefined.

======================= =======================================================
in1_input		12V input voltage (mV)
in2_input		3.3V (VDD) input voltage (mV)
in3_input		Channel A voltage (mV)
in4_input		Channel B voltage (mV)
in5_input		Channel C voltage (mV)
in6_input		Channel D voltage (mV)
in7_input		Channel E voltage (mV)
in8_input		Channel F voltage (mV)
in9_input		AIN1 voltage (mV)
in10_input		AIN2 voltage (mV)

in1_min			12v input minimum voltage (mV)
in2_min			3.3V (VDD) input minimum voltage (mV)
in3_min			Channel A minimum voltage (mV)
in4_min			Channel B minimum voltage (mV)
in5_min			Channel C minimum voltage (mV)
in6_min			Channel D minimum voltage (mV)
in7_min			Channel E minimum voltage (mV)
in8_min			Channel F minimum voltage (mV)
in9_min			AIN1 minimum voltage (mV)
in10_min		AIN2 minimum voltage (mV)

in1_max			12v input maximum voltage (mV)
in2_max			3.3V (VDD) input maximum voltage (mV)
in3_max			Channel A maximum voltage (mV)
in4_max			Channel B maximum voltage (mV)
in5_max			Channel C maximum voltage (mV)
in6_max			Channel D maximum voltage (mV)
in7_max			Channel E maximum voltage (mV)
in8_max			Channel F maximum voltage (mV)
in9_max			AIN1 maximum voltage (mV)
in10_max		AIN2 maximum voltage (mV)

in1_lcrit		12v input critical minimum voltage (mV)
in2_lcrit		3.3V (VDD) input critical minimum voltage (mV)
in3_lcrit		Channel A critical minimum voltage (mV)
in4_lcrit		Channel B critical minimum voltage (mV)
in5_lcrit		Channel C critical minimum voltage (mV)
in6_lcrit		Channel D critical minimum voltage (mV)
in7_lcrit		Channel E critical minimum voltage (mV)
in8_lcrit		Channel F critical minimum voltage (mV)
in9_lcrit		AIN1 critical minimum voltage (mV)
in10_lcrit		AIN2 critical minimum voltage (mV)

in1_crit		12v input critical maximum voltage (mV)
in2_crit		3.3V (VDD) input critical maximum voltage (mV)
in3_crit		Channel A critical maximum voltage (mV)
in4_crit		Channel B critical maximum voltage (mV)
in5_crit		Channel C critical maximum voltage (mV)
in6_crit		Channel D critical maximum voltage (mV)
in7_crit		Channel E critical maximum voltage (mV)
in8_crit		Channel F critical maximum voltage (mV)
in9_crit		AIN1 critical maximum voltage (mV)
in10_crit		AIN2 critical maximum voltage (mV)

in1_crit_alarm		12v input critical alarm
in2_crit_alarm		3.3V (VDD) input critical alarm
in3_crit_alarm		Channel A critical alarm
in4_crit_alarm		Channel B critical alarm
in5_crit_alarm		Channel C critical alarm
in6_crit_alarm		Channel D critical alarm
in7_crit_alarm		Channel E critical alarm
in8_crit_alarm		Channel F critical alarm
in9_crit_alarm		AIN1 critical alarm
in10_crit_alarm		AIN2 critical alarm

temp1_input		Chip temperature
temp1_min		Mimimum chip temperature
temp1_max		Maximum chip temperature
temp1_crit		Critical chip temperature
temp1_crit_alarm	Temperature critical alarm
======================= =======================================================


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

Kernel driver Ampere(R)'s Altra(R) SMpro hwmon
==============================================

Supported chips:

  * Ampere(R) Altra(R)

    Prefix: ``smpro``

    Reference: `Altra SoC BMC Interface Specification`

Author: Thu Nguyen <thu@os.amperecomputing.com>

Description
-----------
The smpro-hwmon driver supports hardware monitoring for Ampere(R) Altra(R)
SoCs based on the SMpro co-processor (SMpro).  The following sensor metrics
are supported by the driver:

  * temperature
  * voltage
  * current
  * power

The interface provides the registers to query the various sensors and
their values which are then exported to userspace by this driver.

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

The driver creates at least two sysfs files for each sensor.

* ``<sensor_type><idx>_label`` reports the sensor label.
* ``<sensor_type><idx>_input`` returns the sensor value.

The sysfs files are allocated in the SMpro rootfs folder, with one root
directory for each instance.

When the SoC is turned off, the driver will fail to read registers and
return ``-ENXIO``.

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

The following sysfs files are supported:

* Ampere(R) Altra(R):

  ============    =============  ======  ===============================================
  Name            Unit           Perm    Description
  ============    =============  ======  ===============================================
  temp1_input     millicelsius   RO      SoC temperature
  temp2_input     millicelsius   RO      Max temperature reported among SoC VRDs
  temp2_crit      millicelsius   RO      SoC VRD HOT Threshold temperature
  temp3_input     millicelsius   RO      Max temperature reported among DIMM VRDs
  temp4_input     millicelsius   RO      Max temperature reported among Core VRDs
  temp5_input     millicelsius   RO      Temperature of DIMM0 on CH0
  temp5_crit      millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp6_input     millicelsius   RO      Temperature of DIMM0 on CH1
  temp6_crit      millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp7_input     millicelsius   RO      Temperature of DIMM0 on CH2
  temp7_crit      millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp8_input     millicelsius   RO      Temperature of DIMM0 on CH3
  temp8_crit      millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp9_input     millicelsius   RO      Temperature of DIMM0 on CH4
  temp9_crit      millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp10_input    millicelsius   RO      Temperature of DIMM0 on CH5
  temp10_crit     millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp11_input    millicelsius   RO      Temperature of DIMM0 on CH6
  temp11_crit     millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp12_input    millicelsius   RO      Temperature of DIMM0 on CH7
  temp12_crit     millicelsius   RO      MEM HOT Threshold for all DIMMs
  temp13_input    millicelsius   RO      Max temperature reported among RCA VRDs
  in0_input       millivolts     RO      Core voltage
  in1_input       millivolts     RO      SoC voltage
  in2_input       millivolts     RO      DIMM VRD1 voltage
  in3_input       millivolts     RO      DIMM VRD2 voltage
  in4_input       millivolts     RO      RCA VRD voltage
  cur1_input      milliamperes   RO      Core VRD current
  cur2_input      milliamperes   RO      SoC VRD current
  cur3_input      milliamperes   RO      DIMM VRD1 current
  cur4_input      milliamperes   RO      DIMM VRD2 current
  cur5_input      milliamperes   RO      RCA VRD current
  power1_input    microwatts     RO      Core VRD power
  power2_input    microwatts     RO      SoC VRD power
  power3_input    microwatts     RO      DIMM VRD1 power
  power4_input    microwatts     RO      DIMM VRD2 power
  power5_input    microwatts     RO      RCA VRD power
  ============    =============  ======  ===============================================

  Example::

    # cat in0_input
    830
    # cat temp1_input
    37000
    # cat curr1_input
    9000
    # cat power5_input
    19500000


code:
Kernel driver smsc47b397
========================

Supported chips:

  * SMSC LPC47B397-NC

  * SMSC SCH5307-NS

  * SMSC SCH5317

    Prefix: 'smsc47b397'

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

    Datasheet: In this file

Authors:

       - Mark M. Hoffman <mhoffman@lightlink.com>
       - Utilitek Systems, Inc.

November 23, 2004

The following specification describes the SMSC LPC47B397-NC [1]_ sensor chip
(for which there is no public datasheet available). This document was
provided by Craig Kelly (In-Store Broadcast Network) and edited/corrected
by Mark M. Hoffman <mhoffman@lightlink.com>.

.. [1] And SMSC SCH5307-NS and SCH5317, which have different device IDs but are
       otherwise compatible.

-------------------------------------------------------------------------

Methods for detecting the HP SIO and reading the thermal data on a dc7100
-------------------------------------------------------------------------

The thermal information on the dc7100 is contained in the SIO Hardware Monitor
(HWM). The information is accessed through an index/data pair. The index/data
pair is located at the HWM Base Address + 0 and the HWM Base Address + 1. The
HWM Base address can be obtained from Logical Device 8, registers 0x60 (MSB)
and 0x61 (LSB). Currently we are using 0x480 for the HWM Base Address and
0x480 and 0x481 for the index/data pair.

Reading temperature information.
The temperature information is located in the following registers:

=============== ======= =======================================================
Temp1		0x25	(Currently, this reflects the CPU temp on all systems).
Temp2		0x26
Temp3		0x27
Temp4		0x80
=============== ======= =======================================================

Programming Example
The following is an example of how to read the HWM temperature registers::

	MOV	DX,480H
	MOV	AX,25H
	OUT	DX,AL
	MOV	DX,481H
	IN	AL,DX

AL contains the data in hex, the temperature in Celsius is the decimal
equivalent.

Ex: If AL contains 0x2A, the temperature is 42 degrees C.

Reading tach information.
The fan speed information is located in the following registers:

=============== ======= ======= =================================
		LSB	MSB
Tach1		0x28	0x29	(Currently, this reflects the CPU
				fan speed on all systems).
Tach2		0x2A	0x2B
Tach3		0x2C	0x2D
Tach4		0x2E	0x2F
=============== ======= ======= =================================

.. Important::

	Reading the tach LSB locks the tach MSB.
	The LSB Must be read first.

How to convert the tach reading to RPM
--------------------------------------

The tach reading (TCount) is given by: (Tach MSB * 256) + (Tach LSB)
The SIO counts the number of 90kHz (11.111us) pulses per revolution.
RPM = 60/(TCount * 11.111us)

Example::

	Reg 0x28 = 0x9B
	Reg 0x29 = 0x08

TCount = 0x89B = 2203

RPM = 60 / (2203 * 11.11111 E-6) = 2451 RPM

Obtaining the SIO version.

Configuration Sequence
----------------------

To program the configuration registers, the following sequence must be followed:
1. Enter Configuration Mode
2. Configure the Configuration Registers
3. Exit Configuration Mode.

Enter Configuration Mode
^^^^^^^^^^^^^^^^^^^^^^^^

To place the chip into the Configuration State The config key (0x55) is written
to the CONFIG PORT (0x2E).

Configuration Mode
^^^^^^^^^^^^^^^^^^

In configuration mode, the INDEX PORT is located at the CONFIG PORT address and
the DATA PORT is at INDEX PORT address + 1.

The desired configuration registers are accessed in two steps:

a.	Write the index of the Logical Device Number Configuration Register
	(i.e., 0x07) to the INDEX PORT and then write the number of the
	desired logical device to the DATA PORT.

b.	Write the address of the desired configuration register within the
	logical device to the INDEX PORT and then write or read the config-
	uration register through the DATA PORT.

Note:
	If accessing the Global Configuration Registers, step (a) is not required.

Exit Configuration Mode
^^^^^^^^^^^^^^^^^^^^^^^

To exit the Configuration State the write 0xAA to the CONFIG PORT (0x2E).
The chip returns to the RUN State.  (This is important).

Programming Example
^^^^^^^^^^^^^^^^^^^

The following is an example of how to read the SIO Device ID located at 0x20:

	; ENTER CONFIGURATION MODE
	MOV	DX,02EH
	MOV	AX,055H
	OUT	DX,AL
	; GLOBAL CONFIGURATION  REGISTER
	MOV	DX,02EH
	MOV	AL,20H
	OUT	DX,AL
	; READ THE DATA
	MOV	DX,02FH
	IN	AL,DX
	; EXIT CONFIGURATION MODE
	MOV	DX,02EH
	MOV	AX,0AAH
	OUT	DX,AL

The registers of interest for identifying the SIO on the dc7100 are Device ID
(0x20) and Device Rev  (0x21).

The Device ID will read 0x6F (0x81 for SCH5307-NS, and 0x85 for SCH5317)
The Device Rev currently reads 0x01

Obtaining the HWM Base Address
------------------------------

The following is an example of how to read the HWM Base Address located in
Logical Device 8::

	; ENTER CONFIGURATION MODE
	MOV	DX,02EH
	MOV	AX,055H
	OUT	DX,AL
	; CONFIGURE REGISTER CRE0,
	; LOGICAL DEVICE 8
	MOV	DX,02EH
	MOV	AL,07H
	OUT	DX,AL ;Point to LD# Config Reg
	MOV	DX,02FH
	MOV	AL, 08H
	OUT	DX,AL;Point to Logical Device 8
	;
	MOV	DX,02EH
	MOV	AL,60H
	OUT	DX,AL	; Point to HWM Base Addr MSB
	MOV	DX,02FH
	IN	AL,DX	; Get MSB of HWM Base Addr
	; EXIT CONFIGURATION MODE
	MOV	DX,02EH
	MOV	AX,0AAH
	OUT	DX,AL


code:
Kernel driver smsc47m1
======================

Supported chips:

  * SMSC LPC47B27x, LPC47M112, LPC47M10x, LPC47M13x, LPC47M14x,

    LPC47M15x and LPC47M192

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

    Prefix: 'smsc47m1'

    Datasheets:

	http://www.smsc.com/media/Downloads_Public/Data_Sheets/47b272.pdf

	http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m10x.pdf

	http://www.smsc.com/media/Downloads_Public/Data_Sheets/47m112.pdf

	http://www.smsc.com/

  * SMSC LPC47M292

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

    Prefix: 'smsc47m2'

    Datasheet: Not public

  * SMSC LPC47M997

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

    Prefix: 'smsc47m1'

    Datasheet: none

Authors:

     - Mark D. Studebaker <mdsxyz123@yahoo.com>,
     - With assistance from Bruce Allen <ballen@uwm.edu>, and his
       fan.c program:

       - http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/

     - Gabriele Gorla <gorlik@yahoo.com>,
     - Jean Delvare <jdelvare@suse.de>

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

The Standard Microsystems Corporation (SMSC) 47M1xx Super I/O chips
contain monitoring and PWM control circuitry for two fans.

The LPC47M15x, LPC47M192 and LPC47M292 chips contain a full 'hardware
monitoring block' in addition to the fan monitoring and control. The
hardware monitoring block is not supported by this driver, use the
smsc47m192 driver for that.

No documentation is available for the 47M997, but it has the same device
ID as the 47M15x and 47M192 chips and seems to be compatible.

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 2, the lowest
representable value is around 2600 RPM.

PWM values are from 0 to 255.

If an alarm triggers, it will remain triggered until the hardware register
is read at least once. This means that the cause for the alarm may
already have disappeared! Note that in the current implementation, all
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 lm_sensors project gratefully acknowledges the support of
Intel in the development of this driver.


code:
Kernel driver smsc47m192
========================

Supported chips:

  * SMSC LPC47M192, LPC47M15x, LPC47M292 and LPC47M997

    Prefix: 'smsc47m192'

    Addresses scanned: I2C 0x2c - 0x2d

    Datasheet: The datasheet for LPC47M192 is publicly available from

	       http://www.smsc.com/

	       The LPC47M15x, LPC47M292 and LPC47M997 are compatible for

	       hardware monitoring.

Author:
      - Hartmut Rick <linux@rick.claranet.de>

      - Special thanks to Jean Delvare for careful checking
	of the code and many helpful comments and suggestions.

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

This driver implements support for the hardware sensor capabilities
of the SMSC LPC47M192 and compatible Super-I/O chips.

These chips support 3 temperature channels and 8 voltage inputs
as well as CPU voltage VID input.

They do also have fan monitoring and control capabilities, but the
these features are accessed via ISA bus and are not supported by this
driver. Use the 'smsc47m1' driver for fan monitoring and control.

Voltages and temperatures are measured by an 8-bit ADC, the resolution
of the temperatures is 1 bit per degree C.
Voltages are scaled such that the nominal voltage corresponds to
192 counts, i.e. 3/4 of the full range. Thus the available range for
each voltage channel is 0V ... 255/192*(nominal voltage), the resolution
is 1 bit per (nominal voltage)/192.
Both voltage and temperature values are scaled by 1000, the sys files
show voltages in mV and temperatures in units of 0.001 degC.

The +12V analog voltage input channel (in4_input) is multiplexed with
bit 4 of the encoded CPU voltage. This means that you either get
a +12V voltage measurement or a 5 bit CPU VID, but not both.
The default setting is to use the pin as 12V input, and use only 4 bit VID.
This driver assumes that the information in the configuration register
is correct, i.e. that the BIOS has updated the configuration if
the motherboard has this input wired to VID4.

The temperature and voltage readings are updated once every 1.5 seconds.
Reading them more often repeats the same values.

sysfs interface
---------------

===================== ==========================================================
in0_input	      +2.5V voltage input
in1_input	      CPU voltage input (nominal 2.25V)
in2_input	      +3.3V voltage input
in3_input	      +5V voltage input
in4_input	      +12V voltage input (may be missing if used as VID4)
in5_input	      Vcc voltage input (nominal 3.3V)
		      This is the supply voltage of the sensor chip itself.
in6_input	      +1.5V voltage input
in7_input	      +1.8V voltage input

in[0-7]_min,
in[0-7]_max	      lower and upper alarm thresholds for in[0-7]_input reading

		      All voltages are read and written in mV.

in[0-7]_alarm	      alarm flags for voltage inputs
		      These files read '1' in case of alarm, '0' otherwise.

temp1_input	      chip temperature measured by on-chip diode
temp[2-3]_input	      temperature measured by external diodes (one of these
		      would typically be wired to the diode inside the CPU)

temp[1-3]_min,
temp[1-3]_max	      lower and upper alarm thresholds for temperatures

temp[1-3]_offset      temperature offset registers
		      The chip adds the offsets stored in these registers to
		      the corresponding temperature readings.
		      Note that temp1 and temp2 offsets share the same register,
		      they cannot both be different from zero at the same time.
		      Writing a non-zero number to one of them will reset the other
		      offset to zero.

		      All temperatures and offsets are read and written in
		      units of 0.001 degC.

temp[1-3]_alarm       alarm flags for temperature inputs, '1' in case of alarm,
		      '0' otherwise.
temp[2-3]_input_fault diode fault flags for temperature inputs 2 and 3.
		      A fault is detected if the two pins for the corresponding
		      sensor are open or shorted, or any of the two is shorted
		      to ground or Vcc. '1' indicates a diode fault.

cpu0_vid	      CPU voltage as received from the CPU

vrm		      CPU VID standard used for decoding CPU voltage
===================== ==========================================================

The `*_min`, `*_max`, `*_offset` and `vrm` files can be read and written,
all others are read-only.


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

Microchip SparX-5 SoC
=====================

Supported chips:

  * VSC7546, VSC7549, VSC755, VSC7556, and VSC7558 (Sparx5 series)

    Prefix: 'sparx5-temp'

    Addresses scanned: -

    Datasheet: Provided by Microchip upon request and under NDA

Author: Lars Povlsen <lars.povlsen@microchip.com>

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

The Sparx5 SoC contains a temperature sensor based on the MR74060
Moortec IP.

The sensor has a range of -40°C to +125°C and an accuracy of +/-5°C.

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

The following attributes are supported.

======================= ========================================================
temp1_input		Die temperature (in millidegree Celsius.)
======================= ========================================================


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

Kernel driver stpddc60
======================

Supported chips:

  * ST STPDDC60

    Prefix: 'stpddc60', 'bmr481'

    Addresses scanned: -

    Datasheet: https://flexpowermodules.com/documents/fpm-techspec-bmr481

Author: Erik Rosen <erik.rosen@metormote.com>

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

This driver supports hardware monitoring for ST STPDDC60 controller chip and
compatible modules.

The driver is a client driver to the core PMBus driver. Please see
Documentation/hwmon/pmbus.rst and Documentation.hwmon/pmbus-core for details
on PMBus client drivers.

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.

The vout under- and over-voltage limits are set in relation to the commanded
output voltage as a positive or negative offset in the interval 50mV to 400mV
in 50mV steps. This means that the absolute values of the limits will change
when the commanded output voltage changes. Also, care should be taken when
writing to those limits since in the worst case the commanded output voltage
could change at the same time as the limit is written to, wich will lead to
unpredictable results.

Platform data support
---------------------

The driver supports standard PMBus driver platform data.

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

The following attributes are supported. Vin, iout, pout and temp limits
are read-write; all other attributes are read-only.

======================= ========================================================
in1_label		"vin"
in1_input		Measured input voltage.
in1_lcrit		Critical minimum input voltage.
in1_crit		Critical maximum input voltage.
in1_lcrit_alarm		Input voltage critical low alarm.
in1_crit_alarm		Input voltage critical high alarm.

in2_label		"vout1"
in2_input		Measured output voltage.
in2_lcrit		Critical minimum output voltage.
in2_crit		Critical maximum output voltage.
in2_lcrit_alarm		Critical output voltage critical low alarm.
in2_crit_alarm		Critical output voltage critical high alarm.

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

power1_label		"pout1"
power1_input		Measured output power.
power1_crit		Critical maximum output power.
power1_crit_alarm	Output power critical high alarm.

temp1_input		Measured maximum temperature of all phases.
temp1_max		Maximum temperature limit.
temp1_max_alarm		High temperature alarm.
temp1_crit		Critical maximum temperature limit.
temp1_crit_alarm	Critical maximum temperature alarm.
======================= ========================================================


code:
How to Get Your Patch Accepted Into the Hwmon Subsystem
=======================================================

This text is a collection of suggestions for people writing patches or
drivers for the hwmon subsystem. Following these suggestions will greatly
increase the chances of your change being accepted.

1. General
----------

* It should be unnecessary to mention, but please read and follow:

    - Documentation/process/submit-checklist.rst
    - Documentation/process/submitting-patches.rst
    - Documentation/process/coding-style.rst

* Please run your patch through 'checkpatch --strict'. There should be no
  errors, no warnings, and few if any check messages. If there are any
  messages, please be prepared to explain.

* Please use the standard multi-line comment style. Do not mix C and C++
  style comments in a single driver (with the exception of the SPDX license
  identifier).

* If your patch generates checkpatch errors, warnings, or check messages,
  please refrain from explanations such as "I prefer that coding style".
  Keep in mind that each unnecessary message helps hiding a real problem,
  and a consistent coding style makes it easier for others to understand
  and review the code.

* Please test your patch thoroughly. We are not your test group.
  Sometimes a patch can not or not completely be tested because of missing
  hardware. In such cases, you should test-build the code on at least one
  architecture. If run-time testing was not achieved, it should be written
  explicitly below the patch header.

* If your patch (or the driver) is affected by configuration options such as
  CONFIG_SMP, make sure it compiles for all configuration variants.

2. Adding functionality to existing drivers
-------------------------------------------

* Make sure the documentation in Documentation/hwmon/<driver_name>.rst is up to
  date.

* Make sure the information in Kconfig is up to date.

* If the added functionality requires some cleanup or structural changes, split
  your patch into a cleanup part and the actual addition. This makes it easier
  to review your changes, and to bisect any resulting problems.

* Never mix bug fixes, cleanup, and functional enhancements in a single patch.

3. New drivers
--------------

* Running your patch or driver file(s) through checkpatch does not mean its
  formatting is clean. If unsure about formatting in your new driver, run it
  through Lindent. Lindent is not perfect, and you may have to do some minor
  cleanup, but it is a good start.

* Consider adding yourself to MAINTAINERS.

* Document the driver in Documentation/hwmon/<driver_name>.rst.

* Add the driver to Kconfig and Makefile in alphabetical order.

* Make sure that all dependencies are listed in Kconfig.

* Please list include files in alphabetic order.

* Please align continuation lines with '(' on the previous line.

* Avoid forward declarations if you can. Rearrange the code if necessary.

* Avoid macros to generate groups of sensor attributes. It not only confuses
  checkpatch, but also makes it more difficult to review the code.

* Avoid calculations in macros and macro-generated functions. While such macros
  may save a line or so in the source, it obfuscates the code and makes code
  review more difficult. It may also result in code which is more complicated
  than necessary. Use inline functions or just regular functions instead.

* Limit the number of kernel log messages. In general, your driver should not
  generate an error message just because a runtime operation failed. Report
  errors to user space instead, using an appropriate error code. Keep in mind
  that kernel error log messages not only fill up the kernel log, but also are
  printed synchronously, most likely with interrupt disabled, often to a serial
  console. Excessive logging can seriously affect system performance.

* Use devres functions whenever possible to allocate resources. For rationale
  and supported functions, please see Documentation/driver-api/driver-model/devres.rst.
  If a function is not supported by devres, consider using devm_add_action().

* If the driver has a detect function, make sure it is silent. Debug messages
  and messages printed after a successful detection are acceptable, but it
  must not print messages such as "Chip XXX not found/supported".

  Keep in mind that the detect function will run for all drivers supporting an
  address if a chip is detected on that address. Unnecessary messages will just
  pollute the kernel log and not provide any value.

* Provide a detect function if and only if a chip can be detected reliably.

* Only the following I2C addresses shall be probed: 0x18-0x1f, 0x28-0x2f,
  0x48-0x4f, 0x58, 0x5c, 0x73 and 0x77. Probing other addresses is strongly
  discouraged as it is known to cause trouble with other (non-hwmon) I2C
  chips. If your chip lives at an address which can't be probed then the
  device will have to be instantiated explicitly (which is always better
  anyway.)

* Avoid writing to chip registers in the detect function. If you have to write,
  only do it after you have already gathered enough data to be certain that the
  detection is going to be successful.

  Keep in mind that the chip might not be what your driver believes it is, and
  writing to it might cause a bad misconfiguration.

* Make sure there are no race conditions in the probe function. Specifically,
  completely initialize your chip and your driver first, then register with
  the hwmon subsystem.

* Use devm_hwmon_device_register_with_info() or, if your driver needs a remove
  function, hwmon_device_register_with_info() to register your driver with the
  hwmon subsystem. Try using devm_add_action() instead of a remove function if
  possible. Do not use hwmon_device_register().

* Your driver should be buildable as module. If not, please be prepared to
  explain why it has to be built into the kernel.

* Do not provide support for deprecated sysfs attributes.

* Do not create non-standard attributes unless really needed. If you have to use
  non-standard attributes, or you believe you do, discuss it on the mailing list
  first. Either case, provide a detailed explanation why you need the
  non-standard attribute(s).
  Standard attributes are specified in Documentation/hwmon/sysfs-interface.rst.

* When deciding which sysfs attributes to support, look at the chip's
  capabilities. While we do not expect your driver to support everything the
  chip may offer, it should at least support all limits and alarms.

* Last but not least, please check if a driver for your chip already exists
  before starting to write a new driver. Especially for temperature sensors,
  new chips are often variants of previously released chips. In some cases,
  a presumably new chip may simply have been relabeled.


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

Kernel driver sy7636a-hwmon
===========================

Supported chips:

 * Silergy SY7636A PMIC

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

This driver adds hardware temperature reading support for
the Silergy SY7636A PMIC.

The following sensors are supported

  * Temperature
      - SoC on-die temperature in milli-degree C

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

temp0_input
	- SoC on-die temperature (milli-degree C)


code:
Naming and data format standards for sysfs files
================================================

The libsensors library offers an interface to the raw sensors data
through the sysfs interface. Since lm-sensors 3.0.0, libsensors is
completely chip-independent. It assumes that all the kernel drivers
implement the standard sysfs interface described in this document.
This makes adding or updating support for any given chip very easy, as
libsensors, and applications using it, do not need to be modified.
This is a major improvement compared to lm-sensors 2.

Note that motherboards vary widely in the connections to sensor chips.
There is no standard that ensures, for example, that the second
temperature sensor is connected to the CPU, or that the second fan is on
the CPU. Also, some values reported by the chips need some computation
before they make full sense. For example, most chips can only measure
voltages between 0 and +4V. Other voltages are scaled back into that
range using external resistors. Since the values of these resistors
can change from motherboard to motherboard, the conversions cannot be
hard coded into the driver and have to be done in user space.

For this reason, even if we aim at a chip-independent libsensors, it will
still require a configuration file (e.g. /etc/sensors.conf) for proper
values conversion, labeling of inputs and hiding of unused inputs.

An alternative method that some programs use is to access the sysfs
files directly. This document briefly describes the standards that the
drivers follow, so that an application program can scan for entries and
access this data in a simple and consistent way. That said, such programs
will have to implement conversion, labeling and hiding of inputs. For
this reason, it is still not recommended to bypass the library.

Each chip gets its own directory in the sysfs /sys/devices tree.  To
find all sensor chips, it is easier to follow the device symlinks from
`/sys/class/hwmon/hwmon*`.

Up to lm-sensors 3.0.0, libsensors looks for hardware monitoring attributes
in the "physical" device directory. Since lm-sensors 3.0.1, attributes found
in the hwmon "class" device directory are also supported. Complex drivers
(e.g. drivers for multifunction chips) may want to use this possibility to
avoid namespace pollution. The only drawback will be that older versions of
libsensors won't support the driver in question.

All sysfs values are fixed point numbers.

There is only one value per file, unlike the older /proc specification.
The common scheme for files naming is: <type><number>_<item>. Usual
types for sensor chips are "in" (voltage), "temp" (temperature) and
"fan" (fan). Usual items are "input" (measured value), "max" (high
threshold, "min" (low threshold). Numbering usually starts from 1,
except for voltages which start from 0 (because most data sheets use
this). A number is always used for elements that can be present more
than once, even if there is a single element of the given type on the
specific chip. Other files do not refer to a specific element, so
they have a simple name, and no number.

Alarms are direct indications read from the chips. The drivers do NOT
make comparisons of readings to thresholds. This allows violations
between readings to be caught and alarmed. The exact definition of an
alarm (for example, whether a threshold must be met or must be exceeded
to cause an alarm) is chip-dependent.

When setting values of hwmon sysfs attributes, the string representation of
the desired value must be written, note that strings which are not a number
are interpreted as 0! For more on how written strings are interpreted see the
"sysfs attribute writes interpretation" section at the end of this file.

Attribute access
----------------

Hardware monitoring sysfs attributes are displayed by unrestricted userspace
applications. For this reason, all standard ABI attributes shall be world
readable. Writeable standard ABI attributes shall be writeable only for
privileged users.

-------------------------------------------------------------------------

======= ===========================================
`[0-*]`	denotes any positive number starting from 0
`[1-*]`	denotes any positive number starting from 1
RO	read only value
WO	write only value
RW	read/write value
======= ===========================================

Read/write values may be read-only for some chips, depending on the
hardware implementation.

All entries (except name) are optional, and should only be created in a
given driver if the chip has the feature.

See Documentation/ABI/testing/sysfs-class-hwmon for a complete description
of the attributes.

*****************
Global attributes
*****************

`name`
		The chip name.

`label`
		A descriptive label that allows to uniquely identify a device
		within the system.

`update_interval`
		The interval at which the chip will update readings.

********
Voltages
********

`in[0-*]_min`
		Voltage min value.

`in[0-*]_lcrit`
		Voltage critical min value.

`in[0-*]_max`
		Voltage max value.

`in[0-*]_crit`
		Voltage critical max value.

`in[0-*]_input`
		Voltage input value.

`in[0-*]_average`
		Average voltage

`in[0-*]_lowest`
		Historical minimum voltage

`in[0-*]_highest`
		Historical maximum voltage

`in[0-*]_reset_history`
		Reset inX_lowest and inX_highest

`in_reset_history`
		Reset inX_lowest and inX_highest for all sensors

`in[0-*]_label`
		Suggested voltage channel label.

`in[0-*]_enable`
		Enable or disable the sensors.

`cpu[0-*]_vid`
		CPU core reference voltage.

`vrm`
		Voltage Regulator Module version number.

`in[0-*]_rated_min`
		Minimum rated voltage.

`in[0-*]_rated_max`
		Maximum rated voltage.

Also see the Alarms section for status flags associated with voltages.

****
Fans
****

`fan[1-*]_min`
		Fan minimum value

`fan[1-*]_max`
		Fan maximum value

`fan[1-*]_input`
		Fan input value.

`fan[1-*]_div`
		Fan divisor.

`fan[1-*]_pulses`
		Number of tachometer pulses per fan revolution.

`fan[1-*]_target`
		Desired fan speed

`fan[1-*]_label`
		Suggested fan channel label.

`fan[1-*]_enable`
		Enable or disable the sensors.

Also see the Alarms section for status flags associated with fans.

***
PWM
***

`pwm[1-*]`
		Pulse width modulation fan control.

`pwm[1-*]_enable`
		Fan speed control method:

`pwm[1-*]_mode`
		direct current or pulse-width modulation.

`pwm[1-*]_freq`
		Base PWM frequency in Hz.

`pwm[1-*]_auto_channels_temp`
		Select which temperature channels affect this PWM output in
		auto mode.

`pwm[1-*]_auto_point[1-*]_pwm` / `pwm[1-*]_auto_point[1-*]_temp` / `pwm[1-*]_auto_point[1-*]_temp_hyst`
		Define the PWM vs temperature curve.

`temp[1-*]_auto_point[1-*]_pwm` / `temp[1-*]_auto_point[1-*]_temp` / `temp[1-*]_auto_point[1-*]_temp_hyst`
		Define the PWM vs temperature curve.

There is a third case where trip points are associated to both PWM output
channels and temperature channels: the PWM values are associated to PWM
output channels while the temperature values are associated to temperature
channels. In that case, the result is determined by the mapping between
temperature inputs and PWM outputs. When several temperature inputs are
mapped to a given PWM output, this leads to several candidate PWM values.
The actual result is up to the chip, but in general the highest candidate
value (fastest fan speed) wins.

************
Temperatures
************

`temp[1-*]_type`
		Sensor type selection.

`temp[1-*]_max`
		Temperature max value.

`temp[1-*]_min`
		Temperature min value.

`temp[1-*]_max_hyst`
		Temperature hysteresis value for max limit.

`temp[1-*]_min_hyst`
		Temperature hysteresis value for min limit.

`temp[1-*]_input`
		Temperature input value.

`temp[1-*]_crit`
		Temperature critical max value, typically greater than
		corresponding temp_max values.

`temp[1-*]_crit_hyst`
		Temperature hysteresis value for critical limit.

`temp[1-*]_emergency`
		Temperature emergency max value, for chips supporting more than
		two upper temperature limits.

`temp[1-*]_emergency_hyst`
		Temperature hysteresis value for emergency limit.

`temp[1-*]_lcrit`
		Temperature critical min value, typically lower than
		corresponding temp_min values.

`temp[1-*]_lcrit_hyst`
		Temperature hysteresis value for critical min limit.

`temp[1-*]_offset`
		Temperature offset which is added to the temperature reading
		by the chip.

`temp[1-*]_label`
		Suggested temperature channel label.

`temp[1-*]_lowest`
		Historical minimum temperature

`temp[1-*]_highest`
		Historical maximum temperature

`temp[1-*]_reset_history`
		Reset temp_lowest and temp_highest

`temp_reset_history`
		Reset temp_lowest and temp_highest for all sensors

`temp[1-*]_enable`
		Enable or disable the sensors.

`temp[1-*]_rated_min`
		Minimum rated temperature.

`temp[1-*]_rated_max`
		Maximum rated temperature.

Some chips measure temperature using external thermistors and an ADC, and
report the temperature measurement as a voltage. Converting this voltage
back to a temperature (or the other way around for limits) requires
mathematical functions not available in the kernel, so the conversion
must occur in user space. For these chips, all temp* files described
above should contain values expressed in millivolt instead of millidegree
Celsius. In other words, such temperature channels are handled as voltage
channels by the driver.

Also see the Alarms section for status flags associated with temperatures.

********
Currents
********

`curr[1-*]_max`
		Current max value.

`curr[1-*]_min`
		Current min value.

`curr[1-*]_lcrit`
		Current critical low value

`curr[1-*]_crit`
		Current critical high value.

`curr[1-*]_input`
		Current input value.

`curr[1-*]_average`
		Average current use.

`curr[1-*]_lowest`
		Historical minimum current.

`curr[1-*]_highest`
		Historical maximum current.

`curr[1-*]_reset_history`
		Reset currX_lowest and currX_highest

		WO

`curr_reset_history`
		Reset currX_lowest and currX_highest for all sensors.

`curr[1-*]_enable`
		Enable or disable the sensors.

`curr[1-*]_rated_min`
		Minimum rated current.

`curr[1-*]_rated_max`
		Maximum rated current.

Also see the Alarms section for status flags associated with currents.

*****
Power
*****

`power[1-*]_average`
		Average power use.

`power[1-*]_average_interval`
		Power use averaging interval.

`power[1-*]_average_interval_max`
		Maximum power use averaging interval.

`power[1-*]_average_interval_min`
		Minimum power use averaging interval.

`power[1-*]_average_highest`
		Historical average maximum power use

`power[1-*]_average_lowest`
		Historical average minimum power use

`power[1-*]_average_max`
		A poll notification is sent to `power[1-*]_average` when
		power use rises above this value.

`power[1-*]_average_min`
		A poll notification is sent to `power[1-*]_average` when
		power use sinks below this value.

`power[1-*]_input`
		Instantaneous power use.

`power[1-*]_input_highest`
		Historical maximum power use

`power[1-*]_input_lowest`
		Historical minimum power use.

`power[1-*]_reset_history`
		Reset input_highest, input_lowest, average_highest and
		average_lowest.

`power[1-*]_accuracy`
		Accuracy of the power meter.

`power[1-*]_cap`
		If power use rises above this limit, the
		system should take action to reduce power use.

`power[1-*]_cap_hyst`
		Margin of hysteresis built around capping and notification.

`power[1-*]_cap_max`
		Maximum cap that can be set.

`power[1-*]_cap_min`
		Minimum cap that can be set.

`power[1-*]_max`
		Maximum power.

`power[1-*]_crit`
				Critical maximum power.

				If power rises to or above this limit, the
				system is expected take drastic action to reduce
				power consumption, such as a system shutdown or
				a forced powerdown of some devices.

				Unit: microWatt

				RW

`power[1-*]_enable`
				Enable or disable the sensors.

				When disabled the sensor read will return
				-ENODATA.

				- 1: Enable
				- 0: Disable

				RW

`power[1-*]_rated_min`
				Minimum rated power.

				Unit: microWatt

				RO

`power[1-*]_rated_max`
				Maximum rated power.

				Unit: microWatt

				RO

Also see the Alarms section for status flags associated with power readings.

******
Energy
******

`energy[1-*]_input`
				Cumulative energy use

				Unit: microJoule

				RO

`energy[1-*]_enable`
				Enable or disable the sensors.

				When disabled the sensor read will return
				-ENODATA.

				- 1: Enable
				- 0: Disable

				RW

********
Humidity
********

`humidity[1-*]_input`
		Humidity.

`humidity[1-*]_enable`
		Enable or disable the sensors.

`humidity[1-*]_rated_min`
		Minimum rated humidity.

`humidity[1-*]_rated_max`
		Maximum rated humidity.

******
Alarms
******

Each channel or limit may have an associated alarm file, containing a
boolean value. 1 means than an alarm condition exists, 0 means no alarm.

Usually a given chip will either use channel-related alarms, or
limit-related alarms, not both. The driver should just reflect the hardware
implementation.

+-------------------------------+-----------------------+
| **`in[0-*]_alarm`,		| Channel alarm		|
| `curr[1-*]_alarm`,		|			|
| `power[1-*]_alarm`,		|   - 0: no alarm	|
| `fan[1-*]_alarm`,		|   - 1: alarm		|
| `temp[1-*]_alarm`**		|			|
|				|   RO			|
+-------------------------------+-----------------------+

**OR**

+-------------------------------+-----------------------+
| **`in[0-*]_min_alarm`,	| Limit alarm		|
| `in[0-*]_max_alarm`,		|			|
| `in[0-*]_lcrit_alarm`,	|   - 0: no alarm	|
| `in[0-*]_crit_alarm`,		|   - 1: alarm		|
| `curr[1-*]_min_alarm`,	|			|
| `curr[1-*]_max_alarm`,	| RO			|
| `curr[1-*]_lcrit_alarm`,	|			|
| `curr[1-*]_crit_alarm`,	|			|
| `power[1-*]_cap_alarm`,	|			|
| `power[1-*]_max_alarm`,	|			|
| `power[1-*]_crit_alarm`,	|			|
| `fan[1-*]_min_alarm`,		|			|
| `fan[1-*]_max_alarm`,		|			|
| `temp[1-*]_min_alarm`,	|			|
| `temp[1-*]_max_alarm`,	|			|
| `temp[1-*]_lcrit_alarm`,	|			|
| `temp[1-*]_crit_alarm`,	|			|
| `temp[1-*]_emergency_alarm`**	|			|
+-------------------------------+-----------------------+

Each input channel may have an associated fault file. This can be used
to notify open diodes, unconnected fans etc. where the hardware
supports it. When this boolean has value 1, the measurement for that
channel should not be trusted.

`fan[1-*]_fault` / `temp[1-*]_fault`
		Input fault condition.

Some chips also offer the possibility to get beeped when an alarm occurs:

`beep_enable`
		Master beep enable.

`in[0-*]_beep`, `curr[1-*]_beep`, `fan[1-*]_beep`, `temp[1-*]_beep`,
		Channel beep.

In theory, a chip could provide per-limit beep masking, but no such chip
was seen so far.

Old drivers provided a different, non-standard interface to alarms and
beeps. These interface files are deprecated, but will be kept around
for compatibility reasons:

`alarms`
		Alarm bitmask.

`beep_mask`
		Bitmask for beep.

*******************
Intrusion detection
*******************

`intrusion[0-*]_alarm`
		Chassis intrusion detection.

`intrusion[0-*]_beep`
		Chassis intrusion beep.

****************************
Average sample configuration
****************************

Devices allowing for reading {in,power,curr,temp}_average values may export
attributes for controlling number of samples used to compute average.

+--------------+---------------------------------------------------------------+
| samples      | Sets number of average samples for all types of measurements. |
|	       |							       |
|	       | RW							       |
+--------------+---------------------------------------------------------------+
| in_samples   | Sets number of average samples for specific type of	       |
| power_samples| measurements.						       |
| curr_samples |							       |
| temp_samples | Note that on some devices it won't be possible to set all of  |
|	       | them to different values so changing one might also change    |
|	       | some others.						       |
|	       |							       |
|	       | RW							       |
+--------------+---------------------------------------------------------------+

sysfs attribute writes interpretation
-------------------------------------

hwmon sysfs attributes always contain numbers, so the first thing to do is to
convert the input to a number, there are 2 ways todo this depending whether
the number can be negative or not::

	unsigned long u = simple_strtoul(buf, NULL, 10);
	long s = simple_strtol(buf, NULL, 10);

With buf being the buffer with the user input being passed by the kernel.
Notice that we do not use the second argument of strto[u]l, and thus cannot
tell when 0 is returned, if this was really 0 or is caused by invalid input.
This is done deliberately as checking this everywhere would add a lot of
code to the kernel.

Notice that it is important to always store the converted value in an
unsigned long or long, so that no wrap around can happen before any further
checking.

After the input string is converted to an (unsigned) long, the value should be
checked if its acceptable. Be careful with further conversions on the value
before checking it for validity, as these conversions could still cause a wrap
around before the check. For example do not multiply the result, and only
add/subtract if it has been divided before the add/subtract.

What to do if a value is found to be invalid, depends on the type of the
sysfs attribute that is being set. If it is a continuous setting like a
tempX_max or inX_max attribute, then the value should be clamped to its
limits using clamp_val(value, min_limit, max_limit). If it is not continuous
like for example a tempX_type, then when an invalid value is written,
-EINVAL should be returned.

Example1, temp1_max, register is a signed 8 bit value (-128 - 127 degrees)::

	long v = simple_strtol(buf, NULL, 10) / 1000;
	v = clamp_val(v, -128, 127);
	/* write v to register */

Example2, fan divider setting, valid values 2, 4 and 8::

	unsigned long v = simple_strtoul(buf, NULL, 10);

	switch (v) {
	case 2: v = 1; break;
	case 4: v = 2; break;
	case 8: v = 3; break;
	default:
		return -EINVAL;
	}
	/* write v to register */


code:
Kernel driver tc654
===================

Supported chips:

  * Microchip TC654 and TC655

    Prefix: 'tc654'
    Datasheet: http://ww1.m
    icrochip.com/downloads/en/DeviceDoc/20001734C.pdf

Authors:
      - Chris Packham <chris.packham@alliedtelesis.co.nz>
      - Masahiko Iwamoto <iwamoto@allied-telesis.co.jp>

Description
-----------
This driver implements support for the Microchip TC654 and TC655.

The TC654 uses the 2-wire interface compatible with the SMBUS 2.0
specification. The TC654 has two (2) inputs for measuring fan RPM and
one (1) PWM output which can be used for fan control.

Configuration Notes
-------------------
Ordinarily the pwm1_mode ABI is used for controlling the pwm output
mode.  However, for this chip the output is always pwm, and the
pwm1_mode determines if the pwm output is controlled via the pwm1 value
or via the Vin analog input.

Setting pwm1_mode to 1 will cause the pwm output to be driven based on
the pwm1 value. Setting pwm1_mode to 0 will cause the pwm output to be
driven based on the Vin input.


code:
Kernel driver tc74
====================

Supported chips:

   * Microchip TC74

     Prefix: 'tc74'

     Datasheet: Publicly available at Microchip website.

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

Driver supports the above part.

The tc74 has an 8-bit sensor, with 1 degree centigrade resolution
and +- 2 degrees centigrade accuracy.

Notes
-----

Currently entering low power standby mode is not supported.


code:
Kernel driver thmc50
=====================

Supported chips:

  * Analog Devices ADM1022

    Prefix: 'adm1022'

    Addresses scanned: I2C 0x2c - 0x2e

    Datasheet: http://www.analog.com/en/prod/0,2877,ADM1022,00.html

  * Texas Instruments THMC50

    Prefix: 'thmc50'

    Addresses scanned: I2C 0x2c - 0x2e

    Datasheet: https://www.ti.com/

Author: Krzysztof Helt <krzysztof.h1@wp.pl>

This driver was derived from the 2.4 kernel thmc50.c source file.

Credits:

  thmc50.c (2.4 kernel):

	- Frodo Looijaard <frodol@dds.nl>
	- Philip Edelbrock <phil@netroedge.com>

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

* adm1022_temp3: short array
    List of adapter,address pairs to force chips into ADM1022 mode with
    second remote temperature. This does not work for original THMC50 chips.

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

The THMC50 implements: an internal temperature sensor, support for an
external diode-type temperature sensor (compatible w/ the diode sensor inside
many processors), and a controllable fan/analog_out DAC. For the temperature
sensors, limits can be set through the appropriate Overtemperature Shutdown
register and Hysteresis register. Each value can be set and read to half-degree
accuracy.  An alarm is issued (usually to a connected LM78) when the
temperature gets higher then the Overtemperature Shutdown value; it stays on
until the temperature falls below the Hysteresis value. All temperatures are in
degrees Celsius, and are guaranteed within a range of -55 to +125 degrees.

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

The THMC50 is usually used in combination with LM78-like chips, to measure
the temperature of the processor(s).

The ADM1022 works the same as THMC50 but it is faster (5 Hz instead of
1 Hz for THMC50). It can be also put in a new mode to handle additional
remote temperature sensor. The driver use the mode set by BIOS by default.

In case the BIOS is broken and the mode is set incorrectly, you can force
the mode with additional remote temperature with adm1022_temp3 parameter.
A typical symptom of wrong setting is a fan forced to full speed.

Driver Features
---------------

The driver provides up to three temperatures:

temp1
	- internal
temp2
	- remote
temp3
	- 2nd remote only for ADM1022

pwm1
	- fan speed (0 = stop, 255 = full)
pwm1_mode
	- always 0 (DC mode)

The value of 0 for pwm1 also forces FAN_OFF signal from the chip,
so it stops fans even if the value 0 into the ANALOG_OUT register does not.

The driver was tested on Compaq AP550 with two ADM1022 chips (one works
in the temp3 mode), five temperature readings and two fans.


code:
Kernel driver tmp102
====================

Supported chips:

  * Texas Instruments TMP102

    Prefix: 'tmp102'

    Addresses scanned: none

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp102.html

Author:

	Steven King <sfking@fdwdc.com>

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

The Texas Instruments TMP102 implements one temperature sensor.  Limits can be
set through the Overtemperature Shutdown register and Hysteresis register.  The
sensor is accurate to 0.5 degree over the range of -25 to +85 C, and to 1.0
degree from -40 to +125 C. Resolution of the sensor is 0.0625 degree.  The
operating temperature has a minimum of -55 C and a maximum of +150 C.

The TMP102 has a programmable update rate that can select between 8, 4, 1, and
0.5 Hz. (Currently the driver only supports the default of 4 Hz).

The driver provides the common sysfs-interface for temperatures (see
Documentation/hwmon/sysfs-interface.rst under Temperatures).


code:
Kernel driver tmp103
====================

Supported chips:

  * Texas Instruments TMP103

    Prefix: 'tmp103'

    Addresses scanned: none

    Product info and datasheet: https://www.ti.com/product/tmp103

Author:

	Heiko Schocher <hs@denx.de>

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

The TMP103 is a digital output temperature sensor in a four-ball
wafer chip-scale package (WCSP). The TMP103 is capable of reading
temperatures to a resolution of 1°C. The TMP103 is specified for
operation over a temperature range of -40°C to +125°C.

Resolution: 8 Bits
Accuracy: ±1°C Typ (-10°C to +100°C)

The driver provides the common sysfs-interface for temperatures (see
Documentation/hwmon/sysfs-interface.rst under Temperatures).

Please refer how to instantiate this driver:
Documentation/i2c/instantiating-devices.rst


code:
Kernel driver tmp108
====================

Supported chips:

  * Texas Instruments TMP108

    Prefix: 'tmp108'

    Addresses scanned: none

    Datasheet: https://www.ti.com/product/tmp108

Author:

	John Muir <john@jmuir.com>

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

The Texas Instruments TMP108 implements one temperature sensor. An alert pin
can be set when temperatures exceed minimum or maximum values plus or minus a
hysteresis value. (This driver does not support interrupts for the alert pin,
and the device runs in comparator mode.)

The sensor is accurate to 0.75C over the range of -25 to +85 C, and to 1.0
degree from -40 to +125 C. Resolution of the sensor is 0.0625 degree. The
operating temperature has a minimum of -55 C and a maximum of +150 C.
Hysteresis values can be set to 0, 1, 2, or 4C.

The TMP108 has a programmable update rate that can select between 8, 4, 1, and
0.5 Hz.

By default the TMP108 reads the temperature continuously. To conserve power,
the TMP108 has a one-shot mode where the device is normally shut-down. When a
one shot is requested the temperature is read, the result can be retrieved,
and then the device is shut down automatically. (This driver only supports
continuous mode.)

The driver provides the common sysfs-interface for temperatures (see
Documentation/hwmon/sysfs-interface.rst under Temperatures).


code:
Kernel driver tmp401
====================

Supported chips:

  * Texas Instruments TMP401

    Prefix: 'tmp401'

    Addresses scanned: I2C 0x4c

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html

  * Texas Instruments TMP411

    Prefix: 'tmp411'

    Addresses scanned: I2C 0x4c, 0x4d, 0x4e

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp411.html

  * Texas Instruments TMP431

    Prefix: 'tmp431'

    Addresses scanned: I2C 0x4c, 0x4d

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp431.html

  * Texas Instruments TMP432

    Prefix: 'tmp432'

    Addresses scanned: I2C 0x4c, 0x4d

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp432.html

  * Texas Instruments TMP435

    Prefix: 'tmp435'

    Addresses scanned: I2C 0x48 - 0x4f

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html

Authors:

	- Hans de Goede <hdegoede@redhat.com>
	- Andre Prendel <andre.prendel@gmx.de>

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

This driver implements support for Texas Instruments TMP401, TMP411,
TMP431, TMP432, and TMP435 chips. These chips implement one or two
remote and one local temperature sensors. Temperature is measured in degrees
Celsius. Resolution of the remote sensor is 0.0625 degree. Local
sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
supported by the driver so far, so using the default resolution of 0.5
degree).

The driver provides the common sysfs-interface for temperatures (see
Documentation/hwmon/sysfs-interface.rst under Temperatures).

The TMP411 and TMP431 chips are compatible with TMP401. TMP411 provides
some additional features.

* Minimum and Maximum temperature measured since power-on, chip-reset

  Exported via sysfs attributes tempX_lowest and tempX_highest.

* Reset of historical minimum/maximum temperature measurements

  Exported via sysfs attribute temp_reset_history. Writing 1 to this
  file triggers a reset.

TMP432 is compatible with TMP401 and TMP431. It supports two external
temperature sensors.


code:
Kernel driver tmp421
====================

Supported chips:

  * Texas Instruments TMP421

    Prefix: 'tmp421'

    Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html

  * Texas Instruments TMP422

    Prefix: 'tmp422'

    Addresses scanned: I2C 0x4c, 0x4d, 0x4e and 0x4f

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html

  * Texas Instruments TMP423

    Prefix: 'tmp423'

    Addresses scanned: I2C 0x4c and 0x4d

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp421.html

  * Texas Instruments TMP441

    Prefix: 'tmp441'

    Addresses scanned: I2C 0x2a, 0x4c, 0x4d, 0x4e and 0x4f

    Datasheet: https://www.ti.com/product/tmp441

  * Texas Instruments TMP442

    Prefix: 'tmp442'

    Addresses scanned: I2C 0x4c and 0x4d

    Datasheet: https://www.ti.com/product/tmp442

Authors:

	Andre Prendel <andre.prendel@gmx.de>

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

This driver implements support for Texas Instruments TMP421, TMP422,
TMP423, TMP441, and TMP442 temperature sensor chips. These chips
implement one local and up to one (TMP421, TMP441), up to two (TMP422,
TMP442) or up to three (TMP423) remote sensors. Temperature is measured
in degrees Celsius. The chips are wired over I2C/SMBus and specified
over a temperature range of -40 to +125 degrees Celsius. Resolution
for both the local and remote channels is 0.0625 degree C.

The chips support only temperature measurement. The driver exports
the temperature values via the following sysfs files:

**temp[1-4]_input**

**temp[2-4]_fault**

Each sensor can be individually disabled via Devicetree or from sysfs
via:

**temp[1-4]_enable**

If labels were specified in Devicetree, additional sysfs files will
be present:

**temp[1-4]_label**


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

Kernel driver tmp464
====================

Supported chips:

  * Texas Instruments TMP464

    Prefix: 'tmp464'

    Addresses scanned: I2C 0x48, 0x49, 0x4a and 0x4b

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp464.html

  * Texas Instruments TMP468

    Prefix: 'tmp468'

    Addresses scanned: I2C 0x48, 0x49, 0x4a and 0x4b

    Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp468.html

Authors:

	Agathe Porte <agathe.porte@nokia.com>
	Guenter Roeck <linux@roeck-us.net>

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

This driver implements support for Texas Instruments TMP464 and TMP468
temperature sensor chips. TMP464 provides one local and four remote
sensors. TMP468 provides one local and eight remote sensors.
Temperature is measured in degrees Celsius. The chips are wired over
I2C/SMBus and specified over a temperature range of -40 to +125 degrees
Celsius. Resolution for both the local and remote channels is 0.0625
degree C.

The chips support only temperature measurements. The driver exports
temperature values, limits, and alarms via the following sysfs files:

**temp[1-9]_input**

**temp[1-9]_max**

**temp[1-9]_max_hyst**

**temp[1-9]_max_alarm**

**temp[1-9]_crit**

**temp[1-9]_crit_alarm**

**temp[1-9]_crit_hyst**

**temp[2-9]_offset**

**temp[2-9]_fault**

Each sensor can be individually disabled via Devicetree or from sysfs
via:

**temp[1-9]_enable**

If labels were specified in Devicetree, additional sysfs files will
be present:

**temp[1-9]_label**

The update interval is configurable with the following sysfs attribute.

**update_interval**


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

Kernel driver tmp513
====================

Supported chips:

  * Texas Instruments TMP512

    Prefix: 'tmp512'

    Datasheet: https://www.ti.com/lit/ds/symlink/tmp512.pdf

  * Texas Instruments TMP513

    Prefix: 'tmp513'

    Datasheet: https://www.ti.com/lit/ds/symlink/tmp513.pdf

Authors:

	Eric Tremblay <etremblay@distech-controls.com>

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

This driver implements support for Texas Instruments TMP512, and TMP513.
The TMP512 (dual-channel) and TMP513 (triple-channel) are system monitors
that include remote sensors, a local temperature sensor, and a high-side current
shunt monitor. These system monitors have the capability of measuring remote
temperatures, on-chip temperatures, and system voltage/power/current
consumption.

The temperatures are measured in degrees Celsius with a range of
-40 to + 125 degrees with a resolution of 0.0625 degree C.

For hysteresis value, only the first channel is writable. Writing to it
will affect all other values since each channels are sharing the same
hysteresis value. The hysteresis is in degrees Celsius with a range of
0 to 127.5 degrees with a resolution of 0.5 degree.

The driver exports the temperature values via the following sysfs files:

**temp[1-4]_input**

**temp[1-4]_crit**

**temp[1-4]_crit_alarm**

**temp[1-4]_crit_hyst**

The driver read the shunt voltage from the chip and convert it to current.
The readable range depends on the "ti,pga-gain" property (default to 8) and the
shunt resistor value. The value resolution will be equal to 10uV/Rshunt.

The driver exports the shunt currents values via the following sysFs files:

**curr1_input**

**curr1_lcrit**

**curr1_lcrit_alarm**

**curr1_crit**

**curr1_crit_alarm**

The bus voltage range is read from the chip with a resolution of 4mV. The chip
can be configurable in two different range (32V or 16V) using the
ti,bus-range-microvolt property in the devicetree.

The driver exports the bus voltage values via the following sysFs files:

**in0_input**

**in0_lcrit**

**in0_lcrit_alarm**

**in0_crit**

**in0_crit_alarm**

The bus power and bus currents range and resolution depends on the calibration
register value. Those values are calculate by the hardware using those
formulas:

Current = (ShuntVoltage * CalibrationRegister) / 4096
Power   = (Current * BusVoltage) / 5000

The driver exports the bus current and bus power values via the following
sysFs files:

**curr2_input**

**power1_input**

**power1_crit**

**power1_crit_alarm**

The calibration process follow the procedure of the datasheet (without overflow)
and depend on the shunt resistor value and the pga_gain value.


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

Kernel driver tps23861
======================

Supported chips:
  * Texas Instruments TPS23861

    Prefix: 'tps23861'

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

Author: Robert Marko <robert.marko@sartura.hr>

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

This driver supports hardware monitoring for Texas Instruments TPS23861 PoE PSE.

TPS23861 is a quad port IEEE802.3at PSE controller with optional I2C control
and monitoring capabilities.

TPS23861 offers three modes of operation: Auto, Semi-Auto and Manual.

This driver only supports the Auto mode of operation providing monitoring
as well as enabling/disabling the four ports.

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

======================= =====================================================================
in[0-3]_input		Voltage on ports [1-4]
in[0-3]_label		"Port[1-4]"
in4_input		IC input voltage
in4_label		"Input"
temp1_input		IC die temperature
temp1_label		"Die"
curr[1-4]_input		Current on ports [1-4]
in[1-4]_label		"Port[1-4]"
in[0-3]_enable		Enable/disable ports [1-4]
======================= =====================================================================