xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging into next

Browse Source 
Pull hwmon updates from Guenter Roeck:
 "New driver for NCT6683D

  New chip support to existing drivers:
   - add support for STTS2004 and AT30TSE004 to jc42 driver
   - add support for EMC1402/EMC1412/EMC1422 to emc1403 driver

  Other notable changes:
   - document hwmon kernel API
   - convert jc42, lm70, lm75, lm77, lm83, lm92, max1619, tmp421, and
     tmp102 drivers to use new hwmon API functions
   - replace function macros in lm80, lm92, and jc42 drivers with real
     code
   - convert emc1403 driver to use regmap, add support for additional
     attributes, and add device IDs for EMC1412, EMC1413, and EMC1414
   - various additional cleanup and minor bug fixes in several drivers"

* tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging: (60 commits)
  hwmon: (nct6775) Fix probe unwind paths to properly unregister platform devices
  hwmon: (nct6683) Fix probe unwind paths to properly unregister platform devices
  hwmon: (ultra45_env) Introduce managed version of kzalloc
  hwmon: Driver for NCT6683D
  hwmon: (lm80) Rearrange code to avoid forward declarations
  hwmon: (lm80) Convert fan display function macros into functions
  hwmon: (lm80) Convert voltage display function macros into functions
  hwmon: (lm80) Convert temperature display function macros into functions
  hwmon: (lm80) Normalize all temperature values to 16 bit
  hwmon: (lm80) Simplify TEMP_FROM_REG
  hwmon: (lm83) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (lm83) Rearange code to avoid forward declarations
  hwmon: (lm83) Drop FSF address
  hwmon: (max1619) Convert to use devm_hwmon_device_register_with_groups
  hwmon: (max1619) Drop function macros
  hwmon: (max1619) Rearrange code to avoid forward declarations
  hwmon: (max1619) Drop FSF address
  hwmon: (max1619) Fix critical alarm display
  hwmon: (jc42) Add support for STTS2004 and AT30TSE004
  hwmon: (jc42) Convert function macros into functions
  ...
This commit is contained in:
Linus Torvalds
2014-06-03 11:09:43 -07:00
parent 8f5759aeb8 9d311eddf3
commit f456205265
35 changed files with 2908 additions and 1440 deletions
Download Patch File Download Diff File Expand all files Collapse all files

59
Documentation/hwmon/emc1403 Normal file
View File

@@ -0,0 +1,59 @@
Kernel driver emc1403
=====================
Supported chips:
* SMSC / Microchip EMC1402, EMC1412
Addresses scanned: I2C 0x18, 0x1c, 0x29, 0x4c, 0x4d, 0x5c
Prefix: 'emc1402'
Datasheets:
http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf
* SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414
Addresses scanned: I2C 0x18, 0x29, 0x4c, 0x4d
Prefix: 'emc1403', 'emc1404'
Datasheets:
http://ww1.microchip.com/downloads/en/DeviceDoc/1403_1404.pdf
http://ww1.microchip.com/downloads/en/DeviceDoc/1413_1414.pdf
* SMSC / Microchip EMC1422
Addresses scanned: I2C 0x4c
Prefix: 'emc1422'
Datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf
* SMSC / Microchip EMC1423, EMC1424
Addresses scanned: I2C 0x4c
Prefix: 'emc1423', 'emc1424'
Datasheet:
http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf
Author:
Kalhan Trisal <kalhan.trisal@intel.com
Description
-----------
The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips
contain up to four temperature sensors. EMC14x2 support two sensors
(one internal, one external). EMC14x3 support three sensors (one internal,
two external), and EMC14x4 support four sensors (one internal, three
external).
The chips implement three limits for each sensor: low (tempX_min), high
(tempX_max) and critical (tempX_crit.) The chips also implement an
hysteresis mechanism which applies to all limits. The relative difference
is stored in a single register on the chip, which means that the relative
difference between the limit and its hysteresis is always the same for
all three limits.
This implementation detail implies the following:
* When setting a limit, its hysteresis will automatically follow, the
difference staying unchanged. For example, if the old critical limit
was 80 degrees C, and the hysteresis was 75 degrees C, and you change
the critical limit to 90 degrees C, then the hysteresis will
automatically change to 85 degrees C.
* The hysteresis values can't be set independently. We decided to make
only temp1_crit_hyst writable, while all other hysteresis attributes
are read-only. Setting temp1_crit_hyst writes the difference between
temp1_crit_hyst and temp1_crit into the chip, and the same relative
hysteresis applies automatically to all other limits.
* The limits should be set before the hysteresis.

107
Documentation/hwmon/hwmon-kernel-api.txt Normal file
View File

@@ -0,0 +1,107 @@
The Linux Hardware Monitoring kernel API.
=========================================
Guenter Roeck
Introduction
------------
This document describes the API that can be used by hardware monitoring
drivers that want to use the hardware monitoring framework.
This document does not describe what a hardware monitoring (hwmon) Driver or
Device is. It also does not describe the API which can be used by user space
to communicate with a hardware monitoring device. If you want to know this
then please read the following file: Documentation/hwmon/sysfs-interface.
For additional guidelines on how to write and improve hwmon drivers, please
also read Documentation/hwmon/submitting-patches.
The API
-------
Each hardware monitoring driver must #include <linux/hwmon.h> and, in most
cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following
register/unregister functions:
struct device *hwmon_device_register(struct device *dev);
struct device *
hwmon_device_register_with_groups(struct device *dev, const char *name,
void *drvdata,
const struct attribute_group **groups);
struct device *
devm_hwmon_device_register_with_groups(struct device *dev,
const char *name, void *drvdata,
const struct attribute_group **groups);
void hwmon_device_unregister(struct device *dev);
void devm_hwmon_device_unregister(struct device *dev);
hwmon_device_register registers a hardware monitoring device. The parameter
of this function is a pointer to the parent device.
This function returns a pointer to the newly created hardware monitoring device
or PTR_ERR for failure. If this registration function is used, hardware
monitoring sysfs attributes are expected to have been created and attached to
the parent device prior to calling hwmon_device_register. A name attribute must
have been created by the caller.
hwmon_device_register_with_groups is similar to hwmon_device_register. However,
it has additional parameters. The name parameter is a pointer to the hwmon
device name. The registration function wil create a name sysfs attribute
pointing to this name. The drvdata parameter is the pointer to the local
driver data. hwmon_device_register_with_groups will attach this pointer
to the newly allocated hwmon device. The pointer can be retrieved by the driver
using dev_get_drvdata() on the hwmon device pointer. The groups parameter is
a pointer to a list of sysfs attribute groups. The list must be NULL terminated.
hwmon_device_register_with_groups creates the hwmon device with name attribute
as well as all sysfs attributes attached to the hwmon device.
devm_hwmon_device_register_with_groups is similar to
hwmon_device_register_with_groups. However, it is device managed, meaning the
hwmon device does not have to be removed explicitly by the removal function.
hwmon_device_unregister deregisters a registered hardware monitoring device.
The parameter of this function is the pointer to the registered hardware
monitoring device structure. This function must be called from the driver
remove function if the hardware monitoring device was registered with
hwmon_device_register or with hwmon_device_register_with_groups.
devm_hwmon_device_unregister does not normally have to be called. It is only
needed for error handling, and only needed if the driver probe fails after
the call to devm_hwmon_device_register_with_groups.
The header file linux/hwmon-sysfs.h provides a number of useful macros to
declare and use hardware monitoring sysfs attributes.
In many cases, you can use the exsting define DEVICE_ATTR to declare such
attributes. This is feasible if an attribute has no additional context. However,
in many cases there will be additional information such as a sensor index which
will need to be passed to the sysfs attribute handling function.
SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes
which need such additional context information. SENSOR_DEVICE_ATTR requires
one additional argument, SENSOR_DEVICE_ATTR_2 requires two.
SENSOR_DEVICE_ATTR defines a struct sensor_device_attribute variable.
This structure has the following fields.
struct sensor_device_attribute {
struct device_attribute dev_attr;
int index;
};
You can use to_sensor_dev_attr to get the pointer to this structure from the
attribute read or write function. Its parameter is the device to which the
attribute is attached.
SENSOR_DEVICE_ATTR_2 defines a struct sensor_device_attribute_2 variable,
which is defined as follows.
struct sensor_device_attribute_2 {
struct device_attribute dev_attr;
u8 index;
u8 nr;
};
Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter
is the device to which the attribute is attached.

16
Documentation/hwmon/jc42
View File

@@ -5,9 +5,12 @@ Supported chips:
* Analog Devices ADT7408
Datasheets:
http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
* Atmel AT30TS00
* Atmel AT30TS00, AT30TS002A/B, AT30TSE004A
Datasheets:
http://www.atmel.com/Images/doc8585.pdf
http://www.atmel.com/Images/doc8711.pdf
http://www.atmel.com/Images/Atmel-8852-SEEPROM-AT30TSE002A-Datasheet.pdf
http://www.atmel.com/Images/Atmel-8868-DTS-AT30TSE004A-Datasheet.pdf
* IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
Datasheets:
http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
@@ -34,12 +37,13 @@ Supported chips:
Datasheet:
http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF
http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF
* ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000
* ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000
Datasheets:
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
http://www.st.com/web/en/resource/technical/document/datasheet/CD00157556.pdf
http://www.st.com/web/en/resource/technical/document/datasheet/CD00157558.pdf
http://www.st.com/web/en/resource/technical/document/datasheet/CD00266638.pdf
http://www.st.com/web/en/resource/technical/document/datasheet/CD00225278.pdf
http://www.st.com/web/en/resource/technical/document/datasheet/DM00076709.pdf
* JEDEC JC 42.4 compliant temperature sensor chips
Datasheet:
http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf

20
Documentation/hwmon/lm77
View File

@@ -18,5 +18,21 @@ sensor incorporates a band-gap type temperature sensor,
10-bit ADC, and a digital comparator with user-programmable upper
and lower limit values.
Limits can be set through the Overtemperature Shutdown register and
Hysteresis register.
The LM77 implements 3 limits: low (temp1_min), high (temp1_max) and
critical (temp1_crit.) It also implements an hysteresis mechanism which
applies to all 3 limits. The relative difference is stored in a single
register on the chip, which means that the relative difference between
the limit and its hysteresis is always the same for all 3 limits.
This implementation detail implies the following:
* When setting a limit, its hysteresis will automatically follow, the
difference staying unchanged. For example, if the old critical limit
was 80 degrees C, and the hysteresis was 75 degrees C, and you change
the critical limit to 90 degrees C, then the hysteresis will
automatically change to 85 degrees C.
* All 3 hysteresis can't be set independently. We decided to make
temp1_crit_hyst writable, while temp1_min_hyst and temp1_max_hyst are
read-only. Setting temp1_crit_hyst writes the difference between
temp1_crit_hyst and temp1_crit into the chip, and the same relative
hysteresis applies automatically to the low and high limits.
* The limits should be set before the hysteresis.

57
Documentation/hwmon/nct6683 Normal file
View File

@@ -0,0 +1,57 @@
Kernel driver nct6683
=====================
Supported chips:
* Nuvoton NCT6683D
Prefix: 'nct6683'
Addresses scanned: ISA address retrieved from Super I/O registers
Datasheet: Available from Nuvoton upon request
Authors:
Guenter Roeck <linux@roeck-us.net>
Description
-----------
This driver implements support for the Nuvoton NCT6683D eSIO chip.
The chips implement up to shared 32 temperature and voltage sensors.
It supports up to 16 fan rotation sensors and up to 8 fan control engines.
Temperatures are measured in degrees Celsius. Measurement resolution is
0.5 degrees C.
Voltage sensors (also known as IN sensors) report their values in millivolts.
Fan rotation speeds are reported in RPM (rotations per minute).
Usage Note
----------
Limit register locations on Intel boards with EC firmware version 1.0
build date 04/03/13 do not match the register locations in the Nuvoton
datasheet. Nuvoton confirms that Intel uses a special firmware version
with different register addresses. The specification describing the Intel
firmware is held under NDA by Nuvoton and Intel and not available
to the public.
Some of the register locations can be reverse engineered; others are too
well hidden. Given this, writing any values from the operating system is
considered too risky with this firmware and has been disabled. All limits
must all be written from the BIOS.
The driver has only been tested with the Intel firmware, and by default
only instantiates on Intel boards. To enable it on non-Intel boards,
set the 'force' module parameter to 1.
Tested Boards and Firmware Versions
-----------------------------------
The driver has been reported to work with the following boards and
firmware versions.
Board Firmware version
---------------------------------------------------------------
Intel DH87RL NCT6683D EC firmware version 1.0 build 04/03/13
Intel DH87MC NCT6683D EC firmware version 1.0 build 04/03/13
Intel DB85FL NCT6683D EC firmware version 1.0 build 04/03/13