142 files changed, 4479 insertions, 275 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index ceb1ff735469..8afe64fb2009 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -136,8 +136,6 @@ fault-injection/
        - dir with docs about the fault injection capabilities infrastructure.
 fb/
        - directory with info on the frame buffer graphics abstraction layer.
-feature-removal-schedule.txt
-        - list of files and features that are going to be removed.
 filesystems/
        - info on the vfs and the various filesystems that Linux supports.
 firmware_class/
diff --git a/Documentation/ABI/README b/Documentation/ABI/README
index 9feaf16f1617..10069828568b 100644
--- a/Documentation/ABI/README
+++ b/Documentation/ABI/README
@@ -36,9 +36,6 @@ The different levels of stability are:
        the kernel, but are marked to be removed at some later point in
        time.  The description of the interface will document the reason
        why it is obsolete and when it can be expected to be removed.
-        The file Documentation/feature-removal-schedule.txt may describe
-        some of these interfaces, giving a schedule for when they will
-        be removed.
  removed/
        This directory contains a list of the old interfaces that have
diff --git a/Documentation/ABI/stable/sysfs-devices-node b/Documentation/ABI/stable/sysfs-devices-node
index 49b82cad7003..ce259c13c36a 100644
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -1,7 +1,101 @@
+What:           /sys/devices/system/node/possible
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Nodes that could be possibly become online at some point.
+What:           /sys/devices/system/node/online
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Nodes that are online.
+What:           /sys/devices/system/node/has_normal_memory
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Nodes that have regular memory.
+What:           /sys/devices/system/node/has_cpu
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Nodes that have one or more CPUs.
+What:           /sys/devices/system/node/has_high_memory
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Nodes that have regular or high memory.
+                Depends on CONFIG_HIGHMEM.
 What:           /sys/devices/system/node/nodeX
 Date:           October 2002
 Contact:        Linux Memory Management list <linux-mm@kvack.org>
 Description:
                When CONFIG_NUMA is enabled, this is a directory containing
                information on node X such as what CPUs are local to the
-                node.
+                node. Each file is detailed next.
+What:           /sys/devices/system/node/nodeX/cpumap
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                The node's cpumap.
+What:           /sys/devices/system/node/nodeX/cpulist
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                The CPUs associated to the node.
+What:           /sys/devices/system/node/nodeX/meminfo
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Provides information about the node's distribution and memory
+                utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
+What:           /sys/devices/system/node/nodeX/numastat
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                The node's hit/miss statistics, in units of pages.
+                See Documentation/numastat.txt
+What:           /sys/devices/system/node/nodeX/distance
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                Distance between the node and all the other nodes
+                in the system.
+What:           /sys/devices/system/node/nodeX/vmstat
+Date:           October 2002
+Contact:        Linux Memory Management list <linux-mm@kvack.org>
+Description:
+                The node's zoned virtual memory statistics.
+                This is a superset of numastat.
+What:           /sys/devices/system/node/nodeX/compact
+Date:           February 2010
+Contact:        Mel Gorman <mel@csn.ul.ie>
+Description:
+                When this file is written to, all memory within that node
+                will be compacted. When it completes, memory will be freed
+                into blocks which have as many contiguous pages as possible
+What:           /sys/devices/system/node/nodeX/scan_unevictable_pages
+Date:           October 2008
+Contact:        Lee Schermerhorn <lee.schermerhorn@hp.com>
+Description:
+                When set, it triggers scanning the node's unevictable lists
+                and move any pages that have become evictable onto the respective
+                zone's inactive list. See mm/vmscan.c
+What:           /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
+Date:           December 2009
+Contact:        Lee Schermerhorn <lee.schermerhorn@hp.com>
+Description:
+                The node's huge page size control/query attributes.
+                See Documentation/vm/hugetlbpage.txt
+\ No newline at end of file
diff --git a/Documentation/ABI/stable/sysfs-driver-ib_srp b/Documentation/ABI/stable/sysfs-driver-ib_srp
new file mode 100644
index 000000000000..481aae95c7d1
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-driver-ib_srp
@@ -0,0 +1,156 @@
+What:           /sys/class/infiniband_srp/srp-<hca>-<port_number>/add_target
+Date:           January 2, 2006
+KernelVersion:  2.6.15
+Contact:        linux-rdma@vger.kernel.org
+Description:    Interface for making ib_srp connect to a new target.
+                One can request ib_srp to connect to a new target by writing
+                a comma-separated list of login parameters to this sysfs
+                attribute. The supported parameters are:
+                * id_ext, a 16-digit hexadecimal number specifying the eight
+                  byte identifier extension in the 16-byte SRP target port
+                  identifier. The target port identifier is sent by ib_srp
+                  to the target in the SRP_LOGIN_REQ request.
+                * ioc_guid, a 16-digit hexadecimal number specifying the eight
+                  byte I/O controller GUID portion of the 16-byte target port
+                  identifier.
+                * dgid, a 32-digit hexadecimal number specifying the
+                  destination GID.
+                * pkey, a four-digit hexadecimal number specifying the
+                  InfiniBand partition key.
+                * service_id, a 16-digit hexadecimal number specifying the
+                  InfiniBand service ID used to establish communication with
+                  the SRP target. How to find out the value of the service ID
+                  is specified in the documentation of the SRP target.
+                * max_sect, a decimal number specifying the maximum number of
+                  512-byte sectors to be transferred via a single SCSI command.
+                * max_cmd_per_lun, a decimal number specifying the maximum
+                  number of outstanding commands for a single LUN.
+                * io_class, a hexadecimal number specifying the SRP I/O class.
+                  Must be either 0xff00 (rev 10) or 0x0100 (rev 16a). The I/O
+                  class defines the format of the SRP initiator and target
+                  port identifiers.
+                * initiator_ext, a 16-digit hexadecimal number specifying the
+                  identifier extension portion of the SRP initiator port
+                  identifier. This data is sent by the initiator to the target
+                  in the SRP_LOGIN_REQ request.
+                * cmd_sg_entries, a number in the range 1..255 that specifies
+                  the maximum number of data buffer descriptors stored in the
+                  SRP_CMD information unit itself. With allow_ext_sg=0 the
+                  parameter cmd_sg_entries defines the maximum S/G list length
+                  for a single SRP_CMD, and commands whose S/G list length
+                  exceeds this limit after S/G list collapsing will fail.
+                * allow_ext_sg, whether ib_srp is allowed to include a partial
+                  memory descriptor list in an SRP_CMD instead of the entire
+                  list. If a partial memory descriptor list has been included
+                  in an SRP_CMD the remaining memory descriptors are
+                  communicated from initiator to target via an additional RDMA
+                  transfer. Setting allow_ext_sg to 1 increases the maximum
+                  amount of data that can be transferred between initiator and
+                  target via a single SCSI command. Since not all SRP target
+                  implementations support partial memory descriptor lists the
+                  default value for this option is 0.
+                * sg_tablesize, a number in the range 1..2048 specifying the
+                  maximum S/G list length the SCSI layer is allowed to pass to
+                  ib_srp. Specifying a value that exceeds cmd_sg_entries is
+                  only safe with partial memory descriptor list support enabled
+                  (allow_ext_sg=1).
+What:           /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
+Date:           January 2, 2006
+KernelVersion:  2.6.15
+Contact:        linux-rdma@vger.kernel.org
+Description:    HCA name (<hca>).
+What:           /sys/class/infiniband_srp/srp-<hca>-<port_number>/port
+Date:           January 2, 2006
+KernelVersion:  2.6.15
+Contact:        linux-rdma@vger.kernel.org
+Description:    HCA port number (<port_number>).
+What:           /sys/class/scsi_host/host<n>/allow_ext_sg
+Date:           May 19, 2011
+KernelVersion:  2.6.39
+Contact:        linux-rdma@vger.kernel.org
+Description:    Whether ib_srp is allowed to include a partial memory
+                descriptor list in an SRP_CMD when communicating with an SRP
+                target.
+What:           /sys/class/scsi_host/host<n>/cmd_sg_entries
+Date:           May 19, 2011
+KernelVersion:  2.6.39
+Contact:        linux-rdma@vger.kernel.org
+Description:    Maximum number of data buffer descriptors that may be sent to
+                the target in a single SRP_CMD request.
+What:           /sys/class/scsi_host/host<n>/dgid
+Date:           June 17, 2006
+KernelVersion:  2.6.17
+Contact:        linux-rdma@vger.kernel.org
+Description:    InfiniBand destination GID used for communication with the SRP
+                target. Differs from orig_dgid if port redirection has happened.
+What:           /sys/class/scsi_host/host<n>/id_ext
+Date:           June 17, 2006
+KernelVersion:  2.6.17
+Contact:        linux-rdma@vger.kernel.org
+Description:    Eight-byte identifier extension portion of the 16-byte target
+                port identifier.
+What:           /sys/class/scsi_host/host<n>/ioc_guid
+Date:           June 17, 2006
+KernelVersion:  2.6.17
+Contact:        linux-rdma@vger.kernel.org
+Description:    Eight-byte I/O controller GUID portion of the 16-byte target
+                port identifier.
+What:           /sys/class/scsi_host/host<n>/local_ib_device
+Date:           November 29, 2006
+KernelVersion:  2.6.19
+Contact:        linux-rdma@vger.kernel.org
+Description:    Name of the InfiniBand HCA used for communicating with the
+                SRP target.
+What:           /sys/class/scsi_host/host<n>/local_ib_port
+Date:           November 29, 2006
+KernelVersion:  2.6.19
+Contact:        linux-rdma@vger.kernel.org
+Description:    Number of the HCA port used for communicating with the
+                SRP target.
+What:           /sys/class/scsi_host/host<n>/orig_dgid
+Date:           June 17, 2006
+KernelVersion:  2.6.17
+Contact:        linux-rdma@vger.kernel.org
+Description:    InfiniBand destination GID specified in the parameters
+                written to the add_target sysfs attribute.
+What:           /sys/class/scsi_host/host<n>/pkey
+Date:           June 17, 2006
+KernelVersion:  2.6.17
+Contact:        linux-rdma@vger.kernel.org
+Description:    A 16-bit number representing the InfiniBand partition key used
+                for communication with the SRP target.
+What:           /sys/class/scsi_host/host<n>/req_lim
+Date:           October 20, 2010
+KernelVersion:  2.6.36
+Contact:        linux-rdma@vger.kernel.org
+Description:    Number of requests ib_srp can send to the target before it has
+                to wait for more credits. For more information see also the
+                SRP credit algorithm in the SRP specification.
+What:           /sys/class/scsi_host/host<n>/service_id
+Date:           June 17, 2006
+KernelVersion:  2.6.17
+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>/zero_req_lim
+Date:           September 20, 2006
+KernelVersion:  2.6.18
+Contact:        linux-rdma@vger.kernel.org
+Description:    Number of times the initiator had to wait before sending a
+                request to the target because it ran out of credits. For more
+                information see also the SRP credit algorithm in the SRP
+                specification.
diff --git a/Documentation/ABI/stable/sysfs-transport-srp b/Documentation/ABI/stable/sysfs-transport-srp
new file mode 100644
index 000000000000..b36fb0dc13c8
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-transport-srp
@@ -0,0 +1,19 @@
+What:           /sys/class/srp_remote_ports/port-<h>:<n>/delete
+Date:           June 1, 2012
+KernelVersion:  3.7
+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>/port_id
+Date:           June 27, 2007
+KernelVersion:  2.6.24
+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>/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".
diff --git a/Documentation/ABI/testing/ima_policy b/Documentation/ABI/testing/ima_policy
index 986946613542..ec0a38ef3145 100644
--- a/Documentation/ABI/testing/ima_policy
+++ b/Documentation/ABI/testing/ima_policy
@@ -23,7 +23,7 @@ Description:
                        lsm:    [[subj_user=] [subj_role=] [subj_type=]
                                 [obj_user=] [obj_role=] [obj_type=]]
-                base:   func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK]
+                base:   func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
                        mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
                        fsmagic:= hex value
                        uid:= decimal value
@@ -53,6 +53,7 @@ Description:
                        measure func=BPRM_CHECK
                        measure func=FILE_MMAP mask=MAY_EXEC
                        measure func=FILE_CHECK mask=MAY_READ uid=0
+                        measure func=MODULE_CHECK uid=0
                        appraise fowner=0
                The default policy measures all executables in bprm_check,
diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
index dff1f48d252d..1ce5ae329c04 100644
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -222,3 +222,37 @@ Description:
                satisfied too.  Reading this attribute will show the current
                value of d3cold_allowed bit.  Writing this attribute will set
                the value of d3cold_allowed bit.
+What:           /sys/bus/pci/devices/.../sriov_totalvfs
+Date:           November 2012
+Contact:        Donald Dutile <ddutile@redhat.com>
+Description:
+                This file appears when a physical PCIe device supports SR-IOV.
+                Userspace applications can read this file to determine the
+                maximum number of Virtual Functions (VFs) a PCIe physical
+                function (PF) can support. Typically, this is the value reported
+                in the PF's SR-IOV extended capability structure's TotalVFs
+                element.  Drivers have the ability at probe time to reduce the
+                value read from this file via the pci_sriov_set_totalvfs()
+                function.
+What:           /sys/bus/pci/devices/.../sriov_numvfs
+Date:           November 2012
+Contact:        Donald Dutile <ddutile@redhat.com>
+Description:
+                This file appears when a physical PCIe device supports SR-IOV.
+                Userspace applications can read and write to this file to
+                determine and control the enablement or disablement of Virtual
+                Functions (VFs) on the physical function (PF). A read of this
+                file will return the number of VFs that are enabled on this PF.
+                A number written to this file will enable the specified
+                number of VFs. A userspace application would typically read the
+                file and check that the value is zero, and then write the number
+                of VFs that should be enabled on the PF; the value written
+                should be less than or equal to the value in the sriov_totalvfs
+                file. A userspace application wanting to disable the VFs would
+                write a zero to this file. The core ensures that valid values
+                are written to this file, and returns errors when values are not
+                valid.  For example, writing a 2 to this file when sriov_numvfs
+                is not 0 and not 2 already will return an error. Writing a 10
+                when the value of sriov_totalvfs is 8 will return an error.
diff --git a/Documentation/ABI/testing/sysfs-bus-rbd b/Documentation/ABI/testing/sysfs-bus-rbd
index 1cf2adf46b11..cd9213ccf3dc 100644
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -70,6 +70,10 @@ snap_*
        A directory per each snapshot
+parent
+        Information identifying the pool, image, and snapshot id for
+        the parent image in a layered rbd image (format 2 only).
 Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
 -------------------------------------------------------------
diff --git a/Documentation/ABI/testing/sysfs-devices-node b/Documentation/ABI/testing/sysfs-devices-node
deleted file mode 100644
index 453a210c3ceb..000000000000
--- a/Documentation/ABI/testing/sysfs-devices-node
+++ /dev/null
@@ -1,7 +0,0 @@
-What:           /sys/devices/system/node/nodeX/compact
-Date:           February 2010
-Contact:        Mel Gorman <mel@csn.ul.ie>
-Description:
-                When this file is written to, all memory within that node
-                will be compacted. When it completes, memory will be freed
-                into blocks which have as many contiguous pages as possible
diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt
index a0b6250add79..4a4fb295ceef 100644
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -468,11 +468,46 @@ To map a single region, you do:
        size_t size = buffer->len;
        dma_handle = dma_map_single(dev, addr, size, direction);
+        if (dma_mapping_error(dma_handle)) {
+                /*
+                 * reduce current DMA mapping usage,
+                 * delay and try again later or
+                 * reset driver.
+                 */
+                goto map_error_handling;
+        }
 and to unmap it:
        dma_unmap_single(dev, dma_handle, size, direction);
+You should call dma_mapping_error() as dma_map_single() could fail and return
+error. Not all dma implementations support dma_mapping_error() interface.
+However, it is a good practice to call dma_mapping_error() interface, which
+will invoke the generic mapping error check interface. Doing so will ensure
+that the mapping code will work correctly on all dma implementations without
+any dependency on the specifics of the underlying implementation. Using the
+returned address without checking for errors could result in failures ranging
+from panics to silent data corruption. Couple of example of incorrect ways to
+check for errors that make assumptions about the underlying dma implementation
+are as follows and these are applicable to dma_map_page() as well.
+Incorrect example 1:
+        dma_addr_t dma_handle;
+        dma_handle = dma_map_single(dev, addr, size, direction);
+        if ((dma_handle & 0xffff != 0) || (dma_handle >= 0x1000000)) {
+                goto map_error;
+        }
+Incorrect example 2:
+        dma_addr_t dma_handle;
+        dma_handle = dma_map_single(dev, addr, size, direction);
+        if (dma_handle == DMA_ERROR_CODE) {
+                goto map_error;
+        }
 You should call dma_unmap_single when the DMA activity is finished, e.g.
 from the interrupt which told you that the DMA transfer is done.
@@ -489,6 +524,14 @@ Specifically:
        size_t size = buffer->len;
        dma_handle = dma_map_page(dev, page, offset, size, direction);
+        if (dma_mapping_error(dma_handle)) {
+                /*
+                 * reduce current DMA mapping usage,
+                 * delay and try again later or
+                 * reset driver.
+                 */
+                goto map_error_handling;
+        }
        ...
@@ -496,6 +539,12 @@ Specifically:
 Here, "offset" means byte offset within the given page.
+You should call dma_mapping_error() as dma_map_page() could fail and return
+error as outlined under the dma_map_single() discussion.
+You should call dma_unmap_page when the DMA activity is finished, e.g.
+from the interrupt which told you that the DMA transfer is done.
 With scatterlists, you map a region gathered from several regions by:
        int i, count = dma_map_sg(dev, sglist, nents, direction);
@@ -578,6 +627,14 @@ to use the dma_sync_*() interfaces.
                dma_addr_t mapping;
                mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
+                if (dma_mapping_error(dma_handle)) {
+                        /*
+                         * reduce current DMA mapping usage,
+                         * delay and try again later or
+                         * reset driver.
+                         */
+                        goto map_error_handling;
+                }
                cp->rx_buf = buffer;
                cp->rx_len = len;
@@ -658,6 +715,75 @@ failure can be determined by:
                 * delay and try again later or
                 * reset driver.
                 */
+                goto map_error_handling;
+        }
+- unmap pages that are already mapped, when mapping error occurs in the middle
+  of a multiple page mapping attempt. These example are applicable to
+  dma_map_page() as well.
+Example 1:
+        dma_addr_t dma_handle1;
+        dma_addr_t dma_handle2;
+        dma_handle1 = dma_map_single(dev, addr, size, direction);
+        if (dma_mapping_error(dev, dma_handle1)) {
+                /*
+                 * reduce current DMA mapping usage,
+                 * delay and try again later or
+                 * reset driver.
+                 */
+                goto map_error_handling1;
+        }
+        dma_handle2 = dma_map_single(dev, addr, size, direction);
+        if (dma_mapping_error(dev, dma_handle2)) {
+                /*
+                 * reduce current DMA mapping usage,
+                 * delay and try again later or
+                 * reset driver.
+                 */
+                goto map_error_handling2;
+        }
+        ...
+        map_error_handling2:
+                dma_unmap_single(dma_handle1);
+        map_error_handling1:
+Example 2: (if buffers are allocated a loop, unmap all mapped buffers when
+            mapping error is detected in the middle)
+        dma_addr_t dma_addr;
+        dma_addr_t array[DMA_BUFFERS];
+        int save_index = 0;
+        for (i = 0; i < DMA_BUFFERS; i++) {
+                ...
+                dma_addr = dma_map_single(dev, addr, size, direction);
+                if (dma_mapping_error(dev, dma_addr)) {
+                        /*
+                         * reduce current DMA mapping usage,
+                         * delay and try again later or
+                         * reset driver.
+                         */
+                        goto map_error_handling;
+                }
+                array[i].dma_addr = dma_addr;
+                save_index++;
+        }
+        ...
+        map_error_handling:
+        for (i = 0; i < save_index; i++) {
+                ...
+                dma_unmap_single(array[i].dma_addr);
        }
 Networking drivers must call dev_kfree_skb to free the socket buffer
diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
index 66bd97a95f10..78a6c569d204 100644
--- a/Documentation/DMA-API.txt
+++ b/Documentation/DMA-API.txt
@@ -678,3 +678,15 @@ out of dma_debug_entries. These entries are preallocated at boot. The number
 of preallocated entries is defined per architecture. If it is too low for you
 boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
 architectural default.
+void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr);
+dma-debug interface debug_dma_mapping_error() to debug drivers that fail
+to check dma mapping errors on addresses returned by dma_map_single() and
+dma_map_page() interfaces. This interface clears a flag set by
+debug_dma_map_page() to indicate that dma_mapping_error() has been called by
+the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
+this flag is still set, prints warning message that includes call trace that
+leads up to the unmap. This interface can be called from dma_mapping_error()
+routines to enable dma mapping error check debugging.
diff --git a/Documentation/DMA-attributes.txt b/Documentation/DMA-attributes.txt
index f50309081ac7..e59480db9ee0 100644
--- a/Documentation/DMA-attributes.txt
+++ b/Documentation/DMA-attributes.txt
@@ -91,3 +91,12 @@ transferred to 'device' domain. This attribute can be also used for
 dma_unmap_{single,page,sg} functions family to force buffer to stay in
 device domain after releasing a mapping for it. Use this attribute with
 care!
+DMA_ATTR_FORCE_CONTIGUOUS
+-------------------------
+By default DMA-mapping subsystem is allowed to assemble the buffer
+allocated by dma_alloc_attrs() function from individual pages if it can
+be mapped as contiguous chunk into device dma address space. By
+specifing this attribute the allocated buffer is forced to be contiguous
+also in physical memory.
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index b0300529ab13..4ee2304f82f9 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1141,23 +1141,13 @@ int max_width, max_height;</synopsis>
            the <methodname>page_flip</methodname> operation will be called with a
            non-NULL <parameter>event</parameter> argument pointing to a
            <structname>drm_pending_vblank_event</structname> instance. Upon page
-            flip completion the driver must fill the
+            flip completion the driver must call <methodname>drm_send_vblank_event</methodname>
-            <parameter>event</parameter>::<structfield>event</structfield>
+            to fill in the event and send to wake up any waiting processes.
-            <structfield>sequence</structfield>, <structfield>tv_sec</structfield>
+            This can be performed with
-            and <structfield>tv_usec</structfield> fields with the associated
-            vertical blanking count and timestamp, add the event to the
-            <parameter>drm_file</parameter> list of events to be signaled, and wake
-            up any waiting process. This can be performed with
            <programlisting><![CDATA[
-            struct timeval now;
-            event->event.sequence = drm_vblank_count_and_time(..., &now);
-            event->event.tv_sec = now.tv_sec;
-            event->event.tv_usec = now.tv_usec;
            spin_lock_irqsave(&dev->event_lock, flags);
-            list_add_tail(&event->base.link, &event->base.file_priv->event_list);
+            ...
-            wake_up_interruptible(&event->base.file_priv->event_wait);
+            drm_send_vblank_event(dev, pipe, event);
            spin_unlock_irqrestore(&dev->event_lock, flags);
            ]]></programlisting>
          </para>
@@ -1621,10 +1611,10 @@ void intel_crt_init(struct drm_device *dev)
    </sect2>
  </sect1>
-  <!-- Internals: mid-layer helper functions -->
+  <!-- Internals: kms helper functions -->
  <sect1>
-    <title>Mid-layer Helper Functions</title>
+    <title>Mode Setting Helper Functions</title>
    <para>
      The CRTC, encoder and connector functions provided by the drivers
      implement the DRM API. They're called by the DRM core and ioctl handlers
@@ -2106,6 +2096,21 @@ void intel_crt_init(struct drm_device *dev)
        </listitem>
      </itemizedlist>
    </sect2>
+    <sect2>
+      <title>Modeset Helper Functions Reference</title>
+!Edrivers/gpu/drm/drm_crtc_helper.c
+    </sect2>
+    <sect2>
+      <title>fbdev Helper Functions Reference</title>
+!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
+!Edrivers/gpu/drm/drm_fb_helper.c
+    </sect2>
+    <sect2>
+      <title>Display Port Helper Functions Reference</title>
+!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
+!Iinclude/drm/drm_dp_helper.h
+!Edrivers/gpu/drm/drm_dp_helper.c
+    </sect2>
  </sect1>
  <!-- Internals: vertical blanking -->
diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl
index 00687ee9d363..f75ab4c1b281 100644
--- a/Documentation/DocBook/kernel-api.tmpl
+++ b/Documentation/DocBook/kernel-api.tmpl
@@ -58,6 +58,9 @@
     <sect1><title>String Conversions</title>
 !Elib/vsprintf.c
+!Finclude/linux/kernel.h kstrtol
+!Finclude/linux/kernel.h kstrtoul
+!Elib/kstrtox.c
     </sect1>
     <sect1><title>String Manipulation</title>
 <!-- All functions are exported at now
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index 4fdf6b562d1c..3dd9e78815d1 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2586,6 +2586,13 @@ ioctls.</para>
          <para>Vendor and device specific media bus pixel formats.
            <xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
        </listitem>
+        <listitem>
+          <para>Importing DMABUF file descriptors as a new IO method described
+          in <xref linkend="dmabuf" />.</para>
+        </listitem>
+        <listitem>
+          <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
+        </listitem>
      </itemizedlist>
    </section>
diff --git a/Documentation/DocBook/media/v4l/driver.xml b/Documentation/DocBook/media/v4l/driver.xml
index eacafe312cd2..7c6638bacedb 100644
--- a/Documentation/DocBook/media/v4l/driver.xml
+++ b/Documentation/DocBook/media/v4l/driver.xml
@@ -116,7 +116,7 @@ my_suspend              (struct pci_dev *               pci_dev,
        return 0; /* a negative value on error, 0 on success. */
 }
-static void __devexit
+static void
 my_remove               (struct pci_dev *               pci_dev)
 {
        my_device *my = pci_get_drvdata (pci_dev);
@@ -124,7 +124,7 @@ my_remove               (struct pci_dev *               pci_dev)
        /* Describe me. */
 }
-static int __devinit
+static int
 my_probe                (struct pci_dev *               pci_dev,
                         const struct pci_device_id *   pci_id)
 {
@@ -157,7 +157,7 @@ my_pci_driver = {
        .id_table = my_pci_device_ids,
        .probe    = my_probe,
-        .remove   = __devexit_p (my_remove),
+        .remove   = my_remove,
        /* Power management functions. */
        .suspend  = my_suspend,
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index b5d1cbdc558b..388a34032653 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By default
 outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
 given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
 returns immediately with an &EAGAIN; when no buffer is available. The
-&func-select; or &func-poll; function are always available.</para>
+&func-select; or &func-poll; functions are always available.</para>
    <para>To start and stop capturing or output applications call the
 &VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,165 @@ rest should be evident.</para>
      </footnote></para>
  </section>
+  <section id="dmabuf">
+    <title>Streaming I/O (DMA buffer importing)</title>
+    <note>
+      <title>Experimental</title>
+      <para>This is an <link linkend="experimental"> experimental </link>
+      interface and may change in the future.</para>
+    </note>
+<para>The DMABUF framework provides a generic method for sharing buffers
+between multiple devices. Device drivers that support DMABUF can export a DMA
+buffer to userspace as a file descriptor (known as the exporter role), import a
+DMA buffer from userspace using a file descriptor previously exported for a
+different or the same device (known as the importer role), or both. This
+section describes the DMABUF importer role API in V4L2.</para>
+    <para>Refer to <link linked="vidioc-expbuf"> DMABUF exporting </link> for
+details about exporting V4L2 buffers as DMABUF file descriptors.</para>
+<para>Input and output devices support the streaming I/O method when the
+<constant>V4L2_CAP_STREAMING</constant> flag in the
+<structfield>capabilities</structfield> field of &v4l2-capability; returned by
+the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
+DMABUF file descriptors is supported is determined by calling the
+&VIDIOC-REQBUFS; ioctl with the memory type set to
+<constant>V4L2_MEMORY_DMABUF</constant>.</para>
+    <para>This I/O method is dedicated to sharing DMA buffers between different
+devices, which may be V4L devices or other video-related devices (e.g. DRM).
+Buffers (planes) are allocated by a driver on behalf of an application. Next,
+these buffers are exported to the application as file descriptors using an API
+which is specific for an allocator driver.  Only such file descriptor are
+exchanged. The descriptors and meta-information are passed in &v4l2-buffer; (or
+in &v4l2-plane; in the multi-planar API case).  The driver must be switched
+into DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer
+type.</para>
+    <example>
+      <title>Initiating streaming I/O with DMABUF file descriptors</title>
+      <programlisting>
+&v4l2-requestbuffers; reqbuf;
+memset(&amp;reqbuf, 0, sizeof (reqbuf));
+reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+reqbuf.memory = V4L2_MEMORY_DMABUF;
+reqbuf.count = 1;
+if (ioctl(fd, &VIDIOC-REQBUFS;, &amp;reqbuf) == -1) {
+        if (errno == EINVAL)
+                printf("Video capturing or DMABUF streaming is not supported\n");
+        else
+                perror("VIDIOC_REQBUFS");
+        exit(EXIT_FAILURE);
+}
+      </programlisting>
+    </example>
+    <para>The buffer (plane) file descriptor is passed on the fly with the
+&VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
+associated with a different DMABUF descriptor. Although buffers are commonly
+cycled, applications can pass a different DMABUF descriptor at each
+<constant>VIDIOC_QBUF</constant> call.</para>
+    <example>
+      <title>Queueing DMABUF using single plane API</title>
+      <programlisting>
+int buffer_queue(int v4lfd, int index, int dmafd)
+{
+        &v4l2-buffer; buf;
+        memset(&amp;buf, 0, sizeof buf);
+        buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+        buf.memory = V4L2_MEMORY_DMABUF;
+        buf.index = index;
+        buf.m.fd = dmafd;
+        if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
+                perror("VIDIOC_QBUF");
+                return -1;
+        }
+        return 0;
+}
+      </programlisting>
+    </example>
+    <example>
+      <title>Queueing DMABUF using multi plane API</title>
+      <programlisting>
+int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
+{
+        &v4l2-buffer; buf;
+        &v4l2-plane; planes[VIDEO_MAX_PLANES];
+        int i;
+        memset(&amp;buf, 0, sizeof buf);
+        buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
+        buf.memory = V4L2_MEMORY_DMABUF;
+        buf.index = index;
+        buf.m.planes = planes;
+        buf.length = n_planes;
+        memset(&amp;planes, 0, sizeof planes);
+        for (i = 0; i &lt; n_planes; ++i)
+                buf.m.planes[i].m.fd = dmafd[i];
+        if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
+                perror("VIDIOC_QBUF");
+                return -1;
+        }
+        return 0;
+}
+      </programlisting>
+    </example>
+    <para>Captured or displayed buffers are dequeued with the
+&VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any
+time between the completion of the DMA and this ioctl. The memory is
+also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
+when the device is closed.</para>
+    <para>For capturing applications it is customary to enqueue a
+number of empty buffers, to start capturing and enter the read loop.
+Here the application waits until a filled buffer can be dequeued, and
+re-enqueues the buffer when the data is no longer needed. Output
+applications fill and enqueue buffers, when enough buffers are stacked
+up output is started. In the write loop, when the application
+runs out of free buffers it must wait until an empty buffer can be
+dequeued and reused. Two methods exist to suspend execution of the
+application until one or more buffers can be dequeued. By default
+<constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the
+outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
+given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
+returns immediately with an &EAGAIN; when no buffer is available. The
+&func-select; and &func-poll; functions are always available.</para>
+    <para>To start and stop capturing or displaying applications call the
+&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that
+<constant>VIDIOC_STREAMOFF</constant> removes all buffers from both queues and
+unlocks all buffers as a side effect. Since there is no notion of doing
+anything "now" on a multitasking system, if an application needs to synchronize
+with another event it should examine the &v4l2-buffer;
+<structfield>timestamp</structfield> of captured buffers, or set the field
+before enqueuing buffers for output.</para>
+    <para>Drivers implementing DMABUF importing I/O must support the
+<constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
+<constant>VIDIOC_DQBUF</constant>, <constant>VIDIOC_STREAMON</constant> and
+<constant>VIDIOC_STREAMOFF</constant> ioctls, and the
+<function>select()</function> and <function>poll()</function> functions.</para>
+  </section>
  <section id="async">
    <title>Asynchronous I/O</title>
@@ -673,6 +832,14 @@ memory, set by the application. See <xref linkend="userp" /> for details.
            <structname>v4l2_buffer</structname> structure.</entry>
          </row>
          <row>
+            <entry></entry>
+            <entry>int</entry>
+            <entry><structfield>fd</structfield></entry>
+            <entry>For the single-plane API and when
+<structfield>memory</structfield> is <constant>V4L2_MEMORY_DMABUF</constant> this
+is the file descriptor associated with a DMABUF buffer.</entry>
+          </row>
+          <row>
            <entry>__u32</entry>
            <entry><structfield>length</structfield></entry>
            <entry></entry>
@@ -744,6 +911,15 @@ should set this to 0.</entry>
              </entry>
          </row>
          <row>
+            <entry></entry>
+            <entry>int</entry>
+            <entry><structfield>fd</structfield></entry>
+            <entry>When the memory type in the containing &v4l2-buffer; is
+                <constant>V4L2_MEMORY_DMABUF</constant>, this is a file
+                descriptor associated with a DMABUF buffer, similar to the
+                <structfield>fd</structfield> field in &v4l2-buffer;.</entry>
+          </row>
+          <row>
            <entry>__u32</entry>
            <entry><structfield>data_offset</structfield></entry>
            <entry></entry>
@@ -923,7 +1099,7 @@ application. Drivers set or clear this flag when the
          </row>
          <row>
            <entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
-            <entry>0x0400</entry>
+            <entry>0x0800</entry>
            <entry>Caches do not have to be invalidated for this buffer.
 Typically applications shall use this flag if the data captured in the buffer
 is not going to be touched by the CPU, instead the buffer will, probably, be
@@ -932,7 +1108,7 @@ passed on to a DMA-capable hardware unit for further processing or output.
          </row>
          <row>
            <entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
-            <entry>0x0800</entry>
+            <entry>0x1000</entry>
            <entry>Caches do not have to be cleaned for this buffer.
 Typically applications shall use this flag for output buffers if the data
 in this buffer has not been created by the CPU but by some DMA-capable unit,
@@ -964,6 +1140,12 @@ pointer</link> I/O.</entry>
            <entry>3</entry>
            <entry>[to do]</entry>
          </row>
+          <row>
+            <entry><constant>V4L2_MEMORY_DMABUF</constant></entry>
+            <entry>4</entry>
+            <entry>The buffer is used for <link linkend="dmabuf">DMA shared
+buffer</link> I/O.</entry>
+          </row>
        </tbody>
      </tgroup>
    </table>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 10ccde9d16d0..4d110b1ad3e9 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -543,6 +543,7 @@ and discussions on the V4L mailing list.</revremark>
    &sub-enuminput;
    &sub-enumoutput;
    &sub-enumstd;
+    &sub-expbuf;
    &sub-g-audio;
    &sub-g-audioout;
    &sub-g-crop;
diff --git a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
index a8cda1acacd9..cd9943672434 100644
--- a/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
@@ -6,7 +6,8 @@
  <refnamediv>
    <refname>VIDIOC_CREATE_BUFS</refname>
-    <refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose>
+    <refpurpose>Create buffers for Memory Mapped or User Pointer or DMA Buffer
+    I/O</refpurpose>
  </refnamediv>
  <refsynopsisdiv>
@@ -55,11 +56,11 @@
    </note>
    <para>This ioctl is used to create buffers for <link linkend="mmap">memory
-mapped</link> or <link linkend="userp">user pointer</link>
+mapped</link> or <link linkend="userp">user pointer</link> or <link
-I/O. It can be used as an alternative or in addition to the
+linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in
-<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
+addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
-is required. This ioctl can be called multiple times to create buffers of
+control over buffers is required. This ioctl can be called multiple times to
-different sizes.</para>
+create buffers of different sizes.</para>
    <para>To allocate device buffers applications initialize relevant fields of
 the <structname>v4l2_create_buffers</structname> structure. They set the
@@ -109,7 +110,8 @@ information.</para>
            <entry>__u32</entry>
            <entry><structfield>memory</structfield></entry>
            <entry>Applications set this field to
-<constant>V4L2_MEMORY_MMAP</constant> or
+<constant>V4L2_MEMORY_MMAP</constant>,
+<constant>V4L2_MEMORY_DMABUF</constant> or
 <constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
 /></entry>
          </row>
diff --git a/Documentation/DocBook/media/v4l/vidioc-expbuf.xml b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
new file mode 100644
index 000000000000..72dfbd20a802
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/vidioc-expbuf.xml
@@ -0,0 +1,212 @@
+<refentry id="vidioc-expbuf">
+  <refmeta>
+    <refentrytitle>ioctl VIDIOC_EXPBUF</refentrytitle>
+    &manvol;
+  </refmeta>
+  <refnamediv>
+    <refname>VIDIOC_EXPBUF</refname>
+    <refpurpose>Export a buffer as a DMABUF file descriptor.</refpurpose>
+  </refnamediv>
+  <refsynopsisdiv>
+    <funcsynopsis>
+      <funcprototype>
+        <funcdef>int <function>ioctl</function></funcdef>
+        <paramdef>int <parameter>fd</parameter></paramdef>
+        <paramdef>int <parameter>request</parameter></paramdef>
+        <paramdef>struct v4l2_exportbuffer *<parameter>argp</parameter></paramdef>
+      </funcprototype>
+    </funcsynopsis>
+  </refsynopsisdiv>
+  <refsect1>
+    <title>Arguments</title>
+    <variablelist>
+      <varlistentry>
+        <term><parameter>fd</parameter></term>
+        <listitem>
+          <para>&fd;</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><parameter>request</parameter></term>
+        <listitem>
+          <para>VIDIOC_EXPBUF</para>
+        </listitem>
+      </varlistentry>
+      <varlistentry>
+        <term><parameter>argp</parameter></term>
+        <listitem>
+          <para></para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+  <refsect1>
+    <title>Description</title>
+    <note>
+      <title>Experimental</title>
+      <para>This is an <link linkend="experimental"> experimental </link>
+      interface and may change in the future.</para>
+    </note>
+<para>This ioctl is an extension to the <link linkend="mmap">memory
+mapping</link> I/O method, therefore it is available only for
+<constant>V4L2_MEMORY_MMAP</constant> buffers.  It can be used to export a
+buffer as a DMABUF file at any time after buffers have been allocated with the
+&VIDIOC-REQBUFS; ioctl.</para>
+<para> To export a buffer, applications fill &v4l2-exportbuffer;.  The
+<structfield> type </structfield> field is set to the same buffer type as was
+previously used with  &v4l2-requestbuffers;<structfield> type </structfield>.
+Applications must also set the <structfield> index </structfield> field. Valid
+index numbers range from zero to the number of buffers allocated with
+&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
+minus one.  For the multi-planar API, applications set the <structfield> plane
+</structfield> field to the index of the plane to be exported. Valid planes
+range from zero to the maximal number of valid planes for the currently active
+format. For the single-planar API, applications must set <structfield> plane
+</structfield> to zero.  Additional flags may be posted in the <structfield>
+flags </structfield> field.  Refer to a manual for open() for details.
+Currently only O_CLOEXEC is supported.  All other fields must be set to zero.
+In the case of multi-planar API, every plane is exported separately using
+multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
+<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
+</structfield> field will be set by a driver.  This is a DMABUF file
+descriptor. The application may pass it to other DMABUF-aware devices. Refer to
+<link linkend="dmabuf">DMABUF importing</link> for details about importing
+DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
+is no longer used to allow the associated memory to be reclaimed. </para>
+  </refsect1>
+  <refsect1>
+   <section>
+      <title>Examples</title>
+      <example>
+        <title>Exporting a buffer.</title>
+        <programlisting>
+int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
+{
+        &v4l2-exportbuffer; expbuf;
+        memset(&amp;expbuf, 0, sizeof(expbuf));
+        expbuf.type = bt;
+        expbuf.index = index;
+        if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
+                perror("VIDIOC_EXPBUF");
+                return -1;
+        }
+        *dmafd = expbuf.fd;
+        return 0;
+}
+        </programlisting>
+      </example>
+      <example>
+        <title>Exporting a buffer using the multi-planar API.</title>
+        <programlisting>
+int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
+        int dmafd[], int n_planes)
+{
+        int i;
+        for (i = 0; i &lt; n_planes; ++i) {
+                &v4l2-exportbuffer; expbuf;
+                memset(&amp;expbuf, 0, sizeof(expbuf));
+                expbuf.type = bt;
+                expbuf.index = index;
+                expbuf.plane = i;
+                if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
+                        perror("VIDIOC_EXPBUF");
+                        while (i)
+                                close(dmafd[--i]);
+                        return -1;
+                }
+                dmafd[i] = expbuf.fd;
+        }
+        return 0;
+}
+        </programlisting>
+      </example>
+   </section>
+  </refsect1>
+  <refsect1>
+    <table pgwide="1" frame="none" id="v4l2-exportbuffer">
+      <title>struct <structname>v4l2_exportbuffer</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>type</structfield></entry>
+            <entry>Type of the buffer, same as &v4l2-format;
+<structfield>type</structfield> or &v4l2-requestbuffers;
+<structfield>type</structfield>, set by the application. See <xref
+linkend="v4l2-buf-type" /></entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>index</structfield></entry>
+            <entry>Number of the buffer, set by the application. This field is
+only used for <link linkend="mmap">memory mapping</link> I/O and can range from
+zero to the number of buffers allocated with the &VIDIOC-REQBUFS; and/or
+&VIDIOC-CREATE-BUFS; ioctls. </entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>plane</structfield></entry>
+            <entry>Index of the plane to be exported when using the
+multi-planar API. Otherwise this value must be set to zero. </entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>flags</structfield></entry>
+            <entry>Flags for the newly created file, currently only <constant>
+O_CLOEXEC </constant> is supported, refer to the manual of open() for more
+details.</entry>
+          </row>
+          <row>
+            <entry>__s32</entry>
+            <entry><structfield>fd</structfield></entry>
+            <entry>The DMABUF file descriptor associated with a buffer. Set by
+                the driver.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved[11]</structfield></entry>
+            <entry>Reserved field for future use. Must be set to zero.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+  </refsect1>
+  <refsect1>
+    &return-value;
+    <variablelist>
+      <varlistentry>
+        <term><errorcode>EINVAL</errorcode></term>
+        <listitem>
+          <para>A queue is not in MMAP mode or DMABUF exporting is not
+supported or <structfield> flags </structfield> or <structfield> type
+</structfield> or <structfield> index </structfield> or <structfield> plane
+</structfield> fields are invalid.</para>
+        </listitem>
+      </varlistentry>
+    </variablelist>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
index 2d37abefce13..3504a7f2f382 100644
--- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
@@ -109,6 +109,23 @@ they cannot be swapped out to disk. Buffers remain locked until
 dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is
 called, or until the device is closed.</para>
+    <para>To enqueue a <link linkend="dmabuf">DMABUF</link> buffer applications
+set the <structfield>memory</structfield> field to
+<constant>V4L2_MEMORY_DMABUF</constant> and the <structfield>m.fd</structfield>
+field to a file descriptor associated with a DMABUF buffer. When the
+multi-planar API is used the <structfield>m.fd</structfield> fields of the
+passed array of &v4l2-plane; have to be used instead. When
+<constant>VIDIOC_QBUF</constant> is called with a pointer to this structure the
+driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the
+<constant>V4L2_BUF_FLAG_MAPPED</constant> and
+<constant>V4L2_BUF_FLAG_DONE</constant> flags in the
+<structfield>flags</structfield> field, or it returns an error code.  This
+ioctl locks the buffer. Locking a buffer means passing it to a driver for a
+hardware access (usually DMA).  If an application accesses (reads/writes) a
+locked buffer then the result is undefined.  Buffers remain locked until
+dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or
+until the device is closed.</para>
    <para>Applications call the <constant>VIDIOC_DQBUF</constant>
 ioctl to dequeue a filled (capturing) or displayed (output) buffer
 from the driver's outgoing queue. They just set the
diff --git a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
index 2b50ef2007f3..78a06a9a5ece 100644
--- a/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
@@ -48,28 +48,30 @@
  <refsect1>
    <title>Description</title>
-    <para>This ioctl is used to initiate <link linkend="mmap">memory
+<para>This ioctl is used to initiate <link linkend="mmap">memory mapped</link>,
-mapped</link> or <link linkend="userp">user pointer</link>
+<link linkend="userp">user pointer</link> or <link
-I/O. Memory mapped buffers are located in device memory and must be
+linkend="dmabuf">DMABUF</link> based I/O.  Memory mapped buffers are located in
-allocated with this ioctl before they can be mapped into the
+device memory and must be allocated with this ioctl before they can be mapped
-application's address space. User buffers are allocated by
+into the application's address space. User buffers are allocated by
-applications themselves, and this ioctl is merely used to switch the
+applications themselves, and this ioctl is merely used to switch the driver
-driver into user pointer I/O mode and to setup some internal structures.</para>
+into user pointer I/O mode and to setup some internal structures.
+Similarly, DMABUF buffers are allocated by applications through a device
+driver, and this ioctl only configures the driver into DMABUF I/O mode without
+performing any direct allocation.</para>
-    <para>To allocate device buffers applications initialize all
+    <para>To allocate device buffers applications initialize all fields of the
-fields of the <structname>v4l2_requestbuffers</structname> structure.
+<structname>v4l2_requestbuffers</structname> structure.  They set the
-They set the <structfield>type</structfield> field to the respective
+<structfield>type</structfield> field to the respective stream or buffer type,
-stream or buffer type, the <structfield>count</structfield> field to
+the <structfield>count</structfield> field to the desired number of buffers,
-the desired number of buffers, <structfield>memory</structfield>
+<structfield>memory</structfield> must be set to the requested I/O method and
-must be set to the requested I/O method and the <structfield>reserved</structfield> array
+the <structfield>reserved</structfield> array must be zeroed. When the ioctl is
-must be zeroed. When the ioctl
+called with a pointer to this structure the driver will attempt to allocate the
-is called with a pointer to this structure the driver will attempt to allocate
+requested number of buffers and it stores the actual number allocated in the
-the requested number of buffers and it stores the actual number
+<structfield>count</structfield> field. It can be smaller than the number
-allocated in the <structfield>count</structfield> field. It can be
+requested, even zero, when the driver runs out of free memory. A larger number
-smaller than the number requested, even zero, when the driver runs out
+is also possible when the driver requires more buffers to function correctly.
-of free memory. A larger number is also possible when the driver requires
+For example video output requires at least two buffers, one displayed and one
-more buffers to function correctly. For example video output requires at least two buffers,
+filled by the application.</para>
-one displayed and one filled by the application.</para>
    <para>When the I/O method is not supported the ioctl
 returns an &EINVAL;.</para>
@@ -102,7 +104,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
            <entry>__u32</entry>
            <entry><structfield>memory</structfield></entry>
            <entry>Applications set this field to
-<constant>V4L2_MEMORY_MMAP</constant> or
+<constant>V4L2_MEMORY_MMAP</constant>,
+<constant>V4L2_MEMORY_DMABUF</constant> or
 <constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
 />.</entry>
          </row>
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt
index fc73ef5d65b8..86551cc72e03 100644
--- a/Documentation/PCI/pci-iov-howto.txt
+++ b/Documentation/PCI/pci-iov-howto.txt
@@ -2,6 +2,9 @@
                Copyright (C) 2009 Intel Corporation
                    Yu Zhao <yu.zhao@intel.com>
+                Update: November 2012
+                        -- sysfs-based SRIOV enable-/disable-ment
+                Donald Dutile <ddutile@redhat.com>
 1. Overview
@@ -24,10 +27,21 @@ real existing PCI device.
 2.1 How can I enable SR-IOV capability
-The device driver (PF driver) will control the enabling and disabling
+Multiple methods are available for SR-IOV enablement.
-of the capability via API provided by SR-IOV core. If the hardware
+In the first method, the device driver (PF driver) will control the
-has SR-IOV capability, loading its PF driver would enable it and all
+enabling and disabling of the capability via API provided by SR-IOV core.
-VFs associated with the PF.
+If the hardware has SR-IOV capability, loading its PF driver would
+enable it and all VFs associated with the PF.  Some PF drivers require
+a module parameter to be set to determine the number of VFs to enable.
+In the second method, a write to the sysfs file sriov_numvfs will
+enable and disable the VFs associated with a PCIe PF.  This method
+enables per-PF, VF enable/disable values versus the first method,
+which applies to all PFs of the same device.  Additionally, the
+PCI SRIOV core support ensures that enable/disable operations are
+valid to reduce duplication in multiple drivers for the same
+checks, e.g., check numvfs == 0 if enabling VFs, ensure
+numvfs <= totalvfs.
+The second method is the recommended method for new/future VF devices.
 2.2 How can I use the Virtual Functions
@@ -40,20 +54,29 @@ requires device driver that is same as a normal PCI device's.
 3.1 SR-IOV API
 To enable SR-IOV capability:
+(a) For the first method, in the driver:
        int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
        'nr_virtfn' is number of VFs to be enabled.
+(b) For the second method, from sysfs:
+        echo 'nr_virtfn' > \
+        /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
 To disable SR-IOV capability:
+(a) For the first method, in the driver:
        void pci_disable_sriov(struct pci_dev *dev);
+(b) For the second method, from sysfs:
+        echo  0 > \
+        /sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
 To notify SR-IOV core of Virtual Function Migration:
+(a) In the driver:
        irqreturn_t pci_sriov_migration(struct pci_dev *dev);
 3.2 Usage example
 Following piece of code illustrates the usage of the SR-IOV API.
-static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
+static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
        pci_enable_sriov(dev, NR_VIRTFN);
@@ -62,7 +85,7 @@ static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *
        return 0;
 }
-static void __devexit dev_remove(struct pci_dev *dev)
+static void dev_remove(struct pci_dev *dev)
 {
        pci_disable_sriov(dev);
@@ -88,12 +111,29 @@ static void dev_shutdown(struct pci_dev *dev)
        ...
 }
+static int dev_sriov_configure(struct pci_dev *dev, int numvfs)
+{
+        if (numvfs > 0) {
+                ...
+                pci_enable_sriov(dev, numvfs);
+                ...
+                return numvfs;
+        }
+        if (numvfs == 0) {
+                ....
+                pci_disable_sriov(dev);
+                ...
+                return 0;
+        }
+}
 static struct pci_driver dev_driver = {
        .name =         "SR-IOV Physical Function driver",
        .id_table =     dev_id_table,
        .probe =        dev_probe,
-        .remove =       __devexit_p(dev_remove),
+        .remove =       dev_remove,
        .suspend =      dev_suspend,
        .resume =       dev_resume,
        .shutdown =     dev_shutdown,
+        .sriov_configure = dev_sriov_configure,
 };
diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt
index aa09e5476bba..bccf602a87f5 100644
--- a/Documentation/PCI/pci.txt
+++ b/Documentation/PCI/pci.txt
@@ -183,12 +183,6 @@ Please mark the initialization and cleanup functions where appropriate
                        initializes.
        __exit          Exit code. Ignored for non-modular drivers.
-        __devinit       Device initialization code.
-                        Identical to __init if the kernel is not compiled
-                        with CONFIG_HOTPLUG, normal function otherwise.
-        __devexit       The same for __exit.
 Tips on when/where to use the above attributes:
        o The module_init()/module_exit() functions (and all
          initialization functions called _only_ from these)
@@ -196,20 +190,6 @@ Tips on when/where to use the above attributes:
        o Do not mark the struct pci_driver.
-        o The ID table array should be marked __devinitconst; this is done
-          automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
-        o The probe() and remove() functions should be marked __devinit
-          and __devexit respectively.  All initialization functions
-          exclusively called by the probe() routine, can be marked __devinit.
-          Ditto for remove() and __devexit.
-        o If mydriver_remove() is marked with __devexit(), then all address
-          references to mydriver_remove must use __devexit_p(mydriver_remove)
-          (in the struct pci_driver declaration for example).
-          __devexit_p() will generate the function name _or_ NULL if the
-          function will be discarded.  For an example, see drivers/net/tg3.c.
        o Do NOT mark a function if you are not sure which mark to use.
          Better to not mark the function than mark the function wrong.
diff --git a/Documentation/acpi/enumeration.txt b/Documentation/acpi/enumeration.txt
index 4f27785ca0c8..54469bc81b1c 100644
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -185,7 +185,7 @@ input driver:
                        .acpi_match_table  ACPI_PTR(mpu3050_acpi_match),
                },
                .probe          = mpu3050_probe,
-                .remove         = __devexit_p(mpu3050_remove),
+                .remove         = mpu3050_remove,
                .id_table       = mpu3050_ids,
        };
diff --git a/Documentation/acpi/initrd_table_override.txt b/Documentation/acpi/initrd_table_override.txt
new file mode 100644
index 000000000000..35c3f5415476
--- /dev/null
+++ b/Documentation/acpi/initrd_table_override.txt
@@ -0,0 +1,94 @@
+Overriding ACPI tables via initrd
+=================================
+1) Introduction (What is this about)
+2) What is this for
+3) How does it work
+4) References (Where to retrieve userspace tools)
+1) What is this about
+---------------------
+If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to
+override nearly any ACPI table provided by the BIOS with an instrumented,
+modified one.
+For a full list of ACPI tables that can be overridden, take a look at
+the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c
+All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
+be overridable, except:
+   - ACPI_SIG_RSDP (has a signature of 6 bytes)
+   - ACPI_SIG_FACS (does not have an ordinary ACPI table header)
+Both could get implemented as well.
+2) What is this for
+-------------------
+Please keep in mind that this is a debug option.
+ACPI tables should not get overridden for productive use.
+If BIOS ACPI tables are overridden the kernel will get tainted with the
+TAINT_OVERRIDDEN_ACPI_TABLE flag.
+Complain to your platform/BIOS vendor if you find a bug which is so sever
+that a workaround is not accepted in the Linux kernel.
+Still, it can and should be enabled in any kernel, because:
+  - There is no functional change with not instrumented initrds
+  - It provides a powerful feature to easily debug and test ACPI BIOS table
+    compatibility with the Linux kernel.
+3) How does it work
+-------------------
+# Extract the machine's ACPI tables:
+cd /tmp
+acpidump >acpidump
+acpixtract -a acpidump
+# Disassemble, modify and recompile them:
+iasl -d *.dat
+# For example add this statement into a _PRT (PCI Routing Table) function
+# of the DSDT:
+Store("HELLO WORLD", debug)
+iasl -sa dsdt.dsl
+# Add the raw ACPI tables to an uncompressed cpio archive.
+# They must be put into a /kernel/firmware/acpi directory inside the
+# cpio archive.
+# The uncompressed cpio archive must be the first.
+# Other, typically compressed cpio archives, must be
+# concatenated on top of the uncompressed one.
+mkdir -p kernel/firmware/acpi
+cp dsdt.aml kernel/firmware/acpi
+# A maximum of: #define ACPI_OVERRIDE_TABLES 10
+# tables are  currently allowed (see osl.c):
+iasl -sa facp.dsl
+iasl -sa ssdt1.dsl
+cp facp.aml kernel/firmware/acpi
+cp ssdt1.aml kernel/firmware/acpi
+# Create the uncompressed cpio archive and concatenate the original initrd
+# on top:
+find kernel | cpio -H newc --create > /boot/instrumented_initrd
+cat /boot/initrd >>/boot/instrumented_initrd
+# reboot with increased acpi debug level, e.g. boot params:
+acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF
+# and check your syslog:
+[    1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
+[    1.272091] [ACPI Debug]  String [0x0B] "HELLO WORLD"
+iasl is able to disassemble and recompile quite a lot different,
+also static ACPI tables.
+4) Where to retrieve userspace tools
+------------------------------------
+iasl and acpixtract are part of Intel's ACPICA project:
+http://acpica.org/
+and should be packaged by distributions (for example in the acpica package
+on SUSE).
+acpidump can be found in Len Browns pmtools:
+ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump
+This tool is also part of the acpica package on SUSE.
+Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels:
+/sys/firmware/acpi/tables
diff --git a/Documentation/aoe/aoe.txt b/Documentation/aoe/aoe.txt
index bfc9cb19abcd..c71487d399d1 100644
--- a/Documentation/aoe/aoe.txt
+++ b/Documentation/aoe/aoe.txt
@@ -125,7 +125,9 @@ DRIVER OPTIONS
  The aoe_deadsecs module parameter determines the maximum number of
  seconds that the driver will wait for an AoE device to provide a
  response to an AoE command.  After aoe_deadsecs seconds have
-  elapsed, the AoE device will be marked as "down".
+  elapsed, the AoE device will be marked as "down".  A value of zero
+  is supported for testing purposes and makes the aoe driver keep
+  trying AoE commands forever.
  The aoe_maxout module parameter has a default of 128.  This is the
  maximum number of unresponded packets that will be sent to an AoE
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index a564ceea9e98..4484e021290e 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -285,7 +285,10 @@ FB0 +-- GFX  ---- LCD ---- LCD
 Misc notes
 ----------
-OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
+OMAP FB allocates the framebuffer memory using the standard dma allocator. You
+can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
+allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
+the global memory area for CMA.
 Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
 of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
@@ -301,11 +304,6 @@ framebuffer parameters.
 Kernel boot arguments
 ---------------------
-vram=<size>[,<physaddr>]
-        - Amount of total VRAM to preallocate and optionally a physical start
-          memory address. For example, "10M". omapfb allocates memory for
-          framebuffers from VRAM.
 omapfb.mode=<display>:<mode>[,...]
        - Default video mode for specified displays. For example,
          "dvi:800x400MR-24@60".  See drivers/video/modedb.c.
diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt
index f5e4caafab7d..1529394cfe8b 100644
--- a/Documentation/backlight/lp855x-driver.txt
+++ b/Documentation/backlight/lp855x-driver.txt
@@ -35,11 +35,8 @@ For supporting platform specific data, the lp855x platform data can be used.
 * mode : Brightness control mode. PWM or register based.
 * device_control : Value of DEVICE CONTROL register.
 * initial_brightness : Initial value of backlight brightness.
-* pwm_data : Platform specific pwm generation functions.
+* period_ns : Platform specific PWM period value. unit is nano.
             Only valid when brightness is pwm input mode.
-             Functions should be implemented by PWM driver.
-             - pwm_set_intensity() : set duty of PWM
-             - pwm_get_intensity() : get current duty of PWM
 * load_new_rom_data :
        0 : use default configuration data
        1 : update values of eeprom or eprom registers on loading driver
@@ -71,8 +68,5 @@ static struct lp855x_platform_data lp8556_pdata = {
        .mode = PWM_BASED,
        .device_control = PWM_CONFIG(LP8556),
        .initial_brightness = INITIAL_BRT,
-        .pwm_data = {
+        .period_ns = 1000000,
-                     .pwm_set_intensity = platform_pwm_set_intensity,
-                     .pwm_get_intensity = platform_pwm_get_intensity,
-                     },
 };
diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt
index cefd3d8bbd11..12e01d432bfe 100644
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -218,7 +218,7 @@ and name space for cpusets, with a minimum of additional kernel code.
 The cpus and mems files in the root (top_cpuset) cpuset are
 read-only.  The cpus file automatically tracks the value of
 cpu_online_mask using a CPU hotplug notifier, and the mems file
-automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
+automatically tracks the value of node_states[N_MEMORY]--i.e.,
 nodes with memory--using the cpuset_track_online_nodes() hook.
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index a25cb3fafeba..8b8c28b9864c 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -71,6 +71,11 @@ Brief summary of control files.
 memory.oom_control              # set/show oom controls.
 memory.numa_stat                # show the number of memory usage per numa node
+ memory.kmem.limit_in_bytes      # set/show hard limit for kernel memory
+ memory.kmem.usage_in_bytes      # show current kernel memory allocation
+ memory.kmem.failcnt             # show the number of kernel memory usage hits limits
+ memory.kmem.max_usage_in_bytes  # show max kernel memory usage recorded
 memory.kmem.tcp.limit_in_bytes  # set/show hard limit for tcp buf memory
 memory.kmem.tcp.usage_in_bytes  # show current tcp buf memory allocation
 memory.kmem.tcp.failcnt            # show the number of tcp buf memory usage hits limits
@@ -268,20 +273,73 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally
 different than user memory, since it can't be swapped out, which makes it
 possible to DoS the system by consuming too much of this precious resource.
+Kernel memory won't be accounted at all until limit on a group is set. This
+allows for existing setups to continue working without disruption.  The limit
+cannot be set if the cgroup have children, or if there are already tasks in the
+cgroup. Attempting to set the limit under those conditions will return -EBUSY.
+When use_hierarchy == 1 and a group is accounted, its children will
+automatically be accounted regardless of their limit value.
+After a group is first limited, it will be kept being accounted until it
+is removed. The memory limitation itself, can of course be removed by writing
+-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not
+limited.
 Kernel memory limits are not imposed for the root cgroup. Usage for the root
-cgroup may or may not be accounted.
+cgroup may or may not be accounted. The memory used is accumulated into
+memory.kmem.usage_in_bytes, or in a separate counter when it makes sense.
+(currently only for tcp).
+The main "kmem" counter is fed into the main counter, so kmem charges will
+also be visible from the user counter.
 Currently no soft limit is implemented for kernel memory. It is future work
 to trigger slab reclaim when those limits are reached.
 2.7.1 Current Kernel Memory resources accounted
+* stack pages: every process consumes some stack pages. By accounting into
+kernel memory, we prevent new processes from being created when the kernel
+memory usage is too high.
+* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
+of each kmem_cache is created everytime the cache is touched by the first time
+from inside the memcg. The creation is done lazily, so some objects can still be
+skipped while the cache is being created. All objects in a slab page should
+belong to the same memcg. This only fails to hold when a task is migrated to a
+different memcg during the page allocation by the cache.
 * sockets memory pressure: some sockets protocols have memory pressure
 thresholds. The Memory Controller allows them to be controlled individually
 per cgroup, instead of globally.
 * tcp memory pressure: sockets memory pressure for the tcp protocol.
+2.7.3 Common use cases
+Because the "kmem" counter is fed to the main user counter, kernel memory can
+never be limited completely independently of user memory. Say "U" is the user
+limit, and "K" the kernel limit. There are three possible ways limits can be
+set:
+    U != 0, K = unlimited:
+    This is the standard memcg limitation mechanism already present before kmem
+    accounting. Kernel memory is completely ignored.
+    U != 0, K < U:
+    Kernel memory is a subset of the user memory. This setup is useful in
+    deployments where the total amount of memory per-cgroup is overcommited.
+    Overcommiting kernel memory limits is definitely not recommended, since the
+    box can still run out of non-reclaimable memory.
+    In this case, the admin could set up K so that the sum of all groups is
+    never greater than the total memory, and freely set U at the cost of his
+    QoS.
+    U != 0, K >= U:
+    Since kmem charges will also be fed to the user counter and reclaim will be
+    triggered for the cgroup for both kinds of memory. This setup gives the
+    admin a unified view of memory, and it is also useful for people who just
+    want to track kernel memory usage.
 3. User Interface
 0. Configuration
@@ -290,6 +348,7 @@ a. Enable CONFIG_CGROUPS
 b. Enable CONFIG_RESOURCE_COUNTERS
 c. Enable CONFIG_MEMCG
 d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
+d. Enable CONFIG_MEMCG_KMEM (to use kmem extension)
 1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
 # mount -t tmpfs none /sys/fs/cgroup
@@ -406,6 +465,11 @@ About use_hierarchy, see Section 6.
  Because rmdir() moves all pages to parent, some out-of-use page caches can be
  moved to the parent. If you want to avoid that, force_empty will be useful.
+  Also, note that when memory.kmem.limit_in_bytes is set the charges due to
+  kernel pages will still be seen. This is not considered a failure and the
+  write will still return success. In this case, it is expected that
+  memory.kmem.usage_in_bytes == memory.usage_in_bytes.
  About use_hierarchy, see Section 6.
 5.2 stat file
diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt
index 0c4a344e78fa..c4d99ed0b418 100644
--- a/Documentation/cgroups/resource_counter.txt
+++ b/Documentation/cgroups/resource_counter.txt
@@ -83,16 +83,17 @@ to work with it.
        res_counter->lock internally (it must be called with res_counter->lock
        held). The force parameter indicates whether we can bypass the limit.
- e. void res_counter_uncharge[_locked]
+ e. u64 res_counter_uncharge[_locked]
                        (struct res_counter *rc, unsigned long val)
        When a resource is released (freed) it should be de-accounted
        from the resource counter it was accounted to.  This is called
-        "uncharging".
+        "uncharging". The return value of this function indicate the amount
+        of charges still present in the counter.
        The _locked routines imply that the res_counter->lock is taken.
- f. void res_counter_uncharge_until
+ f. u64 res_counter_uncharge_until
                (struct res_counter *rc, struct res_counter *top,
                 unsinged long val)
diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt
index 728c38c242d6..56fb62b09fc5 100644
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -141,3 +141,4 @@ Version History
 1.2.0   Handle creation of arrays that contain failed devices.
 1.3.0   Added support for RAID 10
 1.3.1   Allow device replacement/rebuild for RAID 10
+1.3.2   Fix/improve redundancy checking for RAID10
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt
new file mode 100644
index 000000000000..ecdb57d69dbf
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA Reset Manager
+Required properties:
+- compatible : "altr,rst-mgr"
+- reg : Should contain 1 register ranges(address and length)
+Example:
+         rstmgr@ffd05000 {
+                compatible = "altr,rst-mgr";
+                reg = <0xffd05000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
new file mode 100644
index 000000000000..07c65e3cdcbe
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-system.txt
@@ -0,0 +1,11 @@
+Altera SOCFPGA System Manager
+Required properties:
+- compatible : "altr,sys-mgr"
+- reg : Should contain 1 register ranges(address and length)
+Example:
+         sysmgr@ffd08000 {
+                compatible = "altr,sys-mgr";
+                reg = <0xffd08000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index 70c0dc5f00ed..61df564c0d23 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -6,9 +6,15 @@ Required properties:
 - interrupt-controller: Identifies the node as an interrupt controller.
 - #interrupt-cells: The number of cells to define the interrupts. Should be 1.
  The cell is the IRQ number
 - reg: Should contain PMIC registers location and length. First pair
  for the main interrupt registers, second pair for the per-CPU
-  interrupt registers
+  interrupt registers. For this last pair, to be compliant with SMP
+  support, the "virtual" must be use (For the record, these registers
+  automatically map to the interrupt controller registers of the
+  current CPU)
 Example:
@@ -18,6 +24,6 @@ Example:
              #address-cells = <1>;
              #size-cells = <1>;
              interrupt-controller;
-              reg = <0xd0020000 0x1000>,
+              reg = <0xd0020a00 0x1d0>,
-                    <0xd0021000 0x1000>;
+                    <0xd0021070 0x58>;
        };
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
new file mode 100644
index 000000000000..926b4d6aae7e
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
@@ -0,0 +1,20 @@
+Power Management Service Unit(PMSU)
+-----------------------------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+Required properties:
+- compatible: "marvell,armada-370-xp-pmsu"
+- reg: Should contain PMSU registers location and length. First pair
+  for the per-CPU SW Reset Control registers, second pair for the
+  Power Management Service Unit.
+Example:
+armada-370-xp-pmsu@d0022000 {
+        compatible = "marvell,armada-370-xp-pmsu";
+        reg = <0xd0022100 0x430>,
+              <0xd0020800 0x20>;
+};
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
index 8b6ea2267c94..64830118b013 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
@@ -5,6 +5,7 @@ Required properties:
 - compatible: Should be "marvell,armada-370-xp-timer"
 - interrupts: Should contain the list of Global Timer interrupts
 - reg: Should contain the base address of the Global Timer registers
+- clocks: clock driving the timer hardware
 Optional properties:
 - marvell,timer-25Mhz: Tells whether the Global timer supports the 25
diff --git a/Documentation/devicetree/bindings/arm/coherency-fabric.txt b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
new file mode 100644
index 000000000000..17d8cd107559
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/coherency-fabric.txt
@@ -0,0 +1,21 @@
+Coherency fabric
+----------------
+Available on Marvell SOCs: Armada 370 and Armada XP
+Required properties:
+- compatible: "marvell,coherency-fabric"
+- reg: Should contain coherency fabric registers location and
+  length. First pair for the coherency fabric registers, second pair
+  for the per-CPU fabric registers registers.
+Example:
+coherency-fabric@d0020200 {
+        compatible = "marvell,coherency-fabric";
+        reg = <0xd0020200 0xb0>,
+                <0xd0021810 0x1c>;
+};
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
index 49fc7ada929a..3545ea704b50 100644
--- a/Documentation/devicetree/bindings/arm/davinci/nand.txt
+++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
@@ -23,6 +23,9 @@ Recommended properties :
 - ti,davinci-nand-buswidth: buswidth 8 or 16
 - ti,davinci-nand-use-bbt: use flash based bad block table support.
+nand device bindings may contain additional sub-nodes describing
+partitions of the address space. See partition.txt for more detail.
 Example(da850 EVM ):
 nand_cs3@62000000 {
        compatible = "ti,davinci-nand";
@@ -35,4 +38,9 @@ nand_cs3@62000000 {
        ti,davinci-ecc-mode = "hw";
        ti,davinci-ecc-bits = <4>;
        ti,davinci-nand-use-bbt;
+        partition@180000 {
+                label = "ubifs";
+                reg = <0x180000 0x7e80000>;
+        };
 };
diff --git a/Documentation/devicetree/bindings/arm/l2cc.txt b/Documentation/devicetree/bindings/arm/l2cc.txt
index 7c3ee3aeb7b7..cbef09b5c8a7 100644
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -10,6 +10,12 @@ Required properties:
        "arm,pl310-cache"
        "arm,l220-cache"
        "arm,l210-cache"
+        "marvell,aurora-system-cache": Marvell Controller designed to be
+     compatible with the ARM one, with system cache mode (meaning
+     maintenance operations on L1 are broadcasted to the L2 and L2
+     performs the same operation).
+        "marvell,"aurora-outer-cache: Marvell Controller designed to be
+         compatible with the ARM one with outer cache mode.
 - cache-unified : Specifies the cache is a unified cache.
 - cache-level : Should be set to 2 for a level 2 cache.
 - reg : Physical base address and size of cache controller's memory mapped
@@ -29,6 +35,9 @@ Optional properties:
  filter. Addresses in the filter window are directed to the M1 port. Other
  addresses will go to the M0 port.
 - interrupts : 1 combined interrupt.
+- cache-id-part: cache id part number to be used if it is not present
+  on hardware
+- wt-override: If present then L2 is forced to Write through mode
 Example:
diff --git a/Documentation/devicetree/bindings/arm/spear/shirq.txt b/Documentation/devicetree/bindings/arm/spear/shirq.txt
new file mode 100644
index 000000000000..13fbb8866bd6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/spear/shirq.txt
@@ -0,0 +1,48 @@
+* SPEAr Shared IRQ layer (shirq)
+SPEAr3xx architecture includes shared/multiplexed irqs for certain set
+of devices. The multiplexor provides a single interrupt to parent
+interrupt controller (VIC) on behalf of a group of devices.
+There can be multiple groups available on SPEAr3xx variants but not
+exceeding 4. The number of devices in a group can differ, further they
+may share same set of status/mask registers spanning across different
+bit masks. Also in some cases the group may not have enable or other
+registers. This makes software little complex.
+A single node in the device tree is used to describe the shared
+interrupt multiplexor (one node for all groups). A group in the
+interrupt controller shares config/control registers with other groups.
+For example, a 32-bit interrupt enable/disable config register can
+accommodate upto 4 interrupt groups.
+Required properties:
+  - compatible: should be, either of
+     - "st,spear300-shirq"
+     - "st,spear310-shirq"
+     - "st,spear320-shirq"
+  - interrupt-controller: Identifies the node as an interrupt controller.
+  - #interrupt-cells: should be <1> which basically contains the offset
+    (starting from 0) of interrupts for all the groups.
+  - reg: Base address and size of shirq registers.
+  - interrupts: The list of interrupts generated by the groups which are
+    then connected to a parent interrupt controller. Each group is
+    associated with one of the interrupts, hence number of interrupts (to
+    parent) is equal to number of groups. The format of the interrupt
+    specifier depends in the interrupt parent controller.
+  Optional properties:
+  - interrupt-parent: pHandle of the parent interrupt controller, if not
+    inherited from the parent node.
+Example:
+The following is an example from the SPEAr320 SoC dtsi file.
+shirq: interrupt-controller@0xb3000000 {
+        compatible = "st,spear320-shirq";
+        reg = <0xb3000000 0x1000>;
+        interrupts = <28 29 30 1>;
+        #interrupt-cells = <1>;
+        interrupt-controller;
+};
diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.txt b/Documentation/devicetree/bindings/clock/imx23-clock.txt
index baadbb11fe98..5083c0b834b2 100644
--- a/Documentation/devicetree/bindings/clock/imx23-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx23-clock.txt
@@ -60,11 +60,6 @@ clks: clkctrl@80040000 {
        compatible = "fsl,imx23-clkctrl";
        reg = <0x80040000 0x2000>;
        #clock-cells = <1>;
-        clock-output-names =
-                ...
-                "uart",         /* 32 */
-                ...
-                "end_of_list";
 };
 auart0: serial@8006c000 {
diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.txt b/Documentation/devicetree/bindings/clock/imx25-clock.txt
index c2a3525ecb4e..db4f2f05c4d0 100644
--- a/Documentation/devicetree/bindings/clock/imx25-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx25-clock.txt
@@ -146,10 +146,6 @@ clks: ccm@53f80000 {
        compatible = "fsl,imx25-ccm";
        reg = <0x53f80000 0x4000>;
        interrupts = <31>;
-        clock-output-names = ...
-                        "uart_ipg",
-                        "uart_serial",
-                        ...;
 };
 uart1: serial@43f90000 {
diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.txt b/Documentation/devicetree/bindings/clock/imx28-clock.txt
index 52a49a4a50b3..e6587af62ff0 100644
--- a/Documentation/devicetree/bindings/clock/imx28-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx28-clock.txt
@@ -83,11 +83,6 @@ clks: clkctrl@80040000 {
        compatible = "fsl,imx28-clkctrl";
        reg = <0x80040000 0x2000>;
        #clock-cells = <1>;
-        clock-output-names =
-                ...
-                "uart",         /* 45 */
-                ...
-                "end_of_list";
 };
 auart0: serial@8006a000 {
diff --git a/Documentation/devicetree/bindings/clock/imx6q-clock.txt b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
index d77b4e68dc42..f73fdf595568 100644
--- a/Documentation/devicetree/bindings/clock/imx6q-clock.txt
+++ b/Documentation/devicetree/bindings/clock/imx6q-clock.txt
@@ -211,10 +211,6 @@ clks: ccm@020c4000 {
        reg = <0x020c4000 0x4000>;
        interrupts = <0 87 0x04 0 88 0x04>;
        #clock-cells = <1>;
-        clock-output-names = ...
-                             "uart_ipg",
-                             "uart_serial",
-                             ...;
 };
 uart1: serial@02020000 {
diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
new file mode 100644
index 000000000000..1e662948661e
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -0,0 +1,47 @@
+* Core Clock bindings for Marvell MVEBU SoCs
+Marvell MVEBU SoCs usually allow to determine core clock frequencies by
+reading the Sample-At-Reset (SAR) register. The core clock consumer should
+specify the desired clock by having the clock ID in its "clocks" phandle cell.
+The following is a list of provided IDs and clock names on Armada 370/XP:
+ 0 = tclk    (Internal Bus clock)
+ 1 = cpuclk  (CPU clock)
+ 2 = nbclk   (L2 Cache clock)
+ 3 = hclk    (DRAM control clock)
+ 4 = dramclk (DDR clock)
+The following is a list of provided IDs and clock names on Kirkwood and Dove:
+ 0 = tclk   (Internal Bus clock)
+ 1 = cpuclk (CPU0 clock)
+ 2 = l2clk  (L2 Cache clock derived from CPU0 clock)
+ 3 = ddrclk (DDR controller clock derived from CPU0 clock)
+Required properties:
+- compatible : shall be one of the following:
+        "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
+        "marvell,armada-xp-core-clock" - For Armada XP SoC core clocks
+        "marvell,dove-core-clock" - for Dove SoC core clocks
+        "marvell,kirkwood-core-clock" - for Kirkwood SoC (except mv88f6180)
+        "marvell,mv88f6180-core-clock" - for Kirkwood MV88f6180 SoC
+- reg : shall be the register address of the Sample-At-Reset (SAR) register
+- #clock-cells : from common clock binding; shall be set to 1
+Optional properties:
+- clock-output-names : from common clock binding; allows overwrite default clock
+        output names ("tclk", "cpuclk", "l2clk", "ddrclk")
+Example:
+core_clk: core-clocks@d0214 {
+        compatible = "marvell,dove-core-clock";
+        reg = <0xd0214 0x4>;
+        #clock-cells = <1>;
+};
+spi0: spi@10600 {
+        compatible = "marvell,orion-spi";
+        /* ... */
+        /* get tclk from core clock provider */
+        clocks = <&core_clk 0>;
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
new file mode 100644
index 000000000000..feb830130714
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-cpu-clock.txt
@@ -0,0 +1,21 @@
+Device Tree Clock bindings for cpu clock of Marvell EBU platforms
+Required properties:
+- compatible : shall be one of the following:
+        "marvell,armada-xp-cpu-clock" - cpu clocks for Armada XP
+- reg : Address and length of the clock complex register set
+- #clock-cells : should be set to 1.
+- clocks : shall be the input parent clock phandle for the clock.
+cpuclk: clock-complex@d0018700 {
+        #clock-cells = <1>;
+        compatible = "marvell,armada-xp-cpu-clock";
+        reg = <0xd0018700 0xA0>;
+        clocks = <&coreclk 1>;
+}
+cpu@0 {
+        compatible = "marvell,sheeva-v7";
+        reg = <0>;
+        clocks = <&cpuclk 0>;
+};
diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
new file mode 100644
index 000000000000..7337005ef5e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
@@ -0,0 +1,119 @@
+* Gated Clock bindings for Marvell Orion 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.
+The following is a list of provided IDs for Armada 370:
+ID      Clock   Peripheral
+-----------------------------------
+0       Audio   AC97 Cntrl
+1       pex0_en PCIe 0 Clock out
+2       pex1_en PCIe 1 Clock out
+3       ge1     Gigabit Ethernet 1
+4       ge0     Gigabit Ethernet 0
+5       pex0    PCIe Cntrl 0
+9       pex1    PCIe Cntrl 1
+15      sata0   SATA Host 0
+17      sdio    SDHCI Host
+25      tdm     Time Division Mplx
+28      ddr     DDR Cntrl
+30      sata1   SATA Host 0
+The following is a list of provided IDs for Armada XP:
+ID      Clock   Peripheral
+-----------------------------------
+0       audio   Audio Cntrl
+1       ge3     Gigabit Ethernet 3
+2       ge2     Gigabit Ethernet 2
+3       ge1     Gigabit Ethernet 1
+4       ge0     Gigabit Ethernet 0
+5       pex0    PCIe Cntrl 0
+6       pex1    PCIe Cntrl 1
+7       pex2    PCIe Cntrl 2
+8       pex3    PCIe Cntrl 3
+13      bp
+14      sata0lnk
+15      sata0   SATA Host 0
+16      lcd     LCD Cntrl
+17      sdio    SDHCI Host
+18      usb0    USB Host 0
+19      usb1    USB Host 1
+20      usb2    USB Host 2
+22      xor0    XOR DMA 0
+23      crypto  CESA engine
+25      tdm     Time Division Mplx
+28      xor1    XOR DMA 1
+29      sata1lnk
+30      sata1   SATA Host 0
+The following is a list of provided IDs for Dove:
+ID      Clock   Peripheral
+-----------------------------------
+0       usb0    USB Host 0
+1       usb1    USB Host 1
+2       ge      Gigabit Ethernet
+3       sata    SATA Host
+4       pex0    PCIe Cntrl 0
+5       pex1    PCIe Cntrl 1
+8       sdio0   SDHCI Host 0
+9       sdio1   SDHCI Host 1
+10      nand    NAND Cntrl
+11      camera  Camera Cntrl
+12      i2s0    I2S Cntrl 0
+13      i2s1    I2S Cntrl 1
+15      crypto  CESA engine
+21      ac97    AC97 Cntrl
+22      pdma    Peripheral DMA
+23      xor0    XOR DMA 0
+24      xor1    XOR DMA 1
+30      gephy   Gigabit Ethernel PHY
+Note: gephy(30) is implemented as a parent clock of ge(2)
+The following is a list of provided IDs for Kirkwood:
+ID      Clock   Peripheral
+-----------------------------------
+0       ge0     Gigabit Ethernet 0
+2       pex0    PCIe Cntrl 0
+3       usb0    USB Host 0
+4       sdio    SDIO Cntrl
+5       tsu     Transp. Stream Unit
+6       dunit   SDRAM Cntrl
+7       runit   Runit
+8       xor0    XOR DMA 0
+9       audio   I2S Cntrl 0
+14      sata0   SATA Host 0
+15      sata1   SATA Host 1
+16      xor1    XOR DMA 1
+17      crypto  CESA engine
+18      pex1    PCIe Cntrl 1
+19      ge1     Gigabit Ethernet 0
+20      tdm     Time Division Mplx
+Required properties:
+- compatible : shall be one of the following:
+        "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
+- #clock-cells : from common clock binding; shall be set to 1
+Optional properties:
+- clocks : default parent clock phandle (e.g. tclk)
+Example:
+gate_clk: clock-gating-control@d0038 {
+        compatible = "marvell,dove-gating-clock";
+        reg = <0xd0038 0x4>;
+        /* default parent clock is tclk */
+        clocks = <&core_clk 0>;
+        #clock-cells = <1>;
+};
+sdio0: sdio@92000 {
+        compatible = "marvell,dove-sdhci";
+        /* get clk gate bit 8 (sdio0) */
+        clocks = <&gate_clk 8>;
+};
diff --git a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
index bd7ce120bc13..fc9ce6f1688c 100644
--- a/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
+++ b/Documentation/devicetree/bindings/crypto/fsl-sec4.txt
@@ -54,7 +54,8 @@ PROPERTIES
   - compatible
      Usage: required
      Value type: <string>
-      Definition: Must include "fsl,sec-v4.0"
+      Definition: Must include "fsl,sec-v4.0". Also includes SEC
+           ERA versions (optional) with which the device is compatible.
   - #address-cells
       Usage: required
@@ -106,7 +107,7 @@ PROPERTIES
 EXAMPLE
        crypto@300000 {
-                compatible = "fsl,sec-v4.0";
+                compatible = "fsl,sec-v4.0", "fsl,sec-era-v2.0";
                #address-cells = <1>;
                #size-cells = <1>;
                reg = <0x300000 0x10000>;
diff --git a/Documentation/devicetree/bindings/dma/mv-xor.txt b/Documentation/devicetree/bindings/dma/mv-xor.txt
new file mode 100644
index 000000000000..7c6cb7fcecd2
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mv-xor.txt
@@ -0,0 +1,40 @@
+* Marvell XOR engines
+Required properties:
+- compatible: Should be "marvell,orion-xor"
+- reg: Should contain registers location and length (two sets)
+    the first set is the low registers, the second set the high
+    registers for the XOR engine.
+- clocks: pointer to the reference clock
+The DT node must also contains sub-nodes for each XOR channel that the
+XOR engine has. Those sub-nodes have the following required
+properties:
+- interrupts: interrupt of the XOR channel
+And the following optional properties:
+- dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
+- dmacap,memset to indicate that the XOR channel is capable of memset operations
+- dmacap,xor to indicate that the XOR channel is capable of xor operations
+Example:
+xor@d0060900 {
+        compatible = "marvell,orion-xor";
+        reg = <0xd0060900 0x100
+               0xd0060b00 0x100>;
+        clocks = <&coreclk 0>;
+        status = "okay";
+        xor00 {
+              interrupts = <51>;
+              dmacap,memcpy;
+              dmacap,xor;
+        };
+        xor01 {
+              interrupts = <52>;
+              dmacap,memcpy;
+              dmacap,xor;
+              dmacap,memset;
+        };
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
index 558cdf3c9abc..d4eab9227ea4 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-poweroff.txt
@@ -1,4 +1,19 @@
-GPIO line that should be set high/low to power off a device
+Driver a GPIO line that can be used to turn the power off.
+The driver supports both level triggered and edge triggered power off.
+At driver load time, the driver will request the given gpio line and
+install a pm_power_off handler. If the optional properties 'input' is
+not found, the GPIO line will be driven in the inactive
+state. Otherwise its configured as an input.
+When the pm_power_off is called, the gpio is configured as an output,
+and drive active, so triggering a level triggered power off
+condition. This will also cause an inactive->active edge condition, so
+triggering positive edge triggered power off. After a delay of 100ms,
+the GPIO is set to inactive, thus causing an active->inactive edge,
+triggering negative edge triggered power off. After another 100ms
+delay the GPIO is driver active again. If the power is still on and
+the CPU still running after a 3000ms delay, a WARN_ON(1) is emitted.
 Required properties:
 - compatible : should be "gpio-poweroff".
@@ -13,10 +28,9 @@ Optional properties:
  property is not specified, the GPIO is initialized as an output in its
  inactive state.
 Examples:
 gpio-poweroff {
        compatible = "gpio-poweroff";
-        gpios = <&gpio 4 0>; /* GPIO 4 Active Low */
+        gpios = <&gpio 4 0>;
 };
diff --git a/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
new file mode 100644
index 000000000000..b4fa934ae3a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
@@ -0,0 +1,191 @@
+NVIDIA Tegra host1x
+Required properties:
+- compatible: "nvidia,tegra<chip>-host1x"
+- reg: Physical base address and length of the controller's registers.
+- interrupts: The interrupt outputs from the controller.
+- #address-cells: The number of cells used to represent physical base addresses
+  in the host1x address space. Should be 1.
+- #size-cells: The number of cells used to represent the size of an address
+  range in the host1x address space. Should be 1.
+- ranges: The mapping of the host1x address space to the CPU address space.
+The host1x top-level node defines a number of children, each representing one
+of the following host1x client modules:
+- mpe: video encoder
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-mpe"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+- vi: video input
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-vi"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+- epp: encoder pre-processor
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-epp"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+- isp: image signal processor
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-isp"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+- gr2d: 2D graphics engine
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-gr2d"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+- gr3d: 3D graphics engine
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-gr3d"
+  - reg: Physical base address and length of the controller's registers.
+- dc: display controller
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-dc"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+  Each display controller node has a child node, named "rgb", that represents
+  the RGB output associated with the controller. It can take the following
+  optional properties:
+  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+  - nvidia,edid: supplies a binary EDID blob
+- hdmi: High Definition Multimedia Interface
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-hdmi"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+  - vdd-supply: regulator for supply voltage
+  - pll-supply: regulator for PLL
+  Optional properties:
+  - nvidia,ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+  - nvidia,hpd-gpio: specifies a GPIO used for hotplug detection
+  - nvidia,edid: supplies a binary EDID blob
+- tvo: TV encoder output
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-tvo"
+  - reg: Physical base address and length of the controller's registers.
+  - interrupts: The interrupt outputs from the controller.
+- dsi: display serial interface
+  Required properties:
+  - compatible: "nvidia,tegra<chip>-dsi"
+  - reg: Physical base address and length of the controller's registers.
+Example:
+/ {
+        ...
+        host1x {
+                compatible = "nvidia,tegra20-host1x", "simple-bus";
+                reg = <0x50000000 0x00024000>;
+                interrupts = <0 65 0x04   /* mpcore syncpt */
+                              0 67 0x04>; /* mpcore general */
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges = <0x54000000 0x54000000 0x04000000>;
+                mpe {
+                        compatible = "nvidia,tegra20-mpe";
+                        reg = <0x54040000 0x00040000>;
+                        interrupts = <0 68 0x04>;
+                };
+                vi {
+                        compatible = "nvidia,tegra20-vi";
+                        reg = <0x54080000 0x00040000>;
+                        interrupts = <0 69 0x04>;
+                };
+                epp {
+                        compatible = "nvidia,tegra20-epp";
+                        reg = <0x540c0000 0x00040000>;
+                        interrupts = <0 70 0x04>;
+                };
+                isp {
+                        compatible = "nvidia,tegra20-isp";
+                        reg = <0x54100000 0x00040000>;
+                        interrupts = <0 71 0x04>;
+                };
+                gr2d {
+                        compatible = "nvidia,tegra20-gr2d";
+                        reg = <0x54140000 0x00040000>;
+                        interrupts = <0 72 0x04>;
+                };
+                gr3d {
+                        compatible = "nvidia,tegra20-gr3d";
+                        reg = <0x54180000 0x00040000>;
+                };
+                dc@54200000 {
+                        compatible = "nvidia,tegra20-dc";
+                        reg = <0x54200000 0x00040000>;
+                        interrupts = <0 73 0x04>;
+                        rgb {
+                                status = "disabled";
+                        };
+                };
+                dc@54240000 {
+                        compatible = "nvidia,tegra20-dc";
+                        reg = <0x54240000 0x00040000>;
+                        interrupts = <0 74 0x04>;
+                        rgb {
+                                status = "disabled";
+                        };
+                };
+                hdmi {
+                        compatible = "nvidia,tegra20-hdmi";
+                        reg = <0x54280000 0x00040000>;
+                        interrupts = <0 75 0x04>;
+                        status = "disabled";
+                };
+                tvo {
+                        compatible = "nvidia,tegra20-tvo";
+                        reg = <0x542c0000 0x00040000>;
+                        interrupts = <0 76 0x04>;
+                        status = "disabled";
+                };
+                dsi {
+                        compatible = "nvidia,tegra20-dsi";
+                        reg = <0x54300000 0x00040000>;
+                        status = "disabled";
+                };
+        };
+        ...
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
new file mode 100644
index 000000000000..8ce9cd2855b5
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-cbus-gpio.txt
@@ -0,0 +1,27 @@
+Device tree bindings for i2c-cbus-gpio driver
+Required properties:
+        - compatible = "i2c-cbus-gpio";
+        - gpios: clk, dat, sel
+        - #address-cells = <1>;
+        - #size-cells = <0>;
+Optional properties:
+        - child nodes conforming to i2c bus binding
+Example:
+i2c@0 {
+        compatible = "i2c-cbus-gpio";
+        gpios = <&gpio 66 0 /* clk */
+                 &gpio 65 0 /* dat */
+                 &gpio 64 0 /* sel */
+                >;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        retu-mfd: retu@1 {
+                compatible = "retu-mfd";
+                reg = <0x1>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
new file mode 100644
index 000000000000..66709a825541
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt
@@ -0,0 +1,81 @@
+GPIO-based I2C Bus Mux
+This binding describes an I2C bus multiplexer that uses GPIOs to
+route the I2C signals.
+                                  +-----+  +-----+
+                                  | dev |  | dev |
+    +------------+                +-----+  +-----+
+    | SoC        |                   |        |
+    |            |          /--------+--------+
+    |   +------+ |  +------+    child bus A, on GPIO value set to 0
+    |   | I2C  |-|--| Mux  |
+    |   +------+ |  +--+---+    child bus B, on GPIO value set to 1
+    |            |     |    \----------+--------+--------+
+    |   +------+ |     |               |        |        |
+    |   | GPIO |-|-----+            +-----+  +-----+  +-----+
+    |   +------+ |                  | dev |  | dev |  | dev |
+    +------------+                  +-----+  +-----+  +-----+
+Required properties:
+- compatible: i2c-mux-gpio
+- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
+  port is connected to.
+- mux-gpios: list of gpios used to control the muxer
+* Standard I2C mux properties. See mux.txt in this directory.
+* I2C child bus nodes. See mux.txt in this directory.
+Optional properties:
+- idle-state: value to set the muxer to when idle. When no value is
+  given, it defaults to the last value used.
+For each i2c child node, an I2C child bus will be created. They will
+be numbered based on their order in the device tree.
+Whenever an access is made to a device on a child bus, the value set
+in the revelant node's reg property will be output using the list of
+GPIOs, the first in the list holding the least-significant value.
+If an idle state is defined, using the idle-state (optional) property,
+whenever an access is not being made to a device on a child bus, the
+GPIOs will be set according to the idle value.
+If an idle state is not defined, the most recently used value will be
+left programmed into hardware whenever no access is being made to a
+device on a child bus.
+Example:
+        i2cmux {
+                compatible = "i2c-mux-gpio";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                mux-gpios = <&gpio1 22 0 &gpio1 23 0>;
+                i2c-parent = <&i2c1>;
+                i2c@1 {
+                        reg = <1>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        ssd1307: oled@3c {
+                                compatible = "solomon,ssd1307fb-i2c";
+                                reg = <0x3c>;
+                                pwms = <&pwm 4 3000>;
+                                reset-gpios = <&gpio2 7 1>;
+                                reset-active-low;
+                        };
+                };
+                i2c@3 {
+                        reg = <3>;
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        pca9555: pca9555@20 {
+                                compatible = "nxp,pca9555";
+                                gpio-controller;
+                                #gpio-cells = <2>;
+                                reg = <0x20>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
index c15781f4dc8c..1637c298a1b3 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-ocores.txt
@@ -1,7 +1,7 @@
 Device tree configuration for i2c-ocores
 Required properties:
- compatible      : "opencores,i2c-ocores"
+- compatible      : "opencores,i2c-ocores" or "aeroflexgaisler,i2cmst"
 - reg             : bus address start and address range size of device
 - interrupts      : interrupt number
 - clock-frequency : frequency of bus clock in Hz
diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
index b6cb5a12c672..e9611ace8792 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt
@@ -13,11 +13,17 @@ Required properties:
  - interrupts: interrupt number to the cpu.
  - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges.
+Required for all cases except "samsung,s3c2440-hdmiphy-i2c":
+  - Samsung GPIO variant (deprecated):
+    - gpios: The order of the gpios should be the following: <SDA, SCL>.
+      The gpio specifier depends on the gpio controller. Required in all
+      cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
+      lines are permanently wired to the respective clienta
+  - Pinctrl variant (preferred, if available):
+    - pinctrl-0: Pin control group to be used for this controller.
+    - pinctrl-names: Should contain only one value - "default".
 Optional properties:
-  - gpios: The order of the gpios should be the following: <SDA, SCL>.
-    The gpio specifier depends on the gpio controller. Required in all
-    cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output
-    lines are permanently wired to the respective client
  - samsung,i2c-slave-addr: Slave address in multi-master enviroment. If not
    specified, default value is 0.
  - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not
@@ -31,8 +37,14 @@ Example:
                interrupts = <345>;
                samsung,i2c-sda-delay = <100>;
                samsung,i2c-max-bus-freq = <100000>;
+                /* Samsung GPIO variant begins here */
                gpios = <&gpd1 2 0 /* SDA */
                         &gpd1 3 0 /* SCL */>;
+                /* Samsung GPIO variant ends here */
+                /* Pinctrl variant begins here */
+                pinctrl-0 = <&i2c3_bus>;
+                pinctrl-names = "default";
+                /* Pinctrl variant ends here */
                #address-cells = <1>;
                #size-cells = <0>;
diff --git a/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
new file mode 100644
index 000000000000..ead641c65e0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
@@ -0,0 +1,46 @@
+* GPIO driven matrix keypad device tree bindings
+GPIO driven matrix keypad is used to interface a SoC with a matrix keypad.
+The matrix keypad supports multiple row and column lines, a key can be
+placed at each intersection of a unique row and a unique column. The matrix
+keypad can sense a key-press and key-release by means of GPIO lines and
+report the event using GPIO interrupts to the cpu.
+Required Properties:
+- compatible:           Should be "gpio-matrix-keypad"
+- row-gpios:            List of gpios used as row lines. The gpio specifier
+                        for this property depends on the gpio controller to
+                        which these row lines are connected.
+- col-gpios:            List of gpios used as column lines. The gpio specifier
+                        for this property depends on the gpio controller to
+                        which these column lines are connected.
+- linux,keymap:         The definition can be found at
+                        bindings/input/matrix-keymap.txt
+Optional Properties:
+- linux,no-autorepeat:  do no enable autorepeat feature.
+- linux,wakeup:         use any event on keypad as wakeup event.
+- debounce-delay-ms:    debounce interval in milliseconds
+- col-scan-delay-us:    delay, measured in microseconds, that is needed
+                        before we can scan keypad after activating column gpio
+Example:
+        matrix-keypad {
+                compatible = "gpio-matrix-keypad";
+                debounce-delay-ms = <5>;
+                col-scan-delay-us = <2>;
+                row-gpios = <&gpio2 25 0
+                             &gpio2 26 0
+                             &gpio2 27 0>;
+                col-gpios = <&gpio2 21 0
+                             &gpio2 22 0>;
+                linux,keymap = <0x0000008B
+                                0x0100009E
+                                0x02000069
+                                0x0001006A
+                                0x0101001C
+                                0x0201006C>;
+        };
diff --git a/Documentation/devicetree/bindings/input/pwm-beeper.txt b/Documentation/devicetree/bindings/input/pwm-beeper.txt
new file mode 100644
index 000000000000..be332ae4f2d6
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/pwm-beeper.txt
@@ -0,0 +1,7 @@
+* PWM beeper device tree bindings
+Registers a PWM device as beeper.
+Required properties:
+- compatible: should be "pwm-beeper"
+- pwms: phandle to the physical PWM device
diff --git a/Documentation/devicetree/bindings/input/stmpe-keypad.txt b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
new file mode 100644
index 000000000000..1b97222e8a0b
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/stmpe-keypad.txt
@@ -0,0 +1,39 @@
+* STMPE Keypad
+Required properties:
+ - compatible               : "st,stmpe-keypad"
+ - linux,keymap             : See ./matrix-keymap.txt
+Optional properties:
+ - debounce-interval        : Debouncing interval time in milliseconds
+ - st,scan-count            : Scanning cycles elapsed before key data is updated
+ - st,no-autorepeat         : If specified device will not autorepeat
+Example:
+        stmpe_keypad {
+                compatible = "st,stmpe-keypad";
+                debounce-interval = <64>;
+                st,scan-count = <8>;
+                st,no-autorepeat;
+                linux,keymap = <0x205006b
+                                0x4010074
+                                0x3050072
+                                0x1030004
+                                0x502006a
+                                0x500000a
+                                0x5008b
+                                0x706001c
+                                0x405000b
+                                0x6070003
+                                0x3040067
+                                0x303006c
+                                0x60400e7
+                                0x602009e
+                                0x4020073
+                                0x5050002
+                                0x4030069
+                                0x3020008>;
+        };
diff --git a/Documentation/devicetree/bindings/input/tca8418_keypad.txt b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
new file mode 100644
index 000000000000..2a1538f0053f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/tca8418_keypad.txt
@@ -0,0 +1,8 @@
+Required properties:
+- compatible: "ti,tca8418"
+- reg: the I2C address
+- interrupts: IRQ line number, should trigger on falling edge
+- keypad,num-rows: The number of rows
+- keypad,num-columns: The number of columns
+- linux,keymap: Keys definitions, see keypad-matrix.
diff --git a/Documentation/devicetree/bindings/input/touchscreen/mms114.txt b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
new file mode 100644
index 000000000000..89d4c56c5671
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/mms114.txt
@@ -0,0 +1,34 @@
+* MELFAS MMS114 touchscreen controller
+Required properties:
+- compatible: must be "melfas,mms114"
+- reg: I2C address of the chip
+- interrupts: interrupt to which the chip is connected
+- x-size: horizontal resolution of touchscreen
+- y-size: vertical resolution of touchscreen
+Optional properties:
+- contact-threshold:
+- moving-threshold:
+- x-invert: invert X axis
+- y-invert: invert Y axis
+Example:
+        i2c@00000000 {
+                /* ... */
+                touchscreen@48 {
+                        compatible = "melfas,mms114";
+                        reg = <0x48>;
+                        interrupts = <39 0>;
+                        x-size = <720>;
+                        y-size = <1280>;
+                        contact-threshold = <10>;
+                        moving-threshold = <10>;
+                        x-invert;
+                        y-invert;
+                };
+                /* ... */
+        };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
new file mode 100644
index 000000000000..127baa31a77a
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
@@ -0,0 +1,43 @@
+STMPE Touchscreen
+----------------
+Required properties:
+ - compatible: "st,stmpe-ts"
+Optional properties:
+- st,sample-time: ADC converstion time in number of clock.  (0 -> 36 clocks, 1 ->
+  44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96 clocks, 6
+  -> 144 clocks), recommended is 4.
+- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
+- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
+  reference)
+- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 -> 6.5 MHz)
+- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 -> 4
+  samples, 3 -> 8 samples)
+- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us, 2 ->
+  100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms) recommended
+  is 3
+- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 -> 500 us, 3
+  -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is 2
+- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) = Count of
+  the fractional part) recommended is 7
+- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA typical 35
+  mA max, 1 -> 50 mA typical 80 mA max)
+Node name must be stmpe_touchscreen and should be child node of stmpe node to
+which it belongs.
+Example:
+        stmpe_touchscreen {
+                compatible = "st,stmpe-ts";
+                st,sample-time = <4>;
+                st,mod-12b = <1>;
+                st,ref-sel = <0>;
+                st,adc-freq = <1>;
+                st,ave-ctrl = <1>;
+                st,touch-det-delay = <2>;
+                st,settling = <2>;
+                st,fraction-z = <7>;
+                st,i-drive = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt
index ce83c8d3c00e..13b707b7355c 100644
--- a/Documentation/devicetree/bindings/mfd/ab8500.txt
+++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
@@ -24,7 +24,32 @@ ab8500-bm                :                      :              : Battery Manager
 ab8500-btemp             :                      :              : Battery Temperature
 ab8500-charger           :                      :              : Battery Charger
 ab8500-codec             :                      :              : Audio Codec
-ab8500-fg                :                      :              : Fuel Gauge
+ab8500-fg                :                      : vddadc       : Fuel Gauge
+                         : NCONV_ACCU           :              : Accumulate N Sample Conversion
+                         : BATT_OVV             :              : Battery Over Voltage
+                         : LOW_BAT_F            :              : LOW threshold battery voltage
+                         : CC_INT_CALIB         :              : Coulomb Counter Internal Calibration
+                         : CCEOC                :              : Coulomb Counter End of Conversion
+ab8500-btemp             :                      : vtvout       : Battery Temperature
+                         : BAT_CTRL_INDB        :              : Battery Removal Indicator
+                         : BTEMP_LOW            :              : Btemp < BtempLow, if battery temperature is lower than -10°C
+                         : BTEMP_LOW_MEDIUM     :              : BtempLow < Btemp < BtempMedium,if battery temperature is between -10 and 0°C
+                         : BTEMP_MEDIUM_HIGH    :              : BtempMedium < Btemp < BtempHigh,if battery temperature is between 0°C and“MaxTemp
+                         : BTEMP_HIGH           :              : Btemp > BtempHigh, if battery temperature is higher than “MaxTemp
+ab8500-charger           :                      : vddadc       : Charger interface
+                         : MAIN_CH_UNPLUG_DET   :              : main charger unplug detection management (not in 8505)
+                         : MAIN_CHARGE_PLUG_DET :              : main charger plug detection management (not in 8505)
+                         : MAIN_EXT_CH_NOT_OK   :              : main charger not OK
+                         : MAIN_CH_TH_PROT_R    :              : Die temp is above main charger
+                         : MAIN_CH_TH_PROT_F    :              : Die temp is below main charger
+                         : VBUS_DET_F           :              : VBUS falling detected
+                         : VBUS_DET_R           :              : VBUS rising detected
+                         : USB_LINK_STATUS      :              : USB link status has changed
+                         : USB_CH_TH_PROT_R     :              : Die temp is above usb charger
+                         : USB_CH_TH_PROT_F     :              : Die temp is below usb charger
+                         : USB_CHARGER_NOT_OKR  :              : allowed USB charger not ok detection
+                         : VBUS_OVV             :              : Overvoltage on Vbus ball detected (USB charge is stopped)
+                         : CH_WD_EXP            :              : Charger watchdog detected
 ab8500-gpadc             : HW_CONV_END          : vddadc       : Analogue to Digital Converter
                           SW_CONV_END          :              :
 ab8500-gpio              :                      :              : GPIO Controller
diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt b/Documentation/devicetree/bindings/mfd/stmpe.txt
new file mode 100644
index 000000000000..56edb5520685
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
@@ -0,0 +1,28 @@
+* ST Microelectronics STMPE Multi-Functional Device
+STMPE is an MFD device which may expose the following inbuilt devices: gpio,
+keypad, touchscreen, adc, pwm, rotator.
+Required properties:
+ - compatible                   : "st,stmpe[610|801|811|1601|2401|2403]"
+ - reg                          : I2C/SPI address of the device
+Optional properties:
+ - interrupts                   : The interrupt outputs from the controller
+ - interrupt-controller         : Marks the device node as an interrupt controller
+ - interrupt-parent             : Specifies which IRQ controller we're connected to
+ - wakeup-source                : Marks the input device as wakable
+ - st,autosleep-timeout         : Valid entries (ms); 4, 16, 32, 64, 128, 256, 512 and 1024
+Example:
+        stmpe1601: stmpe1601@40 {
+                compatible = "st,stmpe1601";
+                reg = <0x40>;
+                interrupts = <26 0x4>;
+                interrupt-parent = <&gpio6>;
+                interrupt-controller;
+                wakeup-source;
+                st,autosleep-timeout = <1024>;
+        };
diff --git a/Documentation/devicetree/bindings/mtd/denali-nand.txt b/Documentation/devicetree/bindings/mtd/denali-nand.txt
new file mode 100644
index 000000000000..b04d03a1d499
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/denali-nand.txt
@@ -0,0 +1,23 @@
+* Denali NAND controller
+Required properties:
+  - compatible : should be "denali,denali-nand-dt"
+  - reg : should contain registers location and length for data and reg.
+  - reg-names: Should contain the reg names "nand_data" and "denali_reg"
+  - interrupts : The interrupt number.
+  - dm-mask : DMA bit mask
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+Examples:
+nand: nand@ff900000 {
+        #address-cells = <1>;
+        #size-cells = <1>;
+        compatible = "denali,denali-nand-dt";
+        reg = <0xff900000 0x100000>, <0xffb80000 0x10000>;
+        reg-names = "nand_data", "denali_reg";
+        interrupts = <0 144 4>;
+        dma-mask = <0xffffffff>;
+};
diff --git a/Documentation/devicetree/bindings/mtd/flctl-nand.txt b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
new file mode 100644
index 000000000000..427f46dc60ad
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/flctl-nand.txt
@@ -0,0 +1,49 @@
+FLCTL NAND controller
+Required properties:
+- compatible : "renesas,shmobile-flctl-sh7372"
+- reg : Address range of the FLCTL
+- interrupts : flste IRQ number
+- nand-bus-width : bus width to NAND chip
+Optional properties:
+- dmas: DMA specifier(s)
+- dma-names: name for each DMA specifier. Valid names are
+             "data_tx", "data_rx", "ecc_tx", "ecc_rx"
+The DMA fields are not used yet in the driver but are listed here for
+completing the bindings.
+The device tree may optionally contain sub-nodes describing partitions of the
+address space. See partition.txt for more detail.
+Example:
+        flctl@e6a30000 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                compatible = "renesas,shmobile-flctl-sh7372";
+                reg = <0xe6a30000 0x100>;
+                interrupts = <0x0d80>;
+                nand-bus-width = <16>;
+                dmas = <&dmac 1 /* data_tx */
+                        &dmac 2;> /* data_rx */
+                dma-names = "data_tx", "data_rx";
+                system@0 {
+                        label = "system";
+                        reg = <0x0 0x8000000>;
+                };
+                userdata@8000000 {
+                        label = "userdata";
+                        reg = <0x8000000 0x10000000>;
+                };
+                cache@18000000 {
+                        label = "cache";
+                        reg = <0x18000000 0x8000000>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
index e2c663b354d2..e3ea32e7de3e 100644
--- a/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsmc-nand.txt
@@ -3,9 +3,7 @@
 Required properties:
 - compatible : "st,spear600-fsmc-nand"
 - reg : Address range of the mtd chip
- reg-names: Should contain the reg names "fsmc_regs" and "nand_data"
+- reg-names: Should contain the reg names "fsmc_regs", "nand_data", "nand_addr" and "nand_cmd"
- st,ale-off : Chip specific offset to ALE
- st,cle-off : Chip specific offset to CLE
 Optional properties:
 - bank-width : Width (in bytes) of the device.  If not present, the width
@@ -19,10 +17,10 @@ Example:
                #address-cells = <1>;
                #size-cells = <1>;
                reg = <0xd1800000 0x1000        /* FSMC Register */
-                       0xd2000000 0x4000>;      /* NAND Base */
+                       0xd2000000 0x0010        /* NAND Base DATA */
-                reg-names = "fsmc_regs", "nand_data";
+                       0xd2020000 0x0010        /* NAND Base ADDR */
-                st,ale-off = <0x20000>;
+                       0xd2010000 0x0010>;      /* NAND Base CMD */
-                st,cle-off = <0x10000>;
+                reg-names = "fsmc_regs", "nand_data", "nand_addr", "nand_cmd";
                bank-width = <1>;
                nand-skip-bbtscan;
diff --git a/Documentation/devicetree/bindings/mtd/m25p80.txt b/Documentation/devicetree/bindings/mtd/m25p80.txt
new file mode 100644
index 000000000000..6d3d57609470
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/m25p80.txt
@@ -0,0 +1,29 @@
+* MTD SPI driver for ST M25Pxx (and similar) serial flash chips
+Required properties:
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+  representing partitions.
+- compatible : Should be the manufacturer and the name of the chip. Bear in mind
+               the DT binding is not Linux-only, but in case of Linux, see the
+               "m25p_ids" table in drivers/mtd/devices/m25p80.c for the list of
+               supported chips.
+- reg : Chip-Select number
+- spi-max-frequency : Maximum frequency of the SPI bus the chip can operate at
+Optional properties:
+- m25p,fast-read : Use the "fast read" opcode to read data from the chip instead
+                   of the usual "read" opcode. This opcode is not supported by
+                   all chips and support for it can not be detected at runtime.
+                   Refer to your chips' datasheet to check if this is supported
+                   by your chip.
+Example:
+        flash: m25p80@0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                compatible = "spansion,m25p80";
+                reg = <0>;
+                spi-max-frequency = <40000000>;
+                m25p,fast-read;
+        };
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index 94de19b8f16b..dab7847fc800 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
@@ -23,6 +23,9 @@ file systems on embedded devices.
   unaligned accesses as implemented in the JFFS2 code via memcpy().
   By defining "no-unaligned-direct-access", the flash will not be
   exposed directly to the MTD users (e.g. JFFS2) any more.
+ - linux,mtd-name: allow to specify the mtd name for retro capability with
+   physmap-flash drivers as boot loader pass the mtd partition via the old
+   device name physmap-flash.
 For JEDEC compatible devices, the following additional properties
 are defined:
diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
new file mode 100644
index 000000000000..859a6fa7569c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -0,0 +1,23 @@
+* Marvell Armada 370 / Armada XP Ethernet Controller (NETA)
+Required properties:
+- compatible: should be "marvell,armada-370-neta".
+- reg: address and length of the register set for the device.
+- interrupts: interrupt for the device
+- phy: A phandle to a phy node defining the PHY address (as the reg
+  property, a single integer).
+- phy-mode: The interface between the SoC and the PHY (a string that
+  of_get_phy_mode() can understand)
+- clocks: a pointer to the reference clock for this device.
+Example:
+ethernet@d0070000 {
+        compatible = "marvell,armada-370-neta";
+        reg = <0xd0070000 0x2500>;
+        interrupts = <8>;
+        clocks = <&gate_clk 4>;
+        status = "okay";
+        phy = <&phy0>;
+        phy-mode = "rgmii-id";
+};
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
new file mode 100644
index 000000000000..34e7aafa321c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/marvell-orion-mdio.txt
@@ -0,0 +1,35 @@
+* Marvell MDIO Ethernet Controller interface
+The Ethernet controllers of the Marvel Kirkwood, Dove, Orion5x,
+MV78xx0, Armada 370 and Armada XP have an identical unit that provides
+an interface with the MDIO bus. This driver handles this MDIO
+interface.
+Required properties:
+- compatible: "marvell,orion-mdio"
+- reg: address and length of the SMI register
+The child nodes of the MDIO driver are the individual PHY devices
+connected to this MDIO bus. They must have a "reg" property given the
+PHY address on the MDIO bus.
+Example at the SoC level:
+mdio {
+        #address-cells = <1>;
+        #size-cells = <0>;
+        compatible = "marvell,orion-mdio";
+        reg = <0xd0072004 0x4>;
+};
+And at the board level:
+mdio {
+        phy0: ethernet-phy@0 {
+                reg = <0>;
+        };
+        phy1: ethernet-phy@1 {
+                reg = <1>;
+        };
+}
diff --git a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
index 3a268127b054..bc50899e0c81 100644
--- a/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/atmel,at91-pinctrl.txt
@@ -81,7 +81,8 @@ PA31	TXD4
 Required properties for pin configuration node:
 - atmel,pins: 4 integers array, represents a group of pins mux and config
  setting. The format is atmel,pins = <PIN_BANK PIN_BANK_NUM PERIPH CONFIG>.
-  The PERIPH 0 means gpio.
+  The PERIPH 0 means gpio, PERIPH 1 is periph A, PERIPH 2 is periph B...
+  PIN_BANK 0 is pioA, PIN_BANK 1 is pioB...
 Bits used for CONFIG:
 PULL_UP         (1 << 0): indicate this pin need a pull up.
@@ -126,7 +127,7 @@ pinctrl@fffff400 {
                pinctrl_dbgu: dbgu-0 {
                        atmel,pins =
                                <1 14 0x1 0x0   /* PB14 periph A */
-                                 1 15 0x1 0x1>; /* PB15 periph with pullup */
+                                 1 15 0x1 0x1>; /* PB15 periph A with pullup */
                };
        };
 };
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt
new file mode 100644
index 000000000000..c596a6ad3285
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-sirf.txt
@@ -0,0 +1,47 @@
+CSR SiRFprimaII pinmux controller
+Required properties:
+- compatible    : "sirf,prima2-pinctrl"
+- reg           : Address range of the pinctrl registers
+- interrupts    : Interrupts used by every GPIO group
+- gpio-controller : Indicates this device is a GPIO controller
+- interrupt-controller  : Marks the device node as an interrupt controller
+Optional properties:
+- sirf,pullups : if n-th bit of m-th bank is set, set a pullup on GPIO-n of bank m
+- sirf,pulldowns : if n-th bit of m-th bank is set, set a pulldown on GPIO-n of bank m
+Please refer to pinctrl-bindings.txt in this directory for details of the common
+pinctrl bindings used by client devices.
+SiRFprimaII's pinmux nodes act as a container for an abitrary number of subnodes.
+Each of these subnodes represents some desired configuration for a group of pins.
+Required subnode-properties:
+- sirf,pins : An array of strings. Each string contains the name of a group.
+- sirf,function: A string containing the name of the function to mux to the
+  group.
+  Valid values for group and function names can be found from looking at the
+  group and function arrays in driver files:
+  drivers/pinctrl/pinctrl-sirf.c
+For example, pinctrl might have subnodes like the following:
+ uart2_pins_a: uart2@0 {
+         uart {
+                 sirf,pins = "uart2grp";
+                 sirf,function = "uart2";
+         };
+ };
+ uart2_noflow_pins_a: uart2@1 {
+         uart {
+                 sirf,pins = "uart2_nostreamctrlgrp";
+                 sirf,function = "uart2_nostreamctrl";
+         };
+ };
+For a specific board, if it wants to use uart2 without hardware flow control,
+it can add the following to its board-specific .dts file.
+uart2: uart@0xb0070000 {
+        pinctrl-names = "default";
+        pinctrl-0 = <&uart2_noflow_pins_a>;
+}
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
new file mode 100644
index 000000000000..0ba1bcc7f33a
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/btemp.txt
@@ -0,0 +1,16 @@
+=== AB8500 Battery Temperature Monitor Driver ===
+The properties below describes the node for btemp driver.
+Required Properties:
+- compatible = Shall be: "stericsson,ab8500-btemp"
+- battery = Shall be battery specific information
+        Example:
+        ab8500_btemp {
+                compatible = "stericsson,ab8500-btemp";
+                battery    = <&ab8500_battery>;
+        };
+For information on battery specific node, Ref:
+Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt b/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt
new file mode 100644
index 000000000000..ef5328371122
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/chargalg.txt
@@ -0,0 +1,16 @@
+=== AB8500 Charging Algorithm Driver ===
+The properties below describes the node for chargalg driver.
+Required Properties:
+- compatible = Shall be: "stericsson,ab8500-chargalg"
+- battery = Shall be battery specific information
+Example:
+ab8500_chargalg {
+        compatible = "stericsson,ab8500-chargalg";
+        battery    = <&ab8500_battery>;
+};
+For information on battery specific node, Ref:
+Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt b/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt
new file mode 100644
index 000000000000..6bdbb08ea9e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/charger.txt
@@ -0,0 +1,25 @@
+=== AB8500 Charger Driver ===
+Required Properties:
+- compatible = Shall be "stericsson,ab8500-charger"
+- battery = Shall be battery specific information
+        Example:
+        ab8500_charger {
+                compatible = "stericsson,ab8500-charger";
+                battery    = <&ab8500_battery>;
+        };
+- vddadc-supply: Supply for USB and Main charger
+        Example:
+        ab8500-charger {
+                vddadc-supply   = <&ab8500_ldo_tvout_reg>;
+        }
+- autopower_cfg:
+        Boolean value depicting the presence of 'automatic poweron after powerloss'
+        Example:
+        ab8500-charger {
+                autopower_cfg;
+        };
+For information on battery specific node, Ref:
+Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
new file mode 100644
index 000000000000..ccafcb9112fb
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
@@ -0,0 +1,58 @@
+=== AB8500 Fuel Gauge Driver ===
+AB8500 is a mixed signal multimedia and power management
+device comprising: power and energy-management-module,
+wall-charger, usb-charger, audio codec, general purpose adc,
+tvout, clock management and sim card interface.
+Fuelgauge support is part of energy-management-modules, other
+components of this module are:
+main-charger, usb-combo-charger and battery-temperature-monitoring.
+The properties below describes the node for fuelgauge driver.
+Required Properties:
+- compatible = This shall be: "stericsson,ab8500-fg"
+- battery = Shall be battery specific information
+        Example:
+        ab8500_fg {
+                compatible = "stericsson,ab8500-fg";
+                battery    = <&ab8500_battery>;
+        };
+dependent node:
+        ab8500_battery: ab8500_battery {
+        };
+        This node will provide information on 'thermistor interface' and
+        'battery technology type' used.
+Properties of this node are:
+thermistor-on-batctrl:
+        A boolean value indicating thermistor interface to battery
+        Note:
+        'btemp' and 'batctrl' are the pins interfaced for battery temperature
+        measurement, 'btemp' signal is used when NTC(negative temperature
+        coefficient) resister is interfaced external to battery whereas
+        'batctrl' pin is used when NTC resister is internal to battery.
+        Example:
+        ab8500_battery: ab8500_battery {
+                thermistor-on-batctrl;
+        };
+        indicates: NTC resister is internal to battery, 'batctrl' is used
+                for thermal measurement.
+        The absence of property 'thermal-on-batctrl' indicates
+        NTC resister is external to battery and  'btemp' signal is used
+        for thermal measurement.
+battery-type:
+        This shall be the battery manufacturing technology type,
+        allowed types are:
+                "UNKNOWN" "NiMH" "LION" "LIPO" "LiFe" "NiCd" "LiMn"
+        Example:
+        ab8500_battery: ab8500_battery {
+                stericsson,battery-type = "LIPO";
+        }
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
new file mode 100644
index 000000000000..4ad29b9ac2ac
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/raideng.txt
@@ -0,0 +1,81 @@
+* Freescale 85xx RAID Engine nodes
+RAID Engine nodes are defined to describe on-chip RAID accelerators.  Each RAID
+Engine should have a separate node.
+Supported chips:
+P5020, P5040
+Required properties:
+- compatible:   Should contain "fsl,raideng-v1.0" as the value
+                This identifies RAID Engine block. 1 in 1.0 represents
+                major number whereas 0 represents minor number. The
+                version matches the hardware IP version.
+- reg:          offset and length of the register set for the device
+- ranges:       standard ranges property specifying the translation
+                between child address space and parent address space
+Example:
+        /* P5020 */
+        raideng: raideng@320000 {
+                compatible = "fsl,raideng-v1.0";
+                #address-cells = <1>;
+                #size-cells = <1>;
+                reg     = <0x320000 0x10000>;
+                ranges  = <0 0x320000 0x10000>;
+        };
+There must be a sub-node for each job queue present in RAID Engine
+This node must be a sub-node of the main RAID Engine node
+- compatible:   Should contain "fsl,raideng-v1.0-job-queue" as the value
+                This identifies the job queue interface
+- reg:          offset and length of the register set for job queue
+- ranges:       standard ranges property specifying the translation
+                between child address space and parent address space
+Example:
+        /* P5020 */
+        raideng_jq0@1000 {
+                compatible = "fsl,raideng-v1.0-job-queue";
+                reg        = <0x1000 0x1000>;
+                ranges     = <0x0 0x1000 0x1000>;
+        };
+There must be a sub-node for each job ring present in RAID Engine
+This node must be a sub-node of job queue node
+- compatible:   Must contain "fsl,raideng-v1.0-job-ring" as the value
+                This identifies job ring. Should contain either
+                "fsl,raideng-v1.0-hp-ring" or "fsl,raideng-v1.0-lp-ring"
+                depending upon whether ring has high or low priority
+- reg:          offset and length of the register set for job ring
+- interrupts:   interrupt mapping for job ring IRQ
+Optional property:
+- fsl,liodn:    Specifies the LIODN to be used for Job Ring. This
+                property is normally set by firmware. Value
+                is of 12-bits which is the LIODN number for this JR.
+                This property is used by the IOMMU (PAMU) to distinquish
+                transactions from this JR and than be able to do address
+                translation & protection accordingly.
+Example:
+        /* P5020 */
+        raideng_jq0@1000 {
+                compatible = "fsl,raideng-v1.0-job-queue";
+                reg        = <0x1000 0x1000>;
+                ranges     = <0x0 0x1000 0x1000>;
+                raideng_jr0: jr@0 {
+                        compatible = "fsl,raideng-v1.0-job-ring", "fsl,raideng-v1.0-hp-ring";
+                        reg        = <0x0 0x400>;
+                        interrupts = <139 2 0 0>;
+                        interrupt-parent = <&mpic>;
+                        fsl,liodn = <0x41>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
new file mode 100644
index 000000000000..131e8c11d26f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.txt
@@ -0,0 +1,23 @@
+TI SOC ECAP based APWM controller
+Required properties:
+- compatible: Must be "ti,am33xx-ecap"
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period in nanoseconds and bit 0 in the third cell is used to
+  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
+  to 1 for inverse polarity & set to 0 for normal polarity.
+- reg: physical base address and size of the registers map.
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the ECAP:
+  "ecap<x>", <x> being the 0-based instance number from the HW spec
+Example:
+ecap0: ecap@0 {
+        compatible = "ti,am33xx-ecap";
+        #pwm-cells = <3>;
+        reg = <0x48300100 0x80>;
+        ti,hwmods = "ecap0";
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
new file mode 100644
index 000000000000..4fc7079d822e
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.txt
@@ -0,0 +1,23 @@
+TI SOC EHRPWM based PWM controller
+Required properties:
+- compatible : Must be "ti,am33xx-ehrpwm"
+- #pwm-cells: Should be 3. Number of cells being used to specify PWM property.
+  First cell specifies the per-chip index of the PWM to use, the second
+  cell is the period in nanoseconds and bit 0 in the third cell is used to
+  encode the polarity of PWM output. Set bit 0 of the third in PWM specifier
+  to 1 for inverse polarity & set to 0 for normal polarity.
+- reg: physical base address and size of the registers map.
+Optional properties:
+- ti,hwmods: Name of the hwmod associated to the EHRPWM:
+  "ehrpwm<x>", <x> being the 0-based instance number from the HW spec
+Example:
+ehrpwm0: ehrpwm@0 {
+        compatible = "ti,am33xx-ehrpwm";
+        #pwm-cells = <3>;
+        reg = <0x48300200 0x100>;
+        ti,hwmods = "ehrpwm0";
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
new file mode 100644
index 000000000000..f7eae77f8354
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-tipwmss.txt
@@ -0,0 +1,31 @@
+TI SOC based PWM Subsystem
+Required properties:
+- compatible: Must be "ti,am33xx-pwmss";
+- reg: physical base address and size of the registers map.
+- address-cells: Specify the number of u32 entries needed in child nodes.
+                  Should set to 1.
+- size-cells: specify number of u32 entries needed to specify child nodes size
+                in reg property. Should set to 1.
+- ranges: describes the address mapping of a memory-mapped bus. Should set to
+           physical address map of child's base address, physical address within
+           parent's address  space and length of the address map. For am33xx,
+           3 set of child register maps present, ECAP register space, EQEP
+           register space, EHRPWM register space.
+Also child nodes should also populated under PWMSS DT node.
+Example:
+pwmss0: pwmss@48300000 {
+        compatible = "ti,am33xx-pwmss";
+        reg = <0x48300000 0x10>;
+        ti,hwmods = "epwmss0";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        status = "disabled";
+        ranges = <0x48300100 0x48300100 0x80   /* ECAP */
+                  0x48300180 0x48300180 0x80   /* EQEP */
+                  0x48300200 0x48300200 0x80>; /* EHRPWM */
+        /* child nodes go here */
+};
diff --git a/Documentation/devicetree/bindings/pwm/pwm.txt b/Documentation/devicetree/bindings/pwm/pwm.txt
index 73ec962bfe8c..06e67247859a 100644
--- a/Documentation/devicetree/bindings/pwm/pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/pwm.txt
@@ -37,10 +37,21 @@ device:
                pwm-names = "backlight";
        };
+Note that in the example above, specifying the "pwm-names" is redundant
+because the name "backlight" would be used as fallback anyway.
 pwm-specifier typically encodes the chip-relative PWM number and the PWM
-period in nanoseconds. Note that in the example above, specifying the
+period in nanoseconds.
-"pwm-names" is redundant because the name "backlight" would be used as
-fallback anyway.
+Optionally, the pwm-specifier can encode a number of flags in a third cell:
+- bit 0: PWM signal polarity (0: normal polarity, 1: inverse polarity)
+Example with optional PWM specifier for inverse polarity
+        bl: backlight {
+                pwms = <&pwm 0 5000000 1>;
+                pwm-names = "backlight";
+        };
 2) PWM controller nodes
 -----------------------
diff --git a/Documentation/devicetree/bindings/pwm/spear-pwm.txt b/Documentation/devicetree/bindings/pwm/spear-pwm.txt
new file mode 100644
index 000000000000..3ac779d83386
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/spear-pwm.txt
@@ -0,0 +1,18 @@
+== ST SPEAr SoC PWM controller ==
+Required properties:
+- compatible: should be one of:
+  - "st,spear320-pwm"
+  - "st,spear1340-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: number of cells used to specify PWM which is fixed to 2 on
+  SPEAr. The first cell specifies the per-chip index of the PWM to use and
+  the second cell is the period in nanoseconds.
+Example:
+        pwm: pwm@a8000000 {
+            compatible ="st,spear320-pwm";
+            reg = <0xa8000000 0x1000>;
+            #pwm-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
new file mode 100644
index 000000000000..2943ee5fce00
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwm.txt
@@ -0,0 +1,17 @@
+Texas Instruments TWL series PWM drivers
+Supported PWMs:
+On TWL4030 series: PWM1 and PWM2
+On TWL6030 series: PWM0 and PWM1
+Required properties:
+- compatible: "ti,twl4030-pwm" or "ti,twl6030-pwm"
+- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+  of the PWM to use and the second cell is the period in nanoseconds.
+Example:
+twl_pwm: pwm {
+        compatible = "ti,twl6030-pwm";
+        #pwm-cells = <2>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
new file mode 100644
index 000000000000..cb64f3acc10f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/ti,twl-pwmled.txt
@@ -0,0 +1,17 @@
+Texas Instruments TWL series PWM drivers connected to LED terminals
+Supported PWMs:
+On TWL4030 series: PWMA and PWMB (connected to LEDA and LEDB terminals)
+On TWL6030 series: LED PWM (mainly used as charging indicator LED)
+Required properties:
+- compatible: "ti,twl4030-pwmled" or "ti,twl6030-pwmled"
+- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+  of the PWM to use and the second cell is the period in nanoseconds.
+Example:
+twl_pwmled: pwmled {
+        compatible = "ti,twl6030-pwmled";
+        #pwm-cells = <2>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
new file mode 100644
index 000000000000..bcc63678a9a5
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/vt8500-pwm.txt
@@ -0,0 +1,17 @@
+VIA/Wondermedia VT8500/WM8xxx series SoC PWM controller
+Required properties:
+- compatible: should be "via,vt8500-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+  of the PWM to use and the second cell is the period in nanoseconds.
+- clocks: phandle to the PWM source clock
+Example:
+pwm1: pwm@d8220000 {
+        #pwm-cells = <2>;
+        compatible = "via,vt8500-pwm";
+        reg = <0xd8220000 0x1000>;
+        clocks = <&clkpwm>;
+};
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
new file mode 100644
index 000000000000..63c659800c03
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -0,0 +1,37 @@
+GPIO controlled regulators
+Required properties:
+- compatible            : Must be "regulator-gpio".
+- states                : Selection of available voltages and GPIO configs.
+                          if there are no states, then use a fixed regulator
+Optional properties:
+- enable-gpio           : GPIO to use to enable/disable the regulator.
+- gpios                 : GPIO group used to control voltage.
+- startup-delay-us      : Startup time in microseconds.
+- enable-active-high    : Polarity of GPIO is active high (default is low).
+Any property defined as part of the core regulator binding defined in
+regulator.txt can also be used.
+Example:
+        mmciv: gpio-regulator {
+                compatible = "regulator-gpio";
+                regulator-name = "mmci-gpio-supply";
+                regulator-min-microvolt = <1800000>;
+                regulator-max-microvolt = <2600000>;
+                regulator-boot-on;
+                enable-gpio = <&gpio0 23 0x4>;
+                gpios = <&gpio0 24 0x4
+                         &gpio0 25 0x4>;
+                states = <1800000 0x3
+                          2200000 0x2
+                          2600000 0x1
+                          2900000 0x0>;
+                startup-delay-us = <100000>;
+                enable-active-high;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/max8925-regulator.txt b/Documentation/devicetree/bindings/regulator/max8925-regulator.txt
new file mode 100644
index 000000000000..0057695aae8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8925-regulator.txt
@@ -0,0 +1,40 @@
+Max8925 Voltage regulators
+Required nodes:
+-nodes:
+  - SDV1 for SDV SDV1
+  - SDV2 for SDV SDV2
+  - SDV3 for SDV SDV3
+  - LDO1 for LDO LDO1
+  - LDO2 for LDO LDO2
+  - LDO3 for LDO LDO3
+  - LDO4 for LDO LDO4
+  - LDO5 for LDO LDO5
+  - LDO6 for LDO LDO6
+  - LDO7 for LDO LDO7
+  - LDO8 for LDO LDO8
+  - LDO9 for LDO LDO9
+  - LDO10 for LDO LDO10
+  - LDO11 for LDO LDO11
+  - LDO12 for LDO LDO12
+  - LDO13 for LDO LDO13
+  - LDO14 for LDO LDO14
+  - LDO15 for LDO LDO15
+  - LDO16 for LDO LDO16
+  - LDO17 for LDO LDO17
+  - LDO18 for LDO LDO18
+  - LDO19 for LDO LDO19
+  - LDO20 for LDO LDO20
+Optional properties:
+- Any optional property defined in bindings/regulator/regulator.txt
+Example:
+        SDV1 {
+                regulator-min-microvolt = <637500>;
+                regulator-max-microvolt = <1425000>;
+                regulator-boot-on;
+                regulator-always-on;
+        };
diff --git a/Documentation/devicetree/bindings/regulator/max8997-regulator.txt b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
new file mode 100644
index 000000000000..9fd69a18b0ba
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/max8997-regulator.txt
@@ -0,0 +1,146 @@
+* Maxim MAX8997 Voltage and Current Regulator
+The Maxim MAX8997 is a multi-function device which includes volatage and
+current regulators, rtc, charger controller and other sub-blocks. It is
+interfaced to the host controller using a i2c interface. Each sub-block is
+addressed by the host system using different i2c slave address. This document
+describes the bindings for 'pmic' sub-block of max8997.
+Required properties:
+- compatible: Should be "maxim,max8997-pmic".
+- reg: Specifies the i2c slave address of the pmic block. It should be 0x66.
+- max8997,pmic-buck1-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+  units for buck1 when changing voltage using gpio dvs. Refer to [1] below
+  for additional information.
+- max8997,pmic-buck2-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+  units for buck2 when changing voltage using gpio dvs. Refer to [1] below
+  for additional information.
+- max8997,pmic-buck5-dvs-voltage: A set of 8 voltage values in micro-volt (uV)
+  units for buck5 when changing voltage using gpio dvs. Refer to [1] below
+  for additional information.
+[1] If none of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
+    property is specified, the 'max8997,pmic-buck[1/2/5]-dvs-voltage'
+    property should specify atleast one voltage level (which would be a
+    safe operating voltage).
+    If either of the 'max8997,pmic-buck[1/2/5]-uses-gpio-dvs' optional
+    property is specified, then all the eigth voltage values for the
+    'max8997,pmic-buck[1/2/5]-dvs-voltage' should be specified.
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the interrupts from max8997 are delivered to.
+- interrupts: Interrupt specifiers for two interrupt sources.
+  - First interrupt specifier is for 'irq1' interrupt.
+  - Second interrupt specifier is for 'alert' interrupt.
+- max8997,pmic-buck1-uses-gpio-dvs: 'buck1' can be controlled by gpio dvs.
+- max8997,pmic-buck2-uses-gpio-dvs: 'buck2' can be controlled by gpio dvs.
+- max8997,pmic-buck5-uses-gpio-dvs: 'buck5' can be controlled by gpio dvs.
+Additional properties required if either of the optional properties are used:
+- max8997,pmic-ignore-gpiodvs-side-effect: When GPIO-DVS mode is used for
+  multiple bucks, changing the voltage value of one of the bucks may affect
+  that of another buck, which is the side effect of the change (set_voltage).
+  Use this property to ignore such side effects and change the voltage.
+- max8997,pmic-buck125-default-dvs-idx: Default voltage setting selected from
+  the possible 8 options selectable by the dvs gpios. The value of this
+  property should be between 0 and 7. If not specified or if out of range, the
+  default value of this property is set to 0.
+- max8997,pmic-buck125-dvs-gpios: GPIO specifiers for three host gpio's used
+  for dvs. The format of the gpio specifier depends in the gpio controller.
+Regulators: The regulators of max8997 that have to be instantiated should be
+included in a sub-node named 'regulators'. Regulator nodes included in this
+sub-node should be of the format as listed below.
+        regulator_name {
+                standard regulator bindings here
+        };
+The following are the names of the regulators that the max8997 pmic block
+supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
+as per the datasheet of max8997.
+        - LDOn
+                  - valid values for n are 1 to 18 and 21
+                  - Example: LDO0, LD01, LDO2, LDO21
+        - BUCKn
+                  - valid values for n are 1 to 7.
+                  - Example: BUCK1, BUCK2, BUCK3, BUCK7
+        - ENVICHG: Battery Charging Current Monitor Output. This is a fixed
+                   voltage type regulator
+        - ESAFEOUT1: (ldo19)
+        - ESAFEOUT2: (ld020)
+        - CHARGER_CV: main battery charger voltage control
+        - CHARGER: main battery charger current control
+        - CHARGER_TOPOFF: end of charge current threshold level
+The bindings inside the regulator nodes use the standard regulator bindings
+which are documented elsewhere.
+Example:
+        max8997_pmic@66 {
+                compatible = "maxim,max8997-pmic";
+                interrupt-parent = <&wakeup_eint>;
+                reg = <0x66>;
+                interrupts = <4 0>, <3 0>;
+                max8997,pmic-buck1-uses-gpio-dvs;
+                max8997,pmic-buck2-uses-gpio-dvs;
+                max8997,pmic-buck5-uses-gpio-dvs;
+                max8997,pmic-ignore-gpiodvs-side-effect;
+                max8997,pmic-buck125-default-dvs-idx = <0>;
+                max8997,pmic-buck125-dvs-gpios = <&gpx0 0 1 0 0>, /* SET1 */
+                                                 <&gpx0 1 1 0 0>, /* SET2 */
+                                                 <&gpx0 2 1 0 0>; /* SET3 */
+                max8997,pmic-buck1-dvs-voltage = <1350000>, <1300000>,
+                                                 <1250000>, <1200000>,
+                                                 <1150000>, <1100000>,
+                                                 <1000000>, <950000>;
+                max8997,pmic-buck2-dvs-voltage = <1100000>, <1100000>,
+                                                 <1100000>, <1100000>,
+                                                 <1000000>, <1000000>,
+                                                 <1000000>, <1000000>;
+                max8997,pmic-buck5-dvs-voltage = <1200000>, <1200000>,
+                                                 <1200000>, <1200000>,
+                                                 <1200000>, <1200000>,
+                                                 <1200000>, <1200000>;
+                regulators {
+                        ldo1_reg: LDO1 {
+                                regulator-name = "VDD_ABB_3.3V";
+                                regulator-min-microvolt = <3300000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+                        ldo2_reg: LDO2 {
+                                regulator-name = "VDD_ALIVE_1.1V";
+                                regulator-min-microvolt = <1100000>;
+                                regulator-max-microvolt = <1100000>;
+                                regulator-always-on;
+                        };
+                        buck1_reg: BUCK1 {
+                                regulator-name = "VDD_ARM_1.2V";
+                                regulator-min-microvolt = <950000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/regulator/tps65217.txt b/Documentation/devicetree/bindings/regulator/tps65217.txt
index d316fb895daf..4f05d208c95c 100644
--- a/Documentation/devicetree/bindings/regulator/tps65217.txt
+++ b/Documentation/devicetree/bindings/regulator/tps65217.txt
@@ -11,6 +11,9 @@ Required properties:
  using the standard binding for regulators found at
  Documentation/devicetree/bindings/regulator/regulator.txt.
+Optional properties:
+- ti,pmic-shutdown-controller: Telling the PMIC to shutdown on PWR_EN toggle.
  The valid names for regulators are:
  tps65217: dcdc1, dcdc2, dcdc3, ldo1, ldo2, ldo3 and ldo4
@@ -20,6 +23,7 @@ Example:
        tps: tps@24 {
                compatible = "ti,tps65217";
+                ti,pmic-shutdown-controller;
                regulators {
                        dcdc1_reg: dcdc1 {
diff --git a/Documentation/devicetree/bindings/regulator/vexpress.txt b/Documentation/devicetree/bindings/regulator/vexpress.txt
new file mode 100644
index 000000000000..d775f72487aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/regulator/vexpress.txt
@@ -0,0 +1,32 @@
+Versatile Express voltage regulators
+------------------------------------
+Requires node properties:
+- "compatible" value: "arm,vexpress-volt"
+- "arm,vexpress-sysreg,func" when controlled via vexpress-sysreg
+  (see Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
+  for more details)
+Required regulator properties:
+- "regulator-name"
+- "regulator-always-on"
+Optional regulator properties:
+- "regulator-min-microvolt"
+- "regulator-max-microvolt"
+See Documentation/devicetree/bindings/regulator/regulator.txt
+for more details about the regulator properties.
+When no "regulator-[min|max]-microvolt" properties are defined,
+the device is treated as fixed (or rather "read-only") regulator.
+Example:
+        volt@0 {
+                compatible = "arm,vexpress-volt";
+                arm,vexpress-sysreg,func = <2 0>;
+                regulator-name = "Cores";
+                regulator-min-microvolt = <800000>;
+                regulator-max-microvolt = <1050000>;
+                regulator-always-on;
+        };
diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
new file mode 100644
index 000000000000..c9d80d7da141
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.txt
@@ -0,0 +1,17 @@
+* i.MX25 Real Time Clock controller
+This binding supports the following chips: i.MX25, i.MX53
+Required properties:
+- compatible: should be: "fsl,imx25-rtc"
+- reg: physical base address of the controller and length of memory mapped
+  region.
+- interrupts: rtc alarm interrupt
+Example:
+rtc@80056000 {
+        compatible = "fsl,imx53-rtc", "fsl,imx25-rtc";
+        reg = <0x80056000 2000>;
+        interrupts = <29>;
+};
diff --git a/Documentation/devicetree/bindings/rtc/rtc-omap.txt b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
new file mode 100644
index 000000000000..b47aa415c820
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/rtc-omap.txt
@@ -0,0 +1,17 @@
+TI Real Time Clock
+Required properties:
+- compatible: "ti,da830-rtc"
+- reg: Address range of rtc register set
+- interrupts: rtc timer, alarm interrupts in order
+- interrupt-parent: phandle for the interrupt controller
+Example:
+rtc@1c23000 {
+        compatible = "ti,da830-rtc";
+        reg = <0x23000 0x1000>;
+        interrupts = <19
+                      19>;
+        interrupt-parent = <&intc>;
+};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
new file mode 100644
index 000000000000..7b53da5cb75b
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-sflash.txt
@@ -0,0 +1,26 @@
+NVIDIA Tegra20 SFLASH controller.
+Required properties:
+- compatible : should be "nvidia,tegra20-sflash".
+- reg: Should contain SFLASH registers location and length.
+- interrupts: Should contain SFLASH interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for this SFLASH controller.
+Recommended properties:
+- spi-max-frequency: Definition as per
+                     Documentation/devicetree/bindings/spi/spi-bus.txt
+Example:
+spi@7000c380 {
+        compatible = "nvidia,tegra20-sflash";
+        reg = <0x7000c380 0x80>;
+        interrupts = <0 39 0x04>;
+        nvidia,dma-request-selector = <&apbdma 16>;
+        spi-max-frequency = <25000000>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
new file mode 100644
index 000000000000..eefe15e3d95e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/nvidia,tegra20-slink.txt
@@ -0,0 +1,26 @@
+NVIDIA Tegra20/Tegra30 SLINK controller.
+Required properties:
+- compatible : should be "nvidia,tegra20-slink", "nvidia,tegra30-slink".
+- reg: Should contain SLINK registers location and length.
+- interrupts: Should contain SLINK interrupts.
+- nvidia,dma-request-selector : The Tegra DMA controller's phandle and
+  request selector for this SLINK controller.
+Recommended properties:
+- spi-max-frequency: Definition as per
+                     Documentation/devicetree/bindings/spi/spi-bus.txt
+Example:
+spi@7000d600 {
+        compatible = "nvidia,tegra20-slink";
+        reg = <0x7000d600 0x200>;
+        interrupts = <0 82 0x04>;
+        nvidia,dma-request-selector = <&apbdma 16>;
+        spi-max-frequency = <25000000>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        status = "disabled";
+};
diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt
index 81df374adbb9..938809c6829b 100644
--- a/Documentation/devicetree/bindings/spi/omap-spi.txt
+++ b/Documentation/devicetree/bindings/spi/omap-spi.txt
@@ -6,7 +6,9 @@ Required properties:
  - "ti,omap4-spi" 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
+                          input. The default is D0 as input and
+                          D1 as output.
 Example:
diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt b/Documentation/devicetree/bindings/spi/spi-bus.txt
index d2c33d0f533e..296015e3c632 100644
--- a/Documentation/devicetree/bindings/spi/spi-bus.txt
+++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -12,6 +12,7 @@ The SPI master node requires the following properties:
 - #size-cells     - should be zero.
 - compatible      - name of SPI bus controller following generic names
                recommended practice.
+- cs-gpios        - (optional) gpios chip select.
 No other properties are required in the SPI bus node.  It is assumed
 that a driver for an SPI bus device will understand that it is an SPI bus.
 However, the binding does not attempt to define the specific method for
@@ -24,6 +25,22 @@ support describing the chip select layout.
 Optional property:
 - num-cs : total number of chipselects
+If cs-gpios is used the number of chip select will automatically increased
+with max(cs-gpios > hw cs)
+So if for example the controller has 2 CS lines, and the cs-gpios
+property looks like this:
+cs-gpios = <&gpio1 0 0> <0> <&gpio1 1 0> <&gpio1 2 0>;
+Then it should be configured so that num_chipselect = 4 with the
+following mapping:
+cs0 : &gpio1 0 0
+cs1 : native
+cs2 : &gpio1 1 0
+cs3 : &gpio1 2 0
 SPI slave nodes must be children of the SPI master node and can
 contain the following properties.
 - reg             - (required) chip select address of device.
@@ -36,6 +53,11 @@ contain the following properties.
                shifted clock phase (CPHA) mode
 - spi-cs-high     - (optional) Empty property indicating device requires
                chip select active high
+- spi-3wire       - (optional) Empty property indicating device requires
+                    3-wire mode.
+If a gpio chipselect is used for the SPI slave the gpio number will be passed
+via the cs_gpio
 SPI example for an MPC5200 SPI bus:
        spi@f00 {
diff --git a/Documentation/devicetree/bindings/spi/spi_atmel.txt b/Documentation/devicetree/bindings/spi/spi_atmel.txt
new file mode 100644
index 000000000000..07e04cdc0c9e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi_atmel.txt
@@ -0,0 +1,26 @@
+Atmel SPI device
+Required properties:
+- compatible : should be "atmel,at91rm9200-spi".
+- reg: Address and length of the register set for the device
+- interrupts: Should contain spi interrupt
+- cs-gpios: chipselects
+Example:
+spi1: spi@fffcc000 {
+        compatible = "atmel,at91rm9200-spi";
+        reg = <0xfffcc000 0x4000>;
+        interrupts = <13 4 5>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        cs-gpios = <&pioB 3 0>;
+        status = "okay";
+        mmc-slot@0 {
+                compatible = "mmc-spi-slot";
+                reg = <0>;
+                gpios = <&pioC 4 0>;    /* CD */
+                spi-max-frequency = <25000000>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/exynos_dp.txt b/Documentation/devicetree/bindings/video/exynos_dp.txt
new file mode 100644
index 000000000000..c60da67a5d76
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/exynos_dp.txt
@@ -0,0 +1,80 @@
+The Exynos display port interface should be configured based on
+the type of panel connected to it.
+We use two nodes:
+        -dp-controller node
+        -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:
+                Base address of DP PHY register.
+        -samsung,enable-mask:
+                The bit-mask used to enable/disable DP PHY.
+For the Panel initialization, we read data from dp-controller node.
+Required properties for dp-controller:
+        -compatible:
+                should be "samsung,exynos5-dp".
+        -reg:
+                physical base address of the controller and length
+                of memory mapped region.
+        -interrupts:
+                interrupt combiner values.
+        -interrupt-parent:
+                phandle to Interrupt combiner node.
+        -samsung,color-space:
+                input video data format.
+                        COLOR_RGB = 0, COLOR_YCBCR422 = 1, COLOR_YCBCR444 = 2
+        -samsung,dynamic-range:
+                dynamic range for input video data.
+                        VESA = 0, CEA = 1
+        -samsung,ycbcr-coeff:
+                YCbCr co-efficients for input video.
+                        COLOR_YCBCR601 = 0, COLOR_YCBCR709 = 1
+        -samsung,color-depth:
+                number of bits per colour component.
+                        COLOR_6 = 0, COLOR_8 = 1, COLOR_10 = 2, COLOR_12 = 3
+        -samsung,link-rate:
+                link rate supported by the panel.
+                        LINK_RATE_1_62GBPS = 0x6, LINK_RATE_2_70GBPS = 0x0A
+        -samsung,lane-count:
+                number of lanes supported by the panel.
+                        LANE_COUNT1 = 1, LANE_COUNT2 = 2, LANE_COUNT4 = 4
+Optional properties for dp-controller:
+        -interlaced:
+                interlace scan mode.
+                        Progressive if defined, Interlaced if not defined
+        -vsync-active-high:
+                VSYNC polarity configuration.
+                        High if defined, Low if not defined
+        -hsync-active-high:
+                HSYNC polarity configuration.
+                        High if defined, Low if not defined
+Example:
+SOC specific portion:
+        dp-controller {
+                compatible = "samsung,exynos5-dp";
+                reg = <0x145b0000 0x10000>;
+                interrupts = <10 3>;
+                interrupt-parent = <&combiner>;
+                dptx-phy {
+                        reg = <0x10040720>;
+                        samsung,enable-mask = <1>;
+                };
+        };
+Board Specific portion:
+        dp-controller {
+                samsung,color-space = <0>;
+                samsung,dynamic-range = <0>;
+                samsung,ycbcr-coeff = <0>;
+                samsung,color-depth = <1>;
+                samsung,link-rate = <0x0a>;
+                samsung,lane-count = <4>;
+        };
diff --git a/Documentation/devicetree/bindings/video/ssd1307fb.txt b/Documentation/devicetree/bindings/video/ssd1307fb.txt
new file mode 100644
index 000000000000..3d0060cff062
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ssd1307fb.txt
@@ -0,0 +1,24 @@
+* Solomon SSD1307 Framebuffer Driver
+Required properties:
+  - compatible: Should be "solomon,ssd1307fb-<bus>". The only supported bus for
+    now is i2c.
+  - reg: Should contain address of the controller on the I2C bus. Most likely
+         0x3c or 0x3d
+  - pwm: Should contain the pwm to use according to the OF device tree PWM
+         specification [0]
+  - reset-gpios: Should contain the GPIO used to reset the OLED display
+Optional properties:
+  - reset-active-low: Is the reset gpio is active on physical low?
+[0]: Documentation/devicetree/bindings/pwm/pwm.txt
+Examples:
+ssd1307: oled@3c {
+        compatible = "solomon,ssd1307fb-i2c";
+        reg = <0x3c>;
+        pwms = <&pwm 4 3000>;
+        reset-gpios = <&gpio2 7>;
+        reset-active-low;
+};
diff --git a/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
new file mode 100644
index 000000000000..75558ccd9a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/davinci-wdt.txt
@@ -0,0 +1,12 @@
+DaVinci Watchdog Timer (WDT) Controller
+Required properties:
+- compatible : Should be "ti,davinci-wdt"
+- reg : Should contain WDT registers location and length
+Examples:
+wdt: wdt@2320000 {
+        compatible = "ti,davinci-wdt";
+        reg = <0x02320000 0x80>;
+};
diff --git a/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
new file mode 100644
index 000000000000..80a37193c0b8
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/twl4030-wdt.txt
@@ -0,0 +1,10 @@
+Device tree bindings for twl4030-wdt driver (TWL4030 watchdog)
+Required properties:
+        compatible = "ti,twl4030-wdt";
+Example:
+watchdog {
+        compatible = "ti,twl4030-wdt";
+};
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index 8c624a18f67d..8042050eb265 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -38,6 +38,8 @@ dnotify_test.c
        - example program for dnotify
 ecryptfs.txt
        - docs on eCryptfs: stacked cryptographic filesystem for Linux.
+efivarfs.txt
+        - info for the efivarfs filesystem.
 exofs.txt
        - info, usage, mount options, design about EXOFS.
 ext2.txt
@@ -48,6 +50,8 @@ ext4.txt
        - info, mount options and specifications for the Ext4 filesystem.
 files.txt
        - info on file management in the Linux kernel.
+f2fs.txt
+        - info and mount options for the F2FS filesystem.
 fuse.txt
        - info on the Filesystem in User SpacE including mount options.
 gfs2.txt
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index e540a24e5d06..f48e0c6b4c42 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -80,7 +80,6 @@ rename:		yes (all)	(see below)
 readlink:       no
 follow_link:    no
 put_link:       no
-truncate:       yes             (see below)
 setattr:        yes
 permission:     no (may not block if called in rcu-walk mode)
 get_acl:        no
@@ -96,11 +95,6 @@ atomic_open:	yes
        Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
        cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
-        ->truncate() is never called directly - it's a callback, not a
-method. It's called by vmtruncate() - deprecated library function used by
->setattr(). Locking information above applies to that call (i.e. is
-inherited from ->setattr() - vmtruncate() is used when ATTR_SIZE had been
-passed).
 See Documentation/filesystems/directory-locking for more detailed discussion
 of the locking scheme for directory operations.
diff --git a/Documentation/filesystems/caching/backend-api.txt b/Documentation/filesystems/caching/backend-api.txt
index 382d52cdaf2d..d78bab9622c6 100644
--- a/Documentation/filesystems/caching/backend-api.txt
+++ b/Documentation/filesystems/caching/backend-api.txt
@@ -308,6 +308,18 @@ performed on the denizens of the cache.  These are held in a structure of type:
     obtained by calling object->cookie->def->get_aux()/get_attr().
+ (*) Invalidate data object [mandatory]:
+        int (*invalidate_object)(struct fscache_operation *op)
+     This is called to invalidate a data object (as pointed to by op->object).
+     All the data stored for this object should be discarded and an
+     attr_changed operation should be performed.  The caller will follow up
+     with an object update operation.
+     fscache_op_complete() must be called on op before returning.
 (*) Discard object [mandatory]:
        void (*drop_object)(struct fscache_object *object)
@@ -419,7 +431,10 @@ performed on the denizens of the cache.  These are held in a structure of type:
     If an I/O error occurs, fscache_io_error() should be called and -ENOBUFS
     returned if possible or fscache_end_io() called with a suitable error
-     code..
+     code.
+     fscache_put_retrieval() should be called after a page or pages are dealt
+     with.  This will complete the operation when all pages are dealt with.
 (*) Request pages be read from cache [mandatory]:
@@ -526,6 +541,27 @@ FS-Cache provides some utilities that a cache backend may make use of:
     error value should be 0 if successful and an error otherwise.
+ (*) Record that one or more pages being retrieved or allocated have been dealt
+     with:
+        void fscache_retrieval_complete(struct fscache_retrieval *op,
+                                        int n_pages);
+     This is called to record the fact that one or more pages have been dealt
+     with and are no longer the concern of this operation.  When the number of
+     pages remaining in the operation reaches 0, the operation will be
+     completed.
+ (*) Record operation completion:
+        void fscache_op_complete(struct fscache_operation *op);
+     This is called to record the completion of an operation.  This deducts
+     this operation from the parent object's run state, potentially permitting
+     one or more pending operations to start running.
 (*) Set highest store limit:
        void fscache_set_store_limit(struct fscache_object *object,
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt
index 7cc6bf2871eb..97e6c0ecc5ef 100644
--- a/Documentation/filesystems/caching/netfs-api.txt
+++ b/Documentation/filesystems/caching/netfs-api.txt
@@ -35,8 +35,9 @@ This document contains the following sections:
        (12) Index and data file update
        (13) Miscellaneous cookie operations
        (14) Cookie unregistration
-        (15) Index and data file invalidation
+        (15) Index invalidation
-        (16) FS-Cache specific page flags.
+        (16) Data file invalidation
+        (17) FS-Cache specific page flags.
 =============================
@@ -767,13 +768,42 @@ the cookies for "child" indices, objects and pages have been relinquished
 first.
-================================
+==================
-INDEX AND DATA FILE INVALIDATION
+INDEX INVALIDATION
-================================
+==================
+There is no direct way to invalidate an index subtree.  To do this, the caller
+should relinquish and retire the cookie they have, and then acquire a new one.
+======================
+DATA FILE INVALIDATION
+======================
+Sometimes it will be necessary to invalidate an object that contains data.
+Typically this will be necessary when the server tells the netfs of a foreign
+change - at which point the netfs has to throw away all the state it had for an
+inode and reload from the server.
+To indicate that a cache object should be invalidated, the following function
+can be called:
+        void fscache_invalidate(struct fscache_cookie *cookie);
+This can be called with spinlocks held as it defers the work to a thread pool.
+All extant storage, retrieval and attribute change ops at this point are
+cancelled and discarded.  Some future operations will be rejected until the
+cache has had a chance to insert a barrier in the operations queue.  After
+that, operations will be queued again behind the invalidation operation.
+The invalidation operation will perform an attribute change operation and an
+auxiliary data update operation as it is very likely these will have changed.
+Using the following function, the netfs can wait for the invalidation operation
+to have reached a point at which it can start submitting ordinary operations
+once again:
-There is no direct way to invalidate an index subtree or a data file.  To do
+        void fscache_wait_on_invalidate(struct fscache_cookie *cookie);
-this, the caller should relinquish and retire the cookie they have, and then
-acquire a new one.
 ===========================
diff --git a/Documentation/filesystems/caching/object.txt b/Documentation/filesystems/caching/object.txt
index 58313348da87..100ff41127e4 100644
--- a/Documentation/filesystems/caching/object.txt
+++ b/Documentation/filesystems/caching/object.txt
@@ -216,7 +216,14 @@ servicing netfs requests:
     The normal running state.  In this state, requests the netfs makes will be
     passed on to the cache.
- (6) State FSCACHE_OBJECT_UPDATING.
+ (6) State FSCACHE_OBJECT_INVALIDATING.
+     The object is undergoing invalidation.  When the state comes here, it
+     discards all pending read, write and attribute change operations as it is
+     going to clear out the cache entirely and reinitialise it.  It will then
+     continue to the FSCACHE_OBJECT_UPDATING state.
+ (7) State FSCACHE_OBJECT_UPDATING.
     The state machine comes here to update the object in the cache from the
     netfs's records.  This involves updating the auxiliary data that is used
@@ -225,13 +232,13 @@ servicing netfs requests:
 And there are terminal states in which an object cleans itself up, deallocates
 memory and potentially deletes stuff from disk:
- (7) State FSCACHE_OBJECT_LC_DYING.
+ (8) State FSCACHE_OBJECT_LC_DYING.
     The object comes here if it is dying because of a lookup or creation
     error.  This would be due to a disk error or system error of some sort.
     Temporary data is cleaned up, and the parent is released.
- (8) State FSCACHE_OBJECT_DYING.
+ (9) State FSCACHE_OBJECT_DYING.
     The object comes here if it is dying due to an error, because its parent
     cookie has been relinquished by the netfs or because the cache is being
@@ -241,27 +248,27 @@ memory and potentially deletes stuff from disk:
     can destroy themselves.  This object waits for all its children to go away
     before advancing to the next state.
- (9) State FSCACHE_OBJECT_ABORT_INIT.
+(10) State FSCACHE_OBJECT_ABORT_INIT.
     The object comes to this state if it was waiting on its parent in
     FSCACHE_OBJECT_INIT, but its parent died.  The object will destroy itself
     so that the parent may proceed from the FSCACHE_OBJECT_DYING state.
-(10) State FSCACHE_OBJECT_RELEASING.
+(11) State FSCACHE_OBJECT_RELEASING.
-(11) State FSCACHE_OBJECT_RECYCLING.
+(12) State FSCACHE_OBJECT_RECYCLING.
     The object comes to one of these two states when dying once it is rid of
     all its children, if it is dying because the netfs relinquished its
     cookie.  In the first state, the cached data is expected to persist, and
     in the second it will be deleted.
-(12) State FSCACHE_OBJECT_WITHDRAWING.
+(13) State FSCACHE_OBJECT_WITHDRAWING.
     The object transits to this state if the cache decides it wants to
     withdraw the object from service, perhaps to make space, but also due to
     error or just because the whole cache is being withdrawn.
-(13) State FSCACHE_OBJECT_DEAD.
+(14) State FSCACHE_OBJECT_DEAD.
     The object transits to this state when the in-memory object record is
     ready to be deleted.  The object processor shouldn't ever see an object in
diff --git a/Documentation/filesystems/caching/operations.txt b/Documentation/filesystems/caching/operations.txt
index b6b070c57cbf..bee2a5f93d60 100644
--- a/Documentation/filesystems/caching/operations.txt
+++ b/Documentation/filesystems/caching/operations.txt
@@ -174,7 +174,7 @@ Operations are used through the following procedure:
     necessary (the object might have died whilst the thread was waiting).
     When it has finished doing its processing, it should call
-     fscache_put_operation() on it.
+     fscache_op_complete() and fscache_put_operation() on it.
 (4) The operation holds an effective lock upon the object, preventing other
     exclusive ops conflicting until it is released.  The operation can be
diff --git a/Documentation/filesystems/efivarfs.txt b/Documentation/filesystems/efivarfs.txt
new file mode 100644
index 000000000000..c477af086e65
--- /dev/null
+++ b/Documentation/filesystems/efivarfs.txt
@@ -0,0 +1,16 @@
+efivarfs - a (U)EFI variable filesystem
+The efivarfs filesystem was created to address the shortcomings of
+using entries in sysfs to maintain EFI variables. The old sysfs EFI
+variables code only supported variables of up to 1024 bytes. This
+limitation existed in version 0.99 of the EFI specification, but was
+removed before any full releases. Since variables can now be larger
+than a single page, sysfs isn't the best interface for this.
+Variables can be created, deleted and modified with the efivarfs
+filesystem.
+efivarfs is typically mounted like this,
+        mount -t efivarfs none /sys/firmware/efi/efivars
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 104322bf378c..34ea4f1fa6ea 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -200,12 +200,9 @@ inode_readahead_blks=n	This tuning parameter controls the maximum
                        table readahead algorithm will pre-read into
                        the buffer cache.  The default value is 32 blocks.
-nouser_xattr            Disables Extended User Attributes. If you have extended
+nouser_xattr            Disables Extended User Attributes.  See the
-                        attribute support enabled in the kernel configuration
+                        attr(5) manual page and http://acl.bestbits.at/
-                        (CONFIG_EXT4_FS_XATTR), extended attribute support
+                        for more information about extended attributes.
-                        is enabled by default on mount. See the attr(5) manual
-                        page and http://acl.bestbits.at/ for more information
-                        about extended attributes.
 noacl                   This option disables POSIX Access Control List
                        support. If ACL support is enabled in the kernel
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
new file mode 100644
index 000000000000..dcf338e62b71
--- /dev/null
+++ b/Documentation/filesystems/f2fs.txt
@@ -0,0 +1,421 @@
+================================================================================
+WHAT IS Flash-Friendly File System (F2FS)?
+================================================================================
+NAND flash memory-based storage devices, such as SSD, eMMC, and SD cards, have
+been equipped on a variety systems ranging from mobile to server systems. Since
+they are known to have different characteristics from the conventional rotating
+disks, a file system, an upper layer to the storage device, should adapt to the
+changes from the sketch in the design level.
+F2FS is a file system exploiting NAND flash memory-based storage devices, which
+is based on Log-structured File System (LFS). The design has been focused on
+addressing the fundamental issues in LFS, which are snowball effect of wandering
+tree and high cleaning overhead.
+Since a NAND flash memory-based storage device shows different characteristic
+according to its internal geometry or flash memory management scheme, namely FTL,
+F2FS and its tools support various parameters not only for configuring on-disk
+layout, but also for selecting allocation and cleaning algorithms.
+The file system formatting tool, "mkfs.f2fs", is available from the following
+git tree:
+>> git://git.kernel.org/pub/scm/linux/kernel/git/jaegeuk/f2fs-tools.git
+For reporting bugs and sending patches, please use the following mailing list:
+>> linux-f2fs-devel@lists.sourceforge.net
+================================================================================
+BACKGROUND AND DESIGN ISSUES
+================================================================================
+Log-structured File System (LFS)
+--------------------------------
+"A log-structured file system writes all modifications to disk sequentially in
+a log-like structure, thereby speeding up  both file writing and crash recovery.
+The log is the only structure on disk; it contains indexing information so that
+files can be read back from the log efficiently. In order to maintain large free
+areas on disk for fast writing, we divide  the log into segments and use a
+segment cleaner to compress the live information from heavily fragmented
+segments." from Rosenblum, M. and Ousterhout, J. K., 1992, "The design and
+implementation of a log-structured file system", ACM Trans. Computer Systems
+10, 1, 26–52.
+Wandering Tree Problem
+----------------------
+In LFS, when a file data is updated and written to the end of log, its direct
+pointer block is updated due to the changed location. Then the indirect pointer
+block is also updated due to the direct pointer block update. In this manner,
+the upper index structures such as inode, inode map, and checkpoint block are
+also updated recursively. This problem is called as wandering tree problem [1],
+and in order to enhance the performance, it should eliminate or relax the update
+propagation as much as possible.
+[1] Bityutskiy, A. 2005. JFFS3 design issues. http://www.linux-mtd.infradead.org/
+Cleaning Overhead
+-----------------
+Since LFS is based on out-of-place writes, it produces so many obsolete blocks
+scattered across the whole storage. In order to serve new empty log space, it
+needs to reclaim these obsolete blocks seamlessly to users. This job is called
+as a cleaning process.
+The process consists of three operations as follows.
+1. A victim segment is selected through referencing segment usage table.
+2. It loads parent index structures of all the data in the victim identified by
+   segment summary blocks.
+3. It checks the cross-reference between the data and its parent index structure.
+4. It moves valid data selectively.
+This cleaning job may cause unexpected long delays, so the most important goal
+is to hide the latencies to users. And also definitely, it should reduce the
+amount of valid data to be moved, and move them quickly as well.
+================================================================================
+KEY FEATURES
+================================================================================
+Flash Awareness
+---------------
+- Enlarge the random write area for better performance, but provide the high
+  spatial locality
+- Align FS data structures to the operational units in FTL as best efforts
+Wandering Tree Problem
+----------------------
+- Use a term, “node”, that represents inodes as well as various pointer blocks
+- Introduce Node Address Table (NAT) containing the locations of all the “node”
+  blocks; this will cut off the update propagation.
+Cleaning Overhead
+-----------------
+- Support a background cleaning process
+- Support greedy and cost-benefit algorithms for victim selection policies
+- Support multi-head logs for static/dynamic hot and cold data separation
+- Introduce adaptive logging for efficient block allocation
+================================================================================
+MOUNT OPTIONS
+================================================================================
+background_gc_off      Turn off cleaning operations, namely garbage collection,
+                       triggered in background when I/O subsystem is idle.
+disable_roll_forward   Disable the roll-forward recovery routine
+discard                Issue discard/TRIM commands when a segment is cleaned.
+no_heap                Disable heap-style segment allocation which finds free
+                       segments for data from the beginning of main area, while
+                       for node from the end of main area.
+nouser_xattr           Disable Extended User Attributes. Note: xattr is enabled
+                       by default if CONFIG_F2FS_FS_XATTR is selected.
+noacl                  Disable POSIX Access Control List. Note: acl is enabled
+                       by default if CONFIG_F2FS_FS_POSIX_ACL is selected.
+active_logs=%u         Support configuring the number of active logs. In the
+                       current design, f2fs supports only 2, 4, and 6 logs.
+                       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.
+================================================================================
+DEBUGFS ENTRIES
+================================================================================
+/sys/kernel/debug/f2fs/ contains information about all the partitions mounted as
+f2fs. Each file shows the whole f2fs information.
+/sys/kernel/debug/f2fs/status includes:
+ - major file system information managed by f2fs currently
+ - average SIT information about whole segments
+ - current memory footprint consumed by f2fs.
+================================================================================
+USAGE
+================================================================================
+1. Download userland tools and compile them.
+2. Skip, if f2fs was compiled statically inside kernel.
+   Otherwise, insert the f2fs.ko module.
+ # insmod f2fs.ko
+3. Create a directory trying to mount
+ # mkdir /mnt/f2fs
+4. Format the block device, and then mount as f2fs
+ # mkfs.f2fs -l label /dev/block_device
+ # mount -t f2fs /dev/block_device /mnt/f2fs
+Format options
+--------------
+-l [label]   : Give a volume label, up to 256 unicode name.
+-a [0 or 1]  : Split start location of each area for heap-based allocation.
+               1 is set by default, which performs this.
+-o [int]     : Set overprovision ratio in percent over volume size.
+               5 is set by default.
+-s [int]     : Set the number of segments per section.
+               1 is set by default.
+-z [int]     : Set the number of sections per zone.
+               1 is set by default.
+-e [str]     : Set basic extension list. e.g. "mp3,gif,mov"
+================================================================================
+DESIGN
+================================================================================
+On-disk Layout
+--------------
+F2FS divides the whole volume into a number of segments, each of which is fixed
+to 2MB in size. A section is composed of consecutive segments, and a zone
+consists of a set of sections. By default, section and zone sizes are set to one
+segment size identically, but users can easily modify the sizes by mkfs.
+F2FS splits the entire volume into six areas, and all the areas except superblock
+consists of multiple segments as described below.
+                                            align with the zone size <-|
+                 |-> align with the segment size
+     _________________________________________________________________________
+    |            |            |   Segment   |    Node     |   Segment  |      |
+    | Superblock | Checkpoint |    Info.    |   Address   |   Summary  | Main |
+    |    (SB)    |   (CP)     | Table (SIT) | Table (NAT) | Area (SSA) |      |
+    |____________|_____2______|______N______|______N______|______N_____|__N___|
+                                                                       .      .
+                                                             .                .
+                                                 .                            .
+                                    ._________________________________________.
+                                    |_Segment_|_..._|_Segment_|_..._|_Segment_|
+                                    .           .
+                                    ._________._________
+                                    |_section_|__...__|_
+                                    .            .
+                                    .________.
+                                    |__zone__|
+- Superblock (SB)
+ : It is located at the beginning of the partition, and there exist two copies
+   to avoid file system crash. It contains basic partition information and some
+   default parameters of f2fs.
+- Checkpoint (CP)
+ : It contains file system information, bitmaps for valid NAT/SIT sets, orphan
+   inode lists, and summary entries of current active segments.
+- Segment Information Table (SIT)
+ : It contains segment information such as valid block count and bitmap for the
+   validity of all the blocks.
+- Node Address Table (NAT)
+ : It is composed of a block address table for all the node blocks stored in
+   Main area.
+- Segment Summary Area (SSA)
+ : It contains summary entries which contains the owner information of all the
+   data and node blocks stored in Main area.
+- Main Area
+ : It contains file and directory data including their indices.
+In order to avoid misalignment between file system and flash-based storage, F2FS
+aligns the start block address of CP with the segment size. Also, it aligns the
+start block address of Main area with the zone size by reserving some segments
+in SSA area.
+Reference the following survey for additional technical details.
+https://wiki.linaro.org/WorkingGroups/Kernel/Projects/FlashCardSurvey
+File System Metadata Structure
+------------------------------
+F2FS adopts the checkpointing scheme to maintain file system consistency. At
+mount time, F2FS first tries to find the last valid checkpoint data by scanning
+CP area. In order to reduce the scanning time, F2FS uses only two copies of CP.
+One of them always indicates the last valid data, which is called as shadow copy
+mechanism. In addition to CP, NAT and SIT also adopt the shadow copy mechanism.
+For file system consistency, each CP points to which NAT and SIT copies are
+valid, as shown as below.
+  +--------+----------+---------+
+  |   CP   |    SIT   |   NAT   |
+  +--------+----------+---------+
+  .         .          .          .
+  .            .              .              .
+  .               .                 .                 .
+  +-------+-------+--------+--------+--------+--------+
+  | CP #0 | CP #1 | SIT #0 | SIT #1 | NAT #0 | NAT #1 |
+  +-------+-------+--------+--------+--------+--------+
+     |             ^                          ^
+     |             |                          |
+     `----------------------------------------'
+Index Structure
+---------------
+The key data structure to manage the data locations is a "node". Similar to
+traditional file structures, F2FS has three types of node: inode, direct node,
+indirect node. F2FS assigns 4KB to an inode block which contains 923 data block
+indices, two direct node pointers, two indirect node pointers, and one double
+indirect node pointer as described below. One direct node block contains 1018
+data blocks, and one indirect node block contains also 1018 node blocks. Thus,
+one inode block (i.e., a file) covers:
+  4KB * (923 + 2 * 1018 + 2 * 1018 * 1018 + 1018 * 1018 * 1018) := 3.94TB.
+   Inode block (4KB)
+     |- data (923)
+     |- direct node (2)
+     |          `- data (1018)
+     |- indirect node (2)
+     |            `- direct node (1018)
+     |                       `- data (1018)
+     `- double indirect node (1)
+                         `- indirect node (1018)
+                                      `- direct node (1018)
+                                                 `- data (1018)
+Note that, all the node blocks are mapped by NAT which means the location of
+each node is translated by the NAT table. In the consideration of the wandering
+tree problem, F2FS is able to cut off the propagation of node updates caused by
+leaf data writes.
+Directory Structure
+-------------------
+A directory entry occupies 11 bytes, which consists of the following attributes.
+- hash          hash value of the file name
+- ino           inode number
+- len           the length of file name
+- type          file type such as directory, symlink, etc
+A dentry block consists of 214 dentry slots and file names. Therein a bitmap is
+used to represent whether each dentry is valid or not. A dentry block occupies
+4KB with the following composition.
+  Dentry Block(4 K) = bitmap (27 bytes) + reserved (3 bytes) +
+                      dentries(11 * 214 bytes) + file name (8 * 214 bytes)
+                         [Bucket]
+             +--------------------------------+
+             |dentry block 1 | dentry block 2 |
+             +--------------------------------+
+             .               .
+       .                             .
+  .       [Dentry Block Structure: 4KB]       .
+  +--------+----------+----------+------------+
+  | bitmap | reserved | dentries | file names |
+  +--------+----------+----------+------------+
+  [Dentry Block: 4KB] .   .
+                 .               .
+            .                          .
+            +------+------+-----+------+
+            | hash | ino  | len | type |
+            +------+------+-----+------+
+            [Dentry Structure: 11 bytes]
+F2FS implements multi-level hash tables for directory structure. Each level has
+a hash table with dedicated number of hash buckets as shown below. Note that
+"A(2B)" means a bucket includes 2 data blocks.
+----------------------
+A : bucket
+B : block
+N : MAX_DIR_HASH_DEPTH
+----------------------
+level #0   | A(2B)
+           |
+level #1   | A(2B) - A(2B)
+           |
+level #2   | A(2B) - A(2B) - A(2B) - A(2B)
+     .     |   .       .       .       .
+level #N/2 | A(2B) - A(2B) - A(2B) - A(2B) - A(2B) - ... - A(2B)
+     .     |   .       .       .       .
+level #N   | A(4B) - A(4B) - A(4B) - A(4B) - A(4B) - ... - A(4B)
+The number of blocks and buckets are determined by,
+                            ,- 2, if n < MAX_DIR_HASH_DEPTH / 2,
+  # of blocks in level #n = |
+                            `- 4, Otherwise
+                             ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2,
+  # of buckets in level #n = |
+                             `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise
+When F2FS finds a file name in a directory, at first a hash value of the file
+name is calculated. Then, F2FS scans the hash table in level #0 to find the
+dentry consisting of the file name and its inode number. If not found, F2FS
+scans the next hash table in level #1. In this way, F2FS scans hash tables in
+each levels incrementally from 1 to N. In each levels F2FS needs to scan only
+one bucket determined by the following equation, which shows O(log(# of files))
+complexity.
+  bucket number to scan in level #n = (hash value) % (# of buckets in level #n)
+In the case of file creation, F2FS finds empty consecutive slots that cover the
+file name. F2FS searches the empty slots in the hash tables of whole levels from
+1 to N in the same way as the lookup operation.
+The following figure shows an example of two cases holding children.
+       --------------> Dir <--------------
+       |                                 |
+    child                             child
+    child - child                     [hole] - child
+    child - child - child             [hole] - [hole] - child
+   Case 1:                           Case 2:
+   Number of children = 6,           Number of children = 3,
+   File size = 7                     File size = 7
+Default Block Allocation
+------------------------
+At runtime, F2FS manages six active logs inside "Main" area: Hot/Warm/Cold node
+and Hot/Warm/Cold data.
+- Hot node      contains direct node blocks of directories.
+- Warm node     contains direct node blocks except hot node blocks.
+- Cold node     contains indirect node blocks
+- Hot data      contains dentry blocks
+- Warm data     contains data blocks except hot and cold data blocks
+- Cold data     contains multimedia data or migrated data blocks
+LFS has two schemes for free space management: threaded log and copy-and-compac-
+tion. The copy-and-compaction scheme which is known as cleaning, is well-suited
+for devices showing very good sequential write performance, since free segments
+are served all the time for writing new data. However, it suffers from cleaning
+overhead under high utilization. Contrarily, the threaded log scheme suffers
+from random writes, but no cleaning process is needed. F2FS adopts a hybrid
+scheme where the copy-and-compaction scheme is adopted by default, but the
+policy is dynamically changed to the threaded log scheme according to the file
+system status.
+In order to align F2FS with underlying flash-based storage, F2FS allocates a
+segment in a unit of section. F2FS expects that the section size would be the
+same as the unit size of garbage collection in FTL. Furthermore, with respect
+to the mapping granularity in FTL, F2FS allocates each section of the active
+logs from different zones as much as possible, since FTL can write the data in
+the active logs into one allocation unit according to its mapping granularity.
+Cleaning process
+----------------
+F2FS does cleaning both on demand and in the background. On-demand cleaning is
+triggered when there are not enough free segments to serve VFS calls. Background
+cleaner is operated by a kernel thread, and triggers the cleaning job when the
+system is idle.
+F2FS supports two victim selection policies: greedy and cost-benefit algorithms.
+In the greedy algorithm, F2FS selects a victim segment having the smallest number
+of valid blocks. In the cost-benefit algorithm, F2FS selects a victim segment
+according to the segment age and the number of valid blocks in order to address
+log block thrashing problem in the greedy algorithm. F2FS adopts the greedy
+algorithm for on-demand cleaner, while background cleaner adopts cost-benefit
+algorithm.
+In order to identify whether the data in the victim segment are valid or not,
+F2FS manages a bitmap. Each bit represents the validity of a block, and the
+bitmap is composed of a bit stream covering whole blocks in main area.
diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt
index 092fad92a3f0..01c2db769791 100644
--- a/Documentation/filesystems/nfs/nfs41-server.txt
+++ b/Documentation/filesystems/nfs/nfs41-server.txt
@@ -39,21 +39,10 @@ interoperability problems with future clients.  Known issues:
          from a linux client are possible, but we aren't really
          conformant with the spec (for example, we don't use kerberos
          on the backchannel correctly).
-        - Incomplete backchannel support: incomplete backchannel gss
-          support and no support for BACKCHANNEL_CTL mean that
-          callbacks (hence delegations and layouts) may not be
-          available and clients confused by the incomplete
-          implementation may fail.
        - We do not support SSV, which provides security for shared
          client-server state (thus preventing unauthorized tampering
          with locks and opens, for example).  It is mandatory for
          servers to support this, though no clients use it yet.
-        - Mandatory operations which we do not support, such as
-          DESTROY_CLIENTID, are not currently used by clients, but will be
-          (and the spec recommends their uses in common cases), and
-          clients should not be expected to know how to recover from the
-          case where they are not supported.  This will eventually cause
-          interoperability failures.
 In addition, some limitations are inherited from the current NFSv4
 implementation:
@@ -89,7 +78,7 @@ Operations
   |                      | MNI        | or OPT)      |                |
   +----------------------+------------+--------------+----------------+
   | ACCESS               | REQ        |              | Section 18.1   |
-NS | BACKCHANNEL_CTL      | REQ        |              | Section 18.33  |
+I  | BACKCHANNEL_CTL      | REQ        |              | Section 18.33  |
 I  | BIND_CONN_TO_SESSION | REQ        |              | Section 18.34  |
   | CLOSE                | REQ        |              | Section 18.2   |
   | COMMIT               | REQ        |              | Section 18.3   |
@@ -99,7 +88,7 @@ NS*| DELEGPURGE           | OPT        | FDELG (REQ)  | Section 18.5   |
   | DELEGRETURN          | OPT        | FDELG,       | Section 18.6   |
   |                      |            | DDELG, pNFS  |                |
   |                      |            | (REQ)        |                |
-NS | DESTROY_CLIENTID     | REQ        |              | Section 18.50  |
+I  | DESTROY_CLIENTID     | REQ        |              | Section 18.50  |
 I  | DESTROY_SESSION      | REQ        |              | Section 18.37  |
 I  | EXCHANGE_ID          | REQ        |              | Section 18.35  |
 I  | FREE_STATEID         | REQ        |              | Section 18.38  |
@@ -192,7 +181,6 @@ EXCHANGE_ID:
 CREATE_SESSION:
 * backchannel attributes are ignored
-* backchannel security parameters are ignored
 SEQUENCE:
 * no support for dynamic slot table renegotiation (optional)
@@ -202,7 +190,7 @@ Nonstandard compound limitations:
  ca_maxrequestsize request and a ca_maxresponsesize reply, so we may
  fail to live up to the promise we made in CREATE_SESSION fore channel
  negotiation.
-* No more than one IO operation (read, write, readdir) allowed per
+* No more than one read-like operation allowed per compound; encoding
-  compound.
+  replies that cross page boundaries (except for read data) not handled.
 See also http://wiki.linux-nfs.org/wiki/index.php/Server_4.0_and_4.1_issues.
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index 0742feebc6e2..0472c31c163b 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -281,7 +281,7 @@ ext2_write_failed and callers for an example.
 [mandatory]
-        ->truncate is going away.  The whole truncate sequence needs to be
+        ->truncate is gone.  The whole truncate sequence needs to be
 implemented in ->setattr, which is now mandatory for filesystems
 implementing on-disk size changes.  Start with a copy of the old inode_setattr
 and vmtruncate, and the reorder the vmtruncate + foofs_vmtruncate sequence to
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 3844d21d6ca3..fd8d0d594fc7 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -41,6 +41,7 @@ Table of Contents
  3.5   /proc/<pid>/mountinfo - Information about mounts
  3.6   /proc/<pid>/comm  & /proc/<pid>/task/<tid>/comm
  3.7   /proc/<pid>/task/<tid>/children - Information about task children
+  3.8   /proc/<pid>/fdinfo/<fd> - Information about opened file
  4     Configuring procfs
  4.1   Mount options
@@ -142,7 +143,7 @@ Table 1-1: Process specific entries in /proc
 pagemap        Page table
 stack          Report full stack trace, enable via CONFIG_STACKTRACE
 smaps          a extension based on maps, showing the memory consumption of
-                each mapping
+                each mapping and flags associated with it
 ..............................................................................
 For example, to get the status information of a process, all you have to do is
@@ -181,6 +182,7 @@ read the file /proc/PID/status:
  CapPrm: 0000000000000000
  CapEff: 0000000000000000
  CapBnd: ffffffffffffffff
+  Seccomp:        0
  voluntary_ctxt_switches:        0
  nonvoluntary_ctxt_switches:     1
@@ -237,6 +239,7 @@ Table 1-2: Contents of the status files (as of 2.6.30-rc7)
 CapPrm                      bitmap of permitted capabilities
 CapEff                      bitmap of effective capabilities
 CapBnd                      bitmap of capabilities bounding set
+ Seccomp                     seccomp mode, like prctl(PR_GET_SECCOMP, ...)
 Cpus_allowed                mask of CPUs on which this process may run
 Cpus_allowed_list           Same as previous, but in "list format"
 Mems_allowed                mask of memory nodes allowed to this process
@@ -415,8 +418,9 @@ Swap:                  0 kB
 KernelPageSize:        4 kB
 MMUPageSize:           4 kB
 Locked:              374 kB
+VmFlags: rd ex mr mw me de
-The first of these lines shows the same information as is displayed for the
+the first of these lines shows the same information as is displayed for the
 mapping in /proc/PID/maps.  The remaining lines show the size of the mapping
 (size), the amount of the mapping that is currently resident in RAM (RSS), the
 process' proportional share of this mapping (PSS), the number of clean and
@@ -430,6 +434,41 @@ and a page is modified, the file page is replaced by a private anonymous copy.
 "Swap" shows how much would-be-anonymous memory is also used, but out on
 swap.
+"VmFlags" field deserves a separate description. This member represents the kernel
+flags associated with the particular virtual memory area in two letter encoded
+manner. The codes are the following:
+    rd  - readable
+    wr  - writeable
+    ex  - executable
+    sh  - shared
+    mr  - may read
+    mw  - may write
+    me  - may execute
+    ms  - may share
+    gd  - stack segment growns down
+    pf  - pure PFN range
+    dw  - disabled write to the mapped file
+    lo  - pages are locked in memory
+    io  - memory mapped I/O area
+    sr  - sequential read advise provided
+    rr  - random read advise provided
+    dc  - do not copy area on fork
+    de  - do not expand area on remapping
+    ac  - area is accountable
+    nr  - swap space is not reserved for the area
+    ht  - area uses huge tlb pages
+    nl  - non-linear mapping
+    ar  - architecture specific flag
+    dd  - do not include area into core dump
+    mm  - mixed map area
+    hg  - huge page advise flag
+    nh  - no-huge page advise flag
+    mg  - mergable advise flag
+Note that there is no guarantee that every flag and associated mnemonic will
+be present in all further kernel releases. Things get changed, the flags may
+be vanished or the reverse -- new added.
 This file is only present if the CONFIG_MMU kernel configuration option is
 enabled.
@@ -1595,6 +1634,93 @@ pids, so one need to either stop or freeze processes being inspected
 if precise results are needed.
+3.7     /proc/<pid>/fdinfo/<fd> - Information about opened file
+---------------------------------------------------------------
+This file provides information associated with an opened file. The regular
+files have at least two fields -- 'pos' and 'flags'. The 'pos' represents
+the current offset of the opened file in decimal form [see lseek(2) for
+details] and 'flags' denotes the octal O_xxx mask the file has been
+created with [see open(2) for details].
+A typical output is
+        pos:    0
+        flags:  0100002
+The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags
+pair provide additional information particular to the objects they represent.
+        Eventfd files
+        ~~~~~~~~~~~~~
+        pos:    0
+        flags:  04002
+        eventfd-count:  5a
+        where 'eventfd-count' is hex value of a counter.
+        Signalfd files
+        ~~~~~~~~~~~~~~
+        pos:    0
+        flags:  04002
+        sigmask:        0000000000000200
+        where 'sigmask' is hex value of the signal mask associated
+        with a file.
+        Epoll files
+        ~~~~~~~~~~~
+        pos:    0
+        flags:  02
+        tfd:        5 events:       1d data: ffffffffffffffff
+        where 'tfd' is a target file descriptor number in decimal form,
+        'events' is events mask being watched and the 'data' is data
+        associated with a target [see epoll(7) for more details].
+        Fsnotify files
+        ~~~~~~~~~~~~~~
+        For inotify files the format is the following
+        pos:    0
+        flags:  02000000
+        inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d
+        where 'wd' is a watch descriptor in decimal form, ie a target file
+        descriptor number, 'ino' and 'sdev' are inode and device where the
+        target file resides and the 'mask' is the mask of events, all in hex
+        form [see inotify(7) for more details].
+        If the kernel was built with exportfs support, the path to the target
+        file is encoded as a file handle.  The file handle is provided by three
+        fields 'fhandle-bytes', 'fhandle-type' and 'f_handle', all in hex
+        format.
+        If the kernel is built without exportfs support the file handle won't be
+        printed out.
+        If there is no inotify mark attached yet the 'inotify' line will be omitted.
+        For fanotify files the format is
+        pos:    0
+        flags:  02
+        fanotify flags:10 event-flags:0
+        fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003
+        fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4
+        where fanotify 'flags' and 'event-flags' are values used in fanotify_init
+        call, 'mnt_id' is the mount point identifier, 'mflags' is the value of
+        flags associated with mark which are tracked separately from events
+        mask. 'ino', 'sdev' are target inode and device, 'mask' is the events
+        mask and 'ignored_mask' is the mask of events which are to be ignored.
+        All in hex format. Incorporation of 'mflags', 'mask' and 'ignored_mask'
+        does provide information about flags and mask used in fanotify_mark
+        call [see fsnotify manpage for details].
+        While the first three lines are mandatory and always printed, the rest is
+        optional and may be omitted if no marks created yet.
 ------------------------------------------------------------------------------
 Configuring procfs
 ------------------------------------------------------------------------------
diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt
index de1e6c4dccff..d230dd9c99b0 100644
--- a/Documentation/filesystems/vfat.txt
+++ b/Documentation/filesystems/vfat.txt
@@ -111,6 +111,15 @@ tz=UTC        -- Interpret timestamps as UTC rather than local time.
                 useful when mounting devices (like digital cameras)
                 that are set to UTC in order to avoid the pitfalls of
                 local time.
+time_offset=minutes
+              -- Set offset for conversion of timestamps from local time
+                 used by FAT to UTC. I.e. <minutes> minutes will be subtracted
+                 from each timestamp to convert it to UTC used internally by
+                 Linux. This is useful when time zone set in sys_tz is
+                 not the time zone used by the filesystem. Note that this
+                 option still does not provide correct time stamps in all
+                 cases in presence of DST - time stamps in a different DST
+                 setting will be off by one hour.
 showexec      -- If set, the execute permission bits of the file will be
                 allowed only if the extension part of the name is .EXE,
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 2ee133e030c3..e3869098163e 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -350,7 +350,6 @@ struct inode_operations {
        int (*readlink) (struct dentry *, char __user *,int);
        void * (*follow_link) (struct dentry *, struct nameidata *);
        void (*put_link) (struct dentry *, struct nameidata *, void *);
-        void (*truncate) (struct inode *);
        int (*permission) (struct inode *, int);
        int (*get_acl)(struct inode *, int);
        int (*setattr) (struct dentry *, struct iattr *);
@@ -431,16 +430,6 @@ otherwise noted.
        started might not be in the page cache at the end of the
        walk).
-  truncate: Deprecated. This will not be called if ->setsize is defined.
-        Called by the VFS to change the size of a file.  The
-        i_size field of the inode is set to the desired size by the
-        VFS before this method is called.  This method is called by
-        the truncate(2) system call and related functionality.
-        Note: ->truncate and vmtruncate are deprecated. Do not add new
-        instances/calls of these. Filesystems should be converted to do their
-        truncate sequence via ->setattr().
  permission: called by the VFS to check for access rights on a POSIX-like
        filesystem.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 87850d86c559..8386aadc0a82 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -209,3 +209,13 @@ doesn't use CPU cycles.
 Trip points must be set properly before switching to automatic fan speed
 control mode. The driver will perform basic integrity checks before
 actually switching to automatic control mode.
+Temperature offset attributes
+-----------------------------
+The driver supports temp[1-3]_offset sysfs attributes to adjust the reported
+temperature for thermal diodes or diode-connected thermal transistors.
+If a temperature sensor is configured for thermistors, the attribute values
+are ignored. If the thermal sensor type is Intel PECI, the temperature offset
+must be programmed to the critical CPU temperature.
diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices
index abf63615ee05..22182660dda7 100644
--- a/Documentation/i2c/instantiating-devices
+++ b/Documentation/i2c/instantiating-devices
@@ -91,7 +91,7 @@ Example (from the nxp OHCI driver):
 static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END };
-static int __devinit usb_hcd_nxp_probe(struct platform_device *pdev)
+static int usb_hcd_nxp_probe(struct platform_device *pdev)
 {
        (...)
        struct i2c_adapter *i2c_adap;
diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index 49f5b680809d..d1f22618e14b 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -23,6 +23,12 @@ don't match these function names.  For some of the operations which pass a
 single data byte, the functions using SMBus protocol operation names execute
 a different protocol operation entirely.
+Each transaction type corresponds to a functionality flag. Before calling a
+transaction function, a device driver should always check (just once) for
+the corresponding functionality flag to ensure that the underlying I2C
+adapter supports the transaction in question. See
+<file:Documentation/i2c/functionality> for the details.
 Key to symbols
 ==============
@@ -49,6 +55,8 @@ This sends a single bit to the device, at the place of the Rd/Wr bit.
 A Addr Rd/Wr [A] P
+Functionality flag: I2C_FUNC_SMBUS_QUICK
 SMBus Receive Byte:  i2c_smbus_read_byte()
 ==========================================
@@ -60,6 +68,8 @@ the previous SMBus command.
 S Addr Rd [A] [Data] NA P
+Functionality flag: I2C_FUNC_SMBUS_READ_BYTE
 SMBus Send Byte:  i2c_smbus_write_byte()
 ========================================
@@ -69,6 +79,8 @@ to a device.  See Receive Byte for more information.
 S Addr Wr [A] Data [A] P
+Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE
 SMBus Read Byte:  i2c_smbus_read_byte_data()
 ============================================
@@ -78,6 +90,8 @@ The register is specified through the Comm byte.
 S Addr Wr [A] Comm [A] S Addr Rd [A] [Data] NA P
+Functionality flag: I2C_FUNC_SMBUS_READ_BYTE_DATA
 SMBus Read Word:  i2c_smbus_read_word_data()
 ============================================
@@ -88,6 +102,8 @@ byte. But this time, the data is a complete word (16 bits).
 S Addr Wr [A] Comm [A] S Addr Rd [A] [DataLow] A [DataHigh] NA P
+Functionality flag: I2C_FUNC_SMBUS_READ_WORD_DATA
 Note the convenience function i2c_smbus_read_word_swapped is
 available for reads where the two data bytes are the other way
 around (not SMBus compliant, but very popular.)
@@ -102,6 +118,8 @@ the Read Byte operation.
 S Addr Wr [A] Comm [A] Data [A] P
+Functionality flag: I2C_FUNC_SMBUS_WRITE_BYTE_DATA
 SMBus Write Word:  i2c_smbus_write_word_data()
 ==============================================
@@ -112,6 +130,8 @@ specified through the Comm byte.
 S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] P
+Functionality flag: I2C_FUNC_SMBUS_WRITE_WORD_DATA
 Note the convenience function i2c_smbus_write_word_swapped is
 available for writes where the two data bytes are the other way
 around (not SMBus compliant, but very popular.)
@@ -126,6 +146,8 @@ This command selects a device register (through the Comm byte), sends
 S Addr Wr [A] Comm [A] DataLow [A] DataHigh [A] 
                             S Addr Rd [A] [DataLow] A [DataHigh] NA P
+Functionality flag: I2C_FUNC_SMBUS_PROC_CALL
 SMBus Block Read:  i2c_smbus_read_block_data()
 ==============================================
@@ -137,6 +159,8 @@ of data is specified by the device in the Count byte.
 S Addr Wr [A] Comm [A] 
           S Addr Rd [A] [Count] A [Data] A [Data] A ... A [Data] NA P
+Functionality flag: I2C_FUNC_SMBUS_READ_BLOCK_DATA
 SMBus Block Write:  i2c_smbus_write_block_data()
 ================================================
@@ -147,6 +171,8 @@ Comm byte. The amount of data is specified in the Count byte.
 S Addr Wr [A] Comm [A] Count [A] Data [A] Data [A] ... [A] Data [A] P
+Functionality flag: I2C_FUNC_SMBUS_WRITE_BLOCK_DATA
 SMBus Block Write - Block Read Process Call
 ===========================================
@@ -160,6 +186,8 @@ This command selects a device register (through the Comm byte), sends
 S Addr Wr [A] Comm [A] Count [A] Data [A] ...
                             S Addr Rd [A] [Count] A [Data] ... A P
+Functionality flag: I2C_FUNC_SMBUS_BLOCK_PROC_CALL
 SMBus Host Notify
 =================
@@ -229,15 +257,7 @@ designated register that is specified through the Comm byte.
 S Addr Wr [A] Comm [A] 
           S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
+Functionality flag: I2C_FUNC_SMBUS_READ_I2C_BLOCK
-I2C Block Read (2 Comm bytes)
-=============================
-This command reads a block of bytes from a device, from a 
-designated register that is specified through the two Comm bytes.
-S Addr Wr [A] Comm1 [A] Comm2 [A] 
-           S Addr Rd [A] [Data] A [Data] A ... A [Data] NA P
 I2C Block Write:  i2c_smbus_write_i2c_block_data()
@@ -249,3 +269,5 @@ Comm byte. Note that command lengths of 0, 2, or more bytes are
 supported as they are indistinguishable from data.
 S Addr Wr [A] Comm [A] Data [A] Data [A] ... [A] Data [A] P
+Functionality flag: I2C_FUNC_SMBUS_WRITE_I2C_BLOCK
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 20e248cc03a9..363e348bff9b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -446,12 +446,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        possible to determine what the correct size should be.
                        This option provides an override for these situations.
-        capability.disable=
-                        [SECURITY] Disable capabilities.  This would normally
-                        be used only if an alternative security model is to be
-                        configured.  Potentially dangerous and should only be
-                        used if you are entirely sure of the consequences.
        ccw_timeout_log [S390]
                        See Documentation/s390/CommonIO for details.
@@ -1503,9 +1497,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        mem=nn[KMG]     [KNL,BOOT] Force usage of a specific amount of memory
                        Amount of memory to be used when the kernel is not able
                        to see the whole system memory or for test.
-                        [X86-32] Use together with memmap= to avoid physical
+                        [X86] Work as limiting max address. Use together
-                        address space collisions. Without memmap= PCI devices
+                        with memmap= to avoid physical address space collisions.
-                        could be placed at addresses belonging to unused RAM.
+                        Without memmap= PCI devices could be placed at addresses
+                        belonging to unused RAM.
        mem=nopentium   [BUGS=X86-32] Disable usage of 4MB pages for kernel
                        memory.
@@ -2032,6 +2027,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        nr_uarts=       [SERIAL] maximum number of UARTs to be registered.
+        numa_balancing= [KNL,X86] Enable or disable automatic NUMA balancing.
+                        Allowed values are enable and disable
        numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.
                        one of ['zone', 'node', 'default'] can be specified
                        This can be set from sysctl after boot.
diff --git a/Documentation/kref.txt b/Documentation/kref.txt
index 48ba715d5a63..ddf85a5dde0c 100644
--- a/Documentation/kref.txt
+++ b/Documentation/kref.txt
@@ -213,3 +213,91 @@ presentation on krefs, which can be found at:
 and:
  http://www.kroah.com/linux/talks/ols_2004_kref_talk/
+The above example could also be optimized using kref_get_unless_zero() in
+the following way:
+static struct my_data *get_entry()
+{
+        struct my_data *entry = NULL;
+        mutex_lock(&mutex);
+        if (!list_empty(&q)) {
+                entry = container_of(q.next, struct my_data, link);
+                if (!kref_get_unless_zero(&entry->refcount))
+                        entry = NULL;
+        }
+        mutex_unlock(&mutex);
+        return entry;
+}
+static void release_entry(struct kref *ref)
+{
+        struct my_data *entry = container_of(ref, struct my_data, refcount);
+        mutex_lock(&mutex);
+        list_del(&entry->link);
+        mutex_unlock(&mutex);
+        kfree(entry);
+}
+static void put_entry(struct my_data *entry)
+{
+        kref_put(&entry->refcount, release_entry);
+}
+Which is useful to remove the mutex lock around kref_put() in put_entry(), but
+it's important that kref_get_unless_zero is enclosed in the same critical
+section that finds the entry in the lookup table,
+otherwise kref_get_unless_zero may reference already freed memory.
+Note that it is illegal to use kref_get_unless_zero without checking its
+return value. If you are sure (by already having a valid pointer) that
+kref_get_unless_zero() will return true, then use kref_get() instead.
+The function kref_get_unless_zero also makes it possible to use rcu
+locking for lookups in the above example:
+struct my_data
+{
+        struct rcu_head rhead;
+        .
+        struct kref refcount;
+        .
+        .
+};
+static struct my_data *get_entry_rcu()
+{
+        struct my_data *entry = NULL;
+        rcu_read_lock();
+        if (!list_empty(&q)) {
+                entry = container_of(q.next, struct my_data, link);
+                if (!kref_get_unless_zero(&entry->refcount))
+                        entry = NULL;
+        }
+        rcu_read_unlock();
+        return entry;
+}
+static void release_entry_rcu(struct kref *ref)
+{
+        struct my_data *entry = container_of(ref, struct my_data, refcount);
+        mutex_lock(&mutex);
+        list_del_rcu(&entry->link);
+        mutex_unlock(&mutex);
+        kfree_rcu(entry, rhead);
+}
+static void put_entry(struct my_data *entry)
+{
+        kref_put(&entry->refcount, release_entry_rcu);
+}
+But note that the struct kref member needs to remain in valid memory for a
+rcu grace period after release_entry_rcu was called. That can be accomplished
+by using kfree_rcu(entry, rhead) as done above, or by calling synchronize_rcu()
+before using kfree, but note that synchronize_rcu() may sleep for a
+substantial amount of time.
+Thomas Hellstrom <thellstrom@vmware.com>
diff --git a/Documentation/memory-hotplug.txt b/Documentation/memory-hotplug.txt
index c6f993d491b5..8e5eacbdcfa3 100644
--- a/Documentation/memory-hotplug.txt
+++ b/Documentation/memory-hotplug.txt
@@ -390,6 +390,7 @@ struct memory_notify {
       unsigned long start_pfn;
       unsigned long nr_pages;
       int status_change_nid_normal;
+       int status_change_nid_high;
       int status_change_nid;
 }
@@ -397,7 +398,9 @@ start_pfn is start_pfn of online/offline memory.
 nr_pages is # of pages of online/offline memory.
 status_change_nid_normal is set node id when N_NORMAL_MEMORY of nodemask
 is (will be) set/clear, if this is -1, then nodemask status is not changed.
-status_change_nid is set node id when N_HIGH_MEMORY of nodemask is (will be)
+status_change_nid_high is set node id when N_HIGH_MEMORY of nodemask
+is (will be) set/clear, if this is -1, then nodemask status is not changed.
+status_change_nid is set node id when N_MEMORY of nodemask is (will be)
 set/clear. It means a new(memoryless) node gets new memory by online and a
 node loses all memory. If this is -1, then nodemask status is not changed.
 If status_changed_nid* >= 0, callback should create/discard structures for the
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index dd52d516cb89..dbca66182089 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -36,7 +36,7 @@ neigh/default/unres_qlen_bytes - INTEGER
        The maximum number of bytes which may be used by packets
        queued for each unresolved address by other network layers.
        (added in linux 3.3)
-        Seting negative value is meaningless and will retrun error.
+        Setting negative value is meaningless and will return error.
        Default: 65536 Bytes(64KB)
 neigh/default/unres_qlen - INTEGER
@@ -215,7 +215,7 @@ tcp_ecn - INTEGER
        Possible values are:
                0 Disable ECN.  Neither initiate nor accept ECN.
                1 Always request ECN on outgoing connection attempts.
-                2 Enable ECN when requested by incomming connections
+                2 Enable ECN when requested by incoming connections
                  but do not request ECN on outgoing connections.
        Default: 2
@@ -503,7 +503,7 @@ tcp_fastopen - INTEGER
 tcp_syn_retries - INTEGER
        Number of times initial SYNs for an active TCP connection attempt
        will be retransmitted. Should not be higher than 255. Default value
-        is 6, which corresponds to 63seconds till the last restransmission
+        is 6, which corresponds to 63seconds till the last retransmission
        with the current initial RTO of 1second. With this the final timeout
        for an active TCP connection attempt will happen after 127seconds.
@@ -1331,6 +1331,12 @@ force_tllao - BOOLEAN
        race condition where the sender deletes the cached link-layer address
        prior to receiving a response to a previous solicitation."
+ndisc_notify - BOOLEAN
+        Define mode for notification of address and device changes.
+        0 - (default): do nothing
+        1 - Generate unsolicited neighbour advertisements when device is brought
+            up or hardware address changes.
 icmp/*:
 ratelimit - INTEGER
        Limit the maximal rates for sending ICMPv6 packets.
@@ -1530,7 +1536,7 @@ cookie_hmac_alg - STRING
        * sha1
        * none
        Ability to assign md5 or sha1 as the selected alg is predicated on the
-        configuarion of those algorithms at build time (CONFIG_CRYPTO_MD5 and
+        configuration of those algorithms at build time (CONFIG_CRYPTO_MD5 and
        CONFIG_CRYPTO_SHA1).
        Default: Dependent on configuration.  MD5 if available, else SHA1 if
@@ -1548,7 +1554,7 @@ rcvbuf_policy - INTEGER
        blocking.
        1: rcvbuf space is per association
-        0: recbuf space is per socket
+        0: rcvbuf space is per socket
        Default: 0
diff --git a/Documentation/power/power_supply_class.txt b/Documentation/power/power_supply_class.txt
index 9c647bd7c5a9..3f10b39b0346 100644
--- a/Documentation/power/power_supply_class.txt
+++ b/Documentation/power/power_supply_class.txt
@@ -123,6 +123,9 @@ CONSTANT_CHARGE_VOLTAGE - constant charge voltage programmed by charger.
 CONSTANT_CHARGE_VOLTAGE_MAX - maximum charge voltage supported by the
 power supply object.
+CHARGE_CONTROL_LIMIT - current charge control limit setting
+CHARGE_CONTROL_LIMIT_MAX - maximum charge control limit setting
 ENERGY_FULL, ENERGY_EMPTY - same as above but for energy.
 CAPACITY - capacity in percents.
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index 4abe83e1045a..03591a750f99 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -642,12 +642,13 @@ out the following operations:
  * During system suspend it calls pm_runtime_get_noresume() and
    pm_runtime_barrier() for every device right before executing the
    subsystem-level .suspend() callback for it.  In addition to that it calls
-    pm_runtime_disable() for every device right after executing the
+    __pm_runtime_disable() with 'false' as the second argument for every device
-    subsystem-level .suspend() callback for it.
+    right before executing the subsystem-level .suspend_late() callback for it.
  * During system resume it calls pm_runtime_enable() and pm_runtime_put_sync()
-    for every device right before and right after executing the subsystem-level
+    for every device right after executing the subsystem-level .resume_early()
-    .resume() callback for it, respectively.
+    callback and right after executing the subsystem-level .resume() callback
+    for it, respectively.
 7. Generic subsystem callbacks
diff --git a/Documentation/powerpc/ptrace.txt b/Documentation/powerpc/ptrace.txt
index f4a5499b7bc6..f2a7a3919772 100644
--- a/Documentation/powerpc/ptrace.txt
+++ b/Documentation/powerpc/ptrace.txt
@@ -127,6 +127,22 @@ Some examples of using the structure to:
  p.addr2           = (uint64_t) end_range;
  p.condition_value = 0;
+- set a watchpoint in server processors (BookS)
+  p.version         = 1;
+  p.trigger_type    = PPC_BREAKPOINT_TRIGGER_RW;
+  p.addr_mode       = PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE;
+  or
+  p.addr_mode       = PPC_BREAKPOINT_MODE_EXACT;
+  p.condition_mode  = PPC_BREAKPOINT_CONDITION_NONE;
+  p.addr            = (uint64_t) begin_range;
+  /* For PPC_BREAKPOINT_MODE_RANGE_INCLUSIVE addr2 needs to be specified, where
+   * addr2 - addr <= 8 Bytes.
+   */
+  p.addr2           = (uint64_t) end_range;
+  p.condition_value = 0;
 3. PTRACE_DELHWDEBUG
 Takes an integer which identifies an existing breakpoint or watchpoint
diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt
index 597c3c581375..1e469ef75778 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -95,12 +95,15 @@ SECCOMP_RET_KILL:
 SECCOMP_RET_TRAP:
        Results in the kernel sending a SIGSYS signal to the triggering
-        task without executing the system call.  The kernel will
+        task without executing the system call.  siginfo->si_call_addr
-        rollback the register state to just before the system call
+        will show the address of the system call instruction, and
-        entry such that a signal handler in the task will be able to
+        siginfo->si_syscall and siginfo->si_arch will indicate which
-        inspect the ucontext_t->uc_mcontext registers and emulate
+        syscall was attempted.  The program counter will be as though
-        system call success or failure upon return from the signal
+        the syscall happened (i.e. it will not point to the syscall
-        handler.
+        instruction).  The return value register will contain an arch-
+        dependent value -- if resuming execution, set it to something
+        sensible.  (The architecture dependency is because replacing
+        it with -ENOSYS could overwrite some useful information.)
        The SECCOMP_RET_DATA portion of the return value will be passed
        as si_errno.
@@ -123,6 +126,18 @@ SECCOMP_RET_TRACE:
        the BPF program return value will be available to the tracer
        via PTRACE_GETEVENTMSG.
+        The tracer can skip the system call by changing the syscall number
+        to -1.  Alternatively, the tracer can change the system call
+        requested by changing the system call to a valid syscall number.  If
+        the tracer asks to skip the system call, then the system call will
+        appear to return the value that the tracer puts in the return value
+        register.
+        The seccomp check will not be run again after the tracer is
+        notified.  (This means that seccomp-based sandboxes MUST NOT
+        allow use of ptrace, even of other sandboxed processes, without
+        extreme care; ptracers can use this mechanism to escape.)
 SECCOMP_RET_ALLOW:
        Results in the system call being executed.
@@ -161,3 +176,50 @@ architecture supports both ptrace_event and seccomp, it will be able to
 support seccomp filter with minor fixup: SIGSYS support and seccomp return
 value checking.  Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER
 to its arch-specific Kconfig.
+Caveats
+-------
+The vDSO can cause some system calls to run entirely in userspace,
+leading to surprises when you run programs on different machines that
+fall back to real syscalls.  To minimize these surprises on x86, make
+sure you test with
+/sys/devices/system/clocksource/clocksource0/current_clocksource set to
+something like acpi_pm.
+On x86-64, vsyscall emulation is enabled by default.  (vsyscalls are
+legacy variants on vDSO calls.)  Currently, emulated vsyscalls will honor seccomp, with a few oddities:
+- A return value of SECCOMP_RET_TRAP will set a si_call_addr pointing to
+  the vsyscall entry for the given call and not the address after the
+  'syscall' instruction.  Any code which wants to restart the call
+  should be aware that (a) a ret instruction has been emulated and (b)
+  trying to resume the syscall will again trigger the standard vsyscall
+  emulation security checks, making resuming the syscall mostly
+  pointless.
+- A return value of SECCOMP_RET_TRACE will signal the tracer as usual,
+  but the syscall may not be changed to another system call using the
+  orig_rax register. It may only be changed to -1 order to skip the
+  currently emulated call. Any other change MAY terminate the process.
+  The rip value seen by the tracer will be the syscall entry address;
+  this is different from normal behavior.  The tracer MUST NOT modify
+  rip or rsp.  (Do not rely on other changes terminating the process.
+  They might work.  For example, on some kernels, choosing a syscall
+  that only exists in future kernels will be correctly emulated (by
+  returning -ENOSYS).
+To detect this quirky behavior, check for addr & ~0x0C00 ==
+0xFFFFFFFFFF600000.  (For SECCOMP_RET_TRACE, use rip.  For
+SECCOMP_RET_TRAP, use siginfo->si_call_addr.)  Do not check any other
+condition: future kernels may improve vsyscall emulation and current
+kernels in vsyscall=native mode will behave differently, but the
+instructions at 0xF...F600{0,4,8,C}00 will not be system calls in these
+cases.
+Note that modern systems are unlikely to use vsyscalls at all -- they
+are a legacy feature and they are considerably slower than standard
+syscalls.  New code will use the vDSO, and vDSO-issued system calls
+are indistinguishable from normal system calls.
diff --git a/Documentation/rpmsg.txt b/Documentation/rpmsg.txt
index 409d9f964c5b..f7edc3aa1e92 100644
--- a/Documentation/rpmsg.txt
+++ b/Documentation/rpmsg.txt
@@ -236,7 +236,7 @@ static int rpmsg_sample_probe(struct rpmsg_channel *rpdev)
        return 0;
 }
-static void __devexit rpmsg_sample_remove(struct rpmsg_channel *rpdev)
+static void rpmsg_sample_remove(struct rpmsg_channel *rpdev)
 {
        dev_info(&rpdev->dev, "rpmsg sample client driver is removed\n");
 }
@@ -253,7 +253,7 @@ static struct rpmsg_driver rpmsg_sample_client = {
        .id_table       = rpmsg_driver_sample_id_table,
        .probe          = rpmsg_sample_probe,
        .callback       = rpmsg_sample_cb,
-        .remove         = __devexit_p(rpmsg_sample_remove),
+        .remove         = rpmsg_sample_remove,
 };
 static int __init init(void)
diff --git a/Documentation/scsi/hptiop.txt b/Documentation/scsi/hptiop.txt
index 9605179711f4..4a4f47e759cd 100644
--- a/Documentation/scsi/hptiop.txt
+++ b/Documentation/scsi/hptiop.txt
@@ -37,7 +37,7 @@ For Intel IOP based adapters, the controller IOP is accessed via PCI BAR0:
            0x40    Inbound Queue Port
            0x44    Outbound Queue Port
-For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
+For Marvell not Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
     BAR0 offset    Register
         0x20400    Inbound Doorbell Register
@@ -55,9 +55,31 @@ For Marvell IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
     0x40-0x1040    Inbound Queue
   0x1040-0x2040    Outbound Queue
+For Marvell Frey IOP based adapters, the IOP is accessed via PCI BAR0 and BAR1:
-I/O Request Workflow
+     BAR0 offset    Register
----------------------
+             0x0    IOP configuration information.
+     BAR1 offset    Register
+          0x4000    Inbound List Base Address Low
+          0x4004    Inbound List Base Address High
+          0x4018    Inbound List Write Pointer
+          0x402C    Inbound List Configuration and Control
+          0x4050    Outbound List Base Address Low
+          0x4054    Outbound List Base Address High
+          0x4058    Outbound List Copy Pointer Shadow Base Address Low
+          0x405C    Outbound List Copy Pointer Shadow Base Address High
+          0x4088    Outbound List Interrupt Cause
+          0x408C    Outbound List Interrupt Enable
+         0x1020C    PCIe Function 0 Interrupt Enable
+         0x10400    PCIe Function 0 to CPU Message A
+         0x10420    CPU to PCIe Function 0 Message A
+         0x10480    CPU to PCIe Function 0 Doorbell
+         0x10484    CPU to PCIe Function 0 Doorbell Enable
+I/O Request Workflow of Not Marvell Frey
+------------------------------------------
 All queued requests are handled via inbound/outbound queue port.
 A request packet can be allocated in either IOP or host memory.
@@ -101,6 +123,45 @@ register 0. An outbound message with the same value indicates the completion
 of an inbound message.
+I/O Request Workflow of Marvell Frey
+--------------------------------------
+All queued requests are handled via inbound/outbound list.
+To send a request to the controller:
+    - Allocate a free request in host DMA coherent memory.
+      Requests allocated in host memory must be aligned on 32-bytes boundary.
+    - Fill the request with index of the request in the flag.
+      Fill a free inbound list unit with the physical address and the size of
+      the request.
+      Set up the inbound list write pointer with the index of previous unit,
+      round to 0 if the index reaches the supported count of requests.
+    - Post the inbound list writer pointer to IOP.
+    - The IOP process the request. When the request is completed, the flag of
+      the request with or-ed IOPMU_QUEUE_MASK_HOST_BITS will be put into a
+      free outbound list unit and the index of the outbound list unit will be
+      put into the copy pointer shadow register. An outbound interrupt will be
+      generated.
+    - The host read the outbound list copy pointer shadow register and compare
+      with previous saved read ponter N. If they are different, the host will
+      read the (N+1)th outbound list unit.
+      The host get the index of the request from the (N+1)th outbound list
+      unit and complete the request.
+Non-queued requests (reset communication/reset/flush etc) can be sent via PCIe
+Function 0 to CPU Message A register. The CPU to PCIe Function 0 Message register
+with the same value indicates the completion of message.
 User-level Interface
 ---------------------
@@ -112,7 +173,7 @@ The driver exposes following sysfs attributes:
 -----------------------------------------------------------------------------
-Copyright (C) 2006-2009 HighPoint Technologies, Inc. All Rights Reserved.
+Copyright (C) 2006-2012 HighPoint Technologies, Inc. All Rights Reserved.
  This file is distributed in the hope that it will be useful,
  but WITHOUT ANY WARRANTY; without even the implied warranty of
diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX
index eeed1de546d4..414235c1fcfc 100644
--- a/Documentation/security/00-INDEX
+++ b/Documentation/security/00-INDEX
@@ -12,6 +12,8 @@ apparmor.txt
        - documentation on the AppArmor security extension.
 credentials.txt
        - documentation about credentials in Linux.
+keys-ecryptfs.txt
+        - description of the encryption keys for the ecryptfs filesystem.
 keys-request-key.txt
        - description of the kernel key request service.
 keys-trusted-encrypted.txt
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index 7d9ca92022d8..7b4145d00452 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -994,6 +994,23 @@ payload contents" for more information.
    reference pointer if successful.
+(*) A keyring can be created by:
+        struct key *keyring_alloc(const char *description, uid_t uid, gid_t gid,
+                                  const struct cred *cred,
+                                  key_perm_t perm,
+                                  unsigned long flags,
+                                  struct key *dest);
+    This creates a keyring with the given attributes and returns it.  If dest
+    is not NULL, the new keyring will be linked into the keyring to which it
+    points.  No permission checks are made upon the destination keyring.
+    Error EDQUOT can be returned if the keyring would overload the quota (pass
+    KEY_ALLOC_NOT_IN_QUOTA in flags if the keyring shouldn't be accounted
+    towards the user's quota).  Error ENOMEM can also be returned.
 (*) To check the validity of a key, this function can be called:
        int validate_key(struct key *key);
diff --git a/Documentation/sparse.txt b/Documentation/sparse.txt
index 4909d4116356..eceab1308a8c 100644
--- a/Documentation/sparse.txt
+++ b/Documentation/sparse.txt
@@ -49,6 +49,24 @@ be generated without __CHECK_ENDIAN__.
 __bitwise - noisy stuff; in particular, __le*/__be* are that.  We really
 don't want to drown in noise unless we'd explicitly asked for it.
+Using sparse for lock checking
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+The following macros are undefined for gcc and defined during a sparse
+run to use the "context" tracking feature of sparse, applied to
+locking.  These annotations tell sparse when a lock is held, with
+regard to the annotated function's entry and exit.
+__must_hold - The specified lock is held on function entry and exit.
+__acquires - The specified lock is held on function exit, but not entry.
+__releases - The specified lock is held on function entry, but not exit.
+If the function enters and exits without the lock held, acquiring and
+releasing the lock inside the function in a balanced way, no
+annotation is needed.  The tree annotations above are for cases where
+sparse would otherwise report a context imbalance.
 Getting sparse
 ~~~~~~~~~~~~~~
diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary
index 7312ec14dd89..2331eb214146 100644
--- a/Documentation/spi/spi-summary
+++ b/Documentation/spi/spi-summary
@@ -345,7 +345,7 @@ SPI protocol drivers somewhat resemble platform device drivers:
                },
                .probe          = CHIP_probe,
-                .remove         = __devexit_p(CHIP_remove),
+                .remove         = CHIP_remove,
                .suspend        = CHIP_suspend,
                .resume         = CHIP_resume,
        };
@@ -355,7 +355,7 @@ device whose board_info gave a modalias of "CHIP".  Your probe() code
 might look like this unless you're creating a device which is managing
 a bus (appearing under /sys/class/spi_master).
-        static int __devinit CHIP_probe(struct spi_device *spi)
+        static int CHIP_probe(struct spi_device *spi)
        {
                struct CHIP                     *chip;
                struct CHIP_platform_data       *pdata;
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 2907ba6c3607..ccd42589e124 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -38,6 +38,7 @@ show up in /proc/sys/kernel:
 - l2cr                        [ PPC only ]
 - modprobe                    ==> Documentation/debugging-modules.txt
 - modules_disabled
+- msg_next_id                 [ sysv ipc ]
 - msgmax
 - msgmnb
 - msgmni
@@ -62,7 +63,9 @@ show up in /proc/sys/kernel:
 - rtsig-max
 - rtsig-nr
 - sem
+- sem_next_id                 [ sysv ipc ]
 - sg-big-buff                 [ generic SCSI device (sg) ]
+- shm_next_id                 [ sysv ipc ]
 - shm_rmid_forced
 - shmall
 - shmmax                      [ sysv ipc ]
@@ -320,6 +323,22 @@ to false.
 ==============================================================
+msg_next_id, sem_next_id, and shm_next_id:
+These three toggles allows to specify desired id for next allocated IPC
+object: message, semaphore or shared memory respectively.
+By default they are equal to -1, which means generic allocation logic.
+Possible values to set are in range {0..INT_MAX}.
+Notes:
+1) kernel doesn't guarantee, that new object will have desired id. So,
+it's up to userspace, how to handle an object with "wrong" id.
+2) Toggle with non-default value will be set back to -1 by kernel after
+successful IPC object allocation.
+==============================================================
 nmi_watchdog:
 Enables/Disables the NMI watchdog on x86 systems. When the value is
@@ -542,6 +561,19 @@ are doing anyway :)
 ==============================================================
+shmall:
+This parameter sets the total amount of shared memory pages that
+can be used system wide. Hence, SHMALL should always be at least
+ceil(shmmax/PAGE_SIZE).
+If you are not sure what the default PAGE_SIZE is on your Linux
+system, you can run the following command:
+# getconf PAGE_SIZE
+==============================================================
 shmmax:
 This value can be used to query and set the run time limit
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 32bfe926e8d7..b89567ad04b7 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -174,8 +174,7 @@ The recommended approach is as follows:
 static atomic_t drv_instance = ATOMIC_INIT(0);
-static int __devinit drv_probe(struct pci_dev *pdev,
+static int drv_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id)
-                                const struct pci_device_id *pci_id)
 {
        ...
        state->instance = atomic_inc_return(&drv_instance) - 1;
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index f6ec3a92e621..a4df5535996b 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -1194,12 +1194,15 @@ struct kvm_ppc_pvinfo {
 This ioctl fetches PV specific information that need to be passed to the guest
 using the device tree or other means from vm context.
-For now the only implemented piece of information distributed here is an array
+The hcall array defines 4 instructions that make up a hypercall.
-of 4 instructions that make up a hypercall.
 If any additional field gets added to this structure later on, a bit for that
 additional piece of information will be set in the flags bitmap.
+The flags bitmap is defined as:
+   /* the host supports the ePAPR idle hcall
+   #define KVM_PPC_PVINFO_FLAGS_EV_IDLE   (1<<0)
 4.48 KVM_ASSIGN_PCI_DEVICE
@@ -1731,7 +1734,46 @@ registers, find a list below:
  Arch  |       Register        | Width (bits)
        |                       |
  PPC   | KVM_REG_PPC_HIOR      | 64
+  PPC   | KVM_REG_PPC_IAC1      | 64
+  PPC   | KVM_REG_PPC_IAC2      | 64
+  PPC   | KVM_REG_PPC_IAC3      | 64
+  PPC   | KVM_REG_PPC_IAC4      | 64
+  PPC   | KVM_REG_PPC_DAC1      | 64
+  PPC   | KVM_REG_PPC_DAC2      | 64
+  PPC   | KVM_REG_PPC_DABR      | 64
+  PPC   | KVM_REG_PPC_DSCR      | 64
+  PPC   | KVM_REG_PPC_PURR      | 64
+  PPC   | KVM_REG_PPC_SPURR     | 64
+  PPC   | KVM_REG_PPC_DAR       | 64
+  PPC   | KVM_REG_PPC_DSISR     | 32
+  PPC   | KVM_REG_PPC_AMR       | 64
+  PPC   | KVM_REG_PPC_UAMOR     | 64
+  PPC   | KVM_REG_PPC_MMCR0     | 64
+  PPC   | KVM_REG_PPC_MMCR1     | 64
+  PPC   | KVM_REG_PPC_MMCRA     | 64
+  PPC   | KVM_REG_PPC_PMC1      | 32
+  PPC   | KVM_REG_PPC_PMC2      | 32
+  PPC   | KVM_REG_PPC_PMC3      | 32
+  PPC   | KVM_REG_PPC_PMC4      | 32
+  PPC   | KVM_REG_PPC_PMC5      | 32
+  PPC   | KVM_REG_PPC_PMC6      | 32
+  PPC   | KVM_REG_PPC_PMC7      | 32
+  PPC   | KVM_REG_PPC_PMC8      | 32
+  PPC   | KVM_REG_PPC_FPR0      | 64
+          ...
+  PPC   | KVM_REG_PPC_FPR31     | 64
+  PPC   | KVM_REG_PPC_VR0       | 128
+          ...
+  PPC   | KVM_REG_PPC_VR31      | 128
+  PPC   | KVM_REG_PPC_VSR0      | 128
+          ...
+  PPC   | KVM_REG_PPC_VSR31     | 128
+  PPC   | KVM_REG_PPC_FPSCR     | 64
+  PPC   | KVM_REG_PPC_VSCR      | 32
+  PPC   | KVM_REG_PPC_VPA_ADDR  | 64
+  PPC   | KVM_REG_PPC_VPA_SLB   | 128
+  PPC   | KVM_REG_PPC_VPA_DTL   | 128
+  PPC   | KVM_REG_PPC_EPCR      | 32
 4.69 KVM_GET_ONE_REG
@@ -1747,7 +1789,7 @@ kvm_one_reg struct passed in. On success, the register value can be found
 at the memory location pointed to by "addr".
 The list of registers accessible using this interface is identical to the
-list in 4.64.
+list in 4.68.
 4.70 KVM_KVMCLOCK_CTRL
@@ -1997,6 +2039,93 @@ return the hash table order in the parameter.  (If the guest is using
 the virtualized real-mode area (VRMA) facility, the kernel will
 re-create the VMRA HPTEs on the next KVM_RUN of any vcpu.)
+4.77 KVM_S390_INTERRUPT
+Capability: basic
+Architectures: s390
+Type: vm ioctl, vcpu ioctl
+Parameters: struct kvm_s390_interrupt (in)
+Returns: 0 on success, -1 on error
+Allows to inject an interrupt to the guest. Interrupts can be floating
+(vm ioctl) or per cpu (vcpu ioctl), depending on the interrupt type.
+Interrupt parameters are passed via kvm_s390_interrupt:
+struct kvm_s390_interrupt {
+        __u32 type;
+        __u32 parm;
+        __u64 parm64;
+};
+type can be one of the following:
+KVM_S390_SIGP_STOP (vcpu) - sigp restart
+KVM_S390_PROGRAM_INT (vcpu) - program check; code in parm
+KVM_S390_SIGP_SET_PREFIX (vcpu) - sigp set prefix; prefix address in parm
+KVM_S390_RESTART (vcpu) - restart
+KVM_S390_INT_VIRTIO (vm) - virtio external interrupt; external interrupt
+                           parameters in parm and parm64
+KVM_S390_INT_SERVICE (vm) - sclp external interrupt; sclp parameter in parm
+KVM_S390_INT_EMERGENCY (vcpu) - sigp emergency; source cpu in parm
+KVM_S390_INT_EXTERNAL_CALL (vcpu) - sigp external call; source cpu in parm
+Note that the vcpu ioctl is asynchronous to vcpu execution.
+4.78 KVM_PPC_GET_HTAB_FD
+Capability: KVM_CAP_PPC_HTAB_FD
+Architectures: powerpc
+Type: vm ioctl
+Parameters: Pointer to struct kvm_get_htab_fd (in)
+Returns: file descriptor number (>= 0) on success, -1 on error
+This returns a file descriptor that can be used either to read out the
+entries in the guest's hashed page table (HPT), or to write entries to
+initialize the HPT.  The returned fd can only be written to if the
+KVM_GET_HTAB_WRITE bit is set in the flags field of the argument, and
+can only be read if that bit is clear.  The argument struct looks like
+this:
+/* For KVM_PPC_GET_HTAB_FD */
+struct kvm_get_htab_fd {
+        __u64   flags;
+        __u64   start_index;
+        __u64   reserved[2];
+};
+/* Values for kvm_get_htab_fd.flags */
+#define KVM_GET_HTAB_BOLTED_ONLY        ((__u64)0x1)
+#define KVM_GET_HTAB_WRITE              ((__u64)0x2)
+The `start_index' field gives the index in the HPT of the entry at
+which to start reading.  It is ignored when writing.
+Reads on the fd will initially supply information about all
+"interesting" HPT entries.  Interesting entries are those with the
+bolted bit set, if the KVM_GET_HTAB_BOLTED_ONLY bit is set, otherwise
+all entries.  When the end of the HPT is reached, the read() will
+return.  If read() is called again on the fd, it will start again from
+the beginning of the HPT, but will only return HPT entries that have
+changed since they were last read.
+Data read or written is structured as a header (8 bytes) followed by a
+series of valid HPT entries (16 bytes) each.  The header indicates how
+many valid HPT entries there are and how many invalid entries follow
+the valid entries.  The invalid entries are not represented explicitly
+in the stream.  The header format is:
+struct kvm_get_htab_header {
+        __u32   index;
+        __u16   n_valid;
+        __u16   n_invalid;
+};
+Writes to the fd create HPT entries starting at the index given in the
+header; first `n_valid' valid entries with contents from the data
+written, then `n_invalid' invalid entries, invalidating any previously
+valid entries found.
 5. The kvm_run structure
 ------------------------
@@ -2109,7 +2238,8 @@ executed a memory-mapped I/O instruction which could not be satisfied
 by kvm.  The 'data' member contains the written data if 'is_write' is
 true, and should be filled by application code otherwise.
-NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO and KVM_EXIT_OSI, the corresponding
+NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR
+      and KVM_EXIT_PAPR the corresponding
 operations are complete (and guest state is consistent) only after userspace
 has re-entered the kernel with KVM_RUN.  The kernel side will first finish
 incomplete operations and then check for pending signals.  Userspace
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index f734bb2a78dc..8785fb87d9c7 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -116,6 +116,13 @@ echo always >/sys/kernel/mm/transparent_hugepage/defrag
 echo madvise >/sys/kernel/mm/transparent_hugepage/defrag
 echo never >/sys/kernel/mm/transparent_hugepage/defrag
+By default kernel tries to use huge zero page on read page fault.
+It's possible to disable huge zero page by writing 0 or enable it
+back by writing 1:
+echo 0 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page
+echo 1 >/sys/kernel/mm/transparent_hugepage/khugepaged/use_zero_page
 khugepaged will be automatically started when
 transparent_hugepage/enabled is set to "always" or "madvise, and it'll
 be automatically shutdown if it's set to "never".
@@ -197,6 +204,14 @@ thp_split is incremented every time a huge page is split into base
        pages. This can happen for a variety of reasons but a common
        reason is that a huge page is old and is being reclaimed.
+thp_zero_page_alloc is incremented every time a huge zero page is
+        successfully allocated. It includes allocations which where
+        dropped due race with other allocation. Note, it doesn't count
+        every map of the huge zero page, only its allocation.
+thp_zero_page_alloc_failed is incremented if kernel fails to allocate
+        huge zero page and falls back to using small pages.
 As the system ages, allocating huge pages may be expensive as the
 system uses memory compaction to copy data around memory to free a
 huge page for use. There are some counters in /proc/vmstat to help
@@ -276,7 +291,7 @@ unaffected. libhugetlbfs will also work fine as usual.
 == Graceful fallback ==
 Code walking pagetables but unware about huge pmds can simply call
-split_huge_page_pmd(mm, pmd) where the pmd is the one returned by
+split_huge_page_pmd(vma, addr, pmd) where the pmd is the one returned by
 pmd_offset. It's trivial to make the code transparent hugepage aware
 by just grepping for "pmd_offset" and adding split_huge_page_pmd where
 missing after pmd_offset returns the pmd. Thanks to the graceful
@@ -299,7 +314,7 @@ diff --git a/mm/mremap.c b/mm/mremap.c
                return NULL;
        pmd = pmd_offset(pud, addr);
-+       split_huge_page_pmd(mm, pmd);
+       split_huge_page_pmd(vma, addr, pmd);
        if (pmd_none_or_clear_bad(pmd))
                return NULL;
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index f15cb74c4f78..3edb4c2887a1 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -57,6 +57,10 @@ Protocol 2.10:	(Kernel 2.6.31) Added a protocol for relaxed alignment
 Protocol 2.11:  (Kernel 3.6) Added a field for offset of EFI handover
                protocol entry point.
+Protocol 2.12:  (Kernel 3.9) Added the xloadflags field and extension fields
+                to struct boot_params for for loading bzImage and ramdisk
+                above 4G in 64bit.
 **** MEMORY LAYOUT
 The traditional memory map for the kernel loader, used for Image or
@@ -182,7 +186,7 @@ Offset	Proto	Name		Meaning
 0230/4  2.05+   kernel_alignment Physical addr alignment required for kernel
 0234/1  2.05+   relocatable_kernel Whether kernel is relocatable or not
 0235/1  2.10+   min_alignment   Minimum alignment, as a power of two
-0236/2  N/A     pad3            Unused
+0236/2  2.12+   xloadflags      Boot protocol option flags
 0238/4  2.06+   cmdline_size    Maximum size of the kernel command line
 023C/4  2.07+   hardware_subarch Hardware subarchitecture
 0240/8  2.07+   hardware_subarch_data Subarchitecture-specific data
@@ -373,7 +377,7 @@ Protocol:	2.00+
        1  Loadlin
        2  bootsect-loader      (0x20, all other values reserved)
        3  Syslinux
-        4  Etherboot/gPXE
+        4  Etherboot/gPXE/iPXE
        5  ELILO
        7  GRUB
        8  U-Boot
@@ -381,6 +385,7 @@ Protocol:	2.00+
        A  Gujin
        B  Qemu
        C  Arcturus Networks uCbootloader
+        D  kexec-tools
        E  Extended             (see ext_loader_type)
        F  Special              (0xFF = undefined)
       10  Reserved
@@ -581,6 +586,27 @@ Protocol:	2.10+
  misaligned kernel.  Therefore, a loader should typically try each
  power-of-two alignment from kernel_alignment down to this alignment.
+Field name:     xloadflags
+Type:           read
+Offset/size:    0x236/2
+Protocol:       2.12+
+  This field is a bitmask.
+  Bit 0 (read): XLF_KERNEL_64
+        - If 1, this kernel has the legacy 64-bit entry point at 0x200.
+  Bit 1 (read): XLF_CAN_BE_LOADED_ABOVE_4G
+        - If 1, kernel/boot_params/cmdline/ramdisk can be above 4G.
+  Bit 2 (read): XLF_EFI_HANDOVER_32
+        - If 1, the kernel supports the 32-bit EFI handoff entry point
+          given at handover_offset.
+  Bit 3 (read): XLF_EFI_HANDOVER_64
+        - If 1, the kernel supports the 64-bit EFI handoff entry point
+          given at handover_offset + 0x200.
 Field name:     cmdline_size
 Type:           read
 Offset/size:    0x238/4
diff --git a/Documentation/x86/zero-page.txt b/Documentation/x86/zero-page.txt
index cf5437deda81..199f453cb4de 100644
--- a/Documentation/x86/zero-page.txt
+++ b/Documentation/x86/zero-page.txt
@@ -19,6 +19,9 @@ Offset	Proto	Name		Meaning
 090/010 ALL     hd1_info        hd1 disk parameter, OBSOLETE!!
 0A0/010 ALL     sys_desc_table  System description table (struct sys_desc_table)
 0B0/010 ALL     olpc_ofw_header OLPC's OpenFirmware CIF and friends
+0C0/004 ALL     ext_ramdisk_image ramdisk_image high 32bits
+0C4/004 ALL     ext_ramdisk_size  ramdisk_size high 32bits
+0C8/004 ALL     ext_cmd_line_ptr  cmd_line_ptr high 32bits
 140/080 ALL     edid_info       Video mode setup (struct edid_info)
 1C0/020 ALL     efi_info        EFI 32 information (struct efi_info)
 1E0/004 ALL     alk_mem_k       Alternative mem check, in KB
@@ -27,6 +30,7 @@ Offset	Proto	Name		Meaning
 1E9/001 ALL     eddbuf_entries  Number of entries in eddbuf (below)
 1EA/001 ALL     edd_mbr_sig_buf_entries Number of entries in edd_mbr_sig_buffer
                                (below)
+1EF/001 ALL     sentinel        Used to detect broken bootloaders
 290/040 ALL     edd_mbr_sig_buffer EDD MBR signatures
 2D0/A00 ALL     e820_map        E820 memory map table
                                (array of struct e820entry)
diff --git a/Documentation/xtensa/atomctl.txt b/Documentation/xtensa/atomctl.txt
new file mode 100644
index 000000000000..10a8d1ff35ec
--- /dev/null
+++ b/Documentation/xtensa/atomctl.txt
@@ -0,0 +1,44 @@
+We Have Atomic Operation Control (ATOMCTL) Register.
+This register determines the effect of using a S32C1I instruction
+with various combinations of:
+     1. With and without an Coherent Cache Controller which
+        can do Atomic Transactions to the memory internally.
+     2. With and without An Intelligent Memory Controller which
+        can do Atomic Transactions itself.
+The Core comes up with a default value of for the three types of cache ops:
+      0x28: (WB: Internal, WT: Internal, BY:Exception)
+On the FPGA Cards we typically simulate an Intelligent Memory controller
+which can implement  RCW transactions. For FPGA cards with an External
+Memory controller we let it to the atomic operations internally while
+doing a Cached (WB) transaction and use the Memory RCW for un-cached
+operations.
+For systems without an coherent cache controller, non-MX, we always
+use the memory controllers RCW, thought non-MX controlers likely
+support the Internal Operation.
+CUSTOMER-WARNING:
+   Virtually all customers buy their memory controllers from vendors that
+   don't support atomic RCW memory transactions and will likely want to
+   configure this register to not use RCW.
+Developers might find using RCW in Bypass mode convenient when testing
+with the cache being bypassed; for example studying cache alias problems.
+See Section 4.3.12.4 of ISA; Bits:
+                             WB     WT      BY
+                           5   4 | 3   2 | 1   0
+  2 Bit
+  Field
+  Values     WB - Write Back         WT - Write Thru         BY - Bypass
+---------    ---------------         -----------------     ----------------
+    0        Exception               Exception               Exception
+    1        RCW Transaction         RCW Transaction         RCW Transaction
+    2        Internal Operation      Exception               Reserved
+    3        Reserved                Reserved                Reserved
diff --git a/Documentation/zh_CN/video4linux/v4l2-framework.txt b/Documentation/zh_CN/video4linux/v4l2-framework.txt
index 3e74f13af426..44c1d934c4e3 100644
--- a/Documentation/zh_CN/video4linux/v4l2-framework.txt
+++ b/Documentation/zh_CN/video4linux/v4l2-framework.txt
@@ -182,8 +182,7 @@ int iterate(void *p)
 static atomic_t drv_instance = ATOMIC_INIT(0);
-static int __devinit drv_probe(struct pci_dev *pdev,
+static int drv_probe(struct pci_dev *pdev, const struct pci_device_id *pci_id)
-                                const struct pci_device_id *pci_id)
 {
        ...
        state->instance = atomic_inc_return(&drv_instance) - 1;