402 files changed, 12986 insertions, 2274 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/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget
index 37559a06393b..95a36589a66b 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -62,6 +62,40 @@ KernelVersion:	3.11
 Description:
                 This group contains functions available to this USB gadget.
 
+What:           /config/usb-gadget/gadget/functions/<func>.<inst>/interface.<n>
+Date:           May 2014
+KernelVersion:  3.16
+Description:
+                This group contains "Feature Descriptors" specific for one
+                gadget's USB interface or one interface group described
+                by an IAD.
+
+                The attributes:
+
+                compatible_id           - 8-byte string for "Compatible ID"
+                sub_compatible_id       - 8-byte string for "Sub Compatible ID"
+
+What:           /config/usb-gadget/gadget/functions/<func>.<inst>/interface.<n>/<property>
+Date:           May 2014
+KernelVersion:  3.16
+Description:
+                This group contains "Extended Property Descriptors" specific for one
+                gadget's USB interface or one interface group described
+                by an IAD.
+
+                The attributes:
+
+                type            - value 1..7 for interpreting the data
+                                1: unicode string
+                                2: unicode string with environment variable
+                                3: binary
+                                4: little-endian 32-bit
+                                5: big-endian 32-bit
+                                6: unicode string with a symbolic link
+                                7: multiple unicode strings
+                data            - blob of data to be interpreted depending on
+                                type
+
 What:           /config/usb-gadget/gadget/strings
 Date:           Jun 2013
 KernelVersion:  3.11
@@ -79,3 +113,14 @@ Description:
                 product         - gadget's product description
                 manufacturer    - gadget's manufacturer description
 
+What:           /config/usb-gadget/gadget/os_desc
+Date:           May 2014
+KernelVersion:  3.16
+Description:
+                This group contains "OS String" extension handling attributes.
+
+                use             - flag turning "OS Desctiptors" support on/off
+                b_vendor_code   - one-byte value used for custom per-device and
+                                per-interface requests
+                qw_sign         - an identifier to be reported as "OS String"
+                                proper
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-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 6e02c5029152..a9757dcf2e81 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -114,14 +114,17 @@ What:		/sys/bus/iio/devices/iio:deviceX/in_temp_raw
 What:           /sys/bus/iio/devices/iio:deviceX/in_tempX_raw
 What:           /sys/bus/iio/devices/iio:deviceX/in_temp_x_raw
 What:           /sys/bus/iio/devices/iio:deviceX/in_temp_y_raw
-What:           /sys/bus/iio/devices/iio:deviceX/in_temp_z_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_ambient_raw
+What:           /sys/bus/iio/devices/iio:deviceX/in_temp_object_raw
 KernelVersion:  2.6.35
 Contact:        linux-iio@vger.kernel.org
 Description:
                 Raw (unscaled no bias removal etc.) temperature measurement.
                 If an axis is specified it generally means that the temperature
                 sensor is associated with one part of a compound device (e.g.
-                a gyroscope axis). Units after application of scale and offset
+                a gyroscope axis). The ambient and object modifiers distinguish
+                between ambient (reference) and distant temperature for contact-
+                less measurements. Units after application of scale and offset
                 are milli degrees Celsius.
 
 What:           /sys/bus/iio/devices/iio:deviceX/in_tempX_input
@@ -210,6 +213,14 @@ Contact:	linux-iio@vger.kernel.org
 Description:
                 Scaled humidity measurement in milli percent.
 
+What:           /sys/bus/iio/devices/iio:deviceX/in_X_mean_raw
+KernelVersion:  3.5
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Averaged raw measurement from channel X. The number of values
+                used for averaging is device specific. The converting rules for
+                normal raw values also applies to the averaged raw values.
+
 What:           /sys/bus/iio/devices/iio:deviceX/in_accel_offset
 What:           /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
 What:           /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
@@ -784,6 +795,7 @@ What:		/sys/.../iio:deviceX/scan_elements/in_incli_x_en
 What:           /sys/.../iio:deviceX/scan_elements/in_incli_y_en
 What:           /sys/.../iio:deviceX/scan_elements/in_pressureY_en
 What:           /sys/.../iio:deviceX/scan_elements/in_pressure_en
+What:           /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
@@ -799,6 +811,7 @@ What:		/sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
 What:           /sys/.../iio:deviceX/scan_elements/in_timestamp_type
 What:           /sys/.../iio:deviceX/scan_elements/in_pressureY_type
 What:           /sys/.../iio:deviceX/scan_elements/in_pressure_type
+What:           /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
@@ -845,6 +858,7 @@ What:		/sys/.../iio:deviceX/scan_elements/in_incli_y_index
 What:           /sys/.../iio:deviceX/scan_elements/in_timestamp_index
 What:           /sys/.../iio:deviceX/scan_elements/in_pressureY_index
 What:           /sys/.../iio:deviceX/scan_elements/in_pressure_index
+What:           /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
@@ -881,6 +895,25 @@ Description:
                 on-chip EEPROM. After power-up or chip reset the device will
                 automatically load the saved configuration.
 
+What:           /sys/.../iio:deviceX/in_illuminanceY_input
+What:           /sys/.../iio:deviceX/in_illuminanceY_raw
+What:           /sys/.../iio:deviceX/in_illuminanceY_mean_raw
+KernelVersion:  3.4
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Illuminance measurement, units after application of scale
+                and offset are lux.
+
+What:           /sys/.../iio:deviceX/in_intensityY_raw
+What:           /sys/.../iio:deviceX/in_intensityY_ir_raw
+What:           /sys/.../iio:deviceX/in_intensityY_both_raw
+KernelVersion:  3.4
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Unit-less light intensity. Modifiers both and ir indicate
+                that measurements contains visible and infrared light
+                components or just infrared light, respectively.
+
 What:           /sys/.../iio:deviceX/in_intensity_red_integration_time
 What:           /sys/.../iio:deviceX/in_intensity_green_integration_time
 What:           /sys/.../iio:deviceX/in_intensity_blue_integration_time
@@ -891,3 +924,12 @@ Contact:	linux-iio@vger.kernel.org
 Description:
                 This attribute is used to get/set the integration time in
                 seconds.
+
+What:           /sys/bus/iio/devices/iio:deviceX/in_rot_quaternion_raw
+KernelVersion:  3.15
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw value of quaternion components using a format
+                x y z w. Here x, y, and z component represents the axis about
+                which a rotation will occur and w component represents the
+                amount of rotation.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935 b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
new file mode 100644
index 000000000000..6708c5e264aa
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-iio-proximity-as3935
@@ -0,0 +1,16 @@
+What            /sys/bus/iio/devices/iio:deviceX/in_proximity_raw
+Date:           March 2014
+KernelVersion:  3.15
+Contact:        Matt Ranostay <mranostay@gmail.com>
+Description:
+                Get the current distance in meters of storm (1km steps)
+                1000-40000 = distance in meters
+
+What            /sys/bus/iio/devices/iio:deviceX/sensor_sensitivity
+Date:           March 2014
+KernelVersion:  3.15
+Contact:        Matt Ranostay <mranostay@gmail.com>
+Description:
+                Show or set the gain boost of the amp, from 0-31 range.
+                18 = indoors (default)
+                14 = outdoors
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index a3c5a6685036..6615fda0abfb 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -117,7 +117,7 @@ Description:
 
 What:           /sys/bus/pci/devices/.../vpd
 Date:           February 2008
-Contact:        Ben Hutchings <bhutchings@solarflare.com>
+Contact:        Ben Hutchings <bwh@kernel.org>
 Description:
                 A file named vpd in a device directory will be a
                 binary file containing the Vital Product Data for the
@@ -250,3 +250,24 @@ Description:
                 valid.  For example, writing a 2 to this file when sriov_numvfs
                 is not 0 and not 2 already will return an error. Writing a 10
                 when the value of sriov_totalvfs is 8 will return an error.
+
+What:           /sys/bus/pci/devices/.../driver_override
+Date:           April 2014
+Contact:        Alex Williamson <alex.williamson@redhat.com>
+Description:
+                This file allows the driver for a device to be specified which
+                will override standard static and dynamic ID matching.  When
+                specified, only a driver with a name matching the value written
+                to driver_override will have an opportunity to bind to the
+                device.  The override is specified by writing a string to the
+                driver_override file (echo pci-stub > driver_override) and
+                may be cleared with an empty string (echo > driver_override).
+                This returns the device to standard matching rules binding.
+                Writing to driver_override does not automatically unbind the
+                device from its current driver or make any attempt to
+                automatically load the specified driver.  If no driver with a
+                matching name is currently loaded in the kernel, the device
+                will not bind to any driver.  This also allows devices to
+                opt-out of driver binding using a driver_override name such as
+                "none".  Only a single driver may be specified in the override,
+                there is no support for parsing delimiters.
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/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index d5a0d33c571f..acb9bfc89b48 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -128,7 +128,7 @@ Description:	Discover cpuidle policy and mechanism
 
 What:           /sys/devices/system/cpu/cpu#/cpufreq/*
 Date:           pre-git history
-Contact:        cpufreq@vger.kernel.org
+Contact:        linux-pm@vger.kernel.org
 Description:    Discover and change clock speed of CPUs
 
                 Clock scaling allows you to change the clock speed of the
@@ -146,7 +146,7 @@ Description:	Discover and change clock speed of CPUs
 
 What:           /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
 Date:           June 2013
-Contact:        cpufreq@vger.kernel.org
+Contact:        linux-pm@vger.kernel.org
 Description:    Discover CPUs in the same CPU frequency coordination domain
 
                 freqdomain_cpus is the list of CPUs (online+offline) that share
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-thingm b/Documentation/ABI/testing/sysfs-driver-hid-thingm
deleted file mode 100644
index abcffeedd20a..000000000000
--- a/Documentation/ABI/testing/sysfs-driver-hid-thingm
+++ /dev/null
@@ -1,23 +0,0 @@
-What:           /sys/class/leds/blink1::<serial>/rgb
-Date:           January 2013
-Contact:        Vivien Didelot <vivien.didelot@savoirfairelinux.com>
-Description:    The ThingM blink1 is an USB RGB LED. The color notation is
-                3-byte hexadecimal. Read this attribute to get the last set
-                color. Write the 24-bit hexadecimal color to change the current
-                LED color. The default color is full white (0xFFFFFF).
-                For instance, set the color to green with: echo 00FF00 > rgb
-
-What:           /sys/class/leds/blink1::<serial>/fade
-Date:           January 2013
-Contact:        Vivien Didelot <vivien.didelot@savoirfairelinux.com>
-Description:    This attribute allows to set a fade time in milliseconds for
-                the next color change. Read the attribute to know the current
-                fade time. The default value is set to 0 (no fade time). For
-                instance, set a fade time of 2 seconds with: echo 2000 > fade
-
-What:           /sys/class/leds/blink1::<serial>/play
-Date:           January 2013
-Contact:        Vivien Didelot <vivien.didelot@savoirfairelinux.com>
-Description:    This attribute is used to play/pause the light patterns. Write 1
-                to start playing, 0 to stop. Reading this attribute returns the
-                current playing status.
diff --git a/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb b/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb
new file mode 100644
index 000000000000..f1bad92bbe27
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-brcmstb-gisb-arb
@@ -0,0 +1,8 @@
+What:           /sys/devices/../../gisb_arb_timeout
+Date:           May 2014
+KernelVersion:  3.17
+Contact:        Florian Fainelli <f.fainelli@gmail.com>
+Description:
+                Returns the currently configured raw timeout value of the
+                Broadcom Set Top Box internal GISB bus arbiter. Minimum value
+                is 1, and maximum value is 0xffffffff.
diff --git a/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg b/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg
new file mode 100644
index 000000000000..151c59578db4
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-chipidea-usb-otg
@@ -0,0 +1,56 @@
+What:           /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req
+Date:           Feb 2014
+Contact:        Li Jun <b47624@freescale.com>
+Description:
+                Can be set and read.
+                Set a_bus_req(A-device bus request) input to be 1 if
+                the application running on the A-device wants to use the bus,
+                and to be 0 when the application no longer wants to use
+                the bus(or wants to work as peripheral). a_bus_req can also
+                be set to 1 by kernel in response to remote wakeup signaling
+                from the B-device, the A-device should decide to resume the bus.
+
+                Valid values are "1" and "0".
+
+                Reading: returns 1 if the application running on the A-device
+                is using the bus as host role, otherwise 0.
+
+What:           /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop
+Date:           Feb 2014
+Contact:        Li Jun <b47624@freescale.com>
+Description:
+                Can be set and read
+                The a_bus_drop(A-device bus drop) input is 1 when the
+                application running on the A-device wants to power down
+                the bus, and is 0 otherwise, When a_bus_drop is 1, then
+                the a_bus_req shall be 0.
+
+                Valid values are "1" and "0".
+
+                Reading: returns 1 if the bus is off(vbus is turned off) by
+                         A-device, otherwise 0.
+
+What:           /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req
+Date:           Feb 2014
+Contact:        Li Jun <b47624@freescale.com>
+Description:
+                Can be set and read.
+                The b_bus_req(B-device bus request) input is 1 during the time
+                that the application running on the B-device wants to use the
+                bus as host, and is 0 when the application no longer wants to
+                work as host and decides to switch back to be peripheral.
+
+                Valid values are "1" and "0".
+
+                Reading: returns if the application running on the B device
+                is using the bus as host role, otherwise 0.
+
+What:           /sys/bus/platform/devices/ci_hdrc.0/inputs/a_clr_err
+Date:           Feb 2014
+Contact:        Li Jun <b47624@freescale.com>
+Description:
+                Only can be set.
+                The a_clr_err(A-device Vbus error clear) input is used to clear
+                vbus error, then A-device will power down the bus.
+
+                Valid value is "1"
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 64c9276e9421..f4551816329e 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -7,19 +7,30 @@ Description:
                 subsystem.
 
 What:           /sys/power/state
-Date:           August 2006
+Date:           May 2014
 Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
-                The /sys/power/state file controls the system power state.
-                Reading from this file returns what states are supported,
-                which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
-                (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
-                (Suspend-to-Disk).
+                The /sys/power/state file controls system sleep states.
+                Reading from this file returns the available sleep state
+                labels, which may be "mem", "standby", "freeze" and "disk"
+                (hibernation).  The meanings of the first three labels depend on
+                the relative_sleep_states command line argument as follows:
+                 1) relative_sleep_states = 1
+                    "mem", "standby", "freeze" represent non-hibernation sleep
+                    states from the deepest ("mem", always present) to the
+                    shallowest ("freeze").  "standby" and "freeze" may or may
+                    not be present depending on the capabilities of the
+                    platform.  "freeze" can only be present if "standby" is
+                    present.
+                 2) relative_sleep_states = 0 (default)
+                    "mem" - "suspend-to-RAM", present if supported.
+                    "standby" - "power-on suspend", present if supported.
+                    "freeze" - "suspend-to-idle", always present.
 
                 Writing to this file one of these strings causes the system to
-                transition into that state. Please see the file
-                Documentation/power/states.txt for a description of each of
-                these states.
+                transition into the corresponding state, if available.  See
+                Documentation/power/states.txt for a description of what
+                "suspend-to-RAM", "power-on suspend" and "suspend-to-idle" mean.
 
 What:           /sys/power/disk
 Date:           September 2006
diff --git a/Documentation/Changes b/Documentation/Changes
index 07c75d18154e..2254db0f00a5 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -73,6 +73,11 @@ Perl
 You will need perl 5 and the following modules: Getopt::Long, Getopt::Std,
 File::Basename, and File::Find to build the kernel.
 
+BC
+--
+
+You will need bc to build kernels 3.10 and higher
+
 
 System utilities
 ================
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 7fe0546c504a..6b6bef31e956 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -660,15 +660,23 @@ There are a number of driver model diagnostic macros in <linux/device.h>
 which you should use to make sure messages are matched to the right device
 and driver, and are tagged with the right level:  dev_err(), dev_warn(),
 dev_info(), and so forth.  For messages that aren't associated with a
-particular device, <linux/printk.h> defines pr_debug() and pr_info().
+particular device, <linux/printk.h> defines pr_notice(), pr_info(),
+pr_warn(), pr_err(), etc.
 
 Coming up with good debugging messages can be quite a challenge; and once
-you have them, they can be a huge help for remote troubleshooting.  Such
-messages should be compiled out when the DEBUG symbol is not defined (that
-is, by default they are not included).  When you use dev_dbg() or pr_debug(),
-that's automatic.  Many subsystems have Kconfig options to turn on -DDEBUG.
-A related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to the
-ones already enabled by DEBUG.
+you have them, they can be a huge help for remote troubleshooting.  However
+debug message printing is handled differently than printing other non-debug
+messages.  While the other pr_XXX() functions print unconditionally,
+pr_debug() does not; it is compiled out by default, unless either DEBUG is
+defined or CONFIG_DYNAMIC_DEBUG is set.  That is true for dev_dbg() also,
+and a related convention uses VERBOSE_DEBUG to add dev_vdbg() messages to
+the ones already enabled by DEBUG.
+
+Many subsystems have Kconfig debug options to turn on -DDEBUG in the
+corresponding Makefile; in other cases specific files #define DEBUG.  And
+when a debug message should be unconditionally printed, such as if it is
+already inside a debug-related #ifdef secton, printk(KERN_DEBUG ...) can be
+used.
 
 
                 Chapter 14: Allocating memory
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 5e983031cc11..dcbbe3602d78 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -9,16 +9,76 @@ This is a guide to device driver writers on how to use the DMA API
 with example pseudo-code.  For a concise description of the API, see
 DMA-API.txt.
 
-Most of the 64bit platforms have special hardware that translates bus
-addresses (DMA addresses) into physical addresses.  This is similar to
-how page tables and/or a TLB translates virtual addresses to physical
-addresses on a CPU.  This is needed so that e.g. PCI devices can
-access with a Single Address Cycle (32bit DMA address) any page in the
-64bit physical address space.  Previously in Linux those 64bit
-platforms had to set artificial limits on the maximum RAM size in the
-system, so that the virt_to_bus() static scheme works (the DMA address
-translation tables were simply filled on bootup to map each bus
-address to the physical page __pa(bus_to_virt())).
+                       CPU and DMA addresses
+
+There are several kinds of addresses involved in the DMA API, and it's
+important to understand the differences.
+
+The kernel normally uses virtual addresses.  Any address returned by
+kmalloc(), vmalloc(), and similar interfaces is a virtual address and can
+be stored in a "void *".
+
+The virtual memory system (TLB, page tables, etc.) translates virtual
+addresses to CPU physical addresses, which are stored as "phys_addr_t" or
+"resource_size_t".  The kernel manages device resources like registers as
+physical addresses.  These are the addresses in /proc/iomem.  The physical
+address is not directly useful to a driver; it must use ioremap() to map
+the space and produce a virtual address.
+
+I/O devices use a third kind of address: a "bus address" or "DMA address".
+If a device has registers at an MMIO address, or if it performs DMA to read
+or write system memory, the addresses used by the device are bus addresses.
+In some systems, bus addresses are identical to CPU physical addresses, but
+in general they are not.  IOMMUs and host bridges can produce arbitrary
+mappings between physical and bus addresses.
+
+Here's a picture and some examples:
+
+               CPU                  CPU                  Bus
+             Virtual              Physical             Address
+             Address              Address               Space
+              Space                Space
+
+            +-------+             +------+             +------+
+            |       |             |MMIO  |   Offset    |      |
+            |       |  Virtual    |Space |   applied   |      |
+          C +-------+ --------> B +------+ ----------> +------+ A
+            |       |  mapping    |      |   by host   |      |
+  +-----+   |       |             |      |   bridge    |      |   +--------+
+  |     |   |       |             +------+             |      |   |        |
+  | CPU |   |       |             | RAM  |             |      |   | Device |
+  |     |   |       |             |      |             |      |   |        |
+  +-----+   +-------+             +------+             +------+   +--------+
+            |       |  Virtual    |Buffer|   Mapping   |      |
+          X +-------+ --------> Y +------+ <---------- +------+ Z
+            |       |  mapping    | RAM  |   by IOMMU
+            |       |             |      |
+            |       |             |      |
+            +-------+             +------+
+
+During the enumeration process, the kernel learns about I/O devices and
+their MMIO space and the host bridges that connect them to the system.  For
+example, if a PCI device has a BAR, the kernel reads the bus address (A)
+from the BAR and converts it to a CPU physical address (B).  The address B
+is stored in a struct resource and usually exposed via /proc/iomem.  When a
+driver claims a device, it typically uses ioremap() to map physical address
+B at a virtual address (C).  It can then use, e.g., ioread32(C), to access
+the device registers at bus address A.
+
+If the device supports DMA, the driver sets up a buffer using kmalloc() or
+a similar interface, which returns a virtual address (X).  The virtual
+memory system maps X to a physical address (Y) in system RAM.  The driver
+can use virtual address X to access the buffer, but the device itself
+cannot because DMA doesn't go through the CPU virtual memory system.
+
+In some simple systems, the device can do DMA directly to physical address
+Y.  But in many others, there is IOMMU hardware that translates bus
+addresses to physical addresses, e.g., it translates Z to Y.  This is part
+of the reason for the DMA API: the driver can give a virtual address X to
+an interface like dma_map_single(), which sets up any required IOMMU
+mapping and returns the bus address Z.  The driver then tells the device to
+do DMA to Z, and the IOMMU maps it to the buffer at address Y in system
+RAM.
 
 So that Linux can use the dynamic DMA mapping, it needs some help from the
 drivers, namely it has to take into account that DMA addresses should be
@@ -29,17 +89,17 @@ The following API will work of course even on platforms where no such
 hardware exists.
 
 Note that the DMA API works with any bus independent of the underlying
-microprocessor architecture. You should use the DMA API rather than
-the bus specific DMA API (e.g. pci_dma_*).
+microprocessor architecture. You should use the DMA API rather than the
+bus-specific DMA API, i.e., use the dma_map_*() interfaces rather than the
+pci_map_*() interfaces.
 
 First of all, you should make sure
 
 #include <linux/dma-mapping.h>
 
-is in your driver. This file will obtain for you the definition of the
-dma_addr_t (which can hold any valid DMA address for the platform)
-type which should be used everywhere you hold a DMA (bus) address
-returned from the DMA mapping functions.
+is in your driver, which provides the definition of dma_addr_t.  This type
+can hold any valid DMA or bus address for the platform and should be used
+everywhere you hold a DMA address returned from the DMA mapping functions.
 
                          What memory is DMA'able?
 
@@ -123,9 +183,9 @@ Here, dev is a pointer to the device struct of your device, and mask
 is a bit mask describing which bits of an address your device
 supports.  It returns zero if your card can perform DMA properly on
 the machine given the address mask you provided.  In general, the
-device struct of your device is embedded in the bus specific device
-struct of your device.  For example, a pointer to the device struct of
-your PCI device is pdev->dev (pdev is a pointer to the PCI device
+device struct of your device is embedded in the bus-specific device
+struct of your device.  For example, &pdev->dev is a pointer to the
+device struct of a PCI device (pdev is a pointer to the PCI device
 struct of your device).
 
 If it returns non-zero, your device cannot perform DMA properly on
@@ -147,8 +207,7 @@ exactly why.
 The standard 32-bit addressing device would do something like this:
 
         if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
-                printk(KERN_WARNING
-                       "mydev: No suitable DMA available.\n");
+                dev_warn(dev, "mydev: No suitable DMA available\n");
                 goto ignore_this_device;
         }
 
@@ -170,8 +229,7 @@ all 64-bits when accessing streaming DMA:
         } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
                 using_dac = 0;
         } else {
-                printk(KERN_WARNING
-                       "mydev: No suitable DMA available.\n");
+                dev_warn(dev, "mydev: No suitable DMA available\n");
                 goto ignore_this_device;
         }
 
@@ -187,22 +245,20 @@ the case would look like this:
                 using_dac = 0;
                 consistent_using_dac = 0;
         } else {
-                printk(KERN_WARNING
-                       "mydev: No suitable DMA available.\n");
+                dev_warn(dev, "mydev: No suitable DMA available\n");
                 goto ignore_this_device;
         }
 
-The coherent coherent mask will always be able to set the same or a
-smaller mask as the streaming mask. However for the rare case that a
-device driver only uses consistent allocations, one would have to
-check the return value from dma_set_coherent_mask().
+The coherent mask will always be able to set the same or a smaller mask as
+the streaming mask. However for the rare case that a device driver only
+uses consistent allocations, one would have to check the return value from
+dma_set_coherent_mask().
 
 Finally, if your device can only drive the low 24-bits of
 address you might do something like:
 
         if (dma_set_mask(dev, DMA_BIT_MASK(24))) {
-                printk(KERN_WARNING
-                       "mydev: 24-bit DMA addressing not available.\n");
+                dev_warn(dev, "mydev: 24-bit DMA addressing not available\n");
                 goto ignore_this_device;
         }
 
@@ -232,14 +288,14 @@ Here is pseudo-code showing how this might be done:
                 card->playback_enabled = 1;
         } else {
                 card->playback_enabled = 0;
-                printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n",
+                dev_warn(dev, "%s: Playback disabled due to DMA limitations\n",
                        card->name);
         }
         if (!dma_set_mask(dev, RECORD_ADDRESS_BITS)) {
                 card->record_enabled = 1;
         } else {
                 card->record_enabled = 0;
-                printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n",
+                dev_warn(dev, "%s: Record disabled due to DMA limitations\n",
                        card->name);
         }
 
@@ -331,7 +387,7 @@ context with the GFP_ATOMIC flag.
 Size is the length of the region you want to allocate, in bytes.
 
 This routine will allocate RAM for that region, so it acts similarly to
-__get_free_pages (but takes size instead of a page order).  If your
+__get_free_pages() (but takes size instead of a page order).  If your
 driver needs regions sized smaller than a page, you may prefer using
 the dma_pool interface, described below.
 
@@ -343,11 +399,11 @@ the consistent DMA mask has been explicitly changed via
 dma_set_coherent_mask().  This is true of the dma_pool interface as
 well.
 
-dma_alloc_coherent returns two values: the virtual address which you
+dma_alloc_coherent() returns two values: the virtual address which you
 can use to access it from the CPU and dma_handle which you pass to the
 card.
 
-The cpu return address and the DMA bus master address are both
+The CPU virtual address and the DMA bus address are both
 guaranteed to be aligned to the smallest PAGE_SIZE order which
 is greater than or equal to the requested size.  This invariant
 exists (for example) to guarantee that if you allocate a chunk
@@ -359,13 +415,13 @@ To unmap and free such a DMA region, you call:
         dma_free_coherent(dev, size, cpu_addr, dma_handle);
 
 where dev, size are the same as in the above call and cpu_addr and
-dma_handle are the values dma_alloc_coherent returned to you.
+dma_handle are the values dma_alloc_coherent() returned to you.
 This function may not be called in interrupt context.
 
 If your driver needs lots of smaller memory regions, you can write
-custom code to subdivide pages returned by dma_alloc_coherent,
+custom code to subdivide pages returned by dma_alloc_coherent(),
 or you can use the dma_pool API to do that.  A dma_pool is like
-a kmem_cache, but it uses dma_alloc_coherent not __get_free_pages.
+a kmem_cache, but it uses dma_alloc_coherent(), not __get_free_pages().
 Also, it understands common hardware constraints for alignment,
 like queue heads needing to be aligned on N byte boundaries.
 
@@ -373,37 +429,37 @@ Create a dma_pool like this:
 
         struct dma_pool *pool;
 
-        pool = dma_pool_create(name, dev, size, align, alloc);
+        pool = dma_pool_create(name, dev, size, align, boundary);
 
 The "name" is for diagnostics (like a kmem_cache name); dev and size
 are as above.  The device's hardware alignment requirement for this
 type of data is "align" (which is expressed in bytes, and must be a
 power of two).  If your device has no boundary crossing restrictions,
-pass 0 for alloc; passing 4096 says memory allocated from this pool
+pass 0 for boundary; passing 4096 says memory allocated from this pool
 must not cross 4KByte boundaries (but at that time it may be better to
-go for dma_alloc_coherent directly instead).
+use dma_alloc_coherent() directly instead).
 
-Allocate memory from a dma pool like this:
+Allocate memory from a DMA pool like this:
 
         cpu_addr = dma_pool_alloc(pool, flags, &dma_handle);
 
-flags are SLAB_KERNEL if blocking is permitted (not in_interrupt nor
-holding SMP locks), SLAB_ATOMIC otherwise.  Like dma_alloc_coherent,
+flags are GFP_KERNEL if blocking is permitted (not in_interrupt nor
+holding SMP locks), GFP_ATOMIC otherwise.  Like dma_alloc_coherent(),
 this returns two values, cpu_addr and dma_handle.
 
 Free memory that was allocated from a dma_pool like this:
 
         dma_pool_free(pool, cpu_addr, dma_handle);
 
-where pool is what you passed to dma_pool_alloc, and cpu_addr and
-dma_handle are the values dma_pool_alloc returned. This function
+where pool is what you passed to dma_pool_alloc(), and cpu_addr and
+dma_handle are the values dma_pool_alloc() returned. This function
 may be called in interrupt context.
 
 Destroy a dma_pool by calling:
 
         dma_pool_destroy(pool);
 
-Make sure you've called dma_pool_free for all memory allocated
+Make sure you've called dma_pool_free() for all memory allocated
 from a pool before you destroy the pool. This function may not
 be called in interrupt context.
 
@@ -418,7 +474,7 @@ one of the following values:
  DMA_FROM_DEVICE
  DMA_NONE
 
-One should provide the exact DMA direction if you know it.
+You should provide the exact DMA direction if you know it.
 
 DMA_TO_DEVICE means "from main memory to the device"
 DMA_FROM_DEVICE means "from the device to main memory"
@@ -489,14 +545,14 @@ and to unmap it:
         dma_unmap_single(dev, dma_handle, size, direction);
 
 You should call dma_mapping_error() as dma_map_single() could fail and return
-error. Not all dma implementations support dma_mapping_error() interface.
+error. Not all DMA implementations support the dma_mapping_error() interface.
 However, it is a good practice to call dma_mapping_error() interface, which
 will invoke the generic mapping error check interface. Doing so will ensure
-that the mapping code will work correctly on all dma implementations without
+that the mapping code will work correctly on all DMA implementations without
 any dependency on the specifics of the underlying implementation. Using the
 returned address without checking for errors could result in failures ranging
 from panics to silent data corruption. A couple of examples of incorrect ways
-to check for errors that make assumptions about the underlying dma
+to check for errors that make assumptions about the underlying DMA
 implementation are as follows and these are applicable to dma_map_page() as
 well.
 
@@ -516,13 +572,13 @@ Incorrect example 2:
                 goto map_error;
         }
 
-You should call dma_unmap_single when the DMA activity is finished, e.g.
+You should call dma_unmap_single() when the DMA activity is finished, e.g.,
 from the interrupt which told you that the DMA transfer is done.
 
-Using cpu pointers like this for single mappings has a disadvantage,
+Using CPU pointers like this for single mappings has a disadvantage:
 you cannot reference HIGHMEM memory in this way.  Thus, there is a
-map/unmap interface pair akin to dma_{map,unmap}_single.  These
-interfaces deal with page/offset pairs instead of cpu pointers.
+map/unmap interface pair akin to dma_{map,unmap}_single().  These
+interfaces deal with page/offset pairs instead of CPU pointers.
 Specifically:
 
         struct device *dev = &my_dev->dev;
@@ -550,7 +606,7 @@ Here, "offset" means byte offset within the given page.
 You should call dma_mapping_error() as dma_map_page() could fail and return
 error as outlined under the dma_map_single() discussion.
 
-You should call dma_unmap_page when the DMA activity is finished, e.g.
+You should call dma_unmap_page() when the DMA activity is finished, e.g.,
 from the interrupt which told you that the DMA transfer is done.
 
 With scatterlists, you map a region gathered from several regions by:
@@ -588,18 +644,16 @@ PLEASE NOTE:  The 'nents' argument to the dma_unmap_sg call must be
               it should _NOT_ be the 'count' value _returned_ from the
               dma_map_sg call.
 
-Every dma_map_{single,sg} call should have its dma_unmap_{single,sg}
-counterpart, because the bus address space is a shared resource (although
-in some ports the mapping is per each BUS so less devices contend for the
-same bus address space) and you could render the machine unusable by eating
-all bus addresses.
+Every dma_map_{single,sg}() call should have its dma_unmap_{single,sg}()
+counterpart, because the bus address space is a shared resource and
+you could render the machine unusable by consuming all bus addresses.
 
 If you need to use the same streaming DMA region multiple times and touch
 the data in between the DMA transfers, the buffer needs to be synced
-properly in order for the cpu and device to see the most uptodate and
+properly in order for the CPU and device to see the most up-to-date and
 correct copy of the DMA buffer.
 
-So, firstly, just map it with dma_map_{single,sg}, and after each DMA
+So, firstly, just map it with dma_map_{single,sg}(), and after each DMA
 transfer call either:
 
         dma_sync_single_for_cpu(dev, dma_handle, size, direction);
@@ -611,7 +665,7 @@ or:
 as appropriate.
 
 Then, if you wish to let the device get at the DMA area again,
-finish accessing the data with the cpu, and then before actually
+finish accessing the data with the CPU, and then before actually
 giving the buffer to the hardware call either:
 
         dma_sync_single_for_device(dev, dma_handle, size, direction);
@@ -623,9 +677,9 @@ or:
 as appropriate.
 
 After the last DMA transfer call one of the DMA unmap routines
-dma_unmap_{single,sg}. If you don't touch the data from the first dma_map_*
-call till dma_unmap_*, then you don't have to call the dma_sync_*
-routines at all.
+dma_unmap_{single,sg}(). If you don't touch the data from the first
+dma_map_*() call till dma_unmap_*(), then you don't have to call the
+dma_sync_*() routines at all.
 
 Here is pseudo code which shows a situation in which you would need
 to use the dma_sync_*() interfaces.
@@ -690,12 +744,12 @@ to use the dma_sync_*() interfaces.
                 }
         }
 
-Drivers converted fully to this interface should not use virt_to_bus any
-longer, nor should they use bus_to_virt. Some drivers have to be changed a
-little bit, because there is no longer an equivalent to bus_to_virt in the
+Drivers converted fully to this interface should not use virt_to_bus() any
+longer, nor should they use bus_to_virt(). Some drivers have to be changed a
+little bit, because there is no longer an equivalent to bus_to_virt() in the
 dynamic DMA mapping scheme - you have to always store the DMA addresses
-returned by the dma_alloc_coherent, dma_pool_alloc, and dma_map_single
-calls (dma_map_sg stores them in the scatterlist itself if the platform
+returned by the dma_alloc_coherent(), dma_pool_alloc(), and dma_map_single()
+calls (dma_map_sg() stores them in the scatterlist itself if the platform
 supports dynamic DMA mapping in hardware) in your driver structures and/or
 in the card registers.
 
@@ -709,9 +763,9 @@ as it is impossible to correctly support them.
 DMA address space is limited on some architectures and an allocation
 failure can be determined by:
 
-- checking if dma_alloc_coherent returns NULL or dma_map_sg returns 0
+- checking if dma_alloc_coherent() returns NULL or dma_map_sg returns 0
 
-- checking the returned dma_addr_t of dma_map_single and dma_map_page
+- checking the dma_addr_t returned from dma_map_single() and dma_map_page()
   by using dma_mapping_error():
 
         dma_addr_t dma_handle;
@@ -794,7 +848,7 @@ Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
                 dma_unmap_single(array[i].dma_addr);
         }
 
-Networking drivers must call dev_kfree_skb to free the socket buffer
+Networking drivers must call dev_kfree_skb() to free the socket buffer
 and return NETDEV_TX_OK if the DMA mapping fails on the transmit hook
 (ndo_start_xmit). This means that the socket buffer is just dropped in
 the failure case.
@@ -831,7 +885,7 @@ transform some example code.
                 DEFINE_DMA_UNMAP_LEN(len);
         };
 
-2) Use dma_unmap_{addr,len}_set to set these values.
+2) Use dma_unmap_{addr,len}_set() to set these values.
    Example, before:
 
         ringp->mapping = FOO;
@@ -842,7 +896,7 @@ transform some example code.
         dma_unmap_addr_set(ringp, mapping, FOO);
         dma_unmap_len_set(ringp, len, BAR);
 
-3) Use dma_unmap_{addr,len} to access these values.
+3) Use dma_unmap_{addr,len}() to access these values.
    Example, before:
 
         dma_unmap_single(dev, ringp->mapping, ringp->len,
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index e865279cec58..52088408668a 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -4,22 +4,26 @@
         James E.J. Bottomley <James.Bottomley@HansenPartnership.com>
 
 This document describes the DMA API.  For a more gentle introduction
-of the API (and actual examples) see
-Documentation/DMA-API-HOWTO.txt.
+of the API (and actual examples), see Documentation/DMA-API-HOWTO.txt.
 
-This API is split into two pieces.  Part I describes the API.  Part II
-describes the extensions to the API for supporting non-consistent
-memory machines.  Unless you know that your driver absolutely has to
-support non-consistent platforms (this is usually only legacy
-platforms) you should only use the API described in part I.
+This API is split into two pieces.  Part I describes the basic API.
+Part II describes extensions for supporting non-consistent memory
+machines.  Unless you know that your driver absolutely has to support
+non-consistent platforms (this is usually only legacy platforms) you
+should only use the API described in part I.
 
 Part I - dma_ API
 -------------------------------------
 
-To get the dma_ API, you must #include <linux/dma-mapping.h>
+To get the dma_ API, you must #include <linux/dma-mapping.h>.  This
+provides dma_addr_t and the interfaces described below.
 
+A dma_addr_t can hold any valid DMA or bus address for the platform.  It
+can be given to a device to use as a DMA source or target.  A CPU cannot
+reference a dma_addr_t directly because there may be translation between
+its physical address space and the bus address space.
 
-Part Ia - Using large dma-coherent buffers
+Part Ia - Using large DMA-coherent buffers
 ------------------------------------------
 
 void *
@@ -33,20 +37,21 @@ to make sure to flush the processor's write buffers before telling
 devices to read that memory.)
 
 This routine allocates a region of <size> bytes of consistent memory.
-It also returns a <dma_handle> which may be cast to an unsigned
-integer the same width as the bus and used as the physical address
-base of the region.
 
-Returns: a pointer to the allocated region (in the processor's virtual
+It returns a pointer to the allocated region (in the processor's virtual
 address space) or NULL if the allocation failed.
 
+It also returns a <dma_handle> which may be cast to an unsigned integer the
+same width as the bus and given to the device as the bus address base of
+the region.
+
 Note: consistent memory can be expensive on some platforms, and the
 minimum allocation length may be as big as a page, so you should
 consolidate your requests for consistent memory as much as possible.
 The simplest way to do that is to use the dma_pool calls (see below).
 
-The flag parameter (dma_alloc_coherent only) allows the caller to
-specify the GFP_ flags (see kmalloc) for the allocation (the
+The flag parameter (dma_alloc_coherent() only) allows the caller to
+specify the GFP_ flags (see kmalloc()) for the allocation (the
 implementation may choose to ignore flags that affect the location of
 the returned memory, like GFP_DMA).
 
@@ -61,24 +66,24 @@ void
 dma_free_coherent(struct device *dev, size_t size, void *cpu_addr,
                            dma_addr_t dma_handle)
 
-Free the region of consistent memory you previously allocated.  dev,
-size and dma_handle must all be the same as those passed into the
-consistent allocate.  cpu_addr must be the virtual address returned by
-the consistent allocate.
+Free a region of consistent memory you previously allocated.  dev,
+size and dma_handle must all be the same as those passed into
+dma_alloc_coherent().  cpu_addr must be the virtual address returned by
+the dma_alloc_coherent().
 
 Note that unlike their sibling allocation calls, these routines
 may only be called with IRQs enabled.
 
 
-Part Ib - Using small dma-coherent buffers
+Part Ib - Using small DMA-coherent buffers
 ------------------------------------------
 
 To get this part of the dma_ API, you must #include <linux/dmapool.h>
 
-Many drivers need lots of small dma-coherent memory regions for DMA
+Many drivers need lots of small DMA-coherent memory regions for DMA
 descriptors or I/O buffers.  Rather than allocating in units of a page
 or more using dma_alloc_coherent(), you can use DMA pools.  These work
-much like a struct kmem_cache, except that they use the dma-coherent allocator,
+much like a struct kmem_cache, except that they use the DMA-coherent allocator,
 not __get_free_pages().  Also, they understand common hardware constraints
 for alignment, like queue heads needing to be aligned on N-byte boundaries.
 
@@ -87,7 +92,7 @@ for alignment, like queue heads needing to be aligned on N-byte boundaries.
         dma_pool_create(const char *name, struct device *dev,
                         size_t size, size_t align, size_t alloc);
 
-The pool create() routines initialize a pool of dma-coherent buffers
+dma_pool_create() initializes a pool of DMA-coherent buffers
 for use with a given device.  It must be called in a context which
 can sleep.
 
@@ -102,25 +107,26 @@ from this pool must not cross 4KByte boundaries.
         void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
                         dma_addr_t *dma_handle);
 
-This allocates memory from the pool; the returned memory will meet the size
-and alignment requirements specified at creation time.  Pass GFP_ATOMIC to
-prevent blocking, or if it's permitted (not in_interrupt, not holding SMP locks),
-pass GFP_KERNEL to allow blocking.  Like dma_alloc_coherent(), this returns
-two values:  an address usable by the cpu, and the dma address usable by the
-pool's device.
+This allocates memory from the pool; the returned memory will meet the
+size and alignment requirements specified at creation time.  Pass
+GFP_ATOMIC to prevent blocking, or if it's permitted (not
+in_interrupt, not holding SMP locks), pass GFP_KERNEL to allow
+blocking.  Like dma_alloc_coherent(), this returns two values:  an
+address usable by the CPU, and the DMA address usable by the pool's
+device.
 
 
         void dma_pool_free(struct dma_pool *pool, void *vaddr,
                         dma_addr_t addr);
 
 This puts memory back into the pool.  The pool is what was passed to
-the pool allocation routine; the cpu (vaddr) and dma addresses are what
+dma_pool_alloc(); the CPU (vaddr) and DMA addresses are what
 were returned when that routine allocated the memory being freed.
 
 
         void dma_pool_destroy(struct dma_pool *pool);
 
-The pool destroy() routines free the resources of the pool.  They must be
+dma_pool_destroy() frees the resources of the pool.  It must be
 called in a context which can sleep.  Make sure you've freed all allocated
 memory back to the pool before you destroy it.
 
@@ -187,9 +193,9 @@ dma_map_single(struct device *dev, void *cpu_addr, size_t size,
                       enum dma_data_direction direction)
 
 Maps a piece of processor virtual memory so it can be accessed by the
-device and returns the physical handle of the memory.
+device and returns the bus address of the memory.
 
-The direction for both api's may be converted freely by casting.
+The direction for both APIs may be converted freely by casting.
 However the dma_ API uses a strongly typed enumerator for its
 direction:
 
@@ -198,31 +204,30 @@ DMA_TO_DEVICE		data is going from the memory to the device
 DMA_FROM_DEVICE         data is coming from the device to the memory
 DMA_BIDIRECTIONAL       direction isn't known
 
-Notes:  Not all memory regions in a machine can be mapped by this
-API.  Further, regions that appear to be physically contiguous in
-kernel virtual space may not be contiguous as physical memory.  Since
-this API does not provide any scatter/gather capability, it will fail
-if the user tries to map a non-physically contiguous piece of memory.
-For this reason, it is recommended that memory mapped by this API be
-obtained only from sources which guarantee it to be physically contiguous
-(like kmalloc).
-
-Further, the physical address of the memory must be within the
-dma_mask of the device (the dma_mask represents a bit mask of the
-addressable region for the device.  I.e., if the physical address of
-the memory anded with the dma_mask is still equal to the physical
-address, then the device can perform DMA to the memory).  In order to
+Notes:  Not all memory regions in a machine can be mapped by this API.
+Further, contiguous kernel virtual space may not be contiguous as
+physical memory.  Since this API does not provide any scatter/gather
+capability, it will fail if the user tries to map a non-physically
+contiguous piece of memory.  For this reason, memory to be mapped by
+this API should be obtained from sources which guarantee it to be
+physically contiguous (like kmalloc).
+
+Further, the bus address of the memory must be within the
+dma_mask of the device (the dma_mask is a bit mask of the
+addressable region for the device, i.e., if the bus address of
+the memory ANDed with the dma_mask is still equal to the bus
+address, then the device can perform DMA to the memory).  To
 ensure that the memory allocated by kmalloc is within the dma_mask,
 the driver may specify various platform-dependent flags to restrict
-the physical memory range of the allocation (e.g. on x86, GFP_DMA
-guarantees to be within the first 16Mb of available physical memory,
+the bus address range of the allocation (e.g., on x86, GFP_DMA
+guarantees to be within the first 16MB of available bus addresses,
 as required by ISA devices).
 
 Note also that the above constraints on physical contiguity and
 dma_mask may not apply if the platform has an IOMMU (a device which
-supplies a physical to virtual mapping between the I/O memory bus and
-the device).  However, to be portable, device driver writers may *not*
-assume that such an IOMMU exists.
+maps an I/O bus address to a physical memory address).  However, to be
+portable, device driver writers may *not* assume that such an IOMMU
+exists.
 
 Warnings:  Memory coherency operates at a granularity called the cache
 line width.  In order for memory mapped by this API to operate
@@ -281,9 +286,9 @@ cache width is.
 int
 dma_mapping_error(struct device *dev, dma_addr_t dma_addr)
 
-In some circumstances dma_map_single and dma_map_page will fail to create
+In some circumstances dma_map_single() and dma_map_page() will fail to create
 a mapping. A driver can check for these errors by testing the returned
-dma address with dma_mapping_error(). A non-zero return value means the mapping
+DMA address with dma_mapping_error(). A non-zero return value means the mapping
 could not be created and the driver should take appropriate action (e.g.
 reduce current DMA mapping usage or delay and try again later).
 
@@ -291,7 +296,7 @@ reduce current DMA mapping usage or delay and try again later).
         dma_map_sg(struct device *dev, struct scatterlist *sg,
                 int nents, enum dma_data_direction direction)
 
-Returns: the number of physical segments mapped (this may be shorter
+Returns: the number of bus address segments mapped (this may be shorter
 than <nents> passed in if some elements of the scatter/gather list are
 physically or virtually adjacent and an IOMMU maps them with a single
 entry).
@@ -299,7 +304,7 @@ entry).
 Please note that the sg cannot be mapped again if it has been mapped once.
 The mapping process is allowed to destroy information in the sg.
 
-As with the other mapping interfaces, dma_map_sg can fail. When it
+As with the other mapping interfaces, dma_map_sg() can fail. When it
 does, 0 is returned and a driver must take appropriate action. It is
 critical that the driver do something, in the case of a block driver
 aborting the request or even oopsing is better than doing nothing and
@@ -335,7 +340,7 @@ must be the same as those and passed in to the scatter/gather mapping
 API.
 
 Note: <nents> must be the number you passed in, *not* the number of
-physical entries returned.
+bus address entries returned.
 
 void
 dma_sync_single_for_cpu(struct device *dev, dma_addr_t dma_handle, size_t size,
@@ -350,7 +355,7 @@ void
 dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
                        enum dma_data_direction direction)
 
-Synchronise a single contiguous or scatter/gather mapping for the cpu
+Synchronise a single contiguous or scatter/gather mapping for the CPU
 and device. With the sync_sg API, all the parameters must be the same
 as those passed into the single mapping API. With the sync_single API,
 you can use dma_handle and size parameters that aren't identical to
@@ -391,10 +396,10 @@ The four functions above are just like the counterpart functions
 without the _attrs suffixes, except that they pass an optional
 struct dma_attrs*.
 
-struct dma_attrs encapsulates a set of "dma attributes". For the
+struct dma_attrs encapsulates a set of "DMA attributes". For the
 definition of struct dma_attrs see linux/dma-attrs.h.
 
-The interpretation of dma attributes is architecture-specific, and
+The interpretation of DMA attributes is architecture-specific, and
 each attribute should be documented in Documentation/DMA-attributes.txt.
 
 If struct dma_attrs* is NULL, the semantics of each of these
@@ -458,7 +463,7 @@ Note: where the platform can return consistent memory, it will
 guarantee that the sync points become nops.
 
 Warning:  Handling non-consistent memory is a real pain.  You should
-only ever use this API if you positively know your driver will be
+only use this API if you positively know your driver will be
 required to work on one of the rare (usually non-PCI) architectures
 that simply cannot make consistent memory.
 
@@ -492,30 +497,29 @@ continuing on for size.  Again, you *must* observe the cache line
 boundaries when doing this.
 
 int
-dma_declare_coherent_memory(struct device *dev, dma_addr_t bus_addr,
+dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr,
                             dma_addr_t device_addr, size_t size, int
                             flags)
 
-Declare region of memory to be handed out by dma_alloc_coherent when
+Declare region of memory to be handed out by dma_alloc_coherent() when
 it's asked for coherent memory for this device.
 
-bus_addr is the physical address to which the memory is currently
-assigned in the bus responding region (this will be used by the
-platform to perform the mapping).
+phys_addr is the CPU physical address to which the memory is currently
+assigned (this will be ioremapped so the CPU can access the region).
 
-device_addr is the physical address the device needs to be programmed
-with actually to address this memory (this will be handed out as the
+device_addr is the bus address the device needs to be programmed
+with to actually address this memory (this will be handed out as the
 dma_addr_t in dma_alloc_coherent()).
 
 size is the size of the area (must be multiples of PAGE_SIZE).
 
-flags can be or'd together and are:
+flags can be ORed together and are:
 
 DMA_MEMORY_MAP - request that the memory returned from
 dma_alloc_coherent() be directly writable.
 
 DMA_MEMORY_IO - request that the memory returned from
-dma_alloc_coherent() be addressable using read/write/memcpy_toio etc.
+dma_alloc_coherent() be addressable using read()/write()/memcpy_toio() etc.
 
 One or both of these flags must be present.
 
@@ -572,7 +576,7 @@ region is occupied.
 Part III - Debug drivers use of the DMA-API
 -------------------------------------------
 
-The DMA-API as described above as some constraints. DMA addresses must be
+The DMA-API as described above has some constraints. DMA addresses must be
 released with the corresponding function with the same size for example. With
 the advent of hardware IOMMUs it becomes more and more important that drivers
 do not violate those constraints. In the worst case such a violation can
@@ -690,11 +694,11 @@ architectural default.
 void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr);
 
 dma-debug interface debug_dma_mapping_error() to debug drivers that fail
-to check dma mapping errors on addresses returned by dma_map_single() and
+to check DMA mapping errors on addresses returned by dma_map_single() and
 dma_map_page() interfaces. This interface clears a flag set by
 debug_dma_map_page() to indicate that dma_mapping_error() has been called by
 the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
 this flag is still set, prints warning message that includes call trace that
 leads up to the unmap. This interface can be called from dma_mapping_error()
-routines to enable dma mapping error check debugging.
+routines to enable DMA mapping error check debugging.
 
diff --git a/Documentation/DMA-ISA-LPC.txt b/Documentation/DMA-ISA-LPC.txt
index e767805b4182..b1a19835e907 100644
--- a/Documentation/DMA-ISA-LPC.txt
+++ b/Documentation/DMA-ISA-LPC.txt
@@ -16,7 +16,7 @@ To do ISA style DMA you need to include two headers:
 #include <asm/dma.h>
 
 The first is the generic DMA API used to convert virtual addresses to
-physical addresses (see Documentation/DMA-API.txt for details).
+bus addresses (see Documentation/DMA-API.txt for details).
 
 The second contains the routines specific to ISA DMA transfers. Since
 this is not present on all platforms make sure you construct your
@@ -50,7 +50,7 @@ early as possible and not release it until the driver is unloaded.)
 Part III - Address translation
 ------------------------------
 
-To translate the virtual address to a physical use the normal DMA
+To translate the virtual address to a bus address, use the normal DMA
 API. Do _not_ use isa_virt_to_phys() even though it does the same
 thing. The reason for this is that the function isa_virt_to_phys()
 will require a Kconfig dependency to ISA, not just ISA_DMA_API which
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index cc2450d80310..18dc52c4f2a0 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -98,5 +98,5 @@ DMA_ATTR_FORCE_CONTIGUOUS
 By default DMA-mapping subsystem is allowed to assemble the buffer
 allocated by dma_alloc_attrs() function from individual pages if it can
 be mapped as contiguous chunk into device dma address space. By
-specifing this attribute the allocated buffer is forced to be contiguous
+specifying this attribute the allocated buffer is forced to be contiguous
 also in physical memory.
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/Makefile b/Documentation/DocBook/Makefile
index b444f2e8fe32..bec06659e0eb 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -14,7 +14,8 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
             genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
             80211.xml debugobjects.xml sh.xml regulator.xml \
             alsa-driver-api.xml writing-an-alsa-driver.xml \
-            tracepoint.xml drm.xml media_api.xml w1.xml
+            tracepoint.xml drm.xml media_api.xml w1.xml \
+            writing_musb_glue_layer.xml
 
 include Documentation/DocBook/media/Makefile
 
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index f5170082bdb3..cc63f30de166 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -276,7 +276,7 @@ X!Isound/sound_firmware.c
      </para>
 
      <sect1><title>Frame Buffer Memory</title>
-!Edrivers/video/fbmem.c
+!Edrivers/video/fbdev/core/fbmem.c
      </sect1>
 <!--
      <sect1><title>Frame Buffer Console</title>
@@ -284,7 +284,7 @@ X!Edrivers/video/console/fbcon.c
      </sect1>
 -->
      <sect1><title>Frame Buffer Colormap</title>
-!Edrivers/video/fbcmap.c
+!Edrivers/video/fbdev/core/fbcmap.c
      </sect1>
 <!-- FIXME:
   drivers/video/fbgen.c has no docs, which stuffs up the sgml.  Comment
@@ -294,11 +294,11 @@ X!Idrivers/video/fbgen.c
      </sect1>
 KAO -->
      <sect1><title>Frame Buffer Video Mode Database</title>
-!Idrivers/video/modedb.c
-!Edrivers/video/modedb.c
+!Idrivers/video/fbdev/core/modedb.c
+!Edrivers/video/fbdev/core/modedb.c
      </sect1>
      <sect1><title>Frame Buffer Macintosh Video Mode Database</title>
-!Edrivers/video/macmodes.c
+!Edrivers/video/fbdev/macmodes.c
      </sect1>
      <sect1><title>Frame Buffer Fonts</title>
         <para>
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index 702c4474919c..7df3134ebc0e 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -79,7 +79,7 @@
   <partintro>
     <para>
       This first part of the DRM Developer's Guide documents core DRM code,
-      helper libraries for writting drivers and generic userspace interfaces
+      helper libraries for writing drivers and generic userspace interfaces
       exposed by DRM drivers.
     </para>
   </partintro>
@@ -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.
@@ -459,7 +487,7 @@ char *date;</synopsis>
       providing a solution to every graphics memory-related problems, GEM
       identified common code between drivers and created a support library to
       share it. GEM has simpler initialization and execution requirements than
-      TTM, but has no video RAM management capabitilies and is thus limited to
+      TTM, but has no video RAM management capabilities and is thus limited to
       UMA devices.
     </para>
     <sect2>
@@ -889,7 +917,7 @@ int (*prime_fd_to_handle)(struct drm_device *dev,
             vice versa. Drivers must use the kernel dma-buf buffer sharing framework
             to manage the PRIME file descriptors. Similar to the mode setting
             API PRIME is agnostic to the underlying buffer object manager, as
-            long as handles are 32bit unsinged integers.
+            long as handles are 32bit unsigned integers.
           </para>
           <para>
             While non-GEM drivers must implement the operations themselves, GEM
@@ -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
-            <methodname>mode_valid</methodname> helper operation for  each mode in
+            if specified. It then calls the optional connector
+            <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
@@ -2287,6 +2321,11 @@ void intel_crt_init(struct drm_device *dev)
 !Edrivers/gpu/drm/drm_crtc_helper.c
     </sect2>
     <sect2>
+      <title>Output Probing Helper Functions Reference</title>
+!Pdrivers/gpu/drm/drm_probe_helper.c output probing helper overview
+!Edrivers/gpu/drm/drm_probe_helper.c
+    </sect2>
+    <sect2>
       <title>fbdev Helper Functions Reference</title>
 !Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
 !Edrivers/gpu/drm/drm_fb_helper.c
@@ -2351,7 +2390,7 @@ void intel_crt_init(struct drm_device *dev)
       first create properties and then create and associate individual instances
       of those properties to objects. A property can be instantiated multiple
       times and associated with different objects. Values are stored in property
-      instances, and all other property information are stored in the propery
+      instances, and all other property information are stored in the property
       and shared between all instances of the property.
     </para>
     <para>
@@ -2445,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 -->
@@ -2522,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 -->
@@ -2692,10 +3592,10 @@ int num_ioctls;</synopsis>
   <sect1>
     <title>Legacy Support Code</title>
     <para>
-      The section very brievely covers some of the old legacy support code which
+      The section very briefly covers some of the old legacy support code which
       is only used by old DRM drivers which have done a so-called shadow-attach
       to the underlying device instead of registering as a real driver. This
-      also includes some of the old generic buffer mangement and command
+      also includes some of the old generic buffer management and command
       submission code. Do not use any of this in new and modern drivers.
     </para>
 
@@ -2864,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
-                after mode setting, since on many devices the vertical blank
-                counter is reset at that time.  Internally, the DRM snapshots
-                the last vblank count when the ioctl is called with the
-                _DRM_PRE_MODESET command, so that the counter won't go backwards
-                (which is dealt with when _DRM_POST_MODESET is used).
+                This was only used for user-mode-settind drivers around
+                modesetting changes to allow the kernel to update the vblank
+                interrupt after mode setting, since on many devices the vertical
+                blank counter is reset to 0 at some point during modeset. Modern
+                drivers should not call this any more since with kernel mode
+                setting it is a no-op.
               </para>
             </listitem>
           </varlistentry>
         </variablelist>
-<!--!Edrivers/char/drm/drm_irq.c-->
       </para>
     </sect1>
 
@@ -2937,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>
@@ -2945,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/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl
index 4f676838da06..bcdfdb9a9277 100644
--- a/Documentation/DocBook/filesystems.tmpl
+++ b/Documentation/DocBook/filesystems.tmpl
@@ -62,7 +62,7 @@
 !Efs/mpage.c
 !Efs/namei.c
 !Efs/buffer.c
-!Efs/bio.c
+!Eblock/bio.c
 !Efs/seq_file.c
 !Efs/filesystems.c
 !Efs/fs-writeback.c
diff --git a/Documentation/DocBook/media/Makefile b/Documentation/DocBook/media/Makefile
index f9fd615427fb..1d27f0a1abd1 100644
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -195,7 +195,7 @@ DVB_DOCUMENTED = \
 #
 
 install_media_images = \
-        $(Q)cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
+        $(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
 
 $(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
         $(Q)base64 -d $< >$@
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 97a69bf6f3eb..a086a5db7a18 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -125,7 +125,7 @@ location of the buffers in device memory can be determined with the
 <structfield>m.offset</structfield> and <structfield>length</structfield>
 returned in a &v4l2-buffer; are passed as sixth and second parameter to the
 <function>mmap()</function> function. When using the multi-planar API,
-struct &v4l2-buffer; contains an array of &v4l2-plane; structures, each
+&v4l2-buffer; contains an array of &v4l2-plane; structures, each
 containing its own <structfield>m.offset</structfield> and
 <structfield>length</structfield>. When using the multi-planar API, every
 plane of every buffer has to be mapped separately, so the number of
@@ -699,7 +699,12 @@ linkend="v4l2-buf-type" /></entry>
 buffer. It depends on the negotiated data format and may change with
 each buffer for compressed variable size data like JPEG images.
 Drivers must set this field when <structfield>type</structfield>
-refers to an input stream, applications when it refers to an output stream.</entry>
+refers to an input stream, applications when it refers to an output stream.
+If the application sets this to 0 for an output stream, then
+<structfield>bytesused</structfield> will be set to the size of the
+buffer (see the <structfield>length</structfield> field of this struct) by
+the driver. For multiplanar formats this field is ignored and the
+<structfield>planes</structfield> pointer is used instead.</entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -861,7 +866,11 @@ should set this to 0.</entry>
             <entry></entry>
             <entry>The number of bytes occupied by data in the plane
               (its payload). Drivers must set this field when <structfield>type</structfield>
-              refers to an input stream, applications when it refers to an output stream.</entry>
+              refers to an input stream, applications when it refers to an output stream.
+              If the application sets this to 0 for an output stream, then
+              <structfield>bytesused</structfield> will be set to the size of the
+              plane (see the <structfield>length</structfield> field of this struct)
+              by the driver.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
index cf8548556c7d..74fb394ec667 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-links.xml
@@ -79,13 +79,13 @@
             <entry>Entity id, set by the application.</entry>
           </row>
           <row>
-            <entry>struct &media-pad-desc;</entry>
+            <entry>&media-pad-desc;</entry>
             <entry>*<structfield>pads</structfield></entry>
             <entry>Pointer to a pads array allocated by the application. Ignored
             if NULL.</entry>
           </row>
           <row>
-            <entry>struct &media-link-desc;</entry>
+            <entry>&media-link-desc;</entry>
             <entry>*<structfield>links</structfield></entry>
             <entry>Pointer to a links array allocated by the application. Ignored
             if NULL.</entry>
@@ -153,12 +153,12 @@
         &cs-str;
         <tbody valign="top">
           <row>
-            <entry>struct &media-pad-desc;</entry>
+            <entry>&media-pad-desc;</entry>
             <entry><structfield>source</structfield></entry>
             <entry>Pad at the origin of this link.</entry>
           </row>
           <row>
-            <entry>struct &media-pad-desc;</entry>
+            <entry>&media-pad-desc;</entry>
             <entry><structfield>sink</structfield></entry>
             <entry>Pad at the target of this link.</entry>
           </row>
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index ea514d6075c5..91dcbc84f3f8 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -772,7 +772,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
           </row>
           <row id="V4L2-PIX-FMT-H264-MVC">
                 <entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry>
-                <entry>'MVC'</entry>
+                <entry>'M264'</entry>
                 <entry>H264 MVC video elementary stream.</entry>
           </row>
           <row id="V4L2-PIX-FMT-H263">
@@ -812,7 +812,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
           </row>
           <row id="V4L2-PIX-FMT-VP8">
                 <entry><constant>V4L2_PIX_FMT_VP8</constant></entry>
-                <entry>'VP8'</entry>
+                <entry>'VP80'</entry>
                 <entry>VP8 video elementary stream.</entry>
           </row>
         </tbody>
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 7331ce116f4c..b2d5a0363cba 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -1898,6 +1898,134 @@
               <entry>y<subscript>1</subscript></entry>
               <entry>y<subscript>0</subscript></entry>
             </row>
+            <row id="V4L2-MBUS-FMT-UYVY10-2X10">
+              <entry>V4L2_MBUS_FMT_UYVY10_2X10</entry>
+              <entry>0x2018</entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-VYUY10-2X10">
+              <entry>V4L2_MBUS_FMT_VYUY10_2X10</entry>
+              <entry>0x2019</entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-22;
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
             <row id="V4L2-MBUS-FMT-YUYV10-2X10">
               <entry>V4L2_MBUS_FMT_YUYV10_2X10</entry>
               <entry>0x200b</entry>
@@ -2308,6 +2436,110 @@
               <entry>v<subscript>1</subscript></entry>
               <entry>v<subscript>0</subscript></entry>
             </row>
+            <row id="V4L2-MBUS-FMT-UYVY10-1X20">
+              <entry>V4L2_MBUS_FMT_UYVY10_1X20</entry>
+              <entry>0x201a</entry>
+              <entry></entry>
+              &dash-ent-12;
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-12;
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-VYUY10-1X20">
+              <entry>V4L2_MBUS_FMT_VYUY10_1X20</entry>
+              <entry>0x201b</entry>
+              <entry></entry>
+              &dash-ent-12;
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-12;
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
             <row id="V4L2-MBUS-FMT-YUYV10-1X20">
               <entry>V4L2_MBUS_FMT_YUYV10_1X20</entry>
               <entry>0x200d</entry>
@@ -2486,6 +2718,534 @@
               <entry>v<subscript>1</subscript></entry>
               <entry>v<subscript>0</subscript></entry>
             </row>
+            <row id="V4L2-MBUS-FMT-UYVY12-2X12">
+              <entry>V4L2_MBUS_FMT_UYVY12_2X12</entry>
+              <entry>0x201c</entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-VYUY12-2X12">
+              <entry>V4L2_MBUS_FMT_VYUY12_2X12</entry>
+              <entry>0x201d</entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-YUYV12-2X12">
+              <entry>V4L2_MBUS_FMT_YUYV12_2X12</entry>
+              <entry>0x201e</entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-YVYU12-2X12">
+              <entry>V4L2_MBUS_FMT_YVYU12_2X12</entry>
+              <entry>0x201f</entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-20;
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-UYVY12-1X24">
+              <entry>V4L2_MBUS_FMT_UYVY12_1X24</entry>
+              <entry>0x2020</entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-VYUY12-1X24">
+              <entry>V4L2_MBUS_FMT_VYUY12_1X24</entry>
+              <entry>0x2021</entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-YUYV12-1X24">
+              <entry>V4L2_MBUS_FMT_YUYV12_1X24</entry>
+              <entry>0x2022</entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row id="V4L2-MBUS-FMT-YVYU12-1X24">
+              <entry>V4L2_MBUS_FMT_YVYU12_1X24</entry>
+              <entry>0x2023</entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>v<subscript>11</subscript></entry>
+              <entry>v<subscript>10</subscript></entry>
+              <entry>v<subscript>9</subscript></entry>
+              <entry>v<subscript>8</subscript></entry>
+              <entry>v<subscript>7</subscript></entry>
+              <entry>v<subscript>6</subscript></entry>
+              <entry>v<subscript>5</subscript></entry>
+              <entry>v<subscript>4</subscript></entry>
+              <entry>v<subscript>3</subscript></entry>
+              <entry>v<subscript>2</subscript></entry>
+              <entry>v<subscript>1</subscript></entry>
+              <entry>v<subscript>0</subscript></entry>
+            </row>
+            <row>
+              <entry></entry>
+              <entry></entry>
+              <entry></entry>
+              &dash-ent-8;
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+              <entry>u<subscript>11</subscript></entry>
+              <entry>u<subscript>10</subscript></entry>
+              <entry>u<subscript>9</subscript></entry>
+              <entry>u<subscript>8</subscript></entry>
+              <entry>u<subscript>7</subscript></entry>
+              <entry>u<subscript>6</subscript></entry>
+              <entry>u<subscript>5</subscript></entry>
+              <entry>u<subscript>4</subscript></entry>
+              <entry>u<subscript>3</subscript></entry>
+              <entry>u<subscript>2</subscript></entry>
+              <entry>u<subscript>1</subscript></entry>
+              <entry>u<subscript>0</subscript></entry>
+            </row>
           </tbody>
         </tgroup>
       </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
index 89891adb928a..820f86e8744b 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -242,6 +242,22 @@
       </tgroup>
     </table>
 
+    <table frame="none" pgwide="1" id="v4l2-event-src-change">
+      <title>struct <structname>v4l2_event_src_change</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>changes</structfield></entry>
+            <entry>
+              A bitmask that tells what has changed. See <xref linkend="src-changes-flags" />.
+            </entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
     <table pgwide="1" frame="none" id="changes-flags">
       <title>Changes</title>
       <tgroup cols="3">
@@ -270,6 +286,23 @@
         </tbody>
       </tgroup>
     </table>
+
+    <table pgwide="1" frame="none" id="src-changes-flags">
+      <title>Source Changes</title>
+      <tgroup cols="3">
+        &cs-def;
+        <tbody valign="top">
+          <row>
+            <entry><constant>V4L2_EVENT_SRC_CH_RESOLUTION</constant></entry>
+            <entry>0x0001</entry>
+            <entry>This event gets triggered when a resolution change is
+            detected at an input. This can come from an input connector or
+            from a video decoder.
+            </entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
   </refsect1>
   <refsect1>
     &return-value;
diff --git a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
index cd7720d404ea..28a8c1e1c705 100644
--- a/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dv-timings-cap.xml
@@ -1,11 +1,12 @@
 <refentry id="vidioc-dv-timings-cap">
   <refmeta>
-    <refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP</refentrytitle>
+    <refentrytitle>ioctl VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP</refentrytitle>
     &manvol;
   </refmeta>
 
   <refnamediv>
     <refname>VIDIOC_DV_TIMINGS_CAP</refname>
+    <refname>VIDIOC_SUBDEV_DV_TIMINGS_CAP</refname>
     <refpurpose>The capabilities of the Digital Video receiver/transmitter</refpurpose>
   </refnamediv>
 
@@ -33,7 +34,7 @@
       <varlistentry>
         <term><parameter>request</parameter></term>
         <listitem>
-          <para>VIDIOC_DV_TIMINGS_CAP</para>
+          <para>VIDIOC_DV_TIMINGS_CAP, VIDIOC_SUBDEV_DV_TIMINGS_CAP</para>
         </listitem>
       </varlistentry>
       <varlistentry>
@@ -54,10 +55,19 @@
       interface and may change in the future.</para>
     </note>
 
-    <para>To query the capabilities of the DV receiver/transmitter applications can call
-this ioctl and the driver will fill in the structure. Note that drivers may return
+    <para>To query the capabilities of the DV receiver/transmitter applications
+can call the <constant>VIDIOC_DV_TIMINGS_CAP</constant> ioctl on a video node
+and the driver will fill in the structure. Note that drivers may return
 different values after switching the video input or output.</para>
 
+    <para>When implemented by the driver DV capabilities of subdevices can be
+queried by calling the <constant>VIDIOC_SUBDEV_DV_TIMINGS_CAP</constant> ioctl
+directly on a subdevice node. The capabilities are specific to inputs (for DV
+receivers) or outputs (for DV transmitters), applications must specify the
+desired pad number in the &v4l2-dv-timings-cap; <structfield>pad</structfield>
+field. Attempts to query capabilities on a pad that doesn't support them will
+return an &EINVAL;.</para>
+
     <table pgwide="1" frame="none" id="v4l2-bt-timings-cap">
       <title>struct <structname>v4l2_bt_timings_cap</structname></title>
       <tgroup cols="3">
@@ -127,7 +137,14 @@ different values after switching the video input or output.</para>
           </row>
           <row>
             <entry>__u32</entry>
-            <entry><structfield>reserved</structfield>[3]</entry>
+            <entry><structfield>pad</structfield></entry>
+            <entry>Pad number as reported by the media controller API. This field
+            is only used when operating on a subdevice node. When operating on a
+            video node applications must set this field to zero.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[2]</entry>
             <entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
           </row>
           <row>
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
index b3e17c1dfaf5..b9fdfeacdbcb 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enum-dv-timings.xml
@@ -1,11 +1,12 @@
 <refentry id="vidioc-enum-dv-timings">
   <refmeta>
-    <refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS</refentrytitle>
+    <refentrytitle>ioctl VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS</refentrytitle>
     &manvol;
   </refmeta>
 
   <refnamediv>
     <refname>VIDIOC_ENUM_DV_TIMINGS</refname>
+    <refname>VIDIOC_SUBDEV_ENUM_DV_TIMINGS</refname>
     <refpurpose>Enumerate supported Digital Video timings</refpurpose>
   </refnamediv>
 
@@ -33,7 +34,7 @@
       <varlistentry>
         <term><parameter>request</parameter></term>
         <listitem>
-          <para>VIDIOC_ENUM_DV_TIMINGS</para>
+          <para>VIDIOC_ENUM_DV_TIMINGS, VIDIOC_SUBDEV_ENUM_DV_TIMINGS</para>
         </listitem>
       </varlistentry>
       <varlistentry>
@@ -61,14 +62,21 @@ standards or even custom timings that are not in this list.</para>
 
     <para>To query the available timings, applications initialize the
 <structfield>index</structfield> field and zero the reserved array of &v4l2-enum-dv-timings;
-and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl with a pointer to this
-structure. Drivers fill the rest of the structure or return an
+and call the <constant>VIDIOC_ENUM_DV_TIMINGS</constant> ioctl on a video node with a
+pointer to this structure. Drivers fill the rest of the structure or return an
 &EINVAL; when the index is out of bounds. To enumerate all supported DV timings,
 applications shall begin at index zero, incrementing by one until the
 driver returns <errorcode>EINVAL</errorcode>. Note that drivers may enumerate a
 different set of DV timings after switching the video input or
 output.</para>
 
+    <para>When implemented by the driver DV timings of subdevices can be queried
+by calling the <constant>VIDIOC_SUBDEV_ENUM_DV_TIMINGS</constant> ioctl directly
+on a subdevice node. The DV timings are specific to inputs (for DV receivers) or
+outputs (for DV transmitters), applications must specify the desired pad number
+in the &v4l2-enum-dv-timings; <structfield>pad</structfield> field. Attempts to
+enumerate timings on a pad that doesn't support them will return an &EINVAL;.</para>
+
     <table pgwide="1" frame="none" id="v4l2-enum-dv-timings">
       <title>struct <structname>v4l2_enum_dv_timings</structname></title>
       <tgroup cols="3">
@@ -82,8 +90,16 @@ application.</entry>
           </row>
           <row>
             <entry>__u32</entry>
-            <entry><structfield>reserved</structfield>[3]</entry>
-            <entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
+            <entry><structfield>pad</structfield></entry>
+            <entry>Pad number as reported by the media controller API. This field
+            is only used when operating on a subdevice node. When operating on a
+            video node applications must set this field to zero.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[2]</entry>
+            <entry>Reserved for future extensions. Drivers and applications must
+            set the array to zero.</entry>
           </row>
           <row>
             <entry>&v4l2-dv-timings;</entry>
@@ -103,7 +119,7 @@ application.</entry>
         <term><errorcode>EINVAL</errorcode></term>
         <listitem>
           <para>The &v4l2-enum-dv-timings; <structfield>index</structfield>
-is out of bounds.</para>
+is out of bounds or the <structfield>pad</structfield> number is invalid.</para>
         </listitem>
       </varlistentry>
       <varlistentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
index 5c70b616d818..17efa870d4d2 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -155,6 +155,26 @@
             </entry>
           </row>
           <row>
+            <entry><constant>V4L2_EVENT_SOURCE_CHANGE</constant></entry>
+            <entry>5</entry>
+            <entry>
+              <para>This event is triggered when a source parameter change is
+               detected during runtime by the video device. It can be a
+               runtime resolution change triggered by a video decoder or the
+               format change happening on an input connector.
+               This event requires that the <structfield>id</structfield>
+               matches the input index (when used with a video device node)
+               or the pad index (when used with a subdevice node) from which
+               you want to receive events.</para>
+
+              <para>This event has a &v4l2-event-src-change; associated
+              with it. The <structfield>changes</structfield> bitfield denotes
+              what has changed for the subscribed pad. If multiple events
+              occurred before application could dequeue them, then the changes
+              will have the ORed value of all the events generated.</para>
+            </entry>
+          </row>
+          <row>
             <entry><constant>V4L2_EVENT_PRIVATE_START</constant></entry>
             <entry>0x08000000</entry>
             <entry>Base event number for driver-private events.</entry>
diff --git a/Documentation/DocBook/writing_musb_glue_layer.tmpl b/Documentation/DocBook/writing_musb_glue_layer.tmpl
new file mode 100644
index 000000000000..837eca77f274
--- /dev/null
+++ b/Documentation/DocBook/writing_musb_glue_layer.tmpl
@@ -0,0 +1,873 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+        "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+
+<book id="Writing-MUSB-Glue-Layer">
+ <bookinfo>
+  <title>Writing an MUSB Glue Layer</title>
+
+  <authorgroup>
+   <author>
+    <firstname>Apelete</firstname>
+    <surname>Seketeli</surname>
+    <affiliation>
+     <address>
+      <email>apelete at seketeli.net</email>
+     </address>
+    </affiliation>
+   </author>
+  </authorgroup>
+
+  <copyright>
+   <year>2014</year>
+   <holder>Apelete Seketeli</holder>
+  </copyright>
+
+  <legalnotice>
+   <para>
+     This documentation 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.
+   </para>
+
+   <para>
+     This documentation 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.
+   </para>
+
+   <para>
+     You should have received a copy of the GNU General Public License
+     along with this documentation; if not, write to the Free Software
+     Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA
+     02111-1307 USA
+   </para>
+
+   <para>
+     For more details see the file COPYING in the Linux kernel source
+     tree.
+   </para>
+  </legalnotice>
+ </bookinfo>
+
+<toc></toc>
+
+  <chapter id="introduction">
+    <title>Introduction</title>
+    <para>
+      The Linux MUSB subsystem is part of the larger Linux USB
+      subsystem. It provides support for embedded USB Device Controllers
+      (UDC) that do not use Universal Host Controller Interface (UHCI)
+      or Open Host Controller Interface (OHCI).
+    </para>
+    <para>
+      Instead, these embedded UDC rely on the USB On-the-Go (OTG)
+      specification which they implement at least partially. The silicon
+      reference design used in most cases is the Multipoint USB
+      Highspeed Dual-Role Controller (MUSB HDRC) found in the Mentor
+      Graphics Inventra™ design.
+    </para>
+    <para>
+      As a self-taught exercise I have written an MUSB glue layer for
+      the Ingenic JZ4740 SoC, modelled after the many MUSB glue layers
+      in the kernel source tree. This layer can be found at
+      drivers/usb/musb/jz4740.c. In this documentation I will walk
+      through the basics of the jz4740.c glue layer, explaining the
+      different pieces and what needs to be done in order to write your
+      own device glue layer.
+    </para>
+  </chapter>
+
+  <chapter id="linux-musb-basics">
+    <title>Linux MUSB Basics</title>
+    <para>
+      To get started on the topic, please read USB On-the-Go Basics (see
+      Resources) which provides an introduction of USB OTG operation at
+      the hardware level. A couple of wiki pages by Texas Instruments
+      and Analog Devices also provide an overview of the Linux kernel
+      MUSB configuration, albeit focused on some specific devices
+      provided by these companies. Finally, getting acquainted with the
+      USB specification at USB home page may come in handy, with
+      practical instance provided through the Writing USB Device Drivers
+      documentation (again, see Resources).
+    </para>
+    <para>
+      Linux USB stack is a layered architecture in which the MUSB
+      controller hardware sits at the lowest. The MUSB controller driver
+      abstract the MUSB controller hardware to the Linux USB stack.
+    </para>
+    <programlisting>
+      ------------------------
+      |                      | &lt;------- drivers/usb/gadget
+      | Linux USB Core Stack | &lt;------- drivers/usb/host
+      |                      | &lt;------- drivers/usb/core
+      ------------------------
+                 ⬍
+     --------------------------
+     |                        | &lt;------ drivers/usb/musb/musb_gadget.c
+     | MUSB Controller driver | &lt;------ drivers/usb/musb/musb_host.c
+     |                        | &lt;------ drivers/usb/musb/musb_core.c
+     --------------------------
+                 ⬍
+  ---------------------------------
+  | MUSB Platform Specific Driver |
+  |                               | &lt;-- drivers/usb/musb/jz4740.c
+  |       aka &quot;Glue Layer&quot;        |
+  ---------------------------------
+                 ⬍
+  ---------------------------------
+  |   MUSB Controller Hardware    |
+  ---------------------------------
+    </programlisting>
+    <para>
+      As outlined above, the glue layer is actually the platform
+      specific code sitting in between the controller driver and the
+      controller hardware.
+    </para>
+    <para>
+      Just like a Linux USB driver needs to register itself with the
+      Linux USB subsystem, the MUSB glue layer needs first to register
+      itself with the MUSB controller driver. This will allow the
+      controller driver to know about which device the glue layer
+      supports and which functions to call when a supported device is
+      detected or released; remember we are talking about an embedded
+      controller chip here, so no insertion or removal at run-time.
+    </para>
+    <para>
+      All of this information is passed to the MUSB controller driver
+      through a platform_driver structure defined in the glue layer as:
+    </para>
+    <programlisting linenumbering="numbered">
+static struct platform_driver jz4740_driver = {
+        .probe          = jz4740_probe,
+        .remove         = jz4740_remove,
+        .driver         = {
+                .name   = "musb-jz4740",
+        },
+};
+    </programlisting>
+    <para>
+      The probe and remove function pointers are called when a matching
+      device is detected and, respectively, released. The name string
+      describes the device supported by this glue layer. In the current
+      case it matches a platform_device structure declared in
+      arch/mips/jz4740/platform.c. Note that we are not using device
+      tree bindings here.
+    </para>
+    <para>
+      In order to register itself to the controller driver, the glue
+      layer goes through a few steps, basically allocating the
+      controller hardware resources and initialising a couple of
+      circuits. To do so, it needs to keep track of the information used
+      throughout these steps. This is done by defining a private
+      jz4740_glue structure:
+    </para>
+    <programlisting linenumbering="numbered">
+struct jz4740_glue {
+        struct device           *dev;
+        struct platform_device  *musb;
+        struct clk              *clk;
+};
+    </programlisting>
+    <para>
+      The dev and musb members are both device structure variables. The
+      first one holds generic information about the device, since it's
+      the basic device structure, and the latter holds information more
+      closely related to the subsystem the device is registered to. The
+      clk variable keeps information related to the device clock
+      operation.
+    </para>
+    <para>
+      Let's go through the steps of the probe function that leads the
+      glue layer to register itself to the controller driver.
+    </para>
+    <para>
+      N.B.: For the sake of readability each function will be split in
+      logical parts, each part being shown as if it was independent from
+      the others.
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_probe(struct platform_device *pdev)
+{
+        struct platform_device          *musb;
+        struct jz4740_glue              *glue;
+        struct clk                      *clk;
+        int                             ret;
+
+        glue = devm_kzalloc(&amp;pdev->dev, sizeof(*glue), GFP_KERNEL);
+        if (!glue)
+                return -ENOMEM;
+
+        musb = platform_device_alloc("musb-hdrc", PLATFORM_DEVID_AUTO);
+        if (!musb) {
+                dev_err(&amp;pdev->dev, "failed to allocate musb device\n");
+                return -ENOMEM;
+        }
+
+        clk = devm_clk_get(&amp;pdev->dev, "udc");
+        if (IS_ERR(clk)) {
+                dev_err(&amp;pdev->dev, "failed to get clock\n");
+                ret = PTR_ERR(clk);
+                goto err_platform_device_put;
+        }
+
+        ret = clk_prepare_enable(clk);
+        if (ret) {
+                dev_err(&amp;pdev->dev, "failed to enable clock\n");
+                goto err_platform_device_put;
+        }
+
+        musb->dev.parent                = &amp;pdev->dev;
+
+        glue->dev                       = &amp;pdev->dev;
+        glue->musb                      = musb;
+        glue->clk                       = clk;
+
+        return 0;
+
+err_platform_device_put:
+        platform_device_put(musb);
+        return ret;
+}
+    </programlisting>
+    <para>
+      The first few lines of the probe function allocate and assign the
+      glue, musb and clk variables. The GFP_KERNEL flag (line 8) allows
+      the allocation process to sleep and wait for memory, thus being
+      usable in a blocking situation. The PLATFORM_DEVID_AUTO flag (line
+      12) allows automatic allocation and management of device IDs in
+      order to avoid device namespace collisions with explicit IDs. With
+      devm_clk_get() (line 18) the glue layer allocates the clock -- the
+      <literal>devm_</literal> prefix indicates that clk_get() is
+      managed: it automatically frees the allocated clock resource data
+      when the device is released -- and enable it.
+    </para>
+    <para>
+      Then comes the registration steps:
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_probe(struct platform_device *pdev)
+{
+        struct musb_hdrc_platform_data  *pdata = &amp;jz4740_musb_platform_data;
+
+        pdata->platform_ops             = &amp;jz4740_musb_ops;
+
+        platform_set_drvdata(pdev, glue);
+
+        ret = platform_device_add_resources(musb, pdev->resource,
+                                            pdev->num_resources);
+        if (ret) {
+                dev_err(&amp;pdev->dev, "failed to add resources\n");
+                goto err_clk_disable;
+        }
+
+        ret = platform_device_add_data(musb, pdata, sizeof(*pdata));
+        if (ret) {
+                dev_err(&amp;pdev->dev, "failed to add platform_data\n");
+                goto err_clk_disable;
+        }
+
+        return 0;
+
+err_clk_disable:
+        clk_disable_unprepare(clk);
+err_platform_device_put:
+        platform_device_put(musb);
+        return ret;
+}
+    </programlisting>
+    <para>
+      The first step is to pass the device data privately held by the
+      glue layer on to the controller driver through
+      platform_set_drvdata() (line 7). Next is passing on the device
+      resources information, also privately held at that point, through
+      platform_device_add_resources() (line 9).
+    </para>
+    <para>
+      Finally comes passing on the platform specific data to the
+      controller driver (line 16). Platform data will be discussed in
+      <link linkend="device-platform-data">Chapter 4</link>, but here
+      we are looking at the platform_ops function pointer (line 5) in
+      musb_hdrc_platform_data structure (line 3).  This function
+      pointer allows the MUSB controller driver to know which function
+      to call for device operation:
+    </para>
+    <programlisting linenumbering="numbered">
+static const struct musb_platform_ops jz4740_musb_ops = {
+        .init           = jz4740_musb_init,
+        .exit           = jz4740_musb_exit,
+};
+    </programlisting>
+    <para>
+      Here we have the minimal case where only init and exit functions
+      are called by the controller driver when needed. Fact is the
+      JZ4740 MUSB controller is a basic controller, lacking some
+      features found in other controllers, otherwise we may also have
+      pointers to a few other functions like a power management function
+      or a function to switch between OTG and non-OTG modes, for
+      instance.
+    </para>
+    <para>
+      At that point of the registration process, the controller driver
+      actually calls the init function:
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_musb_init(struct musb *musb)
+{
+        musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+        if (!musb->xceiv) {
+                pr_err("HS UDC: no transceiver configured\n");
+                return -ENODEV;
+        }
+
+        /* Silicon does not implement ConfigData register.
+         * Set dyn_fifo to avoid reading EP config from hardware.
+         */
+        musb->dyn_fifo = true;
+
+        musb->isr = jz4740_musb_interrupt;
+
+        return 0;
+}
+    </programlisting>
+    <para>
+      The goal of jz4740_musb_init() is to get hold of the transceiver
+      driver data of the MUSB controller hardware and pass it on to the
+      MUSB controller driver, as usual. The transceiver is the circuitry
+      inside the controller hardware responsible for sending/receiving
+      the USB data. Since it is an implementation of the physical layer
+      of the OSI model, the transceiver is also referred to as PHY.
+    </para>
+    <para>
+      Getting hold of the MUSB PHY driver data is done with
+      usb_get_phy() which returns a pointer to the structure
+      containing the driver instance data. The next couple of
+      instructions (line 12 and 14) are used as a quirk and to setup
+      IRQ handling respectively. Quirks and IRQ handling will be
+      discussed later in <link linkend="device-quirks">Chapter
+      5</link> and <link linkend="handling-irqs">Chapter 3</link>.
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_musb_exit(struct musb *musb)
+{
+        usb_put_phy(musb->xceiv);
+
+        return 0;
+}
+    </programlisting>
+    <para>
+      Acting as the counterpart of init, the exit function releases the
+      MUSB PHY driver when the controller hardware itself is about to be
+      released.
+    </para>
+    <para>
+      Again, note that init and exit are fairly simple in this case due
+      to the basic set of features of the JZ4740 controller hardware.
+      When writing an musb glue layer for a more complex controller
+      hardware, you might need to take care of more processing in those
+      two functions.
+    </para>
+    <para>
+      Returning from the init function, the MUSB controller driver jumps
+      back into the probe function:
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_probe(struct platform_device *pdev)
+{
+        ret = platform_device_add(musb);
+        if (ret) {
+                dev_err(&amp;pdev->dev, "failed to register musb device\n");
+                goto err_clk_disable;
+        }
+
+        return 0;
+
+err_clk_disable:
+        clk_disable_unprepare(clk);
+err_platform_device_put:
+        platform_device_put(musb);
+        return ret;
+}
+    </programlisting>
+    <para>
+      This is the last part of the device registration process where the
+      glue layer adds the controller hardware device to Linux kernel
+      device hierarchy: at this stage, all known information about the
+      device is passed on to the Linux USB core stack.
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_remove(struct platform_device *pdev)
+{
+        struct jz4740_glue      *glue = platform_get_drvdata(pdev);
+
+        platform_device_unregister(glue->musb);
+        clk_disable_unprepare(glue->clk);
+
+        return 0;
+}
+    </programlisting>
+    <para>
+      Acting as the counterpart of probe, the remove function unregister
+      the MUSB controller hardware (line 5) and disable the clock (line
+      6), allowing it to be gated.
+    </para>
+  </chapter>
+
+  <chapter id="handling-irqs">
+    <title>Handling IRQs</title>
+    <para>
+      Additionally to the MUSB controller hardware basic setup and
+      registration, the glue layer is also responsible for handling the
+      IRQs:
+    </para>
+    <programlisting linenumbering="numbered">
+static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci)
+{
+        unsigned long   flags;
+        irqreturn_t     retval = IRQ_NONE;
+        struct musb     *musb = __hci;
+
+        spin_lock_irqsave(&amp;musb->lock, flags);
+
+        musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
+        musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
+        musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
+
+        /*
+         * The controller is gadget only, the state of the host mode IRQ bits is
+         * undefined. Mask them to make sure that the musb driver core will
+         * never see them set
+         */
+        musb->int_usb &amp;= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME |
+            MUSB_INTR_RESET | MUSB_INTR_SOF;
+
+        if (musb->int_usb || musb->int_tx || musb->int_rx)
+                retval = musb_interrupt(musb);
+
+        spin_unlock_irqrestore(&amp;musb->lock, flags);
+
+        return retval;
+}
+    </programlisting>
+    <para>
+      Here the glue layer mostly has to read the relevant hardware
+      registers and pass their values on to the controller driver which
+      will handle the actual event that triggered the IRQ.
+    </para>
+    <para>
+      The interrupt handler critical section is protected by the
+      spin_lock_irqsave() and counterpart spin_unlock_irqrestore()
+      functions (line 7 and 24 respectively), which prevent the
+      interrupt handler code to be run by two different threads at the
+      same time.
+    </para>
+    <para>
+      Then the relevant interrupt registers are read (line 9 to 11):
+    </para>
+    <itemizedlist>
+      <listitem>
+        <para>
+          MUSB_INTRUSB: indicates which USB interrupts are currently
+          active,
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          MUSB_INTRTX: indicates which of the interrupts for TX
+          endpoints are currently active,
+        </para>
+      </listitem>
+      <listitem>
+        <para>
+          MUSB_INTRRX: indicates which of the interrupts for TX
+          endpoints are currently active.
+        </para>
+      </listitem>
+    </itemizedlist>
+    <para>
+      Note that musb_readb() is used to read 8-bit registers at most,
+      while musb_readw() allows us to read at most 16-bit registers.
+      There are other functions that can be used depending on the size
+      of your device registers. See musb_io.h for more information.
+    </para>
+    <para>
+      Instruction on line 18 is another quirk specific to the JZ4740
+      USB device controller, which will be discussed later in <link
+      linkend="device-quirks">Chapter 5</link>.
+    </para>
+    <para>
+      The glue layer still needs to register the IRQ handler though.
+      Remember the instruction on line 14 of the init function:
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_musb_init(struct musb *musb)
+{
+        musb->isr = jz4740_musb_interrupt;
+
+        return 0;
+}
+    </programlisting>
+    <para>
+      This instruction sets a pointer to the glue layer IRQ handler
+      function, in order for the controller hardware to call the handler
+      back when an IRQ comes from the controller hardware. The interrupt
+      handler is now implemented and registered.
+    </para>
+  </chapter>
+
+  <chapter id="device-platform-data">
+    <title>Device Platform Data</title>
+    <para>
+      In order to write an MUSB glue layer, you need to have some data
+      describing the hardware capabilities of your controller hardware,
+      which is called the platform data.
+    </para>
+    <para>
+      Platform data is specific to your hardware, though it may cover a
+      broad range of devices, and is generally found somewhere in the
+      arch/ directory, depending on your device architecture.
+    </para>
+    <para>
+      For instance, platform data for the JZ4740 SoC is found in
+      arch/mips/jz4740/platform.c. In the platform.c file each device of
+      the JZ4740 SoC is described through a set of structures.
+    </para>
+    <para>
+      Here is the part of arch/mips/jz4740/platform.c that covers the
+      USB Device Controller (UDC):
+    </para>
+    <programlisting linenumbering="numbered">
+/* USB Device Controller */
+struct platform_device jz4740_udc_xceiv_device = {
+        .name = "usb_phy_gen_xceiv",
+        .id   = 0,
+};
+
+static struct resource jz4740_udc_resources[] = {
+        [0] = {
+                .start = JZ4740_UDC_BASE_ADDR,
+                .end   = JZ4740_UDC_BASE_ADDR + 0x10000 - 1,
+                .flags = IORESOURCE_MEM,
+        },
+        [1] = {
+                .start = JZ4740_IRQ_UDC,
+                .end   = JZ4740_IRQ_UDC,
+                .flags = IORESOURCE_IRQ,
+                .name  = "mc",
+        },
+};
+
+struct platform_device jz4740_udc_device = {
+        .name = "musb-jz4740",
+        .id   = -1,
+        .dev  = {
+                .dma_mask          = &amp;jz4740_udc_device.dev.coherent_dma_mask,
+                .coherent_dma_mask = DMA_BIT_MASK(32),
+        },
+        .num_resources = ARRAY_SIZE(jz4740_udc_resources),
+        .resource      = jz4740_udc_resources,
+};
+    </programlisting>
+    <para>
+      The jz4740_udc_xceiv_device platform device structure (line 2)
+      describes the UDC transceiver with a name and id number.
+    </para>
+    <para>
+      At the time of this writing, note that
+      &quot;usb_phy_gen_xceiv&quot; is the specific name to be used for
+      all transceivers that are either built-in with reference USB IP or
+      autonomous and doesn't require any PHY programming. You will need
+      to set CONFIG_NOP_USB_XCEIV=y in the kernel configuration to make
+      use of the corresponding transceiver driver. The id field could be
+      set to -1 (equivalent to PLATFORM_DEVID_NONE), -2 (equivalent to
+      PLATFORM_DEVID_AUTO) or start with 0 for the first device of this
+      kind if we want a specific id number.
+    </para>
+    <para>
+      The jz4740_udc_resources resource structure (line 7) defines the
+      UDC registers base addresses.
+    </para>
+    <para>
+      The first array (line 9 to 11) defines the UDC registers base
+      memory addresses: start points to the first register memory
+      address, end points to the last register memory address and the
+      flags member defines the type of resource we are dealing with. So
+      IORESOURCE_MEM is used to define the registers memory addresses.
+      The second array (line 14 to 17) defines the UDC IRQ registers
+      addresses. Since there is only one IRQ register available for the
+      JZ4740 UDC, start and end point at the same address. The
+      IORESOURCE_IRQ flag tells that we are dealing with IRQ resources,
+      and the name &quot;mc&quot; is in fact hard-coded in the MUSB core
+      in order for the controller driver to retrieve this IRQ resource
+      by querying it by its name.
+    </para>
+    <para>
+      Finally, the jz4740_udc_device platform device structure (line 21)
+      describes the UDC itself.
+    </para>
+    <para>
+      The &quot;musb-jz4740&quot; name (line 22) defines the MUSB
+      driver that is used for this device; remember this is in fact
+      the name that we used in the jz4740_driver platform driver
+      structure in <link linkend="linux-musb-basics">Chapter
+      2</link>. The id field (line 23) is set to -1 (equivalent to
+      PLATFORM_DEVID_NONE) since we do not need an id for the device:
+      the MUSB controller driver was already set to allocate an
+      automatic id in <link linkend="linux-musb-basics">Chapter
+      2</link>. In the dev field we care for DMA related information
+      here. The dma_mask field (line 25) defines the width of the DMA
+      mask that is going to be used, and coherent_dma_mask (line 26)
+      has the same purpose but for the alloc_coherent DMA mappings: in
+      both cases we are using a 32 bits mask. Then the resource field
+      (line 29) is simply a pointer to the resource structure defined
+      before, while the num_resources field (line 28) keeps track of
+      the number of arrays defined in the resource structure (in this
+      case there were two resource arrays defined before).
+    </para>
+    <para>
+      With this quick overview of the UDC platform data at the arch/
+      level now done, let's get back to the MUSB glue layer specific
+      platform data in drivers/usb/musb/jz4740.c:
+    </para>
+    <programlisting linenumbering="numbered">
+static struct musb_hdrc_config jz4740_musb_config = {
+        /* Silicon does not implement USB OTG. */
+        .multipoint = 0,
+        /* Max EPs scanned, driver will decide which EP can be used. */
+        .num_eps    = 4,
+        /* RAMbits needed to configure EPs from table */
+        .ram_bits   = 9,
+        .fifo_cfg = jz4740_musb_fifo_cfg,
+        .fifo_cfg_size = ARRAY_SIZE(jz4740_musb_fifo_cfg),
+};
+
+static struct musb_hdrc_platform_data jz4740_musb_platform_data = {
+        .mode   = MUSB_PERIPHERAL,
+        .config = &amp;jz4740_musb_config,
+};
+    </programlisting>
+    <para>
+      First the glue layer configures some aspects of the controller
+      driver operation related to the controller hardware specifics.
+      This is done through the jz4740_musb_config musb_hdrc_config
+      structure.
+    </para>
+    <para>
+      Defining the OTG capability of the controller hardware, the
+      multipoint member (line 3) is set to 0 (equivalent to false)
+      since the JZ4740 UDC is not OTG compatible. Then num_eps (line
+      5) defines the number of USB endpoints of the controller
+      hardware, including endpoint 0: here we have 3 endpoints +
+      endpoint 0. Next is ram_bits (line 7) which is the width of the
+      RAM address bus for the MUSB controller hardware. This
+      information is needed when the controller driver cannot
+      automatically configure endpoints by reading the relevant
+      controller hardware registers. This issue will be discussed when
+      we get to device quirks in <link linkend="device-quirks">Chapter
+      5</link>. Last two fields (line 8 and 9) are also about device
+      quirks: fifo_cfg points to the USB endpoints configuration table
+      and fifo_cfg_size keeps track of the size of the number of
+      entries in that configuration table. More on that later in <link
+      linkend="device-quirks">Chapter 5</link>.
+    </para>
+    <para>
+      Then this configuration is embedded inside
+      jz4740_musb_platform_data musb_hdrc_platform_data structure (line
+      11): config is a pointer to the configuration structure itself,
+      and mode tells the controller driver if the controller hardware
+      may be used as MUSB_HOST only, MUSB_PERIPHERAL only or MUSB_OTG
+      which is a dual mode.
+    </para>
+    <para>
+      Remember that jz4740_musb_platform_data is then used to convey
+      platform data information as we have seen in the probe function
+      in <link linkend="linux-musb-basics">Chapter 2</link>
+    </para>
+  </chapter>
+
+  <chapter id="device-quirks">
+    <title>Device Quirks</title>
+    <para>
+      Completing the platform data specific to your device, you may also
+      need to write some code in the glue layer to work around some
+      device specific limitations. These quirks may be due to some
+      hardware bugs, or simply be the result of an incomplete
+      implementation of the USB On-the-Go specification.
+    </para>
+    <para>
+      The JZ4740 UDC exhibits such quirks, some of which we will discuss
+      here for the sake of insight even though these might not be found
+      in the controller hardware you are working on.
+    </para>
+    <para>
+      Let's get back to the init function first:
+    </para>
+    <programlisting linenumbering="numbered">
+static int jz4740_musb_init(struct musb *musb)
+{
+        musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
+        if (!musb->xceiv) {
+                pr_err("HS UDC: no transceiver configured\n");
+                return -ENODEV;
+        }
+
+        /* Silicon does not implement ConfigData register.
+         * Set dyn_fifo to avoid reading EP config from hardware.
+         */
+        musb->dyn_fifo = true;
+
+        musb->isr = jz4740_musb_interrupt;
+
+        return 0;
+}
+    </programlisting>
+    <para>
+      Instruction on line 12 helps the MUSB controller driver to work
+      around the fact that the controller hardware is missing registers
+      that are used for USB endpoints configuration.
+    </para>
+    <para>
+      Without these registers, the controller driver is unable to read
+      the endpoints configuration from the hardware, so we use line 12
+      instruction to bypass reading the configuration from silicon, and
+      rely on a hard-coded table that describes the endpoints
+      configuration instead:
+    </para>
+    <programlisting linenumbering="numbered">
+static struct musb_fifo_cfg jz4740_musb_fifo_cfg[] = {
+{ .hw_ep_num = 1, .style = FIFO_TX, .maxpacket = 512, },
+{ .hw_ep_num = 1, .style = FIFO_RX, .maxpacket = 512, },
+{ .hw_ep_num = 2, .style = FIFO_TX, .maxpacket = 64, },
+};
+    </programlisting>
+    <para>
+      Looking at the configuration table above, we see that each
+      endpoints is described by three fields: hw_ep_num is the endpoint
+      number, style is its direction (either FIFO_TX for the controller
+      driver to send packets in the controller hardware, or FIFO_RX to
+      receive packets from hardware), and maxpacket defines the maximum
+      size of each data packet that can be transmitted over that
+      endpoint. Reading from the table, the controller driver knows that
+      endpoint 1 can be used to send and receive USB data packets of 512
+      bytes at once (this is in fact a bulk in/out endpoint), and
+      endpoint 2 can be used to send data packets of 64 bytes at once
+      (this is in fact an interrupt endpoint).
+    </para>
+    <para>
+      Note that there is no information about endpoint 0 here: that one
+      is implemented by default in every silicon design, with a
+      predefined configuration according to the USB specification. For
+      more examples of endpoint configuration tables, see musb_core.c.
+    </para>
+    <para>
+      Let's now get back to the interrupt handler function:
+    </para>
+    <programlisting linenumbering="numbered">
+static irqreturn_t jz4740_musb_interrupt(int irq, void *__hci)
+{
+        unsigned long   flags;
+        irqreturn_t     retval = IRQ_NONE;
+        struct musb     *musb = __hci;
+
+        spin_lock_irqsave(&amp;musb->lock, flags);
+
+        musb->int_usb = musb_readb(musb->mregs, MUSB_INTRUSB);
+        musb->int_tx = musb_readw(musb->mregs, MUSB_INTRTX);
+        musb->int_rx = musb_readw(musb->mregs, MUSB_INTRRX);
+
+        /*
+         * The controller is gadget only, the state of the host mode IRQ bits is
+         * undefined. Mask them to make sure that the musb driver core will
+         * never see them set
+         */
+        musb->int_usb &amp;= MUSB_INTR_SUSPEND | MUSB_INTR_RESUME |
+            MUSB_INTR_RESET | MUSB_INTR_SOF;
+
+        if (musb->int_usb || musb->int_tx || musb->int_rx)
+                retval = musb_interrupt(musb);
+
+        spin_unlock_irqrestore(&amp;musb->lock, flags);
+
+        return retval;
+}
+    </programlisting>
+    <para>
+      Instruction on line 18 above is a way for the controller driver to
+      work around the fact that some interrupt bits used for USB host
+      mode operation are missing in the MUSB_INTRUSB register, thus left
+      in an undefined hardware state, since this MUSB controller
+      hardware is used in peripheral mode only. As a consequence, the
+      glue layer masks these missing bits out to avoid parasite
+      interrupts by doing a logical AND operation between the value read
+      from MUSB_INTRUSB and the bits that are actually implemented in
+      the register.
+    </para>
+    <para>
+      These are only a couple of the quirks found in the JZ4740 USB
+      device controller. Some others were directly addressed in the MUSB
+      core since the fixes were generic enough to provide a better
+      handling of the issues for others controller hardware eventually.
+    </para>
+  </chapter>
+
+  <chapter id="conclusion">
+    <title>Conclusion</title>
+    <para>
+      Writing a Linux MUSB glue layer should be a more accessible task,
+      as this documentation tries to show the ins and outs of this
+      exercise.
+    </para>
+    <para>
+      The JZ4740 USB device controller being fairly simple, I hope its
+      glue layer serves as a good example for the curious mind. Used
+      with the current MUSB glue layers, this documentation should
+      provide enough guidance to get started; should anything gets out
+      of hand, the linux-usb mailing list archive is another helpful
+      resource to browse through.
+    </para>
+  </chapter>
+
+  <chapter id="acknowledgements">
+    <title>Acknowledgements</title>
+    <para>
+      Many thanks to Lars-Peter Clausen and Maarten ter Huurne for
+      answering my questions while I was writing the JZ4740 glue layer
+      and for helping me out getting the code in good shape.
+    </para>
+    <para>
+      I would also like to thank the Qi-Hardware community at large for
+      its cheerful guidance and support.
+    </para>
+  </chapter>
+
+  <chapter id="resources">
+    <title>Resources</title>
+    <para>
+      USB Home Page:
+      <ulink url="http://www.usb.org">http://www.usb.org</ulink>
+    </para>
+    <para>
+      linux-usb Mailing List Archives:
+      <ulink url="http://marc.info/?l=linux-usb">http://marc.info/?l=linux-usb</ulink>
+    </para>
+    <para>
+      USB On-the-Go Basics:
+      <ulink url="http://www.maximintegrated.com/app-notes/index.mvp/id/1822">http://www.maximintegrated.com/app-notes/index.mvp/id/1822</ulink>
+    </para>
+    <para>
+      Writing USB Device Drivers:
+      <ulink url="https://www.kernel.org/doc/htmldocs/writing_usb_driver/index.html">https://www.kernel.org/doc/htmldocs/writing_usb_driver/index.html</ulink>
+    </para>
+    <para>
+      Texas Instruments USB Configuration Wiki Page:
+      <ulink url="http://processors.wiki.ti.com/index.php/Usbgeneralpage">http://processors.wiki.ti.com/index.php/Usbgeneralpage</ulink>
+    </para>
+    <para>
+      Analog Devices Blackfin MUSB Configuration:
+      <ulink url="http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:musb">http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:musb</ulink>
+    </para>
+  </chapter>
+
+</book>
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/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 03df71aeb38c..8a8b82c9ca53 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -41,8 +41,7 @@ An interrupt controller driver creates and registers an irq_domain by
 calling one of the irq_domain_add_*() functions (each mapping method
 has a different allocator function, more on that later).  The function
 will return a pointer to the irq_domain on success.  The caller must
-provide the allocator function with an irq_domain_ops structure with
-the .map callback populated as a minimum.
+provide the allocator function with an irq_domain_ops structure.
 
 In most cases, the irq_domain will begin empty without any mappings
 between hwirq and IRQ numbers.  Mappings are added to the irq_domain
diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX
index fa57139f50bf..f773a264ae02 100644
--- a/Documentation/RCU/00-INDEX
+++ b/Documentation/RCU/00-INDEX
@@ -12,6 +12,8 @@ lockdep-splat.txt
         - RCU Lockdep splats explained.
 NMI-RCU.txt
         - Using RCU to Protect Dynamic NMI Handlers
+rcu_dereference.txt
+        - Proper care and feeding of return values from rcu_dereference()
 rcubarrier.txt
         - RCU and Unloadable Modules
 rculist_nulls.txt
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 9d10d1db16a5..877947130ebe 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -114,12 +114,16 @@ over a rather long period of time, but improvements are always welcome!
                         http://www.openvms.compaq.com/wizard/wiz_2637.html
 
                 The rcu_dereference() primitive is also an excellent
-                documentation aid, letting the person reading the code
-                know exactly which pointers are protected by RCU.
+                documentation aid, letting the person reading the
+                code know exactly which pointers are protected by RCU.
                 Please note that compilers can also reorder code, and
                 they are becoming increasingly aggressive about doing
-                just that.  The rcu_dereference() primitive therefore
-                also prevents destructive compiler optimizations.
+                just that.  The rcu_dereference() primitive therefore also
+                prevents destructive compiler optimizations.  However,
+                with a bit of devious creativity, it is possible to
+                mishandle the return value from rcu_dereference().
+                Please see rcu_dereference.txt in this directory for
+                more information.
 
                 The rcu_dereference() primitive is used by the
                 various "_rcu()" list-traversal primitives, such
diff --git a/Documentation/RCU/rcu_dereference.txt b/Documentation/RCU/rcu_dereference.txt
new file mode 100644
index 000000000000..ceb05da5a5ac
--- /dev/null
+++ b/Documentation/RCU/rcu_dereference.txt
@@ -0,0 +1,371 @@
+PROPER CARE AND FEEDING OF RETURN VALUES FROM rcu_dereference()
+
+Most of the time, you can use values from rcu_dereference() or one of
+the similar primitives without worries.  Dereferencing (prefix "*"),
+field selection ("->"), assignment ("="), address-of ("&"), addition and
+subtraction of constants, and casts all work quite naturally and safely.
+
+It is nevertheless possible to get into trouble with other operations.
+Follow these rules to keep your RCU code working properly:
+
+o       You must use one of the rcu_dereference() family of primitives
+        to load an RCU-protected pointer, otherwise CONFIG_PROVE_RCU
+        will complain.  Worse yet, your code can see random memory-corruption
+        bugs due to games that compilers and DEC Alpha can play.
+        Without one of the rcu_dereference() primitives, compilers
+        can reload the value, and won't your code have fun with two
+        different values for a single pointer!  Without rcu_dereference(),
+        DEC Alpha can load a pointer, dereference that pointer, and
+        return data preceding initialization that preceded the store of
+        the pointer.
+
+        In addition, the volatile cast in rcu_dereference() prevents the
+        compiler from deducing the resulting pointer value.  Please see
+        the section entitled "EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH"
+        for an example where the compiler can in fact deduce the exact
+        value of the pointer, and thus cause misordering.
+
+o       Do not use single-element RCU-protected arrays.  The compiler
+        is within its right to assume that the value of an index into
+        such an array must necessarily evaluate to zero.  The compiler
+        could then substitute the constant zero for the computation, so
+        that the array index no longer depended on the value returned
+        by rcu_dereference().  If the array index no longer depends
+        on rcu_dereference(), then both the compiler and the CPU
+        are within their rights to order the array access before the
+        rcu_dereference(), which can cause the array access to return
+        garbage.
+
+o       Avoid cancellation when using the "+" and "-" infix arithmetic
+        operators.  For example, for a given variable "x", avoid
+        "(x-x)".  There are similar arithmetic pitfalls from other
+        arithmetic operatiors, such as "(x*0)", "(x/(x+1))" or "(x%1)".
+        The compiler is within its rights to substitute zero for all of
+        these expressions, so that subsequent accesses no longer depend
+        on the rcu_dereference(), again possibly resulting in bugs due
+        to misordering.
+
+        Of course, if "p" is a pointer from rcu_dereference(), and "a"
+        and "b" are integers that happen to be equal, the expression
+        "p+a-b" is safe because its value still necessarily depends on
+        the rcu_dereference(), thus maintaining proper ordering.
+
+o       Avoid all-zero operands to the bitwise "&" operator, and
+        similarly avoid all-ones operands to the bitwise "|" operator.
+        If the compiler is able to deduce the value of such operands,
+        it is within its rights to substitute the corresponding constant
+        for the bitwise operation.  Once again, this causes subsequent
+        accesses to no longer depend on the rcu_dereference(), causing
+        bugs due to misordering.
+
+        Please note that single-bit operands to bitwise "&" can also
+        be dangerous.  At this point, the compiler knows that the
+        resulting value can only take on one of two possible values.
+        Therefore, a very small amount of additional information will
+        allow the compiler to deduce the exact value, which again can
+        result in misordering.
+
+o       If you are using RCU to protect JITed functions, so that the
+        "()" function-invocation operator is applied to a value obtained
+        (directly or indirectly) from rcu_dereference(), you may need to
+        interact directly with the hardware to flush instruction caches.
+        This issue arises on some systems when a newly JITed function is
+        using the same memory that was used by an earlier JITed function.
+
+o       Do not use the results from the boolean "&&" and "||" when
+        dereferencing.  For example, the following (rather improbable)
+        code is buggy:
+
+                int a[2];
+                int index;
+                int force_zero_index = 1;
+
+                ...
+
+                r1 = rcu_dereference(i1)
+                r2 = a[r1 && force_zero_index];  /* BUGGY!!! */
+
+        The reason this is buggy is that "&&" and "||" are often compiled
+        using branches.  While weak-memory machines such as ARM or PowerPC
+        do order stores after such branches, they can speculate loads,
+        which can result in misordering bugs.
+
+o       Do not use the results from relational operators ("==", "!=",
+        ">", ">=", "<", or "<=") when dereferencing.  For example,
+        the following (quite strange) code is buggy:
+
+                int a[2];
+                int index;
+                int flip_index = 0;
+
+                ...
+
+                r1 = rcu_dereference(i1)
+                r2 = a[r1 != flip_index];  /* BUGGY!!! */
+
+        As before, the reason this is buggy is that relational operators
+        are often compiled using branches.  And as before, although
+        weak-memory machines such as ARM or PowerPC do order stores
+        after such branches, but can speculate loads, which can again
+        result in misordering bugs.
+
+o       Be very careful about comparing pointers obtained from
+        rcu_dereference() against non-NULL values.  As Linus Torvalds
+        explained, if the two pointers are equal, the compiler could
+        substitute the pointer you are comparing against for the pointer
+        obtained from rcu_dereference().  For example:
+
+                p = rcu_dereference(gp);
+                if (p == &default_struct)
+                        do_default(p->a);
+
+        Because the compiler now knows that the value of "p" is exactly
+        the address of the variable "default_struct", it is free to
+        transform this code into the following:
+
+                p = rcu_dereference(gp);
+                if (p == &default_struct)
+                        do_default(default_struct.a);
+
+        On ARM and Power hardware, the load from "default_struct.a"
+        can now be speculated, such that it might happen before the
+        rcu_dereference().  This could result in bugs due to misordering.
+
+        However, comparisons are OK in the following cases:
+
+        o       The comparison was against the NULL pointer.  If the
+                compiler knows that the pointer is NULL, you had better
+                not be dereferencing it anyway.  If the comparison is
+                non-equal, the compiler is none the wiser.  Therefore,
+                it is safe to compare pointers from rcu_dereference()
+                against NULL pointers.
+
+        o       The pointer is never dereferenced after being compared.
+                Since there are no subsequent dereferences, the compiler
+                cannot use anything it learned from the comparison
+                to reorder the non-existent subsequent dereferences.
+                This sort of comparison occurs frequently when scanning
+                RCU-protected circular linked lists.
+
+        o       The comparison is against a pointer that references memory
+                that was initialized "a long time ago."  The reason
+                this is safe is that even if misordering occurs, the
+                misordering will not affect the accesses that follow
+                the comparison.  So exactly how long ago is "a long
+                time ago"?  Here are some possibilities:
+
+                o       Compile time.
+
+                o       Boot time.
+
+                o       Module-init time for module code.
+
+                o       Prior to kthread creation for kthread code.
+
+                o       During some prior acquisition of the lock that
+                        we now hold.
+
+                o       Before mod_timer() time for a timer handler.
+
+                There are many other possibilities involving the Linux
+                kernel's wide array of primitives that cause code to
+                be invoked at a later time.
+
+        o       The pointer being compared against also came from
+                rcu_dereference().  In this case, both pointers depend
+                on one rcu_dereference() or another, so you get proper
+                ordering either way.
+
+                That said, this situation can make certain RCU usage
+                bugs more likely to happen.  Which can be a good thing,
+                at least if they happen during testing.  An example
+                of such an RCU usage bug is shown in the section titled
+                "EXAMPLE OF AMPLIFIED RCU-USAGE BUG".
+
+        o       All of the accesses following the comparison are stores,
+                so that a control dependency preserves the needed ordering.
+                That said, it is easy to get control dependencies wrong.
+                Please see the "CONTROL DEPENDENCIES" section of
+                Documentation/memory-barriers.txt for more details.
+
+        o       The pointers are not equal -and- the compiler does
+                not have enough information to deduce the value of the
+                pointer.  Note that the volatile cast in rcu_dereference()
+                will normally prevent the compiler from knowing too much.
+
+o       Disable any value-speculation optimizations that your compiler
+        might provide, especially if you are making use of feedback-based
+        optimizations that take data collected from prior runs.  Such
+        value-speculation optimizations reorder operations by design.
+
+        There is one exception to this rule:  Value-speculation
+        optimizations that leverage the branch-prediction hardware are
+        safe on strongly ordered systems (such as x86), but not on weakly
+        ordered systems (such as ARM or Power).  Choose your compiler
+        command-line options wisely!
+
+
+EXAMPLE OF AMPLIFIED RCU-USAGE BUG
+
+Because updaters can run concurrently with RCU readers, RCU readers can
+see stale and/or inconsistent values.  If RCU readers need fresh or
+consistent values, which they sometimes do, they need to take proper
+precautions.  To see this, consider the following code fragment:
+
+        struct foo {
+                int a;
+                int b;
+                int c;
+        };
+        struct foo *gp1;
+        struct foo *gp2;
+
+        void updater(void)
+        {
+                struct foo *p;
+
+                p = kmalloc(...);
+                if (p == NULL)
+                        deal_with_it();
+                p->a = 42;  /* Each field in its own cache line. */
+                p->b = 43;
+                p->c = 44;
+                rcu_assign_pointer(gp1, p);
+                p->b = 143;
+                p->c = 144;
+                rcu_assign_pointer(gp2, p);
+        }
+
+        void reader(void)
+        {
+                struct foo *p;
+                struct foo *q;
+                int r1, r2;
+
+                p = rcu_dereference(gp2);
+                if (p == NULL)
+                        return;
+                r1 = p->b;  /* Guaranteed to get 143. */
+                q = rcu_dereference(gp1);  /* Guaranteed non-NULL. */
+                if (p == q) {
+                        /* The compiler decides that q->c is same as p->c. */
+                        r2 = p->c; /* Could get 44 on weakly order system. */
+                }
+                do_something_with(r1, r2);
+        }
+
+You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
+but you should not be.  After all, the updater might have been invoked
+a second time between the time reader() loaded into "r1" and the time
+that it loaded into "r2".  The fact that this same result can occur due
+to some reordering from the compiler and CPUs is beside the point.
+
+But suppose that the reader needs a consistent view?
+
+Then one approach is to use locking, for example, as follows:
+
+        struct foo {
+                int a;
+                int b;
+                int c;
+                spinlock_t lock;
+        };
+        struct foo *gp1;
+        struct foo *gp2;
+
+        void updater(void)
+        {
+                struct foo *p;
+
+                p = kmalloc(...);
+                if (p == NULL)
+                        deal_with_it();
+                spin_lock(&p->lock);
+                p->a = 42;  /* Each field in its own cache line. */
+                p->b = 43;
+                p->c = 44;
+                spin_unlock(&p->lock);
+                rcu_assign_pointer(gp1, p);
+                spin_lock(&p->lock);
+                p->b = 143;
+                p->c = 144;
+                spin_unlock(&p->lock);
+                rcu_assign_pointer(gp2, p);
+        }
+
+        void reader(void)
+        {
+                struct foo *p;
+                struct foo *q;
+                int r1, r2;
+
+                p = rcu_dereference(gp2);
+                if (p == NULL)
+                        return;
+                spin_lock(&p->lock);
+                r1 = p->b;  /* Guaranteed to get 143. */
+                q = rcu_dereference(gp1);  /* Guaranteed non-NULL. */
+                if (p == q) {
+                        /* The compiler decides that q->c is same as p->c. */
+                        r2 = p->c; /* Locking guarantees r2 == 144. */
+                }
+                spin_unlock(&p->lock);
+                do_something_with(r1, r2);
+        }
+
+As always, use the right tool for the job!
+
+
+EXAMPLE WHERE THE COMPILER KNOWS TOO MUCH
+
+If a pointer obtained from rcu_dereference() compares not-equal to some
+other pointer, the compiler normally has no clue what the value of the
+first pointer might be.  This lack of knowledge prevents the compiler
+from carrying out optimizations that otherwise might destroy the ordering
+guarantees that RCU depends on.  And the volatile cast in rcu_dereference()
+should prevent the compiler from guessing the value.
+
+But without rcu_dereference(), the compiler knows more than you might
+expect.  Consider the following code fragment:
+
+        struct foo {
+                int a;
+                int b;
+        };
+        static struct foo variable1;
+        static struct foo variable2;
+        static struct foo *gp = &variable1;
+
+        void updater(void)
+        {
+                initialize_foo(&variable2);
+                rcu_assign_pointer(gp, &variable2);
+                /*
+                 * The above is the only store to gp in this translation unit,
+                 * and the address of gp is not exported in any way.
+                 */
+        }
+
+        int reader(void)
+        {
+                struct foo *p;
+
+                p = gp;
+                barrier();
+                if (p == &variable1)
+                        return p->a; /* Must be variable1.a. */
+                else
+                        return p->b; /* Must be variable2.b. */
+        }
+
+Because the compiler can see all stores to "gp", it knows that the only
+possible values of "gp" are "variable1" on the one hand and "variable2"
+on the other.  The comparison in reader() therefore tells the compiler
+the exact value of "p" even in the not-equals case.  This allows the
+compiler to make the return values independent of the load from "gp",
+in turn destroying the ordering between this load and the loads of the
+return values.  This can result in "p->b" returning pre-initialization
+garbage values.
+
+In short, rcu_dereference() is -not- optional when you are going to
+dereference the resulting pointer.
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 6f3a0057548e..68fe3ad27015 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -24,7 +24,7 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
         timing of the next warning for the current stall.
 
         Stall-warning messages may be enabled and disabled completely via
-        /sys/module/rcutree/parameters/rcu_cpu_stall_suppress.
+        /sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
 
 CONFIG_RCU_CPU_STALL_VERBOSE
 
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 0f0fb7c432c2..49b8551a3b68 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -326,11 +326,11 @@ used as follows:
 a.      synchronize_rcu()       rcu_read_lock() / rcu_read_unlock()
         call_rcu()              rcu_dereference()
 
-b.      call_rcu_bh()           rcu_read_lock_bh() / rcu_read_unlock_bh()
-                                rcu_dereference_bh()
+b.      synchronize_rcu_bh()    rcu_read_lock_bh() / rcu_read_unlock_bh()
+        call_rcu_bh()           rcu_dereference_bh()
 
 c.      synchronize_sched()     rcu_read_lock_sched() / rcu_read_unlock_sched()
-                                preempt_disable() / preempt_enable()
+        call_rcu_sched()        preempt_disable() / preempt_enable()
                                 local_irq_save() / local_irq_restore()
                                 hardirq enter / hardirq exit
                                 NMI enter / NMI exit
@@ -794,10 +794,22 @@ in docbook.  Here is the list, by category.
 
 RCU list traversal:
 
+        list_entry_rcu
+        list_first_entry_rcu
+        list_next_rcu
         list_for_each_entry_rcu
+        list_for_each_entry_continue_rcu
+        hlist_first_rcu
+        hlist_next_rcu
+        hlist_pprev_rcu
         hlist_for_each_entry_rcu
+        hlist_for_each_entry_rcu_bh
+        hlist_for_each_entry_continue_rcu
+        hlist_for_each_entry_continue_rcu_bh
+        hlist_nulls_first_rcu
         hlist_nulls_for_each_entry_rcu
-        list_for_each_entry_continue_rcu
+        hlist_bl_first_rcu
+        hlist_bl_for_each_entry_rcu
 
 RCU pointer/list update:
 
@@ -806,28 +818,38 @@ RCU pointer/list update:
         list_add_tail_rcu
         list_del_rcu
         list_replace_rcu
-        hlist_del_rcu
         hlist_add_after_rcu
         hlist_add_before_rcu
         hlist_add_head_rcu
+        hlist_del_rcu
+        hlist_del_init_rcu
         hlist_replace_rcu
         list_splice_init_rcu()
+        hlist_nulls_del_init_rcu
+        hlist_nulls_del_rcu
+        hlist_nulls_add_head_rcu
+        hlist_bl_add_head_rcu
+        hlist_bl_del_init_rcu
+        hlist_bl_del_rcu
+        hlist_bl_set_first_rcu
 
 RCU:    Critical sections       Grace period            Barrier
 
         rcu_read_lock           synchronize_net         rcu_barrier
         rcu_read_unlock         synchronize_rcu
         rcu_dereference         synchronize_rcu_expedited
-                                call_rcu
-                                kfree_rcu
-
+        rcu_read_lock_held      call_rcu
+        rcu_dereference_check   kfree_rcu
+        rcu_dereference_protected
 
 bh:     Critical sections       Grace period            Barrier
 
         rcu_read_lock_bh        call_rcu_bh             rcu_barrier_bh
         rcu_read_unlock_bh      synchronize_rcu_bh
         rcu_dereference_bh      synchronize_rcu_bh_expedited
-
+        rcu_dereference_bh_check
+        rcu_dereference_bh_protected
+        rcu_read_lock_bh_held
 
 sched:  Critical sections       Grace period            Barrier
 
@@ -835,7 +857,12 @@ sched:	Critical sections	Grace period		Barrier
         rcu_read_unlock_sched   call_rcu_sched
         [preempt_disable]       synchronize_sched_expedited
         [and friends]
+        rcu_read_lock_sched_notrace
+        rcu_read_unlock_sched_notrace
         rcu_dereference_sched
+        rcu_dereference_sched_check
+        rcu_dereference_sched_protected
+        rcu_read_lock_sched_held
 
 
 SRCU:   Critical sections       Grace period            Barrier
@@ -843,6 +870,8 @@ SRCU:	Critical sections	Grace period		Barrier
         srcu_read_lock          synchronize_srcu        srcu_barrier
         srcu_read_unlock        call_srcu
         srcu_dereference        synchronize_srcu_expedited
+        srcu_dereference_check
+        srcu_read_lock_held
 
 SRCU:   Initialization/cleanup
         init_srcu_struct
@@ -850,9 +879,13 @@ SRCU:	Initialization/cleanup
 
 All:  lockdep-checked RCU-protected pointer access
 
-        rcu_dereference_check
-        rcu_dereference_protected
+        rcu_access_index
         rcu_access_pointer
+        rcu_dereference_index_check
+        rcu_dereference_raw
+        rcu_lockdep_assert
+        rcu_sleep_check
+        RCU_NONIDLE
 
 See the comment headers in the source code (or the docbook generated
 from them) for more information.
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 2a8e89e13e45..7e9abb8a276b 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -132,6 +132,20 @@ Example:
         platform_set_drvdata(), but left the variable "dev" unused,
         delete it.
 
+If your patch fixes a bug in a specific commit, e.g. you found an issue using
+git-bisect, please use the 'Fixes:' tag with the first 12 characters of the
+SHA-1 ID, and the one line summary.
+Example:
+
+        Fixes: e21d2170f366 ("video: remove unnecessary platform_set_drvdata()")
+
+The following git-config settings can be used to add a pretty format for
+outputting the above style in the git log or git show commands
+
+        [core]
+                abbrev = 12
+        [pretty]
+                fixes = Fixes: %h (\"%s\")
 
 3) Separate your changes.
 
@@ -443,7 +457,7 @@ person it names.  This tag documents that potentially interested parties
 have been included in the discussion
 
 
-14) Using Reported-by:, Tested-by:, Reviewed-by: and Suggested-by:
+14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
 
 If this patch fixes a problem reported by somebody else, consider adding a
 Reported-by: tag to credit the reporter for their contribution.  Please
@@ -498,6 +512,12 @@ idea was not posted in a public forum. That said, if we diligently credit our
 idea reporters, they will, hopefully, be inspired to help us again in the
 future.
 
+A Fixes: tag indicates that the patch fixes an issue in a previous commit. It
+is used to make it easy to determine where a bug originated, which can help
+review a bug fix. This tag also assists the stable kernel team in determining
+which stable kernel versions should receive your fix. This is the preferred
+method for indicating a bug fixed by the patch. See #2 above for more details.
+
 
 15) The canonical patch format
 
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index 2a1519b87177..fd786ea13a1f 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -296,7 +296,7 @@ specifies the path to the controller. In order to use these GPIOs in Linux
 we need to translate them to the corresponding Linux GPIO descriptors.
 
 There is a standard GPIO API for that and is documented in
-Documentation/gpio.txt.
+Documentation/gpio/.
 
 In the above example we can get the corresponding two GPIO descriptors with
 a code like this:
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
index a94090cc785d..3b08bc2b04cf 100644
--- a/Documentation/arm/00-INDEX
+++ b/Documentation/arm/00-INDEX
@@ -46,5 +46,7 @@ swp_emulation
         - SWP/SWPB emulation handler/logging description
 tcm.txt
         - ARM Tightly Coupled Memory
+uefi.txt
+        - [U]EFI configuration and runtime services documentation
 vlocks.txt
         - Voting locks, low-level mechanism relying on memory system atomic writes.
diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 963ec445e15a..2cce5401e323 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -234,6 +234,11 @@ Berlin family (Digital Entertainment)
                 Core:           Marvell PJ4B (ARMv7), Tauros3 L2CC
                 Homepage:       http://www.marvell.com/digital-entertainment/armada-1500/
                 Product Brief:  http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
+        88DE3114, Armada 1500 Pro
+                Design name:    BG2-Q
+                Core:           Quad Core ARM Cortex-A9, PL310 L2CC
+                Homepage:       http://www.marvell.com/digital-entertainment/armada-1500-pro/
+                Product Brief:  http://www.marvell.com/digital-entertainment/armada-1500-pro/assets/Marvell_ARMADA_1500_PRO-01_product_brief.pdf
         88DE????
                 Design name:    BG3
                 Core:           ARM Cortex-A15, CA15 integrated L2CC
diff --git a/Documentation/arm/memory.txt b/Documentation/arm/memory.txt
index 4bfb9ffbdbc1..38dc06d0a791 100644
--- a/Documentation/arm/memory.txt
+++ b/Documentation/arm/memory.txt
@@ -41,16 +41,9 @@ fffe8000	fffeffff	DTCM mapping area for platforms with
 fffe0000        fffe7fff        ITCM mapping area for platforms with
                                 ITCM mounted inside the CPU.
 
-fff00000        fffdffff        Fixmap mapping region.  Addresses provided
+ffc00000        ffdfffff        Fixmap mapping region.  Addresses provided
                                 by fix_to_virt() will be located here.
 
-ffc00000        ffefffff        DMA memory mapping region.  Memory returned
-                                by the dma_alloc_xxx functions will be
-                                dynamically mapped here.
-
-ff000000        ffbfffff        Reserved for future expansion of DMA
-                                mapping region.
-
 fee00000        feffffff        Mapping of PCI I/O space. This is a static
                                 mapping within the vmalloc space.
 
diff --git a/Documentation/arm/sti/stih407-overview.txt b/Documentation/arm/sti/stih407-overview.txt
new file mode 100644
index 000000000000..3343f32f58bc
--- /dev/null
+++ b/Documentation/arm/sti/stih407-overview.txt
@@ -0,0 +1,18 @@
+                        STiH407 Overview
+                        ================
+
+Introduction
+------------
+
+    The STiH407 is the new generation of SoC for Multi-HD, AVC set-top boxes
+    and server/connected client application for satellite, cable, terrestrial
+    and IP-STB markets.
+
+    Features
+    - ARM Cortex-A9 1.5 GHz dual core CPU (28nm)
+    - SATA2, USB 3.0, PCIe, Gbit Ethernet
+
+  Document Author
+  ---------------
+
+  Maxime Coquelin <maxime.coquelin@st.com>, (c) 2014 ST Microelectronics
diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
new file mode 100644
index 000000000000..d60030a1b909
--- /dev/null
+++ b/Documentation/arm/uefi.txt
@@ -0,0 +1,64 @@
+UEFI, the Unified Extensible Firmware Interface, is a specification
+governing the behaviours of compatible firmware interfaces. It is
+maintained by the UEFI Forum - http://www.uefi.org/.
+
+UEFI is an evolution of its predecessor 'EFI', so the terms EFI and
+UEFI are used somewhat interchangeably in this document and associated
+source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers
+to legacy code or specifications.
+
+UEFI support in Linux
+=====================
+Booting on a platform with firmware compliant with the UEFI specification
+makes it possible for the kernel to support additional features:
+- UEFI Runtime Services
+- Retrieving various configuration information through the standardised
+  interface of UEFI configuration tables. (ACPI, SMBIOS, ...)
+
+For actually enabling [U]EFI support, enable:
+- CONFIG_EFI=y
+- CONFIG_EFI_VARS=y or m
+
+The implementation depends on receiving information about the UEFI environment
+in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF.
+
+UEFI stub
+=========
+The "stub" is a feature that extends the Image/zImage into a valid UEFI
+PE/COFF executable, including a loader application that makes it possible to
+load the kernel directly from the UEFI shell, boot menu, or one of the
+lightweight bootloaders like Gummiboot or rEFInd.
+
+The kernel image built with stub support remains a valid kernel image for
+booting in non-UEFI environments.
+
+UEFI kernel support on ARM
+==========================
+UEFI kernel support on the ARM architectures (arm and arm64) is only available
+when boot is performed through the stub.
+
+When booting in UEFI mode, the stub deletes any memory nodes from a provided DT.
+Instead, the kernel reads the UEFI memory map.
+
+The stub populates the FDT /chosen node with (and the kernel scans for) the
+following parameters:
+________________________________________________________________________________
+Name                      | Size   | Description
+================================================================================
+linux,uefi-system-table   | 64-bit | Physical address of the UEFI System Table.
+--------------------------------------------------------------------------------
+linux,uefi-mmap-start     | 64-bit | Physical address of the UEFI memory map,
+                          |        | populated by the UEFI GetMemoryMap() call.
+--------------------------------------------------------------------------------
+linux,uefi-mmap-size      | 32-bit | Size in bytes of the UEFI memory map
+                          |        | pointed to in previous entry.
+--------------------------------------------------------------------------------
+linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
+                          |        | memory map.
+--------------------------------------------------------------------------------
+linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap descriptor format.
+--------------------------------------------------------------------------------
+linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
+--------------------------------------------------------------------------------
+
+For verbose debug messages, specify 'uefi_debug' on the kernel command line.
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index beb754e87c65..37fc4f632176 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -85,6 +85,10 @@ The decompressed kernel image contains a 64-byte header as follows:
 Header notes:
 
 - code0/code1 are responsible for branching to stext.
+- when booting through EFI, code0/code1 are initially skipped.
+  res5 is an offset to the PE header and the PE header has the EFI
+  entry point (efi_stub_entry). When the stub has done its work, it
+  jumps to code0 to resume the normal boot process.
 
 The image must be placed at the specified offset (currently 0x80000)
 from the start of the system RAM and called there. The start of the
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index d9ca5be9b471..68542fe13b85 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -285,15 +285,13 @@ If a caller requires memory barrier semantics around an atomic_t
 operation which does not return a value, a set of interfaces are
 defined which accomplish this:
 
-        void smp_mb__before_atomic_dec(void);
-        void smp_mb__after_atomic_dec(void);
-        void smp_mb__before_atomic_inc(void);
-        void smp_mb__after_atomic_inc(void);
+        void smp_mb__before_atomic(void);
+        void smp_mb__after_atomic(void);
 
-For example, smp_mb__before_atomic_dec() can be used like so:
+For example, smp_mb__before_atomic() can be used like so:
 
         obj->dead = 1;
-        smp_mb__before_atomic_dec();
+        smp_mb__before_atomic();
         atomic_dec(&obj->ref_count);
 
 It makes sure that all memory operations preceding the atomic_dec()
@@ -302,15 +300,10 @@ operation.  In the above example, it guarantees that the assignment of
 "1" to obj->dead will be globally visible to other cpus before the
 atomic counter decrement.
 
-Without the explicit smp_mb__before_atomic_dec() call, the
+Without the explicit smp_mb__before_atomic() call, the
 implementation could legally allow the atomic counter update visible
 to other cpus before the "obj->dead = 1;" assignment.
 
-The other three interfaces listed are used to provide explicit
-ordering with respect to memory operations after an atomic_dec() call
-(smp_mb__after_atomic_dec()) and around atomic_inc() calls
-(smp_mb__{before,after}_atomic_inc()).
-
 A missing memory barrier in the cases where they are required by the
 atomic_t implementation above can have disastrous results.  Here is
 an example, which follows a pattern occurring frequently in the Linux
@@ -487,12 +480,12 @@ Finally there is the basic operation:
 Which returns a boolean indicating if bit "nr" is set in the bitmask
 pointed to by "addr".
 
-If explicit memory barriers are required around clear_bit() (which
-does not return a value, and thus does not need to provide memory
-barrier semantics), two interfaces are provided:
+If explicit memory barriers are required around {set,clear}_bit() (which do
+not return a value, and thus does not need to provide memory barrier
+semantics), two interfaces are provided:
 
-        void smp_mb__before_clear_bit(void);
-        void smp_mb__after_clear_bit(void);
+        void smp_mb__before_atomic(void);
+        void smp_mb__after_atomic(void);
 
 They are used as follows, and are akin to their atomic_t operation
 brothers:
@@ -500,13 +493,13 @@ brothers:
         /* All memory operations before this call will
          * be globally visible before the clear_bit().
          */
-        smp_mb__before_clear_bit();
+        smp_mb__before_atomic();
         clear_bit( ... );
 
         /* The clear_bit() will be visible before all
          * subsequent memory operations.
          */
-         smp_mb__after_clear_bit();
+         smp_mb__after_atomic();
 
 There are two special bitops with lock barrier semantics (acquire/release,
 same as spinlocks). These operate in the same way as their non-_lock/unlock
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 2622115276aa..02ab997a1ed2 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -270,6 +270,11 @@ When oom event notifier is registered, event will be delivered.
 
 2.7 Kernel Memory Extension (CONFIG_MEMCG_KMEM)
 
+WARNING: Current implementation lacks reclaim support. That means allocation
+         attempts will fail when close to the limit even if there are plenty of
+         kmem available for reclaim. That makes this option unusable in real
+         life so DO NOT SELECT IT unless for development purposes.
+
 With the Kernel memory extension, the Memory Controller is able to limit
 the amount of kernel memory used by the system. Kernel memory is fundamentally
 different than user memory, since it can't be swapped out, which makes it
@@ -453,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.
-  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 cgroup will be reclaimed and as many pages reclaimed as possible.
 
   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
@@ -535,16 +536,13 @@ Note:
 
 5.3 swappiness
 
-Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only.
-Please note that unlike the global swappiness, memcg knob set to 0
-really prevents from any swapping even if there is a swap storage
-available. This might lead to memcg OOM killer if there are no file
-pages to reclaim.
+Overrides /proc/sys/vm/swappiness for the particular group. The tunable
+in the root cgroup corresponds to the global swappiness setting.
 
-Following cgroups' swappiness can't be changed.
-- root cgroup (uses /proc/sys/vm/swappiness).
-- a cgroup which uses hierarchy and it has other cgroup(s) below it.
-- a cgroup which uses hierarchy and not the root of hierarchy.
+Please note that unlike during the global reclaim, limit reclaim
+enforces that 0 swappiness really prevents from any swapping even if
+there is a swap storage available. This might lead to memcg OOM killer
+if there are no file pages to reclaim.
 
 5.4 failcnt
 
@@ -754,7 +752,6 @@ You can disable the OOM-killer by writing "1" to memory.oom_control file, as:
 
         #echo 1 > memory.oom_control
 
-This operation is only allowed to the top cgroup of a sub-hierarchy.
 If OOM-killer is disabled, tasks under cgroup will hang/sleep
 in memory cgroup's OOM-waitqueue when they request accountable memory.
 
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/clk.txt b/Documentation/clk.txt
index c9c399af7c08..1fee72f4d331 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -68,21 +68,27 @@ the operations defined in clk.h:
                 int             (*is_enabled)(struct clk_hw *hw);
                 unsigned long   (*recalc_rate)(struct clk_hw *hw,
                                                 unsigned long parent_rate);
-                long            (*round_rate)(struct clk_hw *hw, unsigned long,
-                                                unsigned long *);
+                long            (*round_rate)(struct clk_hw *hw,
+                                                unsigned long rate,
+                                                unsigned long *parent_rate);
                 long            (*determine_rate)(struct clk_hw *hw,
                                                 unsigned long rate,
                                                 unsigned long *best_parent_rate,
                                                 struct clk **best_parent_clk);
                 int             (*set_parent)(struct clk_hw *hw, u8 index);
                 u8              (*get_parent)(struct clk_hw *hw);
-                int             (*set_rate)(struct clk_hw *hw, unsigned long);
+                int             (*set_rate)(struct clk_hw *hw,
+                                            unsigned long rate,
+                                            unsigned long parent_rate);
                 int             (*set_rate_and_parent)(struct clk_hw *hw,
                                             unsigned long rate,
-                                            unsigned long parent_rate, u8 index);
+                                            unsigned long parent_rate,
+                                            u8 index);
                 unsigned long   (*recalc_accuracy)(struct clk_hw *hw,
-                                                   unsigned long parent_accuracy);
+                                                unsigned long parent_accuracy);
                 void            (*init)(struct clk_hw *hw);
+                int             (*debug_init)(struct clk_hw *hw,
+                                              struct dentry *dentry);
         };
 
         Part 3 - hardware clk implementations
diff --git a/Documentation/connector/connector.txt b/Documentation/connector/connector.txt
index e5c5f5e6ab70..f6215f95149b 100644
--- a/Documentation/connector/connector.txt
+++ b/Documentation/connector/connector.txt
@@ -24,7 +24,8 @@ netlink based networking for inter-process communication in a significantly
 easier way:
 
 int cn_add_callback(struct cb_id *id, char *name, void (*callback) (struct cn_msg *, struct netlink_skb_parms *));
-void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask);
+void cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __group, int gfp_mask);
+void cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __group, int gfp_mask);
 
 struct cb_id
 {
@@ -71,15 +72,21 @@ void cn_del_callback(struct cb_id *id);
  struct cb_id *id               - unique connector's user identifier.
 
 
-int cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);
+int cn_netlink_send_multi(struct cn_msg *msg, u16 len, u32 portid, u32 __groups, int gfp_mask);
+int cn_netlink_send(struct cn_msg *msg, u32 portid, u32 __groups, int gfp_mask);
 
  Sends message to the specified groups.  It can be safely called from
  softirq context, but may silently fail under strong memory pressure.
  If there are no listeners for given group -ESRCH can be returned.
 
  struct cn_msg *                - message header(with attached data).
+ u16 len                        - for *_multi multiple cn_msg messages can be sent
+ u32 port                       - destination port.
+                                  If non-zero the message will be sent to the
+                                  given port, which should be set to the
+                                  original sender.
  u32 __group                    - destination group.
-                                  If __group is zero, then appropriate group will
+                                  If port and __group is zero, then appropriate group will
                                   be searched through all registered connector users,
                                   and message will be delivered to the group which was
                                   created for user with the same ID as in msg.
@@ -111,7 +118,7 @@ acknowledge number MUST be the same + 1.
 If we receive a message and its sequence number is not equal to one we
 are expecting, then it is a new message.  If we receive a message and
 its sequence number is the same as one we are expecting, but its
-acknowledge is not equal to the acknowledge number in the original
+acknowledge is not equal to the sequence number in the original
 message + 1, then it is a new message.
 
 Obviously, the protocol header contains the above id.
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index 0060d76b445f..70933eadc308 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -20,6 +20,7 @@ Contents:
 ---------
 1.  CPUFreq core and interfaces
 2.  CPUFreq notifiers
+3.  CPUFreq Table Generation with Operating Performance Point (OPP)
 
 1. General Information
 =======================
@@ -92,3 +93,31 @@ values:
 cpu     - number of the affected CPU
 old     - old frequency
 new     - new frequency
+
+3. CPUFreq Table Generation with Operating Performance Point (OPP)
+==================================================================
+For details about OPP, see Documentation/power/opp.txt
+
+dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
+        cpufreq_frequency_table_cpuinfo which is provided with the list of
+        frequencies that are available for operation. This function provides
+        a ready to use conversion routine to translate the OPP layer's internal
+        information about the available frequencies into a format readily
+        providable to cpufreq.
+
+        WARNING: Do not use this function in interrupt context.
+
+        Example:
+         soc_pm_init()
+         {
+                /* Do things */
+                r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
+                if (!r)
+                        cpufreq_frequency_table_cpuinfo(policy, freq_table);
+                /* Do other things */
+         }
+
+        NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
+        addition to CONFIG_PM_OPP.
+
+dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index 48da5fdcb9f1..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
@@ -228,3 +253,22 @@ is the corresponding frequency table helper for the ->target
 stage. Just pass the values to this function, and the unsigned int
 index returns the number of the frequency table entry which contains
 the frequency the CPU shall be set to.
+
+The following macros can be used as iterators over cpufreq_frequency_table:
+
+cpufreq_for_each_entry(pos, table) - iterates over all entries of frequency
+table.
+
+cpufreq-for_each_valid_entry(pos, table) - iterates over all entries,
+excluding CPUFREQ_ENTRY_INVALID frequencies.
+Use arguments "pos" - a cpufreq_frequency_table * as a loop cursor and
+"table" - the cpufreq_frequency_table * you want to iterate over.
+
+For example:
+
+        struct cpufreq_frequency_table *pos, *driver_freq_table;
+
+        cpufreq_for_each_entry(pos, driver_freq_table) {
+                /* Do something with pos */
+                pos->frequency = ...
+        }
diff --git a/Documentation/cpu-freq/index.txt b/Documentation/cpu-freq/index.txt
index 3d0b915035b9..dc024ab4054f 100644
--- a/Documentation/cpu-freq/index.txt
+++ b/Documentation/cpu-freq/index.txt
@@ -35,8 +35,8 @@ Mailing List
 ------------
 There is a CPU frequency changing CVS commit and general list where
 you can report bugs, problems or submit patches. To post a message,
-send an email to cpufreq@vger.kernel.org, to subscribe go to
-http://vger.kernel.org/vger-lists.html#cpufreq and follow the
+send an email to linux-pm@vger.kernel.org, to subscribe go to
+http://vger.kernel.org/vger-lists.html#linux-pm and follow the
 instructions there.
 
 Links
diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt
index fa0151a712f9..5c9a567b3fac 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -25,9 +25,11 @@ using data transfer rates in the order of 10MB/s or more.
 With most FireWire controllers, memory access is limited to the low 4 GB
 of physical address space.  This can be a problem on IA64 machines where
 memory is located mostly above that limit, but it is rarely a problem on
-more common hardware such as x86, x86-64 and PowerPC.  However, at least
-Agere/LSI FW643e and FW643e2 controllers are known to support access to
-physical addresses above 4 GB.
+more common hardware such as x86, x86-64 and PowerPC.
+
+At least LSI FW643e and FW643e2 controllers are known to support access to
+physical addresses above 4 GB, but this feature is currently not enabled by
+Linux.
 
 Together with a early initialization of the OHCI-1394 controller for debugging,
 this facility proved most useful for examining long debugs logs in the printk
@@ -101,8 +103,9 @@ Step-by-step instructions for using firescope with early OHCI initialization:
    compliant, they are based on TI PCILynx chips and require drivers for Win-
    dows operating systems.
 
-   The mentioned kernel log message contains ">4 GB phys DMA" in case of
-   OHCI-1394 controllers which support accesses above this limit.
+   The mentioned kernel log message contains the string "physUB" if the
+   controller implements a writable Physical Upper Bound register.  This is
+   required for physical DMA above 4 GB (but not utilized by Linux yet).
 
 2) Establish a working FireWire cable connection:
 
diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt
index 05a27e9442bd..2f5173500bd9 100644
--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@@ -309,7 +309,10 @@ ii) Status
     error_if_no_space|queue_if_no_space
         If the pool runs out of data or metadata space, the pool will
         either queue or error the IO destined to the data device.  The
-        default is to queue the IO until more space is added.
+        default is to queue the IO until more space is added or the
+        'no_space_timeout' expires.  The 'no_space_timeout' dm-thin-pool
+        module parameter can be used to change this timeout -- it
+        defaults to 60 seconds but may be disabled using a value of 0.
 
 iii) Messages
 
diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
index 06fc7602593a..37b2cafa4e52 100644
--- a/Documentation/devicetree/bindings/arm/arch_timer.txt
+++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
@@ -19,6 +19,9 @@ to deliver its interrupts via SPIs.
 
 - clock-frequency : The frequency of the main counter, in Hz. Optional.
 
+- always-on : a boolean property. If present, the timer is powered through an
+  always-on power domain, therefore it never loses context.
+
 Example:
 
         timer {
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
index 926b4d6aae7e..26799ef562df 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
@@ -1,20 +1,21 @@
 Power Management Service Unit(PMSU)
 -----------------------------------
-Available on Marvell SOCs: Armada 370 and Armada XP
+Available on Marvell SOCs: Armada 370, Armada 38x and Armada XP
 
 Required properties:
 
-- compatible: "marvell,armada-370-xp-pmsu"
+- compatible: should be one of:
+  - "marvell,armada-370-pmsu" for Armada 370 or Armada XP
+  - "marvell,armada-380-pmsu" for Armada 38x
+  - "marvell,armada-370-xp-pmsu" was used for Armada 370/XP but is now
+    deprecated and will be removed
 
-- reg: Should contain PMSU registers location and length. First pair
-  for the per-CPU SW Reset Control registers, second pair for the
-  Power Management Service Unit.
+- reg: Should contain PMSU registers location and length.
 
 Example:
 
-armada-370-xp-pmsu@d0022000 {
-        compatible = "marvell,armada-370-xp-pmsu";
-        reg = <0xd0022100 0x430>,
-              <0xd0020800 0x20>;
+armada-370-xp-pmsu@22000 {
+        compatible = "marvell,armada-370-pmsu";
+        reg = <0x22000 0x1000>;
 };
 
diff --git a/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt b/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt
new file mode 100644
index 000000000000..b63a7b6ab998
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-cpu-reset.txt
@@ -0,0 +1,14 @@
+Marvell Armada CPU reset controller
+===================================
+
+Required properties:
+
+- compatible: Should be "marvell,armada-370-cpu-reset".
+
+- reg: should be register base and length as documented in the
+  datasheet for the CPU reset registers
+
+cpurst: cpurst@20800 {
+       compatible = "marvell,armada-370-cpu-reset";
+       reg = <0x20800 0x20>;
+};
diff --git a/Documentation/devicetree/bindings/arm/axxia.txt b/Documentation/devicetree/bindings/arm/axxia.txt
new file mode 100644
index 000000000000..7b4ef9c07696
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/axxia.txt
@@ -0,0 +1,12 @@
+Axxia AXM55xx device tree bindings
+
+Boards using the AXM55xx SoC need to have the following properties:
+
+Required root node property:
+
+  - compatible = "lsi,axm5516"
+
+Boards:
+
+  LSI AXM5516 Validation board (Amarillo)
+        compatible = "lsi,axm5516-amarillo", "lsi,axm5516"
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
index 17d8cd107559..8dd46617c889 100644
--- a/Documentation/devicetree/bindings/arm/coherency-fabric.txt
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -1,16 +1,33 @@
 Coherency fabric
 ----------------
-Available on Marvell SOCs: Armada 370 and Armada XP
+Available on Marvell SOCs: Armada 370, Armada 375, Armada 38x and Armada XP
 
 Required properties:
 
-- compatible: "marvell,coherency-fabric"
+- compatible: the possible values are:
+
+ * "marvell,coherency-fabric", to be used for the coherency fabric of
+   the Armada 370 and Armada XP.
+
+ * "marvell,armada-375-coherency-fabric", for the Armada 375 coherency
+   fabric.
+
+ * "marvell,armada-380-coherency-fabric", for the Armada 38x coherency
+   fabric.
 
 - reg: Should contain coherency fabric registers location and
-  length. First pair for the coherency fabric registers, second pair
-  for the per-CPU fabric registers registers.
+  length.
+
+ * For "marvell,coherency-fabric", the first pair for the coherency
+   fabric registers, second pair for the per-CPU fabric registers.
 
-Example:
+ * For "marvell,armada-375-coherency-fabric", only one pair is needed
+   for the per-CPU fabric registers.
+
+ * For "marvell,armada-380-coherency-fabric", only one pair is needed
+   for the per-CPU fabric registers.
+
+Examples:
 
 coherency-fabric@d0020200 {
         compatible = "marvell,coherency-fabric";
@@ -19,3 +36,8 @@ coherency-fabric@d0020200 {
 
 };
 
+coherency-fabric@21810 {
+        compatible = "marvell,armada-375-coherency-fabric";
+        reg = <0x21810 0x1c>;
+};
+
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 333f4aea3029..1fe72a0778cd 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -178,13 +178,19 @@ nodes to be present and contain the properties described below.
                 Usage and definition depend on ARM architecture version.
                         # On ARM v8 64-bit this property is required and must
                           be one of:
-                             "spin-table"
                              "psci"
+                             "spin-table"
                         # On ARM 32-bit systems this property is optional and
                           can be one of:
+                            "allwinner,sun6i-a31"
+                            "arm,psci"
+                            "marvell,armada-375-smp"
+                            "marvell,armada-380-smp"
+                            "marvell,armada-xp-smp"
                             "qcom,gcc-msm8660"
                             "qcom,kpss-acc-v1"
                             "qcom,kpss-acc-v2"
+                            "rockchip,rk3066-smp"
 
         - cpu-release-addr
                 Usage: required for systems that have an "enable-method"
diff --git a/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
new file mode 100644
index 000000000000..4a0a4f70a0ce
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/exynos/smp-sysram.txt
@@ -0,0 +1,38 @@
+Samsung Exynos SYSRAM for SMP bringup:
+------------------------------------
+
+Samsung SMP-capable Exynos SoCs use part of the SYSRAM for the bringup
+of the secondary cores. Once the core gets powered up it executes the
+code that is residing at some specific location of the SYSRAM.
+
+Therefore reserved section sub-nodes have to be added to the mmio-sram
+declaration. These nodes are of two types depending upon secure or
+non-secure execution environment.
+
+Required sub-node properties:
+- compatible : depending upon boot mode, should be
+                "samsung,exynos4210-sysram" : for Secure SYSRAM
+                "samsung,exynos4210-sysram-ns" : for Non-secure SYSRAM
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sysram.txt
+
+Example:
+
+        sysram@02020000 {
+                compatible = "mmio-sram";
+                reg = <0x02020000 0x54000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges = <0 0x02020000 0x54000>;
+
+                smp-sysram@0 {
+                        compatible = "samsung,exynos4210-sysram";
+                        reg = <0x0 0x1000>;
+                };
+
+                smp-sysram@53000 {
+                        compatible = "samsung,exynos4210-sysram-ns";
+                        reg = <0x53000 0x1000>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/arm/global_timer.txt b/Documentation/devicetree/bindings/arm/global_timer.txt
index 1e548981eda4..bdae3a818793 100644
--- a/Documentation/devicetree/bindings/arm/global_timer.txt
+++ b/Documentation/devicetree/bindings/arm/global_timer.txt
@@ -4,8 +4,11 @@
 
 ** Timer node required properties:
 
-- compatible : Should be "arm,cortex-a9-global-timer"
-                Driver supports versions r2p0 and above.
+- compatible : should contain
+             * "arm,cortex-a5-global-timer" for Cortex-A5 global timers.
+             * "arm,cortex-a9-global-timer" for Cortex-A9 global
+                 timers or any compatible implementation. Note: driver
+                 supports versions r2p0 and above.
 
 - interrupts : One interrupt to each core
 
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
index 737afa5f8148..94013a9a8769 100644
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -12,6 +12,7 @@ SoC and board used. Currently known SoC compatibles are:
     "marvell,berlin2"      for Marvell Armada 1500 (BG2, 88DE3100),
     "marvell,berlin2cd"    for Marvell Armada 1500-mini (BG2CD, 88DE3005)
     "marvell,berlin2ct"    for Marvell Armada ? (BG2CT, 88DE????)
+    "marvell,berlin2q"     for Marvell Armada 1500-pro (BG2Q, 88DE3114)
     "marvell,berlin3"      for Marvell Armada ? (BG3, 88DE????)
 
 * Example:
@@ -22,3 +23,104 @@ SoC and board used. Currently known SoC compatibles are:
 
         ...
 }
+
+* Marvell Berlin2 chip control binding
+
+Marvell Berlin SoCs have a chip control register set providing several
+individual registers dealing with pinmux, padmux, clock, reset, and secondary
+CPU boot address. Unfortunately, the individual registers are spread among the
+chip control registers, so there should be a single DT node only providing the
+different functions which are described below.
+
+Required properties:
+- compatible: shall be one of
+        "marvell,berlin2-chip-ctrl" for BG2
+        "marvell,berlin2cd-chip-ctrl" for BG2CD
+        "marvell,berlin2q-chip-ctrl" for BG2Q
+- reg: address and length of following register sets for
+  BG2/BG2CD: chip control register set
+  BG2Q: chip control register set and cpu pll registers
+
+* Marvell Berlin2 system control binding
+
+Marvell Berlin SoCs have a system control register set providing several
+individual registers dealing with pinmux, padmux, and reset.
+
+Required properties:
+- compatible: should be one of
+        "marvell,berlin2-system-ctrl" for BG2
+        "marvell,berlin2cd-system-ctrl" for BG2CD
+        "marvell,berlin2q-system-ctrl" for BG2Q
+- reg: address and length of the system control register set
+
+* Clock provider binding
+
+As clock related registers are spread among the chip control registers, the
+chip control node also provides the clocks. Marvell Berlin2 (BG2, BG2CD, BG2Q)
+SoCs share the same IP for PLLs and clocks, with some minor differences in
+features and register layout.
+
+Required properties:
+- #clock-cells: shall be set to 1
+- clocks: clock specifiers referencing the core clock input clocks
+- clock-names: array of strings describing the input clock specifiers above.
+    Allowed clock-names for the reference clocks are
+      "refclk" for the SoCs osciallator input on all SoCs,
+    and SoC-specific input clocks for
+      BG2/BG2CD: "video_ext0" for the external video clock input
+
+Clocks provided by core clocks shall be referenced by a clock specifier
+indexing one of the provided clocks. Refer to dt-bindings/clock/berlin<soc>.h
+for the corresponding index mapping.
+
+* Pin controller binding
+
+Pin control registers are part of both register sets, chip control and system
+control. The pins controlled are organized in groups, so no actual pin
+information is needed.
+
+A pin-controller node should contain subnodes representing the pin group
+configurations, one per function. Each subnode has the group name and the muxing
+function used.
+
+Be aware the Marvell Berlin datasheets use the keyword 'mode' for what is called
+a 'function' in the pin-controller subsystem.
+
+Required subnode-properties:
+- groups: a list of strings describing the group names.
+- function: a string describing the function used to mux the groups.
+
+Example:
+
+chip: chip-control@ea0000 {
+        compatible = "marvell,berlin2-chip-ctrl";
+        #clock-cells = <1>;
+        reg = <0xea0000 0x400>;
+        clocks = <&refclk>, <&externaldev 0>;
+        clock-names = "refclk", "video_ext0";
+
+        spi1_pmux: spi1-pmux {
+                groups = "G0";
+                function = "spi1";
+        };
+};
+
+sysctrl: system-controller@d000 {
+        compatible = "marvell,berlin2-system-ctrl";
+        reg = <0xd000 0x100>;
+
+        uart0_pmux: uart0-pmux {
+                groups = "GSM4";
+                function = "uart0";
+        };
+
+        uart1_pmux: uart1-pmux {
+                groups = "GSM5";
+                function = "uart1";
+        };
+
+        uart2_pmux: uart2-pmux {
+                groups = "GSM3";
+                function = "uart2";
+        };
+};
diff --git a/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
new file mode 100644
index 000000000000..925ecbf6e7b7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
@@ -0,0 +1,97 @@
+Marvell Kirkwood SoC Family Device Tree Bindings
+------------------------------------------------
+
+Boards with a SoC of the Marvell Kirkwook family, eg 88f6281
+
+* Required root node properties:
+compatible: must contain "marvell,kirkwood"
+
+In addition, the above compatible shall be extended with the specific
+SoC. Currently known SoC compatibles are:
+
+"marvell,kirkwood-88f6192"
+"marvell,kirkwood-88f6281"
+"marvell,kirkwood-88f6282"
+"marvell,kirkwood-88f6283"
+"marvell,kirkwood-88f6702"
+"marvell,kirkwood-98DX4122"
+
+And in addition, the compatible shall be extended with the specific
+board. Currently known boards are:
+
+"buffalo,lschlv2"
+"buffalo,lsxhl"
+"buffalo,lsxl"
+"dlink,dns-320"
+"dlink,dns-320-a1"
+"dlink,dns-325"
+"dlink,dns-325-a1"
+"dlink,dns-kirkwood"
+"excito,b3"
+"globalscale,dreamplug-003-ds2001"
+"globalscale,guruplug"
+"globalscale,guruplug-server-plus"
+"globalscale,sheevaplug"
+"globalscale,sheevaplug"
+"globalscale,sheevaplug-esata"
+"globalscale,sheevaplug-esata-rev13"
+"iom,iconnect"
+"iom,iconnect-1.1"
+"iom,ix2-200"
+"keymile,km_kirkwood"
+"lacie,cloudbox"
+"lacie,inetspace_v2"
+"lacie,laplug"
+"lacie,netspace_lite_v2"
+"lacie,netspace_max_v2"
+"lacie,netspace_mini_v2"
+"lacie,netspace_v2"
+"marvell,db-88f6281-bp"
+"marvell,db-88f6282-bp"
+"marvell,mv88f6281gtw-ge"
+"marvell,rd88f6281"
+"marvell,rd88f6281"
+"marvell,rd88f6281-a0"
+"marvell,rd88f6281-a1"
+"mpl,cec4"
+"mpl,cec4-10"
+"netgear,readynas"
+"netgear,readynas"
+"netgear,readynas-duo-v2"
+"netgear,readynas-nv+-v2"
+"plathome,openblocks-a6"
+"plathome,openblocks-a7"
+"raidsonic,ib-nas6210"
+"raidsonic,ib-nas6210-b"
+"raidsonic,ib-nas6220"
+"raidsonic,ib-nas6220-b"
+"raidsonic,ib-nas62x0"
+"seagate,dockstar"
+"seagate,goflexnet"
+"synology,ds109"
+"synology,ds110jv10"
+"synology,ds110jv20"
+"synology,ds110jv30"
+"synology,ds111"
+"synology,ds209"
+"synology,ds210jv10"
+"synology,ds210jv20"
+"synology,ds212"
+"synology,ds212jv10"
+"synology,ds212jv20"
+"synology,ds212pv10"
+"synology,ds409"
+"synology,ds409slim"
+"synology,ds410j"
+"synology,ds411"
+"synology,ds411j"
+"synology,ds411slim"
+"synology,ds413jv10"
+"synology,rs212"
+"synology,rs409"
+"synology,rs411"
+"synology,rs812"
+"usi,topkick"
+"usi,topkick-1281P2"
+"zyxel,nsa310"
+"zyxel,nsa310a"
diff --git a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
index c0105de55cbd..974624ea68f6 100644
--- a/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
+++ b/Documentation/devicetree/bindings/arm/omap/l3-noc.txt
@@ -6,6 +6,8 @@ provided by Arteris.
 Required properties:
 - compatible : Should be "ti,omap3-l3-smx" for OMAP3 family
                Should be "ti,omap4-l3-noc" for OMAP4 family
+               Should be "ti,dra7-l3-noc" for DRA7 family
+               Should be "ti,am4372-l3-noc" for AM43 family
 - reg:  Contains L3 register address range for each noc domain.
 - ti,hwmods: "l3_main_1", ... One hwmod for each noc domain.
 
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 36ede19a1630..d22b216f5d23 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -80,7 +80,10 @@ SoCs:
   compatible = "ti,omap5432", "ti,omap5"
 
 - DRA742
-  compatible = "ti,dra7xx", "ti,dra7"
+  compatible = "ti,dra742", "ti,dra74", "ti,dra7"
+
+- DRA722
+  compatible = "ti,dra722", "ti,dra72", "ti,dra7"
 
 - AM4372
   compatible = "ti,am4372", "ti,am43"
@@ -102,6 +105,12 @@ Boards:
 - OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
   compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
 
+- OMAP4 VAR-STK-OM44 : Commercial dev kit with VAR-OM44CustomBoard and VAR-SOM-OM44 w/WLAN
+  compatible = "variscite,var-stk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
+
+- OMAP4 VAR-DVK-OM44 : Commercial dev kit with VAR-OM44CustomBoard, VAR-SOM-OM44 w/WLAN and LCD touchscreen
+  compatible = "variscite,var-dvk-om44", "variscite,var-som-om44", "ti,omap4460", "ti,omap4";
+
 - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
   compatible = "ti,omap3-evm", "ti,omap3"
 
@@ -120,5 +129,8 @@ Boards:
 - AM437x GP EVM
   compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
 
-- DRA7 EVM:  Software Developement Board for DRA7XX
-  compatible = "ti,dra7-evm", "ti,dra7"
+- DRA742 EVM:  Software Development Board for DRA742
+  compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
+
+- DRA722 EVM: Software Development Board for DRA722
+  compatible = "ti,dra72-evm", "ti,dra722", "ti,dra72", "ti,dra7"
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
index fe5cef8976cb..75ef91d08f3b 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -8,6 +8,7 @@ Required properties:
 
 - compatible : should be one of
         "arm,armv8-pmuv3"
+        "arm,cortex-a17-pmu"
         "arm,cortex-a15-pmu"
         "arm,cortex-a12-pmu"
         "arm,cortex-a9-pmu"
diff --git a/Documentation/devicetree/bindings/arm/psci.txt b/Documentation/devicetree/bindings/arm/psci.txt
index 433afe9cb590..b4a58f39223c 100644
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -21,7 +21,15 @@ to #0.
 
 Main node required properties:
 
- - compatible    : Must be "arm,psci"
+ - compatible    : should contain at least one of:
+
+                                 * "arm,psci" : for implementations complying to PSCI versions prior to
+                                        0.2. For these cases function IDs must be provided.
+
+                                 * "arm,psci-0.2" : for implementations complying to PSCI 0.2. Function
+                                        IDs are not required and should be ignored by an OS with PSCI 0.2
+                                        support, but are permitted to be present for compatibility with
+                                        existing software when "arm,psci" is later in the compatible list.
 
  - method        : The method of calling the PSCI firmware. Permitted
                    values are:
@@ -45,6 +53,8 @@ Main node optional properties:
 
 Example:
 
+Case 1: PSCI v0.1 only.
+
         psci {
                 compatible      = "arm,psci";
                 method          = "smc";
@@ -53,3 +63,28 @@ Example:
                 cpu_on          = <0x95c10002>;
                 migrate         = <0x95c10003>;
         };
+
+
+Case 2: PSCI v0.2 only
+
+        psci {
+                compatible      = "arm,psci-0.2";
+                method          = "smc";
+        };
+
+Case 3: PSCI v0.2 and PSCI v0.1.
+
+        A DTB may provide IDs for use by kernels without PSCI 0.2 support,
+        enabling firmware and hypervisors to support existing and new kernels.
+        These IDs will be ignored by kernels with PSCI 0.2 support, which will
+        use the standard PSCI 0.2 IDs exclusively.
+
+        psci {
+                compatible = "arm,psci-0.2", "arm,psci";
+                method = "hvc";
+
+                cpu_on = < arbitrary value >;
+                cpu_off = < arbitrary value >;
+
+                ...
+        };
diff --git a/Documentation/devicetree/bindings/arm/rockchip.txt b/Documentation/devicetree/bindings/arm/rockchip.txt
new file mode 100644
index 000000000000..857f12636eb2
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip.txt
@@ -0,0 +1,10 @@
+Rockchip platforms device tree bindings
+---------------------------------------
+
+- bq Curie 2 tablet:
+    Required root node properties:
+      - compatible = "mundoreader,bq-curie2", "rockchip,rk3066a";
+
+- Radxa Rock board:
+    Required root node properties:
+      - compatible = "radxa,rock", "rockchip,rk3188";
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
index f1f155255f28..2a4ab046a8a1 100644
--- a/Documentation/devicetree/bindings/arm/samsung/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -2,6 +2,10 @@ SAMSUNG Exynos SoC series PMU Registers
 
 Properties:
  - compatible : should contain two values. First value must be one from following list:
+                   - "samsung,exynos3250-pmu" - for Exynos3250 SoC,
+                   - "samsung,exynos4210-pmu" - for Exynos4210 SoC,
+                   - "samsung,exynos4212-pmu" - for Exynos4212 SoC,
+                   - "samsung,exynos4412-pmu" - for Exynos4412 SoC,
                    - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
                    - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
                 second value must be always "syscon".
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 0ab3251a6ec2..4fced6e9d5e4 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -1,8 +1,10 @@
 SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
 
 Properties:
- - compatible : should contain "samsung,<chip name>-sysreg", "syscon";
-   For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
+ - compatible : should contain two values. First value must be one from following list:
+                - "samsung,exynos4-sysreg" - for Exynos4 based SoCs,
+                - "samsung,exynos5-sysreg" - for Exynos5 based SoCs.
+                second value must be always "syscon".
  - reg : offset and length of the register set.
 
 Example:
@@ -10,3 +12,8 @@ Example:
                 compatible = "samsung,exynos4-sysreg", "syscon";
                 reg = <0x10010000 0x400>;
         };
+
+        syscon@10050000 {
+                compatible = "samsung,exynos5-sysreg", "syscon";
+                reg = <0x10050000 0x5000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/sti.txt b/Documentation/devicetree/bindings/arm/sti.txt
new file mode 100644
index 000000000000..92f16c78bb69
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/sti.txt
@@ -0,0 +1,15 @@
+ST STi Platforms Device Tree Bindings
+---------------------------------------
+
+Boards with the ST STiH415 SoC shall have the following properties:
+Required root node property:
+compatible = "st,stih415";
+
+Boards with the ST STiH416 SoC shall have the following properties:
+Required root node property:
+compatible = "st,stih416";
+
+Boards with the ST STiH407 SoC shall have the following properties:
+Required root node property:
+compatible = "st,stih407";
+
diff --git a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
index 5580e9c4bd85..00318d083c9e 100644
--- a/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
@@ -8,6 +8,8 @@ interrupt generation, MMC and NOR Flash control etc.
 Required node properties:
 - compatible value : = "arm,vexpress,sysreg";
 - reg : physical base address and the size of the registers window
+
+Deprecated properties, replaced by GPIO subnodes (see below):
 - gpio-controller : specifies that the node is a GPIO controller
 - #gpio-cells : size of the GPIO specifier, should be 2:
   - first cell is the pseudo-GPIO line number:
@@ -16,35 +18,86 @@ Required node properties:
     2 - NOR FLASH WPn
   - second cell can take standard GPIO flags (currently ignored).
 
+Control registers providing pseudo-GPIO lines must be represented
+by subnodes, each of them requiring the following properties:
+- compatible value : one of
+                        "arm,vexpress-sysreg,sys_led"
+                        "arm,vexpress-sysreg,sys_mci"
+                        "arm,vexpress-sysreg,sys_flash"
+- gpio-controller : makes the node a GPIO controller
+- #gpio-cells : size of the GPIO specifier, must be 2:
+  - first cell is the function number:
+    - for sys_led : 0..7 = LED 0..7
+    - for sys_mci : 0 = MMC CARDIN, 1 = MMC WPROT
+    - for sys_flash : 0 = NOR FLASH WPn
+  - second cell can take standard GPIO flags (currently ignored).
+
 Example:
         v2m_sysreg: sysreg@10000000 {
                 compatible = "arm,vexpress-sysreg";
                 reg = <0x10000000 0x1000>;
-                gpio-controller;
-                #gpio-cells = <2>;
+
+                v2m_led_gpios: sys_led@08 {
+                        compatible = "arm,vexpress-sysreg,sys_led";
+                        gpio-controller;
+                        #gpio-cells = <2>;
+                };
+
+                v2m_mmc_gpios: sys_mci@48 {
+                        compatible = "arm,vexpress-sysreg,sys_mci";
+                        gpio-controller;
+                        #gpio-cells = <2>;
+                };
+
+                v2m_flash_gpios: sys_flash@4c {
+                        compatible = "arm,vexpress-sysreg,sys_flash";
+                        gpio-controller;
+                        #gpio-cells = <2>;
+                };
         };
 
 This block also can also act a bridge to the platform's configuration
 bus via "system control" interface, addressing devices with site number,
 position in the board stack, config controller, function and device
-numbers - see motherboard's TRM for more details.
-
-The node describing a config device must refer to the sysreg node via
-"arm,vexpress,config-bridge" phandle (can be also defined in the node's
-parent) and relies on the board topology properties - see main vexpress
-node documentation for more details. It must also define the following
-property:
-- arm,vexpress-sysreg,func : must contain two cells:
-  - first cell defines function number (eg. 1 for clock generator,
-    2 for voltage regulators etc.)
-  - device number (eg. osc 0, osc 1 etc.)
+numbers - see motherboard's TRM for more details. All configuration
+controller accessible via this interface must reference the sysreg
+node via "arm,vexpress,config-bridge" phandle and define appropriate
+topology properties - see main vexpress node documentation for more
+details. Each child of such node describes one function and must
+define the following properties:
+- compatible value : must be one of (corresponding to the TRM):
+        "arm,vexpress-amp"
+        "arm,vexpress-dvimode"
+        "arm,vexpress-energy"
+        "arm,vexpress-muxfpga"
+        "arm,vexpress-osc"
+        "arm,vexpress-power"
+        "arm,vexpress-reboot"
+        "arm,vexpress-reset"
+        "arm,vexpress-scc"
+        "arm,vexpress-shutdown"
+        "arm,vexpress-temp"
+        "arm,vexpress-volt"
+- arm,vexpress-sysreg,func : must contain a set of two cells long groups:
+  - first cell of each group defines the function number
+    (eg. 1 for clock generator, 2 for voltage regulators etc.)
+  - second cell of each group defines device number (eg. osc 0,
+    osc 1 etc.)
+  - some functions (eg. energy meter, with its 64 bit long counter)
+    are using more than one function/device number pair
 
 Example:
         mcc {
+                compatible = "arm,vexpress,config-bus";
                 arm,vexpress,config-bridge = <&v2m_sysreg>;
 
                 osc@0 {
                         compatible = "arm,vexpress-osc";
                         arm,vexpress-sysreg,func = <1 0>;
                 };
+
+                energy@0 {
+                        compatible = "arm,vexpress-energy";
+                        arm,vexpress-sysreg,func = <13 0>, <13 1>;
+                };
         };
diff --git a/Documentation/devicetree/bindings/arm/vexpress.txt b/Documentation/devicetree/bindings/arm/vexpress.txt
index ae49161e478a..39844cd0bcce 100644
--- a/Documentation/devicetree/bindings/arm/vexpress.txt
+++ b/Documentation/devicetree/bindings/arm/vexpress.txt
@@ -80,12 +80,17 @@ but also control clock generators, voltage regulators, gather
 environmental data like temperature, power consumption etc. Even
 the video output switch (FPGA) is controlled that way.
 
-Nodes describing devices controlled by this infrastructure should
-point at the bridge device node:
+The controllers are not mapped into normal memory address space
+and must be accessed through bridges - other devices capable
+of generating transactions on the configuration bus.
+
+The nodes describing configuration controllers must define
+the following properties:
+- compatible value:
+        compatible = "arm,vexpress,config-bus";
 - bridge phandle:
         arm,vexpress,config-bridge = <phandle>;
-This property can be also defined in a parent node (eg. for a DCC)
-and is effective for all children.
+and children describing available functions.
 
 
 Platform topology
@@ -197,7 +202,7 @@ Example of a VE tile description (simplified)
         };
 
         dcc {
-                compatible = "simple-bus";
+                compatible = "arm,vexpress,config-bus";
                 arm,vexpress,config-bridge = <&v2m_sysreg>;
 
                 osc@0 {
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",
-                      "snps,exynos5440-ahci", "ibm,476gtr-ahci",
-                      "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci"
-                      "fsl,imx6q-ahci" or "snps,dwc-ahci"
+- compatible        : compatible string, one of:
+  - "allwinner,sun4i-a10-ahci"
+  - "fsl,imx53-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/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt
index 7bcfbf59810e..a668f0e7d001 100644
--- a/Documentation/devicetree/bindings/ata/apm-xgene.txt
+++ b/Documentation/devicetree/bindings/ata/apm-xgene.txt
@@ -24,6 +24,7 @@ Required properties:
   * "sata-phy" for the SATA 6.0Gbps PHY
 
 Optional properties:
+- dma-coherent          : Present if dma operations are coherent
 - status                : Shall be "ok" if enabled or "disabled" if disabled.
                           Default is "ok".
 
@@ -55,6 +56,7 @@ Example:
                               <0x0 0x1f22e000 0x0 0x1000>,
                               <0x0 0x1f227000 0x0 0x1000>;
                         interrupts = <0x0 0x87 0x4>;
+                        dma-coherent;
                         status = "ok";
                         clocks = <&sataclk 0>;
                         phys = <&phy2 0>;
@@ -69,6 +71,7 @@ Example:
                               <0x0 0x1f23e000 0x0 0x1000>,
                               <0x0 0x1f237000 0x0 0x1000>;
                         interrupts = <0x0 0x88 0x4>;
+                        dma-coherent;
                         status = "ok";
                         clocks = <&sataclk 0>;
                         phys = <&phy3 0>;
diff --git a/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
new file mode 100644
index 000000000000..e2d501d20c9a
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/brcm,gisb-arb.txt
@@ -0,0 +1,30 @@
+Broadcom GISB bus Arbiter controller
+
+Required properties:
+
+- compatible: should be "brcm,gisb-arb"
+- reg: specifies the base physical address and size of the registers
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+  this arbiter gets interrupt line from
+- interrupts: specifies the two interrupts (timeout and TEA) to be used from
+  the parent interrupt controller
+
+Optional properties:
+
+- brcm,gisb-arb-master-mask: 32-bits wide bitmask used to specify which GISB
+  masters are valid at the system level
+- brcm,gisb-arb-master-names: string list of the litteral name of the GISB
+  masters. Should match the number of bits set in brcm,gisb-master-mask and
+  the order in which they appear
+
+Example:
+
+gisb-arb@f0400000 {
+        compatible = "brcm,gisb-arb";
+        reg = <0xf0400000 0x800>;
+        interrupts = <0>, <2>;
+        interrupt-parent = <&sun_l2_intc>;
+
+        brcm,gisb-arb-master-mask = <0x7>;
+        brcm,gisb-arb-master-names = "bsp_0", "scpu_0", "cpu_0";
+};
diff --git a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
index 7586fb68c072..5fa44f52a0b8 100644
--- a/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
+++ b/Documentation/devicetree/bindings/bus/mvebu-mbus.txt
@@ -197,7 +197,7 @@ to be set by the operating system and that are guaranteed to be free of overlaps
 with one another or with the system memory ranges.
 
 Each entry in the property refers to exactly one window. If the operating system
-choses to use a different set of mbus windows, it must ensure that any address
+chooses to use a different set of mbus windows, it must ensure that any address
 translations performed from downstream devices are adapted accordingly.
 
 The operating system may insert additional mbus windows that do not conflict
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
index 5dfd145d3ccf..f72e80e0dade 100644
--- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -21,8 +21,8 @@ Optional properties:
 - fixed-divider : If clocks have a fixed divider value, use this property.
 - clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register
         and the bit index.
-- div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift,
-        and width.
+- div-reg : For "socfpga-gate-clk" and "socfpga-periph-clock", div-reg contains
+        the divider register, bit shift, and width.
 - clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls
         the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second
         value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct
diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
index cd5e23912888..b3d544ca522a 100644
--- a/Documentation/devicetree/bindings/clock/at91-clock.txt
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -6,6 +6,16 @@ This binding uses the common clock binding[1].
 
 Required properties:
 - compatible : shall be one of the following:
+        "atmel,at91sam9x5-sckc":
+                at91 SCKC (Slow Clock Controller)
+                This node contains the slow clock definitions.
+
+        "atmel,at91sam9x5-clk-slow-osc":
+                at91 slow oscillator
+
+        "atmel,at91sam9x5-clk-slow-rc-osc":
+                at91 internal slow RC oscillator
+
         "atmel,at91rm9200-pmc" or
         "atmel,at91sam9g45-pmc" or
         "atmel,at91sam9n12-pmc" or
@@ -15,8 +25,18 @@ Required properties:
                 All at91 specific clocks (clocks defined below) must be child
                 node of the PMC node.
 
+        "atmel,at91sam9x5-clk-slow" (under sckc node)
+        or
+        "atmel,at91sam9260-clk-slow" (under pmc node):
+                at91 slow clk
+
+        "atmel,at91rm9200-clk-main-osc"
+        "atmel,at91sam9x5-clk-main-rc-osc"
+                at91 main clk sources
+
+        "atmel,at91sam9x5-clk-main"
         "atmel,at91rm9200-clk-main":
-                at91 main oscillator
+                at91 main clock
 
         "atmel,at91rm9200-clk-master" or
         "atmel,at91sam9x5-clk-master":
@@ -54,6 +74,63 @@ Required properties:
         "atmel,at91sam9x5-clk-utmi":
                 at91 utmi clock
 
+Required properties for SCKC node:
+- reg : defines the IO memory reserved for the SCKC.
+- #size-cells : shall be 0 (reg is used to encode clk id).
+- #address-cells : shall be 1 (reg is used to encode clk id).
+
+
+For example:
+        sckc: sckc@fffffe50 {
+                compatible = "atmel,sama5d3-pmc";
+                reg = <0xfffffe50 0x4>
+                #size-cells = <0>;
+                #address-cells = <1>;
+
+                /* put at91 slow clocks here */
+        };
+
+
+Required properties for internal slow RC oscillator:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clock-frequency : define the internal RC oscillator frequency.
+
+Optional properties:
+- clock-accuracy : define the internal RC oscillator accuracy.
+
+For example:
+        slow_rc_osc: slow_rc_osc {
+                compatible = "atmel,at91sam9x5-clk-slow-rc-osc";
+                clock-frequency = <32768>;
+                clock-accuracy = <50000000>;
+        };
+
+Required properties for slow oscillator:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall encode the main osc source clk sources (see atmel datasheet).
+
+Optional properties:
+- atmel,osc-bypass : boolean property. Set this when a clock signal is directly
+  provided on XIN.
+
+For example:
+        slow_osc: slow_osc {
+                compatible = "atmel,at91rm9200-clk-slow-osc";
+                #clock-cells = <0>;
+                clocks = <&slow_xtal>;
+        };
+
+Required properties for slow clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall encode the slow clk sources (see atmel datasheet).
+
+For example:
+        clk32k: slck {
+                compatible = "atmel,at91sam9x5-clk-slow";
+                #clock-cells = <0>;
+                clocks = <&slow_rc_osc &slow_osc>;
+        };
+
 Required properties for PMC node:
 - reg : defines the IO memory reserved for the PMC.
 - #size-cells : shall be 0 (reg is used to encode clk id).
@@ -62,7 +139,7 @@ Required properties for PMC node:
 - interrupt-controller : tell that the PMC is an interrupt controller.
 - #interrupt-cells : must be set to 1. The first cell encodes the interrupt id,
         and reflect the bit position in the PMC_ER/DR/SR registers.
-        You can use the dt macros defined in dt-bindings/clk/at91.h.
+        You can use the dt macros defined in dt-bindings/clock/at91.h.
         0 (AT91_PMC_MOSCS) -> main oscillator ready
         1 (AT91_PMC_LOCKA) -> PLL A ready
         2 (AT91_PMC_LOCKB) -> PLL B ready
@@ -85,24 +162,57 @@ For example:
                 /* put at91 clocks here */
         };
 
+Required properties for main clock internal RC oscillator:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "<0>".
+- clock-frequency : define the internal RC oscillator frequency.
+
+Optional properties:
+- clock-accuracy : define the internal RC oscillator accuracy.
+
+For example:
+        main_rc_osc: main_rc_osc {
+                compatible = "atmel,at91sam9x5-clk-main-rc-osc";
+                interrupt-parent = <&pmc>;
+                interrupts = <0>;
+                clock-frequency = <12000000>;
+                clock-accuracy = <50000000>;
+        };
+
+Required properties for main clock oscillator:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "<0>".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall encode the main osc source clk sources (see atmel datasheet).
+
+Optional properties:
+- atmel,osc-bypass : boolean property. Specified if a clock signal is provided
+  on XIN.
+
+  clock signal is directly provided on XIN pin.
+
+For example:
+        main_osc: main_osc {
+                compatible = "atmel,at91rm9200-clk-main-osc";
+                interrupt-parent = <&pmc>;
+                interrupts = <0>;
+                #clock-cells = <0>;
+                clocks = <&main_xtal>;
+        };
+
 Required properties for main clock:
 - interrupt-parent : must reference the PMC node.
 - interrupts : shall be set to "<0>".
 - #clock-cells : from common clock binding; shall be set to 0.
-- clocks (optional if clock-frequency is provided) : shall be the slow clock
-        phandle. This clock is used to calculate the main clock rate if
-        "clock-frequency" is not provided.
-- clock-frequency : the main oscillator frequency.Prefer the use of
-        "clock-frequency" over automatic clock rate calculation.
+- clocks : shall encode the main clk sources (see atmel datasheet).
 
 For example:
         main: mainck {
-                compatible = "atmel,at91rm9200-clk-main";
+                compatible = "atmel,at91sam9x5-clk-main";
                 interrupt-parent = <&pmc>;
                 interrupts = <0>;
                 #clock-cells = <0>;
-                clocks = <&ck32k>;
-                clock-frequency = <18432000>;
+                clocks = <&main_rc_osc &main_osc>;
         };
 
 Required properties for master clock:
diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
index 56d1f4961075..5286e260fcae 100644
--- a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
+++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
@@ -10,12 +10,12 @@ This binding uses the common clock binding:
 
 Required properties:
 - compatible
-        Shall have one of the following values:
-        - "brcm,bcm11351-root-ccu"
-        - "brcm,bcm11351-aon-ccu"
-        - "brcm,bcm11351-hub-ccu"
-        - "brcm,bcm11351-master-ccu"
-        - "brcm,bcm11351-slave-ccu"
+        Shall have a value of the form "brcm,<model>-<which>-ccu",
+        where <model> is a Broadcom SoC model number and <which> is
+        the name of a defined CCU.  For example:
+            "brcm,bcm11351-root-ccu"
+        The compatible strings used for each supported SoC family
+        are defined below.
 - reg
         Shall define the base and range of the address space
         containing clock control registers
@@ -26,12 +26,48 @@ Required properties:
         Shall be an ordered list of strings defining the names of
         the clocks provided by the CCU.
 
+Device tree example:
+
+        slave_ccu: slave_ccu {
+                compatible = "brcm,bcm11351-slave-ccu";
+                reg = <0x3e011000 0x0f00>;
+                #clock-cells = <1>;
+                clock-output-names = "uartb",
+                                     "uartb2",
+                                     "uartb3",
+                                     "uartb4";
+        };
+
+        ref_crystal_clk: ref_crystal {
+                #clock-cells = <0>;
+                compatible = "fixed-clock";
+                clock-frequency = <26000000>;
+        };
+
+        uart@3e002000 {
+                compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
+                status = "disabled";
+                reg = <0x3e002000 0x1000>;
+                clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
+                interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
+                reg-shift = <2>;
+                reg-io-width = <4>;
+        };
+
+BCM281XX family
+---------------
+CCU compatible string values for SoCs in the BCM281XX family are:
+    "brcm,bcm11351-root-ccu"
+    "brcm,bcm11351-aon-ccu"
+    "brcm,bcm11351-hub-ccu"
+    "brcm,bcm11351-master-ccu"
+    "brcm,bcm11351-slave-ccu"
 
-BCM281XX family SoCs use Kona CCUs.  The following table defines
-the set of CCUs and clock specifiers for BCM281XX clocks.  When
-a clock consumer references a clocks, its symbolic specifier
-(rather than its numeric index value) should be used.  These
-specifiers are defined in "include/dt-bindings/clock/bcm281xx.h".
+The following table defines the set of CCUs and clock specifiers for
+BCM281XX family clocks.  When a clock consumer references a clocks,
+its symbolic specifier (rather than its numeric index value) should
+be used.  These specifiers are defined in:
+    "include/dt-bindings/clock/bcm281xx.h"
 
     CCU     Clock           Type    Index   Specifier
     ---     -----           ----    -----   ---------
@@ -64,30 +100,40 @@ specifiers are defined in "include/dt-bindings/clock/bcm281xx.h".
     slave   pwm             peri      9     BCM281XX_SLAVE_CCU_PWM
 
 
-Device tree example:
+BCM21664 family
+---------------
+CCU compatible string values for SoCs in the BCM21664 family are:
+    "brcm,bcm21664-root-ccu"
+    "brcm,bcm21664-aon-ccu"
+    "brcm,bcm21664-master-ccu"
+    "brcm,bcm21664-slave-ccu"
 
-        slave_ccu: slave_ccu {
-                compatible = "brcm,bcm11351-slave-ccu";
-                reg = <0x3e011000 0x0f00>;
-                #clock-cells = <1>;
-                clock-output-names = "uartb",
-                                     "uartb2",
-                                     "uartb3",
-                                     "uartb4";
-        };
+The following table defines the set of CCUs and clock specifiers for
+BCM21664 family clocks.  When a clock consumer references a clocks,
+its symbolic specifier (rather than its numeric index value) should
+be used.  These specifiers are defined in:
+    "include/dt-bindings/clock/bcm21664.h"
 
-        ref_crystal_clk: ref_crystal {
-                #clock-cells = <0>;
-                compatible = "fixed-clock";
-                clock-frequency = <26000000>;
-        };
+    CCU     Clock           Type    Index   Specifier
+    ---     -----           ----    -----   ---------
+    root    frac_1m         peri      0     BCM21664_ROOT_CCU_FRAC_1M
 
-        uart@3e002000 {
-                compatible = "brcm,bcm11351-dw-apb-uart", "snps,dw-apb-uart";
-                status = "disabled";
-                reg = <0x3e002000 0x1000>;
-                clocks = <&slave_ccu BCM281XX_SLAVE_CCU_UARTB3>;
-                interrupts = <GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH>;
-                reg-shift = <2>;
-                reg-io-width = <4>;
-        };
+    aon     hub_timer       peri      0     BCM21664_AON_CCU_HUB_TIMER
+
+    master  sdio1           peri      0     BCM21664_MASTER_CCU_SDIO1
+    master  sdio2           peri      1     BCM21664_MASTER_CCU_SDIO2
+    master  sdio3           peri      2     BCM21664_MASTER_CCU_SDIO3
+    master  sdio4           peri      3     BCM21664_MASTER_CCU_SDIO4
+    master  sdio1_sleep     peri      4     BCM21664_MASTER_CCU_SDIO1_SLEEP
+    master  sdio2_sleep     peri      5     BCM21664_MASTER_CCU_SDIO2_SLEEP
+    master  sdio3_sleep     peri      6     BCM21664_MASTER_CCU_SDIO3_SLEEP
+    master  sdio4_sleep     peri      7     BCM21664_MASTER_CCU_SDIO4_SLEEP
+
+    slave   uartb           peri      0     BCM21664_SLAVE_CCU_UARTB
+    slave   uartb2          peri      1     BCM21664_SLAVE_CCU_UARTB2
+    slave   uartb3          peri      2     BCM21664_SLAVE_CCU_UARTB3
+    slave   uartb4          peri      3     BCM21664_SLAVE_CCU_UARTB4
+    slave   bsc1            peri      4     BCM21664_SLAVE_CCU_BSC1
+    slave   bsc2            peri      5     BCM21664_SLAVE_CCU_BSC2
+    slave   bsc3            peri      6     BCM21664_SLAVE_CCU_BSC3
+    slave   bsc4            peri      7     BCM21664_SLAVE_CCU_BSC4
diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt
index 700e7aac3717..f15787817d6b 100644
--- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
+++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -44,10 +44,9 @@ For example:
   clocks by index. The names should reflect the clock output signal
   names for the device.
 
-clock-indices:     If the identifyng number for the clocks in the node
-                   is not linear from zero, then the this mapping allows
-                   the mapping of identifiers into the clock-output-names
-                   array.
+clock-indices:     If the identifying number for the clocks in the node
+                   is not linear from zero, then this allows the mapping of
+                   identifiers into the clock-output-names array.
 
 For example, if we have two clocks <&oscillator 1> and <&oscillator 3>:
 
@@ -58,7 +57,7 @@ For example, if we have two clocks <&oscillator 1> and <&oscillator 3>:
                 clock-output-names = "clka", "clkb";
         }
 
-        This ensures we do not have any empty nodes in clock-output-names
+        This ensures we do not have any empty strings in clock-output-names
 
 
 ==Clock consumers==
diff --git a/Documentation/devicetree/bindings/clock/exynos3250-clock.txt b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
new file mode 100644
index 000000000000..aadc9c59e2d1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos3250-clock.txt
@@ -0,0 +1,41 @@
+* Samsung Exynos3250 Clock Controller
+
+The Exynos3250 clock controller generates and supplies clock to various
+controllers within the Exynos3250 SoC.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos3250.h header and can be used in device
+tree sources.
+
+Example 1: An example of a clock controller node is listed below.
+
+        cmu: clock-controller@10030000 {
+                compatible = "samsung,exynos3250-cmu";
+                reg = <0x10030000 0x20000>;
+                #clock-cells = <1>;
+        };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+           controller. Refer to the standard clock bindings for information
+           about 'clocks' and 'clock-names' property.
+
+        serial@13800000 {
+                compatible = "samsung,exynos4210-uart";
+                reg = <0x13800000 0x100>;
+                interrupts = <0 109 0>;
+                clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>;
+                clock-names = "uart", "clk_uart_baud0";
+        };
diff --git a/Documentation/devicetree/bindings/clock/exynos5260-clock.txt b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt
new file mode 100644
index 000000000000..5496b2fac483
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5260-clock.txt
@@ -0,0 +1,190 @@
+* Samsung Exynos5260 Clock Controller
+
+Exynos5260 has 13 clock controllers which are instantiated
+independently from the device-tree. These clock controllers
+generate and supply clocks to various hardware blocks within
+the SoC.
+
+Each clock is assigned an identifier and client nodes can use
+this identifier to specify the clock which they consume. All
+available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5260-clk.h header and can be used in
+device tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It
+is expected that they are defined using standard clock bindings
+with following clock-output-names:
+
+ - "fin_pll" - PLL input clock from XXTI
+ - "xrtcxti" - input clock from XRTCXTI
+ - "ioclk_pcm_extclk" - pcm external operation clock
+ - "ioclk_spdif_extclk" - spdif external operation clock
+ - "ioclk_i2s_cdclk" - i2s0 codec clock
+
+Phy clocks:
+
+There are several clocks which are generated by specific PHYs.
+These clocks are fed into the clock controller and then routed to
+the hardware blocks. These clocks are defined as fixed clocks in the
+driver with following names:
+
+ - "phyclk_dptx_phy_ch3_txd_clk" - dp phy clock for channel 3
+ - "phyclk_dptx_phy_ch2_txd_clk" - dp phy clock for channel 2
+ - "phyclk_dptx_phy_ch1_txd_clk" - dp phy clock for channel 1
+ - "phyclk_dptx_phy_ch0_txd_clk" - dp phy clock for channel 0
+ - "phyclk_hdmi_phy_tmds_clko" - hdmi phy tmds clock
+ - "phyclk_hdmi_phy_pixel_clko" - hdmi phy pixel clock
+ - "phyclk_hdmi_link_o_tmds_clkhi" - hdmi phy for hdmi link
+ - "phyclk_dptx_phy_o_ref_clk_24m" - dp phy reference clock
+ - "phyclk_dptx_phy_clk_div2"
+ - "phyclk_mipi_dphy_4l_m_rxclkesc0"
+ - "phyclk_usbhost20_phy_phyclock" - usb 2.0 phy clock
+ - "phyclk_usbhost20_phy_freeclk"
+ - "phyclk_usbhost20_phy_clk48mohci"
+ - "phyclk_usbdrd30_udrd30_pipe_pclk"
+ - "phyclk_usbdrd30_udrd30_phyclock" - usb 3.0 phy clock
+
+Required Properties for Clock Controller:
+
+ - compatible: should be one of the following.
+        1) "samsung,exynos5260-clock-top"
+        2) "samsung,exynos5260-clock-peri"
+        3) "samsung,exynos5260-clock-egl"
+        4) "samsung,exynos5260-clock-kfc"
+        5) "samsung,exynos5260-clock-g2d"
+        6) "samsung,exynos5260-clock-mif"
+        7) "samsung,exynos5260-clock-mfc"
+        8) "samsung,exynos5260-clock-g3d"
+        9) "samsung,exynos5260-clock-fsys"
+        10) "samsung,exynos5260-clock-aud"
+        11) "samsung,exynos5260-clock-isp"
+        12) "samsung,exynos5260-clock-gscl"
+        13) "samsung,exynos5260-clock-disp"
+
+ - reg: physical base address of the controller and the length of
+        memory mapped region.
+
+ - #clock-cells: should be 1.
+
+ - clocks: list of clock identifiers which are fed as the input to
+        the given clock controller. Please refer the next section to find
+        the input clocks for a given controller.
+
+ - clock-names: list of names of clocks which are fed as the input
+        to the given clock controller.
+
+Input clocks for top clock controller:
+        - fin_pll
+        - dout_mem_pll
+        - dout_bus_pll
+        - dout_media_pll
+
+Input clocks for peri clock controller:
+        - fin_pll
+        - ioclk_pcm_extclk
+        - ioclk_i2s_cdclk
+        - ioclk_spdif_extclk
+        - phyclk_hdmi_phy_ref_cko
+        - dout_aclk_peri_66
+        - dout_sclk_peri_uart0
+        - dout_sclk_peri_uart1
+        - dout_sclk_peri_uart2
+        - dout_sclk_peri_spi0_b
+        - dout_sclk_peri_spi1_b
+        - dout_sclk_peri_spi2_b
+        - dout_aclk_peri_aud
+        - dout_sclk_peri_spi0_b
+
+Input clocks for egl clock controller:
+        - fin_pll
+        - dout_bus_pll
+
+Input clocks for kfc clock controller:
+        - fin_pll
+        - dout_media_pll
+
+Input clocks for g2d clock controller:
+        - fin_pll
+        - dout_aclk_g2d_333
+
+Input clocks for mif clock controller:
+        - fin_pll
+
+Input clocks for mfc clock controller:
+        - fin_pll
+        - dout_aclk_mfc_333
+
+Input clocks for g3d clock controller:
+        - fin_pll
+
+Input clocks for fsys clock controller:
+        - fin_pll
+        - phyclk_usbhost20_phy_phyclock
+        - phyclk_usbhost20_phy_freeclk
+        - phyclk_usbhost20_phy_clk48mohci
+        - phyclk_usbdrd30_udrd30_pipe_pclk
+        - phyclk_usbdrd30_udrd30_phyclock
+        - dout_aclk_fsys_200
+
+Input clocks for aud clock controller:
+        - fin_pll
+        - fout_aud_pll
+        - ioclk_i2s_cdclk
+        - ioclk_pcm_extclk
+
+Input clocks for isp clock controller:
+        - fin_pll
+        - dout_aclk_isp1_266
+        - dout_aclk_isp1_400
+        - mout_aclk_isp1_266
+
+Input clocks for gscl clock controller:
+        - fin_pll
+        - dout_aclk_gscl_400
+        - dout_aclk_gscl_333
+
+Input clocks for disp clock controller:
+        - fin_pll
+        - phyclk_dptx_phy_ch3_txd_clk
+        - phyclk_dptx_phy_ch2_txd_clk
+        - phyclk_dptx_phy_ch1_txd_clk
+        - phyclk_dptx_phy_ch0_txd_clk
+        - phyclk_hdmi_phy_tmds_clko
+        - phyclk_hdmi_phy_ref_clko
+        - phyclk_hdmi_phy_pixel_clko
+        - phyclk_hdmi_link_o_tmds_clkhi
+        - phyclk_mipi_dphy_4l_m_txbyte_clkhs
+        - phyclk_dptx_phy_o_ref_clk_24m
+        - phyclk_dptx_phy_clk_div2
+        - phyclk_mipi_dphy_4l_m_rxclkesc0
+        - phyclk_hdmi_phy_ref_cko
+        - ioclk_spdif_extclk
+        - dout_aclk_peri_aud
+        - dout_aclk_disp_222
+        - dout_sclk_disp_pixel
+        - dout_aclk_disp_333
+
+Example 1: An example of a clock controller node is listed below.
+
+        clock_mfc: clock-controller@11090000 {
+                compatible = "samsung,exynos5260-clock-mfc";
+                clock = <&fin_pll>, <&clock_top TOP_DOUT_ACLK_MFC_333>;
+                clock-names = "fin_pll", "dout_aclk_mfc_333";
+                reg = <0x11090000 0x10000>;
+                #clock-cells = <1>;
+        };
+
+Example 2: UART controller node that consumes the clock generated by the
+                peri clock controller. Refer to the standard clock bindings for
+                information about 'clocks' and 'clock-names' property.
+
+        serial@12C00000 {
+                compatible = "samsung,exynos4210-uart";
+                reg = <0x12C00000 0x100>;
+                interrupts = <0 146 0>;
+                clocks = <&clock_peri PERI_PCLK_UART0>, <&clock_peri PERI_SCLK_UART0>;
+                clock-names = "uart", "clk_uart_baud0";
+        };
+
diff --git a/Documentation/devicetree/bindings/clock/exynos5410-clock.txt b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
new file mode 100644
index 000000000000..aeab635b07b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5410-clock.txt
@@ -0,0 +1,45 @@
+* Samsung Exynos5410 Clock Controller
+
+The Exynos5410 clock controller generates and supplies clock to various
+controllers within the Exynos5410 SoC.
+
+Required Properties:
+
+- compatible: should be "samsung,exynos5410-clock"
+
+- reg: physical base address of the controller and length of memory mapped
+  region.
+
+- #clock-cells: should be 1.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5410.h header and can be used in device
+tree sources.
+
+External clock:
+
+There is clock that is generated outside the SoC. It
+is expected that it is defined using standard clock bindings
+with following clock-output-name:
+
+ - "fin_pll" - PLL input clock from XXTI
+
+Example 1: An example of a clock controller node is listed below.
+
+        clock: clock-controller@0x10010000 {
+                compatible = "samsung,exynos5410-clock";
+                reg = <0x10010000 0x30000>;
+                #clock-cells = <1>;
+        };
+
+Example 2: UART controller node that consumes the clock generated by the clock
+           controller. Refer to the standard clock bindings for information
+           about 'clocks' and 'clock-names' property.
+
+        serial@12C20000 {
+                compatible = "samsung,exynos4210-uart";
+                reg = <0x12C00000 0x100>;
+                interrupts = <0 51 0>;
+                clocks = <&clock CLK_UART0>, <&clock CLK_SCLK_UART0>;
+                clock-names = "uart", "clk_uart_baud0";
+        };
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index ca88c97a8562..d54f42cf0440 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -1,12 +1,13 @@
 * Samsung Exynos5420 Clock Controller
 
 The Exynos5420 clock controller generates and supplies clock to various
-controllers within the Exynos5420 SoC.
+controllers within the Exynos5420 SoC and for the Exynos5800 SoC.
 
 Required Properties:
 
 - compatible: should be one of the following.
   - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC.
+  - "samsung,exynos5800-clock" - controller compatible with Exynos5800 SoC.
 
 - reg: physical base address of the controller and length of memory mapped
   region.
diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt
index 48ea0ad8ad46..0641a663ad69 100644
--- a/Documentation/devicetree/bindings/clock/fixed-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt
@@ -12,7 +12,6 @@ Required properties:
 Optional properties:
 - clock-accuracy : accuracy of clock in ppb (parts per billion).
                    Should be a single cell.
-- gpios : From common gpio binding; gpio connection to clock enable pin.
 - clock-output-names : From common clock binding.
 
 Example:
diff --git a/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt
new file mode 100644
index 000000000000..7894a64887cb
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hix5hd2-clock.txt
@@ -0,0 +1,31 @@
+* Hisilicon Hix5hd2 Clock Controller
+
+The hix5hd2 clock controller generates and supplies clock to various
+controllers within the hix5hd2 SoC.
+
+Required Properties:
+
+- compatible: should be "hisilicon,hix5hd2-clock"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+
+Each clock is assigned an identifier and client nodes use this identifier
+to specify the clock which they consume.
+
+All these identifier could be found in <dt-bindings/clock/hix5hd2-clock.h>.
+
+Examples:
+        clock: clock@f8a22000 {
+                compatible = "hisilicon,hix5hd2-clock";
+                reg = <0xf8a22000 0x1000>;
+                #clock-cells = <1>;
+        };
+
+        uart0: uart@f8b00000 {
+                compatible = "arm,pl011", "arm,primecell";
+                reg = <0xf8b00000 0x1000>;
+                interrupts = <0 49 4>;
+                clocks = <&clock HIX5HD2_FIXED_83M>;
+                clock-names = "apb_pclk";
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt
index db4f2f05c4d0..ba6b312ff8a5 100644
--- a/Documentation/devicetree/bindings/clock/imx25-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt
@@ -139,6 +139,9 @@ clocks and IDs.
         uart5_ipg               124
         reserved                125
         wdt_ipg                 126
+        cko_div                 127
+        cko_sel                 128
+        cko                     129
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.txt b/Documentation/devicetree/bindings/clock/imx27-clock.txt
index 7a2070393732..6bc9fd2c6631 100644
--- a/Documentation/devicetree/bindings/clock/imx27-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx27-clock.txt
@@ -98,7 +98,12 @@ clocks and IDs.
         fpm                  83
         mpll_osc_sel         84
         mpll_sel             85
-        spll_gate            86
+        spll_gate            86
+        mshc_div             87
+        rtic_ipg_gate        88
+        mshc_ipg_gate        89
+        rtic_ahb_gate        90
+        mshc_baud_gate       91
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6aab72bf67ea..90ec91fe5ce0 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -220,6 +220,7 @@ clocks and IDs.
         lvds2_sel               205
         lvds1_gate              206
         lvds2_gate              207
+        esai_ahb                208
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/clock/imx6sx-clock.txt b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt
new file mode 100644
index 000000000000..22362b9b7ba3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6sx-clock.txt
@@ -0,0 +1,13 @@
+* Clock bindings for Freescale i.MX6 SoloX
+
+Required properties:
+- compatible: Should be "fsl,imx6sx-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+- clocks: list of clock specifiers, must contain an entry for each required
+  entry in clock-names
+- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
+
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  See include/dt-bindings/clock/imx6sx-clock.h
+for the full list of i.MX6 SoloX clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt
new file mode 100644
index 000000000000..3ce97cfe999b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/lsi,axm5516-clks.txt
@@ -0,0 +1,29 @@
+AXM5516 clock driver bindings
+-----------------------------
+
+Required properties :
+- compatible : shall contain "lsi,axm5516-clks"
+- reg : shall contain base register location and length
+- #clock-cells : shall contain 1
+
+The consumer specifies the desired clock by having the clock ID in its "clocks"
+phandle cell. See <dt-bindings/clock/lsi,axxia-clock.h> for the list of
+supported clock IDs.
+
+Example:
+
+        clks: clock-controller@2010020000 {
+                compatible = "lsi,axm5516-clks";
+                #clock-cells = <1>;
+                reg = <0x20 0x10020000 0 0x20000>;
+        };
+
+        serial0: uart@2010080000 {
+                compatible = "arm,pl011", "arm,primecell";
+                reg = <0x20 0x10080000 0 0x1000>;
+                interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&clks AXXIA_CLK_PER>;
+                clock-names = "apb_pclk";
+        };
+                                                                                                                                                                                                                                                                };
+
diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
index 307a503c5db8..dc5ea5b22da9 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -29,6 +29,11 @@ The following is a list of provided IDs and clock names on Kirkwood and Dove:
  2 = l2clk  (L2 Cache clock derived from CPU0 clock)
  3 = ddrclk (DDR controller clock derived from CPU0 clock)
 
+The following is a list of provided IDs and clock names on Orion5x:
+ 0 = tclk   (Internal Bus clock)
+ 1 = cpuclk (CPU0 clock)
+ 2 = ddrclk (DDR controller clock derived from CPU0 clock)
+
 Required properties:
 - compatible : shall be one of the following:
         "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
@@ -38,6 +43,9 @@ Required properties:
         "marvell,dove-core-clock" - for Dove SoC core clocks
         "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
         "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC
+        "marvell,mv88f5182-core-clock" - for Orion MV88F5182 SoC
+        "marvell,mv88f5281-core-clock" - for Orion MV88F5281 SoC
+        "marvell,mv88f6183-core-clock" - for Orion MV88F6183 SoC
 - reg : shall be the register address of the Sample-At-Reset (SAR) register
 - #clock-cells : from common clock binding; shall be set to 1
 
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
index 767401f42871..9cfcb4f2bc97 100644
--- a/Documentation/devicetree/bindings/clock/qcom,gcc.txt
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -4,9 +4,12 @@ Qualcomm Global Clock & Reset Controller Binding
 Required properties :
 - compatible : shall contain only one of the following:
 
+                        "qcom,gcc-apq8064"
                         "qcom,gcc-msm8660"
                         "qcom,gcc-msm8960"
                         "qcom,gcc-msm8974"
+                        "qcom,gcc-msm8974pro"
+                        "qcom,gcc-msm8974pro-ac"
 
 - reg : shall contain base register location and length
 - #clock-cells : shall contain 1
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/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
index 5992dceec7af..8a92b5fb3540 100644
--- a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
@@ -10,6 +10,8 @@ index in the group, from 0 to 31.
 Required Properties:
 
   - compatible: Must be one of the following
+    - "renesas,r7s72100-mstp-clocks" for R7S72100 (RZ) MSTP gate clocks
+    - "renesas,r8a7779-mstp-clocks" for R8A7779 (R-Car H1) MSTP gate clocks
     - "renesas,r8a7790-mstp-clocks" for R8A7790 (R-Car H2) MSTP gate clocks
     - "renesas,r8a7791-mstp-clocks" for R8A7791 (R-Car M2) MSTP gate clocks
     - "renesas,cpg-mstp-clock" for generic MSTP gate clocks
@@ -43,7 +45,7 @@ Example
                 clock-output-names =
                         "tpu0", "mmcif1", "sdhi3", "sdhi2",
                          "sdhi1", "sdhi0", "mmcif0";
-                renesas,clock-indices = <
+                clock-indices = <
                         R8A7790_CLK_TPU0 R8A7790_CLK_MMCIF1 R8A7790_CLK_SDHI3
                         R8A7790_CLK_SDHI2 R8A7790_CLK_SDHI1 R8A7790_CLK_SDHI0
                         R8A7790_CLK_MMCIF0
diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt
new file mode 100644
index 000000000000..2c03302f86ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,r8a7740-cpg-clocks.txt
@@ -0,0 +1,41 @@
+These bindings should be considered EXPERIMENTAL for now.
+
+* Renesas R8A7740  Clock Pulse Generator (CPG)
+
+The CPG generates core clocks for the R8A7740 SoC. It includes three PLLs
+and several fixed ratio and variable ratio dividers.
+
+Required Properties:
+
+  - compatible: Must be "renesas,r8a7740-cpg-clocks"
+
+  - reg: Base address and length of the memory resource used by the CPG
+
+  - clocks: Reference to the three parent clocks
+  - #clock-cells: Must be 1
+  - clock-output-names: The names of the clocks. Supported clocks are
+    "system", "pllc0", "pllc1", "pllc2", "r", "usb24s", "i", "zg", "b",
+    "m1", "hp", "hpp", "usbp", "s", "zb", "m3", and "cp".
+
+  - renesas,mode: board-specific settings of the MD_CK* bits
+
+
+Example
+-------
+
+cpg_clocks: cpg_clocks@e6150000 {
+        compatible = "renesas,r8a7740-cpg-clocks";
+        reg = <0xe6150000 0x10000>;
+        clocks = <&extal1_clk>, <&extal2_clk>, <&extalr_clk>;
+        #clock-cells = <1>;
+        clock-output-names = "system", "pllc0", "pllc1",
+                             "pllc2", "r",
+                             "usb24s",
+                             "i", "zg", "b", "m1", "hp",
+                             "hpp", "usbp", "s", "zb", "m3",
+                             "cp";
+};
+
+&cpg_clocks {
+        renesas,mode = <0x05>;
+};
diff --git a/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt
new file mode 100644
index 000000000000..ed3c8cb12f4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt
@@ -0,0 +1,27 @@
+* Renesas R8A7779 Clock Pulse Generator (CPG)
+
+The CPG generates core clocks for the R8A7779. It includes one PLL and
+several fixed ratio dividers
+
+Required Properties:
+
+  - compatible: Must be "renesas,r8a7779-cpg-clocks"
+  - reg: Base address and length of the memory resource used by the CPG
+
+  - clocks: Reference to the parent clock
+  - #clock-cells: Must be 1
+  - clock-output-names: The names of the clocks. Supported clocks are "plla",
+    "z", "zs", "s", "s1", "p", "b", "out".
+
+
+Example
+-------
+
+        cpg_clocks: cpg_clocks@ffc80000 {
+                compatible = "renesas,r8a7779-cpg-clocks";
+                reg = <0 0xffc80000 0 0x30>;
+                clocks = <&extal_clk>;
+                #clock-cells = <1>;
+                clock-output-names = "plla", "z", "zs", "s", "s1", "p",
+                                     "b", "out";
+        };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
new file mode 100644
index 000000000000..822505e715ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c2410-clock.txt
@@ -0,0 +1,50 @@
+* Samsung S3C2410 Clock Controller
+
+The S3C2410 clock controller generates and supplies clock to various controllers
+within the SoC. The clock binding described here is applicable to the s3c2410,
+s3c2440 and s3c2442 SoCs in the s3c24x family.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,s3c2410-clock" - controller compatible with S3C2410 SoC.
+  - "samsung,s3c2440-clock" - controller compatible with S3C2440 SoC.
+  - "samsung,s3c2442-clock" - controller compatible with S3C2442 SoC.
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular SoC.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/s3c2410.h header and can be used in device
+tree sources.
+
+External clocks:
+
+The xti clock used as input for the plls is generated outside the SoC. It is
+expected that is are defined using standard clock bindings with a
+clock-output-names value of "xti".
+
+Example: Clock controller node:
+
+        clocks: clock-controller@4c000000 {
+                compatible = "samsung,s3c2410-clock";
+                reg = <0x4c000000 0x20>;
+                #clock-cells = <1>;
+        };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+        serial@50004000 {
+                compatible = "samsung,s3c2440-uart";
+                reg = <0x50004000 0x4000>;
+                interrupts = <1 23 3 4>, <1 23 4 4>;
+                clock-names = "uart", "clk_uart_baud2";
+                clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt
new file mode 100644
index 000000000000..2b430960ba47
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c2412-clock.txt
@@ -0,0 +1,50 @@
+* Samsung S3C2412 Clock Controller
+
+The S3C2412 clock controller generates and supplies clock to various controllers
+within the SoC. The clock binding described here is applicable to the s3c2412
+and s3c2413 SoCs in the s3c24x family.
+
+Required Properties:
+
+- compatible: should be "samsung,s3c2412-clock"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular SoC.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/s3c2412.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xti" - crystal input - required,
+ - "ext" - external clock source - optional,
+
+Example: Clock controller node:
+
+        clocks: clock-controller@4c000000 {
+                compatible = "samsung,s3c2412-clock";
+                reg = <0x4c000000 0x20>;
+                #clock-cells = <1>;
+        };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+        serial@50004000 {
+                compatible = "samsung,s3c2412-uart";
+                reg = <0x50004000 0x4000>;
+                interrupts = <1 23 3 4>, <1 23 4 4>;
+                clock-names = "uart", "clk_uart_baud2", "clk_uart_baud3";
+                clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
+                         <&clocks SCLK_UART>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
new file mode 100644
index 000000000000..e67bb05478af
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/samsung,s3c2443-clock.txt
@@ -0,0 +1,56 @@
+* Samsung S3C2443 Clock Controller
+
+The S3C2443 clock controller generates and supplies clock to various controllers
+within the SoC. The clock binding described here is applicable to all SoCs in
+the s3c24x family starting with the s3c2443.
+
+Required Properties:
+
+- compatible: should be one of the following.
+  - "samsung,s3c2416-clock" - controller compatible with S3C2416 SoC.
+  - "samsung,s3c2443-clock" - controller compatible with S3C2443 SoC.
+  - "samsung,s3c2450-clock" - controller compatible with S3C2450 SoC.
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume. Some of the clocks are available only
+on a particular SoC.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/s3c2443.h header and can be used in device
+tree sources.
+
+External clocks:
+
+There are several clocks that are generated outside the SoC. It is expected
+that they are defined using standard clock bindings with following
+clock-output-names:
+ - "xti" - crystal input - required,
+ - "ext" - external clock source - optional,
+ - "ext_i2s" - external I2S clock - optional,
+ - "ext_uart" - external uart clock - optional,
+
+Example: Clock controller node:
+
+        clocks: clock-controller@4c000000 {
+                compatible = "samsung,s3c2416-clock";
+                reg = <0x4c000000 0x40>;
+                #clock-cells = <1>;
+        };
+
+Example: UART controller node that consumes the clock generated by the clock
+  controller (refer to the standard clock bindings for information about
+  "clocks" and "clock-names" properties):
+
+        serial@50004000 {
+                compatible = "samsung,s3c2440-uart";
+                reg = <0x50004000 0x4000>;
+                interrupts = <1 23 3 4>, <1 23 4 4>;
+                clock-names = "uart", "clk_uart_baud2",
+                                "clk_uart_baud3";
+                clocks = <&clocks PCLK_UART0>, <&clocks PCLK_UART0>,
+                                <&clocks SCLK_UART>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
new file mode 100644
index 000000000000..3e6a81e99804
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti-keystone-pllctrl.txt
@@ -0,0 +1,20 @@
+* Device tree bindings for Texas Instruments keystone pll controller
+
+The main pll controller used to drive theC66x CorePacs, the switch fabric,
+and a majority of the peripheral clocks (all but the ARM CorePacs, DDR3 and
+the NETCP modules) requires a PLL Controller to manage the various clock
+divisions, gating, and synchronization.
+
+Required properties:
+
+- compatible:           "ti,keystone-pllctrl", "syscon"
+
+- reg:                  contains offset/length value for pll controller
+                        registers space.
+
+Example:
+
+pllctrl: pll-controller@0x02310000 {
+        compatible = "ti,keystone-pllctrl", "syscon";
+        reg = <0x02310000 0x200>;
+};
diff --git a/Documentation/devicetree/bindings/crypto/samsung-sss.txt b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
new file mode 100644
index 000000000000..a6dafa83c6df
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/samsung-sss.txt
@@ -0,0 +1,34 @@
+Samsung SoC SSS (Security SubSystem) module
+
+The SSS module in S5PV210 SoC supports the following:
+-- Feeder (FeedCtrl)
+-- Advanced Encryption Standard (AES)
+-- Data Encryption Standard (DES)/3DES
+-- Public Key Accelerator (PKA)
+-- SHA-1/SHA-256/MD5/HMAC (SHA-1/SHA-256/MD5)/PRNG
+-- PRNG: Pseudo Random Number Generator
+
+The SSS module in Exynos4 (Exynos4210) and
+Exynos5 (Exynos5420 and Exynos5250) SoCs
+supports the following also:
+-- ARCFOUR (ARC4)
+-- True Random Number Generator (TRNG)
+-- Secure Key Manager
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SSS versions:
+  - "samsung,s5pv210-secss" for S5PV210 SoC.
+  - "samsung,exynos4210-secss" for Exynos4210, Exynos4212, Exynos4412, Exynos5250,
+                Exynos5260 and Exynos5420 SoCs.
+- reg : Offset and length of the register set for the module
+- interrupts : interrupt specifiers of SSS module interrupts, should contain
+                following entries:
+                - first : feed control interrupt (required for all variants),
+                - second : hash interrupt (required only for samsung,s5pv210-secss).
+
+- clocks : list of clock phandle and specifier pairs for all clocks  listed in
+                clock-names property.
+- clock-names : list of device clock input names; should contain one entry
+                "secss".
diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt
index 8f504e6bae14..82104271e754 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -14,7 +14,7 @@ Required property:
 
 Optional properties:
 - dma-channels:         Number of DMA channels supported by the controller.
-- dma-requests:         Number of DMA requests signals supported by the
+- dma-requests:         Number of DMA request signals supported by the
                         controller.
 
 Example:
@@ -44,7 +44,7 @@ Required property:
                           #dma-cells property in the node referenced by phandle
                           containing DMA controller specific information. This
                           typically contains a DMA request line number or a
-                          channel number, but can contain any data that is used
+                          channel number, but can contain any data that is
                           required for configuring a channel.
 - dma-names:            Contains one identifier string for each DMA specifier in
                         the dmas property. The specific strings that can be used
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index ee9be9961524..e577196a12c0 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -8,7 +8,7 @@ Required properties:
       "fsl,imx51-sdma"
       "fsl,imx53-sdma"
       "fsl,imx6q-sdma"
-  The -to variants should be preferred since they allow to determnine the
+  The -to variants should be preferred since they allow to determine the
   correct ROM script addresses needed for the driver to work without additional
   firmware.
 - reg : Should contain SDMA registers location and length
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/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
index 9fbbdb783a72..5ba525a10035 100644
--- a/Documentation/devicetree/bindings/dma/ti-edma.txt
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -2,11 +2,8 @@ TI EDMA
 
 Required properties:
 - compatible : "ti,edma3"
-- ti,edma-regions: Number of regions
-- ti,edma-slots: Number of slots
 - #dma-cells: Should be set to <1>
               Clients should use a single channel number per DMA request.
-- dma-channels: Specify total DMA channels per CC
 - reg: Memory map for accessing module
 - interrupt-parent: Interrupt controller the interrupt is routed through
 - interrupts: Exactly 3 interrupts need to be specified in the order:
@@ -17,6 +14,13 @@ Optional properties:
 - ti,hwmods: Name of the hwmods associated to the EDMA
 - ti,edma-xbar-event-map: Crossbar event to channel map
 
+Deprecated properties:
+Listed here in case one wants to boot an old kernel with new DTB. These
+properties might need to be added to the new DTS files.
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- dma-channels: Specify total DMA channels per CC
+
 Example:
 
 edma: edma@49000000 {
@@ -26,9 +30,6 @@ edma: edma@49000000 {
         compatible = "ti,edma3";
         ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
         #dma-cells = <1>;
-        dma-channels = <64>;
-        ti,edma-regions = <4>;
-        ti,edma-slots = <256>;
-        ti,edma-xbar-event-map = <1 12
-                                  2 13>;
+        ti,edma-xbar-event-map = /bits/ 16 <1 12
+                                            2 13>;
 };
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/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
index 3ddc7ccfe5f3..c306a2d0f2b1 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -54,7 +54,7 @@ Optional device specific properties:
         IO 8-15 are bank 2. These chips have two different interrupt outputs:
         One for bank 1 and another for bank 2. If irq-mirror is set, both
         interrupts are generated regardless of the bank that an input change
-        occured on. If it is not set, the interrupt are only generated for the
+        occurred on. If it is not set, the interrupt are only generated for the
         bank they belong to.
         On devices with only one interrupt output this property is useless.
 
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
index f61cef74a212..941a26aa4322 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -21,6 +21,12 @@ Required Properties:
     GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
   - gpio-ranges: Range of pins managed by the GPIO controller.
 
+Optional properties:
+
+  - clocks: Must contain a reference to the functional clock.  The property is
+    mandatory if the hardware implements a controllable functional clock for
+    the GPIO instance.
+
 Please refer to gpio.txt in this directory for details of gpio-ranges property
 and the common GPIO bindings used by client devices.
 
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/hsi/client-devices.txt b/Documentation/devicetree/bindings/hsi/client-devices.txt
new file mode 100644
index 000000000000..104c9a3e57a4
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/client-devices.txt
@@ -0,0 +1,44 @@
+Each HSI port is supposed to have one child node, which
+symbols the remote device connected to the HSI port. The
+following properties are standardized for HSI clients:
+
+Required HSI configuration properties:
+
+- hsi-channel-ids:      A list of channel ids
+
+- hsi-rx-mode:          Receiver Bit transmission mode ("stream" or "frame")
+- hsi-tx-mode:          Transmitter Bit transmission mode ("stream" or "frame")
+- hsi-mode:             May be used instead hsi-rx-mode and hsi-tx-mode if
+                        the transmission mode is the same for receiver and
+                        transmitter
+- hsi-speed-kbps:       Max bit transmission speed in kbit/s
+- hsi-flow:             RX flow type ("synchronized" or "pipeline")
+- hsi-arb-mode:         Arbitration mode for TX frame ("round-robin", "priority")
+
+Optional HSI configuration properties:
+
+- hsi-channel-names:    A list with one name per channel specified in the
+                        hsi-channel-ids property
+
+
+Device Tree node example for an HSI client:
+
+hsi-controller {
+        hsi-port {
+                modem: hsi-client {
+                        compatible = "nokia,n900-modem";
+
+                        hsi-channel-ids = <0>, <1>, <2>, <3>;
+                        hsi-channel-names = "mcsaab-control",
+                                            "speech-control",
+                                            "speech-data",
+                                            "mcsaab-data";
+                        hsi-speed-kbps = <55000>;
+                        hsi-mode = "frame";
+                        hsi-flow = "synchronized";
+                        hsi-arb-mode = "round-robin";
+
+                        /* more client specific properties */
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/hsi/nokia-modem.txt b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
new file mode 100644
index 000000000000..8a979780452b
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/nokia-modem.txt
@@ -0,0 +1,57 @@
+Nokia modem client bindings
+
+The Nokia modem HSI client follows the common HSI client binding
+and inherits all required properties. The following additional
+properties are needed by the Nokia modem HSI client:
+
+Required properties:
+- compatible:           Should be one of
+      "nokia,n900-modem"
+- hsi-channel-names:    Should contain the following strings
+      "mcsaab-control"
+      "speech-control"
+      "speech-data"
+      "mcsaab-data"
+- gpios:                Should provide a GPIO handler for each GPIO listed in
+                        gpio-names
+- gpio-names:           Should contain the following strings
+      "cmt_apeslpx"
+      "cmt_rst_rq"
+      "cmt_en"
+      "cmt_rst"
+      "cmt_bsi"
+- interrupts:           Should be IRQ handle for modem's reset indication
+
+Example:
+
+&ssi_port {
+        modem: hsi-client {
+                compatible = "nokia,n900-modem";
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&modem_pins>;
+
+                hsi-channel-ids = <0>, <1>, <2>, <3>;
+                hsi-channel-names = "mcsaab-control",
+                                    "speech-control",
+                                    "speech-data",
+                                    "mcsaab-data";
+                hsi-speed-kbps = <55000>;
+                hsi-mode = "frame";
+                hsi-flow = "synchronized";
+                hsi-arb-mode = "round-robin";
+
+                interrupts-extended = <&gpio3 8 IRQ_TYPE_EDGE_FALLING>; /* 72 */
+
+                gpios = <&gpio3  6 GPIO_ACTIVE_HIGH>, /* 70 */
+                        <&gpio3  9 GPIO_ACTIVE_HIGH>, /* 73 */
+                        <&gpio3 10 GPIO_ACTIVE_HIGH>, /* 74 */
+                        <&gpio3 11 GPIO_ACTIVE_HIGH>, /* 75 */
+                        <&gpio5 29 GPIO_ACTIVE_HIGH>; /* 157 */
+                gpio-names = "cmt_apeslpx",
+                             "cmt_rst_rq",
+                             "cmt_en",
+                             "cmt_rst",
+                             "cmt_bsi";
+        };
+};
diff --git a/Documentation/devicetree/bindings/hsi/omap-ssi.txt b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
new file mode 100644
index 000000000000..f26625e42693
--- /dev/null
+++ b/Documentation/devicetree/bindings/hsi/omap-ssi.txt
@@ -0,0 +1,97 @@
+OMAP SSI controller bindings
+
+OMAP Synchronous Serial Interface (SSI) controller implements a legacy
+variant of MIPI's High Speed Synchronous Serial Interface (HSI).
+
+Required properties:
+- compatible:           Should include "ti,omap3-ssi".
+- reg-names:            Contains the values "sys" and "gdd" (in this order).
+- reg:                  Contains a matching register specifier for each entry
+                        in reg-names.
+- interrupt-names:      Contains the value "gdd_mpu".
+- interrupts:           Contains matching interrupt information for each entry
+                        in interrupt-names.
+- ranges:               Represents the bus address mapping between the main
+                        controller node and the child nodes below.
+- clock-names:          Must include the following entries:
+  "ssi_ssr_fck": The OMAP clock of that name
+  "ssi_sst_fck": The OMAP clock of that name
+  "ssi_ick": The OMAP clock of that name
+- clocks:               Contains a matching clock specifier for each entry in
+                        clock-names.
+- #address-cells:       Should be set to <1>
+- #size-cells:          Should be set to <1>
+
+Each port is represented as a sub-node of the ti,omap3-ssi device.
+
+Required Port sub-node properties:
+- compatible:           Should be set to the following value
+                        ti,omap3-ssi-port (applicable to OMAP34xx devices)
+- reg-names:            Contains the values "tx" and "rx" (in this order).
+- reg:                  Contains a matching register specifier for each entry
+                        in reg-names.
+- interrupt-parent      Should be a phandle for the interrupt controller
+- interrupts:           Should contain interrupt specifiers for mpu interrupts
+                        0 and 1 (in this order).
+- ti,ssi-cawake-gpio:   Defines which GPIO pin is used to signify CAWAKE
+                        events for the port. This is an optional board-specific
+                        property. If it's missing the port will not be
+                        enabled.
+
+Example for Nokia N900:
+
+ssi-controller@48058000 {
+        compatible = "ti,omap3-ssi";
+
+        /* needed until hwmod is updated to use the compatible string */
+        ti,hwmods = "ssi";
+
+        reg = <0x48058000 0x1000>,
+              <0x48059000 0x1000>;
+        reg-names = "sys",
+                    "gdd";
+
+        interrupts = <55>;
+        interrupt-names = "gdd_mpu";
+
+        clocks = <&ssi_ssr_fck>,
+                 <&ssi_sst_fck>,
+                 <&ssi_ick>;
+        clock-names = "ssi_ssr_fck",
+                      "ssi_sst_fck",
+                      "ssi_ick";
+
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        ssi-port@4805a000 {
+                compatible = "ti,omap3-ssi-port";
+
+                reg = <0x4805a000 0x800>,
+                      <0x4805a800 0x800>;
+                reg-names = "tx",
+                            "rx";
+
+                interrupt-parent = <&intc>;
+                interrupts = <67>,
+                             <68>;
+
+                ti,ssi-cawake-gpio = <&gpio5 23 GPIO_ACTIVE_HIGH>; /* 151 */
+        }
+
+        ssi-port@4805a000 {
+                compatible = "ti,omap3-ssi-port";
+
+                reg = <0x4805b000 0x800>,
+                      <0x4805b800 0x800>;
+                reg-names = "tx",
+                            "rx";
+
+                interrupt-parent = <&intc>;
+                interrupts = <69>,
+                             <70>;
+
+                status = "disabled"; /* second port is not used on N900 */
+        }
+}
diff --git a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
index 1ac8ea8ade1d..bfeabb843941 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-arb-gpio-challenge.txt
@@ -8,6 +8,12 @@ the standard I2C multi-master rules.  Using GPIOs is generally useful in
 the case where there is a device on the bus that has errata and/or bugs
 that makes standard multimaster mode not feasible.
 
+Note that this scheme works well enough but has some downsides:
+* It is nonstandard (not using standard I2C multimaster)
+* Having two masters on a bus in general makes it relatively hard to debug
+  problems (hard to tell if i2c issues were caused by one master, another, or
+  some device on the bus).
+
 
 Algorithm:
 
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
new file mode 100644
index 000000000000..898f030eba62
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cros-ec-tunnel.txt
@@ -0,0 +1,39 @@
+I2C bus that tunnels through the ChromeOS EC (cros-ec)
+======================================================
+On some ChromeOS board designs we've got a connection to the EC (embedded
+controller) but no direct connection to some devices on the other side of
+the EC (like a battery and PMIC).  To get access to those devices we need
+to tunnel our i2c commands through the EC.
+
+The node for this device should be under a cros-ec node like google,cros-ec-spi
+or google,cros-ec-i2c.
+
+
+Required properties:
+- compatible: google,cros-ec-i2c-tunnel
+- google,remote-bus: The EC bus we'd like to talk to.
+
+Optional child nodes:
+- One node per I2C device connected to the tunnelled I2C bus.
+
+
+Example:
+        cros-ec@0 {
+                compatible = "google,cros-ec-spi";
+
+                ...
+
+                i2c-tunnel {
+                        compatible = "google,cros-ec-i2c-tunnel";
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        google,remote-bus = <0>;
+
+                        battery: sbs-battery@b {
+                                compatible = "sbs,sbs-battery";
+                                reg = <0xb>;
+                                sbs,poll-retry-count = <1>;
+                        };
+                };
+        }
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
index 056732cfdcee..d4745e31f5c6 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -5,7 +5,14 @@ at various speeds ranging from 100khz to 3.4Mhz.
 
 Required properties:
   - compatible: value should be.
-      -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+        -> "samsung,exynos5-hsi2c", (DEPRECATED)
+                                for i2c compatible with HSI2C available
+                                on Exynos5250 and Exynos5420 SoCs.
+        -> "samsung,exynos5250-hsi2c", for i2c compatible with HSI2C available
+                                on Exynos5250 and Exynos5420 SoCs.
+        -> "samsung,exynos5260-hsi2c", for i2c compatible with HSI2C available
+                                on Exynos5260 SoCs.
+
   - reg: physical base address of the controller and length of memory mapped
     region.
   - interrupts: interrupt number to the cpu.
@@ -26,7 +33,7 @@ Optional properties:
 Example:
 
 hsi2c@12ca0000 {
-        compatible = "samsung,exynos5-hsi2c";
+        compatible = "samsung,exynos5250-hsi2c";
         reg = <0x12ca0000 0x100>;
         interrupts = <56>;
         clock-frequency = <100000>;
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index befd4fb4764f..5c30026921ae 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -5,7 +5,7 @@ Required properties :
 
  - reg             : Offset and length of the register set for the device
  - compatible      : Should be either:
-                     - "allwinner,sun4i-i2c"
+                     - "allwinner,sun4i-a10-i2c"
                      - "allwinner,sun6i-a31-i2c"
                      - "marvell,mv64xxx-i2c"
                      - "marvell,mv78230-i2c"
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
index dd8b2dd1edeb..16b3e07aa98f 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -7,6 +7,9 @@ Required properties:
         "renesas,i2c-r8a7779"
         "renesas,i2c-r8a7790"
         "renesas,i2c-r8a7791"
+        "renesas,i2c-r8a7792"
+        "renesas,i2c-r8a7793"
+        "renesas,i2c-r8a7794"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: interrupt specifier.
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
new file mode 100644
index 000000000000..d2153ce36fa8
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sh_mobile.txt
@@ -0,0 +1,26 @@
+Device tree configuration for Renesas IIC (sh_mobile) driver
+
+Required properties:
+- compatible      : "renesas,iic-<soctype>". "renesas,rmobile-iic" as fallback
+- reg             : address start and address range size of device
+- interrupts      : interrupt of device
+- clocks          : clock for device
+- #address-cells  : should be <1>
+- #size-cells     : should be <0>
+
+Optional properties:
+- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset.
+
+Pinctrl properties might be needed, too. See there.
+
+Example:
+
+        iic0: i2c@e6500000 {
+                compatible = "renesas,iic-r8a7790", "renesas,rmobile-iic";
+                reg = <0 0xe6500000 0 0x425>;
+                interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&mstp3_clks R8A7790_CLK_IIC0>;
+                clock-frequency = <400000>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 71724d026ffa..bef86e57c388 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -13,8 +13,22 @@ ad,ad7414		SMBus/I2C Digital Temperature Sensor in 6-Pin SOT with SMBus Alert an
 ad,adm9240              ADM9240:  Complete System Hardware Monitor for uProcessor-Based Systems
 adi,adt7461             +/-1C TDM Extended Temp Range I.C
 adt7461                 +/-1C TDM Extended Temp Range I.C
+adi,adt7473             +/-1C TDM Extended Temp Range I.C
+adi,adt7475             +/-1C TDM Extended Temp Range I.C
+adi,adt7476             +/-1C TDM Extended Temp Range I.C
+adi,adt7490             +/-1C TDM Extended Temp Range I.C
 at,24c08                i2c serial eeprom  (24cxx)
+atmel,24c00             i2c serial eeprom  (24cxx)
+atmel,24c01             i2c serial eeprom  (24cxx)
 atmel,24c02             i2c serial eeprom  (24cxx)
+atmel,24c04             i2c serial eeprom  (24cxx)
+atmel,24c16             i2c serial eeprom  (24cxx)
+atmel,24c32             i2c serial eeprom  (24cxx)
+atmel,24c64             i2c serial eeprom  (24cxx)
+atmel,24c128            i2c serial eeprom  (24cxx)
+atmel,24c256            i2c serial eeprom  (24cxx)
+atmel,24c512            i2c serial eeprom  (24cxx)
+atmel,24c1024           i2c serial eeprom  (24cxx)
 atmel,at97sc3204t       i2c trusted platform module (TPM)
 capella,cm32181         CM32181: Ambient Light Sensor
 catalyst,24c32          i2c serial eeprom
@@ -46,8 +60,10 @@ maxim,ds1050		5 Bit Programmable, Pulse-Width Modulator
 maxim,max1237           Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs
 maxim,max6625           9-Bit/12-Bit Temperature Sensors with I²C-Compatible Serial Interface
 mc,rv3029c2             Real Time Clock Module with I2C-Bus
+national,lm63           Temperature sensor with integrated fan control
 national,lm75           I2C TEMP SENSOR
 national,lm80           Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
+national,lm85           Temperature sensor with integrated fan control
 national,lm92           ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface
 nuvoton,npct501         i2c trusted platform module (TPM)
 nxp,pca9556             Octal SMBus and I2C registered interface
diff --git a/Documentation/devicetree/bindings/iio/proximity/as3935.txt b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
new file mode 100644
index 000000000000..ae23dd8da736
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/proximity/as3935.txt
@@ -0,0 +1,28 @@
+Austrian Microsystems AS3935 Franklin lightning sensor device driver
+
+Required properties:
+        - compatible: must be "ams,as3935"
+        - reg: SPI chip select number for the device
+        - spi-cpha: SPI Mode 1. Refer to spi/spi-bus.txt for generic SPI
+        slave node bindings.
+        - interrupt-parent : should be the phandle for the interrupt controller
+        - interrupts : the sole interrupt generated by the device
+
+        Refer to interrupt-controller/interrupts.txt for generic
+        interrupt client node bindings.
+
+Optional properties:
+        - ams,tuning-capacitor-pf: Calibration tuning capacitor stepping
+          value 0 - 120pF. This will require using the calibration data from
+          the manufacturer.
+
+Example:
+
+as3935@0 {
+        compatible = "ams,as3935";
+        reg = <0>;
+        spi-cpha;
+        interrupt-parent = <&gpio1>;
+        interrupts = <16 1>;
+        ams,tuning-capacitor-pf = <80>;
+};
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/interrupt-controller/brcm,l2-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
new file mode 100644
index 000000000000..448273a30a11
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,l2-intc.txt
@@ -0,0 +1,29 @@
+Broadcom Generic Level 2 Interrupt Controller
+
+Required properties:
+
+- compatible: should be "brcm,l2-intc"
+- reg: specifies the base physical address and size of the registers
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an
+  interrupt source. Should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+  this controller is cacaded from
+- interrupts: specifies the interrupt line in the interrupt-parent irq space
+  to be used for cascading
+
+Optional properties:
+
+- brcm,irq-can-wake: If present, this means the L2 controller can be used as a
+  wakeup source for system suspend/resume.
+
+Example:
+
+hif_intr2_intc: interrupt-controller@f0441000 {
+        compatible = "brcm,l2-intc";
+        reg = <0xf0441000 0x30>;
+        interrupt-controller;
+        #interrupt-cells = <1>;
+        interrupt-parent = <&intc>;
+        interrupts = <0x0 0x20 0x0>;
+};
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt
index 5fc03134a999..5fc03134a999 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,armada-370-xp-mpic.txt
diff --git a/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
new file mode 100644
index 000000000000..6fa4c737af23
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/samsung,sysmmu.txt
@@ -0,0 +1,70 @@
+Samsung Exynos IOMMU H/W, System MMU (System Memory Management Unit)
+
+Samsung's Exynos architecture contains System MMUs that enables scattered
+physical memory chunks visible as a contiguous region to DMA-capable peripheral
+devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
+
+System MMU is an IOMMU and supports identical translation table format to
+ARMv7 translation tables with minimum set of page properties including access
+permissions, shareability and security protection. In addition, System MMU has
+another capabilities like L2 TLB or block-fetch buffers to minimize translation
+latency.
+
+System MMUs are in many to one relation with peripheral devices, i.e. single
+peripheral device might have multiple System MMUs (usually one for each bus
+master), but one System MMU can handle transactions from only one peripheral
+device. The relation between a System MMU and the peripheral device needs to be
+defined in device node of the peripheral device.
+
+MFC in all Exynos SoCs and FIMD, M2M Scalers and G2D in Exynos5420 has 2 System
+MMUs.
+* MFC has one System MMU on its left and right bus.
+* FIMD in Exynos5420 has one System MMU for window 0 and 4, the other system MMU
+  for window 1, 2 and 3.
+* M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and
+  the other System MMU on the write channel.
+The drivers must consider how to handle those System MMUs. One of the idea is
+to implement child devices or sub-devices which are the client devices of the
+System MMU.
+
+Note:
+The current DT binding for the Exynos System MMU is incomplete.
+The following properties can be removed or changed, if found incompatible with
+the "Generic IOMMU Binding" support for attaching devices to the IOMMU.
+
+Required properties:
+- compatible: Should be "samsung,exynos-sysmmu"
+- reg: A tuple of base address and size of System MMU registers.
+- interrupt-parent: The phandle of the interrupt controller of System MMU
+- interrupts: An interrupt specifier for interrupt signal of System MMU,
+              according to the format defined by a particular interrupt
+              controller.
+- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
+               Optional "master" if the clock to the System MMU is gated by
+               another gate clock other than "sysmmu".
+               Exynos4 SoCs, there needs no "master" clock.
+               Exynos5 SoCs, some System MMUs must have "master" clocks.
+- clocks: Required if the System MMU is needed to gate its clock.
+- samsung,power-domain: Required if the System MMU is needed to gate its power.
+          Please refer to the following document:
+          Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+
+Examples:
+        gsc_0: gsc@13e00000 {
+                compatible = "samsung,exynos5-gsc";
+                reg = <0x13e00000 0x1000>;
+                interrupts = <0 85 0>;
+                samsung,power-domain = <&pd_gsc>;
+                clocks = <&clock CLK_GSCL0>;
+                clock-names = "gscl";
+        };
+
+        sysmmu_gsc0: sysmmu@13E80000 {
+                compatible = "samsung,exynos-sysmmu";
+                reg = <0x13E80000 0x1000>;
+                interrupt-parent = <&combiner>;
+                interrupts = <2 0>;
+                clock-names = "sysmmu", "master";
+                clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
+                samsung,power-domain = <&pd_gsc>;
+        };
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/media/i2c/adv7604.txt b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
new file mode 100644
index 000000000000..c27cede3bd68
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/i2c/adv7604.txt
@@ -0,0 +1,70 @@
+* Analog Devices ADV7604/11 video decoder with HDMI receiver
+
+The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI
+receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input,
+and the ADV7611 has one HDMI input and no analog input.
+
+These device tree bindings support the ADV7611 only at the moment.
+
+Required Properties:
+
+  - compatible: Must contain one of the following
+    - "adi,adv7611" for the ADV7611
+
+  - reg: I2C slave address
+
+  - hpd-gpios: References to the GPIOs that control the HDMI hot-plug
+    detection pins, one per HDMI input. The active flag indicates the GPIO
+    level that enables hot-plug detection.
+
+The device node must contain one 'port' child node per device input and output
+port, in accordance with the video interface bindings defined in
+Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
+are numbered as follows.
+
+  Port                  ADV7611
+------------------------------------------------------------
+  HDMI                  0
+  Digital output        1
+
+The digital output port node must contain at least one endpoint.
+
+Optional Properties:
+
+  - reset-gpios: Reference to the GPIO connected to the device's reset pin.
+
+Optional Endpoint Properties:
+
+  The following three properties are defined in video-interfaces.txt and are
+  valid for source endpoints only.
+
+  - hsync-active: Horizontal synchronization polarity. Defaults to active low.
+  - vsync-active: Vertical synchronization polarity. Defaults to active low.
+  - pclk-sample: Pixel clock polarity. Defaults to output on the falling edge.
+
+  If none of hsync-active, vsync-active and pclk-sample is specified the
+  endpoint will use embedded BT.656 synchronization.
+
+
+Example:
+
+        hdmi_receiver@4c {
+                compatible = "adi,adv7611";
+                reg = <0x4c>;
+
+                reset-gpios = <&ioexp 0 GPIO_ACTIVE_LOW>;
+                hpd-gpios = <&ioexp 2 GPIO_ACTIVE_HIGH>;
+
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                        reg = <0>;
+                };
+                port@1 {
+                        reg = <1>;
+                        hdmi_in: endpoint {
+                                remote-endpoint = <&ccdc_in>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.txt b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
new file mode 100644
index 000000000000..87fe08abf36d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -0,0 +1,43 @@
+* Renesas VSP1 Video Processing Engine
+
+The VSP1 is a video processing engine that supports up-/down-scaling, alpha
+blending, color space conversion and various other image processing features.
+It can be found in the Renesas R-Car second generation SoCs.
+
+Required properties:
+
+  - compatible: Must contain "renesas,vsp1"
+
+  - reg: Base address and length of the registers block for the VSP1.
+  - interrupts: VSP1 interrupt specifier.
+  - clocks: A phandle + clock-specifier pair for the VSP1 functional clock.
+
+  - renesas,#rpf: Number of Read Pixel Formatter (RPF) modules in the VSP1.
+  - renesas,#uds: Number of Up Down Scaler (UDS) modules in the VSP1.
+  - renesas,#wpf: Number of Write Pixel Formatter (WPF) modules in the VSP1.
+
+
+Optional properties:
+
+  - renesas,has-lif: Boolean, indicates that the LCD Interface (LIF) module is
+    available.
+  - renesas,has-lut: Boolean, indicates that the Look Up Table (LUT) module is
+    available.
+  - renesas,has-sru: Boolean, indicates that the Super Resolution Unit (SRU)
+    module is available.
+
+
+Example: R8A7790 (R-Car H2) VSP1-S node
+
+        vsp1@fe928000 {
+                compatible = "renesas,vsp1";
+                reg = <0 0xfe928000 0 0x8000>;
+                interrupts = <0 267 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&mstp1_clks R8A7790_CLK_VSP1_S>;
+
+                renesas,has-lut;
+                renesas,has-sru;
+                renesas,#rpf = <5>;
+                renesas,#uds = <3>;
+                renesas,#wpf = <4>;
+        };
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index f4181680831b..3e3c5f349570 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -10,7 +10,8 @@ Required properties:
   - compatible : value should be either one among the following
         (a) "samsung,mfc-v5" for MFC v5 present in Exynos4 SoCs
         (b) "samsung,mfc-v6" for MFC v6 present in Exynos5 SoCs
-        (b) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
+        (c) "samsung,mfc-v7" for MFC v7 present in Exynos5420 SoC
+        (d) "samsung,mfc-v8" for MFC v8 present in Exynos5800 SoC
 
   - reg : Physical base address of the IP registers and length of memory
           mapped region.
diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
index 653c90c34a71..1ee3bc09f319 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -6,10 +6,11 @@ The actual devices are instantiated from the child nodes of a Device Bus node.
 
 Required properties:
 
- - compatible:          Currently only Armada 370/XP SoC are supported,
-                        with this compatible string:
+ - compatible:          Armada 370/XP SoC are supported using the
+                        "marvell,mvebu-devbus" compatible string.
 
-                        marvell,mvebu-devbus
+                        Orion5x SoC are supported using the
+                        "marvell,orion-devbus" compatible string.
 
  - reg:                 A resource specifier for the register space.
                         This is the base address of a chip select within
@@ -22,7 +23,14 @@ Required properties:
                         integer values for each chip-select line in use:
                         0 <physical address of mapping> <size>
 
-Mandatory timing properties for child nodes:
+Optional properties:
+
+ - devbus,keep-config   This property can optionally be used to keep
+                        using the timing parameters set by the
+                        bootloader. It makes all the timing properties
+                        described below unused.
+
+Timing properties for child nodes:
 
 Read parameters:
 
@@ -30,21 +38,26 @@ Read parameters:
                         drive the AD bus after the completion of a device read.
                         This prevents contentions on the Device Bus after a read
                         cycle from a slow device.
+                        Mandatory, except if devbus,keep-config is used.
 
- - devbus,bus-width:    Defines the bus width (e.g. <16>)
+ - devbus,bus-width:    Defines the bus width, in bits (e.g. <16>).
+                        Mandatory, except if devbus,keep-config is used.
 
  - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
                         to read data sample. This parameter is useful for
                         synchronous pipelined devices, where the address
                         precedes the read data by one or two cycles.
+                        Mandatory, except if devbus,keep-config is used.
 
  - devbus,acc-first-ps: Defines the time delay from the negation of
                         ALE[0] to the cycle that the first read data is sampled
                         by the controller.
+                        Mandatory, except if devbus,keep-config is used.
 
  - devbus,acc-next-ps:  Defines the time delay between the cycle that
                         samples data N and the cycle that samples data N+1
                         (in burst accesses).
+                        Mandatory, except if devbus,keep-config is used.
 
  - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
                         DEV_OEn assertion. If set to 0 (default),
@@ -52,6 +65,8 @@ Read parameters:
                         This parameter has no affect on <acc-first-ps> parameter
                         (no affect on first data sample). Set <rd-setup-ps>
                         to a value smaller than <acc-first-ps>.
+                        Mandatory for "marvell,mvebu-devbus" compatible string,
+                        except if devbus,keep-config is used.
 
  - devbus,rd-hold-ps:   Defines the time between the last data sample to the
                         de-assertion of DEV_CSn. If set to 0 (default),
@@ -62,16 +77,20 @@ Read parameters:
                         last data sampled. Also this parameter has no
                         affect on <turn-off-ps> parameter.
                         Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+                        Mandatory for "marvell,mvebu-devbus" compatible string,
+                        except if devbus,keep-config is used.
 
 Write parameters:
 
  - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
                         to the DEV_WEn assertion.
+                        Mandatory.
 
  - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
                         A[2:0] and Data are kept valid as long as DEV_WEn
                         is active. This parameter defines the setup time of
                         address and data to DEV_WEn rise.
+                        Mandatory.
 
  - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
                         inactive (high) between data beats of a burst write.
@@ -79,10 +98,13 @@ Write parameters:
                         <wr-high-ps> - <tick> ps.
                         This parameter defines the hold time of address and
                         data after DEV_WEn rise.
+                        Mandatory.
 
  - devbus,sync-enable: Synchronous device enable.
                        1: True
                        0: False
+                       Mandatory for "marvell,mvebu-devbus" compatible string,
+                       except if devbus,keep-config is used.
 
 An example for an Armada XP GP board, with a 16 MiB NOR device as child
 is showed below. Note that the Device Bus driver is in charge of allocating
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
index 1fe30e2b10da..be51a15e05f9 100644
--- a/Documentation/devicetree/bindings/mfd/bcm590xx.txt
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -19,7 +19,9 @@ Optional child nodes:
   The valid regulator node names for BCM59056 are:
         rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
         mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
-        csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+        csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr,
+        gpldo1, gpldo2, gpldo3, gpldo4, gpldo5, gpldo6,
+        vbus
 
 Example:
         pmu: bcm59056@8 {
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/mc13xxx.txt b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
index 1413f39912d3..8aba48821a85 100644
--- a/Documentation/devicetree/bindings/mfd/mc13xxx.txt
+++ b/Documentation/devicetree/bindings/mfd/mc13xxx.txt
@@ -10,6 +10,9 @@ Optional properties:
 - fsl,mc13xxx-uses-touch : Indicate the touchscreen controller is being used
 
 Sub-nodes:
+- codec: Contain the Audio Codec node.
+  - adc-port: Contain PMIC SSI port number used for ADC.
+  - dac-port: Contain PMIC SSI port number used for DAC.
 - leds : Contain the led nodes and initial register values in property
   "led-control". Number of register depends of used IC, for MC13783 is 6,
   for MC13892 is 4, for MC34708 is 1. See datasheet for bits definitions of
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/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 802e839b0829..d81ba30c0d8b 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -56,6 +56,20 @@ for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
 Grouping of BUCKs sharing ramp rate setting is as follow : BUCK[1, 6],
 BUCK[3, 4], and BUCK[7, 8, 10]
 
+On S2MPS14 the LDO10, LDO11 and LDO12 can be configured to external control
+over GPIO. To turn this feature on this property must be added to the regulator
+sub-node:
+        - samsung,ext-control-gpios: GPIO specifier for one GPIO
+                controlling this regulator (enable/disable);
+Example:
+        LDO12 {
+                regulator-name = "V_EMMC_2.8V";
+                regulator-min-microvolt = <2800000>;
+                regulator-max-microvolt = <2800000>;
+                samsung,ext-control-gpios = <&gpk0 2 0>;
+        };
+
+
 The regulator constraints inside the regulator nodes use the standard regulator
 bindings which are documented elsewhere.
 
diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
new file mode 100644
index 000000000000..1f5a31fef907
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
@@ -0,0 +1,59 @@
+* Allwinner PRCM (Power/Reset/Clock Management) Multi-Functional Device
+
+PRCM is an MFD device exposing several Power Management related devices
+(like clks and reset controllers).
+
+Required properties:
+ - compatible: "allwinner,sun6i-a31-prcm"
+ - reg: The PRCM registers range
+
+The prcm node may contain several subdevices definitions:
+ - see Documentation/devicetree/clk/sunxi.txt for clock devices
+ - see Documentation/devicetree/reset/allwinner,sunxi-clock-reset.txt for reset
+   controller devices
+
+
+Example:
+
+        prcm: prcm@01f01400 {
+                compatible = "allwinner,sun6i-a31-prcm";
+                reg = <0x01f01400 0x200>;
+
+                /* Put subdevices here */
+                ar100: ar100_clk {
+                        compatible = "allwinner,sun6i-a31-ar100-clk";
+                        #clock-cells = <0>;
+                        clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+                };
+
+                ahb0: ahb0_clk {
+                        compatible = "fixed-factor-clock";
+                        #clock-cells = <0>;
+                        clock-div = <1>;
+                        clock-mult = <1>;
+                        clocks = <&ar100_div>;
+                        clock-output-names = "ahb0";
+                };
+
+                apb0: apb0_clk {
+                        compatible = "allwinner,sun6i-a31-apb0-clk";
+                        #clock-cells = <0>;
+                        clocks = <&ahb0>;
+                        clock-output-names = "apb0";
+                };
+
+                apb0_gates: apb0_gates_clk {
+                        compatible = "allwinner,sun6i-a31-apb0-gates-clk";
+                        #clock-cells = <1>;
+                        clocks = <&apb0>;
+                        clock-output-names = "apb0_pio", "apb0_ir",
+                                        "apb0_timer01", "apb0_p2wi",
+                                        "apb0_uart", "apb0_1wire",
+                                        "apb0_i2c";
+                };
+
+                apb0_rst: apb0_rst {
+                        compatible = "allwinner,sun6i-a31-clock-reset";
+                        #reset-cells = <1>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt
new file mode 100644
index 000000000000..20963c76b4bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/ti-keystone-devctrl.txt
@@ -0,0 +1,19 @@
+* Device tree bindings for Texas Instruments keystone device state control
+
+The Keystone II devices have a set of registers that are used to control
+the status of its peripherals. This node is intended to allow access to
+this functionality.
+
+Required properties:
+
+- compatible:           "ti,keystone-devctrl", "syscon"
+
+- reg:                  contains offset/length value for device state control
+                        registers space.
+
+Example:
+
+devctrl: device-state-control@0x02620000 {
+        compatible = "ti,keystone-devctrl", "syscon";
+        reg = <0x02620000 0x1000>;
+};
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/mfd/twl6040.txt b/Documentation/devicetree/bindings/mfd/twl6040.txt
index 0f5dd709d752..a41157b5d930 100644
--- a/Documentation/devicetree/bindings/mfd/twl6040.txt
+++ b/Documentation/devicetree/bindings/mfd/twl6040.txt
@@ -19,6 +19,8 @@ Required properties:
 
 Optional properties, nodes:
 - enable-active-high: To power on the twl6040 during boot.
+- clocks: phandle to the clk32k clock provider
+- clock-names: Must be "clk32k"
 
 Vibra functionality
 Required properties:
diff --git a/Documentation/devicetree/bindings/misc/arm-charlcd.txt b/Documentation/devicetree/bindings/misc/arm-charlcd.txt
new file mode 100644
index 000000000000..e28e2aac47f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/arm-charlcd.txt
@@ -0,0 +1,18 @@
+ARM Versatile Character LCD
+-----------------------------------------------------
+This binding defines the character LCD interface found on ARM Versatile AB
+and PB reference platforms.
+
+Required properties:
+- compatible : "arm,versatile-clcd"
+- reg : Location and size of character LCD registers
+
+Optional properties:
+- interrupts - single interrupt for character LCD. The character LCD can
+  operate in polled mode without an interrupt.
+
+Example:
+        lcd@10008000 {
+                compatible = "arm,versatile-lcd";
+                reg = <0x10008000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
index b8653ea97957..e5bc49f764d1 100644
--- a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -12,7 +12,7 @@ extensions to the Synopsys Designware Mobile Storage Host Controller.
 Required Properties:
 
 * compatible: should be one of the following.
-  - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extentions.
+  - "hisilicon,hi4511-dw-mshc": for controllers with hi4511 specific extensions.
 
 Example:
 
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/mmci.txt b/Documentation/devicetree/bindings/mmc/mmci.txt
index 2b584cae352a..03796cf2d3e7 100644
--- a/Documentation/devicetree/bindings/mmc/mmci.txt
+++ b/Documentation/devicetree/bindings/mmc/mmci.txt
@@ -4,12 +4,58 @@ The ARM PrimeCell MMCI PL180 and PL181 provides an interface for
 reading and writing to MultiMedia and SD cards alike.
 
 This file documents differences between the core properties described
-by mmc.txt and the properties used by the mmci driver.
+by mmc.txt and the properties used by the mmci driver. Using "st" as
+the prefix for a property, indicates support by the ST Micro variant.
 
 Required properties:
 - compatible             : contains "arm,pl18x", "arm,primecell".
-- arm,primecell-periphid : contains the PrimeCell Peripheral ID.
+- vmmc-supply            : phandle to the regulator device tree node, mentioned
+                           as the VCC/VDD supply in the eMMC/SD specs.
 
 Optional properties:
-- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable
-- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable
+- arm,primecell-periphid : contains the PrimeCell Peripheral ID, it overrides
+                           the ID provided by the HW
+- vqmmc-supply           : phandle to the regulator device tree node, mentioned
+                           as the VCCQ/VDD_IO supply in the eMMC/SD specs.
+- st,sig-dir-dat0        : bus signal direction pin used for DAT[0].
+- st,sig-dir-dat2        : bus signal direction pin used for DAT[2].
+- st,sig-dir-dat31       : bus signal direction pin used for DAT[3] and DAT[1].
+- st,sig-dir-dat74       : bus signal direction pin used for DAT[4] to DAT[7].
+- st,sig-dir-cmd         : cmd signal direction pin used for CMD.
+- st,sig-pin-fbclk       : feedback clock signal pin used.
+
+Deprecated properties:
+- mmc-cap-mmc-highspeed  : indicates whether MMC is high speed capable.
+- mmc-cap-sd-highspeed   : indicates whether SD is high speed capable.
+
+Example:
+
+sdi0_per1@80126000 {
+        compatible = "arm,pl18x", "arm,primecell";
+        reg = <0x80126000 0x1000>;
+        interrupts = <0 60 IRQ_TYPE_LEVEL_HIGH>;
+
+        dmas = <&dma 29 0 0x2>, /* Logical - DevToMem */
+               <&dma 29 0 0x0>; /* Logical - MemToDev */
+        dma-names = "rx", "tx";
+
+        clocks = <&prcc_kclk 1 5>, <&prcc_pclk 1 5>;
+        clock-names = "sdi", "apb_pclk";
+
+        max-frequency = <100000000>;
+        bus-width = <4>;
+        cap-sd-highspeed;
+        cap-mmc-highspeed;
+        cd-gpios  = <&gpio2 31 0x4>; // 95
+        st,sig-dir-dat0;
+        st,sig-dir-dat2;
+        st,sig-dir-cmd;
+        st,sig-pin-fbclk;
+
+        vmmc-supply = <&ab8500_ldo_aux3_reg>;
+        vqmmc-supply = <&vmmci>;
+
+        pinctrl-names = "default", "sleep";
+        pinctrl-0 = <&sdi0_default_mode>;
+        pinctrl-1 = <&sdi0_sleep_mode>;
+};
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/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
index 328e990d2546..42e0a9afa100 100644
--- a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -3,7 +3,7 @@
 Samsung's SDHCI controller is used as a connectivity interface with external
 MMC, SD and eMMC storage mediums. This file documents differences between the
 core mmc properties described by mmc.txt and the properties used by the
-Samsung implmentation of the SDHCI controller.
+Samsung implementation of the SDHCI controller.
 
 Required SoC Specific Properties:
 - compatible: should be one of the following
diff --git a/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
new file mode 100644
index 000000000000..91b3a3467150
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sunxi-mmc.txt
@@ -0,0 +1,43 @@
+* Allwinner sunxi MMC controller
+
+The highspeed MMC host controller on Allwinner SoCs provides an interface
+for MMC, SD and SDIO types of memory cards.
+
+Supported maximum speeds are the ones of the eMMC standard 4.5 as well
+as the speed of SD standard 3.0.
+Absolute maximum transfer rate is 200MB/s
+
+Required properties:
+ - compatible : "allwinner,sun4i-a10-mmc" or "allwinner,sun5i-a13-mmc"
+ - reg : mmc controller base registers
+ - clocks : a list with 2 phandle + clock specifier pairs
+ - clock-names : must contain "ahb" and "mmc"
+ - interrupts : mmc controller interrupt
+
+Optional properties:
+ - resets : phandle + reset specifier pair
+ - reset-names : must contain "ahb"
+ - for cd, bus-width and additional generic mmc parameters
+   please refer to mmc.txt within this directory
+
+Examples:
+        - Within .dtsi:
+        mmc0: mmc@01c0f000 {
+                compatible = "allwinner,sun5i-a13-mmc";
+                reg = <0x01c0f000 0x1000>;
+                clocks = <&ahb_gates 8>, <&mmc0_clk>;
+                clock-names = "ahb", "mod";
+                interrupts = <0 32 4>;
+                status = "disabled";
+        };
+
+        - Within dts:
+        mmc0: mmc@01c0f000 {
+                pinctrl-names = "default", "default";
+                pinctrl-0 = <&mmc0_pins_a>;
+                pinctrl-1 = <&mmc0_cd_pin_reference_design>;
+                bus-width = <4>;
+                cd-gpios = <&pio 7 1 0>; /* PH1 */
+                cd-inverted;
+                status = "okay";
+        };
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 5e1f31b5ff70..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:
 
@@ -43,7 +45,7 @@ Optional properties:
                 ELM hardware engines should specify this device node in .dtsi
                 Using ELM for ECC error correction frees some CPU cycles.
 
-For inline partiton table parsing (optional):
+For inline partition table parsing (optional):
 
  - #address-cells: should be set to 1
  - #size-cells: should be set to 1
@@ -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/gpmc-nor.txt b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
index 420b3ab18890..4828c17bb784 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nor.txt
@@ -30,7 +30,7 @@ Optional properties:
 - gpmc,XXX              Additional GPMC timings and settings parameters. See
                         Documentation/devicetree/bindings/bus/ti-gpmc.txt
 
-Optional properties for partiton table parsing:
+Optional properties for partition table parsing:
 - #address-cells: should be set to 1
 - #size-cells: should be set to 1
 
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
index b7529424ac88..5d8fa527c496 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-onenand.txt
@@ -17,7 +17,7 @@ Optional properties:
 
  - dma-channel:         DMA Channel index
 
-For inline partiton table parsing (optional):
+For inline partition table parsing (optional):
 
  - #address-cells: should be set to 1
  - #size-cells: should be set to 1
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
-               supported chips.
+               "spi_nor_ids" table in drivers/mtd/spi-nor/spi-nor.c for the list
+               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/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt
index 7fbb027218a1..a1d71eb43b20 100644
--- a/Documentation/devicetree/bindings/net/arc_emac.txt
+++ b/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -4,11 +4,15 @@ Required properties:
 - compatible: Should be "snps,arc-emac"
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the EMAC interrupts
-- clock-frequency: CPU frequency. It is needed to calculate and set polling
-period of EMAC.
 - max-speed: see ethernet.txt file in the same directory.
 - phy: see ethernet.txt file in the same directory.
 
+Clock handling:
+The clock frequency is needed to calculate and set polling period of EMAC.
+It must be provided by one of:
+- clock-frequency: CPU frequency.
+- clocks: reference to the clock supplying the EMAC.
+
 Child nodes of the driver are the individual PHY devices connected to the
 MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
 
@@ -19,7 +23,11 @@ Examples:
                 reg = <0xc0fc2000 0x3c>;
                 interrupts = <6>;
                 mac-address = [ 00 11 22 33 44 55 ];
+
                 clock-frequency = <80000000>;
+                /* or */
+                clocks = <&emac_clock>;
+
                 max-speed = <100>;
                 phy = <&phy0>;
 
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/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
index 9ecd43d8792c..3fc360523bc9 100644
--- a/Documentation/devicetree/bindings/net/ethernet.txt
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -10,7 +10,7 @@ The following properties are common to the Ethernet controllers:
 - max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
   the maximum frame size (there's contradiction in ePAPR).
 - phy-mode: string, operation mode of the PHY interface; supported values are
-  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
+  "mii", "gmii", "sgmii", "qsgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
   "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
   standard property;
 - phy-connection-type: the same as "phy-mode" property but described in ePAPR;
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,
-    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.
+  - fixed-link : See fixed-link.txt in the same directory.
   - 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/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt
index c79bab025369..8dbcf8295c6c 100644
--- a/Documentation/devicetree/bindings/net/mdio-gpio.txt
+++ b/Documentation/devicetree/bindings/net/mdio-gpio.txt
@@ -14,7 +14,7 @@ node.
 Example:
 
 aliases {
-        mdio-gpio0 = <&mdio0>;
+        mdio-gpio0 = &mdio0;
 };
 
 mdio0: mdio {
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/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
index 636f0ac4e223..2a60cd3e8d5d 100644
--- a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -23,5 +23,5 @@ gmac0: ethernet@ff700000 {
         interrupt-names = "macirq";
         mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
         clocks = <&emac_0_clk>;
-        clocks-names = "stmmaceth";
+        clock-names = "stmmaceth";
 };
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 80c1fb8bfbb8..a2acd2b26baf 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -33,7 +33,7 @@ Optional properties:
 - max-frame-size: See ethernet.txt file in the same directory
 - clocks: If present, the first clock should be the GMAC main clock,
   further clocks may be specified in derived bindings.
-- clocks-names: One name for each entry in the clocks property, the
+- clock-names: One name for each entry in the clocks property, the
   first one should be "stmmaceth".
 
 Examples:
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
-        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".
+- compatible: should contain "snps,dw-pcie" to identify the core.
 - #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/host-generic-pci.txt b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
new file mode 100644
index 000000000000..f0b0436807b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
@@ -0,0 +1,100 @@
+* Generic PCI host controller
+
+Firmware-initialised PCI host controllers and PCI emulations, such as the
+virtio-pci implementations found in kvmtool and other para-virtualised
+systems, do not require driver support for complexities such as regulator
+and clock management. In fact, the controller may not even require the
+configuration of a control interface by the operating system, instead
+presenting a set of fixed windows describing a subset of IO, Memory and
+Configuration Spaces.
+
+Such a controller can be described purely in terms of the standardized device
+tree bindings communicated in pci.txt:
+
+
+Properties of the host controller node:
+
+- compatible     : Must be "pci-host-cam-generic" or "pci-host-ecam-generic"
+                   depending on the layout of configuration space (CAM vs
+                   ECAM respectively).
+
+- device_type    : Must be "pci".
+
+- ranges         : As described in IEEE Std 1275-1994, but must provide
+                   at least a definition of non-prefetchable memory. One
+                   or both of prefetchable Memory and IO Space may also
+                   be provided.
+
+- bus-range      : Optional property (also described in IEEE Std 1275-1994)
+                   to indicate the range of bus numbers for this controller.
+                   If absent, defaults to <0 255> (i.e. all buses).
+
+- #address-cells : Must be 3.
+
+- #size-cells    : Must be 2.
+
+- reg            : The Configuration Space base address and size, as accessed
+                   from the parent bus.
+
+
+Properties of the /chosen node:
+
+- linux,pci-probe-only
+                 : Optional property which takes a single-cell argument.
+                   If '0', then Linux will assign devices in its usual manner,
+                   otherwise it will not try to assign devices and instead use
+                   them as they are configured already.
+
+Configuration Space is assumed to be memory-mapped (as opposed to being
+accessed via an ioport) and laid out with a direct correspondence to the
+geography of a PCI bus address by concatenating the various components to
+form an offset.
+
+For CAM, this 24-bit offset is:
+
+        cfg_offset(bus, device, function, register) =
+                   bus << 16 | device << 11 | function << 8 | register
+
+Whilst ECAM extends this by 4 bits to accomodate 4k of function space:
+
+        cfg_offset(bus, device, function, register) =
+                   bus << 20 | device << 15 | function << 12 | register
+
+Interrupt mapping is exactly as described in `Open Firmware Recommended
+Practice: Interrupt Mapping' and requires the following properties:
+
+- #interrupt-cells   : Must be 1
+
+- interrupt-map      : <see aforementioned specification>
+
+- interrupt-map-mask : <see aforementioned specification>
+
+
+Example:
+
+pci {
+    compatible = "pci-host-cam-generic"
+    device_type = "pci";
+    #address-cells = <3>;
+    #size-cells = <2>;
+    bus-range = <0x0 0x1>;
+
+    // CPU_PHYSICAL(2)  SIZE(2)
+    reg = <0x0 0x40000000  0x0 0x1000000>;
+
+    // BUS_ADDRESS(3)  CPU_PHYSICAL(2)  SIZE(2)
+    ranges = <0x01000000 0x0 0x01000000  0x0 0x01000000  0x0 0x00010000>,
+             <0x02000000 0x0 0x41000000  0x0 0x41000000  0x0 0x3f000000>;
+
+
+    #interrupt-cells = <0x1>;
+
+    // PCI_DEVICE(3)  INT#(1)  CONTROLLER(PHANDLE)  CONTROLLER_DATA(3)
+    interrupt-map = <  0x0 0x0 0x0  0x1  &gic  0x0 0x4 0x1
+                     0x800 0x0 0x0  0x1  &gic  0x0 0x5 0x1
+                    0x1000 0x0 0x0  0x1  &gic  0x0 0x6 0x1
+                    0x1800 0x0 0x0  0x1  &gic  0x0 0x7 0x1>;
+
+    // PCI_DEVICE(3)  INT#(1)
+    interrupt-map-mask = <0xf800 0x0 0x0  0x7>;
+}
diff --git a/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
new file mode 100644
index 000000000000..d8ef5bf50f11
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci-rcar-gen2.txt
@@ -0,0 +1,66 @@
+Renesas AHB to PCI bridge
+-------------------------
+
+This is the bridge used internally to connect the USB controllers to the
+AHB. There is one bridge instance per USB port connected to the internal
+OHCI and EHCI controllers.
+
+Required properties:
+- compatible: "renesas,pci-r8a7790" for the R8A7790 SoC;
+              "renesas,pci-r8a7791" for the R8A7791 SoC.
+- reg:  A list of physical regions to access the device: the first is
+        the operational registers for the OHCI/EHCI controllers and the
+        second is for the bridge configuration and control registers.
+- interrupts: interrupt for the device.
+- clocks: The reference to the device clock.
+- bus-range: The PCI bus number range; as this is a single bus, the range
+             should be specified as the same value twice.
+- #address-cells: must be 3.
+- #size-cells: must be 2.
+- #interrupt-cells: must be 1.
+- interrupt-map: standard property used to define the mapping of the PCI
+  interrupts to the GIC interrupts.
+- interrupt-map-mask: standard property that helps to define the interrupt
+  mapping.
+
+Example SoC configuration:
+
+        pci0: pci@ee090000  {
+                compatible = "renesas,pci-r8a7790";
+                clocks = <&mstp7_clks R8A7790_CLK_EHCI>;
+                reg = <0x0 0xee090000 0x0 0xc00>,
+                      <0x0 0xee080000 0x0 0x1100>;
+                interrupts = <0 108 IRQ_TYPE_LEVEL_HIGH>;
+                status = "disabled";
+
+                bus-range = <0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0xff00 0 0 0x7>;
+                interrupt-map = <0x0000 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
+                                 0x0800 0 0 1 &gic 0 108 IRQ_TYPE_LEVEL_HIGH
+                                 0x1000 0 0 2 &gic 0 108 IRQ_TYPE_LEVEL_HIGH>;
+
+                pci@0,1 {
+                        reg = <0x800 0 0 0 0>;
+                        device_type = "pci";
+                        phys = <&usbphy 0 0>;
+                        phy-names = "usb";
+                };
+
+                pci@0,2 {
+                        reg = <0x1000 0 0 0 0>;
+                        device_type = "pci";
+                        phys = <&usbphy 0 0>;
+                        phy-names = "usb";
+                };
+        };
+
+Example board setup:
+
+&pci0 {
+        status = "okay";
+        pinctrl-0 = <&usb0_pins>;
+        pinctrl-names = "default";
+};
diff --git a/Documentation/devicetree/bindings/pci/rcar-pci.txt b/Documentation/devicetree/bindings/pci/rcar-pci.txt
new file mode 100644
index 000000000000..29d3b989d3b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/rcar-pci.txt
@@ -0,0 +1,47 @@
+* Renesas RCar PCIe interface
+
+Required properties:
+- compatible: should contain one of the following
+        "renesas,pcie-r8a7779", "renesas,pcie-r8a7790", "renesas,pcie-r8a7791"
+- reg: base address and length of the pcie controller registers.
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- bus-range: PCI bus numbers covered
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions.
+- dma-ranges: ranges for the inbound memory regions.
+- interrupts: two interrupt sources for MSI interrupts, followed by interrupt
+        source for hardware related interrupts (e.g. link speed change).
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+        to define the mapping of the PCIe interface to interrupt
+        numbers.
+- clocks: from common clock binding: clock specifiers for the PCIe controller
+        and PCIe bus clocks.
+- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+
+Example:
+
+SoC specific DT Entry:
+
+        pcie: pcie@fe000000 {
+                compatible = "renesas,pcie-r8a7791";
+                reg = <0 0xfe000000 0 0x80000>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                bus-range = <0x00 0xff>;
+                device_type = "pci";
+                ranges = <0x01000000 0 0x00000000 0 0xfe100000 0 0x00100000
+                          0x02000000 0 0xfe200000 0 0xfe200000 0 0x00200000
+                          0x02000000 0 0x30000000 0 0x30000000 0 0x08000000
+                          0x42000000 0 0x38000000 0 0x38000000 0 0x08000000>;
+                dma-ranges = <0x42000000 0 0x40000000 0 0x40000000 0 0x40000000
+                              0x42000000 2 0x00000000 2 0x00000000 0 0x40000000>;
+                interrupts = <0 116 4>, <0 117 4>, <0 118 4>;
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &gic 0 116 4>;
+                clocks = <&mstp3_clks R8A7791_CLK_PCIE>, <&pcie_bus_clk>;
+                clock-names = "pcie", "pcie_bus";
+                status = "disabled";
+        };
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/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index b422e38946d7..2049261d8c31 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -114,3 +114,50 @@ Example:
                 compatible = "samsung,exynos-sataphy-i2c";
                 reg = <0x38>;
         };
+
+Samsung Exynos5 SoC series USB DRD PHY controller
+--------------------------------------------------
+
+Required properties:
+- compatible : Should be set to one of the following supported values:
+        - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC,
+        - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC.
+- reg : Register offset and length of USB DRD PHY register set;
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+               Required clocks:
+        - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock),
+               used for register access.
+        - ref: PHY's reference clock (usually crystal clock), used for
+               PHY operations, associated by phy name. It is used to
+               determine bit values for clock settings register.
+               For Exynos5420 this is given as 'sclk_usbphy30' in CMU.
+- samsung,pmu-syscon: phandle for PMU system controller interface, used to
+                      control pmu registers for power isolation.
+- #phy-cells : from the generic PHY bindings, must be 1;
+
+For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy"
+compatible PHYs, the second cell in the PHY specifier identifies the
+PHY id, which is interpreted as follows:
+  0 - UTMI+ type phy,
+  1 - PIPE3 type phy,
+
+Example:
+        usbdrd_phy: usbphy@12100000 {
+                compatible = "samsung,exynos5250-usbdrd-phy";
+                reg = <0x12100000 0x100>;
+                clocks = <&clock 286>, <&clock 1>;
+                clock-names = "phy", "ref";
+                samsung,pmu-syscon = <&pmu_system_controller>;
+                #phy-cells = <1>;
+        };
+
+- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers,
+           'usbdrd_phy' nodes should have numbered alias in the aliases node,
+           in the form of usbdrdphyN, N = 0, 1... (depending on number of
+           controllers).
+Example:
+        aliases {
+                usbdrdphy0 = &usb3_phy0;
+                usbdrdphy1 = &usb3_phy1;
+        };
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
index a82361b62015..16528b9eb561 100644
--- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -2,15 +2,26 @@ Allwinner sun4i USB PHY
 -----------------------
 
 Required properties:
-- compatible : should be one of "allwinner,sun4i-a10-usb-phy",
-  "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy"
+- compatible : should be one of
+  * allwinner,sun4i-a10-usb-phy
+  * allwinner,sun5i-a13-usb-phy
+  * allwinner,sun6i-a31-usb-phy
+  * allwinner,sun7i-a20-usb-phy
 - reg : a list of offset + length pairs
-- reg-names : "phy_ctrl", "pmu1" and for sun4i or sun7i "pmu2"
+- reg-names :
+  * "phy_ctrl"
+  * "pmu1"
+  * "pmu2" for sun4i, sun6i or sun7i
 - #phy-cells : from the generic phy bindings, must be 1
-- clocks : phandle + clock specifier for the phy clock
-- clock-names : "usb_phy"
+- clocks : phandle + clock specifier for the phy clocks
+- clock-names :
+  * "usb_phy" for sun4i, sun5i or sun7i
+  * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i
 - resets : a list of phandle + reset specifier pairs
-- reset-names : "usb0_reset", "usb1_reset" and for sun4i or sun7i "usb2_reset"
+- reset-names :
+  * "usb0_reset"
+  * "usb1_reset"
+  * "usb2_reset" for sun4i, sun6i or sun7i
 
 Example:
         usbphy: phy@0x01c13400 {
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
index 788fb0fa3762..9ce458f32945 100644
--- a/Documentation/devicetree/bindings/phy/ti-phy.txt
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -32,6 +32,11 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - #phy-cells: determine the number of cells that should be given in the
    phandle while referencing this phy.
+ - clocks: a list of phandles and clock-specifier pairs, one for each entry in
+   clock-names.
+ - clock-names: should include:
+   * "wkupclk" - wakeup clock.
+   * "refclk" - reference clock (optional).
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -44,6 +49,8 @@ usb2phy@4a0ad080 {
         reg = <0x4a0ad080 0x58>;
         ctrl-module = <&omap_control_usb>;
         #phy-cells = <0>;
+        clocks = <&usb_phy_cm_clk32k>, <&usb_otg_ss_refclk960m>;
+        clock-names = "wkupclk", "refclk";
 };
 
 TI PIPE3 PHY
diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index dff0e5f995e2..d8d065608ec0 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -6,8 +6,13 @@ the first two functions being GPIO in and out. The configuration on
 the pins includes drive strength and pull-up.
 
 Required properties:
-- compatible: "allwinner,<soc>-pinctrl". Supported SoCs for now are:
-  sun5i-a13.
+- compatible: Should be one of the followings (depending on you SoC):
+  "allwinner,sun4i-a10-pinctrl"
+  "allwinner,sun5i-a10s-pinctrl"
+  "allwinner,sun5i-a13-pinctrl"
+  "allwinner,sun6i-a31-pinctrl"
+  "allwinner,sun6i-a31-r-pinctrl"
+  "allwinner,sun7i-a20-pinctrl"
 - reg: Should contain the register physical address and length for the
   pin controller.
 
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
index c119debe6bab..4eaae32821ae 100644
--- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt
@@ -73,9 +73,9 @@ Optional Properties (for standard pins):
                                 Otherwise:
                                         0: fast slew rate
                                         1: normal slew rate
-- input-enable:                 No arguements. Enable input (does not affect
+- input-enable:                 No arguments. Enable input (does not affect
                                 output.)
-- input-disable:                No arguements. Disable input (does not affect
+- input-disable:                No arguments. Disable input (does not affect
                                 output.)
 - drive-strength:               Integer. Drive strength in mA.  Valid values are
                                 2, 4, 6, 8, 10, 12, 14, 16 mA.
@@ -99,9 +99,9 @@ Optional Properties (for I2C pins):
                                 Otherwise:
                                         0: fast slew rate
                                         1: normal slew rate
-- input-enable:                 No arguements. Enable input (does not affect
+- input-enable:                 No arguments. Enable input (does not affect
                                 output.)
-- input-disable:                No arguements. Disable input (does not affect
+- input-disable:                No arguments. Disable input (does not affect
                                 output.)
 
 Optional Properties (for HDMI pins):
@@ -111,15 +111,15 @@ Optional Properties (for HDMI pins):
 - slew-rate:                    Integer. Controls slew rate.
                                         0: Standard(100kbps)& Fast(400kbps) mode
                                         1: Highspeed (3.4Mbps) mode
-- input-enable:                 No arguements. Enable input (does not affect
+- input-enable:                 No arguments. Enable input (does not affect
                                 output.)
-- input-disable:                No arguements. Disable input (does not affect
+- input-disable:                No arguments. Disable input (does not affect
                                 output.)
 
 Example:
 // pin controller node
 pinctrl@35004800 {
-        compatible = "brcmbcm11351-pinctrl";
+        compatible = "brcm,bcm11351-pinctrl";
         reg = <0x35004800 0x430>;
 
         // pin configuration node
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt
new file mode 100644
index 000000000000..b1b595220f1b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx6sx-pinctrl.txt
@@ -0,0 +1,36 @@
+* Freescale i.MX6 SoloX IOMUX Controller
+
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+
+Required properties:
+- compatible: "fsl,imx6sx-iomuxc"
+- fsl,pins: each entry consists of 6 integers and represents the mux and config
+  setting for one pin.  The first 5 integers <mux_reg conf_reg input_reg mux_val
+  input_val> are specified using a PIN_FUNC_ID macro, which can be found in
+  imx6sx-pinfunc.h under device tree source folder.  The last integer CONFIG is
+  the pad setting value like pull-up on this pin.  Please refer to i.MX6 SoloX
+  Reference Manual for detailed CONFIG settings.
+
+CONFIG bits definition:
+PAD_CTL_HYS                     (1 << 16)
+PAD_CTL_PUS_100K_DOWN           (0 << 14)
+PAD_CTL_PUS_47K_UP              (1 << 14)
+PAD_CTL_PUS_100K_UP             (2 << 14)
+PAD_CTL_PUS_22K_UP              (3 << 14)
+PAD_CTL_PUE                     (1 << 13)
+PAD_CTL_PKE                     (1 << 12)
+PAD_CTL_ODE                     (1 << 11)
+PAD_CTL_SPEED_LOW               (0 << 6)
+PAD_CTL_SPEED_MED               (1 << 6)
+PAD_CTL_SPEED_HIGH              (3 << 6)
+PAD_CTL_DSE_DISABLE             (0 << 3)
+PAD_CTL_DSE_260ohm              (1 << 3)
+PAD_CTL_DSE_130ohm              (2 << 3)
+PAD_CTL_DSE_87ohm               (3 << 3)
+PAD_CTL_DSE_65ohm               (4 << 3)
+PAD_CTL_DSE_52ohm               (5 << 3)
+PAD_CTL_DSE_43ohm               (6 << 3)
+PAD_CTL_DSE_37ohm               (7 << 3)
+PAD_CTL_SRE_FAST                (1 << 0)
+PAD_CTL_SRE_SLOW                (0 << 0)
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
new file mode 100644
index 000000000000..27570a3a1741
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,orion-pinctrl.txt
@@ -0,0 +1,91 @@
+* Marvell Orion SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: "marvell,88f5181l-pinctrl", "marvell,88f5182-pinctrl",
+              "marvell,88f5281-pinctrl"
+
+- reg: two register areas, the first one describing the first two
+  contiguous MPP registers, and the second one describing the single
+  final MPP register, separated from the previous one.
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+* Marvell Orion 88f5181l
+
+name          pins     functions
+================================================================================
+mpp0          0        pcie(rstout), pci(req2), gpio
+mpp1          1        gpio, pci(gnt2)
+mpp2          2        gpio, pci(req3), pci-1(pme)
+mpp3          3        gpio, pci(gnt3)
+mpp4          4        gpio, pci(req4)
+mpp5          5        gpio, pci(gnt4)
+mpp6          6        gpio, pci(req5), pci-1(clk)
+mpp7          7        gpio, pci(gnt5), pci-1(clk)
+mpp8          8        gpio, ge(col)
+mpp9          9        gpio, ge(rxerr)
+mpp10         10       gpio, ge(crs)
+mpp11         11       gpio, ge(txerr)
+mpp12         12       gpio, ge(txd4)
+mpp13         13       gpio, ge(txd5)
+mpp14         14       gpio, ge(txd6)
+mpp15         15       gpio, ge(txd7)
+mpp16         16       ge(rxd4)
+mpp17         17       ge(rxd5)
+mpp18         18       ge(rxd6)
+mpp19         19       ge(rxd7)
+
+* Marvell Orion 88f5182
+
+name          pins     functions
+================================================================================
+mpp0          0        pcie(rstout), pci(req2), gpio
+mpp1          1        gpio, pci(gnt2)
+mpp2          2        gpio, pci(req3), pci-1(pme)
+mpp3          3        gpio, pci(gnt3)
+mpp4          4        gpio, pci(req4), bootnand(re), sata0(prsnt)
+mpp5          5        gpio, pci(gnt4), bootnand(we), sata1(prsnt)
+mpp6          6        gpio, pci(req5), nand(re0), sata0(act)
+mpp7          7        gpio, pci(gnt5), nand(we0), sata1(act)
+mpp8          8        gpio, ge(col)
+mpp9          9        gpio, ge(rxerr)
+mpp10         10       gpio, ge(crs)
+mpp11         11       gpio, ge(txerr)
+mpp12         12       gpio, ge(txd4), nand(re1), sata0(ledprsnt)
+mpp13         13       gpio, ge(txd5), nand(we1), sata1(ledprsnt)
+mpp14         14       gpio, ge(txd6), nand(re2), sata0(ledact)
+mpp15         15       gpio, ge(txd7), nand(we2), sata1(ledact)
+mpp16         16       uart1(rxd), ge(rxd4), gpio
+mpp17         17       uart1(txd), ge(rxd5), gpio
+mpp18         18       uart1(cts), ge(rxd6), gpio
+mpp19         19       uart1(rts), ge(rxd7), gpio
+
+* Marvell Orion 88f5281
+
+name          pins     functions
+================================================================================
+mpp0          0        pcie(rstout), pci(req2), gpio
+mpp1          1        gpio, pci(gnt2)
+mpp2          2        gpio, pci(req3), pci(pme)
+mpp3          3        gpio, pci(gnt3)
+mpp4          4        gpio, pci(req4), bootnand(re)
+mpp5          5        gpio, pci(gnt4), bootnand(we)
+mpp6          6        gpio, pci(req5), nand(re0)
+mpp7          7        gpio, pci(gnt5), nand(we0)
+mpp8          8        gpio, ge(col)
+mpp9          9        gpio, ge(rxerr)
+mpp10         10       gpio, ge(crs)
+mpp11         11       gpio, ge(txerr)
+mpp12         12       gpio, ge(txd4), nand(re1)
+mpp13         13       gpio, ge(txd5), nand(we1)
+mpp14         14       gpio, ge(txd6), nand(re2)
+mpp15         15       gpio, ge(txd7), nand(we2)
+mpp16         16       uart1(rxd), ge(rxd4)
+mpp17         17       uart1(txd), ge(rxd5)
+mpp18         18       uart1(cts), ge(rxd6)
+mpp19         19       uart1(rts), ge(rxd7)
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index 4414163e76d2..fa40a177164c 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -156,6 +156,7 @@ input-disable		- disable input on pin (no effect on output)
 input-schmitt-enable    - enable schmitt-trigger mode
 input-schmitt-disable   - disable schmitt-trigger mode
 input-debounce          - debounce mode with debound time X
+power-source            - select between different power supplies
 low-power-enable        - enable low power mode
 low-power-disable       - disable low power mode
 output-low              - set the pin to output mode with low level
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
index 4bd5be0e5e7d..26bcb18f4e60 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
@@ -83,7 +83,7 @@ Example:
                 reg             = <0xfe61f080 0x4>;
                 reg-names       = "irqmux";
                 interrupts      = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
-                interrupts-names = "irqmux";
+                interrupt-names = "irqmux";
                 ranges          = <0 0xfe610000 0x5000>;
 
                 PIO0: gpio@fe610000 {
@@ -165,7 +165,7 @@ sdhci0:sdhci@fe810000{
         interrupt-parent = <&PIO3>;
         #interrupt-cells = <2>;
         interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; /* Interrupt line via PIO3-3 */
-        interrupts-names = "card-detect";
+        interrupt-names = "card-detect";
         pinctrl-names = "default";
         pinctrl-0       = <&pinctrl_mmc>;
 };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
new file mode 100644
index 000000000000..7181f925acaa
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8064-pinctrl.txt
@@ -0,0 +1,88 @@
+Qualcomm APQ8064 TLMM block
+
+Required properties:
+- compatible: "qcom,apq8064-pinctrl"
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+                The first cell is the gpio pin number and the
+                second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Qualcomm's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+ pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+
+Valid values for pins are:
+  gpio0-gpio89
+
+Valid values for function are:
+  cam_mclk, codec_mic_i2s, codec_spkr_i2s, gsbi1, gsbi2, gsbi3, gsbi4,
+  gsbi4_cam_i2c, gsbi5, gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6,
+  gsbi6_spi_cs1, gsbi6_spi_cs2, gsbi6_spi_cs3, gsbi7, gsbi7_spi_cs1,
+  gsbi7_spi_cs2, gsbi7_spi_cs3, gsbi_cam_i2c, hdmi, mi2s, riva_bt, riva_fm,
+  riva_wlan, sdc2, sdc4, slimbus, spkr_i2s, tsif1, tsif2, usb2_hsic,
+
+Example:
+
+        msmgpio: pinctrl@800000 {
+                compatible = "qcom,apq8064-pinctrl";
+                reg = <0x800000 0x4000>;
+
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                interrupts = <0 32 0x4>;
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&gsbi5_uart_default>;
+
+                gsbi5_uart_default: gsbi5_uart_default {
+                        mux {
+                                pins = "gpio51", "gpio52";
+                                function = "gsbi5";
+                        };
+
+                        tx {
+                                pins = "gpio51";
+                                drive-strength = <4>;
+                                bias-disable;
+                        };
+
+                        rx {
+                                pins = "gpio52";
+                                drive-strength = <2>;
+                                bias-pull-up;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
new file mode 100644
index 000000000000..e0d35a40981b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,ipq8064-pinctrl.txt
@@ -0,0 +1,95 @@
+Qualcomm IPQ8064 TLMM block
+
+Required properties:
+- compatible: "qcom,ipq8064-pinctrl"
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+                The first cell is the gpio pin number and the
+                second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase "pin configuration node".
+
+Qualcomm's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+ pins, function, bias-disable, bias-pull-down, bias-pull,up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+
+Valid values for qcom,pins are:
+  gpio0-gpio68
+   Supports mux, bias, and drive-strength
+
+  sdc3_clk, sdc3_cmd, sdc3_data
+   Supports bias and drive-strength
+
+
+Valid values for function are:
+  mdio, mi2s, pdm, ssbi, spmi, audio_pcm, gsbi1, gsbi2, gsbi4, gsbi5,
+  gsbi5_spi_cs1, gsbi5_spi_cs2, gsbi5_spi_cs3, gsbi6, gsbi7, nss_spi, sdc1,
+  spdif, nand, tsif1, tsif2, usb_fs_n, usb_fs, usb2_hsic, rgmii2, sata,
+  pcie1_rst, pcie1_prsnt, pcie1_pwren_n, pcie1_pwren, pcie1_pwrflt,
+  pcie1_clk_req, pcie2_rst, pcie2_prsnt, pcie2_pwren_n, pcie2_pwren,
+  pcie2_pwrflt, pcie2_clk_req, pcie3_rst, pcie3_prsnt, pcie3_pwren_n,
+  pcie3_pwren, pcie3_pwrflt, pcie3_clk_req, ps_hold
+
+Example:
+
+        pinmux: pinctrl@800000 {
+                compatible = "qcom,ipq8064-pinctrl";
+                reg = <0x800000 0x4000>;
+
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                interrupts = <0 32 0x4>;
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&gsbi5_uart_default>;
+
+                gsbi5_uart_default: gsbi5_uart_default {
+                        mux {
+                                pins = "gpio18", "gpio19";
+                                function = "gsbi5";
+                        };
+
+                        tx {
+                                pins = "gpio18";
+                                drive-strength = <4>;
+                                bias-disable;
+                        };
+
+                        rx {
+                                pins = "gpio19";
+                                drive-strength = <2>;
+                                bias-pull-up;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
index 9fb89e3f61ea..73262b575dfc 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
@@ -50,7 +50,27 @@ Valid values for pins are:
     Supports bias and drive-strength
 
 Valid values for function are:
-  blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus
+  cci_i2c0, cci_i2c1, uim1, uim2, uim_batt_alarm,
+  blsp_uim1, blsp_uart1, blsp_i2c1, blsp_spi1,
+  blsp_uim2, blsp_uart2, blsp_i2c2, blsp_spi2,
+  blsp_uim3, blsp_uart3, blsp_i2c3, blsp_spi3,
+  blsp_uim4, blsp_uart4, blsp_i2c4, blsp_spi4,
+  blsp_uim5, blsp_uart5, blsp_i2c5, blsp_spi5,
+  blsp_uim6, blsp_uart6, blsp_i2c6, blsp_spi6,
+  blsp_uim7, blsp_uart7, blsp_i2c7, blsp_spi7,
+  blsp_uim8, blsp_uart8, blsp_i2c8, blsp_spi8,
+  blsp_uim9, blsp_uart9, blsp_i2c9, blsp_spi9,
+  blsp_uim10, blsp_uart10, blsp_i2c10, blsp_spi10,
+  blsp_uim11, blsp_uart11, blsp_i2c11, blsp_spi11,
+  blsp_uim12, blsp_uart12, blsp_i2c12, blsp_spi12,
+  blsp_spi1_cs1, blsp_spi2_cs2, blsp_spi_cs3, blsp_spi2_cs1, blsp_spi2_cs2
+  blsp_spi2_cs3, blsp_spi10_cs1, blsp_spi10_cs2, blsp_spi10_cs3,
+  sdc3, sdc4, gcc_gp_clk1, gcc_gp_clk2, gcc_gp_clk3, cci_timer0, cci_timer1,
+  cci_timer2, cci_timer3, cci_async_in0, cci_async_in1, cci_async_in2,
+  cam_mckl0, cam_mclk1, cam_mclk2, cam_mclk3, mdp_vsync, hdmi_cec, hdmi_ddc,
+  hdmi_hpd, edp_hpd, gp_pdm0, gp_pdm1, gp_pdm2, gp_pdm3, gp0_clk, gp1_clk,
+  gp_mn, tsif1, tsif2, hsic, grfc, audio_ref_clk, qua_mi2s, pri_mi2s, spkr_mi2s,
+  ter_mi2s, sec_mi2s, bt, fm, wlan, slimbus
 
   (Note that this is not yet the complete list of functions)
 
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index f378d342aae4..cefef741a40b 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -21,13 +21,23 @@ defined as gpio sub-nodes of the pinmux controller.
 Required properties for iomux controller:
   - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
                        "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
+  - rockchip,grf: phandle referencing a syscon providing the
+         "general register files"
+
+Optional properties for iomux controller:
+  - rockchip,pmu: phandle referencing a syscon providing the pmu registers
+         as some SoCs carry parts of the iomux controller registers there.
+         Required for at least rk3188 and rk3288.
+
+Deprecated properties for iomux controller:
   - reg: first element is the general register space of the iomux controller
-         second element is the separate pull register space of the rk3188
+         It should be large enough to contain also separate pull registers.
+         second element is the separate pull register space of the rk3188.
+         Use rockchip,grf and rockchip,pmu described above instead.
 
 Required properties for gpio sub nodes:
   - compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0"
   - reg: register of the gpio bank (different than the iomux registerset)
-         second element: separate pull register for rk3188 bank0
   - interrupts: base interrupt of the gpio bank in the interrupt controller
   - clocks: clock that drives this bank
   - gpio-controller: identifies the node as a gpio controller and pin bank.
@@ -39,6 +49,10 @@ Required properties for gpio sub nodes:
     cells should use the standard two-cell scheme described in
     bindings/interrupt-controller/interrupts.txt
 
+Deprecated properties for gpio sub nodes:
+  - reg: second element: separate pull register for rk3188 bank0, use
+         rockchip,pmu described above instead
+
 Required properties for pin configuration node:
   - rockchip,pins: 3 integers array, represents a group of pins mux and config
     setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>.
@@ -54,7 +68,8 @@ Examples:
 
 pinctrl@20008000 {
         compatible = "rockchip,rk3066a-pinctrl";
-        reg = <0x20008000 0x150>;
+        rockchip,grf = <&grf>;
+
         #address-cells = <1>;
         #size-cells = <1>;
         ranges;
@@ -103,16 +118,15 @@ Example for rk3188:
 
         pinctrl@20008000 {
                 compatible = "rockchip,rk3188-pinctrl";
-                reg = <0x20008000 0xa0>,
-                      <0x20008164 0x1a0>;
+                rockchip,grf = <&grf>;
+                rockchip,pmu = <&pmu>;
                 #address-cells = <1>;
                 #size-cells = <1>;
                 ranges;
 
                 gpio0: gpio0@0x2000a000 {
                         compatible = "rockchip,rk3188-gpio-bank0";
-                        reg = <0x2000a000 0x100>,
-                              <0x20004064 0x8>;
+                        reg = <0x2000a000 0x100>;
                         interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
                         clocks = <&clk_gates8 9>;
 
diff --git a/Documentation/devicetree/bindings/power/reset/keystone-reset.txt b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
new file mode 100644
index 000000000000..c82f12e2d85c
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/keystone-reset.txt
@@ -0,0 +1,67 @@
+* Device tree bindings for Texas Instruments keystone reset
+
+This node is intended to allow SoC reset in case of software reset
+of selected watchdogs.
+
+The Keystone SoCs can contain up to 4 watchdog timers to reset
+SoC. Each watchdog timer event input is connected to the Reset Mux
+block. The Reset Mux block can be configured to cause reset or not.
+
+Additionally soft or hard reset can be configured.
+
+Required properties:
+
+- compatible:           ti,keystone-reset
+
+- ti,syscon-pll:        phandle/offset pair. The phandle to syscon used to
+                        access pll controller registers and the offset to use
+                        reset control registers.
+
+- ti,syscon-dev:        phandle/offset pair. The phandle to syscon used to
+                        access device state control registers and the offset
+                        in order to use mux block registers for all watchdogs.
+
+Optional properties:
+
+- ti,soft-reset:        Boolean option indicating soft reset.
+                        By default hard reset is used.
+
+- ti,wdt-list:          WDT list that can cause SoC reset. It's not related
+                        to WDT driver, it's just needed to enable a SoC related
+                        reset that's triggered by one of WDTs. The list is
+                        in format: <0>, <2>; It can be in random order and
+                        begins from 0 to 3, as keystone can contain up to 4 SoC
+                        reset watchdogs and can be in random order.
+
+Example 1:
+Setup keystone reset so that in case software reset or
+WDT0 is triggered it issues hard reset for SoC.
+
+pllctrl: pll-controller@02310000 {
+        compatible = "ti,keystone-pllctrl", "syscon";
+        reg = <0x02310000 0x200>;
+};
+
+devctrl: device-state-control@02620000 {
+        compatible = "ti,keystone-devctrl", "syscon";
+        reg = <0x02620000 0x1000>;
+};
+
+rstctrl: reset-controller {
+        compatible = "ti,keystone-reset";
+        ti,syscon-pll = <&pllctrl 0xe4>;
+        ti,syscon-dev = <&devctrl 0x328>;
+        ti,wdt-list = <0>;
+};
+
+Example 2:
+Setup keystone reset so that in case of software reset or
+WDT0 or WDT2 is triggered it issues soft reset for SoC.
+
+rstctrl: reset-controller {
+        compatible = "ti,keystone-reset";
+        ti,syscon-pll = <&pllctrl 0xe4>;
+        ti,syscon-dev = <&devctrl 0x328>;
+        ti,wdt-list = <0>, <2>;
+        ti,soft-reset;
+};
diff --git a/Documentation/devicetree/bindings/power_supply/axxia-reset.txt b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt
new file mode 100644
index 000000000000..47e720d249d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt
@@ -0,0 +1,20 @@
+Axxia Restart Driver
+
+This driver can do reset of the Axxia SoC. It uses the registers in the syscon
+block to initiate a chip reset.
+
+Required Properties:
+  -compatible: "lsi,axm55xx-reset"
+  -syscon: phandle to the syscon node.
+
+Example:
+
+        syscon: syscon@2010030000 {
+                compatible = "lsi,axxia-syscon", "syscon";
+                reg = <0x20 0x10030000 0 0x2000>;
+        };
+
+        reset: reset@2010031000 {
+                compatible = "lsi,axm55xx-reset";
+                syscon = <&syscon>;
+        };
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/4xx/reboot.txt b/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt
index d7217260589c..5bc63551319e 100644
--- a/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt
+++ b/Documentation/devicetree/bindings/powerpc/4xx/reboot.txt
@@ -1,7 +1,7 @@
 Reboot property to control system reboot on PPC4xx systems:
 
 By setting "reset_type" to one of the following values, the default
-software reset mechanism may be overidden. Here the possible values of
+software reset mechanism may be overridden. Here the possible values of
 "reset_type":
 
       1 - PPC4xx core reset
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/dcsr.txt b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
index 9d54eb5a295f..18a88100af94 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dcsr.txt
@@ -82,7 +82,7 @@ PROPERTIES
         Which event source asserted the interrupt is captured in an EPU
         Interrupt Status Register (EPISR0,EPISR1).
 
-        Interrupt numbers are lised in order (perfmon, event0, event1).
+        Interrupt numbers are listed in order (perfmon, event0, event1).
 
         - interrupt-parent
         Usage: required
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/regulator/ltc3589.txt b/Documentation/devicetree/bindings/regulator/ltc3589.txt
new file mode 100644
index 000000000000..801053036146
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ltc3589.txt
@@ -0,0 +1,99 @@
+Linear Technology LTC3589, LTC3589-1, and LTC3589-2 8-output regulators
+
+Required properties:
+- compatible: "lltc,ltc3589", "lltc,ltc3589-1" or "lltc,ltc3589-2"
+- reg: I2C slave address
+
+Required child node:
+- regulators: Contains eight regulator child nodes sw1, sw2, sw3, bb-out,
+  ldo1, ldo2, ldo3, and ldo4, specifying the initialization data as
+  documented in Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Each regulator is defined using the standard binding for regulators. The
+nodes for sw1, sw2, sw3, bb-out, ldo1, and ldo2 additionally need to specify
+the resistor values of their external feedback voltage dividers:
+
+Required properties (not on ldo3, ldo4):
+- lltc,fb-voltage-divider: An array of two integers containing the resistor
+  values R1 and R2 of the feedback voltage divider in ohms.
+
+Regulators sw1, sw2, sw3, and ldo2 can regulate the feedback reference from
+0.3625 V to 0.75 V in 12.5 mV steps. The output voltage thus ranges between
+0.3625 * (1 + R1/R2) V and 0.75 * (1 + R1/R2) V. Regulators bb-out and ldo1
+have a fixed 0.8 V reference and thus output 0.8 * (1 + R1/R2) V. The ldo3
+regulator is fixed to 1.8 V on LTC3589 and to 2.8 V on LTC3589-1,2. The ldo4
+regulator can output between 1.8 V and 3.3 V on LTC3589 and between 1.2 V
+and 3.2 V on LTC3589-1,2 in four steps. The ldo1 standby regulator can not
+be disabled and thus should have the regulator-always-on property set.
+
+Example:
+
+        ltc3589: pmic@34 {
+                compatible = "lltc,ltc3589-1";
+                reg = <0x34>;
+
+                regulators {
+                        sw1_reg: sw1 {
+                                regulator-min-microvolt = <591930>;
+                                regulator-max-microvolt = <1224671>;
+                                lltc,fb-voltage-divider = <100000 158000>;
+                                regulator-ramp-delay = <7000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        sw2_reg: sw2 {
+                                regulator-min-microvolt = <704123>;
+                                regulator-max-microvolt = <1456803>;
+                                lltc,fb-voltage-divider = <180000 191000>;
+                                regulator-ramp-delay = <7000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        sw3_reg: sw3 {
+                                regulator-min-microvolt = <1341250>;
+                                regulator-max-microvolt = <2775000>;
+                                lltc,fb-voltage-divider = <270000 100000>;
+                                regulator-ramp-delay = <7000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        bb_out_reg: bb-out {
+                                regulator-min-microvolt = <3387341>;
+                                regulator-max-microvolt = <3387341>;
+                                lltc,fb-voltage-divider = <511000 158000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        ldo1_reg: ldo1 {
+                                regulator-min-microvolt = <1306329>;
+                                regulator-max-microvolt = <1306329>;
+                                lltc,fb-voltage-divider = <100000 158000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        ldo2_reg: ldo2 {
+                                regulator-min-microvolt = <704123>;
+                                regulator-max-microvolt = <1456806>;
+                                lltc,fb-voltage-divider = <180000 191000>;
+                                regulator-ramp-delay = <7000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        ldo3_reg: ldo3 {
+                                regulator-min-microvolt = <2800000>;
+                                regulator-max-microvolt = <2800000>;
+                                regulator-boot-on;
+                        };
+
+                        ldo4_reg: ldo4 {
+                                regulator-min-microvolt = <1200000>;
+                                regulator-max-microvolt = <3200000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index e2c7f1e7251a..86074334e342 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -12,7 +12,7 @@ Optional properties:
 - regulator-allow-bypass: allow the regulator to go into bypass mode
 - <name>-supply: phandle to the parent supply/regulator node
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
-  For hardwares which support disabling ramp rate, it should be explicitly
+  For hardware which supports disabling ramp rate, it should be explicitly
   intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
 - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply
   rail to reach the target voltage, plus/minus whatever tolerance the board
diff --git a/Documentation/devicetree/bindings/regulator/tps65090.txt b/Documentation/devicetree/bindings/regulator/tps65090.txt
index 313a60ba61d8..340980239ea9 100644
--- a/Documentation/devicetree/bindings/regulator/tps65090.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65090.txt
@@ -21,6 +21,10 @@ Optional properties:
   number should be provided. If it is externally controlled and no GPIO
   entry then driver will just configure this rails as external control
   and will not provide any enable/disable APIs.
+- ti,overcurrent-wait: This is applicable to FET registers, which have a
+  poorly defined "overcurrent wait" field.  If this property is present it
+  should be between 0 - 3.  If this property isn't present we won't touch the
+  "overcurrent wait" field and we'll leave it to the BIOS/EC to deal with.
 
 Each regulator is defined using the standard binding for regulators.
 
diff --git a/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt
new file mode 100644
index 000000000000..c8f775714887
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/allwinner,sunxi-clock-reset.txt
@@ -0,0 +1,21 @@
+Allwinner sunxi Peripheral Reset Controller
+===========================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be one of the following:
+  "allwinner,sun6i-a31-ahb1-reset"
+  "allwinner,sun6i-a31-clock-reset"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+example:
+
+ahb1_rst: reset@01c202c0 {
+        #reset-cells = <1>;
+        compatible = "allwinner,sun6i-a31-ahb1-reset";
+        reg = <0x01c202c0 0xc>;
+};
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt b/Documentation/devicetree/bindings/reset/socfpga-reset.txt
index ecdb57d69dbf..32c1c8bfd5dc 100644
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt
+++ b/Documentation/devicetree/bindings/reset/socfpga-reset.txt
@@ -3,9 +3,11 @@ Altera SOCFPGA Reset Manager
 Required properties:
 - compatible : "altr,rst-mgr"
 - reg : Should contain 1 register ranges(address and length)
+- #reset-cells: 1
 
 Example:
          rstmgr@ffd05000 {
+                #reset-cells = <1>;
                 compatible = "altr,rst-mgr";
                 reg = <0xffd05000 0x1000>;
         };
diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
index 31406fd4a43e..5c199ee044cb 100644
--- a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
+++ b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
@@ -9,6 +9,9 @@ Required properties:
 - interrupts: rtc alarm/event interrupt
 - #clock-cells: the value should be 0
 
+Optional properties:
+- clock-output-names: From common clock binding
+
 Example:
 
 hym8563: hym8563@51 {
diff --git a/Documentation/devicetree/bindings/rtc/xgene-rtc.txt b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt
new file mode 100644
index 000000000000..fd195c358446
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/xgene-rtc.txt
@@ -0,0 +1,28 @@
+* APM X-Gene Real Time Clock
+
+RTC controller for the APM X-Gene Real Time Clock
+
+Required properties:
+- compatible : Should be "apm,xgene-rtc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: IRQ line for the RTC.
+- #clock-cells: Should be 1.
+- clocks: Reference to the clock entry.
+
+Example:
+
+rtcclk: rtcclk {
+        compatible = "fixed-clock";
+        #clock-cells = <1>;
+        clock-frequency = <100000000>;
+        clock-output-names = "rtcclk";
+};
+
+rtc: rtc@10510000 {
+        compatible = "apm,xgene-rtc";
+        reg = <0x0 0x10510000 0x0 0x400>;
+        interrupts = <0x0 0x46 0x4>;
+        #clock-cells = <1>;
+        clocks = <&rtcclk 0>;
+};
diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt
index 17c1042b2df8..a6391e70a8fd 100644
--- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt
@@ -13,8 +13,9 @@ Required properties:
 Optional properties:
 - atmel,use-dma-rx: use of PDC or DMA for receiving data
 - atmel,use-dma-tx: use of PDC or DMA for transmitting data
-- rts-gpios: specify a GPIO for RTS line. It will use specified PIO instead of the peripheral
-  function pin for the USART RTS feature. If unsure, don't specify this property.
+- {rts,cts,dtr,dsr,rng,dcd}-gpios: specify a GPIO for RTS/CTS/DTR/DSR/RI/DCD line respectively.
+  It will use specified PIO instead of the peripheral function pin for the USART feature.
+  If unsure, don't specify this property.
 - add dma bindings for dma transfer:
         - dmas: DMA specifier, consisting of a phandle to DMA controller node,
                 memory peripheral interface and USART DMA channel ID, FIFO configuration.
@@ -35,7 +36,12 @@ Example:
                 clock-names = "usart";
                 atmel,use-dma-rx;
                 atmel,use-dma-tx;
-                rts-gpios = <&pioD 15 0>;
+                rts-gpios = <&pioD 15 GPIO_ACTIVE_LOW>;
+                cts-gpios = <&pioD 16 GPIO_ACTIVE_LOW>;
+                dtr-gpios = <&pioD 17 GPIO_ACTIVE_LOW>;
+                dsr-gpios = <&pioD 18 GPIO_ACTIVE_LOW>;
+                dcd-gpios = <&pioD 20 GPIO_ACTIVE_LOW>;
+                rng-gpios = <&pioD 19 GPIO_ACTIVE_LOW>;
         };
 
 - use DMA:
diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt
index 1984bdfbd545..3ca01336b837 100644
--- a/Documentation/devicetree/bindings/serial/efm32-uart.txt
+++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt
@@ -1,7 +1,7 @@
 * Energymicro efm32 UART
 
 Required properties:
-- compatible : Should be "efm32,uart"
+- compatible : Should be "energymicro,efm32-uart"
 - reg : Address and length of the register set
 - interrupts : Should contain uart interrupt
 
@@ -13,7 +13,7 @@ Optional properties:
 Example:
 
 uart@0x4000c400 {
-        compatible = "efm32,uart";
+        compatible = "energymicro,efm32-uart";
         reg = <0x4000c400 0x400>;
         interrupts = <15>;
         efm32,location = <0>;
diff --git a/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
new file mode 100644
index 000000000000..246c795668dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/nxp,sc16is7xx.txt
@@ -0,0 +1,33 @@
+* NXP SC16IS7xx advanced Universal Asynchronous Receiver-Transmitter (UART)
+
+Required properties:
+- compatible: Should be one of the following:
+  - "nxp,sc16is740" for NXP SC16IS740,
+  - "nxp,sc16is741" for NXP SC16IS741,
+  - "nxp,sc16is750" for NXP SC16IS750,
+  - "nxp,sc16is752" for NXP SC16IS752,
+  - "nxp,sc16is760" for NXP SC16IS760,
+  - "nxp,sc16is762" for NXP SC16IS762.
+- reg: I2C address of the SC16IS7xx device.
+- interrupt-parent: The phandle for the interrupt controller that
+  services interrupts for this IC.
+- interrupts: Should contain the UART interrupt
+- clocks: Reference to the IC source clock.
+
+Optional properties:
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the GPIO number and
+  the second cell is used to specify the GPIO polarity:
+    0 = active high,
+    1 = active low.
+
+Example:
+        sc16is750: sc16is750@51 {
+                compatible = "nxp,sc16is750";
+                reg = <0x51>;
+                clocks = <&clk20m>;
+                interrupt-parent = <&gpio3>;
+                interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/serial/of-serial.txt b/Documentation/devicetree/bindings/serial/of-serial.txt
index 1928a3e83cd0..77054772a8f4 100644
--- a/Documentation/devicetree/bindings/serial/of-serial.txt
+++ b/Documentation/devicetree/bindings/serial/of-serial.txt
@@ -37,6 +37,7 @@ Optional properties:
 - auto-flow-control: one way to enable automatic flow control support. The
   driver is allowed to detect support for the capability even without this
   property.
+- has-hw-flow-control: the hardware has flow control capability.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index 53e6c175db6c..64fd7dec1bbc 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -4,6 +4,7 @@ Required properties:
 
   - compatible: Must contain one of the following:
 
+    - "renesas,scif-r8a7779" for R8A7779 (R-Car H1) SCIF compatible UART.
     - "renesas,scif-r8a7790" for R8A7790 (R-Car H2) SCIF compatible UART.
     - "renesas,scifa-r8a7790" for R8A7790 (R-Car H2) SCIFA compatible UART.
     - "renesas,scifb-r8a7790" for R8A7790 (R-Car H2) SCIFB compatible UART.
diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
new file mode 100644
index 000000000000..4ce24d425bf1
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,gsbi.txt
@@ -0,0 +1,78 @@
+QCOM GSBI (General Serial Bus Interface) Driver
+
+The GSBI controller is modeled as a node with zero or more child nodes, each
+representing a serial sub-node device that is mux'd as part of the GSBI
+configuration settings.  The mode setting will govern the input/output mode of
+the 4 GSBI IOs.
+
+Required properties:
+- compatible: must contain "qcom,gsbi-v1.0.0" for APQ8064/IPQ8064
+- reg: Address range for GSBI registers
+- clocks: required clock
+- clock-names: must contain "iface" entry
+- qcom,mode : indicates MUX value for configuration of the serial interface.
+  Please reference dt-bindings/soc/qcom,gsbi.h for valid mux values.
+
+Optional properties:
+- qcom,crci : indicates CRCI MUX value for QUP CRCI ports.  Please reference
+  dt-bindings/soc/qcom,gsbi.h for valid CRCI mux values.
+
+Required properties if child node exists:
+- #address-cells: Must be 1
+- #size-cells: Must be 1
+- ranges: Must be present
+
+Properties for children:
+
+A GSBI controller node can contain 0 or more child nodes representing serial
+devices.  These serial devices can be a QCOM UART, I2C controller, spi
+controller, or some combination of aforementioned devices.
+
+See the following for child node definitions:
+Documentation/devicetree/bindings/i2c/qcom,i2c-qup.txt
+Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
+Documentation/devicetree/bindings/serial/qcom,msm-uartdm.txt
+
+Example for APQ8064:
+
+#include <dt-bindings/soc/qcom,gsbi.h>
+
+        gsbi4@16300000 {
+                compatible = "qcom,gsbi-v1.0.0";
+                reg = <0x16300000 0x100>;
+                clocks = <&gcc GSBI4_H_CLK>;
+                clock-names = "iface";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+                qcom,mode = <GSBI_PROT_I2C_UART>;
+                qcom,crci = <GSBI_CRCI_QUP>;
+
+                /* child nodes go under here */
+
+                i2c_qup4: i2c@16380000 {
+                        compatible = "qcom,i2c-qup-v1.1.1";
+                        reg = <0x16380000 0x1000>;
+                        interrupts = <0 153 0>;
+
+                        clocks = <&gcc GSBI4_QUP_CLK>, <&gcc GSBI4_H_CLK>;
+                        clock-names = "core", "iface";
+
+                        clock-frequency = <200000>;
+
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                 };
+
+                uart4:  serial@16340000 {
+                        compatible = "qcom,msm-uartdm-v1.3", "qcom,msm-uartdm";
+                        reg = <0x16340000 0x1000>,
+                                <0x16300000 0x1000>;
+                        interrupts = <0 152 0x0>;
+                        clocks = <&gcc GSBI4_UART_CLK>, <&gcc GSBI4_H_CLK>;
+                        clock-names = "core", "iface";
+                        status = "ok";
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/sound/ak4104.txt b/Documentation/devicetree/bindings/sound/ak4104.txt
index b902ee39cf89..deca5e18f304 100644
--- a/Documentation/devicetree/bindings/sound/ak4104.txt
+++ b/Documentation/devicetree/bindings/sound/ak4104.txt
@@ -8,6 +8,8 @@ Required properties:
 
   - reg : The chip select number on the SPI bus
 
+  - vdd-supply : A regulator node, providing 2.7V - 3.6V
+
 Optional properties:
 
   - reset-gpio : a GPIO spec for the reset pin. If specified, it will be
@@ -19,4 +21,5 @@ spdif: ak4104@0 {
         compatible = "asahi-kasei,ak4104";
         reg = <0>;
         spi-max-frequency = <5000000>;
+        vdd-supply = <&vdd_3v3_reg>;
 };
diff --git a/Documentation/devicetree/bindings/sound/alc5623.txt b/Documentation/devicetree/bindings/sound/alc5623.txt
new file mode 100644
index 000000000000..26c86c98d671
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/alc5623.txt
@@ -0,0 +1,25 @@
+ALC5621/ALC5622/ALC5623 audio Codec
+
+Required properties:
+
+ - compatible:  "realtek,alc5623"
+ - reg:         the I2C address of the device.
+
+Optional properties:
+
+ - add-ctrl:      Default register value for Reg-40h, Additional Control
+                  Register. If absent or has the value of 0, the
+                  register is untouched.
+
+ - jack-det-ctrl: Default register value for Reg-5Ah, Jack Detect
+                  Control Register. If absent or has value 0, the
+                  register is untouched.
+
+Example:
+
+        alc5621: alc5621@1a {
+                compatible = "alc5621";
+                reg = <0x1a>;
+                add-ctrl = <0x3700>;
+                jack-det-ctrl = <0x4810>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/cs42l56.txt b/Documentation/devicetree/bindings/sound/cs42l56.txt
new file mode 100644
index 000000000000..4feb0eb27ea4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs42l56.txt
@@ -0,0 +1,63 @@
+CS42L52 audio CODEC
+
+Required properties:
+
+  - compatible : "cirrus,cs42l56"
+
+  - reg : the I2C address of the device for I2C
+
+  - VA-supply, VCP-supply, VLDO-supply : power supplies for the device,
+  as covered in Documentation/devicetree/bindings/regulator/regulator.txt.
+
+Optional properties:
+
+  - cirrus,gpio-nreset : GPIO controller's phandle and the number
+  of the GPIO used to reset the codec.
+
+  - cirrus,chgfreq-divisor : Values used to set the Charge Pump Frequency.
+  Allowable values of 0x00 through 0x0F. These are raw values written to the
+  register, not the actual frequency. The frequency is determined by the following.
+  Frequency = MCLK / 4 * (N+2)
+  N = chgfreq_val
+  MCLK = Where MCLK is the frequency of the mclk signal after the MCLKDIV2 circuit.
+
+  - cirrus,ain1a-ref-cfg, ain1b-ref-cfg : boolean, If present, AIN1A or AIN1B are configured
+  as a pseudo-differential input referenced to AIN1REF/AIN3A.
+
+  - cirrus,ain2a-ref-cfg, ain2b-ref-cfg : boolean, If present, AIN2A or AIN2B are configured
+  as a pseudo-differential input referenced to AIN2REF/AIN3B.
+
+  - cirrus,micbias-lvl: Set the output voltage level on the MICBIAS Pin.
+  0 = 0.5 x VA
+  1 = 0.6 x VA
+  2 = 0.7 x VA
+  3 = 0.8 x VA
+  4 = 0.83 x VA
+  5 = 0.91 x VA
+
+  - cirrus,adaptive-pwr-cfg : Configures how the power to the Headphone and Lineout
+  Amplifiers adapt to the output signal levels.
+  0 = Adapt to Volume Mode. Voltage level determined by the sum of the relevant volume settings.
+  1 = Fixed - Headphone and Line Amp supply = + or - VCP/2.
+  2 = Fixed - Headphone and Line Amp supply = + or - VCP.
+  3 = Adapted to Signal; Voltage level is dynamically determined by the output signal.
+
+  - cirrus,hpf-left-freq, hpf-right-freq : Sets the corner frequency (-3dB point) for the internal High-Pass
+  Filter.
+  0 = 1.8Hz
+  1 = 119Hz
+  2 = 236Hz
+  3 = 464Hz
+
+
+Example:
+
+codec: codec@4b {
+        compatible = "cirrus,cs42l56";
+        reg = <0x4b>;
+        gpio-reset = <&gpio 10 0>;
+        cirrus,chgfreq-divisor = <0x05>;
+        cirrus.ain1_ref_cfg;
+        cirrus,micbias-lvl = <5>;
+        VA-supply = <&reg_audio>;
+};
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 569b26c4a81e..60ca07996458 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -47,7 +47,7 @@ mcasp0: mcasp0@1d00000 {
         reg = <0x100000 0x3000>;
         reg-names "mpu";
         interrupts = <82>, <83>;
-        interrupts-names = "tx", "rx";
+        interrupt-names = "tx", "rx";
         op-mode = <0>;          /* MCASP_IIS_MODE */
         tdm-slots = <2>;
         serial-dir = <
diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt
index 98611a6761c0..0f4e23828190 100644
--- a/Documentation/devicetree/bindings/sound/fsl-sai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
@@ -7,10 +7,11 @@ codec/DSP interfaces.
 
 
 Required properties:
-- compatible: Compatible list, contains "fsl,vf610-sai".
+- compatible: Compatible list, contains "fsl,vf610-sai" or "fsl,imx6sx-sai".
 - reg: Offset and length of the register set for the device.
 - clocks: Must contain an entry for each entry in clock-names.
-- clock-names : Must include the "sai" entry.
+- clock-names : Must include the "bus" for register access and "mclk1" "mclk2"
+  "mclk3" for bit clock and frame clock providing.
 - dmas : Generic dma devicetree binding as described in
   Documentation/devicetree/bindings/dma/dma.txt.
 - dma-names : Two dmas have to be defined, "tx" and "rx".
@@ -30,8 +31,10 @@ sai2: sai@40031000 {
               reg = <0x40031000 0x1000>;
               pinctrl-names = "default";
               pinctrl-0 = <&pinctrl_sai2_1>;
-              clocks = <&clks VF610_CLK_SAI2>;
-              clock-names = "sai";
+              clocks = <&clks VF610_CLK_PLATFORM_BUS>,
+                     <&clks VF610_CLK_SAI2>,
+                     <&clks 0>, <&clks 0>;
+              clock-names = "bus", "mclk1", "mclk2", "mclk3";
               dma-names = "tx", "rx";
               dmas = <&edma0 0 VF610_EDMA_MUXID0_SAI2_TX>,
                    <&edma0 0 VF610_EDMA_MUXID0_SAI2_RX>;
diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt
index e4c8b36dcf89..a5e63fa47dc5 100644
--- a/Documentation/devicetree/bindings/sound/max98090.txt
+++ b/Documentation/devicetree/bindings/sound/max98090.txt
@@ -10,6 +10,12 @@ Required properties:
 
 - interrupts : The CODEC's interrupt output.
 
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC
+
+- clock-names: Should be "mclk"
+
 Pins on the device (for linking into audio routes):
 
   * MIC1
diff --git a/Documentation/devicetree/bindings/sound/max98095.txt b/Documentation/devicetree/bindings/sound/max98095.txt
new file mode 100644
index 000000000000..318a4c82f17f
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98095.txt
@@ -0,0 +1,22 @@
+MAX98095 audio CODEC
+
+This device supports I2C only.
+
+Required properties:
+
+- compatible : "maxim,max98095".
+
+- reg : The I2C address of the device.
+
+Optional properties:
+
+- clocks: The phandle of the master clock to the CODEC
+
+- clock-names: Should be "mclk"
+
+Example:
+
+max98095: codec@11 {
+        compatible = "maxim,max98095";
+        reg = <0x11>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nokia,rx51.txt b/Documentation/devicetree/bindings/sound/nokia,rx51.txt
new file mode 100644
index 000000000000..72f93d996273
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nokia,rx51.txt
@@ -0,0 +1,27 @@
+* Nokia N900 audio setup
+
+Required properties:
+- compatible: Should contain "nokia,n900-audio"
+- nokia,cpu-dai: phandle for the McBSP node
+- nokia,audio-codec: phandles for the main TLV320AIC3X node and the
+                     auxiliary TLV320AIC3X node (in this order)
+- nokia,headphone-amplifier: phandle for the TPA6130A2 node
+- tvout-selection-gpios: GPIO for tvout selection
+- jack-detection-gpios: GPIO for jack detection
+- eci-switch-gpios: GPIO for ECI (Enhancement Control Interface) switch
+- speaker-amplifier-gpios: GPIO for speaker amplifier
+
+Example:
+
+sound {
+        compatible = "nokia,n900-audio";
+
+        nokia,cpu-dai = <&mcbsp2>;
+        nokia,audio-codec = <&tlv320aic3x>, <&tlv320aic3x_aux>;
+        nokia,headphone-amplifier = <&tpa6130a2>;
+
+        tvout-selection-gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>; /* 40 */
+        jack-detection-gpios = <&gpio6 17 GPIO_ACTIVE_HIGH>; /* 177 */
+        eci-switch-gpios = <&gpio6 22 GPIO_ACTIVE_HIGH>; /* 182 */
+        speaker-amplifier-gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
new file mode 100644
index 000000000000..b4730c2822bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.txt
@@ -0,0 +1,28 @@
+NVIDIA Tegra30 HDA controller
+
+Required properties:
+- compatible : "nvidia,tegra30-hda"
+- reg : Should contain the HDA registers location and length.
+- interrupts : The interrupt from the HDA controller.
+- clocks : Must contain an entry for each required entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries: hda, hdacodec_2x, hda2hdmi
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries: hda, hdacodec_2x, hda2hdmi
+
+Example:
+
+hda@0,70030000 {
+        compatible = "nvidia,tegra124-hda", "nvidia,tegra30-hda";
+        reg = <0x0 0x70030000 0x0 0x10000>;
+        interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&tegra_car TEGRA124_CLK_HDA>,
+                 <&tegra_car TEGRA124_CLK_HDA2HDMI>,
+                 <&tegra_car TEGRA124_CLK_HDA2CODEC_2X>;
+        clock-names = "hda", "hda2hdmi", "hda2codec_2x";
+        resets = <&tegra_car 125>, /* hda */
+                 <&tegra_car 128>; /* hda2hdmi */
+                 <&tegra_car 111>, /* hda2codec_2x */
+        reset-names = "hda", "hda2hdmi", "hda2codec_2x";
+};
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
index a44e9179faf5..8346cab046cd 100644
--- a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -20,6 +20,7 @@ Required properties:
 SSI subnode properties:
 - interrupts                    : Should contain SSI interrupt for PIO transfer
 - shared-pin                    : if shared clock pin
+- pio-transfer                  : use PIO transfer mode
 
 SRC subnode properties:
 no properties at this point
diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt
index 068a1141b06f..bac4d9ac1edc 100644
--- a/Documentation/devicetree/bindings/sound/rt5640.txt
+++ b/Documentation/devicetree/bindings/sound/rt5640.txt
@@ -1,10 +1,10 @@
-RT5640 audio CODEC
+RT5640/RT5639 audio CODEC
 
 This device supports I2C only.
 
 Required properties:
 
-- compatible : "realtek,rt5640".
+- compatible : One of "realtek,rt5640" or "realtek,rt5639".
 
 - reg : The I2C address of the device.
 
@@ -18,7 +18,7 @@ Optional properties:
 
 - realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
 
-Pins on the device (for linking into audio routes):
+Pins on the device (for linking into audio routes) for RT5639/RT5640:
 
   * DMIC1
   * DMIC2
@@ -31,13 +31,16 @@ Pins on the device (for linking into audio routes):
   * HPOR
   * LOUTL
   * LOUTR
-  * MONOP
-  * MONON
   * SPOLP
   * SPOLN
   * SPORP
   * SPORN
 
+Additional pins on the device for RT5640:
+
+  * MONOP
+  * MONON
+
 Example:
 
 rt5640 {
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt
index 131aa2ad7f1a..c2e9841dfce4 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -1,6 +1,6 @@
 Simple-Card:
 
-Simple-Card specifies audio DAI connection of SoC <-> codec.
+Simple-Card specifies audio DAI connections of SoC <-> codec.
 
 Required properties:
 
@@ -10,26 +10,54 @@ Optional properties:
 
 - simple-audio-card,name                : User specified audio sound card name, one string
                                           property.
-- simple-audio-card,format              : CPU/CODEC common audio format.
-                                          "i2s", "right_j", "left_j" , "dsp_a"
-                                          "dsp_b", "ac97", "pdm", "msb", "lsb"
 - simple-audio-card,widgets             : Please refer to widgets.txt.
 - simple-audio-card,routing             : A list of the connections between audio components.
                                           Each entry is a pair of strings, the first being the
                                           connection's sink, the second being the connection's
                                           source.
-- dai-tdm-slot-num                      : Please refer to tdm-slot.txt.
-- dai-tdm-slot-width                    : Please refer to tdm-slot.txt.
+- simple-audio-card,mclk-fs             : Multiplication factor between stream rate and codec
+                                          mclk.
+
+Optional subnodes:
+
+- simple-audio-card,dai-link            : Container for dai-link level
+                                          properties and the CPU and CODEC
+                                          sub-nodes. This container may be
+                                          omitted when the card has only one
+                                          DAI link. See the examples and the
+                                          section bellow.
+
+Dai-link subnode properties and subnodes:
+
+If dai-link subnode is omitted and the subnode properties are directly
+under "sound"-node the subnode property and subnode names have to be
+prefixed with "simple-audio-card,"-prefix.
 
-Required subnodes:
+Required dai-link subnodes:
 
-- simple-audio-card,dai-link            : container for the CPU and CODEC sub-nodes
-                                          This container may be omitted when the
-                                          card has only one DAI link.
-                                          See the examples.
+- cpu                                   : CPU   sub-node
+- codec                                 : CODEC sub-node
 
-- simple-audio-card,cpu                 : CPU   sub-node
-- simple-audio-card,codec               : CODEC sub-node
+Optional dai-link subnode properties:
+
+- format                                : CPU/CODEC common audio format.
+                                          "i2s", "right_j", "left_j" , "dsp_a"
+                                          "dsp_b", "ac97", "pdm", "msb", "lsb"
+- frame-master                          : Indicates dai-link frame master.
+                                          phandle to a cpu or codec subnode.
+- bitclock-master                       : Indicates dai-link bit clock master.
+                                          phandle to a cpu or codec subnode.
+- bitclock-inversion                    : bool property. Add this if the
+                                          dai-link uses bit clock inversion.
+- frame-inversion                       : bool property. Add this if the
+                                          dai-link uses frame clock inversion.
+
+For backward compatibility the frame-master and bitclock-master
+properties can be used as booleans in codec subnode to indicate if the
+codec is the dai-link frame or bit clock master. In this case there
+should be no dai-link node, the same properties should not be present
+at sound-node level, and the bitclock-inversion and frame-inversion
+properties should also be placed in the codec node if needed.
 
 Required CPU/CODEC subnodes properties:
 
@@ -37,29 +65,21 @@ Required CPU/CODEC subnodes properties:
 
 Optional CPU/CODEC subnodes properties:
 
-- format                                : CPU/CODEC specific audio format if needed.
-                                          see simple-audio-card,format
-- frame-master                          : bool property. add this if subnode is frame master
-- bitclock-master                       : bool property. add this if subnode is bitclock master
-- bitclock-inversion                    : bool property. add this if subnode has clock inversion
-- frame-inversion                       : bool property. add this if subnode has frame inversion
+- dai-tdm-slot-num                      : Please refer to tdm-slot.txt.
+- dai-tdm-slot-width                    : Please refer to tdm-slot.txt.
 - clocks / system-clock-frequency       : specify subnode's clock if needed.
                                           it can be specified via "clocks" if system has
                                           clock node (= common clock), or "system-clock-frequency"
                                           (if system doens't support common clock)
 
-Note:
- * For 'format', 'frame-master', 'bitclock-master', 'bitclock-inversion' and
-   'frame-inversion', the simple card will use the settings of CODEC for both
-   CPU and CODEC sides as we need to keep the settings identical for both ends
-   of the link.
-
 Example 1 - single DAI link:
 
 sound {
         compatible = "simple-audio-card";
         simple-audio-card,name = "VF610-Tower-Sound-Card";
         simple-audio-card,format = "left_j";
+        simple-audio-card,bitclock-master = <&dailink0_master>;
+        simple-audio-card,frame-master = <&dailink0_master>;
         simple-audio-card,widgets =
                 "Microphone", "Microphone Jack",
                 "Headphone", "Headphone Jack",
@@ -69,17 +89,12 @@ sound {
                 "Headphone Jack", "HP_OUT",
                 "External Speaker", "LINE_OUT";
 
-        dai-tdm-slot-num = <2>;
-        dai-tdm-slot-width = <8>;
-
         simple-audio-card,cpu {
                 sound-dai = <&sh_fsi2 0>;
         };
 
-        simple-audio-card,codec {
+        dailink0_master: simple-audio-card,codec {
                 sound-dai = <&ak4648>;
-                bitclock-master;
-                frame-master;
                 clocks = <&osc>;
         };
 };
@@ -105,31 +120,31 @@ Example 2 - many DAI links:
 sound {
         compatible = "simple-audio-card";
         simple-audio-card,name = "Cubox Audio";
-        simple-audio-card,format = "i2s";
 
         simple-audio-card,dai-link@0 {          /* I2S - HDMI */
-                simple-audio-card,cpu {
+                format = "i2s";
+                cpu {
                         sound-dai = <&audio1 0>;
                 };
-                simple-audio-card,codec {
+                codec {
                         sound-dai = <&tda998x 0>;
                 };
         };
 
         simple-audio-card,dai-link@1 {          /* S/PDIF - HDMI */
-                simple-audio-card,cpu {
+                cpu {
                         sound-dai = <&audio1 1>;
                 };
-                simple-audio-card,codec {
+                codec {
                         sound-dai = <&tda998x 1>;
                 };
         };
 
         simple-audio-card,dai-link@2 {          /* S/PDIF - S/PDIF */
-                simple-audio-card,cpu {
+                cpu {
                         sound-dai = <&audio1 1>;
                 };
-                simple-audio-card,codec {
+                codec {
                         sound-dai = <&spdif_codec>;
                 };
         };
diff --git a/Documentation/devicetree/bindings/sound/snow.txt b/Documentation/devicetree/bindings/sound/snow.txt
new file mode 100644
index 000000000000..678b191c37b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/snow.txt
@@ -0,0 +1,17 @@
+Audio Binding for Snow boards
+
+Required properties:
+- compatible : Can be one of the following,
+                        "google,snow-audio-max98090" or
+                        "google,snow-audio-max98095"
+- samsung,i2s-controller: The phandle of the Samsung I2S controller
+- samsung,audio-codec: The phandle of the audio codec
+
+Example:
+
+sound {
+                compatible = "google,snow-audio-max98095";
+
+                samsung,i2s-controller = <&i2s0>;
+                samsung,audio-codec = <&max98095>;
+};
diff --git a/Documentation/devicetree/bindings/sound/st,sta350.txt b/Documentation/devicetree/bindings/sound/st,sta350.txt
new file mode 100644
index 000000000000..b7e71bf5caf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/st,sta350.txt
@@ -0,0 +1,131 @@
+STA350 audio CODEC
+
+The driver for this device only supports I2C.
+
+Required properties:
+
+  - compatible: "st,sta350"
+  - reg: the I2C address of the device for I2C
+  - reset-gpios: a GPIO spec for the reset pin. If specified, it will be
+                 deasserted before communication to the codec starts.
+
+  - power-down-gpios: a GPIO spec for the power down pin. If specified,
+                      it will be deasserted before communication to the codec
+                      starts.
+
+  - vdd-dig-supply: regulator spec, providing 3.3V
+  - vdd-pll-supply: regulator spec, providing 3.3V
+  - vcc-supply: regulator spec, providing 5V - 26V
+
+Optional properties:
+
+  -  st,output-conf: number, Selects the output configuration:
+        0: 2-channel (full-bridge) power, 2-channel data-out
+        1: 2 (half-bridge). 1 (full-bridge) on-board power
+        2: 2 Channel (Full-Bridge) Power, 1 Channel FFX
+        3: 1 Channel Mono-Parallel
+        If parameter is missing, mode 0 will be enabled.
+        This property has to be specified as '/bits/ 8' value.
+
+  -  st,ch1-output-mapping: Channel 1 output mapping
+  -  st,ch2-output-mapping: Channel 2 output mapping
+  -  st,ch3-output-mapping: Channel 3 output mapping
+        0: Channel 1
+        1: Channel 2
+        2: Channel 3
+        If parameter is missing, channel 1 is choosen.
+        This properties have to be specified as '/bits/ 8' values.
+
+  -  st,thermal-warning-recover:
+        If present, thermal warning recovery is enabled.
+
+  -  st,thermal-warning-adjustment:
+        If present, thermal warning adjustment is enabled.
+
+  -  st,fault-detect-recovery:
+        If present, then fault recovery will be enabled.
+
+  -  st,ffx-power-output-mode: string
+        The FFX power output mode selects how the FFX output timing is
+        configured. Must be one of these values:
+          -  "drop-compensation"
+          -  "tapered-compensation"
+          -  "full-power-mode"
+          -  "variable-drop-compensation" (default)
+
+  -  st,drop-compensation-ns: number
+        Only required for "st,ffx-power-output-mode" ==
+        "variable-drop-compensation".
+        Specifies the drop compensation in nanoseconds.
+        The value must be in the range of 0..300, and only
+        multiples of 20 are allowed. Default is 140ns.
+
+  -  st,overcurrent-warning-adjustment:
+        If present, overcurrent warning adjustment is enabled.
+
+  -  st,max-power-use-mpcc:
+        If present, then MPCC bits are used for MPC coefficients,
+        otherwise standard MPC coefficients are used.
+
+  -  st,max-power-corr:
+        If present, power bridge correction for THD reduction near maximum
+        power output is enabled.
+
+  -  st,am-reduction-mode:
+        If present, FFX mode runs in AM reduction mode, otherwise normal
+        FFX mode is used.
+
+  -  st,odd-pwm-speed-mode:
+        If present, PWM speed mode run on odd speed mode (341.3 kHz) on all
+        channels. If not present, normal PWM spped mode (384 kHz) will be used.
+
+  -  st,distortion-compensation:
+        If present, distortion compensation variable uses DCC coefficient.
+        If not present, preset DC coefficient is used.
+
+  -  st,invalid-input-detect-mute:
+        If present, automatic invalid input detect mute is enabled.
+
+  -  st,activate-mute-output:
+        If present, a mute output will be activated in ase the volume will
+        reach a value lower than -76 dBFS.
+
+  -  st,bridge-immediate-off:
+        If present, the bridge will be switched off immediately after the
+        power-down-gpio goes low. Otherwise, the bridge will wait for 13
+        million clock cycles to pass before shutting down.
+
+  -  st,noise-shape-dc-cut:
+        If present, the noise-shaping technique on the DC cutoff filter are
+        enabled.
+
+  -  st,powerdown-master-volume:
+        If present, the power-down pin and I2C power-down functions will
+        act on the master volume. Otherwise, the functions will act on the
+        mute commands.
+
+  -  st,powerdown-delay-divider:
+        If present, the bridge power-down time will be divided by the provided
+        value. If not specified, a divider of 1 will be used. Allowed values
+        are 1, 2, 4, 8, 16, 32, 64 and 128.
+        This property has to be specified as '/bits/ 8' value.
+
+Example:
+
+codec: sta350@38 {
+        compatible = "st,sta350";
+        reg = <0x1c>;
+        reset-gpios = <&gpio1 19 0>;
+        power-down-gpios = <&gpio1 16 0>;
+        st,output-conf = /bits/ 8  <0x3>;       // set output to 2-channel
+                                                // (full-bridge) power,
+                                                // 2-channel data-out
+        st,ch1-output-mapping = /bits/ 8 <0>;   // set channel 1 output ch 1
+        st,ch2-output-mapping = /bits/ 8 <0>;   // set channel 2 output ch 1
+        st,ch3-output-mapping = /bits/ 8 <0>;   // set channel 3 output ch 1
+        st,max-power-correction;                // enables power bridge
+                                                // correction for THD reduction
+                                                // near maximum power output
+        st,invalid-input-detect-mute;           // mute if no valid digital
+                                                // audio signal is provided.
+};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
index 74c66dee3e14..eff12be5e789 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -13,6 +13,9 @@ Required properties:
     "ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP)
 
 - reg - <int> -  I2C slave address
+- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
+  DVDD-supply : power supplies for the device as covered in
+  Documentation/devicetree/bindings/regulator/regulator.txt
 
 
 Optional properties:
@@ -24,9 +27,6 @@ Optional properties:
         3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD
         If this node is not mentioned or if the value is unknown, then
         micbias is set to 2.0V.
-- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
-  DVDD-supply : power supplies for the device as covered in
-  Documentation/devicetree/bindings/regulator/regulator.txt
 
 CODEC output pins:
   * HPL
diff --git a/Documentation/devicetree/bindings/spi/fsl-spi.txt b/Documentation/devicetree/bindings/spi/fsl-spi.txt
index b032dd76e9d2..a2331372068c 100644
--- a/Documentation/devicetree/bindings/spi/fsl-spi.txt
+++ b/Documentation/devicetree/bindings/spi/fsl-spi.txt
@@ -42,6 +42,10 @@ Required properties:
 - interrupts : should contain eSPI interrupt, the device has one interrupt.
 - fsl,espi-num-chipselects : the number of the chipselect signals.
 
+Optional properties:
+- fsl,csbef: chip select assertion time in bits before frame starts
+- fsl,csaft: chip select negation time in bits after frame ends
+
 Example:
         spi@110000 {
                 #address-cells = <1>;
@@ -51,4 +55,6 @@ Example:
                 interrupts = <53 0x2>;
                 interrupt-parent = <&mpic>;
                 fsl,espi-num-chipselects = <4>;
+                fsl,csbef = <1>;
+                fsl,csaft = <1>;
         };
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt
index e5a4d1b4acfe..bbaa857dd68f 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -55,13 +55,15 @@ contain the following properties.
                 chip select active high
 - spi-3wire       - (optional) Empty property indicating device requires
                     3-wire mode.
+- spi-lsb-first   - (optional) Empty property indicating device requires
+                LSB first mode.
 - spi-tx-bus-width - (optional) The bus width(number of data wires) that
                       used for MOSI. Defaults to 1 if not present.
 - spi-rx-bus-width - (optional) The bus width(number of data wires) that
                       used for MISO. Defaults to 1 if not present.
 
 Some SPI controllers and devices support Dual and Quad SPI transfer mode.
-It allows data in SPI system transfered in 2 wires(DUAL) or 4 wires(QUAD).
+It allows data in the SPI system to be transferred in 2 wires(DUAL) or 4 wires(QUAD).
 Now the value that spi-tx-bus-width and spi-rx-bus-width can receive is
 only 1(SINGLE), 2(DUAL) and 4(QUAD).
 Dual/Quad mode is not allowed when 3-wire mode is used.
diff --git a/Documentation/devicetree/bindings/spi/spi-cadence.txt b/Documentation/devicetree/bindings/spi/spi-cadence.txt
new file mode 100644
index 000000000000..94f09141a4f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-cadence.txt
@@ -0,0 +1,31 @@
+Cadence SPI controller Device Tree Bindings
+-------------------------------------------
+
+Required properties:
+- compatible            : Should be "cdns,spi-r1p6" or "xlnx,zynq-spi-r1p6".
+- reg                   : Physical base address and size of SPI 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 - "ref_clk", "pclk"
+                          (See clock bindings for details).
+- clocks                : Clock phandles (see clock bindings for details).
+
+Optional properties:
+- num-cs                : Number of chip selects used.
+                          If a decoder is used, this will be the number of
+                          chip selects after the decoder.
+- is-decoded-cs         : Flag to indicate whether decoder is used or not.
+
+Example:
+
+        spi@e0007000 {
+                compatible = "xlnx,zynq-spi-r1p6";
+                clock-names = "ref_clk", "pclk";
+                clocks = <&clkc 26>, <&clkc 35>;
+                interrupt-parent = <&intc>;
+                interrupts = <0 49 4>;
+                num-cs = <4>;
+                is-decoded-cs = <0>;
+                reg = <0xe0007000 0x1000>;
+        } ;
diff --git a/Documentation/devicetree/bindings/spi/spi-dw.txt b/Documentation/devicetree/bindings/spi/spi-dw.txt
new file mode 100644
index 000000000000..7b63ed601990
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-dw.txt
@@ -0,0 +1,24 @@
+Synopsys DesignWare SPI master
+
+Required properties:
+- compatible: should be "snps,designware-spi"
+- #address-cells: see spi-bus.txt
+- #size-cells: see spi-bus.txt
+- reg: address and length of the spi master registers
+- interrupts: should contain one interrupt
+- clocks: spi clock phandle
+- num-cs: see spi-bus.txt
+
+Optional properties:
+- cs-gpios: see spi-bus.txt
+
+Example:
+
+spi: spi@4020a000 {
+        compatible = "snps,designware-spi";
+        interrupts = <11 1>;
+        reg = <0x4020a000 0x1000>;
+        clocks = <&pclk>;
+        num-cs = <2>;
+        cs-gpios = <&banka 0 0>;
+};
diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt b/Documentation/devicetree/bindings/spmi/spmi.txt
index 462a42fb3a1e..4bb10d161a27 100644
--- a/Documentation/devicetree/bindings/spmi/spmi.txt
+++ b/Documentation/devicetree/bindings/spmi/spmi.txt
@@ -26,7 +26,7 @@ Each child node must have one and only one 'reg' entry of type SPMI_USID.
                 reg = <...>;
 
                 #address-cells = <2>;
-                #size-cells <0>;
+                #size-cells = <0>;
 
                 child@0 {
                         compatible = "...";
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index 3be5ce7a9654..e75f0e549fff 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -61,6 +61,7 @@ Required properties:
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
   display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
+  and "lvds666".
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
diff --git a/Documentation/devicetree/bindings/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
-        registers.
+        belongs to register set of TMU instance and second set belongs to
+        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/timer/allwinner,sun5i-a13-hstimer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt
index 7c26154b8bbb..27cfc7d7ccd7 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.txt
@@ -9,6 +9,9 @@ Required properties:
                 one)
 - clocks: phandle to the source clock (usually the AHB clock)
 
+Optionnal properties:
+- resets: phandle to a reset controller asserting the timer
+
 Example:
 
 timer@01c60000 {
@@ -19,4 +22,5 @@ timer@01c60000 {
                      <0 53 1>,
                      <0 54 1>;
         clocks = <&ahb1_gates 19>;
+        resets = <&ahb1rst 19>;
 };
diff --git a/Documentation/devicetree/bindings/timer/efm32,timer.txt b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt
index 97a568f696c9..e502c11b2211 100644
--- a/Documentation/devicetree/bindings/timer/efm32,timer.txt
+++ b/Documentation/devicetree/bindings/timer/energymicro,efm32-timer.txt
@@ -6,7 +6,7 @@ channels and can be used as PWM or Quadrature Decoder. Available clock sources
 are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin.
 
 Required properties:
-- compatible : Should be efm32,timer
+- compatible : Should be "energymicro,efm32-timer"
 - reg : Address and length of the register set
 - clocks : Should contain a reference to the HFPERCLK
 
@@ -16,7 +16,7 @@ Optional properties:
 Example:
 
 timer@40010c00 {
-        compatible = "efm32,timer";
+        compatible = "energymicro,efm32-timer";
         reg = <0x40010c00 0x400>;
         interrupts = <14>;
         clocks = <&cmu clk_HFPERCLKTIMER3>;
diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
new file mode 100644
index 000000000000..aa8c40230e5e
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
@@ -0,0 +1,31 @@
+Freescale FlexTimer Module (FTM) Timer
+
+Required properties:
+
+- compatible : should be "fsl,ftm-timer"
+- reg : Specifies base physical address and size of the register sets for the
+  clock event device and clock source device.
+- interrupts : Should be the clock event device interrupt.
+- clocks : The clocks provided by the SoC to drive the timer, must contain an
+  entry for each entry in clock-names.
+- clock-names : Must include the following entries:
+  o "ftm-evt"
+  o "ftm-src"
+  o "ftm-evt-counter-en"
+  o "ftm-src-counter-en"
+- big-endian: One boolean property, the big endian mode will be in use if it is
+  present, or the little endian mode will be in use for all the device registers.
+
+Example:
+ftm: ftm@400b8000 {
+        compatible = "fsl,ftm-timer";
+        reg = <0x400b8000 0x1000 0x400b9000 0x1000>;
+        interrupts = <0 44 IRQ_TYPE_LEVEL_HIGH>;
+        clock-names = "ftm-evt", "ftm-src",
+                "ftm-evt-counter-en", "ftm-src-counter-en";
+        clocks = <&clks VF610_CLK_FTM2>,
+                <&clks VF610_CLK_FTM3>,
+                <&clks VF610_CLK_FTM2_EXT_FIX_EN>,
+                <&clks VF610_CLK_FTM3_EXT_FIX_EN>;
+        big-endian;
+};
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
new file mode 100644
index 000000000000..f2899b550939
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-qcom.txt
@@ -0,0 +1,17 @@
+Qualcomm CI13xxx (Chipidea) USB controllers
+
+Required properties:
+- compatible:   should contain "qcom,ci-hdrc"
+- reg:          offset and length of the register set in the memory map
+- interrupts:   interrupt-specifier for the controller interrupt.
+- usb-phy:      phandle for the PHY device
+- dr_mode:      Should be "peripheral"
+
+Examples:
+        gadget@f9a55000 {
+                compatible = "qcom,ci-hdrc";
+                reg = <0xf9a55000 0x400>;
+                dr_mode = "peripheral";
+                interrupts = <0 134 0>;
+                usb-phy = <&usbphy0>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
index b8b6871f116f..467ddd15d40c 100644
--- a/Documentation/devicetree/bindings/usb/dwc2.txt
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -13,7 +13,7 @@ Refer to clk/clock-bindings.txt for generic clock consumer properties
 
 Optional properties:
 - phys: phy provider specifier
-- phy-names: shall be "device"
+- phy-names: shall be "usb2-phy"
 Refer to phy/phy-bindings.txt for generic phy consumer properties
 
 Example:
diff --git a/Documentation/devicetree/bindings/usb/ehci-orion.txt b/Documentation/devicetree/bindings/usb/ehci-orion.txt
index 6bc09ec14c4d..17c3bc858b86 100644
--- a/Documentation/devicetree/bindings/usb/ehci-orion.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-orion.txt
@@ -6,6 +6,11 @@ Required properties:
   region.
 - interrupts: The EHCI interrupt
 
+Optional properties:
+- clocks: reference to the clock
+- phys: reference to the USB PHY
+- phy-names: name of the USB PHY, should be "usb"
+
 Example:
 
         ehci@50000 {
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index d967ba16de60..a3b5990d0f2c 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -12,6 +12,13 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are EHCI phys, they should be listed here.
+   One phy per port. Each port should have following entries:
+        - reg: port number on EHCI controller, e.g
+               On Exynos5250, port 0 is USB2.0 otg phy
+                              port 1 is HSIC phy0
+                              port 2 is HSIC phy1
+        - phys: from the *Generic PHY* bindings; specifying phy used by port.
 
 Optional properties:
  - samsung,vbus-gpio:  if present, specifies the GPIO that
@@ -27,6 +34,14 @@ Example:
 
                 clocks = <&clock 285>;
                 clock-names = "usbhost";
+
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port@0 {
+                    reg = <0>;
+                    phys = <&usb2phy 1>;
+                    status = "disabled";
+                };
         };
 
 OHCI
@@ -38,6 +53,13 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - clocks: from common clock binding: handle to usb clock.
  - clock-names: from common clock binding: Shall be "usbhost".
+ - port: if in the SoC there are OHCI phys, they should be listed here.
+   One phy per port. Each port should have following entries:
+        - reg: port number on OHCI controller, e.g
+               On Exynos5250, port 0 is USB2.0 otg phy
+                              port 1 is HSIC phy0
+                              port 2 is HSIC phy1
+        - phys: from the *Generic PHY* bindings, specifying phy used by port.
 
 Example:
         usb@12120000 {
@@ -47,6 +69,15 @@ Example:
 
                 clocks = <&clock 285>;
                 clock-names = "usbhost";
+
+                #address-cells = <1>;
+                #size-cells = <0>;
+                port@0 {
+                    reg = <0>;
+                    phys = <&usb2phy 1>;
+                    status = "disabled";
+                };
+
         };
 
 DWC3
diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt b/Documentation/devicetree/bindings/usb/gr-udc.txt
index 0c5118f7a916..e9445224fabd 100644
--- a/Documentation/devicetree/bindings/usb/gr-udc.txt
+++ b/Documentation/devicetree/bindings/usb/gr-udc.txt
@@ -12,17 +12,23 @@ Required properties:
 
 - reg : Address and length of the register set for the device
 
-- interrupts : Interrupt numbers for this device
+- interrupts : Interrupt numbers for this device. Either one interrupt number
+        for all interrupts, or one for status related interrupts, one for IN
+        endpoint related interrupts and one for OUT endpoint related interrupts.
 
 Optional properties:
 
-- epobufsizes : An array of buffer sizes for OUT endpoints. If the property is
-        not present, or for endpoints outside of the array, 1024 is assumed by
-        the driver.
-
-- epibufsizes : An array of buffer sizes for IN endpoints. If the property is
-        not present, or for endpoints outside of the array, 1024 is assumed by
-        the driver.
+- epobufsizes : Array of buffer sizes for OUT endpoints when they differ
+        from the default size of 1024. The array is indexed by the OUT endpoint
+        number. If the property is present it typically contains one entry for
+        each OUT endpoint of the core. Fewer entries overrides the default sizes
+        only for as many endpoints as the array contains.
+
+- epibufsizes : Array of buffer sizes for IN endpoints when they differ
+        from the default size of 1024. The array is indexed by the IN endpoint
+        number. If the property is present it typically contains one entry for
+        each IN endpoint of the core. Fewer entries overrides the default sizes
+        only for as many endpoints as the array contains.
 
 For further information look in the documentation for the GLIB IP core library:
 http://www.gaisler.com/products/grlib/grip.pdf
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
index 5ea26c631e3a..2826f2af503a 100644
--- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -15,3 +15,81 @@ Example EHCI controller device node:
                 usb-phy = <&usb_otg>;
         };
 
+USB PHY with optional OTG:
+
+Required properties:
+- compatible:   Should contain:
+  "qcom,usb-otg-ci" for chipsets with ChipIdea 45nm PHY
+  "qcom,usb-otg-snps" for chipsets with Synopsys 28nm PHY
+
+- regs:         Offset and length of the register set in the memory map
+- interrupts:   interrupt-specifier for the OTG interrupt.
+
+- clocks:       A list of phandle + clock-specifier pairs for the
+                clocks listed in clock-names
+- clock-names:  Should contain the following:
+  "phy"         USB PHY reference clock
+  "core"        Protocol engine clock
+  "iface"       Interface bus clock
+  "alt_core"    Protocol engine clock for targets with asynchronous
+                reset methodology. (optional)
+
+- vdccx-supply: phandle to the regulator for the vdd supply for
+                digital circuit operation.
+- v1p8-supply:  phandle to the regulator for the 1.8V supply
+- v3p3-supply:  phandle to the regulator for the 3.3V supply
+
+- resets:       A list of phandle + reset-specifier pairs for the
+                resets listed in reset-names
+- reset-names:  Should contain the following:
+  "phy"         USB PHY controller reset
+  "link"        USB LINK controller reset
+
+- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of
+                1 - PHY control
+                2 - PMIC control
+
+Optional properties:
+- dr_mode:      One of "host", "peripheral" or "otg". Defaults to "otg"
+
+- qcom,phy-init-sequence: PHY configuration sequence values. This is related to Device
+                Mode Eye Diagram test. Start address at which these values will be
+                written is ULPI_EXT_VENDOR_SPECIFIC. Value of -1 is reserved as
+                "do not overwrite default value at this address".
+                For example: qcom,phy-init-sequence = < -1 0x63 >;
+                Will update only value at address ULPI_EXT_VENDOR_SPECIFIC + 1.
+
+- qcom,phy-num: Select number of pyco-phy to use, can be one of
+                0 - PHY one, default
+                1 - Second PHY
+                Some platforms may have configuration to allow USB
+                controller work with any of the two HSPHYs present.
+
+- qcom,vdd-levels: This property must be a list of three integer values
+                (no, min, max) where each value represents either a voltage
+                in microvolts or a value corresponding to voltage corner.
+
+Example HSUSB OTG controller device node:
+
+    usb@f9a55000 {
+        compatible = "qcom,usb-otg-snps";
+        reg = <0xf9a55000 0x400>;
+        interrupts = <0 134 0>;
+        dr_mode = "peripheral";
+
+        clocks = <&gcc GCC_XO_CLK>, <&gcc GCC_USB_HS_SYSTEM_CLK>,
+                <&gcc GCC_USB_HS_AHB_CLK>;
+
+        clock-names = "phy", "core", "iface";
+
+        vddcx-supply = <&pm8841_s2_corner>;
+        v1p8-supply = <&pm8941_l6>;
+        v3p3-supply = <&pm8941_l24>;
+
+        resets = <&gcc GCC_USB2A_PHY_BCR>, <&gcc GCC_USB_HS_BCR>;
+        reset-names = "phy", "link";
+
+        qcom,otg-control = <1>;
+        qcom,phy-init-sequence = < -1 0x63 >;
+        qcom,vdd-levels = <1 5 7>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 38b2faec4199..38d9bb8507cf 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -44,7 +44,9 @@ Board specific device node entry
 };
 
 OMAP DWC3 GLUE
- - compatible : Should be "ti,dwc3"
+ - compatible : Should be
+        * "ti,dwc3" for OMAP5 and DRA7
+        * "ti,am437x-dwc3" for AM437x
  - ti,hwmods : Should be "usb_otg_ss"
  - reg : Address and length of the register set for the device.
  - interrupts : The irq number of this device that is used to interrupt the
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index ff151ec084c4..43c1a4e06767 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -15,6 +15,7 @@ Optional properties:
  - clocks : a list of phandle + clock specifier pairs
  - phys : phandle + phy specifier pair
  - phy-names : "usb"
+ - resets : phandle + reset specifier pair
 
 Example (Sequoia 440EPx):
     ehci@e0000300 {
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
index 45f67d91e888..b968a1aea995 100644
--- a/Documentation/devicetree/bindings/usb/usb-ohci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -12,6 +12,7 @@ Optional properties:
 - clocks : a list of phandle + clock specifier pairs
 - phys : phandle + phy specifier pair
 - phy-names : "usb"
+- resets : phandle + reset specifier pair
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 90f8f607d125..5a79377c6a96 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -1,11 +1,17 @@
 USB xHCI controllers
 
 Required properties:
-  - compatible: should be "generic-xhci" (deprecated: "xhci-platform").
+  - compatible: should be one of "generic-xhci",
+    "marvell,armada-375-xhci", "marvell,armada-380-xhci",
+    "renesas,xhci-r8a7790", "renesas,xhci-r8a7791" (deprecated:
+    "xhci-platform").
   - reg: should contain address and length of the standard XHCI
     register set for the device.
   - interrupts: one XHCI interrupt should be described here.
 
+Optional property:
+  - clocks: reference to a clock
+
 Example:
         usb@f0931000 {
                 compatible = "generic-xhci";
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt
index a018da4a7ad7..221ac0dbc678 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -15,6 +15,14 @@ Optional properties:
 - reset-gpios: Should specify GPIO for reset.
 - initial-mode: Should specify initial mode.
                 (1 for HUB mode, 2 for STANDBY mode)
+- refclk: Clock used for driving REFCLK signal (optional, if not provided
+        the driver assumes that clock signal is always available, its
+        rate is specified by REF_SEL pins and a value from the primary
+        reference clock frequencies table is used)
+- refclk-frequency: Frequency of the REFCLK signal as defined by REF_SEL
+        pins (optional, if not provided, driver will not set rate of the
+        REFCLK signal and assume that a value from the primary reference
+        clock frequencies table is used)
 
 Examples:
         usb3503@08 {
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 0f01c9bf19c8..4d7f3758d1b4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -13,6 +13,7 @@ allwinner	Allwinner Technology Co., Ltd.
 altr    Altera Corp.
 amcc    Applied Micro Circuits Corporation (APM, formally AMCC)
 amd     Advanced Micro Devices (AMD), Inc.
+ams     AMS AG
 amstaos AMS-Taos Inc.
 apm     Applied Micro Circuits Corporation (APM)
 arm     ARM Ltd.
@@ -22,6 +23,7 @@ auo	AU Optronics Corporation
 avago   Avago Technologies
 bosch   Bosch Sensortec GmbH
 brcm    Broadcom Corporation
+buffalo Buffalo, Inc.
 calxeda Calxeda
 capella Capella Microsystems, Inc
 cavium  Cavium, Inc.
@@ -33,15 +35,18 @@ cortina	Cortina Systems, Inc.
 crystalfontz    Crystalfontz America, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
 davicom DAVICOM Semiconductor, Inc.
-dlink   D-Link Systems, Inc.
 denx    Denx Software Engineering
+digi    Digi International Inc.
+dlink   D-Link Corporation
 dmo     Data Modul AG
+ebv     EBV Elektronik
 edt     Emerging Display Technologies
 emmicro EM Microelectronic
 epfl    Ecole Polytechnique Fédérale de Lausanne
 epson   Seiko Epson Corp.
 est     ESTeem Wireless Modems
 eukrea  Eukréa Electromatique
+excito  Excito
 fsl     Freescale Semiconductor
 GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gef     GE Fanuc Intelligent Platforms Embedded Systems, Inc.
@@ -53,26 +58,36 @@ haoyu	Haoyu Microelectronic Co. Ltd.
 hisilicon       Hisilicon Limited.
 honeywell       Honeywell
 hp      Hewlett Packard
+i2se    I2SE GmbH
 ibm     International Business Machines (IBM)
 idt     Integrated Device Technologies, Inc.
+iom     Iomega Corporation
 img     Imagination Technologies Ltd.
 intel   Intel Corporation
 intercontrol    Inter Control Group
+isee    ISEE 2007 S.L.
 isl     Intersil
 karo    Ka-Ro electronics GmbH
+keymile Keymile GmbH
 lacie   LaCie
 lantiq  Lantiq Semiconductor
 lg      LG Corporation
 linux   Linux-specific binding
 lsi     LSI Corp. (LSI Logic)
+lltc    Linear Technology Corporation
 marvell Marvell Technology Group Ltd.
 maxim   Maxim Integrated Products
+micrel  Micrel Inc.
 microchip       Microchip Technology Inc.
 mosaixtech      Mosaix Technologies, Inc.
 moxa    Moxa
+mpl     MPL AG
+mundoreader     Mundo Reader S.L.
+mxicy   Macronix International Co., Ltd.
 national        National Semiconductor
 neonode         Neonode Inc.
 netgear NETGEAR
+newhaven        Newhaven Display International
 nintendo        Nintendo
 nokia   Nokia
 nvidia  NVIDIA
@@ -82,10 +97,13 @@ opencores	OpenCores.org
 panasonic       Panasonic Corporation
 phytec  PHYTEC Messtechnik GmbH
 picochip        Picochip Ltd
+plathome        Plat'Home Co., Ltd.
 powervr PowerVR (deprecated, use img)
 qca     Qualcomm Atheros, Inc.
 qcom    Qualcomm Technologies, Inc
 qnap    QNAP Systems, Inc.
+radxa   Radxa
+raidsonic       RaidSonic Technology GmbH
 ralink  Mediatek/Ralink Technology Corp.
 ramtron Ramtron International
 realtek Realtek Semiconductor Corp.
@@ -95,6 +113,7 @@ rockchip	Fuzhou Rockchip Electronics Co., Ltd
 samsung Samsung Semiconductor
 sbs     Smart Battery System
 schindler       Schindler
+seagate Seagate Technology PLC
 sil     Silicon Image
 silabs  Silicon Laboratories
 simtek
@@ -109,9 +128,12 @@ stericsson	ST-Ericsson
 synology        Synology, Inc.
 ti      Texas Instruments
 tlm     Trusted Logic Mobility
+toradex Toradex AG
 toshiba Toshiba Corporation
 toumaz  Toumaz
+usi     Universal Scientifc Industrial Co., Ltd.
 v3      V3 Semiconductor
+variscite       Variscite Ltd.
 via     VIA Technologies, Inc.
 voipac  Voipac Technologies s.r.o.
 winbond Winbond Electronics corp.
@@ -119,3 +141,5 @@ wlf	Wolfson Microelectronics
 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/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
index ccccc19e2573..acd5668b1ce1 100644
--- a/Documentation/devicetree/bindings/video/hdmi-connector.txt
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -7,6 +7,7 @@ Required properties:
 
 Optional properties:
 - label: a symbolic name for the connector
+- hpd-gpios: HPD GPIO number
 
 Required nodes:
 - Video port for HDMI input
diff --git a/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
new file mode 100644
index 000000000000..1a1e653e5407
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/lgphilips,lb035q02.txt
@@ -0,0 +1,33 @@
+LG.Philips LB035Q02 Panel
+=========================
+
+Required properties:
+- compatible: "lgphilips,lb035q02"
+- enable-gpios: panel enable gpio
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+-------
+
+lcd-panel: panel@0 {
+        compatible = "lgphilips,lb035q02";
+        reg = <0>;
+        spi-max-frequency = <100000>;
+        spi-cpol;
+        spi-cpha;
+
+        label = "lcd";
+
+        enable-gpios = <&gpio7 7 0>;
+
+        port {
+                lcd_in: endpoint {
+                        remote-endpoint = <&dpi_out>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/panel-dpi.txt b/Documentation/devicetree/bindings/video/panel-dpi.txt
new file mode 100644
index 000000000000..a40180b05bab
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dpi.txt
@@ -0,0 +1,45 @@
+Generic MIPI DPI Panel
+======================
+
+Required properties:
+- compatible: "panel-dpi"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: panel enable gpio
+
+Required nodes:
+- "panel-timing" containing video timings
+  (Documentation/devicetree/bindings/video/display-timing.txt)
+- Video port for DPI input
+
+Example
+-------
+
+lcd0: display@0 {
+        compatible = "samsung,lte430wq-f0c", "panel-dpi";
+        label = "lcd";
+
+        port {
+            lcd_in: endpoint {
+                    remote-endpoint = <&dpi_out>;
+            };
+        };
+
+        panel-timing {
+                clock-frequency = <9200000>;
+                hactive = <480>;
+                vactive = <272>;
+                hfront-porch = <8>;
+                hback-porch = <4>;
+                hsync-len = <41>;
+                vback-porch = <2>;
+                vfront-porch = <4>;
+                vsync-len = <10>;
+
+                hsync-active = <0>;
+                vsync-active = <0>;
+                de-active = <1>;
+                pixelclk-active = <1>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index 000000000000..0cc8981e9d49
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,43 @@
+SHARP LS037V7DW01 TFT-LCD panel
+===================================
+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin.
+  This pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin.
+  This pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+  ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure to change configuration
+between QVGA and VGA mode and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are considered optional with holes
+in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+        compatible = "sharp,ls037v7dw01";
+        power-supply = <&lcd_3v3>;
+        enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>;    /* gpio152, lcd INI */
+        reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>;     /* gpio155, lcd RESB */
+        mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH        /* gpio154, lcd MO */
+                      &gpio1 2 GPIO_ACTIVE_HIGH         /* gpio2, lcd LR */
+                      &gpio1 3 GPIO_ACTIVE_HIGH>;       /* gpio3, lcd UD */
+
+        port {
+                lcd_in: endpoint {
+                        remote-endpoint = <&dpi_out>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
index f85d6fcfa705..b8c29fbd1fbb 100644
--- a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -109,3 +109,7 @@ Required properties:
 
 Optional nodes:
 - Video port for HDMI output
+
+HDMI Endpoint optional properties:
+- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-,
+  D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7)
diff --git a/Documentation/devicetree/bindings/video/ti,omap5-dss.txt b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
new file mode 100644
index 000000000000..38ffc8fcd816
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap5-dss.txt
@@ -0,0 +1,96 @@
+Texas Instruments OMAP5 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap5-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap5-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap5-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap5-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+  DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap5-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+       'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
+
+HDMI Endpoint optional properties:
+- lanes: list of 8 pin numbers for the HDMI lanes: CLK+, CLK-, D0+, D0-,
+  D1+, D1-, D2+, D2-. (default: 0,1,2,3,4,5,6,7)
diff --git a/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
new file mode 100644
index 000000000000..7175dc3740ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/toppoly,td028ttec1.txt
@@ -0,0 +1,30 @@
+Toppoly TD028TTEC1 Panel
+========================
+
+Required properties:
+- compatible: "toppoly,td028ttec1"
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+-------
+
+lcd-panel: td028ttec1@0 {
+        compatible = "toppoly,td028ttec1";
+        reg = <0>;
+        spi-max-frequency = <100000>;
+        spi-cpol;
+        spi-cpha;
+
+        label = "lcd";
+        port {
+                lcd_in: endpoint {
+                        remote-endpoint = <&dpi_out>;
+                };
+        };
+};
+
diff --git a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
new file mode 100644
index 000000000000..ec6d62975162
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
@@ -0,0 +1,33 @@
+TPO TD043MTEA1 Panel
+====================
+
+Required properties:
+- compatible: "tpo,td043mtea1"
+- reset-gpios: panel reset gpio
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+-------
+
+lcd-panel: panel@0 {
+        compatible = "tpo,td043mtea1";
+        reg = <0>;
+        spi-max-frequency = <100000>;
+        spi-cpol;
+        spi-cpha;
+
+        label = "lcd";
+
+        reset-gpios = <&gpio7 7 0>;
+
+        port {
+                lcd_in: endpoint {
+                        remote-endpoint = <&dpi_out>;
+                };
+        };
+};
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/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt
index 505e71172ae7..67a4087d53f9 100644
--- a/Documentation/dma-buf-sharing.txt
+++ b/Documentation/dma-buf-sharing.txt
@@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following steps:
 
    Exporting modules which do not wish to provide any specific name may use the
    helper define 'dma_buf_export()', with the same arguments as above, but
-   without the last argument; a __FILE__ pre-processor directive will be
+   without the last argument; a KBUILD_MODNAME pre-processor directive will be
    inserted in place of 'exp_name' instead.
 
 2. Userspace gets a handle to pass around to potential buffer-users
@@ -217,7 +217,7 @@ NOTES:
     and then allow further {map,unmap}_dma_buf operations from any buffer-user
     from the migrated backing-storage.
 
-   If the exporter cannot fulfil the backing-storage constraints of the new
+   If the exporter cannot fulfill the backing-storage constraints of the new
    buffer-user device as requested, dma_buf_attach() would return an error to
    denote non-compatibility of the new buffer-sharing request with the current
    buffer.
@@ -352,7 +352,7 @@ Being able to mmap an export dma-buf buffer object has 2 main use-cases:
 
    No special interfaces, userspace simply calls mmap on the dma-buf fd.
 
-2. Supporting existing mmap interfaces in exporters
+2. Supporting existing mmap interfaces in importers
 
    Similar to the motivation for kernel cpu access it is again important that
    the userspace code of a given importing subsystem can use the same interfaces
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 4f7897e99cba..1525e30483fd 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -236,6 +236,9 @@ certainly invest a bit more effort into libata core layer).
 MEM
   devm_kzalloc()
   devm_kfree()
+  devm_kmemdup()
+  devm_get_free_pages()
+  devm_free_pages()
 
 IIO
   devm_iio_device_alloc()
@@ -308,3 +311,15 @@ SLAVE DMA ENGINE
 
 SPI
   devm_spi_register_master()
+
+GPIO
+  devm_gpiod_get()
+  devm_gpiod_get_index()
+  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/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 46325eb2ea76..9417871b8758 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -321,7 +321,7 @@ nullarbor:~ # echo -n 'func svc_process -p' >
 nullarbor:~ # echo -n 'format "nfsd: READ" +p' >
                                 <debugfs>/dynamic_debug/control
 
-// enable messages in files of which the pathes include string "usb"
+// enable messages in files of which the paths include string "usb"
 nullarbor:~ # echo -n '*usb* +p' > <debugfs>/dynamic_debug/control
 
 // enable all messages
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index cb4c2cefd45a..73fff13e848f 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -550,7 +550,7 @@ installs itself as:
         /sys/devices/systm/edac/test-instance
 
 in this directory are various controls, a symlink and one or more 'instance'
-directorys.
+directories.
 
 The standard default controls are:
 
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index c628788d5b47..7747024d3bb7 100644
--- a/Documentation/efi-stub.txt
+++ b/Documentation/efi-stub.txt
@@ -1,13 +1,21 @@
                           The EFI Boot Stub
                      ---------------------------
 
-On the x86 platform, a bzImage can masquerade as a PE/COFF image,
-thereby convincing EFI firmware loaders to load it as an EFI
-executable. The code that modifies the bzImage header, along with the
-EFI-specific entry point that the firmware loader jumps to are
-collectively known as the "EFI boot stub", and live in
+On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade
+as a PE/COFF image, thereby convincing EFI firmware loaders to load
+it as an EFI executable. The code that modifies the bzImage header,
+along with the EFI-specific entry point that the firmware loader
+jumps to are collectively known as the "EFI boot stub", and live in
 arch/x86/boot/header.S and arch/x86/boot/compressed/eboot.c,
-respectively.
+respectively. For ARM the EFI stub is implemented in
+arch/arm/boot/compressed/efi-header.S and
+arch/arm/boot/compressed/efi-stub.c. EFI stub code that is shared
+between architectures is in drivers/firmware/efi/efi-stub-helper.c.
+
+For arm64, there is no compressed kernel support, so the Image itself
+masquerades as a PE/COFF image and the EFI stub is linked into the
+kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
+and arch/arm64/kernel/efi-stub.c.
 
 By using the EFI boot stub it's possible to boot a Linux kernel
 without the use of a conventional EFI boot loader, such as grub or
@@ -23,7 +31,10 @@ The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
 System Partition (ESP) and renamed with the extension ".efi". Without
 the extension the EFI firmware loader will refuse to execute it. It's
 not possible to execute bzImage.efi from the usual Linux file systems
-because EFI firmware doesn't have support for them.
+because EFI firmware doesn't have support for them. For ARM the
+arch/arm/boot/zImage should be copied to the system partition, and it
+may not need to be renamed. Similarly for arm64, arch/arm64/boot/Image
+should be copied but not necessarily renamed.
 
 
 **** Passing kernel parameters from the EFI shell
@@ -63,3 +74,11 @@ Notice how bzImage.efi can be specified with a relative path. That's
 because the image we're executing is interpreted by the EFI shell,
 which understands relative paths, whereas the rest of the command line
 is passed to bzImage.efi.
+
+
+**** The "dtb=" option
+
+For the ARM and arm64 architectures, we also need to be able to provide a
+device tree to the kernel. This is done with the "dtb=" command line option,
+and is processed in the same manner as the "initrd=" option that is
+described above.
diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt
index e9f5daccbd02..4e30ebaa9e5b 100644
--- a/Documentation/email-clients.txt
+++ b/Documentation/email-clients.txt
@@ -201,20 +201,15 @@ To beat some sense out of the internal editor, do this:
 
 - Edit your Thunderbird config settings so that it won't use format=flowed.
   Go to "edit->preferences->advanced->config editor" to bring up the
-  thunderbird's registry editor, and set "mailnews.send_plaintext_flowed" to
-  "false".
+  thunderbird's registry editor.
 
-- Disable HTML Format: Set "mail.identity.id1.compose_html" to "false".
+- Set "mailnews.send_plaintext_flowed" to "false"
 
-- Enable "preformat" mode: Set "editor.quotesPreformatted" to "true".
+- Set "mailnews.wraplength" from "72" to "0"
 
-- Enable UTF8: Set "prefs.converted-to-utf8" to "true".
+- "View" > "Message Body As" > "Plain Text"
 
-- Install the "toggle wordwrap" extension.  Download the file from:
-    https://addons.mozilla.org/thunderbird/addon/2351/
-  Then go to "tools->add ons", select "install" at the bottom of the screen,
-  and browse to where you saved the .xul file.  This adds an "Enable
-  Wordwrap" entry under the Options menu of the message composer.
+- "View" > "Character Encoding" > "Unicode (UTF-8)"
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 TkRat (GUI)
diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt
index 8d17aebd2648..187f3b3ccb6c 100644
--- a/Documentation/fb/sm501.txt
+++ b/Documentation/fb/sm501.txt
@@ -3,7 +3,7 @@ Configuration:
 You can pass the following kernel command line options to sm501 videoframebuffer:
 
         sm501fb.bpp=    SM501 Display driver:
-                        Specifiy bits-per-pixel if not specified by 'mode'
+                        Specify bits-per-pixel if not specified by 'mode'
 
         sm501fb.mode=   SM501 Display driver:
                         Specify resolution as
diff --git a/Documentation/fb/sstfb.txt b/Documentation/fb/sstfb.txt
index 550ca775a4cb..13db1075e4a5 100644
--- a/Documentation/fb/sstfb.txt
+++ b/Documentation/fb/sstfb.txt
@@ -10,7 +10,7 @@ Introduction
           The main page is located at <http://sstfb.sourceforge.net>, and if
         you want the latest version, check out the CVS, as the driver is a work
         in progress, I feel uncomfortable with releasing tarballs of something
-        not completely working...Don't worry, it's still more than useable
+        not completely working...Don't worry, it's still more than usable
         (I eat my own dog food)
 
           Please read the Bug section, and report any success or failure to me
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,
-                        loff_t offset, unsigned long nr_segs);
+        int (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset);
         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),
-                             |            if n < MAX_DIR_HASH_DEPTH / 2,
+                             ,- 2^(n + dir_level),
+                             |        if n + dir_level < MAX_DIR_HASH_DEPTH / 2,
   # of buckets in level #n = |
-                             `- 2^((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1),
-                                          Otherwise
+                             `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1),
+                                      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/proc.txt b/Documentation/filesystems/proc.txt
index 8b9cd8eb3f91..ddc531a74d04 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -234,7 +234,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7)
  ShdPnd                      bitmap of shared pending signals for the process
  SigBlk                      bitmap of blocked signals
  SigIgn                      bitmap of ignored signals
- SigCgt                      bitmap of catched signals
+ SigCgt                      bitmap of caught signals
  CapInh                      bitmap of inheritable capabilities
  CapPrm                      bitmap of permitted capabilities
  CapEff                      bitmap of effective capabilities
@@ -300,7 +300,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
   pending       bitmap of pending signals
   blocked       bitmap of blocked signals
   sigign        bitmap of ignored signals
-  sigcatch      bitmap of catched signals
+  sigcatch      bitmap of caught signals
   wchan         address where process went to sleep
   0             (place holder)
   0             (place holder)
@@ -854,7 +854,8 @@ WritebackTmp: Memory used by FUSE for temporary writeback buffers
               if strict overcommit accounting is enabled (mode 2 in
               'vm.overcommit_memory').
               The CommitLimit is calculated with the following formula:
-              CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap
+              CommitLimit = ([total RAM pages] - [total huge TLB pages]) *
+                             overcommit_ratio / 100 + [total swap pages]
               For example, on a system with 1G of physical RAM and 7G
               of swap with a `vm.overcommit_ratio` of 30 it would
               yield a CommitLimit of 7.3G.
@@ -1245,8 +1246,9 @@ second).  The meanings of the columns are as follows, from left to right:
 
 The "intr" line gives counts of interrupts  serviced since boot time, for each
 of the  possible system interrupts.   The first  column  is the  total of  all
-interrupts serviced; each  subsequent column is the  total for that particular
-interrupt.
+interrupts serviced  including  unnumbered  architecture specific  interrupts;
+each  subsequent column is the  total for that particular numbered interrupt.
+Unnumbered interrupts are not shown, only summed into the total.
 
 The "ctxt" line gives the total number of context switches across all CPUs.
 
diff --git a/Documentation/filesystems/seq_file.txt b/Documentation/filesystems/seq_file.txt
index a1e2e0dda907..1fe0ccb1af55 100644
--- a/Documentation/filesystems/seq_file.txt
+++ b/Documentation/filesystems/seq_file.txt
@@ -54,6 +54,15 @@ how the mechanism works without getting lost in other details.  (Those
 wanting to see the full source for this module can find it at
 http://lwn.net/Articles/22359/).
 
+Deprecated create_proc_entry
+
+Note that the above article uses create_proc_entry which was removed in
+kernel 3.10. Current versions require the following update
+
+-       entry = create_proc_entry("sequence", 0, NULL);
+-       if (entry)
+-               entry->proc_fops = &ct_file_ops;
++       entry = proc_create("sequence", 0, NULL, &ct_file_ops);
 
 The iterator interface
 
diff --git a/Documentation/filesystems/sharedsubtree.txt b/Documentation/filesystems/sharedsubtree.txt
index 4ede421c9687..32a173dd3158 100644
--- a/Documentation/filesystems/sharedsubtree.txt
+++ b/Documentation/filesystems/sharedsubtree.txt
@@ -727,7 +727,7 @@ replicas continue to be exactly same.
                           mkdir -p /tmp/m3
                           mount --rbind /root /tmp/m3
 
-                          I wont' draw the tree..but it has 24 vfsmounts
+                          I won't draw the tree..but it has 24 vfsmounts
 
 
                 at step i the number of vfsmounts is V[i] = i*V[i-1].
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index 4a93e98b290a..ce1126aceed8 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -172,6 +172,11 @@ nfs=stale_rw|nostale_ro
                 To maintain backward compatibility, '-o nfs' is also accepted,
                 defaulting to stale_rw
 
+dos1xfloppy  -- If set, use a fallback default BIOS Parameter Block
+                configuration, determined by backing device size. These static
+                parameters match defaults assumed by DOS 1.x for 160 kiB,
+                180 kiB, 320 kiB, and 360 kiB floppies and floppy images.
+
 
 <bool>: 0,1,yes,no,true,false
 
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,
-                        loff_t offset, unsigned long nr_segs);
+        ssize_t (*direct_IO)(int, struct kiocb *, struct iov_iter *iter, loff_t offset);
         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/gpio/consumer.txt b/Documentation/gpio/consumer.txt
index 09854fe59307..d8abfc31abbe 100644
--- a/Documentation/gpio/consumer.txt
+++ b/Documentation/gpio/consumer.txt
@@ -41,7 +41,7 @@ Both functions return either a valid GPIO descriptor, or an error code checkable
 with IS_ERR() (they will never return a NULL pointer). -ENOENT will be returned
 if and only if no GPIO has been assigned to the device/function/index triplet,
 other error codes are used for cases where a GPIO has been assigned but an error
-occured while trying to acquire it. This is useful to discriminate between mere
+occurred while trying to acquire it. This is useful to discriminate between mere
 errors and an absence of GPIO for optional GPIO parameters.
 
 Device-managed variants of these functions are also defined:
diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt
index f73cc7b5dc85..fa9a0a8b3734 100644
--- a/Documentation/gpio/driver.txt
+++ b/Documentation/gpio/driver.txt
@@ -73,6 +73,65 @@ The IRQ portions of the GPIO block are implemented using an irqchip, using
 the header <linux/irq.h>. So basically such a driver is utilizing two sub-
 systems simultaneously: gpio and irq.
 
+GPIO irqchips usually fall in one of two categories:
+
+* CHAINED GPIO irqchips: these are usually the type that is embedded on
+  an SoC. This means that there is a fast IRQ handler for the GPIOs that
+  gets called in a chain from the parent IRQ handler, most typically the
+  system interrupt controller. This means the GPIO irqchip is registered
+  using irq_set_chained_handler() or the corresponding
+  gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
+  handler will be called immediately from the parent irqchip, while
+  holding the IRQs disabled. The GPIO irqchip will then end up calling
+  something like this sequence in its interrupt handler:
+
+  static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
+      chained_irq_enter(...);
+      generic_handle_irq(...);
+      chained_irq_exit(...);
+
+  Chained GPIO irqchips typically can NOT set the .can_sleep flag on
+  struct gpio_chip, as everything happens directly in the callbacks.
+
+* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
+  other GPIO irqchip residing on the other side of a sleeping bus. Of course
+  such drivers that need slow bus traffic to read out IRQ status and similar,
+  traffic which may in turn incur other IRQs to happen, cannot be handled
+  in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
+  thread and then mask the parent IRQ line until the interrupt is handled
+  by the driver. The hallmark of this driver is to call something like
+  this in its interrupt handler:
+
+  static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
+      ...
+      handle_nested_irq(irq);
+
+  The hallmark of threaded GPIO irqchips is that they set the .can_sleep
+  flag on struct gpio_chip to true, indicating that this chip may sleep
+  when accessing the GPIOs.
+
+To help out in handling the set-up and management of GPIO irqchips and the
+associated irqdomain and resource allocation callbacks, the gpiolib has
+some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
+symbol:
+
+* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
+  the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
+  need to embed the gpio_chip in its state container and obtain a pointer
+  to the container using container_of().
+  (See Documentation/driver-model/design-patterns.txt)
+
+* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
+  gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
+  data. (Notice handler data, since the irqchip data is likely used by the
+  parent irqchip!) This is for the chained type of chip.
+
+To use the helpers please keep the following in mind:
+
+- Make sure to assign all relevant members of the struct gpio_chip so that
+  the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
+  properly.
+
 It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
 if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
 irq_chip are orthogonal, and offering their services independent of each
diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt
index ee6593608c8e..54c8f9706a95 100644
--- a/Documentation/hid/uhid.txt
+++ b/Documentation/hid/uhid.txt
@@ -125,7 +125,7 @@ the request was handled successfully.
 
 read()
 ------
-read() will return a queued ouput report. These output reports can be of type
+read() will return a queued output report. These output reports can be of type
 UHID_START, UHID_STOP, UHID_OPEN, UHID_CLOSE, UHID_OUTPUT or UHID_OUTPUT_EV. No
 reaction is required to any of them but you should handle them according to your
 needs. Only UHID_OUTPUT and UHID_OUTPUT_EV have payloads.
diff --git a/Documentation/hsi.txt b/Documentation/hsi.txt
new file mode 100644
index 000000000000..6ac6cd51852a
--- /dev/null
+++ b/Documentation/hsi.txt
@@ -0,0 +1,75 @@
+HSI - High-speed Synchronous Serial Interface
+
+1. Introduction
+~~~~~~~~~~~~~~~
+
+High Speed Syncronous Interface (HSI) is a fullduplex, low latency protocol,
+that is optimized for die-level interconnect between an Application Processor
+and a Baseband chipset. It has been specified by the MIPI alliance in 2003 and
+implemented by multiple vendors since then.
+
+The HSI interface supports full duplex communication over multiple channels
+(typically 8) and is capable of reaching speeds up to 200 Mbit/s.
+
+The serial protocol uses two signals, DATA and FLAG as combined data and clock
+signals and an additional READY signal for flow control. An additional WAKE
+signal can be used to wakeup the chips from standby modes. The signals are
+commonly prefixed by AC for signals going from the application die to the
+cellular die and CA for signals going the other way around.
+
++------------+                                 +---------------+
+|  Cellular  |                                 |  Application  |
+|    Die     |                                 |      Die      |
+|            | - - - - - - CAWAKE - - - - - - >|               |
+|           T|------------ CADATA ------------>|R              |
+|           X|------------ CAFLAG ------------>|X              |
+|            |<----------- ACREADY ------------|               |
+|            |                                 |               |
+|            |                                 |               |
+|            |< - - - - -  ACWAKE - - - - - - -|               |
+|           R|<----------- ACDATA -------------|T              |
+|           X|<----------- ACFLAG -------------|X              |
+|            |------------ CAREADY ----------->|               |
+|            |                                 |               |
+|            |                                 |               |
++------------+                                 +---------------+
+
+2. HSI Subsystem in Linux
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+In the Linux kernel the hsi subsystem is supposed to be used for HSI devices.
+The hsi subsystem contains drivers for hsi controllers including support for
+multi-port controllers and provides a generic API for using the HSI ports.
+
+It also contains HSI client drivers, which make use of the generic API to
+implement a protocol used on the HSI interface. These client drivers can
+use an arbitrary number of channels.
+
+3. hsi-char Device
+~~~~~~~~~~~~~~~~~~
+
+Each port automatically registers a generic client driver called hsi_char,
+which provides a charecter device for userspace representing the HSI port.
+It can be used to communicate via HSI from userspace. Userspace may
+configure the hsi_char device using the following ioctl commands:
+
+* HSC_RESET:
+ - flush the HSI port
+
+* HSC_SET_PM
+ - enable or disable the client.
+
+* HSC_SEND_BREAK
+ - send break
+
+* HSC_SET_RX
+ - set RX configuration
+
+* HSC_GET_RX
+ - get RX configuration
+
+* HSC_SET_TX
+ - set TX configuration
+
+* HSC_GET_TX
+ - get TX configuration
diff --git a/Documentation/hwmon/emc1403 b/Documentation/hwmon/emc1403
new file mode 100644
index 000000000000..a869b0ef6a9d
--- /dev/null
+++ b/Documentation/hwmon/emc1403
@@ -0,0 +1,59 @@
+Kernel driver emc1403
+=====================
+
+Supported chips:
+  * SMSC / Microchip EMC1402, EMC1412
+    Addresses scanned: I2C 0x18, 0x1c, 0x29, 0x4c, 0x4d, 0x5c
+    Prefix: 'emc1402'
+    Datasheets:
+        http://ww1.microchip.com/downloads/en/DeviceDoc/1412.pdf
+        http://ww1.microchip.com/downloads/en/DeviceDoc/1402.pdf
+  * SMSC / Microchip EMC1403, EMC1404, EMC1413, EMC1414
+    Addresses scanned: I2C 0x18, 0x29, 0x4c, 0x4d
+    Prefix: 'emc1403', 'emc1404'
+    Datasheets:
+        http://ww1.microchip.com/downloads/en/DeviceDoc/1403_1404.pdf
+        http://ww1.microchip.com/downloads/en/DeviceDoc/1413_1414.pdf
+  * SMSC / Microchip EMC1422
+    Addresses scanned: I2C 0x4c
+    Prefix: 'emc1422'
+    Datasheet:
+        http://ww1.microchip.com/downloads/en/DeviceDoc/1422.pdf
+  * SMSC / Microchip EMC1423, EMC1424
+    Addresses scanned: I2C 0x4c
+    Prefix: 'emc1423', 'emc1424'
+    Datasheet:
+        http://ww1.microchip.com/downloads/en/DeviceDoc/1423_1424.pdf
+
+Author:
+    Kalhan Trisal <kalhan.trisal@intel.com
+
+
+Description
+-----------
+
+The Standard Microsystems Corporation (SMSC) / Microchip EMC14xx chips
+contain up to four temperature sensors. EMC14x2 support two sensors
+(one internal, one external). EMC14x3 support three sensors (one internal,
+two external), and EMC14x4 support four sensors (one internal, three
+external).
+
+The chips implement three limits for each sensor: low (tempX_min), high
+(tempX_max) and critical (tempX_crit.) The chips also implement an
+hysteresis mechanism which applies to all limits. The relative difference
+is stored in a single register on the chip, which means that the relative
+difference between the limit and its hysteresis is always the same for
+all three limits.
+
+This implementation detail implies the following:
+* When setting a limit, its hysteresis will automatically follow, the
+  difference staying unchanged. For example, if the old critical limit
+  was 80 degrees C, and the hysteresis was 75 degrees C, and you change
+  the critical limit to 90 degrees C, then the hysteresis will
+  automatically change to 85 degrees C.
+* The hysteresis values can't be set independently. We decided to make
+  only temp1_crit_hyst writable, while all other hysteresis attributes
+  are read-only. Setting temp1_crit_hyst writes the difference between
+  temp1_crit_hyst and temp1_crit into the chip, and the same relative
+  hysteresis applies automatically to all other limits.
+* The limits should be set before the hysteresis.
diff --git a/Documentation/hwmon/hwmon-kernel-api.txt b/Documentation/hwmon/hwmon-kernel-api.txt
new file mode 100644
index 000000000000..2ecdbfc85ecf
--- /dev/null
+++ b/Documentation/hwmon/hwmon-kernel-api.txt
@@ -0,0 +1,107 @@
+The Linux Hardware Monitoring kernel API.
+=========================================
+
+Guenter Roeck
+
+Introduction
+------------
+
+This document describes the API that can be used by hardware monitoring
+drivers that want to use the hardware monitoring framework.
+
+This document does not describe what a hardware monitoring (hwmon) Driver or
+Device is. It also does not describe the API which can be used by user space
+to communicate with a hardware monitoring device. If you want to know this
+then please read the following file: Documentation/hwmon/sysfs-interface.
+
+For additional guidelines on how to write and improve hwmon drivers, please
+also read Documentation/hwmon/submitting-patches.
+
+The API
+-------
+Each hardware monitoring driver must #include <linux/hwmon.h> and, in most
+cases, <linux/hwmon-sysfs.h>. linux/hwmon.h declares the following
+register/unregister functions:
+
+struct device *hwmon_device_register(struct device *dev);
+struct device *
+hwmon_device_register_with_groups(struct device *dev, const char *name,
+                                  void *drvdata,
+                                  const struct attribute_group **groups);
+
+struct device *
+devm_hwmon_device_register_with_groups(struct device *dev,
+                                       const char *name, void *drvdata,
+                                       const struct attribute_group **groups);
+
+void hwmon_device_unregister(struct device *dev);
+void devm_hwmon_device_unregister(struct device *dev);
+
+hwmon_device_register registers a hardware monitoring device. The parameter
+of this function is a pointer to the parent device.
+This function returns a pointer to the newly created hardware monitoring device
+or PTR_ERR for failure. If this registration function is used, hardware
+monitoring sysfs attributes are expected to have been created and attached to
+the parent device prior to calling hwmon_device_register. A name attribute must
+have been created by the caller.
+
+hwmon_device_register_with_groups is similar to hwmon_device_register. However,
+it has additional parameters. The name parameter is a pointer to the hwmon
+device name. The registration function wil create a name sysfs attribute
+pointing to this name. The drvdata parameter is the pointer to the local
+driver data.  hwmon_device_register_with_groups will attach this pointer
+to the newly allocated hwmon device. The pointer can be retrieved by the driver
+using dev_get_drvdata() on the hwmon device pointer. The groups parameter is
+a pointer to a list of sysfs attribute groups. The list must be NULL terminated.
+hwmon_device_register_with_groups creates the hwmon device with name attribute
+as well as all sysfs attributes attached to the hwmon device.
+
+devm_hwmon_device_register_with_groups is similar to
+hwmon_device_register_with_groups. However, it is device managed, meaning the
+hwmon device does not have to be removed explicitly by the removal function.
+
+hwmon_device_unregister deregisters a registered hardware monitoring device.
+The parameter of this function is the pointer to the registered hardware
+monitoring device structure. This function must be called from the driver
+remove function if the hardware monitoring device was registered with
+hwmon_device_register or with hwmon_device_register_with_groups.
+
+devm_hwmon_device_unregister does not normally have to be called. It is only
+needed for error handling, and only needed if the driver probe fails after
+the call to devm_hwmon_device_register_with_groups.
+
+The header file linux/hwmon-sysfs.h provides a number of useful macros to
+declare and use hardware monitoring sysfs attributes.
+
+In many cases, you can use the exsting define DEVICE_ATTR to declare such
+attributes. This is feasible if an attribute has no additional context. However,
+in many cases there will be additional information such as a sensor index which
+will need to be passed to the sysfs attribute handling function.
+
+SENSOR_DEVICE_ATTR and SENSOR_DEVICE_ATTR_2 can be used to define attributes
+which need such additional context information. SENSOR_DEVICE_ATTR requires
+one additional argument, SENSOR_DEVICE_ATTR_2 requires two.
+
+SENSOR_DEVICE_ATTR defines a struct sensor_device_attribute variable.
+This structure has the following fields.
+
+struct sensor_device_attribute {
+        struct device_attribute dev_attr;
+        int index;
+};
+
+You can use to_sensor_dev_attr to get the pointer to this structure from the
+attribute read or write function. Its parameter is the device to which the
+attribute is attached.
+
+SENSOR_DEVICE_ATTR_2 defines a struct sensor_device_attribute_2 variable,
+which is defined as follows.
+
+struct sensor_device_attribute_2 {
+        struct device_attribute dev_attr;
+        u8 index;
+        u8 nr;
+};
+
+Use to_sensor_dev_attr_2 to get the pointer to this structure. Its parameter
+is the device to which the attribute is attached.
diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42
index 868d74d6b773..f3893f7440de 100644
--- a/Documentation/hwmon/jc42
+++ b/Documentation/hwmon/jc42
@@ -5,9 +5,12 @@ Supported chips:
   * Analog Devices ADT7408
     Datasheets:
         http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf
-  * Atmel AT30TS00
+  * Atmel AT30TS00, AT30TS002A/B, AT30TSE004A
     Datasheets:
         http://www.atmel.com/Images/doc8585.pdf
+        http://www.atmel.com/Images/doc8711.pdf
+        http://www.atmel.com/Images/Atmel-8852-SEEPROM-AT30TSE002A-Datasheet.pdf
+        http://www.atmel.com/Images/Atmel-8868-DTS-AT30TSE004A-Datasheet.pdf
   * IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2
     Datasheets:
         http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf
@@ -34,12 +37,13 @@ Supported chips:
     Datasheet:
         http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF
         http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF
-  * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000
+  * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS2004, STTS3000
     Datasheets:
-        http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf
-        http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf
-        http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf
-        http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf
+        http://www.st.com/web/en/resource/technical/document/datasheet/CD00157556.pdf
+        http://www.st.com/web/en/resource/technical/document/datasheet/CD00157558.pdf
+        http://www.st.com/web/en/resource/technical/document/datasheet/CD00266638.pdf
+        http://www.st.com/web/en/resource/technical/document/datasheet/CD00225278.pdf
+        http://www.st.com/web/en/resource/technical/document/datasheet/DM00076709.pdf
   * JEDEC JC 42.4 compliant temperature sensor chips
     Datasheet:
         http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf
diff --git a/Documentation/hwmon/lm77 b/Documentation/hwmon/lm77
index 57c3a46d6370..bfc915fe3639 100644
--- a/Documentation/hwmon/lm77
+++ b/Documentation/hwmon/lm77
@@ -18,5 +18,21 @@ sensor incorporates a band-gap type temperature sensor,
 10-bit ADC, and a digital comparator with user-programmable upper
 and lower limit values.
 
-Limits can be set through the Overtemperature Shutdown register and
-Hysteresis register.
+The LM77 implements 3 limits: low (temp1_min), high (temp1_max) and
+critical (temp1_crit.) It also implements an hysteresis mechanism which
+applies to all 3 limits. The relative difference is stored in a single
+register on the chip, which means that the relative difference between
+the limit and its hysteresis is always the same for all 3 limits.
+
+This implementation detail implies the following:
+* When setting a limit, its hysteresis will automatically follow, the
+  difference staying unchanged. For example, if the old critical limit
+  was 80 degrees C, and the hysteresis was 75 degrees C, and you change
+  the critical limit to 90 degrees C, then the hysteresis will
+  automatically change to 85 degrees C.
+* All 3 hysteresis can't be set independently. We decided to make
+  temp1_crit_hyst writable, while temp1_min_hyst and temp1_max_hyst are
+  read-only. Setting temp1_crit_hyst writes the difference between
+  temp1_crit_hyst and temp1_crit into the chip, and the same relative
+  hysteresis applies automatically to the low and high limits.
+* The limits should be set before the hysteresis.
diff --git a/Documentation/hwmon/nct6683 b/Documentation/hwmon/nct6683
new file mode 100644
index 000000000000..c1301d4300cd
--- /dev/null
+++ b/Documentation/hwmon/nct6683
@@ -0,0 +1,57 @@
+Kernel driver nct6683
+=====================
+
+Supported chips:
+  * Nuvoton NCT6683D
+    Prefix: 'nct6683'
+    Addresses scanned: ISA address retrieved from Super I/O registers
+    Datasheet: Available from Nuvoton upon request
+
+Authors:
+        Guenter Roeck <linux@roeck-us.net>
+
+Description
+-----------
+
+This driver implements support for the Nuvoton NCT6683D eSIO chip.
+
+The chips implement up to shared 32 temperature and voltage sensors.
+It supports up to 16 fan rotation sensors and up to 8 fan control engines.
+
+Temperatures are measured in degrees Celsius. Measurement resolution is
+0.5 degrees C.
+
+Voltage sensors (also known as IN sensors) report their values in millivolts.
+
+Fan rotation speeds are reported in RPM (rotations per minute).
+
+Usage Note
+----------
+
+Limit register locations on Intel boards with EC firmware version 1.0
+build date 04/03/13 do not match the register locations in the Nuvoton
+datasheet. Nuvoton confirms that Intel uses a special firmware version
+with different register addresses. The specification describing the Intel
+firmware is held under NDA by Nuvoton and Intel and not available
+to the public.
+
+Some of the register locations can be reverse engineered; others are too
+well hidden. Given this, writing any values from the operating system is
+considered too risky with this firmware and has been disabled. All limits
+must all be written from the BIOS.
+
+The driver has only been tested with the Intel firmware, and by default
+only instantiates on Intel boards. To enable it on non-Intel boards,
+set the 'force' module parameter to 1.
+
+Tested Boards and Firmware Versions
+-----------------------------------
+
+The driver has been reported to work with the following boards and
+firmware versions.
+
+Board           Firmware version
+---------------------------------------------------------------
+Intel DH87RL    NCT6683D EC firmware version 1.0 build 04/03/13
+Intel DH87MC    NCT6683D EC firmware version 1.0 build 04/03/13
+Intel DB85FL    NCT6683D EC firmware version 1.0 build 04/03/13
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/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 79f8257dd790..2cc95ad46604 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -327,6 +327,13 @@ temp[1-*]_max_hyst
                 from the max value.
                 RW
 
+temp[1-*]_min_hyst
+                Temperature hysteresis value for min limit.
+                Unit: millidegree Celsius
+                Must be reported as an absolute temperature, NOT a delta
+                from the min value.
+                RW
+
 temp[1-*]_input Temperature input value.
                 Unit: millidegree Celsius
                 RO
@@ -362,6 +369,13 @@ temp[1-*]_lcrit	Temperature critical min value, typically lower than
                 Unit: millidegree Celsius
                 RW
 
+temp[1-*]_lcrit_hyst
+                Temperature hysteresis value for critical min limit.
+                Unit: millidegree Celsius
+                Must be reported as an absolute temperature, NOT a delta
+                from the critical min value.
+                RW
+
 temp[1-*]_offset
                 Temperature offset which is added to the temperature reading
                 by the chip.
diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index e544c7ff8cfa..90bca6f988e1 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -94,7 +94,7 @@ PS/2 packet format
 
 Note that the device never signals overflow condition.
 
-ALPS Absolute Mode - Protocol Verion 1
+ALPS Absolute Mode - Protocol Version 1
 --------------------------------------
 
  byte 0:  1    0    0    0    1   x9   x8   x7
diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt
index 5602eb71ad5d..e1ae127ed099 100644
--- a/Documentation/input/elantech.txt
+++ b/Documentation/input/elantech.txt
@@ -504,9 +504,12 @@ byte 5:
 * reg_10
 
    bit   7   6   5   4   3   2   1   0
-         0   0   0   0   0   0   0   A
+         0   0   0   0   R   F   T   A
 
          A: 1 = enable absolute tracking
+         T: 1 = enable two finger mode auto correct
+         F: 1 = disable ABS Position Filter
+         R: 1 = enable real hardware resolution
 
 6.2 Native absolute mode 6 byte packet format
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt
index 666c06c5ab0c..0acfddbe2028 100644
--- a/Documentation/input/input.txt
+++ b/Documentation/input/input.txt
@@ -226,7 +226,7 @@ And so on up to js31.
 ~~~~~~~~~~~
   evdev is the generic input event interface. It passes the events
 generated in the kernel straight to the program, with timestamps. The
-API is still evolving, but should be useable now. It's described in
+API is still evolving, but should be usable now. It's described in
 section 5. 
 
   This should be the way for GPM and X to get keyboard and mouse
diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO
index 0091a8215ac1..b61885c35ce1 100644
--- a/Documentation/ja_JP/HOWTO
+++ b/Documentation/ja_JP/HOWTO
@@ -315,7 +315,7 @@ Andrew Morton が Linux-kernel メーリングリストにカーネルリリー�
 もし、3.x.y カーネルが存在しない場合には、番号が一番大きい 3.x が
 最新の安定版カーネルです。
 
-3.x.y は "stable" チーム <stable@kernel.org> でメンテされており、必
+3.x.y は "stable" チーム <stable@vger.kernel.org> でメンテされており、必
 要に応じてリリースされます。通常のリリース期間は 2週間毎ですが、差し迫っ
 た問題がなければもう少し長くなることもあります。セキュリティ関連の問題
 の場合はこれに対してだいたいの場合、すぐにリリースがされます。
diff --git a/Documentation/ja_JP/stable_kernel_rules.txt b/Documentation/ja_JP/stable_kernel_rules.txt
index 14265837c4ce..9dbda9b5d21e 100644
--- a/Documentation/ja_JP/stable_kernel_rules.txt
+++ b/Documentation/ja_JP/stable_kernel_rules.txt
@@ -50,16 +50,16 @@ linux-2.6.29/Documentation/stable_kernel_rules.txt
 
 -stable ツリーにパッチを送付する手続き-
 
- - 上記の規則に従っているかを確認した後に、stable@kernel.org にパッチ
+ - 上記の規則に従っているかを確認した後に、stable@vger.kernel.org にパッチ
    を送る。
  - 送信者はパッチがキューに受け付けられた際には ACK を、却下された場合
    には NAK を受け取る。この反応は開発者たちのスケジュールによって、数
    日かかる場合がある。
  - もし受け取られたら、パッチは他の開発者たちと関連するサブシステムの
    メンテナーによるレビューのために -stable キューに追加される。
- - パッチに stable@kernel.org のアドレスが付加されているときには、それ
+ - パッチに stable@vger.kernel.org のアドレスが付加されているときには、それ
    が Linus のツリーに入る時に自動的に stable チームに email される。
- - セキュリティパッチはこのエイリアス (stable@kernel.org) に送られるべ
+ - セキュリティパッチはこのエイリアス (stable@vger.kernel.org) に送られるべ
    きではなく、代わりに security@kernel.org のアドレスに送られる。
 
 レビューサイクル-
diff --git a/Documentation/java.txt b/Documentation/java.txt
index e6a723281547..418020584ccc 100644
--- a/Documentation/java.txt
+++ b/Documentation/java.txt
@@ -188,6 +188,9 @@ shift
 #define CP_METHODREF 10
 #define CP_INTERFACEMETHODREF 11
 #define CP_NAMEANDTYPE 12
+#define CP_METHODHANDLE 15
+#define CP_METHODTYPE 16
+#define CP_INVOKEDYNAMIC 18
 
 /* Define some commonly used error messages */
 
@@ -242,14 +245,19 @@ void skip_constant(FILE *classfile, u_int16_t *cur)
                 break;
         case CP_CLASS:
         case CP_STRING:
+        case CP_METHODTYPE:
                 seekerr = fseek(classfile, 2, SEEK_CUR);
                 break;
+        case CP_METHODHANDLE:
+                seekerr = fseek(classfile, 3, SEEK_CUR);
+                break;
         case CP_INTEGER:
         case CP_FLOAT:
         case CP_FIELDREF:
         case CP_METHODREF:
         case CP_INTERFACEMETHODREF:
         case CP_NAMEANDTYPE:
+        case CP_INVOKEDYNAMIC:
                 seekerr = fseek(classfile, 4, SEEK_CUR);
                 break;
         case CP_LONG:
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 03e50b4883a8..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
-(mostly) by the __setup() macro and sorted into English Dictionary order
-(defined as ignoring all 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:
-
-        modprobe usbcore blinkenlights=1
-
-Module parameters for modules that are built into the kernel image
-are specified on the kernel command line with the module name plus
-'.' plus parameter name, with '=' and value if appropriate, such as:
-
-        usbcore.blinkenlights=1
+The following is a consolidated list of the kernel parameters as
+implemented by the __setup(), core_param() and module_param() macros
+and sorted into English Dictionary order (defined as ignoring all
+punctuation and sorting digits before letters in a case insensitive
+manner), and with descriptions where known.
+
+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
+parameter gets passed to init: parameters with '=' go into init's
+environment, others are passed as command line arguments to init.
+Everything after "--" is passed as an argument to init.
+
+Module parameters can be specified in two ways: via the kernel command
+line with a module name prefix, or via modprobe, e.g.:
+
+        (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
@@ -214,6 +224,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         unusable.  The "log_buf_len" parameter may be useful
                         if you need to capture more output.
 
+        acpi_force_table_verification   [HW,ACPI]
+                        Enable table checksum verification during early stage.
+                        By default, this is disabled due to x86 early mapping
+                        size limitation.
+
         acpi_irq_balance [HW,ACPI]
                         ACPI will balance active IRQs
                         default in APIC mode
@@ -237,7 +252,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         This feature is enabled by default.
                         This option allows to turn off the feature.
 
-        acpi_no_auto_ssdt       [HW,ACPI] Disable automatic loading of SSDT
+        acpi_no_static_ssdt     [HW,ACPI]
+                        Disable installation of static SSDTs at early boot time
+                        By default, SSDTs contained in the RSDT/XSDT will be
+                        installed automatically and they will appear under
+                        /sys/firmware/acpi/tables.
+                        This option turns off this feature.
+                        Note that specifying this option does not affect
+                        dynamic table installation which will install SSDT
+                        tables to /sys/firmware/acpi/tables/dynamic.
 
         acpica_no_return_repair [HW, ACPI]
                         Disable AML predefined validation mechanism
@@ -617,8 +640,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Also note the kernel might malfunction if you disable
                         some critical bits.
 
-        cma=nn[MG]      [ARM,KNL]
-                        Sets the size of kernel global memory area for contiguous
+        cma=nn[MG]@[start[MG][-end[MG]]]
+                        [ARM,X86,KNL]
+                        Sets the size of kernel global memory area for
+                        contiguous memory allocations and optionally the
+                        placement constraint by the physical address range of
                         memory allocations. For more information, see
                         include/linux/dma-contiguous.h
 
@@ -804,13 +830,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         dhash_entries=  [KNL]
                         Set number of hash buckets for dentry cache.
 
-        digi=           [HW,SERIAL]
-                        IO parameters + enable/disable command.
-
-        digiepca=       [HW,SERIAL]
-                        See drivers/char/README.epca and
-                        Documentation/serial/digiepca.txt.
-
         disable=        [IPV6]
                         See Documentation/networking/ipv6.txt.
 
@@ -890,6 +909,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         which are not unmapped.
 
         earlycon=       [KNL] Output early console device and options.
+
                 uart[8250],io,<addr>[,options]
                 uart[8250],mmio,<addr>[,options]
                 uart[8250],mmio32,<addr>[,options]
@@ -899,7 +919,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         (mmio) or 32-bit (mmio32).
                         The options are the same as for ttyS, above.
 
-        earlyprintk=    [X86,SH,BLACKFIN,ARM]
+                pl011,<addr>
+                        Start an early, polled-mode console on a pl011 serial
+                        port at the specified address. The pl011 serial port
+                        must already be setup and configured. Options are not
+                        yet supported.
+
+                smh     Use ARM semihosting calls for early console.
+
+        earlyprintk=    [X86,SH,BLACKFIN,ARM,M68k]
                         earlyprintk=vga
                         earlyprintk=efi
                         earlyprintk=xen
@@ -1294,6 +1322,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         for working out where the kernel is dying during
                         startup.
 
+        initcall_blacklist=  [KNL] Do not execute a comma-separated list of
+                        initcall functions.  Useful for debugging built-in
+                        modules and initcalls.
+
         initrd=         [BOOT] Specify the location of the initial ramdisk
 
         inport.irq=     [HW] Inport (ATI XL and Microsoft) busmouse driver
@@ -2225,10 +2257,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         noreplace-smp   [X86-32,SMP] Don't replace SMP instructions
                         with UP alternatives
 
-        nordrand        [X86] Disable the direct use of the RDRAND
-                        instruction even if it is supported by the
-                        processor.  RDRAND is still available to user
-                        space applications.
+        nordrand        [X86] Disable kernel use of the RDRAND and
+                        RDSEED instructions even if they are supported
+                        by the processor.  RDRAND and RDSEED are still
+                        available to user space applications.
 
         noresume        [SWSUSP] Disables resume and restores original swap
                         space.
@@ -2339,6 +2371,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         timeout < 0: reboot immediately
                         Format: <timeout>
 
+        crash_kexec_post_notifiers
+                        Run kdump after running panic-notifiers and dumping
+                        kmsg. This only for the users who doubt kdump always
+                        succeeds in any situation.
+                        Note that this also increases risks of kdump failure,
+                        because some panic notifiers can make the crashed
+                        kernel more unstable.
+
         parkbd.port=    [HW] Parallel port number the keyboard adapter is
                         connected to, default is 0.
                         Format: <parport#>
@@ -2896,6 +2936,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         [KNL, SMP] Set scheduler's default relax_domain_level.
                         See Documentation/cgroups/cpusets.txt.
 
+        relative_sleep_states=
+                        [SUSPEND] Use sleep state labeling where the deepest
+                        state available other than hibernation is always "mem".
+                        Format: { "0" | "1" }
+                        0 -- Traditional sleep state labels.
+                        1 -- Relative sleep state labels.
+
         reserve=        [KNL,BUGS] Force the kernel to ignore some iomem area
 
         reservetop=     [X86-32]
@@ -2939,9 +2986,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         rhash_entries=  [KNL,NET]
                         Set number of hash buckets for route cache
 
-        riscom8=        [HW,SERIAL]
-                        Format: <io_board1>[,<io_board2>[,...<io_boardN>]]
-
         ro              [KNL] Mount root device read-only on boot
 
         root=           [KNL] Root filesystem
@@ -3083,9 +3127,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         sonypi.*=       [HW] Sony Programmable I/O Control Device driver
                         See Documentation/laptops/sonypi.txt
 
-        specialix=      [HW,SERIAL] Specialix multi-serial port adapter
-                        See Documentation/serial/specialix.txt.
-
         spia_io_base=   [HW,MTD]
         spia_fio_base=
         spia_pedr=
@@ -3474,7 +3515,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         the allocated input device; If set to 0, video driver
                         will only send out the event without touching backlight
                         brightness level.
-                        default: 1
+                        default: 0
 
         virtio_mmio.device=
                         [VMMIO] Memory mapped virtio (platform) device.
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index a7563ec4ea7b..b772418bf064 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -142,6 +142,7 @@ kmemleak_alloc_percpu	 - notify of a percpu memory block allocation
 kmemleak_free            - notify of a memory block freeing
 kmemleak_free_part       - notify of a partial memory block freeing
 kmemleak_free_percpu     - notify of a percpu memory block freeing
+kmemleak_update_trace    - update object allocation stack trace
 kmemleak_not_leak        - mark an object as not a leak
 kmemleak_ignore          - do not scan or report an object as leak
 kmemleak_scan_area       - add scan areas inside a memory block
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/magic-number.txt b/Documentation/magic-number.txt
index 76d80a64bbe1..4c8e142db2ef 100644
--- a/Documentation/magic-number.txt
+++ b/Documentation/magic-number.txt
@@ -63,8 +63,6 @@ Magic Name            Number      Structure            File
 PG_MAGIC              'P'         pg_{read,write}_hdr include/linux/pg.h
 CMAGIC                0x0111      user              include/linux/a.out.h
 MKISS_DRIVER_MAGIC    0x04bf      mkiss_channel     drivers/net/mkiss.h
-RISCOM8_MAGIC         0x0907      riscom_port       drivers/char/riscom8.h
-SPECIALIX_MAGIC       0x0907      specialix_port    drivers/char/specialix_io8.h
 HDLC_MAGIC            0x239e      n_hdlc            drivers/char/n_hdlc.c
 APM_BIOS_MAGIC        0x4101      apm_user          arch/x86/kernel/apm_32.c
 CYCLADES_MAGIC        0x4359      cyclades_port     include/linux/cyclades.h
@@ -82,7 +80,6 @@ STRIP_MAGIC           0x5303      strip             drivers/net/strip.c
 X25_ASY_MAGIC         0x5303      x25_asy           drivers/net/x25_asy.h
 SIXPACK_MAGIC         0x5304      sixpack           drivers/net/hamradio/6pack.h
 AX25_MAGIC            0x5316      ax_disp           drivers/net/mkiss.h
-ESP_MAGIC             0x53ee      esp_struct        drivers/char/esp.h
 TTY_MAGIC             0x5401      tty_struct        include/linux/tty.h
 MGSL_MAGIC            0x5401      mgsl_info         drivers/char/synclink.c
 TTY_DRIVER_MAGIC      0x5402      tty_driver        include/linux/tty_driver.h
@@ -94,13 +91,10 @@ USB_BLUETOOTH_MAGIC   0x6d02      usb_bluetooth     drivers/usb/class/bluetty.c
 RFCOMM_TTY_MAGIC      0x6d02                        net/bluetooth/rfcomm/tty.c
 USB_SERIAL_PORT_MAGIC 0x7301      usb_serial_port   drivers/usb/serial/usb-serial.h
 CG_MAGIC              0x00090255  ufs_cylinder_group include/linux/ufs_fs.h
-A2232_MAGIC           0x000a2232  gs_port           drivers/char/ser_a2232.h
 RPORT_MAGIC           0x00525001  r_port            drivers/char/rocket_int.h
 LSEMAGIC              0x05091998  lse               drivers/fc4/fc.c
 GDTIOCTL_MAGIC        0x06030f07  gdth_iowr_str     drivers/scsi/gdth_ioctl.h
 RIEBL_MAGIC           0x09051990                    drivers/net/atarilance.c
-RIO_MAGIC             0x12345678  gs_port           drivers/char/rio/rio_linux.c
-SX_MAGIC              0x12345678  gs_port           drivers/char/sx.h
 NBD_REQUEST_MAGIC     0x12560953  nbd_request       include/linux/nbd.h
 RED_MAGIC2            0x170fc2a5  (any)             mm/slab.c
 BAYCOM_MAGIC          0x19730510  baycom_state      drivers/net/baycom_epp.c
@@ -116,7 +110,6 @@ ISDN_ASYNC_MAGIC      0x49344C01  modem_info        include/linux/isdn.h
 CTC_ASYNC_MAGIC       0x49344C01  ctc_tty_info      drivers/s390/net/ctctty.c
 ISDN_NET_MAGIC        0x49344C02  isdn_net_local_s  drivers/isdn/i4l/isdn_net_lib.h
 SAVEKMSG_MAGIC2       0x4B4D5347  savekmsg          arch/*/amiga/config.c
-STLI_BOARDMAGIC       0x4bc6c825  stlibrd           include/linux/istallion.h
 CS_STATE_MAGIC        0x4c4f4749  cs_state          sound/oss/cs46xx.c
 SLAB_C_MAGIC          0x4f17a36d  kmem_cache        mm/slab.c
 COW_MAGIC             0x4f4f4f4d  cow_header_v1     arch/um/drivers/ubd_user.c
@@ -127,10 +120,8 @@ SCC_MAGIC             0x52696368  gs_port           drivers/char/scc.h
 SAVEKMSG_MAGIC1       0x53415645  savekmsg          arch/*/amiga/config.c
 GDA_MAGIC             0x58464552  gda               arch/mips/include/asm/sn/gda.h
 RED_MAGIC1            0x5a2cf071  (any)             mm/slab.c
-STL_PORTMAGIC         0x5a7182c9  stlport           include/linux/stallion.h
 EEPROM_MAGIC_VALUE    0x5ab478d2  lanai_dev         drivers/atm/lanai.c
 HDLCDRV_MAGIC         0x5ac6e778  hdlcdrv_state     include/linux/hdlcdrv.h
-EPCA_MAGIC            0x5c6df104  channel           include/linux/epca.h
 PCXX_MAGIC            0x5c6df104  channel           drivers/char/pcxx.h
 KV_MAGIC              0x5f4b565f  kernel_vars_s     arch/mips/include/asm/sn/klkernvars.h
 I810_STATE_MAGIC      0x63657373  i810_state        sound/oss/i810_audio.c
@@ -142,17 +133,14 @@ SLOT_MAGIC            0x67267322  slot              drivers/hotplug/acpiphp.h
 LO_MAGIC              0x68797548  nbd_device        include/linux/nbd.h
 OPROFILE_MAGIC        0x6f70726f  super_block       drivers/oprofile/oprofilefs.h
 M3_STATE_MAGIC        0x734d724d  m3_state          sound/oss/maestro3.c
-STL_PANELMAGIC        0x7ef621a1  stlpanel          include/linux/stallion.h
 VMALLOC_MAGIC         0x87654320  snd_alloc_track   sound/core/memory.c
 KMALLOC_MAGIC         0x87654321  snd_alloc_track   sound/core/memory.c
 PWC_MAGIC             0x89DC10AB  pwc_device        drivers/usb/media/pwc.h
 NBD_REPLY_MAGIC       0x96744668  nbd_reply         include/linux/nbd.h
-STL_BOARDMAGIC        0xa2267f52  stlbrd            include/linux/stallion.h
 ENI155_MAGIC          0xa54b872d  midway_eprom      drivers/atm/eni.h
 SCI_MAGIC             0xbabeface  gs_port           drivers/char/sh-sci.h
 CODA_MAGIC            0xC0DAC0DA  coda_file_info    fs/coda/coda_fs_i.h
 DPMEM_MAGIC           0xc0ffee11  gdt_pci_sram      drivers/scsi/gdth.h
-STLI_PORTMAGIC        0xe671c7a1  stliport          include/linux/istallion.h
 YAM_MAGIC             0xF10A7654  yam_port          drivers/net/hamradio/yam.c
 CCB_MAGIC             0xf2691ad2  ccb               drivers/scsi/ncr53c8xx.c
 QUEUE_MAGIC_FREE      0xf7e1c9a3  queue_entry       drivers/scsi/arm/queue.c
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 556f951f8626..f1dc4a215593 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -115,8 +115,8 @@ For example, consider the following sequence of events:
         CPU 1           CPU 2
         =============== ===============
         { A == 1; B == 2 }
-        A = 3;          x = A;
-        B = 4;          y = B;
+        A = 3;          x = B;
+        B = 4;          y = A;
 
 The set of accesses as seen by the memory system in the middle can be arranged
 in 24 different combinations:
@@ -1583,20 +1583,21 @@ There are some more advanced barrier functions:
      insert anything more than a compiler barrier in a UP compilation.
 
 
- (*) smp_mb__before_atomic_dec();
- (*) smp_mb__after_atomic_dec();
- (*) smp_mb__before_atomic_inc();
- (*) smp_mb__after_atomic_inc();
+ (*) smp_mb__before_atomic();
+ (*) smp_mb__after_atomic();
 
-     These are for use with atomic add, subtract, increment and decrement
-     functions that don't return a value, especially when used for reference
-     counting.  These functions do not imply memory barriers.
+     These are for use with atomic (such as add, subtract, increment and
+     decrement) functions that don't return a value, especially when used for
+     reference counting.  These functions do not imply memory barriers.
+
+     These are also used for atomic bitop functions that do not return a
+     value (such as set_bit and clear_bit).
 
      As an example, consider a piece of code that marks an object as being dead
      and then decrements the object's reference count:
 
         obj->dead = 1;
-        smp_mb__before_atomic_dec();
+        smp_mb__before_atomic();
         atomic_dec(&obj->ref_count);
 
      This makes sure that the death mark on the object is perceived to be set
@@ -1606,27 +1607,6 @@ There are some more advanced barrier functions:
      operations" subsection for information on where to use these.
 
 
- (*) smp_mb__before_clear_bit(void);
- (*) smp_mb__after_clear_bit(void);
-
-     These are for use similar to the atomic inc/dec barriers.  These are
-     typically used for bitwise unlocking operations, so care must be taken as
-     there are no implicit memory barriers here either.
-
-     Consider implementing an unlock operation of some nature by clearing a
-     locking bit.  The clear_bit() would then need to be barriered like this:
-
-        smp_mb__before_clear_bit();
-        clear_bit( ... );
-
-     This prevents memory operations before the clear leaking to after it.  See
-     the subsection on "Locking Functions" with reference to RELEASE operation
-     implications.
-
-     See Documentation/atomic_ops.txt for more information.  See the "Atomic
-     operations" subsection for information on where to use these.
-
-
 MMIO WRITE BARRIER
 ------------------
 
@@ -2283,11 +2263,11 @@ operations:
         change_bit();
 
 With these the appropriate explicit memory barrier should be used if necessary
-(smp_mb__before_clear_bit() for instance).
+(smp_mb__before_atomic() for instance).
 
 
 The following also do _not_ imply memory barriers, and so may require explicit
-memory barriers under some circumstances (smp_mb__before_atomic_dec() for
+memory barriers under some circumstances (smp_mb__before_atomic() for
 instance):
 
         atomic_add();
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index 58340d50f8a6..f304edb8fbe7 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -88,16 +88,21 @@ phase by hand.
 
 1.3. Unit of Memory online/offline operation
 ------------
-Memory hotplug uses SPARSEMEM memory model. SPARSEMEM divides the whole memory
-into chunks of the same size. The chunk is called a "section". The size of
-a section is architecture dependent. For example, power uses 16MiB, ia64 uses
-1GiB. The unit of online/offline operation is "one section". (see Section 3.)
+Memory hotplug uses SPARSEMEM memory model which allows memory to be divided
+into chunks of the same size. These chunks are called "sections". The size of
+a memory section is architecture dependent. For example, power uses 16MiB, ia64
+uses 1GiB.
 
-To determine the size of sections, please read this file:
+Memory sections are combined into chunks referred to as "memory blocks". The
+size of a memory block is architecture dependent and represents the logical
+unit upon which memory online/offline operations are to be performed. The
+default size of a memory block is the same as memory section size unless an
+architecture specifies otherwise. (see Section 3.)
+
+To determine the size (in bytes) of a memory block please read this file:
 
 /sys/devices/system/memory/block_size_bytes
 
-This file shows the size of sections in byte.
 
 -----------------------
 2. Kernel Configuration
@@ -123,42 +128,35 @@ config options.
     (CONFIG_ACPI_CONTAINER).
     This option can be kernel module too.
 
+
 --------------------------------
-4 sysfs files for memory hotplug
+3 sysfs files for memory hotplug
 --------------------------------
-All sections have their device information in sysfs.  Each section is part of
-a memory block under /sys/devices/system/memory as
+All memory blocks have their device information in sysfs.  Each memory block
+is described under /sys/devices/system/memory as
 
 /sys/devices/system/memory/memoryXXX
-(XXX is the section id.)
+(XXX is the memory block id.)
 
-Now, XXX is defined as (start_address_of_section / section_size) of the first
-section contained in the memory block.  The files 'phys_index' and
-'end_phys_index' under each directory report the beginning and end section id's
-for the memory block covered by the sysfs directory.  It is expected that all
+For the memory block covered by the sysfs directory.  It is expected that all
 memory sections in this range are present and no memory holes exist in the
 range. Currently there is no way to determine if there is a memory hole, but
 the existence of one should not affect the hotplug capabilities of the memory
 block.
 
-For example, assume 1GiB section size. A device for a memory starting at
+For example, assume 1GiB memory block size. A device for a memory starting at
 0x100000000 is /sys/device/system/memory/memory4
 (0x100000000 / 1Gib = 4)
 This device covers address range [0x100000000 ... 0x140000000)
 
-Under each section, you can see 4 or 5 files, the end_phys_index file being
-a recent addition and not present on older kernels.
+Under each memory block, you can see 4 files:
 
-/sys/devices/system/memory/memoryXXX/start_phys_index
-/sys/devices/system/memory/memoryXXX/end_phys_index
+/sys/devices/system/memory/memoryXXX/phys_index
 /sys/devices/system/memory/memoryXXX/phys_device
 /sys/devices/system/memory/memoryXXX/state
 /sys/devices/system/memory/memoryXXX/removable
 
-'phys_index'      : read-only and contains section id of the first section
-                    in the memory block, same as XXX.
-'end_phys_index'  : read-only and contains section id of the last section
-                    in the memory block.
+'phys_index'      : read-only and contains memory block id, same as XXX.
 'state'           : read-write
                     at read:  contains online/offline state of memory.
                     at write: user can specify "online_kernel",
@@ -185,6 +183,7 @@ For example:
 A backlink will also be created:
 /sys/devices/system/memory/memory9/node0 -> ../../node/node0
 
+
 --------------------------------
 4. Physical memory hot-add phase
 --------------------------------
@@ -227,11 +226,10 @@ You can tell the physical address of new memory to the kernel by
 
 % echo start_address_of_new_memory > /sys/devices/system/memory/probe
 
-Then, [start_address_of_new_memory, start_address_of_new_memory + section_size)
-memory range is hot-added. In this case, hotplug script is not called (in
-current implementation). You'll have to online memory by yourself.
-Please see "How to online memory" in this text.
-
+Then, [start_address_of_new_memory, start_address_of_new_memory +
+memory_block_size] memory range is hot-added. In this case, hotplug script is
+not called (in current implementation). You'll have to online memory by
+yourself.  Please see "How to online memory" in this text.
 
 
 ------------------------------
@@ -240,36 +238,36 @@ Please see "How to online memory" in this text.
 
 5.1. State of memory
 ------------
-To see (online/offline) state of memory section, read 'state' file.
+To see (online/offline) state of a memory block, read 'state' file.
 
 % cat /sys/device/system/memory/memoryXXX/state
 
 
-If the memory section is online, you'll read "online".
-If the memory section is offline, you'll read "offline".
+If the memory block is online, you'll read "online".
+If the memory block is offline, you'll read "offline".
 
 
 5.2. How to online memory
 ------------
 Even if the memory is hot-added, it is not at ready-to-use state.
-For using newly added memory, you have to "online" the memory section.
+For using newly added memory, you have to "online" the memory block.
 
-For onlining, you have to write "online" to the section's state file as:
+For onlining, you have to write "online" to the memory block's state file as:
 
 % echo online > /sys/devices/system/memory/memoryXXX/state
 
-This onlining will not change the ZONE type of the target memory section,
-If the memory section is in ZONE_NORMAL, you can change it to ZONE_MOVABLE:
+This onlining will not change the ZONE type of the target memory block,
+If the memory block is in ZONE_NORMAL, you can change it to ZONE_MOVABLE:
 
 % echo online_movable > /sys/devices/system/memory/memoryXXX/state
-(NOTE: current limit: this memory section must be adjacent to ZONE_MOVABLE)
+(NOTE: current limit: this memory block must be adjacent to ZONE_MOVABLE)
 
-And if the memory section is in ZONE_MOVABLE, you can change it to ZONE_NORMAL:
+And if the memory block is in ZONE_MOVABLE, you can change it to ZONE_NORMAL:
 
 % echo online_kernel > /sys/devices/system/memory/memoryXXX/state
-(NOTE: current limit: this memory section must be adjacent to ZONE_NORMAL)
+(NOTE: current limit: this memory block must be adjacent to ZONE_NORMAL)
 
-After this, section memoryXXX's state will be 'online' and the amount of
+After this, memory block XXX's state will be 'online' and the amount of
 available memory will be increased.
 
 Currently, newly added memory is added as ZONE_NORMAL (for powerpc, ZONE_DMA).
@@ -284,22 +282,22 @@ This may be changed in future.
 6.1 Memory offline and ZONE_MOVABLE
 ------------
 Memory offlining is more complicated than memory online. Because memory offline
-has to make the whole memory section be unused, memory offline can fail if
-the section includes memory which cannot be freed.
+has to make the whole memory block be unused, memory offline can fail if
+the memory block includes memory which cannot be freed.
 
 In general, memory offline can use 2 techniques.
 
-(1) reclaim and free all memory in the section.
-(2) migrate all pages in the section.
+(1) reclaim and free all memory in the memory block.
+(2) migrate all pages in the memory block.
 
 In the current implementation, Linux's memory offline uses method (2), freeing
-all  pages in the section by page migration. But not all pages are
+all  pages in the memory block by page migration. But not all pages are
 migratable. Under current Linux, migratable pages are anonymous pages and
-page caches. For offlining a section by migration, the kernel has to guarantee
-that the section contains only migratable pages.
+page caches. For offlining a memory block by migration, the kernel has to
+guarantee that the memory block contains only migratable pages.
 
-Now, a boot option for making a section which consists of migratable pages is
-supported. By specifying "kernelcore=" or "movablecore=" boot option, you can
+Now, a boot option for making a memory block which consists of migratable pages
+is supported. By specifying "kernelcore=" or "movablecore=" boot option, you can
 create ZONE_MOVABLE...a zone which is just used for movable pages.
 (See also Documentation/kernel-parameters.txt)
 
@@ -315,28 +313,27 @@ creates ZONE_MOVABLE as following.
   Size of memory for movable pages (for offline) is ZZZZ.
 
 
-Note) Unfortunately, there is no information to show which section belongs
+Note: Unfortunately, there is no information to show which memory block belongs
 to ZONE_MOVABLE. This is TBD.
 
 
 6.2. How to offline memory
 ------------
-You can offline a section by using the same sysfs interface that was used in
-memory onlining.
+You can offline a memory block by using the same sysfs interface that was used
+in memory onlining.
 
 % echo offline > /sys/devices/system/memory/memoryXXX/state
 
-If offline succeeds, the state of the memory section is changed to be "offline".
+If offline succeeds, the state of the memory block is changed to be "offline".
 If it fails, some error core (like -EBUSY) will be returned by the kernel.
-Even if a section does not belong to ZONE_MOVABLE, you can try to offline it.
-If it doesn't contain 'unmovable' memory, you'll get success.
+Even if a memory block does not belong to ZONE_MOVABLE, you can try to offline
+it.  If it doesn't contain 'unmovable' memory, you'll get success.
 
-A section under ZONE_MOVABLE is considered to be able to be offlined easily.
-But under some busy state, it may return -EBUSY. Even if a memory section
-cannot be offlined due to -EBUSY, you can retry offlining it and may be able to
-offline it (or not).
-(For example, a page is referred to by some kernel internal call and released
- soon.)
+A memory block under ZONE_MOVABLE is considered to be able to be offlined
+easily.  But under some busy state, it may return -EBUSY. Even if a memory
+block cannot be offlined due to -EBUSY, you can retry offlining it and may be
+able to offline it (or not). (For example, a page is referred to by some kernel
+internal call and released soon.)
 
 Consideration:
 Memory hotplug's design direction is to make the possibility of memory offlining
@@ -373,11 +370,11 @@ MEMORY_GOING_OFFLINE
   Generated to begin the process of offlining memory. Allocations are no
   longer possible from the memory but some of the memory to be offlined
   is still in use. The callback can be used to free memory known to a
-  subsystem from the indicated memory section.
+  subsystem from the indicated memory block.
 
 MEMORY_CANCEL_OFFLINE
   Generated if MEMORY_GOING_OFFLINE fails. Memory is available again from
-  the section that we attempted to offline.
+  the memory block that we attempted to offline.
 
 MEMORY_OFFLINE
   Generated after offlining memory is complete.
@@ -413,8 +410,8 @@ node if necessary.
 --------------
   - allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
     sysctl or new control file.
-  - showing memory section and physical device relationship.
-  - showing memory section is under ZONE_MOVABLE or not
+  - showing memory block and physical device relationship.
+  - showing memory block is under ZONE_MOVABLE or not
   - test and make it better memory offlining.
   - support HugeTLB page migration and offlining.
   - memmap removing at memory offline.
diff --git a/Documentation/mtd/nand/pxa3xx-nand.txt b/Documentation/mtd/nand/pxa3xx-nand.txt
index 840fd41c181b..1074cbc67ec6 100644
--- a/Documentation/mtd/nand/pxa3xx-nand.txt
+++ b/Documentation/mtd/nand/pxa3xx-nand.txt
@@ -48,7 +48,7 @@ configurable between two modes: 1) Hamming, 2) BCH.
 Note that the actual BCH mode: BCH-4 or BCH-8 will depend on the way
 the controller is configured to transfer the data.
 
-In the BCH mode the ECC code will be calculated for each transfered chunk
+In the BCH mode the ECC code will be calculated for each transferred chunk
 and expected to be located (when reading/programming) right after the spare
 bytes as the figure above shows.
 
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
-   with semaphores?"
+What are mutexes?
+-----------------
 
-firstly, there's nothing wrong with semaphores. But if the simpler
-mutex semantics are sufficient for your code, then there are a couple
-of advantages of mutexes:
+In the Linux kernel, mutexes refer to a particular locking primitive
+that enforces serialization on shared memory systems, and not only to
+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,
-   'struct semaphore' is 20 bytes, 'struct mutex' is 16 bytes.
-   A smaller structure size means less RAM footprint, and better
-   CPU-cache utilization.
+[1] http://lwn.net/Articles/164802/
 
- - tighter code. On x86 i get the following .text sizes when
-   switching all mutex-alike semaphores in the kernel to the mutex
-   subsystem:
+Implementation
+--------------
 
-        text    data     bss     dec     hex filename
-     3280380  868188  396860 4545428  455b94 vmlinux-semaphore
-     3255329  865296  396732 4517357  44eded vmlinux-mutex
+Mutexes are represented by 'struct mutex', defined in include/linux/mutex.h
+and implemented in kernel/locking/mutex.c. These locks use a three
+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
-   codepaths of the kernel. (The .data savings are 2892 bytes, or 0.33%)
-   Smaller code means better icache footprint, which is one of the
-   major optimization goals in the Linux kernel currently.
+          1: unlocked
+          0: locked, no waiters
+   negative: locked, with potential waiters
 
- - the mutex subsystem is slightly faster and has better scalability for
-   contended workloads. On an 8-way x86 system, running a mutex-based
-   kernel and testing creat+unlink+close (of separate, per-task files)
-   in /tmp with 16 parallel tasks, the average number of ops/sec is:
+In its most basic form it also includes a wait-queue and a spinlock
+that serializes access to it. CONFIG_SMP systems can also include
+a pointer to the lock task owner (->owner) as well as a spinner MCS
+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
-    8 CPUs, running 16 tasks.          8 CPUs, running 16 tasks.
-    checking VFS performance.          checking VFS performance.
-    avg loops/sec:      34713          avg loops/sec:      84153
-    CPU utilization:    63%            CPU utilization:    22%
+(i) fastpath: tries to atomically acquire the lock by decrementing the
+    counter. If it was already taken by another task it goes to the next
+    possible path. This logic is architecture specific. On x86-64, the
+    locking fastpath is 2 instructions:
 
-   i.e. in this workload, the mutex based kernel was 2.4 times faster
-   than the semaphore based kernel, _and_ it also had 2.8 times less CPU
-   utilization. (In terms of 'ops per CPU cycle', the semaphore kernel
-   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
+    0000000000000e10 <mutex_lock>:
+    e21:   f0 ff 0b                lock decl (%rbx)
+    e24:   79 08                   jns    e2e <mutex_lock+0x1e>
 
    the unlocking fastpath is equally tight:
 
-    c0377cd1 <mutex_unlock>:
-    c0377cd1:       f0 ff 00                lock incl (%eax)
-    c0377cd4:       7e 0f                   jle    c0377ce5 <.text..lock.mutex+0x7>
-    c0377cd6:       c3                      ret
-
- - 'struct mutex' semantics are well-defined and are enforced if
-   CONFIG_DEBUG_MUTEXES is turned on. Semaphores on the other hand have
-   virtually no debugging code or instrumentation. 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 is not permitted
-   * - a mutex object must be initialized via the API
-   * - a mutex object must not be initialized via memset or copying
-   * - task may not exit with 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
-
-   furthermore, there are also convenience features in the debugging
-   code:
-
-   * - 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)
+    0000000000000bc0 <mutex_unlock>:
+    bc8:   f0 ff 07                lock incl (%rdi)
+    bcb:   7f 0a                   jg     bd7 <mutex_unlock+0x17>
+
+
+(ii) midpath: aka optimistic spinning, tries to spin for acquisition
+     while the lock owner is running and there are no other tasks ready
+     to run that have higher priority (need_resched). The rationale is
+     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
+     one spinner can compete for the mutex.
+
+     The MCS lock (proposed by Mellor-Crummey and Scott) is a simple spinlock
+     with the desirable properties of being fair and with each cpu trying
+     to acquire the lock spinning on a local variable. It avoids expensive
+     cacheline bouncing that common test-and-set spinlock implementations
+     incur. An MCS-like lock is specially tailored for optimistic spinning
+     for sleeping lock implementation. An important feature of the customized
+     MCS lock is that it has the extra property that spinners are able to exit
+     the MCS spinlock queue when they need to reschedule. This further helps
+     avoid situations where MCS spinners that need to reschedule would continue
+     waiting to spin on mutex owner, only to go directly to slowpath upon
+     obtaining the MCS lock.
+
+
+(iii) slowpath: last resort, if the lock is still unable to be acquired,
+      the task is added to the wait-queue and sleeps until woken up by the
+      unlock path. Under normal circumstances it blocks as TASK_UNINTERRUPTIBLE.
+
+While formally kernel mutexes are sleepable locks, it is path (ii) that
+makes them more practically a hybrid type. By simply not interrupting a
+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
-can use semaphores: e.g. they cannot be used from an interrupt context,
-nor can they be unlocked from a different context that which acquired
-it. [ I'm not aware of any other (e.g. performance) disadvantages from
-using mutexes at the moment, please let me know if you find any. ]
-
-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);
+Unlike its original design and purpose, 'struct mutex' is larger than
+most locks in the kernel. E.g: on x86-64 it is 40 bytes, almost twice
+as large as 'struct semaphore' (24 bytes) and 8 bytes shy of the
+'struct rw_semaphore' variant. Larger structure sizes mean more CPU
+cache and memory footprint.
 
- mutex_init(mutex);
+When to use mutexes
+-------------------
 
- void mutex_lock(struct mutex *lock);
- int  mutex_lock_interruptible(struct mutex *lock);
- int  mutex_trylock(struct mutex *lock);
- 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);
+Unless the strict semantics of mutexes are unsuitable and/or the critical
+region prevents the lock from being shared, always prefer them to any other
+locking primitive.
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
-                outgoing traffic is distributed according to the
-                current load (computed relative to the speed) on each
-                slave.  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.
+                does not require any special switch support.
+
+                In tlb_dynamic_lb=1 mode; the outgoing traffic is
+                distributed according to the current load (computed
+                relative to the speed) on each 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 2fa44cbe81b7..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
@@ -706,7 +741,7 @@ solution for a couple of reasons:
 
     RX_NO_AUTOTIMER:    Prevent automatically starting the timeout monitor.
 
-    RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occured, a
+    RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occurred, a
       RX_CHANGED message will be generated when the (cyclic) receive restarts.
 
     TX_RESET_MULTI_IDX: Reset the index for the multiple frame transmission.
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/dccp.txt b/Documentation/networking/dccp.txt
index bf5dbe3ab8c5..55c575fcaf17 100644
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -86,7 +86,7 @@ built-in CCIDs.
 
 DCCP_SOCKOPT_CCID is write-only and sets both the TX and RX CCIDs at the same
 time, combining the operation of the next two socket options. This option is
-preferrable over the latter two, since often applications will use the same
+preferable over the latter two, since often applications will use the same
 type of CCID for both directions; and mixed use of CCIDs is not currently well
 understood. This socket option takes as argument at least one uint8_t value, or
 an array of uint8_t values, which must match available CCIDS (see above). CCIDs
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index 81f940f4e884..ee78eba78a9d 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -277,10 +277,11 @@ Possible BPF extensions are shown in the following table:
   mark                                  skb->mark
   queue                                 skb->queue_mapping
   hatype                                skb->dev->type
-  rxhash                                skb->rxhash
+  rxhash                                skb->hash
   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
-a BPF backend that performs almost as fast as natively compiled code.
+the possibility for GCC/LLVM compilers to generate optimized eBPF code through
+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
-transparently by using sk_unattached_filter_create() for setting up the
-filter, resp. sk_unattached_filter_destroy() for destroying it. The macro
-SK_RUN_FILTER(filter, ctx) transparently invokes the right BPF function to
-run the filter. 'filter' is a pointer to struct sk_filter that we got from
-sk_unattached_filter_create(), and 'ctx' the given context (e.g. skb pointer).
-All constraints and restrictions from sk_chk_filter() apply 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
-compilers reused whenever possible. In other words, we do not (yet!) perform
-a JIT compilation in the new layout, however, future work will successively
-migrate traditional JIT compilers into the new instruction format as well, so
-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.
+in the eBPF interpreter. For in-kernel handlers, this all works transparently
+by using sk_unattached_filter_create() for setting up the filter, resp.
+sk_unattached_filter_destroy() for destroying it. The macro
+SK_RUN_FILTER(filter, ctx) transparently invokes eBPF interpreter or JITed
+code to run the filter. 'filter' is a pointer to struct sk_filter that we
+got from sk_unattached_filter_create(), and 'ctx' the given context (e.g.
+skb pointer). All constraints and restrictions from sk_chk_filter() apply
+before a conversion to the new layout is being done behind the scenes!
+
+Currently, the classic BPF format is being used for JITing on most of the
+architectures. Only x86-64 performs JIT compilation from eBPF instruction set,
+however, future work will migrate other JIT compilers as well, so that they
+will profit from the very same benefits.
 
 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
-    * R1 - R5   - arguments from BPF program to in-kernel function
+    * R0        - return value from in-kernel function, and exit value for eBPF program
+    * 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,
-  etc, and BPF calling convention maps directly to ABIs used by the kernel on
+  Thus, all eBPF registers map one to one to HW registers on x86_64, aarch64,
+  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
-  necessary across calls. Note that there is only one BPF program (== one BPF
-  main routine) and it cannot call other BPF functions, it can only call
-  predefined in-kernel functions, though.
+  R0 - R5 are scratch registers and eBPF program needs spill/fill them if
+  necessary across calls. Note that there is only one eBPF program (== one
+  eBPF main routine) and it cannot call other eBPF functions, it can only
+  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
-  ABI, thus, there won't be able to use a direct BPF register to HW register
+  so 32-bit eBPF registers would otherwise require to define register-pair
+  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
-  return type of the function. Since R6 - R9 are callee saved, their state is
-  preserved across the call.
-
-Also in the new design, BPF is limited to 4096 insns, which means that any
+  Before an in-kernel function call, the internal BPF program needs to
+  place function arguments into R1 to R5 registers to satisfy calling
+  convention, then the interpreter will take them from registers and pass
+  to in-kernel function. If R1 - R5 registers are mapped to CPU registers
+  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/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 6fea79efb4cb..38112d512f47 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -578,7 +578,7 @@ processes. This also works in combination with mmap(2) on packet sockets.
 
 Currently implemented fanout policies are:
 
-  - PACKET_FANOUT_HASH: schedule to socket by skb's rxhash
+  - PACKET_FANOUT_HASH: schedule to socket by skb's packet hash
   - PACKET_FANOUT_LB: schedule to socket by round-robin
   - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on
   - PACKET_FANOUT_RND: schedule to socket by random selection
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
index ca6977f5b2ed..99ca40e8e810 100644
--- a/Documentation/networking/scaling.txt
+++ b/Documentation/networking/scaling.txt
@@ -429,7 +429,7 @@ RPS and RFS were introduced in kernel 2.6.35. XPS was incorporated into
 (therbert@google.com)
 
 Accelerated RFS was introduced in 2.6.35. Original patches were
-submitted by Ben Hutchings (bhutchings@solarflare.com)
+submitted by Ben Hutchings (bwh@kernel.org)
 
 Authors:
 Tom Herbert (therbert@google.com)
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/devices.txt b/Documentation/power/devices.txt
index 47d46dff70f7..d172bce0fd49 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -2,6 +2,7 @@ Device Power Management
 
 Copyright (c) 2010-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
 Copyright (c) 2010 Alan Stern <stern@rowland.harvard.edu>
+Copyright (c) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
 
 Most of the code in Linux is device drivers, so most of the Linux power
@@ -326,6 +327,20 @@ the phases are:
         driver in some way for the upcoming system power transition, but it
         should not put the device into a low-power state.
 
+        For devices supporting runtime power management, the return value of the
+        prepare callback can be used to indicate to the PM core that it may
+        safely leave the device in runtime suspend (if runtime-suspended
+        already), provided that all of the device's descendants are also left in
+        runtime suspend.  Namely, if the prepare callback returns a positive
+        number and that happens for all of the descendants of the device too,
+        and all of them (including the device itself) are runtime-suspended, the
+        PM core will skip the suspend, suspend_late and suspend_noirq suspend
+        phases as well as the resume_noirq, resume_early and resume phases of
+        the following system resume for all of these devices.   In that case,
+        the complete callback will be called directly after the prepare callback
+        and is entirely responsible for bringing the device back to the
+        functional state as appropriate.
+
     2.  The suspend methods should quiesce the device to stop it from performing
         I/O.  They also may save the device registers and put it into the
         appropriate low-power state, depending on the bus type the device is on,
@@ -400,12 +415,23 @@ When resuming from freeze, standby or memory sleep, the phases are:
         the resume callbacks occur; it's not necessary to wait until the
         complete phase.
 
+        Moreover, if the preceding prepare callback returned a positive number,
+        the device may have been left in runtime suspend throughout the whole
+        system suspend and resume (the suspend, suspend_late, suspend_noirq
+        phases of system suspend and the resume_noirq, resume_early, resume
+        phases of system resume may have been skipped for it).  In that case,
+        the complete callback is entirely responsible for bringing the device
+        back to the functional state after system suspend if necessary.  [For
+        example, it may need to queue up a runtime resume request for the device
+        for this purpose.]  To check if that is the case, the complete callback
+        can consult the device's power.direct_complete flag.  Namely, if that
+        flag is set when the complete callback is being run, it has been called
+        directly after the preceding prepare and special action may be required
+        to make the device work correctly afterward.
+
 At the end of these phases, drivers should be as functional as they were before
 suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are
-gated on.  Even if the device was in a low-power state before the system sleep
-because of runtime power management, afterwards it should be back in its
-full-power state.  There are multiple reasons why it's best to do this; they are
-discussed in more detail in Documentation/power/runtime_pm.txt.
+gated on.
 
 However, the details here may again be platform-specific.  For example,
 some systems support multiple "run" states, and the mode in effect at
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index b8a907dc0169..a9adad828cdc 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -10,8 +10,7 @@ Contents
 3. OPP Search Functions
 4. OPP Availability Control Functions
 5. OPP Data Retrieval Functions
-6. Cpufreq Table Generation
-7. Data Structures
+6. Data Structures
 
 1. Introduction
 ===============
@@ -72,7 +71,6 @@ operations until that OPP could be re-enabled if possible.
 OPP library facilitates this concept in it's implementation. The following
 operational functions operate only on available opps:
 opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, dev_pm_opp_get_opp_count
-and dev_pm_opp_init_cpufreq_table
 
 dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then
 be used for dev_pm_opp_enable/disable functions to make an opp available as required.
@@ -96,10 +94,9 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
 opp_get_{voltage, freq, opp_count} fall into this category.
 
 opp_{add,enable,disable} are updaters which use mutex and implement it's own
-RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and uses
-mutex to implment RCU updater strategy. These functions should *NOT* be called
-under RCU locks and other contexts that prevent blocking functions in RCU or
-mutex operations from working.
+RCU locking mechanisms. These functions should *NOT* be called under RCU locks
+and other contexts that prevent blocking functions in RCU or mutex operations
+from working.
 
 2. Initial OPP List Registration
 ================================
@@ -311,34 +308,7 @@ dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device
                 /* Do other things */
          }
 
-6. Cpufreq Table Generation
-===========================
-dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
-        cpufreq_frequency_table_cpuinfo which is provided with the list of
-        frequencies that are available for operation. This function provides
-        a ready to use conversion routine to translate the OPP layer's internal
-        information about the available frequencies into a format readily
-        providable to cpufreq.
-
-        WARNING: Do not use this function in interrupt context.
-
-        Example:
-         soc_pm_init()
-         {
-                /* Do things */
-                r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
-                if (!r)
-                        cpufreq_frequency_table_cpuinfo(policy, freq_table);
-                /* Do other things */
-         }
-
-        NOTE: This function is available only if CONFIG_CPU_FREQ is enabled in
-        addition to CONFIG_PM as power management feature is required to
-        dynamically scale voltage and frequency in a system.
-
-dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
-
-7. Data Structures
+6. Data Structures
 ==================
 Typically an SoC contains multiple voltage domains which are variable. Each
 domain is represented by a device pointer. The relationship to OPP can be
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 5f96daf8566a..f32ce5419573 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -2,6 +2,7 @@ Runtime Power Management Framework for I/O Devices
 
 (C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc.
 (C) 2010 Alan Stern <stern@rowland.harvard.edu>
+(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
 1. Introduction
 
@@ -444,6 +445,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
   bool pm_runtime_status_suspended(struct device *dev);
     - return true if the device's runtime PM status is 'suspended'
 
+  bool pm_runtime_suspended_if_enabled(struct device *dev);
+    - return true if the device's runtime PM status is 'suspended' and its
+      'power.disable_depth' field is equal to 1
+
   void pm_runtime_allow(struct device *dev);
     - set the power.runtime_auto flag for the device and decrease its usage
       counter (used by the /sys/devices/.../power/control interface to
@@ -644,19 +649,33 @@ place (in particular, if the system is not waking up from hibernation), it may
 be more efficient to leave the devices that had been suspended before the system
 suspend began in the suspended state.
 
+To this end, the PM core provides a mechanism allowing some coordination between
+different levels of device hierarchy.  Namely, if a system suspend .prepare()
+callback returns a positive number for a device, that indicates to the PM core
+that the device appears to be runtime-suspended and its state is fine, so it
+may be left in runtime suspend provided that all of its descendants are also
+left in runtime suspend.  If that happens, the PM core will not execute any
+system suspend and resume callbacks for all of those devices, except for the
+complete callback, which is then entirely responsible for handling the device
+as appropriate.  This only applies to system suspend transitions that are not
+related to hibernation (see Documentation/power/devices.txt for more
+information).
+
 The PM core does its best to reduce the probability of race conditions between
 the runtime PM and system suspend/resume (and hibernation) callbacks by carrying
 out the following operations:
 
-  * During system suspend it calls pm_runtime_get_noresume() and
-    pm_runtime_barrier() for every device right before executing the
-    subsystem-level .suspend() callback for it.  In addition to that it calls
-    __pm_runtime_disable() with 'false' as the second argument for every device
-    right before executing the subsystem-level .suspend_late() callback for it.
-
-  * During system resume it calls pm_runtime_enable() and pm_runtime_put()
-    for every device right after executing the subsystem-level .resume_early()
-    callback and right after executing the subsystem-level .resume() callback
+  * During system suspend pm_runtime_get_noresume() is called for every device
+    right before executing the subsystem-level .prepare() callback for it and
+    pm_runtime_barrier() is called for every device right before executing the
+    subsystem-level .suspend() callback for it.  In addition to that the PM core
+    calls  __pm_runtime_disable() with 'false' as the second argument for every
+    device right before executing the subsystem-level .suspend_late() callback
+    for it.
+
+  * During system resume pm_runtime_enable() and pm_runtime_put() are called for
+    every device right after executing the subsystem-level .resume_early()
+    callback and right after executing the subsystem-level .complete() callback
     for it, respectively.
 
 7. Generic subsystem callbacks
diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt
index 442d43df9b25..50f3ef9177c1 100644
--- a/Documentation/power/states.txt
+++ b/Documentation/power/states.txt
@@ -1,62 +1,87 @@
+System Power Management Sleep States
 
-System Power Management States
+(C) 2014 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>
 
+The kernel supports up to four system sleep states generically, although three
+of them depend on the platform support code to implement the low-level details
+for each state.
 
-The kernel supports four power management states generically, though
-one is generic and the other three are dependent on platform support
-code to implement the low-level details for each state.
-This file describes each state, what they are
-commonly called, what ACPI state they map to, and what string to write
-to /sys/power/state to enter that state
+The states are represented by strings that can be read or written to the
+/sys/power/state file.  Those strings may be "mem", "standby", "freeze" and
+"disk", where the last one always represents hibernation (Suspend-To-Disk) and
+the meaning of the remaining ones depends on the relative_sleep_states command
+line argument.
 
-state:          Freeze / Low-Power Idle
+For relative_sleep_states=1, the strings "mem", "standby" and "freeze" label the
+available non-hibernation sleep states from the deepest to the shallowest,
+respectively.  In that case, "mem" is always present in /sys/power/state,
+because there is at least one non-hibernation sleep state in every system.  If
+the given system supports two non-hibernation sleep states, "standby" is present
+in /sys/power/state in addition to "mem".  If the system supports three
+non-hibernation sleep states, "freeze" will be present in /sys/power/state in
+addition to "mem" and "standby".
+
+For relative_sleep_states=0, which is the default, the following descriptions
+apply.
+
+state:          Suspend-To-Idle
 ACPI state:     S0
-String:         "freeze"
+Label:          "freeze"
 
-This state is a generic, pure software, light-weight, low-power state.
-It allows more energy to be saved relative to idle by freezing user
+This state is a generic, pure software, light-weight, system sleep state.
+It allows more energy to be saved relative to runtime idle by freezing user
 space and putting all I/O devices into low-power states (possibly
 lower-power than available at run time), such that the processors can
 spend more time in their idle states.
-This state can be used for platforms without Standby/Suspend-to-RAM
+
+This state can be used for platforms without Power-On Suspend/Suspend-to-RAM
 support, or it can be used in addition to Suspend-to-RAM (memory sleep)
-to provide reduced resume latency.
+to provide reduced resume latency.  It is always supported.
 
 
 State:          Standby / Power-On Suspend
 ACPI State:     S1
-String:         "standby"
+Label:          "standby"
 
-This state offers minimal, though real, power savings, while providing
-a very low-latency transition back to a working system. No operating
-state is lost (the CPU retains power), so the system easily starts up
+This state, if supported, offers moderate, though real, power savings, while
+providing a relatively low-latency transition back to a working system.  No
+operating state is lost (the CPU retains power), so the system easily starts up
 again where it left off. 
 
-We try to put devices in a low-power state equivalent to D1, which
-also offers low power savings, but low resume latency. Not all devices
-support D1, and those that don't are left on. 
+In addition to freezing user space and putting all I/O devices into low-power
+states, which is done for Suspend-To-Idle too, nonboot CPUs are taken offline
+and all low-level system functions are suspended during transitions into this
+state.  For this reason, it should allow more energy to be saved relative to
+Suspend-To-Idle, but the resume latency will generally be greater than for that
+state.
 
 
 State:          Suspend-to-RAM
 ACPI State:     S3
-String:         "mem"
+Label:          "mem"
 
-This state offers significant power savings as everything in the
-system is put into a low-power state, except for memory, which is
-placed in self-refresh mode to retain its contents. 
+This state, if supported, offers significant power savings as everything in the
+system is put into a low-power state, except for memory, which should be placed
+into the self-refresh mode to retain its contents.  All of the steps carried out
+when entering Power-On Suspend are also carried out during transitions to STR.
+Additional operations may take place depending on the platform capabilities.  In
+particular, on ACPI systems the kernel passes control to the BIOS (platform
+firmware) as the last step during STR transitions and that usually results in
+powering down some more low-level components that aren't directly controlled by
+the kernel.
 
-System and device state is saved and kept in memory. All devices are
-suspended and put into D3. In many cases, all peripheral buses lose
-power when entering STR, so devices must be able to handle the
-transition back to the On state. 
+System and device state is saved and kept in memory.  All devices are suspended
+and put into low-power states.  In many cases, all peripheral buses lose power
+when entering STR, so devices must be able to handle the transition back to the
+"on" state.
 
-For at least ACPI, STR requires some minimal boot-strapping code to
-resume the system from STR. This may be true on other platforms. 
+For at least ACPI, STR requires some minimal boot-strapping code to resume the
+system from it.  This may be the case on other platforms too.
 
 
 State:          Suspend-to-disk
 ACPI State:     S4
-String:         "disk"
+Label:          "disk"
 
 This state offers the greatest power savings, and can be used even in
 the absence of low-level platform support for power management. This
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/power/swsusp.txt b/Documentation/power/swsusp.txt
index 079160e22bcc..f732a8321e8a 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -220,7 +220,10 @@ Q: After resuming, system is paging heavily, leading to very bad interactivity.
 
 A: Try running
 
-cat `cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u` > /dev/null
+cat /proc/[0-9]*/maps | grep / | sed 's:.* /:/:' | sort -u | while read file
+do
+  test -f "$file" && cat "$file" > /dev/null
+done
 
 after resume. swapoff -a; swapon -a may also be useful.
 
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/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt
index dc23e58ae264..9791e98ab49c 100644
--- a/Documentation/powerpc/transactional_memory.txt
+++ b/Documentation/powerpc/transactional_memory.txt
@@ -160,7 +160,7 @@ To avoid this, when taking a signal in an active transaction, we need to use
 the stack pointer from the checkpointed state, rather than the speculated
 state.  This ensures that the signal context (written tm suspended) will be
 written below the stack required for the rollback.  The transaction is aborted
-becuase of the treclaim, so any memory written between the tbegin and the
+because of the treclaim, so any memory written between the tbegin and the
 signal will be rolled back anyway.
 
 For signals taken in non-TM or suspended mode, we use the
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 6f4eb322ffaf..b4498218c474 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -199,11 +199,11 @@ struct va_format:
         Do not use this feature without some mechanism to verify the
         correctness of the format string and va_list arguments.
 
-u64 SHOULD be printed with %llu/%llx, (unsigned long long):
+u64 SHOULD be printed with %llu/%llx:
 
         printk("%llu", u64_var);
 
-s64 SHOULD be printed with %lld/%llx, (long long):
+s64 SHOULD be printed with %lld/%llx:
 
         printk("%lld", s64_var);
 
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/rbtree.txt b/Documentation/rbtree.txt
index 61b6c48871a0..39873ef41bf9 100644
--- a/Documentation/rbtree.txt
+++ b/Documentation/rbtree.txt
@@ -255,7 +255,7 @@ However, rbtree can be augmented to store such interval ranges in a structured
 way making it possible to do efficient lookup and exact match.
 
 This "extra information" stored in each node is the maximum hi
-(max_hi) value among all the nodes that are its descendents. This
+(max_hi) value among all the nodes that are its descendants. This
 information can be maintained at each node just be looking at the node
 and its immediate children. And this will be used in O(log n) lookup
 for lowest match (lowest start address among all possible matches)
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index f430004df73c..427e89712f4a 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -21,7 +21,7 @@ aircraft.
 The rfkill subsystem has a concept of "hard" and "soft" block, which
 differ little in their meaning (block == transmitters off) but rather in
 whether they can be changed or not:
- - hard block: read-only radio block that cannot be overriden by software
+ - hard block: read-only radio block that cannot be overridden by software
  - soft block: writable radio block (need not be readable) that is set by
                the system software.
 
diff --git a/Documentation/robust-futexes.txt b/Documentation/robust-futexes.txt
index 0a9446a53bd1..af6fce23e484 100644
--- a/Documentation/robust-futexes.txt
+++ b/Documentation/robust-futexes.txt
@@ -210,7 +210,7 @@ i386 and x86_64 syscalls are wired up at the moment, and Ulrich has
 tested the new glibc code (on x86_64 and i386), and it works for his
 robust-mutex testcases.
 
-All other architectures should build just fine too - but they wont have
+All other architectures should build just fine too - but they won't have
 the new syscalls yet.
 
 Architectures need to implement the new futex_atomic_cmpxchg_inatomic()
diff --git a/Documentation/s390/monreader.txt b/Documentation/s390/monreader.txt
index beeaa4b24427..d3729585fdb0 100644
--- a/Documentation/s390/monreader.txt
+++ b/Documentation/s390/monreader.txt
@@ -10,7 +10,7 @@ Author: Gerald Schaefer (geraldsc@de.ibm.com)
 Description
 ===========
 This item delivers a new Linux API in the form of a misc char device that is
-useable from user space and allows read access to the z/VM Monitor Records
+usable from user space and allows read access to the z/VM Monitor Records
 collected by the *MONITOR System Service of z/VM.
 
 
diff --git a/Documentation/s390/zfcpdump.txt b/Documentation/s390/zfcpdump.txt
index cf45d27c4608..dc929be96016 100644
--- a/Documentation/s390/zfcpdump.txt
+++ b/Documentation/s390/zfcpdump.txt
@@ -1,15 +1,15 @@
-s390 SCSI dump tool (zfcpdump)
+The s390 SCSI dump tool (zfcpdump)
 
 System z machines (z900 or higher) provide hardware support for creating system
 dumps on SCSI disks. The dump process is initiated by booting a dump tool, which
 has to create a dump of the current (probably crashed) Linux image. In order to
 not overwrite memory of the crashed Linux with data of the dump tool, the
-hardware saves some memory plus the register sets of the boot cpu before the
+hardware saves some memory plus the register sets of the boot CPU before the
 dump tool is loaded. There exists an SCLP hardware interface to obtain the saved
 memory afterwards. Currently 32 MB are saved.
 
 This zfcpdump implementation consists of a Linux dump kernel together with
-a userspace dump tool, which are loaded together into the saved memory region
+a user space dump tool, which are loaded together into the saved memory region
 below 32 MB. zfcpdump is installed on a SCSI disk using zipl (as contained in
 the s390-tools package) to make the device bootable. The operator of a Linux
 system can then trigger a SCSI dump by booting the SCSI disk, where zfcpdump
@@ -19,68 +19,33 @@ The kernel part of zfcpdump is implemented as a debugfs file under "zcore/mem",
 which exports memory and registers of the crashed Linux in an s390
 standalone dump format. It can be used in the same way as e.g. /dev/mem. The
 dump format defines a 4K header followed by plain uncompressed memory. The
-register sets are stored in the prefix pages of the respective cpus. To build a
+register sets are stored in the prefix pages of the respective CPUs. To build a
 dump enabled kernel with the zcore driver, the kernel config option
-CONFIG_ZFCPDUMP has to be set. When reading from "zcore/mem", the part of
+CONFIG_CRASH_DUMP has to be set. When reading from "zcore/mem", the part of
 memory, which has been saved by hardware is read by the driver via the SCLP
 hardware interface. The second part is just copied from the non overwritten real
 memory.
 
-The userspace application of zfcpdump can reside e.g. in an intitramfs or an
-initrd. It reads from zcore/mem and writes the system dump to a file on a
-SCSI disk.
+Since kernel version 3.12 also the /proc/vmcore file can also be used to access
+the dump.
 
-To build a zfcpdump kernel use the following settings in your kernel
-configuration:
- * CONFIG_ZFCPDUMP=y
- * Enable ZFCP driver
- * Enable SCSI driver
- * Enable ext2 and ext3 filesystems
- * Disable as many features as possible to keep the kernel small.
-   E.g. network support is not needed at all.
+To get a valid zfcpdump kernel configuration use "make zfcpdump_defconfig".
 
-To use the zfcpdump userspace application in an initramfs you have to do the
-following:
+The s390 zipl tool looks for the zfcpdump kernel and optional initrd/initramfs
+under the following locations:
 
- * Copy the zfcpdump executable somewhere into your Linux tree.
-   E.g. to "arch/s390/boot/zfcpdump. If you do not want to include
-   shared libraries, compile the tool with the "-static" gcc option.
- * If you want to include e2fsck, add it to your source tree, too. The zfcpdump
-   application attempts to start /sbin/e2fsck from the ramdisk.
- * Use an initramfs config file like the following:
+* kernel:  <zfcpdump directory>/zfcpdump.image
+* ramdisk: <zfcpdump directory>/zfcpdump.rd
 
-   dir /dev 755 0 0
-   nod /dev/console 644 0 0 c 5 1
-   nod /dev/null 644 0 0 c 1 3
-   nod /dev/sda1 644 0 0 b 8 1
-   nod /dev/sda2 644 0 0 b 8 2
-   nod /dev/sda3 644 0 0 b 8 3
-   nod /dev/sda4 644 0 0 b 8 4
-   nod /dev/sda5 644 0 0 b 8 5
-   nod /dev/sda6 644 0 0 b 8 6
-   nod /dev/sda7 644 0 0 b 8 7
-   nod /dev/sda8 644 0 0 b 8 8
-   nod /dev/sda9 644 0 0 b 8 9
-   nod /dev/sda10 644 0 0 b 8 10
-   nod /dev/sda11 644 0 0 b 8 11
-   nod /dev/sda12 644 0 0 b 8 12
-   nod /dev/sda13 644 0 0 b 8 13
-   nod /dev/sda14 644 0 0 b 8 14
-   nod /dev/sda15 644 0 0 b 8 15
-   file /init arch/s390/boot/zfcpdump 755 0 0
-   file /sbin/e2fsck arch/s390/boot/e2fsck 755 0 0
-   dir /proc 755 0 0
-   dir /sys 755 0 0
-   dir /mnt 755 0 0
-   dir /sbin 755 0 0
+The zfcpdump directory is defined in the s390-tools package.
 
- * Issue "make image" to build the zfcpdump image with initramfs.
+The user space application of zfcpdump can reside in an intitramfs or an
+initrd. It can also be included in a built-in kernel initramfs. The application
+reads from /proc/vmcore or zcore/mem and writes the system dump to a SCSI disk.
 
-In a Linux distribution the zfcpdump enabled kernel image must be copied to
-/usr/share/zfcpdump/zfcpdump.image, where the s390 zipl tool is looking for the
-dump kernel when preparing a SCSI dump disk.
-
-If you use a ramdisk copy it to "/usr/share/zfcpdump/zfcpdump.rd".
+The s390-tools package version 1.24.0 and above builds an external zfcpdump
+initramfs with a user space application that writes the dump to a SCSI
+partition.
 
 For more information on how to use zfcpdump refer to the s390 'Using the Dump
 Tools book', which is available from
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/security/Yama.txt b/Documentation/security/Yama.txt
index dd908cf64ecf..227a63f018a2 100644
--- a/Documentation/security/Yama.txt
+++ b/Documentation/security/Yama.txt
@@ -37,7 +37,7 @@ still work as root).
 In mode 1, software that has defined application-specific relationships
 between a debugging process and its inferior (crash handlers, etc),
 prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which
-other process (and its descendents) are allowed to call PTRACE_ATTACH
+other process (and its descendants) are allowed to call PTRACE_ATTACH
 against it. Only one such declared debugging process can exists for
 each inferior at a time. For example, this is used by KDE, Chromium, and
 Firefox's crash handlers, and by Wine for allowing only Wine processes
diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index f9c6b5ed03e7..8021a9f29fc5 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -2,23 +2,15 @@
         - this file.
 README.cycladesZ
         - info on Cyclades-Z firmware loading.
-digiepca.txt
-        - info on Digi Intl. {PC,PCI,EISA}Xx and Xem series cards.
 driver
         - intro to the low level serial driver.
 moxa-smartio
         - file with info on installing/using Moxa multiport serial driver.
 n_gsm.txt
         - GSM 0710 tty multiplexer howto.
-riscom8.txt
-        - notes on using the RISCom/8 multi-port serial driver.
 rocket.txt
         - info on the Comtrol RocketPort multiport serial driver.
 serial-rs485.txt
         - info about RS485 structures and support in the kernel.
-specialix.txt
-        - info on hardware/driver for specialix IO8+ multiport serial card.
-sx.txt
-        - info on the Specialix SX/SI multiport serial driver.
 tty.txt
         - guide to the locking policies of the tty layer.
diff --git a/Documentation/serial/digiepca.txt b/Documentation/serial/digiepca.txt
deleted file mode 100644
index f2560e22f2c9..000000000000
--- a/Documentation/serial/digiepca.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-NOTE:  This driver is obsolete.  Digi provides a 2.6 driver (dgdm) at
-http://www.digi.com for PCI cards.  They no longer maintain this driver,
-and have no 2.6 driver for ISA cards.
-
-This driver requires a number of user-space tools.  They can be acquired from
-http://www.digi.com, but only works with 2.4 kernels.
-
-
-The Digi Intl. epca driver. 
-----------------------------
-The Digi Intl. epca driver for Linux supports the following boards:
-
-Digi PC/Xem, PC/Xr, PC/Xe, PC/Xi, PC/Xeve 
-Digi EISA/Xem, PCI/Xem, PCI/Xr 
-
-Limitations:
-------------
-Currently the driver only autoprobes for supported PCI boards. 
-
-The Linux MAKEDEV command does not support generating the Digiboard
-Devices.  Users executing digiConfig to setup EISA and PC series cards
-will have their device nodes automatically constructed (cud?? for ~CLOCAL,
-and ttyD?? for CLOCAL).  Users wishing to boot their board from the LILO
-prompt, or those users booting PCI cards may use buildDIGI to construct 
-the necessary nodes. 
-
-Notes:
-------
-This driver may be configured via LILO.  For users who have already configured
-their driver using digiConfig, configuring from LILO will override previous 
-settings.  Multiple boards may be configured by issuing multiple LILO command 
-lines.  For examples see the bottom of this document.
-
-Device names start at 0 and continue up.  Beware of this as previous Digi 
-drivers started device names with 1.
-
-PCI boards are auto-detected and configured by the driver.  PCI boards will
-be allocated device numbers (internally) beginning with the lowest PCI slot
-first.  In other words a PCI card in slot 3 will always have higher device
-nodes than a PCI card in slot 1. 
-
-LILO config examples:
----------------------
-Using LILO's APPEND command, a string of comma separated identifiers or 
-integers can be used to configure supported boards.  The six values in order 
-are:
-
-   Enable/Disable this card or Override,
-   Type of card: PC/Xe (AccelePort) (0), PC/Xeve (1), PC/Xem or PC/Xr (2), 
-                 EISA/Xem (3), PC/64Xe (4), PC/Xi (5), 
-   Enable/Disable alternate pin arrangement,
-   Number of ports on this card,
-   I/O Port where card is configured (in HEX if using string identifiers),
-   Base of memory window (in HEX if using string identifiers), 
-
-NOTE : PCI boards are auto-detected and configured.  Do not attempt to 
-configure PCI boards with the LILO append command.  If you wish to override
-previous configuration data (As set by digiConfig), but you do not wish to
-configure any specific card (Example if there are PCI cards in the system) 
-the following override command will accomplish this:
--> append="digi=2"
-
-Samples:
-   append="digiepca=E,PC/Xe,D,16,200,D0000"
-                  or
-   append="digi=1,0,0,16,512,851968"
-
-Supporting Tools:
------------------
-Supporting tools include digiDload, digiConfig, buildPCI, and ditty.  See
-drivers/char/README.epca for more details.  Note,
-this driver REQUIRES that digiDload be executed prior to it being used. 
-Failure to do this will result in an ENODEV error.
-
-Documentation:
---------------
-Complete documentation for this product may be found in the tool package. 
-
-Sources of information and support:
------------------------------------
-Digi Intl. support site for this product:
-
-->  http://www.digi.com
-
-Acknowledgments:
-----------------
-Much of this work (And even text) was derived from a similar document 
-supporting the original public domain DigiBoard driver Copyright (C)
-1994,1995 Troy De Jongh.  Many thanks to Christoph Lameter 
-(christoph@lameter.com) and Mike McLagan (mike.mclagan@linux.org) who authored 
-and contributed to the original document. 
-
-Changelog:
-----------
-10-29-04:       Update status of driver, remove dead links in document
-                James Nelson <james4765@gmail.com>
-
-2000 (?)        Original Document
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index c3a7689a90e6..3bba1aeb799c 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -429,3 +429,28 @@ thus:
                 struct uart_port        port;
                 int                     my_stuff;
         };
+
+Modem control lines via GPIO
+----------------------------
+
+Some helpers are provided in order to set/get modem control lines via GPIO.
+
+mctrl_gpio_init(dev, idx):
+        This will get the {cts,rts,...}-gpios from device tree if they are
+        present and request them, set direction etc, and return an
+        allocated structure. devm_* functions are used, so there's no need
+        to call mctrl_gpio_free().
+
+mctrl_gpio_free(dev, gpios):
+        This will free the requested gpios in mctrl_gpio_init().
+        As devm_* function are used, there's generally no need to call
+        this function.
+
+mctrl_gpio_to_gpiod(gpios, gidx)
+        This returns the gpio structure associated to the modem line index.
+
+mctrl_gpio_set(gpios, mctrl):
+        This will sets the gpios according to the mctrl state.
+
+mctrl_gpio_get(gpios, mctrl):
+        This will update mctrl with the gpios values.
diff --git a/Documentation/serial/riscom8.txt b/Documentation/serial/riscom8.txt
deleted file mode 100644
index 14f61fdad7ca..000000000000
--- a/Documentation/serial/riscom8.txt
+++ /dev/null
@@ -1,36 +0,0 @@
-* NOTE - this is an unmaintained driver.  The original author cannot be located.
-
-SDL Communications is now SBS Technologies, and does not have any
-information on these ancient ISA cards on their website.
-
-James Nelson <james4765@gmail.com> - 12-12-2004
-
-        This is the README for RISCom/8 multi-port serial driver
-        (C) 1994-1996 D.Gorodchanin
-        See file LICENSE for terms and conditions.
-
-NOTE: English is not my native language. 
-      I'm sorry for any mistakes in this text.
-
-Misc. notes for RISCom/8 serial driver, in no particular order :)
-
-1) This driver can support up to 4 boards at time.
-   Use string "riscom8=0xXXX,0xXXX,0xXXX,0xXXX" at LILO prompt, for
-   setting I/O base addresses for boards. If you compile driver
-   as module use modprobe options "iobase=0xXXX iobase1=0xXXX iobase2=..."
-
-2) The driver partially supports famous 'setserial' program, you can use almost
-   any of its options, excluding port & irq settings.
-
-3) There are some misc. defines at the beginning of riscom8.c, please read the 
-   comments and try to change some of them in case of problems.
-
-4) I consider the current state of the driver as BETA.
-
-5) SDL Communications WWW page is http://www.sdlcomm.com.
-
-6) You can use the MAKEDEV program to create RISCom/8 /dev/ttyL* entries.
-
-7) Minor numbers for first board are 0-7, for second 8-15, etc.
-
-22 Apr 1996.
diff --git a/Documentation/serial/specialix.txt b/Documentation/serial/specialix.txt
deleted file mode 100644
index 6eb6f3a3331c..000000000000
--- a/Documentation/serial/specialix.txt
+++ /dev/null
@@ -1,383 +0,0 @@
-
-      specialix.txt  -- specialix IO8+ multiport serial driver readme.
-
-
-
-      Copyright (C) 1997  Roger Wolff (R.E.Wolff@BitWizard.nl)
-
-      Specialix pays for the development and support of this driver.
-      Please DO contact io8-linux@specialix.co.uk if you require
-      support.
-
-      This driver was developed in the BitWizard linux device
-      driver service. If you require a linux device driver for your
-      product, please contact devices@BitWizard.nl for a quote.
-
-      This code is firmly based on the riscom/8 serial driver,
-      written by Dmitry Gorodchanin. The specialix IO8+ card
-      programming information was obtained from the CL-CD1865 Data
-      Book, and Specialix document number 6200059: IO8+ Hardware
-      Functional Specification, augmented by document number 6200088:
-      Merak Hardware Functional Specification. (IO8+/PCI is also 
-      called Merak)
-
-
-      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.
-
-      You should have received a copy of the GNU General Public
-      License along with this program; if not, write to the Free
-      Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
-      USA.
-
-
-Intro
-=====
-
- 
-This file contains some random information, that I like to have online
-instead of in a manual that can get lost. Ever misplace your Linux
-kernel sources?  And the manual of one of the boards in your computer?
-
-
-Addresses and interrupts
-========================
-
-Address dip switch settings:
-The dip switch sets bits 2-9 of the IO address. 
-
-       9 8 7 6 5 4 3 2 
-     +-----------------+
-   0 | X   X X X X X X |
-     |                 |    =   IoBase = 0x100 
-   1 |   X             |
-     +-----------------+          ------ RS232 connectors ---->
-         
-         |    |    |
-       edge connector
-         |    |    |
-         V    V    V
-
-Base address 0x100 caused a conflict in one of my computers once.  I
-haven't the foggiest why. My Specialix card is now at 0x180.  My
-other computer runs just fine with the Specialix card at 0x100....
-The card occupies 4 addresses, but actually only two are really used.
-
-The PCI version doesn't have any dip switches. The BIOS assigns
-an IO address. 
-
-The driver now still autoprobes at 0x100, 0x180, 0x250 and 0x260.  If
-that causes trouble for you, please report that. I'll remove
-autoprobing then.
-
-The driver will tell the card what IRQ to use, so you don't have to
-change any jumpers to change the IRQ. Just use a command line
-argument (irq=xx) to the insmod program to set the interrupt.
-
-The BIOS assigns the IRQ on the PCI version. You have no say in what
-IRQ to use in that case. 
-
-If your specialix cards are not at the default locations, you can use
-the kernel command line argument "specialix=io0,irq0,io1,irq1...".
-Here "io0" is the io address for the first card, and "irq0" is the
-irq line that the first card should use. And so on. 
-
-Examples. 
-
-You use the driver as a module and have three cards at 0x100, 0x250
-and 0x180. And some way or another you want them detected in that
-order. Moreover irq 12 is taken (e.g. by your PS/2 mouse).
-
-  insmod specialix.o iobase=0x100,0x250,0x180 irq=9,11,15
-
-The same three cards, but now in the kernel would require you to
-add 
-
-   specialix=0x100,9,0x250,11,0x180,15
-
-to the command line. This would become 
-
-   append="specialix=0x100,9,0x250,11,0x180,15" 
-
-in your /etc/lilo.conf file if you use lilo. 
-
-The Specialix driver is slightly odd: It allows you to have the second
-or third card detected without having a first card. This has
-advantages and disadvantages. A slot that isn't filled by an ISA card,
-might be filled if a PCI card is detected. Thus if you have an ISA
-card at 0x250 and a PCI card, you would get:
-
-sx0: specialix IO8+ Board at 0x100 not found.
-sx1: specialix IO8+ Board at 0x180 not found.
-sx2: specialix IO8+ board detected at 0x250, IRQ 12, CD1865 Rev. B.
-sx3: specialix IO8+ Board at 0x260 not found.
-sx0: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B.
-
-This would happen if you don't give any probe hints to the driver. 
-If you would specify:
-
-   specialix=0x250,11
-
-you'd get the following messages:
-
-sx0: specialix IO8+ board detected at 0x250, IRQ 11, CD1865 Rev. B.
-sx1: specialix IO8+ board detected at 0xd800, IRQ 9, CD1865 Rev. B.
-
-ISA probing is aborted after the IO address you gave is exhausted, and
-the PCI card is now detected as the second card. The ISA card is now
-also forced to IRQ11....
-
-
-Baud rates
-==========
-
-The rev 1.2 and below boards use a CL-CD1864. These chips can only 
-do 64kbit. The rev 1.3 and newer boards use a CL-CD1865. These chips
-are officially capable of 115k2.
-
-The Specialix card uses a 25MHz crystal (in times two mode, which in
-fact is a divided by two mode). This is not enough to reach the rated
-115k2 on all ports at the same time. With this clock rate you can only
-do 37% of this rate. This means that at 115k2 on all ports you are
-going to lose characters (The chip cannot handle that many incoming
-bits at this clock rate.) (Yes, you read that correctly: there is a
-limit to the number of -=bits=- per second that the chip can handle.)
-
-If you near the "limit" you will first start to see a graceful
-degradation in that the chip cannot keep the transmitter busy at all
-times. However with a central clock this slow, you can also get it to
-miss incoming characters. The driver will print a warning message when
-you are outside the official specs. The messages usually show up in
-the file /var/log/messages .
-
-The specialix card cannot reliably do 115k2. If you use it, you have
-to do "extensive testing" (*) to verify if it actually works.
-
-When "mgetty" communicates with my modem at 115k2 it reports:
-got: +++[0d]ATQ0V1H0[0d][0d][8a]O[cb][0d][8a]
-                            ^^^^ ^^^^    ^^^^ 
-
-The three characters that have the "^^^" under them have suffered a
-bit error in the highest bit. In conclusion: I've tested it, and found
-that it simply DOESN'T work for me. I also suspect that this is also
-caused by the baud rate being just a little bit out of tune. 
-
-I upgraded the crystal to 66Mhz on one of my Specialix cards. Works
-great! Contact me for details. (Voids warranty, requires a steady hand
-and more such restrictions....)
-
-
-(*) Cirrus logic CD1864 databook, page 40.
-
-
-Cables for the Specialix IO8+
-=============================
-
-The pinout of the connectors on the IO8+ is:
-
-     pin    short    direction    long name
-            name
-    Pin 1   DCD      input        Data Carrier Detect
-    Pin 2   RXD      input        Receive
-    Pin 3   DTR/RTS  output       Data Terminal Ready/Ready To Send
-    Pin 4   GND      -            Ground
-    Pin 5   TXD      output       Transmit
-    Pin 6   CTS      input        Clear To Send
-        
-    
-             -- 6  5  4  3  2  1 --
-             |                    |
-             |                    |
-             |                    |
-             |                    |
-             +-----          -----+
-                  |__________|
-                      clip
-    
-    Front view of an RJ12 connector. Cable moves "into" the paper.
-    (the plug is ready to plug into your mouth this way...)
-
-    
-    NULL cable. I don't know who is going to use these except for
-    testing purposes, but I tested the cards with this cable. (It 
-    took quite a while to figure out, so I'm not going to delete
-    it. So there! :-)
-    
-    
-    This end goes               This end needs
-    straight into the           some twists in
-    RJ12 plug.                  the wiring.
-       IO8+ RJ12                   IO8+ RJ12
-        1  DCD       white          -
-        -             -             1 DCD
-        2  RXD       black          5 TXD
-        3  DTR/RTS   red            6 CTS
-        4  GND       green          4 GND
-        5  TXD       yellow         2 RXD
-        6  CTS       blue           3 DTR/RTS
-    
-
-    Same NULL cable, but now sorted on the second column.
- 
-        1  DCD       white          -
-        -             -             1 DCD
-        5  TXD       yellow         2 RXD
-        6  CTS       blue           3 DTR/RTS
-        4  GND       green          4 GND
-        2  RXD       black          5 TXD
-        3  DTR/RTS   red            6 CTS
-    
-    
-    
-    This is a modem cable usable for hardware handshaking:
-        RJ12                        DB25           DB9
-        1   DCD      white          8 DCD          1 DCD
-        2   RXD      black          3 RXD          2 RXD
-        3   DTR/RTS  red            4 RTS          7 RTS
-        4   GND      green          7 GND          5 GND
-        5   TXD      yellow         2 TXD          3 TXD
-        6   CTS      blue           5 CTS          8 CTS
-                            +----   6 DSR          6 DSR
-                            +----  20 DTR          4 DTR
-
-    This is a modem cable usable for software handshaking:
-    It allows you to reset the modem using the DTR ioctls.
-    I (REW) have never tested this, "but xxxxxxxxxxxxx
-    says that it works." If you test this, please
-    tell me and I'll fill in your name on the xxx's.
-
-        RJ12                        DB25           DB9
-        1   DCD      white          8 DCD          1 DCD
-        2   RXD      black          3 RXD          2 RXD
-        3   DTR/RTS  red           20 DTR          4 DTR
-        4   GND      green          7 GND          5 GND
-        5   TXD      yellow         2 TXD          3 TXD
-        6   CTS      blue           5 CTS          8 CTS
-                            +----   6 DSR          6 DSR
-                            +----   4 RTS          7 RTS
-
-   I bought a 6 wire flat cable. It was colored as indicated.
-   Check that yours is the same before you trust me on this.
-   
- 
-Hardware handshaking issues.
-============================
-
-The driver can be told to operate in two different ways. The default
-behaviour is specialix.sx_rtscts = 0 where the pin behaves as DTR when
-hardware handshaking is off. It behaves as the RTS hardware
-handshaking signal when hardware handshaking is selected.
-
-When you use this, you have to use the appropriate cable. The
-cable will either be compatible with hardware handshaking or with
-software handshaking. So switching on the fly is not really an
-option.
-
-I actually prefer to use the "specialix.sx_rtscts=1" option.
-This makes the DTR/RTS pin always an RTS pin, and ioctls to
-change DTR are always ignored. I have a cable that is configured
-for this. 
-
-
-Ports and devices
-=================
-
-Port 0 is the one furthest from the card-edge connector.
-
-Devices:
-
-You should make the devices as follows:
-
-bash
-cd /dev
-for i in  0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15 \
-         16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
-do
-  echo -n "$i "
-  mknod /dev/ttyW$i c 75 $i
-  mknod /dev/cuw$i c 76 $i
-done
-echo ""
-
-If your system doesn't come with these devices preinstalled, bug your
-linux-vendor about this. They have had ample time to get this
-implemented by now.
-
-You cannot have more than 4 boards in one computer. The card only
-supports 4 different interrupts. If you really want this, contact me
-about this and I'll give you a few tips (requires soldering iron)....
-
-If you have enough PCI slots, you can probably use more than 4 PCI
-versions of the card though.... 
-
-The PCI version of the card cannot adhere to the mechanical part of
-the PCI spec because the 8 serial connectors are simply too large. If
-it doesn't fit in your computer, bring back the card.
-
-
-------------------------------------------------------------------------
-
-
-  Fixed bugs and restrictions:
-       - During initialization, interrupts are blindly turned on.
-            Having a shadow variable would cause an extra memory
-            access on every IO instruction. 
-       - The interrupt (on the card) should be disabled when we
-         don't allocate the Linux end of the interrupt. This allows 
-         a different driver/card to use it while all ports are not in
-         use..... (a la standard serial port)
-       == An extra _off variant of the sx_in and sx_out macros are
-          now available. They don't set the interrupt enable bit.
-          These are used during initialization. Normal operation uses
-          the old variant which enables the interrupt line.
-       - RTS/DTR issue needs to be implemented according to 
-         specialix' spec.
-            I kind of like the "determinism" of the current 
-            implementation. Compile time flag?
-       == Ok. Compile time flag! Default is how Specialix likes it.
-       == Now a config time flag! Gets saved in your config file. Neat!
-       - Can you set the IO address from the lilo command line?
-            If you need this, bug me about it, I'll make it. 
-       == Hah! No bugging needed. Fixed! :-)
-       - Cirrus logic hasn't gotten back to me yet why the CD1865 can
-            and the CD1864 can't do 115k2. I suspect that this is
-            because the CD1864 is not rated for 33MHz operation.
-            Therefore the CD1864 versions of the card can't do 115k2 on 
-            all ports just like the CD1865 versions. The driver does
-            not block 115k2 on CD1864 cards. 
-        == I called the Cirrus Logic representative here in Holland.
-           The CD1864 databook is identical to the CD1865 databook, 
-           except for an extra warning at the end. Similar Bit errors
-           have been observed in testing at 115k2 on both an 1865 and
-           a 1864 chip. I see no reason why I would prohibit 115k2 on
-           1864 chips and not do it on 1865 chips. Actually there is
-           reason to prohibit it on BOTH chips. I print a warning.
-           If you use 115k2, you're on your own. 
-       - A spiky CD may send spurious HUPs. Also in CLOCAL???
-         -- A fix for this turned out to be counter productive. 
-            Different fix? Current behaviour is acceptable?
-         -- Maybe the current implementation is correct. If anybody
-            gets bitten by this, please report, and it will get fixed.
-
-         -- Testing revealed that when in CLOCAL, the problem doesn't
-            occur. As warned for in the CD1865 manual, the chip may
-            send modem intr's on a spike. We could filter those out,
-            but that would be a cludge anyway (You'd still risk getting
-            a spurious HUP when two spikes occur.).....
- 
-
-
-  Bugs & restrictions:
-       - This is a difficult card to autoprobe.
-            You have to WRITE to the address register to even 
-            read-probe a CD186x register. Disable autodetection?
-         -- Specialix: any suggestions?
-
-
diff --git a/Documentation/serial/sx.txt b/Documentation/serial/sx.txt
deleted file mode 100644
index cb4efa0fb5cc..000000000000
--- a/Documentation/serial/sx.txt
+++ /dev/null
@@ -1,294 +0,0 @@
-
-      sx.txt  -- specialix SX/SI multiport serial driver readme.
-
-
-
-      Copyright (C) 1997  Roger Wolff (R.E.Wolff@BitWizard.nl)
-
-      Specialix pays for the development and support of this driver.
-      Please DO contact support@specialix.co.uk if you require
-      support.
-
-      This driver was developed in the BitWizard linux device
-      driver service. If you require a linux device driver for your
-      product, please contact devices@BitWizard.nl for a quote.
-
-      (History)
-      There used to be an SI driver by Simon Allan. This is a complete 
-      rewrite  from scratch. Just a few lines-of-code have been snatched.
-
-      (Sources)
-      Specialix document number 6210028: SX Host Card and Download Code
-      Software Functional Specification.
-
-      (Copying)
-      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.
-
-      You should have received a copy of the GNU General Public
-      License along with this program; if not, write to the Free
-      Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139,
-      USA.
-      
-      (Addendum)
-      I'd appreciate it that if you have fixes, that you send them
-      to me first. 
-
-
-Introduction
-============
-
-This file contains some random information, that I like to have online
-instead of in a manual that can get lost. Ever misplace your Linux
-kernel sources?  And the manual of one of the boards in your computer?
-
-
-Theory of operation
-===================
-
-An important thing to know is that the driver itself doesn't have the
-firmware for the card. This means that you need the separate package
-"sx_firmware". For now you can get the source at
-
-        ftp://ftp.bitwizard.nl/specialix/sx_firmware_<version>.tgz
-
-The firmware load needs a "misc" device, so you'll need to enable the
-"Support for user misc device modules" in your kernel configuration.
-The misc device needs to be called "/dev/specialix_sxctl". It needs
-misc major 10, and minor number 167 (assigned by HPA). The section
-on creating device files below also creates this device. 
-
-After loading the sx.o module into your kernel, the driver will report
-the number of cards detected, but because it doesn't have any
-firmware, it will not be able to determine the number of ports. Only
-when you then run "sx_firmware" will the firmware be downloaded and
-the rest of the driver initialized. At that time the sx_firmware
-program will report the number of ports installed.
-
-In contrast with many other multi port serial cards, some of the data
-structures are only allocated when the card knows the number of ports
-that are connected. This means we won't waste memory for 120 port
-descriptor structures when you only have 8 ports. If you experience
-problems due to this, please report them: I haven't seen any.
-
-
-Interrupts
-==========
-
-A multi port serial card, would generate a horrendous amount of
-interrupts if it would interrupt the CPU for every received
-character. Even more than 10 years ago, the trick not to use
-interrupts but to poll the serial cards was invented.
-
-The SX card allow us to do this two ways. First the card limits its
-own interrupt rate to a rate that won't overwhelm the CPU. Secondly,
-we could forget about the cards interrupt completely and use the
-internal timer for this purpose.
-
-Polling the card can take up to a few percent of your CPU. Using the
-interrupts would be better if you have most of the ports idle. Using
-timer-based polling is better if your card almost always has work to
-do. You save the separate interrupt in that case.
-
-In any case, it doesn't really matter all that much. 
-
-The most common problem with interrupts is that for ISA cards in a PCI
-system the BIOS has to be told to configure that interrupt as "legacy
-ISA". Otherwise the card can pull on the interrupt line all it wants
-but the CPU won't see this.
-
-If you can't get the interrupt to work, remember that polling mode is
-more efficient (provided you actually use the card intensively).
-
-
-Allowed Configurations
-======================
-
-Some configurations are disallowed. Even though at a glance they might
-seem to work, they are known to lockup the bus between the host card
-and the device concentrators. You should respect the drivers decision
-not to support certain configurations. It's there for a reason.
-
-Warning: Seriously technical stuff ahead. Executive summary: Don't use
-SX cards except configured at a 64k boundary. Skip the next paragraph.
-
-The SX cards can theoretically be placed at a 32k boundary. So for
-instance you can put an SX card at 0xc8000-0xd7fff. This is not a
-"recommended configuration". ISA cards have to tell the bus controller
-how they like their timing. Due to timing issues they have to do this
-based on which 64k window the address falls into. This means that the
-32k window below and above the SX card have to use exactly the same
-timing as the SX card. That reportedly works for other SX cards. But
-you're still left with two useless 32k windows that should not be used
-by anybody else.
-
-
-Configuring the driver
-======================
-
-PCI cards are always detected. The driver auto-probes for ISA cards at
-some sensible addresses. Please report if the auto-probe causes trouble
-in your system, or when a card isn't detected.
-
-I'm afraid I haven't implemented "kernel command line parameters" yet.
-This means that if the default doesn't work for you, you shouldn't use
-the compiled-into-the-kernel version of the driver. Use a module
-instead.  If you convince me that you need this, I'll make it for
-you. Deal?
-
-I'm afraid that the module parameters are a bit clumsy. If you have a
-better idea, please tell me.
-
-You can specify several parameters:
-
-        sx_poll: number of jiffies between timer-based polls.
-
-                Set this to "0" to disable timer based polls. 
-                Initialization of cards without a working interrupt
-                will fail.
-
-                Set this to "1" if you want a polling driver. 
-                (on Intel: 100 polls per second). If you don't use
-                fast baud rates, you might consider a value like "5". 
-                (If you don't know how to do the math, use 1).
-
-        sx_slowpoll: Number of jiffies between timer-based polls. 
-                Set this to "100" to poll once a second. 
-                This should get the card out of a stall if the driver
-                ever misses an interrupt. I've never seen this happen,
-                and if it does, that's a bug. Tell me. 
-
-        sx_maxints: Number of interrupts to request from the card. 
-                The card normally limits interrupts to about 100 per
-                second to offload the host CPU. You can increase this
-                number to reduce latency on the card a little.
-                Note that if you give a very high number you can overload
-                your CPU as well as the CPU on the host card. This setting 
-                is inaccurate and not recommended for SI cards (But it 
-                works). 
-
-        sx_irqmask: The mask of allowable IRQs to use. I suggest you set 
-                this to 0 (disable IRQs all together) and use polling if 
-                the assignment of IRQs becomes problematic. This is defined
-                as the sum of (1 << irq) 's that you want to allow. So 
-                sx_irqmask of 8 (1 << 3) specifies that only irq 3 may
-                be used by the SX driver. If you want to specify to the 
-                driver: "Either irq 11 or 12 is ok for you to use", then
-                specify (1 << 11) | (1 << 12) = 0x1800 . 
-
-        sx_debug: You can enable different sorts of debug traces with this. 
-                At "-1" all debugging traces are active. You'll get several
-                times more debugging output than you'll get characters 
-                transmitted. 
-
-
-Baud rates
-==========
-
-Theoretically new SXDCs should be capable of more than 460k
-baud. However the line drivers usually give up before that.  Also the
-CPU on the card may not be able to handle 8 channels going at full
-blast at that speed. Moreover, the buffers are not large enough to
-allow operation with 100 interrupts per second. You'll have to realize
-that the card has a 256 byte buffer, so you'll have to increase the
-number of interrupts per second if you have more than 256*100 bytes
-per second to transmit.  If you do any performance testing in this
-area, I'd be glad to hear from you...
-
-(Psst Linux users..... I think the Linux driver is more efficient than
-the driver for other OSes. If you can and want to benchmark them
-against each other, be my guest, and report your findings...... :-)
-
-
-Ports and devices
-=================
-
-Port 0 is the top connector on the module closest to the host
-card. Oh, the ports on the SXDCs and TAs are labelled from 1 to 8
-instead of from 0 to 7, as they are numbered by linux. I'm stubborn in
-this: I know for sure that I wouldn't be able to calculate which port
-is which anymore if I would change that....
-
-
-Devices:
-
-You should make the device files as follows:
-
-#!/bin/sh
-# (I recommend that you cut-and-paste this into a file and run that)
-cd /dev
-t=0
-mknod specialix_sxctl c 10 167
-while [ $t -lt 64 ]
-  do 
-  echo -n "$t "
-  mknod ttyX$t c 32 $t
-  mknod cux$t  c 33 $t
-  t=`expr $t + 1`
-done
-echo ""
-rm /etc/psdevtab
-ps > /dev/null
-
-
-This creates 64 devices. If you have more, increase the constant on
-the line with "while". The devices start at 0, as is customary on
-Linux. Specialix seems to like starting the numbering at 1. 
-
-If your system doesn't come with these devices pre-installed, bug your
-linux-vendor about this. They should have these devices
-"pre-installed" before the new millennium. The "ps" stuff at the end
-is to "tell" ps that the new devices exist.
-
-Officially the maximum number of cards per computer is 4. This driver
-however supports as many cards in one machine as you want. You'll run
-out of interrupts after a few, but you can switch to polled operation
-then. At about 256 ports (More than 8 cards), we run out of minor
-device numbers. Sorry. I suggest you buy a second computer.... (Or
-switch to RIO).
-
-------------------------------------------------------------------------
-
-
-  Fixed bugs and restrictions:
-        - Hangup processing.  
-          -- Done.
-
-        - the write path in generic_serial (lockup / oops). 
-          -- Done (Ugly: not the way I want it. Copied from serial.c).
-
-        - write buffer isn't flushed at close.
-          -- Done. I still seem to lose a few chars at close. 
-             Sorry. I think that this is a firmware issue. (-> Specialix)
-
-        - drain hardware before  changing termios
-        - Change debug on the fly. 
-        - ISA free irq -1. (no firmware loaded).
-        - adding c8000 as a probe address. Added warning. 
-        - Add a RAMtest for the RAM on the card.c
-        - Crash when opening a port "way" of the number of allowed ports. 
-          (for example opening port 60 when there are only 24 ports attached)
-        - Sometimes the use-count strays a bit. After a few hours of
-          testing the use count is sometimes "3". If you are not like
-          me and can remember what you did to get it that way, I'd
-          appreciate an Email. Possibly fixed. Tell me if anyone still
-          sees this.
-        - TAs don't work right if you don't connect all the modem control
-          signals. SXDCs do. T225 firmware problem -> Specialix. 
-          (Mostly fixed now, I think. Tell me if you encounter this!)
-
-  Bugs & restrictions:
-
-        - Arbitrary baud rates. Requires firmware update. (-> Specialix)
-
-        - Low latency (mostly firmware, -> Specialix)
-
-
-
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index b8dd0df76952..7ccf933bfbe0 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -948,7 +948,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
     avoided as much as possible...
     
     MORE NOTES ON "azx_get_response timeout" PROBLEMS:
-    On some hardwares, you may need to add a proper probe_mask option
+    On some hardware, you may need to add a proper probe_mask option
     to avoid the "azx_get_response timeout" problem above, instead.
     This occurs when the access to non-existing or non-working codec slot
     (likely a modem one) causes a stall of the communication via HD-audio
@@ -1124,7 +1124,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
     buggy_irq     - Enable workaround for buggy interrupts on some
                     motherboards (default yes on nForce chips,
                     otherwise off)
-    buggy_semaphore - Enable workaround for hardwares with buggy
+    buggy_semaphore - Enable workaround for hardware with buggy
                     semaphores (e.g. on some ASUS laptops)
                     (default off)
     spdif_aclink  - Use S/PDIF over AC-link instead of direct connection
diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt
index b0714d8f678a..cbc2f03056bd 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -39,7 +39,7 @@ Procedure for submitting patches to the -stable tree:
    the stable tree without anything else needing to be done by the author
    or subsystem maintainer.
  - If the patch requires other patches as prerequisites which can be
-   cherry-picked than this can be specified in the following format in
+   cherry-picked, then this can be specified in the following format in
    the sign-off area:
 
      Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 9886c3d57fc2..708bb7f1b7e0 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -77,6 +77,7 @@ show up in /proc/sys/kernel:
 - shmmni
 - stop-a                      [ SPARC only ]
 - sysrq                       ==> Documentation/sysrq.txt
+- sysctl_writes_strict
 - tainted
 - threads-max
 - unknown_nmi_panic
@@ -762,6 +763,26 @@ without users and with a dead originative process will be destroyed.
 
 ==============================================================
 
+sysctl_writes_strict:
+
+Control how file position affects the behavior of updating sysctl values
+via the /proc/sys interface:
+
+  -1 - Legacy per-write sysctl value handling, with no printk warnings.
+       Each write syscall must fully contain the sysctl value to be
+       written, and multiple writes on the same sysctl file descriptor
+       will rewrite the sysctl value, regardless of file position.
+   0 - (default) Same behavior as above, but warn about processes that
+       perform writes to a sysctl file descriptor when the file position
+       is not 0.
+   1 - Respect file position when writing sysctl strings. Multiple writes
+       will append to the sysctl value buffer. Anything past the max length
+       of the sysctl value buffer will be ignored. Writes to numeric sysctl
+       entries must always be at file position 0 and the value must be
+       fully contained in the buffer sent in the write syscall.
+
+==============================================================
+
 tainted:
 
 Non-zero if the kernel has been tainted.  Numeric values, which
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index dd9d0e33b443..bd4b34c03738 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -746,8 +746,8 @@ Changing this takes effect whenever an application requests memory.
 vfs_cache_pressure
 ------------------
 
-Controls the tendency of the kernel to reclaim the memory which is used for
-caching of directory and inode objects.
+This percentage value controls the tendency of the kernel to reclaim
+the memory which is used for caching of directory and inode objects.
 
 At the default value of vfs_cache_pressure=100 the kernel will attempt to
 reclaim dentries and inodes at a "fair" rate with respect to pagecache and
@@ -757,6 +757,11 @@ never reclaim dentries and inodes due to memory pressure and this can easily
 lead to out-of-memory conditions. Increasing vfs_cache_pressure beyond 100
 causes the kernel to prefer to reclaim dentries and inodes.
 
+Increasing vfs_cache_pressure significantly beyond 100 may have negative
+performance impact. Reclaim code needs to take various locks to find freeable
+directory and inode objects. With vfs_cache_pressure=1000, it will look for
+ten times more freeable objects than there are.
+
 ==============================================================
 
 zone_reclaim_mode:
@@ -772,16 +777,17 @@ This is value ORed together of
 2       = Zone reclaim writes dirty pages out
 4       = Zone reclaim swaps pages
 
-zone_reclaim_mode is set during bootup to 1 if it is determined that pages
-from remote zones will cause a measurable performance reduction. The
-page allocator will then reclaim easily reusable pages (those page
-cache pages that are currently not used) before allocating off node pages.
-
-It may be beneficial to switch off zone reclaim if the system is
-used for a file server and all of memory should be used for caching files
-from disk. In that case the caching effect is more important than
+zone_reclaim_mode is disabled by default.  For file servers or workloads
+that benefit from having their data cached, zone_reclaim_mode should be
+left disabled as the caching effect is likely to be more important than
 data locality.
 
+zone_reclaim may be enabled if it's known that the workload is partitioned
+such that each partition fits within a NUMA node and that accessing remote
+memory would cause a measurable performance reduction.  The page allocator
+will then reclaim easily reusable pages (those page cache pages that are
+currently not used) before allocating off node pages.
+
 Allowing zone reclaim to write out pages stops processes that are
 writing large amounts of data from dirtying pages on other nodes. Zone
 reclaim will write out dirty pages if a zone fills up and so effectively
diff --git a/Documentation/timers/timer_stats.txt b/Documentation/timers/timer_stats.txt
index 8abd40b22b7f..de835ee97455 100644
--- a/Documentation/timers/timer_stats.txt
+++ b/Documentation/timers/timer_stats.txt
@@ -39,9 +39,9 @@ To stop a sample period issue:
 The statistics can be retrieved by:
 # cat /proc/timer_stats
 
-The readout of /proc/timer_stats automatically disables sampling. The sampled
-information is kept until a new sample period is started. This allows multiple
-readouts.
+While sampling is enabled, each readout from /proc/timer_stats will see
+newly updated statistics. Once sampling is disabled, the sampled information
+is kept until a new sample period is started. This allows multiple readouts.
 
 Sample output of /proc/timer_stats:
 
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index c94435df2037..75d25a1d6e42 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -443,7 +443,7 @@ The following commands are supported:
   The following command creates a snapshot every time a block request
   queue is unplugged with a depth > 1.  If you were tracing a set of
   events or functions at the time, the snapshot trace buffer would
-  capture those events when the trigger event occured:
+  capture those events when the trigger event occurred:
 
   # echo 'snapshot if nr_rq > 1' > \
         /sys/kernel/debug/tracing/events/block/block_unplug/trigger
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/usb/chipidea.txt b/Documentation/usb/chipidea.txt
new file mode 100644
index 000000000000..995c8bca40e2
--- /dev/null
+++ b/Documentation/usb/chipidea.txt
@@ -0,0 +1,71 @@
+1. How to test OTG FSM(HNP and SRP)
+-----------------------------------
+To show how to demo OTG HNP and SRP functions via sys input files
+with 2 Freescale i.MX6Q sabre SD boards.
+
+1.1 How to enable OTG FSM in menuconfig
+---------------------------------------
+Select CONFIG_USB_OTG_FSM, rebuild kernel Image and modules.
+If you want to check some internal variables for otg fsm,
+select CONFIG_USB_CHIPIDEA_DEBUG, there are 2 files which
+can show otg fsm variables and some controller registers value:
+cat /sys/kernel/debug/ci_hdrc.0/otg
+cat /sys/kernel/debug/ci_hdrc.0/registers
+
+1.2 Test operations
+-------------------
+1) Power up 2 Freescale i.MX6Q sabre SD boards with gadget class driver loaded
+   (e.g. g_mass_storage).
+
+2) Connect 2 boards with usb cable with one end is micro A plug, the other end
+   is micro B plug.
+
+   The A-device(with micro A plug inserted) should enumrate B-device.
+
+3) Role switch
+   On B-device:
+   echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req
+
+   if HNP polling is not supported, also need:
+   On A-device:
+   echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req
+
+   B-device should take host role and enumrate A-device.
+
+4) A-device switch back to host.
+   On B-device:
+   echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req
+
+   A-device should switch back to host and enumrate B-device.
+
+5) Remove B-device(unplug micro B plug) and insert again in 10 seconds,
+   A-device should enumrate B-device again.
+
+6) Remove B-device(unplug micro B plug) and insert again after 10 seconds,
+   A-device should NOT enumrate B-device.
+
+   if A-device wants to use bus:
+   On A-device:
+   echo 0 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop
+   echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_req
+
+   if B-device wants to use bus:
+   On B-device:
+   echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req
+
+7) A-device power down the bus.
+   On A-device:
+   echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/a_bus_drop
+
+   A-device should disconnect with B-device and power down the bus.
+
+8) B-device does data pulse for SRP.
+   On B-device:
+   echo 1 > /sys/bus/platform/devices/ci_hdrc.0/inputs/b_bus_req
+
+   A-device should resume usb bus and enumrate B-device.
+
+1.3 Reference document
+----------------------
+"On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
+July 27, 2012 Revision 2.0 version 1.1a"
diff --git a/Documentation/usb/mass-storage.txt b/Documentation/usb/mass-storage.txt
index 59063ad7a60d..e89803a5a960 100644
--- a/Documentation/usb/mass-storage.txt
+++ b/Documentation/usb/mass-storage.txt
@@ -13,7 +13,7 @@
   operation.
 
   Note that the driver is slightly non-portable in that it assumes
-  a single memory/DMA buffer will be useable for bulk-in and bulk-out
+  a single memory/DMA buffer will be usable for bulk-in and bulk-out
   endpoints.  With most device controllers this is not an issue, but
   there may be some with hardware restrictions that prevent a buffer
   from being used by more than one endpoint.
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 __x86_64__
-# error Not yet ported to non-x86_64 architectures
+#ifndef ELF_BITS
+# if ULONG_MAX > 0xffffffffUL
+#  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;
-        Elf64_Word nbucket, nchain;
+        ELF(Word) *bucket, *chain;
+        ELF(Word) nbucket, nchain;
 
         /* Version table */
-        Elf64_Versym *versym;
-        Elf64_Verdef *verdef;
+        ELF(Versym) *versym;
+        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;
-        Elf64_Phdr *pt = (Elf64_Phdr*)(vdso_info.load_addr + hdr->e_phoff);
-        Elf64_Dyn *dyn = 0;
+        ELF(Ehdr) *hdr = (ELF(Ehdr)*)base;
+        if (hdr->e_ident[EI_CLASS] !=
+            (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,
-                               const char *name, Elf64_Word hash)
+static bool vdso_match_version(ELF(Versym) ver,
+                               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
- * Copyright (c) 2011 Andy Lutomirski
+ * vdso_test.c: Sample code to test parse_vdso.c
+ * Copyright (c) 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
- *      vdso_test.c parse_vdso.c -o vdso_test
- * to generate a small binary with no dependencies at all.
+ * Compile with:
+ * gcc -std=gnu99 vdso_test.c parse_vdso.c
+ *
+ * Tested on x86, 32-bit and 64-bit.  It may work on other architectures, too.
  */
 
-#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 strcmp(const char *a, const char *b)
+int main(int argc, char **argv)
 {
-        /* 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++;
+        unsigned long sysinfo_ehdr = getauxval(AT_SYSINFO_EHDR);
+        if (!sysinfo_ehdr) {
+                printf("AT_SYSINFO_EHDR is not present!\n");
+                return 0;
         }
 
-        return 0;
-}
-
-/* ...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);
+        vdso_init_from_sysinfo_ehdr(getauxval(AT_SYSINFO_EHDR));
 
         /* 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);
+        if (!gtod) {
+                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";
-                to_base10(buf + 31, tv.tv_sec);
-                to_base10(buf + 38, tv.tv_usec);
-                linux_write(1, buf, sizeof(buf) - 1);
+                printf("The time is %lld.%06lld\n",
+                       (long long)tv.tv_sec, (long long)tv.tv_usec);
         } 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"
-        );
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index 2f6e93597ce0..b092c0a14df2 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -164,3 +164,4 @@
 163 -> Bt848 Capture 14MHz
 164 -> CyberVision CV06 (SV)
 165 -> Kworld V-Stream Xpert TV PVR878
+166 -> PCI-8604PW
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index e085b1243b45..5a3ddcd340d3 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -92,3 +92,4 @@
  91 -> SpeedLink Vicious And Devine Laplace webcam (em2765)        [1ae7:9003,1ae7:9004]
  92 -> PCTV DVB-S2 Stick (461e)                 (em28178)
  93 -> KWorld USB ATSC TV Stick UB435-Q V3      (em2874)        [1b80:e34c]
+ 94 -> PCTV tripleStick (292e)                  (em28178)
diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt
index 7d6e160724bd..e0c6b8bc4743 100644
--- a/Documentation/video4linux/fimc.txt
+++ b/Documentation/video4linux/fimc.txt
@@ -140,39 +140,9 @@ You can either grep through the kernel log to find relevant information, i.e.
 or retrieve the information from /dev/media? with help of the media-ctl tool:
 # media-ctl -p
 
-6. Platform support
-===================
-
-The machine code (arch/arm/plat-samsung and arch/arm/mach-*) must select
-following options:
-
-CONFIG_S5P_DEV_FIMC0       mandatory
-CONFIG_S5P_DEV_FIMC1  \
-CONFIG_S5P_DEV_FIMC2  |    optional
-CONFIG_S5P_DEV_FIMC3  |
-CONFIG_S5P_SETUP_FIMC /
-CONFIG_S5P_DEV_CSIS0  \    optional for MIPI-CSI interface
-CONFIG_S5P_DEV_CSIS1  /
-
-Except that, relevant s5p_device_fimc? should be registered in the machine code
-in addition to a "s5p-fimc-md" platform device to which the media device driver
-is bound.  The "s5p-fimc-md" device instance is required even if only mem-to-mem
-operation is used.
-
-The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be
-passed as the "s5p-fimc-md" device platform_data.  The platform data structure
-is defined in file include/media/s5p_fimc.h.
-
 7. Build
 ========
 
-This driver depends on following config options:
-PLAT_S5P,
-PM_RUNTIME,
-I2C,
-REGULATOR,
-VIDEO_V4L2_SUBDEV_API,
-
 If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m)
 two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and
 optional s5p-csis.ko (MIPI-CSI receiver subdev).
diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c
index 3a1c0d2dafce..46904fe49609 100644
--- a/Documentation/video4linux/v4l2-pci-skeleton.c
+++ b/Documentation/video4linux/v4l2-pci-skeleton.c
@@ -77,7 +77,8 @@ struct skeleton {
 
         spinlock_t qlock;
         struct list_head buf_list;
-        unsigned int sequence;
+        unsigned field;
+        unsigned sequence;
 };
 
 struct skel_buffer {
@@ -124,7 +125,7 @@ static const struct v4l2_dv_timings_cap skel_timings_cap = {
  * Interrupt handler: typically interrupts happen after a new frame has been
  * captured. It is the job of the handler to remove the new frame from the
  * internal list and give it back to the vb2 framework, updating the sequence
- * counter and timestamp at the same time.
+ * counter, field and timestamp at the same time.
  */
 static irqreturn_t skeleton_irq(int irq, void *dev_id)
 {
@@ -139,8 +140,15 @@ static irqreturn_t skeleton_irq(int irq, void *dev_id)
                 spin_lock(&skel->qlock);
                 list_del(&new_buf->list);
                 spin_unlock(&skel->qlock);
-                new_buf->vb.v4l2_buf.sequence = skel->sequence++;
                 v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
+                new_buf->vb.v4l2_buf.sequence = skel->sequence++;
+                new_buf->vb.v4l2_buf.field = skel->field;
+                if (skel->format.field == V4L2_FIELD_ALTERNATE) {
+                        if (skel->field == V4L2_FIELD_BOTTOM)
+                                skel->field = V4L2_FIELD_TOP;
+                        else if (skel->field == V4L2_FIELD_TOP)
+                                skel->field = V4L2_FIELD_BOTTOM;
+                }
                 vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE);
         }
 #endif
@@ -160,6 +168,17 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
 {
         struct skeleton *skel = vb2_get_drv_priv(vq);
 
+        skel->field = skel->format.field;
+        if (skel->field == V4L2_FIELD_ALTERNATE) {
+                /*
+                 * You cannot use read() with FIELD_ALTERNATE since the field
+                 * information (TOP/BOTTOM) cannot be passed back to the user.
+                 */
+                if (vb2_fileio_is_active(vq))
+                        return -EINVAL;
+                skel->field = V4L2_FIELD_TOP;
+        }
+
         if (vq->num_buffers + *nbuffers < 3)
                 *nbuffers = 3 - vq->num_buffers;
 
@@ -173,10 +192,7 @@ static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
 
 /*
  * Prepare the buffer for queueing to the DMA engine: check and set the
- * payload size and fill in the field. Note: if the format's field is
- * V4L2_FIELD_ALTERNATE, then vb->v4l2_buf.field should be set in the
- * interrupt handler since that's usually where you know if the TOP or
- * BOTTOM field has been captured.
+ * payload size.
  */
 static int buffer_prepare(struct vb2_buffer *vb)
 {
@@ -190,7 +206,6 @@ static int buffer_prepare(struct vb2_buffer *vb)
         }
 
         vb2_set_plane_payload(vb, 0, size);
-        vb->v4l2_buf.field = skel->format.field;
         return 0;
 }
 
@@ -254,7 +269,7 @@ static int start_streaming(struct vb2_queue *vq, unsigned int count)
  * Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued
  * and passed on to the vb2 framework marked as STATE_ERROR.
  */
-static int stop_streaming(struct vb2_queue *vq)
+static void stop_streaming(struct vb2_queue *vq)
 {
         struct skeleton *skel = vb2_get_drv_priv(vq);
 
@@ -262,7 +277,6 @@ static int stop_streaming(struct vb2_queue *vq)
 
         /* Release all active buffers */
         return_all_buffers(skel, VB2_BUF_STATE_ERROR);
-        return 0;
 }
 
 /*
@@ -319,10 +333,12 @@ static void skeleton_fill_pix_format(struct skeleton *skel,
                 /* HDMI input */
                 pix->width = skel->timings.bt.width;
                 pix->height = skel->timings.bt.height;
-                if (skel->timings.bt.interlaced)
-                        pix->field = V4L2_FIELD_INTERLACED;
-                else
+                if (skel->timings.bt.interlaced) {
+                        pix->field = V4L2_FIELD_ALTERNATE;
+                        pix->height /= 2;
+                } else {
                         pix->field = V4L2_FIELD_NONE;
+                }
                 pix->colorspace = V4L2_COLORSPACE_REC709;
         }
 
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index a9380ba54c8e..0fe36497642c 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1794,6 +1794,11 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_MMCR0     | 64
   PPC   | KVM_REG_PPC_MMCR1     | 64
   PPC   | KVM_REG_PPC_MMCRA     | 64
+  PPC   | KVM_REG_PPC_MMCR2     | 64
+  PPC   | KVM_REG_PPC_MMCRS     | 64
+  PPC   | KVM_REG_PPC_SIAR      | 64
+  PPC   | KVM_REG_PPC_SDAR      | 64
+  PPC   | KVM_REG_PPC_SIER      | 64
   PPC   | KVM_REG_PPC_PMC1      | 32
   PPC   | KVM_REG_PPC_PMC2      | 32
   PPC   | KVM_REG_PPC_PMC3      | 32
@@ -1868,6 +1873,7 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_PPR       | 64
   PPC   | KVM_REG_PPC_ARCH_COMPAT 32
   PPC   | KVM_REG_PPC_DABRX     | 32
+  PPC   | KVM_REG_PPC_WORT      | 64
   PPC   | KVM_REG_PPC_TM_GPR0   | 64
           ...
   PPC   | KVM_REG_PPC_TM_GPR31  | 64
@@ -2066,7 +2072,7 @@ the "Server" class MMU emulation supported by KVM.
 This can in turn be used by userspace to generate the appropriate
 device-tree properties for the guest operating system.
 
-The structure contains some global informations, followed by an
+The structure contains some global information, followed by an
 array of supported segment page sizes:
 
       struct kvm_ppc_smmu_info {
@@ -2126,7 +2132,7 @@ into the hash PTE second double word).
 4.75 KVM_IRQFD
 
 Capability: KVM_CAP_IRQFD
-Architectures: x86
+Architectures: x86 s390
 Type: vm ioctl
 Parameters: struct kvm_irqfd (in)
 Returns: 0 on success, -1 on error
@@ -2211,6 +2217,8 @@ KVM_S390_SIGP_STOP (vcpu) - sigp restart
 KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm
 KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm
 KVM_S390_RESTART (vcpu) - restart
+KVM_S390_INT_CLOCK_COMP (vcpu) - clock comparator interrupt
+KVM_S390_INT_CPU_TIMER (vcpu) - CPU timer interrupt
 KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
                            parameters in parm and parm64
 KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
@@ -2314,8 +2322,8 @@ struct kvm_create_device {
 
 4.80 KVM_SET_DEVICE_ATTR/KVM_GET_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL
-Type: device ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
+Type: device ioctl, vm ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
@@ -2340,8 +2348,8 @@ struct kvm_device_attr {
 
 4.81 KVM_HAS_DEVICE_ATTR
 
-Capability: KVM_CAP_DEVICE_CTRL
-Type: device ioctl
+Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device
+Type: device ioctl, vm ioctl
 Parameters: struct kvm_device_attr
 Returns: 0 on success, -1 on error
 Errors:
@@ -2376,6 +2384,8 @@ Possible features:
           Depends on KVM_CAP_ARM_PSCI.
         - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
           Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
+        - KVM_ARM_VCPU_PSCI_0_2: Emulate PSCI v0.2 for the CPU.
+          Depends on KVM_CAP_ARM_PSCI_0_2.
 
 
 4.83 KVM_ARM_PREFERRED_TARGET
@@ -2738,6 +2748,21 @@ It gets triggered whenever both KVM_CAP_PPC_EPR are enabled and an
 external interrupt has just been delivered into the guest. User space
 should put the acknowledged interrupt vector into the 'epr' field.
 
+                /* KVM_EXIT_SYSTEM_EVENT */
+                struct {
+#define KVM_SYSTEM_EVENT_SHUTDOWN       1
+#define KVM_SYSTEM_EVENT_RESET          2
+                        __u32 type;
+                        __u64 flags;
+                } system_event;
+
+If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered
+a system-level event using some architecture specific mechanism (hypercall
+or some special instruction). In case of ARM/ARM64, this is triggered using
+HVC instruction based PSCI call from the vcpu. The 'type' field describes
+the system-level event type. The 'flags' field describes architecture
+specific flags for the system-level event.
+
                 /* Fix the size of the union. */
                 char padding[256];
         };
diff --git a/Documentation/virtual/kvm/devices/vm.txt b/Documentation/virtual/kvm/devices/vm.txt
new file mode 100644
index 000000000000..0d16f96c0eac
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/vm.txt
@@ -0,0 +1,26 @@
+Generic vm interface
+====================================
+
+The virtual machine "device" also accepts the ioctls KVM_SET_DEVICE_ATTR,
+KVM_GET_DEVICE_ATTR, and KVM_HAS_DEVICE_ATTR. The interface uses the same
+struct kvm_device_attr as other devices, but targets VM-wide settings
+and controls.
+
+The groups and attributes per virtual machine, if any, are architecture
+specific.
+
+1. GROUP: KVM_S390_VM_MEM_CTRL
+Architectures: s390
+
+1.1. ATTRIBUTE: KVM_S390_VM_MEM_CTRL
+Parameters: none
+Returns: -EBUSY if already a vcpus is defined, otherwise 0
+
+Enables CMMA for the virtual machine
+
+1.2. ATTRIBUTE: KVM_S390_VM_CLR_CMMA
+Parameteres: none
+Returns: 0
+
+Clear the CMMA status for all guest pages, so any pages the guest marked
+as unused are again used any may not be reclaimed by the host.
diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt
index 4643cde517c4..319560646f32 100644
--- a/Documentation/virtual/kvm/ppc-pv.txt
+++ b/Documentation/virtual/kvm/ppc-pv.txt
@@ -94,10 +94,24 @@ a bitmap of available features inside the magic page.
 The following enhancements to the magic page are currently available:
 
   KVM_MAGIC_FEAT_SR             Maps SR registers r/w in the magic page
+  KVM_MAGIC_FEAT_MAS0_TO_SPRG7  Maps MASn, ESR, PIR and high SPRGs
 
 For enhanced features in the magic page, please check for the existence of the
 feature before using them!
 
+Magic page flags
+================
+
+In addition to features that indicate whether a host is capable of a particular
+feature we also have a channel for a guest to tell the guest whether it's capable
+of something. This is what we call "flags".
+
+Flags are passed to the host in the low 12 bits of the Effective Address.
+
+The following flags are currently available for a guest to expose:
+
+  MAGIC_PAGE_FLAG_NOT_MAPPED_NX Guest handles NX bits correclty wrt magic page
+
 MSR bits
 ========
 
diff --git a/Documentation/virtual/kvm/s390-diag.txt b/Documentation/virtual/kvm/s390-diag.txt
index f1de4fbade15..48c4921794ed 100644
--- a/Documentation/virtual/kvm/s390-diag.txt
+++ b/Documentation/virtual/kvm/s390-diag.txt
@@ -78,3 +78,5 @@ DIAGNOSE function code 'X'501 - KVM breakpoint
 
 If the function code specifies 0x501, breakpoint functions may be performed.
 This function code is handled by userspace.
+
+This diagnose function code has no subfunctions and uses no parameters.
diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt
index 550068466605..6ae89a9edf2a 100644
--- a/Documentation/vm/hwpoison.txt
+++ b/Documentation/vm/hwpoison.txt
@@ -84,6 +84,11 @@ PR_MCE_KILL
                 PR_MCE_KILL_EARLY: Early kill
                 PR_MCE_KILL_LATE:  Late kill
                 PR_MCE_KILL_DEFAULT: Use system global default
+        Note that if you want to have a dedicated thread which handles
+        the SIGBUS(BUS_MCEERR_AO) on behalf of the process, you should
+        call prctl(PR_MCE_KILL_EARLY) on the designated thread. Otherwise,
+        the SIGBUS is sent to the main thread.
+
 PR_MCE_KILL_GET
         return current mode
 
diff --git a/Documentation/vm/numa_memory_policy.txt b/Documentation/vm/numa_memory_policy.txt
index 4e7da6543424..badb0507608f 100644
--- a/Documentation/vm/numa_memory_policy.txt
+++ b/Documentation/vm/numa_memory_policy.txt
@@ -174,7 +174,6 @@ Components of Memory Policies
         allocation fails, the kernel will search other nodes, in order of
         increasing distance from the preferred node based on information
         provided by the platform firmware.
-        containing the cpu where the allocation takes place.
 
             Internally, the Preferred policy uses a single node--the
             preferred_node member of struct mempolicy.  When the internal
@@ -275,9 +274,9 @@ Components of Memory Policies
             For example, consider a task that is attached to a cpuset with
             mems 2-5 that sets an Interleave policy over the same set with
             MPOL_F_RELATIVE_NODES.  If the cpuset's mems change to 3-7, the
-            interleave now occurs over nodes 3,5-6.  If the cpuset's mems
+            interleave now occurs over nodes 3,5-7.  If the cpuset's mems
             then change to 0,2-3,5, then the interleave occurs over nodes
-            0,3,5.
+            0,2-3,5.
 
             Thanks to the consistent remapping, applications preparing
             nodemasks to specify memory policies using this flag should
diff --git a/Documentation/vm/remap_file_pages.txt b/Documentation/vm/remap_file_pages.txt
new file mode 100644
index 000000000000..560e4363a55d
--- /dev/null
+++ b/Documentation/vm/remap_file_pages.txt
@@ -0,0 +1,28 @@
+The remap_file_pages() system call is used to create a nonlinear mapping,
+that is, a mapping in which the pages of the file are mapped into a
+nonsequential order in memory. The advantage of using remap_file_pages()
+over using repeated calls to mmap(2) is that the former approach does not
+require the kernel to create additional VMA (Virtual Memory Area) data
+structures.
+
+Supporting of nonlinear mapping requires significant amount of non-trivial
+code in kernel virtual memory subsystem including hot paths. Also to get
+nonlinear mapping work kernel need a way to distinguish normal page table
+entries from entries with file offset (pte_file). Kernel reserves flag in
+PTE for this purpose. PTE flags are scarce resource especially on some CPU
+architectures. It would be nice to free up the flag for other usage.
+
+Fortunately, there are not many users of remap_file_pages() in the wild.
+It's only known that one enterprise RDBMS implementation uses the syscall
+on 32-bit systems to map files bigger than can linearly fit into 32-bit
+virtual address space. This use-case is not critical anymore since 64-bit
+systems are widely available.
+
+The plan is to deprecate the syscall and replace it with an emulation.
+The emulation will create new VMAs instead of nonlinear mappings. It's
+going to work slower for rare users of remap_file_pages() but ABI is
+preserved.
+
+One side effect of emulation (apart from performance) is that user can hit
+vm.max_map_count limit more easily due to additional VMAs. See comment for
+DEFAULT_MAX_MAP_COUNT for more details on the limit.
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 4a63953a41f1..6b31cfbe2a9a 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -360,13 +360,13 @@ on any tail page, would mean having to split all hugepages upfront in
 get_user_pages which is unacceptable as too many gup users are
 performance critical and they must work natively on hugepages like
 they work natively on hugetlbfs already (hugetlbfs is simpler because
-hugetlbfs pages cannot be splitted so there wouldn't be requirement of
+hugetlbfs pages cannot be split so there wouldn't be requirement of
 accounting the pins on the tail pages for hugetlbfs). If we wouldn't
 account the gup refcounts on the tail pages during gup, we won't know
 anymore which tail page is pinned by gup and which is not while we run
 split_huge_page. But we still have to add the gup pin to the head page
 too, to know when we can free the compound page in case it's never
-splitted during its lifetime. That requires changing not just
+split during its lifetime. That requires changing not just
 get_page, but put_page as well so that when put_page runs on a tail
 page (and only on a tail page) it will find its respective head page,
 and then it will decrease the head page refcount in addition to the
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index a31c5a242973..b2033c64c7da 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -82,7 +82,7 @@ driver             - (standard) symlink to the w1 driver
 w1_master_add      - Manually register a slave device
 w1_master_attempts - the number of times a search was attempted
 w1_master_max_slave_count
-                   - the maximum slaves that may be attached to a master
+                   - maximum number of slaves to search for at a time
 w1_master_name     - the name of the device (w1_bus_masterX)
 w1_master_pullup   - 5V strong pullup 0 enabled, 1 disabled
 w1_master_remove   - Manually remove a slave device
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink
index 927a52cc0519..ef2727192d69 100644
--- a/Documentation/w1/w1.netlink
+++ b/Documentation/w1/w1.netlink
@@ -30,7 +30,7 @@ Protocol.
                         W1_SLAVE_CMD
                                 userspace command for slave device
                                 (read/write/touch)
-        __u8 res        - reserved
+        __u8 status     - error indication from kernel
         __u16 len       - size of data attached to this header data
         union {
                 __u8 id[8];                      - slave unique device id
@@ -44,10 +44,14 @@ Protocol.
         __u8 cmd        - command opcode.
                         W1_CMD_READ     - read command
                         W1_CMD_WRITE    - write command
-                        W1_CMD_TOUCH    - touch command
-                                (write and sample data back to userspace)
                         W1_CMD_SEARCH   - search command
                         W1_CMD_ALARM_SEARCH - alarm search command
+                        W1_CMD_TOUCH    - touch command
+                                (write and sample data back to userspace)
+                        W1_CMD_RESET    - send bus reset
+                        W1_CMD_SLAVE_ADD        - add slave to kernel list
+                        W1_CMD_SLAVE_REMOVE     - remove slave from kernel list
+                        W1_CMD_LIST_SLAVES      - get slaves list from kernel
         __u8 res        - reserved
         __u16 len       - length of data for this command
                 For read command data must be allocated like for write command
@@ -87,8 +91,7 @@ format:
         id0 ... idN
 
         Each message is at most 4k in size, so if number of master devices
-        exceeds this, it will be split into several messages,
-        cn.seq will be increased for each one.
+        exceeds this, it will be split into several messages.
 
 W1 search and alarm search commands.
 request:
diff --git a/Documentation/x86/earlyprintk.txt b/Documentation/x86/earlyprintk.txt
index f19802c0f485..688e3eeed21d 100644
--- a/Documentation/x86/earlyprintk.txt
+++ b/Documentation/x86/earlyprintk.txt
@@ -33,7 +33,7 @@ and two USB cables, connected like this:
  ...
 
 ( If your system does not list a debug port capability then you probably
-  wont be able to use the USB debug key. )
+  won't be able to use the USB debug key. )
 
  b.) You also need a Netchip USB debug cable/key:
 
diff --git a/Documentation/x86/i386/IO-APIC.txt b/Documentation/x86/i386/IO-APIC.txt
index 30b4c714fbe1..15f5baf7e1b6 100644
--- a/Documentation/x86/i386/IO-APIC.txt
+++ b/Documentation/x86/i386/IO-APIC.txt
@@ -87,7 +87,7 @@ your PCI configuration:
 
         echo -n pirq=; echo `scanpci | grep T_L | cut -c56-` | sed 's/ /,/g'
 
-note that this script wont work if you have skipped a few slots or if your
+note that this script won't work if you have skipped a few slots or if your
 board does not do default daisy-chaining. (or the IO-APIC has the PIRQ pins
 connected in some strange way). E.g. if in the above case you have your SCSI
 card (IRQ11) in Slot3, and have Slot1 empty:
diff --git a/Documentation/x86/x86_64/mm.txt b/Documentation/x86/x86_64/mm.txt
index c584a51add15..afe68ddbe6a4 100644
--- a/Documentation/x86/x86_64/mm.txt
+++ b/Documentation/x86/x86_64/mm.txt
@@ -12,6 +12,8 @@ ffffc90000000000 - ffffe8ffffffffff (=45 bits) vmalloc/ioremap space
 ffffe90000000000 - ffffe9ffffffffff (=40 bits) hole
 ffffea0000000000 - ffffeaffffffffff (=40 bits) virtual memory map (1TB)
 ... unused hole ...
+ffffff0000000000 - ffffff7fffffffff (=39 bits) %esp fixup stacks
+... unused hole ...
 ffffffff80000000 - ffffffffa0000000 (=512 MB)  kernel text mapping, from phys 0
 ffffffffa0000000 - ffffffffff5fffff (=1525 MB) module mapping space
 ffffffffff600000 - ffffffffffdfffff (=8 MB) vsyscalls
diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO
index 6c914aa87e71..54ea24ff63c7 100644
--- a/Documentation/zh_CN/HOWTO
+++ b/Documentation/zh_CN/HOWTO
@@ -237,7 +237,7 @@ kernel.org网站的pub/linux/kernel/v2.6/目录下找到它。它的开发遵循
 如果没有2.6.x.y版本内核存在，那么最新的2.6.x版本内核就相当于是当前的稳定
 版内核。
 
-2.6.x.y版本由“稳定版”小组（邮件地址<stable@kernel.org>）维护，一般隔周发
+2.6.x.y版本由“稳定版”小组（邮件地址<stable@vger.kernel.org>）维护，一般隔周发
 布新版本。
 
 内核源码中的Documentation/stable_kernel_rules.txt文件具体描述了可被稳定
diff --git a/Documentation/zh_CN/io_ordering.txt b/Documentation/zh_CN/io_ordering.txt
new file mode 100644
index 000000000000..e592daf4e014
--- /dev/null
+++ b/Documentation/zh_CN/io_ordering.txt
@@ -0,0 +1,67 @@
+Chinese translated version of Documentation/io_orderings.txt
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly.  However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help.  Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Chinese maintainer: Lin Yongting <linyongting@gmail.com>
+---------------------------------------------------------------------
+Documentation/io_ordering.txt 的中文翻译
+
+如果想评论或更新本文的内容，请直接联系原文档的维护者。如果你使用英文
+交流有困难的话，也可以向中文版维护者求助。如果本翻译更新不及时或者翻
+译存在问题，请联系中文版维护者。
+
+中文版维护者： 林永听 Lin Yongting <linyongting@gmail.com>
+中文版翻译者： 林永听 Lin Yongting <linyongting@gmail.com>
+中文版校译者： 林永听 Lin Yongting <linyongting@gmail.com>
+
+
+以下为正文
+---------------------------------------------------------------------
+
+在某些平台上，所谓的内存映射I/O是弱顺序。在这些平台上，驱动开发者有责任
+保证I/O内存映射地址的写操作按程序图意的顺序达到设备。通常读取一个“安全”
+设备寄存器或桥寄存器，触发IO芯片清刷未处理的写操作到达设备后才处理读操作，
+而达到保证目的。驱动程序通常在spinlock保护的临界区退出之前使用这种技术。
+这也可以保证后面的写操作只在前面的写操作之后到达设备（这非常类似于内存
+屏障操作，mb()，不过仅适用于I/O）。
+
+假设一个设备驱动程的具体例子：
+
+        ...
+CPU A:  spin_lock_irqsave(&dev_lock, flags)
+CPU A:  val = readl(my_status);
+CPU A:  ...
+CPU A:  writel(newval, ring_ptr);
+CPU A:  spin_unlock_irqrestore(&dev_lock, flags)
+        ...
+CPU B:  spin_lock_irqsave(&dev_lock, flags)
+CPU B:  val = readl(my_status);
+CPU B:  ...
+CPU B:  writel(newval2, ring_ptr);
+CPU B:  spin_unlock_irqrestore(&dev_lock, flags)
+        ...
+
+上述例子中，设备可能会先接收到newval2的值，然后接收到newval的值，问题就
+发生了。不过很容易通过下面方法来修复：
+
+        ...
+CPU A:  spin_lock_irqsave(&dev_lock, flags)
+CPU A:  val = readl(my_status);
+CPU A:  ...
+CPU A:  writel(newval, ring_ptr);
+CPU A:  (void)readl(safe_register); /* 配置寄存器？*/
+CPU A:  spin_unlock_irqrestore(&dev_lock, flags)
+        ...
+CPU B:  spin_lock_irqsave(&dev_lock, flags)
+CPU B:  val = readl(my_status);
+CPU B:  ...
+CPU B:  writel(newval2, ring_ptr);
+CPU B:  (void)readl(safe_register); /* 配置寄存器？*/
+CPU B:  spin_unlock_irqrestore(&dev_lock, flags)
+
+在解决方案中，读取safe_register寄存器，触发IO芯片清刷未处理的写操作，
+再处理后面的读操作，防止引发数据不一致问题。
diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt
index 2ebe539f5450..dfb72a5c63e9 100644
--- a/Documentation/zh_CN/magic-number.txt
+++ b/Documentation/zh_CN/magic-number.txt
@@ -63,8 +63,6 @@ struct tty_ldisc {
 PG_MAGIC              'P'         pg_{read,write}_hdr include/linux/pg.h
 CMAGIC                0x0111      user              include/linux/a.out.h
 MKISS_DRIVER_MAGIC    0x04bf      mkiss_channel     drivers/net/mkiss.h
-RISCOM8_MAGIC         0x0907      riscom_port       drivers/char/riscom8.h
-SPECIALIX_MAGIC       0x0907      specialix_port    drivers/char/specialix_io8.h
 HDLC_MAGIC            0x239e      n_hdlc            drivers/char/n_hdlc.c
 APM_BIOS_MAGIC        0x4101      apm_user          arch/x86/kernel/apm_32.c
 CYCLADES_MAGIC        0x4359      cyclades_port     include/linux/cyclades.h
@@ -82,7 +80,6 @@ STRIP_MAGIC           0x5303      strip             drivers/net/strip.c
 X25_ASY_MAGIC         0x5303      x25_asy           drivers/net/x25_asy.h
 SIXPACK_MAGIC         0x5304      sixpack           drivers/net/hamradio/6pack.h
 AX25_MAGIC            0x5316      ax_disp           drivers/net/mkiss.h
-ESP_MAGIC             0x53ee      esp_struct        drivers/char/esp.h
 TTY_MAGIC             0x5401      tty_struct        include/linux/tty.h
 MGSL_MAGIC            0x5401      mgsl_info         drivers/char/synclink.c
 TTY_DRIVER_MAGIC      0x5402      tty_driver        include/linux/tty_driver.h
@@ -94,13 +91,10 @@ USB_BLUETOOTH_MAGIC   0x6d02      usb_bluetooth     drivers/usb/class/bluetty.c
 RFCOMM_TTY_MAGIC      0x6d02                        net/bluetooth/rfcomm/tty.c
 USB_SERIAL_PORT_MAGIC 0x7301      usb_serial_port   drivers/usb/serial/usb-serial.h
 CG_MAGIC              0x00090255  ufs_cylinder_group include/linux/ufs_fs.h
-A2232_MAGIC           0x000a2232  gs_port           drivers/char/ser_a2232.h
 RPORT_MAGIC           0x00525001  r_port            drivers/char/rocket_int.h
 LSEMAGIC              0x05091998  lse               drivers/fc4/fc.c
 GDTIOCTL_MAGIC        0x06030f07  gdth_iowr_str     drivers/scsi/gdth_ioctl.h
 RIEBL_MAGIC           0x09051990                    drivers/net/atarilance.c
-RIO_MAGIC             0x12345678  gs_port           drivers/char/rio/rio_linux.c
-SX_MAGIC              0x12345678  gs_port           drivers/char/sx.h
 NBD_REQUEST_MAGIC     0x12560953  nbd_request       include/linux/nbd.h
 RED_MAGIC2            0x170fc2a5  (any)             mm/slab.c
 BAYCOM_MAGIC          0x19730510  baycom_state      drivers/net/baycom_epp.c
@@ -116,7 +110,6 @@ ISDN_ASYNC_MAGIC      0x49344C01  modem_info        include/linux/isdn.h
 CTC_ASYNC_MAGIC       0x49344C01  ctc_tty_info      drivers/s390/net/ctctty.c
 ISDN_NET_MAGIC        0x49344C02  isdn_net_local_s  drivers/isdn/i4l/isdn_net_lib.h
 SAVEKMSG_MAGIC2       0x4B4D5347  savekmsg          arch/*/amiga/config.c
-STLI_BOARDMAGIC       0x4bc6c825  stlibrd           include/linux/istallion.h
 CS_STATE_MAGIC        0x4c4f4749  cs_state          sound/oss/cs46xx.c
 SLAB_C_MAGIC          0x4f17a36d  kmem_cache        mm/slab.c
 COW_MAGIC             0x4f4f4f4d  cow_header_v1     arch/um/drivers/ubd_user.c
@@ -127,10 +120,8 @@ SCC_MAGIC             0x52696368  gs_port           drivers/char/scc.h
 SAVEKMSG_MAGIC1       0x53415645  savekmsg          arch/*/amiga/config.c
 GDA_MAGIC             0x58464552  gda               arch/mips/include/asm/sn/gda.h
 RED_MAGIC1            0x5a2cf071  (any)             mm/slab.c
-STL_PORTMAGIC         0x5a7182c9  stlport           include/linux/stallion.h
 EEPROM_MAGIC_VALUE    0x5ab478d2  lanai_dev         drivers/atm/lanai.c
 HDLCDRV_MAGIC         0x5ac6e778  hdlcdrv_state     include/linux/hdlcdrv.h
-EPCA_MAGIC            0x5c6df104  channel           include/linux/epca.h
 PCXX_MAGIC            0x5c6df104  channel           drivers/char/pcxx.h
 KV_MAGIC              0x5f4b565f  kernel_vars_s     arch/mips/include/asm/sn/klkernvars.h
 I810_STATE_MAGIC      0x63657373  i810_state        sound/oss/i810_audio.c
@@ -142,17 +133,14 @@ SLOT_MAGIC            0x67267322  slot              drivers/hotplug/acpiphp.h
 LO_MAGIC              0x68797548  nbd_device        include/linux/nbd.h
 OPROFILE_MAGIC        0x6f70726f  super_block       drivers/oprofile/oprofilefs.h
 M3_STATE_MAGIC        0x734d724d  m3_state          sound/oss/maestro3.c
-STL_PANELMAGIC        0x7ef621a1  stlpanel          include/linux/stallion.h
 VMALLOC_MAGIC         0x87654320  snd_alloc_track   sound/core/memory.c
 KMALLOC_MAGIC         0x87654321  snd_alloc_track   sound/core/memory.c
 PWC_MAGIC             0x89DC10AB  pwc_device        drivers/usb/media/pwc.h
 NBD_REPLY_MAGIC       0x96744668  nbd_reply         include/linux/nbd.h
-STL_BOARDMAGIC        0xa2267f52  stlbrd            include/linux/stallion.h
 ENI155_MAGIC          0xa54b872d  midway_eprom      drivers/atm/eni.h
 SCI_MAGIC             0xbabeface  gs_port           drivers/char/sh-sci.h
 CODA_MAGIC            0xC0DAC0DA  coda_file_info    include/linux/coda_fs_i.h
 DPMEM_MAGIC           0xc0ffee11  gdt_pci_sram      drivers/scsi/gdth.h
-STLI_PORTMAGIC        0xe671c7a1  stliport          include/linux/istallion.h
 YAM_MAGIC             0xF10A7654  yam_port          drivers/net/hamradio/yam.c
 CCB_MAGIC             0xf2691ad2  ccb               drivers/scsi/ncr53c8xx.c
 QUEUE_MAGIC_FREE      0xf7e1c9a3  queue_entry       drivers/scsi/arm/queue.c
diff --git a/Documentation/zh_CN/stable_kernel_rules.txt b/Documentation/zh_CN/stable_kernel_rules.txt
index b5b9b0ab02fd..26ea5ed7cd9c 100644
--- a/Documentation/zh_CN/stable_kernel_rules.txt
+++ b/Documentation/zh_CN/stable_kernel_rules.txt
@@ -42,7 +42,7 @@ Documentation/stable_kernel_rules.txt 的中文翻译
 
 向稳定版代码树提交补丁的过程：
 
-  - 在确认了补丁符合以上的规则后，将补丁发送到stable@kernel.org。
+  - 在确认了补丁符合以上的规则后，将补丁发送到stable@vger.kernel.org。
   - 如果补丁被接受到队列里，发送者会收到一个ACK回复，如果没有被接受，收
     到的是NAK回复。回复需要几天的时间，这取决于开发者的时间安排。
   - 被接受的补丁会被加到稳定版本队列里，等待其他开发者的审查。