forked from lordarcadius/electrablue_mido
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge tag 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/ker…
…nel/git/groeck/linux-staging into next 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 ...
- Loading branch information
Showing
35 changed files
with
2,885 additions
and
1,417 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -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 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.