12 files changed, 80 insertions, 41 deletions

diff --git a/Documentation/devicetree/bindings/arm/gic-v3.txt b/Documentation/devicetree/bindings/arm/gic-v3.txt
index ddfade40ac59..7803e77d85cb 100644
--- a/Documentation/devicetree/bindings/arm/gic-v3.txt
+++ b/Documentation/devicetree/bindings/arm/gic-v3.txt
@@ -57,6 +57,8 @@ used to route Message Signalled Interrupts (MSI) to the CPUs.
 These nodes must have the following properties:
 - compatible : Should at least contain  "arm,gic-v3-its".
 - msi-controller : Boolean property. Identifies the node as an MSI controller
+- #msi-cells: Must be <1>. The single msi-cell is the DeviceID of the device
+  which will generate the MSI.
 - reg: Specifies the base physical address and size of the ITS
   registers.
 
@@ -83,6 +85,7 @@ Examples:
                 gic-its@2c200000 {
                         compatible = "arm,gic-v3-its";
                         msi-controller;
+                        #msi-cells = <1>;
                         reg = <0x0 0x2c200000 0 0x200000>;
                 };
         };
@@ -107,12 +110,14 @@ Examples:
                 gic-its@2c200000 {
                         compatible = "arm,gic-v3-its";
                         msi-controller;
+                        #msi-cells = <1>;
                         reg = <0x0 0x2c200000 0 0x200000>;
                 };
 
                 gic-its@2c400000 {
                         compatible = "arm,gic-v3-its";
                         msi-controller;
+                        #msi-cells = <1>;
                         reg = <0x0 0x2c400000 0 0x200000>;
                 };
         };
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt b/Documentation/devicetree/bindings/arm/idle-states.txt
index a8274eabae2e..b8e41c148a3c 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -497,7 +497,7 @@ cpus {
         };
 
         idle-states {
-                entry-method = "arm,psci";
+                entry-method = "psci";
 
                 CPU_RETENTION_0_0: cpu-retention-0-0 {
                         compatible = "arm,idle-state";
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 5788d5cf1252..82d40e2505f6 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -16,7 +16,9 @@ properties, each containing a 'gpio-list':
 GPIO properties should be named "[<name>-]gpios", with <name> being the purpose
 of this GPIO for the device. While a non-existent <name> is considered valid
 for compatibility reasons (resolving to the "gpios" property), it is not allowed
-for new bindings.
+for new bindings. Also, GPIO properties named "[<name>-]gpio" are valid and old
+bindings use it, but are only supported for compatibility reasons and should not
+be used for newer bindings since it has been deprecated.
 
 GPIO properties can contain one or more GPIO phandles, but only in exceptional
 cases should they contain more than one. If your device uses several GPIOs with
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt b/Documentation/devicetree/bindings/iio/accel/bma180.txt
index c5933573e0f6..4a3679d54457 100644
--- a/Documentation/devicetree/bindings/iio/accel/bma180.txt
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -1,10 +1,11 @@
-* Bosch BMA180 triaxial acceleration sensor
+* Bosch BMA180 / BMA250 triaxial acceleration sensor
 
 http://omapworld.com/BMA180_111_1002839.pdf
+http://ae-bst.resource.bosch.com/media/products/dokumente/bma250/bst-bma250-ds002-05.pdf
 
 Required properties:
 
-  - compatible : should be "bosch,bma180"
+  - compatible : should be "bosch,bma180" or "bosch,bma250"
   - reg : the I2C address of the sensor
 
 Optional properties:
@@ -13,6 +14,9 @@ Optional properties:
 
   - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
                 flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+                For the bma250 the first interrupt listed must be the one
+                connected to the INT1 pin, the second (optional) interrupt
+                listed must be the one connected to the INT2 pin.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
index 32aa26f1e434..acbcb452a69a 100644
--- a/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/pbias-regulator.txt
@@ -2,7 +2,12 @@ PBIAS internal regulator for SD card dual voltage i/o pads on OMAP SoCs.
 
 Required properties:
 - compatible:
-  - "ti,pbias-omap" for OMAP2, OMAP3, OMAP4, OMAP5, DRA7.
+  - should be "ti,pbias-dra7" for DRA7
+  - should be "ti,pbias-omap2" for OMAP2
+  - should be "ti,pbias-omap3" for OMAP3
+  - should be "ti,pbias-omap4" for OMAP4
+  - should be "ti,pbias-omap5" for OMAP5
+  - "ti,pbias-omap" is deprecated
 - reg: pbias register offset from syscon base and size of pbias register.
 - syscon : phandle of the system control module
 - regulator-name : should be
diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
index dcefc438272f..6160ffbcb3d3 100644
--- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
+++ b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt
@@ -15,17 +15,18 @@ Required properties:
 - interrupts: Should contain spi interrupt
 
 - clocks: phandles to input clocks.
-  The first should be <&topckgen CLK_TOP_SPI_SEL>.
-  The second should be one of the following.
+  The first should be one of the following. It's PLL.
    -  <&clk26m>: specify parent clock 26MHZ.
    -  <&topckgen CLK_TOP_SYSPLL3_D2>: specify parent clock 109MHZ.
                                       It's the default one.
    -  <&topckgen CLK_TOP_SYSPLL4_D2>: specify parent clock 78MHZ.
    -  <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
    -  <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
+  The second should be <&topckgen CLK_TOP_SPI_SEL>. It's clock mux.
+  The third is <&pericfg CLK_PERI_SPI0>. It's clock gate.
 
-- clock-names: shall be "spi-clk" for the controller clock, and
-  "parent-clk" for the parent clock.
+- clock-names: shall be "parent-clk" for the parent clock, "sel-clk" for the
+  muxes clock, and "spi-clk" for the clock gate.
 
 Optional properties:
 - mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi
@@ -44,8 +45,11 @@ spi: spi@1100a000 {
         #size-cells = <0>;
         reg = <0 0x1100a000 0 0x1000>;
         interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>;
-        clocks = <&topckgen CLK_TOP_SPI_SEL>, <&topckgen CLK_TOP_SYSPLL3_D2>;
-        clock-names = "spi-clk", "parent-clk";
+        clocks = <&topckgen CLK_TOP_SYSPLL3_D2>,
+                 <&topckgen CLK_TOP_SPI_SEL>,
+                 <&pericfg CLK_PERI_SPI0>;
+        clock-names = "parent-clk", "sel-clk", "spi-clk";
+
         mediatek,pad-select = <0>;
         status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
index 8a49362dea6e..41b817f7b670 100644
--- a/Documentation/devicetree/bindings/thermal/thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -55,19 +55,11 @@ of heat dissipation). For example a fan's cooling states correspond to
 the different fan speeds possible. Cooling states are referred to by
 single unsigned integers, where larger numbers mean greater heat
 dissipation. The precise set of cooling states associated with a device
-(as referred to be the cooling-min-state and cooling-max-state
+(as referred to by the cooling-min-level and cooling-max-level
 properties) should be defined in a particular device's binding.
 For more examples of cooling devices, refer to the example sections below.
 
 Required properties:
-- cooling-min-state:    An integer indicating the smallest
-  Type: unsigned        cooling state accepted. Typically 0.
-  Size: one cell
-
-- cooling-max-state:    An integer indicating the largest
-  Type: unsigned        cooling state accepted.
-  Size: one cell
-
 - #cooling-cells:       Used to provide cooling device specific information
   Type: unsigned        while referring to it. Must be at least 2, in order
   Size: one cell        to specify minimum and maximum cooling state used
@@ -77,6 +69,15 @@ Required properties:
                         See Cooling device maps section below for more details
                         on how consumers refer to cooling devices.
 
+Optional properties:
+- cooling-min-level:    An integer indicating the smallest
+  Type: unsigned        cooling state accepted. Typically 0.
+  Size: one cell
+
+- cooling-max-level:    An integer indicating the largest
+  Type: unsigned        cooling state accepted.
+  Size: one cell
+
 * Trip points
 
 The trip node is a node to describe a point in the temperature domain
@@ -225,8 +226,8 @@ cpus {
                         396000  950000
                         198000  850000
                 >;
-                cooling-min-state = <0>;
-                cooling-max-state = <3>;
+                cooling-min-level = <0>;
+                cooling-max-level = <3>;
                 #cooling-cells = <2>; /* min followed by max */
         };
         ...
@@ -240,8 +241,8 @@ cpus {
          */
         fan0: fan@0x48 {
                 ...
-                cooling-min-state = <0>;
-                cooling-max-state = <9>;
+                cooling-min-level = <0>;
+                cooling-max-level = <9>;
                 #cooling-cells = <2>; /* min followed by max */
         };
 };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac5f0c34ae00..82d2ac97af74 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -203,6 +203,7 @@ sitronix	Sitronix Technology Corporation
 skyworks        Skyworks Solutions, Inc.
 smsc    Standard Microsystems Corporation
 snps    Synopsys, Inc.
+socionext       Socionext Inc.
 solidrun        SolidRun
 solomon        Solomon Systech Limited
 sony    Sony Corporation
diff --git a/Documentation/gpio/board.txt b/Documentation/gpio/board.txt
index b80606de545a..f59c43b6411b 100644
--- a/Documentation/gpio/board.txt
+++ b/Documentation/gpio/board.txt
@@ -21,8 +21,8 @@ exact way to do it depends on the GPIO controller providing the GPIOs, see the
 device tree bindings for your controller.
 
 GPIOs mappings are defined in the consumer device's node, in a property named
-<function>-gpios, where <function> is the function the driver will request
-through gpiod_get(). For example:
+either <function>-gpios or <function>-gpio, where <function> is the function
+the driver will request through gpiod_get(). For example:
 
         foo_device {
                 compatible = "acme,foo";
@@ -31,7 +31,7 @@ through gpiod_get(). For example:
                             <&gpio 16 GPIO_ACTIVE_HIGH>, /* green */
                             <&gpio 17 GPIO_ACTIVE_HIGH>; /* blue */
 
-                power-gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+                power-gpio = <&gpio 1 GPIO_ACTIVE_LOW>;
         };
 
 This property will make GPIOs 15, 16 and 17 available to the driver under the
@@ -39,15 +39,24 @@ This property will make GPIOs 15, 16 and 17 available to the driver under the
 
         struct gpio_desc *red, *green, *blue, *power;
 
-        red = gpiod_get_index(dev, "led", 0);
-        green = gpiod_get_index(dev, "led", 1);
-        blue = gpiod_get_index(dev, "led", 2);
+        red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
+        green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
+        blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);
 
-        power = gpiod_get(dev, "power");
+        power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);
 
 The led GPIOs will be active-high, while the power GPIO will be active-low (i.e.
 gpiod_is_active_low(power) will be true).
 
+The second parameter of the gpiod_get() functions, the con_id string, has to be
+the <function>-prefix of the GPIO suffixes ("gpios" or "gpio", automatically
+looked up by the gpiod functions internally) used in the device tree. With above
+"led-gpios" example, use the prefix without the "-" as con_id parameter: "led".
+
+Internally, the GPIO subsystem prefixes the GPIO suffix ("gpios" or "gpio")
+with the string passed in con_id to get the resulting string
+(snprintf(... "%s-%s", con_id, gpio_suffixes[]).
+
 ACPI
 ----
 ACPI also supports function names for GPIOs in a similar fashion to DT.
@@ -142,13 +151,14 @@ The driver controlling "foo.0" will then be able to obtain its GPIOs as follows:
 
         struct gpio_desc *red, *green, *blue, *power;
 
-        red = gpiod_get_index(dev, "led", 0);
-        green = gpiod_get_index(dev, "led", 1);
-        blue = gpiod_get_index(dev, "led", 2);
+        red = gpiod_get_index(dev, "led", 0, GPIOD_OUT_HIGH);
+        green = gpiod_get_index(dev, "led", 1, GPIOD_OUT_HIGH);
+        blue = gpiod_get_index(dev, "led", 2, GPIOD_OUT_HIGH);
 
-        power = gpiod_get(dev, "power");
-        gpiod_direction_output(power, 1);
+        power = gpiod_get(dev, "power", GPIOD_OUT_HIGH);
 
-Since the "power" GPIO is mapped as active-low, its actual signal will be 0
-after this code. Contrary to the legacy integer GPIO interface, the active-low
-property is handled during mapping and is thus transparent to GPIO consumers.
+Since the "led" GPIOs are mapped as active-high, this example will switch their
+signals to 1, i.e. enabling the LEDs. And for the "power" GPIO, which is mapped
+as active-low, its actual signal will be 0 after this code. Contrary to the legacy
+integer GPIO interface, the active-low property is handled during mapping and is
+thus transparent to GPIO consumers.
diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt
index a206639454ab..e000502fde20 100644
--- a/Documentation/gpio/consumer.txt
+++ b/Documentation/gpio/consumer.txt
@@ -39,6 +39,9 @@ device that displays digits), an additional index argument can be specified:
                                           const char *con_id, unsigned int idx,
                                           enum gpiod_flags flags)
 
+For a more detailed description of the con_id parameter in the DeviceTree case
+see Documentation/gpio/board.txt
+
 The flags parameter is used to optionally specify a direction and initial value
 for the GPIO. Values can be:
 
diff --git a/Documentation/hwmon/nct6775 b/Documentation/hwmon/nct6775
index f0dd3d2fec96..76add4c9cd68 100644
--- a/Documentation/hwmon/nct6775
+++ b/Documentation/hwmon/nct6775
@@ -32,6 +32,10 @@ Supported chips:
     Prefix: 'nct6792'
     Addresses scanned: ISA address retrieved from Super I/O registers
     Datasheet: Available from Nuvoton upon request
+  * Nuvoton NCT6793D
+    Prefix: 'nct6793'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
 
 Authors:
         Guenter Roeck <linux@roeck-us.net>
diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
index f4cb0b2d5cd7..477927becacb 100644
--- a/Documentation/static-keys.txt
+++ b/Documentation/static-keys.txt
@@ -15,8 +15,8 @@ The updated API replacements are:
 
 DEFINE_STATIC_KEY_TRUE(key);
 DEFINE_STATIC_KEY_FALSE(key);
-static_key_likely()
-statick_key_unlikely()
+static_branch_likely()
+static_branch_unlikely()
 
 0) Abstract