Merge branch 2.6.39-rc7 into usb-linus

This was needed to resolve a conflict in:
	drivers/usb/host/isp1760-hcd.c

Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

8 files changed, 370 insertions, 56 deletions

diff --git a/Documentation/hwmon/adm1021 b/Documentation/hwmon/adm1021
index 03d02bfb3df1..02ad96cf9b2b 100644
--- a/Documentation/hwmon/adm1021
+++ b/Documentation/hwmon/adm1021
@@ -14,10 +14,6 @@ Supported chips:
     Prefix: 'gl523sm'
     Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
     Datasheet:
-  * Intel Xeon Processor
-    Prefix: - any other - may require 'force_adm1021' parameter
-    Addresses scanned: none
-    Datasheet: Publicly available at Intel website
   * Maxim MAX1617
     Prefix: 'max1617'
     Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
@@ -91,21 +87,27 @@ will do no harm, but will return 'old' values. It is possible to make
 ADM1021-clones do faster measurements, but there is really no good reason
 for that.
 
-Xeon support
-------------
 
-Some Xeon processors have real max1617, adm1021, or compatible chips
-within them, with two temperature sensors.
+Netburst-based Xeon support
+---------------------------
 
-Other Xeons have chips with only one sensor.
+Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
+2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
+within them, with two temperature sensors. Other Xeon processors of this
+era (with 400 MHz FSB) had chips with only one temperature sensor.
 
-If you have a Xeon, and the adm1021 module loads, and both temperatures
-appear valid, then things are good.
+If you have such an old Xeon, and you get two valid temperatures when
+loading the adm1021 module, then things are good.
 
-If the adm1021 module doesn't load, you should try this:
-        modprobe adm1021 force_adm1021=BUS,ADDRESS
-        ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
+If nothing happens when loading the adm1021 module, and you are certain
+that your specific Xeon processor model includes compatible sensors, you
+will have to explicitly instantiate the sensor chips from user-space. See
+method 4 in Documentation/i2c/instantiating-devices. Possible slave
+addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
+only temp2 will be correct and temp1 will have to be ignored.
 
-If you have dual Xeons you may have appear to have two separate
-adm1021-compatible chips, or two single-temperature sensors, at distinct
-addresses.
+Previous generations of the Xeon processor (based on Pentium II/III)
+didn't have these sensors. Next generations of Xeon processors (533 MHz
+FSB and faster) lost them, until the Core-based generation which
+introduced integrated digital thermal sensors. These are supported by
+the coretemp driver.
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index fa475c0a48a3..f3efd18e87f4 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -32,6 +32,16 @@ Supported chips:
     Addresses scanned: I2C 0x4c and 0x4d
     Datasheet: Publicly available at the ON Semiconductor website
                http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
+  * Analog Devices ADT7461A
+    Prefix: 'adt7461a'
+    Addresses scanned: I2C 0x4c and 0x4d
+    Datasheet: Publicly available at the ON Semiconductor website
+               http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
+  * ON Semiconductor NCT1008
+    Prefix: 'nct1008'
+    Addresses scanned: I2C 0x4c and 0x4d
+    Datasheet: Publicly available at the ON Semiconductor website
+               http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
   * Maxim MAX6646
     Prefix: 'max6646'
     Addresses scanned: I2C 0x4d
@@ -149,7 +159,7 @@ ADM1032:
   * ALERT is triggered by open remote sensor.
   * SMBus PEC support for Write Byte and Receive Byte transactions.
 
-ADT7461:
+ADT7461, ADT7461A, NCT1008:
   * Extended temperature range (breaks compatibility)
   * Lower resolution for remote temperature
 
@@ -195,9 +205,9 @@ are exported, one for each channel, but these values are of course linked.
 Only the local hysteresis can be set from user-space, and the same delta
 applies to the remote hysteresis.
 
-The lm90 driver will not update its values more frequently than every
-other second; reading them more often will do no harm, but will return
-'old' values.
+The lm90 driver will not update its values more frequently than configured with
+the update_interval attribute; reading them more often will do no harm, but will
+return 'old' values.
 
 SMBus Alert Support
 -------------------
@@ -205,11 +215,12 @@ SMBus Alert Support
 This driver has basic support for SMBus alert. When an alert is received,
 the status register is read and the faulty temperature channel is logged.
 
-The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
-alert protocol properly so additional care is needed: the ALERT output is
-disabled when an alert is received, and is re-enabled only when the alarm
-is gone. Otherwise the chip would block alerts from other chips in the bus
-as long as the alarm is active.
+The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
+Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
+properly so additional care is needed: the ALERT output is disabled when
+an alert is received, and is re-enabled only when the alarm is gone.
+Otherwise the chip would block alerts from other chips in the bus as long
+as the alarm is active.
 
 PEC Support
 -----------
diff --git a/Documentation/hwmon/max16064 b/Documentation/hwmon/max16064
new file mode 100644
index 000000000000..41728999e142
--- /dev/null
+++ b/Documentation/hwmon/max16064
@@ -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.
diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440
new file mode 100644
index 000000000000..6c525dd07d59
--- /dev/null
+++ b/Documentation/hwmon/max34440
@@ -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.
diff --git a/Documentation/hwmon/max8688 b/Documentation/hwmon/max8688
new file mode 100644
index 000000000000..0ddd3a412030
--- /dev/null
+++ b/Documentation/hwmon/max8688
@@ -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.
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus
index dc4933e96344..5e462fc7f99b 100644
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@@ -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
diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665
index 3820fc9ca52d..59e316140542 100644
--- a/Documentation/hwmon/smm665
+++ b/Documentation/hwmon/smm665
@@ -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
diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches
new file mode 100644
index 000000000000..86f42e8e9e49
--- /dev/null
+++ b/Documentation/hwmon/submitting-patches
@@ -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.