242 files changed, 9626 insertions, 2523 deletions

diff --git a/Documentation/ABI/README b/Documentation/ABI/README
index 10069828568b..1fafc4b0753b 100644
--- a/Documentation/ABI/README
+++ b/Documentation/ABI/README
@@ -72,3 +72,16 @@ kernel tree without going through the obsolete state first.
 
 It's up to the developer to place their interfaces in the category they
 wish for it to start out in.
+
+
+Notable bits of non-ABI, which should not under any circumstances be considered
+stable:
+
+- Kconfig.  Userspace should not rely on the presence or absence of any
+  particular Kconfig symbol, in /proc/config.gz, in the copy of .config
+  commonly installed to /boot, or in any invocation of the kernel build
+  process.
+
+- Kernel-internal symbols.  Do not rely on the presence, absence, location, or
+  type of any kernel symbol, either in System.map files or the kernel binary
+  itself.  See Documentation/stable_api_nonsense.txt.
diff --git a/Documentation/ABI/stable/sysfs-bus-usb b/Documentation/ABI/stable/sysfs-bus-usb
index 2be603c52a24..a6b685724740 100644
--- a/Documentation/ABI/stable/sysfs-bus-usb
+++ b/Documentation/ABI/stable/sysfs-bus-usb
@@ -37,8 +37,8 @@ Description:
                 that the USB device has been connected to the machine.  This
                 file is read-only.
 Users:
-                PowerTOP <power@bughost.org>
-                http://www.lesswatts.org/projects/powertop/
+                PowerTOP <powertop@lists.01.org>
+                https://01.org/powertop/
 
 What:           /sys/bus/usb/device/.../power/active_duration
 Date:           January 2008
@@ -57,8 +57,8 @@ Description:
                 will give an integer percentage.  Note that this does not
                 account for counter wrap.
 Users:
-                PowerTOP <power@bughost.org>
-                http://www.lesswatts.org/projects/powertop/
+                PowerTOP <powertop@lists.01.org>
+                https://01.org/powertop/
 
 What:           /sys/bus/usb/devices/<busnum>-<port[.port]>...:<config num>-<interface num>/supports_autosuspend
 Date:           January 2008
diff --git a/Documentation/ABI/stable/sysfs-driver-ib_srp b/Documentation/ABI/stable/sysfs-driver-ib_srp
index 5c53d28f775c..b9688de8455b 100644
--- a/Documentation/ABI/stable/sysfs-driver-ib_srp
+++ b/Documentation/ABI/stable/sysfs-driver-ib_srp
@@ -61,6 +61,12 @@ Description:	Interface for making ib_srp connect to a new target.
                   interrupt is handled by a different CPU then the comp_vector
                   parameter can be used to spread the SRP completion workload
                   over multiple CPU's.
+                * tl_retry_count, a number in the range 2..7 specifying the
+                  IB RC retry count.
+                * queue_size, the maximum number of commands that the
+                  initiator is allowed to queue per SCSI host. The default
+                  value for this parameter is 62. The lowest supported value
+                  is 2.
 
 What:           /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
 Date:           January 2, 2006
@@ -153,6 +159,13 @@ Contact:	linux-rdma@vger.kernel.org
 Description:    InfiniBand service ID used for establishing communication with
                 the SRP target.
 
+What:           /sys/class/scsi_host/host<n>/sgid
+Date:           February 1, 2014
+KernelVersion:  3.13
+Contact:        linux-rdma@vger.kernel.org
+Description:    InfiniBand GID of the source port used for communication with
+                the SRP target.
+
 What:           /sys/class/scsi_host/host<n>/zero_req_lim
 Date:           September 20, 2006
 KernelVersion:  2.6.18
diff --git a/Documentation/ABI/stable/sysfs-transport-srp b/Documentation/ABI/stable/sysfs-transport-srp
index b36fb0dc13c8..ec7af69fea0a 100644
--- a/Documentation/ABI/stable/sysfs-transport-srp
+++ b/Documentation/ABI/stable/sysfs-transport-srp
@@ -5,6 +5,24 @@ Contact:	linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
 Description:    Instructs an SRP initiator to disconnect from a target and to
                 remove all LUNs imported from that target.
 
+What:           /sys/class/srp_remote_ports/port-<h>:<n>/dev_loss_tmo
+Date:           February 1, 2014
+KernelVersion:  3.13
+Contact:        linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
+Description:    Number of seconds the SCSI layer will wait after a transport
+                layer error has been observed before removing a target port.
+                Zero means immediate removal. Setting this attribute to "off"
+                will disable the dev_loss timer.
+
+What:           /sys/class/srp_remote_ports/port-<h>:<n>/fast_io_fail_tmo
+Date:           February 1, 2014
+KernelVersion:  3.13
+Contact:        linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
+Description:    Number of seconds the SCSI layer will wait after a transport
+                layer error has been observed before failing I/O. Zero means
+                failing I/O immediately. Setting this attribute to "off" will
+                disable the fast_io_fail timer.
+
 What:           /sys/class/srp_remote_ports/port-<h>:<n>/port_id
 Date:           June 27, 2007
 KernelVersion:  2.6.24
@@ -12,8 +30,29 @@ Contact:	linux-scsi@vger.kernel.org
 Description:    16-byte local SRP port identifier in hexadecimal format. An
                 example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
 
+What:           /sys/class/srp_remote_ports/port-<h>:<n>/reconnect_delay
+Date:           February 1, 2014
+KernelVersion:  3.13
+Contact:        linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
+Description:    Number of seconds the SCSI layer will wait after a reconnect
+                attempt failed before retrying. Setting this attribute to
+                "off" will disable time-based reconnecting.
+
 What:           /sys/class/srp_remote_ports/port-<h>:<n>/roles
 Date:           June 27, 2007
 KernelVersion:  2.6.24
 Contact:        linux-scsi@vger.kernel.org
 Description:    Role of the remote port. Either "SRP Initiator" or "SRP Target".
+
+What:           /sys/class/srp_remote_ports/port-<h>:<n>/state
+Date:           February 1, 2014
+KernelVersion:  3.13
+Contact:        linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
+Description:    State of the transport layer used for communication with the
+                remote port. "running" if the transport layer is operational;
+                "blocked" if a transport layer error has been encountered but
+                the fast_io_fail_tmo timer has not yet fired; "fail-fast"
+                after the fast_io_fail_tmo timer has fired and before the
+                "dev_loss_tmo" timer has fired; "lost" after the
+                "dev_loss_tmo" timer has fired and before the port is finally
+                removed.
diff --git a/Documentation/ABI/testing/configfs-usb-gadget-mass-storage b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
new file mode 100644
index 000000000000..ad72a37ee9ff
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-usb-gadget-mass-storage
@@ -0,0 +1,31 @@
+What:           /config/usb-gadget/gadget/functions/mass_storage.name
+Date:           Oct 2013
+KenelVersion:   3.13
+Description:
+                The attributes:
+
+                stall           - Set to permit function to halt bulk endpoints.
+                                Disabled on some USB devices known not to work
+                                correctly. You should set it to true.
+                num_buffers     - Number of pipeline buffers. Valid numbers
+                                are 2..4. Available only if
+                                CONFIG_USB_GADGET_DEBUG_FILES is set.
+
+What:           /config/usb-gadget/gadget/functions/mass_storage.name/lun.name
+Date:           Oct 2013
+KenelVersion:   3.13
+Description:
+                The attributes:
+
+                file            - The path to the backing file for the LUN.
+                                Required if LUN is not marked as removable.
+                ro              - Flag specifying access to the LUN shall be
+                                read-only. This is implied if CD-ROM emulation
+                                is enabled as well as when it was impossible
+                                to open "filename" in R/W mode.
+                removable       - Flag specifying that LUN shall be indicated as
+                                being removable.
+                cdrom           - Flag specifying that LUN shall be reported as
+                                being a CD-ROM.
+                nofua           - Flag specifying that FUA flag
+                                in SCSI WRITE(10,12)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 39c8de0e53d0..b20e829d350f 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -79,7 +79,7 @@ Description:
                 correspond to externally available input one of the named
                 versions may be used. The number must always be specified and
                 unique to allow association with event codes. Units after
-                application of scale and offset are microvolts.
+                application of scale and offset are millivolts.
 
 What:           /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_raw
 KernelVersion:  2.6.35
@@ -90,7 +90,7 @@ Description:
                 physically equivalent inputs when non differential readings are
                 separately available. In differential only parts, then all that
                 is required is a consistent labeling.  Units after application
-                of scale and offset are microvolts.
+                of scale and offset are millivolts.
 
 What:           /sys/bus/iio/devices/iio:deviceX/in_capacitanceY_raw
 KernelVersion:  3.2
@@ -537,6 +537,62 @@ Description:
                 value is in raw device units or in processed units (as _raw
                 and _input do on sysfs direct channel read attributes).
 
+What:           /sys/.../events/in_accel_x_thresh_rising_hysteresis
+What:           /sys/.../events/in_accel_x_thresh_falling_hysteresis
+What:           /sys/.../events/in_accel_x_thresh_either_hysteresis
+What:           /sys/.../events/in_accel_y_thresh_rising_hysteresis
+What:           /sys/.../events/in_accel_y_thresh_falling_hysteresis
+What:           /sys/.../events/in_accel_y_thresh_either_hysteresis
+What:           /sys/.../events/in_accel_z_thresh_rising_hysteresis
+What:           /sys/.../events/in_accel_z_thresh_falling_hysteresis
+What:           /sys/.../events/in_accel_z_thresh_either_hysteresis
+What:           /sys/.../events/in_anglvel_x_thresh_rising_hysteresis
+What:           /sys/.../events/in_anglvel_x_thresh_falling_hysteresis
+What:           /sys/.../events/in_anglvel_x_thresh_either_hysteresis
+What:           /sys/.../events/in_anglvel_y_thresh_rising_hysteresis
+What:           /sys/.../events/in_anglvel_y_thresh_falling_hysteresis
+What:           /sys/.../events/in_anglvel_y_thresh_either_hysteresis
+What:           /sys/.../events/in_anglvel_z_thresh_rising_hysteresis
+What:           /sys/.../events/in_anglvel_z_thresh_falling_hysteresis
+What:           /sys/.../events/in_anglvel_z_thresh_either_hysteresis
+What:           /sys/.../events/in_magn_x_thresh_rising_hysteresis
+What:           /sys/.../events/in_magn_x_thresh_falling_hysteresis
+What:           /sys/.../events/in_magn_x_thresh_either_hysteresis
+What:           /sys/.../events/in_magn_y_thresh_rising_hysteresis
+What:           /sys/.../events/in_magn_y_thresh_falling_hysteresis
+What:           /sys/.../events/in_magn_y_thresh_either_hysteresis
+What:           /sys/.../events/in_magn_z_thresh_rising_hysteresis
+What:           /sys/.../events/in_magn_z_thresh_falling_hysteresis
+What:           /sys/.../events/in_magn_z_thresh_either_hysteresis
+What:           /sys/.../events/in_voltageY_thresh_rising_hysteresis
+What:           /sys/.../events/in_voltageY_thresh_falling_hysteresis
+What:           /sys/.../events/in_voltageY_thresh_either_hysteresis
+What:           /sys/.../events/in_tempY_thresh_rising_hysteresis
+What:           /sys/.../events/in_tempY_thresh_falling_hysteresis
+What:           /sys/.../events/in_tempY_thresh_either_hysteresis
+What:           /sys/.../events/in_illuminance0_thresh_falling_hysteresis
+what:           /sys/.../events/in_illuminance0_thresh_rising_hysteresis
+what:           /sys/.../events/in_illuminance0_thresh_either_hysteresis
+what:           /sys/.../events/in_proximity0_thresh_falling_hysteresis
+what:           /sys/.../events/in_proximity0_thresh_rising_hysteresis
+what:           /sys/.../events/in_proximity0_thresh_either_hysteresis
+KernelVersion:  3.13
+Contact:        linux-iio@vger.kernel.org
+Description:
+                Specifies the hysteresis of threshold that the device is comparing
+                against for the events enabled by
+                <type>Y[_name]_thresh[_(rising|falling)]_hysteresis.
+                If separate attributes exist for the two directions, but
+                direction is not specified for this attribute, then a single
+                hysteresis value applies to both directions.
+                For falling events the hysteresis is added to the _value attribute for
+                this event to get the upper threshold for when the event goes back to
+                normal, for rising events the hysteresis is subtracted from the _value
+                attribute. E.g. if in_voltage0_raw_thresh_rising_value is set to 1200
+                and in_voltage0_raw_thresh_rising_hysteresis is set to 50. The event
+                will get activated once in_voltage0_raw goes above 1200 and will become
+                deactived again once the value falls below 1150.
+
 What:           /sys/.../events/in_accel_x_raw_roc_rising_value
 What:           /sys/.../events/in_accel_x_raw_roc_falling_value
 What:           /sys/.../events/in_accel_y_raw_roc_rising_value
@@ -811,3 +867,14 @@ Description:
                 Writing '1' stores the current device configuration into
                 on-chip EEPROM. After power-up or chip reset the device will
                 automatically load the saved configuration.
+
+What:           /sys/.../iio:deviceX/in_intensity_red_integration_time
+What:           /sys/.../iio:deviceX/in_intensity_green_integration_time
+What:           /sys/.../iio:deviceX/in_intensity_blue_integration_time
+What:           /sys/.../iio:deviceX/in_intensity_clear_integration_time
+What:           /sys/.../iio:deviceX/in_illuminance_integration_time
+KernelVersion:  3.12
+Contact:        linux-iio@vger.kernel.org
+Description:
+                This attribute is used to get/set the integration time in
+                seconds.
diff --git a/Documentation/ABI/testing/sysfs-class-mic.txt b/Documentation/ABI/testing/sysfs-class-mic.txt
new file mode 100644
index 000000000000..13f48afc534f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-mic.txt
@@ -0,0 +1,157 @@
+What:           /sys/class/mic/
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                The mic class directory belongs to Intel MIC devices and
+                provides information per MIC device. An Intel MIC device is a
+                PCIe form factor add-in Coprocessor card based on the Intel Many
+                Integrated Core (MIC) architecture that runs a Linux OS.
+
+What:           /sys/class/mic/mic(x)
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                The directories /sys/class/mic/mic0, /sys/class/mic/mic1 etc.,
+                represent MIC devices (0,1,..etc). Each directory has
+                information specific to that MIC device.
+
+What:           /sys/class/mic/mic(x)/family
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                Provides information about the Coprocessor family for an Intel
+                MIC device. For example - "x100"
+
+What:           /sys/class/mic/mic(x)/stepping
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                Provides information about the silicon stepping for an Intel
+                MIC device. For example - "A0" or "B0"
+
+What:           /sys/class/mic/mic(x)/state
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                When read, this entry provides the current state of an Intel
+                MIC device in the context of the card OS. Possible values that
+                will be read are:
+                "offline" - The MIC device is ready to boot the card OS. On
+                reading this entry after an OSPM resume, a "boot" has to be
+                written to this entry if the card was previously shutdown
+                during OSPM suspend.
+                "online" - The MIC device has initiated booting a card OS.
+                "shutting_down" - The card OS is shutting down.
+                "reset_failed" - The MIC device has failed to reset.
+                "suspending" - The MIC device is currently being prepared for
+                suspend. On reading this entry, a "suspend" has to be written
+                to the state sysfs entry to ensure the card is shutdown during
+                OSPM suspend.
+                "suspended" - The MIC device has been suspended.
+
+                When written, this sysfs entry triggers different state change
+                operations depending upon the current state of the card OS.
+                Acceptable values are:
+                "boot" - Boot the card OS image specified by the combination
+                         of firmware, ramdisk, cmdline and bootmode
+                        sysfs entries.
+                "reset" - Initiates device reset.
+                "shutdown" - Initiates card OS shutdown.
+                "suspend" - Initiates card OS shutdown and also marks the card
+                as suspended.
+
+What:           /sys/class/mic/mic(x)/shutdown_status
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                An Intel MIC device runs a Linux OS during its operation. This
+                OS can shutdown because of various reasons. When read, this
+                entry provides the status on why the card OS was shutdown.
+                Possible values are:
+                "nop" -  shutdown status is not applicable, when the card OS is
+                        "online"
+                "crashed" - Shutdown because of a HW or SW crash.
+                "halted" - Shutdown because of a halt command.
+                "poweroff" - Shutdown because of a poweroff command.
+                "restart" - Shutdown because of a restart command.
+
+What:           /sys/class/mic/mic(x)/cmdline
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                An Intel MIC device runs a Linux OS during its operation. Before
+                booting this card OS, it is possible to pass kernel command line
+                options to configure various features in it, similar to
+                self-bootable machines. When read, this entry provides
+                information about the current kernel command line options set to
+                boot the card OS. This entry can be written to change the
+                existing kernel command line options. Typically, the user would
+                want to read the current command line options, append new ones
+                or modify existing ones and then write the whole kernel command
+                line back to this entry.
+
+What:           /sys/class/mic/mic(x)/firmware
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                When read, this sysfs entry provides the path name under
+                /lib/firmware/ where the firmware image to be booted on the
+                card can be found. The entry can be written to change the
+                firmware image location under /lib/firmware/.
+
+What:           /sys/class/mic/mic(x)/ramdisk
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                When read, this sysfs entry provides the path name under
+                /lib/firmware/ where the ramdisk image to be used during card
+                OS boot can be found. The entry can be written to change
+                the ramdisk image location under /lib/firmware/.
+
+What:           /sys/class/mic/mic(x)/bootmode
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                When read, this sysfs entry provides the current bootmode for
+                the card. This sysfs entry can be written with the following
+                valid strings:
+                a) linux - Boot a Linux image.
+                b) elf - Boot an elf image for flash updates.
+
+What:           /sys/class/mic/mic(x)/log_buf_addr
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                An Intel MIC device runs a Linux OS during its operation. For
+                debugging purpose and early kernel boot messages, the user can
+                access the card OS log buffer via debugfs. When read, this entry
+                provides the kernel virtual address of the buffer where the card
+                OS log buffer can be read. This entry is written by the host
+                configuration daemon to set the log buffer address. The correct
+                log buffer address to be written can be found in the System.map
+                file of the card OS.
+
+What:           /sys/class/mic/mic(x)/log_buf_len
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        Sudeep Dutt <sudeep.dutt@intel.com>
+Description:
+                An Intel MIC device runs a Linux OS during its operation. For
+                debugging purpose and early kernel boot messages, the user can
+                access the card OS log buffer via debugfs. When read, this entry
+                provides the kernel virtual address where the card OS log buffer
+                length can be read. This entry is written by host configuration
+                daemon to set the log buffer length address. The correct log
+                buffer length address to be written can be found in the
+                System.map file of the card OS.
diff --git a/Documentation/ABI/testing/sysfs-class-mtd b/Documentation/ABI/testing/sysfs-class-mtd
index bfd119ace6ad..1399bb2da3eb 100644
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -104,7 +104,7 @@ Description:
                 One of the following ASCII strings, representing the device
                 type:
 
-                absent, ram, rom, nor, nand, dataflash, ubi, unknown
+                absent, ram, rom, nor, nand, mlc-nand, dataflash, ubi, unknown
 
 What:           /sys/class/mtd/mtdX/writesize
 Date:           April 2009
diff --git a/Documentation/ABI/testing/sysfs-class-net-batman-adv b/Documentation/ABI/testing/sysfs-class-net-batman-adv
index bdc00707c751..7f34a95bb963 100644
--- a/Documentation/ABI/testing/sysfs-class-net-batman-adv
+++ b/Documentation/ABI/testing/sysfs-class-net-batman-adv
@@ -1,13 +1,13 @@
 
 What:           /sys/class/net/<iface>/batman-adv/iface_status
 Date:           May 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Indicates the status of <iface> as it is seen by batman.
 
 What:           /sys/class/net/<iface>/batman-adv/mesh_iface
 Date:           May 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 The /sys/class/net/<iface>/batman-adv/mesh_iface file
                 displays the batman mesh interface this <iface>
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index bdcd8b4e38f2..0baa657b18c4 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -1,22 +1,23 @@
 
 What:           /sys/class/net/<mesh_iface>/mesh/aggregated_ogms
 Date:           May 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Indicates whether the batman protocol messages of the
                 mesh <mesh_iface> shall be aggregated or not.
 
-What:           /sys/class/net/<mesh_iface>/mesh/ap_isolation
+What:           /sys/class/net/<mesh_iface>/mesh/<vlan_subdir>/ap_isolation
 Date:           May 2011
-Contact:        Antonio Quartulli <ordex@autistici.org>
+Contact:        Antonio Quartulli <antonio@meshcoding.com>
 Description:
                 Indicates whether the data traffic going from a
                 wireless client to another wireless client will be
-                silently dropped.
+                silently dropped. <vlan_subdir> is empty when referring
+                to the untagged lan.
 
 What:           /sys/class/net/<mesh_iface>/mesh/bonding
 Date:           June 2010
-Contact:        Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
+Contact:        Simon Wunderlich <sw@simonwunderlich.de>
 Description:
                 Indicates whether the data traffic going through the
                 mesh will be sent using multiple interfaces at the
@@ -24,7 +25,7 @@ Description:
 
 What:           /sys/class/net/<mesh_iface>/mesh/bridge_loop_avoidance
 Date:           November 2011
-Contact:        Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
+Contact:        Simon Wunderlich <sw@simonwunderlich.de>
 Description:
                 Indicates whether the bridge loop avoidance feature
                 is enabled. This feature detects and avoids loops
@@ -41,21 +42,21 @@ Description:
 
 What:           /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
 Date:           October 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Defines the bandwidth which is propagated by this
                 node if gw_mode was set to 'server'.
 
 What:           /sys/class/net/<mesh_iface>/mesh/gw_mode
 Date:           October 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Defines the state of the gateway features. Can be
                 either 'off', 'client' or 'server'.
 
 What:           /sys/class/net/<mesh_iface>/mesh/gw_sel_class
 Date:           October 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Defines the selection criteria this node will use
                 to choose a gateway if gw_mode was set to 'client'.
@@ -77,25 +78,14 @@ Description:
 
 What:           /sys/class/net/<mesh_iface>/mesh/orig_interval
 Date:           May 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Defines the interval in milliseconds in which batman
                 sends its protocol messages.
 
 What:           /sys/class/net/<mesh_iface>/mesh/routing_algo
 Date:           Dec 2011
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
+Contact:        Marek Lindner <mareklindner@neomailbox.ch>
 Description:
                 Defines the routing procotol this mesh instance
                 uses to find the optimal paths through the mesh.
-
-What:           /sys/class/net/<mesh_iface>/mesh/vis_mode
-Date:           May 2010
-Contact:        Marek Lindner <lindner_marek@yahoo.de>
-Description:
-                Each batman node only maintains information about its
-                own local neighborhood, therefore generating graphs
-                showing the topology of the entire mesh is not easily
-                feasible without having a central instance to collect
-                the local topologies from all nodes. This file allows
-                to activate the collecting (server) mode.
diff --git a/Documentation/ABI/testing/sysfs-class-powercap b/Documentation/ABI/testing/sysfs-class-powercap
new file mode 100644
index 000000000000..db3b3ff70d84
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-powercap
@@ -0,0 +1,152 @@
+What:           /sys/class/powercap/
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                The powercap/ class sub directory belongs to the power cap
+                subsystem. Refer to
+                Documentation/power/powercap/powercap.txt for details.
+
+What:           /sys/class/powercap/<control type>
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                A <control type> is a unique name under /sys/class/powercap.
+                Here <control type> determines how the power is going to be
+                controlled. A <control type> can contain multiple power zones.
+
+What:           /sys/class/powercap/<control type>/enabled
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                This allows to enable/disable power capping for a "control type".
+                This status affects every power zone using this "control_type.
+
+What:           /sys/class/powercap/<control type>/<power zone>
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                A power zone is a single or a collection of devices, which can
+                be independently monitored and controlled. A power zone sysfs
+                entry is qualified with the name of the <control type>.
+                E.g. intel-rapl:0:1:1.
+
+What:           /sys/class/powercap/<control type>/<power zone>/<child power zone>
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Power zones may be organized in a hierarchy in which child
+                power zones provide monitoring and control for a subset of
+                devices under the parent. For example, if there is a parent
+                power zone for a whole CPU package, each CPU core in it can
+                be a child power zone.
+
+What:           /sys/class/powercap/.../<power zone>/name
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Specifies the name of this power zone.
+
+What:           /sys/class/powercap/.../<power zone>/energy_uj
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Current energy counter in micro-joules. Write "0" to reset.
+                If the counter can not be reset, then this attribute is
+                read-only.
+
+What:           /sys/class/powercap/.../<power zone>/max_energy_range_uj
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Range of the above energy counter in micro-joules.
+
+
+What:           /sys/class/powercap/.../<power zone>/power_uw
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Current power in micro-watts.
+
+What:           /sys/class/powercap/.../<power zone>/max_power_range_uw
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Range of the above power value in micro-watts.
+
+What:           /sys/class/powercap/.../<power zone>/constraint_X_name
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Each power zone can define one or more constraints. Each
+                constraint can have an optional name. Here "X" can have values
+                from 0 to max integer.
+
+What:           /sys/class/powercap/.../<power zone>/constraint_X_power_limit_uw
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Power limit in micro-watts should be applicable for
+                the time window specified by "constraint_X_time_window_us".
+                Here "X" can have values from 0 to max integer.
+
+What:           /sys/class/powercap/.../<power zone>/constraint_X_time_window_us
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Time window in micro seconds. This is used along with
+                constraint_X_power_limit_uw to define a power constraint.
+                Here "X" can have values from 0 to max integer.
+
+
+What:           /sys/class/powercap/<control type>/.../constraint_X_max_power_uw
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Maximum allowed power in micro watts for this constraint.
+                Here "X" can have values from 0 to max integer.
+
+What:           /sys/class/powercap/<control type>/.../constraint_X_min_power_uw
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Minimum allowed power in micro watts for this constraint.
+                Here "X" can have values from 0 to max integer.
+
+What:           /sys/class/powercap/.../<power zone>/constraint_X_max_time_window_us
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Maximum allowed time window in micro seconds for this
+                constraint. Here "X" can have values from 0 to max integer.
+
+What:           /sys/class/powercap/.../<power zone>/constraint_X_min_time_window_us
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description:
+                Minimum allowed time window in micro seconds for this
+                constraint. Here "X" can have values from 0 to max integer.
+
+What:           /sys/class/powercap/.../<power zone>/enabled
+Date:           September 2013
+KernelVersion:  3.13
+Contact:        linux-pm@vger.kernel.org
+Description
+                This allows to enable/disable power capping at power zone level.
+                This applies to current power zone and its children.
diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power
index 9d43e7670841..efe449bdf811 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -1,6 +1,6 @@
 What:           /sys/devices/.../power/
 Date:           January 2009
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../power directory contains attributes
                 allowing the user space to check and modify some power
@@ -8,7 +8,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup
 Date:           January 2009
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../power/wakeup attribute allows the user
                 space to check if the device is enabled to wake up the system
@@ -34,7 +34,7 @@ Description:
 
 What:           /sys/devices/.../power/control
 Date:           January 2009
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../power/control attribute allows the user
                 space to control the run-time power management of the device.
@@ -53,7 +53,7 @@ Description:
 
 What:           /sys/devices/.../power/async
 Date:           January 2009
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../async attribute allows the user space to
                 enable or diasble the device's suspend and resume callbacks to
@@ -79,7 +79,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_count
 Date:           September 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_count attribute contains the number
                 of signaled wakeup events associated with the device.  This
@@ -88,7 +88,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_active_count
 Date:           September 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_active_count attribute contains the
                 number of times the processing of wakeup events associated with
@@ -98,7 +98,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_abort_count
 Date:           February 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_abort_count attribute contains the
                 number of times the processing of a wakeup event associated with
@@ -109,7 +109,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_expire_count
 Date:           February 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_expire_count attribute contains the
                 number of times a wakeup event associated with the device has
@@ -119,7 +119,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_active
 Date:           September 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_active attribute contains either 1,
                 or 0, depending on whether or not a wakeup event associated with
@@ -129,7 +129,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_total_time_ms
 Date:           September 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_total_time_ms attribute contains
                 the total time of processing wakeup events associated with the
@@ -139,7 +139,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_max_time_ms
 Date:           September 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_max_time_ms attribute contains
                 the maximum time of processing a single wakeup event associated
@@ -149,7 +149,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_last_time_ms
 Date:           September 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_last_time_ms attribute contains
                 the value of the monotonic clock corresponding to the time of
@@ -160,7 +160,7 @@ Description:
 
 What:           /sys/devices/.../power/wakeup_prevent_sleep_time_ms
 Date:           February 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
                 contains the total time the device has been preventing
@@ -189,7 +189,7 @@ Description:
 
 What:           /sys/devices/.../power/pm_qos_latency_us
 Date:           March 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../power/pm_qos_resume_latency_us attribute
                 contains the PM QoS resume latency limit for the given device,
@@ -207,7 +207,7 @@ Description:
 
 What:           /sys/devices/.../power/pm_qos_no_power_off
 Date:           September 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../power/pm_qos_no_power_off attribute
                 is used for manipulating the PM QoS "no power off" flag.  If
@@ -222,7 +222,7 @@ Description:
 
 What:           /sys/devices/.../power/pm_qos_remote_wakeup
 Date:           September 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/devices/.../power/pm_qos_remote_wakeup attribute
                 is used for manipulating the PM QoS "remote wakeup required"
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos b/Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos
new file mode 100644
index 000000000000..1d6a8cf9dc0a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos
@@ -0,0 +1,178 @@
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/control
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one select which data from which
+                profile will be read next. The data has to be 3 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/profile
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    The mouse can store 5 profiles which can be switched by the
+                press of a button. profile holds index of actual profile.
+                This value is persistent, so its value determines the profile
+                that's active when the device is powered on next time.
+                When written, the device activates the set profile immediately.
+                The data has to be 3 bytes long.
+                The device will reject invalid data.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_primary
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the default of all keys for
+                a specific profile. Profile index is included in written data.
+                The data has to be 125 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_function
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the function of the
+                function keys for a specific profile. Profile index is included
+                in written data. The data has to be 95 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_macro
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the function of the macro
+                keys for a specific profile. Profile index is included in
+                written data. The data has to be 35 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_thumbster
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the function of the
+                thumbster keys for a specific profile. Profile index is included
+                in written data. The data has to be 23 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_extra
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the function of the
+                capslock and function keys for a specific profile. Profile index
+                is included in written data. The data has to be 8 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/keys_easyzone
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the function of the
+                easyzone keys for a specific profile. Profile index is included
+                in written data. The data has to be 294 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/key_mask
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one deactivate certain keys like
+                windows and application keys, to prevent accidental presses.
+                Profile index for which this settings occur is included in
+                written data. The data has to be 6 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the backlight intensity for
+                a specific profile. Profile index is included in written data.
+                This attribute is only valid for the glow and pro variant.
+                The data has to be 16 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/macro
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one store macros with max 480
+                keystrokes for a specific button for a specific profile.
+                Button and profile indexes are included in written data.
+                The data has to be 2002 bytes long.
+                Before reading this file, control has to be written to select
+                which profile and key to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/info
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When read, this file returns general data like firmware version.
+                The data is 8 bytes long.
+                This file is readonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/reset
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one reset the device.
+                The data has to be 3 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/talk
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one trigger easyshift functionality
+                from the host.
+                The data has to be 16 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_control
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one switch between stored and custom
+                light settings.
+                This attribute is only valid for the pro variant.
+                The data has to be 8 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/stored_lights
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set per-key lighting for different
+                layers.
+                This attribute is only valid for the pro variant.
+                The data has to be 1382 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/custom_lights
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set the actual per-key lighting.
+                This attribute is only valid for the pro variant.
+                The data has to be 20 bytes long.
+                This file is writeonly.
+Users:          http://roccat.sourceforge.net
+
+What:           /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/ryos/roccatryos<minor>/light_macro
+Date:           October 2013
+Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
+Description:    When written, this file lets one set a light macro that is looped
+                whenever the device gets in dimness mode.
+                This attribute is only valid for the pro variant.
+                The data has to be 2002 bytes long.
+                Before reading this file, control has to be written to select
+                which profile to read.
+Users:          http://roccat.sourceforge.net
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
index ed5dd567d397..39dfa5cb1cc5 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-wiimote
+++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
@@ -57,3 +57,21 @@ Description:	This attribute is only provided if the device was detected as a
                 Calibration data is already applied by the kernel to all input
                 values but may be used by user-space to perform other
                 transformations.
+
+What:           /sys/bus/hid/drivers/wiimote/<dev>/pro_calib
+Date:           October 2013
+KernelVersion:  3.13
+Contact:        David Herrmann <dh.herrmann@gmail.com>
+Description:    This attribute is only provided if the device was detected as a
+                pro-controller. It provides a single line with 4 calibration
+                values for all 4 analog sticks. Format is: "x1:y1 x2:y2". Data
+                is prefixed with a +/-. Each value is a signed 16bit number.
+                Data is encoded as decimal numbers and specifies the offsets of
+                the analog sticks of the pro-controller.
+                Calibration data is already applied by the kernel to all input
+                values but may be used by user-space to perform other
+                transformations.
+                Calibration data is detected by the kernel during device setup.
+                You can write "scan\n" into this file to re-trigger calibration.
+                You can also write data directly in the form "x1:y1 x2:y2" to
+                set the calibration values manually.
diff --git a/Documentation/ABI/testing/sysfs-driver-sunxi-sid b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
new file mode 100644
index 000000000000..ffb9536f6ecc
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-sunxi-sid
@@ -0,0 +1,22 @@
+What:           /sys/devices/*/<our-device>/eeprom
+Date:           August 2013
+Contact:        Oliver Schinagl <oliver@schinagl.nl>
+Description:    read-only access to the SID (Security-ID) on current
+                A-series SoC's from Allwinner. Currently supports A10, A10s, A13
+                and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
+                whereas the newer A20 SoC exposes 512 bytes split into sections.
+                Besides the 16 bytes of SID, there's also an SJTAG area,
+                HDMI-HDCP key and some custom keys. Below a quick overview, for
+                details see the user manual:
+                0x000  128 bit root-key (sun[457]i)
+                0x010  128 bit boot-key (sun7i)
+                0x020   64 bit security-jtag-key (sun7i)
+                0x028   16 bit key configuration (sun7i)
+                0x02b   16 bit custom-vendor-key (sun7i)
+                0x02c  320 bit low general key (sun7i)
+                0x040   32 bit read-control access (sun7i)
+                0x064  224 bit low general key (sun7i)
+                0x080 2304 bit HDCP-key (sun7i)
+                0x1a0  768 bit high general key (sun7i)
+Users:          any user space application which wants to read the SID on
+                Allwinner's A-series of CPU's.
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 217772615d02..205a73878441 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -1,6 +1,6 @@
 What:           /sys/power/
 Date:           August 2006
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power directory will contain files that will
                 provide a unified interface to the power management
@@ -8,7 +8,7 @@ Description:
 
 What:           /sys/power/state
 Date:           August 2006
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/state file controls the system power state.
                 Reading from this file returns what states are supported,
@@ -22,7 +22,7 @@ Description:
 
 What:           /sys/power/disk
 Date:           September 2006
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/disk file controls the operating mode of the
                 suspend-to-disk mechanism.  Reading from this file returns
@@ -67,7 +67,7 @@ Description:
 
 What:           /sys/power/image_size
 Date:           August 2006
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/image_size file controls the size of the image
                 created by the suspend-to-disk mechanism.  It can be written a
@@ -84,7 +84,7 @@ Description:
 
 What:           /sys/power/pm_trace
 Date:           August 2006
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/pm_trace file controls the code which saves the
                 last PM event point in the RTC across reboots, so that you can
@@ -133,7 +133,7 @@ Description:
 
 What:           /sys/power/pm_async
 Date:           January 2009
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/pm_async file controls the switch allowing the
                 user space to enable or disable asynchronous suspend and resume
@@ -146,7 +146,7 @@ Description:
 
 What:           /sys/power/wakeup_count
 Date:           July 2010
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/wakeup_count file allows user space to put the
                 system into a sleep state while taking into account the
@@ -161,7 +161,7 @@ Description:
 
 What:           /sys/power/reserved_size
 Date:           May 2011
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/reserved_size file allows user space to control
                 the amount of memory reserved for allocations made by device
@@ -175,7 +175,7 @@ Description:
 
 What:           /sys/power/autosleep
 Date:           April 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/autosleep file can be written one of the strings
                 returned by reads from /sys/power/state.  If that happens, a
@@ -192,7 +192,7 @@ Description:
 
 What:           /sys/power/wake_lock
 Date:           February 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/wake_lock file allows user space to create
                 wakeup source objects and activate them on demand (if one of
@@ -219,7 +219,7 @@ Description:
 
 What:           /sys/power/wake_unlock
 Date:           February 2012
-Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/wake_unlock file allows user space to deactivate
                 wakeup sources created with the help of /sys/power/wake_lock.
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index 14129f149a75..5e983031cc11 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -101,14 +101,23 @@ style to do this even if your device holds the default setting,
 because this shows that you did think about these issues wrt. your
 device.
 
-The query is performed via a call to dma_set_mask():
+The query is performed via a call to dma_set_mask_and_coherent():
 
-        int dma_set_mask(struct device *dev, u64 mask);
+        int dma_set_mask_and_coherent(struct device *dev, u64 mask);
 
-The query for consistent allocations is performed via a call to
-dma_set_coherent_mask():
+which will query the mask for both streaming and coherent APIs together.
+If you have some special requirements, then the following two separate
+queries can be used instead:
 
-        int dma_set_coherent_mask(struct device *dev, u64 mask);
+        The query for streaming mappings is performed via a call to
+        dma_set_mask():
+
+                int dma_set_mask(struct device *dev, u64 mask);
+
+        The query for consistent allocations is performed via a call
+        to dma_set_coherent_mask():
+
+                int dma_set_coherent_mask(struct device *dev, u64 mask);
 
 Here, dev is a pointer to the device struct of your device, and mask
 is a bit mask describing which bits of an address your device
@@ -137,7 +146,7 @@ exactly why.
 
 The standard 32-bit addressing device would do something like this:
 
-        if (dma_set_mask(dev, DMA_BIT_MASK(32))) {
+        if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
                 printk(KERN_WARNING
                        "mydev: No suitable DMA available.\n");
                 goto ignore_this_device;
@@ -171,22 +180,20 @@ the case would look like this:
 
         int using_dac, consistent_using_dac;
 
-        if (!dma_set_mask(dev, DMA_BIT_MASK(64))) {
+        if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
                 using_dac = 1;
                 consistent_using_dac = 1;
-                dma_set_coherent_mask(dev, DMA_BIT_MASK(64));
-        } else if (!dma_set_mask(dev, DMA_BIT_MASK(32))) {
+        } else if (!dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))) {
                 using_dac = 0;
                 consistent_using_dac = 0;
-                dma_set_coherent_mask(dev, DMA_BIT_MASK(32));
         } else {
                 printk(KERN_WARNING
                        "mydev: No suitable DMA available.\n");
                 goto ignore_this_device;
         }
 
-dma_set_coherent_mask() will always be able to set the same or a
-smaller mask as dma_set_mask(). However for the rare case that a
+The coherent coherent mask will always be able to set the same or a
+smaller mask as the streaming mask. However for the rare case that a
 device driver only uses consistent allocations, one would have to
 check the return value from dma_set_coherent_mask().
 
@@ -199,9 +206,9 @@ address you might do something like:
                 goto ignore_this_device;
         }
 
-When dma_set_mask() is successful, and returns zero, the kernel saves
-away this mask you have provided.  The kernel will use this
-information later when you make DMA mappings.
+When dma_set_mask() or dma_set_mask_and_coherent() is successful, and
+returns zero, the kernel saves away this mask you have provided.  The
+kernel will use this information later when you make DMA mappings.
 
 There is a case which we are aware of at this time, which is worth
 mentioning in this documentation.  If your device supports multiple
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 78a6c569d204..e865279cec58 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -142,6 +142,14 @@ internal API for use by the platform than an external API for use by
 driver writers.
 
 int
+dma_set_mask_and_coherent(struct device *dev, u64 mask)
+
+Checks to see if the mask is possible and updates the device
+streaming and coherent DMA mask parameters if it is.
+
+Returns: 0 if successful and a negative error if not.
+
+int
 dma_set_mask(struct device *dev, u64 mask)
 
 Checks to see if the mask is possible and updates the device
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index e59480db9ee0..cc2450d80310 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -13,7 +13,7 @@ all pending DMA writes to complete, and thus provides a mechanism to
 strictly order DMA from a device across all intervening busses and
 bridges.  This barrier is not specific to a particular type of
 interconnect, it applies to the system as a whole, and so its
-implementation must account for the idiosyncracies of the system all
+implementation must account for the idiosyncrasies of the system all
 the way from the DMA device to memory.
 
 As an example of a situation where DMA_ATTR_WRITE_BARRIER would be
@@ -60,7 +60,7 @@ such mapping is non-trivial task and consumes very limited resources
 Buffers allocated with this attribute can be only passed to user space
 by calling dma_mmap_attrs(). By using this API, you are guaranteeing
 that you won't dereference the pointer returned by dma_alloc_attr(). You
-can threat it as a cookie that must be passed to dma_mmap_attrs() and
+can treat it as a cookie that must be passed to dma_mmap_attrs() and
 dma_free_attrs(). Make sure that both of these also get this attribute
 set on each call.
 
@@ -82,7 +82,7 @@ to 'device' domain, what synchronizes CPU caches for the given region
 (usually it means that the cache has been flushed or invalidated
 depending on the dma direction). However, next calls to
 dma_map_{single,page,sg}() for other devices will perform exactly the
-same sychronization operation on the CPU cache. CPU cache sychronization
+same synchronization operation on the CPU cache. CPU cache synchronization
 might be a time consuming operation, especially if the buffers are
 large, so it is highly recommended to avoid it if possible.
 DMA_ATTR_SKIP_CPU_SYNC allows platform code to skip synchronization of
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index f403ec3c5c9a..46ad6faee9ab 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -152,8 +152,8 @@
 !Finclude/net/cfg80211.h cfg80211_scan_request
 !Finclude/net/cfg80211.h cfg80211_scan_done
 !Finclude/net/cfg80211.h cfg80211_bss
-!Finclude/net/cfg80211.h cfg80211_inform_bss_frame
-!Finclude/net/cfg80211.h cfg80211_inform_bss
+!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame
+!Finclude/net/cfg80211.h cfg80211_inform_bss_width
 !Finclude/net/cfg80211.h cfg80211_unlink_bss
 !Finclude/net/cfg80211.h cfg80211_find_ie
 !Finclude/net/cfg80211.h ieee80211_bss_get_ie
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index fe397f90a34f..6c9d9d37c83a 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -87,7 +87,10 @@ X!Iinclude/linux/kobject.h
 !Ekernel/printk/printk.c
 !Ekernel/panic.c
 !Ekernel/sys.c
-!Ekernel/rcupdate.c
+!Ekernel/rcu/srcu.c
+!Ekernel/rcu/tree.c
+!Ekernel/rcu/tree_plugin.h
+!Ekernel/rcu/update.c
      </sect1>
 
      <sect1><title>Device Resource Management</title>
diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl
index 25b58efd955d..4f676838da06 100644
--- a/Documentation/DocBook/filesystems.tmpl
+++ b/Documentation/DocBook/filesystems.tmpl
@@ -91,7 +91,6 @@
      <title>The Filesystem for Exporting Kernel Objects</title>
 !Efs/sysfs/file.c
 !Efs/sysfs/symlink.c
-!Efs/sysfs/bin.c
   </chapter>
 
   <chapter id="debugfs">
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl
index d16d21b7a3b7..46347f603353 100644
--- a/Documentation/DocBook/genericirq.tmpl
+++ b/Documentation/DocBook/genericirq.tmpl
@@ -87,7 +87,7 @@
   <chapter id="rationale">
     <title>Rationale</title>
         <para>
-        The original implementation of interrupt handling in Linux is using
+        The original implementation of interrupt handling in Linux uses
         the __do_IRQ() super-handler, which is able to deal with every
         type of interrupt logic.
         </para>
@@ -111,19 +111,19 @@
         </itemizedlist>
         </para>
         <para>
-        This split implementation of highlevel IRQ handlers allows us to
+        This split implementation of high-level IRQ handlers allows us to
         optimize the flow of the interrupt handling for each specific
-        interrupt type. This reduces complexity in that particular codepath
+        interrupt type. This reduces complexity in that particular code path
         and allows the optimized handling of a given type.
         </para>
         <para>
         The original general IRQ implementation used hw_interrupt_type
         structures and their ->ack(), ->end() [etc.] callbacks to
         differentiate the flow control in the super-handler. This leads to
-        a mix of flow logic and lowlevel hardware logic, and it also leads
-        to unnecessary code duplication: for example in i386, there is a
-        ioapic_level_irq and a ioapic_edge_irq irq-type which share many
-        of the lowlevel details but have different flow handling.
+        a mix of flow logic and low-level hardware logic, and it also leads
+        to unnecessary code duplication: for example in i386, there is an
+        ioapic_level_irq and an ioapic_edge_irq IRQ-type which share many
+        of the low-level details but have different flow handling.
         </para>
         <para>
         A more natural abstraction is the clean separation of the
@@ -132,23 +132,23 @@
         <para>
         Analysing a couple of architecture's IRQ subsystem implementations
         reveals that most of them can use a generic set of 'irq flow'
-        methods and only need to add the chip level specific code.
+        methods and only need to add the chip-level specific code.
         The separation is also valuable for (sub)architectures
-        which need specific quirks in the irq flow itself but not in the
-        chip-details - and thus provides a more transparent IRQ subsystem
+        which need specific quirks in the IRQ flow itself but not in the
+        chip details - and thus provides a more transparent IRQ subsystem
         design.
         </para>
         <para>
-        Each interrupt descriptor is assigned its own highlevel flow
+        Each interrupt descriptor is assigned its own high-level flow
         handler, which is normally one of the generic
-        implementations. (This highlevel flow handler implementation also
+        implementations. (This high-level flow handler implementation also
         makes it simple to provide demultiplexing handlers which can be
         found in embedded platforms on various architectures.)
         </para>
         <para>
         The separation makes the generic interrupt handling layer more
         flexible and extensible. For example, an (sub)architecture can
-        use a generic irq-flow implementation for 'level type' interrupts
+        use a generic IRQ-flow implementation for 'level type' interrupts
         and add a (sub)architecture specific 'edge type' implementation.
         </para>
         <para>
@@ -172,9 +172,9 @@
     <para>
         There are three main levels of abstraction in the interrupt code:
         <orderedlist>
-          <listitem><para>Highlevel driver API</para></listitem>
-          <listitem><para>Highlevel IRQ flow handlers</para></listitem>
-          <listitem><para>Chiplevel hardware encapsulation</para></listitem>
+          <listitem><para>High-level driver API</para></listitem>
+          <listitem><para>High-level IRQ flow handlers</para></listitem>
+          <listitem><para>Chip-level hardware encapsulation</para></listitem>
         </orderedlist>
     </para>
     <sect1 id="Interrupt_control_flow">
@@ -189,16 +189,16 @@
         which are assigned to this interrupt.
         </para>
         <para>
-        Whenever an interrupt triggers, the lowlevel arch code calls into
-        the generic interrupt code by calling desc->handle_irq().
-        This highlevel IRQ handling function only uses desc->irq_data.chip
+        Whenever an interrupt triggers, the low-level architecture code calls
+        into the generic interrupt code by calling desc->handle_irq().
+        This high-level IRQ handling function only uses desc->irq_data.chip
         primitives referenced by the assigned chip descriptor structure.
         </para>
     </sect1>
     <sect1 id="Highlevel_Driver_API">
-        <title>Highlevel Driver API</title>
+        <title>High-level Driver API</title>
         <para>
-          The highlevel Driver API consists of following functions:
+          The high-level Driver API consists of following functions:
           <itemizedlist>
           <listitem><para>request_irq()</para></listitem>
           <listitem><para>free_irq()</para></listitem>
@@ -216,7 +216,7 @@
         </para>
     </sect1>
     <sect1 id="Highlevel_IRQ_flow_handlers">
-        <title>Highlevel IRQ flow handlers</title>
+        <title>High-level IRQ flow handlers</title>
         <para>
           The generic layer provides a set of pre-defined irq-flow methods:
           <itemizedlist>
@@ -228,7 +228,7 @@
           <listitem><para>handle_edge_eoi_irq</para></listitem>
           <listitem><para>handle_bad_irq</para></listitem>
           </itemizedlist>
-          The interrupt flow handlers (either predefined or architecture
+          The interrupt flow handlers (either pre-defined or architecture
           specific) are assigned to specific interrupts by the architecture
           either during bootup or during device initialization.
         </para>
@@ -297,7 +297,7 @@ desc->irq_data.chip->irq_unmask();
                 <para>
                 handle_fasteoi_irq provides a generic implementation
                 for interrupts, which only need an EOI at the end of
-                the handler
+                the handler.
                 </para>
                 <para>
                 The following control flow is implemented (simplified excerpt):
@@ -394,7 +394,7 @@ if (desc->irq_data.chip->irq_eoi)
         The generic functions are intended for 'clean' architectures and chips,
         which have no platform-specific IRQ handling quirks. If an architecture
         needs to implement quirks on the 'flow' level then it can do so by
-        overriding the highlevel irq-flow handler.
+        overriding the high-level irq-flow handler.
         </para>
         </sect2>
         <sect2 id="Delayed_interrupt_disable">
@@ -419,9 +419,9 @@ if (desc->irq_data.chip->irq_eoi)
         </sect2>
     </sect1>
     <sect1 id="Chiplevel_hardware_encapsulation">
-        <title>Chiplevel hardware encapsulation</title>
+        <title>Chip-level hardware encapsulation</title>
         <para>
-        The chip level hardware descriptor structure irq_chip
+        The chip-level hardware descriptor structure irq_chip
         contains all the direct chip relevant functions, which
         can be utilized by the irq flow implementations.
           <itemizedlist>
@@ -429,14 +429,14 @@ if (desc->irq_data.chip->irq_eoi)
           <listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
           <listitem><para>irq_mask()</para></listitem>
           <listitem><para>irq_unmask()</para></listitem>
-          <listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
+          <listitem><para>irq_eoi() - Optional, required for EOI flow handlers</para></listitem>
           <listitem><para>irq_retrigger() - Optional</para></listitem>
           <listitem><para>irq_set_type() - Optional</para></listitem>
           <listitem><para>irq_set_wake() - Optional</para></listitem>
           </itemizedlist>
         These primitives are strictly intended to mean what they say: ack means
         ACK, masking means masking of an IRQ line, etc. It is up to the flow
-        handler(s) to use these basic units of lowlevel functionality.
+        handler(s) to use these basic units of low-level functionality.
         </para>
     </sect1>
   </chapter>
@@ -445,7 +445,7 @@ if (desc->irq_data.chip->irq_eoi)
      <title>__do_IRQ entry point</title>
      <para>
         The original implementation __do_IRQ() was an alternative entry
-        point for all types of interrupts. It not longer exists.
+        point for all types of interrupts. It no longer exists.
      </para>
      <para>
         This handler turned out to be not suitable for all
@@ -468,11 +468,11 @@ if (desc->irq_data.chip->irq_eoi)
   <chapter id="genericchip">
      <title>Generic interrupt chip</title>
      <para>
-       To avoid copies of identical implementations of irq chips the
+       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.
+       functionality slightly differently themselves.
      </para>
 !Ekernel/irq/generic-chip.c
   </chapter>
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index 09e884e5b9f5..19f2a5a5a5b4 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1958,7 +1958,7 @@ machines due to caching.
   <chapter id="apiref-mutex">
    <title>Mutex API reference</title>
 !Iinclude/linux/mutex.h
-!Ekernel/mutex.c
+!Ekernel/locking/mutex.c
   </chapter>
 
   <chapter id="apiref-futex">
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index a248f42a121e..cd11926e07c7 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -1222,8 +1222,6 @@ in this page</entry>
 #define NAND_BBT_VERSION        0x00000100
 /* Create a bbt if none axists */
 #define NAND_BBT_CREATE         0x00000200
-/* Search good / bad pattern through all pages of a block */
-#define NAND_BBT_SCANALLPAGES   0x00000400
 /* Write bbt if neccecary */
 #define NAND_BBT_WRITE          0x00001000
 /* Read and write back block contents when writing bbt */
diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt
index bccf602a87f5..6f458564d625 100644
--- a/Documentation/PCI/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -525,8 +525,9 @@ corresponding register block for you.
 6. Other interesting functions
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-pci_find_slot()                 Find pci_dev corresponding to given bus and
-                                slot numbers.
+pci_get_domain_bus_and_slot()   Find pci_dev corresponding to given domain,
+                                bus and slot and number. If the device is
+                                found, its reference count is increased.
 pci_set_power_state()           Set PCI Power Management state (0=D0 ... 3=D3)
 pci_find_capability()           Find specified capability in device's capability
                                 list.
@@ -582,7 +583,8 @@ having sane locking.
 
 pci_find_device()       Superseded by pci_get_device()
 pci_find_subsys()       Superseded by pci_get_subsys()
-pci_find_slot()         Superseded by pci_get_slot()
+pci_find_slot()         Superseded by pci_get_domain_bus_and_slot()
+pci_get_slot()          Superseded by pci_get_domain_bus_and_slot()
 
 
 The alternative is the traditional PCI device driver that walks PCI
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 7703ec73a9bb..91266193b8f4 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -202,8 +202,8 @@ over a rather long period of time, but improvements are always welcome!
         updater uses call_rcu_sched() or synchronize_sched(), then
         the corresponding readers must disable preemption, possibly
         by calling rcu_read_lock_sched() and rcu_read_unlock_sched().
-        If the updater uses synchronize_srcu() or call_srcu(),
-        the the corresponding readers must use srcu_read_lock() and
+        If the updater uses synchronize_srcu() or call_srcu(), then
+        the corresponding readers must use srcu_read_lock() and
         srcu_read_unlock(), and with the same srcu_struct.  The rules for
         the expedited primitives are the same as for their non-expedited
         counterparts.  Mixing things up will result in confusion and
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 8e9359de1d28..6f3a0057548e 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -12,12 +12,12 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
         This kernel configuration parameter defines the period of time
         that RCU will wait from the beginning of a grace period until it
         issues an RCU CPU stall warning.  This time period is normally
-        sixty seconds.
+        21 seconds.
 
         This configuration parameter may be changed at runtime via the
         /sys/module/rcutree/parameters/rcu_cpu_stall_timeout, however
         this parameter is checked only at the beginning of a cycle.
-        So if you are 30 seconds into a 70-second stall, setting this
+        So if you are 10 seconds into a 40-second stall, setting this
         sysfs parameter to (say) five will shorten the timeout for the
         -next- stall, or the following warning for the current stall
         (assuming the stall lasts long enough).  It will not affect the
@@ -32,7 +32,7 @@ CONFIG_RCU_CPU_STALL_VERBOSE
         also dump the stacks of any tasks that are blocking the current
         RCU-preempt grace period.
 
-RCU_CPU_STALL_INFO
+CONFIG_RCU_CPU_STALL_INFO
 
         This kernel configuration parameter causes the stall warning to
         print out additional per-CPU diagnostic information, including
@@ -43,7 +43,8 @@ RCU_STALL_DELAY_DELTA
         Although the lockdep facility is extremely useful, it does add
         some overhead.  Therefore, under CONFIG_PROVE_RCU, the
         RCU_STALL_DELAY_DELTA macro allows five extra seconds before
-        giving an RCU CPU stall warning message.
+        giving an RCU CPU stall warning message.  (This is a cpp
+        macro, not a kernel configuration parameter.)
 
 RCU_STALL_RAT_DELAY
 
@@ -52,7 +53,8 @@ RCU_STALL_RAT_DELAY
         However, if the offending CPU does not detect its own stall in
         the number of jiffies specified by RCU_STALL_RAT_DELAY, then
         some other CPU will complain.  This delay is normally set to
-        two jiffies.
+        two jiffies.  (This is a cpp macro, not a kernel configuration
+        parameter.)
 
 When a CPU detects that it is stalling, it will print a message similar
 to the following:
@@ -86,7 +88,12 @@ printing, there will be a spurious stall-warning message:
 
 INFO: rcu_bh_state detected stalls on CPUs/tasks: { } (detected by 4, 2502 jiffies)
 
-This is rare, but does happen from time to time in real life.
+This is rare, but does happen from time to time in real life.  It is also
+possible for a zero-jiffy stall to be flagged in this case, depending
+on how the stall warning and the grace-period initialization happen to
+interact.  Please note that it is not possible to entirely eliminate this
+sort of false positive without resorting to things like stop_machine(),
+which is overkill for this sort of problem.
 
 If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
 more information is printed with the stall-warning message, for example:
@@ -216,4 +223,5 @@ that portion of the stack which remains the same from trace to trace.
 If you can reliably trigger the stall, ftrace can be quite helpful.
 
 RCU bugs can often be debugged with the help of CONFIG_RCU_TRACE
-and with RCU's event tracing.
+and with RCU's event tracing.  For information on RCU's event tracing,
+see include/trace/events/rcu.h.
diff --git a/Documentation/acpi/dsdt-override.txt b/Documentation/acpi/dsdt-override.txt
index febbb1ba4d23..784841caa6e6 100644
--- a/Documentation/acpi/dsdt-override.txt
+++ b/Documentation/acpi/dsdt-override.txt
@@ -4,4 +4,4 @@ CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
 
 When to use this method is described in detail on the
 Linux/ACPI home page:
-http://www.lesswatts.org/projects/acpi/overridingDSDT.php
+https://01.org/linux-acpi/documentation/overriding-dsdt
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index aca4e69121b7..b994bcb32b92 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -295,10 +295,6 @@ These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
 specifies the path to the controller. In order to use these GPIOs in Linux
 we need to translate them to the Linux GPIO numbers.
 
-The driver can do this by including <linux/acpi_gpio.h> and then calling
-acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
-negative errno if there was no translation found.
-
 In a simple case of just getting the Linux GPIO number from device
 resources one can use acpi_get_gpio_by_index() helper function. It takes
 pointer to the device and index of the GpioIo/GpioInt descriptor in the
@@ -322,3 +318,25 @@ suitable to the gpiolib before passing them.
 
 In case of GpioInt resource an additional call to gpio_to_irq() must be
 done before calling request_irq().
+
+Note that the above API is ACPI specific and not recommended for drivers
+that need to support non-ACPI systems. The recommended way is to use
+the descriptor based GPIO interfaces. The above example looks like this
+when converted to the GPIO desc:
+
+        #include <linux/gpio/consumer.h>
+        ...
+
+        struct gpio_desc *irq_desc, *power_desc;
+
+        irq_desc = gpiod_get_index(dev, NULL, 1);
+        if (IS_ERR(irq_desc))
+                /* handle error */
+
+        power_desc = gpiod_get_index(dev, NULL, 0);
+        if (IS_ERR(power_desc))
+                /* handle error */
+
+        /* Now we can use the GPIO descriptors */
+
+See also Documentation/gpio.txt.
diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 8f08a86e03b7..da0151db9964 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -88,6 +88,7 @@ EBU Armada family
         MV78230
         MV78260
         MV78460
+    NOTE: not to be confused with the non-SMP 78xx0 SoCs
 
   Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
   No public datasheet available.
diff --git a/Documentation/arm/sunxi/README b/Documentation/arm/sunxi/README
index e3f93fb9224e..7945238453ed 100644
--- a/Documentation/arm/sunxi/README
+++ b/Documentation/arm/sunxi/README
@@ -10,6 +10,10 @@ SunXi family
   Linux kernel mach directory: arch/arm/mach-sunxi
 
   Flavors:
+    * ARM926 based SoCs
+      - Allwinner F20 (sun3i)
+        + Not Supported
+
     * ARM Cortex-A8 based SoCs
       - Allwinner A10 (sun4i)
         + Datasheet
@@ -25,4 +29,24 @@ SunXi family
         + 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
+          http://dl.linux-sunxi.org/A13/A13%20User%20Manual%20-%20v1.2%20%282013-01-08%29.pdf
+
+    * Dual ARM Cortex-A7 based SoCs
+      - Allwinner A20 (sun7i)
+        + User Manual
+          http://dl.linux-sunxi.org/A20/A20%20User%20Manual%202013-03-22.pdf
+
+      - Allwinner A23
+        + Not Supported
+
+    * Quad ARM Cortex-A7 based SoCs
+      - Allwinner A31 (sun6i)
+        + Datasheet
+          http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20(2012-12-24).pdf
+
+      - Allwinner A31s (sun6i)
+        + Not Supported
+
+    * Quad ARM Cortex-A15, Quad ARM Cortex-A7 based SoCs
+      - Allwinner A80
+        + Not Supported
\ No newline at end of file
diff --git a/Documentation/arm64/booting.txt b/Documentation/arm64/booting.txt
index 98df4a03807e..a9691cc48fe3 100644
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -115,9 +115,10 @@ Before jumping into the kernel, the following conditions must be met:
   External caches (if present) must be configured and disabled.
 
 - Architected timers
-  CNTFRQ must be programmed with the timer frequency.
-  If entering the kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0)
-  set where available.
+  CNTFRQ must be programmed with the timer frequency and CNTVOFF must
+  be programmed with a consistent value on all CPUs.  If entering the
+  kernel at EL1, CNTHCTL_EL2 must have EL1PCTEN (bit 0) set where
+  available.
 
 - Coherency
   All CPUs to be booted by the kernel must be part of the same coherency
@@ -130,30 +131,46 @@ Before jumping into the kernel, the following conditions must be met:
   the kernel image will be entered must be initialised by software at a
   higher exception level to prevent execution in an UNKNOWN state.
 
+The requirements described above for CPU mode, caches, MMUs, architected
+timers, coherency and system registers apply to all CPUs.  All CPUs must
+enter the kernel in the same exception level.
+
 The boot loader is expected to enter the kernel on each CPU in the
 following manner:
 
 - The primary CPU must jump directly to the first instruction of the
   kernel image.  The device tree blob passed by this CPU must contain
-  for each CPU node:
-
-    1. An 'enable-method' property. Currently, the only supported value
-       for this field is the string "spin-table".
-
-    2. A 'cpu-release-addr' property identifying a 64-bit,
-       zero-initialised memory location.
+  an 'enable-method' property for each cpu node.  The supported
+  enable-methods are described below.
 
   It is expected that the bootloader will generate these device tree
   properties and insert them into the blob prior to kernel entry.
 
-- Any secondary CPUs must spin outside of the kernel in a reserved area
-  of memory (communicated to the kernel by a /memreserve/ region in the
+- CPUs with a "spin-table" enable-method must have a 'cpu-release-addr'
+  property in their cpu node.  This property identifies a
+  naturally-aligned 64-bit zero-initalised memory location.
+
+  These CPUs should spin outside of the kernel in a reserved area of
+  memory (communicated to the kernel by a /memreserve/ region in the
   device tree) polling their cpu-release-addr location, which must be
   contained in the reserved region.  A wfe instruction may be inserted
   to reduce the overhead of the busy-loop and a sev will be issued by
   the primary CPU.  When a read of the location pointed to by the
-  cpu-release-addr returns a non-zero value, the CPU must jump directly
-  to this value.
+  cpu-release-addr returns a non-zero value, the CPU must jump to this
+  value.  The value will be written as a single 64-bit little-endian
+  value, so CPUs must convert the read value to their native endianness
+  before jumping to it.
+
+- CPUs with a "psci" enable method should remain outside of
+  the kernel (i.e. outside of the regions of memory described to the
+  kernel in the memory node, or in a reserved area of memory described
+  to the kernel by a /memreserve/ region in the device tree).  The
+  kernel will issue CPU_ON calls as described in ARM document number ARM
+  DEN 0022A ("Power State Coordination Interface System Software on ARM
+  processors") to bring CPUs into the kernel.
+
+  The device tree should contain a 'psci' node, as described in
+  Documentation/devicetree/bindings/arm/psci.txt.
 
 - Secondary CPU general-purpose register settings
   x0 = 0 (reserved for future use)
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 78a377124ef0..5e054bfe4dde 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -21,7 +21,7 @@ The swapper_pgd_dir address is written to TTBR1 and never written to
 TTBR0.
 
 
-AArch64 Linux memory layout:
+AArch64 Linux memory layout with 4KB pages:
 
 Start                   End                     Size            Use
 -----------------------------------------------------------------------
@@ -39,13 +39,38 @@ ffffffbffbc00000	ffffffbffbdfffff	   2MB		earlyprintk device
 
 ffffffbffbe00000        ffffffbffbe0ffff          64KB          PCI I/O space
 
-ffffffbbffff0000        ffffffbcffffffff          ~2MB          [guard]
+ffffffbffbe10000        ffffffbcffffffff          ~2MB          [guard]
 
 ffffffbffc000000        ffffffbfffffffff          64MB          modules
 
 ffffffc000000000        ffffffffffffffff         256GB          kernel logical memory map
 
 
+AArch64 Linux memory layout with 64KB pages:
+
+Start                   End                     Size            Use
+-----------------------------------------------------------------------
+0000000000000000        000003ffffffffff           4TB          user
+
+fffffc0000000000        fffffdfbfffeffff          ~2TB          vmalloc
+
+fffffdfbffff0000        fffffdfbffffffff          64KB          [guard page]
+
+fffffdfc00000000        fffffdfdffffffff           8GB          vmemmap
+
+fffffdfe00000000        fffffdfffbbfffff          ~8GB          [guard, future vmmemap]
+
+fffffdfffbc00000        fffffdfffbdfffff           2MB          earlyprintk device
+
+fffffdfffbe00000        fffffdfffbe0ffff          64KB          PCI I/O space
+
+fffffdfffbe10000        fffffdfffbffffff          ~2MB          [guard]
+
+fffffdfffc000000        fffffdffffffffff          64MB          modules
+
+fffffe0000000000        ffffffffffffffff           2TB          kernel logical memory map
+
+
 Translation table lookup with 4KB pages:
 
 +--------+--------+--------+--------+--------+--------+--------+--------+
diff --git a/Documentation/assoc_array.txt b/Documentation/assoc_array.txt
new file mode 100644
index 000000000000..f4faec0f66e4
--- /dev/null
+++ b/Documentation/assoc_array.txt
@@ -0,0 +1,574 @@
+                   ========================================
+                   GENERIC ASSOCIATIVE ARRAY IMPLEMENTATION
+                   ========================================
+
+Contents:
+
+ - Overview.
+
+ - The public API.
+   - Edit script.
+   - Operations table.
+   - Manipulation functions.
+   - Access functions.
+   - Index key form.
+
+ - Internal workings.
+   - Basic internal tree layout.
+   - Shortcuts.
+   - Splitting and collapsing nodes.
+   - Non-recursive iteration.
+   - Simultaneous alteration and iteration.
+
+
+========
+OVERVIEW
+========
+
+This associative array implementation is an object container with the following
+properties:
+
+ (1) Objects are opaque pointers.  The implementation does not care where they
+     point (if anywhere) or what they point to (if anything).
+
+     [!] NOTE: Pointers to objects _must_ be zero in the least significant bit.
+
+ (2) Objects do not need to contain linkage blocks for use by the array.  This
+     permits an object to be located in multiple arrays simultaneously.
+     Rather, the array is made up of metadata blocks that point to objects.
+
+ (3) Objects require index keys to locate them within the array.
+
+ (4) Index keys must be unique.  Inserting an object with the same key as one
+     already in the array will replace the old object.
+
+ (5) Index keys can be of any length and can be of different lengths.
+
+ (6) Index keys should encode the length early on, before any variation due to
+     length is seen.
+
+ (7) Index keys can include a hash to scatter objects throughout the array.
+
+ (8) The array can iterated over.  The objects will not necessarily come out in
+     key order.
+
+ (9) The array can be iterated over whilst it is being modified, provided the
+     RCU readlock is being held by the iterator.  Note, however, under these
+     circumstances, some objects may be seen more than once.  If this is a
+     problem, the iterator should lock against modification.  Objects will not
+     be missed, however, unless deleted.
+
+(10) Objects in the array can be looked up by means of their index key.
+
+(11) Objects can be looked up whilst the array is being modified, provided the
+     RCU readlock is being held by the thread doing the look up.
+
+The implementation uses a tree of 16-pointer nodes internally that are indexed
+on each level by nibbles from the index key in the same manner as in a radix
+tree.  To improve memory efficiency, shortcuts can be emplaced to skip over
+what would otherwise be a series of single-occupancy nodes.  Further, nodes
+pack leaf object pointers into spare space in the node rather than making an
+extra branch until as such time an object needs to be added to a full node.
+
+
+==============
+THE PUBLIC API
+==============
+
+The public API can be found in <linux/assoc_array.h>.  The associative array is
+rooted on the following structure:
+
+        struct assoc_array {
+                ...
+        };
+
+The code is selected by enabling CONFIG_ASSOCIATIVE_ARRAY.
+
+
+EDIT SCRIPT
+-----------
+
+The insertion and deletion functions produce an 'edit script' that can later be
+applied to effect the changes without risking ENOMEM.  This retains the
+preallocated metadata blocks that will be installed in the internal tree and
+keeps track of the metadata blocks that will be removed from the tree when the
+script is applied.
+
+This is also used to keep track of dead blocks and dead objects after the
+script has been applied so that they can be freed later.  The freeing is done
+after an RCU grace period has passed - thus allowing access functions to
+proceed under the RCU read lock.
+
+The script appears as outside of the API as a pointer of the type:
+
+        struct assoc_array_edit;
+
+There are two functions for dealing with the script:
+
+ (1) Apply an edit script.
+
+        void assoc_array_apply_edit(struct assoc_array_edit *edit);
+
+     This will perform the edit functions, interpolating various write barriers
+     to permit accesses under the RCU read lock to continue.  The edit script
+     will then be passed to call_rcu() to free it and any dead stuff it points
+     to.
+
+ (2) Cancel an edit script.
+
+        void assoc_array_cancel_edit(struct assoc_array_edit *edit);
+
+     This frees the edit script and all preallocated memory immediately.  If
+     this was for insertion, the new object is _not_ released by this function,
+     but must rather be released by the caller.
+
+These functions are guaranteed not to fail.
+
+
+OPERATIONS TABLE
+----------------
+
+Various functions take a table of operations:
+
+        struct assoc_array_ops {
+                ...
+        };
+
+This points to a number of methods, all of which need to be provided:
+
+ (1) Get a chunk of index key from caller data:
+
+        unsigned long (*get_key_chunk)(const void *index_key, int level);
+
+     This should return a chunk of caller-supplied index key starting at the
+     *bit* position given by the level argument.  The level argument will be a
+     multiple of ASSOC_ARRAY_KEY_CHUNK_SIZE and the function should return
+     ASSOC_ARRAY_KEY_CHUNK_SIZE bits.  No error is possible.
+
+
+ (2) Get a chunk of an object's index key.
+
+        unsigned long (*get_object_key_chunk)(const void *object, int level);
+
+     As the previous function, but gets its data from an object in the array
+     rather than from a caller-supplied index key.
+
+
+ (3) See if this is the object we're looking for.
+
+        bool (*compare_object)(const void *object, const void *index_key);
+
+     Compare the object against an index key and return true if it matches and
+     false if it doesn't.
+
+
+ (4) Diff the index keys of two objects.
+
+        int (*diff_objects)(const void *a, const void *b);
+
+     Return the bit position at which the index keys of two objects differ or
+     -1 if they are the same.
+
+
+ (5) Free an object.
+
+        void (*free_object)(void *object);
+
+     Free the specified object.  Note that this may be called an RCU grace
+     period after assoc_array_apply_edit() was called, so synchronize_rcu() may
+     be necessary on module unloading.
+
+
+MANIPULATION FUNCTIONS
+----------------------
+
+There are a number of functions for manipulating an associative array:
+
+ (1) Initialise an associative array.
+
+        void assoc_array_init(struct assoc_array *array);
+
+     This initialises the base structure for an associative array.  It can't
+     fail.
+
+
+ (2) Insert/replace an object in an associative array.
+
+        struct assoc_array_edit *
+        assoc_array_insert(struct assoc_array *array,
+                           const struct assoc_array_ops *ops,
+                           const void *index_key,
+                           void *object);
+
+     This inserts the given object into the array.  Note that the least
+     significant bit of the pointer must be zero as it's used to type-mark
+     pointers internally.
+
+     If an object already exists for that key then it will be replaced with the
+     new object and the old one will be freed automatically.
+
+     The index_key argument should hold index key information and is
+     passed to the methods in the ops table when they are called.
+
+     This function makes no alteration to the array itself, but rather returns
+     an edit script that must be applied.  -ENOMEM is returned in the case of
+     an out-of-memory error.
+
+     The caller should lock exclusively against other modifiers of the array.
+
+
+ (3) Delete an object from an associative array.
+
+        struct assoc_array_edit *
+        assoc_array_delete(struct assoc_array *array,
+                           const struct assoc_array_ops *ops,
+                           const void *index_key);
+
+     This deletes an object that matches the specified data from the array.
+
+     The index_key argument should hold index key information and is
+     passed to the methods in the ops table when they are called.
+
+     This function makes no alteration to the array itself, but rather returns
+     an edit script that must be applied.  -ENOMEM is returned in the case of
+     an out-of-memory error.  NULL will be returned if the specified object is
+     not found within the array.
+
+     The caller should lock exclusively against other modifiers of the array.
+
+
+ (4) Delete all objects from an associative array.
+
+        struct assoc_array_edit *
+        assoc_array_clear(struct assoc_array *array,
+                          const struct assoc_array_ops *ops);
+
+     This deletes all the objects from an associative array and leaves it
+     completely empty.
+
+     This function makes no alteration to the array itself, but rather returns
+     an edit script that must be applied.  -ENOMEM is returned in the case of
+     an out-of-memory error.
+
+     The caller should lock exclusively against other modifiers of the array.
+
+
+ (5) Destroy an associative array, deleting all objects.
+
+        void assoc_array_destroy(struct assoc_array *array,
+                                 const struct assoc_array_ops *ops);
+
+     This destroys the contents of the associative array and leaves it
+     completely empty.  It is not permitted for another thread to be traversing
+     the array under the RCU read lock at the same time as this function is
+     destroying it as no RCU deferral is performed on memory release -
+     something that would require memory to be allocated.
+
+     The caller should lock exclusively against other modifiers and accessors
+     of the array.
+
+
+ (6) Garbage collect an associative array.
+
+        int assoc_array_gc(struct assoc_array *array,
+                           const struct assoc_array_ops *ops,
+                           bool (*iterator)(void *object, void *iterator_data),
+                           void *iterator_data);
+
+     This iterates over the objects in an associative array and passes each one
+     to iterator().  If iterator() returns true, the object is kept.  If it
+     returns false, the object will be freed.  If the iterator() function
+     returns true, it must perform any appropriate refcount incrementing on the
+     object before returning.
+
+     The internal tree will be packed down if possible as part of the iteration
+     to reduce the number of nodes in it.
+
+     The iterator_data is passed directly to iterator() and is otherwise
+     ignored by the function.
+
+     The function will return 0 if successful and -ENOMEM if there wasn't
+     enough memory.
+
+     It is possible for other threads to iterate over or search the array under
+     the RCU read lock whilst this function is in progress.  The caller should
+     lock exclusively against other modifiers of the array.
+
+
+ACCESS FUNCTIONS
+----------------
+
+There are two functions for accessing an associative array:
+
+ (1) Iterate over all the objects in an associative array.
+
+        int assoc_array_iterate(const struct assoc_array *array,
+                                int (*iterator)(const void *object,
+                                                void *iterator_data),
+                                void *iterator_data);
+
+     This passes each object in the array to the iterator callback function.
+     iterator_data is private data for that function.
+
+     This may be used on an array at the same time as the array is being
+     modified, provided the RCU read lock is held.  Under such circumstances,
+     it is possible for the iteration function to see some objects twice.  If
+     this is a problem, then modification should be locked against.  The
+     iteration algorithm should not, however, miss any objects.
+
+     The function will return 0 if no objects were in the array or else it will
+     return the result of the last iterator function called.  Iteration stops
+     immediately if any call to the iteration function results in a non-zero
+     return.
+
+
+ (2) Find an object in an associative array.
+
+        void *assoc_array_find(const struct assoc_array *array,
+                               const struct assoc_array_ops *ops,
+                               const void *index_key);
+
+     This walks through the array's internal tree directly to the object
+     specified by the index key..
+
+     This may be used on an array at the same time as the array is being
+     modified, provided the RCU read lock is held.
+
+     The function will return the object if found (and set *_type to the object
+     type) or will return NULL if the object was not found.
+
+
+INDEX KEY FORM
+--------------
+
+The index key can be of any form, but since the algorithms aren't told how long
+the key is, it is strongly recommended that the index key includes its length
+very early on before any variation due to the length would have an effect on
+comparisons.
+
+This will cause leaves with different length keys to scatter away from each
+other - and those with the same length keys to cluster together.
+
+It is also recommended that the index key begin with a hash of the rest of the
+key to maximise scattering throughout keyspace.
+
+The better the scattering, the wider and lower the internal tree will be.
+
+Poor scattering isn't too much of a problem as there are shortcuts and nodes
+can contain mixtures of leaves and metadata pointers.
+
+The index key is read in chunks of machine word.  Each chunk is subdivided into
+one nibble (4 bits) per level, so on a 32-bit CPU this is good for 8 levels and
+on a 64-bit CPU, 16 levels.  Unless the scattering is really poor, it is
+unlikely that more than one word of any particular index key will have to be
+used.
+
+
+=================
+INTERNAL WORKINGS
+=================
+
+The associative array data structure has an internal tree.  This tree is
+constructed of two types of metadata blocks: nodes and shortcuts.
+
+A node is an array of slots.  Each slot can contain one of four things:
+
+ (*) A NULL pointer, indicating that the slot is empty.
+
+ (*) A pointer to an object (a leaf).
+
+ (*) A pointer to a node at the next level.
+
+ (*) A pointer to a shortcut.
+
+
+BASIC INTERNAL TREE LAYOUT
+--------------------------
+
+Ignoring shortcuts for the moment, the nodes form a multilevel tree.  The index
+key space is strictly subdivided by the nodes in the tree and nodes occur on
+fixed levels.  For example:
+
+ Level: 0               1               2               3
+        =============== =============== =============== ===============
+                                                        NODE D
+                        NODE B          NODE C  +------>+---+
+                +------>+---+   +------>+---+   |       | 0 |
+        NODE A  |       | 0 |   |       | 0 |   |       +---+
+        +---+   |       +---+   |       +---+   |       :   :
+        | 0 |   |       :   :   |       :   :   |       +---+
+        +---+   |       +---+   |       +---+   |       | f |
+        | 1 |---+       | 3 |---+       | 7 |---+       +---+
+        +---+           +---+           +---+
+        :   :           :   :           | 8 |---+
+        +---+           +---+           +---+   |       NODE E
+        | e |---+       | f |           :   :   +------>+---+
+        +---+   |       +---+           +---+           | 0 |
+        | f |   |                       | f |           +---+
+        +---+   |                       +---+           :   :
+                |       NODE F                          +---+
+                +------>+---+                           | f |
+                        | 0 |           NODE G          +---+
+                        +---+   +------>+---+
+                        :   :   |       | 0 |
+                        +---+   |       +---+
+                        | 6 |---+       :   :
+                        +---+           +---+
+                        :   :           | f |
+                        +---+           +---+
+                        | f |
+                        +---+
+
+In the above example, there are 7 nodes (A-G), each with 16 slots (0-f).
+Assuming no other meta data nodes in the tree, the key space is divided thusly:
+
+        KEY PREFIX      NODE
+        ==========      ====
+        137*            D
+        138*            E
+        13[0-69-f]*     C
+        1[0-24-f]*      B
+        e6*             G
+        e[0-57-f]*      F
+        [02-df]*        A
+
+So, for instance, keys with the following example index keys will be found in
+the appropriate nodes:
+
+        INDEX KEY       PREFIX  NODE
+        =============== ======= ====
+        13694892892489  13      C
+        13795289025897  137     D
+        13889dde88793   138     E
+        138bbb89003093  138     E
+        1394879524789   12      C
+        1458952489      1       B
+        9431809de993ba  -       A
+        b4542910809cd   -       A
+        e5284310def98   e       F
+        e68428974237    e6      G
+        e7fffcbd443     e       F
+        f3842239082     -       A
+
+To save memory, if a node can hold all the leaves in its portion of keyspace,
+then the node will have all those leaves in it and will not have any metadata
+pointers - even if some of those leaves would like to be in the same slot.
+
+A node can contain a heterogeneous mix of leaves and metadata pointers.
+Metadata pointers must be in the slots that match their subdivisions of key
+space.  The leaves can be in any slot not occupied by a metadata pointer.  It
+is guaranteed that none of the leaves in a node will match a slot occupied by a
+metadata pointer.  If the metadata pointer is there, any leaf whose key matches
+the metadata key prefix must be in the subtree that the metadata pointer points
+to.
+
+In the above example list of index keys, node A will contain:
+
+        SLOT    CONTENT         INDEX KEY (PREFIX)
+        ====    =============== ==================
+        1       PTR TO NODE B   1*
+        any     LEAF            9431809de993ba
+        any     LEAF            b4542910809cd
+        e       PTR TO NODE F   e*
+        any     LEAF            f3842239082
+
+and node B:
+
+        3       PTR TO NODE C   13*
+        any     LEAF            1458952489
+
+
+SHORTCUTS
+---------
+
+Shortcuts are metadata records that jump over a piece of keyspace.  A shortcut
+is a replacement for a series of single-occupancy nodes ascending through the
+levels.  Shortcuts exist to save memory and to speed up traversal.
+
+It is possible for the root of the tree to be a shortcut - say, for example,
+the tree contains at least 17 nodes all with key prefix '1111'.  The insertion
+algorithm will insert a shortcut to skip over the '1111' keyspace in a single
+bound and get to the fourth level where these actually become different.
+
+
+SPLITTING AND COLLAPSING NODES
+------------------------------
+
+Each node has a maximum capacity of 16 leaves and metadata pointers.  If the
+insertion algorithm finds that it is trying to insert a 17th object into a
+node, that node will be split such that at least two leaves that have a common
+key segment at that level end up in a separate node rooted on that slot for
+that common key segment.
+
+If the leaves in a full node and the leaf that is being inserted are
+sufficiently similar, then a shortcut will be inserted into the tree.
+
+When the number of objects in the subtree rooted at a node falls to 16 or
+fewer, then the subtree will be collapsed down to a single node - and this will
+ripple towards the root if possible.
+
+
+NON-RECURSIVE ITERATION
+-----------------------
+
+Each node and shortcut contains a back pointer to its parent and the number of
+slot in that parent that points to it.  None-recursive iteration uses these to
+proceed rootwards through the tree, going to the parent node, slot N + 1 to
+make sure progress is made without the need for a stack.
+
+The backpointers, however, make simultaneous alteration and iteration tricky.
+
+
+SIMULTANEOUS ALTERATION AND ITERATION
+-------------------------------------
+
+There are a number of cases to consider:
+
+ (1) Simple insert/replace.  This involves simply replacing a NULL or old
+     matching leaf pointer with the pointer to the new leaf after a barrier.
+     The metadata blocks don't change otherwise.  An old leaf won't be freed
+     until after the RCU grace period.
+
+ (2) Simple delete.  This involves just clearing an old matching leaf.  The
+     metadata blocks don't change otherwise.  The old leaf won't be freed until
+     after the RCU grace period.
+
+ (3) Insertion replacing part of a subtree that we haven't yet entered.  This
+     may involve replacement of part of that subtree - but that won't affect
+     the iteration as we won't have reached the pointer to it yet and the
+     ancestry blocks are not replaced (the layout of those does not change).
+
+ (4) Insertion replacing nodes that we're actively processing.  This isn't a
+     problem as we've passed the anchoring pointer and won't switch onto the
+     new layout until we follow the back pointers - at which point we've
+     already examined the leaves in the replaced node (we iterate over all the
+     leaves in a node before following any of its metadata pointers).
+
+     We might, however, re-see some leaves that have been split out into a new
+     branch that's in a slot further along than we were at.
+
+ (5) Insertion replacing nodes that we're processing a dependent branch of.
+     This won't affect us until we follow the back pointers.  Similar to (4).
+
+ (6) Deletion collapsing a branch under us.  This doesn't affect us because the
+     back pointers will get us back to the parent of the new node before we
+     could see the new node.  The entire collapsed subtree is thrown away
+     unchanged - and will still be rooted on the same slot, so we shouldn't
+     process it a second time as we'll go back to slot + 1.
+
+Note:
+
+ (*) Under some circumstances, we need to simultaneously change the parent
+     pointer and the parent slot pointer on a node (say, for example, we
+     inserted another node before it and moved it up a level).  We cannot do
+     this without locking against a read - so we have to replace that node too.
+
+     However, when we're changing a shortcut into a node this isn't a problem
+     as shortcuts only have one slot and so the parent slot number isn't used
+     when traversing backwards over one.  This means that it's okay to change
+     the slot number first - provided suitable barriers are used to make sure
+     the parent slot number is read after the back pointer.
+
+Obsolete blocks and leaves are freed up after an RCU grace period has passed,
+so as long as anyone doing walking or iteration holds the RCU read lock, the
+old superstructure should not go away on them.
diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt
index 1c732f0c6758..01bce243d3d7 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -4,7 +4,8 @@ Kernel driver lp855x
 Backlight driver for LP855x ICs
 
 Supported chips:
-        Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8556 and LP8557
+        Texas Instruments LP8550, LP8551, LP8552, LP8553, LP8555, LP8556 and
+        LP8557
 
 Author: Milo(Woogyom) Kim <milo.kim@ti.com>
 
@@ -24,7 +25,7 @@ Value : pwm based or register based
 
 2) chip_id
 The lp855x chip id.
-Value : lp8550/lp8551/lp8552/lp8553/lp8556/lp8557
+Value : lp8550/lp8551/lp8552/lp8553/lp8555/lp8556/lp8557
 
 Platform data for lp855x
 ------------------------
diff --git a/Documentation/block/00-INDEX b/Documentation/block/00-INDEX
index d18ecd827c40..929d9904f74b 100644
--- a/Documentation/block/00-INDEX
+++ b/Documentation/block/00-INDEX
@@ -6,6 +6,8 @@ capability.txt
         - Generic Block Device Capability (/sys/block/<device>/capability)
 cfq-iosched.txt
         - CFQ IO scheduler tunables
+cmdline-partition.txt
+        - how to specify block device partitions on kernel command line
 data-integrity.txt
         - Block data integrity
 deadline-iosched.txt
diff --git a/Documentation/block/cmdline-partition.txt b/Documentation/block/cmdline-partition.txt
index 2bbf4cc40c3f..525b9f6d7fb4 100644
--- a/Documentation/block/cmdline-partition.txt
+++ b/Documentation/block/cmdline-partition.txt
@@ -1,9 +1,9 @@
-Embedded device command line partition
+Embedded device command line partition parsing
 =====================================================================
 
-Read block device partition table from command line.
-The partition used for fixed block device (eMMC) embedded device.
-It is no MBR, save storage space. Bootloader can be easily accessed
+Support for reading the block device partition table from the command line.
+It is typically used for fixed block (eMMC) embedded devices.
+It has no MBR, so saves storage space. Bootloader can be easily accessed
 by absolute address of data on the block device.
 Users can easily change the partition.
 
diff --git a/Documentation/blockdev/floppy.txt b/Documentation/blockdev/floppy.txt
index 470fe4b5e379..e2240f5ab64d 100644
--- a/Documentation/blockdev/floppy.txt
+++ b/Documentation/blockdev/floppy.txt
@@ -39,15 +39,15 @@ Module configuration options
 ============================
 
  If you use the floppy driver as a module, use the following syntax:
-modprobe floppy <options>
+modprobe floppy floppy="<options>"
 
 Example:
- modprobe floppy omnibook messages
+ modprobe floppy floppy="omnibook messages"
 
  If you need certain options enabled every time you load the floppy driver,
 you can put:
 
- options floppy omnibook messages
+ options floppy floppy="omnibook messages"
 
 in a configuration file in /etc/modprobe.d/.
 
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 8af4ad121828..e2bc132608fd 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -573,15 +573,19 @@ an memcg since the pages are allowed to be allocated from any physical
 node.  One of the use cases is evaluating application performance by
 combining this information with the application's CPU allocation.
 
-We export "total", "file", "anon" and "unevictable" pages per-node for
-each memcg.  The ouput format of memory.numa_stat is:
+Each memcg's numa_stat file includes "total", "file", "anon" and "unevictable"
+per-node page counts including "hierarchical_<counter>" which sums up all
+hierarchical children's values in addition to the memcg's own value.
+
+The ouput format of memory.numa_stat is:
 
 total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ...
 file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ...
 anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
 unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ...
+hierarchical_<counter>=<counter pages> N0=<node 0 pages> N1=<node 1 pages> ...
 
-And we have total = file + anon + unevictable.
+The "total" count is sum of file + anon + unevictable.
 
 6. Hierarchy support
 
diff --git a/Documentation/connector/ucon.c b/Documentation/connector/ucon.c
index 4848db8c71ff..8a4da64e02a8 100644
--- a/Documentation/connector/ucon.c
+++ b/Documentation/connector/ucon.c
@@ -71,7 +71,7 @@ static int netlink_send(int s, struct cn_msg *msg)
         nlh->nlmsg_seq = seq++;
         nlh->nlmsg_pid = getpid();
         nlh->nlmsg_type = NLMSG_DONE;
-        nlh->nlmsg_len = NLMSG_LENGTH(size - sizeof(*nlh));
+        nlh->nlmsg_len = size;
         nlh->nlmsg_flags = 0;
 
         m = NLMSG_DATA(nlh);
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index 40282e617913..8b1a4451422e 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -23,8 +23,8 @@ Contents:
 1.1  Initialization
 1.2  Per-CPU Initialization
 1.3  verify
-1.4  target or setpolicy?
-1.5  target
+1.4  target/target_index or setpolicy?
+1.5  target/target_index
 1.6  setpolicy
 2.   Frequency Table Helpers
 
@@ -56,7 +56,8 @@ cpufreq_driver.init -		A pointer to the per-CPU initialization
 cpufreq_driver.verify -         A pointer to a "verification" function.
 
 cpufreq_driver.setpolicy _or_ 
-cpufreq_driver.target -         See below on the differences.
+cpufreq_driver.target/
+target_index            -       See below on the differences.
 
 And optionally
 
@@ -66,7 +67,7 @@ cpufreq_driver.resume -		A pointer to a per-CPU resume function
                                 which is called with interrupts disabled
                                 and _before_ the pre-suspend frequency
                                 and/or policy is restored by a call to
-                                ->target or ->setpolicy.
+                                ->target/target_index or ->setpolicy.
 
 cpufreq_driver.attr -           A pointer to a NULL-terminated list of
                                 "struct freq_attr" which allow to
@@ -103,8 +104,8 @@ policy->governor		must contain the "default policy" for
                                 this CPU. A few moments later,
                                 cpufreq_driver.verify and either
                                 cpufreq_driver.setpolicy or
-                                cpufreq_driver.target is called with
-                                these values.
+                                cpufreq_driver.target/target_index is called
+                                with these values.
 
 For setting some of these values (cpuinfo.min[max]_freq, policy->min[max]), the
 frequency table helpers might be helpful. See the section 2 for more information
@@ -133,20 +134,28 @@ range) is within policy->min and policy->max. If necessary, increase
 policy->max first, and only if this is no solution, decrease policy->min.
 
 
-1.4 target or setpolicy?
+1.4 target/target_index or setpolicy?
 ----------------------------
 
 Most cpufreq drivers or even most cpu frequency scaling algorithms 
 only allow the CPU to be set to one frequency. For these, you use the
-->target call.
+->target/target_index call.
 
 Some cpufreq-capable processors switch the frequency between certain
 limits on their own. These shall use the ->setpolicy call
 
 
-1.4. target
+1.4. target/target_index
 -------------
 
+The target_index call has two arguments: struct cpufreq_policy *policy,
+and unsigned int index (into the exposed frequency table).
+
+The CPUfreq driver must set the new frequency when called here. The
+actual frequency must be determined by freq_table[index].frequency.
+
+Deprecated:
+----------
 The target call has three arguments: struct cpufreq_policy *policy,
 unsigned int target_frequency, unsigned int relation.
 
diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt
index 219970ba54b7..77ec21574fb1 100644
--- a/Documentation/cpu-freq/governors.txt
+++ b/Documentation/cpu-freq/governors.txt
@@ -40,7 +40,7 @@ Most cpufreq drivers (in fact, all except one, longrun) or even most
 cpu frequency scaling algorithms only offer the CPU to be set to one
 frequency. In order to offer dynamic frequency scaling, the cpufreq
 core must be able to tell these drivers of a "target frequency". So
-these specific drivers will be transformed to offer a "->target"
+these specific drivers will be transformed to offer a "->target/target_index"
 call instead of the existing "->setpolicy" call. For "longrun", all
 stays the same, though.
 
@@ -71,7 +71,7 @@ CPU can be set to switch independently	 |	   CPU can only be set
                     /                          the limits of policy->{min,max}
                    /                                \
                   /                                  \
-        Using the ->setpolicy call,              Using the ->target call,
+        Using the ->setpolicy call,              Using the ->target/target_index call,
             the limits and the                    the frequency closest
              "policy" is set.                     to target_freq is set.
                                                   It is assured that it
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 786dc82f98ce..8cb9938cc47e 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -5,7 +5,7 @@
                         Rusty Russell <rusty@rustcorp.com.au>
                         Srivatsa Vaddagiri <vatsa@in.ibm.com>
                 i386:
-                        Zwane Mwaikambo <zwane@arm.linux.org.uk>
+                        Zwane Mwaikambo <zwanem@gmail.com>
                 ppc64:
                         Nathan Lynch <nathanl@austin.ibm.com>
                         Joel Schopp <jschopp@austin.ibm.com>
diff --git a/Documentation/cpuidle/governor.txt b/Documentation/cpuidle/governor.txt
index 12c6bd50c9f6..d9020f5e847b 100644
--- a/Documentation/cpuidle/governor.txt
+++ b/Documentation/cpuidle/governor.txt
@@ -25,5 +25,4 @@ kernel configuration and platform will be selected by cpuidle.
 
 Interfaces:
 extern int cpuidle_register_governor(struct cpuidle_governor *gov);
-extern void cpuidle_unregister_governor(struct cpuidle_governor *gov);
 struct cpuidle_governor
diff --git a/Documentation/device-mapper/cache-policies.txt b/Documentation/device-mapper/cache-policies.txt
index d7c440b444cc..df52a849957f 100644
--- a/Documentation/device-mapper/cache-policies.txt
+++ b/Documentation/device-mapper/cache-policies.txt
@@ -30,8 +30,10 @@ multiqueue
 
 This policy is the default.
 
-The multiqueue policy has two sets of 16 queues: one set for entries
-waiting for the cache and another one for those in the cache.
+The multiqueue policy has three sets of 16 queues: one set for entries
+waiting for the cache and another two for those in the cache (a set for
+clean entries and a set for dirty entries).
+
 Cache entries in the queues are aged based on logical time. Entry into
 the cache is based on variable thresholds and queue selection is based
 on hit count on entry. The policy aims to take different cache miss
diff --git a/Documentation/device-mapper/cache.txt b/Documentation/device-mapper/cache.txt
index 33d45ee0b737..274752f8bdf9 100644
--- a/Documentation/device-mapper/cache.txt
+++ b/Documentation/device-mapper/cache.txt
@@ -68,10 +68,11 @@ So large block sizes are bad because they waste cache space.  And small
 block sizes are bad because they increase the amount of metadata (both
 in core and on disk).
 
-Writeback/writethrough
-----------------------
+Cache operating modes
+---------------------
 
-The cache has two modes, writeback and writethrough.
+The cache has three operating modes: writeback, writethrough and
+passthrough.
 
 If writeback, the default, is selected then a write to a block that is
 cached will go only to the cache and the block will be marked dirty in
@@ -81,8 +82,31 @@ If writethrough is selected then a write to a cached block will not
 complete until it has hit both the origin and cache devices.  Clean
 blocks should remain clean.
 
+If passthrough is selected, useful when the cache contents are not known
+to be coherent with the origin device, then all reads are served from
+the origin device (all reads miss the cache) and all writes are
+forwarded to the origin device; additionally, write hits cause cache
+block invalidates.  To enable passthrough mode the cache must be clean.
+Passthrough mode allows a cache device to be activated without having to
+worry about coherency.  Coherency that exists is maintained, although
+the cache will gradually cool as writes take place.  If the coherency of
+the cache can later be verified, or established through use of the
+"invalidate_cblocks" message, the cache device can be transitioned to
+writethrough or writeback mode while still warm.  Otherwise, the cache
+contents can be discarded prior to transitioning to the desired
+operating mode.
+
 A simple cleaner policy is provided, which will clean (write back) all
-dirty blocks in a cache.  Useful for decommissioning a cache.
+dirty blocks in a cache.  Useful for decommissioning a cache or when
+shrinking a cache.  Shrinking the cache's fast device requires all cache
+blocks, in the area of the cache being removed, to be clean.  If the
+area being removed from the cache still contains dirty blocks the resize
+will fail.  Care must be taken to never reduce the volume used for the
+cache's fast device until the cache is clean.  This is of particular
+importance if writeback mode is used.  Writethrough and passthrough
+modes already maintain a clean cache.  Future support to partially clean
+the cache, above a specified threshold, will allow for keeping the cache
+warm and in writeback mode during resize.
 
 Migration throttling
 --------------------
@@ -161,7 +185,7 @@ Constructor
  block size      : cache unit size in sectors
 
  #feature args   : number of feature arguments passed
- feature args    : writethrough.  (The default is writeback.)
+ feature args    : writethrough or passthrough (The default is writeback.)
 
  policy          : the replacement policy to use
  #policy args    : an even number of arguments corresponding to
@@ -177,6 +201,13 @@ Optional feature arguments are:
                    back cache block contents later for performance reasons,
                    so they may differ from the corresponding origin blocks.
 
+   passthrough   : a degraded mode useful for various cache coherency
+                   situations (e.g., rolling back snapshots of
+                   underlying storage).  Reads and writes always go to
+                   the origin.  If a write goes to a cached origin
+                   block, then the cache block is invalidated.
+                   To enable passthrough mode the cache must be clean.
+
 A policy called 'default' is always registered.  This is an alias for
 the policy we currently think is giving best all round performance.
 
@@ -231,12 +262,26 @@ The message format is:
 E.g.
    dmsetup message my_cache 0 sequential_threshold 1024
 
+
+Invalidation is removing an entry from the cache without writing it
+back.  Cache blocks can be invalidated via the invalidate_cblocks
+message, which takes an arbitrary number of cblock ranges.  Each cblock
+must be expressed as a decimal value, in the future a variant message
+that takes cblock ranges expressed in hexidecimal may be needed to
+better support efficient invalidation of larger caches.  The cache must
+be in passthrough mode when invalidate_cblocks is used.
+
+   invalidate_cblocks [<cblock>|<cblock begin>-<cblock end>]*
+
+E.g.
+   dmsetup message my_cache 0 invalidate_cblocks 2345 3456-4567 5678-6789
+
 Examples
 ========
 
 The test suite can be found here:
 
-https://github.com/jthornber/thinp-test-suite
+https://github.com/jthornber/device-mapper-test-suite
 
 dmsetup create my_cache --table '0 41943040 cache /dev/mapper/metadata \
         /dev/mapper/ssd /dev/mapper/origin 512 1 writeback default 0'
diff --git a/Documentation/device-mapper/dm-crypt.txt b/Documentation/device-mapper/dm-crypt.txt
index 2c656ae43ba7..c81839b52c4d 100644
--- a/Documentation/device-mapper/dm-crypt.txt
+++ b/Documentation/device-mapper/dm-crypt.txt
@@ -4,12 +4,15 @@ dm-crypt
 Device-Mapper's "crypt" target provides transparent encryption of block devices
 using the kernel crypto API.
 
+For a more detailed description of supported parameters see:
+http://code.google.com/p/cryptsetup/wiki/DMCrypt
+
 Parameters: <cipher> <key> <iv_offset> <device path> \
               <offset> [<#opt_params> <opt_params>]
 
 <cipher>
     Encryption cipher and an optional IV generation mode.
-    (In format cipher[:keycount]-chainmode-ivopts:ivmode).
+    (In format cipher[:keycount]-chainmode-ivmode[:ivopts]).
     Examples:
        des
        aes-cbc-essiv:sha256
@@ -19,7 +22,11 @@ Parameters: <cipher> <key> <iv_offset> <device path> \
 
 <key>
     Key used for encryption. It is encoded as a hexadecimal number.
-    You can only use key sizes that are valid for the selected cipher.
+    You can only use key sizes that are valid for the selected cipher
+    in combination with the selected iv mode.
+    Note that for some iv modes the key string can contain additional
+    keys (for example IV seed) so the key contains more parts concatenated
+    into a single string.
 
 <keycount>
     Multi-key compatibility mode. You can define <keycount> keys and
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 23721d3be3e6..80b72419ffd8 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -414,6 +414,7 @@ Your cooperation is appreciated.
                 200 = /dev/net/tun      TAP/TUN network device
                 201 = /dev/button/gulpb Transmeta GULP-B buttons
                 202 = /dev/emd/ctl      Enhanced Metadisk RAID (EMD) control
+                203 = /dev/cuse         Cuse (character device in user-space)
                 204 = /dev/video/em8300         EM8300 DVD decoder control
                 205 = /dev/video/em8300_mv      EM8300 DVD decoder video
                 206 = /dev/video/em8300_ma      EM8300 DVD decoder audio
diff --git a/Documentation/devicetree/bindings/arc/pmu.txt b/Documentation/devicetree/bindings/arc/pmu.txt
new file mode 100644
index 000000000000..49d517340de3
--- /dev/null
+++ b/Documentation/devicetree/bindings/arc/pmu.txt
@@ -0,0 +1,24 @@
+* ARC Performance Monitor Unit
+
+The ARC 700 can be configured with a pipeline performance monitor for counting
+CPU and cache events like cache misses and hits.
+
+Note that:
+ * ARC 700 refers to a family of ARC processor cores;
+   - There is only one type of PMU available for the whole family;
+   - The PMU may support different sets of events; supported events are probed
+     at boot time, as required by the reference manual.
+
+ * The ARC 700 PMU does not support interrupts; although HW events may be
+   counted, the HW events themselves cannot serve as a trigger for a sample.
+
+Required properties:
+
+- compatible : should contain
+        "snps,arc700-pmu"
+
+Example:
+
+pmu {
+        compatible = "snps,arc700-pmu";
+};
diff --git a/Documentation/devicetree/bindings/arm/arm-boards b/Documentation/devicetree/bindings/arm/arm-boards
index db5858e32d3f..5fac246a9530 100644
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -9,9 +9,53 @@ Required properties (in root node):
 
 FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
 
-In the root node the Integrator/CP must have a /cpcon node pointing
-to the CP control registers, and the Integrator/AP must have a
-/syscon node pointing to the Integrator/AP system controller.
+Required nodes:
+
+- core-module: the root node to the Integrator platforms must have
+  a core-module with regs and the compatible string
+  "arm,core-module-integrator"
+
+  Required properties for the core module:
+  - regs: the location and size of the core module registers, one
+    range of 0x200 bytes.
+
+- syscon: the root node of the Integrator platforms must have a
+  system controller node pointong to the control registers,
+  with the compatible string
+  "arm,integrator-ap-syscon"
+  "arm,integrator-cp-syscon"
+  respectively.
+
+  Required properties for the system controller:
+  - regs: the location and size of the system controller registers,
+    one range of 0x100 bytes.
+
+  Required properties for the AP system controller:
+  - interrupts: the AP syscon node must include the logical module
+    interrupts, stated in order of module instance <module 0>,
+    <module 1>, <module 2> ... for the CP system controller this
+    is not required not of any use.
+
+/dts-v1/;
+/include/ "integrator.dtsi"
+
+/ {
+        model = "ARM Integrator/AP";
+        compatible = "arm,integrator-ap";
+
+        core-module@10000000 {
+                compatible = "arm,core-module-integrator";
+                reg = <0x10000000 0x200>;
+        };
+
+        syscon {
+                compatible = "arm,integrator-ap-syscon";
+                reg = <0x11000000 0x100>;
+                interrupt-parent = <&pic>;
+                /* These are the logic module IRQs */
+                interrupts = <9>, <10>, <11>, <12>;
+        };
+};
 
 
 ARM Versatile Application and Platform Baseboards
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 61df564c0d23..d74091a8a3bf 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -4,6 +4,8 @@ Marvell Armada 370 and Armada XP Interrupt Controller
 Required properties:
 - compatible: Should be "marvell,mpic"
 - interrupt-controller: Identifies the node as an interrupt controller.
+- msi-controller: Identifies the node as an PCI Message Signaled
+  Interrupt controller.
 - #interrupt-cells: The number of cells to define the interrupts. Should be 1.
   The cell is the IRQ number
 
@@ -24,6 +26,7 @@ Example:
               #address-cells = <1>;
               #size-cells = <1>;
               interrupt-controller;
+              msi-controller;
               reg = <0xd0020a00 0x1d0>,
                     <0xd0021070 0x58>;
         };
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/arm/atmel-adc.txt
index 723c205cb10d..d1061469f63d 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-adc.txt
@@ -7,7 +7,6 @@ Required properties:
   - interrupts: Should contain the IRQ line for the ADC
   - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this
     device
-  - atmel,adc-num-channels: Number of channels available in the ADC
   - atmel,adc-startup-time: Startup Time of the ADC in microseconds as
     defined in the datasheet
   - atmel,adc-vref: Reference voltage in millivolts for the conversions
@@ -24,6 +23,13 @@ Optional properties:
                        resolution will be used.
   - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
   - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
+  - atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this
+                        value is set, then adc driver will enable touch screen
+                        support.
+    NOTE: when adc touch screen enabled, the adc hardware trigger will be
+          disabled. Since touch screen will occupied the trigger register.
+  - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
+                                     make touch detect more precision.
  
 Optional trigger Nodes:
   - Required properties:
diff --git a/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt b/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
index f770ac0893d4..049675944b78 100644
--- a/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
+++ b/Documentation/devicetree/bindings/arm/calxeda/mem-ctrlr.txt
@@ -1,7 +1,9 @@
 Calxeda DDR memory controller
 
 Properties:
-- compatible : Should be "calxeda,hb-ddr-ctrl"
+- compatible : Should be:
+  - "calxeda,hb-ddr-ctrl" for ECX-1000
+  - "calxeda,ecx-2000-ddr-ctrl" for ECX-2000
 - reg : Address and size for DDR controller registers.
 - interrupts : Interrupt for DDR controller.
 
diff --git a/Documentation/devicetree/bindings/arm/cci.txt b/Documentation/devicetree/bindings/arm/cci.txt
index 92d36e2aa877..f28d82bbbc56 100644
--- a/Documentation/devicetree/bindings/arm/cci.txt
+++ b/Documentation/devicetree/bindings/arm/cci.txt
@@ -36,14 +36,18 @@ specific to ARM.
 
         - reg
                 Usage: required
-                Value type: <prop-encoded-array>
+                Value type: Integer cells. A register entry, expressed as a pair
+                            of cells, containing base and size.
                 Definition: A standard property. Specifies base physical
                             address of CCI control registers common to all
                             interfaces.
 
         - ranges:
                 Usage: required
-                Value type: <prop-encoded-array>
+                Value type: Integer cells. An array of range entries, expressed
+                            as a tuple of cells, containing child address,
+                            parent address and the size of the region in the
+                            child address space.
                 Definition: A standard property. Follow rules in the ePAPR for
                             hierarchical bus addressing. CCI interfaces
                             addresses refer to the parent node addressing
@@ -74,11 +78,49 @@ specific to ARM.
 
                 - reg:
                         Usage: required
-                        Value type: <prop-encoded-array>
+                        Value type: Integer cells. A register entry, expressed
+                                    as a pair of cells, containing base and
+                                    size.
                         Definition: the base address and size of the
                                     corresponding interface programming
                                     registers.
 
+        - CCI PMU node
+
+                Parent node must be CCI interconnect node.
+
+                A CCI pmu node must contain the following properties:
+
+                - compatible
+                        Usage: required
+                        Value type: <string>
+                        Definition: must be "arm,cci-400-pmu"
+
+                - reg:
+                        Usage: required
+                        Value type: Integer cells. A register entry, expressed
+                                    as a pair of cells, containing base and
+                                    size.
+                        Definition: the base address and size of the
+                                    corresponding interface programming
+                                    registers.
+
+                - interrupts:
+                        Usage: required
+                        Value type: Integer cells. Array of interrupt specifier
+                                    entries, as defined in
+                                    ../interrupt-controller/interrupts.txt.
+                        Definition: list of counter overflow interrupts, one per
+                                    counter. The interrupts must be specified
+                                    starting with the cycle counter overflow
+                                    interrupt, followed by counter0 overflow
+                                    interrupt, counter1 overflow interrupt,...
+                                    ,counterN overflow interrupt.
+
+                                    The CCI PMU has an interrupt signal for each
+                                    counter. The number of interrupts must be
+                                    equal to the number of counters.
+
 * CCI interconnect bus masters
 
         Description: masters in the device tree connected to a CCI port
@@ -144,7 +186,7 @@ Example:
                 #address-cells = <1>;
                 #size-cells = <1>;
                 reg = <0x0 0x2c090000 0 0x1000>;
-                ranges = <0x0 0x0 0x2c090000 0x6000>;
+                ranges = <0x0 0x0 0x2c090000 0x10000>;
 
                 cci_control0: slave-if@1000 {
                         compatible = "arm,cci-400-ctrl-if";
@@ -163,6 +205,16 @@ Example:
                         interface-type = "ace";
                         reg = <0x5000 0x1000>;
                 };
+
+                pmu@9000 {
+                         compatible = "arm,cci-400-pmu";
+                         reg = <0x9000 0x5000>;
+                         interrupts = <0 101 4>,
+                                      <0 102 4>,
+                                      <0 103 4>,
+                                      <0 104 4>,
+                                      <0 105 4>;
+                };
         };
 
 This CCI node corresponds to a CCI component whose control registers sits
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index f32494dbfe19..91304353eea4 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -1,77 +1,384 @@
-* ARM CPUs binding description
+=================
+ARM CPUs bindings
+=================
 
 The device tree allows to describe the layout of CPUs in a system through
 the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
 defining properties for every cpu.
 
-Bindings for CPU nodes follow the ePAPR standard, available from:
-
-http://devicetree.org
-
-For the ARM architecture every CPU node must contain the following properties:
-
-- device_type:  must be "cpu"
-- reg:          property matching the CPU MPIDR[23:0] register bits
-                reg[31:24] bits must be set to 0
-- compatible:   should be one of:
-                "arm,arm1020"
-                "arm,arm1020e"
-                "arm,arm1022"
-                "arm,arm1026"
-                "arm,arm720"
-                "arm,arm740"
-                "arm,arm7tdmi"
-                "arm,arm920"
-                "arm,arm922"
-                "arm,arm925"
-                "arm,arm926"
-                "arm,arm940"
-                "arm,arm946"
-                "arm,arm9tdmi"
-                "arm,cortex-a5"
-                "arm,cortex-a7"
-                "arm,cortex-a8"
-                "arm,cortex-a9"
-                "arm,cortex-a15"
-                "arm,arm1136"
-                "arm,arm1156"
-                "arm,arm1176"
-                "arm,arm11mpcore"
-                "faraday,fa526"
-                "intel,sa110"
-                "intel,sa1100"
-                "marvell,feroceon"
-                "marvell,mohawk"
-                "marvell,xsc3"
-                "marvell,xscale"
-
-Example:
+Bindings for CPU nodes follow the ePAPR v1.1 standard, available from:
+
+https://www.power.org/documentation/epapr-version-1-1/
+
+with updates for 32-bit and 64-bit ARM systems provided in this document.
+
+================================
+Convention used in this document
+================================
+
+This document follows the conventions described in the ePAPR v1.1, with
+the addition:
+
+- square brackets define bitfields, eg reg[7:0] value of the bitfield in
+  the reg property contained in bits 7 down to 0
+
+=====================================
+cpus and cpu node bindings definition
+=====================================
+
+The ARM architecture, in accordance with the ePAPR, requires the cpus and cpu
+nodes to be present and contain the properties described below.
+
+- cpus node
+
+        Description: Container of cpu nodes
+
+        The node name must be "cpus".
+
+        A cpus node must define the following properties:
+
+        - #address-cells
+                Usage: required
+                Value type: <u32>
+
+                Definition depends on ARM architecture version and
+                configuration:
+
+                        # On uniprocessor ARM architectures previous to v7
+                          value must be 1, to enable a simple enumeration
+                          scheme for processors that do not have a HW CPU
+                          identification register.
+                        # On 32-bit ARM 11 MPcore, ARM v7 or later systems
+                          value must be 1, that corresponds to CPUID/MPIDR
+                          registers sizes.
+                        # On ARM v8 64-bit systems value should be set to 2,
+                          that corresponds to the MPIDR_EL1 register size.
+                          If MPIDR_EL1[63:32] value is equal to 0 on all CPUs
+                          in the system, #address-cells can be set to 1, since
+                          MPIDR_EL1[63:32] bits are not used for CPUs
+                          identification.
+        - #size-cells
+                Usage: required
+                Value type: <u32>
+                Definition: must be set to 0
+
+- cpu node
+
+        Description: Describes a CPU in an ARM based system
+
+        PROPERTIES
+
+        - device_type
+                Usage: required
+                Value type: <string>
+                Definition: must be "cpu"
+        - reg
+                Usage and definition depend on ARM architecture version and
+                configuration:
+
+                        # On uniprocessor ARM architectures previous to v7
+                          this property is required and must be set to 0.
+
+                        # On ARM 11 MPcore based systems this property is
+                          required and matches the CPUID[11:0] register bits.
+
+                          Bits [11:0] in the reg cell must be set to
+                          bits [11:0] in CPU ID register.
+
+                          All other bits in the reg cell must be set to 0.
+
+                        # On 32-bit ARM v7 or later systems this property is
+                          required and matches the CPU MPIDR[23:0] register
+                          bits.
+
+                          Bits [23:0] in the reg cell must be set to
+                          bits [23:0] in MPIDR.
+
+                          All other bits in the reg cell must be set to 0.
+
+                        # On ARM v8 64-bit systems this property is required
+                          and matches the MPIDR_EL1 register affinity bits.
+
+                          * If cpus node's #address-cells property is set to 2
+
+                            The first reg cell bits [7:0] must be set to
+                            bits [39:32] of MPIDR_EL1.
+
+                            The second reg cell bits [23:0] must be set to
+                            bits [23:0] of MPIDR_EL1.
+
+                          * If cpus node's #address-cells property is set to 1
+
+                            The reg cell bits [23:0] must be set to bits [23:0]
+                            of MPIDR_EL1.
+
+                          All other bits in the reg cells must be set to 0.
+
+        - compatible:
+                Usage: required
+                Value type: <string>
+                Definition: should be one of:
+                            "arm,arm710t"
+                            "arm,arm720t"
+                            "arm,arm740t"
+                            "arm,arm7ej-s"
+                            "arm,arm7tdmi"
+                            "arm,arm7tdmi-s"
+                            "arm,arm9es"
+                            "arm,arm9ej-s"
+                            "arm,arm920t"
+                            "arm,arm922t"
+                            "arm,arm925"
+                            "arm,arm926e-s"
+                            "arm,arm926ej-s"
+                            "arm,arm940t"
+                            "arm,arm946e-s"
+                            "arm,arm966e-s"
+                            "arm,arm968e-s"
+                            "arm,arm9tdmi"
+                            "arm,arm1020e"
+                            "arm,arm1020t"
+                            "arm,arm1022e"
+                            "arm,arm1026ej-s"
+                            "arm,arm1136j-s"
+                            "arm,arm1136jf-s"
+                            "arm,arm1156t2-s"
+                            "arm,arm1156t2f-s"
+                            "arm,arm1176jzf"
+                            "arm,arm1176jz-s"
+                            "arm,arm1176jzf-s"
+                            "arm,arm11mpcore"
+                            "arm,cortex-a5"
+                            "arm,cortex-a7"
+                            "arm,cortex-a8"
+                            "arm,cortex-a9"
+                            "arm,cortex-a15"
+                            "arm,cortex-a53"
+                            "arm,cortex-a57"
+                            "arm,cortex-m0"
+                            "arm,cortex-m0+"
+                            "arm,cortex-m1"
+                            "arm,cortex-m3"
+                            "arm,cortex-m4"
+                            "arm,cortex-r4"
+                            "arm,cortex-r5"
+                            "arm,cortex-r7"
+                            "faraday,fa526"
+                            "intel,sa110"
+                            "intel,sa1100"
+                            "marvell,feroceon"
+                            "marvell,mohawk"
+                            "marvell,pj4a"
+                            "marvell,pj4b"
+                            "marvell,sheeva-v5"
+                            "qcom,krait"
+                            "qcom,scorpion"
+        - enable-method
+                Value type: <stringlist>
+                Usage and definition depend on ARM architecture version.
+                        # On ARM v8 64-bit this property is required and must
+                          be one of:
+                             "spin-table"
+                             "psci"
+                        # On ARM 32-bit systems this property is optional.
+
+        - cpu-release-addr
+                Usage: required for systems that have an "enable-method"
+                       property value of "spin-table".
+                Value type: <prop-encoded-array>
+                Definition:
+                        # On ARM v8 64-bit systems must be a two cell
+                          property identifying a 64-bit zero-initialised
+                          memory location.
+
+Example 1 (dual-cluster big.LITTLE system 32-bit):
 
         cpus {
                 #size-cells = <0>;
                 #address-cells = <1>;
 
-                CPU0: cpu@0 {
+                cpu@0 {
                         device_type = "cpu";
                         compatible = "arm,cortex-a15";
                         reg = <0x0>;
                 };
 
-                CPU1: cpu@1 {
+                cpu@1 {
                         device_type = "cpu";
                         compatible = "arm,cortex-a15";
                         reg = <0x1>;
                 };
 
-                CPU2: cpu@100 {
+                cpu@100 {
                         device_type = "cpu";
                         compatible = "arm,cortex-a7";
                         reg = <0x100>;
                 };
 
-                CPU3: cpu@101 {
+                cpu@101 {
                         device_type = "cpu";
                         compatible = "arm,cortex-a7";
                         reg = <0x101>;
                 };
         };
+
+Example 2 (Cortex-A8 uniprocessor 32-bit system):
+
+        cpus {
+                #size-cells = <0>;
+                #address-cells = <1>;
+
+                cpu@0 {
+                        device_type = "cpu";
+                        compatible = "arm,cortex-a8";
+                        reg = <0x0>;
+                };
+        };
+
+Example 3 (ARM 926EJ-S uniprocessor 32-bit system):
+
+        cpus {
+                #size-cells = <0>;
+                #address-cells = <1>;
+
+                cpu@0 {
+                        device_type = "cpu";
+                        compatible = "arm,arm926ej-s";
+                        reg = <0x0>;
+                };
+        };
+
+Example 4 (ARM Cortex-A57 64-bit system):
+
+cpus {
+        #size-cells = <0>;
+        #address-cells = <2>;
+
+        cpu@0 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x0>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@1 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x1>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@10000 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10000>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@10001 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10001>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@10100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@10101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100000000 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x0>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100000001 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x1>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100000100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100000101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100010000 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10000>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100010001 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10001>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100010100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        cpu@100010101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index 91b7049affa1..808c1543b0f8 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -21,7 +21,8 @@ Required properties:
 Optional properties:
 - ti,no_idle_on_suspend: When present, it prevents the PM to idle the module
   during suspend.
-
+- ti,no-reset-on-init: When present, the module should not be reset at init
+- ti,no-idle-on-init: When present, the module should not be idled at init
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/topology.txt b/Documentation/devicetree/bindings/arm/topology.txt
new file mode 100644
index 000000000000..4aa20e7a424e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/topology.txt
@@ -0,0 +1,474 @@
+===========================================
+ARM topology binding description
+===========================================
+
+===========================================
+1 - Introduction
+===========================================
+
+In an ARM system, the hierarchy of CPUs is defined through three entities that
+are used to describe the layout of physical CPUs in the system:
+
+- cluster
+- core
+- thread
+
+The cpu nodes (bindings defined in [1]) represent the devices that
+correspond to physical CPUs and are to be mapped to the hierarchy levels.
+
+The bottom hierarchy level sits at core or thread level depending on whether
+symmetric multi-threading (SMT) is supported or not.
+
+For instance in a system where CPUs support SMT, "cpu" nodes represent all
+threads existing in the system and map to the hierarchy level "thread" above.
+In systems where SMT is not supported "cpu" nodes represent all cores present
+in the system and map to the hierarchy level "core" above.
+
+ARM topology bindings allow one to associate cpu nodes with hierarchical groups
+corresponding to the system hierarchy; syntactically they are defined as device
+tree nodes.
+
+The remainder of this document provides the topology bindings for ARM, based
+on the ePAPR standard, available from:
+
+http://www.power.org/documentation/epapr-version-1-1/
+
+If not stated otherwise, whenever a reference to a cpu node phandle is made its
+value must point to a cpu node compliant with the cpu node bindings as
+documented in [1].
+A topology description containing phandles to cpu nodes that are not compliant
+with bindings standardized in [1] is therefore considered invalid.
+
+===========================================
+2 - cpu-map node
+===========================================
+
+The ARM CPU topology is defined within the cpu-map node, which is a direct
+child of the cpus node and provides a container where the actual topology
+nodes are listed.
+
+- cpu-map node
+
+        Usage: Optional - On ARM SMP systems provide CPUs topology to the OS.
+                          ARM uniprocessor systems do not require a topology
+                          description and therefore should not define a
+                          cpu-map node.
+
+        Description: The cpu-map node is just a container node where its
+                     subnodes describe the CPU topology.
+
+        Node name must be "cpu-map".
+
+        The cpu-map node's parent node must be the cpus node.
+
+        The cpu-map node's child nodes can be:
+
+        - one or more cluster nodes
+
+        Any other configuration is considered invalid.
+
+The cpu-map node can only contain three types of child nodes:
+
+- cluster node
+- core node
+- thread node
+
+whose bindings are described in paragraph 3.
+
+The nodes describing the CPU topology (cluster/core/thread) can only be
+defined within the cpu-map node.
+Any other configuration is consider invalid and therefore must be ignored.
+
+===========================================
+2.1 - cpu-map child nodes naming convention
+===========================================
+
+cpu-map child nodes must follow a naming convention where the node name
+must be "clusterN", "coreN", "threadN" depending on the node type (ie
+cluster/core/thread) (where N = {0, 1, ...} is the node number; nodes which
+are siblings within a single common parent node must be given a unique and
+sequential N value, starting from 0).
+cpu-map child nodes which do not share a common parent node can have the same
+name (ie same number N as other cpu-map child nodes at different device tree
+levels) since name uniqueness will be guaranteed by the device tree hierarchy.
+
+===========================================
+3 - cluster/core/thread node bindings
+===========================================
+
+Bindings for cluster/cpu/thread nodes are defined as follows:
+
+- cluster node
+
+         Description: must be declared within a cpu-map node, one node
+                      per cluster. A system can contain several layers of
+                      clustering and cluster nodes can be contained in parent
+                      cluster nodes.
+
+        The cluster node name must be "clusterN" as described in 2.1 above.
+        A cluster node can not be a leaf node.
+
+        A cluster node's child nodes must be:
+
+        - one or more cluster nodes; or
+        - one or more core nodes
+
+        Any other configuration is considered invalid.
+
+- core node
+
+        Description: must be declared in a cluster node, one node per core in
+                     the cluster. If the system does not support SMT, core
+                     nodes are leaf nodes, otherwise they become containers of
+                     thread nodes.
+
+        The core node name must be "coreN" as described in 2.1 above.
+
+        A core node must be a leaf node if SMT is not supported.
+
+        Properties for core nodes that are leaf nodes:
+
+        - cpu
+                Usage: required
+                Value type: <phandle>
+                Definition: a phandle to the cpu node that corresponds to the
+                            core node.
+
+        If a core node is not a leaf node (CPUs supporting SMT) a core node's
+        child nodes can be:
+
+        - one or more thread nodes
+
+        Any other configuration is considered invalid.
+
+- thread node
+
+        Description: must be declared in a core node, one node per thread
+                     in the core if the system supports SMT. Thread nodes are
+                     always leaf nodes in the device tree.
+
+        The thread node name must be "threadN" as described in 2.1 above.
+
+        A thread node must be a leaf node.
+
+        A thread node must contain the following property:
+
+        - cpu
+                Usage: required
+                Value type: <phandle>
+                Definition: a phandle to the cpu node that corresponds to
+                            the thread node.
+
+===========================================
+4 - Example dts
+===========================================
+
+Example 1 (ARM 64-bit, 16-cpu system, two clusters of clusters):
+
+cpus {
+        #size-cells = <0>;
+        #address-cells = <2>;
+
+        cpu-map {
+                cluster0 {
+                        cluster0 {
+                                core0 {
+                                        thread0 {
+                                                cpu = <&CPU0>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU1>;
+                                        };
+                                };
+
+                                core1 {
+                                        thread0 {
+                                                cpu = <&CPU2>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU3>;
+                                        };
+                                };
+                        };
+
+                        cluster1 {
+                                core0 {
+                                        thread0 {
+                                                cpu = <&CPU4>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU5>;
+                                        };
+                                };
+
+                                core1 {
+                                        thread0 {
+                                                cpu = <&CPU6>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU7>;
+                                        };
+                                };
+                        };
+                };
+
+                cluster1 {
+                        cluster0 {
+                                core0 {
+                                        thread0 {
+                                                cpu = <&CPU8>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU9>;
+                                        };
+                                };
+                                core1 {
+                                        thread0 {
+                                                cpu = <&CPU10>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU11>;
+                                        };
+                                };
+                        };
+
+                        cluster1 {
+                                core0 {
+                                        thread0 {
+                                                cpu = <&CPU12>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU13>;
+                                        };
+                                };
+                                core1 {
+                                        thread0 {
+                                                cpu = <&CPU14>;
+                                        };
+                                        thread1 {
+                                                cpu = <&CPU15>;
+                                        };
+                                };
+                        };
+                };
+        };
+
+        CPU0: cpu@0 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x0>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU1: cpu@1 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x1>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU2: cpu@100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU3: cpu@101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU4: cpu@10000 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10000>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU5: cpu@10001 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10001>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU6: cpu@10100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU7: cpu@10101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x0 0x10101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU8: cpu@100000000 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x0>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU9: cpu@100000001 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x1>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU10: cpu@100000100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU11: cpu@100000101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU12: cpu@100010000 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10000>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU13: cpu@100010001 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10001>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU14: cpu@100010100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10100>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+
+        CPU15: cpu@100010101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a57";
+                reg = <0x1 0x10101>;
+                enable-method = "spin-table";
+                cpu-release-addr = <0 0x20000000>;
+        };
+};
+
+Example 2 (ARM 32-bit, dual-cluster, 8-cpu system, no SMT):
+
+cpus {
+        #size-cells = <0>;
+        #address-cells = <1>;
+
+        cpu-map {
+                cluster0 {
+                        core0 {
+                                cpu = <&CPU0>;
+                        };
+                        core1 {
+                                cpu = <&CPU1>;
+                        };
+                        core2 {
+                                cpu = <&CPU2>;
+                        };
+                        core3 {
+                                cpu = <&CPU3>;
+                        };
+                };
+
+                cluster1 {
+                        core0 {
+                                cpu = <&CPU4>;
+                        };
+                        core1 {
+                                cpu = <&CPU5>;
+                        };
+                        core2 {
+                                cpu = <&CPU6>;
+                        };
+                        core3 {
+                                cpu = <&CPU7>;
+                        };
+                };
+        };
+
+        CPU0: cpu@0 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a15";
+                reg = <0x0>;
+        };
+
+        CPU1: cpu@1 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a15";
+                reg = <0x1>;
+        };
+
+        CPU2: cpu@2 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a15";
+                reg = <0x2>;
+        };
+
+        CPU3: cpu@3 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a15";
+                reg = <0x3>;
+        };
+
+        CPU4: cpu@100 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a7";
+                reg = <0x100>;
+        };
+
+        CPU5: cpu@101 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a7";
+                reg = <0x101>;
+        };
+
+        CPU6: cpu@102 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a7";
+                reg = <0x102>;
+        };
+
+        CPU7: cpu@103 {
+                device_type = "cpu";
+                compatible = "arm,cortex-a7";
+                reg = <0x103>;
+        };
+};
+
+===============================================================================
+[1] ARM Linux kernel documentation
+    Documentation/devicetree/bindings/arm/cpus.txt
diff --git a/Documentation/devicetree/bindings/arm/vic.txt b/Documentation/devicetree/bindings/arm/vic.txt
index 266716b23437..dd527216c5fb 100644
--- a/Documentation/devicetree/bindings/arm/vic.txt
+++ b/Documentation/devicetree/bindings/arm/vic.txt
@@ -18,6 +18,15 @@ Required properties:
 Optional properties:
 
 - interrupts : Interrupt source for parent controllers if the VIC is nested.
+- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit
+  represents single interrupt source, starting from source 0 at LSb and ending
+  at source 31 at MSb. A bit that is set means that the source is wired and
+  clear means otherwise. If unspecified, defaults to all valid.
+- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be
+  configured as wake up source for the system. Order of bits is the same as for
+  valid-mask property. A set bit means that this interrupt source can be
+  configured as a wake up source for the system. If unspecied, defaults to all
+  interrupt sources configurable as wake up sources.
 
 Example:
 
@@ -26,4 +35,7 @@ Example:
                 interrupt-controller;
                 #interrupt-cells = <1>;
                 reg = <0x60000 0x1000>;
+
+                valid-mask = <0xffffff7f>;
+                valid-wakeup-mask = <0x0000ff7f>;
         };
diff --git a/Documentation/devicetree/bindings/clock/efm32-clock.txt b/Documentation/devicetree/bindings/clock/efm32-clock.txt
new file mode 100644
index 000000000000..263d293f6a10
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/efm32-clock.txt
@@ -0,0 +1,11 @@
+* Clock bindings for Energy Micro efm32 Giant Gecko's Clock Management Unit
+
+Required properties:
+- compatible: Should be "efm32gg,cmu"
+- reg: Base address and length of the register set
+- interrupts: Interrupt used by the CMU
+- #clock-cells: Should be <1>
+
+The clock consumer should specify the desired clock by having the clock ID in
+its "clocks" phandle cell. The header efm32-clk.h contains a list of available
+IDs.
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index 5a90a724b520..6aab72bf67ea 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -215,6 +215,11 @@ clocks and IDs.
         cko2                    200
         cko                     201
         vdoa                    202
+        pll4_audio_div          203
+        lvds1_sel               204
+        lvds2_sel               205
+        lvds1_gate              206
+        lvds2_gate              207
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/clock/keystone-gate.txt b/Documentation/devicetree/bindings/clock/keystone-gate.txt
new file mode 100644
index 000000000000..c5aa187026e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/keystone-gate.txt
@@ -0,0 +1,29 @@
+Status: Unstable - ABI compatibility may be broken in the future
+
+Binding for Keystone gate control driver which uses PSC controller IP.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be "ti,keystone,psc-clock".
+- #clock-cells : from common clock binding; shall be set to 0.
+- clocks : parent clock phandle
+- reg : psc control and domain address address space
+- reg-names : psc control and domain registers
+- domain-id : psc domain id needed to check the transition state register
+
+Optional properties:
+- clock-output-names : From common clock binding to override the
+                        default output clock name
+Example:
+        clkusb: clkusb {
+                #clock-cells = <0>;
+                compatible = "ti,keystone,psc-clock";
+                clocks = <&chipclk16>;
+                clock-output-names = "usb";
+                reg = <0x02350008 0xb00>, <0x02350000 0x400>;
+                reg-names = "control", "domain";
+                domain-id = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/keystone-pll.txt b/Documentation/devicetree/bindings/clock/keystone-pll.txt
new file mode 100644
index 000000000000..12bd72605a31
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/keystone-pll.txt
@@ -0,0 +1,84 @@
+Status: Unstable - ABI compatibility may be broken in the future
+
+Binding for keystone PLLs. The main PLL IP typically has a multiplier,
+a divider and a post divider. The additional PLL IPs like ARMPLL, DDRPLL
+and PAPLL are controlled by the memory mapped register where as the Main
+PLL is controlled by a PLL controller registers along with memory mapped
+registers.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- #clock-cells : from common clock binding; shall be set to 0.
+- compatible : shall be "ti,keystone,main-pll-clock" or "ti,keystone,pll-clock"
+- clocks : parent clock phandle
+- reg - pll control0 and pll multipler registers
+- reg-names : control and multiplier. The multiplier is applicable only for
+                main pll clock
+- fixed-postdiv : fixed post divider value
+
+Example:
+        mainpllclk: mainpllclk@2310110 {
+                #clock-cells = <0>;
+                compatible = "ti,keystone,main-pll-clock";
+                clocks = <&refclkmain>;
+                reg = <0x02620350 4>, <0x02310110 4>;
+                reg-names = "control", "multiplier";
+                fixed-postdiv = <2>;
+        };
+
+        papllclk: papllclk@2620358 {
+                #clock-cells = <0>;
+                compatible = "ti,keystone,pll-clock";
+                clocks = <&refclkmain>;
+                clock-output-names = "pa-pll-clk";
+                reg = <0x02620358 4>;
+                reg-names = "control";
+                fixed-postdiv = <6>;
+        };
+
+Required properties:
+- #clock-cells : from common clock binding; shall be set to 0.
+- compatible : shall be "ti,keystone,pll-mux-clock"
+- clocks : link phandles of parent clocks
+- reg - pll mux register
+- bit-shift : number of bits to shift the bit-mask
+- bit-mask : arbitrary bitmask for programming the mux
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+        mainmuxclk: mainmuxclk@2310108 {
+                #clock-cells = <0>;
+                compatible = "ti,keystone,pll-mux-clock";
+                clocks = <&mainpllclk>, <&refclkmain>;
+                reg = <0x02310108 4>;
+                bit-shift = <23>;
+                bit-mask = <1>;
+                clock-output-names = "mainmuxclk";
+        };
+
+Required properties:
+- #clock-cells : from common clock binding; shall be set to 0.
+- compatible : shall be "ti,keystone,pll-divider-clock"
+- clocks : parent clock phandle
+- reg - pll mux register
+- bit-shift : number of bits to shift the bit-mask
+- bit-mask : arbitrary bitmask for programming the divider
+
+Optional properties:
+- clock-output-names : From common clock binding.
+
+Example:
+        gemtraceclk: gemtraceclk@2310120 {
+                #clock-cells = <0>;
+                compatible = "ti,keystone,pll-divider-clock";
+                clocks = <&mainmuxclk>;
+                reg = <0x02310120 4>;
+                bit-shift = <0>;
+                bit-mask = <8>;
+                clock-output-names = "gemtraceclk";
+        };
diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
new file mode 100644
index 000000000000..c62391fc0e39
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
@@ -0,0 +1,19 @@
+* Core Divider Clock bindings for Marvell MVEBU SoCs
+
+The following is a list of provided IDs and clock names on Armada 370/XP:
+ 0 = nand (NAND clock)
+
+Required properties:
+- compatible : must be "marvell,armada-370-corediv-clock"
+- reg : must be the register address of Core Divider control register
+- #clock-cells : from common clock binding; shall be set to 1
+- clocks : must be set to the parent's phandle
+
+Example:
+
+corediv_clk: corediv-clocks@18740 {
+        compatible = "marvell,armada-370-corediv-clock";
+        reg = <0x18740 0xc>;
+        #clock-cells = <1>;
+        clocks = <&pll>;
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
index cffc93d97f54..fc2910fa7e45 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
@@ -1,10 +1,10 @@
-* Gated Clock bindings for Marvell Orion SoCs
+* Gated Clock bindings for Marvell EBU SoCs
 
-Marvell Dove and Kirkwood allow some peripheral clocks to be gated to save
-some power. The clock consumer should specify the desired clock by having
-the clock ID in its "clocks" phandle cell. The clock ID is directly mapped to
-the corresponding clock gating control bit in HW to ease manual clock lookup
-in datasheet.
+Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be
+gated to save some power. The clock consumer should specify the desired clock
+by having the clock ID in its "clocks" phandle cell. The clock ID is directly
+mapped to the corresponding clock gating control bit in HW to ease manual clock
+lookup in datasheet.
 
 The following is a list of provided IDs for Armada 370:
 ID      Clock   Peripheral
@@ -94,6 +94,8 @@ ID	Clock	Peripheral
 
 Required properties:
 - compatible : shall be one of the following:
+        "marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
+        "marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
         "marvell,dove-gating-clock" - for Dove SoC clock gating
         "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
 - reg : shall be the register address of the Clock Gating Control register
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index 00a5c26454eb..91a748fed13d 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -45,8 +45,8 @@ Additionally, "allwinner,*-gates-clk" clocks require:
 
 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.
+provide an additional ID in their clock property. This ID is the
+offset of the bit controlling this particular gate in the register.
 
 For example:
 
diff --git a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
deleted file mode 100644
index 6a03475bbfe2..000000000000
--- a/Documentation/devicetree/bindings/clock/sunxi/sun4i-a10-gates.txt
+++ /dev/null
@@ -1,93 +0,0 @@
-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-a10s-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun5i-a10s-gates.txt
deleted file mode 100644
index d24279fe1429..000000000000
--- a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a10s-gates.txt
+++ /dev/null
@@ -1,75 +0,0 @@
-Gate clock outputs
-------------------
-
-  * AXI gates ("allwinner,sun4i-axi-gates-clk")
-
-    DRAM                                        0
-
-  * AHB gates ("allwinner,sun5i-a10s-ahb-gates-clk")
-
-    USB0                                        0
-    EHCI0                                       1
-    OHCI0                                       2
-
-    SS                                          5
-    DMA                                         6
-    BIST                                        7
-    MMC0                                        8
-    MMC1                                        9
-    MMC2                                        10
-
-    NAND                                        13
-    SDRAM                                       14
-
-    EMAC                                        17
-    TS                                          18
-
-    SPI0                                        20
-    SPI1                                        21
-    SPI2                                        22
-
-    GPS                                         26
-
-    HSTIMER                                     28
-
-    VE                                          32
-
-    TVE                                         34
-
-    LCD                                         36
-
-    CSI                                         40
-
-    HDMI                                        43
-    DE_BE                                       44
-
-    DE_FE                                       46
-
-    IEP                                         51
-    MALI400                                     52
-
-  * APB0 gates ("allwinner,sun5i-a10s-apb0-gates-clk")
-
-    CODEC                                       0
-
-    IIS                                         3
-
-    PIO                                         5
-    IR                                          6
-
-    KEYPAD                                      10
-
-  * APB1 gates ("allwinner,sun5i-a10s-apb1-gates-clk")
-
-    I2C0                                        0
-    I2C1                                        1
-    I2C2                                        2
-
-    UART0                                       16
-    UART1                                       17
-    UART2                                       18
-    UART3                                       19
-
-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
deleted file mode 100644
index 006b6dfc4703..000000000000
--- a/Documentation/devicetree/bindings/clock/sunxi/sun5i-a13-gates.txt
+++ /dev/null
@@ -1,58 +0,0 @@
-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/sunxi/sun6i-a31-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
deleted file mode 100644
index fe44932b5c6b..000000000000
--- a/Documentation/devicetree/bindings/clock/sunxi/sun6i-a31-gates.txt
+++ /dev/null
@@ -1,83 +0,0 @@
-Gate clock outputs
-------------------
-
-  * AHB1 gates ("allwinner,sun6i-a31-ahb1-gates-clk")
-
-    MIPI DSI                                    1
-
-    SS                                          5
-    DMA                                         6
-
-    MMC0                                        8
-    MMC1                                        9
-    MMC2                                        10
-    MMC3                                        11
-
-    NAND1                                       12
-    NAND0                                       13
-    SDRAM                                       14
-
-    GMAC                                        17
-    TS                                          18
-    HSTIMER                                     19
-    SPI0                                        20
-    SPI1                                        21
-    SPI2                                        22
-    SPI3                                        23
-    USB_OTG                                     24
-
-    EHCI0                                       26
-    EHCI1                                       27
-
-    OHCI0                                       29
-    OHCI1                                       30
-    OHCI2                                       31
-    VE                                          32
-
-    LCD0                                        36
-    LCD1                                        37
-
-    CSI                                         40
-
-    HDMI                                        43
-    DE_BE0                                      44
-    DE_BE1                                      45
-    DE_FE1                                      46
-    DE_FE1                                      47
-
-    MP                                          50
-
-    GPU                                         52
-
-    DEU0                                        55
-    DEU1                                        56
-    DRC0                                        57
-    DRC1                                        58
-
-  * APB1 gates ("allwinner,sun6i-a31-apb1-gates-clk")
-
-    CODEC                                       0
-
-    DIGITAL MIC                                 4
-    PIO                                         5
-
-    DAUDIO0                                     12
-    DAUDIO1                                     13
-
-  * APB2 gates ("allwinner,sun6i-a31-apb2-gates-clk")
-
-    I2C0                                        0
-    I2C1                                        1
-    I2C2                                        2
-    I2C3                                        3
-
-    UART0                                       16
-    UART1                                       17
-    UART2                                       18
-    UART3                                       19
-    UART4                                       20
-    UART5                                       21
-
-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/sun7i-a20-gates.txt b/Documentation/devicetree/bindings/clock/sunxi/sun7i-a20-gates.txt
deleted file mode 100644
index 357f4fdc02ef..000000000000
--- a/Documentation/devicetree/bindings/clock/sunxi/sun7i-a20-gates.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-Gate clock outputs
-------------------
-
-  * AXI gates ("allwinner,sun4i-axi-gates-clk")
-
-    DRAM                                        0
-
-  * AHB gates ("allwinner,sun7i-a20-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
-
-    SATA                                        25
-
-    HSTIMER                                     28
-
-    VE                                          32
-    TVD                                         33
-    TVE0                                        34
-    TVE1                                        35
-    LCD0                                        36
-    LCD1                                        37
-
-    CSI0                                        40
-    CSI1                                        41
-
-    HDMI1                                       42
-    HDMI0                                       43
-    DE_BE0                                      44
-    DE_BE1                                      45
-    DE_FE1                                      46
-    DE_FE1                                      47
-
-    GMAC                                        49
-    MP                                          50
-
-    MALI400                                     52
-
-  * APB0 gates ("allwinner,sun7i-a20-apb0-gates-clk")
-
-    CODEC                                       0
-    SPDIF                                       1
-    AC97                                        2
-    IIS0                                        3
-    IIS1                                        4
-    PIO                                         5
-    IR0                                         6
-    IR1                                         7
-    IIS2                                        8
-
-    KEYPAD                                      10
-
-  * APB1 gates ("allwinner,sun7i-a20-apb1-gates-clk")
-
-    I2C0                                        0
-    I2C1                                        1
-    I2C2                                        2
-    I2C3                                        3
-    CAN                                         4
-    SCR                                         5
-    PS20                                        6
-    PS21                                        7
-
-    I2C4                                        15
-    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/xgene.txt b/Documentation/devicetree/bindings/clock/xgene.txt
new file mode 100644
index 000000000000..1c4ef773feea
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/xgene.txt
@@ -0,0 +1,111 @@
+Device Tree Clock bindings for APM X-Gene
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be one of the following:
+        "apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
+        "apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
+        "apm,xgene-device-clock" - for a X-Gene device clock
+
+Required properties for SoC or PCP PLL clocks:
+- reg : shall be the physical PLL register address for the pll clock.
+- clocks : shall be the input parent clock phandle for the clock. This should
+        be the reference clock.
+- #clock-cells : shall be set to 1.
+- clock-output-names : shall be the name of the PLL referenced by derive
+  clock.
+Optional properties for PLL clocks:
+- clock-names : shall be the name of the PLL. If missing, use the device name.
+
+Required properties for device clocks:
+- reg : shall be a list of address and length pairs describing the CSR
+         reset and/or the divider. Either may be omitted, but at least
+         one must be present.
+ - reg-names : shall be a string list describing the reg resource. This
+               may include "csr-reg" and/or "div-reg". If this property
+               is not present, the reg property is assumed to describe
+               only "csr-reg".
+- clocks : shall be the input parent clock phandle for the clock.
+- #clock-cells : shall be set to 1.
+- clock-output-names : shall be the name of the device referenced.
+Optional properties for device clocks:
+- clock-names : shall be the name of the device clock. If missing, use the
+                device name.
+- csr-offset : Offset to the CSR reset register from the reset address base.
+               Default is 0.
+- csr-mask : CSR reset mask bit. Default is 0xF.
+- enable-offset : Offset to the enable register from the reset address base.
+                  Default is 0x8.
+- enable-mask : CSR enable mask bit. Default is 0xF.
+- divider-offset : Offset to the divider CSR register from the divider base.
+                   Default is 0x0.
+- divider-width : Width of the divider register. Default is 0.
+- divider-shift : Bit shift of the divider register. Default is 0.
+
+For example:
+
+        pcppll: pcppll@17000100 {
+                compatible = "apm,xgene-pcppll-clock";
+                #clock-cells = <1>;
+                clocks = <&refclk 0>;
+                clock-names = "pcppll";
+                reg = <0x0 0x17000100 0x0 0x1000>;
+                clock-output-names = "pcppll";
+                type = <0>;
+        };
+
+        socpll: socpll@17000120 {
+                compatible = "apm,xgene-socpll-clock";
+                #clock-cells = <1>;
+                clocks = <&refclk 0>;
+                clock-names = "socpll";
+                reg = <0x0 0x17000120 0x0 0x1000>;
+                clock-output-names = "socpll";
+                type = <1>;
+        };
+
+        qmlclk: qmlclk {
+                compatible = "apm,xgene-device-clock";
+                #clock-cells = <1>;
+                clocks = <&socplldiv2 0>;
+                clock-names = "qmlclk";
+                reg = <0x0 0x1703C000 0x0 0x1000>;
+                reg-name = "csr-reg";
+                clock-output-names = "qmlclk";
+        };
+
+        ethclk: ethclk {
+                compatible = "apm,xgene-device-clock";
+                #clock-cells = <1>;
+                clocks = <&socplldiv2 0>;
+                clock-names = "ethclk";
+                reg = <0x0 0x17000000 0x0 0x1000>;
+                reg-names = "div-reg";
+                divider-offset = <0x238>;
+                divider-width = <0x9>;
+                divider-shift = <0x0>;
+                clock-output-names = "ethclk";
+        };
+
+        apbclk: apbclk {
+                compatible = "apm,xgene-device-clock";
+                #clock-cells = <1>;
+                clocks = <&ahbclk 0>;
+                clock-names = "apbclk";
+                reg = <0x0 0x1F2AC000 0x0 0x1000
+                        0x0 0x1F2AC000 0x0 0x1000>;
+                reg-names = "csr-reg", "div-reg";
+                csr-offset = <0x0>;
+                csr-mask = <0x200>;
+                enable-offset = <0x8>;
+                enable-mask = <0x200>;
+                divider-offset = <0x10>;
+                divider-width = <0x2>;
+                divider-shift = <0x0>;
+                flags = <0x8>;
+                clock-output-names = "apbclk";
+        };
+
diff --git a/Documentation/devicetree/bindings/crypto/omap-aes.txt b/Documentation/devicetree/bindings/crypto/omap-aes.txt
new file mode 100644
index 000000000000..fd9717653cbb
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-aes.txt
@@ -0,0 +1,31 @@
+OMAP SoC AES crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  AES versions:
+  - "ti,omap2-aes" for OMAP2.
+  - "ti,omap3-aes" for OMAP3.
+  - "ti,omap4-aes" for OMAP4 and AM33XX.
+  Note that the OMAP2 and 3 versions are compatible (OMAP3 supports
+  more algorithms) but they are incompatible with OMAP4.
+- ti,hwmods: Name of the hwmod associated with the AES module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the AES module.
+
+Optional properties:
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+        Documentation/devicetree/bindings/dma/dma.txt
+- dma-names: DMA request names should include "tx" and "rx" if present.
+
+Example:
+        /* AM335x */
+        aes: aes@53500000 {
+                compatible = "ti,omap4-aes";
+                ti,hwmods = "aes";
+                reg = <0x53500000 0xa0>;
+                interrupts = <102>;
+                dmas = <&edma 6>,
+                       <&edma 5>;
+                dma-names = "tx", "rx";
+        };
diff --git a/Documentation/devicetree/bindings/crypto/omap-des.txt b/Documentation/devicetree/bindings/crypto/omap-des.txt
new file mode 100644
index 000000000000..e8c63bf2e16d
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-des.txt
@@ -0,0 +1,30 @@
+OMAP SoC DES crypto Module
+
+Required properties:
+
+- compatible : Should contain "ti,omap4-des"
+- ti,hwmods: Name of the hwmod associated with the DES module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the DES module
+- clocks : A phandle to the functional clock node of the DES module
+           corresponding to each entry in clock-names
+- clock-names : Name of the functional clock, should be "fck"
+
+Optional properties:
+- dmas: DMA specifiers for tx and rx dma. See the DMA client binding,
+        Documentation/devicetree/bindings/dma/dma.txt
+        Each entry corresponds to an entry in dma-names
+- dma-names: DMA request names should include "tx" and "rx" if present
+
+Example:
+        /* DRA7xx SoC */
+        des: des@480a5000 {
+                compatible = "ti,omap4-des";
+                ti,hwmods = "des";
+                reg = <0x480a5000 0xa0>;
+                interrupts = <GIC_SPI 82 IRQ_TYPE_LEVEL_HIGH>;
+                dmas = <&sdma 117>, <&sdma 116>;
+                dma-names = "tx", "rx";
+                clocks = <&l3_iclk_div>;
+                clock-names = "fck";
+        };
diff --git a/Documentation/devicetree/bindings/crypto/omap-sham.txt b/Documentation/devicetree/bindings/crypto/omap-sham.txt
new file mode 100644
index 000000000000..ad9115569611
--- /dev/null
+++ b/Documentation/devicetree/bindings/crypto/omap-sham.txt
@@ -0,0 +1,28 @@
+OMAP SoC SHA crypto Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  SHAM versions:
+  - "ti,omap2-sham" for OMAP2 & OMAP3.
+  - "ti,omap4-sham" for OMAP4 and AM33XX.
+  - "ti,omap5-sham" for OMAP5, DRA7 and AM43XX.
+- ti,hwmods: Name of the hwmod associated with the SHAM module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt-specifier for the SHAM module.
+
+Optional properties:
+- dmas: DMA specifiers for the rx dma. See the DMA client binding,
+        Documentation/devicetree/bindings/dma/dma.txt
+- dma-names: DMA request name. Should be "rx" if a dma is present.
+
+Example:
+        /* AM335x */
+        sham: sham@53100000 {
+                compatible = "ti,omap4-sham";
+                ti,hwmods = "sham";
+                reg = <0x53100000 0x200>;
+                interrupts = <109>;
+                dmas = <&edma 36>;
+                dma-names = "rx";
+        };
diff --git a/Documentation/devicetree/bindings/dma/atmel-dma.txt b/Documentation/devicetree/bindings/dma/atmel-dma.txt
index e1f343c7a34b..f69bcf5a6343 100644
--- a/Documentation/devicetree/bindings/dma/atmel-dma.txt
+++ b/Documentation/devicetree/bindings/dma/atmel-dma.txt
@@ -28,7 +28,7 @@ The three cells in order are:
 dependent:
   - 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.
+  - bit 11-8: FIFO configuration. 0 for half FIFO, 1 for ALAP, 2 for ASAP.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt
new file mode 100644
index 000000000000..00611aceed3e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/abilis,tb10x-gpio.txt
@@ -0,0 +1,36 @@
+* Abilis TB10x GPIO controller
+
+Required Properties:
+- compatible: Should be "abilis,tb10x-gpio"
+- reg: Address and length of the register set for the device
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be <2>. The first cell is the pin number and the
+  second cell is used to specify optional parameters:
+   - bit 0 specifies polarity (0 for normal, 1 for inverted).
+- abilis,ngpio: the number of GPIO pins this driver controls.
+
+Optional Properties:
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be <1>. Interrupts are triggered on both edges.
+- interrupts: Defines the interrupt line connecting this GPIO controller to
+  its parent interrupt controller.
+- interrupt-parent: Defines the parent interrupt controller.
+
+GPIO ranges are specified as described in
+Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+
+        gpioa: gpio@FF140000 {
+                compatible = "abilis,tb10x-gpio";
+                interrupt-controller;
+                #interrupt-cells = <1>;
+                interrupt-parent = <&tb10x_ictl>;
+                interrupts = <27 2>;
+                reg = <0xFF140000 0x1000>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                abilis,ngpio = <3>;
+                gpio-ranges = <&iomux 0 0 0>;
+                gpio-ranges-group-names = "gpioa_pins";
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
new file mode 100644
index 000000000000..4a63bc96b687
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-bcm-kona.txt
@@ -0,0 +1,52 @@
+Broadcom Kona Family GPIO
+=========================
+
+This GPIO driver is used in the following Broadcom SoCs:
+  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155
+
+The Broadcom GPIO Controller IP can be configured prior to synthesis to
+support up to 8 banks of 32 GPIOs where each bank has its own IRQ. The
+GPIO controller only supports edge, not level, triggering of interrupts.
+
+Required properties
+-------------------
+
+- compatible: "brcm,bcm11351-gpio", "brcm,kona-gpio"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller. There is one GPIO
+  interrupt per GPIO bank. The number of interrupts listed depends on the
+  number of GPIO banks on the SoC. The interrupts must be ordered by bank,
+  starting with bank 0. There is always a 1:1 mapping between banks and
+  IRQs.
+- #gpio-cells: Should be <2>. The first cell is the pin number, the second
+  cell is used to specify optional parameters:
+  - bit 0 specifies polarity (0 for normal, 1 for inverted)
+  See also "gpio-specifier" in .../devicetree/bindings/gpio/gpio.txt.
+- #interrupt-cells: Should be <2>. The first cell is the GPIO number. The
+  second cell is used to specify flags. The following subset of flags is
+  supported:
+  - trigger type (bits[1:0]):
+      1 = low-to-high edge triggered.
+      2 = high-to-low edge triggered.
+      3 = low-to-high or high-to-low edge triggered
+      Valid values are 1, 2, 3
+  See also .../devicetree/bindings/interrupt-controller/interrupts.txt.
+- gpio-controller: Marks the device node as a GPIO controller.
+- interrupt-controller: Marks the device node as an interrupt controller.
+
+Example:
+        gpio: gpio@35003000 {
+                compatible = "brcm,bcm11351-gpio", "brcm,kona-gpio";
+                reg = <0x35003000 0x800>;
+                interrupts =
+                       <GIC_SPI 106 IRQ_TYPE_LEVEL_HIGH
+                        GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH
+                        GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH
+                        GIC_SPI 113 IRQ_TYPE_LEVEL_HIGH
+                        GIC_SPI 112 IRQ_TYPE_LEVEL_HIGH
+                        GIC_SPI 111 IRQ_TYPE_LEVEL_HIGH>;
+                #gpio-cells = <2>;
+                #interrupt-cells = <2>;
+                gpio-controller;
+                interrupt-controller;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
new file mode 100644
index 000000000000..d63194a2c848
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt
@@ -0,0 +1,71 @@
+* PCF857x-compatible I/O expanders
+
+The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be
+driven high by a pull-up current source or driven low to ground. This combines
+the direction and output level into a single bit per line, which can't be read
+back. We can't actually know at initialization time whether a line is configured
+(a) as output and driving the signal low/high, or (b) as input and reporting a
+low/high value, without knowing the last value written since the chip came out
+of reset (if any). The only reliable solution for setting up line direction is
+thus to do it explicitly.
+
+Required Properties:
+
+  - compatible: should be one of the following.
+    - "maxim,max7328": For the Maxim MAX7378
+    - "maxim,max7329": For the Maxim MAX7329
+    - "nxp,pca8574": For the NXP PCA8574
+    - "nxp,pca8575": For the NXP PCA8575
+    - "nxp,pca9670": For the NXP PCA9670
+    - "nxp,pca9671": For the NXP PCA9671
+    - "nxp,pca9672": For the NXP PCA9672
+    - "nxp,pca9673": For the NXP PCA9673
+    - "nxp,pca9674": For the NXP PCA9674
+    - "nxp,pca9675": For the NXP PCA9675
+    - "nxp,pcf8574": For the NXP PCF8574
+    - "nxp,pcf8574a": For the NXP PCF8574A
+    - "nxp,pcf8575": For the NXP PCF8575
+    - "ti,tca9554": For the TI TCA9554
+
+  - reg: I2C slave address.
+
+  - 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.
+
+Optional Properties:
+
+  - lines-initial-states: Bitmask that specifies the initial state of each
+  line. When a bit is set to zero, the corresponding line will be initialized to
+  the input (pulled-up) state. When the  bit is set to one, the line will be
+  initialized the the low-level output state. If the property is not specified
+  all lines will be initialized to the input state.
+
+  The I/O expander can detect input state changes, and thus optionally act as
+  an interrupt controller. When the expander interrupt line is connected all the
+  following properties must be set. For more information please see the
+  interrupt controller device tree bindings documentation available at
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt.
+
+  - interrupt-controller: Identifies the node as an interrupt controller.
+  - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2.
+  - interrupt-parent: phandle of the parent interrupt controller.
+  - interrupts: Interrupt specifier for the controllers interrupt.
+
+
+Please refer to gpio.txt in this directory for details of the common GPIO
+bindings used by client devices.
+
+Example: PCF8575 I/O expander node
+
+        pcf8575: gpio@20 {
+                compatible = "nxp,pcf8575";
+                reg = <0x20>;
+                interrupt-parent = <&irqpin2>;
+                interrupts = <3 0>;
+                gpio-controller;
+                #gpio-cells = <2>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 6cec6ff20d2e..0c85bb6e3a80 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -87,8 +87,10 @@ controllers. The gpio-ranges property described below represents this, and
 contains information structures as follows:
 
         gpio-range-list ::= <single-gpio-range> [gpio-range-list]
-        single-gpio-range ::=
+        single-gpio-range ::= <numeric-gpio-range> | <named-gpio-range>
+        numeric-gpio-range ::=
                         <pinctrl-phandle> <gpio-base> <pinctrl-base> <count>
+        named-gpio-range ::= <pinctrl-phandle> <gpio-base> '<0 0>'
         gpio-phandle : phandle to pin controller node.
         gpio-base : Base GPIO ID in the GPIO controller
         pinctrl-base : Base pinctrl pin ID in the pin controller
@@ -97,6 +99,19 @@ contains information structures as follows:
 The "pin controller node" mentioned above must conform to the bindings
 described in ../pinctrl/pinctrl-bindings.txt.
 
+In case named gpio ranges are used (ranges with both <pinctrl-base> and
+<count> set to 0), the property gpio-ranges-group-names contains one string
+for every single-gpio-range in gpio-ranges:
+        gpiorange-names-list ::= <gpiorange-name> [gpiorange-names-list]
+        gpiorange-name : Name of the pingroup associated to the GPIO range in
+                        the respective pin controller.
+
+Elements of gpiorange-names-list corresponding to numeric ranges contain
+the empty string. Elements of gpiorange-names-list corresponding to named
+ranges contain the name of a pin group defined in the respective pin
+controller. The number of pins/GPIOs in the range is the number of pins in
+that pin group.
+
 Previous versions of this binding required all pin controller nodes that
 were referenced by any gpio-ranges property to contain a property named
 #gpio-range-cells with value <3>. This requirement is now deprecated.
@@ -104,7 +119,7 @@ However, that property may still exist in older device trees for
 compatibility reasons, and would still be required even in new device
 trees that need to be compatible with older software.
 
-Example:
+Example 1:
 
         qe_pio_e: gpio-controller@1460 {
                 #gpio-cells = <2>;
@@ -117,3 +132,24 @@ Example:
 Here, a single GPIO controller has GPIOs 0..9 routed to pin controller
 pinctrl1's pins 20..29, and GPIOs 10..19 routed to pin controller pinctrl2's
 pins 50..59.
+
+Example 2:
+
+        gpio_pio_i: gpio-controller@14B0 {
+                #gpio-cells = <2>;
+                compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
+                reg = <0x1480 0x18>;
+                gpio-controller;
+                gpio-ranges =                   <&pinctrl1 0 20 10>,
+                                                <&pinctrl2 10 0 0>,
+                                                <&pinctrl1 15 0 10>,
+                                                <&pinctrl2 25 0 0>;
+                gpio-ranges-group-names =       "",
+                                                "foo",
+                                                "",
+                                                "bar";
+        };
+
+Here, three GPIO ranges are defined wrt. two pin controllers. pinctrl1 GPIO
+ranges are defined using pin numbers whereas the GPIO ranges wrt. pinctrl2
+are named "foo" and "bar".
diff --git a/Documentation/devicetree/bindings/hwmon/lm90.txt b/Documentation/devicetree/bindings/hwmon/lm90.txt
new file mode 100644
index 000000000000..e8632486b9ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/lm90.txt
@@ -0,0 +1,44 @@
+* LM90 series thermometer.
+
+Required node properties:
+- compatible: manufacturer and chip name, one of
+                "adi,adm1032"
+                "adi,adt7461"
+                "adi,adt7461a"
+                "gmt,g781"
+                "national,lm90"
+                "national,lm86"
+                "national,lm89"
+                "national,lm99"
+                "dallas,max6646"
+                "dallas,max6647"
+                "dallas,max6649"
+                "dallas,max6657"
+                "dallas,max6658"
+                "dallas,max6659"
+                "dallas,max6680"
+                "dallas,max6681"
+                "dallas,max6695"
+                "dallas,max6696"
+                "onnn,nct1008"
+                "winbond,w83l771"
+                "nxp,sa56004"
+
+- reg: I2C bus address of the device
+
+- vcc-supply: vcc regulator for the supply voltage.
+
+Optional properties:
+- interrupts: Contains a single interrupt specifier which describes the
+              LM90 "-ALERT" pin output.
+              See interrupt-controller/interrupts.txt for the format.
+
+Example LM90 node:
+
+temp-sensor {
+        compatible = "onnn,nct1008";
+        reg = <0x4c>;
+        vcc-supply = <&palmas_ldo6_reg>;
+        interrupt-parent = <&gpio>;
+        interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>;
+}
diff --git a/Documentation/devicetree/bindings/hwrng/omap_rng.txt b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
new file mode 100644
index 000000000000..6a62acd86953
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwrng/omap_rng.txt
@@ -0,0 +1,22 @@
+OMAP SoC HWRNG Module
+
+Required properties:
+
+- compatible : Should contain entries for this and backward compatible
+  RNG versions:
+  - "ti,omap2-rng" for OMAP2.
+  - "ti,omap4-rng" for OMAP4, OMAP5 and AM33XX.
+  Note that these two versions are incompatible.
+- ti,hwmods: Name of the hwmod associated with the RNG module
+- reg : Offset and length of the register set for the module
+- interrupts : the interrupt number for the RNG module.
+                Only used for "ti,omap4-rng".
+
+Example:
+/* AM335x */
+rng: rng@48310000 {
+        compatible = "ti,omap4-rng";
+        ti,hwmods = "rng";
+        reg = <0x48310000 0x2000>;
+        interrupts = <111>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-bcm-kona.txt b/Documentation/devicetree/bindings/i2c/i2c-bcm-kona.txt
new file mode 100644
index 000000000000..1b87b741fa8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-bcm-kona.txt
@@ -0,0 +1,35 @@
+Broadcom Kona Family I2C
+=========================
+
+This I2C controller is used in the following Broadcom SoCs:
+
+  BCM11130
+  BCM11140
+  BCM11351
+  BCM28145
+  BCM28155
+
+Required Properties
+-------------------
+- compatible: "brcm,bcm11351-i2c", "brcm,kona-i2c"
+- reg: Physical base address and length of controller registers
+- interrupts: The interrupt number used by the controller
+- clocks: clock specifier for the kona i2c external clock
+- clock-frequency: The I2C bus frequency in Hz
+- #address-cells: Should be <1>
+- #size-cells: Should be <0>
+
+Refer to clocks/clock-bindings.txt for generic clock consumer
+properties.
+
+Example:
+
+i2c@3e016000 {
+        compatible = "brcm,bcm11351-i2c","brcm,kona-i2c";
+        reg = <0x3e016000 0x80>;
+        interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_HIGH>;
+        clocks = <&bsc1_clk>;
+        clock-frequency = <400000>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
new file mode 100644
index 000000000000..056732cfdcee
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-exynos5.txt
@@ -0,0 +1,44 @@
+* Samsung's High Speed I2C controller
+
+The Samsung's High Speed I2C controller is used to interface with I2C devices
+at various speeds ranging from 100khz to 3.4Mhz.
+
+Required properties:
+  - compatible: value should be.
+      -> "samsung,exynos5-hsi2c", for i2c compatible with exynos5 hsi2c.
+  - reg: physical base address of the controller and length of memory mapped
+    region.
+  - interrupts: interrupt number to the cpu.
+  - #address-cells: always 1 (for i2c addresses)
+  - #size-cells: always 0
+
+  - Pinctrl:
+    - pinctrl-0: Pin control group to be used for this controller.
+    - pinctrl-names: Should contain only one value - "default".
+
+Optional properties:
+  - clock-frequency: Desired operating frequency in Hz of the bus.
+    -> If not specified, the bus operates in fast-speed mode at
+       at 100khz.
+    -> If specified, the bus operates in high-speed mode only if the
+       clock-frequency is >= 1Mhz.
+
+Example:
+
+hsi2c@12ca0000 {
+        compatible = "samsung,exynos5-hsi2c";
+        reg = <0x12ca0000 0x100>;
+        interrupts = <56>;
+        clock-frequency = <100000>;
+
+        pinctrl-0 = <&i2c4_bus>;
+        pinctrl-names = "default";
+
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        s2mps11_pmic@66 {
+                compatible = "samsung,s2mps11-pmic";
+                reg = <0x66>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-rcar.txt b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
new file mode 100644
index 000000000000..897cfcd5ce92
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-rcar.txt
@@ -0,0 +1,23 @@
+I2C for R-Car platforms
+
+Required properties:
+- compatible: Must be one of
+        "renesas,i2c-rcar"
+        "renesas,i2c-r8a7778"
+        "renesas,i2c-r8a7779"
+        "renesas,i2c-r8a7790"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: interrupt specifier.
+
+Optional properties:
+- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this
+  propoerty indicates the default frequency 100 kHz.
+
+Examples :
+
+i2c0: i2c@e6500000 {
+        compatible = "renesas,i2c-rcar-h2";
+        reg = <0 0xe6500000 0 0x428>;
+        interrupts = <0 174 0x4>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-st.txt b/Documentation/devicetree/bindings/i2c/i2c-st.txt
new file mode 100644
index 000000000000..437e0db3823c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-st.txt
@@ -0,0 +1,41 @@
+ST SSC binding, for I2C mode operation
+
+Required properties :
+- compatible : Must be "st,comms-ssc-i2c" or "st,comms-ssc4-i2c"
+- reg : Offset and length of the register set for the device
+- interrupts : the interrupt specifier
+- clock-names: Must contain "ssc".
+- clocks: Must contain an entry for each name in clock-names. See the common
+  clock bindings.
+- A pinctrl state named "default" must be defined to set pins in mode of
+  operation for I2C transfer.
+
+Optional properties :
+- clock-frequency : Desired I2C bus clock frequency in Hz. If not specified,
+  the default 100 kHz frequency will be used. As only Normal and Fast modes
+  are supported, possible values are 100000 and 400000.
+- st,i2c-min-scl-pulse-width-us : The minimum valid SCL pulse width that is
+  allowed through the deglitch circuit. In units of us.
+- st,i2c-min-sda-pulse-width-us : The minimum valid SDA pulse width that is
+  allowed through the deglitch circuit. In units of us.
+- A pinctrl state named "idle" could be defined to set pins in idle state
+  when I2C instance is not performing a transfer.
+- A pinctrl state named "sleep" could be defined to set pins in sleep state
+  when driver enters in suspend.
+
+
+
+Example :
+
+i2c0: i2c@fed40000 {
+        compatible      = "st,comms-ssc4-i2c";
+        reg             = <0xfed40000 0x110>;
+        interrupts      =  <GIC_SPI 187 IRQ_TYPE_LEVEL_HIGH>;
+        clocks          = <&CLK_S_ICN_REG_0>;
+        clock-names     = "ssc";
+        clock-frequency = <400000>;
+        pinctrl-names   = "default";
+        pinctrl-0       = <&pinctrl_i2c0_default>;
+        st,i2c-min-scl-pulse-width-us = <0>;
+        st,i2c-min-sda-pulse-width-us = <5>;
+};
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index ad6a73852f08..b1cb3415e6f1 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -15,6 +15,7 @@ adi,adt7461		+/-1C TDM Extended Temp Range I.C
 adt7461                 +/-1C TDM Extended Temp Range I.C
 at,24c08                i2c serial eeprom  (24cxx)
 atmel,24c02             i2c serial eeprom  (24cxx)
+atmel,at97sc3204t       i2c trusted platform module (TPM)
 catalyst,24c32          i2c serial eeprom
 dallas,ds1307           64 x 8, Serial, I2C Real-Time Clock
 dallas,ds1338           I2C RTC with 56-Byte NV RAM
@@ -35,6 +36,7 @@ fsl,mc13892		MC13892: Power Management Integrated Circuit (PMIC) for i.MX35/51
 fsl,mma8450             MMA8450Q: Xtrinsic Low-power, 3-axis Xtrinsic Accelerometer
 fsl,mpr121              MPR121: Proximity Capacitive Touch Sensor Controller
 fsl,sgtl5000            SGTL5000: Ultra Low-Power Audio Codec
+gmt,g751                G751: Digital Temperature Sensor and Thermal Watchdog with Two-Wire Interface
 infineon,slb9635tt      Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz)
 infineon,slb9645tt      Infineon SLB9645 I2C TPM (new protocol, max 400khz)
 maxim,ds1050            5 Bit Programmable, Pulse-Width Modulator
@@ -44,6 +46,7 @@ mc,rv3029c2		Real Time Clock Module with I2C-Bus
 national,lm75           I2C TEMP SENSOR
 national,lm80           Serial Interface ACPI-Compatible Microprocessor System Hardware Monitor
 national,lm92           ±0.33°C Accurate, 12-Bit + Sign Temperature Sensor and Thermal Window Comparator with Two-Wire Interface
+nuvoton,npct501         i2c trusted platform module (TPM)
 nxp,pca9556             Octal SMBus and I2C registered interface
 nxp,pca9557             8-bit I2C-bus and SMBus I/O port with reset
 nxp,pcf8563             Real-time clock/calendar
@@ -61,3 +64,4 @@ taos,tsl2550		Ambient Light Sensor with SMBUS/Two Wire Serial Interface
 ti,tsc2003              I2C Touch-Screen Controller
 ti,tmp102               Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
 ti,tmp275               Digital Temperature Sensor
+winbond,wpct301         i2c trusted platform module (TPM)
diff --git a/Documentation/devicetree/bindings/iio/light/cm36651.txt b/Documentation/devicetree/bindings/iio/light/cm36651.txt
new file mode 100644
index 000000000000..c03e19db4550
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/cm36651.txt
@@ -0,0 +1,26 @@
+* Capella CM36651 I2C Proximity and Color Light sensor
+
+Required properties:
+- compatible: must be "capella,cm36651"
+- reg: the I2C address of the device
+- interrupts: interrupt-specifier for the sole interrupt
+              generated by the device
+- vled-supply: regulator for the IR LED. IR_LED is a part
+              of the cm36651 for proximity detection.
+              As covered in ../../regulator/regulator.txt
+
+Example:
+
+        i2c_cm36651: i2c-gpio {
+                /* ... */
+
+                cm36651@18 {
+                        compatible = "capella,cm36651";
+                        reg = <0x18>;
+                        interrupt-parent = <&gpx0>;
+                        interrupts = <2 0>;
+                        vled-supply = <&ps_als_reg>;
+                };
+
+                /* ... */
+        };
diff --git a/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt b/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt
new file mode 100644
index 000000000000..9231c82317ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/light/gp2ap020a00f.txt
@@ -0,0 +1,21 @@
+* Sharp GP2AP020A00F I2C Proximity/ALS sensor
+
+The proximity detector sensor requires power supply
+for its built-in led. It is also defined by this binding.
+
+Required properties:
+
+  - compatible : should be "sharp,gp2ap020a00f"
+  - reg : the I2C slave address of the light sensor
+  - interrupts : interrupt specifier for the sole interrupt generated
+                 by the device
+  - vled-supply : VLED power supply, as covered in ../regulator/regulator.txt
+
+Example:
+
+gp2ap020a00f@39 {
+        compatible = "sharp,gp2ap020a00f";
+        reg = <0x39>;
+        interrupts = <2 0>;
+        vled-supply = <...>;
+};
diff --git a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
index 491c97b78384..878549ba814d 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/ti-tsc-adc.txt
@@ -6,7 +6,7 @@ Required properties:
         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
+        ti,coordinate-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
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 57edb30dbbca..3d3b2b91e333 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -8,9 +8,6 @@ Required properties:
 - #interrupt-cells : Specifies the number of cells needed to encode an
   interrupt source. The value shall be 1.
 
-For the valid interrupt sources for your SoC, see the documentation in
-sunxi/<soc>.txt
-
 Example:
 
 intc: interrupt-controller {
diff --git a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
index 72a06c0ab1db..1486497a24c1 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
@@ -4,16 +4,33 @@ Specifying interrupt information for devices
 1) Interrupt client nodes
 -------------------------
 
-Nodes that describe devices which generate interrupts must contain an
-"interrupts" property. This property must contain a list of interrupt
-specifiers, one per output interrupt. The format of the interrupt specifier is
-determined by the interrupt controller to which the interrupts are routed; see
-section 2 below for details.
+Nodes that describe devices which generate interrupts must contain an either an
+"interrupts" property or an "interrupts-extended" property. These properties
+contain a list of interrupt specifiers, one per output interrupt. The format of
+the interrupt specifier is determined by the interrupt controller to which the
+interrupts are routed; see section 2 below for details.
+
+  Example:
+        interrupt-parent = <&intc1>;
+        interrupts = <5 0>, <6 0>;
 
 The "interrupt-parent" property is used to specify the controller to which
 interrupts are routed and contains a single phandle referring to the interrupt
 controller node. This property is inherited, so it may be specified in an
-interrupt client node or in any of its parent nodes.
+interrupt client node or in any of its parent nodes. Interrupts listed in the
+"interrupts" property are always in reference to the node's interrupt parent.
+
+The "interrupts-extended" property is a special form for use when a node needs
+to reference multiple interrupt parents. Each entry in this property contains
+both the parent phandle and the interrupt specifier. "interrupts-extended"
+should only be used when a device has multiple interrupt parents.
+
+  Example:
+        interrupts-extended = <&intc1 5 1>, <&intc2 1 0>;
+
+A device node may contain either "interrupts" or "interrupts-extended", but not
+both. If both properties are present, then the operating system should log an
+error and use only the data in "interrupts".
 
 2) Interrupt controller nodes
 -----------------------------
diff --git a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt b/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
deleted file mode 100644
index 76b98c834499..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun4i-a10.txt
+++ /dev/null
@@ -1,89 +0,0 @@
-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
deleted file mode 100644
index 2ec3b5ce1a0b..000000000000
--- a/Documentation/devicetree/bindings/interrupt-controller/sunxi/sun5i-a13.txt
+++ /dev/null
@@ -1,55 +0,0 @@
-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/leds/leds-lp55xx.txt b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
index a61727f9a6d1..c55b8c016a9e 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
+++ b/Documentation/devicetree/bindings/leds/leds-lp55xx.txt
@@ -10,6 +10,7 @@ Each child has own specific current settings
 - max-cur: Maximun current at each led channel.
 
 Optional properties:
+- enable-gpio: GPIO attached to the chip's enable pin
 - label: Used for naming LEDs
 - pwr-sel: LP8501 specific property. Power selection for output channels.
          0: D1~9 are connected to VDD
@@ -17,12 +18,15 @@ Optional properties:
          2: D1~6 with VOUT, D7~9 with VDD
          3: D1~9 are connected to VOUT
 
-Alternatively, each child can have specific channel name
-- chan-name: Name of each channel name
+Alternatively, each child can have a specific channel name and trigger:
+- chan-name (optional): name of channel
+- linux,default-trigger (optional): see
+  Documentation/devicetree/bindings/leds/common.txt
 
 example 1) LP5521
 3 LED channels, external clock used. Channel names are 'lp5521_pri:channel0',
-'lp5521_pri:channel1' and 'lp5521_pri:channel2'
+'lp5521_pri:channel1' and 'lp5521_pri:channel2', with a heartbeat trigger
+on channel 0.
 
 lp5521@32 {
         compatible = "national,lp5521";
@@ -33,6 +37,7 @@ lp5521@32 {
         chan0 {
                 led-cur = /bits/ 8 <0x2f>;
                 max-cur = /bits/ 8 <0x5f>;
+                linux,default-trigger = "heartbeat";
         };
 
         chan1 {
diff --git a/Documentation/devicetree/bindings/media/st-rc.txt b/Documentation/devicetree/bindings/media/st-rc.txt
new file mode 100644
index 000000000000..05c432d08bca
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/st-rc.txt
@@ -0,0 +1,29 @@
+Device-Tree bindings for ST IRB IP
+
+Required properties:
+        - compatible: Should contain "st,comms-irb".
+        - reg: Base physical address of the controller and length of memory
+          mapped region.
+        - interrupts: interrupt-specifier for the sole interrupt generated by
+          the device. The interrupt specifier format depends on the interrupt
+          controller parent.
+        - rx-mode: can be "infrared" or "uhf". This property specifies the L1
+          protocol used for receiving remote control signals. rx-mode should
+          be present iff the rx pins are wired up.
+        - tx-mode: should be "infrared". This property specifies the L1
+          protocol used for transmitting remote control signals. tx-mode should
+          be present iff the tx pins are wired up.
+
+Optional properties:
+        - pinctrl-names, pinctrl-0: the pincontrol settings to configure muxing
+          properly for IRB pins.
+        - clocks : phandle with clock-specifier pair for IRB.
+
+Example node:
+
+        rc: rc@fe518000 {
+                compatible      = "st,comms-irb";
+                reg             = <0xfe518000 0x234>;
+                interrupts      = <0 203 0>;
+                rx-mode         = "infrared";
+        };
diff --git a/Documentation/devicetree/bindings/memory.txt b/Documentation/devicetree/bindings/memory.txt
deleted file mode 100644
index eb2469365593..000000000000
--- a/Documentation/devicetree/bindings/memory.txt
+++ /dev/null
@@ -1,168 +0,0 @@
-*** Memory binding ***
-
-The /memory node provides basic information about the address and size
-of the physical memory. This node is usually filled or updated by the
-bootloader, depending on the actual memory configuration of the given
-hardware.
-
-The memory layout is described by the following node:
-
-/ {
-        #address-cells = <(n)>;
-        #size-cells = <(m)>;
-        memory {
-                device_type = "memory";
-                reg =  <(baseaddr1) (size1)
-                        (baseaddr2) (size2)
-                        ...
-                        (baseaddrN) (sizeN)>;
-        };
-        ...
-};
-
-A memory node follows the typical device tree rules for "reg" property:
-n:              number of cells used to store base address value
-m:              number of cells used to store size value
-baseaddrX:      defines a base address of the defined memory bank
-sizeX:          the size of the defined memory bank
-
-
-More than one memory bank can be defined.
-
-
-*** Reserved memory regions ***
-
-In /memory/reserved-memory node one can create child nodes describing
-particular reserved (excluded from normal use) memory regions. Such
-memory regions are usually designed for the special usage by various
-device drivers. A good example are contiguous memory allocations or
-memory sharing with other operating system on the same hardware board.
-Those special memory regions might depend on the board configuration and
-devices used on the target system.
-
-Parameters for each memory region can be encoded into the device tree
-with the following convention:
-
-[(label):] (name) {
-        compatible = "linux,contiguous-memory-region", "reserved-memory-region";
-        reg = <(address) (size)>;
-        (linux,default-contiguous-region);
-};
-
-compatible:     one or more of:
-        - "linux,contiguous-memory-region" - enables binding of this
-          region to Contiguous Memory Allocator (special region for
-          contiguous memory allocations, shared with movable system
-          memory, Linux kernel-specific).
-        - "reserved-memory-region" - compatibility is defined, given
-          region is assigned for exclusive usage for by the respective
-          devices.
-
-reg:    standard property defining the base address and size of
-        the memory region
-
-linux,default-contiguous-region: property indicating that the region
-        is the default region for all contiguous memory
-        allocations, Linux specific (optional)
-
-It is optional to specify the base address, so if one wants to use
-autoconfiguration of the base address, '0' can be specified as a base
-address in the 'reg' property.
-
-The /memory/reserved-memory node must contain the same #address-cells
-and #size-cells value as the root node.
-
-
-*** Device node's properties ***
-
-Once regions in the /memory/reserved-memory node have been defined, they
-may be referenced by other device nodes. Bindings that wish to reference
-memory regions should explicitly document their use of the following
-property:
-
-memory-region = <&phandle_to_defined_region>;
-
-This property indicates that the device driver should use the memory
-region pointed by the given phandle.
-
-
-*** Example ***
-
-This example defines a memory consisting of 4 memory banks. 3 contiguous
-regions are defined for Linux kernel, one default of all device drivers
-(named contig_mem, placed at 0x72000000, 64MiB), one dedicated to the
-framebuffer device (labelled display_mem, placed at 0x78000000, 8MiB)
-and one for multimedia processing (labelled multimedia_mem, placed at
-0x77000000, 64MiB). 'display_mem' region is then assigned to fb@12300000
-device for DMA memory allocations (Linux kernel drivers will use CMA is
-available or dma-exclusive usage otherwise). 'multimedia_mem' is
-assigned to scaler@12500000 and codec@12600000 devices for contiguous
-memory allocations when CMA driver is enabled.
-
-The reason for creating a separate region for framebuffer device is to
-match the framebuffer base address to the one configured by bootloader,
-so once Linux kernel drivers starts no glitches on the displayed boot
-logo appears. Scaller and codec drivers should share the memory
-allocations.
-
-/ {
-        #address-cells = <1>;
-        #size-cells = <1>;
-
-        /* ... */
-
-        memory {
-                reg =  <0x40000000 0x10000000
-                        0x50000000 0x10000000
-                        0x60000000 0x10000000
-                        0x70000000 0x10000000>;
-
-                reserved-memory {
-                        #address-cells = <1>;
-                        #size-cells = <1>;
-
-                        /*
-                         * global autoconfigured region for contiguous allocations
-                         * (used only with Contiguous Memory Allocator)
-                         */
-                        contig_region@0 {
-                                compatible = "linux,contiguous-memory-region";
-                                reg = <0x0 0x4000000>;
-                                linux,default-contiguous-region;
-                        };
-
-                        /*
-                         * special region for framebuffer
-                         */
-                        display_region: region@78000000 {
-                                compatible = "linux,contiguous-memory-region", "reserved-memory-region";
-                                reg = <0x78000000 0x800000>;
-                        };
-
-                        /*
-                         * special region for multimedia processing devices
-                         */
-                        multimedia_region: region@77000000 {
-                                compatible = "linux,contiguous-memory-region";
-                                reg = <0x77000000 0x4000000>;
-                        };
-                };
-        };
-
-        /* ... */
-
-        fb0: fb@12300000 {
-                status = "okay";
-                memory-region = <&display_region>;
-        };
-
-        scaler: scaler@12500000 {
-                status = "okay";
-                memory-region = <&multimedia_region>;
-        };
-
-        codec: codec@12600000 {
-                status = "okay";
-                memory-region = <&multimedia_region>;
-        };
-};
diff --git a/Documentation/devicetree/bindings/mfd/as3722.txt b/Documentation/devicetree/bindings/mfd/as3722.txt
new file mode 100644
index 000000000000..fc2191ecfd6b
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/as3722.txt
@@ -0,0 +1,194 @@
+* ams AS3722 Power management IC.
+
+Required properties:
+-------------------
+- compatible: Must be "ams,as3722".
+- reg: I2C device address.
+- interrupt-controller: AS3722 has internal interrupt controller which takes the
+  interrupt request from internal sub-blocks like RTC, regulators, GPIOs as well
+  as external input.
+- #interrupt-cells: Should be set to 2 for IRQ number and flags.
+  The first cell is the IRQ number. IRQ numbers for different interrupt source
+  of AS3722 are defined at dt-bindings/mfd/as3722.h
+  The second cell is the flags, encoded as the trigger masks from binding document
+        interrupts.txt, using dt-bindings/irq.
+
+Optional submodule and their properties:
+=======================================
+
+Pinmux and GPIO:
+===============
+Device has 8 GPIO pins which can be configured as GPIO as well as the special IO
+functions.
+
+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".
+
+Following are properties which is needed if GPIO and pinmux functionality
+is required:
+    Required properties:
+    -------------------
+        - gpio-controller: Marks the device node as a GPIO controller.
+        - #gpio-cells: Number of GPIO cells. Refer to binding document
+                        gpio/gpio.txt
+
+    Optional properties:
+    --------------------
+        Following properties are require if pin control setting is required
+        at boot.
+        - pinctrl-names: A pinctrl state named "default" be defined, using the
+                bindings in pinctrl/pinctrl-binding.txt.
+        - pinctrl[0...n]: Properties to contain the phandle that refer to
+                different nodes of pin control settings. These nodes represents
+                the pin control setting of state 0 to state n. Each of these
+                nodes contains different subnodes to represents some desired
+                configuration for a list of pins. This configuration can
+                include the mux function to select on those pin(s), and
+                various pin configuration parameters, such as pull-up,
+                open drain.
+
+                Each subnode have following properties:
+                Required properties:
+                    - pins: List of pins. Valid values of pins properties are:
+                                gpio0, gpio1, gpio2, gpio3, gpio4, gpio5,
+                                gpio6, gpio7
+
+                Optional properties:
+                        function, bias-disable, bias-pull-up, bias-pull-down,
+                        bias-high-impedance, drive-open-drain.
+
+                        Valid values for function properties are:
+                                gpio, interrupt-out, gpio-in-interrupt,
+                                vsup-vbat-low-undebounce-out,
+                                vsup-vbat-low-debounce-out,
+                                voltage-in-standby, oc-pg-sd0, oc-pg-sd6,
+                                powergood-out, pwm-in, pwm-out, clk32k-out,
+                                watchdog-in, soft-reset-in
+
+Regulators:
+===========
+Device has multiple DCDC and LDOs. The node "regulators" is require if regulator
+functionality is needed.
+
+Following are properties of regulator subnode.
+
+    Optional properties:
+    -------------------
+        The input supply of regulators are the optional properties on the
+        regulator node. The input supply of these regulators are provided
+        through following properties:
+                vsup-sd2-supply: Input supply for SD2.
+                vsup-sd3-supply: Input supply for SD3.
+                vsup-sd4-supply: Input supply for SD4.
+                vsup-sd5-supply: Input supply for SD5.
+                vin-ldo0-supply: Input supply for LDO0.
+                vin-ldo1-6-supply: Input supply for LDO1 and LDO6.
+                vin-ldo2-5-7-supply: Input supply for LDO2, LDO5 and LDO7.
+                vin-ldo3-4-supply: Input supply for LDO3 and LDO4.
+                vin-ldo9-10-supply: Input supply for LDO9 and LDO10.
+                vin-ldo11-supply: Input supply for LDO11.
+
+    Optional sub nodes for regulators:
+    ---------------------------------
+        The subnodes name is the name of regulator and it must be one of:
+        sd[0-6], ldo[0-7], ldo[9-11]
+
+        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 optional custom properties  are listed below.
+                ams,ext-control: External control of the rail. The option of
+                        this properties will tell which external input is
+                        controlling this rail. Valid values are 0, 1, 2 ad 3.
+                        0: There is no external control of this rail.
+                        1: Rail is controlled by ENABLE1 input pin.
+                        2: Rail is controlled by ENABLE2 input pin.
+                        3: Rail is controlled by ENABLE3 input pin.
+                        Missing this property on DT will be assume as no
+                        external control. The external control pin macros
+                        are defined @dt-bindings/mfd/as3722.h
+
+                ams,enable-tracking: Enable tracking with SD1, only supported
+                        by LDO3.
+
+Example:
+--------
+#include <dt-bindings/mfd/as3722.h>
+...
+ams3722 {
+        compatible = "ams,as3722";
+        reg = <0x48>;
+
+        interrupt-parent = <&intc>;
+        interrupt-controller;
+        #interrupt-cells = <2>;
+
+        gpio-controller;
+        #gpio-cells = <2>;
+
+        pinctrl-names = "default";
+        pinctrl-0 = <&as3722_default>;
+
+        as3722_default: pinmux {
+                        gpio0 {
+                                pins = "gpio0";
+                                function = "gpio";
+                                bias-pull-down;
+                        };
+
+                        gpio1_2_4_7 {
+                                pins = "gpio1", "gpio2", "gpio4", "gpio7";
+                                function = "gpio";
+                                bias-pull-up;
+                        };
+
+                        gpio5 {
+                                pins = "gpio5";
+                                function = "clk32k_out";
+                        };
+        }
+
+        regulators {
+                        vsup-sd2-supply = <...>;
+                        ...
+
+                        sd0 {
+                                regulator-name = "vdd_cpu";
+                                regulator-min-microvolt = <700000>;
+                                regulator-max-microvolt = <1400000>;
+                                regulator-always-on;
+                                ams,ext-control = <2>;
+                        };
+
+                        sd1 {
+                                regulator-name = "vdd_core";
+                                regulator-min-microvolt = <700000>;
+                                regulator-max-microvolt = <1400000>;
+                                regulator-always-on;
+                                ams,ext-control = <1>;
+                        };
+
+                        sd2 {
+                                regulator-name = "vddio_ddr";
+                                regulator-min-microvolt = <1350000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                        };
+
+                        sd4 {
+                                regulator-name = "avdd-hdmi-pex";
+                                regulator-min-microvolt = <1050000>;
+                                regulator-max-microvolt = <1050000>;
+                                regulator-always-on;
+                        };
+
+                        sd5 {
+                                regulator-name = "vdd-1v8";
+                                regulator-min-microvolt = <1800000>;
+                                regulator-max-microvolt = <1800000>;
+                                regulator-always-on;
+                        };
+                        ....
+        };
+};
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index c9332c626021..78a840d7510d 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,10 +1,10 @@
 
 * Samsung S2MPS11 Voltage and Current Regulator
 
-The Samsung S2MP211 is a multi-function device which includes voltage and
+The Samsung S2MPS11 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.
+interfaced to the host controller using an I2C interface. Each sub-block is
+addressed by the host system using different I2C slave addresses.
 
 Required properties:
 - compatible: Should be "samsung,s2mps11-pmic".
@@ -43,7 +43,8 @@ sub-node should be of the format as listed below.
 
  BUCK[2/3/4/6] supports disabling ramp delay on hardware, so explictly
  regulator-ramp-delay = <0> can be used for them to disable ramp delay.
- In absence of regulator-ramp-delay property, default ramp delay will be used.
+ In the absence of the regulator-ramp-delay property, the default ramp
+ delay will be used.
 
 NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
 for a particular group of BUCKs. So provide same regulator-ramp-delay<value>.
@@ -58,10 +59,10 @@ supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
 as per the datasheet of s2mps11.
 
         - LDOn
-                  - valid values for n are 1 to 28
+                  - valid values for n are 1 to 38
                   - Example: LDO0, LD01, LDO28
         - BUCKn
-                  - valid values for n are 1 to 9.
+                  - valid values for n are 1 to 10.
                   - Example: BUCK1, BUCK2, BUCK9
 
 Example:
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
new file mode 100644
index 000000000000..68ba37295565
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
@@ -0,0 +1,17 @@
+Allwinner sunxi-sid
+
+Required properties:
+- compatible: "allwinner,sun4i-sid" or "allwinner,sun7i-a20-sid".
+- reg: Should contain registers location and length
+
+Example for sun4i:
+        sid@01c23800 {
+                compatible = "allwinner,sun4i-sid";
+                reg = <0x01c23800 0x10>
+        };
+
+Example for sun7i:
+        sid@01c23800 {
+                compatible = "allwinner,sun7i-a20-sid";
+                reg = <0x01c23800 0x200>
+        };
diff --git a/Documentation/devicetree/bindings/misc/ti,dac7512.txt b/Documentation/devicetree/bindings/misc/ti,dac7512.txt
new file mode 100644
index 000000000000..1db45939dac9
--- /dev/null
+++ b/Documentation/devicetree/bindings/misc/ti,dac7512.txt
@@ -0,0 +1,20 @@
+TI DAC7512 DEVICETREE BINDINGS
+
+Required properties:
+
+        - "compatible"          Must be set to "ti,dac7512"
+
+Property rules described in Documentation/devicetree/bindings/spi/spi-bus.txt
+apply. In particular, "reg" and "spi-max-frequency" properties must be given.
+
+
+Example:
+
+        spi_master {
+                dac7512: dac7512@0 {
+                        compatible = "ti,dac7512";
+                        reg = <0>; /* CS0 */
+                        spi-max-frequency = <1000000>;
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
index 1dd622546d06..9046ba06c47a 100644
--- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
+++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
@@ -12,6 +12,11 @@ Required properties:
 Optional properties:
 - fsl,cd-controller : Indicate to use controller internal card detection
 - fsl,wp-controller : Indicate to use controller internal write protection
+- fsl,delay-line : Specify the number of delay cells for override mode.
+  This is used to set the clock delay for DLL(Delay Line) on override mode
+  to select a proper data sampling window in case the clock quality is not good
+  due to signal path is too long on the board. Please refer to eSDHC/uSDHC
+  chapter, DLL (Delay Line) section in RM for details.
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
index 066a78b034ca..8f3f13315358 100644
--- a/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
+++ b/Documentation/devicetree/bindings/mmc/synopsys-dw-mshc.txt
@@ -52,6 +52,9 @@ Optional properties:
   is specified and the ciu clock is specified then we'll try to set the ciu
   clock to this at probe time.
 
+* clock-freq-min-max: Minimum and Maximum clock frequency for card output
+  clock(cclk_out). If it's not specified, max is 200MHZ and min is 400KHz by default.
+
 * 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
@@ -66,6 +69,10 @@ Optional properties:
 
 * supports-highspeed: Enables support for high speed cards (up to 50MHz)
 
+* caps2-mmc-hs200-1_8v: Supports mmc HS200 SDR 1.8V mode
+
+* caps2-mmc-hs200-1_2v: Supports mmc HS200 SDR 1.2V mode
+
 * broken-cd: as documented in mmc core bindings.
 
 * vmmc-supply: The phandle to the regulator to use for vmmc.  If this is
@@ -93,8 +100,10 @@ board specific portions as listed below.
 
         dwmmc0@12200000 {
                 clock-frequency = <400000000>;
+                clock-freq-min-max = <400000 200000000>;
                 num-slots = <1>;
                 supports-highspeed;
+                caps2-mmc-hs200-1_8v;
                 broken-cd;
                 fifo-depth = <0x80>;
                 card-detect-delay = <200>;
diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
index ed271fc255b2..8c8908ab84ba 100644
--- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
+++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
@@ -20,8 +20,29 @@ ti,dual-volt: boolean, supports dual voltage cards
 ti,non-removable: non-removable slot (like eMMC)
 ti,needs-special-reset: Requires a special softreset sequence
 ti,needs-special-hs-handling: HSMMC IP needs special setting for handling High Speed
+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.
+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 "rx" and "tx" for RX and TX DMA requests, respectively.
+
+Examples:
+
+[hwmod populated DMA resources]
+
+        mmc1: mmc@0x4809c000 {
+                compatible = "ti,omap4-hsmmc";
+                reg = <0x4809c000 0x400>;
+                ti,hwmods = "mmc1";
+                ti,dual-volt;
+                bus-width = <4>;
+                vmmc-supply = <&vmmc>; /* phandle to regulator node */
+                ti,non-removable;
+        };
+
+[generic DMA request binding]
 
-Example:
         mmc1: mmc@0x4809c000 {
                 compatible = "ti,omap4-hsmmc";
                 reg = <0x4809c000 0x400>;
@@ -30,4 +51,7 @@ Example:
                 bus-width = <4>;
                 vmmc-supply = <&vmmc>; /* phandle to regulator node */
                 ti,non-removable;
+                dmas = <&edma 24
+                        &edma 25>;
+                dma-names = "tx", "rx";
         };
diff --git a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
index df204e18e030..6a2a1160a70d 100644
--- a/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/tmio_mmc.txt
@@ -9,12 +9,15 @@ compulsory and any optional properties, common to all SD/MMC drivers, as
 described in mmc.txt, can be used. Additionally the following tmio_mmc-specific
 optional bindings can be used.
 
+Required properties:
+- compatible:   "renesas,sdhi-shmobile" - a generic sh-mobile SDHI unit
+                "renesas,sdhi-sh7372" - SDHI IP on SH7372 SoC
+                "renesas,sdhi-sh73a0" - SDHI IP on SH73A0 SoC
+                "renesas,sdhi-r8a73a4" - SDHI IP on R8A73A4 SoC
+                "renesas,sdhi-r8a7740" - SDHI IP on R8A7740 SoC
+                "renesas,sdhi-r8a7778" - SDHI IP on R8A7778 SoC
+                "renesas,sdhi-r8a7779" - SDHI IP on R8A7779 SoC
+                "renesas,sdhi-r8a7790" - SDHI IP on R8A7790 SoC
+
 Optional properties:
 - toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
-
-When used with Renesas SDHI hardware, the following compatibility strings
-configure various model-specific properties:
-
-"renesas,sh7372-sdhi":  (default) compatible with SH7372
-"renesas,r8a7740-sdhi": compatible with R8A7740: certain MMC/SD commands have to
-                        wait for the interface to become idle.
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
index df338cb5059c..5e1f31b5ff70 100644
--- a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -22,10 +22,10 @@ Optional properties:
                                 width of 8 is assumed.
 
  - ti,nand-ecc-opt:             A string setting the ECC layout to use. One of:
-
-                "sw"            Software method (default)
-                "hw"            Hardware method
-                "hw-romcode"    gpmc hamming mode method & romcode layout
+                "sw"            <deprecated> use "ham1" instead
+                "hw"            <deprecated> use "ham1" instead
+                "hw-romcode"    <deprecated> use "ham1" instead
+                "ham1"          1-bit Hamming ecc code
                 "bch4"          4-bit BCH ecc code
                 "bch8"          8-bit BCH ecc code
 
@@ -36,8 +36,12 @@ Optional properties:
                 "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.
+ - elm_id:      <deprecated> use "ti,elm-id" instead
+ - ti,elm-id:   Specifies phandle of the ELM devicetree node.
+                ELM is an on-chip hardware engine on TI SoC which is used for
+                locating ECC errors for BCHx algorithms. SoC devices which have
+                ELM hardware engines should specify this device node in .dtsi
+                Using ELM for ECC error correction frees some CPU cycles.
 
 For inline partiton table parsing (optional):
 
diff --git a/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
new file mode 100644
index 000000000000..7ff57a119f81
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/cpsw-phy-sel.txt
@@ -0,0 +1,28 @@
+TI CPSW Phy mode Selection Device Tree Bindings
+-----------------------------------------------
+
+Required properties:
+- compatible            : Should be "ti,am3352-cpsw-phy-sel"
+- reg                   : physical base address and size of the cpsw
+                          registers map
+- reg-names             : names of the register map given in "reg" node
+
+Optional properties:
+-rmii-clock-ext         : If present, the driver will configure the RMII
+                          interface to external clock usage
+
+Examples:
+
+        phy_sel: cpsw-phy-sel@44e10650 {
+                compatible = "ti,am3352-cpsw-phy-sel";
+                reg= <0x44e10650 0x4>;
+                reg-names = "gmii-sel";
+        };
+
+(or)
+        phy_sel: cpsw-phy-sel@44e10650 {
+                compatible = "ti,am3352-cpsw-phy-sel";
+                reg= <0x44e10650 0x4>;
+                reg-names = "gmii-sel";
+                rmii-clock-ext;
+        };
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index 2c6be0377f55..d2ea4605d078 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -86,6 +86,7 @@ General Properties:
 
 Clock Properties:
 
+  - fsl,cksel        Timer reference clock source.
   - fsl,tclk-period  Timer reference clock period in nanoseconds.
   - fsl,tmr-prsc     Prescaler, divides the output clock.
   - fsl,tmr-add      Frequency compensation value.
@@ -97,7 +98,7 @@ Clock Properties:
   clock. You must choose these carefully for the clock to work right.
   Here is how to figure good values:
 
-  TimerOsc     = system clock               MHz
+  TimerOsc     = selected reference clock   MHz
   tclk_period  = desired clock period       nanoseconds
   NominalFreq  = 1000 / tclk_period         MHz
   FreqDivRatio = TimerOsc / NominalFreq     (must be greater that 1.0)
@@ -114,6 +115,20 @@ Clock Properties:
   Pulse Per Second (PPS) signal, since this will be offered to the PPS
   subsystem to synchronize the Linux clock.
 
+  Reference clock source is determined by the value, which is holded
+  in CKSEL bits in TMR_CTRL register. "fsl,cksel" property keeps the
+  value, which will be directly written in those bits, that is why,
+  according to reference manual, the next clock sources can be used:
+
+  <0> - external high precision timer reference clock (TSEC_TMR_CLK
+        input is used for this purpose);
+  <1> - eTSEC system clock;
+  <2> - eTSEC1 transmit clock;
+  <3> - RTC clock input.
+
+  When this attribute is not used, eTSEC system clock will serve as
+  IEEE 1588 timer reference clock.
+
 Example:
 
         ptp_clock@24E00 {
@@ -121,6 +136,7 @@ Example:
                 reg = <0x24E00 0xB0>;
                 interrupts = <12 0x8 13 0x8>;
                 interrupt-parent = < &ipic >;
+                fsl,cksel       = <1>;
                 fsl,tclk-period = <10>;
                 fsl,tmr-prsc    = <100>;
                 fsl,tmr-add     = <0x999999A4>;
diff --git a/Documentation/devicetree/bindings/pci/designware-pcie.txt b/Documentation/devicetree/bindings/pci/designware-pcie.txt
index e216af356847..d5d26d443693 100644
--- a/Documentation/devicetree/bindings/pci/designware-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/designware-pcie.txt
@@ -3,7 +3,7 @@
 Required properties:
 - compatible: should contain "snps,dw-pcie" to identify the
         core, plus an identifier for the specific instance, such
-        as "samsung,exynos5440-pcie".
+        as "samsung,exynos5440-pcie" or "fsl,imx6q-pcie".
 - reg: base addresses and lengths of the pcie controller,
         the phy controller, additional register for the phy controller.
 - interrupts: interrupt values for level interrupt,
@@ -21,6 +21,11 @@ Required properties:
 - num-lanes: number of lanes to use
 - reset-gpio: gpio pin number of power good signal
 
+Optional properties for fsl,imx6q-pcie
+- power-on-gpio: gpio pin number of power-enable signal
+- wake-up-gpio: gpio pin number of incoming wakeup signal
+- disable-gpio: gpio pin number of outgoing rfkill/endpoint disable signal
+
 Example:
 
 SoC specific DT Entry:
diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
index 9556e2fedf6d..08c716b2c6b6 100644
--- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt
+++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt
@@ -5,6 +5,7 @@ Mandatory properties:
 - compatible: one of the following values:
     marvell,armada-370-pcie
     marvell,armada-xp-pcie
+    marvell,dove-pcie
     marvell,kirkwood-pcie
 - #address-cells, set to <3>
 - #size-cells, set to <2>
@@ -14,6 +15,8 @@ Mandatory properties:
 - ranges: ranges describing the MMIO registers to control the PCIe
   interfaces, and ranges describing the MBus windows needed to access
   the memory and I/O regions of each PCIe interface.
+- msi-parent: Link to the hardware entity that serves as the Message
+  Signaled Interrupt controller for this PCI controller.
 
 The ranges describing the MMIO registers have the following layout:
 
@@ -74,6 +77,8 @@ 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.
+- reset-gpios: optional gpio to PERST#
+- reset-delay-us: delay in us to wait after reset de-assertion
 
 Example:
 
@@ -86,6 +91,7 @@ pcie-controller {
         #size-cells = <2>;
 
         bus-range = <0x00 0xff>;
+        msi-parent = <&mpic>;
 
         ranges =
                <0x82000000 0 0x40000 MBUS_ID(0xf0, 0x01) 0x40000 0 0x00002000   /* Port 0.0 registers */
@@ -135,6 +141,10 @@ pcie-controller {
                 interrupt-map = <0 0 0 0 &mpic 58>;
                 marvell,pcie-port = <0>;
                 marvell,pcie-lane = <0>;
+                /* low-active PERST# reset on GPIO 25 */
+                reset-gpios = <&gpio0 25 1>;
+                /* wait 20ms for device settle after reset deassertion */
+                reset-delay-us = <20000>;
                 clocks = <&gateclk 5>;
                 status = "disabled";
         };
diff --git a/Documentation/devicetree/bindings/phy/phy-bindings.txt b/Documentation/devicetree/bindings/phy/phy-bindings.txt
new file mode 100644
index 000000000000..8ae844fc0c60
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/phy-bindings.txt
@@ -0,0 +1,66 @@
+This document explains only the device tree data binding. For general
+information about PHY subsystem refer to Documentation/phy.txt
+
+PHY device node
+===============
+
+Required Properties:
+#phy-cells:     Number of cells in a PHY specifier;  The meaning of all those
+                cells is defined by the binding for the phy node. The PHY
+                provider can use the values in cells to find the appropriate
+                PHY.
+
+For example:
+
+phys: phy {
+    compatible = "xxx";
+    reg = <...>;
+    .
+    .
+    #phy-cells = <1>;
+    .
+    .
+};
+
+That node describes an IP block (PHY provider) that implements 2 different PHYs.
+In order to differentiate between these 2 PHYs, an additonal specifier should be
+given while trying to get a reference to it.
+
+PHY user node
+=============
+
+Required Properties:
+phys : the phandle for the PHY device (used by the PHY subsystem)
+phy-names : the names of the PHY corresponding to the PHYs present in the
+            *phys* phandle
+
+Example 1:
+usb1: usb_otg_ss@xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&usb2_phy>, <&usb3_phy>;
+    phy-names = "usb2phy", "usb3phy";
+    .
+    .
+};
+
+This node represents a controller that uses two PHYs, one for usb2 and one for
+usb3.
+
+Example 2:
+usb2: usb_otg_ss@xxx {
+    compatible = "xxx";
+    reg = <xxx>;
+    .
+    .
+    phys = <&phys 1>;
+    phy-names = "usbphy";
+    .
+    .
+};
+
+This node represents a controller that uses one of the PHYs of the PHY provider
+device defined previously. Note that the phy handle has an additional specifier
+"1" to differentiate between the two PHYs.
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
new file mode 100644
index 000000000000..c0fccaa1671e
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -0,0 +1,22 @@
+Samsung S5P/EXYNOS SoC series MIPI CSIS/DSIM DPHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,s5pv210-mipi-video-phy";
+- reg : offset and length of the MIPI DPHY register set;
+- #phy-cells : from the generic phy bindings, must be 1;
+
+For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in
+the PHY specifier identifies the PHY and its meaning is as follows:
+  0 - MIPI CSIS 0,
+  1 - MIPI DSIM 0,
+  2 - MIPI CSIS 1,
+  3 - MIPI DSIM 1.
+
+Samsung EXYNOS SoC series Display Port PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be "samsung,exynos5250-dp-video-phy";
+- reg : offset and length of the Display Port PHY register set;
+- #phy-cells : from the generic PHY bindings, must be 0;
diff --git a/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt b/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt
new file mode 100644
index 000000000000..2c11866221c2
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/abilis,tb10x-iomux.txt
@@ -0,0 +1,80 @@
+Abilis Systems TB10x pin controller
+===================================
+
+Required properties
+-------------------
+
+- compatible: should be "abilis,tb10x-iomux";
+- reg: should contain the physical address and size of the pin controller's
+  register range.
+
+
+Function definitions
+--------------------
+
+Functions are defined (and referenced) by sub-nodes of the pin controller.
+Every sub-node defines exactly one function (implying a set of pins).
+Every function is associated to one named pin group inside the pin controller
+driver and these names are used to associate pin group predefinitions to pin
+controller sub-nodes.
+
+Required function definition subnode properties:
+  - abilis,function: should be set to the name of the function's pin group.
+
+The following pin groups are available:
+  - GPIO ports: gpioa, gpiob, gpioc, gpiod, gpioe, gpiof, gpiog,
+                gpioh, gpioi, gpioj, gpiok, gpiol, gpiom, gpion
+  - Serial TS input ports: mis0, mis1, mis2, mis3, mis4, mis5, mis6, mis7
+  - Parallel TS input ports: mip1, mip3, mip5, mip7
+  - Serial TS output ports: mos0, mos1, mos2, mos3
+  - Parallel TS output port: mop
+  - CI+ port: ciplus
+  - CableCard (Mcard) port: mcard
+  - Smart card ports: stc0, stc1
+  - UART ports: uart0, uart1
+  - SPI ports: spi1, spi3
+  - JTAG: jtag
+
+All other ports of the chip are not multiplexed and thus not managed by this
+driver.
+
+
+GPIO ranges definition
+----------------------
+
+The named pin groups of GPIO ports can be used to define GPIO ranges as
+explained in Documentation/devicetree/bindings/gpio/gpio.txt.
+
+
+Example
+-------
+
+iomux: iomux@FF10601c {
+        compatible = "abilis,tb10x-iomux";
+        reg = <0xFF10601c 0x4>;
+        pctl_gpio_a: pctl-gpio-a {
+                abilis,function = "gpioa";
+        };
+        pctl_uart0: pctl-uart0 {
+                abilis,function = "uart0";
+        };
+};
+uart@FF100000 {
+        compatible = "snps,dw-apb-uart";
+        reg = <0xFF100000 0x100>;
+        clock-frequency = <166666666>;
+        interrupts = <25 1>;
+        reg-shift = <2>;
+        reg-io-width = <4>;
+        pinctrl-names = "default";
+        pinctrl-0 = <&pctl_uart0>;
+};
+gpioa: gpio@FF140000 {
+        compatible = "abilis,tb10x-gpio";
+        reg = <0xFF140000 0x1000>;
+        gpio-controller;
+        #gpio-cells = <2>;
+        ngpio = <3>;
+        gpio-ranges = <&iomux 0 0>;
+        gpio-ranges-group-names = "gpioa";
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 7ccae490ff6d..02ab5ab198a4 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -18,7 +18,7 @@ mode) this pin can work on and the 'config' configures various pad settings
 such as pull-up, multi drive, etc.
 
 Required properties for iomux controller:
-- compatible: "atmel,at91rm9200-pinctrl"
+- compatible: "atmel,at91rm9200-pinctrl" or "atmel,at91sam9x5-pinctrl"
 - atmel,mux-mask: array of mask (periph per bank) to describe if a pin can be
   configured in this periph mode. All the periph and bank need to be describe.
 
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
index 3a7caf7a744a..9fde25f1401a 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx-pinctrl.txt
@@ -22,11 +22,12 @@ Required properties for iomux controller:
   Please refer to each fsl,<soc>-pinctrl.txt binding doc for supported SoCs.
 
 Required properties for pin configuration node:
-- 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, which consists of a tuple of
-  <mux_reg conf_reg input_reg mux_val input_val>.  CONFIG is the pad setting
-  value like pull-up on this pin.
+- fsl,pins: each entry consists of 6 integers and represents the mux and config
+  setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
+  input_val> are specified using a PIN_FUNC_ID macro, which can be found in
+  imx*-pinfunc.h under device tree source folder. The last integer CONFIG is
+  the pad setting value like pull-up on this pin. And that's why fsl,pins entry
+  looks like <PIN_FUNC_ID CONFIG> in the example below.
 
 Bits used for CONFIG:
 NO_PAD_CTL(1 << 31): indicate this pin does not need config.
@@ -72,17 +73,18 @@ iomuxc@020e0000 {
         /* shared pinctrl settings */
         usdhc4 {
                 pinctrl_usdhc4_1: usdhc4grp-1 {
-                        fsl,pins = <1386 0x17059        /* MX6Q_PAD_SD4_CMD__USDHC4_CMD */
-                                    1392 0x10059        /* MX6Q_PAD_SD4_CLK__USDHC4_CLK */
-                                    1462 0x17059        /* MX6Q_PAD_SD4_DAT0__USDHC4_DAT0 */
-                                    1470 0x17059        /* MX6Q_PAD_SD4_DAT1__USDHC4_DAT1 */
-                                    1478 0x17059        /* MX6Q_PAD_SD4_DAT2__USDHC4_DAT2 */
-                                    1486 0x17059        /* MX6Q_PAD_SD4_DAT3__USDHC4_DAT3 */
-                                    1493 0x17059        /* MX6Q_PAD_SD4_DAT4__USDHC4_DAT4 */
-                                    1501 0x17059        /* MX6Q_PAD_SD4_DAT5__USDHC4_DAT5 */
-                                    1509 0x17059        /* MX6Q_PAD_SD4_DAT6__USDHC4_DAT6 */
-                                    1517 0x17059>;      /* MX6Q_PAD_SD4_DAT7__USDHC4_DAT7 */
-                };
+                        fsl,pins = <
+                                MX6QDL_PAD_SD4_CMD__SD4_CMD    0x17059
+                                MX6QDL_PAD_SD4_CLK__SD4_CLK    0x10059
+                                MX6QDL_PAD_SD4_DAT0__SD4_DATA0 0x17059
+                                MX6QDL_PAD_SD4_DAT1__SD4_DATA1 0x17059
+                                MX6QDL_PAD_SD4_DAT2__SD4_DATA2 0x17059
+                                MX6QDL_PAD_SD4_DAT3__SD4_DATA3 0x17059
+                                MX6QDL_PAD_SD4_DAT4__SD4_DATA4 0x17059
+                                MX6QDL_PAD_SD4_DAT5__SD4_DATA5 0x17059
+                                MX6QDL_PAD_SD4_DAT6__SD4_DATA6 0x17059
+                                MX6QDL_PAD_SD4_DAT7__SD4_DATA7 0x17059
+                        >;
         };
         ....
 };
@@ -90,6 +92,3 @@ Refer to the IOMUXC controller chapter in imx6q datasheet,
 0x17059 means enable hysteresis, 47KOhm Pull Up, 50Mhz speed,
 80Ohm driver strength and Fast Slew Rate.
 User should refer to each SoC spec to set the correct value.
-
-TODO: when dtc macro support is available, we can change above raw data
-to dt macro which can get better readability in dts file.
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt
new file mode 100644
index 000000000000..353eca0efbf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx27-pinctrl.txt
@@ -0,0 +1,99 @@
+* Freescale IMX27 IOMUX Controller
+
+Required properties:
+- compatible: "fsl,imx27-iomuxc"
+
+The iomuxc driver node should define subnodes containing of pinctrl configuration subnodes.
+
+Required properties for pin configuration node:
+- fsl,pins: three integers array, represents a group of pins mux and config
+  setting. The format is fsl,pins = <PIN MUX_ID CONFIG>.
+
+  PIN is an integer between 0 and 0xbf. imx27 has 6 ports with 32 configurable
+  configurable pins each. PIN is PORT * 32 + PORT_PIN, PORT_PIN is the pin
+  number on the specific port (between 0 and 31).
+
+  MUX_ID is
+    function + (direction << 2) + (gpio_oconf << 4) + (gpio_iconfa << 8) + (gpio_iconfb << 10)
+
+      function value is used to select the pin function.
+      Possible values:
+          0 - Primary function
+          1 - Alternate function
+          2 - GPIO
+      Registers: GIUS (GPIO In Use), GPR (General Purpose Register)
+
+      direction defines the data direction of the pin.
+      Possible values:
+          0 - Input
+          1 - Output
+      Register: DDIR
+
+      gpio_oconf configures the gpio submodule output signal. This does not
+      have any effect unless GPIO function is selected. A/B/C_IN are output
+      signals of function blocks A,B and C. Specific function blocks are
+      described in the reference manual.
+      Possible values:
+          0 - A_IN
+          1 - B_IN
+          2 - C_IN
+          3 - Data Register
+      Registers: OCR1, OCR2
+
+      gpio_iconfa/b configures the gpio submodule input to functionblocks A and
+      B. GPIO function should be selected if this is configured.
+      Possible values:
+          0 - GPIO_IN
+          1 - Interrupt Status Register
+          2 - Pulldown
+          3 - Pullup
+      Registers ICONFA1, ICONFA2, ICONFB1 and ICONFB2
+
+  CONFIG can be 0 or 1, meaning Pullup disable/enable.
+
+
+
+Example:
+
+iomuxc: iomuxc@10015000 {
+        compatible = "fsl,imx27-iomuxc";
+        reg = <0x10015000 0x600>;
+
+        uart {
+                pinctrl_uart1: uart-1 {
+                        fsl,pins = <
+                                0x8c 0x004 0x0 /* UART1_TXD__UART1_TXD */
+                                0x8d 0x000 0x0 /* UART1_RXD__UART1_RXD */
+                                0x8e 0x004 0x0 /* UART1_CTS__UART1_CTS */
+                                0x8f 0x000 0x0 /* UART1_RTS__UART1_RTS */
+                        >;
+                };
+
+                ...
+        };
+};
+
+
+For convenience there are macros defined in imx27-pinfunc.h which provide PIN
+and MUX_ID. They are structured as MX27_PAD_<Pad name>__<Signal name>. The names
+are defined in the i.MX27 reference manual.
+
+The above example using macros:
+
+iomuxc: iomuxc@10015000 {
+        compatible = "fsl,imx27-iomuxc";
+        reg = <0x10015000 0x600>;
+
+        uart {
+                pinctrl_uart1: uart-1 {
+                        fsl,pins = <
+                                MX27_PAD_UART1_TXD__UART1_TXD 0x0
+                                MX27_PAD_UART1_RXD__UART1_RXD 0x0
+                                MX27_PAD_UART1_CTS__UART1_CTS 0x0
+                                MX27_PAD_UART1_RTS__UART1_RTS 0x0
+                        >;
+                };
+
+                ...
+        };
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
index 3077370c89af..1e70a8aff260 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,mxs-pinctrl.txt
@@ -59,16 +59,16 @@ Required subnode-properties:
 
 Optional subnode-properties:
 - fsl,drive-strength: Integer.
-    0: 4 mA
-    1: 8 mA
-    2: 12 mA
-    3: 16 mA
+    0: MXS_DRIVE_4mA
+    1: MXS_DRIVE_8mA
+    2: MXS_DRIVE_12mA
+    3: MXS_DRIVE_16mA
 - fsl,voltage: Integer.
-    0: 1.8 V
-    1: 3.3 V
+    0: MXS_VOLTAGE_LOW  - 1.8 V
+    1: MXS_VOLTAGE_HIGH - 3.3 V
 - fsl,pull-up: Integer.
-    0: Disable the internal pull-up
-    1: Enable the internal pull-up
+    0: MXS_PULL_DISABLE - Disable the internal pull-up
+    1: MXS_PULL_ENABLE  - Enable the internal pull-up
 
 Note that when enabling the pull-up, the internal pad keeper gets disabled.
 Also, some pins doesn't have a pull up, in that case, setting the fsl,pull-up
@@ -85,23 +85,32 @@ pinctrl@80018000 {
         mmc0_8bit_pins_a: mmc0-8bit@0 {
                 reg = <0>;
                 fsl,pinmux-ids = <
-                        0x2000 0x2010 0x2020 0x2030
-                        0x2040 0x2050 0x2060 0x2070
-                        0x2080 0x2090 0x20a0>;
-                fsl,drive-strength = <1>;
-                fsl,voltage = <1>;
-                fsl,pull-up = <1>;
+                        MX28_PAD_SSP0_DATA0__SSP0_D0
+                        MX28_PAD_SSP0_DATA1__SSP0_D1
+                        MX28_PAD_SSP0_DATA2__SSP0_D2
+                        MX28_PAD_SSP0_DATA3__SSP0_D3
+                        MX28_PAD_SSP0_DATA4__SSP0_D4
+                        MX28_PAD_SSP0_DATA5__SSP0_D5
+                        MX28_PAD_SSP0_DATA6__SSP0_D6
+                        MX28_PAD_SSP0_DATA7__SSP0_D7
+                        MX28_PAD_SSP0_CMD__SSP0_CMD
+                        MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT
+                        MX28_PAD_SSP0_SCK__SSP0_SCK
+                >;
+                fsl,drive-strength = <MXS_DRIVE_4mA>;
+                fsl,voltage = <MXS_VOLTAGE_HIGH>;
+                fsl,pull-up = <MXS_PULL_ENABLE>;
         };
 
         mmc_cd_cfg: mmc-cd-cfg {
-                fsl,pinmux-ids = <0x2090>;
-                fsl,pull-up = <0>;
+                fsl,pinmux-ids = <MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT>;
+                fsl,pull-up = <MXS_PULL_DISABLE>;
         };
 
         mmc_sck_cfg: mmc-sck-cfg {
-                fsl,pinmux-ids = <0x20a0>;
-                fsl,drive-strength = <2>;
-                fsl,pull-up = <0>;
+                fsl,pinmux-ids = <MX28_PAD_SSP0_SCK__SSP0_SCK>;
+                fsl,drive-strength = <MXS_DRIVE_12mA>;
+                fsl,pull-up = <MXS_PULL_DISABLE>;
         };
 };
 
@@ -112,811 +121,7 @@ adjusting the configuration for pins card-detection and clock from what group
 node mmc0-8bit defines.  Only the configuration properties to be adjusted need
 to be listed in the config nodes.
 
-Valid values for i.MX28 pinmux-id:
-
-pinmux                                          id
-------                                          --
-MX28_PAD_GPMI_D00__GPMI_D0                      0x0000
-MX28_PAD_GPMI_D01__GPMI_D1                      0x0010
-MX28_PAD_GPMI_D02__GPMI_D2                      0x0020
-MX28_PAD_GPMI_D03__GPMI_D3                      0x0030
-MX28_PAD_GPMI_D04__GPMI_D4                      0x0040
-MX28_PAD_GPMI_D05__GPMI_D5                      0x0050
-MX28_PAD_GPMI_D06__GPMI_D6                      0x0060
-MX28_PAD_GPMI_D07__GPMI_D7                      0x0070
-MX28_PAD_GPMI_CE0N__GPMI_CE0N                   0x0100
-MX28_PAD_GPMI_CE1N__GPMI_CE1N                   0x0110
-MX28_PAD_GPMI_CE2N__GPMI_CE2N                   0x0120
-MX28_PAD_GPMI_CE3N__GPMI_CE3N                   0x0130
-MX28_PAD_GPMI_RDY0__GPMI_READY0                 0x0140
-MX28_PAD_GPMI_RDY1__GPMI_READY1                 0x0150
-MX28_PAD_GPMI_RDY2__GPMI_READY2                 0x0160
-MX28_PAD_GPMI_RDY3__GPMI_READY3                 0x0170
-MX28_PAD_GPMI_RDN__GPMI_RDN                     0x0180
-MX28_PAD_GPMI_WRN__GPMI_WRN                     0x0190
-MX28_PAD_GPMI_ALE__GPMI_ALE                     0x01a0
-MX28_PAD_GPMI_CLE__GPMI_CLE                     0x01b0
-MX28_PAD_GPMI_RESETN__GPMI_RESETN               0x01c0
-MX28_PAD_LCD_D00__LCD_D0                        0x1000
-MX28_PAD_LCD_D01__LCD_D1                        0x1010
-MX28_PAD_LCD_D02__LCD_D2                        0x1020
-MX28_PAD_LCD_D03__LCD_D3                        0x1030
-MX28_PAD_LCD_D04__LCD_D4                        0x1040
-MX28_PAD_LCD_D05__LCD_D5                        0x1050
-MX28_PAD_LCD_D06__LCD_D6                        0x1060
-MX28_PAD_LCD_D07__LCD_D7                        0x1070
-MX28_PAD_LCD_D08__LCD_D8                        0x1080
-MX28_PAD_LCD_D09__LCD_D9                        0x1090
-MX28_PAD_LCD_D10__LCD_D10                       0x10a0
-MX28_PAD_LCD_D11__LCD_D11                       0x10b0
-MX28_PAD_LCD_D12__LCD_D12                       0x10c0
-MX28_PAD_LCD_D13__LCD_D13                       0x10d0
-MX28_PAD_LCD_D14__LCD_D14                       0x10e0
-MX28_PAD_LCD_D15__LCD_D15                       0x10f0
-MX28_PAD_LCD_D16__LCD_D16                       0x1100
-MX28_PAD_LCD_D17__LCD_D17                       0x1110
-MX28_PAD_LCD_D18__LCD_D18                       0x1120
-MX28_PAD_LCD_D19__LCD_D19                       0x1130
-MX28_PAD_LCD_D20__LCD_D20                       0x1140
-MX28_PAD_LCD_D21__LCD_D21                       0x1150
-MX28_PAD_LCD_D22__LCD_D22                       0x1160
-MX28_PAD_LCD_D23__LCD_D23                       0x1170
-MX28_PAD_LCD_RD_E__LCD_RD_E                     0x1180
-MX28_PAD_LCD_WR_RWN__LCD_WR_RWN                 0x1190
-MX28_PAD_LCD_RS__LCD_RS                         0x11a0
-MX28_PAD_LCD_CS__LCD_CS                         0x11b0
-MX28_PAD_LCD_VSYNC__LCD_VSYNC                   0x11c0
-MX28_PAD_LCD_HSYNC__LCD_HSYNC                   0x11d0
-MX28_PAD_LCD_DOTCLK__LCD_DOTCLK                 0x11e0
-MX28_PAD_LCD_ENABLE__LCD_ENABLE                 0x11f0
-MX28_PAD_SSP0_DATA0__SSP0_D0                    0x2000
-MX28_PAD_SSP0_DATA1__SSP0_D1                    0x2010
-MX28_PAD_SSP0_DATA2__SSP0_D2                    0x2020
-MX28_PAD_SSP0_DATA3__SSP0_D3                    0x2030
-MX28_PAD_SSP0_DATA4__SSP0_D4                    0x2040
-MX28_PAD_SSP0_DATA5__SSP0_D5                    0x2050
-MX28_PAD_SSP0_DATA6__SSP0_D6                    0x2060
-MX28_PAD_SSP0_DATA7__SSP0_D7                    0x2070
-MX28_PAD_SSP0_CMD__SSP0_CMD                     0x2080
-MX28_PAD_SSP0_DETECT__SSP0_CARD_DETECT          0x2090
-MX28_PAD_SSP0_SCK__SSP0_SCK                     0x20a0
-MX28_PAD_SSP1_SCK__SSP1_SCK                     0x20c0
-MX28_PAD_SSP1_CMD__SSP1_CMD                     0x20d0
-MX28_PAD_SSP1_DATA0__SSP1_D0                    0x20e0
-MX28_PAD_SSP1_DATA3__SSP1_D3                    0x20f0
-MX28_PAD_SSP2_SCK__SSP2_SCK                     0x2100
-MX28_PAD_SSP2_MOSI__SSP2_CMD                    0x2110
-MX28_PAD_SSP2_MISO__SSP2_D0                     0x2120
-MX28_PAD_SSP2_SS0__SSP2_D3                      0x2130
-MX28_PAD_SSP2_SS1__SSP2_D4                      0x2140
-MX28_PAD_SSP2_SS2__SSP2_D5                      0x2150
-MX28_PAD_SSP3_SCK__SSP3_SCK                     0x2180
-MX28_PAD_SSP3_MOSI__SSP3_CMD                    0x2190
-MX28_PAD_SSP3_MISO__SSP3_D0                     0x21a0
-MX28_PAD_SSP3_SS0__SSP3_D3                      0x21b0
-MX28_PAD_AUART0_RX__AUART0_RX                   0x3000
-MX28_PAD_AUART0_TX__AUART0_TX                   0x3010
-MX28_PAD_AUART0_CTS__AUART0_CTS                 0x3020
-MX28_PAD_AUART0_RTS__AUART0_RTS                 0x3030
-MX28_PAD_AUART1_RX__AUART1_RX                   0x3040
-MX28_PAD_AUART1_TX__AUART1_TX                   0x3050
-MX28_PAD_AUART1_CTS__AUART1_CTS                 0x3060
-MX28_PAD_AUART1_RTS__AUART1_RTS                 0x3070
-MX28_PAD_AUART2_RX__AUART2_RX                   0x3080
-MX28_PAD_AUART2_TX__AUART2_TX                   0x3090
-MX28_PAD_AUART2_CTS__AUART2_CTS                 0x30a0
-MX28_PAD_AUART2_RTS__AUART2_RTS                 0x30b0
-MX28_PAD_AUART3_RX__AUART3_RX                   0x30c0
-MX28_PAD_AUART3_TX__AUART3_TX                   0x30d0
-MX28_PAD_AUART3_CTS__AUART3_CTS                 0x30e0
-MX28_PAD_AUART3_RTS__AUART3_RTS                 0x30f0
-MX28_PAD_PWM0__PWM_0                            0x3100
-MX28_PAD_PWM1__PWM_1                            0x3110
-MX28_PAD_PWM2__PWM_2                            0x3120
-MX28_PAD_SAIF0_MCLK__SAIF0_MCLK                 0x3140
-MX28_PAD_SAIF0_LRCLK__SAIF0_LRCLK               0x3150
-MX28_PAD_SAIF0_BITCLK__SAIF0_BITCLK             0x3160
-MX28_PAD_SAIF0_SDATA0__SAIF0_SDATA0             0x3170
-MX28_PAD_I2C0_SCL__I2C0_SCL                     0x3180
-MX28_PAD_I2C0_SDA__I2C0_SDA                     0x3190
-MX28_PAD_SAIF1_SDATA0__SAIF1_SDATA0             0x31a0
-MX28_PAD_SPDIF__SPDIF_TX                        0x31b0
-MX28_PAD_PWM3__PWM_3                            0x31c0
-MX28_PAD_PWM4__PWM_4                            0x31d0
-MX28_PAD_LCD_RESET__LCD_RESET                   0x31e0
-MX28_PAD_ENET0_MDC__ENET0_MDC                   0x4000
-MX28_PAD_ENET0_MDIO__ENET0_MDIO                 0x4010
-MX28_PAD_ENET0_RX_EN__ENET0_RX_EN               0x4020
-MX28_PAD_ENET0_RXD0__ENET0_RXD0                 0x4030
-MX28_PAD_ENET0_RXD1__ENET0_RXD1                 0x4040
-MX28_PAD_ENET0_TX_CLK__ENET0_TX_CLK             0x4050
-MX28_PAD_ENET0_TX_EN__ENET0_TX_EN               0x4060
-MX28_PAD_ENET0_TXD0__ENET0_TXD0                 0x4070
-MX28_PAD_ENET0_TXD1__ENET0_TXD1                 0x4080
-MX28_PAD_ENET0_RXD2__ENET0_RXD2                 0x4090
-MX28_PAD_ENET0_RXD3__ENET0_RXD3                 0x40a0
-MX28_PAD_ENET0_TXD2__ENET0_TXD2                 0x40b0
-MX28_PAD_ENET0_TXD3__ENET0_TXD3                 0x40c0
-MX28_PAD_ENET0_RX_CLK__ENET0_RX_CLK             0x40d0
-MX28_PAD_ENET0_COL__ENET0_COL                   0x40e0
-MX28_PAD_ENET0_CRS__ENET0_CRS                   0x40f0
-MX28_PAD_ENET_CLK__CLKCTRL_ENET                 0x4100
-MX28_PAD_JTAG_RTCK__JTAG_RTCK                   0x4140
-MX28_PAD_EMI_D00__EMI_DATA0                     0x5000
-MX28_PAD_EMI_D01__EMI_DATA1                     0x5010
-MX28_PAD_EMI_D02__EMI_DATA2                     0x5020
-MX28_PAD_EMI_D03__EMI_DATA3                     0x5030
-MX28_PAD_EMI_D04__EMI_DATA4                     0x5040
-MX28_PAD_EMI_D05__EMI_DATA5                     0x5050
-MX28_PAD_EMI_D06__EMI_DATA6                     0x5060
-MX28_PAD_EMI_D07__EMI_DATA7                     0x5070
-MX28_PAD_EMI_D08__EMI_DATA8                     0x5080
-MX28_PAD_EMI_D09__EMI_DATA9                     0x5090
-MX28_PAD_EMI_D10__EMI_DATA10                    0x50a0
-MX28_PAD_EMI_D11__EMI_DATA11                    0x50b0
-MX28_PAD_EMI_D12__EMI_DATA12                    0x50c0
-MX28_PAD_EMI_D13__EMI_DATA13                    0x50d0
-MX28_PAD_EMI_D14__EMI_DATA14                    0x50e0
-MX28_PAD_EMI_D15__EMI_DATA15                    0x50f0
-MX28_PAD_EMI_ODT0__EMI_ODT0                     0x5100
-MX28_PAD_EMI_DQM0__EMI_DQM0                     0x5110
-MX28_PAD_EMI_ODT1__EMI_ODT1                     0x5120
-MX28_PAD_EMI_DQM1__EMI_DQM1                     0x5130
-MX28_PAD_EMI_DDR_OPEN_FB__EMI_DDR_OPEN_FEEDBACK 0x5140
-MX28_PAD_EMI_CLK__EMI_CLK                       0x5150
-MX28_PAD_EMI_DQS0__EMI_DQS0                     0x5160
-MX28_PAD_EMI_DQS1__EMI_DQS1                     0x5170
-MX28_PAD_EMI_DDR_OPEN__EMI_DDR_OPEN             0x51a0
-MX28_PAD_EMI_A00__EMI_ADDR0                     0x6000
-MX28_PAD_EMI_A01__EMI_ADDR1                     0x6010
-MX28_PAD_EMI_A02__EMI_ADDR2                     0x6020
-MX28_PAD_EMI_A03__EMI_ADDR3                     0x6030
-MX28_PAD_EMI_A04__EMI_ADDR4                     0x6040
-MX28_PAD_EMI_A05__EMI_ADDR5                     0x6050
-MX28_PAD_EMI_A06__EMI_ADDR6                     0x6060
-MX28_PAD_EMI_A07__EMI_ADDR7                     0x6070
-MX28_PAD_EMI_A08__EMI_ADDR8                     0x6080
-MX28_PAD_EMI_A09__EMI_ADDR9                     0x6090
-MX28_PAD_EMI_A10__EMI_ADDR10                    0x60a0
-MX28_PAD_EMI_A11__EMI_ADDR11                    0x60b0
-MX28_PAD_EMI_A12__EMI_ADDR12                    0x60c0
-MX28_PAD_EMI_A13__EMI_ADDR13                    0x60d0
-MX28_PAD_EMI_A14__EMI_ADDR14                    0x60e0
-MX28_PAD_EMI_BA0__EMI_BA0                       0x6100
-MX28_PAD_EMI_BA1__EMI_BA1                       0x6110
-MX28_PAD_EMI_BA2__EMI_BA2                       0x6120
-MX28_PAD_EMI_CASN__EMI_CASN                     0x6130
-MX28_PAD_EMI_RASN__EMI_RASN                     0x6140
-MX28_PAD_EMI_WEN__EMI_WEN                       0x6150
-MX28_PAD_EMI_CE0N__EMI_CE0N                     0x6160
-MX28_PAD_EMI_CE1N__EMI_CE1N                     0x6170
-MX28_PAD_EMI_CKE__EMI_CKE                       0x6180
-MX28_PAD_GPMI_D00__SSP1_D0                      0x0001
-MX28_PAD_GPMI_D01__SSP1_D1                      0x0011
-MX28_PAD_GPMI_D02__SSP1_D2                      0x0021
-MX28_PAD_GPMI_D03__SSP1_D3                      0x0031
-MX28_PAD_GPMI_D04__SSP1_D4                      0x0041
-MX28_PAD_GPMI_D05__SSP1_D5                      0x0051
-MX28_PAD_GPMI_D06__SSP1_D6                      0x0061
-MX28_PAD_GPMI_D07__SSP1_D7                      0x0071
-MX28_PAD_GPMI_CE0N__SSP3_D0                     0x0101
-MX28_PAD_GPMI_CE1N__SSP3_D3                     0x0111
-MX28_PAD_GPMI_CE2N__CAN1_TX                     0x0121
-MX28_PAD_GPMI_CE3N__CAN1_RX                     0x0131
-MX28_PAD_GPMI_RDY0__SSP1_CARD_DETECT            0x0141
-MX28_PAD_GPMI_RDY1__SSP1_CMD                    0x0151
-MX28_PAD_GPMI_RDY2__CAN0_TX                     0x0161
-MX28_PAD_GPMI_RDY3__CAN0_RX                     0x0171
-MX28_PAD_GPMI_RDN__SSP3_SCK                     0x0181
-MX28_PAD_GPMI_WRN__SSP1_SCK                     0x0191
-MX28_PAD_GPMI_ALE__SSP3_D1                      0x01a1
-MX28_PAD_GPMI_CLE__SSP3_D2                      0x01b1
-MX28_PAD_GPMI_RESETN__SSP3_CMD                  0x01c1
-MX28_PAD_LCD_D03__ETM_DA8                       0x1031
-MX28_PAD_LCD_D04__ETM_DA9                       0x1041
-MX28_PAD_LCD_D08__ETM_DA3                       0x1081
-MX28_PAD_LCD_D09__ETM_DA4                       0x1091
-MX28_PAD_LCD_D20__ENET1_1588_EVENT2_OUT         0x1141
-MX28_PAD_LCD_D21__ENET1_1588_EVENT2_IN          0x1151
-MX28_PAD_LCD_D22__ENET1_1588_EVENT3_OUT         0x1161
-MX28_PAD_LCD_D23__ENET1_1588_EVENT3_IN          0x1171
-MX28_PAD_LCD_RD_E__LCD_VSYNC                    0x1181
-MX28_PAD_LCD_WR_RWN__LCD_HSYNC                  0x1191
-MX28_PAD_LCD_RS__LCD_DOTCLK                     0x11a1
-MX28_PAD_LCD_CS__LCD_ENABLE                     0x11b1
-MX28_PAD_LCD_VSYNC__SAIF1_SDATA0                0x11c1
-MX28_PAD_LCD_HSYNC__SAIF1_SDATA1                0x11d1
-MX28_PAD_LCD_DOTCLK__SAIF1_MCLK                 0x11e1
-MX28_PAD_SSP0_DATA4__SSP2_D0                    0x2041
-MX28_PAD_SSP0_DATA5__SSP2_D3                    0x2051
-MX28_PAD_SSP0_DATA6__SSP2_CMD                   0x2061
-MX28_PAD_SSP0_DATA7__SSP2_SCK                   0x2071
-MX28_PAD_SSP1_SCK__SSP2_D1                      0x20c1
-MX28_PAD_SSP1_CMD__SSP2_D2                      0x20d1
-MX28_PAD_SSP1_DATA0__SSP2_D6                    0x20e1
-MX28_PAD_SSP1_DATA3__SSP2_D7                    0x20f1
-MX28_PAD_SSP2_SCK__AUART2_RX                    0x2101
-MX28_PAD_SSP2_MOSI__AUART2_TX                   0x2111
-MX28_PAD_SSP2_MISO__AUART3_RX                   0x2121
-MX28_PAD_SSP2_SS0__AUART3_TX                    0x2131
-MX28_PAD_SSP2_SS1__SSP2_D1                      0x2141
-MX28_PAD_SSP2_SS2__SSP2_D2                      0x2151
-MX28_PAD_SSP3_SCK__AUART4_TX                    0x2181
-MX28_PAD_SSP3_MOSI__AUART4_RX                   0x2191
-MX28_PAD_SSP3_MISO__AUART4_RTS                  0x21a1
-MX28_PAD_SSP3_SS0__AUART4_CTS                   0x21b1
-MX28_PAD_AUART0_RX__I2C0_SCL                    0x3001
-MX28_PAD_AUART0_TX__I2C0_SDA                    0x3011
-MX28_PAD_AUART0_CTS__AUART4_RX                  0x3021
-MX28_PAD_AUART0_RTS__AUART4_TX                  0x3031
-MX28_PAD_AUART1_RX__SSP2_CARD_DETECT            0x3041
-MX28_PAD_AUART1_TX__SSP3_CARD_DETECT            0x3051
-MX28_PAD_AUART1_CTS__USB0_OVERCURRENT           0x3061
-MX28_PAD_AUART1_RTS__USB0_ID                    0x3071
-MX28_PAD_AUART2_RX__SSP3_D1                     0x3081
-MX28_PAD_AUART2_TX__SSP3_D2                     0x3091
-MX28_PAD_AUART2_CTS__I2C1_SCL                   0x30a1
-MX28_PAD_AUART2_RTS__I2C1_SDA                   0x30b1
-MX28_PAD_AUART3_RX__CAN0_TX                     0x30c1
-MX28_PAD_AUART3_TX__CAN0_RX                     0x30d1
-MX28_PAD_AUART3_CTS__CAN1_TX                    0x30e1
-MX28_PAD_AUART3_RTS__CAN1_RX                    0x30f1
-MX28_PAD_PWM0__I2C1_SCL                         0x3101
-MX28_PAD_PWM1__I2C1_SDA                         0x3111
-MX28_PAD_PWM2__USB0_ID                          0x3121
-MX28_PAD_SAIF0_MCLK__PWM_3                      0x3141
-MX28_PAD_SAIF0_LRCLK__PWM_4                     0x3151
-MX28_PAD_SAIF0_BITCLK__PWM_5                    0x3161
-MX28_PAD_SAIF0_SDATA0__PWM_6                    0x3171
-MX28_PAD_I2C0_SCL__TIMROT_ROTARYA               0x3181
-MX28_PAD_I2C0_SDA__TIMROT_ROTARYB               0x3191
-MX28_PAD_SAIF1_SDATA0__PWM_7                    0x31a1
-MX28_PAD_LCD_RESET__LCD_VSYNC                   0x31e1
-MX28_PAD_ENET0_MDC__GPMI_CE4N                   0x4001
-MX28_PAD_ENET0_MDIO__GPMI_CE5N                  0x4011
-MX28_PAD_ENET0_RX_EN__GPMI_CE6N                 0x4021
-MX28_PAD_ENET0_RXD0__GPMI_CE7N                  0x4031
-MX28_PAD_ENET0_RXD1__GPMI_READY4                0x4041
-MX28_PAD_ENET0_TX_CLK__HSADC_TRIGGER            0x4051
-MX28_PAD_ENET0_TX_EN__GPMI_READY5               0x4061
-MX28_PAD_ENET0_TXD0__GPMI_READY6                0x4071
-MX28_PAD_ENET0_TXD1__GPMI_READY7                0x4081
-MX28_PAD_ENET0_RXD2__ENET1_RXD0                 0x4091
-MX28_PAD_ENET0_RXD3__ENET1_RXD1                 0x40a1
-MX28_PAD_ENET0_TXD2__ENET1_TXD0                 0x40b1
-MX28_PAD_ENET0_TXD3__ENET1_TXD1                 0x40c1
-MX28_PAD_ENET0_RX_CLK__ENET0_RX_ER              0x40d1
-MX28_PAD_ENET0_COL__ENET1_TX_EN                 0x40e1
-MX28_PAD_ENET0_CRS__ENET1_RX_EN                 0x40f1
-MX28_PAD_GPMI_CE2N__ENET0_RX_ER                 0x0122
-MX28_PAD_GPMI_CE3N__SAIF1_MCLK                  0x0132
-MX28_PAD_GPMI_RDY0__USB0_ID                     0x0142
-MX28_PAD_GPMI_RDY2__ENET0_TX_ER                 0x0162
-MX28_PAD_GPMI_RDY3__HSADC_TRIGGER               0x0172
-MX28_PAD_GPMI_ALE__SSP3_D4                      0x01a2
-MX28_PAD_GPMI_CLE__SSP3_D5                      0x01b2
-MX28_PAD_LCD_D00__ETM_DA0                       0x1002
-MX28_PAD_LCD_D01__ETM_DA1                       0x1012
-MX28_PAD_LCD_D02__ETM_DA2                       0x1022
-MX28_PAD_LCD_D03__ETM_DA3                       0x1032
-MX28_PAD_LCD_D04__ETM_DA4                       0x1042
-MX28_PAD_LCD_D05__ETM_DA5                       0x1052
-MX28_PAD_LCD_D06__ETM_DA6                       0x1062
-MX28_PAD_LCD_D07__ETM_DA7                       0x1072
-MX28_PAD_LCD_D08__ETM_DA8                       0x1082
-MX28_PAD_LCD_D09__ETM_DA9                       0x1092
-MX28_PAD_LCD_D10__ETM_DA10                      0x10a2
-MX28_PAD_LCD_D11__ETM_DA11                      0x10b2
-MX28_PAD_LCD_D12__ETM_DA12                      0x10c2
-MX28_PAD_LCD_D13__ETM_DA13                      0x10d2
-MX28_PAD_LCD_D14__ETM_DA14                      0x10e2
-MX28_PAD_LCD_D15__ETM_DA15                      0x10f2
-MX28_PAD_LCD_D16__ETM_DA7                       0x1102
-MX28_PAD_LCD_D17__ETM_DA6                       0x1112
-MX28_PAD_LCD_D18__ETM_DA5                       0x1122
-MX28_PAD_LCD_D19__ETM_DA4                       0x1132
-MX28_PAD_LCD_D20__ETM_DA3                       0x1142
-MX28_PAD_LCD_D21__ETM_DA2                       0x1152
-MX28_PAD_LCD_D22__ETM_DA1                       0x1162
-MX28_PAD_LCD_D23__ETM_DA0                       0x1172
-MX28_PAD_LCD_RD_E__ETM_TCTL                     0x1182
-MX28_PAD_LCD_WR_RWN__ETM_TCLK                   0x1192
-MX28_PAD_LCD_HSYNC__ETM_TCTL                    0x11d2
-MX28_PAD_LCD_DOTCLK__ETM_TCLK                   0x11e2
-MX28_PAD_SSP1_SCK__ENET0_1588_EVENT2_OUT        0x20c2
-MX28_PAD_SSP1_CMD__ENET0_1588_EVENT2_IN         0x20d2
-MX28_PAD_SSP1_DATA0__ENET0_1588_EVENT3_OUT      0x20e2
-MX28_PAD_SSP1_DATA3__ENET0_1588_EVENT3_IN       0x20f2
-MX28_PAD_SSP2_SCK__SAIF0_SDATA1                 0x2102
-MX28_PAD_SSP2_MOSI__SAIF0_SDATA2                0x2112
-MX28_PAD_SSP2_MISO__SAIF1_SDATA1                0x2122
-MX28_PAD_SSP2_SS0__SAIF1_SDATA2                 0x2132
-MX28_PAD_SSP2_SS1__USB1_OVERCURRENT             0x2142
-MX28_PAD_SSP2_SS2__USB0_OVERCURRENT             0x2152
-MX28_PAD_SSP3_SCK__ENET1_1588_EVENT0_OUT        0x2182
-MX28_PAD_SSP3_MOSI__ENET1_1588_EVENT0_IN        0x2192
-MX28_PAD_SSP3_MISO__ENET1_1588_EVENT1_OUT       0x21a2
-MX28_PAD_SSP3_SS0__ENET1_1588_EVENT1_IN         0x21b2
-MX28_PAD_AUART0_RX__DUART_CTS                   0x3002
-MX28_PAD_AUART0_TX__DUART_RTS                   0x3012
-MX28_PAD_AUART0_CTS__DUART_RX                   0x3022
-MX28_PAD_AUART0_RTS__DUART_TX                   0x3032
-MX28_PAD_AUART1_RX__PWM_0                       0x3042
-MX28_PAD_AUART1_TX__PWM_1                       0x3052
-MX28_PAD_AUART1_CTS__TIMROT_ROTARYA             0x3062
-MX28_PAD_AUART1_RTS__TIMROT_ROTARYB             0x3072
-MX28_PAD_AUART2_RX__SSP3_D4                     0x3082
-MX28_PAD_AUART2_TX__SSP3_D5                     0x3092
-MX28_PAD_AUART2_CTS__SAIF1_BITCLK               0x30a2
-MX28_PAD_AUART2_RTS__SAIF1_LRCLK                0x30b2
-MX28_PAD_AUART3_RX__ENET0_1588_EVENT0_OUT       0x30c2
-MX28_PAD_AUART3_TX__ENET0_1588_EVENT0_IN        0x30d2
-MX28_PAD_AUART3_CTS__ENET0_1588_EVENT1_OUT      0x30e2
-MX28_PAD_AUART3_RTS__ENET0_1588_EVENT1_IN       0x30f2
-MX28_PAD_PWM0__DUART_RX                         0x3102
-MX28_PAD_PWM1__DUART_TX                         0x3112
-MX28_PAD_PWM2__USB1_OVERCURRENT                 0x3122
-MX28_PAD_SAIF0_MCLK__AUART4_CTS                 0x3142
-MX28_PAD_SAIF0_LRCLK__AUART4_RTS                0x3152
-MX28_PAD_SAIF0_BITCLK__AUART4_RX                0x3162
-MX28_PAD_SAIF0_SDATA0__AUART4_TX                0x3172
-MX28_PAD_I2C0_SCL__DUART_RX                     0x3182
-MX28_PAD_I2C0_SDA__DUART_TX                     0x3192
-MX28_PAD_SAIF1_SDATA0__SAIF0_SDATA1             0x31a2
-MX28_PAD_SPDIF__ENET1_RX_ER                     0x31b2
-MX28_PAD_ENET0_MDC__SAIF0_SDATA1                0x4002
-MX28_PAD_ENET0_MDIO__SAIF0_SDATA2               0x4012
-MX28_PAD_ENET0_RX_EN__SAIF1_SDATA1              0x4022
-MX28_PAD_ENET0_RXD0__SAIF1_SDATA2               0x4032
-MX28_PAD_ENET0_TX_CLK__ENET0_1588_EVENT2_OUT    0x4052
-MX28_PAD_ENET0_RXD2__ENET0_1588_EVENT0_OUT      0x4092
-MX28_PAD_ENET0_RXD3__ENET0_1588_EVENT0_IN       0x40a2
-MX28_PAD_ENET0_TXD2__ENET0_1588_EVENT1_OUT      0x40b2
-MX28_PAD_ENET0_TXD3__ENET0_1588_EVENT1_IN       0x40c2
-MX28_PAD_ENET0_RX_CLK__ENET0_1588_EVENT2_IN     0x40d2
-MX28_PAD_ENET0_COL__ENET0_1588_EVENT3_OUT       0x40e2
-MX28_PAD_ENET0_CRS__ENET0_1588_EVENT3_IN        0x40f2
-MX28_PAD_GPMI_D00__GPIO_0_0                     0x0003
-MX28_PAD_GPMI_D01__GPIO_0_1                     0x0013
-MX28_PAD_GPMI_D02__GPIO_0_2                     0x0023
-MX28_PAD_GPMI_D03__GPIO_0_3                     0x0033
-MX28_PAD_GPMI_D04__GPIO_0_4                     0x0043
-MX28_PAD_GPMI_D05__GPIO_0_5                     0x0053
-MX28_PAD_GPMI_D06__GPIO_0_6                     0x0063
-MX28_PAD_GPMI_D07__GPIO_0_7                     0x0073
-MX28_PAD_GPMI_CE0N__GPIO_0_16                   0x0103
-MX28_PAD_GPMI_CE1N__GPIO_0_17                   0x0113
-MX28_PAD_GPMI_CE2N__GPIO_0_18                   0x0123
-MX28_PAD_GPMI_CE3N__GPIO_0_19                   0x0133
-MX28_PAD_GPMI_RDY0__GPIO_0_20                   0x0143
-MX28_PAD_GPMI_RDY1__GPIO_0_21                   0x0153
-MX28_PAD_GPMI_RDY2__GPIO_0_22                   0x0163
-MX28_PAD_GPMI_RDY3__GPIO_0_23                   0x0173
-MX28_PAD_GPMI_RDN__GPIO_0_24                    0x0183
-MX28_PAD_GPMI_WRN__GPIO_0_25                    0x0193
-MX28_PAD_GPMI_ALE__GPIO_0_26                    0x01a3
-MX28_PAD_GPMI_CLE__GPIO_0_27                    0x01b3
-MX28_PAD_GPMI_RESETN__GPIO_0_28                 0x01c3
-MX28_PAD_LCD_D00__GPIO_1_0                      0x1003
-MX28_PAD_LCD_D01__GPIO_1_1                      0x1013
-MX28_PAD_LCD_D02__GPIO_1_2                      0x1023
-MX28_PAD_LCD_D03__GPIO_1_3                      0x1033
-MX28_PAD_LCD_D04__GPIO_1_4                      0x1043
-MX28_PAD_LCD_D05__GPIO_1_5                      0x1053
-MX28_PAD_LCD_D06__GPIO_1_6                      0x1063
-MX28_PAD_LCD_D07__GPIO_1_7                      0x1073
-MX28_PAD_LCD_D08__GPIO_1_8                      0x1083
-MX28_PAD_LCD_D09__GPIO_1_9                      0x1093
-MX28_PAD_LCD_D10__GPIO_1_10                     0x10a3
-MX28_PAD_LCD_D11__GPIO_1_11                     0x10b3
-MX28_PAD_LCD_D12__GPIO_1_12                     0x10c3
-MX28_PAD_LCD_D13__GPIO_1_13                     0x10d3
-MX28_PAD_LCD_D14__GPIO_1_14                     0x10e3
-MX28_PAD_LCD_D15__GPIO_1_15                     0x10f3
-MX28_PAD_LCD_D16__GPIO_1_16                     0x1103
-MX28_PAD_LCD_D17__GPIO_1_17                     0x1113
-MX28_PAD_LCD_D18__GPIO_1_18                     0x1123
-MX28_PAD_LCD_D19__GPIO_1_19                     0x1133
-MX28_PAD_LCD_D20__GPIO_1_20                     0x1143
-MX28_PAD_LCD_D21__GPIO_1_21                     0x1153
-MX28_PAD_LCD_D22__GPIO_1_22                     0x1163
-MX28_PAD_LCD_D23__GPIO_1_23                     0x1173
-MX28_PAD_LCD_RD_E__GPIO_1_24                    0x1183
-MX28_PAD_LCD_WR_RWN__GPIO_1_25                  0x1193
-MX28_PAD_LCD_RS__GPIO_1_26                      0x11a3
-MX28_PAD_LCD_CS__GPIO_1_27                      0x11b3
-MX28_PAD_LCD_VSYNC__GPIO_1_28                   0x11c3
-MX28_PAD_LCD_HSYNC__GPIO_1_29                   0x11d3
-MX28_PAD_LCD_DOTCLK__GPIO_1_30                  0x11e3
-MX28_PAD_LCD_ENABLE__GPIO_1_31                  0x11f3
-MX28_PAD_SSP0_DATA0__GPIO_2_0                   0x2003
-MX28_PAD_SSP0_DATA1__GPIO_2_1                   0x2013
-MX28_PAD_SSP0_DATA2__GPIO_2_2                   0x2023
-MX28_PAD_SSP0_DATA3__GPIO_2_3                   0x2033
-MX28_PAD_SSP0_DATA4__GPIO_2_4                   0x2043
-MX28_PAD_SSP0_DATA5__GPIO_2_5                   0x2053
-MX28_PAD_SSP0_DATA6__GPIO_2_6                   0x2063
-MX28_PAD_SSP0_DATA7__GPIO_2_7                   0x2073
-MX28_PAD_SSP0_CMD__GPIO_2_8                     0x2083
-MX28_PAD_SSP0_DETECT__GPIO_2_9                  0x2093
-MX28_PAD_SSP0_SCK__GPIO_2_10                    0x20a3
-MX28_PAD_SSP1_SCK__GPIO_2_12                    0x20c3
-MX28_PAD_SSP1_CMD__GPIO_2_13                    0x20d3
-MX28_PAD_SSP1_DATA0__GPIO_2_14                  0x20e3
-MX28_PAD_SSP1_DATA3__GPIO_2_15                  0x20f3
-MX28_PAD_SSP2_SCK__GPIO_2_16                    0x2103
-MX28_PAD_SSP2_MOSI__GPIO_2_17                   0x2113
-MX28_PAD_SSP2_MISO__GPIO_2_18                   0x2123
-MX28_PAD_SSP2_SS0__GPIO_2_19                    0x2133
-MX28_PAD_SSP2_SS1__GPIO_2_20                    0x2143
-MX28_PAD_SSP2_SS2__GPIO_2_21                    0x2153
-MX28_PAD_SSP3_SCK__GPIO_2_24                    0x2183
-MX28_PAD_SSP3_MOSI__GPIO_2_25                   0x2193
-MX28_PAD_SSP3_MISO__GPIO_2_26                   0x21a3
-MX28_PAD_SSP3_SS0__GPIO_2_27                    0x21b3
-MX28_PAD_AUART0_RX__GPIO_3_0                    0x3003
-MX28_PAD_AUART0_TX__GPIO_3_1                    0x3013
-MX28_PAD_AUART0_CTS__GPIO_3_2                   0x3023
-MX28_PAD_AUART0_RTS__GPIO_3_3                   0x3033
-MX28_PAD_AUART1_RX__GPIO_3_4                    0x3043
-MX28_PAD_AUART1_TX__GPIO_3_5                    0x3053
-MX28_PAD_AUART1_CTS__GPIO_3_6                   0x3063
-MX28_PAD_AUART1_RTS__GPIO_3_7                   0x3073
-MX28_PAD_AUART2_RX__GPIO_3_8                    0x3083
-MX28_PAD_AUART2_TX__GPIO_3_9                    0x3093
-MX28_PAD_AUART2_CTS__GPIO_3_10                  0x30a3
-MX28_PAD_AUART2_RTS__GPIO_3_11                  0x30b3
-MX28_PAD_AUART3_RX__GPIO_3_12                   0x30c3
-MX28_PAD_AUART3_TX__GPIO_3_13                   0x30d3
-MX28_PAD_AUART3_CTS__GPIO_3_14                  0x30e3
-MX28_PAD_AUART3_RTS__GPIO_3_15                  0x30f3
-MX28_PAD_PWM0__GPIO_3_16                        0x3103
-MX28_PAD_PWM1__GPIO_3_17                        0x3113
-MX28_PAD_PWM2__GPIO_3_18                        0x3123
-MX28_PAD_SAIF0_MCLK__GPIO_3_20                  0x3143
-MX28_PAD_SAIF0_LRCLK__GPIO_3_21                 0x3153
-MX28_PAD_SAIF0_BITCLK__GPIO_3_22                0x3163
-MX28_PAD_SAIF0_SDATA0__GPIO_3_23                0x3173
-MX28_PAD_I2C0_SCL__GPIO_3_24                    0x3183
-MX28_PAD_I2C0_SDA__GPIO_3_25                    0x3193
-MX28_PAD_SAIF1_SDATA0__GPIO_3_26                0x31a3
-MX28_PAD_SPDIF__GPIO_3_27                       0x31b3
-MX28_PAD_PWM3__GPIO_3_28                        0x31c3
-MX28_PAD_PWM4__GPIO_3_29                        0x31d3
-MX28_PAD_LCD_RESET__GPIO_3_30                   0x31e3
-MX28_PAD_ENET0_MDC__GPIO_4_0                    0x4003
-MX28_PAD_ENET0_MDIO__GPIO_4_1                   0x4013
-MX28_PAD_ENET0_RX_EN__GPIO_4_2                  0x4023
-MX28_PAD_ENET0_RXD0__GPIO_4_3                   0x4033
-MX28_PAD_ENET0_RXD1__GPIO_4_4                   0x4043
-MX28_PAD_ENET0_TX_CLK__GPIO_4_5                 0x4053
-MX28_PAD_ENET0_TX_EN__GPIO_4_6                  0x4063
-MX28_PAD_ENET0_TXD0__GPIO_4_7                   0x4073
-MX28_PAD_ENET0_TXD1__GPIO_4_8                   0x4083
-MX28_PAD_ENET0_RXD2__GPIO_4_9                   0x4093
-MX28_PAD_ENET0_RXD3__GPIO_4_10                  0x40a3
-MX28_PAD_ENET0_TXD2__GPIO_4_11                  0x40b3
-MX28_PAD_ENET0_TXD3__GPIO_4_12                  0x40c3
-MX28_PAD_ENET0_RX_CLK__GPIO_4_13                0x40d3
-MX28_PAD_ENET0_COL__GPIO_4_14                   0x40e3
-MX28_PAD_ENET0_CRS__GPIO_4_15                   0x40f3
-MX28_PAD_ENET_CLK__GPIO_4_16                    0x4103
-MX28_PAD_JTAG_RTCK__GPIO_4_20                   0x4143
-
-Valid values for i.MX23 pinmux-id:
-
-pinmux                                          id
-------                                          --
-MX23_PAD_GPMI_D00__GPMI_D00                     0x0000
-MX23_PAD_GPMI_D01__GPMI_D01                     0x0010
-MX23_PAD_GPMI_D02__GPMI_D02                     0x0020
-MX23_PAD_GPMI_D03__GPMI_D03                     0x0030
-MX23_PAD_GPMI_D04__GPMI_D04                     0x0040
-MX23_PAD_GPMI_D05__GPMI_D05                     0x0050
-MX23_PAD_GPMI_D06__GPMI_D06                     0x0060
-MX23_PAD_GPMI_D07__GPMI_D07                     0x0070
-MX23_PAD_GPMI_D08__GPMI_D08                     0x0080
-MX23_PAD_GPMI_D09__GPMI_D09                     0x0090
-MX23_PAD_GPMI_D10__GPMI_D10                     0x00a0
-MX23_PAD_GPMI_D11__GPMI_D11                     0x00b0
-MX23_PAD_GPMI_D12__GPMI_D12                     0x00c0
-MX23_PAD_GPMI_D13__GPMI_D13                     0x00d0
-MX23_PAD_GPMI_D14__GPMI_D14                     0x00e0
-MX23_PAD_GPMI_D15__GPMI_D15                     0x00f0
-MX23_PAD_GPMI_CLE__GPMI_CLE                     0x0100
-MX23_PAD_GPMI_ALE__GPMI_ALE                     0x0110
-MX23_PAD_GPMI_CE2N__GPMI_CE2N                   0x0120
-MX23_PAD_GPMI_RDY0__GPMI_RDY0                   0x0130
-MX23_PAD_GPMI_RDY1__GPMI_RDY1                   0x0140
-MX23_PAD_GPMI_RDY2__GPMI_RDY2                   0x0150
-MX23_PAD_GPMI_RDY3__GPMI_RDY3                   0x0160
-MX23_PAD_GPMI_WPN__GPMI_WPN                     0x0170
-MX23_PAD_GPMI_WRN__GPMI_WRN                     0x0180
-MX23_PAD_GPMI_RDN__GPMI_RDN                     0x0190
-MX23_PAD_AUART1_CTS__AUART1_CTS                 0x01a0
-MX23_PAD_AUART1_RTS__AUART1_RTS                 0x01b0
-MX23_PAD_AUART1_RX__AUART1_RX                   0x01c0
-MX23_PAD_AUART1_TX__AUART1_TX                   0x01d0
-MX23_PAD_I2C_SCL__I2C_SCL                       0x01e0
-MX23_PAD_I2C_SDA__I2C_SDA                       0x01f0
-MX23_PAD_LCD_D00__LCD_D00                       0x1000
-MX23_PAD_LCD_D01__LCD_D01                       0x1010
-MX23_PAD_LCD_D02__LCD_D02                       0x1020
-MX23_PAD_LCD_D03__LCD_D03                       0x1030
-MX23_PAD_LCD_D04__LCD_D04                       0x1040
-MX23_PAD_LCD_D05__LCD_D05                       0x1050
-MX23_PAD_LCD_D06__LCD_D06                       0x1060
-MX23_PAD_LCD_D07__LCD_D07                       0x1070
-MX23_PAD_LCD_D08__LCD_D08                       0x1080
-MX23_PAD_LCD_D09__LCD_D09                       0x1090
-MX23_PAD_LCD_D10__LCD_D10                       0x10a0
-MX23_PAD_LCD_D11__LCD_D11                       0x10b0
-MX23_PAD_LCD_D12__LCD_D12                       0x10c0
-MX23_PAD_LCD_D13__LCD_D13                       0x10d0
-MX23_PAD_LCD_D14__LCD_D14                       0x10e0
-MX23_PAD_LCD_D15__LCD_D15                       0x10f0
-MX23_PAD_LCD_D16__LCD_D16                       0x1100
-MX23_PAD_LCD_D17__LCD_D17                       0x1110
-MX23_PAD_LCD_RESET__LCD_RESET                   0x1120
-MX23_PAD_LCD_RS__LCD_RS                         0x1130
-MX23_PAD_LCD_WR__LCD_WR                         0x1140
-MX23_PAD_LCD_CS__LCD_CS                         0x1150
-MX23_PAD_LCD_DOTCK__LCD_DOTCK                   0x1160
-MX23_PAD_LCD_ENABLE__LCD_ENABLE                 0x1170
-MX23_PAD_LCD_HSYNC__LCD_HSYNC                   0x1180
-MX23_PAD_LCD_VSYNC__LCD_VSYNC                   0x1190
-MX23_PAD_PWM0__PWM0                             0x11a0
-MX23_PAD_PWM1__PWM1                             0x11b0
-MX23_PAD_PWM2__PWM2                             0x11c0
-MX23_PAD_PWM3__PWM3                             0x11d0
-MX23_PAD_PWM4__PWM4                             0x11e0
-MX23_PAD_SSP1_CMD__SSP1_CMD                     0x2000
-MX23_PAD_SSP1_DETECT__SSP1_DETECT               0x2010
-MX23_PAD_SSP1_DATA0__SSP1_DATA0                 0x2020
-MX23_PAD_SSP1_DATA1__SSP1_DATA1                 0x2030
-MX23_PAD_SSP1_DATA2__SSP1_DATA2                 0x2040
-MX23_PAD_SSP1_DATA3__SSP1_DATA3                 0x2050
-MX23_PAD_SSP1_SCK__SSP1_SCK                     0x2060
-MX23_PAD_ROTARYA__ROTARYA                       0x2070
-MX23_PAD_ROTARYB__ROTARYB                       0x2080
-MX23_PAD_EMI_A00__EMI_A00                       0x2090
-MX23_PAD_EMI_A01__EMI_A01                       0x20a0
-MX23_PAD_EMI_A02__EMI_A02                       0x20b0
-MX23_PAD_EMI_A03__EMI_A03                       0x20c0
-MX23_PAD_EMI_A04__EMI_A04                       0x20d0
-MX23_PAD_EMI_A05__EMI_A05                       0x20e0
-MX23_PAD_EMI_A06__EMI_A06                       0x20f0
-MX23_PAD_EMI_A07__EMI_A07                       0x2100
-MX23_PAD_EMI_A08__EMI_A08                       0x2110
-MX23_PAD_EMI_A09__EMI_A09                       0x2120
-MX23_PAD_EMI_A10__EMI_A10                       0x2130
-MX23_PAD_EMI_A11__EMI_A11                       0x2140
-MX23_PAD_EMI_A12__EMI_A12                       0x2150
-MX23_PAD_EMI_BA0__EMI_BA0                       0x2160
-MX23_PAD_EMI_BA1__EMI_BA1                       0x2170
-MX23_PAD_EMI_CASN__EMI_CASN                     0x2180
-MX23_PAD_EMI_CE0N__EMI_CE0N                     0x2190
-MX23_PAD_EMI_CE1N__EMI_CE1N                     0x21a0
-MX23_PAD_GPMI_CE1N__GPMI_CE1N                   0x21b0
-MX23_PAD_GPMI_CE0N__GPMI_CE0N                   0x21c0
-MX23_PAD_EMI_CKE__EMI_CKE                       0x21d0
-MX23_PAD_EMI_RASN__EMI_RASN                     0x21e0
-MX23_PAD_EMI_WEN__EMI_WEN                       0x21f0
-MX23_PAD_EMI_D00__EMI_D00                       0x3000
-MX23_PAD_EMI_D01__EMI_D01                       0x3010
-MX23_PAD_EMI_D02__EMI_D02                       0x3020
-MX23_PAD_EMI_D03__EMI_D03                       0x3030
-MX23_PAD_EMI_D04__EMI_D04                       0x3040
-MX23_PAD_EMI_D05__EMI_D05                       0x3050
-MX23_PAD_EMI_D06__EMI_D06                       0x3060
-MX23_PAD_EMI_D07__EMI_D07                       0x3070
-MX23_PAD_EMI_D08__EMI_D08                       0x3080
-MX23_PAD_EMI_D09__EMI_D09                       0x3090
-MX23_PAD_EMI_D10__EMI_D10                       0x30a0
-MX23_PAD_EMI_D11__EMI_D11                       0x30b0
-MX23_PAD_EMI_D12__EMI_D12                       0x30c0
-MX23_PAD_EMI_D13__EMI_D13                       0x30d0
-MX23_PAD_EMI_D14__EMI_D14                       0x30e0
-MX23_PAD_EMI_D15__EMI_D15                       0x30f0
-MX23_PAD_EMI_DQM0__EMI_DQM0                     0x3100
-MX23_PAD_EMI_DQM1__EMI_DQM1                     0x3110
-MX23_PAD_EMI_DQS0__EMI_DQS0                     0x3120
-MX23_PAD_EMI_DQS1__EMI_DQS1                     0x3130
-MX23_PAD_EMI_CLK__EMI_CLK                       0x3140
-MX23_PAD_EMI_CLKN__EMI_CLKN                     0x3150
-MX23_PAD_GPMI_D00__LCD_D8                       0x0001
-MX23_PAD_GPMI_D01__LCD_D9                       0x0011
-MX23_PAD_GPMI_D02__LCD_D10                      0x0021
-MX23_PAD_GPMI_D03__LCD_D11                      0x0031
-MX23_PAD_GPMI_D04__LCD_D12                      0x0041
-MX23_PAD_GPMI_D05__LCD_D13                      0x0051
-MX23_PAD_GPMI_D06__LCD_D14                      0x0061
-MX23_PAD_GPMI_D07__LCD_D15                      0x0071
-MX23_PAD_GPMI_D08__LCD_D18                      0x0081
-MX23_PAD_GPMI_D09__LCD_D19                      0x0091
-MX23_PAD_GPMI_D10__LCD_D20                      0x00a1
-MX23_PAD_GPMI_D11__LCD_D21                      0x00b1
-MX23_PAD_GPMI_D12__LCD_D22                      0x00c1
-MX23_PAD_GPMI_D13__LCD_D23                      0x00d1
-MX23_PAD_GPMI_D14__AUART2_RX                    0x00e1
-MX23_PAD_GPMI_D15__AUART2_TX                    0x00f1
-MX23_PAD_GPMI_CLE__LCD_D16                      0x0101
-MX23_PAD_GPMI_ALE__LCD_D17                      0x0111
-MX23_PAD_GPMI_CE2N__ATA_A2                      0x0121
-MX23_PAD_AUART1_RTS__IR_CLK                     0x01b1
-MX23_PAD_AUART1_RX__IR_RX                       0x01c1
-MX23_PAD_AUART1_TX__IR_TX                       0x01d1
-MX23_PAD_I2C_SCL__GPMI_RDY2                     0x01e1
-MX23_PAD_I2C_SDA__GPMI_CE2N                     0x01f1
-MX23_PAD_LCD_D00__ETM_DA8                       0x1001
-MX23_PAD_LCD_D01__ETM_DA9                       0x1011
-MX23_PAD_LCD_D02__ETM_DA10                      0x1021
-MX23_PAD_LCD_D03__ETM_DA11                      0x1031
-MX23_PAD_LCD_D04__ETM_DA12                      0x1041
-MX23_PAD_LCD_D05__ETM_DA13                      0x1051
-MX23_PAD_LCD_D06__ETM_DA14                      0x1061
-MX23_PAD_LCD_D07__ETM_DA15                      0x1071
-MX23_PAD_LCD_D08__ETM_DA0                       0x1081
-MX23_PAD_LCD_D09__ETM_DA1                       0x1091
-MX23_PAD_LCD_D10__ETM_DA2                       0x10a1
-MX23_PAD_LCD_D11__ETM_DA3                       0x10b1
-MX23_PAD_LCD_D12__ETM_DA4                       0x10c1
-MX23_PAD_LCD_D13__ETM_DA5                       0x10d1
-MX23_PAD_LCD_D14__ETM_DA6                       0x10e1
-MX23_PAD_LCD_D15__ETM_DA7                       0x10f1
-MX23_PAD_LCD_RESET__ETM_TCTL                    0x1121
-MX23_PAD_LCD_RS__ETM_TCLK                       0x1131
-MX23_PAD_LCD_DOTCK__GPMI_RDY3                   0x1161
-MX23_PAD_LCD_ENABLE__I2C_SCL                    0x1171
-MX23_PAD_LCD_HSYNC__I2C_SDA                     0x1181
-MX23_PAD_LCD_VSYNC__LCD_BUSY                    0x1191
-MX23_PAD_PWM0__ROTARYA                          0x11a1
-MX23_PAD_PWM1__ROTARYB                          0x11b1
-MX23_PAD_PWM2__GPMI_RDY3                        0x11c1
-MX23_PAD_PWM3__ETM_TCTL                         0x11d1
-MX23_PAD_PWM4__ETM_TCLK                         0x11e1
-MX23_PAD_SSP1_DETECT__GPMI_CE3N                 0x2011
-MX23_PAD_SSP1_DATA1__I2C_SCL                    0x2031
-MX23_PAD_SSP1_DATA2__I2C_SDA                    0x2041
-MX23_PAD_ROTARYA__AUART2_RTS                    0x2071
-MX23_PAD_ROTARYB__AUART2_CTS                    0x2081
-MX23_PAD_GPMI_D00__SSP2_DATA0                   0x0002
-MX23_PAD_GPMI_D01__SSP2_DATA1                   0x0012
-MX23_PAD_GPMI_D02__SSP2_DATA2                   0x0022
-MX23_PAD_GPMI_D03__SSP2_DATA3                   0x0032
-MX23_PAD_GPMI_D04__SSP2_DATA4                   0x0042
-MX23_PAD_GPMI_D05__SSP2_DATA5                   0x0052
-MX23_PAD_GPMI_D06__SSP2_DATA6                   0x0062
-MX23_PAD_GPMI_D07__SSP2_DATA7                   0x0072
-MX23_PAD_GPMI_D08__SSP1_DATA4                   0x0082
-MX23_PAD_GPMI_D09__SSP1_DATA5                   0x0092
-MX23_PAD_GPMI_D10__SSP1_DATA6                   0x00a2
-MX23_PAD_GPMI_D11__SSP1_DATA7                   0x00b2
-MX23_PAD_GPMI_D15__GPMI_CE3N                    0x00f2
-MX23_PAD_GPMI_RDY0__SSP2_DETECT                 0x0132
-MX23_PAD_GPMI_RDY1__SSP2_CMD                    0x0142
-MX23_PAD_GPMI_WRN__SSP2_SCK                     0x0182
-MX23_PAD_AUART1_CTS__SSP1_DATA4                 0x01a2
-MX23_PAD_AUART1_RTS__SSP1_DATA5                 0x01b2
-MX23_PAD_AUART1_RX__SSP1_DATA6                  0x01c2
-MX23_PAD_AUART1_TX__SSP1_DATA7                  0x01d2
-MX23_PAD_I2C_SCL__AUART1_TX                     0x01e2
-MX23_PAD_I2C_SDA__AUART1_RX                     0x01f2
-MX23_PAD_LCD_D08__SAIF2_SDATA0                  0x1082
-MX23_PAD_LCD_D09__SAIF1_SDATA0                  0x1092
-MX23_PAD_LCD_D10__SAIF_MCLK_BITCLK              0x10a2
-MX23_PAD_LCD_D11__SAIF_LRCLK                    0x10b2
-MX23_PAD_LCD_D12__SAIF2_SDATA1                  0x10c2
-MX23_PAD_LCD_D13__SAIF2_SDATA2                  0x10d2
-MX23_PAD_LCD_D14__SAIF1_SDATA2                  0x10e2
-MX23_PAD_LCD_D15__SAIF1_SDATA1                  0x10f2
-MX23_PAD_LCD_D16__SAIF_ALT_BITCLK               0x1102
-MX23_PAD_LCD_RESET__GPMI_CE3N                   0x1122
-MX23_PAD_PWM0__DUART_RX                         0x11a2
-MX23_PAD_PWM1__DUART_TX                         0x11b2
-MX23_PAD_PWM3__AUART1_CTS                       0x11d2
-MX23_PAD_PWM4__AUART1_RTS                       0x11e2
-MX23_PAD_SSP1_CMD__JTAG_TDO                     0x2002
-MX23_PAD_SSP1_DETECT__USB_OTG_ID                0x2012
-MX23_PAD_SSP1_DATA0__JTAG_TDI                   0x2022
-MX23_PAD_SSP1_DATA1__JTAG_TCLK                  0x2032
-MX23_PAD_SSP1_DATA2__JTAG_RTCK                  0x2042
-MX23_PAD_SSP1_DATA3__JTAG_TMS                   0x2052
-MX23_PAD_SSP1_SCK__JTAG_TRST                    0x2062
-MX23_PAD_ROTARYA__SPDIF                         0x2072
-MX23_PAD_ROTARYB__GPMI_CE3N                     0x2082
-MX23_PAD_GPMI_D00__GPIO_0_0                     0x0003
-MX23_PAD_GPMI_D01__GPIO_0_1                     0x0013
-MX23_PAD_GPMI_D02__GPIO_0_2                     0x0023
-MX23_PAD_GPMI_D03__GPIO_0_3                     0x0033
-MX23_PAD_GPMI_D04__GPIO_0_4                     0x0043
-MX23_PAD_GPMI_D05__GPIO_0_5                     0x0053
-MX23_PAD_GPMI_D06__GPIO_0_6                     0x0063
-MX23_PAD_GPMI_D07__GPIO_0_7                     0x0073
-MX23_PAD_GPMI_D08__GPIO_0_8                     0x0083
-MX23_PAD_GPMI_D09__GPIO_0_9                     0x0093
-MX23_PAD_GPMI_D10__GPIO_0_10                    0x00a3
-MX23_PAD_GPMI_D11__GPIO_0_11                    0x00b3
-MX23_PAD_GPMI_D12__GPIO_0_12                    0x00c3
-MX23_PAD_GPMI_D13__GPIO_0_13                    0x00d3
-MX23_PAD_GPMI_D14__GPIO_0_14                    0x00e3
-MX23_PAD_GPMI_D15__GPIO_0_15                    0x00f3
-MX23_PAD_GPMI_CLE__GPIO_0_16                    0x0103
-MX23_PAD_GPMI_ALE__GPIO_0_17                    0x0113
-MX23_PAD_GPMI_CE2N__GPIO_0_18                   0x0123
-MX23_PAD_GPMI_RDY0__GPIO_0_19                   0x0133
-MX23_PAD_GPMI_RDY1__GPIO_0_20                   0x0143
-MX23_PAD_GPMI_RDY2__GPIO_0_21                   0x0153
-MX23_PAD_GPMI_RDY3__GPIO_0_22                   0x0163
-MX23_PAD_GPMI_WPN__GPIO_0_23                    0x0173
-MX23_PAD_GPMI_WRN__GPIO_0_24                    0x0183
-MX23_PAD_GPMI_RDN__GPIO_0_25                    0x0193
-MX23_PAD_AUART1_CTS__GPIO_0_26                  0x01a3
-MX23_PAD_AUART1_RTS__GPIO_0_27                  0x01b3
-MX23_PAD_AUART1_RX__GPIO_0_28                   0x01c3
-MX23_PAD_AUART1_TX__GPIO_0_29                   0x01d3
-MX23_PAD_I2C_SCL__GPIO_0_30                     0x01e3
-MX23_PAD_I2C_SDA__GPIO_0_31                     0x01f3
-MX23_PAD_LCD_D00__GPIO_1_0                      0x1003
-MX23_PAD_LCD_D01__GPIO_1_1                      0x1013
-MX23_PAD_LCD_D02__GPIO_1_2                      0x1023
-MX23_PAD_LCD_D03__GPIO_1_3                      0x1033
-MX23_PAD_LCD_D04__GPIO_1_4                      0x1043
-MX23_PAD_LCD_D05__GPIO_1_5                      0x1053
-MX23_PAD_LCD_D06__GPIO_1_6                      0x1063
-MX23_PAD_LCD_D07__GPIO_1_7                      0x1073
-MX23_PAD_LCD_D08__GPIO_1_8                      0x1083
-MX23_PAD_LCD_D09__GPIO_1_9                      0x1093
-MX23_PAD_LCD_D10__GPIO_1_10                     0x10a3
-MX23_PAD_LCD_D11__GPIO_1_11                     0x10b3
-MX23_PAD_LCD_D12__GPIO_1_12                     0x10c3
-MX23_PAD_LCD_D13__GPIO_1_13                     0x10d3
-MX23_PAD_LCD_D14__GPIO_1_14                     0x10e3
-MX23_PAD_LCD_D15__GPIO_1_15                     0x10f3
-MX23_PAD_LCD_D16__GPIO_1_16                     0x1103
-MX23_PAD_LCD_D17__GPIO_1_17                     0x1113
-MX23_PAD_LCD_RESET__GPIO_1_18                   0x1123
-MX23_PAD_LCD_RS__GPIO_1_19                      0x1133
-MX23_PAD_LCD_WR__GPIO_1_20                      0x1143
-MX23_PAD_LCD_CS__GPIO_1_21                      0x1153
-MX23_PAD_LCD_DOTCK__GPIO_1_22                   0x1163
-MX23_PAD_LCD_ENABLE__GPIO_1_23                  0x1173
-MX23_PAD_LCD_HSYNC__GPIO_1_24                   0x1183
-MX23_PAD_LCD_VSYNC__GPIO_1_25                   0x1193
-MX23_PAD_PWM0__GPIO_1_26                        0x11a3
-MX23_PAD_PWM1__GPIO_1_27                        0x11b3
-MX23_PAD_PWM2__GPIO_1_28                        0x11c3
-MX23_PAD_PWM3__GPIO_1_29                        0x11d3
-MX23_PAD_PWM4__GPIO_1_30                        0x11e3
-MX23_PAD_SSP1_CMD__GPIO_2_0                     0x2003
-MX23_PAD_SSP1_DETECT__GPIO_2_1                  0x2013
-MX23_PAD_SSP1_DATA0__GPIO_2_2                   0x2023
-MX23_PAD_SSP1_DATA1__GPIO_2_3                   0x2033
-MX23_PAD_SSP1_DATA2__GPIO_2_4                   0x2043
-MX23_PAD_SSP1_DATA3__GPIO_2_5                   0x2053
-MX23_PAD_SSP1_SCK__GPIO_2_6                     0x2063
-MX23_PAD_ROTARYA__GPIO_2_7                      0x2073
-MX23_PAD_ROTARYB__GPIO_2_8                      0x2083
-MX23_PAD_EMI_A00__GPIO_2_9                      0x2093
-MX23_PAD_EMI_A01__GPIO_2_10                     0x20a3
-MX23_PAD_EMI_A02__GPIO_2_11                     0x20b3
-MX23_PAD_EMI_A03__GPIO_2_12                     0x20c3
-MX23_PAD_EMI_A04__GPIO_2_13                     0x20d3
-MX23_PAD_EMI_A05__GPIO_2_14                     0x20e3
-MX23_PAD_EMI_A06__GPIO_2_15                     0x20f3
-MX23_PAD_EMI_A07__GPIO_2_16                     0x2103
-MX23_PAD_EMI_A08__GPIO_2_17                     0x2113
-MX23_PAD_EMI_A09__GPIO_2_18                     0x2123
-MX23_PAD_EMI_A10__GPIO_2_19                     0x2133
-MX23_PAD_EMI_A11__GPIO_2_20                     0x2143
-MX23_PAD_EMI_A12__GPIO_2_21                     0x2153
-MX23_PAD_EMI_BA0__GPIO_2_22                     0x2163
-MX23_PAD_EMI_BA1__GPIO_2_23                     0x2173
-MX23_PAD_EMI_CASN__GPIO_2_24                    0x2183
-MX23_PAD_EMI_CE0N__GPIO_2_25                    0x2193
-MX23_PAD_EMI_CE1N__GPIO_2_26                    0x21a3
-MX23_PAD_GPMI_CE1N__GPIO_2_27                   0x21b3
-MX23_PAD_GPMI_CE0N__GPIO_2_28                   0x21c3
-MX23_PAD_EMI_CKE__GPIO_2_29                     0x21d3
-MX23_PAD_EMI_RASN__GPIO_2_30                    0x21e3
-MX23_PAD_EMI_WEN__GPIO_2_31                     0x21f3
+Valid values for i.MX28/i.MX23 pinmux-id are defined in
+arch/arm/boot/dts/imx28-pinfunc.h and arch/arm/boot/dts/imx23-pinfunc.h.
+The definitions for the padconfig properties can be found in
+arch/arm/boot/dts/mxs-pinfunc.h.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
index 734d9b04d533..caf297bee1fb 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-palmas.txt
@@ -41,7 +41,7 @@ pinctrl-bindings.txt:
 
 Required: pins
 Options: function, bias-disable, bias-pull-up, bias-pull-down,
-         bias-pin-default, drive-open-drain.
+         drive-open-drain.
 
 Note that many of these properties are only valid for certain specific pins.
 See the Palmas device datasheet for complete details regarding which pins
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index 5a02e30dd262..7069a0b84e3a 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -72,6 +72,13 @@ Optional properties:
                 /* pin base, nr pins & gpio function */
                 pinctrl-single,gpio-range = <&range 0 3 0 &range 3 9 1>;
 
+- interrupt-controller : standard interrupt controller binding if using
+  interrupts for wake-up events for example. In this case pinctrl-single
+  is set up as a chained interrupt controller and the wake-up interrupts
+  can be requested by the drivers using request_irq().
+
+- #interrupt-cells : standard interrupt binding if using interrupts
+
 This driver assumes that there is only one register for each pin (unless the
 pinctrl-single,bit-per-mux is set), and uses the common pinctrl bindings as
 specified in the pinctrl-bindings.txt document in this directory.
@@ -121,6 +128,8 @@ pmx_core: pinmux@4a100040 {
         reg = <0x4a100040 0x0196>;
         #address-cells = <1>;
         #size-cells = <0>;
+        #interrupt-cells = <1>;
+        interrupt-controller;
         pinctrl-single,register-width = <16>;
         pinctrl-single,function-mask = <0xffff>;
 };
@@ -131,6 +140,8 @@ pmx_wkup: pinmux@4a31e040 {
         reg = <0x4a31e040 0x0038>;
         #address-cells = <1>;
         #size-cells = <0>;
+        #interrupt-cells = <1>;
+        interrupt-controller;
         pinctrl-single,register-width = <16>;
         pinctrl-single,function-mask = <0xffff>;
 };
diff --git a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
index b0fb1018d7ad..f378d342aae4 100644
--- a/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/rockchip,pinctrl.txt
@@ -21,10 +21,13 @@ 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"
+  - reg: first element is the general register space of the iomux controller
+         second element is the separate pull register space of the rk3188
 
 Required properties for gpio sub nodes:
-  - compatible: "rockchip,gpio-bank"
+  - compatible: "rockchip,gpio-bank", "rockchip,rk3188-gpio-bank0"
   - reg: register of the gpio bank (different than the iomux registerset)
+         second element: separate pull register for rk3188 bank0
   - interrupts: base interrupt of the gpio bank in the interrupt controller
   - clocks: clock that drives this bank
   - gpio-controller: identifies the node as a gpio controller and pin bank.
@@ -95,3 +98,44 @@ uart2: serial@20064000 {
         pinctrl-names = "default";
         pinctrl-0 = <&uart2_xfer>;
 };
+
+Example for rk3188:
+
+        pinctrl@20008000 {
+                compatible = "rockchip,rk3188-pinctrl";
+                reg = <0x20008000 0xa0>,
+                      <0x20008164 0x1a0>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+
+                gpio0: gpio0@0x2000a000 {
+                        compatible = "rockchip,rk3188-gpio-bank0";
+                        reg = <0x2000a000 0x100>,
+                              <0x20004064 0x8>;
+                        interrupts = <GIC_SPI 54 IRQ_TYPE_LEVEL_HIGH>;
+                        clocks = <&clk_gates8 9>;
+
+                        gpio-controller;
+                        #gpio-cells = <2>;
+
+                        interrupt-controller;
+                        #interrupt-cells = <2>;
+                };
+
+                gpio1: gpio1@0x2003c000 {
+                        compatible = "rockchip,gpio-bank";
+                        reg = <0x2003c000 0x100>;
+                        interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>;
+                        clocks = <&clk_gates8 10>;
+
+                        gpio-controller;
+                        #gpio-cells = <2>;
+
+                        interrupt-controller;
+                        #interrupt-cells = <2>;
+                };
+
+                ...
+
+        };
diff --git a/Documentation/devicetree/bindings/power/twl-charger.txt b/Documentation/devicetree/bindings/power/twl-charger.txt
new file mode 100644
index 000000000000..d5c706216df5
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/twl-charger.txt
@@ -0,0 +1,20 @@
+TWL BCI (Battery Charger Interface)
+
+Required properties:
+- compatible:
+  - "ti,twl4030-bci"
+- interrupts: two interrupt lines from the TWL SIH (secondary
+  interrupt handler) - interrupts 9 and 2.
+
+Optional properties:
+- ti,bb-uvolt: microvolts for charging the backup battery.
+- ti,bb-uamp: microamps for charging the backup battery.
+
+Examples:
+
+bci {
+   compatible = "ti,twl4030-bci";
+   interrupts = <9>, <2>;
+   ti,bb-uvolt = <3200000>;
+   ti,bb-uamp = <150>;
+};
diff --git a/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt b/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt
new file mode 100644
index 000000000000..4f6a550184d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ti,bq24735.txt
@@ -0,0 +1,32 @@
+TI BQ24735 Charge Controller
+~~~~~~~~~~
+
+Required properties :
+ - compatible : "ti,bq24735"
+
+Optional properties :
+ - interrupts : Specify the interrupt to be used to trigger when the AC
+   adapter is either plugged in or removed.
+ - ti,ac-detect-gpios : This GPIO is optionally used to read the AC adapter
+   presence. This is a Host GPIO that is configured as an input and
+   connected to the bq24735.
+ - ti,charge-current : Used to control and set the charging current. This value
+   must be between 128mA and 8.128A with a 64mA step resolution. The POR value
+   is 0x0000h. This number is in mA (e.g. 8192), see spec for more information
+   about the ChargeCurrent (0x14h) register.
+ - ti,charge-voltage : Used to control and set the charging voltage. This value
+   must be between 1.024V and 19.2V with a 16mV step resolution. The POR value
+   is 0x0000h. This number is in mV (e.g. 19200), see spec for more information
+   about the ChargeVoltage (0x15h) register.
+ - ti,input-current : Used to control and set the charger input current. This
+   value must be between 128mA and 8.064A with a 128mA step resolution. The
+   POR value is 0x1000h. This number is in mA (e.g. 8064), see the spec for
+   more information about the InputCurrent (0x3fh) register.
+
+Example:
+
+        bq24735@9 {
+                compatible = "ti,bq24735";
+                reg = <0x9>;
+                ti,ac-detect-gpios = <&gpio 72 0x1>;
+        }
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
index 2a4b4bce6110..7fc1b010fa75 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dma.txt
@@ -1,33 +1,30 @@
-* Freescale 83xx DMA Controller
+* Freescale DMA Controllers
 
-Freescale PowerPC 83xx have on chip general purpose DMA controllers.
+** Freescale Elo DMA Controller
+   This is a little-endian 4-channel DMA controller, used in Freescale mpc83xx
+   series chips such as mpc8315, mpc8349, mpc8379 etc.
 
 Required properties:
 
-- compatible        : compatible list, contains 2 entries, first is
-                 "fsl,CHIP-dma", where CHIP is the processor
-                 (mpc8349, mpc8360, etc.) and the second is
-                 "fsl,elo-dma"
-- reg               : <registers mapping for DMA general status reg>
-- ranges                : Should be defined as specified in 1) to describe the
-                  DMA controller channels.
+- compatible        : must include "fsl,elo-dma"
+- reg               : DMA General Status Register, i.e. DGSR which contains
+                      status for all the 4 DMA channels
+- ranges            : describes the mapping between the address space of the
+                      DMA channels and the address space of the DMA controller
 - cell-index        : controller index.  0 for controller @ 0x8100
-- interrupts        : <interrupt mapping for DMA IRQ>
+- interrupts        : interrupt specifier for DMA IRQ
 - interrupt-parent  : optional, if needed for interrupt mapping
 
-
 - DMA channel nodes:
-        - compatible        : compatible list, contains 2 entries, first is
-                         "fsl,CHIP-dma-channel", where CHIP is the processor
-                         (mpc8349, mpc8350, etc.) and the second is
-                         "fsl,elo-dma-channel". However, see note below.
-        - reg               : <registers mapping for channel>
-        - cell-index        : dma channel index starts at 0.
+        - compatible        : must include "fsl,elo-dma-channel"
+                              However, see note below.
+        - reg               : DMA channel specific registers
+        - cell-index        : DMA channel index starts at 0.
 
 Optional properties:
-        - interrupts        : <interrupt mapping for DMA channel IRQ>
-                          (on 83xx this is expected to be identical to
-                           the interrupts property of the parent node)
+        - interrupts        : interrupt specifier for DMA channel IRQ
+                              (on 83xx this is expected to be identical to
+                              the interrupts property of the parent node)
         - interrupt-parent  : optional, if needed for interrupt mapping
 
 Example:
@@ -70,30 +67,27 @@ Example:
                 };
         };
 
-* Freescale 85xx/86xx DMA Controller
-
-Freescale PowerPC 85xx/86xx have on chip general purpose DMA controllers.
+** Freescale EloPlus DMA Controller
+   This is a 4-channel DMA controller with extended addresses and chaining,
+   mainly used in Freescale mpc85xx/86xx, Pxxx and BSC series chips, such as
+   mpc8540, mpc8641 p4080, bsc9131 etc.
 
 Required properties:
 
-- compatible        : compatible list, contains 2 entries, first is
-                 "fsl,CHIP-dma", where CHIP is the processor
-                 (mpc8540, mpc8540, etc.) and the second is
-                 "fsl,eloplus-dma"
-- reg               : <registers mapping for DMA general status reg>
+- compatible        : must include "fsl,eloplus-dma"
+- reg               : DMA General Status Register, i.e. DGSR which contains
+                      status for all the 4 DMA channels
 - cell-index        : controller index.  0 for controller @ 0x21000,
                                          1 for controller @ 0xc000
-- ranges                : Should be defined as specified in 1) to describe the
-                  DMA controller channels.
+- ranges            : describes the mapping between the address space of the
+                      DMA channels and the address space of the DMA controller
 
 - DMA channel nodes:
-        - compatible        : compatible list, contains 2 entries, first is
-                         "fsl,CHIP-dma-channel", where CHIP is the processor
-                         (mpc8540, mpc8560, etc.) and the second is
-                         "fsl,eloplus-dma-channel". However, see note below.
-        - cell-index        : dma channel index starts at 0.
-        - reg               : <registers mapping for channel>
-        - interrupts        : <interrupt mapping for DMA channel IRQ>
+        - compatible        : must include "fsl,eloplus-dma-channel"
+                              However, see note below.
+        - cell-index        : DMA channel index starts at 0.
+        - reg               : DMA channel specific registers
+        - interrupts        : interrupt specifier for DMA channel IRQ
         - interrupt-parent  : optional, if needed for interrupt mapping
 
 Example:
@@ -134,6 +128,76 @@ Example:
                 };
         };
 
+** Freescale Elo3 DMA Controller
+   DMA controller which has same function as EloPlus except that Elo3 has 8
+   channels while EloPlus has only 4, it is used in Freescale Txxx and Bxxx
+   series chips, such as t1040, t4240, b4860.
+
+Required properties:
+
+- compatible        : must include "fsl,elo3-dma"
+- reg               : contains two entries for DMA General Status Registers,
+                      i.e. DGSR0 which includes status for channel 1~4, and
+                      DGSR1 for channel 5~8
+- ranges            : describes the mapping between the address space of the
+                      DMA channels and the address space of the DMA controller
+
+- DMA channel nodes:
+        - compatible        : must include "fsl,eloplus-dma-channel"
+        - reg               : DMA channel specific registers
+        - interrupts        : interrupt specifier for DMA channel IRQ
+        - interrupt-parent  : optional, if needed for interrupt mapping
+
+Example:
+dma@100300 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "fsl,elo3-dma";
+        reg = <0x100300 0x4>,
+              <0x100600 0x4>;
+        ranges = <0x0 0x100100 0x500>;
+        dma-channel@0 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x0 0x80>;
+                interrupts = <28 2 0 0>;
+        };
+        dma-channel@80 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x80 0x80>;
+                interrupts = <29 2 0 0>;
+        };
+        dma-channel@100 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x100 0x80>;
+                interrupts = <30 2 0 0>;
+        };
+        dma-channel@180 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x180 0x80>;
+                interrupts = <31 2 0 0>;
+        };
+        dma-channel@300 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x300 0x80>;
+                interrupts = <76 2 0 0>;
+        };
+        dma-channel@380 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x380 0x80>;
+                interrupts = <77 2 0 0>;
+        };
+        dma-channel@400 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x400 0x80>;
+                interrupts = <78 2 0 0>;
+        };
+        dma-channel@480 {
+                compatible = "fsl,eloplus-dma-channel";
+                reg = <0x480 0x80>;
+                interrupts = <79 2 0 0>;
+        };
+};
+
 Note on DMA channel compatible properties: The compatible property must say
 "fsl,elo-dma-channel" or "fsl,eloplus-dma-channel" to be used by the Elo DMA
 driver (fsldma).  Any DMA channel used by fsldma cannot be used by another
diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
index d61fccd40bad..5538de9c2007 100644
--- a/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.txt
@@ -15,7 +15,7 @@ Required properties:
     samsung,s5pc100-pwm - for 32-bit timers present on S5PC100, S5PV210,
                           Exynos4210 rev0 SoCs
     samsung,exynos4210-pwm - for 32-bit timers present on Exynos4210,
-                          Exynos4x12 and Exynos5250 SoCs
+                          Exynos4x12, Exynos5250 and Exynos5420 SoCs
 - reg: base address and size of register area
 - interrupts: list of timer interrupts (one interrupt per timer, starting at
   timer 0)
diff --git a/Documentation/devicetree/bindings/regulator/as3722-regulator.txt b/Documentation/devicetree/bindings/regulator/as3722-regulator.txt
new file mode 100644
index 000000000000..caad0c8a258d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/as3722-regulator.txt
@@ -0,0 +1,91 @@
+Regulator of AMS AS3722 PMIC.
+Name of the regulator subnode must be "regulators".
+
+Optional properties:
+--------------------
+The input supply of regulators are the optional properties on the
+regulator node. The AS3722 is having 7 DCDC step-down regulators as
+sd[0-6], 10 LDOs as ldo[0-7], ldo[9-11]. The input supply of these
+regulators are provided through following properties:
+vsup-sd2-supply: Input supply for SD2.
+vsup-sd3-supply: Input supply for SD3.
+vsup-sd4-supply: Input supply for SD4.
+vsup-sd5-supply: Input supply for SD5.
+vin-ldo0-supply: Input supply for LDO0.
+vin-ldo1-6-supply: Input supply for LDO1 and LDO6.
+vin-ldo2-5-7-supply: Input supply for LDO2, LDO5 and LDO7.
+vin-ldo3-4-supply: Input supply for LDO3 and LDO4.
+vin-ldo9-10-supply: Input supply for LDO9 and LDO10.
+vin-ldo11-supply: Input supply for LDO11.
+
+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.
+               sd[0-6], ldo[0-7], ldo[9-11].
+
+               Optional sub-node properties:
+               ----------------------------
+                ams,ext-control: External control of the rail. The option of
+                        this properties will tell which external input is
+                        controlling this rail. Valid values are 0, 1, 2 ad 3.
+                        0: There is no external control of this rail.
+                        1: Rail is controlled by ENABLE1 input pin.
+                        2: Rail is controlled by ENABLE2 input pin.
+                        3: Rail is controlled by ENABLE3 input pin.
+                ams,enable-tracking: Enable tracking with SD1, only supported
+                        by LDO3.
+
+Example:
+-------
+        ams3722: ams3722 {
+                compatible = "ams,as3722";
+                reg = <0x40>;
+                ...
+
+                regulators {
+                        vsup-sd2-supply = <...>;
+                        ...
+
+                        sd0 {
+                                regulator-name = "vdd_cpu";
+                                regulator-min-microvolt = <700000>;
+                                regulator-max-microvolt = <1400000>;
+                                regulator-always-on;
+                                ams,ext-control = <2>;
+                        };
+
+                        sd1 {
+                                regulator-name = "vdd_core";
+                                regulator-min-microvolt = <700000>;
+                                regulator-max-microvolt = <1400000>;
+                                regulator-always-on;
+                                ams,ext-control = <1>;
+                        };
+
+                        sd2 {
+                                regulator-name = "vddio_ddr";
+                                regulator-min-microvolt = <1350000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                        };
+
+                        sd4 {
+                                regulator-name = "avdd-hdmi-pex";
+                                regulator-min-microvolt = <1050000>;
+                                regulator-max-microvolt = <1050000>;
+                                regulator-always-on;
+                        };
+
+                        sd5 {
+                                regulator-name = "vdd-1v8";
+                                regulator-min-microvolt = <1800000>;
+                                regulator-max-microvolt = <1800000>;
+                                regulator-always-on;
+                        };
+                        ....
+                };
+        };
diff --git a/Documentation/devicetree/bindings/regulator/da9210.txt b/Documentation/devicetree/bindings/regulator/da9210.txt
new file mode 100644
index 000000000000..f120f229d67d
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/da9210.txt
@@ -0,0 +1,21 @@
+* Dialog Semiconductor DA9210 Voltage Regulator
+
+Required properties:
+
+- compatible:   must be "diasemi,da9210"
+- reg:          the i2c slave address of the regulator. It should be 0x68.
+
+Any standard regulator properties can be used to configure the single da9210
+DCDC.
+
+Example:
+
+        da9210@68 {
+                compatible = "diasemi,da9210";
+                reg = <0x68>;
+
+                regulator-min-microvolt = <900000>;
+                regulator-max-microvolt = <1000000>;
+                regulator-boot-on;
+                regulator-always-on;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
index 875639ae0606..42e6b6bc48ff 100644
--- a/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
+++ b/Documentation/devicetree/bindings/regulator/palmas-pmic.txt
@@ -26,11 +26,17 @@ Optional nodes:
 
                For ti,palmas-pmic - smps12, smps123, smps3 depending on OTP,
                smps45, smps457, smps7 depending on variant, smps6, smps[8-9],
-               smps10_out2, smps10_out1, do[1-9], ldoln, ldousb.
+               smps10_out2, smps10_out1, 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,roof-floor - This takes as optional argument on platform supporting
+               the rail from desired external control. If there is no argument then
+               it will be assume that it is controlled by NSLEEP pin.
+               The valid value for external pins are:
+                        ENABLE1 then 1,
+                        ENABLE2 then 2 or
+                        NSLEEP then 3.
                ti,mode-sleep - mode to adopt in pmic sleep 0 - off, 1 - auto,
                2 - eco, 3 - forced pwm
                ti,smps-range - OTP has the wrong range set for the hardware so override
@@ -61,7 +67,7 @@ pmic {
                         regulator-always-on;
                         regulator-boot-on;
                         ti,warm-reset;
-                        ti,roof-floor;
+                        ti,roof-floor = <1>; /* ENABLE1 control */
                         ti,mode-sleep = <0>;
                         ti,smps-range = <1>;
                 };
diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 2bd8f0978765..e2c7f1e7251a 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -14,6 +14,11 @@ Optional properties:
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardwares which support disabling ramp rate, it should be explicitly
   intialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
+- regulator-enable-ramp-delay: The time taken, in microseconds, for the supply
+  rail to reach the target voltage, plus/minus whatever tolerance the board
+  design requires. This property describes the total system ramp time
+  required due to the combination of internal ramping of the regulator itself,
+  and board design issues such as trace capacitance and load on the supply.
 
 Deprecated properties:
 - regulator-compatible: If a regulator chip contains multiple
diff --git a/Documentation/devicetree/bindings/sound/cs42l73.txt b/Documentation/devicetree/bindings/sound/cs42l73.txt
new file mode 100644
index 000000000000..80ae910dbf6c
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs42l73.txt
@@ -0,0 +1,22 @@
+CS42L73 audio CODEC
+
+Required properties:
+
+  - compatible : "cirrus,cs42l73"
+
+  - reg : the I2C address of the device for I2C
+
+Optional properties:
+
+  - reset_gpio : a GPIO spec for the reset pin.
+  - chgfreq    : Charge Pump Frequency values 0x00-0x0F
+
+
+Example:
+
+codec: cs42l73@4a {
+        compatible = "cirrus,cs42l73";
+        reg = <0x4a>;
+        reset_gpio = <&gpio 10 0>;
+        chgfreq = <0x05>;
+};
\ No newline at end of file
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
new file mode 100644
index 000000000000..865178d5cdf3
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -0,0 +1,42 @@
+* Texas Instruments SoC audio setups with TLV320AIC3X Codec
+
+Required properties:
+- compatible : "ti,da830-evm-audio" : forDM365/DA8xx/OMAPL1x/AM33xx
+- ti,model : The user-visible name of this sound complex.
+- ti,audio-codec : The phandle of the TLV320AIC3x audio codec
+- ti,mcasp-controller : The phandle of the McASP controller
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
+- ti,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 codec's pins, and the jacks on the board:
+
+  Board connectors:
+
+  * Headphone Jack
+  * Line Out
+  * Mic Jack
+  * Line In
+
+
+Example:
+
+sound {
+        compatible = "ti,da830-evm-audio";
+        ti,model = "DA830 EVM";
+        ti,audio-codec = <&tlv320aic3x>;
+        ti,mcasp-controller = <&mcasp1>;
+        ti,codec-clock-rate = <12000000>;
+        ti,audio-routing =
+                "Headphone Jack",       "HPLOUT",
+                "Headphone Jack",       "HPROUT",
+                "Line Out",             "LLOUT",
+                "Line Out",             "RLOUT",
+                "MIC3L",                "Mic Bias 2V",
+                "MIC3R",                "Mic Bias 2V",
+                "Mic Bias 2V",          "Mic Jack",
+                "LINE1L",               "Line In",
+                "LINE2L",               "Line In",
+                "LINE1R",               "Line In",
+                "LINE2R",               "Line In";
+};
diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
index 374e145c2ef1..ed785b3f67be 100644
--- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt
@@ -4,17 +4,25 @@ Required properties:
 - compatible :
         "ti,dm646x-mcasp-audio" : for DM646x platforms
         "ti,da830-mcasp-audio"  : for both DA830 & DA850 platforms
-        "ti,omap2-mcasp-audio"  : for OMAP2 platforms (TI81xx, AM33xx)
-
-- reg : Should contain McASP registers offset and length
-- interrupts : Interrupt number for McASP
-- op-mode : I2S/DIT ops mode.
-- tdm-slots : Slots for TDM operation.
-- num-serializer : Serializers used by McASP.
-- serial-dir : A list of serializer pin mode. The list number should be equal
-                to "num-serializer" parameter. Each entry is a number indication
-                serializer pin direction. (0 - INACTIVE, 1 - TX, 2 - RX)
+        "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, TI81xx)
 
+- reg : Should contain reg specifiers for the entries in the reg-names property.
+- reg-names : Should contain:
+         * "mpu" for the main registers (required). For compatibility with
+           existing software, it is recommended this is the first entry.
+         * "dat" for separate data port register access (optional).
+- op-mode : I2S/DIT ops mode. 0 for I2S mode. 1 for DIT mode used for S/PDIF,
+            IEC60958-1, and AES-3 formats.
+- tdm-slots : Slots for TDM operation. Indicates number of channels transmitted
+              or received over one serializer.
+- serial-dir : A list of serializer configuration. Each entry is a number
+               indication for serializer pin direction.
+               (0 - INACTIVE, 1 - TX, 2 - RX)
+- dmas: two element list of DMA controller phandles 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. The dma
+             identifiers must be "rx" and "tx".
 
 Optional properties:
 
@@ -23,18 +31,23 @@ Optional properties:
 - rx-num-evt : FIFO levels.
 - sram-size-playback : size of sram to be allocated during playback
 - sram-size-capture  : size of sram to be allocated during capture
+- interrupts : Interrupt numbers for McASP, currently not used by the driver
+- interrupt-names : Known interrupt names are "tx" and "rx"
+- pinctrl-0: Should specify pin control group used for this controller.
+- pinctrl-names: Should contain only one value - "default", for more details
+                 please refer to pinctrl-bindings.txt
+  
 
 Example:
 
 mcasp0: mcasp0@1d00000 {
         compatible = "ti,da830-mcasp-audio";
-        #address-cells = <1>;
-        #size-cells = <0>;
         reg = <0x100000 0x3000>;
-        interrupts = <82 83>;
+        reg-names "mpu";
+        interrupts = <82>, <83>;
+        interrupts-names = "tx", "rx";
         op-mode = <0>;          /* MCASP_IIS_MODE */
         tdm-slots = <2>;
-        num-serializer = <16>;
         serial-dir = <
                         0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */
                         0 0 0 0
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 705a6b156c6c..5e6040c2c2e9 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -24,10 +24,36 @@ Optional properties:
         3 - MICBIAS output is connected to AVDD,
         If this node is not mentioned or if the value is incorrect, then MicBias
         is powered down.
+- AVDD-supply, IOVDD-supply, DRVDD-supply, DVDD-supply : power supplies for the
+  device as covered in Documentation/devicetree/bindings/regulator/regulator.txt
+
+CODEC output pins:
+  * LLOUT
+  * RLOUT
+  * MONO_LOUT
+  * HPLOUT
+  * HPROUT
+  * HPLCOM
+  * HPRCOM
+
+CODEC input pins:
+  * MIC3L
+  * MIC3R
+  * LINE1L
+  * LINE2L
+  * LINE1R
+  * LINE2R
+
+The pins can be used in referring sound node's audio-routing property.
 
 Example:
 
 tlv320aic3x: tlv320aic3x@1b {
         compatible = "ti,tlv320aic3x";
         reg = <0x1b>;
+
+        AVDD-supply = <&regulator>;
+        IOVDD-supply = <&regulator>;
+        DRVDD-supply = <&regulator>;
+        DVDD-supply = <&regulator>;
 };
diff --git a/Documentation/devicetree/bindings/sound/tpa6130a2.txt b/Documentation/devicetree/bindings/sound/tpa6130a2.txt
new file mode 100644
index 000000000000..6dfa740e4b2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tpa6130a2.txt
@@ -0,0 +1,27 @@
+Texas Instruments - tpa6130a2 Codec module
+
+The tpa6130a2 serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - "string" - One of:
+    "ti,tpa6130a2" - TPA6130A2
+    "ti,tpa6140a2" - TPA6140A2
+
+
+- reg - <int> -  I2C slave address
+
+- Vdd-supply - <phandle> - power supply regulator
+
+Optional properties:
+
+- power-gpio - gpio pin to power the device
+
+Example:
+
+tpa6130a2: tpa6130a2@60 {
+        compatible = "ti,tpa6130a2";
+        reg = <0x60>;
+        Vdd-supply = <&vmmc2>;
+        power-gpio = <&gpio4 2 GPIO_ACTIVE_HIGH>;
+};
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 4c85c4c69584..2ba5f9c023ac 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -2,8 +2,8 @@ OMAP2+ McSPI device
 
 Required properties:
 - compatible :
-  - "ti,omap2-spi" for OMAP2 & OMAP3.
-  - "ti,omap4-spi" for OMAP4+.
+  - "ti,omap2-mcspi" for OMAP2 & OMAP3.
+  - "ti,omap4-mcspi" for OMAP4+.
 - ti,spi-num-cs : Number of chipselect supported  by the instance.
 - ti,hwmods: Name of the hwmod associated to the McSPI
 - ti,pindir-d0-out-d1-in: Select the D0 pin as output and D1 as
diff --git a/Documentation/devicetree/bindings/spi/sh-hspi.txt b/Documentation/devicetree/bindings/spi/sh-hspi.txt
new file mode 100644
index 000000000000..30b57b1c8a13
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/sh-hspi.txt
@@ -0,0 +1,7 @@
+Renesas HSPI.
+
+Required properties:
+- compatible :  "renesas,hspi"
+- reg : Offset and length of the register set for the device
+- interrupts : interrupt line used by HSPI
+
diff --git a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
index 46882058b59b..ee05dc390694 100644
--- a/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
+++ b/Documentation/devicetree/bindings/staging/iio/adc/mxs-lradc.txt
@@ -1,7 +1,8 @@
 * Freescale i.MX28 LRADC device driver
 
 Required properties:
-- compatible: Should be "fsl,imx28-lradc"
+- compatible: Should be "fsl,imx23-lradc" for i.MX23 SoC and "fsl,imx28-lradc"
+              for i.MX28 SoC
 - reg: Address and length of the register set for the device
 - interrupts: Should contain the LRADC interrupts
 
@@ -9,13 +10,38 @@ Optional properties:
 - fsl,lradc-touchscreen-wires: Number of wires used to connect the touchscreen
                                to LRADC. Valid value is either 4 or 5. If this
                                property is not present, then the touchscreen is
-                               disabled.
+                               disabled. 5 wires is valid for i.MX28 SoC only.
+- fsl,ave-ctrl: number of samples per direction to calculate an average value.
+                Allowed value is 1 ... 31, default is 4
+- fsl,ave-delay: delay between consecutive samples. Allowed value is
+                 1 ... 2047. It is used if 'fsl,ave-ctrl' > 1, counts at
+                 2 kHz and its default is 2 (= 1 ms)
+- fsl,settling: delay between plate switch to next sample. Allowed value is
+                1 ... 2047. It counts at 2 kHz and its default is
+                10 (= 5 ms)
 
-Examples:
+Example for i.MX23 SoC:
+
+        lradc@80050000 {
+                compatible = "fsl,imx23-lradc";
+                reg = <0x80050000 0x2000>;
+                interrupts = <36 37 38 39 40 41 42 43 44>;
+                status = "okay";
+                fsl,lradc-touchscreen-wires = <4>;
+                fsl,ave-ctrl = <4>;
+                fsl,ave-delay = <2>;
+                fsl,settling = <10>;
+        };
+
+Example for i.MX28 SoC:
 
         lradc@80050000 {
                 compatible = "fsl,imx28-lradc";
                 reg = <0x80050000 0x2000>;
-                interrupts = <10 14 15 16 17 18 19
-                                20 21 22 23 24 25>;
+                interrupts = <10 14 15 16 17 18 19 20 21 22 23 24 25>;
+                status = "okay";
+                fsl,lradc-touchscreen-wires = <5>;
+                fsl,ave-ctrl = <4>;
+                fsl,ave-delay = <2>;
+                fsl,settling = <10>;
         };
diff --git a/Documentation/devicetree/bindings/timer/efm32,timer.txt b/Documentation/devicetree/bindings/timer/efm32,timer.txt
new file mode 100644
index 000000000000..97a568f696c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/efm32,timer.txt
@@ -0,0 +1,23 @@
+* EFM32 timer hardware
+
+The efm32 Giant Gecko SoCs come with four 16 bit timers. Two counters can be
+connected to form a 32 bit counter. Each timer has three Compare/Capture
+channels and can be used as PWM or Quadrature Decoder. Available clock sources
+are the cpu's HFPERCLK (with a 10-bit prescaler) or an external pin.
+
+Required properties:
+- compatible : Should be efm32,timer
+- reg : Address and length of the register set
+- clocks : Should contain a reference to the HFPERCLK
+
+Optional properties:
+- interrupts : Reference to the timer interrupt
+
+Example:
+
+timer@40010c00 {
+        compatible = "efm32,timer";
+        reg = <0x40010c00 0x400>;
+        interrupts = <14>;
+        clocks = <&cmu clk_HFPERCLKTIMER3>;
+};
diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
new file mode 100644
index 000000000000..5ea26c631e3a
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt
@@ -0,0 +1,17 @@
+MSM SoC HSUSB controllers
+
+EHCI
+
+Required properties:
+- compatible:   Should contain "qcom,ehci-host"
+- regs:                 offset and length of the register set in the memory map
+- usb-phy:              phandle for the PHY device
+
+Example EHCI controller device node:
+
+        ehci: ehci@f9a55000 {
+                compatible = "qcom,ehci-host";
+                reg = <0xf9a55000 0x400>;
+                usb-phy = <&usb_otg>;
+        };
+
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index 9088ab09e200..090e5e22bd2b 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -3,9 +3,6 @@ OMAP GLUE AND OTHER OMAP SPECIFIC COMPONENTS
 OMAP MUSB GLUE
  - compatible : Should be "ti,omap4-musb" or "ti,omap3-musb"
  - ti,hwmods : must be "usb_otg_hs"
- - ti,has-mailbox : to specify that omap uses an external mailbox
-   (in control module) to communicate with the musb core during device connect
-   and disconnect.
  - multipoint : Should be "1" indicating the musb controller supports
    multipoint. This is a MUSB configuration-specific setting.
  - num-eps : Specifies the number of endpoints. This is also a
@@ -19,6 +16,9 @@ OMAP MUSB GLUE
  - 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
+ - phys : the phandle for the PHY device (used by generic PHY framework)
+ - phy-names : the names of the PHY corresponding to the PHYs present in the
+   *phy* phandle.
 
 Optional properties:
  - ctrl-module : phandle of the control module this glue uses to write to
@@ -28,11 +28,12 @@ SOC specific device node entry
 usb_otg_hs: usb_otg_hs@4a0ab000 {
         compatible = "ti,omap4-musb";
         ti,hwmods = "usb_otg_hs";
-        ti,has-mailbox;
         multipoint = <1>;
         num-eps = <16>;
         ram-bits = <12>;
         ctrl-module = <&omap_control_usb>;
+        phys = <&usb2_phy>;
+        phy-names = "usb2-phy";
 };
 
 Board specific device node entry
@@ -78,22 +79,22 @@ omap_dwc3 {
 OMAP CONTROL USB
 
 Required properties:
- - compatible: Should be "ti,omap-control-usb"
+ - compatible: Should be one of
+ "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
+ "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
+                        e.g. USB2_PHY on OMAP5.
+ "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
+                        e.g. USB3 PHY and SATA PHY on OMAP5.
+ "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
+                        DRA7 platform.
  - reg : Address and length of the register set for the device. It contains
-   the address of "control_dev_conf" and "otghs_control" or "phy_power_usb"
-   depending upon omap4 or omap5.
- - reg-names: The names of the register addresses corresponding to the registers
-   filled in "reg".
- - ti,type: This is used to differentiate whether the control module has
-   usb mailbox or usb3 phy power. omap4 has usb mailbox in control module to
-   notify events to the musb core and omap5 has usb3 phy power register to
-   power on usb3 phy. Should be "1" if it has mailbox and "2" if it has usb3
-   phy power.
+   the address of "otghs_control" for control-phy-otghs or "power" register
+   for other types.
+ - reg-names: should be "otghs_control" control-phy-otghs and "power" for
+   other types.
 
 omap_control_usb: omap-control-usb@4a002300 {
-        compatible = "ti,omap-control-usb";
-        reg = <0x4a002300 0x4>,
-              <0x4a00233c 0x4>;
-        reg-names = "control_dev_conf", "otghs_control";
-        ti,type = <1>;
+        compatible = "ti,control-phy-otghs";
+        reg = <0x4a00233c 0x4>;
+        reg-names = "otghs_control";
 };
diff --git a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
index d7e272671c7e..1bd37faba05b 100644
--- a/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
+++ b/Documentation/devicetree/bindings/usb/usb-nop-xceiv.txt
@@ -15,7 +15,7 @@ Optional properties:
 
 - vcc-supply: phandle to the regulator that provides RESET to the PHY.
 
-- reset-supply: phandle to the regulator that provides power to the PHY.
+- reset-gpios: Should specify the GPIO for reset.
 
 Example:
 
@@ -25,10 +25,9 @@ Example:
                 clocks = <&osc 0>;
                 clock-names = "main_clk";
                 vcc-supply = <&hsusb1_vcc_regulator>;
-                reset-supply = <&hsusb1_reset_regulator>;
+                reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
         };
 
 hsusb1_phy is a NOP USB PHY device that gets its clock from an oscillator
 and expects that clock to be configured to 19.2MHz by the NOP PHY driver.
-hsusb1_vcc_regulator provides power to the PHY and hsusb1_reset_regulator
-controls RESET.
+hsusb1_vcc_regulator provides power to the PHY and GPIO 7 controls RESET.
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
index 61496f5cb095..c0245c888982 100644
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ b/Documentation/devicetree/bindings/usb/usb-phy.txt
@@ -5,6 +5,8 @@ OMAP USB2 PHY
 Required properties:
  - compatible: Should be "ti,omap-usb2"
  - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -16,6 +18,7 @@ usb2phy@4a0ad080 {
         compatible = "ti,omap-usb2";
         reg = <0x4a0ad080 0x58>;
         ctrl-module = <&omap_control_usb>;
+        #phy-cells = <0>;
 };
 
 OMAP USB3 PHY
@@ -25,6 +28,8 @@ Required properties:
  - reg : Address and length of the register set for the device.
  - reg-names: The names of the register addresses corresponding to the registers
    filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
 
 Optional properties:
  - ctrl-module : phandle of the control module used by PHY driver to power on
@@ -39,4 +44,5 @@ usb3phy@4a084400 {
               <0x4a084c00 0x40>;
         reg-names = "phy_rx", "phy_tx", "pll_ctrl";
         ctrl-module = <&omap_control_usb>;
+        #phy-cells = <0>;
 };
diff --git a/Documentation/devicetree/bindings/usb/ux500-usb.txt b/Documentation/devicetree/bindings/usb/ux500-usb.txt
index 330d6ec15401..439a41c79afa 100644
--- a/Documentation/devicetree/bindings/usb/ux500-usb.txt
+++ b/Documentation/devicetree/bindings/usb/ux500-usb.txt
@@ -15,7 +15,7 @@ Optional properties:
 Example:
 
 usb_per5@a03e0000 {
-        compatible = "stericsson,db8500-musb", "mentor,musb";
+        compatible = "stericsson,db8500-musb";
         reg = <0xa03e0000 0x10000>;
         interrupts = <0 23 0x4>;
         interrupt-names = "mc";
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 2956800f0240..ce95ed1c6d3e 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -12,11 +12,15 @@ amcc	Applied Micro Circuits Corporation (APM, formally AMCC)
 apm     Applied Micro Circuits Corporation (APM)
 arm     ARM Ltd.
 atmel   Atmel Corporation
+auo     AU Optronics Corporation
 avago   Avago Technologies
 bosch   Bosch Sensortec GmbH
 brcm    Broadcom Corporation
+capella Capella Microsystems, Inc
 cavium  Cavium, Inc.
+cdns    Cadence Design Systems Inc.
 chrp    Common Hardware Reference Platform
+chunghwa        Chunghwa Picture Tubes Ltd.
 cirrus  Cirrus Logic, Inc.
 cortina Cortina Systems, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
@@ -45,6 +49,8 @@ nintendo	Nintendo
 nvidia  NVIDIA
 nxp     NXP Semiconductors
 onnn    ON Semiconductor Corp.
+panasonic       Panasonic Corporation
+phytec  PHYTEC Messtechnik GmbH
 picochip        Picochip Ltd
 powervr PowerVR (deprecated, use img)
 qca     Qualcomm Atheros, Inc.
@@ -64,12 +70,12 @@ snps 	Synopsys, Inc.
 st      STMicroelectronics
 ste     ST-Ericsson
 stericsson      ST-Ericsson
-toumaz  Toumaz
 ti      Texas Instruments
 toshiba Toshiba Corporation
+toumaz  Toumaz
 v3      V3 Semiconductor
 via     VIA Technologies, Inc.
+winbond Winbond Electronics corp.
 wlf     Wolfson Microelectronics
 wm      Wondermedia Technologies, Inc.
-winbond Winbond Electronics corp.
 xlnx    Xilinx
diff --git a/Documentation/devicetree/bindings/video/atmel,lcdc.txt b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
new file mode 100644
index 000000000000..1ec175eddca8
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/atmel,lcdc.txt
@@ -0,0 +1,75 @@
+Atmel LCDC Framebuffer
+-----------------------------------------------------
+
+Required properties:
+- compatible :
+        "atmel,at91sam9261-lcdc" , 
+        "atmel,at91sam9263-lcdc" ,
+        "atmel,at91sam9g10-lcdc" ,
+        "atmel,at91sam9g45-lcdc" ,
+        "atmel,at91sam9g45es-lcdc" ,
+        "atmel,at91sam9rl-lcdc" ,
+        "atmel,at32ap-lcdc"
+- reg : Should contain 1 register ranges(address and length)
+- interrupts : framebuffer controller interrupt
+- display: a phandle pointing to the display node
+
+Required nodes:
+- display: a display node is required to initialize the lcd panel
+        This should be in the board dts.
+- default-mode: a videomode within the display with timing parameters
+        as specified below.
+
+Example:
+
+        fb0: fb@0x00500000 {
+                compatible = "atmel,at91sam9g45-lcdc";
+                reg = <0x00500000 0x1000>;
+                interrupts = <23 3 0>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&pinctrl_fb>;
+                display = <&display0>;
+                status = "okay";
+                #address-cells = <1>;
+                #size-cells = <1>;
+
+        };
+
+Atmel LCDC Display
+-----------------------------------------------------
+Required properties (as per of_videomode_helper):
+
+ - atmel,dmacon: dma controler configuration
+ - atmel,lcdcon2: lcd controler configuration
+ - atmel,guard-time: lcd guard time (Delay in frame periods)
+ - bits-per-pixel: lcd panel bit-depth.
+
+Optional properties (as per of_videomode_helper):
+ - atmel,lcdcon-backlight: enable backlight
+ - atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
+ - atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
+
+Example:
+        display0: display {
+                bits-per-pixel = <32>;
+                atmel,lcdcon-backlight;
+                atmel,dmacon = <0x1>;
+                atmel,lcdcon2 = <0x80008002>;
+                atmel,guard-time = <9>;
+                atmel,lcd-wiring-mode = <1>;
+
+                display-timings {
+                        native-mode = <&timing0>;
+                        timing0: timing0 {
+                                clock-frequency = <9000000>;
+                                hactive = <480>;
+                                vactive = <272>;
+                                hback-porch = <1>;
+                                hfront-porch = <1>;
+                                vback-porch = <40>;
+                                vfront-porch = <1>;
+                                hsync-len = <45>;
+                                vsync-len = <1>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/video/backlight/lp855x.txt b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
index 1482103d288f..96e83a56048e 100644
--- a/Documentation/devicetree/bindings/video/backlight/lp855x.txt
+++ b/Documentation/devicetree/bindings/video/backlight/lp855x.txt
@@ -2,7 +2,7 @@ lp855x bindings
 
 Required properties:
   - compatible: "ti,lp8550", "ti,lp8551", "ti,lp8552", "ti,lp8553",
-                "ti,lp8556", "ti,lp8557"
+                "ti,lp8555", "ti,lp8556", "ti,lp8557"
   - reg: I2C slave address (u8)
   - dev-ctrl: Value of DEVICE CONTROL register (u8). It depends on the device.
 
@@ -15,6 +15,33 @@ Optional properties:
 
 Example:
 
+        /* LP8555 */
+        backlight@2c {
+                compatible = "ti,lp8555";
+                reg = <0x2c>;
+
+                dev-ctrl = /bits/ 8 <0x00>;
+                pwm-period = <10000>;
+
+                /* 4V OV, 4 output LED0 string enabled */
+                rom_14h {
+                        rom-addr = /bits/ 8 <0x14>;
+                        rom-val = /bits/ 8 <0xcf>;
+                };
+
+                /* Heavy smoothing, 24ms ramp time step */
+                rom_15h {
+                        rom-addr = /bits/ 8 <0x15>;
+                        rom-val = /bits/ 8 <0xc7>;
+                };
+
+                /* 4 output LED1 string enabled */
+                rom_19h {
+                        rom-addr = /bits/ 8 <0x19>;
+                        rom-val = /bits/ 8 <0x0f>;
+                };
+        };
+
         /* LP8556 */
         backlight@2c {
                 compatible = "ti,lp8556";
diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc727f3b1..764db86d441a 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -10,12 +10,16 @@ Required properties:
       last value in the array represents a 100% duty cycle (brightest).
   - default-brightness-level: the default brightness level (index into the
       array defined by the "brightness-levels" property)
+  - power-supply: regulator for supply voltage
 
 Optional properties:
   - pwm-names: a list of names for the PWM devices specified in the
                "pwms" property (see PWM binding[0])
+  - enable-gpios: contains a single GPIO specifier for the GPIO which enables
+                  and disables the backlight (see GPIO binding[1])
 
 [0]: Documentation/devicetree/bindings/pwm/pwm.txt
+[1]: Documentation/devicetree/bindings/gpio/gpio.txt
 
 Example:
 
@@ -25,4 +29,7 @@ Example:
 
                 brightness-levels = <0 4 8 16 32 64 128 255>;
                 default-brightness-level = <6>;
+
+                power-supply = <&vdd_bl_reg>;
+                enable-gpios = <&gpio 58 0>;
         };
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
index 84f10c16cb38..3289d76a21d0 100644
--- a/Documentation/devicetree/bindings/video/exynos_dp.txt
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -6,10 +6,10 @@ We use two nodes:
         -dptx-phy node(defined inside dp-controller node)
 
 For the DP-PHY initialization, we use the dptx-phy node.
-Required properties for dptx-phy:
-        -reg:
+Required properties for dptx-phy: deprecated, use phys and phy-names
+        -reg: deprecated
                 Base address of DP PHY register.
-        -samsung,enable-mask:
+        -samsung,enable-mask: deprecated
                 The bit-mask used to enable/disable DP PHY.
 
 For the Panel initialization, we read data from dp-controller node.
@@ -27,6 +27,10 @@ Required properties for dp-controller:
                 from common clock binding: Shall be "dp".
         -interrupt-parent:
                 phandle to Interrupt combiner node.
+        -phys:
+                from general PHY binding: the phandle for the PHY device.
+        -phy-names:
+                from general PHY binding: Should be "dp".
         -samsung,color-space:
                 input video data format.
                         COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
@@ -68,11 +72,8 @@ SOC specific portion:
                 clocks = <&clock 342>;
                 clock-names = "dp";
 
-                dptx-phy {
-                        reg = <0x10040720>;
-                        samsung,enable-mask = <1>;
-                };
-
+                phys = <&dp_phy>;
+                phy-names = "dp";
         };
 
 Board Specific portion:
diff --git a/Documentation/devicetree/bindings/video/exynos_hdmi.txt b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
index 323983be3c30..50decf8e1b90 100644
--- a/Documentation/devicetree/bindings/video/exynos_hdmi.txt
+++ b/Documentation/devicetree/bindings/video/exynos_hdmi.txt
@@ -12,7 +12,19 @@ Required properties:
         a) phandle of the gpio controller node.
         b) pin number within the gpio controller.
         c) optional flags and pull up/down.
-
+- clocks: list of clock IDs from SoC clock driver.
+        a) hdmi: Gate of HDMI IP bus clock.
+        b) sclk_hdmi: Gate of HDMI special clock.
+        c) sclk_pixel: Pixel special clock, one of the two possible inputs of
+                HDMI clock mux.
+        d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of
+                HDMI clock mux.
+        e) mout_hdmi: It is required by the driver to switch between the 2
+                parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable
+                after configuration, parent is set to sclk_hdmiphy else
+                sclk_pixel.
+- clock-names: aliases as per driver requirements for above clock IDs:
+        "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi".
 Example:
 
         hdmi {
diff --git a/Documentation/devicetree/bindings/video/exynos_mixer.txt b/Documentation/devicetree/bindings/video/exynos_mixer.txt
index 3334b0a8e343..7bfde9c9d658 100644
--- a/Documentation/devicetree/bindings/video/exynos_mixer.txt
+++ b/Documentation/devicetree/bindings/video/exynos_mixer.txt
@@ -10,6 +10,10 @@ Required properties:
 - reg: physical base address of the mixer and length of memory mapped
         region.
 - interrupts: interrupt number to the cpu.
+- clocks: list of clock IDs from SoC clock driver.
+        a) mixer: Gate of Mixer IP bus clock.
+        b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of
+               mixer mux.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/watchdog/dw_wdt.txt b/Documentation/devicetree/bindings/watchdog/dw_wdt.txt
new file mode 100644
index 000000000000..08e16f684f2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/dw_wdt.txt
@@ -0,0 +1,21 @@
+Synopsys Designware Watchdog Timer
+
+Required Properties:
+
+- compatible    : Should contain "snps,dw-wdt"
+- reg           : Base address and size of the watchdog timer registers.
+- clocks        : phandle + clock-specifier for the clock that drives the
+                watchdog timer.
+
+Optional Properties:
+
+- interrupts    : The interrupt used for the watchdog timeout warning.
+
+Example:
+
+        watchdog0: wd@ffd02000 {
+                compatible = "snps,dw-wdt";
+                reg = <0xffd02000 0x1000>;
+                interrupts = <0 171 4>;
+                clocks = <&per_base_clk>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt b/Documentation/devicetree/bindings/watchdog/men-a021-wdt.txt
index 370dee3226d9..370dee3226d9 100644
--- a/Documentation/devicetree/bindings/gpio/men-a021-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/men-a021-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
new file mode 100644
index 000000000000..1169857d1d12
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/moxa,moxart-watchdog.txt
@@ -0,0 +1,15 @@
+MOXA ART Watchdog timer
+
+Required properties:
+
+- compatible : Must be "moxa,moxart-watchdog"
+- reg : Should contain registers location and length
+- clocks : Should contain phandle for the clock that drives the counter
+
+Example:
+
+        watchdog: watchdog@98500000 {
+                compatible = "moxa,moxart-watchdog";
+                reg = <0x98500000 0x10>;
+                clocks = <&coreclk>;
+        };
diff --git a/Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt b/Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt
new file mode 100644
index 000000000000..d7bab3db9d1f
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/rt2880-wdt.txt
@@ -0,0 +1,19 @@
+Ralink Watchdog Timers
+
+Required properties:
+- compatible: must be "ralink,rt2880-wdt"
+- reg: physical base address of the controller and length of the register range
+
+Optional properties:
+- interrupt-parent: phandle to the INTC device node
+- interrupts: Specify the INTC interrupt number
+
+Example:
+
+        watchdog@120 {
+                compatible = "ralink,rt2880-wdt";
+                reg = <0x120 0x10>;
+
+                interrupt-parent = <&intc>;
+                interrupts = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt b/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt
new file mode 100644
index 000000000000..9cbc76c89b2b
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/sirfsoc_wdt.txt
@@ -0,0 +1,14 @@
+SiRFSoC Timer and Watchdog Timer(WDT) Controller
+
+Required properties:
+- compatible: "sirf,prima2-tick"
+- reg: Address range of tick timer/WDT register set
+- interrupts: interrupt number to the cpu
+
+Example:
+
+timer@b0020000 {
+        compatible = "sirf,prima2-tick";
+        reg = <0xb0020000 0x1000>;
+        interrupts = <0>;
+};
diff --git a/Documentation/dmatest.txt b/Documentation/dmatest.txt
index a2b5663eae26..dd77a81bdb80 100644
--- a/Documentation/dmatest.txt
+++ b/Documentation/dmatest.txt
@@ -15,39 +15,48 @@ be built as module or inside kernel. Let's consider those cases.
 
         Part 2 - When dmatest is built as a module...
 
-After mounting debugfs and loading the module, the /sys/kernel/debug/dmatest
-folder with nodes will be created. There are two important files located. First
-is the 'run' node that controls run and stop phases of the test, and the second
-one, 'results', is used to get the test case results.
-
-Note that in this case test will not run on load automatically.
-
 Example of usage:
+        % modprobe dmatest channel=dma0chan0 timeout=2000 iterations=1 run=1
+
+...or:
+        % modprobe dmatest
         % echo dma0chan0 > /sys/module/dmatest/parameters/channel
         % echo 2000 > /sys/module/dmatest/parameters/timeout
         % echo 1 > /sys/module/dmatest/parameters/iterations
-        % echo 1 > /sys/kernel/debug/dmatest/run
+        % echo 1 > /sys/module/dmatest/parameters/run
+
+...or on the kernel command line:
+
+        dmatest.channel=dma0chan0 dmatest.timeout=2000 dmatest.iterations=1 dmatest.run=1
 
 Hint: available channel list could be extracted by running the following
 command:
         % ls -1 /sys/class/dma/
 
-After a while you will start to get messages about current status or error like
-in the original code.
+Once started a message like "dmatest: Started 1 threads using dma0chan0" is
+emitted.  After that only test failure messages are reported until the test
+stops.
 
 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
-
-To wait for test done the user may perform a busy loop that checks the state.
-
-        % while [ $(cat /sys/kernel/debug/dmatest/run) = "Y" ]
-        > do
-        >       echo -n "."
-        >       sleep 1
-        > done
-        > echo
+The following command returns the state of the test.
+        % cat /sys/module/dmatest/parameters/run
+
+To wait for test completion userpace can poll 'run' until it is false, or use
+the wait parameter.  Specifying 'wait=1' when loading the module causes module
+initialization to pause until a test run has completed, while reading
+/sys/module/dmatest/parameters/wait waits for any running test to complete
+before returning.  For example, the following scripts wait for 42 tests
+to complete before exiting.  Note that if 'iterations' is set to 'infinite' then
+waiting is disabled.
+
+Example:
+        % modprobe dmatest run=1 iterations=42 wait=1
+        % modprobe -r dmatest
+...or:
+        % modprobe dmatest run=1 iterations=42
+        % cat /sys/module/dmatest/parameters/wait
+        % modprobe -r dmatest
 
         Part 3 - When built-in in the kernel...
 
@@ -62,21 +71,22 @@ case. You always could check them at run-time by running
 
         Part 4 - Gathering the test results
 
-The module provides a storage for the test results in the memory. The gathered
-data could be used after test is done.
+Test results are printed to the kernel log buffer with the format:
 
-The special file 'results' in the debugfs represents gathered data of the in
-progress test. The messages collected are printed to the kernel log as well.
+"dmatest: result <channel>: <test id>: '<error msg>' with src_off=<val> dst_off=<val> len=<val> (<err code>)"
 
 Example of output:
-        % cat /sys/kernel/debug/dmatest/results
-        dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)
+        % dmesg | tail -n 1
+        dmatest: result dma0chan0-copy0: #1: No errors with src_off=0x7bf dst_off=0x8ad len=0x3fea (0)
 
 The message format is unified across the different types of errors. A number in
 the parens represents additional information, e.g. error code, error counter,
-or status.
+or status.  A test thread also emits a summary line at completion listing the
+number of tests executed, number that failed, and a result code.
 
-Comparison between buffers is stored to the dedicated structure.
+Example:
+        % dmesg | tail -n 1
+        dmatest: dma0chan0-copy0: summary 1 test, 0 failures 1000 iops 100000 KB/s (0)
 
-Note that the verify result is now accessible only via file 'results' in the
-debugfs.
+The details of a data miscompare error are also emitted, but do not follow the
+above format.
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index fcb34a5697ea..5bdc8cb5fc28 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -283,6 +283,7 @@ REGULATOR
   devm_regulator_get()
   devm_regulator_put()
   devm_regulator_bulk_get()
+  devm_regulator_register()
 
 CLOCK
   devm_clk_get()
@@ -302,3 +303,6 @@ PHY
 
 SLAVE DMA ENGINE
   devm_acpi_dma_controller_register()
+
+SPI
+  devm_spi_register_master()
diff --git a/Documentation/x86/efi-stub.txt b/Documentation/efi-stub.txt
index 44e6bb6ead10..44e6bb6ead10 100644
--- a/Documentation/x86/efi-stub.txt
+++ b/Documentation/efi-stub.txt
diff --git a/Documentation/extcon/porting-android-switch-class b/Documentation/extcon/porting-android-switch-class
index eb0fa5f4fe88..5377f6317961 100644
--- a/Documentation/extcon/porting-android-switch-class
+++ b/Documentation/extcon/porting-android-switch-class
@@ -25,8 +25,10 @@ MyungJoo Ham <myungjoo.ham@samsung.com>
     @print_state: no change but type change (switch_dev->extcon_dev)
 
 - switch_dev_register(sdev, dev)
-        => extcon_dev_register(edev, dev)
-        : no change but type change (sdev->edev)
+        => extcon_dev_register(edev)
+        : type change (sdev->edev)
+        : remove second param('dev'). if edev has parent device, should store
+          'dev' to 'edev.dev.parent' before registering extcon device
 - switch_dev_unregister(sdev)
         => extcon_dev_unregister(edev)
         : no change but type change (sdev->edev)
diff --git a/Documentation/filesystems/btrfs.txt b/Documentation/filesystems/btrfs.txt
index 9dae59407437..5dd282dda55c 100644
--- a/Documentation/filesystems/btrfs.txt
+++ b/Documentation/filesystems/btrfs.txt
@@ -70,6 +70,12 @@ Unless otherwise specified, all options default to off.
 
         See comments at the top of fs/btrfs/check-integrity.c for more info.
 
+  commit=<seconds>
+        Set the interval of periodic commit, 30 seconds by default. Higher
+        values defer data being synced to permanent storage with obvious
+        consequences when the system crashes. The upper bound is not forced,
+        but a warning is printed if it's more than 300 seconds (5 minutes).
+
   compress
   compress=<type>
   compress-force
@@ -154,7 +160,11 @@ Unless otherwise specified, all options default to off.
         Currently this scans a list of several previous tree roots and tries to 
         use the first readable.
 
- skip_balance
+  rescan_uuid_tree
+        Force check and rebuild procedure of the UUID tree. This should not
+        normally be needed.
+
+  skip_balance
         Skip automatic resume of interrupted balance operation after mount.
         May be resumed with "btrfs balance resume."
 
@@ -234,24 +244,14 @@ available from the git repository at the following location:
 
 These include the following tools:
 
-mkfs.btrfs: create a filesystem
-
-btrfsctl: control program to create snapshots and subvolumes:
+* mkfs.btrfs: create a filesystem
 
-        mount /dev/sda2 /mnt
-        btrfsctl -s new_subvol_name /mnt
-        btrfsctl -s snapshot_of_default /mnt/default
-        btrfsctl -s snapshot_of_new_subvol /mnt/new_subvol_name
-        btrfsctl -s snapshot_of_a_snapshot /mnt/snapshot_of_new_subvol
-        ls /mnt
-        default snapshot_of_a_snapshot snapshot_of_new_subvol
-        new_subvol_name snapshot_of_default
+* btrfs: a single tool to manage the filesystems, refer to the manpage for more details
 
-        Snapshots and subvolumes cannot be deleted right now, but you can
-        rm -rf all the files and directories inside them.
+* 'btrfsck' or 'btrfs check': do a consistency check of the filesystem
 
-btrfsck: do a limited check of the FS extent trees.
+Other tools for specific tasks:
 
-btrfs-debug-tree: print all of the FS metadata in text form.  Example:
+* btrfs-convert: in-place conversion from ext2/3/4 filesystems
 
-        btrfs-debug-tree /dev/sda2 >& big_output_file
+* btrfs-image: dump filesystem metadata for debugging
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt
index 11a0a40ce445..aed6b94160b1 100644
--- a/Documentation/filesystems/caching/netfs-api.txt
+++ b/Documentation/filesystems/caching/netfs-api.txt
@@ -29,15 +29,16 @@ This document contains the following sections:
          (6) Index registration
          (7) Data file registration
          (8) Miscellaneous object registration
-         (9) Setting the data file size
+         (9) Setting the data file size
         (10) Page alloc/read/write
         (11) Page uncaching
         (12) Index and data file consistency
-        (13) Miscellaneous cookie operations
-        (14) Cookie unregistration
-        (15) Index invalidation
-        (16) Data file invalidation
-        (17) FS-Cache specific page flags.
+        (13) Cookie enablement
+        (14) Miscellaneous cookie operations
+        (15) Cookie unregistration
+        (16) Index invalidation
+        (17) Data file invalidation
+        (18) FS-Cache specific page flags.
 
 
 =============================
@@ -334,7 +335,8 @@ the path to the file:
         struct fscache_cookie *
         fscache_acquire_cookie(struct fscache_cookie *parent,
                                const struct fscache_object_def *def,
-                               void *netfs_data);
+                               void *netfs_data,
+                               bool enable);
 
 This function creates an index entry in the index represented by parent,
 filling in the index entry by calling the operations pointed to by def.
@@ -350,6 +352,10 @@ object needs to be created somewhere down the hierarchy.  Furthermore, an index
 may be created in several different caches independently at different times.
 This is all handled transparently, and the netfs doesn't see any of it.
 
+A cookie will be created in the disabled state if enabled is false.  A cookie
+must be enabled to do anything with it.  A disabled cookie can be enabled by
+calling fscache_enable_cookie() (see below).
+
 For example, with AFS, a cell would be added to the primary index.  This index
 entry would have a dependent inode containing a volume location index for the
 volume mappings within this cell:
@@ -357,7 +363,7 @@ volume mappings within this cell:
         cell->cache =
                 fscache_acquire_cookie(afs_cache_netfs.primary_index,
                                        &afs_cell_cache_index_def,
-                                       cell);
+                                       cell, true);
 
 Then when a volume location was accessed, it would be entered into the cell's
 index and an inode would be allocated that acts as a volume type and hash chain
@@ -366,7 +372,7 @@ combination:
         vlocation->cache =
                 fscache_acquire_cookie(cell->cache,
                                        &afs_vlocation_cache_index_def,
-                                       vlocation);
+                                       vlocation, true);
 
 And then a particular flavour of volume (R/O for example) could be added to
 that index, creating another index for vnodes (AFS inode equivalents):
@@ -374,7 +380,7 @@ that index, creating another index for vnodes (AFS inode equivalents):
         volume->cache =
                 fscache_acquire_cookie(vlocation->cache,
                                        &afs_volume_cache_index_def,
-                                       volume);
+                                       volume, true);
 
 
 ======================
@@ -388,7 +394,7 @@ the object definition should be something other than index type.
         vnode->cache =
                 fscache_acquire_cookie(volume->cache,
                                        &afs_vnode_cache_object_def,
-                                       vnode);
+                                       vnode, true);
 
 
 =================================
@@ -404,7 +410,7 @@ it would be some other type of object such as a data file.
         xattr->cache =
                 fscache_acquire_cookie(vnode->cache,
                                        &afs_xattr_cache_object_def,
-                                       xattr);
+                                       xattr, true);
 
 Miscellaneous objects might be used to store extended attributes or directory
 entries for example.
@@ -733,6 +739,47 @@ Note that partial updates may happen automatically at other times, such as when
 data blocks are added to a data file object.
 
 
+=================
+COOKIE ENABLEMENT
+=================
+
+Cookies exist in one of two states: enabled and disabled.  If a cookie is
+disabled, it ignores all attempts to acquire child cookies; check, update or
+invalidate its state; allocate, read or write backing pages - though it is
+still possible to uncache pages and relinquish the cookie.
+
+The initial enablement state is set by fscache_acquire_cookie(), but the cookie
+can be enabled or disabled later.  To disable a cookie, call:
+    
+        void fscache_disable_cookie(struct fscache_cookie *cookie,
+                                    bool invalidate);
+    
+If the cookie is not already disabled, this locks the cookie against other
+enable and disable ops, marks the cookie as being disabled, discards or
+invalidates any backing objects and waits for cessation of activity on any
+associated object before unlocking the cookie.
+
+All possible failures are handled internally.  The caller should consider
+calling fscache_uncache_all_inode_pages() afterwards to make sure all page
+markings are cleared up.
+    
+Cookies can be enabled or reenabled with:
+    
+        void fscache_enable_cookie(struct fscache_cookie *cookie,
+                                   bool (*can_enable)(void *data),
+                                   void *data)
+    
+If the cookie is not already enabled, this locks the cookie against other
+enable and disable ops, invokes can_enable() and, if the cookie is not an index
+cookie, will begin the procedure of acquiring backing objects.
+
+The optional can_enable() function is passed the data argument and returns a
+ruling as to whether or not enablement should actually be permitted to begin.
+
+All possible failures are handled internally.  The cookie will only be marked
+as enabled if provisional backing objects are allocated.
+
+
 ===============================
 MISCELLANEOUS COOKIE OPERATIONS
 ===============================
@@ -778,7 +825,7 @@ COOKIE UNREGISTRATION
 To get rid of a cookie, this function should be called.
 
         void fscache_relinquish_cookie(struct fscache_cookie *cookie,
-                                       int retire);
+                                       bool retire);
 
 If retire is non-zero, then the object will be marked for recycling, and all
 copies of it will be removed from all active caches in which it is present.
diff --git a/Documentation/filesystems/directory-locking b/Documentation/filesystems/directory-locking
index ff7b611abf33..09bbf9a54f80 100644
--- a/Documentation/filesystems/directory-locking
+++ b/Documentation/filesystems/directory-locking
@@ -2,6 +2,10 @@
 kinds of locks - per-inode (->i_mutex) and per-filesystem
 (->s_vfs_rename_mutex).
 
+        When taking the i_mutex on multiple non-directory objects, we
+always acquire the locks in order by increasing address.  We'll call
+that "inode pointer" order in the following.
+
         For our purposes all operations fall in 5 classes:
 
 1) read access.  Locking rules: caller locks directory we are accessing.
@@ -12,8 +16,9 @@ kinds of locks - per-inode (->i_mutex) and per-filesystem
 locks victim and calls the method.
 
 4) rename() that is _not_ cross-directory.  Locking rules: caller locks
-the parent, finds source and target, if target already exists - locks it
-and then calls the method.
+the parent and finds source and target.  If target already exists, lock
+it.  If source is a non-directory, lock it.  If that means we need to
+lock both, lock them in inode pointer order.
 
 5) link creation.  Locking rules:
         * lock parent
@@ -30,7 +35,9 @@ rules:
                 fail with -ENOTEMPTY
         * if new parent is equal to or is a descendent of source
                 fail with -ELOOP
-        * if target exists - lock it.
+        * If target exists, lock it.  If source is a non-directory, lock
+          it.  In case that means we need to lock both source and target,
+          do so in inode pointer order.
         * call the method.
 
 
@@ -56,9 +63,11 @@ objects - A < B iff A is an ancestor of B.
     renames will be blocked on filesystem lock and we don't start changing
     the order until we had acquired all locks).
 
-(3) any operation holds at most one lock on non-directory object and
-    that lock is acquired after all other locks.  (Proof: see descriptions
-    of operations).
+(3) locks on non-directory objects are acquired only after locks on
+    directory objects, and are acquired in inode pointer order.
+    (Proof: all operations but renames take lock on at most one
+    non-directory object, except renames, which take locks on source and
+    target in inode pointer order in the case they are not directories.)
 
         Now consider the minimal deadlock.  Each process is blocked on
 attempt to acquire some lock and already holds at least one lock.  Let's
@@ -66,9 +75,13 @@ consider the set of contended locks.  First of all, filesystem lock is
 not contended, since any process blocked on it is not holding any locks.
 Thus all processes are blocked on ->i_mutex.
 
-        Non-directory objects are not contended due to (3).  Thus link
-creation can't be a part of deadlock - it can't be blocked on source
-and it means that it doesn't hold any locks.
+        By (3), any process holding a non-directory lock can only be
+waiting on another non-directory lock with a larger address.  Therefore
+the process holding the "largest" such lock can always make progress, and
+non-directory objects are not included in the set of contended locks.
+
+        Thus link creation can't be a part of deadlock - it can't be
+blocked on source and it means that it doesn't hold any locks.
 
         Any contended object is either held by cross-directory rename or
 has a child that is also contended.  Indeed, suppose that it is held by
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index 3cd27bed6349..a3fe811bbdbc 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -119,6 +119,7 @@ active_logs=%u         Support configuring the number of active logs. In the
                        Default number is 6.
 disable_ext_identify   Disable the extension list configured by mkfs, so f2fs
                        does not aware of cold files such as media files.
+inline_xattr           Enable the inline xattrs feature.
 
 ================================================================================
 DEBUGFS ENTRIES
@@ -164,6 +165,12 @@ Files in /sys/fs/f2fs/<devname>
                               gc_idle = 1 will select the Cost Benefit approach
                               & setting gc_idle = 2 will select the greedy aproach.
 
+ reclaim_segments             This parameter controls the number of prefree
+                              segments to be reclaimed. If the number of prefree
+                              segments is larger than this number, f2fs tries to
+                              conduct checkpoint to reclaim the prefree segments
+                              to free segments. By default, 100 segments, 200MB.
+
 ================================================================================
 USAGE
 ================================================================================
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index f0890581f7f6..fe2b7ae6f962 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -455,3 +455,11 @@ in your dentry operations instead.
         vfs_follow_link has been removed.  Filesystems must use nd_set_link
         from ->follow_link for normal symlinks, or nd_jump_link for magic
         /proc/<pid> style links.
+--
+[mandatory]
+        iget5_locked()/ilookup5()/ilookup5_nowait() test() callback used to be
+        called with both ->i_lock and inode_hash_lock held; the former is *not*
+        taken anymore, so verify that your callbacks do not rely on it (none
+        of the in-tree instances did).  inode_hash_lock is still held,
+        of course, so they are still serialized wrt removal from inode hash,
+        as well as wrt set() callback of iget5_locked().
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 823c95faebd2..22d89aa37218 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -460,6 +460,7 @@ manner. The codes are the following:
     nl  - non-linear mapping
     ar  - architecture specific flag
     dd  - do not include area into core dump
+    sd  - soft-dirty flag
     mm  - mixed map area
     hg  - huge page advise flag
     nh  - no-huge page advise flag
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index aa1f459fa6cf..4a93e98b290a 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 which">
+                <slot #2, id = 0x02, characters = "xtension whic">
                 <slot #1, id = 0x01, characters = "My Big File.E">
                 <directory entry, name = "MYBIGFIL.EXT">
 
diff --git a/Documentation/gcov.txt b/Documentation/gcov.txt
index e7ca6478cd93..7b727783db7e 100644
--- a/Documentation/gcov.txt
+++ b/Documentation/gcov.txt
@@ -50,6 +50,10 @@ Configure the kernel with:
         CONFIG_DEBUG_FS=y
         CONFIG_GCOV_KERNEL=y
 
+select the gcc's gcov format, default is autodetect based on gcc version:
+
+        CONFIG_GCOV_FORMAT_AUTODETECT=y
+
 and to get coverage data for the entire kernel:
 
         CONFIG_GCOV_PROFILE_ALL=y
diff --git a/Documentation/hwmon/lm25066 b/Documentation/hwmon/lm25066
index c1b57d72efc3..b34c3de5c1bc 100644
--- a/Documentation/hwmon/lm25066
+++ b/Documentation/hwmon/lm25066
@@ -8,6 +8,11 @@ Supported chips:
     Datasheets:
         http://www.ti.com/lit/gpn/lm25056
         http://www.ti.com/lit/gpn/lm25056a
+  * TI LM25063
+    Prefix: 'lm25063'
+    Addresses scanned: -
+    Datasheet:
+        To be announced
   * National Semiconductor LM25066
     Prefix: 'lm25066'
     Addresses scanned: -
@@ -32,7 +37,7 @@ Description
 -----------
 
 This driver supports hardware montoring for National Semiconductor / TI LM25056,
-LM25066, LM5064, and LM5064 Power Management, Monitoring, Control, and
+LM25063, LM25066, LM5064, and LM5066 Power Management, Monitoring, Control, and
 Protection ICs.
 
 The driver is a client driver to the core PMBus driver. Please see
@@ -64,8 +69,12 @@ in1_input		Measured input voltage.
 in1_average             Average measured input voltage.
 in1_min                 Minimum input voltage.
 in1_max                 Maximum input voltage.
+in1_crit                Critical high input voltage (LM25063 only).
+in1_lcrit               Critical low input voltage (LM25063 only).
 in1_min_alarm           Input voltage low alarm.
 in1_max_alarm           Input voltage high alarm.
+in1_lcrit_alarm         Input voltage critical low alarm (LM25063 only).
+in1_crit_alarm          Input voltage critical high alarm. (LM25063 only).
 
 in2_label               "vmon"
 in2_input               Measured voltage on VAUX pin
@@ -80,12 +89,16 @@ in3_input		Measured output voltage.
 in3_average             Average measured output voltage.
 in3_min                 Minimum output voltage.
 in3_min_alarm           Output voltage low alarm.
+in3_highest             Historical minimum output voltage (LM25063 only).
+in3_lowest              Historical maximum output voltage (LM25063 only).
 
 curr1_label             "iin"
 curr1_input             Measured input current.
 curr1_average           Average measured input current.
 curr1_max               Maximum input current.
+curr1_crit              Critical input current (LM25063 only).
 curr1_max_alarm         Input current high alarm.
+curr1_crit_alarm        Input current critical high alarm (LM25063 only).
 
 power1_label            "pin"
 power1_input            Measured input power.
@@ -95,6 +108,11 @@ power1_alarm		Input power alarm
 power1_input_highest    Historical maximum power.
 power1_reset_history    Write any value to reset maximum power history.
 
+power2_label            "pout". LM25063 only.
+power2_input            Measured output power.
+power2_max              Maximum output power limit.
+power2_crit             Critical output power limit.
+
 temp1_input             Measured temperature.
 temp1_max               Maximum temperature.
 temp1_crit              Critical high temperature.
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index b466974e142f..ab81013cc390 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -122,6 +122,12 @@ Supported chips:
     Prefix: 'g781'
     Addresses scanned: I2C 0x4c, 0x4d
     Datasheet: Not publicly available from GMT
+  * Texas Instruments TMP451
+    Prefix: 'tmp451'
+    Addresses scanned: I2C 0x4c
+    Datasheet: Publicly available at TI website
+               http://www.ti.com/litv/pdf/sbos686
+
 
 Author: Jean Delvare <khali@linux-fr.org>
 
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
index dc0d08c61305..a0546fc42273 100644
--- a/Documentation/hwmon/ltc2978
+++ b/Documentation/hwmon/ltc2978
@@ -6,10 +6,15 @@ Supported chips:
     Prefix: 'ltc2974'
     Addresses scanned: -
     Datasheet: http://www.linear.com/product/ltc2974
-  * Linear Technology LTC2978
+  * Linear Technology LTC2977
+    Prefix: 'ltc2977'
+    Addresses scanned: -
+    Datasheet: http://www.linear.com/product/ltc2977
+  * Linear Technology LTC2978, LTC2978A
     Prefix: 'ltc2978'
     Addresses scanned: -
     Datasheet: http://www.linear.com/product/ltc2978
+               http://www.linear.com/product/ltc2978a
   * Linear Technology LTC3880
     Prefix: 'ltc3880'
     Addresses scanned: -
@@ -26,8 +31,9 @@ Description
 -----------
 
 LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
-monitor. LTC3880 is a dual output poly-phase step-down DC/DC controller. LTC3883
-is a single phase step-down DC/DC controller.
+monitor. LTC2977 is a pin compatible replacement for LTC2978. LTC3880 is a dual
+output poly-phase step-down DC/DC controller. LTC3883 is a single phase
+step-down DC/DC controller.
 
 
 Usage Notes
@@ -49,21 +55,25 @@ Sysfs attributes
 in1_label               "vin"
 in1_input               Measured input voltage.
 in1_min                 Minimum input voltage.
-in1_max                 Maximum input voltage. LTC2974 and LTC2978 only.
-in1_lcrit               Critical minimum input voltage. LTC2974 and LTC2978
-                        only.
+in1_max                 Maximum input voltage.
+                        LTC2974, LTC2977, and LTC2978 only.
+in1_lcrit               Critical minimum input voltage.
+                        LTC2974, LTC2977, and LTC2978 only.
 in1_crit                Critical maximum input voltage.
 in1_min_alarm           Input voltage low alarm.
-in1_max_alarm           Input voltage high alarm. LTC2974 and LTC2978 only.
-in1_lcrit_alarm         Input voltage critical low alarm. LTC2974 and LTC2978
-                        only.
+in1_max_alarm           Input voltage high alarm.
+                        LTC2974, LTC2977, and LTC2978 only.
+in1_lcrit_alarm         Input voltage critical low alarm.
+                        LTC2974, LTC2977, and LTC2978 only.
 in1_crit_alarm          Input voltage critical high alarm.
-in1_lowest              Lowest input voltage. LTC2974 and LTC2978 only.
+in1_lowest              Lowest input voltage.
+                        LTC2974, LTC2977, and LTC2978 only.
 in1_highest             Highest input voltage.
 in1_reset_history       Reset input voltage history.
 
 in[N]_label             "vout[1-8]".
                         LTC2974: N=2-5
+                        LTC2977: N=2-9
                         LTC2978: N=2-9
                         LTC3880: N=2-3
                         LTC3883: N=2
@@ -83,21 +93,23 @@ in[N]_reset_history	Reset output voltage history.
 temp[N]_input           Measured temperature.
                         On LTC2974, temp[1-4] report external temperatures,
                         and temp5 reports the chip temperature.
-                        On LTC2978, only one temperature measurement is
-                        supported and reports the chip temperature.
+                        On LTC2977 and LTC2978, only one temperature measurement
+                        is supported and reports the chip temperature.
                         On LTC3880, temp1 and temp2 report external
                         temperatures, and temp3 reports the chip temperature.
                         On LTC3883, temp1 reports an external temperature,
                         and temp2 reports the chip temperature.
-temp[N]_min             Mimimum temperature. LTC2974 and LTC2978 only.
+temp[N]_min             Mimimum temperature. LTC2974, LCT2977, and LTC2978 only.
 temp[N]_max             Maximum temperature.
 temp[N]_lcrit           Critical low temperature.
 temp[N]_crit            Critical high temperature.
-temp[N]_min_alarm       Temperature low alarm. LTC2974 and LTC2978 only.
+temp[N]_min_alarm       Temperature low alarm.
+                        LTC2974, LTC2977, and LTC2978 only.
 temp[N]_max_alarm       Temperature high alarm.
 temp[N]_lcrit_alarm     Temperature critical low alarm.
 temp[N]_crit_alarm      Temperature critical high alarm.
-temp[N]_lowest          Lowest measured temperature. LTC2974 and LTC2978 only.
+temp[N]_lowest          Lowest measured temperature.
+                        LTC2974, LTC2977, and LTC2978 only.
                         Not supported for chip temperature sensor on LTC2974.
 temp[N]_highest         Highest measured temperature. Not supported for chip
                         temperature sensor on LTC2974.
@@ -109,6 +121,7 @@ power1_input		Measured input power.
 
 power[N]_label          "pout[1-4]".
                         LTC2974: N=1-4
+                        LTC2977: Not supported
                         LTC2978: Not supported
                         LTC3880: N=1-2
                         LTC3883: N=2
@@ -123,6 +136,7 @@ curr1_reset_history	Reset input current history. LTC3883 only.
 
 curr[N]_label           "iout[1-4]".
                         LTC2974: N=1-4
+                        LTC2977: not supported
                         LTC2978: not supported
                         LTC3880: N=2-3
                         LTC3883: N=2
diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801
index d29dea0f3232..7b0dcdb57173 100644
--- a/Documentation/i2c/busses/i2c-i801
+++ b/Documentation/i2c/busses/i2c-i801
@@ -25,6 +25,7 @@ Supported adapters:
   * Intel Avoton (SOC)
   * Intel Wellsburg (PCH)
   * Intel Coleto Creek (PCH)
+  * Intel Wildcat Point-LP (PCH)
    Datasheets: Publicly available at the Intel website
 
 On Intel Patsburg and later chipsets, both the normal host SMBus controller
diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 8002c894c6b0..31bb6a4029ef 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -122,12 +122,14 @@ D-Pad:
       BTN_DPAD_*
     Analog buttons are reported as:
       ABS_HAT0X and ABS_HAT0Y
+      (for ABS values negative is left/up, positive is right/down)
 
 Analog-Sticks:
   The left analog-stick is reported as ABS_X, ABS_Y. The right analog stick is
   reported as ABS_RX, ABS_RY. Zero, one or two sticks may be present.
   If analog-sticks provide digital buttons, they are mapped accordingly as
   BTN_THUMBL (first/left) and BTN_THUMBR (second/right).
+    (for ABS values negative is left/up, positive is right/down)
 
 Triggers:
   Trigger buttons can be available as digital or analog buttons or both. User-
@@ -138,6 +140,7 @@ Triggers:
   ABS_HAT2X (right/ZR) and BTN_TL2 or ABS_HAT2Y (left/ZL).
   If only one trigger-button combination is present (upper+lower), they are
   reported as "right" triggers (BTN_TR/ABS_HAT1X).
+    (ABS trigger values start at 0, pressure is reported as positive values)
 
 Menu-Pad:
   Menu buttons are always digital and are mapped according to their location
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 2a5f0e14efa3..7cbfa3c4fc3d 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -138,6 +138,7 @@ Code  Seq#(hex)	Include File		Comments
 'H'     C0-DF   net/bluetooth/cmtp/cmtp.h       conflict!
 'H'     C0-DF   net/bluetooth/bnep/bnep.h       conflict!
 'H'     F1      linux/hid-roccat.h      <mailto:erazor_de@users.sourceforge.net>
+'H'     F8-FA   sound/firewire.h
 'I'     all     linux/isdn.h            conflict!
 'I'     00-0F   drivers/isdn/divert/isdn_divert.h       conflict!
 'I'     40-4F   linux/mISDNif.h         conflict!
diff --git a/Documentation/kbuild/kconfig.txt b/Documentation/kbuild/kconfig.txt
index 8ef6dbb6a462..bbc99c0c1094 100644
--- a/Documentation/kbuild/kconfig.txt
+++ b/Documentation/kbuild/kconfig.txt
@@ -20,16 +20,9 @@ symbols have been introduced.
 To see a list of new config symbols when using "make oldconfig", use
 
         cp user/some/old.config .config
-        yes "" | make oldconfig >conf.new
+        make listnewconfig
 
-and the config program will list as (NEW) any new symbols that have
-unknown values.  Of course, the .config file is also updated with
-new (default) values, so you can use:
-
-        grep "(NEW)" conf.new
-
-to see the new config symbols or you can use diffconfig to see the
-differences between the previous and new .config files:
+and the config program will list any new symbols, one per line.
 
         scripts/diffconfig .config.old .config | less
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 539a23631990..50680a59a2ff 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -480,6 +480,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Format: <io>,<irq>,<mode>
                         See header of drivers/net/hamradio/baycom_ser_hdx.c.
 
+        blkdevparts=    Manual partition parsing of block device(s) for
+                        embedded devices based on command line input.
+                        See Documentation/block/cmdline-partition.txt
+
         boot_delay=     Milliseconds to delay each printk during boot.
                         Values larger than 10 seconds (10000) are changed to
                         no delay (0).
@@ -843,6 +847,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         earlyprintk=    [X86,SH,BLACKFIN,ARM]
                         earlyprintk=vga
+                        earlyprintk=efi
                         earlyprintk=xen
                         earlyprintk=serial[,ttySn[,baudrate]]
                         earlyprintk=serial[,0x...[,baudrate]]
@@ -856,7 +861,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Append ",keep" to not disable it when the real console
                         takes over.
 
-                        Only vga or serial or usb debug port at a time.
+                        Only one of vga, efi, serial, or usb debug port can
+                        be used at a time.
 
                         Currently only ttyS0 and ttyS1 may be specified by
                         name.  Other I/O ports may be explicitly specified
@@ -870,8 +876,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Interaction with the standard serial driver is not
                         very good.
 
-                        The VGA output is eventually overwritten by the real
-                        console.
+                        The VGA and EFI output is eventually overwritten by
+                        the real console.
 
                         The xen output can only be used by Xen PV guests.
 
@@ -1064,6 +1070,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                 VIA, nVidia)
                         verbose: show contents of HPET registers during setup
 
+        hpet_mmap=      [X86, HPET_MMAP] Allow userspace to mmap HPET
+                        registers.  Default set by CONFIG_HPET_MMAP_DEFAULT.
+
         hugepages=      [HW,X86-32,IA-64] HugeTLB pages to allocate at boot.
         hugepagesz=     [HW,IA-64,PPC,X86-64] The size of the HugeTLB pages.
                         On x86-64 and powerpc, this option can be specified
@@ -1181,15 +1190,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         owned by uid=0.
 
         ima_hash=       [IMA]
-                        Format: { "sha1" | "md5" }
+                        Format: { md5 | sha1 | rmd160 | sha256 | sha384
+                                   | sha512 | ... }
                         default: "sha1"
 
+                        The list of supported hash algorithms is defined
+                        in crypto/hash_info.h.
+
         ima_tcb         [IMA]
                         Load a policy which meets the needs of the Trusted
                         Computing Base.  This means IMA will measure all
                         programs exec'd, files mmap'd for exec, and all files
                         opened for read by uid=0.
 
+        ima_template=   [IMA]
+                        Select one of defined IMA measurements template formats.
+                        Formats: { "ima" | "ima-ng" }
+                        Default: "ima-ng"
+
         init=           [KNL]
                         Format: <full_path>
                         Run specified binary instead of /sbin/init as init
@@ -1357,7 +1375,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         pages. In the event, a node is too small to have both
                         kernelcore and Movable pages, kernelcore pages will
                         take priority and other nodes will have a larger number
-                        of kernelcore pages.  The Movable zone is used for the
+                        of Movable pages.  The Movable zone is used for the
                         allocation of pages that may be reclaimed or moved
                         by the page migration subsystem.  This means that
                         HugeTLB pages may not be allocated from this zone.
@@ -1769,6 +1787,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         that the amount of memory usable for all allocations
                         is not too small.
 
+        movable_node    [KNL,X86] Boot-time switch to enable the effects
+                        of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details.
+
         MTD_Partition=  [MTD]
                         Format: <name>,<region-number>,<size>,<offset>
 
@@ -2595,7 +2616,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         ramdisk_size=   [RAM] Sizes of RAM disks in kilobytes
                         See Documentation/blockdev/ramdisk.txt.
 
-        rcu_nocbs=      [KNL,BOOT]
+        rcu_nocbs=      [KNL]
                         In kernels built with CONFIG_RCU_NOCB_CPU=y, set
                         the specified list of CPUs to be no-callback CPUs.
                         Invocation of these CPUs' RCU callbacks will
@@ -2608,7 +2629,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         real-time workloads.  It can also improve energy
                         efficiency for asymmetric multiprocessors.
 
-        rcu_nocb_poll   [KNL,BOOT]
+        rcu_nocb_poll   [KNL]
                         Rather than requiring that offloaded CPUs
                         (specified by rcu_nocbs= above) explicitly
                         awaken the corresponding "rcuoN" kthreads,
@@ -2619,126 +2640,145 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         energy efficiency by requiring that the kthreads
                         periodically wake up to do the polling.
 
-        rcutree.blimit= [KNL,BOOT]
+        rcutree.blimit= [KNL]
                         Set maximum number of finished RCU callbacks to process
                         in one batch.
 
-        rcutree.fanout_leaf=    [KNL,BOOT]
+        rcutree.rcu_fanout_leaf= [KNL]
                         Increase the number of CPUs assigned to each
                         leaf rcu_node structure.  Useful for very large
                         systems.
 
-        rcutree.jiffies_till_first_fqs= [KNL,BOOT]
+        rcutree.jiffies_till_first_fqs= [KNL]
                         Set delay from grace-period initialization to
                         first attempt to force quiescent states.
                         Units are jiffies, minimum value is zero,
                         and maximum value is HZ.
 
-        rcutree.jiffies_till_next_fqs= [KNL,BOOT]
+        rcutree.jiffies_till_next_fqs= [KNL]
                         Set delay between subsequent attempts to force
                         quiescent states.  Units are jiffies, minimum
                         value is one, and maximum value is HZ.
 
-        rcutree.qhimark=        [KNL,BOOT]
+        rcutree.qhimark= [KNL]
                         Set threshold of queued
                         RCU callbacks over which batch limiting is disabled.
 
-        rcutree.qlowmark=       [KNL,BOOT]
+        rcutree.qlowmark= [KNL]
                         Set threshold of queued RCU callbacks below which
                         batch limiting is re-enabled.
 
-        rcutree.rcu_cpu_stall_suppress= [KNL,BOOT]
-                        Suppress RCU CPU stall warning messages.
-
-        rcutree.rcu_cpu_stall_timeout= [KNL,BOOT]
-                        Set timeout for RCU CPU stall warning messages.
-
-        rcutree.rcu_idle_gp_delay=      [KNL,BOOT]
+        rcutree.rcu_idle_gp_delay= [KNL]
                         Set wakeup interval for idle CPUs that have
                         RCU callbacks (RCU_FAST_NO_HZ=y).
 
-        rcutree.rcu_idle_lazy_gp_delay= [KNL,BOOT]
+        rcutree.rcu_idle_lazy_gp_delay= [KNL]
                         Set wakeup interval for idle CPUs that have
                         only "lazy" RCU callbacks (RCU_FAST_NO_HZ=y).
                         Lazy RCU callbacks are those which RCU can
                         prove do nothing more than free memory.
 
-        rcutorture.fqs_duration= [KNL,BOOT]
+        rcutorture.fqs_duration= [KNL]
                         Set duration of force_quiescent_state bursts.
 
-        rcutorture.fqs_holdoff= [KNL,BOOT]
+        rcutorture.fqs_holdoff= [KNL]
                         Set holdoff time within force_quiescent_state bursts.
 
-        rcutorture.fqs_stutter= [KNL,BOOT]
+        rcutorture.fqs_stutter= [KNL]
                         Set wait time between force_quiescent_state bursts.
 
-        rcutorture.irqreader= [KNL,BOOT]
-                        Test RCU readers from irq handlers.
+        rcutorture.gp_exp= [KNL]
+                        Use expedited update-side primitives.
+
+        rcutorture.gp_normal= [KNL]
+                        Use normal (non-expedited) update-side primitives.
+                        If both gp_exp and gp_normal are set, do both.
+                        If neither gp_exp nor gp_normal are set, still
+                        do both.
 
-        rcutorture.n_barrier_cbs= [KNL,BOOT]
+        rcutorture.n_barrier_cbs= [KNL]
                         Set callbacks/threads for rcu_barrier() testing.
 
-        rcutorture.nfakewriters= [KNL,BOOT]
+        rcutorture.nfakewriters= [KNL]
                         Set number of concurrent RCU writers.  These just
                         stress RCU, they don't participate in the actual
                         test, hence the "fake".
 
-        rcutorture.nreaders= [KNL,BOOT]
+        rcutorture.nreaders= [KNL]
                         Set number of RCU readers.
 
-        rcutorture.onoff_holdoff= [KNL,BOOT]
+        rcutorture.object_debug= [KNL]
+                        Enable debug-object double-call_rcu() testing.
+
+        rcutorture.onoff_holdoff= [KNL]
                         Set time (s) after boot for CPU-hotplug testing.
 
-        rcutorture.onoff_interval= [KNL,BOOT]
+        rcutorture.onoff_interval= [KNL]
                         Set time (s) between CPU-hotplug operations, or
                         zero to disable CPU-hotplug testing.
 
-        rcutorture.shuffle_interval= [KNL,BOOT]
+        rcutorture.rcutorture_runnable= [BOOT]
+                        Start rcutorture running at boot time.
+
+        rcutorture.shuffle_interval= [KNL]
                         Set task-shuffle interval (s).  Shuffling tasks
                         allows some CPUs to go into dyntick-idle mode
                         during the rcutorture test.
 
-        rcutorture.shutdown_secs= [KNL,BOOT]
+        rcutorture.shutdown_secs= [KNL]
                         Set time (s) after boot system shutdown.  This
                         is useful for hands-off automated testing.
 
-        rcutorture.stall_cpu= [KNL,BOOT]
+        rcutorture.stall_cpu= [KNL]
                         Duration of CPU stall (s) to test RCU CPU stall
                         warnings, zero to disable.
 
-        rcutorture.stall_cpu_holdoff= [KNL,BOOT]
+        rcutorture.stall_cpu_holdoff= [KNL]
                         Time to wait (s) after boot before inducing stall.
 
-        rcutorture.stat_interval= [KNL,BOOT]
+        rcutorture.stat_interval= [KNL]
                         Time (s) between statistics printk()s.
 
-        rcutorture.stutter= [KNL,BOOT]
+        rcutorture.stutter= [KNL]
                         Time (s) to stutter testing, for example, specifying
                         five seconds causes the test to run for five seconds,
                         wait for five seconds, and so on.  This tests RCU's
                         ability to transition abruptly to and from idle.
 
-        rcutorture.test_boost= [KNL,BOOT]
+        rcutorture.test_boost= [KNL]
                         Test RCU priority boosting?  0=no, 1=maybe, 2=yes.
                         "Maybe" means test if the RCU implementation
                         under test support RCU priority boosting.
 
-        rcutorture.test_boost_duration= [KNL,BOOT]
+        rcutorture.test_boost_duration= [KNL]
                         Duration (s) of each individual boost test.
 
-        rcutorture.test_boost_interval= [KNL,BOOT]
+        rcutorture.test_boost_interval= [KNL]
                         Interval (s) between each boost test.
 
-        rcutorture.test_no_idle_hz= [KNL,BOOT]
+        rcutorture.test_no_idle_hz= [KNL]
                         Test RCU's dyntick-idle handling.  See also the
                         rcutorture.shuffle_interval parameter.
 
-        rcutorture.torture_type= [KNL,BOOT]
+        rcutorture.torture_type= [KNL]
                         Specify the RCU implementation to test.
 
-        rcutorture.verbose= [KNL,BOOT]
+        rcutorture.verbose= [KNL]
                         Enable additional printk() statements.
 
+        rcupdate.rcu_expedited= [KNL]
+                        Use expedited grace-period primitives, for
+                        example, synchronize_rcu_expedited() instead
+                        of synchronize_rcu().  This reduces latency,
+                        but can increase CPU utilization, degrade
+                        real-time latency, and degrade energy efficiency.
+
+        rcupdate.rcu_cpu_stall_suppress= [KNL]
+                        Suppress RCU CPU stall warning messages.
+
+        rcupdate.rcu_cpu_stall_timeout= [KNL]
+                        Set timeout for RCU CPU stall warning messages.
+
         rdinit=         [KNL]
                         Format: <full_path>
                         Run specified binary instead of /init from the ramdisk,
@@ -3467,11 +3507,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         default x2apic cluster mode on platforms
                         supporting x2apic.
 
-        x86_mrst_timer= [X86-32,APBT]
-                        Choose timer option for x86 Moorestown MID platform.
+        x86_intel_mid_timer= [X86-32,APBT]
+                        Choose timer option for x86 Intel MID platform.
                         Two valid options are apbt timer only and lapic timer
                         plus one apbt timer for broadcast timer.
-                        x86_mrst_timer=apbt_only | lapic_and_apbt
+                        x86_intel_mid_timer=apbt_only | lapic_and_apbt
 
         xen_emul_unplug=                [HW,X86,XEN]
                         Unplug Xen emulated devices
diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
index 32351bfabf20..827104fb9364 100644
--- a/Documentation/kernel-per-CPU-kthreads.txt
+++ b/Documentation/kernel-per-CPU-kthreads.txt
@@ -181,12 +181,17 @@ To reduce its OS jitter, do any of the following:
                 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().
+                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(),
+                but if your workload is CPU-bound, this is a bad idea.
+                However, there is an RFC patch from Christoph Lameter
+                (based on an earlier one from Gilad Ben-Yossef) that
+                reduces or even eliminates vmstat overhead for some
+                workloads at https://lkml.org/lkml/2013/9/4/379.
         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.
diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt
index 86c52360ffe7..fc04c14de4bb 100644
--- a/Documentation/laptops/thinkpad-acpi.txt
+++ b/Documentation/laptops/thinkpad-acpi.txt
@@ -1,7 +1,7 @@
                      ThinkPad ACPI Extras Driver
 
-                            Version 0.24
-                        December 11th,  2009
+                            Version 0.25
+                        October 16th,  2013
 
                Borislav Deianov <borislav@users.sf.net>
              Henrique de Moraes Holschuh <hmh@hmh.eng.br>
@@ -741,6 +741,9 @@ compiled with the CONFIG_THINKPAD_ACPI_UNSAFE_LEDS option enabled.
 Distributions must never enable this option.  Individual users that
 are aware of the consequences are welcome to enabling it.
 
+Audio mute and microphone mute LEDs are supported, but currently not
+visible to userspace. They are used by the snd-hda-intel audio driver.
+
 procfs notes:
 
 The available commands are:
diff --git a/Documentation/lockstat.txt b/Documentation/lockstat.txt
index dd2f7b26ca30..72d010689751 100644
--- a/Documentation/lockstat.txt
+++ b/Documentation/lockstat.txt
@@ -46,16 +46,14 @@ With these hooks we provide the following statistics:
  contentions       - number of lock acquisitions that had to wait
  wait time min     - shortest (non-0) time we ever had to wait for a lock
            max     - longest time we ever had to wait for a lock
-           total   - total time we spend waiting on this lock
+           total   - total time we spend waiting on this lock
+           avg     - average time spent waiting on this lock
  acq-bounces       - number of lock acquisitions that involved x-cpu data
  acquisitions      - number of times we took the lock
  hold time min     - shortest (non-0) time we ever held the lock
-           max     - longest time we ever held the lock
-           total   - total time this lock was held
-
-From these number various other statistics can be derived, such as:
-
- hold time average = hold time total / acquisitions
+           max     - longest time we ever held the lock
+           total   - total time this lock was held
+           avg     - average time this lock was held
 
 These numbers are gathered per lock class, per read/write state (when
 applicable).
@@ -84,37 +82,38 @@ Look at the current lock statistics:
 
 # less /proc/lock_stat
 
-01 lock_stat version 0.3
-02 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-03                               class name    con-bounces    contentions   waittime-min   waittime-max waittime-total    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total
-04 -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+01 lock_stat version 0.4
+02-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+03                              class name    con-bounces    contentions   waittime-min   waittime-max waittime-total   waittime-avg    acq-bounces   acquisitions   holdtime-min   holdtime-max holdtime-total   holdtime-avg
+04-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 05
-06                          &mm->mmap_sem-W:           233            538 18446744073708       22924.27      607243.51           1342          45806           1.71        8595.89     1180582.34
-07                          &mm->mmap_sem-R:           205            587 18446744073708       28403.36      731975.00           1940         412426           0.58      187825.45     6307502.88
-08                          ---------------
-09                            &mm->mmap_sem            487          [<ffffffff8053491f>] do_page_fault+0x466/0x928
-10                            &mm->mmap_sem            179          [<ffffffff802a6200>] sys_mprotect+0xcd/0x21d
-11                            &mm->mmap_sem            279          [<ffffffff80210a57>] sys_mmap+0x75/0xce
-12                            &mm->mmap_sem             76          [<ffffffff802a490b>] sys_munmap+0x32/0x59
-13                          ---------------
-14                            &mm->mmap_sem            270          [<ffffffff80210a57>] sys_mmap+0x75/0xce
-15                            &mm->mmap_sem            431          [<ffffffff8053491f>] do_page_fault+0x466/0x928
-16                            &mm->mmap_sem            138          [<ffffffff802a490b>] sys_munmap+0x32/0x59
-17                            &mm->mmap_sem            145          [<ffffffff802a6200>] sys_mprotect+0xcd/0x21d
+06                         &mm->mmap_sem-W:            46             84           0.26         939.10       16371.53         194.90          47291        2922365           0.16     2220301.69 17464026916.32        5975.99
+07                         &mm->mmap_sem-R:            37            100           1.31      299502.61      325629.52        3256.30         212344       34316685           0.10        7744.91    95016910.20           2.77
+08                         ---------------
+09                           &mm->mmap_sem              1          [<ffffffff811502a7>] khugepaged_scan_mm_slot+0x57/0x280
+19                           &mm->mmap_sem             96          [<ffffffff815351c4>] __do_page_fault+0x1d4/0x510
+11                           &mm->mmap_sem             34          [<ffffffff81113d77>] vm_mmap_pgoff+0x87/0xd0
+12                           &mm->mmap_sem             17          [<ffffffff81127e71>] vm_munmap+0x41/0x80
+13                         ---------------
+14                           &mm->mmap_sem              1          [<ffffffff81046fda>] dup_mmap+0x2a/0x3f0
+15                           &mm->mmap_sem             60          [<ffffffff81129e29>] SyS_mprotect+0xe9/0x250
+16                           &mm->mmap_sem             41          [<ffffffff815351c4>] __do_page_fault+0x1d4/0x510
+17                           &mm->mmap_sem             68          [<ffffffff81113d77>] vm_mmap_pgoff+0x87/0xd0
 18
-19 ...............................................................................................................................................................................................
+19.............................................................................................................................................................................................................................
 20
-21                              dcache_lock:           621            623           0.52         118.26        1053.02           6745          91930           0.29         316.29      118423.41
-22                              -----------
-23                              dcache_lock            179          [<ffffffff80378274>] _atomic_dec_and_lock+0x34/0x54
-24                              dcache_lock            113          [<ffffffff802cc17b>] d_alloc+0x19a/0x1eb
-25                              dcache_lock             99          [<ffffffff802ca0dc>] d_rehash+0x1b/0x44
-26                              dcache_lock            104          [<ffffffff802cbca0>] d_instantiate+0x36/0x8a
-27                              -----------
-28                              dcache_lock            192          [<ffffffff80378274>] _atomic_dec_and_lock+0x34/0x54
-29                              dcache_lock             98          [<ffffffff802ca0dc>] d_rehash+0x1b/0x44
-30                              dcache_lock             72          [<ffffffff802cc17b>] d_alloc+0x19a/0x1eb
-31                              dcache_lock            112          [<ffffffff802cbca0>] d_instantiate+0x36/0x8a
+21                         unix_table_lock:           110            112           0.21          49.24         163.91           1.46          21094          66312           0.12         624.42       31589.81           0.48
+22                         ---------------
+23                         unix_table_lock             45          [<ffffffff8150ad8e>] unix_create1+0x16e/0x1b0
+24                         unix_table_lock             47          [<ffffffff8150b111>] unix_release_sock+0x31/0x250
+25                         unix_table_lock             15          [<ffffffff8150ca37>] unix_find_other+0x117/0x230
+26                         unix_table_lock              5          [<ffffffff8150a09f>] unix_autobind+0x11f/0x1b0
+27                         ---------------
+28                         unix_table_lock             39          [<ffffffff8150b111>] unix_release_sock+0x31/0x250
+29                         unix_table_lock             49          [<ffffffff8150ad8e>] unix_create1+0x16e/0x1b0
+30                         unix_table_lock             20          [<ffffffff8150ca37>] unix_find_other+0x117/0x230
+31                         unix_table_lock              4          [<ffffffff8150a09f>] unix_autobind+0x11f/0x1b0
+
 
 This excerpt shows the first two lock class statistics. Line 01 shows the
 output version - each time the format changes this will be updated. Line 02-04
@@ -131,30 +130,30 @@ The integer part of the time values is in us.
 
 Dealing with nested locks, subclasses may appear:
 
-32...............................................................................................................................................................................................
+32...........................................................................................................................................................................................................................
 33
-34                               &rq->lock:         13128          13128           0.43         190.53      103881.26          97454        3453404           0.00         401.11    13224683.11
+34                               &rq->lock:       13128          13128           0.43         190.53      103881.26           7.91          97454        3453404           0.00         401.11    13224683.11           3.82
 35                               ---------
-36                               &rq->lock            645          [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
-37                               &rq->lock            297          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
-38                               &rq->lock            360          [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a
-39                               &rq->lock            428          [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb
+36                               &rq->lock          645          [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
+37                               &rq->lock          297          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
+38                               &rq->lock          360          [<ffffffff8103c4c5>] select_task_rq_fair+0x1f0/0x74a
+39                               &rq->lock          428          [<ffffffff81045f98>] scheduler_tick+0x46/0x1fb
 40                               ---------
-41                               &rq->lock             77          [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
-42                               &rq->lock            174          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
-43                               &rq->lock           4715          [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
-44                               &rq->lock            893          [<ffffffff81340524>] schedule+0x157/0x7b8
+41                               &rq->lock           77          [<ffffffff8103bfc4>] task_rq_lock+0x43/0x75
+42                               &rq->lock          174          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
+43                               &rq->lock         4715          [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
+44                               &rq->lock          893          [<ffffffff81340524>] schedule+0x157/0x7b8
 45
-46...............................................................................................................................................................................................
+46...........................................................................................................................................................................................................................
 47
-48                             &rq->lock/1:         11526          11488           0.33         388.73      136294.31          21461          38404           0.00          37.93      109388.53
+48                             &rq->lock/1:        1526          11488           0.33         388.73      136294.31          11.86          21461          38404           0.00          37.93      109388.53           2.84
 49                             -----------
-50                             &rq->lock/1          11526          [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
+50                             &rq->lock/1        11526          [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
 51                             -----------
-52                             &rq->lock/1           5645          [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
-53                             &rq->lock/1           1224          [<ffffffff81340524>] schedule+0x157/0x7b8
-54                             &rq->lock/1           4336          [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
-55                             &rq->lock/1            181          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
+52                             &rq->lock/1         5645          [<ffffffff8103ed4b>] double_rq_lock+0x42/0x54
+53                             &rq->lock/1         1224          [<ffffffff81340524>] schedule+0x157/0x7b8
+54                             &rq->lock/1         4336          [<ffffffff8103ed58>] double_rq_lock+0x4f/0x54
+55                             &rq->lock/1          181          [<ffffffff8104ba65>] try_to_wake_up+0x127/0x25a
 
 Line 48 shows statistics for the second subclass (/1) of &rq->lock class
 (subclass starts from 0), since in this case, as line 50 suggests,
@@ -163,16 +162,16 @@ double_rq_lock actually acquires a nested lock of two spinlocks.
 View the top contending locks:
 
 # grep : /proc/lock_stat | head
-              &inode->i_data.tree_lock-W:            15          21657           0.18     1093295.30 11547131054.85             58          10415           0.16          87.51        6387.60
-              &inode->i_data.tree_lock-R:             0              0           0.00           0.00           0.00          23302         231198           0.25           8.45       98023.38
-                             dcache_lock:          1037           1161           0.38          45.32         774.51           6611         243371           0.15         306.48       77387.24
-                         &inode->i_mutex:           161            286 18446744073709       62882.54     1244614.55           3653          20598 18446744073709       62318.60     1693822.74
-                         &zone->lru_lock:            94             94           0.53           7.33          92.10           4366          32690           0.29          59.81       16350.06
-              &inode->i_data.i_mmap_mutex:            79             79           0.40           3.77          53.03          11779          87755           0.28         116.93       29898.44
-                        &q->__queue_lock:            48             50           0.52          31.62          86.31            774          13131           0.17         113.08       12277.52
-                        &rq->rq_lock_key:            43             47           0.74          68.50         170.63           3706          33929           0.22         107.99       17460.62
-                      &rq->rq_lock_key#2:            39             46           0.75           6.68          49.03           2979          32292           0.17         125.17       17137.63
-                         tasklist_lock-W:            15             15           1.45          10.87          32.70           1201           7390           0.58          62.55       13648.47
+                        clockevents_lock:       2926159        2947636           0.15       46882.81  1784540466.34         605.41        3381345        3879161           0.00        2260.97    53178395.68          13.71
+                     tick_broadcast_lock:        346460         346717           0.18        2257.43    39364622.71         113.54        3642919        4242696           0.00        2263.79    49173646.60          11.59
+                  &mapping->i_mmap_mutex:        203896         203899           3.36      645530.05 31767507988.39      155800.21        3361776        8893984           0.17        2254.15    14110121.02           1.59
+                               &rq->lock:        135014         136909           0.18         606.09      842160.68           6.15        1540728       10436146           0.00         728.72    17606683.41           1.69
+               &(&zone->lru_lock)->rlock:         93000          94934           0.16          59.18      188253.78           1.98        1199912        3809894           0.15         391.40     3559518.81           0.93
+                         tasklist_lock-W:         40667          41130           0.23        1189.42      428980.51          10.43         270278         510106           0.16         653.51     3939674.91           7.72
+                         tasklist_lock-R:         21298          21305           0.20        1310.05      215511.12          10.12         186204         241258           0.14        1162.33     1179779.23           4.89
+                              rcu_node_1:         47656          49022           0.16         635.41      193616.41           3.95         844888        1865423           0.00         764.26     1656226.96           0.89
+       &(&dentry->d_lockref.lock)->rlock:         39791          40179           0.15        1302.08       88851.96           2.21        2790851       12527025           0.10        1910.75     3379714.27           0.27
+                              rcu_node_0:         29203          30064           0.16         786.55     1555573.00          51.74          88963         244254           0.00         398.87      428872.51           1.76
 
 Clear the statistics:
 
diff --git a/Documentation/mic/mic_overview.txt b/Documentation/mic/mic_overview.txt
new file mode 100644
index 000000000000..b41929224804
--- /dev/null
+++ b/Documentation/mic/mic_overview.txt
@@ -0,0 +1,51 @@
+An Intel MIC X100 device is a PCIe form factor add-in coprocessor
+card based on the Intel Many Integrated Core (MIC) architecture
+that runs a Linux OS. It is a PCIe endpoint in a platform and therefore
+implements the three required standard address spaces i.e. configuration,
+memory and I/O. The host OS loads a device driver as is typical for
+PCIe devices. The card itself runs a bootstrap after reset that
+transfers control to the card OS downloaded from the host driver. The
+host driver supports OSPM suspend and resume operations. It shuts down
+the card during suspend and reboots the card OS during resume.
+The card OS as shipped by Intel is a Linux kernel with modifications
+for the X100 devices.
+
+Since it is a PCIe card, it does not have the ability to host hardware
+devices for networking, storage and console. We provide these devices
+on X100 coprocessors thus enabling a self-bootable equivalent environment
+for applications. A key benefit of our solution is that it leverages
+the standard virtio framework for network, disk and console devices,
+though in our case the virtio framework is used across a PCIe bus.
+
+Here is a block diagram of the various components described above. The
+virtio backends are situated on the host rather than the card given better
+single threaded performance for the host compared to MIC, the ability of
+the host to initiate DMA's to/from the card using the MIC DMA engine and
+the fact that the virtio block storage backend can only be on the host.
+
+                              |
+       +----------+           |             +----------+
+       | Card OS  |           |             | Host OS  |
+       +----------+           |             +----------+
+                              |
++-------+ +--------+ +------+ | +---------+  +--------+ +--------+
+| Virtio| |Virtio  | |Virtio| | |Virtio   |  |Virtio  | |Virtio  |
+| Net   | |Console | |Block | | |Net      |  |Console | |Block   |
+| Driver| |Driver  | |Driver| | |backend  |  |backend | |backend |
++-------+ +--------+ +------+ | +---------+  +--------+ +--------+
+    |         |         |     |      |            |         |
+    |         |         |     |User  |            |         |
+    |         |         |     |------|------------|---------|-------
+    +-------------------+     |Kernel +--------------------------+
+              |               |       | Virtio over PCIe IOCTLs  |
+              |               |       +--------------------------+
+      +--------------+        |                   |
+      |Intel MIC     |        |            +---------------+
+      |Card Driver   |        |            |Intel MIC      |
+      +--------------+        |            |Host Driver    |
+              |               |            +---------------+
+              |               |                   |
+     +-------------------------------------------------------------+
+     |                                                             |
+     |                    PCIe Bus                                 |
+     +-------------------------------------------------------------+
diff --git a/Documentation/mic/mpssd/.gitignore b/Documentation/mic/mpssd/.gitignore
new file mode 100644
index 000000000000..8b7c72f07c92
--- /dev/null
+++ b/Documentation/mic/mpssd/.gitignore
@@ -0,0 +1 @@
+mpssd
diff --git a/Documentation/mic/mpssd/Makefile b/Documentation/mic/mpssd/Makefile
new file mode 100644
index 000000000000..eb860a7d152e
--- /dev/null
+++ b/Documentation/mic/mpssd/Makefile
@@ -0,0 +1,19 @@
+#
+# Makefile - Intel MIC User Space Tools.
+# Copyright(c) 2013, Intel Corporation.
+#
+ifdef DEBUG
+CFLAGS += $(USERWARNFLAGS) -I. -g -Wall -DDEBUG=$(DEBUG)
+else
+CFLAGS += $(USERWARNFLAGS) -I. -g -Wall
+endif
+
+mpssd: mpssd.o sysfs.o
+        $(CC) $(CFLAGS) -o $@ $^ -lpthread
+
+install:
+        install mpssd /usr/sbin/mpssd
+        install micctrl /usr/sbin/micctrl
+
+clean:
+        rm -f mpssd *.o
diff --git a/Documentation/mic/mpssd/micctrl b/Documentation/mic/mpssd/micctrl
new file mode 100755
index 000000000000..8f2629b41c5f
--- /dev/null
+++ b/Documentation/mic/mpssd/micctrl
@@ -0,0 +1,173 @@
+#!/bin/bash
+# Intel MIC Platform Software Stack (MPSS)
+#
+# Copyright(c) 2013 Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License, version 2, as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# The full GNU General Public License is included in this distribution in
+# the file called "COPYING".
+#
+# Intel MIC User Space Tools.
+#
+# micctrl - Controls MIC boot/start/stop.
+#
+# chkconfig: 2345 95 05
+# description: start MPSS stack processing.
+#
+### BEGIN INIT INFO
+# Provides: micctrl
+### END INIT INFO
+
+# Source function library.
+. /etc/init.d/functions
+
+sysfs="/sys/class/mic"
+
+_status()
+{
+        f=$sysfs/$1
+        echo -e $1 state: "`cat $f/state`" shutdown_status: "`cat $f/shutdown_status`"
+}
+
+status()
+{
+        if [ "`echo $1 | head -c3`" == "mic" ]; then
+                _status $1
+                return $?
+        fi
+        for f in $sysfs/*
+        do
+                _status `basename $f`
+                RETVAL=$?
+                [ $RETVAL -ne 0 ] && return $RETVAL
+        done
+        return 0
+}
+
+_reset()
+{
+        f=$sysfs/$1
+        echo reset > $f/state
+}
+
+reset()
+{
+        if [ "`echo $1 | head -c3`" == "mic" ]; then
+                _reset $1
+                return $?
+        fi
+        for f in $sysfs/*
+        do
+                _reset `basename $f`
+                RETVAL=$?
+                [ $RETVAL -ne 0 ] && return $RETVAL
+        done
+        return 0
+}
+
+_boot()
+{
+        f=$sysfs/$1
+        echo "linux" > $f/bootmode
+        echo "mic/uos.img" > $f/firmware
+        echo "mic/$1.image" > $f/ramdisk
+        echo "boot" > $f/state
+}
+
+boot()
+{
+        if [ "`echo $1 | head -c3`" == "mic" ]; then
+                _boot $1
+                return $?
+        fi
+        for f in $sysfs/*
+        do
+                _boot `basename $f`
+                RETVAL=$?
+                [ $RETVAL -ne 0 ] && return $RETVAL
+        done
+        return 0
+}
+
+_shutdown()
+{
+        f=$sysfs/$1
+        echo shutdown > $f/state
+}
+
+shutdown()
+{
+        if [ "`echo $1 | head -c3`" == "mic" ]; then
+                _shutdown $1
+                return $?
+        fi
+        for f in $sysfs/*
+        do
+                _shutdown `basename $f`
+                RETVAL=$?
+                [ $RETVAL -ne 0 ] && return $RETVAL
+        done
+        return 0
+}
+
+_wait()
+{
+        f=$sysfs/$1
+        while [ "`cat $f/state`" != "offline" -a "`cat $f/state`" != "online" ]
+        do
+                sleep 1
+                echo -e "Waiting for $1 to go offline"
+        done
+}
+
+wait()
+{
+        if [ "`echo $1 | head -c3`" == "mic" ]; then
+                _wait $1
+                return $?
+        fi
+        # Wait for the cards to go offline
+        for f in $sysfs/*
+        do
+                _wait `basename $f`
+                RETVAL=$?
+                [ $RETVAL -ne 0 ] && return $RETVAL
+        done
+        return 0
+}
+
+if [ ! -d "$sysfs" ]; then
+        echo -e $"Module unloaded "
+        exit 3
+fi
+
+case $1 in
+        -s)
+                status $2
+                ;;
+        -r)
+                reset $2
+                ;;
+        -b)
+                boot $2
+                ;;
+        -S)
+                shutdown $2
+                ;;
+        -w)
+                wait $2
+                ;;
+        *)
+                echo $"Usage: $0 {-s (status) |-r (reset) |-b (boot) |-S (shutdown) |-w (wait)}"
+                exit 2
+esac
+
+exit $?
diff --git a/Documentation/mic/mpssd/mpss b/Documentation/mic/mpssd/mpss
new file mode 100755
index 000000000000..3136c68dad0b
--- /dev/null
+++ b/Documentation/mic/mpssd/mpss
@@ -0,0 +1,202 @@
+#!/bin/bash
+# Intel MIC Platform Software Stack (MPSS)
+#
+# Copyright(c) 2013 Intel Corporation.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License, version 2, as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+# General Public License for more details.
+#
+# The full GNU General Public License is included in this distribution in
+# the file called "COPYING".
+#
+# Intel MIC User Space Tools.
+#
+# mpss  Start mpssd.
+#
+# chkconfig: 2345 95 05
+# description: start MPSS stack processing.
+#
+### BEGIN INIT INFO
+# Provides: mpss
+# Required-Start:
+# Required-Stop:
+# Short-Description: MPSS stack control
+# Description: MPSS stack control
+### END INIT INFO
+
+# Source function library.
+. /etc/init.d/functions
+
+exec=/usr/sbin/mpssd
+sysfs="/sys/class/mic"
+
+start()
+{
+        [ -x $exec ] || exit 5
+
+        if [ "`ps -e | awk '{print $4}' | grep mpssd | head -1`" = "mpssd" ]; then
+                echo -e $"MPSSD already running! "
+                success
+                echo
+                return 0
+        fi
+
+        echo -e $"Starting MPSS Stack"
+        echo -e $"Loading MIC_HOST Module"
+
+        # Ensure the driver is loaded
+        if [ ! -d "$sysfs" ]; then
+                modprobe mic_host
+                RETVAL=$?
+                if [ $RETVAL -ne 0 ]; then
+                        failure
+                        echo
+                        return $RETVAL
+                fi
+        fi
+
+        # Start the daemon
+        echo -n $"Starting MPSSD "
+        $exec
+        RETVAL=$?
+        if [ $RETVAL -ne 0 ]; then
+                failure
+                echo
+                return $RETVAL
+        fi
+        success
+        echo
+
+        sleep 5
+
+        # Boot the cards
+        micctrl -b
+
+        # Wait till ping works
+        for f in $sysfs/*
+        do
+                count=100
+                ipaddr=`cat $f/cmdline`
+                ipaddr=${ipaddr#*address,}
+                ipaddr=`echo $ipaddr | cut -d, -f1 | cut -d\; -f1`
+                while [ $count -ge 0 ]
+                do
+                        echo -e "Pinging "`basename $f`" "
+                        ping -c 1 $ipaddr &> /dev/null
+                        RETVAL=$?
+                        if [ $RETVAL -eq 0 ]; then
+                                success
+                                break
+                        fi
+                        sleep 1
+                        count=`expr $count - 1`
+                done
+                [ $RETVAL -ne 0 ] && failure || success
+                echo
+        done
+        return $RETVAL
+}
+
+stop()
+{
+        echo -e $"Shutting down MPSS Stack: "
+
+        # Bail out if module is unloaded
+        if [ ! -d "$sysfs" ]; then
+                echo -n $"Module unloaded "
+                success
+                echo
+                return 0
+        fi
+
+        # Shut down the cards.
+        micctrl -S
+
+        # Wait for the cards to go offline
+        for f in $sysfs/*
+        do
+                while [ "`cat $f/state`" != "offline" ]
+                do
+                        sleep 1
+                        echo -e "Waiting for "`basename $f`" to go offline"
+                done
+        done
+
+        # Display the status of the cards
+        micctrl -s
+
+        # Kill MPSSD now
+        echo -n $"Killing MPSSD"
+        killall -9 mpssd 2>/dev/null
+        RETVAL=$?
+        [ $RETVAL -ne 0 ] && failure || success
+        echo
+        return $RETVAL
+}
+
+restart()
+{
+        stop
+        sleep 5
+        start
+}
+
+status()
+{
+        micctrl -s
+        if [ "`ps -e | awk '{print $4}' | grep mpssd | head -n 1`" = "mpssd" ]; then
+                echo "mpssd is running"
+        else
+                echo "mpssd is stopped"
+        fi
+        return 0
+}
+
+unload()
+{
+        if [ ! -d "$sysfs" ]; then
+                echo -n $"No MIC_HOST Module: "
+                success
+                echo
+                return
+        fi
+
+        stop
+
+        sleep 5
+        echo -n $"Removing MIC_HOST Module: "
+        modprobe -r mic_host
+        RETVAL=$?
+        [ $RETVAL -ne 0 ] && failure || success
+        echo
+        return $RETVAL
+}
+
+case $1 in
+        start)
+                start
+                ;;
+        stop)
+                stop
+                ;;
+        restart)
+                restart
+                ;;
+        status)
+                status
+                ;;
+        unload)
+                unload
+                ;;
+        *)
+                echo $"Usage: $0 {start|stop|restart|status|unload}"
+                exit 2
+esac
+
+exit $?
diff --git a/Documentation/mic/mpssd/mpssd.c b/Documentation/mic/mpssd/mpssd.c
new file mode 100644
index 000000000000..0c980ad40b17
--- /dev/null
+++ b/Documentation/mic/mpssd/mpssd.c
@@ -0,0 +1,1721 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2013 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel MIC User Space Tools.
+ */
+
+#define _GNU_SOURCE
+
+#include <stdlib.h>
+#include <fcntl.h>
+#include <getopt.h>
+#include <assert.h>
+#include <unistd.h>
+#include <stdbool.h>
+#include <signal.h>
+#include <poll.h>
+#include <features.h>
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <sys/mman.h>
+#include <sys/socket.h>
+#include <linux/virtio_ring.h>
+#include <linux/virtio_net.h>
+#include <linux/virtio_console.h>
+#include <linux/virtio_blk.h>
+#include <linux/version.h>
+#include "mpssd.h"
+#include <linux/mic_ioctl.h>
+#include <linux/mic_common.h>
+
+static void init_mic(struct mic_info *mic);
+
+static FILE *logfp;
+static struct mic_info mic_list;
+
+#define ARRAY_SIZE(x) (sizeof(x) / sizeof((x)[0]))
+
+#define min_t(type, x, y) ({                            \
+                type __min1 = (x);                      \
+                type __min2 = (y);                      \
+                __min1 < __min2 ? __min1 : __min2; })
+
+/* align addr on a size boundary - adjust address up/down if needed */
+#define _ALIGN_DOWN(addr, size)  ((addr)&(~((size)-1)))
+#define _ALIGN_UP(addr, size)    _ALIGN_DOWN(addr + size - 1, size)
+
+/* align addr on a size boundary - adjust address up if needed */
+#define _ALIGN(addr, size)     _ALIGN_UP(addr, size)
+
+/* to align the pointer to the (next) page boundary */
+#define PAGE_ALIGN(addr)        _ALIGN(addr, PAGE_SIZE)
+
+#define ACCESS_ONCE(x) (*(volatile typeof(x) *)&(x))
+
+#define GSO_ENABLED             1
+#define MAX_GSO_SIZE            (64 * 1024)
+#define ETH_H_LEN               14
+#define MAX_NET_PKT_SIZE        (_ALIGN_UP(MAX_GSO_SIZE + ETH_H_LEN, 64))
+#define MIC_DEVICE_PAGE_END     0x1000
+
+#ifndef VIRTIO_NET_HDR_F_DATA_VALID
+#define VIRTIO_NET_HDR_F_DATA_VALID     2       /* Csum is valid */
+#endif
+
+static struct {
+        struct mic_device_desc dd;
+        struct mic_vqconfig vqconfig[2];
+        __u32 host_features, guest_acknowledgements;
+        struct virtio_console_config cons_config;
+} virtcons_dev_page = {
+        .dd = {
+                .type = VIRTIO_ID_CONSOLE,
+                .num_vq = ARRAY_SIZE(virtcons_dev_page.vqconfig),
+                .feature_len = sizeof(virtcons_dev_page.host_features),
+                .config_len = sizeof(virtcons_dev_page.cons_config),
+        },
+        .vqconfig[0] = {
+                .num = htole16(MIC_VRING_ENTRIES),
+        },
+        .vqconfig[1] = {
+                .num = htole16(MIC_VRING_ENTRIES),
+        },
+};
+
+static struct {
+        struct mic_device_desc dd;
+        struct mic_vqconfig vqconfig[2];
+        __u32 host_features, guest_acknowledgements;
+        struct virtio_net_config net_config;
+} virtnet_dev_page = {
+        .dd = {
+                .type = VIRTIO_ID_NET,
+                .num_vq = ARRAY_SIZE(virtnet_dev_page.vqconfig),
+                .feature_len = sizeof(virtnet_dev_page.host_features),
+                .config_len = sizeof(virtnet_dev_page.net_config),
+        },
+        .vqconfig[0] = {
+                .num = htole16(MIC_VRING_ENTRIES),
+        },
+        .vqconfig[1] = {
+                .num = htole16(MIC_VRING_ENTRIES),
+        },
+#if GSO_ENABLED
+                .host_features = htole32(
+                1 << VIRTIO_NET_F_CSUM |
+                1 << VIRTIO_NET_F_GSO |
+                1 << VIRTIO_NET_F_GUEST_TSO4 |
+                1 << VIRTIO_NET_F_GUEST_TSO6 |
+                1 << VIRTIO_NET_F_GUEST_ECN |
+                1 << VIRTIO_NET_F_GUEST_UFO),
+#else
+                .host_features = 0,
+#endif
+};
+
+static const char *mic_config_dir = "/etc/sysconfig/mic";
+static const char *virtblk_backend = "VIRTBLK_BACKEND";
+static struct {
+        struct mic_device_desc dd;
+        struct mic_vqconfig vqconfig[1];
+        __u32 host_features, guest_acknowledgements;
+        struct virtio_blk_config blk_config;
+} virtblk_dev_page = {
+        .dd = {
+                .type = VIRTIO_ID_BLOCK,
+                .num_vq = ARRAY_SIZE(virtblk_dev_page.vqconfig),
+                .feature_len = sizeof(virtblk_dev_page.host_features),
+                .config_len = sizeof(virtblk_dev_page.blk_config),
+        },
+        .vqconfig[0] = {
+                .num = htole16(MIC_VRING_ENTRIES),
+        },
+        .host_features =
+                htole32(1<<VIRTIO_BLK_F_SEG_MAX),
+        .blk_config = {
+                .seg_max = htole32(MIC_VRING_ENTRIES - 2),
+                .capacity = htole64(0),
+         }
+};
+
+static char *myname;
+
+static int
+tap_configure(struct mic_info *mic, char *dev)
+{
+        pid_t pid;
+        char *ifargv[7];
+        char ipaddr[IFNAMSIZ];
+        int ret = 0;
+
+        pid = fork();
+        if (pid == 0) {
+                ifargv[0] = "ip";
+                ifargv[1] = "link";
+                ifargv[2] = "set";
+                ifargv[3] = dev;
+                ifargv[4] = "up";
+                ifargv[5] = NULL;
+                mpsslog("Configuring %s\n", dev);
+                ret = execvp("ip", ifargv);
+                if (ret < 0) {
+                        mpsslog("%s execvp failed errno %s\n",
+                                mic->name, strerror(errno));
+                        return ret;
+                }
+        }
+        if (pid < 0) {
+                mpsslog("%s fork failed errno %s\n",
+                        mic->name, strerror(errno));
+                return ret;
+        }
+
+        ret = waitpid(pid, NULL, 0);
+        if (ret < 0) {
+                mpsslog("%s waitpid failed errno %s\n",
+                        mic->name, strerror(errno));
+                return ret;
+        }
+
+        snprintf(ipaddr, IFNAMSIZ, "172.31.%d.254/24", mic->id);
+
+        pid = fork();
+        if (pid == 0) {
+                ifargv[0] = "ip";
+                ifargv[1] = "addr";
+                ifargv[2] = "add";
+                ifargv[3] = ipaddr;
+                ifargv[4] = "dev";
+                ifargv[5] = dev;
+                ifargv[6] = NULL;
+                mpsslog("Configuring %s ipaddr %s\n", dev, ipaddr);
+                ret = execvp("ip", ifargv);
+                if (ret < 0) {
+                        mpsslog("%s execvp failed errno %s\n",
+                                mic->name, strerror(errno));
+                        return ret;
+                }
+        }
+        if (pid < 0) {
+                mpsslog("%s fork failed errno %s\n",
+                        mic->name, strerror(errno));
+                return ret;
+        }
+
+        ret = waitpid(pid, NULL, 0);
+        if (ret < 0) {
+                mpsslog("%s waitpid failed errno %s\n",
+                        mic->name, strerror(errno));
+                return ret;
+        }
+        mpsslog("MIC name %s %s %d DONE!\n",
+                mic->name, __func__, __LINE__);
+        return 0;
+}
+
+static int tun_alloc(struct mic_info *mic, char *dev)
+{
+        struct ifreq ifr;
+        int fd, err;
+#if GSO_ENABLED
+        unsigned offload;
+#endif
+        fd = open("/dev/net/tun", O_RDWR);
+        if (fd < 0) {
+                mpsslog("Could not open /dev/net/tun %s\n", strerror(errno));
+                goto done;
+        }
+
+        memset(&ifr, 0, sizeof(ifr));
+
+        ifr.ifr_flags = IFF_TAP | IFF_NO_PI | IFF_VNET_HDR;
+        if (*dev)
+                strncpy(ifr.ifr_name, dev, IFNAMSIZ);
+
+        err = ioctl(fd, TUNSETIFF, (void *)&ifr);
+        if (err < 0) {
+                mpsslog("%s %s %d TUNSETIFF failed %s\n",
+                        mic->name, __func__, __LINE__, strerror(errno));
+                close(fd);
+                return err;
+        }
+#if GSO_ENABLED
+        offload = TUN_F_CSUM | TUN_F_TSO4 | TUN_F_TSO6 |
+                TUN_F_TSO_ECN | TUN_F_UFO;
+
+        err = ioctl(fd, TUNSETOFFLOAD, offload);
+        if (err < 0) {
+                mpsslog("%s %s %d TUNSETOFFLOAD failed %s\n",
+                        mic->name, __func__, __LINE__, strerror(errno));
+                close(fd);
+                return err;
+        }
+#endif
+        strcpy(dev, ifr.ifr_name);
+        mpsslog("Created TAP %s\n", dev);
+done:
+        return fd;
+}
+
+#define NET_FD_VIRTIO_NET 0
+#define NET_FD_TUN 1
+#define MAX_NET_FD 2
+
+static void set_dp(struct mic_info *mic, int type, void *dp)
+{
+        switch (type) {
+        case VIRTIO_ID_CONSOLE:
+                mic->mic_console.console_dp = dp;
+                return;
+        case VIRTIO_ID_NET:
+                mic->mic_net.net_dp = dp;
+                return;
+        case VIRTIO_ID_BLOCK:
+                mic->mic_virtblk.block_dp = dp;
+                return;
+        }
+        mpsslog("%s %s %d not found\n", mic->name, __func__, type);
+        assert(0);
+}
+
+static void *get_dp(struct mic_info *mic, int type)
+{
+        switch (type) {
+        case VIRTIO_ID_CONSOLE:
+                return mic->mic_console.console_dp;
+        case VIRTIO_ID_NET:
+                return mic->mic_net.net_dp;
+        case VIRTIO_ID_BLOCK:
+                return mic->mic_virtblk.block_dp;
+        }
+        mpsslog("%s %s %d not found\n", mic->name, __func__, type);
+        assert(0);
+        return NULL;
+}
+
+static struct mic_device_desc *get_device_desc(struct mic_info *mic, int type)
+{
+        struct mic_device_desc *d;
+        int i;
+        void *dp = get_dp(mic, type);
+
+        for (i = mic_aligned_size(struct mic_bootparam); i < PAGE_SIZE;
+                i += mic_total_desc_size(d)) {
+                d = dp + i;
+
+                /* End of list */
+                if (d->type == 0)
+                        break;
+
+                if (d->type == -1)
+                        continue;
+
+                mpsslog("%s %s d-> type %d d %p\n",
+                        mic->name, __func__, d->type, d);
+
+                if (d->type == (__u8)type)
+                        return d;
+        }
+        mpsslog("%s %s %d not found\n", mic->name, __func__, type);
+        assert(0);
+        return NULL;
+}
+
+/* See comments in vhost.c for explanation of next_desc() */
+static unsigned next_desc(struct vring_desc *desc)
+{
+        unsigned int next;
+
+        if (!(le16toh(desc->flags) & VRING_DESC_F_NEXT))
+                return -1U;
+        next = le16toh(desc->next);
+        return next;
+}
+
+/* Sum up all the IOVEC length */
+static ssize_t
+sum_iovec_len(struct mic_copy_desc *copy)
+{
+        ssize_t sum = 0;
+        int i;
+
+        for (i = 0; i < copy->iovcnt; i++)
+                sum += copy->iov[i].iov_len;
+        return sum;
+}
+
+static inline void verify_out_len(struct mic_info *mic,
+        struct mic_copy_desc *copy)
+{
+        if (copy->out_len != sum_iovec_len(copy)) {
+                mpsslog("%s %s %d BUG copy->out_len 0x%x len 0x%zx\n",
+                        mic->name, __func__, __LINE__,
+                        copy->out_len, sum_iovec_len(copy));
+                assert(copy->out_len == sum_iovec_len(copy));
+        }
+}
+
+/* Display an iovec */
+static void
+disp_iovec(struct mic_info *mic, struct mic_copy_desc *copy,
+           const char *s, int line)
+{
+        int i;
+
+        for (i = 0; i < copy->iovcnt; i++)
+                mpsslog("%s %s %d copy->iov[%d] addr %p len 0x%zx\n",
+                        mic->name, s, line, i,
+                        copy->iov[i].iov_base, copy->iov[i].iov_len);
+}
+
+static inline __u16 read_avail_idx(struct mic_vring *vr)
+{
+        return ACCESS_ONCE(vr->info->avail_idx);
+}
+
+static inline void txrx_prepare(int type, bool tx, struct mic_vring *vr,
+                                struct mic_copy_desc *copy, ssize_t len)
+{
+        copy->vr_idx = tx ? 0 : 1;
+        copy->update_used = true;
+        if (type == VIRTIO_ID_NET)
+                copy->iov[1].iov_len = len - sizeof(struct virtio_net_hdr);
+        else
+                copy->iov[0].iov_len = len;
+}
+
+/* Central API which triggers the copies */
+static int
+mic_virtio_copy(struct mic_info *mic, int fd,
+                struct mic_vring *vr, struct mic_copy_desc *copy)
+{
+        int ret;
+
+        ret = ioctl(fd, MIC_VIRTIO_COPY_DESC, copy);
+        if (ret) {
+                mpsslog("%s %s %d errno %s ret %d\n",
+                        mic->name, __func__, __LINE__,
+                        strerror(errno), ret);
+        }
+        return ret;
+}
+
+/*
+ * This initialization routine requires at least one
+ * vring i.e. vr0. vr1 is optional.
+ */
+static void *
+init_vr(struct mic_info *mic, int fd, int type,
+        struct mic_vring *vr0, struct mic_vring *vr1, int num_vq)
+{
+        int vr_size;
+        char *va;
+
+        vr_size = PAGE_ALIGN(vring_size(MIC_VRING_ENTRIES,
+                MIC_VIRTIO_RING_ALIGN) + sizeof(struct _mic_vring_info));
+        va = mmap(NULL, MIC_DEVICE_PAGE_END + vr_size * num_vq,
+                PROT_READ, MAP_SHARED, fd, 0);
+        if (MAP_FAILED == va) {
+                mpsslog("%s %s %d mmap failed errno %s\n",
+                        mic->name, __func__, __LINE__,
+                        strerror(errno));
+                goto done;
+        }
+        set_dp(mic, type, va);
+        vr0->va = (struct mic_vring *)&va[MIC_DEVICE_PAGE_END];
+        vr0->info = vr0->va +
+                vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN);
+        vring_init(&vr0->vr,
+                   MIC_VRING_ENTRIES, vr0->va, MIC_VIRTIO_RING_ALIGN);
+        mpsslog("%s %s vr0 %p vr0->info %p vr_size 0x%x vring 0x%x ",
+                __func__, mic->name, vr0->va, vr0->info, vr_size,
+                vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN));
+        mpsslog("magic 0x%x expected 0x%x\n",
+                vr0->info->magic, MIC_MAGIC + type);
+        assert(vr0->info->magic == MIC_MAGIC + type);
+        if (vr1) {
+                vr1->va = (struct mic_vring *)
+                        &va[MIC_DEVICE_PAGE_END + vr_size];
+                vr1->info = vr1->va + vring_size(MIC_VRING_ENTRIES,
+                        MIC_VIRTIO_RING_ALIGN);
+                vring_init(&vr1->vr,
+                           MIC_VRING_ENTRIES, vr1->va, MIC_VIRTIO_RING_ALIGN);
+                mpsslog("%s %s vr1 %p vr1->info %p vr_size 0x%x vring 0x%x ",
+                        __func__, mic->name, vr1->va, vr1->info, vr_size,
+                        vring_size(MIC_VRING_ENTRIES, MIC_VIRTIO_RING_ALIGN));
+                mpsslog("magic 0x%x expected 0x%x\n",
+                        vr1->info->magic, MIC_MAGIC + type + 1);
+                assert(vr1->info->magic == MIC_MAGIC + type + 1);
+        }
+done:
+        return va;
+}
+
+static void
+wait_for_card_driver(struct mic_info *mic, int fd, int type)
+{
+        struct pollfd pollfd;
+        int err;
+        struct mic_device_desc *desc = get_device_desc(mic, type);
+
+        pollfd.fd = fd;
+        mpsslog("%s %s Waiting .... desc-> type %d status 0x%x\n",
+                mic->name, __func__, type, desc->status);
+        while (1) {
+                pollfd.events = POLLIN;
+                pollfd.revents = 0;
+                err = poll(&pollfd, 1, -1);
+                if (err < 0) {
+                        mpsslog("%s %s poll failed %s\n",
+                                mic->name, __func__, strerror(errno));
+                        continue;
+                }
+
+                if (pollfd.revents) {
+                        mpsslog("%s %s Waiting... desc-> type %d status 0x%x\n",
+                                mic->name, __func__, type, desc->status);
+                        if (desc->status & VIRTIO_CONFIG_S_DRIVER_OK) {
+                                mpsslog("%s %s poll.revents %d\n",
+                                        mic->name, __func__, pollfd.revents);
+                                mpsslog("%s %s desc-> type %d status 0x%x\n",
+                                        mic->name, __func__, type,
+                                        desc->status);
+                                break;
+                        }
+                }
+        }
+}
+
+/* Spin till we have some descriptors */
+static void
+spin_for_descriptors(struct mic_info *mic, struct mic_vring *vr)
+{
+        __u16 avail_idx = read_avail_idx(vr);
+
+        while (avail_idx == le16toh(ACCESS_ONCE(vr->vr.avail->idx))) {
+#ifdef DEBUG
+                mpsslog("%s %s waiting for desc avail %d info_avail %d\n",
+                        mic->name, __func__,
+                        le16toh(vr->vr.avail->idx), vr->info->avail_idx);
+#endif
+                sched_yield();
+        }
+}
+
+static void *
+virtio_net(void *arg)
+{
+        static __u8 vnet_hdr[2][sizeof(struct virtio_net_hdr)];
+        static __u8 vnet_buf[2][MAX_NET_PKT_SIZE] __aligned(64);
+        struct iovec vnet_iov[2][2] = {
+                { { .iov_base = vnet_hdr[0], .iov_len = sizeof(vnet_hdr[0]) },
+                  { .iov_base = vnet_buf[0], .iov_len = sizeof(vnet_buf[0]) } },
+                { { .iov_base = vnet_hdr[1], .iov_len = sizeof(vnet_hdr[1]) },
+                  { .iov_base = vnet_buf[1], .iov_len = sizeof(vnet_buf[1]) } },
+        };
+        struct iovec *iov0 = vnet_iov[0], *iov1 = vnet_iov[1];
+        struct mic_info *mic = (struct mic_info *)arg;
+        char if_name[IFNAMSIZ];
+        struct pollfd net_poll[MAX_NET_FD];
+        struct mic_vring tx_vr, rx_vr;
+        struct mic_copy_desc copy;
+        struct mic_device_desc *desc;
+        int err;
+
+        snprintf(if_name, IFNAMSIZ, "mic%d", mic->id);
+        mic->mic_net.tap_fd = tun_alloc(mic, if_name);
+        if (mic->mic_net.tap_fd < 0)
+                goto done;
+
+        if (tap_configure(mic, if_name))
+                goto done;
+        mpsslog("MIC name %s id %d\n", mic->name, mic->id);
+
+        net_poll[NET_FD_VIRTIO_NET].fd = mic->mic_net.virtio_net_fd;
+        net_poll[NET_FD_VIRTIO_NET].events = POLLIN;
+        net_poll[NET_FD_TUN].fd = mic->mic_net.tap_fd;
+        net_poll[NET_FD_TUN].events = POLLIN;
+
+        if (MAP_FAILED == init_vr(mic, mic->mic_net.virtio_net_fd,
+                                  VIRTIO_ID_NET, &tx_vr, &rx_vr,
+                virtnet_dev_page.dd.num_vq)) {
+                mpsslog("%s init_vr failed %s\n",
+                        mic->name, strerror(errno));
+                goto done;
+        }
+
+        copy.iovcnt = 2;
+        desc = get_device_desc(mic, VIRTIO_ID_NET);
+
+        while (1) {
+                ssize_t len;
+
+                net_poll[NET_FD_VIRTIO_NET].revents = 0;
+                net_poll[NET_FD_TUN].revents = 0;
+
+                /* Start polling for data from tap and virtio net */
+                err = poll(net_poll, 2, -1);
+                if (err < 0) {
+                        mpsslog("%s poll failed %s\n",
+                                __func__, strerror(errno));
+                        continue;
+                }
+                if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK))
+                        wait_for_card_driver(mic, mic->mic_net.virtio_net_fd,
+                                             VIRTIO_ID_NET);
+                /*
+                 * Check if there is data to be read from TUN and write to
+                 * virtio net fd if there is.
+                 */
+                if (net_poll[NET_FD_TUN].revents & POLLIN) {
+                        copy.iov = iov0;
+                        len = readv(net_poll[NET_FD_TUN].fd,
+                                copy.iov, copy.iovcnt);
+                        if (len > 0) {
+                                struct virtio_net_hdr *hdr
+                                        = (struct virtio_net_hdr *)vnet_hdr[0];
+
+                                /* Disable checksums on the card since we are on
+                                   a reliable PCIe link */
+                                hdr->flags |= VIRTIO_NET_HDR_F_DATA_VALID;
+#ifdef DEBUG
+                                mpsslog("%s %s %d hdr->flags 0x%x ", mic->name,
+                                        __func__, __LINE__, hdr->flags);
+                                mpsslog("copy.out_len %d hdr->gso_type 0x%x\n",
+                                        copy.out_len, hdr->gso_type);
+#endif
+#ifdef DEBUG
+                                disp_iovec(mic, copy, __func__, __LINE__);
+                                mpsslog("%s %s %d read from tap 0x%lx\n",
+                                        mic->name, __func__, __LINE__,
+                                        len);
+#endif
+                                spin_for_descriptors(mic, &tx_vr);
+                                txrx_prepare(VIRTIO_ID_NET, 1, &tx_vr, &copy,
+                                             len);
+
+                                err = mic_virtio_copy(mic,
+                                        mic->mic_net.virtio_net_fd, &tx_vr,
+                                        &copy);
+                                if (err < 0) {
+                                        mpsslog("%s %s %d mic_virtio_copy %s\n",
+                                                mic->name, __func__, __LINE__,
+                                                strerror(errno));
+                                }
+                                if (!err)
+                                        verify_out_len(mic, &copy);
+#ifdef DEBUG
+                                disp_iovec(mic, copy, __func__, __LINE__);
+                                mpsslog("%s %s %d wrote to net 0x%lx\n",
+                                        mic->name, __func__, __LINE__,
+                                        sum_iovec_len(&copy));
+#endif
+                                /* Reinitialize IOV for next run */
+                                iov0[1].iov_len = MAX_NET_PKT_SIZE;
+                        } else if (len < 0) {
+                                disp_iovec(mic, &copy, __func__, __LINE__);
+                                mpsslog("%s %s %d read failed %s ", mic->name,
+                                        __func__, __LINE__, strerror(errno));
+                                mpsslog("cnt %d sum %zd\n",
+                                        copy.iovcnt, sum_iovec_len(&copy));
+                        }
+                }
+
+                /*
+                 * Check if there is data to be read from virtio net and
+                 * write to TUN if there is.
+                 */
+                if (net_poll[NET_FD_VIRTIO_NET].revents & POLLIN) {
+                        while (rx_vr.info->avail_idx !=
+                                le16toh(rx_vr.vr.avail->idx)) {
+                                copy.iov = iov1;
+                                txrx_prepare(VIRTIO_ID_NET, 0, &rx_vr, &copy,
+                                             MAX_NET_PKT_SIZE
+                                        + sizeof(struct virtio_net_hdr));
+
+                                err = mic_virtio_copy(mic,
+                                        mic->mic_net.virtio_net_fd, &rx_vr,
+                                        &copy);
+                                if (!err) {
+#ifdef DEBUG
+                                        struct virtio_net_hdr *hdr
+                                                = (struct virtio_net_hdr *)
+                                                        vnet_hdr[1];
+
+                                        mpsslog("%s %s %d hdr->flags 0x%x, ",
+                                                mic->name, __func__, __LINE__,
+                                                hdr->flags);
+                                        mpsslog("out_len %d gso_type 0x%x\n",
+                                                copy.out_len,
+                                                hdr->gso_type);
+#endif
+                                        /* Set the correct output iov_len */
+                                        iov1[1].iov_len = copy.out_len -
+                                                sizeof(struct virtio_net_hdr);
+                                        verify_out_len(mic, &copy);
+#ifdef DEBUG
+                                        disp_iovec(mic, copy, __func__,
+                                                   __LINE__);
+                                        mpsslog("%s %s %d ",
+                                                mic->name, __func__, __LINE__);
+                                        mpsslog("read from net 0x%lx\n",
+                                                sum_iovec_len(copy));
+#endif
+                                        len = writev(net_poll[NET_FD_TUN].fd,
+                                                copy.iov, copy.iovcnt);
+                                        if (len != sum_iovec_len(&copy)) {
+                                                mpsslog("Tun write failed %s ",
+                                                        strerror(errno));
+                                                mpsslog("len 0x%zx ", len);
+                                                mpsslog("read_len 0x%zx\n",
+                                                        sum_iovec_len(&copy));
+                                        } else {
+#ifdef DEBUG
+                                                disp_iovec(mic, &copy, __func__,
+                                                           __LINE__);
+                                                mpsslog("%s %s %d ",
+                                                        mic->name, __func__,
+                                                        __LINE__);
+                                                mpsslog("wrote to tap 0x%lx\n",
+                                                        len);
+#endif
+                                        }
+                                } else {
+                                        mpsslog("%s %s %d mic_virtio_copy %s\n",
+                                                mic->name, __func__, __LINE__,
+                                                strerror(errno));
+                                        break;
+                                }
+                        }
+                }
+                if (net_poll[NET_FD_VIRTIO_NET].revents & POLLERR)
+                        mpsslog("%s: %s: POLLERR\n", __func__, mic->name);
+        }
+done:
+        pthread_exit(NULL);
+}
+
+/* virtio_console */
+#define VIRTIO_CONSOLE_FD 0
+#define MONITOR_FD (VIRTIO_CONSOLE_FD + 1)
+#define MAX_CONSOLE_FD (MONITOR_FD + 1)  /* must be the last one + 1 */
+#define MAX_BUFFER_SIZE PAGE_SIZE
+
+static void *
+virtio_console(void *arg)
+{
+        static __u8 vcons_buf[2][PAGE_SIZE];
+        struct iovec vcons_iov[2] = {
+                { .iov_base = vcons_buf[0], .iov_len = sizeof(vcons_buf[0]) },
+                { .iov_base = vcons_buf[1], .iov_len = sizeof(vcons_buf[1]) },
+        };
+        struct iovec *iov0 = &vcons_iov[0], *iov1 = &vcons_iov[1];
+        struct mic_info *mic = (struct mic_info *)arg;
+        int err;
+        struct pollfd console_poll[MAX_CONSOLE_FD];
+        int pty_fd;
+        char *pts_name;
+        ssize_t len;
+        struct mic_vring tx_vr, rx_vr;
+        struct mic_copy_desc copy;
+        struct mic_device_desc *desc;
+
+        pty_fd = posix_openpt(O_RDWR);
+        if (pty_fd < 0) {
+                mpsslog("can't open a pseudoterminal master device: %s\n",
+                        strerror(errno));
+                goto _return;
+        }
+        pts_name = ptsname(pty_fd);
+        if (pts_name == NULL) {
+                mpsslog("can't get pts name\n");
+                goto _close_pty;
+        }
+        printf("%s console message goes to %s\n", mic->name, pts_name);
+        mpsslog("%s console message goes to %s\n", mic->name, pts_name);
+        err = grantpt(pty_fd);
+        if (err < 0) {
+                mpsslog("can't grant access: %s %s\n",
+                        pts_name, strerror(errno));
+                goto _close_pty;
+        }
+        err = unlockpt(pty_fd);
+        if (err < 0) {
+                mpsslog("can't unlock a pseudoterminal: %s %s\n",
+                        pts_name, strerror(errno));
+                goto _close_pty;
+        }
+        console_poll[MONITOR_FD].fd = pty_fd;
+        console_poll[MONITOR_FD].events = POLLIN;
+
+        console_poll[VIRTIO_CONSOLE_FD].fd = mic->mic_console.virtio_console_fd;
+        console_poll[VIRTIO_CONSOLE_FD].events = POLLIN;
+
+        if (MAP_FAILED == init_vr(mic, mic->mic_console.virtio_console_fd,
+                                  VIRTIO_ID_CONSOLE, &tx_vr, &rx_vr,
+                virtcons_dev_page.dd.num_vq)) {
+                mpsslog("%s init_vr failed %s\n",
+                        mic->name, strerror(errno));
+                goto _close_pty;
+        }
+
+        copy.iovcnt = 1;
+        desc = get_device_desc(mic, VIRTIO_ID_CONSOLE);
+
+        for (;;) {
+                console_poll[MONITOR_FD].revents = 0;
+                console_poll[VIRTIO_CONSOLE_FD].revents = 0;
+                err = poll(console_poll, MAX_CONSOLE_FD, -1);
+                if (err < 0) {
+                        mpsslog("%s %d: poll failed: %s\n", __func__, __LINE__,
+                                strerror(errno));
+                        continue;
+                }
+                if (!(desc->status & VIRTIO_CONFIG_S_DRIVER_OK))
+                        wait_for_card_driver(mic,
+                                             mic->mic_console.virtio_console_fd,
+                                VIRTIO_ID_CONSOLE);
+
+                if (console_poll[MONITOR_FD].revents & POLLIN) {
+                        copy.iov = iov0;
+                        len = readv(pty_fd, copy.iov, copy.iovcnt);
+                        if (len > 0) {
+#ifdef DEBUG
+                                disp_iovec(mic, copy, __func__, __LINE__);
+                                mpsslog("%s %s %d read from tap 0x%lx\n",
+                                        mic->name, __func__, __LINE__,
+                                        len);
+#endif
+                                spin_for_descriptors(mic, &tx_vr);
+                                txrx_prepare(VIRTIO_ID_CONSOLE, 1, &tx_vr,
+                                             &copy, len);
+
+                                err = mic_virtio_copy(mic,
+                                        mic->mic_console.virtio_console_fd,
+                                        &tx_vr, &copy);
+                                if (err < 0) {
+                                        mpsslog("%s %s %d mic_virtio_copy %s\n",
+                                                mic->name, __func__, __LINE__,
+                                                strerror(errno));
+                                }
+                                if (!err)
+                                        verify_out_len(mic, &copy);
+#ifdef DEBUG
+                                disp_iovec(mic, copy, __func__, __LINE__);
+                                mpsslog("%s %s %d wrote to net 0x%lx\n",
+                                        mic->name, __func__, __LINE__,
+                                        sum_iovec_len(copy));
+#endif
+                                /* Reinitialize IOV for next run */
+                                iov0->iov_len = PAGE_SIZE;
+                        } else if (len < 0) {
+                                disp_iovec(mic, &copy, __func__, __LINE__);
+                                mpsslog("%s %s %d read failed %s ",
+                                        mic->name, __func__, __LINE__,
+                                        strerror(errno));
+                                mpsslog("cnt %d sum %zd\n",
+                                        copy.iovcnt, sum_iovec_len(&copy));
+                        }
+                }
+
+                if (console_poll[VIRTIO_CONSOLE_FD].revents & POLLIN) {
+                        while (rx_vr.info->avail_idx !=
+                                le16toh(rx_vr.vr.avail->idx)) {
+                                copy.iov = iov1;
+                                txrx_prepare(VIRTIO_ID_CONSOLE, 0, &rx_vr,
+                                             &copy, PAGE_SIZE);
+
+                                err = mic_virtio_copy(mic,
+                                        mic->mic_console.virtio_console_fd,
+                                        &rx_vr, &copy);
+                                if (!err) {
+                                        /* Set the correct output iov_len */
+                                        iov1->iov_len = copy.out_len;
+                                        verify_out_len(mic, &copy);
+#ifdef DEBUG
+                                        disp_iovec(mic, copy, __func__,
+                                                   __LINE__);
+                                        mpsslog("%s %s %d ",
+                                                mic->name, __func__, __LINE__);
+                                        mpsslog("read from net 0x%lx\n",
+                                                sum_iovec_len(copy));
+#endif
+                                        len = writev(pty_fd,
+                                                copy.iov, copy.iovcnt);
+                                        if (len != sum_iovec_len(&copy)) {
+                                                mpsslog("Tun write failed %s ",
+                                                        strerror(errno));
+                                                mpsslog("len 0x%zx ", len);
+                                                mpsslog("read_len 0x%zx\n",
+                                                        sum_iovec_len(&copy));
+                                        } else {
+#ifdef DEBUG
+                                                disp_iovec(mic, copy, __func__,
+                                                           __LINE__);
+                                                mpsslog("%s %s %d ",
+                                                        mic->name, __func__,
+                                                        __LINE__);
+                                                mpsslog("wrote to tap 0x%lx\n",
+                                                        len);
+#endif
+                                        }
+                                } else {
+                                        mpsslog("%s %s %d mic_virtio_copy %s\n",
+                                                mic->name, __func__, __LINE__,
+                                                strerror(errno));
+                                        break;
+                                }
+                        }
+                }
+                if (console_poll[NET_FD_VIRTIO_NET].revents & POLLERR)
+                        mpsslog("%s: %s: POLLERR\n", __func__, mic->name);
+        }
+_close_pty:
+        close(pty_fd);
+_return:
+        pthread_exit(NULL);
+}
+
+static void
+add_virtio_device(struct mic_info *mic, struct mic_device_desc *dd)
+{
+        char path[PATH_MAX];
+        int fd, err;
+
+        snprintf(path, PATH_MAX, "/dev/mic%d", mic->id);
+        fd = open(path, O_RDWR);
+        if (fd < 0) {
+                mpsslog("Could not open %s %s\n", path, strerror(errno));
+                return;
+        }
+
+        err = ioctl(fd, MIC_VIRTIO_ADD_DEVICE, dd);
+        if (err < 0) {
+                mpsslog("Could not add %d %s\n", dd->type, strerror(errno));
+                close(fd);
+                return;
+        }
+        switch (dd->type) {
+        case VIRTIO_ID_NET:
+                mic->mic_net.virtio_net_fd = fd;
+                mpsslog("Added VIRTIO_ID_NET for %s\n", mic->name);
+                break;
+        case VIRTIO_ID_CONSOLE:
+                mic->mic_console.virtio_console_fd = fd;
+                mpsslog("Added VIRTIO_ID_CONSOLE for %s\n", mic->name);
+                break;
+        case VIRTIO_ID_BLOCK:
+                mic->mic_virtblk.virtio_block_fd = fd;
+                mpsslog("Added VIRTIO_ID_BLOCK for %s\n", mic->name);
+                break;
+        }
+}
+
+static bool
+set_backend_file(struct mic_info *mic)
+{
+        FILE *config;
+        char buff[PATH_MAX], *line, *evv, *p;
+
+        snprintf(buff, PATH_MAX, "%s/mpssd%03d.conf", mic_config_dir, mic->id);
+        config = fopen(buff, "r");
+        if (config == NULL)
+                return false;
+        do {  /* look for "virtblk_backend=XXXX" */
+                line = fgets(buff, PATH_MAX, config);
+                if (line == NULL)
+                        break;
+                if (*line == '#')
+                        continue;
+                p = strchr(line, '\n');
+                if (p)
+                        *p = '\0';
+        } while (strncmp(line, virtblk_backend, strlen(virtblk_backend)) != 0);
+        fclose(config);
+        if (line == NULL)
+                return false;
+        evv = strchr(line, '=');
+        if (evv == NULL)
+                return false;
+        mic->mic_virtblk.backend_file = malloc(strlen(evv) + 1);
+        if (mic->mic_virtblk.backend_file == NULL) {
+                mpsslog("%s %d can't allocate memory\n", mic->name, mic->id);
+                return false;
+        }
+        strcpy(mic->mic_virtblk.backend_file, evv + 1);
+        return true;
+}
+
+#define SECTOR_SIZE 512
+static bool
+set_backend_size(struct mic_info *mic)
+{
+        mic->mic_virtblk.backend_size = lseek(mic->mic_virtblk.backend, 0,
+                SEEK_END);
+        if (mic->mic_virtblk.backend_size < 0) {
+                mpsslog("%s: can't seek: %s\n",
+                        mic->name, mic->mic_virtblk.backend_file);
+                return false;
+        }
+        virtblk_dev_page.blk_config.capacity =
+                mic->mic_virtblk.backend_size / SECTOR_SIZE;
+        if ((mic->mic_virtblk.backend_size % SECTOR_SIZE) != 0)
+                virtblk_dev_page.blk_config.capacity++;
+
+        virtblk_dev_page.blk_config.capacity =
+                htole64(virtblk_dev_page.blk_config.capacity);
+
+        return true;
+}
+
+static bool
+open_backend(struct mic_info *mic)
+{
+        if (!set_backend_file(mic))
+                goto _error_exit;
+        mic->mic_virtblk.backend = open(mic->mic_virtblk.backend_file, O_RDWR);
+        if (mic->mic_virtblk.backend < 0) {
+                mpsslog("%s: can't open: %s\n", mic->name,
+                        mic->mic_virtblk.backend_file);
+                goto _error_free;
+        }
+        if (!set_backend_size(mic))
+                goto _error_close;
+        mic->mic_virtblk.backend_addr = mmap(NULL,
+                mic->mic_virtblk.backend_size,
+                PROT_READ|PROT_WRITE, MAP_SHARED,
+                mic->mic_virtblk.backend, 0L);
+        if (mic->mic_virtblk.backend_addr == MAP_FAILED) {
+                mpsslog("%s: can't map: %s %s\n",
+                        mic->name, mic->mic_virtblk.backend_file,
+                        strerror(errno));
+                goto _error_close;
+        }
+        return true;
+
+ _error_close:
+        close(mic->mic_virtblk.backend);
+ _error_free:
+        free(mic->mic_virtblk.backend_file);
+ _error_exit:
+        return false;
+}
+
+static void
+close_backend(struct mic_info *mic)
+{
+        munmap(mic->mic_virtblk.backend_addr, mic->mic_virtblk.backend_size);
+        close(mic->mic_virtblk.backend);
+        free(mic->mic_virtblk.backend_file);
+}
+
+static bool
+start_virtblk(struct mic_info *mic, struct mic_vring *vring)
+{
+        if (((unsigned long)&virtblk_dev_page.blk_config % 8) != 0) {
+                mpsslog("%s: blk_config is not 8 byte aligned.\n",
+                        mic->name);
+                return false;
+        }
+        add_virtio_device(mic, &virtblk_dev_page.dd);
+        if (MAP_FAILED == init_vr(mic, mic->mic_virtblk.virtio_block_fd,
+                                  VIRTIO_ID_BLOCK, vring, NULL,
+                                  virtblk_dev_page.dd.num_vq)) {
+                mpsslog("%s init_vr failed %s\n",
+                        mic->name, strerror(errno));
+                return false;
+        }
+        return true;
+}
+
+static void
+stop_virtblk(struct mic_info *mic)
+{
+        int vr_size, ret;
+
+        vr_size = PAGE_ALIGN(vring_size(MIC_VRING_ENTRIES,
+                MIC_VIRTIO_RING_ALIGN) + sizeof(struct _mic_vring_info));
+        ret = munmap(mic->mic_virtblk.block_dp,
+                MIC_DEVICE_PAGE_END + vr_size * virtblk_dev_page.dd.num_vq);
+        if (ret < 0)
+                mpsslog("%s munmap errno %d\n", mic->name, errno);
+        close(mic->mic_virtblk.virtio_block_fd);
+}
+
+static __u8
+header_error_check(struct vring_desc *desc)
+{
+        if (le32toh(desc->len) != sizeof(struct virtio_blk_outhdr)) {
+                mpsslog("%s() %d: length is not sizeof(virtio_blk_outhd)\n",
+                        __func__, __LINE__);
+                return -EIO;
+        }
+        if (!(le16toh(desc->flags) & VRING_DESC_F_NEXT)) {
+                mpsslog("%s() %d: alone\n",
+                        __func__, __LINE__);
+                return -EIO;
+        }
+        if (le16toh(desc->flags) & VRING_DESC_F_WRITE) {
+                mpsslog("%s() %d: not read\n",
+                        __func__, __LINE__);
+                return -EIO;
+        }
+        return 0;
+}
+
+static int
+read_header(int fd, struct virtio_blk_outhdr *hdr, __u32 desc_idx)
+{
+        struct iovec iovec;
+        struct mic_copy_desc copy;
+
+        iovec.iov_len = sizeof(*hdr);
+        iovec.iov_base = hdr;
+        copy.iov = &iovec;
+        copy.iovcnt = 1;
+        copy.vr_idx = 0;  /* only one vring on virtio_block */
+        copy.update_used = false;  /* do not update used index */
+        return ioctl(fd, MIC_VIRTIO_COPY_DESC, &copy);
+}
+
+static int
+transfer_blocks(int fd, struct iovec *iovec, __u32 iovcnt)
+{
+        struct mic_copy_desc copy;
+
+        copy.iov = iovec;
+        copy.iovcnt = iovcnt;
+        copy.vr_idx = 0;  /* only one vring on virtio_block */
+        copy.update_used = false;  /* do not update used index */
+        return ioctl(fd, MIC_VIRTIO_COPY_DESC, &copy);
+}
+
+static __u8
+status_error_check(struct vring_desc *desc)
+{
+        if (le32toh(desc->len) != sizeof(__u8)) {
+                mpsslog("%s() %d: length is not sizeof(status)\n",
+                        __func__, __LINE__);
+                return -EIO;
+        }
+        return 0;
+}
+
+static int
+write_status(int fd, __u8 *status)
+{
+        struct iovec iovec;
+        struct mic_copy_desc copy;
+
+        iovec.iov_base = status;
+        iovec.iov_len = sizeof(*status);
+        copy.iov = &iovec;
+        copy.iovcnt = 1;
+        copy.vr_idx = 0;  /* only one vring on virtio_block */
+        copy.update_used = true; /* Update used index */
+        return ioctl(fd, MIC_VIRTIO_COPY_DESC, &copy);
+}
+
+static void *
+virtio_block(void *arg)
+{
+        struct mic_info *mic = (struct mic_info *)arg;
+        int ret;
+        struct pollfd block_poll;
+        struct mic_vring vring;
+        __u16 avail_idx;
+        __u32 desc_idx;
+        struct vring_desc *desc;
+        struct iovec *iovec, *piov;
+        __u8 status;
+        __u32 buffer_desc_idx;
+        struct virtio_blk_outhdr hdr;
+        void *fos;
+
+        for (;;) {  /* forever */
+                if (!open_backend(mic)) { /* No virtblk */
+                        for (mic->mic_virtblk.signaled = 0;
+                                !mic->mic_virtblk.signaled;)
+                                sleep(1);
+                        continue;
+                }
+
+                /* backend file is specified. */
+                if (!start_virtblk(mic, &vring))
+                        goto _close_backend;
+                iovec = malloc(sizeof(*iovec) *
+                        le32toh(virtblk_dev_page.blk_config.seg_max));
+                if (!iovec) {
+                        mpsslog("%s: can't alloc iovec: %s\n",
+                                mic->name, strerror(ENOMEM));
+                        goto _stop_virtblk;
+                }
+
+                block_poll.fd = mic->mic_virtblk.virtio_block_fd;
+                block_poll.events = POLLIN;
+                for (mic->mic_virtblk.signaled = 0;
+                     !mic->mic_virtblk.signaled;) {
+                        block_poll.revents = 0;
+                                        /* timeout in 1 sec to see signaled */
+                        ret = poll(&block_poll, 1, 1000);
+                        if (ret < 0) {
+                                mpsslog("%s %d: poll failed: %s\n",
+                                        __func__, __LINE__,
+                                        strerror(errno));
+                                continue;
+                        }
+
+                        if (!(block_poll.revents & POLLIN)) {
+#ifdef DEBUG
+                                mpsslog("%s %d: block_poll.revents=0x%x\n",
+                                        __func__, __LINE__, block_poll.revents);
+#endif
+                                continue;
+                        }
+
+                        /* POLLIN */
+                        while (vring.info->avail_idx !=
+                                le16toh(vring.vr.avail->idx)) {
+                                /* read header element */
+                                avail_idx =
+                                        vring.info->avail_idx &
+                                        (vring.vr.num - 1);
+                                desc_idx = le16toh(
+                                        vring.vr.avail->ring[avail_idx]);
+                                desc = &vring.vr.desc[desc_idx];
+#ifdef DEBUG
+                                mpsslog("%s() %d: avail_idx=%d ",
+                                        __func__, __LINE__,
+                                        vring.info->avail_idx);
+                                mpsslog("vring.vr.num=%d desc=%p\n",
+                                        vring.vr.num, desc);
+#endif
+                                status = header_error_check(desc);
+                                ret = read_header(
+                                        mic->mic_virtblk.virtio_block_fd,
+                                        &hdr, desc_idx);
+                                if (ret < 0) {
+                                        mpsslog("%s() %d %s: ret=%d %s\n",
+                                                __func__, __LINE__,
+                                                mic->name, ret,
+                                                strerror(errno));
+                                        break;
+                                }
+                                /* buffer element */
+                                piov = iovec;
+                                status = 0;
+                                fos = mic->mic_virtblk.backend_addr +
+                                        (hdr.sector * SECTOR_SIZE);
+                                buffer_desc_idx = next_desc(desc);
+                                desc_idx = buffer_desc_idx;
+                                for (desc = &vring.vr.desc[buffer_desc_idx];
+                                     desc->flags & VRING_DESC_F_NEXT;
+                                     desc_idx = next_desc(desc),
+                                             desc = &vring.vr.desc[desc_idx]) {
+                                        piov->iov_len = desc->len;
+                                        piov->iov_base = fos;
+                                        piov++;
+                                        fos += desc->len;
+                                }
+                                /* Returning NULLs for VIRTIO_BLK_T_GET_ID. */
+                                if (hdr.type & ~(VIRTIO_BLK_T_OUT |
+                                        VIRTIO_BLK_T_GET_ID)) {
+                                        /*
+                                          VIRTIO_BLK_T_IN - does not do
+                                          anything. Probably for documenting.
+                                          VIRTIO_BLK_T_SCSI_CMD - for
+                                          virtio_scsi.
+                                          VIRTIO_BLK_T_FLUSH - turned off in
+                                          config space.
+                                          VIRTIO_BLK_T_BARRIER - defined but not
+                                          used in anywhere.
+                                        */
+                                        mpsslog("%s() %d: type %x ",
+                                                __func__, __LINE__,
+                                                hdr.type);
+                                        mpsslog("is not supported\n");
+                                        status = -ENOTSUP;
+
+                                } else {
+                                        ret = transfer_blocks(
+                                        mic->mic_virtblk.virtio_block_fd,
+                                                iovec,
+                                                piov - iovec);
+                                        if (ret < 0 &&
+                                            status != 0)
+                                                status = ret;
+                                }
+                                /* write status and update used pointer */
+                                if (status != 0)
+                                        status = status_error_check(desc);
+                                ret = write_status(
+                                        mic->mic_virtblk.virtio_block_fd,
+                                        &status);
+#ifdef DEBUG
+                                mpsslog("%s() %d: write status=%d on desc=%p\n",
+                                        __func__, __LINE__,
+                                        status, desc);
+#endif
+                        }
+                }
+                free(iovec);
+_stop_virtblk:
+                stop_virtblk(mic);
+_close_backend:
+                close_backend(mic);
+        }  /* forever */
+
+        pthread_exit(NULL);
+}
+
+static void
+reset(struct mic_info *mic)
+{
+#define RESET_TIMEOUT 120
+        int i = RESET_TIMEOUT;
+        setsysfs(mic->name, "state", "reset");
+        while (i) {
+                char *state;
+                state = readsysfs(mic->name, "state");
+                if (!state)
+                        goto retry;
+                mpsslog("%s: %s %d state %s\n",
+                        mic->name, __func__, __LINE__, state);
+
+                /*
+                 * If the shutdown was initiated by OSPM, the state stays
+                 * in "suspended" which is also a valid condition for reset.
+                 */
+                if ((!strcmp(state, "offline")) ||
+                    (!strcmp(state, "suspended"))) {
+                        free(state);
+                        break;
+                }
+                free(state);
+retry:
+                sleep(1);
+                i--;
+        }
+}
+
+static int
+get_mic_shutdown_status(struct mic_info *mic, char *shutdown_status)
+{
+        if (!strcmp(shutdown_status, "nop"))
+                return MIC_NOP;
+        if (!strcmp(shutdown_status, "crashed"))
+                return MIC_CRASHED;
+        if (!strcmp(shutdown_status, "halted"))
+                return MIC_HALTED;
+        if (!strcmp(shutdown_status, "poweroff"))
+                return MIC_POWER_OFF;
+        if (!strcmp(shutdown_status, "restart"))
+                return MIC_RESTART;
+        mpsslog("%s: BUG invalid status %s\n", mic->name, shutdown_status);
+        /* Invalid state */
+        assert(0);
+};
+
+static int get_mic_state(struct mic_info *mic, char *state)
+{
+        if (!strcmp(state, "offline"))
+                return MIC_OFFLINE;
+        if (!strcmp(state, "online"))
+                return MIC_ONLINE;
+        if (!strcmp(state, "shutting_down"))
+                return MIC_SHUTTING_DOWN;
+        if (!strcmp(state, "reset_failed"))
+                return MIC_RESET_FAILED;
+        if (!strcmp(state, "suspending"))
+                return MIC_SUSPENDING;
+        if (!strcmp(state, "suspended"))
+                return MIC_SUSPENDED;
+        mpsslog("%s: BUG invalid state %s\n", mic->name, state);
+        /* Invalid state */
+        assert(0);
+};
+
+static void mic_handle_shutdown(struct mic_info *mic)
+{
+#define SHUTDOWN_TIMEOUT 60
+        int i = SHUTDOWN_TIMEOUT, ret, stat = 0;
+        char *shutdown_status;
+        while (i) {
+                shutdown_status = readsysfs(mic->name, "shutdown_status");
+                if (!shutdown_status)
+                        continue;
+                mpsslog("%s: %s %d shutdown_status %s\n",
+                        mic->name, __func__, __LINE__, shutdown_status);
+                switch (get_mic_shutdown_status(mic, shutdown_status)) {
+                case MIC_RESTART:
+                        mic->restart = 1;
+                case MIC_HALTED:
+                case MIC_POWER_OFF:
+                case MIC_CRASHED:
+                        free(shutdown_status);
+                        goto reset;
+                default:
+                        break;
+                }
+                free(shutdown_status);
+                sleep(1);
+                i--;
+        }
+reset:
+        ret = kill(mic->pid, SIGTERM);
+        mpsslog("%s: %s %d kill pid %d ret %d\n",
+                mic->name, __func__, __LINE__,
+                mic->pid, ret);
+        if (!ret) {
+                ret = waitpid(mic->pid, &stat,
+                        WIFSIGNALED(stat));
+                mpsslog("%s: %s %d waitpid ret %d pid %d\n",
+                        mic->name, __func__, __LINE__,
+                        ret, mic->pid);
+        }
+        if (ret == mic->pid)
+                reset(mic);
+}
+
+static void *
+mic_config(void *arg)
+{
+        struct mic_info *mic = (struct mic_info *)arg;
+        char *state = NULL;
+        char pathname[PATH_MAX];
+        int fd, ret;
+        struct pollfd ufds[1];
+        char value[4096];
+
+        snprintf(pathname, PATH_MAX - 1, "%s/%s/%s",
+                 MICSYSFSDIR, mic->name, "state");
+
+        fd = open(pathname, O_RDONLY);
+        if (fd < 0) {
+                mpsslog("%s: opening file %s failed %s\n",
+                        mic->name, pathname, strerror(errno));
+                goto error;
+        }
+
+        do {
+                ret = read(fd, value, sizeof(value));
+                if (ret < 0) {
+                        mpsslog("%s: Failed to read sysfs entry '%s': %s\n",
+                                mic->name, pathname, strerror(errno));
+                        goto close_error1;
+                }
+retry:
+                state = readsysfs(mic->name, "state");
+                if (!state)
+                        goto retry;
+                mpsslog("%s: %s %d state %s\n",
+                        mic->name, __func__, __LINE__, state);
+                switch (get_mic_state(mic, state)) {
+                case MIC_SHUTTING_DOWN:
+                        mic_handle_shutdown(mic);
+                        goto close_error;
+                case MIC_SUSPENDING:
+                        mic->boot_on_resume = 1;
+                        setsysfs(mic->name, "state", "suspend");
+                        mic_handle_shutdown(mic);
+                        goto close_error;
+                case MIC_OFFLINE:
+                        if (mic->boot_on_resume) {
+                                setsysfs(mic->name, "state", "boot");
+                                mic->boot_on_resume = 0;
+                        }
+                        break;
+                default:
+                        break;
+                }
+                free(state);
+
+                ufds[0].fd = fd;
+                ufds[0].events = POLLERR | POLLPRI;
+                ret = poll(ufds, 1, -1);
+                if (ret < 0) {
+                        mpsslog("%s: poll failed %s\n",
+                                mic->name, strerror(errno));
+                        goto close_error1;
+                }
+        } while (1);
+close_error:
+        free(state);
+close_error1:
+        close(fd);
+error:
+        init_mic(mic);
+        pthread_exit(NULL);
+}
+
+static void
+set_cmdline(struct mic_info *mic)
+{
+        char buffer[PATH_MAX];
+        int len;
+
+        len = snprintf(buffer, PATH_MAX,
+                "clocksource=tsc highres=off nohz=off ");
+        len += snprintf(buffer + len, PATH_MAX,
+                "cpufreq_on;corec6_off;pc3_off;pc6_off ");
+        len += snprintf(buffer + len, PATH_MAX,
+                "ifcfg=static;address,172.31.%d.1;netmask,255.255.255.0",
+                mic->id);
+
+        setsysfs(mic->name, "cmdline", buffer);
+        mpsslog("%s: Command line: \"%s\"\n", mic->name, buffer);
+        snprintf(buffer, PATH_MAX, "172.31.%d.1", mic->id);
+        mpsslog("%s: IPADDR: \"%s\"\n", mic->name, buffer);
+}
+
+static void
+set_log_buf_info(struct mic_info *mic)
+{
+        int fd;
+        off_t len;
+        char system_map[] = "/lib/firmware/mic/System.map";
+        char *map, *temp, log_buf[17] = {'\0'};
+
+        fd = open(system_map, O_RDONLY);
+        if (fd < 0) {
+                mpsslog("%s: Opening System.map failed: %d\n",
+                        mic->name, errno);
+                return;
+        }
+        len = lseek(fd, 0, SEEK_END);
+        if (len < 0) {
+                mpsslog("%s: Reading System.map size failed: %d\n",
+                        mic->name, errno);
+                close(fd);
+                return;
+        }
+        map = mmap(NULL, len, PROT_READ, MAP_PRIVATE, fd, 0);
+        if (map == MAP_FAILED) {
+                mpsslog("%s: mmap of System.map failed: %d\n",
+                        mic->name, errno);
+                close(fd);
+                return;
+        }
+        temp = strstr(map, "__log_buf");
+        if (!temp) {
+                mpsslog("%s: __log_buf not found: %d\n", mic->name, errno);
+                munmap(map, len);
+                close(fd);
+                return;
+        }
+        strncpy(log_buf, temp - 19, 16);
+        setsysfs(mic->name, "log_buf_addr", log_buf);
+        mpsslog("%s: log_buf_addr: %s\n", mic->name, log_buf);
+        temp = strstr(map, "log_buf_len");
+        if (!temp) {
+                mpsslog("%s: log_buf_len not found: %d\n", mic->name, errno);
+                munmap(map, len);
+                close(fd);
+                return;
+        }
+        strncpy(log_buf, temp - 19, 16);
+        setsysfs(mic->name, "log_buf_len", log_buf);
+        mpsslog("%s: log_buf_len: %s\n", mic->name, log_buf);
+        munmap(map, len);
+        close(fd);
+}
+
+static void init_mic(struct mic_info *mic);
+
+static void
+change_virtblk_backend(int x, siginfo_t *siginfo, void *p)
+{
+        struct mic_info *mic;
+
+        for (mic = mic_list.next; mic != NULL; mic = mic->next)
+                mic->mic_virtblk.signaled = 1/* true */;
+}
+
+static void
+init_mic(struct mic_info *mic)
+{
+        struct sigaction ignore = {
+                .sa_flags = 0,
+                .sa_handler = SIG_IGN
+        };
+        struct sigaction act = {
+                .sa_flags = SA_SIGINFO,
+                .sa_sigaction = change_virtblk_backend,
+        };
+        char buffer[PATH_MAX];
+        int err;
+
+        /*
+         * Currently, one virtio block device is supported for each MIC card
+         * at a time. Any user (or test) can send a SIGUSR1 to the MIC daemon.
+         * The signal informs the virtio block backend about a change in the
+         * configuration file which specifies the virtio backend file name on
+         * the host. Virtio block backend then re-reads the configuration file
+         * and switches to the new block device. This signalling mechanism may
+         * not be required once multiple virtio block devices are supported by
+         * the MIC daemon.
+         */
+        sigaction(SIGUSR1, &ignore, NULL);
+
+        mic->pid = fork();
+        switch (mic->pid) {
+        case 0:
+                set_log_buf_info(mic);
+                set_cmdline(mic);
+                add_virtio_device(mic, &virtcons_dev_page.dd);
+                add_virtio_device(mic, &virtnet_dev_page.dd);
+                err = pthread_create(&mic->mic_console.console_thread, NULL,
+                        virtio_console, mic);
+                if (err)
+                        mpsslog("%s virtcons pthread_create failed %s\n",
+                                mic->name, strerror(err));
+                err = pthread_create(&mic->mic_net.net_thread, NULL,
+                        virtio_net, mic);
+                if (err)
+                        mpsslog("%s virtnet pthread_create failed %s\n",
+                                mic->name, strerror(err));
+                err = pthread_create(&mic->mic_virtblk.block_thread, NULL,
+                        virtio_block, mic);
+                if (err)
+                        mpsslog("%s virtblk pthread_create failed %s\n",
+                                mic->name, strerror(err));
+                sigemptyset(&act.sa_mask);
+                err = sigaction(SIGUSR1, &act, NULL);
+                if (err)
+                        mpsslog("%s sigaction SIGUSR1 failed %s\n",
+                                mic->name, strerror(errno));
+                while (1)
+                        sleep(60);
+        case -1:
+                mpsslog("fork failed MIC name %s id %d errno %d\n",
+                        mic->name, mic->id, errno);
+                break;
+        default:
+                if (mic->restart) {
+                        snprintf(buffer, PATH_MAX, "boot");
+                        setsysfs(mic->name, "state", buffer);
+                        mpsslog("%s restarting mic %d\n",
+                                mic->name, mic->restart);
+                        mic->restart = 0;
+                }
+                pthread_create(&mic->config_thread, NULL, mic_config, mic);
+        }
+}
+
+static void
+start_daemon(void)
+{
+        struct mic_info *mic;
+
+        for (mic = mic_list.next; mic != NULL; mic = mic->next)
+                init_mic(mic);
+
+        while (1)
+                sleep(60);
+}
+
+static int
+init_mic_list(void)
+{
+        struct mic_info *mic = &mic_list;
+        struct dirent *file;
+        DIR *dp;
+        int cnt = 0;
+
+        dp = opendir(MICSYSFSDIR);
+        if (!dp)
+                return 0;
+
+        while ((file = readdir(dp)) != NULL) {
+                if (!strncmp(file->d_name, "mic", 3)) {
+                        mic->next = calloc(1, sizeof(struct mic_info));
+                        if (mic->next) {
+                                mic = mic->next;
+                                mic->id = atoi(&file->d_name[3]);
+                                mic->name = malloc(strlen(file->d_name) + 16);
+                                if (mic->name)
+                                        strcpy(mic->name, file->d_name);
+                                mpsslog("MIC name %s id %d\n", mic->name,
+                                        mic->id);
+                                cnt++;
+                        }
+                }
+        }
+
+        closedir(dp);
+        return cnt;
+}
+
+void
+mpsslog(char *format, ...)
+{
+        va_list args;
+        char buffer[4096];
+        char ts[52], *ts1;
+        time_t t;
+
+        if (logfp == NULL)
+                return;
+
+        va_start(args, format);
+        vsprintf(buffer, format, args);
+        va_end(args);
+
+        time(&t);
+        ts1 = ctime_r(&t, ts);
+        ts1[strlen(ts1) - 1] = '\0';
+        fprintf(logfp, "%s: %s", ts1, buffer);
+
+        fflush(logfp);
+}
+
+int
+main(int argc, char *argv[])
+{
+        int cnt;
+        pid_t pid;
+
+        myname = argv[0];
+
+        logfp = fopen(LOGFILE_NAME, "a+");
+        if (!logfp) {
+                fprintf(stderr, "cannot open logfile '%s'\n", LOGFILE_NAME);
+                exit(1);
+        }
+        pid = fork();
+        switch (pid) {
+        case 0:
+                break;
+        case -1:
+                exit(2);
+        default:
+                exit(0);
+        }
+
+        mpsslog("MIC Daemon start\n");
+
+        cnt = init_mic_list();
+        if (cnt == 0) {
+                mpsslog("MIC module not loaded\n");
+                exit(3);
+        }
+        mpsslog("MIC found %d devices\n", cnt);
+
+        start_daemon();
+
+        exit(0);
+}
diff --git a/Documentation/mic/mpssd/mpssd.h b/Documentation/mic/mpssd/mpssd.h
new file mode 100644
index 000000000000..f5f18b15d9a0
--- /dev/null
+++ b/Documentation/mic/mpssd/mpssd.h
@@ -0,0 +1,102 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2013 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel MIC User Space Tools.
+ */
+#ifndef _MPSSD_H_
+#define _MPSSD_H_
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <dirent.h>
+#include <libgen.h>
+#include <pthread.h>
+#include <stdarg.h>
+#include <time.h>
+#include <errno.h>
+#include <sys/dir.h>
+#include <sys/ioctl.h>
+#include <sys/poll.h>
+#include <sys/types.h>
+#include <sys/socket.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <sys/mman.h>
+#include <sys/utsname.h>
+#include <sys/wait.h>
+#include <netinet/in.h>
+#include <arpa/inet.h>
+#include <netdb.h>
+#include <pthread.h>
+#include <signal.h>
+#include <limits.h>
+#include <syslog.h>
+#include <getopt.h>
+#include <net/if.h>
+#include <linux/if_tun.h>
+#include <linux/if_tun.h>
+#include <linux/virtio_ids.h>
+
+#define MICSYSFSDIR "/sys/class/mic"
+#define LOGFILE_NAME "/var/log/mpssd"
+#define PAGE_SIZE 4096
+
+struct mic_console_info {
+        pthread_t       console_thread;
+        int             virtio_console_fd;
+        void            *console_dp;
+};
+
+struct mic_net_info {
+        pthread_t       net_thread;
+        int             virtio_net_fd;
+        int             tap_fd;
+        void            *net_dp;
+};
+
+struct mic_virtblk_info {
+        pthread_t       block_thread;
+        int             virtio_block_fd;
+        void            *block_dp;
+        volatile sig_atomic_t   signaled;
+        char            *backend_file;
+        int             backend;
+        void            *backend_addr;
+        long            backend_size;
+};
+
+struct mic_info {
+        int             id;
+        char            *name;
+        pthread_t       config_thread;
+        pid_t           pid;
+        struct mic_console_info mic_console;
+        struct mic_net_info     mic_net;
+        struct mic_virtblk_info mic_virtblk;
+        int             restart;
+        int             boot_on_resume;
+        struct mic_info *next;
+};
+
+__attribute__((format(printf, 1, 2)))
+void mpsslog(char *format, ...);
+char *readsysfs(char *dir, char *entry);
+int setsysfs(char *dir, char *entry, char *value);
+#endif
diff --git a/Documentation/mic/mpssd/sysfs.c b/Documentation/mic/mpssd/sysfs.c
new file mode 100644
index 000000000000..8dd326936083
--- /dev/null
+++ b/Documentation/mic/mpssd/sysfs.c
@@ -0,0 +1,102 @@
+/*
+ * Intel MIC Platform Software Stack (MPSS)
+ *
+ * Copyright(c) 2013 Intel Corporation.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * The full GNU General Public License is included in this distribution in
+ * the file called "COPYING".
+ *
+ * Intel MIC User Space Tools.
+ */
+
+#include "mpssd.h"
+
+#define PAGE_SIZE 4096
+
+char *
+readsysfs(char *dir, char *entry)
+{
+        char filename[PATH_MAX];
+        char value[PAGE_SIZE];
+        char *string = NULL;
+        int fd;
+        int len;
+
+        if (dir == NULL)
+                snprintf(filename, PATH_MAX, "%s/%s", MICSYSFSDIR, entry);
+        else
+                snprintf(filename, PATH_MAX,
+                         "%s/%s/%s", MICSYSFSDIR, dir, entry);
+
+        fd = open(filename, O_RDONLY);
+        if (fd < 0) {
+                mpsslog("Failed to open sysfs entry '%s': %s\n",
+                        filename, strerror(errno));
+                return NULL;
+        }
+
+        len = read(fd, value, sizeof(value));
+        if (len < 0) {
+                mpsslog("Failed to read sysfs entry '%s': %s\n",
+                        filename, strerror(errno));
+                goto readsys_ret;
+        }
+        if (len == 0)
+                goto readsys_ret;
+
+        value[len - 1] = '\0';
+
+        string = malloc(strlen(value) + 1);
+        if (string)
+                strcpy(string, value);
+
+readsys_ret:
+        close(fd);
+        return string;
+}
+
+int
+setsysfs(char *dir, char *entry, char *value)
+{
+        char filename[PATH_MAX];
+        char *oldvalue;
+        int fd, ret = 0;
+
+        if (dir == NULL)
+                snprintf(filename, PATH_MAX, "%s/%s", MICSYSFSDIR, entry);
+        else
+                snprintf(filename, PATH_MAX, "%s/%s/%s",
+                         MICSYSFSDIR, dir, entry);
+
+        oldvalue = readsysfs(dir, entry);
+
+        fd = open(filename, O_RDWR);
+        if (fd < 0) {
+                ret = errno;
+                mpsslog("Failed to open sysfs entry '%s': %s\n",
+                        filename, strerror(errno));
+                goto done;
+        }
+
+        if (!oldvalue || strcmp(value, oldvalue)) {
+                if (write(fd, value, strlen(value)) < 0) {
+                        ret = errno;
+                        mpsslog("Failed to write new sysfs entry '%s': %s\n",
+                                filename, strerror(errno));
+                }
+        }
+        close(fd);
+done:
+        if (oldvalue)
+                free(oldvalue);
+        return ret;
+}
diff --git a/Documentation/mutex-design.txt b/Documentation/mutex-design.txt
index 38c10fd7f411..1dfe62c3641d 100644
--- a/Documentation/mutex-design.txt
+++ b/Documentation/mutex-design.txt
@@ -116,11 +116,11 @@ using mutexes at the moment, please let me know if you find any. ]
 Implementation of mutexes
 -------------------------
 
-'struct mutex' is the new mutex type, defined in include/linux/mutex.h
-and implemented in kernel/mutex.c. It is a counter-based mutex with a
-spinlock and a wait-list. The counter has 3 states: 1 for "unlocked",
-0 for "locked" and negative numbers (usually -1) for "locked, potential
-waiters queued".
+'struct mutex' is the new mutex type, defined in include/linux/mutex.h and
+implemented in kernel/locking/mutex.c. It is a counter-based mutex with a
+spinlock and a wait-list. The counter has 3 states: 1 for "unlocked", 0 for
+"locked" and negative numbers (usually -1) for "locked, potential waiters
+queued".
 
 the APIs of 'struct mutex' have been streamlined:
 
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
index c1d82047a4b1..89490beb3c0b 100644
--- a/Documentation/networking/batman-adv.txt
+++ b/Documentation/networking/batman-adv.txt
@@ -69,8 +69,7 @@ folder:
 # aggregated_ogms        gw_bandwidth           log_level
 # ap_isolation           gw_mode                orig_interval
 # bonding                gw_sel_class           routing_algo
-# bridge_loop_avoidance  hop_penalty            vis_mode
-# fragmentation
+# bridge_loop_avoidance  hop_penalty            fragmentation
 
 
 There is a special folder for debugging information:
@@ -78,7 +77,7 @@ There is a special folder for debugging information:
 # ls /sys/kernel/debug/batman_adv/bat0/
 # bla_backbone_table  log                 transtable_global
 # bla_claim_table     originators         transtable_local
-# gateways            socket              vis_data
+# gateways            socket
 
 Some of the files contain all sort of status information  regard-
 ing  the  mesh  network.  For  example, you can view the table of
@@ -127,51 +126,6 @@ ously assigned to interfaces now used by batman advanced, e.g.
 # ifconfig eth0 0.0.0.0
 
 
-VISUALIZATION
--------------
-
-If you want topology visualization, at least one mesh  node  must
-be configured as VIS-server:
-
-# echo "server" > /sys/class/net/bat0/mesh/vis_mode
-
-Each  node  is  either configured as "server" or as "client" (de-
-fault: "client").  Clients send their topology data to the server
-next to them, and server synchronize with other servers. If there
-is no server configured (default) within the  mesh,  no  topology
-information   will  be  transmitted.  With  these  "synchronizing
-servers", there can be 1 or more vis servers sharing the same (or
-at least very similar) data.
-
-When  configured  as  server,  you can get a topology snapshot of
-your mesh:
-
-# cat /sys/kernel/debug/batman_adv/bat0/vis_data
-
-This raw output is intended to be easily parsable and convertable
-with  other tools. Have a look at the batctl README if you want a
-vis output in dot or json format for instance and how those  out-
-puts could then be visualised in an image.
-
-The raw format consists of comma separated values per entry where
-each entry is giving information about a  certain  source  inter-
-face.  Each  entry can/has to have the following values:
--> "mac" - mac address of an originator's source interface
-           (each line begins with it)
--> "TQ mac  value"  -  src mac's link quality towards mac address
-                       of a neighbor originator's interface which
-                       is being used for routing
--> "TT mac" - TT announced by source mac
--> "PRIMARY" - this  is a primary interface
--> "SEC mac" - secondary mac address of source
-               (requires preceding PRIMARY)
-
-The TQ value has a range from 4 to 255 with 255 being  the  best.
-The TT entries are showing which hosts are connected to the mesh
-via bat0 or being bridged into the mesh network.  The PRIMARY/SEC
-values are only applied on primary interfaces
-
-
 LOGGING/DEBUGGING
 -----------------
 
@@ -245,5 +199,5 @@ Mailing-list:   b.a.t.m.a.n@open-mesh.org (optional  subscription
 
 You can also contact the Authors:
 
-Marek  Lindner  <lindner_marek@yahoo.de>
-Simon  Wunderlich  <siwu@hrz.tu-chemnitz.de>
+Marek  Lindner  <mareklindner@neomailbox.ch>
+Simon  Wunderlich  <sw@simonwunderlich.de>
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 9b28e714831a..2cdb8b66caa9 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -639,6 +639,15 @@ num_unsol_na
         are generated by the ipv4 and ipv6 code and the numbers of
         repetitions cannot be set independently.
 
+packets_per_slave
+
+        Specify the number of packets to transmit through a slave before
+        moving to the next one. When set to 0 then a slave is chosen at
+        random.
+
+        The valid range is 0 - 65535; the default value is 1. This option
+        has effect only in balance-rr mode.
+
 primary
 
         A string (eth0, eth2, etc) specifying which slave is the
@@ -743,21 +752,16 @@ xmit_hash_policy
                 protocol information to generate the hash.
 
                 Uses XOR of hardware MAC addresses and IP addresses to
-                generate the hash.  The IPv4 formula is
-
-                (((source IP XOR dest IP) AND 0xffff) XOR
-                        ( source MAC XOR destination MAC ))
-                                modulo slave count
-
-                The IPv6 formula is
+                generate the hash.  The formula is
 
-                hash = (source ip quad 2 XOR dest IP quad 2) XOR
-                       (source ip quad 3 XOR dest IP quad 3) XOR
-                       (source ip quad 4 XOR dest IP quad 4)
+                hash = source MAC XOR destination MAC
+                hash = hash XOR source IP XOR destination IP
+                hash = hash XOR (hash RSHIFT 16)
+                hash = hash XOR (hash RSHIFT 8)
+                And then hash is reduced modulo slave count.
 
-                (((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
-                        XOR (source MAC XOR destination MAC))
-                                modulo slave count
+                If the protocol is IPv6 then the source and destination
+                addresses are first hashed using ipv6_addr_hash.
 
                 This algorithm will place all traffic to a particular
                 network peer on the same slave.  For non-IP traffic,
@@ -779,21 +783,16 @@ xmit_hash_policy
                 slaves, although a single connection will not span
                 multiple slaves.
 
-                The formula for unfragmented IPv4 TCP and UDP packets is
+                The formula for unfragmented TCP and UDP packets is
 
-                ((source port XOR dest port) XOR
-                         ((source IP XOR dest IP) AND 0xffff)
-                                modulo slave count
+                hash = source port, destination port (as in the header)
+                hash = hash XOR source IP XOR destination IP
+                hash = hash XOR (hash RSHIFT 16)
+                hash = hash XOR (hash RSHIFT 8)
+                And then hash is reduced modulo slave count.
 
-                The formula for unfragmented IPv6 TCP and UDP packets is
-
-                hash = (source port XOR dest port) XOR
-                       ((source ip quad 2 XOR dest IP quad 2) XOR
-                        (source ip quad 3 XOR dest IP quad 3) XOR
-                        (source ip quad 4 XOR dest IP quad 4))
-
-                ((hash >> 24) XOR (hash >> 16) XOR (hash >> 8) XOR hash)
-                        modulo slave count
+                If the protocol is IPv6 then the source and destination
+                addresses are first hashed using ipv6_addr_hash.
 
                 For fragmented TCP or UDP packets and all other IPv4 and
                 IPv6 protocol traffic, the source and destination port
@@ -801,10 +800,6 @@ xmit_hash_policy
                 formula is the same as for the layer2 transmit hash
                 policy.
 
-                The IPv4 policy is intended to mimic the behavior of
-                certain switches, notably Cisco switches with PFC2 as
-                well as some Foundry and IBM products.
-
                 This algorithm is not fully 802.3ad compliant.  A
                 single TCP or UDP conversation containing both
                 fragmented and unfragmented packets will see packets
@@ -815,6 +810,26 @@ xmit_hash_policy
                 conversations.  Other implementations of 802.3ad may
                 or may not tolerate this noncompliance.
 
+        encap2+3
+
+                This policy uses the same formula as layer2+3 but it
+                relies on skb_flow_dissect to obtain the header fields
+                which might result in the use of inner headers if an
+                encapsulation protocol is used. For example this will
+                improve the performance for tunnel users because the
+                packets will be distributed according to the encapsulated
+                flows.
+
+        encap3+4
+
+                This policy uses the same formula as layer3+4 but it
+                relies on skb_flow_dissect to obtain the header fields
+                which might result in the use of inner headers if an
+                encapsulation protocol is used. For example this will
+                improve the performance for tunnel users because the
+                packets will be distributed according to the encapsulated
+                flows.
+
         The default value is layer2.  This option was added in bonding
         version 2.6.3.  In earlier versions of bonding, this parameter
         does not exist, and the layer2 policy is the only policy.  The
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 820f55344edc..4c072414eadb 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -25,6 +25,12 @@ This file contains
       4.1.5 RAW socket option CAN_RAW_FD_FRAMES
       4.1.6 RAW socket returned message flags
     4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
+      4.2.1 Broadcast Manager operations
+      4.2.2 Broadcast Manager message flags
+      4.2.3 Broadcast Manager transmission timers
+      4.2.4 Broadcast Manager message sequence transmission
+      4.2.5 Broadcast Manager receive filter timers
+      4.2.6 Broadcast Manager multiplex message receive filter
     4.3 connected transport protocols (SOCK_SEQPACKET)
     4.4 unconnected transport protocols (SOCK_DGRAM)
 
@@ -593,6 +599,217 @@ solution for a couple of reasons:
       In order to receive such messages, CAN_RAW_RECV_OWN_MSGS must be set.
 
   4.2 Broadcast Manager protocol sockets (SOCK_DGRAM)
+
+  The Broadcast Manager protocol provides a command based configuration
+  interface to filter and send (e.g. cyclic) CAN messages in kernel space.
+
+  Receive filters can be used to down sample frequent messages; detect events
+  such as message contents changes, packet length changes, and do time-out
+  monitoring of received messages.
+
+  Periodic transmission tasks of CAN frames or a sequence of CAN frames can be
+  created and modified at runtime; both the message content and the two
+  possible transmit intervals can be altered.
+
+  A BCM socket is not intended for sending individual CAN frames using the
+  struct can_frame as known from the CAN_RAW socket. Instead a special BCM
+  configuration message is defined. The basic BCM configuration message used
+  to communicate with the broadcast manager and the available operations are
+  defined in the linux/can/bcm.h include. The BCM message consists of a
+  message header with a command ('opcode') followed by zero or more CAN frames.
+  The broadcast manager sends responses to user space in the same form:
+
+    struct bcm_msg_head {
+            __u32 opcode;                   /* command */
+            __u32 flags;                    /* special flags */
+            __u32 count;                    /* run 'count' times with ival1 */
+            struct timeval ival1, ival2;    /* count and subsequent interval */
+            canid_t can_id;                 /* unique can_id for task */
+            __u32 nframes;                  /* number of can_frames following */
+            struct can_frame frames[0];
+    };
+
+  The aligned payload 'frames' uses the same basic CAN frame structure defined
+  at the beginning of section 4 and in the include/linux/can.h include. All
+  messages to the broadcast manager from user space have this structure.
+
+  Note a CAN_BCM socket must be connected instead of bound after socket
+  creation (example without error checking):
+
+    int s;
+    struct sockaddr_can addr;
+    struct ifreq ifr;
+
+    s = socket(PF_CAN, SOCK_DGRAM, CAN_BCM);
+
+    strcpy(ifr.ifr_name, "can0");
+    ioctl(s, SIOCGIFINDEX, &ifr);
+
+    addr.can_family = AF_CAN;
+    addr.can_ifindex = ifr.ifr_ifindex;
+
+    connect(s, (struct sockaddr *)&addr, sizeof(addr))
+
+    (..)
+
+  The broadcast manager socket is able to handle any number of in flight
+  transmissions or receive filters concurrently. The different RX/TX jobs are
+  distinguished by the unique can_id in each BCM message. However additional
+  CAN_BCM sockets are recommended to communicate on multiple CAN interfaces.
+  When the broadcast manager socket is bound to 'any' CAN interface (=> the
+  interface index is set to zero) the configured receive filters apply to any
+  CAN interface unless the sendto() syscall is used to overrule the 'any' CAN
+  interface index. When using recvfrom() instead of read() to retrieve BCM
+  socket messages the originating CAN interface is provided in can_ifindex.
+
+  4.2.1 Broadcast Manager operations
+
+  The opcode defines the operation for the broadcast manager to carry out,
+  or details the broadcast managers response to several events, including
+  user requests.
+
+  Transmit Operations (user space to broadcast manager):
+
+    TX_SETUP:   Create (cyclic) transmission task.
+
+    TX_DELETE:  Remove (cyclic) transmission task, requires only can_id.
+
+    TX_READ:    Read properties of (cyclic) transmission task for can_id.
+
+    TX_SEND:    Send one CAN frame.
+
+  Transmit Responses (broadcast manager to user space):
+
+    TX_STATUS:  Reply to TX_READ request (transmission task configuration).
+
+    TX_EXPIRED: Notification when counter finishes sending at initial interval
+      'ival1'. Requires the TX_COUNTEVT flag to be set at TX_SETUP.
+
+  Receive Operations (user space to broadcast manager):
+
+    RX_SETUP:   Create RX content filter subscription.
+
+    RX_DELETE:  Remove RX content filter subscription, requires only can_id.
+
+    RX_READ:    Read properties of RX content filter subscription for can_id.
+
+  Receive Responses (broadcast manager to user space):
+
+    RX_STATUS:  Reply to RX_READ request (filter task configuration).
+
+    RX_TIMEOUT: Cyclic message is detected to be absent (timer ival1 expired).
+
+    RX_CHANGED: BCM message with updated CAN frame (detected content change).
+      Sent on first message received or on receipt of revised CAN messages.
+
+  4.2.2 Broadcast Manager message flags
+
+  When sending a message to the broadcast manager the 'flags' element may
+  contain the following flag definitions which influence the behaviour:
+
+    SETTIMER:           Set the values of ival1, ival2 and count
+
+    STARTTIMER:         Start the timer with the actual values of ival1, ival2
+      and count. Starting the timer leads simultaneously to emit a CAN frame.
+
+    TX_COUNTEVT:        Create the message TX_EXPIRED when count expires
+
+    TX_ANNOUNCE:        A change of data by the process is emitted immediately.
+
+    TX_CP_CAN_ID:       Copies the can_id from the message header to each
+      subsequent frame in frames. This is intended as usage simplification. For
+      TX tasks the unique can_id from the message header may differ from the
+      can_id(s) stored for transmission in the subsequent struct can_frame(s).
+
+    RX_FILTER_ID:       Filter by can_id alone, no frames required (nframes=0).
+
+    RX_CHECK_DLC:       A change of the DLC leads to an RX_CHANGED.
+
+    RX_NO_AUTOTIMER:    Prevent automatically starting the timeout monitor.
+
+    RX_ANNOUNCE_RESUME: If passed at RX_SETUP and a receive timeout occured, a
+      RX_CHANGED message will be generated when the (cyclic) receive restarts.
+
+    TX_RESET_MULTI_IDX: Reset the index for the multiple frame transmission.
+
+    RX_RTR_FRAME:       Send reply for RTR-request (placed in op->frames[0]).
+
+  4.2.3 Broadcast Manager transmission timers
+
+  Periodic transmission configurations may use up to two interval timers.
+  In this case the BCM sends a number of messages ('count') at an interval
+  'ival1', then continuing to send at another given interval 'ival2'. When
+  only one timer is needed 'count' is set to zero and only 'ival2' is used.
+  When SET_TIMER and START_TIMER flag were set the timers are activated.
+  The timer values can be altered at runtime when only SET_TIMER is set.
+
+  4.2.4 Broadcast Manager message sequence transmission
+
+  Up to 256 CAN frames can be transmitted in a sequence in the case of a cyclic
+  TX task configuration. The number of CAN frames is provided in the 'nframes'
+  element of the BCM message head. The defined number of CAN frames are added
+  as array to the TX_SETUP BCM configuration message.
+
+    /* create a struct to set up a sequence of four CAN frames */
+    struct {
+            struct bcm_msg_head msg_head;
+            struct can_frame frame[4];
+    } mytxmsg;
+
+    (..)
+    mytxmsg.nframes = 4;
+    (..)
+
+    write(s, &mytxmsg, sizeof(mytxmsg));
+
+  With every transmission the index in the array of CAN frames is increased
+  and set to zero at index overflow.
+
+  4.2.5 Broadcast Manager receive filter timers
+
+  The timer values ival1 or ival2 may be set to non-zero values at RX_SETUP.
+  When the SET_TIMER flag is set the timers are enabled:
+
+  ival1: Send RX_TIMEOUT when a received message is not received again within
+    the given time. When START_TIMER is set at RX_SETUP the timeout detection
+    is activated directly - even without a former CAN frame reception.
+
+  ival2: Throttle the received message rate down to the value of ival2. This
+    is useful to reduce messages for the application when the signal inside the
+    CAN frame is stateless as state changes within the ival2 periode may get
+    lost.
+
+  4.2.6 Broadcast Manager multiplex message receive filter
+
+  To filter for content changes in multiplex message sequences an array of more
+  than one CAN frames can be passed in a RX_SETUP configuration message. The
+  data bytes of the first CAN frame contain the mask of relevant bits that
+  have to match in the subsequent CAN frames with the received CAN frame.
+  If one of the subsequent CAN frames is matching the bits in that frame data
+  mark the relevant content to be compared with the previous received content.
+  Up to 257 CAN frames (multiplex filter bit mask CAN frame plus 256 CAN
+  filters) can be added as array to the TX_SETUP BCM configuration message.
+
+    /* usually used to clear CAN frame data[] - beware of endian problems! */
+    #define U64_DATA(p) (*(unsigned long long*)(p)->data)
+
+    struct {
+            struct bcm_msg_head msg_head;
+            struct can_frame frame[5];
+    } msg;
+
+    msg.msg_head.opcode  = RX_SETUP;
+    msg.msg_head.can_id  = 0x42;
+    msg.msg_head.flags   = 0;
+    msg.msg_head.nframes = 5;
+    U64_DATA(&msg.frame[0]) = 0xFF00000000000000ULL; /* MUX mask */
+    U64_DATA(&msg.frame[1]) = 0x01000000000000FFULL; /* data mask (MUX 0x01) */
+    U64_DATA(&msg.frame[2]) = 0x0200FFFF000000FFULL; /* data mask (MUX 0x02) */
+    U64_DATA(&msg.frame[3]) = 0x330000FFFFFF0003ULL; /* data mask (MUX 0x33) */
+    U64_DATA(&msg.frame[4]) = 0x4F07FC0FF0000000ULL; /* data mask (MUX 0x4F) */
+
+    write(s, &msg, sizeof(msg));
+
   4.3 connected transport protocols (SOCK_SEQPACKET)
   4.4 unconnected transport protocols (SOCK_DGRAM)
 
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt
index d718bc2ff1cf..bf5dbe3ab8c5 100644
--- a/Documentation/networking/dccp.txt
+++ b/Documentation/networking/dccp.txt
@@ -18,8 +18,8 @@ Introduction
 Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
 oriented protocol designed to solve issues present in UDP and TCP, particularly
 for real-time and multimedia (streaming) traffic.
-It divides into a base protocol (RFC 4340) and plugable congestion control
-modules called CCIDs. Like plugable TCP congestion control, at least one CCID
+It divides into a base protocol (RFC 4340) and pluggable congestion control
+modules called CCIDs. Like pluggable TCP congestion control, at least one CCID
 needs to be enabled in order for the protocol to function properly. In the Linux
 implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
 the TCP-friendly CCID3 (RFC 4342), are optional.
diff --git a/Documentation/networking/e100.txt b/Documentation/networking/e100.txt
index 13a32124bca0..f862cf3aff34 100644
--- a/Documentation/networking/e100.txt
+++ b/Documentation/networking/e100.txt
@@ -103,7 +103,7 @@ Additional Configurations
   PRO/100 Family of Adapters is e100.
 
   As an example, if you install the e100 driver for two PRO/100 adapters
-  (eth0 and eth1), add the following to a configuraton file in /etc/modprobe.d/
+  (eth0 and eth1), add the following to a configuration file in /etc/modprobe.d/
 
        alias eth0 e100
        alias eth1 e100
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 09eb57329f11..22bbc7225f8e 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -4,7 +4,7 @@
 
 Introduction
 ============
-The IEEE 802.15.4 working group focuses on standartization of bottom
+The IEEE 802.15.4 working group focuses on standardization of bottom
 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
@@ -66,7 +66,7 @@ net_device, with .type = ARPHRD_IEEE802154. Data is exchanged with socket family
 code via plain sk_buffs. On skb reception skb->cb must contain additional
 info as described in the struct ieee802154_mac_cb. During packet transmission
 the skb->cb is used to provide additional data to device's header_ops->create
-function. Be aware, that this data can be overriden later (when socket code
+function. Be aware that this data can be overridden later (when socket code
 submits skb to qdisc), so if you need something from that cb later, you should
 store info in the skb->data on your own.
 
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index a46d78583ae1..3c12d9a7ed00 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -267,17 +267,6 @@ tcp_max_orphans - INTEGER
         more aggressively. Let me to remind again: each orphan eats
         up to ~64K of unswappable memory.
 
-tcp_max_ssthresh - INTEGER
-        Limited Slow-Start for TCP with large congestion windows (cwnd) defined in
-        RFC3742. Limited slow-start is a mechanism to limit growth of the cwnd
-        on the region where cwnd is larger than tcp_max_ssthresh. TCP increases cwnd
-        by at most tcp_max_ssthresh segments, and by at least tcp_max_ssthresh/2
-        segments per RTT when the cwnd is above tcp_max_ssthresh.
-        If TCP connection increased cwnd to thousands (or tens of thousands) segments,
-        and thousands of packets were being dropped during slow-start, you can set
-        tcp_max_ssthresh to improve performance for new TCP connection.
-        Default: 0 (off)
-
 tcp_max_syn_backlog - INTEGER
         Maximal number of remembered connection requests, which have not
         received an acknowledgment from connecting client.
@@ -451,7 +440,7 @@ tcp_fastopen - INTEGER
         connect() to perform a TCP handshake automatically.
 
         The values (bitmap) are
-        1: Enables sending data in the opening SYN on the client.
+        1: Enables sending data in the opening SYN on the client w/ MSG_FASTOPEN.
         2: Enables TCP Fast Open on the server side, i.e., allowing data in
            a SYN packet to be accepted and passed to the application before
            3-way hand shake finishes.
@@ -464,7 +453,7 @@ tcp_fastopen - INTEGER
            different ways of setting max_qlen without the TCP_FASTOPEN socket
            option.
 
-        Default: 0
+        Default: 1
 
         Note that the client & server side Fast Open flags (1 and 2
         respectively) must be also enabled before the rest of flags can take
@@ -588,9 +577,6 @@ tcp_limit_output_bytes - INTEGER
         typical pfifo_fast qdiscs.
         tcp_limit_output_bytes limits the number of bytes on qdisc
         or device to reduce artificial RTT/cwnd and reduce bufferbloat.
-        Note: For GSO/TSO enabled flows, we try to have at least two
-        packets in flight. Reducing tcp_limit_output_bytes might also
-        reduce the size of individual GSO packet (64KB being the max)
         Default: 131072
 
 tcp_challenge_ack_limit - INTEGER
diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt
index e63fc1f7bf87..c74434de2fa5 100644
--- a/Documentation/networking/l2tp.txt
+++ b/Documentation/networking/l2tp.txt
@@ -197,7 +197,7 @@ state information because the file format is subject to change. It is
 implemented to provide extra debug information to help diagnose
 problems.) Users should use the netlink API.
 
-/proc/net/pppol2tp is also provided for backwards compaibility with
+/proc/net/pppol2tp is also provided for backwards compatibility with
 the original pppol2tp driver. It lists information about L2TPv2
 tunnels and sessions only. Its use is discouraged.
 
diff --git a/Documentation/networking/netdev-FAQ.txt b/Documentation/networking/netdev-FAQ.txt
index d9112f01c44a..0fe1c6e0dbcd 100644
--- a/Documentation/networking/netdev-FAQ.txt
+++ b/Documentation/networking/netdev-FAQ.txt
@@ -4,23 +4,23 @@ Information you need to know about netdev
 
 Q: What is netdev?
 
-A: It is a mailing list for all network related linux stuff.  This includes
+A: It is a mailing list for all network-related Linux stuff.  This includes
    anything found under net/  (i.e. core code like IPv6) and drivers/net
-   (i.e. hardware specific drivers) in the linux source tree.
+   (i.e. hardware specific drivers) in the Linux source tree.
 
    Note that some subsystems (e.g. wireless drivers) which have a high volume
    of traffic have their own specific mailing lists.
 
-   The netdev list is managed (like many other linux mailing lists) through
+   The netdev list is managed (like many other Linux mailing lists) through
    VGER ( http://vger.kernel.org/ ) and archives can be found below:
 
         http://marc.info/?l=linux-netdev
         http://www.spinics.net/lists/netdev/
 
-   Aside from subsystems like that mentioned above, all network related linux
-   development (i.e. RFC, review, comments, etc) takes place on netdev.
+   Aside from subsystems like that mentioned above, all network-related Linux
+   development (i.e. RFC, review, comments, etc.) takes place on netdev.
 
-Q: How do the changes posted to netdev make their way into linux?
+Q: How do the changes posted to netdev make their way into Linux?
 
 A: There are always two trees (git repositories) in play.  Both are driven
    by David Miller, the main network maintainer.  There is the "net" tree,
@@ -35,7 +35,7 @@ A: There are always two trees (git repositories) in play.  Both are driven
 Q: How often do changes from these trees make it to the mainline Linus tree?
 
 A: To understand this, you need to know a bit of background information
-   on the cadence of linux development.  Each new release starts off with
+   on the cadence of Linux development.  Each new release starts off with
    a two week "merge window" where the main maintainers feed their new
    stuff to Linus for merging into the mainline tree.  After the two weeks,
    the merge window is closed, and it is called/tagged "-rc1".  No new
@@ -46,7 +46,7 @@ A: To understand this, you need to know a bit of background information
    things are in a state of churn), and a week after the last vX.Y-rcN
    was done, the official "vX.Y" is released.
 
-   Relating that to netdev:  At the beginning of the 2 week merge window,
+   Relating that to netdev:  At the beginning of the 2-week merge window,
    the net-next tree will be closed - no new changes/features.  The
    accumulated new content of the past ~10 weeks will be passed onto
    mainline/Linus via a pull request for vX.Y -- at the same time,
@@ -59,16 +59,16 @@ A: To understand this, you need to know a bit of background information
    IMPORTANT:  Do not send new net-next content to netdev during the
    period during which net-next tree is closed.
 
-   Shortly after the two weeks have passed, (and vX.Y-rc1 is released) the
+   Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
    tree for net-next reopens to collect content for the next (vX.Y+1) release.
 
    If you aren't subscribed to netdev and/or are simply unsure if net-next
    has re-opened yet, simply check the net-next git repository link above for
-   any new networking related commits.
+   any new networking-related commits.
 
    The "net" tree continues to collect fixes for the vX.Y content, and
    is fed back to Linus at regular (~weekly) intervals.  Meaning that the
-   focus for "net" is on stablilization and bugfixes.
+   focus for "net" is on stabilization and bugfixes.
 
    Finally, the vX.Y gets released, and the whole cycle starts over.
 
@@ -217,7 +217,7 @@ A: Attention to detail.  Re-read your own work as if you were the
    to why it happens, and then if necessary, explain why the fix proposed
    is the best way to get things done.   Don't mangle whitespace, and as
    is common, don't mis-indent function arguments that span multiple lines.
-   If it is your 1st patch, mail it to yourself so you can test apply
+   If it is your first patch, mail it to yourself so you can test apply
    it to an unpatched tree to confirm infrastructure didn't mangle it.
 
    Finally, go back and read Documentation/SubmittingPatches to be
diff --git a/Documentation/networking/netdevices.txt b/Documentation/networking/netdevices.txt
index c7ecc7080494..0b1cf6b2a592 100644
--- a/Documentation/networking/netdevices.txt
+++ b/Documentation/networking/netdevices.txt
@@ -10,12 +10,12 @@ network devices.
 struct net_device allocation rules
 ==================================
 Network device structures need to persist even after module is unloaded and
-must be allocated with kmalloc.  If device has registered successfully,
-it will be freed on last use by free_netdev.  This is required to handle the
-pathologic case cleanly (example: rmmod mydriver </sys/class/net/myeth/mtu )
+must be allocated with alloc_netdev_mqs() and friends.
+If device has registered successfully, it will be freed on last use
+by free_netdev(). This is required to handle the pathologic case cleanly
+(example: rmmod mydriver </sys/class/net/myeth/mtu )
 
-There are routines in net_init.c to handle the common cases of
-alloc_etherdev, alloc_netdev.  These reserve extra space for driver
+alloc_netdev_mqs()/alloc_netdev() reserve extra space for driver
 private data which gets freed when the network device is freed. If
 separately allocated data is attached to the network device
 (netdev_priv(dev)) then it is up to the module exit handler to free that.
diff --git a/Documentation/networking/netlink_mmap.txt b/Documentation/networking/netlink_mmap.txt
index 533378839546..b26122973525 100644
--- a/Documentation/networking/netlink_mmap.txt
+++ b/Documentation/networking/netlink_mmap.txt
@@ -45,7 +45,7 @@ processing.
 
 Conversion of the reception path involves calling poll() on the file
 descriptor, once the socket is readable the frames from the ring are
-processsed in order until no more messages are available, as indicated by
+processed in order until no more messages are available, as indicated by
 a status word in the frame header.
 
 On kernel side, in order to make use of memory mapped I/O on receive, the
@@ -56,7 +56,7 @@ Dumps of kernel databases automatically support memory mapped I/O.
 
 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
+stack and setting up the frame header appropriately. Optionally poll() can
 be used to wait for free frames in the TX ring.
 
 Structured and definitions for using memory mapped I/O are contained in
@@ -231,7 +231,7 @@ Ring setup:
         if (setsockopt(fd, NETLINK_TX_RING, &req, sizeof(req)) < 0)
                 exit(1)
 
-        /* Calculate size of each invididual ring */
+        /* Calculate size of each individual ring */
         ring_size = req.nm_block_nr * req.nm_block_size;
 
         /* Map RX/TX rings. The TX ring is located after the RX ring */
diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt
index 97694572338b..355c6d8ef8ad 100644
--- a/Documentation/networking/operstates.txt
+++ b/Documentation/networking/operstates.txt
@@ -89,8 +89,8 @@ packets. The name 'carrier' and the inversion are historical, think of
 it as lower layer.
 
 Note that for certain kind of soft-devices, which are not managing any
-real hardware, there is possible to set this bit from userpsace.
-One should use TVL IFLA_CARRIER to do so.
+real hardware, it is possible to set this bit from userspace.  One
+should use TVL IFLA_CARRIER to do so.
 
 netif_carrier_ok() can be used to query that bit.
 
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index 60d05eb77c64..b89bc82eed46 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -144,7 +144,7 @@ An overview of the RxRPC protocol:
  (*) Calls use ACK packets to handle reliability.  Data packets are also
      explicitly sequenced per call.
 
- (*) There are two types of positive acknowledgement: hard-ACKs and soft-ACKs.
+ (*) There are two types of positive acknowledgment: hard-ACKs and soft-ACKs.
      A hard-ACK indicates to the far side that all the data received to a point
      has been received and processed; a soft-ACK indicates that the data has
      been received but may yet be discarded and re-requested.  The sender may
diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt
index 457b8bbafb08..cdd916da838d 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -160,7 +160,7 @@ Where:
  o pmt: core has the embedded power module (optional).
  o force_sf_dma_mode: force DMA to use the Store and Forward mode
                      instead of the Threshold.
- o force_thresh_dma_mode: force DMA to use the Shreshold mode other than
+ o force_thresh_dma_mode: force DMA to use the Threshold mode other than
                      the Store and Forward mode.
  o riwt_off: force to disable the RX watchdog feature and switch to NAPI mode.
  o fix_mac_speed: this callback is used for modifying some syscfg registers
@@ -175,7 +175,7 @@ Where:
              registers.
  o custom_cfg/custom_data: this is a custom configuration that can be passed
                            while initializing the resources.
- o bsp_priv: another private poiter.
+ o bsp_priv: another private pointer.
 
 For MDIO bus The we have:
 
@@ -271,7 +271,7 @@ reset procedure etc).
  o dwmac1000_dma.c:  dma functions for the GMAC chip;
  o dwmac1000.h: specific header file for the GMAC;
  o dwmac100_core: MAC 100 core and dma code;
- o dwmac100_dma.c: dma funtions for the MAC chip;
+ o dwmac100_dma.c: dma functions for the MAC chip;
  o dwmac1000.h: specific header file for the MAC;
  o dwmac_lib.c: generic DMA functions shared among chips;
  o enh_desc.c: functions for handling enhanced descriptors;
@@ -364,4 +364,4 @@ Auto-negotiated Link Parter Ability.
 10) TODO:
  o XGMAC is not supported.
  o Complete the TBI & RTBI support.
- o extened VLAN support for 3.70a SYNP GMAC.
+ o extend VLAN support for 3.70a SYNP GMAC.
diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt
index 9a8041dcbb53..97282da82b75 100644
--- a/Documentation/networking/vortex.txt
+++ b/Documentation/networking/vortex.txt
@@ -68,7 +68,7 @@ Module parameters
 
 There are several parameters which may be provided to the driver when
 its module is loaded.  These are usually placed in /etc/modprobe.d/*.conf
-configuretion files.  Example:
+configuration files.  Example:
 
 options 3c59x debug=3 rx_copybreak=300
 
@@ -178,7 +178,7 @@ max_interrupt_work=N
 
   The driver's interrupt service routine can handle many receive and
   transmit packets in a single invocation.  It does this in a loop. 
-  The value of max_interrupt_work governs how mnay times the interrupt
+  The value of max_interrupt_work governs how many times the interrupt
   service routine will loop.  The default value is 32 loops.  If this
   is exceeded the interrupt service routine gives up and generates a
   warning message "eth0: Too much work in interrupt".
diff --git a/Documentation/networking/x25-iface.txt b/Documentation/networking/x25-iface.txt
index 78f662ee0622..7f213b556e85 100644
--- a/Documentation/networking/x25-iface.txt
+++ b/Documentation/networking/x25-iface.txt
@@ -105,7 +105,7 @@ reduced by the following measures or a combination thereof:
     later.
     The lapb module interface was modified to support this. Its
     data_indication() method should now transparently pass the
-    netif_rx() return value to the (lapb mopdule) caller.
+    netif_rx() return value to the (lapb module) caller.
 (2) Drivers for kernel versions 2.2.x should always check the global
     variable netdev_dropping when a new frame is received. The driver
     should only call netif_rx() if netdev_dropping is zero. Otherwise
diff --git a/Documentation/phy.txt b/Documentation/phy.txt
new file mode 100644
index 000000000000..0103e4b15b0e
--- /dev/null
+++ b/Documentation/phy.txt
@@ -0,0 +1,166 @@
+                            PHY SUBSYSTEM
+                  Kishon Vijay Abraham I <kishon@ti.com>
+
+This document explains the Generic PHY Framework along with the APIs provided,
+and how-to-use.
+
+1. Introduction
+
+*PHY* is the abbreviation for physical layer. It is used to connect a device
+to the physical medium e.g., the USB controller has a PHY to provide functions
+such as serialization, de-serialization, encoding, decoding and is responsible
+for obtaining the required data transmission rate. Note that some USB
+controllers have PHY functionality embedded into it and others use an external
+PHY. Other peripherals that use PHY include Wireless LAN, Ethernet,
+SATA etc.
+
+The intention of creating this framework is to bring the PHY drivers spread
+all over the Linux kernel to drivers/phy to increase code re-use and for
+better code maintainability.
+
+This framework will be of use only to devices that use external PHY (PHY
+functionality is not embedded within the controller).
+
+2. Registering/Unregistering the PHY provider
+
+PHY provider refers to an entity that implements one or more PHY instances.
+For the simple case where the PHY provider implements only a single instance of
+the PHY, the framework provides its own implementation of of_xlate in
+of_phy_simple_xlate. If the PHY provider implements multiple instances, it
+should provide its own implementation of of_xlate. of_xlate is used only for
+dt boot case.
+
+#define of_phy_provider_register(dev, xlate)    \
+        __of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+#define devm_of_phy_provider_register(dev, xlate)       \
+        __devm_of_phy_provider_register((dev), THIS_MODULE, (xlate))
+
+of_phy_provider_register and devm_of_phy_provider_register macros can be used to
+register the phy_provider and it takes device and of_xlate as
+arguments. For the dt boot case, all PHY providers should use one of the above
+2 macros to register the PHY provider.
+
+void devm_of_phy_provider_unregister(struct device *dev,
+        struct phy_provider *phy_provider);
+void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister and of_phy_provider_unregister can be used to
+unregister the PHY.
+
+3. Creating the PHY
+
+The PHY driver should create the PHY in order for other peripheral controllers
+to make use of it. The PHY framework provides 2 APIs to create the PHY.
+
+struct phy *phy_create(struct device *dev, const struct phy_ops *ops,
+        struct phy_init_data *init_data);
+struct phy *devm_phy_create(struct device *dev, const struct phy_ops *ops,
+        struct phy_init_data *init_data);
+
+The PHY drivers can use one of the above 2 APIs to create the PHY by passing
+the device pointer, phy ops and init_data.
+phy_ops is a set of function pointers for performing PHY operations such as
+init, exit, power_on and power_off. *init_data* is mandatory to get a reference
+to the PHY in the case of non-dt boot. See section *Board File Initialization*
+on how init_data should be used.
+
+Inorder to dereference the private data (in phy_ops), the phy provider driver
+can use phy_set_drvdata() after creating the PHY and use phy_get_drvdata() in
+phy_ops to get back the private data.
+
+4. Getting a reference to the PHY
+
+Before the controller can make use of the PHY, it has to get a reference to
+it. This framework provides the following APIs to get a reference to the PHY.
+
+struct phy *phy_get(struct device *dev, const char *string);
+struct phy *devm_phy_get(struct device *dev, const char *string);
+
+phy_get and devm_phy_get can be used to get the PHY. In the case of dt boot,
+the string arguments should contain the phy name as given in the dt data and
+in the case of non-dt boot, it should contain the label of the PHY.
+The only difference between the two APIs is that devm_phy_get associates the
+device with the PHY using devres on successful PHY get. On driver detach,
+release function is invoked on the the devres data and devres data is freed.
+
+5. Releasing a reference to the PHY
+
+When the controller no longer needs the PHY, it has to release the reference
+to the PHY it has obtained using the APIs mentioned in the above section. The
+PHY framework provides 2 APIs to release a reference to the PHY.
+
+void phy_put(struct phy *phy);
+void devm_phy_put(struct device *dev, struct phy *phy);
+
+Both these APIs are used to release a reference to the PHY and devm_phy_put
+destroys the devres associated with this PHY.
+
+6. Destroying the PHY
+
+When the driver that created the PHY is unloaded, it should destroy the PHY it
+created using one of the following 2 APIs.
+
+void phy_destroy(struct phy *phy);
+void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+Both these APIs destroy the PHY and devm_phy_destroy destroys the devres
+associated with this PHY.
+
+7. PM Runtime
+
+This subsystem is pm runtime enabled. So while creating the PHY,
+pm_runtime_enable of the phy device created by this subsystem is called and
+while destroying the PHY, pm_runtime_disable is called. Note that the phy
+device created by this subsystem will be a child of the device that calls
+phy_create (PHY provider device).
+
+So pm_runtime_get_sync of the phy_device created by this subsystem will invoke
+pm_runtime_get_sync of PHY provider device because of parent-child relationship.
+It should also be noted that phy_power_on and phy_power_off performs
+phy_pm_runtime_get_sync and phy_pm_runtime_put respectively.
+There are exported APIs like phy_pm_runtime_get, phy_pm_runtime_get_sync,
+phy_pm_runtime_put, phy_pm_runtime_put_sync, phy_pm_runtime_allow and
+phy_pm_runtime_forbid for performing PM operations.
+
+8. Board File Initialization
+
+Certain board file initialization is necessary in order to get a reference
+to the PHY in the case of non-dt boot.
+Say we have a single device that implements 3 PHYs that of USB, SATA and PCIe,
+then in the board file the following initialization should be done.
+
+struct phy_consumer consumers[] = {
+        PHY_CONSUMER("dwc3.0", "usb"),
+        PHY_CONSUMER("pcie.0", "pcie"),
+        PHY_CONSUMER("sata.0", "sata"),
+};
+PHY_CONSUMER takes 2 parameters, first is the device name of the controller
+(PHY consumer) and second is the port name.
+
+struct phy_init_data init_data = {
+        .consumers = consumers,
+        .num_consumers = ARRAY_SIZE(consumers),
+};
+
+static const struct platform_device pipe3_phy_dev = {
+        .name = "pipe3-phy",
+        .id = -1,
+        .dev = {
+                .platform_data = {
+                        .init_data = &init_data,
+                },
+        },
+};
+
+then, while doing phy_create, the PHY driver should pass this init_data
+        phy_create(dev, ops, pdata->init_data);
+
+and the controller driver (phy consumer) should pass the port name along with
+the device to get a reference to the PHY
+        phy_get(dev, "pcie");
+
+9. DeviceTree Binding
+
+The documentation for PHY dt binding can be found @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt
index c0ffd30eb55e..a7929cb47e7c 100644
--- a/Documentation/pinctrl.txt
+++ b/Documentation/pinctrl.txt
@@ -358,7 +358,12 @@ static struct pinctrl_gpio_range gpio_range = {
         .gc = &chip;
 };
 
-In this case the pin_base property will be ignored.
+In this case the pin_base property will be ignored. If the name of a pin
+group is known, the pins and npins elements of the above structure can be
+initialised using the function pinctrl_get_group_pins(), e.g. for pin
+group "foo":
+
+pinctrl_get_group_pins(pctl, "foo", &gpio_range.pins, &gpio_range.npins);
 
 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
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index 425c51d56aef..b8a907dc0169 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -42,7 +42,7 @@ We can represent these as three OPPs as the following {Hz, uV} tuples:
 
 OPP library provides a set of helper functions to organize and query the OPP
 information. The library is located in drivers/base/power/opp.c and the header
-is located in include/linux/opp.h. OPP library can be enabled by enabling
+is located in include/linux/pm_opp.h. OPP library can be enabled by enabling
 CONFIG_PM_OPP from power management menuconfig menu. OPP library depends on
 CONFIG_PM as certain SoCs such as Texas Instrument's OMAP framework allows to
 optionally boot at a certain OPP without needing cpufreq.
@@ -71,14 +71,14 @@ operations until that OPP could be re-enabled if possible.
 
 OPP library facilitates this concept in it's implementation. The following
 operational functions operate only on available opps:
-opp_find_freq_{ceil, floor}, opp_get_voltage, opp_get_freq, opp_get_opp_count
-and opp_init_cpufreq_table
+opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, dev_pm_opp_get_freq, dev_pm_opp_get_opp_count
+and dev_pm_opp_init_cpufreq_table
 
-opp_find_freq_exact is meant to be used to find the opp pointer which can then
-be used for opp_enable/disable functions to make an opp available as required.
+dev_pm_opp_find_freq_exact is meant to be used to find the opp pointer which can then
+be used for dev_pm_opp_enable/disable functions to make an opp available as required.
 
 WARNING: Users of OPP library should refresh their availability count using
-get_opp_count if opp_enable/disable functions are invoked for a device, the
+get_opp_count if dev_pm_opp_enable/disable functions are invoked for a device, the
 exact mechanism to trigger these or the notification mechanism to other
 dependent subsystems such as cpufreq are left to the discretion of the SoC
 specific framework which uses the OPP library. Similar care needs to be taken
@@ -96,24 +96,24 @@ using RCU read locks. The opp_find_freq_{exact,ceil,floor},
 opp_get_{voltage, freq, opp_count} fall into this category.
 
 opp_{add,enable,disable} are updaters which use mutex and implement it's own
-RCU locking mechanisms. opp_init_cpufreq_table acts as an updater and uses
+RCU locking mechanisms. dev_pm_opp_init_cpufreq_table acts as an updater and uses
 mutex to implment RCU updater strategy. These functions should *NOT* be called
 under RCU locks and other contexts that prevent blocking functions in RCU or
 mutex operations from working.
 
 2. Initial OPP List Registration
 ================================
-The SoC implementation calls opp_add function iteratively to add OPPs per
+The SoC implementation calls dev_pm_opp_add function iteratively to add OPPs per
 device. It is expected that the SoC framework will register the OPP entries
 optimally- typical numbers range to be less than 5. The list generated by
 registering the OPPs is maintained by OPP library throughout the device
 operation. The SoC framework can subsequently control the availability of the
-OPPs dynamically using the opp_enable / disable functions.
+OPPs dynamically using the dev_pm_opp_enable / disable functions.
 
-opp_add - Add a new OPP for a specific domain represented by the device pointer.
+dev_pm_opp_add - Add a new OPP for a specific domain represented by the device pointer.
         The OPP is defined using the frequency and voltage. Once added, the OPP
         is assumed to be available and control of it's availability can be done
-        with the opp_enable/disable functions. OPP library internally stores
+        with the dev_pm_opp_enable/disable functions. OPP library internally stores
         and manages this information in the opp struct. This function may be
         used by SoC framework to define a optimal list as per the demands of
         SoC usage environment.
@@ -124,7 +124,7 @@ opp_add - Add a new OPP for a specific domain represented by the device pointer.
          soc_pm_init()
          {
                 /* Do things */
-                r = opp_add(mpu_dev, 1000000, 900000);
+                r = dev_pm_opp_add(mpu_dev, 1000000, 900000);
                 if (!r) {
                         pr_err("%s: unable to register mpu opp(%d)\n", r);
                         goto no_cpufreq;
@@ -143,44 +143,44 @@ functions return the matching pointer representing the opp if a match is
 found, else returns error. These errors are expected to be handled by standard
 error checks such as IS_ERR() and appropriate actions taken by the caller.
 
-opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
+dev_pm_opp_find_freq_exact - Search for an OPP based on an *exact* frequency and
         availability. This function is especially useful to enable an OPP which
         is not available by default.
         Example: In a case when SoC framework detects a situation where a
         higher frequency could be made available, it can use this function to
-        find the OPP prior to call the opp_enable to actually make it available.
+        find the OPP prior to call the dev_pm_opp_enable to actually make it available.
          rcu_read_lock();
-         opp = opp_find_freq_exact(dev, 1000000000, false);
+         opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false);
          rcu_read_unlock();
          /* dont operate on the pointer.. just do a sanity check.. */
          if (IS_ERR(opp)) {
                 pr_err("frequency not disabled!\n");
                 /* trigger appropriate actions.. */
          } else {
-                opp_enable(dev,1000000000);
+                dev_pm_opp_enable(dev,1000000000);
          }
 
         NOTE: This is the only search function that operates on OPPs which are
         not available.
 
-opp_find_freq_floor - Search for an available OPP which is *at most* the
+dev_pm_opp_find_freq_floor - Search for an available OPP which is *at most* the
         provided frequency. This function is useful while searching for a lesser
         match OR operating on OPP information in the order of decreasing
         frequency.
         Example: To find the highest opp for a device:
          freq = ULONG_MAX;
          rcu_read_lock();
-         opp_find_freq_floor(dev, &freq);
+         dev_pm_opp_find_freq_floor(dev, &freq);
          rcu_read_unlock();
 
-opp_find_freq_ceil - Search for an available OPP which is *at least* the
+dev_pm_opp_find_freq_ceil - Search for an available OPP which is *at least* the
         provided frequency. This function is useful while searching for a
         higher match OR operating on OPP information in the order of increasing
         frequency.
         Example 1: To find the lowest opp for a device:
          freq = 0;
          rcu_read_lock();
-         opp_find_freq_ceil(dev, &freq);
+         dev_pm_opp_find_freq_ceil(dev, &freq);
          rcu_read_unlock();
         Example 2: A simplified implementation of a SoC cpufreq_driver->target:
          soc_cpufreq_target(..)
@@ -188,7 +188,7 @@ opp_find_freq_ceil - Search for an available OPP which is *at least* the
                 /* Do stuff like policy checks etc. */
                 /* Find the best frequency match for the req */
                 rcu_read_lock();
-                opp = opp_find_freq_ceil(dev, &freq);
+                opp = dev_pm_opp_find_freq_ceil(dev, &freq);
                 rcu_read_unlock();
                 if (!IS_ERR(opp))
                         soc_switch_to_freq_voltage(freq);
@@ -208,34 +208,34 @@ as thermal considerations (e.g. don't use OPPx until the temperature drops).
 
 WARNING: Do not use these functions in interrupt context.
 
-opp_enable - Make a OPP available for operation.
+dev_pm_opp_enable - Make a OPP available for operation.
         Example: Lets say that 1GHz OPP is to be made available only if the
         SoC temperature is lower than a certain threshold. The SoC framework
         implementation might choose to do something as follows:
          if (cur_temp < temp_low_thresh) {
                 /* Enable 1GHz if it was disabled */
                 rcu_read_lock();
-                opp = opp_find_freq_exact(dev, 1000000000, false);
+                opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false);
                 rcu_read_unlock();
                 /* just error check */
                 if (!IS_ERR(opp))
-                        ret = opp_enable(dev, 1000000000);
+                        ret = dev_pm_opp_enable(dev, 1000000000);
                 else
                         goto try_something_else;
          }
 
-opp_disable - Make an OPP to be not available for operation
+dev_pm_opp_disable - Make an OPP to be not available for operation
         Example: Lets say that 1GHz OPP is to be disabled if the temperature
         exceeds a threshold value. The SoC framework implementation might
         choose to do something as follows:
          if (cur_temp > temp_high_thresh) {
                 /* Disable 1GHz if it was enabled */
                 rcu_read_lock();
-                opp = opp_find_freq_exact(dev, 1000000000, true);
+                opp = dev_pm_opp_find_freq_exact(dev, 1000000000, true);
                 rcu_read_unlock();
                 /* just error check */
                 if (!IS_ERR(opp))
-                        ret = opp_disable(dev, 1000000000);
+                        ret = dev_pm_opp_disable(dev, 1000000000);
                 else
                         goto try_something_else;
          }
@@ -247,7 +247,7 @@ information from the OPP structure is necessary. Once an OPP pointer is
 retrieved using the search functions, the following functions can be used by SoC
 framework to retrieve the information represented inside the OPP layer.
 
-opp_get_voltage - Retrieve the voltage represented by the opp pointer.
+dev_pm_opp_get_voltage - Retrieve the voltage represented by the opp pointer.
         Example: At a cpufreq transition to a different frequency, SoC
         framework requires to set the voltage represented by the OPP using
         the regulator framework to the Power Management chip providing the
@@ -256,15 +256,15 @@ opp_get_voltage - Retrieve the voltage represented by the opp pointer.
          {
                 /* do things */
                 rcu_read_lock();
-                opp = opp_find_freq_ceil(dev, &freq);
-                v = opp_get_voltage(opp);
+                opp = dev_pm_opp_find_freq_ceil(dev, &freq);
+                v = dev_pm_opp_get_voltage(opp);
                 rcu_read_unlock();
                 if (v)
                         regulator_set_voltage(.., v);
                 /* do other things */
          }
 
-opp_get_freq - Retrieve the freq represented by the opp pointer.
+dev_pm_opp_get_freq - Retrieve the freq represented by the opp pointer.
         Example: Lets say the SoC framework uses a couple of helper functions
         we could pass opp pointers instead of doing additional parameters to
         handle quiet a bit of data parameters.
@@ -273,8 +273,8 @@ opp_get_freq - Retrieve the freq represented by the opp pointer.
                 /* do things.. */
                  max_freq = ULONG_MAX;
                  rcu_read_lock();
-                 max_opp = opp_find_freq_floor(dev,&max_freq);
-                 requested_opp = opp_find_freq_ceil(dev,&freq);
+                 max_opp = dev_pm_opp_find_freq_floor(dev,&max_freq);
+                 requested_opp = dev_pm_opp_find_freq_ceil(dev,&freq);
                  if (!IS_ERR(max_opp) && !IS_ERR(requested_opp))
                         r = soc_test_validity(max_opp, requested_opp);
                  rcu_read_unlock();
@@ -282,25 +282,25 @@ opp_get_freq - Retrieve the freq represented by the opp pointer.
          }
          soc_test_validity(..)
          {
-                 if(opp_get_voltage(max_opp) < opp_get_voltage(requested_opp))
+                 if(dev_pm_opp_get_voltage(max_opp) < dev_pm_opp_get_voltage(requested_opp))
                          return -EINVAL;
-                 if(opp_get_freq(max_opp) < opp_get_freq(requested_opp))
+                 if(dev_pm_opp_get_freq(max_opp) < dev_pm_opp_get_freq(requested_opp))
                          return -EINVAL;
                 /* do things.. */
          }
 
-opp_get_opp_count - Retrieve the number of available opps for a device
+dev_pm_opp_get_opp_count - Retrieve the number of available opps for a device
         Example: Lets say a co-processor in the SoC needs to know the available
         frequencies in a table, the main processor can notify as following:
          soc_notify_coproc_available_frequencies()
          {
                 /* Do things */
                 rcu_read_lock();
-                num_available = opp_get_opp_count(dev);
+                num_available = dev_pm_opp_get_opp_count(dev);
                 speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL);
                 /* populate the table in increasing order */
                 freq = 0;
-                while (!IS_ERR(opp = opp_find_freq_ceil(dev, &freq))) {
+                while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) {
                         speeds[i] = freq;
                         freq++;
                         i++;
@@ -313,7 +313,7 @@ opp_get_opp_count - Retrieve the number of available opps for a device
 
 6. Cpufreq Table Generation
 ===========================
-opp_init_cpufreq_table - cpufreq framework typically is initialized with
+dev_pm_opp_init_cpufreq_table - cpufreq framework typically is initialized with
         cpufreq_frequency_table_cpuinfo which is provided with the list of
         frequencies that are available for operation. This function provides
         a ready to use conversion routine to translate the OPP layer's internal
@@ -326,7 +326,7 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with
          soc_pm_init()
          {
                 /* Do things */
-                r = opp_init_cpufreq_table(dev, &freq_table);
+                r = dev_pm_opp_init_cpufreq_table(dev, &freq_table);
                 if (!r)
                         cpufreq_frequency_table_cpuinfo(policy, freq_table);
                 /* Do other things */
@@ -336,7 +336,7 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with
         addition to CONFIG_PM as power management feature is required to
         dynamically scale voltage and frequency in a system.
 
-opp_free_cpufreq_table - Free up the table allocated by opp_init_cpufreq_table
+dev_pm_opp_free_cpufreq_table - Free up the table allocated by dev_pm_opp_init_cpufreq_table
 
 7. Data Structures
 ==================
@@ -358,16 +358,16 @@ accessed by various functions as described above. However, the structures
 representing the actual OPPs and domains are internal to the OPP library itself
 to allow for suitable abstraction reusable across systems.
 
-struct opp - The internal data structure of OPP library which is used to
+struct dev_pm_opp - The internal data structure of OPP library which is used to
         represent an OPP. In addition to the freq, voltage, availability
         information, it also contains internal book keeping information required
         for the OPP library to operate on.  Pointer to this structure is
         provided back to the users such as SoC framework to be used as a
         identifier for OPP in the interactions with OPP layer.
 
-        WARNING: The struct opp pointer should not be parsed or modified by the
-        users. The defaults of for an instance is populated by opp_add, but the
-        availability of the OPP can be modified by opp_enable/disable functions.
+        WARNING: The struct dev_pm_opp pointer should not be parsed or modified by the
+        users. The defaults of for an instance is populated by dev_pm_opp_add, but the
+        availability of the OPP can be modified by dev_pm_opp_enable/disable functions.
 
 struct device - This is used to identify a domain to the OPP layer. The
         nature of the device and it's implementation is left to the user of
@@ -377,19 +377,19 @@ Overall, in a simplistic view, the data structure operations is represented as
 following:
 
 Initialization / modification:
-            +-----+        /- opp_enable
-opp_add --> | opp | <-------
-  |         +-----+        \- opp_disable
+            +-----+        /- dev_pm_opp_enable
+dev_pm_opp_add --> | opp | <-------
+  |         +-----+        \- dev_pm_opp_disable
   \-------> domain_info(device)
 
 Search functions:
-             /-- opp_find_freq_ceil  ---\   +-----+
-domain_info<---- opp_find_freq_exact -----> | opp |
-             \-- opp_find_freq_floor ---/   +-----+
+             /-- dev_pm_opp_find_freq_ceil  ---\   +-----+
+domain_info<---- dev_pm_opp_find_freq_exact -----> | opp |
+             \-- dev_pm_opp_find_freq_floor ---/   +-----+
 
 Retrieval functions:
-+-----+     /- opp_get_voltage
++-----+     /- dev_pm_opp_get_voltage
 | opp | <---
-+-----+     \- opp_get_freq
++-----+     \- dev_pm_opp_get_freq
 
-domain_info <- opp_get_opp_count
+domain_info <- dev_pm_opp_get_opp_count
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt
index 3f10b39b0346..89a8816990ff 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -135,11 +135,11 @@ CAPACITY_LEVEL - capacity level. This corresponds to
 POWER_SUPPLY_CAPACITY_LEVEL_*.
 
 TEMP - temperature of the power supply.
-TEMP_ALERT_MIN - minimum battery temperature alert value in milli centigrade.
-TEMP_ALERT_MAX - maximum battery temperature alert value in milli centigrade.
+TEMP_ALERT_MIN - minimum battery temperature alert.
+TEMP_ALERT_MAX - maximum battery temperature alert.
 TEMP_AMBIENT - ambient temperature.
-TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert value in milli centigrade.
-TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert value in milli centigrade.
+TEMP_AMBIENT_ALERT_MIN - minimum ambient temperature alert.
+TEMP_AMBIENT_ALERT_MAX - maximum ambient temperature alert.
 
 TIME_TO_EMPTY - seconds left for battery to be considered empty (i.e.
 while battery powers a load)
diff --git a/Documentation/power/powercap/powercap.txt b/Documentation/power/powercap/powercap.txt
new file mode 100644
index 000000000000..1e6ef164e07a
--- /dev/null
+++ b/Documentation/power/powercap/powercap.txt
@@ -0,0 +1,236 @@
+Power Capping Framework
+==================================
+
+The power capping framework provides a consistent interface between the kernel
+and the user space that allows power capping drivers to expose the settings to
+user space in a uniform way.
+
+Terminology
+=========================
+The framework exposes power capping devices to user space via sysfs in the
+form of a tree of objects. The objects at the root level of the tree represent
+'control types', which correspond to different methods of power capping.  For
+example, the intel-rapl control type represents the Intel "Running Average
+Power Limit" (RAPL) technology, whereas the 'idle-injection' control type
+corresponds to the use of idle injection for controlling power.
+
+Power zones represent different parts of the system, which can be controlled and
+monitored using the power capping method determined by the control type the
+given zone belongs to. They each contain attributes for monitoring power, as
+well as controls represented in the form of power constraints.  If the parts of
+the system represented by different power zones are hierarchical (that is, one
+bigger part consists of multiple smaller parts that each have their own power
+controls), those power zones may also be organized in a hierarchy with one
+parent power zone containing multiple subzones and so on to reflect the power
+control topology of the system.  In that case, it is possible to apply power
+capping to a set of devices together using the parent power zone and if more
+fine grained control is required, it can be applied through the subzones.
+
+
+Example sysfs interface tree:
+
+/sys/devices/virtual/powercap
+??? intel-rapl
+    ??? intel-rapl:0
+    ?   ??? constraint_0_name
+    ?   ??? constraint_0_power_limit_uw
+    ?   ??? constraint_0_time_window_us
+    ?   ??? constraint_1_name
+    ?   ??? constraint_1_power_limit_uw
+    ?   ??? constraint_1_time_window_us
+    ?   ??? device -> ../../intel-rapl
+    ?   ??? energy_uj
+    ?   ??? intel-rapl:0:0
+    ?   ?   ??? constraint_0_name
+    ?   ?   ??? constraint_0_power_limit_uw
+    ?   ?   ??? constraint_0_time_window_us
+    ?   ?   ??? constraint_1_name
+    ?   ?   ??? constraint_1_power_limit_uw
+    ?   ?   ??? constraint_1_time_window_us
+    ?   ?   ??? device -> ../../intel-rapl:0
+    ?   ?   ??? energy_uj
+    ?   ?   ??? max_energy_range_uj
+    ?   ?   ??? name
+    ?   ?   ??? enabled
+    ?   ?   ??? power
+    ?   ?   ?   ??? async
+    ?   ?   ?   []
+    ?   ?   ??? subsystem -> ../../../../../../class/power_cap
+    ?   ?   ??? uevent
+    ?   ??? intel-rapl:0:1
+    ?   ?   ??? constraint_0_name
+    ?   ?   ??? constraint_0_power_limit_uw
+    ?   ?   ??? constraint_0_time_window_us
+    ?   ?   ??? constraint_1_name
+    ?   ?   ??? constraint_1_power_limit_uw
+    ?   ?   ??? constraint_1_time_window_us
+    ?   ?   ??? device -> ../../intel-rapl:0
+    ?   ?   ??? energy_uj
+    ?   ?   ??? max_energy_range_uj
+    ?   ?   ??? name
+    ?   ?   ??? enabled
+    ?   ?   ??? power
+    ?   ?   ?   ??? async
+    ?   ?   ?   []
+    ?   ?   ??? subsystem -> ../../../../../../class/power_cap
+    ?   ?   ??? uevent
+    ?   ??? max_energy_range_uj
+    ?   ??? max_power_range_uw
+    ?   ??? name
+    ?   ??? enabled
+    ?   ??? power
+    ?   ?   ??? async
+    ?   ?   []
+    ?   ??? subsystem -> ../../../../../class/power_cap
+    ?   ??? enabled
+    ?   ??? uevent
+    ??? intel-rapl:1
+    ?   ??? constraint_0_name
+    ?   ??? constraint_0_power_limit_uw
+    ?   ??? constraint_0_time_window_us
+    ?   ??? constraint_1_name
+    ?   ??? constraint_1_power_limit_uw
+    ?   ??? constraint_1_time_window_us
+    ?   ??? device -> ../../intel-rapl
+    ?   ??? energy_uj
+    ?   ??? intel-rapl:1:0
+    ?   ?   ??? constraint_0_name
+    ?   ?   ??? constraint_0_power_limit_uw
+    ?   ?   ??? constraint_0_time_window_us
+    ?   ?   ??? constraint_1_name
+    ?   ?   ??? constraint_1_power_limit_uw
+    ?   ?   ??? constraint_1_time_window_us
+    ?   ?   ??? device -> ../../intel-rapl:1
+    ?   ?   ??? energy_uj
+    ?   ?   ??? max_energy_range_uj
+    ?   ?   ??? name
+    ?   ?   ??? enabled
+    ?   ?   ??? power
+    ?   ?   ?   ??? async
+    ?   ?   ?   []
+    ?   ?   ??? subsystem -> ../../../../../../class/power_cap
+    ?   ?   ??? uevent
+    ?   ??? intel-rapl:1:1
+    ?   ?   ??? constraint_0_name
+    ?   ?   ??? constraint_0_power_limit_uw
+    ?   ?   ??? constraint_0_time_window_us
+    ?   ?   ??? constraint_1_name
+    ?   ?   ??? constraint_1_power_limit_uw
+    ?   ?   ??? constraint_1_time_window_us
+    ?   ?   ??? device -> ../../intel-rapl:1
+    ?   ?   ??? energy_uj
+    ?   ?   ??? max_energy_range_uj
+    ?   ?   ??? name
+    ?   ?   ??? enabled
+    ?   ?   ??? power
+    ?   ?   ?   ??? async
+    ?   ?   ?   []
+    ?   ?   ??? subsystem -> ../../../../../../class/power_cap
+    ?   ?   ??? uevent
+    ?   ??? max_energy_range_uj
+    ?   ??? max_power_range_uw
+    ?   ??? name
+    ?   ??? enabled
+    ?   ??? power
+    ?   ?   ??? async
+    ?   ?   []
+    ?   ??? subsystem -> ../../../../../class/power_cap
+    ?   ??? uevent
+    ??? power
+    ?   ??? async
+    ?   []
+    ??? subsystem -> ../../../../class/power_cap
+    ??? enabled
+    ??? uevent
+
+The above example illustrates a case in which the Intel RAPL technology,
+available in Intel® IA-64 and IA-32 Processor Architectures, is used. There is one
+control type called intel-rapl which contains two power zones, intel-rapl:0 and
+intel-rapl:1, representing CPU packages.  Each of these power zones contains
+two subzones, intel-rapl:j:0 and intel-rapl:j:1 (j = 0, 1), representing the
+"core" and the "uncore" parts of the given CPU package, respectively.  All of
+the zones and subzones contain energy monitoring attributes (energy_uj,
+max_energy_range_uj) and constraint attributes (constraint_*) allowing controls
+to be applied (the constraints in the 'package' power zones apply to the whole
+CPU packages and the subzone constraints only apply to the respective parts of
+the given package individually). Since Intel RAPL doesn't provide instantaneous
+power value, there is no power_uw attribute.
+
+In addition to that, each power zone contains a name attribute, allowing the
+part of the system represented by that zone to be identified.
+For example:
+
+cat /sys/class/power_cap/intel-rapl/intel-rapl:0/name
+package-0
+
+The Intel RAPL technology allows two constraints, short term and long term,
+with two different time windows to be applied to each power zone.  Thus for
+each zone there are 2 attributes representing the constraint names, 2 power
+limits and 2 attributes representing the sizes of the time windows. Such that,
+constraint_j_* attributes correspond to the jth constraint (j = 0,1).
+
+For example:
+        constraint_0_name
+        constraint_0_power_limit_uw
+        constraint_0_time_window_us
+        constraint_1_name
+        constraint_1_power_limit_uw
+        constraint_1_time_window_us
+
+Power Zone Attributes
+=================================
+Monitoring attributes
+----------------------
+
+energy_uj (rw): Current energy counter in micro joules. Write "0" to reset.
+If the counter can not be reset, then this attribute is read only.
+
+max_energy_range_uj (ro): Range of the above energy counter in micro-joules.
+
+power_uw (ro): Current power in micro watts.
+
+max_power_range_uw (ro): Range of the above power value in micro-watts.
+
+name (ro): Name of this power zone.
+
+It is possible that some domains have both power ranges and energy counter ranges;
+however, only one is mandatory.
+
+Constraints
+----------------
+constraint_X_power_limit_uw (rw): Power limit in micro watts, which should be
+applicable for the time window specified by "constraint_X_time_window_us".
+
+constraint_X_time_window_us (rw): Time window in micro seconds.
+
+constraint_X_name (ro): An optional name of the constraint
+
+constraint_X_max_power_uw(ro): Maximum allowed power in micro watts.
+
+constraint_X_min_power_uw(ro): Minimum allowed power in micro watts.
+
+constraint_X_max_time_window_us(ro): Maximum allowed time window in micro seconds.
+
+constraint_X_min_time_window_us(ro): Minimum allowed time window in micro seconds.
+
+Except power_limit_uw and time_window_us other fields are optional.
+
+Common zone and control type attributes
+----------------------------------------
+enabled (rw): Enable/Disable controls at zone level or for all zones using
+a control type.
+
+Power Cap Client Driver Interface
+==================================
+The API summary:
+
+Call powercap_register_control_type() to register control type object.
+Call powercap_register_zone() to register a power zone (under a given
+control type), either as a top-level power zone or as a subzone of another
+power zone registered earlier.
+The number of constraints in a power zone and the corresponding callbacks have
+to be defined prior to calling powercap_register_zone() to register that zone.
+
+To Free a power zone call powercap_unregister_zone().
+To free a control type object call powercap_unregister_control_type().
+Detailed API can be generated using kernel-doc on include/linux/powercap.h.
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 71d8fe4e75d3..b6ce00b2be9a 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -145,11 +145,13 @@ The action performed by the idle callback is totally dependent on the subsystem
 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.  If there is no idle callback, or if the callback returns
-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.
+0, then the PM core will attempt to carry out a runtime suspend of the device,
+also respecting devices configured for autosuspend.  In essence this means a
+call to pm_runtime_autosuspend() (do note that drivers needs to update the
+device last busy mark, pm_runtime_mark_last_busy(), to control the delay under
+this circumstance).  To prevent this (for example, if the callback routine has
+started a delayed suspend), the routine must 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
@@ -308,7 +310,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
     - execute the subsystem-level idle callback for the device; returns an
       error code on failure, where -EINPROGRESS means that ->runtime_idle() is
       already being executed; if there is no callback or the callback returns 0
-      then run pm_runtime_suspend(dev) and return its result
+      then run pm_runtime_autosuspend(dev) and return its result
 
   int pm_runtime_suspend(struct device *dev);
     - execute the subsystem-level suspend callback for the device; returns 0 on
@@ -545,13 +547,11 @@ helper functions described in Section 4.  In that case, pm_runtime_resume()
 should be used.  Of course, for this purpose the device's runtime PM has to be
 enabled earlier by calling pm_runtime_enable().
 
-If the device bus type's or driver's ->probe() callback runs
-pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,
-they will fail returning -EAGAIN, because the device's usage counter is
-incremented by the driver core before executing ->probe().  Still, it may be
-desirable to suspend the device as soon as ->probe() has finished, so the driver
-core uses pm_runtime_put_sync() to invoke the subsystem-level idle callback for
-the device at that time.
+It may be desirable to suspend the device once ->probe() has finished.
+Therefore the driver core uses the asyncronous pm_request_idle() to submit a
+request to execute the subsystem-level idle callback for the device at that
+time.  A driver that makes use of the runtime autosuspend feature, may want to
+update the last busy mark before returning from ->probe().
 
 Moreover, the driver core prevents runtime PM callbacks from racing with the bus
 notifier callback in __device_release_driver(), which is necessary, because the
@@ -654,7 +654,7 @@ out the following operations:
     __pm_runtime_disable() with 'false' as the second argument for every device
     right before executing the subsystem-level .suspend_late() callback for it.
 
-  * During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
+  * During system resume it calls pm_runtime_enable() and pm_runtime_put()
     for every device right after executing the subsystem-level .resume_early()
     callback and right after executing the subsystem-level .resume() callback
     for it, respectively.
diff --git a/Documentation/pps/pps.txt b/Documentation/pps/pps.txt
index d35dcdd82ff6..c03b1be5eb15 100644
--- a/Documentation/pps/pps.txt
+++ b/Documentation/pps/pps.txt
@@ -66,6 +66,21 @@ In LinuxPPS the PPS sources are simply char devices usually mapped
 into files /dev/pps0, /dev/pps1, etc..
 
 
+PPS with USB to serial devices
+------------------------------
+
+It is possible to grab the PPS from an USB to serial device. However,
+you should take into account the latencies and jitter introduced by
+the USB stack. Users has reported clock instability around +-1ms when
+synchronized with PPS through USB. This isn't suited for time server
+synchronization.
+
+If your device doesn't report PPS, you can check that the feature is
+supported by its driver. Most of the time, you only need to add a call
+to usb_serial_handle_dcd_change after checking the DCD status (see
+ch341 and pl2303 examples).
+
+
 Coding example
 --------------
 
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index f59ded066108..a74d0a84d329 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -100,6 +100,11 @@ static long ppb_to_scaled_ppm(int ppb)
         return (long) (ppb * 65.536);
 }
 
+static int64_t pctns(struct ptp_clock_time *t)
+{
+        return t->sec * 1000000000LL + t->nsec;
+}
+
 static void usage(char *progname)
 {
         fprintf(stderr,
@@ -112,6 +117,8 @@ static void usage(char *progname)
                 " -f val     adjust the ptp clock frequency by 'val' ppb\n"
                 " -g         get the ptp clock time\n"
                 " -h         prints this message\n"
+                " -k val     measure the time offset between system and phc clock\n"
+                "            for 'val' times (Maximum 25)\n"
                 " -p val     enable output with a period of 'val' nanoseconds\n"
                 " -P val     enable or disable (val=1|0) the system clock PPS\n"
                 " -s         set the ptp clock time from the system time\n"
@@ -133,8 +140,12 @@ int main(int argc, char *argv[])
         struct itimerspec timeout;
         struct sigevent sigevent;
 
+        struct ptp_clock_time *pct;
+        struct ptp_sys_offset *sysoff;
+
+
         char *progname;
-        int c, cnt, fd;
+        int i, c, cnt, fd;
 
         char *device = DEVICE;
         clockid_t clkid;
@@ -144,14 +155,19 @@ int main(int argc, char *argv[])
         int extts = 0;
         int gettime = 0;
         int oneshot = 0;
+        int pct_offset = 0;
+        int n_samples = 0;
         int periodic = 0;
         int perout = -1;
         int pps = -1;
         int settime = 0;
 
+        int64_t t1, t2, tp;
+        int64_t interval, offset;
+
         progname = strrchr(argv[0], '/');
         progname = progname ? 1+progname : argv[0];
-        while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghp:P:sSt:v"))) {
+        while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghk:p:P:sSt:v"))) {
                 switch (c) {
                 case 'a':
                         oneshot = atoi(optarg);
@@ -174,6 +190,10 @@ int main(int argc, char *argv[])
                 case 'g':
                         gettime = 1;
                         break;
+                case 'k':
+                        pct_offset = 1;
+                        n_samples = atoi(optarg);
+                        break;
                 case 'p':
                         perout = atoi(optarg);
                         break;
@@ -376,6 +396,47 @@ int main(int argc, char *argv[])
                 }
         }
 
+        if (pct_offset) {
+                if (n_samples <= 0 || n_samples > 25) {
+                        puts("n_samples should be between 1 and 25");
+                        usage(progname);
+                        return -1;
+                }
+
+                sysoff = calloc(1, sizeof(*sysoff));
+                if (!sysoff) {
+                        perror("calloc");
+                        return -1;
+                }
+                sysoff->n_samples = n_samples;
+
+                if (ioctl(fd, PTP_SYS_OFFSET, sysoff))
+                        perror("PTP_SYS_OFFSET");
+                else
+                        puts("system and phc clock time offset request okay");
+
+                pct = &sysoff->ts[0];
+                for (i = 0; i < sysoff->n_samples; i++) {
+                        t1 = pctns(pct+2*i);
+                        tp = pctns(pct+2*i+1);
+                        t2 = pctns(pct+2*i+2);
+                        interval = t2 - t1;
+                        offset = (t2 + t1) / 2 - tp;
+
+                        printf("system time: %ld.%ld\n",
+                                (pct+2*i)->sec, (pct+2*i)->nsec);
+                        printf("phc    time: %ld.%ld\n",
+                                (pct+2*i+1)->sec, (pct+2*i+1)->nsec);
+                        printf("system time: %ld.%ld\n",
+                                (pct+2*i+2)->sec, (pct+2*i+2)->nsec);
+                        printf("system/phc clock time offset is %ld ns\n"
+                                "system     clock time delay  is %ld ns\n",
+                                offset, interval);
+                }
+
+                free(sysoff);
+        }
+
         close(fd);
         return 0;
 }
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 1039b68fe9c6..93cb97974986 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -39,7 +39,7 @@ New users should use the pwm_get() function and pass to it the consumer
 device or a consumer name. pwm_put() is used to free the PWM device. Managed
 variants of these functions, devm_pwm_get() and devm_pwm_put(), also exist.
 
-After being requested a PWM has to be configured using:
+After being requested, a PWM has to be configured using:
 
 int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns);
 
@@ -94,7 +94,7 @@ for new drivers to use the generic PWM framework.
 A new PWM controller/chip can be added using pwmchip_add() and removed
 again with pwmchip_remove(). pwmchip_add() takes a filled in struct
 pwm_chip as argument which provides a description of the PWM chip, the
-number of PWM devices provider by the chip and the chip-specific
+number of PWM devices provided by the chip and the chip-specific
 implementation of the supported PWM operations to the framework.
 
 Locking
diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt
index fcaf0b4efba2..3da163383c93 100644
--- a/Documentation/s390/s390dbf.txt
+++ b/Documentation/s390/s390dbf.txt
@@ -158,6 +158,16 @@ Return Value:  none
 Description:   Sets new actual debug level if new_level is valid. 
 
 ---------------------------------------------------------------------------
+bool debug_level_enabled (debug_info_t * id, int level);
+
+Parameter:    id:         handle for debug log
+              level:      debug level
+
+Return Value: True if level is less or equal to the current debug level.
+
+Description:  Returns true if debug events for the specified level would be
+              logged. Otherwise returns false.
+---------------------------------------------------------------------------
 void debug_stop_all(void);
 
 Parameter:     none
diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt
index b1b8587b86f0..9290de703450 100644
--- a/Documentation/scheduler/sched-arch.txt
+++ b/Documentation/scheduler/sched-arch.txt
@@ -65,11 +65,6 @@ Possible arch/ problems
 
 Possible arch problems I found (and either tried to fix or didn't):
 
-h8300 - Is such sleeping racy vs interrupts? (See #4a).
-        The H8/300 manual I found indicates yes, however disabling IRQs
-        over the sleep mean only NMIs can wake it up, so can't fix easily
-        without doing spin waiting.
-
 ia64 - is safe_halt call racy vs interrupts? (does it sleep?) (See #4a)
 
 sh64 - Is sleeping racy vs interrupts? (See #4a)
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index 414235c1fcfc..45c82fd3e9d3 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -22,3 +22,5 @@ keys.txt
         - description of the kernel key retention service.
 tomoyo.txt
         - documentation on the TOMOYO Linux Security Module.
+IMA-templates.txt
+        - documentation on the template management mechanism for IMA.
diff --git a/Documentation/security/IMA-templates.txt b/Documentation/security/IMA-templates.txt
new file mode 100644
index 000000000000..a777e5f1df5b
--- /dev/null
+++ b/Documentation/security/IMA-templates.txt
@@ -0,0 +1,87 @@
+                       IMA Template Management Mechanism
+
+
+==== INTRODUCTION ====
+
+The original 'ima' template is fixed length, containing the filedata hash
+and pathname. The filedata hash is limited to 20 bytes (md5/sha1).
+The pathname is a null terminated string, limited to 255 characters.
+To overcome these limitations and to add additional file metadata, it is
+necessary to extend the current version of IMA by defining additional
+templates. For example, information that could be possibly reported are
+the inode UID/GID or the LSM labels either of the inode and of the process
+that is accessing it.
+
+However, the main problem to introduce this feature is that, each time
+a new template is defined, the functions that generate and display
+the measurements list would include the code for handling a new format
+and, thus, would significantly grow over the time.
+
+The proposed solution solves this problem by separating the template
+management from the remaining IMA code. The core of this solution is the
+definition of two new data structures: a template descriptor, to determine
+which information should be included in the measurement list; a template
+field, to generate and display data of a given type.
+
+Managing templates with these structures is very simple. To support
+a new data type, developers define the field identifier and implement
+two functions, init() and show(), respectively to generate and display
+measurement entries. Defining a new template descriptor requires
+specifying the template format, a string of field identifiers separated
+by the '|' character. While in the current implementation it is possible
+to define new template descriptors only by adding their definition in the
+template specific code (ima_template.c), in a future version it will be
+possible to register a new template on a running kernel by supplying to IMA
+the desired format string. In this version, IMA initializes at boot time
+all defined template descriptors by translating the format into an array
+of template fields structures taken from the set of the supported ones.
+
+After the initialization step, IMA will call ima_alloc_init_template()
+(new function defined within the patches for the new template management
+mechanism) to generate a new measurement entry by using the template
+descriptor chosen through the kernel configuration or through the newly
+introduced 'ima_template=' kernel command line parameter. It is during this
+phase that the advantages of the new architecture are clearly shown:
+the latter function will not contain specific code to handle a given template
+but, instead, it simply calls the init() method of the template fields
+associated to the chosen template descriptor and store the result (pointer
+to allocated data and data length) in the measurement entry structure.
+
+The same mechanism is employed to display measurements entries.
+The functions ima[_ascii]_measurements_show() retrieve, for each entry,
+the template descriptor used to produce that entry and call the show()
+method for each item of the array of template fields structures.
+
+
+
+==== SUPPORTED TEMPLATE FIELDS AND DESCRIPTORS ====
+
+In the following, there is the list of supported template fields
+('<identifier>': description), that can be used to define new template
+descriptors by adding their identifier to the format string
+(support for more data types will be added later):
+
+ - 'd': the digest of the event (i.e. the digest of a measured file),
+        calculated with the SHA1 or MD5 hash algorithm;
+ - 'n': the name of the event (i.e. the file name), with size up to 255 bytes;
+ - 'd-ng': the digest of the event, calculated with an arbitrary hash
+           algorithm (field format: [<hash algo>:]digest, where the digest
+           prefix is shown only if the hash algorithm is not SHA1 or MD5);
+ - 'n-ng': the name of the event, without size limitations.
+
+
+Below, there is the list of defined template descriptors:
+ - "ima": its format is 'd|n';
+ - "ima-ng" (default): its format is 'd-ng|n-ng'.
+
+
+
+==== USE ====
+
+To specify the template descriptor to be used to generate measurement entries,
+currently the following methods are supported:
+
+ - select a template descriptor among those supported in the kernel
+   configuration ('ima-ng' is the default choice);
+ - specify a template descriptor name from the kernel command line through
+   the 'ima_template=' parameter.
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index 7b4145d00452..a4c33f1a7c6d 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -865,15 +865,14 @@ encountered:
      calling processes has a searchable link to the key from one of its
      keyrings. There are three functions for dealing with these:
 
-        key_ref_t make_key_ref(const struct key *key,
-                               unsigned long possession);
+        key_ref_t make_key_ref(const struct key *key, bool possession);
 
         struct key *key_ref_to_ptr(const key_ref_t key_ref);
 
-        unsigned long is_key_possessed(const key_ref_t key_ref);
+        bool is_key_possessed(const key_ref_t key_ref);
 
      The first function constructs a key reference from a key pointer and
-     possession information (which must be 0 or 1 and not any other value).
+     possession information (which must be true or false).
 
      The second function retrieves the key pointer from a reference and the
      third retrieves the possession flag.
@@ -961,14 +960,17 @@ payload contents" for more information.
     the argument will not be parsed.
 
 
-(*) Extra references can be made to a key by calling the following function:
+(*) Extra references can be made to a key by calling one of the following
+    functions:
 
+        struct key *__key_get(struct key *key);
         struct key *key_get(struct key *key);
 
-    These need to be disposed of by calling key_put() when they've been
-    finished with. The key pointer passed in will be returned. If the pointer
-    is NULL or CONFIG_KEYS is not set then the key will not be dereferenced and
-    no increment will take place.
+    Keys so references will need to be disposed of by calling key_put() when
+    they've been finished with.  The key pointer passed in will be returned.
+
+    In the case of key_get(), if the pointer is NULL or CONFIG_KEYS is not set
+    then the key will not be dereferenced and no increment will take place.
 
 
 (*) A key's serial number can be obtained by calling:
diff --git a/Documentation/serial/driver b/Documentation/serial/driver
index 067c47d46917..c3a7689a90e6 100644
--- a/Documentation/serial/driver
+++ b/Documentation/serial/driver
@@ -264,10 +264,6 @@ hardware.
         Locking: none.
         Interrupts: caller dependent.
 
-  set_wake(port,state)
-        Enable/disable power management wakeup on serial activity.  Not
-        currently implemented.
-
   type(port)
         Return a pointer to a string constant describing the specified
         port, or return NULL, in which case the string 'unknown' is
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 95731a08f257..b8dd0df76952 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -616,7 +616,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
 
     As default, snd-dummy drivers doesn't allocate the real buffers
     but either ignores read/write or mmap a single dummy page to all
-    buffer pages, in order to save the resouces.  If your apps need
+    buffer pages, in order to save the resources.  If your apps need
     the read/ written buffer data to be consistent, pass fake_buffer=0
     option.
 
diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt
index 654dd3b694a8..e7a5ed4dcae8 100644
--- a/Documentation/sound/alsa/Audiophile-Usb.txt
+++ b/Documentation/sound/alsa/Audiophile-Usb.txt
@@ -232,7 +232,7 @@ The parameter can be given:
    # modprobe snd-usb-audio index=1 device_setup=0x09
 
  * Or while configuring the modules options in your modules configuration file
-   (tipically a .conf file in /etc/modprobe.d/ directory:
+   (typically a .conf file in /etc/modprobe.d/ directory:
        alias snd-card-1 snd-usb-audio
        options snd-usb-audio index=1 device_setup=0x09
 
diff --git a/Documentation/sound/alsa/CMIPCI.txt b/Documentation/sound/alsa/CMIPCI.txt
index 16935c8561f7..4e36e6e809ca 100644
--- a/Documentation/sound/alsa/CMIPCI.txt
+++ b/Documentation/sound/alsa/CMIPCI.txt
@@ -87,7 +87,7 @@ with 4 channels,
 
 and use the interleaved 4 channel data.
 
-There are some control switchs affecting to the speaker connections:
+There are some control switches affecting to the speaker connections:
 
 "Line-In Mode"  - an enum control to change the behavior of line-in
         jack.  Either "Line-In", "Rear Output" or "Bass Output" can
diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt
index f911e3656209..85c362d8ea34 100644
--- a/Documentation/sound/alsa/HD-Audio-Models.txt
+++ b/Documentation/sound/alsa/HD-Audio-Models.txt
@@ -28,6 +28,7 @@ ALC269/270/275/276/28x/29x
   alc269-dmic           Enable ALC269(VA) digital mic workaround
   alc271-dmic           Enable ALC271X digital mic workaround
   inv-dmic              Inverted internal mic workaround
+  headset-mic           Indicates a combined headset (headphone+mic) jack
   lenovo-dock           Enables docking station I/O for some Lenovos
   dell-headset-multi    Headset jack, which can also be used as mic-in
   dell-headset-dock     Headset jack (without mic-in), and also dock I/O
diff --git a/Documentation/sound/alsa/compress_offload.txt b/Documentation/sound/alsa/compress_offload.txt
index fd74ff26376e..630c492c3dc2 100644
--- a/Documentation/sound/alsa/compress_offload.txt
+++ b/Documentation/sound/alsa/compress_offload.txt
@@ -217,12 +217,12 @@ Not supported:
   would be enabled with ALSA kcontrols.
 
 - Audio policy/resource management. This API does not provide any
-  hooks to query the utilization of the audio DSP, nor any premption
+  hooks to query the utilization of the audio DSP, nor any preemption
   mechanisms.
 
-- No notion of underun/overrun. Since the bytes written are compressed
+- No notion of underrun/overrun. Since the bytes written are compressed
   in nature and data written/read doesn't translate directly to
-  rendered output in time, this does not deal with underrun/overun and
+  rendered output in time, this does not deal with underrun/overrun and
   maybe dealt in user-library
 
 Credits:
diff --git a/Documentation/sound/alsa/soc/DPCM.txt b/Documentation/sound/alsa/soc/DPCM.txt
new file mode 100644
index 000000000000..0110180b7ac6
--- /dev/null
+++ b/Documentation/sound/alsa/soc/DPCM.txt
@@ -0,0 +1,380 @@
+Dynamic PCM
+===========
+
+1. Description
+==============
+
+Dynamic PCM allows an ALSA PCM device to digitally route its PCM audio to
+various digital endpoints during the PCM stream runtime. e.g. PCM0 can route
+digital audio to I2S DAI0, I2S DAI1 or PDM DAI2. This is useful for on SoC DSP
+drivers that expose several ALSA PCMs and can route to multiple DAIs.
+
+The DPCM runtime routing is determined by the ALSA mixer settings in the same
+way as the analog signal is routed in an ASoC codec driver. DPCM uses a DAPM
+graph representing the DSP internal audio paths and uses the mixer settings to
+determine the patch used by each ALSA PCM.
+
+DPCM re-uses all the existing component codec, platform and DAI drivers without
+any modifications.
+
+
+Phone Audio System with SoC based DSP
+-------------------------------------
+
+Consider the following phone audio subsystem. This will be used in this
+document for all examples :-
+
+| Front End PCMs    |  SoC DSP  | Back End DAIs | Audio devices |
+
+                    *************
+PCM0 <------------> *           * <----DAI0-----> Codec Headset
+                    *           *
+PCM1 <------------> *           * <----DAI1-----> Codec Speakers
+                    *   DSP     *
+PCM2 <------------> *           * <----DAI2-----> MODEM
+                    *           *
+PCM3 <------------> *           * <----DAI3-----> BT
+                    *           *
+                    *           * <----DAI4-----> DMIC
+                    *           *
+                    *           * <----DAI5-----> FM
+                    *************
+
+This diagram shows a simple smart phone audio subsystem. It supports Bluetooth,
+FM digital radio, Speakers, Headset Jack, digital microphones and cellular
+modem. This sound card exposes 4 DSP front end (FE) ALSA PCM devices and
+supports 6 back end (BE) DAIs. Each FE PCM can digitally route audio data to any
+of the BE DAIs. The FE PCM devices can also route audio to more than 1 BE DAI.
+
+
+
+Example - DPCM Switching playback from DAI0 to DAI1
+---------------------------------------------------
+
+Audio is being played to the Headset. After a while the user removes the headset
+and audio continues playing on the speakers.
+
+Playback on PCM0 to Headset would look like :-
+
+                    *************
+PCM0 <============> *           * <====DAI0=====> Codec Headset
+                    *           *
+PCM1 <------------> *           * <----DAI1-----> Codec Speakers
+                    *   DSP     *
+PCM2 <------------> *           * <----DAI2-----> MODEM
+                    *           *
+PCM3 <------------> *           * <----DAI3-----> BT
+                    *           *
+                    *           * <----DAI4-----> DMIC
+                    *           *
+                    *           * <----DAI5-----> FM
+                    *************
+
+The headset is removed from the jack by user so the speakers must now be used :-
+
+                    *************
+PCM0 <============> *           * <----DAI0-----> Codec Headset
+                    *           *
+PCM1 <------------> *           * <====DAI1=====> Codec Speakers
+                    *   DSP     *
+PCM2 <------------> *           * <----DAI2-----> MODEM
+                    *           *
+PCM3 <------------> *           * <----DAI3-----> BT
+                    *           *
+                    *           * <----DAI4-----> DMIC
+                    *           *
+                    *           * <----DAI5-----> FM
+                    *************
+
+The audio driver processes this as follows :-
+
+ 1) Machine driver receives Jack removal event.
+
+ 2) Machine driver OR audio HAL disables the Headset path.
+
+ 3) DPCM runs the PCM trigger(stop), hw_free(), shutdown() operations on DAI0
+    for headset since the path is now disabled.
+
+ 4) Machine driver or audio HAL enables the speaker path.
+
+ 5) DPCM runs the PCM ops for startup(), hw_params(), prepapre() and
+    trigger(start) for DAI1 Speakers since the path is enabled.
+
+In this example, the machine driver or userspace audio HAL can alter the routing
+and then DPCM will take care of managing the DAI PCM operations to either bring
+the link up or down. Audio playback does not stop during this transition.
+
+
+
+DPCM machine driver
+===================
+
+The DPCM enabled ASoC machine driver is similar to normal machine drivers
+except that we also have to :-
+
+ 1) Define the FE and BE DAI links.
+
+ 2) Define any FE/BE PCM operations.
+
+ 3) Define widget graph connections.
+
+
+1 FE and BE DAI links
+---------------------
+
+| Front End PCMs    |  SoC DSP  | Back End DAIs | Audio devices |
+
+                    *************
+PCM0 <------------> *           * <----DAI0-----> Codec Headset
+                    *           *
+PCM1 <------------> *           * <----DAI1-----> Codec Speakers
+                    *   DSP     *
+PCM2 <------------> *           * <----DAI2-----> MODEM
+                    *           *
+PCM3 <------------> *           * <----DAI3-----> BT
+                    *           *
+                    *           * <----DAI4-----> DMIC
+                    *           *
+                    *           * <----DAI5-----> FM
+                    *************
+
+For the example above we have to define 4 FE DAI links and 6 BE DAI links. The
+FE DAI links are defined as follows :-
+
+static struct snd_soc_dai_link machine_dais[] = {
+        {
+                .name = "PCM0 System",
+                .stream_name = "System Playback",
+                .cpu_dai_name = "System Pin",
+                .platform_name = "dsp-audio",
+                .codec_name = "snd-soc-dummy",
+                .codec_dai_name = "snd-soc-dummy-dai",
+                .dynamic = 1,
+                .trigger = {SND_SOC_DPCM_TRIGGER_POST, SND_SOC_DPCM_TRIGGER_POST},
+                .dpcm_playback = 1,
+        },
+        .....< other FE and BE DAI links here >
+};
+
+This FE DAI link is pretty similar to a regular DAI link except that we also
+set the DAI link to a DPCM FE with the "dynamic = 1". The supported FE stream
+directions should also be set with the "dpcm_playback" and "dpcm_capture"
+flags. There is also an option to specify the ordering of the trigger call for
+each FE. This allows the ASoC core to trigger the DSP before or after the other
+components (as some DSPs have strong requirements for the ordering DAI/DSP
+start and stop sequences).
+
+The FE DAI above sets the codec and code DAIs to dummy devices since the BE is
+dynamic and will change depending on runtime config.
+
+The BE DAIs are configured as follows :-
+
+static struct snd_soc_dai_link machine_dais[] = {
+        .....< FE DAI links here >
+        {
+                .name = "Codec Headset",
+                .cpu_dai_name = "ssp-dai.0",
+                .platform_name = "snd-soc-dummy",
+                .no_pcm = 1,
+                .codec_name = "rt5640.0-001c",
+                .codec_dai_name = "rt5640-aif1",
+                .ignore_suspend = 1,
+                .ignore_pmdown_time = 1,
+                .be_hw_params_fixup = hswult_ssp0_fixup,
+                .ops = &haswell_ops,
+                .dpcm_playback = 1,
+                .dpcm_capture = 1,
+        },
+        .....< other BE DAI links here >
+};
+
+This BE DAI link connects DAI0 to the codec (in this case RT5460 AIF1). It sets
+the "no_pcm" flag to mark it has a BE and sets flags for supported stream
+directions using "dpcm_playback" and "dpcm_capture" above.
+
+The BE has also flags set for ignoring suspend and PM down time. This allows
+the BE to work in a hostless mode where the host CPU is not transferring data
+like a BT phone call :-
+
+                    *************
+PCM0 <------------> *           * <----DAI0-----> Codec Headset
+                    *           *
+PCM1 <------------> *           * <----DAI1-----> Codec Speakers
+                    *   DSP     *
+PCM2 <------------> *           * <====DAI2=====> MODEM
+                    *           *
+PCM3 <------------> *           * <====DAI3=====> BT
+                    *           *
+                    *           * <----DAI4-----> DMIC
+                    *           *
+                    *           * <----DAI5-----> FM
+                    *************
+
+This allows the host CPU to sleep whilst the DSP, MODEM DAI and the BT DAI are
+still in operation.
+
+A BE DAI link can also set the codec to a dummy device if the code is a device
+that is managed externally.
+
+Likewise a BE DAI can also set a dummy cpu DAI if the CPU DAI is managed by the
+DSP firmware.
+
+
+2 FE/BE PCM operations
+----------------------
+
+The BE above also exports some PCM operations and a "fixup" callback. The fixup
+callback is used by the machine driver to (re)configure the DAI based upon the
+FE hw params. i.e. the DSP may perform SRC or ASRC from the FE to BE.
+
+e.g. DSP converts all FE hw params to run at fixed rate of 48k, 16bit, stereo for
+DAI0. This means all FE hw_params have to be fixed in the machine driver for
+DAI0 so that the DAI is running at desired configuration regardless of the FE
+configuration.
+
+static int dai0_fixup(struct snd_soc_pcm_runtime *rtd,
+                        struct snd_pcm_hw_params *params)
+{
+        struct snd_interval *rate = hw_param_interval(params,
+                        SNDRV_PCM_HW_PARAM_RATE);
+        struct snd_interval *channels = hw_param_interval(params,
+                                                SNDRV_PCM_HW_PARAM_CHANNELS);
+
+        /* The DSP will covert the FE rate to 48k, stereo */
+        rate->min = rate->max = 48000;
+        channels->min = channels->max = 2;
+
+        /* set DAI0 to 16 bit */
+        snd_mask_set(&params->masks[SNDRV_PCM_HW_PARAM_FORMAT -
+                                    SNDRV_PCM_HW_PARAM_FIRST_MASK],
+                                    SNDRV_PCM_FORMAT_S16_LE);
+        return 0;
+}
+
+The other PCM operation are the same as for regular DAI links. Use as necessary.
+
+
+3 Widget graph connections
+--------------------------
+
+The BE DAI links will normally be connected to the graph at initialisation time
+by the ASoC DAPM core. However, if the BE codec or BE DAI is a dummy then this
+has to be set explicitly in the driver :-
+
+/* BE for codec Headset -  DAI0 is dummy and managed by DSP FW */
+{"DAI0 CODEC IN", NULL, "AIF1 Capture"},
+{"AIF1 Playback", NULL, "DAI0 CODEC OUT"},
+
+
+Writing a DPCM DSP driver
+=========================
+
+The DPCM DSP driver looks much like a standard platform class ASoC driver
+combined with elements from a codec class driver. A DSP platform driver must
+implement :-
+
+ 1) Front End PCM DAIs - i.e. struct snd_soc_dai_driver.
+
+ 2) DAPM graph showing DSP audio routing from FE DAIs to BEs.
+
+ 3) DAPM widgets from DSP graph.
+
+ 4) Mixers for gains, routing, etc.
+
+ 5) DMA configuration.
+
+ 6) BE AIF widgets.
+
+Items 6 is important for routing the audio outside of the DSP. AIF need to be
+defined for each BE and each stream direction. e.g for BE DAI0 above we would
+have :-
+
+SND_SOC_DAPM_AIF_IN("DAI0 RX", NULL, 0, SND_SOC_NOPM, 0, 0),
+SND_SOC_DAPM_AIF_OUT("DAI0 TX", NULL, 0, SND_SOC_NOPM, 0, 0),
+
+The BE AIF are used to connect the DSP graph to the graphs for the other
+component drivers (e.g. codec graph).
+
+
+Hostless PCM streams
+====================
+
+A hostless PCM stream is a stream that is not routed through the host CPU. An
+example of this would be a phone call from handset to modem.
+
+
+                    *************
+PCM0 <------------> *           * <----DAI0-----> Codec Headset
+                    *           *
+PCM1 <------------> *           * <====DAI1=====> Codec Speakers/Mic
+                    *   DSP     *
+PCM2 <------------> *           * <====DAI2=====> MODEM
+                    *           *
+PCM3 <------------> *           * <----DAI3-----> BT
+                    *           *
+                    *           * <----DAI4-----> DMIC
+                    *           *
+                    *           * <----DAI5-----> FM
+                    *************
+
+In this case the PCM data is routed via the DSP. The host CPU in this use case
+is only used for control and can sleep during the runtime of the stream.
+
+The host can control the hostless link either by :-
+
+ 1) Configuring the link as a CODEC <-> CODEC style link. In this case the link
+    is enabled or disabled by the state of the DAPM graph. This usually means
+    there is a mixer control that can be used to connect or disconnect the path
+    between both DAIs.
+
+ 2) Hostless FE. This FE has a virtual connection to the BE DAI links on the DAPM
+    graph. Control is then carried out by the FE as regular PCM operations.
+    This method gives more control over the DAI links, but requires much more
+    userspace code to control the link. Its recommended to use CODEC<->CODEC
+    unless your HW needs more fine grained sequencing of the PCM ops.
+
+
+CODEC <-> CODEC link
+--------------------
+
+This DAI link is enabled when DAPM detects a valid path within the DAPM graph.
+The machine driver sets some additional parameters to the DAI link i.e.
+
+static const struct snd_soc_pcm_stream dai_params = {
+        .formats = SNDRV_PCM_FMTBIT_S32_LE,
+        .rate_min = 8000,
+        .rate_max = 8000,
+        .channels_min = 2,
+        .channels_max = 2,
+};
+
+static struct snd_soc_dai_link dais[] = {
+        < ... more DAI links above ... >
+        {
+                .name = "MODEM",
+                .stream_name = "MODEM",
+                .cpu_dai_name = "dai2",
+                .codec_dai_name = "modem-aif1",
+                .codec_name = "modem",
+                .dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF
+                                | SND_SOC_DAIFMT_CBM_CFM,
+                .params = &dai_params,
+        }
+        < ... more DAI links here ... >
+
+These parameters are used to configure the DAI hw_params() when DAPM detects a
+valid path and then calls the PCM operations to start the link. DAPM will also
+call the appropriate PCM operations to disable the DAI when the path is no
+longer valid.
+
+
+Hostless FE
+-----------
+
+The DAI link(s) are enabled by a FE that does not read or write any PCM data.
+This means creating a new FE that is connected with a virtual path to both
+DAI links. The DAI links will be started when the FE PCM is started and stopped
+when the FE PCM is stopped. Note that the FE PCM cannot read or write data in
+this configuration.
+
+
diff --git a/Documentation/sound/alsa/soc/codec.txt b/Documentation/sound/alsa/soc/codec.txt
index bce23a4a7875..db5f9c9ae149 100644
--- a/Documentation/sound/alsa/soc/codec.txt
+++ b/Documentation/sound/alsa/soc/codec.txt
@@ -1,22 +1,23 @@
-ASoC Codec Driver
-=================
+ASoC Codec Class Driver
+=======================
 
-The codec driver is generic and hardware independent code that configures the
-codec to provide audio capture and playback. It should contain no code that is
-specific to the target platform or machine. All platform and machine specific
-code should be added to the platform and machine drivers respectively.
+The codec class driver is generic and hardware independent code that configures
+the codec, FM, MODEM, BT or external DSP to provide audio capture and playback.
+It should contain no code that is specific to the target platform or machine.
+All platform and machine specific code should be added to the platform and
+machine drivers respectively.
 
-Each codec driver *must* provide the following features:-
+Each codec class driver *must* provide the following features:-
 
  1) Codec DAI and PCM configuration
- 2) Codec control IO - using I2C, 3 Wire(SPI) or both APIs
+ 2) Codec control IO - using RegMap API
  3) Mixers and audio controls
  4) Codec audio operations
+ 5) DAPM description.
+ 6) DAPM event handler.
 
 Optionally, codec drivers can also provide:-
 
- 5) DAPM description.
- 6) DAPM event handler.
  7) DAC Digital mute control.
 
 Its probably best to use this guide in conjunction with the existing codec
@@ -64,26 +65,9 @@ struct snd_soc_dai_driver wm8731_dai = {
 2 - Codec control IO
 --------------------
 The codec can usually be controlled via an I2C or SPI style interface
-(AC97 combines control with data in the DAI). The codec drivers provide
-functions to read and write the codec registers along with supplying a
-register cache:-
-
-        /* IO control data and register cache */
-        void *control_data; /* codec control (i2c/3wire) data */
-        void *reg_cache;
-
-Codec read/write should do any data formatting and call the hardware
-read write below to perform the IO. These functions are called by the
-core and ALSA when performing DAPM or changing the mixer:-
-
-    unsigned int (*read)(struct snd_soc_codec *, unsigned int);
-    int (*write)(struct snd_soc_codec *, unsigned int, unsigned int);
-
-Codec hardware IO functions - usually points to either the I2C, SPI or AC97
-read/write:-
-
-        hw_write_t hw_write;
-        hw_read_t hw_read;
+(AC97 combines control with data in the DAI). The codec driver should use the
+Regmap API for all codec IO. Please see include/linux/regmap.h and existing
+codec drivers for example regmap usage.
 
 
 3 - Mixers and audio controls
@@ -127,7 +111,7 @@ Defines a stereo enumerated control
 
 4 - Codec Audio Operations
 --------------------------
-The codec driver also supports the following ALSA operations:-
+The codec driver also supports the following ALSA PCM operations:-
 
 /* SoC audio ops */
 struct snd_soc_ops {
diff --git a/Documentation/sound/alsa/soc/dapm.txt b/Documentation/sound/alsa/soc/dapm.txt
index 05bf5a0eee41..6faab4880006 100644
--- a/Documentation/sound/alsa/soc/dapm.txt
+++ b/Documentation/sound/alsa/soc/dapm.txt
@@ -21,7 +21,7 @@ level power systems.
 
 There are 4 power domains within DAPM
 
-   1. Codec domain - VREF, VMID (core codec and audio power)
+   1. Codec bias domain - VREF, VMID (core codec and audio power)
       Usually controlled at codec probe/remove and suspend/resume, although
       can be set at stream time if power is not needed for sidetone, etc.
 
@@ -30,7 +30,7 @@ There are 4 power domains within DAPM
       machine driver and responds to asynchronous events e.g when HP
       are inserted
 
-   3. Path domain - audio susbsystem signal paths
+   3. Path domain - audio subsystem signal paths
       Automatically set when mixer and mux settings are changed by the user.
       e.g. alsamixer, amixer.
 
@@ -63,14 +63,22 @@ Audio DAPM widgets fall into a number of types:-
  o Line       - Line Input/Output (and optional Jack)
  o Speaker    - Speaker
  o Supply     - Power or clock supply widget used by other widgets.
+ o Regulator  - External regulator that supplies power to audio components.
+ o Clock      - External clock that supplies clock to audio components.
+ o AIF IN     - Audio Interface Input (with TDM slot mask).
+ o AIF OUT    - Audio Interface Output (with TDM slot mask).
+ o Siggen     - Signal Generator.
+ o DAI IN     - Digital Audio Interface Input.
+ o DAI OUT    - Digital Audio Interface Output.
+ o DAI Link   - DAI Link between two DAI structures */
  o Pre        - Special PRE widget (exec before all others)
  o Post       - Special POST widget (exec after all others)
 
 (Widgets are defined in include/sound/soc-dapm.h)
 
-Widgets are usually added in the codec driver and the machine driver. There are
-convenience macros defined in soc-dapm.h that can be used to quickly build a
-list of widgets of the codecs and machines DAPM widgets.
+Widgets can be added to the sound card by any of the component driver types.
+There are convenience macros defined in soc-dapm.h that can be used to quickly
+build a list of widgets of the codecs and machines DAPM widgets.
 
 Most widgets have a name, register, shift and invert. Some widgets have extra
 parameters for stream name and kcontrols.
@@ -80,11 +88,13 @@ parameters for stream name and kcontrols.
 -------------------------
 
 Stream Widgets relate to the stream power domain and only consist of ADCs
-(analog to digital converters) and DACs (digital to analog converters).
+(analog to digital converters), DACs (digital to analog converters),
+AIF IN and AIF OUT.
 
 Stream widgets have the following format:-
 
 SND_SOC_DAPM_DAC(name, stream name, reg, shift, invert),
+SND_SOC_DAPM_AIF_IN(name, stream, slot, reg, shift, invert)
 
 NOTE: the stream name must match the corresponding stream name in your codec
 snd_soc_codec_dai.
@@ -94,6 +104,11 @@ e.g. stream widgets for HiFi playback and capture
 SND_SOC_DAPM_DAC("HiFi DAC", "HiFi Playback", REG, 3, 1),
 SND_SOC_DAPM_ADC("HiFi ADC", "HiFi Capture", REG, 2, 1),
 
+e.g. stream widgets for AIF
+
+SND_SOC_DAPM_AIF_IN("AIF1RX", "AIF1 Playback", 0, SND_SOC_NOPM, 0, 0),
+SND_SOC_DAPM_AIF_OUT("AIF1TX", "AIF1 Capture", 0, SND_SOC_NOPM, 0, 0),
+
 
 2.2 Path Domain Widgets
 -----------------------
@@ -121,12 +136,14 @@ If you dont want the mixer elements prefixed with the name of the mixer widget,
 you can use SND_SOC_DAPM_MIXER_NAMED_CTL instead. the parameters are the same
 as for SND_SOC_DAPM_MIXER.
 
-2.3 Platform/Machine domain Widgets
------------------------------------
+
+2.3 Machine domain Widgets
+--------------------------
 
 Machine widgets are different from codec widgets in that they don't have a
 codec register bit associated with them. A machine widget is assigned to each
-machine audio component (non codec) that can be independently powered. e.g.
+machine audio component (non codec or DSP) that can be independently
+powered. e.g.
 
  o Speaker Amp
  o Microphone Bias
@@ -146,12 +163,12 @@ static int spitz_mic_bias(struct snd_soc_dapm_widget* w, int event)
 SND_SOC_DAPM_MIC("Mic Jack", spitz_mic_bias),
 
 
-2.4 Codec Domain
-----------------
+2.4 Codec (BIAS) Domain
+-----------------------
 
-The codec power domain has no widgets and is handled by the codecs DAPM event
-handler. This handler is called when the codec powerstate is changed wrt to any
-stream event or by kernel PM events.
+The codec bias power domain has no widgets and is handled by the codecs DAPM
+event handler. This handler is called when the codec powerstate is changed wrt
+to any stream event or by kernel PM events.
 
 
 2.5 Virtual Widgets
@@ -169,15 +186,16 @@ After all the widgets have been defined, they can then be added to the DAPM
 subsystem individually with a call to snd_soc_dapm_new_control().
 
 
-3. Codec Widget Interconnections
-================================
+3. Codec/DSP Widget Interconnections
+====================================
 
-Widgets are connected to each other within the codec and machine by audio paths
-(called interconnections). Each interconnection must be defined in order to
-create a map of all audio paths between widgets.
+Widgets are connected to each other within the codec, platform and machine by
+audio paths (called interconnections). Each interconnection must be defined in
+order to create a map of all audio paths between widgets.
 
-This is easiest with a diagram of the codec (and schematic of the machine audio
-system), as it requires joining widgets together via their audio signal paths.
+This is easiest with a diagram of the codec or DSP (and schematic of the machine
+audio system), as it requires joining widgets together via their audio signal
+paths.
 
 e.g., from the WM8731 output mixer (wm8731.c)
 
@@ -247,16 +265,9 @@ machine and includes the codec. e.g.
  o Mic Jack
  o Codec Pins
 
-When a codec pin is NC it can be marked as not used with a call to
-
-snd_soc_dapm_set_endpoint(codec, "Widget Name", 0);
-
-The last argument is 0 for inactive and 1 for active. This way the pin and its
-input widget will never be powered up and consume power.
-
-This also applies to machine widgets. e.g. if a headphone is connected to a
-jack then the jack can be marked active. If the headphone is removed, then
-the headphone jack can be marked inactive.
+Endpoints are added to the DAPM graph so that their usage can be determined in
+order to save power. e.g. NC codecs pins will be switched OFF, unconnected
+jacks can also be switched OFF.
 
 
 5 DAPM Widget Events
diff --git a/Documentation/sound/alsa/soc/machine.txt b/Documentation/sound/alsa/soc/machine.txt
index d50c14df3411..74056dba52be 100644
--- a/Documentation/sound/alsa/soc/machine.txt
+++ b/Documentation/sound/alsa/soc/machine.txt
@@ -1,8 +1,10 @@
 ASoC Machine Driver
 ===================
 
-The ASoC machine (or board) driver is the code that glues together the platform
-and codec drivers.
+The ASoC machine (or board) driver is the code that glues together all the
+component drivers (e.g. codecs, platforms and DAIs). It also describes the
+relationships between each componnent which include audio paths, GPIOs,
+interrupts, clocking, jacks and voltage regulators.
 
 The machine driver can contain codec and platform specific code. It registers
 the audio subsystem with the kernel as a platform device and is represented by
diff --git a/Documentation/sound/alsa/soc/platform.txt b/Documentation/sound/alsa/soc/platform.txt
index d57efad37e0a..3a08a2c9150c 100644
--- a/Documentation/sound/alsa/soc/platform.txt
+++ b/Documentation/sound/alsa/soc/platform.txt
@@ -1,9 +1,9 @@
 ASoC Platform Driver
 ====================
 
-An ASoC platform driver can be divided into audio DMA and SoC DAI configuration
-and control. The platform drivers only target the SoC CPU and must have no board
-specific code.
+An ASoC platform driver class can be divided into audio DMA drivers, SoC DAI
+drivers and DSP drivers. The platform drivers only target the SoC CPU and must
+have no board specific code.
 
 Audio DMA
 =========
@@ -64,3 +64,16 @@ Each SoC DAI driver must provide the following features:-
  5) Suspend and resume (optional)
 
 Please see codec.txt for a description of items 1 - 4.
+
+
+SoC DSP Drivers
+===============
+
+Each SoC DSP driver usually supplies the following features :-
+
+ 1) DAPM graph
+ 2) Mixer controls
+ 3) DMA IO to/from DSP buffers (if applicable)
+ 4) Definition of DSP front end (FE) PCM devices.
+
+Please see DPCM.txt for a description of item 4.
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 9d4c1d18ad44..26b7ee491df8 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -290,13 +290,24 @@ Default value is "/sbin/hotplug".
 kptr_restrict:
 
 This toggle indicates whether restrictions are placed on
-exposing kernel addresses via /proc and other interfaces.  When
-kptr_restrict is set to (0), there are no restrictions.  When
-kptr_restrict is set to (1), the default, kernel pointers
-printed using the %pK format specifier will be replaced with 0's
-unless the user has CAP_SYSLOG.  When kptr_restrict is set to
-(2), kernel pointers printed using %pK will be replaced with 0's
-regardless of privileges.
+exposing kernel addresses via /proc and other interfaces.
+
+When kptr_restrict is set to (0), the default, there are no restrictions.
+
+When kptr_restrict is set to (1), kernel pointers printed using the %pK
+format specifier will be replaced with 0's unless the user has CAP_SYSLOG
+and effective user and group ids are equal to the real ids. This is
+because %pK checks are done at read() time rather than open() time, so
+if permissions are elevated between the open() and the read() (e.g via
+a setuid binary) then %pK will not leak kernel pointers to unprivileged
+users. Note, this is a temporary solution only. The correct long-term
+solution is to do the permission checks at open() time. Consider removing
+world read permissions from files that use %pK, and using dmesg_restrict
+to protect against uses of %pK in dmesg(8) if leaking kernel pointer
+values to unprivileged users is a concern.
+
+When kptr_restrict is set to (2), kernel pointers printed using
+%pK will be replaced with 0's regardless of privileges.
 
 ==============================================================
 
@@ -355,6 +366,82 @@ utilize.
 
 ==============================================================
 
+numa_balancing
+
+Enables/disables automatic page fault based NUMA memory
+balancing. Memory is moved automatically to nodes
+that access it often.
+
+Enables/disables automatic NUMA memory balancing. On NUMA machines, there
+is a performance penalty if remote memory is accessed by a CPU. When this
+feature is enabled the kernel samples what task thread is accessing memory
+by periodically unmapping pages and later trapping a page fault. At the
+time of the page fault, it is determined if the data being accessed should
+be migrated to a local memory node.
+
+The unmapping of pages and trapping faults incur additional overhead that
+ideally is offset by improved memory locality but there is no universal
+guarantee. If the target workload is already bound to NUMA nodes then this
+feature should be disabled. Otherwise, if the system overhead from the
+feature is too high then the rate the kernel samples for NUMA hinting
+faults may be controlled by the numa_balancing_scan_period_min_ms,
+numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms,
+numa_balancing_scan_size_mb, numa_balancing_settle_count sysctls and
+numa_balancing_migrate_deferred.
+
+==============================================================
+
+numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms,
+numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb
+
+Automatic NUMA balancing scans tasks address space and unmaps pages to
+detect if pages are properly placed or if the data should be migrated to a
+memory node local to where the task is running.  Every "scan delay" the task
+scans the next "scan size" number of pages in its address space. When the
+end of the address space is reached the scanner restarts from the beginning.
+
+In combination, the "scan delay" and "scan size" determine the scan rate.
+When "scan delay" decreases, the scan rate increases.  The scan delay and
+hence the scan rate of every task is adaptive and depends on historical
+behaviour. If pages are properly placed then the scan delay increases,
+otherwise the scan delay decreases.  The "scan size" is not adaptive but
+the higher the "scan size", the higher the scan rate.
+
+Higher scan rates incur higher system overhead as page faults must be
+trapped and potentially data must be migrated. However, the higher the scan
+rate, the more quickly a tasks memory is migrated to a local node if the
+workload pattern changes and minimises performance impact due to remote
+memory accesses. These sysctls control the thresholds for scan delays and
+the number of pages scanned.
+
+numa_balancing_scan_period_min_ms is the minimum time in milliseconds to
+scan a tasks virtual memory. It effectively controls the maximum scanning
+rate for each task.
+
+numa_balancing_scan_delay_ms is the starting "scan delay" used for a task
+when it initially forks.
+
+numa_balancing_scan_period_max_ms is the maximum time in milliseconds to
+scan a tasks virtual memory. It effectively controls the minimum scanning
+rate for each task.
+
+numa_balancing_scan_size_mb is how many megabytes worth of pages are
+scanned for a given scan.
+
+numa_balancing_settle_count is how many scan periods must complete before
+the schedule balancer stops pushing the task towards a preferred node. This
+gives the scheduler a chance to place the task on an alternative node if the
+preferred node is overloaded.
+
+numa_balancing_migrate_deferred is how many page migrations get skipped
+unconditionally, after a page migration is skipped because a page is shared
+with other tasks. This reduces page migration overhead, and determines
+how much stronger the "move task near its memory" policy scheduler becomes,
+versus the "move memory near its task" memory management policy, for workloads
+with shared memory.
+
+==============================================================
+
 osrelease, ostype & version:
 
 # cat osrelease
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index 79a797eb3e87..1fbd4eb7b64a 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -119,8 +119,11 @@ other appears as 0 when read.
 
 dirty_background_ratio
 
-Contains, as a percentage of total system memory, the number of pages at which
-the background kernel flusher threads will start writing out dirty data.
+Contains, as a percentage of total available memory that contains free pages
+and reclaimable pages, the number of pages at which the background kernel
+flusher threads will start writing out dirty data.
+
+The total avaiable memory is not equal to total system memory.
 
 ==============================================================
 
@@ -151,9 +154,11 @@ interval will be written out next time a flusher thread wakes up.
 
 dirty_ratio
 
-Contains, as a percentage of total system memory, the number of pages at which
-a process which is generating disk writes will itself start writing out dirty
-data.
+Contains, as a percentage of total available memory that contains free pages
+and reclaimable pages, the number of pages at which a process which is
+generating disk writes will itself start writing out dirty data.
+
+The total avaiable memory is not equal to total system memory.
 
 ==============================================================
 
diff --git a/Documentation/sysrq.txt b/Documentation/sysrq.txt
index 8cb4d7842a5f..0e307c94809a 100644
--- a/Documentation/sysrq.txt
+++ b/Documentation/sysrq.txt
@@ -11,27 +11,29 @@ regardless of whatever else it is doing, unless it is completely locked up.
 You need to say "yes" to 'Magic SysRq key (CONFIG_MAGIC_SYSRQ)' when
 configuring the kernel. When running a kernel with SysRq compiled in,
 /proc/sys/kernel/sysrq controls the functions allowed to be invoked via
-the SysRq key. By default the file contains 1 which means that every
-possible SysRq request is allowed (in older versions SysRq was disabled
-by default, and you were required to specifically enable it at run-time
-but this is not the case any more). Here is the list of possible values
-in /proc/sys/kernel/sysrq:
+the SysRq key. The default value in this file is set by the
+CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE config symbol, which itself defaults
+to 1. Here is the list of possible values in /proc/sys/kernel/sysrq:
    0 - disable sysrq completely
    1 - enable all functions of sysrq
   >1 - bitmask of allowed sysrq functions (see below for detailed function
        description):
-          2 - enable control of console logging level
-          4 - enable control of keyboard (SAK, unraw)
-          8 - enable debugging dumps of processes etc.
-         16 - enable sync command
-         32 - enable remount read-only
-         64 - enable signalling of processes (term, kill, oom-kill)
-        128 - allow reboot/poweroff
-        256 - allow nicing of all RT tasks
+          2 =   0x2 - enable control of console logging level
+          4 =   0x4 - enable control of keyboard (SAK, unraw)
+          8 =   0x8 - enable debugging dumps of processes etc.
+         16 =  0x10 - enable sync command
+         32 =  0x20 - enable remount read-only
+         64 =  0x40 - enable signalling of processes (term, kill, oom-kill)
+        128 =  0x80 - allow reboot/poweroff
+        256 = 0x100 - allow nicing of all RT tasks
 
 You can set the value in the file by the following command:
     echo "number" >/proc/sys/kernel/sysrq
 
+The number may be written here either as decimal or as hexadecimal
+with the 0x prefix. CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE must always be
+written in hexadecimal.
+
 Note that the value of /proc/sys/kernel/sysrq influences only the invocation
 via a keyboard. Invocation of any operation via /proc/sysrq-trigger is always
 allowed (by a user with admin privileges).
diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX
index a9248da5cdbc..ef2ccbf77fa2 100644
--- a/Documentation/timers/00-INDEX
+++ b/Documentation/timers/00-INDEX
@@ -8,5 +8,9 @@ hpet_example.c
         - sample hpet timer test program
 hrtimers.txt
         - subsystem for high-resolution kernel timers
+NO_HZ.txt
+        - Summary of the different methods for the scheduler clock-interrupts management.
+timers-howto.txt
+        - how to insert delays in the kernel the right (tm) way.
 timer_stats.txt
         - timer usage statistics
diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
index ea2d35d64d26..bd365988e8d8 100644
--- a/Documentation/trace/ftrace.txt
+++ b/Documentation/trace/ftrace.txt
@@ -655,7 +655,11 @@ explains which is which.
                   read the irq flags variable, an 'X' will always
                   be printed here.
 
-  need-resched: 'N' task need_resched is set, '.' otherwise.
+  need-resched:
+        'N' both TIF_NEED_RESCHED and PREEMPT_NEED_RESCHED is set,
+        'n' only TIF_NEED_RESCHED is set,
+        'p' only PREEMPT_NEED_RESCHED is set,
+        '.' otherwise.
 
   hardirq/softirq:
         'H' - hard irq occurred inside a softirq.
diff --git a/Documentation/trace/tracepoints.txt b/Documentation/trace/tracepoints.txt
index ac4170dd0f24..6b018b53177a 100644
--- a/Documentation/trace/tracepoints.txt
+++ b/Documentation/trace/tracepoints.txt
@@ -114,3 +114,8 @@ core kernel image or in modules.
 If the tracepoint has to be used in kernel modules, an
 EXPORT_TRACEPOINT_SYMBOL_GPL() or EXPORT_TRACEPOINT_SYMBOL() can be
 used to export the defined tracepoints.
+
+Note: The convenience macro TRACE_EVENT provides an alternative way to
+      define tracepoints. Check http://lwn.net/Articles/379903,
+      http://lwn.net/Articles/381064 and http://lwn.net/Articles/383362
+      for a series of articles with more details.
diff --git a/Documentation/usb/gadget_configfs.txt b/Documentation/usb/gadget_configfs.txt
index 8ec2a67c39b7..4cf53e406613 100644
--- a/Documentation/usb/gadget_configfs.txt
+++ b/Documentation/usb/gadget_configfs.txt
@@ -26,7 +26,7 @@ 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
+Configfs (please see Documentation/filesystems/configfs/*) lends itself nicely
 for the purpose of telling the kernel about the above mentioned decision.
 This document is about how to do it.
 
@@ -99,7 +99,7 @@ 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.:
+<number> is the configuration's number, e.g.:
 
 $ mkdir configs/c.1
 
@@ -327,7 +327,7 @@ 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;
+typedef struct specific_attribute sa;
 
                                        sa
                        +----------------------------------+
diff --git a/Documentation/virtual/kvm/00-INDEX b/Documentation/virtual/kvm/00-INDEX
new file mode 100644
index 000000000000..641ec9220179
--- /dev/null
+++ b/Documentation/virtual/kvm/00-INDEX
@@ -0,0 +1,24 @@
+00-INDEX
+        - this file.
+api.txt
+        - KVM userspace API.
+cpuid.txt
+        - KVM-specific cpuid leaves (x86).
+devices/
+        - KVM_CAP_DEVICE_CTRL userspace API.
+hypercalls.txt
+        - KVM hypercalls.
+locking.txt
+        - notes on KVM locks.
+mmu.txt
+        - the x86 kvm shadow mmu.
+msr.txt
+        - KVM-specific MSRs (x86).
+nested-vmx.txt
+        - notes on nested virtualization for Intel x86 processors.
+ppc-pv.txt
+        - the paravirtualization interface on PowerPC.
+review-checklist.txt
+        - review checklist for KVM patches.
+timekeeping.txt
+        - timekeeping virtualization for x86-based architectures.
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 858aecf21db2..a30035dd4c26 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1122,9 +1122,9 @@ struct kvm_cpuid2 {
         struct kvm_cpuid_entry2 entries[0];
 };
 
-#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX 1
-#define KVM_CPUID_FLAG_STATEFUL_FUNC    2
-#define KVM_CPUID_FLAG_STATE_READ_NEXT  4
+#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX         BIT(0)
+#define KVM_CPUID_FLAG_STATEFUL_FUNC            BIT(1)
+#define KVM_CPUID_FLAG_STATE_READ_NEXT          BIT(2)
 
 struct kvm_cpuid_entry2 {
         __u32 function;
@@ -1810,6 +1810,50 @@ registers, find a list below:
   PPC   | KVM_REG_PPC_TLB3PS    | 32
   PPC   | KVM_REG_PPC_EPTCFG    | 32
   PPC   | KVM_REG_PPC_ICP_STATE | 64
+  PPC   | KVM_REG_PPC_TB_OFFSET | 64
+  PPC   | KVM_REG_PPC_SPMC1     | 32
+  PPC   | KVM_REG_PPC_SPMC2     | 32
+  PPC   | KVM_REG_PPC_IAMR      | 64
+  PPC   | KVM_REG_PPC_TFHAR     | 64
+  PPC   | KVM_REG_PPC_TFIAR     | 64
+  PPC   | KVM_REG_PPC_TEXASR    | 64
+  PPC   | KVM_REG_PPC_FSCR      | 64
+  PPC   | KVM_REG_PPC_PSPB      | 32
+  PPC   | KVM_REG_PPC_EBBHR     | 64
+  PPC   | KVM_REG_PPC_EBBRR     | 64
+  PPC   | KVM_REG_PPC_BESCR     | 64
+  PPC   | KVM_REG_PPC_TAR       | 64
+  PPC   | KVM_REG_PPC_DPDES     | 64
+  PPC   | KVM_REG_PPC_DAWR      | 64
+  PPC   | KVM_REG_PPC_DAWRX     | 64
+  PPC   | KVM_REG_PPC_CIABR     | 64
+  PPC   | KVM_REG_PPC_IC        | 64
+  PPC   | KVM_REG_PPC_VTB       | 64
+  PPC   | KVM_REG_PPC_CSIGR     | 64
+  PPC   | KVM_REG_PPC_TACR      | 64
+  PPC   | KVM_REG_PPC_TCSCR     | 64
+  PPC   | KVM_REG_PPC_PID       | 64
+  PPC   | KVM_REG_PPC_ACOP      | 64
+  PPC   | KVM_REG_PPC_VRSAVE    | 32
+  PPC   | KVM_REG_PPC_LPCR      | 64
+  PPC   | KVM_REG_PPC_PPR       | 64
+  PPC   | KVM_REG_PPC_ARCH_COMPAT 32
+  PPC   | KVM_REG_PPC_TM_GPR0   | 64
+          ...
+  PPC   | KVM_REG_PPC_TM_GPR31  | 64
+  PPC   | KVM_REG_PPC_TM_VSR0   | 128
+          ...
+  PPC   | KVM_REG_PPC_TM_VSR63  | 128
+  PPC   | KVM_REG_PPC_TM_CR     | 64
+  PPC   | KVM_REG_PPC_TM_LR     | 64
+  PPC   | KVM_REG_PPC_TM_CTR    | 64
+  PPC   | KVM_REG_PPC_TM_FPSCR  | 64
+  PPC   | KVM_REG_PPC_TM_AMR    | 64
+  PPC   | KVM_REG_PPC_TM_PPR    | 64
+  PPC   | KVM_REG_PPC_TM_VRSAVE | 64
+  PPC   | KVM_REG_PPC_TM_VSCR   | 32
+  PPC   | KVM_REG_PPC_TM_DSCR   | 64
+  PPC   | KVM_REG_PPC_TM_TAR    | 64
 
 ARM registers are mapped using the lower 32 bits.  The upper 16 of that
 is the register group type, or coprocessor number:
@@ -2304,7 +2348,31 @@ Possible features:
           Depends on KVM_CAP_ARM_EL1_32BIT (arm64 only).
 
 
-4.83 KVM_GET_REG_LIST
+4.83 KVM_ARM_PREFERRED_TARGET
+
+Capability: basic
+Architectures: arm, arm64
+Type: vm ioctl
+Parameters: struct struct kvm_vcpu_init (out)
+Returns: 0 on success; -1 on error
+Errors:
+  ENODEV:    no preferred target available for the host
+
+This queries KVM for preferred CPU target type which can be emulated
+by KVM on underlying host.
+
+The ioctl returns struct kvm_vcpu_init instance containing information
+about preferred CPU target type and recommended features for it.  The
+kvm_vcpu_init->features bitmap returned will have feature bits set if
+the preferred target recommends setting these features, but this is
+not mandatory.
+
+The information returned by this ioctl can be used to prepare an instance
+of struct kvm_vcpu_init for KVM_ARM_VCPU_INIT ioctl which will result in
+in VCPU matching underlying host.
+
+
+4.84 KVM_GET_REG_LIST
 
 Capability: basic
 Architectures: arm, arm64
@@ -2323,8 +2391,7 @@ struct kvm_reg_list {
 This ioctl returns the guest registers that are supported for the
 KVM_GET_ONE_REG/KVM_SET_ONE_REG calls.
 
-
-4.84 KVM_ARM_SET_DEVICE_ADDR
+4.85 KVM_ARM_SET_DEVICE_ADDR
 
 Capability: KVM_CAP_ARM_SET_DEVICE_ADDR
 Architectures: arm, arm64
@@ -2362,7 +2429,7 @@ must be called after calling KVM_CREATE_IRQCHIP, but before calling
 KVM_RUN on any of the VCPUs.  Calling this ioctl twice for any of the
 base addresses will return -EEXIST.
 
-4.85 KVM_PPC_RTAS_DEFINE_TOKEN
+4.86 KVM_PPC_RTAS_DEFINE_TOKEN
 
 Capability: KVM_CAP_PPC_RTAS
 Architectures: ppc
@@ -2661,6 +2728,77 @@ and usually define the validity of a groups of registers. (e.g. one bit
 };
 
 
+4.81 KVM_GET_EMULATED_CPUID
+
+Capability: KVM_CAP_EXT_EMUL_CPUID
+Architectures: x86
+Type: system ioctl
+Parameters: struct kvm_cpuid2 (in/out)
+Returns: 0 on success, -1 on error
+
+struct kvm_cpuid2 {
+        __u32 nent;
+        __u32 flags;
+        struct kvm_cpuid_entry2 entries[0];
+};
+
+The member 'flags' is used for passing flags from userspace.
+
+#define KVM_CPUID_FLAG_SIGNIFCANT_INDEX         BIT(0)
+#define KVM_CPUID_FLAG_STATEFUL_FUNC            BIT(1)
+#define KVM_CPUID_FLAG_STATE_READ_NEXT          BIT(2)
+
+struct kvm_cpuid_entry2 {
+        __u32 function;
+        __u32 index;
+        __u32 flags;
+        __u32 eax;
+        __u32 ebx;
+        __u32 ecx;
+        __u32 edx;
+        __u32 padding[3];
+};
+
+This ioctl returns x86 cpuid features which are emulated by
+kvm.Userspace can use the information returned by this ioctl to query
+which features are emulated by kvm instead of being present natively.
+
+Userspace invokes KVM_GET_EMULATED_CPUID by passing a kvm_cpuid2
+structure with the 'nent' field indicating the number of entries in
+the variable-size array 'entries'. If the number of entries is too low
+to describe the cpu capabilities, an error (E2BIG) is returned. If the
+number is too high, the 'nent' field is adjusted and an error (ENOMEM)
+is returned. If the number is just right, the 'nent' field is adjusted
+to the number of valid entries in the 'entries' array, which is then
+filled.
+
+The entries returned are the set CPUID bits of the respective features
+which kvm emulates, as returned by the CPUID instruction, with unknown
+or unsupported feature bits cleared.
+
+Features like x2apic, for example, may not be present in the host cpu
+but are exposed by kvm in KVM_GET_SUPPORTED_CPUID because they can be
+emulated efficiently and thus not included here.
+
+The fields in each entry are defined as follows:
+
+  function: the eax value used to obtain the entry
+  index: the ecx value used to obtain the entry (for entries that are
+         affected by ecx)
+  flags: an OR of zero or more of the following:
+        KVM_CPUID_FLAG_SIGNIFCANT_INDEX:
+           if the index field is valid
+        KVM_CPUID_FLAG_STATEFUL_FUNC:
+           if cpuid for this function returns different values for successive
+           invocations; there will be several entries with the same function,
+           all with this flag set
+        KVM_CPUID_FLAG_STATE_READ_NEXT:
+           for KVM_CPUID_FLAG_STATEFUL_FUNC entries, set if this entry is
+           the first entry to be read by a cpu
+   eax, ebx, ecx, edx: the values returned by the cpuid instruction for
+         this function/index combination
+
+
 6. Capabilities that can be enabled
 -----------------------------------
 
diff --git a/Documentation/virtual/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 22ff659bc0fb..3c65feb83010 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -43,6 +43,13 @@ KVM_FEATURE_CLOCKSOURCE2           ||     3 || kvmclock available at msrs
 KVM_FEATURE_ASYNC_PF               ||     4 || async pf can be enabled by
                                    ||       || writing to msr 0x4b564d02
 ------------------------------------------------------------------------------
+KVM_FEATURE_STEAL_TIME             ||     5 || steal time can be enabled by
+                                   ||       || writing to msr 0x4b564d03.
+------------------------------------------------------------------------------
+KVM_FEATURE_PV_EOI                 ||     6 || paravirtualized end of interrupt
+                                   ||       || handler can be enabled by writing
+                                   ||       || to msr 0x4b564d04.
+------------------------------------------------------------------------------
 KVM_FEATURE_PV_UNHALT              ||     7 || guest checks this feature bit
                                    ||       || before enabling paravirtualized
                                    ||       || spinlock support.
diff --git a/Documentation/virtual/kvm/devices/vfio.txt b/Documentation/virtual/kvm/devices/vfio.txt
new file mode 100644
index 000000000000..ef51740c67ca
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/vfio.txt
@@ -0,0 +1,22 @@
+VFIO virtual device
+===================
+
+Device types supported:
+  KVM_DEV_TYPE_VFIO
+
+Only one VFIO instance may be created per VM.  The created device
+tracks VFIO groups in use by the VM and features of those groups
+important to the correctness and acceleration of the VM.  As groups
+are enabled and disabled for use by the VM, KVM should be updated
+about their presence.  When registered with KVM, a reference to the
+VFIO-group is held by KVM.
+
+Groups:
+  KVM_DEV_VFIO_GROUP
+
+KVM_DEV_VFIO_GROUP attributes:
+  KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
+  KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
+
+For each, kvm_device_attr.addr points to an int32_t file descriptor
+for the VFIO group.
diff --git a/Documentation/virtual/kvm/locking.txt b/Documentation/virtual/kvm/locking.txt
index 41b7ac9884b5..f8869410d40c 100644
--- a/Documentation/virtual/kvm/locking.txt
+++ b/Documentation/virtual/kvm/locking.txt
@@ -132,10 +132,14 @@ See the comments in spte_has_volatile_bits() and mmu_spte_update().
 ------------
 
 Name:           kvm_lock
-Type:           raw_spinlock
+Type:           spinlock_t
 Arch:           any
 Protects:       - vm_list
-                - hardware virtualization enable/disable
+
+Name:           kvm_count_lock
+Type:           raw_spinlock_t
+Arch:           any
+Protects:       - hardware virtualization enable/disable
 Comment:        'raw' because hardware enabling/disabling must be atomic /wrt
                 migration.
 
@@ -151,3 +155,14 @@ Type:		spinlock_t
 Arch:           any
 Protects:       -shadow page/shadow tlb entry
 Comment:        it is a spinlock since it is used in mmu notifier.
+
+Name:           kvm->srcu
+Type:           srcu lock
+Arch:           any
+Protects:       - kvm->memslots
+                - kvm->buses
+Comment:        The srcu read lock must be held while accessing memslots (e.g.
+                when using gfn_to_* functions) and while accessing in-kernel
+                MMIO/PIO address->device structure mapping (kvm->buses).
+                The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu
+                if it is needed by multiple functions.
diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX
index 5481c8ba3412..a39d06680e1c 100644
--- a/Documentation/vm/00-INDEX
+++ b/Documentation/vm/00-INDEX
@@ -4,10 +4,12 @@ active_mm.txt
         - An explanation from Linus about tsk->active_mm vs tsk->mm.
 balance
         - various information on memory balancing.
-hugepage-mmap.c
-        - Example app using huge page memory with the mmap system call.
-hugepage-shm.c
-        - Example app using huge page memory with Sys V shared memory system calls.
+cleancache.txt
+        - Intro to cleancache and page-granularity victim cache.
+frontswap.txt
+        - Outline frontswap, part of the transcendent memory frontend.
+highmem.txt
+        - Outline of highmem and common issues.
 hugetlbpage.txt
         - a brief summary of hugetlbpage support in the Linux kernel.
 hwpoison.txt
@@ -16,21 +18,23 @@ ksm.txt
         - how to use the Kernel Samepage Merging feature.
 locking
         - info on how locking and synchronization is done in the Linux vm code.
-map_hugetlb.c
-        - an example program that uses the MAP_HUGETLB mmap flag.
 numa
         - information about NUMA specific code in the Linux vm.
 numa_memory_policy.txt
         - documentation of concepts and APIs of the 2.6 memory policy support.
 overcommit-accounting
         - description of the Linux kernels overcommit handling modes.
-page-types.c
-        - Tool for querying page flags
 page_migration
         - description of page migration in NUMA systems.
 pagemap.txt
         - pagemap, from the userspace perspective
 slub.txt
         - a short users guide for SLUB.
+soft-dirty.txt
+        - short explanation for soft-dirty PTEs
+transhuge.txt
+        - Transparent Hugepage Support, alternative way of using hugepages.
 unevictable-lru.txt
         - Unevictable LRU infrastructure
+zswap.txt
+        - Intro to compressed cache for swap pages
diff --git a/Documentation/vm/split_page_table_lock b/Documentation/vm/split_page_table_lock
new file mode 100644
index 000000000000..6dea4fd5c961
--- /dev/null
+++ b/Documentation/vm/split_page_table_lock
@@ -0,0 +1,94 @@
+Split page table lock
+=====================
+
+Originally, mm->page_table_lock spinlock protected all page tables of the
+mm_struct. But this approach leads to poor page fault scalability of
+multi-threaded applications due high contention on the lock. To improve
+scalability, split page table lock was introduced.
+
+With split page table lock we have separate per-table lock to serialize
+access to the table. At the moment we use split lock for PTE and PMD
+tables. Access to higher level tables protected by mm->page_table_lock.
+
+There are helpers to lock/unlock a table and other accessor functions:
+ - pte_offset_map_lock()
+        maps pte and takes PTE table lock, returns pointer to the taken
+        lock;
+ - pte_unmap_unlock()
+        unlocks and unmaps PTE table;
+ - pte_alloc_map_lock()
+        allocates PTE table if needed and take the lock, returns pointer
+        to taken lock or NULL if allocation failed;
+ - pte_lockptr()
+        returns pointer to PTE table lock;
+ - pmd_lock()
+        takes PMD table lock, returns pointer to taken lock;
+ - pmd_lockptr()
+        returns pointer to PMD table lock;
+
+Split page table lock for PTE tables is enabled compile-time if
+CONFIG_SPLIT_PTLOCK_CPUS (usually 4) is less or equal to NR_CPUS.
+If split lock is disabled, all tables guaded by mm->page_table_lock.
+
+Split page table lock for PMD tables is enabled, if it's enabled for PTE
+tables and the architecture supports it (see below).
+
+Hugetlb and split page table lock
+---------------------------------
+
+Hugetlb can support several page sizes. We use split lock only for PMD
+level, but not for PUD.
+
+Hugetlb-specific helpers:
+ - huge_pte_lock()
+        takes pmd split lock for PMD_SIZE page, mm->page_table_lock
+        otherwise;
+ - huge_pte_lockptr()
+        returns pointer to table lock;
+
+Support of split page table lock by an architecture
+---------------------------------------------------
+
+There's no need in special enabling of PTE split page table lock:
+everything required is done by pgtable_page_ctor() and pgtable_page_dtor(),
+which must be called on PTE table allocation / freeing.
+
+Make sure the architecture doesn't use slab allocator for page table
+allocation: slab uses page->slab_cache and page->first_page for its pages.
+These fields share storage with page->ptl.
+
+PMD split lock only makes sense if you have more than two page table
+levels.
+
+PMD split lock enabling requires pgtable_pmd_page_ctor() call on PMD table
+allocation and pgtable_pmd_page_dtor() on freeing.
+
+Allocation usually happens in pmd_alloc_one(), freeing in pmd_free() and
+pmd_free_tlb(), but make sure you cover all PMD table allocation / freeing
+paths: i.e X86_PAE preallocate few PMDs on pgd_alloc().
+
+With everything in place you can set CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK.
+
+NOTE: pgtable_page_ctor() and pgtable_pmd_page_ctor() can fail -- it must
+be handled properly.
+
+page->ptl
+---------
+
+page->ptl is used to access split page table lock, where 'page' is struct
+page of page containing the table. It shares storage with page->private
+(and few other fields in union).
+
+To avoid increasing size of struct page and have best performance, we use a
+trick:
+ - if spinlock_t fits into long, we use page->ptr as spinlock, so we
+   can avoid indirect access and save a cache line.
+ - if size of spinlock_t is bigger then size of long, we use page->ptl as
+   pointer to spinlock_t and allocate it dynamically. This allows to use
+   split lock with enabled DEBUG_SPINLOCK or DEBUG_LOCK_ALLOC, but costs
+   one more cache line for indirect access;
+
+The spinlock_t allocated in pgtable_page_ctor() for PTE table and in
+pgtable_pmd_page_ctor() for PMD table.
+
+Please, never access page->ptl directly -- use appropriate helper.
diff --git a/Documentation/vm/zswap.txt b/Documentation/vm/zswap.txt
index 7e492d8aaeaf..00c3d31e7971 100644
--- a/Documentation/vm/zswap.txt
+++ b/Documentation/vm/zswap.txt
@@ -8,7 +8,7 @@ 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
+reclaim.  This interaction has not been 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.
 
@@ -23,7 +23,7 @@ Some potential benefits:
     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
+device when the compressed pool reaches its 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.
@@ -37,7 +37,7 @@ 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
+returned 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.
 
@@ -56,7 +56,7 @@ 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:
+controlled policy:
 * max_pool_percent - The maximum percentage of memory that the compressed
     pool can occupy.