372 files changed, 9440 insertions, 1891 deletions
diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget
index 01e769d6984d..37559a06393b 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -1,13 +1,13 @@
 What:           /config/usb-gadget
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This group contains sub-groups corresponding to created
                USB gadgets.
 What:           /config/usb-gadget/gadget
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes of a gadget:
@@ -27,7 +27,7 @@ Description:
 What:           /config/usb-gadget/gadget/configs
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This group contains a USB gadget's configurations
@@ -58,20 +58,20 @@ Description:
 What:           /config/usb-gadget/gadget/functions
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This group contains functions available to this USB gadget.
 What:           /config/usb-gadget/gadget/strings
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This group contains subdirectories for language-specific
                strings for this gadget.
 What:           /config/usb-gadget/gadget/strings/language
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm
index 5708a568b5f6..d21092d75a05 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-acm
+++ b/Documentation/ABI/testing/configfs-usb-gadget-acm
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/acm.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This item contains just one readonly attribute: port_num.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ecm b/Documentation/ABI/testing/configfs-usb-gadget-ecm
index 6b9a582ce0b5..0addf7704b4c 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-ecm
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ecm
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/ecm.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-eem b/Documentation/ABI/testing/configfs-usb-gadget-eem
index dbddf36b48b3..a4c57158fcde 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-eem
+++ b/Documentation/ABI/testing/configfs-usb-gadget-eem
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/eem.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ffs b/Documentation/ABI/testing/configfs-usb-gadget-ffs
new file mode 100644
index 000000000000..e39b27653c65
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ffs
@@ -0,0 +1,9 @@
+What:           /config/usb-gadget/gadget/functions/ffs.name
+Date:           Nov 2013
+KernelVersion:  3.13
+Description:    The purpose of this directory is to create and remove it.
+                A corresponding USB function instance is created/removed.
+                There are no attributes here.
+                All parameters are set through FunctionFS.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-loopback b/Documentation/ABI/testing/configfs-usb-gadget-loopback
new file mode 100644
index 000000000000..9aae5bfb9908
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-loopback
@@ -0,0 +1,8 @@
+What:           /config/usb-gadget/gadget/functions/Loopback.name
+Date:           Nov 2013
+KernelVersion:  3.13
+Description:
+                The attributes:
+                qlen            - depth of loopback queue
+                bulk_buflen     - buffer length
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
index ad72a37ee9ff..9931fb0d63ba 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
+++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/mass_storage.name
 Date:           Oct 2013
-KenelVersion:   3.13
+KernelVersion:  3.13
 Description:
                The attributes:
@@ -13,7 +13,7 @@ Description:
 What:           /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
 Date:           Oct 2013
-KenelVersion:   3.13
+KernelVersion:  3.13
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ncm b/Documentation/ABI/testing/configfs-usb-gadget-ncm
index bc309f42357d..6fe723effc78 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-ncm
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ncm
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/ncm.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-obex b/Documentation/ABI/testing/configfs-usb-gadget-obex
index aaa5c96fb7c6..a6a9327ed9ba 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-obex
+++ b/Documentation/ABI/testing/configfs-usb-gadget-obex
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/obex.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This item contains just one readonly attribute: port_num.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-phonet b/Documentation/ABI/testing/configfs-usb-gadget-phonet
index 3e3b742cdfd7..7037a358e6c4 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-phonet
+++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/phonet.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This item contains just one readonly attribute: ifname.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis
index 822e6dad8fc0..e32879b84b4d 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-rndis
+++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/rndis.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-serial b/Documentation/ABI/testing/configfs-usb-gadget-serial
index 16f130c1501f..474d249f760b 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-serial
+++ b/Documentation/ABI/testing/configfs-usb-gadget-serial
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/gser.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                This item contains just one readonly attribute: port_num.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-sourcesink b/Documentation/ABI/testing/configfs-usb-gadget-sourcesink
new file mode 100644
index 000000000000..29477c319f61
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-sourcesink
@@ -0,0 +1,12 @@
+What:           /config/usb-gadget/gadget/functions/SourceSink.name
+Date:           Nov 2013
+KernelVersion:  3.13
+Description:
+                The attributes:
+                pattern         - 0 (all zeros), 1 (mod63), 2 (none)
+                isoc_interval   - 1..16
+                isoc_maxpacket  - 0 - 1023 (fs), 0 - 1024 (hs/ss)
+                isoc_mult       - 0..2 (hs/ss only)
+                isoc_maxburst   - 0..15 (ss only)
+                qlen            - buffer length
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-subset b/Documentation/ABI/testing/configfs-usb-gadget-subset
index 154ae597cd99..9373e2c51ea4 100644
--- a/Documentation/ABI/testing/configfs-usb-gadget-subset
+++ b/Documentation/ABI/testing/configfs-usb-gadget-subset
@@ -1,6 +1,6 @@
 What:           /config/usb-gadget/gadget/functions/geth.name
 Date:           Jun 2013
-KenelVersion:   3.11
+KernelVersion:  3.11
 Description:
                The attributes:
diff --git a/Documentation/ABI/testing/debugfs-driver-genwqe b/Documentation/ABI/testing/debugfs-driver-genwqe
new file mode 100644
index 000000000000..1c2f25674e8c
--- /dev/null
+++ b/Documentation/ABI/testing/debugfs-driver-genwqe
@@ -0,0 +1,91 @@
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/ddcb_info
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    DDCB queue dump used for debugging queueing problems.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/curr_regs
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Dump of the current error registers.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid0
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Internal chip state of UID0 (unit id 0).
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid1
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Internal chip state of UID1.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/curr_dbg_uid2
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Internal chip state of UID2.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/prev_regs
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Dump of the error registers before the last reset of
+                the card occured.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid0
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Internal chip state of UID0 before card was reset.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid1
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Internal chip state of UID1 before card was reset.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/prev_dbg_uid2
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Internal chip state of UID2 before card was reset.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/info
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Comprehensive summary of bitstream version and software
+                version. Used bitstream and bitstream clocking information.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/err_inject
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Possibility to inject error cases to ensure that the drivers
+                error handling code works well.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/vf<0..14>_jobtimeout_msec
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Default VF timeout 250ms. Testing might require 1000ms.
+                Using 0 will use the cards default value (whatever that is).
+                The timeout depends on the max number of available cards
+                in the system and the maximum allowed queue size.
+                The driver ensures that the settings are done just before
+                the VFs get enabled. Changing the timeouts in flight is not
+                possible.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/jobtimer
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Dump job timeout register values for PF and VFs.
+                Only available for PF.
+What:           /sys/kernel/debug/genwqe/genwqe<n>_card/queue_working_time
+Date:           Dec 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Dump queue working time register values for PF and VFs.
+                Only available for PF.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index b20e829d350f..6e02c5029152 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -197,6 +197,19 @@ Description:
                Raw pressure measurement from channel Y. Units after
                application of scale and offset are kilopascal.
+What:           /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_raw
+KernelVersion:  3.14
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Raw humidity measurement of air. Units after application of
+                scale and offset are milli percent.
+What:           /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_input
+KernelVersion:  3.14
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Scaled humidity measurement in milli percent.
 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
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 5210a51c90fd..a3c5a6685036 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -70,18 +70,15 @@ Date:		September, 2011
 Contact:        Neil Horman <nhorman@tuxdriver.com>
 Description:
                The /sys/devices/.../msi_irqs directory contains a variable set
-                of sub-directories, with each sub-directory being named after a
+                of files, with each file being named after a corresponding msi
-                corresponding msi irq vector allocated to that device.  Each
+                irq vector allocated to that device.
-                numbered sub-directory N contains attributes of that irq.
-                Note that this directory is not created for device drivers which
-                do not support msi irqs
-What:           /sys/bus/pci/devices/.../msi_irqs/<N>/mode
+What:           /sys/bus/pci/devices/.../msi_irqs/<N>
 Date:           September 2011
 Contact:        Neil Horman <nhorman@tuxdriver.com>
 Description:
                This attribute indicates the mode that the irq vector named by
-                the parent directory is in (msi vs. msix)
+                the file is in (msi vs. msix)
 What:           /sys/bus/pci/devices/.../remove
 Date:           January 2009
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd
index 0a306476424e..501adc2a9ec7 100644
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -18,6 +18,28 @@ Removal of a device:
  $ echo <dev-id> > /sys/bus/rbd/remove
+What:           /sys/bus/rbd/add_single_major
+Date:           December 2013
+KernelVersion:  3.14
+Contact:        Sage Weil <sage@inktank.com>
+Description:    Available only if rbd module is inserted with single_major
+                parameter set to true.
+                Usage is the same as for /sys/bus/rbd/add.  If present,
+                should be used instead of the latter: any attempts to use
+                /sys/bus/rbd/add if /sys/bus/rbd/add_single_major is
+                available will fail for backwards compatibility reasons.
+What:           /sys/bus/rbd/remove_single_major
+Date:           December 2013
+KernelVersion:  3.14
+Contact:        Sage Weil <sage@inktank.com>
+Description:    Available only if rbd module is inserted with single_major
+                parameter set to true.
+                Usage is the same as for /sys/bus/rbd/remove.  If present,
+                should be used instead of the latter: any attempts to use
+                /sys/bus/rbd/remove if /sys/bus/rbd/remove_single_major is
+                available will fail for backwards compatibility reasons.
 Entries under /sys/bus/rbd/devices/<dev-id>/
 --------------------------------------------
@@ -33,6 +55,10 @@ major
        The block device major number.
+minor
+        The block device minor number.  (December 2013, since 3.14.)
 name
        The name of the rbd image.
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index 1430f584b266..614d451cee41 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -50,13 +50,19 @@ Description:
                This may allow the driver to support more hardware than
                was included in the driver's static device ID support
                table at compile time. The format for the device ID is:
-                idVendor idProduct bInterfaceClass.
+                idVendor idProduct bInterfaceClass RefIdVendor RefIdProduct
                The vendor ID and device ID fields are required, the
-                interface class is optional.
+                rest is optional. The Ref* tuple can be used to tell the
+                driver to use the same driver_data for the new device as
+                it is used for the reference device.
                Upon successfully adding an ID, the driver will probe
                for the device and attempt to bind to it.  For example:
                # echo "8086 10f5" > /sys/bus/usb/drivers/foo/new_id
+                Here add a new device (0458:7045) using driver_data from
+                an already supported device (0458:704c):
+                # echo "0458 7045 0 0458 704c" > /sys/bus/usb/drivers/foo/new_id
                Reading from this file will list all dynamically added
                device IDs in the same format, with one entry per
                line. For example:
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index 0baa657b18c4..4793d3dff6af 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -68,6 +68,14 @@ Description:
                Defines the penalty which will be applied to an
                originator message's tq-field on every hop.
+What:           /sys/class/net/<mesh_iface>/mesh/isolation_mark
+Date:           Nov 2013
+Contact:        Antonio Quartulli <antonio@meshcoding.com>
+Description:
+                Defines the isolation mark (and its bitmask) which
+                is used to classify clients as "isolated" by the
+                Extended Isolation feature.
 What:           /sys/class/net/<mesh_iface>/mesh/network_coding
 Date:           Nov 2012
 Contact:        Martin Hundeboll <martin@hundeboll.net>
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 468e4d48f884..d5a0d33c571f 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -200,3 +200,27 @@ Description:	address and size of the percpu note.
                note of cpu#.
                crash_notes_size: size of the note of cpu#.
+What:           /sys/devices/system/cpu/intel_pstate/max_perf_pct
+                /sys/devices/system/cpu/intel_pstate/min_perf_pct
+                /sys/devices/system/cpu/intel_pstate/no_turbo
+Date:           February 2013
+Contact:        linux-pm@vger.kernel.org
+Description:    Parameters for the Intel P-state driver
+                Logic for selecting the current P-state in Intel
+                Sandybridge+ processors. The three knobs control
+                limits for the P-state that will be requested by the
+                driver.
+                max_perf_pct: limits the maximum P state that will be requested by
+                the driver stated as a percentage of the available performance.
+                min_perf_pct: limits the minimum P state that will be requested by
+                the driver stated as a percentage of the available performance.
+                no_turbo: limits the driver to selecting P states below the turbo
+                frequency range.
+                More details can be found in Documentation/cpu-freq/intel-pstate.txt
diff --git a/Documentation/ABI/testing/sysfs-driver-genwqe b/Documentation/ABI/testing/sysfs-driver-genwqe
new file mode 100644
index 000000000000..1870737a1f5e
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-genwqe
@@ -0,0 +1,62 @@
+What:           /sys/class/genwqe/genwqe<n>_card/version
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Unique bitstream identification e.g.
+                '0000000330336283.00000000475a4950'.
+What:           /sys/class/genwqe/genwqe<n>_card/appid
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Identifies the currently active card application e.g. 'GZIP'
+                for compression/decompression.
+What:           /sys/class/genwqe/genwqe<n>_card/type
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Type of the card e.g. 'GenWQE5-A7'.
+What:           /sys/class/genwqe/genwqe<n>_card/curr_bitstream
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Currently active bitstream. 1 is default, 0 is backup.
+What:           /sys/class/genwqe/genwqe<n>_card/next_bitstream
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Interface to set the next bitstream to be used.
+What:           /sys/class/genwqe/genwqe<n>_card/tempsens
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Interface to read the cards temperature sense register.
+What:           /sys/class/genwqe/genwqe<n>_card/freerunning_timer
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Interface to read the cards free running timer.
+                Used for performance and utilization measurements.
+What:           /sys/class/genwqe/genwqe<n>_card/queue_working_time
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Interface to read queue working time.
+                Used for performance and utilization measurements.
+What:           /sys/class/genwqe/genwqe<n>_card/state
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    State of the card: "unused", "used", "error".
+What:           /sys/class/genwqe/genwqe<n>_card/base_clock
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Base clock frequency of the card.
+What:           /sys/class/genwqe/genwqe<n>_card/device/sriov_numvfs
+Date:           Oct 2013
+Contact:        haver@linux.vnet.ibm.com
+Description:    Enable VFs (1..15):
+                  sudo sh -c 'echo 15 > \
+                    /sys/bus/pci/devices/0000\:1b\:00.0/sriov_numvfs'
+                Disable VFs:
+                  Write a 0 into the same sysfs entry.
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 31942efcaf0e..32b0809203dd 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -24,3 +24,34 @@ Date:		July 2013
 Contact:        "Namjae Jeon" <namjae.jeon@samsung.com>
 Description:
                 Controls the victim selection policy for garbage collection.
+What:           /sys/fs/f2fs/<disk>/reclaim_segments
+Date:           October 2013
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the issue rate of segment discard commands.
+What:           /sys/fs/f2fs/<disk>/ipu_policy
+Date:           November 2013
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the in-place-update policy.
+What:           /sys/fs/f2fs/<disk>/min_ipu_util
+Date:           November 2013
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the FS utilization condition for the in-place-update
+                 policies.
+What:           /sys/fs/f2fs/<disk>/max_small_discards
+Date:           November 2013
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the issue rate of small discard commands.
+What:           /sys/fs/f2fs/<disk>/max_victim_search
+Date:           January 2014
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the number of trials to find a victim segment.
diff --git a/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo b/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
new file mode 100644
index 000000000000..7bd81168e063
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-vmcoreinfo
@@ -0,0 +1,14 @@
+What:           /sys/kernel/vmcoreinfo
+Date:           October 2007
+KernelVersion:  2.6.24
+Contact:        Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
+                Kexec Mailing List <kexec@lists.infradead.org>
+                Vivek Goyal <vgoyal@redhat.com>
+Description
+                Shows physical address and size of vmcoreinfo ELF note.
+                First value contains physical address of note in hex and
+                second value contains the size of note in hex. This ELF
+                note info is parsed by second kernel and exported to user
+                space as part of ELF note in /proc/vmcore file. This note
+                contains various information like struct size, symbol
+                values, page size etc.
diff --git a/Documentation/ABI/testing/sysfs-platform-tahvo-usb b/Documentation/ABI/testing/sysfs-platform-tahvo-usb
new file mode 100644
index 000000000000..f6e20ce4b538
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform-tahvo-usb
@@ -0,0 +1,16 @@
+What:           /sys/bus/platform/devices/tahvo-usb/otg_mode
+Date:           December 2013
+Contact:        Aaro Koskinen <aaro.koskinen@iki.fi>
+Description:
+                Set or read the current OTG mode. Valid values are "host" and
+                "peripheral".
+                Reading: returns the current mode.
+What:           /sys/bus/platform/devices/tahvo-usb/vbus
+Date:           December 2013
+Contact:        Aaro Koskinen <aaro.koskinen@iki.fi>
+Description:
+                Read the current VBUS state.
+                Reading: returns "on" or "off".
diff --git a/Documentation/DocBook/.gitignore b/Documentation/DocBook/.gitignore
index 720f245ceb1f..7ebd5465d927 100644
--- a/Documentation/DocBook/.gitignore
+++ b/Documentation/DocBook/.gitignore
@@ -10,5 +10,6 @@
 *.out
 *.png
 *.gif
+*.svg
 media-indices.tmpl
 media-entities.tmpl
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index bc3d9f8c0a90..0f9c6ff41aac 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -54,6 +54,7 @@ htmldocs: $(HTML)
 MAN := $(patsubst %.xml, %.9, $(BOOKS))
 mandocs: $(MAN)
+        $(if $(wildcard $(obj)/man/*.9),gzip -f $(obj)/man/*.9)
 installmandocs: mandocs
        mkdir -p /usr/local/man/man9/
@@ -145,7 +146,7 @@ build_main_index = rm -rf $(main_idx); \
                   cat $(HTML) >> $(main_idx)
 quiet_cmd_db2html = HTML    $@
-      cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
+      cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
                echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
        $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
@@ -159,7 +160,7 @@ quiet_cmd_db2html = HTML    $@
            cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
 quiet_cmd_db2man = MAN     $@
-      cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; gzip -f $(obj)/man/*.9; fi
+      cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi
 %.9 : %.xml
        @(which xmlto > /dev/null 2>&1) || \
         (echo "*** You need to install xmlto ***"; \
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index f75ab4c1b281..ecfd0ea40661 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -109,6 +109,7 @@ X!Ilib/string.c
     <sect1><title>The Slab Cache</title>
 !Iinclude/linux/slab.h
 !Emm/slab.c
+!Emm/util.c
     </sect1>
     <sect1><title>User Space Memory Access</title>
 !Iarch/x86/include/asm/uaccess_32.h
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 27faae3e3846..57cf5efb044d 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -112,7 +112,7 @@ required reading:
    Other excellent descriptions of how to create patches properly are:
        "The Perfect Patch"
-                http://kerneltrap.org/node/3737
+                http://www.ozlabs.org/~akpm/stuff/tpp.txt
        "Linux kernel patch submission format"
                http://linux.yyz.us/patch-format.html
@@ -579,7 +579,7 @@ all time.  It should describe the patch completely, containing:
 For more details on what this should all look like, please see the
 ChangeLog section of the document:
  "The Perfect Patch"
-      http://userweb.kernel.org/~akpm/stuff/tpp.txt
+      http://www.ozlabs.org/~akpm/stuff/tpp.txt
diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index 9bc95942ec22..03df71aeb38c 100644
--- a/Documentation/IRQ-domain.txt
+++ b/Documentation/IRQ-domain.txt
@@ -141,7 +141,7 @@ will use a legacy domain only if an IRQ range is supplied by the
 system and will otherwise use a linear domain mapping. The semantics
 of this call are such that if an IRQ range is specified then
 descriptors will be allocated on-the-fly for it, and if no range is
-specified it will fall through to irq_domain_add_linear() which meand
+specified it will fall through to irq_domain_add_linear() which means
 *no* irq descriptors will be allocated.
 A typical use case for simple domains is where an irqchip provider
diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index 812b17fe3ed0..147231f1613e 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -2,12 +2,12 @@
        - this file
 MSI-HOWTO.txt
        - the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
-PCI-DMA-mapping.txt
-        - info for PCI drivers using DMA portably across all platforms
 PCIEBUS-HOWTO.txt
        - a guide describing the PCI Express Port Bus driver
 pci-error-recovery.txt
        - info on PCI error recovery
+pci-iov-howto.txt
+        - the PCI Express I/O Virtualization HOWTO
 pci.txt
        - info on the PCI subsystem for device driver authors
 pcieaer-howto.txt
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index a09178086c30..a8d01005f480 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -82,93 +82,111 @@ Most of the hard work is done for the driver in the PCI layer.  It simply
 has to request that the PCI layer set up the MSI capability for this
 device.
-4.2.1 pci_enable_msi
+4.2.1 pci_enable_msi_range
-int pci_enable_msi(struct pci_dev *dev)
+int pci_enable_msi_range(struct pci_dev *dev, int minvec, int maxvec)
-A successful call allocates ONE interrupt to the device, regardless
+This function allows a device driver to request any number of MSI
-of how many MSIs the device supports.  The device is switched from
+interrupts within specified range from 'minvec' to 'maxvec'.
-pin-based interrupt mode to MSI mode.  The dev->irq number is changed
-to a new number which represents the message signaled interrupt;
-consequently, this function should be called before the driver calls
-request_irq(), because an MSI is delivered via a vector that is
-different from the vector of a pin-based interrupt.
-4.2.2 pci_enable_msi_block
+If this function returns a positive number it indicates the number of
+MSI interrupts that have been successfully allocated.  In this case
+the device is switched from pin-based interrupt mode to MSI mode and
+updates dev->irq to be the lowest of the new interrupts assigned to it.
+The other interrupts assigned to the device are in the range dev->irq
+to dev->irq + returned value - 1.  Device driver can use the returned
+number of successfully allocated MSI interrupts to further allocate
+and initialize device resources.
-int pci_enable_msi_block(struct pci_dev *dev, int count)
+If this function returns a negative number, it indicates an error and
+the driver should not attempt to request any more MSI interrupts for
+this device.
-This variation on the above call allows a device driver to request multiple
+This function should be called before the driver calls request_irq(),
-MSIs.  The MSI specification only allows interrupts to be allocated in
+because MSI interrupts are delivered via vectors that are different
-powers of two, up to a maximum of 2^5 (32).
+from the vector of a pin-based interrupt.
-If this function returns 0, it has succeeded in allocating at least as many
+It is ideal if drivers can cope with a variable number of MSI interrupts;
-interrupts as the driver requested (it may have allocated more in order
+there are many reasons why the platform may not be able to provide the
-to satisfy the power-of-two requirement).  In this case, the function
+exact number that a driver asks for.
-enables MSI on this device and updates dev->irq to be the lowest of
-the new interrupts assigned to it.  The other interrupts assigned to
-the device are in the range dev->irq to dev->irq + count - 1.
-If this function returns a negative number, it indicates an error and
+There could be devices that can not operate with just any number of MSI
-the driver should not attempt to request any more MSI interrupts for
+interrupts within a range.  See chapter 4.3.1.3 to get the idea how to
-this device.  If this function returns a positive number, it is
+handle such devices for MSI-X - the same logic applies to MSI.
-less than 'count' and indicates the number of interrupts that could have
-been allocated.  In neither case is the irq value updated or the device
-switched into MSI mode.
-The device driver must decide what action to take if
-pci_enable_msi_block() returns a value less than the number requested.
-For instance, the driver could still make use of fewer interrupts;
-in this case the driver should call pci_enable_msi_block()
-again.  Note that it is not guaranteed to succeed, even when the
-'count' has been reduced to the value returned from a previous call to
-pci_enable_msi_block().  This is because there are multiple constraints
-on the number of vectors that can be allocated; pci_enable_msi_block()
-returns as soon as it finds any constraint that doesn't allow the
-call to succeed.
-4.2.3 pci_enable_msi_block_auto
-int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
-This variation on pci_enable_msi() call allows a device driver to request
-the maximum possible number of MSIs.  The MSI specification only allows
-interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
-If this function returns a positive number, it indicates that it has
-succeeded and the returned value is the number of allocated interrupts. In
-this case, the function enables MSI on this device and updates dev->irq to
-be the lowest of the new interrupts assigned to it.  The other interrupts
-assigned to the device are in the range dev->irq to dev->irq + returned
-value - 1.
-If this function returns a negative number, it indicates an error and
+4.2.1.1 Maximum possible number of MSI interrupts
-the driver should not attempt to request any more MSI interrupts for
-this device.
+The typical usage of MSI interrupts is to allocate as many vectors as
+possible, likely up to the limit returned by pci_msi_vec_count() function:
+static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
+{
+        return pci_enable_msi_range(pdev, 1, nvec);
+}
+Note the value of 'minvec' parameter is 1.  As 'minvec' is inclusive,
+the value of 0 would be meaningless and could result in error.
-If the device driver needs to know the number of interrupts the device
+Some devices have a minimal limit on number of MSI interrupts.
-supports it can pass the pointer count where that number is stored. The
+In this case the function could look like this:
-device driver must decide what action to take if pci_enable_msi_block_auto()
-succeeds, but returns a value less than the number of interrupts supported.
-If the device driver does not need to know the number of interrupts
-supported, it can set the pointer count to NULL.
-4.2.4 pci_disable_msi
+static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
+{
+        return pci_enable_msi_range(pdev, FOO_DRIVER_MINIMUM_NVEC, nvec);
+}
+4.2.1.2 Exact number of MSI interrupts
+If a driver is unable or unwilling to deal with a variable number of MSI
+interrupts it could request a particular number of interrupts by passing
+that number to pci_enable_msi_range() function as both 'minvec' and 'maxvec'
+parameters:
+static int foo_driver_enable_msi(struct pci_dev *pdev, int nvec)
+{
+        return pci_enable_msi_range(pdev, nvec, nvec);
+}
+4.2.1.3 Single MSI mode
+The most notorious example of the request type described above is
+enabling the single MSI mode for a device.  It could be done by passing
+two 1s as 'minvec' and 'maxvec':
+static int foo_driver_enable_single_msi(struct pci_dev *pdev)
+{
+        return pci_enable_msi_range(pdev, 1, 1);
+}
+4.2.2 pci_disable_msi
 void pci_disable_msi(struct pci_dev *dev)
-This function should be used to undo the effect of pci_enable_msi() or
+This function should be used to undo the effect of pci_enable_msi_range().
-pci_enable_msi_block() or pci_enable_msi_block_auto().  Calling it restores
+Calling it restores dev->irq to the pin-based interrupt number and frees
-dev->irq to the pin-based interrupt number and frees the previously
+the previously allocated MSIs.  The interrupts may subsequently be assigned
-allocated message signaled interrupt(s).  The interrupt may subsequently be
+to another device, so drivers should not cache the value of dev->irq.
-assigned to another device, so drivers should not cache the value of
-dev->irq.
 Before calling this function, a device driver must always call free_irq()
 on any interrupt for which it previously called request_irq().
 Failure to do so results in a BUG_ON(), leaving the device with
 MSI enabled and thus leaking its vector.
+4.2.3 pci_msi_vec_count
+int pci_msi_vec_count(struct pci_dev *dev)
+This function could be used to retrieve the number of MSI vectors the
+device requested (via the Multiple Message Capable register). The MSI
+specification only allows the returned value to be a power of two,
+up to a maximum of 2^5 (32).
+If this function returns a negative number, it indicates the device is
+not capable of sending MSIs.
+If this function returns a positive number, it indicates the maximum
+number of MSI interrupt vectors that could be allocated.
 4.3 Using MSI-X
 The MSI-X capability is much more flexible than the MSI capability.
@@ -188,26 +206,31 @@ in each element of the array to indicate for which entries the kernel
 should assign interrupts; it is invalid to fill in two entries with the
 same number.
-4.3.1 pci_enable_msix
+4.3.1 pci_enable_msix_range
-int pci_enable_msix(struct pci_dev *dev, struct msix_entry *entries, int nvec)
+int pci_enable_msix_range(struct pci_dev *dev, struct msix_entry *entries,
+                          int minvec, int maxvec)
-Calling this function asks the PCI subsystem to allocate 'nvec' MSIs.
+Calling this function asks the PCI subsystem to allocate any number of
+MSI-X interrupts within specified range from 'minvec' to 'maxvec'.
 The 'entries' argument is a pointer to an array of msix_entry structs
-which should be at least 'nvec' entries in size.  On success, the
+which should be at least 'maxvec' entries in size.
-device is switched into MSI-X mode and the function returns 0.
-The 'vector' member in each entry is populated with the interrupt number;
+On success, the device is switched into MSI-X mode and the function
+returns the number of MSI-X interrupts that have been successfully
+allocated.  In this case the 'vector' member in entries numbered from
+0 to the returned value - 1 is populated with the interrupt number;
 the driver should then call request_irq() for each 'vector' that it
 decides to use.  The device driver is responsible for keeping track of the
 interrupts assigned to the MSI-X vectors so it can free them again later.
+Device driver can use the returned number of successfully allocated MSI-X
+interrupts to further allocate and initialize device resources.
 If this function returns a negative number, it indicates an error and
 the driver should not attempt to allocate any more MSI-X interrupts for
-this device.  If it returns a positive number, it indicates the maximum
+this device.
-number of interrupt vectors that could have been allocated. See example
-below.
-This function, in contrast with pci_enable_msi(), does not adjust
+This function, in contrast with pci_enable_msi_range(), does not adjust
 dev->irq.  The device will not generate interrupts for this interrupt
 number once MSI-X is enabled.
@@ -218,28 +241,103 @@ It is ideal if drivers can cope with a variable number of MSI-X interrupts;
 there are many reasons why the platform may not be able to provide the
 exact number that a driver asks for.
-A request loop to achieve that might look like:
+There could be devices that can not operate with just any number of MSI-X
+interrupts within a range.  E.g., an network adapter might need let's say
+four vectors per each queue it provides.  Therefore, a number of MSI-X
+interrupts allocated should be a multiple of four.  In this case interface
+pci_enable_msix_range() can not be used alone to request MSI-X interrupts
+(since it can allocate any number within the range, without any notion of
+the multiple of four) and the device driver should master a custom logic
+to request the required number of MSI-X interrupts.
+4.3.1.1 Maximum possible number of MSI-X interrupts
+The typical usage of MSI-X interrupts is to allocate as many vectors as
+possible, likely up to the limit returned by pci_msix_vec_count() function:
 static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
 {
-        while (nvec >= FOO_DRIVER_MINIMUM_NVEC) {
+        return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
-                rc = pci_enable_msix(adapter->pdev,
+                                    1, nvec);
-                                     adapter->msix_entries, nvec);
+}
-                if (rc > 0)
-                        nvec = rc;
+Note the value of 'minvec' parameter is 1.  As 'minvec' is inclusive,
-                else
+the value of 0 would be meaningless and could result in error.
-                        return rc;
+Some devices have a minimal limit on number of MSI-X interrupts.
+In this case the function could look like this:
+static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
+{
+        return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
+                                    FOO_DRIVER_MINIMUM_NVEC, nvec);
+}
+4.3.1.2 Exact number of MSI-X interrupts
+If a driver is unable or unwilling to deal with a variable number of MSI-X
+interrupts it could request a particular number of interrupts by passing
+that number to pci_enable_msix_range() function as both 'minvec' and 'maxvec'
+parameters:
+static int foo_driver_enable_msix(struct foo_adapter *adapter, int nvec)
+{
+        return pci_enable_msi_range(adapter->pdev, adapter->msix_entries,
+                                    nvec, nvec);
+}
+4.3.1.3 Specific requirements to the number of MSI-X interrupts
+As noted above, there could be devices that can not operate with just any
+number of MSI-X interrupts within a range.  E.g., let's assume a device that
+is only capable sending the number of MSI-X interrupts which is a power of
+two.  A routine that enables MSI-X mode for such device might look like this:
+/*
+ * Assume 'minvec' and 'maxvec' are non-zero
+ */
+static int foo_driver_enable_msix(struct foo_adapter *adapter,
+                                  int minvec, int maxvec)
+{
+        int rc;
+        minvec = roundup_pow_of_two(minvec);
+        maxvec = rounddown_pow_of_two(maxvec);
+        if (minvec > maxvec)
+                return -ERANGE;
+retry:
+        rc = pci_enable_msix_range(adapter->pdev, adapter->msix_entries,
+                                   maxvec, maxvec);
+        /*
+         * -ENOSPC is the only error code allowed to be analized
+         */
+        if (rc == -ENOSPC) {
+                if (maxvec == 1)
+                        return -ENOSPC;
+                maxvec /= 2;
+                if (minvec > maxvec)
+                        return -ENOSPC;
+                goto retry;
        }
-        return -ENOSPC;
+        return rc;
 }
+Note how pci_enable_msix_range() return value is analized for a fallback -
+any error code other than -ENOSPC indicates a fatal error and should not
+be retried.
 4.3.2 pci_disable_msix
 void pci_disable_msix(struct pci_dev *dev)
-This function should be used to undo the effect of pci_enable_msix().  It frees
+This function should be used to undo the effect of pci_enable_msix_range().
-the previously allocated message signaled interrupts.  The interrupts may
+It frees the previously allocated MSI-X interrupts. The interrupts may
 subsequently be assigned to another device, so drivers should not cache
 the value of the 'vector' elements over a call to pci_disable_msix().
@@ -255,18 +353,32 @@ MSI-X Table.  This address is mapped by the PCI subsystem, and should not
 be accessed directly by the device driver.  If the driver wishes to
 mask or unmask an interrupt, it should call disable_irq() / enable_irq().
+4.3.4 pci_msix_vec_count
+int pci_msix_vec_count(struct pci_dev *dev)
+This function could be used to retrieve number of entries in the device
+MSI-X table.
+If this function returns a negative number, it indicates the device is
+not capable of sending MSI-Xs.
+If this function returns a positive number, it indicates the maximum
+number of MSI-X interrupt vectors that could be allocated.
 4.4 Handling devices implementing both MSI and MSI-X capabilities
 If a device implements both MSI and MSI-X capabilities, it can
 run in either MSI mode or MSI-X mode, but not both simultaneously.
 This is a requirement of the PCI spec, and it is enforced by the
-PCI layer.  Calling pci_enable_msi() when MSI-X is already enabled or
+PCI layer.  Calling pci_enable_msi_range() when MSI-X is already
-pci_enable_msix() when MSI is already enabled results in an error.
+enabled or pci_enable_msix_range() when MSI is already enabled
-If a device driver wishes to switch between MSI and MSI-X at runtime,
+results in an error.  If a device driver wishes to switch between MSI
-it must first quiesce the device, then switch it back to pin-interrupt
+and MSI-X at runtime, it must first quiesce the device, then switch
-mode, before calling pci_enable_msi() or pci_enable_msix() and resuming
+it back to pin-interrupt mode, before calling pci_enable_msi_range()
-operation.  This is not expected to be a common operation but may be
+or pci_enable_msix_range() and resuming operation.  This is not expected
-useful for debugging or testing during development.
+to be a common operation but may be useful for debugging or testing
+during development.
 4.5 Considerations when using MSIs
@@ -381,5 +493,5 @@ or disabled (0).  If 0 is found in any of the msi_bus files belonging
 to bridges between the PCI root and the device, MSIs are disabled.
 It is also worth checking the device driver to see whether it supports MSIs.
-For example, it may contain calls to pci_enable_msi(), pci_enable_msix() or
+For example, it may contain calls to pci_enable_msi_range() or
-pci_enable_msi_block().
+pci_enable_msix_range().
diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt
index 6f458564d625..9518006f6675 100644
--- a/Documentation/PCI/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -123,8 +123,10 @@ initialization with a pointer to a structure describing the driver
 The ID table is an array of struct pci_device_id entries ending with an
-all-zero entry; use of the macro DEFINE_PCI_DEVICE_TABLE is the preferred
+all-zero entry.  Definitions with static const are generally preferred.
-method of declaring the table.  Each entry consists of:
+Use of the deprecated macro DEFINE_PCI_DEVICE_TABLE should be avoided.
+Each entry consists of:
        vendor,device   Vendor and device ID to match (or PCI_ANY_ID)
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index b994bcb32b92..2a1519b87177 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -293,36 +293,13 @@ the device to the driver. For example:
 These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
 specifies the path to the controller. In order to use these GPIOs in Linux
-we need to translate them to the Linux GPIO numbers.
+we need to translate them to the corresponding Linux GPIO descriptors.
-In a simple case of just getting the Linux GPIO number from device
+There is a standard GPIO API for that and is documented in
-resources one can use acpi_get_gpio_by_index() helper function. It takes
+Documentation/gpio.txt.
-pointer to the device and index of the GpioIo/GpioInt descriptor in the
-device resources list. For example:
-        int gpio_irq, gpio_power;
+In the above example we can get the corresponding two GPIO descriptors with
-        int ret;
+a code like this:
-        gpio_irq = acpi_get_gpio_by_index(dev, 1, NULL);
-        if (gpio_irq < 0)
-                /* handle error */
-        gpio_power = acpi_get_gpio_by_index(dev, 0, NULL);
-        if (gpio_power < 0)
-                /* handle error */
-        /* Now we can use the GPIO numbers */
-Other GpioIo parameters must be converted first by the driver to be
-suitable to the gpiolib before passing them.
-In case of GpioInt resource an additional call to gpio_to_irq() must be
-done before calling request_irq().
-Note that the above API is ACPI specific and not recommended for drivers
-that need to support non-ACPI systems. The recommended way is to use
-the descriptor based GPIO interfaces. The above example looks like this
-when converted to the GPIO desc:
        #include <linux/gpio/consumer.h>
        ...
@@ -339,4 +316,5 @@ when converted to the GPIO desc:
        /* Now we can use the GPIO descriptors */
-See also Documentation/gpio.txt.
+There are also devm_* versions of these functions which release the
+descriptors once the device is released.
diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt
index 260f6a3661fa..1860cb3865c6 100644
--- a/Documentation/acpi/namespace.txt
+++ b/Documentation/acpi/namespace.txt
@@ -235,10 +235,6 @@ Wysocki <rafael.j.wysocki@intel.com>.
      named object's type in the second column).  In that case the object's
      directory in sysfs will contain the 'path' attribute whose value is
      the full path to the node from the namespace root.
-      struct acpi_device objects are created for the ACPI namespace nodes
-      whose _STA control methods return PRESENT or FUNCTIONING.  The power
-      resource nodes or nodes without _STA are assumed to be both PRESENT
-      and FUNCTIONING.
   F:
      The struct acpi_device object is created for a fixed hardware
      feature (as indicated by the fixed feature flag's name in the second
@@ -340,7 +336,7 @@ Wysocki <rafael.j.wysocki@intel.com>.
     | +-------------+-------+----------------+
     |   |
     |   | +- - - - - - - +- - - - - - +- - - - - - - -+
-     |   +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
+     |   +-| PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
     |   | +- - - - - - - +- - - - - - +- - - - - - - -+
     |   |
     |   | +------------+------------+-----------------------+
@@ -390,6 +386,3 @@ Wysocki <rafael.j.wysocki@intel.com>.
            attribute (as described earlier in this document).
   NOTE: N/A indicates the device object does not have the 'path' or the
         'modalias' attribute.
-   NOTE: The PNP0C0D device listed above is highlighted (marked by "*")
-         to indicate it will be created only when its _STA methods return
-         PRESENT or FUNCTIONING.
diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index da0151db9964..5a930c1528ad 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -211,6 +211,30 @@ MMP/MMP2 family (communication processor)
   Linux kernel mach directory: arch/arm/mach-mmp
   Linux kernel plat directory: arch/arm/plat-pxa
+Berlin family (Digital Entertainment)
+-------------------------------------
+  Flavors:
+        88DE3005, Armada 1500-mini
+                Design name:    BG2CD
+                Core:           ARM Cortex-A9, PL310 L2CC
+                Homepage:       http://www.marvell.com/digital-entertainment/armada-1500-mini/
+        88DE3100, Armada 1500
+                Design name:    BG2
+                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
+        88DE????
+                Design name:    BG3
+                Core:           ARM Cortex-A15, CA15 integrated L2CC
+  Homepage: http://www.marvell.com/digital-entertainment/
+  Directory: arch/arm/mach-berlin
+  Comments:
+   * This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
+     with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
 Long-term plans
 ---------------
diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
index 8b46c79679c4..0ebd7e2244d0 100644
--- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt
+++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt
@@ -85,21 +85,10 @@ between the calls.
 Headers
 -------
-  See arch/arm/mach-s3c2410/include/mach/regs-gpio.h for the list
+  See arch/arm/mach-s3c24xx/include/mach/regs-gpio.h for the list
  of GPIO pins, and the configuration values for them. This
  is included by using #include <mach/regs-gpio.h>
-  The GPIO management functions are defined in the hardware
-  header arch/arm/mach-s3c2410/include/mach/hardware.h which can be
-  included by #include <mach/hardware.h>
-  A useful amount of documentation can be found in the hardware
-  header on how the GPIO functions (and others) work.
-  Whilst a number of these functions do make some checks on what
-  is passed to them, for speed of use, they may not always ensure
-  that the user supplied data to them is correct.
 PIN Numbers
 -----------
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 8df5e8e6dceb..2101e718670d 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -447,14 +447,13 @@ struct bio_vec {
 * main unit of I/O for the block layer and lower layers (ie drivers)
 */
 struct bio {
-       sector_t            bi_sector;
       struct bio          *bi_next;    /* request queue link */
       struct block_device *bi_bdev;    /* target device */
       unsigned long       bi_flags;    /* status, command, etc */
       unsigned long       bi_rw;       /* low bits: r/w, high: priority */
       unsigned int     bi_vcnt;     /* how may bio_vec's */
-       unsigned int     bi_idx;         /* current index into bio_vec array */
+       struct bvec_iter bi_iter;        /* current index into bio_vec array */
       unsigned int     bi_size;     /* total size in bytes */
       unsigned short   bi_phys_segments; /* segments after physaddr coalesce*/
@@ -480,7 +479,7 @@ With this multipage bio design:
 - Code that traverses the req list can find all the segments of a bio
  by using rq_for_each_segment.  This handles the fact that a request
  has multiple bios, each of which can have multiple segments.
- Drivers which can't process a large bio in one shot can use the bi_idx
+- Drivers which can't process a large bio in one shot can use the bi_iter
  field to keep track of the next bio_vec entry to process.
  (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE)
  [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying
@@ -589,7 +588,7 @@ driver should not modify these values. The block layer sets up the
 nr_sectors and current_nr_sectors fields (based on the corresponding
 hard_xxx values and the number of bytes transferred) and updates it on
 every transfer that invokes end_that_request_first. It does the same for the
-buffer, bio, bio->bi_idx fields too.
+buffer, bio, bio->bi_iter fields too.
 The buffer field is just a virtual address mapping of the current segment
 of the i/o buffer in cases where the buffer resides in low-memory. For high
diff --git a/Documentation/block/biovecs.txt b/Documentation/block/biovecs.txt
new file mode 100644
index 000000000000..74a32ad52f53
--- /dev/null
+++ b/Documentation/block/biovecs.txt
@@ -0,0 +1,111 @@
+Immutable biovecs and biovec iterators:
+=======================================
+Kent Overstreet <kmo@daterainc.com>
+As of 3.13, biovecs should never be modified after a bio has been submitted.
+Instead, we have a new struct bvec_iter which represents a range of a biovec -
+the iterator will be modified as the bio is completed, not the biovec.
+More specifically, old code that needed to partially complete a bio would
+update bi_sector and bi_size, and advance bi_idx to the next biovec. If it
+ended up partway through a biovec, it would increment bv_offset and decrement
+bv_len by the number of bytes completed in that biovec.
+In the new scheme of things, everything that must be mutated in order to
+partially complete a bio is segregated into struct bvec_iter: bi_sector,
+bi_size and bi_idx have been moved there; and instead of modifying bv_offset
+and bv_len, struct bvec_iter has bi_bvec_done, which represents the number of
+bytes completed in the current bvec.
+There are a bunch of new helper macros for hiding the gory details - in
+particular, presenting the illusion of partially completed biovecs so that
+normal code doesn't have to deal with bi_bvec_done.
+ * Driver code should no longer refer to biovecs directly; we now have
+   bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
+   constructed from the raw biovecs but taking into account bi_bvec_done and
+   bi_size.
+   bio_for_each_segment() has been updated to take a bvec_iter argument
+   instead of an integer (that corresponded to bi_idx); for a lot of code the
+   conversion just required changing the types of the arguments to
+   bio_for_each_segment().
+ * Advancing a bvec_iter is done with bio_advance_iter(); bio_advance() is a
+   wrapper around bio_advance_iter() that operates on bio->bi_iter, and also
+   advances the bio integrity's iter if present.
+   There is a lower level advance function - bvec_iter_advance() - which takes
+   a pointer to a biovec, not a bio; this is used by the bio integrity code.
+What's all this get us?
+=======================
+Having a real iterator, and making biovecs immutable, has a number of
+advantages:
+ * Before, iterating over bios was very awkward when you weren't processing
+   exactly one bvec at a time - for example, bio_copy_data() in fs/bio.c,
+   which copies the contents of one bio into another. Because the biovecs
+   wouldn't necessarily be the same size, the old code was tricky convoluted -
+   it had to walk two different bios at the same time, keeping both bi_idx and
+   and offset into the current biovec for each.
+   The new code is much more straightforward - have a look. This sort of
+   pattern comes up in a lot of places; a lot of drivers were essentially open
+   coding bvec iterators before, and having common implementation considerably
+   simplifies a lot of code.
+ * Before, any code that might need to use the biovec after the bio had been
+   completed (perhaps to copy the data somewhere else, or perhaps to resubmit
+   it somewhere else if there was an error) had to save the entire bvec array
+   - again, this was being done in a fair number of places.
+ * Biovecs can be shared between multiple bios - a bvec iter can represent an
+   arbitrary range of an existing biovec, both starting and ending midway
+   through biovecs. This is what enables efficient splitting of arbitrary
+   bios. Note that this means we _only_ use bi_size to determine when we've
+   reached the end of a bio, not bi_vcnt - and the bio_iovec() macro takes
+   bi_size into account when constructing biovecs.
+ * Splitting bios is now much simpler. The old bio_split() didn't even work on
+   bios with more than a single bvec! Now, we can efficiently split arbitrary
+   size bios - because the new bio can share the old bio's biovec.
+   Care must be taken to ensure the biovec isn't freed while the split bio is
+   still using it, in case the original bio completes first, though. Using
+   bio_chain() when splitting bios helps with this.
+ * Submitting partially completed bios is now perfectly fine - this comes up
+   occasionally in stacking block drivers and various code (e.g. md and
+   bcache) had some ugly workarounds for this.
+   It used to be the case that submitting a partially completed bio would work
+   fine to _most_ devices, but since accessing the raw bvec array was the
+   norm, not all drivers would respect bi_idx and those would break. Now,
+   since all drivers _must_ go through the bvec iterator - and have been
+   audited to make sure they are - submitting partially completed bios is
+   perfectly fine.
+Other implications:
+===================
+ * Almost all usage of bi_idx is now incorrect and has been removed; instead,
+   where previously you would have used bi_idx you'd now use a bvec_iter,
+   probably passing it to one of the helper macros.
+   I.e. instead of using bio_iovec_idx() (or bio->bi_iovec[bio->bi_idx]), you
+   now use bio_iter_iovec(), which takes a bvec_iter and returns a
+   literal struct bio_vec - constructed on the fly from the raw biovec but
+   taking into account bi_bvec_done (and bi_size).
+ * bi_vcnt can't be trusted or relied upon by driver code - i.e. anything that
+   doesn't actually own the bio. The reason is twofold: firstly, it's not
+   actually needed for iterating over the bio anymore - we only use bi_size.
+   Secondly, when cloning a bio and reusing (a portion of) the original bio's
+   biovec, in order to calculate bi_vcnt for the new bio we'd have to iterate
+   over all the biovecs in the new bio - which is silly as it's not needed.
+   So, don't use bi_vcnt anymore.
diff --git a/Documentation/blockdev/ramdisk.txt b/Documentation/blockdev/ramdisk.txt
index fa72e97dd669..fe2ef978d85a 100644
--- a/Documentation/blockdev/ramdisk.txt
+++ b/Documentation/blockdev/ramdisk.txt
@@ -36,21 +36,30 @@ allowing one to squeeze more programs onto an average installation or
 rescue floppy disk.
-2) Kernel Command Line Parameters
+2) Parameters
 ---------------------------------
+2a) Kernel Command Line Parameters
        ramdisk_size=N
        ==============
 This parameter tells the RAM disk driver to set up RAM disks of N k size.  The
-default is 4096 (4 MB) (8192 (8 MB) on S390).
+default is 4096 (4 MB).
+2b) Module parameters
-        ramdisk_blocksize=N
+        rd_nr
-        ===================
+        =====
+        /dev/ramX devices created.
-This parameter tells the RAM disk driver how many bytes to use per block.  The
+        max_part
-default is 1024 (BLOCK_SIZE).
+        ========
+        Maximum partition number.
+        rd_size
+        =======
+        See ramdisk_size.
 3) Using "rdev -r"
 ------------------
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
new file mode 100644
index 000000000000..2eccddffa6c8
--- /dev/null
+++ b/Documentation/blockdev/zram.txt
@@ -0,0 +1,71 @@
+zram: Compressed RAM based block devices
+----------------------------------------
+* Introduction
+The zram module creates RAM based block devices named /dev/zram<id>
+(<id> = 0, 1, ...). Pages written to these disks are compressed and stored
+in memory itself. These disks allow very fast I/O and compression provides
+good amounts of memory savings. Some of the usecases include /tmp storage,
+use as swap disks, various caches under /var and maybe many more :)
+Statistics for individual zram devices are exported through sysfs nodes at
+/sys/block/zram<id>/
+* Usage
+Following shows a typical sequence of steps for using zram.
+1) Load Module:
+        modprobe zram num_devices=4
+        This creates 4 devices: /dev/zram{0,1,2,3}
+        (num_devices parameter is optional. Default: 1)
+2) Set Disksize
+        Set disk size by writing the value to sysfs node 'disksize'.
+        The value can be either in bytes or you can use mem suffixes.
+        Examples:
+            # Initialize /dev/zram0 with 50MB disksize
+            echo $((50*1024*1024)) > /sys/block/zram0/disksize
+            # Using mem suffixes
+            echo 256K > /sys/block/zram0/disksize
+            echo 512M > /sys/block/zram0/disksize
+            echo 1G > /sys/block/zram0/disksize
+3) Activate:
+        mkswap /dev/zram0
+        swapon /dev/zram0
+        mkfs.ext4 /dev/zram1
+        mount /dev/zram1 /tmp
+4) Stats:
+        Per-device statistics are exported as various nodes under
+        /sys/block/zram<id>/
+                disksize
+                num_reads
+                num_writes
+                invalid_io
+                notify_free
+                discard
+                zero_pages
+                orig_data_size
+                compr_data_size
+                mem_used_total
+5) Deactivate:
+        swapoff /dev/zram0
+        umount /dev/zram1
+6) Reset:
+        Write any positive value to 'reset' sysfs node
+        echo 1 > /sys/block/zram0/reset
+        echo 1 > /sys/block/zram1/reset
+        This frees all the memory allocated for the given device and
+        resets the disksize to zero. You must set the disksize again
+        before reusing the device.
+Nitin Gupta
+ngupta@vflare.org
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index 638bf17ff869..821de56d1580 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -24,7 +24,6 @@ CONTENTS:
  2.1 Basic Usage
  2.2 Attaching processes
  2.3 Mounting hierarchies by name
-  2.4 Notification API
 3. Kernel API
  3.1 Overview
  3.2 Synchronization
@@ -472,25 +471,6 @@ you give a subsystem a name.
 The name of the subsystem appears as part of the hierarchy description
 in /proc/mounts and /proc/<pid>/cgroups.
-2.4 Notification API
--------------------
-There is mechanism which allows to get notifications about changing
-status of a cgroup.
-To register a new notification handler you need to:
- - create a file descriptor for event notification using eventfd(2);
- - open a control file to be monitored (e.g. memory.usage_in_bytes);
- - write "<event_fd> <control_fd> <args>" to cgroup.event_control.
-   Interpretation of args is defined by control file implementation;
-eventfd will be woken up by control file implementation or when the
-cgroup is removed.
-To unregister a notification handler just close eventfd.
-NOTE: Support of notifications should be implemented for the control
-file. See documentation for the subsystem.
 3. Kernel API
 =============
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index e2bc132608fd..2622115276aa 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -577,7 +577,7 @@ Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
 per-node page counts including "hierarchical_<counter>" which sums up all
 hierarchical children's values in addition to the memcg's own value.
-The ouput format of memory.numa_stat is:
+The output format of memory.numa_stat is:
 total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
 file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
@@ -670,7 +670,7 @@ page tables.
 8.1 Interface
-This feature is disabled by default. It can be enabledi (and disabled again) by
+This feature is disabled by default. It can be enabled (and disabled again) by
 writing to memory.move_charge_at_immigrate of the destination cgroup.
 If you want to enable it:
diff --git a/Documentation/cgroups/net_cls.txt b/Documentation/cgroups/net_cls.txt
index 9face6bb578a..ec182346dea2 100644
--- a/Documentation/cgroups/net_cls.txt
+++ b/Documentation/cgroups/net_cls.txt
@@ -6,6 +6,8 @@ tag network packets with a class identifier (classid).
 The Traffic Controller (tc) can be used to assign
 different priorities to packets from different cgroups.
+Also, Netfilter (iptables) can use this tag to perform
+actions on such packets.
 Creating a net_cls cgroups instance creates a net_cls.classid file.
 This net_cls.classid value is initialized to 0.
@@ -32,3 +34,6 @@ tc class add dev eth0 parent 10: classid 10:1 htb rate 40mbit
 - creating traffic class 10:1
 tc filter add dev eth0 parent 10: protocol ip prio 10 handle 1: cgroup
+configuring iptables, basic example:
+iptables -A OUTPUT -m cgroup ! --cgroup 0x100001 -j DROP
diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt
index c4d99ed0b418..52e1da16a309 100644
--- a/Documentation/cgroups/resource_counter.txt
+++ b/Documentation/cgroups/resource_counter.txt
@@ -97,8 +97,8 @@ to work with it.
                (struct res_counter *rc, struct res_counter *top,
                 unsinged long val)
-        Almost same as res_cunter_uncharge() but propagation of uncharge
+        Almost same as res_counter_uncharge() but propagation of uncharge
-        stops when rc == top. This is useful when kill a res_coutner in
+        stops when rc == top. This is useful when kill a res_counter in
        child cgroup.
 2.1 Other accounting routines
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 3aeb5c440442..699ef2a323b1 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -77,6 +77,11 @@ the operations defined in clk.h:
                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_and_parent)(struct clk_hw *hw,
+                                            unsigned long rate,
+                                            unsigned long parent_rate, u8 index);
+                unsigned long   (*recalc_accuracy)(struct clk_hw *hw,
+                                                   unsigned long parent_accuracy);
                void            (*init)(struct clk_hw *hw);
        };
@@ -202,6 +207,8 @@ optional or must be evaluated on a case-by-case basis.
 .set_parent     |      |             | n             | y           | n    |
 .get_parent     |      |             | n             | y           | n    |
                |      |             |               |             |      |
+.recalc_accuracy|      |             |               |             |      |
+                |      |             |               |             |      |
 .init           |      |             |               |             |      |
                -----------------------------------------------------------
 [1] either one of round_rate or determine_rate is required.
diff --git a/Documentation/cpu-freq/boost.txt b/Documentation/cpu-freq/boost.txt
index 9b4edfcf486f..dd62e1334f0a 100644
--- a/Documentation/cpu-freq/boost.txt
+++ b/Documentation/cpu-freq/boost.txt
@@ -17,8 +17,8 @@ Introduction
 Some CPUs support a functionality to raise the operating frequency of
 some cores in a multi-core package if certain conditions apply, mostly
 if the whole chip is not fully utilized and below it's intended thermal
-budget. This is done without operating system control by a combination
+budget. The decision about boost disable/enable is made either at hardware
-of hardware and firmware.
+(e.g. x86) or software (e.g ARM).
 On Intel CPUs this is called "Turbo Boost", AMD calls it "Turbo-Core",
 in technical documentation "Core performance boost". In Linux we use
 the term "boost" for convenience.
@@ -48,24 +48,24 @@ be desirable:
 User controlled switch
 ----------------------
-To allow the user to toggle the boosting functionality, the acpi-cpufreq
+To allow the user to toggle the boosting functionality, the cpufreq core
-driver exports a sysfs knob to disable it. There is a file:
+driver exports a sysfs knob to enable or disable it. There is a file:
 /sys/devices/system/cpu/cpufreq/boost
 which can either read "0" (boosting disabled) or "1" (boosting enabled).
-Reading the file is always supported, even if the processor does not
+The file is exported only when cpufreq driver supports boosting.
-support boosting. In this case the file will be read-only and always
+Explicitly changing the permissions and writing to that file anyway will
-reads as "0". Explicitly changing the permissions and writing to that
+return EINVAL.
-file anyway will return EINVAL.
 On supported CPUs one can write either a "0" or a "1" into this file.
 This will either disable the boost functionality on all cores in the
-whole system (0) or will allow the hardware to boost at will (1).
+whole system (0) or will allow the software or hardware to boost at will
+(1).
 Writing a "1" does not explicitly boost the system, but just allows the
-CPU (and the firmware) to boost at their discretion. Some implementations
+CPU to boost at their discretion. Some implementations take external
-take external factors like the chip's temperature into account, so
+factors like the chip's temperature into account, so boosting once does
-boosting once does not necessarily mean that it will occur every time
+not necessarily mean that it will occur every time even using the exact
-even using the exact same software setup.
+same software setup.
 AMD legacy cpb switch
diff --git a/Documentation/cpu-freq/intel-pstate.txt b/Documentation/cpu-freq/intel-pstate.txt
new file mode 100644
index 000000000000..e742d21dbd96
--- /dev/null
+++ b/Documentation/cpu-freq/intel-pstate.txt
@@ -0,0 +1,40 @@
+Intel P-state driver
+--------------------
+This driver implements a scaling driver with an internal governor for
+Intel Core processors.  The driver follows the same model as the
+Transmeta scaling driver (longrun.c) and implements the setpolicy()
+instead of target().  Scaling drivers that implement setpolicy() are
+assumed to implement internal governors by the cpufreq core. All the
+logic for selecting the current P state is contained within the
+driver; no external governor is used by the cpufreq core.
+Intel SandyBridge+ processors are supported.
+New sysfs files for controlling P state selection have been added to
+/sys/devices/system/cpu/intel_pstate/
+      max_perf_pct: limits the maximum P state that will be requested by
+      the driver stated as a percentage of the available performance.
+      min_perf_pct: limits the minimum P state that will be  requested by
+      the driver stated as a percentage of the available performance.
+      no_turbo: limits the driver to selecting P states below the turbo
+      frequency range.
+For contemporary Intel processors, the frequency is controlled by the
+processor itself and the P-states exposed to software are related to
+performance levels.  The idea that frequency can be set to a single
+frequency is fiction for Intel Core processors. Even if the scaling
+driver selects a single P state the actual frequency the processor
+will run at is selected by the processor itself.
+New debugfs files have also been added to /sys/kernel/debug/pstate_snb/
+      deadband
+      d_gain_pct
+      i_gain_pct
+      p_gain_pct
+      sample_rate_ms
+      setpoint
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 8cb9938cc47e..be675d2d15a7 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -285,7 +285,7 @@ A: This is what you would need in your kernel code to receive notifications.
                return NOTIFY_OK;
        }
-        static struct notifier_block foobar_cpu_notifer =
+        static struct notifier_block foobar_cpu_notifier =
        {
           .notifier_call = foobar_cpu_callback,
        };
diff --git a/Documentation/debugging-via-ohci1394.txt b/Documentation/debugging-via-ohci1394.txt
index 611f5a5499b1..fa0151a712f9 100644
--- a/Documentation/debugging-via-ohci1394.txt
+++ b/Documentation/debugging-via-ohci1394.txt
@@ -22,10 +22,12 @@ locations such as buffers like the printk buffer or the process table.
 Retrieving a full system memory dump is also possible over the FireWire,
 using data transfer rates in the order of 10MB/s or more.
-Memory access is currently limited to the low 4G of physical address
+With most FireWire controllers, memory access is limited to the low 4 GB
-space which can be a problem on IA64 machines where memory is located
+of physical address space.  This can be a problem on IA64 machines where
-mostly above that limit, but it is rarely a problem on more common
+memory is located mostly above that limit, but it is rarely a problem on
-hardware such as hardware based on x86, x86-64 and PowerPC.
+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.
 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
@@ -36,17 +38,11 @@ available (notebooks) or too slow for extensive debug information (like ACPI).
 Drivers
 -------
-The ohci1394 driver in drivers/ieee1394 initializes the OHCI-1394 controllers
+The firewire-ohci driver in drivers/firewire uses filtered physical
-to a working state and enables physical DMA by default for all remote nodes.
-This can be turned off by ohci1394's module parameter phys_dma=0.
-The alternative firewire-ohci driver in drivers/firewire uses filtered physical
 DMA by default, which is more secure but not suitable for remote debugging.
-Compile the driver with CONFIG_FIREWIRE_OHCI_REMOTE_DMA (Kernel hacking menu:
+Pass the remote_dma=1 parameter to the driver to get unfiltered physical DMA.
-Remote debugging over FireWire with firewire-ohci) to get unfiltered physical
-DMA.
-Because ohci1394 and firewire-ohci depend on the PCI enumeration to be
+Because the firewire-ohci driver depends on the PCI enumeration to be
 completed, an initialization routine which runs pretty early has been
 implemented for x86.  This routine runs long before console_init() can be
 called, i.e. before the printk buffer appears on the console.
@@ -64,7 +60,7 @@ be used to view the printk buffer of a remote machine, even with live update.
 Bernhard Kaindl enhanced firescope to support accessing 64-bit machines
 from 32-bit firescope and vice versa:
- http://halobates.de/firewire/firescope-0.2.2.tar.bz2
+- http://v3.sk/~lkundrak/firescope/
 and he implemented fast system dump (alpha version - read README.txt):
 - http://halobates.de/firewire/firedump-0.1.tar.bz2
@@ -92,11 +88,11 @@ Step-by-step instructions for using firescope with early OHCI initialization:
 1) Verify that your hardware is supported:
-   Load the ohci1394 or the fw-ohci module and check your kernel logs.
+   Load the firewire-ohci module and check your kernel logs.
   You should see a line similar to
-   ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[18]  MMIO=[fe9ff800-fe9fffff]
+   firewire_ohci 0000:15:00.1: added OHCI v1.0 device as card 2, 4 IR + 4 IT
-   ... Max Packet=[2048]  IR/IT contexts=[4/8]
+   ... contexts, quirks 0x11
   when loading the driver. If you have no supported controller, many PCI,
   CardBus and even some Express cards which are fully compliant to OHCI-1394
@@ -105,6 +101,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.
 2) Establish a working FireWire cable connection:
   Any FireWire cable, as long at it provides electrically and mechanically
@@ -113,20 +112,18 @@ Step-by-step instructions for using firescope with early OHCI initialization:
   If an driver is running on both machines you should see a line like
-   ieee1394: Node added: ID:BUS[0-01:1023]  GUID[0090270001b84bba]
+   firewire_core 0000:15:00.1: created device fw1: GUID 00061b0020105917, S400
   on both machines in the kernel log when the cable is plugged in
   and connects the two machines.
 3) Test physical DMA using firescope:
-   On the debug host,
+   On the debug host, make sure that /dev/fw* is accessible,
-        - load the raw1394 module,
-        - make sure that /dev/raw1394 is accessible,
   then start firescope:
        $ firescope
-        Port 0 (ohci1394) opened, 2 nodes detected
+        Port 0 (/dev/fw1) opened, 2 nodes detected
        FireScope
        ---------
diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt
index df52a849957f..66c2774c0c64 100644
--- a/Documentation/device-mapper/cache-policies.txt
+++ b/Documentation/device-mapper/cache-policies.txt
@@ -40,8 +40,11 @@ on hit count on entry. The policy aims to take different cache miss
 costs into account and to adjust to varying load patterns automatically.
 Message and constructor argument pairs are:
-        'sequential_threshold <#nr_sequential_ios>' and
+        'sequential_threshold <#nr_sequential_ios>'
-        'random_threshold <#nr_random_ios>'.
+        'random_threshold <#nr_random_ios>'
+        'read_promote_adjustment <value>'
+        'write_promote_adjustment <value>'
+        'discard_promote_adjustment <value>'
 The sequential threshold indicates the number of contiguous I/Os
 required before a stream is treated as sequential.  The random threshold
@@ -55,6 +58,15 @@ since spindles tend to have good bandwidth. The io_tracker counts
 contiguous I/Os to try to spot when the io is in one of these sequential
 modes.
+Internally the mq policy maintains a promotion threshold variable.  If
+the hit count of a block not in the cache goes above this threshold it
+gets promoted to the cache.  The read, write and discard promote adjustment
+tunables allow you to tweak the promotion threshold by adding a small
+value based on the io type.  They default to 4, 8 and 1 respectively.
+If you're trying to quickly warm a new cache device you may wish to
+reduce these to encourage promotion.  Remember to switch them back to
+their defaults after the cache fills though.
 cleaner
 -------
diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt
index 719320b5ed3f..e6b72d355151 100644
--- a/Documentation/device-mapper/cache.txt
+++ b/Documentation/device-mapper/cache.txt
@@ -217,36 +217,43 @@ the characteristics of a specific policy, always request it by name.
 Status
 ------
-<#used metadata blocks>/<#total metadata blocks> <#read hits> <#read misses>
+<metadata block size> <#used metadata blocks>/<#total metadata blocks>
-<#write hits> <#write misses> <#demotions> <#promotions> <#blocks in cache>
+<cache block size> <#used cache blocks>/<#total cache blocks>
-<#dirty> <#features> <features>* <#core args> <core args>* <#policy args>
+<#read hits> <#read misses> <#write hits> <#write misses>
-<policy args>*
+<#demotions> <#promotions> <#dirty> <#features> <features>*
+<#core args> <core args>* <policy name> <#policy args> <policy args>*
-#used metadata blocks    : Number of metadata blocks used
-#total metadata blocks   : Total number of metadata blocks
+metadata block size      : Fixed block size for each metadata block in
-#read hits               : Number of times a READ bio has been mapped
+                             sectors
+#used metadata blocks    : Number of metadata blocks used
+#total metadata blocks   : Total number of metadata blocks
+cache block size         : Configurable block size for the cache device
+                             in sectors
+#used cache blocks       : Number of blocks resident in the cache
+#total cache blocks      : Total number of cache blocks
+#read hits               : Number of times a READ bio has been mapped
                             to the cache
-#read misses             : Number of times a READ bio has been mapped
+#read misses             : Number of times a READ bio has been mapped
                             to the origin
-#write hits              : Number of times a WRITE bio has been mapped
+#write hits              : Number of times a WRITE bio has been mapped
                             to the cache
-#write misses            : Number of times a WRITE bio has been
+#write misses            : Number of times a WRITE bio has been
                             mapped to the origin
-#demotions               : Number of times a block has been removed
+#demotions               : Number of times a block has been removed
                             from the cache
-#promotions              : Number of times a block has been moved to
+#promotions              : Number of times a block has been moved to
                             the cache
-#blocks in cache         : Number of blocks resident in the cache
+#dirty                   : Number of blocks in the cache that differ
-#dirty                   : Number of blocks in the cache that differ
                             from the origin
-#feature args            : Number of feature args to follow
+#feature args            : Number of feature args to follow
-feature args             : 'writethrough' (optional)
+feature args             : 'writethrough' (optional)
-#core args               : Number of core arguments (must be even)
+#core args               : Number of core arguments (must be even)
-core args                : Key/value pairs for tuning the core
+core args                : Key/value pairs for tuning the core
                             e.g. migration_threshold
-#policy args             : Number of policy arguments to follow (must be even)
+policy name              : Name of the policy
-policy args              : Key/value pairs
+#policy args             : Number of policy arguments to follow (must be even)
-                             e.g. 'sequential_threshold 1024
+policy args              : Key/value pairs
+                             e.g. sequential_threshold
 Messages
 --------
diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt
index 50c44cf79b0e..8a7a3d46e0da 100644
--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@@ -235,6 +235,8 @@ i) Constructor
      read_only: Don't allow any changes to be made to the pool
                 metadata.
+      error_if_no_space: Error IOs, instead of queueing, if no space.
    Data block size must be between 64KB (128 sectors) and 1GB
    (2097152 sectors) inclusive.
@@ -276,6 +278,11 @@ ii) Status
        contain the string 'Fail'.  The userspace recovery tools
        should then be used.
+    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.
 iii) Messages
    create_thin <dev id>
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 80b72419ffd8..10378cc48374 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -409,6 +409,7 @@ Your cooperation is appreciated.
                193 = /dev/d7s          SPARC 7-segment display
                194 = /dev/zkshim       Zero-Knowledge network shim control
                195 = /dev/elographics/e2201    Elographics touchscreen E271-2201
+                196 = /dev/vfio/vfio    VFIO userspace driver interface
                198 = /dev/sexec        Signed executable interface
                199 = /dev/scanners/cuecat :CueCat barcode scanner
                200 = /dev/net/tun      TAP/TUN network device
diff --git a/Documentation/devicetree/bindings/ABI.txt b/Documentation/devicetree/bindings/ABI.txt
new file mode 100644
index 000000000000..d25f8d379680
--- /dev/null
+++ b/Documentation/devicetree/bindings/ABI.txt
@@ -0,0 +1,39 @@
+  Devicetree (DT) ABI
+I. Regarding stable bindings/ABI, we quote from the 2013 ARM mini-summit
+   summary document:
+     "That still leaves the question of, what does a stable binding look
+     like?  Certainly a stable binding means that a newer kernel will not
+     break on an older device tree, but that doesn't mean the binding is
+     frozen for all time. Grant said there are ways to change bindings that
+     don't result in breakage. For instance, if a new property is added,
+     then default to the previous behaviour if it is missing. If a binding
+     truly needs an incompatible change, then change the compatible string
+     at the same time.  The driver can bind against both the old and the
+     new. These guidelines aren't new, but they desperately need to be
+     documented."
+II.  General binding rules
+  1) Maintainers, don't let perfect be the enemy of good.  Don't hold up a
+     binding because it isn't perfect.
+  2) Use specific compatible strings so that if we need to add a feature (DMA)
+     in the future, we can create a new compatible string.  See I.
+  3) Bindings can be augmented, but the driver shouldn't break when given
+     the old binding. ie. add additional properties, but don't change the
+     meaning of an existing property. For drivers, default to the original
+     behaviour when a newly added property is missing.
+  4) Don't submit bindings for staging or unstable.  That will be decided by
+     the devicetree maintainers *after* discussion on the mailinglist.
+III. Notes
+  1) This document is intended as a general familiarization with the process as
+     decided at the 2013 Kernel Summit.  When in doubt, the current word of the
+     devicetree maintainers overrules this document.  In that situation, a patch
+     updating this document would be appreciated.
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index 5fac246a9530..3509707f9320 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -14,6 +14,9 @@ Required nodes:
 - core-module: the root node to the Integrator platforms must have
  a core-module with regs and the compatible string
  "arm,core-module-integrator"
+- external-bus-interface: the root node to the Integrator platforms
+  must have an external bus interface with regs and the
+  compatible-string "arm,external-bus-interface"
  Required properties for the core module:
  - regs: the location and size of the core module registers, one
@@ -48,6 +51,11 @@ Required nodes:
                reg = <0x10000000 0x200>;
        };
+        ebi@12000000 {
+                compatible = "arm,external-bus-interface";
+                reg = <0x12000000 0x100>;
+        };
        syscon {
                compatible = "arm,integrator-ap-syscon";
                reg = <0x11000000 0x100>;
diff --git a/Documentation/devicetree/bindings/arm/atmel-aic.txt b/Documentation/devicetree/bindings/arm/atmel-aic.txt
index ad031211b5b8..2742e9cfd6b1 100644
--- a/Documentation/devicetree/bindings/arm/atmel-aic.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-aic.txt
@@ -2,6 +2,7 @@
 Required properties:
 - compatible: Should be "atmel,<chip>-aic"
+  <chip> can be "at91rm9200" or "sama5d3"
 - interrupt-controller: Identifies the node as an interrupt controller.
 - interrupt-parent: For single AIC system, it is an empty property.
 - #interrupt-cells: The number of cells to define the interrupts. It should be 3.
diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.txt b/Documentation/devicetree/bindings/arm/atmel-at91.txt
index 1196290082d1..16f60b41c147 100644
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -20,6 +20,10 @@ TC/TCLIB Timer required properties:
 - interrupts: Should contain all interrupts for the TC block
  Note that you can specify several interrupt cells if the TC
  block has one interrupt per channel.
+- clock-names: tuple listing input clock names.
+        Required elements: "t0_clk"
+        Optional elements: "t1_clk", "t2_clk"
+- clocks: phandles to input clocks.
 Examples:
@@ -28,6 +32,8 @@ One interrupt per TC block:
                compatible = "atmel,at91rm9200-tcb";
                reg = <0xfff7c000 0x100>;
                interrupts = <18 4>;
+                clocks = <&tcb0_clk>;
+                clock-names = "t0_clk";
        };
 One interrupt per TC channel in a TC block:
@@ -35,6 +41,8 @@ One interrupt per TC channel in a TC block:
                compatible = "atmel,at91rm9200-tcb";
                reg = <0xfffdc000 0x100>;
                interrupts = <26 4 27 4 28 4>;
+                clocks = <&tcb1_clk>;
+                clock-names = "t0_clk";
        };
 RSTC Reset Controller required properties:
@@ -50,7 +58,8 @@ Example:
        };
 RAMC SDRAM/DDR Controller required properties:
- compatible: Should be "atmel,at91sam9260-sdramc",
+- compatible: Should be "atmel,at91rm9200-sdramc",
+                        "atmel,at91sam9260-sdramc",
                        "atmel,at91sam9g45-ddramc",
 - reg: Should contain registers location and length
  For at91sam9263 and at91sam9g45 you must specify 2 entries.
diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
index 17d88b233d1b..39adf54b4388 100644
--- a/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/kona-timer.txt
@@ -8,13 +8,18 @@ Required properties:
 - DEPRECATED: compatible : "bcm,kona-timer"
 - reg : Register range for the timer
 - interrupts : interrupt for the timer
+- clocks: phandle + clock specifier pair of the external clock
 - clock-frequency: frequency that the clock operates
+Only one of clocks or clock-frequency should be specified.
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
 Example:
        timer@35006000 {
                compatible = "brcm,kona-timer";
                reg = <0x35006000 0x1000>;
                interrupts = <0x0 7 0x4>;
-                clock-frequency = <32768>;
+                clocks = <&hub_timer_clk>;
        };
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
deleted file mode 100644
index 3545ea704b50..000000000000
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ /dev/null
@@ -1,46 +0,0 @@
-* Texas Instruments Davinci NAND
-This file provides information, what the device node for the
-davinci nand interface contain.
-Required properties:
- compatible: "ti,davinci-nand";
- reg : contain 2 offset/length values:
-        - offset and length for the access window
-        - offset and length for accessing the aemif control registers
- ti,davinci-chipselect: Indicates on the davinci_nand driver which
-                         chipselect is used for accessing the nand.
-Recommended properties :
- ti,davinci-mask-ale: mask for ale
- ti,davinci-mask-cle: mask for cle
- ti,davinci-mask-chipsel: mask for chipselect
- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
-                - "none"
-                - "soft"
-                - "hw"
- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
- ti,davinci-nand-buswidth: buswidth 8 or 16
- ti,davinci-nand-use-bbt: use flash based bad block table support.
-nand device bindings may contain additional sub-nodes describing
-partitions of the address space. See partition.txt for more detail.
-Example(da850 EVM ):
-nand_cs3@62000000 {
-        compatible = "ti,davinci-nand";
-        reg = <0x62000000 0x807ff
-                0x68000000 0x8000>;
-        ti,davinci-chipselect = <1>;
-        ti,davinci-mask-ale = <0>;
-        ti,davinci-mask-cle = <0>;
-        ti,davinci-mask-chipsel = <0>;
-        ti,davinci-ecc-mode = "hw";
-        ti,davinci-ecc-bits = <4>;
-        ti,davinci-nand-use-bbt;
-        partition@180000 {
-                label = "ubifs";
-                reg = <0x180000 0x7e80000>;
-        };
-};
diff --git a/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
new file mode 100644
index 000000000000..780d0392a66b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/firmware/tlm,trusted-foundations.txt
@@ -0,0 +1,20 @@
+Trusted Foundations
+-------------------
+Boards that use the Trusted Foundations secure monitor can signal its
+presence by declaring a node compatible with "tlm,trusted-foundations"
+under the /firmware/ node
+Required properties:
+- compatible: "tlm,trusted-foundations"
+- tlm,version-major: major version number of Trusted Foundations firmware
+- tlm,version-minor: minor version number of Trusted Foundations firmware
+Example:
+        firmware {
+                trusted-foundations {
+                        compatible = "tlm,trusted-foundations";
+                        tlm,version-major = <2>;
+                        tlm,version-minor = <8>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index 3dfb0c0384f5..bae0d87a38b2 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -11,6 +11,7 @@ have PPIs or SGIs.
 Main node required properties:
 - compatible : should be one of:
+        "arm,gic-400"
        "arm,cortex-a15-gic"
        "arm,cortex-a9-gic"
        "arm,cortex-a7-gic"
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
new file mode 100644
index 000000000000..8c7a4653508d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -0,0 +1,32 @@
+Hisilicon Platforms Device Tree Bindings
+----------------------------------------------------
+Hi4511 Board
+Required root node properties:
+        - compatible = "hisilicon,hi3620-hi4511";
+Hisilicon system controller
+Required properties:
+- compatible : "hisilicon,sysctrl"
+- reg : Register address and size
+Optional properties:
+- smp-offset : offset in sysctrl for notifying slave cpu booting
+                cpu 1, reg;
+                cpu 2, reg + 0x4;
+                cpu 3, reg + 0x8;
+                If reg value is not zero, cpun exit wfi and go
+- resume-offset : offset in sysctrl for notifying cpu0 when resume
+- reboot-offset : offset in sysctrl for system reboot
+Example:
+        /* for Hi3620 */
+        sysctrl: system-controller@fc802000 {
+                compatible = "hisilicon,sysctrl";
+                reg = <0xfc802000 0x1000>;
+                smp-offset = <0x31c>;
+                resume-offset = <0x308>;
+                reboot-offset = <0x4>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index c0c7626fd0ff..b513cb8196fe 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -7,20 +7,21 @@ The ARM L2 cache representation in the device tree should be done as follows:
 Required properties:
 - compatible : should be one of:
-        "arm,pl310-cache"
+  "arm,pl310-cache"
-        "arm,l220-cache"
+  "arm,l220-cache"
-        "arm,l210-cache"
+  "arm,l210-cache"
-        "marvell,aurora-system-cache": Marvell Controller designed to be
+  "bcm,bcm11351-a2-pl310-cache": DEPRECATED by "brcm,bcm11351-a2-pl310-cache"
+  "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
+     offset needs to be added to the address before passing down to the L2
+     cache controller
+  "marvell,aurora-system-cache": Marvell Controller designed to be
     compatible with the ARM one, with system cache mode (meaning
     maintenance operations on L1 are broadcasted to the L2 and L2
     performs the same operation).
-        "marvell,"aurora-outer-cache: Marvell Controller designed to be
+  "marvell,aurora-outer-cache": Marvell Controller designed to be
-         compatible with the ARM one with outer cache mode.
+     compatible with the ARM one with outer cache mode.
-        "brcm,bcm11351-a2-pl310-cache": For Broadcom bcm11351 chipset where an
+  "marvell,tauros3-cache": Marvell Tauros3 cache controller, compatible
-        offset needs to be added to the address before passing down to the L2
+     with arm,pl310-cache controller.
-        cache controller
-        "bcm,bcm11351-a2-pl310-cache": DEPRECATED by
-                                       "brcm,bcm11351-a2-pl310-cache"
 - cache-unified : Specifies the cache is a unified cache.
 - cache-level : Should be set to 2 for a level 2 cache.
 - reg : Physical base address and size of cache controller's memory mapped
diff --git a/Documentation/devicetree/bindings/arm/marvell,berlin.txt b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
new file mode 100644
index 000000000000..737afa5f8148
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -0,0 +1,24 @@
+Marvell Berlin SoC Family Device Tree Bindings
+---------------------------------------------------------------
+Boards with a SoC of the Marvell Berlin family, e.g. Armada 1500
+shall have the following properties:
+* Required root node properties:
+compatible: must contain "marvell,berlin"
+In addition, the above compatible shall be extended with the specific
+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,berlin3"      for Marvell Armada ? (BG3, 88DE????)
+* Example:
+/ {
+        model = "Sony NSZ-GS7";
+        compatible = "sony,nsz-gs7", "marvell,berlin2", "marvell,berlin";
+        ...
+}
diff --git a/Documentation/devicetree/bindings/arm/moxart.txt b/Documentation/devicetree/bindings/arm/moxart.txt
new file mode 100644
index 000000000000..11087edb0658
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/moxart.txt
@@ -0,0 +1,12 @@
+MOXA ART device tree bindings
+Boards with the MOXA ART SoC shall have the following properties:
+Required root node property:
+compatible = "moxa,moxart";
+Boards:
+- UC-7112-LX: embedded computer
+  compatible = "moxa,moxart-uc-7112-lx", "moxa,moxart"
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 808c1543b0f8..34dc40cffdfd 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -31,6 +31,59 @@ spinlock@1 {
    ti,hwmods = "spinlock";
 };
+SoC Type (optional):
+- General Purpose devices
+  compatible = "ti,gp"
+- High Security devices
+  compatible = "ti,hs"
+SoC Families:
+- OMAP2 generic - defaults to OMAP2420
+  compatible = "ti,omap2"
+- OMAP3 generic - defaults to OMAP3430
+  compatible = "ti,omap3"
+- OMAP4 generic - defaults to OMAP4430
+  compatible = "ti,omap4"
+- OMAP5 generic - defaults to OMAP5430
+  compatible = "ti,omap5"
+- DRA7 generic - defaults to DRA742
+  compatible = "ti,dra7"
+- AM43x generic - defaults to AM4372
+  compatible = "ti,am43"
+SoCs:
+- OMAP2420
+  compatible = "ti,omap2420", "ti,omap2"
+- OMAP2430
+  compatible = "ti,omap2430", "ti,omap2"
+- OMAP3430
+  compatible = "ti,omap3430", "ti,omap3"
+- AM3517
+  compatible = "ti,am3517", "ti,omap3"
+- OMAP3630
+  compatible = "ti,omap36xx", "ti,omap3"
+- AM33xx
+  compatible = "ti,am33xx", "ti,omap3"
+- OMAP4430
+  compatible = "ti,omap4430", "ti,omap4"
+- OMAP4460
+  compatible = "ti,omap4460", "ti,omap4"
+- OMAP5430
+  compatible = "ti,omap5430", "ti,omap5"
+- OMAP5432
+  compatible = "ti,omap5432", "ti,omap5"
+- DRA742
+  compatible = "ti,dra7xx", "ti,dra7"
+- AM4372
+  compatible = "ti,am4372", "ti,am43"
 Boards:
diff --git a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
index 5039c0a12f55..0ab3251a6ec2 100644
--- a/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/sysreg.txt
@@ -1,7 +1,12 @@
 SAMSUNG S5P/Exynos SoC series System Registers (SYSREG)
 Properties:
- - name : should be 'sysreg';
 - compatible : should contain "samsung,<chip name>-sysreg", "syscon";
   For Exynos4 SoC series it should be "samsung,exynos4-sysreg", "syscon";
 - reg : offset and length of the register set.
+Example:
+        syscon@10010000 {
+                compatible = "samsung,exynos4-sysreg", "syscon";
+                reg = <0x10010000 0x400>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/tegra.txt b/Documentation/devicetree/bindings/arm/tegra.txt
index ed9c85334436..558ed4b4ef39 100644
--- a/Documentation/devicetree/bindings/arm/tegra.txt
+++ b/Documentation/devicetree/bindings/arm/tegra.txt
@@ -32,3 +32,8 @@ board-specific compatible values:
  nvidia,whistler
  toradex,colibri_t20-512
  toradex,iris
+Trusted Foundations
+-------------------------------------------
+Tegra supports the Trusted Foundation secure monitor. See the
+"tlm,trusted-foundations" binding's documentation for more details.
diff --git a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
index 1608a54e90e1..68ac65f82a1c 100644
--- a/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/tegra/nvidia,tegra20-pmc.txt
@@ -9,6 +9,7 @@ Required properties:
 - compatible : Should contain "nvidia,tegra<chip>-pmc".
 - reg : Offset and length of the register set for the device
 - 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:
  "pclk" (The Tegra clock of that name),
  "clk32k_in" (The 32KHz clock input to Tegra).
diff --git a/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt b/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
index 9989eda755d9..c9cf605bb995 100644
--- a/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
+++ b/Documentation/devicetree/bindings/arm/versatile-fpga-irq.txt
@@ -29,3 +29,8 @@ pic: pic@14000000 {
        clear-mask = <0xffffffff>;
        valid-mask = <0x003fffff>;
 };
+Optional properties:
+- interrupts: if the FPGA IRQ controller is cascaded, i.e. if its IRQ
+  output is simply connected to the input of another IRQ controller,
+  then the parent IRQ shall be specified in this property.
diff --git a/Documentation/devicetree/bindings/ata/marvell.txt b/Documentation/devicetree/bindings/ata/marvell.txt
index b5cdd20cde9c..1c8351604d38 100644
--- a/Documentation/devicetree/bindings/ata/marvell.txt
+++ b/Documentation/devicetree/bindings/ata/marvell.txt
@@ -1,7 +1,7 @@
 * Marvell Orion SATA
 Required Properties:
- compatibility : "marvell,orion-sata"
+- compatibility : "marvell,orion-sata" or "marvell,armada-370-sata"
 - reg           : Address range of controller
 - interrupts    : Interrupt controller is using
 - nr-ports      : Number of SATA ports in use.
diff --git a/Documentation/devicetree/bindings/ata/sata_rcar.txt b/Documentation/devicetree/bindings/ata/sata_rcar.txt
new file mode 100644
index 000000000000..1e6111333fa8
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/sata_rcar.txt
@@ -0,0 +1,18 @@
+* Renesas R-Car SATA
+Required properties:
+- compatible            : should contain one of the following:
+                          - "renesas,sata-r8a7779" for R-Car H1
+                          - "renesas,sata-r8a7790" for R-Car H2
+                          - "renesas,sata-r8a7791" for R-Car M2
+- reg                   : address and length of the SATA registers;
+- interrupts            : must consist of one interrupt specifier.
+Example:
+sata: sata@fc600000 {
+        compatible = "renesas,sata-r8a7779";
+        reg = <0xfc600000 0x2000>;
+        interrupt-parent = <&gic>;
+        interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/clock/at91-clock.txt b/Documentation/devicetree/bindings/clock/at91-clock.txt
new file mode 100644
index 000000000000..cd5e23912888
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/at91-clock.txt
@@ -0,0 +1,339 @@
+Device Tree Clock bindings for arch-at91
+This binding uses the common clock binding[1].
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+Required properties:
+- compatible : shall be one of the following:
+        "atmel,at91rm9200-pmc" or
+        "atmel,at91sam9g45-pmc" or
+        "atmel,at91sam9n12-pmc" or
+        "atmel,at91sam9x5-pmc" or
+        "atmel,sama5d3-pmc":
+                at91 PMC (Power Management Controller)
+                All at91 specific clocks (clocks defined below) must be child
+                node of the PMC node.
+        "atmel,at91rm9200-clk-main":
+                at91 main oscillator
+        "atmel,at91rm9200-clk-master" or
+        "atmel,at91sam9x5-clk-master":
+                at91 master clock
+        "atmel,at91sam9x5-clk-peripheral" or
+        "atmel,at91rm9200-clk-peripheral":
+                at91 peripheral clocks
+        "atmel,at91rm9200-clk-pll" or
+        "atmel,at91sam9g45-clk-pll" or
+        "atmel,at91sam9g20-clk-pllb" or
+        "atmel,sama5d3-clk-pll":
+                at91 pll clocks
+        "atmel,at91sam9x5-clk-plldiv":
+                at91 plla divisor
+        "atmel,at91rm9200-clk-programmable" or
+        "atmel,at91sam9g45-clk-programmable" or
+        "atmel,at91sam9x5-clk-programmable":
+                at91 programmable clocks
+        "atmel,at91sam9x5-clk-smd":
+                at91 SMD (Soft Modem) clock
+        "atmel,at91rm9200-clk-system":
+                at91 system clocks
+        "atmel,at91rm9200-clk-usb" or
+        "atmel,at91sam9x5-clk-usb" or
+        "atmel,at91sam9n12-clk-usb":
+                at91 usb clock
+        "atmel,at91sam9x5-clk-utmi":
+                at91 utmi clock
+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).
+- #address-cells : shall be 1 (reg is used to encode clk id).
+- interrupts : shall be set to PMC interrupt line.
+- 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.
+        0 (AT91_PMC_MOSCS) -> main oscillator ready
+        1 (AT91_PMC_LOCKA) -> PLL A ready
+        2 (AT91_PMC_LOCKB) -> PLL B ready
+        3 (AT91_PMC_MCKRDY) -> master clock ready
+        6 (AT91_PMC_LOCKU) -> UTMI PLL clock ready
+        8 .. 15 (AT91_PMC_PCKRDY(id)) -> programmable clock ready
+        16 (AT91_PMC_MOSCSELS) -> main oscillator selected
+        17 (AT91_PMC_MOSCRCS) -> RC main oscillator stabilized
+        18 (AT91_PMC_CFDEV) -> clock failure detected
+For example:
+        pmc: pmc@fffffc00 {
+                compatible = "atmel,sama5d3-pmc";
+                interrupts = <1 4 7>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                #size-cells = <0>;
+                #address-cells = <1>;
+                /* put at91 clocks here */
+        };
+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.
+For example:
+        main: mainck {
+                compatible = "atmel,at91rm9200-clk-main";
+                interrupt-parent = <&pmc>;
+                interrupts = <0>;
+                #clock-cells = <0>;
+                clocks = <&ck32k>;
+                clock-frequency = <18432000>;
+        };
+Required properties for master clock:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "<3>".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the master clock sources (see atmel datasheet) phandles.
+        e.g. "<&ck32k>, <&main>, <&plla>, <&pllb>".
+- atmel,clk-output-range : minimum and maximum clock frequency (two u32
+                           fields).
+           e.g. output = <0 133000000>; <=> 0 to 133MHz.
+- atmel,clk-divisors : master clock divisors table (four u32 fields).
+                0 <=> reserved value.
+                e.g. divisors = <1 2 4 6>;
+- atmel,master-clk-have-div3-pres : some SoC use the reserved value 7 in the
+                                    PRES field as CLOCK_DIV3 (e.g sam9x5).
+For example:
+        mck: mck {
+                compatible = "atmel,at91rm9200-clk-master";
+                interrupt-parent = <&pmc>;
+                interrupts = <3>;
+                #clock-cells = <0>;
+                atmel,clk-output-range = <0 133000000>;
+                atmel,clk-divisors = <1 2 4 0>;
+        };
+Required properties for peripheral clocks:
+- #size-cells : shall be 0 (reg is used to encode clk id).
+- #address-cells : shall be 1 (reg is used to encode clk id).
+- clocks : shall be the master clock phandle.
+        e.g. clocks = <&mck>;
+- name: device tree node describing a specific system clock.
+        * #clock-cells : from common clock binding; shall be set to 0.
+        * reg: peripheral id. See Atmel's datasheets to get a full
+          list of peripheral ids.
+        * atmel,clk-output-range : minimum and maximum clock frequency
+          (two u32 fields). Only valid on at91sam9x5-clk-peripheral
+          compatible IPs.
+For example:
+        periph: periphck {
+                compatible = "atmel,at91sam9x5-clk-peripheral";
+                #size-cells = <0>;
+                #address-cells = <1>;
+                clocks = <&mck>;
+                ssc0_clk {
+                        #clock-cells = <0>;
+                        reg = <2>;
+                        atmel,clk-output-range = <0 133000000>;
+                };
+                usart0_clk {
+                        #clock-cells = <0>;
+                        reg = <3>;
+                        atmel,clk-output-range = <0 66000000>;
+                };
+        };
+Required properties for pll clocks:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "<1>".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the main clock phandle.
+- reg : pll id.
+        0 -> PLL A
+        1 -> PLL B
+- atmel,clk-input-range : minimum and maximum source clock frequency (two u32
+                          fields).
+          e.g. input = <1 32000000>; <=> 1 to 32MHz.
+- #atmel,pll-clk-output-range-cells : number of cells reserved for pll output
+                                      range description. Sould be set to 2, 3
+                                      or 4.
+        * 1st and 2nd cells represent the frequency range (min-max).
+        * 3rd cell is optional and represents the OUT field value for the given
+          range.
+        * 4th cell is optional and represents the ICPLL field (PLLICPR
+          register)
+- atmel,pll-clk-output-ranges : pll output frequency ranges + optional parameter
+                                depending on #atmel,pll-output-range-cells
+                                property value.
+For example:
+        plla: pllack {
+                compatible = "atmel,at91sam9g45-clk-pll";
+                interrupt-parent = <&pmc>;
+                interrupts = <1>;
+                #clock-cells = <0>;
+                clocks = <&main>;
+                reg = <0>;
+                atmel,clk-input-range = <2000000 32000000>;
+                #atmel,pll-clk-output-range-cells = <4>;
+                atmel,pll-clk-output-ranges = <74500000 800000000 0 0
+                                               69500000 750000000 1 0
+                                               64500000 700000000 2 0
+                                               59500000 650000000 3 0
+                                               54500000 600000000 0 1
+                                               49500000 550000000 1 1
+                                               44500000 500000000 2 1
+                                               40000000 450000000 3 1>;
+        };
+Required properties for plldiv clocks (plldiv = pll / 2):
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the plla clock phandle.
+The pll divisor is equal to 2 and cannot be changed.
+For example:
+        plladiv: plladivck {
+                compatible = "atmel,at91sam9x5-clk-plldiv";
+                #clock-cells = <0>;
+                clocks = <&plla>;
+        };
+Required properties for programmable clocks:
+- interrupt-parent : must reference the PMC node.
+- #size-cells : shall be 0 (reg is used to encode clk id).
+- #address-cells : shall be 1 (reg is used to encode clk id).
+- clocks : shall be the programmable clock source phandles.
+        e.g. clocks = <&clk32k>, <&main>, <&plla>, <&pllb>;
+- name: device tree node describing a specific prog clock.
+        * #clock-cells : from common clock binding; shall be set to 0.
+        * reg : programmable clock id (register offset from  PCKx
+                         register).
+        * interrupts : shall be set to "<(8 + id)>".
+For example:
+        prog: progck {
+                compatible = "atmel,at91sam9g45-clk-programmable";
+                #size-cells = <0>;
+                #address-cells = <1>;
+                interrupt-parent = <&pmc>;
+                clocks = <&clk32k>, <&main>, <&plladiv>, <&utmi>, <&mck>;
+                prog0 {
+                        #clock-cells = <0>;
+                        reg = <0>;
+                        interrupts = <8>;
+                };
+                prog1 {
+                        #clock-cells = <0>;
+                        reg = <1>;
+                        interrupts = <9>;
+                };
+        };
+Required properties for smd clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the smd clock source phandles.
+        e.g. clocks = <&plladiv>, <&utmi>;
+For example:
+        smd: smdck {
+                compatible = "atmel,at91sam9x5-clk-smd";
+                #clock-cells = <0>;
+                clocks = <&plladiv>, <&utmi>;
+        };
+Required properties for system clocks:
+- #size-cells : shall be 0 (reg is used to encode clk id).
+- #address-cells : shall be 1 (reg is used to encode clk id).
+- name: device tree node describing a specific system clock.
+        * #clock-cells : from common clock binding; shall be set to 0.
+        * reg: system clock id (bit position in SCER/SCDR/SCSR registers).
+              See Atmel's datasheet to get a full list of system clock ids.
+For example:
+        system: systemck {
+                compatible = "atmel,at91rm9200-clk-system";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                ddrck {
+                        #clock-cells = <0>;
+                        reg = <2>;
+                        clocks = <&mck>;
+                };
+                uhpck {
+                        #clock-cells = <0>;
+                        reg = <6>;
+                        clocks = <&usb>;
+                };
+                udpck {
+                        #clock-cells = <0>;
+                        reg = <7>;
+                        clocks = <&usb>;
+                };
+        };
+Required properties for usb clock:
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the smd clock source phandles.
+        e.g. clocks = <&pllb>;
+- atmel,clk-divisors (only available for "atmel,at91rm9200-clk-usb"):
+        usb clock divisor table.
+        e.g. divisors = <1 2 4 0>;
+For example:
+        usb: usbck {
+                compatible = "atmel,at91sam9x5-clk-usb";
+                #clock-cells = <0>;
+                clocks = <&plladiv>, <&utmi>;
+        };
+        usb: usbck {
+                compatible = "atmel,at91rm9200-clk-usb";
+                #clock-cells = <0>;
+                clocks = <&pllb>;
+                atmel,clk-divisors = <1 2 4 0>;
+        };
+Required properties for utmi clock:
+- interrupt-parent : must reference the PMC node.
+- interrupts : shall be set to "<AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : shall be the main clock source phandle.
+For example:
+        utmi: utmick {
+                compatible = "atmel,at91sam9x5-clk-utmi";
+                interrupt-parent = <&pmc>;
+                interrupts = <AT91_PMC_LOCKU IRQ_TYPE_LEVEL_HIGH>;
+                #clock-cells = <0>;
+                clocks = <&main>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
new file mode 100644
index 000000000000..56d1f4961075
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/bcm-kona-clock.txt
@@ -0,0 +1,93 @@
+Broadcom Kona Family Clocks
+This binding is associated with Broadcom SoCs having "Kona" style
+clock control units (CCUs).  A CCU is a clock provider that manages
+a set of clock signals.  Each CCU is represented by a node in the
+device tree.
+This binding uses the common clock binding:
+    Documentation/devicetree/bindings/clock/clock-bindings.txt
+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"
+- reg
+        Shall define the base and range of the address space
+        containing clock control registers
+- #clock-cells
+        Shall have value <1>.  The permitted clock-specifier values
+        are defined below.
+- clock-output-names
+        Shall be an ordered list of strings defining the names of
+        the clocks provided by the 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".
+    CCU     Clock           Type    Index   Specifier
+    ---     -----           ----    -----   ---------
+    root    frac_1m         peri      0     BCM281XX_ROOT_CCU_FRAC_1M
+    aon     hub_timer       peri      0     BCM281XX_AON_CCU_HUB_TIMER
+    aon     pmu_bsc         peri      1     BCM281XX_AON_CCU_PMU_BSC
+    aon     pmu_bsc_var     peri      2     BCM281XX_AON_CCU_PMU_BSC_VAR
+    hub     tmon_1m         peri      0     BCM281XX_HUB_CCU_TMON_1M
+    master  sdio1           peri      0     BCM281XX_MASTER_CCU_SDIO1
+    master  sdio2           peri      1     BCM281XX_MASTER_CCU_SDIO2
+    master  sdio3           peri      2     BCM281XX_MASTER_CCU_SDIO3
+    master  sdio4           peri      3     BCM281XX_MASTER_CCU_SDIO4
+    master  dmac            peri      4     BCM281XX_MASTER_CCU_DMAC
+    master  usb_ic          peri      5     BCM281XX_MASTER_CCU_USB_IC
+    master  hsic2_48m       peri      6     BCM281XX_MASTER_CCU_HSIC_48M
+    master  hsic2_12m       peri      7     BCM281XX_MASTER_CCU_HSIC_12M
+    slave   uartb           peri      0     BCM281XX_SLAVE_CCU_UARTB
+    slave   uartb2          peri      1     BCM281XX_SLAVE_CCU_UARTB2
+    slave   uartb3          peri      2     BCM281XX_SLAVE_CCU_UARTB3
+    slave   uartb4          peri      3     BCM281XX_SLAVE_CCU_UARTB4
+    slave   ssp0            peri      4     BCM281XX_SLAVE_CCU_SSP0
+    slave   ssp2            peri      5     BCM281XX_SLAVE_CCU_SSP2
+    slave   bsc1            peri      6     BCM281XX_SLAVE_CCU_BSC1
+    slave   bsc2            peri      7     BCM281XX_SLAVE_CCU_BSC2
+    slave   bsc3            peri      8     BCM281XX_SLAVE_CCU_BSC3
+    slave   pwm             peri      9     BCM281XX_SLAVE_CCU_PWM
+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>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
index 75e2e1999f87..180e8835569e 100644
--- a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -8,12 +8,29 @@ Required Properties:
 - compatible: should be one of the following:
  - "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
-  - "samsung,exynos5250-audss-clock" - controller compatible with all Exynos5 SoCs.
+  - "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
+    SoCs.
+  - "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
+    SoCs.
 - reg: physical base address and length of the controller's register set.
 - #clock-cells: should be 1.
+- clocks:
+  - pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
+    is used if not specified.
+  - pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
+    is used if not specified.
+  - cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
+    specified.
+  - sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
+    not specified.
+  - sclk_pcm_in: PCM clock, parent of sclk_pcm.  "sclk_pcm0" is used if not
+    specified.
+- clock-names: Aliases for the above clocks. They should be "pll_ref",
+  "pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively.
 The following is the list of clocks generated by the controller. Each clock is
 assigned an identifier and client nodes use this identifier to specify the
 clock which they consume. Some of the clocks are available only on a particular
@@ -34,16 +51,30 @@ i2s_bus         6
 sclk_i2s        7
 pcm_bus         8
 sclk_pcm        9
+adma            10      Exynos5420
+Example 1: An example of a clock controller node using the default input
+           clock names is listed below.
+clock_audss: audss-clock-controller@3810000 {
+        compatible = "samsung,exynos5250-audss-clock";
+        reg = <0x03810000 0x0C>;
+        #clock-cells = <1>;
+};
-Example 1: An example of a clock controller node is listed below.
+Example 2: An example of a clock controller node with the input clocks
+           specified.
 clock_audss: audss-clock-controller@3810000 {
        compatible = "samsung,exynos5250-audss-clock";
        reg = <0x03810000 0x0C>;
        #clock-cells = <1>;
+        clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>,
+                <&ext_i2s_clk>;
+        clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk";
 };
-Example 2: I2S controller node that consumes the clock generated by the clock
+Example 3: I2S 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.
diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt
index eb65d417f8c4..7c52c29d99fa 100644
--- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
+++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -5,7 +5,7 @@ Sources of clock signal can be represented by any node in the device
 tree.  Those nodes are designated as clock providers.  Clock consumer
 nodes use a phandle and clock specifier pair to connect clock provider
 outputs to clock inputs.  Similar to the gpio specifiers, a clock
-specifier is an array of one more more cells identifying the clock
+specifier is an array of zero, one or more cells identifying the clock
 output on a device.  The length of a clock specifier is defined by the
 value of a #clock-cells property in the clock provider node.
diff --git a/Documentation/devicetree/bindings/clock/corenet-clock.txt b/Documentation/devicetree/bindings/clock/corenet-clock.txt
new file mode 100644
index 000000000000..24711af48e30
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/corenet-clock.txt
@@ -0,0 +1,134 @@
+* Clock Block on Freescale CoreNet Platforms
+Freescale CoreNet chips take primary clocking input from the external
+SYSCLK signal. The SYSCLK input (frequency) is multiplied using
+multiple phase locked loops (PLL) to create a variety of frequencies
+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.
+1. Clock Block Binding
+Required properties:
+- compatible: Should contain a specific clock block compatible string
+        and a single chassis clock compatible string.
+        Clock block strings include, but not limited to, one of the:
+        * "fsl,p2041-clockgen"
+        * "fsl,p3041-clockgen"
+        * "fsl,p4080-clockgen"
+        * "fsl,p5020-clockgen"
+        * "fsl,p5040-clockgen"
+        * "fsl,t4240-clockgen"
+        * "fsl,b4420-clockgen"
+        * "fsl,b4860-clockgen"
+        Chassis clock strings include:
+        * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks
+        * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks
+- reg: Describes the address of the device's resources within the
+        address space defined by its parent bus, and resource zero
+        represents the clock register set
+- clock-frequency: Input system clock frequency
+Recommended properties:
+- ranges: Allows valid translation between child's address space and
+        parent's. Must be present if the device has sub-nodes.
+- #address-cells: Specifies the number of cells used to represent
+        physical base addresses.  Must be present if the device has
+        sub-nodes and set to 1 if present
+- #size-cells: Specifies the number of cells used to represent
+        the size of an address. Must be present if the device has
+        sub-nodes and set to 1 if present
+2. Clock Provider/Consumer Binding
+Most of the bindings are from the common clock binding[1].
+ [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+Required properties:
+- compatible : Should include one of the following:
+        * "fsl,qoriq-core-pll-1.0" for core PLL clocks (v1.0)
+        * "fsl,qoriq-core-pll-2.0" for core PLL clocks (v2.0)
+        * "fsl,qoriq-core-mux-1.0" for core mux clocks (v1.0)
+        * "fsl,qoriq-core-mux-2.0" for core mux clocks (v2.0)
+        * "fsl,qoriq-sysclk-1.0": for input system clock (v1.0).
+                It takes parent's clock-frequency as its clock.
+        * "fsl,qoriq-sysclk-2.0": for input system clock (v2.0).
+                It takes parent's clock-frequency as its clock.
+- #clock-cells: From common clock binding. The number of cells in a
+        clock-specifier. Should be <0> for "fsl,qoriq-sysclk-[1,2].0"
+        clocks, or <1> for "fsl,qoriq-core-pll-[1,2].0" clocks.
+        For "fsl,qoriq-core-pll-[1,2].0" clocks, the single
+        clock-specifier cell may take the following values:
+        * 0 - equal to the PLL frequency
+        * 1 - equal to the PLL frequency divided by 2
+        * 2 - equal to the PLL frequency divided by 4
+Recommended properties:
+- clocks: Should be the phandle of input parent clock
+- clock-names: From common clock binding, indicates the clock name
+- clock-output-names: From common clock binding, indicates the names of
+        output clocks
+- reg: Should be the offset and length of clock block base address.
+        The length should be 4.
+Example for clock block and clock provider:
+/ {
+        clockgen: global-utilities@e1000 {
+                compatible = "fsl,p5020-clockgen", "fsl,qoriq-clockgen-1.0";
+                ranges = <0x0 0xe1000 0x1000>;
+                clock-frequency = <133333333>;
+                reg = <0xe1000 0x1000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                sysclk: sysclk {
+                        #clock-cells = <0>;
+                        compatible = "fsl,qoriq-sysclk-1.0";
+                        clock-output-names = "sysclk";
+                }
+                pll0: pll0@800 {
+                        #clock-cells = <1>;
+                        reg = <0x800 0x4>;
+                        compatible = "fsl,qoriq-core-pll-1.0";
+                        clocks = <&sysclk>;
+                        clock-output-names = "pll0", "pll0-div2";
+                };
+                pll1: pll1@820 {
+                        #clock-cells = <1>;
+                        reg = <0x820 0x4>;
+                        compatible = "fsl,qoriq-core-pll-1.0";
+                        clocks = <&sysclk>;
+                        clock-output-names = "pll1", "pll1-div2";
+                };
+                mux0: mux0@0 {
+                        #clock-cells = <0>;
+                        reg = <0x0 0x4>;
+                        compatible = "fsl,qoriq-core-mux-1.0";
+                        clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+                        clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+                        clock-output-names = "cmux0";
+                };
+                mux1: mux1@20 {
+                        #clock-cells = <0>;
+                        reg = <0x20 0x4>;
+                        compatible = "fsl,qoriq-core-mux-1.0";
+                        clocks = <&pll0 0>, <&pll0 1>, <&pll1 0>, <&pll1 1>;
+                        clock-names = "pll0", "pll0-div2", "pll1", "pll1-div2";
+                        clock-output-names = "cmux1";
+                };
+        };
+  }
+Example for clock consumer:
+/ {
+        cpu0: PowerPC,e5500@0 {
+                ...
+                clocks = <&mux0>;
+                ...
+        };
+  }
diff --git a/Documentation/devicetree/bindings/clock/emev2-clock.txt b/Documentation/devicetree/bindings/clock/emev2-clock.txt
new file mode 100644
index 000000000000..60bbb1a8c69a
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/emev2-clock.txt
@@ -0,0 +1,98 @@
+Device tree Clock bindings for Renesas EMMA Mobile EV2
+This binding uses the common clock binding.
+* SMU
+System Management Unit described in user's manual R19UH0037EJ1000_SMU.
+This is not a clock provider, but clocks under SMU depend on it.
+Required properties:
+- compatible: Should be "renesas,emev2-smu"
+- reg: Address and Size of SMU registers
+* SMU_CLKDIV
+Function block with an input mux and a divider, which corresponds to
+"Serial clock generator" in fig."Clock System Overview" of the manual,
+and "xxx frequency division setting register" (XXXCLKDIV) registers.
+This makes internal (neither input nor output) clock that is provided
+to input of xxxGCLK block.
+Required properties:
+- compatible: Should be "renesas,emev2-smu-clkdiv"
+- reg: Byte offset from SMU base and Bit position in the register
+- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
+- #clock-cells: Should be <0>
+* SMU_GCLK
+Clock gating node shown as "Clock stop processing block" in the
+fig."Clock System Overview" of the manual.
+Registers are "xxx clock gate control register" (XXXGCLKCTRL).
+Required properties:
+- compatible: Should be "renesas,emev2-smu-gclk"
+- reg: Byte offset from SMU base and Bit position in the register
+- clocks: Input clock as described in clock-bindings.txt
+- #clock-cells: Should be <0>
+Example of provider:
+usia_u0_sclkdiv: usia_u0_sclkdiv {
+        compatible = "renesas,emev2-smu-clkdiv";
+        reg = <0x610 0>;
+        clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>;
+        #clock-cells = <0>;
+};
+usia_u0_sclk: usia_u0_sclk {
+        compatible = "renesas,emev2-smu-gclk";
+        reg = <0x4a0 1>;
+        clocks = <&usia_u0_sclkdiv>;
+        #clock-cells = <0>;
+};
+Example of consumer:
+uart@e1020000 {
+        compatible = "renesas,em-uart";
+        reg = <0xe1020000 0x38>;
+        interrupts = <0 8 0>;
+        clocks = <&usia_u0_sclk>;
+        clock-names = "sclk";
+};
+Example of clock-tree description:
+ This describes a clock path in the clock tree
+  c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
+smu@e0110000 {
+        compatible = "renesas,emev2-smu";
+        reg = <0xe0110000 0x10000>;
+        #address-cells = <2>;
+        #size-cells = <0>;
+        c32ki: c32ki {
+                compatible = "fixed-clock";
+                clock-frequency = <32768>;
+                #clock-cells = <0>;
+        };
+        pll3_fo: pll3_fo {
+                compatible = "fixed-factor-clock";
+                clocks = <&c32ki>;
+                clock-div = <1>;
+                clock-mult = <7000>;
+                #clock-cells = <0>;
+        };
+        usia_u0_sclkdiv: usia_u0_sclkdiv {
+                compatible = "renesas,emev2-smu-clkdiv";
+                reg = <0x610 0>;
+                clocks = <&pll3_fo>;
+                #clock-cells = <0>;
+        };
+        usia_u0_sclk: usia_u0_sclk {
+                compatible = "renesas,emev2-smu-gclk";
+                reg = <0x4a0 1>;
+                clocks = <&usia_u0_sclkdiv>;
+                #clock-cells = <0>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 0f2f920e8734..72ce617dea82 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -62,6 +62,7 @@ clock which they consume.
  div_i2s1              157
  div_i2s2              158
  sclk_hdmiphy          159
+  div_pcm0              160
   [Peripheral Clock Gates]
diff --git a/Documentation/devicetree/bindings/clock/fixed-clock.txt b/Documentation/devicetree/bindings/clock/fixed-clock.txt
index 0b1fe7824093..48ea0ad8ad46 100644
--- a/Documentation/devicetree/bindings/clock/fixed-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-clock.txt
@@ -10,6 +10,8 @@ Required properties:
 - clock-frequency : frequency of clock in Hz. Should be a single cell.
 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.
@@ -18,4 +20,5 @@ Example:
                compatible = "fixed-clock";
                #clock-cells = <0>;
                clock-frequency = <1000000000>;
+                clock-accuracy = <100>;
        };
diff --git a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
index 5757f9abfc26..1bae8527eb9b 100644
--- a/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
+++ b/Documentation/devicetree/bindings/clock/fixed-factor-clock.txt
@@ -19,6 +19,6 @@ Example:
                compatible = "fixed-factor-clock";
                clocks = <&parentclk>;
                #clock-cells = <0>;
-                div = <2>;
+                clock-div = <2>;
-                mult = <1>;
+                clock-mult = <1>;
        };
diff --git a/Documentation/devicetree/bindings/clock/hi3620-clock.txt b/Documentation/devicetree/bindings/clock/hi3620-clock.txt
new file mode 100644
index 000000000000..4b71ab41be53
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/hi3620-clock.txt
@@ -0,0 +1,19 @@
+* Hisilicon Hi3620 Clock Controller
+The Hi3620 clock controller generates and supplies clock to various
+controllers within the Hi3620 SoC.
+Required Properties:
+- compatible: should be one of the following.
+  - "hisilicon,hi3620-clock" - controller compatible with Hi3620 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 use this identifier
+to specify the clock which they consume.
+All these identifier could be found in <dt-bindings/clock/hi3620-clock.h>.
diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.txt b/Documentation/devicetree/bindings/clock/imx35-clock.txt
new file mode 100644
index 000000000000..a70356452a82
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx35-clock.txt
@@ -0,0 +1,113 @@
+* Clock bindings for Freescale i.MX35
+Required properties:
+- compatible: Should be "fsl,imx35-ccm"
+- reg: Address and length of the register set
+- interrupts: Should contain CCM interrupt
+- #clock-cells: Should be <1>
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  The following is a full list of i.MX35
+clocks and IDs.
+        Clock                   ID
+        ---------------------------
+        ckih                    0
+        mpll                    1
+        ppll                    2
+        mpll_075                3
+        arm                     4
+        hsp                     5
+        hsp_div                 6
+        hsp_sel                 7
+        ahb                     8
+        ipg                     9
+        arm_per_div             10
+        ahb_per_div             11
+        ipg_per                 12
+        uart_sel                13
+        uart_div                14
+        esdhc_sel               15
+        esdhc1_div              16
+        esdhc2_div              17
+        esdhc3_div              18
+        spdif_sel               19
+        spdif_div_pre           20
+        spdif_div_post          21
+        ssi_sel                 22
+        ssi1_div_pre            23
+        ssi1_div_post           24
+        ssi2_div_pre            25
+        ssi2_div_post           26
+        usb_sel                 27
+        usb_div                 28
+        nfc_div                 29
+        asrc_gate               30
+        pata_gate               31
+        audmux_gate             32
+        can1_gate               33
+        can2_gate               34
+        cspi1_gate              35
+        cspi2_gate              36
+        ect_gate                37
+        edio_gate               38
+        emi_gate                39
+        epit1_gate              40
+        epit2_gate              41
+        esai_gate               42
+        esdhc1_gate             43
+        esdhc2_gate             44
+        esdhc3_gate             45
+        fec_gate                46
+        gpio1_gate              47
+        gpio2_gate              48
+        gpio3_gate              49
+        gpt_gate                50
+        i2c1_gate               51
+        i2c2_gate               52
+        i2c3_gate               53
+        iomuxc_gate             54
+        ipu_gate                55
+        kpp_gate                56
+        mlb_gate                57
+        mshc_gate               58
+        owire_gate              59
+        pwm_gate                60
+        rngc_gate               61
+        rtc_gate                62
+        rtic_gate               63
+        scc_gate                64
+        sdma_gate               65
+        spba_gate               66
+        spdif_gate              67
+        ssi1_gate               68
+        ssi2_gate               69
+        uart1_gate              70
+        uart2_gate              71
+        uart3_gate              72
+        usbotg_gate             73
+        wdog_gate               74
+        max_gate                75
+        admux_gate              76
+        csi_gate                77
+        csi_div                 78
+        csi_sel                 79
+        iim_gate                80
+        gpu2d_gate              81
+Examples:
+clks: ccm@53f80000 {
+        compatible = "fsl,imx35-ccm";
+        reg = <0x53f80000 0x4000>;
+        interrupts = <31>;
+        #clock-cells = <1>;
+};
+esdhc1: esdhc@53fb4000 {
+        compatible = "fsl,imx35-esdhc";
+        reg = <0x53fb4000 0x4000>;
+        interrupts = <7>;
+        clocks = <&clks 9>, <&clks 8>, <&clks 43>;
+        clock-names = "ipg", "ahb", "per";
+};
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index 4c029a8739d3..cadc4d29ada6 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -7,197 +7,8 @@ Required properties:
 - #clock-cells: Should be <1>
 The clock consumer should specify the desired clock by having the clock
-ID in its "clocks" phandle cell.  The following is a full list of i.MX5
+ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx5-clock.h
-clocks and IDs.
+for the full list of i.MX5 clock IDs.
-        Clock                   ID
-        ---------------------------
-        dummy                   0
-        ckil                    1
-        osc                     2
-        ckih1                   3
-        ckih2                   4
-        ahb                     5
-        ipg                     6
-        axi_a                   7
-        axi_b                   8
-        uart_pred               9
-        uart_root               10
-        esdhc_a_pred            11
-        esdhc_b_pred            12
-        esdhc_c_s               13
-        esdhc_d_s               14
-        emi_sel                 15
-        emi_slow_podf           16
-        nfc_podf                17
-        ecspi_pred              18
-        ecspi_podf              19
-        usboh3_pred             20
-        usboh3_podf             21
-        usb_phy_pred            22
-        usb_phy_podf            23
-        cpu_podf                24
-        di_pred                 25
-        tve_s                   27
-        uart1_ipg_gate          28
-        uart1_per_gate          29
-        uart2_ipg_gate          30
-        uart2_per_gate          31
-        uart3_ipg_gate          32
-        uart3_per_gate          33
-        i2c1_gate               34
-        i2c2_gate               35
-        gpt_ipg_gate            36
-        pwm1_ipg_gate           37
-        pwm1_hf_gate            38
-        pwm2_ipg_gate           39
-        pwm2_hf_gate            40
-        gpt_hf_gate             41
-        fec_gate                42
-        usboh3_per_gate         43
-        esdhc1_ipg_gate         44
-        esdhc2_ipg_gate         45
-        esdhc3_ipg_gate         46
-        esdhc4_ipg_gate         47
-        ssi1_ipg_gate           48
-        ssi2_ipg_gate           49
-        ssi3_ipg_gate           50
-        ecspi1_ipg_gate         51
-        ecspi1_per_gate         52
-        ecspi2_ipg_gate         53
-        ecspi2_per_gate         54
-        cspi_ipg_gate           55
-        sdma_gate               56
-        emi_slow_gate           57
-        ipu_s                   58
-        ipu_gate                59
-        nfc_gate                60
-        ipu_di1_gate            61
-        vpu_s                   62
-        vpu_gate                63
-        vpu_reference_gate      64
-        uart4_ipg_gate          65
-        uart4_per_gate          66
-        uart5_ipg_gate          67
-        uart5_per_gate          68
-        tve_gate                69
-        tve_pred                70
-        esdhc1_per_gate         71
-        esdhc2_per_gate         72
-        esdhc3_per_gate         73
-        esdhc4_per_gate         74
-        usb_phy_gate            75
-        hsi2c_gate              76
-        mipi_hsc1_gate          77
-        mipi_hsc2_gate          78
-        mipi_esc_gate           79
-        mipi_hsp_gate           80
-        ldb_di1_div_3_5         81
-        ldb_di1_div             82
-        ldb_di0_div_3_5         83
-        ldb_di0_div             84
-        ldb_di1_gate            85
-        can2_serial_gate        86
-        can2_ipg_gate           87
-        i2c3_gate               88
-        lp_apm                  89
-        periph_apm              90
-        main_bus                91
-        ahb_max                 92
-        aips_tz1                93
-        aips_tz2                94
-        tmax1                   95
-        tmax2                   96
-        tmax3                   97
-        spba                    98
-        uart_sel                99
-        esdhc_a_sel             100
-        esdhc_b_sel             101
-        esdhc_a_podf            102
-        esdhc_b_podf            103
-        ecspi_sel               104
-        usboh3_sel              105
-        usb_phy_sel             106
-        iim_gate                107
-        usboh3_gate             108
-        emi_fast_gate           109
-        ipu_di0_gate            110
-        gpc_dvfs                111
-        pll1_sw                 112
-        pll2_sw                 113
-        pll3_sw                 114
-        ipu_di0_sel             115
-        ipu_di1_sel             116
-        tve_ext_sel             117
-        mx51_mipi               118
-        pll4_sw                 119
-        ldb_di1_sel             120
-        di_pll4_podf            121
-        ldb_di0_sel             122
-        ldb_di0_gate            123
-        usb_phy1_gate           124
-        usb_phy2_gate           125
-        per_lp_apm              126
-        per_pred1               127
-        per_pred2               128
-        per_podf                129
-        per_root                130
-        ssi_apm                 131
-        ssi1_root_sel           132
-        ssi2_root_sel           133
-        ssi3_root_sel           134
-        ssi_ext1_sel            135
-        ssi_ext2_sel            136
-        ssi_ext1_com_sel        137
-        ssi_ext2_com_sel        138
-        ssi1_root_pred          139
-        ssi1_root_podf          140
-        ssi2_root_pred          141
-        ssi2_root_podf          142
-        ssi_ext1_pred           143
-        ssi_ext1_podf           144
-        ssi_ext2_pred           145
-        ssi_ext2_podf           146
-        ssi1_root_gate          147
-        ssi2_root_gate          148
-        ssi3_root_gate          149
-        ssi_ext1_gate           150
-        ssi_ext2_gate           151
-        epit1_ipg_gate          152
-        epit1_hf_gate           153
-        epit2_ipg_gate          154
-        epit2_hf_gate           155
-        can_sel                 156
-        can1_serial_gate        157
-        can1_ipg_gate           158
-        owire_gate              159
-        gpu3d_s                 160
-        gpu2d_s                 161
-        gpu3d_gate              162
-        gpu2d_gate              163
-        garb_gate               164
-        cko1_sel                165
-        cko1_podf               166
-        cko1                    167
-        cko2_sel                168
-        cko2_podf               169
-        cko2                    170
-        srtc_gate               171
-        pata_gate               172
-        sata_gate               173
-        spdif_xtal_sel          174
-        spdif0_sel              175
-        spdif1_sel              176
-        spdif0_pred             177
-        spdif0_podf             178
-        spdif1_pred             179
-        spdif1_podf             180
-        spdif0_com_sel          181
-        spdif1_com_sel          182
-        spdif0_gate             183
-        spdif1_gate             184
-        spdif_ipg_gate          185
-        ocram                   186
 Examples (for mx53):
@@ -212,7 +23,7 @@ can1: can@53fc8000 {
        compatible = "fsl,imx53-flexcan", "fsl,p1010-flexcan";
        reg = <0x53fc8000 0x4000>;
        interrupts = <82>;
-        clocks = <&clks 158>, <&clks 157>;
+        clocks = <&clks IMX5_CLK_CAN1_IPG_GATE>, <&clks IMX5_CLK_CAN1_SERIAL_GATE>;
        clock-names = "ipg", "per";
        status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt b/Documentation/devicetree/bindings/clock/keystone-pll.txt
index 12bd72605a31..225990f79b7c 100644
--- a/Documentation/devicetree/bindings/clock/keystone-pll.txt
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -17,13 +17,14 @@ Required properties:
 - reg - pll control0 and pll multipler registers
 - reg-names : control and multiplier. The multiplier is applicable only for
                main pll clock
- fixed-postdiv : fixed post divider value
+- fixed-postdiv : fixed post divider value. If absent, use clkod register bits
+                for postdiv
 Example:
        mainpllclk: mainpllclk@2310110 {
                #clock-cells = <0>;
                compatible = "ti,keystone,main-pll-clock";
-                clocks = <&refclkmain>;
+                clocks = <&refclksys>;
                reg = <0x02620350 4>, <0x02310110 4>;
                reg-names = "control", "multiplier";
                fixed-postdiv = <2>;
@@ -32,11 +33,10 @@ Example:
        papllclk: papllclk@2620358 {
                #clock-cells = <0>;
                compatible = "ti,keystone,pll-clock";
-                clocks = <&refclkmain>;
+                clocks = <&refclkpass>;
                clock-output-names = "pa-pll-clk";
                reg = <0x02620358 4>;
                reg-names = "control";
-                fixed-postdiv = <6>;
        };
 Required properties:
diff --git a/Documentation/devicetree/bindings/clock/maxim,max77686.txt b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
new file mode 100644
index 000000000000..96ce71bbd745
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/maxim,max77686.txt
@@ -0,0 +1,38 @@
+Binding for Maxim MAX77686 32k clock generator block
+This is a part of device tree bindings of MAX77686 multi-function device.
+More information can be found in bindings/mfd/max77686.txt file.
+The MAX77686 contains three 32.768khz clock outputs that can be controlled
+(gated/ungated) over I2C.
+Following properties should be presend in main device node of the MFD chip.
+Required properties:
+- #clock-cells: simple one-cell clock specifier format is used, where the
+  only cell is used as an index of the clock inside the provider. Following
+  indices are allowed:
+    - 0: 32khz_ap clock,
+    - 1: 32khz_cp clock,
+    - 2: 32khz_pmic clock.
+Example: Node of the MFD chip
+        max77686: max77686@09 {
+                compatible = "maxim,max77686";
+                interrupt-parent = <&wakeup_eint>;
+                interrupts = <26 0>;
+                reg = <0x09>;
+                #clock-cells = <1>;
+                /* ... */
+        };
+Example: Clock consumer node
+        foo@0 {
+                compatible = "bar,foo";
+                /* ... */
+                clock-names = "my-clock";
+                clocks = <&max77686 2>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
index 0c80c2677104..9acea9d93160 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
@@ -15,6 +15,9 @@ Required properties :
  In clock consumers, this cell represents the clock ID exposed by the
  CAR. The assignments may be found in header file
  <dt-bindings/clock/tegra114-car.h>.
+- #reset-cells : Should be 1.
+  In clock consumers, this cell represents the bit number in the CAR's
+  array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
 Example SoC include file:
@@ -23,6 +26,7 @@ Example SoC include file:
                compatible = "nvidia,tegra114-car";
                reg = <0x60006000 0x1000>;
                #clock-cells = <1>;
+                #reset-cells = <1>;
        };
        usb@c5004000 {
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
new file mode 100644
index 000000000000..ded5d6212c84
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
@@ -0,0 +1,63 @@
+NVIDIA Tegra124 Clock And Reset Controller
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The CAR (Clock And Reset) Controller on Tegra is the HW module responsible
+for muxing and gating Tegra's clocks, and setting their rates.
+Required properties :
+- compatible : Should be "nvidia,tegra124-car"
+- reg : Should contain CAR registers location and length
+- clocks : Should contain phandle and clock specifiers for two clocks:
+  the 32 KHz "32k_in", and the board-specific oscillator "osc".
+- #clock-cells : Should be 1.
+  In clock consumers, this cell represents the clock ID exposed by the
+  CAR. The assignments may be found in header file
+  <dt-bindings/clock/tegra124-car.h>.
+- #reset-cells : Should be 1.
+  In clock consumers, this cell represents the bit number in the CAR's
+  array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
+Example SoC include file:
+/ {
+        tegra_car: clock {
+                compatible = "nvidia,tegra124-car";
+                reg = <0x60006000 0x1000>;
+                #clock-cells = <1>;
+                #reset-cells = <1>;
+        };
+        usb@c5004000 {
+                clocks = <&tegra_car TEGRA124_CLK_USB2>;
+        };
+};
+Example board file:
+/ {
+        clocks {
+                compatible = "simple-bus";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                osc: clock@0 {
+                        compatible = "fixed-clock";
+                        reg = <0>;
+                        #clock-cells = <0>;
+                        clock-frequency = <112400000>;
+                };
+                clk_32k: clock@1 {
+                        compatible = "fixed-clock";
+                        reg = <1>;
+                        #clock-cells = <0>;
+                        clock-frequency = <32768>;
+                };
+        };
+        &tegra_car {
+                clocks = <&clk_32k> <&osc>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
index fcfed5bf73fb..6c5901b503d0 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -15,6 +15,9 @@ Required properties :
  In clock consumers, this cell represents the clock ID exposed by the
  CAR. The assignments may be found in header file
  <dt-bindings/clock/tegra20-car.h>.
+- #reset-cells : Should be 1.
+  In clock consumers, this cell represents the bit number in the CAR's
+  array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
 Example SoC include file:
@@ -23,6 +26,7 @@ Example SoC include file:
                compatible = "nvidia,tegra20-car";
                reg = <0x60006000 0x1000>;
                #clock-cells = <1>;
+                #reset-cells = <1>;
        };
        usb@c5004000 {
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
index 0f714081e986..63618cde12df 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
@@ -15,6 +15,9 @@ Required properties :
  In clock consumers, this cell represents the clock ID exposed by the
  CAR. The assignments may be found in header file
  <dt-bindings/clock/tegra30-car.h>.
+- #reset-cells : Should be 1.
+  In clock consumers, this cell represents the bit number in the CAR's
+  array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
 Example SoC include file:
@@ -23,6 +26,7 @@ Example SoC include file:
                compatible = "nvidia,tegra30-car";
                reg = <0x60006000 0x1000>;
                #clock-cells = <1>;
+                #reset-cells = <1>;
        };
        usb@c5004000 {
diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.txt b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
new file mode 100644
index 000000000000..767401f42871
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,gcc.txt
@@ -0,0 +1,21 @@
+Qualcomm Global Clock & Reset Controller Binding
+------------------------------------------------
+Required properties :
+- compatible : shall contain only one of the following:
+                        "qcom,gcc-msm8660"
+                        "qcom,gcc-msm8960"
+                        "qcom,gcc-msm8974"
+- reg : shall contain base register location and length
+- #clock-cells : shall contain 1
+- #reset-cells : shall contain 1
+Example:
+        clock-controller@900000 {
+                compatible = "qcom,gcc-msm8960";
+                reg = <0x900000 0x4000>;
+                #clock-cells = <1>;
+                #reset-cells = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.txt b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
new file mode 100644
index 000000000000..d572e9964c54
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.txt
@@ -0,0 +1,21 @@
+Qualcomm Multimedia Clock & Reset Controller Binding
+----------------------------------------------------
+Required properties :
+- compatible : shall contain only one of the following:
+                        "qcom,mmcc-msm8660"
+                        "qcom,mmcc-msm8960"
+                        "qcom,mmcc-msm8974"
+- reg : shall contain base register location and length
+- #clock-cells : shall contain 1
+- #reset-cells : shall contain 1
+Example:
+        clock-controller@4000000 {
+                compatible = "qcom,mmcc-msm8960";
+                reg = <0x4000000 0x1000>;
+                #clock-cells = <1>;
+                #reset-cells = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
new file mode 100644
index 000000000000..952e373178d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clocks.txt
@@ -0,0 +1,28 @@
+* Renesas CPG DIV6 Clock
+The CPG DIV6 clocks are variable factor clocks provided by the Clock Pulse
+Generator (CPG). They clock input is divided by a configurable factor from 1
+to 64.
+Required Properties:
+  - compatible: Must be one of the following
+    - "renesas,r8a7790-div6-clock" for R8A7790 (R-Car H2) DIV6 clocks
+    - "renesas,r8a7791-div6-clock" for R8A7791 (R-Car M2) DIV6 clocks
+    - "renesas,cpg-div6-clock" for generic DIV6 clocks
+  - reg: Base address and length of the memory resource used by the DIV6 clock
+  - clocks: Reference to the parent clock
+  - #clock-cells: Must be 0
+  - clock-output-names: The name of the clock as a free-form string
+Example
+-------
+        sd2_clk: sd2_clk@e6150078 {
+                compatible = "renesas,r8a7790-div6-clock", "renesas,cpg-div6-clock";
+                reg = <0 0xe6150078 0 4>;
+                clocks = <&pll1_div2_clk>;
+                #clock-cells = <0>;
+                clock-output-names = "sd2";
+        };
diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
new file mode 100644
index 000000000000..a6a352c2771e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
@@ -0,0 +1,51 @@
+* Renesas CPG Module Stop (MSTP) Clocks
+The CPG can gate SoC device clocks. The gates are organized in groups of up to
+32 gates.
+This device tree binding describes a single 32 gate clocks group per node.
+Clocks are referenced by user nodes by the MSTP node phandle and the clock
+index in the group, from 0 to 31.
+Required Properties:
+  - compatible: Must be one of the following
+    - "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
+  - reg: Base address and length of the I/O mapped registers used by the MSTP
+    clocks. The first register is the clock control register and is mandatory.
+    The second register is the clock status register and is optional when not
+    implemented in hardware.
+  - clocks: Reference to the parent clocks, one per output clock. The parents
+    must appear in the same order as the output clocks.
+  - #clock-cells: Must be 1
+  - clock-output-names: The name of the clocks as free-form strings
+  - renesas,indices: Indices of the gate clocks into the group (0 to 31)
+The clocks, clock-output-names and renesas,indices properties contain one
+entry per gate clock. The MSTP groups are sparsely populated. Unimplemented
+gate clocks must not be declared.
+Example
+-------
+        #include <dt-bindings/clock/r8a7790-clock.h>
+        mstp3_clks: mstp3_clks@e615013c {
+                compatible = "renesas,r8a7790-mstp-clocks", "renesas,cpg-mstp-clocks";
+                reg = <0 0xe615013c 0 4>, <0 0xe6150048 0 4>;
+                clocks = <&cp_clk>, <&mmc1_clk>, <&sd3_clk>, <&sd2_clk>,
+                         <&cpg_clocks R8A7790_CLK_SD1>, <&cpg_clocks R8A7790_CLK_SD0>,
+                         <&mmc0_clk>;
+                #clock-cells = <1>;
+                clock-output-names =
+                        "tpu0", "mmcif1", "sdhi3", "sdhi2",
+                         "sdhi1", "sdhi0", "mmcif0";
+                renesas,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,rcar-gen2-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
new file mode 100644
index 000000000000..7b41c2fe54db
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
@@ -0,0 +1,32 @@
+* Renesas R-Car Gen2 Clock Pulse Generator (CPG)
+The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
+and several fixed ratio dividers.
+Required Properties:
+  - compatible: Must be one of
+    - "renesas,r8a7790-cpg-clocks" for the r8a7790 CPG
+    - "renesas,r8a7791-cpg-clocks" for the r8a7791 CPG
+    - "renesas,rcar-gen2-cpg-clocks" for the generic R-Car Gen2 CPG
+  - 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 "main",
+    "pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1" and "z"
+Example
+-------
+        cpg_clocks: cpg_clocks@e6150000 {
+                compatible = "renesas,r8a7790-cpg-clocks",
+                             "renesas,rcar-gen2-cpg-clocks";
+                reg = <0 0xe6150000 0 0x1000>;
+                clocks = <&extal_clk>;
+                #clock-cells = <1>;
+                clock-output-names = "main", "pll0, "pll1", "pll3",
+                                     "lb", "qspi", "sdh", "sd0", "sd1", "z";
+        };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si570.txt b/Documentation/devicetree/bindings/clock/silabs,si570.txt
new file mode 100644
index 000000000000..c09f21e1d98f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/silabs,si570.txt
@@ -0,0 +1,39 @@
+Binding for Silicon Labs 570, 571, 598 and 599 programmable
+I2C clock generators.
+Reference
+This binding uses the common clock binding[1]. Details about the devices can be
+found in the data sheets[2][3].
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Si570/571 Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/si570.pdf
+[3] Si598/599 Data Sheet
+    http://www.silabs.com/Support%20Documents/TechnicalDocs/si598-99.pdf
+Required properties:
+ - compatible: Shall be one of "silabs,si570", "silabs,si571",
+                               "silabs,si598", "silabs,si599"
+ - reg: I2C device address.
+ - #clock-cells: From common clock bindings: Shall be 0.
+ - factory-fout: Factory set default frequency. This frequency is part specific.
+                 The correct frequency for the part used has to be provided in
+                 order to generate the correct output frequencies. For more
+                 details, please refer to the data sheet.
+ - temperature-stability: Temperature stability of the device in PPM. Should be
+                          one of: 7, 20, 50 or 100.
+Optional properties:
+ - clock-output-names: From common clock bindings. Recommended to be "si570".
+ - clock-frequency: Output frequency to generate. This defines the output
+                    frequency set during boot. It can be reprogrammed during
+                    runtime through the common clock framework.
+Example:
+        si570: clock-generator@5d {
+                #clock-cells = <0>;
+                compatible = "silabs,si570";
+                temperature-stability = <50>;
+                reg = <0x5d>;
+                factory-fout = <156250000>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 91a748fed13d..c2cb7621ad2d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -7,8 +7,10 @@ This binding uses the common clock binding[1].
 Required properties:
 - compatible : shall be one of the following:
        "allwinner,sun4i-osc-clk" - for a gatable oscillator
-        "allwinner,sun4i-pll1-clk" - for the main PLL clock
+        "allwinner,sun4i-pll1-clk" - for the main PLL clock and PLL4
        "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
+        "allwinner,sun4i-pll5-clk" - for the PLL5 clock
+        "allwinner,sun4i-pll6-clk" - for the PLL6 clock
        "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
        "allwinner,sun4i-axi-clk" - for the AXI clock
        "allwinner,sun4i-axi-gates-clk" - for the AXI gates
@@ -33,10 +35,14 @@ Required properties:
        "allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
        "allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
        "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
+        "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
+        "allwinner,sun7i-a20-out-clk" - for the external output clocks
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
- clocks : shall be the input parent clock(s) phandle for the clock
+- clocks : shall be the input parent clock(s) phandle for the clock. For
+        multiplexed clocks, the list order must match the hardware
+        programming order.
 - #clock-cells : from common clock binding; shall be set to 0 except for
        "allwinner,*-gates-clk" where it shall be set to 1
diff --git a/Documentation/devicetree/bindings/clock/ti/apll.txt b/Documentation/devicetree/bindings/clock/ti/apll.txt
new file mode 100644
index 000000000000..7faf5a68b3be
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/apll.txt
@@ -0,0 +1,31 @@
+Binding for Texas Instruments APLL clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1].  It assumes a
+register-mapped APLL with usually two selectable input clocks
+(reference clock and bypass clock), with analog phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) APLL mostly behaves like
+a subtype of a DPLL [2], although a simplified one at that.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/dpll.txt
+Required properties:
+- compatible : shall be "ti,dra7-apll-clock"
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks (clk-ref and clk-bypass)
+- reg : address and length of the register set for controlling the APLL.
+  It contains the information of registers in the following order:
+        "control" - contains the control register base address
+        "idlest" - contains the idlest register base address
+Examples:
+        apll_pcie_ck: apll_pcie_ck@4a008200 {
+                #clock-cells = <0>;
+                clocks = <&apll_pcie_in_clk_mux>, <&dpll_pcie_ref_ck>;
+                reg = <0x4a00821c 0x4>, <0x4a008220 0x4>;
+                compatible = "ti,dra7-apll-clock";
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/autoidle.txt b/Documentation/devicetree/bindings/clock/ti/autoidle.txt
new file mode 100644
index 000000000000..7c735dde9fe9
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/autoidle.txt
@@ -0,0 +1,39 @@
+Binding for Texas Instruments autoidle clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1]. It assumes a register mapped
+clock which can be put to idle automatically by hardware based on the usage
+and a configuration bit setting. Autoidle clock is never an individual
+clock, it is always a derivative of some basic clock like a gate, divider,
+or fixed-factor.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+Required properties:
+- reg : offset for the register controlling the autoidle
+- ti,autoidle-shift : bit shift of the autoidle enable bit
+- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0
+Examples:
+        dpll_core_m4_ck: dpll_core_m4_ck {
+                #clock-cells = <0>;
+                compatible = "ti,divider-clock";
+                clocks = <&dpll_core_x2_ck>;
+                ti,max-div = <31>;
+                ti,autoidle-shift = <8>;
+                reg = <0x2d38>;
+                ti,index-starts-at-one;
+                ti,invert-autoidle-bit;
+        };
+        dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck {
+                #clock-cells = <0>;
+                compatible = "ti,fixed-factor-clock";
+                clocks = <&dpll_usb_ck>;
+                ti,clock-div = <1>;
+                ti,autoidle-shift = <8>;
+                reg = <0x01b4>;
+                ti,clock-mult = <1>;
+                ti,invert-autoidle-bit;
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/clockdomain.txt b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
new file mode 100644
index 000000000000..cb76b3f2b341
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/clockdomain.txt
@@ -0,0 +1,24 @@
+Binding for Texas Instruments clockdomain.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1] in consumer role.
+Every clock on TI SoC belongs to one clockdomain, but software
+only needs this information for specific clocks which require
+their parent clockdomain to be controlled when the clock is
+enabled/disabled. This binding doesn't define a new clock
+binding type, it is used to group existing clock nodes under
+hardware hierarchy.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+Required properties:
+- compatible : shall be "ti,clockdomain"
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of clocks within this domain
+Examples:
+        dss_clkdm: dss_clkdm {
+                compatible = "ti,clockdomain";
+                clocks = <&dss1_alwon_fck_3430es2>, <&dss_ick_3430es2>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/composite.txt b/Documentation/devicetree/bindings/clock/ti/composite.txt
new file mode 100644
index 000000000000..5f43c4706b09
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/composite.txt
@@ -0,0 +1,54 @@
+Binding for TI composite clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1]. It assumes a
+register-mapped composite clock with multiple different sub-types;
+a multiplexer clock with multiple input clock signals or parents, one
+of which can be selected as output, this behaves exactly as [2]
+an adjustable clock rate divider, this behaves exactly as [3]
+a gating function which can be used to enable and disable the output
+clock, this behaves exactly as [4]
+The binding must provide a list of the component clocks that shall be
+merged to this clock. The component clocks shall be of one of the
+"ti,*composite*-clock" types.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/mux.txt
+[3] Documentation/devicetree/bindings/clock/ti/divider.txt
+[4] Documentation/devicetree/bindings/clock/ti/gate.txt
+Required properties:
+- compatible : shall be: "ti,composite-clock"
+- clocks : link phandles of component clocks
+- #clock-cells : from common clock binding; shall be set to 0.
+Examples:
+usb_l4_gate_ick: usb_l4_gate_ick {
+        #clock-cells = <0>;
+        compatible = "ti,composite-interface-clock";
+        clocks = <&l4_ick>;
+        ti,bit-shift = <5>;
+        reg = <0x0a10>;
+};
+usb_l4_div_ick: usb_l4_div_ick {
+        #clock-cells = <0>;
+        compatible = "ti,composite-divider-clock";
+        clocks = <&l4_ick>;
+        ti,bit-shift = <4>;
+        ti,max-div = <1>;
+        reg = <0x0a40>;
+        ti,index-starts-at-one;
+};
+usb_l4_ick: usb_l4_ick {
+        #clock-cells = <0>;
+        compatible = "ti,composite-clock";
+        clocks = <&usb_l4_gate_ick>, <&usb_l4_div_ick>;
+};
diff --git a/Documentation/devicetree/bindings/clock/ti/divider.txt b/Documentation/devicetree/bindings/clock/ti/divider.txt
new file mode 100644
index 000000000000..35a6f5c7e5c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/divider.txt
@@ -0,0 +1,114 @@
+Binding for TI divider clock
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1].  It assumes a
+register-mapped adjustable clock rate divider that does not gate and has
+only one input clock or parent.  By default the value programmed into
+the register is one less than the actual divisor value.  E.g:
+register value          actual divisor value
+0                       1
+1                       2
+2                       3
+This assumption may be modified by the following optional properties:
+ti,index-starts-at-one - valid divisor values start at 1, not the default
+of 0.  E.g:
+register value          actual divisor value
+1                       1
+2                       2
+3                       3
+ti,index-power-of-two - valid divisor values are powers of two.  E.g:
+register value          actual divisor value
+0                       1
+1                       2
+2                       4
+Additionally an array of valid dividers may be supplied like so:
+        ti,dividers = <4>, <8>, <0>, <16>;
+Which will map the resulting values to a divisor table by their index:
+register value          actual divisor value
+0                       4
+1                       8
+2                       <invalid divisor, skipped>
+3                       16
+Any zero value in this array means the corresponding bit-value is invalid
+and must not be used.
+The binding must also provide the register to control the divider and
+unless the divider array is provided, min and max dividers. Optionally
+the number of bits to shift that mask, if necessary. If the shift value
+is missing it is the same as supplying a zero shift.
+This binding can also optionally provide support to the hardware autoidle
+feature, see [2].
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt
+Required properties:
+- compatible : shall be "ti,divider-clock" or "ti,composite-divider-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link to phandle of parent clock
+- reg : offset for register controlling adjustable divider
+Optional properties:
+- clock-output-names : from common clock binding.
+- ti,dividers : array of integers defining divisors
+- ti,bit-shift : number of bits to shift the divider value, defaults to 0
+- ti,min-div : min divisor for dividing the input clock rate, only
+  needed if the first divisor is offset from the default value (1)
+- ti,max-div : max divisor for dividing the input clock rate, only needed
+  if ti,dividers is not defined.
+- ti,index-starts-at-one : valid divisor programming starts at 1, not zero,
+  only valid if ti,dividers is not defined.
+- ti,index-power-of-two : valid divisor programming must be a power of two,
+  only valid if ti,dividers is not defined.
+- ti,autoidle-shift : bit shift of the autoidle enable bit for the clock,
+  see [2]
+- ti,invert-autoidle-bit : autoidle is enabled by setting the bit to 0,
+  see [2]
+- ti,set-rate-parent : clk_set_rate is propagated to parent
+Examples:
+dpll_usb_m2_ck: dpll_usb_m2_ck@4a008190 {
+        #clock-cells = <0>;
+        compatible = "ti,divider-clock";
+        clocks = <&dpll_usb_ck>;
+        ti,max-div = <127>;
+        reg = <0x190>;
+        ti,index-starts-at-one;
+};
+aess_fclk: aess_fclk@4a004528 {
+        #clock-cells = <0>;
+        compatible = "ti,divider-clock";
+        clocks = <&abe_clk>;
+        ti,bit-shift = <24>;
+        reg = <0x528>;
+        ti,max-div = <2>;
+};
+dpll_core_m3x2_div_ck: dpll_core_m3x2_div_ck {
+        #clock-cells = <0>;
+        compatible = "ti,composite-divider-clock";
+        clocks = <&dpll_core_x2_ck>;
+        ti,max-div = <31>;
+        reg = <0x0134>;
+        ti,index-starts-at-one;
+};
+ssi_ssr_div_fck_3430es2: ssi_ssr_div_fck_3430es2 {
+        #clock-cells = <0>;
+        compatible = "ti,composite-divider-clock";
+        clocks = <&corex2_fck>;
+        ti,bit-shift = <8>;
+        reg = <0x0a40>;
+        ti,dividers = <0>, <1>, <2>, <3>, <4>, <0>, <6>, <0>, <8>;
+};
diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt
new file mode 100644
index 000000000000..30bfdb7c9f18
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt
@@ -0,0 +1,75 @@
+Binding for Texas Instruments DPLL clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1].  It assumes a
+register-mapped DPLL with usually two selectable input clocks
+(reference clock and bypass clock), with digital phase locked
+loop logic for multiplying the input clock to a desired output
+clock. This clock also typically supports different operation
+modes (locked, low power stop etc.) This binding has several
+sub-types, which effectively result in slightly different setup
+for the actual DPLL clock.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+Required properties:
+- compatible : shall be one of:
+                "ti,omap3-dpll-clock",
+                "ti,omap3-dpll-core-clock",
+                "ti,omap3-dpll-per-clock",
+                "ti,omap3-dpll-per-j-type-clock",
+                "ti,omap4-dpll-clock",
+                "ti,omap4-dpll-x2-clock",
+                "ti,omap4-dpll-core-clock",
+                "ti,omap4-dpll-m4xen-clock",
+                "ti,omap4-dpll-j-type-clock",
+                "ti,am3-dpll-no-gate-clock",
+                "ti,am3-dpll-j-type-clock",
+                "ti,am3-dpll-no-gate-j-type-clock",
+                "ti,am3-dpll-clock",
+                "ti,am3-dpll-core-clock",
+                "ti,am3-dpll-x2-clock",
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks, first entry lists reference clock
+  and second entry bypass clock
+- reg : offsets for the register set for controlling the DPLL.
+  Registers are listed in following order:
+        "control" - contains the control register base address
+        "idlest" - contains the idle status register base address
+        "mult-div1" - contains the multiplier / divider register base address
+        "autoidle" - contains the autoidle register base address (optional)
+  ti,am3-* dpll types do not have autoidle register
+Optional properties:
+- DPLL mode setting - defining any one or more of the following overrides
+  default setting.
+        - ti,low-power-stop : DPLL supports low power stop mode, gating output
+        - ti,low-power-bypass : DPLL output matches rate of parent bypass clock
+        - ti,lock : DPLL locks in programmed rate
+Examples:
+        dpll_core_ck: dpll_core_ck@44e00490 {
+                #clock-cells = <0>;
+                compatible = "ti,omap4-dpll-core-clock";
+                clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
+                reg = <0x490>, <0x45c>, <0x488>, <0x468>;
+        };
+        dpll2_ck: dpll2_ck@48004004 {
+                #clock-cells = <0>;
+                compatible = "ti,omap3-dpll-clock";
+                clocks = <&sys_ck>, <&dpll2_fck>;
+                ti,low-power-stop;
+                ti,low-power-bypass;
+                ti,lock;
+                reg = <0x4>, <0x24>, <0x34>, <0x40>;
+        };
+        dpll_core_ck: dpll_core_ck@44e00490 {
+                #clock-cells = <0>;
+                compatible = "ti,am3-dpll-core-clock";
+                clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
+                reg = <0x90>, <0x5c>, <0x68>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt
new file mode 100644
index 000000000000..662b36d53bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/fixed-factor-clock.txt
@@ -0,0 +1,43 @@
+Binding for TI fixed factor rate clock sources.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1], and also uses the autoidle
+support from TI autoidle clock [2].
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/ti/autoidle.txt
+Required properties:
+- compatible : shall be "ti,fixed-factor-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- ti,clock-div: fixed divider.
+- ti,clock-mult: fixed multiplier.
+- clocks: parent clock.
+Optional properties:
+- ti,autoidle-shift: bit shift of the autoidle enable bit for the clock,
+  see [2]
+- reg: offset for the autoidle register of this clock, see [2]
+- ti,invert-autoidle-bit: autoidle is enabled by setting the bit to 0, see [2]
+- ti,set-rate-parent: clk_set_rate is propagated to parent
+Example:
+        clock {
+                compatible = "ti,fixed-factor-clock";
+                clocks = <&parentclk>;
+                #clock-cells = <0>;
+                ti,clock-div = <2>;
+                ti,clock-mult = <1>;
+        };
+        dpll_usb_clkdcoldo_ck: dpll_usb_clkdcoldo_ck {
+                #clock-cells = <0>;
+                compatible = "ti,fixed-factor-clock";
+                clocks = <&dpll_usb_ck>;
+                ti,clock-div = <1>;
+                ti,autoidle-shift = <8>;
+                reg = <0x01b4>;
+                ti,clock-mult = <1>;
+                ti,invert-autoidle-bit;
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/gate.txt b/Documentation/devicetree/bindings/clock/ti/gate.txt
new file mode 100644
index 000000000000..125281aaa4ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/gate.txt
@@ -0,0 +1,85 @@
+Binding for Texas Instruments gate clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1]. This clock is
+quite much similar to the basic gate-clock [2], however,
+it supports a number of additional features. If no register
+is provided for this clock, the code assumes that a clockdomain
+will be controlled instead and the corresponding hw-ops for
+that is used.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+[3] Documentation/devicetree/bindings/clock/ti/clockdomain.txt
+Required properties:
+- compatible : shall be one of:
+  "ti,gate-clock" - basic gate clock
+  "ti,wait-gate-clock" - gate clock which waits until clock is active before
+                         returning from clk_enable()
+  "ti,dss-gate-clock" - gate clock with DSS specific hardware handling
+  "ti,am35xx-gate-clock" - gate clock with AM35xx specific hardware handling
+  "ti,clkdm-gate-clock" - clockdomain gate clock, which derives its functional
+                          clock directly from a clockdomain, see [3] how
+                          to map clockdomains properly
+  "ti,hsdiv-gate-clock" - gate clock with OMAP36xx specific hardware handling,
+                          required for a hardware errata
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : link to phandle of parent clock
+- reg : offset for register controlling adjustable gate, not needed for
+        ti,clkdm-gate-clock type
+Optional properties:
+- ti,bit-shift : bit shift for programming the clock gate, invalid for
+                 ti,clkdm-gate-clock type
+- ti,set-bit-to-disable : inverts default gate programming. Setting the bit
+  gates the clock and clearing the bit ungates the clock.
+Examples:
+        mmchs2_fck: mmchs2_fck@48004a00 {
+                #clock-cells = <0>;
+                compatible = "ti,gate-clock";
+                clocks = <&core_96m_fck>;
+                reg = <0x48004a00 0x4>;
+                ti,bit-shift = <25>;
+        };
+        uart4_fck_am35xx: uart4_fck_am35xx {
+                #clock-cells = <0>;
+                compatible = "ti,wait-gate-clock";
+                clocks = <&core_48m_fck>;
+                reg = <0x0a00>;
+                ti,bit-shift = <23>;
+        };
+        dss1_alwon_fck_3430es2: dss1_alwon_fck_3430es2@48004e00 {
+                #clock-cells = <0>;
+                compatible = "ti,dss-gate-clock";
+                clocks = <&dpll4_m4x2_ck>;
+                reg = <0x48004e00 0x4>;
+                ti,bit-shift = <0>;
+        };
+        emac_ick: emac_ick@4800259c {
+                #clock-cells = <0>;
+                compatible = "ti,am35xx-gate-clock";
+                clocks = <&ipss_ick>;
+                reg = <0x4800259c 0x4>;
+                ti,bit-shift = <1>;
+        };
+        emu_src_ck: emu_src_ck {
+                #clock-cells = <0>;
+                compatible = "ti,clkdm-gate-clock";
+                clocks = <&emu_src_mux_ck>;
+        };
+        dpll4_m2x2_ck: dpll4_m2x2_ck@48004d00 {
+                #clock-cells = <0>;
+                compatible = "ti,hsdiv-gate-clock";
+                clocks = <&dpll4_m2x2_mul_ck>;
+                ti,bit-shift = <0x1b>;
+                reg = <0x48004d00 0x4>;
+                ti,set-bit-to-disable;
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/interface.txt b/Documentation/devicetree/bindings/clock/ti/interface.txt
new file mode 100644
index 000000000000..064e8caccac3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/interface.txt
@@ -0,0 +1,54 @@
+Binding for Texas Instruments interface clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1]. This clock is
+quite much similar to the basic gate-clock [2], however,
+it supports a number of additional features, including
+companion clock finding (match corresponding functional gate
+clock) and hardware autoidle enable / disable.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/gate-clock.txt
+Required properties:
+- compatible : shall be one of:
+  "ti,omap3-interface-clock" - basic OMAP3 interface clock
+  "ti,omap3-no-wait-interface-clock" - interface clock which has no hardware
+                                       capability for waiting clock to be ready
+  "ti,omap3-hsotgusb-interface-clock" - interface clock with USB specific HW
+                                        handling
+  "ti,omap3-dss-interface-clock" - interface clock with DSS specific HW handling
+  "ti,omap3-ssi-interface-clock" - interface clock with SSI specific HW handling
+  "ti,am35xx-interface-clock" - interface clock with AM35xx specific HW handling
+- #clock-cells : from common clock binding; shall be set to 0
+- clocks : link to phandle of parent clock
+- reg : base address for the control register
+Optional properties:
+- ti,bit-shift : bit shift for the bit enabling/disabling the clock (default 0)
+Examples:
+        aes1_ick: aes1_ick@48004a14 {
+                #clock-cells = <0>;
+                compatible = "ti,omap3-interface-clock";
+                clocks = <&security_l4_ick2>;
+                reg = <0x48004a14 0x4>;
+                ti,bit-shift = <3>;
+        };
+        cam_ick: cam_ick@48004f10 {
+                #clock-cells = <0>;
+                compatible = "ti,omap3-no-wait-interface-clock";
+                clocks = <&l4_ick>;
+                reg = <0x48004f10 0x4>;
+                ti,bit-shift = <0>;
+        };
+        ssi_ick_3430es2: ssi_ick_3430es2@48004a10 {
+                #clock-cells = <0>;
+                compatible = "ti,omap3-ssi-interface-clock";
+                clocks = <&ssi_l4_ick>;
+                reg = <0x48004a10 0x4>;
+                ti,bit-shift = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/ti/mux.txt b/Documentation/devicetree/bindings/clock/ti/mux.txt
new file mode 100644
index 000000000000..2d0d170f8001
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ti/mux.txt
@@ -0,0 +1,76 @@
+Binding for TI mux clock.
+Binding status: Unstable - ABI compatibility may be broken in the future
+This binding uses the common clock binding[1].  It assumes a
+register-mapped multiplexer with multiple input clock signals or
+parents, one of which can be selected as output.  This clock does not
+gate or adjust the parent rate via a divider or multiplier.
+By default the "clocks" property lists the parents in the same order
+as they are programmed into the regster.  E.g:
+        clocks = <&foo_clock>, <&bar_clock>, <&baz_clock>;
+results in programming the register as follows:
+register value          selected parent clock
+0                       foo_clock
+1                       bar_clock
+2                       baz_clock
+Some clock controller IPs do not allow a value of zero to be programmed
+into the register, instead indexing begins at 1.  The optional property
+"index-starts-at-one" modified the scheme as follows:
+register value          selected clock parent
+1                       foo_clock
+2                       bar_clock
+3                       baz_clock
+The binding must provide the register to control the mux. Optionally
+the number of bits to shift the control field in the register can be
+supplied. If the shift value is missing it is the same as supplying
+a zero shift.
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+Required properties:
+- compatible : shall be "ti,mux-clock" or "ti,composite-mux-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : link phandles of parent clocks
+- reg : register offset for register controlling adjustable mux
+Optional properties:
+- ti,bit-shift : number of bits to shift the bit-mask, defaults to
+  0 if not present
+- ti,index-starts-at-one : valid input select programming starts at 1, not
+  zero
+- ti,set-rate-parent : clk_set_rate is propagated to parent clock,
+  not supported by the composite-mux-clock subtype
+Examples:
+sys_clkin_ck: sys_clkin_ck@4a306110 {
+        #clock-cells = <0>;
+        compatible = "ti,mux-clock";
+        clocks = <&virt_12000000_ck>, <&virt_13000000_ck>, <&virt_16800000_ck>, <&virt_19200000_ck>, <&virt_26000000_ck>, <&virt_27000000_ck>, <&virt_38400000_ck>;
+        reg = <0x0110>;
+        ti,index-starts-at-one;
+};
+abe_dpll_bypass_clk_mux_ck: abe_dpll_bypass_clk_mux_ck@4a306108 {
+        #clock-cells = <0>;
+        compatible = "ti,mux-clock";
+        clocks = <&sys_clkin_ck>, <&sys_32k_ck>;
+        ti,bit-shift = <24>;
+        reg = <0x0108>;
+};
+mcbsp5_mux_fck: mcbsp5_mux_fck {
+        #clock-cells = <0>;
+        compatible = "ti,composite-mux-clock";
+        clocks = <&core_96m_fck>, <&mcbsp_clks>;
+        ti,bit-shift = <4>;
+        reg = <0x02d8>;
+};
diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt
index d99af878f5d7..17b4a94916d6 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -22,6 +22,10 @@ Required properties:
 Optional properties:
 - clocks : as described in the clock bindings
 - clock-names : as described in the clock bindings
+ - fclk-enable : Bit mask to enable FCLKs statically at boot time.
+                 Bit [0..3] correspond to FCLK0..FCLK3. The corresponding
+                 FCLK will only be enabled if it is actually running at
+                 boot time.
 Clock inputs:
 The following strings are optional parameters to the 'clock-names' property in
diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
index 051f764bedb8..f055515d2b62 100644
--- a/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
+++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-cpu0.txt
@@ -15,6 +15,10 @@ Optional properties:
 - clock-latency: Specify the possible maximum transition latency for clock,
  in unit of nanoseconds.
 - voltage-tolerance: Specify the CPU voltage tolerance in percentage.
+- #cooling-cells:
+- cooling-min-level:
+- cooling-max-level:
+     Please refer to Documentation/devicetree/bindings/thermal/thermal.txt.
 Examples:
@@ -33,6 +37,9 @@ cpus {
                        198000  850000
                >;
                clock-latency = <61036>; /* two CLK32 periods */
+                #cooling-cells = <2>;
+                cooling-min-level = <0>;
+                cooling-max-level = <2>;
        };
        cpu@1 {
diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt
new file mode 100644
index 000000000000..f2aab3dc2b52
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt
@@ -0,0 +1,68 @@
+* Atmel HW cryptographic accelerators
+These are the HW cryptographic accelerators found on some Atmel products.
+* Advanced Encryption Standard (AES)
+Required properties:
+- compatible : Should be "atmel,at91sam9g46-aes".
+- reg: Should contain AES registers location and length.
+- interrupts: Should contain the IRQ line for the AES.
+- dmas: List of two DMA specifiers as described in
+        atmel-dma.txt and dma.txt files.
+- dma-names: Contains one identifier string for each DMA specifier
+             in the dmas property.
+Example:
+aes@f8038000 {
+        compatible = "atmel,at91sam9g46-aes";
+        reg = <0xf8038000 0x100>;
+        interrupts = <43 4 0>;
+        dmas = <&dma1 2 18>,
+               <&dma1 2 19>;
+        dma-names = "tx", "rx";
+* Triple Data Encryption Standard (Triple DES)
+Required properties:
+- compatible : Should be "atmel,at91sam9g46-tdes".
+- reg: Should contain TDES registers location and length.
+- interrupts: Should contain the IRQ line for the TDES.
+Optional properties:
+- dmas: List of two DMA specifiers as described in
+        atmel-dma.txt and dma.txt files.
+- dma-names: Contains one identifier string for each DMA specifier
+             in the dmas property.
+Example:
+tdes@f803c000 {
+        compatible = "atmel,at91sam9g46-tdes";
+        reg = <0xf803c000 0x100>;
+        interrupts = <44 4 0>;
+        dmas = <&dma1 2 20>,
+               <&dma1 2 21>;
+        dma-names = "tx", "rx";
+};
+* Secure Hash Algorithm (SHA)
+Required properties:
+- compatible : Should be "atmel,at91sam9g46-sha".
+- reg: Should contain SHA registers location and length.
+- interrupts: Should contain the IRQ line for the SHA.
+Optional properties:
+- dmas: One DMA specifiers as described in
+        atmel-dma.txt and dma.txt files.
+- dma-names: Contains one identifier string for each DMA specifier
+             in the dmas property. Only one "tx" string needed.
+Example:
+sha@f8034000 {
+        compatible = "atmel,at91sam9g46-sha";
+        reg = <0xf8034000 0x100>;
+        interrupts = <42 4 0>;
+        dmas = <&dma1 2 17>;
+        dma-names = "tx";
+};
diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.txt b/Documentation/devicetree/bindings/crypto/fsl-dcp.txt
new file mode 100644
index 000000000000..6949e50f1f16
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.txt
@@ -0,0 +1,17 @@
+Freescale DCP (Data Co-Processor) found on i.MX23/i.MX28 .
+Required properties:
+- compatible : Should be "fsl,<soc>-dcp"
+- reg : Should contain MXS DCP registers location and length
+- interrupts : Should contain MXS DCP interrupt numbers, VMI IRQ and DCP IRQ
+               must be supplied, optionally Secure IRQ can be present, but
+               is currently not implemented and not used.
+Example:
+dcp@80028000 {
+        compatible = "fsl,imx28-dcp", "fsl,imx23-dcp";
+        reg = <0x80028000 0x2000>;
+        interrupts = <52 53>;
+        status = "okay";
+};
diff --git a/Documentation/devicetree/bindings/dma/bcm2835-dma.txt b/Documentation/devicetree/bindings/dma/bcm2835-dma.txt
new file mode 100644
index 000000000000..1396078d15ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/bcm2835-dma.txt
@@ -0,0 +1,57 @@
+* BCM2835 DMA controller
+The BCM2835 DMA controller has 16 channels in total.
+Only the lower 13 channels have an associated IRQ.
+Some arbitrary channels are used by the firmware
+(1,3,6,7 in the current firmware version).
+The channels 0,2 and 3 have special functionality
+and should not be used by the driver.
+Required properties:
+- compatible: Should be "brcm,bcm2835-dma".
+- reg: Should contain DMA registers location and length.
+- interrupts: Should contain the DMA interrupts associated
+                to the DMA channels in ascending order.
+- #dma-cells: Must be <1>, the cell in the dmas property of the
+                client device represents the DREQ number.
+- brcm,dma-channel-mask: Bit mask representing the channels
+                         not used by the firmware in ascending order,
+                         i.e. first channel corresponds to LSB.
+Example:
+dma: dma@7e007000 {
+        compatible = "brcm,bcm2835-dma";
+        reg = <0x7e007000 0xf00>;
+        interrupts = <1 16>,
+                     <1 17>,
+                     <1 18>,
+                     <1 19>,
+                     <1 20>,
+                     <1 21>,
+                     <1 22>,
+                     <1 23>,
+                     <1 24>,
+                     <1 25>,
+                     <1 26>,
+                     <1 27>,
+                     <1 28>;
+        #dma-cells = <1>;
+        brcm,dma-channel-mask = <0x7f35>;
+};
+DMA clients connected to the BCM2835 DMA controller must use the format
+described in the dma.txt file, using a two-cell specifier for each channel.
+Example:
+bcm2835_i2s: i2s@7e203000 {
+        compatible = "brcm,bcm2835-i2s";
+        reg = < 0x7e203000 0x20>,
+              < 0x7e101098 0x02>;
+        dmas = <&dma 2>,
+               <&dma 3>;
+        dma-names = "tx", "rx";
+};
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index 4fa814d38321..68b83ecc3850 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -42,6 +42,7 @@ The full ID of peripheral types can be found below.
        19      IPU Memory
        20      ASRC
        21      ESAI
+        22      SSI Dual FIFO   (needs firmware ver >= 2)
 The third cell specifies the transfer priority as below.
diff --git a/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
new file mode 100644
index 000000000000..8a9f3559335b
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/moxa,moxart-dma.txt
@@ -0,0 +1,45 @@
+MOXA ART DMA Controller
+See dma.txt first
+Required properties:
+- compatible :  Must be "moxa,moxart-dma"
+- reg :         Should contain registers location and length
+- interrupts :  Should contain an interrupt-specifier for the sole
+                interrupt generated by the device
+- #dma-cells :  Should be 1, a single cell holding a line request number
+Example:
+        dma: dma@90500000 {
+                compatible = "moxa,moxart-dma";
+                reg = <0x90500080 0x40>;
+                interrupts = <24 0>;
+                #dma-cells = <1>;
+        };
+Clients:
+DMA clients connected to the MOXA ART DMA controller must use the format
+described in the dma.txt file, using a two-cell specifier for each channel:
+a phandle plus one integer cells.
+The two cells in order are:
+1. A phandle pointing to the DMA controller.
+2. Peripheral identifier for the hardware handshaking interface.
+Example:
+Use specific request line passing from dma
+For example, MMC request line is 5
+        sdhci: sdhci@98e00000 {
+                compatible = "moxa,moxart-sdhci";
+                reg = <0x98e00000 0x5C>;
+                interrupts = <5 0>;
+                clocks = <&clk_apb>;
+                dmas =  <&dma 5>,
+                        <&dma 5>;
+                dma-names = "tx", "rx";
+        };
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
index a8c21c256baa..1f5729f10621 100644
--- a/Documentation/devicetree/bindings/dma/ste-dma40.txt
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -50,6 +50,9 @@ Each dmas request consists of 4 cells:
        0x00000008: Use fixed channel:
                Use automatic channel selection when unset
                Use DMA request line number when set
+        0x00000010: Set channel as high priority:
+                Normal priority when unset
+                High priority when set
 Example:
diff --git a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
index 90fa7da525b8..c6908e7c42cc 100644
--- a/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
+++ b/Documentation/devicetree/bindings/dma/tegra20-apbdma.txt
@@ -5,6 +5,16 @@ Required properties:
 - reg: Should contain DMA registers location and length. This shuld include
  all of the per-channel registers.
 - interrupts: Should contain all of the per-channel DMA interrupts.
+- clocks: Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - dma
+- #dma-cells : Must be <1>. This dictates the length of DMA specifiers in
+  client nodes' dmas properties. The specifier represents the DMA request
+  select value for the peripheral. For more details, consult the Tegra TRM's
+  documentation of the APB DMA channel control register REQ_SEL field.
 Examples:
@@ -27,4 +37,8 @@ apbdma: dma@6000a000 {
                       0 149 0x04
                       0 150 0x04
                       0 151 0x04 >;
+        clocks = <&tegra_car 34>;
+        resets = <&tegra_car 34>;
+        reset-names = "dma";
+        #dma-cells = <1>;
 };
diff --git a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
index 7dab6a8f4a0e..45414bbcd945 100644
--- a/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
+++ b/Documentation/devicetree/bindings/extcon/extcon-palmas.txt
@@ -2,7 +2,11 @@ EXTCON FOR PALMAS/TWL CHIPS
 PALMAS USB COMPARATOR
 Required Properties:
- - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb"
+ - compatible: should contain one of:
+   * "ti,palmas-usb-vid".
+   * "ti,twl6035-usb-vid".
+   * "ti,palmas-usb" (DEPRECATED - use "ti,palmas-usb-vid").
+   * "ti,twl6035-usb" (DEPRECATED - use "ti,twl6035-usb-vid").
 Optional Properties:
 - ti,wakeup : To enable the wakeup comparator in probe
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
new file mode 100644
index 000000000000..a2e839d6e338
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -0,0 +1,41 @@
+Davinci GPIO controller bindings
+Required Properties:
+- compatible: should be "ti,dm6441-gpio"
+- reg: Physical base address of the controller and the size of memory mapped
+       registers.
+- gpio-controller : Marks the device node as a gpio controller.
+- interrupt-parent: phandle of the parent interrupt controller.
+- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are
+              supported at a time.
+- ti,ngpio: The number of GPIO pins supported.
+- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt
+                             line to processor.
+The GPIO controller also acts as an interrupt controller. It uses the default
+two cells specifier as described in Documentation/devicetree/bindings/
+interrupt-controller/interrupts.txt.
+Example:
+gpio: gpio@1e26000 {
+        compatible = "ti,dm6441-gpio";
+        gpio-controller;
+        reg = <0x226000 0x1000>;
+        interrupt-parent = <&intc>;
+        interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
+                44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH
+                46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH
+                48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH
+                50 IRQ_TYPE_EDGE_BOTH>;
+        ti,ngpio = <144>;
+        ti,davinci-gpio-unbanked = <0>;
+        interrupt-controller;
+        #interrupt-cells = <2>;
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
new file mode 100644
index 000000000000..80fcb7d70e13
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
@@ -0,0 +1,37 @@
+TI/National Semiconductor LP3943 GPIO controller
+Required properties:
+  - compatible: "ti,lp3943-gpio"
+  - gpio-controller: Marks the device node as a GPIO controller.
+  - #gpio-cells: Should be 2. See gpio.txt in this directory for a
+                 description of the cells format.
+Example:
+Simple LED controls with LP3943 GPIO controller
+&i2c4 {
+        lp3943@60 {
+                compatible = "ti,lp3943";
+                reg = <0x60>;
+                gpioex: gpio {
+                        compatible = "ti,lp3943-gpio";
+                        gpio-controller;
+                        #gpio-cells = <2>;
+                };
+        };
+};
+leds {
+        compatible = "gpio-leds";
+        indicator1 {
+                label = "indi1";
+                gpios = <&gpioex 9 GPIO_ACTIVE_LOW>;
+        };
+        indicator2 {
+                label = "indi2";
+                gpios = <&gpioex 10 GPIO_ACTIVE_LOW>;
+                default-state = "off";
+        };
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
index daa30174bcc1..3ddc7ccfe5f3 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt
@@ -38,12 +38,38 @@ Required device specific properties (only for SPI chips):
    removed.
 - spi-max-frequency = The maximum frequency this chip is able to handle
-Example I2C:
+Optional properties:
+- #interrupt-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify flags.
+- interrupt-controller: Marks the device node as a interrupt controller.
+NOTE: The interrupt functionality is only supported for i2c versions of the
+chips. The spi chips can also do the interrupts, but this is not supported by
+the linux driver yet.
+Optional device specific properties:
+- microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices
+        with two interrupt outputs (these are the devices ending with 17 and
+        those that have 16 IOs) have two IO banks: IO 0-7 form bank 1 and
+        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
+        bank they belong to.
+        On devices with only one interrupt output this property is useless.
+Example I2C (with interrupt):
 gpiom1: gpio@20 {
        compatible = "microchip,mcp23017";
        gpio-controller;
        #gpio-cells = <2>;
        reg = <0x20>;
+        interrupt-parent = <&gpio1>;
+        interrupts = <17 IRQ_TYPE_LEVEL_LOW>;
+        interrupt-controller;
+        #interrupt-cells=<2>;
+        microchip,irq-mirror;
 };
 Example SPI:
diff --git a/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
new file mode 100644
index 000000000000..f8e8f185a3db
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/moxa,moxart-gpio.txt
@@ -0,0 +1,19 @@
+MOXA ART GPIO Controller
+Required properties:
+- #gpio-cells : Should be 2, The first cell is the pin number,
+                the second cell is used to specify polarity:
+                        0 = active high
+                        1 = active low
+- compatible : Must be "moxa,moxart-gpio"
+- reg : Should contain registers location and length
+Example:
+        gpio: gpio@98700000 {
+                gpio-controller;
+                #gpio-cells = <2>;
+                compatible = "moxa,moxart-gpio";
+                reg =   <0x98700000 0xC>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
index 8655df9440d5..f61cef74a212 100644
--- a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -2,10 +2,11 @@
 Required Properties:
-  - compatible: should be one of the following.
+  - compatible: should contain one of the following.
    - "renesas,gpio-r8a7778": for R8A7778 (R-Mobile M1) compatible GPIO controller.
    - "renesas,gpio-r8a7779": for R8A7779 (R-Car H1) compatible GPIO controller.
    - "renesas,gpio-r8a7790": for R8A7790 (R-Car H2) compatible GPIO controller.
+    - "renesas,gpio-r8a7791": for R8A7791 (R-Car M2) compatible GPIO controller.
    - "renesas,gpio-rcar": for generic R-Car GPIO controller.
  - reg: Base address and length of each memory resource used by the GPIO
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
index b4fa934ae3a2..efaeec8961b6 100644
--- a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -9,6 +9,12 @@ Required properties:
 - #size-cells: The number of cells used to represent the size of an address
  range in the host1x address space. Should be 1.
 - ranges: The mapping of the host1x address space to the CPU address space.
+- clocks: Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - host1x
 The host1x top-level node defines a number of children, each representing one
 of the following host1x client modules:
@@ -19,6 +25,12 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-mpe"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+    See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - mpe
 - vi: video input
@@ -26,6 +38,12 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-vi"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+    See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - vi
 - epp: encoder pre-processor
@@ -33,6 +51,12 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-epp"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+    See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - epp
 - isp: image signal processor
@@ -40,6 +64,12 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-isp"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+    See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - isp
 - gr2d: 2D graphics engine
@@ -47,12 +77,30 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-gr2d"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+    See ../clocks/clock-bindings.txt for details.
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - 2d
 - gr3d: 3D graphics engine
  Required properties:
  - compatible: "nvidia,tegra<chip>-gr3d"
  - reg: Physical base address and length of the controller's registers.
+  - 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:
+    (This property may be omitted if the only clock in the list is "3d")
+    - 3d
+      This MUST be the first entry.
+    - 3d2 (Only required on SoCs with two 3D clocks)
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - 3d
+    - 3d2 (Only required on SoCs with two 3D clocks)
 - dc: display controller
@@ -60,6 +108,19 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-dc"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - 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:
+    - dc
+      This MUST be the first entry.
+    - parent
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - dc
+  - nvidia,head: The number of the display controller head. This is used to
+    setup the various types of output to receive video data from the given
+    head.
  Each display controller node has a child node, named "rgb", that represents
  the RGB output associated with the controller. It can take the following
@@ -67,6 +128,7 @@ of the following host1x client modules:
  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
  - nvidia,edid: supplies a binary EDID blob
+  - nvidia,panel: phandle of a display panel
 - hdmi: High Definition Multimedia Interface
@@ -76,11 +138,22 @@ of the following host1x client modules:
  - interrupts: The interrupt outputs from the controller.
  - vdd-supply: regulator for supply voltage
  - pll-supply: regulator for PLL
+  - 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:
+    - hdmi
+      This MUST be the first entry.
+    - parent
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - hdmi
  Optional properties:
  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
  - nvidia,edid: supplies a binary EDID blob
+  - nvidia,panel: phandle of a display panel
 - tvo: TV encoder output
@@ -88,12 +161,34 @@ of the following host1x client modules:
  - compatible: "nvidia,tegra<chip>-tvo"
  - reg: Physical base address and length of the controller's registers.
  - interrupts: The interrupt outputs from the controller.
+  - clocks: Must contain one entry, for the module clock.
+    See ../clocks/clock-bindings.txt for details.
 - dsi: display serial interface
  Required properties:
  - compatible: "nvidia,tegra<chip>-dsi"
  - reg: Physical base address and length of the controller's registers.
+  - 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:
+    - dsi
+      This MUST be the first entry.
+    - lp
+    - parent
+  - resets: Must contain an entry for each entry in reset-names.
+    See ../reset/reset.txt for details.
+  - reset-names: Must include the following entries:
+    - dsi
+  - 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.
+  Optional properties:
+  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+  - nvidia,edid: supplies a binary EDID blob
+  - nvidia,panel: phandle of a display panel
 Example:
@@ -105,6 +200,9 @@ Example:
                reg = <0x50000000 0x00024000>;
                interrupts = <0 65 0x04   /* mpcore syncpt */
                              0 67 0x04>; /* mpcore general */
+                clocks = <&tegra_car TEGRA20_CLK_HOST1X>;
+                resets = <&tegra_car 28>;
+                reset-names = "host1x";
                #address-cells = <1>;
                #size-cells = <1>;
@@ -115,41 +213,64 @@ Example:
                        compatible = "nvidia,tegra20-mpe";
                        reg = <0x54040000 0x00040000>;
                        interrupts = <0 68 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_MPE>;
+                        resets = <&tegra_car 60>;
+                        reset-names = "mpe";
                };
                vi {
                        compatible = "nvidia,tegra20-vi";
                        reg = <0x54080000 0x00040000>;
                        interrupts = <0 69 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_VI>;
+                        resets = <&tegra_car 100>;
+                        reset-names = "vi";
                };
                epp {
                        compatible = "nvidia,tegra20-epp";
                        reg = <0x540c0000 0x00040000>;
                        interrupts = <0 70 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_EPP>;
+                        resets = <&tegra_car 19>;
+                        reset-names = "epp";
                };
                isp {
                        compatible = "nvidia,tegra20-isp";
                        reg = <0x54100000 0x00040000>;
                        interrupts = <0 71 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_ISP>;
+                        resets = <&tegra_car 23>;
+                        reset-names = "isp";
                };
                gr2d {
                        compatible = "nvidia,tegra20-gr2d";
                        reg = <0x54140000 0x00040000>;
                        interrupts = <0 72 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_GR2D>;
+                        resets = <&tegra_car 21>;
+                        reset-names = "2d";
                };
                gr3d {
                        compatible = "nvidia,tegra20-gr3d";
                        reg = <0x54180000 0x00040000>;
+                        clocks = <&tegra_car TEGRA20_CLK_GR3D>;
+                        resets = <&tegra_car 24>;
+                        reset-names = "3d";
                };
                dc@54200000 {
                        compatible = "nvidia,tegra20-dc";
                        reg = <0x54200000 0x00040000>;
                        interrupts = <0 73 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_DISP1>,
+                                 <&tegra_car TEGRA20_CLK_PLL_P>;
+                        clock-names = "dc", "parent";
+                        resets = <&tegra_car 27>;
+                        reset-names = "dc";
                        rgb {
                                status = "disabled";
@@ -160,6 +281,11 @@ Example:
                        compatible = "nvidia,tegra20-dc";
                        reg = <0x54240000 0x00040000>;
                        interrupts = <0 74 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_DISP2>,
+                                 <&tegra_car TEGRA20_CLK_PLL_P>;
+                        clock-names = "dc", "parent";
+                        resets = <&tegra_car 26>;
+                        reset-names = "dc";
                        rgb {
                                status = "disabled";
@@ -170,6 +296,11 @@ Example:
                        compatible = "nvidia,tegra20-hdmi";
                        reg = <0x54280000 0x00040000>;
                        interrupts = <0 75 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_HDMI>,
+                                 <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
+                        clock-names = "hdmi", "parent";
+                        resets = <&tegra_car 51>;
+                        reset-names = "hdmi";
                        status = "disabled";
                };
@@ -177,12 +308,18 @@ Example:
                        compatible = "nvidia,tegra20-tvo";
                        reg = <0x542c0000 0x00040000>;
                        interrupts = <0 76 0x04>;
+                        clocks = <&tegra_car TEGRA20_CLK_TVO>;
                        status = "disabled";
                };
                dsi {
                        compatible = "nvidia,tegra20-dsi";
                        reg = <0x54300000 0x00040000>;
+                        clocks = <&tegra_car TEGRA20_CLK_DSI>,
+                                 <&tegra_car TEGRA20_CLK_PLL_D_OUT0>;
+                        clock-names = "dsi", "parent";
+                        resets = <&tegra_car 48>;
+                        reset-names = "dsi";
                        status = "disabled";
                };
        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
index b689a0d9441c..4fade84bea16 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
@@ -9,6 +9,7 @@ Required properties :
 - interrupts: interrupt number to the cpu.
 - #address-cells = <1>;
 - #size-cells = <0>;
+- clocks: phandles to input clocks.
 Optional properties:
 - Child nodes conforming to i2c bus binding
@@ -21,6 +22,7 @@ i2c0: i2c@fff84000 {
        interrupts = <12 4 6>;
        #address-cells = <1>;
        #size-cells = <0>;
+        clocks = <&twi0_clk>;
        24c512@50 {
                compatible = "24c512";
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
new file mode 100644
index 000000000000..34a3fb6f8488
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt
@@ -0,0 +1,50 @@
+* NXP PCA954x I2C bus switch
+Required Properties:
+  - compatible: Must contain one of the following.
+    "nxp,pca9540", "nxp,pca9542", "nxp,pca9543", "nxp,pca9544",
+    "nxp,pca9545", "nxp,pca9546", "nxp,pca9547", "nxp,pca9548"
+  - reg: The I2C address of the device.
+  The following required properties are defined externally:
+  - Standard I2C mux properties. See i2c-mux.txt in this directory.
+  - I2C child bus nodes. See i2c-mux.txt in this directory.
+Optional Properties:
+  - reset-gpios: Reference to the GPIO connected to the reset input.
+Example:
+        i2c-switch@74 {
+                compatible = "nxp,pca9548";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                reg = <0x74>;
+                i2c@2 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        reg = <2>;
+                        eeprom@54 {
+                                compatible = "at,24c08";
+                                reg = <0x54>;
+                        };
+                };
+                i2c@4 {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        reg = <4>;
+                        rtc@51 {
+                                compatible = "nxp,pcf8563";
+                                reg = <0x51>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index 82e8f6f17179..582b4652a82a 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -5,7 +5,11 @@ Required properties :
 - reg             : Offset and length of the register set for the device
 - compatible      : Should be "marvell,mv64xxx-i2c" or "allwinner,sun4i-i2c"
-                     or "marvell,mv78230-i2c"
+                     or "marvell,mv78230-i2c" or "marvell,mv78230-a0-i2c"
+                     Note: Only use "marvell,mv78230-a0-i2c" for a very rare,
+                     initial version of the SoC which had broken offload
+                     support.  Linux auto-detects this and sets it
+                     appropriately.
 - interrupts      : The interrupt number
 Optional properties :
diff --git a/Documentation/devicetree/bindings/i2c/i2c-riic.txt b/Documentation/devicetree/bindings/i2c/i2c-riic.txt
new file mode 100644
index 000000000000..0bcc4716c319
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-riic.txt
@@ -0,0 +1,29 @@
+Device tree configuration for Renesas RIIC driver
+Required properties:
+- compatible      : "renesas,riic-<soctype>". "renesas,riic-rz" as fallback
+- reg             : address start and address range size of device
+- interrupts      : 8 interrupts (TEI, RI, TI, SPI, STI, NAKI, ALI, TMOI)
+- clock-frequency : frequency of bus clock in Hz
+- #address-cells  : should be <1>
+- #size-cells     : should be <0>
+Pinctrl properties might be needed, too. See there.
+Example:
+        i2c0: i2c@fcfee000 {
+                compatible = "renesas,riic-r7s72100", "renesas,riic-rz";
+                reg = <0xfcfee000 0x44>;
+                interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 158 IRQ_TYPE_EDGE_RISING>,
+                             <0 159 IRQ_TYPE_EDGE_RISING>,
+                             <0 160 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 161 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 162 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 163 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 164 IRQ_TYPE_LEVEL_HIGH>;
+                clock-frequency = <100000>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index 296eb4536129..278de8e64bbf 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
@@ -10,6 +10,8 @@ Required properties:
          inside HDMIPHY block found on several samsung SoCs
      (d) "samsung, exynos5440-i2c", for s3c2440-like i2c used
           on EXYNOS5440 which does not need GPIO configuration.
+      (e) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as
+           a host to SATA PHY controller on an internal bus.
  - reg: physical base address of the controller and length of memory mapped
    region.
  - interrupts: interrupt number to the cpu.
diff --git a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
index ef77cc7a0e46..87507e9ce6db 100644
--- a/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
+++ b/Documentation/devicetree/bindings/i2c/nvidia,tegra20-i2c.txt
@@ -39,12 +39,23 @@ Required properties:
 - interrupts: Should contain I2C controller interrupts.
 - address-cells: Address cells for I2C device address.
 - size-cells: Size of the I2C device address.
- clocks: Clock ID as per
+- clocks: Must contain an entry for each entry in clock-names.
-                Documentation/devicetree/bindings/clock/tegra<chip-id>.txt
+  See ../clocks/clock-bindings.txt for details.
-        for I2C controller.
+- clock-names: Must include the following entries:
- clock-names: Name of the clock:
+  Tegra20/Tegra30:
-        Tegra20/Tegra30 I2C controller: "div-clk and "fast-clk".
+  - div-clk
-        Tegra114 I2C controller: "div-clk".
+  - fast-clk
+  Tegra114:
+  - div-clk
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - i2c
+- dmas: Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names: Must include the following entries:
+  - rx
+  - tx
 Example:
@@ -56,5 +67,9 @@ Example:
                #size-cells = <0>;
                clocks = <&tegra_car 12>, <&tegra_car 124>;
                clock-names = "div-clk", "fast-clk";
+                resets = <&tegra_car 12>;
+                reset-names = "i2c";
+                dmas = <&apbdma 16>, <&apbdma 16>;
+                dma-names = "rx", "tx";
                status = "disabled";
        };
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index b1cb3415e6f1..1a1ac2e560e9 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -16,6 +16,7 @@ adt7461			+/-1C TDM Extended Temp Range I.C
 at,24c08                i2c serial eeprom  (24cxx)
 atmel,24c02             i2c serial eeprom  (24cxx)
 atmel,at97sc3204t       i2c trusted platform module (TPM)
+capella,cm32181         CM32181: Ambient Light Sensor
 catalyst,24c32          i2c serial eeprom
 dallas,ds1307           64 x 8, Serial, I2C Real-Time Clock
 dallas,ds1338           I2C RTC with 56-Byte NV RAM
@@ -39,6 +40,7 @@ fsl,sgtl5000		SGTL5000: Ultra Low-Power Audio Codec
 gmt,g751                G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface
 infineon,slb9635tt      Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
 infineon,slb9645tt      Infineon SLB9645 I2C TPM (new protocol, max 400khz)
+isl,isl12057            Intersil ISL12057 I2C RTC Chip
 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
diff --git a/Documentation/devicetree/bindings/iio/humidity/dht11.txt b/Documentation/devicetree/bindings/iio/humidity/dht11.txt
new file mode 100644
index 000000000000..ecc24c199fd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/humidity/dht11.txt
@@ -0,0 +1,14 @@
+* DHT11 humidity/temperature sensor (and compatibles like DHT22)
+Required properties:
+  - compatible: Should be "dht11"
+  - gpios: Should specify the GPIO connected to the sensor's data
+    line, see "gpios property" in
+    Documentation/devicetree/bindings/gpio/gpio.txt.
+Example:
+humidity_sensor {
+        compatible = "dht11";
+        gpios = <&gpio0 6 0>;
+}
diff --git a/Documentation/devicetree/bindings/iio/light/tsl2563.txt b/Documentation/devicetree/bindings/iio/light/tsl2563.txt
new file mode 100644
index 000000000000..f91e809e736e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/tsl2563.txt
@@ -0,0 +1,19 @@
+* AMS TAOS TSL2563 ambient light sensor
+Required properties:
+  - compatible : should be "amstaos,tsl2563"
+  - reg : the I2C address of the sensor
+Optional properties:
+  - amstaos,cover-comp-gain : integer used as multiplier for gain
+                              compensation (default = 1)
+Example:
+tsl2563@29 {
+        compatible = "amstaos,tsl2563";
+        reg = <0x29>;
+        amstaos,cover-comp-gain = <16>;
+};
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt b/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt
new file mode 100644
index 000000000000..90d5f34db04e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/hmc5843.txt
@@ -0,0 +1,17 @@
+* Honeywell HMC5843 magnetometer sensor
+Required properties:
+  - compatible : should be "honeywell,hmc5843"
+  - reg : the I2C address of the magnetometer - typically 0x1e
+Optional properties:
+  - gpios : should be device tree identifier of the magnetometer DRDY pin
+Example:
+hmc5843@1e {
+        compatible = "honeywell,hmc5843"
+        reg = <0x1e>;
+};
diff --git a/Documentation/devicetree/bindings/input/gpio-beeper.txt b/Documentation/devicetree/bindings/input/gpio-beeper.txt
new file mode 100644
index 000000000000..a5086e37fce6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-beeper.txt
@@ -0,0 +1,13 @@
+* GPIO beeper device tree bindings
+Register a beeper connected to GPIO pin.
+Required properties:
+- compatible:   Should be "gpio-beeper".
+- gpios:        From common gpio binding; gpio connection to beeper enable pin.
+Example:
+        beeper: beeper {
+                compatible = "gpio-beeper";
+                gpios = <&gpio3 23 GPIO_ACTIVE_HIGH>;
+        };
diff --git a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
index 2995fae7ee47..0382b8bd69c6 100644
--- a/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
+++ b/Documentation/devicetree/bindings/input/nvidia,tegra20-kbc.txt
@@ -13,6 +13,12 @@ Required properties:
  array of pin numbers which is used as column.
 - linux,keymap: The keymap for keys as described in the binding document
  devicetree/bindings/input/matrix-keymap.txt.
+- clocks: Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - kbc
 Optional properties, in addition to those specified by the shared
 matrix-keyboard bindings:
@@ -31,6 +37,9 @@ keyboard: keyboard {
        compatible = "nvidia,tegra20-kbc";
        reg = <0x7000e200 0x100>;
        interrupts = <0 85 0x04>;
+        clocks = <&tegra_car 36>;
+        resets = <&tegra_car 36>;
+        reset-names = "kbc";
        nvidia,ghost-filter;
        nvidia,debounce-delay-ms = <640>;
        nvidia,kbc-row-pins = <0 1 2>;    /* pin 0, 1, 2 as rows */
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
new file mode 100644
index 000000000000..ec365e172236
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -0,0 +1,41 @@
+* Texas Instruments tsc2007 touchscreen controller
+Required properties:
+- compatible: must be "ti,tsc2007".
+- reg: I2C address of the chip.
+- ti,x-plate-ohms: X-plate resistance in ohms.
+Optional properties:
+- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
+  The penirq pin goes to low when the panel is touched.
+  (see GPIO binding[1] for more details).
+- interrupt-parent: the phandle for the gpio controller
+  (see interrupt binding[0]).
+- interrupts: (gpio) interrupt to which the chip is connected
+  (see interrupt binding[0]).
+- ti,max-rt: maximum pressure.
+- ti,fuzzx: specifies the absolute input fuzz x value.
+  If set, it will permit noise in the data up to +- the value given to the fuzz
+  parameter, that is used to filter noise from the event stream.
+- ti,fuzzy: specifies the absolute input fuzz y value.
+- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,poll-period: how much time to wait (in milliseconds) before reading again the
+  values from the tsc2007.
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
+Example:
+        &i2c1 {
+                /* ... */
+                tsc2007@49 {
+                        compatible = "ti,tsc2007";
+                        reg = <0x49>;
+                        interrupt-parent = <&gpio4>;
+                        interrupts = <0x0 0x8>;
+                        gpios = <&gpio4 0 0>;
+                        ti,x-plate-ohms = <180>;
+                };
+                /* ... */
+        };
diff --git a/Documentation/devicetree/bindings/input/twl4030-keypad.txt b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
new file mode 100644
index 000000000000..e4be2f76a717
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-keypad.txt
@@ -0,0 +1,27 @@
+* TWL4030's Keypad Controller device tree bindings
+TWL4030's Keypad controller is used to interface a SoC with a matrix-type
+keypad device. The keypad controller supports multiple row and column lines.
+A key can be placed at each intersection of a unique row and a unique column.
+The keypad controller can sense a key-press and key-release and report the
+event using a interrupt to the cpu.
+This binding is based on the matrix-keymap binding with the following
+changes:
+ * keypad,num-rows and keypad,num-columns are required.
+Required SoC Specific Properties:
+- compatible: should be one of the following
+   - "ti,twl4030-keypad": For controllers compatible with twl4030 keypad
+      controller.
+- interrupt: should be one of the following
+   - <1>: For controllers compatible with twl4030 keypad controller.
+Example:
+        twl_keypad: keypad {
+                compatible = "ti,twl4030-keypad";
+                interrupts = <1>;
+                keypad,num-rows = <8>;
+                keypad,num-columns = <8>;
+        };
diff --git a/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
new file mode 100644
index 000000000000..c864a46cddcf
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/twl4030-pwrbutton.txt
@@ -0,0 +1,21 @@
+Texas Instruments TWL family (twl4030) pwrbutton module
+This module is part of the TWL4030. For more details about the whole
+chip see Documentation/devicetree/bindings/mfd/twl-familly.txt.
+This module provides a simple power button event via an Interrupt.
+Required properties:
+- compatible: should be one of the following
+   - "ti,twl4030-pwrbutton": For controllers compatible with twl4030
+- interrupts: should be one of the following
+   - <8>: For controllers compatible with twl4030
+Example:
+&twl {
+        twl_pwrbutton: pwrbutton {
+                compatible = "ti,twl4030-pwrbutton";
+                interrupts = <8>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 3d3b2b91e333..32cec4b26cd0 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -14,5 +14,5 @@ intc: interrupt-controller {
        compatible = "allwinner,sun4i-ic";
        reg = <0x01c20400 0x400>;
        interrupt-controller;
-        #interrupt-cells = <2>;
+        #interrupt-cells = <1>;
 };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
new file mode 100644
index 000000000000..492911744ca3
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/snps,dw-apb-ictl.txt
@@ -0,0 +1,32 @@
+Synopsys DesignWare APB interrupt controller (dw_apb_ictl)
+Synopsys DesignWare provides interrupt controller IP for APB known as
+dw_apb_ictl. The IP is used as secondary interrupt controller in some SoCs with
+APB bus, e.g. Marvell Armada 1500.
+Required properties:
+- compatible: shall be "snps,dw-apb-ictl"
+- reg: physical base address of the controller and length of memory mapped
+  region starting with ENABLE_LOW register
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt-specifier, shall be 1
+- interrupts: interrupt reference to primary interrupt controller
+- interrupt-parent: (optional) reference specific primary interrupt controller
+The interrupt sources map to the corresponding bits in the interrupt
+registers, i.e.
+- 0 maps to bit 0 of low interrupts,
+- 1 maps to bit 1 of low interrupts,
+- 32 maps to bit 0 of high interrupts,
+- 33 maps to bit 1 of high interrupts,
+- (optional) fast interrupts start at 64.
+Example:
+        aic: interrupt-controller@3000 {
+                compatible = "snps,dw-apb-ictl";
+                reg = <0x3000 0xc00>;
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                interrupt-parent = <&gic>;
+                interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>;
+        };
diff --git a/Documentation/devicetree/bindings/leds/tca6507.txt b/Documentation/devicetree/bindings/leds/tca6507.txt
index 80ff3dfb1f32..d7221b84987c 100644
--- a/Documentation/devicetree/bindings/leds/tca6507.txt
+++ b/Documentation/devicetree/bindings/leds/tca6507.txt
@@ -2,6 +2,13 @@ LEDs connected to tca6507
 Required properties:
 - compatible : should be : "ti,tca6507".
+- #address-cells: must be 1
+- #size-cells: must be 0
+- reg: typically 0x45.
+Optional properties:
+- gpio-controller: allows lines to be used as output-only GPIOs.
+- #gpio-cells: if present, must be 0.
 Each led is represented as a sub-node of the ti,tca6507 device.
@@ -10,6 +17,7 @@ LED sub-node properties:
 - reg : number of LED line (could be from 0 to 6)
 - linux,default-trigger : (optional)
   see Documentation/devicetree/bindings/leds/common.txt
+- compatible: either "led" (the default) or "gpio".
 Examples:
@@ -19,6 +27,9 @@ tca6507@45 {
        #size-cells = <0>;
        reg = <0x45>;
+        gpio-controller;
+        #gpio-cells = <2>;
        led0: red-aux@0 {
                label = "red:aux";
                reg = <0x0>;
@@ -29,5 +40,10 @@ tca6507@45 {
                reg = <0x5>;
                linux,default-trigger = "default-on";
        };
+        wifi-reset@6 {
+                reg = <0x6>;
+                compatible = "gpio";
+        };
 };
diff --git a/Documentation/devicetree/bindings/marvell.txt b/Documentation/devicetree/bindings/marvell.txt
index f7a0da6b4022..ea2b16ced49b 100644
--- a/Documentation/devicetree/bindings/marvell.txt
+++ b/Documentation/devicetree/bindings/marvell.txt
@@ -79,7 +79,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   Required properties:
     - #address-cells : Should be <1>
     - #size-cells : Should be <0>
-     - device_type : Should be "mdio"
     - compatible : Should be "marvell,mv64360-mdio"
   Example:
@@ -87,7 +86,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
     mdio {
             #address-cells = <1>;
             #size-cells = <0>;
-             device_type = "mdio";
             compatible = "marvell,mv64360-mdio";
             ethernet-phy@0 {
@@ -132,7 +130,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   Ethernet port node
   Required properties:
-     - device_type : Should be "network".
     - compatible : Should be "marvell,mv64360-eth".
     - reg : Should be <0>, <1>, or <2>, according to which registers
       within the silicon block the device uses.
@@ -145,7 +142,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   Example Discovery Ethernet port node:
     ethernet@0 {
-             device_type = "network";
             compatible = "marvell,mv64360-eth";
             reg = <0>;
             interrupts = <32>;
@@ -159,7 +155,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   c) Marvell Discovery PHY nodes
   Required properties:
-     - device_type : Should be "ethernet-phy"
     - interrupts : <a> where a is the interrupt number for this phy.
     - interrupt-parent : the phandle for the interrupt controller that
       services interrupts for this device.
@@ -167,7 +162,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   Example Discovery PHY node:
     ethernet-phy@1 {
-             device_type = "ethernet-phy";
             compatible = "broadcom,bcm5421";
             interrupts = <76>;      /* GPP 12 */
             interrupt-parent = <&PIC>;
@@ -271,7 +265,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   serial port.
   Required properties:
-     - device_type : "serial"
     - compatible : "marvell,mv64360-mpsc"
     - reg : Offset and length of the register set for this device
     - sdma : the phandle for the SDMA node used by this port
@@ -288,7 +281,6 @@ prefixed with the string "marvell,", for Marvell Technology Group Ltd.
   Example Discovery MPSCINTR node:
     mpsc@8000 {
-             device_type = "serial";
             compatible = "marvell,mv64360-mpsc";
             reg = <0x8000 0x38>;
             virtual-reg = <0xf1008000>;
diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt b/Documentation/devicetree/bindings/mfd/as3722.txt
index fc2191ecfd6b..8edcb9bd873b 100644
--- a/Documentation/devicetree/bindings/mfd/as3722.txt
+++ b/Documentation/devicetree/bindings/mfd/as3722.txt
@@ -112,6 +112,15 @@ Following are properties of regulator subnode.
                ams,enable-tracking: Enable tracking with SD1, only supported
                        by LDO3.
+Power-off:
+=========
+AS3722 supports the system power off by turning off all its rail. This
+is provided through pm_power_off.
+The device node should have the following properties to enable this
+functionality
+ams,system-power-controller: Boolean, to enable the power off functionality
+        through this device.
 Example:
 --------
 #include <dt-bindings/mfd/as3722.h>
@@ -120,6 +129,8 @@ ams3722 {
        compatible = "ams,as3722";
        reg = <0x48>;
+        ams,system-power-controller;
        interrupt-parent = <&intc>;
        interrupt-controller;
        #interrupt-cells = <2>;
diff --git a/Documentation/devicetree/bindings/mfd/cros-ec.txt b/Documentation/devicetree/bindings/mfd/cros-ec.txt
index 5f229c5f6da9..8009c3d87f33 100644
--- a/Documentation/devicetree/bindings/mfd/cros-ec.txt
+++ b/Documentation/devicetree/bindings/mfd/cros-ec.txt
@@ -17,6 +17,15 @@ Required properties (SPI):
 - compatible: "google,cros-ec-spi"
 - reg: SPI chip select
+Optional properties (SPI):
+- google,cros-ec-spi-msg-delay: Some implementations of the EC require some
+  additional processing time in order to accept new transactions. If the delay
+  between transactions is not long enough the EC may not be able to respond
+  properly to subsequent transactions and cause them to hang. This property
+  specifies the delay, in usecs, introduced between transactions to account
+  for the time required by the EC to get back into a state in which new data
+  can be accepted.
 Required properties (LPC):
 - compatible: "google,cros-ec-lpc"
 - reg: List of (IO address, size) pairs defining the interface uses
diff --git a/Documentation/devicetree/bindings/mfd/lp3943.txt b/Documentation/devicetree/bindings/mfd/lp3943.txt
new file mode 100644
index 000000000000..e8591d6b11b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lp3943.txt
@@ -0,0 +1,33 @@
+TI/National Semiconductor LP3943 MFD driver
+Required properties:
+  - compatible: "ti,lp3943"
+  - reg: I2C slave address. From 0x60 to 0x67.
+LP3943 consists of two sub-devices, lp3943-gpio and lp3943-pwm.
+For the LP3943 GPIO properties please refer to:
+Documentation/devicetree/bindings/gpio/gpio-lp3943.txt
+For the LP3943 PWM properties please refer to:
+Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
+Example:
+lp3943@60 {
+        compatible = "ti,lp3943";
+        reg = <0x60>;
+        gpioex: gpio {
+                compatible = "ti,lp3943-gpio";
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
+        pwm3943: pwm {
+                compatible = "ti,lp3943-pwm";
+                #pwm-cells = <2>;
+                ti,pwm0 = <8 9 10>;
+                ti,pwm1 = <15>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/mfd/max77686.txt b/Documentation/devicetree/bindings/mfd/max77686.txt
index c6a3469d3436..678f3cf0b8f0 100644
--- a/Documentation/devicetree/bindings/mfd/max77686.txt
+++ b/Documentation/devicetree/bindings/mfd/max77686.txt
@@ -7,6 +7,9 @@ different i2c slave address,presently for which we are statically creating i2c
 client while probing.This document describes the binding for mfd device and
 PMIC submodule.
+Binding for the built-in 32k clock generator block is defined separately
+in bindings/clk/maxim,max77686.txt file.
 Required properties:
 - compatible : Must be "maxim,max77686";
 - reg : Specifies the i2c slave address of PMIC block.
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 78a840d7510d..15ee89c3cc7b 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -60,7 +60,7 @@ as per the datasheet of s2mps11.
        - LDOn
                  - valid values for n are 1 to 38
-                  - Example: LDO0, LD01, LDO28
+                  - Example: LDO1, LD02, LDO28
        - BUCKn
                  - valid values for n are 1 to 10.
                  - Example: BUCK1, BUCK2, BUCK9
diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt
index 2e3304888ffc..b4bd98af1cc7 100644
--- a/Documentation/devicetree/bindings/mfd/tps65910.txt
+++ b/Documentation/devicetree/bindings/mfd/tps65910.txt
@@ -21,7 +21,7 @@ Required properties:
  The valid regulator-compatible values are:
  tps65910: vrtc, vio, vdd1, vdd2, vdd3, vdig1, vdig2, vpll, vdac, vaux1,
-            vaux2, vaux33, vmmc
+            vaux2, vaux33, vmmc, vbb
  tps65911: vrtc, vio, vdd1, vdd3, vddctrl, ldo1, ldo2, ldo3, ldo4, ldo5,
            ldo6, ldo7, ldo8
@@ -38,7 +38,7 @@ Required properties:
        vcc4-supply: VAUX1 and VAUX2 input.
        vcc5-supply: VPLL and VDAC input.
        vcc6-supply: VDIG1 and VDIG2 input.
-        vcc7-supply: VRTC input.
+        vcc7-supply: VRTC and VBB input.
        vccio-supply: VIO input.
  tps65911:
        vcc1-supply: VDD1 input.
diff --git a/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
new file mode 100644
index 000000000000..973c27273772
--- /dev/null
+++ b/Documentation/devicetree/bindings/mipi/dsi/mipi-dsi-bus.txt
@@ -0,0 +1,98 @@
+MIPI DSI (Display Serial Interface) busses
+==========================================
+The MIPI Display Serial Interface specifies a serial bus and a protocol for
+communication between a host and up to four peripherals. This document will
+define the syntax used to represent a DSI bus in a device tree.
+This document describes DSI bus-specific properties only or defines existing
+standard properties in the context of the DSI bus.
+Each DSI host provides a DSI bus. The DSI host controller's node contains a
+set of properties that characterize the bus. Child nodes describe individual
+peripherals on that bus.
+The following assumes that only a single peripheral is connected to a DSI
+host. Experience shows that this is true for the large majority of setups.
+DSI host
+--------
+In addition to the standard properties and those defined by the parent bus of
+a DSI host, the following properties apply to a node representing a DSI host.
+Required properties:
+- #address-cells: The number of cells required to represent an address on the
+  bus. DSI peripherals are addressed using a 2-bit virtual channel number, so
+  a maximum of 4 devices can be addressed on a single bus. Hence the value of
+  this property should be 1.
+- #size-cells: Should be 0. There are cases where it makes sense to use a
+  different value here. See below.
+DSI peripheral
+--------------
+Peripherals are represented as child nodes of the DSI host's node. Properties
+described here apply to all DSI peripherals, but individual bindings may want
+to define additional, device-specific properties.
+Required properties:
+- reg: The virtual channel number of a DSI peripheral. Must be in the range
+  from 0 to 3.
+Some DSI peripherals respond to more than a single virtual channel. In that
+case two alternative representations can be chosen:
+- The reg property can take multiple entries, one for each virtual channel
+  that the peripheral responds to.
+- If the virtual channels that a peripheral responds to are consecutive, the
+  #size-cells can be set to 1. The first cell of each entry in the reg
+  property is the number of the first virtual channel and the second cell is
+  the number of consecutive virtual channels.
+Example
+-------
+        dsi-host {
+                ...
+                #address-cells = <1>;
+                #size-cells = <0>;
+                /* peripheral responds to virtual channel 0 */
+                peripheral@0 {
+                        compatible = "...";
+                        reg = <0>;
+                };
+                ...
+        };
+        dsi-host {
+                ...
+                #address-cells = <1>;
+                #size-cells = <0>;
+                /* peripheral responds to virtual channels 0 and 2 */
+                peripheral@0 {
+                        compatible = "...";
+                        reg = <0, 2>;
+                };
+                ...
+        };
+        dsi-host {
+                ...
+                #address-cells = <1>;
+                #size-cells = <1>;
+                /* peripheral responds to virtual channels 1, 2 and 3 */
+                peripheral@1 {
+                        compatible = "...";
+                        reg = <1 3>;
+                };
+                ...
+        };
diff --git a/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt b/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt
new file mode 100644
index 000000000000..e4a25cedc5cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/mipi/nvidia,tegra114-mipi.txt
@@ -0,0 +1,41 @@
+NVIDIA Tegra MIPI pad calibration controller
+Required properties:
+- compatible: "nvidia,tegra<chip>-mipi"
+- reg: Physical base address and length of the controller's registers.
+- 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:
+  - mipi-cal
+- #nvidia,mipi-calibrate-cells: Should be 1. The cell is a bitmask of the pads
+  that need to be calibrated for a given device.
+User nodes need to contain an nvidia,mipi-calibrate property that has a
+phandle to refer to the calibration controller node and a bitmask of the pads
+that need to be calibrated.
+Example:
+        mipi: mipi@700e3000 {
+                compatible = "nvidia,tegra114-mipi";
+                reg = <0x700e3000 0x100>;
+                clocks = <&tegra_car TEGRA114_CLK_MIPI_CAL>;
+                clock-names = "mipi-cal";
+                #nvidia,mipi-calibrate-cells = <1>;
+        };
+        ...
+        host1x@50000000 {
+                ...
+                dsi@54300000 {
+                        ...
+                        nvidia,mipi-calibrate = <&mipi 0x060>;
+                        ...
+                };
+                ...
+        };
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index a45ae08c8ed1..60960b2755f4 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -6,6 +6,9 @@ Required properties:
        - atmel,at91sam9g45-ssc: support dma transfer
 - reg: Should contain SSC registers location and length
 - interrupts: Should contain SSC interrupt
+- clock-names: tuple listing input clock names.
+        Required elements: "pclk"
+- clocks: phandles to input clocks.
 Required properties for devices compatible with "atmel,at91sam9g45-ssc":
@@ -20,6 +23,8 @@ ssc0: ssc@fffbc000 {
        compatible = "atmel,at91rm9200-ssc";
        reg = <0xfffbc000 0x4000>;
        interrupts = <14 4 5>;
+        clocks = <&ssc0_clk>;
+        clock-names = "pclk";
 };
 - DMA transfer:
diff --git a/Documentation/devicetree/bindings/misc/bmp085.txt b/Documentation/devicetree/bindings/misc/bmp085.txt
index 91dfda2e4e11..d7a6deb6b21e 100644
--- a/Documentation/devicetree/bindings/misc/bmp085.txt
+++ b/Documentation/devicetree/bindings/misc/bmp085.txt
@@ -8,6 +8,8 @@ Optional properties:
 - temp-measurement-period: temperature measurement period (milliseconds)
 - default-oversampling: default oversampling value to be used at startup,
  value range is 0-3 with rising sensitivity.
+- interrupt-parent: should be the phandle for the interrupt controller
+- interrupts: interrupt mapping for IRQ
 Example:
@@ -17,4 +19,6 @@ pressure@77 {
        chip-id = <10>;
        temp-measurement-period = <100>;
        default-oversampling = <2>;
+        interrupt-parent = <&gpio0>;
+        interrupts = <25 IRQ_TYPE_EDGE_RISING>;
 };
diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
new file mode 100644
index 000000000000..98ee2abbe138
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
@@ -0,0 +1,27 @@
+Device Tree Bindings for the Arasan SDHCI Controller
+  The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
+  deviations are documented here.
+  [1] Documentation/devicetree/bindings/mmc/mmc.txt
+  [2] Documentation/devicetree/bindings/clock/clock-bindings.txt
+  [3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+Required Properties:
+  - compatible: Compatibility string. Must be 'arasan,sdhci-8.9a'
+  - reg: From mmc bindings: Register location and length.
+  - clocks: From clock bindings: Handles to clock inputs.
+  - clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"
+  - interrupts: Interrupt specifier
+  - interrupt-parent: Phandle for the interrupt controller that services
+                      interrupts for this device.
+Example:
+        sdhci@e0100000 {
+                compatible = "arasan,sdhci-8.9a";
+                reg = <0xe0100000 0x1000>;
+                clock-names = "clk_xin", "clk_ahb";
+                clocks = <&clkc 21>, <&clkc 32>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 24 4>;
+        } ;
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
index c67b975c8906..532b1d440abc 100644
--- a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -16,6 +16,8 @@ Required Properties:
          specific extensions.
        - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
          specific extensions.
+        - "samsung,exynos5420-dw-mshc": for controllers with Samsung Exynos5420
+          specific extensions.
 * samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
diff --git a/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
new file mode 100644
index 000000000000..b8653ea97957
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/k3-dw-mshc.txt
@@ -0,0 +1,46 @@
+* Hisilicon specific extensions to the Synopsys Designware Mobile
+  Storage Host Controller
+Read synopsys-dw-mshc.txt for more details
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Hisilicon specific
+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.
+Example:
+        /* for Hi3620 */
+        /* SoC portion */
+        dwmmc_0: dwmmc0@fcd03000 {
+                compatible = "hisilicon,hi4511-dw-mshc";
+                reg = <0xfcd03000 0x1000>;
+                interrupts = <0 16 4>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                clocks = <&mmc_clock HI3620_SD_CIUCLK>, <&clock HI3620_DDRC_PER_CLK>;
+                clock-names = "ciu", "biu";
+        };
+        /* Board portion */
+        dwmmc0@fcd03000 {
+                num-slots = <1>;
+                vmmc-supply = <&ldo12>;
+                fifo-depth = <0x100>;
+                supports-highspeed;
+                pinctrl-names = "default";
+                pinctrl-0 = <&sd_pmx_pins &sd_cfg_func1 &sd_cfg_func2>;
+                slot@0 {
+                        reg = <0>;
+                        bus-width = <4>;
+                        disable-wp;
+                        cd-gpios = <&gpio10 3 0>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mmc/kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
index 789fb07a426d..aaba2483b4ff 100644
--- a/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/kona-sdhci.txt
@@ -6,12 +6,16 @@ and the properties present in the bcm281xx SDHCI
 Required properties:
 - compatible : Should be "brcm,kona-sdhci"
 - DEPRECATED: compatible : Should be "bcm,kona-sdhci"
+- clocks: phandle + clock specifier pair of the external clock
+Refer to clocks/clock-bindings.txt for generic clock consumer properties.
 Example:
 sdio2: sdio@0x3f1a0000 {
        compatible = "brcm,kona-sdhci";
        reg = <0x3f1a0000 0x10000>;
+        clocks = <&sdio3_clk>;
        interrupts = <0x0 74 0x4>;
 };
diff --git a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
index c6d7b11db9eb..f357c16ea815 100644
--- a/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
+++ b/Documentation/devicetree/bindings/mmc/nvidia,tegra20-sdhci.txt
@@ -8,6 +8,12 @@ by mmc.txt and the properties used by the sdhci-tegra driver.
 Required properties:
 - compatible : Should be "nvidia,<chip>-sdhci"
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - sdhci
 Optional properties:
 - power-gpios : Specify GPIOs for power control
@@ -18,6 +24,9 @@ sdhci@c8000200 {
        compatible = "nvidia,tegra20-sdhci";
        reg = <0xc8000200 0x200>;
        interrupts = <47>;
+        clocks = <&tegra_car 14>;
+        resets = <&tegra_car 14>;
+        reset-names = "sdhci";
        cd-gpios = <&gpio 69 0>; /* gpio PI5 */
        wp-gpios = <&gpio 57 0>; /* gpio PH1 */
        power-gpios = <&gpio 155 0>; /* gpio PT3 */
diff --git a/Documentation/devicetree/bindings/mtd/davinci-nand.txt b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
new file mode 100644
index 000000000000..cfb18abe6001
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/davinci-nand.txt
@@ -0,0 +1,94 @@
+Device tree bindings for Texas instruments Davinci/Keystone NAND controller
+This file provides information, what the device node for the davinci/keystone
+NAND interface contains.
+Documentation:
+Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
+Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
+Required properties:
+- compatible:                   "ti,davinci-nand"
+                                "ti,keystone-nand"
+- reg:                          Contains 2 offset/length values:
+                                - offset and length for the access window.
+                                - offset and length for accessing the AEMIF
+                                control registers.
+- ti,davinci-chipselect:        number of chipselect. Indicates on the
+                                davinci_nand driver which chipselect is used
+                                for accessing the nand.
+                                Can be in the range [0-3].
+Recommended properties :
+- ti,davinci-mask-ale:          mask for ALE. Needed for executing address
+                                phase. These offset will be added to the base
+                                address for the chip select space the NAND Flash
+                                device is connected to.
+                                If not set equal to 0x08.
+- ti,davinci-mask-cle:          mask for CLE. Needed for executing command
+                                phase. These offset will be added to the base
+                                address for the chip select space the NAND Flash
+                                device is connected to.
+                                If not set equal to 0x10.
+- ti,davinci-mask-chipsel:      mask for chipselect address. Needed to mask
+                                addresses for given chipselect.
+- nand-ecc-mode:                operation mode of the NAND ecc mode. ECC mode
+                                valid values for davinci driver:
+                                - "none"
+                                - "soft"
+                                - "hw"
+- ti,davinci-ecc-bits:          used ECC bits, currently supported 1 or 4.
+- nand-bus-width:               buswidth 8 or 16. If not present 8.
+- nand-on-flash-bbt:            use flash based bad block table support. OOB
+                                identifier is saved in OOB area. If not present
+                                false.
+Deprecated properties:
+- ti,davinci-ecc-mode:          operation mode of the NAND ecc mode. ECC mode
+                                valid values for davinci driver:
+                                - "none"
+                                - "soft"
+                                - "hw"
+- ti,davinci-nand-buswidth:     buswidth 8 or 16. If not present 8.
+- ti,davinci-nand-use-bbt:      use flash based bad block table support. OOB
+                                identifier is saved in OOB area. If not present
+                                false.
+Nand device bindings may contain additional sub-nodes describing partitions of
+the address space. See partition.txt for more detail. The NAND Flash timing
+values must be programmed in the chip select’s node of AEMIF
+memory-controller (see Documentation/devicetree/bindings/memory-controllers/
+davinci-aemif.txt).
+Example(da850 EVM ):
+nand_cs3@62000000 {
+        compatible = "ti,davinci-nand";
+        reg = <0x62000000 0x807ff
+               0x68000000 0x8000>;
+        ti,davinci-chipselect = <1>;
+        ti,davinci-mask-ale = <0>;
+        ti,davinci-mask-cle = <0>;
+        ti,davinci-mask-chipsel = <0>;
+        nand-ecc-mode = "hw";
+        ti,davinci-ecc-bits = <4>;
+        nand-on-flash-bbt;
+        partition@180000 {
+                label = "ubifs";
+                reg = <0x180000 0x7e80000>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index 551b2a179d01..458d59634688 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -17,6 +17,14 @@ Required properties:
 Optional properties:
  - nand-on-flash-bbt: boolean to enable on flash bbt option if not
                       present false
+  - fsl,use-minimum-ecc: Protect this NAND flash with the minimum ECC
+                       strength required. The required ECC strength is
+                       automatically discoverable for some flash
+                       (e.g., according to the ONFI standard).
+                       However, note that if this strength is not
+                       discoverable or this property is not enabled,
+                       the software may chooses an implementation-defined
+                       ECC scheme.
 The device tree may optionally contain sub-nodes describing partitions of the
 address space. See partition.txt for more detail.
diff --git a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
index f1421e2bbab7..86e0a5601ff5 100644
--- a/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
@@ -2,7 +2,9 @@ PXA3xx NAND DT bindings
 Required properties:
- - compatible:          Should be "marvell,pxa3xx-nand"
+ - compatible:          Should be set to one of the following:
+                        marvell,pxa3xx-nand
+                        marvell,armada370-nand
 - reg:                 The register base for the controller
 - interrupts:          The interrupt to map
 - #address-cells:      Set to <1> if the node includes partitions
@@ -13,6 +15,8 @@ Optional properties:
 - marvell,nand-keep-config:    Set to keep the NAND controller config as set
                                by the bootloader
 - num-cs:                      Number of chipselect lines to usw
+ - nand-on-flash-bbt:           boolean to enable on flash bbt option if
+                                not present false
 Example:
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
new file mode 100644
index 000000000000..ea4d752389a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun7i-a20-gmac.txt
@@ -0,0 +1,27 @@
+* Allwinner GMAC ethernet controller
+This device is a platform glue layer for stmmac.
+Please see stmmac.txt for the other unchanged properties.
+Required properties:
+ - compatible:  Should be "allwinner,sun7i-a20-gmac"
+ - clocks: Should contain the GMAC main clock, and tx clock
+   The tx clock type should be "allwinner,sun7i-a20-gmac-clk"
+ - clock-names: Should contain the clock names "stmmaceth",
+   and "allwinner_gmac_tx"
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+Examples:
+        gmac: ethernet@01c50000 {
+                compatible = "allwinner,sun7i-a20-gmac";
+                reg = <0x01c50000 0x10000>,
+                      <0x01c20164 0x4>;
+                interrupts = <0 85 1>;
+                interrupt-names = "macirq";
+                clocks = <&ahb_gates 49>, <&gmac_tx>;
+                clock-names = "stmmaceth", "allwinner_gmac_tx";
+                phy-mode = "mii";
+        };
diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt b/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt
new file mode 100644
index 000000000000..ee3723beb701
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251x.txt
@@ -0,0 +1,25 @@
+* Microchip MCP251X stand-alone CAN controller device tree bindings
+Required properties:
+ - compatible: Should be one of the following:
+   - "microchip,mcp2510" for MCP2510.
+   - "microchip,mcp2515" for MCP2515.
+ - reg: SPI chip select.
+ - clocks: The clock feeding the CAN controller.
+ - interrupt-parent: The parent interrupt controller.
+ - interrupts: Should contain IRQ line for the CAN controller.
+Optional properties:
+ - vdd-supply: Regulator that powers the CAN controller.
+ - xceiver-supply: Regulator that powers the CAN transceiver.
+Example:
+        can0: can@1 {
+                compatible = "microchip,mcp2515";
+                reg = <1>;
+                clocks = <&clk24m>;
+                interrupt-parent = <&gpio4>;
+                interrupts = <13 0x2>;
+                vdd-supply = <&reg5v0>;
+                xceiver-supply = <&reg5v0>;
+        };
diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt
index bad381faf036..6e356d15154a 100644
--- a/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -10,10 +10,6 @@ Required properties:
 - ti,davinci-ctrl-mod-reg-offset: offset to control module register
 - ti,davinci-ctrl-ram-offset: offset to control module ram
 - ti,davinci-ctrl-ram-size: size of control module ram
- ti,davinci-rmii-en: use RMII
- ti,davinci-no-bd-ram: has the emac controller BD RAM
- phy-handle: Contains a phandle to an Ethernet PHY.
-              if not, davinci_emac driver defaults to 100/FULL
 - interrupts: interrupt mapping for the davinci emac interrupts sources:
              4 sources: <Receive Threshold Interrupt
                          Receive Interrupt
@@ -21,7 +17,11 @@ Required properties:
                          Miscellaneous Interrupt>
 Optional properties:
+- phy-handle: Contains a phandle to an Ethernet PHY.
+              If absent, davinci_emac driver defaults to 100/FULL.
 - local-mac-address : 6 bytes, mac address
+- ti,davinci-rmii-en: 1 byte, 1 means use RMII
+- ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM?
 Example (enbw_cmc board):
        eth0: emac@1e20000 {
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 4ff65047bb9a..70af2ec12b09 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -10,6 +10,10 @@ Required properties:
 - interrupts: Should contain macb interrupt
 - phy-mode: String, operation mode of the PHY interface.
  Supported values are: "mii", "rmii", "gmii", "rgmii".
+- clock-names: Tuple listing input clock names.
+        Required elements: 'pclk', 'hclk'
+        Optional elements: 'tx_clk'
+- clocks: Phandles to input clocks.
 Optional properties:
 - local-mac-address: 6 bytes, mac address
@@ -22,4 +26,6 @@ Examples:
                interrupts = <21>;
                phy-mode = "rmii";
                local-mac-address = [3a 0e 03 04 05 06];
+                clock-names = "pclk", "hclk", "tx_clk";
+                clocks = <&clkc 30>, <&clkc 30>, <&clkc 13>;
        };
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
index a73b79f227e1..c233b6114242 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-net.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -32,7 +32,6 @@ Optional controller properties:
 * Ethernet port node
 Required port properties:
- - device_type: shall be "network".
 - compatible: shall be one of "marvell,orion-eth-port",
      "marvell,kirkwood-eth-port".
 - reg: port number relative to ethernet controller, shall be 0, 1, or 2.
@@ -61,7 +60,6 @@ or
 mdio-bus {
        ...
        ethphy: ethernet-phy@8 {
-                device_type = "ethernet-phy";
                ...
        };
 };
@@ -75,7 +73,6 @@ eth: ethernet-controller@72000 {
        marvell,tx-checksum-limit = <1600>;
        ethernet@0 {
-                device_type = "network";
                compatible = "marvell,orion-eth-port";
                reg = <0>;
                interrupts = <29>;
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 7cd18fbfcf71..58307d0931c8 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -2,7 +2,6 @@ PHY nodes
 Required properties:
- - device_type : Should be "ethernet-phy"
 - interrupts : <a b> where a is the interrupt number and b is a
   field that represents an encoding of the sense and level
   information for the interrupt.  This should be encoded based on
@@ -11,8 +10,6 @@ Required properties:
 - interrupt-parent : the phandle for the interrupt controller that
   services interrupts for this device.
 - reg : The ID number for the phy, usually a small integer
- - linux,phandle :  phandle for this node; likely referenced by an
-   ethernet controller node.
 Optional Properties:
@@ -22,14 +19,13 @@ Optional Properties:
  specifications. If neither of these are specified, the default is to
  assume clause 22. The compatible list may also contain other
  elements.
+- max-speed: Maximum PHY supported speed (10, 100, 1000...)
 Example:
 ethernet-phy@0 {
        compatible = "ethernet-phy-ieee802.3-c22";
-        linux,phandle = <2452000>;
        interrupt-parent = <40000>;
        interrupts = <35 1>;
        reg = <0>;
-        device_type = "ethernet-phy";
 };
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index eba0e5e59ebe..9d92d42140f2 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,7 +12,6 @@ Required properties:
  property
 - phy-mode: String, operation mode of the PHY interface.
  Supported values are: "mii", "rmii", "gmii", "rgmii".
- snps,phy-addr         phy address to connect to.
 - snps,reset-gpio       gpio number for phy reset.
 - snps,reset-active-low boolean flag to indicate if phy reset is active low.
 - snps,reset-delays-us  is triplet of delays
@@ -30,6 +29,11 @@ Required properties:
 Optional properties:
 - mac-address: 6 bytes, mac address
+- resets: Should contain a phandle to the STMMAC reset signal, if any
+- reset-names: Should contain the reset signal name "stmmaceth", if a
+        reset phandle is given
+- max-frame-size:       Maximum Transfer Unit (IEEE defined MTU), rather
+                        than the maximum frame size.
 Examples:
@@ -40,5 +44,6 @@ Examples:
                interrupts = <24 23>;
                interrupt-names = "macirq", "eth_wake_irq";
                mac-address = [000000000000]; /* Filled in by U-Boot */
+                max-frame-size = <3800>;
                phy-mode = "gmii";
        };
diff --git a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
index 5aeee53ff9f4..5ae601e7f51f 100644
--- a/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
+++ b/Documentation/devicetree/bindings/nvec/nvidia,nvec.txt
@@ -7,3 +7,15 @@ Required properties:
 - clock-frequency : the frequency of the i2c bus
 - gpios : the gpio used for ec request
 - slave-addr: the i2c address of the slave controller
+- 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:
+  Tegra20/Tegra30:
+  - div-clk
+  - fast-clk
+  Tegra114:
+  - div-clk
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - i2c
diff --git a/Documentation/devicetree/bindings/panel/auo,b101aw03.txt b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
new file mode 100644
index 000000000000..72e088a4fb3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/auo,b101aw03.txt
@@ -0,0 +1,7 @@
+AU Optronics Corporation 10.1" WSVGA TFT LCD panel
+Required properties:
+- compatible: should be "auo,b101aw03"
+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/chunghwa,claa101wa01a.txt b/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt
new file mode 100644
index 000000000000..f24614e4d5ec
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wa01a.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+Required properties:
+- compatible: should be "chunghwa,claa101wa01a"
+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/chunghwa,claa101wb03.txt b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
new file mode 100644
index 000000000000..0ab2c05a4c22
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/chunghwa,claa101wb03.txt
@@ -0,0 +1,7 @@
+Chunghwa Picture Tubes Ltd. 10.1" WXGA TFT LCD panel
+Required properties:
+- compatible: should be "chunghwa,claa101wb03"
+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/panasonic,vvx10f004b00.txt b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
new file mode 100644
index 000000000000..d328b0341bf4
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/panasonic,vvx10f004b00.txt
@@ -0,0 +1,7 @@
+Panasonic Corporation 10.1" WUXGA TFT LCD panel
+Required properties:
+- compatible: should be "panasonic,vvx10f004b00"
+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/samsung,ltn101nt05.txt b/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt
new file mode 100644
index 000000000000..ef522c6bb85f
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/samsung,ltn101nt05.txt
@@ -0,0 +1,7 @@
+Samsung Electronics 10.1" WSVGA TFT LCD panel
+Required properties:
+- compatible: should be "samsung,ltn101nt05"
+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/simple-panel.txt b/Documentation/devicetree/bindings/panel/simple-panel.txt
new file mode 100644
index 000000000000..1341bbf4aa3d
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/simple-panel.txt
@@ -0,0 +1,21 @@
+Simple display panel
+Required properties:
+- power-supply: regulator to provide the supply voltage
+Optional properties:
+- ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+- enable-gpios: GPIO pin to enable or disable the panel
+- backlight: phandle of the backlight device attached to the panel
+Example:
+        panel: panel {
+                compatible = "cptt,claa101wb01";
+                ddc-i2c-bus = <&panelddc>;
+                power-supply = <&vdd_pnl_reg>;
+                enable-gpios = <&gpio 90 0>;
+                backlight = <&backlight>;
+        };
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index d5d26d443693..d6fae13ff062 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -19,6 +19,8 @@ Required properties:
        to define the mapping of the PCIe interface to interrupt
        numbers.
 - num-lanes: number of lanes to use
+Optional properties:
 - reset-gpio: gpio pin number of power good signal
 Optional properties for fsl,imx6q-pcie
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
index 6b7510775c50..24cee06915c9 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -42,14 +42,19 @@ Required properties:
    - 0xc2000000: prefetchable memory region
  Please refer to the standard PCI bus binding document for a more detailed
  explanation.
- clocks: List of clock inputs of the controller. Must contain an entry for
+- clocks: Must contain an entry for each entry in clock-names.
-  each entry in the clock-names property.
+  See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
-  "pex": The Tegra clock of that name
+  - pex
-  "afi": The Tegra clock of that name
+  - afi
-  "pcie_xclk": The Tegra clock of that name
+  - pll_e
-  "pll_e": The Tegra clock of that name
+  - cml (not required for Tegra20)
-  "cml": The Tegra clock of that name (not required for Tegra20)
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - pex
+  - afi
+  - pcie_x
 Root ports are defined as subnodes of the PCIe controller node.
@@ -91,9 +96,10 @@ SoC DTSI:
                          0x82000000 0 0xa0000000 0xa0000000 0 0x10000000   /* non-prefetchable memory */
                          0xc2000000 0 0xb0000000 0xb0000000 0 0x10000000>; /* prefetchable memory */
-                clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>,
+                clocks = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 118>;
-                         <&tegra_car 118>;
+                clock-names = "pex", "afi", "pll_e";
-                clock-names = "pex", "afi", "pcie_xclk", "pll_e";
+                resets = <&tegra_car 70>, <&tegra_car 72>, <&tegra_car 74>;
+                reset-names = "pex", "afi", "pcie_x";
                status = "disabled";
                pci@1,0 {
diff --git a/Documentation/devicetree/bindings/phy/bcm-phy.txt b/Documentation/devicetree/bindings/phy/bcm-phy.txt
new file mode 100644
index 000000000000..3dc8b3d2ffbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - reg: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+Example:
+        usbphy: usb-phy@3f130000 {
+                compatible = "brcm,kona-usb2-phy";
+                reg = <0x3f130000 0x28>;
+                #phy-cells = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt
new file mode 100644
index 000000000000..9e9e9ef9f852
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,capri-pinctrl.txt
@@ -0,0 +1,461 @@
+Broadcom Capri Pin Controller
+This is a pin controller for the Broadcom BCM281xx SoC family, which includes
+BCM11130, BCM11140, BCM11351, BCM28145, and BCM28155 SoCs.
+=== Pin Controller Node ===
+Required Properties:
+- compatible:   Must be "brcm,capri-pinctrl".
+- reg:          Base address of the PAD Controller register block and the size
+                of the block.
+For example, the following is the bare minimum node:
+        pinctrl@35004800 {
+                compatible = "brcm,capri-pinctrl";
+                reg = <0x35004800 0x430>;
+        };
+As a pin controller device, in addition to the required properties, this node
+should also contain the pin configuration nodes that client devices reference,
+if any.
+=== Pin Configuration Node ===
+Each pin configuration node is a sub-node of the pin controller node and is a
+container of an arbitrary number of subnodes, called pin group nodes in this
+document.
+Please refer to the pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the definition of a
+"pin configuration node".
+=== Pin Group Node ===
+A pin group node specifies the desired pin mux and/or pin configuration for an
+arbitrary number of pins.  The name of the pin group node is optional and not
+used.
+A pin group node only affects the properties specified in the node, and has no
+effect on any properties that are omitted.
+The pin group node accepts a subset of the generic pin config properties. For
+details generic pin config properties, please refer to pinctrl-bindings.txt
+and <include/linux/pinctrl/pinconfig-generic.h>.
+Each pin controlled by this pin controller belong to one of three types:
+Standard, I2C, and HDMI.  Each type accepts a different set of pin config
+properties.  A list of pins and their types is provided below.
+Required Properties (applicable to all pins):
+- pins:         Multiple strings.  Specifies the name(s) of one or more pins to
+                be configured by this node.
+Optional Properties (for standard pins):
+- function:                     String. Specifies the pin mux selection. Values
+                                must be one of: "alt1", "alt2", "alt3", "alt4"
+- input-schmitt-enable:         No arguments. Enable schmitt-trigger mode.
+- input-schmitt-disable:        No arguments. Disable schmitt-trigger mode.
+- bias-pull-up:                 No arguments. Pull up on pin.
+- bias-pull-down:               No arguments. Pull down on pin.
+- bias-disable:                 No arguments. Disable pin bias.
+- slew-rate:                    Integer. Meaning depends on configured pin mux:
+                                *_SCL or *_SDA:
+                                        0: Standard(100kbps)& Fast(400kbps) mode
+                                        1: Highspeed (3.4Mbps) mode
+                                IC_DM or IC_DP:
+                                        0: normal slew rate
+                                        1: fast slew rate
+                                Otherwise:
+                                        0: fast slew rate
+                                        1: normal slew rate
+- input-enable:                 No arguements. Enable input (does not affect
+                                output.)
+- input-disable:                No arguements. 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.
+Optional Properties (for I2C pins):
+- function:                     String. Specifies the pin mux selection. Values
+                                must be one of: "alt1", "alt2", "alt3", "alt4"
+- bias-pull-up:                 Integer. Pull up strength in Ohm. There are 3
+                                pull-up resisitors (1.2k, 1.8k, 2.7k) available
+                                in parallel for I2C pins, so the valid values
+                                are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm.
+- bias-disable:                 No arguments. Disable pin bias.
+- slew-rate:                    Integer. Meaning depends on configured pin mux:
+                                *_SCL or *_SDA:
+                                        0: Standard(100kbps)& Fast(400kbps) mode
+                                        1: Highspeed (3.4Mbps) mode
+                                IC_DM or IC_DP:
+                                        0: normal slew rate
+                                        1: fast slew rate
+                                Otherwise:
+                                        0: fast slew rate
+                                        1: normal slew rate
+- input-enable:                 No arguements. Enable input (does not affect
+                                output.)
+- input-disable:                No arguements. Disable input (does not affect
+                                output.)
+Optional Properties (for HDMI pins):
+- function:                     String. Specifies the pin mux selection. Values
+                                must be one of: "alt1", "alt2", "alt3", "alt4"
+- 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
+                                output.)
+- input-disable:                No arguements. Disable input (does not affect
+                                output.)
+Example:
+// pin controller node
+pinctrl@35004800 {
+        compatible = "brcm,capri-pinctrl";
+        reg = <0x35004800 0x430>;
+        // pin configuration node
+        dev_a_default: dev_a_active {
+                //group node defining 1 standard pin
+                grp_1 {
+                        pins            = "std_pin1";
+                        function        = "alt1";
+                        input-schmitt-enable;
+                        bias-disable;
+                        slew-rate       = <1>;
+                        drive-strength  = <4>;
+                };
+                // group node defining 2 I2C pins
+                grp_2 {
+                        pins            = "i2c_pin1", "i2c_pin2";
+                        function        = "alt2";
+                        bias-pull-up    = <720>;
+                        input-enable;
+                };
+                // group node defining 2 HDMI pins
+                grp_3 {
+                        pins            = "hdmi_pin1", "hdmi_pin2";
+                        function        = "alt3";
+                        slew-rate       = <1>;
+                };
+                // other pin group nodes
+                ...
+        };
+        // other pin configuration nodes
+        ...
+};
+In the example above, "dev_a_active" is a pin configuration node with a number
+of sub-nodes.  In the pin group node "grp_1", one pin, "std_pin1", is defined in
+the "pins" property.  Thus, the remaining properties in the "grp_1" node applies
+only to this pin, including the following settings:
+ - setting pinmux to "alt1"
+ - enabling schmitt-trigger (hystersis) mode
+ - disabling pin bias
+ - setting the slew-rate to 1
+ - setting the drive strength to 4 mA
+Note that neither "input-enable" nor "input-disable" was specified - the pinctrl
+subsystem will therefore leave this property unchanged from whatever state it
+was in before applying these changes.
+The "pins" property in the pin group node "grp_2" specifies two pins -
+"i2c_pin1" and "i2c_pin2"; the remaining properties in this pin group node,
+therefore, applies to both of these pins.  The properties include:
+ - setting pinmux to "alt2"
+ - setting pull-up resistance to 720 Ohm (ie. enabling 1.2k and 1.8k resistors
+   in parallel)
+ - enabling both pins' input
+"slew-rate" is not specified in this pin group node, so the slew-rate for these
+pins are left as-is.
+Finally, "grp_3" defines two HDMI pins.  The following properties are applied to
+both pins:
+ - setting pinmux to "alt3"
+ - setting slew-rate to 1; for HDMI pins, this corresponds to the 3.4 Mbps
+   Highspeed mode
+The input is neither enabled or disabled, and is left untouched.
+=== Pin Names and Type ===
+The following are valid pin names and their pin types:
+        "adcsync",              Standard
+        "bat_rm",               Standard
+        "bsc1_scl",             I2C
+        "bsc1_sda",             I2C
+        "bsc2_scl",             I2C
+        "bsc2_sda",             I2C
+        "classgpwr",            Standard
+        "clk_cx8",              Standard
+        "clkout_0",             Standard
+        "clkout_1",             Standard
+        "clkout_2",             Standard
+        "clkout_3",             Standard
+        "clkreq_in_0",          Standard
+        "clkreq_in_1",          Standard
+        "cws_sys_req1",         Standard
+        "cws_sys_req2",         Standard
+        "cws_sys_req3",         Standard
+        "digmic1_clk",          Standard
+        "digmic1_dq",           Standard
+        "digmic2_clk",          Standard
+        "digmic2_dq",           Standard
+        "gpen13",               Standard
+        "gpen14",               Standard
+        "gpen15",               Standard
+        "gpio00",               Standard
+        "gpio01",               Standard
+        "gpio02",               Standard
+        "gpio03",               Standard
+        "gpio04",               Standard
+        "gpio05",               Standard
+        "gpio06",               Standard
+        "gpio07",               Standard
+        "gpio08",               Standard
+        "gpio09",               Standard
+        "gpio10",               Standard
+        "gpio11",               Standard
+        "gpio12",               Standard
+        "gpio13",               Standard
+        "gpio14",               Standard
+        "gps_pablank",          Standard
+        "gps_tmark",            Standard
+        "hdmi_scl",             HDMI
+        "hdmi_sda",             HDMI
+        "ic_dm",                Standard
+        "ic_dp",                Standard
+        "kp_col_ip_0",          Standard
+        "kp_col_ip_1",          Standard
+        "kp_col_ip_2",          Standard
+        "kp_col_ip_3",          Standard
+        "kp_row_op_0",          Standard
+        "kp_row_op_1",          Standard
+        "kp_row_op_2",          Standard
+        "kp_row_op_3",          Standard
+        "lcd_b_0",              Standard
+        "lcd_b_1",              Standard
+        "lcd_b_2",              Standard
+        "lcd_b_3",              Standard
+        "lcd_b_4",              Standard
+        "lcd_b_5",              Standard
+        "lcd_b_6",              Standard
+        "lcd_b_7",              Standard
+        "lcd_g_0",              Standard
+        "lcd_g_1",              Standard
+        "lcd_g_2",              Standard
+        "lcd_g_3",              Standard
+        "lcd_g_4",              Standard
+        "lcd_g_5",              Standard
+        "lcd_g_6",              Standard
+        "lcd_g_7",              Standard
+        "lcd_hsync",            Standard
+        "lcd_oe",               Standard
+        "lcd_pclk",             Standard
+        "lcd_r_0",              Standard
+        "lcd_r_1",              Standard
+        "lcd_r_2",              Standard
+        "lcd_r_3",              Standard
+        "lcd_r_4",              Standard
+        "lcd_r_5",              Standard
+        "lcd_r_6",              Standard
+        "lcd_r_7",              Standard
+        "lcd_vsync",            Standard
+        "mdmgpio0",             Standard
+        "mdmgpio1",             Standard
+        "mdmgpio2",             Standard
+        "mdmgpio3",             Standard
+        "mdmgpio4",             Standard
+        "mdmgpio5",             Standard
+        "mdmgpio6",             Standard
+        "mdmgpio7",             Standard
+        "mdmgpio8",             Standard
+        "mphi_data_0",          Standard
+        "mphi_data_1",          Standard
+        "mphi_data_2",          Standard
+        "mphi_data_3",          Standard
+        "mphi_data_4",          Standard
+        "mphi_data_5",          Standard
+        "mphi_data_6",          Standard
+        "mphi_data_7",          Standard
+        "mphi_data_8",          Standard
+        "mphi_data_9",          Standard
+        "mphi_data_10",         Standard
+        "mphi_data_11",         Standard
+        "mphi_data_12",         Standard
+        "mphi_data_13",         Standard
+        "mphi_data_14",         Standard
+        "mphi_data_15",         Standard
+        "mphi_ha0",             Standard
+        "mphi_hat0",            Standard
+        "mphi_hat1",            Standard
+        "mphi_hce0_n",          Standard
+        "mphi_hce1_n",          Standard
+        "mphi_hrd_n",           Standard
+        "mphi_hwr_n",           Standard
+        "mphi_run0",            Standard
+        "mphi_run1",            Standard
+        "mtx_scan_clk",         Standard
+        "mtx_scan_data",        Standard
+        "nand_ad_0",            Standard
+        "nand_ad_1",            Standard
+        "nand_ad_2",            Standard
+        "nand_ad_3",            Standard
+        "nand_ad_4",            Standard
+        "nand_ad_5",            Standard
+        "nand_ad_6",            Standard
+        "nand_ad_7",            Standard
+        "nand_ale",             Standard
+        "nand_cen_0",           Standard
+        "nand_cen_1",           Standard
+        "nand_cle",             Standard
+        "nand_oen",             Standard
+        "nand_rdy_0",           Standard
+        "nand_rdy_1",           Standard
+        "nand_wen",             Standard
+        "nand_wp",              Standard
+        "pc1",                  Standard
+        "pc2",                  Standard
+        "pmu_int",              Standard
+        "pmu_scl",              I2C
+        "pmu_sda",              I2C
+        "rfst2g_mtsloten3g",    Standard
+        "rgmii_0_rx_ctl",       Standard
+        "rgmii_0_rxc",          Standard
+        "rgmii_0_rxd_0",        Standard
+        "rgmii_0_rxd_1",        Standard
+        "rgmii_0_rxd_2",        Standard
+        "rgmii_0_rxd_3",        Standard
+        "rgmii_0_tx_ctl",       Standard
+        "rgmii_0_txc",          Standard
+        "rgmii_0_txd_0",        Standard
+        "rgmii_0_txd_1",        Standard
+        "rgmii_0_txd_2",        Standard
+        "rgmii_0_txd_3",        Standard
+        "rgmii_1_rx_ctl",       Standard
+        "rgmii_1_rxc",          Standard
+        "rgmii_1_rxd_0",        Standard
+        "rgmii_1_rxd_1",        Standard
+        "rgmii_1_rxd_2",        Standard
+        "rgmii_1_rxd_3",        Standard
+        "rgmii_1_tx_ctl",       Standard
+        "rgmii_1_txc",          Standard
+        "rgmii_1_txd_0",        Standard
+        "rgmii_1_txd_1",        Standard
+        "rgmii_1_txd_2",        Standard
+        "rgmii_1_txd_3",        Standard
+        "rgmii_gpio_0",         Standard
+        "rgmii_gpio_1",         Standard
+        "rgmii_gpio_2",         Standard
+        "rgmii_gpio_3",         Standard
+        "rtxdata2g_txdata3g1",  Standard
+        "rtxen2g_txdata3g2",    Standard
+        "rxdata3g0",            Standard
+        "rxdata3g1",            Standard
+        "rxdata3g2",            Standard
+        "sdio1_clk",            Standard
+        "sdio1_cmd",            Standard
+        "sdio1_data_0",         Standard
+        "sdio1_data_1",         Standard
+        "sdio1_data_2",         Standard
+        "sdio1_data_3",         Standard
+        "sdio4_clk",            Standard
+        "sdio4_cmd",            Standard
+        "sdio4_data_0",         Standard
+        "sdio4_data_1",         Standard
+        "sdio4_data_2",         Standard
+        "sdio4_data_3",         Standard
+        "sim_clk",              Standard
+        "sim_data",             Standard
+        "sim_det",              Standard
+        "sim_resetn",           Standard
+        "sim2_clk",             Standard
+        "sim2_data",            Standard
+        "sim2_det",             Standard
+        "sim2_resetn",          Standard
+        "sri_c",                Standard
+        "sri_d",                Standard
+        "sri_e",                Standard
+        "ssp_extclk",           Standard
+        "ssp0_clk",             Standard
+        "ssp0_fs",              Standard
+        "ssp0_rxd",             Standard
+        "ssp0_txd",             Standard
+        "ssp2_clk",             Standard
+        "ssp2_fs_0",            Standard
+        "ssp2_fs_1",            Standard
+        "ssp2_fs_2",            Standard
+        "ssp2_fs_3",            Standard
+        "ssp2_rxd_0",           Standard
+        "ssp2_rxd_1",           Standard
+        "ssp2_txd_0",           Standard
+        "ssp2_txd_1",           Standard
+        "ssp3_clk",             Standard
+        "ssp3_fs",              Standard
+        "ssp3_rxd",             Standard
+        "ssp3_txd",             Standard
+        "ssp4_clk",             Standard
+        "ssp4_fs",              Standard
+        "ssp4_rxd",             Standard
+        "ssp4_txd",             Standard
+        "ssp5_clk",             Standard
+        "ssp5_fs",              Standard
+        "ssp5_rxd",             Standard
+        "ssp5_txd",             Standard
+        "ssp6_clk",             Standard
+        "ssp6_fs",              Standard
+        "ssp6_rxd",             Standard
+        "ssp6_txd",             Standard
+        "stat_1",               Standard
+        "stat_2",               Standard
+        "sysclken",             Standard
+        "traceclk",             Standard
+        "tracedt00",            Standard
+        "tracedt01",            Standard
+        "tracedt02",            Standard
+        "tracedt03",            Standard
+        "tracedt04",            Standard
+        "tracedt05",            Standard
+        "tracedt06",            Standard
+        "tracedt07",            Standard
+        "tracedt08",            Standard
+        "tracedt09",            Standard
+        "tracedt10",            Standard
+        "tracedt11",            Standard
+        "tracedt12",            Standard
+        "tracedt13",            Standard
+        "tracedt14",            Standard
+        "tracedt15",            Standard
+        "txdata3g0",            Standard
+        "txpwrind",             Standard
+        "uartb1_ucts",          Standard
+        "uartb1_urts",          Standard
+        "uartb1_urxd",          Standard
+        "uartb1_utxd",          Standard
+        "uartb2_urxd",          Standard
+        "uartb2_utxd",          Standard
+        "uartb3_ucts",          Standard
+        "uartb3_urts",          Standard
+        "uartb3_urxd",          Standard
+        "uartb3_utxd",          Standard
+        "uartb4_ucts",          Standard
+        "uartb4_urts",          Standard
+        "uartb4_urxd",          Standard
+        "uartb4_utxd",          Standard
+        "vc_cam1_scl",          I2C
+        "vc_cam1_sda",          I2C
+        "vc_cam2_scl",          I2C
+        "vc_cam2_sda",          I2C
+        "vc_cam3_scl",          I2C
+        "vc_cam3_sda",          I2C
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt
new file mode 100644
index 000000000000..fd653bde18d5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx25-pinctrl.txt
@@ -0,0 +1,23 @@
+* Freescale IMX25 IOMUX Controller
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+CONFIG bits definition:
+PAD_CTL_HYS                     (1 << 8)
+PAD_CTL_PKE                     (1 << 7)
+PAD_CTL_PUE                     (1 << 6)
+PAD_CTL_PUS_100K_DOWN           (0 << 4)
+PAD_CTL_PUS_47K_UP              (1 << 4)
+PAD_CTL_PUS_100K_UP             (2 << 4)
+PAD_CTL_PUS_22K_UP              (3 << 4)
+PAD_CTL_ODE_CMOS                (0 << 3)
+PAD_CTL_ODE_OPENDRAIN           (1 << 3)
+PAD_CTL_DSE_NOMINAL             (0 << 1)
+PAD_CTL_DSE_HIGH                (1 << 1)
+PAD_CTL_DSE_MAX                 (2 << 1)
+PAD_CTL_SRE_FAST                (1 << 0)
+PAD_CTL_SRE_SLOW                (0 << 0)
+Refer to imx25-pinfunc.h in device tree source folder for all available
+imx25 PIN_FUNC_ID.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt
index 353eca0efbf8..d1706ea82572 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt
@@ -52,12 +52,25 @@ Required properties for pin configuration node:
  CONFIG can be 0 or 1, meaning Pullup disable/enable.
+The iomux controller has gpio child nodes which are embedded in the iomux
+control registers. They have to be defined as child nodes of the iomux device
+node. If gpio subnodes are defined "#address-cells", "#size-cells" and "ranges"
+properties for the iomux device node are required.
 Example:
 iomuxc: iomuxc@10015000 {
        compatible = "fsl,imx27-iomuxc";
        reg = <0x10015000 0x600>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        gpio1: gpio@10015000 {
+                ...
+        };
+        ...
        uart {
                pinctrl_uart1: uart-1 {
@@ -83,6 +96,15 @@ The above example using macros:
 iomuxc: iomuxc@10015000 {
        compatible = "fsl,imx27-iomuxc";
        reg = <0x10015000 0x600>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        gpio1: gpio@10015000 {
+                ...
+        };
+        ...
        uart {
                pinctrl_uart1: uart-1 {
diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
new file mode 100644
index 000000000000..6464bf769460
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
@@ -0,0 +1,144 @@
+NVIDIA Tegra124 pinmux controller
+The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30
+pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
+nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
+a baseline, and only documents the differences between the two bindings.
+Required properties:
+- compatible: "nvidia,tegra124-pinmux"
+- reg: Should contain a list of base address and size pairs for:
+    -- first entry - the drive strength and pad control registers.
+    -- second entry - the pinmux registers
+Tegra124 adds the following optional properties for pin configuration subnodes.
+The macros for options are defined in the
+        include/dt-binding/pinctrl/pinctrl-tegra.h.
+- nvidia,enable-input: Integer. Enable the pin's input path.
+                enable :TEGRA_PIN_ENABLE0 and
+                disable or output only: TEGRA_PIN_DISABLE.
+- nvidia,open-drain: Integer.
+                enable: TEGRA_PIN_ENABLE.
+                disable: TEGRA_PIN_DISABLE.
+- nvidia,lock: Integer. Lock the pin configuration against further changes
+    until reset.
+                enable: TEGRA_PIN_ENABLE.
+                disable: TEGRA_PIN_DISABLE.
+- nvidia,io-reset: Integer. Reset the IO path.
+                enable: TEGRA_PIN_ENABLE.
+                disable: TEGRA_PIN_DISABLE.
+- nvidia,rcv-sel: Integer. Select VIL/VIH receivers.
+                normal: TEGRA_PIN_DISABLE
+                high: TEGRA_PIN_ENABLE
+Please refer the Tegra TRM for complete details regarding which groups
+support which functionality.
+Valid values for pin and group names are:
+  per-pin mux groups:
+    These all support nvidia,function, nvidia,tristate, nvidia,pull,
+    nvidia,enable-input. Some support nvidia,lock nvidia,open-drain,
+    nvidia,io-reset and nvidia,rcv-sel.
+        ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
+        ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
+        ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
+        dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
+        sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
+        sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
+        ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
+        uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
+        uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_scl_pc4,
+        gen1_i2c_sda_pc5, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6,
+        dap4_sclk_pp7, clk3_out_pee0, clk3_req_pee1, pc7, pi5, pi7, pk0, pk1,
+        pj0, pj2, pk3, pk4, pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6,
+        pg7, ph0, ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0,
+        pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, sdmmc4_clk_pcc4,
+        sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, sdmmc4_dat2_paa2,
+        sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6,
+        sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, cam_i2c_scl_pbb1,
+        cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, pcc2, jtag_rtck,
+        pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2,
+        kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7,
+        kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4,
+        kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, kb_col0_pq0, kb_col1_pq1,
+        kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, kb_col6_pq6,
+        kb_col7_pq7, clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n,
+        clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
+        dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, spdif_in_pk6,
+        spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3,
+        dvfs_pwm_px0, gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2,
+        gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7,
+        sdmmc3_clk_pa6, sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6,
+        sdmmc3_dat2_pb5, sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1,
+        pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3, pex_l1_rst_n_pdd5,
+        pex_l1_clkreq_n_pdd6, hdmi_cec_pee3, sdmmc1_wp_n_pv3,
+        sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4,
+        usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4, sdmmc3_clk_lb_in_pee5,
+        gmi_clk_lb, reset_out_n, kb_row16_pt0, kb_row17_pt1, usb_vbus_en2_pff1,
+        pff2, dp_hpd_pff0,
+  drive groups:
+    These all support nvidia,pull-down-strength, nvidia,pull-up-strength,
+    nvidia,slew-rate-rising, nvidia,slew-rate-falling. Most but not all
+    support nvidia,high-speed-mode, nvidia,schmitt, nvidia,low-power-mode
+    and nvidia,drive-type.
+    ao1, ao2, at1, at2, at3, at4, at5, cdev1, cdev2, dap1, dap2, dap3, dap4,
+    dbg, sdio3, spi, uaa, uab, uart2, uart3, sdio1, ddc, gma, gme, gmf, gmg,
+    gmh, owr, uda, gpv, dev3, cec, usb_vbus_en, ao3, ao0, hv0, sdio4, ao4.
+Valid values for nvidia,functions are:
+  blink, cec, cldvfs, clk12, cpu, dap, dap1, dap2, dev3, displaya,
+  displaya_alt, displayb, dtv, extperiph1, extperiph2, extperiph3,
+  gmi, gmi_alt, hda, hsi, i2c1, i2c2, i2c3, i2c4, i2cpwr, i2s0,
+  i2s1, i2s2, i2s3, i2s4, irda, kbc, owr, pmi, pwm0, pwm1, pwm2, pwm3,
+  pwron, reset_out_n, rsvd1, rsvd2, rsvd3, rsvd4, sdmmc1, sdmmc2, sdmmc3,
+  sdmmc4, soc, spdif, spi1, spi2, spi3, spi4, spi5, spi6, trace, uarta,
+  uartb, uartc, uartd, ulpi, usb, vgp1, vgp2, vgp3, vgp4, vgp5, vgp6,
+  vi, vi_alt1, vi_alt3, vimclk2, vimclk2_alt, sata, ccla, pe0, pe, pe1,
+  dp, rtck, sys, clk tmds.
+Example:
+        pinmux: pinmux {
+                compatible = "nvidia,tegra124-pinmux";
+                reg = <0x70000868 0x164         /* Pad control registers */
+                       0x70003000 0x434>;       /* PinMux registers */
+        };
+Example pinmux entries:
+        pinctrl {
+                sdmmc4_default: pinmux {
+                        sdmmc4_clk_pcc4 {
+                                nvidia,pins = "sdmmc4_clk_pcc4",
+                                nvidia,function = "sdmmc4";
+                                nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+                                nvidia,tristate = <TEGRA_PIN_DISABLE>;
+                        };
+                        sdmmc4_dat0_paa0 {
+                                nvidia,pins = "sdmmc4_dat0_paa0",
+                                                "sdmmc4_dat1_paa1",
+                                                "sdmmc4_dat2_paa2",
+                                                "sdmmc4_dat3_paa3",
+                                                "sdmmc4_dat4_paa4",
+                                                "sdmmc4_dat5_paa5",
+                                                "sdmmc4_dat6_paa6",
+                                                "sdmmc4_dat7_paa7";
+                                nvidia,function = "sdmmc4";
+                                nvidia,pull = <TEGRA_PIN_PULL_UP>;
+                                nvidia,tristate = <TEGRA_PIN_DISABLE>;
+                        };
+                };
+        };
+        sdhci@78000400 {
+                pinctrl-names = "default";
+                pinctrl-0 = <&sdmmc4_default>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index 1958ca9f9e5c..4414163e76d2 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -151,6 +151,8 @@ drive-push-pull		- drive actively high and low
 drive-open-drain        - drive with open drain
 drive-open-source       - drive with open source
 drive-strength          - sink or source at most X mA
+input-enable            - enable input on pin (no effect on output)
+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
@@ -158,6 +160,7 @@ 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
 output-high             - set the pin to output mode with high level
+slew-rate               - set the slew rate
 Some of the generic properties take arguments. For those that do, the
 arguments are described below.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 7069a0b84e3a..bc0dfdfdb148 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -98,7 +98,7 @@ below for more information.
 In case when one register changes more than one pin's mux the
 pinctrl-single,bits need to be used which takes three parameters:
-        pinctrl-single,bits = <0xdc 0x18, 0xff>;
+        pinctrl-single,bits = <0xdc 0x18 0xff>;
 Where 0xdc is the offset from the pinctrl register base address for the
 device pinctrl register, 0x18 is the desired value, and 0xff is the sub mask to
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
new file mode 100644
index 000000000000..4c352be5dd61
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
@@ -0,0 +1,92 @@
+Qualcomm MSM8974 TLMM block
+Required properties:
+- compatible: "qcom,msm8x74-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.
+Non-empty subnodes must specify the 'pins' property.
+Note that not all properties are valid for all pins.
+Valid values for qcom,pins are:
+  gpio0-gpio145
+    Supports mux, bias and drive-strength
+  sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data
+    Supports bias and drive-strength
+Valid values for qcom,function are:
+  blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus
+  (Note that this is not yet the complete list of functions)
+Example:
+        msmgpio: pinctrl@fd510000 {
+                compatible = "qcom,msm8974-pinctrl";
+                reg = <0xfd510000 0x4000>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                interrupts = <0 208 0>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&uart2_default>;
+                uart2_default: uart2_default {
+                        mux {
+                                qcom,pins = "gpio4", "gpio5";
+                                qcom,function = "blsp_uart2";
+                        };
+                        tx {
+                                qcom,pins = "gpio4";
+                                drive-strength = <4>;
+                                bias-disable;
+                        };
+                        rx {
+                                qcom,pins = "gpio5";
+                                drive-strength = <2>;
+                                bias-pull-up;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
index d5dac7b843a9..35d2e1f186f0 100644
--- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -26,6 +26,11 @@ Optional properties:
  - #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden
    otherwise. Should be 3.
+  - interrupts-extended: Specify the interrupts associated with external
+    IRQ pins. This property is mandatory when the PFC handles GPIOs and
+    forbidden otherwise. When specified, it must contain one interrupt per
+    external IRQ, sorted by external IRQ number.
 The PFC node also acts as a container for pin configuration nodes. Please refer
 to pinctrl-bindings.txt in this directory for the definition of the term "pin
 configuration node" and for the common pinctrl bindings used by client devices.
@@ -103,6 +108,15 @@ Example 1: SH73A0 (SH-Mobile AG5) pin controller node
                      <0xe605801c 0x1c>;
                gpio-controller;
                #gpio-cells = <2>;
+                interrupts-extended =
+                        <&irqpin0 0 0>, <&irqpin0 1 0>, <&irqpin0 2 0>, <&irqpin0 3 0>,
+                        <&irqpin0 4 0>, <&irqpin0 5 0>, <&irqpin0 6 0>, <&irqpin0 7 0>,
+                        <&irqpin1 0 0>, <&irqpin1 1 0>, <&irqpin1 2 0>, <&irqpin1 3 0>,
+                        <&irqpin1 4 0>, <&irqpin1 5 0>, <&irqpin1 6 0>, <&irqpin1 7 0>,
+                        <&irqpin2 0 0>, <&irqpin2 1 0>, <&irqpin2 2 0>, <&irqpin2 3 0>,
+                        <&irqpin2 4 0>, <&irqpin2 5 0>, <&irqpin2 6 0>, <&irqpin2 7 0>,
+                        <&irqpin3 0 0>, <&irqpin3 1 0>, <&irqpin3 2 0>, <&irqpin3 3 0>,
+                        <&irqpin3 4 0>, <&irqpin3 5 0>, <&irqpin3 6 0>, <&irqpin3 7 0>;
        };
 Example 2: A GPIO LED node that references a GPIO
diff --git a/Documentation/devicetree/bindings/power/isp1704.txt b/Documentation/devicetree/bindings/power/isp1704.txt
new file mode 100644
index 000000000000..fa3596907967
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/isp1704.txt
@@ -0,0 +1,17 @@
+Binding for NXP ISP1704 USB Charger Detection
+Required properties:
+- compatible: Should contain one of the following:
+ * "nxp,isp1704"
+- nxp,enable-gpio: Should contain a phandle + gpio-specifier
+  to the GPIO pin connected to the chip's enable pin.
+- usb-phy: Should contain a phandle to the USB PHY
+  the ISP1704 is connected to.
+Example:
+isp1704 {
+        compatible = "nxp,isp1704";
+        nxp,enable-gpio = <&gpio3 3 GPIO_ACTIVE_LOW>;
+        usb-phy = <&usb2_phy>;
+};
diff --git a/Documentation/devicetree/bindings/power_supply/charger-manager.txt b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
new file mode 100644
index 000000000000..2b33750e3db2
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/charger-manager.txt
@@ -0,0 +1,81 @@
+charger-manager bindings
+~~~~~~~~~~~~~~~~~~~~~~~~
+Required properties :
+ - compatible : "charger-manager"
+ - <>-supply : for regulator consumer
+ - cm-num-chargers : number of chargers
+ - cm-chargers : name of chargers
+ - cm-fuel-gauge : name of battery fuel gauge
+ - subnode <regulator> :
+        - cm-regulator-name : name of charger regulator
+        - subnode <cable> :
+                - cm-cable-name : name of charger cable
+                - cm-cable-extcon : name of extcon dev
+(optional)      - cm-cable-min : minimum current of cable
+(optional)      - cm-cable-max : maximum current of cable
+Optional properties :
+ - cm-name : charger manager's name (default : "battery")
+ - cm-poll-mode : polling mode (enum polling_modes)
+ - cm-poll-interval : polling interval
+ - cm-battery-stat : battery status (enum data_source)
+ - cm-fullbatt-* : data for full battery checking
+ - cm-thermal-zone : name of external thermometer's thermal zone
+ - cm-battery-* : threshold battery temperature for charging
+        -cold : critical cold temperature of battery for charging
+        -cold-in-minus : flag that cold temerature is in minus degree
+        -hot : critical hot temperature of battery for charging
+        -temp-diff : temperature difference to allow recharging
+ - cm-dis/charging-max = limits of charging duration
+Example :
+        charger-manager@0 {
+                compatible = "charger-manager";
+                chg-reg-supply = <&charger_regulator>;
+                cm-name = "battery";
+                /* Always polling ON : 30s */
+                cm-poll-mode = <1>;
+                cm-poll-interval = <30000>;
+                cm-fullbatt-vchkdrop-ms = <30000>;
+                cm-fullbatt-vchkdrop-volt = <150000>;
+                cm-fullbatt-soc = <100>;
+                cm-battery-stat = <3>;
+                cm-num-chargers = <3>;
+                cm-chargers = "charger0", "charger1", "charger2";
+                cm-fuel-gauge = "fuelgauge0";
+                cm-thermal-zone = "thermal_zone.1"
+                /* in deci centigrade */
+                cm-battery-cold = <50>;
+                cm-battery-cold-in-minus;
+                cm-battery-hot = <800>;
+                cm-battery-temp-diff = <100>;
+                /* Allow charging for 5hr */
+                cm-charging-max = <18000000>;
+                /* Allow discharging for 2hr */
+                cm-discharging-max = <7200000>;
+                regulator@0 {
+                        cm-regulator-name = "chg-reg";
+                        cable@0 {
+                                cm-cable-name = "USB";
+                                cm-cable-extcon = "extcon-dev.0";
+                                cm-cable-min = <475000>;
+                                cm-cable-max = <500000>;
+                        };
+                        cable@1 {
+                                cm-cable-name = "TA";
+                                cm-cable-extcon = "extcon-dev.0";
+                                cm-cable-min = <650000>;
+                                cm-cable-max = <675000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
index 0e4269446580..29b28b8f9a89 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/network.txt
@@ -10,7 +10,6 @@ Currently defined compatibles:
 Example:
        ethernet@11300 {
-                device_type = "network";
                compatible = "fsl,mpc8272-fcc-enet",
                             "fsl,cpm2-fcc-enet";
                reg = <11300 20 8400 100 11390 1>;
@@ -33,7 +32,6 @@ fsl,mdc-pin : pin of port C controlling mdio clock
 Example:
        mdio@10d40 {
-                device_type = "mdio";
                compatible = "fsl,mpc8272ads-mdio-bitbang",
                             "fsl,mpc8272-mdio-bitbang",
                             "fsl,cpm2-mdio-bitbang";
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt
index c5b43061db3a..ec6ee2e864a2 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/cpm_qe/qe/pincfg.txt
@@ -1,8 +1,6 @@
 * Pin configuration nodes
 Required properties:
- linux,phandle : phandle of this node; likely referenced by a QE
-  device.
 - pio-map : array of pin configurations.  Each pin is defined by 6
  integers.  The six numbers are respectively: port, pin, dir,
  open_drain, assignment, has_irq.
@@ -29,7 +27,6 @@ Required properties:
 Example:
     ucc_pin@01 {
-        linux,phandle = <140001>;
        pio-map = <
        /* port  pin  dir  open_drain  assignment  has_irq */
                0  3  1  0  1  0        /* TxD0 */
diff --git a/Documentation/devicetree/bindings/pwm/atmel-pwm.txt b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
new file mode 100644
index 000000000000..02331b904d4e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/atmel-pwm.txt
@@ -0,0 +1,33 @@
+Atmel PWM controller
+Required properties:
+  - compatible: should be one of:
+    - "atmel,at91sam9rl-pwm"
+    - "atmel,sama5d3-pwm"
+  - reg: physical base address and length of the controller's registers
+  - #pwm-cells: Should be 3. See pwm.txt in this directory for a
+    description of the cells format.
+Example:
+        pwm0: pwm@f8034000 {
+                compatible = "atmel,at91sam9rl-pwm";
+                reg = <0xf8034000 0x400>;
+                #pwm-cells = <3>;
+        };
+        pwmleds {
+                compatible = "pwm-leds";
+                d1 {
+                        label = "d1";
+                        pwms = <&pwm0 3 5000 0>
+                        max-brightness = <255>;
+                };
+                d2 {
+                        label = "d2";
+                        pwms = <&pwm0 1 5000 1>
+                        max-brightness = <255>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
index c3fc57af8772..c7ea9d4a988b 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
@@ -7,6 +7,12 @@ Required properties:
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: should be 2. See pwm.txt in this directory for a description of
  the cells format.
+- clocks: Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- resets: Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names: Must include the following entries:
+  - pwm
 Example:
@@ -14,4 +20,7 @@ Example:
                compatible = "nvidia,tegra20-pwm";
                reg = <0x7000a000 0x100>;
                #pwm-cells = <2>;
+                clocks = <&tegra_car 17>;
+                resets = <&tegra_car 17>;
+                reset-names = "pwm";
        };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
new file mode 100644
index 000000000000..7bd9d3b12ce1
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-lp3943.txt
@@ -0,0 +1,58 @@
+TI/National Semiconductor LP3943 PWM controller
+Required properties:
+  - compatible: "ti,lp3943-pwm"
+  - #pwm-cells: Should be 2. See pwm.txt in this directory for a
+                description of the cells format.
+                Note that this hardware limits the period length to the
+                range 6250~1600000.
+  - ti,pwm0 or ti,pwm1: Output pin number(s) for PWM channel 0 or 1.
+    0 = output 0
+    1 = output 1
+    .
+    .
+    15 = output 15
+Example:
+PWM 0 is for RGB LED brightness control
+PWM 1 is for brightness control of LP8557 backlight device
+&i2c3 {
+        lp3943@60 {
+                compatible = "ti,lp3943";
+                reg = <0x60>;
+                /*
+                 * PWM 0 : output 8, 9 and 10
+                 * PWM 1 : output 15
+                 */
+                pwm3943: pwm {
+                        compatible = "ti,lp3943-pwm";
+                        #pwm-cells = <2>;
+                        ti,pwm0 = <8 9 10>;
+                        ti,pwm1 = <15>;
+                };
+        };
+};
+/* LEDs control with PWM 0 of LP3943 */
+pwmleds {
+        compatible = "pwm-leds";
+        rgb {
+                label = "indi::rgb";
+                pwms = <&pwm3943 0 10000>;
+                max-brightness = <255>;
+        };
+};
+&i2c4 {
+        /* Backlight control with PWM 1 of LP3943 */
+        backlight@2c {
+                compatible = "ti,lp8557";
+                reg = <0x2c>;
+                pwms = <&pwm3943 1 10000>;
+                pwm-names = "lp8557";
+        };
+};
diff --git a/Documentation/devicetree/bindings/pwm/pxa-pwm.txt b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
new file mode 100644
index 000000000000..5ae9f1e3c338
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pxa-pwm.txt
@@ -0,0 +1,30 @@
+Marvell PWM controller
+Required properties:
+- compatible: should be one or more of:
+  - "marvell,pxa250-pwm"
+  - "marvell,pxa270-pwm"
+  - "marvell,pxa168-pwm"
+  - "marvell,pxa910-pwm"
+- reg: Physical base address and length of the registers used by the PWM channel
+  Note that one device instance must be created for each PWM that is used, so the
+  length covers only the register window for one PWM output, not that of the
+  entire PWM controller.  Currently length is 0x10 for all supported devices.
+- #pwm-cells: Should be 1.  This cell is used to specify the period in
+  nanoseconds.
+Example PWM device node:
+pwm0: pwm@40b00000 {
+        compatible = "marvell,pxa250-pwm";
+        reg = <0x40b00000 0x10>;
+        #pwm-cells = <1>;
+};
+Example PWM client node:
+backlight {
+        compatible = "pwm-backlight";
+        pwms = <&pwm0 5000000>;
+        ...
+}
diff --git a/Documentation/devicetree/bindings/regulator/act8865-regulator.txt b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
new file mode 100644
index 000000000000..bef1fbb647ca
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/act8865-regulator.txt
@@ -0,0 +1,60 @@
+ACT8865 regulator
+-------------------
+Required properties:
+- compatible: "active-semi,act8865"
+- reg: I2C slave address
+Any standard regulator properties can be used to configure the single regulator.
+The valid names for regulators are:
+        DCDC_REG1, DCDC_REG2, DCDC_REG3, LDO_REG1, LDO_REG2, LDO_REG3, LDO_REG4.
+Example:
+--------
+                i2c1: i2c@f0018000 {
+                        pmic: act8865@5b {
+                                compatible = "active-semi,act8865";
+                                reg = <0x5b>;
+                                status = "disabled";
+                                regulators {
+                                        vcc_1v8_reg: DCDC_REG1 {
+                                                regulator-name = "VCC_1V8";
+                                                regulator-min-microvolt = <1800000>;
+                                                regulator-max-microvolt = <1800000>;
+                                                regulator-always-on;
+                                        };
+                                        vcc_1v2_reg: DCDC_REG2 {
+                                                regulator-name = "VCC_1V2";
+                                                regulator-min-microvolt = <1100000>;
+                                                regulator-max-microvolt = <1300000>;
+                                                regulator-suspend-mem-microvolt = <1150000>;
+                                                regulator-suspend-standby-microvolt = <1150000>;
+                                                regulator-always-on;
+                                        };
+                                        vcc_3v3_reg: DCDC_REG3 {
+                                                regulator-name = "VCC_3V3";
+                                                regulator-min-microvolt = <3300000>;
+                                                regulator-max-microvolt = <3300000>;
+                                                regulator-always-on;
+                                        };
+                                        vddana_reg: LDO_REG1 {
+                                                regulator-name = "VDDANA";
+                                                regulator-min-microvolt = <3300000>;
+                                                regulator-max-microvolt = <3300000>;
+                                                regulator-always-on;
+                                        };
+                                        vddfuse_reg: LDO_REG2 {
+                                                regulator-name = "FUSE_2V5";
+                                                regulator-min-microvolt = <2500000>;
+                                                regulator-max-microvolt = <2500000>;
+                                        };
+                                };
+                        };
+                };
diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
index d1660a90fc06..fc6b38f035bd 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -83,7 +83,7 @@ as per the datasheet of s5m8767.
        - LDOn
                  - valid values for n are 1 to 28
-                  - Example: LDO0, LD01, LDO28
+                  - Example: LDO1, LD02, LDO28
        - BUCKn
                  - valid values for n are 1 to 9.
                  - Example: BUCK1, BUCK2, BUCK9
diff --git a/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
new file mode 100644
index 000000000000..31406fd4a43e
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/haoyu,hym8563.txt
@@ -0,0 +1,27 @@
+Haoyu Microelectronics HYM8563 Real Time Clock
+The HYM8563 provides basic rtc and alarm functionality
+as well as a clock output of up to 32kHz.
+Required properties:
+- compatible: should be: "haoyu,hym8563"
+- reg: i2c address
+- interrupts: rtc alarm/event interrupt
+- #clock-cells: the value should be 0
+Example:
+hym8563: hym8563@51 {
+        compatible = "haoyu,hym8563";
+        reg = <0x51>;
+        interrupts = <13 IRQ_TYPE_EDGE_FALLING>;
+        #clock-cells = <0>;
+};
+device {
+...
+        clocks = <&hym8563>;
+...
+};
diff --git a/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt b/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt
new file mode 100644
index 000000000000..d0f937c355b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/maxim,ds1742.txt
@@ -0,0 +1,12 @@
+* Maxim (Dallas) DS1742/DS1743 Real Time Clock
+Required properties:
+- compatible: Should contain "maxim,ds1742".
+- reg: Physical base address of the RTC and length of memory
+  mapped region.
+Example:
+        rtc: rtc@10000000 {
+                compatible = "maxim,ds1742";
+                reg = <0x10000000 0x800>;
+        };
diff --git a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt
index 93f45e9dce7c..652d1ff2e8be 100644
--- a/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/nvidia,tegra20-rtc.txt
@@ -9,6 +9,8 @@ Required properties:
 - compatible : should be "nvidia,tegra20-rtc".
 - reg : Specifies base physical address and size of the registers.
 - interrupts : A single interrupt specifier.
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
 Example:
@@ -16,4 +18,5 @@ timer {
        compatible = "nvidia,tegra20-rtc";
        reg = <0x7000e000 0x100>;
        interrupts = <0 2 0x04>;
+        clocks = <&tegra_car 4>;
 };
diff --git a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt
new file mode 100644
index 000000000000..7cb9dbf34878
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt
@@ -0,0 +1,17 @@
+* sun4i/sun7i Real Time Clock
+RTC controller for the Allwinner A10/A20
+Required properties:
+- compatible : Should be "allwinner,sun4i-rtc" or "allwinner,sun7i-a20-rtc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: IRQ line for the RTC.
+Example:
+rtc: rtc@01c20d00 {
+        compatible = "allwinner,sun4i-rtc";
+        reg = <0x01c20d00 0x20>;
+        interrupts = <24>;
+};
diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt
index 2191dcb9f1da..9c5d19ac935c 100644
--- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt
@@ -6,6 +6,9 @@ Required properties:
  additional mode or an USART new feature.
 - reg: Should contain registers location and length
 - interrupts: Should contain interrupt
+- clock-names: tuple listing input clock names.
+        Required elements: "usart"
+- clocks: phandles to input clocks.
 Optional properties:
 - atmel,use-dma-rx: use of PDC or DMA for receiving data
@@ -26,6 +29,8 @@ Example:
                compatible = "atmel,at91sam9260-usart";
                reg = <0xfff8c000 0x4000>;
                interrupts = <7>;
+                clocks = <&usart0_clk>;
+                clock-names = "usart";
                atmel,use-dma-rx;
                atmel,use-dma-tx;
        };
@@ -35,6 +40,8 @@ Example:
                compatible = "atmel,at91sam9260-usart";
                reg = <0xf001c000 0x100>;
                interrupts = <12 4 5>;
+                clocks = <&usart0_clk>;
+                clock-names = "usart";
                atmel,use-dma-rx;
                atmel,use-dma-tx;
                dmas = <&dma0 2 0x3>,
diff --git a/Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt b/Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt
new file mode 100644
index 000000000000..12f3cf834deb
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/cirrus,clps711x-uart.txt
@@ -0,0 +1,28 @@
+* Cirrus Logic CLPS711X Universal Asynchronous Receiver/Transmitter (UART)
+Required properties:
+- compatible: Should be "cirrus,clps711x-uart".
+- reg: Address and length of the register set for the device.
+- interrupts: Should contain UART TX and RX interrupt.
+- clocks: Should contain UART core clock number.
+- syscon: Phandle to SYSCON node, which contain UART control bits.
+Optional properties:
+- uart-use-ms: Indicate the UART has modem signal (DCD, DSR, CTS).
+Note: Each UART port should have an alias correctly numbered
+in "aliases" node.
+Example:
+        aliases {
+                serial0 = &uart1;
+        };
+        uart1: uart@80000480 {
+                compatible = "cirrus,clps711x-uart";
+                reg = <0x80000480 0x80>;
+                interrupts = <12 13>;
+                clocks = <&clks 11>;
+                syscon = <&syscon1>;
+                uart-use-ms;
+        };
diff --git a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
index 392a4493eebd..845850caf088 100644
--- a/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
+++ b/Documentation/devicetree/bindings/serial/nvidia,tegra20-hsuart.txt
@@ -4,8 +4,17 @@ Required properties:
 - compatible : should be "nvidia,tegra30-hsuart", "nvidia,tegra20-hsuart".
 - reg: Should contain UART controller registers location and length.
 - interrupts: Should contain UART controller interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+- clocks: Must contain one entry, for the module clock.
-  request selector for this UART controller.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - serial
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
 Optional properties:
 - nvidia,enable-modem-interrupt: Enable modem interrupts. Should be enable
@@ -18,7 +27,11 @@ serial@70006000 {
        reg = <0x70006000 0x40>;
        reg-shift = <2>;
        interrupts = <0 36 0x04>;
-        nvidia,dma-request-selector = <&apbdma 8>;
        nvidia,enable-modem-interrupt;
+        clocks = <&tegra_car 6>;
+        resets = <&tegra_car 6>;
+        reset-names = "serial";
+        dmas = <&apbdma 8>, <&apbdma 8>;
+        dma-names = "rx", "tx";
        status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
new file mode 100644
index 000000000000..f372cf29068d
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -0,0 +1,46 @@
+* Renesas SH-Mobile Serial Communication Interface
+Required properties:
+  - compatible: Must contain one of the following:
+    - "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.
+    - "renesas,hscif-r8a7790" for R8A7790 (R-Car H2) HSCIF compatible UART.
+    - "renesas,scif-r8a7791" for R8A7791 (R-Car M2) SCIF compatible UART.
+    - "renesas,scifa-r8a7791" for R8A7791 (R-Car M2) SCIFA compatible UART.
+    - "renesas,scifb-r8a7791" for R8A7791 (R-Car M2) SCIFB compatible UART.
+    - "renesas,hscif-r8a7791" for R8A7791 (R-Car M2) HSCIF compatible UART.
+    - "renesas,scif" for generic SCIF compatible UART.
+    - "renesas,scifa" for generic SCIFA compatible UART.
+    - "renesas,scifb" for generic SCIFB compatible UART.
+    - "renesas,hscif" for generic HSCIF compatible UART.
+    When compatible with the generic version, nodes must list the
+    SoC-specific version corresponding to the platform first followed by the
+    generic version.
+  - reg: Base address and length of the I/O registers used by the UART.
+  - interrupts: Must contain an interrupt-specifier for the SCIx interrupt.
+  - clocks: Must contain a phandle and clock-specifier pair for each entry
+    in clock-names.
+  - clock-names: Must contain "sci_ick" for the SCIx UART interface clock.
+Note: Each enabled SCIx UART should have an alias correctly numbered in the
+"aliases" node.
+Example:
+        aliases {
+                serial0 = &scifa0;
+        };
+        scifa0: serial@e6c40000 {
+                compatible = "renesas,scifa-r8a7790", "renesas,scifa-generic";
+                reg = <0 0xe6c40000 0 64>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&mstp2_clks R8A7790_CLK_SCIFA0>;
+                clock-names = "sci_ick";
+        };
diff --git a/Documentation/devicetree/bindings/serial/vt8500-uart.txt b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
new file mode 100644
index 000000000000..795c393d09c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
@@ -0,0 +1,26 @@
+* VIA VT8500 and WonderMedia WM8xxx UART Controller
+Required properties:
+- compatible: should be "via,vt8500-uart"
+- reg: base physical address of the controller and length of memory mapped
+        region.
+- interrupts: hardware interrupt number
+- clocks: shall be the input parent clock phandle for the clock. This should
+        be the 24Mhz reference clock.
+Aliases may be defined to ensure the correct ordering of the uarts.
+Example:
+        aliases {
+                serial0 = &uart0;
+        };
+        uart0: serial@d8200000 {
+                compatible = "via,vt8500-uart";
+                reg = <0xd8200000 0x1040>;
+                interrupts = <32>;
+                clocks = <&clkuart0>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/adi,axi-i2s.txt b/Documentation/devicetree/bindings/sound/adi,axi-i2s.txt
new file mode 100644
index 000000000000..5875ca459ed1
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,axi-i2s.txt
@@ -0,0 +1,31 @@
+ADI AXI-I2S controller
+Required properties:
+ - compatible : Must be "adi,axi-i2s-1.00.a"
+ - reg : Must contain I2S core's registers location and length
+ - clocks : Pairs of phandle and specifier referencing the controller's clocks.
+   The controller expects two clocks, the clock used for the AXI interface and
+   the clock used as the sampling rate reference clock sample.
+ - clock-names : "axi" for the clock to the AXI interface, "ref" for the sample
+   rate reference clock.
+ - dmas: Pairs of phandle and specifier for the DMA channels that are used by
+   the core. The core expects two dma channels, one for transmit and one for
+   receive.
+ - dma-names : "tx" for the transmit channel, "rx" for the receive channel.
+For more details on the 'dma', 'dma-names', 'clock' and 'clock-names' properties
+please check:
+        * resource-names.txt
+        * clock/clock-bindings.txt
+        * dma/dma.txt
+Example:
+        i2s: i2s@0x77600000 {
+                compatible = "adi,axi-i2s-1.00.a";
+                reg = <0x77600000 0x1000>;
+                clocks = <&clk 15>, <&audio_clock>;
+                clock-names = "axi", "ref";
+                dmas = <&ps7_dma 0>, <&ps7_dma 1>;
+                dma-names = "tx", "rx";
+        };
diff --git a/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt b/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt
new file mode 100644
index 000000000000..46f344965313
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,axi-spdif-tx.txt
@@ -0,0 +1,30 @@
+ADI AXI-SPDIF controller
+Required properties:
+ - compatible : Must be "adi,axi-spdif-1.00.a"
+ - reg : Must contain SPDIF core's registers location and length
+ - clocks : Pairs of phandle and specifier referencing the controller's clocks.
+   The controller expects two clocks, the clock used for the AXI interface and
+   the clock used as the sampling rate reference clock sample.
+ - clock-names: "axi" for the clock to the AXI interface, "ref" for the sample
+   rate reference clock.
+ - dmas: Pairs of phandle and specifier for the DMA channel that is used by
+   the core. The core expects one dma channel for transmit.
+ - dma-names : Must be "tx"
+For more details on the 'dma', 'dma-names', 'clock' and 'clock-names' properties
+please check:
+        * resource-names.txt
+        * clock/clock-bindings.txt
+        * dma/dma.txt
+Example:
+        spdif: spdif@0x77400000 {
+                compatible = "adi,axi-spdif-tx-1.00.a";
+                reg = <0x77600000 0x1000>;
+                clocks = <&clk 15>, <&audio_clock>;
+                clock-names = "axi", "ref";
+                dmas = <&ps7_dma 0>;
+                dma-names = "tx";
+        };
diff --git a/Documentation/devicetree/bindings/sound/bcm2835-i2s.txt b/Documentation/devicetree/bindings/sound/bcm2835-i2s.txt
new file mode 100644
index 000000000000..65783de0aedf
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/bcm2835-i2s.txt
@@ -0,0 +1,25 @@
+* Broadcom BCM2835 SoC I2S/PCM module
+Required properties:
+- compatible: "brcm,bcm2835-i2s"
+- reg: A list of base address and size entries:
+        * The first entry should cover the PCM registers
+        * The second entry should cover the PCM clock registers
+- dmas: List of DMA controller phandle and DMA request line ordered pairs.
+- dma-names: Identifier string for each DMA request line in the dmas property.
+  These strings correspond 1:1 with the ordered pairs in dmas.
+  One of the DMA channels will be responsible for transmission (should be
+  named "tx") and one for reception (should be named "rx").
+Example:
+bcm2835_i2s: i2s@7e203000 {
+        compatible = "brcm,bcm2835-i2s";
+        reg = <0x7e203000 0x20>,
+              <0x7e101098 0x02>;
+        dmas = <&dma 2>,
+               <&dma 3>;
+        dma-names = "tx", "rx";
+};
diff --git a/Documentation/devicetree/bindings/sound/cs42l52.txt b/Documentation/devicetree/bindings/sound/cs42l52.txt
new file mode 100644
index 000000000000..bc03c9312a19
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs42l52.txt
@@ -0,0 +1,46 @@
+CS42L52 audio CODEC
+Required properties:
+  - compatible : "cirrus,cs42l52"
+  - reg : the I2C address of the device for I2C
+Optional properties:
+  - cirrus,reset-gpio : 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 = (64xFs)/(N+2)
+  N = chgfreq_val
+  Fs = Sample Rate (variable)
+  - cirrus,mica-differential-cfg : boolean, If present, then the MICA input is configured
+  as a differential input. If not present then the MICA input is configured as
+  Single-ended input. Single-ended mode allows for MIC1 or MIC2 muxing for input.
+  - cirrus,micb-differential-cfg : boolean, If present, then the MICB input is configured
+  as a differential input. If not present then the MICB input is configured as
+  Single-ended input. Single-ended mode allows for MIC1 or MIC2 muxing for input.
+  - 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
+Example:
+codec: codec@4a {
+        compatible = "cirrus,cs42l52";
+        reg = <0x4a>;
+        reset-gpio = <&gpio 10 0>;
+        cirrus,chgfreq-divisor = <0x05>;
+        cirrus.mica-differential-cfg;
+        cirrus,micbias-lvl = <5>;
+};
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index ed785b3f67be..569b26c4a81e 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -4,7 +4,8 @@ Required properties:
 - compatible :
        "ti,dm646x-mcasp-audio" : for DM646x platforms
        "ti,da830-mcasp-audio"  : for both DA830 & DA850 platforms
-        "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, TI81xx)
+        "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, AM43xx, TI81xx)
+        "ti,dra7-mcasp-audio"   : for DRA7xx platforms
 - reg : Should contain reg specifiers for the entries in the reg-names property.
 - reg-names : Should contain:
@@ -36,7 +37,8 @@ Optional properties:
 - pinctrl-0: Should specify pin control group used for this controller.
 - pinctrl-names: Should contain only one value - "default", for more details
                 please refer to pinctrl-bindings.txt
-  
+- fck_parent : Should contain a valid clock name which will be used as parent
+               for the McASP fck
 Example:
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
new file mode 100644
index 000000000000..d7b99fa637b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -0,0 +1,50 @@
+Freescale Enhanced Serial Audio Interface (ESAI) Controller
+The Enhanced Serial Audio Interface (ESAI) provides a full-duplex serial port
+for serial communication with a variety of serial devices, including industry
+standard codecs, Sony/Phillips Digital Interface (S/PDIF) transceivers, and
+other DSPs. It has up to six transmitters and four receivers.
+Required properties:
+  - compatible : Compatible list, must contain "fsl,imx35-esai".
+  - reg : Offset and length of the register set for the device.
+  - interrupts : Contains the spdif interrupt.
+  - 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".
+  - clocks: Contains an entry for each entry in clock-names.
+  - clock-names : Includes the following entries:
+        "core"          The core clock used to access registers
+        "extal"         The esai baud clock for esai controller used to derive
+                        HCK, SCK and FS.
+        "fsys"          The system clock derived from ahb clock used to derive
+                        HCK, SCK and FS.
+  - fsl,fifo-depth: The number of elements in the transmit and receive FIFOs.
+    This number is the maximum allowed value for TFCR[TFWM] or RFCR[RFWM].
+  - fsl,esai-synchronous: This is a boolean property. If present, indicating
+    that ESAI would work in the synchronous mode, which means all the settings
+    for Receiving would be duplicated from Transmition related registers.
+Example:
+esai: esai@02024000 {
+        compatible = "fsl,imx35-esai";
+        reg = <0x02024000 0x4000>;
+        interrupts = <0 51 0x04>;
+        clocks = <&clks 208>, <&clks 118>, <&clks 208>;
+        clock-names = "core", "extal", "fsys";
+        dmas = <&sdma 23 21 0>, <&sdma 24 21 0>;
+        dma-names = "rx", "tx";
+        fsl,fifo-depth = <128>;
+        fsl,esai-synchronous;
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/sound/fsl,ssi.txt b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
index 4303b6ab6208..b93e9a91e30e 100644
--- a/Documentation/devicetree/bindings/sound/fsl,ssi.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,ssi.txt
@@ -4,7 +4,12 @@ The SSI is a serial device that communicates with audio codecs.  It can
 be programmed in AC97, I2S, left-justified, or right-justified modes.
 Required properties:
- compatible:       Compatible list, contains "fsl,ssi".
+- compatible:       Compatible list, should contain one of the following
+                    compatibles:
+                      fsl,mpc8610-ssi
+                      fsl,imx51-ssi
+                      fsl,imx35-ssi
+                      fsl,imx21-ssi
 - cell-index:       The SSI, <0> = SSI1, <1> = SSI2, and so on.
 - reg:              Offset and length of the register set for the device.
 - interrupts:       <a b> where a is the interrupt number and b is a
diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt
new file mode 100644
index 000000000000..98611a6761c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt
@@ -0,0 +1,40 @@
+Freescale Synchronous Audio Interface (SAI).
+The SAI is based on I2S module that used communicating with audio codecs,
+which provides a synchronous audio interface that supports fullduplex
+serial interfaces with frame synchronization such as I2S, AC97, TDM, and
+codec/DSP interfaces.
+Required properties:
+- compatible: Compatible list, contains "fsl,vf610-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.
+- 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".
+- pinctrl-names: Must contain a "default" entry.
+- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
+  See ../pinctrl/pinctrl-bindings.txt for details of the property values.
+- big-endian-regs: If this property is absent, the little endian mode will
+  be in use as default, or the big endian mode will be in use for all the
+  device registers.
+- big-endian-data: If this property is absent, the little endian mode will
+  be in use as default, or the big endian mode will be in use for all the
+  fifo data.
+Example:
+sai2: sai@40031000 {
+              compatible = "fsl,vf610-sai";
+              reg = <0x40031000 0x1000>;
+              pinctrl-names = "default";
+              pinctrl-0 = <&pinctrl_sai2_1>;
+              clocks = <&clks VF610_CLK_SAI2>;
+              clock-names = "sai";
+              dma-names = "tx", "rx";
+              dmas = <&edma0 0 VF610_EDMA_MUXID0_SAI2_TX>,
+                   <&edma0 0 VF610_EDMA_MUXID0_SAI2_RX>;
+              big-endian-regs;
+              big-endian-data;
+};
diff --git a/Documentation/devicetree/bindings/sound/hdmi.txt b/Documentation/devicetree/bindings/sound/hdmi.txt
new file mode 100644
index 000000000000..31af7bca3099
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/hdmi.txt
@@ -0,0 +1,17 @@
+Device-Tree bindings for dummy HDMI codec
+Required properties:
+        - compatible: should be "linux,hdmi-audio".
+CODEC output pins:
+  * TX
+CODEC input pins:
+  * RX
+Example node:
+        hdmi_audio: hdmi_audio@0 {
+                compatible = "linux,hdmi-audio";
+                status = "okay";
+        };
diff --git a/Documentation/devicetree/bindings/sound/max98090.txt b/Documentation/devicetree/bindings/sound/max98090.txt
new file mode 100644
index 000000000000..e4c8b36dcf89
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/max98090.txt
@@ -0,0 +1,43 @@
+MAX98090 audio CODEC
+This device supports I2C only.
+Required properties:
+- compatible : "maxim,max98090".
+- reg : The I2C address of the device.
+- interrupts : The CODEC's interrupt output.
+Pins on the device (for linking into audio routes):
+  * MIC1
+  * MIC2
+  * DMICL
+  * DMICR
+  * IN1
+  * IN2
+  * IN3
+  * IN4
+  * IN5
+  * IN6
+  * IN12
+  * IN34
+  * IN56
+  * HPL
+  * HPR
+  * SPKL
+  * SPKR
+  * RCVL
+  * RCVR
+  * MICBIAS
+Example:
+audio-codec@10 {
+        compatible = "maxim,max98090";
+        reg = <0x10>;
+        interrupt-parent = <&gpio>;
+        interrupts = <TEGRA_GPIO(H, 4) GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
index 8b8903ef0800..57f40f93453e 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-alc5632.txt
@@ -3,10 +3,11 @@ NVIDIA Tegra audio complex
 Required properties:
 - compatible : "nvidia,tegra-audio-alc5632"
 - 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:
-  "pll_a" (The Tegra clock of that name),
+  - pll_a
-  "pll_a_out0" (The Tegra clock of that name),
+  - pll_a_out0
-  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+  - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the connection's sink,
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt
new file mode 100644
index 000000000000..9c7c55c71370
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-max98090.txt
@@ -0,0 +1,51 @@
+NVIDIA Tegra audio complex, with MAX98090 CODEC
+Required properties:
+- compatible : "nvidia,tegra-audio-max98090"
+- 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:
+  - pll_a
+  - pll_a_out0
+  - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+- nvidia,model : The user-visible name of this sound complex.
+- nvidia,audio-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. Valid names for sources and
+  sinks are the MAX98090's pins (as documented in its binding), and the jacks
+  on the board:
+  * Headphones
+  * Speakers
+  * Mic Jack
+- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's
+  connected to the CODEC.
+- nvidia,audio-codec : The phandle of the MAX98090 audio codec.
+Optional properties:
+- nvidia,hp-det-gpios : The GPIO that detect headphones are plugged in
+Example:
+sound {
+        compatible = "nvidia,tegra-audio-max98090-venice2",
+                     "nvidia,tegra-audio-max98090";
+        nvidia,model = "NVIDIA Tegra Venice2";
+        nvidia,audio-routing =
+                "Headphones", "HPR",
+                "Headphones", "HPL",
+                "Speakers", "SPKR",
+                "Speakers", "SPKL",
+                "Mic Jack", "MICBIAS",
+                "IN34", "Mic Jack";
+        nvidia,i2s-controller = <&tegra_i2s1>;
+        nvidia,audio-codec = <&acodec>;
+        clocks = <&tegra_car TEGRA124_CLK_PLL_A>,
+                 <&tegra_car TEGRA124_CLK_PLL_A_OUT0>,
+                 <&tegra_car TEGRA124_CLK_EXTERN1>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
+};
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
index dc6224994d69..7788808dcd0b 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
@@ -3,10 +3,11 @@ NVIDIA Tegra audio complex, with RT5640 CODEC
 Required properties:
 - compatible : "nvidia,tegra-audio-rt5640"
 - 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:
-  "pll_a" (The Tegra clock of that name),
+  - pll_a
-  "pll_a_out0" (The Tegra clock of that name),
+  - pll_a_out0
-  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+  - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the connection's sink,
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
index aab6ce0ad2fc..96f6a57dd6b4 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8753.txt
@@ -3,10 +3,11 @@ NVIDIA Tegra audio complex
 Required properties:
 - compatible : "nvidia,tegra-audio-wm8753"
 - 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:
-  "pll_a" (The Tegra clock of that name),
+  - pll_a
-  "pll_a_out0" (The Tegra clock of that name),
+  - pll_a_out0
-  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+  - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the connection's sink,
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
index 4b44dfb6ca0d..b795d282818d 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm8903.txt
@@ -3,10 +3,11 @@ NVIDIA Tegra audio complex
 Required properties:
 - compatible : "nvidia,tegra-audio-wm8903"
 - 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:
-  "pll_a" (The Tegra clock of that name),
+  - pll_a
-  "pll_a_out0" (The Tegra clock of that name),
+  - pll_a_out0
-  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+  - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the connection's sink,
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
index ad589b163639..436f6cd9d07c 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-wm9712.txt
@@ -3,10 +3,11 @@ NVIDIA Tegra audio complex
 Required properties:
 - compatible : "nvidia,tegra-audio-wm9712"
 - 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:
-  "pll_a" (The Tegra clock of that name),
+  - pll_a
-  "pll_a_out0" (The Tegra clock of that name),
+  - pll_a_out0
-  "mclk" (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
+  - mclk (The Tegra cdev1/extern1 clock, which feeds the CODEC's mclk)
 - nvidia,model : The user-visible name of this sound complex.
 - nvidia,audio-routing : A list of the connections between audio components.
  Each entry is a pair of strings, the first being the connection's sink,
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
index c1454979c1ef..eaf00102d92c 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-ac97.txt
@@ -4,19 +4,33 @@ Required properties:
 - compatible : "nvidia,tegra20-ac97"
 - reg : Should contain AC97 controller registers location and length
 - interrupts : Should contain AC97 interrupt
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+- resets : Must contain an entry for each entry in reset-names.
-  request selector for the AC97 controller
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - ac97
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
 - nvidia,codec-reset-gpio : The Tegra GPIO controller's phandle and the number
  of the GPIO used to reset the external AC97 codec
 - nvidia,codec-sync-gpio : The Tegra GPIO controller's phandle and the number
  of the GPIO corresponding with the AC97 DAP _FS line
 Example:
 ac97@70002000 {
        compatible = "nvidia,tegra20-ac97";
        reg = <0x70002000 0x200>;
        interrupts = <0 81 0x04>;
-        nvidia,dma-request-selector = <&apbdma 12>;
        nvidia,codec-reset-gpio = <&gpio 170 0>;
        nvidia,codec-sync-gpio = <&gpio 120 0>;
+        clocks = <&tegra_car 3>;
+        resets = <&tegra_car 3>;
+        reset-names = "ac97";
+        dmas = <&apbdma 12>, <&apbdma 12>;
+        dma-names = "rx", "tx";
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
index 0df2b5c816e3..dc30c6bfbe95 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra20-i2s.txt
@@ -4,8 +4,17 @@ Required properties:
 - compatible : "nvidia,tegra20-i2s"
 - reg : Should contain I2S registers location and length
 - interrupts : Should contain I2S interrupt
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+- resets : Must contain an entry for each entry in reset-names.
-  request selector for this I2S controller
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - i2s
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
 Example:
@@ -13,5 +22,9 @@ i2s@70002800 {
        compatible = "nvidia,tegra20-i2s";
        reg = <0x70002800 0x200>;
        interrupts = < 45 >;
-        nvidia,dma-request-selector = < &apbdma 2 >;
+        clocks = <&tegra_car 11>;
+        resets = <&tegra_car 11>;
+        reset-names = "i2s";
+        dmas = <&apbdma 21>, <&apbdma 21>;
+        dma-names = "rx", "tx";
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
index 0e5c12c66523..946e2ac46091 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-ahub.txt
@@ -7,18 +7,48 @@ Required properties:
  - Tegra30 requires 2 entries, for the APBIF and AHUB/AUDIO register blocks.
  - Tegra114 requires an additional entry, for the APBIF2 register block.
 - interrupts : Should contain AHUB interrupt
- nvidia,dma-request-selector : A list of the DMA channel specifiers. Each
+- clocks : Must contain an entry for each entry in clock-names.
-  entry contains the Tegra DMA controller's phandle and request selector.
+  See ../clocks/clock-bindings.txt for details.
-  If a single entry is present, the request selectors for the channels are
-  assumed to be contiguous, and increment from this value.
-  If multiple values are given, one value must be given per channel.
- clocks : Must contain an entry for each required entry in clock-names.
 - clock-names : Must include the following entries:
-  - Tegra30: Requires d_audio, apbif, i2s0, i2s1, i2s2, i2s3, i2s4, dam0,
+  - d_audio
-    dam1, dam2, spdif_in.
+  - apbif
-  - Tegra114: Additionally requires amx, adx.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  Tegra30 and later:
+  - d_audio
+  - apbif
+  - i2s0
+  - i2s1
+  - i2s2
+  - i2s3
+  - i2s4
+  - dam0
+  - dam1
+  - dam2
+  - spdif
+  Tegra114 and later additionally require:
+  - amx
+  - adx
+  Tegra124 and later additionally require:
+  - amx1
+  - adx1
+  - afc0
+  - afc1
+  - afc2
+  - afc3
+  - afc4
+  - afc5
 - ranges : The bus address mapping for the configlink register bus.
  Can be empty since the mapping is 1:1.
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx0 .. rx<n>
+  - tx0 .. tx<n>
+  ... where n is:
+  Tegra30: 3
+  Tegra114, Tegra124: 9
 - #address-cells : For the configlink bus. Should be <1>;
 - #size-cells : For the configlink bus. Should be <1>.
@@ -35,13 +65,20 @@ ahub@70080000 {
        reg = <0x70080000 0x200 0x70080200 0x100>;
        interrupts = < 0 103 0x04 >;
        nvidia,dma-request-selector = <&apbdma 1>;
-        clocks = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
+        clocks = <&tegra_car 106>, <&tegra_car 107>;
+        clock-names = "d_audio", "apbif";
+        resets = <&tegra_car 106>, <&tegra_car 107>, <&tegra_car 30>,
                <&tegra_car 11>, <&tegra_car 18>, <&tegra_car 101>,
                <&tegra_car 102>, <&tegra_car 108>, <&tegra_car 109>,
-                <&tegra_car 110>, <&tegra_car 162>;
+                <&tegra_car 110>, <&tegra_car 10>;
-        clock-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
+        reset-names = "d_audio", "apbif", "i2s0", "i2s1", "i2s2",
                "i2s3", "i2s4", "dam0", "dam1", "dam2",
-                "spdif_in";
+                "spdif";
+        dmas = <&apbdma 1>, <&apbdma 1>;
+               <&apbdma 2>, <&apbdma 2>;
+               <&apbdma 3>, <&apbdma 3>;
+               <&apbdma 4>, <&apbdma 4>;
+        dma-names = "rx0", "tx0", "rx1", "tx1", "rx2", "tx2", "rx3", "tx3";
        ranges;
        #address-cells = <1>;
        #size-cells = <1>;
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
index dfa6c037124a..0c113ffe3814 100644
--- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-i2s.txt
@@ -3,13 +3,22 @@ NVIDIA Tegra30 I2S controller
 Required properties:
 - compatible : "nvidia,tegra30-i2s"
 - reg : Should contain I2S registers location and length
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - i2s
 - nvidia,ahub-cif-ids : The list of AHUB CIF IDs for this port, rx (playback)
  first, tx (capture) second. See nvidia,tegra30-ahub.txt for values.
 Example:
-i2s@70002800 {
+i2s@70080300 {
        compatible = "nvidia,tegra30-i2s";
        reg = <0x70080300 0x100>;
        nvidia,ahub-cif-ids = <4 4>;
+        clocks = <&tegra_car 11>;
+        resets = <&tegra_car 11>;
+        reset-names = "i2s";
 };
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt
new file mode 100644
index 000000000000..e9e20ec67d62
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -0,0 +1,77 @@
+Simple-Card:
+Simple-Card specifies audio DAI connection of SoC <-> codec.
+Required properties:
+- compatible                            : "simple-audio-card"
+Optional properties:
+- 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,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.
+Required subnodes:
+- simple-audio-card,cpu                 : CPU   sub-node
+- simple-audio-card,codec               : CODEC sub-node
+Required CPU/CODEC subnodes properties:
+- sound-dai                             : phandle and port of CPU/CODEC
+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
+- 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)
+Example:
+sound {
+        compatible = "simple-audio-card";
+        simple-audio-card,format = "left_j";
+        simple-audio-routing =
+                "MIC_IN", "Mic Jack",
+                "Headphone Jack", "HP_OUT",
+                "Ext Spk", "LINE_OUT";
+        simple-audio-card,cpu {
+                sound-dai = <&sh_fsi2 0>;
+        };
+        simple-audio-card,codec {
+                sound-dai = <&ak4648>;
+                bitclock-master;
+                frame-master;
+                clocks = <&osc>;
+        };
+};
+&i2c0 {
+        ak4648: ak4648@12 {
+                #sound-dai-cells = <0>;
+                compatible = "asahi-kasei,ak4648";
+                reg = <0x12>;
+        };
+};
+sh_fsi2: sh_fsi2@ec230000 {
+        #sound-dai-cells = <1>;
+        compatible = "renesas,sh_fsi2";
+        reg = <0xec230000 0x400>;
+        interrupt-parent = <&gic>;
+        interrupts = <0 146 0x4>;
+};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 5e6040c2c2e9..9d8ea14db490 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -6,6 +6,7 @@ Required properties:
 - compatible - "string" - One of:
    "ti,tlv320aic3x" - Generic TLV320AIC3x device
+    "ti,tlv320aic32x4" - TLV320AIC32x4
    "ti,tlv320aic33" - TLV320AIC33
    "ti,tlv320aic3007" - TLV320AIC3007
    "ti,tlv320aic3106" - TLV320AIC3106
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
index 91ff771c7e77..7ea701e07dc2 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra114-spi.txt
@@ -4,10 +4,19 @@ Required properties:
 - compatible : should be "nvidia,tegra114-spi".
 - reg: Should contain SPI registers location and length.
 - interrupts: Should contain SPI interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+- clock-names : Must include the following entries:
-  request selector for this SPI controller.
+  - spi
- This is also require clock named "spi" as per binding document
+- resets : Must contain an entry for each entry in reset-names.
-  Documentation/devicetree/bindings/clock/clock-bindings.txt
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - spi
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
+- clocks : Must contain an entry for each entry in clock-names.
+  See ../clocks/clock-bindings.txt for details.
 Recommended properties:
 - spi-max-frequency: Definition as per
@@ -18,9 +27,14 @@ spi@7000d600 {
        compatible = "nvidia,tegra114-spi";
        reg = <0x7000d600 0x200>;
        interrupts = <0 82 0x04>;
-        nvidia,dma-request-selector = <&apbdma 16>;
        spi-max-frequency = <25000000>;
        #address-cells = <1>;
        #size-cells = <0>;
+        clocks = <&tegra_car 44>;
+        clock-names = "spi";
+        resets = <&tegra_car 44>;
+        reset-names = "spi";
+        dmas = <&apbdma 16>, <&apbdma 16>;
+        dma-names = "rx", "tx";
        status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
index 7b53da5cb75b..bdf08e6dec9b 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
@@ -4,8 +4,17 @@ Required properties:
 - compatible : should be "nvidia,tegra20-sflash".
 - reg: Should contain SFLASH registers location and length.
 - interrupts: Should contain SFLASH interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+- clocks : Must contain one entry, for the module clock.
-  request selector for this SFLASH controller.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - spi
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
 Recommended properties:
 - spi-max-frequency: Definition as per
@@ -17,10 +26,13 @@ spi@7000c380 {
        compatible = "nvidia,tegra20-sflash";
        reg = <0x7000c380 0x80>;
        interrupts = <0 39 0x04>;
-        nvidia,dma-request-selector = <&apbdma 16>;
        spi-max-frequency = <25000000>;
        #address-cells = <1>;
        #size-cells = <0>;
+        clocks = <&tegra_car 43>;
+        resets = <&tegra_car 43>;
+        reset-names = "spi";
+        dmas = <&apbdma 11>, <&apbdma 11>;
+        dma-names = "rx", "tx";
        status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
index eefe15e3d95e..5db9144a33c8 100644
--- a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
@@ -4,8 +4,17 @@ Required properties:
 - compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
 - reg: Should contain SLINK registers location and length.
 - interrupts: Should contain SLINK interrupts.
- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+- clocks : Must contain one entry, for the module clock.
-  request selector for this SLINK controller.
+  See ../clocks/clock-bindings.txt for details.
+- resets : Must contain an entry for each entry in reset-names.
+  See ../reset/reset.txt for details.
+- reset-names : Must include the following entries:
+  - spi
+- dmas : Must contain an entry for each entry in clock-names.
+  See ../dma/dma.txt for details.
+- dma-names : Must include the following entries:
+  - rx
+  - tx
 Recommended properties:
 - spi-max-frequency: Definition as per
@@ -17,10 +26,13 @@ spi@7000d600 {
        compatible = "nvidia,tegra20-slink";
        reg = <0x7000d600 0x200>;
        interrupts = <0 82 0x04>;
-        nvidia,dma-request-selector = <&apbdma 16>;
        spi-max-frequency = <25000000>;
        #address-cells = <1>;
        #size-cells = <0>;
+        clocks = <&tegra_car 44>;
+        resets = <&tegra_car 44>;
+        reset-names = "spi";
+        dmas = <&apbdma 16>, <&apbdma 16>;
+        dma-names = "rx", "tx";
        status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt
index 800dafe5b01b..e5a4d1b4acfe 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -67,7 +67,7 @@ only 1(SINGLE), 2(DUAL) and 4(QUAD).
 Dual/Quad mode is not allowed when 3-wire mode is used.
 If a gpio chipselect is used for the SPI slave the gpio number will be passed
-via the cs_gpio
+via the SPI master node cs-gpios property.
 SPI example for an MPC5200 SPI bus:
        spi@f00 {
diff --git a/Documentation/devicetree/bindings/spi/ti_qspi.txt b/Documentation/devicetree/bindings/spi/ti_qspi.txt
index 1f9641ade0b5..601a360531a5 100644
--- a/Documentation/devicetree/bindings/spi/ti_qspi.txt
+++ b/Documentation/devicetree/bindings/spi/ti_qspi.txt
@@ -3,6 +3,11 @@ TI QSPI controller.
 Required properties:
 - compatible : should be "ti,dra7xxx-qspi" or "ti,am4372-qspi".
 - reg: Should contain QSPI registers location and length.
+- reg-names: Should contain the resource reg names.
+        - qspi_base: Qspi configuration register Address space
+        - qspi_mmap: Memory mapped Address space
+        - (optional) qspi_ctrlmod: Control module Address space
+- interrupts: should contain the qspi interrupt number.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
 - ti,hwmods: Name of the hwmod associated to the QSPI
@@ -14,7 +19,8 @@ Example:
 qspi: qspi@4b300000 {
        compatible = "ti,dra7xxx-qspi";
-        reg = <0x4b300000 0x100>;
+        reg = <0x47900000 0x100>, <0x30000000 0x3ffffff>;
+        reg-names = "qspi_base", "qspi_mmap";
        #address-cells = <1>;
        #size-cells = <0>;
        spi-max-frequency = <25000000>;
diff --git a/Documentation/devicetree/bindings/staging/dwc2.txt b/Documentation/devicetree/bindings/staging/dwc2.txt
deleted file mode 100644
index 1a1b7cfa4845..000000000000
--- a/Documentation/devicetree/bindings/staging/dwc2.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-Platform DesignWare HS OTG USB 2.0 controller
-----------------------------------------------------
-Required properties:
- compatible : "snps,dwc2"
- reg : Should contain 1 register range (address and length)
- interrupts : Should contain 1 interrupt
-Example:
-        usb@101c0000 {
-                compatible = "ralink,rt3050-usb, snps,dwc2";
-                reg = <0x101c0000 40000>;
-                interrupts = <18>;
-        };
diff --git a/Documentation/devicetree/bindings/staging/xillybus.txt b/Documentation/devicetree/bindings/staging/xillybus.txt
new file mode 100644
index 000000000000..9e316dc2e40f
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/xillybus.txt
@@ -0,0 +1,20 @@
+* Xillybus driver for generic FPGA interface
+Required properties:
+- compatible: Should be "xillybus,xillybus-1.00.a"
+- reg: Address and length of the register set for the device
+- interrupts: Contains one interrupt node, typically consisting of three cells.
+- interrupt-parent: the phandle for the interrupt controller that
+                    services interrupts for this device.
+Optional properties:
+- dma-coherent: Present if DMA operations are coherent
+Example:
+        xillybus@ff200400 {
+                compatible = "xillybus,xillybus-1.00.a";
+                reg = < 0xff200400 0x00000080 >;
+                interrupts = < 0 40 1 >;
+                interrupt-parent = <&intc>;
+        } ;
diff --git a/Documentation/devicetree/bindings/submitting-patches.txt b/Documentation/devicetree/bindings/submitting-patches.txt
new file mode 100644
index 000000000000..042a0273b8ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/submitting-patches.txt
@@ -0,0 +1,38 @@
+  Submitting devicetree (DT) binding patches
+I. For patch submitters
+  0) Normal patch submission rules from Documentation/SubmittingPatches
+     applies.
+  1) The Documentation/ portion of the patch should be a separate patch.
+  2) Submit the entire series to the devicetree mailinglist at
+       devicetree@vger.kernel.org
+II. For kernel maintainers
+  1) If you aren't comfortable reviewing a given binding, reply to it and ask
+     the devicetree maintainers for guidance.  This will help them prioritize
+     which ones to review and which ones are ok to let go.
+  2) For driver (not subsystem) bindings: If you are comfortable with the
+     binding, and it hasn't received an Acked-by from the devicetree
+     maintainers after a few weeks, go ahead and take it.
+     Subsystem bindings (anything affecting more than a single device)
+     then getting a devicetree maintainer to review it is required.
+  3) For a series going though multiple trees, the binding patch should be
+     kept with the driver using the binding.
+III. Notes
+  0) Please see ...bindings/ABI.txt for details regarding devicetree ABI.
+  1) This document is intended as a general familiarization with the process as
+     decided at the 2013 Kernel Summit.  When in doubt, the current word of the
+     devicetree maintainers overrules this document.  In that situation, a patch
+     updating this document would be appreciated.
diff --git a/Documentation/devicetree/bindings/thermal/imx-thermal.txt b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
index 541c25e49abf..1f0f67234a91 100644
--- a/Documentation/devicetree/bindings/thermal/imx-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/imx-thermal.txt
@@ -8,10 +8,14 @@ Required properties:
  calibration data, e.g. OCOTP on imx6q.  The details about calibration data
  can be found in SoC Reference Manual.
+Optional properties:
+- clocks : thermal sensor's clock source.
 Example:
 tempmon {
        compatible = "fsl,imx6q-tempmon";
        fsl,tempmon = <&anatop>;
        fsl,tempmon-data = <&ocotp>;
+        clocks = <&clks 172>;
 };
diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt b/Documentation/devicetree/bindings/thermal/thermal.txt
new file mode 100644
index 000000000000..f5db6b72a36f
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/thermal.txt
@@ -0,0 +1,595 @@
+* Thermal Framework Device Tree descriptor
+This file describes a generic binding to provide a way of
+defining hardware thermal structure using device tree.
+A thermal structure includes thermal zones and their components,
+such as trip points, polling intervals, sensors and cooling devices
+binding descriptors.
+The target of device tree thermal descriptors is to describe only
+the hardware thermal aspects. The thermal device tree bindings are
+not about how the system must control or which algorithm or policy
+must be taken in place.
+There are five types of nodes involved to describe thermal bindings:
+- thermal sensors: devices which may be used to take temperature
+  measurements.
+- cooling devices: devices which may be used to dissipate heat.
+- trip points: describe key temperatures at which cooling is recommended. The
+  set of points should be chosen based on hardware limits.
+- cooling maps: used to describe links between trip points and cooling devices;
+- thermal zones: used to describe thermal data within the hardware;
+The following is a description of each of these node types.
+* Thermal sensor devices
+Thermal sensor devices are nodes providing temperature sensing capabilities on
+thermal zones. Typical devices are I2C ADC converters and bandgaps. These are
+nodes providing temperature data to thermal zones. Thermal sensor devices may
+control one or more internal sensors.
+Required property:
+- #thermal-sensor-cells: Used to provide sensor device specific information
+  Type: unsigned         while referring to it. Typically 0 on thermal sensor
+  Size: one cell         nodes with only one sensor, and at least 1 on nodes
+                         with several internal sensors, in order
+                         to identify uniquely the sensor instances within
+                         the IC. See thermal zone binding for more details
+                         on how consumers refer to sensor devices.
+* Cooling device nodes
+Cooling devices are nodes providing control on power dissipation. There
+are essentially two ways to provide control on power dissipation. First
+is by means of regulating device performance, which is known as passive
+cooling. A typical passive cooling is a CPU that has dynamic voltage and
+frequency scaling (DVFS), and uses lower frequencies as cooling states.
+Second is by means of activating devices in order to remove
+the dissipated heat, which is known as active cooling, e.g. regulating
+fan speeds. In both cases, cooling devices shall have a way to determine
+the state of cooling in which the device is.
+Any cooling device has a range of cooling states (i.e. different levels
+of heat dissipation). For example a fan's cooling states correspond to
+the different fan speeds possible. Cooling states are referred to by
+single unsigned integers, where larger numbers mean greater heat
+dissipation. The precise set of cooling states associated with a device
+(as referred to be the cooling-min-state and cooling-max-state
+properties) should be defined in a particular device's binding.
+For more examples of cooling devices, refer to the example sections below.
+Required properties:
+- cooling-min-state:    An integer indicating the smallest
+  Type: unsigned        cooling state accepted. Typically 0.
+  Size: one cell
+- cooling-max-state:    An integer indicating the largest
+  Type: unsigned        cooling state accepted.
+  Size: one cell
+- #cooling-cells:       Used to provide cooling device specific information
+  Type: unsigned        while referring to it. Must be at least 2, in order
+  Size: one cell        to specify minimum and maximum cooling state used
+                        in the reference. The first cell is the minimum
+                        cooling state requested and the second cell is
+                        the maximum cooling state requested in the reference.
+                        See Cooling device maps section below for more details
+                        on how consumers refer to cooling devices.
+* Trip points
+The trip node is a node to describe a point in the temperature domain
+in which the system takes an action. This node describes just the point,
+not the action.
+Required properties:
+- temperature:          An integer indicating the trip temperature level,
+  Type: signed          in millicelsius.
+  Size: one cell
+- hysteresis:           A low hysteresis value on temperature property (above).
+  Type: unsigned        This is a relative value, in millicelsius.
+  Size: one cell
+- type:                 a string containing the trip type. Expected values are:
+        "active":       A trip point to enable active cooling
+        "passive":      A trip point to enable passive cooling
+        "hot":          A trip point to notify emergency
+        "critical":     Hardware not reliable.
+  Type: string
+* Cooling device maps
+The cooling device maps node is a node to describe how cooling devices
+get assigned to trip points of the zone. The cooling devices are expected
+to be loaded in the target system.
+Required properties:
+- cooling-device:       A phandle of a cooling device with its specifier,
+  Type: phandle +       referring to which cooling device is used in this
+    cooling specifier   binding. In the cooling specifier, the first cell
+                        is the minimum cooling state and the second cell
+                        is the maximum cooling state used in this map.
+- trip:                 A phandle of a trip point node within the same thermal
+  Type: phandle of      zone.
+   trip point node
+Optional property:
+- contribution:         The cooling contribution to the thermal zone of the
+  Type: unsigned        referred cooling device at the referred trip point.
+  Size: one cell        The contribution is a ratio of the sum
+                        of all cooling contributions within a thermal zone.
+Note: Using the THERMAL_NO_LIMIT (-1UL) constant in the cooling-device phandle
+limit specifier means:
+(i)   - minimum state allowed for minimum cooling state used in the reference.
+(ii)  - maximum state allowed for maximum cooling state used in the reference.
+Refer to include/dt-bindings/thermal/thermal.h for definition of this constant.
+* Thermal zone nodes
+The thermal zone node is the node containing all the required info
+for describing a thermal zone, including its cooling device bindings. The
+thermal zone node must contain, apart from its own properties, one sub-node
+containing trip nodes and one sub-node containing all the zone cooling maps.
+Required properties:
+- polling-delay:        The maximum number of milliseconds to wait between polls
+  Type: unsigned        when checking this thermal zone.
+  Size: one cell
+- polling-delay-passive: The maximum number of milliseconds to wait
+  Type: unsigned        between polls when performing passive cooling.
+  Size: one cell
+- thermal-sensors:      A list of thermal sensor phandles and sensor specifier
+  Type: list of         used while monitoring the thermal zone.
+  phandles + sensor
+  specifier
+- trips:                A sub-node which is a container of only trip point nodes
+  Type: sub-node        required to describe the thermal zone.
+- cooling-maps:         A sub-node which is a container of only cooling device
+  Type: sub-node        map nodes, used to describe the relation between trips
+                        and cooling devices.
+Optional property:
+- coefficients:         An array of integers (one signed cell) containing
+  Type: array           coefficients to compose a linear relation between
+  Elem size: one cell   the sensors listed in the thermal-sensors property.
+  Elem type: signed     Coefficients defaults to 1, in case this property
+                        is not specified. A simple linear polynomial is used:
+                        Z = c0 * x0 + c1 + x1 + ... + c(n-1) * x(n-1) + cn.
+                        The coefficients are ordered and they match with sensors
+                        by means of sensor ID. Additional coefficients are
+                        interpreted as constant offset.
+Note: The delay properties are bound to the maximum dT/dt (temperature
+derivative over time) in two situations for a thermal zone:
+(i)  - when passive cooling is activated (polling-delay-passive); and
+(ii) - when the zone just needs to be monitored (polling-delay) or
+when active cooling is activated.
+The maximum dT/dt is highly bound to hardware power consumption and dissipation
+capability. The delays should be chosen to account for said max dT/dt,
+such that a device does not cross several trip boundaries unexpectedly
+between polls. Choosing the right polling delays shall avoid having the
+device in temperature ranges that may damage the silicon structures and
+reduce silicon lifetime.
+* The thermal-zones node
+The "thermal-zones" node is a container for all thermal zone nodes. It shall
+contain only sub-nodes describing thermal zones as in the section
+"Thermal zone nodes". The "thermal-zones" node appears under "/".
+* Examples
+Below are several examples on how to use thermal data descriptors
+using device tree bindings:
+(a) - CPU thermal zone
+The CPU thermal zone example below describes how to setup one thermal zone
+using one single sensor as temperature source and many cooling devices and
+power dissipation control sources.
+#include <dt-bindings/thermal/thermal.h>
+cpus {
+        /*
+         * Here is an example of describing a cooling device for a DVFS
+         * capable CPU. The CPU node describes its four OPPs.
+         * The cooling states possible are 0..3, and they are
+         * used as OPP indexes. The minimum cooling state is 0, which means
+         * all four OPPs can be available to the system. The maximum
+         * cooling state is 3, which means only the lowest OPPs (198MHz@0.85V)
+         * can be available in the system.
+         */
+        cpu0: cpu@0 {
+                ...
+                operating-points = <
+                        /* kHz    uV */
+                        970000  1200000
+                        792000  1100000
+                        396000  950000
+                        198000  850000
+                >;
+                cooling-min-state = <0>;
+                cooling-max-state = <3>;
+                #cooling-cells = <2>; /* min followed by max */
+        };
+        ...
+};
+&i2c1 {
+        ...
+        /*
+         * A simple fan controller which supports 10 speeds of operation
+         * (represented as 0-9).
+         */
+        fan0: fan@0x48 {
+                ...
+                cooling-min-state = <0>;
+                cooling-max-state = <9>;
+                #cooling-cells = <2>; /* min followed by max */
+        };
+};
+ocp {
+        ...
+        /*
+         * A simple IC with a single bandgap temperature sensor.
+         */
+        bandgap0: bandgap@0x0000ED00 {
+                ...
+                #thermal-sensor-cells = <0>;
+        };
+};
+thermal-zones {
+        cpu-thermal: cpu-thermal {
+                polling-delay-passive = <250>; /* milliseconds */
+                polling-delay = <1000>; /* milliseconds */
+                thermal-sensors = <&bandgap0>;
+                trips {
+                        cpu-alert0: cpu-alert {
+                                temperature = <90000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "active";
+                        };
+                        cpu-alert1: cpu-alert {
+                                temperature = <100000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        };
+                        cpu-crit: cpu-crit {
+                                temperature = <125000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "critical";
+                        };
+                };
+                cooling-maps {
+                        map0 {
+                                trip = <&cpu-alert0>;
+                                cooling-device = <&fan0 THERMAL_NO_LIMITS 4>;
+                        };
+                        map1 {
+                                trip = <&cpu-alert1>;
+                                cooling-device = <&fan0 5 THERMAL_NO_LIMITS>;
+                        };
+                        map2 {
+                                trip = <&cpu-alert1>;
+                                cooling-device =
+                                    <&cpu0 THERMAL_NO_LIMITS THERMAL_NO_LIMITS>;
+                        };
+                };
+        };
+};
+In the example above, the ADC sensor (bandgap0) at address 0x0000ED00 is
+used to monitor the zone 'cpu-thermal' using its sole sensor. A fan
+device (fan0) is controlled via I2C bus 1, at address 0x48, and has ten
+different cooling states 0-9. It is used to remove the heat out of
+the thermal zone 'cpu-thermal' using its cooling states
+from its minimum to 4, when it reaches trip point 'cpu-alert0'
+at 90C, as an example of active cooling. The same cooling device is used at
+'cpu-alert1', but from 5 to its maximum state. The cpu@0 device is also
+linked to the same thermal zone, 'cpu-thermal', as a passive cooling device,
+using all its cooling states at trip point 'cpu-alert1',
+which is a trip point at 100C. On the thermal zone 'cpu-thermal', at the
+temperature of 125C, represented by the trip point 'cpu-crit', the silicon
+is not reliable anymore.
+(b) - IC with several internal sensors
+The example below describes how to deploy several thermal zones based off a
+single sensor IC, assuming it has several internal sensors. This is a common
+case on SoC designs with several internal IPs that may need different thermal
+requirements, and thus may have their own sensor to monitor or detect internal
+hotspots in their silicon.
+#include <dt-bindings/thermal/thermal.h>
+ocp {
+        ...
+        /*
+         * A simple IC with several bandgap temperature sensors.
+         */
+        bandgap0: bandgap@0x0000ED00 {
+                ...
+                #thermal-sensor-cells = <1>;
+        };
+};
+thermal-zones {
+        cpu-thermal: cpu-thermal {
+                polling-delay-passive = <250>; /* milliseconds */
+                polling-delay = <1000>; /* milliseconds */
+                                /* sensor       ID */
+                thermal-sensors = <&bandgap0     0>;
+                trips {
+                        /* each zone within the SoC may have its own trips */
+                        cpu-alert: cpu-alert {
+                                temperature = <100000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        };
+                        cpu-crit: cpu-crit {
+                                temperature = <125000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "critical";
+                        };
+                };
+                cooling-maps {
+                        /* each zone within the SoC may have its own cooling */
+                        ...
+                };
+        };
+        gpu-thermal: gpu-thermal {
+                polling-delay-passive = <120>; /* milliseconds */
+                polling-delay = <1000>; /* milliseconds */
+                                /* sensor       ID */
+                thermal-sensors = <&bandgap0     1>;
+                trips {
+                        /* each zone within the SoC may have its own trips */
+                        gpu-alert: gpu-alert {
+                                temperature = <90000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        };
+                        gpu-crit: gpu-crit {
+                                temperature = <105000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "critical";
+                        };
+                };
+                cooling-maps {
+                        /* each zone within the SoC may have its own cooling */
+                        ...
+                };
+        };
+        dsp-thermal: dsp-thermal {
+                polling-delay-passive = <50>; /* milliseconds */
+                polling-delay = <1000>; /* milliseconds */
+                                /* sensor       ID */
+                thermal-sensors = <&bandgap0     2>;
+                trips {
+                        /* each zone within the SoC may have its own trips */
+                        dsp-alert: gpu-alert {
+                                temperature = <90000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        };
+                        dsp-crit: gpu-crit {
+                                temperature = <135000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "critical";
+                        };
+                };
+                cooling-maps {
+                        /* each zone within the SoC may have its own cooling */
+                        ...
+                };
+        };
+};
+In the example above, there is one bandgap IC which has the capability to
+monitor three sensors. The hardware has been designed so that sensors are
+placed on different places in the DIE to monitor different temperature
+hotspots: one for CPU thermal zone, one for GPU thermal zone and the
+other to monitor a DSP thermal zone.
+Thus, there is a need to assign each sensor provided by the bandgap IC
+to different thermal zones. This is achieved by means of using the
+#thermal-sensor-cells property and using the first cell of the sensor
+specifier as sensor ID. In the example, then, <bandgap 0> is used to
+monitor CPU thermal zone, <bandgap 1> is used to monitor GPU thermal
+zone and <bandgap 2> is used to monitor DSP thermal zone. Each zone
+may be uncorrelated, having its own dT/dt requirements, trips
+and cooling maps.
+(c) - Several sensors within one single thermal zone
+The example below illustrates how to use more than one sensor within
+one thermal zone.
+#include <dt-bindings/thermal/thermal.h>
+&i2c1 {
+        ...
+        /*
+         * A simple IC with a single temperature sensor.
+         */
+        adc: sensor@0x49 {
+                ...
+                #thermal-sensor-cells = <0>;
+        };
+};
+ocp {
+        ...
+        /*
+         * A simple IC with a single bandgap temperature sensor.
+         */
+        bandgap0: bandgap@0x0000ED00 {
+                ...
+                #thermal-sensor-cells = <0>;
+        };
+};
+thermal-zones {
+        cpu-thermal: cpu-thermal {
+                polling-delay-passive = <250>; /* milliseconds */
+                polling-delay = <1000>; /* milliseconds */
+                thermal-sensors = <&bandgap0>,  /* cpu */
+                                  <&adc>;       /* pcb north */
+                /* hotspot = 100 * bandgap - 120 * adc + 484 */
+                coefficients =          <100    -120    484>;
+                trips {
+                        ...
+                };
+                cooling-maps {
+                        ...
+                };
+        };
+};
+In some cases, there is a need to use more than one sensor to extrapolate
+a thermal hotspot in the silicon. The above example illustrates this situation.
+For instance, it may be the case that a sensor external to CPU IP may be placed
+close to CPU hotspot and together with internal CPU sensor, it is used
+to determine the hotspot. Assuming this is the case for the above example,
+the hypothetical extrapolation rule would be:
+                hotspot = 100 * bandgap - 120 * adc + 484
+In other context, the same idea can be used to add fixed offset. For instance,
+consider the hotspot extrapolation rule below:
+                hotspot = 1 * adc + 6000
+In the above equation, the hotspot is always 6C higher than what is read
+from the ADC sensor. The binding would be then:
+        thermal-sensors =  <&adc>;
+                /* hotspot = 1 * adc + 6000 */
+        coefficients =          <1      6000>;
+(d) - Board thermal
+The board thermal example below illustrates how to setup one thermal zone
+with many sensors and many cooling devices.
+#include <dt-bindings/thermal/thermal.h>
+&i2c1 {
+        ...
+        /*
+         * An IC with several temperature sensor.
+         */
+        adc-dummy: sensor@0x50 {
+                ...
+                #thermal-sensor-cells = <1>; /* sensor internal ID */
+        };
+};
+thermal-zones {
+        batt-thermal {
+                polling-delay-passive = <500>; /* milliseconds */
+                polling-delay = <2500>; /* milliseconds */
+                                /* sensor       ID */
+                thermal-sensors = <&adc-dummy     4>;
+                trips {
+                        ...
+                };
+                cooling-maps {
+                        ...
+                };
+        };
+        board-thermal: board-thermal {
+                polling-delay-passive = <1000>; /* milliseconds */
+                polling-delay = <2500>; /* milliseconds */
+                                /* sensor       ID */
+                thermal-sensors = <&adc-dummy     0>, /* pcb top edge */
+                                  <&adc-dummy     1>, /* lcd */
+                                  <&adc-dymmy     2>; /* back cover */
+                /*
+                 * An array of coefficients describing the sensor
+                 * linear relation. E.g.:
+                 * z = c1*x1 + c2*x2 + c3*x3
+                 */
+                coefficients =          <1200   -345    890>;
+                trips {
+                        /* Trips are based on resulting linear equation */
+                        cpu-trip: cpu-trip {
+                                temperature = <60000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        };
+                        gpu-trip: gpu-trip {
+                                temperature = <55000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        }
+                        lcd-trip: lcp-trip {
+                                temperature = <53000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "passive";
+                        };
+                        crit-trip: crit-trip {
+                                temperature = <68000>; /* millicelsius */
+                                hysteresis = <2000>; /* millicelsius */
+                                type = "critical";
+                        };
+                };
+                cooling-maps {
+                        map0 {
+                                trip = <&cpu-trip>;
+                                cooling-device = <&cpu0 0 2>;
+                                contribution = <55>;
+                        };
+                        map1 {
+                                trip = <&gpu-trip>;
+                                cooling-device = <&gpu0 0 2>;
+                                contribution = <20>;
+                        };
+                        map2 {
+                                trip = <&lcd-trip>;
+                                cooling-device = <&lcd0 5 10>;
+                                contribution = <15>;
+                        };
+                };
+        };
+};
+The above example is a mix of previous examples, a sensor IP with several internal
+sensors used to monitor different zones, one of them is composed by several sensors and
+with different cooling devices.
diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt
index e019fdc38773..4a864bd10d3d 100644
--- a/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt
+++ b/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt
@@ -8,6 +8,8 @@ Required properties:
 - compatible : should be "nvidia,tegra20-timer".
 - reg : Specifies base physical address and size of the registers.
 - interrupts : A list of 4 interrupts; one per timer channel.
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
 Example:
@@ -18,4 +20,5 @@ timer {
                        0 1 0x04
                        0 41 0x04
                        0 42 0x04>;
+        clocks = <&tegra_car 132>;
 };
diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt
index 906109d4c593..b5082a1cf461 100644
--- a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt
+++ b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt
@@ -10,6 +10,8 @@ Required properties:
 - reg : Specifies base physical address and size of the registers.
 - interrupts : A list of 6 interrupts; one per each of timer channels 1
    through 5, and one for the shared interrupt for the remaining channels.
+- clocks : Must contain one entry, for the module clock.
+  See ../clocks/clock-bindings.txt for details.
 timer {
        compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer";
@@ -20,4 +22,5 @@ timer {
                      0 42 0x04
                      0 121 0x04
                      0 122 0x04>;
+        clocks = <&tegra_car 214>;
 };
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
index b5a86d20ee36..167d5dab9f64 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -31,38 +31,58 @@ Required properties:
        7: ..
        i: Local Timer Interrupt n
-Example 1: In this example, the system uses only the first global timer
+  For MCT block that uses a per-processor interrupt for local timers, such
-           interrupt generated by MCT and the remaining three global timer
+  as ones compatible with "samsung,exynos4412-mct", only one local timer
-           interrupts are unused. Two local timer interrupts have been
+  interrupt might be specified, meaning that all local timers use the same
-           specified.
+  per processor interrupt.
+Example 1: In this example, the IP contains two local timers, using separate
+           interrupts, so two local timer interrupts have been specified,
+           in addition to four global timer interrupts.
        mct@10050000 {
                compatible = "samsung,exynos4210-mct";
                reg = <0x10050000 0x800>;
-                interrupts = <0 57 0>, <0 0 0>, <0 0 0>, <0 0 0>,
+                interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
                             <0 42 0>, <0 48 0>;
        };
-Example 2: In this example, the MCT global and local timer interrupts are
+Example 2: In this example, the timer interrupts are connected to two separate
-           connected to two separate interrupt controllers. Hence, an
+           interrupt controllers. Hence, an interrupt-map is created to map
-           interrupt-map is created to map the interrupts to the respective
+           the interrupts to the respective interrupt controllers.
-           interrupt controllers.
        mct@101C0000 {
                compatible = "samsung,exynos4210-mct";
                reg = <0x101C0000 0x800>;
-                interrupt-controller;
-                #interrups-cells = <2>;
                interrupt-parent = <&mct_map>;
-                interrupts = <0 0>, <1 0>, <2 0>, <3 0>,
+                interrupts = <0>, <1>, <2>, <3>, <4>, <5>;
-                             <4 0>, <5 0>;
                mct_map: mct-map {
-                        #interrupt-cells = <2>;
+                        #interrupt-cells = <1>;
                        #address-cells = <0>;
                        #size-cells = <0>;
-                        interrupt-map = <0x0 0 &combiner 23 3>,
+                        interrupt-map = <0 &gic 0 57 0>,
-                                        <0x4 0 &gic 0 120 0>,
+                                        <1 &gic 0 69 0>,
-                                        <0x5 0 &gic 0 121 0>;
+                                        <2 &combiner 12 6>,
+                                        <3 &combiner 12 7>,
+                                        <4 &gic 0 42 0>,
+                                        <5 &gic 0 48 0>;
                };
        };
+Example 3: In this example, the IP contains four local timers, but using
+           a per-processor interrupt to handle them. Either all the local
+           timer interrupts can be specified, with the same interrupt specifier
+           value or just the first one.
+        mct@10050000 {
+                compatible = "samsung,exynos4412-mct";
+                reg = <0x10050000 0x800>;
+                /* Both ways are possible in this case. Either: */
+                interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
+                             <0 42 0>;
+                /* or: */
+                interrupts = <0 57 0>, <0 69 0>, <0 70 0>, <0 71 0>,
+                             <0 42 0>, <0 42 0>, <0 42 0>, <0 42 0>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
index b4b5b7906c88..b4b5b7906c88 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
diff --git a/Documentation/devicetree/bindings/usb/dwc2.txt b/Documentation/devicetree/bindings/usb/dwc2.txt
new file mode 100644
index 000000000000..b8b6871f116f
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc2.txt
@@ -0,0 +1,29 @@
+Platform DesignWare HS OTG USB 2.0 controller
+-----------------------------------------------------
+Required properties:
+- compatible : One of:
+  - brcm,bcm2835-usb: The DWC2 USB controller instance in the BCM2835 SoC.
+  - snps,dwc2: A generic DWC2 USB controller with default parameters.
+- reg : Should contain 1 register range (address and length)
+- interrupts : Should contain 1 interrupt
+- clocks: clock provider specifier
+- clock-names: shall be "otg"
+Refer to clk/clock-bindings.txt for generic clock consumer properties
+Optional properties:
+- phys: phy provider specifier
+- phy-names: shall be "device"
+Refer to phy/phy-bindings.txt for generic phy consumer properties
+Example:
+        usb@101c0000 {
+                compatible = "ralink,rt3050-usb, snps,dwc2";
+                reg = <0x101c0000 40000>;
+                interrupts = <18>;
+                clocks = <&usb_otg_ahb_clk>;
+                clock-names = "otg";
+                phys = <&usbphy>;
+                phy-names = "usb2-phy";
+        };
diff --git a/Documentation/devicetree/bindings/usb/gr-udc.txt b/Documentation/devicetree/bindings/usb/gr-udc.txt
new file mode 100644
index 000000000000..0c5118f7a916
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/gr-udc.txt
@@ -0,0 +1,28 @@
+USB Peripheral Controller driver for Aeroflex Gaisler GRUSBDC.
+The GRUSBDC USB Device Controller core is available in the GRLIB VHDL
+IP core library.
+Note: In the ordinary environment for the core, a Leon SPARC system,
+these properties are built from information in the AMBA plug&play.
+Required properties:
+- name : Should be "GAISLER_USBDC" or "01_021"
+- reg : Address and length of the register set for the device
+- interrupts : Interrupt numbers for this device
+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.
+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/keystone-phy.txt b/Documentation/devicetree/bindings/usb/keystone-phy.txt
new file mode 100644
index 000000000000..f37b3a86341d
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/keystone-phy.txt
@@ -0,0 +1,20 @@
+TI Keystone USB PHY
+Required properties:
+ - compatible: should be "ti,keystone-usbphy".
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+   with 'reg' property.
+ - reg : Address and length of the usb phy control register set.
+The main purpose of this PHY driver is to enable the USB PHY reference clock
+gate on the Keystone SOC for both the USB2 and USB3 PHY. Otherwise it is just
+an NOP PHY driver.  Hence this node is referenced as both the usb2 and usb3
+phy node in the USB Glue layer driver node.
+usb_phy: usb_phy@2620738 {
+        compatible = "ti,keystone-usbphy";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        reg = <0x2620738 32>;
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/usb/keystone-usb.txt b/Documentation/devicetree/bindings/usb/keystone-usb.txt
new file mode 100644
index 000000000000..60527d335b58
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/keystone-usb.txt
@@ -0,0 +1,42 @@
+TI Keystone Soc USB Controller
+DWC3 GLUE
+Required properties:
+ - compatible: should be "ti,keystone-dwc3".
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+   with 'reg' property.
+ - reg : Address and length of the register set for the USB subsystem on
+   the SOC.
+ - interrupts : The irq number of this device that is used to interrupt the
+   MPU.
+ - ranges: allows valid 1:1 translation between child's address space and
+   parent's address space.
+ - clocks: Clock IDs array as required by the controller.
+ - clock-names: names of clocks correseponding to IDs in the clock property.
+Sub-nodes:
+The dwc3 core should be added as subnode to Keystone DWC3 glue.
+- dwc3 :
+   The binding details of dwc3 can be found in:
+   Documentation/devicetree/bindings/usb/dwc3.txt
+Example:
+        usb: usb@2680000 {
+                compatible = "ti,keystone-dwc3";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                reg = <0x2680000 0x10000>;
+                clocks = <&clkusb>;
+                clock-names = "usb";
+                interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>;
+                ranges;
+                status = "disabled";
+                dwc3@2690000 {
+                        compatible = "synopsys,dwc3";
+                        reg = <0x2690000 0x70000>;
+                        interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>;
+                        usb-phy = <&usb_phy>, <&usb_phy>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index df0933043a5b..3dc9140e3dfb 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -8,7 +8,12 @@ and additions :
 Required properties :
 - compatible : Should be "nvidia,tegra20-ehci".
 - nvidia,phy : phandle of the PHY that the controller is connected to.
- - clocks : Contains a single entry which defines the USB controller's clock.
+ - clocks : Must contain one entry, for the module clock.
+   See ../clocks/clock-bindings.txt for details.
+ - resets : Must contain an entry for each entry in reset-names.
+   See ../reset/reset.txt for details.
+ - reset-names : Must include the following entries:
+   - usb
 Optional properties:
 - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 090e5e22bd2b..c495135115cb 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -87,6 +87,8 @@ Required properties:
                        e.g. USB3 PHY and SATA PHY on OMAP5.
 "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
                        DRA7 platform.
+ "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
+                        AM437 platform.
 - reg : Address and length of the register set for the device. It contains
   the address of "otghs_control" for control-phy-otghs or "power" register
   for other types.
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index edbb8d88c85e..3f900cd51bf0 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -3,12 +3,14 @@ Device tree binding vendor prefix registry.  Keep list in alphabetical order.
 This isn't an exhaustive list, but you should add new prefixes to it before
 using them to avoid name-space collisions.
+active-semi     Active-Semi International Inc
 ad      Avionic Design GmbH
 adi     Analog Devices, Inc.
 aeroflexgaisler Aeroflex Gaisler AB
 ak      Asahi Kasei Corp.
 altr    Altera Corp.
 amcc    Applied Micro Circuits Corporation (APM, formally AMCC)
+amstaos AMS-Taos Inc.
 apm     Applied Micro Circuits Corporation (APM)
 arm     ARM Ltd.
 atmel   Atmel Corporation
@@ -26,19 +28,25 @@ cortina	Cortina Systems, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
 davicom DAVICOM Semiconductor, Inc.
 denx    Denx Software Engineering
+edt     Emerging Display Technologies
 emmicro EM Microelectronic
+epfl    Ecole Polytechnique Fédérale de Lausanne
 epson   Seiko Epson Corp.
 est     ESTeem Wireless Modems
 fsl     Freescale Semiconductor
 GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gef     GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gmt     Global Mixed-mode Technology, Inc.
+gumstix Gumstix, Inc.
+haoyu   Haoyu Microelectronic Co. Ltd.
 hisilicon       Hisilicon Limited.
 hp      Hewlett Packard
 ibm     International Business Machines (IBM)
 idt     Integrated Device Technologies, Inc.
 img     Imagination Technologies Ltd.
 intercontrol    Inter Control Group
+isl     Intersil
+karo    Ka-Ro electronics GmbH
 lg      LG Corporation
 linux   Linux-specific binding
 lsi     LSI Corp. (LSI Logic)
@@ -61,6 +69,7 @@ ralink	Mediatek/Ralink Technology Corp.
 ramtron Ramtron International
 realtek Realtek Semiconductor Corp.
 renesas Renesas Electronics Corporation
+rockchip        Fuzhou Rockchip Electronics Co., Ltd
 samsung Samsung Semiconductor
 sbs     Smart Battery System
 schindler       Schindler
@@ -73,6 +82,7 @@ st	STMicroelectronics
 ste     ST-Ericsson
 stericsson      ST-Ericsson
 ti      Texas Instruments
+tlm     Trusted Logic Mobility
 toshiba Toshiba Corporation
 toumaz  Toumaz
 v3      V3 Semiconductor
diff --git a/Documentation/devicetree/bindings/video/ssd1289fb.txt b/Documentation/devicetree/bindings/video/ssd1289fb.txt
new file mode 100644
index 000000000000..4fcd5e68cb6e
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ssd1289fb.txt
@@ -0,0 +1,13 @@
+* Solomon SSD1289 Framebuffer Driver
+Required properties:
+  - compatible: Should be "solomon,ssd1289fb". The only supported bus for
+    now is lbc.
+  - reg: Should contain address of the controller on the LBC bus. The detail
+    was described in Documentation/devicetree/bindings/powerpc/fsl/lbc.txt
+Examples:
+display@2,0 {
+        compatible = "solomon,ssd1289fb";
+        reg = <0x2 0x0000 0x0004>;
+};
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
index fcdd48f7dcff..f90e294d7631 100644
--- a/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/atmel-wdt.txt
@@ -9,11 +9,37 @@ Required properties:
 Optional properties:
 - timeout-sec: contains the watchdog timeout in seconds.
+- interrupts : Should contain WDT interrupt.
+- atmel,max-heartbeat-sec : Should contain the maximum heartbeat value in
+        seconds. This value should be less or equal to 16. It is used to
+        compute the WDV field.
+- atmel,min-heartbeat-sec : Should contain the minimum heartbeat value in
+        seconds. This value must be smaller than the max-heartbeat-sec value.
+        It is used to compute the WDD field.
+- atmel,watchdog-type : Should be "hardware" or "software". Hardware watchdog
+        use the at91 watchdog reset. Software watchdog use the watchdog
+        interrupt to trigger a software reset.
+- atmel,reset-type : Should be "proc" or "all".
+        "all" : assert peripherals and processor reset signals
+        "proc" : assert the processor reset signal
+        This is valid only when using "hardware" watchdog.
+- atmel,disable : Should be present if you want to disable the watchdog.
+- atmel,idle-halt : Should be present if you want to stop the watchdog when
+        entering idle state.
+- atmel,dbg-halt : Should be present if you want to stop the watchdog when
+        entering debug state.
 Example:
        watchdog@fffffd40 {
                compatible = "atmel,at91sam9260-wdt";
                reg = <0xfffffd40 0x10>;
-                timeout-sec = <10>;
+                interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>;
+                timeout-sec = <15>;
+                atmel,watchdog-type = "hardware";
+                atmel,reset-type = "all";
+                atmel,dbg-halt;
+                atmel,idle-halt;
+                atmel,max-heartbeat-sec = <16>;
+                atmel,min-heartbeat-sec = <0>;
+                status = "okay";
        };
diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
index 75558ccd9a05..e60b9a13bdcb 100644
--- a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
@@ -1,12 +1,24 @@
-DaVinci Watchdog Timer (WDT) Controller
+Texas Instruments DaVinci/Keystone Watchdog Timer (WDT) Controller
 Required properties:
- compatible : Should be "ti,davinci-wdt"
+- compatible : Should be "ti,davinci-wdt", "ti,keystone-wdt"
 - reg : Should contain WDT registers location and length
+Optional properties:
+- timeout-sec : Contains the watchdog timeout in seconds
+- clocks : the clock feeding the watchdog timer.
+           Needed if platform uses clocks.
+           See clock-bindings.txt
+Documentation:
+Davinci DM646x - http://www.ti.com/lit/ug/spruer5b/spruer5b.pdf
+Keystone - http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
 Examples:
 wdt: wdt@2320000 {
        compatible = "ti,davinci-wdt";
        reg = <0x02320000 0x80>;
+        timeout-sec = <30>;
+        clocks = <&clkwdtimer0>;
 };
diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
new file mode 100644
index 000000000000..37afec194949
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
@@ -0,0 +1,23 @@
+* GPIO-controlled Watchdog
+Required Properties:
+- compatible: Should contain "linux,wdt-gpio".
+- gpios: From common gpio binding; gpio connection to WDT reset pin.
+- hw_algo: The algorithm used by the driver. Should be one of the
+  following values:
+  - toggle: Either a high-to-low or a low-to-high transition clears
+    the WDT counter. The watchdog timer is disabled when GPIO is
+    left floating or connected to a three-state buffer.
+  - level: Low or high level starts counting WDT timeout,
+    the opposite level disables the WDT. Active level is determined
+    by the GPIO flags.
+- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
+Example:
+        watchdog: watchdog {
+                /* ADM706 */
+                compatible = "linux,wdt-gpio";
+                gpios = <&gpio3 9 GPIO_ACTIVE_LOW>;
+                hw_algo = "toggle";
+                hw_margin_ms = <1600>;
+        };
diff --git a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
index 2aa486cc1ff6..cfff37511aac 100644
--- a/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/samsung-wdt.txt
@@ -5,10 +5,29 @@ after a preset amount of time during which the WDT reset event has not
 occurred.
 Required properties:
- compatible : should be "samsung,s3c2410-wdt"
+- compatible : should be one among the following
+        (a) "samsung,s3c2410-wdt" for Exynos4 and previous SoCs
+        (b) "samsung,exynos5250-wdt" for Exynos5250
+        (c) "samsung,exynos5420-wdt" for Exynos5420
 - reg : base physical address of the controller and length of memory mapped
        region.
 - interrupts : interrupt number to the cpu.
+- samsung,syscon-phandle : reference to syscon node (This property required only
+        in case of compatible being "samsung,exynos5250-wdt" or "samsung,exynos5420-wdt".
+        In case of Exynos5250 and 5420 this property points to syscon node holding the PMU
+        base address)
 Optional properties:
 - timeout-sec : contains the watchdog timeout in seconds.
+Example:
+watchdog@101D0000 {
+        compatible = "samsung,exynos5250-wdt";
+        reg = <0x101D0000 0x100>;
+        interrupts = <0 42 0>;
+        clocks = <&clock 336>;
+        clock-names = "watchdog";
+        samsung,syscon-phandle = <&pmu_syscon>;
+};
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index b2fb2f5e1922..1f013bd0d320 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -1364,19 +1364,16 @@ Appendix A - Sample SOC node for MPC8540
                                phy0: ethernet-phy@0 {
                                        interrupts = <5 1>;
                                        reg = <0>;
-                                        device_type = "ethernet-phy";
                                };
                                phy1: ethernet-phy@1 {
                                        interrupts = <5 1>;
                                        reg = <1>;
-                                        device_type = "ethernet-phy";
                                };
                                phy3: ethernet-phy@3 {
                                        interrupts = <7 1>;
                                        reg = <3>;
-                                        device_type = "ethernet-phy";
                                };
                        };
                };
diff --git a/Documentation/driver-model/design-patterns.txt b/Documentation/driver-model/design-patterns.txt
new file mode 100644
index 000000000000..ba7b2df64904
--- /dev/null
+++ b/Documentation/driver-model/design-patterns.txt
@@ -0,0 +1,116 @@
+Device Driver Design Patterns
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+This document describes a few common design patterns found in device drivers.
+It is likely that subsystem maintainers will ask driver developers to
+conform to these design patterns.
+1. State Container
+2. container_of()
+1. State Container
+~~~~~~~~~~~~~~~~~~
+While the kernel contains a few device drivers that assume that they will
+only be probed() once on a certain system (singletons), it is custom to assume
+that the device the driver binds to will appear in several instances. This
+means that the probe() function and all callbacks need to be reentrant.
+The most common way to achieve this is to use the state container design
+pattern. It usually has this form:
+struct foo {
+    spinlock_t lock; /* Example member */
+    (...)
+};
+static int foo_probe(...)
+{
+    struct foo *foo;
+    foo = devm_kzalloc(dev, sizeof(*foo), GFP_KERNEL);
+    if (!foo)
+        return -ENOMEM;
+    spin_lock_init(&foo->lock);
+    (...)
+}
+This will create an instance of struct foo in memory every time probe() is
+called. This is our state container for this instance of the device driver.
+Of course it is then necessary to always pass this instance of the
+state around to all functions that need access to the state and its members.
+For example, if the driver is registering an interrupt handler, you would
+pass around a pointer to struct foo like this:
+static irqreturn_t foo_handler(int irq, void *arg)
+{
+    struct foo *foo = arg;
+    (...)
+}
+static int foo_probe(...)
+{
+    struct foo *foo;
+    (...)
+    ret = request_irq(irq, foo_handler, 0, "foo", foo);
+}
+This way you always get a pointer back to the correct instance of foo in
+your interrupt handler.
+2. container_of()
+~~~~~~~~~~~~~~~~~
+Continuing on the above example we add an offloaded work:
+struct foo {
+    spinlock_t lock;
+    struct workqueue_struct *wq;
+    struct work_struct offload;
+    (...)
+};
+static void foo_work(struct work_struct *work)
+{
+    struct foo *foo = container_of(work, struct foo, offload);
+    (...)
+}
+static irqreturn_t foo_handler(int irq, void *arg)
+{
+    struct foo *foo = arg;
+    queue_work(foo->wq, &foo->offload);
+    (...)
+}
+static int foo_probe(...)
+{
+    struct foo *foo;
+    foo->wq = create_singlethread_workqueue("foo-wq");
+    INIT_WORK(&foo->offload, foo_work);
+    (...)
+}
+The design pattern is the same for an hrtimer or something similar that will
+return a single argument which is a pointer to a struct member in the
+callback.
+container_of() is a macro defined in <linux/kernel.h>
+What container_of() does is to obtain a pointer to the containing struct from
+a pointer to a member by a simple subtraction using the offsetof() macro from
+standard C, which allows something similar to object oriented behaviours.
+Notice that the contained member must not be a pointer, but an actual member
+for this to work.
+We can see here that we avoid having global pointers to our struct foo *
+instance this way, while still keeping the number of parameters passed to the
+work function to a single pointer.
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 5bdc8cb5fc28..4f7897e99cba 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -242,6 +242,8 @@ IIO
  devm_iio_device_free()
  devm_iio_trigger_alloc()
  devm_iio_trigger_free()
+  devm_iio_device_register()
+  devm_iio_device_unregister()
 IO region
  devm_request_region()
diff --git a/Documentation/driver-model/platform.txt b/Documentation/driver-model/platform.txt
index 41f41632ee55..07795ec51cde 100644
--- a/Documentation/driver-model/platform.txt
+++ b/Documentation/driver-model/platform.txt
@@ -48,7 +48,7 @@ struct platform_driver {
        struct device_driver driver;
 };
-Note that probe() should general verify that the specified device hardware
+Note that probe() should in general verify that the specified device hardware
 actually exists; sometimes platform setup code can't be sure.  The probing
 can use device resources, including clocks, and device platform_data.
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 1bbdcfcf1f13..46325eb2ea76 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -108,6 +108,12 @@ If your query set is big, you can batch them too:
  ~# cat query-batch-file > <debugfs>/dynamic_debug/control
+A another way is to use wildcard. The match rule support '*' (matches
+zero or more characters) and '?' (matches exactly one character).For
+example, you can match all usb drivers:
+  ~# echo "file drivers/usb/* +p" > <debugfs>/dynamic_debug/control
 At the syntactical level, a command comprises a sequence of match
 specifications, followed by a flags change specification.
@@ -315,6 +321,9 @@ 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"
+nullarbor:~ # echo -n '*usb* +p' > <debugfs>/dynamic_debug/control
 // enable all messages
 nullarbor:~ # echo -n '+p' > <debugfs>/dynamic_debug/control
diff --git a/Documentation/efi-stub.txt b/Documentation/efi-stub.txt
index 44e6bb6ead10..c628788d5b47 100644
--- a/Documentation/efi-stub.txt
+++ b/Documentation/efi-stub.txt
@@ -20,7 +20,7 @@ The EFI boot stub is enabled with the CONFIG_EFI_STUB kernel option.
 **** How to install bzImage.efi
 The bzImage located in arch/x86/boot/bzImage must be copied to the EFI
-System Partiion (ESP) and renamed with the extension ".efi". Without
+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.
diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt
index 860c29a472ad..e9f5daccbd02 100644
--- a/Documentation/email-clients.txt
+++ b/Documentation/email-clients.txt
@@ -104,7 +104,7 @@ Then from the "Message" menu item, select insert file and choose your patch.
 As an added bonus you can customise the message creation toolbar menu
 and put the "insert file" icon there.
-Make the the composer window wide enough so that no lines wrap. As of
+Make the composer window wide enough so that no lines wrap. As of
 KMail 1.13.5 (KDE 4.5.4), KMail will apply word wrapping when sending
 the email if the lines wrap in the composer window. Having word wrapping
 disabled in the Options menu isn't enough. Thus, if your patch has very
diff --git a/Documentation/extcon/porting-android-switch-class b/Documentation/extcon/porting-android-switch-class
index 5377f6317961..49c81caef84d 100644
--- a/Documentation/extcon/porting-android-switch-class
+++ b/Documentation/extcon/porting-android-switch-class
@@ -50,7 +50,7 @@ so that they are still compatible with legacy userspace processes.
        Extcon's extended features for switch device drivers with
        complex features usually required magic numbers in state
        value of switch_dev. With extcon, such magic numbers that
-        support multiple cables (
+        support multiple cables are no more required or supported.
  1. Define cable names at edev->supported_cable.
  2. (Recommended) remove print_state callback.
@@ -114,11 +114,8 @@ exclusive, the two cables cannot be in ATTACHED state simulteneously.
 ****** ABI Location
-  If "CONFIG_ANDROID" is enabled and "CONFIG_ANDROID_SWITCH" is
+  If "CONFIG_ANDROID" is enabled, /sys/class/switch/* are created
-disabled, /sys/class/switch/* are created as symbolic links to
+as symbolic links to /sys/class/extcon/*.
-/sys/class/extcon/*. Because CONFIG_ANDROID_SWITCH creates
-/sys/class/switch directory, we disable symboling linking if
-CONFIG_ANDROID_SWITCH is enabled.
  The two files of switch class, name and state, are provided with
 extcon, too. When the multistate support (STEP 2 of CHAPTER 1.) is
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index 8042050eb265..632211cbdd56 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -10,24 +10,32 @@ afs.txt
        - info and examples for the distributed AFS (Andrew File System) fs.
 affs.txt
        - info and mount options for the Amiga Fast File System.
+autofs4-mount-control.txt
+        - info on device control operations for autofs4 module.
 automount-support.txt
        - information about filesystem automount support.
 befs.txt
        - information about the BeOS filesystem for Linux.
 bfs.txt
        - info for the SCO UnixWare Boot Filesystem (BFS).
+btrfs.txt
+        - info for the BTRFS filesystem.
+caching/
+        - directory containing filesystem cache documentation.
 ceph.txt
-        - info for the Ceph Distributed File System
+        - info for the Ceph Distributed File System.
-cifs.txt
+cifs/
-        - description of the CIFS filesystem.
+        - directory containing CIFS filesystem documentation and example code.
 coda.txt
        - description of the CODA filesystem.
 configfs/
        - directory containing configfs documentation and example code.
 cramfs.txt
        - info on the cram filesystem for small storage (ROMs etc).
-dentry-locking.txt
+debugfs.txt
-        - info on the RCU-based dcache locking model.
+        - info on the debugfs filesystem.
+devpts.txt
+        - info on the devpts filesystem.
 directory-locking
        - info about the locking scheme used for directory operations.
 dlmfs.txt
@@ -35,7 +43,7 @@ dlmfs.txt
 dnotify.txt
        - info about directory notification in Linux.
 dnotify_test.c
-        - example program for dnotify
+        - example program for dnotify.
 ecryptfs.txt
        - docs on eCryptfs: stacked cryptographic filesystem for Linux.
 efivarfs.txt
@@ -48,12 +56,18 @@ ext3.txt
        - info, mount options and specifications for the Ext3 filesystem.
 ext4.txt
        - info, mount options and specifications for the Ext4 filesystem.
-files.txt
-        - info on file management in the Linux kernel.
 f2fs.txt
        - info and mount options for the F2FS filesystem.
+fiemap.txt
+        - info on fiemap ioctl.
+files.txt
+        - info on file management in the Linux kernel.
 fuse.txt
        - info on the Filesystem in User SpacE including mount options.
+gfs2-glocks.txt
+        - info on the Global File System 2 - Glock internal locking rules.
+gfs2-uevents.txt
+        - info on the Global File System 2 - uevents.
 gfs2.txt
        - info on the Global File System 2.
 hfs.txt
@@ -84,40 +98,58 @@ ntfs.txt
        - info and mount options for the NTFS filesystem (Windows NT).
 ocfs2.txt
        - info and mount options for the OCFS2 clustered filesystem.
+omfs.txt
+        - info on the Optimized MPEG FileSystem.
+path-lookup.txt
+        - info on path walking and name lookup locking.
+pohmelfs/
+        - directory containing pohmelfs filesystem documentation.
 porting
        - various information on filesystem porting.
 proc.txt
        - info on Linux's /proc filesystem.
+qnx6.txt
+        - info on the QNX6 filesystem.
+quota.txt
+        - info on Quota subsystem.
 ramfs-rootfs-initramfs.txt
        - info on the 'in memory' filesystems ramfs, rootfs and initramfs.
-reiser4.txt
-        - info on the Reiser4 filesystem based on dancing tree algorithms.
 relay.txt
        - info on relay, for efficient streaming from kernel to user space.
 romfs.txt
        - description of the ROMFS filesystem.
 seq_file.txt
-        - how to use the seq_file API
+        - how to use the seq_file API.
 sharedsubtree.txt
        - a description of shared subtrees for namespaces.
 spufs.txt
        - info and mount options for the SPU filesystem used on Cell.
+squashfs.txt
+        - info on the squashfs filesystem.
 sysfs-pci.txt
        - info on accessing PCI device resources through sysfs.
+sysfs-tagging.txt
+        - info on sysfs tagging to avoid duplicates.
 sysfs.txt
        - info on sysfs, a ram-based filesystem for exporting kernel objects.
 sysv-fs.txt
        - info on the SystemV/V7/Xenix/Coherent filesystem.
 tmpfs.txt
        - info on tmpfs, a filesystem that holds all files in virtual memory.
+ubifs.txt
+        - info on the Unsorted Block Images FileSystem.
 udf.txt
        - info and mount options for the UDF filesystem.
 ufs.txt
        - info on the ufs filesystem.
 vfat.txt
-        - info on using the VFAT filesystem used in Windows NT and Windows 95
+        - info on using the VFAT filesystem used in Windows NT and Windows 95.
 vfs.txt
-        - overview of the Virtual File System
+        - overview of the Virtual File System.
+xfs-delayed-logging-design.txt
+        - info on the XFS Delayed Logging Design.
+xfs-self-describing-metadata.txt
+        - info on XFS Self Describing Metadata.
 xfs.txt
        - info and mount options for the XFS filesystem.
 xip.txt
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index 2c0321442845..fec7144e817c 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -69,10 +69,14 @@ OPTIONS
                offering several exported file systems.
  cache=mode    specifies a caching policy.  By default, no caches are used.
+                        none = default no cache policy, metadata and data
+                                alike are synchronous.
                        loose = no attempts are made at consistency,
                                intended for exclusive, read-only mounts
-                        fscache = use FS-Cache for a persistent, read-only
+                        fscache = use FS-Cache for a persistent, read-only
                                cache backend.
+                        mmap = minimal cache that is only used for read-write
+                                mmap.  Northing else is cached, like cache=none
  debug=n       specifies debug level.  The debug level is a bitmask.
                        0x01  = display verbose error messages
@@ -147,8 +151,7 @@ on sourceforge (http://sourceforge.net/projects/v9fs).
 News and other information is maintained on a Wiki.
 (http://sf.net/apps/mediawiki/v9fs/index.php).
-Bug reports may be issued through the kernel.org bugzilla 
+Bug reports are best issued via the mailing list.
-(http://bugzilla.kernel.org)
 For more information on the Plan 9 Operating System check out
 http://plan9.bell-labs.com/plan9
@@ -156,11 +159,3 @@ http://plan9.bell-labs.com/plan9
 For information on Plan 9 from User Space (Plan 9 applications and libraries
 ported to Linux/BSD/OSX/etc) check out http://swtch.com/plan9
-STATUS
-======
-The 2.6 kernel support is working on PPC and x86.
-PLEASE USE THE KERNEL BUGZILLA TO REPORT PROBLEMS. (http://bugzilla.kernel.org)
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index fe7afe225381..5b0c083d7c0e 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -544,7 +544,7 @@ like the ->fault() handler, but simply return with VM_FAULT_NOPAGE, which
 will cause the VM to retry the fault.
        ->access() is called when get_user_pages() fails in
-acces_process_vm(), typically used to debug a process through
+access_process_vm(), typically used to debug a process through
 /proc/pid/mem or ptrace.  This function is needed only for
 VM_IO | VM_PFNMAP VMAs.
diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt
index 5dd282dda55c..d11cc2f8077b 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.txt
@@ -38,7 +38,7 @@ Mount Options
 =============
 When mounting a btrfs filesystem, the following option are accepted.
-Unless otherwise specified, all options default to off.
+Options with (*) are default options and will not show in the mount options.
  alloc_start=<bytes>
        Debugging option to force all block allocations above a certain
@@ -46,10 +46,12 @@ Unless otherwise specified, all options default to off.
        bytes, optionally with a K, M, or G suffix, case insensitive.
        Default is 1MB.
+  noautodefrag(*)
  autodefrag
-        Detect small random writes into files and queue them up for the
+        Disable/enable auto defragmentation.
-        defrag process.  Works best for small files; Not well suited for
+        Auto defragmentation detects small random writes into files and queue
-        large database workloads.
+        them up for the defrag process.  Works best for small files;
+        Not well suited for large database workloads.
  check_int
  check_int_data
@@ -96,21 +98,26 @@ Unless otherwise specified, all options default to off.
        can be avoided.  Especially useful when trying to mount a multi-device
        setup as root.  May be specified multiple times for multiple devices.
+  nodiscard(*)
  discard
-        Issue frequent commands to let the block device reclaim space freed by
+        Disable/enable discard mount option.
-        the filesystem.  This is useful for SSD devices, thinly provisioned
+        Discard issues frequent commands to let the block device reclaim space
+        freed by the filesystem.
+        This is useful for SSD devices, thinly provisioned
        LUNs and virtual machine images, but may have a significant
        performance impact.  (The fstrim command is also available to
        initiate batch trims from userspace).
+  noenospc_debug(*)
  enospc_debug
-        Debugging option to be more verbose in some ENOSPC conditions.
+        Disable/enable debugging option to be more verbose in some ENOSPC conditions.
  fatal_errors=<action>
        Action to take when encountering a fatal error: 
          "bug" - BUG() on a fatal error.  This is the default.
          "panic" - panic() on a fatal error.
+  noflushoncommit(*)
  flushoncommit
        The 'flushoncommit' mount option forces any data dirtied by a write in a
        prior transaction to commit as part of the current commit.  This makes
@@ -134,26 +141,32 @@ Unless otherwise specified, all options default to off.
        Specify that 1 metadata chunk should be allocated after every <value>
        data chunks.  Off by default.
+  acl(*)
  noacl
-        Disable support for Posix Access Control Lists (ACLs).  See the
+        Enable/disable support for Posix Access Control Lists (ACLs).  See the
        acl(5) manual page for more information about ACLs.
+  barrier(*)
  nobarrier
-        Disables the use of block layer write barriers.  Write barriers ensure
+        Enable/disable the use of block layer write barriers.  Write barriers
-        that certain IOs make it through the device cache and are on persistent
+        ensure that certain IOs make it through the device cache and are on
-        storage.  If used on a device with a volatile (non-battery-backed)
+        persistent storage. If disabled on a device with a volatile
-        write-back cache, this option will lead to filesystem corruption on a
+        (non-battery-backed) write-back cache, nobarrier option will lead to
-        system crash or power loss.
+        filesystem corruption on a system crash or power loss.
+  datacow(*)
  nodatacow
-        Disable data copy-on-write for newly created files.  Implies nodatasum,
+        Enable/disable data copy-on-write for newly created files.
-        and disables all compression.
+        Nodatacow implies nodatasum, and disables all compression.
+  datasum(*)
  nodatasum
-        Disable data checksumming for newly created files.
+        Enable/disable data checksumming for newly created files.
+        Datasum implies datacow.
+  treelog(*)
  notreelog
-        Disable the tree logging used for fsync and O_SYNC writes.
+        Enable/disable the tree logging used for fsync and O_SYNC writes.
  recovery
        Enable autorecovery attempts if a bad tree root is found at mount time.
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index a3fe811bbdbc..b8d284975f0f 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -120,6 +120,8 @@ active_logs=%u         Support configuring the number of active logs. In the
 disable_ext_identify   Disable the extension list configured by mkfs, so f2fs
                       does not aware of cold files such as media files.
 inline_xattr           Enable the inline xattrs feature.
+inline_data            Enable the inline data feature: New created small(<~3.4k)
+                       files can be written into inode block.
 ================================================================================
 DEBUGFS ENTRIES
@@ -171,6 +173,28 @@ Files in /sys/fs/f2fs/<devname>
                              conduct checkpoint to reclaim the prefree segments
                              to free segments. By default, 100 segments, 200MB.
+ max_small_discards           This parameter controls the number of discard
+                              commands that consist small blocks less than 2MB.
+                              The candidates to be discarded are cached until
+                              checkpoint is triggered, and issued during the
+                              checkpoint. By default, it is disabled with 0.
+ ipu_policy                   This parameter controls the policy of in-place
+                              updates in f2fs. There are five policies:
+                               0: F2FS_IPU_FORCE, 1: F2FS_IPU_SSR,
+                               2: F2FS_IPU_UTIL,  3: F2FS_IPU_SSR_UTIL,
+                               4: F2FS_IPU_DISABLE.
+ min_ipu_util                 This parameter controls the threshold to trigger
+                              in-place-updates. The number indicates percentage
+                              of the filesystem utilization, and used by
+                              F2FS_IPU_UTIL and F2FS_IPU_SSR_UTIL policies.
+ max_victim_search            This parameter controls the number of trials to
+                              find a victim segment when conducting SSR and
+                              cleaning operations. The default value is 4096
+                              which covers 8GB block address range.
 ================================================================================
 USAGE
 ================================================================================
diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt
index 01c2db769791..b930ad087780 100644
--- a/Documentation/filesystems/nfs/nfs41-server.txt
+++ b/Documentation/filesystems/nfs/nfs41-server.txt
@@ -5,11 +5,11 @@ Server support for minorversion 1 can be controlled using the
 by reading this file will contain either "+4.1" or "-4.1"
 correspondingly.
-Currently, server support for minorversion 1 is disabled by default.
+Currently, server support for minorversion 1 is enabled by default.
-It can be enabled at run time by writing the string "+4.1" to
+It can be disabled at run time by writing the string "-4.1" to
 the /proc/fs/nfsd/versions control file.  Note that to write this
-control file, the nfsd service must be taken down.  Use your user-mode
+control file, the nfsd service must be taken down.  You can use rpc.nfsd
-nfs-utils to set this up; see rpc.nfsd(8)
+for this; see rpc.nfsd(8).
 (Warning: older servers will interpret "+4.1" and "-4.1" as "+4" and
 "-4", respectively.  Therefore, code meant to work on both new and old
@@ -29,29 +29,6 @@ are still under development out of tree.
 See http://wiki.linux-nfs.org/wiki/index.php/PNFS_prototype_design
 for more information.
-The current implementation is intended for developers only: while it
-does support ordinary file operations on clients we have tested against
-(including the linux client), it is incomplete in ways which may limit
-features unexpectedly, cause known bugs in rare cases, or cause
-interoperability problems with future clients.  Known issues:
-        - gss support is questionable: currently mounts with kerberos
-          from a linux client are possible, but we aren't really
-          conformant with the spec (for example, we don't use kerberos
-          on the backchannel correctly).
-        - We do not support SSV, which provides security for shared
-          client-server state (thus preventing unauthorized tampering
-          with locks and opens, for example).  It is mandatory for
-          servers to support this, though no clients use it yet.
-In addition, some limitations are inherited from the current NFSv4
-implementation:
-        - Incomplete delegation enforcement: if a file is renamed or
-          unlinked by a local process, a client holding a delegation may
-          continue to indefinitely allow opens of the file under the old
-          name.
 The table below, taken from the NFSv4.1 document, lists
 the operations that are mandatory to implement (REQ), optional
 (OPT), and NFSv4.0 operations that are required not to implement (MNI)
@@ -169,6 +146,16 @@ NS*| CB_WANTS_CANCELLED      | OPT       | FDELG,      | Section 20.10 |
 Implementation notes:
+SSV:
+* The spec claims this is mandatory, but we don't actually know of any
+  implementations, so we're ignoring it for now.  The server returns
+  NFS4ERR_ENCR_ALG_UNSUPP on EXCHANGE_ID, which should be future-proof.
+GSS on the backchannel:
+* Again, theoretically required but not widely implemented (in
+  particular, the current Linux client doesn't request it).  We return
+  NFS4ERR_ENCR_ALG_UNSUPP on CREATE_SESSION.
 DELEGPURGE:
 * mandatory only for servers that support CLAIM_DELEGATE_PREV and/or
  CLAIM_DELEG_PREV_FH (which allows clients to keep delegations that
@@ -176,7 +163,6 @@ DELEGPURGE:
  now.
 EXCHANGE_ID:
-* only SP4_NONE state protection supported
 * implementation ids are ignored
 CREATE_SESSION:
diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt
index 873a2ab2e9f8..06887d46ccf2 100644
--- a/Documentation/filesystems/nilfs2.txt
+++ b/Documentation/filesystems/nilfs2.txt
@@ -81,6 +81,62 @@ nodiscard(*)		The discard/TRIM commands are sent to the underlying
                        block device when blocks are freed.  This is useful
                        for SSD devices and sparse/thinly-provisioned LUNs.
+Ioctls
+======
+There is some NILFS2 specific functionality which can be accessed by applications
+through the system call interfaces. The list of all NILFS2 specific ioctls are
+shown in the table below.
+Table of NILFS2 specific ioctls
+..............................................................................
+ Ioctl                          Description
+ NILFS_IOCTL_CHANGE_CPMODE      Change mode of given checkpoint between
+                                checkpoint and snapshot state. This ioctl is
+                                used in chcp and mkcp utilities.
+ NILFS_IOCTL_DELETE_CHECKPOINT  Remove checkpoint from NILFS2 file system.
+                                This ioctl is used in rmcp utility.
+ NILFS_IOCTL_GET_CPINFO         Return info about requested checkpoints. This
+                                ioctl is used in lscp utility and by
+                                nilfs_cleanerd daemon.
+ NILFS_IOCTL_GET_CPSTAT         Return checkpoints statistics. This ioctl is
+                                used by lscp, rmcp utilities and by
+                                nilfs_cleanerd daemon.
+ NILFS_IOCTL_GET_SUINFO         Return segment usage info about requested
+                                segments. This ioctl is used in lssu,
+                                nilfs_resize utilities and by nilfs_cleanerd
+                                daemon.
+ NILFS_IOCTL_GET_SUSTAT         Return segment usage statistics. This ioctl
+                                is used in lssu, nilfs_resize utilities and
+                                by nilfs_cleanerd daemon.
+ NILFS_IOCTL_GET_VINFO          Return information on virtual block addresses.
+                                This ioctl is used by nilfs_cleanerd daemon.
+ NILFS_IOCTL_GET_BDESCS         Return information about descriptors of disk
+                                block numbers. This ioctl is used by
+                                nilfs_cleanerd daemon.
+ NILFS_IOCTL_CLEAN_SEGMENTS     Do garbage collection operation in the
+                                environment of requested parameters from
+                                userspace. This ioctl is used by
+                                nilfs_cleanerd daemon.
+ NILFS_IOCTL_SYNC               Make a checkpoint. This ioctl is used in
+                                mkcp utility.
+ NILFS_IOCTL_RESIZE             Resize NILFS2 volume. This ioctl is used
+                                by nilfs_resize utility.
+ NILFS_IOCTL_SET_ALLOC_RANGE    Define lower limit of segments in bytes and
+                                upper limit of segments in bytes. This ioctl
+                                is used by nilfs_resize utility.
 NILFS2 usage
 ============
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 22d89aa37218..f00bee144add 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -547,7 +547,7 @@ Table 1-5: Kernel info in /proc
 sys         See chapter 2                                     
 sysvipc     Info of SysVIPC Resources (msg, sem, shm)          (2.4)
 tty         Info of tty drivers
- uptime      System uptime                                     
+ uptime      Wall clock since boot, combined idle time of all cpus
 version     Kernel version                                    
 video       bttv info of video resources                       (2.4)
 vmallocinfo Show vmalloced areas
@@ -767,6 +767,7 @@ The "Locked" indicates whether the mapping is locked in memory or not.
 MemTotal:     16344972 kB
 MemFree:      13634064 kB
+MemAvailable: 14836172 kB
 Buffers:          3656 kB
 Cached:        1195708 kB
 SwapCached:          0 kB
@@ -799,6 +800,14 @@ AnonHugePages:   49152 kB
    MemTotal: Total usable ram (i.e. physical ram minus a few reserved
              bits and the kernel binary code)
     MemFree: The sum of LowFree+HighFree
+MemAvailable: An estimate of how much memory is available for starting new
+              applications, without swapping. Calculated from MemFree,
+              SReclaimable, the size of the file LRU lists, and the low
+              watermarks in each zone.
+              The estimate takes into account that the system needs some
+              page cache to function well, and that not all reclaimable
+              slab will be reclaimable, due to items being in use. The
+              impact of those factors will vary from system to system.
     Buffers: Relatively temporary storage for raw disk blocks
              shouldn't get tremendously large (20MB or so)
      Cached: in-memory cache for files read from the disk (the
@@ -1377,8 +1386,8 @@ may allocate from based on an estimation of its current memory and swap use.
 For example, if a task is using all allowed memory, its badness score will be
 1000.  If it is using half of its allowed memory, its score will be 500.
-There is an additional factor included in the badness score: root
+There is an additional factor included in the badness score: the current memory
-processes are given 3% extra memory over other tasks.
+and swap usage is discounted by 3% for root processes.
 The amount of "allowed" memory depends on the context in which the oom killer
 was called.  If it is due to the memory assigned to the allocating task's cpuset
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index a6619b7064b9..b35a64b82f9e 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -108,12 +108,12 @@ static DEVICE_ATTR(foo, S_IWUSR | S_IRUGO, show_foo, store_foo);
 is equivalent to doing:
 static struct device_attribute dev_attr_foo = {
-       .attr    = {
+        .attr = {
                .name = "foo",
                .mode = S_IWUSR | S_IRUGO,
-                .show = show_foo,
-                .store = store_foo,
        },
+        .show = show_foo,
+        .store = store_foo,
 };
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index deb48b5fd883..c53784c119c8 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -782,7 +782,7 @@ struct file_operations
 ----------------------
 This describes how the VFS can manipulate an open file. As of kernel
-3.5, the following members are defined:
+3.12, the following members are defined:
 struct file_operations {
        struct module *owner;
@@ -803,9 +803,6 @@ struct file_operations {
        int (*aio_fsync) (struct kiocb *, int datasync);
        int (*fasync) (int, struct file *, int);
        int (*lock) (struct file *, int, struct file_lock *);
-        ssize_t (*readv) (struct file *, const struct iovec *, unsigned long, loff_t *);
-        ssize_t (*writev) (struct file *, const struct iovec *, unsigned long, loff_t *);
-        ssize_t (*sendfile) (struct file *, loff_t *, size_t, read_actor_t, void *);
        ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
        unsigned long (*get_unmapped_area)(struct file *, unsigned long, unsigned long, unsigned long, unsigned long);
        int (*check_flags)(int);
@@ -814,6 +811,7 @@ struct file_operations {
        ssize_t (*splice_read)(struct file *, struct pipe_inode_info *, size_t, unsigned int);
        int (*setlease)(struct file *, long arg, struct file_lock **);
        long (*fallocate)(struct file *, int mode, loff_t offset, loff_t len);
+        int (*show_fdinfo)(struct seq_file *m, struct file *f);
 };
 Again, all methods are called without any locks being held, unless
@@ -864,12 +862,6 @@ otherwise noted.
  lock: called by the fcntl(2) system call for F_GETLK, F_SETLK, and F_SETLKW
        commands
-  readv: called by the readv(2) system call
-  writev: called by the writev(2) system call
-  sendfile: called by the sendfile(2) system call
  get_unmapped_area: called by the mmap(2) system call
  check_flags: called by the fcntl(2) system call for F_SETFL command
diff --git a/Documentation/gpio/board.txt b/Documentation/gpio/board.txt
index 0d03506f2cc5..ba169faad5c6 100644
--- a/Documentation/gpio/board.txt
+++ b/Documentation/gpio/board.txt
@@ -72,10 +72,11 @@ where
  - chip_label is the label of the gpiod_chip instance providing the GPIO
  - chip_hwnum is the hardware number of the GPIO within the chip
-  - dev_id is the identifier of the device that will make use of this GPIO. If
+  - dev_id is the identifier of the device that will make use of this GPIO. It
-        NULL, the GPIO will be available to all devices.
+        can be NULL, in which case it will be matched for calls to gpiod_get()
+        with a NULL device.
  - con_id is the name of the GPIO function from the device point of view. It
-        can be NULL.
+        can be NULL, in which case it will match any function.
  - idx is the index of the GPIO within the function.
  - flags is defined to specify the following properties:
        * GPIOF_ACTIVE_LOW      - to configure the GPIO as active-low
@@ -86,18 +87,23 @@ In the future, these flags might be extended to support more properties.
 Note that GPIO_LOOKUP() is just a shortcut to GPIO_LOOKUP_IDX() where idx = 0.
-A lookup table can then be defined as follows:
+A lookup table can then be defined as follows, with an empty entry defining its
+end:
-        struct gpiod_lookup gpios_table[] = {
+struct gpiod_lookup_table gpios_table = {
-        GPIO_LOOKUP_IDX("gpio.0", 15, "foo.0", "led", 0, GPIO_ACTIVE_HIGH),
+        .dev_id = "foo.0",
-        GPIO_LOOKUP_IDX("gpio.0", 16, "foo.0", "led", 1, GPIO_ACTIVE_HIGH),
+        .table = {
-        GPIO_LOOKUP_IDX("gpio.0", 17, "foo.0", "led", 2, GPIO_ACTIVE_HIGH),
+                GPIO_LOOKUP_IDX("gpio.0", 15, "led", 0, GPIO_ACTIVE_HIGH),
-        GPIO_LOOKUP("gpio.0", 1, "foo.0", "power", GPIO_ACTIVE_LOW),
+                GPIO_LOOKUP_IDX("gpio.0", 16, "led", 1, GPIO_ACTIVE_HIGH),
-        };
+                GPIO_LOOKUP_IDX("gpio.0", 17, "led", 2, GPIO_ACTIVE_HIGH),
+                GPIO_LOOKUP("gpio.0", 1, "power", GPIO_ACTIVE_LOW),
+                { },
+        },
+};
 And the table can be added by the board code as follows:
-        gpiod_add_table(gpios_table, ARRAY_SIZE(gpios_table));
+        gpiod_add_lookup_table(&gpios_table);
 The driver controlling "foo.0" will then be able to obtain its GPIOs as follows:
diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt
index 07c74a3765a0..e42f77d8d4ca 100644
--- a/Documentation/gpio/consumer.txt
+++ b/Documentation/gpio/consumer.txt
@@ -38,7 +38,11 @@ device that displays digits), an additional index argument can be specified:
                                          const char *con_id, unsigned int idx)
 Both functions return either a valid GPIO descriptor, or an error code checkable
-with IS_ERR(). They will never return a NULL pointer.
+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
+errors and an absence of GPIO for optional GPIO parameters.
 Device-managed variants of these functions are also defined:
diff --git a/Documentation/hwmon/adm1025 b/Documentation/hwmon/adm1025
index 39d2b781b5d6..99f05049c68a 100644
--- a/Documentation/hwmon/adm1025
+++ b/Documentation/hwmon/adm1025
@@ -18,7 +18,7 @@ The NE1619 presents some differences with the original ADM1025:
 Authors:
        Chen-Yuan Wu <gwu@esoft.com>,
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/adm1031 b/Documentation/hwmon/adm1031
index be92a77da1d5..a143117c99cb 100644
--- a/Documentation/hwmon/adm1031
+++ b/Documentation/hwmon/adm1031
@@ -16,7 +16,7 @@ Supported chips:
 Authors:
        Alexandre d'Alton <alex@alexdalton.org>
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/adm9240 b/Documentation/hwmon/adm9240
index 36e8ec6aa868..9b174fc700cc 100644
--- a/Documentation/hwmon/adm9240
+++ b/Documentation/hwmon/adm9240
@@ -25,7 +25,7 @@ Authors:
    Philip Edelbrock <phil@netroedge.com>,
    Michiel Rook <michiel@grendelproject.nl>,
    Grant Coady <gcoady.lk@gmail.com> with guidance
-        from Jean Delvare <khali@linux-fr.org>
+        from Jean Delvare <jdelvare@suse.de>
 Interface
 ---------
diff --git a/Documentation/hwmon/ds1621 b/Documentation/hwmon/ds1621
index 896cdc972ca8..f775e612f582 100644
--- a/Documentation/hwmon/ds1621
+++ b/Documentation/hwmon/ds1621
@@ -31,7 +31,7 @@ Authors:
        Christian W. Zuckschwerdt <zany@triq.net>
        valuable contributions by Jan M. Sendler <sendler@sendler.de>
        ported to 2.6 by Aurelien Jarno <aurelien@aurel32.net>
-        with the help of Jean Delvare <khali@linux-fr.org>
+        with the help of Jean Delvare <jdelvare@suse.de>
 Module Parameters
 ------------------
diff --git a/Documentation/hwmon/emc6w201 b/Documentation/hwmon/emc6w201
index 32f355aaf56b..757629b12897 100644
--- a/Documentation/hwmon/emc6w201
+++ b/Documentation/hwmon/emc6w201
@@ -7,7 +7,7 @@ Supported chips:
    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
    Datasheet: Not public
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 Description
diff --git a/Documentation/hwmon/f71805f b/Documentation/hwmon/f71805f
index f0d55976740a..48a356084bc6 100644
--- a/Documentation/hwmon/f71805f
+++ b/Documentation/hwmon/f71805f
@@ -15,7 +15,7 @@ Supported chips:
    Addresses scanned: none, address read from Super I/O config space
    Datasheet: Available from the Fintek website
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 Thanks to Denis Kieft from Barracuda Networks for the donation of a
 test system (custom Jetway K8M8MS motherboard, with CPU and RAM) and
diff --git a/Documentation/hwmon/gl518sm b/Documentation/hwmon/gl518sm
index 26f9f3c02dc7..494bb55b6e72 100644
--- a/Documentation/hwmon/gl518sm
+++ b/Documentation/hwmon/gl518sm
@@ -14,7 +14,7 @@ Authors:
        Frodo Looijaard <frodol@dds.nl>,
        Kyösti Mälkki <kmalkki@cc.hut.fi>
        Hong-Gunn Chew <hglinux@gunnet.org>
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index c263740f0cba..0c1635082c99 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -2,6 +2,10 @@ Kernel driver it87
 ==================
 Supported chips:
+  * IT8603E
+    Prefix: 'it8603'
+    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Datasheet: Not publicly available
  * IT8705F
    Prefix: 'it87'
    Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -53,7 +57,7 @@ Supported chips:
 Authors:
    Christophe Gauthron
-    Jean Delvare <khali@linux-fr.org>
+    Jean Delvare <jdelvare@suse.de>
 Module Parameters
@@ -90,7 +94,7 @@ motherboard models.
 Description
 -----------
-This driver implements support for the IT8705F, IT8712F, IT8716F,
+This driver implements support for the IT8603E, IT8705F, IT8712F, IT8716F,
 IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E,
 IT8782F, IT8783E/F, and SiS950 chips.
@@ -129,6 +133,10 @@ to userspace applications.
 The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F,
 until a datasheet becomes available (hopefully.)
+The IT8603E is a custom design, hardware monitoring part is similar to
+IT8728F. It only supports 16-bit fan mode, the full speed mode of the
+fan is not supported (value 0 of pwmX_enable).
 Temperatures are measured in degrees Celsius. An alarm is triggered once
 when the Overtemperature Shutdown limit is crossed.
@@ -145,13 +153,16 @@ alarm is triggered if the voltage has crossed a programmable minimum or
 maximum limit. Note that minimum in this case always means 'closest to
 zero'; this is important for negative voltage measurements. All voltage
 inputs can measure voltages between 0 and 4.08 volts, with a resolution of
-0.016 volt (except IT8721F/IT8758E and IT8728F: 0.012 volt.) The battery
+0.016 volt (except IT8603E, IT8721F/IT8758E and IT8728F: 0.012 volt.) The
-voltage in8 does not have limit registers.
+battery voltage in8 does not have limit registers.
-On the IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs are
+On the IT8603E, IT8721F/IT8758E, IT8782F, and IT8783E/F, some voltage inputs
-internal and scaled inside the chip (in7 (optional for IT8782F and IT8783E/F),
+are internal and scaled inside the chip:
-in8 and optionally in3). The driver handles this transparently so user-space
+* in3 (optional)
-doesn't have to care.
+* in7 (optional for IT8782F and IT8783E/F)
+* in8 (always)
+* in9 (relevant for IT8603E only)
+The driver handles this transparently so user-space doesn't have to care.
 The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
 the voltage level your processor should work with. This is hardcoded by
diff --git a/Documentation/hwmon/lm63 b/Documentation/hwmon/lm63
index 4d30d209881a..4a00461512a6 100644
--- a/Documentation/hwmon/lm63
+++ b/Documentation/hwmon/lm63
@@ -18,7 +18,7 @@ Supported chips:
    Datasheet: Publicly available at the National Semiconductor website
               http://www.national.com/pf/LM/LM96163.html
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 Thanks go to Tyan and especially Alex Buckingham for setting up a remote
 access to their S4882 test platform for this driver.
diff --git a/Documentation/hwmon/lm70 b/Documentation/hwmon/lm70
index 86d182942c51..1bb2db440671 100644
--- a/Documentation/hwmon/lm70
+++ b/Documentation/hwmon/lm70
@@ -43,5 +43,5 @@ data (0.03125 degrees celsius resolution).
 Thanks to
 ---------
-Jean Delvare <khali@linux-fr.org> for mentoring the hwmon-side driver
+Jean Delvare <jdelvare@suse.de> for mentoring the hwmon-side driver
 development.
diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78
index 2bdc881a0c12..4dd47731789f 100644
--- a/Documentation/hwmon/lm78
+++ b/Documentation/hwmon/lm78
@@ -14,7 +14,7 @@ Supported chips:
               http://www.national.com/
 Authors: Frodo Looijaard <frodol@dds.nl>
-         Jean Delvare <khali@linux-fr.org>
+         Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/lm83 b/Documentation/hwmon/lm83
index a04d1fe9269c..50be5cb26de9 100644
--- a/Documentation/hwmon/lm83
+++ b/Documentation/hwmon/lm83
@@ -13,7 +13,7 @@ Supported chips:
               http://www.national.com/pf/LM/LM82.html
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/lm87 b/Documentation/hwmon/lm87
index 6b47b67fd968..a2339fd9acb9 100644
--- a/Documentation/hwmon/lm87
+++ b/Documentation/hwmon/lm87
@@ -17,7 +17,7 @@ Authors:
        Mark Studebaker <mdsxyz123@yahoo.com>,
        Stephen Rousset <stephen.rousset@rocketlogix.com>,
        Dan Eaton <dan.eaton@rocketlogix.com>,
-        Jean Delvare <khali@linux-fr.org>,
+        Jean Delvare <jdelvare@suse.de>,
        Original 2.6 port Jeff Oliver
 Description
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index ab81013cc390..8122675d30f6 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -129,7 +129,7 @@ Supported chips:
               http://www.ti.com/litv/pdf/sbos686
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 Description
diff --git a/Documentation/hwmon/lm92 b/Documentation/hwmon/lm92
index 7705bfaa0708..22f68ad032cf 100644
--- a/Documentation/hwmon/lm92
+++ b/Documentation/hwmon/lm92
@@ -19,7 +19,7 @@ Supported chips:
 Authors:
        Abraham van der Merwe <abraham@2d3d.co.za>
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
diff --git a/Documentation/hwmon/max1619 b/Documentation/hwmon/max1619
index e6d87398cc8f..518bae3a80c4 100644
--- a/Documentation/hwmon/max1619
+++ b/Documentation/hwmon/max1619
@@ -10,7 +10,7 @@ Supported chips:
 Authors:
        Oleksij Rempel <bug-track@fisher-privat.net>,
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/pc87360 b/Documentation/hwmon/pc87360
index cbac32b59c8c..d5f5cf16ce59 100644
--- a/Documentation/hwmon/pc87360
+++ b/Documentation/hwmon/pc87360
@@ -7,7 +7,7 @@ Supported chips:
    Addresses scanned: none, address read from Super I/O config space
    Datasheets: No longer available
-Authors: Jean Delvare <khali@linux-fr.org>
+Authors: Jean Delvare <jdelvare@suse.de>
 Thanks to Sandeep Mehta, Tonko de Rooy and Daniel Ceregatti for testing.
 Thanks to Rudolf Marek for helping me investigate conversion issues.
diff --git a/Documentation/hwmon/pc87427 b/Documentation/hwmon/pc87427
index 8fdd08c9e48b..c313eb66e08a 100644
--- a/Documentation/hwmon/pc87427
+++ b/Documentation/hwmon/pc87427
@@ -7,7 +7,7 @@ Supported chips:
    Addresses scanned: none, address read from Super I/O config space
    Datasheet: No longer available
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 Thanks to Amir Habibi at Candelis for setting up a test system, and to
 Michael Kress for testing several iterations of this driver.
diff --git a/Documentation/hwmon/pcf8591 b/Documentation/hwmon/pcf8591
index ac020b3bb7b3..447c0702c0ec 100644
--- a/Documentation/hwmon/pcf8591
+++ b/Documentation/hwmon/pcf8591
@@ -11,7 +11,7 @@ Supported chips:
 Authors:
        Aurelien Jarno <aurelien@aurel32.net>
        valuable contributions by Jan M. Sendler <sendler@sendler.de>,
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
diff --git a/Documentation/hwmon/smsc47m1 b/Documentation/hwmon/smsc47m1
index 2a13378dcf22..10a24b420686 100644
--- a/Documentation/hwmon/smsc47m1
+++ b/Documentation/hwmon/smsc47m1
@@ -25,7 +25,7 @@ Authors:
        With assistance from Bruce Allen <ballen@uwm.edu>, and his
        fan.c program: http://www.lsc-group.phys.uwm.edu/%7Eballen/driver/
        Gabriele Gorla <gorlik@yahoo.com>,
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf
index ceaf6f652b00..735c42a85ead 100644
--- a/Documentation/hwmon/w83627ehf
+++ b/Documentation/hwmon/w83627ehf
@@ -36,7 +36,7 @@ Supported chips:
    Datasheet: Available from Nuvoton upon request
 Authors:
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
        Yuan Mu (Winbond)
        Rudolf Marek <r.marek@assembler.cz>
        David Hubbard <david.c.hubbard@gmail.com>
diff --git a/Documentation/hwmon/w83795 b/Documentation/hwmon/w83795
index 9f160371f463..d3e678216b9a 100644
--- a/Documentation/hwmon/w83795
+++ b/Documentation/hwmon/w83795
@@ -13,7 +13,7 @@ Supported chips:
 Authors:
    Wei Song (Nuvoton)
-    Jean Delvare <khali@linux-fr.org>
+    Jean Delvare <jdelvare@suse.de>
 Pin mapping
diff --git a/Documentation/hwmon/w83l785ts b/Documentation/hwmon/w83l785ts
index bd1fa9d4468d..c8978478871f 100644
--- a/Documentation/hwmon/w83l785ts
+++ b/Documentation/hwmon/w83l785ts
@@ -9,7 +9,7 @@ Supported chips:
               http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83L785TS-S.pdf
 Authors:
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Description
 -----------
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index 7b0dcdb57173..aaaf069306a3 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -33,7 +33,7 @@ and the additional 'Integrated Device Function' controllers are supported.
 Authors: 
        Mark Studebaker <mdsxyz123@yahoo.com>
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Module Parameters
diff --git a/Documentation/i2c/busses/i2c-parport b/Documentation/i2c/busses/i2c-parport
index 2461c7b53b2c..0e2d17b460fd 100644
--- a/Documentation/i2c/busses/i2c-parport
+++ b/Documentation/i2c/busses/i2c-parport
@@ -1,6 +1,6 @@
 Kernel driver i2c-parport
-Author: Jean Delvare <khali@linux-fr.org> 
+Author: Jean Delvare <jdelvare@suse.de>
 This is a unified driver for several i2c-over-parallel-port adapters,
 such as the ones made by Philips, Velleman or ELV. This driver is
diff --git a/Documentation/i2c/busses/i2c-parport-light b/Documentation/i2c/busses/i2c-parport-light
index c22ee063e1e5..7071b8ba0af4 100644
--- a/Documentation/i2c/busses/i2c-parport-light
+++ b/Documentation/i2c/busses/i2c-parport-light
@@ -1,6 +1,6 @@
 Kernel driver i2c-parport-light
-Author: Jean Delvare <khali@linux-fr.org> 
+Author: Jean Delvare <jdelvare@suse.de>
 This driver is a light version of i2c-parport. It doesn't depend        
 on the parport driver, and uses direct I/O access instead. This might be
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index c097e0f020fe..aa959fd22450 100644
--- a/Documentation/i2c/busses/i2c-piix4
+++ b/Documentation/i2c/busses/i2c-piix4
@@ -13,7 +13,7 @@ Supported adapters:
  * AMD SP5100 (SB700 derivative found on some server mainboards)
    Datasheet: Publicly available at the AMD website
    http://support.amd.com/us/Embedded_TechDocs/44413.pdf
-  * AMD Hudson-2, CZ
+  * AMD Hudson-2, ML, CZ
    Datasheet: Not publicly available
  * Standard Microsystems (SMSC) SLC90E66 (Victory66) southbridge
    Datasheet: Publicly available at the SMSC website http://www.smsc.com
diff --git a/Documentation/i2c/busses/i2c-taos-evm b/Documentation/i2c/busses/i2c-taos-evm
index 63f62bcbf592..60299555dcf0 100644
--- a/Documentation/i2c/busses/i2c-taos-evm
+++ b/Documentation/i2c/busses/i2c-taos-evm
@@ -1,6 +1,6 @@
 Kernel driver i2c-taos-evm
-Author: Jean Delvare <khali@linux-fr.org>
+Author: Jean Delvare <jdelvare@suse.de>
 This is a driver for the evaluation modules for TAOS I2C/SMBus chips.
 The modules include an SMBus master with limited capabilities, which can
diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro
index b88f91ae580e..ab64ce21c254 100644
--- a/Documentation/i2c/busses/i2c-viapro
+++ b/Documentation/i2c/busses/i2c-viapro
@@ -28,7 +28,7 @@ Supported adapters:
 Authors:
        Kyösti Mälkki <kmalkki@cc.hut.fi>,
        Mark D. Studebaker <mdsxyz123@yahoo.com>,
-        Jean Delvare <khali@linux-fr.org>
+        Jean Delvare <jdelvare@suse.de>
 Module Parameters
 -----------------
diff --git a/Documentation/i2c/fault-codes b/Documentation/i2c/fault-codes
index 045765c0b9b5..47c25abb7d52 100644
--- a/Documentation/i2c/fault-codes
+++ b/Documentation/i2c/fault-codes
@@ -64,9 +64,6 @@ EINVAL
        detected before any I/O operation was started.  Use a more
        specific fault code when you can.
-        One example would be a driver trying an SMBus Block Write
-        with block size outside the range of 1-32 bytes.
 EIO
        This rather vague error means something went wrong when
        performing an I/O operation.  Use a more specific fault
diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 31bb6a4029ef..3f6d8a5e9cdc 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -68,7 +68,7 @@ features that you need, first. How each feature is mapped is described below.
 Legacy drivers often don't comply to these rules. As we cannot change them
 for backwards-compatibility reasons, you need to provide fixup mappings in
 user-space yourself. Some of them might also provide module-options that
-change the mappings so you can adivce users to set these.
+change the mappings so you can advise users to set these.
 All new gamepads are supposed to comply with this mapping. Please report any
 bugs, if they don't.
@@ -150,10 +150,10 @@ Menu-Pad:
                  BTN_START
  Many pads also have a third button which is branded or has a special symbol
  and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo
-  "HOME" button, the XBox "X"-button or Sony "P" button.
+  "HOME" button, the XBox "X"-button or Sony "PS" button.
 Rumble:
-  Rumble is adverticed as FF_RUMBLE.
+  Rumble is advertised as FF_RUMBLE.
 ----------------------------------------------------------------------------
  Written 2013 by David Herrmann <dh.herrmann@gmail.com>
diff --git a/Documentation/input/joystick-api.txt b/Documentation/input/joystick-api.txt
index c507330740cd..943b18eac918 100644
--- a/Documentation/input/joystick-api.txt
+++ b/Documentation/input/joystick-api.txt
@@ -16,14 +16,14 @@ joystick.
 By default, the device is opened in blocking mode.
-        int fd = open ("/dev/js0", O_RDONLY);
+        int fd = open ("/dev/input/js0", O_RDONLY);
 2. Event Reading
 ~~~~~~~~~~~~~~~~
        struct js_event e;
-        read (fd, &e, sizeof(struct js_event));
+        read (fd, &e, sizeof(e));
 where js_event is defined as
@@ -34,8 +34,8 @@ where js_event is defined as
                __u8 number;    /* axis/button number */
        };
-If the read is successful, it will return sizeof(struct js_event), unless
+If the read is successful, it will return sizeof(e), unless you wanted to read
-you wanted to read more than one event per read as described in section 3.1.
+more than one event per read as described in section 3.1.
 2.1 js_event.type
@@ -99,9 +99,9 @@ may work well if you handle JS_EVENT_INIT events separately,
        if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) {
                if (js_event.value)
-                        buttons_state |= (1 << js_event.number);
+                        buttons_state |= (1 << js_event.number);
-                else
+                else
-                        buttons_state &= ~(1 << js_event.number);
+                        buttons_state &= ~(1 << js_event.number);
        }
 is much safer since it can't lose sync with the driver. As you would
@@ -144,14 +144,14 @@ all events on the queue (that is, until you get a -1).
 For example,
        while (1) {
-                while (read (fd, &e, sizeof(struct js_event)) > 0) {
+                while (read (fd, &e, sizeof(e)) > 0) {
-                        process_event (e);
+                        process_event (e);
-                }
+                }
-                /* EAGAIN is returned when the queue is empty */
+                /* EAGAIN is returned when the queue is empty */
-                if (errno != EAGAIN) {
+                if (errno != EAGAIN) {
-                        /* error */
+                        /* error */
-                }
+                }
-                /* do something interesting with processed events */
+                /* do something interesting with processed events */
        }
 One reason for emptying the queue is that if it gets full you'll start
@@ -181,7 +181,7 @@ at a time using the typical read(2) functionality. For that, you would
 replace the read above with something like
        struct js_event mybuffer[0xff];
-        int i = read (fd, mybuffer, sizeof(struct mybuffer));
+        int i = read (fd, mybuffer, sizeof(mybuffer));
 In this case, read would return -1 if the queue was empty, or some
 other value in which the number of events read would be i /
@@ -269,9 +269,9 @@ The driver offers backward compatibility, though. Here's a quick summary:
        struct JS_DATA_TYPE js;
        while (1) {
                if (read (fd, &js, JS_RETURN) != JS_RETURN) {
-                        /* error */
+                        /* error */
-                }
+                }
-                usleep (1000);
+                usleep (1000);
        }
 As you can figure out from the example, the read returns immediately,
diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt
index 304262bb661a..8d027dc86c1f 100644
--- a/Documentation/input/joystick.txt
+++ b/Documentation/input/joystick.txt
@@ -116,7 +116,7 @@ your needs:
  For testing the joystick driver functionality, there is the jstest
 program in the utilities package. You run it by typing:
-        jstest /dev/js0
+        jstest /dev/input/js0
  And it should show a line with the joystick values, which update as you
 move the stick, and press its buttons. The axes should all be zero when the
@@ -136,7 +136,7 @@ joystick should be autocalibrated by the driver automagically. However, with
 some analog joysticks, that either do not use linear resistors, or if you
 want better precision, you can use the jscal program
-        jscal -c /dev/js0
+        jscal -c /dev/input/js0
 included in the joystick package to set better correction coefficients than
 what the driver would choose itself.
@@ -145,7 +145,7 @@ what the driver would choose itself.
 calibration using the jstest command, and if you do, you then can save the
 correction coefficients into a file
-        jscal -p /dev/js0 > /etc/joystick.cal
+        jscal -p /dev/input/js0 > /etc/joystick.cal
  And add a line to your rc script executing that file
@@ -556,7 +556,7 @@ interface, and "old" for the "0.x" interface. You run it by typing:
 5. FAQ
 ~~~~~~
-Q: Running 'jstest /dev/js0' results in "File not found" error. What's the
+Q: Running 'jstest /dev/input/js0' results in "File not found" error. What's the
   cause?
 A: The device files don't exist. Create them (see section 2.2).
diff --git a/Documentation/io-mapping.txt b/Documentation/io-mapping.txt
index 473e43b2d588..5ca78426f54c 100644
--- a/Documentation/io-mapping.txt
+++ b/Documentation/io-mapping.txt
@@ -38,7 +38,7 @@ maps are more efficient:
        void io_mapping_unmap_atomic(void *vaddr)
-                'vaddr' must be the the value returned by the last
+                'vaddr' must be the value returned by the last
                io_mapping_map_atomic_wc call. This unmaps the specified
                page and allows the task to sleep once again.
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 7cbfa3c4fc3d..d7e43fa88575 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -73,6 +73,7 @@ Code  Seq#(hex)	Include File		Comments
 0x09    all     linux/raid/md_u.h
 0x10    00-0F   drivers/char/s390/vmcp.h
 0x10    10-1F   arch/s390/include/uapi/sclp_ctl.h
+0x10    20-2F   arch/s390/include/uapi/asm/hypfs.h
 0x12    all     linux/fs.h
                linux/blkpg.h
 0x1b    all     InfiniBand Subsystem    <http://infiniband.sourceforge.net/>
diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO
index 8148a47fc70e..0091a8215ac1 100644
--- a/Documentation/ja_JP/HOWTO
+++ b/Documentation/ja_JP/HOWTO
@@ -149,7 +149,7 @@ linux-api@ver.kernel.org に送ることを勧めます。
     この他にパッチを作る方法についてのよくできた記述は-
        "The Perfect Patch"
-                http://userweb.kernel.org/~akpm/stuff/tpp.txt
+                http://www.ozlabs.org/~akpm/stuff/tpp.txt
        "Linux kernel patch submission format"
                http://linux.yyz.us/patch-format.html
@@ -622,7 +622,7 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を�
 これについて全てがどのようにあるべきかについての詳細は、以下のドキュメ
 ントの ChangeLog セクションを見てください-
  "The Perfect Patch"
-      http://userweb.kernel.org/~akpm/stuff/tpp.txt
+      http://www.ozlabs.org/~akpm/stuff/tpp.txt
 これらのどれもが、時にはとても困難です。これらの慣例を完璧に実施するに
 は数年かかるかもしれません。これは継続的な改善のプロセスであり、そのた
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4252af6ffda1..8f441dab0396 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -343,6 +343,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        no: ACPI OperationRegions are not marked as reserved,
                        no further checks are performed.
+        acpi_no_memhotplug [ACPI] Disable memory hotplug.  Useful for kdump
+                           kernels.
        add_efi_memmap  [EFI; X86] Include EFI memory map in
                        kernel's map of available physical RAM.
@@ -463,6 +466,22 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        atkbd.softrepeat= [HW]
                        Use software keyboard repeat
+        audit=          [KNL] Enable the audit sub-system
+                        Format: { "0" | "1" } (0 = disabled, 1 = enabled)
+                        0 - kernel audit is disabled and can not be enabled
+                            until the next reboot
+                        unset - kernel audit is initialized but disabled and
+                            will be fully enabled by the userspace auditd.
+                        1 - kernel audit is initialized and partially enabled,
+                            storing at most audit_backlog_limit messages in
+                            RAM until it is fully enabled by the userspace
+                            auditd.
+                        Default: unset
+        audit_backlog_limit= [KNL] Set the audit queue size limit.
+                        Format: <int> (must be >=0)
+                        Default: 64
        baycom_epp=     [HW,AX25]
                        Format: <io>,<mode>
@@ -515,7 +534,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        cgroup_disable= [KNL] Disable a particular controller
                        Format: {name of the controller(s) to disable}
-                                {Currently supported controllers - "memory"}
+                        The effects of cgroup_disable=foo are:
+                        - foo isn't auto-mounted if you mount all cgroups in
+                          a single hierarchy
+                        - foo isn't visible as an individually mountable
+                          subsystem
+                        {Currently only "memory" controller deal with this and
+                        cut the overhead, others just disable the usage. So
+                        only cgroup_disable=memory is actually worthy}
        checkreqprot    [SELINUX] Set initial checkreqprot flag value.
                        Format: { "0" | "1" }
@@ -1036,7 +1062,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        debugfs files are removed at module unload time.
        gpt             [EFI] Forces disk with valid GPT signature but
-                        invalid Protective MBR to be treated as GPT.
+                        invalid Protective MBR to be treated as GPT. If the
+                        primary GPT is corrupted, it enables the backup/alternate
+                        GPT to be used instead.
        grcan.enable0=  [HW] Configuration of physical interface 0. Determines
                        the "Enable 0" bit of the configuration register.
@@ -1438,6 +1466,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        Valid arguments: on, off
                        Default: on
+        kmemcheck=      [X86] Boot-time kmemcheck enable/disable/one-shot mode
+                        Valid arguments: 0, 1, 2
+                        kmemcheck=0 (disabled)
+                        kmemcheck=1 (enabled)
+                        kmemcheck=2 (one-shot mode)
+                        Default: 2 (one-shot mode)
        kstack=N        [X86] Print N words from the kernel stack
                        in oops dumps.
@@ -3089,7 +3124,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        controller if no parameter or 1 is given or disable
                        it if 0 is given (See Documentation/cgroups/memory.txt)
-        swiotlb=        [IA-64] Number of I/O TLB slabs
+        swiotlb=        [ARM,IA-64,PPC,MIPS,X86]
+                        Format: { <int> | force }
+                        <int> -- Number of I/O TLB slabs
+                        force -- force using of bounce buffers even if they
+                                 wouldn't be automatically used by the kernel
        switches=       [HW,M68k]
diff --git a/Documentation/kmsg/s390/zcrypt b/Documentation/kmsg/s390/zcrypt
deleted file mode 100644
index 7fb2087409d6..000000000000
--- a/Documentation/kmsg/s390/zcrypt
+++ /dev/null
@@ -1,20 +0,0 @@
-/*?
- * Text: "Cryptographic device %x failed and was set offline\n"
- * Severity: Error
- * Parameter:
- *   @1: device index
- * Description:
- * A cryptographic device failed to process a cryptographic request.
- * The cryptographic device driver could not correct the error and
- * set the device offline. The application that issued the
- * request received an indication that the request has failed.
- * User action:
- * Use the lszcrypt command to confirm that the cryptographic
- * hardware is still configured to your LPAR or z/VM guest virtual
- * machine. If the device is available to your Linux instance the
- * command output contains a line that begins with 'card<device index>',
- * where <device index> is the two-digit decimal number in the message text.
- * After ensuring that the device is available, use the chzcrypt command to
- * set it online again.
- * If the error persists, contact your support organization.
- */
diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 680e64635958..dc2ff8f611e0 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -122,7 +122,7 @@ mtk.manpages@gmail.com의 메인테이너에게 보낼 것을 권장한다.
    올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
    "The Perfect Patch"
-        http://userweb.kernel.org/~akpm/stuff/tpp.txt
+        http://www.ozlabs.org/~akpm/stuff/tpp.txt
    "Linux kernel patch submission format"
        http://linux.yyz.us/patch-format.html
@@ -213,7 +213,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
 코드 저장소는 다음을 통하여 참조할 수 있다.
-      http://users.sosdg.org/~qiyong/lxr/
+      http://lxr.linux.no/+trees
 개발 프로세스
@@ -222,20 +222,20 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과
 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
 브랜치들은 다음과 같다.
-  - main 2.6.x 커널 트리
+  - main 3.x 커널 트리
-  - 2.6.x.y - 안정된 커널 트리
+  - 3.x.y - 안정된 커널 트리
-  - 2.6.x -git 커널 패치들
+  - 3.x -git 커널 패치들
-  - 2.6.x -mm 커널 패치들
  - 서브시스템을 위한 커널 트리들과 패치들
+  - 3.x - 통합 테스트를 위한 next 커널 트리
-2.6.x 커널 트리
+3.x 커널 트리
 ---------------
-2.6.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v2.6/
+3.x 커널들은 Linux Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v3.x/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
  - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
    메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
-    몇 주 동안 -mm 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
+    몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
    선호되는 방법은  git(커널의 소스 관리 툴, 더 많은 정보들은 http://git.or.cz/
    에서 참조할 수 있다)를 사용하는 것이지만 순수한 패치파일의 형식으로 보내는
    것도 무관하다.
@@ -262,20 +262,20 @@ Andrew Morton의 글이 있다.
         버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
         배포되는 것은 아니기 때문이다."
-2.6.x.y - 안정 커널 트리
+3.x.y - 안정 커널 트리
 ------------------------
-4 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 2.6.x
+3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 3.x
 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
 포함한다.
 이것은 가장 최근의 안정적인 커널을 원하는 사용자에게 추천되는 브랜치이며,
 개발/실험적 버젼을 테스트하는 것을 돕고자 하는 사용자들과는 별로 관련이 없다.
-어떤 2.6.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 2.6.x
+어떤 3.x.y 커널도 사용할 수 없다면 그때는 가장 높은 숫자의 3.x
 커널이 현재의 안정 커널이다.
-2.6.x.y는 "stable" 팀<stable@kernel.org>에 의해 관리되며 거의 매번 격주로
+3.x.y는 "stable" 팀<stable@vger.kernel.org>에 의해 관리되며 거의 매번 격주로
 배포된다.
 커널 트리 문서들 내에 Documentation/stable_kernel_rules.txt 파일은 어떤
@@ -283,84 +283,46 @@ Andrew Morton의 글이 있다.
 진행되는지를 설명한다.
-2.6.x -git 패치들
+3.x -git 패치들
 ------------------
 git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
 Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
 살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
-2.6.x -mm 커널 패치들
---------------------
-Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 모든 다른
-서브시스템 커널 트리와 패치들을 가져와서 리눅스 커널 메일링 리스트로
-온 많은 패치들과 한데 묶는다. 이 트리는 새로운 기능들과 패치들을 위한
-장소를 제공하는 역할을 한다. 하나의 패치가 -mm에 한동안 있으면서 그 가치가
-증명되게 되면 Andrew나 서브시스템 메인테이너는 그것을 메인라인에 포함시키기
-위하여 Linus에게 보낸다.
-커널 트리에 포함하고 싶은 모든 새로운 패치들은 Linus에게 보내지기 전에
-mm 트리에서 테스트를 하는 것을 적극 추천한다.
-이 커널들은 안정되게 사용할 시스템에서에 실행하는 것은 적합하지 않으며
-다른 브랜치들의 어떤 것들보다 위험하다.
-여러분이 커널 개발 프로세스를 돕길 원한다면 이 커널 배포들을 사용하고
-테스트한 후 어떤 문제를 발견하거나 또는 모든 것이 잘 동작한다면 리눅스
-커널 메일링 리스트로 피드백을 해달라.
-이 커널들은 일반적으로 모든 다른 실험적인 패치들과 배포될 당시의
-사용가능한 메인라인 -git 커널들의 몇몇 변경을 포함한다.
-mm 커널들은 정해진 일정대로 배포되지 않는다. 하지만 대개 몇몇 -mm 커널들은
-각 -rc 커널(1부터 3이 흔함) 사이에서 배포된다.
 서브시스템 커널 트리들과 패치들
 -------------------------------
-많은 다른 커널 서브시스템 개발자들은 커널의 다른 부분들에서 무슨 일이
+다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들
-일어나고 있는지를 볼수 있도록 그들의 개발 트리를 공개한다. 이 트리들은
+--- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도
-위에서 설명하였던 것 처럼 -mm 커널 배포들로 합쳐진다.
+커널의 다른 영역에 어떤 변화가 이루어지고 있는지 알 수 있다. 급속히 개발이
+진행되는 영역이 있고 그렇지 않은 영역이 있으므로, 개발자는 다른 개발자가 제출한
-다음은  활용가능한 커널 트리들을 나열한다.
+수정 사항과 자신의 수정사항의 충돌이나 동일한 일을 동시에 두사람이 따로
-  git trees:
+진행하는 사태를 방지하기 위해 급속히 개발이 진행되고 있는 영역에 작업의
-    - Kbuild development tree, Sam Ravnborg < sam@ravnborg.org>
+베이스를 맞춰줄 것이 요구된다.
-    git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
+대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt
-    - ACPI development tree, Len Brown <len.brown@intel.com >
+시리즈로 제공되는 패치들도 존재한다. 이러한 서브시스템 저장소들은 MAINTAINERS
-    git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
+파일에 나열되어 있다. 대부분은 http://git.kernel.org 에서 볼 수 있다.
-    - Block development tree, Jens Axboe <jens.axboe@oracle.com>
+제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해
-    git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
+리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이
+리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와
-    - DRM development tree, Dave Airlie <airlied@linux.ie>
+패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고,
-    git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
+메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다.
+대부분의 이러한 patchwork 사이트는 http://patchwork.kernel.org/ 또는
-    - ia64 development tree, Tony Luck < tony.luck@intel.com>
+http://patchwork.ozlabs.org/ 에 나열되어 있다.
-    git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
+3.x - 통합 테스트를 위한 next 커널 트리
-    - infiniband, Roland Dreier <rolandd@cisco.com >
+-----------------------------------------
-    git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
+서브시스템 트리들의 변경사항들은 mainline 3.x 트리로 들어오기 전에 통합
+테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
-    - libata, Jeff Garzik <jgarzik@pobox.com>
+매일 받아가는 특수한 테스트 저장소가 존재한다:
-    git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
+       http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
+       http://linux.f-seidel.de/linux-next/pmwiki/
-    - network drivers, Jeff Garzik <jgarzik@pobox.com>
-    git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
+이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이
+가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를
-    - pcmcia, Dominik Brodowski < linux@dominikbrodowski.net>
+수행하는 것도 좋을 것이다.
-    git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
-    - SCSI, James Bottomley < James.Bottomley@SteelEye.com>
-    git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
-  quilt trees:
-    - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@linuxfoundation.org>
-    kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
-    - x86-64, partly i386, Andi Kleen < ak@suse.de>
-        ftp.firstfloor.org:/pub/ak/x86_64/quilt/
-  다른 커널 트리들은 http://kernel.org/git와 MAINTAINERS 파일에서 참조할 수
-  있다.
 버그 보고
 ---------
@@ -597,7 +559,7 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅�
 이것이 무엇인지 더 자세한 것을 알고 싶다면 다음 문서의 ChageLog 항을 봐라.
   "The Perfect Patch"
-    http://userweb.kernel.org/~akpm/stuff/tpp.txt
+    http://www.ozlabs.org/~akpm/stuff/tpp.txt
diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt
index c5182bb2c16c..f87241dfed87 100644
--- a/Documentation/kobject.txt
+++ b/Documentation/kobject.txt
@@ -342,7 +342,10 @@ kset use:
 When you are finished with the kset, call:
  void kset_unregister(struct kset *kset);
-to destroy it.
+to destroy it.  This removes the kset from sysfs and decrements its reference
+count.  When the reference count goes to zero, the kset will be released.
+Because other references to the kset may still exist, the release may happen
+after kset_unregister() returns.
 An example of using a kset can be seen in the
 samples/kobject/kset-example.c file in the kernel tree.
diff --git a/Documentation/laptops/hpfall.c b/Documentation/laptops/hpfall.c
index a4a8fc5d05d4..b85dbbac0499 100644
--- a/Documentation/laptops/hpfall.c
+++ b/Documentation/laptops/hpfall.c
@@ -29,7 +29,7 @@ int set_unload_heads_path(char *device)
                return -EINVAL;
        strncpy(devname, device + 5, sizeof(devname));
-        snprintf(unload_heads_path, sizeof(unload_heads_path),
+        snprintf(unload_heads_path, sizeof(unload_heads_path) - 1,
                                "/sys/block/%s/device/unload_heads", devname);
        return 0;
 }
diff --git a/Documentation/leds/leds-lp55xx.txt b/Documentation/leds/leds-lp55xx.txt
index 82713ff92eb3..bcea12a0c584 100644
--- a/Documentation/leds/leds-lp55xx.txt
+++ b/Documentation/leds/leds-lp55xx.txt
@@ -73,6 +73,10 @@ select_engine : Select which engine is used for running program
 run_engine    : Start program which is loaded via the firmware interface
 firmware      : Load program data
+In case of LP5523, one more command is required, 'enginex_leds'.
+It is used for selecting LED output(s) at each engine number.
+In more details, please refer to 'leds-lp5523.txt'.
 For example, run blinking pattern in engine #1 of LP5521
 echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
 echo 1 > /sys/class/firmware/lp5521/loading
@@ -81,10 +85,12 @@ echo 0 > /sys/class/firmware/lp5521/loading
 echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
 For example, run blinking pattern in engine #3 of LP55231
+Two LEDs are configured as pattern output channels.
 echo 3 > /sys/bus/i2c/devices/xxxx/select_engine
 echo 1 > /sys/class/firmware/lp55231/loading
 echo "9d0740ff7e0040007e00a0010000" > /sys/class/firmware/lp55231/data
 echo 0 > /sys/class/firmware/lp55231/loading
+echo "000001100" > /sys/bus/i2c/devices/xxxx/engine3_leds
 echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
 To start blinking patterns in engine #2 and #3 simultaneously,
@@ -99,17 +105,19 @@ done
 echo 1 > /sys/class/leds/red/device/run_engine
 Here is another example for LP5523.
+Full LED strings are selected by 'engine2_leds'.
 echo 2 > /sys/bus/i2c/devices/xxxx/select_engine
 echo 1 > /sys/class/firmware/lp5523/loading
 echo "9d80400004ff05ff437f0000" > /sys/class/firmware/lp5523/data
 echo 0 > /sys/class/firmware/lp5523/loading
+echo "111111111" > /sys/bus/i2c/devices/xxxx/engine2_leds
 echo 1 > /sys/bus/i2c/devices/xxxx/run_engine
 As soon as 'loading' is set to 0, registered callback is called.
 Inside the callback, the selected engine is loaded and memory is updated.
 To run programmed pattern, 'run_engine' attribute should be enabled.
-The pattern sqeuence of LP8501 is same as LP5523.
+The pattern sqeuence of LP8501 is similar to LP5523.
 However pattern data is specific.
 Ex 1) Engine 1 is used
 echo 1 > /sys/bus/i2c/devices/xxxx/select_engine
diff --git a/Documentation/md.txt b/Documentation/md.txt
index fbb2fcbf16b6..f925666e4342 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -533,7 +533,7 @@ also have
      found.  The count in 'mismatch_cnt' is the number of sectors
      that were re-written, or (for 'check') would have been
      re-written.  As most raid levels work in units of pages rather
-      than sectors, this my be larger than the number of actual errors
+      than sectors, this may be larger than the number of actual errors
      by a factor of the number of sectors in a page.
   bitmap_set_bits
diff --git a/Documentation/misc-devices/eeprom b/Documentation/misc-devices/eeprom
index f7e8104b5764..ba692011f221 100644
--- a/Documentation/misc-devices/eeprom
+++ b/Documentation/misc-devices/eeprom
@@ -38,7 +38,7 @@ Supported chips:
 Authors:
        Frodo Looijaard <frodol@dds.nl>,
        Philip Edelbrock <phil@netroedge.com>,
-        Jean Delvare <khali@linux-fr.org>,
+        Jean Delvare <jdelvare@suse.de>,
        Greg Kroah-Hartman <greg@kroah.com>,
        IBM Corp.
diff --git a/Documentation/misc-devices/mei/mei-amt-version.c b/Documentation/misc-devices/mei/mei-amt-version.c
index 49e4f770864a..57d0d871dcf7 100644
--- a/Documentation/misc-devices/mei/mei-amt-version.c
+++ b/Documentation/misc-devices/mei/mei-amt-version.c
@@ -115,8 +115,6 @@ static bool mei_init(struct mei *me, const uuid_le *guid,
        struct mei_client *cl;
        struct mei_connect_client_data data;
-        mei_deinit(me);
        me->verbose = verbose;
        me->fd = open("/dev/mei", O_RDWR);
diff --git a/Documentation/mtd/nand/pxa3xx-nand.txt b/Documentation/mtd/nand/pxa3xx-nand.txt
new file mode 100644
index 000000000000..840fd41c181b
--- /dev/null
+++ b/Documentation/mtd/nand/pxa3xx-nand.txt
@@ -0,0 +1,113 @@
+About this document
+===================
+Some notes about Marvell's NAND controller available in PXA and Armada 370/XP
+SoC (aka NFCv1 and NFCv2), with an emphasis on the latter.
+NFCv2 controller background
+===========================
+The controller has a 2176 bytes FIFO buffer. Therefore, in order to support
+larger pages, I/O operations on 4 KiB and 8 KiB pages is done with a set of
+chunked transfers.
+For instance, if we choose a 2048 data chunk and set "BCH" ECC (see below)
+we'll have this layout in the pages:
+  ------------------------------------------------------------------------------
+  | 2048B data | 32B spare | 30B ECC || 2048B data | 32B spare | 30B ECC | ... |
+  ------------------------------------------------------------------------------
+The driver reads the data and spare portions independently and builds an internal
+buffer with this layout (in the 4 KiB page case):
+  ------------------------------------------
+  |     4096B data     |     64B spare     |
+  ------------------------------------------
+Also, for the READOOB command the driver disables the ECC and reads a 'spare + ECC'
+OOB, one per chunk read.
+  -------------------------------------------------------------------
+  |     4096B data     |  32B spare | 30B ECC | 32B spare | 30B ECC |
+  -------------------------------------------------------------------
+So, in order to achieve reading (for instance), we issue several READ0 commands
+(with some additional controller-specific magic) and read two chunks of 2080B
+(2048 data + 32 spare) each.
+The driver accommodates this data to expose the NAND core a contiguous buffer
+(4096 data + spare) or (4096 + spare + ECC + spare + ECC).
+ECC
+===
+The controller has built-in hardware ECC capabilities. In addition it is
+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
+and expected to be located (when reading/programming) right after the spare
+bytes as the figure above shows.
+So, repeating the above scheme, a 2048B data chunk will be followed by 32B
+spare, and then the ECC controller will read/write the ECC code (30B in
+this case):
+  ------------------------------------
+  | 2048B data | 32B spare | 30B ECC |
+  ------------------------------------
+If the ECC mode is 'BCH' then the ECC is *always* 30 bytes long.
+If the ECC mode is 'Hamming' the ECC is 6 bytes long, for each 512B block.
+So in Hamming mode, a 2048B page will have a 24B ECC.
+Despite all of the above, the controller requires the driver to only read or
+write in multiples of 8-bytes, because the data buffer is 64-bits.
+OOB
+===
+Because of the above scheme, and because the "spare" OOB is really located in
+the middle of a page, spare OOB cannot be read or write independently of the
+data area. In other words, in order to read the OOB (aka READOOB), the entire
+page (aka READ0) has to be read.
+In the same sense, in order to write to the spare OOB the driver has to write
+an *entire* page.
+Factory bad blocks handling
+===========================
+Given the ECC BCH requires to layout the device's pages in a split
+data/OOB/data/OOB way, the controller has a view of the flash page that's
+different from the specified (aka the manufacturer's) view. In other words,
+Factory view:
+  -----------------------------------------------
+  |                    Data           |x  OOB   |
+  -----------------------------------------------
+Driver's view:
+  -----------------------------------------------
+  |      Data      | OOB |      Data   x  | OOB |
+  -----------------------------------------------
+It can be seen from the above, that the factory bad block marker must be
+searched within the 'data' region, and not in the usual OOB region.
+In addition, this means under regular usage the driver will write such
+position (since it belongs to the data region) and every used block is
+likely to be marked as bad.
+For this reason, marking the block as bad in the OOB is explicitly
+disabled by using the NAND_BBT_NO_OOB_BBM option in the driver. The rationale
+for this is that there's no point in marking a block as bad, because good
+blocks are also 'marked as bad' (in the OOB BBM sense) under normal usage.
+Instead, the driver relies on the bad block table alone, and should only perform
+the bad block scan on the very first time (when the device hasn't been used).
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
index 89490beb3c0b..58e49042fc20 100644
--- a/Documentation/networking/batman-adv.txt
+++ b/Documentation/networking/batman-adv.txt
@@ -66,11 +66,10 @@ All  mesh  wide  settings  can be found in batman's own interface
 folder:
 # ls /sys/class/net/bat0/mesh/
-# aggregated_ogms        gw_bandwidth           log_level
+#aggregated_ogms        distributed_arp_table  gw_sel_class    orig_interval
-# ap_isolation           gw_mode                orig_interval
+#ap_isolation           fragmentation          hop_penalty     routing_algo
-# bonding                gw_sel_class           routing_algo
+#bonding                gw_bandwidth           isolation_mark  vlan0
-# bridge_loop_avoidance  hop_penalty            fragmentation
+#bridge_loop_avoidance  gw_mode                log_level
 There is a special folder for debugging information:
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 2cdb8b66caa9..5cdb22971d19 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -657,7 +657,8 @@ primary
        one slave is preferred over another, e.g., when one slave has
        higher throughput than another.
-        The primary option is only valid for active-backup mode.
+        The primary option is only valid for active-backup(1),
+        balance-tlb (5) and balance-alb (6) mode.
 primary_reselect
@@ -853,6 +854,14 @@ resend_igmp
        This option was added for bonding version 3.7.0.
+lp_interval
+        Specifies the number of seconds between instances where the bonding
+        driver sends learning packets to each slaves peer switch.
+        The valid range is 1 - 0x7fffffff; the default value is 1. This Option
+        has effect only in balance-tlb and balance-alb modes.
 3. Configuring Bonding Devices
 ==============================
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 4c072414eadb..f3089d423515 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -2,21 +2,20 @@
 can.txt
-Readme file for the Controller Area Network Protocol Family (aka Socket CAN)
+Readme file for the Controller Area Network Protocol Family (aka SocketCAN)
 This file contains
-  1 Overview / What is Socket CAN
+  1 Overview / What is SocketCAN
  2 Motivation / Why using the socket API
-  3 Socket CAN concept
+  3 SocketCAN concept
    3.1 receive lists
    3.2 local loopback of sent frames
-    3.3 network security issues (capabilities)
+    3.3 network problem notifications
-    3.4 network problem notifications
-  4 How to use Socket CAN
+  4 How to use SocketCAN
    4.1 RAW protocol sockets with can_filters (SOCK_RAW)
      4.1.1 RAW socket option CAN_RAW_FILTER
      4.1.2 RAW socket option CAN_RAW_ERR_FILTER
@@ -34,7 +33,7 @@ This file contains
    4.3 connected transport protocols (SOCK_SEQPACKET)
    4.4 unconnected transport protocols (SOCK_DGRAM)
-  5 Socket CAN core module
+  5 SocketCAN core module
    5.1 can.ko module params
    5.2 procfs content
    5.3 writing own CAN protocol modules
@@ -51,20 +50,20 @@ This file contains
    6.6 CAN FD (flexible data rate) driver support
    6.7 supported CAN hardware
-  7 Socket CAN resources
+  7 SocketCAN resources
  8 Credits
 ============================================================================
-1. Overview / What is Socket CAN
+1. Overview / What is SocketCAN
 --------------------------------
 The socketcan package is an implementation of CAN protocols
 (Controller Area Network) for Linux.  CAN is a networking technology
 which has widespread use in automation, embedded devices, and
 automotive fields.  While there have been other CAN implementations
-for Linux based on character devices, Socket CAN uses the Berkeley
+for Linux based on character devices, SocketCAN uses the Berkeley
 socket API, the Linux network stack and implements the CAN device
 drivers as network interfaces.  The CAN socket API has been designed
 as similar as possible to the TCP/IP protocols to allow programmers,
@@ -74,7 +73,7 @@ sockets.
 2. Motivation / Why using the socket API
 ----------------------------------------
-There have been CAN implementations for Linux before Socket CAN so the
+There have been CAN implementations for Linux before SocketCAN so the
 question arises, why we have started another project.  Most existing
 implementations come as a device driver for some CAN hardware, they
 are based on character devices and provide comparatively little
@@ -89,10 +88,10 @@ the CAN controller requires employment of another device driver and
 often the need for adaption of large parts of the application to the
 new driver's API.
-Socket CAN was designed to overcome all of these limitations.  A new
+SocketCAN was designed to overcome all of these limitations.  A new
 protocol family has been implemented which provides a socket interface
 to user space applications and which builds upon the Linux network
-layer, so to use all of the provided queueing functionality.  A device
+layer, enabling use all of the provided queueing functionality.  A device
 driver for CAN controller hardware registers itself with the Linux
 network layer as a network device, so that CAN frames from the
 controller can be passed up to the network layer and on to the CAN
@@ -146,15 +145,15 @@ solution for a couple of reasons:
  providing an API for device drivers to register with.  However, then
  it would be no more difficult, or may be even easier, to use the
  networking framework provided by the Linux kernel, and this is what
-  Socket CAN does.
+  SocketCAN does.
  The use of the networking framework of the Linux kernel is just the
  natural and most appropriate way to implement CAN for Linux.
-3. Socket CAN concept
+3. SocketCAN concept
 ---------------------
-  As described in chapter 2 it is the main goal of Socket CAN to
+  As described in chapter 2 it is the main goal of SocketCAN to
  provide a socket interface to user space applications which builds
  upon the Linux network layer. In contrast to the commonly known
  TCP/IP and ethernet networking, the CAN bus is a broadcast-only(!)
@@ -168,11 +167,11 @@ solution for a couple of reasons:
  The network transparent access of multiple applications leads to the
  problem that different applications may be interested in the same
-  CAN-IDs from the same CAN network interface. The Socket CAN core
+  CAN-IDs from the same CAN network interface. The SocketCAN core
  module - which implements the protocol family CAN - provides several
  high efficient receive lists for this reason. If e.g. a user space
  application opens a CAN RAW socket, the raw protocol module itself
-  requests the (range of) CAN-IDs from the Socket CAN core that are
+  requests the (range of) CAN-IDs from the SocketCAN core that are
  requested by the user. The subscription and unsubscription of
  CAN-IDs can be done for specific CAN interfaces or for all(!) known
  CAN interfaces with the can_rx_(un)register() functions provided to
@@ -217,21 +216,7 @@ solution for a couple of reasons:
  * = you really like to have this when you're running analyser tools
      like 'candump' or 'cansniffer' on the (same) node.
-  3.3 network security issues (capabilities)
+  3.3 network problem notifications
-  The Controller Area Network is a local field bus transmitting only
-  broadcast messages without any routing and security concepts.
-  In the majority of cases the user application has to deal with
-  raw CAN frames. Therefore it might be reasonable NOT to restrict
-  the CAN access only to the user root, as known from other networks.
-  Since the currently implemented CAN_RAW and CAN_BCM sockets can only
-  send and receive frames to/from CAN interfaces it does not affect
-  security of others networks to allow all users to access the CAN.
-  To enable non-root users to access CAN_RAW and CAN_BCM protocol
-  sockets the Kconfig options CAN_RAW_USER and/or CAN_BCM_USER may be
-  selected at kernel compile time.
-  3.4 network problem notifications
  The use of the CAN bus may lead to several problems on the physical
  and media access control layer. Detecting and logging of these lower
@@ -251,11 +236,11 @@ solution for a couple of reasons:
  by default. The format of the CAN error message frame is briefly
  described in the Linux header file "include/linux/can/error.h".
-4. How to use Socket CAN
+4. How to use SocketCAN
 ------------------------
  Like TCP/IP, you first need to open a socket for communicating over a
-  CAN network. Since Socket CAN implements a new protocol family, you
+  CAN network. Since SocketCAN implements a new protocol family, you
  need to pass PF_CAN as the first argument to the socket(2) system
  call. Currently, there are two CAN protocols to choose from, the raw
  socket protocol and the broadcast manager (BCM). So to open a socket,
@@ -286,8 +271,8 @@ solution for a couple of reasons:
    };
  The alignment of the (linear) payload data[] to a 64bit boundary
-  allows the user to define own structs and unions to easily access the
+  allows the user to define their own structs and unions to easily access
-  CAN payload. There is no given byteorder on the CAN bus by
+  the CAN payload. There is no given byteorder on the CAN bus by
  default. A read(2) system call on a CAN_RAW socket transfers a
  struct can_frame to the user space.
@@ -479,7 +464,7 @@ solution for a couple of reasons:
    setsockopt(s, SOL_CAN_RAW, CAN_RAW_FILTER, NULL, 0);
-  To set the filters to zero filters is quite obsolete as not read
+  To set the filters to zero filters is quite obsolete as to not read
  data causes the raw socket to discard the received CAN frames. But
  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.
@@ -814,17 +799,17 @@ solution for a couple of reasons:
  4.4 unconnected transport protocols (SOCK_DGRAM)
-5. Socket CAN core module
+5. SocketCAN core module
 -------------------------
-  The Socket CAN core module implements the protocol family
+  The SocketCAN core module implements the protocol family
  PF_CAN. CAN protocol modules are loaded by the core module at
  runtime. The core module provides an interface for CAN protocol
  modules to subscribe needed CAN IDs (see chapter 3.1).
  5.1 can.ko module params
-  - stats_timer: To calculate the Socket CAN core statistics
+  - stats_timer: To calculate the SocketCAN core statistics
    (e.g. current/maximum frames per second) this 1 second timer is
    invoked at can.ko module start time by default. This timer can be
    disabled by using stattimer=0 on the module commandline.
@@ -833,7 +818,7 @@ solution for a couple of reasons:
  5.2 procfs content
-  As described in chapter 3.1 the Socket CAN core uses several filter
+  As described in chapter 3.1 the SocketCAN core uses several filter
  lists to deliver received CAN frames to CAN protocol modules. These
  receive lists, their filters and the count of filter matches can be
  checked in the appropriate receive list. All entries contain the
@@ -860,15 +845,15 @@ solution for a couple of reasons:
  Additional procfs files in /proc/net/can
-    stats       - Socket CAN core statistics (rx/tx frames, match ratios, ...)
+    stats       - SocketCAN core statistics (rx/tx frames, match ratios, ...)
    reset_stats - manual statistic reset
-    version     - prints the Socket CAN core version and the ABI version
+    version     - prints the SocketCAN core version and the ABI version
  5.3 writing own CAN protocol modules
  To implement a new protocol in the protocol family PF_CAN a new
  protocol has to be defined in include/linux/can.h .
-  The prototypes and definitions to use the Socket CAN core can be
+  The prototypes and definitions to use the SocketCAN core can be
  accessed by including include/linux/can/core.h .
  In addition to functions that register the CAN protocol and the
  CAN device notifier chain there are functions to subscribe CAN
@@ -1105,7 +1090,7 @@ solution for a couple of reasons:
    $ ip link set canX up type can bitrate 125000
-  A device may enter the "bus-off" state if too much errors occurred on
+  A device may enter the "bus-off" state if too many errors occurred on
  the CAN bus. Then no more messages are received or sent. An automatic
  bus-off recovery can be enabled by setting the "restart-ms" to a
  non-zero value, e.g.:
@@ -1125,7 +1110,7 @@ solution for a couple of reasons:
  CAN FD capable CAN controllers support two different bitrates for the
  arbitration phase and the payload phase of the CAN FD frame. Therefore a
-  second bittiming has to be specified in order to enable the CAN FD bitrate.
+  second bit timing has to be specified in order to enable the CAN FD bitrate.
  Additionally CAN FD capable CAN controllers support up to 64 bytes of
  payload. The representation of this length in can_frame.can_dlc and
@@ -1150,21 +1135,16 @@ solution for a couple of reasons:
  6.7 Supported CAN hardware
  Please check the "Kconfig" file in "drivers/net/can" to get an actual
-  list of the support CAN hardware. On the Socket CAN project website
+  list of the support CAN hardware. On the SocketCAN project website
  (see chapter 7) there might be further drivers available, also for
  older kernel versions.
-7. Socket CAN resources
+7. SocketCAN resources
 -----------------------
-  You can find further resources for Socket CAN like user space tools,
+  The Linux CAN / SocketCAN project ressources (project site / mailing list)
-  support for old kernel versions, more drivers, mailing lists, etc.
+  are referenced in the MAINTAINERS file in the Linux source tree.
-  at the BerliOS OSS project website for Socket CAN:
+  Search for CAN NETWORK [LAYERS|DRIVERS].
-    http://developer.berlios.de/projects/socketcan
-  If you have questions, bug fixes, etc., don't hesitate to post them to
-  the Socketcan-Users mailing list. But please search the archives first.
 8. Credits
 ----------
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index cdb3e40b9d14..a06b48d2f5cc 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -1,49 +1,563 @@
-filter.txt: Linux Socket Filtering
+Linux Socket Filtering aka Berkeley Packet Filter (BPF)
-Written by: Jay Schulist <jschlst@samba.org>
+=======================================================
 Introduction
-============
+------------
-        Linux Socket Filtering is derived from the Berkeley
+Linux Socket Filtering (LSF) is derived from the Berkeley Packet Filter.
-Packet Filter. There are some distinct differences between
+Though there are some distinct differences between the BSD and Linux
-the BSD and Linux Kernel Filtering.
+Kernel filtering, but when we speak of BPF or LSF in Linux context, we
+mean the very same mechanism of filtering in the Linux kernel.
-Linux Socket Filtering (LSF) allows a user-space program to
-attach a filter onto any socket and allow or disallow certain
+BPF allows a user-space program to attach a filter onto any socket and
-types of data to come through the socket. LSF follows exactly
+allow or disallow certain types of data to come through the socket. LSF
-the same filter code structure as the BSD Berkeley Packet Filter
+follows exactly the same filter code structure as BSD's BPF, so referring
-(BPF), so referring to the BSD bpf.4 manpage is very helpful in
+to the BSD bpf.4 manpage is very helpful in creating filters.
-creating filters.
+On Linux, BPF is much simpler than on BSD. One does not have to worry
-LSF is much simpler than BPF. One does not have to worry about
+about devices or anything like that. You simply create your filter code,
-devices or anything like that. You simply create your filter
+send it to the kernel via the SO_ATTACH_FILTER option and if your filter
-code, send it to the kernel via the SO_ATTACH_FILTER option and
+code passes the kernel check on it, you then immediately begin filtering
-if your filter code passes the kernel check on it, you then
+data on that socket.
-immediately begin filtering data on that socket.
+You can also detach filters from your socket via the SO_DETACH_FILTER
-You can also detach filters from your socket via the
+option. This will probably not be used much since when you close a socket
-SO_DETACH_FILTER option. This will probably not be used much
+that has a filter on it the filter is automagically removed. The other
-since when you close a socket that has a filter on it the
+less common case may be adding a different filter on the same socket where
-filter is automagically removed. The other less common case
+you had another filter that is still running: the kernel takes care of
-may be adding a different filter on the same socket where you had another
+removing the old one and placing your new one in its place, assuming your
-filter that is still running: the kernel takes care of removing
+filter has passed the checks, otherwise if it fails the old filter will
-the old one and placing your new one in its place, assuming your
+remain on that socket.
-filter has passed the checks, otherwise if it fails the old filter
-will remain on that socket.
+SO_LOCK_FILTER option allows to lock the filter attached to a socket. Once
+set, a filter cannot be removed or changed. This allows one process to
-SO_LOCK_FILTER option allows to lock the filter attached to a
+setup a socket, attach a filter, lock it then drop privileges and be
-socket. Once set, a filter cannot be removed or changed. This allows
+assured that the filter will be kept until the socket is closed.
-one process to setup a socket, attach a filter, lock it then drop
-privileges and be assured that the filter will be kept until the
+The biggest user of this construct might be libpcap. Issuing a high-level
-socket is closed.
+filter command like `tcpdump -i em1 port 22` passes through the libpcap
+internal compiler that generates a structure that can eventually be loaded
-Examples
+via SO_ATTACH_FILTER to the kernel. `tcpdump -i em1 port 22 -ddd`
-========
+displays what is being placed into this structure.
-Ioctls-
+Although we were only speaking about sockets here, BPF in Linux is used
-setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
+in many more places. There's xt_bpf for netfilter, cls_bpf in the kernel
-setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
+qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places
-setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &value, sizeof(value));
+such as team driver, PTP code, etc where BPF is being used.
-See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
+ [1] Documentation/prctl/seccomp_filter.txt
-Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.
+Original BPF paper:
+Steven McCanne and Van Jacobson. 1993. The BSD packet filter: a new
+architecture for user-level packet capture. In Proceedings of the
+USENIX Winter 1993 Conference Proceedings on USENIX Winter 1993
+Conference Proceedings (USENIX'93). USENIX Association, Berkeley,
+CA, USA, 2-2. [http://www.tcpdump.org/papers/bpf-usenix93.pdf]
+Structure
+---------
+User space applications include <linux/filter.h> which contains the
+following relevant structures:
+struct sock_filter {    /* Filter block */
+        __u16   code;   /* Actual filter code */
+        __u8    jt;     /* Jump true */
+        __u8    jf;     /* Jump false */
+        __u32   k;      /* Generic multiuse field */
+};
+Such a structure is assembled as an array of 4-tuples, that contains
+a code, jt, jf and k value. jt and jf are jump offsets and k a generic
+value to be used for a provided code.
+struct sock_fprog {                     /* Required for SO_ATTACH_FILTER. */
+        unsigned short             len; /* Number of filter blocks */
+        struct sock_filter __user *filter;
+};
+For socket filtering, a pointer to this structure (as shown in
+follow-up example) is being passed to the kernel through setsockopt(2).
+Example
+-------
+#include <sys/socket.h>
+#include <sys/types.h>
+#include <arpa/inet.h>
+#include <linux/if_ether.h>
+/* ... */
+/* From the example above: tcpdump -i em1 port 22 -dd */
+struct sock_filter code[] = {
+        { 0x28,  0,  0, 0x0000000c },
+        { 0x15,  0,  8, 0x000086dd },
+        { 0x30,  0,  0, 0x00000014 },
+        { 0x15,  2,  0, 0x00000084 },
+        { 0x15,  1,  0, 0x00000006 },
+        { 0x15,  0, 17, 0x00000011 },
+        { 0x28,  0,  0, 0x00000036 },
+        { 0x15, 14,  0, 0x00000016 },
+        { 0x28,  0,  0, 0x00000038 },
+        { 0x15, 12, 13, 0x00000016 },
+        { 0x15,  0, 12, 0x00000800 },
+        { 0x30,  0,  0, 0x00000017 },
+        { 0x15,  2,  0, 0x00000084 },
+        { 0x15,  1,  0, 0x00000006 },
+        { 0x15,  0,  8, 0x00000011 },
+        { 0x28,  0,  0, 0x00000014 },
+        { 0x45,  6,  0, 0x00001fff },
+        { 0xb1,  0,  0, 0x0000000e },
+        { 0x48,  0,  0, 0x0000000e },
+        { 0x15,  2,  0, 0x00000016 },
+        { 0x48,  0,  0, 0x00000010 },
+        { 0x15,  0,  1, 0x00000016 },
+        { 0x06,  0,  0, 0x0000ffff },
+        { 0x06,  0,  0, 0x00000000 },
+};
+struct sock_fprog bpf = {
+        .len = ARRAY_SIZE(code),
+        .filter = code,
+};
+sock = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
+if (sock < 0)
+        /* ... bail out ... */
+ret = setsockopt(sock, SOL_SOCKET, SO_ATTACH_FILTER, &bpf, sizeof(bpf));
+if (ret < 0)
+        /* ... bail out ... */
+/* ... */
+close(sock);
+The above example code attaches a socket filter for a PF_PACKET socket
+in order to let all IPv4/IPv6 packets with port 22 pass. The rest will
+be dropped for this socket.
+The setsockopt(2) call to SO_DETACH_FILTER doesn't need any arguments
+and SO_LOCK_FILTER for preventing the filter to be detached, takes an
+integer value with 0 or 1.
+Note that socket filters are not restricted to PF_PACKET sockets only,
+but can also be used on other socket families.
+Summary of system calls:
+ * setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &val, sizeof(val));
+ * setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &val, sizeof(val));
+ * setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER,   &val, sizeof(val));
+Normally, most use cases for socket filtering on packet sockets will be
+covered by libpcap in high-level syntax, so as an application developer
+you should stick to that. libpcap wraps its own layer around all that.
+Unless i) using/linking to libpcap is not an option, ii) the required BPF
+filters use Linux extensions that are not supported by libpcap's compiler,
+iii) a filter might be more complex and not cleanly implementable with
+libpcap's compiler, or iv) particular filter codes should be optimized
+differently than libpcap's internal compiler does; then in such cases
+writing such a filter "by hand" can be of an alternative. For example,
+xt_bpf and cls_bpf users might have requirements that could result in
+more complex filter code, or one that cannot be expressed with libpcap
+(e.g. different return codes for various code paths). Moreover, BPF JIT
+implementors may wish to manually write test cases and thus need low-level
+access to BPF code as well.
+BPF engine and instruction set
+------------------------------
+Under tools/net/ there's a small helper tool called bpf_asm which can
+be used to write low-level filters for example scenarios mentioned in the
+previous section. Asm-like syntax mentioned here has been implemented in
+bpf_asm and will be used for further explanations (instead of dealing with
+less readable opcodes directly, principles are the same). The syntax is
+closely modelled after Steven McCanne's and Van Jacobson's BPF paper.
+The BPF architecture consists of the following basic elements:
+  Element          Description
+  A                32 bit wide accumulator
+  X                32 bit wide X register
+  M[]              16 x 32 bit wide misc registers aka "scratch memory
+                   store", addressable from 0 to 15
+A program, that is translated by bpf_asm into "opcodes" is an array that
+consists of the following elements (as already mentioned):
+  op:16, jt:8, jf:8, k:32
+The element op is a 16 bit wide opcode that has a particular instruction
+encoded. jt and jf are two 8 bit wide jump targets, one for condition
+"jump if true", the other one "jump if false". Eventually, element k
+contains a miscellaneous argument that can be interpreted in different
+ways depending on the given instruction in op.
+The instruction set consists of load, store, branch, alu, miscellaneous
+and return instructions that are also represented in bpf_asm syntax. This
+table lists all bpf_asm instructions available resp. what their underlying
+opcodes as defined in linux/filter.h stand for:
+  Instruction      Addressing mode      Description
+  ld               1, 2, 3, 4, 10       Load word into A
+  ldi              4                    Load word into A
+  ldh              1, 2                 Load half-word into A
+  ldb              1, 2                 Load byte into A
+  ldx              3, 4, 5, 10          Load word into X
+  ldxi             4                    Load word into X
+  ldxb             5                    Load byte into X
+  st               3                    Store A into M[]
+  stx              3                    Store X into M[]
+  jmp              6                    Jump to label
+  ja               6                    Jump to label
+  jeq              7, 8                 Jump on k == A
+  jneq             8                    Jump on k != A
+  jne              8                    Jump on k != A
+  jlt              8                    Jump on k < A
+  jle              8                    Jump on k <= A
+  jgt              7, 8                 Jump on k > A
+  jge              7, 8                 Jump on k >= A
+  jset             7, 8                 Jump on k & A
+  add              0, 4                 A + <x>
+  sub              0, 4                 A - <x>
+  mul              0, 4                 A * <x>
+  div              0, 4                 A / <x>
+  mod              0, 4                 A % <x>
+  neg              0, 4                 !A
+  and              0, 4                 A & <x>
+  or               0, 4                 A | <x>
+  xor              0, 4                 A ^ <x>
+  lsh              0, 4                 A << <x>
+  rsh              0, 4                 A >> <x>
+  tax                                   Copy A into X
+  txa                                   Copy X into A
+  ret              4, 9                 Return
+The next table shows addressing formats from the 2nd column:
+  Addressing mode  Syntax               Description
+   0               x/%x                 Register X
+   1               [k]                  BHW at byte offset k in the packet
+   2               [x + k]              BHW at the offset X + k in the packet
+   3               M[k]                 Word at offset k in M[]
+   4               #k                   Literal value stored in k
+   5               4*([k]&0xf)          Lower nibble * 4 at byte offset k in the packet
+   6               L                    Jump label L
+   7               #k,Lt,Lf             Jump to Lt if true, otherwise jump to Lf
+   8               #k,Lt                Jump to Lt if predicate is true
+   9               a/%a                 Accumulator A
+  10               extension            BPF extension
+The Linux kernel also has a couple of BPF extensions that are used along
+with the class of load instructions by "overloading" the k argument with
+a negative offset + a particular extension offset. The result of such BPF
+extensions are loaded into A.
+Possible BPF extensions are shown in the following table:
+  Extension                             Description
+  len                                   skb->len
+  proto                                 skb->protocol
+  type                                  skb->pkt_type
+  poff                                  Payload start offset
+  ifidx                                 skb->dev->ifindex
+  nla                                   Netlink attribute of type X with offset A
+  nlan                                  Nested Netlink attribute of type X with offset A
+  mark                                  skb->mark
+  queue                                 skb->queue_mapping
+  hatype                                skb->dev->type
+  rxhash                                skb->rxhash
+  cpu                                   raw_smp_processor_id()
+  vlan_tci                              vlan_tx_tag_get(skb)
+  vlan_pr                               vlan_tx_tag_present(skb)
+These extensions can also be prefixed with '#'.
+Examples for low-level BPF:
+** ARP packets:
+  ldh [12]
+  jne #0x806, drop
+  ret #-1
+  drop: ret #0
+** IPv4 TCP packets:
+  ldh [12]
+  jne #0x800, drop
+  ldb [23]
+  jneq #6, drop
+  ret #-1
+  drop: ret #0
+** (Accelerated) VLAN w/ id 10:
+  ld vlan_tci
+  jneq #10, drop
+  ret #-1
+  drop: ret #0
+** SECCOMP filter example:
+  ld [4]                  /* offsetof(struct seccomp_data, arch) */
+  jne #0xc000003e, bad    /* AUDIT_ARCH_X86_64 */
+  ld [0]                  /* offsetof(struct seccomp_data, nr) */
+  jeq #15, good           /* __NR_rt_sigreturn */
+  jeq #231, good          /* __NR_exit_group */
+  jeq #60, good           /* __NR_exit */
+  jeq #0, good            /* __NR_read */
+  jeq #1, good            /* __NR_write */
+  jeq #5, good            /* __NR_fstat */
+  jeq #9, good            /* __NR_mmap */
+  jeq #14, good           /* __NR_rt_sigprocmask */
+  jeq #13, good           /* __NR_rt_sigaction */
+  jeq #35, good           /* __NR_nanosleep */
+  bad: ret #0             /* SECCOMP_RET_KILL */
+  good: ret #0x7fff0000   /* SECCOMP_RET_ALLOW */
+The above example code can be placed into a file (here called "foo"), and
+then be passed to the bpf_asm tool for generating opcodes, output that xt_bpf
+and cls_bpf understands and can directly be loaded with. Example with above
+ARP code:
+$ ./bpf_asm foo
+4,40 0 0 12,21 0 1 2054,6 0 0 4294967295,6 0 0 0,
+In copy and paste C-like output:
+$ ./bpf_asm -c foo
+{ 0x28,  0,  0, 0x0000000c },
+{ 0x15,  0,  1, 0x00000806 },
+{ 0x06,  0,  0, 0xffffffff },
+{ 0x06,  0,  0, 0000000000 },
+In particular, as usage with xt_bpf or cls_bpf can result in more complex BPF
+filters that might not be obvious at first, it's good to test filters before
+attaching to a live system. For that purpose, there's a small tool called
+bpf_dbg under tools/net/ in the kernel source directory. This debugger allows
+for testing BPF filters against given pcap files, single stepping through the
+BPF code on the pcap's packets and to do BPF machine register dumps.
+Starting bpf_dbg is trivial and just requires issuing:
+# ./bpf_dbg
+In case input and output do not equal stdin/stdout, bpf_dbg takes an
+alternative stdin source as a first argument, and an alternative stdout
+sink as a second one, e.g. `./bpf_dbg test_in.txt test_out.txt`.
+Other than that, a particular libreadline configuration can be set via
+file "~/.bpf_dbg_init" and the command history is stored in the file
+"~/.bpf_dbg_history".
+Interaction in bpf_dbg happens through a shell that also has auto-completion
+support (follow-up example commands starting with '>' denote bpf_dbg shell).
+The usual workflow would be to ...
+> load bpf 6,40 0 0 12,21 0 3 2048,48 0 0 23,21 0 1 1,6 0 0 65535,6 0 0 0
+  Loads a BPF filter from standard output of bpf_asm, or transformed via
+  e.g. `tcpdump -iem1 -ddd port 22 | tr '\n' ','`. Note that for JIT
+  debugging (next section), this command creates a temporary socket and
+  loads the BPF code into the kernel. Thus, this will also be useful for
+  JIT developers.
+> load pcap foo.pcap
+  Loads standard tcpdump pcap file.
+> run [<n>]
+bpf passes:1 fails:9
+  Runs through all packets from a pcap to account how many passes and fails
+  the filter will generate. A limit of packets to traverse can be given.
+> disassemble
+l0:     ldh [12]
+l1:     jeq #0x800, l2, l5
+l2:     ldb [23]
+l3:     jeq #0x1, l4, l5
+l4:     ret #0xffff
+l5:     ret #0
+  Prints out BPF code disassembly.
+> dump
+/* { op, jt, jf, k }, */
+{ 0x28,  0,  0, 0x0000000c },
+{ 0x15,  0,  3, 0x00000800 },
+{ 0x30,  0,  0, 0x00000017 },
+{ 0x15,  0,  1, 0x00000001 },
+{ 0x06,  0,  0, 0x0000ffff },
+{ 0x06,  0,  0, 0000000000 },
+  Prints out C-style BPF code dump.
+> breakpoint 0
+breakpoint at: l0:      ldh [12]
+> breakpoint 1
+breakpoint at: l1:      jeq #0x800, l2, l5
+  ...
+  Sets breakpoints at particular BPF instructions. Issuing a `run` command
+  will walk through the pcap file continuing from the current packet and
+  break when a breakpoint is being hit (another `run` will continue from
+  the currently active breakpoint executing next instructions):
+  > run
+  -- register dump --
+  pc:       [0]                       <-- program counter
+  code:     [40] jt[0] jf[0] k[12]    <-- plain BPF code of current instruction
+  curr:     l0: ldh [12]              <-- disassembly of current instruction
+  A:        [00000000][0]             <-- content of A (hex, decimal)
+  X:        [00000000][0]             <-- content of X (hex, decimal)
+  M[0,15]:  [00000000][0]             <-- folded content of M (hex, decimal)
+  -- packet dump --                   <-- Current packet from pcap (hex)
+  len: 42
+    0: 00 19 cb 55 55 a4 00 14 a4 43 78 69 08 06 00 01
+   16: 08 00 06 04 00 01 00 14 a4 43 78 69 0a 3b 01 26
+   32: 00 00 00 00 00 00 0a 3b 01 01
+  (breakpoint)
+  >
+> breakpoint
+breakpoints: 0 1
+  Prints currently set breakpoints.
+> step [-<n>, +<n>]
+  Performs single stepping through the BPF program from the current pc
+  offset. Thus, on each step invocation, above register dump is issued.
+  This can go forwards and backwards in time, a plain `step` will break
+  on the next BPF instruction, thus +1. (No `run` needs to be issued here.)
+> select <n>
+  Selects a given packet from the pcap file to continue from. Thus, on
+  the next `run` or `step`, the BPF program is being evaluated against
+  the user pre-selected packet. Numbering starts just as in Wireshark
+  with index 1.
+> quit
+#
+  Exits bpf_dbg.
+JIT compiler
+------------
+The Linux kernel has a built-in BPF JIT compiler for x86_64, SPARC, PowerPC,
+ARM and s390 and can be enabled through CONFIG_BPF_JIT. The JIT compiler is
+transparently invoked for each attached filter from user space or for internal
+kernel users if it has been previously enabled by root:
+  echo 1 > /proc/sys/net/core/bpf_jit_enable
+For JIT developers, doing audits etc, each compile run can output the generated
+opcode image into the kernel log via:
+  echo 2 > /proc/sys/net/core/bpf_jit_enable
+Example output from dmesg:
+[ 3389.935842] flen=6 proglen=70 pass=3 image=ffffffffa0069c8f
+[ 3389.935847] JIT code: 00000000: 55 48 89 e5 48 83 ec 60 48 89 5d f8 44 8b 4f 68
+[ 3389.935849] JIT code: 00000010: 44 2b 4f 6c 4c 8b 87 d8 00 00 00 be 0c 00 00 00
+[ 3389.935850] JIT code: 00000020: e8 1d 94 ff e0 3d 00 08 00 00 75 16 be 17 00 00
+[ 3389.935851] JIT code: 00000030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 00 00
+[ 3389.935852] JIT code: 00000040: eb 02 31 c0 c9 c3
+In the kernel source tree under tools/net/, there's bpf_jit_disasm for
+generating disassembly out of the kernel log's hexdump:
+# ./bpf_jit_disasm
+70 bytes emitted from JIT compiler (pass:3, flen:6)
+ffffffffa0069c8f + <x>:
+   0:   push   %rbp
+   1:   mov    %rsp,%rbp
+   4:   sub    $0x60,%rsp
+   8:   mov    %rbx,-0x8(%rbp)
+   c:   mov    0x68(%rdi),%r9d
+  10:   sub    0x6c(%rdi),%r9d
+  14:   mov    0xd8(%rdi),%r8
+  1b:   mov    $0xc,%esi
+  20:   callq  0xffffffffe0ff9442
+  25:   cmp    $0x800,%eax
+  2a:   jne    0x0000000000000042
+  2c:   mov    $0x17,%esi
+  31:   callq  0xffffffffe0ff945e
+  36:   cmp    $0x1,%eax
+  39:   jne    0x0000000000000042
+  3b:   mov    $0xffff,%eax
+  40:   jmp    0x0000000000000044
+  42:   xor    %eax,%eax
+  44:   leaveq
+  45:   retq
+Issuing option `-o` will "annotate" opcodes to resulting assembler
+instructions, which can be very useful for JIT developers:
+# ./bpf_jit_disasm -o
+70 bytes emitted from JIT compiler (pass:3, flen:6)
+ffffffffa0069c8f + <x>:
+   0:   push   %rbp
+        55
+   1:   mov    %rsp,%rbp
+        48 89 e5
+   4:   sub    $0x60,%rsp
+        48 83 ec 60
+   8:   mov    %rbx,-0x8(%rbp)
+        48 89 5d f8
+   c:   mov    0x68(%rdi),%r9d
+        44 8b 4f 68
+  10:   sub    0x6c(%rdi),%r9d
+        44 2b 4f 6c
+  14:   mov    0xd8(%rdi),%r8
+        4c 8b 87 d8 00 00 00
+  1b:   mov    $0xc,%esi
+        be 0c 00 00 00
+  20:   callq  0xffffffffe0ff9442
+        e8 1d 94 ff e0
+  25:   cmp    $0x800,%eax
+        3d 00 08 00 00
+  2a:   jne    0x0000000000000042
+        75 16
+  2c:   mov    $0x17,%esi
+        be 17 00 00 00
+  31:   callq  0xffffffffe0ff945e
+        e8 28 94 ff e0
+  36:   cmp    $0x1,%eax
+        83 f8 01
+  39:   jne    0x0000000000000042
+        75 07
+  3b:   mov    $0xffff,%eax
+        b8 ff ff 00 00
+  40:   jmp    0x0000000000000044
+        eb 02
+  42:   xor    %eax,%eax
+        31 c0
+  44:   leaveq
+        c9
+  45:   retq
+        c3
+For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful
+toolchain for developing and testing the kernel's JIT compiler.
+Misc
+----
+Also trinity, the Linux syscall fuzzer, has built-in support for BPF and
+SECCOMP-BPF kernel fuzzing.
+Written by
+----------
+The document was written in the hope that it is found useful and in order
+to give potential BPF hackers or security auditors a better overview of
+the underlying architecture.
+Jay Schulist <jschlst@samba.org>
+Daniel Borkmann <dborkman@redhat.com>
diff --git a/Documentation/networking/i40evf.txt b/Documentation/networking/i40evf.txt
new file mode 100644
index 000000000000..21e41271af79
--- /dev/null
+++ b/Documentation/networking/i40evf.txt
@@ -0,0 +1,47 @@
+Linux* Base Driver for Intel(R) Network Connection
+==================================================
+Intel XL710 X710 Virtual Function Linux driver.
+Copyright(c) 2013 Intel Corporation.
+Contents
+========
+- Identifying Your Adapter
+- Known Issues/Troubleshooting
+- Support
+This file describes the i40evf Linux* Base Driver for the Intel(R) XL710
+X710 Virtual Function.
+The i40evf driver supports XL710 and X710 virtual function devices that
+can only be activated on kernels with CONFIG_PCI_IOV enabled.
+The guest OS loading the i40evf driver must support MSI-X interrupts.
+Identifying Your Adapter
+========================
+For more information on how to identify your adapter, go to the Adapter &
+Driver ID Guide at:
+    http://support.intel.com/support/go/network/adapter/idguide.htm
+Known Issues/Troubleshooting
+============================
+Support
+=======
+For general information, go to the Intel support website at:
+    http://support.intel.com
+or the Intel Wired Networking project hosted by Sourceforge at:
+    http://sourceforge.net/projects/e1000
+If an issue is identified with the released source code on the supported
+kernel with a supported adapter, email the specific information related
+to the issue to e1000-devel@lists.sf.net
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index 8a984e994e61..ab42c95f9985 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -15,17 +15,47 @@ ip_default_ttl - INTEGER
        forwarded) IP packets. Should be between 1 and 255 inclusive.
        Default: 64 (as recommended by RFC1700)
-ip_no_pmtu_disc - BOOLEAN
+ip_no_pmtu_disc - INTEGER
-        Disable Path MTU Discovery. If enabled and a
+        Disable Path MTU Discovery. If enabled in mode 1 and a
        fragmentation-required ICMP is received, the PMTU to this
        destination will be set to min_pmtu (see below). You will need
        to raise min_pmtu to the smallest interface MTU on your system
        manually if you want to avoid locally generated fragments.
+        In mode 2 incoming Path MTU Discovery messages will be
+        discarded. Outgoing frames are handled the same as in mode 1,
+        implicitly setting IP_PMTUDISC_DONT on every created socket.
+        Mode 3 is a hardend pmtu discover mode. The kernel will only
+        accept fragmentation-needed errors if the underlying protocol
+        can verify them besides a plain socket lookup. Current
+        protocols for which pmtu events will be honored are TCP, SCTP
+        and DCCP as they verify e.g. the sequence number or the
+        association. This mode should not be enabled globally but is
+        only intended to secure e.g. name servers in namespaces where
+        TCP path mtu must still work but path MTU information of other
+        protocols should be discarded. If enabled globally this mode
+        could break other protocols.
+        Possible values: 0-3
        Default: FALSE
 min_pmtu - INTEGER
        default 552 - minimum discovered Path MTU
+ip_forward_use_pmtu - BOOLEAN
+        By default we don't trust protocol path MTUs while forwarding
+        because they could be easily forged and can lead to unwanted
+        fragmentation by the router.
+        You only need to enable this if you have user-space software
+        which tries to discover path mtus by itself and depends on the
+        kernel honoring this information. This is normally not the
+        case.
+        Default: 0 (disabled)
+        Possible values:
+        0 - disabled
+        1 - enabled
 route/max_size - INTEGER
        Maximum number of routes allowed in the kernel.  Increase
        this when using large numbers of interfaces and/or routes.
@@ -160,6 +190,16 @@ tcp_app_win - INTEGER
        buffer. Value 0 is special, it means that nothing is reserved.
        Default: 31
+tcp_autocorking - BOOLEAN
+        Enable TCP auto corking :
+        When applications do consecutive small write()/sendmsg() system calls,
+        we try to coalesce these small writes as much as possible, to lower
+        total amount of sent packets. This is done if at least one prior
+        packet for the flow is waiting in Qdisc queues or device transmit
+        queue. Applications can still use TCP_CORK for optimal behavior
+        when they know how/when to uncork their sockets.
+        Default : 1
 tcp_available_congestion_control - STRING
        Shows the available congestion control choices that are registered.
        More congestion control algorithms may be available as modules,
@@ -1048,6 +1088,12 @@ igmpv3_unsolicited_report_interval - INTEGER
        IGMPv3 report retransmit will take place.
        Default: 1000 (1 seconds)
+promote_secondaries - BOOLEAN
+        When a primary IP address is removed from this interface
+        promote a corresponding secondary IP address instead of
+        removing all the corresponding secondary IP addresses.
 tag - INTEGER
        Allows you to write a number, which can be used as required.
        Default value is 0.
@@ -1078,6 +1124,21 @@ bindv6only - BOOLEAN
        Default: FALSE (as specified in RFC3493)
+flowlabel_consistency - BOOLEAN
+        Protect the consistency (and unicity) of flow label.
+        You have to disable it to use IPV6_FL_F_REFLECT flag on the
+        flow label manager.
+        TRUE: enabled
+        FALSE: disabled
+        Default: TRUE
+anycast_src_echo_reply - BOOLEAN
+        Controls the use of anycast addresses as source addresses for ICMPv6
+        echo reply
+        TRUE:  enabled
+        FALSE: disabled
+        Default: FALSE
 IPv6 Fragmentation:
 ip6frag_high_thresh - INTEGER
diff --git a/Documentation/networking/ipsec.txt b/Documentation/networking/ipsec.txt
new file mode 100644
index 000000000000..8dbc08b7e431
--- /dev/null
+++ b/Documentation/networking/ipsec.txt
@@ -0,0 +1,38 @@
+Here documents known IPsec corner cases which need to be keep in mind when
+deploy various IPsec configuration in real world production environment.
+1. IPcomp: Small IP packet won't get compressed at sender, and failed on
+           policy check on receiver.
+Quote from RFC3173:
+2.2. Non-Expansion Policy
+   If the total size of a compressed payload and the IPComp header, as
+   defined in section 3, is not smaller than the size of the original
+   payload, the IP datagram MUST be sent in the original non-compressed
+   form.  To clarify: If an IP datagram is sent non-compressed, no
+   IPComp header is added to the datagram.  This policy ensures saving
+   the decompression processing cycles and avoiding incurring IP
+   datagram fragmentation when the expanded datagram is larger than the
+   MTU.
+   Small IP datagrams are likely to expand as a result of compression.
+   Therefore, a numeric threshold should be applied before compression,
+   where IP datagrams of size smaller than the threshold are sent in the
+   original form without attempting compression.  The numeric threshold
+   is implementation dependent.
+Current IPComp implementation is indeed by the book, while as in practice
+when sending non-compressed packet to the peer(whether or not packet len
+is smaller than the threshold or the compressed len is large than original
+packet len), the packet is dropped when checking the policy as this packet
+matches the selector but not coming from any XFRM layer, i.e., with no
+security path. Such naked packet will not eventually make it to upper layer.
+The result is much more wired to the user when ping peer with different
+payload length.
+One workaround is try to set "level use" for each policy if user observed
+above scenario. The consequence of doing so is small packet(uncompressed)
+will skip policy checking on receiver side.
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 8e48e3b14227..1404674c0a02 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -98,6 +98,11 @@ by the kernel.
 The destruction of the socket and all associated resources
 is done by a simple call to close(fd).
+Similarly as without PACKET_MMAP, it is possible to use one socket
+for capture and transmission. This can be done by mapping the
+allocated RX and TX buffer ring with a single mmap() call.
+See "Mapping and use of the circular buffer (ring)".
 Next I will describe PACKET_MMAP settings and its constraints,
 also the mapping of the circular buffer in the user process and 
 the use of this buffer.
@@ -414,6 +419,19 @@ tp_block_size/tp_frame_size frames there will be a gap between
 the frames. This is because a frame cannot be spawn across two
 blocks. 
+To use one socket for capture and transmission, the mapping of both the
+RX and TX buffer ring has to be done with one call to mmap:
+    ...
+    setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &foo, sizeof(foo));
+    setsockopt(fd, SOL_PACKET, PACKET_TX_RING, &bar, sizeof(bar));
+    ...
+    rx_ring = mmap(0, size * 2, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
+    tx_ring = rx_ring + size;
+RX must be the first as the kernel maps the TX ring memory right
+after the RX one.
 At the beginning of each frame there is an status field (see 
 struct tpacket_hdr). If this field is 0 means that the frame is ready
 to be used for the kernel, If not, there is a frame the user can read 
@@ -517,8 +535,6 @@ where 'tpacket_version' can be TPACKET_V1 (default), TPACKET_V2, TPACKET_V3.
 TPACKET_V1:
        - Default if not otherwise specified by setsockopt(2)
        - RX_RING, TX_RING available
-        - VLAN metadata information available for packets
-          (TP_STATUS_VLAN_VALID)
 TPACKET_V1 --> TPACKET_V2:
        - Made 64 bit clean due to unsigned long usage in TPACKET_V1
@@ -526,6 +542,13 @@ TPACKET_V1 --> TPACKET_V2:
          userspace and the like
        - Timestamp resolution in nanoseconds instead of microseconds
        - RX_RING, TX_RING available
+        - VLAN metadata information available for packets
+          (TP_STATUS_VLAN_VALID, TP_STATUS_VLAN_TPID_VALID),
+          in the tpacket2_hdr structure:
+                - TP_STATUS_VLAN_VALID bit being set into the tp_status field indicates
+                  that the tp_vlan_tci field has valid VLAN TCI value
+                - TP_STATUS_VLAN_TPID_VALID bit being set into the tp_status field
+                  indicates that the tp_vlan_tpid field has valid VLAN TPID value
        - How to switch to TPACKET_V2:
                1. Replace struct tpacket_hdr by struct tpacket2_hdr
                2. Query header len and save
@@ -560,6 +583,7 @@ Currently implemented fanout policies are:
  - PACKET_FANOUT_CPU: schedule to socket by CPU packet arrives on
  - PACKET_FANOUT_RND: schedule to socket by random selection
  - PACKET_FANOUT_ROLLOVER: if one socket is full, rollover to another
+  - PACKET_FANOUT_QM: schedule to socket by skbs recorded queue_mapping
 Minimal example code by David S. Miller (try things like "./test eth0 hash",
 "./test eth0 lb", etc.):
@@ -953,6 +977,27 @@ int main(int argc, char **argp)
 }
 -------------------------------------------------------------------------------
+ PACKET_QDISC_BYPASS
+-------------------------------------------------------------------------------
+If there is a requirement to load the network with many packets in a similar
+fashion as pktgen does, you might set the following option after socket
+creation:
+    int one = 1;
+    setsockopt(fd, SOL_PACKET, PACKET_QDISC_BYPASS, &one, sizeof(one));
+This has the side-effect, that packets sent through PF_PACKET will bypass the
+kernel's qdisc layer and are forcedly pushed to the driver directly. Meaning,
+packet are not buffered, tc disciplines are ignored, increased loss can occur
+and such packets are also not visible to other PF_PACKET sockets anymore. So,
+you have been warned; generally, this can be useful for stress testing various
+components of a system.
+On default, PACKET_QDISC_BYPASS is disabled and needs to be explicitly enabled
+on PF_PACKET sockets.
+-------------------------------------------------------------------------------
 + PACKET_TIMESTAMP
 -------------------------------------------------------------------------------
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index d5b1a3935245..ebf270719402 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -255,7 +255,8 @@ Writing a PHY driver
   config_init: configures PHY into a sane state after a reset.
     For instance, a Davicom PHY requires descrambling disabled.
-   probe: Does any setup needed by the driver
+   probe: Allocate phy->priv, optionally refuse to bind.
+   PHY may not have been reset or had fixups run yet.
   suspend/resume: power management
   config_aneg: Changes the speed/duplex/negotiation settings
   read_status: Reads the current speed/duplex/negotiation settings
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index 75e4fd708ccb..5a61a240a652 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -108,7 +108,9 @@ Examples:
                              MPLS_RND, VID_RND, SVID_RND
                              QUEUE_MAP_RND # queue map random
                              QUEUE_MAP_CPU # queue map mirrors smp_processor_id()
+                              IPSEC # Make IPsec encapsulation for packet
+ pgset spi SPI_VALUE     Set specific SA used to transform packet.
 pgset "udp_src_min 9"   set UDP source port min, If < udp_src_max, then
                         cycle through the port range.
@@ -177,6 +179,18 @@ Note when adding devices to a specific CPU there good idea to also assign
 /proc/irq/XX/smp_affinity so the TX-interrupts gets bound to the same CPU.
 as this reduces cache bouncing when freeing skb's.
+Enable IPsec
+============
+Default IPsec transformation with ESP encapsulation plus Transport mode
+could be enabled by simply setting:
+pgset "flag IPSEC"
+pgset "flows 1"
+To avoid breaking existing testbed scripts for using AH type and tunnel mode,
+user could use "pgset spi SPI_VALUE" to specify which formal of transformation
+to employ.
 Current commands and configuration options
 ==========================================
@@ -225,6 +239,7 @@ flag
  UDPDST_RND
  MACSRC_RND
  MACDST_RND
+  IPSEC
 dst_min
 dst_max
diff --git a/Documentation/networking/regulatory.txt b/Documentation/networking/regulatory.txt
index 9551622d0a7b..356f791af574 100644
--- a/Documentation/networking/regulatory.txt
+++ b/Documentation/networking/regulatory.txt
@@ -159,10 +159,10 @@ struct ieee80211_regdomain mydriver_jp_regdom = {
                REG_RULE(2412-20, 2484+20, 40, 6, 20, 0),
                /* IEEE 802.11a, channels 34..48 */
                REG_RULE(5170-20, 5240+20, 40, 6, 20,
-                        NL80211_RRF_PASSIVE_SCAN),
+                        NL80211_RRF_NO_IR),
                /* IEEE 802.11a, channels 52..64 */
                REG_RULE(5260-20, 5320+20, 40, 6, 20,
-                        NL80211_RRF_NO_IBSS |
+                        NL80211_RRF_NO_IR|
                        NL80211_RRF_DFS),
        }
 };
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index cdd916da838d..2090895b08d4 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -127,8 +127,9 @@ struct plat_stmmacenet_data {
        int riwt_off;
        void (*fix_mac_speed)(void *priv, unsigned int speed);
        void (*bus_setup)(void __iomem *ioaddr);
-        int (*init)(struct platform_device *pdev);
+        void *(*setup)(struct platform_device *pdev);
-        void (*exit)(struct platform_device *pdev);
+        int (*init)(struct platform_device *pdev, void *priv);
+        void (*exit)(struct platform_device *pdev, void *priv);
        void *custom_cfg;
        void *custom_data;
        void *bsp_priv;
@@ -169,10 +170,13 @@ Where:
 o bus_setup: perform HW setup of the bus. For example, on some ST platforms
             this field is used to configure the AMBA  bridge to generate more
             efficient STBus traffic.
- o init/exit: callbacks used for calling a custom initialization;
+ o setup/init/exit: callbacks used for calling a custom initialization;
             this is sometime necessary on some platforms (e.g. ST boxes)
             where the HW needs to have set some PIO lines or system cfg
-             registers.
+             registers. setup should return a pointer to private data,
+             which will be stored in bsp_priv, and then passed to init and
+             exit callbacks. init/exit callbacks should not use or modify
+             platform data.
 o custom_cfg/custom_data: this is a custom configuration that can be passed
                           while initializing the resources.
 o bsp_priv: another private pointer.
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 98097d8cb910..661d3c316a17 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -85,7 +85,7 @@ Filled in if SOF_TIMESTAMPING_SYS_HARDWARE is set. Requires support
 by the network device and will be empty without that support.
-SIOCSHWTSTAMP:
+SIOCSHWTSTAMP, SIOCGHWTSTAMP:
 Hardware time stamping must also be initialized for each device driver
 that is expected to do hardware time stamping. The parameter is defined in
@@ -115,6 +115,10 @@ Only a processes with admin rights may change the configuration. User
 space is responsible to ensure that multiple processes don't interfere
 with each other and that the settings are reset.
+Any process can read the actual configuration by passing this
+structure to ioctl(SIOCGHWTSTAMP) in the same way.  However, this has
+not been implemented in all drivers.
 /* possible values for hwtstamp_config->tx_type */
 enum {
        /*
@@ -157,7 +161,8 @@ DEVICE IMPLEMENTATION
 A driver which supports hardware time stamping must support the
 SIOCSHWTSTAMP ioctl and update the supplied struct hwtstamp_config with
-the actual values as described in the section on SIOCSHWTSTAMP.
+the actual values as described in the section on SIOCSHWTSTAMP.  It
+should also support SIOCGHWTSTAMP.
 Time stamps for received packets must be stored in the skb. To get a pointer
 to the shared time stamp structure of the skb call skb_hwtstamps(). Then
diff --git a/Documentation/networking/timestamping/.gitignore b/Documentation/networking/timestamping/.gitignore
index 71e81eb2e22f..a380159765ce 100644
--- a/Documentation/networking/timestamping/.gitignore
+++ b/Documentation/networking/timestamping/.gitignore
@@ -1 +1,2 @@
 timestamping
+hwtstamp_config
diff --git a/Documentation/networking/timestamping/Makefile b/Documentation/networking/timestamping/Makefile
index e79973443e9f..d934afc8306a 100644
--- a/Documentation/networking/timestamping/Makefile
+++ b/Documentation/networking/timestamping/Makefile
@@ -2,12 +2,13 @@
 obj- := dummy.o
 # List of programs to build
-hostprogs-y := timestamping
+hostprogs-y := timestamping hwtstamp_config
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
 HOSTCFLAGS_timestamping.o += -I$(objtree)/usr/include
+HOSTCFLAGS_hwtstamp_config.o += -I$(objtree)/usr/include
 clean:
-        rm -f timestamping
+        rm -f timestamping hwtstamp_config
diff --git a/Documentation/networking/timestamping/hwtstamp_config.c b/Documentation/networking/timestamping/hwtstamp_config.c
new file mode 100644
index 000000000000..e8b685a7f15f
--- /dev/null
+++ b/Documentation/networking/timestamping/hwtstamp_config.c
@@ -0,0 +1,134 @@
+/* Test program for SIOC{G,S}HWTSTAMP
+ * Copyright 2013 Solarflare Communications
+ * Author: Ben Hutchings
+ */
+#include <errno.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <sys/socket.h>
+#include <sys/ioctl.h>
+#include <linux/if.h>
+#include <linux/net_tstamp.h>
+#include <linux/sockios.h>
+static int
+lookup_value(const char **names, int size, const char *name)
+{
+        int value;
+        for (value = 0; value < size; value++)
+                if (names[value] && strcasecmp(names[value], name) == 0)
+                        return value;
+        return -1;
+}
+static const char *
+lookup_name(const char **names, int size, int value)
+{
+        return (value >= 0 && value < size) ? names[value] : NULL;
+}
+static void list_names(FILE *f, const char **names, int size)
+{
+        int value;
+        for (value = 0; value < size; value++)
+                if (names[value])
+                        fprintf(f, "    %s\n", names[value]);
+}
+static const char *tx_types[] = {
+#define TX_TYPE(name) [HWTSTAMP_TX_ ## name] = #name
+        TX_TYPE(OFF),
+        TX_TYPE(ON),
+        TX_TYPE(ONESTEP_SYNC)
+#undef TX_TYPE
+};
+#define N_TX_TYPES ((int)(sizeof(tx_types) / sizeof(tx_types[0])))
+static const char *rx_filters[] = {
+#define RX_FILTER(name) [HWTSTAMP_FILTER_ ## name] = #name
+        RX_FILTER(NONE),
+        RX_FILTER(ALL),
+        RX_FILTER(SOME),
+        RX_FILTER(PTP_V1_L4_EVENT),
+        RX_FILTER(PTP_V1_L4_SYNC),
+        RX_FILTER(PTP_V1_L4_DELAY_REQ),
+        RX_FILTER(PTP_V2_L4_EVENT),
+        RX_FILTER(PTP_V2_L4_SYNC),
+        RX_FILTER(PTP_V2_L4_DELAY_REQ),
+        RX_FILTER(PTP_V2_L2_EVENT),
+        RX_FILTER(PTP_V2_L2_SYNC),
+        RX_FILTER(PTP_V2_L2_DELAY_REQ),
+        RX_FILTER(PTP_V2_EVENT),
+        RX_FILTER(PTP_V2_SYNC),
+        RX_FILTER(PTP_V2_DELAY_REQ),
+#undef RX_FILTER
+};
+#define N_RX_FILTERS ((int)(sizeof(rx_filters) / sizeof(rx_filters[0])))
+static void usage(void)
+{
+        fputs("Usage: hwtstamp_config if_name [tx_type rx_filter]\n"
+              "tx_type is any of (case-insensitive):\n",
+              stderr);
+        list_names(stderr, tx_types, N_TX_TYPES);
+        fputs("rx_filter is any of (case-insensitive):\n", stderr);
+        list_names(stderr, rx_filters, N_RX_FILTERS);
+}
+int main(int argc, char **argv)
+{
+        struct ifreq ifr;
+        struct hwtstamp_config config;
+        const char *name;
+        int sock;
+        if ((argc != 2 && argc != 4) || (strlen(argv[1]) >= IFNAMSIZ)) {
+                usage();
+                return 2;
+        }
+        if (argc == 4) {
+                config.flags = 0;
+                config.tx_type = lookup_value(tx_types, N_TX_TYPES, argv[2]);
+                config.rx_filter = lookup_value(rx_filters, N_RX_FILTERS, argv[3]);
+                if (config.tx_type < 0 || config.rx_filter < 0) {
+                        usage();
+                        return 2;
+                }
+        }
+        sock = socket(AF_INET, SOCK_DGRAM, 0);
+        if (sock < 0) {
+                perror("socket");
+                return 1;
+        }
+        strcpy(ifr.ifr_name, argv[1]);
+        ifr.ifr_data = (caddr_t)&config;
+        if (ioctl(sock, (argc == 2) ? SIOCGHWTSTAMP : SIOCSHWTSTAMP, &ifr)) {
+                perror("ioctl");
+                return 1;
+        }
+        printf("flags = %#x\n", config.flags);
+        name = lookup_name(tx_types, N_TX_TYPES, config.tx_type);
+        if (name)
+                printf("tx_type = %s\n", name);
+        else
+                printf("tx_type = %d\n", config.tx_type);
+        name = lookup_name(rx_filters, N_RX_FILTERS, config.rx_filter);
+        if (name)
+                printf("rx_filter = %s\n", name);
+        else
+                printf("rx_filter = %d\n", config.rx_filter);
+        return 0;
+}
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index a7929cb47e7c..23f1590f49fe 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -18,7 +18,7 @@ Definition of PIN CONTROLLER:
 - A pin controller is a piece of hardware, usually a set of registers, that
  can control PINs. It may be able to multiplex, bias, set load capacitance,
-  set drive strength etc for individual pins or groups of pins.
+  set drive strength, etc. for individual pins or groups of pins.
 Definition of PIN:
@@ -90,7 +90,7 @@ selected drivers, you need to select them from your machine's Kconfig entry,
 since these are so tightly integrated with the machines they are used on.
 See for example arch/arm/mach-u300/Kconfig for an example.
-Pins usually have fancier names than this. You can find these in the dataheet
+Pins usually have fancier names than this. You can find these in the datasheet
 for your chip. Notice that the core pinctrl.h file provides a fancy macro
 called PINCTRL_PIN() to create the struct entries. As you can see I enumerated
 the pins from 0 in the upper left corner to 63 in the lower right corner.
@@ -185,7 +185,7 @@ static struct pinctrl_desc foo_desc = {
 };
 The pin control subsystem will call the .get_groups_count() function to
-determine total number of legal selectors, then it will call the other functions
+determine the total number of legal selectors, then it will call the other functions
 to retrieve the name and pins of the group. Maintaining the data structure of
 the groups is up to the driver, this is just a simple example - in practice you
 may need more entries in your group structure, for example specific register
@@ -195,7 +195,7 @@ ranges associated with each group and so on.
 Pin configuration
 =================
-Pins can sometimes be software-configured in an various ways, mostly related
+Pins can sometimes be software-configured in various ways, mostly related
 to their electronic properties when used as inputs or outputs. For example you
 may be able to make an output pin high impedance, or "tristate" meaning it is
 effectively disconnected. You may be able to connect an input pin to VDD or GND
@@ -291,7 +291,7 @@ Since the pin controller subsystem have its pinspace local to the pin
 controller we need a mapping so that the pin control subsystem can figure out
 which pin controller handles control of a certain GPIO pin. Since a single
 pin controller may be muxing several GPIO ranges (typically SoCs that have
-one set of pins but internally several GPIO silicon blocks, each modelled as
+one set of pins, but internally several GPIO silicon blocks, each modelled as
 a struct gpio_chip) any number of GPIO ranges can be added to a pin controller
 instance like this:
@@ -373,9 +373,9 @@ will be called on that specific pin controller.
 For all functionalities dealing with pin biasing, pin muxing etc, the pin
 controller subsystem will look up the corresponding pin number from the passed
-in gpio number, and use the range's internals to retrive a pin number. After
+in gpio number, and use the range's internals to retrieve a pin number. After
 that, the subsystem passes it on to the pin control driver, so the driver
-will get an pin number into its handled number range. Further it is also passed
+will get a pin number into its handled number range. Further it is also passed
 the range ID value, so that the pin controller knows which range it should
 deal with.
@@ -430,8 +430,8 @@ pins you see some will be taken by things like a few VCC and GND to feed power
 to the chip, and quite a few will be taken by large ports like an external
 memory interface. The remaining pins will often be subject to pin multiplexing.
-The example 8x8 PGA package above will have pin numbers 0 thru 63 assigned to
+The example 8x8 PGA package above will have pin numbers 0 through 63 assigned
-its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
+to its physical pins. It will name the pins { A1, A2, A3 ... H6, H7, H8 } using
 pinctrl_register_pins() and a suitable data set as shown earlier.
 In this 8x8 BGA package the pins { A8, A7, A6, A5 } can be used as an SPI port
@@ -442,7 +442,7 @@ we cannot use the SPI port and I2C port at the same time. However in the inside
 of the package the silicon performing the SPI logic can alternatively be routed
 out on pins { G4, G3, G2, G1 }.
-On the botton row at { A1, B1, C1, D1, E1, F1, G1, H1 } we have something
+On the bottom row at { A1, B1, C1, D1, E1, F1, G1, H1 } we have something
 special - it's an external MMC bus that can be 2, 4 or 8 bits wide, and it will
 consume 2, 4 or 8 pins respectively, so either { A1, B1 } are taken or
 { A1, B1, C1, D1 } or all of them. If we use all 8 bits, we cannot use the SPI
@@ -549,7 +549,7 @@ Assumptions:
 We assume that the number of possible function maps to pin groups is limited by
 the hardware. I.e. we assume that there is no system where any function can be
-mapped to any pin, like in a phone exchange. So the available pins groups for
+mapped to any pin, like in a phone exchange. So the available pin groups for
 a certain function will be limited to a few choices (say up to eight or so),
 not hundreds or any amount of choices. This is the characteristic we have found
 by inspecting available pinmux hardware, and a necessary assumption since we
@@ -564,7 +564,7 @@ The pinmux core takes care of preventing conflicts on pins and calling
 the pin controller driver to execute different settings.
 It is the responsibility of the pinmux driver to impose further restrictions
-(say for example infer electronic limitations due to load etc) to determine
+(say for example infer electronic limitations due to load, etc.) to determine
 whether or not the requested function can actually be allowed, and in case it
 is possible to perform the requested mux setting, poke the hardware so that
 this happens.
@@ -755,7 +755,7 @@ Pin control interaction with the GPIO subsystem
 Note that the following implies that the use case is to use a certain pin
 from the Linux kernel using the API in <linux/gpio.h> with gpio_request()
 and similar functions. There are cases where you may be using something
-that your datasheet calls "GPIO mode" but actually is just an electrical
+that your datasheet calls "GPIO mode", but actually is just an electrical
 configuration for a certain device. See the section below named
 "GPIO mode pitfalls" for more details on this scenario.
@@ -871,7 +871,7 @@ hardware and shall be put into different subsystems:
 - Registers (or fields within registers) that control muxing of signals
  from various other HW blocks (e.g. I2C, MMC, or GPIO) onto pins should
-  be exposed through the pinctrl subssytem, as mux functions.
+  be exposed through the pinctrl subsystem, as mux functions.
 - Registers (or fields within registers) that control GPIO functionality
  such as setting a GPIO's output value, reading a GPIO's input value, or
@@ -895,7 +895,7 @@ Example: a pin is usually muxed in to be used as a UART TX line. But during
 system sleep, we need to put this pin into "GPIO mode" and ground it.
 If you make a 1-to-1 map to the GPIO subsystem for this pin, you may start
-to think that you need to come up with something real complex, that the
+to think that you need to come up with something really complex, that the
 pin shall be used for UART TX and GPIO at the same time, that you will grab
 a pin control handle and set it to a certain state to enable UART TX to be
 muxed in, then twist it over to GPIO mode and use gpio_direction_output()
@@ -964,12 +964,12 @@ GPIO mode.
 This will give the desired effect without any bogus interaction with the
 GPIO subsystem. It is just an electrical configuration used by that device
 when going to sleep, it might imply that the pin is set into something the
-datasheet calls "GPIO mode" but that is not the point: it is still used
+datasheet calls "GPIO mode", but that is not the point: it is still used
 by that UART device to control the pins that pertain to that very UART
 driver, putting them into modes needed by the UART. GPIO in the Linux
 kernel sense are just some 1-bit line, and is a different use case.
-How the registers are poked to attain the push/pull and output low
+How the registers are poked to attain the push or pull, and output low
 configuration and the muxing of the "u0" or "gpio-mode" group onto these
 pins is a question for the driver.
@@ -977,7 +977,7 @@ Some datasheets will be more helpful and refer to the "GPIO mode" as
 "low power mode" rather than anything to do with GPIO. This often means
 the same thing electrically speaking, but in this latter case the
 software engineers will usually quickly identify that this is some
-specific muxing/configuration rather than anything related to the GPIO
+specific muxing or configuration rather than anything related to the GPIO
 API.
@@ -1024,8 +1024,7 @@ up the device struct (just like with clockdev or regulators). The function name
 must match a function provided by the pinmux driver handling this pin range.
 As you can see we may have several pin controllers on the system and thus
-we need to specify which one of them that contain the functions we wish
+we need to specify which one of them contains the functions we wish to map.
-to map.
 You register this pinmux mapping to the pinmux subsystem by simply:
@@ -1254,10 +1253,10 @@ The semantics of the pinctrl APIs are:
  pinctrl_get().
 - pinctrl_lookup_state() is called in process context to obtain a handle to a
-  specific state for a the client device. This operation may be slow too.
+  specific state for a client device. This operation may be slow, too.
 - pinctrl_select_state() programs pin controller hardware according to the
-  definition of the state as given by the mapping table. In theory this is a
+  definition of the state as given by the mapping table. In theory, this is a
  fast-path operation, since it only involved blasting some register settings
  into hardware. However, note that some pin controllers may have their
  registers on a slow/IRQ-based bus, so client devices should not assume they
diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt
index e9b54de8fdf7..edeecd447d23 100644
--- a/Documentation/power/basic-pm-debugging.txt
+++ b/Documentation/power/basic-pm-debugging.txt
@@ -172,7 +172,7 @@ you can boot the kernel with the 'no_console_suspend' parameter and try to log
 kernel messages using the serial console.  This may provide you with some
 information about the reasons of the suspend (resume) failure.  Alternatively,
 it may be possible to use a FireWire port for debugging with firescope
-(ftp://ftp.firstfloor.org/pub/ak/firescope/).  On x86 it is also possible to
+(http://v3.sk/~lkundrak/firescope/).  On x86 it is also possible to
 use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt .
 2. Testing suspend to RAM (STR)
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 445ad743ec81..6f4eb322ffaf 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -55,14 +55,21 @@ Struct Resources:
        For printing struct resources. The 'R' and 'r' specifiers result in a
        printed resource with ('R') or without ('r') a decoded flags member.
-Physical addresses:
+Physical addresses types phys_addr_t:
-        %pa     0x01234567 or 0x0123456789abcdef
+        %pa[p]  0x01234567 or 0x0123456789abcdef
        For printing a phys_addr_t type (and its derivatives, such as
        resource_size_t) which can vary based on build options, regardless of
        the width of the CPU data path. Passed by reference.
+DMA addresses types dma_addr_t:
+        %pad    0x01234567 or 0x0123456789abcdef
+        For printing a dma_addr_t type which can vary based on build options,
+        regardless of the width of the CPU data path. Passed by reference.
 Raw buffer as a hex string:
        %*ph    00 01 02  ...  3f
        %*phC   00:01:02: ... :3f
diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt
index 03c9d9299c6b..f430004df73c 100644
--- a/Documentation/rfkill.txt
+++ b/Documentation/rfkill.txt
@@ -71,7 +71,7 @@ To create an rfkill driver, driver's Kconfig needs to have
        depends on RFKILL || !RFKILL
 to ensure the driver cannot be built-in when rfkill is modular. The !RFKILL
-case allows the driver to be built when rfkill is not configured, which which
+case allows the driver to be built when rfkill is not configured, which
 case all rfkill API can still be used but will be provided by static inlines
 which compile to almost nothing.
diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt
index a5bcd7f5c33f..8666070d3189 100644
--- a/Documentation/rt-mutex-design.txt
+++ b/Documentation/rt-mutex-design.txt
@@ -30,7 +30,7 @@ is something called unbounded priority inversion.  That is when the high
 priority process is prevented from running by a lower priority process for
 an undetermined amount of time.
-The classic example of unbounded priority inversion is were you have three
+The classic example of unbounded priority inversion is where you have three
 processes, let's call them processes A, B, and C, where A is the highest
 priority process, C is the lowest, and B is in between. A tries to grab a lock
 that C owns and must wait and lets C run to release the lock. But in the
diff --git a/Documentation/s390/qeth.txt b/Documentation/s390/qeth.txt
new file mode 100644
index 000000000000..74122ada9949
--- /dev/null
+++ b/Documentation/s390/qeth.txt
@@ -0,0 +1,50 @@
+IBM s390 QDIO Ethernet Driver
+HiperSockets Bridge Port Support
+Uevents
+To generate the events the device must be assigned a role of either
+a primary or a secondary Bridge Port. For more information, see
+"z/VM Connectivity, SC24-6174".
+When run on HiperSockets Bridge Capable Port hardware, and the state
+of some configured Bridge Port device on the channel changes, a udev
+event with ACTION=CHANGE is emitted on behalf of the corresponding
+ccwgroup device. The event has the following attributes:
+BRIDGEPORT=statechange -  indicates that the Bridge Port device changed
+  its state.
+ROLE={primary|secondary|none} - the role assigned to the port.
+STATE={active|standby|inactive} - the newly assumed state of the port.
+When run on HiperSockets Bridge Capable Port hardware with host address
+notifications enabled, a udev event with ACTION=CHANGE is emitted.
+It is emitted on behalf of the corresponding ccwgroup device when a host
+or a VLAN is registered or unregistered on the network served by the device.
+The event has the following attributes:
+BRIDGEDHOST={reset|register|deregister|abort} - host address
+  notifications are started afresh, a new host or VLAN is registered or
+  deregistered on the Bridge Port HiperSockets channel, or address
+  notifications are aborted.
+VLAN=numeric-vlan-id - VLAN ID on which the event occurred. Not included
+  if no VLAN is involved in the event.
+MAC=xx:xx:xx:xx:xx:xx - MAC address of the host that is being registered
+  or deregistered from the HiperSockets channel. Not reported if the
+  event reports the creation or destruction of a VLAN.
+NTOK_BUSID=x.y.zzzz - device bus ID (CSSID, SSID and device number).
+NTOK_IID=xx - device IID.
+NTOK_CHPID=xx - device CHPID.
+NTOK_CHID=xxxx - device channel ID.
+Note that the NTOK_* attributes refer to devices other than  the one
+connected to the system on which the OS is running.
diff --git a/Documentation/scsi/00-INDEX b/Documentation/scsi/00-INDEX
index 9b0787f965e9..2044be565d93 100644
--- a/Documentation/scsi/00-INDEX
+++ b/Documentation/scsi/00-INDEX
@@ -42,8 +42,6 @@ aic79xx.txt
        - Adaptec Ultra320 SCSI host adapters
 aic7xxx.txt
        - info on driver for Adaptec controllers
-aic7xxx_old.txt
-        - info on driver for Adaptec controllers, old generation
 arcmsr_spec.txt
        - ARECA FIRMWARE SPEC (for IOP331 adapter)
 dc395x.txt
diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt
deleted file mode 100644
index ecfc474f36a8..000000000000
--- a/Documentation/scsi/aic7xxx_old.txt
+++ /dev/null
@@ -1,511 +0,0 @@
-                            AIC7xxx Driver for Linux
-Introduction
----------------------------
-The AIC7xxx SCSI driver adds support for Adaptec (http://www.adaptec.com)
-SCSI controllers and chipsets. Major portions of the driver and driver
-development are shared between both Linux and FreeBSD. Support for the
-AIC-7xxx chipsets have been in the default Linux kernel since approximately
-linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD
-2.1.0 or later.
-  Supported cards/chipsets
-  ----------------------------
-    Adaptec Cards
-    ----------------------------
-    AHA-274x
-    AHA-274xT               
-    AHA-2842
-    AHA-2910B               
-    AHA-2920C
-    AHA-2930
-    AHA-2930U
-    AHA-2930CU
-    AHA-2930U2
-    AHA-2940               
-    AHA-2940W              
-    AHA-2940U              
-    AHA-2940UW
-    AHA-2940UW-PRO
-    AHA-2940AU 
-    AHA-2940U2W
-    AHA-2940U2
-    AHA-2940U2B
-    AHA-2940U2BOEM
-    AHA-2944D              
-    AHA-2944WD
-    AHA-2944UD
-    AHA-2944UWD
-    AHA-2950U2
-    AHA-2950U2W
-    AHA-2950U2B
-    AHA-29160M
-    AHA-3940
-    AHA-3940U
-    AHA-3940W
-    AHA-3940UW
-    AHA-3940AUW
-    AHA-3940U2W
-    AHA-3950U2B
-    AHA-3950U2D
-    AHA-3960D
-    AHA-39160M
-    AHA-3985
-    AHA-3985U
-    AHA-3985W
-    AHA-3985UW
-    Motherboard Chipsets
-    ----------------------------
-    AIC-777x   
-    AIC-785x
-    AIC-786x
-    AIC-787x
-    AIC-788x
-    AIC-789x
-    AIC-3860
-    Bus Types
-    ----------------------------
-    W - Wide SCSI, SCSI-3, 16bit bus, 68pin connector, will also support
-        SCSI-1/SCSI-2 50pin devices, transfer rates up to 20MB/s.
-    U - Ultra SCSI, transfer rates up to 40MB/s.
-    U2- Ultra 2 SCSI, transfer rates up to 80MB/s.
-    D - Differential SCSI.
-    T - Twin Channel SCSI. Up to 14 SCSI devices.
-    AHA-274x - EISA SCSI controller
-    AHA-284x - VLB SCSI controller
-    AHA-29xx - PCI SCSI controller
-    AHA-394x - PCI controllers with two separate SCSI controllers on-board.
-    AHA-398x - PCI RAID controllers with three separate SCSI controllers
-               on-board.
-  Not Supported Devices
-  ------------------------------
-    Adaptec Cards
-    ----------------------------
-    AHA-2920 (Only the cards that use the Future Domain chipset are not
-              supported, any 2920 cards based on Adaptec AIC chipsets,
-              such as the 2920C, are supported)
-    AAA-13x Raid Adapters
-    AAA-113x Raid Port Card
-    Motherboard Chipsets
-    ----------------------------
-    AIC-7810
-    Bus Types
-    ----------------------------
-    R - Raid Port busses are not supported.
-    The hardware RAID devices sold by Adaptec are *NOT* supported by this
-    driver (and will people please stop emailing me about them, they are
-    a totally separate beast from the bare SCSI controllers and this driver
-    cannot be retrofitted in any sane manner to support the hardware RAID
-    features on those cards - Doug Ledford).
-    
-  People
-  ------------------------------
-    Justin T Gibbs  gibbs@plutotech.com
-      (BSD Driver Author)
-    Dan Eischen     deischen@iworks.InterWorks.org
-      (Original Linux Driver Co-maintainer)
-    Dean Gehnert    deang@teleport.com
-      (Original Linux FTP/patch maintainer)
-    Jess Johnson    jester@frenzy.com
-      (AIC7xxx FAQ author)
-    Doug Ledford    dledford@redhat.com
-      (Current Linux aic7xxx-5.x.x Driver/Patch/FTP maintainer)
-    
-    Special thanks go to John Aycock (aycock@cpsc.ucalgary.ca), the original
-    author of the driver. John has since retired from the project. Thanks
-    again for all his work!
-    
-  Mailing list
-  ------------------------------
-    There is a mailing list available for users who want to track development
-    and converse with other users and developers. This list is for both
-    FreeBSD and Linux support of the AIC7xxx chipsets.
-    To subscribe to the AIC7xxx mailing list send mail to the list server,
-    with "subscribe AIC7xxx" in the body (no Subject: required):
-        To: majordomo@FreeBSD.ORG
-        ---
-        subscribe AIC7xxx
-    To unsubscribe from the list, send mail to the list server with:
-        To: majordomo@FreeBSD.ORG
-        ---
-        unsubscribe AIC7xxx
-    Send regular messages and replies to: AIC7xxx@FreeBSD.ORG
-    
-  Boot Command line options
-  ------------------------------
-    "aic7xxx=no_reset" -  Eliminate the SCSI bus reset during startup.
-        Some SCSI devices need the initial reset that this option disables
-        in order to work.  If you have problems at bootup, please make sure
-        you aren't using this option.
-        
-    "aic7xxx=reverse_scan" - Certain PCI motherboards scan for devices at
-        bootup by scanning from the highest numbered PCI device to the
-        lowest numbered PCI device, others do just the opposite and scan
-        from lowest to highest numbered PCI device.  There is no reliable
-        way to autodetect this ordering.  So, we default to the most common
-        order, which is lowest to highest.  Then, in case your motherboard
-        scans from highest to lowest, we have this option.  If your BIOS
-        finds the drives on controller A before controller B but the linux
-        kernel finds your drives on controller B before A, then you should
-        use this option.
-        
-    "aic7xxx=extended" - Force the driver to detect extended drive translation
-        on your controller.  This helps those people who have cards without
-        a SEEPROM make sure that linux and all other operating systems think
-        the same way about your hard drives.
-    "aic7xxx=scbram" - Some cards have external SCB RAM that can be used to
-        give the card more hardware SCB slots.  This allows the driver to use
-        that SCB RAM.  Without this option, the driver won't touch the SCB
-        RAM because it is known to cause problems on a few cards out there
-        (such as 3985 class cards).
-        
-    "aic7xxx=irq_trigger:x" - Replace x with either 0 or 1 to force the kernel
-        to use the correct IRQ type for your card.  This only applies to EISA
-        based controllers.  On these controllers, 0 is for Edge triggered
-        interrupts, and 1 is for Level triggered interrupts.  If you aren't
-        sure or don't know which IRQ trigger type your EISA card uses, then
-        let the kernel autodetect the trigger type.
-        
-    "aic7xxx=verbose" - This option can be used in one of two ways.  If you
-        simply specify aic7xxx=verbose, then the kernel will automatically
-        pick the default set of verbose messages for you to see.
-        Alternatively, you can specify the command as 
-        "aic7xxx=verbose:0xXXXX" where the X entries are replaced with
-        hexadecimal digits.  This option is a bit field type option.  For
-        a full listing of the available options, search for the 
-        #define VERBOSE_xxxxxx lines in the aic7xxx.c file.  If you want
-        verbose messages, then it is recommended that you simply use the
-        aic7xxx=verbose variant of this command.
-        
-    "aic7xxx=pci_parity:x" - This option controls whether or not the driver
-        enables PCI parity error checking on the PCI bus.  By default, this
-        checking is disabled.  To enable the checks, simply specify pci_parity
-        with no value afterwords.  To reverse the parity from even to odd,
-        supply any number other than 0 or 255.  In short:
-          pci_parity     - Even parity checking (even is the normal PCI parity)
-          pci_parity:x   - Where x > 0, Odd parity checking
-          pci_parity:0   - No check (default)
-        NOTE: In order to get Even PCI parity checking, you must use the
-        version of the option that does not include the : and a number at
-        the end (unless you want to enter exactly 2^32 - 1 as the number).
-        
-    "aic7xxx=no_probe" - This option will disable the probing for any VLB
-        based 2842 controllers and any EISA based controllers.  This is
-        needed on certain newer motherboards where the normal EISA I/O ranges
-        have been claimed by other PCI devices.  Probing on those machines
-        will often result in the machine crashing or spontaneously rebooting
-        during startup.  Examples of machines that need this are the
-        Dell PowerEdge 6300 machines.
-    "aic7xxx=seltime:2" - This option controls how long the card waits
-        during a device selection sequence for the device to respond.
-        The original SCSI spec says that this "should be" 256ms.  This
-        is generally not required with modern devices.  However, some
-        very old SCSI I devices need the full 256ms.  Most modern devices
-        can run fine with only 64ms.  The default for this option is
-        64ms.  If you need to change this option, then use the following
-        table to set the proper value in the example above:
-          0  -  256ms
-          1  -  128ms
-          2  -   64ms
-          3  -   32ms
-        
-    "aic7xxx=panic_on_abort" - This option is for debugging and will cause
-        the driver to panic the linux kernel and freeze the system the first
-        time the drivers abort or reset routines are called.  This is most
-        helpful when some problem causes infinite reset loops that scroll too
-        fast to see.  By using this option, you can write down what the errors
-        actually are and send that information to me so it can be fixed.
-        
-    "aic7xxx=dump_card" - This option will print out the *entire* set of
-        configuration registers on the card during the init sequence.  This
-        is a debugging aid used to see exactly what state the card is in
-        when we finally finish our initialization routines.  If you don't
-        have documentation on the chipsets, this will do you absolutely
-        no good unless you are simply trying to write all the information
-        down in order to send it to me.
-        
-    "aic7xxx=dump_sequencer" - This is the same as the above options except
-        that instead of dumping the register contents on the card, this
-        option dumps the contents of the sequencer program RAM.  This gives
-        the ability to verify that the instructions downloaded to the
-        card's sequencer are indeed what they are supposed to be.  Again,
-        unless you have documentation to tell you how to interpret these
-        numbers, then it is totally useless.
-        
-    "aic7xxx=override_term:0xffffffff" - This option is used to force the
-        termination on your SCSI controllers to a particular setting.  This
-        is a bit mask variable that applies for up to 8 aic7xxx SCSI channels.
-        Each channel gets 4 bits, divided as follows:
-        bit   3   2   1   0
-              |   |   |   Enable/Disable Single Ended Low Byte Termination
-              |   |   En/Disable Single Ended High Byte Termination
-              |   En/Disable Low Byte LVD Termination
-              En/Disable High Byte LVD Termination
-        The upper 2 bits that deal with LVD termination only apply to Ultra2
-        controllers.  Furthermore, due to the current Ultra2 controller
-        designs, these bits are tied together such that setting either bit
-        enables both low and high byte LVD termination.  It is not possible
-        to only set high or low byte LVD termination in this manner.  This is
-        an artifact of the BIOS definition on Ultra2 controllers.  For other
-        controllers, the only important bits are the two lowest bits.  Setting
-        the higher bits on non-Ultra2 controllers has no effect.  A few
-        examples of how to use this option:
-        Enable low and high byte termination on a non-ultra2 controller that
-        is the first aic7xxx controller (the correct bits are 0011), 
-        aic7xxx=override_term:0x3
-        Enable all termination on the third aic7xxx controller, high byte
-        termination on the second aic7xxx controller, and low and high byte
-        SE termination on the first aic7xxx controller 
-        (bits are 1111 0010 0011), 
-        aic7xxx=override_term:0xf23
-        
-        No attempt has been made to make this option non-cryptic.  It really
-        shouldn't be used except in dire circumstances, and if that happens,
-        I'm probably going to be telling you what to set this to anyway :)
-    "aic7xxx=stpwlev:0xffffffff" - This option is used to control the STPWLEV
-        bit in the DEVCONFIG PCI register.  Currently, this is one of the
-        very few registers that we have absolutely *no* way of detecting
-        what the variable should be.  It depends entirely on how the chipset
-        and external terminators were coupled by the card/motherboard maker.
-        Further, a chip reset (at power up) always sets this bit to 0.  If
-        there is no BIOS to run on the chipset/card (such as with a 2910C
-        or a motherboard controller with the BIOS totally disabled) then
-        the variable may not get set properly.  Of course, if the proper
-        setting was 0, then that's what it would be after the reset, but if
-        the proper setting is actually 1.....you get the picture.  Now, since
-        we can't detect this at all, I've added this option to force the
-        setting.  If you have a BIOS on your controller then you should never
-        need to use this option.  However, if you are having lots of SCSI
-        reset problems and can't seem to get them knocked out, this may help.
-        Here's a test to know for certain if you need this option.  Make
-        a boot floppy that you can use to boot your computer up and that
-        will detect the aic7xxx controller.  Next, power down your computer.
-        While it's down, unplug all SCSI cables from your Adaptec SCSI
-        controller.  Boot the system back up to the Adaptec EZ-SCSI BIOS
-        and then make sure that termination is enabled on your adapter (if
-        you have an Adaptec BIOS of course).  Next, boot up the floppy you
-        made and wait for it to detect the aic7xxx controller.  If the kernel
-        finds the controller fine, says scsi : x hosts and then tries to
-        detect your devices like normal, up to the point where it fails to
-        mount your root file system and panics, then you're fine.  If, on
-        the other hand, the system goes into an infinite reset loop, then
-        you need to use this option and/or the previous option to force the
-        proper termination settings on your controller.   If this happens,
-        then you next need to figure out what your settings should be.
-        To find the correct settings, power your machine back down, connect
-        back up the SCSI cables, and boot back into your machine like normal.
-        However, boot with the aic7xxx=verbose:0x39 option.  Record the
-        initial DEVCONFIG values for each of your aic7xxx controllers as
-        they are listed, and also record what the machine is detecting as
-        the proper termination on your controllers.  NOTE: the order in
-        which the initial DEVCONFIG values are printed out is not guaranteed
-        to be the same order as the SCSI controllers are registered.  The
-        above option and this option both work on the order of the SCSI
-        controllers as they are registered, so make sure you match the right
-        DEVCONFIG values with the right controllers if you have more than
-        one aic7xxx controller.
-        Once you have the detected termination settings and the initial
-        DEVCONFIG values for each controller, then figure out what the
-        termination on each of the controllers *should* be.  Hopefully, that
-        part is correct, but it could possibly be wrong if there is
-        bogus cable detection logic on your controller or something similar.
-        If all the controllers have the correct termination settings, then
-        don't set the aic7xxx=override_term variable at all, leave it alone.
-        Next, on any controllers that go into an infinite reset loop when
-        you unplug all the SCSI cables, get the starting DEVCONFIG value.
-        If the initial DEVCONFIG value is divisible by 2, then the correct
-        setting for that controller is 0.  If it's an odd number, then
-        the correct setting for that controller is 1.  For any other
-        controllers that didn't have an infinite reset problem, then reverse
-        the above options.  If DEVCONFIG was even, then the correct setting
-        is 1, if not then the correct setting is 0.
-        Now that you know what the correct setting was for each controller,
-        we need to encode that into the aic7xxx=stpwlev:0x... variable.
-        This variable is a bit field encoded variable.  Bit 0 is for the first
-        aic7xxx controller, bit 1 for the next, etc.  Put all these bits
-        together and you get a number.  For example, if the third aic7xxx
-        needed a 1, but the second and first both needed a 0, then the bits
-        would be 100 in binary.  This then translates to 0x04.  You would
-        therefore set aic7xxx=stpwlev:0x04.  This is fairly standard binary
-        to hexadecimal conversions here.  If you aren't up to speed on the
-        binary->hex conversion then send an email to the aic7xxx mailing
-        list and someone can help you out.
-    "aic7xxx=tag_info:{{8,8..},{8,8..},..}" - This option is used to disable
-        or enable Tagged Command Queueing (TCQ) on specific devices.  As of
-        driver version 5.1.11, TCQ is now either on or off by default
-        according to the setting you choose during the make config process.
-        In order to en/disable TCQ for certain devices at boot time, a user
-        may use this boot param.  The driver will then parse this message out
-        and en/disable the specific device entries that are present based upon
-        the value given.  The param line is parsed in the following manner:
-          { - first instance indicates the start of this parameter values
-              second instance is the start of entries for a particular
-              device entry
-          } - end the entries for a particular host adapter, or end the entire
-              set of parameter entries
-          , - move to next entry.  Inside of a set of device entries, this
-              moves us to the next device on the list.  Outside of device
-              entries, this moves us to the next host adapter
-          . - Same effect as , but is safe to use with insmod.
-          x - the number to enter into the array at this position.  
-              0 = Enable tagged queueing on this device and use the default
-                  queue depth
-              1-254 = Enable tagged queueing on this device and use this
-                      number as the queue depth
-              255 = Disable tagged queueing on this device.
-              Note: anything above 32 for an actual queue depth is wasteful
-                    and not recommended.
-        A few examples of how this can be used:
-        tag_info:{{8,12,,0,,255,4}}
-          This line will only effect the first aic7xxx card registered.  It
-          will set scsi id 0 to a queue depth of 8, id 1 to 12, leave id 2
-          at the default, set id 3 to tagged queueing enabled and use the
-          default queue depth, id 4 default, id 5 disabled, and id 6 to 4.
-          Any not specified entries stay at the default value, repeated
-          commas with no value specified will simply increment to the next id
-          without changing anything for the missing values.
-        tag_info:{,,,{,,,255}}
-          First, second, and third adapters at default values.  Fourth
-          adapter, id 3 is disabled.  Notice that leading commas simply
-          increment what the first number effects, and there are no need
-          for trailing commas.  When you close out an adapter, or the
-          entire entry, anything not explicitly set stays at the default
-          value.
-        A final note on this option.  The scanner I used for this isn't
-        perfect or highly robust.  If you mess the line up, the worst that
-        should happen is that the line will get ignored.  If you don't
-        close out the entire entry with the final bracket, then any other
-        aic7xxx options after this will get ignored.  So, in general, be
-        sure of what you are entering, and after you have it right, just
-        add it to the lilo.conf file so there won't be any mistakes.  As
-        a means of checking this parser, the entire tag_info array for
-        each card is now printed out in the /proc/scsi/aic7xxx/x file.  You
-        can use that to verify that your options were parsed correctly. 
-        
-    Boot command line options may be combined to form the proper set of options
-    a user might need.  For example, the following is valid:
-    
-    aic7xxx=verbose,extended,irq_trigger:1
-    
-    The only requirement is that individual options be separated by a comma or
-    a period on the command line.
-        
-  Module Loading command options
-  ------------------------------
-    When loading the aic7xxx driver as a module, the exact same options are
-    available to the user.  However, the syntax to specify the options changes
-    slightly.  For insmod, you need to wrap the aic7xxx= argument in quotes
-    and replace all ',' with '.'.  So, for example, a valid insmod line
-    would be:
-    insmod aic7xxx aic7xxx='verbose.irq_trigger:1.extended'
-    This line should result in the *exact* same behaviour as if you typed
-    it in at the lilo prompt and the driver was compiled into the kernel
-    instead of being a module.  The reason for the single quote is so that
-    the shell won't try to interpret anything in the line, such as {. 
-    Insmod assumes any options starting with a letter instead of a number
-    is a character string (which is what we want) and by switching all of
-    the commas to periods, insmod won't interpret this as more than one
-    string and write junk into our binary image.  I consider it a bug in
-    the insmod program that even if you wrap your string in quotes (quotes
-    that pass the shell mind you and that insmod sees) it still treats
-    a comma inside of those quotes as starting a new variable, resulting
-    in memory scribbles if you don't switch the commas to periods.
-  Kernel Compile options
-  ------------------------------
-    The various kernel compile time options for this driver are now fairly
-    well documented in the file drivers/scsi/Kconfig.  In order to
-    see this documentation, you need to use one of the advanced configuration
-    programs (menuconfig and xconfig).  If you are using the "make menuconfig"
-    method of configuring your kernel, then you would simply highlight the
-    option in question and hit the ? key.  If you are using the "make xconfig"
-    method of configuring your kernel, then simply click on the help button
-    next to the option you have questions about.  The help information from
-    the Configure.help file will then get automatically displayed.
-  /proc support
-  ------------------------------
-    The /proc support for the AIC7xxx can be found in the /proc/scsi/aic7xxx/
-    directory. That directory contains a file for each SCSI controller in
-    the system. Each file presents the current configuration and transfer
-    statistics (enabled with #define in aic7xxx.c) for each controller.
-    Thanks to Michael Neuffer for his upper-level SCSI help, and
-    Matthew Jacob for statistics support.
-  Debugging the driver
-  ------------------------------
-    Should you have problems with this driver, and would like some help in
-    getting them solved, there are a couple debugging items built into
-    the driver to facilitate getting the needed information from the system.
-    In general, I need a complete description of the problem, with as many
-    logs as possible concerning what happens.  To help with this, there is
-    a command option aic7xxx=panic_on_abort.  This option, when set, forces
-    the driver to panic the kernel on the first SCSI abort issued by the
-    mid level SCSI code.  If your system is going to reset loops and you
-    can't read the screen, then this is what you need.  Not only will it
-    stop the system, but it also prints out a large amount of state
-    information in the process.  Second, if you specify the option
-    "aic7xxx=verbose:0x1ffff", the system will print out *SOOOO* much
-    information as it runs that you won't be able to see anything.
-    However, this can actually be very useful if your machine simply
-    locks up when trying to boot, since it will pin-point what was last
-    happening (in regards to the aic7xxx driver) immediately prior to
-    the lockup.  This is really only useful if your machine simply can
-    not boot up successfully.  If you can get your machine to run, then
-    this will produce far too much information.
-  FTP sites
-  ------------------------------
-    ftp://ftp.redhat.com/pub/aic/
-      - Out of date.  I used to keep stuff here, but too many people
-        complained about having a hard time getting into Red Hat's ftp
-        server.  So use the web site below instead.
-    ftp://ftp.pcnet.com/users/eischen/Linux/
-      - Dan Eischen's driver distribution area
-    ftp://ekf2.vsb.cz/pub/linux/kernel/aic7xxx/ftp.teleport.com/
-      - European Linux mirror of Teleport site
-  Web sites
-  ------------------------------
-    http://people.redhat.com/dledford/
-      - My web site, also the primary aic7xxx site with several related
-        pages.
-Dean W. Gehnert
-deang@teleport.com
-$Revision: 3.0 $
-Modified by Doug Ledford 1998-2000
diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt
index 6ff16b620d84..a0c85110a07e 100644
--- a/Documentation/scsi/scsi_eh.txt
+++ b/Documentation/scsi/scsi_eh.txt
@@ -42,20 +42,14 @@ discussion.
 Once LLDD gets hold of a scmd, either the LLDD will complete the
 command by calling scsi_done callback passed from midlayer when
-invoking hostt->queuecommand() or SCSI midlayer will time it out.
+invoking hostt->queuecommand() or the block layer will time it out.
 [1-2-1] Completing a scmd w/ scsi_done
 For all non-EH commands, scsi_done() is the completion callback.  It
-does the following.
+just calls blk_complete_request() to delete the block layer timer and
+raise SCSI_SOFTIRQ
- 1. Delete timeout timer.  If it fails, it means that timeout timer
-    has expired and is going to finish the command.  Just return.
- 2. Link scmd to per-cpu scsi_done_q using scmd->en_entry
- 3. Raise SCSI_SOFTIRQ
 SCSI_SOFTIRQ handler scsi_softirq calls scsi_decide_disposition() to
 determine what to do with the command.  scsi_decide_disposition()
@@ -64,10 +58,12 @@ with the command.
 - SUCCESS
        scsi_finish_command() is invoked for the command.  The
-        function does some maintenance choirs and notify completion by
+        function does some maintenance chores and then calls
-        calling scmd->done() callback, which, for fs requests, would
+        scsi_io_completion() to finish the I/O.
-        be HLD completion callback - sd:sd_rw_intr, sr:rw_intr,
+        scsi_io_completion() then notifies the block layer on
-        st:st_intr.
+        the completed request by calling blk_end_request and
+        friends or figures out what to do with the remainder
+        of the data in case of an error.
 - NEEDS_RETRY
 - ADD_TO_MLQUEUE
@@ -86,33 +82,45 @@ function
 1. invokes optional hostt->eh_timed_out() callback.  Return value can
    be one of
-    - EH_HANDLED
+    - BLK_EH_HANDLED
-        This indicates that eh_timed_out() dealt with the timeout.  The
+        This indicates that eh_timed_out() dealt with the timeout.
-        scmd is passed to __scsi_done() and thus linked into per-cpu
+        The command is passed back to the block layer and completed
-        scsi_done_q.  Normal command completion described in [1-2-1]
+        via __blk_complete_requests().
-        follows.
+        *NOTE* After returning BLK_EH_HANDLED the SCSI layer is
+        assumed to be finished with the command, and no other
+        functions from the SCSI layer will be called. So this
+        should typically only be returned if the eh_timed_out()
+        handler raced with normal completion.
-    - EH_RESET_TIMER
+    - BLK_EH_RESET_TIMER
        This indicates that more time is required to finish the
        command.  Timer is restarted.  This action is counted as a
        retry and only allowed scmd->allowed + 1(!) times.  Once the
-        limit is reached, action for EH_NOT_HANDLED is taken instead.
+        limit is reached, action for BLK_EH_NOT_HANDLED is taken instead.
-        *NOTE* This action is racy as the LLDD could finish the scmd
+    - BLK_EH_NOT_HANDLED
-        after the timeout has expired but before it's added back.  In
+        eh_timed_out() callback did not handle the command.
-        such cases, scsi_done() would think that timeout has occurred
-        and return without doing anything.  We lose completion and the
-        command will time out again.
-    - EH_NOT_HANDLED
-        This is the same as when eh_timed_out() callback doesn't exist.
        Step #2 is taken.
+ 2. If the host supports asynchronous completion (as indicated by the
+    no_async_abort setting in the host template) scsi_abort_command()
+    is invoked to schedule an asynchrous abort. If that fails
+    Step #3 is taken.
 2. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the
    command.  See [1-3] for more information.
+[1-3] Asynchronous command aborts
+ After a timeout occurs a command abort is scheduled from
+ scsi_abort_command(). If the abort is successful the command
+ will either be retried (if the number of retries is not exhausted)
+ or terminated with DID_TIME_OUT.
+ Otherwise scsi_eh_scmd_add() is invoked for the command.
+ See [1-4] for more information.
-[1-3] How EH takes over
+[1-4] How EH takes over
 scmds enter EH via scsi_eh_scmd_add(), which does the following.
@@ -320,7 +328,8 @@ scmd->allowed.
    <<scsi_eh_abort_cmds>>
-        This action is taken for each timed out command.
+        This action is taken for each timed out command when
+        no_async_abort is enabled in the host template.
        hostt->eh_abort_handler() is invoked for each scmd.  The
        handler returns SUCCESS if it has succeeded to make LLDD and
        all related hardware forget about the scmd.
diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt
index 2b06aba4fa0f..d6a9bdeee7f2 100644
--- a/Documentation/scsi/scsi_mid_low_api.txt
+++ b/Documentation/scsi/scsi_mid_low_api.txt
@@ -882,8 +882,11 @@ Details:
 *
 *      Calling context: kernel thread
 *
- *      Notes: Invoked from scsi_eh thread. No other commands will be
+ *      Notes: If 'no_async_abort' is defined this callback
- *      queued on current host during eh.
+ *      will be invoked from scsi_eh thread. No other commands
+ *      will then be queued on current host during eh.
+ *      Otherwise it will be called whenever scsi_times_out()
+ *      is called due to a command timeout.
 *
 *      Optionally defined in: LLD
 **/
@@ -1257,6 +1260,8 @@ of interest:
                   address space
    use_clustering - 1=>SCSI commands in mid level's queue can be merged,
                     0=>disallow SCSI command merging
+    no_async_abort - 1=>Asynchronous aborts are not supported
+                     0=>Timed-out commands will be aborted asynchronously
    hostt        - pointer to driver's struct scsi_host_template from which
                   this struct Scsi_Host instance was spawned
    hostt->proc_name  - name of LLD. This is the driver name that sysfs uses
diff --git a/Documentation/scsi/scsi_transport_srp/Makefile b/Documentation/scsi/scsi_transport_srp/Makefile
new file mode 100644
index 000000000000..5f6b567e955c
--- /dev/null
+++ b/Documentation/scsi/scsi_transport_srp/Makefile
@@ -0,0 +1,7 @@
+all: rport_state_diagram.svg rport_state_diagram.png
+rport_state_diagram.svg: rport_state_diagram.dot
+        dot -Tsvg -o $@ $<
+rport_state_diagram.png: rport_state_diagram.dot
+        dot -Tpng -o $@ $<
diff --git a/Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot b/Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot
new file mode 100644
index 000000000000..75d610d6411a
--- /dev/null
+++ b/Documentation/scsi/scsi_transport_srp/rport_state_diagram.dot
@@ -0,0 +1,26 @@
+digraph srp_initiator {
+        node [shape = doublecircle]; running lost;
+        node [shape = circle];
+        {
+          rank = min;
+          running_rta   [ label = "running;\nreconnect\ntimer\nactive" ];
+        };
+        running         [ label = "running;\nreconnect\ntimer\nstopped" ];
+        blocked;
+        failfast        [ label = "fail I/O\nfast" ];
+        lost;
+        running -> running_rta          [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nsrp_start_tl_fail_timers()" ];
+        running_rta -> running          [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nreconnecting succeeded" ];
+        running -> blocked              [ label = "fast_io_fail_tmo >= 0 or\ndev_loss_tmo >= 0;\nsrp_start_tl_fail_timers()" ];
+        running -> failfast             [ label = "fast_io_fail_tmo = off and\ndev_loss_tmo = off;\nreconnecting failed\n" ];
+        blocked -> failfast             [ label = "fast_io_fail_tmo\nexpired or\nreconnecting\nfailed" ];
+        blocked -> lost                 [ label = "dev_loss_tmo\nexpired or\nsrp_stop_rport_timers()" ];
+        failfast -> lost                [ label = "dev_loss_tmo\nexpired or\nsrp_stop_rport_timers()" ];
+        blocked -> running              [ label = "reconnecting\nsucceeded" ];
+        failfast -> failfast            [ label = "reconnecting\nfailed" ];
+        failfast -> running             [ label = "reconnecting\nsucceeded" ];
+        running -> lost                 [ label = "srp_stop_rport_timers()" ];
+        running_rta -> lost             [ label = "srp_stop_rport_timers()" ];
+}
diff --git a/Documentation/security/IMA-templates.txt b/Documentation/security/IMA-templates.txt
index a777e5f1df5b..a4e102dddfea 100644
--- a/Documentation/security/IMA-templates.txt
+++ b/Documentation/security/IMA-templates.txt
@@ -67,12 +67,14 @@ descriptors by adding their identifier to the format string
 - 'd-ng': the digest of the event, calculated with an arbitrary hash
           algorithm (field format: [<hash algo>:]digest, where the digest
           prefix is shown only if the hash algorithm is not SHA1 or MD5);
- - 'n-ng': the name of the event, without size limitations.
+ - 'n-ng': the name of the event, without size limitations;
+ - 'sig': the file signature.
 Below, there is the list of defined template descriptors:
 - "ima": its format is 'd|n';
- - "ima-ng" (default): its format is 'd-ng|n-ng'.
+ - "ima-ng" (default): its format is 'd-ng|n-ng';
+ - "ima-sig": its format is 'd-ng|n-ng|sig'.
diff --git a/Documentation/sound/alsa/soc/overview.txt b/Documentation/sound/alsa/soc/overview.txt
index 138ac88c1461..ff88f52eec98 100644
--- a/Documentation/sound/alsa/soc/overview.txt
+++ b/Documentation/sound/alsa/soc/overview.txt
@@ -49,18 +49,23 @@ features :-
  * Machine specific controls: Allow machines to add controls to the sound card
    (e.g. volume control for speaker amplifier).
-To achieve all this, ASoC basically splits an embedded audio system into 3
+To achieve all this, ASoC basically splits an embedded audio system into
-components :-
+multiple re-usable component drivers :-
-  * Codec driver: The codec driver is platform independent and contains audio
+  * Codec class drivers: The codec class driver is platform independent and
-    controls, audio interface capabilities, codec DAPM definition and codec IO
+    contains audio controls, audio interface capabilities, codec DAPM
-    functions.
+    definition and codec IO functions. This class extends to BT, FM and MODEM
+    ICs if required. Codec class drivers should be generic code that can run
+    on any architecture and machine.
-  * Platform driver: The platform driver contains the audio DMA engine and audio
+  * Platform class drivers: The platform class driver includes the audio DMA
-    interface drivers (e.g. I2S, AC97, PCM) for that platform.
+    engine driver, digital audio interface (DAI) drivers (e.g. I2S, AC97, PCM)
+    and any audio DSP drivers for that platform.
-  * Machine driver: The machine driver handles any machine specific controls and
+  * Machine class driver: The machine driver class acts as the glue that
-    audio events (e.g. turning on an amp at start of playback).
+    decribes and binds the other component drivers together to form an ALSA
+    "sound card device". It handles any machine specific controls and
+    machine level audio events (e.g. turning on an amp at start of playback).
 Documentation
@@ -84,3 +89,7 @@ machine.txt: Machine driver internals.
 pop_clicks.txt: How to minimise audio artifacts.
 clocking.txt: ASoC clocking for best power performance.
+jack.txt: ASoC jack detection.
+DPCM.txt: Dynamic PCM - Describes DPCM with DSP examples.
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index f21edb983413..f72e0d1e0da8 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -34,7 +34,7 @@ SPI slave functions are usually not interoperable between vendors
  - It may also be used to stream data in either direction (half duplex),
    or both of them at the same time (full duplex).
-  - Some devices may use eight bit words.  Others may different word
+  - Some devices may use eight bit words.  Others may use different word
    lengths, such as streams of 12-bit or 20-bit digital samples.
  - Words are usually sent with their most significant bit (MSB) first,
@@ -121,7 +121,7 @@ active.  So the master must set the clock to inactive before selecting
 a slave, and the slave can tell the chosen polarity by sampling the
 clock level when its select line goes active.  That's why many devices
 support for example both modes 0 and 3:  they don't care about polarity,
-and alway clock data in/out on rising clock edges.
+and always clock data in/out on rising clock edges.
 How do these driver programming interfaces work?
@@ -139,7 +139,7 @@ a command and then reading its response.
 There are two types of SPI driver, here called:
-  Controller drivers ... controllers may be built in to System-On-Chip
+  Controller drivers ... controllers may be built into System-On-Chip
        processors, and often support both Master and Slave roles.
        These drivers touch hardware registers and may use DMA.
        Or they can be PIO bitbangers, needing just GPIO pins.
@@ -548,7 +548,7 @@ SPI MASTER METHODS
    DEPRECATED METHODS
    master->transfer(struct spi_device *spi, struct spi_message *message)
-        This must not sleep. Its responsibility is arrange that the
+        This must not sleep. Its responsibility is to arrange that the
        transfer happens and its complete() callback is issued. The two
        will normally happen later, after other transfers complete, and
        if the controller is idle it will need to be kickstarted. This
diff --git a/Documentation/static-keys.txt b/Documentation/static-keys.txt
index 9f5263d3152c..c4407a41b0fc 100644
--- a/Documentation/static-keys.txt
+++ b/Documentation/static-keys.txt
@@ -116,7 +116,7 @@ The branch(es) can then be switched via:
        static_key_slow_dec(&key);
 Thus, 'static_key_slow_inc()' means 'make the branch true', and
-'static_key_slow_dec()' means 'make the the branch false' with appropriate
+'static_key_slow_dec()' means 'make the branch false' with appropriate
 reference counting. For example, if the key is initialized true, a
 static_key_slow_dec(), will switch the branch to false. And a subsequent
 static_key_slow_inc(), will change the branch back to true. Likewise, if the
@@ -236,7 +236,7 @@ label case adds:
 If we then include the padding bytes, the jump label code saves, 16 total bytes
 of instruction memory for this small function. In this case the non-jump label
-function is 80 bytes long. Thus, we have have saved 20% of the instruction
+function is 80 bytes long. Thus, we have saved 20% of the instruction
 footprint. We can in fact improve this even further, since the 5-byte no-op
 really can be a 2-byte no-op since we can reach the branch with a 2-byte jmp.
 However, we have not yet implemented optimal no-op sizes (they are currently
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 6d486404200e..e55124e7c40c 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -33,6 +33,11 @@ show up in /proc/sys/kernel:
 - domainname
 - hostname
 - hotplug
+- hung_task_panic
+- hung_task_check_count
+- hung_task_timeout_secs
+- hung_task_warnings
+- kexec_load_disabled
 - kptr_restrict
 - kstack_depth_to_print       [ X86 only ]
 - l2cr                        [ PPC only ]
@@ -287,6 +292,56 @@ Default value is "/sbin/hotplug".
 ==============================================================
+hung_task_panic:
+Controls the kernel's behavior when a hung task is detected.
+This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+0: continue operation. This is the default behavior.
+1: panic immediately.
+==============================================================
+hung_task_check_count:
+The upper bound on the number of tasks that are checked.
+This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+==============================================================
+hung_task_timeout_secs:
+Check interval. When a task in D state did not get scheduled
+for more than this value report a warning.
+This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+0: means infinite timeout - no checking done.
+==============================================================
+hung_task_warning:
+The maximum number of warnings to report. During a check interval
+When this value is reached, no more the warnings will be reported.
+This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
+-1: report an infinite number of warnings.
+==============================================================
+kexec_load_disabled:
+A toggle indicating if the kexec_load syscall has been disabled. This
+value defaults to 0 (false: kexec_load enabled), but can be set to 1
+(true: kexec_load disabled). Once true, kexec can no longer be used, and
+the toggle cannot be set back to false. This allows a kexec image to be
+loaded before disabling the syscall, allowing a system to set up (and
+later use) an image without it being altered. Generally used together
+with the "modules_disabled" sysctl.
+==============================================================
 kptr_restrict:
 This toggle indicates whether restrictions are placed on
@@ -331,7 +386,7 @@ A toggle value indicating if modules are allowed to be loaded
 in an otherwise modular kernel.  This toggle defaults to off
 (0), but can be set true (1).  Once true, modules can be
 neither loaded nor unloaded, and the toggle cannot be set back
-to false.
+to false.  Generally used with the "kexec_load_disabled" toggle.
 ==============================================================
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 1fbd4eb7b64a..d614a9b6a280 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -47,6 +47,7 @@ Currently, these files are in /proc/sys/vm:
 - numa_zonelist_order
 - oom_dump_tasks
 - oom_kill_allocating_task
+- overcommit_kbytes
 - overcommit_memory
 - overcommit_ratio
 - page-cluster
@@ -574,6 +575,17 @@ The default value is 0.
 ==============================================================
+overcommit_kbytes:
+When overcommit_memory is set to 2, the committed address space is not
+permitted to exceed swap plus this amount of physical RAM. See below.
+Note: overcommit_kbytes is the counterpart of overcommit_ratio. Only one
+of them may be specified at a time. Setting one disables the other (which
+then appears as 0 when read).
+==============================================================
 overcommit_memory:
 This value contains a flag that enables memory overcommitment.
@@ -684,7 +696,9 @@ swappiness
 This control is used to define how aggressive the kernel will swap
 memory pages.  Higher values will increase agressiveness, lower values
-decrease the amount of swap.
+decrease the amount of swap.  A value of 0 instructs the kernel not to
+initiate swap until the amount of free and file-backed pages is less
+than the high water mark in a zone.
 The default value is 60.
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index 37732a220d33..c94435df2037 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -287,3 +287,210 @@ their old filters):
 prev_pid == 0
 # cat sched_wakeup/filter
 common_pid == 0
+6. Event triggers
+=================
+Trace events can be made to conditionally invoke trigger 'commands'
+which can take various forms and are described in detail below;
+examples would be enabling or disabling other trace events or invoking
+a stack trace whenever the trace event is hit.  Whenever a trace event
+with attached triggers is invoked, the set of trigger commands
+associated with that event is invoked.  Any given trigger can
+additionally have an event filter of the same form as described in
+section 5 (Event filtering) associated with it - the command will only
+be invoked if the event being invoked passes the associated filter.
+If no filter is associated with the trigger, it always passes.
+Triggers are added to and removed from a particular event by writing
+trigger expressions to the 'trigger' file for the given event.
+A given event can have any number of triggers associated with it,
+subject to any restrictions that individual commands may have in that
+regard.
+Event triggers are implemented on top of "soft" mode, which means that
+whenever a trace event has one or more triggers associated with it,
+the event is activated even if it isn't actually enabled, but is
+disabled in a "soft" mode.  That is, the tracepoint will be called,
+but just will not be traced, unless of course it's actually enabled.
+This scheme allows triggers to be invoked even for events that aren't
+enabled, and also allows the current event filter implementation to be
+used for conditionally invoking triggers.
+The syntax for event triggers is roughly based on the syntax for
+set_ftrace_filter 'ftrace filter commands' (see the 'Filter commands'
+section of Documentation/trace/ftrace.txt), but there are major
+differences and the implementation isn't currently tied to it in any
+way, so beware about making generalizations between the two.
+6.1 Expression syntax
+---------------------
+Triggers are added by echoing the command to the 'trigger' file:
+  # echo 'command[:count] [if filter]' > trigger
+Triggers are removed by echoing the same command but starting with '!'
+to the 'trigger' file:
+  # echo '!command[:count] [if filter]' > trigger
+The [if filter] part isn't used in matching commands when removing, so
+leaving that off in a '!' command will accomplish the same thing as
+having it in.
+The filter syntax is the same as that described in the 'Event
+filtering' section above.
+For ease of use, writing to the trigger file using '>' currently just
+adds or removes a single trigger and there's no explicit '>>' support
+('>' actually behaves like '>>') or truncation support to remove all
+triggers (you have to use '!' for each one added.)
+6.2 Supported trigger commands
+------------------------------
+The following commands are supported:
+- enable_event/disable_event
+  These commands can enable or disable another trace event whenever
+  the triggering event is hit.  When these commands are registered,
+  the other trace event is activated, but disabled in a "soft" mode.
+  That is, the tracepoint will be called, but just will not be traced.
+  The event tracepoint stays in this mode as long as there's a trigger
+  in effect that can trigger it.
+  For example, the following trigger causes kmalloc events to be
+  traced when a read system call is entered, and the :1 at the end
+  specifies that this enablement happens only once:
+  # echo 'enable_event:kmem:kmalloc:1' > \
+      /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+  The following trigger causes kmalloc events to stop being traced
+  when a read system call exits.  This disablement happens on every
+  read system call exit:
+  # echo 'disable_event:kmem:kmalloc' > \
+      /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+  The format is:
+      enable_event:<system>:<event>[:count]
+      disable_event:<system>:<event>[:count]
+  To remove the above commands:
+  # echo '!enable_event:kmem:kmalloc:1' > \
+      /sys/kernel/debug/tracing/events/syscalls/sys_enter_read/trigger
+  # echo '!disable_event:kmem:kmalloc' > \
+      /sys/kernel/debug/tracing/events/syscalls/sys_exit_read/trigger
+  Note that there can be any number of enable/disable_event triggers
+  per triggering event, but there can only be one trigger per
+  triggered event. e.g. sys_enter_read can have triggers enabling both
+  kmem:kmalloc and sched:sched_switch, but can't have two kmem:kmalloc
+  versions such as kmem:kmalloc and kmem:kmalloc:1 or 'kmem:kmalloc if
+  bytes_req == 256' and 'kmem:kmalloc if bytes_alloc == 256' (they
+  could be combined into a single filter on kmem:kmalloc though).
+- stacktrace
+  This command dumps a stacktrace in the trace buffer whenever the
+  triggering event occurs.
+  For example, the following trigger dumps a stacktrace every time the
+  kmalloc tracepoint is hit:
+  # echo 'stacktrace' > \
+        /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
+  The following trigger dumps a stacktrace the first 5 times a kmalloc
+  request happens with a size >= 64K
+  # echo 'stacktrace:5 if bytes_req >= 65536' > \
+        /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
+  The format is:
+      stacktrace[:count]
+  To remove the above commands:
+  # echo '!stacktrace' > \
+        /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
+  # echo '!stacktrace:5 if bytes_req >= 65536' > \
+        /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
+  The latter can also be removed more simply by the following (without
+  the filter):
+  # echo '!stacktrace:5' > \
+        /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
+  Note that there can be only one stacktrace trigger per triggering
+  event.
+- snapshot
+  This command causes a snapshot to be triggered whenever the
+  triggering event occurs.
+  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:
+  # echo 'snapshot if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  To only snapshot once:
+  # echo 'snapshot:1 if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  To remove the above commands:
+  # echo '!snapshot if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  # echo '!snapshot:1 if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  Note that there can be only one snapshot trigger per triggering
+  event.
+- traceon/traceoff
+  These commands turn tracing on and off when the specified events are
+  hit. The parameter determines how many times the tracing system is
+  turned on and off. If unspecified, there is no limit.
+  The following command turns tracing off the first time a block
+  request queue is unplugged with a depth > 1.  If you were tracing a
+  set of events or functions at the time, you could then examine the
+  trace buffer to see the sequence of events that led up to the
+  trigger event:
+  # echo 'traceoff:1 if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  To always disable tracing when nr_rq  > 1 :
+  # echo 'traceoff if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  To remove the above commands:
+  # echo '!traceoff:1 if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  # echo '!traceoff if nr_rq > 1' > \
+        /sys/kernel/debug/tracing/events/block/block_unplug/trigger
+  Note that there can be only one traceon or traceoff trigger per
+  triggering event.
diff --git a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
index 4a37c4759cd2..00e425faa2fd 100644
--- a/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
+++ b/Documentation/trace/postprocess/trace-vmscan-postprocess.pl
@@ -123,7 +123,7 @@ my $regex_writepage;
 # Static regex used. Specified like this for readability and for use with /o
 #                      (process_pid)     (cpus      )   ( time  )   (tpoint    ) (details)
-my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)';
+my $regex_traceevent = '\s*([a-zA-Z0-9-]*)\s*(\[[0-9]*\])(\s*[dX.][Nnp.][Hhs.][0-9a-fA-F.]*|)\s*([0-9.]*):\s*([a-zA-Z_]*):\s*(.*)';
 my $regex_statname = '[-0-9]*\s\((.*)\).*';
 my $regex_statppid = '[-0-9]*\s\(.*\)\s[A-Za-z]\s([0-9]*).*';
@@ -270,8 +270,8 @@ EVENT_PROCESS:
        while ($traceevent = <STDIN>) {
                if ($traceevent =~ /$regex_traceevent/o) {
                        $process_pid = $1;
-                        $timestamp = $3;
+                        $timestamp = $4;
-                        $tracepoint = $4;
+                        $tracepoint = $5;
                        $process_pid =~ /(.*)-([0-9]*)$/;
                        my $process = $1;
@@ -299,7 +299,7 @@ EVENT_PROCESS:
                        $perprocesspid{$process_pid}->{MM_VMSCAN_DIRECT_RECLAIM_BEGIN}++;
                        $perprocesspid{$process_pid}->{STATE_DIRECT_BEGIN} = $timestamp;
-                        $details = $5;
+                        $details = $6;
                        if ($details !~ /$regex_direct_begin/o) {
                                print "WARNING: Failed to parse mm_vmscan_direct_reclaim_begin as expected\n";
                                print "         $details\n";
@@ -322,7 +322,7 @@ EVENT_PROCESS:
                                $perprocesspid{$process_pid}->{HIGH_DIRECT_RECLAIM_LATENCY}[$index] = "$order-$latency";
                        }
                } elsif ($tracepoint eq "mm_vmscan_kswapd_wake") {
-                        $details = $5;
+                        $details = $6;
                        if ($details !~ /$regex_kswapd_wake/o) {
                                print "WARNING: Failed to parse mm_vmscan_kswapd_wake as expected\n";
                                print "         $details\n";
@@ -356,7 +356,7 @@ EVENT_PROCESS:
                } elsif ($tracepoint eq "mm_vmscan_wakeup_kswapd") {
                        $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD}++;
-                        $details = $5;
+                        $details = $6;
                        if ($details !~ /$regex_wakeup_kswapd/o) {
                                print "WARNING: Failed to parse mm_vmscan_wakeup_kswapd as expected\n";
                                print "         $details\n";
@@ -366,7 +366,7 @@ EVENT_PROCESS:
                        my $order = $3;
                        $perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]++;
                } elsif ($tracepoint eq "mm_vmscan_lru_isolate") {
-                        $details = $5;
+                        $details = $6;
                        if ($details !~ /$regex_lru_isolate/o) {
                                print "WARNING: Failed to parse mm_vmscan_lru_isolate as expected\n";
                                print "         $details\n";
@@ -387,7 +387,7 @@ EVENT_PROCESS:
                        }
                        $perprocesspid{$process_pid}->{HIGH_NR_CONTIG_DIRTY} += $nr_contig_dirty;
                } elsif ($tracepoint eq "mm_vmscan_lru_shrink_inactive") {
-                        $details = $5;
+                        $details = $6;
                        if ($details !~ /$regex_lru_shrink_inactive/o) {
                                print "WARNING: Failed to parse mm_vmscan_lru_shrink_inactive as expected\n";
                                print "         $details\n";
@@ -397,7 +397,7 @@ EVENT_PROCESS:
                        my $nr_reclaimed = $4;
                        $perprocesspid{$process_pid}->{HIGH_NR_RECLAIMED} += $nr_reclaimed;
                } elsif ($tracepoint eq "mm_vmscan_writepage") {
-                        $details = $5;
+                        $details = $6;
                        if ($details !~ /$regex_writepage/o) {
                                print "WARNING: Failed to parse mm_vmscan_writepage as expected\n";
                                print "         $details\n";
diff --git a/Documentation/trace/uprobetracer.txt b/Documentation/trace/uprobetracer.txt
index d9c3e682312c..f1cf9a34ad9d 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -19,18 +19,44 @@ user to calculate the offset of the probepoint in the object.
 Synopsis of uprobe_tracer
 -------------------------
-  p[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a uprobe
+  p[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a uprobe
-  r[:[GRP/]EVENT] PATH:SYMBOL[+offs] [FETCHARGS] : Set a return uprobe (uretprobe)
+  r[:[GRP/]EVENT] PATH:OFFSET [FETCHARGS] : Set a return uprobe (uretprobe)
-  -:[GRP/]EVENT                                  : Clear uprobe or uretprobe event
+  -:[GRP/]EVENT                           : Clear uprobe or uretprobe event
  GRP           : Group name. If omitted, "uprobes" is the default value.
  EVENT         : Event name. If omitted, the event name is generated based
-                  on SYMBOL+offs.
+                  on PATH+OFFSET.
  PATH          : Path to an executable or a library.
-  SYMBOL[+offs] : Symbol+offset where the probe is inserted.
+  OFFSET        : Offset where the probe is inserted.
  FETCHARGS     : Arguments. Each probe can have up to 128 args.
   %REG         : Fetch register REG
+   @ADDR        : Fetch memory at ADDR (ADDR should be in userspace)
+   @+OFFSET     : Fetch memory at OFFSET (OFFSET from same file as PATH)
+   $stackN      : Fetch Nth entry of stack (N >= 0)
+   $stack       : Fetch stack address.
+   $retval      : Fetch return value.(*)
+   +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address.(**)
+   NAME=FETCHARG     : Set NAME as the argument name of FETCHARG.
+   FETCHARG:TYPE     : Set TYPE as the type of FETCHARG. Currently, basic types
+                       (u8/u16/u32/u64/s8/s16/s32/s64), "string" and bitfield
+                       are supported.
+  (*) only for return probe.
+  (**) this is useful for fetching a field of data structures.
+Types
+-----
+Several types are supported for fetch-args. Uprobe tracer will access memory
+by given type. Prefix 's' and 'u' means those types are signed and unsigned
+respectively. Traced arguments are shown in decimal (signed) or hex (unsigned).
+String type is a special type, which fetches a "null-terminated" string from
+user space.
+Bitfield is another special type, which takes 3 parameters, bit-width, bit-
+offset, and container-size (usually 32). The syntax is;
+ b<bit-width>@<bit-offset>/<container-size>
 Event Profiling
 ---------------
diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt
index f866c72291bf..a445da098bc6 100644
--- a/Documentation/unaligned-memory-access.txt
+++ b/Documentation/unaligned-memory-access.txt
@@ -137,24 +137,34 @@ Code that causes unaligned access
 =================================
 With the above in mind, let's move onto a real life example of a function
-that can cause an unaligned memory access. The following function adapted
+that can cause an unaligned memory access. The following function taken
 from include/linux/etherdevice.h is an optimized routine to compare two
 ethernet MAC addresses for equality.
-unsigned int compare_ether_addr(const u8 *addr1, const u8 *addr2)
+bool ether_addr_equal(const u8 *addr1, const u8 *addr2)
 {
-        const u16 *a = (const u16 *) addr1;
+#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
-        const u16 *b = (const u16 *) addr2;
+        u32 fold = ((*(const u32 *)addr1) ^ (*(const u32 *)addr2)) |
+                   ((*(const u16 *)(addr1 + 4)) ^ (*(const u16 *)(addr2 + 4)));
+        return fold == 0;
+#else
+        const u16 *a = (const u16 *)addr1;
+        const u16 *b = (const u16 *)addr2;
        return ((a[0] ^ b[0]) | (a[1] ^ b[1]) | (a[2] ^ b[2])) != 0;
+#endif
 }
-In the above function, the reference to a[0] causes 2 bytes (16 bits) to
+In the above function, when the hardware has efficient unaligned access
-be read from memory starting at address addr1. Think about what would happen
+capability, there is no issue with this code.  But when the hardware isn't
-if addr1 was an odd address such as 0x10003. (Hint: it'd be an unaligned
+able to access memory on arbitrary boundaries, the reference to a[0] causes
-access.)
+2 bytes (16 bits) to be read from memory starting at address addr1.
+Think about what would happen if addr1 was an odd address such as 0x10003.
+(Hint: it'd be an unaligned access.)
 Despite the potential unaligned access problems with the above function, it
-is included in the kernel anyway but is understood to only work on
+is included in the kernel anyway but is understood to only work normally on
 16-bit-aligned addresses. It is up to the caller to ensure this alignment or
 not use this function at all. This alignment-unsafe function is still useful
 as it is a decent optimization for the cases when you can ensure alignment,
diff --git a/Documentation/usb/gadget_multi.txt b/Documentation/usb/gadget_multi.txt
index 80f4ef0eb75b..7d66a8636cb5 100644
--- a/Documentation/usb/gadget_multi.txt
+++ b/Documentation/usb/gadget_multi.txt
@@ -14,7 +14,7 @@ A CDC ECM (Ethernet) function may be turned on via a Kconfig option
 and RNDIS can be turned off.  If they are both enabled the gadget will
 have two configurations -- one with RNDIS and another with CDC ECM[3].
-Please not that if you use non-standard configuration (that is enable
+Please note that if you use non-standard configuration (that is enable
 CDC ECM) you may need to change vendor and/or product ID.
 * Host drivers
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index a30035dd4c26..6cd63a9010fb 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1838,6 +1838,7 @@ registers, find a list below:
  PPC   | KVM_REG_PPC_LPCR      | 64
  PPC   | KVM_REG_PPC_PPR       | 64
  PPC   | KVM_REG_PPC_ARCH_COMPAT 32
+  PPC   | KVM_REG_PPC_DABRX     | 32
  PPC   | KVM_REG_PPC_TM_GPR0   | 64
          ...
  PPC   | KVM_REG_PPC_TM_GPR31  | 64
@@ -2104,7 +2105,7 @@ Returns: 0 on success, -1 on error
 Allows setting an eventfd to directly trigger a guest interrupt.
 kvm_irqfd.fd specifies the file descriptor to use as the eventfd and
 kvm_irqfd.gsi specifies the irqchip pin toggled by this event.  When
-an event is tiggered on the eventfd, an interrupt is injected into
+an event is triggered on the eventfd, an interrupt is injected into
 the guest using the specified gsi pin.  The irqfd is removed using
 the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
 and kvm_irqfd.gsi.
@@ -2115,7 +2116,7 @@ interrupts.  When KVM_IRQFD_FLAG_RESAMPLE is set the user must pass an
 additional eventfd in the kvm_irqfd.resamplefd field.  When operating
 in resample mode, posting of an interrupt through kvm_irq.fd asserts
 the specified gsi in the irqchip.  When the irqchip is resampled, such
-as from an EOI, the gsi is de-asserted and the user is notifed via
+as from an EOI, the gsi is de-asserted and the user is notified via
 kvm_irqfd.resamplefd.  It is the user's responsibility to re-queue
 the interrupt if the device making use of it still requires service.
 Note that closing the resamplefd is not sufficient to disable the
@@ -2327,7 +2328,7 @@ current state.  "addr" is ignored.
 Capability: basic
 Architectures: arm, arm64
 Type: vcpu ioctl
-Parameters: struct struct kvm_vcpu_init (in)
+Parameters: struct kvm_vcpu_init (in)
 Returns: 0 on success; -1 on error
 Errors:
  EINVAL:    the target is unknown, or the combination of features is invalid.
@@ -2391,7 +2392,8 @@ struct kvm_reg_list {
 This ioctl returns the guest registers that are supported for the
 KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
-4.85 KVM_ARM_SET_DEVICE_ADDR
+4.85 KVM_ARM_SET_DEVICE_ADDR (deprecated)
 Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
 Architectures: arm, arm64
@@ -2429,6 +2431,10 @@ must be called after calling KVM_CREATE_IRQCHIP, but before calling
 KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
 base addresses will return -EEXIST.
+Note, this IOCTL is deprecated and the more flexible SET/GET_DEVICE_ATTR API
+should be used instead.
 4.86 KVM_PPC_RTAS_DEFINE_TOKEN
 Capability: KVM_CAP_PPC_RTAS
diff --git a/Documentation/virtual/kvm/devices/arm-vgic.txt b/Documentation/virtual/kvm/devices/arm-vgic.txt
new file mode 100644
index 000000000000..7f4e91b1316b
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/arm-vgic.txt
@@ -0,0 +1,73 @@
+ARM Virtual Generic Interrupt Controller (VGIC)
+===============================================
+Device types supported:
+  KVM_DEV_TYPE_ARM_VGIC_V2     ARM Generic Interrupt Controller v2.0
+Only one VGIC instance may be instantiated through either this API or the
+legacy KVM_CREATE_IRQCHIP api.  The created VGIC will act as the VM interrupt
+controller, requiring emulated user-space devices to inject interrupts to the
+VGIC instead of directly to CPUs.
+Groups:
+  KVM_DEV_ARM_VGIC_GRP_ADDR
+  Attributes:
+    KVM_VGIC_V2_ADDR_TYPE_DIST (rw, 64-bit)
+      Base address in the guest physical address space of the GIC distributor
+      register mappings.
+    KVM_VGIC_V2_ADDR_TYPE_CPU (rw, 64-bit)
+      Base address in the guest physical address space of the GIC virtual cpu
+      interface register mappings.
+  KVM_DEV_ARM_VGIC_GRP_DIST_REGS
+  Attributes:
+    The attr field of kvm_device_attr encodes two values:
+    bits:     | 63   ....  40 | 39 ..  32  |  31   ....    0 |
+    values:   |    reserved   |   cpu id   |      offset     |
+    All distributor regs are (rw, 32-bit)
+    The offset is relative to the "Distributor base address" as defined in the
+    GICv2 specs.  Getting or setting such a register has the same effect as
+    reading or writing the register on the actual hardware from the cpu
+    specified with cpu id field.  Note that most distributor fields are not
+    banked, but return the same value regardless of the cpu id used to access
+    the register.
+  Limitations:
+    - Priorities are not implemented, and registers are RAZ/WI
+  Errors:
+    -ENODEV: Getting or setting this register is not yet supported
+    -EBUSY: One or more VCPUs are running
+  KVM_DEV_ARM_VGIC_GRP_CPU_REGS
+  Attributes:
+    The attr field of kvm_device_attr encodes two values:
+    bits:     | 63   ....  40 | 39 ..  32  |  31   ....    0 |
+    values:   |    reserved   |   cpu id   |      offset     |
+    All CPU interface regs are (rw, 32-bit)
+    The offset specifies the offset from the "CPU interface base address" as
+    defined in the GICv2 specs.  Getting or setting such a register has the
+    same effect as reading or writing the register on the actual hardware.
+    The Active Priorities Registers APRn are implementation defined, so we set a
+    fixed format for our implementation that fits with the model of a "GICv2
+    implementation without the security extensions" which we present to the
+    guest.  This interface always exposes four register APR[0-3] describing the
+    maximum possible 128 preemption levels.  The semantics of the register
+    indicate if any interrupts in a given preemption level are in the active
+    state by setting the corresponding bit.
+    Thus, preemption level X has one or more active interrupts if and only if:
+      APRn[X mod 32] == 0b1,  where n = X / 32
+    Bits for undefined preemption levels are RAZ/WI.
+  Limitations:
+    - Priorities are not implemented, and registers are RAZ/WI
+  Errors:
+    -ENODEV: Getting or setting this register is not yet supported
+    -EBUSY: One or more VCPUs are running
diff --git a/Documentation/virtual/kvm/hypercalls.txt b/Documentation/virtual/kvm/hypercalls.txt
index 022198e389d7..c8d040e27046 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -17,6 +17,9 @@ S390:
  S390 uses diagnose instruction as hypercall (0x500) along with hypercall
  number in R1.
+  For further information on the S390 diagnose call as supported by KVM,
+  refer to Documentation/virtual/kvm/s390-diag.txt.
 PowerPC:
  It uses R3-R10 and hypercall number in R11. R4-R11 are used as output registers.
  Return value is placed in R3.
@@ -74,7 +77,7 @@ Usage example : A vcpu of a paravirtualized guest that is busywaiting in guest
 kernel mode for an event to occur (ex: a spinlock to become available) can
 execute HLT instruction once it has busy-waited for more than a threshold
 time-interval. Execution of HLT instruction would cause the hypervisor to put
-the vcpu to sleep until occurence of an appropriate event. Another vcpu of the
+the vcpu to sleep until occurrence of an appropriate event. Another vcpu of the
 same guest can wakeup the sleeping vcpu by issuing KVM_HC_KICK_CPU hypercall,
 specifying APIC ID (a1) of the vcpu to be woken up. An additional argument (a0)
 is used in the hypercall for future use.
diff --git a/Documentation/virtual/kvm/locking.txt b/Documentation/virtual/kvm/locking.txt
index f8869410d40c..d68af4dc3006 100644
--- a/Documentation/virtual/kvm/locking.txt
+++ b/Documentation/virtual/kvm/locking.txt
@@ -112,7 +112,7 @@ The Dirty bit is lost in this case.
 In order to avoid this kind of issue, we always treat the spte as "volatile"
 if it can be updated out of mmu-lock, see spte_has_volatile_bits(), it means,
-the spte is always atomicly updated in this case.
+the spte is always atomically updated in this case.
 3): flush tlbs due to spte updated
 If the spte is updated from writable to readonly, we should flush all TLBs,
@@ -125,7 +125,7 @@ be flushed caused by this reason in mmu_spte_update() since this is a common
 function to update spte (present -> present).
 Since the spte is "volatile" if it can be updated out of mmu-lock, we always
-atomicly update the spte, the race caused by fast page fault can be avoided,
+atomically update the spte, the race caused by fast page fault can be avoided,
 See the comments in spte_has_volatile_bits() and mmu_spte_update().
 3. Reference
diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt
index 4cd076febb02..4643cde517c4 100644
--- a/Documentation/virtual/kvm/ppc-pv.txt
+++ b/Documentation/virtual/kvm/ppc-pv.txt
@@ -115,7 +115,7 @@ If any other bit changes in the MSR, please still use mtmsr(d).
 Patched instructions
 ====================
-The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
+The "ld" and "std" instructions are transformed to "lwz" and "stw" instructions
 respectively on 32 bit systems with an added offset of 4 to accommodate for big
 endianness.
diff --git a/Documentation/virtual/kvm/s390-diag.txt b/Documentation/virtual/kvm/s390-diag.txt
new file mode 100644
index 000000000000..f1de4fbade15
--- /dev/null
+++ b/Documentation/virtual/kvm/s390-diag.txt
@@ -0,0 +1,80 @@
+The s390 DIAGNOSE call on KVM
+=============================
+KVM on s390 supports the DIAGNOSE call for making hypercalls, both for
+native hypercalls and for selected hypercalls found on other s390
+hypervisors.
+Note that bits are numbered as by the usual s390 convention (most significant
+bit on the left).
+General remarks
+---------------
+DIAGNOSE calls by the guest cause a mandatory intercept. This implies
+all supported DIAGNOSE calls need to be handled by either KVM or its
+userspace.
+All DIAGNOSE calls supported by KVM use the RS-a format:
+--------------------------------------
+|  '83'  | R1 | R3 | B2 |     D2     |
+--------------------------------------
+0        8    12   16   20           31
+The second-operand address (obtained by the base/displacement calculation)
+is not used to address data. Instead, bits 48-63 of this address specify
+the function code, and bits 0-47 are ignored.
+The supported DIAGNOSE function codes vary by the userspace used. For
+DIAGNOSE function codes not specific to KVM, please refer to the
+documentation for the s390 hypervisors defining them.
+DIAGNOSE function code 'X'500' - KVM virtio functions
+-----------------------------------------------------
+If the function code specifies 0x500, various virtio-related functions
+are performed.
+General register 1 contains the virtio subfunction code. Supported
+virtio subfunctions depend on KVM's userspace. Generally, userspace
+provides either s390-virtio (subcodes 0-2) or virtio-ccw (subcode 3).
+Upon completion of the DIAGNOSE instruction, general register 2 contains
+the function's return code, which is either a return code or a subcode
+specific value.
+Subcode 0 - s390-virtio notification and early console printk
+    Handled by userspace.
+Subcode 1 - s390-virtio reset
+    Handled by userspace.
+Subcode 2 - s390-virtio set status
+    Handled by userspace.
+Subcode 3 - virtio-ccw notification
+    Handled by either userspace or KVM (ioeventfd case).
+    General register 2 contains a subchannel-identification word denoting
+    the subchannel of the virtio-ccw proxy device to be notified.
+    General register 3 contains the number of the virtqueue to be notified.
+    General register 4 contains a 64bit identifier for KVM usage (the
+    kvm_io_bus cookie). If general register 4 does not contain a valid
+    identifier, it is ignored.
+    After completion of the DIAGNOSE call, general register 2 may contain
+    a 64bit identifier (in the kvm_io_bus cookie case).
+    See also the virtio standard for a discussion of this hypercall.
+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.
diff --git a/Documentation/virtual/kvm/timekeeping.txt b/Documentation/virtual/kvm/timekeeping.txt
index df8946377cb6..76808a17ad84 100644
--- a/Documentation/virtual/kvm/timekeeping.txt
+++ b/Documentation/virtual/kvm/timekeeping.txt
@@ -467,7 +467,7 @@ at any time.  This causes problems as the passage of real time, the injection
 of machine interrupts and the associated clock sources are no longer completely
 synchronized with real time.
-This same problem can occur on native harware to a degree, as SMM mode may
+This same problem can occur on native hardware to a degree, as SMM mode may
 steal cycles from the naturally on X86 systems when SMM mode is used by the
 BIOS, but not in such an extreme fashion.  However, the fact that SMM mode may
 cause similar problems to virtualization makes it a good justification for
diff --git a/Documentation/vm/locking b/Documentation/vm/locking
deleted file mode 100644
index f61228bd6395..000000000000
--- a/Documentation/vm/locking
+++ /dev/null
@@ -1,130 +0,0 @@
-Started Oct 1999 by Kanoj Sarcar <kanojsarcar@yahoo.com>
-The intent of this file is to have an uptodate, running commentary 
-from different people about how locking and synchronization is done 
-in the Linux vm code.
-page_table_lock & mmap_sem
--------------------------------------
-Page stealers pick processes out of the process pool and scan for 
-the best process to steal pages from. To guarantee the existence 
-of the victim mm, a mm_count inc and a mmdrop are done in swap_out().
-Page stealers hold kernel_lock to protect against a bunch of races.
-The vma list of the victim mm is also scanned by the stealer, 
-and the page_table_lock is used to preserve list sanity against the
-process adding/deleting to the list. This also guarantees existence
-of the vma. Vma existence is not guaranteed once try_to_swap_out() 
-drops the page_table_lock. To guarantee the existence of the underlying 
-file structure, a get_file is done before the swapout() method is 
-invoked. The page passed into swapout() is guaranteed not to be reused
-for a different purpose because the page reference count due to being
-present in the user's pte is not released till after swapout() returns.
-Any code that modifies the vmlist, or the vm_start/vm_end/
-vm_flags:VM_LOCKED/vm_next of any vma *in the list* must prevent 
-kswapd from looking at the chain.
-The rules are:
-1. To scan the vmlist (look but don't touch) you must hold the
-   mmap_sem with read bias, i.e. down_read(&mm->mmap_sem)
-2. To modify the vmlist you need to hold the mmap_sem with
-   read&write bias, i.e. down_write(&mm->mmap_sem)  *AND*
-   you need to take the page_table_lock.
-3. The swapper takes _just_ the page_table_lock, this is done
-   because the mmap_sem can be an extremely long lived lock
-   and the swapper just cannot sleep on that.
-4. The exception to this rule is expand_stack, which just
-   takes the read lock and the page_table_lock, this is ok
-   because it doesn't really modify fields anybody relies on.
-5. You must be able to guarantee that while holding page_table_lock
-   or page_table_lock of mm A, you will not try to get either lock
-   for mm B.
-The caveats are:
-1. find_vma() makes use of, and updates, the mmap_cache pointer hint.
-The update of mmap_cache is racy (page stealer can race with other code
-that invokes find_vma with mmap_sem held), but that is okay, since it 
-is a hint. This can be fixed, if desired, by having find_vma grab the
-page_table_lock.
-Code that add/delete elements from the vmlist chain are
-1. callers of insert_vm_struct
-2. callers of merge_segments
-3. callers of avl_remove
-Code that changes vm_start/vm_end/vm_flags:VM_LOCKED of vma's on
-the list:
-1. expand_stack
-2. mprotect
-3. mlock
-4. mremap
-It is advisable that changes to vm_start/vm_end be protected, although 
-in some cases it is not really needed. Eg, vm_start is modified by 
-expand_stack(), it is hard to come up with a destructive scenario without 
-having the vmlist protection in this case.
-The page_table_lock nests with the inode i_mmap_mutex and the kmem cache
-c_spinlock spinlocks.  This is okay, since the kmem code asks for pages after
-dropping c_spinlock.  The page_table_lock also nests with pagecache_lock and
-pagemap_lru_lock spinlocks, and no code asks for memory with these locks
-held.
-The page_table_lock is grabbed while holding the kernel_lock spinning monitor.
-The page_table_lock is a spin lock.
-Note: PTL can also be used to guarantee that no new clones using the
-mm start up ... this is a loose form of stability on mm_users. For
-example, it is used in copy_mm to protect against a racing tlb_gather_mmu
-single address space optimization, so that the zap_page_range (from
-truncate) does not lose sending ipi's to cloned threads that might
-be spawned underneath it and go to user mode to drag in pte's into tlbs.
-swap_lock
--------------
-The swap devices are chained in priority order from the "swap_list" header. 
-The "swap_list" is used for the round-robin swaphandle allocation strategy.
-The #free swaphandles is maintained in "nr_swap_pages". These two together
-are protected by the swap_lock.
-The swap_lock also protects all the device reference counts on the
-corresponding swaphandles, maintained in the "swap_map" array, and the
-"highest_bit" and "lowest_bit" fields.
-The swap_lock is a spinlock, and is never acquired from intr level.
-To prevent races between swap space deletion or async readahead swapins
-deciding whether a swap handle is being used, ie worthy of being read in
-from disk, and an unmap -> swap_free making the handle unused, the swap
-delete and readahead code grabs a temp reference on the swaphandle to
-prevent warning messages from swap_duplicate <- read_swap_cache_async.
-Swap cache locking
------------------
-Pages are added into the swap cache with kernel_lock held, to make sure
-that multiple pages are not being added (and hence lost) by associating
-all of them with the same swaphandle.
-Pages are guaranteed not to be removed from the scache if the page is 
-"shared": ie, other processes hold reference on the page or the associated 
-swap handle. The only code that does not follow this rule is shrink_mmap,
-which deletes pages from the swap cache if no process has a reference on 
-the page (multiple processes might have references on the corresponding
-swap handle though). lookup_swap_cache() races with shrink_mmap, when
-establishing a reference on a scache page, so, it must check whether the
-page it located is still in the swapcache, or shrink_mmap deleted it.
-(This race is due to the fact that shrink_mmap looks at the page ref
-count with pagecache_lock, but then drops pagecache_lock before deleting
-the page from the scache).
-do_wp_page and do_swap_page have MP races in them while trying to figure
-out whether a page is "shared", by looking at the page_count + swap_count.
-To preserve the sum of the counts, the page lock _must_ be acquired before
-calling is_page_shared (else processes might switch their swap_count refs
-to the page count refs, after the page count ref has been snapshotted).
-Swap device deletion code currently breaks all the scache assumptions,
-since it grabs neither mmap_sem nor page_table_lock.
diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting
index 8eaa2fc4b8fa..cbfaaa674118 100644
--- a/Documentation/vm/overcommit-accounting
+++ b/Documentation/vm/overcommit-accounting
@@ -14,8 +14,8 @@ The Linux kernel supports the following overcommit handling modes
 2       -       Don't overcommit. The total address space commit
                for the system is not permitted to exceed swap + a
-                configurable percentage (default is 50) of physical RAM.
+                configurable amount (default is 50%) of physical RAM.
-                Depending on the percentage you use, in most situations
+                Depending on the amount you use, in most situations
                this means a process will not be killed while accessing
                pages but will receive errors on memory allocation as
                appropriate.
@@ -26,7 +26,8 @@ The Linux kernel supports the following overcommit handling modes
 The overcommit policy is set via the sysctl `vm.overcommit_memory'.
-The overcommit percentage is set via `vm.overcommit_ratio'.
+The overcommit amount can be set via `vm.overcommit_ratio' (percentage)
+or `vm.overcommit_kbytes' (absolute value).
 The current overcommit limit and amount committed are viewable in
 /proc/meminfo as CommitLimit and Committed_AS respectively.
diff --git a/Documentation/vme_api.txt b/Documentation/vme_api.txt
index 856efa35f6e3..ffe6e22a2ccd 100644
--- a/Documentation/vme_api.txt
+++ b/Documentation/vme_api.txt
@@ -393,4 +393,14 @@ Slot Detection
 This function returns the slot ID of the provided bridge.
-        int vme_slot_get(struct vme_dev *dev);
+        int vme_slot_num(struct vme_dev *dev);
+Bus Detection
+=============
+This function returns the bus ID of the provided bridge.
+        int vme_bus_num(struct vme_dev *dev);
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index 1228b22e142b..5223479291a2 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -78,14 +78,6 @@ APICs
   no_timer_check Don't check the IO-APIC timer. This can work around
                 problems with incorrect timer initialization on some boards.
-   apicmaintimer Run time keeping from the local APIC timer instead
-                 of using the PIT/HPET interrupt for this. This is useful
-                 when the PIT/HPET interrupts are unreliable.
-   noapicmaintimer  Don't do time keeping using the APIC timer.
-                 Useful when this option was auto selected, but doesn't work.
   apicpmtimer
                 Do APIC timer calibration using the pmtimer. Implies
                 apicmaintimer. Useful when your PIT timer is totally
@@ -144,11 +136,6 @@ Non Executable Mappings
  on      Enable(default)
  off     Disable
-SMP
-  additional_cpus=NUM Allow NUM more CPUs for hotplug
-                 (defaults are specified by the BIOS, see Documentation/x86/x86_64/cpu-hotplug-spec)
 NUMA
  numa=off      Only set up a single NUMA node spanning all memory.
@@ -289,16 +276,6 @@ Debugging
  kstack=N      Print N words from the kernel stack in oops dumps.
-  pagefaulttrace  Dump all page faults. Only useful for extreme debugging
-                and will create a lot of output.
-  call_trace=[old|both|newfallback|new]
-                old: use old inexact backtracer
-                new: use new exact dwarf2 unwinder
-                both: print entries from both
-                newfallback: use new unwinder but fall back to old if it gets
-                        stuck (default)
 Miscellaneous
        nogbpages
diff --git a/Documentation/xtensa/atomctl.txt b/Documentation/xtensa/atomctl.txt
index 10a8d1ff35ec..1da783ac200c 100644
--- a/Documentation/xtensa/atomctl.txt
+++ b/Documentation/xtensa/atomctl.txt
@@ -40,5 +40,5 @@ See Section 4.3.12.4 of ISA; Bits:
 ---------    ---------------         -----------------     ----------------
    0        Exception               Exception               Exception
    1        RCW Transaction         RCW Transaction         RCW Transaction
-    2        Internal Operation      Exception               Reserved
+    2        Internal Operation      Internal Operation      Reserved
    3        Reserved                Reserved                Reserved
diff --git a/Documentation/xtensa/mmu.txt b/Documentation/xtensa/mmu.txt
index 2b1af7606d57..0312fe66475c 100644
--- a/Documentation/xtensa/mmu.txt
+++ b/Documentation/xtensa/mmu.txt
@@ -44,3 +44,21 @@ After step 4, we jump to intended (linked) address of this code.
 40..5F -> 40         40..5F -> pc  -> pc  40..5F -> pc
 20..3F -> 20  -> 20  20..3F -> 20
 00..1F -> 00  -> 00  00..1F -> 00
+The default location of IO peripherals is above 0xf0000000. This may change
+using a "ranges" property in a device tree simple-bus node. See ePAPR 1.1, §6.5
+for details on the syntax and semantic of simple-bus nodes. The following
+limitations apply:
+1. Only top level simple-bus nodes are considered
+2. Only one (first) simple-bus node is considered
+3. Empty "ranges" properties are not supported
+4. Only the first triplet in the "ranges" property is considered
+5. The parent-bus-address value is rounded down to the nearest 256MB boundary
+6. The IO area covers the entire 256MB segment of parent-bus-address; the
+   "ranges" triplet length field is ignored
diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO
index 7fba5aab9ef9..6c914aa87e71 100644
--- a/Documentation/zh_CN/HOWTO
+++ b/Documentation/zh_CN/HOWTO
@@ -112,7 +112,7 @@ Linux内核代码中包含有大量的文档。这些文档对于学习如何与
    其他关于如何正确地生成补丁的优秀文档包括：
    "The Perfect Patch"
-        http://userweb.kernel.org/~akpm/stuff/tpp.txt
+        http://www.ozlabs.org/~akpm/stuff/tpp.txt
    "Linux kernel patch submission format"
        http://linux.yyz.us/patch-format.html
@@ -515,7 +515,7 @@ Linux内核社区并不喜欢一下接收大段的代码。修改需要被恰当
 想了解它具体应该看起来像什么，请查阅以下文档中的“ChangeLog”章节：
  “The Perfect Patch”
-         http://userweb.kernel.org/~akpm/stuff/tpp.txt
+         http://www.ozlabs.org/~akpm/stuff/tpp.txt
 这些事情有时候做起来很难。要在任何方面都做到完美可能需要好几年时间。这是