28 files changed, 1063 insertions, 150 deletions

diff --git a/Documentation/ABI/testing/sysfs-bus-mei b/Documentation/ABI/testing/sysfs-bus-mei
new file mode 100644
index 000000000000..2066f0bbd453
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-mei
@@ -0,0 +1,7 @@
+What:           /sys/bus/mei/devices/.../modalias
+Date:           March 2013
+KernelVersion:  3.10
+Contact:        Samuel Ortiz <sameo@linux.intel.com>
+                linux-mei@linux.intel.com
+Description:    Stores the same MODALIAS value emitted by uevent
+                Format: mei:<mei device name>
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 9c978dcae07d..2447698aed41 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -173,3 +173,15 @@ Description:	Processor frequency boosting control
                 Boosting allows the CPU and the firmware to run at a frequency
                 beyound it's nominal limit.
                 More details can be found in Documentation/cpu-freq/boost.txt
+
+
+What:           /sys/devices/system/cpu/cpu#/crash_notes
+                /sys/devices/system/cpu/cpu#/crash_notes_size
+Date:           April 2013
+Contact:        kexec@lists.infradead.org
+Description:    address and size of the percpu note.
+
+                crash_notes: the physical address of the memory that holds the
+                note of cpu#.
+
+                crash_notes_size: size of the note of cpu#.
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
index c63097d6afeb..16769d9cedd6 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -14,9 +14,19 @@ Required properties:
   - atmel,adc-status-register: Offset of the Interrupt Status Register
   - atmel,adc-trigger-register: Offset of the Trigger Register
   - atmel,adc-vref: Reference voltage in millivolts for the conversions
+  - atmel,adc-res: List of resolution in bits supported by the ADC. List size
+                   must be two at least.
+  - atmel,adc-res-names: Contains one identifier string for each resolution
+                         in atmel,adc-res property. "lowres" and "highres"
+                         identifiers are required.
 
 Optional properties:
   - atmel,adc-use-external: Boolean to enable of external triggers
+  - atmel,adc-use-res: String corresponding to an identifier from
+                       atmel,adc-res-names property. If not specified, the highest
+                       resolution will be used.
+  - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
+  - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
  
 Optional trigger Nodes:
   - Required properties:
@@ -40,6 +50,9 @@ adc0: adc@fffb0000 {
         atmel,adc-trigger-register = <0x08>;
         atmel,adc-use-external;
         atmel,adc-vref = <3300>;
+        atmel,adc-res = <8 10>;
+        atmel,adc-res-names = "lowres", "highres";
+        atmel,adc-use-res = "lowres";
 
         trigger@0 {
                 trigger-name = "external-rising";
diff --git a/Documentation/devicetree/bindings/arm/msm/ssbi.txt b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
new file mode 100644
index 000000000000..54fd5ced3401
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/ssbi.txt
@@ -0,0 +1,18 @@
+* Qualcomm SSBI
+
+Some Qualcomm MSM devices contain a point-to-point serial bus used to
+communicate with a limited range of devices (mostly power management
+chips).
+
+These require the following properties:
+
+- compatible: "qcom,ssbi"
+
+- qcom,controller-type
+  indicates the SSBI bus variant the controller should use to talk
+  with the slave device.  This should be one of "ssbi", "ssbi2", or
+  "pmic-arbiter".  The type chosen is determined by the attached
+  slave.
+
+The slave device should be the single child node of the ssbi device
+with a compatible field.
diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
new file mode 100644
index 000000000000..47ada1dff216
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-adc.txt
@@ -0,0 +1,60 @@
+Samsung Exynos Analog to Digital Converter bindings
+
+The devicetree bindings are for the new ADC driver written for
+Exynos4 and upward SoCs from Samsung.
+
+New driver handles the following
+1. Supports ADC IF found on EXYNOS4412/EXYNOS5250
+   and future SoCs from Samsung
+2. Add ADC driver under iio/adc framework
+3. Also adds the Documentation for device tree bindings
+
+Required properties:
+- compatible:           Must be "samsung,exynos-adc-v1"
+                                for exynos4412/5250 controllers.
+                        Must be "samsung,exynos-adc-v2" for
+                                future controllers.
+- reg:                  Contains ADC register address range (base address and
+                        length) and the address of the phy enable register.
+- interrupts:           Contains the interrupt information for the timer. The
+                        format is being dependent on which interrupt controller
+                        the Samsung device uses.
+- #io-channel-cells = <1>; As ADC has multiple outputs
+- clocks                From common clock binding: handle to adc clock.
+- clock-names           From common clock binding: Shall be "adc".
+- vdd-supply            VDD input supply.
+
+Note: child nodes can be added for auto probing from device tree.
+
+Example: adding device info in dtsi file
+
+adc: adc@12D10000 {
+        compatible = "samsung,exynos-adc-v1";
+        reg = <0x12D10000 0x100>, <0x10040718 0x4>;
+        interrupts = <0 106 0>;
+        #io-channel-cells = <1>;
+        io-channel-ranges;
+
+        clocks = <&clock 303>;
+        clock-names = "adc";
+
+        vdd-supply = <&buck5_reg>;
+};
+
+
+Example: Adding child nodes in dts file
+
+adc@12D10000 {
+
+        /* NTC thermistor is a hwmon device */
+        ncp15wb473@0 {
+                compatible = "ntc,ncp15wb473";
+                pullup-uV = <1800000>;
+                pullup-ohm = <47000>;
+                pulldown-ohm = <0>;
+                io-channels = <&adc 4>;
+        };
+};
+
+Note: Does not apply to ADC driver under arch/arm/plat-samsung/
+Note: The child node can be added under the adc node or separately.
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index a33628759d36..d933af370697 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -98,7 +98,7 @@ announce the pinrange to the pin ctrl subsystem. For example,
                 compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
                 reg = <0x1460 0x18>;
                 gpio-controller;
-                gpio-ranges = <&pinctrl1 20 10>, <&pinctrl2 50 20>;
+                gpio-ranges = <&pinctrl1 0 20 10>, <&pinctrl2 10 50 20>;
 
     }
 
@@ -107,8 +107,8 @@ where,
 
    Next values specify the base pin and number of pins for the range
    handled by 'qe_pio_e' gpio. In the given example from base pin 20 to
-   pin 29 under pinctrl1 and pin 50 to pin 69 under pinctrl2 is handled
-   by this gpio controller.
+   pin 29 under pinctrl1 with gpio offset 0 and pin 50 to pin 69 under
+   pinctrl2 with gpio offset 10 is handled by this gpio controller.
 
 The pinctrl node must have "#gpio-range-cells" property to show number of
 arguments to pass with phandle from gpio controllers node.
diff --git a/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
new file mode 100644
index 000000000000..c6f66674f19c
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/ntc_thermistor.txt
@@ -0,0 +1,29 @@
+NTC Thermistor hwmon sensors
+-------------------------------
+
+Requires node properties:
+- "compatible" value : one of
+        "ntc,ncp15wb473"
+        "ntc,ncp18wb473"
+        "ntc,ncp21wb473"
+        "ntc,ncp03wb473"
+        "ntc,ncp15wl333"
+- "pullup-uv"   Pull up voltage in micro volts
+- "pullup-ohm"  Pull up resistor value in ohms
+- "pulldown-ohm" Pull down resistor value in ohms
+- "connected-positive" Always ON, If not specified.
+                Status change is possible.
+- "io-channels" Channel node of ADC to be used for
+                conversion.
+
+Read more about iio bindings at
+        Documentation/devicetree/bindings/iio/iio-bindings.txt
+
+Example:
+        ncp15wb473@0 {
+                compatible = "ntc,ncp15wb473";
+                pullup-uv = <1800000>;
+                pullup-ohm = <47000>;
+                pulldown-ohm = <0>;
+                io-channels = <&adc 3>;
+        };
diff --git a/Documentation/devicetree/bindings/iio/iio-bindings.txt b/Documentation/devicetree/bindings/iio/iio-bindings.txt
new file mode 100644
index 000000000000..0b447d9ad196
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/iio-bindings.txt
@@ -0,0 +1,97 @@
+This binding is derived from clock bindings, and based on suggestions
+from Lars-Peter Clausen [1].
+
+Sources of IIO channels can be represented by any node in the device
+tree. Those nodes are designated as IIO providers. IIO consumer
+nodes use a phandle and IIO specifier pair to connect IIO provider
+outputs to IIO inputs. Similar to the gpio specifiers, an IIO
+specifier is an array of one or more cells identifying the IIO
+output on a device. The length of an IIO specifier is defined by the
+value of a #io-channel-cells property in the IIO provider node.
+
+[1] http://marc.info/?l=linux-iio&m=135902119507483&w=2
+
+==IIO providers==
+
+Required properties:
+#io-channel-cells: Number of cells in an IIO specifier; Typically 0 for nodes
+                   with a single IIO output and 1 for nodes with multiple
+                   IIO outputs.
+
+Example for a simple configuration with no trigger:
+
+        adc: voltage-sensor@35 {
+                compatible = "maxim,max1139";
+                reg = <0x35>;
+                #io-channel-cells = <1>;
+        };
+
+Example for a configuration with trigger:
+
+        adc@35 {
+                compatible = "some-vendor,some-adc";
+                reg = <0x35>;
+
+                adc1: iio-device@0 {
+                        #io-channel-cells = <1>;
+                        /* other properties */
+                };
+                adc2: iio-device@1 {
+                        #io-channel-cells = <1>;
+                        /* other properties */
+                };
+        };
+
+==IIO consumers==
+
+Required properties:
+io-channels:    List of phandle and IIO specifier pairs, one pair
+                for each IIO input to the device. Note: if the
+                IIO provider specifies '0' for #io-channel-cells,
+                then only the phandle portion of the pair will appear.
+
+Optional properties:
+io-channel-names:
+                List of IIO input name strings sorted in the same
+                order as the io-channels property. Consumers drivers
+                will use io-channel-names to match IIO input names
+                with IIO specifiers.
+io-channel-ranges:
+                Empty property indicating that child nodes can inherit named
+                IIO channels from this node. Useful for bus nodes to provide
+                and IIO channel to their children.
+
+For example:
+
+        device {
+                io-channels = <&adc 1>, <&ref 0>;
+                io-channel-names = "vcc", "vdd";
+        };
+
+This represents a device with two IIO inputs, named "vcc" and "vdd".
+The vcc channel is connected to output 1 of the &adc device, and the
+vdd channel is connected to output 0 of the &ref device.
+
+==Example==
+
+        adc: max1139@35 {
+                compatible = "maxim,max1139";
+                reg = <0x35>;
+                #io-channel-cells = <1>;
+        };
+
+        ...
+
+        iio_hwmon {
+                compatible = "iio-hwmon";
+                io-channels = <&adc 0>, <&adc 1>, <&adc 2>,
+                        <&adc 3>, <&adc 4>, <&adc 5>,
+                        <&adc 6>, <&adc 7>, <&adc 8>,
+                        <&adc 9>;
+        };
+
+        some_consumer {
+                compatible = "some-consumer";
+                io-channels = <&adc 10>, <&adc 11>;
+                io-channel-names = "adc1", "adc2";
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 2c81e45f1374..08f0c3d01575 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -1,7 +1,9 @@
 One-register-per-pin type device tree based pinctrl driver
 
 Required properties:
-- compatible : "pinctrl-single"
+- compatible : "pinctrl-single" or "pinconf-single".
+  "pinctrl-single" means that pinconf isn't supported.
+  "pinconf-single" means that generic pinconf is supported.
 
 - reg : offset and length of the register set for the mux registers
 
@@ -14,9 +16,61 @@ Optional properties:
 - pinctrl-single,function-off : function off mode for disabled state if
   available and same for all registers; if not specified, disabling of
   pin functions is ignored
+
 - pinctrl-single,bit-per-mux : boolean to indicate that one register controls
   more than one pin
 
+- pinctrl-single,drive-strength : array of value that are used to configure
+  drive strength in the pinmux register. They're value of drive strength
+  current and drive strength mask.
+
+                /* drive strength current, mask */
+                pinctrl-single,power-source = <0x30 0xf0>;
+
+- pinctrl-single,bias-pullup : array of value that are used to configure the
+  input bias pullup in the pinmux register.
+
+                /* input, enabled pullup bits, disabled pullup bits, mask */
+                pinctrl-single,bias-pullup = <0 1 0 1>;
+
+- pinctrl-single,bias-pulldown : array of value that are used to configure the
+  input bias pulldown in the pinmux register.
+
+                /* input, enabled pulldown bits, disabled pulldown bits, mask */
+                pinctrl-single,bias-pulldown = <2 2 0 2>;
+
+  * Two bits to control input bias pullup and pulldown: User should use
+    pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. One bit means
+    pullup, and the other one bit means pulldown.
+  * Three bits to control input bias enable, pullup and pulldown. User should
+    use pinctrl-single,bias-pullup & pinctrl-single,bias-pulldown. Input bias
+    enable bit should be included in pullup or pulldown bits.
+  * Although driver could set PIN_CONFIG_BIAS_DISABLE, there's no property as
+    pinctrl-single,bias-disable. Because pinctrl single driver could implement
+    it by calling pulldown, pullup disabled.
+
+- pinctrl-single,input-schmitt : array of value that are used to configure
+  input schmitt in the pinmux register. In some silicons, there're two input
+  schmitt value (rising-edge & falling-edge) in the pinmux register.
+
+                /* input schmitt value, mask */
+                pinctrl-single,input-schmitt = <0x30 0x70>;
+
+- pinctrl-single,input-schmitt-enable : array of value that are used to
+  configure input schmitt enable or disable in the pinmux register.
+
+                /* input, enable bits, disable bits, mask */
+                pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
+
+- pinctrl-single,gpio-range : list of value that are used to configure a GPIO
+  range. They're value of subnode phandle, pin base in pinctrl device, pin
+  number in this range, GPIO function value of this GPIO range.
+  The number of parameters is depend on #pinctrl-single,gpio-range-cells
+  property.
+
+                /* pin base, nr pins & gpio function */
+                pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
+
 This driver assumes that there is only one register for each pin (unless the
 pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
 specified in the pinctrl-bindings.txt document in this directory.
@@ -42,6 +96,20 @@ Where 0xdc is the offset from the pinctrl register base address for the
 device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
 be used when applying this change to the register.
 
+
+Optional sub-node: In case some pins could be configured as GPIO in the pinmux
+register, those pins could be defined as a GPIO range. This sub-node is required
+by pinctrl-single,gpio-range property.
+
+Required properties in sub-node:
+- #pinctrl-single,gpio-range-cells : the number of parameters after phandle in
+  pinctrl-single,gpio-range property.
+
+        range: gpio-range {
+                #pinctrl-single,gpio-range-cells = <3>;
+        };
+
+
 Example:
 
 /* SoC common file */
@@ -58,7 +126,7 @@ pmx_core: pinmux@4a100040 {
 
 /* second controller instance for pins in wkup domain */
 pmx_wkup: pinmux@4a31e040 {
-        compatible = "pinctrl-single;
+        compatible = "pinctrl-single";
         reg = <0x4a31e040 0x0038>;
         #address-cells = <1>;
         #size-cells = <0>;
@@ -76,6 +144,29 @@ control_devconf0: pinmux@48002274 {
         pinctrl-single,function-mask = <0x5F>;
 };
 
+/* third controller instance for pins in gpio domain */
+pmx_gpio: pinmux@d401e000 {
+        compatible = "pinconf-single";
+        reg = <0xd401e000 0x0330>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        pinctrl-single,register-width = <32>;
+        pinctrl-single,function-mask = <7>;
+
+        /* sparse GPIO range could be supported */
+        pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1
+                                &range 12 1 0 &range 13 29 1
+                                &range 43 1 0 &range 44 49 1
+                                &range 94 1 1 &range 96 2 1>;
+
+        range: gpio-range {
+                #pinctrl-single,gpio-range-cells = <3>;
+        };
+};
+
+
 /* board specific .dts file */
 
 &pmx_core {
@@ -96,6 +187,15 @@ control_devconf0: pinmux@48002274 {
                 >;
         };
 
+        uart0_pins: pinmux_uart0_pins {
+                pinctrl-single,pins = <
+                        0x208 0         /* UART0_RXD (IOCFG138) */
+                        0x20c 0         /* UART0_TXD (IOCFG139) */
+                >;
+                pinctrl-single,bias-pulldown = <0 2 2>;
+                pinctrl-single,bias-pullup = <0 1 1>;
+        };
+
         /* map uart2 pins */
         uart2_pins: pinmux_uart2_pins {
                 pinctrl-single,pins = <
@@ -122,6 +222,11 @@ control_devconf0: pinmux@48002274 {
 
 };
 
+&uart1 {
+       pinctrl-names = "default";
+       pinctrl-0 = <&uart0_pins>;
+};
+
 &uart2 {
        pinctrl-names = "default";
        pinctrl-0 = <&uart2_pins>;
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 4598a47aa0cd..c70fca146e91 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,6 +7,7 @@ on-chip controllers onto these pads.
 
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
   - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
@@ -105,6 +106,8 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
 
    - compatible: identifies the type of the external wakeup interrupt controller
      The possible values are:
+     - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C64xx SoCs,
      - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
        found on Samsung Exynos4210 SoC.
    - interrupt-parent: phandle of the interrupt parent to which the external
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
new file mode 100644
index 000000000000..1a1b7cfa4845
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/dwc2.txt
@@ -0,0 +1,15 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-----------------------------------------------------
+
+Required properties:
+- compatible : "snps,dwc2"
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+
+Example:
+
+        usb@101c0000 {
+                compatible = "ralink,rt3050-usb, snps,dwc2";
+                reg = <0x101c0000 40000>;
+                interrupts = <18>;
+        };
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index 07654f0338b6..8071ac20d4b3 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -26,7 +26,7 @@ Required properties:
 - crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565"
+  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
index c870b6478ec8..2871e218a0fb 100644
--- a/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+++ b/Documentation/devicetree/bindings/video/via,vt8500-fb.txt
@@ -5,58 +5,32 @@ Required properties:
 - compatible : "via,vt8500-fb"
 - reg : Should contain 1 register ranges(address and length)
 - interrupts : framebuffer controller interrupt
-- display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-        This should be in the board dts.
-- default-mode: a videomode within the display with timing parameters
-        as specified below.
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-        fb@d800e400 {
+        fb@d8050800 {
                 compatible = "via,vt8500-fb";
                 reg = <0xd800e400 0x400>;
                 interrupts = <12>;
-                display = <&display>;
-                default-mode = <&mode0>;
-        };
-
-VIA VT8500 Display
------------------------------------------------------
-Required properties (as per of_videomode_helper):
-
- - hactive, vactive: Display resolution
- - hfront-porch, hback-porch, hsync-len: Horizontal Display timing parameters
-   in pixels
-   vfront-porch, vback-porch, vsync-len: Vertical display timing parameters in
-   lines
- - clock: displayclock in Hz
- - bpp: lcd panel bit-depth.
-        <16> for RGB565, <32> for RGB888
-
-Optional properties (as per of_videomode_helper):
- - width-mm, height-mm: Display dimensions in mm
- - hsync-active-high (bool): Hsync pulse is active high
- - vsync-active-high (bool): Vsync pulse is active high
- - interlaced (bool): This is an interlaced mode
- - doublescan (bool): This is a doublescan mode
+                bits-per-pixel = <16>;
 
-Example:
-        display: display@0 {
-                modes {
-                        mode0: mode@0 {
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: 800x480 {
+                                clock-frequency = <0>; /* unused but required */
                                 hactive = <800>;
                                 vactive = <480>;
-                                hback-porch = <88>;
                                 hfront-porch = <40>;
+                                hback-porch = <88>;
                                 hsync-len = <0>;
                                 vback-porch = <32>;
                                 vfront-porch = <11>;
                                 vsync-len = <1>;
-                                clock = <0>;    /* unused but required */
-                                bpp = <16>;     /* non-standard but required */
                         };
                 };
         };
+
diff --git a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
index 3d325e1d11ee..0bcadb2840a5 100644
--- a/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
+++ b/Documentation/devicetree/bindings/video/wm,wm8505-fb.txt
@@ -4,20 +4,30 @@ Wondermedia WM8505 Framebuffer
 Required properties:
 - compatible : "wm,wm8505-fb"
 - reg : Should contain 1 register ranges(address and length)
-- via,display: a phandle pointing to the display node
+- bits-per-pixel : bit depth of framebuffer (16 or 32)
 
-Required nodes:
-- display: a display node is required to initialize the lcd panel
-        This should be in the board dts. See definition in
-        Documentation/devicetree/bindings/video/via,vt8500-fb.txt
-- default-mode: a videomode node as specified in
-        Documentation/devicetree/bindings/video/via,vt8500-fb.txt
+Required subnodes:
+- display-timings: see display-timing.txt for information
 
 Example:
 
-        fb@d8050800 {
+        fb@d8051700 {
                 compatible = "wm,wm8505-fb";
-                reg = <0xd8050800 0x200>;
-                display = <&display>;
-                default-mode = <&mode0>;
+                reg = <0xd8051700 0x200>;
+                bits-per-pixel = <16>;
+
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: 800x480 {
+                                clock-frequency = <0>; /* unused but required */
+                                hactive = <800>;
+                                vactive = <480>;
+                                hfront-porch = <40>;
+                                hback-porch = <88>;
+                                hsync-len = <0>;
+                                vback-porch = <32>;
+                                vfront-porch = <11>;
+                                vsync-len = <1>;
+                        };
+                };
         };
diff --git a/Documentation/hwmon/adt7410 b/Documentation/hwmon/adt7410
index 58150c480e56..9817941e5f19 100644
--- a/Documentation/hwmon/adt7410
+++ b/Documentation/hwmon/adt7410
@@ -12,29 +12,42 @@ Supported chips:
     Addresses scanned: None
     Datasheet: Publicly available at the Analog Devices website
                http://www.analog.com/static/imported-files/data_sheets/ADT7420.pdf
+  * Analog Devices ADT7310
+    Prefix: 'adt7310'
+    Addresses scanned: None
+    Datasheet: Publicly available at the Analog Devices website
+               http://www.analog.com/static/imported-files/data_sheets/ADT7310.pdf
+  * Analog Devices ADT7320
+    Prefix: 'adt7320'
+    Addresses scanned: None
+    Datasheet: Publicly available at the Analog Devices website
+               http://www.analog.com/static/imported-files/data_sheets/ADT7320.pdf
 
 Author: Hartmut Knaack <knaack.h@gmx.de>
 
 Description
 -----------
 
-The ADT7410 is a temperature sensor with rated temperature range of -55°C to
-+150°C. It has a high accuracy of +/-0.5°C and can be operated at a resolution
-of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an INT pin to
-indicate that a minimum or maximum temperature set point has been exceeded, as
-well as a critical temperature (CT) pin to indicate that the critical
-temperature set point has been exceeded. Both pins can be set up with a common
-hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events. Both
-pins can individually set to be active-low or active-high, while the whole
-device can either run in comparator mode or interrupt mode. The ADT7410
-supports continous temperature sampling, as well as sampling one temperature
-value per second or even justget one sample on demand for power saving.
-Besides, it can completely power down its ADC, if power management is
-required.
-
-The ADT7420 is register compatible, the only differences being the package,
-a slightly narrower operating temperature range (-40°C to +150°C), and a
-better accuracy (0.25°C instead of 0.50°C.)
+The ADT7310/ADT7410 is a temperature sensor with rated temperature range of
+-55°C to +150°C. It has a high accuracy of +/-0.5°C and can be operated at a
+resolution of 13 bits (0.0625°C) or 16 bits (0.0078°C). The sensor provides an
+INT pin to indicate that a minimum or maximum temperature set point has been
+exceeded, as well as a critical temperature (CT) pin to indicate that the
+critical temperature set point has been exceeded. Both pins can be set up with a
+common hysteresis of 0°C - 15°C and a fault queue, ranging from 1 to 4 events.
+Both pins can individually set to be active-low or active-high, while the whole
+device can either run in comparator mode or interrupt mode. The ADT7410 supports
+continuous temperature sampling, as well as sampling one temperature value per
+second or even just get one sample on demand for power saving. Besides, it can
+completely power down its ADC, if power management is required.
+
+The ADT7320/ADT7420 is register compatible, the only differences being the
+package, a slightly narrower operating temperature range (-40°C to +150°C), and
+a better accuracy (0.25°C instead of 0.50°C.)
+
+The difference between the ADT7310/ADT7320 and ADT7410/ADT7420 is the control
+interface, the ADT7310 and ADT7320 use SPI while the ADT7410 and ADT7420 use
+I2C.
 
 Configuration Notes
 -------------------
diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066
index 26025e419d35..c1b57d72efc3 100644
--- a/Documentation/hwmon/lm25066
+++ b/Documentation/hwmon/lm25066
@@ -1,7 +1,13 @@
-Kernel driver max8688
+Kernel driver lm25066
 =====================
 
 Supported chips:
+  * TI LM25056
+    Prefix: 'lm25056'
+    Addresses scanned: -
+    Datasheets:
+        http://www.ti.com/lit/gpn/lm25056
+        http://www.ti.com/lit/gpn/lm25056a
   * National Semiconductor LM25066
     Prefix: 'lm25066'
     Addresses scanned: -
@@ -25,8 +31,9 @@ Author: Guenter Roeck <linux@roeck-us.net>
 Description
 -----------
 
-This driver supports hardware montoring for National Semiconductor LM25066,
-LM5064, and LM5064 Power Management, Monitoring, Control, and Protection ICs.
+This driver supports hardware montoring for National Semiconductor / TI LM25056,
+LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
+Protection ICs.
 
 The driver is a client driver to the core PMBus driver. Please see
 Documentation/hwmon/pmbus for details on PMBus client drivers.
@@ -60,14 +67,19 @@ in1_max			Maximum input voltage.
 in1_min_alarm           Input voltage low alarm.
 in1_max_alarm           Input voltage high alarm.
 
-in2_label               "vout1"
-in2_input               Measured output voltage.
-in2_average             Average measured output voltage.
-in2_min                 Minimum output voltage.
-in2_min_alarm           Output voltage low alarm.
-
-in3_label               "vout2"
-in3_input               Measured voltage on vaux pin
+in2_label               "vmon"
+in2_input               Measured voltage on VAUX pin
+in2_min                 Minimum VAUX voltage (LM25056 only).
+in2_max                 Maximum VAUX voltage (LM25056 only).
+in2_min_alarm           VAUX voltage low alarm (LM25056 only).
+in2_max_alarm           VAUX voltage high alarm (LM25056 only).
+
+in3_label               "vout1"
+                        Not supported on LM25056.
+in3_input               Measured output voltage.
+in3_average             Average measured output voltage.
+in3_min                 Minimum output voltage.
+in3_min_alarm           Output voltage low alarm.
 
 curr1_label             "iin"
 curr1_input             Measured input current.
diff --git a/Documentation/hwmon/lm95234 b/Documentation/hwmon/lm95234
new file mode 100644
index 000000000000..a0e95ddfd372
--- /dev/null
+++ b/Documentation/hwmon/lm95234
@@ -0,0 +1,36 @@
+Kernel driver lm95234
+=====================
+
+Supported chips:
+  * National Semiconductor / Texas Instruments LM95234
+    Addresses scanned: I2C 0x18, 0x4d, 0x4e
+    Datasheet: Publicly available at the Texas Instruments website
+               http://www.ti.com/product/lm95234
+
+
+Author: Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+LM95234 is an 11-bit digital temperature sensor with a 2-wire System Management
+Bus (SMBus) interface and TrueTherm technology that can very accurately monitor
+the temperature of four remote diodes as well as its own temperature.
+The four remote diodes can be external devices such as microprocessors,
+graphics processors or diode-connected 2N3904s. The LM95234's TruTherm
+beta compensation technology allows sensing of 90 nm or 65 nm process
+thermal diodes accurately.
+
+All temperature values are given in millidegrees Celsius. Temperature
+is provided within a range of -127 to +255 degrees (+127.875 degrees for
+the internal sensor). Resolution depends on temperature input and range.
+
+Each sensor has its own maximum limit, but the hysteresis is common to all
+channels. The hysteresis is configurable with the tem1_max_hyst attribute and
+affects the hysteresis on all channels. The first two external sensors also
+have a critical limit.
+
+The lm95234 driver can change its update interval to a fixed set of values.
+It will round up to the next selectable interval. See the datasheet for exact
+values. Reading sensor values more often will do no harm, but will return
+'old' values.
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
index e4d75c606c97..dc0d08c61305 100644
--- a/Documentation/hwmon/ltc2978
+++ b/Documentation/hwmon/ltc2978
@@ -2,6 +2,10 @@ Kernel driver ltc2978
 =====================
 
 Supported chips:
+  * Linear Technology LTC2974
+    Prefix: 'ltc2974'
+    Addresses scanned: -
+    Datasheet: http://www.linear.com/product/ltc2974
   * Linear Technology LTC2978
     Prefix: 'ltc2978'
     Addresses scanned: -
@@ -10,6 +14,10 @@ Supported chips:
     Prefix: 'ltc3880'
     Addresses scanned: -
     Datasheet: http://www.linear.com/product/ltc3880
+  * Linear Technology LTC3883
+    Prefix: 'ltc3883'
+    Addresses scanned: -
+    Datasheet: http://www.linear.com/product/ltc3883
 
 Author: Guenter Roeck <linux@roeck-us.net>
 
@@ -17,9 +25,9 @@ Author: Guenter Roeck <linux@roeck-us.net>
 Description
 -----------
 
-The LTC2978 is an octal power supply monitor, supervisor, sequencer and
-margin controller. The LTC3880 is a dual, PolyPhase DC/DC synchronous
-step-down switching regulator controller.
+LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
+monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
+is a single phase step-down DC/DC controller.
 
 
 Usage Notes
@@ -41,63 +49,90 @@ Sysfs attributes
 in1_label               "vin"
 in1_input               Measured input voltage.
 in1_min                 Minimum input voltage.
-in1_max                 Maximum input voltage.
-in1_lcrit               Critical minimum input voltage.
+in1_max                 Maximum input voltage. LTC2974 and LTC2978 only.
+in1_lcrit               Critical minimum input voltage. LTC2974 and LTC2978
+                        only.
 in1_crit                Critical maximum input voltage.
 in1_min_alarm           Input voltage low alarm.
-in1_max_alarm           Input voltage high alarm.
-in1_lcrit_alarm         Input voltage critical low alarm.
+in1_max_alarm           Input voltage high alarm. LTC2974 and LTC2978 only.
+in1_lcrit_alarm         Input voltage critical low alarm. LTC2974 and LTC2978
+                        only.
 in1_crit_alarm          Input voltage critical high alarm.
-in1_lowest              Lowest input voltage. LTC2978 only.
+in1_lowest              Lowest input voltage. LTC2974 and LTC2978 only.
 in1_highest             Highest input voltage.
-in1_reset_history       Reset history. Writing into this attribute will reset
-                        history for all attributes.
-
-in[2-9]_label           "vout[1-8]". Channels 3 to 9 on LTC2978 only.
-in[2-9]_input           Measured output voltage.
-in[2-9]_min             Minimum output voltage.
-in[2-9]_max             Maximum output voltage.
-in[2-9]_lcrit           Critical minimum output voltage.
-in[2-9]_crit            Critical maximum output voltage.
-in[2-9]_min_alarm       Output voltage low alarm.
-in[2-9]_max_alarm       Output voltage high alarm.
-in[2-9]_lcrit_alarm     Output voltage critical low alarm.
-in[2-9]_crit_alarm      Output voltage critical high alarm.
-in[2-9]_lowest          Lowest output voltage. LTC2978 only.
-in[2-9]_highest         Lowest output voltage.
-in[2-9]_reset_history   Reset history. Writing into this attribute will reset
-                        history for all attributes.
-
-temp[1-3]_input         Measured temperature.
+in1_reset_history       Reset input voltage history.
+
+in[N]_label             "vout[1-8]".
+                        LTC2974: N=2-5
+                        LTC2978: N=2-9
+                        LTC3880: N=2-3
+                        LTC3883: N=2
+in[N]_input             Measured output voltage.
+in[N]_min               Minimum output voltage.
+in[N]_max               Maximum output voltage.
+in[N]_lcrit             Critical minimum output voltage.
+in[N]_crit              Critical maximum output voltage.
+in[N]_min_alarm         Output voltage low alarm.
+in[N]_max_alarm         Output voltage high alarm.
+in[N]_lcrit_alarm       Output voltage critical low alarm.
+in[N]_crit_alarm        Output voltage critical high alarm.
+in[N]_lowest            Lowest output voltage. LTC2974 and LTC2978 only.
+in[N]_highest           Highest output voltage.
+in[N]_reset_history     Reset output voltage history.
+
+temp[N]_input           Measured temperature.
+                        On LTC2974, temp[1-4] report external temperatures,
+                        and temp5 reports the chip temperature.
                         On LTC2978, only one temperature measurement is
-                        supported and reflects the internal temperature.
+                        supported and reports the chip temperature.
                         On LTC3880, temp1 and temp2 report external
-                        temperatures, and temp3 reports the internal
-                        temperature.
-temp[1-3]_min           Mimimum temperature.
-temp[1-3]_max           Maximum temperature.
-temp[1-3]_lcrit         Critical low temperature.
-temp[1-3]_crit          Critical high temperature.
-temp[1-3]_min_alarm     Chip temperature low alarm.
-temp[1-3]_max_alarm     Chip temperature high alarm.
-temp[1-3]_lcrit_alarm   Chip temperature critical low alarm.
-temp[1-3]_crit_alarm    Chip temperature critical high alarm.
-temp[1-3]_lowest        Lowest measured temperature. LTC2978 only.
-temp[1-3]_highest       Highest measured temperature.
-temp[1-3]_reset_history Reset history. Writing into this attribute will reset
-                        history for all attributes.
-
-power[1-2]_label        "pout[1-2]". LTC3880 only.
-power[1-2]_input        Measured power.
-
-curr1_label             "iin". LTC3880 only.
+                        temperatures, and temp3 reports the chip temperature.
+                        On LTC3883, temp1 reports an external temperature,
+                        and temp2 reports the chip temperature.
+temp[N]_min             Mimimum temperature. LTC2974 and LTC2978 only.
+temp[N]_max             Maximum temperature.
+temp[N]_lcrit           Critical low temperature.
+temp[N]_crit            Critical high temperature.
+temp[N]_min_alarm       Temperature low alarm. LTC2974 and LTC2978 only.
+temp[N]_max_alarm       Temperature high alarm.
+temp[N]_lcrit_alarm     Temperature critical low alarm.
+temp[N]_crit_alarm      Temperature critical high alarm.
+temp[N]_lowest          Lowest measured temperature. LTC2974 and LTC2978 only.
+                        Not supported for chip temperature sensor on LTC2974.
+temp[N]_highest         Highest measured temperature. Not supported for chip
+                        temperature sensor on LTC2974.
+temp[N]_reset_history   Reset temperature history. Not supported for chip
+                        temperature sensor on LTC2974.
+
+power1_label            "pin". LTC3883 only.
+power1_input            Measured input power.
+
+power[N]_label          "pout[1-4]".
+                        LTC2974: N=1-4
+                        LTC2978: Not supported
+                        LTC3880: N=1-2
+                        LTC3883: N=2
+power[N]_input          Measured output power.
+
+curr1_label             "iin". LTC3880 and LTC3883 only.
 curr1_input             Measured input current.
 curr1_max               Maximum input current.
 curr1_max_alarm         Input current high alarm.
-
-curr[2-3]_label         "iout[1-2]". LTC3880 only.
-curr[2-3]_input         Measured input current.
-curr[2-3]_max           Maximum input current.
-curr[2-3]_crit          Critical input current.
-curr[2-3]_max_alarm     Input current high alarm.
-curr[2-3]_crit_alarm    Input current critical high alarm.
+curr1_highest           Highest input current. LTC3883 only.
+curr1_reset_history     Reset input current history. LTC3883 only.
+
+curr[N]_label           "iout[1-4]".
+                        LTC2974: N=1-4
+                        LTC2978: not supported
+                        LTC3880: N=2-3
+                        LTC3883: N=2
+curr[N]_input           Measured output current.
+curr[N]_max             Maximum output current.
+curr[N]_crit            Critical high output current.
+curr[N]_lcrit           Critical low output current. LTC2974 only.
+curr[N]_max_alarm       Output current high alarm.
+curr[N]_crit_alarm      Output current critical high alarm.
+curr[N]_lcrit_alarm     Output current critical low alarm. LTC2974 only.
+curr[N]_lowest          Lowest output current. LTC2974 only.
+curr[N]_highest         Highest output current.
+curr[N]_reset_history   Reset output current history.
diff --git a/Documentation/hwmon/nct6775 b/Documentation/hwmon/nct6775
new file mode 100644
index 000000000000..4e9ef60e8c6c
--- /dev/null
+++ b/Documentation/hwmon/nct6775
@@ -0,0 +1,188 @@
+Note
+====
+
+This driver supersedes the NCT6775F and NCT6776F support in the W83627EHF
+driver.
+
+Kernel driver NCT6775
+=====================
+
+Supported chips:
+  * Nuvoton NCT5572D/NCT6771F/NCT6772F/NCT6775F/W83677HG-I
+    Prefix: 'nct6775'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
+  * Nuvoton NCT5577D/NCT6776D/NCT6776F
+    Prefix: 'nct6776'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
+  * Nuvoton NCT5532D/NCT6779D
+    Prefix: 'nct6779'
+    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 NCT6775F, NCT6776F, and NCT6779D
+and compatible super I/O chips.
+
+The chips support up to 25 temperature monitoring sources. Up to 6 of those are
+direct temperature sensor inputs, the others are special sources such as PECI,
+PCH, and SMBUS. Depending on the chip type, 2 to 6 of the temperature sources
+can be monitored and compared against minimum, maximum, and critical
+temperatures. The driver reports up to 10 of the temperatures to the user.
+There are 4 to 5 fan rotation speed sensors, 8 to 15 analog voltage sensors,
+one VID, alarms with beep warnings (control unimplemented), and some automatic
+fan regulation strategies (plus manual fan control mode).
+
+The temperature sensor sources on all chips are configurable. The configured
+source for each of the temperature sensors is provided in tempX_label.
+
+Temperatures are measured in degrees Celsius and measurement resolution is
+either 1 degC or 0.5 degC, depending on the temperature source and
+configuration. An alarm is triggered when the temperature gets higher than
+the high limit; it stays on until the temperature falls below the hysteresis
+value. Alarms are only supported for temp1 to temp6, depending on the chip type.
+
+Fan rotation speeds are reported in RPM (rotations per minute). An alarm is
+triggered if the rotation speed has dropped below a programmable limit. On
+NCT6775F, fan readings can be divided by a programmable divider (1, 2, 4, 8,
+16, 32, 64 or 128) to give the readings more range or accuracy; the other chips
+do not have a fan speed divider. The driver sets the most suitable fan divisor
+itself; specifically, it increases the divider value each time a fan speed
+reading returns an invalid value, and it reduces it if the fan speed reading
+is lower than optimal. Some fans might not be present because they share pins
+with other functions.
+
+Voltage sensors (also known as IN sensors) report their values in millivolts.
+An alarm is triggered if the voltage has crossed a programmable minimum
+or maximum limit.
+
+The driver supports automatic fan control mode known as Thermal Cruise.
+In this mode, the chip attempts to keep the measured temperature in a
+predefined temperature range. If the temperature goes out of range, fan
+is driven slower/faster to reach the predefined range again.
+
+The mode works for fan1-fan5.
+
+sysfs attributes
+----------------
+
+pwm[1-5] - this file stores PWM duty cycle or DC value (fan speed) in range:
+           0 (lowest speed) to 255 (full)
+
+pwm[1-5]_enable - this file controls mode of fan/temperature control:
+        * 0 Fan control disabled (fans set to maximum speed)
+        * 1 Manual mode, write to pwm[0-5] any value 0-255
+        * 2 "Thermal Cruise" mode
+        * 3 "Fan Speed Cruise" mode
+        * 4 "Smart Fan III" mode (NCT6775F only)
+        * 5 "Smart Fan IV" mode
+
+pwm[1-5]_mode - controls if output is PWM or DC level
+        * 0 DC output
+        * 1 PWM output
+
+Common fan control attributes
+-----------------------------
+
+pwm[1-5]_temp_sel       Temperature source. Value is temperature sensor index.
+                        For example, select '1' for temp1_input.
+pwm[1-5]_weight_temp_sel
+                        Secondary temperature source. Value is temperature
+                        sensor index. For example, select '1' for temp1_input.
+                        Set to 0 to disable secondary temperature control.
+
+If secondary temperature functionality is enabled, it is controlled with the
+following attributes.
+
+pwm[1-5]_weight_duty_step
+                        Duty step size.
+pwm[1-5]_weight_temp_step
+                        Temperature step size. With each step over
+                        temp_step_base, the value of weight_duty_step is added
+                        to the current pwm value.
+pwm[1-5]_weight_temp_step_base
+                        Temperature at which secondary temperature control kicks
+                        in.
+pwm[1-5]_weight_temp_step_tol
+                        Temperature step tolerance.
+
+Thermal Cruise mode (2)
+-----------------------
+
+If the temperature is in the range defined by:
+
+pwm[1-5]_target_temp    Target temperature, unit millidegree Celsius
+                        (range 0 - 127000)
+pwm[1-5]_temp_tolerance
+                        Target temperature tolerance, unit millidegree Celsius
+
+there are no changes to fan speed. Once the temperature leaves the interval, fan
+speed increases (if temperature is higher that desired) or decreases (if
+temperature is lower than desired), using the following limits and time
+intervals.
+
+pwm[1-5]_start          fan pwm start value (range 1 - 255), to start fan
+                        when the temperature is above defined range.
+pwm[1-5]_floor          lowest fan pwm (range 0 - 255) if temperature is below
+                        the defined range. If set to 0, the fan is expected to
+                        stop if the temperature is below the defined range.
+pwm[1-5]_step_up_time   milliseconds before fan speed is increased
+pwm[1-5]_step_down_time milliseconds before fan speed is decreased
+pwm[1-5]_stop_time      how many milliseconds must elapse to switch
+                        corresponding fan off (when the temperature was below
+                        defined range).
+
+Speed Cruise mode (3)
+---------------------
+
+This modes tries to keep the fan speed constant.
+
+fan[1-5]_target         Target fan speed
+fan[1-5]_tolerance
+                        Target speed tolerance
+
+
+Untested; use at your own risk.
+
+Smart Fan IV mode (5)
+---------------------
+
+This mode offers multiple slopes to control the fan speed. The slopes can be
+controlled by setting the pwm and temperature attributes. When the temperature
+rises, the chip will calculate the DC/PWM output based on the current slope.
+There are up to seven data points depending on the chip type. Subsequent data
+points should be set to higher temperatures and higher pwm values to achieve
+higher fan speeds with increasing temperature. The last data point reflects
+critical temperature mode, in which the fans should run at full speed.
+
+pwm[1-5]_auto_point[1-7]_pwm
+                        pwm value to be set if temperature reaches matching
+                        temperature range.
+pwm[1-5]_auto_point[1-7]_temp
+                        Temperature over which the matching pwm is enabled.
+pwm[1-5]_temp_tolerance
+                        Temperature tolerance, unit millidegree Celsius
+pwm[1-5]_crit_temp_tolerance
+                        Temperature tolerance for critical temperature,
+                        unit millidegree Celsius
+
+pwm[1-5]_step_up_time   milliseconds before fan speed is increased
+pwm[1-5]_step_down_time milliseconds before fan speed is decreased
+
+Usage Notes
+-----------
+
+On various ASUS boards with NCT6776F, it appears that CPUTIN is not really
+connected to anything and floats, or that it is connected to some non-standard
+temperature measurement device. As a result, the temperature reported on CPUTIN
+will not reflect a usable value. It often reports unreasonably high
+temperatures, and in some cases the reported temperature declines if the actual
+temperature increases (similar to the raw PECI temperature value - see PECI
+specification for details). CPUTIN should therefore be be ignored on ASUS
+boards. The CPU temperature on ASUS boards is reported from PECI 0.
diff --git a/Documentation/hwmon/sht15 b/Documentation/hwmon/sht15
index 02850bdfac18..778987d1856f 100644
--- a/Documentation/hwmon/sht15
+++ b/Documentation/hwmon/sht15
@@ -40,7 +40,7 @@ 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 loosing on precision.
+measurement and decrease power consumption, while losing on precision.
 
 Some options may be set directly in the sht15_platform_data structure
 or via sysfs attributes.
diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
index 9fc447249212..f91e3fa7e5ec 100644
--- a/Documentation/hwmon/tmp401
+++ b/Documentation/hwmon/tmp401
@@ -8,8 +8,16 @@ Supported chips:
     Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp401.html
   * Texas Instruments TMP411
     Prefix: 'tmp411'
-    Addresses scanned: I2C 0x4c
+    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
 
 Authors:
          Hans de Goede <hdegoede@redhat.com>
@@ -18,19 +26,19 @@ Authors:
 Description
 -----------
 
-This driver implements support for Texas Instruments TMP401 and
-TMP411 chips. These chips implements one remote and one local
-temperature sensor. Temperature is measured in degrees
+This driver implements support for Texas Instruments TMP401, TMP411,
+TMP431, and TMP432 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 under Temperatures).
+Documentation/hwmon/sysfs-interface under Temperatures).
 
-The TMP411 chip is compatible with TMP401. It provides some additional
-features.
+The TMP411 and TMP431 chips are compatible with TMP401. TMP411 provides
+some additional features.
 
 * Minimum and Maximum temperature measured since power-on, chip-reset
 
@@ -40,3 +48,6 @@ features.
 
   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.
diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100
index 756b57c6b73e..33908a4d68ff 100644
--- a/Documentation/hwmon/zl6100
+++ b/Documentation/hwmon/zl6100
@@ -125,7 +125,7 @@ in2_label		"vmon"
 in2_input               Measured voltage on VMON (ZL2004) or VDRV (ZL9101M,
                         ZL9117M) pin. Reported voltage is 16x the voltage on the
                         pin (adjusted internally by the chip).
-in2_lcrit               Critical minumum VMON/VDRV Voltage.
+in2_lcrit               Critical minimum VMON/VDRV Voltage.
 in2_crit                Critical maximum VMON/VDRV voltage.
 in2_lcrit_alarm         VMON/VDRV voltage critical low alarm.
 in2_crit_alarm          VMON/VDRV voltage critical high alarm.
diff --git a/Documentation/ia64/err_inject.txt b/Documentation/ia64/err_inject.txt
index 223e4f0582d0..9f651c181429 100644
--- a/Documentation/ia64/err_inject.txt
+++ b/Documentation/ia64/err_inject.txt
@@ -882,7 +882,7 @@ int err_inj()
                         cpu=parameters[i].cpu;
                         k = cpu%64;
                         j = cpu/64;
-                        mask[j]=1<<k;
+                        mask[j] = 1UL << k;
 
                         if (sched_setaffinity(0, MASK_SIZE*8, mask)==-1) {
                                 perror("Error sched_setaffinity:");
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 13f1aa09b938..9c7fd988e299 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -297,6 +297,7 @@ Boot into System Kernel
    On ia64, 256M@256M is a generous value that typically works.
    The region may be automatically placed on ia64, see the
    dump-capture kernel config option notes above.
+   If use sparse memory, the size should be rounded to GRANULE boundaries.
 
    On s390x, typically use "crashkernel=xxM". The value of xx is dependent
    on the memory consumption of the kdump system. In general this is not
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4609e81dbc37..8ccbf27aead4 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -596,9 +596,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         is selected automatically. Check
                         Documentation/kdump/kdump.txt for further details.
 
-        crashkernel_low=size[KMG]
-                        [KNL, x86] parts under 4G.
-
         crashkernel=range1:size1[,range2:size2,...][@offset]
                         [KNL] Same as above, but depends on the memory
                         in the running system. The syntax of range is
@@ -606,6 +603,26 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         a memory unit (amount[KMG]). See also
                         Documentation/kdump/kdump.txt for an example.
 
+        crashkernel=size[KMG],high
+                        [KNL, x86_64] range could be above 4G. Allow kernel
+                        to allocate physical memory region from top, so could
+                        be above 4G if system have more than 4G ram installed.
+                        Otherwise memory region will be allocated below 4G, if
+                        available.
+                        It will be ignored if crashkernel=X is specified.
+        crashkernel=size[KMG],low
+                        [KNL, x86_64] range under 4G. When crashkernel=X,high
+                        is passed, kernel could allocate physical memory region
+                        above 4G, that cause second kernel crash on system
+                        that require some amount of low memory, e.g. swiotlb
+                        requires at least 64M+32K low memory.  Kernel would
+                        try to allocate 72M below 4G automatically.
+                        This one let user to specify own low range under 4G
+                        for second kernel instead.
+                        0: to disable low allocation.
+                        It will be ignored when crashkernel=X,high is not used
+                        or memory reserved is below 4G.
+
         cs89x0_dma=     [HW,NET]
                         Format: <dma>
 
@@ -788,6 +805,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         edd=            [EDD]
                         Format: {"off" | "on" | "skip[mbr]"}
 
+        efi_no_storage_paranoia [EFI; X86]
+                        Using this parameter you can use more than 50% of
+                        your efi variable storage. Use this parameter only if
+                        you are really sure that your UEFI does sane gc and
+                        fulfills the spec otherwise your board may brick.
+
         eisa_irq_edge=  [PARISC,HW]
                         See header of drivers/parisc/eisa.c.
 
diff --git a/Documentation/misc-devices/mei/mei-client-bus.txt b/Documentation/misc-devices/mei/mei-client-bus.txt
new file mode 100644
index 000000000000..f83910a8ce76
--- /dev/null
+++ b/Documentation/misc-devices/mei/mei-client-bus.txt
@@ -0,0 +1,138 @@
+Intel(R) Management Engine (ME) Client bus API
+===============================================
+
+
+Rationale
+=========
+MEI misc character device is useful for dedicated applications to send and receive
+data to the many FW appliance found in Intel's ME from the user space.
+However for some of the ME functionalities it make sense to leverage existing software
+stack and expose them through existing kernel subsystems.
+
+In order to plug seamlessly into the kernel device driver model we add kernel virtual
+bus abstraction on top of the MEI driver. This allows implementing linux kernel drivers
+for the various MEI features as a stand alone entities found in their respective subsystem.
+Existing device drivers can even potentially be re-used by adding an MEI CL bus layer to
+the existing code.
+
+
+MEI CL bus API
+===========
+A driver implementation for an MEI Client is very similar to existing bus
+based device drivers. The driver registers itself as an MEI CL bus driver through
+the mei_cl_driver structure:
+
+struct mei_cl_driver {
+        struct device_driver driver;
+        const char *name;
+
+        const struct mei_cl_device_id *id_table;
+
+        int (*probe)(struct mei_cl_device *dev, const struct mei_cl_id *id);
+        int (*remove)(struct mei_cl_device *dev);
+};
+
+struct mei_cl_id {
+        char name[MEI_NAME_SIZE];
+        kernel_ulong_t driver_info;
+};
+
+The mei_cl_id structure allows the driver to bind itself against a device name.
+
+To actually register a driver on the ME Client bus one must call the mei_cl_add_driver()
+API. This is typically called at module init time.
+
+Once registered on the ME Client bus, a driver will typically try to do some I/O on
+this bus and this should be done through the mei_cl_send() and mei_cl_recv()
+routines. The latter is synchronous (blocks and sleeps until data shows up).
+In order for drivers to be notified of pending events waiting for them (e.g.
+an Rx event) they can register an event handler through the
+mei_cl_register_event_cb() routine. Currently only the MEI_EVENT_RX event
+will trigger an event handler call and the driver implementation is supposed
+to call mei_recv() from the event handler in order to fetch the pending
+received buffers.
+
+
+Example
+=======
+As a theoretical example let's pretend the ME comes with a "contact" NFC IP.
+The driver init and exit routines for this device would look like:
+
+#define CONTACT_DRIVER_NAME "contact"
+
+static struct mei_cl_device_id contact_mei_cl_tbl[] = {
+        { CONTACT_DRIVER_NAME, },
+
+        /* required last entry */
+        { }
+};
+MODULE_DEVICE_TABLE(mei_cl, contact_mei_cl_tbl);
+
+static struct mei_cl_driver contact_driver = {
+       .id_table = contact_mei_tbl,
+       .name = CONTACT_DRIVER_NAME,
+
+       .probe = contact_probe,
+       .remove = contact_remove,
+};
+
+static int contact_init(void)
+{
+        int r;
+
+        r = mei_cl_driver_register(&contact_driver);
+        if (r) {
+                pr_err(CONTACT_DRIVER_NAME ": driver registration failed\n");
+                return r;
+        }
+
+        return 0;
+}
+
+static void __exit contact_exit(void)
+{
+        mei_cl_driver_unregister(&contact_driver);
+}
+
+module_init(contact_init);
+module_exit(contact_exit);
+
+And the driver's simplified probe routine would look like that:
+
+int contact_probe(struct mei_cl_device *dev, struct mei_cl_device_id *id)
+{
+        struct contact_driver *contact;
+
+        [...]
+        mei_cl_enable_device(dev);
+
+        mei_cl_register_event_cb(dev, contact_event_cb, contact);
+
+        return 0;
+ }
+
+In the probe routine the driver first enable the MEI device and then registers
+an ME bus event handler which is as close as it can get to registering a
+threaded IRQ handler.
+The handler implementation will typically call some I/O routine depending on
+the pending events:
+
+#define MAX_NFC_PAYLOAD 128
+
+static void contact_event_cb(struct mei_cl_device *dev, u32 events,
+                             void *context)
+{
+        struct contact_driver *contact = context;
+
+        if (events & BIT(MEI_EVENT_RX)) {
+                u8 payload[MAX_NFC_PAYLOAD];
+                int payload_size;
+
+                payload_size = mei_recv(dev, payload, MAX_NFC_PAYLOAD);
+                if (payload_size <= 0)
+                        return;
+
+                /* Hook to the NFC subsystem */
+                nfc_hci_recv_frame(contact->hdev, payload, payload_size);
+        }
+}
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index a2b57e0a1db0..447fd4cd54ec 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -736,6 +736,13 @@ All the above functions are mandatory to implement for a pinmux driver.
 Pin control interaction with the GPIO subsystem
 ===============================================
 
+Note that the following implies that the use case is to use a certain pin
+from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
+and similar functions. There are cases where you may be using something
+that your datasheet calls "GPIO mode" but actually is just an electrical
+configuration for a certain device. See the section below named
+"GPIO mode pitfalls" for more details on this scenario.
+
 The public pinmux API contains two functions named pinctrl_request_gpio()
 and pinctrl_free_gpio(). These two functions shall *ONLY* be called from
 gpiolib-based drivers as part of their gpio_request() and
@@ -774,6 +781,111 @@ obtain the function "gpioN" where "N" is the global GPIO pin number if no
 special GPIO-handler is registered.
 
 
+GPIO mode pitfalls
+==================
+
+Sometime the developer may be confused by a datasheet talking about a pin
+being possible to set into "GPIO mode". It appears that what hardware
+engineers mean with "GPIO mode" is not necessarily the use case that is
+implied in the kernel interface <linux/gpio.h>: a pin that you grab from
+kernel code and then either listen for input or drive high/low to
+assert/deassert some external line.
+
+Rather hardware engineers think that "GPIO mode" means that you can
+software-control a few electrical properties of the pin that you would
+not be able to control if the pin was in some other mode, such as muxed in
+for a device.
+
+Example: a pin is usually muxed in to be used as a UART TX line. But during
+system sleep, we need to put this pin into "GPIO mode" and ground it.
+
+If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
+to think that you need to come up with something real complex, that the
+pin shall be used for UART TX and GPIO at the same time, that you will grab
+a pin control handle and set it to a certain state to enable UART TX to be
+muxed in, then twist it over to GPIO mode and use gpio_direction_output()
+to drive it low during sleep, then mux it over to UART TX again when you
+wake up and maybe even gpio_request/gpio_free as part of this cycle. This
+all gets very complicated.
+
+The solution is to not think that what the datasheet calls "GPIO mode"
+has to be handled by the <linux/gpio.h> interface. Instead view this as
+a certain pin config setting. Look in e.g. <linux/pinctrl/pinconf-generic.h>
+and you find this in the documentation:
+
+  PIN_CONFIG_OUTPUT: this will configure the pin in output, use argument
+     1 to indicate high level, argument 0 to indicate low level.
+
+So it is perfectly possible to push a pin into "GPIO mode" and drive the
+line low as part of the usual pin control map. So for example your UART
+driver may look like this:
+
+#include <linux/pinctrl/consumer.h>
+
+struct pinctrl          *pinctrl;
+struct pinctrl_state    *pins_default;
+struct pinctrl_state    *pins_sleep;
+
+pins_default = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_DEFAULT);
+pins_sleep = pinctrl_lookup_state(uap->pinctrl, PINCTRL_STATE_SLEEP);
+
+/* Normal mode */
+retval = pinctrl_select_state(pinctrl, pins_default);
+/* Sleep mode */
+retval = pinctrl_select_state(pinctrl, pins_sleep);
+
+And your machine configuration may look like this:
+--------------------------------------------------
+
+static unsigned long uart_default_mode[] = {
+    PIN_CONF_PACKED(PIN_CONFIG_DRIVE_PUSH_PULL, 0),
+};
+
+static unsigned long uart_sleep_mode[] = {
+    PIN_CONF_PACKED(PIN_CONFIG_OUTPUT, 0),
+};
+
+static struct pinctrl_map __initdata pinmap[] = {
+    PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
+                      "u0_group", "u0"),
+    PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_DEFAULT, "pinctrl-foo",
+                        "UART_TX_PIN", uart_default_mode),
+    PIN_MAP_MUX_GROUP("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
+                      "u0_group", "gpio-mode"),
+    PIN_MAP_CONFIGS_PIN("uart", PINCTRL_STATE_SLEEP, "pinctrl-foo",
+                        "UART_TX_PIN", uart_sleep_mode),
+};
+
+foo_init(void) {
+    pinctrl_register_mappings(pinmap, ARRAY_SIZE(pinmap));
+}
+
+Here the pins we want to control are in the "u0_group" and there is some
+function called "u0" that can be enabled on this group of pins, and then
+everything is UART business as usual. But there is also some function
+named "gpio-mode" that can be mapped onto the same pins to move them into
+GPIO mode.
+
+This will give the desired effect without any bogus interaction with the
+GPIO subsystem. It is just an electrical configuration used by that device
+when going to sleep, it might imply that the pin is set into something the
+datasheet calls "GPIO mode" but that is not the point: it is still used
+by that UART device to control the pins that pertain to that very UART
+driver, putting them into modes needed by the UART. GPIO in the Linux
+kernel sense are just some 1-bit line, and is a different use case.
+
+How the registers are poked to attain the push/pull and output low
+configuration and the muxing of the "u0" or "gpio-mode" group onto these
+pins is a question for the driver.
+
+Some datasheets will be more helpful and refer to the "GPIO mode" as
+"low power mode" rather than anything to do with GPIO. This often means
+the same thing electrically speaking, but in this latter case the
+software engineers will usually quickly identify that this is some
+specific muxing/configuration rather than anything related to the GPIO
+API.
+
+
 Board/machine configuration
 ==================================
 
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index ae66f9b90a25..fcaf0b4efba2 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -143,7 +143,8 @@ Parameter:     id:   handle for debug log
 
 Return Value:  none 
 
-Description:   frees memory for a debug log     
+Description:   frees memory for a debug log and removes all registered debug
+               views.
                Must not be called within an interrupt handler 
 
 ---------------------------------------------------------------------------