352 files changed, 12118 insertions, 3485 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 45b3df936d2f..0c4cc688e89a 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -187,6 +187,8 @@ firmware_class/
        - request_firmware() hotplug interface info.
 flexible-arrays.txt
        - how to make use of flexible sized arrays in linux
+fmc/
+        - information about the FMC bus abstraction
 frv/
        - Fujitsu FR-V Linux documentation.
 futex-requeue-pi.txt
diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module
index a0dd21c6db59..6272ae5fb366 100644
--- a/Documentation/ABI/stable/sysfs-module
+++ b/Documentation/ABI/stable/sysfs-module
@@ -4,9 +4,13 @@ Description:
        /sys/module/MODULENAME
                The name of the module that is in the kernel.  This
-                module name will show up either if the module is built
+                module name will always show up if the module is loaded as a
-                directly into the kernel, or if it is loaded as a
+                dynamic module.  If it is built directly into the kernel, it
-                dynamic module.
+                will only show up if it has a version or at least one
+                parameter.
+                Note: The conditions of creation in the built-in case are not
+                by design and may be removed in the future.
        /sys/module/MODULENAME/parameters
                This directory contains individual files that are each
diff --git a/Documentation/ABI/testing/configfs-usb-gadget b/Documentation/ABI/testing/configfs-usb-gadget
new file mode 100644
index 000000000000..01e769d6984d
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget
@@ -0,0 +1,81 @@
+What:           /config/usb-gadget
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This group contains sub-groups corresponding to created
+                USB gadgets.
+What:           /config/usb-gadget/gadget
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                The attributes of a gadget:
+                UDC             - bind a gadget to UDC/unbind a gadget;
+                                write UDC's name found in /sys/class/udc/*
+                                to bind a gadget, empty string "" to unbind.
+                bDeviceClass    - USB device class code
+                bDeviceSubClass - USB device subclass code
+                bDeviceProtocol - USB device protocol code
+                bMaxPacketSize0 - maximum endpoint 0 packet size
+                bcdDevice       - bcd device release number
+                bcdUSB          - bcd USB specification version number
+                idProduct       - product ID
+                idVendor        - vendor ID
+What:           /config/usb-gadget/gadget/configs
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This group contains a USB gadget's configurations
+What:           /config/usb-gadget/gadget/configs/config
+Date:           Jun 2013
+KernelVersion:  3.11
+Description:
+                The attributes of a configuration:
+                bmAttributes    - configuration characteristics
+                MaxPower        - maximum power consumption from the bus
+What:           /config/usb-gadget/gadget/configs/config/strings
+Date:           Jun 2013
+KernelVersion:  3.11
+Description:
+                This group contains subdirectories for language-specific
+                strings for this configuration.
+What:           /config/usb-gadget/gadget/configs/config/strings/language
+Date:           Jun 2013
+KernelVersion:  3.11
+Description:
+                The attributes:
+                configuration   - configuration description
+What:           /config/usb-gadget/gadget/functions
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This group contains functions available to this USB gadget.
+What:           /config/usb-gadget/gadget/strings
+Date:           Jun 2013
+KenelVersion:   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
+Description:
+                The attributes:
+                serialnumber    - gadget's serial number (string)
+                product         - gadget's product description
+                manufacturer    - gadget's manufacturer description
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-acm b/Documentation/ABI/testing/configfs-usb-gadget-acm
new file mode 100644
index 000000000000..5708a568b5f6
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-acm
@@ -0,0 +1,8 @@
+What:           /config/usb-gadget/gadget/functions/acm.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This item contains just one readonly attribute: port_num.
+                It contains the port number of the /dev/ttyGS<n> device
+                associated with acm function's instance "name".
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ecm b/Documentation/ABI/testing/configfs-usb-gadget-ecm
new file mode 100644
index 000000000000..6b9a582ce0b5
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ecm
@@ -0,0 +1,16 @@
+What:           /config/usb-gadget/gadget/functions/ecm.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                The attributes:
+                ifname          - network device interface name associated with
+                                this function instance
+                qmult           - queue length multiplier for high and
+                                super speed
+                host_addr       - MAC address of host's end of this
+                                Ethernet over USB link
+                dev_addr        - MAC address of device's end of this
+                                Ethernet over USB link
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-eem b/Documentation/ABI/testing/configfs-usb-gadget-eem
new file mode 100644
index 000000000000..dbddf36b48b3
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-eem
@@ -0,0 +1,14 @@
+What:           /config/usb-gadget/gadget/functions/eem.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                The attributes:
+                ifname          - network device interface name associated with
+                                this function instance
+                qmult           - queue length multiplier for high and
+                                super speed
+                host_addr       - MAC address of host's end of this
+                                Ethernet over USB link
+                dev_addr        - MAC address of device's end of this
+                                Ethernet over USB link
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-ncm b/Documentation/ABI/testing/configfs-usb-gadget-ncm
new file mode 100644
index 000000000000..bc309f42357d
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-ncm
@@ -0,0 +1,15 @@
+What:           /config/usb-gadget/gadget/functions/ncm.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                The attributes:
+                ifname          - network device interface name associated with
+                                this function instance
+                qmult           - queue length multiplier for high and
+                                super speed
+                host_addr       - MAC address of host's end of this
+                                Ethernet over USB link
+                dev_addr        - MAC address of device's end of this
+                                Ethernet over USB link
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-obex b/Documentation/ABI/testing/configfs-usb-gadget-obex
new file mode 100644
index 000000000000..aaa5c96fb7c6
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-obex
@@ -0,0 +1,9 @@
+What:           /config/usb-gadget/gadget/functions/obex.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This item contains just one readonly attribute: port_num.
+                It contains the port number of the /dev/ttyGS<n> device
+                associated with obex function's instance "name".
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-phonet b/Documentation/ABI/testing/configfs-usb-gadget-phonet
new file mode 100644
index 000000000000..3e3b742cdfd7
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-phonet
@@ -0,0 +1,8 @@
+What:           /config/usb-gadget/gadget/functions/phonet.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This item contains just one readonly attribute: ifname.
+                It contains the network interface name assigned during
+                network device registration.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-rndis b/Documentation/ABI/testing/configfs-usb-gadget-rndis
new file mode 100644
index 000000000000..822e6dad8fc0
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-rndis
@@ -0,0 +1,14 @@
+What:           /config/usb-gadget/gadget/functions/rndis.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                The attributes:
+                ifname          - network device interface name associated with
+                                this function instance
+                qmult           - queue length multiplier for high and
+                                super speed
+                host_addr       - MAC address of host's end of this
+                                Ethernet over USB link
+                dev_addr        - MAC address of device's end of this
+                                Ethernet over USB link
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-serial b/Documentation/ABI/testing/configfs-usb-gadget-serial
new file mode 100644
index 000000000000..16f130c1501f
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-serial
@@ -0,0 +1,9 @@
+What:           /config/usb-gadget/gadget/functions/gser.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                This item contains just one readonly attribute: port_num.
+                It contains the port number of the /dev/ttyGS<n> device
+                associated with gser function's instance "name".
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-subset b/Documentation/ABI/testing/configfs-usb-gadget-subset
new file mode 100644
index 000000000000..154ae597cd99
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-subset
@@ -0,0 +1,14 @@
+What:           /config/usb-gadget/gadget/functions/geth.name
+Date:           Jun 2013
+KenelVersion:   3.11
+Description:
+                The attributes:
+                ifname          - network device interface name associated with
+                                this function instance
+                qmult           - queue length multiplier for high and
+                                super speed
+                host_addr       - MAC address of host's end of this
+                                Ethernet over USB link
+                dev_addr        - MAC address of device's end of this
+                                Ethernet over USB link
diff --git a/Documentation/ABI/testing/sysfs-bus-acpi b/Documentation/ABI/testing/sysfs-bus-acpi
new file mode 100644
index 000000000000..7fa9cbc75344
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-acpi
@@ -0,0 +1,58 @@
+What:           /sys/bus/acpi/devices/.../path
+Date:           December 2006
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                This attribute indicates the full path of ACPI namespace
+                object associated with the device object.  For example,
+                \_SB_.PCI0.
+                This file is not present for device objects representing
+                fixed ACPI hardware features (like power and sleep
+                buttons).
+What:           /sys/bus/acpi/devices/.../modalias
+Date:           July 2007
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                This attribute indicates the PNP IDs of the device object.
+                That is acpi:HHHHHHHH:[CCCCCCC:].  Where each HHHHHHHH or
+                CCCCCCCC contains device object's PNPID (_HID or _CID).
+What:           /sys/bus/acpi/devices/.../hid
+Date:           April 2005
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                This attribute indicates the hardware ID (_HID) of the
+                device object.  For example, PNP0103.
+                This file is present for device objects having the _HID
+                control method.
+What:           /sys/bus/acpi/devices/.../description
+Date:           October 2012
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                This attribute contains the output of the device object's
+                _STR control method, if present.
+What:           /sys/bus/acpi/devices/.../adr
+Date:           October 2012
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                This attribute contains the output of the device object's
+                _ADR control method, which is present for ACPI device
+                objects representing devices having standard enumeration
+                algorithms, such as PCI.
+What:           /sys/bus/acpi/devices/.../uid
+Date:           October 2012
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                This attribute contains the output of the device object's
+                _UID control method, if present.
+What:           /sys/bus/acpi/devices/.../eject
+Date:           December 2006
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                Writing 1 to this attribute will trigger hot removal of
+                this device object.  This file exists for every device
+                object that has _EJ0 method.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 0adeb524c0d4..8b25ffb42562 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -27,14 +27,36 @@ Description:	Generic performance monitoring events
                "basename".
-What:           /sys/devices/cpu/events/PM_LD_MISS_L1
+What:           /sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
-                /sys/devices/cpu/events/PM_LD_REF_L1
-                /sys/devices/cpu/events/PM_CYC
                /sys/devices/cpu/events/PM_BRU_FIN
-                /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
                /sys/devices/cpu/events/PM_BRU_MPRED
-                /sys/devices/cpu/events/PM_INST_CMPL
                /sys/devices/cpu/events/PM_CMPLU_STALL
+                /sys/devices/cpu/events/PM_CMPLU_STALL_BRU
+                /sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
+                /sys/devices/cpu/events/PM_CMPLU_STALL_DFU
+                /sys/devices/cpu/events/PM_CMPLU_STALL_DIV
+                /sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
+                /sys/devices/cpu/events/PM_CMPLU_STALL_FXU
+                /sys/devices/cpu/events/PM_CMPLU_STALL_IFU
+                /sys/devices/cpu/events/PM_CMPLU_STALL_LSU
+                /sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
+                /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
+                /sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
+                /sys/devices/cpu/events/PM_CMPLU_STALL_STORE
+                /sys/devices/cpu/events/PM_CMPLU_STALL_THRD
+                /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
+                /sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
+                /sys/devices/cpu/events/PM_CYC
+                /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
+                /sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
+                /sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
+                /sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
+                /sys/devices/cpu/events/PM_GRP_CMPL
+                /sys/devices/cpu/events/PM_INST_CMPL
+                /sys/devices/cpu/events/PM_LD_MISS_L1
+                /sys/devices/cpu/events/PM_LD_REF_L1
+                /sys/devices/cpu/events/PM_RUN_CYC
+                /sys/devices/cpu/events/PM_RUN_INST_CMPL
 Date:           2013/01/08
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
index 079afc71363d..77f47ff5ee02 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-format
@@ -9,6 +9,12 @@ Description:
                we want to export, so that userspace can deal with sane
                name/value pairs.
+                Userspace must be prepared for the possibility that attributes
+                define overlapping bit ranges. For example:
+                        attr1 = 'config:0-23'
+                        attr2 = 'config:0-7'
+                        attr3 = 'config:12-35'
                Example: 'config1:1,6-10,44'
                Defines contents of attribute that occupies bits 1,6-10,44 of
                perf_event_attr::config1.
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 2e33dc6b2346..dda81ffae5cf 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -690,45 +690,45 @@ Description:
                Actually start the buffer capture up.  Will start trigger
                if first device and appropriate.
-What:           /sys/bus/iio/devices/iio:deviceX/buffer/scan_elements
+What:           /sys/bus/iio/devices/iio:deviceX/scan_elements
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
                Directory containing interfaces for elements that will be
                captured for a single triggered sample set in the buffer.
-What:           /sys/.../buffer/scan_elements/in_accel_x_en
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_x_en
-What:           /sys/.../buffer/scan_elements/in_accel_y_en
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_y_en
-What:           /sys/.../buffer/scan_elements/in_accel_z_en
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_z_en
-What:           /sys/.../buffer/scan_elements/in_anglvel_x_en
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en
-What:           /sys/.../buffer/scan_elements/in_anglvel_y_en
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en
-What:           /sys/.../buffer/scan_elements/in_anglvel_z_en
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
-What:           /sys/.../buffer/scan_elements/in_magn_x_en
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_x_en
-What:           /sys/.../buffer/scan_elements/in_magn_y_en
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_y_en
-What:           /sys/.../buffer/scan_elements/in_magn_z_en
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_z_en
-What:           /sys/.../buffer/scan_elements/in_timestamp_en
+What:           /sys/.../iio:deviceX/scan_elements/in_timestamp_en
-What:           /sys/.../buffer/scan_elements/in_voltageY_supply_en
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
-What:           /sys/.../buffer/scan_elements/in_voltageY_en
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY_en
-What:           /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
-What:           /sys/.../buffer/scan_elements/in_incli_x_en
+What:           /sys/.../iio:deviceX/scan_elements/in_incli_x_en
-What:           /sys/.../buffer/scan_elements/in_incli_y_en
+What:           /sys/.../iio:deviceX/scan_elements/in_incli_y_en
-What:           /sys/.../buffer/scan_elements/in_pressureY_en
+What:           /sys/.../iio:deviceX/scan_elements/in_pressureY_en
-What:           /sys/.../buffer/scan_elements/in_pressure_en
+What:           /sys/.../iio:deviceX/scan_elements/in_pressure_en
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
                Scan element control for triggered data capture.
-What:           /sys/.../buffer/scan_elements/in_accel_type
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_type
-What:           /sys/.../buffer/scan_elements/in_anglvel_type
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_type
-What:           /sys/.../buffer/scan_elements/in_magn_type
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_type
-What:           /sys/.../buffer/scan_elements/in_incli_type
+What:           /sys/.../iio:deviceX/scan_elements/in_incli_type
-What:           /sys/.../buffer/scan_elements/in_voltageY_type
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY_type
-What:           /sys/.../buffer/scan_elements/in_voltage_type
+What:           /sys/.../iio:deviceX/scan_elements/in_voltage_type
-What:           /sys/.../buffer/scan_elements/in_voltageY_supply_type
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
-What:           /sys/.../buffer/scan_elements/in_timestamp_type
+What:           /sys/.../iio:deviceX/scan_elements/in_timestamp_type
-What:           /sys/.../buffer/scan_elements/in_pressureY_type
+What:           /sys/.../iio:deviceX/scan_elements/in_pressureY_type
-What:           /sys/.../buffer/scan_elements/in_pressure_type
+What:           /sys/.../iio:deviceX/scan_elements/in_pressure_type
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
@@ -752,29 +752,29 @@ Description:
                For other storage combinations this attribute will be extended
                appropriately.
-What:           /sys/.../buffer/scan_elements/in_accel_type_available
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_type_available
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
                If the type parameter can take one of a small set of values,
                this attribute lists them.
-What:           /sys/.../buffer/scan_elements/in_voltageY_index
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY_index
-What:           /sys/.../buffer/scan_elements/in_voltageY_supply_index
+What:           /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
-What:           /sys/.../buffer/scan_elements/in_accel_x_index
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_x_index
-What:           /sys/.../buffer/scan_elements/in_accel_y_index
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_y_index
-What:           /sys/.../buffer/scan_elements/in_accel_z_index
+What:           /sys/.../iio:deviceX/scan_elements/in_accel_z_index
-What:           /sys/.../buffer/scan_elements/in_anglvel_x_index
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index
-What:           /sys/.../buffer/scan_elements/in_anglvel_y_index
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index
-What:           /sys/.../buffer/scan_elements/in_anglvel_z_index
+What:           /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
-What:           /sys/.../buffer/scan_elements/in_magn_x_index
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_x_index
-What:           /sys/.../buffer/scan_elements/in_magn_y_index
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_y_index
-What:           /sys/.../buffer/scan_elements/in_magn_z_index
+What:           /sys/.../iio:deviceX/scan_elements/in_magn_z_index
-What:           /sys/.../buffer/scan_elements/in_incli_x_index
+What:           /sys/.../iio:deviceX/scan_elements/in_incli_x_index
-What:           /sys/.../buffer/scan_elements/in_incli_y_index
+What:           /sys/.../iio:deviceX/scan_elements/in_incli_y_index
-What:           /sys/.../buffer/scan_elements/in_timestamp_index
+What:           /sys/.../iio:deviceX/scan_elements/in_timestamp_index
-What:           /sys/.../buffer/scan_elements/in_pressureY_index
+What:           /sys/.../iio:deviceX/scan_elements/in_pressureY_index
-What:           /sys/.../buffer/scan_elements/in_pressure_index
+What:           /sys/.../iio:deviceX/scan_elements/in_pressure_index
 KernelVersion:  2.6.37
 Contact:        linux-iio@vger.kernel.org
 Description:
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index 1ce5ae329c04..5210a51c90fd 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -64,7 +64,6 @@ Description:
                Writing a non-zero value to this attribute will
                force a rescan of all PCI buses in the system, and
                re-discover previously removed devices.
-                Depends on CONFIG_HOTPLUG.
 What:           /sys/bus/pci/devices/.../msi_irqs/
 Date:           September, 2011
@@ -90,7 +89,6 @@ Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 Description:
                Writing a non-zero value to this attribute will
                hot-remove the PCI device and any of its children.
-                Depends on CONFIG_HOTPLUG.
 What:           /sys/bus/pci/devices/.../pci_bus/.../rescan
 Date:           May 2011
@@ -99,7 +97,7 @@ Description:
                Writing a non-zero value to this attribute will
                force a rescan of the bus and all child buses,
                and re-discover devices removed earlier from this
-                part of the device tree.  Depends on CONFIG_HOTPLUG.
+                part of the device tree.
 What:           /sys/bus/pci/devices/.../rescan
 Date:           January 2009
@@ -109,7 +107,6 @@ Description:
                force a rescan of the device's parent bus and all
                child buses, and re-discover devices removed earlier
                from this part of the device tree.
-                Depends on CONFIG_HOTPLUG.
 What:           /sys/bus/pci/devices/.../reset
 Date:           July 2009
diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb
index f093e59cbe5f..9759b8c91332 100644
--- a/Documentation/ABI/testing/sysfs-bus-usb
+++ b/Documentation/ABI/testing/sysfs-bus-usb
@@ -236,3 +236,30 @@ Description:
                This attribute is to expose these information to user space.
                The file will read "hotplug", "wired" and "not used" if the
                information is available, and "unknown" otherwise.
+What:           /sys/bus/usb/devices/.../power/usb2_lpm_l1_timeout
+Date:           May 2013
+Contact:        Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+                USB 2.0 devices may support hardware link power management (LPM)
+                L1 sleep state. The usb2_lpm_l1_timeout attribute allows
+                tuning the timeout for L1 inactivity timer (LPM timer), e.g.
+                needed inactivity time before host requests the device to go to L1 sleep.
+                Useful for power management tuning.
+                Supported values are 0 - 65535 microseconds.
+What:           /sys/bus/usb/devices/.../power/usb2_lpm_besl
+Date:           May 2013
+Contact:        Mathias Nyman <mathias.nyman@linux.intel.com>
+Description:
+                USB 2.0 devices that support hardware link power management (LPM)
+                L1 sleep state now use a best effort service latency value (BESL) to
+                indicate the best effort to resumption of service to the device after the
+                initiation of the resume event.
+                If the device does not have a preferred besl value then the host can select
+                one instead. This usb2_lpm_besl attribute allows to tune the host selected besl
+                value in order to tune power saving and service latency.
+                Supported values are 0 - 15.
+                More information on how besl values map to microseconds can be found in
+                USB 2.0 ECN Errata for Link Power Management, section 4.10)
diff --git a/Documentation/ABI/testing/sysfs-class-devfreq b/Documentation/ABI/testing/sysfs-class-devfreq
index 0ba6ea2f89d9..ee39acacf6f8 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -78,3 +78,23 @@ Contact:	Nishanth Menon <nm@ti.com>
 Description:
                The /sys/class/devfreq/.../available_governors shows
                currently available governors in the system.
+What:           /sys/class/devfreq/.../min_freq
+Date:           January 2013
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/devfreq/.../min_freq shows and stores
+                the minimum frequency requested by users. It is 0 if
+                the user does not care. min_freq overrides the
+                frequency requested by governors.
+What:           /sys/class/devfreq/.../max_freq
+Date:           January 2013
+Contact:        MyungJoo Ham <myungjoo.ham@samsung.com>
+Description:
+                The /sys/class/devfreq/.../max_freq shows and stores
+                the maximum frequency requested by users. It is 0 if
+                the user does not care. max_freq overrides the
+                frequency requested by governors and min_freq.
+                The max_freq overrides min_freq because max_freq may be
+                used to throttle devices to avoid overheating.
diff --git a/Documentation/ABI/testing/sysfs-class-pwm b/Documentation/ABI/testing/sysfs-class-pwm
new file mode 100644
index 000000000000..c479d77b67c5
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-pwm
@@ -0,0 +1,79 @@
+What:           /sys/class/pwm/
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                The pwm/ class sub-directory belongs to the Generic PWM
+                Framework and provides a sysfs interface for using PWM
+                channels.
+What:           /sys/class/pwm/pwmchipN/
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                A /sys/class/pwm/pwmchipN directory is created for each
+                probed PWM controller/chip where N is the base of the
+                PWM chip.
+What:           /sys/class/pwm/pwmchipN/npwm
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                The number of PWM channels supported by the PWM chip.
+What:           /sys/class/pwm/pwmchipN/export
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                Exports a PWM channel from the PWM chip for sysfs control.
+                Value is between 0 and /sys/class/pwm/pwmchipN/npwm - 1.
+What:           /sys/class/pwm/pwmchipN/unexport
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                Unexports a PWM channel.
+What:           /sys/class/pwm/pwmchipN/pwmX
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                A /sys/class/pwm/pwmchipN/pwmX directory is created for
+                each exported PWM channel where X is the exported PWM
+                channel number.
+What:           /sys/class/pwm/pwmchipN/pwmX/period
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                Sets the PWM signal period in nanoseconds.
+What:           /sys/class/pwm/pwmchipN/pwmX/duty_cycle
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                Sets the PWM signal duty cycle in nanoseconds.
+What:           /sys/class/pwm/pwmchipN/pwmX/polarity
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                Sets the output polarity of the PWM signal to "normal" or
+                "inversed".
+What:           /sys/class/pwm/pwmchipN/pwmX/enable
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        H Hartley Sweeten <hsweeten@visionengravers.com>
+Description:
+                Enable/disable the PWM signal.
+                0 is disabled
+                1 is enabled
diff --git a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
index 25b1e751b777..5977e2875325 100644
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
+++ b/Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
@@ -36,3 +36,22 @@ Description:
                Refer to [ECMA-368] section 10.3.1.1 for the value to
                use.
+What:           /sys/class/uwb_rc/uwbN/wusbhc/wusb_dnts
+Date:           June 2013
+KernelVersion:  3.11
+Contact:        Thomas Pugliese <thomas.pugliese@gmail.com>
+Description:
+                The device notification time slot (DNTS) count and inverval in
+                milliseconds that the WUSB host should use.  This controls how
+                often the devices will have the opportunity to send
+                notifications to the host.
+What:           /sys/class/uwb_rc/uwbN/wusbhc/wusb_retry_count
+Date:           June 2013
+KernelVersion:  3.11
+Contact:        Thomas Pugliese <thomas.pugliese@gmail.com>
+Description:
+                The number of retries that the WUSB host should attempt
+                before reporting an error for a bus transaction.  The range of
+                valid values is [0..15], where 0 indicates infinite retries.
diff --git a/Documentation/ABI/testing/sysfs-devices-online b/Documentation/ABI/testing/sysfs-devices-online
new file mode 100644
index 000000000000..f990026c0740
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-online
@@ -0,0 +1,20 @@
+What:           /sys/devices/.../online
+Date:           April 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The /sys/devices/.../online attribute is only present for
+                devices whose bus types provide .online() and .offline()
+                callbacks.  The number read from it (0 or 1) reflects the value
+                of the device's 'offline' field.  If that number is 1 and '0'
+                (or 'n', or 'N') is written to this file, the device bus type's
+                .offline() callback is executed for the device and (if
+                successful) its 'offline' field is updated accordingly.  In
+                turn, if that number is 0 and '1' (or 'y', or 'Y') is written to
+                this file, the device bus type's .online() callback is executed
+                for the device and (if successful) its 'offline' field is
+                updated as appropriate.
+                After a successful execution of the bus type's .offline()
+                callback the device cannot be used for any purpose until either
+                it is removed (i.e. device_del() is called for it), or its bus
+                type's .online() is exeucted successfully.
diff --git a/Documentation/ABI/testing/sysfs-devices-sun b/Documentation/ABI/testing/sysfs-devices-sun
index 86be9848a77e..625ce4b63758 100644
--- a/Documentation/ABI/testing/sysfs-devices-sun
+++ b/Documentation/ABI/testing/sysfs-devices-sun
@@ -1,4 +1,4 @@
-Whatt:          /sys/devices/.../sun
+What:           /sys/devices/.../sun
 Date:           October 2012
 Contact:        Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
 Description:
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 2447698aed41..468e4d48f884 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -144,6 +144,21 @@ Description:	Discover and change clock speed of CPUs
                to learn how to control the knobs.
+What:           /sys/devices/system/cpu/cpu#/cpufreq/freqdomain_cpus
+Date:           June 2013
+Contact:        cpufreq@vger.kernel.org
+Description:    Discover CPUs in the same CPU frequency coordination domain
+                freqdomain_cpus is the list of CPUs (online+offline) that share
+                the same clock/freq domain (possibly at the hardware level).
+                That information may be hidden from the cpufreq core and the
+                value of related_cpus may be different from freqdomain_cpus. This
+                attribute is useful for user space DVFS controllers to get better
+                power/performance results for platforms using acpi-cpufreq.
+                This file is only present if the acpi-cpufreq driver is in use.
 What:           /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
 Date:           August 2008
 KernelVersion:  2.6.27
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
index 3d98009f447a..ed5dd567d397 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-wiimote
+++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
@@ -12,7 +12,7 @@ Description:	Make it possible to set/get current led state. Reading from it
 What:           /sys/bus/hid/drivers/wiimote/<dev>/extension
 Date:           August 2011
 KernelVersion:  3.2
-Contact:        David Herrmann <dh.herrmann@googlemail.com>
+Contact:        David Herrmann <dh.herrmann@gmail.com>
 Description:    This file contains the currently connected and initialized
                extensions. It can be one of: none, motionp, nunchuck, classic,
                motionp+nunchuck, motionp+classic
@@ -20,3 +20,40 @@ Description:	This file contains the currently connected and initialized
                the official Nintendo Nunchuck extension and classic is the
                Nintendo Classic Controller extension. The motionp extension can
                be combined with the other two.
+                Starting with kernel-version 3.11 Motion Plus hotplugging is
+                supported and if detected, it's no longer reported as static
+                extension. You will get uevent notifications for the motion-plus
+                device then.
+What:           /sys/bus/hid/drivers/wiimote/<dev>/devtype
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        David Herrmann <dh.herrmann@gmail.com>
+Description:    While a device is initialized by the wiimote driver, we perform
+                a device detection and signal a "change" uevent after it is
+                done. This file shows the detected device type. "pending" means
+                that the detection is still ongoing, "unknown" means, that the
+                device couldn't be detected or loaded. "generic" means, that the
+                device couldn't be detected but supports basic Wii Remote
+                features and can be used.
+                Other strings for each device-type are available and may be
+                added if new device-specific detections are added.
+                Currently supported are:
+                        gen10: First Wii Remote generation
+                        gen20: Second Wii Remote Plus generation (builtin MP)
+                        balanceboard: Wii Balance Board
+What:           /sys/bus/hid/drivers/wiimote/<dev>/bboard_calib
+Date:           May 2013
+KernelVersion:  3.11
+Contact:        David Herrmann <dh.herrmann@gmail.com>
+Description:    This attribute is only provided if the device was detected as a
+                balance board. It provides a single line with 3 calibration
+                values for all 4 sensors. The values are separated by colons and
+                are each 2 bytes long (encoded as 4 digit hexadecimal value).
+                First, 0kg values for all 4 sensors are written, followed by the
+                17kg values for all 4 sensors and last the 34kg values for all 4
+                sensors.
+                Calibration data is already applied by the kernel to all input
+                values but may be used by user-space to perform other
+                transformations.
diff --git a/Documentation/ABI/testing/sysfs-firmware-acpi b/Documentation/ABI/testing/sysfs-firmware-acpi
index ce9bee98b43b..b4436cca97a8 100644
--- a/Documentation/ABI/testing/sysfs-firmware-acpi
+++ b/Documentation/ABI/testing/sysfs-firmware-acpi
@@ -44,6 +44,16 @@ Description:
                or 0 (unset).  Attempts to write any other values to it will
                cause -EINVAL to be returned.
+What:           /sys/firmware/acpi/hotplug/force_remove
+Date:           May 2013
+Contact:        Rafael J. Wysocki <rafael.j.wysocki@intel.com>
+Description:
+                The number in this file (0 or 1) determines whether (1) or not
+                (0) the ACPI subsystem will allow devices to be hot-removed even
+                if they cannot be put offline gracefully (from the kernel's
+                viewpoint).  That number can be changed by writing a boolean
+                value to this file.
 What:           /sys/firmware/acpi/interrupts/
 Date:           February 2008
 Contact:        Len Brown <lenb@kernel.org>
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index e00b8f0dde52..7fe0546c504a 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -389,7 +389,8 @@ Albeit deprecated by some people, the equivalent of the goto statement is
 used frequently by compilers in form of the unconditional jump instruction.
 The goto statement comes in handy when a function exits from multiple
-locations and some common work such as cleanup has to be done.
+locations and some common work such as cleanup has to be done.  If there is no
+cleanup needed then just return directly.
 The rationale is:
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index 0f6a3edcd44b..49267ea97568 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -127,14 +127,11 @@
 !Finclude/net/cfg80211.h cfg80211_ibss_params
 !Finclude/net/cfg80211.h cfg80211_connect_params
 !Finclude/net/cfg80211.h cfg80211_pmksa
-!Finclude/net/cfg80211.h cfg80211_send_rx_auth
+!Finclude/net/cfg80211.h cfg80211_rx_mlme_mgmt
-!Finclude/net/cfg80211.h cfg80211_send_auth_timeout
+!Finclude/net/cfg80211.h cfg80211_auth_timeout
-!Finclude/net/cfg80211.h cfg80211_send_rx_assoc
+!Finclude/net/cfg80211.h cfg80211_rx_assoc_resp
-!Finclude/net/cfg80211.h cfg80211_send_assoc_timeout
+!Finclude/net/cfg80211.h cfg80211_assoc_timeout
-!Finclude/net/cfg80211.h cfg80211_send_deauth
+!Finclude/net/cfg80211.h cfg80211_tx_mlme_mgmt
-!Finclude/net/cfg80211.h __cfg80211_send_deauth
-!Finclude/net/cfg80211.h cfg80211_send_disassoc
-!Finclude/net/cfg80211.h __cfg80211_send_disassoc
 !Finclude/net/cfg80211.h cfg80211_ibss_joined
 !Finclude/net/cfg80211.h cfg80211_connect_result
 !Finclude/net/cfg80211.h cfg80211_roamed
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index c36892c072da..cbfdf5486639 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -126,6 +126,8 @@ X!Edrivers/base/interface.c
     </sect1>
     <sect1><title>Device Drivers DMA Management</title>
 !Edrivers/base/dma-buf.c
+!Edrivers/base/reservation.c
+!Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
 !Edrivers/base/dma-mapping.c
     </sect1>
@@ -297,10 +299,10 @@ KAO -->
     </sect1>
     <sect1><title>Frame Buffer Fonts</title>
        <para>
-           Refer to the file drivers/video/console/fonts.c for more information.
+           Refer to the file lib/fonts/fonts.c for more information.
        </para>
 <!-- FIXME: Removed for now since no structured comments in source
-X!Idrivers/video/console/fonts.c
+X!Ilib/fonts/fonts.c
 -->
     </sect1>
  </chapter>
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index f9df3b872c16..7d1278e7a434 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -186,11 +186,12 @@
          <varlistentry>
            <term>DRIVER_HAVE_IRQ</term><term>DRIVER_IRQ_SHARED</term>
            <listitem><para>
-              DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler. The
+              DRIVER_HAVE_IRQ indicates whether the driver has an IRQ handler
-              DRM core will automatically register an interrupt handler when the
+              managed by the DRM Core. The core will support simple IRQ handler
-              flag is set. DRIVER_IRQ_SHARED indicates whether the device &amp;
+              installation when the flag is set. The installation process is
-              handler support shared IRQs (note that this is required of PCI
+              described in <xref linkend="drm-irq-registration"/>.</para>
-              drivers).
+              <para>DRIVER_IRQ_SHARED indicates whether the device &amp; handler
+              support shared IRQs (note that this is required of PCI  drivers).
            </para></listitem>
          </varlistentry>
          <varlistentry>
@@ -344,50 +345,71 @@ char *date;</synopsis>
          The DRM core tries to facilitate IRQ handler registration and
          unregistration by providing <function>drm_irq_install</function> and
          <function>drm_irq_uninstall</function> functions. Those functions only
-          support a single interrupt per device.
+          support a single interrupt per device, devices that use more than one
-        </para>
+          IRQs need to be handled manually.
-  <!--!Fdrivers/char/drm/drm_irq.c drm_irq_install-->
-        <para>
-          Both functions get the device IRQ by calling
-          <function>drm_dev_to_irq</function>. This inline function will call a
-          bus-specific operation to retrieve the IRQ number. For platform devices,
-          <function>platform_get_irq</function>(..., 0) is used to retrieve the
-          IRQ number.
-        </para>
-        <para>
-          <function>drm_irq_install</function> starts by calling the
-          <methodname>irq_preinstall</methodname> driver operation. The operation
-          is optional and must make sure that the interrupt will not get fired by
-          clearing all pending interrupt flags or disabling the interrupt.
-        </para>
-        <para>
-          The IRQ will then be requested by a call to
-          <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
-          feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
-          requested.
-        </para>
-        <para>
-          The IRQ handler function must be provided as the mandatory irq_handler
-          driver operation. It will get passed directly to
-          <function>request_irq</function> and thus has the same prototype as all
-          IRQ handlers. It will get called with a pointer to the DRM device as the
-          second argument.
-        </para>
-        <para>
-          Finally the function calls the optional
-          <methodname>irq_postinstall</methodname> driver operation. The operation
-          usually enables interrupts (excluding the vblank interrupt, which is
-          enabled separately), but drivers may choose to enable/disable interrupts
-          at a different time.
-        </para>
-        <para>
-          <function>drm_irq_uninstall</function> is similarly used to uninstall an
-          IRQ handler. It starts by waking up all processes waiting on a vblank
-          interrupt to make sure they don't hang, and then calls the optional
-          <methodname>irq_uninstall</methodname> driver operation. The operation
-          must disable all hardware interrupts. Finally the function frees the IRQ
-          by calling <function>free_irq</function>.
        </para>
+        <sect4>
+          <title>Managed IRQ Registration</title>
+          <para>
+            Both the <function>drm_irq_install</function> and
+            <function>drm_irq_uninstall</function> functions get the device IRQ by
+            calling <function>drm_dev_to_irq</function>. This inline function will
+            call a bus-specific operation to retrieve the IRQ number. For platform
+            devices, <function>platform_get_irq</function>(..., 0) is used to
+            retrieve the IRQ number.
+          </para>
+          <para>
+            <function>drm_irq_install</function> starts by calling the
+            <methodname>irq_preinstall</methodname> driver operation. The operation
+            is optional and must make sure that the interrupt will not get fired by
+            clearing all pending interrupt flags or disabling the interrupt.
+          </para>
+          <para>
+            The IRQ will then be requested by a call to
+            <function>request_irq</function>. If the DRIVER_IRQ_SHARED driver
+            feature flag is set, a shared (IRQF_SHARED) IRQ handler will be
+            requested.
+          </para>
+          <para>
+            The IRQ handler function must be provided as the mandatory irq_handler
+            driver operation. It will get passed directly to
+            <function>request_irq</function> and thus has the same prototype as all
+            IRQ handlers. It will get called with a pointer to the DRM device as the
+            second argument.
+          </para>
+          <para>
+            Finally the function calls the optional
+            <methodname>irq_postinstall</methodname> driver operation. The operation
+            usually enables interrupts (excluding the vblank interrupt, which is
+            enabled separately), but drivers may choose to enable/disable interrupts
+            at a different time.
+          </para>
+          <para>
+            <function>drm_irq_uninstall</function> is similarly used to uninstall an
+            IRQ handler. It starts by waking up all processes waiting on a vblank
+            interrupt to make sure they don't hang, and then calls the optional
+            <methodname>irq_uninstall</methodname> driver operation. The operation
+            must disable all hardware interrupts. Finally the function frees the IRQ
+            by calling <function>free_irq</function>.
+          </para>
+        </sect4>
+        <sect4>
+          <title>Manual IRQ Registration</title>
+          <para>
+            Drivers that require multiple interrupt handlers can't use the managed
+            IRQ registration functions. In that case IRQs must be registered and
+            unregistered manually (usually with the <function>request_irq</function>
+            and <function>free_irq</function> functions, or their devm_* equivalent).
+          </para>
+          <para>
+            When manually registering IRQs, drivers must not set the DRIVER_HAVE_IRQ
+            driver feature flag, and must not provide the
+            <methodname>irq_handler</methodname> driver operation. They must set the
+            <structname>drm_device</structname> <structfield>irq_enabled</structfield>
+            field to 1 upon registration of the IRQs, and clear it to 0 after
+            unregistering the IRQs.
+          </para>
+        </sect4>
      </sect3>
      <sect3>
        <title>Memory Manager Initialization</title>
@@ -434,7 +456,7 @@ char *date;</synopsis>
      The DRM core includes two memory managers, namely Translation Table Maps
      (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory
      manager to be developed and tried to be a one-size-fits-them all
-      solution. It provides a single userspace API to accomodate the need of
+      solution. It provides a single userspace API to accommodate the need of
      all hardware, supporting both Unified Memory Architecture (UMA) devices
      and devices with dedicated video RAM (i.e. most discrete video cards).
      This resulted in a large, complex piece of code that turned out to be
@@ -701,7 +723,7 @@ char *date;</synopsis>
        <para>
          Similar to global names, GEM file descriptors are also used to share GEM
          objects across processes. They offer additional security: as file
-          descriptors must be explictly sent over UNIX domain sockets to be shared
+          descriptors must be explicitly sent over UNIX domain sockets to be shared
          between applications, they can't be guessed like the globally unique GEM
          names.
        </para>
@@ -1154,7 +1176,7 @@ int max_width, max_height;</synopsis>
          </para>
          <para>
            The <methodname>page_flip</methodname> operation schedules a page flip.
-            Once any pending rendering targetting the new frame buffer has
+            Once any pending rendering targeting the new frame buffer has
            completed, the CRTC will be reprogrammed to display that frame buffer
            after the next vertical refresh. The operation must return immediately
            without waiting for rendering or page flip to complete and must block
@@ -1214,6 +1236,15 @@ int max_width, max_height;</synopsis>
          <title>Miscellaneous</title>
          <itemizedlist>
            <listitem>
+              <synopsis>void (*set_property)(struct drm_crtc *crtc,
+                     struct drm_property *property, uint64_t value);</synopsis>
+              <para>
+                Set the value of the given CRTC property to
+                <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
+                for more information about properties.
+              </para>
+            </listitem>
+            <listitem>
              <synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
                        uint32_t start, uint32_t size);</synopsis>
              <para>
@@ -1363,6 +1394,15 @@ int max_width, max_height;</synopsis>
              <xref linkend="drm-kms-init"/>.
            </para>
          </listitem>
+          <listitem>
+            <synopsis>void (*set_property)(struct drm_plane *plane,
+                     struct drm_property *property, uint64_t value);</synopsis>
+            <para>
+              Set the value of the given plane property to
+              <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
+              for more information about properties.
+            </para>
+          </listitem>
        </itemizedlist>
      </sect3>
    </sect2>
@@ -1572,6 +1612,15 @@ int max_width, max_height;</synopsis>
          <title>Miscellaneous</title>
          <itemizedlist>
            <listitem>
+              <synopsis>void (*set_property)(struct drm_connector *connector,
+                     struct drm_property *property, uint64_t value);</synopsis>
+              <para>
+                Set the value of the given connector property to
+                <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
+                for more information about properties.
+              </para>
+            </listitem>
+            <listitem>
              <synopsis>void (*destroy)(struct drm_connector *connector);</synopsis>
              <para>
                Destroy the connector when not needed anymore. See
@@ -1846,10 +1895,6 @@ void intel_crt_init(struct drm_device *dev)
          <synopsis>bool (*mode_fixup)(struct drm_encoder *encoder,
                       const struct drm_display_mode *mode,
                       struct drm_display_mode *adjusted_mode);</synopsis>
-          <note><para>
-            FIXME: The mode argument be const, but the i915 driver modifies
-            mode-&gt;clock in <function>intel_dp_mode_fixup</function>.
-          </para></note>
          <para>
            Let encoders adjust the requested mode or reject it completely. This
            operation returns true if the mode is accepted (possibly after being
@@ -2161,6 +2206,128 @@ void intel_crt_init(struct drm_device *dev)
      <title>EDID Helper Functions Reference</title>
 !Edrivers/gpu/drm/drm_edid.c
    </sect2>
+    <sect2>
+      <title>Rectangle Utilities Reference</title>
+!Pinclude/drm/drm_rect.h rect utils
+!Iinclude/drm/drm_rect.h
+!Edrivers/gpu/drm/drm_rect.c
+    </sect2>
+  </sect1>
+  <!-- Internals: kms properties -->
+  <sect1 id="drm-kms-properties">
+    <title>KMS Properties</title>
+    <para>
+      Drivers may need to expose additional parameters to applications than
+      those described in the previous sections. KMS supports attaching
+      properties to CRTCs, connectors and planes and offers a userspace API to
+      list, get and set the property values.
+    </para>
+    <para>
+      Properties are identified by a name that uniquely defines the property
+      purpose, and store an associated value. For all property types except blob
+      properties the value is a 64-bit unsigned integer.
+    </para>
+    <para>
+      KMS differentiates between properties and property instances. Drivers
+      first create properties and then create and associate individual instances
+      of those properties to objects. A property can be instantiated multiple
+      times and associated with different objects. Values are stored in property
+      instances, and all other property information are stored in the propery
+      and shared between all instances of the property.
+    </para>
+    <para>
+      Every property is created with a type that influences how the KMS core
+      handles the property. Supported property types are
+      <variablelist>
+        <varlistentry>
+          <term>DRM_MODE_PROP_RANGE</term>
+          <listitem><para>Range properties report their minimum and maximum
+            admissible values. The KMS core verifies that values set by
+            application fit in that range.</para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>DRM_MODE_PROP_ENUM</term>
+          <listitem><para>Enumerated properties take a numerical value that
+            ranges from 0 to the number of enumerated values defined by the
+            property minus one, and associate a free-formed string name to each
+            value. Applications can retrieve the list of defined value-name pairs
+            and use the numerical value to get and set property instance values.
+            </para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>DRM_MODE_PROP_BITMASK</term>
+          <listitem><para>Bitmask properties are enumeration properties that
+            additionally restrict all enumerated values to the 0..63 range.
+            Bitmask property instance values combine one or more of the
+            enumerated bits defined by the property.</para></listitem>
+        </varlistentry>
+        <varlistentry>
+          <term>DRM_MODE_PROP_BLOB</term>
+          <listitem><para>Blob properties store a binary blob without any format
+            restriction. The binary blobs are created as KMS standalone objects,
+            and blob property instance values store the ID of their associated
+            blob object.</para>
+            <para>Blob properties are only used for the connector EDID property
+            and cannot be created by drivers.</para></listitem>
+        </varlistentry>
+      </variablelist>
+    </para>
+    <para>
+      To create a property drivers call one of the following functions depending
+      on the property type. All property creation functions take property flags
+      and name, as well as type-specific arguments.
+      <itemizedlist>
+        <listitem>
+          <synopsis>struct drm_property *drm_property_create_range(struct drm_device *dev, int flags,
+                                               const char *name,
+                                               uint64_t min, uint64_t max);</synopsis>
+          <para>Create a range property with the given minimum and maximum
+            values.</para>
+        </listitem>
+        <listitem>
+          <synopsis>struct drm_property *drm_property_create_enum(struct drm_device *dev, int flags,
+                                              const char *name,
+                                              const struct drm_prop_enum_list *props,
+                                              int num_values);</synopsis>
+          <para>Create an enumerated property. The <parameter>props</parameter>
+            argument points to an array of <parameter>num_values</parameter>
+            value-name pairs.</para>
+        </listitem>
+        <listitem>
+          <synopsis>struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
+                                                 int flags, const char *name,
+                                                 const struct drm_prop_enum_list *props,
+                                                 int num_values);</synopsis>
+          <para>Create a bitmask property. The <parameter>props</parameter>
+            argument points to an array of <parameter>num_values</parameter>
+            value-name pairs.</para>
+        </listitem>
+      </itemizedlist>
+    </para>
+    <para>
+      Properties can additionally be created as immutable, in which case they
+      will be read-only for applications but can be modified by the driver. To
+      create an immutable property drivers must set the DRM_MODE_PROP_IMMUTABLE
+      flag at property creation time.
+    </para>
+    <para>
+      When no array of value-name pairs is readily available at property
+      creation time for enumerated or range properties, drivers can create
+      the property using the <function>drm_property_create</function> function
+      and manually add enumeration value-name pairs by calling the
+      <function>drm_property_add_enum</function> function. Care must be taken to
+      properly specify the property type through the <parameter>flags</parameter>
+      argument.
+    </para>
+    <para>
+      After creating properties drivers can attach property instances to CRTC,
+      connector and plane objects by calling the
+      <function>drm_object_attach_property</function>. The function takes a
+      pointer to the target object, a pointer to the previously created property
+      and an initial instance value.
+    </para>
  </sect1>
  <!-- Internals: vertical blanking -->
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl
index b3422341d65c..d16d21b7a3b7 100644
--- a/Documentation/DocBook/genericirq.tmpl
+++ b/Documentation/DocBook/genericirq.tmpl
@@ -464,6 +464,19 @@ if (desc->irq_data.chip->irq_eoi)
        protected via desc->lock, by the generic layer.
     </para>
  </chapter>
+  <chapter id="genericchip">
+     <title>Generic interrupt chip</title>
+     <para>
+       To avoid copies of identical implementations of irq chips the
+       core provides a configurable generic interrupt chip
+       implementation. Developers should check carefuly whether the
+       generic chip fits their needs before implementing the same
+       functionality slightly different themself.
+     </para>
+!Ekernel/irq/generic-chip.c
+  </chapter>
  <chapter id="structs">
     <title>Structures</title>
     <para>
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 67e7ab41c0a6..09e884e5b9f5 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1955,12 +1955,17 @@ machines due to caching.
   </sect1>
  </chapter>
-  <chapter id="apiref">
+  <chapter id="apiref-mutex">
   <title>Mutex API reference</title>
 !Iinclude/linux/mutex.h
 !Ekernel/mutex.c
  </chapter>
+  <chapter id="apiref-futex">
+   <title>Futex API reference</title>
+!Ikernel/futex.c
+  </chapter>
  <chapter id="references">
   <title>Further reading</title>
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml
index df39ba395df0..0d6e81bd9ed2 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -233,7 +233,7 @@ typedef enum fe_status {
 <entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
 </row><row>
 <entry align="char">FE_HAS_SYNC</entry>
-<entry align="char">Syncronization bytes was found</entry>
+<entry align="char">Synchronization bytes was found</entry>
 </row><row>
 <entry align="char">FE_HAS_LOCK</entry>
 <entry align="char">The DVB were locked and everything is working</entry>
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 8d7a77928d49..c2fc9ec1417e 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3147,7 +3147,7 @@ giving priority to the center of the metered area.</entry>
                  <entry>A multi-zone metering. The light intensity is measured
 in several points of the frame and the the results are combined. The
 algorithm of the zones selection and their significance in calculating the
-final value is device dependant.</entry>
+final value is device dependent.</entry>
                </row>
              </tbody>
            </entrytbl>
diff --git a/Documentation/DocBook/media/v4l/dev-codec.xml b/Documentation/DocBook/media/v4l/dev-codec.xml
index dca0ecd54dc6..ff44c16fc080 100644
--- a/Documentation/DocBook/media/v4l/dev-codec.xml
+++ b/Documentation/DocBook/media/v4l/dev-codec.xml
@@ -1,18 +1,27 @@
  <title>Codec Interface</title>
-  <note>
+  <para>A V4L2 codec can compress, decompress, transform, or otherwise
-    <title>Suspended</title>
+convert video data from one format into another format, in memory. Typically
+such devices are memory-to-memory devices (i.e. devices with the
+<constant>V4L2_CAP_VIDEO_M2M</constant> or <constant>V4L2_CAP_VIDEO_M2M_MPLANE</constant>
+capability set).
+</para>
-    <para>This interface has been be suspended from the V4L2 API
+  <para>A memory-to-memory video node acts just like a normal video node, but it
-implemented in Linux 2.6 until we have more experience with codec
+supports both output (sending frames from memory to the codec hardware) and
-device interfaces.</para>
+capture (receiving the processed frames from the codec hardware into memory)
-  </note>
+stream I/O. An application will have to setup the stream
+I/O for both sides and finally call &VIDIOC-STREAMON; for both capture and output
+to start the codec.</para>
-  <para>A V4L2 codec can compress, decompress, transform, or otherwise
+  <para>Video compression codecs use the MPEG controls to setup their codec parameters
-convert video data from one format into another format, in memory.
+(note that the MPEG controls actually support many more codecs than just MPEG).
-Applications send data to be converted to the driver through a
+See <xref linkend="mpeg-controls"></xref>.</para>
-&func-write; call, and receive the converted data through a
-&func-read; call. For efficiency a driver may also support streaming
-I/O.</para>
-  <para>[to do]</para>
+  <para>Memory-to-memory devices can often be used as a shared resource: you can
+open the video node multiple times, each application setting up their own codec properties
+that are local to the file handle, and each can use it independently from the others.
+The driver will arbitrate access to the codec and reprogram it whenever another file
+handler gets access. This is different from the usual video node behavior where the video properties
+are global to the device (i.e. changing something through one file handle is visible
+through another file handle).</para>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
index 2f82b1da8dfe..8a70a1707b7a 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12mt.xml
@@ -24,7 +24,7 @@ into 64x32 macroblocks. The CbCr plane has the same width, in bytes, as the Y
 plane (and the image), but is half as tall in pixels. The chroma plane is also
 grouped into 64x32 macroblocks.</para>
        <para>Width of the buffer has to be aligned to the multiple of 128, and
-height alignment is 32. Every four adjactent buffers - two horizontally and two
+height alignment is 32. Every four adjacent buffers - two horizontally and two
 vertically are grouped together and are located in memory in Z or flipped Z
 order. </para>
        <para>Layout of macroblocks in memory is presented in the following
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index bfc93cdcf696..bfe823dd0f31 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -493,7 +493,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.9</subtitle>
+ <subtitle>Revision 3.10</subtitle>
  <chapter id="common">
    &sub-common;
diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl
index bd97a13fa5ae..3210dcf741c9 100644
--- a/Documentation/DocBook/writing_usb_driver.tmpl
+++ b/Documentation/DocBook/writing_usb_driver.tmpl
@@ -83,7 +83,7 @@
  </para>
  <para>
      Because each different protocol causes a new driver to be created, I have
-      written a generic USB driver skeleton, modeled after the pci-skeleton.c
+      written a generic USB driver skeleton, modelled after the pci-skeleton.c
      file in the kernel source tree upon which many PCI network drivers have
      been based. This USB skeleton can be found at drivers/usb/usb-skeleton.c
      in the kernel source tree. In this article I will walk through the basics
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index a9f288ff54f9..27faae3e3846 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://userweb.kernel.org/~akpm/stuff/tpp.txt
+                http://kerneltrap.org/node/3737
        "Linux kernel patch submission format"
                http://linux.yyz.us/patch-format.html
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 79e789b8b8ea..7703ec73a9bb 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -354,12 +354,6 @@ over a rather long period of time, but improvements are always welcome!
        using RCU rather than SRCU, because RCU is almost always faster
        and easier to use than is SRCU.
-        If you need to enter your read-side critical section in a
-        hardirq or exception handler, and then exit that same read-side
-        critical section in the task that was interrupted, then you need
-        to srcu_read_lock_raw() and srcu_read_unlock_raw(), which avoid
-        the lockdep checking that would otherwise this practice illegal.
        Also unlike other forms of RCU, explicit initialization
        and cleanup is required via init_srcu_struct() and
        cleanup_srcu_struct().  These are passed a "struct srcu_struct"
diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt
index 7dce8a17eac2..d8a502387397 100644
--- a/Documentation/RCU/torture.txt
+++ b/Documentation/RCU/torture.txt
@@ -182,12 +182,6 @@ torture_type	The type of RCU to test, with string values as follows:
                "srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
                        synchronize_srcu_expedited().
-                "srcu_raw": srcu_read_lock_raw(), srcu_read_unlock_raw(),
-                        and call_srcu().
-                "srcu_raw_sync": srcu_read_lock_raw(), srcu_read_unlock_raw(),
-                        and synchronize_srcu().
                "sched": preempt_disable(), preempt_enable(), and
                        call_rcu_sched().
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
index c776968f4463..f3778f8952da 100644
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@@ -530,113 +530,21 @@ o	"nos" counts the number of times we balked for other
        reasons, e.g., the grace period ended first.
-CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
+CONFIG_TINY_RCU debugfs Files and Formats
 These implementations of RCU provides a single debugfs file under the
 top-level directory RCU, namely rcu/rcudata, which displays fields in
-rcu_bh_ctrlblk, rcu_sched_ctrlblk and, for CONFIG_TINY_PREEMPT_RCU,
+rcu_bh_ctrlblk and rcu_sched_ctrlblk.
-rcu_preempt_ctrlblk.
 The output of "cat rcu/rcudata" is as follows:
-rcu_preempt: qlen=24 gp=1097669 g197/p197/c197 tasks=...
-             ttb=. btg=no ntb=184 neb=0 nnb=183 j=01f7 bt=0274
-             normal balk: nt=1097669 gt=0 bt=371 b=0 ny=25073378 nos=0
-             exp balk: bt=0 nos=0
 rcu_sched: qlen: 0
 rcu_bh: qlen: 0
-This is split into rcu_preempt, rcu_sched, and rcu_bh sections, with the
+This is split into rcu_sched and rcu_bh sections.  The field is as
-rcu_preempt section appearing only in CONFIG_TINY_PREEMPT_RCU builds.
+follows:
-The last three lines of the rcu_preempt section appear only in
-CONFIG_RCU_BOOST kernel builds.  The fields are as follows:
 o       "qlen" is the number of RCU callbacks currently waiting either
        for an RCU grace period or waiting to be invoked.  This is the
        only field present for rcu_sched and rcu_bh, due to the
        short-circuiting of grace period in those two cases.
-o       "gp" is the number of grace periods that have completed.
-o       "g197/p197/c197" displays the grace-period state, with the
-        "g" number being the number of grace periods that have started
-        (mod 256), the "p" number being the number of grace periods
-        that the CPU has responded to (also mod 256), and the "c"
-        number being the number of grace periods that have completed
-        (once again mode 256).
-        Why have both "gp" and "g"?  Because the data flowing into
-        "gp" is only present in a CONFIG_RCU_TRACE kernel.
-o       "tasks" is a set of bits.  The first bit is "T" if there are
-        currently tasks that have recently blocked within an RCU
-        read-side critical section, the second bit is "N" if any of the
-        aforementioned tasks are blocking the current RCU grace period,
-        and the third bit is "E" if any of the aforementioned tasks are
-        blocking the current expedited grace period.  Each bit is "."
-        if the corresponding condition does not hold.
-o       "ttb" is a single bit.  It is "B" if any of the blocked tasks
-        need to be priority boosted and "." otherwise.
-o       "btg" indicates whether boosting has been carried out during
-        the current grace period, with "exp" indicating that boosting
-        is in progress for an expedited grace period, "no" indicating
-        that boosting has not yet started for a normal grace period,
-        "begun" indicating that boosting has bebug for a normal grace
-        period, and "done" indicating that boosting has completed for
-        a normal grace period.
-o       "ntb" is the total number of tasks subjected to RCU priority boosting
-        periods since boot.
-o       "neb" is the number of expedited grace periods that have had
-        to resort to RCU priority boosting since boot.
-o       "nnb" is the number of normal grace periods that have had
-        to resort to RCU priority boosting since boot.
-o       "j" is the low-order 16 bits of the jiffies counter in hexadecimal.
-o       "bt" is the low-order 16 bits of the value that the jiffies counter
-        will have at the next time that boosting is scheduled to begin.
-o       In the line beginning with "normal balk", the fields are as follows:
-        o       "nt" is the number of times that the system balked from
-                boosting because there were no blocked tasks to boost.
-                Note that the system will balk from boosting even if the
-                grace period is overdue when the currently running task
-                is looping within an RCU read-side critical section.
-                There is no point in boosting in this case, because
-                boosting a running task won't make it run any faster.
-        o       "gt" is the number of times that the system balked
-                from boosting because, although there were blocked tasks,
-                none of them were preventing the current grace period
-                from completing.
-        o       "bt" is the number of times that the system balked
-                from boosting because boosting was already in progress.
-        o       "b" is the number of times that the system balked from
-                boosting because boosting had already completed for
-                the grace period in question.
-        o       "ny" is the number of times that the system balked from
-                boosting because it was not yet time to start boosting
-                the grace period in question.
-        o       "nos" is the number of times that the system balked from
-                boosting for inexplicable ("not otherwise specified")
-                reasons.  This can actually happen due to races involving
-                increments of the jiffies counter.
-o       In the line beginning with "exp balk", the fields are as follows:
-        o       "bt" is the number of times that the system balked from
-                boosting because there were no blocked tasks to boost.
-        o       "nos" is the number of times that the system balked from
-                 boosting for inexplicable ("not otherwise specified")
-                 reasons.
diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt
index 10df0b82f459..0f0fb7c432c2 100644
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -842,9 +842,7 @@ SRCU:	Critical sections	Grace period		Barrier
        srcu_read_lock          synchronize_srcu        srcu_barrier
        srcu_read_unlock        call_srcu
-        srcu_read_lock_raw      synchronize_srcu_expedited
+        srcu_dereference        synchronize_srcu_expedited
-        srcu_read_unlock_raw
-        srcu_dereference
 SRCU:   Initialization/cleanup
        init_srcu_struct
@@ -865,38 +863,32 @@ list can be helpful:
 a.      Will readers need to block?  If so, you need SRCU.
-b.      Is it necessary to start a read-side critical section in a
+b.      What about the -rt patchset?  If readers would need to block
-        hardirq handler or exception handler, and then to complete
-        this read-side critical section in the task that was
-        interrupted?  If so, you need SRCU's srcu_read_lock_raw() and
-        srcu_read_unlock_raw() primitives.
-c.      What about the -rt patchset?  If readers would need to block
        in an non-rt kernel, you need SRCU.  If readers would block
        in a -rt kernel, but not in a non-rt kernel, SRCU is not
        necessary.
-d.      Do you need to treat NMI handlers, hardirq handlers,
+c.      Do you need to treat NMI handlers, hardirq handlers,
        and code segments with preemption disabled (whether
        via preempt_disable(), local_irq_save(), local_bh_disable(),
        or some other mechanism) as if they were explicit RCU readers?
        If so, RCU-sched is the only choice that will work for you.
-e.      Do you need RCU grace periods to complete even in the face
+d.      Do you need RCU grace periods to complete even in the face
        of softirq monopolization of one or more of the CPUs?  For
        example, is your code subject to network-based denial-of-service
        attacks?  If so, you need RCU-bh.
-f.      Is your workload too update-intensive for normal use of
+e.      Is your workload too update-intensive for normal use of
        RCU, but inappropriate for other synchronization mechanisms?
        If so, consider SLAB_DESTROY_BY_RCU.  But please be careful!
-g.      Do you need read-side critical sections that are respected
+f.      Do you need read-side critical sections that are respected
        even though they are in the middle of the idle loop, during
        user-mode execution, or on an offlined CPU?  If so, SRCU is the
        only choice that will work for you.
-h.      Otherwise, use RCU.
+g.      Otherwise, use RCU.
 Of course, this all assumes that you have determined that RCU is in fact
 the right tool for your job.
diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
index dc0e33210d7e..2b7e32dfe00d 100644
--- a/Documentation/SubmitChecklist
+++ b/Documentation/SubmitChecklist
@@ -105,5 +105,5 @@ kernel patches.
    same time, just various/random combinations of them]:
    CONFIG_SMP, CONFIG_SYSFS, CONFIG_PROC_FS, CONFIG_INPUT, CONFIG_PCI,
-    CONFIG_BLOCK, CONFIG_PM, CONFIG_HOTPLUG, CONFIG_MAGIC_SYSRQ,
+    CONFIG_BLOCK, CONFIG_PM, CONFIG_MAGIC_SYSRQ,
    CONFIG_NET, CONFIG_INET=n (but latter with CONFIG_NET=y)
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index f8ebcde43b17..c6a06b71594d 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -272,7 +272,7 @@ int main(int argc, char *argv[])
        char *logfile = NULL;
        int loop = 0;
        int containerset = 0;
-        char containerpath[1024];
+        char *containerpath = NULL;
        int cfd = 0;
        int forking = 0;
        sigset_t sigset;
@@ -299,7 +299,7 @@ int main(int argc, char *argv[])
                        break;
                case 'C':
                        containerset = 1;
-                        strncpy(containerpath, optarg, strlen(optarg) + 1);
+                        containerpath = optarg;
                        break;
                case 'w':
                        logfile = strdup(optarg);
diff --git a/Documentation/acpi/apei/einj.txt b/Documentation/acpi/apei/einj.txt
index e20b6daaced4..a58b63da1a36 100644
--- a/Documentation/acpi/apei/einj.txt
+++ b/Documentation/acpi/apei/einj.txt
@@ -47,11 +47,16 @@ directory apei/einj. The following files are provided.
 - param1
  This file is used to set the first error parameter value. Effect of
-  parameter depends on error_type specified.
+  parameter depends on error_type specified. For example, if error
+  type is memory related type, the param1 should be a valid physical
+  memory address.
 - param2
  This file is used to set the second error parameter value. Effect of
-  parameter depends on error_type specified.
+  parameter depends on error_type specified. For example, if error
+  type is memory related type, the param2 should be a physical memory
+  address mask. Linux requires page or narrower granularity, say,
+  0xfffffffffffff000.
 - notrigger
  The EINJ mechanism is a two step process. First inject the error, then
diff --git a/Documentation/acpi/namespace.txt b/Documentation/acpi/namespace.txt
new file mode 100644
index 000000000000..260f6a3661fa
--- /dev/null
+++ b/Documentation/acpi/namespace.txt
@@ -0,0 +1,395 @@
+ACPI Device Tree - Representation of ACPI Namespace
+Copyright (C) 2013, Intel Corporation
+Author: Lv Zheng <lv.zheng@intel.com>
+Abstract:
+The Linux ACPI subsystem converts ACPI namespace objects into a Linux
+device tree under the /sys/devices/LNXSYSTEM:00 and updates it upon
+receiving ACPI hotplug notification events.  For each device object in this
+hierarchy there is a corresponding symbolic link in the
+/sys/bus/acpi/devices.
+This document illustrates the structure of the ACPI device tree.
+Credit:
+Thanks for the help from Zhang Rui <rui.zhang@intel.com> and Rafael J.
+Wysocki <rafael.j.wysocki@intel.com>.
+1. ACPI Definition Blocks
+   The ACPI firmware sets up RSDP (Root System Description Pointer) in the
+   system memory address space pointing to the XSDT (Extended System
+   Description Table).  The XSDT always points to the FADT (Fixed ACPI
+   Description Table) using its first entry, the data within the FADT
+   includes various fixed-length entries that describe fixed ACPI features
+   of the hardware.  The FADT contains a pointer to the DSDT
+   (Differentiated System Descripition Table).  The XSDT also contains
+   entries pointing to possibly multiple SSDTs (Secondary System
+   Description Table).
+   The DSDT and SSDT data is organized in data structures called definition
+   blocks that contain definitions of various objects, including ACPI
+   control methods, encoded in AML (ACPI Machine Language).  The data block
+   of the DSDT along with the contents of SSDTs represents a hierarchical
+   data structure called the ACPI namespace whose topology reflects the
+   structure of the underlying hardware platform.
+   The relationships between ACPI System Definition Tables described above
+   are illustrated in the following diagram.
+     +---------+    +-------+    +--------+    +------------------------+
+     |  RSDP   | +->| XSDT  | +->|  FADT  |    |  +-------------------+ |
+     +---------+ |  +-------+ |  +--------+  +-|->|       DSDT        | |
+     | Pointer | |  | Entry |-+  | ...... |  | |  +-------------------+ |
+     +---------+ |  +-------+    | X_DSDT |--+ |  | Definition Blocks | |
+     | Pointer |-+  | ..... |    | ...... |    |  +-------------------+ |
+     +---------+    +-------+    +--------+    |  +-------------------+ |
+                    | Entry |------------------|->|       SSDT        | |
+                    +- - - -+                  |  +-------------------| |
+                    | Entry | - - - - - - - -+ |  | Definition Blocks | |
+                    +- - - -+                | |  +-------------------+ |
+                                             | |  +- - - - - - - - - -+ |
+                                             +-|->|       SSDT        | |
+                                               |  +-------------------+ |
+                                               |  | Definition Blocks | |
+                                               |  +- - - - - - - - - -+ |
+                                               +------------------------+
+                                                           |
+                                              OSPM Loading |
+                                                          \|/
+                                                    +----------------+
+                                                    | ACPI Namespace |
+                                                    +----------------+
+                     Figure 1. ACPI Definition Blocks
+   NOTE: RSDP can also contain a pointer to the RSDT (Root System
+         Description Table).  Platforms provide RSDT to enable
+         compatibility with ACPI 1.0 operating systems.  The OS is expected
+         to use XSDT, if present.
+2. Example ACPI Namespace
+   All definition blocks are loaded into a single namespace.  The namespace
+   is a hierarchy of objects identified by names and paths.
+   The following naming conventions apply to object names in the ACPI
+   namespace:
+   1. All names are 32 bits long.
+   2. The first byte of a name must be one of 'A' - 'Z', '_'.
+   3. Each of the remaining bytes of a name must be one of 'A' - 'Z', '0'
+      - '9', '_'.
+   4. Names starting with '_' are reserved by the ACPI specification.
+   5. The '\' symbol represents the root of the namespace (i.e. names
+      prepended with '\' are relative to the namespace root).
+   6. The '^' symbol represents the parent of the current namespace node
+      (i.e. names prepended with '^' are relative to the parent of the
+      current namespace node).
+   The figure below shows an example ACPI namespace.
+   +------+
+   | \    |                     Root
+   +------+
+     |
+     | +------+
+     +-| _PR  |                 Scope(_PR): the processor namespace
+     | +------+
+     |   |
+     |   | +------+
+     |   +-| CPU0 |             Processor(CPU0): the first processor
+     |     +------+
+     |
+     | +------+
+     +-| _SB  |                 Scope(_SB): the system bus namespace
+     | +------+
+     |   |
+     |   | +------+
+     |   +-| LID0 |             Device(LID0); the lid device
+     |   | +------+
+     |   |   |
+     |   |   | +------+
+     |   |   +-| _HID |         Name(_HID, "PNP0C0D"): the hardware ID
+     |   |   | +------+
+     |   |   |
+     |   |   | +------+
+     |   |   +-| _STA |         Method(_STA): the status control method
+     |   |     +------+
+     |   |
+     |   | +------+
+     |   +-| PCI0 |             Device(PCI0); the PCI root bridge
+     |     +------+
+     |       |
+     |       | +------+
+     |       +-| _HID |         Name(_HID, "PNP0A08"): the hardware ID
+     |       | +------+
+     |       |
+     |       | +------+
+     |       +-| _CID |         Name(_CID, "PNP0A03"): the compatible ID
+     |       | +------+
+     |       |
+     |       | +------+
+     |       +-| RP03 |         Scope(RP03): the PCI0 power scope
+     |       | +------+
+     |       |   |
+     |       |   | +------+
+     |       |   +-| PXP3 |     PowerResource(PXP3): the PCI0 power resource
+     |       |     +------+
+     |       |
+     |       | +------+
+     |       +-| GFX0 |         Device(GFX0): the graphics adapter
+     |         +------+
+     |           |
+     |           | +------+
+     |           +-| _ADR |     Name(_ADR, 0x00020000): the PCI bus address
+     |           | +------+
+     |           |
+     |           | +------+
+     |           +-| DD01 |     Device(DD01): the LCD output device
+     |             +------+
+     |               |
+     |               | +------+
+     |               +-| _BCL | Method(_BCL): the backlight control method
+     |                 +------+
+     |
+     | +------+
+     +-| _TZ  |                 Scope(_TZ): the thermal zone namespace
+     | +------+
+     |   |
+     |   | +------+
+     |   +-| FN00 |             PowerResource(FN00): the FAN0 power resource
+     |   | +------+
+     |   |
+     |   | +------+
+     |   +-| FAN0 |             Device(FAN0): the FAN0 cooling device
+     |   | +------+
+     |   |   |
+     |   |   | +------+
+     |   |   +-| _HID |         Name(_HID, "PNP0A0B"): the hardware ID
+     |   |     +------+
+     |   |
+     |   | +------+
+     |   +-| TZ00 |             ThermalZone(TZ00); the FAN thermal zone
+     |     +------+
+     |
+     | +------+
+     +-| _GPE |                 Scope(_GPE): the GPE namespace
+       +------+
+                     Figure 2. Example ACPI Namespace
+3. Linux ACPI Device Objects
+   The Linux kernel's core ACPI subsystem creates struct acpi_device
+   objects for ACPI namespace objects representing devices, power resources
+   processors, thermal zones.  Those objects are exported to user space via
+   sysfs as directories in the subtree under /sys/devices/LNXSYSTM:00.  The
+   format of their names is <bus_id:instance>, where 'bus_id' refers to the
+   ACPI namespace representation of the given object and 'instance' is used
+   for distinguishing different object of the same 'bus_id' (it is
+   two-digit decimal representation of an unsigned integer).
+   The value of 'bus_id' depends on the type of the object whose name it is
+   part of as listed in the table below.
+                +---+-----------------+-------+----------+
+                |   | Object/Feature  | Table | bus_id   |
+                +---+-----------------+-------+----------+
+                | N | Root            | xSDT  | LNXSYSTM |
+                +---+-----------------+-------+----------+
+                | N | Device          | xSDT  | _HID     |
+                +---+-----------------+-------+----------+
+                | N | Processor       | xSDT  | LNXCPU   |
+                +---+-----------------+-------+----------+
+                | N | ThermalZone     | xSDT  | LNXTHERM |
+                +---+-----------------+-------+----------+
+                | N | PowerResource   | xSDT  | LNXPOWER |
+                +---+-----------------+-------+----------+
+                | N | Other Devices   | xSDT  | device   |
+                +---+-----------------+-------+----------+
+                | F | PWR_BUTTON      | FADT  | LNXPWRBN |
+                +---+-----------------+-------+----------+
+                | F | SLP_BUTTON      | FADT  | LNXSLPBN |
+                +---+-----------------+-------+----------+
+                | M | Video Extension | xSDT  | LNXVIDEO |
+                +---+-----------------+-------+----------+
+                | M | ATA Controller  | xSDT  | LNXIOBAY |
+                +---+-----------------+-------+----------+
+                | M | Docking Station | xSDT  | LNXDOCK  |
+                +---+-----------------+-------+----------+
+                 Table 1. ACPI Namespace Objects Mapping
+   The following rules apply when creating struct acpi_device objects on
+   the basis of the contents of ACPI System Description Tables (as
+   indicated by the letter in the first column and the notation in the
+   second column of the table above):
+   N:
+      The object's source is an ACPI namespace node (as indicated by the
+      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
+      column), so its sysfs directory will not contain the 'path'
+      attribute.
+   M:
+      The struct acpi_device object is created for an ACPI namespace node
+      with specific control methods (as indicated by the ACPI defined
+      device's type in the second column).  The 'path' attribute containing
+      its namespace path will be present in its sysfs directory.  For
+      example, if the _BCL method is present for an ACPI namespace node, a
+      struct acpi_device object with LNXVIDEO 'bus_id' will be created for
+      it.
+   The third column of the above table indicates which ACPI System
+   Description Tables contain information used for the creation of the
+   struct acpi_device objects represented by the given row (xSDT means DSDT
+   or SSDT).
+   The forth column of the above table indicates the 'bus_id' generation
+   rule of the struct acpi_device object:
+   _HID:
+      _HID in the last column of the table means that the object's bus_id
+      is derived from the _HID/_CID identification objects present under
+      the corresponding ACPI namespace node. The object's sysfs directory
+      will then contain the 'hid' and 'modalias' attributes that can be
+      used to retrieve the _HID and _CIDs of that object.
+   LNXxxxxx:
+      The 'modalias' attribute is also present for struct acpi_device
+      objects having bus_id of the "LNXxxxxx" form (pseudo devices), in
+      which cases it contains the bus_id string itself.
+   device:
+      'device' in the last column of the table indicates that the object's
+      bus_id cannot be determined from _HID/_CID of the corresponding
+      ACPI namespace node, although that object represents a device (for
+      example, it may be a PCI device with _ADR defined and without _HID
+      or _CID).  In that case the string 'device' will be used as the
+      object's bus_id.
+4. Linux ACPI Physical Device Glue
+   ACPI device (i.e. struct acpi_device) objects may be linked to other
+   objects in the Linux' device hierarchy that represent "physical" devices
+   (for example, devices on the PCI bus).  If that happens, it means that
+   the ACPI device object is a "companion" of a device otherwise
+   represented in a different way and is used (1) to provide configuration
+   information on that device which cannot be obtained by other means and
+   (2) to do specific things to the device with the help of its ACPI
+   control methods.  One ACPI device object may be linked this way to
+   multiple "physical" devices.
+   If an ACPI device object is linked to a "physical" device, its sysfs
+   directory contains the "physical_node" symbolic link to the sysfs
+   directory of the target device object.  In turn, the target device's
+   sysfs directory will then contain the "firmware_node" symbolic link to
+   the sysfs directory of the companion ACPI device object.
+   The linking mechanism relies on device identification provided by the
+   ACPI namespace.  For example, if there's an ACPI namespace object
+   representing a PCI device (i.e. a device object under an ACPI namespace
+   object representing a PCI bridge) whose _ADR returns 0x00020000 and the
+   bus number of the parent PCI bridge is 0, the sysfs directory
+   representing the struct acpi_device object created for that ACPI
+   namespace object will contain the 'physical_node' symbolic link to the
+   /sys/devices/pci0000:00/0000:00:02:0/ sysfs directory of the
+   corresponding PCI device.
+   The linking mechanism is generally bus-specific.  The core of its
+   implementation is located in the drivers/acpi/glue.c file, but there are
+   complementary parts depending on the bus types in question located
+   elsewhere.  For example, the PCI-specific part of it is located in
+   drivers/pci/pci-acpi.c.
+5. Example Linux ACPI Device Tree
+   The sysfs hierarchy of struct acpi_device objects corresponding to the
+   example ACPI namespace illustrated in Figure 2 with the addition of
+   fixed PWR_BUTTON/SLP_BUTTON devices is shown below.
+   +--------------+---+-----------------+
+   | LNXSYSTEM:00 | \ | acpi:LNXSYSTEM: |
+   +--------------+---+-----------------+
+     |
+     | +-------------+-----+----------------+
+     +-| LNXPWRBN:00 | N/A | acpi:LNXPWRBN: |
+     | +-------------+-----+----------------+
+     |
+     | +-------------+-----+----------------+
+     +-| LNXSLPBN:00 | N/A | acpi:LNXSLPBN: |
+     | +-------------+-----+----------------+
+     |
+     | +-----------+------------+--------------+
+     +-| LNXCPU:00 | \_PR_.CPU0 | acpi:LNXCPU: |
+     | +-----------+------------+--------------+
+     |
+     | +-------------+-------+----------------+
+     +-| LNXSYBUS:00 | \_SB_ | acpi:LNXSYBUS: |
+     | +-------------+-------+----------------+
+     |   |
+     |   | +- - - - - - - +- - - - - - +- - - - - - - -+
+     |   +-| * PNP0C0D:00 | \_SB_.LID0 | acpi:PNP0C0D: |
+     |   | +- - - - - - - +- - - - - - +- - - - - - - -+
+     |   |
+     |   | +------------+------------+-----------------------+
+     |   +-| PNP0A08:00 | \_SB_.PCI0 | acpi:PNP0A08:PNP0A03: |
+     |     +------------+------------+-----------------------+
+     |       |
+     |       | +-----------+-----------------+-----+
+     |       +-| device:00 | \_SB_.PCI0.RP03 | N/A |
+     |       | +-----------+-----------------+-----+
+     |       |   |
+     |       |   | +-------------+----------------------+----------------+
+     |       |   +-| LNXPOWER:00 | \_SB_.PCI0.RP03.PXP3 | acpi:LNXPOWER: |
+     |       |     +-------------+----------------------+----------------+
+     |       |
+     |       | +-------------+-----------------+----------------+
+     |       +-| LNXVIDEO:00 | \_SB_.PCI0.GFX0 | acpi:LNXVIDEO: |
+     |         +-------------+-----------------+----------------+
+     |           |
+     |           | +-----------+-----------------+-----+
+     |           +-| device:01 | \_SB_.PCI0.DD01 | N/A |
+     |             +-----------+-----------------+-----+
+     |
+     | +-------------+-------+----------------+
+     +-| LNXSYBUS:01 | \_TZ_ | acpi:LNXSYBUS: |
+       +-------------+-------+----------------+
+         |
+         | +-------------+------------+----------------+
+         +-| LNXPOWER:0a | \_TZ_.FN00 | acpi:LNXPOWER: |
+         | +-------------+------------+----------------+
+         |
+         | +------------+------------+---------------+
+         +-| PNP0C0B:00 | \_TZ_.FAN0 | acpi:PNP0C0B: |
+         | +------------+------------+---------------+
+         |
+         | +-------------+------------+----------------+
+         +-| LNXTHERM:00 | \_TZ_.TZ00 | acpi:LNXTHERM: |
+           +-------------+------------+----------------+
+                  Figure 3. Example Linux ACPI Device Tree
+   NOTE: Each node is represented as "object/path/modalias", where:
+         1. 'object' is the name of the object's directory in sysfs.
+         2. 'path' is the ACPI namespace path of the corresponding
+            ACPI namespace object, as returned by the object's 'path'
+            sysfs attribute.
+         3. 'modalias' is the value of the object's 'modalias' sysfs
+            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/acpi/video_extension.txt b/Documentation/acpi/video_extension.txt
new file mode 100644
index 000000000000..78b32ac02466
--- /dev/null
+++ b/Documentation/acpi/video_extension.txt
@@ -0,0 +1,106 @@
+ACPI video extensions
+~~~~~~~~~~~~~~~~~~~~~
+This driver implement the ACPI Extensions For Display Adapters for
+integrated graphics devices on motherboard, as specified in ACPI 2.0
+Specification, Appendix B, allowing to perform some basic control like
+defining the video POST device, retrieving EDID information or to
+setup a video output, etc.  Note that this is an ref. implementation
+only.  It may or may not work for your integrated video device.
+The ACPI video driver does 3 things regarding backlight control:
+1 Export a sysfs interface for user space to control backlight level
+If the ACPI table has a video device, and acpi_backlight=vendor kernel
+command line is not present, the driver will register a backlight device
+and set the required backlight operation structure for it for the sysfs
+interface control. For every registered class device, there will be a
+directory named acpi_videoX under /sys/class/backlight.
+The backlight sysfs interface has a standard definition here:
+Documentation/ABI/stable/sysfs-class-backlight.
+And what ACPI video driver does is:
+actual_brightness: on read, control method _BQC will be evaluated to
+get the brightness level the firmware thinks it is at;
+bl_power: not implemented, will set the current brightness instead;
+brightness: on write, control method _BCM will run to set the requested
+brightness level;
+max_brightness: Derived from the _BCL package(see below);
+type: firmware
+Note that ACPI video backlight driver will always use index for
+brightness, actual_brightness and max_brightness. So if we have
+the following _BCL package:
+Method (_BCL, 0, NotSerialized)
+{
+        Return (Package (0x0C)
+        {
+                0x64,
+                0x32,
+                0x0A,
+                0x14,
+                0x1E,
+                0x28,
+                0x32,
+                0x3C,
+                0x46,
+                0x50,
+                0x5A,
+                0x64
+        })
+}
+The first two levels are for when laptop are on AC or on battery and are
+not used by Linux currently. The remaining 10 levels are supported levels
+that we can choose from. The applicable index values are from 0 (that
+corresponds to the 0x0A brightness value) to 9 (that corresponds to the
+0x64 brightness value) inclusive. Each of those index values is regarded
+as a "brightness level" indicator. Thus from the user space perspective
+the range of available brightness levels is from 0 to 9 (max_brightness)
+inclusive.
+2 Notify user space about hotkey event
+There are generally two cases for hotkey event reporting:
+i) For some laptops, when user presses the hotkey, a scancode will be
+   generated and sent to user space through the input device created by
+   the keyboard driver as a key type input event, with proper remap, the
+   following key code will appear to user space:
+        EV_KEY, KEY_BRIGHTNESSUP
+        EV_KEY, KEY_BRIGHTNESSDOWN
+        etc.
+For this case, ACPI video driver does not need to do anything(actually,
+it doesn't even know this happened).
+ii) For some laptops, the press of the hotkey will not generate the
+    scancode, instead, firmware will notify the video device ACPI node
+    about the event. The event value is defined in the ACPI spec. ACPI
+    video driver will generate an key type input event according to the
+    notify value it received and send the event to user space through the
+    input device it created:
+        event           keycode
+        0x86            KEY_BRIGHTNESSUP
+        0x87            KEY_BRIGHTNESSDOWN
+        etc.
+so this would lead to the same effect as case i) now.
+Once user space tool receives this event, it can modify the backlight
+level through the sysfs interface.
+3 Change backlight level in the kernel
+This works for machines covered by case ii) in Section 2. Once the driver
+received a notification, it will set the backlight level accordingly. This does
+not affect the sending of event to user space, they are always sent to user
+space regardless of whether or not the video module controls the backlight level
+directly. This behaviour can be controlled through the brightness_switch_enabled
+module parameter as documented in kernel-parameters.txt. It is recommended to
+disable this behaviour once a GUI environment starts up and wants to have full
+control of the backlight level.
diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx
index 7b9351f2f555..e48b74de6ac0 100644
--- a/Documentation/arm/IXP4xx
+++ b/Documentation/arm/IXP4xx
@@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
 - Timers (watchdog, OS)
 The following components of the chips are not supported by Linux and
-require the use of Intel's proprietary CSR softare:
+require the use of Intel's proprietary CSR software:
 - USB device interface
 - Network interfaces (HSS, Utopia, NPEs, etc)
diff --git a/Documentation/arm/sti/overview.txt b/Documentation/arm/sti/overview.txt
new file mode 100644
index 000000000000..1a4e93d6027f
--- /dev/null
+++ b/Documentation/arm/sti/overview.txt
@@ -0,0 +1,33 @@
+                        STi ARM Linux Overview
+                        ==========================
+Introduction
+------------
+  The ST Microelectronics Multimedia and Application Processors range of
+  CortexA9 System-on-Chip are supported by the 'STi' platform of
+  ARM Linux. Currently STiH415, STiH416 SOCs are supported with both
+  B2000 and B2020 Reference boards.
+  configuration
+  -------------
+  A generic configuration is provided for both STiH415/416, and can be used as the
+  default by
+        make stih41x_defconfig
+  Layout
+  ------
+  All the files for multiple machine families (STiH415, STiH416, and STiG125)
+  are located in the platform code contained in arch/arm/mach-sti
+  There is a generic board board-dt.c in the mach folder which support
+  Flattened Device Tree, which means, It works with any compatible board with
+  Device Trees.
+  Document Author
+  ---------------
+  Srinivas Kandagatla <srinivas.kandagatla@st.com>, (c) 2013 ST Microelectronics
diff --git a/Documentation/arm/sti/stih415-overview.txt b/Documentation/arm/sti/stih415-overview.txt
new file mode 100644
index 000000000000..1383e33f265d
--- /dev/null
+++ b/Documentation/arm/sti/stih415-overview.txt
@@ -0,0 +1,12 @@
+                        STiH415 Overview
+                        ================
+Introduction
+------------
+    The STiH415 is the next generation of HD, AVC set-top box processors
+    for satellite, cable, terrestrial and IP-STB markets.
+    Features
+    - ARM Cortex-A9 1.0 GHz, dual-core CPU
+    - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2
diff --git a/Documentation/arm/sti/stih416-overview.txt b/Documentation/arm/sti/stih416-overview.txt
new file mode 100644
index 000000000000..558444c201c6
--- /dev/null
+++ b/Documentation/arm/sti/stih416-overview.txt
@@ -0,0 +1,12 @@
+                        STiH416 Overview
+                        ================
+Introduction
+------------
+    The STiH416 is the next generation of HD, AVC set-top box processors
+    for satellite, cable, terrestrial and IP-STB markets.
+    Features
+    - ARM Cortex-A9 1.2 GHz dual core CPU
+    - SATA2x2,USB 2.0x3, PCIe, Gbit Ethernet MACx2
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index 87a1e8fb6242..e3f93fb9224e 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -3,17 +3,26 @@ ARM Allwinner SoCs
 This document lists all the ARM Allwinner SoCs that are currently
 supported in mainline by the Linux kernel. This document will also
-provide links to documentation and or datasheet for these SoCs.
+provide links to documentation and/or datasheet for these SoCs.
 SunXi family
 ------------
+  Linux kernel mach directory: arch/arm/mach-sunxi
  Flavors:
-        Allwinner A10 (sun4i)
+    * ARM Cortex-A8 based SoCs
-                Datasheet       : http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
+      - Allwinner A10 (sun4i)
+        + Datasheet
+          http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
+        + User Manual
+          http://dl.linux-sunxi.org/A10/A10%20User%20Manual%20-%20v1.20%20%282012-04-09%2c%20DECRYPTED%29.pdf
-        Allwinner A13 (sun5i)
+      - Allwinner A10s (sun5i)
-                Datasheet       : http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+        + Datasheet
+          http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
-  Core: Cortex A8
+      - Allwinner A13 (sun5i)
-  Linux kernel mach directory: arch/arm/mach-sunxi
-\ No newline at end of file
+        + Datasheet
+          http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+        + User Manual
+          http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-08-08%29.pdf
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 5f583af0a6e1..78a377124ef0 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -73,3 +73,10 @@ Translation table lookup with 64KB pages:
 |                 |    +--------------------------> [41:29] L2 index (only 38:29 used)
 |                 +-------------------------------> [47:42] L1 index (not used)
 +-------------------------------------------------> [63] TTBR0/1
+When using KVM, the hypervisor maps kernel pages in EL2, at a fixed
+offset from the kernel VA (top 24bits of the kernel VA set to zero):
+Start                   End                     Size            Use
+-----------------------------------------------------------------------
+0000004000000000        0000007fffffffff         256GB          kernel objects mapped in HYP
diff --git a/Documentation/bcache.txt b/Documentation/bcache.txt
index 77db8809bd96..c3365f26b2d9 100644
--- a/Documentation/bcache.txt
+++ b/Documentation/bcache.txt
@@ -181,7 +181,7 @@ want for getting the best possible numbers when benchmarking.
   In practice this isn't an issue because as soon as a write comes along it'll
   cause the btree node to be split, and you need almost no write traffic for
-   this to not show up enough to be noticable (especially since bcache's btree
+   this to not show up enough to be noticeable (especially since bcache's btree
   nodes are huge and index large regions of the device). But when you're
   benchmarking, if you're trying to warm the cache by reading a bunch of data
   and there's no other traffic - that can be a problem.
@@ -222,7 +222,7 @@ running
  it's in passthrough mode or caching).
 sequential_cutoff
-  A sequential IO will bypass the cache once it passes this threshhold; the
+  A sequential IO will bypass the cache once it passes this threshold; the
  most recent 128 IOs are tracked so sequential IO can be detected even when
  it isn't all done at once.
@@ -296,7 +296,7 @@ cache_miss_collisions
  since the synchronization for cache misses was rewritten)
 cache_readaheads
-  Count of times readahead occured.
+  Count of times readahead occurred.
 SYSFS - CACHE SET:
@@ -319,7 +319,10 @@ cache<0..n>
  Symlink to each of the cache devices comprising this cache set. 
 cache_available_percent
-  Percentage of cache device free.
+  Percentage of cache device which doesn't contain dirty data, and could
+  potentially be used for writeback.  This doesn't mean this space isn't used
+  for clean cached data; the unused statistic (in priority_stats) is typically
+  much lower.
 clear_stats
  Clears the statistics associated with this cache
@@ -359,7 +362,7 @@ unregister
 SYSFS - CACHE SET INTERNAL:
 This directory also exposes timings for a number of internal operations, with
-separate files for average duration, average frequency, last occurence and max
+separate files for average duration, average frequency, last occurrence and max
 duration: garbage collection, btree read, btree node sorts and btree splits.
 active_journal_entries
@@ -414,7 +417,7 @@ freelist_percent
  space.
 io_errors
-  Number of errors that have occured, decayed by io_error_halflife.
+  Number of errors that have occurred, decayed by io_error_halflife.
 metadata_written
  Sum of all non data writes (btree writes and all other metadata).
@@ -423,8 +426,11 @@ nbuckets
  Total buckets in this cache
 priority_stats
-  Statistics about how recently data in the cache has been accessed.  This can
+  Statistics about how recently data in the cache has been accessed.
-  reveal your working set size.
+  This can reveal your working set size.  Unused is the percentage of
+  the cache that doesn't contain any data.  Metadata is bcache's
+  metadata overhead.  Average is the average priority of cache buckets.
+  Next is a list of quantiles with the priority threshold of each.
 written
  Sum of all data that has been written to the cache; comparison with
diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt
index e54ac1d53403..7d2d046c265f 100644
--- a/Documentation/block/queue-sysfs.txt
+++ b/Documentation/block/queue-sysfs.txt
@@ -93,7 +93,7 @@ To avoid priority inversion through request starvation, a request
 queue maintains a separate request pool per each cgroup when
 CONFIG_BLK_CGROUP is enabled, and this parameter applies to each such
 per-block-cgroup request pool.  IOW, if there are N block cgroups,
-each request queue may have upto N request pools, each independently
+each request queue may have up to N request pools, each independently
 regulated by nr_requests.
 optimal_io_size (RO)
diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt
index da272c8f44e7..cd556b914786 100644
--- a/Documentation/cgroups/blkio-controller.txt
+++ b/Documentation/cgroups/blkio-controller.txt
@@ -94,11 +94,13 @@ Throttling/Upper Limit policy
 Hierarchical Cgroups
 ====================
- Currently only CFQ supports hierarchical groups. For throttling,
-  cgroup interface does allow creation of hierarchical cgroups and
-  internally it treats them as flat hierarchy.
-  If somebody created a hierarchy like as follows.
+Both CFQ and throttling implement hierarchy support; however,
+throttling's hierarchy support is enabled iff "sane_behavior" is
+enabled from cgroup side, which currently is a development option and
+not publicly available.
+If somebody created a hierarchy like as follows.
                        root
                        /  \
@@ -106,21 +108,20 @@ Hierarchical Cgroups
                        |
                     test3
-  CFQ will handle the hierarchy correctly but and throttling will
+CFQ by default and throttling with "sane_behavior" will handle the
-  practically treat all groups at same level. For details on CFQ
+hierarchy correctly.  For details on CFQ hierarchy support, refer to
-  hierarchy support, refer to Documentation/block/cfq-iosched.txt.
+Documentation/block/cfq-iosched.txt.  For throttling, all limits apply
-  Throttling will treat the hierarchy as if it looks like the
+to the whole subtree while all statistics are local to the IOs
-  following.
+directly generated by tasks in that cgroup.
+Throttling without "sane_behavior" enabled from cgroup side will
+practically treat all groups at same level as if it looks like the
+following.
                                pivot
                             /  /   \  \
                        root  test1 test2  test3
-  Nesting cgroups, while allowed, isn't officially supported and blkio
-  genereates warning when cgroups nest. Once throttling implements
-  hierarchy support, hierarchy will be supported and the warning will
-  be removed.
 Various user visible config options
 ===================================
 CONFIG_BLK_CGROUP
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt
index 12e01d432bfe..7740038d82bc 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -373,7 +373,7 @@ can become very uneven.
 1.7 What is sched_load_balance ?
 --------------------------------
-The kernel scheduler (kernel/sched.c) automatically load balances
+The kernel scheduler (kernel/sched/core.c) automatically load balances
 tasks.  If one CPU is underutilized, kernel code running on that
 CPU will look for tasks on other more overloaded CPUs and move those
 tasks to itself, within the constraints of such placement mechanisms
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index ddf4f93967a9..2a3330696372 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -304,7 +304,7 @@ kernel memory, we prevent new processes from being created when the kernel
 memory usage is too high.
 * slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
-of each kmem_cache is created everytime the cache is touched by the first time
+of each kmem_cache is created every time the cache is touched by the first time
 from inside the memcg. The creation is done lazily, so some objects can still be
 skipped while the cache is being created. All objects in a slab page should
 belong to the same memcg. This only fails to hold when a task is migrated to a
@@ -490,10 +490,10 @@ pgpgin		- # of charging events to the memory cgroup. The charging
 pgpgout         - # of uncharging events to the memory cgroup. The uncharging
                event happens each time a page is unaccounted from the cgroup.
 swap            - # of bytes of swap usage
-inactive_anon   - # of bytes of anonymous memory and swap cache memory on
+inactive_anon   - # of bytes of anonymous and swap cache memory on inactive
                LRU list.
 active_anon     - # of bytes of anonymous and swap cache memory on active
-                inactive LRU list.
+                LRU list.
 inactive_file   - # of bytes of file-backed memory on inactive LRU list.
 active_file     - # of bytes of file-backed memory on active LRU list.
 unevictable     - # of bytes of memory that cannot be reclaimed (mlocked etc).
@@ -834,10 +834,9 @@ Test:
 12. TODO
-1. Add support for accounting huge pages (as a separate controller)
+1. Make per-cgroup scanner reclaim not-shared pages first
-2. Make per-cgroup scanner reclaim not-shared pages first
+2. Teach controller to account for shared-pages
-3. Teach controller to account for shared-pages
+3. Start reclamation in the background when the limit is
-4. Start reclamation in the background when the limit is
   not yet hit but the usage is getting closer
 Summary
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index b9911c27f496..6f68ba0d1e01 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -32,7 +32,7 @@ hardware-specific bits for the hypothetical "foo" hardware.
 Tying the two halves of this interface together is struct clk_hw, which
 is defined in struct clk_foo and pointed to within struct clk.  This
-allows easy for navigation between the two discrete halves of the common
+allows for easy navigation between the two discrete halves of the common
 clock interface.
        Part 2 - common data structures and api
diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt
index 18de78599dd4..7f773d51fdd9 100644
--- a/Documentation/coccinelle.txt
+++ b/Documentation/coccinelle.txt
@@ -6,15 +6,17 @@ Copyright 2010 Gilles Muller <Gilles.Muller@lip6.fr>
 Getting Coccinelle
 ~~~~~~~~~~~~~~~~~~~~
-The semantic patches included in the kernel use the 'virtual rule'
+The semantic patches included in the kernel use features and options
-feature which was introduced in Coccinelle version 0.1.11.
+which are provided by Coccinelle version 1.0.0-rc11 and above.
+Using earlier versions will fail as the option names used by
+the Coccinelle files and coccicheck have been updated.
-Coccinelle (>=0.2.0) is available through the package manager
+Coccinelle is available through the package manager
 of many distributions, e.g. :
- - Debian (>=squeeze)
+ - Debian
- - Fedora (>=13)
+ - Fedora
- - Ubuntu (>=10.04 Lucid Lynx)
+ - Ubuntu
 - OpenSUSE
 - Arch Linux
 - NetBSD
@@ -36,11 +38,6 @@ as a regular user, and install it with
        sudo make install
-The semantic patches in the kernel will work best with Coccinelle version
-0.2.4 or later.  Using earlier versions may incur some parse errors in the
-semantic patch code, but any results that are obtained should still be
-correct.
 Using Coccinelle on the Linux kernel
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -48,7 +45,7 @@ A Coccinelle-specific target is defined in the top level
 Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
 front-end in the 'scripts' directory.
-Four modes are defined: patch, report, context, and org. The mode to
+Four basic modes are defined: patch, report, context, and org. The mode to
 use is specified by setting the MODE variable with 'MODE=<mode>'.
 'patch' proposes a fix, when possible.
@@ -62,18 +59,24 @@ diff-like style.Lines of interest are indicated with '-'.
 'org' generates a report in the Org mode format of Emacs.
 Note that not all semantic patches implement all modes. For easy use
-of Coccinelle, the default mode is "chain" which tries the previous
+of Coccinelle, the default mode is "report".
-modes in the order above until one succeeds.
+Two other modes provide some common combinations of these modes.
-To make a report for every semantic patch, run the following command:
+'chain' tries the previous modes in the order above until one succeeds.
-        make coccicheck MODE=report
+'rep+ctxt' runs successively the report mode and the context mode.
+           It should be used with the C option (described later)
+           which checks the code on a file basis.
-NB: The 'report' mode is the default one.
+Examples:
+        To make a report for every semantic patch, run the following command:
-To produce patches, run:
+                make coccicheck MODE=report
-        make coccicheck MODE=patch
+        To produce patches, run:
+                make coccicheck MODE=patch
 The coccicheck target applies every semantic patch available in the
@@ -91,6 +94,11 @@ To enable verbose messages set the V= variable, for example:
   make coccicheck MODE=report V=1
+By default, coccicheck tries to run as parallel as possible. To change
+the parallelism, set the J= variable. For example, to run across 4 CPUs:
+   make coccicheck MODE=report J=4
 Using Coccinelle with a single semantic patch
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -124,26 +132,33 @@ To check only newly edited code, use the value 2 for the C flag, i.e.
    make C=2 CHECK="scripts/coccicheck"
+In these modes, which works on a file basis, there is no information
+about semantic patches displayed, and no commit message proposed.
 This runs every semantic patch in scripts/coccinelle by default. The
 COCCI variable may additionally be used to only apply a single
 semantic patch as shown in the previous section.
-The "chain" mode is the default. You can select another one with the
+The "report" mode is the default. You can select another one with the
 MODE variable explained above.
-In this mode, there is no information about semantic patches
-displayed, and no commit message proposed.
 Additional flags
 ~~~~~~~~~~~~~~~~~~
 Additional flags can be passed to spatch through the SPFLAGS
 variable.
-    make SPFLAGS=--use_glimpse coccicheck
+    make SPFLAGS=--use-glimpse coccicheck
+    make SPFLAGS=--use-idutils coccicheck
 See spatch --help to learn more about spatch options.
+Note that the '--use-glimpse' and '--use-idutils' options
+require external tools for indexing the code. None of them is
+thus active by default. However, by indexing the code with
+one of these tools, and according to the cocci file used,
+spatch could proceed the entire code base more quickly.
 Proposing new semantic patches
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/console/console.txt b/Documentation/console/console.txt
index 926cf1b5e63e..f93810d599ad 100644
--- a/Documentation/console/console.txt
+++ b/Documentation/console/console.txt
@@ -12,20 +12,20 @@ The second type has to be explicitly loaded and unloaded. This will be called
 any time with each driver sharing the console with other drivers including
 the system driver. However, modular drivers cannot take over the console
 that is currently occupied by another modular driver. (Exception: Drivers that
-call take_over_console() will succeed in the takeover regardless of the type
+call do_take_over_console() will succeed in the takeover regardless of the type
 of driver occupying the consoles.) They can only take over the console that is
 occupied by the system driver. In the same token, if the modular driver is
 released by the console, the system driver will take over.
 Modular drivers, from the programmer's point of view, has to call:
-         take_over_console() - load and bind driver to console layer
+         do_take_over_console() - load and bind driver to console layer
-         give_up_console() - unbind and unload driver
+         give_up_console() - unload driver, it will only work if driver is fully unbond
 In newer kernels, the following are also available:
-         register_con_driver()
+         do_register_con_driver()
-         unregister_con_driver()
+         do_unregister_con_driver()
 If sysfs is enabled, the contents of /sys/class/vtconsole can be
 examined. This shows the console backends currently registered by the
@@ -94,12 +94,12 @@ for more details).
 Notes for developers:
 =====================
-take_over_console() is now broken up into:
+do_take_over_console() is now broken up into:
-     register_con_driver()
+     do_register_con_driver()
-     bind_con_driver() - private function
+     do_bind_con_driver() - private function
-give_up_console() is a wrapper to unregister_con_driver(), and a driver must
+give_up_console() is a wrapper to do_unregister_con_driver(), and a driver must
 be fully unbound for this call to succeed. con_is_bound() will check if the
 driver is bound or not.
@@ -109,10 +109,10 @@ Guidelines for console driver writers:
 In order for binding to and unbinding from the console to properly work,
 console drivers must follow these guidelines:
-1. All drivers, except system drivers, must call either register_con_driver()
+1. All drivers, except system drivers, must call either do_register_con_driver()
-   or take_over_console(). register_con_driver() will just add the driver to
+   or do_take_over_console(). do_register_con_driver() will just add the driver to
   the console's internal list. It won't take over the
-   console. take_over_console(), as it name implies, will also take over (or
+   console. do_take_over_console(), as it name implies, will also take over (or
   bind to) the console.
 2. All resources allocated during con->con_init() must be released in
@@ -128,10 +128,10 @@ console drivers must follow these guidelines:
   rebind the driver to the console arrives.
 4. Upon exit of the driver, ensure that the driver is totally unbound. If the
-   condition is satisfied, then the driver must call unregister_con_driver()
+   condition is satisfied, then the driver must call do_unregister_con_driver()
   or give_up_console().
-5. unregister_con_driver() can also be called on conditions which make it
+5. do_unregister_con_driver() can also be called on conditions which make it
   impossible for the driver to service console requests.  This can happen
   with the framebuffer console that suddenly lost all of its drivers.
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index a3585eac83b6..19fa98e07bf7 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -186,7 +186,7 @@ As most cpufreq processors only allow for being set to a few specific
 frequencies, a "frequency table" with some functions might assist in
 some work of the processor driver. Such a "frequency table" consists
 of an array of struct cpufreq_frequency_table entries, with any value in
-"index" you want to use, and the corresponding frequency in
+"driver_data" you want to use, and the corresponding frequency in
 "frequency". At the end of the table, you need to add a
 cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
 if you want to skip one entry in the table, set the frequency to 
@@ -214,10 +214,4 @@ int cpufreq_frequency_table_target(struct cpufreq_policy *policy,
 is the corresponding frequency table helper for the ->target
 stage. Just pass the values to this function, and the unsigned int
 index returns the number of the frequency table entry which contains
-the frequency the CPU shall be set to. PLEASE NOTE: This is not the
+the frequency the CPU shall be set to.
-"index" which is in this cpufreq_table_entry.index, but instead
-cpufreq_table[index]. So, the new frequency is
-cpufreq_table[index].frequency, and the value you stored into the
-frequency table "index" field is
-cpufreq_table[index].index.
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 9f401350f502..edd4b4df3932 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -128,7 +128,7 @@ A: When doing make defconfig, Enable CPU hotplug support
   "Processor type and Features" -> Support for Hotpluggable CPUs
-Make sure that you have CONFIG_HOTPLUG, and CONFIG_SMP turned on as well.
+Make sure that you have CONFIG_SMP turned on as well.
 You would need to enable CONFIG_HOTPLUG_CPU for SMP suspend/resume support
 as well.
@@ -370,8 +370,10 @@ A: There is no clear spec defined way from ACPI that can give us that
   CPUs in MADT as hotpluggable CPUS.  In the case there are no disabled CPUS
   we assume 1/2 the number of CPUs currently present can be hotplugged.
-   Caveat: Today's ACPI MADT can only provide 256 entries since the apicid field
+   Caveat: ACPI MADT can only provide 256 entries in systems with only ACPI 2.0c
-   in MADT is only 8 bits.
+   or earlier ACPI version supported, because the apicid field in MADT is only
+   8 bits. From ACPI 3.0, this limitation was removed since the apicid field
+   was extended to 32 bits with x2APIC introduced.
 User Space Notification
diff --git a/Documentation/crypto/async-tx-api.txt b/Documentation/crypto/async-tx-api.txt
index ba046b8fa92f..7bf1be20d93a 100644
--- a/Documentation/crypto/async-tx-api.txt
+++ b/Documentation/crypto/async-tx-api.txt
@@ -222,5 +222,4 @@ drivers/dma/: location for offload engine drivers
 include/linux/async_tx.h: core header file for the async_tx api
 crypto/async_tx/async_tx.c: async_tx interface to dmaengine and common code
 crypto/async_tx/async_memcpy.c: copy offload
-crypto/async_tx/async_memset.c: memory fill offload
 crypto/async_tx/async_xor.c: xor and xor zero sum offload
diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt
index f50470abe241..e8cdf7241b66 100644
--- a/Documentation/device-mapper/cache.txt
+++ b/Documentation/device-mapper/cache.txt
@@ -87,7 +87,7 @@ Migration throttling
 Migrating data between the origin and cache device uses bandwidth.
 The user can set a throttle to prevent more than a certain amount of
-migration occuring at any one time.  Currently we're not taking any
+migration occurring at any one time.  Currently we're not taking any
 account of normal io traffic going to the devices.  More work needs
 doing here to avoid migrating during those peak io moments.
diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt
index e9192283e5a5..ef8ba9fa58c4 100644
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -222,3 +222,5 @@ Version History
 1.4.2   Add RAID10 "far" and "offset" algorithm support.
 1.5.0   Add message interface to allow manipulation of the sync_action.
        New status (STATUSTYPE_INFO) fields: sync_action and mismatch_cnt.
+1.5.1   Add ability to restore transiently failed devices on resume.
+1.5.2   'mismatch_cnt' is zero unless [last_]sync_action is "check".
diff --git a/Documentation/device-mapper/switch.txt b/Documentation/device-mapper/switch.txt
new file mode 100644
index 000000000000..2fa749387be8
--- /dev/null
+++ b/Documentation/device-mapper/switch.txt
@@ -0,0 +1,126 @@
+dm-switch
+=========
+The device-mapper switch target creates a device that supports an
+arbitrary mapping of fixed-size regions of I/O across a fixed set of
+paths.  The path used for any specific region can be switched
+dynamically by sending the target a message.
+It maps I/O to underlying block devices efficiently when there is a large
+number of fixed-sized address regions but there is no simple pattern
+that would allow for a compact representation of the mapping such as
+dm-stripe.
+Background
+----------
+Dell EqualLogic and some other iSCSI storage arrays use a distributed
+frameless architecture.  In this architecture, the storage group
+consists of a number of distinct storage arrays ("members") each having
+independent controllers, disk storage and network adapters.  When a LUN
+is created it is spread across multiple members.  The details of the
+spreading are hidden from initiators connected to this storage system.
+The storage group exposes a single target discovery portal, no matter
+how many members are being used.  When iSCSI sessions are created, each
+session is connected to an eth port on a single member.  Data to a LUN
+can be sent on any iSCSI session, and if the blocks being accessed are
+stored on another member the I/O will be forwarded as required.  This
+forwarding is invisible to the initiator.  The storage layout is also
+dynamic, and the blocks stored on disk may be moved from member to
+member as needed to balance the load.
+This architecture simplifies the management and configuration of both
+the storage group and initiators.  In a multipathing configuration, it
+is possible to set up multiple iSCSI sessions to use multiple network
+interfaces on both the host and target to take advantage of the
+increased network bandwidth.  An initiator could use a simple round
+robin algorithm to send I/O across all paths and let the storage array
+members forward it as necessary, but there is a performance advantage to
+sending data directly to the correct member.
+A device-mapper table already lets you map different regions of a
+device onto different targets.  However in this architecture the LUN is
+spread with an address region size on the order of 10s of MBs, which
+means the resulting table could have more than a million entries and
+consume far too much memory.
+Using this device-mapper switch target we can now build a two-layer
+device hierarchy:
+    Upper Tier – Determine which array member the I/O should be sent to.
+    Lower Tier – Load balance amongst paths to a particular member.
+The lower tier consists of a single dm multipath device for each member.
+Each of these multipath devices contains the set of paths directly to
+the array member in one priority group, and leverages existing path
+selectors to load balance amongst these paths.  We also build a
+non-preferred priority group containing paths to other array members for
+failover reasons.
+The upper tier consists of a single dm-switch device.  This device uses
+a bitmap to look up the location of the I/O and choose the appropriate
+lower tier device to route the I/O.  By using a bitmap we are able to
+use 4 bits for each address range in a 16 member group (which is very
+large for us).  This is a much denser representation than the dm table
+b-tree can achieve.
+Construction Parameters
+=======================
+    <num_paths> <region_size> <num_optional_args> [<optional_args>...]
+    [<dev_path> <offset>]+
+<num_paths>
+    The number of paths across which to distribute the I/O.
+<region_size>
+    The number of 512-byte sectors in a region. Each region can be redirected
+    to any of the available paths.
+<num_optional_args>
+    The number of optional arguments. Currently, no optional arguments
+    are supported and so this must be zero.
+<dev_path>
+    The block device that represents a specific path to the device.
+<offset>
+    The offset of the start of data on the specific <dev_path> (in units
+    of 512-byte sectors). This number is added to the sector number when
+    forwarding the request to the specific path. Typically it is zero.
+Messages
+========
+set_region_mappings <index>:<path_nr> [<index>]:<path_nr> [<index>]:<path_nr>...
+Modify the region table by specifying which regions are redirected to
+which paths.
+<index>
+    The region number (region size was specified in constructor parameters).
+    If index is omitted, the next region (previous index + 1) is used.
+    Expressed in hexadecimal (WITHOUT any prefix like 0x).
+<path_nr>
+    The path number in the range 0 ... (<num_paths> - 1).
+    Expressed in hexadecimal (WITHOUT any prefix like 0x).
+Status
+======
+No status line is reported.
+Example
+=======
+Assume that you have volumes vg1/switch0 vg1/switch1 vg1/switch2 with
+the same size.
+Create a switch device with 64kB region size:
+    dmsetup create switch --table "0 `blockdev --getsize /dev/vg1/switch0`
+        switch 3 128 0 /dev/vg1/switch0 0 /dev/vg1/switch1 0 /dev/vg1/switch2 0"
+Set mappings for the first 7 entries to point to devices switch0, switch1,
+switch2, switch0, switch1, switch2, switch1:
+    dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 08f01e79c41a..23721d3be3e6 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -100,8 +100,7 @@ Your cooperation is appreciated.
                 10 = /dev/aio          Asynchronous I/O notification interface
                 11 = /dev/kmsg         Writes to this come out as printk's, reads
                                        export the buffered printk records.
-                 12 = /dev/oldmem       Used by crashdump kernels to access
+                 12 = /dev/oldmem       OBSOLETE - replaced by /proc/vmcore
-                                        the memory of the kernel that crashed.
  1 block       RAM disk
                  0 = /dev/ram0         First RAM disk
@@ -498,12 +497,8 @@ Your cooperation is appreciated.
                Each device type has 5 bits (32 minors).
- 13 block       8-bit MFM/RLL/IDE controller
+ 13 block       Previously used for the XT disk (/dev/xdN)
-                  0 = /dev/xda          First XT disk whole disk
+                Deleted in kernel v3.9.
-                 64 = /dev/xdb          Second XT disk whole disk
-                Partitions are handled in the same way as IDE disks
-                (see major number 3).
 14 char        Open Sound System (OSS)
                  0 = /dev/mixer        Mixer control
diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
new file mode 100644
index 000000000000..92d36e2aa877
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -0,0 +1,172 @@
+=======================================================
+ARM CCI cache coherent interconnect binding description
+=======================================================
+ARM multi-cluster systems maintain intra-cluster coherency through a
+cache coherent interconnect (CCI) that is capable of monitoring bus
+transactions and manage coherency, TLB invalidations and memory barriers.
+It allows snooping and distributed virtual memory message broadcast across
+clusters, through memory mapped interface, with a global control register
+space and multiple sets of interface control registers, one per slave
+interface.
+Bindings for the CCI node follow the ePAPR standard, available from:
+www.power.org/documentation/epapr-version-1-1/
+with the addition of the bindings described in this document which are
+specific to ARM.
+* CCI interconnect node
+        Description: Describes a CCI cache coherent Interconnect component
+        Node name must be "cci".
+        Node's parent must be the root node /, and the address space visible
+        through the CCI interconnect is the same as the one seen from the
+        root node (ie from CPUs perspective as per DT standard).
+        Every CCI node has to define the following properties:
+        - compatible
+                Usage: required
+                Value type: <string>
+                Definition: must be set to
+                            "arm,cci-400"
+        - reg
+                Usage: required
+                Value type: <prop-encoded-array>
+                Definition: A standard property. Specifies base physical
+                            address of CCI control registers common to all
+                            interfaces.
+        - ranges:
+                Usage: required
+                Value type: <prop-encoded-array>
+                Definition: A standard property. Follow rules in the ePAPR for
+                            hierarchical bus addressing. CCI interfaces
+                            addresses refer to the parent node addressing
+                            scheme to declare their register bases.
+        CCI interconnect node can define the following child nodes:
+        - CCI control interface nodes
+                Node name must be "slave-if".
+                Parent node must be CCI interconnect node.
+                A CCI control interface node must contain the following
+                properties:
+                - compatible
+                        Usage: required
+                        Value type: <string>
+                        Definition: must be set to
+                                    "arm,cci-400-ctrl-if"
+                - interface-type:
+                        Usage: required
+                        Value type: <string>
+                        Definition: must be set to one of {"ace", "ace-lite"}
+                                    depending on the interface type the node
+                                    represents.
+                - reg:
+                        Usage: required
+                        Value type: <prop-encoded-array>
+                        Definition: the base address and size of the
+                                    corresponding interface programming
+                                    registers.
+* CCI interconnect bus masters
+        Description: masters in the device tree connected to a CCI port
+                     (inclusive of CPUs and their cpu nodes).
+        A CCI interconnect bus master node must contain the following
+        properties:
+        - cci-control-port:
+                Usage: required
+                Value type: <phandle>
+                Definition: a phandle containing the CCI control interface node
+                            the master is connected to.
+Example:
+        cpus {
+                #size-cells = <0>;
+                #address-cells = <1>;
+                CPU0: cpu@0 {
+                        device_type = "cpu";
+                        compatible = "arm,cortex-a15";
+                        cci-control-port = <&cci_control1>;
+                        reg = <0x0>;
+                };
+                CPU1: cpu@1 {
+                        device_type = "cpu";
+                        compatible = "arm,cortex-a15";
+                        cci-control-port = <&cci_control1>;
+                        reg = <0x1>;
+                };
+                CPU2: cpu@100 {
+                        device_type = "cpu";
+                        compatible = "arm,cortex-a7";
+                        cci-control-port = <&cci_control2>;
+                        reg = <0x100>;
+                };
+                CPU3: cpu@101 {
+                        device_type = "cpu";
+                        compatible = "arm,cortex-a7";
+                        cci-control-port = <&cci_control2>;
+                        reg = <0x101>;
+                };
+        };
+        dma0: dma@3000000 {
+                compatible = "arm,pl330", "arm,primecell";
+                cci-control-port = <&cci_control0>;
+                reg = <0x0 0x3000000 0x0 0x1000>;
+                interrupts = <10>;
+                #dma-cells = <1>;
+                #dma-channels = <8>;
+                #dma-requests = <32>;
+        };
+        cci@2c090000 {
+                compatible = "arm,cci-400";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                reg = <0x0 0x2c090000 0 0x1000>;
+                ranges = <0x0 0x0 0x2c090000 0x6000>;
+                cci_control0: slave-if@1000 {
+                        compatible = "arm,cci-400-ctrl-if";
+                        interface-type = "ace-lite";
+                        reg = <0x1000 0x1000>;
+                };
+                cci_control1: slave-if@4000 {
+                        compatible = "arm,cci-400-ctrl-if";
+                        interface-type = "ace";
+                        reg = <0x4000 0x1000>;
+                };
+                cci_control2: slave-if@5000 {
+                        compatible = "arm,cci-400-ctrl-if";
+                        interface-type = "ace";
+                        reg = <0x5000 0x1000>;
+                };
+        };
+This CCI node corresponds to a CCI component whose control registers sits
+at address 0x000000002c090000.
+CCI slave interface @0x000000002c091000 is connected to dma controller dma0.
+CCI slave interface @0x000000002c094000 is connected to CPUs {CPU0, CPU1};
+CCI slave interface @0x000000002c095000 is connected to CPUs {CPU2, CPU3};
diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
new file mode 100644
index 000000000000..63c0e6ae5cf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -0,0 +1,10 @@
+TI Keystone Platforms Device Tree Bindings
+-----------------------------------------------
+Boards with Keystone2 based devices (TCI66xxK2H) SOC shall have the
+following properties.
+Required properties:
+ - compatible: All TI specific devices present in Keystone SOC should be in
+   the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
+   type UART should use the specified compatible for those devices.
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index cbef09b5c8a7..69ddf9fad2dc 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -16,6 +16,9 @@ Required properties:
     performs the same operation).
        "marvell,"aurora-outer-cache: Marvell Controller designed to be
         compatible with the ARM one with outer cache mode.
+        "bcm,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
 - 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/nspire.txt b/Documentation/devicetree/bindings/arm/nspire.txt
new file mode 100644
index 000000000000..4d08518bd176
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/nspire.txt
@@ -0,0 +1,14 @@
+TI-NSPIRE calculators
+Required properties:
+- compatible: Compatible property value should contain "ti,nspire".
+        CX models should have "ti,nspire-cx"
+        Touchpad models should have "ti,nspire-tp"
+        Clickpad models should have "ti,nspire-clp"
+Example:
+/ {
+        model = "TI-NSPIRE CX";
+        compatible = "ti,nspire-cx";
+        ...
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index f8288ea1b530..6d498c758b45 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -56,3 +56,6 @@ Boards:
 - OMAP5 EVM : Evaluation Module
  compatible = "ti,omap5-evm", "ti,omap5"
+- AM43x EPOS EVM
+  compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
diff --git a/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
new file mode 100644
index 000000000000..3b8fbf3c00c5
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rtsm-dcscb.txt
@@ -0,0 +1,19 @@
+ARM Dual Cluster System Configuration Block
+-------------------------------------------
+The Dual Cluster System Configuration Block (DCSCB) provides basic
+functionality for controlling clocks, resets and configuration pins in
+the Dual Cluster System implemented by the Real-Time System Model (RTSM).
+Required properties:
+- compatible : should be "arm,rtsm,dcscb"
+- reg : physical base address and the size of the registers window
+Example:
+        dcscb@60000000 {
+                compatible = "arm,rtsm,dcscb";
+                reg = <0x60000000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
index f2f2171e530e..9e5f73412cd7 100644
--- a/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/interrupt-combiner.txt
@@ -5,7 +5,7 @@ can combine interrupt sources as a group and provide a single interrupt request
 for the group. The interrupt request from each group are connected to a parent
 interrupt controller, such as GIC in case of Exynos4210.
-The interrupt combiner controller consists of multiple combiners. Upto eight
+The interrupt combiner controller consists of multiple combiners. Up to eight
 interrupt sources can be connected to a combiner. The combiner outputs one
 combined interrupt for its eight interrupt sources. The combined interrupt
 is usually connected to a parent interrupt controller.
@@ -14,8 +14,8 @@ A single node in the device tree is used to describe the interrupt combiner
 controller module (which includes multiple combiners). A combiner in the
 interrupt controller module shares config/control registers with other
 combiners. For example, a 32-bit interrupt enable/disable config register
-can accommodate upto 4 interrupt combiners (with each combiner supporting
+can accommodate up to 4 interrupt combiners (with each combiner supporting
-upto 8 interrupt sources).
+up to 8 interrupt sources).
 Required properties:
 - compatible: should be "samsung,exynos4210-combiner".
diff --git a/Documentation/devicetree/bindings/arm/spear/shirq.txt b/Documentation/devicetree/bindings/arm/spear/shirq.txt
index 13fbb8866bd6..715a013ed4bd 100644
--- a/Documentation/devicetree/bindings/arm/spear/shirq.txt
+++ b/Documentation/devicetree/bindings/arm/spear/shirq.txt
@@ -14,7 +14,7 @@ A single node in the device tree is used to describe the shared
 interrupt multiplexor (one node for all groups). A group in the
 interrupt controller shares config/control registers with other groups.
 For example, a 32-bit interrupt enable/disable config register can
-accommodate upto 4 interrupt groups.
+accommodate up to 4 interrupt groups.
 Required properties:
  - compatible: should be, either of
diff --git a/Documentation/devicetree/bindings/arm/ste-nomadik.txt b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
index 19bca04b81c9..6256ec31666d 100644
--- a/Documentation/devicetree/bindings/arm/ste-nomadik.txt
+++ b/Documentation/devicetree/bindings/arm/ste-nomadik.txt
@@ -3,6 +3,11 @@ ST-Ericsson Nomadik Device Tree Bindings
 For various board the "board" node may contain specific properties
 that pertain to this particular board, such as board-specific GPIOs.
+Required root node property: src
+- Nomadik System and reset controller used for basic chip control, clock
+  and reset line control.
+- compatible: must be "stericsson,nomadik,src"
 Boards with the Nomadik SoC include:
 S8815 "MiniKit" manufactured by Calao Systems:
diff --git a/Documentation/devicetree/bindings/arm/ste-u300.txt b/Documentation/devicetree/bindings/arm/ste-u300.txt
new file mode 100644
index 000000000000..69b5ab0b5f4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/ste-u300.txt
@@ -0,0 +1,46 @@
+ST-Ericsson U300 Device Tree Bindings
+For various board the "board" node may contain specific properties
+that pertain to this particular board, such as board-specific GPIOs
+or board power regulator supplies.
+Required root node property:
+compatible="stericsson,u300";
+Required node: syscon
+This contains the system controller.
+- compatible: must be "stericsson,u300-syscon".
+- reg: the base address and size of the system controller.
+Boards with the U300 SoC include:
+S365 "Small Board U365":
+Required node: s365
+This contains the board-specific information.
+- compatible: must be "stericsson,s365".
+- vana15-supply: the regulator supplying the 1.5V to drive the
+  board.
+- syscon: a pointer to the syscon node so we can acccess the
+  syscon registers to set the board as self-powered.
+Example:
+/ {
+        model = "ST-Ericsson U300";
+        compatible = "stericsson,u300";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        s365 {
+                compatible = "stericsson,s365";
+                vana15-supply = <&ab3100_ldo_d_reg>;
+                syscon = <&syscon>;
+        };
+        syscon: syscon@c0011000 {
+                compatible = "stericsson,u300-syscon";
+                reg = <0xc0011000 0x1000>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index b519f9b699c3..3ec0c5c4f0e9 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -12,6 +12,11 @@ Optional properties:
 - calxeda,port-phys: phandle-combophy and lane assignment, which maps each
                        SATA port to a combophy and a lane within that
                        combophy
+- calxeda,sgpio-gpio: phandle-gpio bank, bit offset, and default on or off,
+                        which indicates that the driver supports SGPIO
+                        indicator lights using the indicated GPIOs
+- calxeda,led-order : a u32 array that map port numbers to offsets within the
+                        SGPIO bitstream.
 - dma-coherent      : Present if dma operations are coherent
 Example:
diff --git a/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
new file mode 100644
index 000000000000..c1d22b3ae134
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/atmel-at91_cf.txt
@@ -0,0 +1,19 @@
+Atmel AT91RM9200 CompactFlash
+Required properties:
+- compatible : "atmel,at91rm9200-cf".
+- reg : should specify localbus address and size used.
+- gpios : specifies the gpio pins to control the CF device. Detect
+  and reset gpio's are mandatory while irq and vcc gpio's are
+  optional and may be set to 0 if not present.
+Example:
+compact-flash@50000000 {
+        compatible = "atmel,at91rm9200-cf";
+        reg = <0x50000000 0x30000000>;
+        gpios = <&pioC 13 0     /* irq */
+                 &pioC 15 0     /* detect */
+                 0              /* vcc */
+                 &pioC  5 0     /* reset */
+                >;
+};
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
new file mode 100644
index 000000000000..cedc2a9c4785
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -0,0 +1,49 @@
+Device tree bindings for i.MX Wireless External Interface Module (WEIM)
+The term "wireless" does not imply that the WEIM is literally an interface
+without wires. It simply means that this module was originally designed for
+wireless and mobile applications that use low-power technology.
+The actual devices are instantiated from the child nodes of a WEIM node.
+Required properties:
+ - compatible:          Should be set to "fsl,imx6q-weim"
+ - reg:                 A resource specifier for the register space
+                        (see the example below)
+ - clocks:              the clock, see the example below.
+ - #address-cells:      Must be set to 2 to allow memory address translation
+ - #size-cells:         Must be set to 1 to allow CS address passing
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                           <cs-number> 0 <physical address of mapping> <size>
+Timing property for child nodes. It is mandatory, not optional.
+ - fsl,weim-cs-timing:  The timing array, contains 6 timing values for the
+                        child node. We can get the CS index from the child
+                        node's "reg" property. This property contains the values
+                        for the registers EIM_CSnGCR1, EIM_CSnGCR2, EIM_CSnRCR1,
+                        EIM_CSnRCR2, EIM_CSnWCR1, EIM_CSnWCR2 in this order.
+Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
+        weim: weim@021b8000 {
+                compatible = "fsl,imx6q-weim";
+                reg = <0x021b8000 0x4000>;
+                clocks = <&clks 196>;
+                #address-cells = <2>;
+                #size-cells = <1>;
+                ranges = <0 0 0x08000000 0x08000000>;
+                nor@0,0 {
+                        compatible = "cfi-flash";
+                        reg = <0 0 0x02000000>;
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        bank-width = <2>;
+                        fsl,weim-cs-timing = <0x00620081 0x00000001 0x1c022000
+                                        0x0000c000 0x1404a38e 0x00000000>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
index 4b87ea1194e3..704be9306c9f 100644
--- a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -95,7 +95,6 @@ GPMC chip-select settings properties for child nodes. All are optional.
 - gpmc,burst-wrap       Enables wrap bursting
 - gpmc,burst-read       Enables read page/burst mode
 - gpmc,burst-write      Enables write page/burst mode
- gpmc,device-nand      Device is NAND
 - gpmc,device-width     Total width of device(s) connected to a GPMC
                        chip-select in bytes. The GPMC supports 8-bit
                        and 16-bit devices and so this property must be
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
index bd0c8416a5c8..0045433eae1f 100644
--- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -9,6 +9,9 @@ Required properties:
        "altr,socfpga-pll-clock" - for a PLL clock
        "altr,socfpga-perip-clock" - The peripheral clock divided from the
                PLL clock.
+        "altr,socfpga-gate-clk" - Clocks that directly feed peripherals and
+                can get gated.
 - reg : shall be the control register offset from CLOCK_MANAGER's base for the clock.
 - clocks : shall be the input parent clock phandle for the clock. This is
        either an oscillator or a pll output.
@@ -16,3 +19,7 @@ Required properties:
 Optional properties:
 - fixed-divider : If clocks have a fixed divider value, use this property.
+- clk-gate : For "socfpga-gate-clk", clk-gate contains the gating register
+        and the bit index.
+- div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift,
+        and width.
diff --git a/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
new file mode 100644
index 000000000000..a1201802f90d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/clk-exynos-audss.txt
@@ -0,0 +1,64 @@
+* Samsung Audio Subsystem Clock Controller
+The Samsung Audio Subsystem clock controller generates and supplies clocks
+to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock
+binding described here is applicable to all SoC's in Exynos family.
+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.
+- reg: physical base address and length of the controller's register set.
+- #clock-cells: should be 1.
+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
+Exynos4 SoC and this is specified where applicable.
+Provided clocks:
+Clock           ID      SoC (if specific)
+-----------------------------------------------
+mout_audss      0
+mout_i2s        1
+dout_srp        2
+dout_aud_bus    3
+dout_i2s        4
+srp_clk         5
+i2s_bus         6
+sclk_i2s        7
+pcm_bus         8
+sclk_pcm        9
+Example 1: An example of a clock controller node is listed below.
+clock_audss: audss-clock-controller@3810000 {
+        compatible = "samsung,exynos5250-audss-clock";
+        reg = <0x03810000 0x0C>;
+        #clock-cells = <1>;
+};
+Example 2: 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.
+i2s0: i2s@03830000 {
+        compatible = "samsung,i2s-v5";
+        reg = <0x03830000 0x100>;
+        dmas = <&pdma0 10
+                &pdma0 9
+                &pdma0 8>;
+        dma-names = "tx", "rx", "tx-sec";
+        clocks = <&clock_audss EXYNOS_I2S_BUS>,
+                <&clock_audss EXYNOS_I2S_BUS>,
+                <&clock_audss EXYNOS_SCLK_I2S>,
+                <&clock_audss EXYNOS_MOUT_AUDSS>,
+                <&clock_audss EXYNOS_MOUT_I2S>;
+        clock-names = "iis", "i2s_opclk0", "i2s_opclk1",
+        "mout_audss", "mout_i2s";
+};
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index ea5e26f16aec..14d5c2af26f4 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -102,6 +102,7 @@ Exynos4 SoC and this is specified where applicable.
  sclk_spi0_isp       174     Exynos4x12
  sclk_spi1_isp       175     Exynos4x12
  sclk_uart_isp       176     Exynos4x12
+  sclk_fimg2d         177
              [Peripheral Clock Gates]
@@ -129,7 +130,7 @@ Exynos4 SoC and this is specified where applicable.
  smmu_mfcl           274
  smmu_mfcr           275
  g3d                 276
-  g2d                 277     Exynos4210
+  g2d                 277
  rotator             278     Exynos4210
  mdma                279     Exynos4210
  smmu_g2d            280     Exynos4210
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
new file mode 100644
index 000000000000..9bcc4b1bff51
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -0,0 +1,201 @@
+* Samsung Exynos5420 Clock Controller
+The Exynos5420 clock controller generates and supplies clock to various
+controllers within the Exynos5420 SoC.
+Required Properties:
+- comptible: should be one of the following.
+  - "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC.
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- #clock-cells: should be 1.
+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.
+       [Core Clocks]
+  Clock                 ID
+  ----------------------------
+  fin_pll               1
+  [Clock Gate for Special Clocks]
+  Clock                 ID
+  ----------------------------
+  sclk_uart0            128
+  sclk_uart1            129
+  sclk_uart2            130
+  sclk_uart3            131
+  sclk_mmc0             132
+  sclk_mmc1             133
+  sclk_mmc2             134
+  sclk_spi0             135
+  sclk_spi1             136
+  sclk_spi2             137
+  sclk_i2s1             138
+  sclk_i2s2             139
+  sclk_pcm1             140
+  sclk_pcm2             141
+  sclk_spdif            142
+  sclk_hdmi             143
+  sclk_pixel            144
+  sclk_dp1              145
+  sclk_mipi1            146
+  sclk_fimd1            147
+  sclk_maudio0          148
+  sclk_maupcm0          149
+  sclk_usbd300          150
+  sclk_usbd301          151
+  sclk_usbphy300        152
+  sclk_usbphy301        153
+  sclk_unipro           154
+  sclk_pwm              155
+  sclk_gscl_wa          156
+  sclk_gscl_wb          157
+   [Peripheral Clock Gates]
+  Clock                 ID
+  ----------------------------
+  aclk66_peric          256
+  uart0                 257
+  uart1                 258
+  uart2                 259
+  uart3                 260
+  i2c0                  261
+  i2c1                  262
+  i2c2                  263
+  i2c3                  264
+  i2c4                  265
+  i2c5                  266
+  i2c6                  267
+  i2c7                  268
+  i2c_hdmi              269
+  tsadc                 270
+  spi0                  271
+  spi1                  272
+  spi2                  273
+  keyif                 274
+  i2s1                  275
+  i2s2                  276
+  pcm1                  277
+  pcm2                  278
+  pwm                   279
+  spdif                 280
+  i2c8                  281
+  i2c9                  282
+  i2c10                 283
+  aclk66_psgen          300
+  chipid                301
+  sysreg                302
+  tzpc0                 303
+  tzpc1                 304
+  tzpc2                 305
+  tzpc3                 306
+  tzpc4                 307
+  tzpc5                 308
+  tzpc6                 309
+  tzpc7                 310
+  tzpc8                 311
+  tzpc9                 312
+  hdmi_cec              313
+  seckey                314
+  mct                   315
+  wdt                   316
+  rtc                   317
+  tmu                   318
+  tmu_gpu               319
+  pclk66_gpio           330
+  aclk200_fsys2         350
+  mmc0                  351
+  mmc1                  352
+  mmc2                  353
+  sromc                 354
+  ufs                   355
+  aclk200_fsys          360
+  tsi                   361
+  pdma0                 362
+  pdma1                 363
+  rtic                  364
+  usbh20                365
+  usbd300               366
+  usbd301               377
+  aclk400_mscl          380
+  mscl0                 381
+  mscl1                 382
+  mscl2                 383
+  smmu_mscl0            384
+  smmu_mscl1            385
+  smmu_mscl2            386
+  aclk333               400
+  mfc                   401
+  smmu_mfcl             402
+  smmu_mfcr             403
+  aclk200_disp1         410
+  dsim1                 411
+  dp1                   412
+  hdmi                  413
+  aclk300_disp1         420
+  fimd1                 421
+  smmu_fimd1            422
+  aclk166               430
+  mixer                 431
+  aclk266               440
+  rotator               441
+  mdma1                 442
+  smmu_rotator          443
+  smmu_mdma1            444
+  aclk300_jpeg          450
+  jpeg                  451
+  jpeg2                 452
+  smmu_jpeg             453
+  aclk300_gscl          460
+  smmu_gscl0            461
+  smmu_gscl1            462
+  gscl_wa               463
+  gscl_wb               464
+  gscl0                 465
+  gscl1                 466
+  clk_3aa               467
+  aclk266_g2d           470
+  sss                   471
+  slim_sss              472
+  mdma0                 473
+  aclk333_g2d           480
+  g2d                   481
+  aclk333_432_gscl      490
+  smmu_3aa              491
+  smmu_fimcl0           492
+  smmu_fimcl1           493
+  smmu_fimcl3           494
+  fimc_lite3            495
+  aclk_g3d              500
+  g3d                   501
+Example 1: An example of a clock controller node is listed below.
+        clock: clock-controller@0x10010000 {
+                compatible = "samsung,exynos5420-clock";
+                reg = <0x10010000 0x30000>;
+                #clock-cells = <1>;
+        };
+Example 2: UART controller node that consumes the clock generated by the clock
+           controller. Refer to the standard clock bindings for information
+           about 'clocks' and 'clock-names' property.
+        serial@13820000 {
+                compatible = "samsung,exynos4210-uart";
+                reg = <0x13820000 0x100>;
+                interrupts = <0 54 0>;
+                clocks = <&clock 259>, <&clock 130>;
+                clock-names = "uart", "clk_uart_baud0";
+        };
diff --git a/Documentation/devicetree/bindings/clock/imx5-clock.txt b/Documentation/devicetree/bindings/clock/imx5-clock.txt
index d71b4b2c077d..f46f5625d8ad 100644
--- a/Documentation/devicetree/bindings/clock/imx5-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx5-clock.txt
@@ -184,6 +184,19 @@ clocks and IDs.
        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
 Examples (for mx53):
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 6deb6fd1c7cd..a0e104f0527e 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -208,6 +208,7 @@ clocks and IDs.
        pll4_post_div           193
        pll5_post_div           194
        pll5_video_div          195
+        eim_slow                196
 Examples:
diff --git a/Documentation/devicetree/bindings/clock/imx6sl-clock.txt b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
new file mode 100644
index 000000000000..15e40bdf147d
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/imx6sl-clock.txt
@@ -0,0 +1,10 @@
+* Clock bindings for Freescale i.MX6 SoloLite
+Required properties:
+- compatible: Should be "fsl,imx6sl-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell.  See include/dt-bindings/clock/imx6sl-clock.h
+for the full list of i.MX6 SoloLite clock IDs.
diff --git a/Documentation/devicetree/bindings/clock/nspire-clock.txt b/Documentation/devicetree/bindings/clock/nspire-clock.txt
new file mode 100644
index 000000000000..7c3bc8bb5b9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nspire-clock.txt
@@ -0,0 +1,24 @@
+TI-NSPIRE Clocks
+Required properties:
+- compatible: Valid compatible properties include:
+        "lsi,nspire-cx-ahb-divider" for the AHB divider in the CX model
+        "lsi,nspire-classic-ahb-divider" for the AHB divider in the older model
+        "lsi,nspire-cx-clock" for the base clock in the CX model
+        "lsi,nspire-classic-clock" for the base clock in the older model
+- reg: Physical base address of the controller and length of memory mapped
+        region.
+Optional:
+- clocks: For the "nspire-*-ahb-divider" compatible clocks, this is the parent
+        clock where it divides the rate from.
+Example:
+ahb_clk {
+        #clock-cells = <0>;
+        compatible = "lsi,nspire-cx-clock";
+        reg = <0x900B0000 0x4>;
+        clocks = <&base_clk>;
+};
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
index d6cb083b90a2..0c80c2677104 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra114-car.txt
@@ -12,253 +12,9 @@ Required properties :
 - 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.
+  In clock consumers, this cell represents the clock ID exposed by the
+  CAR. The assignments may be found in header file
-  The first 160 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  <dt-bindings/clock/tegra114-car.h>.
-  registers. These IDs often match those in the CAR's RST_DEVICES registers,
-  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
-  this case, those clocks are assigned IDs above 160 in order to highlight
-  this issue. Implementations that interpret these clock IDs as bit values
-  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
-  explicitly handle these special cases.
-  The balance of the clocks controlled by the CAR are assigned IDs of 160 and
-  above.
-  0     unassigned
-  1     unassigned
-  2     unassigned
-  3     unassigned
-  4     rtc
-  5     timer
-  6     uarta
-  7     unassigned      (register bit affects uartb and vfir)
-  8     unassigned
-  9     sdmmc2
-  10    unassigned      (register bit affects spdif_in and spdif_out)
-  11    i2s1
-  12    i2c1
-  13    ndflash
-  14    sdmmc1
-  15    sdmmc4
-  16    unassigned
-  17    pwm
-  18    i2s2
-  19    epp
-  20    unassigned      (register bit affects vi and vi_sensor)
-  21    2d
-  22    usbd
-  23    isp
-  24    3d
-  25    unassigned
-  26    disp2
-  27    disp1
-  28    host1x
-  29    vcp
-  30    i2s0
-  31    unassigned
-  32    unassigned
-  33    unassigned
-  34    apbdma
-  35    unassigned
-  36    kbc
-  37    unassigned
-  38    unassigned
-  39    unassigned      (register bit affects fuse and fuse_burn)
-  40    kfuse
-  41    sbc1
-  42    nor
-  43    unassigned
-  44    sbc2
-  45    unassigned
-  46    sbc3
-  47    i2c5
-  48    dsia
-  49    unassigned
-  50    mipi
-  51    hdmi
-  52    csi
-  53    unassigned
-  54    i2c2
-  55    uartc
-  56    mipi-cal
-  57    emc
-  58    usb2
-  59    usb3
-  60    msenc
-  61    vde
-  62    bsea
-  63    bsev
-  64    unassigned
-  65    uartd
-  66    unassigned
-  67    i2c3
-  68    sbc4
-  69    sdmmc3
-  70    unassigned
-  71    owr
-  72    afi
-  73    csite
-  74    unassigned
-  75    unassigned
-  76    la
-  77    trace
-  78    soc_therm
-  79    dtv
-  80    ndspeed
-  81    i2cslow
-  82    dsib
-  83    tsec
-  84    unassigned
-  85    unassigned
-  86    unassigned
-  87    unassigned
-  88    unassigned
-  89    xusb_host
-  90    unassigned
-  91    msenc
-  92    csus
-  93    unassigned
-  94    unassigned
-  95    unassigned      (bit affects xusb_dev and xusb_dev_src)
-  96    unassigned
-  97    unassigned
-  98    unassigned
-  99    mselect
-  100   tsensor
-  101   i2s3
-  102   i2s4
-  103   i2c4
-  104   sbc5
-  105   sbc6
-  106   d_audio
-  107   apbif
-  108   dam0
-  109   dam1
-  110   dam2
-  111   hda2codec_2x
-  112   unassigned
-  113   audio0_2x
-  114   audio1_2x
-  115   audio2_2x
-  116   audio3_2x
-  117   audio4_2x
-  118   spdif_2x
-  119   actmon
-  120   extern1
-  121   extern2
-  122   extern3
-  123   unassigned
-  124   unassigned
-  125   hda
-  126   unassigned
-  127   se
-  128   hda2hdmi
-  129   unassigned
-  130   unassigned
-  131   unassigned
-  132   unassigned
-  133   unassigned
-  134   unassigned
-  135   unassigned
-  136   unassigned
-  137   unassigned
-  138   unassigned
-  139   unassigned
-  140   unassigned
-  141   unassigned
-  142   unassigned
-  143   unassigned      (bit affects xusb_falcon_src, xusb_fs_src,
-                         xusb_host_src and xusb_ss_src)
-  144   cilab
-  145   cilcd
-  146   cile
-  147   dsialp
-  148   dsiblp
-  149   unassigned
-  150   dds
-  151   unassigned
-  152   dp2
-  153   amx
-  154   adx
-  155   unassigned      (bit affects dfll_ref and dfll_soc)
-  156   xusb_ss
-  192   uartb
-  193   vfir
-  194   spdif_in
-  195   spdif_out
-  196   vi
-  197   vi_sensor
-  198   fuse
-  199   fuse_burn
-  200   clk_32k
-  201   clk_m
-  202   clk_m_div2
-  203   clk_m_div4
-  204   pll_ref
-  205   pll_c
-  206   pll_c_out1
-  207   pll_c2
-  208   pll_c3
-  209   pll_m
-  210   pll_m_out1
-  211   pll_p
-  212   pll_p_out1
-  213   pll_p_out2
-  214   pll_p_out3
-  215   pll_p_out4
-  216   pll_a
-  217   pll_a_out0
-  218   pll_d
-  219   pll_d_out0
-  220   pll_d2
-  221   pll_d2_out0
-  222   pll_u
-  223   pll_u_480M
-  224   pll_u_60M
-  225   pll_u_48M
-  226   pll_u_12M
-  227   pll_x
-  228   pll_x_out0
-  229   pll_re_vco
-  230   pll_re_out
-  231   pll_e_out0
-  232   spdif_in_sync
-  233   i2s0_sync
-  234   i2s1_sync
-  235   i2s2_sync
-  236   i2s3_sync
-  237   i2s4_sync
-  238   vimclk_sync
-  239   audio0
-  240   audio1
-  241   audio2
-  242   audio3
-  243   audio4
-  244   spdif
-  245   clk_out_1
-  246   clk_out_2
-  247   clk_out_3
-  248   blink
-  252   xusb_host_src
-  253   xusb_falcon_src
-  254   xusb_fs_src
-  255   xusb_ss_src
-  256   xusb_dev_src
-  257   xusb_dev
-  258   xusb_hs_src
-  259   sclk
-  260   hclk
-  261   pclk
-  262   cclk_g
-  263   cclk_lp
-  264   dfll_ref
-  265   dfll_soc
 Example SoC include file:
@@ -270,7 +26,7 @@ Example SoC include file:
        };
        usb@c5004000 {
-                clocks = <&tegra_car 58>; /* usb2 */
+                clocks = <&tegra_car TEGRA114_CLK_USB2>;
        };
 };
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
index e885680f6b45..fcfed5bf73fb 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.txt
@@ -12,155 +12,9 @@ Required properties :
 - 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.
+  In clock consumers, this cell represents the clock ID exposed by the
+  CAR. The assignments may be found in header file
-  The first 96 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  <dt-bindings/clock/tegra20-car.h>.
-  registers. These IDs often match those in the CAR's RST_DEVICES registers,
-  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
-  this case, those clocks are assigned IDs above 95 in order to highlight
-  this issue. Implementations that interpret these clock IDs as bit values
-  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
-  explicitly handle these special cases.
-  The balance of the clocks controlled by the CAR are assigned IDs of 96 and
-  above.
-  0     cpu
-  1     unassigned
-  2     unassigned
-  3     ac97
-  4     rtc
-  5     tmr
-  6     uart1
-  7     unassigned      (register bit affects uart2 and vfir)
-  8     gpio
-  9     sdmmc2
-  10    unassigned      (register bit affects spdif_in and spdif_out)
-  11    i2s1
-  12    i2c1
-  13    ndflash
-  14    sdmmc1
-  15    sdmmc4
-  16    twc
-  17    pwm
-  18    i2s2
-  19    epp
-  20    unassigned      (register bit affects vi and vi_sensor)
-  21    2d
-  22    usbd
-  23    isp
-  24    3d
-  25    ide
-  26    disp2
-  27    disp1
-  28    host1x
-  29    vcp
-  30    unassigned
-  31    cache2
-  32    mem
-  33    ahbdma
-  34    apbdma
-  35    unassigned
-  36    kbc
-  37    stat_mon
-  38    pmc
-  39    fuse
-  40    kfuse
-  41    sbc1
-  42    snor
-  43    spi1
-  44    sbc2
-  45    xio
-  46    sbc3
-  47    dvc
-  48    dsi
-  49    unassigned      (register bit affects tvo and cve)
-  50    mipi
-  51    hdmi
-  52    csi
-  53    tvdac
-  54    i2c2
-  55    uart3
-  56    unassigned
-  57    emc
-  58    usb2
-  59    usb3
-  60    mpe
-  61    vde
-  62    bsea
-  63    bsev
-  64    speedo
-  65    uart4
-  66    uart5
-  67    i2c3
-  68    sbc4
-  69    sdmmc3
-  70    pcie
-  71    owr
-  72    afi
-  73    csite
-  74    unassigned
-  75    avpucq
-  76    la
-  77    unassigned
-  78    unassigned
-  79    unassigned
-  80    unassigned
-  81    unassigned
-  82    unassigned
-  83    unassigned
-  84    irama
-  85    iramb
-  86    iramc
-  87    iramd
-  88    cram2
-  89    audio_2x        a/k/a audio_2x_sync_clk
-  90    clk_d
-  91    unassigned
-  92    sus
-  93    cdev2
-  94    cdev1
-  95    unassigned
-  96    uart2
-  97    vfir
-  98    spdif_in
-  99    spdif_out
-  100   vi
-  101   vi_sensor
-  102   tvo
-  103   cve
-  104   osc
-  105   clk_32k         a/k/a clk_s
-  106   clk_m
-  107   sclk
-  108   cclk
-  109   hclk
-  110   pclk
-  111   blink
-  112   pll_a
-  113   pll_a_out0
-  114   pll_c
-  115   pll_c_out1
-  116   pll_d
-  117   pll_d_out0
-  118   pll_e
-  119   pll_m
-  120   pll_m_out1
-  121   pll_p
-  122   pll_p_out1
-  123   pll_p_out2
-  124   pll_p_out3
-  125   pll_p_out4
-  126   pll_s
-  127   pll_u
-  128   pll_x
-  129   cop             a/k/a avp
-  130   audio           a/k/a audio_sync_clk
-  131   pll_ref
-  132   twd
 Example SoC include file:
@@ -172,7 +26,7 @@ Example SoC include file:
        };
        usb@c5004000 {
-                clocks = <&tegra_car 58>; /* usb2 */
+                clocks = <&tegra_car TEGRA20_CLK_USB2>;
        };
 };
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
index f3da3be5fcad..0f714081e986 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
@@ -12,212 +12,9 @@ Required properties :
 - 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.
+  In clock consumers, this cell represents the clock ID exposed by the
+  CAR. The assignments may be found in header file
-  The first 130 clocks are numbered to match the bits in the CAR's CLK_OUT_ENB
+  <dt-bindings/clock/tegra30-car.h>.
-  registers. These IDs often match those in the CAR's RST_DEVICES registers,
-  but not in all cases. Some bits in CLK_OUT_ENB affect multiple clocks. In
-  this case, those clocks are assigned IDs above 160 in order to highlight
-  this issue. Implementations that interpret these clock IDs as bit values
-  within the CLK_OUT_ENB or RST_DEVICES registers should be careful to
-  explicitly handle these special cases.
-  The balance of the clocks controlled by the CAR are assigned IDs of 160 and
-  above.
-  0     cpu
-  1     unassigned
-  2     unassigned
-  3     unassigned
-  4     rtc
-  5     timer
-  6     uarta
-  7     unassigned      (register bit affects uartb and vfir)
-  8     gpio
-  9     sdmmc2
-  10    unassigned      (register bit affects spdif_in and spdif_out)
-  11    i2s1
-  12    i2c1
-  13    ndflash
-  14    sdmmc1
-  15    sdmmc4
-  16    unassigned
-  17    pwm
-  18    i2s2
-  19    epp
-  20    unassigned      (register bit affects vi and vi_sensor)
-  21    2d
-  22    usbd
-  23    isp
-  24    3d
-  25    unassigned
-  26    disp2
-  27    disp1
-  28    host1x
-  29    vcp
-  30    i2s0
-  31    cop_cache
-  32    mc
-  33    ahbdma
-  34    apbdma
-  35    unassigned
-  36    kbc
-  37    statmon
-  38    pmc
-  39    unassigned      (register bit affects fuse and fuse_burn)
-  40    kfuse
-  41    sbc1
-  42    nor
-  43    unassigned
-  44    sbc2
-  45    unassigned
-  46    sbc3
-  47    i2c5
-  48    dsia
-  49    unassigned      (register bit affects cve and tvo)
-  50    mipi
-  51    hdmi
-  52    csi
-  53    tvdac
-  54    i2c2
-  55    uartc
-  56    unassigned
-  57    emc
-  58    usb2
-  59    usb3
-  60    mpe
-  61    vde
-  62    bsea
-  63    bsev
-  64    speedo
-  65    uartd
-  66    uarte
-  67    i2c3
-  68    sbc4
-  69    sdmmc3
-  70    pcie
-  71    owr
-  72    afi
-  73    csite
-  74    pciex
-  75    avpucq
-  76    la
-  77    unassigned
-  78    unassigned
-  79    dtv
-  80    ndspeed
-  81    i2cslow
-  82    dsib
-  83    unassigned
-  84    irama
-  85    iramb
-  86    iramc
-  87    iramd
-  88    cram2
-  89    unassigned
-  90    audio_2x        a/k/a audio_2x_sync_clk
-  91    unassigned
-  92    csus
-  93    cdev2
-  94    cdev1
-  95    unassigned
-  96    cpu_g
-  97    cpu_lp
-  98    3d2
-  99    mselect
-  100   tsensor
-  101   i2s3
-  102   i2s4
-  103   i2c4
-  104   sbc5
-  105   sbc6
-  106   d_audio
-  107   apbif
-  108   dam0
-  109   dam1
-  110   dam2
-  111   hda2codec_2x
-  112   atomics
-  113   audio0_2x
-  114   audio1_2x
-  115   audio2_2x
-  116   audio3_2x
-  117   audio4_2x
-  118   audio5_2x
-  119   actmon
-  120   extern1
-  121   extern2
-  122   extern3
-  123   sata_oob
-  124   sata
-  125   hda
-  127   se
-  128   hda2hdmi
-  129   sata_cold
-  160   uartb
-  161   vfir
-  162   spdif_in
-  163   spdif_out
-  164   vi
-  165   vi_sensor
-  166   fuse
-  167   fuse_burn
-  168   cve
-  169   tvo
-  170   clk_32k
-  171   clk_m
-  172   clk_m_div2
-  173   clk_m_div4
-  174   pll_ref
-  175   pll_c
-  176   pll_c_out1
-  177   pll_m
-  178   pll_m_out1
-  179   pll_p
-  180   pll_p_out1
-  181   pll_p_out2
-  182   pll_p_out3
-  183   pll_p_out4
-  184   pll_a
-  185   pll_a_out0
-  186   pll_d
-  187   pll_d_out0
-  188   pll_d2
-  189   pll_d2_out0
-  190   pll_u
-  191   pll_x
-  192   pll_x_out0
-  193   pll_e
-  194   spdif_in_sync
-  195   i2s0_sync
-  196   i2s1_sync
-  197   i2s2_sync
-  198   i2s3_sync
-  199   i2s4_sync
-  200   vimclk
-  201   audio0
-  202   audio1
-  203   audio2
-  204   audio3
-  205   audio4
-  206   audio5
-  207   clk_out_1 (extern1)
-  208   clk_out_2 (extern2)
-  209   clk_out_3 (extern3)
-  210   sclk
-  211   blink
-  212   cclk_g
-  213   cclk_lp
-  214   twd
-  215   cml0
-  216   cml1
-  217   hclk
-  218   pclk
 Example SoC include file:
@@ -229,7 +26,7 @@ Example SoC include file:
        };
        usb@c5004000 {
-                clocks = <&tegra_car 58>; /* usb2 */
+                clocks = <&tegra_car TEGRA30_CLK_USB2>;
        };
 };
diff --git a/Documentation/devicetree/bindings/clock/rockchip.txt b/Documentation/devicetree/bindings/clock/rockchip.txt
new file mode 100644
index 000000000000..a891c823ed44
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/rockchip.txt
@@ -0,0 +1,74 @@
+Device Tree Clock bindings for arch-rockchip
+This binding uses the common clock binding[1].
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+== Gate clocks ==
+The gate registers form a continuos block which makes the dt node
+structure a matter of taste, as either all gates can be put into
+one gate clock spanning all registers or they can be divided into
+the 10 individual gates containing 16 clocks each.
+The code supports both approaches.
+Required properties:
+- compatible : "rockchip,rk2928-gate-clk"
+- reg : shall be the control register address(es) for the clock.
+- #clock-cells : from common clock binding; shall be set to 1
+- clock-output-names : the corresponding gate names that the clock controls
+- clocks : should contain the parent clock for each individual gate,
+  therefore the number of clocks elements should match the number of
+  clock-output-names
+Example using multiple gate clocks:
+                clk_gates0: gate-clk@200000d0 {
+                        compatible = "rockchip,rk2928-gate-clk";
+                        reg = <0x200000d0 0x4>;
+                        clocks = <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>,
+                                 <&dummy>, <&dummy>;
+                        clock-output-names =
+                                "gate_core_periph", "gate_cpu_gpll",
+                                "gate_ddrphy", "gate_aclk_cpu",
+                                "gate_hclk_cpu", "gate_pclk_cpu",
+                                "gate_atclk_cpu", "gate_i2s0",
+                                "gate_i2s0_frac", "gate_i2s1",
+                                "gate_i2s1_frac", "gate_i2s2",
+                                "gate_i2s2_frac", "gate_spdif",
+                                "gate_spdif_frac", "gate_testclk";
+                        #clock-cells = <1>;
+                };
+                clk_gates1: gate-clk@200000d4 {
+                        compatible = "rockchip,rk2928-gate-clk";
+                        reg = <0x200000d4 0x4>;
+                        clocks = <&xin24m>, <&xin24m>,
+                                 <&xin24m>, <&dummy>,
+                                 <&dummy>, <&xin24m>,
+                                 <&xin24m>, <&dummy>,
+                                 <&xin24m>, <&dummy>,
+                                 <&xin24m>, <&dummy>,
+                                 <&xin24m>, <&dummy>,
+                                 <&xin24m>, <&dummy>;
+                        clock-output-names =
+                                "gate_timer0", "gate_timer1",
+                                "gate_timer2", "gate_jtag",
+                                "gate_aclk_lcdc1_src", "gate_otgphy0",
+                                "gate_otgphy1", "gate_ddr_gpll",
+                                "gate_uart0", "gate_frac_uart0",
+                                "gate_uart1", "gate_frac_uart1",
+                                "gate_uart2", "gate_frac_uart2",
+                                "gate_uart3", "gate_frac_uart3";
+                        #clock-cells = <1>;
+                };
diff --git a/Documentation/devicetree/bindings/clock/silabs,si5351.txt b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
index cc374651662c..c40711e8e8f7 100644
--- a/Documentation/devicetree/bindings/clock/silabs,si5351.txt
+++ b/Documentation/devicetree/bindings/clock/silabs,si5351.txt
@@ -4,7 +4,7 @@ Reference
 [1] Si5351A/B/C Data Sheet
    http://www.silabs.com/Support%20Documents/TechnicalDocs/Si5351.pdf
-The Si5351a/b/c are programmable i2c clock generators with upto 8 output
+The Si5351a/b/c are programmable i2c clock generators with up to 8 output
 clocks. Si5351a also has a reduced pin-count package (MSOP10) where only
 3 output clocks are accessible. The internal structure of the clock
 generators can be found in [1].
@@ -44,6 +44,11 @@ Optional child node properties:
 - silabs,multisynth-source: source pll A(0) or B(1) of corresponding multisynth
  divider.
 - silabs,pll-master: boolean, multisynth can change pll frequency.
+- silabs,disable-state : clock output disable state, shall be
+  0 = clock output is driven LOW when disabled
+  1 = clock output is driven HIGH when disabled
+  2 = clock output is FLOATING (HIGH-Z) when disabled
+  3 = clock output is NEVER disabled
 ==Example==
diff --git a/Documentation/devicetree/bindings/clock/st,nomadik.txt b/Documentation/devicetree/bindings/clock/st,nomadik.txt
new file mode 100644
index 000000000000..7fc09773de46
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st,nomadik.txt
@@ -0,0 +1,104 @@
+ST Microelectronics Nomadik SRC System Reset and Control
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+The Nomadik SRC controller is responsible of controlling chrystals,
+PLLs and clock gates.
+Required properties for the SRC node:
+- compatible: must be "stericsson,nomadik-src"
+- reg: must contain the SRC register base and size
+Optional properties for the SRC node:
+- disable-sxtalo: if present this will disable the SXTALO
+  i.e. the driver output for the slow 32kHz chrystal, if the
+  board has its own circuitry for providing this oscillator
+- disable-mxtal: if present this will disable the MXTALO,
+  i.e. the driver output for the main (~19.2 MHz) chrystal,
+  if the board has its own circuitry for providing this
+  osciallator
+PLL nodes: these nodes represent the two PLLs on the system,
+which should both have the main chrystal, represented as a
+fixed frequency clock, as parent.
+Required properties for the two PLL nodes:
+- compatible: must be "st,nomadik-pll-clock"
+- clock-cells: must be 0
+- clock-id: must be 1 or 2 for PLL1 and PLL2 respectively
+- clocks: this clock will have main chrystal as parent
+HCLK nodes: these represent the clock gates on individual
+lines from the HCLK clock tree and the gate for individual
+lines from the PCLK clock tree.
+Requires properties for the HCLK nodes:
+- compatible: must be "st,nomadik-hclk-clock"
+- clock-cells: must be 0
+- clock-id: must be the clock ID from 0 to 63 according to
+  this table:
+        0:  HCLKDMA0
+        1:  HCLKSMC
+        2:  HCLKSDRAM
+        3:  HCLKDMA1
+        4:  HCLKCLCD
+        5:  PCLKIRDA
+        6:  PCLKSSP
+        7:  PCLKUART0
+        8:  PCLKSDI
+        9:  PCLKI2C0
+        10: PCLKI2C1
+        11: PCLKUART1
+        12: PCLMSP0
+        13: HCLKUSB
+        14: HCLKDIF
+        15: HCLKSAA
+        16: HCLKSVA
+        17: PCLKHSI
+        18: PCLKXTI
+        19: PCLKUART2
+        20: PCLKMSP1
+        21: PCLKMSP2
+        22: PCLKOWM
+        23: HCLKHPI
+        24: PCLKSKE
+        25: PCLKHSEM
+        26: HCLK3D
+        27: HCLKHASH
+        28: HCLKCRYP
+        29: PCLKMSHC
+        30: HCLKUSBM
+        31: HCLKRNG
+        (32, 33, 34, 35 RESERVED)
+        36: CLDCLK
+        37: IRDACLK
+        38: SSPICLK
+        39: UART0CLK
+        40: SDICLK
+        41: I2C0CLK
+        42: I2C1CLK
+        43: UART1CLK
+        44: MSPCLK0
+        45: USBCLK
+        46: DIFCLK
+        47: IPI2CCLK
+        48: IPBMCCLK
+        49: HSICLKRX
+        50: HSICLKTX
+        51: UART2CLK
+        52: MSPCLK1
+        53: MSPCLK2
+        54: OWMCLK
+        (55 RESERVED)
+        56: SKECLK
+        (57 RESERVED)
+        58: 3DCLK
+        59: PCLKMSP3
+        60: MSPCLK3
+        61: MSHCCLK
+        62: USBMCLK
+        63: RNGCCLK
diff --git a/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt
new file mode 100644
index 000000000000..7cafcb98ead7
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/ste-u300-syscon-clock.txt
@@ -0,0 +1,80 @@
+Clock bindings for ST-Ericsson U300 System Controller Clocks
+Bindings for the gated system controller clocks:
+Required properties:
+- compatible: must be "stericsson,u300-syscon-clk"
+- #clock-cells: must be <0>
+- clock-type: specifies the type of clock:
+  0 = slow clock
+  1 = fast clock
+  2 = rest/remaining clock
+- clock-id: specifies the clock in the type range
+Optional properties:
+- clocks: parent clock(s)
+The available clocks per type are as follows:
+Type:  ID:   Clock:
+-------------------
+0      0     Slow peripheral bridge clock
+0      1     UART0 clock
+0      4     GPIO clock
+0      6     RTC clock
+0      7     Application timer clock
+0      8     Access timer clock
+1      0     Fast peripheral bridge clock
+1      1     I2C bus 0 clock
+1      2     I2C bus 1 clock
+1      5     MMC interface peripheral (silicon) clock
+1      6     SPI clock
+2      3     CPU clock
+2      4     DMA controller clock
+2      5     External Memory Interface (EMIF) clock
+2      6     NAND flask interface clock
+2      8     XGAM graphics engine clock
+2      9     Shared External Memory Interface (SEMI) clock
+2      10    AHB Subsystem Bridge clock
+2      12    Interrupt controller clock
+Example:
+gpio_clk: gpio_clk@13M {
+        #clock-cells = <0>;
+        compatible = "stericsson,u300-syscon-clk";
+        clock-type = <0>; /* Slow */
+        clock-id = <4>;
+        clocks = <&slow_clk>;
+};
+gpio: gpio@c0016000 {
+        compatible = "stericsson,gpio-coh901";
+        (...)
+        clocks = <&gpio_clk>;
+};
+Bindings for the MMC/SD card clock:
+Required properties:
+- compatible: must be "stericsson,u300-syscon-mclk"
+- #clock-cells: must be <0>
+Optional properties:
+- clocks: parent clock(s)
+mmc_mclk: mmc_mclk {
+        #clock-cells = <0>;
+        compatible = "stericsson,u300-syscon-mclk";
+        clocks = <&mmc_pclk>;
+};
+mmcsd: mmcsd@c0001000 {
+        compatible = "arm,pl18x", "arm,primecell";
+        clocks = <&mmc_pclk>, <&mmc_mclk>;
+        clock-names = "apb_pclk", "mclk";
+        (...)
+};
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 729f52426fe1..d495521a79d2 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -12,22 +12,30 @@ Required properties:
        "allwinner,sun4i-axi-clk" - for the AXI clock
        "allwinner,sun4i-axi-gates-clk" - for the AXI gates
        "allwinner,sun4i-ahb-clk" - for the AHB clock
-        "allwinner,sun4i-ahb-gates-clk" - for the AHB gates
+        "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
+        "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
        "allwinner,sun4i-apb0-clk" - for the APB0 clock
-        "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates
+        "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
+        "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
        "allwinner,sun4i-apb1-clk" - for the APB1 clock
        "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
-        "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates
+        "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
+        "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
 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
 - #clock-cells : from common clock binding; shall be set to 0 except for
-        "allwinner,sun4i-*-gates-clk" where it shall be set to 1
+        "allwinner,*-gates-clk" where it shall be set to 1
-Additionally, "allwinner,sun4i-*-gates-clk" clocks require:
+Additionally, "allwinner,*-gates-clk" clocks require:
 - clock-output-names : the corresponding gate names that the clock controls
+Clock consumers should specify the desired clocks they use with a
+"clocks" phandle cell. Consumers that are using a gated clock should
+provide an additional ID in their clock property. The values of this
+ID are documented in sunxi/<soc>-gates.txt.
 For example:
 osc24M: osc24M@01c20050 {
@@ -50,102 +58,3 @@ cpu: cpu@01c20054 {
        reg = <0x01c20054 0x4>;
        clocks = <&osc32k>, <&osc24M>, <&pll1>;
 };
-Gate clock outputs
-The "allwinner,sun4i-*-gates-clk" clocks provide several gatable outputs;
-their corresponding offsets as present on sun4i are listed below. Note that
-some of these gates are not present on sun5i.
-  * AXI gates ("allwinner,sun4i-axi-gates-clk")
-    DRAM                                                                0
-  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
-    USB0                                                                0
-    EHCI0                                                               1
-    OHCI0                                                               2*
-    EHCI1                                                               3
-    OHCI1                                                               4*
-    SS                                                                  5
-    DMA                                                                 6
-    BIST                                                                7
-    MMC0                                                                8
-    MMC1                                                                9
-    MMC2                                                                10
-    MMC3                                                                11
-    MS                                                                  12**
-    NAND                                                                13
-    SDRAM                                                               14
-    ACE                                                                 16
-    EMAC                                                                17
-    TS                                                                  18
-    SPI0                                                                20
-    SPI1                                                                21
-    SPI2                                                                22
-    SPI3                                                                23
-    PATA                                                                24
-    SATA                                                                25**
-    GPS                                                                 26*
-    VE                                                                  32
-    TVD                                                                 33
-    TVE0                                                                34
-    TVE1                                                                35
-    LCD0                                                                36
-    LCD1                                                                37
-    CSI0                                                                40
-    CSI1                                                                41
-    HDMI                                                                43
-    DE_BE0                                                              44
-    DE_BE1                                                              45
-    DE_FE0                                                              46
-    DE_FE1                                                              47
-    MP                                                                  50
-    MALI400                                                             52
-  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
-    CODEC                                                               0
-    SPDIF                                                               1*
-    AC97                                                                2
-    IIS                                                                 3
-    PIO                                                                 5
-    IR0                                                                 6
-    IR1                                                                 7
-    KEYPAD                                                              10
-  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
-    I2C0                                                                0
-    I2C1                                                                1
-    I2C2                                                                2
-    CAN                                                                 4
-    SCR                                                                 5
-    PS20                                                                6
-    PS21                                                                7
-    UART0                                                               16
-    UART1                                                               17
-    UART2                                                               18
-    UART3                                                               19
-    UART4                                                               20
-    UART5                                                               21
-    UART6                                                               22
-    UART7                                                               23
-Notation:
- [*]:  The datasheet didn't mention these, but they are present on AW code
- [**]: The datasheet had this marked as "NC" but they are used on AW code
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
new file mode 100644
index 000000000000..6a03475bbfe2
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
@@ -0,0 +1,93 @@
+Gate clock outputs
+------------------
+  * AXI gates ("allwinner,sun4i-axi-gates-clk")
+    DRAM                                        0
+  * AHB gates ("allwinner,sun4i-ahb-gates-clk")
+    USB0                                        0
+    EHCI0                                       1
+    OHCI0                                       2*
+    EHCI1                                       3
+    OHCI1                                       4*
+    SS                                          5
+    DMA                                         6
+    BIST                                        7
+    MMC0                                        8
+    MMC1                                        9
+    MMC2                                        10
+    MMC3                                        11
+    MS                                          12**
+    NAND                                        13
+    SDRAM                                       14
+    ACE                                         16
+    EMAC                                        17
+    TS                                          18
+    SPI0                                        20
+    SPI1                                        21
+    SPI2                                        22
+    SPI3                                        23
+    PATA                                        24
+    SATA                                        25**
+    GPS                                         26*
+    VE                                          32
+    TVD                                         33
+    TVE0                                        34
+    TVE1                                        35
+    LCD0                                        36
+    LCD1                                        37
+    CSI0                                        40
+    CSI1                                        41
+    HDMI                                        43
+    DE_BE0                                      44
+    DE_BE1                                      45
+    DE_FE1                                      46
+    DE_FE1                                      47
+    MP                                          50
+    MALI400                                     52
+  * APB0 gates ("allwinner,sun4i-apb0-gates-clk")
+    CODEC                                       0
+    SPDIF                                       1*
+    AC97                                        2
+    IIS                                         3
+    PIO                                         5
+    IR0                                         6
+    IR1                                         7
+    KEYPAD                                      10
+  * APB1 gates ("allwinner,sun4i-apb1-gates-clk")
+    I2C0                                        0
+    I2C1                                        1
+    I2C2                                        2
+    CAN                                         4
+    SCR                                         5
+    PS20                                        6
+    PS21                                        7
+    UART0                                       16
+    UART1                                       17
+    UART2                                       18
+    UART3                                       19
+    UART4                                       20
+    UART5                                       21
+    UART6                                       22
+    UART7                                       23
+Notation:
+ [*]:  The datasheet didn't mention these, but they are present on AW code
+ [**]: The datasheet had this marked as "NC" but they are used on AW code
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
new file mode 100644
index 000000000000..006b6dfc4703
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
@@ -0,0 +1,58 @@
+Gate clock outputs
+------------------
+  * AXI gates ("allwinner,sun4i-axi-gates-clk")
+    DRAM                                        0
+  * AHB gates ("allwinner,sun5i-a13-ahb-gates-clk")
+    USBOTG                                      0
+    EHCI                                        1
+    OHCI                                        2
+    SS                                          5
+    DMA                                         6
+    BIST                                        7
+    MMC0                                        8
+    MMC1                                        9
+    MMC2                                        10
+    NAND                                        13
+    SDRAM                                       14
+    SPI0                                        20
+    SPI1                                        21
+    SPI2                                        22
+    STIMER                                      28
+    VE                                          32
+    LCD                                         36
+    CSI                                         40
+    DE_BE                                       44
+    DE_FE                                       46
+    IEP                                         51
+    MALI400                                     52
+  * APB0 gates ("allwinner,sun5i-a13-apb0-gates-clk")
+    CODEC                                       0
+    PIO                                         5
+    IR                                          6
+  * APB1 gates ("allwinner,sun5i-a13-apb1-gates-clk")
+    I2C0                                        0
+    I2C1                                        1
+    I2C2                                        2
+    UART1                                       17
+    UART3                                       19
diff --git a/Documentation/devicetree/bindings/clock/vf610-clock.txt b/Documentation/devicetree/bindings/clock/vf610-clock.txt
new file mode 100644
index 000000000000..c80863d344ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/vf610-clock.txt
@@ -0,0 +1,26 @@
+* Clock bindings for Freescale Vybrid VF610 SOC
+Required properties:
+- compatible: Should be "fsl,vf610-ccm"
+- reg: Address and length of the register set
+- #clock-cells: Should be <1>
+The clock consumer should specify the desired clock by having the clock
+ID in its "clocks" phandle cell. See include/dt-bindings/clock/vf610-clock.h
+for the full list of VF610 clock IDs.
+Examples:
+clks: ccm@4006b000 {
+        compatible = "fsl,vf610-ccm";
+        reg = <0x4006b000 0x1000>;
+        #clock-cells = <1>;
+};
+uart1: serial@40028000 {
+        compatible = "fsl,vf610-uart";
+        reg = <0x40028000 0x1000>;
+        interrupts = <0 62 0x04>;
+        clocks = <&clks VF610_CLK_UART1>;
+        clock-names = "ipg";
+};
diff --git a/Documentation/devicetree/bindings/clock/vt8500.txt b/Documentation/devicetree/bindings/clock/vt8500.txt
index a880c70d0047..91d71cc0314a 100644
--- a/Documentation/devicetree/bindings/clock/vt8500.txt
+++ b/Documentation/devicetree/bindings/clock/vt8500.txt
@@ -8,6 +8,8 @@ Required properties:
 - compatible : shall be one of the following:
        "via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
        "wm,wm8650-pll-clock" - for a WM8650 PLL clock
+        "wm,wm8750-pll-clock" - for a WM8750 PLL clock
+        "wm,wm8850-pll-clock" - for a WM8850 PLL clock
        "via,vt8500-device-clock" - for a VT/WM device clock
 Required properties for PLL clocks:
diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt
index 23ae1db1bc13..d99af878f5d7 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -6,50 +6,99 @@ The purpose of this document is to document their usage.
 See clock_bindings.txt for more information on the generic clock bindings.
 See Chapter 25 of Zynq TRM for more information about Zynq clocks.
-== PLLs ==
+== Clock Controller ==
+The clock controller is a logical abstraction of Zynq's clock tree. It reads
-Used to describe the ARM_PLL, DDR_PLL, and IO_PLL.
+required input clock frequencies from the devicetree and acts as clock provider
+for all clock consumers of PS clocks.
 Required properties:
- #clock-cells : shall be 0 (only one clock is output from this node)
+ - #clock-cells : Must be 1
- compatible : "xlnx,zynq-pll"
+ - compatible : "xlnx,ps7-clkc"
- reg : pair of u32 values, which are the address offsets within the SLCR
+ - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
-        of the relevant PLL_CTRL register and PLL_CFG register respectively
+                      (usually 33 MHz oscillators are used for Zynq platforms)
- clocks : phandle for parent clock.  should be the phandle for ps_clk
+ - clock-output-names : List of strings used to name the clock outputs. Shall be
+                        a list of the outputs given below.
 Optional properties:
- clock-output-names : name of the output clock
+ - clocks : as described in the clock bindings
+ - clock-names : as described in the clock bindings
-Example:
-        armpll: armpll {
-                #clock-cells = <0>;
-                compatible = "xlnx,zynq-pll";
-                clocks = <&ps_clk>;
-                reg = <0x100 0x110>;
-                clock-output-names = "armpll";
-        };
-== Peripheral clocks ==
-Describes clock node for the SDIO, SMC, SPI, QSPI, and UART clocks.
+Clock inputs:
+The following strings are optional parameters to the 'clock-names' property in
+order to provide an optional (E)MIO clock source.
+ - swdt_ext_clk
+ - gem0_emio_clk
+ - gem1_emio_clk
+ - mio_clk_XX           # with XX = 00..53
+...
-Required properties:
+Clock outputs:
- #clock-cells : shall be 1
+ 0:  armpll
- compatible : "xlnx,zynq-periph-clock"
+ 1:  ddrpll
- reg : a single u32 value, describing the offset within the SLCR where
+ 2:  iopll
-        the CLK_CTRL register is found for this peripheral
+ 3:  cpu_6or4x
- clocks : phandle for parent clocks.  should hold phandles for
+ 4:  cpu_3or2x
-           the IO_PLL, ARM_PLL, and DDR_PLL in order
+ 5:  cpu_2x
- clock-output-names : names of the output clock(s).  For peripherals that have
+ 6:  cpu_1x
-                       two output clocks (for example, the UART), two clocks
+ 7:  ddr2x
-                       should be listed.
+ 8:  ddr3x
+ 9:  dci
+ 10: lqspi
+ 11: smc
+ 12: pcap
+ 13: gem0
+ 14: gem1
+ 15: fclk0
+ 16: fclk1
+ 17: fclk2
+ 18: fclk3
+ 19: can0
+ 20: can1
+ 21: sdio0
+ 22: sdio1
+ 23: uart0
+ 24: uart1
+ 25: spi0
+ 26: spi1
+ 27: dma
+ 28: usb0_aper
+ 29: usb1_aper
+ 30: gem0_aper
+ 31: gem1_aper
+ 32: sdio0_aper
+ 33: sdio1_aper
+ 34: spi0_aper
+ 35: spi1_aper
+ 36: can0_aper
+ 37: can1_aper
+ 38: i2c0_aper
+ 39: i2c1_aper
+ 40: uart0_aper
+ 41: uart1_aper
+ 42: gpio_aper
+ 43: lqspi_aper
+ 44: smc_aper
+ 45: swdt
+ 46: dbg_trc
+ 47: dbg_apb
 Example:
-        uart_clk: uart_clk {
+        clkc: clkc {
                #clock-cells = <1>;
-                compatible = "xlnx,zynq-periph-clock";
+                compatible = "xlnx,ps7-clkc";
-                clocks = <&iopll &armpll &ddrpll>;
+                ps-clk-frequency = <33333333>;
-                reg = <0x154>;
+                clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x",
-                clock-output-names = "uart0_ref_clk",
+                                "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x",
-                                     "uart1_ref_clk";
+                                "dci", "lqspi", "smc", "pcap", "gem0", "gem1",
+                                "fclk0", "fclk1", "fclk2", "fclk3", "can0", "can1",
+                                "sdio0", "sdio1", "uart0", "uart1", "spi0", "spi1",
+                                "dma", "usb0_aper", "usb1_aper", "gem0_aper",
+                                "gem1_aper", "sdio0_aper", "sdio1_aper",
+                                "spi0_aper", "spi1_aper", "can0_aper", "can1_aper",
+                                "i2c0_aper", "i2c1_aper", "uart0_aper", "uart1_aper",
+                                "gpio_aper", "lqspi_aper", "smc_aper", "swdt",
+                                "dbg_trc", "dbg_apb";
+                # optional props
+                clocks = <&clkc 16>, <&clk_foo>;
+                clock-names = "gem1_emio_clk", "can_mio_clk_23";
        };
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index c80e8a3402f0..c280a0e6f42d 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -24,8 +24,11 @@ The three cells in order are:
 1. A phandle pointing to the DMA controller.
 2. The memory interface (16 most significant bits), the peripheral interface
 (16 less significant bits).
-3. The peripheral identifier for the hardware handshaking interface. The
+3. Parameters for the at91 DMA configuration register which are device
-identifier can be different for tx and rx.
+dependant:
+  - bit 7-0: peripheral identifier for the hardware handshaking interface. The
+  identifier can be different for tx and rx.
+  - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 1 for ASAP.
 Example:
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
new file mode 100644
index 000000000000..2717ecb47db9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-dma.txt
@@ -0,0 +1,48 @@
+* Freescale Direct Memory Access (DMA) Controller for i.MX
+This document will only describe differences to the generic DMA Controller and
+DMA request bindings as described in dma/dma.txt .
+* DMA controller
+Required properties:
+- compatible : Should be "fsl,<chip>-dma". chip can be imx1, imx21 or imx27
+- reg : Should contain DMA registers location and length
+- interrupts : First item should be DMA interrupt, second one is optional and
+    should contain DMA Error interrupt
+- #dma-cells : Has to be 1. imx-dma does not support anything else.
+Optional properties:
+- #dma-channels : Number of DMA channels supported. Should be 16.
+- #dma-requests : Number of DMA requests supported.
+Example:
+        dma: dma@10001000 {
+                compatible = "fsl,imx27-dma";
+                reg = <0x10001000 0x1000>;
+                interrupts = <32 33>;
+                #dma-cells = <1>;
+                #dma-channels = <16>;
+        };
+* DMA client
+Clients have to specify the DMA requests with phandles in a list.
+Required properties:
+- dmas: List of one or more DMA request specifiers. One DMA request specifier
+    consists of a phandle to the DMA controller followed by the integer
+    specifiying the request line.
+- dma-names: List of string identifiers for the DMA requests. For the correct
+    names, have a look at the specific client driver.
+Example:
+        sdhci1: sdhci@10013000 {
+                ...
+                dmas = <&dma 7>;
+                dma-names = "rx-tx";
+                ...
+        };
diff --git a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
index d1e3f443e205..68cee4f5539f 100644
--- a/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
+++ b/Documentation/devicetree/bindings/dma/fsl-imx-sdma.txt
@@ -4,14 +4,70 @@ Required properties:
 - compatible : Should be "fsl,<chip>-sdma"
 - reg : Should contain SDMA registers location and length
 - interrupts : Should contain SDMA interrupt
+- #dma-cells : Must be <3>.
+  The first cell specifies the DMA request/event ID.  See details below
+  about the second and third cell.
 - fsl,sdma-ram-script-name : Should contain the full path of SDMA RAM
  scripts firmware
+The second cell of dma phandle specifies the peripheral type of DMA transfer.
+The full ID of peripheral types can be found below.
+        ID      transfer type
+        ---------------------
+        0       MCU domain SSI
+        1       Shared SSI
+        2       MMC
+        3       SDHC
+        4       MCU domain UART
+        5       Shared UART
+        6       FIRI
+        7       MCU domain CSPI
+        8       Shared CSPI
+        9       SIM
+        10      ATA
+        11      CCM
+        12      External peripheral
+        13      Memory Stick Host Controller
+        14      Shared Memory Stick Host Controller
+        15      DSP
+        16      Memory
+        17      FIFO type Memory
+        18      SPDIF
+        19      IPU Memory
+        20      ASRC
+        21      ESAI
+The third cell specifies the transfer priority as below.
+        ID      transfer priority
+        -------------------------
+        0       High
+        1       Medium
+        2       Low
 Examples:
 sdma@83fb0000 {
        compatible = "fsl,imx51-sdma", "fsl,imx35-sdma";
        reg = <0x83fb0000 0x4000>;
        interrupts = <6>;
+        #dma-cells = <3>;
        fsl,sdma-ram-script-name = "sdma-imx51.bin";
 };
+DMA clients connected to the i.MX SDMA controller must use the format
+described in the dma.txt file.
+Examples:
+ssi2: ssi@70014000 {
+        compatible = "fsl,imx51-ssi", "fsl,imx21-ssi";
+        reg = <0x70014000 0x4000>;
+        interrupts = <30>;
+        clocks = <&clks 49>;
+        dmas = <&sdma 24 1 0>,
+               <&sdma 25 1 0>;
+        dma-names = "rx", "tx";
+        fsl,fifo-depth = <15>;
+};
diff --git a/Documentation/devicetree/bindings/dma/shdma.txt b/Documentation/devicetree/bindings/dma/shdma.txt
new file mode 100644
index 000000000000..c15994aa1939
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/shdma.txt
@@ -0,0 +1,75 @@
+* SHDMA Device Tree bindings
+Sh-/r-mobile and r-car systems often have multiple identical DMA controller
+instances, capable of serving any of a common set of DMA slave devices, using
+the same configuration. To describe this topology we require all compatible
+SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible
+DMAC instances have the same number of channels and use the same DMA
+descriptors. Therefore respective DMA DT bindings can also all be placed in the
+multiplexer node. Even if there is only one such DMAC instance on a system, it
+still has to be placed under such a multiplexer node.
+* DMA multiplexer
+Required properties:
+- compatible:   should be "renesas,shdma-mux"
+- #dma-cells:   should be <1>, see "dmas" property below
+Optional properties (currently unused):
+- dma-channels: number of DMA channels
+- dma-requests: number of DMA request signals
+* DMA controller
+Required properties:
+- compatible:   should be "renesas,shdma"
+Example:
+        dmac: dma-mux0 {
+                compatible = "renesas,shdma-mux";
+                #dma-cells = <1>;
+                dma-channels = <6>;
+                dma-requests = <256>;
+                reg = <0 0>;    /* Needed for AUXDATA */
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+                dma0: shdma@fe008020 {
+                        compatible = "renesas,shdma";
+                        reg = <0xfe008020 0x270>,
+                                <0xfe009000 0xc>;
+                        interrupt-parent = <&gic>;
+                        interrupts = <0 34 4
+                                        0 28 4
+                                        0 29 4
+                                        0 30 4
+                                        0 31 4
+                                        0 32 4
+                                        0 33 4>;
+                        interrupt-names = "error",
+                                        "ch0", "ch1", "ch2", "ch3",
+                                        "ch4", "ch5";
+                };
+                dma1: shdma@fe018020 {
+                        ...
+                };
+                dma2: shdma@fe028020 {
+                        ...
+                };
+        };
+* DMA client
+Required properties:
+- dmas:         a list of <[DMA multiplexer phandle] [MID/RID value]> pairs,
+                where MID/RID values are fixed handles, specified in the SoC
+                manual
+- dma-names:    a list of DMA channel names, one per "dmas" entry
+Example:
+        dmas = <&dmac 0xd1
+                &dmac 0xd2>;
+        dma-names = "tx", "rx";
diff --git a/Documentation/devicetree/bindings/dma/ste-coh901318.txt b/Documentation/devicetree/bindings/dma/ste-coh901318.txt
new file mode 100644
index 000000000000..091ad057e9cf
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-coh901318.txt
@@ -0,0 +1,32 @@
+ST-Ericsson COH 901 318 DMA Controller
+This is a DMA controller which has begun as a fork of the
+ARM PL08x PrimeCell VHDL code.
+Required properties:
+- compatible: should be "stericsson,coh901318"
+- reg: register locations and length
+- interrupts: the single DMA IRQ
+- #dma-cells: must be set to <1>, as the channels on the
+  COH 901 318 are simple and identified by a single number
+- dma-channels: the number of DMA channels handled
+Example:
+dmac: dma-controller@c00020000 {
+        compatible = "stericsson,coh901318";
+        reg = <0xc0020000 0x1000>;
+        interrupt-parent = <&vica>;
+        interrupts = <2>;
+        #dma-cells = <1>;
+        dma-channels = <40>;
+};
+Consumers example:
+uart0: serial@c0013000 {
+        compatible = "...";
+        (...)
+        dmas = <&dmac 17 &dmac 18>;
+        dma-names = "tx", "rx";
+};
diff --git a/Documentation/devicetree/bindings/dma/ste-dma40.txt b/Documentation/devicetree/bindings/dma/ste-dma40.txt
new file mode 100644
index 000000000000..bea5b73a7390
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ste-dma40.txt
@@ -0,0 +1,66 @@
+* DMA40 DMA Controller
+Required properties:
+- compatible: "stericsson,dma40"
+- reg: Address range of the DMAC registers
+- reg-names: Names of the above areas to use during resource look-up
+- interrupt: Should contain the DMAC interrupt number
+- #dma-cells: must be <3>
+- memcpy-channels: Channels to be used for memcpy
+Optional properties:
+- dma-channels: Number of channels supported by hardware - if not present
+                the driver will attempt to obtain the information from H/W
+- disabled-channels: Channels which can not be used
+Example:
+        dma: dma-controller@801C0000 {
+                compatible = "stericsson,db8500-dma40", "stericsson,dma40";
+                reg = <0x801C0000 0x1000  0x40010000 0x800>;
+                reg-names = "base", "lcpa";
+                interrupt-parent = <&intc>;
+                interrupts = <0 25 0x4>;
+                #dma-cells = <2>;
+                memcpy-channels  = <56 57 58 59 60>;
+                disabled-channels  = <12>;
+                dma-channels = <8>;
+        };
+Clients
+Required properties:
+- dmas: Comma separated list of dma channel requests
+- dma-names: Names of the aforementioned requested channels
+Each dmas request consists of 4 cells:
+  1. A phandle pointing to the DMA controller
+  2. Device Type
+  3. The DMA request line number (only when 'use fixed channel' is set)
+  4. A 32bit mask specifying; mode, direction and endianess [NB: This list will grow]
+        0x00000001: Mode:
+                Logical channel when unset
+                Physical channel when set
+        0x00000002: Direction:
+                Memory to Device when unset
+                Device to Memory when set
+        0x00000004: Endianess:
+                Little endian when unset
+                Big endian when set
+        0x00000008: Use fixed channel:
+                Use automatic channel selection when unset
+                Use DMA request line number when set
+Example:
+        uart@80120000 {
+                compatible = "arm,pl011", "arm,primecell";
+                reg = <0x80120000 0x1000>;
+                interrupts = <0 11 0x4>;
+                dmas = <&dma 13 0 0x2>, /* Logical - DevToMem */
+                       <&dma 13 0 0x0>; /* Logical - MemToDev */
+                dma-names = "rx", "rx";
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt
new file mode 100644
index 000000000000..9fbbdb783a72
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-edma.txt
@@ -0,0 +1,34 @@
+TI EDMA
+Required properties:
+- compatible : "ti,edma3"
+- ti,edma-regions: Number of regions
+- ti,edma-slots: Number of slots
+- #dma-cells: Should be set to <1>
+              Clients should use a single channel number per DMA request.
+- dma-channels: Specify total DMA channels per CC
+- reg: Memory map for accessing module
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Exactly 3 interrupts need to be specified in the order:
+              1. Transfer completion interrupt.
+              2. Memory protection interrupt.
+              3. Error interrupt.
+Optional properties:
+- ti,hwmods: Name of the hwmods associated to the EDMA
+- ti,edma-xbar-event-map: Crossbar event to channel map
+Example:
+edma: edma@49000000 {
+        reg = <0x49000000 0x10000>;
+        interrupt-parent = <&intc>;
+        interrupts = <12 13 14>;
+        compatible = "ti,edma3";
+        ti,hwmods = "tpcc", "tptc0", "tptc1", "tptc2";
+        #dma-cells = <1>;
+        dma-channels = <64>;
+        ti,edma-regions = <4>;
+        ti,edma-slots = <256>;
+        ti,edma-xbar-event-map = <1 12
+                                  2 13>;
+};
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt b/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
deleted file mode 100644
index fa166d945809..000000000000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiddc.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiddc driver
-Required properties:
- compatible: value should be "samsung,exynos5-hdmiddc".
- reg: I2C address of the hdmiddc device.
-Example:
-        hdmiddc {
-                compatible = "samsung,exynos5-hdmiddc";
-                reg = <0x50>;
-        };
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt b/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
deleted file mode 100644
index 858f4f9b902f..000000000000
--- a/Documentation/devicetree/bindings/drm/exynos/hdmiphy.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-Device-Tree bindings for hdmiphy driver
-Required properties:
- compatible: value should be "samsung,exynos5-hdmiphy".
- reg: I2C address of the hdmiphy device.
-Example:
-        hdmiphy {
-                compatible = "samsung,exynos5-hdmiphy";
-                reg = <0x38>;
-        };
diff --git a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
index e5f130159ae1..fff10da5e927 100644
--- a/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
+++ b/Documentation/devicetree/bindings/drm/tilcdc/tilcdc.txt
@@ -10,6 +10,14 @@ Recommended properties:
   services interrupts for this device.
 - ti,hwmods: Name of the hwmod associated to the LCDC
+Optional properties:
+ - max-bandwidth: The maximum pixels per second that the memory
+   interface / lcd controller combination can sustain
+ - max-width: The maximum horizontal pixel width supported by
+   the lcd controller.
+ - max-pixelclock: The maximum pixel clock that can be supported
+   by the lcd controller in KHz.
 Example:
        fb: fb@4830e000 {
diff --git a/Documentation/devicetree/bindings/extcon/extcon-twl.txt b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
new file mode 100644
index 000000000000..58f531ab4df3
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-twl.txt
@@ -0,0 +1,15 @@
+EXTCON FOR TWL CHIPS
+PALMAS USB COMPARATOR
+Required Properties:
+ - compatible : Should be "ti,palmas-usb" or "ti,twl6035-usb"
+ - vbus-supply : phandle to the regulator device tree node.
+Optional Properties:
+ - ti,wakeup : To enable the wakeup comparator in probe
+palmas-usb {
+       compatible = "ti,twl6035-usb", "ti,palmas-usb";
+       vbus-supply = <&smps10_reg>;
+       ti,wakeup;
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
new file mode 100644
index 000000000000..e0d0446a6b78
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-clps711x.txt
@@ -0,0 +1,28 @@
+Cirrus Logic CLPS711X GPIO controller
+Required properties:
+- compatible: Should be "cirrus,clps711x-gpio"
+- reg: Physical base GPIO controller registers location and length.
+  There should be two registers, first is DATA register, the second
+  is DIRECTION.
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+    0 = active high
+    1 = active low
+Note: Each GPIO port should have an alias correctly numbered in "aliases"
+node.
+Example:
+aliases {
+        gpio0 = &porta;
+};
+porta: gpio@80000000 {
+        compatible = "cirrus,clps711x-gpio";
+        reg = <0x80000000 0x1>, <0x80000040 0x1>;
+        gpio-controller;
+        #gpio-cells = <2>;
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-msm.txt b/Documentation/devicetree/bindings/gpio/gpio-msm.txt
new file mode 100644
index 000000000000..ac20e68a004e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-msm.txt
@@ -0,0 +1,26 @@
+MSM GPIO controller bindings
+Required properties:
+- compatible:
+  - "qcom,msm-gpio" for MSM controllers
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+- gpio-controller : Marks the device node as a GPIO controller.
+- #interrupt-cells : Should be 2.
+- interrupt-controller: Mark the device node as an interrupt controller
+- interrupts : Specify the TLMM summary interrupt number
+- ngpio : Specify the number of MSM GPIOs
+Example:
+        msmgpio: gpio@fd510000 {
+                compatible = "qcom,msm-gpio";
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                reg = <0xfd510000 0x4000>;
+                interrupts = <0 208 0>;
+                ngpio = <150>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
index f1e5dfecf55d..5375625e8cd2 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-samsung.txt
@@ -39,46 +39,3 @@ Example:
                #gpio-cells = <4>;
                gpio-controller;
        };
-Samsung S3C24XX GPIO Controller
-Required properties:
- compatible: Compatible property value should be "samsung,s3c24xx-gpio".
- reg: Physical base address of the controller and length of memory mapped
-  region.
- #gpio-cells: Should be 3. The syntax of the gpio specifier used by client nodes
-  should be the following with values derived from the SoC user manual.
-     <[phandle of the gpio controller node]
-      [pin number within the gpio controller]
-      [mux function]
-      [flags and pull up/down]
-  Values for gpio specifier:
-  - Pin number: depending on the controller a number from 0 up to 15.
-  - Mux function: Depending on the SoC and the gpio bank the gpio can be set
-                  as input, output or a special function
-  - Flags and Pull Up/Down: the values to use differ for the individual SoCs
-                    example S3C2416/S3C2450:
-                            0 - Pull Up/Down Disabled.
-                            1 - Pull Down Enabled.
-                            2 - Pull Up Enabled.
-          Bit 16 (0x00010000) - Input is active low.
-  Consult the user manual for the correct values of Mux and Pull Up/Down.
- gpio-controller: Specifies that the node is a gpio controller.
- #address-cells: should be 1.
- #size-cells: should be 1.
-Example:
-        gpa: gpio-controller@56000000 {
-                #address-cells = <1>;
-                #size-cells = <1>;
-                compatible = "samsung,s3c24xx-gpio";
-                reg = <0x56000000 0x10>;
-                #gpio-cells = <3>;
-                gpio-controller;
-        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
new file mode 100644
index 000000000000..fd665b44d767
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-stericsson-coh901.txt
@@ -0,0 +1,7 @@
+ST-Ericsson COH 901 571/3 GPIO controller
+Required properties:
+- compatible: Compatible property value should be "stericsson,gpio-coh901"
+- reg: Physical base address of the controller and length of memory mapped
+  region.
+- interrupts: the 0...n interrupts assigned to the different GPIO ports/banks.
diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
new file mode 100644
index 000000000000..63bf4becd5f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
@@ -0,0 +1,48 @@
+Xilinx plb/axi GPIO controller
+Dual channel GPIO controller with configurable number of pins
+(from 1 to 32 per channel). Every pin can be configured as
+input/output/tristate. Both channels share the same global IRQ but
+local interrupts can be enabled on channel basis.
+Required properties:
+- compatible : Should be "xlnx,xps-gpio-1.00.a"
+- reg : Address and length of the register set for the device
+- #gpio-cells : Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters (currently unused).
+- gpio-controller : Marks the device node as a GPIO controller.
+Optional properties:
+- interrupts : Interrupt mapping for GPIO IRQ.
+- interrupt-parent : Phandle for the interrupt controller that
+  services interrupts for this device.
+- xlnx,all-inputs : if n-th bit is setup, GPIO-n is input
+- xlnx,dout-default : if n-th bit is 1, GPIO-n default value is 1
+- xlnx,gpio-width : gpio width
+- xlnx,tri-default : if n-th bit is 1, GPIO-n is in tristate mode
+- xlnx,is-dual : if 1, controller also uses the second channel
+- xlnx,all-inputs-2 : as above but for the second channel
+- xlnx,dout-default-2 : as above but the second channel
+- xlnx,gpio2-width : as above but for the second channel
+- xlnx,tri-default-2 : as above but for the second channel
+Example:
+gpio: gpio@40000000 {
+        #gpio-cells = <2>;
+        compatible = "xlnx,xps-gpio-1.00.a";
+        gpio-controller ;
+        interrupt-parent = <&microblaze_0_intc>;
+        interrupts = < 6 2 >;
+        reg = < 0x40000000 0x10000 >;
+        xlnx,all-inputs = <0x0>;
+        xlnx,all-inputs-2 = <0x0>;
+        xlnx,dout-default = <0x0>;
+        xlnx,dout-default-2 = <0x0>;
+        xlnx,gpio-width = <0x2>;
+        xlnx,gpio2-width = <0x2>;
+        xlnx,interrupt-present = <0x1>;
+        xlnx,is-dual = <0x1>;
+        xlnx,tri-default = <0xffffffff>;
+        xlnx,tri-default-2 = <0xffffffff>;
+} ;
diff --git a/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
new file mode 100644
index 000000000000..cb3dc7bcd8e6
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
@@ -0,0 +1,46 @@
+* Renesas R-Car GPIO Controller
+Required Properties:
+  - compatible: should be 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-rcar": for generic R-Car GPIO controller.
+  - reg: Base address and length of each memory resource used by the GPIO
+    controller hardware module.
+  - interrupt-parent: phandle of the parent interrupt controller.
+  - interrupts: Interrupt specifier for the controllers interrupt.
+  - gpio-controller: Marks the device node as a gpio controller.
+  - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+    cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
+    GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+  - gpio-ranges: Range of pins managed by the GPIO controller.
+Please refer to gpio.txt in this directory for details of gpio-ranges property
+and the common GPIO bindings used by client devices.
+Example: R8A7779 (R-Car H1) GPIO controller nodes
+        gpio0: gpio@ffc40000 {
+                compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+                reg = <0xffc40000 0x2c>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 141 0x4>;
+                #gpio-cells = <2>;
+                gpio-controller;
+                gpio-ranges = <&pfc 0 0 32>;
+        };
+        ...
+        gpio6: gpio@ffc46000 {
+                compatible = "renesas,gpio-r8a7779", "renesas,gpio-rcar";
+                reg = <0xffc46000 0x2c>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 147 0x4>;
+                #gpio-cells = <2>;
+                gpio-controller;
+                gpio-ranges = <&pfc 0 192 9>;
+        };
diff --git a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
index 2b14a940eb75..3f454ffc654a 100644
--- a/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
+++ b/Documentation/devicetree/bindings/gpu/samsung-g2d.txt
@@ -10,11 +10,16 @@ Required properties:
          mapped region.
  - interrupts : G2D interrupt number to the CPU.
+  - clocks : from common clock binding: handle to G2D clocks.
+  - clock-names : from common clock binding: must contain "sclk_fimg2d" and
+                  "fimg2d", corresponding to entries in the clocks property.
 Example:
        g2d@12800000 {
                compatible = "samsung,s5pv210-g2d";
                reg = <0x12800000 0x1000>;
                interrupts = <0 89 0>;
+                clocks = <&clock 177>, <&clock 277>;
+                clock-names = "sclk_fimg2d", "fimg2d";
                status = "disabled";
        };
diff --git a/Documentation/devicetree/bindings/hwmon/g762.txt b/Documentation/devicetree/bindings/hwmon/g762.txt
new file mode 100644
index 000000000000..25cc6d8ee575
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/g762.txt
@@ -0,0 +1,47 @@
+GMT G762/G763 PWM Fan controller
+Required node properties:
+ - "compatible": must be either "gmt,g762" or "gmt,g763"
+ - "reg": I2C bus address of the device
+ - "clocks": a fixed clock providing input clock frequency
+             on CLK pin of the chip.
+Optional properties:
+ - "fan_startv": fan startup voltage. Accepted values are 0, 1, 2 and 3.
+               The higher the more.
+ - "pwm_polarity": pwm polarity. Accepted values are 0 (positive duty)
+               and 1 (negative duty).
+ - "fan_gear_mode": fan gear mode. Supported values are 0, 1 and 2.
+If an optional property is not set in .dts file, then current value is kept
+unmodified (e.g. u-boot installed value).
+Additional information on operational parameters for the device is available
+in Documentation/hwmon/g762. A detailed datasheet for the device is available
+at http://natisbad.org/NAS/refs/GMT_EDS-762_763-080710-0.2.pdf.
+Example g762 node:
+   clocks {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        g762_clk: fixedclk {
+                 compatible = "fixed-clock";
+                 #clock-cells = <0>;
+                 clock-frequency = <8192>;
+        }
+   }
+   g762: g762@3e {
+        compatible = "gmt,g762";
+        reg = <0x3e>;
+        clocks = <&g762_clk>
+        fan_gear_mode = <0>; /* chip default */
+        fan_startv = <1>;    /* chip default */
+        pwm_polarity = <0>;  /* chip default */
+   };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-designware.txt b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
index e42a2ee233e6..7fd7fa25e9b0 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-designware.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-designware.txt
@@ -10,6 +10,10 @@ Recommended properties :
 - clock-frequency : desired I2C bus clock frequency in Hz.
+Optional properties :
+ - i2c-sda-hold-time-ns : should contain the SDA hold time in nanoseconds.
+   This option is only supported in hardware blocks version 1.11a or newer.
 Example :
        i2c@f0000 {
@@ -20,3 +24,14 @@ Example :
                interrupts = <11>;
                clock-frequency = <400000>;
        };
+        i2c@1120000 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                compatible = "snps,designware-i2c";
+                reg = <0x1120000 0x1000>;
+                interrupt-parent = <&ictl>;
+                interrupts = <12 1>;
+                clock-frequency = <400000>;
+                i2c-sda-hold-time-ns = <300>;
+        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
index f46d928aa73d..a1ee681942cc 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mv64xxx.txt
@@ -6,7 +6,11 @@ Required properties :
 - reg             : Offset and length of the register set for the device
 - compatible      : Should be "marvell,mv64xxx-i2c"
 - interrupts      : The interrupt number
- - clock-frequency : Desired I2C bus clock frequency in Hz.
+Optional properties :
+ - clock-frequency : Desired I2C bus clock frequency in Hz. If not set the
+default frequency is 100kHz
 Examples:
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
new file mode 100644
index 000000000000..bd81a482634f
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st-ddci2c.txt
@@ -0,0 +1,15 @@
+ST Microelectronics DDC I2C
+Required properties :
+- compatible : Must be "st,ddci2c"
+- reg: physical base address of the controller and length of memory mapped
+     region.
+- interrupts: interrupt number to the cpu.
+- #address-cells = <1>;
+- #size-cells = <0>;
+Optional properties:
+- Child nodes conforming to i2c bus binding
+Examples :
diff --git a/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
new file mode 100644
index 000000000000..94a425eaa6c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-vt8500.txt
@@ -0,0 +1,24 @@
+* Wondermedia I2C Controller
+Required properties :
+ - compatible : should be "wm,wm8505-i2c"
+ - reg : Offset and length of the register set for the device
+ - interrupts : <IRQ> where IRQ is the interrupt number
+ - clocks : phandle to the I2C clock source
+Optional properties :
+ - clock-frequency : desired I2C bus clock frequency in Hz.
+        Valid values are 100000 and 400000.
+        Default to 100000 if not specified, or invalid value.
+Example :
+        i2c_0: i2c@d8280000 {
+                compatible = "wm,wm8505-i2c";
+                reg = <0xd8280000 0x1000>;
+                interrupts = <19>;
+                clocks = <&clki2c0>;
+                clock-frequency = <400000>;
+        };
diff --git a/Documentation/devicetree/bindings/i2c/ina2xx.txt b/Documentation/devicetree/bindings/i2c/ina2xx.txt
new file mode 100644
index 000000000000..a2ad85d7e747
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/ina2xx.txt
@@ -0,0 +1,22 @@
+ina2xx properties
+Required properties:
+- compatible: Must be one of the following:
+        - "ti,ina219" for ina219
+        - "ti,ina220" for ina220
+        - "ti,ina226" for ina226
+        - "ti,ina230" for ina230
+- reg: I2C address
+Optional properties:
+- shunt-resistor
+        Shunt resistor value in micro-Ohm
+Example:
+ina220@44 {
+        compatible = "ti,ina220";
+        reg = <0x44>;
+        shunt-resistor = <1000>;
+};
diff --git a/Documentation/devicetree/bindings/iio/dac/ad7303.txt b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
new file mode 100644
index 000000000000..914610f0556e
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/ad7303.txt
@@ -0,0 +1,23 @@
+Analog Devices AD7303 DAC device driver
+Required properties:
+        - compatible: Must be "adi,ad7303"
+        - reg: SPI chip select number for the device
+        - spi-max-frequency: Max SPI frequency to use (< 30000000)
+        - Vdd-supply: Phandle to the Vdd power supply
+Optional properties:
+        - REF-supply: Phandle to the external reference voltage supply. This should
+          only be set if there is an external reference voltage connected to the REF
+          pin. If the property is not set Vdd/2 is used as the reference voltage.
+Example:
+                ad7303@4 {
+                        compatible = "adi,ad7303";
+                        reg = <4>;
+                        spi-max-frequency = <10000000>;
+                        Vdd-supply = <&vdd_supply>;
+                        adi,use-external-reference;
+                        REF-supply = <&vref_supply>;
+                };
diff --git a/Documentation/devicetree/bindings/iio/frequency/adf4350.txt b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt
new file mode 100644
index 000000000000..f8c181d81d2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/frequency/adf4350.txt
@@ -0,0 +1,86 @@
+Analog Devices ADF4350/ADF4351 device driver
+Required properties:
+        - compatible: Should be one of
+                * "adi,adf4350": When using the ADF4350 device
+                * "adi,adf4351": When using the ADF4351 device
+        - reg: SPI chip select numbert for the device
+        - spi-max-frequency: Max SPI frequency to use (< 20000000)
+        - clocks: From common clock binding. Clock is phandle to clock for
+                ADF435x Reference Clock (CLKIN).
+Optional properties:
+        - gpios:         GPIO Lock detect - If set with a valid phandle and GPIO number,
+                        pll lock state is tested upon read.
+        - adi,channel-spacing: Channel spacing in Hz (influences MODULUS).
+        - adi,power-up-frequency:       If set in Hz the PLL tunes to
+                        the desired frequency on probe.
+        - adi,reference-div-factor: If set the driver skips dynamic calculation
+                        and uses this default value instead.
+        - adi,reference-doubler-enable: Enables reference doubler.
+        - adi,reference-div2-enable: Enables reference divider.
+        - adi,phase-detector-polarity-positive-enable: Enables positive phase
+                        detector polarity. Default = negative.
+        - adi,lock-detect-precision-6ns-enable: Enables 6ns lock detect precision.
+                        Default = 10ns.
+        - adi,lock-detect-function-integer-n-enable: Enables lock detect
+                        for integer-N mode. Default = factional-N mode.
+        - adi,charge-pump-current: Charge pump current in mA.
+                        Default = 2500mA.
+        - adi,muxout-select: On chip multiplexer output selection.
+                        Valid values for the multiplexer output are:
+                        0: Three-State Output (default)
+                        1: DVDD
+                        2: DGND
+                        3: R-Counter output
+                        4: N-Divider output
+                        5: Analog lock detect
+                        6: Digital lock detect
+        - adi,low-spur-mode-enable: Enables low spur mode.
+                        Default = Low noise mode.
+        - adi,cycle-slip-reduction-enable: Enables cycle slip reduction.
+        - adi,charge-cancellation-enable: Enabled charge pump
+                        charge cancellation for integer-N modes.
+        - adi,anti-backlash-3ns-enable: Enables 3ns antibacklash pulse width
+                         for integer-N modes.
+        - adi,band-select-clock-mode-high-enable: Enables faster band
+                        selection logic.
+        - adi,12bit-clk-divider: Clock divider value used when
+                        adi,12bit-clkdiv-mode != 0
+        - adi,clk-divider-mode:
+                        Valid values for the clkdiv mode are:
+                        0: Clock divider off (default)
+                        1: Fast lock enable
+                        2: Phase resync enable
+        - adi,aux-output-enable: Enables auxiliary RF output.
+        - adi,aux-output-fundamental-enable: Selects fundamental VCO output on
+                        the auxiliary RF output. Default = Output of RF dividers.
+        - adi,mute-till-lock-enable: Enables Mute-Till-Lock-Detect function.
+        - adi,output-power: Output power selection.
+                        Valid values for the power mode are:
+                        0: -4dBm (default)
+                        1: -1dBm
+                        2: +2dBm
+                        3: +5dBm
+        - adi,aux-output-power: Auxiliary output power selection.
+                        Valid values for the power mode are:
+                        0: -4dBm (default)
+                        1: -1dBm
+                        2: +2dBm
+                        3: +5dBm
+Example:
+                lo_pll0_rx_adf4351: adf4351-rx-lpc@4 {
+                        compatible = "adi,adf4351";
+                        reg = <4>;
+                        spi-max-frequency = <10000000>;
+                        clocks = <&clk0_ad9523 9>;
+                        clock-names = "clkin";
+                        adi,channel-spacing = <10000>;
+                        adi,power-up-frequency = <2400000000>;
+                        adi,phase-detector-polarity-positive-enable;
+                        adi,charge-pump-current = <2500>;
+                        adi,output-power = <3>;
+                        adi,mute-till-lock-enable;
+                };
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
new file mode 100644
index 000000000000..011679f1a425
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/ak8975.txt
@@ -0,0 +1,18 @@
+* AsahiKASEI AK8975 magnetometer sensor
+Required properties:
+  - compatible : should be "asahi-kasei,ak8975"
+  - reg : the I2C address of the magnetometer
+Optional properties:
+  - gpios : should be device tree identifier of the magnetometer DRDY pin
+Example:
+ak8975@0c {
+        compatible = "asahi-kasei,ak8975";
+        reg = <0x0c>;
+        gpios = <&gpj0 7 0>;
+};
diff --git a/Documentation/devicetree/bindings/input/pxa27x-keypad.txt b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
new file mode 100644
index 000000000000..f8674f7e5ea5
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pxa27x-keypad.txt
@@ -0,0 +1,60 @@
+* Marvell PXA Keypad controller
+Required Properties
+- compatible : should be "marvell,pxa27x-keypad"
+- reg : Address and length of the register set for the device
+- interrupts : The interrupt for the keypad controller
+- marvell,debounce-interval : How long time the key will be
+  recognized when it is pressed. It is a u32 value, and bit[31:16]
+  is debounce interval for direct key and bit[15:0] is debounce
+  interval for matrix key. The value is in binary number of 2ms
+Optional Properties For Matrix Keyes
+Please refer to matrix-keymap.txt
+Optional Properties for Direct Keyes
+- marvell,direct-key-count : How many direct keyes are used.
+- marvell,direct-key-mask : The mask indicates which keyes
+  are used. If bit[X] of the mask is set, the direct key X
+  is used.
+- marvell,direct-key-low-active : Direct key status register
+  tells the level of pins that connects to the direct keyes.
+  When this property is set, it means that when the pin level
+  is low, the key is pressed(active).
+- marvell,direct-key-map : It is a u16 array. Each item indicates
+  the linux key-code for the direct key.
+Optional Properties For Rotary
+- marvell,rotary0 : It is a u32 value. Bit[31:16] is the
+  linux key-code for rotary up. Bit[15:0] is the linux key-code
+  for rotary down. It is for rotary 0.
+- marvell,rotary1 : Same as marvell,rotary0. It is for rotary 1.
+- marvell,rotary-rel-key : When rotary is used for relative axes
+  in the device, the value indicates the key-code for relative
+  axes measurement in the device. It is a u32 value. Bit[31:16]
+  is for rotary 1, and Bit[15:0] is for rotary 0.
+Examples:
+        keypad: keypad@d4012000 {
+                keypad,num-rows = <3>;
+                keypad,num-columns = <5>;
+                linux,keymap = <0x0000000e      /* KEY_BACKSPACE */
+                                0x0001006b      /* KEY_END */
+                                0x00020061      /* KEY_RIGHTCTRL */
+                                0x0003000b      /* KEY_0 */
+                                0x00040002      /* KEY_1 */
+                                0x0100008b      /* KEY_MENU */
+                                0x01010066      /* KEY_HOME */
+                                0x010200e7      /* KEY_SEND */
+                                0x01030009      /* KEY_8 */
+                                0x0104000a      /* KEY_9 */
+                                0x02000160      /* KEY_OK */
+                                0x02010003      /* KEY_2 */
+                                0x02020004      /* KEY_3 */
+                                0x02030005      /* KEY_4 */
+                                0x02040006>;    /* KEY_5 */
+                marvell,rotary0 = <0x006c0067>; /* KEY_UP & KEY_DOWN */
+                marvell,direct-key-count = <1>;
+                marvell,direct-key-map = <0x001c>;
+                marvell,debounce-interval = <0x001e001e>;
+        };
diff --git a/Documentation/devicetree/bindings/input/samsung-keypad.txt b/Documentation/devicetree/bindings/input/samsung-keypad.txt
index ce3e394c0e64..942d071baaa5 100644
--- a/Documentation/devicetree/bindings/input/samsung-keypad.txt
+++ b/Documentation/devicetree/bindings/input/samsung-keypad.txt
@@ -25,14 +25,6 @@ Required Board Specific Properties:
 - samsung,keypad-num-columns: Number of column lines connected to the
  keypad controller.
- row-gpios: List of gpios used as row lines. The gpio specifier for
-  this property depends on the gpio controller to which these row lines
-  are connected.
- col-gpios: List of gpios used as column lines. The gpio specifier for
-  this property depends on the gpio controller to which these column
-  lines are connected.
 - Keys represented as child nodes: Each key connected to the keypad
  controller is represented as a child node to the keypad controller
  device node and should include the following properties.
@@ -41,6 +33,9 @@ Required Board Specific Properties:
  - linux,code: the key-code to be reported when the key is pressed
    and released.
+- pinctrl-0: Should specify pin control groups used for this controller.
+- pinctrl-names: Should contain only one value - "default".
 Optional Properties specific to linux:
 - linux,keypad-no-autorepeat: do no enable autorepeat feature.
 - linux,keypad-wakeup: use any event on keypad as wakeup event.
@@ -56,17 +51,8 @@ Example:
                linux,input-no-autorepeat;
                linux,input-wakeup;
-                row-gpios = <&gpx2 0 3 3 0
+                pinctrl-names = "default";
-                             &gpx2 1 3 3 0>;
+                pinctrl-0 = <&keypad_rows &keypad_columns>;
-                col-gpios = <&gpx1 0 3 0 0
-                             &gpx1 1 3 0 0
-                             &gpx1 2 3 0 0
-                             &gpx1 3 3 0 0
-                             &gpx1 4 3 0 0
-                             &gpx1 5 3 0 0
-                             &gpx1 6 3 0 0
-                             &gpx1 7 3 0 0>;
                key_1 {
                        keypad,row = <0>;
diff --git a/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt
new file mode 100644
index 000000000000..513d94d6e899
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/ti,nspire-keypad.txt
@@ -0,0 +1,60 @@
+TI-NSPIRE Keypad
+Required properties:
+- compatible: Compatible property value should be "ti,nspire-keypad".
+- reg: Physical base address of the peripheral and length of memory mapped
+  region.
+- interrupts: The interrupt number for the peripheral.
+- scan-interval: How often to scan in us. Based on a APB speed of 33MHz, the
+        maximum and minimum delay time is ~2000us and ~500us respectively
+- row-delay: How long to wait before scanning each row.
+- clocks: The clock this peripheral is attached to.
+- linux,keymap: The keymap to use
+        (see Documentation/devicetree/bindings/input/matrix-keymap.txt)
+Optional properties:
+- active-low: Specify that the keypad is active low (i.e. logical low signifies
+        a key press).
+Example:
+input {
+        compatible = "ti,nspire-keypad";
+        reg = <0x900E0000 0x1000>;
+        interrupts = <16>;
+        scan-interval = <1000>;
+        row-delay = <200>;
+        clocks = <&apb_pclk>;
+        linux,keymap = <
+        0x0000001c      0x0001001c      0x00040039
+        0x0005002c      0x00060015      0x0007000b
+        0x0008000f      0x0100002d      0x01010011
+        0x0102002f      0x01030004      0x01040016
+        0x01050014      0x0106001f      0x01070002
+        0x010a006a      0x02000013      0x02010010
+        0x02020019      0x02030007      0x02040018
+        0x02050031      0x02060032      0x02070005
+        0x02080028      0x0209006c      0x03000026
+        0x03010025      0x03020024      0x0303000a
+        0x03040017      0x03050023      0x03060022
+        0x03070008      0x03080035      0x03090069
+        0x04000021      0x04010012      0x04020020
+        0x0404002e      0x04050030      0x0406001e
+        0x0407000d      0x04080037      0x04090067
+        0x05010038      0x0502000c      0x0503001b
+        0x05040034      0x0505001a      0x05060006
+        0x05080027      0x0509000e      0x050a006f
+        0x0600002b      0x0602004e      0x06030068
+        0x06040003      0x0605006d      0x06060009
+        0x06070001      0x0609000f      0x0708002a
+        0x0709001d      0x070a0033      >;
+};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
new file mode 100644
index 000000000000..491c97b78384
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -0,0 +1,44 @@
+* TI - TSC ADC (Touschscreen and analog digital converter)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Required properties:
+- child "tsc"
+        ti,wires: Wires refer to application modes i.e. 4/5/8 wire touchscreen
+                  support on the platform.
+        ti,x-plate-resistance: X plate resistance
+        ti,coordiante-readouts: The sequencer supports a total of 16
+                                programmable steps each step is used to
+                                read a single coordinate. A single
+                                readout is enough but multiple reads can
+                                increase the quality.
+                                A value of 5 means, 5 reads for X, 5 for
+                                Y and 2 for Z (always). This utilises 12
+                                of the 16 software steps available. The
+                                remaining 4 can be used by the ADC.
+        ti,wire-config: Different boards could have a different order for
+                        connecting wires on touchscreen. We need to provide an
+                        8 bit number where in the 1st four bits represent the
+                        analog lines and the next 4 bits represent positive/
+                        negative terminal on that input line. Notations to
+                        represent the input lines and terminals resoectively
+                        is as follows:
+                        AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+                        XP  = 0, XN = 1, YP = 2, YN = 3.
+- child "adc"
+        ti,adc-channels: List of analog inputs available for ADC.
+                         AIN0 = 0, AIN1 = 1 and so on till AIN7 = 7.
+Example:
+        tscadc: tscadc@44e0d000 {
+                compatible = "ti,am3359-tscadc";
+                tsc {
+                        ti,wires = <4>;
+                        ti,x-plate-resistance = <200>;
+                        ti,coordiante-readouts = <5>;
+                        ti,wire-config = <0x00 0x11 0x22 0x33>;
+                };
+                adc {
+                        ti,adc-channels = <4 5 6 7>;
+                };
+        }
diff --git a/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt
new file mode 100644
index 000000000000..9d52d5afe3e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/abilis,tb10x-ictl.txt
@@ -0,0 +1,38 @@
+TB10x Top Level Interrupt Controller
+====================================
+The Abilis TB10x SOC contains a custom interrupt controller. It performs
+one-to-one mapping of external interrupt sources to CPU interrupts and
+provides support for reconfigurable trigger modes.
+Required properties
+-------------------
+- compatible: Should be "abilis,tb10x-ictl"
+- reg: specifies physical base address and size of register range.
+- interrupt-congroller: Identifies the node as an interrupt controller.
+- #interrupt cells: Specifies the number of cells used to encode an interrupt
+  source connected to this controller. The value shall be 2.
+- interrupt-parent: Specifies the parent interrupt controller.
+- interrupts: Specifies the list of interrupt lines which are handled by
+  the interrupt controller in the parent controller's notation. Interrupts
+  are mapped one-to-one to parent interrupts.
+Example
+-------
+intc: interrupt-controller {    /* Parent interrupt controller */
+        interrupt-controller;
+        #interrupt-cells = <1>; /* For example below */
+        /* ... */
+};
+tb10x_ictl: pic@2000 {          /* TB10x interrupt controller */
+        compatible = "abilis,tb10x-ictl";
+        reg = <0x2000 0x20>;
+        interrupt-controller;
+        #interrupt-cells = <2>;
+        interrupt-parent = <&intc>;
+        interrupts = <5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
+                        20 21 22 23 24 25 26 27 28 29 30 31>;
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index e7f4dc14eff2..57edb30dbbca 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -8,91 +8,8 @@ Required properties:
 - #interrupt-cells : Specifies the number of cells needed to encode an
  interrupt source. The value shall be 1.
-The interrupt sources are as follows:
+For the valid interrupt sources for your SoC, see the documentation in
+sunxi/<soc>.txt
-0: ENMI
-1: UART0
-2: UART1
-3: UART2
-4: UART3
-5: IR0
-6: IR1
-7: I2C0
-8: I2C1
-9: I2C2
-10: SPI0
-11: SPI1
-12: SPI2
-13: SPDIF
-14: AC97
-15: TS
-16: I2S
-17: UART4
-18: UART5
-19: UART6
-20: UART7
-21: KEYPAD
-22: TIMER0
-23: TIMER1
-24: TIMER2
-25: TIMER3
-26: CAN
-27: DMA
-28: PIO
-29: TOUCH_PANEL
-30: AUDIO_CODEC
-31: LRADC
-32: SDMC0
-33: SDMC1
-34: SDMC2
-35: SDMC3
-36: MEMSTICK
-37: NAND
-38: USB0
-39: USB1
-40: USB2
-41: SCR
-42: CSI0
-43: CSI1
-44: LCDCTRL0
-45: LCDCTRL1
-46: MP
-47: DEFEBE0
-48: DEFEBE1
-49: PMU
-50: SPI3
-51: TZASC
-52: PATA
-53: VE
-54: SS
-55: EMAC
-56: SATA
-57: GPS
-58: HDMI
-59: TVE
-60: ACE
-61: TVD
-62: PS2_0
-63: PS2_1
-64: USB3
-65: USB4
-66: PLE_PFM
-67: TIMER4
-68: TIMER5
-69: GPU_GP
-70: GPU_GPMMU
-71: GPU_PP0
-72: GPU_PPMMU0
-73: GPU_PMU
-74: GPU_RSV0
-75: GPU_RSV1
-76: GPU_RSV2
-77: GPU_RSV3
-78: GPU_RSV4
-79: GPU_RSV5
-80: GPU_RSV6
-82: SYNC_TIMER0
-83: SYNC_TIMER1
 Example:
diff --git a/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt
new file mode 100644
index 000000000000..2c11ac76fac9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/marvell,orion-intc.txt
@@ -0,0 +1,48 @@
+Marvell Orion SoC interrupt controllers
+* Main interrupt controller
+Required properties:
+- compatible: shall be "marvell,orion-intc"
+- reg: base address(es) of interrupt registers starting with CAUSE register
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
+The interrupt sources map to the corresponding bits in the interrupt
+registers, i.e.
+- 0 maps to bit 0 of first base address,
+- 1 maps to bit 1 of first base address,
+- 32 maps to bit 0 of second base address, and so on.
+Example:
+        intc: interrupt-controller {
+                compatible = "marvell,orion-intc";
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                 /* Dove has 64 first level interrupts */
+                reg = <0x20200 0x10>, <0x20210 0x10>;
+        };
+* Bridge interrupt controller
+Required properties:
+- compatible: shall be "marvell,orion-bridge-intc"
+- reg: base address of bridge interrupt registers starting with CAUSE register
+- interrupts: bridge interrupt of the main interrupt controller
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: number of cells to encode an interrupt source, shall be 1
+Optional properties:
+- marvell,#interrupts: number of interrupts provided by bridge interrupt
+      controller, defaults to 32 if not set
+Example:
+        bridge_intc: interrupt-controller {
+                compatible = "marvell,orion-bridge-intc";
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                reg = <0x20110 0x8>;
+                interrupts = <0>;
+                /* Dove bridge provides 5 interrupts */
+                marvell,#interrupts = <5>;
+        };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
new file mode 100644
index 000000000000..1f8b0c507c26
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,intc-irqpin.txt
@@ -0,0 +1,16 @@
+DT bindings for the R-/SH-Mobile irqpin controller
+Required properties:
+- compatible: has to be "renesas,intc-irqpin"
+- #interrupt-cells: has to be <2>: an interrupt index and flags, as defined in
+  interrupts.txt in this directory
+Optional properties:
+- any properties, listed in interrupts.txt, and any standard resource allocation
+  properties
+- sense-bitfield-width: width of a single sense bitfield in the SENSE register,
+  if different from the default 4 bits
+- control-parent: disable and enable interrupts on the parent interrupt
+  controller, needed for some broken implementations
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
new file mode 100644
index 000000000000..76b98c834499
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
@@ -0,0 +1,89 @@
+Allwinner A10 (sun4i) interrupt sources
+---------------------------------------
+The interrupt sources available for the Allwinner A10 SoC are the
+following one:
+0: ENMI
+1: UART0
+2: UART1
+3: UART2
+4: UART3
+5: IR0
+6: IR1
+7: I2C0
+8: I2C1
+9: I2C2
+10: SPI0
+11: SPI1
+12: SPI2
+13: SPDIF
+14: AC97
+15: TS
+16: I2S
+17: UART4
+18: UART5
+19: UART6
+20: UART7
+21: KEYPAD
+22: TIMER0
+23: TIMER1
+24: TIMER2
+25: TIMER3
+26: CAN
+27: DMA
+28: PIO
+29: TOUCH_PANEL
+30: AUDIO_CODEC
+31: LRADC
+32: MMC0
+33: MMC1
+34: MMC2
+35: MMC3
+36: MEMSTICK
+37: NAND
+38: USB0
+39: USB1
+40: USB2
+41: SCR
+42: CSI0
+43: CSI1
+44: LCDCTRL0
+45: LCDCTRL1
+46: MP
+47: DEFEBE0
+48: DEFEBE1
+49: PMU
+50: SPI3
+51: TZASC
+52: PATA
+53: VE
+54: SS
+55: EMAC
+56: SATA
+57: GPS
+58: HDMI
+59: TVE
+60: ACE
+61: TVD
+62: PS2_0
+63: PS2_1
+64: USB3
+65: USB4
+66: PLE_PFM
+67: TIMER4
+68: TIMER5
+69: GPU_GP
+70: GPU_GPMMU
+71: GPU_PP0
+72: GPU_PPMMU0
+73: GPU_PMU
+74: GPU_RSV0
+75: GPU_RSV1
+76: GPU_RSV2
+77: GPU_RSV3
+78: GPU_RSV4
+79: GPU_RSV5
+80: GPU_RSV6
+82: SYNC_TIMER0
+83: SYNC_TIMER1
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt
new file mode 100644
index 000000000000..2ec3b5ce1a0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt
@@ -0,0 +1,55 @@
+Allwinner A13 (sun5i) interrupt sources
+---------------------------------------
+The interrupt sources available for the Allwinner A13 SoC are the
+following one:
+0: ENMI
+2: UART1
+4: UART3
+5: IR
+7: I2C0
+8: I2C1
+9: I2C2
+10: SPI0
+11: SPI1
+12: SPI2
+22: TIMER0
+23: TIMER1
+24: TIMER2
+25: TIMER3
+27: DMA
+28: PIO
+29: TOUCH_PANEL
+30: AUDIO_CODEC
+31: LRADC
+32: MMC0
+33: MMC1
+34: MMC2
+37: NAND
+38: USB OTG
+39: USB EHCI
+40: USB OHCI
+42: CSI
+44: LCDCTRL
+47: DEFEBE
+49: PMU
+53: VE
+54: SS
+66: PLE_PFM
+67: TIMER4
+68: TIMER5
+69: GPU_GP
+70: GPU_GPMMU
+71: GPU_PP0
+72: GPU_PPMMU0
+73: GPU_PMU
+74: GPU_RSV0
+75: GPU_RSV1
+76: GPU_RSV2
+77: GPU_RSV3
+78: GPU_RSV4
+79: GPU_RSV5
+80: GPU_RSV6
+82: SYNC_TIMER0
+83: SYNC_TIMER1
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
new file mode 100644
index 000000000000..e34c6cdd8ba8
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -0,0 +1,70 @@
+* ARM System MMU Architecture Implementation
+ARM SoCs may contain an implementation of the ARM System Memory
+Management Unit Architecture, which can be used to provide 1 or 2 stages
+of address translation to bus masters external to the CPU.
+The SMMU may also raise interrupts in response to various fault
+conditions.
+** System MMU required properties:
+- compatible    : Should be one of:
+                        "arm,smmu-v1"
+                        "arm,smmu-v2"
+                        "arm,mmu-400"
+                        "arm,mmu-500"
+                  depending on the particular implementation and/or the
+                  version of the architecture implemented.
+- reg           : Base address and size of the SMMU.
+- #global-interrupts : The number of global interrupts exposed by the
+                       device.
+- interrupts    : Interrupt list, with the first #global-irqs entries
+                  corresponding to the global interrupts and any
+                  following entries corresponding to context interrupts,
+                  specified in order of their indexing by the SMMU.
+                  For SMMUv2 implementations, there must be exactly one
+                  interrupt per context bank. In the case of a single,
+                  combined interrupt, it must be listed multiple times.
+- mmu-masters   : A list of phandles to device nodes representing bus
+                  masters for which the SMMU can provide a translation
+                  and their corresponding StreamIDs (see example below).
+                  Each device node linked from this list must have a
+                  "#stream-id-cells" property, indicating the number of
+                  StreamIDs associated with it.
+** System MMU optional properties:
+- smmu-parent   : When multiple SMMUs are chained together, this
+                  property can be used to provide a phandle to the
+                  parent SMMU (that is the next SMMU on the path going
+                  from the mmu-masters towards memory) node for this
+                  SMMU.
+Example:
+        smmu {
+                compatible = "arm,smmu-v1";
+                reg = <0xba5e0000 0x10000>;
+                #global-interrupts = <2>;
+                interrupts = <0 32 4>,
+                             <0 33 4>,
+                             <0 34 4>, /* This is the first context interrupt */
+                             <0 35 4>,
+                             <0 36 4>,
+                             <0 37 4>;
+                /*
+                 * Two DMA controllers, the first with two StreamIDs (0xd01d
+                 * and 0xd01e) and the second with only one (0xd11c).
+                 */
+                mmu-masters = <&dma0 0xd01d 0xd01e>,
+                              <&dma1 0xd11c>;
+        };
diff --git a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
new file mode 100644
index 000000000000..d5176882d8b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -0,0 +1,147 @@
+Binding for TI/National Semiconductor LP55xx Led Drivers
+Required properties:
+- compatible: "national,lp5521" or "national,lp5523" or "ti,lp5562"
+- reg: I2C slave address
+- clock-mode: Input clock mode, (0: automode, 1: internal, 2: external)
+Each child has own specific current settings
+- led-cur: Current setting at each led channel (mA x10, 0 if led is not connected)
+- max-cur: Maximun current at each led channel.
+Optional properties:
+- label: Used for naming LEDs
+Alternatively, each child can have specific channel name
+- chan-name: Name of each channel name
+example 1) LP5521
+3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
+'lp5521_pri:channel1' and 'lp5521_pri:channel2'
+lp5521@32 {
+        compatible = "national,lp5521";
+        reg = <0x32>;
+        label = "lp5521_pri";
+        clock-mode = /bits/ 8 <2>;
+        chan0 {
+                led-cur = /bits/ 8 <0x2f>;
+                max-cur = /bits/ 8 <0x5f>;
+        };
+        chan1 {
+                led-cur = /bits/ 8 <0x2f>;
+                max-cur = /bits/ 8 <0x5f>;
+        };
+        chan2 {
+                led-cur = /bits/ 8 <0x2f>;
+                max-cur = /bits/ 8 <0x5f>;
+        };
+};
+example 2) LP5523
+9 LED channels with specific name. Internal clock used.
+The I2C slave address is configurable with ASEL1 and ASEL0 pins.
+Available addresses are 32/33/34/35h.
+ASEL1    ASEL0    Address
+-------------------------
+ GND      GND       32h
+ GND      VEN       33h
+ VEN      GND       34h
+ VEN      VEN       35h
+lp5523@32 {
+        compatible = "national,lp5523";
+        reg = <0x32>;
+        clock-mode = /bits/ 8 <1>;
+        chan0 {
+                chan-name = "d1";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan1 {
+                chan-name = "d2";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan2 {
+                chan-name = "d3";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan3 {
+                chan-name = "d4";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan4 {
+                chan-name = "d5";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan5 {
+                chan-name = "d6";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan6 {
+                chan-name = "d7";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan7 {
+                chan-name = "d8";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+        chan8 {
+                chan-name = "d9";
+                led-cur = /bits/ 8 <0x14>;
+                max-cur = /bits/ 8 <0x20>;
+        };
+};
+example 3) LP5562
+4 channels are defined.
+lp5562@30 {
+        compatible = "ti,lp5562";
+        reg = <0x30>;
+        clock-mode = /bits/8 <2>;
+        chan0 {
+                chan-name = "R";
+                led-cur = /bits/ 8 <0x20>;
+                max-cur = /bits/ 8 <0x60>;
+        };
+        chan1 {
+                chan-name = "G";
+                led-cur = /bits/ 8 <0x20>;
+                max-cur = /bits/ 8 <0x60>;
+        };
+        chan2 {
+                chan-name = "B";
+                led-cur = /bits/ 8 <0x20>;
+                max-cur = /bits/ 8 <0x60>;
+        };
+        chan3 {
+                chan-name = "W";
+                led-cur = /bits/ 8 <0x20>;
+                max-cur = /bits/ 8 <0x60>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
index 3f62adfb3e0b..de9f6b78ee51 100644
--- a/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
+++ b/Documentation/devicetree/bindings/media/exynos-fimc-lite.txt
@@ -2,7 +2,7 @@ Exynos4x12/Exynos5 SoC series camera host interface (FIMC-LITE)
 Required properties:
- compatible    : should be "samsung,exynos4212-fimc" for Exynos4212 and
+- compatible    : should be "samsung,exynos4212-fimc-lite" for Exynos4212 and
                  Exynos4412 SoCs;
 - reg           : physical base address and size of the device memory mapped
                  registers;
diff --git a/Documentation/devicetree/bindings/media/s5p-mfc.txt b/Documentation/devicetree/bindings/media/s5p-mfc.txt
index bf0182d8da25..df37b0230c75 100644
--- a/Documentation/devicetree/bindings/media/s5p-mfc.txt
+++ b/Documentation/devicetree/bindings/media/s5p-mfc.txt
@@ -15,6 +15,9 @@ Required properties:
          mapped region.
  - interrupts : MFC interrupt number to the CPU.
+  - clocks : from common clock binding: handle to mfc clocks.
+  - clock-names : from common clock binding: must contain "sclk_mfc" and "mfc",
+                  corresponding to entries in the clocks property.
  - samsung,mfc-r : Base address of the first memory bank used by MFC
                    for DMA contiguous memory allocation and its size.
@@ -34,6 +37,8 @@ mfc: codec@13400000 {
        reg = <0x13400000 0x10000>;
        interrupts = <0 94 0>;
        samsung,power-domain = <&pd_mfc>;
+        clocks = <&clock 170>, <&clock 273>;
+        clock-names = "sclk_mfc", "mfc";
 };
 Board specific DT entry:
diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
new file mode 100644
index 000000000000..653c90c34a71
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-devbus.txt
@@ -0,0 +1,156 @@
+Device tree bindings for MVEBU Device Bus controllers
+The Device Bus controller available in some Marvell's SoC allows to control
+different types of standard memory and I/O devices such as NOR, NAND, and FPGA.
+The actual devices are instantiated from the child nodes of a Device Bus node.
+Required properties:
+ - compatible:          Currently only Armada 370/XP SoC are supported,
+                        with this compatible string:
+                        marvell,mvebu-devbus
+ - reg:                 A resource specifier for the register space.
+                        This is the base address of a chip select within
+                        the controller's register space.
+                        (see the example below)
+ - #address-cells:      Must be set to 1
+ - #size-cells:         Must be set to 1
+ - ranges:              Must be set up to reflect the memory layout with four
+                        integer values for each chip-select line in use:
+                        0 <physical address of mapping> <size>
+Mandatory timing properties for child nodes:
+Read parameters:
+ - devbus,turn-off-ps:  Defines the time during which the controller does not
+                        drive the AD bus after the completion of a device read.
+                        This prevents contentions on the Device Bus after a read
+                        cycle from a slow device.
+ - devbus,bus-width:    Defines the bus width (e.g. <16>)
+ - devbus,badr-skew-ps: Defines the time delay from from A[2:0] toggle,
+                        to read data sample. This parameter is useful for
+                        synchronous pipelined devices, where the address
+                        precedes the read data by one or two cycles.
+ - devbus,acc-first-ps: Defines the time delay from the negation of
+                        ALE[0] to the cycle that the first read data is sampled
+                        by the controller.
+ - devbus,acc-next-ps:  Defines the time delay between the cycle that
+                        samples data N and the cycle that samples data N+1
+                        (in burst accesses).
+ - devbus,rd-setup-ps:  Defines the time delay between DEV_CSn assertion to
+                        DEV_OEn assertion. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are asserted at the same cycle.
+                        This parameter has no affect on <acc-first-ps> parameter
+                        (no affect on first data sample). Set <rd-setup-ps>
+                        to a value smaller than <acc-first-ps>.
+ - devbus,rd-hold-ps:   Defines the time between the last data sample to the
+                        de-assertion of DEV_CSn. If set to 0 (default),
+                        DEV_OEn and DEV_CSn are de-asserted at the same cycle
+                        (the cycle of the last data sample).
+                        This parameter has no affect on DEV_OEn de-assertion.
+                        DEV_OEn is always de-asserted the next cycle after
+                        last data sampled. Also this parameter has no
+                        affect on <turn-off-ps> parameter.
+                        Set <rd-hold-ps> to a value smaller than <turn-off-ps>.
+Write parameters:
+ - devbus,ale-wr-ps:    Defines the time delay from the ALE[0] negation cycle
+                        to the DEV_WEn assertion.
+ - devbus,wr-low-ps:    Defines the time during which DEV_WEn is active.
+                        A[2:0] and Data are kept valid as long as DEV_WEn
+                        is active. This parameter defines the setup time of
+                        address and data to DEV_WEn rise.
+ - devbus,wr-high-ps:   Defines the time during which DEV_WEn is kept
+                        inactive (high) between data beats of a burst write.
+                        DEV_A[2:0] and Data are kept valid (do not toggle) for
+                        <wr-high-ps> - <tick> ps.
+                        This parameter defines the hold time of address and
+                        data after DEV_WEn rise.
+ - devbus,sync-enable: Synchronous device enable.
+                       1: True
+                       0: False
+An example for an Armada XP GP board, with a 16 MiB NOR device as child
+is showed below. Note that the Device Bus driver is in charge of allocating
+the mbus address decoding window for each of its child devices.
+The window is created using the chip select specified in the child
+device node together with the base address and size specified in the ranges
+property. For instance, in the example below the allocated decoding window
+will start at base address 0xf0000000, with a size 0x1000000 (16 MiB)
+for chip select 0 (a.k.a DEV_BOOTCS).
+This address window handling is done in this mvebu-devbus only as a temporary
+solution. It will be removed when the support for mbus device tree binding is
+added.
+The reg property implicitly specifies the chip select as this:
+  0x10400: DEV_BOOTCS
+  0x10408: DEV_CS0
+  0x10410: DEV_CS1
+  0x10418: DEV_CS2
+  0x10420: DEV_CS3
+Example:
+        devbus-bootcs@d0010400 {
+                status = "okay";
+                ranges = <0 0xf0000000 0x1000000>; /* @addr 0xf0000000, size 0x1000000 */
+                #address-cells = <1>;
+                #size-cells = <1>;
+                /* Device Bus parameters are required */
+                /* Read parameters */
+                devbus,bus-width    = <8>;
+                devbus,turn-off-ps  = <60000>;
+                devbus,badr-skew-ps = <0>;
+                devbus,acc-first-ps = <124000>;
+                devbus,acc-next-ps  = <248000>;
+                devbus,rd-setup-ps  = <0>;
+                devbus,rd-hold-ps   = <0>;
+                /* Write parameters */
+                devbus,sync-enable = <0>;
+                devbus,wr-high-ps  = <60000>;
+                devbus,wr-low-ps   = <60000>;
+                devbus,ale-wr-ps   = <60000>;
+                flash@0 {
+                        compatible = "cfi-flash";
+                        /* 16 MiB */
+                        reg = <0 0x1000000>;
+                        bank-width = <2>;
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        /*
+                         * We split the 16 MiB in two partitions,
+                         * just as an example.
+                         */
+                        partition@0 {
+                                label = "First";
+                                reg = <0 0x800000>;
+                        };
+                        partition@800000 {
+                                label = "Second";
+                                reg = <0x800000 0x800000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/metag/meta.txt b/Documentation/devicetree/bindings/metag/meta.txt
new file mode 100644
index 000000000000..f4457f57ab08
--- /dev/null
+++ b/Documentation/devicetree/bindings/metag/meta.txt
@@ -0,0 +1,30 @@
+* Meta Processor Binding
+This binding specifies what properties must be available in the device tree
+representation of a Meta Processor Core, which is the root node in the tree.
+Required properties:
+    - compatible: Specifies the compatibility list for the Meta processor.
+      The type shall be <string> and the value shall include "img,meta".
+Optional properties:
+    - clocks: Clock consumer specifiers as described in
+      Documentation/devicetree/bindings/clock/clock-bindings.txt
+    - clock-names: Clock consumer names as described in
+      Documentation/devicetree/bindings/clock/clock-bindings.txt.
+Clocks are identified by name. Valid clocks are:
+    - "core": The Meta core clock from which the Meta timers are derived.
+* Examples
+/ {
+        compatible = "toumaz,tz1090", "img,meta";
+        clocks = <&meta_core_clk>;
+        clock-names = "core";
+};
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt
index c3a14e0ad0ad..cd9e90c5d171 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -120,7 +120,7 @@ ab8500 {
                                  "USB_LINK_STATUS",
                                  "USB_ADP_PROBE_PLUG",
                                  "USB_ADP_PROBE_UNPLUG";
-                vddulpivio18-supply = <&ab8500_ldo_initcore_reg>;
+                vddulpivio18-supply = <&ab8500_ldo_intcore_reg>;
                v-ape-supply = <&db8500_vape_reg>;
                musb_1v8-supply = <&db8500_vsmps2_reg>;
        };
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
new file mode 100644
index 000000000000..0e295c9d8937
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -0,0 +1,62 @@
+Wolfson Arizona class audio SoCs
+These devices are audio SoCs with extensive digital capabilites and a range
+of analogue I/O.
+Required properties:
+  - compatible : one of the following chip-specific strings:
+        "wlf,wm5102"
+        "wlf,wm5110"
+  - reg : I2C slave address when connected using I2C, chip select number when
+    using SPI.
+  - interrupts : The interrupt line the /IRQ signal for the device is
+    connected to.
+  - interrupt-controller : Arizona class devices contain interrupt controllers
+    and may provide interrupt services to other devices.
+  - interrupt-parent : The parent interrupt controller.
+  - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
+    The first cell is the IRQ number.
+    The second cell is the flags, encoded as the trigger masks from
+    Documentation/devicetree/bindings/interrupts.txt
+  - gpio-controller : Indicates this device is a GPIO controller.
+  - #gpio-cells : Must be 2. The first cell is the pin number and the
+    second cell is used to specify optional parameters (currently unused).
+  - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
+    SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered
+    in Documentation/devicetree/bindings/regulator/regulator.txt
+Optional properties:
+  - wlf,reset : GPIO specifier for the GPIO controlling /RESET
+  - wlf,ldoena : GPIO specifier for the GPIO controlling LDOENA
+  - wlf,gpio-defaults : A list of GPIO configuration register values. If
+    absent, no configuration of these registers is performed. If any
+    entry has a value that is out of range for a 16 bit register then
+    the chip default will be used.  If present exactly five values must
+    be specified.
+Example:
+codec: wm5102@1a {
+        compatible = "wlf,wm5102";
+        reg = <0x1a>;
+        interrupts = <347>;
+        #interrupt-cells = <2>;
+        interrupt-parent = <&gic>;
+        gpio-controller;
+        #gpio-cells = <2>;
+        wlf,gpio-defaults = <
+                0x00000000, /* AIF1TXLRCLK */
+                0xffffffff,
+                0xffffffff,
+                0xffffffff,
+                0xffffffff,
+        >;
+};
diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt
new file mode 100644
index 000000000000..11921cc417bf
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max77693.txt
@@ -0,0 +1,55 @@
+Maxim MAX77693 multi-function device
+MAX77693 is a Multifunction device with the following submodules:
+- PMIC,
+- CHARGER,
+- LED,
+- MUIC,
+- HAPTIC
+It is interfaced to host controller using i2c.
+This document describes the bindings for the mfd device.
+Required properties:
+- compatible : Must be "maxim,max77693".
+- reg : Specifies the i2c slave address of PMIC block.
+- interrupts : This i2c device has an IRQ line connected to the main SoC.
+- interrupt-parent :  The parent interrupt controller.
+Optional properties:
+- regulators : The regulators of max77693 have to be instantiated under subnod
+  named "regulators" using the following format.
+        regulators {
+                regualtor-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER
+                standard regulator constratints[*].
+        };
+        [*] refer Documentation/devicetree/bindings/regulator/regulator.txt
+Example:
+        max77693@66 {
+                compatible = "maxim,max77693";
+                reg = <0x66>;
+                interrupt-parent = <&gpx1>;
+                interrupts = <5 2>;
+                regulators {
+                        esafeout@1 {
+                                regulator-compatible = "ESAFEOUT1";
+                                regulator-name = "ESAFEOUT1";
+                                regulator-boot-on;
+                        };
+                        esafeout@2 {
+                                regulator-compatible = "ESAFEOUT2";
+                                regulator-name = "ESAFEOUT2";
+                                };
+                        charger@0 {
+                                regulator-compatible = "CHARGER";
+                                regulator-name = "CHARGER";
+                                regulator-min-microamp = <60000>;
+                                regulator-max-microamp = <2580000>;
+                                        regulator-boot-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/max8998.txt b/Documentation/devicetree/bindings/mfd/max8998.txt
new file mode 100644
index 000000000000..23a3650ff2a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/max8998.txt
@@ -0,0 +1,119 @@
+* Maxim MAX8998, National/TI LP3974 multi-function device
+The Maxim MAX8998 is a multi-function device which includes voltage/current
+regulators, real time clock, battery charging controller and several
+other sub-blocks. It is interfaced using an I2C interface. Each sub-block
+is addressed by the host system using different i2c slave address.
+PMIC sub-block
+--------------
+The PMIC sub-block contains a number of voltage and current regulators,
+with controllable parameters and dynamic voltage scaling capability.
+In addition, it includes a real time clock and battery charging controller
+as well. It is accessible at I2C address 0x66.
+Required properties:
+- compatible: Should be one of the following:
+    - "maxim,max8998" for Maxim MAX8998
+    - "national,lp3974" or "ti,lp3974" for National/TI LP3974.
+- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the interrupts from MAX8998 are routed to.
+- interrupts: Interrupt specifiers for two interrupt sources.
+  - First interrupt specifier is for main interrupt.
+  - Second interrupt specifier is for power-on/-off interrupt.
+- max8998,pmic-buck1-dvs-gpios: GPIO specifiers for two host gpios used
+  for buck 1 dvs. The format of the gpio specifier depends on the gpio
+  controller.
+- max8998,pmic-buck2-dvs-gpio: GPIO specifier for host gpio used
+  for buck 2 dvs. The format of the gpio specifier depends on the gpio
+  controller.
+- max8998,pmic-buck1-default-dvs-idx: Default voltage setting selected from
+  the possible 4 options selectable by the dvs gpios. The value of this
+  property should be 0, 1, 2 or 3. If not specified or out of range,
+  a default value of 0 is taken.
+- max8998,pmic-buck2-default-dvs-idx: Default voltage setting selected from
+  the possible 2 options selectable by the dvs gpios. The value of this
+  property should be 0 or 1. If not specified or out of range, a default
+  value of 0 is taken.
+- max8998,pmic-buck-voltage-lock: If present, disallows changing of
+  preprogrammed buck dvfs voltages.
+Additional properties required if max8998,pmic-buck1-dvs-gpios is defined:
+- max8998,pmic-buck1-dvs-voltage: An array of 4 voltage values in microvolts
+  for buck1 regulator that can be selected using dvs gpio.
+Additional properties required if max8998,pmic-buck2-dvs-gpio is defined:
+- max8998,pmic-buck2-dvs-voltage: An array of 2 voltage values in microvolts
+  for buck2 regulator that can be selected using dvs gpio.
+Regulators: All the regulators of MAX8998 to be instantiated shall be
+listed in a child node named 'regulators'. Each regulator is represented
+by a child node of the 'regulators' node.
+        regulator-name {
+                /* standard regulator bindings here */
+        };
+Following regulators of the MAX8998 PMIC block are supported. Note that
+the 'n' in regulator name, as in LDOn or BUCKn, represents the LDO or BUCK
+number as described in MAX8998 datasheet.
+        - LDOn
+                  - valid values for n are 2 to 17
+                  - Example: LDO2, LDO10, LDO17
+        - BUCKn
+                  - valid values for n are 1 to 4.
+                  - Example: BUCK1, BUCK2, BUCK3, BUCK4
+        - ENVICHG: Battery Charging Current Monitor Output. This is a fixed
+                   voltage type regulator
+        - ESAFEOUT1: (ldo19)
+        - ESAFEOUT2: (ld020)
+Standard regulator bindings are used inside regulator subnodes. Check
+  Documentation/devicetree/bindings/regulator/regulator.txt
+for more details.
+Example:
+        pmic@66 {
+                compatible = "maxim,max8998-pmic";
+                reg = <0x66>;
+                interrupt-parent = <&wakeup_eint>;
+                interrupts = <4 0>, <3 0>;
+                /* Buck 1 DVS settings */
+                max8998,pmic-buck1-default-dvs-idx = <0>;
+                max8998,pmic-buck1-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
+                                               <&gpx0 1 1 0 0>; /* SET2 */
+                max8998,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
+                                                 <1000000>, <950000>;
+                /* Buck 2 DVS settings */
+                max8998,pmic-buck2-default-dvs-idx = <0>;
+                max8998,pmic-buck2-dvs-gpio = <&gpx0 0 3 0 0>; /* SET3 */
+                max8998,pmic-buck2-dvs-voltage = <1350000>, <1300000>;
+                /* Regulators to instantiate */
+                regulators {
+                        ldo2_reg: LDO2 {
+                                regulator-name = "VDD_ALIVE_1.1V";
+                                regulator-min-microvolt = <1100000>;
+                                regulator-max-microvolt = <1100000>;
+                                regulator-always-on;
+                        };
+                        buck1_reg: BUCK1 {
+                                regulator-name = "VDD_ARM_1.2V";
+                                regulator-min-microvolt = <950000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt b/Documentation/devicetree/bindings/mfd/palmas.txt
new file mode 100644
index 000000000000..892537d1a48f
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/palmas.txt
@@ -0,0 +1,49 @@
+* palmas device tree bindings
+The TI palmas family current members :-
+twl6035 (palmas)
+twl6037 (palmas)
+tps65913 (palmas)
+tps65914 (palmas)
+Required properties:
+- compatible : Should be from the list
+  ti,twl6035
+  ti,twl6036
+  ti,twl6037
+  ti,tps65913
+  ti,tps65914
+  ti,tps80036
+and also the generic series names
+  ti,palmas
+- interrupt-controller : palmas has its own internal IRQs
+- #interrupt-cells : should be set to 2 for IRQ number and flags
+  The first cell is the IRQ number.
+  The second cell is the flags, encoded as the trigger masks from
+  Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+Optional properties:
+  ti,mux-padX : set the pad register X (1-2) to the correct muxing for the
+                hardware, if not set will use muxing in OTP.
+Example:
+palmas {
+        compatible = "ti,twl6035", "ti,palmas";
+        reg = <0x48>
+        interrupt-parent = <&intc>;
+        interrupt-controller;
+        #interrupt-cells = <2>;
+        ti,mux-pad1 = <0>;
+        ti,mux-pad2 = <0>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        pmic {
+                compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+                ....
+        };
+}
diff --git a/Documentation/devicetree/bindings/mfd/twl4030-power.txt b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
new file mode 100644
index 000000000000..8e15ec35ac99
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/twl4030-power.txt
@@ -0,0 +1,28 @@
+Texas Instruments TWL family (twl4030) reset and power management module
+The power management module inside the TWL family provides several facilities
+to control the power resources, including power scripts. For now, the
+binding only supports the complete shutdown of the system after poweroff.
+Required properties:
+- compatible : must be "ti,twl4030-power"
+Optional properties:
+- ti,use_poweroff: With this flag, the chip will initiates an ACTIVE-to-OFF or
+                   SLEEP-to-OFF transition when the system poweroffs.
+Example:
+&i2c1 {
+        clock-frequency = <2600000>;
+        twl: twl@48 {
+                reg = <0x48>;
+                interrupts = <7>; /* SYS_NIRQ cascaded to intc */
+                interrupt-parent = <&intc>;
+                twl_power: power {
+                        compatible = "ti,twl4030-power";
+                        ti,use_poweroff;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt b/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt
new file mode 100644
index 000000000000..094ae010f2fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/bcm,kona-sdhci.txt
@@ -0,0 +1,16 @@
+Broadcom BCM281xx SDHCI
+This file documents differences between the core properties in mmc.txt
+and the properties present in the bcm281xx SDHCI
+Required properties:
+- compatible : Should be "bcm,kona-sdhci"
+Example:
+sdio2: sdio@0x3f1a0000 {
+        compatible = "bcm,kona-sdhci";
+        reg = <0x3f1a0000 0x10000>;
+        interrupts = <0x0 74 0x4>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 85aada2263d5..458b57f199af 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -28,6 +28,7 @@ Optional properties:
 - cap-mmc-highspeed: MMC high-speed timing is supported
 - cap-power-off-card: powering off the card is safe
 - cap-sdio-irq: enable SDIO IRQ signalling on this interface
+- full-pwr-cycle: full power cycle of the card is supported
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
diff --git a/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
new file mode 100644
index 000000000000..8a3d91d47b6a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/rockchip-dw-mshc.txt
@@ -0,0 +1,23 @@
+* Rockchip specific extensions to the Synopsis Designware Mobile
+  Storage Host Controller
+The Synopsis 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 Synopsis dw mshc controller properties described
+by synopsis-dw-mshc.txt and the properties used by the Rockchip specific
+extensions to the Synopsis Designware Mobile Storage Host Controller.
+Required Properties:
+* compatible: should be
+        - "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following
+Example:
+        rkdwmmc0@12200000 {
+                compatible = "rockchip,rk2928-dw-mshc";
+                reg = <0x12200000 0x1000>;
+                interrupts = <0 75 0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
index 726fd2122a13..cdcebea9c6f5 100644
--- a/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsis-dw-mshc.txt
@@ -39,6 +39,19 @@ Required Properties:
 Optional properties:
+* clocks: from common clock binding: handle to biu and ciu clocks for the
+  bus interface unit clock and the card interface unit clock.
+* clock-names: from common clock binding: Shall be "biu" and "ciu".
+  If the biu clock is missing we'll simply skip enabling it.  If the
+  ciu clock is missing we'll just assume that the clock is running at
+  clock-frequency.  It is an error to omit both the ciu clock and the
+  clock-frequency.
+* clock-frequency: should be the frequency (in Hz) of the ciu clock.  If this
+  is specified and the ciu clock is specified then we'll try to set the ciu
+  clock to this at probe time.
 * num-slots: specifies the number of slots supported by the controller.
  The number of physical slots actually used could be equal or less than the
  value specified by num-slots. If this property is not specified, the value
@@ -51,10 +64,13 @@ Optional properties:
 * card-detect-delay: Delay in milli-seconds before detecting card after card
  insert event. The default value is 0.
-* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+* supports-highspeed: Enables support for high speed cards (up to 50MHz)
 * broken-cd: as documented in mmc core bindings.
+* vmmc-supply: The phandle to the regulator to use for vmmc.  If this is
+  specified we'll defer probe until we can find this regulator.
 Aliases:
 - All the MSHC controller nodes should be represented in the aliases node using
@@ -67,6 +83,8 @@ board specific portions as listed below.
        dwmmc0@12200000 {
                compatible = "snps,dw-mshc";
+                clocks = <&clock 351>, <&clock 132>;
+                clock-names = "biu", "ciu";
                reg = <0x12200000 0x1000>;
                interrupts = <0 75 0>;
                #address-cells = <1>;
@@ -74,11 +92,13 @@ board specific portions as listed below.
        };
        dwmmc0@12200000 {
+                clock-frequency = <400000000>;
                num-slots = <1>;
                supports-highspeed;
                broken-cd;
                fifo-depth = <0x80>;
                card-detect-delay = <200>;
+                vmmc-supply = <&buck8>;
                slot@0 {
                        reg = <0>;
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index 6a983c1d87cd..df338cb5059c 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -29,6 +29,13 @@ Optional properties:
                "bch4"          4-bit BCH ecc code
                "bch8"          8-bit BCH ecc code
+ - ti,nand-xfer-type:           A string setting the data transfer type. One of:
+                "prefetch-polled"       Prefetch polled mode (default)
+                "polled"                Polled mode, without prefetch
+                "prefetch-dma"          Prefetch enabled sDMA mode
+                "prefetch-irq"          Prefetch enabled irq mode
 - elm_id:      Specifies elm device node. This is required to support BCH
                error correction using ELM module.
@@ -55,6 +62,7 @@ Example for an AM33xx board:
                        reg = <0 0 0>; /* CS0, offset 0 */
                        nand-bus-width = <16>;
                        ti,nand-ecc-opt = "bch8";
+                        ti,nand-xfer-type = "polled";
                        gpmc,sync-clk-ps = <0>;
                        gpmc,cs-on-ns = <0>;
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
new file mode 100644
index 000000000000..b90bfcd138ff
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -0,0 +1,22 @@
+* Allwinner EMAC ethernet controller
+Required properties:
+- compatible: should be "allwinner,sun4i-emac".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: A phandle to a phy node defining the PHY address (as the reg
+  property, a single integer).
+- clocks: A phandle to the reference clock for this device
+Optional properties:
+- (local-)mac-address: mac address to be used by this driver
+Example:
+emac: ethernet@01c0b000 {
+       compatible = "allwinner,sun4i-emac";
+       reg = <0x01c0b000 0x1000>;
+       interrupts = <55>;
+       clocks = <&ahb_gates 17>;
+       phy = <&phy0>;
+};
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
new file mode 100644
index 000000000000..00b9f9a3ec1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-mdio.txt
@@ -0,0 +1,26 @@
+* Allwinner A10 MDIO Ethernet Controller interface
+Required properties:
+- compatible: should be "allwinner,sun4i-mdio".
+- reg: address and length of the register set for the device.
+Optional properties:
+- phy-supply: phandle to a regulator if the PHY needs one
+Example at the SoC level:
+mdio@01c0b080 {
+        compatible = "allwinner,sun4i-mdio";
+        reg = <0x01c0b080 0x14>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+};
+And at the board level:
+mdio@01c0b080 {
+        phy-supply = <&reg_emac_3v3>;
+        phy0: ethernet-phy@0 {
+                reg = <0>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt
new file mode 100644
index 000000000000..bcbc3f009158
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -0,0 +1,38 @@
+* Synopsys ARC EMAC 10/100 Ethernet driver (EMAC)
+Required properties:
+- compatible: Should be "snps,arc-emac"
+- reg: Address and length of the register set for the device
+- interrupts: Should contain the EMAC interrupts
+- clock-frequency: CPU frequency. It is needed to calculate and set polling
+period of EMAC.
+- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
+bandwidth of external memory controller might be a limiting factor. That's why
+it's required to specify which data-rate is supported on current SoC or FPGA.
+For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is
+supported (100BASE-TX) set "100".
+- phy: PHY device attached to the EMAC via MDIO bus
+Child nodes of the driver are the individual PHY devices connected to the
+MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
+Optional properties:
+- mac-address: 6 bytes, mac address
+Examples:
+        ethernet@c0fc2000 {
+                compatible = "snps,arc-emac";
+                reg = <0xc0fc2000 0x3c>;
+                interrupts = <6>;
+                mac-address = [ 00 11 22 33 44 55 ];
+                clock-frequency = <80000000>;
+                max-speed = <100>;
+                phy = <&phy0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                phy0: ethernet-phy@0 {
+                        reg = <1>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
index 8ff324eaa889..56d6cc336e1c 100644
--- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -16,6 +16,8 @@ Optional properties:
 - clock-frequency : The oscillator frequency driving the flexcan device
+- xceiver-supply: Regulator that powers the CAN transceiver
 Example:
        can@1c000 {
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 4f2ca6b4a182..05d660e4ac64 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -28,6 +28,8 @@ Optional properties:
 Slave Properties:
 Required properties:
 - phy_id                : Specifies slave phy id
+- phy-mode              : The interface between the SoC and the PHY (a string
+                          that of_get_phy_mode() can understand)
 - mac-address           : Specifies slave MAC address
 Optional properties:
@@ -58,11 +60,13 @@ Examples:
                cpts_clock_shift = <29>;
                cpsw_emac0: slave@0 {
                        phy_id = <&davinci_mdio>, <0>;
+                        phy-mode = "rgmii-txid";
                        /* Filled in by U-Boot */
                        mac-address = [ 00 00 00 00 00 00 ];
                };
                cpsw_emac1: slave@1 {
                        phy_id = <&davinci_mdio>, <1>;
+                        phy-mode = "rgmii-txid";
                        /* Filled in by U-Boot */
                        mac-address = [ 00 00 00 00 00 00 ];
                };
@@ -84,11 +88,13 @@ Examples:
                cpts_clock_shift = <29>;
                cpsw_emac0: slave@0 {
                        phy_id = <&davinci_mdio>, <0>;
+                        phy-mode = "rgmii-txid";
                        /* Filled in by U-Boot */
                        mac-address = [ 00 00 00 00 00 00 ];
                };
                cpsw_emac1: slave@1 {
                        phy_id = <&davinci_mdio>, <1>;
+                        phy-mode = "rgmii-txid";
                        /* Filled in by U-Boot */
                        mac-address = [ 00 00 00 00 00 00 ];
                };
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
new file mode 100644
index 000000000000..2d39c990e641
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -0,0 +1,26 @@
+Davicom DM9000 Fast Ethernet controller
+Required properties:
+- compatible = "davicom,dm9000";
+- reg : physical addresses and sizes of registers, must contain 2 entries:
+    first entry : address register,
+    second entry : data register.
+- interrupt-parent : interrupt controller to which the device is connected
+- interrupts : interrupt specifier specific to interrupt controller
+Optional properties:
+- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
+    to use (from firmware or bootloader)
+- davicom,no-eeprom : Configuration EEPROM is not available
+- davicom,ext-phy : Use external PHY
+Example:
+        ethernet@18000000 {
+                compatible = "davicom,dm9000";
+                reg = <0x18000000 0x2 0x18000004 0x2>;
+                interrupt-parent = <&gpn>;
+                interrupts = <7 4>;
+                local-mac-address = [00 00 de ad be ef];
+                davicom,no-eeprom;
+        };
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 44afa0e5057d..4ff65047bb9a 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: Should be "cdns,[<chip>-]{macb|gem}"
  Use "cdns,at91sam9260-macb" Atmel at91sam9260 and at91sam9263 SoCs.
  Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form: "cdns,macb".
-  Use "cnds,pc302-gem" for Picochip picoXcell pc302 and later devices based on
+  Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
  the Cadence GEM, or the generic form: "cdns,gem".
 - reg: Address and length of the register set for the device
 - interrupts: Should contain macb interrupt
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
new file mode 100644
index 000000000000..a73b79f227e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -0,0 +1,85 @@
+Marvell Orion/Discovery ethernet controller
+=============================================
+The Marvell Discovery ethernet controller can be found on Marvell Orion SoCs
+(Kirkwood, Dove, Orion5x, and Discovery Innovation) and as part of Marvell
+Discovery system controller chips (mv64[345]60).
+The Discovery ethernet controller is described with two levels of nodes. The
+first level describes the ethernet controller itself and the second level
+describes up to 3 ethernet port nodes within that controller. The reason for
+the multiple levels is that the port registers are interleaved within a single
+set of controller registers. Each port node describes port-specific properties.
+Note: The above separation is only true for Discovery system controllers.
+For Orion SoCs we stick to the separation, although there each controller has
+only one port associated. Multiple ports are implemented as multiple single-port
+controllers. As Kirkwood has some issues with proper initialization after reset,
+an extra compatible string is added for it.
+* Ethernet controller node
+Required controller properties:
+ - #address-cells: shall be 1.
+ - #size-cells: shall be 0.
+ - compatible: shall be one of "marvell,orion-eth", "marvell,kirkwood-eth".
+ - reg: address and length of the controller registers.
+Optional controller properties:
+ - clocks: phandle reference to the controller clock.
+ - marvell,tx-checksum-limit: max tx packet size for hardware checksum.
+* 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.
+ - interrupts: port interrupt.
+ - local-mac-address: 6 bytes MAC address.
+Optional port properties:
+ - marvell,tx-queue-size: size of the transmit ring buffer.
+ - marvell,tx-sram-addr: address of transmit descriptor buffer located in SRAM.
+ - marvell,tx-sram-size: size of transmit descriptor buffer located in SRAM.
+ - marvell,rx-queue-size: size of the receive ring buffer.
+ - marvell,rx-sram-addr: address of receive descriptor buffer located in SRAM.
+ - marvell,rx-sram-size: size of receive descriptor buffer located in SRAM.
+and
+ - phy-handle: phandle reference to ethernet PHY.
+or
+ - speed: port speed if no PHY connected.
+ - duplex: port mode if no PHY connected.
+* Node example:
+mdio-bus {
+        ...
+        ethphy: ethernet-phy@8 {
+                device_type = "ethernet-phy";
+                ...
+        };
+};
+eth: ethernet-controller@72000 {
+        compatible = "marvell,orion-eth";
+        #address-cells = <1>;
+        #size-cells = <0>;
+        reg = <0x72000 0x2000>;
+        clocks = <&gate_clk 2>;
+        marvell,tx-checksum-limit = <1600>;
+        ethernet@0 {
+                device_type = "network";
+                compatible = "marvell,orion-eth-port";
+                reg = <0>;
+                interrupts = <29>;
+                phy-handle = <&ethphy>;
+                local-mac-address = [00 00 00 00 00 00];
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
new file mode 100644
index 000000000000..11ace3c3d805
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@ -0,0 +1,9 @@
+Micrel KS8851 Ethernet mac
+Required properties:
+- compatible = "micrel,ks8851-ml" of parallel interface
+- reg : 2 physical address and size of registers for data and command
+- interrupts : interrupt connection
+Optional properties:
+- local-mac-address : Ethernet mac address to use
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 060bbf098ef3..261c563b5f06 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -12,6 +12,16 @@ 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
+        The 1st cell is reset pre-delay in micro seconds.
+        The 2nd cell is reset pulse in micro seconds.
+        The 3rd cell is reset post-delay in micro seconds.
+- snps,pbl              Programmable Burst Length
+- snps,fixed-burst      Program the DMA to use the fixed burst mode
+- snps,mixed-burst      Program the DMA to use the mixed burst mode
 Optional properties:
 - mac-address: 6 bytes, mac address
diff --git a/Documentation/devicetree/bindings/net/via-velocity.txt b/Documentation/devicetree/bindings/net/via-velocity.txt
new file mode 100644
index 000000000000..b3db469b1ad7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/via-velocity.txt
@@ -0,0 +1,20 @@
+* VIA Velocity 10/100/1000 Network Controller
+Required properties:
+- compatible : Should be "via,velocity-vt6110"
+- reg : Address and length of the io space
+- interrupts : Should contain the controller interrupt line
+Optional properties:
+- no-eeprom : PCI network cards use an external EEPROM to store data. Embedded
+        devices quite often set this data in uboot and do not provide an eeprom.
+        Specify this option if you have no external eeprom.
+Examples:
+eth0@d8004000 {
+        compatible = "via,velocity-vt6110";
+        reg = <0xd8004000 0x400>;
+        interrupts = <10>;
+        no-eeprom;
+};
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
new file mode 100644
index 000000000000..e2371f5cdebe
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -0,0 +1,73 @@
+* Synopsis Designware PCIe interface
+Required properties:
+- compatible: should contain "snps,dw-pcie" to identify the
+        core, plus an identifier for the specific instance, such
+        as "samsung,exynos5440-pcie".
+- reg: base addresses and lengths of the pcie controller,
+        the phy controller, additional register for the phy controller.
+- interrupts: interrupt values for level interrupt,
+        pulse interrupt, special interrupt.
+- clocks: from common clock binding: handle to pci clock.
+- clock-names: from common clock binding: should be "pcie" and "pcie_bus".
+- #address-cells: set to <3>
+- #size-cells: set to <2>
+- device_type: set to "pci"
+- ranges: ranges for the PCI memory and I/O regions
+- #interrupt-cells: set to <1>
+- interrupt-map-mask and interrupt-map: standard PCI properties
+        to define the mapping of the PCIe interface to interrupt
+        numbers.
+- reset-gpio: gpio pin number of power good signal
+Example:
+SoC specific DT Entry:
+        pcie@290000 {
+                compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
+                reg = <0x290000 0x1000
+                        0x270000 0x1000
+                        0x271000 0x40>;
+                interrupts = <0 20 0>, <0 21 0>, <0 22 0>;
+                clocks = <&clock 28>, <&clock 27>;
+                clock-names = "pcie", "pcie_bus";
+                #address-cells = <3>;
+                #size-cells = <2>;
+                device_type = "pci";
+                ranges = <0x00000800 0 0x40000000 0x40000000 0 0x00001000   /* configuration space */
+                          0x81000000 0 0          0x40001000 0 0x00010000   /* downstream I/O */
+                          0x82000000 0 0x40011000 0x40011000 0 0x1ffef000>; /* non-prefetchable memory */
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0x0 0 &gic 53>;
+        };
+        pcie@2a0000 {
+                compatible = "samsung,exynos5440-pcie", "snps,dw-pcie";
+                reg = <0x2a0000 0x1000
+                        0x272000 0x1000
+                        0x271040 0x40>;
+                interrupts = <0 23 0>, <0 24 0>, <0 25 0>;
+                clocks = <&clock 29>, <&clock 27>;
+                clock-names = "pcie", "pcie_bus";
+                #address-cells = <3>;
+                #size-cells = <2>;
+                device_type = "pci";
+                ranges = <0x00000800 0 0x60000000 0x60000000 0 0x00001000   /* configuration space */
+                          0x81000000 0 0          0x60001000 0 0x00010000   /* downstream I/O */
+                          0x82000000 0 0x60011000 0x60011000 0 0x1ffef000>; /* non-prefetchable memory */
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0x0 0 &gic 56>;
+        };
+Board specific DT Entry:
+        pcie@290000 {
+                reset-gpio = <&pin_ctrl 5 0>;
+        };
+        pcie@2a0000 {
+                reset-gpio = <&pin_ctrl 22 0>;
+        };
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
new file mode 100644
index 000000000000..f8d405897a94
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -0,0 +1,221 @@
+* Marvell EBU PCIe interfaces
+Mandatory properties:
+- compatible: one of the following values:
+    marvell,armada-370-pcie
+    marvell,armada-xp-pcie
+    marvell,kirkwood-pcie
+- #address-cells, set to <3>
+- #size-cells, set to <2>
+- #interrupt-cells, set to <1>
+- bus-range: PCI bus numbers covered
+- device_type, set to "pci"
+- ranges: ranges for the PCI memory and I/O regions, as well as the
+  MMIO registers to control the PCIe interfaces.
+In addition, the Device Tree node must have sub-nodes describing each
+PCIe interface, having the following mandatory properties:
+- reg: used only for interrupt mapping, so only the first four bytes
+  are used to refer to the correct bus number and device number.
+- assigned-addresses: reference to the MMIO registers used to control
+  this PCIe interface.
+- clocks: the clock associated to this PCIe interface
+- marvell,pcie-port: the physical PCIe port number
+- status: either "disabled" or "okay"
+- device_type, set to "pci"
+- #address-cells, set to <3>
+- #size-cells, set to <2>
+- #interrupt-cells, set to <1>
+- ranges, empty property.
+- interrupt-map-mask and interrupt-map, standard PCI properties to
+  define the mapping of the PCIe interface to interrupt numbers.
+and the following optional properties:
+- marvell,pcie-lane: the physical PCIe lane number, for ports having
+  multiple lanes. If this property is not found, we assume that the
+  value is 0.
+Example:
+pcie-controller {
+        compatible = "marvell,armada-xp-pcie";
+        status = "disabled";
+        device_type = "pci";
+        #address-cells = <3>;
+        #size-cells = <2>;
+        bus-range = <0x00 0xff>;
+        ranges = <0x82000000 0 0xd0040000 0xd0040000 0 0x00002000   /* Port 0.0 registers */
+                  0x82000000 0 0xd0042000 0xd0042000 0 0x00002000   /* Port 2.0 registers */
+                  0x82000000 0 0xd0044000 0xd0044000 0 0x00002000   /* Port 0.1 registers */
+                  0x82000000 0 0xd0048000 0xd0048000 0 0x00002000   /* Port 0.2 registers */
+                  0x82000000 0 0xd004c000 0xd004c000 0 0x00002000   /* Port 0.3 registers */
+                  0x82000000 0 0xd0080000 0xd0080000 0 0x00002000   /* Port 1.0 registers */
+                  0x82000000 0 0xd0082000 0xd0082000 0 0x00002000   /* Port 3.0 registers */
+                  0x82000000 0 0xd0084000 0xd0084000 0 0x00002000   /* Port 1.1 registers */
+                  0x82000000 0 0xd0088000 0xd0088000 0 0x00002000   /* Port 1.2 registers */
+                  0x82000000 0 0xd008c000 0xd008c000 0 0x00002000   /* Port 1.3 registers */
+                  0x82000000 0 0xe0000000 0xe0000000 0 0x08000000   /* non-prefetchable memory */
+                  0x81000000 0 0          0xe8000000 0 0x00100000>; /* downstream I/O */
+        pcie@1,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82000800 0 0xd0040000 0 0x2000>;
+                reg = <0x0800 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 58>;
+                marvell,pcie-port = <0>;
+                marvell,pcie-lane = <0>;
+                clocks = <&gateclk 5>;
+                status = "disabled";
+        };
+        pcie@2,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82001000 0 0xd0044000 0 0x2000>;
+                reg = <0x1000 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 59>;
+                marvell,pcie-port = <0>;
+                marvell,pcie-lane = <1>;
+                clocks = <&gateclk 6>;
+                status = "disabled";
+        };
+        pcie@3,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82001800 0 0xd0048000 0 0x2000>;
+                reg = <0x1800 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 60>;
+                marvell,pcie-port = <0>;
+                marvell,pcie-lane = <2>;
+                clocks = <&gateclk 7>;
+                status = "disabled";
+        };
+        pcie@4,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82002000 0 0xd004c000 0 0x2000>;
+                reg = <0x2000 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 61>;
+                marvell,pcie-port = <0>;
+                marvell,pcie-lane = <3>;
+                clocks = <&gateclk 8>;
+                status = "disabled";
+        };
+        pcie@5,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82002800 0 0xd0080000 0 0x2000>;
+                reg = <0x2800 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 62>;
+                marvell,pcie-port = <1>;
+                marvell,pcie-lane = <0>;
+                clocks = <&gateclk 9>;
+                status = "disabled";
+        };
+        pcie@6,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82003000 0 0xd0084000 0 0x2000>;
+                reg = <0x3000 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 63>;
+                marvell,pcie-port = <1>;
+                marvell,pcie-lane = <1>;
+                clocks = <&gateclk 10>;
+                status = "disabled";
+        };
+        pcie@7,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82003800 0 0xd0088000 0 0x2000>;
+                reg = <0x3800 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 64>;
+                marvell,pcie-port = <1>;
+                marvell,pcie-lane = <2>;
+                clocks = <&gateclk 11>;
+                status = "disabled";
+        };
+        pcie@8,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82004000 0 0xd008c000 0 0x2000>;
+                reg = <0x4000 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 65>;
+                marvell,pcie-port = <1>;
+                marvell,pcie-lane = <3>;
+                clocks = <&gateclk 12>;
+                status = "disabled";
+        };
+        pcie@9,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82004800 0 0xd0042000 0 0x2000>;
+                reg = <0x4800 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 99>;
+                marvell,pcie-port = <2>;
+                marvell,pcie-lane = <0>;
+                clocks = <&gateclk 26>;
+                status = "disabled";
+        };
+        pcie@10,0 {
+                device_type = "pci";
+                assigned-addresses = <0x82005000 0 0xd0082000 0 0x2000>;
+                reg = <0x5000 0 0 0 0>;
+                #address-cells = <3>;
+                #size-cells = <2>;
+                #interrupt-cells = <1>;
+                ranges;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &mpic 103>;
+                marvell,pcie-port = <3>;
+                marvell,pcie-lane = <0>;
+                clocks = <&gateclk 27>;
+                status = "disabled";
+        };
+};
diff --git a/Documentation/devicetree/bindings/pci/pci.txt b/Documentation/devicetree/bindings/pci/pci.txt
new file mode 100644
index 000000000000..41aeed38926d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/pci.txt
@@ -0,0 +1,9 @@
+PCI bus bridges have standardized Device Tree bindings:
+PCI Bus Binding to: IEEE Std 1275-1994
+http://www.openfirmware.org/ofwg/bindings/pci/pci2_1.pdf
+And for the interrupt mapping part:
+Open Firmware Recommended Practice: Interrupt Mapping
+http://www.openfirmware.org/1275/practice/imap/imap0_9d.pdf
diff --git a/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
new file mode 100644
index 000000000000..30b364e504ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/v3-v360epc-pci.txt
@@ -0,0 +1,15 @@
+V3 Semiconductor V360 EPC PCI bridge
+This bridge is found in the ARM Integrator/AP (Application Platform)
+Integrator-specific notes:
+- syscon: should contain a link to the syscon device node (since
+  on the Integrator, some registers in the syscon are required to
+  operate the V3).
+V360 EPC specific notes:
+- reg: should contain the base address of the V3 adapter.
+- interrupts: should contain a reference to the V3 error interrupt
+  as routed on the system.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
index bcfdab5d442e..3a7caf7a744a 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -58,7 +58,7 @@ Some requirements for using fsl,imx-pinctrl binding:
 Examples:
 usdhc@0219c000 { /* uSDHC4 */
-        fsl,card-wired;
+        non-removable;
        vmmc-supply = <&reg_3p3v>;
        status = "okay";
        pinctrl-names = "default";
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt
new file mode 100644
index 000000000000..ddcdeb697c29
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,vf610-pinctrl.txt
@@ -0,0 +1,41 @@
+Freescale Vybrid VF610 IOMUX Controller
+Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
+and usage.
+Required properties:
+- compatible: "fsl,vf610-iomuxc"
+- fsl,pins: two integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN_FUNC_ID CONFIG>, PIN_FUNC_ID is
+  a pin working on a specific function, CONFIG is the pad setting value
+  such as pull-up, speed, ode for this pin. Please refer to Vybrid VF610
+  datasheet for the valid pad config settings.
+CONFIG bits definition:
+PAD_CTL_SPEED_LOW               (1 << 12)
+PAD_CTL_SPEED_MED               (2 << 12)
+PAD_CTL_SPEED_HIGH              (3 << 12)
+PAD_CTL_SRE_FAST                (1 << 11)
+PAD_CTL_SRE_SLOW                (0 << 11)
+PAD_CTL_ODE                     (1 << 10)
+PAD_CTL_HYS                     (1 << 9)
+PAD_CTL_DSE_DISABLE             (0 << 6)
+PAD_CTL_DSE_150ohm              (1 << 6)
+PAD_CTL_DSE_75ohm               (2 << 6)
+PAD_CTL_DSE_50ohm               (3 << 6)
+PAD_CTL_DSE_37ohm               (4 << 6)
+PAD_CTL_DSE_30ohm               (5 << 6)
+PAD_CTL_DSE_25ohm               (6 << 6)
+PAD_CTL_DSE_20ohm               (7 << 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_PKE                     (1 << 3)
+PAD_CTL_PUE                     (1 << 2)
+PAD_CTL_OBE_ENABLE              (1 << 1)
+PAD_CTL_IBE_ENABLE              (1 << 0)
+PAD_CTL_OBE_IBE_ENABLE          (3 << 0)
+Please refer to vf610-pinfunc.h in device tree source folder
+for all available PIN_FUNC_ID for Vybrid VF610.
diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt
new file mode 100644
index 000000000000..a186181c402b
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pdc-pinctrl.txt
@@ -0,0 +1,127 @@
+ImgTec TZ1090 PDC pin controller
+Required properties:
+- compatible: "img,tz1090-pdc-pinctrl"
+- reg: Should contain the register physical address and length of the
+  SOC_GPIO_CONTROL registers in the PDC register region.
+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".
+TZ1090-PDC'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. For this reason, even seemingly boolean
+values are actually tristates in this binding: unspecified, off, or on.
+Unspecified is represented as an absent property, and off/on are represented as
+integer values 0 and 1.
+Required subnode-properties:
+- tz1090,pins : An array of strings. Each string contains the name of a pin or
+  group. Valid values for these names are listed below.
+Optional subnode-properties:
+- tz1090,function: A string containing the name of the function to mux to the
+  pin or group. Valid values for function names are listed below, including
+  which pingroups can be muxed to them.
+- supported generic pinconfig properties (for further details see
+  Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
+  - bias-disable
+  - bias-high-impedance
+  - bias-bus-hold
+  - bias-pull-up
+  - bias-pull-down
+  - input-schmitt-enable
+  - input-schmitt-disable
+  - drive-strength: Integer, control drive strength of pins in mA.
+      2: 2mA
+      4: 4mA
+      8: 8mA
+      12: 12mA
+  - low-power-enable: Flag, power-on-start weak pull-down for invalid power.
+  - low-power-disable: Flag, power-on-start weak pull-down disabled.
+Note that many of these properties are only valid for certain specific pins
+or groups. See the TZ1090 TRM for complete details regarding which groups
+support which functionality. The Linux pinctrl driver may also be a useful
+reference.
+Valid values for pin and group names are:
+  pins:
+    These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
+    bias-bus-hold (which can also be provided to any of the groups below to set
+    it for all gpio pins in that group).
+    gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data, ext_power.
+  mux groups:
+    These all support function.
+    gpio0
+        pins:       gpio0.
+        function:   ir_mod_stable_out.
+    gpio1
+        pins:       gpio1.
+        function:   ir_mod_power_out.
+  drive groups:
+    These support input-schmitt-enable, input-schmitt-disable,
+    drive-strength, low-power-enable, and low-power-disable.
+    pdc
+        pins:   gpio0, gpio1, sys_wake0, sys_wake1, sys_wake2, ir_data,
+                ext_power.
+Example:
+        pinctrl_pdc: pinctrl@02006500 {
+                #gpio-range-cells = <3>;
+                compatible = "img,tz1090-pdc-pinctrl";
+                reg = <0x02006500 0x100>;
+        };
+Example board file extracts:
+        &pinctrl_pdc {
+                pinctrl-names = "default";
+                pinctrl-0 = <&syswake_default>;
+                syswake_default: syswakes {
+                        syswake_cfg {
+                                tz1090,pins =   "sys_wake0",
+                                                "sys_wake1",
+                                                "sys_wake2";
+                                pull-up;
+                        };
+                };
+                irmod_default: irmod {
+                        gpio0_cfg {
+                                tz1090,pins =   "gpio0";
+                                tz1090,function = "ir_mod_stable_out";
+                        };
+                        gpio1_cfg {
+                                tz1090,pins =   "gpio1";
+                                tz1090,function = "ir_mod_power_out";
+                        };
+                };
+        };
+        ir: ir@02006200 {
+                pinctrl-names = "default";
+                pinctrl-0 = <&irmod_default>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt
new file mode 100644
index 000000000000..4b27c99f7f9d
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/img,tz1090-pinctrl.txt
@@ -0,0 +1,227 @@
+ImgTec TZ1090 pin controller
+Required properties:
+- compatible: "img,tz1090-pinctrl"
+- reg: Should contain the register physical address and length of the pad
+  configuration registers (CR_PADS_* and CR_IF_CTL0).
+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".
+TZ1090'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. For this reason, even seemingly boolean
+values are actually tristates in this binding: unspecified, off, or on.
+Unspecified is represented as an absent property, and off/on are represented as
+integer values 0 and 1.
+Required subnode-properties:
+- tz1090,pins : An array of strings. Each string contains the name of a pin or
+  group. Valid values for these names are listed below.
+Optional subnode-properties:
+- tz1090,function: A string containing the name of the function to mux to the
+  pin or group. Valid values for function names are listed below, including
+  which pingroups can be muxed to them.
+- supported generic pinconfig properties (for further details see
+  Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt):
+  - bias-disable
+  - bias-high-impedance
+  - bias-bus-hold
+  - bias-pull-up
+  - bias-pull-down
+  - input-schmitt-enable
+  - input-schmitt-disable
+  - drive-strength: Integer, control drive strength of pins in mA.
+      2: 2mA
+      4: 4mA
+      8: 8mA
+      12: 12mA
+Note that many of these properties are only valid for certain specific pins
+or groups. See the TZ1090 TRM for complete details regarding which groups
+support which functionality. The Linux pinctrl driver may also be a useful
+reference.
+Valid values for pin and group names are:
+  gpio pins:
+    These all support bias-high-impediance, bias-pull-up, bias-pull-down, and
+    bias-bus-hold (which can also be provided to any of the groups below to set
+    it for all pins in that group).
+    They also all support the some form of muxing. Any pins which are contained
+    in one of the mux groups (see below) can be muxed only to the functions
+    supported by the mux group. All other pins can be muxed to the "perip"
+    function which which enables them with their intended peripheral.
+    Different pins in the same mux group cannot be muxed to different functions,
+    however it is possible to mux only a subset of the pins in a mux group to a
+    particular function and leave the remaining pins unmuxed. This is useful if
+    the board connects certain pins in a group to other devices to be controlled
+    by GPIO, and you don't want the usual peripheral to have any control of the
+    pin.
+    ant_sel0, ant_sel1, gain0, gain1, gain2, gain3, gain4, gain5, gain6, gain7,
+    i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2, i2s_lrclk_out,
+    i2s_mclk, pa_on, pdm_a, pdm_b, pdm_c, pdm_d, pll_on, rx_hp, rx_on,
+    scb0_sclk, scb0_sdat, scb1_sclk, scb1_sdat, scb2_sclk, scb2_sdat, sdh_cd,
+    sdh_clk_in, sdh_wp, sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
+    spi0_cs0, spi0_cs1, spi0_cs2, spi0_din, spi0_dout, spi0_mclk, spi1_cs0,
+    spi1_cs1, spi1_cs2, spi1_din, spi1_dout, spi1_mclk, tft_blank_ls, tft_blue0,
+    tft_blue1, tft_blue2, tft_blue3, tft_blue4, tft_blue5, tft_blue6, tft_blue7,
+    tft_green0, tft_green1, tft_green2, tft_green3, tft_green4, tft_green5,
+    tft_green6, tft_green7, tft_hsync_nr, tft_panelclk, tft_pwrsave, tft_red0,
+    tft_red1, tft_red2, tft_red3, tft_red4, tft_red5, tft_red6, tft_red7,
+    tft_vd12acb, tft_vdden_gd, tft_vsync_ns, tx_on, uart0_cts, uart0_rts,
+    uart0_rxd, uart0_txd, uart1_rxd, uart1_txd.
+        bias-high-impediance:  supported.
+        bias-pull-up:          supported.
+        bias-pull-down:        supported.
+        bias-bus-hold:         supported.
+        function:              perip or those supported by pin's mux group.
+  other pins:
+    These other pins are part of various pin groups below, but can't be
+    controlled as GPIOs. They do however support bias-high-impediance,
+    bias-pull-up, bias-pull-down, and bias-bus-hold (which can also be provided
+    to any of the groups below to set it for all pins in that group).
+    clk_out0, clk_out1, tck, tdi, tdo, tms, trst.
+        bias-high-impediance:  supported.
+        bias-pull-up:          supported.
+        bias-pull-down:        supported.
+        bias-bus-hold:         supported.
+  mux groups:
+    These all support function, and some support drive configs.
+    afe
+        pins:                  tx_on, rx_on, pll_on, pa_on, rx_hp, ant_sel0,
+                               ant_sel1, gain0, gain1, gain2, gain3, gain4,
+                               gain5, gain6, gain7.
+        function:              afe, ts_out_0.
+        input-schmitt-enable:  supported.
+        input-schmitt-disable: supported.
+        drive-strength:        supported.
+    pdm_d
+        pins:                  pdm_d.
+        function:              pdm_dac, usb_vbus.
+    sdh
+        pins:                  sdh_cd, sdh_wp, sdh_clk_in.
+        function:              sdh, sdio.
+    sdio
+        pins:                  sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2,
+                               sdio_d3.
+        function:              sdio, sdh.
+    spi1_cs2
+        pins:                  spi1_cs2.
+        function:              spi1_cs2, usb_vbus.
+    tft
+        pins:                  tft_red0, tft_red1, tft_red2, tft_red3,
+                               tft_red4, tft_red5, tft_red6, tft_red7,
+                               tft_green0, tft_green1, tft_green2, tft_green3,
+                               tft_green4, tft_green5, tft_green6, tft_green7,
+                               tft_blue0, tft_blue1, tft_blue2, tft_blue3,
+                               tft_blue4, tft_blue5, tft_blue6, tft_blue7,
+                               tft_vdden_gd, tft_panelclk, tft_blank_ls,
+                               tft_vsync_ns, tft_hsync_nr, tft_vd12acb,
+                               tft_pwrsave.
+        function:              tft, ext_dac, not_iqadc_stb, iqdac_stb, ts_out_1,
+                               lcd_trace, phy_ringosc.
+        input-schmitt-enable:  supported.
+        input-schmitt-disable: supported.
+        drive-strength:        supported.
+  drive groups:
+    These all support input-schmitt-enable, input-schmitt-disable,
+    and drive-strength.
+    jtag
+        pins:   tck, trst, tdi, tdo, tms.
+    scb1
+        pins:   scb1_sdat, scb1_sclk.
+    scb2
+        pins:   scb2_sdat, scb2_sclk.
+    spi0
+        pins:   spi0_mclk, spi0_cs0, spi0_cs1, spi0_cs2, spi0_dout, spi0_din.
+    spi1
+        pins:   spi1_mclk, spi1_cs0, spi1_cs1, spi1_cs2, spi1_dout, spi1_din.
+    uart
+        pins:   uart0_txd, uart0_rxd, uart0_rts, uart0_cts,
+                uart1_txd, uart1_rxd.
+    drive_i2s
+        pins:   clk_out1, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
+                i2s_lrclk_out, i2s_bclk_out, i2s_mclk.
+    drive_pdm
+        pins:   clk_out0, pdm_b, pdm_a.
+    drive_scb0
+        pins:   scb0_sclk, scb0_sdat, pdm_d, pdm_c.
+    drive_sdio
+        pins:   sdio_clk, sdio_cmd, sdio_d0, sdio_d1, sdio_d2, sdio_d3,
+                sdh_wp, sdh_cd, sdh_clk_in.
+  convenience groups:
+    These are just convenient groupings of pins and don't support any drive
+    configs.
+    uart0
+        pins:   uart0_cts, uart0_rts, uart0_rxd, uart0_txd.
+    uart1
+        pins:   uart1_rxd, uart1_txd.
+    scb0
+        pins:   scb0_sclk, scb0_sdat.
+    i2s
+        pins:   i2s_bclk_out, i2s_din, i2s_dout0, i2s_dout1, i2s_dout2,
+                i2s_lrclk_out, i2s_mclk.
+Example:
+        pinctrl: pinctrl@02005800 {
+                #gpio-range-cells = <3>;
+                compatible = "img,tz1090-pinctrl";
+                reg = <0x02005800 0xe4>;
+        };
+Example board file extract:
+        &pinctrl {
+                uart0_default: uart0 {
+                        uart0_cfg {
+                                tz1090,pins =   "uart0_rxd",
+                                                "uart0_txd";
+                                tz1090,function = "perip";
+                        };
+                };
+                tft_default: tft {
+                        tft_cfg {
+                                tz1090,pins =   "tft";
+                                tz1090,function = "tft";
+                        };
+                };
+        };
+        uart@02004b00 {
+                pinctrl-names = "default";
+                pinctrl-0 = <&uart0_default>;
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
index a648aaad6110..50ec3512a292 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -10,29 +10,31 @@ Required properties:
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
 only for more detailed description in this document.
+Note: pmu* also allows for Power Management functions listed below
 name          pins     functions
 ================================================================================
-mpp0          0        gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm)
+mpp0          0        gpio, pmu, uart2(rts), sdio0(cd), lcd0(pwm), pmu*
-mpp1          1        gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm)
+mpp1          1        gpio, pmu, uart2(cts), sdio0(wp), lcd1(pwm), pmu*
 mpp2          2        gpio, pmu, uart2(txd), sdio0(buspwr), sata(prsnt),
-                       uart1(rts)
+                       uart1(rts), pmu*
 mpp3          3        gpio, pmu, uart2(rxd), sdio0(ledctrl), sata(act),
-                       uart1(cts), lcd-spi(cs1)
+                       uart1(cts), lcd-spi(cs1), pmu*
-mpp4          4        gpio, pmu, uart3(rts), sdio1(cd), spi1(miso)
+mpp4          4        gpio, pmu, uart3(rts), sdio1(cd), spi1(miso), pmu*
-mpp5          5        gpio, pmu, uart3(cts), sdio1(wp), spi1(cs)
+mpp5          5        gpio, pmu, uart3(cts), sdio1(wp), spi1(cs), pmu*
-mpp6          6        gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi)
+mpp6          6        gpio, pmu, uart3(txd), sdio1(buspwr), spi1(mosi), pmu*
-mpp7          7        gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck)
+mpp7          7        gpio, pmu, uart3(rxd), sdio1(ledctrl), spi1(sck), pmu*
-mpp8          8        gpio, pmu, watchdog(rstout)
+mpp8          8        gpio, pmu, watchdog(rstout), pmu*
-mpp9          9        gpio, pmu, pex1(clkreq)
+mpp9          9        gpio, pmu, pex1(clkreq), pmu*
-mpp10         10       gpio, pmu, ssp(sclk)
+mpp10         10       gpio, pmu, ssp(sclk), pmu*
 mpp11         11       gpio, pmu, sata(prsnt), sata-1(act), sdio0(ledctrl),
-                       sdio1(ledctrl), pex0(clkreq)
+                       sdio1(ledctrl), pex0(clkreq), pmu*
-mpp12         12       gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd), sata(act)
+mpp12         12       gpio, pmu, uart2(rts), audio0(extclk), sdio1(cd),
+                       sata(act), pmu*
 mpp13         13       gpio, pmu, uart2(cts), audio1(extclk), sdio1(wp),
-                       ssp(extclk)
+                       ssp(extclk), pmu*
-mpp14         14       gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd)
+mpp14         14       gpio, pmu, uart2(txd), sdio1(buspwr), ssp(rxd), pmu*
-mpp15         15       gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm)
+mpp15         15       gpio, pmu, uart2(rxd), sdio1(ledctrl), ssp(sfrm), pmu*
 mpp16         16       gpio, uart3(rts), sdio0(cd), ac97(sdi1), lcd-spi(cs1)
 mpp17         17       gpio, uart3(cts), sdio0(wp), ac97(sdi2), twsi(sda),
                       ac97-1(sysclko)
@@ -57,6 +59,21 @@ mpp_nand      64-71    gpo, nand
 audio0        -        i2s, ac97
 twsi          -        none, opt1, opt2, opt3
+Power Management functions (pmu*):
+pmu-nc               Pin not driven by any PM function
+pmu-low              Pin driven low (0)
+pmu-high             Pin driven high (1)
+pmic(sdi)            Pin is used for PMIC SDI
+cpu-pwr-down         Pin is used for CPU_PWRDWN
+standby-pwr-down     Pin is used for STBY_PWRDWN
+core-pwr-good        Pin is used for CORE_PWR_GOOD (Pins 0-7 only)
+cpu-pwr-good         Pin is used for CPU_PWR_GOOD (Pins 8-15 only)
+bat-fault            Pin is used for BATTERY_FAULT
+ext0-wakeup          Pin is used for EXT0_WU
+ext1-wakeup          Pin is used for EXT0_WU
+ext2-wakeup          Pin is used for EXT0_WU
+pmu-blink            Pin is used for blink function
 Notes:
 * group "mpp_audio1" allows the following functions and gpio pins:
  - gpio          : gpio on pins 52-57
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
index c95ea8278f87..aeb3c995cc04 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
@@ -126,3 +126,51 @@ device; they may be grandchildren, for example. Whether this is legal, and
 whether there is any interaction between the child and intermediate parent
 nodes, is again defined entirely by the binding for the individual pin
 controller device.
+== Using generic pinconfig options ==
+Generic pinconfig parameters can be used by defining a separate node containing
+the applicable parameters (and optional values), like:
+pcfg_pull_up: pcfg_pull_up {
+        bias-pull-up;
+        drive-strength = <20>;
+};
+This node should then be referenced in the appropriate pinctrl node as a phandle
+and parsed in the driver using the pinconf_generic_parse_dt_config function.
+Supported configuration parameters are:
+bias-disable            - disable any pin bias
+bias-high-impedance     - high impedance mode ("third-state", "floating")
+bias-bus-hold           - latch weakly
+bias-pull-up            - pull up the pin
+bias-pull-down          - pull down the pin
+bias-pull-pin-default   - use pin-default pull state
+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-schmitt-enable    - enable schmitt-trigger mode
+input-schmitt-disable   - disable schmitt-trigger mode
+input-debounce          - debounce mode with debound time X
+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
+Arguments for parameters:
+- bias-pull-up, -down and -pin-default take as optional argument on hardware
+  supporting it the pull strength in Ohm. bias-disable will disable the pull.
+- drive-strength takes as argument the target strength in mA.
+- input-debounce takes the debounce time in usec as argument
+  or 0 to disable debouncing
+All parameters not listed here, do not take an argument.
+More in-depth documentation on these parameters can be found in
+<include/linux/pinctrl/pinconfig-generic.h>
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 08f0c3d01575..5a02e30dd262 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -18,7 +18,8 @@ Optional properties:
  pin functions is ignored
 - pinctrl-single,bit-per-mux : boolean to indicate that one register controls
-  more than one pin
+  more than one pin, for which "pinctrl-single,function-mask" property specifies
+ position mask of pin.
 - pinctrl-single,drive-strength : array of value that are used to configure
  drive strength in the pinmux register. They're value of drive strength
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
new file mode 100644
index 000000000000..05bf82a07dfd
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
@@ -0,0 +1,110 @@
+*ST pin controller.
+Each multi-function pin is controlled, driven and routed through the
+PIO multiplexing block. Each pin supports GPIO functionality (ALT0)
+and multiple alternate functions(ALT1 - ALTx) that directly connect
+the pin to different hardware blocks.
+When a pin is in GPIO mode, Output Enable (OE), Open Drain(OD), and
+Pull Up (PU) are driven by the related PIO block.
+ST pinctrl driver controls PIO multiplexing block and also interacts with
+gpio driver to configure a pin.
+Required properties: (PIO multiplexing block)
+- compatible    : should be "st,<SOC>-<pio-block>-pinctrl"
+        like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on.
+- gpio-controller : Indicates this device is a GPIO controller
+- #gpio-cells     : Should be one. The first cell is the pin number.
+- st,retime-pin-mask    : Should be mask to specify which pins can be retimed.
+        If the property is not present, it is assumed that all the pins in the
+        bank are capable of retiming. Retiming is mainly used to improve the
+        IO timing margins of external synchronous interfaces.
+- st,bank-name          : Should be a name string for this bank as
+                        specified in datasheet.
+- st,syscfg             : Should be a phandle of the syscfg node.
+Example:
+        pin-controller-sbc {
+                #address-cells  = <1>;
+                #size-cells     = <1>;
+                compatible      = "st,stih415-sbc-pinctrl";
+                st,syscfg       = <&syscfg_sbc>;
+                ranges          = <0 0xfe610000 0x5000>;
+                PIO0: gpio@fe610000 {
+                        gpio-controller;
+                        #gpio-cells     = <1>;
+                        reg             = <0 0x100>;
+                        st,bank-name    = "PIO0";
+                };
+                ...
+                pin-functions nodes follow...
+        };
+Contents of function subnode node:
+----------------------
+Required properties for pin configuration node:
+- st,pins       : Child node with list of pins with configuration.
+Below is the format of how each pin conf should look like.
+<bank offset mux mode rt_type rt_delay rt_clk>
+Every PIO is represented with 4-7 parameters depending on retime configuration.
+Each parameter is explained as below.
+-bank           : Should be bank phandle to which this PIO belongs.
+-offset         : Offset in the PIO bank.
+-mux            : Should be alternate function number associated this pin.
+                Use same numbers from datasheet.
+-mode           :pin configuration is selected from one of the below values.
+                IN
+                IN_PU
+                OUT
+                BIDIR
+                BIDIR_PU
+-rt_type        Retiming Configuration for the pin.
+                Possible retime configuration are:
+                -------         -------------
+                value           args
+                -------         -------------
+                NICLK           <delay> <clk>
+                ICLK_IO         <delay> <clk>
+                BYPASS          <delay>
+                DE_IO           <delay> <clk>
+                SE_ICLK_IO      <delay> <clk>
+                SE_NICLK_IO     <delay> <clk>
+- delay is retime delay in pico seconds as mentioned in data sheet.
+- rt_clk        :clk to be use for retime.
+                Possible values are:
+                CLK_A
+                CLK_B
+                CLK_C
+                CLK_D
+Example of mmcclk pin which is a bi-direction pull pu with retime config
+as non inverted clock retimed with CLK_B and delay of 0 pico seconds:
+pin-controller {
+        ...
+        mmc0 {
+                pinctrl_mmc: mmc {
+                        st,pins {
+                                mmcclk = <&PIO13 4 ALT4 BIDIR_PU NICLK 0 CLK_B>;
+                                ...
+                        };
+                };
+        ...
+        };
+};
+sdhci0:sdhci@fe810000{
+        ...
+        pinctrl-names = "default";
+        pinctrl-0       = <&pinctrl_mmc>;
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
new file mode 100644
index 000000000000..d5dac7b843a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc-pinctrl.txt
@@ -0,0 +1,153 @@
+* Renesas Pin Function Controller (GPIO and Pin Mux/Config)
+The Pin Function Controller (PFC) is a Pin Mux/Config controller. On SH7372,
+SH73A0, R8A73A4 and R8A7740 it also acts as a GPIO controller.
+Pin Control
+-----------
+Required Properties:
+  - compatible: should be one of the following.
+    - "renesas,pfc-r8a73a4": for R8A73A4 (R-Mobile APE6) compatible pin-controller.
+    - "renesas,pfc-r8a7740": for R8A7740 (R-Mobile A1) compatible pin-controller.
+    - "renesas,pfc-r8a7778": for R8A7778 (R-Mobile M1) compatible pin-controller.
+    - "renesas,pfc-r8a7779": for R8A7779 (R-Car H1) compatible pin-controller.
+    - "renesas,pfc-r8a7790": for R8A7790 (R-Car H2) compatible pin-controller.
+    - "renesas,pfc-sh7372": for SH7372 (SH-Mobile AP4) compatible pin-controller.
+    - "renesas,pfc-sh73a0": for SH73A0 (SH-Mobile AG5) compatible pin-controller.
+  - reg: Base address and length of each memory resource used by the pin
+    controller hardware module.
+Optional properties:
+  - #gpio-range-cells: Mandatory when the PFC doesn't handle GPIO, forbidden
+    otherwise. Should be 3.
+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.
+Each pin configuration node represents a desired configuration for a pin, a
+pin group, or a list of pins or pin groups. The configuration can include the
+function to select on those pin(s) and pin configuration parameters (such as
+pull-up and pull-down).
+Pin configuration nodes contain pin configuration properties, either directly
+or grouped in child subnodes. Both pin muxing and configuration parameters can
+be grouped in that way and referenced as a single pin configuration node by
+client devices.
+A configuration node or subnode must reference at least one pin (through the
+pins or pin groups properties) and contain at least a function or one
+configuration parameter. When the function is present only pin groups can be
+used to reference pins.
+All pin configuration nodes and subnodes names are ignored. All of those nodes
+are parsed through phandles and processed purely based on their content.
+Pin Configuration Node Properties:
+- renesas,pins : An array of strings, each string containing the name of a pin.
+- renesas,groups : An array of strings, each string containing the name of a pin
+  group.
+- renesas,function: A string containing the name of the function to mux to the
+  pin group(s) specified by the renesas,groups property
+  Valid values for pin, group and function names can be found in the group and
+  function arrays of the PFC data file corresponding to the SoC
+  (drivers/pinctrl/sh-pfc/pfc-*.c)
+The pin configuration parameters use the generic pinconf bindings defined in
+pinctrl-bindings.txt in this directory. The supported parameters are
+bias-disable, bias-pull-up and bias-pull-down.
+GPIO
+----
+On SH7372, SH73A0, R8A73A4 and R8A7740 the PFC node is also a GPIO controller
+node.
+Required Properties:
+  - gpio-controller: Marks the device node as a gpio controller.
+  - #gpio-cells: Should be 2. The first cell is the GPIO number and the second
+    cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the
+    GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported.
+The syntax of the gpio specifier used by client nodes should be the following
+with values derived from the SoC user manual.
+  <[phandle of the gpio controller node]
+   [pin number within the gpio controller]
+   [flags]>
+On other mach-shmobile platforms GPIO is handled by the gpio-rcar driver.
+Please refer to Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
+for documentation of the GPIO device tree bindings on those platforms.
+Examples
+--------
+Example 1: SH73A0 (SH-Mobile AG5) pin controller node
+        pfc: pfc@e6050000 {
+                compatible = "renesas,pfc-sh73a0";
+                reg = <0xe6050000 0x8000>,
+                      <0xe605801c 0x1c>;
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
+Example 2: A GPIO LED node that references a GPIO
+        #include <dt-bindings/gpio/gpio.h>
+        leds {
+                compatible = "gpio-leds";
+                led1 {
+                        gpios = <&pfc 20 GPIO_ACTIVE_LOW>;
+                };
+        };
+Example 3: KZM-A9-GT (SH-Mobile AG5) default pin state hog and pin control maps
+           for the MMCIF and SCIFA4 devices
+        &pfc {
+                pinctrl-0 = <&scifa4_pins>;
+                pinctrl-names = "default";
+                mmcif_pins: mmcif {
+                        mux {
+                                renesas,groups = "mmc0_data8_0", "mmc0_ctrl_0";
+                                renesas,function = "mmc0";
+                        };
+                        cfg {
+                                renesas,groups = "mmc0_data8_0";
+                                renesas,pins = "PORT279";
+                                bias-pull-up;
+                        };
+                };
+                scifa4_pins: scifa4 {
+                        renesas,groups = "scifa4_data", "scifa4_ctrl";
+                        renesas,function = "scifa4";
+                };
+        };
+Example 4: KZM-A9-GT (SH-Mobile AG5) default pin state for the MMCIF device
+        &mmcif {
+                pinctrl-0 = <&mmcif_pins>;
+                pinctrl-names = "default";
+                bus-width = <8>;
+                vmmc-supply = <&reg_1p8v>;
+                status = "okay";
+        };
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
new file mode 100644
index 000000000000..b0fb1018d7ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -0,0 +1,97 @@
+* Rockchip Pinmux Controller
+The Rockchip Pinmux Controller, enables the IC
+to share one PAD to several functional blocks. The sharing is done by
+multiplexing the PAD input/output signals. For each PAD there are up to
+4 muxing options with option 0 being the use as a GPIO.
+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".
+The Rockchip pin configuration node is a node of a group of pins which can be
+used for a specific device or function. This node represents both mux and
+config of the pins in that group. The 'pins' selects the function mode(also
+named pin mode) this pin can work on and the 'config' configures various pad
+settings such as pull-up, etc.
+The pins are grouped into up to 5 individual pin banks which need to be
+defined as gpio sub-nodes of the pinmux controller.
+Required properties for iomux controller:
+  - compatible: one of "rockchip,rk2928-pinctrl", "rockchip,rk3066a-pinctrl"
+                       "rockchip,rk3066b-pinctrl", "rockchip,rk3188-pinctrl"
+Required properties for gpio sub nodes:
+  - compatible: "rockchip,gpio-bank"
+  - reg: register of the gpio bank (different than the iomux registerset)
+  - interrupts: base interrupt of the gpio bank in the interrupt controller
+  - clocks: clock that drives this bank
+  - gpio-controller: identifies the node as a gpio controller and pin bank.
+  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
+    binding is used, the amount of cells must be specified as 2. See generic
+    GPIO binding documentation for description of particular cells.
+  - interrupt-controller: identifies the controller node as interrupt-parent.
+  - #interrupt-cells: the value of this property should be 2 and the interrupt
+    cells should use the standard two-cell scheme described in
+    bindings/interrupt-controller/interrupts.txt
+Required properties for pin configuration node:
+  - rockchip,pins: 3 integers array, represents a group of pins mux and config
+    setting. The format is rockchip,pins = <PIN_BANK PIN_BANK_IDX MUX &phandle>.
+    The MUX 0 means gpio and MUX 1 to 3 mean the specific device function.
+    The phandle of a node containing the generic pinconfig options
+    to use, as described in pinctrl-bindings.txt in this directory.
+Examples:
+#include <dt-bindings/pinctrl/rockchip.h>
+...
+pinctrl@20008000 {
+        compatible = "rockchip,rk3066a-pinctrl";
+        reg = <0x20008000 0x150>;
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+        gpio0: gpio0@20034000 {
+                compatible = "rockchip,gpio-bank";
+                reg = <0x20034000 0x100>;
+                interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&clk_gates8 9>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
+        ...
+        pcfg_pull_default: pcfg_pull_default {
+                bias-pull-pin-default
+        };
+        uart2 {
+                uart2_xfer: uart2-xfer {
+                        rockchip,pins = <RK_GPIO1 8 1 &pcfg_pull_default>,
+                                        <RK_GPIO1 9 1 &pcfg_pull_default>;
+                };
+        };
+};
+uart2: serial@20064000 {
+        compatible = "snps,dw-apb-uart";
+        reg = <0x20064000 0x400>;
+        interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+        reg-shift = <2>;
+        reg-io-width = <1>;
+        clocks = <&mux_uart2>;
+        status = "okay";
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart2_xfer>;
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index c70fca146e91..36281e7a2a46 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -7,10 +7,15 @@ on-chip controllers onto these pads.
 Required Properties:
 - compatible: should be one of the following.
+  - "samsung,s3c2412-pinctrl": for S3C2412-compatible pin-controller,
+  - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller,
+  - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller,
+  - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller,
  - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller,
  - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
  - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
  - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
+  - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
 - reg: Base address of the pin controller hardware module and length of
  the address space it occupies.
@@ -21,8 +26,18 @@ Required Properties:
  - gpio-controller: identifies the node as a gpio controller and pin bank.
  - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO
-    binding is used, the amount of cells must be specified as 2. See generic
+    binding is used, the amount of cells must be specified as 2. See the below
-    GPIO binding documentation for description of particular cells.
+    mentioned gpio binding representation for description of particular cells.
+        Eg: <&gpx2 6 0>
+        <[phandle of the gpio controller node]
+        [pin number within the gpio controller]
+        [flags]>
+        Values for gpio specifier:
+        - Pin number: is a value between 0 to 7.
+        - Flags: 0 - Active High
+                 1 - Active Low
 - Pin mux/config groups as child nodes: The pin mux (selecting pin function
  mode) and pin config (pull up/down, driver strength) settings are represented
@@ -106,6 +121,10 @@ B. External Wakeup Interrupts: For supporting external wakeup interrupts, a
   - compatible: identifies the type of the external wakeup interrupt controller
     The possible values are:
+     - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C24xx SoCs except S3C2412 and S3C2413,
+     - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller
+       found on Samsung S3C2412 and S3C2413 SoCs,
     - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller
       found on Samsung S3C64xx SoCs,
     - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller
@@ -266,3 +285,33 @@ Example 4: Set up the default pin state for uart controller.
                pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
        }
+Example 5: A display port client node that supports 'default' pinctrl state
+           and gpio binding.
+        display-port-controller {
+                /* ... */
+                samsung,hpd-gpio = <&gpx2 6 0>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&dp_hpd>;
+        };
+Example 6: Request the gpio for display port controller
+        static int exynos_dp_probe(struct platform_device *pdev)
+        {
+                int hpd_gpio, ret;
+                struct device *dev = &pdev->dev;
+                struct device_node *dp_node = dev->of_node;
+                /* ... */
+                hpd_gpio = of_get_named_gpio(dp_node, "samsung,hpd-gpio", 0);
+                /* ... */
+                ret = devm_gpio_request_one(&pdev->dev, hpd_gpio, GPIOF_IN,
+                                            "hpd_gpio");
+                /* ... */
+        }
diff --git a/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt b/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt
new file mode 100644
index 000000000000..e3865e136067
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/ste,abx500.txt
@@ -0,0 +1,352 @@
+ST Ericsson abx500 pinmux controller
+Required properties:
+- compatible: "stericsson,ab8500-gpio",  "stericsson,ab8540-gpio",
+              "stericsson,ab8505-gpio", "stericsson,ab9540-gpio",
+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".
+ST Ericsson's pin configuration nodes act as a container for an arbitrary 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 input, output, pull up, pull down...
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+Required subnode-properties:
+- ste,pins : An array of strings. Each string contains the name of a pin or
+    group.
+Optional subnode-properties:
+- ste,function: A string containing the name of the function to mux to the
+  pin or group.
+- generic pin configuration option to use. Example :
+        default_cfg {
+                ste,pins = "GPIO1";
+                bias-disable;
+        };
+- ste,config: Handle of pin configuration node containing the generic
+  pinconfig options to use, as described in pinctrl-bindings.txt in
+  this directory. Example :
+        pcfg_bias_disable: pcfg_bias_disable {
+                bias-disable;
+        };
+        default_cfg {
+                ste,pins = "GPIO1";
+                ste.config = <&pcfg_bias_disable>;
+        };
+Example board file extract:
+&pinctrl_abx500 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&sysclkreq2_default_mode>, <&sysclkreq3_default_mode>, <&gpio3_default_mode>, <&sysclkreq6_default_mode>, <&pwmout1_default_mode>, <&pwmout2_default_mode>, <&pwmout3_default_mode>, <&adi1_default_mode>, <&dmic12_default_mode>, <&dmic34_default_mode>, <&dmic56_default_mode>, <&sysclkreq5_default_mode>, <&batremn_default_mode>, <&service_default_mode>, <&pwrctrl0_default_mode>, <&pwrctrl1_default_mode>, <&pwmextvibra1_default_mode>, <&pwmextvibra2_default_mode>, <&gpio51_default_mode>, <&gpio52_default_mode>, <&gpio53_default_mode>, <&gpio54_default_mode>, <&pdmclkdat_default_mode>;
+        sysclkreq2 {
+                sysclkreq2_default_mode: sysclkreq2_default {
+                        default_mux {
+                                ste,function = "sysclkreq";
+                                ste,pins = "sysclkreq2_d_1";
+                        };
+                        default_cfg {
+                                ste,pins = "GPIO1";
+                                bias-disable;
+                        };
+                };
+        };
+        sysclkreq3 {
+                sysclkreq3_default_mode: sysclkreq3_default {
+                        default_mux {
+                                ste,function = "sysclkreq";
+                                ste,pins = "sysclkreq3_d_1";
+                        };
+                        default_cfg {
+                                ste,pins = "GPIO2";
+                                output-low;
+                        };
+                };
+        };
+        gpio3 {
+                gpio3_default_mode: gpio3_default {
+                        default_mux {
+                                ste,function = "gpio";
+                                ste,pins = "gpio3_a_1";
+                        };
+                        default_cfg {
+                                ste,pins = "GPIO3";
+                                output-low;
+                        };
+                };
+        };
+        sysclkreq6 {
+                sysclkreq6_default_mode: sysclkreq6_default {
+                        default_mux {
+                                ste,function = "sysclkreq";
+                                ste,pins = "sysclkreq6_d_1";
+                        };
+                        default_cfg {
+                                ste,pins = "GPIO4";
+                                bias-disable;
+                        };
+                };
+        };
+        pwmout1 {
+                pwmout1_default_mode: pwmout1_default {
+                        default_mux {
+                                ste,function = "pwmout";
+                                ste,pins = "pwmout1_d_1";
+                        };
+                        default_cfg {
+                                ste,pins = "GPIO14";
+                                output-low;
+                        };
+                };
+        };
+        pwmout2 {
+                pwmout2_default_mode: pwmout2_default {
+                        pwmout2_default_mux {
+                                ste,function = "pwmout";
+                                ste,pins = "pwmout2_d_1";
+                        };
+                        pwmout2_default_cfg {
+                                ste,pins = "GPIO15";
+                                output-low;
+                        };
+                };
+        };
+        pwmout3 {
+                pwmout3_default_mode: pwmout3_default {
+                        pwmout3_default_mux {
+                                ste,function = "pwmout";
+                                ste,pins = "pwmout3_d_1";
+                        };
+                        pwmout3_default_cfg {
+                                ste,pins = "GPIO16";
+                                output-low;
+                        };
+                };
+        };
+        adi1 {
+                adi1_default_mode: adi1_default {
+                        adi1_default_mux {
+                                ste,function = "adi1";
+                                ste,pins = "adi1_d_1";
+                        };
+                        adi1_default_cfg1 {
+                                ste,pins = "GPIO17","GPIO19","GPIO20";
+                                bias-disable;
+                        };
+                        adi1_default_cfg2 {
+                                ste,pins = "GPIO18";
+                                output-low;
+                        };
+                };
+        };
+        dmic12 {
+                dmic12_default_mode: dmic12_default {
+                        dmic12_default_mux {
+                                ste,function = "dmic";
+                                ste,pins = "dmic12_d_1";
+                        };
+                        dmic12_default_cfg1 {
+                                ste,pins = "GPIO27";
+                                output-low;
+                        };
+                        dmic12_default_cfg2 {
+                                ste,pins = "GPIO28";
+                                bias-disable;
+                        };
+                };
+        };
+        dmic34 {
+                dmic34_default_mode: dmic34_default {
+                        dmic34_default_mux {
+                                ste,function = "dmic";
+                                ste,pins = "dmic34_d_1";
+                        };
+                        dmic34_default_cfg1 {
+                                ste,pins = "GPIO29";
+                                output-low;
+                        };
+                        dmic34_default_cfg2 {
+                                ste,pins = "GPIO30";
+                                bias-disable;{
+                        };
+                };
+        };
+        dmic56 {
+                dmic56_default_mode: dmic56_default {
+                        dmic56_default_mux {
+                                ste,function = "dmic";
+                                ste,pins = "dmic56_d_1";
+                        };
+                        dmic56_default_cfg1 {
+                                ste,pins = "GPIO31";
+                                output-low;
+                        };
+                        dmic56_default_cfg2 {
+                                ste,pins = "GPIO32";
+                                bias-disable;
+                        };
+                };
+        };
+        sysclkreq5 {
+                sysclkreq5_default_mode: sysclkreq5_default {
+                        sysclkreq5_default_mux {
+                                ste,function = "sysclkreq";
+                                ste,pins = "sysclkreq5_d_1";
+                        };
+                        sysclkreq5_default_cfg {
+                                ste,pins = "GPIO42";
+                                output-low;
+                        };
+                };
+        };
+        batremn {
+                batremn_default_mode: batremn_default {
+                        batremn_default_mux {
+                                ste,function = "batremn";
+                                ste,pins = "batremn_d_1";
+                        };
+                        batremn_default_cfg {
+                                ste,pins = "GPIO43";
+                                bias-disable;
+                        };
+                };
+        };
+        service {
+                service_default_mode: service_default {
+                        service_default_mux {
+                                ste,function = "service";
+                                ste,pins = "service_d_1";
+                        };
+                        service_default_cfg {
+                                ste,pins = "GPIO44";
+                                bias-disable;
+                        };
+                };
+        };
+        pwrctrl0 {
+                pwrctrl0_default_mux: pwrctrl0_mux {
+                        pwrctrl0_default_mux {
+                                ste,function = "pwrctrl";
+                                ste,pins = "pwrctrl0_d_1";
+                        };
+                };
+                pwrctrl0_default_mode: pwrctrl0_default {
+                        pwrctrl0_default_cfg {
+                                ste,pins = "GPIO45";
+                                bias-disable;
+                        };
+                };
+        };
+        pwrctrl1 {
+                pwrctrl1_default_mux: pwrctrl1_mux {
+                        pwrctrl1_default_mux {
+                                ste,function = "pwrctrl";
+                                ste,pins = "pwrctrl1_d_1";
+                        };
+                };
+                pwrctrl1_default_mode: pwrctrl1_default {
+                        pwrctrl1_default_cfg {
+                                ste,pins = "GPIO46";
+                                bias-disable;
+                        };
+                };
+        };
+        pwmextvibra1 {
+                pwmextvibra1_default_mode: pwmextvibra1_default {
+                        pwmextvibra1_default_mux {
+                                ste,function = "pwmextvibra";
+                                ste,pins = "pwmextvibra1_d_1";
+                        };
+                        pwmextvibra1_default_cfg {
+                                ste,pins = "GPIO47";
+                                bias-disable;
+                        };
+                };
+        };
+        pwmextvibra2 {
+                pwmextvibra2_default_mode: pwmextvibra2_default {
+                        pwmextvibra2_default_mux {
+                                ste,function = "pwmextvibra";
+                                ste,pins = "pwmextvibra2_d_1";
+                        };
+                        pwmextvibra1_default_cfg {
+                                ste,pins = "GPIO48";
+                                bias-disable;
+                        };
+                };
+        };
+        gpio51 {
+                gpio51_default_mode: gpio51_default {
+                                gpio51_default_mux {
+                                ste,function = "gpio";
+                                ste,pins = "gpio51_a_1";
+                        };
+                        gpio51_default_cfg {
+                                ste,pins = "GPIO51";
+                                output-low;
+                        };
+                };
+        };
+        gpio52 {
+                gpio52_default_mode: gpio52_default {
+                        gpio52_default_mux {
+                                ste,function = "gpio";
+                                ste,pins = "gpio52_a_1";
+                        };
+                        gpio52_default_cfg {
+                                ste,pins = "GPIO52";
+                                bias-pull-down;
+                        };
+                };
+        };
+        gpio53 {
+                gpio53_default_mode: gpio53_default {
+                        gpio53_default_mux {
+                                ste,function = "gpio";
+                                ste,pins = "gpio53_a_1";
+                        };
+                        gpio53_default_cfg {
+                                ste,pins = "GPIO53";
+                                bias-pull-down;
+                        };
+                };
+        };
+        gpio54 {
+                gpio54_default_mode: gpio54_default {
+                        gpio54_default_mux {
+                                ste,function = "gpio";
+                                ste,pins = "gpio54_a_1";
+                        };
+                        gpio54_default_cfg {
+                                ste,pins = "GPIO54";
+                                output-low;
+                        };
+                };
+        };
+        pdmclkdat {
+                pdmclkdat_default_mode: pdmclkdat_default {
+                        pdmclkdat_default_mux {
+                                ste,function = "pdm";
+                                ste,pins = "pdmclkdat_d_1";
+                        };
+                        pdmclkdat_default_cfg {
+                                ste,pins = "GPIO55", "GPIO56";
+                                bias-disable;
+                        };
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt b/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt
new file mode 100644
index 000000000000..2246bc5c874b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/lp8727_charger.txt
@@ -0,0 +1,44 @@
+Binding for TI/National Semiconductor LP8727 Charger
+Required properties:
+- compatible: "ti,lp8727"
+- reg: I2C slave address 27h
+Optional properties:
+- interrupt-parent: interrupt controller node (see interrupt binding[0])
+- interrupts: interrupt specifier (see interrupt binding[0])
+- debounce-ms: interrupt debounce time. (u32)
+AC and USB charging parameters
+- charger-type: "ac" or "usb" (string)
+- eoc-level: value of 'enum lp8727_eoc_level' (u8)
+- charging-current: value of 'enum lp8727_ichg' (u8)
+[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+Example)
+lp8727@27 {
+        compatible = "ti,lp8727";
+        reg = <0x27>;
+        /* GPIO 134 is used for LP8728 interrupt pin */
+        interrupt-parent = <&gpio5>;    /* base = 128 */
+        interrupts = <6 0x2>;           /* offset = 6, falling edge type */
+        debounce-ms = <300>;
+        /* AC charger: 5% EOC and 500mA charging current */
+        ac {
+                charger-type = "ac";
+                eoc-level = /bits/ 8 <0>;
+                charging-current = /bits/ 8 <4>;
+        };
+        /* USB charger: 10% EOC and 400mA charging current */
+        usb {
+                charger-type = "usb";
+                eoc-level = /bits/ 8 <1>;
+                charging-current = /bits/ 8 <2>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt
index 2161334a7ca5..712baf6c3e24 100644
--- a/Documentation/devicetree/bindings/powerpc/4xx/emac.txt
+++ b/Documentation/devicetree/bindings/powerpc/4xx/emac.txt
@@ -1,7 +1,7 @@
    4xx/Axon EMAC ethernet nodes
    The EMAC ethernet controller in IBM and AMCC 4xx chips, and also
-    the Axon bridge.  To operate this needs to interact with a ths
+    the Axon bridge.  To operate this needs to interact with a this
    special McMAL DMA controller, and sometimes an RGMII or ZMII
    interface.  In addition to the nodes and properties described
    below, the node for the OPB bus on which the EMAC sits must have a
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt b/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt
new file mode 100644
index 000000000000..641bc13983e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/interlaken-lac.txt
@@ -0,0 +1,309 @@
+===============================================================================
+Freescale Interlaken Look-Aside Controller Device Bindings
+Copyright 2012 Freescale Semiconductor Inc.
+CONTENTS
+  - Interlaken Look-Aside Controller (LAC) Node
+  - Example LAC Node
+  - Interlaken Look-Aside Controller (LAC) Software Portal Node
+  - Interlaken Look-Aside Controller (LAC) Software Portal Child Nodes
+  - Example LAC SWP Node with Child Nodes
+==============================================================================
+Interlaken Look-Aside Controller (LAC) Node
+DESCRIPTION
+The Interlaken is a narrow, high speed channelized chip-to-chip interface. To
+facilitate interoperability between a data path device and a look-aside
+co-processor, the Interlaken Look-Aside protocol is defined for short
+transaction-related transfers. Although based on the Interlaken protocol,
+Interlaken Look-Aside is not directly compatible with Interlaken and can be
+considered a different operation mode.
+The Interlaken LA controller connects internal platform to Interlaken serial
+interface. It accepts LA command through software portals, which are system
+memory mapped 4KB spaces. The LA commands are then translated into the
+Interlaken control words and data words, which are sent on TX side to TCAM
+through SerDes lanes.
+There are two 4KiB spaces defined within the LAC global register memory map.
+There is a full register set at 0x0000-0x0FFF (also known as the "hypervisor"
+version), and a subset at 0x1000-0x1FFF.  The former is a superset of the
+latter, and includes certain registers that should not be accessible to
+partitioned software.  Separate nodes are used for each region, with a phandle
+linking the hypervisor node to the normal operating node.
+PROPERTIES
+  - compatible
+        Usage: required
+        Value type: <string>
+        Definition: Must include "fsl,interlaken-lac". This represents only
+                those LAC CCSR registers not protected in partitioned
+                software. The version of the device is determined by the LAC
+                IP Block Revision Register (IPBRR0) at offset 0x0BF8.
+                Table of correspondences between IPBRR0 values and example
+                chips:
+                        Value           Device
+                        -----------     -------
+                        0x02000100      T4240
+                The Hypervisor node has a different compatible. It must include
+                "fsl,interlaken-lac-hv". This node represents the protected
+                LAC register space and is required except inside a partition
+                where access to the hypervisor node is to be denied.
+  - fsl,non-hv-node
+        Usage: required in "fsl,interlaken-lac-hv"
+        Value type: <phandle>
+        Definition: Points to the non-protected LAC CCSR mapped register space
+                node.
+  - reg
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: A standard property. The first resource represents the
+                Interlaken LAC configuration registers.
+  - interrupts:
+        Usage: required in non-hv node only
+        Value type: <prop-encoded-array>
+        Definition: Interrupt mapping for Interlaken LAC error IRQ.
+EXAMPLE
+        lac: lac@229000 {
+                compatible = "fsl,interlaken-lac"
+                reg = <0x229000 0x1000>;
+                interrupts = <16 2 1 18>;
+        };
+        lac-hv@228000 {
+                compatible = "fsl,interlaken-lac-hv"
+                reg = <0x228000 0x1000>;
+                fsl,non-hv-node = <&lac>;
+        };
+===============================================================================
+Interlaken Look-Aside Controller (LAC) Software Portal Container Node
+DESCRIPTION
+The Interlaken Look-Aside Controller (LAC) utilizes Software Portals to accept
+Interlaken Look-Aside (ILA) commands. The Interlaken LAC software portal
+memory map occupies 128KB of memory space. The software portal memory space is
+intended to be cache-enabled. WIMG for each software space is required to be
+0010 if stashing is enabled; otherwise, WIMG can be 0000 or 0010.
+PROPERTIES
+  - #address-cells
+        Usage: required
+        Value type: <u32>
+        Definition: A standard property. Must have a value of 1.
+  - #size-cells
+        Usage: required
+        Value type: <u32>
+        Definition: A standard property. Must have a value of 1.
+  - compatible
+        Usage: required
+        Value type: <string>
+        Definition: Must include "fsl,interlaken-lac-portals"
+  - ranges
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: A standard property. Specifies the address and length
+                of the LAC portal memory space.
+===============================================================================
+Interlaken Look-Aside Controller (LAC) Software Portals Child Nodes
+DESCRIPTION
+There are up to 24 available software portals with each software portal
+requiring 4KB of consecutive memory within the software portal memory mapped
+space.
+PROPERTIES
+  - compatible
+        Usage: required
+        Value type: <string>
+        Definition: Must include "fsl,interlaken-lac-portal-vX.Y" where X is
+                the Major version (IP_MJ) found in the LAC IP Block Revision
+                Register (IPBRR0), at offset 0x0BF8, and Y is the Minor version
+                (IP_MN).
+                Table of correspondences between version values and example chips:
+                    Value       Device
+                    ------      -------
+                      1.0       T4240
+  - reg
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: A standard property.  The first resource represents the
+                Interlaken LAC software portal registers.
+  - fsl,liodn
+        Value type: <u32>
+        Definition: The logical I/O device number (LIODN) for this device.  The
+                LIODN is a number expressed by this device and used to perform
+                look-ups in the IOMMU (PAMU) address table when performing
+                DMAs. This property is automatically added by u-boot.
+===============================================================================
+EXAMPLE
+lac-portals {
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        compatible = "fsl,interlaken-lac-portals";
+        ranges = <0x0 0xf 0xf4400000 0x20000>;
+        lportal0: lac-portal@0 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x204>;
+                reg = <0x0 0x1000>;
+        };
+        lportal1: lac-portal@1000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x205>;
+                reg = <0x1000 0x1000>;
+        };
+        lportal2: lac-portal@2000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x206>;
+                reg = <0x2000 0x1000>;
+        };
+        lportal3: lac-portal@3000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x207>;
+                reg = <0x3000 0x1000>;
+        };
+        lportal4: lac-portal@4000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x208>;
+                reg = <0x4000 0x1000>;
+        };
+        lportal5: lac-portal@5000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x209>;
+                reg = <0x5000 0x1000>;
+        };
+        lportal6: lac-portal@6000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x20A>;
+                reg = <0x6000 0x1000>;
+        };
+        lportal7: lac-portal@7000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x20B>;
+                reg = <0x7000 0x1000>;
+        };
+        lportal8: lac-portal@8000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x20C>;
+                reg = <0x8000 0x1000>;
+        };
+        lportal9: lac-portal@9000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x20D>;
+                reg = <0x9000 0x1000>;
+        };
+        lportal10: lac-portal@A000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x20E>;
+                reg = <0xA000 0x1000>;
+        };
+        lportal11: lac-portal@B000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x20F>;
+                reg = <0xB000 0x1000>;
+        };
+        lportal12: lac-portal@C000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x210>;
+                reg = <0xC000 0x1000>;
+        };
+        lportal13: lac-portal@D000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x211>;
+                reg = <0xD000 0x1000>;
+        };
+        lportal14: lac-portal@E000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x212>;
+                reg = <0xE000 0x1000>;
+        };
+        lportal15: lac-portal@F000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x213>;
+                reg = <0xF000 0x1000>;
+        };
+        lportal16: lac-portal@10000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x214>;
+                reg = <0x10000 0x1000>;
+        };
+        lportal17: lac-portal@11000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x215>;
+                reg = <0x11000 0x1000>;
+        };
+        lportal8: lac-portal@1200 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x216>;
+                reg = <0x12000 0x1000>;
+        };
+        lportal19: lac-portal@13000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x217>;
+                reg = <0x13000 0x1000>;
+        };
+        lportal20: lac-portal@14000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x218>;
+                reg = <0x14000 0x1000>;
+        };
+        lportal21: lac-portal@15000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x219>;
+                reg = <0x15000 0x1000>;
+        };
+        lportal22: lac-portal@16000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x21A>;
+                reg = <0x16000 0x1000>;
+        };
+        lportal23: lac-portal@17000 {
+                compatible = "fsl,interlaken-lac-portal-v1.0";
+                fsl,liodn = <0x21B>;
+                reg = <0x17000 0x1000>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/pps/pps-gpio.txt b/Documentation/devicetree/bindings/pps/pps-gpio.txt
new file mode 100644
index 000000000000..40bf9c3564a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pps/pps-gpio.txt
@@ -0,0 +1,20 @@
+Device-Tree Bindings for a PPS Signal on GPIO
+These properties describe a PPS (pulse-per-second) signal connected to
+a GPIO pin.
+Required properties:
+- compatible: should be "pps-gpio"
+- gpios: one PPS GPIO in the format described by ../gpio/gpio.txt
+Optional properties:
+- assert-falling-edge: when present, assert is indicated by a falling edge
+                       (instead of by a rising edge)
+Example:
+        pps {
+                compatible = "pps-gpio";
+                gpios = <&gpio2 6 0>;
+                assert-falling-edge;
+        };
diff --git a/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
new file mode 100644
index 000000000000..1e3dfe7a4894
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/nxp,pca9685-pwm.txt
@@ -0,0 +1,27 @@
+NXP PCA9685 16-channel 12-bit PWM LED controller
+================================================
+Required properties:
+  - compatible: "nxp,pca9685-pwm"
+  - #pwm-cells: should be 2. The first cell specifies the per-chip index
+    of the PWM to use and the second cell is the period in nanoseconds.
+    The index 16 is the ALLCALL channel, that sets all PWM channels at the same
+    time.
+Optional properties:
+  - invert (bool): boolean to enable inverted logic
+  - open-drain (bool): boolean to configure outputs with open-drain structure;
+                       if omitted use totem-pole structure
+Example:
+For LEDs that are directly connected to the PCA, the following setting is
+applicable:
+pca: pca@41 {
+        compatible = "nxp,pca9685-pwm";
+        #pwm-cells = <2>;
+        reg = <0x41>;
+        invert;
+        open-drain;
+};
diff --git a/Documentation/devicetree/bindings/regulator/lp872x.txt b/Documentation/devicetree/bindings/regulator/lp872x.txt
new file mode 100644
index 000000000000..78183182dad9
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/lp872x.txt
@@ -0,0 +1,160 @@
+Binding for TI/National Semiconductor LP872x Driver
+Required properties:
+  - compatible: "ti,lp8720" or "ti,lp8725"
+  - reg: I2C slave address. 0x7d = LP8720, 0x7a = LP8725
+Optional properties:
+  - ti,general-config: the value of LP872X_GENERAL_CFG register (u8)
+    (LP8720)
+    bit[2]: BUCK output voltage control by external DVS pin or register
+            1 = external pin, 0 = bit7 of register 08h
+    bit[1]: sleep control by external DVS pin or register
+            1 = external pin, 0 = bit6 of register 08h
+    bit[0]: time step unit(usec). 1 = 25, 0 = 50
+    (LP8725)
+    bit[7:6]: time step unit(usec). 00 = 32, 01 = 64, 10 = 128, 11 = 256
+    bit[4]:   BUCK2 enable control. 1 = enable, 0 = disable
+    bit[3]:   BUCK2 output voltage register address. 1 = 0Ah, 0 = 0Bh
+    bit[2]:   BUCK1 output voltage control by external DVS pin or register
+              1 = register 08h, 0 = DVS
+    bit[1]:   LDO sleep control. 1 = sleep mode, 0 = normal
+    bit[0]:   BUCK1 enable control, 1 = enable, 0 = disable
+    For more details, please see the datasheet.
+  - ti,update-config: define it when LP872X_GENERAL_CFG register should be set
+  - ti,dvs-gpio: GPIO specifier for external DVS pin control of LP872x devices.
+  - ti,dvs-vsel: DVS selector. 0 = SEL_V1, 1 = SEL_V2.
+  - ti,dvs-state: initial DVS pin state. 0 = DVS_LOW, 1 = DVS_HIGH.
+  Sub nodes for regulator_init_data
+    LP8720 has maximum 6 nodes. (child name: ldo1 ~ 5 and buck)
+    LP8725 has maximum 9 nodes. (child name: ldo1 ~ 5, lilo1,2 and buck1,2)
+    For more details, please see the following binding document.
+    (Documentation/devicetree/bindings/regulator/regulator.txt)
+Datasheet
+  - LP8720: http://www.ti.com/lit/ds/symlink/lp8720.pdf
+  - LP8725: http://www.ti.com/lit/ds/symlink/lp8725.pdf
+Example 1) LP8720
+lp8720@7d {
+        compatible = "ti,lp8720";
+        reg = <0x7d>;
+        /* external DVS pin used, timestep is 25usec */
+        ti,general-config = /bits/ 8 <0x03>;
+        ti,update-config;
+        /*
+         * The dvs-gpio depends on the processor environment.
+         * For example, following GPIO specifier means GPIO134 in OMAP4.
+         */
+        ti,dvs-gpio = <&gpio5 6 0>;
+        ti,dvs-vsel = /bits/ 8 <1>;             /* SEL_V2 */
+        ti,dvs-state = /bits/ 8 <1>;            /* DVS_HIGH */
+        vaf: ldo1 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vmmc: ldo2 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vcam_io: ldo3 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+                regulator-boot-on;
+        };
+        vcam_core: ldo4 {
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <2850000>;
+                regulator-boot-on;
+        };
+        vcam: ldo5 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vcc: buck {
+                regulator-name = "VBUCK";
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <2300000>;
+        };
+};
+Example 2) LP8725
+lp8725@7a {
+        compatible = "ti,lp8725";
+        reg = <0x7a>;
+        /* Enable BUCK1,2, no DVS, normal LDO mode, timestep is 256usec */
+        ti,general-config = /bits/ 8 <0xdd>;
+        ti,update-config;
+        vcam_io: ldo1 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vcam_core: ldo2 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vcam: ldo3 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vcmmb_io: ldo4 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+                regulator-boot-on;
+        };
+        vcmmb_core: ldo5 {
+                regulator-min-microvolt = <1200000>;
+                regulator-max-microvolt = <3300000>;
+                regulator-boot-on;
+        };
+        vaux1: lilo1 {
+                regulator-name = "VAUX1";
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vaux2: lilo2 {
+                regulator-name = "VAUX2";
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <3300000>;
+        };
+        vcc1: buck1 {
+                regulator-name = "VBUCK1";
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <3000000>;
+                regulator-min-microamp  = <460000>;
+                regulator-max-microamp  = <1370000>;
+                regulator-boot-on;
+        };
+        vcc2: buck2 {
+                regulator-name = "VBUCK2";
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <3000000>;
+                regulator-min-microamp  = <460000>;
+                regulator-max-microamp  = <1370000>;
+                regulator-boot-on;
+        };
+};
diff --git a/Documentation/devicetree/bindings/regulator/max8973-regulator.txt b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
new file mode 100644
index 000000000000..4f15d8a1bfd0
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8973-regulator.txt
@@ -0,0 +1,21 @@
+* Maxim MAX8973 Voltage Regulator
+Required properties:
+- compatible:   must be "maxim,max8973"
+- reg:          the i2c slave address of the regulator. It should be 0x1b.
+Any standard regulator properties can be used to configure the single max8973
+DCDC.
+Example:
+        max8973@1b {
+                compatible = "maxim,max8973";
+                reg = <0x1b>;
+                regulator-min-microvolt = <935000>;
+                regulator-max-microvolt = <1200000>;
+                regulator-boot-on;
+                regulator-always-on;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
index 9e5e51d78868..5c186a7a77ba 100644
--- a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
@@ -1,6 +1,6 @@
 * Maxim MAX8997 Voltage and Current Regulator
-The Maxim MAX8997 is a multi-function device which includes volatage and
+The Maxim MAX8997 is a multi-function device which includes voltage and
 current regulators, rtc, charger controller and other sub-blocks. It is
 interfaced to the host controller using a i2c interface. Each sub-block is
 addressed by the host system using different i2c slave address. This document
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
new file mode 100644
index 000000000000..d5a308629c57
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -0,0 +1,72 @@
+* palmas regulator IP block devicetree bindings
+Required properties:
+- compatible : Should be from the list
+  ti,twl6035-pmic
+  ti,twl6036-pmic
+  ti,twl6037-pmic
+  ti,tps65913-pmic
+  ti,tps65914-pmic
+and also the generic series names
+  ti,palmas-pmic
+- interrupt-parent : The parent interrupt controller which is palmas.
+- interrupts : The interrupt number and the type which can be looked up here:
+               arch/arm/boot/dts/include/dt-bindings/interrupt-controller/irq.h
+- interrupts-name: The names of the individual interrupts.
+Optional properties:
+- ti,ldo6-vibrator : ldo6 is in vibrator mode
+Optional nodes:
+- regulators : Must contain a sub-node per regulator from the list below.
+               Each sub-node should contain the constraints and initialization
+               information for that regulator. See regulator.txt for a
+               description of standard properties for these sub-nodes.
+               Additional custom properties  are listed below.
+               For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP,
+               smps45, smps457, smps7 depending on variant, smps6, smps[8-10],
+               ldo[1-9], ldoln, ldousb.
+               Optional sub-node properties:
+               ti,warm-reset - maintain voltage during warm reset(boolean)
+               ti,roof-floor - control voltage selection by pin(boolean)
+               ti,sleep-mode - mode to adopt in pmic sleep 0 - off, 1 - auto,
+               2 - eco, 3 - forced pwm
+               ti,tstep - slope control 0 - Jump, 1 10mV/us, 2 5mV/us, 3 2.5mV/us
+               ti,smps-range - OTP has the wrong range set for the hardware so override
+               0 - low range, 1 - high range.
+Example:
+#include <dt-bindings/interrupt-controller/irq.h>
+pmic {
+        compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+        interrupt-parent = <&palmas>;
+        interrupts = <14 IRQ_TYPE_NONE>;
+        interrupts-name = "short-irq";
+        ti,ldo6-vibrator;
+        regulators {
+                smps12_reg : smps12 {
+                        regulator-name = "smps12";
+                        regulator-min-microvolt = < 600000>;
+                        regulator-max-microvolt = <1500000>;
+                        regulator-always-on;
+                        regulator-boot-on;
+                        ti,warm-reset;
+                        ti,roof-floor;
+                        ti,mode-sleep = <0>;
+                        ti,tstep = <0>;
+                        ti,smps-range = <1>;
+                };
+                ldo1_reg: ldo1 {
+                        regulator-name = "ldo1";
+                        regulator-min-microvolt = <2800000>;
+                        regulator-max-microvolt = <2800000>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index ecfc6ccd67ef..48a3b8e5d6bd 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -9,6 +9,7 @@ Optional properties:
 - regulator-max-microamp: largest current consumers may set
 - regulator-always-on: boolean, regulator should never be disabled
 - regulator-boot-on: bootloader/firmware enabled regulator
+- regulator-allow-bypass: allow the regulator to go into bypass mode
 - <name>-supply: phandle to the parent supply/regulator node
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
index a35ff99003a5..d1660a90fc06 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -1,6 +1,6 @@
 * Samsung S5M8767 Voltage and Current Regulator
-The Samsung S5M8767 is a multi-function device which includes volatage and
+The Samsung S5M8767 is a multi-function device which includes voltage and
 current regulators, rtc, charger controller and other sub-blocks. It is
 interfaced to the host controller using a i2c interface. Each sub-block is
 addressed by the host system using different i2c slave address. This document
@@ -103,13 +103,13 @@ Example:
                s5m8767,pmic-buck-default-dvs-idx = <0>;
-                s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 1 0 0>, /* DVS1 */
+                s5m8767,pmic-buck-dvs-gpios = <&gpx0 0 0>, /* DVS1 */
-                                                 <&gpx0 1 1 0 0>, /* DVS2 */
+                                                 <&gpx0 1 0>, /* DVS2 */
-                                                 <&gpx0 2 1 0 0>; /* DVS3 */
+                                                 <&gpx0 2 0>; /* DVS3 */
-                s5m8767,pmic-buck-ds-gpios = <&gpx2 3 1 0 0>, /* SET1 */
+                s5m8767,pmic-buck-ds-gpios = <&gpx2 3 0>, /* SET1 */
-                                                <&gpx2 4 1 0 0>, /* SET2 */
+                                                <&gpx2 4 0>, /* SET2 */
-                                                <&gpx2 5 1 0 0>; /* SET3 */
+                                                <&gpx2 5 0>; /* SET3 */
                s5m8767,pmic-buck2-dvs-voltage = <1350000>, <1300000>,
                                                 <1250000>, <1200000>,
diff --git a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
new file mode 100644
index 000000000000..2e57a33e9029
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
@@ -0,0 +1,128 @@
+Adaptive Body Bias(ABB) SoC internal LDO regulator for Texas Instruments SoCs
+Required Properties:
+- compatible: Should be one of:
+  - "ti,abb-v1" for older SoCs like OMAP3
+  - "ti,abb-v2" for newer SoCs like OMAP4, OMAP5
+- reg: Address and length of the register set for the device. It contains
+  the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+  - "base-address"      - contains base address of ABB module
+  - "int-address"       - contains address of interrupt register for ABB module
+  (also see Optional properties)
+- #address-cell: should be 0
+- #size-cell: should be 0
+- clocks: should point to the clock node used by ABB module
+- ti,settling-time: Settling time in uSecs from SoC documentation for ABB module
+        to settle down(target time for SR2_WTCNT_VALUE).
+- ti,clock-cycles: SoC specific data about count of system ti,clock-cycles used for
+        computing settling time from SoC Documentation for ABB module(clock
+        cycles for SR2_WTCNT_VALUE).
+- ti,tranxdone-status-mask: Mask to the int-register to write-to-clear mask
+        indicating LDO tranxdone (operation complete).
+- ti,abb_info: An array of 6-tuples u32 items providing information about ABB
+        configuration needed per operational voltage of the device.
+        Each item consists of the following in the same order:
+        volt: voltage in uV - Only used to index ABB information.
+        ABB mode: one of the following:
+                0-bypass
+                1-Forward Body Bias(FBB)
+                3-Reverse Body Bias(RBB)
+        efuse:  (see Optional properties)
+        RBB enable efuse Mask:  (See Optional properties)
+        FBB enable efuse Mask:  (See Optional properties)
+        Vset value efuse Mask:  (See Optional properties)
+        NOTE: If more than 1 entry is present, then regulator is setup to change
+              voltage, allowing for various modes to be selected indexed off
+              the regulator. Further, ABB LDOs are considered always-on by
+              default.
+Optional Properties:
+- reg-names: In addition to the required properties, the following are optional
+  - "efuse-address"     - Contains efuse base address used to pick up ABB info.
+  - "ldo-address"       - Contains address of ABB LDO overide register address.
+        "efuse-address" is required for this.
+- ti,ldovbb-vset-mask   - Required if ldo-address is set, mask for LDO override
+        register to provide override vset value.
+- ti,ldovbb-override-mask - Required if ldo-address is set, mask for LDO
+        override register to enable override vset value.
+- ti,abb_opp_sel: Addendum to the description in required properties
+        efuse: Mandatory if 'efuse-address' register is defined. Provides offset
+               from efuse-address to pick up ABB characteristics. Set to 0 if
+               'efuse-address' is not defined.
+        RBB enable efuse Mask:  Optional if 'efuse-address' register is defined.
+                'ABB mode' is force set to RBB mode if value at "efuse-address"
+                + efuse maps to RBB mask. Set to 0 to ignore this.
+        FBB enable efuse Mask:  Optional if 'efuse-address' register is defined.
+                'ABB mode' is force set to FBB mode if value at "efuse-address"
+                + efuse maps to FBB mask (valid only if RBB mask does not match)
+                Set to 0 to ignore this.
+        Vset value efuse Mask:  Mandatory if ldo-address is set. Picks up from
+                efuse the value to set in 'ti,ldovbb-vset-mask' at ldo-address.
+Example #1: Simplest configuration (no efuse data, hard coded ABB table):
+abb_x: regulator-abb-x {
+        compatible = "ti,abb-v1";
+        regulator-name = "abb_x";
+        #address-cell = <0>;
+        #size-cells = <0>;
+        reg = <0x483072f0 0x8>, <0x48306818 0x4>;
+        reg-names = "base-address", "int-address";
+        ti,tranxdone-status-mask = <0x4000000>;
+        clocks = <&sysclk>;
+        ti,settling-time = <30>;
+        ti,clock-cycles = <8>;
+        ti,abb_info = <
+        /* uV           ABB     efuse   rbb_m   fbb_m   vset_m */
+        1012500         0       0       0       0       0 /* Bypass */
+        1200000         3       0       0       0       0 /* RBB mandatory */
+        1320000         1       0       0       0       0 /* FBB mandatory */
+        >;
+};
+Example #2: Efuse bits contain ABB mode setting (no LDO override capability)
+abb_y: regulator-abb-y {
+        compatible = "ti,abb-v2";
+        regulator-name = "abb_y";
+        #address-cell = <0>;
+        #size-cells = <0>;
+        reg = <0x4a307bd0 0x8>, <0x4a306014 0x4>, <0x4A002268 0x8>;
+        reg-names = "base-address", "int-address", "efuse-address";
+        ti,tranxdone-status-mask = <0x4000000>;
+        clocks = <&sysclk>;
+        ti,settling-time = <50>;
+        ti,clock-cycles = <16>;
+        ti,abb_info = <
+        /* uV           ABB     efuse   rbb_m   fbb_m   vset_m */
+        975000          0       0       0       0       0 /* Bypass */
+        1012500         0       0       0x40000 0       0 /* RBB optional */
+        1200000         0       0x4     0       0x40000 0 /* FBB optional */
+        1320000         1       0       0       0       0 /* FBB mandatory */
+        >;
+};
+Example #3: Efuse bits contain ABB mode setting and LDO override capability
+abb_z: regulator-abb-z {
+        compatible = "ti,abb-v2";
+        regulator-name = "abb_z";
+        #address-cell = <0>;
+        #size-cells = <0>;
+        reg = <0x4ae07ce4 0x8>, <0x4ae06010 0x4>,
+              <0x4a002194 0x8>, <0x4ae0C314 0x4>;
+        reg-names = "base-address", "int-address",
+                    "efuse-address", "ldo-address";
+        ti,tranxdone-status-mask = <0x8000000>;
+        /* LDOVBBMM_MUX_CTRL */
+        ti,ldovbb-override-mask = <0x400>;
+        /* LDOVBBMM_VSET_OUT */
+        ti,ldovbb-vset-mask = <0x1F>;
+        clocks = <&sysclk>;
+        ti,settling-time = <50>;
+        ti,clock-cycles = <16>;
+        ti,abb_info = <
+        /* uV   ABB     efuse   rbb_m   fbb_m   vset_m */
+        975000  0       0       0       0       0       /* Bypass */
+        1200000 0       0x4     0       0x40000 0x1f00  /* FBB optional, vset */
+        >;
+};
diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
index 658749b90b97..75b0c1669504 100644
--- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt
@@ -18,20 +18,20 @@ For twl6030 regulators/LDOs
  - "ti,twl6030-vdd1" for VDD1 SMPS
  - "ti,twl6030-vdd2" for VDD2 SMPS
  - "ti,twl6030-vdd3" for VDD3 SMPS
-For twl6025 regulators/LDOs
+For twl6032 regulators/LDOs
 - compatible:
-  - "ti,twl6025-ldo1" for LDO1 LDO
+  - "ti,twl6032-ldo1" for LDO1 LDO
-  - "ti,twl6025-ldo2" for LDO2 LDO
+  - "ti,twl6032-ldo2" for LDO2 LDO
-  - "ti,twl6025-ldo3" for LDO3 LDO
+  - "ti,twl6032-ldo3" for LDO3 LDO
-  - "ti,twl6025-ldo4" for LDO4 LDO
+  - "ti,twl6032-ldo4" for LDO4 LDO
-  - "ti,twl6025-ldo5" for LDO5 LDO
+  - "ti,twl6032-ldo5" for LDO5 LDO
-  - "ti,twl6025-ldo6" for LDO6 LDO
+  - "ti,twl6032-ldo6" for LDO6 LDO
-  - "ti,twl6025-ldo7" for LDO7 LDO
+  - "ti,twl6032-ldo7" for LDO7 LDO
-  - "ti,twl6025-ldoln" for LDOLN LDO
+  - "ti,twl6032-ldoln" for LDOLN LDO
-  - "ti,twl6025-ldousb" for LDOUSB LDO
+  - "ti,twl6032-ldousb" for LDOUSB LDO
-  - "ti,twl6025-smps3" for SMPS3 SMPS
+  - "ti,twl6032-smps3" for SMPS3 SMPS
-  - "ti,twl6025-smps4" for SMPS4 SMPS
+  - "ti,twl6032-smps4" for SMPS4 SMPS
-  - "ti,twl6025-vio" for VIO SMPS
+  - "ti,twl6032-vio" for VIO SMPS
 For twl4030 regulators/LDOs
 - compatible:
  - "ti,twl4030-vaux1" for VAUX1 LDO
diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
index 2a3feabd3b22..34c1505774bf 100644
--- a/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
@@ -1,7 +1,7 @@
 Atmel AT91RM9200 Real Time Clock
 Required properties:
- compatible: should be: "atmel,at91rm9200-rtc"
+- compatible: should be: "atmel,at91rm9200-rtc" or "atmel,at91sam9x5-rtc"
 - reg: physical base address of the controller and length of memory mapped
  region.
 - interrupts: rtc alarm/event interrupt
diff --git a/Documentation/devicetree/bindings/rtc/dw-apb.txt b/Documentation/devicetree/bindings/rtc/dw-apb.txt
index 93e2b0f048e6..eb2327b2bdb3 100644
--- a/Documentation/devicetree/bindings/rtc/dw-apb.txt
+++ b/Documentation/devicetree/bindings/rtc/dw-apb.txt
@@ -5,9 +5,20 @@ Required properties:
 - reg: physical base address of the controller and length of memory mapped
  region.
 - interrupts: IRQ line for the timer.
+- either clocks+clock-names or clock-frequency properties
+Optional properties:
+- clocks        : list of clock specifiers, corresponding to entries in
+                  the clock-names property;
+- clock-names   : should contain "timer" and "pclk" entries, matching entries
+                  in the clocks property.
 - clock-frequency: The frequency in HZ of the timer.
 - clock-freq: For backwards compatibility with picoxcell
+If using the clock specifiers, the pclk clock is optional, as not all
+systems may use one.
 Example:
                timer1: timer@ffc09000 {
@@ -23,3 +34,11 @@ Example:
                                clock-frequency = <200000000>;
                                reg = <0xffd00000 0x1000>;
                        };
+                timer3: timer@ffe00000 {
+                                compatible = "snps,dw-apb-timer-osc";
+                                interrupts = <0 170 4>;
+                                reg = <0xffe00000 0x1000>;
+                                clocks = <&timer_clk>, <&timer_pclk>;
+                                clock-names = "timer", "pclk";
+                        };
diff --git a/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
new file mode 100644
index 000000000000..0e72183f52bc
--- /dev/null
+++ b/Documentation/devicetree/bindings/serio/olpc,ap-sp.txt
@@ -0,0 +1,13 @@
+OLPC AP-SP serio interface
+Required properties:
+- compatible : "olpc,ap-sp"
+- reg : base address and length of SoC's WTM registers
+- interrupts : SP-AP interrupt
+Example:
+        ap-sp@d4290000 {
+                compatible = "olpc,ap-sp";
+                reg = <0xd4290000 0x1000>;
+                interrupts = <40>;
+        }
diff --git a/Documentation/devicetree/bindings/sound/adi,adau1701.txt b/Documentation/devicetree/bindings/sound/adi,adau1701.txt
new file mode 100644
index 000000000000..547a49b56a62
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/adi,adau1701.txt
@@ -0,0 +1,35 @@
+Analog Devices ADAU1701
+Required properties:
+ - compatible:          Should contain "adi,adau1701"
+ - reg:                 The i2c address. Value depends on the state of ADDR0
+                        and ADDR1, as wired in hardware.
+Optional properties:
+ - reset-gpio:          A GPIO spec to define which pin is connected to the
+                        chip's !RESET pin. If specified, the driver will
+                        assert a hardware reset at probe time.
+ - adi,pll-mode-gpios:  An array of two GPIO specs to describe the GPIOs
+                        the ADAU's PLL config pins are connected to.
+                        The state of the pins are set according to the
+                        configured clock divider on ASoC side before the
+                        firmware is loaded.
+ - adi,pin-config:      An array of 12 numerical values selecting one of the
+                        pin configurations as described in the datasheet,
+                        table 53. Note that the value of this property has
+                        to be prefixed with '/bits/ 8'.
+Examples:
+        i2c_bus {
+                adau1701@34 {
+                        compatible = "adi,adau1701";
+                        reg = <0x34>;
+                        reset-gpio = <&gpio 23 0>;
+                        adi,pll-mode-gpios = <&gpio 24 0 &gpio 25 0>;
+                        adi,pin-config = /bits/ 8 <0x4 0x7 0x5 0x5 0x4 0x4
+                                                   0x4 0x4 0x4 0x4 0x4 0x4>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt
new file mode 100644
index 000000000000..f49450a87890
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/imx-audio-wm8962.txt
@@ -0,0 +1,46 @@
+Freescale i.MX audio complex with WM8962 codec
+Required properties:
+- compatible : "fsl,imx-audio-wm8962"
+- model : The user-visible name of this sound complex
+- ssi-controller : The phandle of the i.MX SSI controller
+- audio-codec : The phandle of the WM8962 audio codec
+- 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 could be power
+  supplies, WM8962 pins, and the jacks on the board:
+  Power supplies:
+   * Mic Bias
+  Board connectors:
+   * Mic Jack
+   * Headphone Jack
+   * Ext Spk
+- mux-int-port : The internal port of the i.MX audio muxer (AUDMUX)
+- mux-ext-port : The external port of the i.MX audio muxer
+Note: The AUDMUX port numbering should start at 1, which is consistent with
+hardware manual.
+Example:
+sound {
+        compatible = "fsl,imx6q-sabresd-wm8962",
+                     "fsl,imx-audio-wm8962";
+        model = "wm8962-audio";
+        ssi-controller = <&ssi2>;
+        audio-codec = <&codec>;
+                audio-routing =
+                "Headphone Jack", "HPOUTL",
+                "Headphone Jack", "HPOUTR",
+                "Ext Spk", "SPKOUTL",
+                "Ext Spk", "SPKOUTR",
+                "MICBIAS", "AMIC",
+                "IN3R", "MICBIAS",
+                "DMIC", "MICBIAS",
+                "DMICDAT", "DMIC";
+        mux-int-port = <2>;
+        mux-ext-port = <3>;
+};
diff --git a/Documentation/devicetree/bindings/sound/mxs-saif.txt b/Documentation/devicetree/bindings/sound/mxs-saif.txt
index c37ba6143d9b..7ba07a118e37 100644
--- a/Documentation/devicetree/bindings/sound/mxs-saif.txt
+++ b/Documentation/devicetree/bindings/sound/mxs-saif.txt
@@ -3,8 +3,11 @@
 Required properties:
 - compatible: Should be "fsl,<chip>-saif"
 - reg: Should contain registers location and length
- interrupts: Should contain ERROR and DMA interrupts
+- interrupts: Should contain ERROR interrupt number
- fsl,saif-dma-channel: APBX DMA channel for the SAIF
+- dmas: DMA specifier, consisting of a phandle to DMA controller node
+  and SAIF DMA channel ID.
+  Refer to dma.txt and fsl-mxs-dma.txt for details.
+- dma-names: Must be "rx-tx".
 Optional properties:
 - fsl,saif-master: phandle to the master SAIF.  It's only required for
@@ -23,14 +26,16 @@ aliases {
 saif0: saif@80042000 {
        compatible = "fsl,imx28-saif";
        reg = <0x80042000 2000>;
-        interrupts = <59 80>;
+        interrupts = <59>;
-        fsl,saif-dma-channel = <4>;
+        dmas = <&dma_apbx 4>;
+        dma-names = "rx-tx";
 };
 saif1: saif@80046000 {
        compatible = "fsl,imx28-saif";
        reg = <0x80046000 2000>;
-        interrupts = <58 81>;
+        interrupts = <58>;
-        fsl,saif-dma-channel = <5>;
+        dmas = <&dma_apbx 5>;
+        dma-names = "rx-tx";
        fsl,saif-master = <&saif0>;
 };
diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
new file mode 100644
index 000000000000..d130818700b2
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-rt5640.txt
@@ -0,0 +1,71 @@
+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.
+- clock-names : Must include the following entries:
+  "pll_a" (The Tegra clock of that name),
+  "pll_a_out0" (The Tegra clock of that name),
+  "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 RT5640's pins, and the jacks on the board:
+  RT5640 pins:
+  * DMIC1
+  * DMIC2
+  * MICBIAS1
+  * IN1P
+  * IN1R
+  * IN2P
+  * IN2R
+  * HPOL
+  * HPOR
+  * LOUTL
+  * LOUTR
+  * MONOP
+  * MONON
+  * SPOLP
+  * SPOLN
+  * SPORP
+  * SPORN
+  Board connectors:
+  * Headphones
+  * Speakers
+- nvidia,i2s-controller : The phandle of the Tegra I2S controller that's
+  connected to the CODEC.
+- nvidia,audio-codec : The phandle of the RT5640 audio codec. This binding
+  assumes that AIF1 on the CODEC is connected to Tegra.
+Optional properties:
+- nvidia,hp-det-gpios : The GPIO that detects headphones are plugged in
+Example:
+sound {
+        compatible = "nvidia,tegra-audio-rt5640-dalmore",
+                        "nvidia,tegra-audio-rt5640";
+        nvidia,model = "NVIDIA Tegra Dalmore";
+        nvidia,audio-routing =
+                "Headphones", "HPOR",
+                "Headphones", "HPOL",
+                "Speakers", "SPORP",
+                "Speakers", "SPORN",
+                "Speakers", "SPOLP",
+                "Speakers", "SPOLN";
+        nvidia,i2s-controller = <&tegra_i2s1>;
+        nvidia,audio-codec = <&rt5640>;
+        nvidia,hp-det-gpios = <&gpio 143 0>; /* GPIO PR7 */
+        clocks = <&tegra_car 216>, <&tegra_car 217>, <&tegra_car 120>;
+        clock-names = "pll_a", "pll_a_out0", "mclk";
+};
diff --git a/Documentation/devicetree/bindings/sound/rt5640.txt b/Documentation/devicetree/bindings/sound/rt5640.txt
new file mode 100644
index 000000000000..005bcb24d72d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/rt5640.txt
@@ -0,0 +1,30 @@
+RT5640 audio CODEC
+This device supports I2C only.
+Required properties:
+- compatible : "realtek,rt5640".
+- reg : The I2C address of the device.
+- interrupts : The CODEC's interrupt output.
+Optional properties:
+- realtek,in1-differential
+- realtek,in2-differential
+  Boolean. Indicate MIC1/2 input are differential, rather than single-ended.
+- realtek,ldo1-en-gpios : The GPIO that controls the CODEC's LDO1_EN pin.
+Example:
+rt5640 {
+        compatible = "realtek,rt5640";
+        reg = <0x1c>;
+        interrupt-parent = <&gpio>;
+        interrupts = <TEGRA_GPIO(W, 3) GPIO_ACTIVE_HIGH>;
+        realtek,ldo1-en-gpios =
+                <&gpio TEGRA_GPIO(V, 3) GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/sound/samsung-i2s.txt b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
index 3070046da2e5..025e66b85a43 100644
--- a/Documentation/devicetree/bindings/sound/samsung-i2s.txt
+++ b/Documentation/devicetree/bindings/sound/samsung-i2s.txt
@@ -8,6 +8,16 @@ Required SoC Specific Properties:
 - 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.
+- clocks: Handle to iis clock and RCLK source clk.
+- clock-names:
+  i2s0 uses some base clks from CMU and some are from audio subsystem internal
+  clock controller. The clock names for i2s0 should be "iis", "i2s_opclk0" and
+  "i2s_opclk1" as shown in the example below.
+  i2s1 and i2s2 uses clocks from CMU. The clock names for i2s1 and i2s2 should
+  be "iis" and "i2s_opclk0".
+  "iis" is the i2s bus clock and i2s_opclk0, i2s_opclk1 are sources of the root
+  clk. i2s0 has internal mux to select the source of root clk and i2s1 and i2s2
+  doesn't have any such mux.
 Optional SoC Specific Properties:
@@ -20,44 +30,26 @@ Optional SoC Specific Properties:
  then this flag is enabled.
 - samsung,idma-addr: Internal DMA register base address of the audio
  sub system(used in secondary sound source).
+- pinctrl-0: Should specify pin control groups used for this controller.
-Required Board Specific Properties:
+- pinctrl-names: Should contain only one value - "default".
- gpios: The gpio specifier for data out,data in, LRCLK, CDCLK and SCLK
-  interface lines. The format of the gpio specifier depends on the gpio
-  controller.
-  The syntax of samsung gpio specifier is
-        <[phandle of the gpio controller node]
-         [pin number within the gpio controller]
-         [mux function]
-         [flags and pull up/down]
-         [drive strength]>
 Example:
- SoC Specific Portion:
+i2s0: i2s@03830000 {
-i2s@03830000 {
        compatible = "samsung,i2s-v5";
        reg = <0x03830000 0x100>;
        dmas = <&pdma0 10
                &pdma0 9
                &pdma0 8>;
        dma-names = "tx", "rx", "tx-sec";
+        clocks = <&clock_audss EXYNOS_I2S_BUS>,
+                <&clock_audss EXYNOS_I2S_BUS>,
+                <&clock_audss EXYNOS_SCLK_I2S>;
+        clock-names = "iis", "i2s_opclk0", "i2s_opclk1";
        samsung,supports-6ch;
        samsung,supports-rstclr;
        samsung,supports-secdai;
        samsung,idma-addr = <0x03000000>;
-};
+        pinctrl-names = "default";
+        pinctrl-0 = <&i2s0_bus>;
- Board Specific Portion:
-i2s@03830000 {
-        gpios = <&gpz 0 2 0 0>, /* I2S_0_SCLK */
-                <&gpz 1 2 0 0>, /* I2S_0_CDCLK */
-                <&gpz 2 2 0 0>, /* I2S_0_LRCK */
-                <&gpz 3 2 0 0>, /* I2S_0_SDI */
-                <&gpz 4 2 0 0>, /* I2S_0_SDO[1] */
-                <&gpz 5 2 0 0>, /* I2S_0_SDO[2] */
-                <&gpz 6 2 0 0>; /* I2S_0_SDO[3] */
 };
diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt
index 9cc44449508d..955df60a118c 100644
--- a/Documentation/devicetree/bindings/sound/sgtl5000.txt
+++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt
@@ -5,9 +5,12 @@ Required properties:
 - reg : the I2C address of the device
+- clocks : the clock provider of SYS_MCLK
 Example:
 codec: sgtl5000@0a {
        compatible = "fsl,sgtl5000";
        reg = <0x0a>;
+        clocks = <&clks 150>;
 };
diff --git a/Documentation/devicetree/bindings/sound/spdif-receiver.txt b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
new file mode 100644
index 000000000000..80f807bf8a1d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spdif-receiver.txt
@@ -0,0 +1,10 @@
+Device-Tree bindings for dummy spdif receiver
+Required properties:
+        - compatible: should be "linux,spdif-dir".
+Example node:
+        codec: spdif-receiver {
+                compatible = "linux,spdif-dir";
+        };
diff --git a/Documentation/devicetree/bindings/sound/spdif-transmitter.txt b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
new file mode 100644
index 000000000000..55a85841dd85
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/spdif-transmitter.txt
@@ -0,0 +1,10 @@
+Device-Tree bindings for dummy spdif transmitter
+Required properties:
+        - compatible: should be "linux,spdif-dit".
+Example node:
+        codec: spdif-transmitter {
+                compatible = "linux,spdif-dit";
+        };
diff --git a/Documentation/devicetree/bindings/sound/ssm2518.txt b/Documentation/devicetree/bindings/sound/ssm2518.txt
new file mode 100644
index 000000000000..59381a778c79
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ssm2518.txt
@@ -0,0 +1,20 @@
+SSM2518 audio amplifier
+This device supports I2C only.
+Required properties:
+  - compatible : Must be "adi,ssm2518"
+  - reg : the I2C address of the device. This will either be 0x34 (ADDR pin low)
+        or 0x35 (ADDR pin high)
+Optional properties:
+  - gpios : GPIO connected to the nSD pin. If the property is not present it is
+                assumed that the nSD pin is hardwired to always on.
+Example:
+        ssm2518: ssm2518@34 {
+                compatible = "adi,ssm2518";
+                reg = <0x34>;
+                gpios = <&gpio 5 0>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/ti,tas5086.txt b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
index 8ea4f5b4818d..d2866a0d6a26 100644
--- a/Documentation/devicetree/bindings/sound/ti,tas5086.txt
+++ b/Documentation/devicetree/bindings/sound/ti,tas5086.txt
@@ -20,6 +20,17 @@ Optional properties:
                        When not specified, the hardware default of 1300ms
                        is retained.
+ - ti,mid-z-channel-X:  Boolean properties, X being a number from 1 to 6.
+                        If given, channel X will start with the Mid-Z start
+                        sequence, otherwise the default Low-Z scheme is used.
+                        The correct configuration depends on how the power
+                        stages connected to the PWM output pins work. Not all
+                        power stages are compatible to Mid-Z - please refer
+                        to the datasheets for more details.
+                        Most systems should not set any of these properties.
 Examples:
        i2c_bus {
diff --git a/Documentation/devicetree/bindings/sound/wm8962.txt b/Documentation/devicetree/bindings/sound/wm8962.txt
index dceb3b1c2bb7..7f82b59ec8f9 100644
--- a/Documentation/devicetree/bindings/sound/wm8962.txt
+++ b/Documentation/devicetree/bindings/sound/wm8962.txt
@@ -8,9 +8,32 @@ Required properties:
  - reg : the I2C address of the device.
+Optional properties:
+  - spk-mono: This is a boolean property. If present, the SPK_MONO bit
+    of R51 (Class D Control 2) gets set, indicating that the speaker is
+    in mono mode.
+  - mic-cfg : Default register value for R48 (Additional Control 4).
+    If absent, the default should be the register default.
+  - gpio-cfg : A list of GPIO configuration register values. The list must
+    be 6 entries long. If absent, no configuration of these registers is
+    performed. And note that only the value within [0x0, 0xffff] is valid.
+    Any other value is regarded as setting the GPIO register by its reset
+    value 0x0.
 Example:
 codec: wm8962@1a {
        compatible = "wlf,wm8962";
        reg = <0x1a>;
+        gpio-cfg = <
+                0x0000 /* 0:Default */
+                0x0000 /* 1:Default */
+                0x0013 /* 2:FN_DMICCLK */
+                0x0000 /* 3:Default */
+                0x8014 /* 4:FN_DMICCDAT */
+                0x0000 /* 5:Default */
+        >;
 };
diff --git a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
index 8bf89c643640..f11f295c8450 100644
--- a/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
+++ b/Documentation/devicetree/bindings/spi/brcm,bcm2835-spi.txt
@@ -2,7 +2,7 @@ Broadcom BCM2835 SPI0 controller
 The BCM2835 contains two forms of SPI master controller, one known simply as
 SPI0, and the other known as the "Universal SPI Master"; part of the
-auxilliary block. This binding applies to the SPI0 controller.
+auxiliary block. This binding applies to the SPI0 controller.
 Required properties:
 - compatible: Should be "brcm,bcm2835-spi".
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 938809c6829b..4c85c4c69584 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -10,7 +10,18 @@ Required properties:
                          input. The default is D0 as input and
                          D1 as output.
-Example:
+Optional properties:
+- dmas: List of DMA specifiers with the controller specific format
+        as described in the generic DMA client binding. A tx and rx
+        specifier is required for each chip select.
+- dma-names: List of DMA request names. These strings correspond
+        1:1 with the DMA specifiers listed in dmas. The string naming
+        is to be "rxN" and "txN" for RX and TX requests,
+        respectively, where N equals the chip select number.
+Examples:
+[hwmod populated DMA resources]
 mcspi1: mcspi@1 {
    #address-cells = <1>;
@@ -20,3 +31,17 @@ mcspi1: mcspi@1 {
    ti,spi-num-cs = <4>;
 };
+[generic DMA request binding]
+mcspi1: mcspi@1 {
+    #address-cells = <1>;
+    #size-cells = <0>;
+    compatible = "ti,omap4-mcspi";
+    ti,hwmods = "mcspi1";
+    ti,spi-num-cs = <2>;
+    dmas = <&edma 42
+            &edma 43
+            &edma 44
+            &edma 45>;
+    dma-names = "tx0", "rx0", "tx1", "rx1";
+};
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
new file mode 100644
index 000000000000..ed9377811ee2
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
@@ -0,0 +1,99 @@
+Device-Tree bindings for LVDS Display Bridge (ldb)
+LVDS Display Bridge
+===================
+The LVDS Display Bridge device tree node contains up to two lvds-channel
+nodes describing each of the two LVDS encoder channels of the bridge.
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be "fsl,imx53-ldb" or "fsl,imx6q-ldb".
+                Both LDB versions are similar, but i.MX6 has an additional
+                multiplexer in the front to select any of the four IPU display
+                interfaces as input for each LVDS channel.
+ - gpr : should be <&gpr> on i.MX53 and i.MX6q.
+         The phandle points to the iomuxc-gpr region containing the LVDS
+         control register.
+- clocks, clock-names : phandles to the LDB divider and selector clocks and to
+                        the display interface selector clocks, as described in
+                        Documentation/devicetree/bindings/clock/clock-bindings.txt
+        The following clocks are expected on i.MX53:
+                "di0_pll" - LDB LVDS channel 0 mux
+                "di1_pll" - LDB LVDS channel 1 mux
+                "di0" - LDB LVDS channel 0 gate
+                "di1" - LDB LVDS channel 1 gate
+                "di0_sel" - IPU1 DI0 mux
+                "di1_sel" - IPU1 DI1 mux
+        On i.MX6q the following additional clocks are needed:
+                "di2_sel" - IPU2 DI0 mux
+                "di3_sel" - IPU2 DI1 mux
+        The needed clock numbers for each are documented in
+        Documentation/devicetree/bindings/clock/imx5-clock.txt, and in
+        Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+Optional properties:
+ - pinctrl-names : should be "default" on i.MX53, not used on i.MX6q
+ - pinctrl-0 : a phandle pointing to LVDS pin settings on i.MX53,
+               not used on i.MX6q
+ - fsl,dual-channel : boolean. if it exists, only LVDS channel 0 should
+   be configured - one input will be distributed on both outputs in dual
+   channel mode
+LVDS Channel
+============
+Each LVDS Channel has to contain a display-timings node that describes the
+video timings for the connected LVDS display. For detailed information, also
+have a look at Documentation/devicetree/bindings/video/display-timing.txt.
+Required properties:
+ - reg : should be <0> or <1>
+ - crtcs : a list of phandles with index pointing to the IPU display interfaces
+           that can be used as video source for this channel.
+ - fsl,data-mapping : should be "spwg" or "jeida"
+                      This describes how the color bits are laid out in the
+                      serialized LVDS signal.
+ - fsl,data-width : should be <18> or <24>
+example:
+gpr: iomuxc-gpr@53fa8000 {
+        /* ... */
+};
+ldb: ldb@53fa8008 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        compatible = "fsl,imx53-ldb";
+        gpr = <&gpr>;
+        clocks = <&clks 122>, <&clks 120>,
+                 <&clks 115>, <&clks 116>,
+                 <&clks 123>, <&clks 85>;
+        clock-names = "di0_pll", "di1_pll",
+                      "di0_sel", "di1_sel",
+                      "di0", "di1";
+        lvds-channel@0 {
+                reg = <0>;
+                crtcs = <&ipu 0>;
+                fsl,data-mapping = "spwg";
+                fsl,data-width = <24>;
+                display-timings {
+                        /* ... */
+                };
+        };
+        lvds-channel@1 {
+                reg = <1>;
+                crtcs = <&ipu 1>;
+                fsl,data-mapping = "spwg";
+                fsl,data-width = <24>;
+                display-timings {
+                        /* ... */
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
new file mode 100644
index 000000000000..0c9222d27fae
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/ti_soc_thermal.txt
@@ -0,0 +1,74 @@
+* Texas Instrument OMAP SCM bandgap bindings
+In the System Control Module, OMAP supplies a voltage reference
+and a temperature sensor feature that are gathered in the band
+gap voltage and temperature sensor (VBGAPTS) module. The band
+gap provides current and voltage reference for its internal
+circuits and other analog IP blocks. The analog-to-digital
+converter (ADC) produces an output value that is proportional
+to the silicon temperature.
+Required properties:
+- compatible : Should be:
+  - "ti,omap4430-bandgap" : for OMAP4430 bandgap
+  - "ti,omap4460-bandgap" : for OMAP4460 bandgap
+  - "ti,omap4470-bandgap" : for OMAP4470 bandgap
+  - "ti,omap5430-bandgap" : for OMAP5430 bandgap
+- interrupts : this entry should indicate which interrupt line
+the talert signal is routed to;
+Specific:
+- gpios : this entry should be used to inform which GPIO
+line the tshut signal is routed to. The informed GPIO will
+be treated as an IRQ;
+- regs : this entry must also be specified and it is specific
+to each bandgap version, because the mapping may change from
+soc to soc, apart of depending on available features.
+Example:
+OMAP4430:
+bandgap {
+        reg = <0x4a002260 0x4 0x4a00232C 0x4>;
+        compatible = "ti,omap4430-bandgap";
+};
+OMAP4460:
+bandgap {
+        reg = <0x4a002260 0x4
+                0x4a00232C 0x4
+                0x4a002378 0x18>;
+        compatible = "ti,omap4460-bandgap";
+        interrupts = <0 126 4>; /* talert */
+        gpios = <&gpio3 22 0>; /* tshut */
+};
+OMAP4470:
+bandgap {
+        reg = <0x4a002260 0x4
+                0x4a00232C 0x4
+                0x4a002378 0x18>;
+        compatible = "ti,omap4470-bandgap";
+        interrupts = <0 126 4>; /* talert */
+        gpios = <&gpio3 22 0>; /* tshut */
+};
+OMAP5430:
+bandgap {
+        reg = <0x4a0021e0 0xc
+                0x4a00232c 0xc
+                0x4a002380 0x2c
+                0x4a0023C0 0x3c>;
+        compatible = "ti,omap5430-bandgap";
+        interrupts = <0 126 4>; /* talert */
+};
+DRA752:
+bandgap {
+        reg = <0x4a0021e0 0xc
+                0x4a00232c 0xc
+                0x4a002380 0x2c
+                0x4a0023C0 0x3c
+                0x4a002564 0x8
+                0x4a002574 0x50>;
+        compatible = "ti,dra752-bandgap";
+        interrupts = <0 126 4>; /* talert */
+};
diff --git a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
index cb47bfbcaeea..b5a86d20ee36 100644
--- a/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
+++ b/Documentation/devicetree/bindings/timer/samsung,exynos4210-mct.txt
@@ -44,7 +44,7 @@ Example 1: In this example, the system uses only the first global timer
        };
 Example 2: In this example, the MCT global and local timer interrupts are
-           connected to two seperate interrupt controllers. Hence, an
+           connected to two separate interrupt controllers. Hence, an
           interrupt-map is created to map the interrupts to the respective
           interrupt controllers.
diff --git a/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
new file mode 100644
index 000000000000..9499bc8ee9e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/stericsson-u300-apptimer.txt
@@ -0,0 +1,18 @@
+ST-Ericsson U300 apptimer
+Required properties:
+- compatible : should be "stericsson,u300-apptimer"
+- reg : Specifies base physical address and size of the registers.
+- interrupts : A list of 4 interrupts; one for each subtimer. These
+  are, in order: OS (operating system), DD (device driver) both
+  adopted for EPOC/Symbian with two specific IRQs for these tasks,
+  then GP1 and GP2, which are general-purpose timers.
+Example:
+timer {
+        compatible = "stericsson,u300-apptimer";
+        reg = <0xc0014000 0x1000>;
+        interrupts = <24 25 26 27>;
+};
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
index b462d0c54823..c662eb36be29 100644
--- a/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-imx-uart.txt
@@ -8,6 +8,8 @@ Required properties:
 Optional properties:
 - fsl,uart-has-rtscts : Indicate the uart has rts and cts
 - fsl,irda-mode : Indicate the uart supports irda mode
+- fsl,dte-mode : Indicate the uart works in DTE mode. The uart works
+                  is DCE mode by default.
 Example:
@@ -16,4 +18,5 @@ serial@73fbc000 {
        reg = <0x73fbc000 0x4000>;
        interrupts = <31>;
        fsl,uart-has-rtscts;
+        fsl,dte-mode;
 };
diff --git a/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt
new file mode 100644
index 000000000000..6fd1dd1638dd
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/fsl-lpuart.txt
@@ -0,0 +1,14 @@
+* Freescale low power universal asynchronous receiver/transmitter (lpuart)
+Required properties:
+- compatible : Should be "fsl,<soc>-lpuart"
+- reg : Address and length of the register set for the device
+- interrupts : Should contain uart interrupt
+Example:
+uart0: serial@40027000 {
+               compatible = "fsl,vf610-lpuart";
+               reg = <0x40027000 0x1000>;
+               interrupts = <0 61 0x00>;
+       };
diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
new file mode 100644
index 000000000000..20468b2a7516
--- /dev/null
+++ b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt
@@ -0,0 +1,16 @@
+* Universal Flash Storage (UFS) Host Controller
+UFSHC nodes are defined to describe on-chip UFS host controllers.
+Each UFS controller instance should have its own node.
+Required properties:
+- compatible        : compatible list, contains "jedec,ufs-1.1"
+- interrupts        : <interrupt mapping for UFS host controller IRQ>
+- reg               : <registers mapping>
+Example:
+        ufshc@0xfc598000 {
+                compatible = "jedec,ufs-1.1";
+                reg = <0xfc598000 0x800>;
+                interrupts = <0 28 0>;
+        };
diff --git a/Documentation/devicetree/bindings/usb/am33xx-usb.txt b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
index ea840f7f9258..dc9dc8c87f15 100644
--- a/Documentation/devicetree/bindings/usb/am33xx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/am33xx-usb.txt
@@ -12,7 +12,7 @@ AM33XX MUSB GLUE
   represents PERIPHERAL.
 - port1-mode : Should be "1" to represent HOST. "3" signifies OTG and "2"
   represents PERIPHERAL.
- - power : Should be "250". This signifies the controller can supply upto
+ - power : Should be "250". This signifies the controller can supply up to
   500mA when operating in host mode.
 Example:
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 60bd2150a3e6..55f51af08bc7 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -47,3 +47,85 @@ usb1: gadget@fffa4000 {
        interrupts = <10 4>;
        atmel,vbus-gpio = <&pioC 5 0>;
 };
+Atmel High-Speed USB device controller
+Required properties:
+ - compatible: Should be "atmel,at91sam9rl-udc"
+ - reg: Address and length of the register set for the device
+ - interrupts: Should contain usba interrupt
+ - ep childnode: To specify the number of endpoints and their properties.
+Optional properties:
+ - atmel,vbus-gpio: If present, specifies a gpio that needs to be
+   activated for the bus to be powered.
+Required child node properties:
+ - name: Name of the endpoint.
+ - reg: Num of the endpoint.
+ - atmel,fifo-size: Size of the fifo.
+ - atmel,nb-banks: Number of banks.
+ - atmel,can-dma: Boolean to specify if the endpoint support DMA.
+ - atmel,can-isoc: Boolean to specify if the endpoint support ISOC.
+usb2: gadget@fff78000 {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        compatible = "atmel,at91sam9rl-udc";
+        reg = <0x00600000 0x80000
+               0xfff78000 0x400>;
+        interrupts = <27 4 0>;
+        atmel,vbus-gpio = <&pioB 19 0>;
+        ep0 {
+                reg = <0>;
+                atmel,fifo-size = <64>;
+                atmel,nb-banks = <1>;
+        };
+        ep1 {
+                reg = <1>;
+                atmel,fifo-size = <1024>;
+                atmel,nb-banks = <2>;
+                atmel,can-dma;
+                atmel,can-isoc;
+        };
+        ep2 {
+                reg = <2>;
+                atmel,fifo-size = <1024>;
+                atmel,nb-banks = <2>;
+                atmel,can-dma;
+                atmel,can-isoc;
+        };
+        ep3 {
+                reg = <3>;
+                atmel,fifo-size = <1024>;
+                atmel,nb-banks = <3>;
+                atmel,can-dma;
+        };
+        ep4 {
+                reg = <4>;
+                atmel,fifo-size = <1024>;
+                atmel,nb-banks = <3>;
+                atmel,can-dma;
+        };
+        ep5 {
+                reg = <5>;
+                atmel,fifo-size = <1024>;
+                atmel,nb-banks = <3>;
+                atmel,can-dma;
+                atmel,can-isoc;
+        };
+        ep6 {
+                reg = <6>;
+                atmel,fifo-size = <1024>;
+                atmel,nb-banks = <3>;
+                atmel,can-dma;
+                atmel,can-isoc;
+        };
+};
diff --git a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
index 1c04a4c9515f..b4b5b7906c88 100644
--- a/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci13xxx-imx.txt
@@ -5,6 +5,12 @@ Required properties:
 - reg: Should contain registers location and length
 - interrupts: Should contain controller interrupt
+Recommended properies:
+- phy_type: the type of the phy connected to the core. Should be one
+  of "utmi", "utmi_wide", "ulpi", "serial" or "hsic". Without this
+  property the PORTSC register won't be touched
+- dr_mode: One of "host", "peripheral" or "otg". Defaults to "otg"
 Optional properties:
 - fsl,usbphy: phandler of usb phy that connects to the only one port
 - fsl,usbmisc: phandler of non-core register device, with one argument
diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt
index b3abde736017..d967ba16de60 100644
--- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
+++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
@@ -48,3 +48,37 @@ Example:
                clocks = <&clock 285>;
                clock-names = "usbhost";
        };
+DWC3
+Required properties:
+ - compatible: should be "samsung,exynos5250-dwusb3" for USB 3.0 DWC3
+               controller.
+ - #address-cells, #size-cells : should be '1' if the device has sub-nodes
+                                 with 'reg' property.
+ - 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 Exynos dwc3 glue.
+- dwc3 :
+   The binding details of dwc3 can be found in:
+   Documentation/devicetree/bindings/usb/dwc3.txt
+Example:
+        usb@12000000 {
+                compatible = "samsung,exynos5250-dwusb3";
+                clocks = <&clock 286>;
+                clock-names = "usbdrd30";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+                dwc3 {
+                        compatible = "synopsys,dwc3";
+                        reg = <0x12000000 0x10000>;
+                        interrupts = <0 72 0>;
+                        usb-phy = <&usb2_phy &usb3_phy>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
index 34c952883276..df0933043a5b 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-ehci.txt
@@ -6,27 +6,10 @@ Practice : Universal Serial Bus" with the following modifications
 and additions :
 Required properties :
- - compatible : Should be "nvidia,tegra20-ehci" for USB controllers
+ - compatible : Should be "nvidia,tegra20-ehci".
-   used in host mode.
+ - nvidia,phy : phandle of the PHY that the controller is connected to.
- - phy_type : Should be one of "ulpi" or "utmi".
+ - clocks : Contains a single entry which defines the USB controller's clock.
- - nvidia,vbus-gpio : If present, specifies a gpio that needs to be
-   activated for the bus to be powered.
- - nvidia,phy : phandle of the PHY instance, the controller is connected to.
-Required properties for phy_type == ulpi:
-  - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
 Optional properties:
-  - dr_mode : dual role mode. Indicates the working mode for
+ - nvidia,needs-double-reset : boolean is to be set for some of the Tegra20
-   nvidia,tegra20-ehci compatible controllers.  Can be "host", "peripheral",
+   USB ports, which need reset twice due to hardware issues.
-   or "otg".  Default to "host" if not defined for backward compatibility.
-      host means this is a host controller
-      peripheral means it is device controller
-      otg means it can operate as either ("on the go")
-  - nvidia,has-legacy-mode : boolean indicates whether this controller can
-    operate in legacy mode (as APX 2500 / 2600). In legacy mode some
-    registers are accessed through the APB_MISC base address instead of
-    the USB controller. Since this is a legacy issue it probably does not
-    warrant a compatible string of its own.
-  - nvidia,needs-double-reset : boolean is to be set for some of the Tegra2
-    USB ports, which need reset twice due to hardware issues.
diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
index 6bdaba2f0aa1..c4c9e9e664aa 100644
--- a/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/nvidia,tegra20-usb-phy.txt
@@ -4,14 +4,49 @@ The device node for Tegra SOC USB PHY:
 Required properties :
 - compatible : Should be "nvidia,tegra20-usb-phy".
- - reg : Address and length of the register set for the USB PHY interface.
+ - reg : Defines the following set of registers, in the order listed:
- - phy_type : Should be one of "ulpi" or "utmi".
+   - The PHY's own register set.
+     Always present.
+   - The register set of the PHY containing the UTMI pad control registers.
+     Present if-and-only-if phy_type == utmi.
+ - phy_type : Should be one of "utmi", "ulpi" or "hsic".
+ - clocks : Defines the clocks listed in the clock-names property.
+ - clock-names : The following clock names must be present:
+   - reg: The clock needed to access the PHY's own registers. This is the
+     associated EHCI controller's clock. Always present.
+   - pll_u: PLL_U. Always present.
+   - timer: The timeout clock (clk_m). Present if phy_type == utmi.
+   - utmi-pads: The clock needed to access the UTMI pad control registers.
+     Present if phy_type == utmi.
+   - ulpi-link: The clock Tegra provides to the ULPI PHY (cdev2).
+     Present if phy_type == ulpi, and ULPI link mode is in use.
 Required properties for phy_type == ulpi:
  - nvidia,phy-reset-gpio : The GPIO used to reset the PHY.
+Required PHY timing params for utmi phy:
+  - nvidia,hssync-start-delay : Number of 480 Mhz clock cycles to wait before
+    start of sync launches RxActive
+  - nvidia,elastic-limit : Variable FIFO Depth of elastic input store
+  - nvidia,idle-wait-delay : Number of 480 Mhz clock cycles of idle to wait
+    before declare IDLE.
+  - nvidia,term-range-adj : Range adjusment on terminations
+  - nvidia,xcvr-setup : HS driver output control
+  - nvidia,xcvr-lsfslew : LS falling slew rate control.
+  - nvidia,xcvr-lsrslew :  LS rising slew rate control.
 Optional properties:
  - nvidia,has-legacy-mode : boolean indicates whether this controller can
    operate in legacy mode (as APX 2500 / 2600). In legacy mode some
    registers are accessed through the APB_MISC base address instead of
-    the USB controller.
-\ No newline at end of file
+    the USB controller.
+  - nvidia,is-wired : boolean. Indicates whether we can do certain kind of power
+    optimizations for the devices that are always connected. e.g. modem.
+  - dr_mode : dual role mode. Indicates the working mode for the PHY. Can be
+    "host", "peripheral", or "otg". Defaults to "host" if not defined.
+      host means this is a host controller
+      peripheral means it is device controller
+      otg means it can operate as either ("on the go")
+Required properties for dr_mode == otg:
+  - vbus-supply: regulator for VBUS
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index d4769f343d6c..57e71f6817d0 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -16,7 +16,7 @@ OMAP MUSB GLUE
   specifying ULPI and UTMI respectively.
 - mode : Should be "3" to represent OTG. "1" signifies HOST and "2"
   represents PERIPHERAL.
- - power : Should be "50". This signifies the controller can supply upto
+ - power : Should be "50". This signifies the controller can supply up to
   100mA when operating in host mode.
 - usb-phy : the phandle for the PHY device
diff --git a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
index 36b9aede3f40..0aee0ad3f035 100644
--- a/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
+++ b/Documentation/devicetree/bindings/usb/twlxxxx-usb.txt
@@ -8,7 +8,7 @@ TWL6030 USB COMPARATOR
   usb interrupt number that raises VBUS interrupts when the controller has to
   act as device
 - usb-supply : phandle to the regulator device tree node. It should be vusb
-   if it is twl6030 or ldousb if it is twl6025 subclass.
+   if it is twl6030 or ldousb if it is twl6032 subclass.
 twl6030-usb {
        compatible = "ti,twl6030-usb";
diff --git a/Documentation/devicetree/bindings/usb/usb3503.txt b/Documentation/devicetree/bindings/usb/usb3503.txt
index 6813a715fc7d..8c5be48b43c8 100644
--- a/Documentation/devicetree/bindings/usb/usb3503.txt
+++ b/Documentation/devicetree/bindings/usb/usb3503.txt
@@ -4,6 +4,10 @@ Required properties:
 - compatible: Should be "smsc,usb3503".
 - reg: Specifies the i2c slave address, it should be 0x08.
 - connect-gpios: Should specify GPIO for connect.
+- disabled-ports: Should specify the ports unused.
+        '1' or '2' or '3' are availe for this property to describe the port
+        number. 1~3 property values are possible to be desribed.
+        Do not describe this property if all ports have to be enabled.
 - intn-gpios: Should specify GPIO for interrupt.
 - reset-gpios: Should specify GPIO for reset.
 - initial-mode: Should specify initial mode.
@@ -14,6 +18,7 @@ Examples:
                compatible = "smsc,usb3503";
                reg = <0x08>;
                connect-gpios = <&gpx3 0 1>;
+                disabled-ports = <2 3>;
                intn-gpios = <&gpx3 4 1>;
                reset-gpios = <&gpx3 5 1>;
                initial-mode = <1>;
diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt
new file mode 100644
index 000000000000..330d6ec15401
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt
@@ -0,0 +1,50 @@
+Ux500 MUSB
+Required properties:
+ - compatible : Should be "stericsson,db8500-musb"
+ - reg        : Offset and length of registers
+ - interrupts : Interrupt; mode, number and trigger
+ - dr_mode    : Dual-role; either host mode "host", peripheral mode "peripheral"
+                or both "otg"
+Optional properties:
+ - dmas       : A list of dma channels;
+                dma-controller, event-line, fixed-channel, flags
+ - dma-names  : An ordered list of channel names affiliated to the above
+Example:
+usb_per5@a03e0000 {
+        compatible = "stericsson,db8500-musb", "mentor,musb";
+        reg = <0xa03e0000 0x10000>;
+        interrupts = <0 23 0x4>;
+        interrupt-names = "mc";
+        dr_mode = "otg";
+        dmas = <&dma 38 0 0x2>, /* Logical - DevToMem */
+               <&dma 38 0 0x0>, /* Logical - MemToDev */
+               <&dma 37 0 0x2>, /* Logical - DevToMem */
+               <&dma 37 0 0x0>, /* Logical - MemToDev */
+               <&dma 36 0 0x2>, /* Logical - DevToMem */
+               <&dma 36 0 0x0>, /* Logical - MemToDev */
+               <&dma 19 0 0x2>, /* Logical - DevToMem */
+               <&dma 19 0 0x0>, /* Logical - MemToDev */
+               <&dma 18 0 0x2>, /* Logical - DevToMem */
+               <&dma 18 0 0x0>, /* Logical - MemToDev */
+               <&dma 17 0 0x2>, /* Logical - DevToMem */
+               <&dma 17 0 0x0>, /* Logical - MemToDev */
+               <&dma 16 0 0x2>, /* Logical - DevToMem */
+               <&dma 16 0 0x0>, /* Logical - MemToDev */
+               <&dma 39 0 0x2>, /* Logical - DevToMem */
+               <&dma 39 0 0x0>; /* Logical - MemToDev */
+        dma-names = "iep_1_9",  "oep_1_9",
+                    "iep_2_10", "oep_2_10",
+                    "iep_3_11", "oep_3_11",
+                    "iep_4_12", "oep_4_12",
+                    "iep_5_13", "oep_5_13",
+                    "iep_6_14", "oep_6_14",
+                    "iep_7_15", "oep_7_15",
+                    "iep_8",    "oep_8";
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 6931c4348d24..d5a79caec147 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -18,6 +18,7 @@ chrp	Common Hardware Reference Platform
 cirrus  Cirrus Logic, Inc.
 cortina Cortina Systems, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
+davicom DAVICOM Semiconductor, Inc.
 denx    Denx Software Engineering
 emmicro EM Microelectronic
 epson   Seiko Epson Corp.
@@ -31,6 +32,7 @@ idt	Integrated Device Technologies, Inc.
 img     Imagination Technologies Ltd.
 intercontrol    Inter Control Group
 linux   Linux-specific binding
+lsi     LSI Corp. (LSI Logic)
 marvell Marvell Technology Group Ltd.
 maxim   Maxim Integrated Products
 mosaixtech      Mosaix Technologies, Inc.
@@ -57,8 +59,10 @@ snps 	Synopsys, Inc.
 st      STMicroelectronics
 ste     ST-Ericsson
 stericsson      ST-Ericsson
+toumaz  Toumaz
 ti      Texas Instruments
 toshiba Toshiba Corporation
+v3      V3 Semiconductor
 via     VIA Technologies, Inc.
 wlf     Wolfson Microelectronics
 wm      Wondermedia Technologies, Inc.
diff --git a/Documentation/devicetree/bindings/video/display-timing.txt b/Documentation/devicetree/bindings/video/display-timing.txt
index 150038552bc3..e1d4a0b59612 100644
--- a/Documentation/devicetree/bindings/video/display-timing.txt
+++ b/Documentation/devicetree/bindings/video/display-timing.txt
@@ -34,6 +34,7 @@ optional properties:
                        - ignored     = ignored
 - interlaced (bool): boolean to enable interlaced mode
 - doublescan (bool): boolean to enable doublescan mode
+ - doubleclk (bool): boolean to enable doubleclock mode
 All the optional properties that are not bool follow the following logic:
    <1>: high active
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index c60da67a5d76..84f10c16cb38 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -21,6 +21,10 @@ Required properties for dp-controller:
                of memory mapped region.
        -interrupts:
                interrupt combiner values.
+        -clocks:
+                from common clock binding: handle to dp clock.
+        -clock-names:
+                from common clock binding: Shall be "dp".
        -interrupt-parent:
                phandle to Interrupt combiner node.
        -samsung,color-space:
@@ -61,6 +65,8 @@ SOC specific portion:
                reg = <0x145b0000 0x10000>;
                interrupts = <10 3>;
                interrupt-parent = <&combiner>;
+                clocks = <&clock 342>;
+                clock-names = "dp";
                dptx-phy {
                        reg = <0x10040720>;
diff --git a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 589edee37394..323983be3c30 100644
--- a/Documentation/devicetree/bindings/drm/exynos/hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -1,22 +1,23 @@
 Device-Tree bindings for drm hdmi driver
 Required properties:
- compatible: value should be "samsung,exynos5-hdmi".
+- compatible: value should be one among the following:
+        1) "samsung,exynos5-hdmi" <DEPRECATED>
+        2) "samsung,exynos4210-hdmi"
+        3) "samsung,exynos4212-hdmi"
 - reg: physical base address of the hdmi and length of memory mapped
        region.
 - interrupts: interrupt number to the cpu.
 - hpd-gpio: following information about the hotplug gpio pin.
        a) phandle of the gpio controller node.
        b) pin number within the gpio controller.
-        c) pin function mode.
+        c) optional flags and pull up/down.
-        d) optional flags and pull up/down.
-        e) drive strength.
 Example:
        hdmi {
-                compatible = "samsung,exynos5-hdmi";
+                compatible = "samsung,exynos4212-hdmi";
                reg = <0x14530000 0x100000>;
                interrupts = <0 95 0>;
-                hpd-gpio = <&gpx3 7 0xf 1 3>;
+                hpd-gpio = <&gpx3 7 1>;
        };
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
new file mode 100644
index 000000000000..41eee971562b
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiddc.txt
@@ -0,0 +1,15 @@
+Device-Tree bindings for hdmiddc driver
+Required properties:
+- compatible: value should be one of the following
+        1) "samsung,exynos5-hdmiddc" <DEPRECATED>
+        2) "samsung,exynos4210-hdmiddc"
+- reg: I2C address of the hdmiddc device.
+Example:
+        hdmiddc {
+                compatible = "samsung,exynos4210-hdmiddc";
+                reg = <0x50>;
+        };
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
new file mode 100644
index 000000000000..162f641f7639
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_hdmiphy.txt
@@ -0,0 +1,15 @@
+Device-Tree bindings for hdmiphy driver
+Required properties:
+- compatible: value should be one of the following:
+        1) "samsung,exynos5-hdmiphy" <DEPRECATED>
+        2) "samsung,exynos4210-hdmiphy".
+        3) "samsung,exynos4212-hdmiphy".
+- reg: I2C address of the hdmiphy device.
+Example:
+        hdmiphy {
+                compatible = "samsung,exynos4210-hdmiphy";
+                reg = <0x38>;
+        };
diff --git a/Documentation/devicetree/bindings/drm/exynos/mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 9b2ea0343566..3334b0a8e343 100644
--- a/Documentation/devicetree/bindings/drm/exynos/mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -1,7 +1,12 @@
 Device-Tree bindings for mixer driver
 Required properties:
- compatible: value should be "samsung,exynos5-mixer".
+- compatible: value should be one of the following:
+        1) "samsung,exynos5-mixer" <DEPRECATED>
+        2) "samsung,exynos4210-mixer"
+        3) "samsung,exynos5250-mixer"
+        4) "samsung,exynos5420-mixer"
 - reg: physical base address of the mixer and length of memory mapped
        region.
 - interrupts: interrupt number to the cpu.
@@ -9,7 +14,7 @@ Required properties:
 Example:
        mixer {
-                compatible = "samsung,exynos5-mixer";
+                compatible = "samsung,exynos5250-mixer";
                reg = <0x14450000 0x10000>;
                interrupts = <0 94 0>;
        };
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
new file mode 100644
index 000000000000..46da08db186a
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -0,0 +1,51 @@
+Freescale imx21 Framebuffer
+This framebuffer driver supports devices imx1, imx21, imx25, and imx27.
+Required properties:
+- compatible : "fsl,<chip>-fb", chip should be imx1 or imx21
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : One interrupt of the fb dev
+Required nodes:
+- display: Phandle to a display node as described in
+        Documentation/devicetree/bindings/video/display-timing.txt
+        Additional, the display node has to define properties:
+        - bits-per-pixel: Bits per pixel
+        - fsl,pcr: LCDC PCR value
+Optional properties:
+- fsl,dmacr: DMA Control Register value. This is optional. By default, the
+        register is not modified as recommended by the datasheet.
+- fsl,lscr1: LCDC Sharp Configuration Register value.
+Example:
+        imxfb: fb@10021000 {
+                compatible = "fsl,imx21-fb";
+                interrupts = <61>;
+                reg = <0x10021000 0x1000>;
+                display = <&display0>;
+        };
+        ...
+        display0: display0 {
+                model = "Primeview-PD050VL1";
+                native-mode = <&timing_disp0>;
+                bits-per-pixel = <16>;
+                fsl,pcr = <0xf0c88080>; /* non-standard but required */
+                display-timings {
+                        timing_disp0: 640x480 {
+                                hactive = <640>;
+                                vactive = <480>;
+                                hback-porch = <112>;
+                                hfront-porch = <36>;
+                                hsync-len = <32>;
+                                vback-porch = <33>;
+                                vfront-porch = <33>;
+                                vsync-len = <2>;
+                                clock-frequency = <25000000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/video/simple-framebuffer.txt b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
new file mode 100644
index 000000000000..3ea460583111
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/simple-framebuffer.txt
@@ -0,0 +1,25 @@
+Simple Framebuffer
+A simple frame-buffer describes a raw memory region that may be rendered to,
+with the assumption that the display hardware has already been set up to scan
+out from that buffer.
+Required properties:
+- compatible: "simple-framebuffer"
+- reg: Should contain the location and size of the framebuffer memory.
+- width: The width of the framebuffer in pixels.
+- height: The height of the framebuffer in pixels.
+- stride: The number of bytes in each line of the framebuffer.
+- format: The format of the framebuffer surface. Valid values are:
+  - r5g6b5 (16-bit pixels, d[15:11]=r, d[10:5]=g, d[4:0]=b).
+Example:
+        framebuffer {
+                compatible = "simple-framebuffer";
+                reg = <0x1d385000 (1600 * 1200 * 2)>;
+                width = <1600>;
+                height = <1200>;
+                stride = <(1600 * 2)>;
+                format = "r5g6b5";
+        };
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
index 3d0060cff062..7a125427ff4b 100644
--- a/Documentation/devicetree/bindings/video/ssd1307fb.txt
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -1,13 +1,17 @@
 * Solomon SSD1307 Framebuffer Driver
 Required properties:
-  - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
+  - compatible: Should be "solomon,<chip>fb-<bus>". The only supported bus for
-    now is i2c.
+    now is i2c, and the supported chips are ssd1306 and ssd1307.
  - reg: Should contain address of the controller on the I2C bus. Most likely
         0x3c or 0x3d
  - pwm: Should contain the pwm to use according to the OF device tree PWM
-         specification [0]
+         specification [0]. Only required for the ssd1307.
  - reset-gpios: Should contain the GPIO used to reset the OLED display
+  - solomon,height: Height in pixel of the screen driven by the controller
+  - solomon,width: Width in pixel of the screen driven by the controller
+  - solomon,page-offset: Offset of pages (band of 8 pixels) that the screen is
+    mapped to.
 Optional properties:
  - reset-active-low: Is the reset gpio is active on physical low?
diff --git a/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
new file mode 100644
index 000000000000..8ffb88e39e76
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/stericsson-coh901327.txt
@@ -0,0 +1,19 @@
+ST-Ericsson COH 901 327 Watchdog timer
+Required properties:
+- compatible: must be "stericsson,coh901327".
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: the interrupt used for the watchdog timeout warning.
+Optional properties:
+- timeout-sec: contains the watchdog timeout in seconds.
+Example:
+watchdog: watchdog@c0012000 {
+        compatible = "stericsson,coh901327";
+        reg = <0xc0012000 0x1000>;
+        interrupts = <3>;
+        timeout-sec = <60>;
+};
diff --git a/Documentation/devicetree/usage-model.txt b/Documentation/devicetree/usage-model.txt
index ef9d06c9f8fd..2b6b3d3f0388 100644
--- a/Documentation/devicetree/usage-model.txt
+++ b/Documentation/devicetree/usage-model.txt
@@ -106,17 +106,18 @@ In the majority of cases, the machine identity is irrelevant, and the
 kernel will instead select setup code based on the machine's core
 CPU or SoC.  On ARM for example, setup_arch() in
 arch/arm/kernel/setup.c will call setup_machine_fdt() in
-arch/arm/kernel/devicetree.c which searches through the machine_desc
+arch/arm/kernel/devtree.c which searches through the machine_desc
 table and selects the machine_desc which best matches the device tree
 data.  It determines the best match by looking at the 'compatible'
 property in the root device tree node, and comparing it with the
-dt_compat list in struct machine_desc.
+dt_compat list in struct machine_desc (which is defined in
+arch/arm/include/asm/mach/arch.h if you're curious).
 The 'compatible' property contains a sorted list of strings starting
 with the exact name of the machine, followed by an optional list of
 boards it is compatible with sorted from most compatible to least.  For
 example, the root compatible properties for the TI BeagleBoard and its
-successor, the BeagleBoard xM board might look like:
+successor, the BeagleBoard xM board might look like, respectively:
        compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3";
        compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3";
@@ -161,7 +162,7 @@ cases.
 Instead, the compatible list allows a generic machine_desc to provide
 support for a wide common set of boards by specifying "less
-compatible" value in the dt_compat list.  In the example above,
+compatible" values in the dt_compat list.  In the example above,
 generic board support can claim compatibility with "ti,omap3" or
 "ti,omap3450".  If a bug was discovered on the original beagleboard
 that required special workaround code during early boot, then a new
@@ -191,9 +192,11 @@ Linux it will look something like this:
        };
 The bootargs property contains the kernel arguments, and the initrd-*
-properties define the address and size of an initrd blob.  The
+properties define the address and size of an initrd blob.  Note that
-chosen node may also optionally contain an arbitrary number of
+initrd-end is the first address after the initrd image, so this doesn't
-additional properties for platform-specific configuration data.
+match the usual semantic of struct resource.  The chosen node may also
+optionally contain an arbitrary number of additional properties for
+platform-specific configuration data.
 During early boot, the architecture setup code calls of_scan_flat_dt()
 several times with different helper callbacks to parse device tree
@@ -375,7 +378,7 @@ platform_devices as more platform_devices is a common pattern, and the
 device tree support code reflects that and makes the above example
 simpler.  The second argument to of_platform_populate() is an
 of_device_id table, and any node that matches an entry in that table
-will also get its child nodes registered.  In the tegra case, the code
+will also get its child nodes registered.  In the Tegra case, the code
 can look something like this:
 static void __init harmony_init_machine(void)
diff --git a/Documentation/dmatest.txt b/Documentation/dmatest.txt
index 279ac0a8c5b1..132a094c7bc3 100644
--- a/Documentation/dmatest.txt
+++ b/Documentation/dmatest.txt
@@ -34,7 +34,7 @@ command:
 After a while you will start to get messages about current status or error like
 in the original code.
-Note that running a new test will stop any in progress test.
+Note that running a new test will not stop any in progress test.
 The following command should return actual state of the test.
        % cat /sys/kernel/debug/dmatest/run
@@ -52,8 +52,8 @@ To wait for test done the user may perform a busy loop that checks the state.
 The module parameters that is supplied to the kernel command line will be used
 for the first performed test. After user gets a control, the test could be
-interrupted or re-run with same or different parameters. For the details see
+re-run with the same or different parameters. For the details see the above
-the above section "Part 2 - When dmatest is built as a module..."
+section "Part 2 - When dmatest is built as a module..."
 In both cases the module parameters are used as initial values for the test case.
 You always could check them at run-time by running
diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt
index 72322c6d7352..1bbdcfcf1f13 100644
--- a/Documentation/dynamic-debug-howto.txt
+++ b/Documentation/dynamic-debug-howto.txt
@@ -279,7 +279,7 @@ The dyndbg option is a "fake" module parameter, which means:
 - modules do not need to define it explicitly
 - every module gets it tacitly, whether they use pr_debug or not
- it doesnt appear in /sys/module/$module/parameters/
+- it doesn't appear in /sys/module/$module/parameters/
  To see it, grep the control file, or inspect /proc/cmdline.
 For CONFIG_DYNAMIC_DEBUG kernels, any settings given at boot-time (or
diff --git a/Documentation/early-userspace/README b/Documentation/early-userspace/README
index e35d83052192..661a73fad399 100644
--- a/Documentation/early-userspace/README
+++ b/Documentation/early-userspace/README
@@ -71,7 +71,7 @@ can really be interpreted as any legal argument to
 gen_initramfs_list.sh.  If a directory is specified as an argument then
 the contents are scanned, uid/gid translation is performed, and
 usr/gen_init_cpio file directives are output.  If a directory is
-specified as an arugemnt to scripts/gen_initramfs_list.sh then the
+specified as an argument to scripts/gen_initramfs_list.sh then the
 contents of the file are simply copied to the output.  All of the output
 directives from directory scanning and file contents copying are
 processed by usr/gen_init_cpio.
diff --git a/Documentation/fb/cirrusfb.txt b/Documentation/fb/cirrusfb.txt
index f9436843e998..f75950d330a4 100644
--- a/Documentation/fb/cirrusfb.txt
+++ b/Documentation/fb/cirrusfb.txt
@@ -55,7 +55,7 @@ Version 1.9.4.4
 * Overhaul color register routines.
 * Associated with the above, console colors are now obtained from a LUT
  called 'palette' instead of from the VGA registers.  This code was
-  modeled after that in atyfb and matroxfb.
+  modelled after that in atyfb and matroxfb.
 * Code cleanup, add comments.
 * Overhaul SR07 handling.
 * Bug fixes.
diff --git a/Documentation/fb/uvesafb.txt b/Documentation/fb/uvesafb.txt
index eefdd91d298a..f6362d88763b 100644
--- a/Documentation/fb/uvesafb.txt
+++ b/Documentation/fb/uvesafb.txt
@@ -81,17 +81,11 @@ pmipal  Use the protected mode interface for palette changes.
 mtrr:n  Setup memory type range registers for the framebuffer
        where n:
-              0 - disabled (equivalent to nomtrr) (default)
+              0 - disabled (equivalent to nomtrr)
-              1 - uncachable
+              3 - write-combining (default)
-              2 - write-back
-              3 - write-combining
+        Values other than 0 and 3 will result in a warning and will be
-              4 - write-through
+        treated just like 3.
-        If you see the following in dmesg, choose the type that matches
-        the old one.  In this example, use "mtrr:2".
-...
-mtrr: type mismatch for e0000000,8000000 old: write-back new: write-combining
-...
 nomtrr  Do not use memory type range registers.
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 0706d32a61e6..fe7afe225381 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -11,10 +11,8 @@ be able to use diff(1).
 prototypes:
        int (*d_revalidate)(struct dentry *, unsigned int);
        int (*d_weak_revalidate)(struct dentry *, unsigned int);
-        int (*d_hash)(const struct dentry *, const struct inode *,
+        int (*d_hash)(const struct dentry *, struct qstr *);
-                        struct qstr *);
+        int (*d_compare)(const struct dentry *, const struct dentry *,
-        int (*d_compare)(const struct dentry *, const struct inode *,
-                        const struct dentry *, const struct inode *,
                        unsigned int, const char *, const struct qstr *);
        int (*d_delete)(struct dentry *);
        void (*d_release)(struct dentry *);
@@ -66,6 +64,7 @@ prototypes:
        int (*atomic_open)(struct inode *, struct dentry *,
                                struct file *, unsigned open_flag,
                                umode_t create_mode, int *opened);
+        int (*tmpfile) (struct inode *, struct dentry *, umode_t);
 locking rules:
        all may block
@@ -93,6 +92,7 @@ removexattr:	yes
 fiemap:         no
 update_time:    no
 atomic_open:    yes
+tmpfile:        no
        Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
@@ -189,7 +189,7 @@ prototypes:
                                loff_t pos, unsigned len, unsigned copied,
                                struct page *page, void *fsdata);
        sector_t (*bmap)(struct address_space *, sector_t);
-        int (*invalidatepage) (struct page *, unsigned long);
+        void (*invalidatepage) (struct page *, unsigned int, unsigned int);
        int (*releasepage) (struct page *, int);
        void (*freepage)(struct page *);
        int (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
@@ -310,8 +310,8 @@ filesystems and by the swapper. The latter will eventually go away.  Please,
 keep it that way and don't breed new callers.
        ->invalidatepage() is called when the filesystem must attempt to drop
-some or all of the buffers from the page when it is being truncated.  It
+some or all of the buffers from the page when it is being truncated. It
-returns zero on success.  If ->invalidatepage is zero, the kernel uses
+returns zero on success. If ->invalidatepage is zero, the kernel uses
 block_invalidatepage() instead.
        ->releasepage() is called when the kernel is about to try to drop the
@@ -344,25 +344,38 @@ prototypes:
 locking rules:
-                        file_lock_lock  may block
+                        inode->i_lock   may block
 fl_copy_lock:           yes             no
 fl_release_private:     maybe           no
 ----------------------- lock_manager_operations ---------------------------
 prototypes:
        int (*lm_compare_owner)(struct file_lock *, struct file_lock *);
+        unsigned long (*lm_owner_key)(struct file_lock *);
        void (*lm_notify)(struct file_lock *);  /* unblock callback */
        int (*lm_grant)(struct file_lock *, struct file_lock *, int);
        void (*lm_break)(struct file_lock *); /* break_lease callback */
        int (*lm_change)(struct file_lock **, int);
 locking rules:
-                        file_lock_lock  may block
-lm_compare_owner:       yes             no
+                        inode->i_lock   blocked_lock_lock       may block
-lm_notify:              yes             no
+lm_compare_owner:       yes[1]          maybe                   no
-lm_grant:               no              no
+lm_owner_key            yes[1]          yes                     no
-lm_break:               yes             no
+lm_notify:              yes             yes                     no
-lm_change               yes             no
+lm_grant:               no              no                      no
+lm_break:               yes             no                      no
+lm_change               yes             no                      no
+[1]:    ->lm_compare_owner and ->lm_owner_key are generally called with
+*an* inode->i_lock held. It may not be the i_lock of the inode
+associated with either file_lock argument! This is the case with deadlock
+detection, since the code has to chase down the owners of locks that may
+be entirely unrelated to the one on which the lock is being acquired.
+For deadlock detection however, the blocked_lock_lock is also held. The
+fact that these locks are held ensures that the file_locks do not
+disappear out from under you while doing the comparison or generating an
+owner key.
 --------------------------- buffer_head -----------------------------------
 prototypes:
@@ -414,7 +427,7 @@ prototypes:
        ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
        ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
        ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
-        int (*readdir) (struct file *, void *, filldir_t);
+        int (*iterate) (struct file *, struct dir_context *);
        unsigned int (*poll) (struct file *, struct poll_table_struct *);
        long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
        long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index bd3c56c67380..b91e2f26b672 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -98,8 +98,13 @@ Cleaning Overhead
 MOUNT OPTIONS
 ================================================================================
-background_gc_off      Turn off cleaning operations, namely garbage collection,
+background_gc=%s       Turn on/off cleaning operations, namely garbage
-                       triggered in background when I/O subsystem is idle.
+                       collection, triggered in background when I/O subsystem is
+                       idle. If background_gc=on, it will turn on the garbage
+                       collection and if background_gc=off, garbage collection
+                       will be truned off.
+                       Default value for this option is on. So garbage
+                       collection is on by default.
 disable_roll_forward   Disable the roll-forward recovery routine
 discard                Issue discard/TRIM commands when a segment is cleaned.
 no_heap                Disable heap-style segment allocation which finds free
diff --git a/Documentation/filesystems/jfs.txt b/Documentation/filesystems/jfs.txt
index f7433355394a..41fd757997b3 100644
--- a/Documentation/filesystems/jfs.txt
+++ b/Documentation/filesystems/jfs.txt
@@ -42,7 +42,7 @@ nodiscard(*)	block device when blocks are freed. This is useful for SSD
                devices and sparse/thinly-provisioned LUNs.  The FITRIM ioctl
                command is also available together with the nodiscard option.
                The value of minlen specifies the minimum blockcount, when
-                a TRIM command to the block device is considered usefull.
+                a TRIM command to the block device is considered useful.
                When no value is given to the discard option, it defaults to
                64 blocks, which means 256KiB in JFS.
                The minlen value of discard overrides the minlen value given
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index 4db22f6491e0..206a1bdc7321 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -445,3 +445,9 @@ object doesn't exist.  It's remote/distributed ones that might care...
 [mandatory]
        FS_REVAL_DOT is gone; if you used to have it, add ->d_weak_revalidate()
 in your dentry operations instead.
+--
+[mandatory]
+        vfs_readdir() is gone; switch to iterate_dir() instead
+--
+[mandatory]
+        ->readdir() is gone now; switch to ->iterate()
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index fd8d0d594fc7..fcc22c982a25 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -473,7 +473,8 @@ This file is only present if the CONFIG_MMU kernel configuration option is
 enabled.
 The /proc/PID/clear_refs is used to reset the PG_Referenced and ACCESSED/YOUNG
-bits on both physical and virtual pages associated with a process.
+bits on both physical and virtual pages associated with a process, and the
+soft-dirty bit on pte (see Documentation/vm/soft-dirty.txt for details).
 To clear the bits for all the pages associated with the process
    > echo 1 > /proc/PID/clear_refs
@@ -482,6 +483,10 @@ To clear the bits for the anonymous pages associated with the process
 To clear the bits for the file mapped pages associated with the process
    > echo 3 > /proc/PID/clear_refs
+To clear the soft-dirty bit
+    > echo 4 > /proc/PID/clear_refs
 Any other value written to /proc/PID/clear_refs will have no effect.
 The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt
index e59f2f09f56e..99e90184a72f 100644
--- a/Documentation/filesystems/qnx6.txt
+++ b/Documentation/filesystems/qnx6.txt
@@ -148,7 +148,7 @@ smaller than addressing space in the bitmap.
 Bitmap system area
 ------------------
-The bitmap itself is devided into three parts.
+The bitmap itself is divided into three parts.
 First the system area, that is split into two halfs.
 Then userspace.
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index 4a93e98b290a..aa1f459fa6cf 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -307,7 +307,7 @@ the following:
                <proceeding files...>
                <slot #3, id = 0x43, characters = "h is long">
-                <slot #2, id = 0x02, characters = "xtension whic">
+                <slot #2, id = 0x02, characters = "xtension which">
                <slot #1, id = 0x01, characters = "My Big File.E">
                <directory entry, name = "MYBIGFIL.EXT">
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index bc4b06b3160a..f93a88250a44 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -360,6 +360,8 @@ struct inode_operations {
        int (*removexattr) (struct dentry *, const char *);
        void (*update_time)(struct inode *, struct timespec *, int);
        int (*atomic_open)(struct inode *, struct dentry *,
+        int (*tmpfile) (struct inode *, struct dentry *, umode_t);
+} ____cacheline_aligned;
                                struct file *, unsigned open_flag,
                                umode_t create_mode, int *opened);
 };
@@ -472,6 +474,9 @@ otherwise noted.
        component is negative or needs lookup.  Cached positive dentries are
        still handled by f_op->open().
+  tmpfile: called in the end of O_TMPFILE open().  Optional, equivalent to
+        atomically creating, opening and unlinking a file in given directory.
 The Address Space Object
 ========================
@@ -549,12 +554,11 @@ struct address_space_operations
 -------------------------------
 This describes how the VFS can manipulate mapping of a file to page cache in
-your filesystem. As of kernel 2.6.22, the following members are defined:
+your filesystem. The following members are defined:
 struct address_space_operations {
        int (*writepage)(struct page *page, struct writeback_control *wbc);
        int (*readpage)(struct file *, struct page *);
-        int (*sync_page)(struct page *);
        int (*writepages)(struct address_space *, struct writeback_control *);
        int (*set_page_dirty)(struct page *page);
        int (*readpages)(struct file *filp, struct address_space *mapping,
@@ -566,7 +570,7 @@ struct address_space_operations {
                                loff_t pos, unsigned len, unsigned copied,
                                struct page *page, void *fsdata);
        sector_t (*bmap)(struct address_space *, sector_t);
-        int (*invalidatepage) (struct page *, unsigned long);
+        void (*invalidatepage) (struct page *, unsigned int, unsigned int);
        int (*releasepage) (struct page *, int);
        void (*freepage)(struct page *);
        ssize_t (*direct_IO)(int, struct kiocb *, const struct iovec *iov,
@@ -576,6 +580,9 @@ struct address_space_operations {
        /* migrate the contents of a page to the specified target */
        int (*migratepage) (struct page *, struct page *);
        int (*launder_page) (struct page *);
+        int (*is_partially_uptodate) (struct page *, read_descriptor_t *,
+                                        unsigned long);
+        void (*is_dirty_writeback) (struct page *, bool *, bool *);
        int (*error_remove_page) (struct mapping *mapping, struct page *page);
        int (*swap_activate)(struct file *);
        int (*swap_deactivate)(struct file *);
@@ -607,13 +614,6 @@ struct address_space_operations {
       In this case, the page will be relocated, relocked and if
       that all succeeds, ->readpage will be called again.
-  sync_page: called by the VM to notify the backing store to perform all
-        queued I/O operations for a page. I/O operations for other pages
-        associated with this address_space object may also be performed.
-        This function is optional and is called only for pages with
-        PG_Writeback set while waiting for the writeback to complete.
  writepages: called by the VM to write out pages associated with the
        address_space object.  If wbc->sync_mode is WBC_SYNC_ALL, then
        the writeback_control will specify a range of pages that must be
@@ -685,14 +685,14 @@ struct address_space_operations {
  invalidatepage: If a page has PagePrivate set, then invalidatepage
        will be called when part or all of the page is to be removed
        from the address space.  This generally corresponds to either a
-        truncation or a complete invalidation of the address space
+        truncation, punch hole  or a complete invalidation of the address
-        (in the latter case 'offset' will always be 0).
+        space (in the latter case 'offset' will always be 0 and 'length'
-        Any private data associated with the page should be updated
+        will be PAGE_CACHE_SIZE). Any private data associated with the page
-        to reflect this truncation.  If offset is 0, then
+        should be updated to reflect this truncation.  If offset is 0 and
-        the private data should be released, because the page
+        length is PAGE_CACHE_SIZE, then the private data should be released,
-        must be able to be completely discarded.  This may be done by
+        because the page must be able to be completely discarded.  This may
-        calling the ->releasepage function, but in this case the
+        be done by calling the ->releasepage function, but in this case the
-        release MUST succeed.
+        release MUST succeed.
  releasepage: releasepage is called on PagePrivate pages to indicate
        that the page should be freed if possible.  ->releasepage
@@ -742,6 +742,20 @@ struct address_space_operations {
        prevent redirtying the page, it is kept locked during the whole
        operation.
+  is_partially_uptodate: Called by the VM when reading a file through the
+        pagecache when the underlying blocksize != pagesize. If the required
+        block is up to date then the read can complete without needing the IO
+        to bring the whole page up to date.
+  is_dirty_writeback: Called by the VM when attempting to reclaim a page.
+        The VM uses dirty and writeback information to determine if it needs
+        to stall to allow flushers a chance to complete some IO. Ordinarily
+        it can use PageDirty and PageWriteback but some filesystems have
+        more complex state (unstable pages in NFS prevent reclaim) or
+        do not set those flags due to locking problems (jbd). This callback
+        allows a filesystem to indicate to the VM if a page should be
+        treated as dirty or writeback for the purposes of stalling.
  error_remove_page: normally set to generic_error_remove_page if truncation
        is ok for this address space. Used for memory failure handling.
        Setting this implies you deal with pages going away under you,
@@ -777,7 +791,7 @@ struct file_operations {
        ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *);
        ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
        ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t);
-        int (*readdir) (struct file *, void *, filldir_t);
+        int (*iterate) (struct file *, struct dir_context *);
        unsigned int (*poll) (struct file *, struct poll_table_struct *);
        long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
        long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
@@ -815,7 +829,7 @@ otherwise noted.
  aio_write: called by io_submit(2) and other asynchronous I/O operations
-  readdir: called when the VFS needs to read the directory contents
+  iterate: called when the VFS needs to read the directory contents
  poll: called by the VFS when a process wants to check if there is
        activity on this file and (optionally) go to sleep until there
@@ -901,10 +915,8 @@ defined:
 struct dentry_operations {
        int (*d_revalidate)(struct dentry *, unsigned int);
        int (*d_weak_revalidate)(struct dentry *, unsigned int);
-        int (*d_hash)(const struct dentry *, const struct inode *,
+        int (*d_hash)(const struct dentry *, struct qstr *);
-                        struct qstr *);
+        int (*d_compare)(const struct dentry *, const struct dentry *,
-        int (*d_compare)(const struct dentry *, const struct inode *,
-                        const struct dentry *, const struct inode *,
                        unsigned int, const char *, const struct qstr *);
        int (*d_delete)(const struct dentry *);
        void (*d_release)(struct dentry *);
@@ -949,25 +961,24 @@ struct dentry_operations {
  d_hash: called when the VFS adds a dentry to the hash table. The first
        dentry passed to d_hash is the parent directory that the name is
-        to be hashed into. The inode is the dentry's inode.
+        to be hashed into.
        Same locking and synchronisation rules as d_compare regarding
        what is safe to dereference etc.
  d_compare: called to compare a dentry name with a given name. The first
        dentry is the parent of the dentry to be compared, the second is
-        the parent's inode, then the dentry and inode (may be NULL) of the
+        the child dentry. len and name string are properties of the dentry
-        child dentry. len and name string are properties of the dentry to be
+        to be compared. qstr is the name to compare it with.
-        compared. qstr is the name to compare it with.
        Must be constant and idempotent, and should not take locks if
-        possible, and should not or store into the dentry or inodes.
+        possible, and should not or store into the dentry.
-        Should not dereference pointers outside the dentry or inodes without
+        Should not dereference pointers outside the dentry without
        lots of care (eg.  d_parent, d_inode, d_name should not be used).
        However, our vfsmount is pinned, and RCU held, so the dentries and
        inodes won't disappear, neither will our sb or filesystem module.
-        ->i_sb and ->d_sb may be used.
+        ->d_sb may be used.
        It is a tricky calling convention because it needs to be called under
        "rcu-walk", ie. without any locks or references on things.
diff --git a/Documentation/filesystems/xfs.txt b/Documentation/filesystems/xfs.txt
index 3e4b3dd1e046..83577f0232a0 100644
--- a/Documentation/filesystems/xfs.txt
+++ b/Documentation/filesystems/xfs.txt
@@ -33,6 +33,9 @@ When mounting an XFS filesystem, the following options are accepted.
        removing extended attributes) the on-disk superblock feature
        bit field will be updated to reflect this format being in use.
+        CRC enabled filesystems always use the attr2 format, and so
+        will reject the noattr2 mount option if it is set.
  barrier
        Enables the use of block layer write barriers for writes into
        the journal and unwritten extent conversion.  This allows for
diff --git a/Documentation/fmc/00-INDEX b/Documentation/fmc/00-INDEX
new file mode 100644
index 000000000000..431c69570f43
--- /dev/null
+++ b/Documentation/fmc/00-INDEX
@@ -0,0 +1,38 @@
+Documentation in this directory comes from sections of the manual we
+wrote for the externally-developed fmc-bus package. The complete
+manual as of today (2013-02) is available in PDF format at
+http://www.ohwr.org/projects/fmc-bus/files
+00-INDEX
+        - this file.
+FMC-and-SDB.txt
+        - What are FMC and SDB, basic concepts for this framework
+API.txt
+        - The functions that are exported by the bus driver
+parameters.txt
+        - The module parameters
+carrier.txt
+        - writing a carrier (a device)
+mezzanine.txt
+        - writing code for your mezzanine (a driver)
+identifiers.txt
+        - how identification and matching works
+fmc-fakedev.txt
+        - about drivers/fmc/fmc-fakedev.ko
+fmc-trivial.txt
+        - about drivers/fmc/fmc-trivial.ko
+fmc-write-eeprom.txt
+        - about drivers/fmc/fmc-write-eeprom.ko
+fmc-chardev.txt
+        - about drivers/fmc/fmc-chardev.ko
diff --git a/Documentation/fmc/API.txt b/Documentation/fmc/API.txt
new file mode 100644
index 000000000000..06b06b92c794
--- /dev/null
+++ b/Documentation/fmc/API.txt
@@ -0,0 +1,47 @@
+Functions Exported by fmc.ko
+****************************
+The FMC core exports the usual 4 functions that are needed for a bus to
+work, and a few more:
+        int fmc_driver_register(struct fmc_driver *drv);
+        void fmc_driver_unregister(struct fmc_driver *drv);
+        int fmc_device_register(struct fmc_device *fmc);
+        void fmc_device_unregister(struct fmc_device *fmc);
+        int fmc_device_register_n(struct fmc_device **fmc, int n);
+        void fmc_device_unregister_n(struct fmc_device **fmc, int n);
+        uint32_t fmc_readl(struct fmc_device *fmc, int offset);
+        void fmc_writel(struct fmc_device *fmc, uint32_t val, int off);
+        void *fmc_get_drvdata(struct fmc_device *fmc);
+        void fmc_set_drvdata(struct fmc_device *fmc, void *data);
+        int fmc_reprogram(struct fmc_device *f, struct fmc_driver *d, char *gw,
+                          int sdb_entry);
+The data structure that describe a device is detailed in *note FMC
+Device::, the one that describes a driver is detailed in *note FMC
+Driver::.  Please note that structures of type fmc_device must be
+allocated by the caller, but must not be released after unregistering.
+The fmc-bus itself takes care of releasing the structure when their use
+count reaches zero - actually, the device model does that in lieu of us.
+The functions to register and unregister n devices are meant to be used
+by carriers that host more than one mezzanine. The devices must all be
+registered at the same time because if the FPGA is reprogrammed, all
+devices in the array are affected. Usually, the driver matching the
+first device will reprogram the FPGA, so other devices must know they
+are already driven by a reprogrammed FPGA.
+If a carrier hosts slots that are driven by different FPGA devices, it
+should register as a group only mezzanines that are driven by the same
+FPGA, for the reason outlined above.
+Finally, the fmc_reprogram function calls the reprogram method (see
+*note The API Offered by Carriers:: and also scans the memory area for
+an SDB tree. You can pass -1 as sdb_entry to disable such scan.
+Otherwise, the function fails if no tree is found at the specified
+entry point.  The function is meant to factorize common code, and by
+the time you read this it is already used by the spec-sw and fine-delay
+modules.
diff --git a/Documentation/fmc/FMC-and-SDB.txt b/Documentation/fmc/FMC-and-SDB.txt
new file mode 100644
index 000000000000..fa14e0b24521
--- /dev/null
+++ b/Documentation/fmc/FMC-and-SDB.txt
@@ -0,0 +1,88 @@
+FMC (FPGA Mezzanine Card) is the standard we use for our I/O devices,
+in the context of White Rabbit and related hardware.
+In our I/O environments we need to write drivers for each mezzanine
+card, and such drivers must work regardless of the carrier being used.
+To achieve this, we abstract the FMC interface.
+We have a carrier for PCI-E called SPEC and one for VME called SVEC,
+but more are planned.  Also, we support stand-alone devices (usually
+plugged on a SPEC card), controlled through Etherbone, developed by GSI.
+Code and documentation for the FMC bus was born as part of the spec-sw
+project, but now it lives in its own project. Other projects, i.e.
+software support for the various carriers, should include this as a
+submodule.
+The most up to date version of code and documentation is always
+available from the repository you can clone from:
+        git://ohwr.org/fmc-projects/fmc-bus.git (read-only)
+        git@ohwr.org:fmc-projects/fmc-bus.git (read-write for developers)
+Selected versions of the documentation, as well as complete tar
+archives for selected revisions are placed to the Files section of the
+project: `http://www.ohwr.org/projects/fmc-bus/files'
+What is FMC
+***********
+FMC, as said, stands for "FPGA Mezzanine Card". It is a standard
+developed by the VME consortium called VITA (VMEbus International Trade
+Association and ratified by ANSI, the American National Standard
+Institute.  The official documentation is called "ANSI-VITA 57.1".
+The FMC card is an almost square PCB, around 70x75 millimeters, that is
+called mezzanine in this document.  It usually lives plugged into
+another PCB for power supply and control; such bigger circuit board is
+called carrier from now on, and a single carrier may host more than one
+mezzanine.
+In the typical application the mezzanine is mostly analog while the
+carrier is mostly digital, and hosts an FPGA that must be configured to
+match the specific mezzanine and the desired application. Thus, you may
+need to load different FPGA images to drive different instances of the
+same mezzanine.
+FMC, as such, is not a bus in the usual meaning of the term, because
+most carriers have only one connector, and carriers with several
+connectors have completely separate electrical connections to them.
+This package, however, implements a bus as a software abstraction.
+What is SDB
+***********
+SDB (Self Describing Bus) is a set of data structures that we use for
+enumerating the internal structure of an FPGA image. We also use it as
+a filesystem inside the FMC EEPROM.
+SDB is not mandatory for use of this FMC kernel bus, but if you have SDB
+this package can make good use of it.  SDB itself is developed in the
+fpga-config-space OHWR project. The link to the repository is
+`git://ohwr.org/hdl-core-lib/fpga-config-space.git' and what is used in
+this project lives in the sdbfs subdirectory in there.
+SDB support for FMC is described in *note FMC Identification:: and
+*note SDB Support::
+SDB Support
+***********
+The fmc.ko bus driver exports a few functions to help drivers taking
+advantage of the SDB information that may be present in your own FPGA
+memory image.
+The module exports the following functions, in the special header
+<linux/fmc-sdb.h>. The linux/ prefix in the name is there because we
+plan to submit it upstream in the future, and don't want to force
+changes on our drivers if that happens.
+         int fmc_scan_sdb_tree(struct fmc_device *fmc, unsigned long address);
+         void fmc_show_sdb_tree(struct fmc_device *fmc);
+         signed long fmc_find_sdb_device(struct sdb_array *tree, uint64_t vendor,
+                                         uint32_t device, unsigned long *sz);
+         int fmc_free_sdb_tree(struct fmc_device *fmc);
diff --git a/Documentation/fmc/carrier.txt b/Documentation/fmc/carrier.txt
new file mode 100644
index 000000000000..173f6d65c88d
--- /dev/null
+++ b/Documentation/fmc/carrier.txt
@@ -0,0 +1,311 @@
+FMC Device
+**********
+Within the Linux bus framework, the FMC device is created and
+registered by the carrier driver. For example, the PCI driver for the
+SPEC card fills a data structure for each SPEC that it drives, and
+registers an associated FMC device for each card.  The SVEC driver can
+do exactly the same for the VME carrier (actually, it should do it
+twice, because the SVEC carries two FMC mezzanines).  Similarly, an
+Etherbone driver will be able to register its own FMC devices, offering
+communication primitives through frame exchange.
+The contents of the EEPROM within the FMC are used for identification
+purposes, i.e. for matching the device with its own driver. For this
+reason the device structure includes a complete copy of the EEPROM
+(actually, the carrier driver may choose whether or not to return it -
+for example we most likely won't have the whole EEPROM available for
+Etherbone devices.
+The following listing shows the current structure defining a device.
+Please note that all the machinery is in place but some details may
+still change in the future.  For this reason, there is a version field
+at the beginning of the structure.  As usual, the minor number will
+change for compatible changes (like a new flag) and the major number
+will increase when an incompatible change happens (for example, a
+change in layout of some fmc data structures).  Device writers should
+just set it to the value FMC_VERSION, and be ready to get back -EINVAL
+at registration time.
+     struct fmc_device {
+             unsigned long version;
+             unsigned long flags;
+             struct module *owner;           /* char device must pin it */
+             struct fmc_fru_id id;           /* for EEPROM-based match */
+             struct fmc_operations *op;      /* carrier-provided */
+             int irq;                        /* according to host bus. 0 == none */
+             int eeprom_len;                 /* Usually 8kB, may be less */
+             int eeprom_addr;                /* 0x50, 0x52 etc */
+             uint8_t *eeprom;                /* Full contents or leading part */
+             char *carrier_name;             /* "SPEC" or similar, for special use */
+             void *carrier_data;             /* "struct spec *" or equivalent */
+             __iomem void *fpga_base;        /* May be NULL (Etherbone) */
+             __iomem void *slot_base;        /* Set by the driver */
+             struct fmc_device **devarray;   /* Allocated by the bus */
+             int slot_id;                    /* Index in the slot array */
+             int nr_slots;                   /* Number of slots in this carrier */
+             unsigned long memlen;           /* Used for the char device */
+             struct device dev;              /* For Linux use */
+             struct device *hwdev;           /* The underlying hardware device */
+             unsigned long sdbfs_entry;
+             struct sdb_array *sdb;
+             uint32_t device_id;             /* Filled by the device */
+             char *mezzanine_name;           /* Defaults to ``fmc'' */
+             void *mezzanine_data;
+     };
+The meaning of most fields is summarized in the code comment above.
+The following fields must be filled by the carrier driver before
+registration:
+   * version: must be set to FMC_VERSION.
+   * owner: set to MODULE_OWNER.
+   * op: the operations to act on the device.
+   * irq: number for the mezzanine; may be zero.
+   * eeprom_len: length of the following array.
+   * eeprom_addr: 0x50 for first mezzanine and so on.
+   * eeprom: the full content of the I2C EEPROM.
+   * carrier_name.
+   * carrier_data: a unique pointer for the carrier.
+   * fpga_base: the I/O memory address (may be NULL).
+   * slot_id: the index of this slot (starting from zero).
+   * memlen: if fpga_base is valid, the length of I/O memory.
+   * hwdev: to be used in some dev_err() calls.
+   * device_id: a slot-specific unique integer number.
+Please note that the carrier should read its own EEPROM memory before
+registering the device, as well as fill all other fields listed above.
+The following fields should not be assigned, because they are filled
+later by either the bus or the device driver:
+   * flags.
+   * fru_id: filled by the bus, parsing the eeprom.
+   * slot_base: filled and used by the driver, if useful to it.
+   * devarray: an array og all mezzanines driven by a singe FPGA.
+   * nr_slots: set by the core at registration time.
+   * dev: used by Linux.
+   * sdb: FPGA contents, scanned according to driver's directions.
+   * sdbfs_entry: SDB entry point in EEPROM: autodetected.
+   * mezzanine_data: available for the driver.
+   * mezzanine_name: filled by fmc-bus during identification.
+Note: mezzanine_data may be redundant, because Linux offers the drvdata
+approach, so the field may be removed in later versions of this bus
+implementation.
+As I write this, she SPEC carrier is already completely functional in
+the fmc-bus environment, and is a good reference to look at.
+The API Offered by Carriers
+===========================
+The carrier provides a number of methods by means of the
+`fmc_operations' structure, which currently is defined like this
+(again, it is a moving target, please refer to the header rather than
+this document):
+     struct fmc_operations {
+             uint32_t (*readl)(struct fmc_device *fmc, int offset);
+             void (*writel)(struct fmc_device *fmc, uint32_t value, int offset);
+             int (*reprogram)(struct fmc_device *f, struct fmc_driver *d, char *gw);
+             int (*validate)(struct fmc_device *fmc, struct fmc_driver *drv);
+             int (*irq_request)(struct fmc_device *fmc, irq_handler_t h,
+                                char *name, int flags);
+             void (*irq_ack)(struct fmc_device *fmc);
+             int (*irq_free)(struct fmc_device *fmc);
+             int (*gpio_config)(struct fmc_device *fmc, struct fmc_gpio *gpio,
+                                int ngpio);
+             int (*read_ee)(struct fmc_device *fmc, int pos, void *d, int l);
+             int (*write_ee)(struct fmc_device *fmc, int pos, const void *d, int l);
+     };
+The individual methods perform the following tasks:
+`readl'
+`writel'
+     These functions access FPGA registers by whatever means the
+     carrier offers. They are not expected to fail, and most of the time
+     they will just make a memory access to the host bus. If the
+     carrier provides a fpga_base pointer, the driver may use direct
+     access through that pointer. For this reason the header offers the
+     inline functions fmc_readl and fmc_writel that access fpga_base if
+     the respective method is NULL. A driver that wants to be portable
+     and efficient should use fmc_readl and fmc_writel.  For Etherbone,
+     or other non-local carriers, error-management is still to be
+     defined.
+`validate'
+     Module parameters are used to manage different applications for
+     two or more boards of the same kind. Validation is based on the
+     busid module parameter, if provided, and returns the matching
+     index in the associated array. See *note Module Parameters:: in in
+     doubt. If no match is found, `-ENOENT' is returned; if the user
+     didn't pass `busid=', all devices will pass validation.  The value
+     returned by the validate method can be used as index into other
+     parameters (for example, some drivers use the `lm32=' parameter in
+     this way). Such "generic parameters" are documented in *note
+     Module Parameters::, below. The validate method is used by
+     `fmc-trivial.ko', described in *note fmc-trivial::.
+`reprogram'
+     The carrier enumerates FMC devices by loading a standard (or
+     golden) FPGA binary that allows EEPROM access. Each driver, then,
+     will need to reprogram the FPGA by calling this function.  If the
+     name argument is NULL, the carrier should reprogram the golden
+     binary. If the gateware name has been overridden through module
+     parameters (in a carrier-specific way) the file loaded will match
+     the parameters. Per-device gateware names can be specified using
+     the `gateware=' parameter, see *note Module Parameters::.  Note:
+     Clients should call rhe new helper, fmc_reprogram, which both
+     calls this method and parse the SDB tree of the FPGA.
+`irq_request'
+`irq_ack'
+`irq_free'
+     Interrupt management is carrier-specific, so it is abstracted as
+     operations. The interrupt number is listed in the device
+     structure, and for the mezzanine driver the number is only
+     informative.  The handler will receive the fmc pointer as dev_id;
+     the flags argument is passed to the Linux request_irq function,
+     but fmc-specific flags may be added in the future. You'll most
+     likely want to pass the `IRQF_SHARED' flag.
+`gpio_config'
+     The method allows to configure a GPIO pin in the carrier, and read
+     its current value if it is configured as input. See *note The GPIO
+     Abstraction:: for details.
+`read_ee'
+`write_ee'
+     Read or write the EEPROM. The functions are expected to be only
+     called before reprogramming and the carrier should refuse them
+     with `ENODEV' after reprogramming.  The offset is expected to be
+     within 8kB (the current size), but addresses up to 1MB are
+     reserved to fit bigger I2C devices in the future. Carriers may
+     offer access to other internal flash memories using these same
+     methods: for example the SPEC driver may define that its carrier
+     I2C memory is seen at offset 1M and the internal SPI flash is seen
+     at offset 16M.  This multiplexing of several flash memories in the
+     same address space is is carrier-specific and should only be used
+     by a driver that has verified the `carrier_name' field.
+The GPIO Abstraction
+====================
+Support for GPIO pins in the fmc-bus environment is not very
+straightforward and deserves special discussion.
+While the general idea of a carrier-independent driver seems to fly,
+configuration of specific signals within the carrier needs at least
+some knowledge of the carrier itself.  For this reason, the specific
+driver can request to configure carrier-specific GPIO pins, numbered
+from 0 to at most 4095.  Configuration is performed by passing a
+pointer to an array of struct fmc_gpio items, as well as the length of
+the array. This is the data structure:
+        struct fmc_gpio {
+                char *carrier_name;
+                int gpio;
+                int _gpio;      /* internal use by the carrier */
+                int mode;       /* GPIOF_DIR_OUT etc, from <linux/gpio.h> */
+                int irqmode;    /* IRQF_TRIGGER_LOW and so on */
+        };
+By specifying a carrier_name for each pin, the driver may access
+different pins in different carriers.  The gpio_config method is
+expected to return the number of pins successfully configured, ignoring
+requests for other carriers. However, if no pin is configured (because
+no structure at all refers to the current carrier_name), the operation
+returns an error so the caller will know that it is running under a
+yet-unsupported carrier.
+So, for example, a driver that has been developed and tested on both
+the SPEC and the SVEC may request configuration of two different GPIO
+pins, and expect one such configuration to succeed - if none succeeds
+it most likely means that the current carrier is a still-unknown one.
+If, however, your GPIO pin has a specific known role, you can pass a
+special number in the gpio field, using one of the following macros:
+        #define FMC_GPIO_RAW(x)         (x)             /* 4096 of them */
+        #define FMC_GPIO_IRQ(x)         ((x) + 0x1000)  /*  256 of them */
+        #define FMC_GPIO_LED(x)         ((x) + 0x1100)  /*  256 of them */
+        #define FMC_GPIO_KEY(x)         ((x) + 0x1200)  /*  256 of them */
+        #define FMC_GPIO_TP(x)          ((x) + 0x1300)  /*  256 of them */
+        #define FMC_GPIO_USER(x)        ((x) + 0x1400)  /*  256 of them */
+Use of virtual GPIO numbers (anything but FMC_GPIO_RAW) is allowed
+provided the carrier_name field in the data structure is left
+unspecified (NULL). Each carrier is responsible for providing a mapping
+between virtual and physical GPIO numbers. The carrier may then use the
+_gpio field to cache the result of this mapping.
+All carriers must map their I/O lines to the sets above starting from
+zero.  The SPEC, for example, maps interrupt pins 0 and 1, and test
+points 0 through 3 (even if the test points on the PCB are called
+5,6,7,8).
+If, for example, a driver requires a free LED and a test point (for a
+scope probe to be plugged at some point during development) it may ask
+for FMC_GPIO_LED(0) and FMC_GPIO_TP(0). Each carrier will provide
+suitable GPIO pins.  Clearly, the person running the drivers will know
+the order used by the specific carrier driver in assigning leds and
+testpoints, so to make a carrier-dependent use of the diagnostic tools.
+In theory, some form of autodetection should be possible: a driver like
+the wr-nic (which uses IRQ(1) on the SPEC card) should configure
+IRQ(0), make a test with software-generated interrupts and configure
+IRQ(1) if the test fails. This probing step should be used because even
+if the wr-nic gateware is known to use IRQ1 on the SPEC, the driver
+should be carrier-independent and thus use IRQ(0) as a first bet -
+actually, the knowledge that IRQ0 may fail is carrier-dependent
+information, but using it doesn't make the driver unsuitable for other
+carriers.
+The return value of gpio_config is defined as follows:
+   * If no pin in the array can be used by the carrier, `-ENODEV'.
+   * If at least one virtual GPIO number cannot be mapped, `-ENOENT'.
+   * On success, 0 or positive. The value returned is the number of
+     high input bits (if no input is configured, the value for success
+     is 0).
+While I admit the procedure is not completely straightforward, it
+allows configuration, input and output with a single carrier operation.
+Given the typical use case of FMC devices, GPIO operations are not
+expected to ever by in hot paths, and GPIO access so fare has only been
+used to configure the interrupt pin, mode and polarity. Especially
+reading inputs is not expected to be common. If your device has GPIO
+capabilities in the hot path, you should consider using the kernel's
+GPIO mechanisms.
diff --git a/Documentation/fmc/fmc-chardev.txt b/Documentation/fmc/fmc-chardev.txt
new file mode 100644
index 000000000000..d9ccb278e597
--- /dev/null
+++ b/Documentation/fmc/fmc-chardev.txt
@@ -0,0 +1,64 @@
+fmc-chardev
+===========
+This is a simple generic driver, that allows user access by means of a
+character device (actually, one for each mezzanine it takes hold of).
+The char device is created as a misc device. Its name in /dev (as
+created by udev) is the same name as the underlying FMC device. Thus,
+the name can be a silly fmc-0000 look-alike if the device has no
+identifiers nor bus_id, a more specific fmc-0400 if the device has a
+bus-specific address but no associated name, or something like
+fdelay-0400 if the FMC core can rely on both a mezzanine name and a bus
+address.
+Currently the driver only supports read and write: you can lseek to the
+desired address and read or write a register.
+The driver assumes all registers are 32-bit in size, and only accepts a
+single read or write per system call. However, as a result of Unix read
+and write semantics, users can simply fread or fwrite bigger areas in
+order to dump or store bigger memory areas.
+There is currently no support for mmap, user-space interrupt management
+and DMA buffers. They may be added in later versions, if the need
+arises.
+The example below shows raw access to a SPEC card programmed with its
+golden FPGA file, that features an SDB structure at offset 256 - i.e.
+64 words.  The mezzanine's EEPROM in this case is not programmed, so the
+default name is fmc-<bus><devfn>, and there are two cards in the system:
+  spusa.root# insmod fmc-chardev.ko
+  [ 1073.339332] spec 0000:02:00.0: Driver has no ID: matches all
+  [ 1073.345051] spec 0000:02:00.0: Created misc device "fmc-0200"
+  [ 1073.350821] spec 0000:04:00.0: Driver has no ID: matches all
+  [ 1073.356525] spec 0000:04:00.0: Created misc device "fmc-0400"
+  spusa.root# ls -l /dev/fmc*
+  crw------- 1 root root 10, 58 Nov 20 19:23 /dev/fmc-0200
+  crw------- 1 root root 10, 57 Nov 20 19:23 /dev/fmc-0400
+  spusa.root# dd bs=4 skip=64 count=1 if=/dev/fmc-0200 2> /dev/null | od -t x1z
+  0000000 2d 42 44 53                                      >-BDS<
+  0000004
+The simple program tools/fmc-mem in this package can access an FMC char
+device and read or write a word or a whole area.  Actually, the program
+is not specific to FMC at all, it just uses lseek, read and write.
+Its first argument is the device name, the second the offset, the third
+(if any) the value to write and the optional last argument that must
+begin with "+" is the number of bytes to read or write.  In case of
+repeated reading data is written to stdout; repeated writes read from
+stdin and the value argument is ignored.
+The following examples show reading the SDB magic number and the first
+SDB record from a SPEC device programmed with its golden image:
+     spusa.root# ./fmc-mem /dev/fmc-0200 100
+     5344422d
+     spusa.root# ./fmc-mem /dev/fmc-0200 100 +40 | od -Ax -t x1z
+     000000 2d 42 44 53 00 01 02 00 00 00 00 00 00 00 00 00  >-BDS............<
+     000010 00 00 00 00 ff 01 00 00 00 00 00 00 51 06 00 00  >............Q...<
+     000020 c9 42 a5 e6 02 00 00 00 11 05 12 20 2d 34 42 57  >.B......... -4BW<
+     000030 73 6f 72 43 72 61 62 73 49 53 47 2d 00 20 20 20  >sorCrabsISG-.   <
+     000040
diff --git a/Documentation/fmc/fmc-fakedev.txt b/Documentation/fmc/fmc-fakedev.txt
new file mode 100644
index 000000000000..e85b74a4ae30
--- /dev/null
+++ b/Documentation/fmc/fmc-fakedev.txt
@@ -0,0 +1,36 @@
+fmc-fakedev
+===========
+This package includes a software-only device, called fmc-fakedev, which
+is able to register up to 4 mezzanines (by default it registers one).
+Unlike the SPEC driver, which creates an FMC device for each PCI cards
+it manages, this module creates a single instance of its set of
+mezzanines.
+It is meant as the simplest possible example of how a driver should be
+written, and it includes a fake EEPROM image (built using the tools
+described in *note FMC Identification::),, which by default is
+replicated for each fake mezzanine.
+You can also use this device to verify the match algorithms, by asking
+it to test your own EEPROM image. You can provide the image by means of
+the eeprom= module parameter: the new EEPROM image is loaded, as usual,
+by means of the firmware loader.  This example shows the defaults and a
+custom EEPROM image:
+     spusa.root# insmod fmc-fakedev.ko
+     [   99.971247]  fake-fmc-carrier: mezzanine 0
+     [   99.975393]       Manufacturer: fake-vendor
+     [   99.979624]       Product name: fake-design-for-testing
+     spusa.root# rmmod fmc-fakedev
+     spusa.root# insmod fmc-fakedev.ko eeprom=fdelay-eeprom.bin
+     [  121.447464]  fake-fmc-carrier: Mezzanine 0: eeprom "fdelay-eeprom.bin"
+     [  121.462725]  fake-fmc-carrier: mezzanine 0
+     [  121.466858]       Manufacturer: CERN
+     [  121.470477]       Product name: FmcDelay1ns4cha
+     spusa.root# rmmod fmc-fakedev
+After loading the device, you can use the write_ee method do modify its
+own internal fake EEPROM: whenever the image is overwritten starting at
+offset 0, the module will unregister and register again the FMC device.
+This is shown in fmc-write-eeprom.txt
diff --git a/Documentation/fmc/fmc-trivial.txt b/Documentation/fmc/fmc-trivial.txt
new file mode 100644
index 000000000000..d1910bc67159
--- /dev/null
+++ b/Documentation/fmc/fmc-trivial.txt
@@ -0,0 +1,17 @@
+fmc-trivial
+===========
+The simple module fmc-trivial is just a simple client that registers an
+interrupt handler. I used it to verify the basic mechanism of the FMC
+bus and how interrupts worked.
+The module implements the generic FMC parameters, so it can program a
+different gateware file in each card. The whole list of parameters it
+accepts are:
+`busid='
+`gateware='
+     Generic parameters. See mezzanine.txt
+This driver is worth reading, in my opinion.
diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt
new file mode 100644
index 000000000000..44a3bc678bf0
--- /dev/null
+++ b/Documentation/fmc/fmc-write-eeprom.txt
@@ -0,0 +1,125 @@
+fmc-write-eeprom
+================
+This module is designed to load a binary file from /lib/firmware and to
+write it to the internal EEPROM of the mezzanine card. This driver uses
+the `busid' generic parameter.
+Overwriting the EEPROM is not something you should do daily, and it is
+expected to only happen during manufacturing. For this reason, the
+module makes it unlikely for the random user to change a working EEPROM.
+The module takes the following measures:
+   * It accepts a `file=' argument (within /lib/firmware) and if no
+     such argument is received, it doesn't write anything to EEPROM
+     (i.e. there is no default file name).
+   * If the file name ends with `.bin' it is written verbatim starting
+     at offset 0.
+   * If the file name ends with `.tlv' it is interpreted as
+     type-length-value (i.e., it allows writev(2)-like operation).
+   * If the file name doesn't match any of the patterns above, it is
+     ignored and no write is performed.
+   * Only cards listed with `busid=' are written to. If no busid is
+     specified, no programming is done (and the probe function of the
+     driver will fail).
+Each TLV tuple is formatted in this way: the header is 5 bytes,
+followed by data. The first byte is `w' for write, the next two bytes
+represent the address, in little-endian byte order, and the next two
+represent the data length, in little-endian order. The length does not
+include the header (it is the actual number of bytes to be written).
+This is a real example: that writes 5 bytes at position 0x110:
+        spusa.root# od -t x1 -Ax /lib/firmware/try.tlv
+        000000 77 10 01 05 00 30 31 32 33 34
+        00000a
+        spusa.root# insmod /tmp/fmc-write-eeprom.ko busid=0x0200 file=try.tlv
+        [19983.391498] spec 0000:03:00.0: write 5 bytes at 0x0110
+        [19983.414615] spec 0000:03:00.0: write_eeprom: success
+Please note that you'll most likely want to use SDBFS to build your
+EEPROM image, at least if your mezzanines are being used in the White
+Rabbit environment. For this reason the TLV format is not expected to
+be used much and is not expected to be developed further.
+If you want to try reflashing fake EEPROM devices, you can use the
+fmc-fakedev.ko module (see *note fmc-fakedev::).  Whenever you change
+the image starting at offset 0, it will deregister and register again
+after two seconds.  Please note, however, that if fmc-write-eeprom is
+still loaded, the system will associate it to the new device, which
+will be reprogrammed and thus will be unloaded after two seconds.  The
+following example removes the module after it reflashed fakedev the
+first time.
+     spusa.root# insmod fmc-fakedev.ko
+        [   72.984733]  fake-fmc: Manufacturer: fake-vendor
+        [   72.989434]  fake-fmc: Product name: fake-design-for-testing
+        spusa.root# insmod fmc-write-eeprom.ko busid=0 file=fdelay-eeprom.bin; \
+            rmmod fmc-write-eeprom
+        [  130.874098]  fake-fmc: Matching a generic driver (no ID)
+        [  130.887845]  fake-fmc: programming 6155 bytes
+        [  130.894567]  fake-fmc: write_eeprom: success
+        [  132.895794]  fake-fmc: Manufacturer: CERN
+        [  132.899872]  fake-fmc: Product name: FmcDelay1ns4cha
+Writing to the EEPROM
+=====================
+Once you have created a binary file for your EEPROM, you can write it
+to the storage medium using the fmc-write-eeprom (See *note
+fmc-write-eeprom::, while relying on a carrier driver.  The procedure
+here shown here uses the SPEC driver
+(`http://www.ohwr.org/projects/spec-sw').
+The example assumes no driver is already loaded (actually, I unloaded
+them by hand as everything loads automatically at boot time after you
+installed the modules), and shows kernel messages together with
+commands. Here the prompt is spusa.root# and two SPEC cards are plugged
+in the system.
+     spusa.root# insmod fmc.ko
+     spusa.root# insmod spec.ko
+     [13972.382818] spec 0000:02:00.0:  probe for device 0002:0000
+     [13972.392773] spec 0000:02:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes
+     [13972.591388] spec 0000:02:00.0: FPGA programming successful
+     [13972.883011] spec 0000:02:00.0: EEPROM has no FRU information
+     [13972.888719] spec 0000:02:00.0: No device_id filled, using index
+     [13972.894676] spec 0000:02:00.0: No mezzanine_name found
+     [13972.899863] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init
+     [13972.906578] spec 0000:04:00.0:  probe for device 0004:0000
+     [13972.916509] spec 0000:04:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes
+     [13973.115096] spec 0000:04:00.0: FPGA programming successful
+     [13973.401798] spec 0000:04:00.0: EEPROM has no FRU information
+     [13973.407474] spec 0000:04:00.0: No device_id filled, using index
+     [13973.413417] spec 0000:04:00.0: No mezzanine_name found
+     [13973.418600] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init
+     spusa.root# ls /sys/bus/fmc/devices
+     fmc-0000  fmc-0001
+     spusa.root# insmod fmc-write-eeprom.ko busid=0x0200 file=fdelay-eeprom.bin
+     [14103.966259] spec 0000:02:00.0: Matching an generic driver (no ID)
+     [14103.975519] spec 0000:02:00.0: programming 6155 bytes
+     [14126.373762] spec 0000:02:00.0: write_eeprom: success
+     [14126.378770] spec 0000:04:00.0: Matching an generic driver (no ID)
+     [14126.384903] spec 0000:04:00.0: fmc_write_eeprom: no filename given: not programming
+     [14126.392600] fmc_write_eeprom: probe of fmc-0001 failed with error -2
+Reading back the EEPROM
+=======================
+In order to read back the binary content of the EEPROM of your
+mezzanine device, the bus creates a read-only sysfs file called eeprom
+for each mezzanine it knows about:
+   spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom
+   -r--r--r-- 1 root root 8192 Apr  9 16:53 FmcDelay1ns4cha-f001/eeprom
+   -r--r--r-- 1 root root 8192 Apr  9 17:19 fake-design-for-testing-f002/eeprom
+   -r--r--r-- 1 root root 8192 Apr  9 17:19 fake-design-for-testing-f003/eeprom
+   -r--r--r-- 1 root root 8192 Apr  9 17:19 fmc-f004/eeprom
diff --git a/Documentation/fmc/identifiers.txt b/Documentation/fmc/identifiers.txt
new file mode 100644
index 000000000000..3bb577ff0d52
--- /dev/null
+++ b/Documentation/fmc/identifiers.txt
@@ -0,0 +1,168 @@
+FMC Identification
+******************
+The FMC standard requires every compliant mezzanine to carry
+identification information in an I2C EEPROM.  The information must be
+laid out according to the "IPMI Platform Management FRU Information",
+where IPMI is a lie I'd better not expand, and FRU means "Field
+Replaceable Unit".
+The FRU information is an intricate unreadable binary blob that must
+live at offset 0 of the EEPROM, and typically extends for a few hundred
+bytes. The standard allows the application to use all the remaining
+storage area of the EEPROM as it wants.
+This chapter explains how to create your own EEPROM image and how to
+write it in your mezzanine, as well as how devices and drivers are
+paired at run time.  EEPROM programming uses tools that are part of this
+package and SDB (part of the fpga-config-space package).
+The first sections are only interesting for manufacturers who need to
+write the EEPROM. If you are just a software developer writing an FMC
+device or driver, you may jump straight to *note SDB Support::.
+Building the FRU Structure
+==========================
+If you want to know the internals of the FRU structure and despair, you
+can retrieve the document from
+`http://download.intel.com/design/servers/ipmi/FRU1011.pdf' .  The
+standard is awful and difficult without reason, so we only support the
+minimum mandatory subset - we create a simple structure and parse it
+back at run time, but we are not able to either generate or parse more
+arcane features like non-english languages and 6-bit text.  If you need
+more items of the FRU standard for your boards, please submit patches.
+This package includes the Python script that Matthieu Cattin wrote to
+generate the FRU binary blob, based on an helper libipmi by Manohar
+Vanga and Matthieu himself.  I changed the test script to receive
+parameters from the command line or from the environment (the command
+line takes precedence)
+To make a long story short, in order to build a standard-compliant
+binary file to be burned in your EEPROM, you need the following items:
+        Environment    Opt     Official Name          Default
+---------------------------------------------------------------------
+        FRU_VENDOR     -v      "Board Manufacturer"   fmc-example
+        FRU_NAME       -n      "Board Product Name"   mezzanine
+        FRU_SERIAL     -s      `Board Serial Number"  0001
+        FRU_PART       -p      "Board Part Number"    sample-part
+        FRU_OUTPUT     -o      not applicable         /dev/stdout
+The "Official Name" above is what you find in the FRU official
+documentation, chapter 11, page 7 ("Board Info Area Format").  The
+output option is used to save the generated binary to a specific file
+name instead of stdout.
+You can pass the items to the FRU generator either in the environment
+or on the command line.  This package has currently no support for
+specifying power consumption or such stuff, but I plan to add it as
+soon as I find some time for that.
+FIXME: consumption etc for FRU are here or in PTS?
+The following example creates a binary image for a specific board:
+        ./tools/fru-generator -v CERN -n FmcAdc100m14b4cha \
+               -s HCCFFIA___-CR000003 -p EDA-02063-V5-0 > eeprom.bin
+The following example shows a script that builds several binary EEPROM
+images for a series of boards, changing the serial number for each of
+them. The script uses a mix of environment variables and command line
+options, and uses the same string patterns shown above.
+        #!/bin/sh
+        export FRU_VENDOR="CERN"
+        export FRU_NAME="FmcAdc100m14b4cha"
+        export FRU_PART="EDA-02063-V5-0"
+        serial="HCCFFIA___-CR"
+        for number in $(seq 1 50); do
+           # build number-string "ns"
+           ns="$(printf %06d $number)"
+           ./fru-generator -s "${serial}${ns}" > eeprom-${ns}.bin
+        done
+Using SDB-FS in the EEPROM
+==========================
+If you want to use SDB as a filesystem in the EEPROM device within the
+mezzanine, you should create one such filesystem using gensdbfs, from
+the fpga-config-space package on OHWR.
+By using an SBD filesystem you can cluster several files in a single
+EEPROM, so both the host system and a soft-core running in the FPGA (if
+any) can access extra production-time information.
+We chose to use SDB as a storage filesystem because the format is very
+simple, and both the host system and the soft-core will likely already
+include support code for such format. The SDB library offered by the
+fpga-config-space is less than 1kB under LM32, so it proves quite up to
+the task.
+The SDB entry point (which acts as a directory listing) cannot live at
+offset zero in the flash device, because the FRU information must live
+there.  To avoid wasting precious storage space while still allowing
+for more-than-minimal FRU structures, the fmc.ko will look for the SDB
+record at address 256, 512 and 1024.
+In order to generate the complete EEPROM image you'll need a
+configuration file for gensdbfs: you tell the program where to place
+the sdb entry point, and you must force the FRU data file to be placed
+at the beginning of the storage device. If needed, you can also place
+other files at a special offset (we sometimes do it for backward
+compatibility with drivers we wrote before implementing SDB for flash
+memory).
+The directory tools/sdbfs of this package includes a well-commented
+example that you may want to use as a starting point (the comments are
+in the file called -SDB-CONFIG-).  Reading documentation for gensdbfs
+is a suggested first step anyways.
+This package (generic FMC bus support) only accesses two files in the
+EEPROM: the FRU information, at offset zero, with a suggested filename
+of IPMI-FRU and the short name for the mezzanine, in a file called
+name. The IPMI-FRU name is not mandatory, but a strongly suggested
+choice; the name filename is mandatory, because this is the preferred
+short name used by the FMC core.  For example, a name of "fdelay" may
+supplement a Product Name like "FmcDelay1ns4cha" - exactly as
+demonstrated in `tools/sdbfs'.
+Note: SDB access to flash memory is not yet supported, so the short
+name currently in use is just the "Product Name" FRU string.
+The example in tools/sdbfs includes an extra file, that is needed by
+the fine-delay driver, and must live at a known address of 0x1800.  By
+running gensdbfs on that directory you can output your binary EEPROM
+image (here below spusa$ is the shell prompt):
+        spusa$ ../fru-generator -v CERN -n FmcDelay1ns4cha -s proto-0 \
+                      -p EDA-02267-V3 > IPMI-FRU
+        spusa$ ls -l
+        total 16
+        -rw-rw-r-- 1 rubini staff 975 Nov 19 18:08 --SDB-CONFIG--
+        -rw-rw-r-- 1 rubini staff 216 Nov 19 18:13 IPMI-FRU
+        -rw-rw-r-- 1 rubini staff  11 Nov 19 18:04 fd-calib
+        -rw-rw-r-- 1 rubini staff   7 Nov 19 18:04 name
+        spusa$ sudo gensdbfs . /lib/firmware/fdelay-eeprom.bin
+        spusa$ sdb-read -l -e 0x100 /lib/firmware/fdelay-eeprom.bin
+        /home/rubini/wip/sdbfs/userspace/sdb-read: listing format is to be defined
+        46696c6544617461:2e202020  00000100-000018ff .
+        46696c6544617461:6e616d65  00000200-00000206 name
+        46696c6544617461:66642d63  00001800-000018ff fd-calib
+        46696c6544617461:49504d49  00000000-000000d7 IPMI-FRU
+        spusa$ ../fru-dump /lib/firmware/fdelay-eeprom.bin
+        /lib/firmware/fdelay-eeprom.bin: manufacturer: CERN
+        /lib/firmware/fdelay-eeprom.bin: product-name: FmcDelay1ns4cha
+        /lib/firmware/fdelay-eeprom.bin: serial-number: proto-0
+        /lib/firmware/fdelay-eeprom.bin: part-number: EDA-02267-V3
+As expected, the output file is both a proper sdbfs object and an IPMI
+FRU information blob. The fd-calib file lives at offset 0x1800 and is
+over-allocated to 256 bytes, according to the configuration file for
+gensdbfs.
diff --git a/Documentation/fmc/mezzanine.txt b/Documentation/fmc/mezzanine.txt
new file mode 100644
index 000000000000..87910dbfc91e
--- /dev/null
+++ b/Documentation/fmc/mezzanine.txt
@@ -0,0 +1,123 @@
+FMC Driver
+**********
+An FMC driver is concerned with the specific mezzanine and associated
+gateware. As such, it is expected to be independent of the carrier
+being used: it will perform I/O accesses only by means of
+carrier-provided functions.
+The matching between device and driver is based on the content of the
+EEPROM (as mandated by the FMC standard) or by the actual cores
+configured in the FPGA; the latter technique is used when the FPGA is
+already programmed when the device is registered to the bus core.
+In some special cases it is possible for a driver to directly access
+FPGA registers, by means of the `fpga_base' field of the device
+structure. This may be needed for high-bandwidth peripherals like fast
+ADC cards. If the device module registered a remote device (for example
+by means of Etherbone), the `fpga_base' pointer will be NULL.
+Therefore, drivers must be ready to deal with NULL base pointers, and
+fail gracefully.  Most driver, however, are not expected to access the
+pointer directly but run fmc_readl and fmc_writel instead, which will
+work in any case.
+In even more special cases, the driver may access carrier-specific
+functionality: the `carrier_name' string allows the driver to check
+which is the current carrier and make use of the `carrier_data'
+pointer.  We chose to use carrier names rather than numeric identifiers
+for greater flexibility, but also to avoid a central registry within
+the `fmc.h' file - we hope other users will exploit our framework with
+their own carriers.  An example use of carrier names is in GPIO setup
+(see *note The GPIO Abstraction::), although the name match is not
+expected to be performed by the driver.  If you depend on specific
+carriers, please check the carrier name and fail gracefully if your
+driver finds it is running in a yet-unknown-to-it environment.
+ID Table
+========
+Like most other Linux drivers, and FMC driver must list all the devices
+which it is able to drive.  This is usually done by means of a device
+table, but in FMC we can match hardware based either on the contents of
+their EEPROM or on the actual FPGA cores that can be enumerated.
+Therefore, we have two tables of identifiers.
+Matching of FRU information depends on two names, the manufacturer (or
+vendor) and the device (see *note FMC Identification::); for
+flexibility during production (i.e. before writing to the EEPROM) the
+bus supports a catch-all driver that specifies NULL strings. For this
+reason, the table is specified as pointer-and-length, not a a
+null-terminated array - the entry with NULL names can be a valid entry.
+Matching on FPGA cores depends on two numeric fields: the 64-bit vendor
+number and the 32-bit device number. Support for matching based on
+class is not yet implemented.  Each device is expected to be uniquely
+identified by an array of cores (it matches if all of the cores are
+instantiated), and for consistency the list is passed as
+pointer-and-length.  Several similar devices can be driven by the same
+driver, and thus the driver specifies and array of such arrays.
+The complete set of involved data structures is thus the following:
+        struct fmc_fru_id { char *manufacturer; char *product_name; };
+        struct fmc_sdb_one_id { uint64_t vendor; uint32_t device; };
+        struct fmc_sdb_id { struct fmc_sdb_one_id *cores; int cores_nr; };
+        struct fmc_device_id {
+                struct fmc_fru_id *fru_id; int fru_id_nr;
+                struct fmc_sdb_id *sdb_id; int sdb_id_nr;
+        };
+A better reference, with full explanation, is the <linux/fmc.h> header.
+Module Parameters
+=================
+Most of the FMC drivers need the same set of kernel parameters. This
+package includes support to implement common parameters by means of
+fields in the `fmc_driver' structure and simple macro definitions.
+The parameters are carrier-specific, in that they rely on the busid
+concept, that varies among carriers. For the SPEC, the identifier is a
+PCI bus and devfn number, 16 bits wide in total; drivers for other
+carriers will most likely offer something similar but not identical,
+and some code duplication is unavoidable.
+This is the list of parameters that are common to several modules to
+see how they are actually used, please look at spec-trivial.c.
+`busid='
+     This is an array of integers, listing carrier-specific
+     identification numbers. For PIC, for example, `0x0400' represents
+     bus 4, slot 0.  If any such ID is specified, the driver will only
+     accept to drive cards that appear in the list (even if the FMC ID
+     matches). This is accomplished by the validate carrier method.
+`gateware='
+     The argument is an array of strings. If no busid= is specified,
+     the first string of gateware= is used for all cards; otherwise the
+     identifiers and gateware names are paired one by one, in the order
+     specified.
+`show_sdb='
+     For modules supporting it, this parameter asks to show the SDB
+     internal structure by means of kernel messages. It is disabled by
+     default because those lines tend to hide more important messages,
+     if you look at the system console while loading the drivers.
+     Note: the parameter is being obsoleted, because fmc.ko itself now
+     supports dump_sdb= that applies to every client driver.
+For example, if you are using the trivial driver to load two different
+gateware files to two different cards, you can use the following
+parameters to load different binaries to the cards, after looking up
+the PCI identifiers. This has been tested with a SPEC carrier.
+        insmod fmc-trivial.ko \
+                              busid=0x0200,0x0400 \
+                              gateware=fmc/fine-delay.bin,fmc/simple-dio.bin
+Please note that not all sub-modules support all of those parameters.
+You can use modinfo to check what is supported by each module.
diff --git a/Documentation/fmc/parameters.txt b/Documentation/fmc/parameters.txt
new file mode 100644
index 000000000000..59edf088e3a4
--- /dev/null
+++ b/Documentation/fmc/parameters.txt
@@ -0,0 +1,56 @@
+Module Parameters in fmc.ko
+***************************
+The core driver receives two module parameters, meant to help debugging
+client modules. Both parameters can be modified by writing to
+/sys/module/fmc/parameters/, because they are used when client drivers
+are devices are registered, not when fmc.ko is loaded.
+`dump_eeprom='
+     If not zero, the parameter asks the bus controller to dump the
+     EEPROM of any device that is registered, using printk.
+`dump_sdb='
+     If not zero, the parameter prints the SDB tree of every FPGA it is
+     loaded by fmc_reprogram(). If greater than one, it asks to dump
+     the binary content of SDB records.  This currently only dumps the
+     top-level SDB array, though.
+EEPROM dumping avoids repeating lines, since most of the contents is
+usually empty and all bits are one or zero. This is an example of the
+output:
+        [ 6625.850480] spec 0000:02:00.0: FPGA programming successful
+        [ 6626.139949] spec 0000:02:00.0: Manufacturer: CERN
+        [ 6626.144666] spec 0000:02:00.0: Product name: FmcDelay1ns4cha
+        [ 6626.150370] FMC: mezzanine 0: 0000:02:00.0 on SPEC
+        [ 6626.155179] FMC: dumping eeprom 0x2000 (8192) bytes
+        [ 6626.160087] 0000: 01 00 00 01  00 0b 00 f3  01 0a 00 a5  85 87 c4 43
+        [ 6626.167069] 0010: 45 52 4e cf  46 6d 63 44  65 6c 61 79  31 6e 73 34
+        [ 6626.174019] 0020: 63 68 61 c7  70 72 6f 74  6f 2d 30 cc  45 44 41 2d
+        [ 6626.180975] 0030: 30 32 32 36  37 2d 56 33  da 32 30 31  32 2d 31 31
+        [...]
+        [ 6626.371366] 0200: 66 64 65 6c  61 79 0a 00  00 00 00 00  00 00 00 00
+        [ 6626.378359] 0210: 00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
+        [ 6626.385361] [...]
+        [ 6626.387308] 1800: 70 6c 61 63  65 68 6f 6c  64 65 72 ff  ff ff ff ff
+        [ 6626.394259] 1810: ff ff ff ff  ff ff ff ff  ff ff ff ff  ff ff ff ff
+        [ 6626.401250] [...]
+The dump of SDB looks like the following; the example shows the simple
+golden gateware for the SPEC card, removing the leading timestamps to
+fit the page:
+        spec 0000:02:00.0: SDB: 00000651:e6a542c9 WB4-Crossbar-GSI
+        spec 0000:02:00.0: SDB: 0000ce42:ff07fc47 WR-Periph-Syscon (00000000-000000ff)
+        FMC: mezzanine 0: 0000:02:00.0 on SPEC
+        FMC: poor dump of sdb first level:
+        0000: 53 44 42 2d  00 02 01 00  00 00 00 00  00 00 00 00
+        0010: 00 00 00 00  00 00 01 ff  00 00 00 00  00 00 06 51
+        0020: e6 a5 42 c9  00 00 00 02  20 12 05 11  57 42 34 2d
+        0030: 43 72 6f 73  73 62 61 72  2d 47 53 49  20 20 20 00
+        0040: 00 00 01 01  00 00 00 07  00 00 00 00  00 00 00 00
+        0050: 00 00 00 00  00 00 00 ff  00 00 00 00  00 00 ce 42
+        0060: ff 07 fc 47  00 00 00 01  20 12 03 05  57 52 2d 50
+        0070: 65 72 69 70  68 2d 53 79  73 63 6f 6e  20 20 20 01
diff --git a/Documentation/hwmon/ds1621 b/Documentation/hwmon/ds1621
index 5e97f333c4df..896cdc972ca8 100644
--- a/Documentation/hwmon/ds1621
+++ b/Documentation/hwmon/ds1621
@@ -2,16 +2,30 @@ Kernel driver ds1621
 ====================
 Supported chips:
-  * Dallas Semiconductor DS1621
+  * Dallas Semiconductor / Maxim Integrated DS1621
    Prefix: 'ds1621'
-    Addresses scanned: I2C 0x48 - 0x4f
+    Addresses scanned: none
-    Datasheet: Publicly available at the Dallas Semiconductor website
+    Datasheet: Publicly available from www.maximintegrated.com
-               http://www.dalsemi.com/
  * Dallas Semiconductor DS1625
-    Prefix: 'ds1621'
+    Prefix: 'ds1625'
-    Addresses scanned: I2C 0x48 - 0x4f
+    Addresses scanned: none
-    Datasheet: Publicly available at the Dallas Semiconductor website
+    Datasheet: Publicly available from www.datasheetarchive.com
-               http://www.dalsemi.com/
+  * Maxim Integrated DS1631
+    Prefix: 'ds1631'
+    Addresses scanned: none
+    Datasheet: Publicly available from www.maximintegrated.com
+  * Maxim Integrated DS1721
+    Prefix: 'ds1721'
+    Addresses scanned: none
+    Datasheet: Publicly available from www.maximintegrated.com
+  * Maxim Integrated DS1731
+    Prefix: 'ds1731'
+    Addresses scanned: none
+    Datasheet: Publicly available from www.maximintegrated.com
 Authors:
        Christian W. Zuckschwerdt <zany@triq.net>
@@ -59,5 +73,115 @@ any of the limits have ever been met or exceeded since last power-up or
 reset. Be aware: When testing, it showed that the status of Tout can change
 with neither of the alarms set.
-Temperature conversion of the DS1621 takes up to 1000ms; internal access to
+Since there is no version or vendor identification register, there is
-non-volatile registers may last for 10ms or below.
+no unique identification for these devices. Therefore, explicit device
+instantiation is required for correct device identification and functionality
+(one device per address in this address range: 0x48..0x4f).
+The DS1625 is pin compatible and functionally equivalent with the DS1621,
+but the DS1621 is meant to replace it. The DS1631, DS1721, and DS1731 are
+also pin compatible with the DS1621 and provide multi-resolution support.
+Additionally, the DS1721 data sheet says the temperature flags (THF and TLF)
+are used internally, however, these flags do get set and cleared as the actual
+temperature crosses the min or max settings (which by default are set to 75
+and 80 degrees respectively).
+Temperature Conversion:
+-----------------------
+DS1621 - 750ms (older devices may take up to 1000ms)
+DS1625 - 500ms
+DS1631 - 93ms..750ms for 9..12 bits resolution, respectively.
+DS1721 - 93ms..750ms for 9..12 bits resolution, respectively.
+DS1731 - 93ms..750ms for 9..12 bits resolution, respectively.
+Note:
+On the DS1621, internal access to non-volatile registers may last for 10ms
+or less (unverified on the other devices).
+Temperature Accuracy:
+---------------------
+DS1621: +/- 0.5 degree Celsius (from 0 to +70 degrees)
+DS1625: +/- 0.5 degree Celsius (from 0 to +70 degrees)
+DS1631: +/- 0.5 degree Celsius (from 0 to +70 degrees)
+DS1721: +/- 1.0 degree Celsius (from -10 to +85 degrees)
+DS1731: +/- 1.0 degree Celsius (from -10 to +85 degrees)
+Note:
+Please refer to the device datasheets for accuracy at other temperatures.
+Temperature Resolution:
+-----------------------
+As mentioned above, the DS1631, DS1721, and DS1731 provide multi-resolution
+support, which is achieved via the R0 and R1 config register bits, where:
+R0..R1
+------
+ 0  0 => 9 bits, 0.5 degrees Celcius
+ 1  0 => 10 bits, 0.25 degrees Celcius
+ 0  1 => 11 bits, 0.125 degrees Celcius
+ 1  1 => 12 bits, 0.0625 degrees Celcius
+Note:
+At initial device power-on, the default resolution is set to 12-bits.
+The resolution mode for the DS1631, DS1721, or DS1731 can be changed from
+userspace, via the device 'update_interval' sysfs attribute. This attribute
+will normalize the range of input values to the device maximum resolution
+values defined in the datasheet as follows:
+Resolution    Conversion Time    Input Range
+ (C/LSB)       (msec)             (msec)
+------------------------------------------------
+0.5             93.75              0....94
+0.25            187.5              95...187
+0.125           375                188..375
+0.0625          750                376..infinity
+------------------------------------------------
+The following examples show how the 'update_interval' attribute can be
+used to change the conversion time:
+$ cat update_interval
+750
+$ cat temp1_input
+22062
+$
+$ echo 300 > update_interval
+$ cat update_interval
+375
+$ cat temp1_input
+22125
+$
+$ echo 150 > update_interval
+$ cat update_interval
+188
+$ cat temp1_input
+22250
+$
+$ echo 1 > update_interval
+$ cat update_interval
+94
+$ cat temp1_input
+22000
+$
+$ echo 1000 > update_interval
+$ cat update_interval
+750
+$ cat temp1_input
+22062
+$
+As shown, the ds1621 driver automatically adjusts the 'update_interval'
+user input, via a step function. Reading back the 'update_interval' value
+after a write operation provides the conversion time used by the device.
+Mathematically, the resolution can be derived from the conversion time
+via the following function:
+   g(x) = 0.5 * [minimum_conversion_time/x]
+where:
+ -> 'x' = the output from 'update_interval'
+ -> 'g(x)' = the resolution in degrees C per LSB.
+ -> 93.75ms = minimum conversion time
diff --git a/Documentation/hwmon/g762 b/Documentation/hwmon/g762
new file mode 100644
index 000000000000..923db9c5b5bc
--- /dev/null
+++ b/Documentation/hwmon/g762
@@ -0,0 +1,65 @@
+Kernel driver g762
+==================
+The GMT G762 Fan Speed PWM Controller is connected directly to a fan
+and performs closed-loop or open-loop control of the fan speed. Two
+modes - PWM or DC - are supported by the device.
+For additional information, a detailed datasheet is available at
+http://natisbad.org/NAS/ref/GMT_EDS-762_763-080710-0.2.pdf. sysfs
+bindings are described in Documentation/hwmon/sysfs-interface.
+The following entries are available to the user in a subdirectory of
+/sys/bus/i2c/drivers/g762/ to control the operation of the device.
+This can be done manually using the following entries but is usually
+done via a userland daemon like fancontrol.
+Note that those entries do not provide ways to setup the specific
+hardware characteristics of the system (reference clock, pulses per
+fan revolution, ...); Those can be modified via devicetree bindings
+documented in Documentation/devicetree/bindings/hwmon/g762.txt or
+using a specific platform_data structure in board initialization
+file (see include/linux/platform_data/g762.h).
+  fan1_target: set desired fan speed. This only makes sense in closed-loop
+            fan speed control (i.e. when pwm1_enable is set to 2).
+  fan1_input: provide current fan rotation value in RPM as reported by
+            the fan to the device.
+  fan1_div: fan clock divisor. Supported value are 1, 2, 4 and 8.
+  fan1_pulses: number of pulses per fan revolution. Supported values
+            are 2 and 4.
+  fan1_fault: reports fan failure, i.e. no transition on fan gear pin for
+            about 0.7s (if the fan is not voluntarily set off).
+  fan1_alarm: in closed-loop control mode, if fan RPM value is 25% out
+            of the programmed value for over 6 seconds 'fan1_alarm' is
+            set to 1.
+  pwm1_enable: set current fan speed control mode i.e. 1 for manual fan
+            speed control (open-loop) via pwm1 described below, 2 for
+            automatic fan speed control (closed-loop) via fan1_target
+            above.
+  pwm1_mode: set or get fan driving mode: 1 for PWM mode, 0 for DC mode.
+  pwm1: get or set PWM fan control value in open-loop mode. This is an
+            integer value between 0 and 255. 0 stops the fan, 255 makes
+            it run at full speed.
+Both in PWM mode ('pwm1_mode' set to 1) and DC mode ('pwm1_mode' set to 0),
+when current fan speed control mode is open-loop ('pwm1_enable' set to 1),
+the fan speed is programmed by setting a value between 0 and 255 via 'pwm1'
+entry (0 stops the fan, 255 makes it run at full speed). In closed-loop mode
+('pwm1_enable' set to 2), the expected rotation speed in RPM can be passed to
+the chip via 'fan1_target'. In closed-loop mode, the target speed is compared
+with current speed (available via 'fan1_input') by the device and a feedback
+is performed to match that target value. The fan speed value is computed
+based on the parameters associated with the physical characteristics of the
+system: a reference clock source frequency, a number of pulses per fan
+revolution, etc.
+Note that the driver will update its values at most once per second.
diff --git a/Documentation/hwmon/ina2xx b/Documentation/hwmon/ina2xx
index 03444f9d833f..4223c2d3b508 100644
--- a/Documentation/hwmon/ina2xx
+++ b/Documentation/hwmon/ina2xx
@@ -44,4 +44,6 @@ The INA226 monitors both a shunt voltage drop and bus supply voltage.
 The INA230 is a high or low side current shunt and power monitor with an I2C
 interface. The INA230 monitors both a shunt voltage drop and bus supply voltage.
-The shunt value in micro-ohms can be set via platform data.
+The shunt value in micro-ohms can be set via platform data or device tree.
+Please refer to the Documentation/devicetree/bindings/i2c/ina2xx.txt for bindings
+if the device tree is used.
diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches
index 843751c41fea..46286460462b 100644
--- a/Documentation/hwmon/submitting-patches
+++ b/Documentation/hwmon/submitting-patches
@@ -27,8 +27,7 @@ increase the chances of your change being accepted.
  explicitly below the patch header.
 * If your patch (or the driver) is affected by configuration options such as
-  CONFIG_SMP or CONFIG_HOTPLUG, make sure it compiles for all configuration
+  CONFIG_SMP, make sure it compiles for all configuration variants.
-  variants.
 2. Adding functionality to existing drivers
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index d55b8ab2d10f..d29dea0f3232 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -24,6 +24,7 @@ Supported adapters:
  * Intel Lynx Point-LP (PCH)
  * Intel Avoton (SOC)
  * Intel Wellsburg (PCH)
+  * Intel Coleto Creek (PCH)
   Datasheets: Publicly available at the Intel website
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/Documentation/i2c/busses/i2c-piix4 b/Documentation/i2c/busses/i2c-piix4
index 1e6634f54c50..a370b2047cf3 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
+  * AMD Hudson-2, 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/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index 2c179613f81b..de139b18184a 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -80,6 +80,8 @@ Userspace can detect that a driver can report more total contacts than slots
 by noting that the largest supported BTN_TOOL_*TAP event is larger than the
 total number of type B slots reported in the absinfo for the ABS_MT_SLOT axis.
+The minimum value of the ABS_MT_SLOT axis must be 0.
 Protocol Example A
 ------------------
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 237acab169dd..2a5f0e14efa3 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -72,6 +72,7 @@ Code  Seq#(hex)	Include File		Comments
 0x06    all     linux/lp.h
 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
 0x12    all     linux/fs.h
                linux/blkpg.h
 0x1b    all     InfiniBand Subsystem    <http://infiniband.sourceforge.net/>
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 3f429ed8b3b8..e349f293cc98 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -165,7 +165,7 @@ Searching in menuconfig:
        Example:
                /hotplug
                This lists all config symbols that contain "hotplug",
-                e.g., HOTPLUG, HOTPLUG_CPU, MEMORY_HOTPLUG.
+                e.g., HOTPLUG_CPU, MEMORY_HOTPLUG.
        For search help, enter / followed TAB-TAB-TAB (to highlight
        <Help>) and Enter.  This will tell you that you can also use
@@ -174,6 +174,19 @@ Searching in menuconfig:
                /^hotplug
+        When searching, symbols are sorted thus:
+          - exact match first: an exact match is when the search matches
+            the complete symbol name;
+          - alphabetical order: when two symbols do not match exactly,
+            they are sorted in alphabetical order (in the user's current
+            locale).
+        For example: ^ATH.K matches:
+            ATH5K ATH9K ATH5K_AHB ATH5K_DEBUG [...] ATH6KL ATH6KL_DEBUG
+            [...] ATH9K_AHB ATH9K_BTCOEX_SUPPORT ATH9K_COMMON [...]
+        of which only ATH5K and ATH9K match exactly and so are sorted
+        first (and in alphabetical order), then come all other symbols,
+        sorted in alphabetical order.
 ______________________________________________________________________
 User interface options for 'menuconfig'
diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 9c7fd988e299..88d5a863712a 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -47,19 +47,12 @@ parameter. Optionally the size of the ELF header can also be passed
 when using the elfcorehdr=[size[KMG]@]offset[KMG] syntax.
-With the dump-capture kernel, you can access the memory image, or "old
+With the dump-capture kernel, you can access the memory image through
-memory," in two ways:
+/proc/vmcore. This exports the dump as an ELF-format file that you can
+write out using file copy commands such as cp or scp. Further, you can
- Through a /dev/oldmem device interface. A capture utility can read the
+use analysis tools such as the GNU Debugger (GDB) and the Crash tool to
-  device file and write out the memory in raw format. This is a raw dump
+debug the dump file. This method ensures that the dump pages are correctly
-  of memory. Analysis and capture tools must be intelligent enough to
+ordered.
-  determine where to look for the right information.
- Through /proc/vmcore. This exports the dump as an ELF-format file that
-  you can write out using file copy commands such as cp or scp. Further,
-  you can use analysis tools such as the GNU Debugger (GDB) and the Crash
-  tool to debug the dump file. This method ensures that the dump pages are
-  correctly ordered.
 Setup and Installation
@@ -423,18 +416,6 @@ the following command:
   cp /proc/vmcore <dump-file>
-You can also access dumped memory as a /dev/oldmem device for a linear
-and raw view. To create the device, use the following command:
-    mknod /dev/oldmem c 1 12
-Use the dd command with suitable options for count, bs, and skip to
-access specific portions of the dump.
-To see the entire memory, use the following command:
-   dd if=/dev/oldmem of=oldmem.001
 Analysis
 ========
@@ -461,14 +442,6 @@ format. Crash is available on Dave Anderson's site at the following URL:
   http://people.redhat.com/~anderson/
-To Do
-=====
-1) Provide relocatable kernels for all architectures to help in maintaining
-   multiple kernels for crash_dump, and the same kernel as the system kernel
-   can be used to capture the dump.
 Contact
 =======
diff --git a/Documentation/kernel-doc-nano-HOWTO.txt b/Documentation/kernel-doc-nano-HOWTO.txt
index 99b57abddf8a..acbc1a3d0d91 100644
--- a/Documentation/kernel-doc-nano-HOWTO.txt
+++ b/Documentation/kernel-doc-nano-HOWTO.txt
@@ -142,9 +142,10 @@ are:
 - Makefile
-  The targets 'sgmldocs', 'psdocs', 'pdfdocs', and 'htmldocs' are used
+  The targets 'xmldocs', 'psdocs', 'pdfdocs', and 'htmldocs' are used
-  to build DocBook files, PostScript files, PDF files, and html files
+  to build XML DocBook files, PostScript files, PDF files, and html files
-  in Documentation/DocBook.
+  in Documentation/DocBook. The older target 'sgmldocs' is equivalent
+  to 'xmldocs'.
 - Documentation/DocBook/Makefile
@@ -158,8 +159,8 @@ If you just want to read the ready-made books on the various
 subsystems (see Documentation/DocBook/*.tmpl), just type 'make
 psdocs', or 'make pdfdocs', or 'make htmldocs', depending on your
 preference.  If you would rather read a different format, you can type
-'make sgmldocs' and then use DocBook tools to convert
+'make xmldocs' and then use DocBook tools to convert
-Documentation/DocBook/*.sgml to a format of your choice (for example,
+Documentation/DocBook/*.xml to a format of your choice (for example,
 'db2html ...' if 'make htmldocs' was not defined).
 If you want to see man pages instead, you can do this:
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c3bfacb92910..15356aca938c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1129,11 +1129,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        The builtin appraise policy appraises all files
                        owned by uid=0.
-        ima_audit=      [IMA]
-                        Format: { "0" | "1" }
-                        0 -- integrity auditing messages. (Default)
-                        1 -- enable informational integrity auditing messages.
        ima_hash=       [IMA]
                        Format: { "sha1" | "md5" }
                        default: "sha1"
@@ -1158,6 +1153,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        inport.irq=     [HW] Inport (ATI XL and Microsoft) busmouse driver
                        Format: <irq>
+        int_pln_enable  [x86] Enable power limit notification interrupt
+        integrity_audit=[IMA]
+                        Format: { "0" | "1" }
+                        0 -- basic integrity auditing messages. (Default)
+                        1 -- additional integrity auditing messages.
        intel_iommu=    [DMAR] Intel IOMMU driver (DMAR) option
                on
                        Enable intel iommu driver.
@@ -1456,6 +1458,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        * dump_id: dump IDENTIFY data.
+                        * atapi_dmadir: Enable ATAPI DMADIR bridge support
                        If there are multiple matching configurations changing
                        the same attribute, the last one is used.
@@ -2677,9 +2681,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        Run specified binary instead of /init from the ramdisk,
                        used for early userspace startup. See initrd.
-        reboot=         [BUGS=X86-32,BUGS=ARM,BUGS=IA-64] Rebooting mode
+        reboot=         [KNL]
-                        Format: <reboot_mode>[,<reboot_mode2>[,...]]
+                        Format (x86 or x86_64):
-                        See arch/*/kernel/reboot.c or arch/*/kernel/process.c
+                                [w[arm] | c[old] | h[ard] | s[oft] | g[pio]] \
+                                [[,]s[mp]#### \
+                                [[,]b[ios] | a[cpi] | k[bd] | t[riple] | e[fi] | p[ci]] \
+                                [[,]f[orce]
+                        Where reboot_mode is one of warm (soft) or cold (hard) or gpio,
+                              reboot_type is one of bios, acpi, kbd, triple, efi, or pci,
+                              reboot_force is either force or not specified,
+                              reboot_cpu is s[mp]#### with #### being the processor
+                                        to be used for rebooting.
        relax_domain_level=
                        [KNL, SMP] Set scheduler's default relax_domain_level.
@@ -3005,6 +3017,27 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        Force threading of all interrupt handlers except those
                        marked explicitly IRQF_NO_THREAD.
+        tmem            [KNL,XEN]
+                        Enable the Transcendent memory driver if built-in.
+        tmem.cleancache=0|1 [KNL, XEN]
+                        Default is on (1). Disable the usage of the cleancache
+                        API to send anonymous pages to the hypervisor.
+        tmem.frontswap=0|1 [KNL, XEN]
+                        Default is on (1). Disable the usage of the frontswap
+                        API to send swap pages to the hypervisor. If disabled
+                        the selfballooning and selfshrinking are force disabled.
+        tmem.selfballooning=0|1 [KNL, XEN]
+                        Default is on (1). Disable the driving of swap pages
+                        to the hypervisor.
+        tmem.selfshrinking=0|1 [KNL, XEN]
+                        Default is on (1). Partial swapoff that immediately
+                        transfers pages from Xen hypervisor back to the
+                        kernel based on different criteria.
        topology=       [S390]
                        Format: {off | on}
                        Specify if the kernel should make use of the cpu
@@ -3048,6 +3081,19 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        See also Documentation/trace/ftrace.txt "trace options"
                        section.
+        traceoff_on_warning
+                        [FTRACE] enable this option to disable tracing when a
+                        warning is hit. This turns off "tracing_on". Tracing can
+                        be enabled again by echoing '1' into the "tracing_on"
+                        file located in /sys/kernel/debug/tracing/
+                        This option is useful, as it disables the trace before
+                        the WARNING dump is called, which prevents the trace to
+                        be filled with content caused by the warning output.
+                        This option can also be set at run time via the sysctl
+                        option:  kernel/traceoff_on_warning
        transparent_hugepage=
                        [KNL]
                        Format: [always|madvise|never]
@@ -3208,6 +3254,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        video=          [FB] Frame buffer configuration
                        See Documentation/fb/modedb.txt.
+        video.brightness_switch_enabled= [0,1]
+                        If set to 1, on receiving an ACPI notify event
+                        generated by hotkey, video driver will adjust brightness
+                        level and then send out the event to user space through
+                        the allocated input device; If set to 0, video driver
+                        will only send out the event without touching backlight
+                        brightness level.
+                        default: 1
        virtio_mmio.device=
                        [VMMIO] Memory mapped virtio (platform) device.
@@ -3320,6 +3375,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        that this also can be controlled per-workqueue for
                        workqueues visible under /sys/bus/workqueue/.
+        workqueue.power_efficient
+                        Per-cpu workqueues are generally preferred because
+                        they show better performance thanks to cache
+                        locality; unfortunately, per-cpu workqueues tend to
+                        be more power hungry than unbound workqueues.
+                        Enabling this makes the per-cpu workqueues which
+                        were observed to contribute significantly to power
+                        consumption unbound, leading to measurably lower
+                        power usage at the cost of small performance
+                        overhead.
+                        The default value of this parameter is determined by
+                        the config option CONFIG_WQ_POWER_EFFICIENT_DEFAULT.
        x2apic_phys     [X86-64,APIC] Use x2apic physical mode instead of
                        default x2apic cluster mode on platforms
                        supporting x2apic.
@@ -3330,9 +3400,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        plus one apbt timer for broadcast timer.
                        x86_mrst_timer=apbt_only | lapic_and_apbt
-        xd=             [HW,XT] Original XT pre-IDE (RLL encoded) disks.
-        xd_geo=         See header of drivers/block/xd.c.
        xen_emul_unplug=                [HW,X86,XEN]
                        Unplug Xen emulated devices
                        Format: [unplug0,][unplug1]
diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
index cbf7ae412da4..32351bfabf20 100644
--- a/Documentation/kernel-per-CPU-kthreads.txt
+++ b/Documentation/kernel-per-CPU-kthreads.txt
@@ -157,6 +157,53 @@ RCU_SOFTIRQ:  Do at least one of the following:
                calls and by forcing both kernel threads and interrupts
                to execute elsewhere.
+Name: kworker/%u:%d%s (cpu, id, priority)
+Purpose: Execute workqueue requests
+To reduce its OS jitter, do any of the following:
+1.      Run your workload at a real-time priority, which will allow
+        preempting the kworker daemons.
+2.      Do any of the following needed to avoid jitter that your
+        application cannot tolerate:
+        a.      Build your kernel with CONFIG_SLUB=y rather than
+                CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
+                use of each CPU's workqueues to run its cache_reap()
+                function.
+        b.      Avoid using oprofile, thus avoiding OS jitter from
+                wq_sync_buffer().
+        c.      Limit your CPU frequency so that a CPU-frequency
+                governor is not required, possibly enlisting the aid of
+                special heatsinks or other cooling technologies.  If done
+                correctly, and if you CPU architecture permits, you should
+                be able to build your kernel with CONFIG_CPU_FREQ=n to
+                avoid the CPU-frequency governor periodically running
+                on each CPU, including cs_dbs_timer() and od_dbs_timer().
+                WARNING:  Please check your CPU specifications to
+                make sure that this is safe on your particular system.
+        d.      It is not possible to entirely get rid of OS jitter
+                from vmstat_update() on CONFIG_SMP=y systems, but you
+                can decrease its frequency by writing a large value to
+                /proc/sys/vm/stat_interval.  The default value is HZ,
+                for an interval of one second.  Of course, larger values
+                will make your virtual-memory statistics update more
+                slowly.  Of course, you can also run your workload at
+                a real-time priority, thus preempting vmstat_update().
+        e.      If running on high-end powerpc servers, build with
+                CONFIG_PPC_RTAS_DAEMON=n.  This prevents the RTAS
+                daemon from running on each CPU every second or so.
+                (This will require editing Kconfig files and will defeat
+                this platform's RAS functionality.)  This avoids jitter
+                due to the rtas_event_scan() function.
+                WARNING:  Please check your CPU specifications to
+                make sure that this is safe on your particular system.
+        f.      If running on Cell Processor, build your kernel with
+                CBE_CPUFREQ_SPU_GOVERNOR=n to avoid OS jitter from
+                spu_gov_work().
+                WARNING:  Please check your CPU specifications to
+                make sure that this is safe on your particular system.
+        g.      If running on PowerMAC, build your kernel with
+                CONFIG_PMAC_RACKMETER=n to disable the CPU-meter,
+                avoiding OS jitter from rackmeter_do_timer().
 Name: rcuc/%u
 Purpose: Execute RCU callbacks in CONFIG_RCU_BOOST=y kernels.
 To reduce its OS jitter, do at least one of the following:
@@ -185,7 +232,7 @@ Purpose: Offload RCU callbacks from the corresponding CPU.
 To reduce its OS jitter, do at least one of the following:
 1.      Use affinity, cgroups, or other mechanism to force these kthreads
        to execute on some other CPU.
-2.      Build with CONFIG_RCU_NOCB_CPUS=n, which will prevent these
+2.      Build with CONFIG_RCU_NOCB_CPU=n, which will prevent these
        kthreads from being created in the first place.  However, please
        note that this will not eliminate OS jitter, but will instead
        shift it to RCU_SOFTIRQ.
diff --git a/Documentation/laptops/dslm.c b/Documentation/laptops/dslm.c
index 72ff290c5fc6..d5dd2d4b04d8 100644
--- a/Documentation/laptops/dslm.c
+++ b/Documentation/laptops/dslm.c
@@ -2,7 +2,7 @@
 * dslm.c
 * Simple Disk Sleep Monitor
 *  by Bartek Kania
- * Licenced under the GPL
+ * Licensed under the GPL
 */
 #include <unistd.h>
 #include <stdlib.h>
diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt
index 97d45f276fe6..eaf32a1fd0b1 100644
--- a/Documentation/m68k/kernel-options.txt
+++ b/Documentation/m68k/kernel-options.txt
@@ -80,8 +80,6 @@ Valid names are:
  /dev/sdd: -> 0x0830 (forth SCSI disk)
  /dev/sde: -> 0x0840 (fifth SCSI disk)
  /dev/fd : -> 0x0200 (floppy disk)
-  /dev/xda: -> 0x0c00 (first XT disk, unused in Linux/m68k)
-  /dev/xdb: -> 0x0c40 (second XT disk, unused in Linux/m68k)
  The name must be followed by a decimal number, that stands for the
 partition number. Internally, the value of the number is just
diff --git a/Documentation/md.txt b/Documentation/md.txt
index e0ddd327632d..fbb2fcbf16b6 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -566,13 +566,6 @@ also have
     when it reaches the current sync_max (below) and possibly at
     other times.
-   sync_max
-     This is a number of sectors at which point a resync/recovery
-     process will pause.  When a resync is active, the value can
-     only ever be increased, never decreased.  The value of 'max'
-     effectively disables the limit.
   sync_speed
     This shows the current actual speed, in K/sec, of the current
     sync_action.  It is averaged over the last 30 seconds.
@@ -593,6 +586,12 @@ also have
     that number to reach sync_max.  Then you can either increase
     "sync_max", or can write 'idle' to "sync_action".
+     The value of 'max' for "sync_max" effectively disables the limit.
+     When a resync is active, the value can only ever be increased,
+     never decreased.
+     The value of '0' is the minimum for "sync_min".
 Each active md device may also have attributes specific to the
 personality module that manages it.
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt
index 77bd0a42f19d..eeced24e56af 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -18,7 +18,7 @@ Abstract media device model
 Discovering a device internal topology, and configuring it at runtime, is one
 of the goals of the media framework. To achieve this, hardware devices are
-modeled as an oriented graph of building blocks called entities connected
+modelled as an oriented graph of building blocks called entities connected
 through pads.
 An entity is a basic media hardware building block. It can correspond to
diff --git a/Documentation/metag/kernel-ABI.txt b/Documentation/metag/kernel-ABI.txt
index 7b8dee83b9c1..628216603198 100644
--- a/Documentation/metag/kernel-ABI.txt
+++ b/Documentation/metag/kernel-ABI.txt
@@ -189,7 +189,7 @@ call:
 64-bit arguments are placed in matching pairs of registers (i.e. the same
 register number in both D0 and D1 units), with the least significant half in D0
-and the most significant half in D1, leaving a gap where necessary. Futher
+and the most significant half in D1, leaving a gap where necessary. Further
 arguments are stored on the stack in reverse order (earlier arguments at higher
 addresses):
diff --git a/Documentation/misc-devices/mei/mei.txt b/Documentation/misc-devices/mei/mei.txt
index 6ec702950719..15bba1aeba9a 100644
--- a/Documentation/misc-devices/mei/mei.txt
+++ b/Documentation/misc-devices/mei/mei.txt
@@ -120,7 +120,7 @@ The Intel MEI Driver supports the following IOCTL command:
        Notes:
        max_msg_length (MTU) in client properties describes the maximum
        data that can be sent or received. (e.g. if MTU=2K, can send
-        requests up to bytes 2k and received responses upto 2k bytes).
+        requests up to bytes 2k and received responses up to 2k bytes).
 Intel ME Applications:
 ==============
diff --git a/Documentation/networking/.gitignore b/Documentation/networking/.gitignore
index 286a5680f490..e69de29bb2d1 100644
--- a/Documentation/networking/.gitignore
+++ b/Documentation/networking/.gitignore
@@ -1 +0,0 @@
-ifenslave
diff --git a/Documentation/networking/00-INDEX b/Documentation/networking/00-INDEX
index 258d9b92c36f..32dfbd924121 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -88,8 +88,6 @@ gianfar.txt
        - Gianfar Ethernet Driver.
 ieee802154.txt
        - Linux IEEE 802.15.4 implementation, API and drivers
-ifenslave.c
-        - Configure network interfaces for parallel routing (bonding).
 igb.txt
        - README for the Intel Gigabit Ethernet Driver (igb).
 igbvf.txt
diff --git a/Documentation/networking/Makefile b/Documentation/networking/Makefile
index 24c308dd3fd1..0aa1ac98fc2b 100644
--- a/Documentation/networking/Makefile
+++ b/Documentation/networking/Makefile
@@ -1,11 +1,6 @@
 # kbuild trick to avoid linker error. Can be omitted if a module is built.
 obj- := dummy.o
-# List of programs to build
-hostprogs-y := ifenslave
-HOSTCFLAGS_ifenslave.o += -I$(objtree)/usr/include
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
diff --git a/Documentation/networking/arcnet.txt b/Documentation/networking/arcnet.txt
index 9ff579502151..aff97f47c05c 100644
--- a/Documentation/networking/arcnet.txt
+++ b/Documentation/networking/arcnet.txt
@@ -70,9 +70,10 @@ list, mail to linux-arcnet@tichy.ch.uj.edu.pl.
 There are archives of the mailing list at:
        http://epistolary.org/mailman/listinfo.cgi/arcnet
-The people on linux-net@vger.kernel.org have also been known to be very
+The people on linux-net@vger.kernel.org (now defunct, replaced by
-helpful, especially when we're talking about ALPHA Linux kernels that may or
+netdev@vger.kernel.org) have also been known to be very helpful, especially
-may not work right in the first place.
+when we're talking about ALPHA Linux kernels that may or may not work right
+in the first place.
 Other Drivers and Info
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 10a015c384b8..87bbcfee2e06 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -104,8 +104,7 @@ Table of Contents
 ==============================
        Most popular distro kernels ship with the bonding driver
-already available as a module and the ifenslave user level control
+already available as a module. If your distro does not, or you
-program installed and ready for use. If your distro does not, or you
 have need to compile bonding from source (e.g., configuring and
 installing a mainline kernel from kernel.org), you'll need to perform
 the following steps:
@@ -124,46 +123,13 @@ device support" section.  It is recommended that you configure the
 driver as module since it is currently the only way to pass parameters
 to the driver or configure more than one bonding device.
-        Build and install the new kernel and modules, then continue
+        Build and install the new kernel and modules.
-below to install ifenslave.
-1.2 Install ifenslave Control Utility
+1.2 Bonding Control Utility
 -------------------------------------
-        The ifenslave user level control program is included in the
+         It is recommended to configure bonding via iproute2 (netlink)
-kernel source tree, in the file Documentation/networking/ifenslave.c.
+or sysfs, the old ifenslave control utility is obsolete.
-It is generally recommended that you use the ifenslave that
-corresponds to the kernel that you are using (either from the same
-source tree or supplied with the distro), however, ifenslave
-executables from older kernels should function (but features newer
-than the ifenslave release are not supported).  Running an ifenslave
-that is newer than the kernel is not supported, and may or may not
-work.
-        To install ifenslave, do the following:
-# gcc -Wall -O -I/usr/src/linux/include ifenslave.c -o ifenslave
-# cp ifenslave /sbin/ifenslave
-        If your kernel source is not in "/usr/src/linux," then replace
-"/usr/src/linux/include" in the above with the location of your kernel
-source include directory.
-        You may wish to back up any existing /sbin/ifenslave, or, for
-testing or informal use, tag the ifenslave to the kernel version
-(e.g., name the ifenslave executable /sbin/ifenslave-2.6.10).
-IMPORTANT NOTE:
-        If you omit the "-I" or specify an incorrect directory, you
-may end up with an ifenslave that is incompatible with the kernel
-you're trying to build it for.  Some distros (e.g., Red Hat from 7.1
-onwards) do not have /usr/include/linux symbolically linked to the
-default kernel source include directory.
-SECOND IMPORTANT NOTE:
-        If you plan to configure bonding using sysfs or using the
-/etc/network/interfaces file, you do not need to use ifenslave.
 2. Bonding Driver Options
 =========================
@@ -337,6 +303,12 @@ arp_validate
        such a situation, validation of backup slaves must be
        disabled.
+        The validation of ARP requests on backup slaves is mainly
+        helping bonding to decide which slaves are more likely to
+        work in case of the active slave failure, it doesn't really
+        guarantee that the backup slave will work if it's selected
+        as the next active slave.
        This option is useful in network configurations in which
        multiple bonding hosts are concurrently issuing ARPs to one or
        more targets beyond a common switch.  Should the link between
@@ -349,6 +321,25 @@ arp_validate
        This option was added in bonding version 3.1.0.
+arp_all_targets
+        Specifies the quantity of arp_ip_targets that must be reachable
+        in order for the ARP monitor to consider a slave as being up.
+        This option affects only active-backup mode for slaves with
+        arp_validation enabled.
+        Possible values are:
+        any or 0
+                consider the slave up only when any of the arp_ip_targets
+                is reachable
+        all or 1
+                consider the slave up only when all of the arp_ip_targets
+                are reachable
 downdelay
        Specifies the time, in milliseconds, to wait before disabling
@@ -851,7 +842,7 @@ resend_igmp
 ==============================
        You can configure bonding using either your distro's network
-initialization scripts, or manually using either ifenslave or the
+initialization scripts, or manually using either iproute2 or the
 sysfs interface.  Distros generally use one of three packages for the
 network initialization scripts: initscripts, sysconfig or interfaces.
 Recent versions of these packages have support for bonding, while older
@@ -1160,7 +1151,7 @@ not support this method for specifying multiple bonding interfaces; for
 those instances, see the "Configuring Multiple Bonds Manually" section,
 below.
-3.3 Configuring Bonding Manually with Ifenslave
+3.3 Configuring Bonding Manually with iproute2
 -----------------------------------------------
        This section applies to distros whose network initialization
@@ -1171,7 +1162,7 @@ version 8.
        The general method for these systems is to place the bonding
 module parameters into a config file in /etc/modprobe.d/ (as
 appropriate for the installed distro), then add modprobe and/or
-ifenslave commands to the system's global init script.  The name of
+`ip link` commands to the system's global init script.  The name of
 the global init script differs; for sysconfig, it is
 /etc/init.d/boot.local and for initscripts it is /etc/rc.d/rc.local.
@@ -1183,8 +1174,8 @@ reboots, edit the appropriate file (/etc/init.d/boot.local or
 modprobe bonding mode=balance-alb miimon=100
 modprobe e100
 ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
-ifenslave bond0 eth0
+ip link set eth0 master bond0
-ifenslave bond0 eth1
+ip link set eth1 master bond0
        Replace the example bonding module parameters and bond0
 network configuration (IP address, netmask, etc) with the appropriate
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 67a9cb259d40..09eb57329f11 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -5,7 +5,7 @@
 Introduction
 ============
 The IEEE 802.15.4 working group focuses on standartization of bottom
-two layers: Medium Accsess Control (MAC) and Physical (PHY). And there
+two layers: Medium Access Control (MAC) and Physical (PHY). And there
 are mainly two options available for upper layers:
 - ZigBee - proprietary protocol from ZigBee Alliance
 - 6LowPAN - IPv6 networking over low rate personal area networks
diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c
deleted file mode 100644
index ac5debb2f16c..000000000000
--- a/Documentation/networking/ifenslave.c
+++ /dev/null
@@ -1,1105 +0,0 @@
-/* Mode: C;
- * ifenslave.c: Configure network interfaces for parallel routing.
- *
- *      This program controls the Linux implementation of running multiple
- *      network interfaces in parallel.
- *
- * Author:      Donald Becker <becker@cesdis.gsfc.nasa.gov>
- *              Copyright 1994-1996 Donald Becker
- *
- *              This program is free software; you can redistribute it
- *              and/or modify it under the terms of the GNU General Public
- *              License as published by the Free Software Foundation.
- *
- *      The author may be reached as becker@CESDIS.gsfc.nasa.gov, or C/O
- *      Center of Excellence in Space Data and Information Sciences
- *         Code 930.5, Goddard Space Flight Center, Greenbelt MD 20771
- *
- *  Changes :
- *    - 2000/10/02 Willy Tarreau <willy at meta-x.org> :
- *       - few fixes. Master's MAC address is now correctly taken from
- *         the first device when not previously set ;
- *       - detach support : call BOND_RELEASE to detach an enslaved interface.
- *       - give a mini-howto from command-line help : # ifenslave -h
- *
- *    - 2001/02/16 Chad N. Tindel <ctindel at ieee dot org> :
- *       - Master is now brought down before setting the MAC address.  In
- *         the 2.4 kernel you can't change the MAC address while the device is
- *         up because you get EBUSY.
- *
- *    - 2001/09/13 Takao Indoh <indou dot takao at jp dot fujitsu dot com>
- *       - Added the ability to change the active interface on a mode 1 bond
- *         at runtime.
- *
- *    - 2001/10/23 Chad N. Tindel <ctindel at ieee dot org> :
- *       - No longer set the MAC address of the master.  The bond device will
- *         take care of this itself
- *       - Try the SIOC*** versions of the bonding ioctls before using the
- *         old versions
- *    - 2002/02/18 Erik Habbinga <erik_habbinga @ hp dot com> :
- *       - ifr2.ifr_flags was not initialized in the hwaddr_notset case,
- *         SIOCGIFFLAGS now called before hwaddr_notset test
- *
- *    - 2002/10/31 Tony Cureington <tony.cureington * hp_com> :
- *       - If the master does not have a hardware address when the first slave
- *         is enslaved, the master is assigned the hardware address of that
- *         slave - there is a comment in bonding.c stating "ifenslave takes
- *         care of this now." This corrects the problem of slaves having
- *         different hardware addresses in active-backup mode when
- *         multiple interfaces are specified on a single ifenslave command
- *         (ifenslave bond0 eth0 eth1).
- *
- *    - 2003/03/18 - Tsippy Mendelson <tsippy.mendelson at intel dot com> and
- *                   Shmulik Hen <shmulik.hen at intel dot com>
- *       - Moved setting the slave's mac address and openning it, from
- *         the application to the driver. This enables support of modes
- *         that need to use the unique mac address of each slave.
- *         The driver also takes care of closing the slave and restoring its
- *         original mac address upon release.
- *         In addition, block possibility of enslaving before the master is up.
- *         This prevents putting the system in an undefined state.
- *
- *    - 2003/05/01 - Amir Noam <amir.noam at intel dot com>
- *       - Added ABI version control to restore compatibility between
- *         new/old ifenslave and new/old bonding.
- *       - Prevent adding an adapter that is already a slave.
- *         Fixes the problem of stalling the transmission and leaving
- *         the slave in a down state.
- *
- *    - 2003/05/01 - Shmulik Hen <shmulik.hen at intel dot com>
- *       - Prevent enslaving if the bond device is down.
- *         Fixes the problem of leaving the system in unstable state and
- *         halting when trying to remove the module.
- *       - Close socket on all abnormal exists.
- *       - Add versioning scheme that follows that of the bonding driver.
- *         current version is 1.0.0 as a base line.
- *
- *    - 2003/05/22 - Jay Vosburgh <fubar at us dot ibm dot com>
- *       - ifenslave -c was broken; it's now fixed
- *       - Fixed problem with routes vanishing from master during enslave
- *         processing.
- *
- *    - 2003/05/27 - Amir Noam <amir.noam at intel dot com>
- *       - Fix backward compatibility issues:
- *         For drivers not using ABI versions, slave was set down while
- *         it should be left up before enslaving.
- *         Also, master was not set down and the default set_mac_address()
- *         would fail and generate an error message in the system log.
- *       - For opt_c: slave should not be set to the master's setting
- *         while it is running. It was already set during enslave. To
- *         simplify things, it is now handled separately.
- *
- *    - 2003/12/01 - Shmulik Hen <shmulik.hen at intel dot com>
- *       - Code cleanup and style changes
- *         set version to 1.1.0
- */
-#define APP_VERSION     "1.1.0"
-#define APP_RELDATE     "December 1, 2003"
-#define APP_NAME        "ifenslave"
-static char *version =
-APP_NAME ".c:v" APP_VERSION " (" APP_RELDATE ")\n"
-"o Donald Becker (becker@cesdis.gsfc.nasa.gov).\n"
-"o Detach support added on 2000/10/02 by Willy Tarreau (willy at meta-x.org).\n"
-"o 2.4 kernel support added on 2001/02/16 by Chad N. Tindel\n"
-"  (ctindel at ieee dot org).\n";
-static const char *usage_msg =
-"Usage: ifenslave [-f] <master-if> <slave-if> [<slave-if>...]\n"
-"       ifenslave -d   <master-if> <slave-if> [<slave-if>...]\n"
-"       ifenslave -c   <master-if> <slave-if>\n"
-"       ifenslave --help\n";
-static const char *help_msg =
-"\n"
-"       To create a bond device, simply follow these three steps :\n"
-"       - ensure that the required drivers are properly loaded :\n"
-"         # modprobe bonding ; modprobe <3c59x|eepro100|pcnet32|tulip|...>\n"
-"       - assign an IP address to the bond device :\n"
-"         # ifconfig bond0 <addr> netmask <mask> broadcast <bcast>\n"
-"       - attach all the interfaces you need to the bond device :\n"
-"         # ifenslave [{-f|--force}] bond0 eth0 [eth1 [eth2]...]\n"
-"         If bond0 didn't have a MAC address, it will take eth0's. Then, all\n"
-"         interfaces attached AFTER this assignment will get the same MAC addr.\n"
-"         (except for ALB/TLB modes)\n"
-"\n"
-"       To set the bond device down and automatically release all the slaves :\n"
-"         # ifconfig bond0 down\n"
-"\n"
-"       To detach a dead interface without setting the bond device down :\n"
-"         # ifenslave {-d|--detach} bond0 eth0 [eth1 [eth2]...]\n"
-"\n"
-"       To change active slave :\n"
-"         # ifenslave {-c|--change-active} bond0 eth0\n"
-"\n"
-"       To show master interface info\n"
-"         # ifenslave bond0\n"
-"\n"
-"       To show all interfaces info\n"
-"       # ifenslave {-a|--all-interfaces}\n"
-"\n"
-"       To be more verbose\n"
-"       # ifenslave {-v|--verbose} ...\n"
-"\n"
-"       # ifenslave {-u|--usage}   Show usage\n"
-"       # ifenslave {-V|--version} Show version\n"
-"       # ifenslave {-h|--help}    This message\n"
-"\n";
-#include <unistd.h>
-#include <stdlib.h>
-#include <stdio.h>
-#include <ctype.h>
-#include <string.h>
-#include <errno.h>
-#include <fcntl.h>
-#include <getopt.h>
-#include <sys/types.h>
-#include <sys/socket.h>
-#include <sys/ioctl.h>
-#include <linux/if.h>
-#include <net/if_arp.h>
-#include <linux/if_ether.h>
-#include <linux/if_bonding.h>
-#include <linux/sockios.h>
-typedef unsigned long long u64; /* hack, so we may include kernel's ethtool.h */
-typedef __uint32_t u32;         /* ditto */
-typedef __uint16_t u16;         /* ditto */
-typedef __uint8_t u8;           /* ditto */
-#include <linux/ethtool.h>
-struct option longopts[] = {
-        /* { name  has_arg  *flag  val } */
-        {"all-interfaces",      0, 0, 'a'},     /* Show all interfaces. */
-        {"change-active",       0, 0, 'c'},     /* Change the active slave.  */
-        {"detach",              0, 0, 'd'},     /* Detach a slave interface. */
-        {"force",               0, 0, 'f'},     /* Force the operation. */
-        {"help",                0, 0, 'h'},     /* Give help */
-        {"usage",               0, 0, 'u'},     /* Give usage */
-        {"verbose",             0, 0, 'v'},     /* Report each action taken. */
-        {"version",             0, 0, 'V'},     /* Emit version information. */
-        { 0, 0, 0, 0}
-};
-/* Command-line flags. */
-unsigned int
-opt_a = 0,      /* Show-all-interfaces flag. */
-opt_c = 0,      /* Change-active-slave flag. */
-opt_d = 0,      /* Detach a slave interface. */
-opt_f = 0,      /* Force the operation. */
-opt_h = 0,      /* Help */
-opt_u = 0,      /* Usage */
-opt_v = 0,      /* Verbose flag. */
-opt_V = 0;      /* Version */
-int skfd = -1;          /* AF_INET socket for ioctl() calls.*/
-int abi_ver = 0;        /* userland - kernel ABI version */
-int hwaddr_set = 0;     /* Master's hwaddr is set */
-int saved_errno;
-struct ifreq master_mtu, master_flags, master_hwaddr;
-struct ifreq slave_mtu, slave_flags, slave_hwaddr;
-struct dev_ifr {
-        struct ifreq *req_ifr;
-        char *req_name;
-        int req_type;
-};
-struct dev_ifr master_ifra[] = {
-        {&master_mtu,     "SIOCGIFMTU",     SIOCGIFMTU},
-        {&master_flags,   "SIOCGIFFLAGS",   SIOCGIFFLAGS},
-        {&master_hwaddr,  "SIOCGIFHWADDR",  SIOCGIFHWADDR},
-        {NULL, "", 0}
-};
-struct dev_ifr slave_ifra[] = {
-        {&slave_mtu,     "SIOCGIFMTU",     SIOCGIFMTU},
-        {&slave_flags,   "SIOCGIFFLAGS",   SIOCGIFFLAGS},
-        {&slave_hwaddr,  "SIOCGIFHWADDR",  SIOCGIFHWADDR},
-        {NULL, "", 0}
-};
-static void if_print(char *ifname);
-static int get_drv_info(char *master_ifname);
-static int get_if_settings(char *ifname, struct dev_ifr ifra[]);
-static int get_slave_flags(char *slave_ifname);
-static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr);
-static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr);
-static int set_slave_mtu(char *slave_ifname, int mtu);
-static int set_if_flags(char *ifname, short flags);
-static int set_if_up(char *ifname, short flags);
-static int set_if_down(char *ifname, short flags);
-static int clear_if_addr(char *ifname);
-static int set_if_addr(char *master_ifname, char *slave_ifname);
-static int change_active(char *master_ifname, char *slave_ifname);
-static int enslave(char *master_ifname, char *slave_ifname);
-static int release(char *master_ifname, char *slave_ifname);
-#define v_print(fmt, args...)   \
-        if (opt_v)              \
-                fprintf(stderr, fmt, ## args )
-int main(int argc, char *argv[])
-{
-        char **spp, *master_ifname, *slave_ifname;
-        int c, i, rv;
-        int res = 0;
-        int exclusive = 0;
-        while ((c = getopt_long(argc, argv, "acdfhuvV", longopts, 0)) != EOF) {
-                switch (c) {
-                case 'a': opt_a++; exclusive++; break;
-                case 'c': opt_c++; exclusive++; break;
-                case 'd': opt_d++; exclusive++; break;
-                case 'f': opt_f++; exclusive++; break;
-                case 'h': opt_h++; exclusive++; break;
-                case 'u': opt_u++; exclusive++; break;
-                case 'v': opt_v++; break;
-                case 'V': opt_V++; exclusive++; break;
-                case '?':
-                        fprintf(stderr, "%s", usage_msg);
-                        res = 2;
-                        goto out;
-                }
-        }
-        /* options check */
-        if (exclusive > 1) {
-                fprintf(stderr, "%s", usage_msg);
-                res = 2;
-                goto out;
-        }
-        if (opt_v || opt_V) {
-                printf("%s", version);
-                if (opt_V) {
-                        res = 0;
-                        goto out;
-                }
-        }
-        if (opt_u) {
-                printf("%s", usage_msg);
-                res = 0;
-                goto out;
-        }
-        if (opt_h) {
-                printf("%s", usage_msg);
-                printf("%s", help_msg);
-                res = 0;
-                goto out;
-        }
-        /* Open a basic socket */
-        if ((skfd = socket(AF_INET, SOCK_DGRAM, 0)) < 0) {
-                perror("socket");
-                res = 1;
-                goto out;
-        }
-        if (opt_a) {
-                if (optind == argc) {
-                        /* No remaining args */
-                        /* show all interfaces */
-                        if_print((char *)NULL);
-                        goto out;
-                } else {
-                        /* Just show usage */
-                        fprintf(stderr, "%s", usage_msg);
-                        res = 2;
-                        goto out;
-                }
-        }
-        /* Copy the interface name */
-        spp = argv + optind;
-        master_ifname = *spp++;
-        if (master_ifname == NULL) {
-                fprintf(stderr, "%s", usage_msg);
-                res = 2;
-                goto out;
-        }
-        /* exchange abi version with bonding module */
-        res = get_drv_info(master_ifname);
-        if (res) {
-                fprintf(stderr,
-                        "Master '%s': Error: handshake with driver failed. "
-                        "Aborting\n",
-                        master_ifname);
-                goto out;
-        }
-        slave_ifname = *spp++;
-        if (slave_ifname == NULL) {
-                if (opt_d || opt_c) {
-                        fprintf(stderr, "%s", usage_msg);
-                        res = 2;
-                        goto out;
-                }
-                /* A single arg means show the
-                 * configuration for this interface
-                 */
-                if_print(master_ifname);
-                goto out;
-        }
-        res = get_if_settings(master_ifname, master_ifra);
-        if (res) {
-                /* Probably a good reason not to go on */
-                fprintf(stderr,
-                        "Master '%s': Error: get settings failed: %s. "
-                        "Aborting\n",
-                        master_ifname, strerror(res));
-                goto out;
-        }
-        /* check if master is indeed a master;
-         * if not then fail any operation
-         */
-        if (!(master_flags.ifr_flags & IFF_MASTER)) {
-                fprintf(stderr,
-                        "Illegal operation; the specified interface '%s' "
-                        "is not a master. Aborting\n",
-                        master_ifname);
-                res = 1;
-                goto out;
-        }
-        /* check if master is up; if not then fail any operation */
-        if (!(master_flags.ifr_flags & IFF_UP)) {
-                fprintf(stderr,
-                        "Illegal operation; the specified master interface "
-                        "'%s' is not up.\n",
-                        master_ifname);
-                res = 1;
-                goto out;
-        }
-        /* Only for enslaving */
-        if (!opt_c && !opt_d) {
-                sa_family_t master_family = master_hwaddr.ifr_hwaddr.sa_family;
-                unsigned char *hwaddr =
-                        (unsigned char *)master_hwaddr.ifr_hwaddr.sa_data;
-                /* The family '1' is ARPHRD_ETHER for ethernet. */
-                if (master_family != 1 && !opt_f) {
-                        fprintf(stderr,
-                                "Illegal operation: The specified master "
-                                "interface '%s' is not ethernet-like.\n "
-                                "This program is designed to work with "
-                                "ethernet-like network interfaces.\n "
-                                "Use the '-f' option to force the "
-                                "operation.\n",
-                                master_ifname);
-                        res = 1;
-                        goto out;
-                }
-                /* Check master's hw addr */
-                for (i = 0; i < 6; i++) {
-                        if (hwaddr[i] != 0) {
-                                hwaddr_set = 1;
-                                break;
-                        }
-                }
-                if (hwaddr_set) {
-                        v_print("current hardware address of master '%s' "
-                                "is %2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x, "
-                                "type %d\n",
-                                master_ifname,
-                                hwaddr[0], hwaddr[1],
-                                hwaddr[2], hwaddr[3],
-                                hwaddr[4], hwaddr[5],
-                                master_family);
-                }
-        }
-        /* Accepts only one slave */
-        if (opt_c) {
-                /* change active slave */
-                res = get_slave_flags(slave_ifname);
-                if (res) {
-                        fprintf(stderr,
-                                "Slave '%s': Error: get flags failed. "
-                                "Aborting\n",
-                                slave_ifname);
-                        goto out;
-                }
-                res = change_active(master_ifname, slave_ifname);
-                if (res) {
-                        fprintf(stderr,
-                                "Master '%s', Slave '%s': Error: "
-                                "Change active failed\n",
-                                master_ifname, slave_ifname);
-                }
-        } else {
-                /* Accept multiple slaves */
-                do {
-                        if (opt_d) {
-                                /* detach a slave interface from the master */
-                                rv = get_slave_flags(slave_ifname);
-                                if (rv) {
-                                        /* Can't work with this slave. */
-                                        /* remember the error and skip it*/
-                                        fprintf(stderr,
-                                                "Slave '%s': Error: get flags "
-                                                "failed. Skipping\n",
-                                                slave_ifname);
-                                        res = rv;
-                                        continue;
-                                }
-                                rv = release(master_ifname, slave_ifname);
-                                if (rv) {
-                                        fprintf(stderr,
-                                                "Master '%s', Slave '%s': Error: "
-                                                "Release failed\n",
-                                                master_ifname, slave_ifname);
-                                        res = rv;
-                                }
-                        } else {
-                                /* attach a slave interface to the master */
-                                rv = get_if_settings(slave_ifname, slave_ifra);
-                                if (rv) {
-                                        /* Can't work with this slave. */
-                                        /* remember the error and skip it*/
-                                        fprintf(stderr,
-                                                "Slave '%s': Error: get "
-                                                "settings failed: %s. "
-                                                "Skipping\n",
-                                                slave_ifname, strerror(rv));
-                                        res = rv;
-                                        continue;
-                                }
-                                rv = enslave(master_ifname, slave_ifname);
-                                if (rv) {
-                                        fprintf(stderr,
-                                                "Master '%s', Slave '%s': Error: "
-                                                "Enslave failed\n",
-                                                master_ifname, slave_ifname);
-                                        res = rv;
-                                }
-                        }
-                } while ((slave_ifname = *spp++) != NULL);
-        }
-out:
-        if (skfd >= 0) {
-                close(skfd);
-        }
-        return res;
-}
-static short mif_flags;
-/* Get the inteface configuration from the kernel. */
-static int if_getconfig(char *ifname)
-{
-        struct ifreq ifr;
-        int metric, mtu;        /* Parameters of the master interface. */
-        struct sockaddr dstaddr, broadaddr, netmask;
-        unsigned char *hwaddr;
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFFLAGS, &ifr) < 0)
-                return -1;
-        mif_flags = ifr.ifr_flags;
-        printf("The result of SIOCGIFFLAGS on %s is %x.\n",
-               ifname, ifr.ifr_flags);
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFADDR, &ifr) < 0)
-                return -1;
-        printf("The result of SIOCGIFADDR is %2.2x.%2.2x.%2.2x.%2.2x.\n",
-               ifr.ifr_addr.sa_data[0], ifr.ifr_addr.sa_data[1],
-               ifr.ifr_addr.sa_data[2], ifr.ifr_addr.sa_data[3]);
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFHWADDR, &ifr) < 0)
-                return -1;
-        /* Gotta convert from 'char' to unsigned for printf(). */
-        hwaddr = (unsigned char *)ifr.ifr_hwaddr.sa_data;
-        printf("The result of SIOCGIFHWADDR is type %d  "
-               "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
-               ifr.ifr_hwaddr.sa_family, hwaddr[0], hwaddr[1],
-               hwaddr[2], hwaddr[3], hwaddr[4], hwaddr[5]);
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFMETRIC, &ifr) < 0) {
-                metric = 0;
-        } else
-                metric = ifr.ifr_metric;
-        printf("The result of SIOCGIFMETRIC is %d\n", metric);
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFMTU, &ifr) < 0)
-                mtu = 0;
-        else
-                mtu = ifr.ifr_mtu;
-        printf("The result of SIOCGIFMTU is %d\n", mtu);
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFDSTADDR, &ifr) < 0) {
-                memset(&dstaddr, 0, sizeof(struct sockaddr));
-        } else
-                dstaddr = ifr.ifr_dstaddr;
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFBRDADDR, &ifr) < 0) {
-                memset(&broadaddr, 0, sizeof(struct sockaddr));
-        } else
-                broadaddr = ifr.ifr_broadaddr;
-        strcpy(ifr.ifr_name, ifname);
-        if (ioctl(skfd, SIOCGIFNETMASK, &ifr) < 0) {
-                memset(&netmask, 0, sizeof(struct sockaddr));
-        } else
-                netmask = ifr.ifr_netmask;
-        return 0;
-}
-static void if_print(char *ifname)
-{
-        char buff[1024];
-        struct ifconf ifc;
-        struct ifreq *ifr;
-        int i;
-        if (ifname == (char *)NULL) {
-                ifc.ifc_len = sizeof(buff);
-                ifc.ifc_buf = buff;
-                if (ioctl(skfd, SIOCGIFCONF, &ifc) < 0) {
-                        perror("SIOCGIFCONF failed");
-                        return;
-                }
-                ifr = ifc.ifc_req;
-                for (i = ifc.ifc_len / sizeof(struct ifreq); --i >= 0; ifr++) {
-                        if (if_getconfig(ifr->ifr_name) < 0) {
-                                fprintf(stderr,
-                                        "%s: unknown interface.\n",
-                                        ifr->ifr_name);
-                                continue;
-                        }
-                        if (((mif_flags & IFF_UP) == 0) && !opt_a) continue;
-                        /*ife_print(&ife);*/
-                }
-        } else {
-                if (if_getconfig(ifname) < 0) {
-                        fprintf(stderr,
-                                "%s: unknown interface.\n", ifname);
-                }
-        }
-}
-static int get_drv_info(char *master_ifname)
-{
-        struct ifreq ifr;
-        struct ethtool_drvinfo info;
-        char *endptr;
-        memset(&ifr, 0, sizeof(ifr));
-        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
-        ifr.ifr_data = (caddr_t)&info;
-        info.cmd = ETHTOOL_GDRVINFO;
-        strncpy(info.driver, "ifenslave", 32);
-        snprintf(info.fw_version, 32, "%d", BOND_ABI_VERSION);
-        if (ioctl(skfd, SIOCETHTOOL, &ifr) < 0) {
-                if (errno == EOPNOTSUPP) {
-                        goto out;
-                }
-                saved_errno = errno;
-                v_print("Master '%s': Error: get bonding info failed %s\n",
-                        master_ifname, strerror(saved_errno));
-                return 1;
-        }
-        abi_ver = strtoul(info.fw_version, &endptr, 0);
-        if (*endptr) {
-                v_print("Master '%s': Error: got invalid string as an ABI "
-                        "version from the bonding module\n",
-                        master_ifname);
-                return 1;
-        }
-out:
-        v_print("ABI ver is %d\n", abi_ver);
-        return 0;
-}
-static int change_active(char *master_ifname, char *slave_ifname)
-{
-        struct ifreq ifr;
-        int res = 0;
-        if (!(slave_flags.ifr_flags & IFF_SLAVE)) {
-                fprintf(stderr,
-                        "Illegal operation: The specified slave interface "
-                        "'%s' is not a slave\n",
-                        slave_ifname);
-                return 1;
-        }
-        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
-        strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
-        if ((ioctl(skfd, SIOCBONDCHANGEACTIVE, &ifr) < 0) &&
-            (ioctl(skfd, BOND_CHANGE_ACTIVE_OLD, &ifr) < 0)) {
-                saved_errno = errno;
-                v_print("Master '%s': Error: SIOCBONDCHANGEACTIVE failed: "
-                        "%s\n",
-                        master_ifname, strerror(saved_errno));
-                res = 1;
-        }
-        return res;
-}
-static int enslave(char *master_ifname, char *slave_ifname)
-{
-        struct ifreq ifr;
-        int res = 0;
-        if (slave_flags.ifr_flags & IFF_SLAVE) {
-                fprintf(stderr,
-                        "Illegal operation: The specified slave interface "
-                        "'%s' is already a slave\n",
-                        slave_ifname);
-                return 1;
-        }
-        res = set_if_down(slave_ifname, slave_flags.ifr_flags);
-        if (res) {
-                fprintf(stderr,
-                        "Slave '%s': Error: bring interface down failed\n",
-                        slave_ifname);
-                return res;
-        }
-        if (abi_ver < 2) {
-                /* Older bonding versions would panic if the slave has no IP
-                 * address, so get the IP setting from the master.
-                 */
-                set_if_addr(master_ifname, slave_ifname);
-        } else {
-                res = clear_if_addr(slave_ifname);
-                if (res) {
-                        fprintf(stderr,
-                                "Slave '%s': Error: clear address failed\n",
-                                slave_ifname);
-                        return res;
-                }
-        }
-        if (master_mtu.ifr_mtu != slave_mtu.ifr_mtu) {
-                res = set_slave_mtu(slave_ifname, master_mtu.ifr_mtu);
-                if (res) {
-                        fprintf(stderr,
-                                "Slave '%s': Error: set MTU failed\n",
-                                slave_ifname);
-                        return res;
-                }
-        }
-        if (hwaddr_set) {
-                /* Master already has an hwaddr
-                 * so set it's hwaddr to the slave
-                 */
-                if (abi_ver < 1) {
-                        /* The driver is using an old ABI, so
-                         * the application sets the slave's
-                         * hwaddr
-                         */
-                        res = set_slave_hwaddr(slave_ifname,
-                                               &(master_hwaddr.ifr_hwaddr));
-                        if (res) {
-                                fprintf(stderr,
-                                        "Slave '%s': Error: set hw address "
-                                        "failed\n",
-                                        slave_ifname);
-                                goto undo_mtu;
-                        }
-                        /* For old ABI the application needs to bring the
-                         * slave back up
-                         */
-                        res = set_if_up(slave_ifname, slave_flags.ifr_flags);
-                        if (res) {
-                                fprintf(stderr,
-                                        "Slave '%s': Error: bring interface "
-                                        "down failed\n",
-                                        slave_ifname);
-                                goto undo_slave_mac;
-                        }
-                }
-                /* The driver is using a new ABI,
-                 * so the driver takes care of setting
-                 * the slave's hwaddr and bringing
-                 * it up again
-                 */
-        } else {
-                /* No hwaddr for master yet, so
-                 * set the slave's hwaddr to it
-                 */
-                if (abi_ver < 1) {
-                        /* For old ABI, the master needs to be
-                         * down before setting its hwaddr
-                         */
-                        res = set_if_down(master_ifname, master_flags.ifr_flags);
-                        if (res) {
-                                fprintf(stderr,
-                                        "Master '%s': Error: bring interface "
-                                        "down failed\n",
-                                        master_ifname);
-                                goto undo_mtu;
-                        }
-                }
-                res = set_master_hwaddr(master_ifname,
-                                        &(slave_hwaddr.ifr_hwaddr));
-                if (res) {
-                        fprintf(stderr,
-                                "Master '%s': Error: set hw address "
-                                "failed\n",
-                                master_ifname);
-                        goto undo_mtu;
-                }
-                if (abi_ver < 1) {
-                        /* For old ABI, bring the master
-                         * back up
-                         */
-                        res = set_if_up(master_ifname, master_flags.ifr_flags);
-                        if (res) {
-                                fprintf(stderr,
-                                        "Master '%s': Error: bring interface "
-                                        "up failed\n",
-                                        master_ifname);
-                                goto undo_master_mac;
-                        }
-                }
-                hwaddr_set = 1;
-        }
-        /* Do the real thing */
-        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
-        strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
-        if ((ioctl(skfd, SIOCBONDENSLAVE, &ifr) < 0) &&
-            (ioctl(skfd, BOND_ENSLAVE_OLD, &ifr) < 0)) {
-                saved_errno = errno;
-                v_print("Master '%s': Error: SIOCBONDENSLAVE failed: %s\n",
-                        master_ifname, strerror(saved_errno));
-                res = 1;
-        }
-        if (res) {
-                goto undo_master_mac;
-        }
-        return 0;
-/* rollback (best effort) */
-undo_master_mac:
-        set_master_hwaddr(master_ifname, &(master_hwaddr.ifr_hwaddr));
-        hwaddr_set = 0;
-        goto undo_mtu;
-undo_slave_mac:
-        set_slave_hwaddr(slave_ifname, &(slave_hwaddr.ifr_hwaddr));
-undo_mtu:
-        set_slave_mtu(slave_ifname, slave_mtu.ifr_mtu);
-        return res;
-}
-static int release(char *master_ifname, char *slave_ifname)
-{
-        struct ifreq ifr;
-        int res = 0;
-        if (!(slave_flags.ifr_flags & IFF_SLAVE)) {
-                fprintf(stderr,
-                        "Illegal operation: The specified slave interface "
-                        "'%s' is not a slave\n",
-                        slave_ifname);
-                return 1;
-        }
-        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
-        strncpy(ifr.ifr_slave, slave_ifname, IFNAMSIZ);
-        if ((ioctl(skfd, SIOCBONDRELEASE, &ifr) < 0) &&
-            (ioctl(skfd, BOND_RELEASE_OLD, &ifr) < 0)) {
-                saved_errno = errno;
-                v_print("Master '%s': Error: SIOCBONDRELEASE failed: %s\n",
-                        master_ifname, strerror(saved_errno));
-                return 1;
-        } else if (abi_ver < 1) {
-                /* The driver is using an old ABI, so we'll set the interface
-                 * down to avoid any conflicts due to same MAC/IP
-                 */
-                res = set_if_down(slave_ifname, slave_flags.ifr_flags);
-                if (res) {
-                        fprintf(stderr,
-                                "Slave '%s': Error: bring interface "
-                                "down failed\n",
-                                slave_ifname);
-                }
-        }
-        /* set to default mtu */
-        set_slave_mtu(slave_ifname, 1500);
-        return res;
-}
-static int get_if_settings(char *ifname, struct dev_ifr ifra[])
-{
-        int i;
-        int res = 0;
-        for (i = 0; ifra[i].req_ifr; i++) {
-                strncpy(ifra[i].req_ifr->ifr_name, ifname, IFNAMSIZ);
-                res = ioctl(skfd, ifra[i].req_type, ifra[i].req_ifr);
-                if (res < 0) {
-                        saved_errno = errno;
-                        v_print("Interface '%s': Error: %s failed: %s\n",
-                                ifname, ifra[i].req_name,
-                                strerror(saved_errno));
-                        return saved_errno;
-                }
-        }
-        return 0;
-}
-static int get_slave_flags(char *slave_ifname)
-{
-        int res = 0;
-        strncpy(slave_flags.ifr_name, slave_ifname, IFNAMSIZ);
-        res = ioctl(skfd, SIOCGIFFLAGS, &slave_flags);
-        if (res < 0) {
-                saved_errno = errno;
-                v_print("Slave '%s': Error: SIOCGIFFLAGS failed: %s\n",
-                        slave_ifname, strerror(saved_errno));
-        } else {
-                v_print("Slave %s: flags %04X.\n",
-                        slave_ifname, slave_flags.ifr_flags);
-        }
-        return res;
-}
-static int set_master_hwaddr(char *master_ifname, struct sockaddr *hwaddr)
-{
-        unsigned char *addr = (unsigned char *)hwaddr->sa_data;
-        struct ifreq ifr;
-        int res = 0;
-        strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
-        memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr));
-        res = ioctl(skfd, SIOCSIFHWADDR, &ifr);
-        if (res < 0) {
-                saved_errno = errno;
-                v_print("Master '%s': Error: SIOCSIFHWADDR failed: %s\n",
-                        master_ifname, strerror(saved_errno));
-                return res;
-        } else {
-                v_print("Master '%s': hardware address set to "
-                        "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
-                        master_ifname, addr[0], addr[1], addr[2],
-                        addr[3], addr[4], addr[5]);
-        }
-        return res;
-}
-static int set_slave_hwaddr(char *slave_ifname, struct sockaddr *hwaddr)
-{
-        unsigned char *addr = (unsigned char *)hwaddr->sa_data;
-        struct ifreq ifr;
-        int res = 0;
-        strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
-        memcpy(&(ifr.ifr_hwaddr), hwaddr, sizeof(struct sockaddr));
-        res = ioctl(skfd, SIOCSIFHWADDR, &ifr);
-        if (res < 0) {
-                saved_errno = errno;
-                v_print("Slave '%s': Error: SIOCSIFHWADDR failed: %s\n",
-                        slave_ifname, strerror(saved_errno));
-                if (saved_errno == EBUSY) {
-                        v_print("  The device is busy: it must be idle "
-                                "before running this command.\n");
-                } else if (saved_errno == EOPNOTSUPP) {
-                        v_print("  The device does not support setting "
-                                "the MAC address.\n"
-                                "  Your kernel likely does not support slave "
-                                "devices.\n");
-                } else if (saved_errno == EINVAL) {
-                        v_print("  The device's address type does not match "
-                                "the master's address type.\n");
-                }
-                return res;
-        } else {
-                v_print("Slave '%s': hardware address set to "
-                        "%2.2x:%2.2x:%2.2x:%2.2x:%2.2x:%2.2x.\n",
-                        slave_ifname, addr[0], addr[1], addr[2],
-                        addr[3], addr[4], addr[5]);
-        }
-        return res;
-}
-static int set_slave_mtu(char *slave_ifname, int mtu)
-{
-        struct ifreq ifr;
-        int res = 0;
-        ifr.ifr_mtu = mtu;
-        strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
-        res = ioctl(skfd, SIOCSIFMTU, &ifr);
-        if (res < 0) {
-                saved_errno = errno;
-                v_print("Slave '%s': Error: SIOCSIFMTU failed: %s\n",
-                        slave_ifname, strerror(saved_errno));
-        } else {
-                v_print("Slave '%s': MTU set to %d.\n", slave_ifname, mtu);
-        }
-        return res;
-}
-static int set_if_flags(char *ifname, short flags)
-{
-        struct ifreq ifr;
-        int res = 0;
-        ifr.ifr_flags = flags;
-        strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
-        res = ioctl(skfd, SIOCSIFFLAGS, &ifr);
-        if (res < 0) {
-                saved_errno = errno;
-                v_print("Interface '%s': Error: SIOCSIFFLAGS failed: %s\n",
-                        ifname, strerror(saved_errno));
-        } else {
-                v_print("Interface '%s': flags set to %04X.\n", ifname, flags);
-        }
-        return res;
-}
-static int set_if_up(char *ifname, short flags)
-{
-        return set_if_flags(ifname, flags | IFF_UP);
-}
-static int set_if_down(char *ifname, short flags)
-{
-        return set_if_flags(ifname, flags & ~IFF_UP);
-}
-static int clear_if_addr(char *ifname)
-{
-        struct ifreq ifr;
-        int res = 0;
-        strncpy(ifr.ifr_name, ifname, IFNAMSIZ);
-        ifr.ifr_addr.sa_family = AF_INET;
-        memset(ifr.ifr_addr.sa_data, 0, sizeof(ifr.ifr_addr.sa_data));
-        res = ioctl(skfd, SIOCSIFADDR, &ifr);
-        if (res < 0) {
-                saved_errno = errno;
-                v_print("Interface '%s': Error: SIOCSIFADDR failed: %s\n",
-                        ifname, strerror(saved_errno));
-        } else {
-                v_print("Interface '%s': address cleared\n", ifname);
-        }
-        return res;
-}
-static int set_if_addr(char *master_ifname, char *slave_ifname)
-{
-        struct ifreq ifr;
-        int res;
-        unsigned char *ipaddr;
-        int i;
-        struct {
-                char *req_name;
-                char *desc;
-                int g_ioctl;
-                int s_ioctl;
-        } ifra[] = {
-                {"IFADDR", "addr", SIOCGIFADDR, SIOCSIFADDR},
-                {"DSTADDR", "destination addr", SIOCGIFDSTADDR, SIOCSIFDSTADDR},
-                {"BRDADDR", "broadcast addr", SIOCGIFBRDADDR, SIOCSIFBRDADDR},
-                {"NETMASK", "netmask", SIOCGIFNETMASK, SIOCSIFNETMASK},
-                {NULL, NULL, 0, 0},
-        };
-        for (i = 0; ifra[i].req_name; i++) {
-                strncpy(ifr.ifr_name, master_ifname, IFNAMSIZ);
-                res = ioctl(skfd, ifra[i].g_ioctl, &ifr);
-                if (res < 0) {
-                        int saved_errno = errno;
-                        v_print("Interface '%s': Error: SIOCG%s failed: %s\n",
-                                master_ifname, ifra[i].req_name,
-                                strerror(saved_errno));
-                        ifr.ifr_addr.sa_family = AF_INET;
-                        memset(ifr.ifr_addr.sa_data, 0,
-                               sizeof(ifr.ifr_addr.sa_data));
-                }
-                strncpy(ifr.ifr_name, slave_ifname, IFNAMSIZ);
-                res = ioctl(skfd, ifra[i].s_ioctl, &ifr);
-                if (res < 0) {
-                        int saved_errno = errno;
-                        v_print("Interface '%s': Error: SIOCS%s failed: %s\n",
-                                slave_ifname, ifra[i].req_name,
-                                strerror(saved_errno));
-                }
-                ipaddr = (unsigned char *)ifr.ifr_addr.sa_data;
-                v_print("Interface '%s': set IP %s to %d.%d.%d.%d\n",
-                        slave_ifname, ifra[i].desc,
-                        ipaddr[0], ipaddr[1], ipaddr[2], ipaddr[3]);
-        }
-        return 0;
-}
-/*
- * Local variables:
- *  version-control: t
- *  kept-new-versions: 5
- *  c-indent-level: 4
- *  c-basic-offset: 4
- *  tab-width: 4
- *  compile-command: "gcc -Wall -Wstrict-prototypes -O -I/usr/src/linux/include ifenslave.c -o ifenslave"
- * End:
- */
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index f98ca633b528..10742902146f 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -183,7 +183,7 @@ tcp_early_retrans - INTEGER
        for triggering fast retransmit when the amount of outstanding data is
        small and when no previously unsent data can be transmitted (such
        that limited transmit could be used). Also controls the use of
-        Tail loss probe (TLP) that converts RTOs occuring due to tail
+        Tail loss probe (TLP) that converts RTOs occurring due to tail
        losses into fast recovery (draft-dukkipati-tcpm-tcp-loss-probe-01).
        Possible values:
                0 disables ER
@@ -420,10 +420,10 @@ tcp_synack_retries - INTEGER
        for a passive TCP connection will happen after 63seconds.
 tcp_syncookies - BOOLEAN
-        Only valid when the kernel was compiled with CONFIG_SYNCOOKIES
+        Only valid when the kernel was compiled with CONFIG_SYN_COOKIES
        Send out syncookies when the syn backlog queue of a socket
        overflows. This is to prevent against the common 'SYN flood attack'
-        Default: FALSE
+        Default: 1
        Note, that syncookies is fallback facility.
        It MUST NOT be used to help highly loaded servers to stand
@@ -685,6 +685,15 @@ ip_dynaddr - BOOLEAN
        occurs.
        Default: 0
+ip_early_demux - BOOLEAN
+        Optimize input packet processing down to one demux for
+        certain kinds of local sockets.  Currently we only do this
+        for established TCP sockets.
+        It may add an additional cost for pure routing workloads that
+        reduces overall throughput, in such case you should disable it.
+        Default: 1
 icmp_echo_ignore_all - BOOLEAN
        If set non-zero, then the kernel will ignore all ICMP ECHO
        requests sent to it.
@@ -729,7 +738,7 @@ icmp_ignore_bogus_error_responses - BOOLEAN
        frames.  Such violations are normally logged via a kernel warning.
        If this is set to TRUE, the kernel will not give such warnings, which
        will avoid log file clutter.
-        Default: FALSE
+        Default: 1
 icmp_errors_use_inbound_ifaddr - BOOLEAN
diff --git a/Documentation/networking/ipvs-sysctl.txt b/Documentation/networking/ipvs-sysctl.txt
index 9573d0c48c6e..7a3c04729591 100644
--- a/Documentation/networking/ipvs-sysctl.txt
+++ b/Documentation/networking/ipvs-sysctl.txt
@@ -181,6 +181,19 @@ snat_reroute - BOOLEAN
        always be the same as the original route so it is an optimisation
        to disable snat_reroute and avoid the recalculation.
+sync_persist_mode - INTEGER
+        default 0
+        Controls the synchronisation of connections when using persistence
+        0: All types of connections are synchronised
+        1: Attempt to reduce the synchronisation traffic depending on
+        the connection type. For persistent services avoid synchronisation
+        for normal connections, do it only for persistence templates.
+        In such case, for TCP and SCTP it may need enabling sloppy_tcp and
+        sloppy_sctp flags on backup servers. For non-persistent services
+        such optimization is not applied, mode 0 is assumed.
 sync_version - INTEGER
        default 1
diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt
index 1c2dab409625..533378839546 100644
--- a/Documentation/networking/netlink_mmap.txt
+++ b/Documentation/networking/netlink_mmap.txt
@@ -54,7 +54,7 @@ it will use an allocated socket buffer as usual and the contents will be
 copied to the ring on transmission, nullifying most of the performance gains.
 Dumps of kernel databases automatically support memory mapped I/O.
-Conversion of the transmit path involves changing message contruction to
+Conversion of the transmit path involves changing message construction to
 use memory from the TX ring instead of (usually) a buffer declared on the
 stack and setting up the frame header approriately. Optionally poll() can
 be used to wait for free frames in the TX ring.
@@ -65,8 +65,8 @@ Structured and definitions for using memory mapped I/O are contained in
 RX and TX rings
 ----------------
-Each ring contains a number of continous memory blocks, containing frames of
+Each ring contains a number of continuous memory blocks, containing frames of
-fixed size dependant on the parameters used for ring setup.
+fixed size dependent on the parameters used for ring setup.
 Ring:   [ block 0 ]
                [ frame 0 ]
@@ -80,7 +80,7 @@ Ring:	[ block 0 ]
                [ frame 2 * n + 1 ]
 The blocks are only visible to the kernel, from the point of view of user-space
-the ring just contains the frames in a continous memory zone.
+the ring just contains the frames in a continuous memory zone.
 The ring parameters used for setting up the ring are defined as follows:
@@ -91,7 +91,7 @@ struct nl_mmap_req {
        unsigned int    nm_frame_nr;
 };
-Frames are grouped into blocks, where each block is a continous region of memory
+Frames are grouped into blocks, where each block is a continuous region of memory
 and holds nm_block_size / nm_frame_size frames. The total number of frames in
 the ring is nm_frame_nr. The following invariants hold:
@@ -113,8 +113,8 @@ Some parameters are constrained, specifically:
 - nm_frame_nr must equal the actual number of frames as specified above.
-When the kernel can't allocate phsyically continous memory for a ring block,
+When the kernel can't allocate physically continuous memory for a ring block,
-it will fall back to use physically discontinous memory. This might affect
+it will fall back to use physically discontinuous memory. This might affect
 performance negatively, in order to avoid this the nm_frame_size parameter
 should be chosen to be as small as possible for the required frame size and
 the number of blocks should be increased instead.
@@ -274,9 +274,9 @@ This example assumes some ring parameters of the ring setup are available.
                        /* Get next frame header */
                        hdr = rx_ring + frame_offset;
-                        if (hdr->nm_status == NL_MMAP_STATUS_VALID)
+                        if (hdr->nm_status == NL_MMAP_STATUS_VALID) {
                                /* Regular memory mapped frame */
-                                nlh = (void *hdr) + NL_MMAP_HDRLEN;
+                                nlh = (void *)hdr + NL_MMAP_HDRLEN;
                                len = hdr->nm_len;
                                /* Release empty message immediately. May happen
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 23dd80e82b8e..8572796b1eb6 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -704,6 +704,12 @@ So it seems to be a good candidate to be used with packet fanout.
 Minimal example code by Daniel Borkmann based on Chetan Loke's lolpcap (compile
 it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
+/* Written from scratch, but kernel-to-user space API usage
+ * dissected from lolpcap:
+ *  Copyright 2011, Chetan Loke <loke.chetan@gmail.com>
+ *  License: GPL, version 2.0
+ */
 #include <stdio.h>
 #include <stdlib.h>
 #include <stdint.h>
@@ -722,27 +728,6 @@ it with gcc -Wall -O2 blob.c, and try things like "./a.out eth0", etc.):
 #include <linux/if_ether.h>
 #include <linux/ip.h>
-#define BLOCK_SIZE              (1 << 22)
-#define FRAME_SIZE              2048
-#define NUM_BLOCKS              64
-#define NUM_FRAMES              ((BLOCK_SIZE * NUM_BLOCKS) / FRAME_SIZE)
-#define BLOCK_RETIRE_TOV_IN_MS  64
-#define BLOCK_PRIV_AREA_SZ      13
-#define ALIGN_8(x)              (((x) + 8 - 1) & ~(8 - 1))
-#define BLOCK_STATUS(x)         ((x)->h1.block_status)
-#define BLOCK_NUM_PKTS(x)       ((x)->h1.num_pkts)
-#define BLOCK_O2FP(x)           ((x)->h1.offset_to_first_pkt)
-#define BLOCK_LEN(x)            ((x)->h1.blk_len)
-#define BLOCK_SNUM(x)           ((x)->h1.seq_num)
-#define BLOCK_O2PRIV(x)         ((x)->offset_to_priv)
-#define BLOCK_PRIV(x)           ((void *) ((uint8_t *) (x) + BLOCK_O2PRIV(x)))
-#define BLOCK_HDR_LEN           (ALIGN_8(sizeof(struct block_desc)))
-#define BLOCK_PLUS_PRIV(sz_pri) (BLOCK_HDR_LEN + ALIGN_8((sz_pri)))
 #ifndef likely
 # define likely(x)              __builtin_expect(!!(x), 1)
 #endif
@@ -765,7 +750,7 @@ struct ring {
 static unsigned long packets_total = 0, bytes_total = 0;
 static sig_atomic_t sigint = 0;
-void sighandler(int num)
+static void sighandler(int num)
 {
        sigint = 1;
 }
@@ -774,6 +759,8 @@ static int setup_socket(struct ring *ring, char *netdev)
 {
        int err, i, fd, v = TPACKET_V3;
        struct sockaddr_ll ll;
+        unsigned int blocksiz = 1 << 22, framesiz = 1 << 11;
+        unsigned int blocknum = 64;
        fd = socket(AF_PACKET, SOCK_RAW, htons(ETH_P_ALL));
        if (fd < 0) {
@@ -788,13 +775,12 @@ static int setup_socket(struct ring *ring, char *netdev)
        }
        memset(&ring->req, 0, sizeof(ring->req));
-        ring->req.tp_block_size = BLOCK_SIZE;
+        ring->req.tp_block_size = blocksiz;
-        ring->req.tp_frame_size = FRAME_SIZE;
+        ring->req.tp_frame_size = framesiz;
-        ring->req.tp_block_nr = NUM_BLOCKS;
+        ring->req.tp_block_nr = blocknum;
-        ring->req.tp_frame_nr = NUM_FRAMES;
+        ring->req.tp_frame_nr = (blocksiz * blocknum) / framesiz;
-        ring->req.tp_retire_blk_tov = BLOCK_RETIRE_TOV_IN_MS;
+        ring->req.tp_retire_blk_tov = 60;
-        ring->req.tp_sizeof_priv = BLOCK_PRIV_AREA_SZ;
+        ring->req.tp_feature_req_word = TP_FT_REQ_FILL_RXHASH;
-        ring->req.tp_feature_req_word |= TP_FT_REQ_FILL_RXHASH;
        err = setsockopt(fd, SOL_PACKET, PACKET_RX_RING, &ring->req,
                         sizeof(ring->req));
@@ -804,8 +790,7 @@ static int setup_socket(struct ring *ring, char *netdev)
        }
        ring->map = mmap(NULL, ring->req.tp_block_size * ring->req.tp_block_nr,
-                         PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED,
+                         PROT_READ | PROT_WRITE, MAP_SHARED | MAP_LOCKED, fd, 0);
-                         fd, 0);
        if (ring->map == MAP_FAILED) {
                perror("mmap");
                exit(1);
@@ -835,58 +820,6 @@ static int setup_socket(struct ring *ring, char *netdev)
        return fd;
 }
-#ifdef __checked
-static uint64_t prev_block_seq_num = 0;
-void assert_block_seq_num(struct block_desc *pbd)
-{
-        if (unlikely(prev_block_seq_num + 1 != BLOCK_SNUM(pbd))) {
-                printf("prev_block_seq_num:%"PRIu64", expected seq:%"PRIu64" != "
-                       "actual seq:%"PRIu64"\n", prev_block_seq_num,
-                       prev_block_seq_num + 1, (uint64_t) BLOCK_SNUM(pbd));
-                exit(1);
-        }
-        prev_block_seq_num = BLOCK_SNUM(pbd);
-}
-static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num)
-{
-        if (BLOCK_NUM_PKTS(pbd)) {
-                if (unlikely(bytes != BLOCK_LEN(pbd))) {
-                        printf("block:%u with %upackets, expected len:%u != actual len:%u\n",
-                               block_num, BLOCK_NUM_PKTS(pbd), bytes, BLOCK_LEN(pbd));
-                        exit(1);
-                }
-        } else {
-                if (unlikely(BLOCK_LEN(pbd) != BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ))) {
-                        printf("block:%u, expected len:%lu != actual len:%u\n",
-                               block_num, BLOCK_HDR_LEN, BLOCK_LEN(pbd));
-                        exit(1);
-                }
-        }
-}
-static void assert_block_header(struct block_desc *pbd, const int block_num)
-{
-        uint32_t block_status = BLOCK_STATUS(pbd);
-        if (unlikely((block_status & TP_STATUS_USER) == 0)) {
-                printf("block:%u, not in TP_STATUS_USER\n", block_num);
-                exit(1);
-        }
-        assert_block_seq_num(pbd);
-}
-#else
-static inline void assert_block_header(struct block_desc *pbd, const int block_num)
-{
-}
-static void assert_block_len(struct block_desc *pbd, uint32_t bytes, int block_num)
-{
-}
-#endif
 static void display(struct tpacket3_hdr *ppd)
 {
        struct ethhdr *eth = (struct ethhdr *) ((uint8_t *) ppd + ppd->tp_mac);
@@ -916,37 +849,27 @@ static void display(struct tpacket3_hdr *ppd)
 static void walk_block(struct block_desc *pbd, const int block_num)
 {
-        int num_pkts = BLOCK_NUM_PKTS(pbd), i;
+        int num_pkts = pbd->h1.num_pkts, i;
        unsigned long bytes = 0;
-        unsigned long bytes_with_padding = BLOCK_PLUS_PRIV(BLOCK_PRIV_AREA_SZ);
        struct tpacket3_hdr *ppd;
-        assert_block_header(pbd, block_num);
+        ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd +
+                                       pbd->h1.offset_to_first_pkt);
-        ppd = (struct tpacket3_hdr *) ((uint8_t *) pbd + BLOCK_O2FP(pbd));
        for (i = 0; i < num_pkts; ++i) {
                bytes += ppd->tp_snaplen;
-                if (ppd->tp_next_offset)
-                        bytes_with_padding += ppd->tp_next_offset;
-                else
-                        bytes_with_padding += ALIGN_8(ppd->tp_snaplen + ppd->tp_mac);
                display(ppd);
-                ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd + ppd->tp_next_offset);
+                ppd = (struct tpacket3_hdr *) ((uint8_t *) ppd +
-                __sync_synchronize();
+                                               ppd->tp_next_offset);
        }
-        assert_block_len(pbd, bytes_with_padding, block_num);
        packets_total += num_pkts;
        bytes_total += bytes;
 }
-void flush_block(struct block_desc *pbd)
+static void flush_block(struct block_desc *pbd)
 {
-        BLOCK_STATUS(pbd) = TP_STATUS_KERNEL;
+        pbd->h1.block_status = TP_STATUS_KERNEL;
-        __sync_synchronize();
 }
 static void teardown_socket(struct ring *ring, int fd)
@@ -962,7 +885,7 @@ int main(int argc, char **argp)
        socklen_t len;
        struct ring ring;
        struct pollfd pfd;
-        unsigned int block_num = 0;
+        unsigned int block_num = 0, blocks = 64;
        struct block_desc *pbd;
        struct tpacket_stats_v3 stats;
@@ -984,15 +907,15 @@ int main(int argc, char **argp)
        while (likely(!sigint)) {
                pbd = (struct block_desc *) ring.rd[block_num].iov_base;
-retry_block:
-                if ((BLOCK_STATUS(pbd) & TP_STATUS_USER) == 0) {
+                if ((pbd->h1.block_status & TP_STATUS_USER) == 0) {
                        poll(&pfd, 1, -1);
-                        goto retry_block;
+                        continue;
                }
                walk_block(pbd, block_num);
                flush_block(pbd);
-                block_num = (block_num + 1) % NUM_BLOCKS;
+                block_num = (block_num + 1) % blocks;
        }
        len = sizeof(stats);
diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt
index 579994afbe06..ca6977f5b2ed 100644
--- a/Documentation/networking/scaling.txt
+++ b/Documentation/networking/scaling.txt
@@ -163,6 +163,64 @@ and unnecessary. If there are fewer hardware queues than CPUs, then
 RPS might be beneficial if the rps_cpus for each queue are the ones that
 share the same memory domain as the interrupting CPU for that queue.
+==== RPS Flow Limit
+RPS scales kernel receive processing across CPUs without introducing
+reordering. The trade-off to sending all packets from the same flow
+to the same CPU is CPU load imbalance if flows vary in packet rate.
+In the extreme case a single flow dominates traffic. Especially on
+common server workloads with many concurrent connections, such
+behavior indicates a problem such as a misconfiguration or spoofed
+source Denial of Service attack.
+Flow Limit is an optional RPS feature that prioritizes small flows
+during CPU contention by dropping packets from large flows slightly
+ahead of those from small flows. It is active only when an RPS or RFS
+destination CPU approaches saturation.  Once a CPU's input packet
+queue exceeds half the maximum queue length (as set by sysctl
+net.core.netdev_max_backlog), the kernel starts a per-flow packet
+count over the last 256 packets. If a flow exceeds a set ratio (by
+default, half) of these packets when a new packet arrives, then the
+new packet is dropped. Packets from other flows are still only
+dropped once the input packet queue reaches netdev_max_backlog.
+No packets are dropped when the input packet queue length is below
+the threshold, so flow limit does not sever connections outright:
+even large flows maintain connectivity.
+== Interface
+Flow limit is compiled in by default (CONFIG_NET_FLOW_LIMIT), but not
+turned on. It is implemented for each CPU independently (to avoid lock
+and cache contention) and toggled per CPU by setting the relevant bit
+in sysctl net.core.flow_limit_cpu_bitmap. It exposes the same CPU
+bitmap interface as rps_cpus (see above) when called from procfs:
+ /proc/sys/net/core/flow_limit_cpu_bitmap
+Per-flow rate is calculated by hashing each packet into a hashtable
+bucket and incrementing a per-bucket counter. The hash function is
+the same that selects a CPU in RPS, but as the number of buckets can
+be much larger than the number of CPUs, flow limit has finer-grained
+identification of large flows and fewer false positives. The default
+table has 4096 buckets. This value can be modified through sysctl
+ net.core.flow_limit_table_len
+The value is only consulted when a new table is allocated. Modifying
+it does not update active tables.
+== Suggested Configuration
+Flow limit is useful on systems with many concurrent connections,
+where a single connection taking up 50% of a CPU indicates a problem.
+In such environments, enable the feature on all CPUs that handle
+network rx interrupts (as set in /proc/irq/N/smp_affinity).
+The feature depends on the input packet queue length to exceed
+the flow limit threshold (50%) + the flow history length (256).
+Setting net.core.netdev_max_backlog to either 1000 or 10000
+performed well in experiments.
 RFS: Receive Flow Steering
 ==========================
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index b4038ffb3bc5..9a8041dcbb53 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -359,7 +359,7 @@ steps you should take:
 - OK, it's a driver problem.
   You need to generate a report.  Typically this is an email to the
-   maintainer and/or linux-net@vger.kernel.org.  The maintainer's
+   maintainer and/or netdev@vger.kernel.org.  The maintainer's
   email address will be in the driver source or in the MAINTAINERS file.
 - The contents of your report will vary a lot depending upon the
diff --git a/Documentation/parisc/registers b/Documentation/parisc/registers
index dd3caddd1ad9..10c7d1730f5d 100644
--- a/Documentation/parisc/registers
+++ b/Documentation/parisc/registers
@@ -78,6 +78,14 @@ Shadow Registers		used by interruption handler code
 TOC enable bit                  1
 =========================================================================
+The PA-RISC architecture defines 7 registers as "shadow registers".
+Those are used in RETURN FROM INTERRUPTION AND RESTORE instruction to reduce
+the state save and restore time by eliminating the need for general register
+(GR) saves and restores in interruption handlers.
+Shadow registers are the GRs 1, 8, 9, 16, 17, 24, and 25.
+=========================================================================
 Register usage notes, originally from John Marvin, with some additional
 notes from Randolph Chung.
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index 447fd4cd54ec..052e13af2d38 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -203,15 +203,8 @@ using a certain resistor value - pull up and pull down - so that the pin has a
 stable value when nothing is driving the rail it is connected to, or when it's
 unconnected.
-Pin configuration can be programmed either using the explicit APIs described
+Pin configuration can be programmed by adding configuration entries into the
-immediately below, or by adding configuration entries into the mapping table;
+mapping table; see section "Board/machine configuration" below.
-see section "Board/machine configuration" below.
-For example, a platform may do the following to pull up a pin to VDD:
-#include <linux/pinctrl/consumer.h>
-ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP);
 The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP
 above, is entirely defined by the pin controller driver.
@@ -298,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 modeled 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:
@@ -350,6 +343,23 @@ chip b:
 - GPIO range : [48 .. 55]
 - pin range  : [64 .. 71]
+The above examples assume the mapping between the GPIOs and pins is
+linear. If the mapping is sparse or haphazard, an array of arbitrary pin
+numbers can be encoded in the range like this:
+static const unsigned range_pins[] = { 14, 1, 22, 17, 10, 8, 6, 2 };
+static struct pinctrl_gpio_range gpio_range = {
+        .name = "chip",
+        .id = 0,
+        .base = 32,
+        .pins = &range_pins,
+        .npins = ARRAY_SIZE(range_pins),
+        .gc = &chip;
+};
+In this case the pin_base property will be ignored.
 When GPIO-specific functions in the pin control subsystem are called, these
 ranges will be used to look up the appropriate pin controller by inspecting
 and matching the pin to the pin ranges across all controllers. When a
@@ -357,9 +367,9 @@ pin controller handling the matching range is found, GPIO-specific functions
 will be called on that specific pin controller.
 For all functionalities dealing with pin biasing, pin muxing etc, the pin
-controller subsystem will subtract the range's .base offset from the passed
+controller subsystem will look up the corresponding pin number from the passed
-in gpio number, and add the ranges's .pin_base offset to retrive a pin number.
+in gpio number, and use the range's internals to retrive a pin number. After
-After that, the subsystem passes it on to the pin control driver, so the driver
+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
 the range ID value, so that the pin controller knows which range it should
 deal with.
@@ -368,6 +378,7 @@ Calling pinctrl_add_gpio_range from pinctrl driver is DEPRECATED. Please see
 section 2.1 of Documentation/devicetree/bindings/gpio/gpio.txt on how to bind
 pinctrl and gpio drivers.
 PINMUX interfaces
 =================
@@ -1226,8 +1237,8 @@ setting up the config and muxing for the pins right before the device is
 probing, nevertheless orthogonal to the GPIO subsystem.
 But there are also situations where it makes sense for the GPIO subsystem
-to communicate directly with with the pinctrl subsystem, using the latter
+to communicate directly with the pinctrl subsystem, using the latter as a
-as a back-end. This is when the GPIO driver may call out to the functions
+back-end. This is when the GPIO driver may call out to the functions
 described in the section "Pin control interaction with the GPIO subsystem"
 above. This only involves per-pin multiplexing, and will be completely
 hidden behind the gpio_*() function namespace. In this case, the driver
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 504dfe4d52eb..a66c9821b5ce 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -268,7 +268,7 @@ situations.
 System Power Management Phases
 ------------------------------
 Suspending or resuming the system is done in several phases.  Different phases
-are used for standby or memory sleep states ("suspend-to-RAM") and the
+are used for freeze, standby, and memory sleep states ("suspend-to-RAM") and the
 hibernation state ("suspend-to-disk").  Each phase involves executing callbacks
 for every device before the next phase begins.  Not all busses or classes
 support all these callbacks and not all drivers use all the callbacks.  The
@@ -309,7 +309,8 @@ execute the corresponding method from dev->driver->pm instead if there is one.
 Entering System Suspend
 -----------------------
-When the system goes into the standby or memory sleep state, the phases are:
+When the system goes into the freeze, standby or memory sleep state,
+the phases are:
                prepare, suspend, suspend_late, suspend_noirq.
@@ -368,7 +369,7 @@ the devices that were suspended.
 Leaving System Suspend
 ----------------------
-When resuming from standby or memory sleep, the phases are:
+When resuming from freeze, standby or memory sleep, the phases are:
                resume_noirq, resume_early, resume, complete.
@@ -433,8 +434,8 @@ the system log.
 Entering Hibernation
 --------------------
-Hibernating the system is more complicated than putting it into the standby or
+Hibernating the system is more complicated than putting it into the other
-memory sleep state, because it involves creating and saving a system image.
+sleep states, because it involves creating and saving a system image.
 Therefore there are more phases for hibernation, with a different set of
 callbacks.  These phases always run after tasks have been frozen and memory has
 been freed.
@@ -485,8 +486,8 @@ image forms an atomic snapshot of the system state.
 At this point the system image is saved, and the devices then need to be
 prepared for the upcoming system shutdown.  This is much like suspending them
-before putting the system into the standby or memory sleep state, and the phases
+before putting the system into the freeze, standby or memory sleep state,
-are similar.
+and the phases are similar.
    9.  The prepare phase is discussed above.
diff --git a/Documentation/power/interface.txt b/Documentation/power/interface.txt
index c537834af005..f1f0f59a7c47 100644
--- a/Documentation/power/interface.txt
+++ b/Documentation/power/interface.txt
@@ -7,8 +7,8 @@ running. The interface exists in /sys/power/ directory (assuming sysfs
 is mounted at /sys). 
 /sys/power/state controls system power state. Reading from this file
-returns what states are supported, which is hard-coded to 'standby'
+returns what states are supported, which is hard-coded to 'freeze',
-(Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
+'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
 (Suspend-to-Disk). 
 Writing to this file one of those strings causes the system to
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt
index c2a4a346c0d9..a81fa254303d 100644
--- a/Documentation/power/notifiers.txt
+++ b/Documentation/power/notifiers.txt
@@ -15,8 +15,10 @@ A suspend/hibernation notifier may be used for this purpose.
 The subsystems or drivers having such needs can register suspend notifiers that
 will be called upon the following events by the PM core:
-PM_HIBERNATION_PREPARE  The system is going to hibernate or suspend, tasks will
+PM_HIBERNATION_PREPARE  The system is going to hibernate, tasks will be frozen
-                        be frozen immediately.
+                        immediately. This is different from PM_SUSPEND_PREPARE
+                        below because here we do additional work between notifiers
+                        and drivers freezing.
 PM_POST_HIBERNATION     The system memory state has been restored from a
                        hibernation image or an error occurred during
diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt
index 79a2a58425ee..483632087788 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
@@ -7,7 +7,7 @@ one of the parameters.
 Two different PM QoS frameworks are available:
 1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput.
 2. the per-device PM QoS framework provides the API to manage the per-device latency
-constraints.
+constraints and PM QoS flags.
 Each parameters have defined units:
 * latency: usec
@@ -86,13 +86,17 @@ To remove the user mode request for a target value simply close the device
 node.
-2. PM QoS per-device latency framework
+2. PM QoS per-device latency and flags framework
+For each device, there are two lists of PM QoS requests. One is maintained
+along with the aggregated target of latency value and the other is for PM QoS
+flags. Values are updated in response to changes of the request list.
+Target latency value is simply the minimum of the request values held in the
+parameter list elements.  The PM QoS flags aggregate value is a gather (bitwise
+OR) of all list elements' values. Two device PM QoS flags are defined currently:
+PM_QOS_FLAG_NO_POWER_OFF and PM_QOS_FLAG_REMOTE_WAKEUP.
-For each device a list of performance requests is maintained along with
-an aggregated target value.  The aggregated target value is updated with
-changes to the request list or elements of the list.  Typically the
-aggregated target value is simply the max or min of the request values held
-in the parameter list elements.
 Note: the aggregated target value is implemented as an atomic variable so that
 reading the aggregated value does not require any locking mechanism.
@@ -119,6 +123,38 @@ the request.
 s32 dev_pm_qos_read_value(device):
 Returns the aggregated value for a given device's constraints list.
+enum pm_qos_flags_status dev_pm_qos_flags(device, mask)
+Check PM QoS flags of the given device against the given mask of flags.
+The meaning of the return values is as follows:
+        PM_QOS_FLAGS_ALL: All flags from the mask are set
+        PM_QOS_FLAGS_SOME: Some flags from the mask are set
+        PM_QOS_FLAGS_NONE: No flags from the mask are set
+        PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
+                        initialized or the list of requests is empty.
+int dev_pm_qos_add_ancestor_request(dev, handle, value)
+Add a PM QoS request for the first direct ancestor of the given device whose
+power.ignore_children flag is unset.
+int dev_pm_qos_expose_latency_limit(device, value)
+Add a request to the device's PM QoS list of latency constraints and create
+a sysfs attribute pm_qos_resume_latency_us under the device's power directory
+allowing user space to manipulate that request.
+void dev_pm_qos_hide_latency_limit(device)
+Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
+PM QoS list of latency constraints and remove sysfs attribute pm_qos_resume_latency_us
+from the device's power directory.
+int dev_pm_qos_expose_flags(device, value)
+Add a request to the device's PM QoS list of flags and create sysfs attributes
+pm_qos_no_power_off and pm_qos_remote_wakeup under the device's power directory
+allowing user space to change these flags' value.
+void dev_pm_qos_hide_flags(device)
+Drop the request added by dev_pm_qos_expose_flags() from the device's PM QoS list
+of flags and remove sysfs attributes pm_qos_no_power_off and pm_qos_remote_wakeup
+under the device's power directory.
 Notification mechanisms:
 The per-device PM QoS framework has 2 different and distinct notification trees:
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 6c9f5d9aa115..71d8fe4e75d3 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -144,8 +144,12 @@ The action performed by the idle callback is totally dependent on the subsystem
 (or driver) in question, but the expected and recommended action is to check
 if the device can be suspended (i.e. if all of the conditions necessary for
 suspending the device are satisfied) and to queue up a suspend request for the
-device in that case.  The value returned by this callback is ignored by the PM
+device in that case.  If there is no idle callback, or if the callback returns
-core.
+0, then the PM core will attempt to carry out a runtime suspend of the device;
+in essence, it will call pm_runtime_suspend() directly.  To prevent this (for
+example, if the callback routine has started a delayed suspend), the routine
+should return a non-zero value.  Negative error return codes are ignored by the
+PM core.
 The helper functions provided by the PM core, described in Section 4, guarantee
 that the following constraints are met with respect to runtime PM callbacks for
@@ -301,9 +305,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
      removing the device from device hierarchy
  int pm_runtime_idle(struct device *dev);
-    - execute the subsystem-level idle callback for the device; returns 0 on
+    - execute the subsystem-level idle callback for the device; returns an
-      success or error code on failure, where -EINPROGRESS means that
+      error code on failure, where -EINPROGRESS means that ->runtime_idle() is
-      ->runtime_idle() is already being executed
+      already being executed; if there is no callback or the callback returns 0
+      then run pm_runtime_suspend(dev) and return its result
  int pm_runtime_suspend(struct device *dev);
    - execute the subsystem-level suspend callback for the device; returns 0 on
@@ -660,11 +665,6 @@ Subsystems may wish to conserve code space by using the set of generic power
 management callbacks provided by the PM core, defined in
 driver/base/power/generic_ops.c:
-  int pm_generic_runtime_idle(struct device *dev);
-    - invoke the ->runtime_idle() callback provided by the driver of this
-      device, if defined, and call pm_runtime_suspend() for this device if the
-      return value is 0 or the callback is not defined
  int pm_generic_runtime_suspend(struct device *dev);
    - invoke the ->runtime_suspend() callback provided by the driver of this
      device and return its result, or return -EINVAL if not defined
diff --git a/Documentation/power/states.txt b/Documentation/power/states.txt
index 4416b28630df..442d43df9b25 100644
--- a/Documentation/power/states.txt
+++ b/Documentation/power/states.txt
@@ -2,12 +2,26 @@
 System Power Management States
-The kernel supports three power management states generically, though
+The kernel supports four power management states generically, though
-each is dependent on platform support code to implement the low-level
+one is generic and the other three are dependent on platform support
-details for each state. This file describes each state, what they are
+code to implement the low-level details for each state.
+This file describes each state, what they are
 commonly called, what ACPI state they map to, and what string to write
 to /sys/power/state to enter that state
+state:          Freeze / Low-Power Idle
+ACPI state:     S0
+String:         "freeze"
+This state is a generic, pure software, light-weight, low-power state.
+It allows more energy to be saved relative to idle by freezing user
+space and putting all I/O devices into low-power states (possibly
+lower-power than available at run time), such that the processors can
+spend more time in their idle states.
+This state can be used for platforms without Standby/Suspend-to-RAM
+support, or it can be used in addition to Suspend-to-RAM (memory sleep)
+to provide reduced resume latency.
 State:          Standby / Power-On Suspend
 ACPI State:     S1
@@ -22,9 +36,6 @@ We try to put devices in a low-power state equivalent to D1, which
 also offers low power savings, but low resume latency. Not all devices
 support D1, and those that don't are left on. 
-A transition from Standby to the On state should take about 1-2
-seconds. 
 State:          Suspend-to-RAM
 ACPI State:     S3
@@ -42,9 +53,6 @@ transition back to the On state.
 For at least ACPI, STR requires some minimal boot-strapping code to
 resume the system from STR. This may be true on other platforms. 
-A transition from Suspend-to-RAM to the On state should take about
-3-5 seconds. 
 State:          Suspend-to-disk
 ACPI State:     S4
@@ -74,7 +82,3 @@ low-power state (like ACPI S4), or it may simply power down. Powering
 down offers greater savings, and allows this mechanism to work on any
 system. However, entering a real low-power state allows the user to
 trigger wake up events (e.g. pressing a key or opening a laptop lid).
-A transition from Suspend-to-Disk to the On state should take about 30
-seconds, though it's typically a bit more with the current
-implementation. 
diff --git a/Documentation/power/video_extension.txt b/Documentation/power/video_extension.txt
deleted file mode 100644
index b2f9b1598ac2..000000000000
--- a/Documentation/power/video_extension.txt
+++ /dev/null
@@ -1,37 +0,0 @@
-ACPI video extensions
-~~~~~~~~~~~~~~~~~~~~~
-This driver implement the ACPI Extensions For Display Adapters for
-integrated graphics devices on motherboard, as specified in ACPI 2.0
-Specification, Appendix B, allowing to perform some basic control like
-defining the video POST device, retrieving EDID information or to
-setup a video output, etc.  Note that this is an ref. implementation
-only.  It may or may not work for your integrated video device.
-Interfaces exposed to userland through /proc/acpi/video:
-VGA/info : display the supported video bus device capability like Video ROM, CRT/LCD/TV.
-VGA/ROM :  Used to get a copy of the display devices' ROM data (up to 4k).
-VGA/POST_info : Used to determine what options are implemented.
-VGA/POST : Used to get/set POST device.
-VGA/DOS : Used to get/set ownership of output switching:
-        Please refer ACPI spec B.4.1 _DOS
-VGA/CRT : CRT output
-VGA/LCD : LCD output
-VGA/TVO : TV output
-VGA/*/brightness : Used to get/set brightness of output device
-Notify event through /proc/acpi/event:
-#define ACPI_VIDEO_NOTIFY_SWITCH        0x80
-#define ACPI_VIDEO_NOTIFY_PROBE         0x81
-#define ACPI_VIDEO_NOTIFY_CYCLE         0x82
-#define ACPI_VIDEO_NOTIFY_NEXT_OUTPUT   0x83
-#define ACPI_VIDEO_NOTIFY_PREV_OUTPUT   0x84
-#define ACPI_VIDEO_NOTIFY_CYCLE_BRIGHTNESS      0x82
-#define ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS        0x83
-#define ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS        0x84
-#define ACPI_VIDEO_NOTIFY_ZERO_BRIGHTNESS       0x85
-#define ACPI_VIDEO_NOTIFY_DISPLAY_OFF           0x86
diff --git a/Documentation/powerpc/00-INDEX b/Documentation/powerpc/00-INDEX
index dd9e92802ec0..05026ce1875e 100644
--- a/Documentation/powerpc/00-INDEX
+++ b/Documentation/powerpc/00-INDEX
@@ -14,6 +14,8 @@ hvcs.txt
        - IBM "Hypervisor Virtual Console Server" Installation Guide
 mpc52xx.txt
        - Linux 2.6.x on MPC52xx family
+pmu-ebb.txt
+        - Description of the API for using the PMU with Event Based Branches.
 qe_firmware.txt
        - describes the layout of firmware binaries for the Freescale QUICC
          Engine and the code that parses and uploads the microcode therein.
diff --git a/Documentation/powerpc/pmu-ebb.txt b/Documentation/powerpc/pmu-ebb.txt
new file mode 100644
index 000000000000..73cd163dbfb8
--- /dev/null
+++ b/Documentation/powerpc/pmu-ebb.txt
@@ -0,0 +1,137 @@
+PMU Event Based Branches
+========================
+Event Based Branches (EBBs) are a feature which allows the hardware to
+branch directly to a specified user space address when certain events occur.
+The full specification is available in Power ISA v2.07:
+  https://www.power.org/documentation/power-isa-version-2-07/
+One type of event for which EBBs can be configured is PMU exceptions. This
+document describes the API for configuring the Power PMU to generate EBBs,
+using the Linux perf_events API.
+Terminology
+-----------
+Throughout this document we will refer to an "EBB event" or "EBB events". This
+just refers to a struct perf_event which has set the "EBB" flag in its
+attr.config. All events which can be configured on the hardware PMU are
+possible "EBB events".
+Background
+----------
+When a PMU EBB occurs it is delivered to the currently running process. As such
+EBBs can only sensibly be used by programs for self-monitoring.
+It is a feature of the perf_events API that events can be created on other
+processes, subject to standard permission checks. This is also true of EBB
+events, however unless the target process enables EBBs (via mtspr(BESCR)) no
+EBBs will ever be delivered.
+This makes it possible for a process to enable EBBs for itself, but not
+actually configure any events. At a later time another process can come along
+and attach an EBB event to the process, which will then cause EBBs to be
+delivered to the first process. It's not clear if this is actually useful.
+When the PMU is configured for EBBs, all PMU interrupts are delivered to the
+user process. This means once an EBB event is scheduled on the PMU, no non-EBB
+events can be configured. This means that EBB events can not be run
+concurrently with regular 'perf' commands, or any other perf events.
+It is however safe to run 'perf' commands on a process which is using EBBs. The
+kernel will in general schedule the EBB event, and perf will be notified that
+its events could not run.
+The exclusion between EBB events and regular events is implemented using the
+existing "pinned" and "exclusive" attributes of perf_events. This means EBB
+events will be given priority over other events, unless they are also pinned.
+If an EBB event and a regular event are both pinned, then whichever is enabled
+first will be scheduled and the other will be put in error state. See the
+section below titled "Enabling an EBB event" for more information.
+Creating an EBB event
+---------------------
+To request that an event is counted using EBB, the event code should have bit
+63 set.
+EBB events must be created with a particular, and restrictive, set of
+attributes - this is so that they interoperate correctly with the rest of the
+perf_events subsystem.
+An EBB event must be created with the "pinned" and "exclusive" attributes set.
+Note that if you are creating a group of EBB events, only the leader can have
+these attributes set.
+An EBB event must NOT set any of the "inherit", "sample_period", "freq" or
+"enable_on_exec" attributes.
+An EBB event must be attached to a task. This is specified to perf_event_open()
+by passing a pid value, typically 0 indicating the current task.
+All events in a group must agree on whether they want EBB. That is all events
+must request EBB, or none may request EBB.
+EBB events must specify the PMC they are to be counted on. This ensures
+userspace is able to reliably determine which PMC the event is scheduled on.
+Enabling an EBB event
+---------------------
+Once an EBB event has been successfully opened, it must be enabled with the
+perf_events API. This can be achieved either via the ioctl() interface, or the
+prctl() interface.
+However, due to the design of the perf_events API, enabling an event does not
+guarantee that it has been scheduled on the PMU. To ensure that the EBB event
+has been scheduled on the PMU, you must perform a read() on the event. If the
+read() returns EOF, then the event has not been scheduled and EBBs are not
+enabled.
+This behaviour occurs because the EBB event is pinned and exclusive. When the
+EBB event is enabled it will force all other non-pinned events off the PMU. In
+this case the enable will be successful. However if there is already an event
+pinned on the PMU then the enable will not be successful.
+Reading an EBB event
+--------------------
+It is possible to read() from an EBB event. However the results are
+meaningless. Because interrupts are being delivered to the user process the
+kernel is not able to count the event, and so will return a junk value.
+Closing an EBB event
+--------------------
+When an EBB event is finished with, you can close it using close() as for any
+regular event. If this is the last EBB event the PMU will be deconfigured and
+no further PMU EBBs will be delivered.
+EBB Handler
+-----------
+The EBB handler is just regular userspace code, however it must be written in
+the style of an interrupt handler. When the handler is entered all registers
+are live (possibly) and so must be saved somehow before the handler can invoke
+other code.
+It's up to the program how to handle this. For C programs a relatively simple
+option is to create an interrupt frame on the stack and save registers there.
+Fork
+----
+EBB events are not inherited across fork. If the child process wishes to use
+EBBs it should open a new event for itself. Similarly the EBB state in
+BESCR/EBBHR/EBBRR is cleared across fork().
diff --git a/Documentation/powerpc/transactional_memory.txt b/Documentation/powerpc/transactional_memory.txt
index c907be41d60f..dc23e58ae264 100644
--- a/Documentation/powerpc/transactional_memory.txt
+++ b/Documentation/powerpc/transactional_memory.txt
@@ -147,6 +147,25 @@ Example signal handler:
      fix_the_problem(ucp->dar);
    }
+When in an active transaction that takes a signal, we need to be careful with
+the stack.  It's possible that the stack has moved back up after the tbegin.
+The obvious case here is when the tbegin is called inside a function that
+returns before a tend.  In this case, the stack is part of the checkpointed
+transactional memory state.  If we write over this non transactionally or in
+suspend, we are in trouble because if we get a tm abort, the program counter and
+stack pointer will be back at the tbegin but our in memory stack won't be valid
+anymore.
+To avoid this, when taking a signal in an active transaction, we need to use
+the stack pointer from the checkpointed state, rather than the speculated
+state.  This ensures that the signal context (written tm suspended) will be
+written below the stack required for the rollback.  The transaction is aborted
+becuase of the treclaim, so any memory written between the tbegin and the
+signal will be rolled back anyway.
+For signals taken in non-TM or suspended mode, we use the
+normal/non-checkpointed stack pointer.
 Failure cause codes used by kernel
 ==================================
@@ -155,14 +174,18 @@ These are defined in <asm/reg.h>, and distinguish different reasons why the
 kernel aborted a transaction:
 TM_CAUSE_RESCHED       Thread was rescheduled.
+ TM_CAUSE_TLBI          Software TLB invalide.
 TM_CAUSE_FAC_UNAV      FP/VEC/VSX unavailable trap.
 TM_CAUSE_SYSCALL       Currently unused; future syscalls that must abort
                        transactions for consistency will use this.
 TM_CAUSE_SIGNAL        Signal delivered.
 TM_CAUSE_MISC          Currently unused.
+ TM_CAUSE_ALIGNMENT     Alignment fault.
+ TM_CAUSE_EMULATE       Emulation that touched memory.
-These can be checked by the user program's abort handler as TEXASR[0:7].
+These can be checked by the user program's abort handler as TEXASR[0:7].  If
+bit 7 is set, it indicates that the error is consider persistent.  For example
+a TM_CAUSE_ALIGNMENT will be persistent while a TM_CAUSE_RESCHED will not.q
 GDB
 ===
diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt
index 3af5ae6c9c11..3e8cb73ac43c 100644
--- a/Documentation/printk-formats.txt
+++ b/Documentation/printk-formats.txt
@@ -121,6 +121,38 @@ IPv6 addresses:
        print a compressed IPv6 address as described by
        http://tools.ietf.org/html/rfc5952
+IPv4/IPv6 addresses (generic, with port, flowinfo, scope):
+        %pIS    1.2.3.4         or 0001:0002:0003:0004:0005:0006:0007:0008
+        %piS    001.002.003.004 or 00010002000300040005000600070008
+        %pISc   1.2.3.4         or 1:2:3:4:5:6:7:8
+        %pISpc  1.2.3.4:12345   or [1:2:3:4:5:6:7:8]:12345
+        %p[Ii]S[pfschnbl]
+        For printing an IP address without the need to distinguish whether it's
+        of type AF_INET or AF_INET6, a pointer to a valid 'struct sockaddr',
+        specified through 'IS' or 'iS', can be passed to this format specifier.
+        The additional 'p', 'f', and 's' specifiers are used to specify port
+        (IPv4, IPv6), flowinfo (IPv6) and scope (IPv6). Ports have a ':' prefix,
+        flowinfo a '/' and scope a '%', each followed by the actual value.
+        In case of an IPv6 address the compressed IPv6 address as described by
+        http://tools.ietf.org/html/rfc5952 is being used if the additional
+        specifier 'c' is given. The IPv6 address is surrounded by '[', ']' in
+        case of additional specifiers 'p', 'f' or 's' as suggested by
+        https://tools.ietf.org/html/draft-ietf-6man-text-addr-representation-07
+        In case of IPv4 addresses, the additional 'h', 'n', 'b', and 'l'
+        specifiers can be used as well and are ignored in case of an IPv6
+        address.
+        Further examples:
+        %pISfc          1.2.3.4         or [1:2:3:4:5:6:7:8]/123456789
+        %pISsc          1.2.3.4         or [1:2:3:4:5:6:7:8]%1234567890
+        %pISpfc         1.2.3.4:12345   or [1:2:3:4:5:6:7:8]:12345/123456789
 UUID/GUID addresses:
        %pUb    00010203-0405-0607-0809-0a0b0c0d0e0f
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 7d2b4c9b544b..1039b68fe9c6 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -45,6 +45,43 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
 To start/stop toggling the PWM output use pwm_enable()/pwm_disable().
+Using PWMs with the sysfs interface
+-----------------------------------
+If CONFIG_SYSFS is enabled in your kernel configuration a simple sysfs
+interface is provided to use the PWMs from userspace. It is exposed at
+/sys/class/pwm/. Each probed PWM controller/chip will be exported as
+pwmchipN, where N is the base of the PWM chip. Inside the directory you
+will find:
+npwm - The number of PWM channels this chip supports (read-only).
+export - Exports a PWM channel for use with sysfs (write-only).
+unexport - Unexports a PWM channel from sysfs (write-only).
+The PWM channels are numbered using a per-chip index from 0 to npwm-1.
+When a PWM channel is exported a pwmX directory will be created in the
+pwmchipN directory it is associated with, where X is the number of the
+channel that was exported. The following properties will then be available:
+period - The total period of the PWM signal (read/write).
+        Value is in nanoseconds and is the sum of the active and inactive
+        time of the PWM.
+duty_cycle - The active time of the PWM signal (read/write).
+        Value is in nanoseconds and must be less than the period.
+polarity - Changes the polarity of the PWM signal (read/write).
+        Writes to this property only work if the PWM chip supports changing
+        the polarity. The polarity can only be changed if the PWM is not
+        enabled. Value is the string "normal" or "inversed".
+enable - Enable/disable the PWM signal (read/write).
+        0 - disabled
+        1 - enabled
 Implementing a PWM driver
 -------------------------
diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt
index c75694b35d08..717f5aa388b1 100644
--- a/Documentation/rapidio/rapidio.txt
+++ b/Documentation/rapidio/rapidio.txt
@@ -73,39 +73,175 @@ data structure. This structure includes lists of all devices and local master
 ports that form the same network. It also contains a pointer to the default
 master port that is used to communicate with devices within the network.
+2.5 Device Drivers
+RapidIO device-specific drivers follow Linux Kernel Driver Model and are
+intended to support specific RapidIO devices attached to the RapidIO network.
+2.6 Subsystem Interfaces
+RapidIO interconnect specification defines features that may be used to provide
+one or more common service layers for all participating RapidIO devices. These
+common services may act separately from device-specific drivers or be used by
+device-specific drivers. Example of such service provider is the RIONET driver
+which implements Ethernet-over-RapidIO interface. Because only one driver can be
+registered for a device, all common RapidIO services have to be registered as
+subsystem interfaces. This allows to have multiple common services attached to
+the same device without blocking attachment of a device-specific driver.
 3. Subsystem Initialization
 ---------------------------
 In order to initialize the RapidIO subsystem, a platform must initialize and
 register at least one master port within the RapidIO network. To register mport
-within the subsystem controller driver initialization code calls function
+within the subsystem controller driver's initialization code calls function
-rio_register_mport() for each available master port. After all active master
+rio_register_mport() for each available master port.
-ports are registered with a RapidIO subsystem, the rio_init_mports() routine
-is called to perform enumeration and discovery.
+After all active master ports are registered with a RapidIO subsystem,
+an enumeration and/or discovery routine may be called automatically or
+by user-space command.
-In the current PowerPC-based implementation a subsys_initcall() is specified to
+RapidIO subsystem can be configured to be built as a statically linked or
-perform controller initialization and mport registration. At the end it directly
+modular component of the kernel (see details below).
-calls rio_init_mports() to execute RapidIO enumeration and discovery.
 4. Enumeration and Discovery
 ----------------------------
-When rio_init_mports() is called it scans a list of registered master ports and
+4.1 Overview
-calls an enumeration or discovery routine depending on the configured role of a
+------------
-master port: host or agent.
+RapidIO subsystem configuration options allow users to build enumeration and
+discovery methods as statically linked components or loadable modules.
+An enumeration/discovery method implementation and available input parameters
+define how any given method can be attached to available RapidIO mports:
+simply to all available mports OR individually to the specified mport device.
+Depending on selected enumeration/discovery build configuration, there are
+several methods to initiate an enumeration and/or discovery process:
+  (a) Statically linked enumeration and discovery process can be started
+  automatically during kernel initialization time using corresponding module
+  parameters. This was the original method used since introduction of RapidIO
+  subsystem. Now this method relies on enumerator module parameter which is
+  'rio-scan.scan' for existing basic enumeration/discovery method.
+  When automatic start of enumeration/discovery is used a user has to ensure
+  that all discovering endpoints are started before the enumerating endpoint
+  and are waiting for enumeration to be completed.
+  Configuration option CONFIG_RAPIDIO_DISC_TIMEOUT defines time that discovering
+  endpoint waits for enumeration to be completed. If the specified timeout
+  expires the discovery process is terminated without obtaining RapidIO network
+  information. NOTE: a timed out discovery process may be restarted later using
+  a user-space command as it is described below (if the given endpoint was
+  enumerated successfully).
+  (b) Statically linked enumeration and discovery process can be started by
+  a command from user space. This initiation method provides more flexibility
+  for a system startup compared to the option (a) above. After all participating
+  endpoints have been successfully booted, an enumeration process shall be
+  started first by issuing a user-space command, after an enumeration is
+  completed a discovery process can be started on all remaining endpoints.
+  (c) Modular enumeration and discovery process can be started by a command from
+  user space. After an enumeration/discovery module is loaded, a network scan
+  process can be started by issuing a user-space command.
+  Similar to the option (b) above, an enumerator has to be started first.
+  (d) Modular enumeration and discovery process can be started by a module
+  initialization routine. In this case an enumerating module shall be loaded
+  first.
+When a network scan process is started it calls an enumeration or discovery
+routine depending on the configured role of a master port: host or agent.
 Enumeration is performed by a master port if it is configured as a host port by
-assigning a host device ID greater than or equal to zero. A host device ID is
+assigning a host destination ID greater than or equal to zero. The host
-assigned to a master port through the kernel command line parameter "riohdid=",
+destination ID can be assigned to a master port using various methods depending
-or can be configured in a platform-specific manner. If the host device ID for
+on RapidIO subsystem build configuration:
-a specific master port is set to -1, the discovery process will be performed
-for it.
+  (a) For a statically linked RapidIO subsystem core use command line parameter
+  "rapidio.hdid=" with a list of destination ID assignments in order of mport
+  device registration. For example, in a system with two RapidIO controllers
+  the command line parameter "rapidio.hdid=-1,7" will result in assignment of
+  the host destination ID=7 to the second RapidIO controller, while the first
+  one will be assigned destination ID=-1.
+  (b) If the RapidIO subsystem core is built as a loadable module, in addition
+  to the method shown above, the host destination ID(s) can be specified using
+  traditional methods of passing module parameter "hdid=" during its loading:
+  - from command line: "modprobe rapidio hdid=-1,7", or
+  - from modprobe configuration file using configuration command "options",
+    like in this example: "options rapidio hdid=-1,7". An example of modprobe
+    configuration file is provided in the section below.
+  NOTES:
+  (i) if "hdid=" parameter is omitted all available mport will be assigned
+  destination ID = -1;
+  (ii) the "hdid=" parameter in systems with multiple mports can have
+  destination ID assignments omitted from the end of list (default = -1).
+If the host device ID for a specific master port is set to -1, the discovery
+process will be performed for it.
 The enumeration and discovery routines use RapidIO maintenance transactions
 to access the configuration space of devices.
-The enumeration process is implemented according to the enumeration algorithm
+NOTE: If RapidIO switch-specific device drivers are built as loadable modules
-outlined in the RapidIO Interconnect Specification: Annex I [1].
+they must be loaded before enumeration/discovery process starts.
+This requirement is cased by the fact that enumeration/discovery methods invoke
+vendor-specific callbacks on early stages.
+4.2 Automatic Start of Enumeration and Discovery
+------------------------------------------------
+Automatic enumeration/discovery start method is applicable only to built-in
+enumeration/discovery RapidIO configuration selection. To enable automatic
+enumeration/discovery start by existing basic enumerator method set use boot
+command line parameter "rio-scan.scan=1".
+This configuration requires synchronized start of all RapidIO endpoints that
+form a network which will be enumerated/discovered. Discovering endpoints have
+to be started before an enumeration starts to ensure that all RapidIO
+controllers have been initialized and are ready to be discovered. Configuration
+parameter CONFIG_RAPIDIO_DISC_TIMEOUT defines time (in seconds) which
+a discovering endpoint will wait for enumeration to be completed.
+When automatic enumeration/discovery start is selected, basic method's
+initialization routine calls rio_init_mports() to perform enumeration or
+discovery for all known mport devices.
+Depending on RapidIO network size and configuration this automatic
+enumeration/discovery start method may be difficult to use due to the
+requirement for synchronized start of all endpoints.
+4.3 User-space Start of Enumeration and Discovery
+-------------------------------------------------
+User-space start of enumeration and discovery can be used with built-in and
+modular build configurations. For user-space controlled start RapidIO subsystem
+creates the sysfs write-only attribute file '/sys/bus/rapidio/scan'. To initiate
+an enumeration or discovery process on specific mport device, a user needs to
+write mport_ID (not RapidIO destination ID) into that file. The mport_ID is a
+sequential number (0 ... RIO_MAX_MPORTS) assigned during mport device
+registration. For example for machine with single RapidIO controller, mport_ID
+for that controller always will be 0.
+To initiate RapidIO enumeration/discovery on all available mports a user may
+write '-1' (or RIO_MPORT_ANY) into the scan attribute file.
+4.4 Basic Enumeration Method
+----------------------------
+This is an original enumeration/discovery method which is available since
+first release of RapidIO subsystem code. The enumeration process is
+implemented according to the enumeration algorithm outlined in the RapidIO
+Interconnect Specification: Annex I [1].
+This method can be configured as statically linked or loadable module.
+The method's single parameter "scan" allows to trigger the enumeration/discovery
+process from module initialization routine.
+This enumeration/discovery method can be started only once and does not support
+unloading if it is built as a module.
 The enumeration process traverses the network using a recursive depth-first
 algorithm. When a new device is found, the enumerator takes ownership of that
@@ -160,7 +296,49 @@ time period. If this wait time period expires before enumeration is completed,
 an agent skips RapidIO discovery and continues with remaining kernel
 initialization.
-5. References
+4.5 Adding New Enumeration/Discovery Method
+-------------------------------------------
+RapidIO subsystem code organization allows addition of new enumeration/discovery
+methods as new configuration options without significant impact to to the core
+RapidIO code.
+A new enumeration/discovery method has to be attached to one or more mport
+devices before an enumeration/discovery process can be started. Normally,
+method's module initialization routine calls rio_register_scan() to attach
+an enumerator to a specified mport device (or devices). The basic enumerator
+implementation demonstrates this process.
+4.6 Using Loadable RapidIO Switch Drivers
+-----------------------------------------
+In the case when RapidIO switch drivers are built as loadable modules a user
+must ensure that they are loaded before the enumeration/discovery starts.
+This process can be automated by specifying pre- or post- dependencies in the
+RapidIO-specific modprobe configuration file as shown in the example below.
+  File /etc/modprobe.d/rapidio.conf:
+  ----------------------------------
+  # Configure RapidIO subsystem modules
+  # Set enumerator host destination ID (overrides kernel command line option)
+  options rapidio hdid=-1,2
+  # Load RapidIO switch drivers immediately after rapidio core module was loaded
+  softdep rapidio post: idt_gen2 idtcps tsi57x
+  # OR :
+  # Load RapidIO switch drivers just before rio-scan enumerator module is loaded
+  softdep rio-scan pre: idt_gen2 idtcps tsi57x
+  --------------------------
+NOTE: In the example above, one of "softdep" commands must be removed or
+commented out to keep required module loading sequence.
+A. References
 -------------
 [1] RapidIO Trade Association. RapidIO Interconnect Specifications.
diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt
index 97f71ce575d6..271438c0617f 100644
--- a/Documentation/rapidio/sysfs.txt
+++ b/Documentation/rapidio/sysfs.txt
@@ -40,6 +40,7 @@ device_rev - returns the device revision level
             (see 4.1 for switch specific details)
   lprev   - returns name of previous device (switch) on the path to the device
             that that owns this attribute
+  modalias - returns the device modalias
 In addition to the files listed above, each device has a binary attribute file
 that allows read/write access to the device configuration registers using
@@ -88,3 +89,20 @@ that exports additional attributes.
 IDT_GEN2:
 errlog - reads contents of device error log until it is empty.
+5. RapidIO Bus Attributes
+-------------------------
+RapidIO bus subdirectory /sys/bus/rapidio implements the following bus-specific
+attribute:
+  scan - allows to trigger enumeration discovery process from user space. This
+         is a write-only attribute. To initiate an enumeration or discovery
+         process on specific mport device, a user needs to write mport_ID (not
+         RapidIO destination ID) into this file. The mport_ID is a sequential
+         number (0 ... RIO_MAX_MPORTS) assigned to the mport device.
+         For example, for a machine with a single RapidIO controller, mport_ID
+         for that controller always will be 0.
+         To initiate RapidIO enumeration/discovery on all available mports
+         a user must write '-1' (or RIO_MPORT_ANY) into this attribute file.
diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt
index 33ed8007a845..a5bcd7f5c33f 100644
--- a/Documentation/rt-mutex-design.txt
+++ b/Documentation/rt-mutex-design.txt
@@ -384,7 +384,7 @@ priority back.
 __rt_mutex_adjust_prio examines the result of rt_mutex_getprio, and if the
 result does not equal the task's current priority, then rt_mutex_setprio
 is called to adjust the priority of the task to the new priority.
-Note that rt_mutex_setprio is defined in kernel/sched.c to implement the
+Note that rt_mutex_setprio is defined in kernel/sched/core.c to implement the
 actual change in priority.
 It is interesting to note that __rt_mutex_adjust_prio can either increase
diff --git a/Documentation/rtc.txt b/Documentation/rtc.txt
index 32aa4002de4a..596b60c08b74 100644
--- a/Documentation/rtc.txt
+++ b/Documentation/rtc.txt
@@ -153,9 +153,10 @@ since_epoch:	 The number of seconds since the epoch according to the RTC
 time:            RTC-provided time
 wakealarm:       The time at which the clock will generate a system wakeup
                 event. This is a one shot wakeup event, so must be reset
-                 after wake if a daily wakeup is required. Format is either
+                 after wake if a daily wakeup is required. Format is seconds since
-                 seconds since the epoch or, if there's a leading +, seconds
+                 the epoch by default, or if there's a leading +, seconds in the
-                 in the future.
+                 future, or if there is a leading +=, seconds ahead of the current
+                 alarm.
 IOCTL INTERFACE
 ---------------
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt
index 443f0c76bab4..4af80b1c05aa 100644
--- a/Documentation/scheduler/sched-domains.txt
+++ b/Documentation/scheduler/sched-domains.txt
@@ -25,7 +25,7 @@ is treated as one entity. The load of a group is defined as the sum of the
 load of each of its member CPUs, and only when the load of a group becomes
 out of balance are tasks moved between groups.
-In kernel/sched.c, trigger_load_balance() is run periodically on each CPU
+In kernel/sched/core.c, trigger_load_balance() is run periodically on each CPU
 through scheduler_tick(). It raises a softirq after the next regularly scheduled
 rebalancing event for the current runqueue has arrived. The actual load
 balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
@@ -62,7 +62,7 @@ struct sched_domain fields, SD_FLAG_*, SD_*_INIT to get an idea of
 the specifics and what to tune.
 Architectures may retain the regular override the default SD_*_INIT flags
-while using the generic domain builder in kernel/sched.c if they wish to
+while using the generic domain builder in kernel/sched/core.c if they wish to
 retain the traditional SMT->SMP->NUMA topology (or some subset of that). This
 can be done by #define'ing ARCH_HASH_SCHED_TUNE.
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas
index 09673c7fc8ee..cc92ca8c8963 100644
--- a/Documentation/scsi/ChangeLog.megaraid_sas
+++ b/Documentation/scsi/ChangeLog.megaraid_sas
@@ -1,3 +1,25 @@
+Release Date    : Wed. May 15, 2013 17:00:00 PST 2013 -
+                        (emaild-id:megaraidlinux@lsi.com)
+                        Adam Radford
+                        Kashyap Desai
+                        Sumit Saxena
+Current Version : 06.600.18.00-rc1
+Old Version     : 06.506.00.00-rc1
+    1. Return DID_ERROR for scsi io, when controller is in critical h/w error.
+    2. Fix the interrupt mask for Gen2 controller.
+    3. Update balance count in driver to be in sync of firmware.
+    4. Free event detail memory without device ID check.
+    5. Set IO request timeout value provided by OS timeout for Tape devices.
+    6. Add support for MegaRAID Fury (device ID-0x005f) 12Gb/s controllers.
+    7. Add support to display Customer branding details in syslog.
+    8. Set IoFlags to enable Fast Path for JBODs for Invader/Fury(12 Gb/s)
+    controllers.
+    9. Add support for Extended MSI-x vectors for Invader and Fury(12Gb/s
+    HBA).
+    10.Add support for Uneven Span PRL11.
+    11.Add support to differentiate between iMR and MR Firmware.
+    12.Version and Changelog update.
+-------------------------------------------------------------------------------
 Release Date    : Sat. Feb 9, 2013 17:00:00 PST 2013 -
                        (emaild-id:megaraidlinux@lsi.com)
                        Adam Radford
diff --git a/Documentation/serial/00-INDEX b/Documentation/serial/00-INDEX
index f7b0c7dc25ef..1f1b22fbd739 100644
--- a/Documentation/serial/00-INDEX
+++ b/Documentation/serial/00-INDEX
@@ -16,8 +16,6 @@ serial-rs485.txt
        - info about RS485 structures and support in the kernel.
 specialix.txt
        - info on hardware/driver for specialix IO8+ multiport serial card.
-stallion.txt
-        - info on using the Stallion multiport serial driver.
 sx.txt
        - info on the Specialix SX/SI multiport serial driver.
 tty.txt
diff --git a/Documentation/serial/stallion.txt b/Documentation/serial/stallion.txt
deleted file mode 100644
index 4d798c0cb5cb..000000000000
--- a/Documentation/serial/stallion.txt
+++ /dev/null
@@ -1,392 +0,0 @@
-* NOTE - This is an unmaintained driver.  Lantronix, which bought Stallion
-technologies, is not active in driver maintenance, and they have no information
-on when or if they will have a 2.6 driver.
-James Nelson <james4765@gmail.com> - 12-12-2004
-Stallion Multiport Serial Driver Readme
---------------------------------------
-Copyright (C) 1994-1999,  Stallion Technologies.
-Version:   5.5.1
-Date:      28MAR99
-1. INTRODUCTION
-There are two drivers that work with the different families of Stallion
-multiport serial boards. One is for the Stallion smart boards - that is
-EasyIO, EasyConnection 8/32 and EasyConnection 8/64-PCI, the other for
-the true Stallion intelligent multiport boards - EasyConnection 8/64
-(ISA, EISA), EasyConnection/RA-PCI, ONboard and Brumby.
-If you are using any of the Stallion intelligent multiport boards (Brumby,
-ONboard, EasyConnection 8/64 (ISA, EISA), EasyConnection/RA-PCI) with
-Linux you will need to get the driver utility package.  This contains a
-firmware loader and the firmware images necessary to make the devices operate.
-The Stallion Technologies ftp site, ftp.stallion.com, will always have
-the latest version of the driver utility package.
-ftp://ftp.stallion.com/drivers/ata5/Linux/ata-linux-550.tar.gz
-As of the printing of this document the latest version of the driver
-utility package is 5.5.0. If a later version is now available then you
-should use the latest version.
-If you are using the EasyIO, EasyConnection 8/32 or EasyConnection 8/64-PCI
-boards then you don't need this package, although it does have a serial stats
-display program.
-If you require DIP switch settings, or EISA configuration files, or any
-other information related to Stallion boards then have a look at Stallion's
-web pages at http://www.stallion.com.
-2. INSTALLATION
-The drivers can be used as loadable modules or compiled into the kernel.
-You can choose which when doing a "config" on the kernel.
-All ISA, and EISA boards that you want to use need to be configured into
-the driver(s). All PCI boards will be automatically detected when you load
-the driver - so they do not need to be entered into the driver(s)
-configuration structure. Note that kernel PCI support is required to use PCI
-boards.
-There are two methods of configuring ISA and EISA boards into the drivers.
-If using the driver as a loadable module then the simplest method is to pass
-the driver configuration as module arguments. The other method is to modify
-the driver source to add configuration lines for each board in use.
-If you have pre-built Stallion driver modules then the module argument
-configuration method should be used. A lot of Linux distributions come with
-pre-built driver modules in /lib/modules/X.Y.Z/misc for the kernel in use.
-That makes things pretty simple to get going.
-2.1 MODULE DRIVER CONFIGURATION:
-The simplest configuration for modules is to use the module load arguments
-to configure any ISA or EISA boards. PCI boards are automatically
-detected, so do not need any additional configuration at all.
-If using EasyIO, EasyConnection 8/32 ISA, or EasyConnection 8/63-PCI
-boards then use the "stallion" driver module, Otherwise if you are using
-an EasyConnection 8/64 ISA or EISA, EasyConnection/RA-PCI, ONboard,
-Brumby or original Stallion board then use the "istallion" driver module.
-Typically to load up the smart board driver use:
-    modprobe stallion
-This will load the EasyIO and EasyConnection 8/32 driver. It will output a
-message to say that it loaded and print the driver version number. It will
-also print out whether it found the configured boards or not. These messages
-may not appear on the console, but typically are always logged to
-/var/adm/messages or /var/log/syslog files - depending on how the klogd and
-syslogd daemons are setup on your system.
-To load the intelligent board driver use:
-    modprobe istallion
-It will output similar messages to the smart board driver.
-If not using an auto-detectable board type (that is a PCI board) then you
-will also need to supply command line arguments to the modprobe command
-when loading the driver. The general form of the configuration argument is
-    board?=<name>[,<ioaddr>[,<addr>][,<irq>]]
-where:
-    board?  -- specifies the arbitrary board number of this board,
-               can be in the range 0 to 3.
-    name    -- textual name of this board. The board name is the common
-               board name, or any "shortened" version of that. The board
-               type number may also be used here.
-    ioaddr  -- specifies the I/O address of this board. This argument is
-               optional, but should generally be specified.
-    addr    -- optional second address argument. Some board types require
-               a second I/O address, some require a memory address. The
-               exact meaning of this argument depends on the board type.
-    irq     -- optional IRQ line used by this board.
-Up to 4 board configuration arguments can be specified on the load line.
-Here is some examples:
-    modprobe stallion board0=easyio,0x2a0,5
-This configures an EasyIO board as board 0 at I/O address 0x2a0 and IRQ 5.
-    modprobe istallion board3=ec8/64,0x2c0,0xcc000
-This configures an EasyConnection 8/64 ISA as board 3 at I/O address 0x2c0 at
-memory address 0xcc000.
-    modprobe stallion board1=ec8/32-at,0x2a0,0x280,10
-This configures an EasyConnection 8/32 ISA board at primary I/O address 0x2a0,
-secondary address 0x280 and IRQ 10.
-You will probably want to enter this module load and configuration information
-into your system startup scripts so that the drivers are loaded and configured
-on each system boot. Typically configuration files are put in the
-/etc/modprobe.d/ directory.
-2.2 STATIC DRIVER CONFIGURATION:
-For static driver configuration you need to modify the driver source code.
-Entering ISA and EISA boards into the driver(s) configuration structure
-involves editing the driver(s) source file. It's pretty easy if you follow
-the instructions below. Both drivers can support up to 4 boards. The smart
-card driver (the stallion.c driver) supports any combination of EasyIO and
-EasyConnection 8/32 boards (up to a total of 4). The intelligent driver
-supports any combination of ONboards, Brumbys, Stallions and EasyConnection
-8/64 (ISA and EISA) boards (up to a total of 4).
-To set up the driver(s) for the boards that you want to use you need to
-edit the appropriate driver file and add configuration entries.
-If using EasyIO or EasyConnection 8/32 ISA boards,
-   In drivers/char/stallion.c:
-      - find the definition of the stl_brdconf array (of structures)
-        near the top of the file
-      - modify this to match the boards you are going to install
-        (the comments before this structure should help)
-      - save and exit
-If using ONboard, Brumby, Stallion or EasyConnection 8/64 (ISA or EISA)
-boards,
-   In drivers/char/istallion.c:
-      - find the definition of the stli_brdconf array (of structures)
-        near the top of the file
-      - modify this to match the boards you are going to install
-        (the comments before this structure should help)
-      - save and exit
-Once you have set up the board configurations then you are ready to build
-the kernel or modules.
-When the new kernel is booted, or the loadable module loaded then the
-driver will emit some kernel trace messages about whether the configured
-boards were detected or not. Depending on how your system logger is set
-up these may come out on the console, or just be logged to
-/var/adm/messages or /var/log/syslog. You should check the messages to
-confirm that all is well.
-2.3 SHARING INTERRUPTS
-It is possible to share interrupts between multiple EasyIO and
-EasyConnection 8/32 boards in an EISA system. To do this you must be using
-static driver configuration, modifying the driver source code to add driver
-configuration. Then a couple of extra things are required:
-1. When entering the board resources into the stallion.c file you need to
-   mark the boards as using level triggered interrupts. Do this by replacing
-   the "0" entry at field position 6 (the last field) in the board
-   configuration structure with a "1". (This is the structure that defines
-   the board type, I/O locations, etc. for each board). All boards that are
-   sharing an interrupt must be set this way, and each board should have the
-   same interrupt number specified here as well. Now build the module or
-   kernel as you would normally.
-2. When physically installing the boards into the system you must enter
-   the system EISA configuration utility. You will need to install the EISA
-   configuration files for *all* the EasyIO and EasyConnection 8/32 boards
-   that are sharing interrupts. The Stallion EasyIO and EasyConnection 8/32
-   EISA configuration files required are supplied by Stallion Technologies
-   on the EASY Utilities floppy diskette (usually supplied in the box with
-   the board when purchased. If not, you can pick it up from Stallion's FTP
-   site, ftp.stallion.com). You will need to edit the board resources to
-   choose level triggered interrupts, and make sure to set each board's
-   interrupt to the same IRQ number.
-You must complete both the above steps for this to work. When you reboot
-or load the driver your EasyIO and EasyConnection 8/32 boards will be
-sharing interrupts.
-2.4 USING HIGH SHARED MEMORY
-The EasyConnection 8/64-EI, ONboard and Stallion boards are capable of
-using shared memory addresses above the usual 640K - 1Mb range. The ONboard
-ISA and the Stallion boards can be programmed to use memory addresses up to
-16Mb (the ISA bus addressing limit), and the EasyConnection 8/64-EI and
-ONboard/E can be programmed for memory addresses up to 4Gb (the EISA bus
-addressing limit).
-The higher than 1Mb memory addresses are fully supported by this driver.
-Just enter the address as you normally would for a lower than 1Mb address
-(in the driver's board configuration structure).
-2.5 TROUBLE SHOOTING
-If a board is not found by the driver but is actually in the system then the
-most likely problem is that the I/O address is wrong. Change the module load
-argument for the loadable module form. Or change it in the driver stallion.c
-or istallion.c configuration structure and rebuild the kernel or modules, or
-change it on the board.
-On EasyIO and EasyConnection 8/32 boards the IRQ is software programmable, so
-if there is a conflict you may need to change the IRQ used for a board. There
-are no interrupts to worry about for ONboard, Brumby or EasyConnection 8/64
-(ISA and EISA) boards. The memory region on EasyConnection 8/64 and
-ONboard boards is software programmable, but not on the Brumby boards.
-3. USING THE DRIVERS
-3.1 INTELLIGENT DRIVER OPERATION
-The intelligent boards also need to have their "firmware" code downloaded
-to them. This is done via a user level application supplied in the driver
-utility package called "stlload". Compile this program wherever you dropped
-the package files, by typing "make". In its simplest form you can then type
-    ./stlload -i cdk.sys
-in this directory and that will download board 0 (assuming board 0 is an
-EasyConnection 8/64 or EasyConnection/RA board). To download to an
-ONboard, Brumby or Stallion do:
-    ./stlload -i 2681.sys
-Normally you would want all boards to be downloaded as part of the standard
-system startup. To achieve this, add one of the lines above into the
-/etc/rc.d/rc.S or /etc/rc.d/rc.serial file. To download each board just add
-the "-b <brd-number>" option to the line. You will need to download code for
-every board. You should probably move the stlload program into a system
-directory, such as /usr/sbin. Also, the default location of the cdk.sys image
-file in the stlload down-loader is /usr/lib/stallion. Create that directory
-and put the cdk.sys and 2681.sys files in it. (It's a convenient place to put
-them anyway). As an example your /etc/rc.d/rc.S file might have the
-following lines added to it (if you had 3 boards):
-    /usr/sbin/stlload -b 0 -i /usr/lib/stallion/cdk.sys
-    /usr/sbin/stlload -b 1 -i /usr/lib/stallion/2681.sys
-    /usr/sbin/stlload -b 2 -i /usr/lib/stallion/2681.sys
-The image files cdk.sys and 2681.sys are specific to the board types. The
-cdk.sys will only function correctly on an EasyConnection 8/64 board. Similarly
-the 2681.sys image fill only operate on ONboard, Brumby and Stallion boards.
-If you load the wrong image file into a board it will fail to start up, and
-of course the ports will not be operational!
-If you are using the modularized version of the driver you might want to put
-the modprobe calls in the startup script as well (before the download lines
-obviously).
-3.2 USING THE SERIAL PORTS
-Once the driver is installed you will need to setup some device nodes to
-access the serial ports. The simplest method is to use the /dev/MAKEDEV program.
-It will automatically create device entries for Stallion boards. This will
-create the normal serial port devices as /dev/ttyE# where# is the port number
-starting from 0. A bank of 64 minor device numbers is allocated to each board,
-so the first port on the second board is port 64,etc. A set of callout type
-devices may also be created. They are created as the devices /dev/cue# where #
-is the same as for the ttyE devices.
-For the most part the Stallion driver tries to emulate the standard PC system
-COM ports and the standard Linux serial driver. The idea is that you should
-be able to use Stallion board ports and COM ports interchangeably without
-modifying anything but the device name. Anything that doesn't work like that
-should be considered a bug in this driver!
-If you look at the driver code you will notice that it is fairly closely
-based on the Linux serial driver (linux/drivers/char/serial.c). This is
-intentional, obviously this is the easiest way to emulate its behavior!
-Since this driver tries to emulate the standard serial ports as much as
-possible, most system utilities should work as they do for the standard
-COM ports. Most importantly "stty" works as expected and "setserial" can
-also be used (excepting the ability to auto-configure the I/O and IRQ
-addresses of boards). Higher baud rates are supported in the usual fashion
-through setserial or using the CBAUDEX extensions. Note that the EasyIO and
-EasyConnection (all types) support at least 57600 and 115200 baud. The newer
-EasyConnection XP modules and new EasyIO boards support 230400 and 460800
-baud as well. The older boards including ONboard and Brumby support a
-maximum baud rate of 38400.
-If you are unfamiliar with how to use serial ports, then get the Serial-HOWTO
-by Greg Hankins. It will explain everything you need to know!
-4. NOTES
-You can use both drivers at once if you have a mix of board types installed
-in a system. However to do this you will need to change the major numbers
-used by one of the drivers. Currently both drivers use major numbers 24, 25
-and 28 for their devices. Change one driver to use some other major numbers,
-and then modify the mkdevnods script to make device nodes based on those new
-major numbers. For example, you could change the istallion.c driver to use
-major numbers 60, 61 and 62. You will also need to create device nodes with
-different names for the ports, for example ttyF# and cuf#.
-The original Stallion board is no longer supported by Stallion Technologies.
-Although it is known to work with the istallion driver.
-Finding a free physical memory address range can be a problem. The older
-boards like the Stallion and ONboard need large areas (64K or even 128K), so
-they can be very difficult to get into a system. If you have 16 Mb of RAM
-then you have no choice but to put them somewhere in the 640K -> 1Mb range.
-ONboards require 64K, so typically 0xd0000 is good, or 0xe0000 on some
-systems. If you have an original Stallion board, "V4.0" or Rev.O, then you
-need a 64K memory address space, so again 0xd0000 and 0xe0000 are good.
-Older Stallion boards are a much bigger problem. They need 128K of address
-space and must be on a 128K boundary. If you don't have a VGA card then
-0xc0000 might be usable - there is really no other place you can put them
-below 1Mb.
-Both the ONboard and old Stallion boards can use higher memory addresses as
-well, but you must have less than 16Mb of RAM to be able to use them. Usual
-high memory addresses used include 0xec0000 and 0xf00000.
-The Brumby boards only require 16Kb of address space, so you can usually
-squeeze them in somewhere. Common addresses are 0xc8000, 0xcc000, or in
-the 0xd0000 range. EasyConnection 8/64 boards are even better, they only
-require 4Kb of address space, again usually 0xc8000, 0xcc000 or 0xd0000
-are good.
-If you are using an EasyConnection 8/64-EI or ONboard/E then usually the
-0xd0000 or 0xe0000 ranges are the best options below 1Mb. If neither of
-them can be used then the high memory support to use the really high address
-ranges is the best option. Typically the 2Gb range is convenient for them,
-and gets them well out of the way.
-The ports of the EasyIO-8M board do not have DCD or DTR signals. So these
-ports cannot be used as real modem devices. Generally, when using these
-ports you should only use the cueX devices.
-The driver utility package contains a couple of very useful programs. One 
-is a serial port statistics collection and display program - very handy
-for solving serial port problems. The other is an extended option setting
-program that works with the intelligent boards.
-5. DISCLAIMER
-The information contained in this document is believed to be accurate and
-reliable. However, no responsibility is assumed by Stallion Technologies
-Pty. Ltd. for its use, nor any infringements of patents or other rights
-of third parties resulting from its use. Stallion Technologies reserves
-the right to modify the design of its products and will endeavour to change
-the information in manuals and accompanying documentation accordingly.
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index bb8b0dc532b8..809d72b8eff1 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -21,38 +21,41 @@ ALC267/268
 ==========
  inv-dmic      Inverted internal mic workaround
-ALC269/270/275/276/280/282
+ALC269/270/275/276/28x/29x
 ======
-  laptop-amic   Laptops with analog-mic input
+  laptop-amic           Laptops with analog-mic input
-  laptop-dmic   Laptops with digital-mic input
+  laptop-dmic           Laptops with digital-mic input
-  alc269-dmic   Enable ALC269(VA) digital mic workaround
+  alc269-dmic           Enable ALC269(VA) digital mic workaround
-  alc271-dmic   Enable ALC271X digital mic workaround
+  alc271-dmic           Enable ALC271X digital mic workaround
-  inv-dmic      Inverted internal mic workaround
+  inv-dmic              Inverted internal mic workaround
-  lenovo-dock   Enables docking station I/O for some Lenovos
+  lenovo-dock           Enables docking station I/O for some Lenovos
+  dell-headset-multi    Headset jack, which can also be used as mic-in
-ALC662/663/272
+  dell-headset-dock     Headset jack (without mic-in), and also dock I/O
+ALC66x/67x/892
 ==============
-  mario         Chromebook mario model fixup
+  mario                 Chromebook mario model fixup
-  asus-mode1    ASUS
+  asus-mode1            ASUS
-  asus-mode2    ASUS
+  asus-mode2            ASUS
-  asus-mode3    ASUS
+  asus-mode3            ASUS
-  asus-mode4    ASUS
+  asus-mode4            ASUS
-  asus-mode5    ASUS
+  asus-mode5            ASUS
-  asus-mode6    ASUS
+  asus-mode6            ASUS
-  asus-mode7    ASUS
+  asus-mode7            ASUS
-  asus-mode8    ASUS
+  asus-mode8            ASUS
-  inv-dmic      Inverted internal mic workaround
+  inv-dmic              Inverted internal mic workaround
+  dell-headset-multi    Headset jack, which can also be used as mic-in
 ALC680
 ======
  N/A
-ALC882/883/885/888/889
+ALC88x/898/1150
 ======================
  acer-aspire-4930g     Acer Aspire 4930G/5930G/6530G/6930G/7730G
  acer-aspire-8930g     Acer Aspire 8330G/6935G
  acer-aspire           Acer Aspire others
-  inv-dmic      Inverted internal mic workaround
+  inv-dmic              Inverted internal mic workaround
  no-primary-hp         VAIO Z/VGC-LN51JGB workaround (for fixed speaker DAC)
 ALC861/660
diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt
index 9dbe885ecd8d..97eaf5727178 100644
--- a/Documentation/spinlocks.txt
+++ b/Documentation/spinlocks.txt
@@ -137,7 +137,7 @@ don't block on each other (and thus there is no dead-lock wrt interrupts.
 But when you do the write-lock, you have to use the irq-safe version. 
 For an example of being clever with rw-locks, see the "waitqueue_lock" 
-handling in kernel/sched.c - nothing ever _changes_ a wait-queue from
+handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
 within an interrupt, they only read the queue in order to know whom to
 wake up. So read-locks are safe (which is good: they are very common
 indeed), while write-locks need to protect themselves against interrupts.
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index ccd42589e124..ab7d16efa96b 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -70,12 +70,12 @@ show up in /proc/sys/kernel:
 - shmall
 - shmmax                      [ sysv ipc ]
 - shmmni
- softlockup_thresh
 - stop-a                      [ SPARC only ]
 - sysrq                       ==> Documentation/sysrq.txt
 - tainted
 - threads-max
 - unknown_nmi_panic
+- watchdog_thresh
 - version
 ==============================================================
@@ -427,6 +427,32 @@ This file shows up if CONFIG_DEBUG_STACKOVERFLOW is enabled.
 ==============================================================
+perf_cpu_time_max_percent:
+Hints to the kernel how much CPU time it should be allowed to
+use to handle perf sampling events.  If the perf subsystem
+is informed that its samples are exceeding this limit, it
+will drop its sampling frequency to attempt to reduce its CPU
+usage.
+Some perf sampling happens in NMIs.  If these samples
+unexpectedly take too long to execute, the NMIs can become
+stacked up next to each other so much that nothing else is
+allowed to execute.
+0: disable the mechanism.  Do not monitor or correct perf's
+   sampling rate no matter how CPU time it takes.
+1-100: attempt to throttle perf's sample rate to this
+   percentage of CPU.  Note: the kernel calculates an
+   "expected" length of each sample event.  100 here means
+   100% of that expected length.  Even if this is set to
+   100, you may still see sample throttling if this
+   length is exceeded.  Set to 0 if you truly do not care
+   how much CPU is consumed.
+==============================================================
 pid_max:
@@ -604,15 +630,6 @@ without users and with a dead originative process will be destroyed.
 ==============================================================
-softlockup_thresh:
-This value can be used to lower the softlockup tolerance threshold.  The
-default threshold is 60 seconds.  If a cpu is locked up for 60 seconds,
-the kernel complains.  Valid values are 1-60 seconds.  Setting this
-tunable to zero will disable the softlockup detection altogether.
-==============================================================
 tainted:
 Non-zero if the kernel has been tainted.  Numeric values, which
@@ -648,3 +665,16 @@ that time, kernel debugging information is displayed on console.
 NMI switch that most IA32 servers have fires unknown NMI up, for
 example.  If a system hangs up, try pressing the NMI switch.
+==============================================================
+watchdog_thresh:
+This value can be used to control the frequency of hrtimer and NMI
+events and the soft and hard lockup thresholds. The default threshold
+is 10 seconds.
+The softlockup threshold is (2 * watchdog_thresh). Setting this
+tunable to zero will disable lockup detection altogether.
+==============================================================
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index 98335b7a5337..d69e14c9002c 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -1,4 +1,4 @@
-Documentation for /proc/sys/net/*       kernel version 2.4.0-test11-pre4
+Documentation for /proc/sys/net/*
        (c) 1999                Terrehon Bowden <terrehon@pacbell.net>
                                Bodo Bauer <bb@ricochet.net>
        (c) 2000                Jorge Nerin <comandante@zaralinux.com>
@@ -9,10 +9,10 @@ For general info and legal blurb, please look in README.
 ==============================================================
 This file contains the documentation for the sysctl files in
-/proc/sys/net and is valid for Linux kernel version 2.4.0-test11-pre4.
+/proc/sys/net
 The interface  to  the  networking  parts  of  the  kernel  is  located  in
-/proc/sys/net. The following table shows all possible subdirectories.You may
+/proc/sys/net. The following table shows all possible subdirectories.  You may
 see only some of them, depending on your kernel's configuration.
@@ -26,7 +26,7 @@ Table : Subdirectories in /proc/sys/net
 ipv4      IP version 4        x25        X.25 protocol
 ipx       IPX                 token-ring IBM token ring
 bridge    Bridging            decnet     DEC net
- ipv6      IP version 6
+ ipv6      IP version 6        tipc       TIPC
 ..............................................................................
 1. /proc/sys/net/core - Network core options
@@ -50,6 +50,29 @@ The maximum number of packets that kernel can handle on a NAPI interrupt,
 it's a Per-CPU variable.
 Default: 64
+low_latency_read
+----------------
+Low latency busy poll timeout for socket reads. (needs CONFIG_NET_LL_RX_POLL)
+Approximate time in us to busy loop waiting for packets on the device queue.
+This sets the default value of the SO_LL socket option.
+Can be set or overridden per socket by setting socket option SO_LL, which is
+the preferred method of enabling.
+If you need to enable the feature globally via sysctl, a value of 50 is recommended.
+Will increase power usage.
+Default: 0 (off)
+low_latency_poll
+----------------
+Low latency busy poll timeout for poll and select. (needs CONFIG_NET_LL_RX_POLL)
+Approximate time in us to busy loop waiting for events.
+Recommended value depends on the number of sockets you poll on.
+For several sockets 50, for several hundreds 100.
+For more than that you probably want to use epoll.
+Note that only sockets with SO_LL set will be busy polled, so you want to either
+selectively set SO_LL on those sockets or set sysctl.net.low_latency_read globally.
+Will increase power usage.
+Default: 0 (off)
 rmem_default
 ------------
@@ -93,8 +116,7 @@ netdev_budget
 Maximum number of packets taken from all interfaces in one polling cycle (NAPI
 poll). In one polling cycle interfaces which are registered to polling are
-probed in a round-robin manner. The limit of packets in one such probe can be
+probed in a round-robin manner.
-set per-device via sysfs class/net/<device>/weight .
 netdev_max_backlog
 ------------------
@@ -201,3 +223,18 @@ IPX.
 The /proc/net/ipx_route  table  holds  a list of IPX routes. For each route it
 gives the  destination  network, the router node (or Directly) and the network
 address of the router (or Connected) for internal networks.
+6. TIPC
+-------------------------------------------------------
+The TIPC protocol now has a tunable for the receive memory, similar to the
+tcp_rmem - i.e. a vector of 3 INTEGERs: (min, default, max)
+    # cat /proc/sys/net/tipc/tipc_rmem
+    4252725 34021800        68043600
+    #
+The max value is set to CONN_OVERLOAD_LIMIT, and the default and min values
+are scaled (shifted) versions of that same value.  Note that the min value
+is not at this point in time used in any meaningful way, but the triplet is
+preserved in order to be consistent with things like tcp_rmem.
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index dcc75a9ed919..36ecc26c7433 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -510,7 +510,7 @@ Specify "[Dd]efault" to request automatic configuration.  Autoconfiguration
 will select "node" order in following case.
 (1) if the DMA zone does not exist or
 (2) if the DMA zone comprises greater than 50% of the available memory or
-(3) if any node's DMA zone comprises greater than 60% of its local memory and
+(3) if any node's DMA zone comprises greater than 70% of its local memory and
    the amount of local memory is big enough.
 Otherwise, "zone" order will be selected. Default order is recommended unless
diff --git a/Documentation/thermal/exynos_thermal_emulation b/Documentation/thermal/exynos_thermal_emulation
index 36a3e79c1203..b15efec6ca28 100644
--- a/Documentation/thermal/exynos_thermal_emulation
+++ b/Documentation/thermal/exynos_thermal_emulation
@@ -20,7 +20,7 @@ When it's enabled, sysfs node will be created as
 The sysfs node, 'emul_node', will contain value 0 for the initial state. When you input any
 temperature you want to update to sysfs node, it automatically enable emulation mode and
 current temperature will be changed into it.
-(Exynos also supports user changable delay time which would be used to delay of
+(Exynos also supports user changeable delay time which would be used to delay of
 changing temperature. However, this node only uses same delay of real sensing time, 938us.)
 Exynos emulation mode requires synchronous of value changing and enabling. It means when you
diff --git a/Documentation/thermal/x86_pkg_temperature_thermal b/Documentation/thermal/x86_pkg_temperature_thermal
new file mode 100644
index 000000000000..17a3a4c0a0ca
--- /dev/null
+++ b/Documentation/thermal/x86_pkg_temperature_thermal
@@ -0,0 +1,47 @@
+Kernel driver: x86_pkg_temp_thermal
+===================
+Supported chips:
+* x86: with package level thermal management
+(Verify using: CPUID.06H:EAX[bit 6] =1)
+Authors: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
+Reference
+---
+Intel® 64 and IA-32 Architectures Software Developer’s Manual (Jan, 2013):
+Chapter 14.6: PACKAGE LEVEL THERMAL MANAGEMENT
+Description
+---------
+This driver register CPU digital temperature package level sensor as a thermal
+zone with maximum two user mode configurable trip points. Number of trip points
+depends on the capability of the package. Once the trip point is violated,
+user mode can receive notification via thermal notification mechanism and can
+take any action to control temperature.
+Threshold management
+--------------------
+Each package will register as a thermal zone under /sys/class/thermal.
+Example:
+/sys/class/thermal/thermal_zone1
+This contains two trip points:
+- trip_point_0_temp
+- trip_point_1_temp
+User can set any temperature between 0 to TJ-Max temperature. Temperature units
+are in milli-degree Celsius. Refer to "Documentation/thermal/sysfs-api.txt" for
+thermal sys-fs details.
+Any value other than 0 in these trip points, can trigger thermal notifications.
+Setting 0, stops sending thermal notifications.
+Thermal notifications: To get kobject-uevent notifications, set the thermal zone
+policy to "user_space". For example: echo -n "user_space" > policy
diff --git a/Documentation/timers/NO_HZ.txt b/Documentation/timers/NO_HZ.txt
index 5b5322024067..88697584242b 100644
--- a/Documentation/timers/NO_HZ.txt
+++ b/Documentation/timers/NO_HZ.txt
@@ -7,21 +7,59 @@ efficiency and reducing OS jitter.  Reducing OS jitter is important for
 some types of computationally intensive high-performance computing (HPC)
 applications and for real-time applications.
-There are two main contexts in which the number of scheduling-clock
+There are three main ways of managing scheduling-clock interrupts
-interrupts can be reduced compared to the old-school approach of sending
+(also known as "scheduling-clock ticks" or simply "ticks"):
-a scheduling-clock interrupt to all CPUs every jiffy whether they need
-it or not (CONFIG_HZ_PERIODIC=y or CONFIG_NO_HZ=n for older kernels):
-1.      Idle CPUs (CONFIG_NO_HZ_IDLE=y or CONFIG_NO_HZ=y for older kernels).
+1.      Never omit scheduling-clock ticks (CONFIG_HZ_PERIODIC=y or
+        CONFIG_NO_HZ=n for older kernels).  You normally will -not-
+        want to choose this option.
-2.      CPUs having only one runnable task (CONFIG_NO_HZ_FULL=y).
+2.      Omit scheduling-clock ticks on idle CPUs (CONFIG_NO_HZ_IDLE=y or
+        CONFIG_NO_HZ=y for older kernels).  This is the most common
+        approach, and should be the default.
-These two cases are described in the following two sections, followed
+3.      Omit scheduling-clock ticks on CPUs that are either idle or that
+        have only one runnable task (CONFIG_NO_HZ_FULL=y).  Unless you
+        are running realtime applications or certain types of HPC
+        workloads, you will normally -not- want this option.
+These three cases are described in the following three sections, followed
 by a third section on RCU-specific considerations and a fourth and final
 section listing known issues.
-IDLE CPUs
+NEVER OMIT SCHEDULING-CLOCK TICKS
+Very old versions of Linux from the 1990s and the very early 2000s
+are incapable of omitting scheduling-clock ticks.  It turns out that
+there are some situations where this old-school approach is still the
+right approach, for example, in heavy workloads with lots of tasks
+that use short bursts of CPU, where there are very frequent idle
+periods, but where these idle periods are also quite short (tens or
+hundreds of microseconds).  For these types of workloads, scheduling
+clock interrupts will normally be delivered any way because there
+will frequently be multiple runnable tasks per CPU.  In these cases,
+attempting to turn off the scheduling clock interrupt will have no effect
+other than increasing the overhead of switching to and from idle and
+transitioning between user and kernel execution.
+This mode of operation can be selected using CONFIG_HZ_PERIODIC=y (or
+CONFIG_NO_HZ=n for older kernels).
+However, if you are instead running a light workload with long idle
+periods, failing to omit scheduling-clock interrupts will result in
+excessive power consumption.  This is especially bad on battery-powered
+devices, where it results in extremely short battery lifetimes.  If you
+are running light workloads, you should therefore read the following
+section.
+In addition, if you are running either a real-time workload or an HPC
+workload with short iterations, the scheduling-clock interrupts can
+degrade your applications performance.  If this describes your workload,
+you should read the following two sections.
+OMIT SCHEDULING-CLOCK TICKS FOR IDLE CPUs
 If a CPU is idle, there is little point in sending it a scheduling-clock
 interrupt.  After all, the primary purpose of a scheduling-clock interrupt
@@ -59,10 +97,12 @@ By default, CONFIG_NO_HZ_IDLE=y kernels boot with "nohz=on", enabling
 dyntick-idle mode.
-CPUs WITH ONLY ONE RUNNABLE TASK
+OMIT SCHEDULING-CLOCK TICKS FOR CPUs WITH ONLY ONE RUNNABLE TASK
 If a CPU has only one runnable task, there is little point in sending it
 a scheduling-clock interrupt because there is no other task to switch to.
+Note that omitting scheduling-clock ticks for CPUs with only one runnable
+task implies also omitting them for idle CPUs.
 The CONFIG_NO_HZ_FULL=y Kconfig option causes the kernel to avoid
 sending scheduling-clock interrupts to CPUs with a single runnable task,
@@ -238,6 +278,11 @@ o	Adaptive-ticks does not do anything unless there is only one
        single runnable SCHED_FIFO task and multiple runnable SCHED_OTHER
        tasks, even though these interrupts are unnecessary.
+        And even when there are multiple runnable tasks on a given CPU,
+        there is little point in interrupting that CPU until the current
+        running task's timeslice expires, which is almost always way
+        longer than the time of the next scheduling-clock interrupt.
        Better handling of these sorts of situations is future work.
 o       A reboot is required to reconfigure both adaptive idle and RCU
@@ -268,6 +313,16 @@ o	Unless all CPUs are idle, at least one CPU must keep the
        scheduling-clock interrupt going in order to support accurate
        timekeeping.
-o       If there are adaptive-ticks CPUs, there will be at least one
+o       If there might potentially be some adaptive-ticks CPUs, there
-        CPU keeping the scheduling-clock interrupt going, even if all
+        will be at least one CPU keeping the scheduling-clock interrupt
-        CPUs are otherwise idle.
+        going, even if all CPUs are otherwise idle.
+        Better handling of this situation is ongoing work.
+o       Some process-handling operations still require the occasional
+        scheduling-clock tick.  These operations include calculating CPU
+        load, maintaining sched average, computing CFS entity vruntime,
+        computing avenrun, and carrying out load balancing.  They are
+        currently accommodated by scheduling-clock tick every second
+        or so.  On-going work will eliminate the need even for these
+        infrequent scheduling-clock ticks.
diff --git a/Documentation/trace/events-nmi.txt b/Documentation/trace/events-nmi.txt
new file mode 100644
index 000000000000..c03c8c89f08d
--- /dev/null
+++ b/Documentation/trace/events-nmi.txt
@@ -0,0 +1,43 @@
+NMI Trace Events
+These events normally show up here:
+        /sys/kernel/debug/tracing/events/nmi
+--
+nmi_handler:
+You might want to use this tracepoint if you suspect that your
+NMI handlers are hogging large amounts of CPU time.  The kernel
+will warn if it sees long-running handlers:
+        INFO: NMI handler took too long to run: 9.207 msecs
+and this tracepoint will allow you to drill down and get some
+more details.
+Let's say you suspect that perf_event_nmi_handler() is causing
+you some problems and you only want to trace that handler
+specifically.  You need to find its address:
+        $ grep perf_event_nmi_handler /proc/kallsyms
+        ffffffff81625600 t perf_event_nmi_handler
+Let's also say you are only interested in when that function is
+really hogging a lot of CPU time, like a millisecond at a time.
+Note that the kernel's output is in milliseconds, but the input
+to the filter is in nanoseconds!  You can filter on 'delta_ns':
+cd /sys/kernel/debug/tracing/events/nmi/nmi_handler
+echo 'handler==0xffffffff81625600 && delta_ns>1000000' > filter
+echo 1 > enable
+Your output would then look like:
+$ cat /sys/kernel/debug/tracing/trace_pipe
+<idle>-0     [000] d.h3   505.397558: nmi_handler: perf_event_nmi_handler() delta_ns: 3236765 handled: 1
+<idle>-0     [000] d.h3   505.805893: nmi_handler: perf_event_nmi_handler() delta_ns: 3174234 handled: 1
+<idle>-0     [000] d.h3   506.158206: nmi_handler: perf_event_nmi_handler() delta_ns: 3084642 handled: 1
+<idle>-0     [000] d.h3   506.334346: nmi_handler: perf_event_nmi_handler() delta_ns: 3080351 handled: 1
diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index e1498ff8cf94..3bd33b8dc7c4 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -63,3 +63,34 @@ power_domain_target	"%s state=%lu cpu_id=%lu"
 The first parameter gives the power domain name (e.g. "mpu_pwrdm").
 The second parameter is the power domain target state.
+4. PM QoS events
+================
+The PM QoS events are used for QoS add/update/remove request and for
+target/flags update.
+pm_qos_add_request                 "pm_qos_class=%s value=%d"
+pm_qos_update_request              "pm_qos_class=%s value=%d"
+pm_qos_remove_request              "pm_qos_class=%s value=%d"
+pm_qos_update_request_timeout      "pm_qos_class=%s value=%d, timeout_us=%ld"
+The first parameter gives the QoS class name (e.g. "CPU_DMA_LATENCY").
+The second parameter is value to be added/updated/removed.
+The third parameter is timeout value in usec.
+pm_qos_update_target               "action=%s prev_value=%d curr_value=%d"
+pm_qos_update_flags                "action=%s prev_value=0x%x curr_value=0x%x"
+The first parameter gives the QoS action name (e.g. "ADD_REQ").
+The second parameter is the previous QoS value.
+The third parameter is the current QoS value to update.
+And, there are also events used for device PM QoS add/update/remove request.
+dev_pm_qos_add_request             "device=%s type=%s new_value=%d"
+dev_pm_qos_update_request          "device=%s type=%s new_value=%d"
+dev_pm_qos_remove_request          "device=%s type=%s new_value=%d"
+The first parameter gives the device name which tries to add/update/remove
+QoS requests.
+The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY").
+The third parameter is value to be added/updated/removed.
diff --git a/Documentation/trace/events.txt b/Documentation/trace/events.txt
index bb24c2a0e870..37732a220d33 100644
--- a/Documentation/trace/events.txt
+++ b/Documentation/trace/events.txt
@@ -183,13 +183,22 @@ The relational-operators depend on the type of the field being tested:
 The operators available for numeric fields are:
-==, !=, <, <=, >, >=
+==, !=, <, <=, >, >=, &
 And for string fields they are:
-==, !=
+==, !=, ~
-Currently, only exact string matches are supported.
+The glob (~) only accepts a wild card character (*) at the start and or
+end of the string. For example:
+  prev_comm ~ "*sh"
+  prev_comm ~ "sh*"
+  prev_comm ~ "*sh*"
+But does not allow for it to be within the string:
+  prev_comm ~ "ba*sh"   <-- is invalid
 5.2 Setting filters
 -------------------
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index bfe8c29b1f1d..b937c6e2163c 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -2430,6 +2430,19 @@ The following commands are supported:
   echo '!schedule:disable_event:sched:sched_switch' > \
         set_ftrace_filter
+- dump
+  When the function is hit, it will dump the contents of the ftrace
+  ring buffer to the console. This is useful if you need to debug
+  something, and want to dump the trace when a certain function
+  is hit. Perhaps its a function that is called before a tripple
+  fault happens and does not allow you to get a regular dump.
+- cpudump
+  When the function is hit, it will dump the contents of the ftrace
+  ring buffer for the current CPU to the console. Unlike the "dump"
+  command, it only prints out the contents of the ring buffer for the
+  CPU that executed the function that triggered the dump.
 trace_pipe
 ----------
diff --git a/Documentation/usb/gadget_configfs.txt b/Documentation/usb/gadget_configfs.txt
new file mode 100644
index 000000000000..8ec2a67c39b7
--- /dev/null
+++ b/Documentation/usb/gadget_configfs.txt
@@ -0,0 +1,384 @@
+                Linux USB gadget configured through configfs
+                             25th April 2013
+Overview
+========
+A USB Linux Gadget is a device which has a UDC (USB Device Controller) and can
+be connected to a USB Host to extend it with additional functions like a serial
+port or a mass storage capability.
+A gadget is seen by its host as a set of configurations, each of which contains
+a number of interfaces which, from the gadget's perspective, are known as
+functions, each function representing e.g. a serial connection or a SCSI disk.
+Linux provides a number of functions for gadgets to use.
+Creating a gadget means deciding what configurations there will be
+and which functions each configuration will provide.
+Configfs (please see Documentation/filesystems/configfs/*) lends itslef nicely
+for the purpose of telling the kernel about the above mentioned decision.
+This document is about how to do it.
+It also describes how configfs integration into gadget is designed.
+Requirements
+============
+In order for this to work configfs must be available, so CONFIGFS_FS must be
+'y' or 'm' in .config. As of this writing USB_LIBCOMPOSITE selects CONFIGFS_FS.
+Usage
+=====
+(The original post describing the first function
+made available through configfs can be seen here:
+http://www.spinics.net/lists/linux-usb/msg76388.html)
+$ modprobe libcomposite
+$ mount none $CONFIGFS_HOME -t configfs
+where CONFIGFS_HOME is the mount point for configfs
+1. Creating the gadgets
+-----------------------
+For each gadget to be created its corresponding directory must be created:
+$ mkdir $CONFIGFS_HOME/usb_gadget/<gadget name>
+e.g.:
+$ mkdir $CONFIGFS_HOME/usb_gadget/g1
+...
+...
+...
+$ cd $CONFIGFS_HOME/usb_gadget/g1
+Each gadget needs to have its vendor id <VID> and product id <PID> specified:
+$ echo <VID> > idVendor
+$ echo <PID> > idProduct
+A gadget also needs its serial number, manufacturer and product strings.
+In order to have a place to store them, a strings subdirectory must be created
+for each language, e.g.:
+$ mkdir strings/0x409
+Then the strings can be specified:
+$ echo <serial number> > strings/0x409/serialnumber
+$ echo <manufacturer> > strings/0x409/manufacturer
+$ echo <product> > strings/0x409/product
+2. Creating the configurations
+------------------------------
+Each gadget will consist of a number of configurations, their corresponding
+directories must be created:
+$ mkdir configs/<name>.<number>
+where <name> can be any string which is legal in a filesystem and the
+<numebr> is the configuration's number, e.g.:
+$ mkdir configs/c.1
+...
+...
+...
+Each configuration also needs its strings, so a subdirectory must be created
+for each language, e.g.:
+$ mkdir configs/c.1/strings/0x409
+Then the configuration string can be specified:
+$ echo <configuration> > configs/c.1/strings/0x409/configuration
+Some attributes can also be set for a configuration, e.g.:
+$ echo 120 > configs/c.1/MaxPower
+3. Creating the functions
+-------------------------
+The gadget will provide some functions, for each function its corresponding
+directory must be created:
+$ mkdir functions/<name>.<instance name>
+where <name> corresponds to one of allowed function names and instance name
+is an arbitrary string allowed in a filesystem, e.g.:
+$ mkdir functions/ncm.usb0 # usb_f_ncm.ko gets loaded with request_module()
+...
+...
+...
+Each function provides its specific set of attributes, with either read-only
+or read-write access. Where applicable they need to be written to as
+appropriate.
+Please refer to Documentation/ABI/*/configfs-usb-gadget* for more information.
+4. Associating the functions with their configurations
+------------------------------------------------------
+At this moment a number of gadgets is created, each of which has a number of
+configurations specified and a number of functions available. What remains
+is specifying which function is available in which configuration (the same
+function can be used in multiple configurations). This is achieved with
+creating symbolic links:
+$ ln -s functions/<name>.<instance name> configs/<name>.<number>
+e.g.:
+$ ln -s functions/ncm.usb0 configs/c.1
+...
+...
+...
+5. Enabling the gadget
+----------------------
+All the above steps serve the purpose of composing the gadget of
+configurations and functions.
+An example directory structure might look like this:
+.
+./strings
+./strings/0x409
+./strings/0x409/serialnumber
+./strings/0x409/product
+./strings/0x409/manufacturer
+./configs
+./configs/c.1
+./configs/c.1/ncm.usb0 -> ../../../../usb_gadget/g1/functions/ncm.usb0
+./configs/c.1/strings
+./configs/c.1/strings/0x409
+./configs/c.1/strings/0x409/configuration
+./configs/c.1/bmAttributes
+./configs/c.1/MaxPower
+./functions
+./functions/ncm.usb0
+./functions/ncm.usb0/ifname
+./functions/ncm.usb0/qmult
+./functions/ncm.usb0/host_addr
+./functions/ncm.usb0/dev_addr
+./UDC
+./bcdUSB
+./bcdDevice
+./idProduct
+./idVendor
+./bMaxPacketSize0
+./bDeviceProtocol
+./bDeviceSubClass
+./bDeviceClass
+Such a gadget must be finally enabled so that the USB host can enumerate it.
+In order to enable the gadget it must be bound to a UDC (USB Device Controller).
+$ echo <udc name> > UDC
+where <udc name> is one of those found in /sys/class/udc/*
+e.g.:
+$ echo s3c-hsotg > UDC
+6. Disabling the gadget
+-----------------------
+$ echo "" > UDC
+7. Cleaning up
+--------------
+Remove functions from configurations:
+$ rm configs/<config name>.<number>/<function>
+where <config name>.<number> specify the configuration and <function> is
+a symlink to a function being removed from the configuration, e.g.:
+$ rm configfs/c.1/ncm.usb0
+...
+...
+...
+Remove strings directories in configurations
+$ rmdir configs/<config name>.<number>/strings/<lang>
+e.g.:
+$ rmdir configs/c.1/strings/0x409
+...
+...
+...
+and remove the configurations
+$ rmdir configs/<config name>.<number>
+e.g.:
+rmdir configs/c.1
+...
+...
+...
+Remove functions (function modules are not unloaded, though)
+$ rmdir functions/<name>.<instance name>
+e.g.:
+$ rmdir functions/ncm.usb0
+...
+...
+...
+Remove strings directories in the gadget
+$ rmdir strings/<lang>
+e.g.:
+$ rmdir strings/0x409
+and finally remove the gadget:
+$ cd ..
+$ rmdir <gadget name>
+e.g.:
+$ rmdir g1
+Implementation design
+=====================
+Below the idea of how configfs works is presented.
+In configfs there are items and groups, both represented as directories.
+The difference between an item and a group is that a group can contain
+other groups. In the picture below only an item is shown.
+Both items and groups can have attributes, which are represented as files.
+The user can create and remove directories, but cannot remove files,
+which can be read-only or read-write, depending on what they represent.
+The filesystem part of configfs operates on config_items/groups and
+configfs_attributes which are generic and of the same type for all
+configured elements. However, they are embedded in usage-specific
+larger structures. In the picture below there is a "cs" which contains
+a config_item and an "sa" which contains a configfs_attribute.
+The filesystem view would be like this:
+./
+./cs        (directory)
+   |
+   +--sa    (file)
+   |
+   .
+   .
+   .
+Whenever a user reads/writes the "sa" file, a function is called
+which accepts a struct config_item and a struct configfs_attribute.
+In the said function the "cs" and "sa" are retrieved using the well
+known container_of technique and an appropriate sa's function (show or
+store) is called and passed the "cs" and a character buffer. The "show"
+is for displaying the file's contents (copy data from the cs to the
+buffer), while the "store" is for modifying the file's contents (copy data
+from the buffer to the cs), but it is up to the implementer of the
+two functions to decide what they actually do.
+typedef struct configured_structure cs;
+typedef struc specific_attribute sa;
+                                       sa
+                       +----------------------------------+
+        cs             |  (*show)(cs *, buffer);          |
+-----------------+    |  (*store)(cs *, buffer, length); |
+|                 |    |                                  |
+| +-------------+ |    |       +------------------+       |
+| | struct      |-|----|------>|struct            |       |
+| | config_item | |    |       |configfs_attribute|       |
+| +-------------+ |    |       +------------------+       |
+|                 |    +----------------------------------+
+| data to be set  |                .
+|                 |                .
+-----------------+                .
+The file names are decided by the config item/group designer, while
+the directories in general can be named at will. A group can have
+a number of its default sub-groups created automatically.
+For more information on configfs please see
+Documentation/filesystems/configfs/*.
+The concepts described above translate to USB gadgets like this:
+1. A gadget has its config group, which has some attributes (idVendor,
+idProduct etc) and default sub-groups (configs, functions, strings).
+Writing to the attributes causes the information to be stored in
+appropriate locations. In the configs, functions and strings sub-groups
+a user can create their sub-groups to represent configurations, functions,
+and groups of strings in a given language.
+2. The user creates configurations and functions, in the configurations
+creates symbolic links to functions. This information is used when the
+gadget's UDC attribute is written to, which means binding the gadget
+to the UDC. The code in drivers/usb/gadget/configfs.c iterates over
+all configurations, and in each configuration it iterates over all
+functions and binds them. This way the whole gadget is bound.
+3. The file drivers/usb/gadget/configfs.c contains code for
+        - gadget's config_group
+        - gadget's default groups (configs, functions, strings)
+        - associating functions with configurations (symlinks)
+4. Each USB function naturally has its own view of what it wants
+configured, so config_groups for particular functions are defined
+in the functions implementation files drivers/usb/gadget/f_*.c.
+5. Funciton's code is written in such a way that it uses
+usb_get_function_instance(), which, in turn, calls request_module.
+So, provided that modprobe works, modules for particular functions
+are loaded automatically. Please note that the converse is not true:
+after a gadget is disabled and torn down, the modules remain loaded.
diff --git a/Documentation/usb/hotplug.txt b/Documentation/usb/hotplug.txt
index 4c945716a660..6424b130485c 100644
--- a/Documentation/usb/hotplug.txt
+++ b/Documentation/usb/hotplug.txt
@@ -33,9 +33,9 @@ you get the best hotplugging when you configure a highly modular system.
 KERNEL HOTPLUG HELPER (/sbin/hotplug)
-When you compile with CONFIG_HOTPLUG, you get a new kernel parameter:
+There is a kernel parameter: /proc/sys/kernel/hotplug, which normally
-/proc/sys/kernel/hotplug, which normally holds the pathname "/sbin/hotplug".
+holds the pathname "/sbin/hotplug".  That parameter names a program
-That parameter names a program which the kernel may invoke at various times.
+which the kernel may invoke at various times.
 The /sbin/hotplug program can be invoked by any subsystem as part of its
 reaction to a configuration change, from a thread in that subsystem.
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 8eda3635a17d..d7993dcf8537 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -172,12 +172,12 @@ group and can access them as follows:
        struct vfio_device_info device_info = { .argsz = sizeof(device_info) };
        /* Create a new container */
-        container = open("/dev/vfio/vfio, O_RDWR);
+        container = open("/dev/vfio/vfio", O_RDWR);
        if (ioctl(container, VFIO_GET_API_VERSION) != VFIO_API_VERSION)
                /* Unknown API version */
-        if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_X86_IOMMU))
+        if (!ioctl(container, VFIO_CHECK_EXTENSION, VFIO_TYPE1_IOMMU))
                /* Doesn't support the IOMMU driver we want. */
        /* Open the group */
@@ -193,7 +193,7 @@ group and can access them as follows:
        ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
        /* Enable the IOMMU model we want */
-        ioctl(container, VFIO_SET_IOMMU, VFIO_X86_IOMMU)
+        ioctl(container, VFIO_SET_IOMMU, VFIO_TYPE1_IOMMU)
        /* Get addition IOMMU info */
        ioctl(container, VFIO_IOMMU_GET_INFO, &iommu_info);
@@ -283,6 +283,69 @@ a direct pass through for VFIO_DEVICE_* ioctls.  The read/write/mmap
 interfaces implement the device region access defined by the device's
 own VFIO_DEVICE_GET_REGION_INFO ioctl.
+PPC64 sPAPR implementation note
+-------------------------------------------------------------------------------
+This implementation has some specifics:
+1) Only one IOMMU group per container is supported as an IOMMU group
+represents the minimal entity which isolation can be guaranteed for and
+groups are allocated statically, one per a Partitionable Endpoint (PE)
+(PE is often a PCI domain but not always).
+2) The hardware supports so called DMA windows - the PCI address range
+within which DMA transfer is allowed, any attempt to access address space
+out of the window leads to the whole PE isolation.
+3) PPC64 guests are paravirtualized but not fully emulated. There is an API
+to map/unmap pages for DMA, and it normally maps 1..32 pages per call and
+currently there is no way to reduce the number of calls. In order to make things
+faster, the map/unmap handling has been implemented in real mode which provides
+an excellent performance which has limitations such as inability to do
+locked pages accounting in real time.
+So 3 additional ioctls have been added:
+        VFIO_IOMMU_SPAPR_TCE_GET_INFO - returns the size and the start
+                of the DMA window on the PCI bus.
+        VFIO_IOMMU_ENABLE - enables the container. The locked pages accounting
+                is done at this point. This lets user first to know what
+                the DMA window is and adjust rlimit before doing any real job.
+        VFIO_IOMMU_DISABLE - disables the container.
+The code flow from the example above should be slightly changed:
+        .....
+        /* Add the group to the container */
+        ioctl(group, VFIO_GROUP_SET_CONTAINER, &container);
+        /* Enable the IOMMU model we want */
+        ioctl(container, VFIO_SET_IOMMU, VFIO_SPAPR_TCE_IOMMU)
+        /* Get addition sPAPR IOMMU info */
+        vfio_iommu_spapr_tce_info spapr_iommu_info;
+        ioctl(container, VFIO_IOMMU_SPAPR_TCE_GET_INFO, &spapr_iommu_info);
+        if (ioctl(container, VFIO_IOMMU_ENABLE))
+                /* Cannot enable container, may be low rlimit */
+        /* Allocate some space and setup a DMA mapping */
+        dma_map.vaddr = mmap(0, 1024 * 1024, PROT_READ | PROT_WRITE,
+                             MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
+        dma_map.size = 1024 * 1024;
+        dma_map.iova = 0; /* 1MB starting at 0x0 from device view */
+        dma_map.flags = VFIO_DMA_MAP_FLAG_READ | VFIO_DMA_MAP_FLAG_WRITE;
+        /* Check here is .iova/.size are within DMA window from spapr_iommu_info */
+        ioctl(container, VFIO_IOMMU_MAP_DMA, &dma_map);
+        .....
 -------------------------------------------------------------------------------
 [1] VFIO was originally an acronym for "Virtual Function I/O" in its
diff --git a/Documentation/video4linux/si476x.txt b/Documentation/video4linux/si476x.txt
index d1a08db2cbd9..2f9b4875ab8a 100644
--- a/Documentation/video4linux/si476x.txt
+++ b/Documentation/video4linux/si476x.txt
@@ -166,7 +166,7 @@ The drivers exposes following files:
  --------------------------------------------------------------------
  0x21          | dev           | Frequency deviation
  --------------------------------------------------------------------
-  0x24          | assi          | Adjascent channel SSI
+  0x24          | assi          | Adjacent channel SSI
  --------------------------------------------------------------------
  0x25          | usn           | Ultrasonic noise indicator
  --------------------------------------------------------------------
diff --git a/Documentation/video4linux/soc-camera.txt b/Documentation/video4linux/soc-camera.txt
index f62fcdbc8b9f..daa9e2ac162c 100644
--- a/Documentation/video4linux/soc-camera.txt
+++ b/Documentation/video4linux/soc-camera.txt
@@ -116,7 +116,7 @@ VIDIOC_S_FMT: sets user window. Should preserve previously set sensor window as
 much as possible by modifying scaling factors. If the sensor window cannot be
 preserved precisely, it may be changed too.
-In soc-camera there are two locations, where scaling and cropping can taks
+In soc-camera there are two locations, where scaling and cropping can take
 place: in the camera driver and in the host driver. User ioctls are first passed
 to the host driver, which then generally passes them down to the camera driver.
 It is more efficient to perform scaling and cropping in the camera driver to
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 5f91eda91647..ef925eaa1460 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -280,7 +280,7 @@ kvm_run' (see below).
 4.11 KVM_GET_REGS
 Capability: basic
-Architectures: all except ARM
+Architectures: all except ARM, arm64
 Type: vcpu ioctl
 Parameters: struct kvm_regs (out)
 Returns: 0 on success, -1 on error
@@ -301,7 +301,7 @@ struct kvm_regs {
 4.12 KVM_SET_REGS
 Capability: basic
-Architectures: all except ARM
+Architectures: all except ARM, arm64
 Type: vcpu ioctl
 Parameters: struct kvm_regs (in)
 Returns: 0 on success, -1 on error
@@ -587,7 +587,7 @@ struct kvm_fpu {
 4.24 KVM_CREATE_IRQCHIP
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64, ARM
+Architectures: x86, ia64, ARM, arm64
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error
@@ -595,14 +595,14 @@ Returns: 0 on success, -1 on error
 Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
-only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM, a GIC is
+only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
 created.
 4.25 KVM_IRQ_LINE
 Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64, arm
+Architectures: x86, ia64, arm, arm64
 Type: vm ioctl
 Parameters: struct kvm_irq_level
 Returns: 0 on success, -1 on error
@@ -612,9 +612,10 @@ On some architectures it is required that an interrupt controller model has
 been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
 interrupts require the level to be set to 1 and then back to 0.
-ARM can signal an interrupt either at the CPU level, or at the in-kernel irqchip
+ARM/arm64 can signal an interrupt either at the CPU level, or at the
-(GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for
+in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
-specific cpus.  The irq field is interpreted like this:
+use PPIs designated for specific cpus.  The irq field is interpreted
+like this:
  bits:  | 31 ... 24 | 23  ... 16 | 15    ...    0 |
  field: | irq_type  | vcpu_index |     irq_id     |
@@ -1683,7 +1684,7 @@ The parameter is defined like this:
 This ioctl maps the memory at "user_addr" with the length "length" to
 the vcpu's address space starting at "vcpu_addr". All parameters need to
-be alligned by 1 megabyte.
+be aligned by 1 megabyte.
 4.66 KVM_S390_UCAS_UNMAP
@@ -1703,7 +1704,7 @@ The parameter is defined like this:
 This ioctl unmaps the memory in the vcpu's address space starting at
 "vcpu_addr" with the length "length". The field "user_addr" is ignored.
-All parameters need to be alligned by 1 megabyte.
+All parameters need to be aligned by 1 megabyte.
 4.67 KVM_S390_VCPU_FAULT
@@ -1831,6 +1832,22 @@ ARM 32-bit VFP control registers have the following id bit patterns:
 ARM 64-bit FP registers have the following id bit patterns:
  0x4030 0000 0012 0 <regno:12>
+arm64 registers are mapped using the lower 32 bits. The upper 16 of
+that is the register group type, or coprocessor number:
+arm64 core/FP-SIMD registers have the following id bit patterns. Note
+that the size of the access is variable, as the kvm_regs structure
+contains elements ranging from 32 to 128 bits. The index is a 32bit
+value in the kvm_regs structure seen as a 32bit array.
+  0x60x0 0000 0010 <index into the kvm_regs struct:16>
+arm64 CCSIDR registers are demultiplexed by CSSELR value:
+  0x6020 0000 0011 00 <csselr:8>
+arm64 system registers have the following id bit patterns:
+  0x6030 0000 0013 <op0:2> <op1:3> <crn:4> <crm:4> <op2:3>
 4.69 KVM_GET_ONE_REG
 Capability: KVM_CAP_ONE_REG
@@ -1972,7 +1989,7 @@ Returns: 0 on success, -1 on error
 This populates and returns a structure describing the features of
 the "Server" class MMU emulation supported by KVM.
-This can in turn be used by userspace to generate the appropariate
+This can in turn be used by userspace to generate the appropriate
 device-tree properties for the guest operating system.
 The structure contains some global informations, followed by an
@@ -2019,7 +2036,7 @@ be OR'ed into the "vsid" argument of the slbmte instruction.
 The "enc" array is a list which for each of those segment base page
 size provides the list of supported actual page sizes (which can be
 only larger or equal to the base page size), along with the
-corresponding encoding in the hash PTE. Similarily, the array is
+corresponding encoding in the hash PTE. Similarly, the array is
 8 entries sorted by increasing sizes and an entry with a "0" shift
 is an empty entry and a terminator:
@@ -2261,10 +2278,10 @@ return indicates the attribute is implemented.  It does not necessarily
 indicate that the attribute can be read or written in the device's
 current state.  "addr" is ignored.
-4.77 KVM_ARM_VCPU_INIT
+4.82 KVM_ARM_VCPU_INIT
 Capability: basic
-Architectures: arm
+Architectures: arm, arm64
 Type: vcpu ioctl
 Parameters: struct struct kvm_vcpu_init (in)
 Returns: 0 on success; -1 on error
@@ -2283,12 +2300,14 @@ should be created before this ioctl is invoked.
 Possible features:
        - KVM_ARM_VCPU_POWER_OFF: Starts the CPU in a power-off state.
          Depends on KVM_CAP_ARM_PSCI.
+        - KVM_ARM_VCPU_EL1_32BIT: Starts the CPU in a 32bit mode.
+          Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
-4.78 KVM_GET_REG_LIST
+4.83 KVM_GET_REG_LIST
 Capability: basic
-Architectures: arm
+Architectures: arm, arm64
 Type: vcpu ioctl
 Parameters: struct kvm_reg_list (in/out)
 Returns: 0 on success; -1 on error
@@ -2305,10 +2324,10 @@ This ioctl returns the guest registers that are supported for the
 KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
-4.80 KVM_ARM_SET_DEVICE_ADDR
+4.84 KVM_ARM_SET_DEVICE_ADDR
 Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
-Architectures: arm
+Architectures: arm, arm64
 Type: vm ioctl
 Parameters: struct kvm_arm_device_address (in)
 Returns: 0 on success, -1 on error
@@ -2329,20 +2348,21 @@ can access emulated or directly exposed devices, which the host kernel needs
 to know about. The id field is an architecture specific identifier for a
 specific device.
-ARM divides the id field into two parts, a device id and an address type id
+ARM/arm64 divides the id field into two parts, a device id and an
-specific to the individual device.
+address type id specific to the individual device.
  bits:  | 63        ...       32 | 31    ...    16 | 15    ...    0 |
  field: |        0x00000000      |     device id   |  addr type id  |
-ARM currently only require this when using the in-kernel GIC support for the
+ARM/arm64 currently only require this when using the in-kernel GIC
-hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id.  When
+support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2
-setting the base address for the guest's mapping of the VGIC virtual CPU
+as the device id.  When setting the base address for the guest's
-and distributor interface, the ioctl must be called after calling
+mapping of the VGIC virtual CPU and distributor interface, the ioctl
-KVM_CREATE_IRQCHIP, but before calling KVM_RUN on any of the VCPUs.  Calling
+must be called after calling KVM_CREATE_IRQCHIP, but before calling
-this ioctl twice for any of the base addresses will return -EEXIST.
+KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
+base addresses will return -EEXIST.
-4.82 KVM_PPC_RTAS_DEFINE_TOKEN
+4.85 KVM_PPC_RTAS_DEFINE_TOKEN
 Capability: KVM_CAP_PPC_RTAS
 Architectures: ppc
diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt
index 43fcb761ed16..290894176142 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -191,12 +191,12 @@ Shadow pages contain the following information:
    A counter keeping track of how many hardware registers (guest cr3 or
    pdptrs) are now pointing at the page.  While this counter is nonzero, the
    page cannot be destroyed.  See role.invalid.
-  multimapped:
+  parent_ptes:
-    Whether there exist multiple sptes pointing at this page.
+    The reverse mapping for the pte/ptes pointing at this page's spt. If
-  parent_pte/parent_ptes:
+    parent_ptes bit 0 is zero, only one spte points at this pages and
-    If multimapped is zero, parent_pte points at the single spte that points at
+    parent_ptes points at this single spte, otherwise, there exists multiple
-    this page's spt.  Otherwise, parent_ptes points at a data structure
+    sptes pointing at this page and (parent_ptes & ~0x1) points at a data
-    with a list of parent_ptes.
+    structure with a list of parent_ptes.
  unsync:
    If true, then the translations in this page may not match the guest's
    translation.  This is equivalent to the state of the tlb when a pte is
@@ -210,6 +210,24 @@ Shadow pages contain the following information:
    A bitmap indicating which sptes in spt point (directly or indirectly) at
    pages that may be unsynchronized.  Used to quickly locate all unsychronized
    pages reachable from a given page.
+  mmu_valid_gen:
+    Generation number of the page.  It is compared with kvm->arch.mmu_valid_gen
+    during hash table lookup, and used to skip invalidated shadow pages (see
+    "Zapping all pages" below.)
+  clear_spte_count:
+    Only present on 32-bit hosts, where a 64-bit spte cannot be written
+    atomically.  The reader uses this while running out of the MMU lock
+    to detect in-progress updates and retry them until the writer has
+    finished the write.
+  write_flooding_count:
+    A guest may write to a page table many times, causing a lot of
+    emulations if the page needs to be write-protected (see "Synchronized
+    and unsynchronized pages" below).  Leaf pages can be unsynchronized
+    so that they do not trigger frequent emulation, but this is not
+    possible for non-leafs.  This field counts the number of emulations
+    since the last time the page table was actually used; if emulation
+    is triggered too frequently on this page, KVM will unmap the page
+    to avoid emulation in the future.
 Reverse map
 ===========
@@ -258,14 +276,26 @@ This is the most complicated event.  The cause of a page fault can be:
 Handling a page fault is performed as follows:
+ - if the RSV bit of the error code is set, the page fault is caused by guest
+   accessing MMIO and cached MMIO information is available.
+   - walk shadow page table
+   - check for valid generation number in the spte (see "Fast invalidation of
+     MMIO sptes" below)
+   - cache the information to vcpu->arch.mmio_gva, vcpu->arch.access and
+     vcpu->arch.mmio_gfn, and call the emulator
+ - If both P bit and R/W bit of error code are set, this could possibly
+   be handled as a "fast page fault" (fixed without taking the MMU lock).  See
+   the description in Documentation/virtual/kvm/locking.txt.
 - if needed, walk the guest page tables to determine the guest translation
   (gva->gpa or ngpa->gpa)
   - if permissions are insufficient, reflect the fault back to the guest
 - determine the host page
-   - if this is an mmio request, there is no host page; call the emulator
+   - if this is an mmio request, there is no host page; cache the info to
-     to emulate the instruction instead
+     vcpu->arch.mmio_gva, vcpu->arch.access and vcpu->arch.mmio_gfn
 - walk the shadow page table to find the spte for the translation,
   instantiating missing intermediate page tables as necessary
+   - If this is an mmio request, cache the mmio info to the spte and set some
+     reserved bit on the spte (see callers of kvm_mmu_set_mmio_spte_mask)
 - try to unsynchronize the page
   - if successful, we can let the guest continue and modify the gpte
 - emulate the instruction
@@ -351,6 +381,51 @@ causes its write_count to be incremented, thus preventing instantiation of
 a large spte.  The frames at the end of an unaligned memory slot have
 artificially inflated ->write_counts so they can never be instantiated.
+Zapping all pages (page generation count)
+=========================================
+For the large memory guests, walking and zapping all pages is really slow
+(because there are a lot of pages), and also blocks memory accesses of
+all VCPUs because it needs to hold the MMU lock.
+To make it be more scalable, kvm maintains a global generation number
+which is stored in kvm->arch.mmu_valid_gen.  Every shadow page stores
+the current global generation-number into sp->mmu_valid_gen when it
+is created.  Pages with a mismatching generation number are "obsolete".
+When KVM need zap all shadow pages sptes, it just simply increases the global
+generation-number then reload root shadow pages on all vcpus.  As the VCPUs
+create new shadow page tables, the old pages are not used because of the
+mismatching generation number.
+KVM then walks through all pages and zaps obsolete pages.  While the zap
+operation needs to take the MMU lock, the lock can be released periodically
+so that the VCPUs can make progress.
+Fast invalidation of MMIO sptes
+===============================
+As mentioned in "Reaction to events" above, kvm will cache MMIO
+information in leaf sptes.  When a new memslot is added or an existing
+memslot is changed, this information may become stale and needs to be
+invalidated.  This also needs to hold the MMU lock while walking all
+shadow pages, and is made more scalable with a similar technique.
+MMIO sptes have a few spare bits, which are used to store a
+generation number.  The global generation number is stored in
+kvm_memslots(kvm)->generation, and increased whenever guest memory info
+changes.  This generation number is distinct from the one described in
+the previous section.
+When KVM finds an MMIO spte, it checks the generation number of the spte.
+If the generation number of the spte does not equal the global generation
+number, it will ignore the cached MMIO information and handle the page
+fault through the slow path.
+Since only 19 bits are used to store generation-number on mmio spte, all
+pages are zapped when there is an overflow.
 Further reading
 ===============
diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
index a5f8436753e7..f4099ca6b483 100644
--- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
+++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
@@ -3127,7 +3127,7 @@
           at process_kern.c:156
       #3  0x1006a052 in switch_to (prev=0x50072000, next=0x507e8000, last=0x50072000)
           at process_kern.c:161
-       #4  0x10001d12 in schedule () at sched.c:777
+       #4  0x10001d12 in schedule () at core.c:777
       #5  0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
       #6  0x1006aa10 in __down_failed () at semaphore.c:157
       #7  0x1006c5d8 in segv_handler (sc=0x5006e940) at trap_user.c:174
@@ -3191,7 +3191,7 @@
           at process_kern.c:161
       161       _switch_to(prev, next);
       (gdb)
-       #4  0x10001d12 in schedule () at sched.c:777
+       #4  0x10001d12 in schedule () at core.c:777
       777             switch_to(prev, next, prev);
       (gdb)
       #5  0x1006a744 in __down (sem=0x507d241c) at semaphore.c:71
diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt
index 7587493c67f1..5948e455c4d2 100644
--- a/Documentation/vm/pagemap.txt
+++ b/Documentation/vm/pagemap.txt
@@ -15,7 +15,8 @@ There are three components to pagemap:
    * Bits 0-54  page frame number (PFN) if present
    * Bits 0-4   swap type if swapped
    * Bits 5-54  swap offset if swapped
-    * Bits 55-60 page shift (page size = 1<<page shift)
+    * Bit  55    pte is soft-dirty (see Documentation/vm/soft-dirty.txt)
+    * Bits 56-60 zero
    * Bit  61    page is file-page or shared-anon
    * Bit  62    page swapped
    * Bit  63    page present
@@ -147,5 +148,5 @@ once.
 Other notes:
 Reading from any of the files will return -EINVAL if you are not starting
-the read on an 8-byte boundary (e.g., if you seeked an odd number of bytes
+the read on an 8-byte boundary (e.g., if you sought an odd number of bytes
 into the file), or if the size of the read is not a multiple of 8 bytes.
diff --git a/Documentation/vm/soft-dirty.txt b/Documentation/vm/soft-dirty.txt
new file mode 100644
index 000000000000..9a12a5956bc0
--- /dev/null
+++ b/Documentation/vm/soft-dirty.txt
@@ -0,0 +1,36 @@
+                            SOFT-DIRTY PTEs
+  The soft-dirty is a bit on a PTE which helps to track which pages a task
+writes to. In order to do this tracking one should
+  1. Clear soft-dirty bits from the task's PTEs.
+     This is done by writing "4" into the /proc/PID/clear_refs file of the
+     task in question.
+  2. Wait some time.
+  3. Read soft-dirty bits from the PTEs.
+     This is done by reading from the /proc/PID/pagemap. The bit 55 of the
+     64-bit qword is the soft-dirty one. If set, the respective PTE was
+     written to since step 1.
+  Internally, to do this tracking, the writable bit is cleared from PTEs
+when the soft-dirty bit is cleared. So, after this, when the task tries to
+modify a page at some virtual address the #PF occurs and the kernel sets
+the soft-dirty bit on the respective PTE.
+  Note, that although all the task's address space is marked as r/o after the
+soft-dirty bits clear, the #PF-s that occur after that are processed fast.
+This is so, since the pages are still mapped to physical memory, and thus all
+the kernel does is finds this fact out and puts both writable and soft-dirty
+bits on the PTE.
+  This feature is actively used by the checkpoint-restore project. You
+can find more details about it on http://criu.org
+-- Pavel Emelyanov, Apr 9, 2013
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 8785fb87d9c7..4a63953a41f1 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -120,8 +120,8 @@ By default kernel tries to use huge zero page on read page fault.
 It's possible to disable huge zero page by writing 0 or enable it
 back by writing 1:
-echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page
+echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
-echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page
+echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
 khugepaged will be automatically started when
 transparent_hugepage/enabled is set to "always" or "madvise, and it'll
diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt
new file mode 100644
index 000000000000..7e492d8aaeaf
--- /dev/null
+++ b/Documentation/vm/zswap.txt
@@ -0,0 +1,68 @@
+Overview:
+Zswap is a lightweight compressed cache for swap pages. It takes pages that are
+in the process of being swapped out and attempts to compress them into a
+dynamically allocated RAM-based memory pool.  zswap basically trades CPU cycles
+for potentially reduced swap I/O.  This trade-off can also result in a
+significant performance improvement if reads from the compressed cache are
+faster than reads from a swap device.
+NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
+reclaim.  This interaction has not be fully explored on the large set of
+potential configurations and workloads that exist.  For this reason, zswap
+is a work in progress and should be considered experimental.
+Some potential benefits:
+* Desktop/laptop users with limited RAM capacities can mitigate the
+    performance impact of swapping.
+* Overcommitted guests that share a common I/O resource can
+    dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
+    throttling by the hypervisor. This allows more work to get done with less
+    impact to the guest workload and guests sharing the I/O subsystem
+* Users with SSDs as swap devices can extend the life of the device by
+    drastically reducing life-shortening writes.
+Zswap evicts pages from compressed cache on an LRU basis to the backing swap
+device when the compressed pool reaches it size limit.  This requirement had
+been identified in prior community discussions.
+To enabled zswap, the "enabled" attribute must be set to 1 at boot time.  e.g.
+zswap.enabled=1
+Design:
+Zswap receives pages for compression through the Frontswap API and is able to
+evict pages from its own compressed pool on an LRU basis and write them back to
+the backing swap device in the case that the compressed pool is full.
+Zswap makes use of zbud for the managing the compressed memory pool.  Each
+allocation in zbud is not directly accessible by address.  Rather, a handle is
+return by the allocation routine and that handle must be mapped before being
+accessed.  The compressed memory pool grows on demand and shrinks as compressed
+pages are freed.  The pool is not preallocated.
+When a swap page is passed from frontswap to zswap, zswap maintains a mapping
+of the swap entry, a combination of the swap type and swap offset, to the zbud
+handle that references that compressed swap page.  This mapping is achieved
+with a red-black tree per swap type.  The swap offset is the search key for the
+tree nodes.
+During a page fault on a PTE that is a swap entry, frontswap calls the zswap
+load function to decompress the page into the page allocated by the page fault
+handler.
+Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
+in the swap_map goes to 0) the swap code calls the zswap invalidate function,
+via frontswap, to free the compressed entry.
+Zswap seeks to be simple in its policies.  Sysfs attributes allow for one user
+controlled policies:
+* max_pool_percent - The maximum percentage of memory that the compressed
+    pool can occupy.
+Zswap allows the compressor to be selected at kernel boot time by setting the
+“compressor” attribute.  The default compressor is lzo.  e.g.
+zswap.compressor=deflate
+A debugfs interface is provided for various statistic about pool size, number
+of pages stored, and various counters for the reasons pages are rejected.
diff --git a/Documentation/w1/slaves/w1_ds28e04 b/Documentation/w1/slaves/w1_ds28e04
index 85bc9a7e02fe..7819b65cfa48 100644
--- a/Documentation/w1/slaves/w1_ds28e04
+++ b/Documentation/w1/slaves/w1_ds28e04
@@ -24,7 +24,7 @@ Memory Access
        A write operation on the "eeprom" file writes the given byte sequence
        to the EEPROM of the DS28E04. If CRC checking mode is enabled only
-        fully alligned blocks of 32 bytes with valid CRC16 values (in bytes 30
+        fully aligned blocks of 32 bytes with valid CRC16 values (in bytes 30
        and 31) are allowed to be written.
 PIO Access
diff --git a/Documentation/w1/w1.generic b/Documentation/w1/w1.generic
index 212f4ac31c01..a31c5a242973 100644
--- a/Documentation/w1/w1.generic
+++ b/Documentation/w1/w1.generic
@@ -25,8 +25,8 @@ When a w1 master driver registers with the w1 subsystem, the following occurs:
 - sysfs entries for that w1 master are created
 - the w1 bus is periodically searched for new slave devices
-When a device is found on the bus, w1 core checks if driver for its family is
+When a device is found on the bus, w1 core tries to load the driver for its family
-loaded. If so, the family driver is attached to the slave.
+and check if it is loaded. If so, the family driver is attached to the slave.
 If there is no driver for the family, default one is assigned, which allows to perform
 almost any kind of operations. Each logical operation is a transaction
 in nature, which can contain several (two or one) low-level operations.
diff --git a/Documentation/ww-mutex-design.txt b/Documentation/ww-mutex-design.txt
new file mode 100644
index 000000000000..8a112dc304c3
--- /dev/null
+++ b/Documentation/ww-mutex-design.txt
@@ -0,0 +1,344 @@
+Wait/Wound Deadlock-Proof Mutex Design
+======================================
+Please read mutex-design.txt first, as it applies to wait/wound mutexes too.
+Motivation for WW-Mutexes
+-------------------------
+GPU's do operations that commonly involve many buffers.  Those buffers
+can be shared across contexts/processes, exist in different memory
+domains (for example VRAM vs system memory), and so on.  And with
+PRIME / dmabuf, they can even be shared across devices.  So there are
+a handful of situations where the driver needs to wait for buffers to
+become ready.  If you think about this in terms of waiting on a buffer
+mutex for it to become available, this presents a problem because
+there is no way to guarantee that buffers appear in a execbuf/batch in
+the same order in all contexts.  That is directly under control of
+userspace, and a result of the sequence of GL calls that an application
+makes.  Which results in the potential for deadlock.  The problem gets
+more complex when you consider that the kernel may need to migrate the
+buffer(s) into VRAM before the GPU operates on the buffer(s), which
+may in turn require evicting some other buffers (and you don't want to
+evict other buffers which are already queued up to the GPU), but for a
+simplified understanding of the problem you can ignore this.
+The algorithm that the TTM graphics subsystem came up with for dealing with
+this problem is quite simple.  For each group of buffers (execbuf) that need
+to be locked, the caller would be assigned a unique reservation id/ticket,
+from a global counter.  In case of deadlock while locking all the buffers
+associated with a execbuf, the one with the lowest reservation ticket (i.e.
+the oldest task) wins, and the one with the higher reservation id (i.e. the
+younger task) unlocks all of the buffers that it has already locked, and then
+tries again.
+In the RDBMS literature this deadlock handling approach is called wait/wound:
+The older tasks waits until it can acquire the contended lock. The younger tasks
+needs to back off and drop all the locks it is currently holding, i.e. the
+younger task is wounded.
+Concepts
+--------
+Compared to normal mutexes two additional concepts/objects show up in the lock
+interface for w/w mutexes:
+Acquire context: To ensure eventual forward progress it is important the a task
+trying to acquire locks doesn't grab a new reservation id, but keeps the one it
+acquired when starting the lock acquisition. This ticket is stored in the
+acquire context. Furthermore the acquire context keeps track of debugging state
+to catch w/w mutex interface abuse.
+W/w class: In contrast to normal mutexes the lock class needs to be explicit for
+w/w mutexes, since it is required to initialize the acquire context.
+Furthermore there are three different class of w/w lock acquire functions:
+* Normal lock acquisition with a context, using ww_mutex_lock.
+* Slowpath lock acquisition on the contending lock, used by the wounded task
+  after having dropped all already acquired locks. These functions have the
+  _slow postfix.
+  From a simple semantics point-of-view the _slow functions are not strictly
+  required, since simply calling the normal ww_mutex_lock functions on the
+  contending lock (after having dropped all other already acquired locks) will
+  work correctly. After all if no other ww mutex has been acquired yet there's
+  no deadlock potential and hence the ww_mutex_lock call will block and not
+  prematurely return -EDEADLK. The advantage of the _slow functions is in
+  interface safety:
+  - ww_mutex_lock has a __must_check int return type, whereas ww_mutex_lock_slow
+    has a void return type. Note that since ww mutex code needs loops/retries
+    anyway the __must_check doesn't result in spurious warnings, even though the
+    very first lock operation can never fail.
+  - When full debugging is enabled ww_mutex_lock_slow checks that all acquired
+    ww mutex have been released (preventing deadlocks) and makes sure that we
+    block on the contending lock (preventing spinning through the -EDEADLK
+    slowpath until the contended lock can be acquired).
+* Functions to only acquire a single w/w mutex, which results in the exact same
+  semantics as a normal mutex. This is done by calling ww_mutex_lock with a NULL
+  context.
+  Again this is not strictly required. But often you only want to acquire a
+  single lock in which case it's pointless to set up an acquire context (and so
+  better to avoid grabbing a deadlock avoidance ticket).
+Of course, all the usual variants for handling wake-ups due to signals are also
+provided.
+Usage
+-----
+Three different ways to acquire locks within the same w/w class. Common
+definitions for methods #1 and #2:
+static DEFINE_WW_CLASS(ww_class);
+struct obj {
+        struct ww_mutex lock;
+        /* obj data */
+};
+struct obj_entry {
+        struct list_head head;
+        struct obj *obj;
+};
+Method 1, using a list in execbuf->buffers that's not allowed to be reordered.
+This is useful if a list of required objects is already tracked somewhere.
+Furthermore the lock helper can use propagate the -EALREADY return code back to
+the caller as a signal that an object is twice on the list. This is useful if
+the list is constructed from userspace input and the ABI requires userspace to
+not have duplicate entries (e.g. for a gpu commandbuffer submission ioctl).
+int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+        struct obj *res_obj = NULL;
+        struct obj_entry *contended_entry = NULL;
+        struct obj_entry *entry;
+        ww_acquire_init(ctx, &ww_class);
+retry:
+        list_for_each_entry (entry, list, head) {
+                if (entry->obj == res_obj) {
+                        res_obj = NULL;
+                        continue;
+                }
+                ret = ww_mutex_lock(&entry->obj->lock, ctx);
+                if (ret < 0) {
+                        contended_entry = entry;
+                        goto err;
+                }
+        }
+        ww_acquire_done(ctx);
+        return 0;
+err:
+        list_for_each_entry_continue_reverse (entry, list, head)
+                ww_mutex_unlock(&entry->obj->lock);
+        if (res_obj)
+                ww_mutex_unlock(&res_obj->lock);
+        if (ret == -EDEADLK) {
+                /* we lost out in a seqno race, lock and retry.. */
+                ww_mutex_lock_slow(&contended_entry->obj->lock, ctx);
+                res_obj = contended_entry->obj;
+                goto retry;
+        }
+        ww_acquire_fini(ctx);
+        return ret;
+}
+Method 2, using a list in execbuf->buffers that can be reordered. Same semantics
+of duplicate entry detection using -EALREADY as method 1 above. But the
+list-reordering allows for a bit more idiomatic code.
+int lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+        struct obj_entry *entry, *entry2;
+        ww_acquire_init(ctx, &ww_class);
+        list_for_each_entry (entry, list, head) {
+                ret = ww_mutex_lock(&entry->obj->lock, ctx);
+                if (ret < 0) {
+                        entry2 = entry;
+                        list_for_each_entry_continue_reverse (entry2, list, head)
+                                ww_mutex_unlock(&entry2->obj->lock);
+                        if (ret != -EDEADLK) {
+                                ww_acquire_fini(ctx);
+                                return ret;
+                        }
+                        /* we lost out in a seqno race, lock and retry.. */
+                        ww_mutex_lock_slow(&entry->obj->lock, ctx);
+                        /*
+                         * Move buf to head of the list, this will point
+                         * buf->next to the first unlocked entry,
+                         * restarting the for loop.
+                         */
+                        list_del(&entry->head);
+                        list_add(&entry->head, list);
+                }
+        }
+        ww_acquire_done(ctx);
+        return 0;
+}
+Unlocking works the same way for both methods #1 and #2:
+void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+        struct obj_entry *entry;
+        list_for_each_entry (entry, list, head)
+                ww_mutex_unlock(&entry->obj->lock);
+        ww_acquire_fini(ctx);
+}
+Method 3 is useful if the list of objects is constructed ad-hoc and not upfront,
+e.g. when adjusting edges in a graph where each node has its own ww_mutex lock,
+and edges can only be changed when holding the locks of all involved nodes. w/w
+mutexes are a natural fit for such a case for two reasons:
+- They can handle lock-acquisition in any order which allows us to start walking
+  a graph from a starting point and then iteratively discovering new edges and
+  locking down the nodes those edges connect to.
+- Due to the -EALREADY return code signalling that a given objects is already
+  held there's no need for additional book-keeping to break cycles in the graph
+  or keep track off which looks are already held (when using more than one node
+  as a starting point).
+Note that this approach differs in two important ways from the above methods:
+- Since the list of objects is dynamically constructed (and might very well be
+  different when retrying due to hitting the -EDEADLK wound condition) there's
+  no need to keep any object on a persistent list when it's not locked. We can
+  therefore move the list_head into the object itself.
+- On the other hand the dynamic object list construction also means that the -EALREADY return
+  code can't be propagated.
+Note also that methods #1 and #2 and method #3 can be combined, e.g. to first lock a
+list of starting nodes (passed in from userspace) using one of the above
+methods. And then lock any additional objects affected by the operations using
+method #3 below. The backoff/retry procedure will be a bit more involved, since
+when the dynamic locking step hits -EDEADLK we also need to unlock all the
+objects acquired with the fixed list. But the w/w mutex debug checks will catch
+any interface misuse for these cases.
+Also, method 3 can't fail the lock acquisition step since it doesn't return
+-EALREADY. Of course this would be different when using the _interruptible
+variants, but that's outside of the scope of these examples here.
+struct obj {
+        struct ww_mutex ww_mutex;
+        struct list_head locked_list;
+};
+static DEFINE_WW_CLASS(ww_class);
+void __unlock_objs(struct list_head *list)
+{
+        struct obj *entry, *temp;
+        list_for_each_entry_safe (entry, temp, list, locked_list) {
+                /* need to do that before unlocking, since only the current lock holder is
+                allowed to use object */
+                list_del(&entry->locked_list);
+                ww_mutex_unlock(entry->ww_mutex)
+        }
+}
+void lock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+        struct obj *obj;
+        ww_acquire_init(ctx, &ww_class);
+retry:
+        /* re-init loop start state */
+        loop {
+                /* magic code which walks over a graph and decides which objects
+                 * to lock */
+                ret = ww_mutex_lock(obj->ww_mutex, ctx);
+                if (ret == -EALREADY) {
+                        /* we have that one already, get to the next object */
+                        continue;
+                }
+                if (ret == -EDEADLK) {
+                        __unlock_objs(list);
+                        ww_mutex_lock_slow(obj, ctx);
+                        list_add(&entry->locked_list, list);
+                        goto retry;
+                }
+                /* locked a new object, add it to the list */
+                list_add_tail(&entry->locked_list, list);
+        }
+        ww_acquire_done(ctx);
+        return 0;
+}
+void unlock_objs(struct list_head *list, struct ww_acquire_ctx *ctx)
+{
+        __unlock_objs(list);
+        ww_acquire_fini(ctx);
+}
+Method 4: Only lock one single objects. In that case deadlock detection and
+prevention is obviously overkill, since with grabbing just one lock you can't
+produce a deadlock within just one class. To simplify this case the w/w mutex
+api can be used with a NULL context.
+Implementation Details
+----------------------
+Design:
+  ww_mutex currently encapsulates a struct mutex, this means no extra overhead for
+  normal mutex locks, which are far more common. As such there is only a small
+  increase in code size if wait/wound mutexes are not used.
+  In general, not much contention is expected. The locks are typically used to
+  serialize access to resources for devices. The only way to make wakeups
+  smarter would be at the cost of adding a field to struct mutex_waiter. This
+  would add overhead to all cases where normal mutexes are used, and
+  ww_mutexes are generally less performance sensitive.
+Lockdep:
+  Special care has been taken to warn for as many cases of api abuse
+  as possible. Some common api abuses will be caught with
+  CONFIG_DEBUG_MUTEXES, but CONFIG_PROVE_LOCKING is recommended.
+  Some of the errors which will be warned about:
+   - Forgetting to call ww_acquire_fini or ww_acquire_init.
+   - Attempting to lock more mutexes after ww_acquire_done.
+   - Attempting to lock the wrong mutex after -EDEADLK and
+     unlocking all mutexes.
+   - Attempting to lock the right mutex after -EDEADLK,
+     before unlocking all mutexes.
+   - Calling ww_mutex_lock_slow before -EDEADLK was returned.
+   - Unlocking mutexes with the wrong unlock function.
+   - Calling one of the ww_acquire_* twice on the same context.
+   - Using a different ww_class for the mutex than for the ww_acquire_ctx.
+   - Normal lockdep errors that can result in deadlocks.
+  Some of the lockdep errors that can result in deadlocks:
+   - Calling ww_acquire_init to initialize a second ww_acquire_ctx before
+     having called ww_acquire_fini on the first.
+   - 'normal' deadlocks that can occur.
+FIXME: Update this section once we have the TASK_DEADLOCK task state flag magic
+implemented.
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index 3840b6f28afb..fc66d42422ee 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -657,9 +657,10 @@ Protocol:	2.08+
  uncompressed data should be determined using the standard magic
  numbers.  The currently supported compression formats are gzip
  (magic numbers 1F 8B or 1F 9E), bzip2 (magic number 42 5A), LZMA
-  (magic number 5D 00), and XZ (magic number FD 37).  The uncompressed
+  (magic number 5D 00), XZ (magic number FD 37), and LZ4 (magic number
-  payload is currently always ELF (magic number 7F 45 4C 46).
+  02 21).  The uncompressed payload is currently always ELF (magic
-  
+  number 7F 45 4C 46).
 Field name:     payload_length
 Type:           read
 Offset/size:    0x24c/4
diff --git a/Documentation/x86/early-microcode.txt b/Documentation/x86/early-microcode.txt
index 4aaf0dfb0cb8..d62bea6796da 100644
--- a/Documentation/x86/early-microcode.txt
+++ b/Documentation/x86/early-microcode.txt
@@ -11,7 +11,8 @@ file and loaded to CPUs during boot time.
 The format of the combined initrd image is microcode in cpio format followed by
 the initrd image (maybe compressed). Kernel parses the combined initrd image
 during boot time. The microcode file in cpio name space is:
-kernel/x86/microcode/GenuineIntel.bin
+on Intel: kernel/x86/microcode/GenuineIntel.bin
+on AMD  : kernel/x86/microcode/AuthenticAMD.bin
 During BSP boot (before SMP starts), if the kernel finds the microcode file in
 the initrd file, it parses the microcode and saves matching microcode in memory.
@@ -34,10 +35,8 @@ original initrd image /boot/initrd-3.5.0.img.
 mkdir initrd
 cd initrd
-mkdir kernel
+mkdir -p kernel/x86/microcode
-mkdir kernel/x86
+cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin (or AuthenticAMD.bin)
-mkdir kernel/x86/microcode
+find . | cpio -o -H newc >../ucode.cpio
-cp ../microcode.bin kernel/x86/microcode/GenuineIntel.bin
-find .|cpio -oc >../ucode.cpio
 cd ..
 cat ucode.cpio /boot/initrd-3.5.0.img >/boot/initrd-3.5.0.ucode.img