105 files changed, 4795 insertions, 493 deletions
diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu
new file mode 100644
index 000000000000..33c133e2a631
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-devices-system-cpu
@@ -0,0 +1,25 @@
+What:           /sys/devices/system/cpu/dscr_default
+Date:           13-May-2014
+KernelVersion:  v3.15.0
+Contact:
+Description:    Writes are equivalent to writing to
+                /sys/devices/system/cpu/cpuN/dscr on all CPUs.
+                Reads return the last written value or 0.
+                This value is not a global default: it is a way to set
+                all per-CPU defaults at the same time.
+Values:         64 bit unsigned integer (bit field)
+What:           /sys/devices/system/cpu/cpu[0-9]+/dscr
+Date:           13-May-2014
+KernelVersion:  v3.15.0
+Contact:
+Description:    Default value for the Data Stream Control Register (DSCR) on
+                a CPU.
+                This default value is used when the kernel is executing and
+                for any process that has not set the DSCR itself.
+                If a process ever sets the DSCR (via direct access to the
+                SPR) that value will be persisted for that process and used
+                on any CPU where it executes (overriding the value described
+                here).
+                If set by a process it will be inherited by child processes.
+Values:         64 bit unsigned integer (bit field)
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index f1c5cc9d17a8..4c3efe434806 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -23,7 +23,7 @@ Description:
                                 [fowner]]
                        lsm:    [[subj_user=] [subj_role=] [subj_type=]
                                 [obj_user=] [obj_role=] [obj_type=]]
-                        option: [[appraise_type=]]
+                        option: [[appraise_type=]] [permit_directio]
                base:   func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
                        mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net
index d922060e455d..416c5d59f52e 100644
--- a/Documentation/ABI/testing/sysfs-class-net
+++ b/Documentation/ABI/testing/sysfs-class-net
@@ -169,6 +169,14 @@ Description:
                "unknown", "notpresent", "down", "lowerlayerdown", "testing",
                "dormant", "up".
+What:           /sys/class/net/<iface>/phys_port_id
+Date:           July 2013
+KernelVersion:  3.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface unique physical port identifier within
+                the NIC, as a string.
 What:           /sys/class/net/<iface>/speed
 Date:           October 2009
 KernelVersion:  2.6.33
diff --git a/Documentation/ABI/testing/sysfs-class-net-cdc_ncm b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
new file mode 100644
index 000000000000..5cedf72df358
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-cdc_ncm
@@ -0,0 +1,149 @@
+What:           /sys/class/net/<iface>/cdc_ncm/min_tx_pkt
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                The driver will pad NCM Transfer Blocks (NTBs) longer
+                than this to tx_max, allowing the device to receive
+                tx_max sized frames with no terminating short
+                packet. NTBs shorter than this limit are transmitted
+                as-is, without any padding, and are terminated with a
+                short USB packet.
+                Padding to tx_max allows the driver to transmit NTBs
+                back-to-back without any interleaving short USB
+                packets.  This reduces the number of short packet
+                interrupts in the device, and represents a tradeoff
+                between USB bus bandwidth and device DMA optimization.
+                Set to 0 to pad all frames. Set greater than tx_max to
+                disable all padding.
+What:           /sys/class/net/<iface>/cdc_ncm/rx_max
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                The maximum NTB size for RX.  Cannot exceed the
+                maximum value supported by the device. Must allow at
+                least one max sized datagram plus headers.
+                The actual limits are device dependent.  See
+                dwNtbInMaxSize.
+                Note: Some devices will silently ignore changes to
+                this value, resulting in oversized NTBs and
+                corresponding framing errors.
+What:           /sys/class/net/<iface>/cdc_ncm/tx_max
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                The maximum NTB size for TX.  Cannot exceed the
+                maximum value supported by the device.  Must allow at
+                least one max sized datagram plus headers.
+                The actual limits are device dependent.  See
+                dwNtbOutMaxSize.
+What:           /sys/class/net/<iface>/cdc_ncm/tx_timer_usecs
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                Datagram aggregation timeout in µs. The driver will
+                wait up to 3 times this timeout for more datagrams to
+                aggregate before transmitting an NTB frame.
+                Valid range: 5 to 4000000
+                Set to 0 to disable aggregation.
+The following read-only attributes all represent fields of the
+structure defined in section 6.2.1 "GetNtbParameters" of "Universal
+Serial Bus Communications Class Subclass Specifications for Network
+Control Model Devices" (CDC NCM), Revision 1.0 (Errata 1), November
+24, 2010 from USB Implementers Forum, Inc.  The descriptions are
+quoted from table 6-3 of CDC NCM: "NTB Parameter Structure".
+What:           /sys/class/net/<iface>/cdc_ncm/bmNtbFormatsSupported
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                Bit 0: 16-bit NTB supported (set to 1)
+                Bit 1: 32-bit NTB supported
+                Bits 2 – 15: reserved (reset to zero; must be ignored by host)
+What:           /sys/class/net/<iface>/cdc_ncm/dwNtbInMaxSize
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                IN NTB Maximum Size in bytes
+What:           /sys/class/net/<iface>/cdc_ncm/wNdpInDivisor
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                Divisor used for IN NTB Datagram payload alignment
+What:           /sys/class/net/<iface>/cdc_ncm/wNdpInPayloadRemainder
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                Remainder used to align input datagram payload within
+                the NTB: (Payload Offset) mod (wNdpInDivisor) =
+                wNdpInPayloadRemainder
+What:           /sys/class/net/<iface>/cdc_ncm/wNdpInAlignment
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                NDP alignment modulus for NTBs on the IN pipe. Shall
+                be a power of 2, and shall be at least 4.
+What:           /sys/class/net/<iface>/cdc_ncm/dwNtbOutMaxSize
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                OUT NTB Maximum Size
+What:           /sys/class/net/<iface>/cdc_ncm/wNdpOutDivisor
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                OUT NTB Datagram alignment modulus
+What:           /sys/class/net/<iface>/cdc_ncm/wNdpOutPayloadRemainder
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                Remainder used to align output datagram payload
+                offsets within the NTB: Padding, shall be transmitted
+                as zero by function, and ignored by host.  (Payload
+                Offset) mod (wNdpOutDivisor) = wNdpOutPayloadRemainder
+What:           /sys/class/net/<iface>/cdc_ncm/wNdpOutAlignment
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                NDP alignment modulus for use in NTBs on the OUT
+                pipe. Shall be a power of 2, and shall be at least 4.
+What:           /sys/class/net/<iface>/cdc_ncm/wNtbOutMaxDatagrams
+Date:           May 2014
+KernelVersion:  3.16
+Contact:        Bjørn Mork <bjorn@mork.no>
+Description:
+                Maximum number of datagrams that the host may pack
+                into a single OUT NTB. Zero means that the device
+                imposes no limit.
diff --git a/Documentation/ABI/testing/sysfs-class-net-queues b/Documentation/ABI/testing/sysfs-class-net-queues
new file mode 100644
index 000000000000..5e9aeb91d355
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-queues
@@ -0,0 +1,79 @@
+What:           /sys/class/<iface>/queues/rx-<queue>/rps_cpus
+Date:           March 2010
+KernelVersion:  2.6.35
+Contact:        netdev@vger.kernel.org
+Description:
+                Mask of the CPU(s) currently enabled to participate into the
+                Receive Packet Steering packet processing flow for this
+                network device queue. Possible values depend on the number
+                of available CPU(s) in the system.
+What:           /sys/class/<iface>/queues/rx-<queue>/rps_flow_cnt
+Date:           April 2010
+KernelVersion:  2.6.35
+Contact:        netdev@vger.kernel.org
+Description:
+                Number of Receive Packet Steering flows being currently
+                processed by this particular network device receive queue.
+What:           /sys/class/<iface>/queues/tx-<queue>/tx_timeout
+Date:           November 2011
+KernelVersion:  3.3
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of transmit timeout events seen by this
+                network interface transmit queue.
+What:           /sys/class/<iface>/queues/tx-<queue>/xps_cpus
+Date:           November 2010
+KernelVersion:  2.6.38
+Contact:        netdev@vger.kernel.org
+Description:
+                Mask of the CPU(s) currently enabled to participate into the
+                Transmit Packet Steering packet processing flow for this
+                network device transmit queue. Possible vaules depend on the
+                number of available CPU(s) in the system.
+What:           /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
+Date:           November 2011
+KernelVersion:  3.3
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the hold time in milliseconds to measure the slack
+                of this particular network device transmit queue.
+                Default value is 1000.
+What:           /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/inflight
+Date:           November 2011
+KernelVersion:  3.3
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of bytes (objects) in flight on this
+                network device transmit queue.
+What:           /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit
+Date:           November 2011
+KernelVersion:  3.3
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the current limit of bytes allowed to be queued
+                on this network device transmit queue. This value is clamped
+                to be within the bounds defined by limit_max and limit_min.
+What:           /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_max
+Date:           November 2011
+KernelVersion:  3.3
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the absolute maximum limit of bytes allowed to be
+                queued on this network device transmit queue. See
+                include/linux/dynamic_queue_limits.h for the default value.
+What:           /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/limit_min
+Date:           November 2011
+KernelVersion:  3.3
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the absolute minimum limit of bytes allowed to be
+                queued on this network device transmit queue. Default value is
+                0.
diff --git a/Documentation/ABI/testing/sysfs-class-net-statistics b/Documentation/ABI/testing/sysfs-class-net-statistics
new file mode 100644
index 000000000000..397118de7b5e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net-statistics
@@ -0,0 +1,201 @@
+What:           /sys/class/<iface>/statistics/collisions
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of collisions seen by this network device.
+                This value might not be relevant with all MAC layers.
+What:           /sys/class/<iface>/statistics/multicast
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of multicast packets received by this
+                network device.
+What:           /sys/class/<iface>/statistics/rx_bytes
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of bytes received by this network device.
+                See the network driver for the exact meaning of when this
+                value is incremented.
+What:           /sys/class/<iface>/statistics/rx_compressed
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of compressed packets received by this
+                network device. This value might only be relevant for interfaces
+                that support packet compression (e.g: PPP).
+What:           /sys/class/<iface>/statistics/rx_crc_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets received with a CRC (FCS) error
+                by this network device. Note that the specific meaning might
+                depend on the MAC layer used by the interface.
+What:           /sys/class/<iface>/statistics/rx_dropped
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets received by the network device
+                but dropped, that are not forwarded to the upper layers for
+                packet processing. See the network driver for the exact
+                meaning of this value.
+What:           /sys/class/<iface>/statistics/rx_fifo_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of receive FIFO errors seen by this
+                network device. See the network driver for the exact
+                meaning of this value.
+What:           /sys/class/<iface>/statistics/rx_frame_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of received frames with error, such as
+                alignment errors. Note that the specific meaning depends on
+                on the MAC layer protocol used. See the network driver for
+                the exact meaning of this value.
+What:           /sys/class/<iface>/statistics/rx_length_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of received error packet with a length
+                error, oversized or undersized. See the network driver for the
+                exact meaning of this value.
+What:           /sys/class/<iface>/statistics/rx_missed_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of received packets that have been missed
+                due to lack of capacity in the receive side. See the network
+                driver for the exact meaning of this value.
+What:           /sys/class/<iface>/statistics/rx_over_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of received packets that are oversized
+                compared to what the network device is configured to accept
+                (e.g: larger than MTU). See the network driver for the exact
+                meaning of this value.
+What:           /sys/class/<iface>/statistics/rx_packets
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the total number of good packets received by this
+                network device.
+What:           /sys/class/<iface>/statistics/tx_aborted_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets that have been aborted
+                during transmission by a network device (e.g: because of
+                a medium collision). See the network driver for the exact
+                meaning of this value.
+What:           /sys/class/<iface>/statistics/tx_bytes
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of bytes transmitted by a network
+                device. See the network driver for the exact meaning of this
+                value, in particular whether this accounts for all successfully
+                transmitted packets or all packets that have been queued for
+                transmission.
+What:           /sys/class/<iface>/statistics/tx_carrier_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets that could not be transmitted
+                because of carrier errors (e.g: physical link down). See the
+                network driver for the exact meaning of this value.
+What:           /sys/class/<iface>/statistics/tx_compressed
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of transmitted compressed packets. Note
+                this might only be relevant for devices that support
+                compression (e.g: PPP).
+What:           /sys/class/<iface>/statistics/tx_dropped
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets dropped during transmission.
+                See the driver for the exact reasons as to why the packets were
+                dropped.
+What:           /sys/class/<iface>/statistics/tx_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets in error during transmission by
+                a network device. See the driver for the exact reasons as to
+                why the packets were dropped.
+What:           /sys/class/<iface>/statistics/tx_fifo_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets having caused a transmit
+                FIFO error. See the driver for the exact reasons as to why the
+                packets were dropped.
+What:           /sys/class/<iface>/statistics/tx_heartbeat_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets transmitted that have been
+                reported as heartbeat errors. See the driver for the exact
+                reasons as to why the packets were dropped.
+What:           /sys/class/<iface>/statistics/tx_packets
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets transmitted by a network
+                device. See the driver for whether this reports the number of all
+                attempted or successful transmissions.
+What:           /sys/class/<iface>/statistics/tx_window_errors
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the number of packets not successfully transmitted
+                due to a window collision. The specific meaning depends on the
+                MAC layer used.  On Ethernet this is usually used to report
+                late collisions errors.
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index 044b76436e83..d9b9416c989f 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -100,6 +100,7 @@
 !Finclude/net/cfg80211.h wdev_priv
 !Finclude/net/cfg80211.h ieee80211_iface_limit
 !Finclude/net/cfg80211.h ieee80211_iface_combination
+!Finclude/net/cfg80211.h cfg80211_check_combinations
      </chapter>
      <chapter>
      <title>Actions and configuration</title>
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index ba60d93c1855..7df3134ebc0e 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -142,6 +142,12 @@
      to register it with the DRM subsystem.
    </para>
    <para>
+      Newer drivers that no longer require a <structname>drm_bus</structname>
+      structure can alternatively use the low-level device initialization and
+      registration functions such as <function>drm_dev_alloc()</function> and
+      <function>drm_dev_register()</function> directly.
+    </para>
+    <para>
      The <structname>drm_driver</structname> structure contains static
      information that describes the driver and features it supports, and
      pointers to methods that the DRM core will call to implement the DRM API.
@@ -282,6 +288,36 @@ char *date;</synopsis>
      </sect3>
    </sect2>
    <sect2>
+      <title>Device Registration</title>
+      <para>
+        A number of functions are provided to help with device registration.
+        The functions deal with PCI, USB and platform devices, respectively.
+      </para>
+!Edrivers/gpu/drm/drm_pci.c
+!Edrivers/gpu/drm/drm_usb.c
+!Edrivers/gpu/drm/drm_platform.c
+      <para>
+        New drivers that no longer rely on the services provided by the
+        <structname>drm_bus</structname> structure can call the low-level
+        device registration functions directly. The
+        <function>drm_dev_alloc()</function> function can be used to allocate
+        and initialize a new <structname>drm_device</structname> structure.
+        Drivers will typically want to perform some additional setup on this
+        structure, such as allocating driver-specific data and storing a
+        pointer to it in the DRM device's <structfield>dev_private</structfield>
+        field. Drivers should also set the device's unique name using the
+        <function>drm_dev_set_unique()</function> function. After it has been
+        set up a device can be registered with the DRM subsystem by calling
+        <function>drm_dev_register()</function>. This will cause the device to
+        be exposed to userspace and will call the driver's
+        <structfield>.load()</structfield> implementation. When a device is
+        removed, the DRM device can safely be unregistered and freed by calling
+        <function>drm_dev_unregister()</function> followed by a call to
+        <function>drm_dev_unref()</function>.
+      </para>
+!Edrivers/gpu/drm/drm_stub.c
+    </sect2>
+    <sect2>
      <title>Driver Load</title>
      <para>
        The <methodname>load</methodname> method is the driver and device
@@ -342,21 +378,13 @@ char *date;</synopsis>
        <sect4>
          <title>Managed IRQ Registration</title>
          <para>
-            Both the <function>drm_irq_install</function> and
-            <function>drm_irq_uninstall</function> functions get the device IRQ by
-            calling <function>drm_dev_to_irq</function>. This inline function will
-            call a bus-specific operation to retrieve the IRQ number. For platform
-            devices, <function>platform_get_irq</function>(..., 0) is used to
-            retrieve the IRQ number.
-          </para>
-          <para>
            <function>drm_irq_install</function> starts by calling the
            <methodname>irq_preinstall</methodname> driver operation. The operation
            is optional and must make sure that the interrupt will not get fired by
            clearing all pending interrupt flags or disabling the interrupt.
          </para>
          <para>
-            The IRQ will then be requested by a call to
+            The passed-in IRQ will then be requested by a call to
            <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
            feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
            requested.
@@ -1799,6 +1827,12 @@ void intel_crt_init(struct drm_device *dev)
      <title>KMS API Functions</title>
 !Edrivers/gpu/drm/drm_crtc.c
    </sect2>
+    <sect2>
+      <title>KMS Locking</title>
+!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking
+!Iinclude/drm/drm_modeset_lock.h
+!Edrivers/gpu/drm/drm_modeset_lock.c
+    </sect2>
  </sect1>
  <!-- Internals: kms helper functions -->
@@ -1903,8 +1937,8 @@ void intel_crt_init(struct drm_device *dev)
          <para>
            The function filters out modes larger than
            <parameter>max_width</parameter> and <parameter>max_height</parameter>
-            if specified. It then calls the connector
+            if specified. It then calls the optional connector
-            <methodname>mode_valid</methodname> helper operation for  each mode in
+            <methodname>mode_valid</methodname> helper operation for each mode in
            the probed list to check whether the mode is valid for the connector.
          </para>
        </listitem>
@@ -2265,7 +2299,7 @@ void intel_crt_init(struct drm_device *dev)
          <para>
            Verify whether a mode is valid for the connector. Return MODE_OK for
            supported modes and one of the enum drm_mode_status values (MODE_*)
-            for unsupported modes. This operation is mandatory.
+            for unsupported modes. This operation is optional.
          </para>
          <para>
            As the mode rejection reason is currently not used beside for
@@ -2450,6 +2484,863 @@ void intel_crt_init(struct drm_device *dev)
      pointer to the target object, a pointer to the previously created property
      and an initial instance value.
    </para>
+    <sect2>
+        <title>Existing KMS Properties</title>
+        <para>
+        The following table gives description of drm properties exposed by various
+        modules/drivers.
+        </para>
+        <table border="1" cellpadding="0" cellspacing="0">
+        <tbody>
+        <tr style="font-weight: bold;">
+        <td valign="top" >Owner Module/Drivers</td>
+        <td valign="top" >Group</td>
+        <td valign="top" >Property Name</td>
+        <td valign="top" >Type</td>
+        <td valign="top" >Property Values</td>
+        <td valign="top" >Object attached</td>
+        <td valign="top" >Description/Restrictions</td>
+        </tr>
+        <tr>
+        <td rowspan="20" valign="top" >DRM</td>
+        <td rowspan="2" valign="top" >Generic</td>
+        <td valign="top" >“EDID”</td>
+        <td valign="top" >BLOB | IMMUTABLE</td>
+        <td valign="top" >0</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >Contains id of edid blob ptr object.</td>
+        </tr>
+        <tr>
+        <td valign="top" >“DPMS”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ “On”, “Standby”, “Suspend”, “Off” }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >Contains DPMS operation mode value.</td>
+        </tr>
+        <tr>
+        <td rowspan="1" valign="top" >Plane</td>
+        <td valign="top" >“type”</td>
+        <td valign="top" >ENUM | IMMUTABLE</td>
+        <td valign="top" >{ "Overlay", "Primary", "Cursor" }</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >Plane type</td>
+        </tr>
+        <tr>
+        <td rowspan="2" valign="top" >DVI-I</td>
+        <td valign="top" >“subconnector”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ “Unknown”, “DVI-D”, “DVI-A” }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“select subconnector”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ “Automatic”, “DVI-D”, “DVI-A” }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="13" valign="top" >TV</td>
+        <td valign="top" >“subconnector”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "Unknown", "Composite", "SVIDEO", "Component", "SCART" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“select subconnector”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "Automatic", "Composite", "SVIDEO", "Component", "SCART" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“left margin”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“right margin”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“top margin”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“bottom margin”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“brightness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“contrast”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker reduction”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“overscan”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“saturation”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“hue”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="2" valign="top" >Optional</td>
+        <td valign="top" >“scaling mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“dirty”</td>
+        <td valign="top" >ENUM | IMMUTABLE</td>
+        <td valign="top" >{ "Off", "On", "Annotate" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="21" valign="top" >i915</td>
+        <td rowspan="3" valign="top" >Generic</td>
+        <td valign="top" >"Broadcast RGB"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“audio”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "force-dvi", "off", "auto", "on" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Standard name as in DRM</td>
+        <td valign="top" >Standard type as in DRM</td>
+        <td valign="top" >Standard value as in DRM</td>
+        <td valign="top" >Standard Object as in DRM</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="17" valign="top" >SDVO-TV</td>
+        <td valign="top" >“mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"left_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"right_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"top_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"bottom_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“hpos”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“vpos”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“contrast”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“saturation”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“hue”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“sharpness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker_filter”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker_filter_adaptive”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker_filter_2d”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“tv_chroma_filter”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“tv_luma_filter”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“dot_crawl”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >SDVO-TV/LVDS</td>
+        <td valign="top" >“brightness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="3" valign="top" >CDV gma-500</td>
+        <td rowspan="3" valign="top" >Generic</td>
+        <td valign="top" >"Broadcast RGB"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ “Full”, “Limited 16:235” }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"Broadcast RGB"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ “off”, “auto”, “on” }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Standard name as in DRM</td>
+        <td valign="top" >Standard type as in DRM</td>
+        <td valign="top" >Standard value as in DRM</td>
+        <td valign="top" >Standard Object as in DRM</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="20" valign="top" >Poulsbo</td>
+        <td rowspan="2" valign="top" >Generic</td>
+        <td valign="top" >“backlight”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=100</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Standard name as in DRM</td>
+        <td valign="top" >Standard type as in DRM</td>
+        <td valign="top" >Standard value as in DRM</td>
+        <td valign="top" >Standard Object as in DRM</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="17" valign="top" >SDVO-TV</td>
+        <td valign="top" >“mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "NTSC_M", "NTSC_J", "NTSC_443", "PAL_B" } etc.</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"left_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"right_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"top_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"bottom_margin"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“hpos”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“vpos”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“contrast”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“saturation”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“hue”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“sharpness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker_filter”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker_filter_adaptive”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“flicker_filter_2d”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“tv_chroma_filter”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“tv_luma_filter”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“dot_crawl”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >SDVO-TV/LVDS</td>
+        <td valign="top" >“brightness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max= SDVO dependent</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="11" valign="top" >armada</td>
+        <td rowspan="2" valign="top" >CRTC</td>
+        <td valign="top" >"CSC_YUV"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "Auto" , "CCIR601", "CCIR709" }</td>
+        <td valign="top" >CRTC</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"CSC_RGB"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "Auto", "Computer system", "Studio" }</td>
+        <td valign="top" >CRTC</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="9" valign="top" >Overlay</td>
+        <td valign="top" >"colorkey"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0xffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"colorkey_min"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0xffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"colorkey_max"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0xffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"colorkey_val"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0xffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"colorkey_alpha"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0xffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"colorkey_mode"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "disabled", "Y component", "U component"
+        , "V component", "RGB", “R component", "G component", "B component" }</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"brightness"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=256 + 255</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"contrast"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0x7fff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"saturation"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0x7fff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="2" valign="top" >exynos</td>
+        <td valign="top" >CRTC</td>
+        <td valign="top" >“mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "normal", "blank" }</td>
+        <td valign="top" >CRTC</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Overlay</td>
+        <td valign="top" >“zpos”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=MAX_PLANE-1</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="3" valign="top" >i2c/ch7006_drv</td>
+        <td valign="top" >Generic</td>
+        <td valign="top" >“scale”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=2</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="2" valign="top" >TV</td>
+        <td valign="top" >Standard names as in DRM</td>
+        <td valign="top" >Standard types as in DRM</td>
+        <td valign="top" >Standard Values as in DRM</td>
+        <td valign="top" >Standard object as in DRM</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
+        , "PAL-60", "NTSC-M", "NTSC-J" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="16" valign="top" >nouveau</td>
+        <td rowspan="6" valign="top" >NV10 Overlay</td>
+        <td valign="top" >"colorkey"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0x01ffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“contrast”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=8192-1</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“brightness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1024</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“hue”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=359</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“saturation”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=8192-1</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“iturbt_709”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="2" valign="top" >Nv04 Overlay</td>
+        <td valign="top" >“colorkey”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0x01ffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“brightness”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1024</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="7" valign="top" >Display</td>
+        <td valign="top" >“dithering mode”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "auto", "off", "on" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“dithering depth”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "auto", "off", "on", "static 2x2", "dynamic 2x2", "temporal" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“underscan”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "auto", "6 bpc", "8 bpc" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“underscan hborder”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=128</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“underscan vborder”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=128</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“vibrant hue”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=180</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“color vibrance”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=200</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Generic</td>
+        <td valign="top" >Standard name as in DRM</td>
+        <td valign="top" >Standard type as in DRM</td>
+        <td valign="top" >Standard value as in DRM</td>
+        <td valign="top" >Standard Object as in DRM</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="2" valign="top" >omap</td>
+        <td rowspan="2" valign="top" >Generic</td>
+        <td valign="top" >“rotation”</td>
+        <td valign="top" >BITMASK</td>
+        <td valign="top" >{ 0, "rotate-0" },
+        { 1, "rotate-90" },
+        { 2, "rotate-180" },
+        { 3, "rotate-270" },
+        { 4, "reflect-x" },
+        { 5, "reflect-y" }</td>
+        <td valign="top" >CRTC, Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >“zorder”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=3</td>
+        <td valign="top" >CRTC, Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >qxl</td>
+        <td valign="top" >Generic</td>
+        <td valign="top" >“hotplug_mode_update"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="10" valign="top" >radeon</td>
+        <td valign="top" >DVI-I</td>
+        <td valign="top" >“coherent”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >DAC enable load detect</td>
+        <td valign="top" >“load detection”</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=1</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >TV Standard</td>
+        <td valign="top" >"tv standard"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "ntsc", "pal", "pal-m", "pal-60", "ntsc-j"
+        , "scart-pal", "pal-cn", "secam" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >legacy TMDS PLL detect</td>
+        <td valign="top" >"tmds_pll"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "driver", "bios" }</td>
+        <td valign="top" >-</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="3" valign="top" >Underscan</td>
+        <td valign="top" >"underscan"</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "off", "on", "auto" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"underscan hborder"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=128</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"underscan vborder"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=128</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Audio</td>
+        <td valign="top" >“audio”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "off", "on", "auto" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >FMT Dithering</td>
+        <td valign="top" >“dither”</td>
+        <td valign="top" >ENUM</td>
+        <td valign="top" >{ "off", "on" }</td>
+        <td valign="top" >Connector</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >Generic</td>
+        <td valign="top" >Standard name as in DRM</td>
+        <td valign="top" >Standard type as in DRM</td>
+        <td valign="top" >Standard value as in DRM</td>
+        <td valign="top" >Standard Object as in DRM</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td rowspan="3" valign="top" >rcar-du</td>
+        <td rowspan="3" valign="top" >Generic</td>
+        <td valign="top" >"alpha"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=255</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"colorkey"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=0, Max=0x01ffffff</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        <tr>
+        <td valign="top" >"zpos"</td>
+        <td valign="top" >RANGE</td>
+        <td valign="top" >Min=1, Max=7</td>
+        <td valign="top" >Plane</td>
+        <td valign="top" >TBD</td>
+        </tr>
+        </tbody>
+        </table>
+    </sect2>
  </sect1>
  <!-- Internals: vertical blanking -->
@@ -2527,6 +3418,10 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
      with a call to <function>drm_vblank_cleanup</function> in the driver
      <methodname>unload</methodname> operation handler.
    </para>
+    <sect2>
+      <title>Vertical Blanking and Interrupt Handling Functions Reference</title>
+!Edrivers/gpu/drm/drm_irq.c
+    </sect2>
  </sect1>
  <!-- Internals: open/close, file operations and ioctls -->
@@ -2869,17 +3764,16 @@ int num_ioctls;</synopsis>
            <term>DRM_IOCTL_MODESET_CTL</term>
            <listitem>
              <para>
-                This should be called by application level drivers before and
+                This was only used for user-mode-settind drivers around
-                after mode setting, since on many devices the vertical blank
+                modesetting changes to allow the kernel to update the vblank
-                counter is reset at that time.  Internally, the DRM snapshots
+                interrupt after mode setting, since on many devices the vertical
-                the last vblank count when the ioctl is called with the
+                blank counter is reset to 0 at some point during modeset. Modern
-                _DRM_PRE_MODESET command, so that the counter won't go backwards
+                drivers should not call this any more since with kernel mode
-                (which is dealt with when _DRM_POST_MODESET is used).
+                setting it is a no-op.
              </para>
            </listitem>
          </varlistentry>
        </variablelist>
-<!--!Edrivers/char/drm/drm_irq.c-->
      </para>
    </sect1>
@@ -2942,6 +3836,96 @@ int num_ioctls;</synopsis>
          probing, so those sections fully apply.
        </para>
      </sect2>
+      <sect2>
+        <title>DPIO</title>
+!Pdrivers/gpu/drm/i915/i915_reg.h DPIO
+        <table id="dpiox2">
+          <title>Dual channel PHY (VLV/CHV)</title>
+          <tgroup cols="8">
+            <colspec colname="c0" />
+            <colspec colname="c1" />
+            <colspec colname="c2" />
+            <colspec colname="c3" />
+            <colspec colname="c4" />
+            <colspec colname="c5" />
+            <colspec colname="c6" />
+            <colspec colname="c7" />
+            <spanspec spanname="ch0" namest="c0" nameend="c3" />
+            <spanspec spanname="ch1" namest="c4" nameend="c7" />
+            <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" />
+            <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" />
+            <spanspec spanname="ch1pcs01" namest="c4" nameend="c5" />
+            <spanspec spanname="ch1pcs23" namest="c6" nameend="c7" />
+            <thead>
+              <row>
+                <entry spanname="ch0">CH0</entry>
+                <entry spanname="ch1">CH1</entry>
+              </row>
+            </thead>
+            <tbody valign="top" align="center">
+              <row>
+                <entry spanname="ch0">CMN/PLL/REF</entry>
+                <entry spanname="ch1">CMN/PLL/REF</entry>
+              </row>
+              <row>
+                <entry spanname="ch0pcs01">PCS01</entry>
+                <entry spanname="ch0pcs23">PCS23</entry>
+                <entry spanname="ch1pcs01">PCS01</entry>
+                <entry spanname="ch1pcs23">PCS23</entry>
+              </row>
+              <row>
+                <entry>TX0</entry>
+                <entry>TX1</entry>
+                <entry>TX2</entry>
+                <entry>TX3</entry>
+                <entry>TX0</entry>
+                <entry>TX1</entry>
+                <entry>TX2</entry>
+                <entry>TX3</entry>
+              </row>
+              <row>
+                <entry spanname="ch0">DDI0</entry>
+                <entry spanname="ch1">DDI1</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+        <table id="dpiox1">
+          <title>Single channel PHY (CHV)</title>
+          <tgroup cols="4">
+            <colspec colname="c0" />
+            <colspec colname="c1" />
+            <colspec colname="c2" />
+            <colspec colname="c3" />
+            <spanspec spanname="ch0" namest="c0" nameend="c3" />
+            <spanspec spanname="ch0pcs01" namest="c0" nameend="c1" />
+            <spanspec spanname="ch0pcs23" namest="c2" nameend="c3" />
+            <thead>
+              <row>
+                <entry spanname="ch0">CH0</entry>
+              </row>
+            </thead>
+            <tbody valign="top" align="center">
+              <row>
+                <entry spanname="ch0">CMN/PLL/REF</entry>
+              </row>
+              <row>
+                <entry spanname="ch0pcs01">PCS01</entry>
+                <entry spanname="ch0pcs23">PCS23</entry>
+              </row>
+              <row>
+                <entry>TX0</entry>
+                <entry>TX1</entry>
+                <entry>TX2</entry>
+                <entry>TX3</entry>
+              </row>
+              <row>
+                <entry spanname="ch0">DDI2</entry>
+              </row>
+            </tbody>
+          </tgroup>
+        </table>
+      </sect2>
    </sect1>
    <sect1>
@@ -2950,6 +3934,11 @@ int num_ioctls;</synopsis>
        This sections covers all things related to the GEM implementation in the
        i915 driver.
      </para>
+      <sect2>
+        <title>Batchbuffer Parsing</title>
+!Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
+!Idrivers/gpu/drm/i915/i915_cmd_parser.c
+      </sect2>
    </sect1>
  </chapter>
 </part>
diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S
index 4b486fe31b32..6f3e4b75e49e 100644
--- a/Documentation/EDID/1024x768.S
+++ b/Documentation/EDID/1024x768.S
@@ -36,7 +36,7 @@
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux XGA"
-#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
+#define ESTABLISHED_TIMING2_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */
 #define HSYNC_POL 0
 #define VSYNC_POL 0
 #define CRC 0x55
diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S
index a2799fe33a4d..bd9bef2a65af 100644
--- a/Documentation/EDID/1280x1024.S
+++ b/Documentation/EDID/1280x1024.S
@@ -36,7 +36,7 @@
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux SXGA"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0xa0
diff --git a/Documentation/EDID/1600x1200.S b/Documentation/EDID/1600x1200.S
index 0ded64cfd1f5..a45101c6160c 100644
--- a/Documentation/EDID/1600x1200.S
+++ b/Documentation/EDID/1600x1200.S
@@ -36,7 +36,7 @@
 #define DPI 72
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux UXGA"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x9d
diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S
index 96f67cafcf2e..b0d7c69282b4 100644
--- a/Documentation/EDID/1680x1050.S
+++ b/Documentation/EDID/1680x1050.S
@@ -36,7 +36,7 @@
 #define DPI 96
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux WSXGA"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x26
diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S
index 36ed5d571d0a..3084355e81e7 100644
--- a/Documentation/EDID/1920x1080.S
+++ b/Documentation/EDID/1920x1080.S
@@ -36,7 +36,7 @@
 #define DPI 96
 #define VFREQ 60 /* Hz */
 #define TIMING_NAME "Linux FHD"
-#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */
+/* No ESTABLISHED_TIMINGx_BITS */
 #define HSYNC_POL 1
 #define VSYNC_POL 1
 #define CRC 0x05
diff --git a/Documentation/EDID/800x600.S b/Documentation/EDID/800x600.S
new file mode 100644
index 000000000000..6644e26d5801
--- /dev/null
+++ b/Documentation/EDID/800x600.S
@@ -0,0 +1,41 @@
+/*
+   800x600.S: EDID data set for standard 800x600 60 Hz monitor
+   Copyright (C) 2011 Carsten Emde <C.Emde@osadl.org>
+   Copyright (C) 2014 Linaro Limited
+   This program is free software; you can redistribute it and/or
+   modify it under the terms of the GNU General Public License
+   as published by the Free Software Foundation; either version 2
+   of the License, or (at your option) any later version.
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+*/
+/* EDID */
+#define VERSION 1
+#define REVISION 3
+/* Display */
+#define CLOCK 40000 /* kHz */
+#define XPIX 800
+#define YPIX 600
+#define XY_RATIO XY_RATIO_4_3
+#define XBLANK 256
+#define YBLANK 28
+#define XOFFSET 40
+#define XPULSE 128
+#define YOFFSET (63+1)
+#define YPULSE (63+4)
+#define DPI 72
+#define VFREQ 60 /* Hz */
+#define TIMING_NAME "Linux SVGA"
+#define ESTABLISHED_TIMING1_BITS 0x01 /* Bit 0: 800x600 @ 60Hz */
+#define HSYNC_POL 1
+#define VSYNC_POL 1
+#define CRC 0xc2
+#include "edid.S"
diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt
index 7146db1d9e8c..835db332289b 100644
--- a/Documentation/EDID/HOWTO.txt
+++ b/Documentation/EDID/HOWTO.txt
@@ -18,7 +18,7 @@ CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an
 individually prepared or corrected EDID data set in the /lib/firmware
 directory from where it is loaded via the firmware interface. The code
 (see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for
-commonly used screen resolutions (1024x768, 1280x1024, 1600x1200,
+commonly used screen resolutions (800x600, 1024x768, 1280x1024, 1600x1200,
 1680x1050, 1920x1080) as binary blobs, but the kernel source tree does
 not contain code to create these data. In order to elucidate the origin
 of the built-in binary EDID blobs and to facilitate the creation of
diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S
index ea97ae275fca..7ac03276d7a2 100644
--- a/Documentation/EDID/edid.S
+++ b/Documentation/EDID/edid.S
@@ -33,6 +33,17 @@
 #define XY_RATIO_5_4    0b10
 #define XY_RATIO_16_9   0b11
+/* Provide defaults for the timing bits */
+#ifndef ESTABLISHED_TIMING1_BITS
+#define ESTABLISHED_TIMING1_BITS 0x00
+#endif
+#ifndef ESTABLISHED_TIMING2_BITS
+#define ESTABLISHED_TIMING2_BITS 0x00
+#endif
+#ifndef ESTABLISHED_TIMING3_BITS
+#define ESTABLISHED_TIMING3_BITS 0x00
+#endif
 #define mfgname2id(v1,v2,v3) \
        ((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f))
 #define swap16(v1) ((v1>>8)+((v1&0xff)<<8))
@@ -139,7 +150,7 @@ white_x_y_msb:	.byte	0x50,0x54
   Bit 2        640x480 @ 75 Hz
   Bit 1        800x600 @ 56 Hz
   Bit 0        800x600 @ 60 Hz */
-estbl_timing1:  .byte   0x00
+estbl_timing1:  .byte   ESTABLISHED_TIMING1_BITS
 /* Bit 7        800x600 @ 72 Hz
   Bit 6        800x600 @ 75 Hz
@@ -149,11 +160,11 @@ estbl_timing1:	.byte	0x00
   Bit 2        1024x768 @ 72 Hz
   Bit 1        1024x768 @ 75 Hz
   Bit 0        1280x1024 @ 75 Hz */
-estbl_timing2:  .byte   ESTABLISHED_TIMINGS_BITS
+estbl_timing2:  .byte   ESTABLISHED_TIMING2_BITS
 /* Bit 7        1152x870 @ 75 Hz (Apple Macintosh II)
   Bits 6-0     Other manufacturer-specific display mod */
-estbl_timing3:  .byte   0x00
+estbl_timing3:  .byte   ESTABLISHED_TIMING3_BITS
 /* Standard timing */
 /* X resolution, less 31, divided by 8 (256-2288 pixels) */
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index b3429aec444c..02ab997a1ed2 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -458,15 +458,11 @@ About use_hierarchy, see Section 6.
 5.1 force_empty
  memory.force_empty interface is provided to make cgroup's memory usage empty.
-  You can use this interface only when the cgroup has no tasks.
  When writing anything to this
  # echo 0 > memory.force_empty
-  Almost all pages tracked by this memory cgroup will be unmapped and freed.
+  the cgroup will be reclaimed and as many pages reclaimed as possible.
-  Some pages cannot be freed because they are locked or in-use. Such pages are
-  moved to parent (if use_hierarchy==1) or root (if use_hierarchy==0) and this
-  cgroup will be empty.
  The typical use case for this interface is before calling rmdir().
  Because rmdir() moves all pages to parent, some out-of-use page caches can be
diff --git a/Documentation/cgroups/unified-hierarchy.txt b/Documentation/cgroups/unified-hierarchy.txt
new file mode 100644
index 000000000000..324b182e6000
--- /dev/null
+++ b/Documentation/cgroups/unified-hierarchy.txt
@@ -0,0 +1,359 @@
+Cgroup unified hierarchy
+April, 2014             Tejun Heo <tj@kernel.org>
+This document describes the changes made by unified hierarchy and
+their rationales.  It will eventually be merged into the main cgroup
+documentation.
+CONTENTS
+1. Background
+2. Basic Operation
+  2-1. Mounting
+  2-2. cgroup.subtree_control
+  2-3. cgroup.controllers
+3. Structural Constraints
+  3-1. Top-down
+  3-2. No internal tasks
+4. Other Changes
+  4-1. [Un]populated Notification
+  4-2. Other Core Changes
+  4-3. Per-Controller Changes
+    4-3-1. blkio
+    4-3-2. cpuset
+    4-3-3. memory
+5. Planned Changes
+  5-1. CAP for resource control
+1. Background
+cgroup allows an arbitrary number of hierarchies and each hierarchy
+can host any number of controllers.  While this seems to provide a
+high level of flexibility, it isn't quite useful in practice.
+For example, as there is only one instance of each controller, utility
+type controllers such as freezer which can be useful in all
+hierarchies can only be used in one.  The issue is exacerbated by the
+fact that controllers can't be moved around once hierarchies are
+populated.  Another issue is that all controllers bound to a hierarchy
+are forced to have exactly the same view of the hierarchy.  It isn't
+possible to vary the granularity depending on the specific controller.
+In practice, these issues heavily limit which controllers can be put
+on the same hierarchy and most configurations resort to putting each
+controller on its own hierarchy.  Only closely related ones, such as
+the cpu and cpuacct controllers, make sense to put on the same
+hierarchy.  This often means that userland ends up managing multiple
+similar hierarchies repeating the same steps on each hierarchy
+whenever a hierarchy management operation is necessary.
+Unfortunately, support for multiple hierarchies comes at a steep cost.
+Internal implementation in cgroup core proper is dazzlingly
+complicated but more importantly the support for multiple hierarchies
+restricts how cgroup is used in general and what controllers can do.
+There's no limit on how many hierarchies there may be, which means
+that a task's cgroup membership can't be described in finite length.
+The key may contain any varying number of entries and is unlimited in
+length, which makes it highly awkward to handle and leads to addition
+of controllers which exist only to identify membership, which in turn
+exacerbates the original problem.
+Also, as a controller can't have any expectation regarding what shape
+of hierarchies other controllers would be on, each controller has to
+assume that all other controllers are operating on completely
+orthogonal hierarchies.  This makes it impossible, or at least very
+cumbersome, for controllers to cooperate with each other.
+In most use cases, putting controllers on hierarchies which are
+completely orthogonal to each other isn't necessary.  What usually is
+called for is the ability to have differing levels of granularity
+depending on the specific controller.  In other words, hierarchy may
+be collapsed from leaf towards root when viewed from specific
+controllers.  For example, a given configuration might not care about
+how memory is distributed beyond a certain level while still wanting
+to control how CPU cycles are distributed.
+Unified hierarchy is the next version of cgroup interface.  It aims to
+address the aforementioned issues by having more structure while
+retaining enough flexibility for most use cases.  Various other
+general and controller-specific interface issues are also addressed in
+the process.
+2. Basic Operation
+2-1. Mounting
+Currently, unified hierarchy can be mounted with the following mount
+command.  Note that this is still under development and scheduled to
+change soon.
+ mount -t cgroup -o __DEVEL__sane_behavior cgroup $MOUNT_POINT
+All controllers which are not bound to other hierarchies are
+automatically bound to unified hierarchy and show up at the root of
+it.  Controllers which are enabled only in the root of unified
+hierarchy can be bound to other hierarchies at any time.  This allows
+mixing unified hierarchy with the traditional multiple hierarchies in
+a fully backward compatible way.
+2-2. cgroup.subtree_control
+All cgroups on unified hierarchy have a "cgroup.subtree_control" file
+which governs which controllers are enabled on the children of the
+cgroup.  Let's assume a hierarchy like the following.
+  root - A - B - C
+               \ D
+root's "cgroup.subtree_control" file determines which controllers are
+enabled on A.  A's on B.  B's on C and D.  This coincides with the
+fact that controllers on the immediate sub-level are used to
+distribute the resources of the parent.  In fact, it's natural to
+assume that resource control knobs of a child belong to its parent.
+Enabling a controller in a "cgroup.subtree_control" file declares that
+distribution of the respective resources of the cgroup will be
+controlled.  Note that this means that controller enable states are
+shared among siblings.
+When read, the file contains a space-separated list of currently
+enabled controllers.  A write to the file should contain a
+space-separated list of controllers with '+' or '-' prefixed (without
+the quotes).  Controllers prefixed with '+' are enabled and '-'
+disabled.  If a controller is listed multiple times, the last entry
+wins.  The specific operations are executed atomically - either all
+succeed or fail.
+2-3. cgroup.controllers
+Read-only "cgroup.controllers" file contains a space-separated list of
+controllers which can be enabled in the cgroup's
+"cgroup.subtree_control" file.
+In the root cgroup, this lists controllers which are not bound to
+other hierarchies and the content changes as controllers are bound to
+and unbound from other hierarchies.
+In non-root cgroups, the content of this file equals that of the
+parent's "cgroup.subtree_control" file as only controllers enabled
+from the parent can be used in its children.
+3. Structural Constraints
+3-1. Top-down
+As it doesn't make sense to nest control of an uncontrolled resource,
+all non-root "cgroup.subtree_control" files can only contain
+controllers which are enabled in the parent's "cgroup.subtree_control"
+file.  A controller can be enabled only if the parent has the
+controller enabled and a controller can't be disabled if one or more
+children have it enabled.
+3-2. No internal tasks
+One long-standing issue that cgroup faces is the competition between
+tasks belonging to the parent cgroup and its children cgroups.  This
+is inherently nasty as two different types of entities compete and
+there is no agreed-upon obvious way to handle it.  Different
+controllers are doing different things.
+The cpu controller considers tasks and cgroups as equivalents and maps
+nice levels to cgroup weights.  This works for some cases but falls
+flat when children should be allocated specific ratios of CPU cycles
+and the number of internal tasks fluctuates - the ratios constantly
+change as the number of competing entities fluctuates.  There also are
+other issues.  The mapping from nice level to weight isn't obvious or
+universal, and there are various other knobs which simply aren't
+available for tasks.
+The blkio controller implicitly creates a hidden leaf node for each
+cgroup to host the tasks.  The hidden leaf has its own copies of all
+the knobs with "leaf_" prefixed.  While this allows equivalent control
+over internal tasks, it's with serious drawbacks.  It always adds an
+extra layer of nesting which may not be necessary, makes the interface
+messy and significantly complicates the implementation.
+The memory controller currently doesn't have a way to control what
+happens between internal tasks and child cgroups and the behavior is
+not clearly defined.  There have been attempts to add ad-hoc behaviors
+and knobs to tailor the behavior to specific workloads.  Continuing
+this direction will lead to problems which will be extremely difficult
+to resolve in the long term.
+Multiple controllers struggle with internal tasks and came up with
+different ways to deal with it; unfortunately, all the approaches in
+use now are severely flawed and, furthermore, the widely different
+behaviors make cgroup as whole highly inconsistent.
+It is clear that this is something which needs to be addressed from
+cgroup core proper in a uniform way so that controllers don't need to
+worry about it and cgroup as a whole shows a consistent and logical
+behavior.  To achieve that, unified hierarchy enforces the following
+structural constraint:
+ Except for the root, only cgroups which don't contain any task may
+ have controllers enabled in their "cgroup.subtree_control" files.
+Combined with other properties, this guarantees that, when a
+controller is looking at the part of the hierarchy which has it
+enabled, tasks are always only on the leaves.  This rules out
+situations where child cgroups compete against internal tasks of the
+parent.
+There are two things to note.  Firstly, the root cgroup is exempt from
+the restriction.  Root contains tasks and anonymous resource
+consumption which can't be associated with any other cgroup and
+requires special treatment from most controllers.  How resource
+consumption in the root cgroup is governed is up to each controller.
+Secondly, the restriction doesn't take effect if there is no enabled
+controller in the cgroup's "cgroup.subtree_control" file.  This is
+important as otherwise it wouldn't be possible to create children of a
+populated cgroup.  To control resource distribution of a cgroup, the
+cgroup must create children and transfer all its tasks to the children
+before enabling controllers in its "cgroup.subtree_control" file.
+4. Other Changes
+4-1. [Un]populated Notification
+cgroup users often need a way to determine when a cgroup's
+subhierarchy becomes empty so that it can be cleaned up.  cgroup
+currently provides release_agent for it; unfortunately, this mechanism
+is riddled with issues.
+- It delivers events by forking and execing a userland binary
+  specified as the release_agent.  This is a long deprecated method of
+  notification delivery.  It's extremely heavy, slow and cumbersome to
+  integrate with larger infrastructure.
+- There is single monitoring point at the root.  There's no way to
+  delegate management of a subtree.
+- The event isn't recursive.  It triggers when a cgroup doesn't have
+  any tasks or child cgroups.  Events for internal nodes trigger only
+  after all children are removed.  This again makes it impossible to
+  delegate management of a subtree.
+- Events are filtered from the kernel side.  A "notify_on_release"
+  file is used to subscribe to or suppress release events.  This is
+  unnecessarily complicated and probably done this way because event
+  delivery itself was expensive.
+Unified hierarchy implements an interface file "cgroup.populated"
+which can be used to monitor whether the cgroup's subhierarchy has
+tasks in it or not.  Its value is 0 if there is no task in the cgroup
+and its descendants; otherwise, 1.  poll and [id]notify events are
+triggered when the value changes.
+This is significantly lighter and simpler and trivially allows
+delegating management of subhierarchy - subhierarchy monitoring can
+block further propagation simply by putting itself or another process
+in the subhierarchy and monitor events that it's interested in from
+there without interfering with monitoring higher in the tree.
+In unified hierarchy, the release_agent mechanism is no longer
+supported and the interface files "release_agent" and
+"notify_on_release" do not exist.
+4-2. Other Core Changes
+- None of the mount options is allowed.
+- remount is disallowed.
+- rename(2) is disallowed.
+- The "tasks" file is removed.  Everything should at process
+  granularity.  Use the "cgroup.procs" file instead.
+- The "cgroup.procs" file is not sorted.  pids will be unique unless
+  they got recycled in-between reads.
+- The "cgroup.clone_children" file is removed.
+4-3. Per-Controller Changes
+4-3-1. blkio
+- blk-throttle becomes properly hierarchical.
+4-3-2. cpuset
+- Tasks are kept in empty cpusets after hotplug and take on the masks
+  of the nearest non-empty ancestor, instead of being moved to it.
+- A task can be moved into an empty cpuset, and again it takes on the
+  masks of the nearest non-empty ancestor.
+4-3-3. memory
+- use_hierarchy is on by default and the cgroup file for the flag is
+  not created.
+5. Planned Changes
+5-1. CAP for resource control
+Unified hierarchy will require one of the capabilities(7), which is
+yet to be decided, for all resource control related knobs.  Process
+organization operations - creation of sub-cgroups and migration of
+processes in sub-hierarchies may be delegated by changing the
+ownership and/or permissions on the cgroup directory and
+"cgroup.procs" interface file; however, all operations which affect
+resource control - writes to a "cgroup.subtree_control" file or any
+controller-specific knobs - will require an explicit CAP privilege.
+This, in part, is to prevent the cgroup interface from being
+inadvertently promoted to programmable API used by non-privileged
+binaries.  cgroup exposes various aspects of the system in ways which
+aren't properly abstracted for direct consumption by regular programs.
+This is an administration interface much closer to sysctl knobs than
+system calls.  Even the basic access model, being filesystem path
+based, isn't suitable for direct consumption.  There's no way to
+access "my cgroup" in a race-free way or make multiple operations
+atomic against migration to another cgroup.
+Another aspect is that, for better or for worse, the cgroup interface
+goes through far less scrutiny than regular interfaces for
+unprivileged userland.  The upside is that cgroup is able to expose
+useful features which may not be suitable for general consumption in a
+reasonable time frame.  It provides a relatively short path between
+internal details and userland-visible interface.  Of course, this
+shortcut comes with high risk.  We go through what we go through for
+general kernel APIs for good reasons.  It may end up leaking internal
+details in a way which can exert significant pain by locking the
+kernel into a contract that can't be maintained in a reasonable
+manner.
+Also, due to the specific nature, cgroup and its controllers don't
+tend to attract attention from a wide scope of developers.  cgroup's
+short history is already fraught with severely mis-designed
+interfaces, unnecessary commitments to and exposing of internal
+details, broken and dangerous implementations of various features.
+Keeping cgroup as an administration interface is both advantageous for
+its role and imperative given its nature.  Some of the cgroup features
+may make sense for unprivileged access.  If deemed justified, those
+must be further abstracted and implemented as a different interface,
+be it a system call or process-private filesystem, and survive through
+the scrutiny that any interface for general consumption is required to
+go through.
+Requiring CAP is not a complete solution but should serve as a
+significant deterrent against spraying cgroup usages in non-privileged
+programs.
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index b045fe54986a..14f4e6336d88 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -26,6 +26,7 @@ Contents:
 1.4  target/target_index or setpolicy?
 1.5  target/target_index
 1.6  setpolicy
+1.7  get_intermediate and target_intermediate
 2.   Frequency Table Helpers
@@ -79,6 +80,10 @@ cpufreq_driver.attr -		A pointer to a NULL-terminated list of
                                "struct freq_attr" which allow to
                                export values to sysfs.
+cpufreq_driver.get_intermediate
+and target_intermediate         Used to switch to stable frequency while
+                                changing CPU frequency.
 1.2 Per-CPU Initialization
 --------------------------
@@ -151,7 +156,7 @@ Some cpufreq-capable processors switch the frequency between certain
 limits on their own. These shall use the ->setpolicy call
-1.4. target/target_index
+1.5. target/target_index
 -------------
 The target_index call has two arguments: struct cpufreq_policy *policy,
@@ -160,6 +165,9 @@ and unsigned int index (into the exposed frequency table).
 The CPUfreq driver must set the new frequency when called here. The
 actual frequency must be determined by freq_table[index].frequency.
+It should always restore to earlier frequency (i.e. policy->restore_freq) in
+case of errors, even if we switched to intermediate frequency earlier.
 Deprecated:
 ----------
 The target call has three arguments: struct cpufreq_policy *policy,
@@ -179,7 +187,7 @@ Here again the frequency table helper might assist you - see section 2
 for details.
-1.5 setpolicy
+1.6 setpolicy
 ---------------
 The setpolicy call only takes a struct cpufreq_policy *policy as
@@ -190,6 +198,23 @@ setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a
 powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check
 the reference implementation in drivers/cpufreq/longrun.c
+1.7 get_intermediate and target_intermediate
+--------------------------------------------
+Only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset.
+get_intermediate should return a stable intermediate frequency platform wants to
+switch to, and target_intermediate() should set CPU to to that frequency, before
+jumping to the frequency corresponding to 'index'. Core will take care of
+sending notifications and driver doesn't have to handle them in
+target_intermediate() or target_index().
+Drivers can return '0' from get_intermediate() in case they don't wish to switch
+to intermediate frequency for some target frequency. In that case core will
+directly call ->target_index().
+NOTE: ->target_index() should restore to policy->restore_freq in case of
+failures as core would send notifications for that.
 2. Frequency Table Helpers
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 48b285ffa3a6..c96d8dcf98fd 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -4,10 +4,16 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
 Each SATA controller should have its own node.
 Required properties:
- compatible        : compatible list, one of "snps,spear-ahci",
+- compatible        : compatible string, one of:
-                      "snps,exynos5440-ahci", "ibm,476gtr-ahci",
+  - "allwinner,sun4i-a10-ahci"
-                      "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci"
+  - "fsl,imx53-ahci"
-                      "fsl,imx6q-ahci" or "snps,dwc-ahci"
+  - "fsl,imx6q-ahci"
+  - "hisilicon,hisi-ahci"
+  - "ibm,476gtr-ahci"
+  - "marvell,armada-380-ahci"
+  - "snps,dwc-ahci"
+  - "snps,exynos5440-ahci"
+  - "snps,spear-ahci"
 - interrupts        : <interrupt mapping for SATA IRQ>
 - reg               : <registers mapping>
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
index 24711af48e30..5666812fc42b 100644
--- a/Documentation/devicetree/bindings/clock/corenet-clock.txt
+++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt
@@ -7,6 +7,14 @@ which can then be passed to a variety of internal logic, including
 cores and peripheral IP blocks.
 Please refer to the Reference Manual for details.
+All references to "1.0" and "2.0" refer to the QorIQ chassis version to
+which the chip complies.
+Chassis Version         Example Chips
+---------------         -------------
+1.0                     p4080, p5020, p5040
+2.0                     t4240, b4860, t1040
 1. Clock Block Binding
 Required properties:
@@ -85,7 +93,7 @@ Example for clock block and clock provider:
                        #clock-cells = <0>;
                        compatible = "fsl,qoriq-sysclk-1.0";
                        clock-output-names = "sysclk";
-                }
+                };
                pll0: pll0@800 {
                        #clock-cells = <1>;
diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt
index a4fa4efa1d83..7a802f64e5bd 100644
--- a/Documentation/devicetree/bindings/dma/mmp-dma.txt
+++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt
@@ -1,17 +1,20 @@
 * MARVELL MMP DMA controller
 Marvell Peripheral DMA Controller
-Used platfroms: pxa688, pxa910, pxa3xx, etc
+Used platforms: pxa688, pxa910, pxa3xx, etc
 Required properties:
 - compatible: Should be "marvell,pdma-1.0"
 - reg: Should contain DMA registers location and length.
 - interrupts: Either contain all of the per-channel DMA interrupts
                or one irq for pdma device
- #dma-channels: Number of DMA channels supported by the controller.
+Optional properties:
+- #dma-channels: Number of DMA channels supported by the controller (defaults
+  to 32 when not specified)
 "marvell,pdma-1.0"
-Used platfroms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
+Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
 Examples:
@@ -45,7 +48,7 @@ pdma: dma-controller@d4000000 {
 Marvell Two Channel DMA Controller used specifically for audio
-Used platfroms: pxa688, pxa910
+Used platforms: pxa688, pxa910
 Required properties:
 - compatible: Should be "marvell,adma-1.0" or "marvell,pxa910-squ"
diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
new file mode 100644
index 000000000000..1405ed071bb4
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -0,0 +1,75 @@
+Xilinx AXI VDMA engine, it does transfers between memory and video devices.
+It can be configured to have one channel or two channels. If configured
+as two channels, one is to transmit to the video device and another is
+to receive from the video device.
+Required properties:
+- compatible: Should be "xlnx,axi-vdma-1.00.a"
+- #dma-cells: Should be <1>, see "dmas" property below
+- reg: Should contain VDMA registers location and length.
+- xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+- dma-channel child node: Should have at least one channel and can have up to
+        two channels per device. This node specifies the properties of each
+        DMA channel (see child node properties below).
+Optional properties:
+- xlnx,include-sg: Tells configured for Scatter-mode in
+        the hardware.
+- xlnx,flush-fsync: Tells which channel to Flush on Frame sync.
+        It takes following values:
+        {1}, flush both channels
+        {2}, flush mm2s channel
+        {3}, flush s2mm channel
+Required child node properties:
+- compatible: It should be either "xlnx,axi-vdma-mm2s-channel" or
+        "xlnx,axi-vdma-s2mm-channel".
+- interrupts: Should contain per channel VDMA interrupts.
+- xlnx,data-width: Should contain the stream data width, take values
+        {32,64...1024}.
+Optional child node properties:
+- xlnx,include-dre: Tells hardware is configured for Data
+        Realignment Engine.
+- xlnx,genlock-mode: Tells Genlock synchronization is
+        enabled/disabled in hardware.
+Example:
++++++++
+axi_vdma_0: axivdma@40030000 {
+        compatible = "xlnx,axi-vdma-1.00.a";
+        #dma_cells = <1>;
+        reg = < 0x40030000 0x10000 >;
+        xlnx,num-fstores = <0x8>;
+        xlnx,flush-fsync = <0x1>;
+        dma-channel@40030000 {
+                compatible = "xlnx,axi-vdma-mm2s-channel";
+                interrupts = < 0 54 4 >;
+                xlnx,datawidth = <0x40>;
+        } ;
+        dma-channel@40030030 {
+                compatible = "xlnx,axi-vdma-s2mm-channel";
+                interrupts = < 0 53 4 >;
+                xlnx,datawidth = <0x40>;
+        } ;
+} ;
+* DMA client
+Required properties:
+- dmas: a list of <[Video DMA device phandle] [Channel ID]> pairs,
+        where Channel ID is '0' for write/tx and '1' for read/rx
+        channel.
+- dma-names: a list of DMA channel names, one per "dmas" entry
+Example:
++++++++
+vdmatest_0: vdmatest@0 {
+        compatible ="xlnx,axi-vdma-test-1.00.a";
+        dmas = <&axi_vdma_0 0
+                &axi_vdma_0 1>;
+        dma-names = "vdma0", "vdma1";
+} ;
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index efa8b8451f93..b48f4ef31d93 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -136,6 +136,7 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-hdmi"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - hdmi-supply: supply for the +5V HDMI connector pin
  - vdd-supply: regulator for supply voltage
  - pll-supply: regulator for PLL
  - clocks: Must contain an entry for each entry in clock-names.
@@ -180,6 +181,7 @@ of the following host1x client modules:
    See ../reset/reset.txt for details.
  - reset-names: Must include the following entries:
    - dsi
+  - avdd-dsi-supply: phandle of a supply that powers the DSI controller
  - nvidia,mipi-calibrate: Should contain a phandle and a specifier specifying
    which pads are used by this DSI output and need to be calibrated. See also
    ../mipi/nvidia,tegra114-mipi.txt.
diff --git a/Documentation/devicetree/bindings/gpio/gpio_keys.txt b/Documentation/devicetree/bindings/input/gpio-keys.txt
index 5c2c02140a62..5c2c02140a62 100644
--- a/Documentation/devicetree/bindings/gpio/gpio_keys.txt
+++ b/Documentation/devicetree/bindings/input/gpio-keys.txt
diff --git a/Documentation/devicetree/bindings/input/st-keyscan.txt b/Documentation/devicetree/bindings/input/st-keyscan.txt
new file mode 100644
index 000000000000..51eb428e5c85
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/st-keyscan.txt
@@ -0,0 +1,60 @@
+* ST Keyscan controller Device Tree bindings
+The ST keyscan controller Device Tree binding is based on the
+matrix-keymap.
+Required properties:
+- compatible: "st,sti-keyscan"
+- reg: Register base address and size of st-keyscan controller.
+- interrupts: Interrupt number for the st-keyscan controller.
+- clocks: Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- pinctrl: Should specify pin control groups used for this controller.
+  See ../pinctrl/pinctrl-bindings.txt for details.
+- linux,keymap: The keymap for keys as described in the binding document
+  devicetree/bindings/input/matrix-keymap.txt.
+- keypad,num-rows: Number of row lines connected to the keypad controller.
+- keypad,num-columns: Number of column lines connected to the keypad
+  controller.
+Optional property:
+- st,debounce_us: Debouncing interval time in microseconds
+Example:
+keyscan: keyscan@fe4b0000 {
+        compatible = "st,sti-keyscan";
+        reg = <0xfe4b0000 0x2000>;
+        interrupts = <GIC_SPI 212 IRQ_TYPE_NONE>;
+        clocks  = <&CLK_SYSIN>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&pinctrl_keyscan>;
+        keypad,num-rows = <4>;
+        keypad,num-columns = <4>;
+        st,debounce_us = <5000>;
+        linux,keymap = < MATRIX_KEY(0x00, 0x00, KEY_F13)
+                         MATRIX_KEY(0x00, 0x01, KEY_F9)
+                         MATRIX_KEY(0x00, 0x02, KEY_F5)
+                         MATRIX_KEY(0x00, 0x03, KEY_F1)
+                         MATRIX_KEY(0x01, 0x00, KEY_F14)
+                         MATRIX_KEY(0x01, 0x01, KEY_F10)
+                         MATRIX_KEY(0x01, 0x02, KEY_F6)
+                         MATRIX_KEY(0x01, 0x03, KEY_F2)
+                         MATRIX_KEY(0x02, 0x00, KEY_F15)
+                         MATRIX_KEY(0x02, 0x01, KEY_F11)
+                         MATRIX_KEY(0x02, 0x02, KEY_F7)
+                         MATRIX_KEY(0x02, 0x03, KEY_F3)
+                         MATRIX_KEY(0x03, 0x00, KEY_F16)
+                         MATRIX_KEY(0x03, 0x01, KEY_F12)
+                         MATRIX_KEY(0x03, 0x02, KEY_F8)
+                         MATRIX_KEY(0x03, 0x03, KEY_F4) >;
+        };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
new file mode 100644
index 000000000000..aef57791f40b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
@@ -0,0 +1,20 @@
+sun4i resistive touchscreen controller
+--------------------------------------
+Required properties:
+ - compatible: "allwinner,sun4i-a10-ts"
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+Optional properties:
+ - allwinner,ts-attached: boolean indicating that an actual touchscreen is
+                          attached to the controller
+Example:
+        rtp: rtp@01c25000 {
+                compatible = "allwinner,sun4i-a10-ts";
+                reg = <0x01c25000 0x100>;
+                interrupts = <29>;
+                allwinner,ts-attached;
+        };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
new file mode 100644
index 000000000000..d8e06163c54e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.txt
@@ -0,0 +1,27 @@
+General Touchscreen Properties:
+Optional properties for Touchscreens:
+ - touchscreen-size-x           : horizontal resolution of touchscreen
+                                  (in pixels)
+ - touchscreen-size-y           : vertical resolution of touchscreen
+                                  (in pixels)
+ - touchscreen-max-pressure     : maximum reported pressure (arbitrary range
+                                  dependent on the controller)
+ - touchscreen-fuzz-x           : horizontal noise value of the absolute input
+                                  device (in pixels)
+ - touchscreen-fuzz-y           : vertical noise value of the absolute input
+                                  device (in pixels)
+ - touchscreen-fuzz-pressure    : pressure noise value of the absolute input
+                                  device (arbitrary range dependent on the
+                                  controller)
+ - touchscreen-inverted-x       : X axis is inverted (boolean)
+ - touchscreen-inverted-y       : Y axis is inverted (boolean)
+Deprecated properties for Touchscreens:
+ - x-size                       : deprecated name for touchscreen-size-x
+ - y-size                       : deprecated name for touchscreen-size-y
+ - moving-threshold             : deprecated name for a combination of
+                                  touchscreen-fuzz-x and touchscreen-fuzz-y
+ - contact-threshold            : deprecated name for touchscreen-fuzz-pressure
+ - x-invert                     : deprecated name for touchscreen-inverted-x
+ - y-invert                     : deprecated name for touchscreen-inverted-y
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
new file mode 100644
index 000000000000..4b641c7bf1c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2005.txt
@@ -0,0 +1,42 @@
+* Texas Instruments tsc2005 touchscreen controller
+Required properties:
+ - compatible                 : "ti,tsc2005"
+ - reg                        : SPI device address
+ - spi-max-frequency          : Maximal SPI speed
+ - interrupts                 : IRQ specifier
+ - reset-gpios                : GPIO specifier
+ - vio-supply                 : Regulator specifier
+Optional properties:
+ - ti,x-plate-ohms            : integer, resistance of the touchscreen's X plates
+                                in ohm (defaults to 280)
+ - ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
+                                the configured time (in milli seconds), the driver
+                                will reset it. This is disabled by default.
+ - properties defined in touchscreen.txt
+Example:
+&mcspi1 {
+        tsc2005@0 {
+                compatible = "ti,tsc2005";
+                spi-max-frequency = <6000000>;
+                reg = <0>;
+                vio-supply = <&vio>;
+                reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
+                interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
+                touchscreen-fuzz-x = <4>;
+                touchscreen-fuzz-y = <7>;
+                touchscreen-fuzz-pressure = <2>;
+                touchscreen-max-x = <4096>;
+                touchscreen-max-y = <4096>;
+                touchscreen-max-pressure = <2048>;
+                ti,x-plate-ohms = <280>;
+                ti,esd-recovery-timeout-ms = <8000>;
+        };
+}
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
index c55b8c016a9e..1b66a413fb9d 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -1,7 +1,13 @@
 Binding for TI/National Semiconductor LP55xx Led Drivers
 Required properties:
- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562" or "ti,lp8501"
+- compatible: one of
+        national,lp5521
+        national,lp5523
+        ti,lp55231
+        ti,lp5562
+        ti,lp8501
 - reg: I2C slave address
 - clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
diff --git a/Documentation/devicetree/bindings/leds/leds-pwm.txt b/Documentation/devicetree/bindings/leds/leds-pwm.txt
index 7297107cf832..6c6583c35f2f 100644
--- a/Documentation/devicetree/bindings/leds/leds-pwm.txt
+++ b/Documentation/devicetree/bindings/leds/leds-pwm.txt
@@ -13,6 +13,8 @@ LED sub-node properties:
  For the pwms and pwm-names property please refer to:
  Documentation/devicetree/bindings/pwm/pwm.txt
 - max-brightness : Maximum brightness possible for the LED
+- active-low : (optional) For PWMs where the LED is wired to supply
+  rather than ground.
 - label :  (optional)
  see Documentation/devicetree/bindings/leds/common.txt
 - linux,default-trigger :  (optional)
diff --git a/Documentation/devicetree/bindings/mfd/bfticu.txt b/Documentation/devicetree/bindings/mfd/bfticu.txt
new file mode 100644
index 000000000000..65c90776c620
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bfticu.txt
@@ -0,0 +1,25 @@
+KEYMILE bfticu Chassis Management FPGA
+The bfticu is a multifunction device that manages the whole chassis.
+Its main functionality is to collect IRQs from the whole chassis and signals
+them to a single controller.
+Required properties:
+- compatible: "keymile,bfticu"
+- interrupt-controller: the bfticu FPGA is an interrupt controller
+- interrupts: the main IRQ line to signal the collected IRQs
+- #interrupt-cells : is 2 and their usage is compliant to the 2 cells variant
+  of Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+- interrupt-parent: the parent IRQ ctrl the main IRQ is connected to
+- reg: access on the parent local bus (chip select, offset in chip select, size)
+Example:
+        chassis-mgmt@3,0 {
+                compatible = "keymile,bfticu";
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                reg = <3 0 0x100>;
+                interrupt-parent = <&mpic>;
+                interrupts = <6 1 0 0>;
+        };
diff --git a/Documentation/devicetree/bindings/mfd/qriox.txt b/Documentation/devicetree/bindings/mfd/qriox.txt
new file mode 100644
index 000000000000..f301e2d4ce76
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qriox.txt
@@ -0,0 +1,17 @@
+KEYMILE qrio Board Control CPLD
+The qrio is a multifunction device that controls the KEYMILE boards based on
+the kmp204x design.
+It is consists of a reset controller, watchdog timer, LEDs, and 2 IRQ capable
+GPIO blocks.
+Required properties:
+- compatible: "keymile,qriox"
+- reg: access on the parent local bus (chip select, offset in chip select, size)
+Example:
+        board-control@1,0 {
+                compatible = "keymile,qriox";
+                reg = <1 0 0x80>;
+        };
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
index 8e15ec35ac99..b9ee7b98d3e2 100644
--- a/Documentation/devicetree/bindings/mfd/twl4030-power.txt
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -5,7 +5,22 @@ to control the power resources, including power scripts. For now, the
 binding only supports the complete shutdown of the system after poweroff.
 Required properties:
- compatible : must be "ti,twl4030-power"
+- compatible : must be one of the following
+        "ti,twl4030-power"
+        "ti,twl4030-power-reset"
+        "ti,twl4030-power-idle"
+        "ti,twl4030-power-idle-osc-off"
+The use of ti,twl4030-power-reset is recommended at least on
+3530 that needs a special configuration for warm reset to work.
+When using ti,twl4030-power-idle, the TI recommended configuration
+for idle modes is loaded to the tlw4030 PMIC.
+When using ti,twl4030-power-idle-osc-off, the TI recommended
+configuration is used with the external oscillator being shut
+down during off-idle. Note that this does not work on all boards
+depending on how the external oscillator is wired.
 Optional properties:
 - ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 9dce540771fb..3c18001dfd5d 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -38,6 +38,8 @@ Optional properties:
 - mmc-highspeed-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
 - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
 - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
+- mmc-hs400-1_8v: eMMC HS400 mode(1.8V I/O) is supported
+- mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
diff --git a/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
new file mode 100644
index 000000000000..b63819149f22
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/moxa,moxart-mmc.txt
@@ -0,0 +1,30 @@
+MOXA ART MMC Host Controller Interface
+  Inherits from mmc binding[1].
+  [1] Documentation/devicetree/bindings/mmc/mmc.txt
+Required properties:
+- compatible :  Must be "moxa,moxart-mmc" or "faraday,ftsdc010"
+- reg :         Should contain registers location and length
+- interrupts :  Should contain the interrupt number
+- clocks :      Should contain phandle for the clock feeding the MMC controller
+Optional properties:
+- dmas :        Should contain two DMA channels, line request number must be 5 for
+                both channels
+- dma-names :   Must be "tx", "rx"
+Example:
+        mmc: mmc@98e00000 {
+                compatible = "moxa,moxart-mmc";
+                reg = <0x98e00000 0x5C>;
+                interrupts = <5 0>;
+                clocks = <&clk_apb>;
+                dmas =  <&dma 5>,
+                        <&dma 5>;
+                dma-names = "tx", "rx";
+        };
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 8f3f13315358..2d4a7258a10d 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -69,10 +69,6 @@ Optional properties:
 * supports-highspeed: Enables support for high speed cards (up to 50MHz)
-* caps2-mmc-hs200-1_8v: Supports mmc HS200 SDR 1.8V mode
-* caps2-mmc-hs200-1_2v: Supports mmc HS200 SDR 1.2V mode
 * broken-cd: as documented in mmc core bindings.
 * vmmc-supply: The phandle to the regulator to use for vmmc.  If this is
@@ -103,7 +99,6 @@ board specific portions as listed below.
                clock-freq-min-max = <400000 200000000>;
                num-slots = <1>;
                supports-highspeed;
-                caps2-mmc-hs200-1_8v;
                broken-cd;
                fifo-depth = <0x80>;
                card-detect-delay = <200>;
diff --git a/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
new file mode 100644
index 000000000000..8babdaa8623b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/usdhi6rol0.txt
@@ -0,0 +1,33 @@
+* Renesas usdhi6rol0 SD/SDIO host controller
+Required properties:
+- compatible:   must be
+                "renesas,usdhi6rol0"
+- interrupts:   3 interrupts, named "card detect", "data" and "SDIO" must be
+                specified
+- clocks:       a clock binding for the IMCLK input
+Optional properties:
+- vmmc-supply:  a phandle of a regulator, supplying Vcc to the card
+- vqmmc-supply: a phandle of a regulator, supplying VccQ to the card
+Additionally any standard mmc bindings from mmc.txt can be used.
+Example:
+sd0: sd@ab000000 {
+        compatible = "renesas,usdhi6rol0";
+        reg = <0xab000000 0x200>;
+        interrupts = <0 23 0x4
+                      0 24 0x4
+                      0 25 0x4>;
+        interrupt-names = "card detect", "data", "SDIO";
+        bus-width = <4>;
+        max-frequency = <50000000>;
+        cap-power-off-card;
+        clocks = <&imclk>;
+        vmmc-supply = <&vcc_sd0>;
+        vqmmc-supply = <&vccq_sd0>;
+};
diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
new file mode 100644
index 000000000000..823d13412195
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -0,0 +1,35 @@
+* Freescale Quad Serial Peripheral Interface(QuadSPI)
+Required properties:
+  - compatible : Should be "fsl,vf610-qspi"
+  - reg : the first contains the register location and length,
+          the second contains the memory mapping address and length
+  - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
+  - interrupts : Should contain the interrupt for the device
+  - clocks : The clocks needed by the QuadSPI controller
+  - clock-names : the name of the clocks
+Optional properties:
+  - fsl,qspi-has-second-chip: The controller has two buses, bus A and bus B.
+                              Each bus can be connected with two NOR flashes.
+                              Most of the time, each bus only has one NOR flash
+                              connected, this is the default case.
+                              But if there are two NOR flashes connected to the
+                              bus, you should enable this property.
+                              (Please check the board's schematic.)
+Example:
+qspi0: quadspi@40044000 {
+        compatible = "fsl,vf610-qspi";
+        reg = <0x40044000 0x1000>, <0x20000000 0x10000000>;
+        reg-names = "QuadSPI", "QuadSPI-memory";
+        interrupts = <0 24 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&clks VF610_CLK_QSPI0_EN>,
+                <&clks VF610_CLK_QSPI0>;
+        clock-names = "qspi_en", "qspi";
+        flash0: s25fl128s@0 {
+                ....
+        };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index eb05255b6788..65f4f7c43136 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -28,6 +28,8 @@ Optional properties:
                "ham1"          1-bit Hamming ecc code
                "bch4"          4-bit BCH ecc code
                "bch8"          8-bit BCH ecc code
+                "bch16"         16-bit BCH ECC code
+                Refer below "How to select correct ECC scheme for your device ?"
 - ti,nand-xfer-type:           A string setting the data transfer type. One of:
@@ -90,3 +92,46 @@ Example for an AM33xx board:
                };
        };
+How to select correct ECC scheme for your device ?
+--------------------------------------------------
+Higher ECC scheme usually means better protection against bit-flips and
+increased system lifetime. However, selection of ECC scheme is dependent
+on various other factors also like;
+(1) support of built in hardware engines.
+        Some legacy OMAP SoC do not have ELM harware engine, so those SoC cannot
+        support ecc-schemes with hardware error-correction (BCHx_HW). However
+        such SoC can use ecc-schemes with software library for error-correction
+        (BCHx_HW_DETECTION_SW). The error correction capability with software
+        library remains equivalent to their hardware counter-part, but there is
+        slight CPU penalty when too many bit-flips are detected during reads.
+(2) Device parameters like OOBSIZE.
+        Other factor which governs the selection of ecc-scheme is oob-size.
+        Higher ECC schemes require more OOB/Spare area to store ECC syndrome,
+        so the device should have enough free bytes available its OOB/Spare
+        area to accomodate ECC for entire page. In general following expression
+        helps in determining if given device can accomodate ECC syndrome:
+        "2 + (PAGESIZE / 512) * ECC_BYTES" >= OOBSIZE"
+        where
+                OOBSIZE         number of bytes in OOB/spare area
+                PAGESIZE        number of bytes in main-area of device page
+                ECC_BYTES       number of ECC bytes generated to protect
+                                512 bytes of data, which is:
+                                '3' for HAM1_xx ecc schemes
+                                '7' for BCH4_xx ecc schemes
+                                '14' for BCH8_xx ecc schemes
+                                '26' for BCH16_xx ecc schemes
+        Example(a): For a device with PAGESIZE = 2048 and OOBSIZE = 64 and
+                trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
+                Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
+                which is greater than capacity of NAND device (OOBSIZE=64)
+                Hence, BCH16 cannot be supported on given device. But it can
+                probably use lower ecc-schemes like BCH8.
+        Example(b): For a device with PAGESIZE = 2048 and OOBSIZE = 128 and
+                trying to use BCH16 (ECC_BYTES=26) ecc-scheme.
+                Number of ECC bytes per page = (2 + (2048 / 512) * 26) = 106 B
+                which can be accomodate in the OOB/Spare area of this device
+                (OOBSIZE=128). So this device can use BCH16 ecc-scheme.
diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt b/Documentation/devicetree/bindings/mtd/m25p80.txt
index 6d3d57609470..4611aa83531b 100644
--- a/Documentation/devicetree/bindings/mtd/m25p80.txt
+++ b/Documentation/devicetree/bindings/mtd/m25p80.txt
@@ -5,8 +5,8 @@ Required properties:
  representing partitions.
 - compatible : Should be the manufacturer and the name of the chip. Bear in mind
               the DT binding is not Linux-only, but in case of Linux, see the
-               "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of
+               "spi_nor_ids" table in drivers/mtd/spi-nor/spi-nor.c for the list
-               supported chips.
+               of supported chips.
 - reg : Chip-Select number
 - spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
index 86e0a5601ff5..de8b517a5521 100644
--- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
@@ -17,6 +17,14 @@ Optional properties:
 - num-cs:                      Number of chipselect lines to usw
 - nand-on-flash-bbt:           boolean to enable on flash bbt option if
                                not present false
+ - nand-ecc-strength:           number of bits to correct per ECC step
+ - nand-ecc-step-size:          number of data bytes covered by a single ECC step
+The following ECC strength and step size are currently supported:
+ - nand-ecc-strength = <1>, nand-ecc-step-size = <512>
+ - nand-ecc-strength = <4>, nand-ecc-step-size = <512>
+ - nand-ecc-strength = <8>, nand-ecc-step-size = <512>
 Example:
diff --git a/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt
new file mode 100644
index 000000000000..d01ed63d3ebb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amd-xgbe-phy.txt
@@ -0,0 +1,17 @@
+* AMD 10GbE PHY driver (amd-xgbe-phy)
+Required properties:
+- compatible: Should be "amd,xgbe-phy-seattle-v1a" and
+  "ethernet-phy-ieee802.3-c45"
+- reg: Address and length of the register sets for the device
+   - SerDes Rx/Tx registers
+   - SerDes integration registers (1/2)
+   - SerDes integration registers (2/2)
+Example:
+        xgbe_phy@e1240800 {
+                compatible = "amd,xgbe-phy-seattle-v1a", "ethernet-phy-ieee802.3-c45";
+                reg = <0 0xe1240800 0 0x00400>,
+                      <0 0xe1250000 0 0x00060>,
+                      <0 0xe1250080 0 0x00004>;
+        };
diff --git a/Documentation/devicetree/bindings/net/amd-xgbe.txt b/Documentation/devicetree/bindings/net/amd-xgbe.txt
new file mode 100644
index 000000000000..ea0c7908a3b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/amd-xgbe.txt
@@ -0,0 +1,34 @@
+* AMD 10GbE driver (amd-xgbe)
+Required properties:
+- compatible: Should be "amd,xgbe-seattle-v1a"
+- reg: Address and length of the register sets for the device
+   - MAC registers
+   - PCS registers
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupts: Should contain the amd-xgbe interrupt
+- clocks: Should be the DMA clock for the amd-xgbe device (used for
+  calculating the correct Rx interrupt watchdog timer value on a DMA
+  channel for coalescing)
+- clock-names: Should be the name of the DMA clock, "dma_clk"
+- phy-handle: See ethernet.txt file in the same directory
+- phy-mode: See ethernet.txt file in the same directory
+Optional properties:
+- mac-address: mac address to be assigned to the device. Can be overridden
+  by UEFI.
+Example:
+        xgbe@e0700000 {
+                compatible = "amd,xgbe-seattle-v1a";
+                reg = <0 0xe0700000 0 0x80000>,
+                      <0 0xe0780000 0 0x80000>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 325 4>;
+                clocks = <&xgbe_clk>;
+                clock-names = "dma_clk";
+                phy-handle = <&phy>;
+                phy-mode = "xgmii";
+                mac-address = [ 02 a1 a2 a3 a4 a5 ];
+        };
diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
index f2febb94550e..451fef26b4df 100644
--- a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
+++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
@@ -24,7 +24,7 @@ Optional properties:
 - fixed-link: When the GENET interface is connected to a MoCA hardware block or
  when operating in a RGMII to RGMII type of connection, or when the MDIO bus is
  voluntarily disabled, this property should be used to describe the "fixed link".
-  See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on
+  See Documentation/devicetree/bindings/net/fixed-link.txt for information on
  the property specifics
 Required child nodes:
diff --git a/Documentation/devicetree/bindings/net/broadcom-systemport.txt b/Documentation/devicetree/bindings/net/broadcom-systemport.txt
new file mode 100644
index 000000000000..c183ea90d9bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/broadcom-systemport.txt
@@ -0,0 +1,29 @@
+* Broadcom BCM7xxx Ethernet Systemport Controller (SYSTEMPORT)
+Required properties:
+- compatible: should be one of "brcm,systemport-v1.00" or "brcm,systemport"
+- reg: address and length of the register set for the device.
+- interrupts: interrupts for the device, first cell must be for the the rx
+  interrupts, and the second cell should be for the transmit queues
+- local-mac-address: Ethernet MAC address (48 bits) of this adapter
+- phy-mode: Should be a string describing the PHY interface to the
+  Ethernet switch/PHY, see Documentation/devicetree/bindings/net/ethernet.txt
+- fixed-link: see Documentation/devicetree/bindings/net/fixed-link.txt for
+  the property specific details
+Optional properties:
+- systemport,num-tier2-arb: number of tier 2 arbiters, an integer
+- systemport,num-tier1-arb: number of tier 1 arbiters, an integer
+- systemport,num-txq: number of HW transmit queues, an integer
+- systemport,num-rxq: number of HW receive queues, an integer
+Example:
+ethernet@f04a0000 {
+        compatible = "brcm,systemport-v1.00";
+        reg = <0xf04a0000 0x4650>;
+        local-mac-address = [ 00 11 22 33 44 55 ];
+        fixed-link = <0 1 1000 0 0>;
+        phy-mode = "gmii";
+        interrupts = <0x0 0x16 0x0>,
+                <0x0 0x17 0x0>;
+};
diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
new file mode 100644
index 000000000000..fe38847d8e26
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
@@ -0,0 +1,44 @@
+Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
+---------------------------------------------------------
+Required properties:
+- compatible            : Should be "xlnx,zynq-can-1.0" for Zynq CAN
+                          controllers and "xlnx,axi-can-1.00.a" for Axi CAN
+                          controllers.
+- reg                   : Physical base address and size of the Axi CAN/Zynq
+                          CANPS registers map.
+- interrupts            : Property with a value describing the interrupt
+                          number.
+- interrupt-parent      : Must be core interrupt controller
+- clock-names           : List of input clock names - "can_clk", "pclk"
+                          (For CANPS), "can_clk" , "s_axi_aclk"(For AXI CAN)
+                          (See clock bindings for details).
+- clocks                : Clock phandles (see clock bindings for details).
+- tx-fifo-depth         : Can Tx fifo depth.
+- rx-fifo-depth         : Can Rx fifo depth.
+Example:
+For Zynq CANPS Dts file:
+        zynq_can_0: can@e0008000 {
+                        compatible = "xlnx,zynq-can-1.0";
+                        clocks = <&clkc 19>, <&clkc 36>;
+                        clock-names = "can_clk", "pclk";
+                        reg = <0xe0008000 0x1000>;
+                        interrupts = <0 28 4>;
+                        interrupt-parent = <&intc>;
+                        tx-fifo-depth = <0x40>;
+                        rx-fifo-depth = <0x40>;
+                };
+For Axi CAN Dts file:
+        axi_can_0: axi-can@40000000 {
+                        compatible = "xlnx,axi-can-1.00.a";
+                        clocks = <&clkc 0>, <&clkc 1>;
+                        clock-names = "can_clk","s_axi_aclk" ;
+                        reg = <0x40000000 0x10000>;
+                        interrupt-parent = <&intc>;
+                        interrupts = <0 59 1>;
+                        tx-fifo-depth = <0x40>;
+                        rx-fifo-depth = <0x40>;
+                };
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
index 7ff57a119f81..764c0c79b43d 100644
--- a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -2,7 +2,9 @@ TI CPSW Phy mode Selection Device Tree Bindings
 -----------------------------------------------
 Required properties:
- compatible            : Should be "ti,am3352-cpsw-phy-sel"
+- compatible            : Should be "ti,am3352-cpsw-phy-sel" for am335x platform and
+                          "ti,dra7xx-cpsw-phy-sel" for dra7xx platform
+                          "ti,am43xx-cpsw-phy-sel" for am43xx platform
 - reg                   : physical base address and size of the cpsw
                          registers map
 - reg-names             : names of the register map given in "reg" node
diff --git a/Documentation/devicetree/bindings/net/fixed-link.txt b/Documentation/devicetree/bindings/net/fixed-link.txt
new file mode 100644
index 000000000000..82bf7e0f47b6
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/fixed-link.txt
@@ -0,0 +1,42 @@
+Fixed link Device Tree binding
+------------------------------
+Some Ethernet MACs have a "fixed link", and are not connected to a
+normal MDIO-managed PHY device. For those situations, a Device Tree
+binding allows to describe a "fixed link".
+Such a fixed link situation is described by creating a 'fixed-link'
+sub-node of the Ethernet MAC device node, with the following
+properties:
+* 'speed' (integer, mandatory), to indicate the link speed. Accepted
+  values are 10, 100 and 1000
+* 'full-duplex' (boolean, optional), to indicate that full duplex is
+  used. When absent, half duplex is assumed.
+* 'pause' (boolean, optional), to indicate that pause should be
+  enabled.
+* 'asym-pause' (boolean, optional), to indicate that asym_pause should
+  be enabled.
+Old, deprecated 'fixed-link' binding:
+* A 'fixed-link' property in the Ethernet MAC node, with 5 cells, of the
+  form <a b c d e> with the following accepted values:
+  - a: emulated PHY ID, choose any but but unique to the all specified
+    fixed-links, from 0 to 31
+  - b: duplex configuration: 0 for half duplex, 1 for full duplex
+  - c: link speed in Mbits/sec, accepted values are: 10, 100 and 1000
+  - d: pause configuration: 0 for no pause, 1 for pause
+  - e: asymmetric pause configuration: 0 for no asymmetric pause, 1 for
+    asymmetric pause
+Example:
+ethernet@0 {
+        ...
+        fixed-link {
+              speed = <1000>;
+              full-duplex;
+        };
+        ...
+};
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 737cdef4f903..be6ea8960f20 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -42,10 +42,7 @@ Properties:
    interrupt.  For TSEC and eTSEC devices, the first interrupt is
    transmit, the second is receive, and the third is error.
  - phy-handle : See ethernet.txt file in the same directory.
-  - fixed-link : <a b c d e> where a is emulated phy id - choose any,
+  - fixed-link : See fixed-link.txt in the same directory.
-    but unique to the all specified fixed-links, b is duplex - 0 half,
-    1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
-    pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
  - phy-connection-type : See ethernet.txt file in the same directory.
    This property is only really needed if the connection is of type
    "rgmii-id", as all other connection types are detected by hardware.
diff --git a/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
new file mode 100644
index 000000000000..75d398bb1fbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/hisilicon-hix5hd2-gmac.txt
@@ -0,0 +1,36 @@
+Hisilicon hix5hd2 gmac controller
+Required properties:
+- compatible: should be "hisilicon,hix5hd2-gmac".
+- reg: specifies base physical address(s) and size of the device registers.
+  The first region is the MAC register base and size.
+  The second region is external interface control register.
+- interrupts: should contain the MAC interrupt.
+- #address-cells: must be <1>.
+- #size-cells: must be <0>.
+- phy-mode: see ethernet.txt [1].
+- phy-handle: see ethernet.txt [1].
+- mac-address: see ethernet.txt [1].
+- clocks: clock phandle and specifier pair.
+- PHY subnode: inherits from phy binding [2]
+[1] Documentation/devicetree/bindings/net/ethernet.txt
+[2] Documentation/devicetree/bindings/net/phy.txt
+Example:
+        gmac0: ethernet@f9840000 {
+                compatible = "hisilicon,hix5hd2-gmac";
+                reg = <0xf9840000 0x1000>,<0xf984300c 0x4>;
+                interrupts = <0 71 4>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                phy-mode = "mii";
+                phy-handle = <&phy2>;
+                mac-address = [00 00 00 00 00 00];
+                clocks = <&clock HIX5HD2_MAC0_CLK>;
+                phy2: ethernet-phy@2 {
+                        reg = <2>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt
new file mode 100644
index 000000000000..d3bbdded4cbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ieee802154/at86rf230.txt
@@ -0,0 +1,23 @@
+* AT86RF230 IEEE 802.15.4 *
+Required properties:
+  - compatible:         should be "atmel,at86rf230", "atmel,at86rf231",
+                        "atmel,at86rf233" or "atmel,at86rf212"
+  - spi-max-frequency:  maximal bus speed, should be set to 7500000 depends
+                        sync or async operation mode
+  - reg:                the chipselect index
+  - interrupts:         the interrupt generated by the device
+Optional properties:
+  - reset-gpio:         GPIO spec for the rstn pin
+  - sleep-gpio:         GPIO spec for the slp_tr pin
+Example:
+        at86rf231@0 {
+                compatible = "atmel,at86rf231";
+                spi-max-frequency = <7500000>;
+                reg = <0>;
+                interrupts = <19 1>;
+                interrupt-parent = <&gpio3>;
+        };
diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
index d54d0cc79487..bbdf9a7359a2 100644
--- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@ -1,9 +1,18 @@
-Micrel KS8851 Ethernet mac
+Micrel KS8851 Ethernet mac (MLL)
 Required properties:
- compatible = "micrel,ks8851-ml" of parallel interface
+- compatible = "micrel,ks8851-mll" of parallel interface
 - reg : 2 physical address and size of registers for data and command
 - interrupts : interrupt connection
+Micrel KS8851 Ethernet mac (SPI)
+Required properties:
+- compatible = "micrel,ks8851" or the deprecated "ks8851"
+- reg : chip select number
+- interrupts : interrupt connection
 Optional properties:
- vdd-supply:   supply for Ethernet mac
+- vdd-supply: analog 3.3V supply for Ethernet mac
+- vdd-io-supply: digital 1.8V IO supply for Ethernet mac
+- reset-gpios: reset_n input pin
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt b/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
deleted file mode 100644
index 997a63f1aea1..000000000000
--- a/Documentation/devicetree/bindings/net/micrel-ksz9021.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-Micrel KSZ9021 Gigabit Ethernet PHY
-Some boards require special tuning values, particularly when it comes to
-clock delays.  You can specify clock delay values by adding
-micrel-specific properties to an Ethernet OF device node.
-All skew control options are specified in picoseconds.  The minimum
-value is 0, and the maximum value is 3000.
-Optional properties:
- - rxc-skew-ps : Skew control of RXC pad
- - rxdv-skew-ps : Skew control of RX CTL pad
- - txc-skew-ps : Skew control of TXC pad
- - txen-skew-ps : Skew control of TX_CTL pad
- - rxd0-skew-ps : Skew control of RX data 0 pad
- - rxd1-skew-ps : Skew control of RX data 1 pad
- - rxd2-skew-ps : Skew control of RX data 2 pad
- - rxd3-skew-ps : Skew control of RX data 3 pad
- - txd0-skew-ps : Skew control of TX data 0 pad
- - txd1-skew-ps : Skew control of TX data 1 pad
- - txd2-skew-ps : Skew control of TX data 2 pad
- - txd3-skew-ps : Skew control of TX data 3 pad
-Examples:
-        /* Attach to an Ethernet device with autodetected PHY */
-        &enet {
-                rxc-skew-ps = <3000>;
-                rxdv-skew-ps = <0>;
-                txc-skew-ps = <3000>;
-                txen-skew-ps = <0>;
-                status = "okay";
-        };
-        /* Attach to an explicitly-specified PHY */
-        mdio {
-                phy0: ethernet-phy@0 {
-                        rxc-skew-ps = <3000>;
-                        rxdv-skew-ps = <0>;
-                        txc-skew-ps = <3000>;
-                        txen-skew-ps = <0>;
-                        reg = <0>;
-                };
-        };
-        ethernet@70000 {
-                status = "okay";
-                phy = <&phy0>;
-                phy-mode = "rgmii-id";
-        };
diff --git a/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
new file mode 100644
index 000000000000..692076fda0e5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/micrel-ksz90x1.txt
@@ -0,0 +1,83 @@
+Micrel KSZ9021/KSZ9031 Gigabit Ethernet PHY
+Some boards require special tuning values, particularly when it comes to
+clock delays. You can specify clock delay values by adding
+micrel-specific properties to an Ethernet OF device node.
+Note that these settings are applied after any phy-specific fixup from
+phy_fixup_list (see phy_init_hw() from drivers/net/phy/phy_device.c),
+and therefore may overwrite them.
+KSZ9021:
+  All skew control options are specified in picoseconds. The minimum
+  value is 0, the maximum value is 3000, and it is incremented by 200ps
+  steps.
+  Optional properties:
+    - rxc-skew-ps : Skew control of RXC pad
+    - rxdv-skew-ps : Skew control of RX CTL pad
+    - txc-skew-ps : Skew control of TXC pad
+    - txen-skew-ps : Skew control of TX CTL pad
+    - rxd0-skew-ps : Skew control of RX data 0 pad
+    - rxd1-skew-ps : Skew control of RX data 1 pad
+    - rxd2-skew-ps : Skew control of RX data 2 pad
+    - rxd3-skew-ps : Skew control of RX data 3 pad
+    - txd0-skew-ps : Skew control of TX data 0 pad
+    - txd1-skew-ps : Skew control of TX data 1 pad
+    - txd2-skew-ps : Skew control of TX data 2 pad
+    - txd3-skew-ps : Skew control of TX data 3 pad
+KSZ9031:
+  All skew control options are specified in picoseconds. The minimum
+  value is 0, and the maximum is property-dependent. The increment
+  step is 60ps.
+  Optional properties:
+    Maximum value of 1860:
+      - rxc-skew-ps : Skew control of RX clock pad
+      - txc-skew-ps : Skew control of TX clock pad
+    Maximum value of 900:
+      - rxdv-skew-ps : Skew control of RX CTL pad
+      - txen-skew-ps : Skew control of TX CTL pad
+      - rxd0-skew-ps : Skew control of RX data 0 pad
+      - rxd1-skew-ps : Skew control of RX data 1 pad
+      - rxd2-skew-ps : Skew control of RX data 2 pad
+      - rxd3-skew-ps : Skew control of RX data 3 pad
+      - txd0-skew-ps : Skew control of TX data 0 pad
+      - txd1-skew-ps : Skew control of TX data 1 pad
+      - txd2-skew-ps : Skew control of TX data 2 pad
+      - txd3-skew-ps : Skew control of TX data 3 pad
+Examples:
+        /* Attach to an Ethernet device with autodetected PHY */
+        &enet {
+                rxc-skew-ps = <3000>;
+                rxdv-skew-ps = <0>;
+                txc-skew-ps = <3000>;
+                txen-skew-ps = <0>;
+                status = "okay";
+        };
+        /* Attach to an explicitly-specified PHY */
+        mdio {
+                phy0: ethernet-phy@0 {
+                        rxc-skew-ps = <3000>;
+                        rxdv-skew-ps = <0>;
+                        txc-skew-ps = <3000>;
+                        txen-skew-ps = <0>;
+                        reg = <0>;
+                };
+        };
+        ethernet@70000 {
+                status = "okay";
+                phy = <&phy0>;
+                phy-mode = "rgmii-id";
+        };
diff --git a/Documentation/devicetree/bindings/net/nfc/pn544.txt b/Documentation/devicetree/bindings/net/nfc/pn544.txt
new file mode 100644
index 000000000000..dab69f36167c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nfc/pn544.txt
@@ -0,0 +1,35 @@
+* NXP Semiconductors PN544 NFC Controller
+Required properties:
+- compatible: Should be "nxp,pn544-i2c".
+- clock-frequency: I�C work frequency.
+- reg: address on the bus
+- interrupt-parent: phandle for the interrupt gpio controller
+- interrupts: GPIO interrupt to which the chip is connected
+- enable-gpios: Output GPIO pin used for enabling/disabling the PN544
+- firmware-gpios: Output GPIO pin used to enter firmware download mode
+Optional SoC Specific Properties:
+- pinctrl-names: Contains only one value - "default".
+- pintctrl-0: Specifies the pin control groups used for this controller.
+Example (for ARM-based BeagleBone with PN544 on I2C2):
+&i2c2 {
+        status = "okay";
+        pn544: pn544@28 {
+                compatible = "nxp,pn544-i2c";
+                reg = <0x28>;
+                clock-frequency = <400000>;
+                interrupt-parent = <&gpio1>;
+                interrupts = <17 GPIO_ACTIVE_HIGH>;
+                enable-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>;
+                firmware-gpios = <&gpio3 19 GPIO_ACTIVE_HIGH>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/nfc/st21nfca.txt b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt
new file mode 100644
index 000000000000..e4faa2e8dfeb
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nfc/st21nfca.txt
@@ -0,0 +1,33 @@
+* STMicroelectronics SAS. ST21NFCA NFC Controller
+Required properties:
+- compatible: Should be "st,st21nfca_i2c".
+- clock-frequency: I²C work frequency.
+- reg: address on the bus
+- interrupt-parent: phandle for the interrupt gpio controller
+- interrupts: GPIO interrupt to which the chip is connected
+- enable-gpios: Output GPIO pin used for enabling/disabling the ST21NFCA
+Optional SoC Specific Properties:
+- pinctrl-names: Contains only one value - "default".
+- pintctrl-0: Specifies the pin control groups used for this controller.
+Example (for ARM-based BeagleBoard xM with ST21NFCA on I2C2):
+&i2c2 {
+        status = "okay";
+        st21nfca: st21nfca@1 {
+                compatible = "st,st21nfca_i2c";
+                reg = <0x01>;
+                clock-frequency = <400000>;
+                interrupt-parent = <&gpio5>;
+                interrupts = <2 IRQ_TYPE_LEVEL_LOW>;
+                enable-gpios = <&gpio5 29 GPIO_ACTIVE_HIGH>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
index 8dd3ef7bc56b..1e436133685f 100644
--- a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -12,6 +12,7 @@ Required properties:
 Optional SoC Specific Properties:
 - pinctrl-names: Contains only one value - "default".
 - pintctrl-0: Specifies the pin control groups used for this controller.
+- autosuspend-delay: Specify autosuspend delay in milliseconds.
 Example (for ARM-based BeagleBone with TRF7970A on SPI1):
@@ -29,6 +30,7 @@ Example (for ARM-based BeagleBone with TRF7970A on SPI1):
                ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>,
                                  <&gpio2 5 GPIO_ACTIVE_LOW>;
                vin-supply = <&ldo3_reg>;
+                autosuspend-delay = <30000>;
                status = "okay";
        };
 };
diff --git a/Documentation/devicetree/bindings/net/via-rhine.txt b/Documentation/devicetree/bindings/net/via-rhine.txt
new file mode 100644
index 000000000000..334eca2bf937
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-rhine.txt
@@ -0,0 +1,17 @@
+* VIA Rhine 10/100 Network Controller
+Required properties:
+- compatible : Should be "via,vt8500-rhine" for integrated
+        Rhine controllers found in VIA VT8500, WonderMedia WM8950
+        and similar. These are listed as 1106:3106 rev. 0x84 on the
+        virtual PCI bus under vendor-provided kernels
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+Examples:
+ethernet@d8004000 {
+        compatible = "via,vt8500-rhine";
+        reg = <0xd8004000 0x100>;
+        interrupts = <10>;
+};
diff --git a/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt
new file mode 100644
index 000000000000..7443b7c76769
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b133xtn01.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 13.3" WXGA (1366x768) TFT LCD panel
+Required properties:
+- compatible: should be "auo,b133xtn01"
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt
new file mode 100644
index 000000000000..4903d7b1d947
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/edt,et057090dhu.txt
@@ -0,0 +1,7 @@
+Emerging Display Technology Corp. 5.7" VGA TFT LCD panel
+Required properties:
+- compatible: should be "edt,et057090dhu"
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt
new file mode 100644
index 000000000000..20cb38e836e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/edt,et070080dh6.txt
@@ -0,0 +1,10 @@
+Emerging Display Technology Corp. ET070080DH6 7.0" WVGA TFT LCD panel
+Required properties:
+- compatible: should be "edt,et070080dh6"
+This panel is the same as ETM0700G0DH6 except for the touchscreen.
+ET070080DH6 is the model with resistive touch.
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt
new file mode 100644
index 000000000000..ee4b18053e40
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/edt,etm0700g0dh6.txt
@@ -0,0 +1,10 @@
+Emerging Display Technology Corp. ETM0700G0DH6 7.0" WVGA TFT LCD panel
+Required properties:
+- compatible: should be "edt,etm0700g0dh6"
+This panel is the same as ET070080DH6 except for the touchscreen.
+ETM0700G0DH6 is the model with capacitive multitouch.
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d6fae13ff062..d0d15ee42834 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -1,15 +1,7 @@
 * Synopsys Designware PCIe interface
 Required properties:
- compatible: should contain "snps,dw-pcie" to identify the
+- compatible: should contain "snps,dw-pcie" to identify the core.
-        core, plus an identifier for the specific instance, such
-        as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
- reg: base addresses and lengths of the pcie controller,
-        the phy controller, additional register for the phy controller.
- interrupts: interrupt values for level interrupt,
-        pulse interrupt, special interrupt.
- clocks: from common clock binding: handle to pci clock.
- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
 - #address-cells: set to <3>
 - #size-cells: set to <2>
 - device_type: set to "pci"
@@ -19,65 +11,11 @@ Required properties:
        to define the mapping of the PCIe interface to interrupt
        numbers.
 - num-lanes: number of lanes to use
+- clocks: Must contain an entry for each entry in clock-names.
+        See ../clocks/clock-bindings.txt for details.
+- clock-names: Must include the following entries:
+        - "pcie"
+        - "pcie_bus"
 Optional properties:
 - reset-gpio: gpio pin number of power good signal
-Optional properties for fsl,imx6q-pcie
- power-on-gpio: gpio pin number of power-enable signal
- wake-up-gpio: gpio pin number of incoming wakeup signal
- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
-Example:
-SoC specific DT Entry:
-        pcie@290000 {
-                compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
-                reg = <0x290000 0x1000
-                        0x270000 0x1000
-                        0x271000 0x40>;
-                interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
-                clocks = <&clock 28>, <&clock 27>;
-                clock-names = "pcie", "pcie_bus";
-                #address-cells = <3>;
-                #size-cells = <2>;
-                device_type = "pci";
-                ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000   /* configuration space */
-                          0x81000000 0 0          0x40001000 0 0x00010000   /* downstream I/O */
-                          0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
-                #interrupt-cells = <1>;
-                interrupt-map-mask = <0 0 0 0>;
-                interrupt-map = <0x0 0 &gic 53>;
-                num-lanes = <4>;
-        };
-        pcie@2a0000 {
-                compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
-                reg = <0x2a0000 0x1000
-                        0x272000 0x1000
-                        0x271040 0x40>;
-                interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
-                clocks = <&clock 29>, <&clock 27>;
-                clock-names = "pcie", "pcie_bus";
-                #address-cells = <3>;
-                #size-cells = <2>;
-                device_type = "pci";
-                ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000   /* configuration space */
-                          0x81000000 0 0          0x60001000 0 0x00010000   /* downstream I/O */
-                          0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
-                #interrupt-cells = <1>;
-                interrupt-map-mask = <0 0 0 0>;
-                interrupt-map = <0x0 0 &gic 56>;
-                num-lanes = <4>;
-        };
-Board specific DT Entry:
-        pcie@290000 {
-                reset-gpio = <&pin_ctrl 5 0>;
-        };
-        pcie@2a0000 {
-                reset-gpio = <&pin_ctrl 22 0>;
-        };
diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
new file mode 100644
index 000000000000..9455fd0ec830
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.txt
@@ -0,0 +1,38 @@
+* Freescale i.MX6 PCIe interface
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+Required properties:
+- compatible: "fsl,imx6q-pcie"
+- reg: base addresse and length of the pcie controller
+- interrupts: A list of interrupt outputs of the controller. Must contain an
+  entry for each entry in the interrupt-names property.
+- interrupt-names: Must include the following entries:
+        - "msi": The interrupt that is asserted when an MSI is received
+- clock-names: Must include the following additional entries:
+        - "pcie_phy"
+Example:
+        pcie@0x01000000 {
+                compatible = "fsl,imx6q-pcie", "snps,dw-pcie";
+                reg = <0x01ffc000 0x4000>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                device_type = "pci";
+                ranges = <0x00000800 0 0x01f00000 0x01f00000 0 0x00080000
+                          0x81000000 0 0          0x01f80000 0 0x00010000
+                          0x82000000 0 0x01000000 0x01000000 0 0x00f00000>;
+                num-lanes = <1>;
+                interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+                interrupt-names = "msi";
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0x7>;
+                interrupt-map = <0 0 0 1 &intc GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH>,
+                                <0 0 0 2 &intc GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH>,
+                                <0 0 0 3 &intc GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>,
+                                <0 0 0 4 &intc GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&clks 144>, <&clks 206>, <&clks 189>;
+                clock-names = "pcie", "pcie_bus", "pcie_phy";
+        };
diff --git a/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
new file mode 100644
index 000000000000..4f9d23d2ed67
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/samsung,exynos5440-pcie.txt
@@ -0,0 +1,65 @@
+* Samsung Exynos 5440 PCIe interface
+This PCIe host controller is based on the Synopsis Designware PCIe IP
+and thus inherits all the common properties defined in designware-pcie.txt.
+Required properties:
+- compatible: "samsung,exynos5440-pcie"
+- reg: base addresses and lengths of the pcie controller,
+        the phy controller, additional register for the phy controller.
+- interrupts: A list of interrupt outputs for level interrupt,
+        pulse interrupt, special interrupt.
+Example:
+SoC specific DT Entry:
+        pcie@290000 {
+                compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
+                reg = <0x290000 0x1000
+                        0x270000 0x1000
+                        0x271000 0x40>;
+                interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
+                clocks = <&clock 28>, <&clock 27>;
+                clock-names = "pcie", "pcie_bus";
+                #address-cells = <3>;
+                #size-cells = <2>;
+                device_type = "pci";
+                ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000   /* configuration space */
+                          0x81000000 0 0          0x40001000 0 0x00010000   /* downstream I/O */
+                          0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &gic GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
+                num-lanes = <4>;
+        };
+        pcie@2a0000 {
+                compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
+                reg = <0x2a0000 0x1000
+                        0x272000 0x1000
+                        0x271040 0x40>;
+                interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
+                clocks = <&clock 29>, <&clock 27>;
+                clock-names = "pcie", "pcie_bus";
+                #address-cells = <3>;
+                #size-cells = <2>;
+                device_type = "pci";
+                ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000   /* configuration space */
+                          0x81000000 0 0          0x60001000 0 0x00010000   /* downstream I/O */
+                          0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &gic GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH>;
+                num-lanes = <4>;
+        };
+Board specific DT Entry:
+        pcie@290000 {
+                reset-gpio = <&pin_ctrl 5 0>;
+        };
+        pcie@2a0000 {
+                reset-gpio = <&pin_ctrl 22 0>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt
new file mode 100644
index 000000000000..db939210e29d
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/4xx/akebono.txt
@@ -0,0 +1,54 @@
+IBM Akebono board device tree
+=============================
+The IBM Akebono board is a development board for the PPC476GTR SoC.
+0) The root node
+   Required properties:
+   - model : "ibm,akebono".
+   - compatible : "ibm,akebono" , "ibm,476gtr".
+1.a) The Secure Digital Host Controller Interface (SDHCI) node
+  Represent the Secure Digital Host Controller Interfaces.
+  Required properties:
+   - compatible : should be "ibm,476gtr-sdhci","generic-sdhci".
+   - reg : should contain the SDHCI registers location and length.
+   - interrupt-parent : a phandle for the interrupt controller.
+   - interrupts : should contain the SDHCI interrupt.
+1.b) The Advanced Host Controller Interface (AHCI) SATA node
+  Represents the advanced host controller SATA interface.
+  Required properties:
+   - compatible : should be "ibm,476gtr-ahci".
+   - reg : should contain the AHCI registers location and length.
+   - interrupt-parent : a phandle for the interrupt controller.
+   - interrupts : should contain the AHCI interrupt.
+1.c) The FPGA node
+  The Akebono board stores some board information such as the revision
+  number in an FPGA which is represented by this node.
+  Required properties:
+   - compatible : should be "ibm,akebono-fpga".
+   - reg : should contain the FPGA registers location and length.
+1.d) The AVR node
+  The Akebono board has an Atmel AVR microprocessor attached to the I2C
+  bus as a power controller for the board.
+  Required properties:
+   - compatible : should be "ibm,akebono-avr".
+   - reg : should contain the I2C bus address for the AVR.
diff --git a/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt
new file mode 100644
index 000000000000..c737c8338705
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/4xx/hsta.txt
@@ -0,0 +1,19 @@
+ppc476gtr High Speed Serial Assist (HSTA) node
+==============================================
+The 476gtr SoC contains a high speed serial assist module attached
+between the plb4 and plb6 system buses to provide high speed data
+transfer between memory and system peripherals as well as support for
+PCI message signalled interrupts.
+Currently only the MSI support is used by Linux using the following
+device tree entries:
+Require properties:
+- compatible            : "ibm,476gtr-hsta-msi", "ibm,hsta-msi"
+- reg                   : register mapping for the HSTA MSI space
+- interrupt-parent      : parent controller for mapping interrupts
+- interrupts            : ordered interrupt mapping for each MSI in the register
+                          space. The first interrupt should be associated with a
+                          register offset of 0x00, the second to 0x10, etc.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/board.txt b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
index 380914e965e0..700dec4774fa 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/board.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/board.txt
@@ -67,3 +67,20 @@ Example:
                        gpio-controller;
                };
        };
+* Freescale on-board FPGA connected on I2C bus
+Some Freescale boards like BSC9132QDS have on board FPGA connected on
+the i2c bus.
+Required properties:
+- compatible: Should be a board-specific string followed by a string
+  indicating the type of FPGA.  Example:
+        "fsl,<board>-fpga", "fsl,fpga-qixis-i2c"
+- reg: Should contain the address of the FPGA
+Example:
+        fpga: fpga@66 {
+                compatible = "fsl,bsc9132qds-fpga", "fsl,fpga-qixis-i2c";
+                reg = <0x66>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
new file mode 100644
index 000000000000..454da7e08acd
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/ccf.txt
@@ -0,0 +1,46 @@
+Freescale CoreNet Coherency Fabric(CCF) Device Tree Binding
+DESCRIPTION
+The CoreNet coherency fabric is a fabric-oriented, connectivity infrastructure
+that enables the implementation of coherent, multicore systems.
+Required properties:
+- compatible: <string list>
+                fsl,corenet1-cf - CoreNet coherency fabric version 1.
+                Example chips: T4240, B4860
+                fsl,corenet2-cf - CoreNet coherency fabric version 2.
+                Example chips: P5040, P5020, P4080, P3041, P2041
+                fsl,corenet-cf - Used to represent the common registers
+                between CCF version 1 and CCF version 2.  This compatible
+                is retained for compatibility reasons, as it was already
+                used for both CCF version 1 chips and CCF version 2
+                chips.  It should be specified after either
+                "fsl,corenet1-cf" or "fsl,corenet2-cf".
+- reg: <prop-encoded-array>
+                A standard property. Represents the CCF registers.
+- interrupts: <prop-encoded-array>
+                Interrupt mapping for CCF error interrupt.
+- fsl,ccf-num-csdids: <u32>
+                Specifies the number of Coherency Subdomain ID Port Mapping
+                Registers that are supported by the CCF.
+- fsl,ccf-num-snoopids: <u32>
+                Specifies the number of Snoop ID Port Mapping Registers that
+                are supported by CCF.
+Example:
+        corenet-cf@18000 {
+                compatible = "fsl,corenet2-cf", "fsl,corenet-cf";
+                reg = <0x18000 0x1000>;
+                interrupts = <16 2 1 31>;
+                fsl,ccf-num-csdids = <32>;
+                fsl,ccf-num-snoopids = <32>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
index 922c30ad90d1..f8cd2397aa04 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpus.txt
@@ -20,3 +20,14 @@ PROPERTIES
        a property named fsl,eref-[CAT], where [CAT] is the abbreviated category
        name with all uppercase letters converted to lowercase, indicates that
        the category is supported by the implementation.
+    - fsl,portid-mapping
+        Usage: optional
+        Value type: <u32>
+        Definition: The Coherency Subdomain ID Port Mapping Registers and
+        Snoop ID Port Mapping registers, which are part of the CoreNet
+        Coherency fabric (CCF), provide a CoreNet Coherency Subdomain
+        ID/CoreNet Snoop ID to cpu mapping functions.  Certain bits from
+        these registers should be set if the coresponding CPU should be
+        snooped.  This property defines a bitmask which selects the bit
+        that should be set if this cpu should be snooped.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
index 1f5e329f756c..c2b2899885f2 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/pamu.txt
@@ -34,6 +34,15 @@ Optional properties:
                  for legacy drivers.
 - interrupt-parent : <phandle>
                  Phandle to interrupt controller
+- fsl,portid-mapping : <u32>
+                  The Coherency Subdomain ID Port Mapping Registers and
+                  Snoop ID Port Mapping registers, which are part of the
+                  CoreNet Coherency fabric (CCF), provide a CoreNet
+                  Coherency Subdomain ID/CoreNet Snoop ID to pamu mapping
+                  functions.  Certain bits from these registers should be
+                  set if PAMUs should be snooped.  This property defines
+                  a bitmask which selects the bits that should be set if
+                  PAMUs should be snooped.
 Child nodes:
@@ -88,6 +97,7 @@ Example:
                compatible = "fsl,pamu-v1.0", "fsl,pamu";
                reg = <0x20000 0x5000>;
                ranges = <0 0x20000 0x5000>;
+                fsl,portid-mapping = <0xf80000>;
                #address-cells = <1>;
                #size-cells = <1>;
                interrupts = <
diff --git a/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
new file mode 100644
index 000000000000..8eae9fe7841c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/bcm-kona-pwm.txt
@@ -0,0 +1,21 @@
+Broadcom Kona PWM controller device tree bindings
+This controller has 6 channels.
+Required Properties :
+- compatible: should contain "brcm,kona-pwm"
+- reg: physical base address and length of the controller's registers
+- clocks: phandle + clock specifier pair for the external clock
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a
+  description of the cells format.
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
+Example:
+pwm: pwm@3e01a000 {
+        compatible = "brcm,bcm11351-pwm", "brcm,kona-pwm";
+        reg = <0x3e01a000 0xc4>;
+        clocks = <&pwm_clk>;
+        #pwm-cells = <3>;
+};
diff --git a/Documentation/devicetree/bindings/thermal/armada-thermal.txt b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
index fff93d5f92de..4cf024929a3f 100644
--- a/Documentation/devicetree/bindings/thermal/armada-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/armada-thermal.txt
@@ -1,11 +1,21 @@
-* Marvell Armada 370/XP thermal management
+* Marvell Armada 370/375/380/XP thermal management
 Required properties:
 - compatible:   Should be set to one of the following:
                marvell,armada370-thermal
+                marvell,armada375-thermal
+                marvell,armada375-z1-thermal
+                marvell,armada380-thermal
                marvell,armadaxp-thermal
+                Note: As the name suggests, "marvell,armada375-z1-thermal"
+                applies for the SoC Z1 stepping only. On such stepping
+                some quirks need to be done and the register offset differs
+                from the one in the A0 stepping.
+                The operating system may auto-detect the SoC stepping and
+                update the compatible and register offsets at runtime.
 - reg:          Device's register space.
                Two entries are expected, see the examples below.
                The first one is required for the sensor register;
diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f5300fd8b..c94909215c07 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,16 +6,35 @@
               "samsung,exynos4412-tmu"
               "samsung,exynos4210-tmu"
               "samsung,exynos5250-tmu"
+               "samsung,exynos5260-tmu"
+               "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
+               "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
+                        Exynos5420 (Must pass triminfo base and triminfo clock)
               "samsung,exynos5440-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
        instances of TMU and some registers are shared across all TMU's like
        interrupt related then 2 set of register has to supplied. First set
-        belongs to each instance of TMU and second set belongs to common TMU
+        belongs to register set of TMU instance and second set belongs to
-        registers.
+        registers shared with the TMU instance.
+  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+        channels 2, 3 and 4
+        Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced
+        register, also provide clock to access that base.
+        TRIMINFO at 0x1006c000 contains data for TMU channel 3
+        TRIMINFO at 0x100a0000 contains data for TMU channel 4
+        TRIMINFO at 0x10068000 contains data for TMU channel 2
 - interrupts : Should contain interrupt for thermal system
- clocks : The main clock for TMU device
+- clocks : The main clocks for TMU device
+        -- 1. operational clock for TMU channel
+        -- 2. optional clock to access the shared registers of TMU channel
 - clock-names : Thermal system clock name
+        -- "tmu_apbif" operational clock for current TMU channel
+        -- "tmu_triminfo_apbif" clock to access the shared triminfo register
+                for current TMU channel
 - vtmu-supply: This entry is optional and provides the regulator node supplying
                voltage to TMU. If needed this entry can be placed inside
                board/platform specific dts file.
@@ -43,6 +62,31 @@ Example 2):
                clock-names = "tmu_apbif";
        };
+Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+        tmu_cpu2: tmu@10068000 {
+                compatible = "samsung,exynos5420-tmu-ext-triminfo";
+                reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+                interrupts = <0 184 0>;
+                clocks = <&clock 318>, <&clock 318>;
+                clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+        };
+        tmu_cpu3: tmu@1006c000 {
+                compatible = "samsung,exynos5420-tmu-ext-triminfo";
+                reg = <0x1006c000 0x100>, <0x100a0000 0x4>;
+                interrupts = <0 185 0>;
+                clocks = <&clock 318>, <&clock 319>;
+                clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+        };
+        tmu_gpu: tmu@100a0000 {
+                compatible = "samsung,exynos5420-tmu-ext-triminfo";
+                reg = <0x100a0000 0x100>, <0x10068000 0x4>;
+                interrupts = <0 215 0>;
+                clocks = <&clock 319>, <&clock 318>;
+                clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+        };
 Note: For multi-instance tmu each instance should have an alias correctly
 numbered in "aliases" node.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 5261271046ce..4d7f3758d1b4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -142,3 +142,4 @@ wm	Wondermedia Technologies, Inc.
 xes     Extreme Engineering Solutions (X-ES)
 xlnx    Xilinx
 zyxel   ZyXEL Communications Corp.
+zarlink Zarlink Semiconductor
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 57ccdde02c3a..53dbccfa80ca 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -62,6 +62,10 @@ Optional properties for dp-controller:
        -hsync-active-high:
                HSYNC polarity configuration.
                        High if defined, Low if not defined
+        -samsung,hpd-gpio:
+                Hotplug detect GPIO.
+                        Indicates which GPIO should be used for hotplug
+                        detection
 Example:
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index f9187a259259..1fd8cf9cbfac 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -5,6 +5,7 @@ Required properties:
        1) "samsung,exynos5-hdmi" <DEPRECATED>
        2) "samsung,exynos4210-hdmi"
        3) "samsung,exynos4212-hdmi"
+        4) "samsung,exynos5420-hdmi"
 - reg: physical base address of the hdmi and length of memory mapped
        region.
 - interrupts: interrupt number to the cpu.
@@ -27,6 +28,7 @@ Required properties:
        "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
 - ddc: phandle to the hdmi ddc node
 - phy: phandle to the hdmi phy node
+- samsung,syscon-phandle: phandle for system controller node for PMU.
 Example:
@@ -37,4 +39,5 @@ Example:
                hpd-gpio = <&gpx3 7 1>;
                ddc = <&hdmi_ddc_node>;
                phy = <&hdmi_phy_node>;
+                samsung,syscon-phandle = <&pmu_system_controller>;
        };
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
index de11eb4c121f..97223fddb7bd 100644
--- a/Documentation/devicetree/bindings/watchdog/marvel.txt
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -5,11 +5,18 @@ Required Properties:
 - Compatibility : "marvell,orion-wdt"
                  "marvell,armada-370-wdt"
                  "marvell,armada-xp-wdt"
+                  "marvell,armada-375-wdt"
+                  "marvell,armada-380-wdt"
 - reg           : Should contain two entries: first one with the
                  timer control address, second one with the
                  rstout enable address.
+For "marvell,armada-375-wdt" and "marvell,armada-380-wdt":
+- reg           : A third entry is mandatory and should contain the
+                  shared mask/unmask RSTOUT address.
 Optional properties:
 - interrupts    : Contains the IRQ for watchdog expiration
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 89472558011e..1525e30483fd 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -318,3 +318,8 @@ GPIO
  devm_gpiod_get_optional()
  devm_gpiod_get_index_optional()
  devm_gpiod_put()
+MDIO
+  devm_mdiobus_alloc()
+  devm_mdiobus_alloc_size()
+  devm_mdiobus_free()
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index eba790134253..b18dd1779029 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -196,8 +196,7 @@ prototypes:
        void (*invalidatepage) (struct page *, unsigned int, unsigned int);
        int (*releasepage) (struct page *, int);
        void (*freepage)(struct page *);
-        int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
+        int (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset);
-                        loff_t offset, unsigned long nr_segs);
        int (*get_xip_mem)(struct address_space *, pgoff_t, int, void **,
                                unsigned long *);
        int (*migratepage)(struct address_space *, struct page *, struct page *);
@@ -431,6 +430,8 @@ prototypes:
        ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
        ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
        ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
+        ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
+        ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
        int (*iterate) (struct file *, struct dir_context *);
        unsigned int (*poll) (struct file *, struct poll_table_struct *);
        long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index 25311e113e75..51afba17bbae 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -461,11 +461,11 @@ The number of blocks and buckets are determined by,
  # of blocks in level #n = |
                            `- 4, Otherwise
-                             ,- 2^ (n + dir_level),
+                             ,- 2^(n + dir_level),
-                             |            if n < MAX_DIR_HASH_DEPTH / 2,
+                             |        if n + dir_level < MAX_DIR_HASH_DEPTH / 2,
  # of buckets in level #n = |
-                             `- 2^((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1),
+                             `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1),
-                                          Otherwise
+                                      Otherwise
 When F2FS finds a file name in a directory, at first a hash value of the file
 name is calculated. Then, F2FS scans the hash table in level #0 to find the
diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt
index b930ad087780..c49cd7e796e7 100644
--- a/Documentation/filesystems/nfs/nfs41-server.txt
+++ b/Documentation/filesystems/nfs/nfs41-server.txt
@@ -176,7 +176,5 @@ Nonstandard compound limitations:
  ca_maxrequestsize request and a ca_maxresponsesize reply, so we may
  fail to live up to the promise we made in CREATE_SESSION fore channel
  negotiation.
-* No more than one read-like operation allowed per compound; encoding
-  replies that cross page boundaries (except for read data) not handled.
 See also http://wiki.linux-nfs.org/wiki/index.php/Server_4.0_and_4.1_issues.
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 617f6d70c077..a1d0d7a30165 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -589,8 +589,7 @@ struct address_space_operations {
        void (*invalidatepage) (struct page *, unsigned int, unsigned int);
        int (*releasepage) (struct page *, int);
        void (*freepage)(struct page *);
-        ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
+        ssize_t (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset);
-                        loff_t offset, unsigned long nr_segs);
        struct page* (*get_xip_page)(struct address_space *, sector_t,
                        int);
        /* migrate the contents of a page to the specified target */
@@ -807,6 +806,8 @@ struct file_operations {
        ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
        ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
        ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
+        ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
+        ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
        int (*iterate) (struct file *, struct dir_context *);
        unsigned int (*poll) (struct file *, struct poll_table_struct *);
        long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
@@ -837,11 +838,15 @@ otherwise noted.
  read: called by read(2) and related system calls
-  aio_read: called by io_submit(2) and other asynchronous I/O operations
+  aio_read: vectored, possibly asynchronous read
+  read_iter: possibly asynchronous read with iov_iter as destination
  write: called by write(2) and related system calls
-  aio_write: called by io_submit(2) and other asynchronous I/O operations
+  aio_write: vectored, possibly asynchronous write
+  write_iter: possibly asynchronous write with iov_iter as source
  iterate: called when the VFS needs to read the directory contents
diff --git a/Documentation/hwmon/shtc1 b/Documentation/hwmon/shtc1
new file mode 100644
index 000000000000..6b1e05458f0f
--- /dev/null
+++ b/Documentation/hwmon/shtc1
@@ -0,0 +1,43 @@
+Kernel driver shtc1
+===================
+Supported chips:
+  * Sensirion SHTC1
+    Prefix: 'shtc1'
+    Addresses scanned: none
+    Datasheet: http://www.sensirion.com/file/datasheet_shtc1
+  * Sensirion SHTW1
+    Prefix: 'shtw1'
+    Addresses scanned: none
+    Datasheet: Not publicly available
+Author:
+  Johannes Winkelmann <johannes.winkelmann@sensirion.com>
+Description
+-----------
+This driver implements support for the Sensirion SHTC1 chip, a humidity and
+temperature sensor. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. Driver can be used as well for SHTW1
+chip, which has the same electrical interface.
+The device communicates with the I2C protocol. All sensors are set to I2C
+address 0x70. See Documentation/i2c/instantiating-devices for methods to
+instantiate the device.
+There are two options configurable by means of shtc1_platform_data:
+1. blocking (pull the I2C clock line down while performing the measurement) or
+   non-blocking mode. Blocking mode will guarantee the fastest result but
+   the I2C bus will be busy during that time. By default, non-blocking mode
+   is used. Make sure clock-stretching works properly on your device if you
+   want to use blocking mode.
+2. high or low accuracy. High accuracy is used by default and using it is
+   strongly recommended.
+sysfs-Interface
+---------------
+temp1_input - temperature input
+humidity1_input - humidity input
diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index 69372fb98cf8..3fb39e0116b4 100644
--- a/Documentation/kbuild/modules.txt
+++ b/Documentation/kbuild/modules.txt
@@ -470,7 +470,7 @@ build.
        Sometimes, an external module uses exported symbols from
        another external module. kbuild needs to have full knowledge of
-        all symbols to avoid spliitting out warnings about undefined
+        all symbols to avoid spitting out warnings about undefined
        symbols. Three solutions exist for this situation.
        NOTE: The method with a top-level kbuild file is recommended
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index b9f67781c577..6eaa9cdb7094 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1,27 +1,37 @@
                          Kernel Parameters
                          ~~~~~~~~~~~~~~~~~
-The following is a consolidated list of the kernel parameters as implemented
+The following is a consolidated list of the kernel parameters as
-(mostly) by the __setup() macro and sorted into English Dictionary order
+implemented by the __setup(), core_param() and module_param() macros
-(defined as ignoring all punctuation and sorting digits before letters in a
+and sorted into English Dictionary order (defined as ignoring all
-case insensitive manner), and with descriptions where known.
+punctuation and sorting digits before letters in a case insensitive
+manner), and with descriptions where known.
-Module parameters for loadable modules are specified only as the
-parameter name with optional '=' and value as appropriate, such as:
+The kernel parses parameters from the kernel command line up to "--";
+if it doesn't recognize a parameter and it doesn't contain a '.', the
-        modprobe usbcore blinkenlights=1
+parameter gets passed to init: parameters with '=' go into init's
+environment, others are passed as command line arguments to init.
-Module parameters for modules that are built into the kernel image
+Everything after "--" is passed as an argument to init.
-are specified on the kernel command line with the module name plus
-'.' plus parameter name, with '=' and value if appropriate, such as:
+Module parameters can be specified in two ways: via the kernel command
+line with a module name prefix, or via modprobe, e.g.:
-        usbcore.blinkenlights=1
+        (kernel command line) usbcore.blinkenlights=1
+        (modprobe command line) modprobe usbcore blinkenlights=1
+Parameters for modules which are built into the kernel need to be
+specified on the kernel command line.  modprobe looks through the
+kernel command line (/proc/cmdline) and collects module parameters
+when it loads a module, so the kernel command line can be used for
+loadable modules too.
 Hyphens (dashes) and underscores are equivalent in parameter names, so
        log_buf_len=1M print-fatal-signals=1
 can also be entered as
        log-buf-len=1M print_fatal_signals=1
+Double-quotes can be used to protect spaces in values, e.g.:
+        param="spaces in here"
 This document may not be entirely up to date and comprehensive. The command
 "modinfo -p ${modulename}" shows a current list of all parameters of a loadable
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 0cfb00fd86ff..4bbeca8483ed 100644
--- a/Documentation/kprobes.txt
+++ b/Documentation/kprobes.txt
@@ -22,8 +22,9 @@ Appendix B: The kprobes sysctl interface
 Kprobes enables you to dynamically break into any kernel routine and
 collect debugging and performance information non-disruptively. You
-can trap at almost any kernel code address, specifying a handler
+can trap at almost any kernel code address(*), specifying a handler
 routine to be invoked when the breakpoint is hit.
+(*: some parts of the kernel code can not be trapped, see 1.5 Blacklist)
 There are currently three types of probes: kprobes, jprobes, and
 kretprobes (also called return probes).  A kprobe can be inserted
@@ -273,6 +274,19 @@ using one of the following techniques:
 or
 - Execute 'sysctl -w debug.kprobes_optimization=n'
+1.5 Blacklist
+Kprobes can probe most of the kernel except itself. This means
+that there are some functions where kprobes cannot probe. Probing
+(trapping) such functions can cause a recursive trap (e.g. double
+fault) or the nested probe handler may never be called.
+Kprobes manages such functions as a blacklist.
+If you want to add a function into the blacklist, you just need
+to (1) include linux/kprobes.h and (2) use NOKPROBE_SYMBOL() macro
+to specify a blacklisted function.
+Kprobes checks the given probe address against the blacklist and
+rejects registering it, if the given address is in the blacklist.
 2. Architectures Supported
 Kprobes, jprobes, and return probes are implemented on the following
diff --git a/Documentation/mtd/spi-nor.txt b/Documentation/mtd/spi-nor.txt
new file mode 100644
index 000000000000..548d6306ebca
--- /dev/null
+++ b/Documentation/mtd/spi-nor.txt
@@ -0,0 +1,62 @@
+                          SPI NOR framework
+               ============================================
+Part I - Why do we need this framework?
+---------------------------------------
+SPI bus controllers (drivers/spi/) only deal with streams of bytes; the bus
+controller operates agnostic of the specific device attached. However, some
+controllers (such as Freescale's QuadSPI controller) cannot easily handle
+arbitrary streams of bytes, but rather are designed specifically for SPI NOR.
+In particular, Freescale's QuadSPI controller must know the NOR commands to
+find the right LUT sequence. Unfortunately, the SPI subsystem has no notion of
+opcodes, addresses, or data payloads; a SPI controller simply knows to send or
+receive bytes (Tx and Rx). Therefore, we must define a new layering scheme under
+which the controller driver is aware of the opcodes, addressing, and other
+details of the SPI NOR protocol.
+Part II - How does the framework work?
+--------------------------------------
+This framework just adds a new layer between the MTD and the SPI bus driver.
+With this new layer, the SPI NOR controller driver does not depend on the
+m25p80 code anymore.
+   Before this framework, the layer is like:
+                   MTD
+         ------------------------
+                  m25p80
+         ------------------------
+               SPI bus driver
+         ------------------------
+                SPI NOR chip
+   After this framework, the layer is like:
+                   MTD
+         ------------------------
+              SPI NOR framework
+         ------------------------
+                  m25p80
+         ------------------------
+               SPI bus driver
+         ------------------------
+               SPI NOR chip
+  With the SPI NOR controller driver (Freescale QuadSPI), it looks like:
+                   MTD
+         ------------------------
+              SPI NOR framework
+         ------------------------
+                fsl-quadSPI
+         ------------------------
+               SPI NOR chip
+Part III - How can drivers use the framework?
+---------------------------------------------
+The main API is spi_nor_scan(). Before you call the hook, a driver should
+initialize the necessary fields for spi_nor{}. Please see
+drivers/mtd/spi-nor/spi-nor.c for detail. Please also refer to fsl-quadspi.c
+when you want to write a new driver for a SPI NOR controller.
diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt
index 1dfe62c3641d..ee231ed09ec6 100644
--- a/Documentation/mutex-design.txt
+++ b/Documentation/mutex-design.txt
@@ -1,139 +1,157 @@
 Generic Mutex Subsystem
 started by Ingo Molnar <mingo@redhat.com>
+updated by Davidlohr Bueso <davidlohr@hp.com>
-  "Why on earth do we need a new mutex subsystem, and what's wrong
+What are mutexes?
-   with semaphores?"
+-----------------
-firstly, there's nothing wrong with semaphores. But if the simpler
+In the Linux kernel, mutexes refer to a particular locking primitive
-mutex semantics are sufficient for your code, then there are a couple
+that enforces serialization on shared memory systems, and not only to
-of advantages of mutexes:
+the generic term referring to 'mutual exclusion' found in academia
+or similar theoretical text books. Mutexes are sleeping locks which
+behave similarly to binary semaphores, and were introduced in 2006[1]
+as an alternative to these. This new data structure provided a number
+of advantages, including simpler interfaces, and at that time smaller
+code (see Disadvantages).
- - 'struct mutex' is smaller on most architectures: E.g. on x86,
+[1] http://lwn.net/Articles/164802/
-   'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes.
-   A smaller structure size means less RAM footprint, and better
-   CPU-cache utilization.
- - tighter code. On x86 i get the following .text sizes when
+Implementation
-   switching all mutex-alike semaphores in the kernel to the mutex
+--------------
-   subsystem:
-        text    data     bss     dec     hex filename
+Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h
-     3280380  868188  396860 4545428  455b94 vmlinux-semaphore
+and implemented in kernel/locking/mutex.c. These locks use a three
-     3255329  865296  396732 4517357  44eded vmlinux-mutex
+state atomic counter (->count) to represent the different possible
+transitions that can occur during the lifetime of a lock:
-   that's 25051 bytes of code saved, or a 0.76% win - off the hottest
+          1: unlocked
-   codepaths of the kernel. (The .data savings are 2892 bytes, or 0.33%)
+          0: locked, no waiters
-   Smaller code means better icache footprint, which is one of the
+   negative: locked, with potential waiters
-   major optimization goals in the Linux kernel currently.
- - the mutex subsystem is slightly faster and has better scalability for
+In its most basic form it also includes a wait-queue and a spinlock
-   contended workloads. On an 8-way x86 system, running a mutex-based
+that serializes access to it. CONFIG_SMP systems can also include
-   kernel and testing creat+unlink+close (of separate, per-task files)
+a pointer to the lock task owner (->owner) as well as a spinner MCS
-   in /tmp with 16 parallel tasks, the average number of ops/sec is:
+lock (->osq), both described below in (ii).
-    Semaphores:                        Mutexes:
+When acquiring a mutex, there are three possible paths that can be
+taken, depending on the state of the lock:
-    $ ./test-mutex V 16 10             $ ./test-mutex V 16 10
+(i) fastpath: tries to atomically acquire the lock by decrementing the
-    8 CPUs, running 16 tasks.          8 CPUs, running 16 tasks.
+    counter. If it was already taken by another task it goes to the next
-    checking VFS performance.          checking VFS performance.
+    possible path. This logic is architecture specific. On x86-64, the
-    avg loops/sec:      34713          avg loops/sec:      84153
+    locking fastpath is 2 instructions:
-    CPU utilization:    63%            CPU utilization:    22%
-   i.e. in this workload, the mutex based kernel was 2.4 times faster
+    0000000000000e10 <mutex_lock>:
-   than the semaphore based kernel, _and_ it also had 2.8 times less CPU
+    e21:   f0 ff 0b                lock decl (%rbx)
-   utilization. (In terms of 'ops per CPU cycle', the semaphore kernel
+    e24:   79 08                   jns    e2e <mutex_lock+0x1e>
-   performed 551 ops/sec per 1% of CPU time used, while the mutex kernel
-   performed 3825 ops/sec per 1% of CPU time used - it was 6.9 times
-   more efficient.)
-   the scalability difference is visible even on a 2-way P4 HT box:
-    Semaphores:                        Mutexes:
-    $ ./test-mutex V 16 10             $ ./test-mutex V 16 10
-    4 CPUs, running 16 tasks.          8 CPUs, running 16 tasks.
-    checking VFS performance.          checking VFS performance.
-    avg loops/sec:      127659         avg loops/sec:      181082
-    CPU utilization:    100%           CPU utilization:    34%
-   (the straight performance advantage of mutexes is 41%, the per-cycle
-    efficiency of mutexes is 4.1 times better.)
- - there are no fastpath tradeoffs, the mutex fastpath is just as tight
-   as the semaphore fastpath. On x86, the locking fastpath is 2
-   instructions:
-    c0377ccb <mutex_lock>:
-    c0377ccb:       f0 ff 08                lock decl (%eax)
-    c0377cce:       78 0e                   js     c0377cde <.text..lock.mutex>
-    c0377cd0:       c3                      ret
   the unlocking fastpath is equally tight:
-    c0377cd1 <mutex_unlock>:
+    0000000000000bc0 <mutex_unlock>:
-    c0377cd1:       f0 ff 00                lock incl (%eax)
+    bc8:   f0 ff 07                lock incl (%rdi)
-    c0377cd4:       7e 0f                   jle    c0377ce5 <.text..lock.mutex+0x7>
+    bcb:   7f 0a                   jg     bd7 <mutex_unlock+0x17>
-    c0377cd6:       c3                      ret
- - 'struct mutex' semantics are well-defined and are enforced if
+(ii) midpath: aka optimistic spinning, tries to spin for acquisition
-   CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have
+     while the lock owner is running and there are no other tasks ready
-   virtually no debugging code or instrumentation. The mutex subsystem
+     to run that have higher priority (need_resched). The rationale is
-   checks and enforces the following rules:
+     that if the lock owner is running, it is likely to release the lock
+     soon. The mutex spinners are queued up using MCS lock so that only
-   * - only one task can hold the mutex at a time
+     one spinner can compete for the mutex.
-   * - only the owner can unlock the mutex
-   * - multiple unlocks are not permitted
+     The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spinlock
-   * - recursive locking is not permitted
+     with the desirable properties of being fair and with each cpu trying
-   * - a mutex object must be initialized via the API
+     to acquire the lock spinning on a local variable. It avoids expensive
-   * - a mutex object must not be initialized via memset or copying
+     cacheline bouncing that common test-and-set spinlock implementations
-   * - task may not exit with mutex held
+     incur. An MCS-like lock is specially tailored for optimistic spinning
-   * - memory areas where held locks reside must not be freed
+     for sleeping lock implementation. An important feature of the customized
-   * - held mutexes must not be reinitialized
+     MCS lock is that it has the extra property that spinners are able to exit
-   * - mutexes may not be used in hardware or software interrupt
+     the MCS spinlock queue when they need to reschedule. This further helps
-   *   contexts such as tasklets and timers
+     avoid situations where MCS spinners that need to reschedule would continue
+     waiting to spin on mutex owner, only to go directly to slowpath upon
-   furthermore, there are also convenience features in the debugging
+     obtaining the MCS lock.
-   code:
-   * - uses symbolic names of mutexes, whenever they are printed in debug output
+(iii) slowpath: last resort, if the lock is still unable to be acquired,
-   * - point-of-acquire tracking, symbolic lookup of function names
+      the task is added to the wait-queue and sleeps until woken up by the
-   * - list of all locks held in the system, printout of them
+      unlock path. Under normal circumstances it blocks as TASK_UNINTERRUPTIBLE.
-   * - owner tracking
-   * - detects self-recursing locks and prints out all relevant info
+While formally kernel mutexes are sleepable locks, it is path (ii) that
-   * - detects multi-task circular deadlocks and prints out all affected
+makes them more practically a hybrid type. By simply not interrupting a
-   *   locks and tasks (and only those tasks)
+task and busy-waiting for a few cycles instead of immediately sleeping,
+the performance of this lock has been seen to significantly improve a
+number of workloads. Note that this technique is also used for rw-semaphores.
+Semantics
+---------
+The mutex subsystem checks and enforces the following rules:
+    - Only one task can hold the mutex at a time.
+    - Only the owner can unlock the mutex.
+    - Multiple unlocks are not permitted.
+    - Recursive locking/unlocking is not permitted.
+    - A mutex must only be initialized via the API (see below).
+    - A task may not exit with a mutex held.
+    - Memory areas where held locks reside must not be freed.
+    - Held mutexes must not be reinitialized.
+    - Mutexes may not be used in hardware or software interrupt
+      contexts such as tasklets and timers.
+These semantics are fully enforced when CONFIG DEBUG_MUTEXES is enabled.
+In addition, the mutex debugging code also implements a number of other
+features that make lock debugging easier and faster:
+    - Uses symbolic names of mutexes, whenever they are printed
+      in debug output.
+    - Point-of-acquire tracking, symbolic lookup of function names,
+      list of all locks held in the system, printout of them.
+    - Owner tracking.
+    - Detects self-recursing locks and prints out all relevant info.
+    - Detects multi-task circular deadlocks and prints out all affected
+      locks and tasks (and only those tasks).
+Interfaces
+----------
+Statically define the mutex:
+   DEFINE_MUTEX(name);
+Dynamically initialize the mutex:
+   mutex_init(mutex);
+Acquire the mutex, uninterruptible:
+   void mutex_lock(struct mutex *lock);
+   void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
+   int  mutex_trylock(struct mutex *lock);
+Acquire the mutex, interruptible:
+   int mutex_lock_interruptible_nested(struct mutex *lock,
+                                       unsigned int subclass);
+   int mutex_lock_interruptible(struct mutex *lock);
+Acquire the mutex, interruptible, if dec to 0:
+   int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
+Unlock the mutex:
+   void mutex_unlock(struct mutex *lock);
+Test if the mutex is taken:
+   int mutex_is_locked(struct mutex *lock);
 Disadvantages
 -------------
-The stricter mutex API means you cannot use mutexes the same way you
+Unlike its original design and purpose, 'struct mutex' is larger than
-can use semaphores: e.g. they cannot be used from an interrupt context,
+most locks in the kernel. E.g: on x86-64 it is 40 bytes, almost twice
-nor can they be unlocked from a different context that which acquired
+as large as 'struct semaphore' (24 bytes) and 8 bytes shy of the
-it. [ I'm not aware of any other (e.g. performance) disadvantages from
+'struct rw_semaphore' variant. Larger structure sizes mean more CPU
-using mutexes at the moment, please let me know if you find any. ]
+cache and memory footprint.
-Implementation of mutexes
-------------------------
-'struct mutex' is the new mutex type, defined in include/linux/mutex.h and
-implemented in kernel/locking/mutex.c. It is a counter-based mutex with a
-spinlock and a wait-list. The counter has 3 states: 1 for "unlocked", 0 for
-"locked" and negative numbers (usually -1) for "locked, potential waiters
-queued".
-the APIs of 'struct mutex' have been streamlined:
- DEFINE_MUTEX(name);
- mutex_init(mutex);
+When to use mutexes
+-------------------
- void mutex_lock(struct mutex *lock);
+Unless the strict semantics of mutexes are unsuitable and/or the critical
- int  mutex_lock_interruptible(struct mutex *lock);
+region prevents the lock from being shared, always prefer them to any other
- int  mutex_trylock(struct mutex *lock);
+locking primitive.
- void mutex_unlock(struct mutex *lock);
- int  mutex_is_locked(struct mutex *lock);
- void mutex_lock_nested(struct mutex *lock, unsigned int subclass);
- int  mutex_lock_interruptible_nested(struct mutex *lock,
-                                      unsigned int subclass);
- int atomic_dec_and_mutex_lock(atomic_t *cnt, struct mutex *lock);
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index a383c00392d0..9c723ecd0025 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -585,13 +585,19 @@ mode
        balance-tlb or 5
                Adaptive transmit load balancing: channel bonding that
-                does not require any special switch support.  The
+                does not require any special switch support.
-                outgoing traffic is distributed according to the
-                current load (computed relative to the speed) on each
+                In tlb_dynamic_lb=1 mode; the outgoing traffic is
-                slave.  Incoming traffic is received by the current
+                distributed according to the current load (computed
-                slave.  If the receiving slave fails, another slave
+                relative to the speed) on each slave.
-                takes over the MAC address of the failed receiving
-                slave.
+                In tlb_dynamic_lb=0 mode; the load balancing based on
+                current load is disabled and the load is distributed
+                only using the hash distribution.
+                Incoming traffic is received by the current slave.
+                If the receiving slave fails, another slave takes over
+                the MAC address of the failed receiving slave.
                Prerequisite:
@@ -736,6 +742,28 @@ primary_reselect
        This option was added for bonding version 3.6.0.
+tlb_dynamic_lb
+        Specifies if dynamic shuffling of flows is enabled in tlb
+        mode. The value has no effect on any other modes.
+        The default behavior of tlb mode is to shuffle active flows across
+        slaves based on the load in that interval. This gives nice lb
+        characteristics but can cause packet reordering. If re-ordering is
+        a concern use this variable to disable flow shuffling and rely on
+        load balancing provided solely by the hash distribution.
+        xmit-hash-policy can be used to select the appropriate hashing for
+        the setup.
+        The sysfs entry can be used to change the setting per bond device
+        and the initial value is derived from the module parameter. The
+        sysfs entry is allowed to be changed only if the bond device is
+        down.
+        The default value is "1" that enables flow shuffling while value "0"
+        disables it. This option was added in bonding driver 3.7.1
 updelay
        Specifies the time, in milliseconds, to wait before enabling a
@@ -769,7 +797,7 @@ use_carrier
 xmit_hash_policy
        Selects the transmit hash policy to use for slave selection in
-        balance-xor and 802.3ad modes.  Possible values are:
+        balance-xor, 802.3ad, and tlb modes.  Possible values are:
        layer2
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 4f7ae5261364..2236d6dcb7da 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -469,6 +469,41 @@ solution for a couple of reasons:
  having this 'send only' use-case we may remove the receive list in the
  Kernel to save a little (really a very little!) CPU usage.
+  4.1.1.1 CAN filter usage optimisation
+  The CAN filters are processed in per-device filter lists at CAN frame
+  reception time. To reduce the number of checks that need to be performed
+  while walking through the filter lists the CAN core provides an optimized
+  filter handling when the filter subscription focusses on a single CAN ID.
+  For the possible 2048 SFF CAN identifiers the identifier is used as an index
+  to access the corresponding subscription list without any further checks.
+  For the 2^29 possible EFF CAN identifiers a 10 bit XOR folding is used as
+  hash function to retrieve the EFF table index.
+  To benefit from the optimized filters for single CAN identifiers the
+  CAN_SFF_MASK or CAN_EFF_MASK have to be set into can_filter.mask together
+  with set CAN_EFF_FLAG and CAN_RTR_FLAG bits. A set CAN_EFF_FLAG bit in the
+  can_filter.mask makes clear that it matters whether a SFF or EFF CAN ID is
+  subscribed. E.g. in the example from above
+    rfilter[0].can_id   = 0x123;
+    rfilter[0].can_mask = CAN_SFF_MASK;
+  both SFF frames with CAN ID 0x123 and EFF frames with 0xXXXXX123 can pass.
+  To filter for only 0x123 (SFF) and 0x12345678 (EFF) CAN identifiers the
+  filter has to be defined in this way to benefit from the optimized filters:
+    struct can_filter rfilter[2];
+    rfilter[0].can_id   = 0x123;
+    rfilter[0].can_mask = (CAN_EFF_FLAG | CAN_RTR_FLAG | CAN_SFF_MASK);
+    rfilter[1].can_id   = 0x12345678 | CAN_EFF_FLAG;
+    rfilter[1].can_mask = (CAN_EFF_FLAG | CAN_RTR_FLAG | CAN_EFF_MASK);
+    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, &rfilter, sizeof(rfilter));
  4.1.2 RAW socket option CAN_RAW_ERR_FILTER
  As described in chapter 3.4 the CAN interface driver can generate so
diff --git a/Documentation/networking/cdc_mbim.txt b/Documentation/networking/cdc_mbim.txt
new file mode 100644
index 000000000000..a15ea602aa52
--- /dev/null
+++ b/Documentation/networking/cdc_mbim.txt
@@ -0,0 +1,339 @@
+     cdc_mbim - Driver for CDC MBIM Mobile Broadband modems
+    ========================================================
+The cdc_mbim driver supports USB devices conforming to the "Universal
+Serial Bus Communications Class Subclass Specification for Mobile
+Broadband Interface Model" [1], which is a further development of
+"Universal Serial Bus Communications Class Subclass Specifications for
+Network Control Model Devices" [2] optimized for Mobile Broadband
+devices, aka "3G/LTE modems".
+Command Line Parameters
+=======================
+The cdc_mbim driver has no parameters of its own.  But the probing
+behaviour for NCM 1.0 backwards compatible MBIM functions (an
+"NCM/MBIM function" as defined in section 3.2 of [1]) is affected
+by a cdc_ncm driver parameter:
+prefer_mbim
+-----------
+Type:          Boolean
+Valid Range:   N/Y (0-1)
+Default Value: Y (MBIM is preferred)
+This parameter sets the system policy for NCM/MBIM functions.  Such
+functions will be handled by either the cdc_ncm driver or the cdc_mbim
+driver depending on the prefer_mbim setting.  Setting prefer_mbim=N
+makes the cdc_mbim driver ignore these functions and lets the cdc_ncm
+driver handle them instead.
+The parameter is writable, and can be changed at any time. A manual
+unbind/bind is required to make the change effective for NCM/MBIM
+functions bound to the "wrong" driver
+Basic usage
+===========
+MBIM functions are inactive when unmanaged. The cdc_mbim driver only
+provides an userspace interface to the MBIM control channel, and will
+not participate in the management of the function. This implies that a
+userspace MBIM management application always is required to enable a
+MBIM function.
+Such userspace applications includes, but are not limited to:
+ - mbimcli (included with the libmbim [3] library), and
+ - ModemManager [4]
+Establishing a MBIM IP session reequires at least these actions by the
+management application:
+ - open the control channel
+ - configure network connection settings
+ - connect to network
+ - configure IP interface
+Management application development
+----------------------------------
+The driver <-> userspace interfaces are described below.  The MBIM
+control channel protocol is described in [1].
+MBIM control channel userspace ABI
+==================================
+/dev/cdc-wdmX character device
+------------------------------
+The driver creates a two-way pipe to the MBIM function control channel
+using the cdc-wdm driver as a subdriver.  The userspace end of the
+control channel pipe is a /dev/cdc-wdmX character device.
+The cdc_mbim driver does not process or police messages on the control
+channel.  The channel is fully delegated to the userspace management
+application.  It is therefore up to this application to ensure that it
+complies with all the control channel requirements in [1].
+The cdc-wdmX device is created as a child of the MBIM control
+interface USB device.  The character device associated with a specific
+MBIM function can be looked up using sysfs.  For example:
+ bjorn@nemi:~$ ls /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc
+ cdc-wdm0
+ bjorn@nemi:~$ grep . /sys/bus/usb/drivers/cdc_mbim/2-4:2.12/usbmisc/cdc-wdm0/dev
+ 180:0
+USB configuration descriptors
+-----------------------------
+The wMaxControlMessage field of the CDC MBIM functional descriptor
+limits the maximum control message size. The managament application is
+responsible for negotiating a control message size complying with the
+requirements in section 9.3.1 of [1], taking this descriptor field
+into consideration.
+The userspace application can access the CDC MBIM functional
+descriptor of a MBIM function using either of the two USB
+configuration descriptor kernel interfaces described in [6] or [7].
+See also the ioctl documentation below.
+Fragmentation
+-------------
+The userspace application is responsible for all control message
+fragmentation and defragmentaion, as described in section 9.5 of [1].
+/dev/cdc-wdmX write()
+---------------------
+The MBIM control messages from the management application *must not*
+exceed the negotiated control message size.
+/dev/cdc-wdmX read()
+--------------------
+The management application *must* accept control messages of up the
+negotiated control message size.
+/dev/cdc-wdmX ioctl()
+--------------------
+IOCTL_WDM_MAX_COMMAND: Get Maximum Command Size
+This ioctl returns the wMaxControlMessage field of the CDC MBIM
+functional descriptor for MBIM devices.  This is intended as a
+convenience, eliminating the need to parse the USB descriptors from
+userspace.
+        #include <stdio.h>
+        #include <fcntl.h>
+        #include <sys/ioctl.h>
+        #include <linux/types.h>
+        #include <linux/usb/cdc-wdm.h>
+        int main()
+        {
+                __u16 max;
+                int fd = open("/dev/cdc-wdm0", O_RDWR);
+                if (!ioctl(fd, IOCTL_WDM_MAX_COMMAND, &max))
+                        printf("wMaxControlMessage is %d\n", max);
+        }
+Custom device services
+----------------------
+The MBIM specification allows vendors to freely define additional
+services.  This is fully supported by the cdc_mbim driver.
+Support for new MBIM services, including vendor specified services, is
+implemented entirely in userspace, like the rest of the MBIM control
+protocol
+New services should be registered in the MBIM Registry [5].
+MBIM data channel userspace ABI
+===============================
+wwanY network device
+--------------------
+The cdc_mbim driver represents the MBIM data channel as a single
+network device of the "wwan" type. This network device is initially
+mapped to MBIM IP session 0.
+Multiplexed IP sessions (IPS)
+-----------------------------
+MBIM allows multiplexing up to 256 IP sessions over a single USB data
+channel.  The cdc_mbim driver models such IP sessions as 802.1q VLAN
+subdevices of the master wwanY device, mapping MBIM IP session Z to
+VLAN ID Z for all values of Z greater than 0.
+The device maximum Z is given in the MBIM_DEVICE_CAPS_INFO structure
+described in section 10.5.1 of [1].
+The userspace management application is responsible for adding new
+VLAN links prior to establishing MBIM IP sessions where the SessionId
+is greater than 0. These links can be added by using the normal VLAN
+kernel interfaces, either ioctl or netlink.
+For example, adding a link for a MBIM IP session with SessionId 3:
+  ip link add link wwan0 name wwan0.3 type vlan id 3
+The driver will automatically map the "wwan0.3" network device to MBIM
+IP session 3.
+Device Service Streams (DSS)
+----------------------------
+MBIM also allows up to 256 non-IP data streams to be multiplexed over
+the same shared USB data channel.  The cdc_mbim driver models these
+sessions as another set of 802.1q VLAN subdevices of the master wwanY
+device, mapping MBIM DSS session A to VLAN ID (256 + A) for all values
+of A.
+The device maximum A is given in the MBIM_DEVICE_SERVICES_INFO
+structure described in section 10.5.29 of [1].
+The DSS VLAN subdevices are used as a practical interface between the
+shared MBIM data channel and a MBIM DSS aware userspace application.
+It is not intended to be presented as-is to an end user. The
+assumption is that an userspace application initiating a DSS session
+also takes care of the necessary framing of the DSS data, presenting
+the stream to the end user in an appropriate way for the stream type.
+The network device ABI requires a dummy ethernet header for every DSS
+data frame being transported.  The contents of this header is
+arbitrary, with the following exceptions:
+ - TX frames using an IP protocol (0x0800 or 0x86dd) will be dropped
+ - RX frames will have the protocol field set to ETH_P_802_3 (but will
+   not be properly formatted 802.3 frames)
+ - RX frames will have the destination address set to the hardware
+   address of the master device
+The DSS supporting userspace management application is responsible for
+adding the dummy ethernet header on TX and stripping it on RX.
+This is a simple example using tools commonly available, exporting
+DssSessionId 5 as a pty character device pointed to by a /dev/nmea
+symlink:
+  ip link add link wwan0 name wwan0.dss5 type vlan id 261
+  ip link set dev wwan0.dss5 up
+  socat INTERFACE:wwan0.dss5,type=2 PTY:,echo=0,link=/dev/nmea
+This is only an example, most suitable for testing out a DSS
+service. Userspace applications supporting specific MBIM DSS services
+are expected to use the tools and programming interfaces required by
+that service.
+Note that adding VLAN links for DSS sessions is entirely optional.  A
+management application may instead choose to bind a packet socket
+directly to the master network device, using the received VLAN tags to
+map frames to the correct DSS session and adding 18 byte VLAN ethernet
+headers with the appropriate tag on TX.  In this case using a socket
+filter is recommended, matching only the DSS VLAN subset. This avoid
+unnecessary copying of unrelated IP session data to userspace.  For
+example:
+  static struct sock_filter dssfilter[] = {
+        /* use special negative offsets to get VLAN tag */
+        BPF_STMT(BPF_LD|BPF_B|BPF_ABS, SKF_AD_OFF + SKF_AD_VLAN_TAG_PRESENT),
+        BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, 1, 0, 6), /* true */
+        /* verify DSS VLAN range */
+        BPF_STMT(BPF_LD|BPF_H|BPF_ABS, SKF_AD_OFF + SKF_AD_VLAN_TAG),
+        BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 256, 0, 4),     /* 256 is first DSS VLAN */
+        BPF_JUMP(BPF_JMP|BPF_JGE|BPF_K, 512, 3, 0),     /* 511 is last DSS VLAN */
+        /* verify ethertype */
+        BPF_STMT(BPF_LD|BPF_H|BPF_ABS, 2 * ETH_ALEN),
+        BPF_JUMP(BPF_JMP|BPF_JEQ|BPF_K, ETH_P_802_3, 0, 1),
+        BPF_STMT(BPF_RET|BPF_K, (u_int)-1),     /* accept */
+        BPF_STMT(BPF_RET|BPF_K, 0),             /* ignore */
+  };
+Tagged IP session 0 VLAN
+------------------------
+As described above, MBIM IP session 0 is treated as special by the
+driver.  It is initially mapped to untagged frames on the wwanY
+network device.
+This mapping implies a few restrictions on multiplexed IPS and DSS
+sessions, which may not always be practical:
+ - no IPS or DSS session can use a frame size greater than the MTU on
+   IP session 0
+ - no IPS or DSS session can be in the up state unless the network
+   device representing IP session 0 also is up
+These problems can be avoided by optionally making the driver map IP
+session 0 to a VLAN subdevice, similar to all other IP sessions.  This
+behaviour is triggered by adding a VLAN link for the magic VLAN ID
+4094.  The driver will then immediately start mapping MBIM IP session
+0 to this VLAN, and will drop untagged frames on the master wwanY
+device.
+Tip: It might be less confusing to the end user to name this VLAN
+subdevice after the MBIM SessionID instead of the VLAN ID.  For
+example:
+  ip link add link wwan0 name wwan0.0 type vlan id 4094
+VLAN mapping
+------------
+Summarizing the cdc_mbim driver mapping described above, we have this
+relationship between VLAN tags on the wwanY network device and MBIM
+sessions on the shared USB data channel:
+  VLAN ID       MBIM type   MBIM SessionID           Notes
+  ---------------------------------------------------------
+  untagged      IPS         0                        a)
+  1 - 255       IPS         1 - 255 <VLANID>
+  256 - 511     DSS         0 - 255 <VLANID - 256>
+  512 - 4093                                         b)
+  4094          IPS         0                        c)
+    a) if no VLAN ID 4094 link exists, else dropped
+    b) unsupported VLAN range, unconditionally dropped
+    c) if a VLAN ID 4094 link exists, else dropped
+References
+==========
+[1] USB Implementers Forum, Inc. - "Universal Serial Bus
+      Communications Class Subclass Specification for Mobile Broadband
+      Interface Model", Revision 1.0 (Errata 1), May 1, 2013
+      - http://www.usb.org/developers/docs/devclass_docs/
+[2] USB Implementers Forum, Inc. - "Universal Serial Bus
+      Communications Class Subclass Specifications for Network Control
+      Model Devices", Revision 1.0 (Errata 1), November 24, 2010
+      - http://www.usb.org/developers/docs/devclass_docs/
+[3] libmbim - "a glib-based library for talking to WWAN modems and
+      devices which speak the Mobile Interface Broadband Model (MBIM)
+      protocol"
+      - http://www.freedesktop.org/wiki/Software/libmbim/
+[4] ModemManager - "a DBus-activated daemon which controls mobile
+      broadband (2G/3G/4G) devices and connections"
+      - http://www.freedesktop.org/wiki/Software/ModemManager/
+[5] "MBIM (Mobile Broadband Interface Model) Registry"
+       - http://compliance.usb.org/mbim/
+[6] "/proc/bus/usb filesystem output"
+       - Documentation/usb/proc_usb_info.txt
+[7] "/sys/bus/usb/devices/.../descriptors"
+       - Documentation/ABI/stable/sysfs-bus-usb
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index e3ba753cb714..ee78eba78a9d 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -281,6 +281,7 @@ Possible BPF extensions are shown in the following table:
  cpu                                   raw_smp_processor_id()
  vlan_tci                              vlan_tx_tag_get(skb)
  vlan_pr                               vlan_tx_tag_present(skb)
+  rand                                  prandom_u32()
 These extensions can also be prefixed with '#'.
 Examples for low-level BPF:
@@ -308,6 +309,18 @@ Examples for low-level BPF:
  ret #-1
  drop: ret #0
+** icmp random packet sampling, 1 in 4
+  ldh [12]
+  jne #0x800, drop
+  ldb [23]
+  jneq #1, drop
+  # get a random uint32 number
+  ld rand
+  mod #4
+  jneq #1, drop
+  ret #-1
+  drop: ret #0
 ** SECCOMP filter example:
  ld [4]                  /* offsetof(struct seccomp_data, arch) */
@@ -548,42 +561,43 @@ toolchain for developing and testing the kernel's JIT compiler.
 BPF kernel internals
 --------------------
-Internally, for the kernel interpreter, a different BPF instruction set
+Internally, for the kernel interpreter, a different instruction set
 format with similar underlying principles from BPF described in previous
 paragraphs is being used. However, the instruction set format is modelled
 closer to the underlying architecture to mimic native instruction sets, so
-that a better performance can be achieved (more details later).
+that a better performance can be achieved (more details later). This new
+ISA is called 'eBPF' or 'internal BPF' interchangeably. (Note: eBPF which
+originates from [e]xtended BPF is not the same as BPF extensions! While
+eBPF is an ISA, BPF extensions date back to classic BPF's 'overloading'
+of BPF_LD | BPF_{B,H,W} | BPF_ABS instruction.)
 It is designed to be JITed with one to one mapping, which can also open up
-the possibility for GCC/LLVM compilers to generate optimized BPF code through
+the possibility for GCC/LLVM compilers to generate optimized eBPF code through
-a BPF backend that performs almost as fast as natively compiled code.
+an eBPF backend that performs almost as fast as natively compiled code.
 The new instruction set was originally designed with the possible goal in
-mind to write programs in "restricted C" and compile into BPF with a optional
+mind to write programs in "restricted C" and compile into eBPF with a optional
 GCC/LLVM backend, so that it can just-in-time map to modern 64-bit CPUs with
-minimal performance overhead over two steps, that is, C -> BPF -> native code.
+minimal performance overhead over two steps, that is, C -> eBPF -> native code.
 Currently, the new format is being used for running user BPF programs, which
 includes seccomp BPF, classic socket filters, cls_bpf traffic classifier,
 team driver's classifier for its load-balancing mode, netfilter's xt_bpf
 extension, PTP dissector/classifier, and much more. They are all internally
 converted by the kernel into the new instruction set representation and run
-in the extended interpreter. For in-kernel handlers, this all works
+in the eBPF interpreter. For in-kernel handlers, this all works transparently
-transparently by using sk_unattached_filter_create() for setting up the
+by using sk_unattached_filter_create() for setting up the filter, resp.
-filter, resp. sk_unattached_filter_destroy() for destroying it. The macro
+sk_unattached_filter_destroy() for destroying it. The macro
-SK_RUN_FILTER(filter, ctx) transparently invokes the right BPF function to
+SK_RUN_FILTER(filter, ctx) transparently invokes eBPF interpreter or JITed
-run the filter. 'filter' is a pointer to struct sk_filter that we got from
+code to run the filter. 'filter' is a pointer to struct sk_filter that we
-sk_unattached_filter_create(), and 'ctx' the given context (e.g. skb pointer).
+got from sk_unattached_filter_create(), and 'ctx' the given context (e.g.
-All constraints and restrictions from sk_chk_filter() apply before a
+skb pointer). All constraints and restrictions from sk_chk_filter() apply
-conversion to the new layout is being done behind the scenes!
+before a conversion to the new layout is being done behind the scenes!
-Currently, for JITing, the user BPF format is being used and current BPF JIT
+Currently, the classic BPF format is being used for JITing on most of the
-compilers reused whenever possible. In other words, we do not (yet!) perform
+architectures. Only x86-64 performs JIT compilation from eBPF instruction set,
-a JIT compilation in the new layout, however, future work will successively
+however, future work will migrate other JIT compilers as well, so that they
-migrate traditional JIT compilers into the new instruction format as well, so
+will profit from the very same benefits.
-that they will profit from the very same benefits. Thus, when speaking about
-JIT in the following, a JIT compiler (TBD) for the new instruction format is
-meant in this context.
 Some core changes of the new internal format:
@@ -592,35 +606,35 @@ Some core changes of the new internal format:
  The old format had two registers A and X, and a hidden frame pointer. The
  new layout extends this to be 10 internal registers and a read-only frame
  pointer. Since 64-bit CPUs are passing arguments to functions via registers
-  the number of args from BPF program to in-kernel function is restricted
+  the number of args from eBPF program to in-kernel function is restricted
  to 5 and one register is used to accept return value from an in-kernel
  function. Natively, x86_64 passes first 6 arguments in registers, aarch64/
  sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved
  registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers.
-  Therefore, BPF calling convention is defined as:
+  Therefore, eBPF calling convention is defined as:
-    * R0        - return value from in-kernel function
+    * R0        - return value from in-kernel function, and exit value for eBPF program
-    * R1 - R5   - arguments from BPF program to in-kernel function
+    * R1 - R5   - arguments from eBPF program to in-kernel function
    * R6 - R9   - callee saved registers that in-kernel function will preserve
    * R10       - read-only frame pointer to access stack
-  Thus, all BPF registers map one to one to HW registers on x86_64, aarch64,
+  Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64,
-  etc, and BPF calling convention maps directly to ABIs used by the kernel on
+  etc, and eBPF calling convention maps directly to ABIs used by the kernel on
  64-bit architectures.
  On 32-bit architectures JIT may map programs that use only 32-bit arithmetic
  and may let more complex programs to be interpreted.
-  R0 - R5 are scratch registers and BPF program needs spill/fill them if
+  R0 - R5 are scratch registers and eBPF program needs spill/fill them if
-  necessary across calls. Note that there is only one BPF program (== one BPF
+  necessary across calls. Note that there is only one eBPF program (== one
-  main routine) and it cannot call other BPF functions, it can only call
+  eBPF main routine) and it cannot call other eBPF functions, it can only
-  predefined in-kernel functions, though.
+  call predefined in-kernel functions, though.
 - Register width increases from 32-bit to 64-bit:
  Still, the semantics of the original 32-bit ALU operations are preserved
-  via 32-bit subregisters. All BPF registers are 64-bit with 32-bit lower
+  via 32-bit subregisters. All eBPF registers are 64-bit with 32-bit lower
  subregisters that zero-extend into 64-bit if they are being written to.
  That behavior maps directly to x86_64 and arm64 subregister definition, but
  makes other JITs more difficult.
@@ -631,8 +645,8 @@ Some core changes of the new internal format:
  Operation is 64-bit, because on 64-bit architectures, pointers are also
  64-bit wide, and we want to pass 64-bit values in/out of kernel functions,
-  so 32-bit BPF registers would otherwise require to define register-pair
+  so 32-bit eBPF registers would otherwise require to define register-pair
-  ABI, thus, there won't be able to use a direct BPF register to HW register
+  ABI, thus, there won't be able to use a direct eBPF register to HW register
  mapping and JIT would need to do combine/split/move operations for every
  register in and out of the function, which is complex, bug prone and slow.
  Another reason is the use of atomic 64-bit counters.
@@ -646,14 +660,145 @@ Some core changes of the new internal format:
 - Introduces bpf_call insn and register passing convention for zero overhead
  calls from/to other kernel functions:
-  After a kernel function call, R1 - R5 are reset to unreadable and R0 has a
+  Before an in-kernel function call, the internal BPF program needs to
-  return type of the function. Since R6 - R9 are callee saved, their state is
+  place function arguments into R1 to R5 registers to satisfy calling
-  preserved across the call.
+  convention, then the interpreter will take them from registers and pass
+  to in-kernel function. If R1 - R5 registers are mapped to CPU registers
-Also in the new design, BPF is limited to 4096 insns, which means that any
+  that are used for argument passing on given architecture, the JIT compiler
+  doesn't need to emit extra moves. Function arguments will be in the correct
+  registers and BPF_CALL instruction will be JITed as single 'call' HW
+  instruction. This calling convention was picked to cover common call
+  situations without performance penalty.
+  After an in-kernel function call, R1 - R5 are reset to unreadable and R0 has
+  a return value of the function. Since R6 - R9 are callee saved, their state
+  is preserved across the call.
+  For example, consider three C functions:
+  u64 f1() { return (*_f2)(1); }
+  u64 f2(u64 a) { return f3(a + 1, a); }
+  u64 f3(u64 a, u64 b) { return a - b; }
+  GCC can compile f1, f3 into x86_64:
+  f1:
+    movl $1, %edi
+    movq _f2(%rip), %rax
+    jmp  *%rax
+  f3:
+    movq %rdi, %rax
+    subq %rsi, %rax
+    ret
+  Function f2 in eBPF may look like:
+  f2:
+    bpf_mov R2, R1
+    bpf_add R1, 1
+    bpf_call f3
+    bpf_exit
+  If f2 is JITed and the pointer stored to '_f2'. The calls f1 -> f2 -> f3 and
+  returns will be seamless. Without JIT, __sk_run_filter() interpreter needs to
+  be used to call into f2.
+  For practical reasons all eBPF programs have only one argument 'ctx' which is
+  already placed into R1 (e.g. on __sk_run_filter() startup) and the programs
+  can call kernel functions with up to 5 arguments. Calls with 6 or more arguments
+  are currently not supported, but these restrictions can be lifted if necessary
+  in the future.
+  On 64-bit architectures all register map to HW registers one to one. For
+  example, x86_64 JIT compiler can map them as ...
+    R0 - rax
+    R1 - rdi
+    R2 - rsi
+    R3 - rdx
+    R4 - rcx
+    R5 - r8
+    R6 - rbx
+    R7 - r13
+    R8 - r14
+    R9 - r15
+    R10 - rbp
+  ... since x86_64 ABI mandates rdi, rsi, rdx, rcx, r8, r9 for argument passing
+  and rbx, r12 - r15 are callee saved.
+  Then the following internal BPF pseudo-program:
+    bpf_mov R6, R1 /* save ctx */
+    bpf_mov R2, 2
+    bpf_mov R3, 3
+    bpf_mov R4, 4
+    bpf_mov R5, 5
+    bpf_call foo
+    bpf_mov R7, R0 /* save foo() return value */
+    bpf_mov R1, R6 /* restore ctx for next call */
+    bpf_mov R2, 6
+    bpf_mov R3, 7
+    bpf_mov R4, 8
+    bpf_mov R5, 9
+    bpf_call bar
+    bpf_add R0, R7
+    bpf_exit
+  After JIT to x86_64 may look like:
+    push %rbp
+    mov %rsp,%rbp
+    sub $0x228,%rsp
+    mov %rbx,-0x228(%rbp)
+    mov %r13,-0x220(%rbp)
+    mov %rdi,%rbx
+    mov $0x2,%esi
+    mov $0x3,%edx
+    mov $0x4,%ecx
+    mov $0x5,%r8d
+    callq foo
+    mov %rax,%r13
+    mov %rbx,%rdi
+    mov $0x2,%esi
+    mov $0x3,%edx
+    mov $0x4,%ecx
+    mov $0x5,%r8d
+    callq bar
+    add %r13,%rax
+    mov -0x228(%rbp),%rbx
+    mov -0x220(%rbp),%r13
+    leaveq
+    retq
+  Which is in this example equivalent in C to:
+    u64 bpf_filter(u64 ctx)
+    {
+        return foo(ctx, 2, 3, 4, 5) + bar(ctx, 6, 7, 8, 9);
+    }
+  In-kernel functions foo() and bar() with prototype: u64 (*)(u64 arg1, u64
+  arg2, u64 arg3, u64 arg4, u64 arg5); will receive arguments in proper
+  registers and place their return value into '%rax' which is R0 in eBPF.
+  Prologue and epilogue are emitted by JIT and are implicit in the
+  interpreter. R0-R5 are scratch registers, so eBPF program needs to preserve
+  them across the calls as defined by calling convention.
+  For example the following program is invalid:
+    bpf_mov R1, 1
+    bpf_call foo
+    bpf_mov R0, R1
+    bpf_exit
+  After the call the registers R1-R5 contain junk values and cannot be read.
+  In the future an eBPF verifier can be used to validate internal BPF programs.
+Also in the new design, eBPF is limited to 4096 insns, which means that any
 program will terminate quickly and will only call a fixed number of kernel
 functions. Original BPF and the new format are two operand instructions,
-which helps to do one-to-one mapping between BPF insn and x86 insn during JIT.
+which helps to do one-to-one mapping between eBPF insn and x86 insn during JIT.
 The input context pointer for invoking the interpreter function is generic,
 its content is defined by a specific use case. For seccomp register R1 points
@@ -661,7 +806,26 @@ to seccomp_data, for converted BPF filters R1 points to a skb.
 A program, that is translated internally consists of the following elements:
-  op:16, jt:8, jf:8, k:32    ==>    op:8, a_reg:4, x_reg:4, off:16, imm:32
+  op:16, jt:8, jf:8, k:32    ==>    op:8, dst_reg:4, src_reg:4, off:16, imm:32
+So far 87 internal BPF instructions were implemented. 8-bit 'op' opcode field
+has room for new instructions. Some of them may use 16/24/32 byte encoding. New
+instructions must be multiple of 8 bytes to preserve backward compatibility.
+Internal BPF is a general purpose RISC instruction set. Not every register and
+every instruction are used during translation from original BPF to new format.
+For example, socket filters are not using 'exclusive add' instruction, but
+tracing filters may do to maintain counters of events, for example. Register R9
+is not used by socket filters either, but more complex filters may be running
+out of registers and would have to resort to spill/fill to stack.
+Internal BPF can used as generic assembler for last step performance
+optimizations, socket filters and seccomp are using it as assembler. Tracing
+filters may use it as assembler to generate code from kernel. In kernel usage
+may not be bounded by security considerations, since generated internal BPF code
+may be optimizing internal code path and not being exposed to the user space.
+Safety of internal BPF can come from a verifier (TBD). In such use cases as
+described, it may be used as safe instruction set.
 Just like the original BPF, the new format runs within a controlled environment,
 is deterministic and the kernel can easily prove that. The safety of the program
@@ -670,6 +834,181 @@ loops and other CFG validation; second step starts from the first insn and
 descends all possible paths. It simulates execution of every insn and observes
 the state change of registers and stack.
+eBPF opcode encoding
+--------------------
+eBPF is reusing most of the opcode encoding from classic to simplify conversion
+of classic BPF to eBPF. For arithmetic and jump instructions the 8-bit 'code'
+field is divided into three parts:
+  +----------------+--------+--------------------+
+  |   4 bits       |  1 bit |   3 bits           |
+  | operation code | source | instruction class  |
+  +----------------+--------+--------------------+
+  (MSB)                                      (LSB)
+Three LSB bits store instruction class which is one of:
+  Classic BPF classes:    eBPF classes:
+  BPF_LD    0x00          BPF_LD    0x00
+  BPF_LDX   0x01          BPF_LDX   0x01
+  BPF_ST    0x02          BPF_ST    0x02
+  BPF_STX   0x03          BPF_STX   0x03
+  BPF_ALU   0x04          BPF_ALU   0x04
+  BPF_JMP   0x05          BPF_JMP   0x05
+  BPF_RET   0x06          [ class 6 unused, for future if needed ]
+  BPF_MISC  0x07          BPF_ALU64 0x07
+When BPF_CLASS(code) == BPF_ALU or BPF_JMP, 4th bit encodes source operand ...
+  BPF_K     0x00
+  BPF_X     0x08
+ * in classic BPF, this means:
+  BPF_SRC(code) == BPF_X - use register X as source operand
+  BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand
+ * in eBPF, this means:
+  BPF_SRC(code) == BPF_X - use 'src_reg' register as source operand
+  BPF_SRC(code) == BPF_K - use 32-bit immediate as source operand
+... and four MSB bits store operation code.
+If BPF_CLASS(code) == BPF_ALU or BPF_ALU64 [ in eBPF ], BPF_OP(code) is one of:
+  BPF_ADD   0x00
+  BPF_SUB   0x10
+  BPF_MUL   0x20
+  BPF_DIV   0x30
+  BPF_OR    0x40
+  BPF_AND   0x50
+  BPF_LSH   0x60
+  BPF_RSH   0x70
+  BPF_NEG   0x80
+  BPF_MOD   0x90
+  BPF_XOR   0xa0
+  BPF_MOV   0xb0  /* eBPF only: mov reg to reg */
+  BPF_ARSH  0xc0  /* eBPF only: sign extending shift right */
+  BPF_END   0xd0  /* eBPF only: endianness conversion */
+If BPF_CLASS(code) == BPF_JMP, BPF_OP(code) is one of:
+  BPF_JA    0x00
+  BPF_JEQ   0x10
+  BPF_JGT   0x20
+  BPF_JGE   0x30
+  BPF_JSET  0x40
+  BPF_JNE   0x50  /* eBPF only: jump != */
+  BPF_JSGT  0x60  /* eBPF only: signed '>' */
+  BPF_JSGE  0x70  /* eBPF only: signed '>=' */
+  BPF_CALL  0x80  /* eBPF only: function call */
+  BPF_EXIT  0x90  /* eBPF only: function return */
+So BPF_ADD | BPF_X | BPF_ALU means 32-bit addition in both classic BPF
+and eBPF. There are only two registers in classic BPF, so it means A += X.
+In eBPF it means dst_reg = (u32) dst_reg + (u32) src_reg; similarly,
+BPF_XOR | BPF_K | BPF_ALU means A ^= imm32 in classic BPF and analogous
+src_reg = (u32) src_reg ^ (u32) imm32 in eBPF.
+Classic BPF is using BPF_MISC class to represent A = X and X = A moves.
+eBPF is using BPF_MOV | BPF_X | BPF_ALU code instead. Since there are no
+BPF_MISC operations in eBPF, the class 7 is used as BPF_ALU64 to mean
+exactly the same operations as BPF_ALU, but with 64-bit wide operands
+instead. So BPF_ADD | BPF_X | BPF_ALU64 means 64-bit addition, i.e.:
+dst_reg = dst_reg + src_reg
+Classic BPF wastes the whole BPF_RET class to represent a single 'ret'
+operation. Classic BPF_RET | BPF_K means copy imm32 into return register
+and perform function exit. eBPF is modeled to match CPU, so BPF_JMP | BPF_EXIT
+in eBPF means function exit only. The eBPF program needs to store return
+value into register R0 before doing a BPF_EXIT. Class 6 in eBPF is currently
+unused and reserved for future use.
+For load and store instructions the 8-bit 'code' field is divided as:
+  +--------+--------+-------------------+
+  | 3 bits | 2 bits |   3 bits          |
+  |  mode  |  size  | instruction class |
+  +--------+--------+-------------------+
+  (MSB)                             (LSB)
+Size modifier is one of ...
+  BPF_W   0x00    /* word */
+  BPF_H   0x08    /* half word */
+  BPF_B   0x10    /* byte */
+  BPF_DW  0x18    /* eBPF only, double word */
+... which encodes size of load/store operation:
+ B  - 1 byte
+ H  - 2 byte
+ W  - 4 byte
+ DW - 8 byte (eBPF only)
+Mode modifier is one of:
+  BPF_IMM  0x00  /* classic BPF only, reserved in eBPF */
+  BPF_ABS  0x20
+  BPF_IND  0x40
+  BPF_MEM  0x60
+  BPF_LEN  0x80  /* classic BPF only, reserved in eBPF */
+  BPF_MSH  0xa0  /* classic BPF only, reserved in eBPF */
+  BPF_XADD 0xc0  /* eBPF only, exclusive add */
+eBPF has two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and
+(BPF_IND | <size> | BPF_LD) which are used to access packet data.
+They had to be carried over from classic to have strong performance of
+socket filters running in eBPF interpreter. These instructions can only
+be used when interpreter context is a pointer to 'struct sk_buff' and
+have seven implicit operands. Register R6 is an implicit input that must
+contain pointer to sk_buff. Register R0 is an implicit output which contains
+the data fetched from the packet. Registers R1-R5 are scratch registers
+and must not be used to store the data across BPF_ABS | BPF_LD or
+BPF_IND | BPF_LD instructions.
+These instructions have implicit program exit condition as well. When
+eBPF program is trying to access the data beyond the packet boundary,
+the interpreter will abort the execution of the program. JIT compilers
+therefore must preserve this property. src_reg and imm32 fields are
+explicit inputs to these instructions.
+For example:
+  BPF_IND | BPF_W | BPF_LD means:
+    R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32))
+    and R1 - R5 were scratched.
+Unlike classic BPF instruction set, eBPF has generic load/store operations:
+BPF_MEM | <size> | BPF_STX:  *(size *) (dst_reg + off) = src_reg
+BPF_MEM | <size> | BPF_ST:   *(size *) (dst_reg + off) = imm32
+BPF_MEM | <size> | BPF_LDX:  dst_reg = *(size *) (src_reg + off)
+BPF_XADD | BPF_W  | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg
+BPF_XADD | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg
+Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. Note that 1 and
+2 byte atomic increments are not supported.
+Testing
+-------
+Next to the BPF toolchain, the kernel also ships a test module that contains
+various test cases for classic and internal BPF that can be executed against
+the BPF interpreter and JIT compiler. It can be found in lib/test_bpf.c and
+enabled via Kconfig:
+  CONFIG_TEST_BPF=m
+After the module has been built and installed, the test suite can be executed
+via insmod or modprobe against 'test_bpf' module. Results of the test cases
+including timings in nsec can be found in the kernel log (dmesg).
 Misc
 ----
diff --git a/Documentation/platform/x86-laptop-drivers.txt b/Documentation/platform/x86-laptop-drivers.txt
new file mode 100644
index 000000000000..01facd2590bb
--- /dev/null
+++ b/Documentation/platform/x86-laptop-drivers.txt
@@ -0,0 +1,18 @@
+compal-laptop
+=============
+List of supported hardware:
+by Compal:
+        Compal FL90/IFL90
+        Compal FL91/IFL91
+        Compal FL92/JFL92
+        Compal FT00/IFT00
+by Dell:
+        Dell Vostro 1200
+        Dell Mini 9 (Inspiron 910)
+        Dell Mini 10 (Inspiron 1010)
+        Dell Mini 10v (Inspiron 1011)
+        Dell Mini 1012 (Inspiron 1012)
+        Dell Inspiron 11z (Inspiron 1110)
+        Dell Mini 12 (Inspiron 1210)
diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt
index e13dafc8e8f1..2850df3bf957 100644
--- a/Documentation/power/suspend-and-cpuhotplug.txt
+++ b/Documentation/power/suspend-and-cpuhotplug.txt
@@ -1,6 +1,6 @@
 Interaction of Suspend code (S3) with the CPU hotplug infrastructure
-     (C) 2011 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
+     (C) 2011 - 2014 Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
 I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM
diff --git a/Documentation/powerpc/cpu_families.txt b/Documentation/powerpc/cpu_families.txt
new file mode 100644
index 000000000000..fc08e22feb1a
--- /dev/null
+++ b/Documentation/powerpc/cpu_families.txt
@@ -0,0 +1,221 @@
+CPU Families
+============
+This document tries to summarise some of the different cpu families that exist
+and are supported by arch/powerpc.
+Book3S (aka sPAPR)
+------------------
+ - Hash MMU
+ - Mix of 32 & 64 bit
+   +--------------+                 +----------------+
+   |  Old POWER   | --------------> | RS64 (threads) |
+   +--------------+                 +----------------+
+          |
+          |
+          v
+   +--------------+                 +----------------+      +------+
+   |     601      | --------------> |      603       | ---> | e300 |
+   +--------------+                 +----------------+      +------+
+          |                                 |
+          |                                 |
+          v                                 v
+   +--------------+                 +----------------+      +-------+
+   |     604      |                 |    750 (G3)    | ---> | 750CX |
+   +--------------+                 +----------------+      +-------+
+          |                                 |                   |
+          |                                 |                   |
+          v                                 v                   v
+   +--------------+                 +----------------+      +-------+
+   | 620 (64 bit) |                 |      7400      |      | 750CL |
+   +--------------+                 +----------------+      +-------+
+          |                                 |                   |
+          |                                 |                   |
+          v                                 v                   v
+   +--------------+                 +----------------+      +-------+
+   |  POWER3/630  |                 |      7410      |      | 750FX |
+   +--------------+                 +----------------+      +-------+
+          |                                 |
+          |                                 |
+          v                                 v
+   +--------------+                 +----------------+
+   |   POWER3+    |                 |      7450      |
+   +--------------+                 +----------------+
+          |                                 |
+          |                                 |
+          v                                 v
+   +--------------+                 +----------------+
+   |    POWER4    |                 |      7455      |
+   +--------------+                 +----------------+
+          |                                 |
+          |                                 |
+          v                                 v
+   +--------------+     +-------+   +----------------+
+   |   POWER4+    | --> |  970  |   |      7447      |
+   +--------------+     +-------+   +----------------+
+          |                 |               |
+          |                 |               |
+          v                 v               v
+   +--------------+     +-------+   +----------------+
+   |    POWER5    |     | 970FX |   |      7448      |
+   +--------------+     +-------+   +----------------+
+          |                 |               |
+          |                 |               |
+          v                 v               v
+   +--------------+     +-------+   +----------------+
+   |   POWER5+    |     | 970MP |   |      e600      |
+   +--------------+     +-------+   +----------------+
+          |
+          |
+          v
+   +--------------+
+   |   POWER5++   |
+   +--------------+
+          |
+          |
+          v
+   +--------------+       +-------+
+   |    POWER6    | <-?-> | Cell  |
+   +--------------+       +-------+
+          |
+          |
+          v
+   +--------------+
+   |    POWER7    |
+   +--------------+
+          |
+          |
+          v
+   +--------------+
+   |   POWER7+    |
+   +--------------+
+          |
+          |
+          v
+   +--------------+
+   |    POWER8    |
+   +--------------+
+   +---------------+
+   | PA6T (64 bit) |
+   +---------------+
+IBM BookE
+---------
+ - Software loaded TLB.
+ - All 32 bit
+   +--------------+
+   |     401      |
+   +--------------+
+          |
+          |
+          v
+   +--------------+
+   |     403      |
+   +--------------+
+          |
+          |
+          v
+   +--------------+
+   |     405      |
+   +--------------+
+          |
+          |
+          v
+   +--------------+
+   |     440      |
+   +--------------+
+          |
+          |
+          v
+   +--------------+     +----------------+
+   |     450      | --> |      BG/P      |
+   +--------------+     +----------------+
+          |
+          |
+          v
+   +--------------+
+   |     460      |
+   +--------------+
+          |
+          |
+          v
+   +--------------+
+   |     476      |
+   +--------------+
+Motorola/Freescale 8xx
+----------------------
+ - Software loaded with hardware assist.
+ - All 32 bit
+   +-------------+
+   | MPC8xx Core |
+   +-------------+
+Freescale BookE
+---------------
+ - Software loaded TLB.
+ - e6500 adds HW loaded indirect TLB entries.
+ - Mix of 32 & 64 bit
+   +--------------+
+   |     e200     |
+   +--------------+
+   +--------------------------------+
+   |              e500              |
+   +--------------------------------+
+                   |
+                   |
+                   v
+   +--------------------------------+
+   |             e500v2             |
+   +--------------------------------+
+                   |
+                   |
+                   v
+   +--------------------------------+
+   |        e500mc (Book3e)         |
+   +--------------------------------+
+                   |
+                   |
+                   v
+   +--------------------------------+
+   |          e5500 (64 bit)        |
+   +--------------------------------+
+                   |
+                   |
+                   v
+   +--------------------------------+
+   | e6500 (HW TLB) (Multithreaded) |
+   +--------------------------------+
+IBM A2 core
+-----------
+ - Book3E, software loaded TLB + HW loaded indirect TLB entries.
+ - 64 bit
+   +--------------+     +----------------+
+   |   A2 core    | --> |      WSP       |
+   +--------------+     +----------------+
+           |
+           |
+           v
+   +--------------+
+   |     BG/Q     |
+   +--------------+
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 93cb97974986..ca895fd211e4 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -19,7 +19,8 @@ should instead register a static mapping that can be used to match PWM
 consumers to providers, as given in the following example:
        static struct pwm_lookup board_pwm_lookup[] = {
-                PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL),
+                PWM_LOOKUP("tegra-pwm", 0, "pwm-backlight", NULL,
+                           50000, PWM_POLARITY_NORMAL),
        };
        static void __init board_init(void)
@@ -97,6 +98,13 @@ pwm_chip as argument which provides a description of the PWM chip, the
 number of PWM devices provided by the chip and the chip-specific
 implementation of the supported PWM operations to the framework.
+When implementing polarity support in a PWM driver, make sure to respect the
+signal conventions in the PWM framework. By definition, normal polarity
+characterizes a signal starts high for the duration of the duty cycle and
+goes low for the remainder of the period. Conversely, a signal with inversed
+polarity starts low for the duration of the duty cycle and goes high for the
+remainder of the period.
 Locking
 -------
diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx
index 5020b7b5a244..52f0b4359234 100644
--- a/Documentation/scsi/LICENSE.qla2xxx
+++ b/Documentation/scsi/LICENSE.qla2xxx
@@ -1,4 +1,4 @@
-Copyright (c) 2003-2013 QLogic Corporation
+Copyright (c) 2003-2014 QLogic Corporation
 QLogic Linux FC-FCoE Driver
 This program includes a device driver for Linux 3.x.
diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index 5ea996f21d6c..b6ef7e9dba30 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -204,6 +204,16 @@ onlycap
        these capabilities are effective at for processes with any
        label. The value is set by writing the desired label to the
        file or cleared by writing "-" to the file.
+ptrace
+        This is used to define the current ptrace policy
+        0 - default: this is the policy that relies on smack access rules.
+            For the PTRACE_READ a subject needs to have a read access on
+            object. For the PTRACE_ATTACH a read-write access is required.
+        1 - exact: this is the policy that limits PTRACE_ATTACH. Attach is
+            only allowed when subject's and object's labels are equal.
+            PTRACE_READ is not affected. Can be overriden with CAP_SYS_PTRACE.
+        2 - draconian: this policy behaves like the 'exact' above with an
+            exception that it can't be overriden with CAP_SYS_PTRACE.
 revoke-subject
        Writing a Smack label here sets the access to '-' for all access
        rules with that subject label.
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index bd365988e8d8..2479b2a0c77c 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -2003,6 +2003,32 @@ want, depending on your needs.
  360.774530 |   1)   0.594 us    |                                          __phys_addr();
+The function name is always displayed after the closing bracket
+for a function if the start of that function is not in the
+trace buffer.
+Display of the function name after the closing bracket may be
+enabled for functions whose start is in the trace buffer,
+allowing easier searching with grep for function durations.
+It is default disabled.
+        hide: echo nofuncgraph-tail > trace_options
+        show: echo funcgraph-tail > trace_options
+  Example with nofuncgraph-tail (default):
+  0)               |      putname() {
+  0)               |        kmem_cache_free() {
+  0)   0.518 us    |          __phys_addr();
+  0)   1.757 us    |        }
+  0)   2.861 us    |      }
+  Example with funcgraph-tail:
+  0)               |      putname() {
+  0)               |        kmem_cache_free() {
+  0)   0.518 us    |          __phys_addr();
+  0)   1.757 us    |        } /* kmem_cache_free() */
+  0)   2.861 us    |      } /* putname() */
 You can put some comments on specific functions by using
 trace_printk() For example, if you want to put a comment inside
 the __might_sleep() function, you just have to include
diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt
index 6b018b53177a..a3efac621c5a 100644
--- a/Documentation/trace/tracepoints.txt
+++ b/Documentation/trace/tracepoints.txt
@@ -115,6 +115,30 @@ If the tracepoint has to be used in kernel modules, an
 EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
 used to export the defined tracepoints.
+If you need to do a bit of work for a tracepoint parameter, and
+that work is only used for the tracepoint, that work can be encapsulated
+within an if statement with the following:
+        if (trace_foo_bar_enabled()) {
+                int i;
+                int tot = 0;
+                for (i = 0; i < count; i++)
+                        tot += calculate_nuggets();
+                trace_foo_bar(tot);
+        }
+All trace_<tracepoint>() calls have a matching trace_<tracepoint>_enabled()
+function defined that returns true if the tracepoint is enabled and
+false otherwise. The trace_<tracepoint>() should always be within the
+block of the if (trace_<tracepoint>_enabled()) to prevent races between
+the tracepoint being enabled and the check being seen.
+The advantage of using the trace_<tracepoint>_enabled() is that it uses
+the static_key of the tracepoint to allow the if statement to be implemented
+with jump labels and avoid conditional branches.
 Note: The convenience macro TRACE_EVENT provides an alternative way to
      define tracepoints. Check http://lwn.net/Articles/379903,
      http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
diff --git a/Documentation/vDSO/parse_vdso.c b/Documentation/vDSO/parse_vdso.c
index 85870208edcf..1dbb4b87268f 100644
--- a/Documentation/vDSO/parse_vdso.c
+++ b/Documentation/vDSO/parse_vdso.c
@@ -1,6 +1,6 @@
 /*
 * parse_vdso.c: Linux reference vDSO parser
- * Written by Andrew Lutomirski, 2011.
+ * Written by Andrew Lutomirski, 2011-2014.
 *
 * This code is meant to be linked in to various programs that run on Linux.
 * As such, it is available with as few restrictions as possible.  This file
@@ -11,13 +11,14 @@
 * it starts a program.  It works equally well in statically and dynamically
 * linked binaries.
 *
- * This code is tested on x86_64.  In principle it should work on any 64-bit
+ * This code is tested on x86.  In principle it should work on any
 * architecture that has a vDSO.
 */
 #include <stdbool.h>
 #include <stdint.h>
 #include <string.h>
+#include <limits.h>
 #include <elf.h>
 /*
@@ -45,11 +46,18 @@ extern void *vdso_sym(const char *version, const char *name);
 /* And here's the code. */
+#ifndef ELF_BITS
-#ifndef __x86_64__
+# if ULONG_MAX > 0xffffffffUL
-# error Not yet ported to non-x86_64 architectures
+#  define ELF_BITS 64
+# else
+#  define ELF_BITS 32
+# endif
 #endif
+#define ELF_BITS_XFORM2(bits, x) Elf##bits##_##x
+#define ELF_BITS_XFORM(bits, x) ELF_BITS_XFORM2(bits, x)
+#define ELF(x) ELF_BITS_XFORM(ELF_BITS, x)
 static struct vdso_info
 {
        bool valid;
@@ -59,14 +67,14 @@ static struct vdso_info
        uintptr_t load_offset;  /* load_addr - recorded vaddr */
        /* Symbol table */
-        Elf64_Sym *symtab;
+        ELF(Sym) *symtab;
        const char *symstrings;
-        Elf64_Word *bucket, *chain;
+        ELF(Word) *bucket, *chain;
-        Elf64_Word nbucket, nchain;
+        ELF(Word) nbucket, nchain;
        /* Version table */
-        Elf64_Versym *versym;
+        ELF(Versym) *versym;
-        Elf64_Verdef *verdef;
+        ELF(Verdef) *verdef;
 } vdso_info;
 /* Straight from the ELF specification. */
@@ -92,9 +100,14 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base)
        vdso_info.load_addr = base;
-        Elf64_Ehdr *hdr = (Elf64_Ehdr*)base;
+        ELF(Ehdr) *hdr = (ELF(Ehdr)*)base;
-        Elf64_Phdr *pt = (Elf64_Phdr*)(vdso_info.load_addr + hdr->e_phoff);
+        if (hdr->e_ident[EI_CLASS] !=
-        Elf64_Dyn *dyn = 0;
+            (ELF_BITS == 32 ? ELFCLASS32 : ELFCLASS64)) {
+                return;  /* Wrong ELF class -- check ELF_BITS */
+        }
+        ELF(Phdr) *pt = (ELF(Phdr)*)(vdso_info.load_addr + hdr->e_phoff);
+        ELF(Dyn) *dyn = 0;
        /*
         * We need two things from the segment table: the load offset
@@ -108,7 +121,7 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base)
                                + (uintptr_t)pt[i].p_offset
                                - (uintptr_t)pt[i].p_vaddr;
                } else if (pt[i].p_type == PT_DYNAMIC) {
-                        dyn = (Elf64_Dyn*)(base + pt[i].p_offset);
+                        dyn = (ELF(Dyn)*)(base + pt[i].p_offset);
                }
        }
@@ -118,7 +131,7 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base)
        /*
         * Fish out the useful bits of the dynamic table.
         */
-        Elf64_Word *hash = 0;
+        ELF(Word) *hash = 0;
        vdso_info.symstrings = 0;
        vdso_info.symtab = 0;
        vdso_info.versym = 0;
@@ -131,22 +144,22 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base)
                                 + vdso_info.load_offset);
                        break;
                case DT_SYMTAB:
-                        vdso_info.symtab = (Elf64_Sym *)
+                        vdso_info.symtab = (ELF(Sym) *)
                                ((uintptr_t)dyn[i].d_un.d_ptr
                                 + vdso_info.load_offset);
                        break;
                case DT_HASH:
-                        hash = (Elf64_Word *)
+                        hash = (ELF(Word) *)
                                ((uintptr_t)dyn[i].d_un.d_ptr
                                 + vdso_info.load_offset);
                        break;
                case DT_VERSYM:
-                        vdso_info.versym = (Elf64_Versym *)
+                        vdso_info.versym = (ELF(Versym) *)
                                ((uintptr_t)dyn[i].d_un.d_ptr
                                 + vdso_info.load_offset);
                        break;
                case DT_VERDEF:
-                        vdso_info.verdef = (Elf64_Verdef *)
+                        vdso_info.verdef = (ELF(Verdef) *)
                                ((uintptr_t)dyn[i].d_un.d_ptr
                                 + vdso_info.load_offset);
                        break;
@@ -168,8 +181,8 @@ void vdso_init_from_sysinfo_ehdr(uintptr_t base)
        vdso_info.valid = true;
 }
-static bool vdso_match_version(Elf64_Versym ver,
+static bool vdso_match_version(ELF(Versym) ver,
-                               const char *name, Elf64_Word hash)
+                               const char *name, ELF(Word) hash)
 {
        /*
         * This is a helper function to check if the version indexed by
@@ -188,7 +201,7 @@ static bool vdso_match_version(Elf64_Versym ver,
        /* First step: find the version definition */
        ver &= 0x7fff;  /* Apparently bit 15 means "hidden" */
-        Elf64_Verdef *def = vdso_info.verdef;
+        ELF(Verdef) *def = vdso_info.verdef;
        while(true) {
                if ((def->vd_flags & VER_FLG_BASE) == 0
                    && (def->vd_ndx & 0x7fff) == ver)
@@ -197,11 +210,11 @@ static bool vdso_match_version(Elf64_Versym ver,
                if (def->vd_next == 0)
                        return false;  /* No definition. */
-                def = (Elf64_Verdef *)((char *)def + def->vd_next);
+                def = (ELF(Verdef) *)((char *)def + def->vd_next);
        }
        /* Now figure out whether it matches. */
-        Elf64_Verdaux *aux = (Elf64_Verdaux*)((char *)def + def->vd_aux);
+        ELF(Verdaux) *aux = (ELF(Verdaux)*)((char *)def + def->vd_aux);
        return def->vd_hash == hash
                && !strcmp(name, vdso_info.symstrings + aux->vda_name);
 }
@@ -213,10 +226,10 @@ void *vdso_sym(const char *version, const char *name)
                return 0;
        ver_hash = elf_hash(version);
-        Elf64_Word chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket];
+        ELF(Word) chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket];
        for (; chain != STN_UNDEF; chain = vdso_info.chain[chain]) {
-                Elf64_Sym *sym = &vdso_info.symtab[chain];
+                ELF(Sym) *sym = &vdso_info.symtab[chain];
                /* Check for a defined global or weak function w/ right name. */
                if (ELF64_ST_TYPE(sym->st_info) != STT_FUNC)
@@ -243,7 +256,7 @@ void *vdso_sym(const char *version, const char *name)
 void vdso_init_from_auxv(void *auxv)
 {
-        Elf64_auxv_t *elf_auxv = auxv;
+        ELF(auxv_t) *elf_auxv = auxv;
        for (int i = 0; elf_auxv[i].a_type != AT_NULL; i++)
        {
                if (elf_auxv[i].a_type == AT_SYSINFO_EHDR) {
diff --git a/Documentation/vDSO/vdso_standalone_test_x86.c b/Documentation/vDSO/vdso_standalone_test_x86.c
new file mode 100644
index 000000000000..d46240265c50
--- /dev/null
+++ b/Documentation/vDSO/vdso_standalone_test_x86.c
@@ -0,0 +1,128 @@
+/*
+ * vdso_test.c: Sample code to test parse_vdso.c on x86
+ * Copyright (c) 2011-2014 Andy Lutomirski
+ * Subject to the GNU General Public License, version 2
+ *
+ * You can amuse yourself by compiling with:
+ * gcc -std=gnu99 -nostdlib
+ *     -Os -fno-asynchronous-unwind-tables -flto -lgcc_s
+ *      vdso_standalone_test_x86.c parse_vdso.c
+ * to generate a small binary.  On x86_64, you can omit -lgcc_s
+ * if you want the binary to be completely standalone.
+ */
+#include <sys/syscall.h>
+#include <sys/time.h>
+#include <unistd.h>
+#include <stdint.h>
+extern void *vdso_sym(const char *version, const char *name);
+extern void vdso_init_from_sysinfo_ehdr(uintptr_t base);
+extern void vdso_init_from_auxv(void *auxv);
+/* We need a libc functions... */
+int strcmp(const char *a, const char *b)
+{
+        /* This implementation is buggy: it never returns -1. */
+        while (*a || *b) {
+                if (*a != *b)
+                        return 1;
+                if (*a == 0 || *b == 0)
+                        return 1;
+                a++;
+                b++;
+        }
+        return 0;
+}
+/* ...and two syscalls.  This is x86-specific. */
+static inline long x86_syscall3(long nr, long a0, long a1, long a2)
+{
+        long ret;
+#ifdef __x86_64__
+        asm volatile ("syscall" : "=a" (ret) : "a" (nr),
+                      "D" (a0), "S" (a1), "d" (a2) :
+                      "cc", "memory", "rcx",
+                      "r8", "r9", "r10", "r11" );
+#else
+        asm volatile ("int $0x80" : "=a" (ret) : "a" (nr),
+                      "b" (a0), "c" (a1), "d" (a2) :
+                      "cc", "memory" );
+#endif
+        return ret;
+}
+static inline long linux_write(int fd, const void *data, size_t len)
+{
+        return x86_syscall3(__NR_write, fd, (long)data, (long)len);
+}
+static inline void linux_exit(int code)
+{
+        x86_syscall3(__NR_exit, code, 0, 0);
+}
+void to_base10(char *lastdig, uint64_t n)
+{
+        while (n) {
+                *lastdig = (n % 10) + '0';
+                n /= 10;
+                lastdig--;
+        }
+}
+__attribute__((externally_visible)) void c_main(void **stack)
+{
+        /* Parse the stack */
+        long argc = (long)*stack;
+        stack += argc + 2;
+        /* Now we're pointing at the environment.  Skip it. */
+        while(*stack)
+                stack++;
+        stack++;
+        /* Now we're pointing at auxv.  Initialize the vDSO parser. */
+        vdso_init_from_auxv((void *)stack);
+        /* Find gettimeofday. */
+        typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz);
+        gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday");
+        if (!gtod)
+                linux_exit(1);
+        struct timeval tv;
+        long ret = gtod(&tv, 0);
+        if (ret == 0) {
+                char buf[] = "The time is                     .000000\n";
+                to_base10(buf + 31, tv.tv_sec);
+                to_base10(buf + 38, tv.tv_usec);
+                linux_write(1, buf, sizeof(buf) - 1);
+        } else {
+                linux_exit(ret);
+        }
+        linux_exit(0);
+}
+/*
+ * This is the real entry point.  It passes the initial stack into
+ * the C entry point.
+ */
+asm (
+        ".text\n"
+        ".global _start\n"
+        ".type _start,@function\n"
+        "_start:\n\t"
+#ifdef __x86_64__
+        "mov %rsp,%rdi\n\t"
+        "jmp c_main"
+#else
+        "push %esp\n\t"
+        "call c_main\n\t"
+        "int $3"
+#endif
+        );
diff --git a/Documentation/vDSO/vdso_test.c b/Documentation/vDSO/vdso_test.c
index fff633432dff..8daeb7d7032c 100644
--- a/Documentation/vDSO/vdso_test.c
+++ b/Documentation/vDSO/vdso_test.c
@@ -1,111 +1,52 @@
 /*
- * vdso_test.c: Sample code to test parse_vdso.c on x86_64
+ * vdso_test.c: Sample code to test parse_vdso.c
- * Copyright (c) 2011 Andy Lutomirski
+ * Copyright (c) 2014 Andy Lutomirski
 * Subject to the GNU General Public License, version 2
 *
- * You can amuse yourself by compiling with:
+ * Compile with:
- * gcc -std=gnu99 -nostdlib
+ * gcc -std=gnu99 vdso_test.c parse_vdso.c
- *     -Os -fno-asynchronous-unwind-tables -flto
+ *
- *      vdso_test.c parse_vdso.c -o vdso_test
+ * Tested on x86, 32-bit and 64-bit.  It may work on other architectures, too.
- * to generate a small binary with no dependencies at all.
 */
-#include <sys/syscall.h>
-#include <sys/time.h>
-#include <unistd.h>
 #include <stdint.h>
+#include <elf.h>
+#include <stdio.h>
+#include <sys/auxv.h>
+#include <sys/time.h>
 extern void *vdso_sym(const char *version, const char *name);
 extern void vdso_init_from_sysinfo_ehdr(uintptr_t base);
 extern void vdso_init_from_auxv(void *auxv);
-/* We need a libc functions... */
+int main(int argc, char **argv)
-int strcmp(const char *a, const char *b)
 {
-        /* This implementation is buggy: it never returns -1. */
+        unsigned long sysinfo_ehdr = getauxval(AT_SYSINFO_EHDR);
-        while (*a || *b) {
+        if (!sysinfo_ehdr) {
-                if (*a != *b)
+                printf("AT_SYSINFO_EHDR is not present!\n");
-                        return 1;
+                return 0;
-                if (*a == 0 || *b == 0)
-                        return 1;
-                a++;
-                b++;
        }
-        return 0;
+        vdso_init_from_sysinfo_ehdr(getauxval(AT_SYSINFO_EHDR));
-}
-/* ...and two syscalls.  This is x86_64-specific. */
-static inline long linux_write(int fd, const void *data, size_t len)
-{
-        long ret;
-        asm volatile ("syscall" : "=a" (ret) : "a" (__NR_write),
-                      "D" (fd), "S" (data), "d" (len) :
-                      "cc", "memory", "rcx",
-                      "r8", "r9", "r10", "r11" );
-        return ret;
-}
-static inline void linux_exit(int code)
-{
-        asm volatile ("syscall" : : "a" (__NR_exit), "D" (code));
-}
-void to_base10(char *lastdig, uint64_t n)
-{
-        while (n) {
-                *lastdig = (n % 10) + '0';
-                n /= 10;
-                lastdig--;
-        }
-}
-__attribute__((externally_visible)) void c_main(void **stack)
-{
-        /* Parse the stack */
-        long argc = (long)*stack;
-        stack += argc + 2;
-        /* Now we're pointing at the environment.  Skip it. */
-        while(*stack)
-                stack++;
-        stack++;
-        /* Now we're pointing at auxv.  Initialize the vDSO parser. */
-        vdso_init_from_auxv((void *)stack);
        /* Find gettimeofday. */
        typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz);
        gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday");
-        if (!gtod)
+        if (!gtod) {
-                linux_exit(1);
+                printf("Could not find __vdso_gettimeofday\n");
+                return 1;
+        }
        struct timeval tv;
        long ret = gtod(&tv, 0);
        if (ret == 0) {
-                char buf[] = "The time is                     .000000\n";
+                printf("The time is %lld.%06lld\n",
-                to_base10(buf + 31, tv.tv_sec);
+                       (long long)tv.tv_sec, (long long)tv.tv_usec);
-                to_base10(buf + 38, tv.tv_usec);
-                linux_write(1, buf, sizeof(buf) - 1);
        } else {
-                linux_exit(ret);
+                printf("__vdso_gettimeofday failed\n");
        }
-        linux_exit(0);
+        return 0;
 }
-/*
- * This is the real entry point.  It passes the initial stack into
- * the C entry point.
- */
-asm (
-        ".text\n"
-        ".global _start\n"
-        ".type _start,@function\n"
-        "_start:\n\t"
-        "mov %rsp,%rdi\n\t"
-        "jmp c_main"
-        );