Merge branch 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging
* 'hwmon-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/staging: hwmon: (max34440) Add driver documentation hwmon: (max16064) Add driver documentation hwmon: (max8688) Add driver documentation hwmon: (pmbus) Documentation updates hwmon: (smm665) Fix spelling error in driver documentation hwmon: (pmbus) Removed unused variable from struct pmbus_data hwmon: Add submitting-patches checklist to documentation
This commit is contained in:
Коммит
584f790467
|
@ -0,0 +1,62 @@
|
|||
Kernel driver max16064
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Maxim MAX16064
|
||||
Prefix: 'max16064'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver supports hardware montoring for Maxim MAX16064 Quad Power-Supply
|
||||
Controller with Active-Voltage Output Control and PMBus Interface.
|
||||
|
||||
The driver is a client driver to the core PMBus driver.
|
||||
Please see Documentation/hwmon/pmbus 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 for
|
||||
details.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
||||
The driver supports standard PMBus driver platform data.
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The following attributes are supported. Limits are read-write; all other
|
||||
attributes are read-only.
|
||||
|
||||
in[1-4]_label "vout[1-4]"
|
||||
in[1-4]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
in[1-4]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
|
||||
in[1-4]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
||||
|
||||
temp1_input Measured temperature. From READ_TEMPERATURE_1 register.
|
||||
temp1_max Maximum temperature. From OT_WARN_LIMIT register.
|
||||
temp1_crit Critical high temperature. From OT_FAULT_LIMIT register.
|
||||
temp1_max_alarm Chip temperature high alarm. Set by comparing
|
||||
READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
|
||||
status is set.
|
||||
temp1_crit_alarm Chip temperature critical high alarm. Set by comparing
|
||||
READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
|
||||
status is set.
|
|
@ -0,0 +1,79 @@
|
|||
Kernel driver max34440
|
||||
======================
|
||||
|
||||
Supported chips:
|
||||
* Maxim MAX34440
|
||||
Prefixes: 'max34440'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
|
||||
* Maxim MAX34441
|
||||
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
|
||||
Prefixes: 'max34441'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
|
||||
Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
|
||||
and Intelligent Fan Controller.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus 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 for
|
||||
details.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
||||
The driver supports standard PMBus driver platform data.
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The following attributes are supported. Limits are read-write; all other
|
||||
attributes are read-only.
|
||||
|
||||
in[1-6]_label "vout[1-6]".
|
||||
in[1-6]_input Measured voltage. From READ_VOUT register.
|
||||
in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
in[1-6]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
|
||||
in[1-6]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
||||
|
||||
curr[1-6]_label "iout[1-6]".
|
||||
curr[1-6]_input Measured current. From READ_IOUT register.
|
||||
curr[1-6]_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr[1-6]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr[1-6]_max_alarm Current high alarm. From IOUT_OC_WARNING status.
|
||||
curr[1-6]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
|
||||
|
||||
in6 and curr6 attributes only exist for MAX34440.
|
||||
|
||||
temp[1-8]_input Measured temperatures. From READ_TEMPERATURE_1 register.
|
||||
temp1 is the chip's internal temperature. temp2..temp5
|
||||
are remote I2C temperature sensors. For MAX34441, temp6
|
||||
is a remote thermal-diode sensor. For MAX34440, temp6..8
|
||||
are remote I2C temperature sensors.
|
||||
temp[1-8]_max Maximum temperature. From OT_WARN_LIMIT register.
|
||||
temp[1-8]_crit Critical high temperature. From OT_FAULT_LIMIT register.
|
||||
temp[1-8]_max_alarm Temperature high alarm.
|
||||
temp[1-8]_crit_alarm Temperature critical high alarm.
|
||||
|
||||
temp7 and temp8 attributes only exist for MAX34440.
|
|
@ -0,0 +1,69 @@
|
|||
Kernel driver max8688
|
||||
=====================
|
||||
|
||||
Supported chips:
|
||||
* Maxim MAX8688
|
||||
Prefix: 'max8688'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
|
||||
|
||||
Author: Guenter Roeck <guenter.roeck@ericsson.com>
|
||||
|
||||
|
||||
Description
|
||||
-----------
|
||||
|
||||
This driver supports hardware montoring for Maxim MAX8688 Digital Power-Supply
|
||||
Controller/Monitor with PMBus Interface.
|
||||
|
||||
The driver is a client driver to the core PMBus driver. Please see
|
||||
Documentation/hwmon/pmbus 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 for
|
||||
details.
|
||||
|
||||
|
||||
Platform data support
|
||||
---------------------
|
||||
|
||||
The driver supports standard PMBus driver platform data.
|
||||
|
||||
|
||||
Sysfs entries
|
||||
-------------
|
||||
|
||||
The following attributes are supported. Limits are read-write; all other
|
||||
attributes are read-only.
|
||||
|
||||
in1_label "vout1"
|
||||
in1_input Measured voltage. From READ_VOUT register.
|
||||
in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
|
||||
in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register.
|
||||
in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
|
||||
in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
|
||||
in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status.
|
||||
in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status.
|
||||
in1_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
|
||||
in1_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
|
||||
|
||||
curr1_label "iout1"
|
||||
curr1_input Measured current. From READ_IOUT register.
|
||||
curr1_max Maximum current. From IOUT_OC_WARN_LIMIT register.
|
||||
curr1_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
|
||||
curr1_max_alarm Current high alarm. From IOUT_OC_WARN_LIMIT register.
|
||||
curr1_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status.
|
||||
|
||||
temp1_input Measured temperature. From READ_TEMPERATURE_1 register.
|
||||
temp1_max Maximum temperature. From OT_WARN_LIMIT register.
|
||||
temp1_crit Critical high temperature. From OT_FAULT_LIMIT register.
|
||||
temp1_max_alarm Chip temperature high alarm. Set by comparing
|
||||
READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
|
||||
status is set.
|
||||
temp1_crit_alarm Chip temperature critical high alarm. Set by comparing
|
||||
READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
|
||||
status is set.
|
|
@ -13,26 +13,6 @@ Supported chips:
|
|||
Prefix: 'ltc2978'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
|
||||
* Maxim MAX16064
|
||||
Quad Power-Supply Controller
|
||||
Prefix: 'max16064'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
|
||||
* Maxim MAX34440
|
||||
PMBus 6-Channel Power-Supply Manager
|
||||
Prefixes: 'max34440'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
|
||||
* Maxim MAX34441
|
||||
PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
|
||||
Prefixes: 'max34441'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
|
||||
* Maxim MAX8688
|
||||
Digital Power-Supply Controller/Monitor
|
||||
Prefix: 'max8688'
|
||||
Addresses scanned: -
|
||||
Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
|
||||
* Generic PMBus devices
|
||||
Prefix: 'pmbus'
|
||||
Addresses scanned: -
|
||||
|
@ -175,11 +155,13 @@ currX_crit Critical maximum current.
|
|||
From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
|
||||
currX_alarm Current high alarm.
|
||||
From IIN_OC_WARNING or IOUT_OC_WARNING status.
|
||||
currX_max_alarm Current high alarm.
|
||||
From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT status.
|
||||
currX_lcrit_alarm Output current critical low alarm.
|
||||
From IOUT_UC_FAULT status.
|
||||
currX_crit_alarm Current critical high alarm.
|
||||
From IIN_OC_FAULT or IOUT_OC_FAULT status.
|
||||
currX_label "iin" or "vinY"
|
||||
currX_label "iin" or "ioutY"
|
||||
|
||||
powerX_input Measured power. From READ_PIN or READ_POUT register.
|
||||
powerX_cap Output power cap. From POUT_MAX register.
|
||||
|
@ -193,13 +175,13 @@ powerX_crit_alarm Output power critical high alarm.
|
|||
From POUT_OP_FAULT status.
|
||||
powerX_label "pin" or "poutY"
|
||||
|
||||
tempX_input Measured tempererature.
|
||||
tempX_input Measured temperature.
|
||||
From READ_TEMPERATURE_X register.
|
||||
tempX_min Mimimum tempererature. From UT_WARN_LIMIT register.
|
||||
tempX_max Maximum tempererature. From OT_WARN_LIMIT register.
|
||||
tempX_lcrit Critical low tempererature.
|
||||
tempX_min Mimimum temperature. From UT_WARN_LIMIT register.
|
||||
tempX_max Maximum temperature. From OT_WARN_LIMIT register.
|
||||
tempX_lcrit Critical low temperature.
|
||||
From UT_FAULT_LIMIT register.
|
||||
tempX_crit Critical high tempererature.
|
||||
tempX_crit Critical high temperature.
|
||||
From OT_FAULT_LIMIT register.
|
||||
tempX_min_alarm Chip temperature low alarm. Set by comparing
|
||||
READ_TEMPERATURE_X with UT_WARN_LIMIT if
|
||||
|
|
|
@ -150,8 +150,8 @@ in8_crit_alarm Channel F critical alarm
|
|||
in9_crit_alarm AIN1 critical alarm
|
||||
in10_crit_alarm AIN2 critical alarm
|
||||
|
||||
temp1_input Chip tempererature
|
||||
temp1_min Mimimum chip tempererature
|
||||
temp1_max Maximum chip tempererature
|
||||
temp1_crit Critical chip tempererature
|
||||
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
|
||||
|
|
|
@ -0,0 +1,109 @@
|
|||
How to Get Your Patch Accepted Into the Hwmon Subsystem
|
||||
-------------------------------------------------------
|
||||
|
||||
This text is 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/SubmitChecklist
|
||||
Documentation/SubmittingDrivers
|
||||
Documentation/SubmittingPatches
|
||||
Documentation/CodingStyle
|
||||
|
||||
* If your patch generates checkpatch warnings, please refrain from explanations
|
||||
such as "I don't like that coding style". Keep in mind that each unnecessary
|
||||
warning helps hiding a real problem. If you don't like the kernel coding
|
||||
style, don't write kernel drivers.
|
||||
|
||||
* 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 or CONFIG_HOTPLUG, make sure it compiles for all configuration
|
||||
variants.
|
||||
|
||||
|
||||
2. Adding functionality to existing drivers
|
||||
-------------------------------------------
|
||||
|
||||
* Make sure the documentation in Documentation/hwmon/<driver_name> 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>.
|
||||
|
||||
* Add the driver to Kconfig and Makefile in alphabetical order.
|
||||
|
||||
* Make sure that all dependencies are listed in Kconfig. For new drivers, it
|
||||
is most likely prudent to add a dependency on EXPERIMENTAL.
|
||||
|
||||
* Avoid forward declarations if you can. Rearrange the code if necessary.
|
||||
|
||||
* 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.
|
||||
|
||||
* 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.
|
||||
|
||||
* 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 first, then create sysfs entries and register
|
||||
with the hwmon subsystem.
|
||||
|
||||
* 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.
|
||||
|
||||
* 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.
|
|
@ -139,7 +139,6 @@ struct pmbus_data {
|
|||
* A single status register covers multiple attributes,
|
||||
* so we keep them all together.
|
||||
*/
|
||||
u8 status_bits;
|
||||
u8 status[PB_NUM_STATUS_REG];
|
||||
|
||||
u8 currpage;
|
||||
|
|
Загрузка…
Ссылка в новой задаче