376 files changed, 12213 insertions, 2868 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 07de7e19b4ce..27e67a98b7be 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -413,8 +413,6 @@ serial-console.txt
         - how to set up Linux with a serial line console as the default.
 sgi-ioc4.txt
         - description of the SGI IOC4 PCI (multi function) device.
-sgi-visws.txt
-        - short blurb on the SGI Visual Workstations.
 sh/
         - directory with info on porting Linux to a new architecture.
 smsc_ece1099.txt
diff --git a/Documentation/ABI/stable/sysfs-firmware-opal-dump b/Documentation/ABI/stable/sysfs-firmware-opal-dump
new file mode 100644
index 000000000000..32fe7f5c4880
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-firmware-opal-dump
@@ -0,0 +1,41 @@
+What:           /sys/firmware/opal/dump
+Date:           Feb 2014
+Contact:        Stewart Smith <stewart@linux.vnet.ibm.com>
+Description:
+                This directory exposes interfaces for interacting with
+                the FSP and platform dumps through OPAL firmware interface.
+
+                This is only for the powerpc/powernv platform.
+
+                initiate_dump:  When '1' is written to it,
+                                we will initiate a dump.
+                                Read this file for supported commands.
+
+                0xXX-0xYYYY:    A directory for dump of type 0xXX and
+                                id 0xYYYY (in hex). The name of this
+                                directory should not be relied upon to
+                                be in this format, only that it's unique
+                                among all dumps. For determining the type
+                                and ID of the dump, use the id and type files.
+                                Do not rely on any particular size of dump
+                                type or dump id.
+
+                Each dump has the following files:
+                id:             An ASCII representation of the dump ID
+                                in hex (e.g. '0x01')
+                type:           An ASCII representation of the type of
+                                dump in the format "0x%x %s" with the ID
+                                in hex and a description of the dump type
+                                (or 'unknown').
+                                Type '0xffffffff unknown' is used when
+                                we could not get the type from firmware.
+                                e.g. '0x02 System/Platform Dump'
+                dump:           A binary file containing the dump.
+                                The size of the dump is the size of this file.
+                acknowledge:    When 'ack' is written to this, we will
+                                acknowledge that we've retrieved the
+                                dump to the service processor. It will
+                                then remove it, making the dump
+                                inaccessible.
+                                Reading this file will get a list of
+                                supported actions.
diff --git a/Documentation/ABI/stable/sysfs-firmware-opal-elog b/Documentation/ABI/stable/sysfs-firmware-opal-elog
new file mode 100644
index 000000000000..e1f3058f5954
--- /dev/null
+++ b/Documentation/ABI/stable/sysfs-firmware-opal-elog
@@ -0,0 +1,60 @@
+What:           /sys/firmware/opal/elog
+Date:           Feb 2014
+Contact:        Stewart Smith <stewart@linux.vnet.ibm.com>
+Description:
+                This directory exposes error log entries retrieved
+                through the OPAL firmware interface.
+
+                Each error log is identified by a unique ID and will
+                exist until explicitly acknowledged to firmware.
+
+                Each log entry has a directory in /sys/firmware/opal/elog.
+
+                Log entries may be purged by the service processor
+                before retrieved by firmware or retrieved/acknowledged by
+                Linux if there is no room for more log entries.
+
+                In the event that Linux has retrieved the log entries
+                but not explicitly acknowledged them to firmware and
+                the service processor needs more room for log entries,
+                the only remaining copy of a log message may be in
+                Linux.
+
+                Typically, a user space daemon will monitor for new
+                entries, read them out and acknowledge them.
+
+                The service processor may be able to store more log
+                entries than firmware can, so after you acknowledge
+                an event from Linux you may instantly get another one
+                from the queue that was generated some time in the past.
+
+                The raw log format is a binary format. We currently
+                do not parse this at all in kernel, leaving it up to
+                user space to solve the problem. In future, we may
+                do more parsing in kernel and add more files to make
+                it easier for simple user space processes to extract
+                more information.
+
+                For each log entry (directory), there are the following
+                files:
+
+                id:             An ASCII representation of the ID of the
+                                error log, in hex - e.g. "0x01".
+
+                type:           An ASCII representation of the type id and
+                                description of the type of error log.
+                                Currently just "0x00 PEL" - platform error log.
+                                In the future there may be additional types.
+
+                raw:            A read-only binary file that can be read
+                                to get the raw log entry. These are
+                                <16kb, often just hundreds of bytes and
+                                "average" 2kb.
+
+                acknowledge:    Writing 'ack' to this file will acknowledge
+                                the error log to firmware (and in turn
+                                the service processor, if applicable).
+                                Shortly after acknowledging it, the log
+                                entry will be removed from sysfs.
+                                Reading this file will list the supported
+                                operations (curently just acknowledge).
\ No newline at end of file
diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram
index 3f0b9ae61d8c..70ec992514d0 100644
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -43,6 +43,36 @@ Description:
                 The invalid_io file is read-only and specifies the number of
                 non-page-size-aligned I/O requests issued to this device.
 
+What:           /sys/block/zram<id>/failed_reads
+Date:           February 2014
+Contact:        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Description:
+                The failed_reads file is read-only and specifies the number of
+                failed reads happened on this device.
+
+What:           /sys/block/zram<id>/failed_writes
+Date:           February 2014
+Contact:        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Description:
+                The failed_writes file is read-only and specifies the number of
+                failed writes happened on this device.
+
+What:           /sys/block/zram<id>/max_comp_streams
+Date:           February 2014
+Contact:        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Description:
+                The max_comp_streams file is read-write and specifies the
+                number of backend's zcomp_strm compression streams (number of
+                concurrent compress operations).
+
+What:           /sys/block/zram<id>/comp_algorithm
+Date:           February 2014
+Contact:        Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
+Description:
+                The comp_algorithm file is read-write and lets to show
+                available and selected compression algorithms, change
+                compression algorithm selection.
+
 What:           /sys/block/zram<id>/notify_free
 Date:           August 2010
 Contact:        Nitin Gupta <ngupta@vflare.org>
@@ -53,15 +83,6 @@ Description:
                 is freed. This statistic is applicable only when this disk is
                 being used as a swap disk.
 
-What:           /sys/block/zram<id>/discard
-Date:           August 2010
-Contact:        Nitin Gupta <ngupta@vflare.org>
-Description:
-                The discard file is read-only and specifies the number of
-                discard requests received by this device. These requests
-                provide information to block device regarding blocks which are
-                no longer used by filesystem.
-
 What:           /sys/block/zram<id>/zero_pages
 Date:           August 2010
 Contact:        Nitin Gupta <ngupta@vflare.org>
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
index 3c1cc24361bd..7b40a3cbc26a 100644
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -57,6 +57,523 @@ What: 		/sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
                 /sys/devices/cpu/events/PM_LD_REF_L1
                 /sys/devices/cpu/events/PM_RUN_CYC
                 /sys/devices/cpu/events/PM_RUN_INST_CMPL
+                /sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_ALL
+                /sys/devices/cpu/events/PM_GCT_UTIL_7_TO_10_SLOTS
+                /sys/devices/cpu/events/PM_PMC2_SAVED
+                /sys/devices/cpu/events/PM_VSU0_16FLOP
+                /sys/devices/cpu/events/PM_MRK_LSU_DERAT_MISS
+                /sys/devices/cpu/events/PM_MRK_ST_CMPL
+                /sys/devices/cpu/events/PM_NEST_PAIR3_ADD
+                /sys/devices/cpu/events/PM_L2_ST_DISP
+                /sys/devices/cpu/events/PM_L2_CASTOUT_MOD
+                /sys/devices/cpu/events/PM_ISEG
+                /sys/devices/cpu/events/PM_MRK_INST_TIMEO
+                /sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_ADDR
+                /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM
+                /sys/devices/cpu/events/PM_IERAT_WR_64K
+                /sys/devices/cpu/events/PM_MRK_DTLB_MISS_16M
+                /sys/devices/cpu/events/PM_IERAT_MISS
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_LMEM
+                /sys/devices/cpu/events/PM_FLOP
+                /sys/devices/cpu/events/PM_THRD_PRIO_4_5_CYC
+                /sys/devices/cpu/events/PM_BR_PRED_TA
+                /sys/devices/cpu/events/PM_EXT_INT
+                /sys/devices/cpu/events/PM_VSU_FSQRT_FDIV
+                /sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC
+                /sys/devices/cpu/events/PM_LSU1_LDF
+                /sys/devices/cpu/events/PM_IC_WRITE_ALL
+                /sys/devices/cpu/events/PM_LSU0_SRQ_STFWD
+                /sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_MOD
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_DATA_FROM_L21_MOD
+                /sys/devices/cpu/events/PM_VSU1_SCAL_DOUBLE_ISSUED
+                /sys/devices/cpu/events/PM_VSU0_8FLOP
+                /sys/devices/cpu/events/PM_POWER_EVENT1
+                /sys/devices/cpu/events/PM_DISP_CLB_HELD_BAL
+                /sys/devices/cpu/events/PM_VSU1_2FLOP
+                /sys/devices/cpu/events/PM_LWSYNC_HELD
+                /sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_SHR
+                /sys/devices/cpu/events/PM_INST_FROM_L21_MOD
+                /sys/devices/cpu/events/PM_IERAT_XLATE_WR_16MPLUS
+                /sys/devices/cpu/events/PM_IC_REQ_ALL
+                /sys/devices/cpu/events/PM_DSLB_MISS
+                /sys/devices/cpu/events/PM_L3_MISS
+                /sys/devices/cpu/events/PM_LSU0_L1_PREF
+                /sys/devices/cpu/events/PM_VSU_SCALAR_SINGLE_ISSUED
+                /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_CONFIRM_STRIDE
+                /sys/devices/cpu/events/PM_L2_INST
+                /sys/devices/cpu/events/PM_VSU0_FRSP
+                /sys/devices/cpu/events/PM_FLUSH_DISP
+                /sys/devices/cpu/events/PM_PTEG_FROM_L2MISS
+                /sys/devices/cpu/events/PM_VSU1_DQ_ISSUED
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM
+                /sys/devices/cpu/events/PM_LSU_FLUSH_ULD
+                /sys/devices/cpu/events/PM_PTEG_FROM_LMEM
+                /sys/devices/cpu/events/PM_MRK_DERAT_MISS_16M
+                /sys/devices/cpu/events/PM_THRD_ALL_RUN_CYC
+                /sys/devices/cpu/events/PM_MEM0_PREFETCH_DISP
+                /sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC_COUNT
+                /sys/devices/cpu/events/PM_DATA_FROM_DL2L3_MOD
+                /sys/devices/cpu/events/PM_VSU_FRSP
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD
+                /sys/devices/cpu/events/PM_PMC1_OVERFLOW
+                /sys/devices/cpu/events/PM_VSU0_SINGLE
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3MISS
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_VSU0_VECTOR_SP_ISSUED
+                /sys/devices/cpu/events/PM_VSU1_FEST
+                /sys/devices/cpu/events/PM_MRK_INST_DISP
+                /sys/devices/cpu/events/PM_VSU0_COMPLEX_ISSUED
+                /sys/devices/cpu/events/PM_LSU1_FLUSH_UST
+                /sys/devices/cpu/events/PM_FXU_IDLE
+                /sys/devices/cpu/events/PM_LSU0_FLUSH_ULD
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD
+                /sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_ALL_CYC
+                /sys/devices/cpu/events/PM_LSU1_REJECT_LMQ_FULL
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_MOD
+                /sys/devices/cpu/events/PM_INST_FROM_RL2L3_MOD
+                /sys/devices/cpu/events/PM_SHL_CREATED
+                /sys/devices/cpu/events/PM_L2_ST_HIT
+                /sys/devices/cpu/events/PM_DATA_FROM_DMEM
+                /sys/devices/cpu/events/PM_L3_LD_MISS
+                /sys/devices/cpu/events/PM_FXU1_BUSY_FXU0_IDLE
+                /sys/devices/cpu/events/PM_DISP_CLB_HELD_RES
+                /sys/devices/cpu/events/PM_L2_SN_SX_I_DONE
+                /sys/devices/cpu/events/PM_STCX_CMPL
+                /sys/devices/cpu/events/PM_VSU0_2FLOP
+                /sys/devices/cpu/events/PM_L3_PREF_MISS
+                /sys/devices/cpu/events/PM_LSU_SRQ_SYNC_CYC
+                /sys/devices/cpu/events/PM_LSU_REJECT_ERAT_MISS
+                /sys/devices/cpu/events/PM_L1_ICACHE_MISS
+                /sys/devices/cpu/events/PM_LSU1_FLUSH_SRQ
+                /sys/devices/cpu/events/PM_LD_REF_L1_LSU0
+                /sys/devices/cpu/events/PM_VSU0_FEST
+                /sys/devices/cpu/events/PM_VSU_VECTOR_SINGLE_ISSUED
+                /sys/devices/cpu/events/PM_FREQ_UP
+                /sys/devices/cpu/events/PM_DATA_FROM_LMEM
+                /sys/devices/cpu/events/PM_LSU1_LDX
+                /sys/devices/cpu/events/PM_PMC3_OVERFLOW
+                /sys/devices/cpu/events/PM_MRK_BR_MPRED
+                /sys/devices/cpu/events/PM_SHL_MATCH
+                /sys/devices/cpu/events/PM_MRK_BR_TAKEN
+                /sys/devices/cpu/events/PM_ISLB_MISS
+                /sys/devices/cpu/events/PM_DISP_HELD_THERMAL
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_SHR
+                /sys/devices/cpu/events/PM_LSU1_SRQ_STFWD
+                /sys/devices/cpu/events/PM_PTEG_FROM_DMEM
+                /sys/devices/cpu/events/PM_VSU_2FLOP
+                /sys/devices/cpu/events/PM_GCT_FULL_CYC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L3_CYC
+                /sys/devices/cpu/events/PM_LSU_SRQ_S0_ALLOC
+                /sys/devices/cpu/events/PM_MRK_DERAT_MISS_4K
+                /sys/devices/cpu/events/PM_BR_MPRED_TA
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L2MISS
+                /sys/devices/cpu/events/PM_DPU_HELD_POWER
+                /sys/devices/cpu/events/PM_MRK_VSU_FIN
+                /sys/devices/cpu/events/PM_LSU_SRQ_S0_VALID
+                /sys/devices/cpu/events/PM_GCT_EMPTY_CYC
+                /sys/devices/cpu/events/PM_IOPS_DISP
+                /sys/devices/cpu/events/PM_RUN_SPURR
+                /sys/devices/cpu/events/PM_PTEG_FROM_L21_MOD
+                /sys/devices/cpu/events/PM_VSU0_1FLOP
+                /sys/devices/cpu/events/PM_SNOOP_TLBIE
+                /sys/devices/cpu/events/PM_DATA_FROM_L3MISS
+                /sys/devices/cpu/events/PM_VSU_SINGLE
+                /sys/devices/cpu/events/PM_DTLB_MISS_16G
+                /sys/devices/cpu/events/PM_FLUSH
+                /sys/devices/cpu/events/PM_L2_LD_HIT
+                /sys/devices/cpu/events/PM_NEST_PAIR2_AND
+                /sys/devices/cpu/events/PM_VSU1_1FLOP
+                /sys/devices/cpu/events/PM_IC_PREF_REQ
+                /sys/devices/cpu/events/PM_L3_LD_HIT
+                /sys/devices/cpu/events/PM_DISP_HELD
+                /sys/devices/cpu/events/PM_L2_LD
+                /sys/devices/cpu/events/PM_LSU_FLUSH_SRQ
+                /sys/devices/cpu/events/PM_BC_PLUS_8_CONV
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD_CYC
+                /sys/devices/cpu/events/PM_L2_RCST_BUSY_RC_FULL
+                /sys/devices/cpu/events/PM_TB_BIT_TRANS
+                /sys/devices/cpu/events/PM_THERMAL_MAX
+                /sys/devices/cpu/events/PM_LSU1_FLUSH_ULD
+                /sys/devices/cpu/events/PM_LSU1_REJECT_LHS
+                /sys/devices/cpu/events/PM_LSU_LRQ_S0_ALLOC
+                /sys/devices/cpu/events/PM_L3_CO_L31
+                /sys/devices/cpu/events/PM_POWER_EVENT4
+                /sys/devices/cpu/events/PM_DATA_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_BR_UNCOND
+                /sys/devices/cpu/events/PM_LSU1_DC_PREF_STREAM_ALLOC
+                /sys/devices/cpu/events/PM_PMC4_REWIND
+                /sys/devices/cpu/events/PM_L2_RCLD_DISP
+                /sys/devices/cpu/events/PM_THRD_PRIO_2_3_CYC
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2MISS
+                /sys/devices/cpu/events/PM_IC_DEMAND_L2_BHT_REDIRECT
+                /sys/devices/cpu/events/PM_DATA_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_IC_PREF_CANCEL_L2
+                /sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC_COUNT
+                /sys/devices/cpu/events/PM_BR_PRED_CCACHE
+                /sys/devices/cpu/events/PM_GCT_UTIL_1_TO_2_SLOTS
+                /sys/devices/cpu/events/PM_MRK_ST_CMPL_INT
+                /sys/devices/cpu/events/PM_LSU_TWO_TABLEWALK_CYC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L3MISS
+                /sys/devices/cpu/events/PM_LSU_SET_MPRED
+                /sys/devices/cpu/events/PM_FLUSH_DISP_TLBIE
+                /sys/devices/cpu/events/PM_VSU1_FCONV
+                /sys/devices/cpu/events/PM_DERAT_MISS_16G
+                /sys/devices/cpu/events/PM_INST_FROM_LMEM
+                /sys/devices/cpu/events/PM_IC_DEMAND_L2_BR_REDIRECT
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L2
+                /sys/devices/cpu/events/PM_PTEG_FROM_L2
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR_CYC
+                /sys/devices/cpu/events/PM_MRK_DTLB_MISS_4K
+                /sys/devices/cpu/events/PM_VSU0_FPSCR
+                /sys/devices/cpu/events/PM_VSU1_VECT_DOUBLE_ISSUED
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_MOD
+                /sys/devices/cpu/events/PM_MEM0_RQ_DISP
+                /sys/devices/cpu/events/PM_L2_LD_MISS
+                /sys/devices/cpu/events/PM_VMX_RESULT_SAT_1
+                /sys/devices/cpu/events/PM_L1_PREF
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM_CYC
+                /sys/devices/cpu/events/PM_GRP_IC_MISS_NONSPEC
+                /sys/devices/cpu/events/PM_PB_NODE_PUMP
+                /sys/devices/cpu/events/PM_SHL_MERGED
+                /sys/devices/cpu/events/PM_NEST_PAIR1_ADD
+                /sys/devices/cpu/events/PM_DATA_FROM_L3
+                /sys/devices/cpu/events/PM_LSU_FLUSH
+                /sys/devices/cpu/events/PM_LSU_SRQ_SYNC_COUNT
+                /sys/devices/cpu/events/PM_PMC2_OVERFLOW
+                /sys/devices/cpu/events/PM_LSU_LDF
+                /sys/devices/cpu/events/PM_POWER_EVENT3
+                /sys/devices/cpu/events/PM_DISP_WT
+                /sys/devices/cpu/events/PM_IC_BANK_CONFLICT
+                /sys/devices/cpu/events/PM_BR_MPRED_CR_TA
+                /sys/devices/cpu/events/PM_L2_INST_MISS
+                /sys/devices/cpu/events/PM_NEST_PAIR2_ADD
+                /sys/devices/cpu/events/PM_MRK_LSU_FLUSH
+                /sys/devices/cpu/events/PM_L2_LDST
+                /sys/devices/cpu/events/PM_INST_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_VSU0_FIN
+                /sys/devices/cpu/events/PM_VSU1_FCONV
+                /sys/devices/cpu/events/PM_INST_FROM_RMEM
+                /sys/devices/cpu/events/PM_DISP_CLB_HELD_TLBIE
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_DMEM_CYC
+                /sys/devices/cpu/events/PM_BR_PRED_CR
+                /sys/devices/cpu/events/PM_LSU_REJECT
+                /sys/devices/cpu/events/PM_GCT_UTIL_3_TO_6_SLOTS
+                /sys/devices/cpu/events/PM_CMPLU_STALL_END_GCT_NOSLOT
+                /sys/devices/cpu/events/PM_LSU0_REJECT_LMQ_FULL
+                /sys/devices/cpu/events/PM_VSU_FEST
+                /sys/devices/cpu/events/PM_NEST_PAIR0_AND
+                /sys/devices/cpu/events/PM_PTEG_FROM_L3
+                /sys/devices/cpu/events/PM_POWER_EVENT2
+                /sys/devices/cpu/events/PM_IC_PREF_CANCEL_PAGE
+                /sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV
+                /sys/devices/cpu/events/PM_MRK_GRP_CMPL
+                /sys/devices/cpu/events/PM_VSU0_SCAL_DOUBLE_ISSUED
+                /sys/devices/cpu/events/PM_GRP_DISP
+                /sys/devices/cpu/events/PM_LSU0_LDX
+                /sys/devices/cpu/events/PM_DATA_FROM_L2
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD
+                /sys/devices/cpu/events/PM_VSU0_VECT_DOUBLE_ISSUED
+                /sys/devices/cpu/events/PM_VSU1_2FLOP_DOUBLE
+                /sys/devices/cpu/events/PM_THRD_PRIO_6_7_CYC
+                /sys/devices/cpu/events/PM_BC_PLUS_8_RSLV_TAKEN
+                /sys/devices/cpu/events/PM_BR_MPRED_CR
+                /sys/devices/cpu/events/PM_L3_CO_MEM
+                /sys/devices/cpu/events/PM_DATA_FROM_RL2L3_MOD
+                /sys/devices/cpu/events/PM_LSU_SRQ_FULL_CYC
+                /sys/devices/cpu/events/PM_TABLEWALK_CYC
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_RMEM
+                /sys/devices/cpu/events/PM_LSU_SRQ_STFWD
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_RMEM
+                /sys/devices/cpu/events/PM_FXU0_FIN
+                /sys/devices/cpu/events/PM_LSU1_L1_SW_PREF
+                /sys/devices/cpu/events/PM_PTEG_FROM_L31_MOD
+                /sys/devices/cpu/events/PM_PMC5_OVERFLOW
+                /sys/devices/cpu/events/PM_LD_REF_L1_LSU1
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L21_SHR
+                /sys/devices/cpu/events/PM_DATA_FROM_RMEM
+                /sys/devices/cpu/events/PM_VSU0_SCAL_SINGLE_ISSUED
+                /sys/devices/cpu/events/PM_BR_MPRED_LSTACK
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_MOD_CYC
+                /sys/devices/cpu/events/PM_LSU0_FLUSH_UST
+                /sys/devices/cpu/events/PM_LSU_NCST
+                /sys/devices/cpu/events/PM_BR_TAKEN
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_LMEM
+                /sys/devices/cpu/events/PM_DTLB_MISS_4K
+                /sys/devices/cpu/events/PM_PMC4_SAVED
+                /sys/devices/cpu/events/PM_VSU1_PERMUTE_ISSUED
+                /sys/devices/cpu/events/PM_SLB_MISS
+                /sys/devices/cpu/events/PM_LSU1_FLUSH_LRQ
+                /sys/devices/cpu/events/PM_DTLB_MISS
+                /sys/devices/cpu/events/PM_VSU1_FRSP
+                /sys/devices/cpu/events/PM_VSU_VECTOR_DOUBLE_ISSUED
+                /sys/devices/cpu/events/PM_L2_CASTOUT_SHR
+                /sys/devices/cpu/events/PM_DATA_FROM_DL2L3_SHR
+                /sys/devices/cpu/events/PM_VSU1_STF
+                /sys/devices/cpu/events/PM_ST_FIN
+                /sys/devices/cpu/events/PM_PTEG_FROM_L21_SHR
+                /sys/devices/cpu/events/PM_L2_LOC_GUESS_WRONG
+                /sys/devices/cpu/events/PM_MRK_STCX_FAIL
+                /sys/devices/cpu/events/PM_LSU0_REJECT_LHS
+                /sys/devices/cpu/events/PM_IC_PREF_CANCEL_HIT
+                /sys/devices/cpu/events/PM_L3_PREF_BUSY
+                /sys/devices/cpu/events/PM_MRK_BRU_FIN
+                /sys/devices/cpu/events/PM_LSU1_NCLD
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_MOD
+                /sys/devices/cpu/events/PM_LSU_NCLD
+                /sys/devices/cpu/events/PM_LSU_LDX
+                /sys/devices/cpu/events/PM_L2_LOC_GUESS_CORRECT
+                /sys/devices/cpu/events/PM_THRESH_TIMEO
+                /sys/devices/cpu/events/PM_L3_PREF_ST
+                /sys/devices/cpu/events/PM_DISP_CLB_HELD_SYNC
+                /sys/devices/cpu/events/PM_VSU_SIMPLE_ISSUED
+                /sys/devices/cpu/events/PM_VSU1_SINGLE
+                /sys/devices/cpu/events/PM_DATA_TABLEWALK_CYC
+                /sys/devices/cpu/events/PM_L2_RC_ST_DONE
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_MOD
+                /sys/devices/cpu/events/PM_LARX_LSU1
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM
+                /sys/devices/cpu/events/PM_DISP_CLB_HELD
+                /sys/devices/cpu/events/PM_DERAT_MISS_4K
+                /sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_ADDR
+                /sys/devices/cpu/events/PM_SEG_EXCEPTION
+                /sys/devices/cpu/events/PM_FLUSH_DISP_SB
+                /sys/devices/cpu/events/PM_L2_DC_INV
+                /sys/devices/cpu/events/PM_PTEG_FROM_DL2L3_MOD
+                /sys/devices/cpu/events/PM_DSEG
+                /sys/devices/cpu/events/PM_BR_PRED_LSTACK
+                /sys/devices/cpu/events/PM_VSU0_STF
+                /sys/devices/cpu/events/PM_LSU_FX_FIN
+                /sys/devices/cpu/events/PM_DERAT_MISS_16M
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_MOD
+                /sys/devices/cpu/events/PM_GCT_UTIL_11_PLUS_SLOTS
+                /sys/devices/cpu/events/PM_INST_FROM_L3
+                /sys/devices/cpu/events/PM_MRK_IFU_FIN
+                /sys/devices/cpu/events/PM_ITLB_MISS
+                /sys/devices/cpu/events/PM_VSU_STF
+                /sys/devices/cpu/events/PM_LSU_FLUSH_UST
+                /sys/devices/cpu/events/PM_L2_LDST_MISS
+                /sys/devices/cpu/events/PM_FXU1_FIN
+                /sys/devices/cpu/events/PM_SHL_DEALLOCATED
+                /sys/devices/cpu/events/PM_L2_SN_M_WR_DONE
+                /sys/devices/cpu/events/PM_LSU_REJECT_SET_MPRED
+                /sys/devices/cpu/events/PM_L3_PREF_LD
+                /sys/devices/cpu/events/PM_L2_SN_M_RD_DONE
+                /sys/devices/cpu/events/PM_MRK_DERAT_MISS_16G
+                /sys/devices/cpu/events/PM_VSU_FCONV
+                /sys/devices/cpu/events/PM_ANY_THRD_RUN_CYC
+                /sys/devices/cpu/events/PM_LSU_LMQ_FULL_CYC
+                /sys/devices/cpu/events/PM_MRK_LSU_REJECT_LHS
+                /sys/devices/cpu/events/PM_MRK_LD_MISS_L1_CYC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L2_CYC
+                /sys/devices/cpu/events/PM_INST_IMC_MATCH_DISP
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_RMEM_CYC
+                /sys/devices/cpu/events/PM_VSU0_SIMPLE_ISSUED
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_RL2L3_SHR
+                /sys/devices/cpu/events/PM_VSU_FMA_DOUBLE
+                /sys/devices/cpu/events/PM_VSU_4FLOP
+                /sys/devices/cpu/events/PM_VSU1_FIN
+                /sys/devices/cpu/events/PM_NEST_PAIR1_AND
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_RL2L3_MOD
+                /sys/devices/cpu/events/PM_PTEG_FROM_RMEM
+                /sys/devices/cpu/events/PM_LSU_LRQ_S0_VALID
+                /sys/devices/cpu/events/PM_LSU0_LDF
+                /sys/devices/cpu/events/PM_FLUSH_COMPLETION
+                /sys/devices/cpu/events/PM_ST_MISS_L1
+                /sys/devices/cpu/events/PM_L2_NODE_PUMP
+                /sys/devices/cpu/events/PM_INST_FROM_DL2L3_SHR
+                /sys/devices/cpu/events/PM_MRK_STALL_CMPLU_CYC
+                /sys/devices/cpu/events/PM_VSU1_DENORM
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_SHR_CYC
+                /sys/devices/cpu/events/PM_NEST_PAIR0_ADD
+                /sys/devices/cpu/events/PM_INST_FROM_L3MISS
+                /sys/devices/cpu/events/PM_EE_OFF_EXT_INT
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_DMEM
+                /sys/devices/cpu/events/PM_INST_FROM_DL2L3_MOD
+                /sys/devices/cpu/events/PM_PMC6_OVERFLOW
+                /sys/devices/cpu/events/PM_VSU_2FLOP_DOUBLE
+                /sys/devices/cpu/events/PM_TLB_MISS
+                /sys/devices/cpu/events/PM_FXU_BUSY
+                /sys/devices/cpu/events/PM_L2_RCLD_DISP_FAIL_OTHER
+                /sys/devices/cpu/events/PM_LSU_REJECT_LMQ_FULL
+                /sys/devices/cpu/events/PM_IC_RELOAD_SHR
+                /sys/devices/cpu/events/PM_GRP_MRK
+                /sys/devices/cpu/events/PM_MRK_ST_NEST
+                /sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV
+                /sys/devices/cpu/events/PM_LSU0_FLUSH_LRQ
+                /sys/devices/cpu/events/PM_LARX_LSU0
+                /sys/devices/cpu/events/PM_IBUF_FULL_CYC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR_CYC
+                /sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_ALLOC
+                /sys/devices/cpu/events/PM_GRP_MRK_CYC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR_CYC
+                /sys/devices/cpu/events/PM_L2_GLOB_GUESS_CORRECT
+                /sys/devices/cpu/events/PM_LSU_REJECT_LHS
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_LMEM
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L3
+                /sys/devices/cpu/events/PM_FREQ_DOWN
+                /sys/devices/cpu/events/PM_PB_RETRY_NODE_PUMP
+                /sys/devices/cpu/events/PM_INST_FROM_RL2L3_SHR
+                /sys/devices/cpu/events/PM_MRK_INST_ISSUED
+                /sys/devices/cpu/events/PM_PTEG_FROM_L3MISS
+                /sys/devices/cpu/events/PM_RUN_PURR
+                /sys/devices/cpu/events/PM_MRK_GRP_IC_MISS
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L3
+                /sys/devices/cpu/events/PM_PTEG_FROM_RL2L3_SHR
+                /sys/devices/cpu/events/PM_LSU_FLUSH_LRQ
+                /sys/devices/cpu/events/PM_MRK_DERAT_MISS_64K
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_MOD
+                /sys/devices/cpu/events/PM_L2_ST_MISS
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L21_SHR
+                /sys/devices/cpu/events/PM_LWSYNC
+                /sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM_STRIDE
+                /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_LRQ
+                /sys/devices/cpu/events/PM_INST_IMC_MATCH_CMPL
+                /sys/devices/cpu/events/PM_NEST_PAIR3_AND
+                /sys/devices/cpu/events/PM_PB_RETRY_SYS_PUMP
+                /sys/devices/cpu/events/PM_MRK_INST_FIN
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_DL2L3_SHR
+                /sys/devices/cpu/events/PM_INST_FROM_L31_MOD
+                /sys/devices/cpu/events/PM_MRK_DTLB_MISS_64K
+                /sys/devices/cpu/events/PM_LSU_FIN
+                /sys/devices/cpu/events/PM_MRK_LSU_REJECT
+                /sys/devices/cpu/events/PM_L2_CO_FAIL_BUSY
+                /sys/devices/cpu/events/PM_MEM0_WQ_DISP
+                /sys/devices/cpu/events/PM_DATA_FROM_L31_MOD
+                /sys/devices/cpu/events/PM_THERMAL_WARN
+                /sys/devices/cpu/events/PM_VSU0_4FLOP
+                /sys/devices/cpu/events/PM_BR_MPRED_CCACHE
+                /sys/devices/cpu/events/PM_L1_DEMAND_WRITE
+                /sys/devices/cpu/events/PM_FLUSH_BR_MPRED
+                /sys/devices/cpu/events/PM_MRK_DTLB_MISS_16G
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_DMEM
+                /sys/devices/cpu/events/PM_L2_RCST_DISP
+                /sys/devices/cpu/events/PM_LSU_PARTIAL_CDF
+                /sys/devices/cpu/events/PM_DISP_CLB_HELD_SB
+                /sys/devices/cpu/events/PM_VSU0_FMA_DOUBLE
+                /sys/devices/cpu/events/PM_FXU0_BUSY_FXU1_IDLE
+                /sys/devices/cpu/events/PM_IC_DEMAND_CYC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_SHR
+                /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_UST
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L3MISS
+                /sys/devices/cpu/events/PM_VSU_DENORM
+                /sys/devices/cpu/events/PM_MRK_LSU_PARTIAL_CDF
+                /sys/devices/cpu/events/PM_INST_FROM_L21_SHR
+                /sys/devices/cpu/events/PM_IC_PREF_WRITE
+                /sys/devices/cpu/events/PM_BR_PRED
+                /sys/devices/cpu/events/PM_INST_FROM_DMEM
+                /sys/devices/cpu/events/PM_IC_PREF_CANCEL_ALL
+                /sys/devices/cpu/events/PM_LSU_DC_PREF_STREAM_CONFIRM
+                /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_SRQ
+                /sys/devices/cpu/events/PM_MRK_FIN_STALL_CYC
+                /sys/devices/cpu/events/PM_L2_RCST_DISP_FAIL_OTHER
+                /sys/devices/cpu/events/PM_VSU1_DD_ISSUED
+                /sys/devices/cpu/events/PM_PTEG_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_DATA_FROM_L21_SHR
+                /sys/devices/cpu/events/PM_LSU0_NCLD
+                /sys/devices/cpu/events/PM_VSU1_4FLOP
+                /sys/devices/cpu/events/PM_VSU1_8FLOP
+                /sys/devices/cpu/events/PM_VSU_8FLOP
+                /sys/devices/cpu/events/PM_LSU_LMQ_SRQ_EMPTY_CYC
+                /sys/devices/cpu/events/PM_DTLB_MISS_64K
+                /sys/devices/cpu/events/PM_THRD_CONC_RUN_INST
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L2
+                /sys/devices/cpu/events/PM_PB_SYS_PUMP
+                /sys/devices/cpu/events/PM_VSU_FIN
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L31_MOD
+                /sys/devices/cpu/events/PM_THRD_PRIO_0_1_CYC
+                /sys/devices/cpu/events/PM_DERAT_MISS_64K
+                /sys/devices/cpu/events/PM_PMC2_REWIND
+                /sys/devices/cpu/events/PM_INST_FROM_L2
+                /sys/devices/cpu/events/PM_GRP_BR_MPRED_NONSPEC
+                /sys/devices/cpu/events/PM_INST_DISP
+                /sys/devices/cpu/events/PM_MEM0_RD_CANCEL_TOTAL
+                /sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_CONFIRM
+                /sys/devices/cpu/events/PM_L1_DCACHE_RELOAD_VALID
+                /sys/devices/cpu/events/PM_VSU_SCALAR_DOUBLE_ISSUED
+                /sys/devices/cpu/events/PM_L3_PREF_HIT
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L31_MOD
+                /sys/devices/cpu/events/PM_MRK_FXU_FIN
+                /sys/devices/cpu/events/PM_PMC4_OVERFLOW
+                /sys/devices/cpu/events/PM_MRK_PTEG_FROM_L3
+                /sys/devices/cpu/events/PM_LSU0_LMQ_LHR_MERGE
+                /sys/devices/cpu/events/PM_BTAC_HIT
+                /sys/devices/cpu/events/PM_L3_RD_BUSY
+                /sys/devices/cpu/events/PM_LSU0_L1_SW_PREF
+                /sys/devices/cpu/events/PM_INST_FROM_L2MISS
+                /sys/devices/cpu/events/PM_LSU0_DC_PREF_STREAM_ALLOC
+                /sys/devices/cpu/events/PM_L2_ST
+                /sys/devices/cpu/events/PM_VSU0_DENORM
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_SHR
+                /sys/devices/cpu/events/PM_BR_PRED_CR_TA
+                /sys/devices/cpu/events/PM_VSU0_FCONV
+                /sys/devices/cpu/events/PM_MRK_LSU_FLUSH_ULD
+                /sys/devices/cpu/events/PM_BTAC_MISS
+                /sys/devices/cpu/events/PM_MRK_LD_MISS_EXPOSED_CYC_COUNT
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L2
+                /sys/devices/cpu/events/PM_LSU_DCACHE_RELOAD_VALID
+                /sys/devices/cpu/events/PM_VSU_FMA
+                /sys/devices/cpu/events/PM_LSU0_FLUSH_SRQ
+                /sys/devices/cpu/events/PM_LSU1_L1_PREF
+                /sys/devices/cpu/events/PM_IOPS_CMPL
+                /sys/devices/cpu/events/PM_L2_SYS_PUMP
+                /sys/devices/cpu/events/PM_L2_RCLD_BUSY_RC_FULL
+                /sys/devices/cpu/events/PM_LSU_LMQ_S0_ALLOC
+                /sys/devices/cpu/events/PM_FLUSH_DISP_SYNC
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_DL2L3_MOD_CYC
+                /sys/devices/cpu/events/PM_L2_IC_INV
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L21_MOD_CYC
+                /sys/devices/cpu/events/PM_L3_PREF_LDST
+                /sys/devices/cpu/events/PM_LSU_SRQ_EMPTY_CYC
+                /sys/devices/cpu/events/PM_LSU_LMQ_S0_VALID
+                /sys/devices/cpu/events/PM_FLUSH_PARTIAL
+                /sys/devices/cpu/events/PM_VSU1_FMA_DOUBLE
+                /sys/devices/cpu/events/PM_1PLUS_PPC_DISP
+                /sys/devices/cpu/events/PM_DATA_FROM_L2MISS
+                /sys/devices/cpu/events/PM_SUSPENDED
+                /sys/devices/cpu/events/PM_VSU0_FMA
+                /sys/devices/cpu/events/PM_STCX_FAIL
+                /sys/devices/cpu/events/PM_VSU0_FSQRT_FDIV_DOUBLE
+                /sys/devices/cpu/events/PM_DC_PREF_DST
+                /sys/devices/cpu/events/PM_VSU1_SCAL_SINGLE_ISSUED
+                /sys/devices/cpu/events/PM_L3_HIT
+                /sys/devices/cpu/events/PM_L2_GLOB_GUESS_WRONG
+                /sys/devices/cpu/events/PM_MRK_DFU_FIN
+                /sys/devices/cpu/events/PM_INST_FROM_L1
+                /sys/devices/cpu/events/PM_IC_DEMAND_REQ
+                /sys/devices/cpu/events/PM_VSU1_FSQRT_FDIV_DOUBLE
+                /sys/devices/cpu/events/PM_VSU1_FMA
+                /sys/devices/cpu/events/PM_MRK_LD_MISS_L1
+                /sys/devices/cpu/events/PM_VSU0_2FLOP_DOUBLE
+                /sys/devices/cpu/events/PM_LSU_DC_PREF_STRIDED_STREAM_CONFIRM
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_L31_SHR
+                /sys/devices/cpu/events/PM_MRK_LSU_REJECT_ERAT_MISS
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_L2MISS
+                /sys/devices/cpu/events/PM_DATA_FROM_RL2L3_SHR
+                /sys/devices/cpu/events/PM_INST_FROM_PREF
+                /sys/devices/cpu/events/PM_VSU1_SQ
+                /sys/devices/cpu/events/PM_L2_LD_DISP
+                /sys/devices/cpu/events/PM_L2_DISP_ALL
+                /sys/devices/cpu/events/PM_THRD_GRP_CMPL_BOTH_CYC
+                /sys/devices/cpu/events/PM_VSU_FSQRT_FDIV_DOUBLE
+                /sys/devices/cpu/events/PM_INST_PTEG_FROM_DL2L3_SHR
+                /sys/devices/cpu/events/PM_VSU_1FLOP
+                /sys/devices/cpu/events/PM_HV_CYC
+                /sys/devices/cpu/events/PM_MRK_LSU_FIN
+                /sys/devices/cpu/events/PM_MRK_DATA_FROM_RL2L3_SHR
+                /sys/devices/cpu/events/PM_DTLB_MISS_16M
+                /sys/devices/cpu/events/PM_LSU1_LMQ_LHR_MERGE
+                /sys/devices/cpu/events/PM_IFU_FIN
+                /sys/devices/cpu/events/PM_1THRD_CON_RUN_INSTR
+                /sys/devices/cpu/events/PM_CMPLU_STALL_COUNT
+                /sys/devices/cpu/events/PM_MEM0_PB_RD_CL
+                /sys/devices/cpu/events/PM_THRD_1_RUN_CYC
+                /sys/devices/cpu/events/PM_THRD_2_CONC_RUN_INSTR
+                /sys/devices/cpu/events/PM_THRD_2_RUN_CYC
+                /sys/devices/cpu/events/PM_THRD_3_CONC_RUN_INST
+                /sys/devices/cpu/events/PM_THRD_3_RUN_CYC
+                /sys/devices/cpu/events/PM_THRD_4_CONC_RUN_INST
+                /sys/devices/cpu/events/PM_THRD_4_RUN_CYC
 
 Date:           2013/01/08
 
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7 b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
new file mode 100644
index 000000000000..e78ee798d7bd
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -0,0 +1,23 @@
+What:           /sys/bus/event_source/devices/hv_24x7/interface/catalog
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                Provides access to the binary "24x7 catalog" provided by the
+                hypervisor on POWER7 and 8 systems. This catalog lists events
+                avaliable from the powerpc "hv_24x7" pmu. Its format is
+                documented here:
+                https://raw.githubusercontent.com/jmesmon/catalog-24x7/master/hv-24x7-catalog.h
+
+What:           /sys/bus/event_source/devices/hv_24x7/interface/catalog_length
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                A number equal to the length in bytes of the catalog. This is
+                also extractable from the provided binary "catalog" sysfs entry.
+
+What:           /sys/bus/event_source/devices/hv_24x7/interface/catalog_version
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                Exposes the "version" field of the 24x7 catalog. This is also
+                extractable from the provided binary "catalog" sysfs entry.
diff --git a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
new file mode 100644
index 000000000000..3fa58c23f13b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -0,0 +1,43 @@
+What:           /sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                '0' if the hypervisor is configured to forbid access to event
+                counters being accumulated by other guests and to physical
+                domain event counters.
+                '1' if that access is allowed.
+
+What:           /sys/bus/event_source/devices/hv_gpci/interface/ga
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                0 or 1. Indicates whether we have access to "GA" events (listed
+                in arch/powerpc/perf/hv-gpci.h).
+
+What:           /sys/bus/event_source/devices/hv_gpci/interface/expanded
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                0 or 1. Indicates whether we have access to "EXPANDED" events (listed
+                in arch/powerpc/perf/hv-gpci.h).
+
+What:           /sys/bus/event_source/devices/hv_gpci/interface/lab
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                0 or 1. Indicates whether we have access to "LAB" events (listed
+                in arch/powerpc/perf/hv-gpci.h).
+
+What:           /sys/bus/event_source/devices/hv_gpci/interface/version
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                A number indicating the version of the gpci interface that the
+                hypervisor reports supporting.
+
+What:           /sys/bus/event_source/devices/hv_gpci/interface/kernel_version
+Date:           February 2014
+Contact:        Cody P Schafer <cody@linux.vnet.ibm.com>
+Description:
+                A number indicating the latest version of the gpci interface
+                that the kernel is aware of.
diff --git a/Documentation/ABI/testing/sysfs-bus-mdio b/Documentation/ABI/testing/sysfs-bus-mdio
index 6349749ebc29..491baaf4285f 100644
--- a/Documentation/ABI/testing/sysfs-bus-mdio
+++ b/Documentation/ABI/testing/sysfs-bus-mdio
@@ -7,3 +7,23 @@ Description:
                 by the device during bus enumeration, encoded in hexadecimal.
                 This ID is used to match the device with the appropriate
                 driver.
+
+What:           /sys/bus/mdio_bus/devices/.../phy_interface
+Date:           February 2014
+KernelVersion:  3.15
+Contact:        netdev@vger.kernel.org
+Description:
+                This attribute contains the PHY interface as configured by the
+                Ethernet driver during bus enumeration, encoded in string.
+                This interface mode is used to configure the Ethernet MAC with the
+                appropriate mode for its data lines to the PHY hardware.
+
+What:           /sys/bus/mdio_bus/devices/.../phy_has_fixups
+Date:           February 2014
+KernelVersion:  3.15
+Contact:        netdev@vger.kernel.org
+Description:
+                This attribute contains the boolean value whether a given PHY
+                device has had any "fixup" workaround running on it, encoded as
+                a boolean. This information is provided to help troubleshooting
+                PHY configurations.
diff --git a/Documentation/ABI/testing/sysfs-class-net b/Documentation/ABI/testing/sysfs-class-net
new file mode 100644
index 000000000000..d922060e455d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-net
@@ -0,0 +1,199 @@
+What:           /sys/class/net/<iface>/addr_assign_type
+Date:           July 2010
+KernelVersion:  3.2
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the address assignment type. Possible values are:
+                0: permanent address
+                1: randomly generated
+                2: stolen from another device
+                3: set using dev_set_mac_address
+
+What:           /sys/class/net/<iface>/addr_len
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the hardware address size in bytes.
+                Values vary based on the lower-level protocol used by the
+                interface (Ethernet, FDDI, ATM, IEEE 802.15.4...). See
+                include/uapi/linux/if_*.h for actual values.
+
+What:           /sys/class/net/<iface>/address
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Hardware address currently assigned to this interface.
+                Format is a string, e.g: 00:11:22:33:44:55 for an Ethernet MAC
+                address.
+
+What:           /sys/class/net/<iface>/broadcast
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Hardware broadcast address for this interface. Format is a
+                string, e.g: ff:ff:ff:ff:ff:ff for an Ethernet broadcast MAC
+                address.
+
+What:           /sys/class/net/<iface>/carrier
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the current physical link state of the interface.
+                Posssible values are:
+                0: physical link is down
+                1: physical link is up
+
+                Note: some special devices, e.g: bonding and team drivers will
+                allow this attribute to be written to force a link state for
+                operating correctly and designating another fallback interface.
+
+What:           /sys/class/net/<iface>/dev_id
+Date:           April 2008
+KernelVersion:  2.6.26
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the device unique identifier. Format is an hexadecimal
+                value. This is used to disambiguate interfaces which might be
+                stacked (e.g: VLAN interfaces) but still have the same MAC
+                address as their parent device.
+
+What:           /sys/class/net/<iface>/dormant
+Date:           March 2006
+KernelVersion:  2.6.17
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates whether the interface is in dormant state. Possible
+                values are:
+                0: interface is not dormant
+                1: interface is dormant
+
+                This attribute can be used by supplicant software to signal that
+                the device is not usable unless some supplicant-based
+                authentication is performed (e.g: 802.1x). 'link_mode' attribute
+                will also reflect the dormant state.
+
+What:           /sys/clas/net/<iface>/duplex
+Date:           October 2009
+KernelVersion:  2.6.33
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface latest or current duplex value. Possible
+                values are:
+                half: half duplex
+                full: full duplex
+
+                Note: This attribute is only valid for interfaces that implement
+                the ethtool get_settings method (mostly Ethernet).
+
+What:           /sys/class/net/<iface>/flags
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface flags as a bitmask in hexadecimal. See
+                include/uapi/linux/if.h for a list of all possible values and
+                the flags semantics.
+
+What:           /sys/class/net/<iface>/ifalias
+Date:           September 2008
+KernelVersion:  2.6.28
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates/stores an interface alias name as a string. This can
+                be used for system management purposes.
+
+What:           /sys/class/net/<iface>/ifindex
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the system-wide interface unique index identifier as a
+                decimal number. This attribute is used for mapping an interface
+                identifier to an interface name. It is used throughout the
+                networking stack for specifying the interface specific
+                requests/events.
+
+What:           /sys/class/net/<iface>/iflink
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the system-wide interface unique index identifier a
+                the interface is linked to. Format is decimal. This attribute is
+                used to resolve interfaces chaining, linking and stacking.
+                Physical interfaces have the same 'ifindex' and 'iflink' values.
+
+What:           /sys/class/net/<iface>/link_mode
+Date:           March 2006
+KernelVersion:  2.6.17
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface link mode, as a decimal number. This
+                attribute should be used in conjunction with 'dormant' attribute
+                to determine the interface usability. Possible values:
+                0: default link mode
+                1: dormant link mode
+
+What:           /sys/class/net/<iface>/mtu
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface currently configured MTU value, in
+                bytes, and in decimal format. Specific values depends on the
+                lower-level interface protocol used. Ethernet devices will show
+                a 'mtu' attribute value of 1500 unless changed.
+
+What:           /sys/calss/net/<iface>/netdev_group
+Date:           January 2011
+KernelVersion:  2.6.39
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface network device group, as a decimal
+                integer. Default value is 0 which corresponds to the initial
+                network devices group. The group can be changed to affect
+                routing decisions (see: net/ipv4/fib_rules and
+                net/ipv6/fib6_rules.c).
+
+What:           /sys/class/net/<iface>/operstate
+Date:           March 2006
+KernelVersion:  2.6.17
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface RFC2863 operational state as a string.
+                Possible values are:
+                "unknown", "notpresent", "down", "lowerlayerdown", "testing",
+                "dormant", "up".
+
+What:           /sys/class/net/<iface>/speed
+Date:           October 2009
+KernelVersion:  2.6.33
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface latest or current speed value. Value is
+                an integer representing the link speed in Mbits/sec.
+
+                Note: this attribute is only valid for interfaces that implement
+                the ethtool get_settings method (mostly Ethernet ).
+
+What:           /sys/class/net/<iface>/tx_queue_len
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface transmit queue len in number of packets,
+                as an integer value. Value depend on the type of interface,
+                Ethernet network adapters have a default value of 1000 unless
+                configured otherwise
+
+What:           /sys/class/net/<iface>/type
+Date:           April 2005
+KernelVersion:  2.6.12
+Contact:        netdev@vger.kernel.org
+Description:
+                Indicates the interface protocol type as a decimal value. See
+                include/uapi/linux/if_arp.h for all possible values.
diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh
index 4793d3dff6af..c46406296631 100644
--- a/Documentation/ABI/testing/sysfs-class-net-mesh
+++ b/Documentation/ABI/testing/sysfs-class-net-mesh
@@ -76,6 +76,15 @@ Description:
                 is used to classify clients as "isolated" by the
                 Extended Isolation feature.
 
+What:           /sys/class/net/<mesh_iface>/mesh/multicast_mode
+Date:           Feb 2014
+Contact:        Linus Lüssing <linus.luessing@web.de>
+Description:
+                Indicates whether multicast optimizations are enabled
+                or disabled. If set to zero then all nodes in the
+                mesh are going to use classic flooding for any
+                multicast packet with no optimizations.
+
 What:           /sys/class/net/<mesh_iface>/mesh/network_coding
 Date:           Nov 2012
 Contact:        Martin Hundeboll <martin@hundeboll.net>
diff --git a/Documentation/ABI/testing/sysfs-class-rc b/Documentation/ABI/testing/sysfs-class-rc
new file mode 100644
index 000000000000..b65674da43bb
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-rc
@@ -0,0 +1,111 @@
+What:           /sys/class/rc/
+Date:           Apr 2010
+KernelVersion:  2.6.35
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                The rc/ class sub-directory belongs to the Remote Controller
+                core and provides a sysfs interface for configuring infrared
+                remote controller receivers.
+
+What:           /sys/class/rc/rcN/
+Date:           Apr 2010
+KernelVersion:  2.6.35
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                A /sys/class/rc/rcN directory is created for each remote
+                control receiver device where N is the number of the receiver.
+
+What:           /sys/class/rc/rcN/protocols
+Date:           Jun 2010
+KernelVersion:  2.6.36
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                Reading this file returns a list of available protocols,
+                something like:
+                    "rc5 [rc6] nec jvc [sony]"
+                Enabled protocols are shown in [] brackets.
+                Writing "+proto" will add a protocol to the list of enabled
+                protocols.
+                Writing "-proto" will remove a protocol from the list of enabled
+                protocols.
+                Writing "proto" will enable only "proto".
+                Writing "none" will disable all protocols.
+                Write fails with EINVAL if an invalid protocol combination or
+                unknown protocol name is used.
+
+What:           /sys/class/rc/rcN/filter
+Date:           Jan 2014
+KernelVersion:  3.15
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                Sets the scancode filter expected value.
+                Use in combination with /sys/class/rc/rcN/filter_mask to set the
+                expected value of the bits set in the filter mask.
+                If the hardware supports it then scancodes which do not match
+                the filter will be ignored. Otherwise the write will fail with
+                an error.
+                This value may be reset to 0 if the current protocol is altered.
+
+What:           /sys/class/rc/rcN/filter_mask
+Date:           Jan 2014
+KernelVersion:  3.15
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                Sets the scancode filter mask of bits to compare.
+                Use in combination with /sys/class/rc/rcN/filter to set the bits
+                of the scancode which should be compared against the expected
+                value. A value of 0 disables the filter to allow all valid
+                scancodes to be processed.
+                If the hardware supports it then scancodes which do not match
+                the filter will be ignored. Otherwise the write will fail with
+                an error.
+                This value may be reset to 0 if the current protocol is altered.
+
+What:           /sys/class/rc/rcN/wakeup_protocols
+Date:           Feb 2014
+KernelVersion:  3.15
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                Reading this file returns a list of available protocols to use
+                for the wakeup filter, something like:
+                    "rc5 rc6 nec jvc [sony]"
+                The enabled wakeup protocol is shown in [] brackets.
+                Writing "+proto" will add a protocol to the list of enabled
+                wakeup protocols.
+                Writing "-proto" will remove a protocol from the list of enabled
+                wakeup protocols.
+                Writing "proto" will use "proto" for wakeup events.
+                Writing "none" will disable wakeup.
+                Write fails with EINVAL if an invalid protocol combination or
+                unknown protocol name is used, or if wakeup is not supported by
+                the hardware.
+
+What:           /sys/class/rc/rcN/wakeup_filter
+Date:           Jan 2014
+KernelVersion:  3.15
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                Sets the scancode wakeup filter expected value.
+                Use in combination with /sys/class/rc/rcN/wakeup_filter_mask to
+                set the expected value of the bits set in the wakeup filter mask
+                to trigger a system wake event.
+                If the hardware supports it and wakeup_filter_mask is not 0 then
+                scancodes which match the filter will wake the system from e.g.
+                suspend to RAM or power off.
+                Otherwise the write will fail with an error.
+                This value may be reset to 0 if the wakeup protocol is altered.
+
+What:           /sys/class/rc/rcN/wakeup_filter_mask
+Date:           Jan 2014
+KernelVersion:  3.15
+Contact:        Mauro Carvalho Chehab <m.chehab@samsung.com>
+Description:
+                Sets the scancode wakeup filter mask of bits to compare.
+                Use in combination with /sys/class/rc/rcN/wakeup_filter to set
+                the bits of the scancode which should be compared against the
+                expected value to trigger a system wake event.
+                If the hardware supports it and wakeup_filter_mask is not 0 then
+                scancodes which match the filter will wake the system from e.g.
+                suspend to RAM or power off.
+                Otherwise the write will fail with an error.
+                This value may be reset to 0 if the wakeup protocol is altered.
diff --git a/Documentation/ABI/testing/sysfs-class-scsi_host b/Documentation/ABI/testing/sysfs-class-scsi_host
index 29a4f892e433..0eb255e7db12 100644
--- a/Documentation/ABI/testing/sysfs-class-scsi_host
+++ b/Documentation/ABI/testing/sysfs-class-scsi_host
@@ -11,3 +11,19 @@ Description:
                 guaranteed.  The 'isci_id' attribute unambiguously identifies
                 the controller index: '0' for the first controller,
                 '1' for the second.
+
+What:           /sys/class/scsi_host/hostX/acciopath_status
+Date:           November 2013
+Contact:        Stephen M. Cameron <scameron@beardog.cce.hp.com>
+Description:    This file contains the current status of the "SSD Smart Path"
+                feature of HP Smart Array RAID controllers using the hpsa
+                driver.  SSD Smart Path, when enabled permits the driver to
+                send i/o requests directly to physical devices that are part
+                of a logical drive, bypassing the controllers firmware RAID
+                stack for a performance advantage when possible.  A value of
+                '1' indicates the feature is enabled, and the controller may
+                use the direct i/o path to physical devices.  A value of zero
+                means the feature is disabled and the controller may not use
+                the direct i/o path to physical devices.  This setting is
+                controller wide, affecting all configured logical drives on the
+                controller.  This file is readable and writable.
diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power
index efe449bdf811..7dbf96b724ed 100644
--- a/Documentation/ABI/testing/sysfs-devices-power
+++ b/Documentation/ABI/testing/sysfs-devices-power
@@ -187,7 +187,7 @@ Description:
                 Not all drivers support this attribute.  If it isn't supported,
                 attempts to read or write it will yield I/O errors.
 
-What:           /sys/devices/.../power/pm_qos_latency_us
+What:           /sys/devices/.../power/pm_qos_resume_latency_us
 Date:           March 2012
 Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
@@ -205,6 +205,31 @@ Description:
                 This attribute has no effect on system-wide suspend/resume and
                 hibernation.
 
+What:           /sys/devices/.../power/pm_qos_latency_tolerance_us
+Date:           January 2014
+Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
+Description:
+                The /sys/devices/.../power/pm_qos_latency_tolerance_us attribute
+                contains the PM QoS active state latency tolerance limit for the
+                given device in microseconds.  That is the maximum memory access
+                latency the device can suffer without any visible adverse
+                effects on user space functionality.  If that value is the
+                string "any", the latency does not matter to user space at all,
+                but hardware should not be allowed to set the latency tolerance
+                for the device automatically.
+
+                Reading "auto" from this file means that the maximum memory
+                access latency for the device may be determined automatically
+                by the hardware as needed.  Writing "auto" to it allows the
+                hardware to be switched to this mode if there are no other
+                latency tolerance requirements from the kernel side.
+
+                This attribute is only present if the feature controlled by it
+                is supported by the hardware.
+
+                This attribute has no effect on runtime suspend and resume of
+                devices and on system-wide suspend/resume and hibernation.
+
 What:           /sys/devices/.../power/pm_qos_no_power_off
 Date:           September 2012
 Contact:        Rafael J. Wysocki <rjw@rjwysocki.net>
diff --git a/Documentation/ABI/testing/sysfs-firmware-ofw b/Documentation/ABI/testing/sysfs-firmware-ofw
new file mode 100644
index 000000000000..f562b188e71d
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-ofw
@@ -0,0 +1,28 @@
+What:           /sys/firmware/devicetree/*
+Date:           November 2013
+Contact:        Grant Likely <grant.likely@linaro.org>
+Description:
+                When using OpenFirmware or a Flattened Device Tree to enumerate
+                hardware, the device tree structure will be exposed in this
+                directory.
+
+                It is possible for multiple device-tree directories to exist.
+                Some device drivers use a separate detached device tree which
+                have no attachment to the system tree and will appear in a
+                different subdirectory under /sys/firmware/devicetree.
+
+                Userspace must not use the /sys/firmware/devicetree/base
+                path directly, but instead should follow /proc/device-tree
+                symlink. It is possible that the absolute path will change
+                in the future, but the symlink is the stable ABI.
+
+                The /proc/device-tree symlink replaces the devicetree /proc
+                filesystem support, and has largely the same semantics and
+                should be compatible with existing userspace.
+
+                The contents of /sys/firmware/devicetree/ is a
+                hierarchy of directories, one per device tree node. The
+                directory name is the resolved path component name (node
+                name plus address). Properties are represented as files
+                in the directory. The contents of each file is the exact
+                binary data from the device tree.
diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs
index 32b0809203dd..62dd72522d6e 100644
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -55,3 +55,15 @@ Date:		January 2014
 Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
 Description:
                  Controls the number of trials to find a victim segment.
+
+What:           /sys/fs/f2fs/<disk>/dir_level
+Date:           March 2014
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the directory level for large directory.
+
+What:           /sys/fs/f2fs/<disk>/ram_thresh
+Date:           March 2014
+Contact:        "Jaegeuk Kim" <jaegeuk.kim@samsung.com>
+Description:
+                 Controls the memory footprint used by f2fs.
diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module
index 47064c2b1f79..0aac02e7fb0e 100644
--- a/Documentation/ABI/testing/sysfs-module
+++ b/Documentation/ABI/testing/sysfs-module
@@ -49,3 +49,4 @@ Description:	Module taint flags:
                         O - out-of-tree module
                         F - force-loaded module
                         C - staging driver module
+                        E - unsigned module
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 205a73878441..64c9276e9421 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -12,8 +12,9 @@ Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
 Description:
                 The /sys/power/state file controls the system power state.
                 Reading from this file returns what states are supported,
-                which is hard-coded to 'standby' (Power-On Suspend), 'mem'
-                (Suspend-to-RAM), and 'disk' (Suspend-to-Disk).
+                which is hard-coded to 'freeze' (Low-Power Idle), 'standby'
+                (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'
+                (Suspend-to-Disk).
 
                 Writing to this file one of these strings causes the system to
                 transition into that state. Please see the file
diff --git a/Documentation/ABI/testing/sysfs-ptp b/Documentation/ABI/testing/sysfs-ptp
index 05aeedf17794..44806a678f12 100644
--- a/Documentation/ABI/testing/sysfs-ptp
+++ b/Documentation/ABI/testing/sysfs-ptp
@@ -54,6 +54,26 @@ Description:
                 This file contains the number of programmable periodic
                 output channels offered by the PTP hardware clock.
 
+What:           /sys/class/ptp/ptpN/n_pins
+Date:           March 2014
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This file contains the number of programmable pins
+                offered by the PTP hardware clock.
+
+What:           /sys/class/ptp/ptpN/pins
+Date:           March 2014
+Contact:        Richard Cochran <richardcochran@gmail.com>
+Description:
+                This directory contains one file for each programmable
+                pin offered by the PTP hardware clock. The file name
+                is the hardware dependent pin name. Reading from this
+                file produces two numbers, the assigned function (see
+                the PTP_PF_ enumeration values in linux/ptp_clock.h)
+                and the channel number. The function and channel
+                assignment may be changed by two writing numbers into
+                the file.
+
 What:           /sys/class/ptp/ptpN/pps_avaiable
 Date:           September 2010
 Contact:        Richard Cochran <richardcochran@gmail.com>
diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl
index 46ad6faee9ab..044b76436e83 100644
--- a/Documentation/DocBook/80211.tmpl
+++ b/Documentation/DocBook/80211.tmpl
@@ -98,6 +98,8 @@
 !Finclude/net/cfg80211.h priv_to_wiphy
 !Finclude/net/cfg80211.h set_wiphy_dev
 !Finclude/net/cfg80211.h wdev_priv
+!Finclude/net/cfg80211.h ieee80211_iface_limit
+!Finclude/net/cfg80211.h ieee80211_iface_combination
       </chapter>
       <chapter>
       <title>Actions and configuration</title>
diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 0f9c6ff41aac..b444f2e8fe32 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -14,9 +14,9 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
             genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
             80211.xml debugobjects.xml sh.xml regulator.xml \
             alsa-driver-api.xml writing-an-alsa-driver.xml \
-            tracepoint.xml drm.xml media_api.xml
+            tracepoint.xml drm.xml media_api.xml w1.xml
 
-include $(srctree)/Documentation/DocBook/media/Makefile
+include Documentation/DocBook/media/Makefile
 
 ###
 # The build process is as follows (targets):
@@ -36,6 +36,7 @@ PS_METHOD	= $(prefer-db2x)
 # The targets that may be used.
 PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs
 
+targets += $(DOCBOOKS)
 BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
 xmldocs: $(BOOKS)
 sgmldocs: xmldocs
@@ -58,14 +59,14 @@ mandocs: $(MAN)
 
 installmandocs: mandocs
         mkdir -p /usr/local/man/man9/
-        install Documentation/DocBook/man/*.9.gz /usr/local/man/man9/
+        install $(obj)/man/*.9.gz /usr/local/man/man9/
 
 ###
 #External programs used
 KERNELDOC = $(srctree)/scripts/kernel-doc
 DOCPROC   = $(objtree)/scripts/docproc
 
-XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl
+XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
 XMLTOFLAGS += --skip-validation
 
 ###
@@ -87,21 +88,9 @@ define rule_docproc
         ) > $(dir $@).$(notdir $@).cmd
 endef
 
-%.xml: %.tmpl FORCE
+%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
         $(call if_changed_rule,docproc)
 
-###
-#Read in all saved dependency files
-cmd_files := $(wildcard $(foreach f,$(BOOKS),$(dir $(f)).$(notdir $(f)).cmd))
-
-ifneq ($(cmd_files),)
-  include $(cmd_files)
-endif
-
-###
-# Changes in kernel-doc force a rebuild of all documentation
-$(BOOKS): $(KERNELDOC)
-
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
 
@@ -139,7 +128,7 @@ quiet_cmd_db2pdf = PDF     $@
 
 
 index = index.html
-main_idx = Documentation/DocBook/$(index)
+main_idx = $(obj)/$(index)
 build_main_index = rm -rf $(main_idx); \
                    echo '<h1>Linux Kernel HTML Documentation</h1>' >> $(main_idx) && \
                    echo '<h2>Kernel Version: $(KERNELVERSION)</h2>' >> $(main_idx) && \
@@ -148,7 +137,7 @@ build_main_index = rm -rf $(main_idx); \
 quiet_cmd_db2html = HTML    $@
       cmd_db2html = xmlto html $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< && \
                 echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
-        $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
+                $(patsubst %.html,%,$(notdir $@))</a><p>' > $@
 
 %.html: %.xml
         @(which xmlto > /dev/null 2>&1) || \
diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl
index d0758b241b23..e84f09467cd7 100644
--- a/Documentation/DocBook/kernel-hacking.tmpl
+++ b/Documentation/DocBook/kernel-hacking.tmpl
@@ -671,7 +671,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
 
   <sect1 id="routines-local-irqs">
    <title><function>local_irq_save()</function>/<function>local_irq_restore()</function>
-    <filename class="headerfile">include/asm/system.h</filename>
+    <filename class="headerfile">include/linux/irqflags.h</filename>
    </title>
 
    <para>
@@ -850,16 +850,6 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
     <returnvalue>-ERESTARTSYS</returnvalue> if a signal is received.
     The <function>wait_event()</function> version ignores signals.
    </para>
-   <para>
-   Do not use the <function>sleep_on()</function> function family -
-   it is very easy to accidentally introduce races; almost certainly
-   one of the <function>wait_event()</function> family will do, or a
-   loop around <function>schedule_timeout()</function>. If you choose
-   to loop around <function>schedule_timeout()</function> remember
-   you must set the task state (with 
-   <function>set_current_state()</function>) on each iteration to avoid
-   busy-looping.
-   </para>
  
   </sect1>
 
diff --git a/Documentation/DocBook/media/dvb/demux.xml b/Documentation/DocBook/media/dvb/demux.xml
index 86de89cfbd67..c8683d66f059 100644
--- a/Documentation/DocBook/media/dvb/demux.xml
+++ b/Documentation/DocBook/media/dvb/demux.xml
@@ -1042,7 +1042,14 @@ role="subsection"><title>DMX_ADD_PID</title>
 </para>
 <informaltable><tgroup cols="1"><tbody><row><entry
  align="char">
-<para>This ioctl is undocumented. Documentation is welcome.</para>
+<para>This ioctl call allows to add multiple PIDs to a transport stream filter
+previously set up with DMX_SET_PES_FILTER and output equal to DMX_OUT_TSDEMUX_TAP.
+</para></entry></row><row><entry align="char"><para>
+It is used by readers of /dev/dvb/adapterX/demuxY.
+</para></entry></row><row><entry align="char"><para>
+It may be called at any time, i.e. before or after the first filter on the
+shared file descriptor was started. It makes it possible to record multiple
+services without the need to de-multiplex or re-multiplex TS packets.</para>
 </entry>
  </row></tbody></tgroup></informaltable>
 <para>SYNOPSIS
@@ -1075,7 +1082,7 @@ role="subsection"><title>DMX_ADD_PID</title>
 </para>
 </entry><entry
  align="char">
-<para>Undocumented.</para>
+<para>PID number to be filtered.</para>
 </entry>
  </row></tbody></tgroup></informaltable>
 &return-value-dvb;
@@ -1087,7 +1094,15 @@ role="subsection"><title>DMX_REMOVE_PID</title>
 </para>
 <informaltable><tgroup cols="1"><tbody><row><entry
  align="char">
-<para>This ioctl is undocumented. Documentation is welcome.</para>
+<para>This ioctl call allows to remove a PID when multiple PIDs are set on a
+transport stream filter, e. g. a filter previously set up with output equal to
+DMX_OUT_TSDEMUX_TAP, created via either DMX_SET_PES_FILTER or DMX_ADD_PID.
+</para></entry></row><row><entry align="char"><para>
+It is used by readers of /dev/dvb/adapterX/demuxY.
+</para></entry></row><row><entry align="char"><para>
+It may be called at any time, i.e. before or after the first filter on the
+shared file descriptor was started. It makes it possible to record multiple
+services without the need to de-multiplex or re-multiplex TS packets.</para>
 </entry>
  </row></tbody></tgroup></informaltable>
 <para>SYNOPSIS
@@ -1120,7 +1135,7 @@ role="subsection"><title>DMX_REMOVE_PID</title>
 </para>
 </entry><entry
  align="char">
-<para>Undocumented.</para>
+<para>PID of the PES filter to be removed.</para>
 </entry>
  </row></tbody></tgroup></informaltable>
 &return-value-dvb;
diff --git a/Documentation/DocBook/media/dvb/dvbapi.xml b/Documentation/DocBook/media/dvb/dvbapi.xml
index 0197bcc7842d..4c15396c67e5 100644
--- a/Documentation/DocBook/media/dvb/dvbapi.xml
+++ b/Documentation/DocBook/media/dvb/dvbapi.xml
@@ -18,7 +18,7 @@
 <firstname>Mauro</firstname>
 <othername role="mi">Carvalho</othername>
 <surname>Chehab</surname>
-<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
+<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation>
 <contrib>Ported document to Docbook XML.</contrib>
 </author>
 </authorgroup>
@@ -28,7 +28,7 @@
         <holder>Convergence GmbH</holder>
 </copyright>
 <copyright>
-        <year>2009-2012</year>
+        <year>2009-2014</year>
         <holder>Mauro Carvalho Chehab</holder>
 </copyright>
 
diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml
index a9b15e34c5b2..24c22cabc668 100644
--- a/Documentation/DocBook/media/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/media/dvb/dvbproperty.xml
@@ -196,7 +196,7 @@ get/set up to 64 properties. The actual meaning of each property is described on
                 <para>1)For satellital delivery systems, it is measured in kHz.
                         For the other ones, it is measured in Hz.</para>
                 <para>2)For ISDB-T, the channels are usually transmitted with an offset of 143kHz.
-                        E.g. a valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
+                        E.g. a valid frequency could be 474143 kHz. The stepping is bound to the bandwidth of
                         the channel which is 6MHz.</para>
 
                 <para>3)As in ISDB-Tsb the channel consists of only one or three segments the
diff --git a/Documentation/DocBook/media/dvb/frontend.xml b/Documentation/DocBook/media/dvb/frontend.xml
index 0d6e81bd9ed2..8a6a6ff27af5 100644
--- a/Documentation/DocBook/media/dvb/frontend.xml
+++ b/Documentation/DocBook/media/dvb/frontend.xml
@@ -744,7 +744,7 @@ typedef enum fe_hierarchy {
 </para>
 <informaltable><tgroup cols="1"><tbody><row><entry
  align="char">
-<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t
+<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, uint16_t
  &#x22C6;snr);</para>
 </entry>
  </row></tbody></tgroup></informaltable>
@@ -766,7 +766,7 @@ typedef enum fe_hierarchy {
 </entry>
  </row><row><entry
  align="char">
-<para>int16_t *snr</para>
+<para>uint16_t *snr</para>
 </entry><entry
  align="char">
 <para>The signal-to-noise ratio is stored into *snr.</para>
@@ -791,7 +791,7 @@ typedef enum fe_hierarchy {
 <informaltable><tgroup cols="1"><tbody><row><entry
  align="char">
 <para>int ioctl( int fd, int request =
- <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t &#x22C6;strength);</para>
+ <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, uint16_t &#x22C6;strength);</para>
 </entry>
  </row></tbody></tgroup></informaltable>
 
@@ -814,7 +814,7 @@ typedef enum fe_hierarchy {
 </entry>
  </row><row><entry
  align="char">
-<para>int16_t *strength</para>
+<para>uint16_t *strength</para>
 </entry><entry
  align="char">
 <para>The signal strength value is stored into *strength.</para>
diff --git a/Documentation/DocBook/media/v4l/common.xml b/Documentation/DocBook/media/v4l/common.xml
index 1ddf354aa997..71f6bf9e735e 100644
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -38,70 +38,41 @@ the basic concepts applicable to all devices.</para>
 
       <para>V4L2 drivers are implemented as kernel modules, loaded
 manually by the system administrator or automatically when a device is
-first opened. The driver modules plug into the "videodev" kernel
+first discovered. The driver modules plug into the "videodev" kernel
 module. It provides helper functions and a common application
 interface specified in this document.</para>
 
       <para>Each driver thus loaded registers one or more device nodes
-with major number 81 and a minor number between 0 and 255. Assigning
-minor numbers to V4L2 devices is entirely up to the system administrator,
-this is primarily intended to solve conflicts between devices.<footnote>
-          <para>Access permissions are associated with character
-device special files, hence we must ensure device numbers cannot
-change with the module load order. To this end minor numbers are no
-longer automatically assigned by the "videodev" module as in V4L but
-requested by the driver. The defaults will suffice for most people
-unless two drivers compete for the same minor numbers.</para>
-        </footnote> The module options to select minor numbers are named
-after the device special file with a "_nr" suffix. For example "video_nr"
-for <filename>/dev/video</filename> video capture devices. The number is
-an offset to the base minor number associated with the device type.
-<footnote>
-          <para>In earlier versions of the V4L2 API the module options
-where named after the device special file with a "unit_" prefix, expressing
-the minor number itself, not an offset. Rationale for this change is unknown.
-Lastly the naming and semantics are just a convention among driver writers,
-the point to note is that minor numbers are not supposed to be hardcoded
-into drivers.</para>
-        </footnote> When the driver supports multiple devices of the same
-type more than one minor number can be assigned, separated by commas:
-<informalexample>
+with major number 81 and a minor number between 0 and 255. Minor numbers
+are allocated dynamically unless the kernel is compiled with the kernel
+option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are
+allocated in ranges depending on the device node type (video, radio, etc.).</para>
+
+      <para>Many drivers support "video_nr", "radio_nr" or "vbi_nr"
+module options to select specific video/radio/vbi node numbers. This allows
+the user to request that the device node is named e.g. /dev/video5 instead
+of leaving it to chance. When the driver supports multiple devices of the same
+type more than one device node number can be assigned, separated by commas:
+        <informalexample>
           <screen>
-&gt; insmod mydriver.o video_nr=0,1 radio_nr=0,1</screen>
+&gt; modprobe mydriver video_nr=0,1 radio_nr=0,1</screen>
         </informalexample></para>
 
       <para>In <filename>/etc/modules.conf</filename> this may be
 written as: <informalexample>
           <screen>
-alias char-major-81-0 mydriver
-alias char-major-81-1 mydriver
-alias char-major-81-64 mydriver              <co id="alias" />
-options mydriver video_nr=0,1 radio_nr=0,1   <co id="options" />
+options mydriver video_nr=0,1 radio_nr=0,1
           </screen>
-          <calloutlist>
-            <callout arearefs="alias">
-              <para>When an application attempts to open a device
-special file with major number 81 and minor number 0, 1, or 64, load
-"mydriver" (and the "videodev" module it depends upon).</para>
-            </callout>
-            <callout arearefs="options">
-              <para>Register the first two video capture devices with
-minor number 0 and 1 (base number is 0), the first two radio device
-with minor number 64 and 65 (base 64).</para>
-            </callout>
-          </calloutlist>
-        </informalexample> When no minor number is given as module
-option the driver supplies a default. <xref linkend="devices" />
-recommends the base minor numbers to be used for the various device
-types. Obviously minor numbers must be unique. When the number is
-already in use the <emphasis>offending device</emphasis> will not be
-registered. <!-- Blessed by Linus Torvalds on
-linux-kernel@vger.kernel.org, 2002-11-20. --></para>
-
-      <para>By convention system administrators create various
-character device special files with these major and minor numbers in
-the <filename>/dev</filename> directory. The names recommended for the
-different V4L2 device types are listed in <xref linkend="devices" />.
+        </informalexample> When no device node number is given as module
+option the driver supplies a default.</para>
+
+      <para>Normally udev will create the device nodes in /dev automatically
+for you. If udev is not installed, then you need to enable the
+CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to correctly
+relate a minor number to a device node number. I.e., you need to be certain
+that minor number 5 maps to device node name video5. With this kernel option
+different device types have different minor number ranges. These ranges are
+listed in <xref linkend="devices" />.
 </para>
 
       <para>The creation of character special files (with
@@ -110,85 +81,66 @@ devices cannot be opened by major and minor number. That means
 applications cannot <emphasis>reliable</emphasis> scan for loaded or
 installed drivers. The user must enter a device name, or the
 application can try the conventional device names.</para>
-
-      <para>Under the device filesystem (devfs) the minor number
-options are ignored. V4L2 drivers (or by proxy the "videodev" module)
-automatically create the required device files in the
-<filename>/dev/v4l</filename> directory using the conventional device
-names above.</para>
     </section>
 
     <section id="related">
       <title>Related Devices</title>
 
-      <para>Devices can support several related functions. For example
-video capturing, video overlay and VBI capturing are related because
-these functions share, amongst other, the same video input and tuner
-frequency. V4L and earlier versions of V4L2 used the same device name
-and minor number for video capturing and overlay, but different ones
-for VBI. Experience showed this approach has several problems<footnote>
-          <para>Given a device file name one cannot reliable find
-related devices. For once names are arbitrary and in a system with
-multiple devices, where only some support VBI capturing, a
-<filename>/dev/video2</filename> is not necessarily related to
-<filename>/dev/vbi2</filename>. The V4L
-<constant>VIDIOCGUNIT</constant> ioctl would require a search for a
-device file with a particular major and minor number.</para>
-        </footnote>, and to make things worse the V4L videodev module
-used to prohibit multiple opens of a device.</para>
-
-      <para>As a remedy the present version of the V4L2 API relaxed the
-concept of device types with specific names and minor numbers. For
-compatibility with old applications drivers must still register different
-minor numbers to assign a default function to the device. But if related
-functions are supported by the driver they must be available under all
-registered minor numbers. The desired function can be selected after
-opening the device as described in <xref linkend="devices" />.</para>
-
-      <para>Imagine a driver supporting video capturing, video
-overlay, raw VBI capturing, and FM radio reception. It registers three
-devices with minor number 0, 64 and 224 (this numbering scheme is
-inherited from the V4L API). Regardless if
-<filename>/dev/video</filename> (81, 0) or
-<filename>/dev/vbi</filename> (81, 224) is opened the application can
-select any one of the video capturing, overlay or VBI capturing
-functions. Without programming (e.&nbsp;g. reading from the device
-with <application>dd</application> or <application>cat</application>)
-<filename>/dev/video</filename> captures video images, while
-<filename>/dev/vbi</filename> captures raw VBI data.
-<filename>/dev/radio</filename> (81, 64) is invariable a radio device,
-unrelated to the video functions. Being unrelated does not imply the
-devices can be used at the same time, however. The &func-open;
-function may very well return an &EBUSY;.</para>
+      <para>Devices can support several functions. For example
+video capturing, VBI capturing and radio support.</para>
+
+      <para>The V4L2 API creates different nodes for each of these functions.</para>
+
+      <para>The V4L2 API was designed with the idea that one device node could support
+all functions. However, in practice this never worked: this 'feature'
+was never used by applications and many drivers did not support it and if
+they did it was certainly never tested. In addition, switching a device
+node between different functions only works when using the streaming I/O
+API, not with the read()/write() API.</para>
+
+      <para>Today each device node supports just one function.</para>
 
       <para>Besides video input or output the hardware may also
 support audio sampling or playback. If so, these functions are
-implemented as OSS or ALSA PCM devices and eventually OSS or ALSA
-audio mixer. The V4L2 API makes no provisions yet to find these
-related devices. If you have an idea please write to the linux-media
-mailing list: &v4l-ml;.</para>
+implemented as ALSA PCM devices with optional ALSA audio mixer
+devices.</para>
+
+      <para>One problem with all these devices is that the V4L2 API
+makes no provisions to find these related devices. Some really
+complex devices use the Media Controller (see <xref linkend="media_controller" />)
+which can be used for this purpose. But most drivers do not use it,
+and while some code exists that uses sysfs to discover related devices
+(see libmedia_dev in the <ulink url="http://git.linuxtv.org/v4l-utils/">v4l-utils</ulink>
+git repository), there is no library yet that can provide a single API towards
+both Media Controller-based devices and devices that do not use the Media Controller.
+If you want to work on this please write to the linux-media mailing list: &v4l-ml;.</para>
     </section>
 
     <section>
       <title>Multiple Opens</title>
 
-      <para>In general, V4L2 devices can be opened more than once.
+      <para>V4L2 devices can be opened more than once.<footnote><para>
+There are still some old and obscure drivers that have not been updated to
+allow for multiple opens. This implies that for such drivers &func-open; can
+return an &EBUSY; when the device is already in use.</para></footnote>
 When this is supported by the driver, users can for example start a
 "panel" application to change controls like brightness or audio
 volume, while another application captures video and audio. In other words, panel
-applications are comparable to an OSS or ALSA audio mixer application.
-When a device supports multiple functions like capturing and overlay
-<emphasis>simultaneously</emphasis>, multiple opens allow concurrent
-use of the device by forked processes or specialized applications.</para>
-
-      <para>Multiple opens are optional, although drivers should
-permit at least concurrent accesses without data exchange, &ie; panel
-applications. This implies &func-open; can return an &EBUSY; when the
-device is already in use, as well as &func-ioctl; functions initiating
-data exchange (namely the &VIDIOC-S-FMT; ioctl), and the &func-read;
-and &func-write; functions.</para>
-
-      <para>Mere opening a V4L2 device does not grant exclusive
+applications are comparable to an ALSA audio mixer application.
+Just opening a V4L2 device should not change the state of the device.<footnote>
+<para>Unfortunately, opening a radio device often switches the state of the
+device to radio mode in many drivers. This behavior should be fixed eventually
+as it violates the V4L2 specification.</para></footnote></para>
+
+      <para>Once an application has allocated the memory buffers needed for
+streaming data (by calling the &VIDIOC-REQBUFS; or &VIDIOC-CREATE-BUFS; ioctls,
+or implicitly by calling the &func-read; or &func-write; functions) that
+application (filehandle) becomes the owner of the device. It is no longer
+allowed to make changes that would affect the buffer sizes (e.g. by calling
+the &VIDIOC-S-FMT; ioctl) and other applications are no longer allowed to allocate
+buffers or start or stop streaming. The &EBUSY; will be returned instead.</para>
+
+      <para>Merely opening a V4L2 device does not grant exclusive
 access.<footnote>
           <para>Drivers could recognize the
 <constant>O_EXCL</constant> open flag. Presently this is not required,
@@ -206,12 +158,7 @@ additional access privileges using the priority mechanism described in
       <para>V4L2 drivers should not support multiple applications
 reading or writing the same data stream on a device by copying
 buffers, time multiplexing or similar means. This is better handled by
-a proxy application in user space. When the driver supports stream
-sharing anyway it must be implemented transparently. The V4L2 API does
-not specify how conflicts are solved. <!-- For example O_EXCL when the
-application does not want to be preempted, PROT_READ mmapped buffers
-which can be mapped twice, what happens when image formats do not
-match etc.--></para>
+a proxy application in user space.</para>
     </section>
 
     <section>
@@ -240,15 +187,15 @@ methods</link> supported by the device.</para>
 
     <para>Starting with kernel version 3.1, VIDIOC-QUERYCAP will return the
 V4L2 API version used by the driver, with generally matches the Kernel version.
-There's no need of using &VIDIOC-QUERYCAP; to check if an specific ioctl is
-supported, the V4L2 core now returns ENOIOCTLCMD if a driver doesn't provide
+There's no need of using &VIDIOC-QUERYCAP; to check if a specific ioctl is
+supported, the V4L2 core now returns ENOTTY if a driver doesn't provide
 support for an ioctl.</para>
 
     <para>Other features can be queried
 by calling the respective ioctl, for example &VIDIOC-ENUMINPUT;
 to learn about the number, types and names of video connectors on the
 device. Although abstraction is a major objective of this API, the
-ioctl also allows driver specific applications to reliable identify
+&VIDIOC-QUERYCAP; ioctl also allows driver specific applications to reliably identify
 the driver.</para>
 
     <para>All V4L2 drivers must support
@@ -278,9 +225,7 @@ Applications requiring a different priority will usually call
 the &VIDIOC-QUERYCAP; ioctl.</para>
 
     <para>Ioctls changing driver properties, such as &VIDIOC-S-INPUT;,
-return an &EBUSY; after another application obtained higher priority.
-An event mechanism to notify applications about asynchronous property
-changes has been proposed but not added yet.</para>
+return an &EBUSY; after another application obtained higher priority.</para>
   </section>
 
   <section id="video">
@@ -288,9 +233,9 @@ changes has been proposed but not added yet.</para>
 
     <para>Video inputs and outputs are physical connectors of a
 device. These can be for example RF connectors (antenna/cable), CVBS
-a.k.a. Composite Video, S-Video or RGB connectors. Only video and VBI
-capture devices have inputs, output devices have outputs, at least one
-each. Radio devices have no video inputs or outputs.</para>
+a.k.a. Composite Video, S-Video or RGB connectors. Video and VBI
+capture devices have inputs. Video and VBI output devices have outputs,
+at least one each. Radio devices have no video inputs or outputs.</para>
 
     <para>To learn about the number and attributes of the
 available inputs and outputs applications can enumerate them with the
@@ -299,30 +244,13 @@ available inputs and outputs applications can enumerate them with the
 ioctl also contains signal status information applicable when the
 current video input is queried.</para>
 
-    <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctl return the
+    <para>The &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; ioctls return the
 index of the current video input or output. To select a different
 input or output applications call the &VIDIOC-S-INPUT; and
-&VIDIOC-S-OUTPUT; ioctl. Drivers must implement all the input ioctls
+&VIDIOC-S-OUTPUT; ioctls. Drivers must implement all the input ioctls
 when the device has one or more inputs, all the output ioctls when the
 device has one or more outputs.</para>
 
-    <!--
-    <figure id=io-tree>
-      <title>Input and output enumeration is the root of most device properties.</title>
-      <mediaobject>
-        <imageobject>
-          <imagedata fileref="links.pdf" format="ps" />
-        </imageobject>
-        <imageobject>
-          <imagedata fileref="links.gif" format="gif" />
-        </imageobject>
-        <textobject>
-          <phrase>Links between various device property structures.</phrase>
-        </textobject>
-      </mediaobject>
-    </figure>
-    -->
-
     <example>
       <title>Information about the current video input</title>
 
@@ -330,20 +258,20 @@ device has one or more outputs.</para>
 &v4l2-input; input;
 int index;
 
-if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &amp;index)) {
-        perror ("VIDIOC_G_INPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &amp;index)) {
+        perror("VIDIOC_G_INPUT");
+        exit(EXIT_FAILURE);
 }
 
-memset (&amp;input, 0, sizeof (input));
+memset(&amp;input, 0, sizeof(input));
 input.index = index;
 
-if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
-        perror ("VIDIOC_ENUMINPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
+        perror("VIDIOC_ENUMINPUT");
+        exit(EXIT_FAILURE);
 }
 
-printf ("Current input: %s\n", input.name);
+printf("Current input: %s\n", input.name);
       </programlisting>
     </example>
 
@@ -355,9 +283,9 @@ int index;
 
 index = 0;
 
-if (-1 == ioctl (fd, &VIDIOC-S-INPUT;, &amp;index)) {
-        perror ("VIDIOC_S_INPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-S-INPUT;, &amp;index)) {
+        perror("VIDIOC_S_INPUT");
+        exit(EXIT_FAILURE);
 }
       </programlisting>
     </example>
@@ -397,7 +325,7 @@ available inputs and outputs applications can enumerate them with the
 also contains signal status information applicable when the current
 audio input is queried.</para>
 
-    <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctl report
+    <para>The &VIDIOC-G-AUDIO; and &VIDIOC-G-AUDOUT; ioctls report
 the current audio input and output, respectively. Note that, unlike
 &VIDIOC-G-INPUT; and &VIDIOC-G-OUTPUT; these ioctls return a structure
 as <constant>VIDIOC_ENUMAUDIO</constant> and
@@ -408,11 +336,11 @@ applications call the &VIDIOC-S-AUDIO; ioctl. To select an audio
 output (which presently has no changeable properties) applications
 call the &VIDIOC-S-AUDOUT; ioctl.</para>
 
-    <para>Drivers must implement all input ioctls when the device
-has one or more inputs, all output ioctls when the device has one
-or more outputs. When the device has any audio inputs or outputs the
-driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the
-&v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para>
+    <para>Drivers must implement all audio input ioctls when the device
+has multiple selectable audio inputs, all audio output ioctls when the
+device has multiple selectable audio outputs. When the device has any
+audio inputs or outputs the driver must set the <constant>V4L2_CAP_AUDIO</constant>
+flag in the &v4l2-capability; returned by the &VIDIOC-QUERYCAP; ioctl.</para>
 
     <example>
       <title>Information about the current audio input</title>
@@ -420,14 +348,14 @@ driver must set the <constant>V4L2_CAP_AUDIO</constant> flag in the
       <programlisting>
 &v4l2-audio; audio;
 
-memset (&amp;audio, 0, sizeof (audio));
+memset(&amp;audio, 0, sizeof(audio));
 
-if (-1 == ioctl (fd, &VIDIOC-G-AUDIO;, &amp;audio)) {
-        perror ("VIDIOC_G_AUDIO");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-G-AUDIO;, &amp;audio)) {
+        perror("VIDIOC_G_AUDIO");
+        exit(EXIT_FAILURE);
 }
 
-printf ("Current input: %s\n", audio.name);
+printf("Current input: %s\n", audio.name);
       </programlisting>
     </example>
 
@@ -437,13 +365,13 @@ printf ("Current input: %s\n", audio.name);
       <programlisting>
 &v4l2-audio; audio;
 
-memset (&amp;audio, 0, sizeof (audio)); /* clear audio.mode, audio.reserved */
+memset(&amp;audio, 0, sizeof(audio)); /* clear audio.mode, audio.reserved */
 
 audio.index = 0;
 
-if (-1 == ioctl (fd, &VIDIOC-S-AUDIO;, &amp;audio)) {
-        perror ("VIDIOC_S_AUDIO");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-S-AUDIO;, &amp;audio)) {
+        perror("VIDIOC_S_AUDIO");
+        exit(EXIT_FAILURE);
 }
       </programlisting>
     </example>
@@ -468,7 +396,7 @@ the tuner.</para>
 video inputs.</para>
 
       <para>To query and change tuner properties applications use the
-&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctl, respectively. The
+&VIDIOC-G-TUNER; and &VIDIOC-S-TUNER; ioctls, respectively. The
 &v4l2-tuner; returned by <constant>VIDIOC_G_TUNER</constant> also
 contains signal status information applicable when the tuner of the
 current video or radio input is queried. Note that
@@ -533,7 +461,7 @@ standards or variations of standards. Each video input and output may
 support another set of standards. This set is reported by the
 <structfield>std</structfield> field of &v4l2-input; and
 &v4l2-output; returned by the &VIDIOC-ENUMINPUT; and
-&VIDIOC-ENUMOUTPUT; ioctl, respectively.</para>
+&VIDIOC-ENUMOUTPUT; ioctls, respectively.</para>
 
     <para>V4L2 defines one bit for each analog video standard
 currently in use worldwide, and sets aside bits for driver defined
@@ -564,28 +492,10 @@ automatically.</para>
     <para>To query and select the standard used by the current video
 input or output applications call the &VIDIOC-G-STD; and
 &VIDIOC-S-STD; ioctl, respectively. The <emphasis>received</emphasis>
-standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the parameter of all these ioctls is a pointer to a &v4l2-std-id; type (a standard set), <emphasis>not</emphasis> an index into the standard enumeration.<footnote>
-        <para>An alternative to the current scheme is to use pointers
-to indices as arguments of <constant>VIDIOC_G_STD</constant> and
-<constant>VIDIOC_S_STD</constant>, the &v4l2-input; and
-&v4l2-output; <structfield>std</structfield> field would be a set of
-indices like <structfield>audioset</structfield>.</para>
-        <para>Indices are consistent with the rest of the API
-and identify the standard unambiguously. In the present scheme of
-things an enumerated standard is looked up by &v4l2-std-id;. Now the
-standards supported by the inputs of a device can overlap. Just
-assume the tuner and composite input in the example above both
-exist on a device. An enumeration of "PAL-B/G", "PAL-H/I" suggests
-a choice which does not exist. We cannot merge or omit sets, because
-applications would be unable to find the standards reported by
-<constant>VIDIOC_G_STD</constant>. That leaves separate enumerations
-for each input. Also selecting a standard by &v4l2-std-id; can be
-ambiguous. Advantage of this method is that applications need not
-identify the standard indirectly, after enumerating.</para><para>So in
-summary, the lookup itself is unavoidable. The difference is only
-whether the lookup is necessary to find an enumerated standard or to
-switch to a standard by &v4l2-std-id;.</para>
-      </footnote> Drivers must implement all video standard ioctls
+standard can be sensed with the &VIDIOC-QUERYSTD; ioctl. Note that the
+parameter of all these ioctls is a pointer to a &v4l2-std-id; type
+(a standard set), <emphasis>not</emphasis> an index into the standard
+enumeration. Drivers must implement all video standard ioctls
 when the device has one or more video inputs or outputs.</para>
 
     <para>Special rules apply to devices such as USB cameras where the notion of video
@@ -604,17 +514,10 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
 <constant>VIDIOC_S_STD</constant>,
 <constant>VIDIOC_QUERYSTD</constant> and
 <constant>VIDIOC_ENUMSTD</constant> ioctls shall return the
-&ENOTTY;.<footnote>
-        <para>See <xref linkend="buffer" /> for a rationale.</para>
+&ENOTTY; or the &EINVAL;.</para>
         <para>Applications can make use of the <xref linkend="input-capabilities" /> and
 <xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
-are available for the device.</para>
-
-        <para>See <xref linkend="buffer" /> for a rationale. Probably
-even USB cameras follow some well known video standard. It might have
-been better to explicitly indicate elsewhere if a device cannot live
-up to normal expectations, instead of this exception.</para>
-            </footnote></para>
+can be used with the given input or output.</para>
 
     <example>
       <title>Information about the current video standard</title>
@@ -623,22 +526,22 @@ up to normal expectations, instead of this exception.</para>
 &v4l2-std-id; std_id;
 &v4l2-standard; standard;
 
-if (-1 == ioctl (fd, &VIDIOC-G-STD;, &amp;std_id)) {
+if (-1 == ioctl(fd, &VIDIOC-G-STD;, &amp;std_id)) {
         /* Note when VIDIOC_ENUMSTD always returns ENOTTY this
            is no video device or it falls under the USB exception,
            and VIDIOC_G_STD returning ENOTTY is no error. */
 
-        perror ("VIDIOC_G_STD");
-        exit (EXIT_FAILURE);
+        perror("VIDIOC_G_STD");
+        exit(EXIT_FAILURE);
 }
 
-memset (&amp;standard, 0, sizeof (standard));
+memset(&amp;standard, 0, sizeof(standard));
 standard.index = 0;
 
-while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
+while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
         if (standard.id &amp; std_id) {
-               printf ("Current video standard: %s\n", standard.name);
-               exit (EXIT_SUCCESS);
+               printf("Current video standard: %s\n", standard.name);
+               exit(EXIT_SUCCESS);
         }
 
         standard.index++;
@@ -648,8 +551,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
    empty unless this device falls under the USB exception. */
 
 if (errno == EINVAL || standard.index == 0) {
-        perror ("VIDIOC_ENUMSTD");
-        exit (EXIT_FAILURE);
+        perror("VIDIOC_ENUMSTD");
+        exit(EXIT_FAILURE);
 }
       </programlisting>
     </example>
@@ -662,26 +565,26 @@ input</title>
 &v4l2-input; input;
 &v4l2-standard; standard;
 
-memset (&amp;input, 0, sizeof (input));
+memset(&amp;input, 0, sizeof(input));
 
-if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
-        perror ("VIDIOC_G_INPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
+        perror("VIDIOC_G_INPUT");
+        exit(EXIT_FAILURE);
 }
 
-if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
-        perror ("VIDIOC_ENUM_INPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
+        perror("VIDIOC_ENUM_INPUT");
+        exit(EXIT_FAILURE);
 }
 
-printf ("Current input %s supports:\n", input.name);
+printf("Current input %s supports:\n", input.name);
 
-memset (&amp;standard, 0, sizeof (standard));
+memset(&amp;standard, 0, sizeof(standard));
 standard.index = 0;
 
-while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
+while (0 == ioctl(fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
         if (standard.id &amp; input.std)
-                printf ("%s\n", standard.name);
+                printf("%s\n", standard.name);
 
         standard.index++;
 }
@@ -690,8 +593,8 @@ while (0 == ioctl (fd, &VIDIOC-ENUMSTD;, &amp;standard)) {
    empty unless this device falls under the USB exception. */
 
 if (errno != EINVAL || standard.index == 0) {
-        perror ("VIDIOC_ENUMSTD");
-        exit (EXIT_FAILURE);
+        perror("VIDIOC_ENUMSTD");
+        exit(EXIT_FAILURE);
 }
       </programlisting>
     </example>
@@ -703,21 +606,21 @@ if (errno != EINVAL || standard.index == 0) {
 &v4l2-input; input;
 &v4l2-std-id; std_id;
 
-memset (&amp;input, 0, sizeof (input));
+memset(&amp;input, 0, sizeof(input));
 
-if (-1 == ioctl (fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
-        perror ("VIDIOC_G_INPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-G-INPUT;, &amp;input.index)) {
+        perror("VIDIOC_G_INPUT");
+        exit(EXIT_FAILURE);
 }
 
-if (-1 == ioctl (fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
-        perror ("VIDIOC_ENUM_INPUT");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-ENUMINPUT;, &amp;input)) {
+        perror("VIDIOC_ENUM_INPUT");
+        exit(EXIT_FAILURE);
 }
 
 if (0 == (input.std &amp; V4L2_STD_PAL_BG)) {
-        fprintf (stderr, "Oops. B/G PAL is not supported.\n");
-        exit (EXIT_FAILURE);
+        fprintf(stderr, "Oops. B/G PAL is not supported.\n");
+        exit(EXIT_FAILURE);
 }
 
 /* Note this is also supposed to work when only B
@@ -725,9 +628,9 @@ if (0 == (input.std &amp; V4L2_STD_PAL_BG)) {
 
 std_id = V4L2_STD_PAL_BG;
 
-if (-1 == ioctl (fd, &VIDIOC-S-STD;, &amp;std_id)) {
-        perror ("VIDIOC_S_STD");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, &VIDIOC-S-STD;, &amp;std_id)) {
+        perror("VIDIOC_S_STD");
+        exit(EXIT_FAILURE);
 }
       </programlisting>
     </example>
@@ -740,26 +643,25 @@ corresponding video timings. Today there are many more different hardware interf
 such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry
 video signals and there is a need to extend the API to select the video timings
 for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to
-the limited bits available, a new set of IOCTLs was added to set/get video timings at
-the input and output: </para><itemizedlist>
-        <listitem>
-        <para>DV Timings: This will allow applications to define detailed
-video timings for the interface. This includes parameters such as width, height,
-polarities, frontporch, backporch etc. The <filename>linux/v4l2-dv-timings.h</filename>
+the limited bits available, a new set of ioctls was added to set/get video timings at
+the input and output.</para>
+
+        <para>These ioctls deal with the detailed digital video timings that define
+each video format. This includes parameters such as the active video width and height,
+signal polarities, frontporches, backporches, sync widths etc. The <filename>linux/v4l2-dv-timings.h</filename>
 header can be used to get the timings of the formats in the <xref linkend="cea861" /> and
 <xref linkend="vesadmt" /> standards.
         </para>
-        </listitem>
-        </itemizedlist>
-        <para>To enumerate and query the attributes of the DV timings supported by a device,
+
+        <para>To enumerate and query the attributes of the DV timings supported by a device
         applications use the &VIDIOC-ENUM-DV-TIMINGS; and &VIDIOC-DV-TIMINGS-CAP; ioctls.
-        To set DV timings for the device, applications use the
+        To set DV timings for the device applications use the
 &VIDIOC-S-DV-TIMINGS; ioctl and to get current DV timings they use the
 &VIDIOC-G-DV-TIMINGS; ioctl. To detect the DV timings as seen by the video receiver applications
 use the &VIDIOC-QUERY-DV-TIMINGS; ioctl.</para>
         <para>Applications can make use of the <xref linkend="input-capabilities" /> and
-<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
-video timings for the device.</para>
+<xref linkend="output-capabilities"/> flags to determine whether the digital video ioctls
+can be used with the given input or output.</para>
   </section>
 
   &sub-controls;
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index c4cac6dbf9af..eee6f0f4aa43 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -397,7 +397,7 @@ linkend="control" />.</para>
 
       <para>The <structfield>depth</structfield> (average number of
 bits per pixel) of a video image is implied by the selected image
-format. V4L2 does not explicitely provide such information assuming
+format. V4L2 does not explicitly provide such information assuming
 applications recognizing the format are aware of the image depth and
 others need not know. The <structfield>palette</structfield> field
 moved into the &v4l2-pix-format;:<informaltable>
@@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32.
       </orderedlist>
     </section>
 
+    <section>
+      <title>V4L2 in Linux 3.15</title>
+      <orderedlist>
+        <listitem>
+          <para>Added Software Defined Radio (SDR) Interface.
+          </para>
+        </listitem>
+      </orderedlist>
+    </section>
+
     <section id="other">
       <title>Relation of V4L2 to other Linux multimedia APIs</title>
 
@@ -2651,6 +2661,9 @@ ioctls.</para>
         <listitem>
           <para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
         </listitem>
+        <listitem>
+          <para>Software Defined Radio (SDR) Interface, <xref linkend="sdr" />.</para>
+        </listitem>
       </itemizedlist>
     </section>
 
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index a5a3188e5af7..47198eef75a4 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -2258,6 +2258,26 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
 VBV buffer control.</entry>
               </row>
 
+                  <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-hor-search-range">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_H_SEARCH_RANGE</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row>
+                <row><entry spanname="descr">Horizontal search range defines maximum horizontal search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+horizontal search range for motion estimation module in video encoder.</entry>
+              </row>
+
+                 <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-vert-search-range">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_MV_V_SEARCH_RANGE</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row>
+                <row><entry spanname="descr">Vertical search range defines maximum vertical search area in pixels
+to search and match for the present Macroblock (MB) in the reference picture. This V4L2 control macro is used to set
+vertical search range for motion estimation module in video encoder.</entry>
+              </row>
+
               <row><entry></entry></row>
               <row>
                 <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
@@ -4370,6 +4390,24 @@ interface and may change in the future.</para>
                   <entry>The flash controller has detected a short or open
                   circuit condition on the indicator LED.</entry>
                 </row>
+                <row>
+                  <entry><constant>V4L2_FLASH_FAULT_UNDER_VOLTAGE</constant></entry>
+                  <entry>Flash controller voltage to the flash LED
+                  has been below the minimum limit specific to the flash
+                  controller.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_FLASH_FAULT_INPUT_VOLTAGE</constant></entry>
+                  <entry>The input voltage of the flash controller is below
+                  the limit under which strobing the flash at full current
+                  will not be possible.The condition persists until this flag
+                  is no longer set.</entry>
+                </row>
+                <row>
+                  <entry><constant>V4L2_FLASH_FAULT_LED_OVER_TEMPERATURE</constant></entry>
+                  <entry>The temperature of the LED has exceeded its
+                  allowed upper limit.</entry>
+                </row>
               </tbody>
             </entrytbl>
           </row>
@@ -4971,4 +5009,142 @@ defines possible values for de-emphasis. Here they are:</entry>
       </table>
 
       </section>
+
+    <section id="rf-tuner-controls">
+      <title>RF Tuner Control Reference</title>
+
+      <para>
+The RF Tuner (RF_TUNER) class includes controls for common features of devices
+having RF tuner.
+      </para>
+      <para>
+In this context, RF tuner is radio receiver circuit between antenna and
+demodulator. It receives radio frequency (RF) from the antenna and converts that
+received signal to lower intermediate frequency (IF) or baseband frequency (BB).
+Tuners that could do baseband output are often called Zero-IF tuners. Older
+tuners were typically simple PLL tuners inside a metal box, whilst newer ones
+are highly integrated chips without a metal box "silicon tuners". These controls
+are mostly applicable for new feature rich silicon tuners, just because older
+tuners does not have much adjustable features.
+      </para>
+      <para>
+For more information about RF tuners see
+<ulink url="http://en.wikipedia.org/wiki/Tuner_%28radio%29">Tuner (radio)</ulink>
+and
+<ulink url="http://en.wikipedia.org/wiki/RF_front_end">RF front end</ulink>
+from Wikipedia.
+      </para>
+
+      <table pgwide="1" frame="none" id="rf-tuner-control-id">
+        <title>RF_TUNER Control IDs</title>
+
+        <tgroup cols="4">
+          <colspec colname="c1" colwidth="1*" />
+          <colspec colname="c2" colwidth="6*" />
+          <colspec colname="c3" colwidth="2*" />
+          <colspec colname="c4" colwidth="6*" />
+          <spanspec namest="c1" nameend="c2" spanname="id" />
+          <spanspec namest="c2" nameend="c4" spanname="descr" />
+          <thead>
+            <row>
+              <entry spanname="id" align="left">ID</entry>
+              <entry align="left">Type</entry>
+            </row>
+            <row rowsep="1">
+              <entry spanname="descr" align="left">Description</entry>
+            </row>
+          </thead>
+          <tbody valign="top">
+            <row><entry></entry></row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_CLASS</constant>&nbsp;</entry>
+              <entry>class</entry>
+            </row><row><entry spanname="descr">The RF_TUNER class
+descriptor. Calling &VIDIOC-QUERYCTRL; for this control will return a
+description of this control class.</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH_AUTO</constant>&nbsp;</entry>
+              <entry>boolean</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Enables/disables tuner radio channel
+bandwidth configuration. In automatic mode bandwidth configuration is performed
+by the driver.</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_BANDWIDTH</constant>&nbsp;</entry>
+              <entry>integer</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Filter(s) on tuner signal path are used to
+filter signal according to receiving party needs. Driver configures filters to
+fulfill desired bandwidth requirement. Used when V4L2_CID_RF_TUNER_BANDWIDTH_AUTO is not
+set. Unit is in Hz. The range and step are driver-specific.</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant>&nbsp;</entry>
+              <entry>boolean</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Enables/disables LNA automatic gain control (AGC)</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant>&nbsp;</entry>
+              <entry>boolean</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Enables/disables mixer automatic gain control (AGC)</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant>&nbsp;</entry>
+              <entry>boolean</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant>&nbsp;</entry>
+              <entry>integer</entry>
+            </row>
+            <row>
+              <entry spanname="descr">LNA (low noise amplifier) gain is first
+gain stage on the RF tuner signal path. It is located very close to tuner
+antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set.
+The range and step are driver-specific.</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_MIXER_GAIN</constant>&nbsp;</entry>
+              <entry>integer</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Mixer gain is second gain stage on the RF
+tuner signal path. It is located inside mixer block, where RF signal is
+down-converted by the mixer. Used when <constant>V4L2_CID_RF_TUNER_MIXER_GAIN_AUTO</constant>
+is not set. The range and step are driver-specific.</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_IF_GAIN</constant>&nbsp;</entry>
+              <entry>integer</entry>
+            </row>
+            <row>
+              <entry spanname="descr">IF gain is last gain stage on the RF tuner
+signal path. It is located on output of RF tuner. It controls signal level of
+intermediate frequency output or baseband output. Used when
+<constant>V4L2_CID_RF_TUNER_IF_GAIN_AUTO</constant> is not set. The range and step are
+driver-specific.</entry>
+            </row>
+            <row>
+              <entry spanname="id"><constant>V4L2_CID_RF_TUNER_PLL_LOCK</constant>&nbsp;</entry>
+              <entry>boolean</entry>
+            </row>
+            <row>
+              <entry spanname="descr">Is synthesizer PLL locked? RF tuner is
+receiving given frequency when that control is set. This is a read-only control.
+</entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </table>
+    </section>
 </section>
diff --git a/Documentation/DocBook/media/v4l/dev-osd.xml b/Documentation/DocBook/media/v4l/dev-osd.xml
index dd91d6134e8c..54853329140b 100644
--- a/Documentation/DocBook/media/v4l/dev-osd.xml
+++ b/Documentation/DocBook/media/v4l/dev-osd.xml
@@ -56,18 +56,18 @@ framebuffer device.</para>
 unsigned int i;
 int fb_fd;
 
-if (-1 == ioctl (fd, VIDIOC_G_FBUF, &amp;fbuf)) {
-        perror ("VIDIOC_G_FBUF");
-        exit (EXIT_FAILURE);
+if (-1 == ioctl(fd, VIDIOC_G_FBUF, &amp;fbuf)) {
+        perror("VIDIOC_G_FBUF");
+        exit(EXIT_FAILURE);
 }
 
-for (i = 0; i &gt; 30; ++i) {
+for (i = 0; i &lt; 30; i++) {
         char dev_name[16];
         struct fb_fix_screeninfo si;
 
-        snprintf (dev_name, sizeof (dev_name), "/dev/fb%u", i);
+        snprintf(dev_name, sizeof(dev_name), "/dev/fb%u", i);
 
-        fb_fd = open (dev_name, O_RDWR);
+        fb_fd = open(dev_name, O_RDWR);
         if (-1 == fb_fd) {
                 switch (errno) {
                 case ENOENT: /* no such file */
@@ -75,19 +75,19 @@ for (i = 0; i &gt; 30; ++i) {
                         continue;
 
                 default:
-                        perror ("open");
-                        exit (EXIT_FAILURE);
+                        perror("open");
+                        exit(EXIT_FAILURE);
                 }
         }
 
-        if (0 == ioctl (fb_fd, FBIOGET_FSCREENINFO, &amp;si)) {
-                if (si.smem_start == (unsigned long) fbuf.base)
+        if (0 == ioctl(fb_fd, FBIOGET_FSCREENINFO, &amp;si)) {
+                if (si.smem_start == (unsigned long)fbuf.base)
                         break;
         } else {
                 /* Apparently not a framebuffer device. */
         }
 
-        close (fb_fd);
+        close(fb_fd);
         fb_fd = -1;
 }
 
diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml b/Documentation/DocBook/media/v4l/dev-sdr.xml
new file mode 100644
index 000000000000..dc14804f5436
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/dev-sdr.xml
@@ -0,0 +1,110 @@
+  <title>Software Defined Radio Interface (SDR)</title>
+
+  <note>
+    <title>Experimental</title>
+    <para>This is an <link linkend="experimental"> experimental </link>
+    interface and may change in the future.</para>
+  </note>
+
+  <para>
+SDR is an abbreviation of Software Defined Radio, the radio device
+which uses application software for modulation or demodulation. This interface
+is intended for controlling and data streaming of such devices.
+  </para>
+
+  <para>
+SDR devices are accessed through character device special files named
+<filename>/dev/swradio0</filename> to <filename>/dev/swradio255</filename>
+with major number 81 and dynamically allocated minor numbers 0 to 255.
+  </para>
+
+  <section>
+    <title>Querying Capabilities</title>
+
+    <para>
+Devices supporting the SDR receiver interface set the
+<constant>V4L2_CAP_SDR_CAPTURE</constant> and
+<constant>V4L2_CAP_TUNER</constant> flag in the
+<structfield>capabilities</structfield> field of &v4l2-capability;
+returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an
+Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver.
+At least one of the read/write, streaming or asynchronous I/O methods must
+be supported.
+    </para>
+  </section>
+
+  <section>
+    <title>Supplemental Functions</title>
+
+    <para>
+SDR devices can support <link linkend="control">controls</link>, and must
+support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used
+for setting the ADC sampling rate (sampling frequency) and the possible RF tuner
+frequency.
+    </para>
+
+    <para>
+The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and
+the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The
+tuner index of the RF tuner (if any) must always follow the ADC tuner index.
+Normally the ADC tuner is #0 and the RF tuner is #1.
+    </para>
+
+    <para>
+The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported.
+    </para>
+  </section>
+
+  <section>
+    <title>Data Format Negotiation</title>
+
+    <para>
+The SDR capture device uses the <link linkend="format">format</link> ioctls to
+select the capture format. Both the sampling resolution and the data streaming
+format are bound to that selectable format. In addition to the basic
+<link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl
+must be supported as well.
+    </para>
+
+    <para>
+To use the <link linkend="format">format</link> ioctls applications set the
+<structfield>type</structfield> field of a &v4l2-format; to
+<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format;
+<structfield>sdr</structfield> member of the <structfield>fmt</structfield>
+union as needed per the desired operation.
+Currently only the <structfield>pixelformat</structfield> field of
+&v4l2-sdr-format; is used. The content of that field is the V4L2 fourcc code
+of the data format.
+    </para>
+
+    <table pgwide="1" frame="none" id="v4l2-sdr-format">
+      <title>struct <structname>v4l2_sdr_format</structname></title>
+      <tgroup cols="3">
+        &cs-str;
+        <tbody valign="top">
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>pixelformat</structfield></entry>
+            <entry>
+The data format or type of compression, set by the application. This is a
+little endian <link linkend="v4l2-fourcc">four character code</link>.
+V4L2 defines SDR formats in <xref linkend="sdr-formats" />.
+           </entry>
+          </row>
+          <row>
+            <entry>__u8</entry>
+            <entry><structfield>reserved[28]</structfield></entry>
+            <entry>This array is reserved for future extensions.
+Drivers and applications must set it to zero.</entry>
+          </row>
+        </tbody>
+      </tgroup>
+    </table>
+
+    <para>
+An SDR device may support <link linkend="rw">read/write</link>
+and/or streaming (<link linkend="mmap">memory mapping</link>
+or <link linkend="userp">user pointer</link>) I/O.
+    </para>
+
+  </section>
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 2c4c068dde83..97a69bf6f3eb 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -339,8 +339,8 @@ returns immediately with an &EAGAIN; when no buffer is available. The
 queues 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>
+<structfield>timestamp</structfield> of captured or outputted buffers.
+</para>
 
     <para>Drivers implementing memory mapping I/O must
 support the <constant>VIDIOC_REQBUFS</constant>,
@@ -457,7 +457,7 @@ 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>
+or outputted buffers.</para>
 
     <para>Drivers implementing user pointer I/O must
 support the <constant>VIDIOC_REQBUFS</constant>,
@@ -620,8 +620,7 @@ returns immediately with an &EAGAIN; when no buffer is available. The
 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>
+<structfield>timestamp</structfield> of captured or outputted buffers.</para>
 
     <para>Drivers implementing DMABUF importing I/O must support the
 <constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
@@ -654,38 +653,19 @@ plane, are stored in struct <structname>v4l2_plane</structname> instead.
 In that case, struct <structname>v4l2_buffer</structname> contains an array of
 plane structures.</para>
 
-      <para>Nominally timestamps refer to the first data byte transmitted.
-In practice however the wide range of hardware covered by the V4L2 API
-limits timestamp accuracy. Often an interrupt routine will
-sample the system clock shortly after the field or frame was stored
-completely in memory. So applications must expect a constant
-difference up to one field or frame period plus a small (few scan
-lines) random error. The delay and error can be much
-larger due to compression or transmission over an external bus when
-the frames are not properly stamped by the sender. This is frequently
-the case with USB cameras. Here timestamps refer to the instant the
-field or frame was received by the driver, not the capture time. These
-devices identify by not enumerating any video standards, see <xref
-linkend="standard" />.</para>
-
-      <para>Similar limitations apply to output timestamps. Typically
-the video hardware locks to a clock controlling the video timing, the
-horizontal and vertical synchronization pulses. At some point in the
-line sequence, possibly the vertical blanking, an interrupt routine
-samples the system clock, compares against the timestamp and programs
-the hardware to repeat the previous field or frame, or to display the
-buffer contents.</para>
-
-      <para>Apart of limitations of the video device and natural
-inaccuracies of all clocks, it should be noted system time itself is
-not perfectly stable. It can be affected by power saving cycles,
-warped to insert leap seconds, or even turned back or forth by the
-system administrator affecting long term measurements. <footnote>
-          <para>Since no other Linux multimedia
-API supports unadjusted time it would be foolish to introduce here. We
-must use a universally supported clock to synchronize different media,
-hence time of day.</para>
-        </footnote></para>
+    <para>Dequeued video buffers come with timestamps. The driver
+    decides at which part of the frame and with which clock the
+    timestamp is taken. Please see flags in the masks
+    <constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant> and
+    <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> in <xref
+    linkend="buffer-flags" />. These flags are always valid and constant
+    across all buffers during the whole video stream. Changes in these
+    flags may take place as a side effect of &VIDIOC-S-INPUT; or
+    &VIDIOC-S-OUTPUT; however. The
+    <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> timestamp type
+    which is used by e.g. on mem-to-mem devices is an exception to the
+    rule: the timestamp source flags are copied from the OUTPUT video
+    buffer to the CAPTURE video buffer.</para>
 
     <table frame="none" pgwide="1" id="v4l2-buffer">
       <title>struct <structname>v4l2_buffer</structname></title>
@@ -696,10 +676,11 @@ hence time of day.</para>
             <entry>__u32</entry>
             <entry><structfield>index</structfield></entry>
             <entry></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; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>) minus one.</entry>
+            <entry>Number of the buffer, set by the application except
+when calling &VIDIOC-DQBUF;, then it is set by the driver.
+This field can range from zero to the number of buffers allocated
+with the &VIDIOC-REQBUFS; ioctl (&v4l2-requestbuffers; <structfield>count</structfield>),
+plus any buffers allocated with &VIDIOC-CREATE-BUFS; minus one.</entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -718,7 +699,7 @@ linkend="v4l2-buf-type" /></entry>
 buffer. It depends on the negotiated data format and may change with
 each buffer for compressed variable size data like JPEG images.
 Drivers must set this field when <structfield>type</structfield>
-refers to an input stream, applications when an output stream.</entry>
+refers to an input stream, applications when it refers to an output stream.</entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -735,7 +716,7 @@ linkend="buffer-flags" />.</entry>
 buffer, see <xref linkend="v4l2-field" />. This field is not used when
 the buffer contains VBI data. Drivers must set it when
 <structfield>type</structfield> refers to an input stream,
-applications when an output stream.</entry>
+applications when it refers to an output stream.</entry>
           </row>
           <row>
             <entry>struct timeval</entry>
@@ -745,15 +726,13 @@ applications when an output stream.</entry>
             byte was captured, as returned by the
             <function>clock_gettime()</function> function for the relevant
             clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
-            <xref linkend="buffer-flags" />. For output streams the data
-            will not be displayed before this time, secondary to the nominal
-            frame rate determined by the current video standard in enqueued
-            order. Applications can for example zero this field to display
-            frames as soon as possible. The driver stores the time at which
-            the first data byte was actually sent out in the
-            <structfield>timestamp</structfield> field. This permits
+            <xref linkend="buffer-flags" />. For output streams the driver
+            stores the time at which the last data byte was actually sent out
+            in the  <structfield>timestamp</structfield> field. This permits
             applications to monitor the drift between the video and system
-            clock.</para></entry>
+            clock. For output streams that use <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant>
+            the application has to fill in the timestamp which will be copied
+            by the driver to the capture stream.</para></entry>
           </row>
           <row>
             <entry>&v4l2-timecode;</entry>
@@ -846,7 +825,8 @@ is the file descriptor associated with a DMABUF buffer.</entry>
             <entry><structfield>length</structfield></entry>
             <entry></entry>
             <entry>Size of the buffer (not the payload) in bytes for the
-            single-planar API. For the multi-planar API the application sets
+            single-planar API. This is set by the driver based on the calls to
+            &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;. For the multi-planar API the application sets
             this to the number of elements in the <structfield>planes</structfield>
             array. The driver will fill in the actual number of valid elements in
             that array.
@@ -880,13 +860,15 @@ should set this to 0.</entry>
             <entry><structfield>bytesused</structfield></entry>
             <entry></entry>
             <entry>The number of bytes occupied by data in the plane
-            (its payload).</entry>
+              (its payload). Drivers must set this field when <structfield>type</structfield>
+              refers to an input stream, applications when it refers to an output stream.</entry>
           </row>
           <row>
             <entry>__u32</entry>
             <entry><structfield>length</structfield></entry>
             <entry></entry>
-            <entry>Size in bytes of the plane (not its payload).</entry>
+            <entry>Size in bytes of the plane (not its payload). This is set by the driver
+            based on the calls to &VIDIOC-REQBUFS; and/or &VIDIOC-CREATE-BUFS;.</entry>
           </row>
           <row>
             <entry>union</entry>
@@ -925,7 +907,9 @@ should set this to 0.</entry>
             <entry>__u32</entry>
             <entry><structfield>data_offset</structfield></entry>
             <entry></entry>
-            <entry>Offset in bytes to video data in the plane, if applicable.
+            <entry>Offset in bytes to video data in the plane.
+              Drivers must set this field when <structfield>type</structfield>
+              refers to an input stream, applications when it refers to an output stream.
             </entry>
           </row>
           <row>
@@ -1005,6 +989,12 @@ should set this to 0.</entry>
             <entry>Buffer for video output overlay (OSD), see <xref
                 linkend="osd" />.</entry>
           </row>
+          <row>
+            <entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry>
+            <entry>11</entry>
+            <entry>Buffer for Software Defined Radio (SDR), see <xref
+                linkend="sdr" />.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
@@ -1016,7 +1006,7 @@ should set this to 0.</entry>
         <tbody valign="top">
           <row>
             <entry><constant>V4L2_BUF_FLAG_MAPPED</constant></entry>
-            <entry>0x0001</entry>
+            <entry>0x00000001</entry>
             <entry>The buffer resides in device memory and has been mapped
 into the application's address space, see <xref linkend="mmap" /> for details.
 Drivers set or clear this flag when the
@@ -1026,7 +1016,7 @@ Drivers set or clear this flag when the
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_QUEUED</constant></entry>
-            <entry>0x0002</entry>
+            <entry>0x00000002</entry>
           <entry>Internally drivers maintain two buffer queues, an
 incoming and outgoing queue. When this flag is set, the buffer is
 currently on the incoming queue. It automatically moves to the
@@ -1039,7 +1029,7 @@ cleared.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_DONE</constant></entry>
-            <entry>0x0004</entry>
+            <entry>0x00000004</entry>
             <entry>When this flag is set, the buffer is currently on
 the outgoing queue, ready to be dequeued from the driver. Drivers set
 or clear this flag when the <constant>VIDIOC_QUERYBUF</constant> ioctl
@@ -1049,11 +1039,11 @@ buffer cannot be on both queues at the same time, the
 <constant>V4L2_BUF_FLAG_QUEUED</constant> and
 <constant>V4L2_BUF_FLAG_DONE</constant> flag are mutually exclusive.
 They can be both cleared however, then the buffer is in "dequeued"
-state, in the application domain to say so.</entry>
+state, in the application domain so to say.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_ERROR</constant></entry>
-            <entry>0x0040</entry>
+            <entry>0x00000040</entry>
             <entry>When this flag is set, the buffer has been dequeued
             successfully, although the data might have been corrupted.
             This is recoverable, streaming may continue as normal and
@@ -1063,35 +1053,43 @@ state, in the application domain to say so.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_KEYFRAME</constant></entry>
-            <entry>0x0008</entry>
+            <entry>0x00000008</entry>
           <entry>Drivers set or clear this flag when calling the
 <constant>VIDIOC_DQBUF</constant> ioctl. It may be set by video
 capture devices when the buffer contains a compressed image which is a
-key frame (or field), &ie; can be decompressed on its own.</entry>
+key frame (or field), &ie; can be decompressed on its own. Also know as
+an I-frame.  Applications can set this bit when <structfield>type</structfield>
+refers to an output stream.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_PFRAME</constant></entry>
-            <entry>0x0010</entry>
+            <entry>0x00000010</entry>
             <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant>
 this flags predicted frames or fields which contain only differences to a
-previous key frame.</entry>
+previous key frame. Applications can set this bit when <structfield>type</structfield>
+refers to an output stream.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_BFRAME</constant></entry>
-            <entry>0x0020</entry>
-            <entry>Similar to <constant>V4L2_BUF_FLAG_PFRAME</constant>
-        this is a bidirectional predicted frame or field. [ooc tbd]</entry>
+            <entry>0x00000020</entry>
+            <entry>Similar to <constant>V4L2_BUF_FLAG_KEYFRAME</constant>
+this flags a bi-directional predicted frame or field which contains only
+the differences between the current frame and both the preceding and following
+key frames to specify its content. Applications can set this bit when
+<structfield>type</structfield> refers to an output stream.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_TIMECODE</constant></entry>
-            <entry>0x0100</entry>
+            <entry>0x00000100</entry>
             <entry>The <structfield>timecode</structfield> field is valid.
 Drivers set or clear this flag when the <constant>VIDIOC_DQBUF</constant>
-ioctl is called.</entry>
+ioctl is called.  Applications can set this bit and the corresponding
+<structfield>timecode</structfield> structure when <structfield>type</structfield>
+refers to an output stream.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_PREPARED</constant></entry>
-            <entry>0x0400</entry>
+            <entry>0x00000400</entry>
             <entry>The buffer has been prepared for I/O and can be queued by the
 application. Drivers set or clear this flag when the
 <link linkend="vidioc-querybuf">VIDIOC_QUERYBUF</link>, <link
@@ -1101,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>0x0800</entry>
+            <entry>0x00000800</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
@@ -1110,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>0x1000</entry>
+            <entry>0x00001000</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,
@@ -1118,7 +1116,7 @@ in which case caches have not been used.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
-            <entry>0xe000</entry>
+            <entry>0x0000e000</entry>
             <entry>Mask for timestamp types below. To test the
             timestamp type, mask out bits not belonging to timestamp
             type by performing a logical and operation with buffer
@@ -1126,7 +1124,7 @@ in which case caches have not been used.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
-            <entry>0x0000</entry>
+            <entry>0x00000000</entry>
             <entry>Unknown timestamp type. This type is used by
             drivers before Linux 3.9 and may be either monotonic (see
             below) or realtime (wall clock). Monotonic clock has been
@@ -1139,7 +1137,7 @@ in which case caches have not been used.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
-            <entry>0x2000</entry>
+            <entry>0x00002000</entry>
             <entry>The buffer timestamp has been taken from the
             <constant>CLOCK_MONOTONIC</constant> clock. To access the
             same clock outside V4L2, use
@@ -1147,10 +1145,42 @@ in which case caches have not been used.</entry>
           </row>
           <row>
             <entry><constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant></entry>
-            <entry>0x4000</entry>
+            <entry>0x00004000</entry>
             <entry>The CAPTURE buffer timestamp has been taken from the
             corresponding OUTPUT buffer. This flag applies only to mem2mem devices.</entry>
           </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant></entry>
+            <entry>0x00070000</entry>
+            <entry>Mask for timestamp sources below. The timestamp source
+            defines the point of time the timestamp is taken in relation to
+            the frame. Logical 'and' operation between the
+            <structfield>flags</structfield> field and
+            <constant>V4L2_BUF_FLAG_TSTAMP_SRC_MASK</constant> produces the
+            value of the timestamp source. Applications must set the timestamp
+            source when <structfield>type</structfield> refers to an output stream
+            and <constant>V4L2_BUF_FLAG_TIMESTAMP_COPY</constant> is set.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_EOF</constant></entry>
+            <entry>0x00000000</entry>
+            <entry>End Of Frame. The buffer timestamp has been taken
+            when the last pixel of the frame has been received or the
+            last pixel of the frame has been transmitted. In practice,
+            software generated timestamps will typically be read from
+            the clock a small amount of time after the last pixel has
+            been received or transmitten, depending on the system and
+            other activity in it.</entry>
+          </row>
+          <row>
+            <entry><constant>V4L2_BUF_FLAG_TSTAMP_SRC_SOE</constant></entry>
+            <entry>0x00010000</entry>
+            <entry>Start Of Exposure. The buffer timestamp has been
+            taken when the exposure of the frame has begun. This is
+            only valid for the
+            <constant>V4L2_BUF_TYPE_VIDEO_CAPTURE</constant> buffer
+            type.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
@@ -1440,10 +1470,9 @@ or application, depending on data direction, must set &v4l2-buffer;
 <constant>V4L2_FIELD_BOTTOM</constant>. Any two successive fields pair
 to build a frame. If fields are successive, without any dropped fields
 between them (fields can drop individually), can be determined from
-the &v4l2-buffer; <structfield>sequence</structfield> field. Image
-sizes refer to the frame, not fields. This format cannot be selected
-when using the read/write I/O method.<!-- Where it's indistinguishable
-from V4L2_FIELD_SEQ_*. --></entry>
+the &v4l2-buffer; <structfield>sequence</structfield> field. This format
+cannot be selected when using the read/write I/O method since there
+is no way to communicate if a field was a top or bottom field.</entry>
           </row>
           <row>
             <entry><constant>V4L2_FIELD_INTERLACED_TB</constant></entry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
index c51d5a4cda09..fb2b5e35d665 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv16m.xml
@@ -12,18 +12,17 @@
       <refsect1>
         <title>Description</title>
 
-        <para>This is a multi-planar, two-plane version of the YUV 4:2:0 format.
+        <para>This is a multi-planar, two-plane version of the YUV 4:2:2 format.
 The three components are separated into two sub-images or planes.
 <constant>V4L2_PIX_FMT_NV16M</constant> differs from <constant>V4L2_PIX_FMT_NV16
 </constant> in that the two planes are non-contiguous in memory, i.e. the chroma
-plane does not necessarily immediately follows the luma plane.
+plane does not necessarily immediately follow the luma plane.
 The luminance data occupies the first plane. The Y plane has one byte per pixel.
 In the second plane there is chrominance data with alternating chroma samples.
 The CbCr plane is the same width and height, in bytes, as the Y plane.
-Each CbCr pair belongs to four pixels. For example,
+Each CbCr pair belongs to two pixels. For example,
 Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
-Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
-Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.
+Y'<subscript>00</subscript>, Y'<subscript>01</subscript>.
 <constant>V4L2_PIX_FMT_NV61M</constant> is the same as <constant>V4L2_PIX_FMT_NV16M</constant>
 except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>
 
diff --git a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
index 166c8d65e4f7..e1c4f8b4c0b3 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -121,14 +121,14 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry>
             <entry>'RGB1'</entry>
             <entry></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
             <entry>r<subscript>2</subscript></entry>
             <entry>r<subscript>1</subscript></entry>
             <entry>r<subscript>0</subscript></entry>
+            <entry>g<subscript>2</subscript></entry>
+            <entry>g<subscript>1</subscript></entry>
+            <entry>g<subscript>0</subscript></entry>
+            <entry>b<subscript>1</subscript></entry>
+            <entry>b<subscript>0</subscript></entry>
           </row>
           <row id="V4L2-PIX-FMT-RGB444">
             <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry>
@@ -159,18 +159,18 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry>g<subscript>2</subscript></entry>
             <entry>g<subscript>1</subscript></entry>
             <entry>g<subscript>0</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>a</entry>
             <entry>b<subscript>4</subscript></entry>
             <entry>b<subscript>3</subscript></entry>
             <entry>b<subscript>2</subscript></entry>
             <entry>b<subscript>1</subscript></entry>
             <entry>b<subscript>0</subscript></entry>
+            <entry></entry>
+            <entry>a</entry>
+            <entry>r<subscript>4</subscript></entry>
+            <entry>r<subscript>3</subscript></entry>
+            <entry>r<subscript>2</subscript></entry>
+            <entry>r<subscript>1</subscript></entry>
+            <entry>r<subscript>0</subscript></entry>
             <entry>g<subscript>4</subscript></entry>
             <entry>g<subscript>3</subscript></entry>
           </row>
@@ -181,17 +181,17 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry>g<subscript>2</subscript></entry>
             <entry>g<subscript>1</subscript></entry>
             <entry>g<subscript>0</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry></entry>
             <entry>b<subscript>4</subscript></entry>
             <entry>b<subscript>3</subscript></entry>
             <entry>b<subscript>2</subscript></entry>
             <entry>b<subscript>1</subscript></entry>
             <entry>b<subscript>0</subscript></entry>
+            <entry></entry>
+            <entry>r<subscript>4</subscript></entry>
+            <entry>r<subscript>3</subscript></entry>
+            <entry>r<subscript>2</subscript></entry>
+            <entry>r<subscript>1</subscript></entry>
+            <entry>r<subscript>0</subscript></entry>
             <entry>g<subscript>5</subscript></entry>
             <entry>g<subscript>4</subscript></entry>
             <entry>g<subscript>3</subscript></entry>
@@ -201,32 +201,32 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry>'RGBQ'</entry>
             <entry></entry>
             <entry>a</entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
             <entry>r<subscript>4</subscript></entry>
             <entry>r<subscript>3</subscript></entry>
             <entry>r<subscript>2</subscript></entry>
             <entry>r<subscript>1</subscript></entry>
             <entry>r<subscript>0</subscript></entry>
-          </row>
-          <row id="V4L2-PIX-FMT-RGB565X">
-            <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry>
-            <entry>'RGBR'</entry>
+            <entry>g<subscript>4</subscript></entry>
+            <entry>g<subscript>3</subscript></entry>
             <entry></entry>
+            <entry>g<subscript>2</subscript></entry>
+            <entry>g<subscript>1</subscript></entry>
+            <entry>g<subscript>0</subscript></entry>
             <entry>b<subscript>4</subscript></entry>
             <entry>b<subscript>3</subscript></entry>
             <entry>b<subscript>2</subscript></entry>
             <entry>b<subscript>1</subscript></entry>
             <entry>b<subscript>0</subscript></entry>
+          </row>
+          <row id="V4L2-PIX-FMT-RGB565X">
+            <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry>
+            <entry>'RGBR'</entry>
+            <entry></entry>
+            <entry>r<subscript>4</subscript></entry>
+            <entry>r<subscript>3</subscript></entry>
+            <entry>r<subscript>2</subscript></entry>
+            <entry>r<subscript>1</subscript></entry>
+            <entry>r<subscript>0</subscript></entry>
             <entry>g<subscript>5</subscript></entry>
             <entry>g<subscript>4</subscript></entry>
             <entry>g<subscript>3</subscript></entry>
@@ -234,11 +234,11 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry>g<subscript>2</subscript></entry>
             <entry>g<subscript>1</subscript></entry>
             <entry>g<subscript>0</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
+            <entry>b<subscript>4</subscript></entry>
+            <entry>b<subscript>3</subscript></entry>
+            <entry>b<subscript>2</subscript></entry>
+            <entry>b<subscript>1</subscript></entry>
+            <entry>b<subscript>0</subscript></entry>
           </row>
           <row id="V4L2-PIX-FMT-BGR666">
             <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
@@ -385,6 +385,15 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry>
             <entry>'RGB4'</entry>
             <entry></entry>
+            <entry>a<subscript>7</subscript></entry>
+            <entry>a<subscript>6</subscript></entry>
+            <entry>a<subscript>5</subscript></entry>
+            <entry>a<subscript>4</subscript></entry>
+            <entry>a<subscript>3</subscript></entry>
+            <entry>a<subscript>2</subscript></entry>
+            <entry>a<subscript>1</subscript></entry>
+            <entry>a<subscript>0</subscript></entry>
+            <entry></entry>
             <entry>r<subscript>7</subscript></entry>
             <entry>r<subscript>6</subscript></entry>
             <entry>r<subscript>5</subscript></entry>
@@ -411,25 +420,16 @@ colorspace <constant>V4L2_COLORSPACE_SRGB</constant>.</para>
             <entry>b<subscript>2</subscript></entry>
             <entry>b<subscript>1</subscript></entry>
             <entry>b<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>a<subscript>7</subscript></entry>
-            <entry>a<subscript>6</subscript></entry>
-            <entry>a<subscript>5</subscript></entry>
-            <entry>a<subscript>4</subscript></entry>
-            <entry>a<subscript>3</subscript></entry>
-            <entry>a<subscript>2</subscript></entry>
-            <entry>a<subscript>1</subscript></entry>
-            <entry>a<subscript>0</subscript></entry>
           </row>
         </tbody>
       </tgroup>
     </table>
 
-    <para>Bit 7 is the most significant bit. The value of a = alpha
+    <para>Bit 7 is the most significant bit. The value of the a = alpha
 bits is undefined when reading from the driver, ignored when writing
 to the driver, except when alpha blending has been negotiated for a
 <link linkend="overlay">Video Overlay</link> or <link linkend="osd">
-Video Output Overlay</link> or when alpha component has been configured
+Video Output Overlay</link> or when the alpha component has been configured
 for a <link linkend="capture">Video Capture</link> by means of <link
 linkend="v4l2-alpha-component"> <constant>V4L2_CID_ALPHA_COMPONENT
 </constant> </link> control.</para>
@@ -512,421 +512,6 @@ image</title>
       </formalpara>
     </example>
 
-    <important>
-      <para>Drivers may interpret these formats differently.</para>
-    </important>
-
-    <para>Some RGB formats above are uncommon and were probably
-defined in error. Drivers may interpret them as in <xref
-        linkend="rgb-formats-corrected" />.</para>
-
-    <table pgwide="1" frame="none" id="rgb-formats-corrected">
-      <title>Packed RGB Image Formats (corrected)</title>
-      <tgroup cols="37" align="center">
-        <colspec colname="id" align="left" />
-        <colspec colname="fourcc" />
-        <colspec colname="bit" />
-
-        <colspec colnum="4" colname="b07" align="center" />
-        <colspec colnum="5" colname="b06" align="center" />
-        <colspec colnum="6" colname="b05" align="center" />
-        <colspec colnum="7" colname="b04" align="center" />
-        <colspec colnum="8" colname="b03" align="center" />
-        <colspec colnum="9" colname="b02" align="center" />
-        <colspec colnum="10" colname="b01" align="center" />
-        <colspec colnum="11" colname="b00" align="center" />
-
-        <colspec colnum="13" colname="b17" align="center" />
-        <colspec colnum="14" colname="b16" align="center" />
-        <colspec colnum="15" colname="b15" align="center" />
-        <colspec colnum="16" colname="b14" align="center" />
-        <colspec colnum="17" colname="b13" align="center" />
-        <colspec colnum="18" colname="b12" align="center" />
-        <colspec colnum="19" colname="b11" align="center" />
-        <colspec colnum="20" colname="b10" align="center" />
-
-        <colspec colnum="22" colname="b27" align="center" />
-        <colspec colnum="23" colname="b26" align="center" />
-        <colspec colnum="24" colname="b25" align="center" />
-        <colspec colnum="25" colname="b24" align="center" />
-        <colspec colnum="26" colname="b23" align="center" />
-        <colspec colnum="27" colname="b22" align="center" />
-        <colspec colnum="28" colname="b21" align="center" />
-        <colspec colnum="29" colname="b20" align="center" />
-
-        <colspec colnum="31" colname="b37" align="center" />
-        <colspec colnum="32" colname="b36" align="center" />
-        <colspec colnum="33" colname="b35" align="center" />
-        <colspec colnum="34" colname="b34" align="center" />
-        <colspec colnum="35" colname="b33" align="center" />
-        <colspec colnum="36" colname="b32" align="center" />
-        <colspec colnum="37" colname="b31" align="center" />
-        <colspec colnum="38" colname="b30" align="center" />
-
-        <spanspec namest="b07" nameend="b00" spanname="b0" />
-        <spanspec namest="b17" nameend="b10" spanname="b1" />
-        <spanspec namest="b27" nameend="b20" spanname="b2" />
-        <spanspec namest="b37" nameend="b30" spanname="b3" />
-        <thead>
-          <row>
-            <entry>Identifier</entry>
-            <entry>Code</entry>
-            <entry>&nbsp;</entry>
-            <entry spanname="b0">Byte&nbsp;0 in memory</entry>
-            <entry spanname="b1">Byte&nbsp;1</entry>
-            <entry spanname="b2">Byte&nbsp;2</entry>
-            <entry spanname="b3">Byte&nbsp;3</entry>
-          </row>
-          <row>
-            <entry>&nbsp;</entry>
-            <entry>&nbsp;</entry>
-            <entry>Bit</entry>
-            <entry>7</entry>
-            <entry>6</entry>
-            <entry>5</entry>
-            <entry>4</entry>
-            <entry>3</entry>
-            <entry>2</entry>
-            <entry>1</entry>
-            <entry>0</entry>
-            <entry>&nbsp;</entry>
-            <entry>7</entry>
-            <entry>6</entry>
-            <entry>5</entry>
-            <entry>4</entry>
-            <entry>3</entry>
-            <entry>2</entry>
-            <entry>1</entry>
-            <entry>0</entry>
-            <entry>&nbsp;</entry>
-            <entry>7</entry>
-            <entry>6</entry>
-            <entry>5</entry>
-            <entry>4</entry>
-            <entry>3</entry>
-            <entry>2</entry>
-            <entry>1</entry>
-            <entry>0</entry>
-            <entry>&nbsp;</entry>
-            <entry>7</entry>
-            <entry>6</entry>
-            <entry>5</entry>
-            <entry>4</entry>
-            <entry>3</entry>
-            <entry>2</entry>
-            <entry>1</entry>
-            <entry>0</entry>
-          </row>
-        </thead>
-        <tbody valign="top">
-          <row><!-- id="V4L2-PIX-FMT-RGB332" -->
-            <entry><constant>V4L2_PIX_FMT_RGB332</constant></entry>
-            <entry>'RGB1'</entry>
-            <entry></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB444" -->
-            <entry><constant>V4L2_PIX_FMT_RGB444</constant></entry>
-            <entry>'R444'</entry>
-            <entry></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>a<subscript>3</subscript></entry>
-            <entry>a<subscript>2</subscript></entry>
-            <entry>a<subscript>1</subscript></entry>
-            <entry>a<subscript>0</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB555" -->
-            <entry><constant>V4L2_PIX_FMT_RGB555</constant></entry>
-            <entry>'RGBO'</entry>
-            <entry></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>a</entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB565" -->
-            <entry><constant>V4L2_PIX_FMT_RGB565</constant></entry>
-            <entry>'RGBP'</entry>
-            <entry></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB555X" -->
-            <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry>
-            <entry>'RGBQ'</entry>
-            <entry></entry>
-            <entry>a</entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB565X" -->
-            <entry><constant>V4L2_PIX_FMT_RGB565X</constant></entry>
-            <entry>'RGBR'</entry>
-            <entry></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-BGR666" -->
-            <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
-            <entry>'BGRH'</entry>
-            <entry></entry>
-            <entry>b<subscript>5</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry>r<subscript>5</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-            <entry></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-BGR24" -->
-            <entry><constant>V4L2_PIX_FMT_BGR24</constant></entry>
-            <entry>'BGR3'</entry>
-            <entry></entry>
-            <entry>b<subscript>7</subscript></entry>
-            <entry>b<subscript>6</subscript></entry>
-            <entry>b<subscript>5</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>7</subscript></entry>
-            <entry>g<subscript>6</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>r<subscript>7</subscript></entry>
-            <entry>r<subscript>6</subscript></entry>
-            <entry>r<subscript>5</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB24" -->
-            <entry><constant>V4L2_PIX_FMT_RGB24</constant></entry>
-            <entry>'RGB3'</entry>
-            <entry></entry>
-            <entry>r<subscript>7</subscript></entry>
-            <entry>r<subscript>6</subscript></entry>
-            <entry>r<subscript>5</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>7</subscript></entry>
-            <entry>g<subscript>6</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>b<subscript>7</subscript></entry>
-            <entry>b<subscript>6</subscript></entry>
-            <entry>b<subscript>5</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-BGR32" -->
-            <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry>
-            <entry>'BGR4'</entry>
-            <entry></entry>
-            <entry>b<subscript>7</subscript></entry>
-            <entry>b<subscript>6</subscript></entry>
-            <entry>b<subscript>5</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>7</subscript></entry>
-            <entry>g<subscript>6</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>r<subscript>7</subscript></entry>
-            <entry>r<subscript>6</subscript></entry>
-            <entry>r<subscript>5</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>a<subscript>7</subscript></entry>
-            <entry>a<subscript>6</subscript></entry>
-            <entry>a<subscript>5</subscript></entry>
-            <entry>a<subscript>4</subscript></entry>
-            <entry>a<subscript>3</subscript></entry>
-            <entry>a<subscript>2</subscript></entry>
-            <entry>a<subscript>1</subscript></entry>
-            <entry>a<subscript>0</subscript></entry>
-          </row>
-          <row><!-- id="V4L2-PIX-FMT-RGB32" -->
-            <entry><constant>V4L2_PIX_FMT_RGB32</constant></entry>
-            <entry>'RGB4'</entry>
-            <entry></entry>
-            <entry>a<subscript>7</subscript></entry>
-            <entry>a<subscript>6</subscript></entry>
-            <entry>a<subscript>5</subscript></entry>
-            <entry>a<subscript>4</subscript></entry>
-            <entry>a<subscript>3</subscript></entry>
-            <entry>a<subscript>2</subscript></entry>
-            <entry>a<subscript>1</subscript></entry>
-            <entry>a<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>r<subscript>7</subscript></entry>
-            <entry>r<subscript>6</subscript></entry>
-            <entry>r<subscript>5</subscript></entry>
-            <entry>r<subscript>4</subscript></entry>
-            <entry>r<subscript>3</subscript></entry>
-            <entry>r<subscript>2</subscript></entry>
-            <entry>r<subscript>1</subscript></entry>
-            <entry>r<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>g<subscript>7</subscript></entry>
-            <entry>g<subscript>6</subscript></entry>
-            <entry>g<subscript>5</subscript></entry>
-            <entry>g<subscript>4</subscript></entry>
-            <entry>g<subscript>3</subscript></entry>
-            <entry>g<subscript>2</subscript></entry>
-            <entry>g<subscript>1</subscript></entry>
-            <entry>g<subscript>0</subscript></entry>
-            <entry></entry>
-            <entry>b<subscript>7</subscript></entry>
-            <entry>b<subscript>6</subscript></entry>
-            <entry>b<subscript>5</subscript></entry>
-            <entry>b<subscript>4</subscript></entry>
-            <entry>b<subscript>3</subscript></entry>
-            <entry>b<subscript>2</subscript></entry>
-            <entry>b<subscript>1</subscript></entry>
-            <entry>b<subscript>0</subscript></entry>
-          </row>
-        </tbody>
-      </tgroup>
-    </table>
-
     <para>A test utility to determine which RGB formats a driver
 actually supports is available from the LinuxTV v4l-dvb repository.
 See &v4l-dvb; for access instructions.</para>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml
new file mode 100644
index 000000000000..2d80104c178b
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu08.xml
@@ -0,0 +1,44 @@
+<refentry id="V4L2-SDR-FMT-CU08">
+  <refmeta>
+    <refentrytitle>V4L2_SDR_FMT_CU8 ('CU08')</refentrytitle>
+    &manvol;
+  </refmeta>
+    <refnamediv>
+      <refname>
+        <constant>V4L2_SDR_FMT_CU8</constant>
+      </refname>
+      <refpurpose>Complex unsigned 8-bit IQ sample</refpurpose>
+    </refnamediv>
+    <refsect1>
+      <title>Description</title>
+      <para>
+This format contains sequence of complex number samples. Each complex number
+consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
+represented as a 8 bit unsigned number. I value comes first and Q value after
+that.
+      </para>
+    <example>
+      <title><constant>V4L2_SDR_FMT_CU8</constant> 1 sample</title>
+      <formalpara>
+        <title>Byte Order.</title>
+        <para>Each cell is one byte.
+          <informaltable frame="none">
+            <tgroup cols="2" align="center">
+              <colspec align="left" colwidth="2*" />
+              <tbody valign="top">
+                <row>
+                  <entry>start&nbsp;+&nbsp;0:</entry>
+                  <entry>I'<subscript>0</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;1:</entry>
+                  <entry>Q'<subscript>0</subscript></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+        </para>
+      </formalpara>
+    </example>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml
new file mode 100644
index 000000000000..26288ffa9071
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/pixfmt-sdr-cu16le.xml
@@ -0,0 +1,46 @@
+<refentry id="V4L2-SDR-FMT-CU16LE">
+  <refmeta>
+    <refentrytitle>V4L2_SDR_FMT_CU16LE ('CU16')</refentrytitle>
+    &manvol;
+  </refmeta>
+    <refnamediv>
+      <refname>
+        <constant>V4L2_SDR_FMT_CU16LE</constant>
+      </refname>
+      <refpurpose>Complex unsigned 16-bit little endian IQ sample</refpurpose>
+    </refnamediv>
+    <refsect1>
+      <title>Description</title>
+      <para>
+This format contains sequence of complex number samples. Each complex number
+consist two parts, called In-phase and Quadrature (IQ). Both I and Q are
+represented as a 16 bit unsigned little endian number. I value comes first
+and Q value after that.
+      </para>
+    <example>
+      <title><constant>V4L2_SDR_FMT_CU16LE</constant> 1 sample</title>
+      <formalpara>
+        <title>Byte Order.</title>
+        <para>Each cell is one byte.
+          <informaltable frame="none">
+            <tgroup cols="3" align="center">
+              <colspec align="left" colwidth="2*" />
+              <tbody valign="top">
+                <row>
+                  <entry>start&nbsp;+&nbsp;0:</entry>
+                  <entry>I'<subscript>0[7:0]</subscript></entry>
+                  <entry>I'<subscript>0[15:8]</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;2:</entry>
+                  <entry>Q'<subscript>0[7:0]</subscript></entry>
+                  <entry>Q'<subscript>0[15:8]</subscript></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+        </para>
+      </formalpara>
+    </example>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 72d72bd67d0a..ea514d6075c5 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -25,7 +25,12 @@ capturing and output, for overlay frame buffer formats see also
         <row>
           <entry>__u32</entry>
           <entry><structfield>height</structfield></entry>
-          <entry>Image height in pixels.</entry>
+          <entry>Image height in pixels. If <structfield>field</structfield> is
+          one of <constant>V4L2_FIELD_TOP</constant>, <constant>V4L2_FIELD_BOTTOM</constant>
+          or <constant>V4L2_FIELD_ALTERNATE</constant> then height refers to the
+          number of lines in the field, otherwise it refers to the number of
+          lines in the frame (which is twice the field height for interlaced
+          formats).</entry>
         </row>
         <row>
           <entry spanname="hspan">Applications set these fields to
@@ -54,7 +59,7 @@ linkend="reserved-formats" /></entry>
 can request to capture or output only the top or bottom field, or both
 fields interlaced or sequentially stored in one buffer or alternating
 in separate buffers. Drivers return the actual field order selected.
-For details see <xref linkend="field-order" />.</entry>
+For more details on fields see <xref linkend="field-order" />.</entry>
         </row>
         <row>
           <entry>__u32</entry>
@@ -81,7 +86,10 @@ plane and is divided by the same factor as the
 example the Cb and Cr planes of a YUV 4:2:0 image have half as many
 padding bytes following each line as the Y plane. To avoid ambiguities
 drivers must return a <structfield>bytesperline</structfield> value
-rounded up to a multiple of the scale factor.</para></entry>
+rounded up to a multiple of the scale factor.</para>
+<para>For compressed formats the <structfield>bytesperline</structfield>
+value makes no sense. Applications and drivers must set this to 0 in
+that case.</para></entry>
         </row>
         <row>
           <entry>__u32</entry>
@@ -97,7 +105,8 @@ hold an image.</entry>
           <entry>&v4l2-colorspace;</entry>
           <entry><structfield>colorspace</structfield></entry>
           <entry>This information supplements the
-<structfield>pixelformat</structfield> and must be set by the driver,
+<structfield>pixelformat</structfield> and must be set by the driver for
+capture streams and by the application for output streams,
 see <xref linkend="colorspaces" />.</entry>
         </row>
         <row>
@@ -135,7 +144,7 @@ set this field to zero.</entry>
           <entry>__u16</entry>
           <entry><structfield>bytesperline</structfield></entry>
           <entry>Distance in bytes between the leftmost pixels in two adjacent
-            lines.</entry>
+            lines. See &v4l2-pix-format;.</entry>
         </row>
         <row>
           <entry>__u16</entry>
@@ -154,12 +163,12 @@ set this field to zero.</entry>
         <row>
           <entry>__u32</entry>
           <entry><structfield>width</structfield></entry>
-          <entry>Image width in pixels.</entry>
+          <entry>Image width in pixels. See &v4l2-pix-format;.</entry>
         </row>
         <row>
           <entry>__u32</entry>
           <entry><structfield>height</structfield></entry>
-          <entry>Image height in pixels.</entry>
+          <entry>Image height in pixels. See &v4l2-pix-format;.</entry>
         </row>
         <row>
           <entry>__u32</entry>
@@ -811,6 +820,17 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
     </table>
   </section>
 
+  <section id="sdr-formats">
+    <title>SDR Formats</title>
+
+    <para>These formats are used for <link linkend="sdr">SDR Capture</link>
+interface only.</para>
+
+    &sub-sdr-cu08;
+    &sub-sdr-cu16le;
+
+  </section>
+
   <section id="pixfmt-reserved">
     <title>Reserved Format Identifiers</title>
 
diff --git a/Documentation/DocBook/media/v4l/remote_controllers.xml b/Documentation/DocBook/media/v4l/remote_controllers.xml
index 160e464d44b7..5124a6c4daa8 100644
--- a/Documentation/DocBook/media/v4l/remote_controllers.xml
+++ b/Documentation/DocBook/media/v4l/remote_controllers.xml
@@ -1,10 +1,152 @@
+<partinfo>
+<authorgroup>
+<author>
+<firstname>Mauro</firstname>
+<surname>Chehab</surname>
+<othername role="mi">Carvalho</othername>
+<affiliation><address><email>m.chehab@samsung.com</email></address></affiliation>
+<contrib>Initial version.</contrib>
+</author>
+</authorgroup>
+<copyright>
+        <year>2009-2014</year>
+        <holder>Mauro Carvalho Chehab</holder>
+</copyright>
+
+<revhistory>
+<!-- Put document revisions here, newest first. -->
+<revision>
+<revnumber>3.15</revnumber>
+<date>2014-02-06</date>
+<authorinitials>mcc</authorinitials>
+<revremark>Added the interface description and the RC sysfs class description.</revremark>
+</revision>
+<revision>
+<revnumber>1.0</revnumber>
+<date>2009-09-06</date>
+<authorinitials>mcc</authorinitials>
+<revremark>Initial revision</revremark>
+</revision>
+</revhistory>
+</partinfo>
+
+ <title>Remote Controller API</title>
+ <chapter id="remote_controllers">
+
 <title>Remote Controllers</title>
+
 <section id="Remote_controllers_Intro">
 <title>Introduction</title>
 
 <para>Currently, most analog and digital devices have a Infrared input for remote controllers. Each
 manufacturer has their own type of control. It is not rare for the same manufacturer to ship different
 types of controls, depending on the device.</para>
+<para>A Remote Controller interface is mapped as a normal evdev/input interface, just like a keyboard or a mouse.
+So, it uses all ioctls already defined for any other input devices.</para>
+<para>However, remove controllers are more flexible than a normal input device, as the IR
+receiver (and/or transmitter) can be used in conjunction with a wide variety of different IR remotes.</para>
+<para>In order to allow flexibility, the Remote Controller subsystem allows controlling the
+RC-specific attributes via <link linkend="remote_controllers_sysfs_nodes">the sysfs class nodes</link>.</para>
+</section>
+
+<section id="remote_controllers_sysfs_nodes">
+<title>Remote Controller's sysfs nodes</title>
+<para>As defined at <constant>Documentation/ABI/testing/sysfs-class-rc</constant>, those are the sysfs nodes that control the Remote Controllers:</para>
+
+<section id="sys_class_rc">
+<title>/sys/class/rc/</title>
+<para>The <constant>/sys/class/rc/</constant> class sub-directory belongs to the Remote Controller
+core and provides a sysfs interface for configuring infrared remote controller receivers.
+</para>
+
+</section>
+<section id="sys_class_rc_rcN">
+<title>/sys/class/rc/rcN/</title>
+<para>A <constant>/sys/class/rc/rcN</constant> directory is created for each remote
+  control receiver device where N is the number of the receiver.</para>
+
+</section>
+<section id="sys_class_rc_rcN_protocols">
+<title>/sys/class/rc/rcN/protocols</title>
+<para>Reading this file returns a list of available protocols, something like:</para>
+<para><constant>rc5 [rc6] nec jvc [sony]</constant></para>
+<para>Enabled protocols are shown in [] brackets.</para>
+<para>Writing "+proto" will add a protocol to the list of enabled protocols.</para>
+<para>Writing "-proto" will remove a protocol from the list of enabled protocols.</para>
+<para>Writing "proto" will enable only "proto".</para>
+<para>Writing "none" will disable all protocols.</para>
+<para>Write fails with EINVAL if an invalid protocol combination or unknown protocol name is used.</para>
+
+</section>
+<section id="sys_class_rc_rcN_filter">
+<title>/sys/class/rc/rcN/filter</title>
+<para>Sets the scancode filter expected value.</para>
+<para>Use in combination with <constant>/sys/class/rc/rcN/filter_mask</constant> to set the
+expected value of the bits set in the filter mask.
+If the hardware supports it then scancodes which do not match
+the filter will be ignored. Otherwise the write will fail with
+an error.</para>
+<para>This value may be reset to 0 if the current protocol is altered.</para>
+
+</section>
+<section id="sys_class_rc_rcN_filter_mask">
+<title>/sys/class/rc/rcN/filter_mask</title>
+<para>Sets the scancode filter mask of bits to compare.
+Use in combination with <constant>/sys/class/rc/rcN/filter</constant> to set the bits
+of the scancode which should be compared against the expected
+value. A value of 0 disables the filter to allow all valid
+scancodes to be processed.</para>
+<para>If the hardware supports it then scancodes which do not match
+the filter will be ignored. Otherwise the write will fail with
+an error.</para>
+<para>This value may be reset to 0 if the current protocol is altered.</para>
+
+</section>
+<section id="sys_class_rc_rcN_wakeup_protocols">
+<title>/sys/class/rc/rcN/wakeup_protocols</title>
+<para>Reading this file returns a list of available protocols to use for the
+wakeup filter, something like:</para>
+<para><constant>rc5 rc6 nec jvc [sony]</constant></para>
+<para>The enabled wakeup protocol is shown in [] brackets.</para>
+<para>Writing "+proto" will add a protocol to the list of enabled wakeup
+protocols.</para>
+<para>Writing "-proto" will remove a protocol from the list of enabled wakeup
+protocols.</para>
+<para>Writing "proto" will use "proto" for wakeup events.</para>
+<para>Writing "none" will disable wakeup.</para>
+<para>Write fails with EINVAL if an invalid protocol combination or unknown
+protocol name is used, or if wakeup is not supported by the hardware.</para>
+
+</section>
+<section id="sys_class_rc_rcN_wakeup_filter">
+<title>/sys/class/rc/rcN/wakeup_filter</title>
+<para>Sets the scancode wakeup filter expected value.
+Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter_mask</constant> to
+set the expected value of the bits set in the wakeup filter mask
+to trigger a system wake event.</para>
+<para>If the hardware supports it and wakeup_filter_mask is not 0 then
+scancodes which match the filter will wake the system from e.g.
+suspend to RAM or power off.
+Otherwise the write will fail with an error.</para>
+<para>This value may be reset to 0 if the wakeup protocol is altered.</para>
+
+</section>
+<section id="sys_class_rc_rcN_wakeup_filter_mask">
+<title>/sys/class/rc/rcN/wakeup_filter_mask</title>
+<para>Sets the scancode wakeup filter mask of bits to compare.
+Use in combination with <constant>/sys/class/rc/rcN/wakeup_filter</constant> to set
+the bits of the scancode which should be compared against the
+expected value to trigger a system wake event.</para>
+<para>If the hardware supports it and wakeup_filter_mask is not 0 then
+scancodes which match the filter will wake the system from e.g.
+suspend to RAM or power off.
+Otherwise the write will fail with an error.</para>
+<para>This value may be reset to 0 if the wakeup protocol is altered.</para>
+</section>
+</section>
+
+<section id="Remote_controllers_tables">
+<title>Remote controller tables</title>
 <para>Unfortunately, for several years, there was no effort to create uniform IR keycodes for
 different devices.  This caused the same IR keyname to be mapped completely differently on
 different IR devices. This resulted that the same IR keyname to be mapped completely different on
@@ -175,3 +317,4 @@ keymapping.</para>
 </section>
 
 &sub-lirc_device_interface;
+</chapter>
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml
index 74b7f27af71a..b445161b912c 100644
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -70,7 +70,7 @@ MPEG stream embedded, sliced VBI data format in this specification.
 Remote Controller chapter.</contrib>
         <affiliation>
           <address>
-            <email>mchehab@redhat.com</email>
+            <email>m.chehab@samsung.com</email>
           </address>
         </affiliation>
       </author>
@@ -107,6 +107,16 @@ Remote Controller chapter.</contrib>
           </address>
         </affiliation>
       </author>
+      <author>
+        <firstname>Antti</firstname>
+        <surname>Palosaari</surname>
+        <contrib>SDR API.</contrib>
+        <affiliation>
+          <address>
+            <email>crope@iki.fi</email>
+          </address>
+        </affiliation>
+      </author>
     </authorgroup>
 
     <copyright>
@@ -125,6 +135,7 @@ Remote Controller chapter.</contrib>
       <year>2011</year>
       <year>2012</year>
       <year>2013</year>
+      <year>2014</year>
       <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
 Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
         Pawel Osciak</holder>
@@ -141,6 +152,16 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
 
       <revision>
+        <revnumber>3.15</revnumber>
+        <date>2014-02-03</date>
+        <authorinitials>hv, ap</authorinitials>
+        <revremark>Update several sections of "Common API Elements": "Opening and Closing Devices"
+"Querying Capabilities", "Application Priority", "Video Inputs and Outputs", "Audio Inputs and Outputs"
+"Tuners and Modulators", "Video Standards" and "Digital Video (DV) Timings". Added SDR API.
+        </revremark>
+      </revision>
+
+      <revision>
         <revnumber>3.14</revnumber>
         <date>2013-11-25</date>
         <authorinitials>rr</authorinitials>
@@ -537,6 +558,7 @@ and discussions on the V4L mailing list.</revremark>
     <section id="ttx"> &sub-dev-teletext; </section>
     <section id="radio"> &sub-dev-radio; </section>
     <section id="rds"> &sub-dev-rds; </section>
+    <section id="sdr"> &sub-dev-sdr; </section>
     <section id="event"> &sub-dev-event; </section>
     <section id="subdev"> &sub-dev-subdev; </section>
   </chapter>
@@ -585,6 +607,7 @@ and discussions on the V4L mailing list.</revremark>
     &sub-g-crop;
     &sub-g-ctrl;
     &sub-g-dv-timings;
+    &sub-g-edid;
     &sub-g-enc-index;
     &sub-g-ext-ctrls;
     &sub-g-fbuf;
@@ -616,7 +639,6 @@ and discussions on the V4L mailing list.</revremark>
     &sub-subdev-enum-frame-size;
     &sub-subdev-enum-mbus-code;
     &sub-subdev-g-crop;
-    &sub-subdev-g-edid;
     &sub-subdev-g-fmt;
     &sub-subdev-g-frame-interval;
     &sub-subdev-g-selection;
diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
index 6541ba0175ed..4e8ea65f7282 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
@@ -100,7 +100,7 @@ See <xref linkend="v4l2-tuner-type" /></entry>
             <entry><structfield>capability</structfield></entry>
             <entry spanname="hspan">The tuner/modulator capability flags for
 this frequency band, see <xref linkend="tuner-capability" />. The <constant>V4L2_TUNER_CAP_LOW</constant>
-capability must be the same for all frequency bands of the selected tuner/modulator.
+or <constant>V4L2_TUNER_CAP_1HZ</constant> capability must be the same for all frequency bands of the selected tuner/modulator.
 So either all bands have that capability set, or none of them have that capability.</entry>
           </row>
           <row>
@@ -109,7 +109,8 @@ So either all bands have that capability set, or none of them have that capabili
             <entry spanname="hspan">The lowest tunable frequency in
 units of 62.5 kHz, or if the <structfield>capability</structfield>
 flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz, for this frequency band.</entry>
+Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -117,7 +118,8 @@ Hz, for this frequency band.</entry>
             <entry spanname="hspan">The highest tunable frequency in
 units of 62.5 kHz, or if the <structfield>capability</structfield>
 flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz, for this frequency band.</entry>
+Hz, for this frequency band. A 1 Hz unit is used when the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml
index bbd18f0e6ede..ce4563b87131 100644
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-edid.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml
@@ -1,12 +1,12 @@
-<refentry id="vidioc-subdev-g-edid">
+<refentry id="vidioc-g-edid">
   <refmeta>
-    <refentrytitle>ioctl VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</refentrytitle>
+    <refentrytitle>ioctl VIDIOC_G_EDID, VIDIOC_S_EDID</refentrytitle>
     &manvol;
   </refmeta>
 
   <refnamediv>
-    <refname>VIDIOC_SUBDEV_G_EDID</refname>
-    <refname>VIDIOC_SUBDEV_S_EDID</refname>
+    <refname>VIDIOC_G_EDID</refname>
+    <refname>VIDIOC_S_EDID</refname>
     <refpurpose>Get or set the EDID of a video receiver/transmitter</refpurpose>
   </refnamediv>
 
@@ -16,7 +16,7 @@
         <funcdef>int <function>ioctl</function></funcdef>
         <paramdef>int <parameter>fd</parameter></paramdef>
         <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
+        <paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef>
       </funcprototype>
     </funcsynopsis>
     <funcsynopsis>
@@ -24,7 +24,7 @@
         <funcdef>int <function>ioctl</function></funcdef>
         <paramdef>int <parameter>fd</parameter></paramdef>
         <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>const struct v4l2_subdev_edid *<parameter>argp</parameter></paramdef>
+        <paramdef>const struct v4l2_edid *<parameter>argp</parameter></paramdef>
       </funcprototype>
     </funcsynopsis>
   </refsynopsisdiv>
@@ -42,7 +42,7 @@
       <varlistentry>
         <term><parameter>request</parameter></term>
         <listitem>
-          <para>VIDIOC_SUBDEV_G_EDID, VIDIOC_SUBDEV_S_EDID</para>
+          <para>VIDIOC_G_EDID, VIDIOC_S_EDID</para>
         </listitem>
       </varlistentry>
       <varlistentry>
@@ -56,12 +56,20 @@
 
   <refsect1>
     <title>Description</title>
-    <para>These ioctls can be used to get or set an EDID associated with an input pad
-    from a receiver or an output pad of a transmitter subdevice.</para>
+    <para>These ioctls can be used to get or set an EDID associated with an input
+    from a receiver or an output of a transmitter device. They can be
+    used with subdevice nodes (/dev/v4l-subdevX) or with video nodes (/dev/videoX).</para>
+
+    <para>When used with video nodes the <structfield>pad</structfield> field represents the
+    input (for video capture devices) or output (for video output devices) index as
+    is returned by &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively. When used
+    with subdevice nodes the <structfield>pad</structfield> field represents the
+    input or output pad of the subdevice. If there is no EDID support for the given
+    <structfield>pad</structfield> value, then the &EINVAL; will be returned.</para>
 
     <para>To get the EDID data the application has to fill in the <structfield>pad</structfield>,
     <structfield>start_block</structfield>, <structfield>blocks</structfield> and <structfield>edid</structfield>
-    fields and call <constant>VIDIOC_SUBDEV_G_EDID</constant>. The current EDID from block
+    fields and call <constant>VIDIOC_G_EDID</constant>. The current EDID from block
     <structfield>start_block</structfield> and of size <structfield>blocks</structfield>
     will be placed in the memory <structfield>edid</structfield> points to. The <structfield>edid</structfield>
     pointer must point to memory at least <structfield>blocks</structfield>&nbsp;*&nbsp;128 bytes
@@ -91,15 +99,17 @@
     data in some way. In any case, the end result is the same: the EDID is no longer available.
     </para>
 
-    <table pgwide="1" frame="none" id="v4l2-subdev-edid">
-      <title>struct <structname>v4l2_subdev_edid</structname></title>
+    <table pgwide="1" frame="none" id="v4l2-edid">
+      <title>struct <structname>v4l2_edid</structname></title>
       <tgroup cols="3">
         &cs-str;
         <tbody valign="top">
           <row>
             <entry>__u32</entry>
             <entry><structfield>pad</structfield></entry>
-            <entry>Pad for which to get/set the EDID blocks.</entry>
+            <entry>Pad for which to get/set the EDID blocks. When used with a video device
+            node the pad represents the input or output index as returned by
+            &VIDIOC-ENUMINPUT; and &VIDIOC-ENUMOUTPUT; respectively.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
index b3bb9575b2e0..e9f6735c0823 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
@@ -327,7 +327,12 @@ These controls are described in <xref
 These controls are described in <xref
                 linkend="fm-rx-controls" />.</entry>
           </row>
-
+          <row>
+            <entry><constant>V4L2_CTRL_CLASS_RF_TUNER</constant></entry>
+            <entry>0xa20000</entry>
+            <entry>The class containing RF tuner controls.
+These controls are described in <xref linkend="rf-tuner-controls" />.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
index ee8f56e1bac0..4fe19a7a9a31 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-fmt.xml
@@ -172,6 +172,13 @@ capture and output devices.</entry>
           </row>
           <row>
             <entry></entry>
+            <entry>&v4l2-sdr-format;</entry>
+            <entry><structfield>sdr</structfield></entry>
+            <entry>Definition of a data format, see
+<xref linkend="pixfmt" />, used by SDR capture devices.</entry>
+          </row>
+          <row>
+            <entry></entry>
             <entry>__u8</entry>
             <entry><structfield>raw_data</structfield>[200]</entry>
             <entry>Place holder for future extensions.</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
index c7a1c462e724..d1034fb61d15 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
@@ -109,9 +109,10 @@ See <xref linkend="v4l2-tuner-type" /></entry>
             <entry>__u32</entry>
             <entry><structfield>frequency</structfield></entry>
             <entry>Tuning frequency in units of 62.5 kHz, or if the
-&v4l2-tuner; or &v4l2-modulator; <structfield>capabilities</structfield> flag
+&v4l2-tuner; or &v4l2-modulator; <structfield>capability</structfield> flag
 <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz.</entry>
+Hz. A 1 Hz unit is used when the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
index 7f4ac7e41fa8..7068b599a00d 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
@@ -113,7 +113,8 @@ change for example with the current video standard.</entry>
             <entry>The lowest tunable frequency in units of 62.5
 KHz, or if the <structfield>capability</structfield> flag
 <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz.</entry>
+Hz, or if the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry>
           </row>
           <row>
             <entry>__u32</entry>
@@ -121,7 +122,8 @@ Hz.</entry>
             <entry>The highest tunable frequency in units of 62.5
 KHz, or if the <structfield>capability</structfield> flag
 <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz.</entry>
+Hz, or if the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.</entry>
           </row>
           <row>
             <entry>__u32</entry>
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
index 6cc82010c736..b0d865933da6 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
@@ -134,7 +134,9 @@ the structure refers to a radio tuner the
             <entry spanname="hspan">The lowest tunable frequency in
 units of 62.5 kHz, or if the <structfield>capability</structfield>
 flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz. If multiple frequency bands are supported, then
+Hz, or if the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.
+If multiple frequency bands are supported, then
 <structfield>rangelow</structfield> is the lowest frequency
 of all the frequency bands.</entry>
           </row>
@@ -144,7 +146,9 @@ of all the frequency bands.</entry>
             <entry spanname="hspan">The highest tunable frequency in
 units of 62.5 kHz, or if the <structfield>capability</structfield>
 flag <constant>V4L2_TUNER_CAP_LOW</constant> is set, in units of 62.5
-Hz. If multiple frequency bands are supported, then
+Hz, or if the <structfield>capability</structfield> flag
+<constant>V4L2_TUNER_CAP_1HZ</constant> is set, in units of 1 Hz.
+If multiple frequency bands are supported, then
 <structfield>rangehigh</structfield> is the highest frequency
 of all the frequency bands.</entry>
           </row>
@@ -270,7 +274,7 @@ applications must set the array to zero.</entry>
             <entry><constant>V4L2_TUNER_CAP_LOW</constant></entry>
             <entry>0x0001</entry>
             <entry>When set, tuning frequencies are expressed in units of
-62.5&nbsp;Hz, otherwise in units of 62.5&nbsp;kHz.</entry>
+62.5 Hz instead of 62.5 kHz.</entry>
           </row>
           <row>
             <entry><constant>V4L2_TUNER_CAP_NORM</constant></entry>
@@ -360,6 +364,11 @@ radio tuners.</entry>
         <entry>The range to search when using the hardware seek functionality
         is programmable, see &VIDIOC-S-HW-FREQ-SEEK; for details.</entry>
           </row>
+          <row>
+        <entry><constant>V4L2_TUNER_CAP_1HZ</constant></entry>
+        <entry>0x1000</entry>
+        <entry>When set, tuning frequencies are expressed in units of 1 Hz instead of 62.5 kHz.</entry>
+          </row>
         </tbody>
       </tgroup>
     </table>
diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
index d5a3c97b206a..370d49d6fb64 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml
@@ -296,6 +296,12 @@ modulator programming see
 <xref linkend="tuner" />.</entry>
           </row>
           <row>
+            <entry><constant>V4L2_CAP_SDR_CAPTURE</constant></entry>
+            <entry>0x00100000</entry>
+            <entry>The device supports the
+<link linkend="sdr">SDR Capture</link> interface.</entry>
+          </row>
+          <row>
             <entry><constant>V4L2_CAP_READWRITE</constant></entry>
             <entry>0x01000000</entry>
             <entry>The device supports the <link
diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
index 5b379e752194..a5fc4c4880f3 100644
--- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml
@@ -121,7 +121,9 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
             <entry>If non-zero, the lowest tunable frequency of the band to
 search in units of 62.5 kHz, or if the &v4l2-tuner;
 <structfield>capability</structfield> field has the
-<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
+<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner;
+<structfield>capability</structfield> field has the
+<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz.
 If <structfield>rangelow</structfield> is zero a reasonable default value
 is used.</entry>
           </row>
@@ -131,7 +133,9 @@ is used.</entry>
             <entry>If non-zero, the highest tunable frequency of the band to
 search in units of 62.5 kHz, or if the &v4l2-tuner;
 <structfield>capability</structfield> field has the
-<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz.
+<constant>V4L2_TUNER_CAP_LOW</constant> flag set, in units of 62.5 Hz or if the &v4l2-tuner;
+<structfield>capability</structfield> field has the
+<constant>V4L2_TUNER_CAP_1HZ</constant> flag set, in units of 1 Hz.
 If <structfield>rangehigh</structfield> is zero a reasonable default value
 is used.</entry>
           </row>
diff --git a/Documentation/DocBook/media/v4l/vidioc-streamon.xml b/Documentation/DocBook/media/v4l/vidioc-streamon.xml
index 65dff55079d7..df2c63d07bac 100644
--- a/Documentation/DocBook/media/v4l/vidioc-streamon.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-streamon.xml
@@ -52,16 +52,24 @@
     <para>The <constant>VIDIOC_STREAMON</constant> and
 <constant>VIDIOC_STREAMOFF</constant> ioctl start and stop the capture
 or output process during streaming (<link linkend="mmap">memory
-mapping</link> or <link linkend="userp">user pointer</link>) I/O.</para>
+mapping</link>, <link linkend="userp">user pointer</link> or
+<link linkend="dmabuf">DMABUF</link>) I/O.</para>
 
-    <para>Specifically the capture hardware is disabled and no input
+    <para>Capture hardware is disabled and no input
 buffers are filled (if there are any empty buffers in the incoming
 queue) until <constant>VIDIOC_STREAMON</constant> has been called.
-Accordingly the output hardware is disabled, no video signal is
+Output hardware is disabled and no video signal is
 produced until <constant>VIDIOC_STREAMON</constant> has been called.
 The ioctl will succeed when at least one output buffer is in the
 incoming queue.</para>
 
+    <para>Memory-to-memory devices will not start until
+<constant>VIDIOC_STREAMON</constant> has been called for both the capture
+and output stream types.</para>
+
+    <para>If <constant>VIDIOC_STREAMON</constant> fails then any already
+queued buffers will remain queued.</para>
+
     <para>The <constant>VIDIOC_STREAMOFF</constant> ioctl, apart of
 aborting or finishing any DMA in progress, unlocks any user pointer
 buffers locked in physical memory, and it removes all buffers from the
@@ -70,14 +78,22 @@ dequeued yet will be lost, likewise all images enqueued for output but
 not transmitted yet. I/O returns to the same state as after calling
 &VIDIOC-REQBUFS; and can be restarted accordingly.</para>
 
+    <para>If buffers have been queued with &VIDIOC-QBUF; and
+<constant>VIDIOC_STREAMOFF</constant> is called without ever having
+called <constant>VIDIOC_STREAMON</constant>, then those queued buffers
+will also be removed from the incoming queue and all are returned to the
+same state as after calling &VIDIOC-REQBUFS; and can be restarted
+accordingly.</para>
+
     <para>Both ioctls take a pointer to an integer, the desired buffer or
 stream type. This is the same as &v4l2-requestbuffers;
 <structfield>type</structfield>.</para>
 
     <para>If <constant>VIDIOC_STREAMON</constant> is called when streaming
 is already in progress, or if <constant>VIDIOC_STREAMOFF</constant> is called
-when streaming is already stopped, then the ioctl does nothing and 0 is
-returned.</para>
+when streaming is already stopped, then 0 is returned. Nothing happens in the
+case of <constant>VIDIOC_STREAMON</constant>, but <constant>VIDIOC_STREAMOFF</constant>
+will return queued buffers to their starting state as mentioned above.</para>
 
     <para>Note that applications can be preempted for unknown periods right
 before or after the <constant>VIDIOC_STREAMON</constant> or
@@ -93,7 +109,7 @@ synchronize with other events.</para>
       <varlistentry>
         <term><errorcode>EINVAL</errorcode></term>
         <listitem>
-          <para>The buffer<structfield>type</structfield> is not supported,
+          <para>The buffer <structfield>type</structfield> is not supported,
           or no buffers have been allocated (memory mapping) or enqueued
           (output) yet.</para>
         </listitem>
diff --git a/Documentation/DocBook/media_api.tmpl b/Documentation/DocBook/media_api.tmpl
index 4c8d282545a2..4decb46bfa76 100644
--- a/Documentation/DocBook/media_api.tmpl
+++ b/Documentation/DocBook/media_api.tmpl
@@ -34,22 +34,20 @@
 
 <book id="media_api">
 <bookinfo>
-<title>LINUX MEDIA INFRASTRUCTURE API</title>
-
-<copyright>
-        <year>2009-2012</year>
-        <holder>LinuxTV Developers</holder>
-</copyright>
-
-<legalnotice>
-
-<para>Permission is granted to copy, distribute and/or modify
-this document under the terms of the GNU Free Documentation License,
-Version 1.1 or any later version published by the Free Software
-Foundation. A copy of the license is included in the chapter entitled
-"GNU Free Documentation License"</para>
-</legalnotice>
-
+        <title>LINUX MEDIA INFRASTRUCTURE API</title>
+
+        <copyright>
+                <year>2009-2014</year>
+                <holder>LinuxTV Developers</holder>
+        </copyright>
+
+        <legalnotice>
+                <para>Permission is granted to copy, distribute and/or modify
+                this document under the terms of the GNU Free Documentation License,
+                Version 1.1 or any later version published by the Free Software
+                Foundation. A copy of the license is included in the chapter entitled
+                "GNU Free Documentation License"</para>
+        </legalnotice>
 </bookinfo>
 
 <toc></toc> <!-- autogenerated -->
@@ -58,12 +56,13 @@ Foundation. A copy of the license is included in the chapter entitled
         <title>Introduction</title>
 
         <para>This document covers the Linux Kernel to Userspace API's used by
-                video and radio straming devices, including video cameras,
+                video and radio streaming devices, including video cameras,
                 analog and digital TV receiver cards, AM/FM receiver cards,
-                streaming capture devices.</para>
+                streaming capture and output devices, codec devices and remote
+                controllers.</para>
         <para>It is divided into four parts.</para>
-        <para>The first part covers radio, capture,
-                cameras and analog TV devices.</para>
+        <para>The first part covers radio, video capture and output,
+                cameras, analog TV devices and codecs.</para>
         <para>The second part covers the
                 API used for digital TV and Internet reception via one of the
                 several digital tv standards. While it is called as DVB API,
@@ -75,55 +74,14 @@ Foundation. A copy of the license is included in the chapter entitled
         <para>For additional information and for the latest development code,
                 see: <ulink url="http://linuxtv.org">http://linuxtv.org</ulink>.</para>
         <para>For discussing improvements, reporting troubles, sending new drivers, etc, please mail to: <ulink url="http://vger.kernel.org/vger-lists.html#linux-media">Linux Media Mailing List (LMML).</ulink>.</para>
-
 </preface>
 
-<part id="v4l2spec">
-&sub-v4l2;
-</part>
-<part id="dvbapi">
-&sub-dvbapi;
-</part>
-<part id="v4ldvb_common">
-<partinfo>
-<authorgroup>
-<author>
-<firstname>Mauro</firstname>
-<surname>Chehab</surname>
-<othername role="mi">Carvalho</othername>
-<affiliation><address><email>mchehab@redhat.com</email></address></affiliation>
-<contrib>Initial version.</contrib>
-</author>
-</authorgroup>
-<copyright>
-        <year>2009-2012</year>
-        <holder>Mauro Carvalho Chehab</holder>
-</copyright>
-
-<revhistory>
-<!-- Put document revisions here, newest first. -->
-<revision>
-<revnumber>1.0.0</revnumber>
-<date>2009-09-06</date>
-<authorinitials>mcc</authorinitials>
-<revremark>Initial revision</revremark>
-</revision>
-</revhistory>
-</partinfo>
-
-<title>Remote Controller API</title>
-<chapter id="remote_controllers">
-&sub-remote_controllers;
-</chapter>
-</part>
-<part id="media_common">
-&sub-media-controller;
-</part>
-
-<chapter id="gen_errors">
-&sub-gen-errors;
-</chapter>
+<part id="v4l2spec">&sub-v4l2;</part>
+<part id="dvbapi">&sub-dvbapi;</part>
+<part id="remotes">&sub-remote_controllers;</part>
+<part id="media_common">&sub-media-controller;</part>
 
+<chapter id="gen_errors">&sub-gen-errors;</chapter>
 
 &sub-fdl-appendix;
 
diff --git a/Documentation/DocBook/w1.tmpl b/Documentation/DocBook/w1.tmpl
new file mode 100644
index 000000000000..b0228d4c81bb
--- /dev/null
+++ b/Documentation/DocBook/w1.tmpl
@@ -0,0 +1,101 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
+        "http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
+
+<book id="w1id">
+  <bookinfo>
+    <title>W1: Dallas' 1-wire bus</title>
+
+    <authorgroup>
+      <author>
+        <firstname>David</firstname>
+        <surname>Fries</surname>
+        <affiliation>
+          <address>
+            <email>David@Fries.net</email>
+          </address>
+        </affiliation>
+      </author>
+
+    </authorgroup>
+
+    <copyright>
+      <year>2013</year>
+      <!--
+      <holder></holder>
+      -->
+    </copyright>
+
+    <legalnotice>
+      <para>
+        This documentation is free software; you can redistribute
+        it and/or modify it under the terms of the GNU General Public
+        License version 2.
+      </para>
+
+      <para>
+        This program is distributed in the hope that it will be
+        useful, but WITHOUT ANY WARRANTY; without even the implied
+        warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+        For more details see the file COPYING in the source
+        distribution of Linux.
+      </para>
+    </legalnotice>
+  </bookinfo>
+
+  <toc></toc>
+
+  <chapter id="w1_internal">
+    <title>W1 API internal to the kernel</title>
+
+    <sect1 id="w1_internal_api">
+      <title>W1 API internal to the kernel</title>
+      <sect2 id="w1.h">
+        <title>drivers/w1/w1.h</title>
+        <para>W1 core functions.</para>
+!Idrivers/w1/w1.h
+      </sect2>
+
+      <sect2 id="w1.c">
+        <title>drivers/w1/w1.c</title>
+        <para>W1 core functions.</para>
+!Idrivers/w1/w1.c
+      </sect2>
+
+      <sect2 id="w1_family.h">
+        <title>drivers/w1/w1_family.h</title>
+        <para>Allows registering device family operations.</para>
+!Idrivers/w1/w1_family.h
+      </sect2>
+
+      <sect2 id="w1_family.c">
+        <title>drivers/w1/w1_family.c</title>
+        <para>Allows registering device family operations.</para>
+!Edrivers/w1/w1_family.c
+      </sect2>
+
+      <sect2 id="w1_int.c">
+        <title>drivers/w1/w1_int.c</title>
+        <para>W1 internal initialization for master devices.</para>
+!Edrivers/w1/w1_int.c
+      </sect2>
+
+      <sect2 id="w1_netlink.h">
+        <title>drivers/w1/w1_netlink.h</title>
+        <para>W1 external netlink API structures and commands.</para>
+!Idrivers/w1/w1_netlink.h
+      </sect2>
+
+      <sect2 id="w1_io.c">
+        <title>drivers/w1/w1_io.c</title>
+        <para>W1 input/output.</para>
+!Edrivers/w1/w1_io.c
+!Idrivers/w1/w1_io.c
+      </sect2>
+
+    </sect1>
+
+
+  </chapter>
+
+</book>
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl
index 06741e925985..d0056a4e9c53 100644
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -468,8 +468,6 @@
                   return err;
           }
 
-          snd_card_set_dev(card, &pci->dev);
-
           *rchip = chip;
           return 0;
   }
@@ -492,7 +490,8 @@
           }
 
           /* (2) */
-          err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
+          err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
+                             0, &card);
           if (err < 0)
                   return err;
 
@@ -591,7 +590,8 @@
   struct snd_card *card;
   int err;
   ....
-  err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
+  err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
+                     0, &card);
 ]]>
             </programlisting>
           </informalexample>
@@ -809,28 +809,34 @@
 
       <para>
         As mentioned above, to create a card instance, call
-      <function>snd_card_create()</function>.
+      <function>snd_card_new()</function>.
 
         <informalexample>
           <programlisting>
 <![CDATA[
   struct snd_card *card;
   int err;
-  err = snd_card_create(index, id, module, extra_size, &card);
+  err = snd_card_new(&pci->dev, index, id, module, extra_size, &card);
 ]]>
           </programlisting>
         </informalexample>
       </para>
 
       <para>
-        The function takes five arguments, the card-index number, the
-        id string, the module pointer (usually
+        The function takes six arguments: the parent device pointer,
+        the card-index number, the id string, the module pointer (usually
         <constant>THIS_MODULE</constant>),
         the size of extra-data space, and the pointer to return the
         card instance.  The extra_size argument is used to
         allocate card-&gt;private_data for the
         chip-specific data.  Note that these data
-        are allocated by <function>snd_card_create()</function>.
+        are allocated by <function>snd_card_new()</function>.
+      </para>
+
+      <para>
+        The first argument, the pointer of struct
+        <structname>device</structname>, specifies the parent device.
+        For PCI devices, typically &amp;pci-&gt; is passed there.
       </para>
     </section>
 
@@ -916,16 +922,16 @@
       </para>
 
       <section id="card-management-chip-specific-snd-card-new">
-        <title>1. Allocating via <function>snd_card_create()</function>.</title>
+        <title>1. Allocating via <function>snd_card_new()</function>.</title>
         <para>
           As mentioned above, you can pass the extra-data-length
-          to the 4th argument of <function>snd_card_create()</function>, i.e.
+          to the 5th argument of <function>snd_card_new()</function>, i.e.
 
           <informalexample>
             <programlisting>
 <![CDATA[
-  err = snd_card_create(index[dev], id[dev], THIS_MODULE,
-                        sizeof(struct mychip), &card);
+  err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
+                     sizeof(struct mychip), &card);
 ]]>
             </programlisting>
           </informalexample>
@@ -954,7 +960,7 @@
 
         <para>
           After allocating a card instance via
-          <function>snd_card_create()</function> (with
+          <function>snd_card_new()</function> (with
           <constant>0</constant> on the 4th arg), call
           <function>kzalloc()</function>. 
 
@@ -963,7 +969,8 @@
 <![CDATA[
   struct snd_card *card;
   struct mychip *chip;
-  err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
+  err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
+                     0, &card);
   .....
   chip = kzalloc(sizeof(*chip), GFP_KERNEL);
 ]]>
@@ -1170,8 +1177,6 @@
                   return err;
           }
 
-          snd_card_set_dev(card, &pci->dev);
-
           *rchip = chip;
           return 0;
   }        
@@ -1526,30 +1531,6 @@
 
     </section>
 
-    <section id="pci-resource-device-struct">
-      <title>Registration of Device Struct</title>
-      <para>
-        At some point, typically after calling <function>snd_device_new()</function>,
-        you need to register the struct <structname>device</structname> of the chip
-        you're handling for udev and co.  ALSA provides a macro for compatibility with
-        older kernels.  Simply call like the following:
-        <informalexample>
-          <programlisting>
-<![CDATA[
-  snd_card_set_dev(card, &pci->dev);
-]]>
-          </programlisting>
-        </informalexample>
-        so that it stores the PCI's device pointer to the card.  This will be
-        referred by ALSA core functions later when the devices are registered.
-      </para>
-      <para>
-        In the case of non-PCI, pass the proper device struct pointer of the BUS
-        instead.  (In the case of legacy ISA without PnP, you don't have to do
-        anything.)
-      </para>
-    </section>
-
     <section id="pci-resource-entries">
       <title>PCI Entries</title>
       <para>
@@ -5740,7 +5721,8 @@ struct _snd_pcm_runtime {
           struct mychip *chip;
           int err;
           ....
-          err = snd_card_create(index[dev], id[dev], THIS_MODULE, 0, &card);
+          err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
+                             0, &card);
           ....
           chip = kzalloc(sizeof(*chip), GFP_KERNEL);
           ....
@@ -5752,7 +5734,7 @@ struct _snd_pcm_runtime {
       </informalexample>
 
         When you created the chip data with
-        <function>snd_card_create()</function>, it's anyway accessible
+        <function>snd_card_new()</function>, it's anyway accessible
         via <structfield>private_data</structfield> field.
 
       <informalexample>
@@ -5766,8 +5748,8 @@ struct _snd_pcm_runtime {
           struct mychip *chip;
           int err;
           ....
-          err = snd_card_create(index[dev], id[dev], THIS_MODULE,
-                                sizeof(struct mychip), &card);
+          err = snd_card_new(&pci->dev, index[dev], id[dev], THIS_MODULE,
+                             sizeof(struct mychip), &card);
           ....
           chip = card->private_data;
           ....
diff --git a/Documentation/PCI/pci-iov-howto.txt b/Documentation/PCI/pci-iov-howto.txt
index 86551cc72e03..2d91ae251982 100644
--- a/Documentation/PCI/pci-iov-howto.txt
+++ b/Documentation/PCI/pci-iov-howto.txt
@@ -68,10 +68,6 @@ To disable SR-IOV capability:
         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.
diff --git a/Documentation/RCU/RTFP.txt b/Documentation/RCU/RTFP.txt
index 273e654d7d08..2f0fcb2112d2 100644
--- a/Documentation/RCU/RTFP.txt
+++ b/Documentation/RCU/RTFP.txt
@@ -31,6 +31,14 @@ has lapsed, so this approach may be used in non-GPL software, if desired.
 (In contrast, implementation of RCU is permitted only in software licensed
 under either GPL or LGPL.  Sorry!!!)
 
+In 1987, Rashid et al. described lazy TLB-flush [RichardRashid87a].
+At first glance, this has nothing to do with RCU, but nevertheless
+this paper helped inspire the update-side batching used in the later
+RCU implementation in DYNIX/ptx.  In 1988, Barbara Liskov published
+a description of Argus that noted that use of out-of-date values can
+be tolerated in some situations.  Thus, this paper provides some early
+theoretical justification for use of stale data.
+
 In 1990, Pugh [Pugh90] noted that explicitly tracking which threads
 were reading a given data structure permitted deferred free to operate
 in the presence of non-terminating threads.  However, this explicit
@@ -41,11 +49,11 @@ providing a fine-grained locking design, however, it would be interesting
 to see how much of the performance advantage reported in 1990 remains
 today.
 
-At about this same time, Adams [Adams91] described ``chaotic relaxation'',
-where the normal barriers between successive iterations of convergent
-numerical algorithms are relaxed, so that iteration $n$ might use
-data from iteration $n-1$ or even $n-2$.  This introduces error,
-which typically slows convergence and thus increases the number of
+At about this same time, Andrews [Andrews91textbook] described ``chaotic
+relaxation'', where the normal barriers between successive iterations
+of convergent numerical algorithms are relaxed, so that iteration $n$
+might use data from iteration $n-1$ or even $n-2$.  This introduces
+error, which typically slows convergence and thus increases the number of
 iterations required.  However, this increase is sometimes more than made
 up for by a reduction in the number of expensive barrier operations,
 which are otherwise required to synchronize the threads at the end
@@ -55,7 +63,8 @@ is thus inapplicable to most data structures in operating-system kernels.
 
 In 1992, Henry (now Alexia) Massalin completed a dissertation advising
 parallel programmers to defer processing when feasible to simplify
-synchronization.  RCU makes extremely heavy use of this advice.
+synchronization [HMassalinPhD].  RCU makes extremely heavy use of
+this advice.
 
 In 1993, Jacobson [Jacobson93] verbally described what is perhaps the
 simplest deferred-free technique: simply waiting a fixed amount of time
@@ -90,27 +99,29 @@ mechanism, which is quite similar to RCU [Gamsa99].  These operating
 systems made pervasive use of RCU in place of "existence locks", which
 greatly simplifies locking hierarchies and helps avoid deadlocks.
 
-2001 saw the first RCU presentation involving Linux [McKenney01a]
-at OLS.  The resulting abundance of RCU patches was presented the
-following year [McKenney02a], and use of RCU in dcache was first
-described that same year [Linder02a].
+The year 2000 saw an email exchange that would likely have
+led to yet another independent invention of something like RCU
+[RustyRussell2000a,RustyRussell2000b].  Instead, 2001 saw the first
+RCU presentation involving Linux [McKenney01a] at OLS.  The resulting
+abundance of RCU patches was presented the following year [McKenney02a],
+and use of RCU in dcache was first described that same year [Linder02a].
 
 Also in 2002, Michael [Michael02b,Michael02a] presented "hazard-pointer"
 techniques that defer the destruction of data structures to simplify
 non-blocking synchronization (wait-free synchronization, lock-free
 synchronization, and obstruction-free synchronization are all examples of
-non-blocking synchronization).  In particular, this technique eliminates
-locking, reduces contention, reduces memory latency for readers, and
-parallelizes pipeline stalls and memory latency for writers.  However,
-these techniques still impose significant read-side overhead in the
-form of memory barriers.  Researchers at Sun worked along similar lines
-in the same timeframe [HerlihyLM02].  These techniques can be thought
-of as inside-out reference counts, where the count is represented by the
-number of hazard pointers referencing a given data structure rather than
-the more conventional counter field within the data structure itself.
-The key advantage of inside-out reference counts is that they can be
-stored in immortal variables, thus allowing races between access and
-deletion to be avoided.
+non-blocking synchronization).  The corresponding journal article appeared
+in 2004 [MagedMichael04a].  This technique eliminates locking, reduces
+contention, reduces memory latency for readers, and parallelizes pipeline
+stalls and memory latency for writers.  However, these techniques still
+impose significant read-side overhead in the form of memory barriers.
+Researchers at Sun worked along similar lines in the same timeframe
+[HerlihyLM02].  These techniques can be thought of as inside-out reference
+counts, where the count is represented by the number of hazard pointers
+referencing a given data structure rather than the more conventional
+counter field within the data structure itself.  The key advantage
+of inside-out reference counts is that they can be stored in immortal
+variables, thus allowing races between access and deletion to be avoided.
 
 By the same token, RCU can be thought of as a "bulk reference count",
 where some form of reference counter covers all reference by a given CPU
@@ -123,8 +134,10 @@ can be thought of in other terms as well.
 
 In 2003, the K42 group described how RCU could be used to create
 hot-pluggable implementations of operating-system functions [Appavoo03a].
-Later that year saw a paper describing an RCU implementation of System
-V IPC [Arcangeli03], and an introduction to RCU in Linux Journal
+Later that year saw a paper describing an RCU implementation
+of System V IPC [Arcangeli03] (following up on a suggestion by
+Hugh Dickins [Dickins02a] and an implementation by Mingming Cao
+[MingmingCao2002IPCRCU]), and an introduction to RCU in Linux Journal
 [McKenney03a].
 
 2004 has seen a Linux-Journal article on use of RCU in dcache
@@ -383,6 +396,21 @@ for Programming Languages and Operating Systems}"
 }
 }
 
+@phdthesis{HMassalinPhD
+,author="H. Massalin"
+,title="Synthesis: An Efficient Implementation of Fundamental Operating
+System Services"
+,school="Columbia University"
+,address="New York, NY"
+,year="1992"
+,annotation={
+        Mondo optimizing compiler.
+        Wait-free stuff.
+        Good advice: defer work to avoid synchronization.  See page 90
+                (PDF page 106), Section 5.4, fourth bullet point.
+}
+}
+
 @unpublished{Jacobson93
 ,author="Van Jacobson"
 ,title="Avoid Read-Side Locking Via Delayed Free"
@@ -671,6 +699,20 @@ Orran Krieger and Rusty Russell and Dipankar Sarma and Maneesh Soni"
 [Viewed October 18, 2004]"
 }
 
+@conference{Michael02b
+,author="Maged M. Michael"
+,title="High Performance Dynamic Lock-Free Hash Tables and List-Based Sets"
+,Year="2002"
+,Month="August"
+,booktitle="{Proceedings of the 14\textsuperscript{th} Annual ACM
+Symposium on Parallel
+Algorithms and Architecture}"
+,pages="73-82"
+,annotation={
+Like the title says...
+}
+}
+
 @Conference{Linder02a
 ,Author="Hanna Linder and Dipankar Sarma and Maneesh Soni"
 ,Title="Scalability of the Directory Entry Cache"
@@ -727,6 +769,24 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell"
 }
 }
 
+@conference{Michael02a
+,author="Maged M. Michael"
+,title="Safe Memory Reclamation for Dynamic Lock-Free Objects Using Atomic
+Reads and Writes"
+,Year="2002"
+,Month="August"
+,booktitle="{Proceedings of the 21\textsuperscript{st} Annual ACM
+Symposium on Principles of Distributed Computing}"
+,pages="21-30"
+,annotation={
+        Each thread keeps an array of pointers to items that it is
+        currently referencing.  Sort of an inside-out garbage collection
+        mechanism, but one that requires the accessing code to explicitly
+        state its needs.  Also requires read-side memory barriers on
+        most architectures.
+}
+}
+
 @unpublished{Dickins02a
 ,author="Hugh Dickins"
 ,title="Use RCU for System-V IPC"
@@ -735,6 +795,17 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell"
 ,note="private communication"
 }
 
+@InProceedings{HerlihyLM02
+,author={Maurice Herlihy and Victor Luchangco and Mark Moir}
+,title="The Repeat Offender Problem: A Mechanism for Supporting Dynamic-Sized,
+Lock-Free Data Structures"
+,booktitle={Proceedings of 16\textsuperscript{th} International
+Symposium on Distributed Computing}
+,year=2002
+,month="October"
+,pages="339-353"
+}
+
 @unpublished{Sarma02b
 ,Author="Dipankar Sarma"
 ,Title="Some dcache\_rcu benchmark numbers"
@@ -749,6 +820,19 @@ Andrea Arcangeli and Andi Kleen and Orran Krieger and Rusty Russell"
 }
 }
 
+@unpublished{MingmingCao2002IPCRCU
+,Author="Mingming Cao"
+,Title="[PATCH]updated ipc lock patch"
+,month="October"
+,year="2002"
+,note="Available:
+\url{https://lkml.org/lkml/2002/10/24/262}
+[Viewed February 15, 2014]"
+,annotation={
+        Mingming Cao's patch to introduce RCU to SysV IPC.
+}
+}
+
 @unpublished{LinusTorvalds2003a
 ,Author="Linus Torvalds"
 ,Title="Re: {[PATCH]} small fixes in brlock.h"
@@ -982,6 +1066,23 @@ Realtime Applications"
 }
 }
 
+@article{MagedMichael04a
+,author="Maged M. Michael"
+,title="Hazard Pointers: Safe Memory Reclamation for Lock-Free Objects"
+,Year="2004"
+,Month="June"
+,journal="IEEE Transactions on Parallel and Distributed Systems"
+,volume="15"
+,number="6"
+,pages="491-504"
+,url="Available:
+\url{http://www.research.ibm.com/people/m/michael/ieeetpds-2004.pdf}
+[Viewed March 1, 2005]"
+,annotation={
+        New canonical hazard-pointer citation.
+}
+}
+
 @phdthesis{PaulEdwardMcKenneyPhD
 ,author="Paul E. McKenney"
 ,title="Exploiting Deferred Destruction:
diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt
index 91266193b8f4..9d10d1db16a5 100644
--- a/Documentation/RCU/checklist.txt
+++ b/Documentation/RCU/checklist.txt
@@ -256,10 +256,10 @@ over a rather long period of time, but improvements are always welcome!
                 variations on this theme.
 
         b.      Limiting update rate.  For example, if updates occur only
-                once per hour, then no explicit rate limiting is required,
-                unless your system is already badly broken.  The dcache
-                subsystem takes this approach -- updates are guarded
-                by a global lock, limiting their rate.
+                once per hour, then no explicit rate limiting is
+                required, unless your system is already badly broken.
+                Older versions of the dcache subsystem take this approach,
+                guarding updates with a global lock, limiting their rate.
 
         c.      Trusted update -- if updates can only be done manually by
                 superuser or some other trusted user, then it might not
@@ -268,7 +268,8 @@ over a rather long period of time, but improvements are always welcome!
                 the machine.
 
         d.      Use call_rcu_bh() rather than call_rcu(), in order to take
-                advantage of call_rcu_bh()'s faster grace periods.
+                advantage of call_rcu_bh()'s faster grace periods.  (This
+                is only a partial solution, though.)
 
         e.      Periodically invoke synchronize_rcu(), permitting a limited
                 number of updates per grace period.
@@ -276,6 +277,13 @@ over a rather long period of time, but improvements are always welcome!
         The same cautions apply to call_rcu_bh(), call_rcu_sched(),
         call_srcu(), and kfree_rcu().
 
+        Note that although these primitives do take action to avoid memory
+        exhaustion when any given CPU has too many callbacks, a determined
+        user could still exhaust memory.  This is especially the case
+        if a system with a large number of CPUs has been configured to
+        offload all of its RCU callbacks onto a single CPU, or if the
+        system has relatively little free memory.
+
 9.      All RCU list-traversal primitives, which include
         rcu_dereference(), list_for_each_entry_rcu(), and
         list_for_each_safe_rcu(), must be either within an RCU read-side
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 26b1e31d5a13..2a8e89e13e45 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -14,7 +14,10 @@ Read Documentation/SubmitChecklist for a list of items to check
 before submitting code.  If you are submitting a driver, also read
 Documentation/SubmittingDrivers.
 
-
+Many of these steps describe the default behavior of the git version
+control system; if you use git to prepare your patches, you'll find much
+of the mechanical work done for you, though you'll still need to prepare
+and document a sensible set of patches.
 
 --------------------------------------------
 SECTION 1 - CREATING AND SENDING YOUR CHANGE
@@ -25,7 +28,9 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
 1) "diff -up"
 ------------
 
-Use "diff -up" or "diff -uprN" to create patches.
+Use "diff -up" or "diff -uprN" to create patches.  git generates patches
+in this form by default; if you're using git, you can skip this section
+entirely.
 
 All changes to the Linux kernel occur in the form of patches, as
 generated by diff(1).  When creating your patch, make sure to create it
@@ -66,19 +71,14 @@ Make sure your patch does not include any extra files which do not
 belong in a patch submission.  Make sure to review your patch -after-
 generated it with diff(1), to ensure accuracy.
 
-If your changes produce a lot of deltas, you may want to look into
-splitting them into individual patches which modify things in
-logical stages.  This will facilitate easier reviewing by other
-kernel developers, very important if you want your patch accepted.
-There are a number of scripts which can aid in this:
-
-Quilt:
-http://savannah.nongnu.org/projects/quilt
+If your changes produce a lot of deltas, you need to split them into
+individual patches which modify things in logical stages; see section
+#3.  This will facilitate easier reviewing by other kernel developers,
+very important if you want your patch accepted.
 
-Andrew Morton's patch scripts:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-Instead of these scripts, quilt is the recommended patch management
-tool (see above).
+If you're using git, "git rebase -i" can help you with this process.  If
+you're not using git, quilt <http://savannah.nongnu.org/projects/quilt>
+is another popular alternative.
 
 
 
@@ -106,8 +106,21 @@ I.e., the patch (series) and its description should be self-contained.
 This benefits both the patch merger(s) and reviewers.  Some reviewers
 probably didn't even receive earlier versions of the patch.
 
+Describe your changes in imperative mood, e.g. "make xyzzy do frotz"
+instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy
+to do frotz", as if you are giving orders to the codebase to change
+its behaviour.
+
 If the patch fixes a logged bug entry, refer to that bug entry by
-number and URL.
+number and URL.  If the patch follows from a mailing list discussion,
+give a URL to the mailing list archive; use the https://lkml.kernel.org/
+redirector with a Message-Id, to ensure that the links cannot become
+stale.
+
+However, try to make your explanation understandable without external
+resources.  In addition to giving a URL to a mailing list archive or
+bug, summarize the relevant points of the discussion that led to the
+patch as submitted.
 
 If you want to refer to a specific commit, don't just refer to the
 SHA-1 ID of the commit. Please also include the oneline summary of
@@ -594,7 +607,8 @@ patch.
 If you are going to include a diffstat after the "---" marker, please
 use diffstat options "-p 1 -w 70" so that filenames are listed from
 the top of the kernel source tree and don't use too much horizontal
-space (easily fit in 80 columns, maybe with some indentation).
+space (easily fit in 80 columns, maybe with some indentation).  (git
+generates appropriate diffstats by default.)
 
 See more details on the proper patch format in the following
 references.
@@ -725,7 +739,7 @@ SECTION 3 - REFERENCES
 ----------------------
 
 Andrew Morton, "The perfect patch" (tpp).
-  <http://userweb.kernel.org/~akpm/stuff/tpp.txt>
+  <http://www.ozlabs.org/~akpm/stuff/tpp.txt>
 
 Jeff Garzik, "Linux kernel patch submission format".
   <http://linux.yyz.us/patch-format.html>
@@ -738,7 +752,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
   <http://www.kroah.com/log/linux/maintainer-05.html>
 
 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
-  <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
+  <https://lkml.org/lkml/2005/7/11/336>
 
 Kernel Documentation/CodingStyle:
   <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
diff --git a/Documentation/arm/Marvell/README b/Documentation/arm/Marvell/README
index 5a930c1528ad..963ec445e15a 100644
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -83,14 +83,24 @@ EBU Armada family
         88F6710
         88F6707
         88F6W11
+    Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
+
+  Armada 375 Flavors:
+        88F6720
+    Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
+
+  Armada 380/385 Flavors:
+        88F6810
+        88F6820
+        88F6828
 
   Armada XP Flavors:
         MV78230
         MV78260
         MV78460
     NOTE: not to be confused with the non-SMP 78xx0 SoCs
+    Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
 
-  Product Brief: http://www.marvell.com/embedded-processors/armada-xp/assets/Marvell-ArmadaXP-SoC-product%20brief.pdf
   No public datasheet available.
 
   Core: Sheeva ARMv7 compatible
diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 5e054bfe4dde..d50fa618371b 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -35,11 +35,13 @@ ffffffbc00000000	ffffffbdffffffff	   8GB		vmemmap
 
 ffffffbe00000000        ffffffbffbbfffff          ~8GB          [guard, future vmmemap]
 
-ffffffbffbc00000        ffffffbffbdfffff           2MB          earlyprintk device
+ffffffbffa000000        ffffffbffaffffff          16MB          PCI I/O space
 
-ffffffbffbe00000        ffffffbffbe0ffff          64KB          PCI I/O space
+ffffffbffb000000        ffffffbffbbfffff          12MB          [guard]
 
-ffffffbffbe10000        ffffffbcffffffff          ~2MB          [guard]
+ffffffbffbc00000        ffffffbffbdfffff           2MB          fixed mappings
+
+ffffffbffbe00000        ffffffbffbffffff           2MB          [guard]
 
 ffffffbffc000000        ffffffbfffffffff          64MB          modules
 
@@ -60,11 +62,13 @@ fffffdfc00000000	fffffdfdffffffff	   8GB		vmemmap
 
 fffffdfe00000000        fffffdfffbbfffff          ~8GB          [guard, future vmmemap]
 
-fffffdfffbc00000        fffffdfffbdfffff           2MB          earlyprintk device
+fffffdfffa000000        fffffdfffaffffff          16MB          PCI I/O space
+
+fffffdfffb000000        fffffdfffbbfffff          12MB          [guard]
 
-fffffdfffbe00000        fffffdfffbe0ffff          64KB          PCI I/O space
+fffffdfffbc00000        fffffdfffbdfffff           2MB          fixed mappings
 
-fffffdfffbe10000        fffffdfffbffffff          ~2MB          [guard]
+fffffdfffbe00000        fffffdfffbffffff           2MB          [guard]
 
 fffffdfffc000000        fffffdffffffffff          64MB          modules
 
diff --git a/Documentation/blockdev/drbd/data-structure-v9.txt b/Documentation/blockdev/drbd/data-structure-v9.txt
new file mode 100644
index 000000000000..1e52a0e32624
--- /dev/null
+++ b/Documentation/blockdev/drbd/data-structure-v9.txt
@@ -0,0 +1,38 @@
+This describes the in kernel data structure for DRBD-9. Starting with
+Linux v3.14 we are reorganizing DRBD to use this data structure.
+
+Basic Data Structure
+====================
+
+A node has a number of DRBD resources.  Each such resource has a number of
+devices (aka volumes) and connections to other nodes ("peer nodes"). Each DRBD
+device is represented by a block device locally.
+
+The DRBD objects are interconnected to form a matrix as depicted below; a
+drbd_peer_device object sits at each intersection between a drbd_device and a
+drbd_connection:
+
+  /--------------+---------------+.....+---------------\
+  |   resource   |    device     |     |    device     |
+  +--------------+---------------+.....+---------------+
+  |  connection  |  peer_device  |     |  peer_device  |
+  +--------------+---------------+.....+---------------+
+  :              :               :     :               :
+  :              :               :     :               :
+  +--------------+---------------+.....+---------------+
+  |  connection  |  peer_device  |     |  peer_device  |
+  \--------------+---------------+.....+---------------/
+
+In this table, horizontally, devices can be accessed from resources by their
+volume number.  Likewise, peer_devices can be accessed from connections by
+their volume number.  Objects in the vertical direction are connected by double
+linked lists.  There are back pointers from peer_devices to their connections a
+devices, and from connections and devices to their resource.
+
+All resources are in the drbd_resources double-linked list.  In addition, all
+devices can be accessed by their minor device number via the drbd_devices idr.
+
+The drbd_resource, drbd_connection, and drbd_device objects are reference
+counted.  The peer_device objects only serve to establish the links between
+devices and connections; their lifetime is determined by the lifetime of the
+device and connection which they reference.
diff --git a/Documentation/blockdev/zram.txt b/Documentation/blockdev/zram.txt
index 2eccddffa6c8..0595c3f56ccf 100644
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -21,7 +21,43 @@ Following shows a typical sequence of steps for using zram.
         This creates 4 devices: /dev/zram{0,1,2,3}
         (num_devices parameter is optional. Default: 1)
 
-2) Set Disksize
+2) Set max number of compression streams
+        Compression backend may use up to max_comp_streams compression streams,
+        thus allowing up to max_comp_streams concurrent compression operations.
+        By default, compression backend uses single compression stream.
+
+        Examples:
+        #show max compression streams number
+        cat /sys/block/zram0/max_comp_streams
+
+        #set max compression streams number to 3
+        echo 3 > /sys/block/zram0/max_comp_streams
+
+Note:
+In order to enable compression backend's multi stream support max_comp_streams
+must be initially set to desired concurrency level before ZRAM device
+initialisation. Once the device initialised as a single stream compression
+backend (max_comp_streams equals to 1), you will see error if you try to change
+the value of max_comp_streams because single stream compression backend
+implemented as a special case by lock overhead issue and does not support
+dynamic max_comp_streams. Only multi stream backend supports dynamic
+max_comp_streams adjustment.
+
+3) Select compression algorithm
+        Using comp_algorithm device attribute one can see available and
+        currently selected (shown in square brackets) compression algortithms,
+        change selected compression algorithm (once the device is initialised
+        there is no way to change compression algorithm).
+
+        Examples:
+        #show supported compression algorithms
+        cat /sys/block/zram0/comp_algorithm
+        lzo [lz4]
+
+        #select lzo compression algorithm
+        echo lzo > /sys/block/zram0/comp_algorithm
+
+4) Set Disksize
         Set disk size by writing the value to sysfs node 'disksize'.
         The value can be either in bytes or you can use mem suffixes.
         Examples:
@@ -33,32 +69,38 @@ Following shows a typical sequence of steps for using zram.
             echo 512M > /sys/block/zram0/disksize
             echo 1G > /sys/block/zram0/disksize
 
-3) Activate:
+Note:
+There is little point creating a zram of greater than twice the size of memory
+since we expect a 2:1 compression ratio. Note that zram uses about 0.1% of the
+size of the disk when not in use so a huge zram is wasteful.
+
+5) Activate:
         mkswap /dev/zram0
         swapon /dev/zram0
 
         mkfs.ext4 /dev/zram1
         mount /dev/zram1 /tmp
 
-4) Stats:
+6) Stats:
         Per-device statistics are exported as various nodes under
         /sys/block/zram<id>/
                 disksize
                 num_reads
                 num_writes
+                failed_reads
+                failed_writes
                 invalid_io
                 notify_free
-                discard
                 zero_pages
                 orig_data_size
                 compr_data_size
                 mem_used_total
 
-5) Deactivate:
+7) Deactivate:
         swapoff /dev/zram0
         umount /dev/zram1
 
-6) Reset:
+8) Reset:
         Write any positive value to 'reset' sysfs node
         echo 1 > /sys/block/zram0/reset
         echo 1 > /sys/block/zram1/reset
diff --git a/Documentation/cgroups/memcg_test.txt b/Documentation/cgroups/memcg_test.txt
index ce94a83a7d9a..80ac454704b8 100644
--- a/Documentation/cgroups/memcg_test.txt
+++ b/Documentation/cgroups/memcg_test.txt
@@ -24,7 +24,7 @@ Please note that implementation details can be changed.
 
    a page/swp_entry may be charged (usage += PAGE_SIZE) at
 
-        mem_cgroup_newpage_charge()
+        mem_cgroup_charge_anon()
           Called at new page fault and Copy-On-Write.
 
         mem_cgroup_try_charge_swapin()
@@ -32,7 +32,7 @@ Please note that implementation details can be changed.
           Followed by charge-commit-cancel protocol. (With swap accounting)
           At commit, a charge recorded in swap_cgroup is removed.
 
-        mem_cgroup_cache_charge()
+        mem_cgroup_charge_file()
           Called at add_to_page_cache()
 
         mem_cgroup_cache_charge_swapin()
diff --git a/Documentation/cgroups/resource_counter.txt b/Documentation/cgroups/resource_counter.txt
index 5108afb3645c..762ca54eb929 100644
--- a/Documentation/cgroups/resource_counter.txt
+++ b/Documentation/cgroups/resource_counter.txt
@@ -76,15 +76,7 @@ to work with it.
         limit_fail_at parameter is set to the particular res_counter element
         where the charging failed.
 
- d. int res_counter_charge_locked
-                        (struct res_counter *rc, unsigned long val, bool force)
-
-        The same as res_counter_charge(), but it must not acquire/release the
-        res_counter->lock internally (it must be called with res_counter->lock
-        held). The force parameter indicates whether we can bypass the limit.
-
- e. u64 res_counter_uncharge[_locked]
-                        (struct res_counter *rc, unsigned long val)
+ d. u64 res_counter_uncharge(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
@@ -93,7 +85,7 @@ to work with it.
 
         The _locked routines imply that the res_counter->lock is taken.
 
- f. u64 res_counter_uncharge_until
+ e. u64 res_counter_uncharge_until
                 (struct res_counter *rc, struct res_counter *top,
                  unsigned long val)
 
diff --git a/Documentation/clk.txt b/Documentation/clk.txt
index 699ef2a323b1..c9c399af7c08 100644
--- a/Documentation/clk.txt
+++ b/Documentation/clk.txt
@@ -255,3 +255,37 @@ are sorted out.
 
 To bypass this disabling, include "clk_ignore_unused" in the bootargs to the
 kernel.
+
+        Part 7 - Locking
+
+The common clock framework uses two global locks, the prepare lock and the
+enable lock.
+
+The enable lock is a spinlock and is held across calls to the .enable,
+.disable and .is_enabled operations. Those operations are thus not allowed to
+sleep, and calls to the clk_enable(), clk_disable() and clk_is_enabled() API
+functions are allowed in atomic context.
+
+The prepare lock is a mutex and is held across calls to all other operations.
+All those operations are allowed to sleep, and calls to the corresponding API
+functions are not allowed in atomic context.
+
+This effectively divides operations in two groups from a locking perspective.
+
+Drivers don't need to manually protect resources shared between the operations
+of one group, regardless of whether those resources are shared by multiple
+clocks or not. However, access to resources that are shared between operations
+of the two groups needs to be protected by the drivers. An example of such a
+resource would be a register that controls both the clock rate and the clock
+enable/disable state.
+
+The clock framework is reentrant, in that a driver is allowed to call clock
+framework functions from within its implementation of clock operations. This
+can for instance cause a .set_rate operation of one clock being called from
+within the .set_rate operation of another clock. This case must be considered
+in the driver implementations, but the code flow is usually controlled by the
+driver in that case.
+
+Note that locking must also be considered when code outside of the common
+clock framework needs to access resources used by the clock operations. This
+is considered out of scope of this document.
diff --git a/Documentation/connector/cn_test.c b/Documentation/connector/cn_test.c
index adcca0368d60..d12cc944b696 100644
--- a/Documentation/connector/cn_test.c
+++ b/Documentation/connector/cn_test.c
@@ -145,7 +145,7 @@ static void cn_test_timer_func(unsigned long __data)
 
                 memcpy(m + 1, data, m->len);
 
-                cn_netlink_send(m, 0, GFP_ATOMIC);
+                cn_netlink_send(m, 0, 0, GFP_ATOMIC);
                 kfree(m);
         }
 
diff --git a/Documentation/cpu-freq/core.txt b/Documentation/cpu-freq/core.txt
index ce0666e51036..0060d76b445f 100644
--- a/Documentation/cpu-freq/core.txt
+++ b/Documentation/cpu-freq/core.txt
@@ -92,7 +92,3 @@ values:
 cpu     - number of the affected CPU
 old     - old frequency
 new     - new frequency
-
-If the cpufreq core detects the frequency has changed while the system
-was suspended, these notifiers are called with CPUFREQ_RESUMECHANGE as
-second argument.
diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt
index 8b1a4451422e..48da5fdcb9f1 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -61,7 +61,13 @@ target_index		-	See below on the differences.
 
 And optionally
 
-cpufreq_driver.exit -           A pointer to a per-CPU cleanup function.
+cpufreq_driver.exit -           A pointer to a per-CPU cleanup
+                                function called during CPU_POST_DEAD
+                                phase of cpu hotplug process.
+
+cpufreq_driver.stop_cpu -       A pointer to a per-CPU stop function
+                                called during CPU_DOWN_PREPARE phase of
+                                cpu hotplug process.
 
 cpufreq_driver.resume -         A pointer to a per-CPU resume function
                                 which is called with interrupts disabled
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index be675d2d15a7..a0b005d2bd95 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -312,12 +312,57 @@ things will happen if a notifier in path sent a BAD notify code.
 Q: I don't see my action being called for all CPUs already up and running?
 A: Yes, CPU notifiers are called only when new CPUs are on-lined or offlined.
    If you need to perform some action for each cpu already in the system, then
+   do this:
 
         for_each_online_cpu(i) {
                 foobar_cpu_callback(&foobar_cpu_notifier, CPU_UP_PREPARE, i);
                 foobar_cpu_callback(&foobar_cpu_notifier, CPU_ONLINE, i);
         }
 
+   However, if you want to register a hotplug callback, as well as perform
+   some initialization for CPUs that are already online, then do this:
+
+   Version 1: (Correct)
+   ---------
+
+        cpu_notifier_register_begin();
+
+                for_each_online_cpu(i) {
+                        foobar_cpu_callback(&foobar_cpu_notifier,
+                                            CPU_UP_PREPARE, i);
+                        foobar_cpu_callback(&foobar_cpu_notifier,
+                                            CPU_ONLINE, i);
+                }
+
+        /* Note the use of the double underscored version of the API */
+        __register_cpu_notifier(&foobar_cpu_notifier);
+
+        cpu_notifier_register_done();
+
+   Note that the following code is *NOT* the right way to achieve this,
+   because it is prone to an ABBA deadlock between the cpu_add_remove_lock
+   and the cpu_hotplug.lock.
+
+   Version 2: (Wrong!)
+   ---------
+
+        get_online_cpus();
+
+                for_each_online_cpu(i) {
+                        foobar_cpu_callback(&foobar_cpu_notifier,
+                                            CPU_UP_PREPARE, i);
+                        foobar_cpu_callback(&foobar_cpu_notifier,
+                                            CPU_ONLINE, i);
+                }
+
+        register_cpu_notifier(&foobar_cpu_notifier);
+
+        put_online_cpus();
+
+    So always use the first version shown above when you want to register
+    callbacks as well as initialize the already online CPUs.
+
+
 Q: If i would like to develop cpu hotplug support for a new architecture,
    what do i need at a minimum?
 A: The following are what is required for CPU hotplug infrastructure to work
diff --git a/Documentation/device-mapper/era.txt b/Documentation/device-mapper/era.txt
new file mode 100644
index 000000000000..3c6d01be3560
--- /dev/null
+++ b/Documentation/device-mapper/era.txt
@@ -0,0 +1,108 @@
+Introduction
+============
+
+dm-era is a target that behaves similar to the linear target.  In
+addition it keeps track of which blocks were written within a user
+defined period of time called an 'era'.  Each era target instance
+maintains the current era as a monotonically increasing 32-bit
+counter.
+
+Use cases include tracking changed blocks for backup software, and
+partially invalidating the contents of a cache to restore cache
+coherency after rolling back a vendor snapshot.
+
+Constructor
+===========
+
+ era <metadata dev> <origin dev> <block size>
+
+ metadata dev    : fast device holding the persistent metadata
+ origin dev      : device holding data blocks that may change
+ block size      : block size of origin data device, granularity that is
+                     tracked by the target
+
+Messages
+========
+
+None of the dm messages take any arguments.
+
+checkpoint
+----------
+
+Possibly move to a new era.  You shouldn't assume the era has
+incremented.  After sending this message, you should check the
+current era via the status line.
+
+take_metadata_snap
+------------------
+
+Create a clone of the metadata, to allow a userland process to read it.
+
+drop_metadata_snap
+------------------
+
+Drop the metadata snapshot.
+
+Status
+======
+
+<metadata block size> <#used metadata blocks>/<#total metadata blocks>
+<current era> <held metadata root | '-'>
+
+metadata block size      : Fixed block size for each metadata block in
+                             sectors
+#used metadata blocks    : Number of metadata blocks used
+#total metadata blocks   : Total number of metadata blocks
+current era              : The current era
+held metadata root       : The location, in blocks, of the metadata root
+                             that has been 'held' for userspace read
+                             access. '-' indicates there is no held root
+
+Detailed use case
+=================
+
+The scenario of invalidating a cache when rolling back a vendor
+snapshot was the primary use case when developing this target:
+
+Taking a vendor snapshot
+------------------------
+
+- Send a checkpoint message to the era target
+- Make a note of the current era in its status line
+- Take vendor snapshot (the era and snapshot should be forever
+  associated now).
+
+Rolling back to an vendor snapshot
+----------------------------------
+
+- Cache enters passthrough mode (see: dm-cache's docs in cache.txt)
+- Rollback vendor storage
+- Take metadata snapshot
+- Ascertain which blocks have been written since the snapshot was taken
+  by checking each block's era
+- Invalidate those blocks in the caching software
+- Cache returns to writeback/writethrough mode
+
+Memory usage
+============
+
+The target uses a bitset to record writes in the current era.  It also
+has a spare bitset ready for switching over to a new era.  Other than
+that it uses a few 4k blocks for updating metadata.
+
+   (4 * nr_blocks) bytes + buffers
+
+Resilience
+==========
+
+Metadata is updated on disk before a write to a previously unwritten
+block is performed.  As such dm-era should not be effected by a hard
+crash such as power failure.
+
+Userland tools
+==============
+
+Userland tools are found in the increasingly poorly named
+thin-provisioning-tools project:
+
+    https://github.com/jthornber/thin-provisioning-tools
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index 10378cc48374..87b4c5e82d39 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -353,6 +353,7 @@ Your cooperation is appreciated.
                 133 = /dev/exttrp       External device trap
                 134 = /dev/apm_bios     Advanced Power Management BIOS
                 135 = /dev/rtc          Real Time Clock
+                137 = /dev/vhci         Bluetooth virtual HCI driver
                 139 = /dev/openprom     SPARC OpenBoot PROM
                 140 = /dev/relay8       Berkshire Products Octal relay card
                 141 = /dev/relay16      Berkshire Products ISO-16 relay card
@@ -410,6 +411,7 @@ Your cooperation is appreciated.
                 194 = /dev/zkshim       Zero-Knowledge network shim control
                 195 = /dev/elographics/e2201    Elographics touchscreen E271-2201
                 196 = /dev/vfio/vfio    VFIO userspace driver interface
+                197 = /dev/pxa3xx-gcu   PXA3xx graphics controller unit driver
                 198 = /dev/sexec        Signed executable interface
                 199 = /dev/scanners/cuecat :CueCat barcode scanner
                 200 = /dev/net/tun      TAP/TUN network device
@@ -451,6 +453,7 @@ Your cooperation is appreciated.
                 236 = /dev/mapper/control       Device-Mapper control device
                 237 = /dev/loop-control Loopback control device
                 238 = /dev/vhost-net    Host kernel accelerator for virtio net
+                239 = /dev/uhid         User-space I/O driver support for HID subsystem
 
                 240-254                 Reserved for local use
                 255                     Reserved for MISC_DYNAMIC_MINOR
@@ -1491,10 +1494,17 @@ Your cooperation is appreciated.
                  64 = /dev/radio0       Radio device
                     ...
                 127 = /dev/radio63      Radio device
+                128 = /dev/swradio0     Software Defined Radio device
+                    ...
+                191 = /dev/swradio63    Software Defined Radio device
                 224 = /dev/vbi0         Vertical blank interrupt
                     ...
                 255 = /dev/vbi31        Vertical blank interrupt
 
+                Minor numbers are allocated dynamically unless
+                CONFIG_VIDEO_FIXED_MINOR_RANGES (default n)
+                configuration option is set.
+
  81 block       I2O hard disk
                   0 = /dev/i2o/hdq      17th I2O hard disk, whole disk
                  16 = /dev/i2o/hdr      18th I2O hard disk, whole disk
diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
index d74091a8a3bf..5fc03134a999 100644
--- a/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
+++ b/Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
@@ -1,4 +1,4 @@
-Marvell Armada 370 and Armada XP Interrupt Controller
+Marvell Armada 370, 375, 38x, XP Interrupt Controller
 -----------------------------------------------------
 
 Required properties:
@@ -16,7 +16,13 @@ Required properties:
   automatically map to the interrupt controller registers of the
   current CPU)
 
+Optional properties:
 
+- interrupts: If defined, then it indicates that this MPIC is
+  connected as a slave to another interrupt controller. This is
+  typically the case on Armada 375 and Armada 38x, where the MPIC is
+  connected as a slave to the Cortex-A9 GIC. The provided interrupt
+  indicate to which GIC interrupt the MPIC output is connected.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/armada-375.txt b/Documentation/devicetree/bindings/arm/armada-375.txt
new file mode 100644
index 000000000000..867d0b80cb8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-375.txt
@@ -0,0 +1,9 @@
+Marvell Armada 375 Platforms Device Tree Bindings
+-------------------------------------------------
+
+Boards with a SoC of the Marvell Armada 375 family shall have the
+following property:
+
+Required root node property:
+
+compatible: must contain "marvell,armada375"
diff --git a/Documentation/devicetree/bindings/arm/armada-38x.txt b/Documentation/devicetree/bindings/arm/armada-38x.txt
new file mode 100644
index 000000000000..11f2330a6554
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/armada-38x.txt
@@ -0,0 +1,10 @@
+Marvell Armada 38x Platforms Device Tree Bindings
+-------------------------------------------------
+
+Boards with a SoC of the Marvell Armada 38x family shall have the
+following property:
+
+Required root node property:
+
+ - compatible: must contain either "marvell,armada380" or
+   "marvell,armada385" depending on the variant of the SoC being used.
diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
new file mode 100644
index 000000000000..e0774255e1a6
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm21664.txt
@@ -0,0 +1,15 @@
+Broadcom BCM21664 device tree bindings
+--------------------------------------
+
+This document describes the device tree bindings for boards with the BCM21664
+SoC.
+
+Required root node property:
+  - compatible: brcm,bcm21664
+
+Example:
+        / {
+                model = "BCM21664 SoC";
+                compatible = "brcm,bcm21664";
+                [...]
+        }
diff --git a/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
new file mode 100644
index 000000000000..93f31ca1ef4b
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm/kona-resetmgr.txt
@@ -0,0 +1,14 @@
+Broadcom Kona Family Reset Manager
+----------------------------------
+
+The reset manager is used on the Broadcom BCM21664 SoC.
+
+Required properties:
+  - compatible: brcm,bcm21664-resetmgr
+  - reg: memory address & range
+
+Example:
+        brcm,resetmgr@35001f00 {
+                compatible = "brcm,bcm21664-resetmgr";
+                reg = <0x35001f00 0x24>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/bcm4708.txt b/Documentation/devicetree/bindings/arm/bcm4708.txt
new file mode 100644
index 000000000000..6b0f49f6f499
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/bcm4708.txt
@@ -0,0 +1,8 @@
+Broadcom BCM4708 device tree bindings
+-------------------------------------------
+
+Boards with the BCM4708 SoC shall have the following properties:
+
+Required root node property:
+
+compatible = "brcm,bcm4708";
diff --git a/Documentation/devicetree/bindings/arm/cpus.txt b/Documentation/devicetree/bindings/arm/cpus.txt
index 91304353eea4..333f4aea3029 100644
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -180,7 +180,11 @@ nodes to be present and contain the properties described below.
                           be one of:
                              "spin-table"
                              "psci"
-                        # On ARM 32-bit systems this property is optional.
+                        # On ARM 32-bit systems this property is optional and
+                          can be one of:
+                            "qcom,gcc-msm8660"
+                            "qcom,kpss-acc-v1"
+                            "qcom,kpss-acc-v2"
 
         - cpu-release-addr
                 Usage: required for systems that have an "enable-method"
@@ -191,6 +195,21 @@ nodes to be present and contain the properties described below.
                           property identifying a 64-bit zero-initialised
                           memory location.
 
+        - qcom,saw
+                Usage: required for systems that have an "enable-method"
+                       property value of "qcom,kpss-acc-v1" or
+                       "qcom,kpss-acc-v2"
+                Value type: <phandle>
+                Definition: Specifies the SAW[1] node associated with this CPU.
+
+        - qcom,acc
+                Usage: required for systems that have an "enable-method"
+                       property value of "qcom,kpss-acc-v1" or
+                       "qcom,kpss-acc-v2"
+                Value type: <phandle>
+                Definition: Specifies the ACC[2] node associated with this CPU.
+
+
 Example 1 (dual-cluster big.LITTLE system 32-bit):
 
         cpus {
@@ -382,3 +401,7 @@ cpus {
                 cpu-release-addr = <0 0x20000000>;
         };
 };
+
+--
+[1] arm/msm/qcom,saw2.txt
+[2] arm/msm/qcom,kpss-acc.txt
diff --git a/Documentation/devicetree/bindings/arm/gic.txt b/Documentation/devicetree/bindings/arm/gic.txt
index bae0d87a38b2..5573c08d3180 100644
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -50,6 +50,11 @@ Optional
   regions, used when the GIC doesn't have banked registers. The offset is
   cpu-offset * cpu-nr.
 
+- arm,routable-irqs : Total number of gic irq inputs which are not directly
+                  connected from the peripherals, but are routed dynamically
+                  by a crossbar/multiplexer preceding the GIC. The GIC irq
+                  input line is assigned dynamically when the corresponding
+                  peripheral's crossbar line is mapped.
 Example:
 
         intc: interrupt-controller@fff11000 {
@@ -57,6 +62,7 @@ Example:
                 #interrupt-cells = <3>;
                 #address-cells = <1>;
                 interrupt-controller;
+                arm,routable-irqs = <160>;
                 reg = <0xfff11000 0x1000>,
                       <0xfff10100 0x100>;
         };
diff --git a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
index 8c7a4653508d..df0a452b8526 100644
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -30,3 +30,17 @@ Example:
                 resume-offset = <0x308>;
                 reboot-offset = <0x4>;
         };
+
+PCTRL: Peripheral misc control register
+
+Required Properties:
+- compatible: "hisilicon,pctrl"
+- reg: Address and size of pctrl.
+
+Example:
+
+        /* for Hi3620 */
+        pctrl: pctrl@fca09000 {
+                compatible = "hisilicon,pctrl";
+                reg = <0xfca09000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/keystone/keystone.txt b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
index 63c0e6ae5cf7..59d7a46f85eb 100644
--- a/Documentation/devicetree/bindings/arm/keystone/keystone.txt
+++ b/Documentation/devicetree/bindings/arm/keystone/keystone.txt
@@ -8,3 +8,13 @@ Required properties:
  - compatible: All TI specific devices present in Keystone SOC should be in
    the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
    type UART should use the specified compatible for those devices.
+
+Boards:
+-  Keystone 2 Hawking/Kepler EVM
+   compatible = "ti,k2hk-evm","ti,keystone"
+
+-  Keystone 2 Lamarr EVM
+   compatible = "ti,k2l-evm","ti,keystone"
+
+-  Keystone 2 Edison EVM
+   compatible = "ti,k2e-evm","ti,keystone"
diff --git a/Documentation/devicetree/bindings/arm/marvell,dove.txt b/Documentation/devicetree/bindings/arm/marvell,dove.txt
new file mode 100644
index 000000000000..aaaf64c56e44
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/marvell,dove.txt
@@ -0,0 +1,22 @@
+Marvell Dove Platforms Device Tree Bindings
+-----------------------------------------------
+
+Boards with a Marvell Dove SoC shall have the following properties:
+
+Required root node property:
+- compatible: must contain "marvell,dove";
+
+* Global Configuration registers
+
+Global Configuration registers of Dove SoC are shared by a syscon node.
+
+Required properties:
+- compatible: must contain "marvell,dove-global-config" and "syscon".
+- reg: base address and size of the Global Configuration registers.
+
+Example:
+
+gconf: global-config@e802c {
+        compatible = "marvell,dove-global-config", "syscon";
+        reg = <0xe802c 0x14>;
+};
diff --git a/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt
new file mode 100644
index 000000000000..0d244b999d10
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/mrvl/feroceon.txt
@@ -0,0 +1,16 @@
+* Marvell Feroceon Cache
+
+Required properties:
+- compatible : Should be either "marvell,feroceon-cache" or
+               "marvell,kirkwood-cache".
+
+Optional properties:
+- reg        : Address of the L2 cache control register. Mandatory for
+               "marvell,kirkwood-cache", not used by "marvell,feroceon-cache"
+
+
+Example:
+                l2: l2-cache@20128 {
+                        compatible = "marvell,kirkwood-cache";
+                        reg = <0x20128 0x4>;
+                };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
new file mode 100644
index 000000000000..1333db9acfee
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,kpss-acc.txt
@@ -0,0 +1,30 @@
+Krait Processor Sub-system (KPSS) Application Clock Controller (ACC)
+
+The KPSS ACC provides clock, power domain, and reset control to a Krait CPU.
+There is one ACC register region per CPU within the KPSS remapped region as
+well as an alias register region that remaps accesses to the ACC associated
+with the CPU accessing the region.
+
+PROPERTIES
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: should be one of:
+                        "qcom,kpss-acc-v1"
+                        "qcom,kpss-acc-v2"
+
+- reg:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: the first element specifies the base address and size of
+                    the register region. An optional second element specifies
+                    the base address and size of the alias register region.
+
+Example:
+
+        clock-controller@2088000 {
+                compatible = "qcom,kpss-acc-v2";
+                reg = <0x02088000 0x1000>,
+                      <0x02008000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
new file mode 100644
index 000000000000..1505fb8e131a
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/qcom,saw2.txt
@@ -0,0 +1,35 @@
+SPM AVS Wrapper 2 (SAW2)
+
+The SAW2 is a wrapper around the Subsystem Power Manager (SPM) and the
+Adaptive Voltage Scaling (AVS) hardware. The SPM is a programmable
+micro-controller that transitions a piece of hardware (like a processor or
+subsystem) into and out of low power modes via a direct connection to
+the PMIC. It can also be wired up to interact with other processors in the
+system, notifying them when a low power state is entered or exited.
+
+PROPERTIES
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: shall contain "qcom,saw2". A more specific value should be
+                    one of:
+                         "qcom,saw2-v1"
+                         "qcom,saw2-v1.1"
+                         "qcom,saw2-v2"
+                         "qcom,saw2-v2.1"
+
+- reg:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: the first element specifies the base address and size of
+                    the register region. An optional second element specifies
+                    the base address and size of the alias register region.
+
+
+Example:
+
+        regulator@2099000 {
+                compatible = "qcom,saw2";
+                reg = <0x02099000 0x1000>, <0x02009000 0x1000>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
index 081c6a786c8a..d24ab2ebf8a7 100644
--- a/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
+++ b/Documentation/devicetree/bindings/arm/mvebu-system-controller.txt
@@ -1,12 +1,13 @@
 MVEBU System Controller
 -----------------------
-MVEBU (Marvell SOCs: Armada 370/XP, Dove, mv78xx0, Kirkwood, Orion5x)
+MVEBU (Marvell SOCs: Armada 370/375/XP, Dove, mv78xx0, Kirkwood, Orion5x)
 
 Required properties:
 
 - compatible: one of:
         - "marvell,orion-system-controller"
         - "marvell,armada-370-xp-system-controller"
+        - "marvell,armada-375-system-controller"
 - reg: Should contain system controller registers location and length.
 
 Example:
diff --git a/Documentation/devicetree/bindings/arm/omap/crossbar.txt b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
new file mode 100644
index 000000000000..fb88585cfb93
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/crossbar.txt
@@ -0,0 +1,27 @@
+Some socs have a large number of interrupts requests to service
+the needs of its many peripherals and subsystems. All of the
+interrupt lines from the subsystems are not needed at the same
+time, so they have to be muxed to the irq-controller appropriately.
+In such places a interrupt controllers are preceded by an CROSSBAR
+that provides flexibility in muxing the device requests to the controller
+inputs.
+
+Required properties:
+- compatible : Should be "ti,irq-crossbar"
+- reg: Base address and the size of the crossbar registers.
+- ti,max-irqs: Total number of irqs available at the interrupt controller.
+- ti,reg-size: Size of a individual register in bytes. Every individual
+            register is assumed to be of same size. Valid sizes are 1, 2, 4.
+- ti,irqs-reserved: List of the reserved irq lines that are not muxed using
+                 crossbar. These interrupt lines are reserved in the soc,
+                 so crossbar bar driver should not consider them as free
+                 lines.
+
+Examples:
+                crossbar_mpu: @4a020000 {
+                        compatible = "ti,irq-crossbar";
+                        reg = <0x4a002a48 0x130>;
+                        ti,max-irqs = <160>;
+                        ti,reg-size = <2>;
+                        ti,irqs-reserved = <0 1 2 3 5 6 131 132 139 140>;
+                };
diff --git a/Documentation/devicetree/bindings/arm/omap/dmm.txt b/Documentation/devicetree/bindings/arm/omap/dmm.txt
new file mode 100644
index 000000000000..8bd6d0a238a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/omap/dmm.txt
@@ -0,0 +1,22 @@
+OMAP Dynamic Memory Manager (DMM) bindings
+
+The dynamic memory manager (DMM) is a module located immediately in front of the
+SDRAM controllers (called EMIFs on OMAP). DMM manages various aspects of memory
+accesses such as priority generation amongst initiators, configuration of SDRAM
+interleaving, optimizing transfer of 2D block objects, and provide MMU-like page
+translation for initiators which need contiguous dma bus addresses.
+
+Required properties:
+- compatible:   Should contain "ti,omap4-dmm" for OMAP4 family
+                Should contain "ti,omap5-dmm" for OMAP5 and DRA7x family
+- reg:          Contains DMM register address range (base address and length)
+- interrupts:   Should contain an interrupt-specifier for DMM_IRQ.
+- ti,hwmods:    Name of the hwmod associated to DMM, which is typically "dmm"
+
+Example:
+
+dmm@4e000000 {
+        compatible = "ti,omap4-dmm";
+        reg = <0x4e000000 0x800>;
+        ti,hwmods = "dmm";
+};
diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index af9b4a0d902b..36ede19a1630 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -99,6 +99,9 @@ Boards:
 - OMAP4 PandaBoard : Low cost community board
   compatible = "ti,omap4-panda", "ti,omap4430"
 
+- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
+  compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
 - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
   compatible = "ti,omap3-evm", "ti,omap3"
 
@@ -114,5 +117,8 @@ Boards:
 - AM43x EPOS EVM
   compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
 
+- AM437x GP EVM
+  compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
+
 - DRA7 EVM:  Software Developement Board for DRA7XX
   compatible = "ti,dra7-evm", "ti,dra7"
diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt
index 3e1e498fea96..fe5cef8976cb 100644
--- a/Documentation/devicetree/bindings/arm/pmu.txt
+++ b/Documentation/devicetree/bindings/arm/pmu.txt
@@ -9,6 +9,7 @@ Required properties:
 - compatible : should be one of
         "arm,armv8-pmuv3"
         "arm,cortex-a15-pmu"
+        "arm,cortex-a12-pmu"
         "arm,cortex-a9-pmu"
         "arm,cortex-a8-pmu"
         "arm,cortex-a7-pmu"
@@ -16,7 +17,14 @@ Required properties:
         "arm,arm11mpcore-pmu"
         "arm,arm1176-pmu"
         "arm,arm1136-pmu"
-- interrupts : 1 combined interrupt or 1 per core.
+        "qcom,krait-pmu"
+- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
+               interrupt (PPI) then 1 interrupt should be specified.
+
+Optional properties:
+
+- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
+                     events.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/arm/rockchip/pmu.txt b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
new file mode 100644
index 000000000000..3ee9b428b2f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/pmu.txt
@@ -0,0 +1,16 @@
+Rockchip power-management-unit:
+-------------------------------
+
+The pmu is used to turn off and on different power domains of the SoCs
+This includes the power to the CPU cores.
+
+Required node properties:
+- compatible value : = "rockchip,rk3066-pmu";
+- reg : physical base address and the size of the registers window
+
+Example:
+
+        pmu@20004000 {
+                compatible = "rockchip,rk3066-pmu";
+                reg = <0x20004000 0x100>;
+        };
diff --git a/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
new file mode 100644
index 000000000000..d9416fb8db6f
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/rockchip/smp-sram.txt
@@ -0,0 +1,30 @@
+Rockchip SRAM for smp bringup:
+------------------------------
+
+Rockchip's smp-capable SoCs use the first part of the sram for the bringup
+of the cores. Once the core gets powered up it executes the code that is
+residing at the very beginning of the sram.
+
+Therefore a reserved section sub-node has to be added to the mmio-sram
+declaration.
+
+Required sub-node properties:
+- compatible : should be "rockchip,rk3066-smp-sram"
+
+The rest of the properties should follow the generic mmio-sram discription
+found in ../../misc/sram.txt
+
+Example:
+
+        sram: sram@10080000 {
+                compatible = "mmio-sram";
+                reg = <0x10080000 0x10000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+
+                smp-sram@10080000 {
+                        compatible = "rockchip,rk3066-smp-sram";
+                        reg = <0x10080000 0x50>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/arm/samsung/pmu.txt b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
new file mode 100644
index 000000000000..f1f155255f28
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/samsung/pmu.txt
@@ -0,0 +1,15 @@
+SAMSUNG Exynos SoC series PMU Registers
+
+Properties:
+ - compatible : should contain two values. First value must be one from following list:
+                   - "samsung,exynos5250-pmu" - for Exynos5250 SoC,
+                   - "samsung,exynos5420-pmu" - for Exynos5420 SoC.
+                second value must be always "syscon".
+
+ - reg : offset and length of the register set.
+
+Example :
+pmu_system_controller: system-controller@10040000 {
+        compatible = "samsung,exynos5250-pmu", "syscon";
+        reg = <0x10040000 0x5000>;
+};
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 89de1564950c..48b285ffa3a6 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -4,17 +4,33 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
 Each SATA controller should have its own node.
 
 Required properties:
-- compatible        : compatible list, contains "snps,spear-ahci"
+- compatible        : compatible list, one of "snps,spear-ahci",
+                      "snps,exynos5440-ahci", "ibm,476gtr-ahci",
+                      "allwinner,sun4i-a10-ahci", "fsl,imx53-ahci"
+                      "fsl,imx6q-ahci" or "snps,dwc-ahci"
 - interrupts        : <interrupt mapping for SATA IRQ>
 - reg               : <registers mapping>
 
 Optional properties:
 - dma-coherent      : Present if dma operations are coherent
+- clocks            : a list of phandle + clock specifier pairs
+- target-supply     : regulator for SATA target power
 
-Example:
+"fsl,imx53-ahci", "fsl,imx6q-ahci" required properties:
+- clocks            : must contain the sata, sata_ref and ahb clocks
+- clock-names       : must contain "ahb" for the ahb clock
+
+Examples:
         sata@ffe08000 {
                 compatible = "snps,spear-ahci";
                 reg = <0xffe08000 0x1000>;
                 interrupts = <115>;
-
         };
+
+        ahci: sata@01c18000 {
+                compatible = "allwinner,sun4i-a10-ahci";
+                reg = <0x01c18000 0x1000>;
+                interrupts = <56>;
+                clocks = <&pll6 0>, <&ahb_gates 25>;
+                target-supply = <&reg_ahci_5v>;
+        };
diff --git a/Documentation/devicetree/bindings/ata/apm-xgene.txt b/Documentation/devicetree/bindings/ata/apm-xgene.txt
new file mode 100644
index 000000000000..7bcfbf59810e
--- /dev/null
+++ b/Documentation/devicetree/bindings/ata/apm-xgene.txt
@@ -0,0 +1,76 @@
+* APM X-Gene 6.0 Gb/s SATA host controller nodes
+
+SATA host controller nodes are defined to describe on-chip Serial ATA
+controllers. Each SATA controller (pair of ports) have its own node.
+
+Required properties:
+- compatible            : Shall contain:
+  * "apm,xgene-ahci"
+- reg                   : First memory resource shall be the AHCI memory
+                          resource.
+                          Second memory resource shall be the host controller
+                          core memory resource.
+                          Third memory resource shall be the host controller
+                          diagnostic memory resource.
+                          4th memory resource shall be the host controller
+                          AXI memory resource.
+                          5th optional memory resource shall be the host
+                          controller MUX memory resource if required.
+- interrupts            : Interrupt-specifier for SATA host controller IRQ.
+- clocks                : Reference to the clock entry.
+- phys                  : A list of phandles + phy-specifiers, one for each
+                          entry in phy-names.
+- phy-names             : Should contain:
+  * "sata-phy" for the SATA 6.0Gbps PHY
+
+Optional properties:
+- status                : Shall be "ok" if enabled or "disabled" if disabled.
+                          Default is "ok".
+
+Example:
+                sataclk: sataclk {
+                        compatible = "fixed-clock";
+                        #clock-cells = <1>;
+                        clock-frequency = <100000000>;
+                        clock-output-names = "sataclk";
+                };
+
+                phy2: phy@1f22a000 {
+                        compatible = "apm,xgene-phy";
+                        reg = <0x0 0x1f22a000 0x0 0x100>;
+                        #phy-cells = <1>;
+                };
+
+                phy3: phy@1f23a000 {
+                        compatible = "apm,xgene-phy";
+                        reg = <0x0 0x1f23a000 0x0 0x100>;
+                        #phy-cells = <1>;
+                };
+
+                sata2: sata@1a400000 {
+                        compatible = "apm,xgene-ahci";
+                        reg = <0x0 0x1a400000 0x0 0x1000>,
+                              <0x0 0x1f220000 0x0 0x1000>,
+                              <0x0 0x1f22d000 0x0 0x1000>,
+                              <0x0 0x1f22e000 0x0 0x1000>,
+                              <0x0 0x1f227000 0x0 0x1000>;
+                        interrupts = <0x0 0x87 0x4>;
+                        status = "ok";
+                        clocks = <&sataclk 0>;
+                        phys = <&phy2 0>;
+                        phy-names = "sata-phy";
+                };
+
+                sata3: sata@1a800000 {
+                        compatible = "apm,xgene-ahci-pcie";
+                        reg = <0x0 0x1a800000 0x0 0x1000>,
+                              <0x0 0x1f230000 0x0 0x1000>,
+                              <0x0 0x1f23d000 0x0 0x1000>,
+                              <0x0 0x1f23e000 0x0 0x1000>,
+                              <0x0 0x1f237000 0x0 0x1000>;
+                        interrupts = <0x0 0x88 0x4>;
+                        status = "ok";
+                        clocks = <&sataclk 0>;
+                        phys = <&phy3 0>;
+                        phy-names = "sata-phy";
+                };
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt b/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
deleted file mode 100644
index 37824fac688e..000000000000
--- a/Documentation/devicetree/bindings/ata/exynos-sata-phy.txt
+++ /dev/null
@@ -1,14 +0,0 @@
-* Samsung SATA PHY Controller
-
-SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
-Each SATA PHY controller should have its own node.
-
-Required properties:
-- compatible        : compatible list, contains "samsung,exynos5-sata-phy"
-- reg               : <registers mapping>
-
-Example:
-        sata@ffe07000 {
-                compatible = "samsung,exynos5-sata-phy";
-                reg = <0xffe07000 0x1000>;
-        };
diff --git a/Documentation/devicetree/bindings/ata/exynos-sata.txt b/Documentation/devicetree/bindings/ata/exynos-sata.txt
index 0849f1025e34..cb48448247ea 100644
--- a/Documentation/devicetree/bindings/ata/exynos-sata.txt
+++ b/Documentation/devicetree/bindings/ata/exynos-sata.txt
@@ -4,14 +4,27 @@ SATA nodes are defined to describe on-chip Serial ATA controllers.
 Each SATA controller should have its own node.
 
 Required properties:
-- compatible        : compatible list, contains "samsung,exynos5-sata"
-- interrupts        : <interrupt mapping for SATA IRQ>
-- reg               : <registers mapping>
-- samsung,sata-freq : <frequency in MHz>
+- compatible            : compatible list, contains "samsung,exynos5-sata"
+- interrupts            : <interrupt mapping for SATA IRQ>
+- reg                   : <registers mapping>
+- samsung,sata-freq     : <frequency in MHz>
+- phys                  : Must contain exactly one entry as specified
+                          in phy-bindings.txt
+- phy-names             : Must be "sata-phy"
+
+Optional properties:
+- clocks                : Must contain an entry for each entry in clock-names.
+- clock-names           : Shall be "sata" for the external SATA bus clock,
+                          and "sclk_sata" for the internal controller clock.
 
 Example:
-        sata@ffe08000 {
-                compatible = "samsung,exynos5-sata";
-                reg = <0xffe08000 0x1000>;
-                interrupts = <115>;
-        };
+        sata@122f0000 {
+                compatible = "snps,dwc-ahci";
+                samsung,sata-freq = <66>;
+                reg = <0x122f0000 0x1ff>;
+                interrupts = <0 115 0>;
+                clocks = <&clock 277>, <&clock 143>;
+                clock-names = "sata", "sclk_sata";
+                phys = <&sata_phy>;
+                phy-names = "sata-phy";
+        };
diff --git a/Documentation/devicetree/bindings/bus/imx-weim.txt b/Documentation/devicetree/bindings/bus/imx-weim.txt
index 0fd76c405208..6630d842c7a3 100644
--- a/Documentation/devicetree/bindings/bus/imx-weim.txt
+++ b/Documentation/devicetree/bindings/bus/imx-weim.txt
@@ -8,7 +8,12 @@ The actual devices are instantiated from the child nodes of a WEIM node.
 
 Required properties:
 
- - compatible:          Should be set to "fsl,<soc>-weim"
+ - compatible:          Should contain one of the following:
+                          "fsl,imx1-weim"
+                          "fsl,imx27-weim"
+                          "fsl,imx51-weim"
+                          "fsl,imx50-weim"
+                          "fsl,imx6q-weim"
  - reg:                 A resource specifier for the register space
                         (see the example below)
  - clocks:              the clock, see the example below.
@@ -19,6 +24,26 @@ Required properties:
 
                            <cs-number> 0 <physical address of mapping> <size>
 
+Optional properties:
+
+ - fsl,weim-cs-gpr:     For "fsl,imx50-weim" and "fsl,imx6q-weim" type of
+                        devices, it should be the phandle to the system General
+                        Purpose Register controller that contains WEIM CS GPR
+                        register, e.g. IOMUXC_GPR1 on i.MX6Q.  IOMUXC_GPR1[11:0]
+                        should be set up as one of the following 4 possible
+                        values depending on the CS space configuration.
+
+                        IOMUXC_GPR1[11:0]    CS0    CS1    CS2    CS3
+                        ---------------------------------------------
+                                05          128M     0M     0M     0M
+                                033          64M    64M     0M     0M
+                                0113         64M    32M    32M     0M
+                                01111        32M    32M    32M    32M
+
+                        In case that the property is absent, the reset value or
+                        what bootloader sets up in IOMUXC_GPR1[11:0] will be
+                        used.
+
 Timing property for child nodes. It is mandatory, not optional.
 
  - fsl,weim-cs-timing:  The timing array, contains timing values for the
@@ -43,6 +68,7 @@ Example for an imx6q-sabreauto board, the NOR flash connected to the WEIM:
                 #address-cells = <2>;
                 #size-cells = <1>;
                 ranges = <0 0 0x08000000 0x08000000>;
+                fsl,weim-cs-gpr = <&gpr>;
 
                 nor@0,0 {
                         compatible = "cfi-flash";
diff --git a/Documentation/devicetree/bindings/clock/altr_socfpga.txt b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
index 0045433eae1f..5dfd145d3ccf 100644
--- a/Documentation/devicetree/bindings/clock/altr_socfpga.txt
+++ b/Documentation/devicetree/bindings/clock/altr_socfpga.txt
@@ -23,3 +23,8 @@ Optional properties:
         and the bit index.
 - div-reg : For "socfpga-gate-clk", div-reg contains the divider register, bit shift,
         and width.
+- clk-phase : For the sdmmc_clk, contains the value of the clock phase that controls
+        the SDMMC CIU clock. The first value is the clk_sample(smpsel), and the second
+        value is the cclk_in_drv(drvsel). The clk-phase is used to enable the correct
+        hold/delay times that is needed for the SD/MMC CIU clock. The values of both
+        can be 0-315 degrees, in 45 degree increments.
diff --git a/Documentation/devicetree/bindings/clock/arm-integrator.txt b/Documentation/devicetree/bindings/clock/arm-integrator.txt
new file mode 100644
index 000000000000..652914b17b95
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/arm-integrator.txt
@@ -0,0 +1,34 @@
+Clock bindings for ARM Integrator Core Module clocks
+
+Auxilary Oscillator Clock
+
+This is a configurable clock fed from a 24 MHz chrystal,
+used for generating e.g. video clocks. It is located on the
+core module and there is only one of these.
+
+This clock node *must* be a subnode of the core module, since
+it obtains the base address for it's address range from its
+parent node.
+
+
+Required properties:
+- compatible: must be "arm,integrator-cm-auxosc"
+- #clock-cells: must be <0>
+
+Optional properties:
+- clocks: parent clock(s)
+
+Example:
+
+core-module@10000000 {
+        xtal24mhz: xtal24mhz@24M {
+                #clock-cells = <0>;
+                compatible = "fixed-clock";
+                clock-frequency = <24000000>;
+        };
+        auxosc: cm_aux_osc@25M {
+                #clock-cells = <0>;
+                compatible = "arm,integrator-cm-auxosc";
+                clocks = <&xtal24mhz>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/clock/axi-clkgen.txt b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
index 028b493e97ff..20e1704e7df2 100644
--- a/Documentation/devicetree/bindings/clock/axi-clkgen.txt
+++ b/Documentation/devicetree/bindings/clock/axi-clkgen.txt
@@ -5,7 +5,7 @@ This binding uses the common clock binding[1].
 [1] Documentation/devicetree/bindings/clock/clock-bindings.txt
 
 Required properties:
-- compatible : shall be "adi,axi-clkgen".
+- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
 - #clock-cells : from common clock binding; Should always be set to 0.
 - reg : Address and length of the axi-clkgen register set.
 - clocks : Phandle and clock specifier for the parent clock.
diff --git a/Documentation/devicetree/bindings/clock/clock-bindings.txt b/Documentation/devicetree/bindings/clock/clock-bindings.txt
index 7c52c29d99fa..700e7aac3717 100644
--- a/Documentation/devicetree/bindings/clock/clock-bindings.txt
+++ b/Documentation/devicetree/bindings/clock/clock-bindings.txt
@@ -44,6 +44,23 @@ For example:
   clocks by index. The names should reflect the clock output signal
   names for the device.
 
+clock-indices:     If the identifyng number for the clocks in the node
+                   is not linear from zero, then the this mapping allows
+                   the mapping of identifiers into the clock-output-names
+                   array.
+
+For example, if we have two clocks <&oscillator 1> and <&oscillator 3>:
+
+        oscillator {
+                compatible = "myclocktype";
+                #clock-cells = <1>;
+                clock-indices = <1>, <3>;
+                clock-output-names = "clka", "clkb";
+        }
+
+        This ensures we do not have any empty nodes in clock-output-names
+
+
 ==Clock consumers==
 
 Required properties:
diff --git a/Documentation/devicetree/bindings/clock/exynos4-clock.txt b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
index a2ac2d9ac71a..f5a5b19ed3b2 100644
--- a/Documentation/devicetree/bindings/clock/exynos4-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos4-clock.txt
@@ -15,259 +15,12 @@ Required Properties:
 
 - #clock-cells: should be 1.
 
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume. Some of the clocks are available only on a particular
-Exynos4 SoC and this is specified where applicable.
-
-
-                 [Core Clocks]
-
-  Clock               ID      SoC (if specific)
-  -----------------------------------------------
-
-  xxti                1
-  xusbxti             2
-  fin_pll             3
-  fout_apll           4
-  fout_mpll           5
-  fout_epll           6
-  fout_vpll           7
-  sclk_apll           8
-  sclk_mpll           9
-  sclk_epll           10
-  sclk_vpll           11
-  arm_clk             12
-  aclk200             13
-  aclk100             14
-  aclk160             15
-  aclk133             16
-  mout_mpll_user_t    17      Exynos4x12
-  mout_mpll_user_c    18      Exynos4x12
-  mout_core           19
-  mout_apll           20
-
-
-            [Clock Gate for Special Clocks]
-
-  Clock               ID      SoC (if specific)
-  -----------------------------------------------
-
-  sclk_fimc0          128
-  sclk_fimc1          129
-  sclk_fimc2          130
-  sclk_fimc3          131
-  sclk_cam0           132
-  sclk_cam1           133
-  sclk_csis0          134
-  sclk_csis1          135
-  sclk_hdmi           136
-  sclk_mixer          137
-  sclk_dac            138
-  sclk_pixel          139
-  sclk_fimd0          140
-  sclk_mdnie0         141     Exynos4412
-  sclk_mdnie_pwm0 12  142     Exynos4412
-  sclk_mipi0          143
-  sclk_audio0         144
-  sclk_mmc0           145
-  sclk_mmc1           146
-  sclk_mmc2           147
-  sclk_mmc3           148
-  sclk_mmc4           149
-  sclk_sata           150     Exynos4210
-  sclk_uart0          151
-  sclk_uart1          152
-  sclk_uart2          153
-  sclk_uart3          154
-  sclk_uart4          155
-  sclk_audio1         156
-  sclk_audio2         157
-  sclk_spdif          158
-  sclk_spi0           159
-  sclk_spi1           160
-  sclk_spi2           161
-  sclk_slimbus        162
-  sclk_fimd1          163     Exynos4210
-  sclk_mipi1          164     Exynos4210
-  sclk_pcm1           165
-  sclk_pcm2           166
-  sclk_i2s1           167
-  sclk_i2s2           168
-  sclk_mipihsi        169     Exynos4412
-  sclk_mfc            170
-  sclk_pcm0           171
-  sclk_g3d            172
-  sclk_pwm_isp        173     Exynos4x12
-  sclk_spi0_isp       174     Exynos4x12
-  sclk_spi1_isp       175     Exynos4x12
-  sclk_uart_isp       176     Exynos4x12
-  sclk_fimg2d         177
-
-              [Peripheral Clock Gates]
-
-  Clock               ID      SoC (if specific)
-  -----------------------------------------------
-
-  fimc0               256
-  fimc1               257
-  fimc2               258
-  fimc3               259
-  csis0               260
-  csis1               261
-  jpeg                262
-  smmu_fimc0          263
-  smmu_fimc1          264
-  smmu_fimc2          265
-  smmu_fimc3          266
-  smmu_jpeg           267
-  vp                  268
-  mixer               269
-  tvenc               270     Exynos4210
-  hdmi                271
-  smmu_tv             272
-  mfc                 273
-  smmu_mfcl           274
-  smmu_mfcr           275
-  g3d                 276
-  g2d                 277
-  rotator             278     Exynos4210
-  mdma                279     Exynos4210
-  smmu_g2d            280     Exynos4210
-  smmu_rotator        281     Exynos4210
-  smmu_mdma           282     Exynos4210
-  fimd0               283
-  mie0                284
-  mdnie0              285     Exynos4412
-  dsim0               286
-  smmu_fimd0          287
-  fimd1               288     Exynos4210
-  mie1                289     Exynos4210
-  dsim1               290     Exynos4210
-  smmu_fimd1          291     Exynos4210
-  pdma0               292
-  pdma1               293
-  pcie_phy            294
-  sata_phy            295     Exynos4210
-  tsi                 296
-  sdmmc0              297
-  sdmmc1              298
-  sdmmc2              299
-  sdmmc3              300
-  sdmmc4              301
-  sata                302     Exynos4210
-  sromc               303
-  usb_host            304
-  usb_device          305
-  pcie                306
-  onenand             307
-  nfcon               308
-  smmu_pcie           309
-  gps                 310
-  smmu_gps            311
-  uart0               312
-  uart1               313
-  uart2               314
-  uart3               315
-  uart4               316
-  i2c0                317
-  i2c1                318
-  i2c2                319
-  i2c3                320
-  i2c4                321
-  i2c5                322
-  i2c6                323
-  i2c7                324
-  i2c_hdmi            325
-  tsadc               326
-  spi0                327
-  spi1                328
-  spi2                329
-  i2s1                330
-  i2s2                331
-  pcm0                332
-  i2s0                333
-  pcm1                334
-  pcm2                335
-  pwm                 336
-  slimbus             337
-  spdif               338
-  ac97                339
-  modemif             340
-  chipid              341
-  sysreg              342
-  hdmi_cec            343
-  mct                 344
-  wdt                 345
-  rtc                 346
-  keyif               347
-  audss               348
-  mipi_hsi            349     Exynos4210
-  mdma2               350     Exynos4210
-  pixelasyncm0        351
-  pixelasyncm1        352
-  fimc_lite0          353     Exynos4x12
-  fimc_lite1          354     Exynos4x12
-  ppmuispx            355     Exynos4x12
-  ppmuispmx           356     Exynos4x12
-  fimc_isp            357     Exynos4x12
-  fimc_drc            358     Exynos4x12
-  fimc_fd             359     Exynos4x12
-  mcuisp              360     Exynos4x12
-  gicisp              361     Exynos4x12
-  smmu_isp            362     Exynos4x12
-  smmu_drc            363     Exynos4x12
-  smmu_fd             364     Exynos4x12
-  smmu_lite0          365     Exynos4x12
-  smmu_lite1          366     Exynos4x12
-  mcuctl_isp          367     Exynos4x12
-  mpwm_isp            368     Exynos4x12
-  i2c0_isp            369     Exynos4x12
-  i2c1_isp            370     Exynos4x12
-  mtcadc_isp          371     Exynos4x12
-  pwm_isp             372     Exynos4x12
-  wdt_isp             373     Exynos4x12
-  uart_isp            374     Exynos4x12
-  asyncaxim           375     Exynos4x12
-  smmu_ispcx          376     Exynos4x12
-  spi0_isp            377     Exynos4x12
-  spi1_isp            378     Exynos4x12
-  pwm_isp_sclk        379     Exynos4x12
-  spi0_isp_sclk       380     Exynos4x12
-  spi1_isp_sclk       381     Exynos4x12
-  uart_isp_sclk       382     Exynos4x12
-  tmu_apbif           383
-
-                [Mux Clocks]
-
-  Clock                 ID      SoC (if specific)
-  -----------------------------------------------
-
-  mout_fimc0            384
-  mout_fimc1            385
-  mout_fimc2            386
-  mout_fimc3            387
-  mout_cam0             388
-  mout_cam1             389
-  mout_csis0            390
-  mout_csis1            391
-  mout_g3d0             392
-  mout_g3d1             393
-  mout_g3d              394
-  aclk400_mcuisp        395     Exynos4x12
-
-                [Div Clocks]
-
-  Clock                 ID      SoC (if specific)
-  -----------------------------------------------
-
-  div_isp0              450     Exynos4x12
-  div_isp1              451     Exynos4x12
-  div_mcuisp0           452     Exynos4x12
-  div_mcuisp1           453     Exynos4x12
-  div_aclk200           454     Exynos4x12
-  div_aclk400_mcuisp    455     Exynos4x12
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
 
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos4.h header and can be used in device
+tree sources.
 
 Example 1: An example of a clock controller node is listed below.
 
@@ -285,6 +38,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
                 compatible = "samsung,exynos4210-uart";
                 reg = <0x13820000 0x100>;
                 interrupts = <0 54 0>;
-                clocks = <&clock 314>, <&clock 153>;
+                clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
                 clock-names = "uart", "clk_uart_baud0";
         };
diff --git a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
index 72ce617dea82..536eacd1063f 100644
--- a/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5250-clock.txt
@@ -13,163 +13,12 @@ Required Properties:
 
 - #clock-cells: should be 1.
 
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume.
-
-
-       [Core Clocks]
-
-  Clock                 ID
-  ----------------------------
-
-  fin_pll               1
-
-  [Clock Gate for Special Clocks]
-
-  Clock                 ID
-  ----------------------------
-
-  sclk_cam_bayer        128
-  sclk_cam0             129
-  sclk_cam1             130
-  sclk_gscl_wa          131
-  sclk_gscl_wb          132
-  sclk_fimd1            133
-  sclk_mipi1            134
-  sclk_dp               135
-  sclk_hdmi             136
-  sclk_pixel            137
-  sclk_audio0           138
-  sclk_mmc0             139
-  sclk_mmc1             140
-  sclk_mmc2             141
-  sclk_mmc3             142
-  sclk_sata             143
-  sclk_usb3             144
-  sclk_jpeg             145
-  sclk_uart0            146
-  sclk_uart1            147
-  sclk_uart2            148
-  sclk_uart3            149
-  sclk_pwm              150
-  sclk_audio1           151
-  sclk_audio2           152
-  sclk_spdif            153
-  sclk_spi0             154
-  sclk_spi1             155
-  sclk_spi2             156
-  div_i2s1              157
-  div_i2s2              158
-  sclk_hdmiphy          159
-  div_pcm0              160
-
-
-   [Peripheral Clock Gates]
-
-  Clock                 ID
-  ----------------------------
-
-  gscl0                 256
-  gscl1                 257
-  gscl2                 258
-  gscl3                 259
-  gscl_wa               260
-  gscl_wb               261
-  smmu_gscl0            262
-  smmu_gscl1            263
-  smmu_gscl2            264
-  smmu_gscl3            265
-  mfc                   266
-  smmu_mfcl             267
-  smmu_mfcr             268
-  rotator               269
-  jpeg                  270
-  mdma1                 271
-  smmu_rotator          272
-  smmu_jpeg             273
-  smmu_mdma1            274
-  pdma0                 275
-  pdma1                 276
-  sata                  277
-  usbotg                278
-  mipi_hsi              279
-  sdmmc0                280
-  sdmmc1                281
-  sdmmc2                282
-  sdmmc3                283
-  sromc                 284
-  usb2                  285
-  usb3                  286
-  sata_phyctrl          287
-  sata_phyi2c           288
-  uart0                 289
-  uart1                 290
-  uart2                 291
-  uart3                 292
-  uart4                 293
-  i2c0                  294
-  i2c1                  295
-  i2c2                  296
-  i2c3                  297
-  i2c4                  298
-  i2c5                  299
-  i2c6                  300
-  i2c7                  301
-  i2c_hdmi              302
-  adc                   303
-  spi0                  304
-  spi1                  305
-  spi2                  306
-  i2s1                  307
-  i2s2                  308
-  pcm1                  309
-  pcm2                  310
-  pwm                   311
-  spdif                 312
-  ac97                  313
-  hsi2c0                314
-  hsi2c1                315
-  hs12c2                316
-  hs12c3                317
-  chipid                318
-  sysreg                319
-  pmu                   320
-  cmu_top               321
-  cmu_core              322
-  cmu_mem               323
-  tzpc0                 324
-  tzpc1                 325
-  tzpc2                 326
-  tzpc3                 327
-  tzpc4                 328
-  tzpc5                 329
-  tzpc6                 330
-  tzpc7                 331
-  tzpc8                 332
-  tzpc9                 333
-  hdmi_cec              334
-  mct                   335
-  wdt                   336
-  rtc                   337
-  tmu                   338
-  fimd1                 339
-  mie1                  340
-  dsim0                 341
-  dp                    342
-  mixer                 343
-  hdmi                  344
-  g2d                   345
-  mdma0                 346
-  smmu_mdma0            347
-
-
-   [Clock Muxes]
-
-  Clock                 ID
-  ----------------------------
-  mout_hdmi             1024
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
 
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5250.h header and can be used in device
+tree sources.
 
 Example 1: An example of a clock controller node is listed below.
 
@@ -187,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
                 compatible = "samsung,exynos4210-uart";
                 reg = <0x13820000 0x100>;
                 interrupts = <0 54 0>;
-                clocks = <&clock 314>, <&clock 153>;
+                clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
                 clock-names = "uart", "clk_uart_baud0";
         };
diff --git a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
index 458f34789e5d..ca88c97a8562 100644
--- a/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5420-clock.txt
@@ -13,184 +13,12 @@ Required Properties:
 
 - #clock-cells: should be 1.
 
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume.
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
 
-
-       [Core Clocks]
-
-  Clock                 ID
-  ----------------------------
-
-  fin_pll               1
-
-  [Clock Gate for Special Clocks]
-
-  Clock                 ID
-  ----------------------------
-  sclk_uart0            128
-  sclk_uart1            129
-  sclk_uart2            130
-  sclk_uart3            131
-  sclk_mmc0             132
-  sclk_mmc1             133
-  sclk_mmc2             134
-  sclk_spi0             135
-  sclk_spi1             136
-  sclk_spi2             137
-  sclk_i2s1             138
-  sclk_i2s2             139
-  sclk_pcm1             140
-  sclk_pcm2             141
-  sclk_spdif            142
-  sclk_hdmi             143
-  sclk_pixel            144
-  sclk_dp1              145
-  sclk_mipi1            146
-  sclk_fimd1            147
-  sclk_maudio0          148
-  sclk_maupcm0          149
-  sclk_usbd300          150
-  sclk_usbd301          151
-  sclk_usbphy300        152
-  sclk_usbphy301        153
-  sclk_unipro           154
-  sclk_pwm              155
-  sclk_gscl_wa          156
-  sclk_gscl_wb          157
-  sclk_hdmiphy          158
-
-   [Peripheral Clock Gates]
-
-  Clock                 ID
-  ----------------------------
-
-  aclk66_peric          256
-  uart0                 257
-  uart1                 258
-  uart2                 259
-  uart3                 260
-  i2c0                  261
-  i2c1                  262
-  i2c2                  263
-  i2c3                  264
-  i2c4                  265
-  i2c5                  266
-  i2c6                  267
-  i2c7                  268
-  i2c_hdmi              269
-  tsadc                 270
-  spi0                  271
-  spi1                  272
-  spi2                  273
-  keyif                 274
-  i2s1                  275
-  i2s2                  276
-  pcm1                  277
-  pcm2                  278
-  pwm                   279
-  spdif                 280
-  i2c8                  281
-  i2c9                  282
-  i2c10                 283
-  aclk66_psgen          300
-  chipid                301
-  sysreg                302
-  tzpc0                 303
-  tzpc1                 304
-  tzpc2                 305
-  tzpc3                 306
-  tzpc4                 307
-  tzpc5                 308
-  tzpc6                 309
-  tzpc7                 310
-  tzpc8                 311
-  tzpc9                 312
-  hdmi_cec              313
-  seckey                314
-  mct                   315
-  wdt                   316
-  rtc                   317
-  tmu                   318
-  tmu_gpu               319
-  pclk66_gpio           330
-  aclk200_fsys2         350
-  mmc0                  351
-  mmc1                  352
-  mmc2                  353
-  sromc                 354
-  ufs                   355
-  aclk200_fsys          360
-  tsi                   361
-  pdma0                 362
-  pdma1                 363
-  rtic                  364
-  usbh20                365
-  usbd300               366
-  usbd301               377
-  aclk400_mscl          380
-  mscl0                 381
-  mscl1                 382
-  mscl2                 383
-  smmu_mscl0            384
-  smmu_mscl1            385
-  smmu_mscl2            386
-  aclk333               400
-  mfc                   401
-  smmu_mfcl             402
-  smmu_mfcr             403
-  aclk200_disp1         410
-  dsim1                 411
-  dp1                   412
-  hdmi                  413
-  aclk300_disp1         420
-  fimd1                 421
-  smmu_fimd1            422
-  aclk166               430
-  mixer                 431
-  aclk266               440
-  rotator               441
-  mdma1                 442
-  smmu_rotator          443
-  smmu_mdma1            444
-  aclk300_jpeg          450
-  jpeg                  451
-  jpeg2                 452
-  smmu_jpeg             453
-  aclk300_gscl          460
-  smmu_gscl0            461
-  smmu_gscl1            462
-  gscl_wa               463
-  gscl_wb               464
-  gscl0                 465
-  gscl1                 466
-  clk_3aa               467
-  aclk266_g2d           470
-  sss                   471
-  slim_sss              472
-  mdma0                 473
-  aclk333_g2d           480
-  g2d                   481
-  aclk333_432_gscl      490
-  smmu_3aa              491
-  smmu_fimcl0           492
-  smmu_fimcl1           493
-  smmu_fimcl3           494
-  fimc_lite3            495
-  aclk_g3d              500
-  g3d                   501
-  smmu_mixer            502
-
-  Mux                   ID
-  ----------------------------
-
-  mout_hdmi             640
-
-  Divider               ID
-  ----------------------------
-
-  dout_pixel            768
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5420.h header and can be used in device
+tree sources.
 
 Example 1: An example of a clock controller node is listed below.
 
@@ -208,6 +36,6 @@ Example 2: UART controller node that consumes the clock generated by the clock
                 compatible = "samsung,exynos4210-uart";
                 reg = <0x13820000 0x100>;
                 interrupts = <0 54 0>;
-                clocks = <&clock 259>, <&clock 130>;
+                clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
                 clock-names = "uart", "clk_uart_baud0";
         };
diff --git a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
index 9955dc9c7d96..5f7005f73058 100644
--- a/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
+++ b/Documentation/devicetree/bindings/clock/exynos5440-clock.txt
@@ -12,45 +12,12 @@ Required Properties:
 
 - #clock-cells: should be 1.
 
-The following is the list of clocks generated by the controller. Each clock is
-assigned an identifier and client nodes use this identifier to specify the
-clock which they consume.
-
-
-       [Core Clocks]
-
-  Clock                 ID
-  ----------------------------
-
-  xtal                  1
-  arm_clk               2
-
-   [Peripheral Clock Gates]
-
-  Clock                 ID
-  ----------------------------
-
-  spi_baud              16
-  pb0_250               17
-  pr0_250               18
-  pr1_250               19
-  b_250                 20
-  b_125                 21
-  b_200                 22
-  sata                  23
-  usb                   24
-  gmac0                 25
-  cs250                 26
-  pb0_250_o             27
-  pr0_250_o             28
-  pr1_250_o             29
-  b_250_o               30
-  b_125_o               31
-  b_200_o               32
-  sata_o                33
-  usb_o                 34
-  gmac0_o               35
-  cs250_o               36
+Each clock is assigned an identifier and client nodes can use this identifier
+to specify the clock which they consume.
+
+All available clocks are defined as preprocessor macros in
+dt-bindings/clock/exynos5440.h header and can be used in device
+tree sources.
 
 Example: An example of a clock controller node is listed below.
 
diff --git a/Documentation/devicetree/bindings/clock/hi3620-clock.txt b/Documentation/devicetree/bindings/clock/hi3620-clock.txt
index 4b71ab41be53..dad6269f52c5 100644
--- a/Documentation/devicetree/bindings/clock/hi3620-clock.txt
+++ b/Documentation/devicetree/bindings/clock/hi3620-clock.txt
@@ -7,6 +7,7 @@ Required Properties:
 
 - compatible: should be one of the following.
   - "hisilicon,hi3620-clock" - controller compatible with Hi3620 SoC.
+  - "hisilicon,hi3620-mmc-clock" - controller specific for Hi3620 mmc.
 
 - reg: physical base address of the controller and length of memory mapped
   region.
diff --git a/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
new file mode 100644
index 000000000000..fedea84314a1
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/moxa,moxart-clock.txt
@@ -0,0 +1,48 @@
+Device Tree Clock bindings for arch-moxart
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+MOXA ART SoCs allow to determine PLL output and APB frequencies
+by reading registers holding multiplier and divisor information.
+
+
+PLL:
+
+Required properties:
+- compatible : Must be "moxa,moxart-pll-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clocks : Should contain phandle + clock-specifier for the parent clock
+
+Optional properties:
+- clock-output-names : Should contain clock name
+
+
+APB:
+
+Required properties:
+- compatible : Must be "moxa,moxart-apb-clock"
+- #clock-cells : Should be 0
+- reg : Should contain registers location and length
+- clocks : Should contain phandle + clock-specifier for the parent clock
+
+Optional properties:
+- clock-output-names : Should contain clock name
+
+
+For example:
+
+        clk_pll: clk_pll@98100000 {
+                compatible = "moxa,moxart-pll-clock";
+                #clock-cells = <0>;
+                reg = <0x98100000 0x34>;
+        };
+
+        clk_apb: clk_apb@98100000 {
+                compatible = "moxa,moxart-apb-clock";
+                #clock-cells = <0>;
+                reg = <0x98100000 0x34>;
+                clocks = <&clk_pll>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
index 1e662948661e..307a503c5db8 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-core-clock.txt
@@ -11,6 +11,18 @@ The following is a list of provided IDs and clock names on Armada 370/XP:
  3 = hclk    (DRAM control clock)
  4 = dramclk (DDR clock)
 
+The following is a list of provided IDs and clock names on Armada 375:
+ 0 = tclk    (Internal Bus clock)
+ 1 = cpuclk  (CPU clock)
+ 2 = l2clk   (L2 Cache clock)
+ 3 = ddrclk  (DDR clock)
+
+The following is a list of provided IDs and clock names on Armada 380/385:
+ 0 = tclk    (Internal Bus clock)
+ 1 = cpuclk  (CPU clock)
+ 2 = l2clk   (L2 Cache clock)
+ 3 = ddrclk  (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)
@@ -20,6 +32,8 @@ The following is a list of provided IDs and clock names on Kirkwood and Dove:
 Required properties:
 - compatible : shall be one of the following:
         "marvell,armada-370-core-clock" - For Armada 370 SoC core clocks
+        "marvell,armada-375-core-clock" - For Armada 375 SoC core clocks
+        "marvell,armada-380-core-clock" - For Armada 380/385 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)
diff --git a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
index c62391fc0e39..520562a7dc2a 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-corediv-clock.txt
@@ -4,7 +4,10 @@ The following is a list of provided IDs and clock names on Armada 370/XP:
  0 = nand (NAND clock)
 
 Required properties:
-- compatible : must be "marvell,armada-370-corediv-clock"
+- compatible : must be "marvell,armada-370-corediv-clock",
+                       "marvell,armada-375-corediv-clock",
+                       "marvell,armada-380-corediv-clock",
+
 - reg : must be the register address of Core Divider control register
 - #clock-cells : from common clock binding; shall be set to 1
 - clocks : must be set to the parent's phandle
diff --git a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
index fc2910fa7e45..76477be742b2 100644
--- a/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
+++ b/Documentation/devicetree/bindings/clock/mvebu-gated-clock.txt
@@ -1,9 +1,10 @@
 * Gated Clock bindings for Marvell EBU SoCs
 
-Marvell Armada 370/XP, Dove and Kirkwood allow some peripheral clocks to be
-gated to save some power. The clock consumer should specify the desired clock
-by having the clock ID in its "clocks" phandle cell. The clock ID is directly
-mapped to the corresponding clock gating control bit in HW to ease manual clock
+Marvell Armada 370/375/380/385/XP, Dove and Kirkwood allow some
+peripheral clocks to be gated to save some power. The clock consumer
+should specify the desired clock by having the clock ID in its
+"clocks" phandle cell. The clock ID is directly mapped to the
+corresponding clock gating control bit in HW to ease manual clock
 lookup in datasheet.
 
 The following is a list of provided IDs for Armada 370:
@@ -22,6 +23,60 @@ ID	Clock	Peripheral
 28      ddr     DDR Cntrl
 30      sata1   SATA Host 0
 
+The following is a list of provided IDs for Armada 375:
+ID      Clock           Peripheral
+-----------------------------------
+2       mu              Management Unit
+3       pp              Packet Processor
+4       ptp             PTP
+5       pex0            PCIe 0 Clock out
+6       pex1            PCIe 1 Clock out
+8       audio           Audio Cntrl
+11      nd_clk          Nand Flash Cntrl
+14      sata0_link      SATA 0 Link
+15      sata0_core      SATA 0 Core
+16      usb3            USB3 Host
+17      sdio            SDHCI Host
+18      usb             USB Host
+19      gop             Gigabit Ethernet MAC
+20      sata1_link      SATA 1 Link
+21      sata1_core      SATA 1 Core
+22      xor0            XOR DMA 0
+23      xor1            XOR DMA 0
+24      copro           Coprocessor
+25      tdm             Time Division Mplx
+28      crypto0_enc     Cryptographic Unit Port 0 Encryption
+29      crypto0_core    Cryptographic Unit Port 0 Core
+30      crypto1_enc     Cryptographic Unit Port 1 Encryption
+31      crypto1_core    Cryptographic Unit Port 1 Core
+
+The following is a list of provided IDs for Armada 380/385:
+ID      Clock           Peripheral
+-----------------------------------
+0       audio           Audio
+2       ge2             Gigabit Ethernet 2
+3       ge1             Gigabit Ethernet 1
+4       ge0             Gigabit Ethernet 0
+5       pex1            PCIe 1
+6       pex2            PCIe 2
+7       pex3            PCIe 3
+8       pex0            PCIe 0
+9       usb3h0          USB3 Host 0
+10      usb3h1          USB3 Host 1
+11      usb3d           USB3 Device
+13      bm              Buffer Management
+14      crypto0z        Cryptographic 0 Z
+15      sata0           SATA 0
+16      crypto1z        Cryptographic 1 Z
+17      sdio            SDIO
+18      usb2            USB 2
+21      crypto1         Cryptographic 1
+22      xor0            XOR 0
+23      crypto0         Cryptographic 0
+25      tdm             Time Division Multiplexing
+28      xor1            XOR 1
+30      sata1           SATA 1
+
 The following is a list of provided IDs for Armada XP:
 ID      Clock   Peripheral
 -----------------------------------
@@ -95,6 +150,8 @@ ID	Clock	Peripheral
 Required properties:
 - compatible : shall be one of the following:
         "marvell,armada-370-gating-clock" - for Armada 370 SoC clock gating
+        "marvell,armada-375-gating-clock" - for Armada 375 SoC clock gating
+        "marvell,armada-380-gating-clock" - for Armada 380/385 SoC clock gating
         "marvell,armada-xp-gating-clock" - for Armada XP SoC clock gating
         "marvell,dove-gating-clock" - for Dove SoC clock gating
         "marvell,kirkwood-gating-clock" - for Kirkwood SoC clock gating
diff --git a/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt
new file mode 100644
index 000000000000..98a257492522
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt
@@ -0,0 +1,29 @@
+* Renesas RZ Clock Pulse Generator (CPG)
+
+The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
+CPU and GPU clocks, and several fixed ratio dividers.
+
+Required Properties:
+
+  - compatible: Must be one of
+    - "renesas,r7s72100-cpg-clocks" for the r7s72100 CPG
+    - "renesas,rz-cpg-clocks" for the generic RZ CPG
+  - reg: Base address and length of the memory resource used by the CPG
+  - clocks: References to possible parent clocks. Order must match clock modes
+    in the datasheet. For the r7s72100, this is extal, usb_x1.
+  - #clock-cells: Must be 1
+  - clock-output-names: The names of the clocks. Supported clocks are "pll",
+    "i", and "g"
+
+
+Example
+-------
+
+        cpg_clocks: cpg_clocks@fcfe0000 {
+                #clock-cells = <1>;
+                compatible = "renesas,r7s72100-cpg-clocks",
+                             "renesas,rz-cpg-clocks";
+                reg = <0xfcfe0000 0x18>;
+                clocks = <&extal_clk>, <&usb_x1_clk>;
+                clock-output-names = "pll", "i", "g";
+        };
diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt
new file mode 100644
index 000000000000..ae56315fcec5
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-divmux.txt
@@ -0,0 +1,49 @@
+Binding for a ST divider and multiplexer clock driver.
+
+This binding uses the common clock binding[1].
+Base address is located to the parent node. See clock binding[2]
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt
+
+Required properties:
+
+- compatible : shall be:
+        "st,clkgena-divmux-c65-hs",     "st,clkgena-divmux"
+        "st,clkgena-divmux-c65-ls",     "st,clkgena-divmux"
+        "st,clkgena-divmux-c32-odf0",   "st,clkgena-divmux"
+        "st,clkgena-divmux-c32-odf1",   "st,clkgena-divmux"
+        "st,clkgena-divmux-c32-odf2",   "st,clkgena-divmux"
+        "st,clkgena-divmux-c32-odf3",   "st,clkgena-divmux"
+
+- #clock-cells : From common clock binding; shall be set to 1.
+
+- clocks : From common clock binding
+
+- clock-output-names : From common clock binding.
+
+Example:
+
+        clockgenA@fd345000 {
+                reg = <0xfd345000 0xb50>;
+
+                CLK_M_A1_DIV1: CLK_M_A1_DIV1 {
+                        #clock-cells = <1>;
+                        compatible = "st,clkgena-divmux-c32-odf1",
+                                     "st,clkgena-divmux";
+
+                        clocks = <&CLK_M_A1_OSC_PREDIV>,
+                                 <&CLK_M_A1_PLL0 1>, /* PLL0 PHI1 */
+                                 <&CLK_M_A1_PLL1 1>; /* PLL1 PHI1 */
+
+                        clock-output-names = "CLK_M_RX_ICN_TS",
+                                             "CLK_M_RX_ICN_VDP_0",
+                                             "", /* Unused */
+                                             "CLK_M_PRV_T1_BUS",
+                                             "CLK_M_ICN_REG_12",
+                                             "CLK_M_ICN_REG_10",
+                                             "", /* Unused */
+                                             "CLK_M_ICN_ST231";
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
new file mode 100644
index 000000000000..943e0808e212
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-mux.txt
@@ -0,0 +1,36 @@
+Binding for a ST multiplexed clock driver.
+
+This binding supports only simple indexed multiplexers, it does not
+support table based parent index to hardware value translations.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+
+- compatible : shall be:
+        "st,stih416-clkgenc-vcc-hd",    "st,clkgen-mux"
+        "st,stih416-clkgenf-vcc-fvdp",  "st,clkgen-mux"
+        "st,stih416-clkgenf-vcc-hva",   "st,clkgen-mux"
+        "st,stih416-clkgenf-vcc-hd",    "st,clkgen-mux"
+        "st,stih416-clkgenf-vcc-sd",    "st,clkgen-mux"
+        "st,stih415-clkgen-a9-mux",     "st,clkgen-mux"
+        "st,stih416-clkgen-a9-mux",     "st,clkgen-mux"
+
+
+- #clock-cells : from common clock binding; shall be set to 0.
+
+- reg : A Base address and length of the register set.
+
+- clocks : from common clock binding
+
+Example:
+
+        CLK_M_HVA: CLK_M_HVA {
+                #clock-cells = <0>;
+                compatible = "st,stih416-clkgenf-vcc-hva", "st,clkgen-mux";
+                reg = <0xfd690868 4>;
+
+                clocks = <&CLOCKGEN_F 1>, <&CLK_M_A1_DIV0 3>;
+        };
diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
new file mode 100644
index 000000000000..81eb3855ab92
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
@@ -0,0 +1,48 @@
+Binding for a ST pll clock driver.
+
+This binding uses the common clock binding[1].
+Base address is located to the parent node. See clock binding[2]
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt
+
+Required properties:
+
+- compatible : shall be:
+        "st,clkgena-prediv-c65",        "st,clkgena-prediv"
+        "st,clkgena-prediv-c32",        "st,clkgena-prediv"
+
+        "st,clkgena-plls-c65"
+        "st,plls-c32-a1x-0",            "st,clkgen-plls-c32"
+        "st,plls-c32-a1x-1",            "st,clkgen-plls-c32"
+        "st,stih415-plls-c32-a9",       "st,clkgen-plls-c32"
+        "st,stih415-plls-c32-ddr",      "st,clkgen-plls-c32"
+        "st,stih416-plls-c32-a9",       "st,clkgen-plls-c32"
+        "st,stih416-plls-c32-ddr",      "st,clkgen-plls-c32"
+
+        "st,stih415-gpu-pll-c32",       "st,clkgengpu-pll-c32"
+        "st,stih416-gpu-pll-c32",       "st,clkgengpu-pll-c32"
+
+
+- #clock-cells : From common clock binding; shall be set to 1.
+
+- clocks : From common clock binding
+
+- clock-output-names : From common clock binding.
+
+Example:
+
+        clockgenA@fee62000 {
+                reg = <0xfee62000 0xb48>;
+
+                CLK_S_A0_PLL: CLK_S_A0_PLL {
+                        #clock-cells = <1>;
+                        compatible = "st,clkgena-plls-c65";
+
+                        clocks = <&CLK_SYSIN>;
+
+                        clock-output-names = "CLK_S_A0_PLL0_HS",
+                                             "CLK_S_A0_PLL0_LS",
+                                             "CLK_S_A0_PLL1";
+                };
+        };
diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt
new file mode 100644
index 000000000000..566c9d79ed32
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-prediv.txt
@@ -0,0 +1,36 @@
+Binding for a ST pre-divider clock driver.
+
+This binding uses the common clock binding[1].
+Base address is located to the parent node. See clock binding[2]
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/st/st,clkgen.txt
+
+Required properties:
+
+- compatible : shall be:
+        "st,clkgena-prediv-c65",        "st,clkgena-prediv"
+        "st,clkgena-prediv-c32",        "st,clkgena-prediv"
+
+- #clock-cells : From common clock binding; shall be set to 0.
+
+- clocks : From common clock binding
+
+- clock-output-names : From common clock binding.
+
+Example:
+
+        clockgenA@fd345000 {
+                reg = <0xfd345000 0xb50>;
+
+                CLK_M_A2_OSC_PREDIV: CLK_M_A2_OSC_PREDIV {
+                        #clock-cells = <0>;
+                        compatible = "st,clkgena-prediv-c32",
+                                     "st,clkgena-prediv";
+
+                        clocks = <&CLK_SYSIN>;
+
+                        clock-output-names = "CLK_M_A2_OSC_PREDIV";
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt
new file mode 100644
index 000000000000..4e3ff28b04c3
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-vcc.txt
@@ -0,0 +1,53 @@
+Binding for a type of STMicroelectronics clock crossbar (VCC).
+
+The crossbar can take up to 4 input clocks and control up to 16
+output clocks. Not all inputs or outputs have to be in use in a
+particular instantiation. Each output can be individually enabled,
+select any of the input clocks and apply a divide (by 1,2,4 or 8) to
+that selected clock.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+
+- compatible : shall be:
+        "st,stih416-clkgenc",           "st,vcc"
+        "st,stih416-clkgenf",           "st,vcc"
+
+- #clock-cells : from common clock binding; shall be set to 1.
+
+- reg : A Base address and length of the register set.
+
+- clocks : from common clock binding
+
+- clock-output-names : From common clock binding. The block has 16
+                       clock outputs but not all of them in a specific instance
+                       have to be used in the SoC. If a clock name is left as
+                       an empty string then no clock will be created for the
+                       output associated with that string index. If fewer than
+                       16 strings are provided then no clocks will be created
+                       for the remaining outputs.
+
+Example:
+
+        CLOCKGEN_C_VCC: CLOCKGEN_C_VCC {
+                #clock-cells = <1>;
+                compatible = "st,stih416-clkgenc", "st,clkgen-vcc";
+                reg = <0xfe8308ac 12>;
+
+                clocks = <&CLK_S_VCC_HD>, <&CLOCKGEN_C 1>,
+                        <&CLK_S_TMDS_FROMPHY>, <&CLOCKGEN_C 2>;
+
+                clock-output-names  =
+                        "CLK_S_PIX_HDMI",  "CLK_S_PIX_DVO",
+                        "CLK_S_OUT_DVO",   "CLK_S_PIX_HD",
+                        "CLK_S_HDDAC",     "CLK_S_DENC",
+                        "CLK_S_SDDAC",     "CLK_S_PIX_MAIN",
+                        "CLK_S_PIX_AUX",   "CLK_S_STFE_FRC_0",
+                        "CLK_S_REF_MCRU",  "CLK_S_SLAVE_MCRU",
+                        "CLK_S_TMDS_HDMI", "CLK_S_HDMI_REJECT_PLL",
+                        "CLK_S_THSENS";
+        };
+
diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
new file mode 100644
index 000000000000..49ec5ae18b5b
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,clkgen.txt
@@ -0,0 +1,83 @@
+Binding for a Clockgen hardware block found on
+certain STMicroelectronics consumer electronics SoC devices.
+
+A Clockgen node can contain pll, diviser or multiplexer nodes.
+
+We will find only the base address of the Clockgen, this base
+address is common of all subnode.
+
+        clockgen_node {
+                reg = <>;
+
+                pll_node {
+                        ...
+                };
+
+                prediv_node {
+                        ...
+                };
+
+                divmux_node {
+                        ...
+                };
+
+                quadfs_node {
+                        ...
+                };
+                ...
+        };
+
+This binding uses the common clock binding[1].
+Each subnode should use the binding discribe in [2]..[4]
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+[2] Documentation/devicetree/bindings/clock/st,quadfs.txt
+[3] Documentation/devicetree/bindings/clock/st,quadfs.txt
+[4] Documentation/devicetree/bindings/clock/st,quadfs.txt
+
+Required properties:
+- reg : A Base address and length of the register set.
+
+Example:
+
+        clockgenA@fee62000 {
+
+                reg = <0xfee62000 0xb48>;
+
+                CLK_S_A0_PLL: CLK_S_A0_PLL {
+                        #clock-cells = <1>;
+                        compatible = "st,clkgena-plls-c65";
+
+                        clocks = <&CLK_SYSIN>;
+
+                        clock-output-names = "CLK_S_A0_PLL0_HS",
+                                             "CLK_S_A0_PLL0_LS",
+                                             "CLK_S_A0_PLL1";
+                };
+
+                CLK_S_A0_OSC_PREDIV: CLK_S_A0_OSC_PREDIV {
+                        #clock-cells = <0>;
+                        compatible = "st,clkgena-prediv-c65",
+                                     "st,clkgena-prediv";
+
+                        clocks = <&CLK_SYSIN>;
+
+                        clock-output-names = "CLK_S_A0_OSC_PREDIV";
+                };
+
+                CLK_S_A0_HS: CLK_S_A0_HS {
+                        #clock-cells = <1>;
+                        compatible = "st,clkgena-divmux-c65-hs",
+                                     "st,clkgena-divmux";
+
+                        clocks = <&CLK_S_A0_OSC_PREDIV>,
+                                 <&CLK_S_A0_PLL 0>, /* PLL0 HS */
+                                 <&CLK_S_A0_PLL 2>; /* PLL1 */
+
+                        clock-output-names = "CLK_S_FDMA_0",
+                                             "CLK_S_FDMA_1",
+                                             ""; /* CLK_S_JIT_SENSE */
+                                             /* Fourth output unused */
+                };
+        };
+
diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt
new file mode 100644
index 000000000000..ec86d62ca283
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt
@@ -0,0 +1,45 @@
+Binding for a type of quad channel digital frequency synthesizer found on
+certain STMicroelectronics consumer electronics SoC devices.
+
+This version contains a programmable PLL which can generate up to 216, 432
+or 660MHz (from a 30MHz oscillator input) as the input to the digital
+synthesizers.
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible : shall be:
+  "st,stih416-quadfs216",       "st,quadfs"
+  "st,stih416-quadfs432",       "st,quadfs"
+  "st,stih416-quadfs660-E",     "st,quadfs"
+  "st,stih416-quadfs660-F",     "st,quadfs"
+
+- #clock-cells : from common clock binding; shall be set to 1.
+
+- reg : A Base address and length of the register set.
+
+- clocks : from common clock binding
+
+- clock-output-names : From common clock binding. The block has 4
+                       clock outputs but not all of them in a specific instance
+                       have to be used in the SoC. If a clock name is left as
+                       an empty string then no clock will be created for the
+                       output associated with that string index. If fewer than
+                       4 strings are provided then no clocks will be created
+                       for the remaining outputs.
+
+Example:
+
+        CLOCKGEN_E: CLOCKGEN_E {
+                #clock-cells = <1>;
+                compatible = "st,stih416-quadfs660-E", "st,quadfs";
+                reg = <0xfd3208bc 0xB0>;
+
+                clocks = <&CLK_SYSIN>;
+                clock-output-names = "CLK_M_PIX_MDTP_0",
+                                        "CLK_M_PIX_MDTP_1",
+                                        "CLK_M_PIX_MDTP_2",
+                                        "CLK_M_MPELPC";
+        };
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
index c2cb7621ad2d..a5160d8cbb5f 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -6,37 +6,41 @@ This binding uses the common clock binding[1].
 
 Required properties:
 - compatible : shall be one of the following:
-        "allwinner,sun4i-osc-clk" - for a gatable oscillator
-        "allwinner,sun4i-pll1-clk" - for the main PLL clock and PLL4
+        "allwinner,sun4i-a10-osc-clk" - for a gatable oscillator
+        "allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
         "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
-        "allwinner,sun4i-pll5-clk" - for the PLL5 clock
-        "allwinner,sun4i-pll6-clk" - for the PLL6 clock
-        "allwinner,sun4i-cpu-clk" - for the CPU multiplexer clock
-        "allwinner,sun4i-axi-clk" - for the AXI clock
-        "allwinner,sun4i-axi-gates-clk" - for the AXI gates
-        "allwinner,sun4i-ahb-clk" - for the AHB clock
-        "allwinner,sun4i-ahb-gates-clk" - for the AHB gates on A10
+        "allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
+        "allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
+        "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
+        "allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
+        "allwinner,sun4i-a10-axi-clk" - for the AXI clock
+        "allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
+        "allwinner,sun4i-a10-ahb-clk" - for the AHB clock
+        "allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
         "allwinner,sun5i-a13-ahb-gates-clk" - for the AHB gates on A13
         "allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
         "allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
         "allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
         "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
-        "allwinner,sun4i-apb0-clk" - for the APB0 clock
-        "allwinner,sun4i-apb0-gates-clk" - for the APB0 gates on A10
+        "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
+        "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
         "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
         "allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
         "allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
-        "allwinner,sun4i-apb1-clk" - for the APB1 clock
-        "allwinner,sun4i-apb1-mux-clk" - for the APB1 clock muxing
-        "allwinner,sun4i-apb1-gates-clk" - for the APB1 gates on A10
+        "allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
+        "allwinner,sun4i-a10-apb1-mux-clk" - for the APB1 clock muxing
+        "allwinner,sun4i-a10-apb1-gates-clk" - for the APB1 gates on A10
         "allwinner,sun5i-a13-apb1-gates-clk" - for the APB1 gates on A13
         "allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
         "allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
         "allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
         "allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
         "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
-        "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
+        "allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
         "allwinner,sun7i-a20-out-clk" - for the external output clocks
+        "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
+        "allwinner,sun4i-a10-usb-clk" - for usb gates + resets on A10 / A20
+        "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
 
 Required properties for all clocks:
 - reg : shall be the control register address for the clock.
@@ -44,10 +48,17 @@ Required properties for all clocks:
         multiplexed clocks, the list order must match the hardware
         programming order.
 - #clock-cells : from common clock binding; shall be set to 0 except for
-        "allwinner,*-gates-clk" where it shall be set to 1
+        "allwinner,*-gates-clk", "allwinner,sun4i-pll5-clk" and
+        "allwinner,sun4i-pll6-clk" where it shall be set to 1
+- clock-output-names : shall be the corresponding names of the outputs.
+        If the clock module only has one output, the name shall be the
+        module name.
 
-Additionally, "allwinner,*-gates-clk" clocks require:
-- clock-output-names : the corresponding gate names that the clock controls
+And "allwinner,*-usb-clk" clocks also require:
+- reset-cells : shall be set to 1
+
+For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
+dummy clocks at 25 MHz and 125 MHz, respectively. See example.
 
 Clock consumers should specify the desired clocks they use with a
 "clocks" phandle cell. Consumers that are using a gated clock should
@@ -56,23 +67,68 @@ offset of the bit controlling this particular gate in the register.
 
 For example:
 
-osc24M: osc24M@01c20050 {
+osc24M: clk@01c20050 {
         #clock-cells = <0>;
-        compatible = "allwinner,sun4i-osc-clk";
+        compatible = "allwinner,sun4i-a10-osc-clk";
         reg = <0x01c20050 0x4>;
         clocks = <&osc24M_fixed>;
+        clock-output-names = "osc24M";
 };
 
-pll1: pll1@01c20000 {
+pll1: clk@01c20000 {
         #clock-cells = <0>;
-        compatible = "allwinner,sun4i-pll1-clk";
+        compatible = "allwinner,sun4i-a10-pll1-clk";
         reg = <0x01c20000 0x4>;
         clocks = <&osc24M>;
+        clock-output-names = "pll1";
+};
+
+pll5: clk@01c20020 {
+        #clock-cells = <1>;
+        compatible = "allwinner,sun4i-pll5-clk";
+        reg = <0x01c20020 0x4>;
+        clocks = <&osc24M>;
+        clock-output-names = "pll5_ddr", "pll5_other";
 };
 
 cpu: cpu@01c20054 {
         #clock-cells = <0>;
-        compatible = "allwinner,sun4i-cpu-clk";
+        compatible = "allwinner,sun4i-a10-cpu-clk";
         reg = <0x01c20054 0x4>;
         clocks = <&osc32k>, <&osc24M>, <&pll1>;
+        clock-output-names = "cpu";
+};
+
+mmc0_clk: clk@01c20088 {
+        #clock-cells = <0>;
+        compatible = "allwinner,sun4i-mod0-clk";
+        reg = <0x01c20088 0x4>;
+        clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
+        clock-output-names = "mmc0";
+};
+
+mii_phy_tx_clk: clk@2 {
+        #clock-cells = <0>;
+        compatible = "fixed-clock";
+        clock-frequency = <25000000>;
+        clock-output-names = "mii_phy_tx";
+};
+
+gmac_int_tx_clk: clk@3 {
+        #clock-cells = <0>;
+        compatible = "fixed-clock";
+        clock-frequency = <125000000>;
+        clock-output-names = "gmac_int_tx";
+};
+
+gmac_clk: clk@01c20164 {
+        #clock-cells = <0>;
+        compatible = "allwinner,sun7i-a20-gmac-clk";
+        reg = <0x01c20164 0x4>;
+        /*
+         * The first clock must be fixed at 25MHz;
+         * the second clock must be fixed at 125MHz
+         */
+        clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
+        clock-output-names = "gmac";
 };
diff --git a/Documentation/devicetree/bindings/clock/zynq-7000.txt b/Documentation/devicetree/bindings/clock/zynq-7000.txt
index 17b4a94916d6..d93746cf2975 100644
--- a/Documentation/devicetree/bindings/clock/zynq-7000.txt
+++ b/Documentation/devicetree/bindings/clock/zynq-7000.txt
@@ -14,6 +14,7 @@ for all clock consumers of PS clocks.
 Required properties:
  - #clock-cells : Must be 1
  - compatible : "xlnx,ps7-clkc"
+ - reg : SLCR offset and size taken via syscon < 0x100 0x100 >
  - ps-clk-frequency : Frequency of the oscillator providing ps_clk in HZ
                       (usually 33 MHz oscillators are used for Zynq platforms)
  - clock-output-names : List of strings used to name the clock outputs. Shall be
@@ -87,10 +88,11 @@ Clock outputs:
  47: dbg_apb
 
 Example:
-        clkc: clkc {
+        clkc: clkc@100 {
                 #clock-cells = <1>;
                 compatible = "xlnx,ps7-clkc";
                 ps-clk-frequency = <33333333>;
+                reg = <0x100 0x100>;
                 clock-output-names = "armpll", "ddrpll", "iopll", "cpu_6or4x",
                                 "cpu_3or2x", "cpu_2x", "cpu_1x", "ddr2x", "ddr3x",
                                 "dci", "lqspi", "smc", "pcap", "gem0", "gem1",
diff --git a/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt
new file mode 100644
index 000000000000..94ae9f82dcf8
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/cirrus,clps711x-mctrl-gpio.txt
@@ -0,0 +1,17 @@
+* ARM Cirrus Logic CLPS711X SYSFLG1 MCTRL GPIOs
+
+Required properties:
+- compatible: Should contain "cirrus,clps711x-mctrl-gpio".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+    0 = Active high,
+    1 = Active low.
+
+Example:
+        sysgpio: sysgpio {
+                compatible = "cirrus,ep7312-mctrl-gpio",
+                             "cirrus,clps711x-mctrl-gpio";
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
index a2e839d6e338..5079ba7d6568 100644
--- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt
@@ -1,13 +1,17 @@
-Davinci GPIO controller bindings
+Davinci/Keystone GPIO controller bindings
 
 Required Properties:
-- compatible: should be "ti,dm6441-gpio"
+- compatible: should be "ti,dm6441-gpio", "ti,keystone-gpio"
 
 - reg: Physical base address of the controller and the size of memory mapped
        registers.
 
 - gpio-controller : Marks the device node as a gpio controller.
 
+- #gpio-cells : Should be two.
+  - first cell is the pin number
+  - second cell is used to specify optional parameters (unused)
+
 - interrupt-parent: phandle of the parent interrupt controller.
 
 - interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are
@@ -27,6 +31,7 @@ Example:
 gpio: gpio@1e26000 {
         compatible = "ti,dm6441-gpio";
         gpio-controller;
+        #gpio-cells = <2>;
         reg = <0x226000 0x1000>;
         interrupt-parent = <&intc>;
         interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH
@@ -39,3 +44,19 @@ gpio: gpio@1e26000 {
         interrupt-controller;
         #interrupt-cells = <2>;
 };
+
+leds {
+        compatible = "gpio-leds";
+
+        led1 {
+                label = "davinci:green:usr1";
+                gpios = <&gpio 10 GPIO_ACTIVE_HIGH>;
+                ...
+        };
+
+        led2 {
+                label = "davinci:red:debug1";
+                gpios = <&gpio 11 GPIO_ACTIVE_HIGH>;
+                ...
+        };
+};
diff --git a/Documentation/devicetree/bindings/gpio/gpio-zevio.txt b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
new file mode 100644
index 000000000000..a37bd9ae2730
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/gpio-zevio.txt
@@ -0,0 +1,16 @@
+Zevio GPIO controller
+
+Required properties:
+- compatible: Should be "lsi,zevio-gpio"
+- reg: Address and length of the register set for the device
+- #gpio-cells: Should be two. The first cell is the pin number and the
+  second cell is used to specify optional parameters (currently unused).
+- gpio-controller: Marks the device node as a GPIO controller.
+
+Example:
+        gpio: gpio@90000000 {
+                compatible = "lsi,zevio-gpio";
+                reg = <0x90000000 0x1000>;
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt
index 0c85bb6e3a80..3fb8f53071b8 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -13,11 +13,11 @@ properties, each containing a 'gpio-list':
         gpio-specifier : Array of #gpio-cells specifying specific gpio
                          (controller specific)
 
-GPIO properties should be named "[<name>-]gpios".  Exact
+GPIO properties should be named "[<name>-]gpios". The exact
 meaning of each gpios property must be documented in the device tree
 binding for each device.
 
-For example, the following could be used to describe gpios pins to use
+For example, the following could be used to describe GPIO pins used
 as chip select lines; with chip selects 0, 1 and 3 populated, and chip
 select 2 left empty:
 
@@ -44,35 +44,79 @@ whether pin is open-drain and whether pin is logically inverted.
 Exact meaning of each specifier cell is controller specific, and must
 be documented in the device tree binding for the device.
 
-Example of the node using GPIOs:
+Example of a node using GPIOs:
 
         node {
                 gpios = <&qe_pio_e 18 0>;
         };
 
 In this example gpio-specifier is "18 0" and encodes GPIO pin number,
-and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller.
+and GPIO flags as accepted by the "qe_pio_e" gpio-controller.
+
+1.1) GPIO specifier best practices
+----------------------------------
+
+A gpio-specifier should contain a flag indicating the GPIO polarity; active-
+high or active-low. If it does, the follow best practices should be followed:
+
+The gpio-specifier's polarity flag should represent the physical level at the
+GPIO controller that achieves (or represents, for inputs) a logically asserted
+value at the device. The exact definition of logically asserted should be
+defined by the binding for the device. If the board inverts the signal between
+the GPIO controller and the device, then the gpio-specifier will represent the
+opposite physical level than the signal at the device's pin.
+
+When the device's signal polarity is configurable, the binding for the
+device must either:
+
+a) Define a single static polarity for the signal, with the expectation that
+any software using that binding would statically program the device to use
+that signal polarity.
+
+The static choice of polarity may be either:
+
+a1) (Preferred) Dictated by a binding-specific DT property.
+
+or:
+
+a2) Defined statically by the DT binding itself.
+
+In particular, the polarity cannot be derived from the gpio-specifier, since
+that would prevent the DT from separately representing the two orthogonal
+concepts of configurable signal polarity in the device, and possible board-
+level signal inversion.
+
+or:
+
+b) Pick a single option for device signal polarity, and document this choice
+in the binding. The gpio-specifier should represent the polarity of the signal
+(at the GPIO controller) assuming that the device is configured for this
+particular signal polarity choice. If software chooses to program the device
+to generate or receive a signal of the opposite polarity, software will be
+responsible for correctly interpreting (inverting) the GPIO signal at the GPIO
+controller.
 
 2) gpio-controller nodes
 ------------------------
 
-Every GPIO controller node must both an empty "gpio-controller"
-property, and have #gpio-cells contain the size of the gpio-specifier.
+Every GPIO controller node must contain both an empty "gpio-controller"
+property, and a #gpio-cells integer property, which indicates the number of
+cells in a gpio-specifier.
 
 Example of two SOC GPIO banks defined as gpio-controller nodes:
 
         qe_pio_a: gpio-controller@1400 {
-                #gpio-cells = <2>;
                 compatible = "fsl,qe-pario-bank-a", "fsl,qe-pario-bank";
                 reg = <0x1400 0x18>;
                 gpio-controller;
+                #gpio-cells = <2>;
         };
 
         qe_pio_e: gpio-controller@1460 {
-                #gpio-cells = <2>;
                 compatible = "fsl,qe-pario-bank-e", "fsl,qe-pario-bank";
                 reg = <0x1460 0x18>;
                 gpio-controller;
+                #gpio-cells = <2>;
         };
 
 2.1) gpio- and pin-controller interaction
diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
new file mode 100644
index 000000000000..dd5d2c0394b1
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
@@ -0,0 +1,60 @@
+* Synopsys DesignWare APB GPIO controller
+
+Required properties:
+- compatible : Should contain "snps,dw-apb-gpio"
+- reg : Address and length of the register set for the device.
+- #address-cells : should be 1 (for addressing port subnodes).
+- #size-cells : should be 0 (port subnodes).
+
+The GPIO controller has a configurable number of ports, each of which are
+represented as child nodes with the following properties:
+
+Required properties:
+- compatible : "snps,dw-apb-gpio-port"
+- gpio-controller : Marks the device node as a gpio controller.
+- #gpio-cells : Should be two.  The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+      0 = active high
+      1 = active low
+- reg : The integer port index of the port, a single cell.
+
+Optional properties:
+- interrupt-controller : The first port may be configured to be an interrupt
+controller.
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt.  Shall be set to 2.  The first cell defines the interrupt number,
+  the second encodes the triger flags encoded as described in
+  Documentation/devicetree/bindings/interrupts.txt
+- interrupt-parent : The parent interrupt controller.
+- interrupts : The interrupt to the parent controller raised when GPIOs
+  generate the interrupts.
+- snps,nr-gpios : The number of pins in the port, a single cell.
+
+Example:
+
+gpio: gpio@20000 {
+        compatible = "snps,dw-apb-gpio";
+        reg = <0x20000 0x1000>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        porta: gpio-controller@0 {
+                compatible = "snps,dw-apb-gpio-port";
+                gpio-controller;
+                #gpio-cells = <2>;
+                snps,nr-gpios = <8>;
+                reg = <0>;
+                interrupt-controller;
+                #interrupt-cells = <2>;
+                interrupt-parent = <&vic1>;
+                interrupts = <0>;
+        };
+
+        portb: gpio-controller@1 {
+                compatible = "snps,dw-apb-gpio-port";
+                gpio-controller;
+                #gpio-cells = <2>;
+                snps,nr-gpios = <8>;
+                reg = <1>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/graph.txt b/Documentation/devicetree/bindings/graph.txt
new file mode 100644
index 000000000000..1a69c078adf2
--- /dev/null
+++ b/Documentation/devicetree/bindings/graph.txt
@@ -0,0 +1,129 @@
+Common bindings for device graphs
+
+General concept
+---------------
+
+The hierarchical organisation of the device tree is well suited to describe
+control flow to devices, but there can be more complex connections between
+devices that work together to form a logical compound device, following an
+arbitrarily complex graph.
+There already is a simple directed graph between devices tree nodes using
+phandle properties pointing to other nodes to describe connections that
+can not be inferred from device tree parent-child relationships. The device
+tree graph bindings described herein abstract more complex devices that can
+have multiple specifiable ports, each of which can be linked to one or more
+ports of other devices.
+
+These common bindings do not contain any information about the direction or
+type of the connections, they just map their existence. Specific properties
+may be described by specialized bindings depending on the type of connection.
+
+To see how this binding applies to video pipelines, for example, see
+Documentation/device-tree/bindings/media/video-interfaces.txt.
+Here the ports describe data interfaces, and the links between them are
+the connecting data buses. A single port with multiple connections can
+correspond to multiple devices being connected to the same physical bus.
+
+Organisation of ports and endpoints
+-----------------------------------
+
+Ports are described by child 'port' nodes contained in the device node.
+Each port node contains an 'endpoint' subnode for each remote device port
+connected to this port. If a single port is connected to more than one
+remote device, an 'endpoint' child node must be provided for each link.
+If more than one port is present in a device node or there is more than one
+endpoint at a port, or a port node needs to be associated with a selected
+hardware interface, a common scheme using '#address-cells', '#size-cells'
+and 'reg' properties is used number the nodes.
+
+device {
+        ...
+        #address-cells = <1>;
+        #size-cells = <0>;
+
+        port@0 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                reg = <0>;
+
+                endpoint@0 {
+                        reg = <0>;
+                        ...
+                };
+                endpoint@1 {
+                        reg = <1>;
+                        ...
+                };
+        };
+
+        port@1 {
+                reg = <1>;
+
+                endpoint { ... };
+        };
+};
+
+All 'port' nodes can be grouped under an optional 'ports' node, which
+allows to specify #address-cells, #size-cells properties for the 'port'
+nodes independently from any other child device nodes a device might
+have.
+
+device {
+        ...
+        ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                        ...
+                        endpoint@0 { ... };
+                        endpoint@1 { ... };
+                };
+
+                port@1 { ... };
+        };
+};
+
+Links between endpoints
+-----------------------
+
+Each endpoint should contain a 'remote-endpoint' phandle property that points
+to the corresponding endpoint in the port of the remote device. In turn, the
+remote endpoint should contain a 'remote-endpoint' property. If it has one,
+it must not point to another than the local endpoint. Two endpoints with their
+'remote-endpoint' phandles pointing at each other form a link between the
+containing ports.
+
+device-1 {
+        port {
+                device_1_output: endpoint {
+                        remote-endpoint = <&device_2_input>;
+                };
+        };
+};
+
+device-2 {
+        port {
+                device_2_input: endpoint {
+                        remote-endpoint = <&device_1_output>;
+                };
+        };
+};
+
+
+Required properties
+-------------------
+
+If there is more than one 'port' or more than one 'endpoint' node or 'reg'
+property is present in port and/or endpoint nodes the following properties
+are required in a relevant parent node:
+
+ - #address-cells : number of cells required to define port/endpoint
+                    identifier, should be 1.
+ - #size-cells    : should be zero.
+
+Optional endpoint properties
+----------------------------
+
+- remote-endpoint: phandle to an 'endpoint' subnode of a remote device node.
+
diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 1a1ac2e560e9..71724d026ffa 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -18,6 +18,7 @@ atmel,24c02		i2c serial eeprom  (24cxx)
 atmel,at97sc3204t       i2c trusted platform module (TPM)
 capella,cm32181         CM32181: Ambient Light Sensor
 catalyst,24c32          i2c serial eeprom
+cirrus,cs42l51          Cirrus Logic CS42L51 audio codec
 dallas,ds1307           64 x 8, Serial, I2C Real-Time Clock
 dallas,ds1338           I2C RTC with 56-Byte NV RAM
 dallas,ds1339           I2C Serial Real-Time Clock
@@ -58,6 +59,7 @@ plx,pex8648		48-Lane, 12-Port PCI Express Gen 2 (5.0 GT/s) Switch
 ramtron,24c64           i2c serial eeprom  (24cxx)
 ricoh,rs5c372a          I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
 samsung,24ad0xd1        S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
+sii,s35390a             2-wire CMOS real-time clock
 st-micro,24c256         i2c serial eeprom  (24cxx)
 stm,m41t00              Serial Access TIMEKEEPER
 stm,m41t62              Serial real-time clock (RTC) with alarm
diff --git a/Documentation/devicetree/bindings/arm/atmel-adc.txt b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
index d1061469f63d..0f813dec5e08 100644
--- a/Documentation/devicetree/bindings/arm/atmel-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/at91_adc.txt
@@ -5,32 +5,35 @@ Required properties:
     <chip> can be "at91sam9260", "at91sam9g45" or "at91sam9x5"
   - reg: Should contain ADC registers location and length
   - interrupts: Should contain the IRQ line for the ADC
-  - atmel,adc-channels-used: Bitmask of the channels muxed and enable for this
+  - clock-names: tuple listing input clock names.
+        Required elements: "adc_clk", "adc_op_clk".
+  - clocks: phandles to input clocks.
+  - atmel,adc-channels-used: Bitmask of the channels muxed and enabled for this
     device
   - atmel,adc-startup-time: Startup Time of the ADC in microseconds as
     defined in the datasheet
   - atmel,adc-vref: Reference voltage in millivolts for the conversions
-  - atmel,adc-res: List of resolution in bits supported by the ADC. List size
+  - atmel,adc-res: List of resolutions in bits supported by the ADC. List size
                    must be two at least.
   - atmel,adc-res-names: Contains one identifier string for each resolution
                          in atmel,adc-res property. "lowres" and "highres"
                          identifiers are required.
 
 Optional properties:
-  - atmel,adc-use-external: Boolean to enable of external triggers
+  - atmel,adc-use-external-triggers: Boolean to enable the external triggers
   - atmel,adc-use-res: String corresponding to an identifier from
                        atmel,adc-res-names property. If not specified, the highest
                        resolution will be used.
   - atmel,adc-sleep-mode: Boolean to enable sleep mode when no conversion
   - atmel,adc-sample-hold-time: Sample and Hold Time in microseconds
-  - atmel,adc-ts-wires: Number of touch screen wires. Should be 4 or 5. If this
-                        value is set, then adc driver will enable touch screen
+  - atmel,adc-ts-wires: Number of touchscreen wires. Should be 4 or 5. If this
+                        value is set, then the adc driver will enable touchscreen
                         support.
-    NOTE: when adc touch screen enabled, the adc hardware trigger will be
-          disabled. Since touch screen will occupied the trigger register.
+    NOTE: when adc touchscreen is enabled, the adc hardware trigger will be
+          disabled. Since touchscreen will occupy the trigger register.
   - atmel,adc-ts-pressure-threshold: a pressure threshold for touchscreen. It
-                                     make touch detect more precision.
- 
+                                     makes touch detection more precise.
+
 Optional trigger Nodes:
   - Required properties:
     * trigger-name: Name of the trigger exposed to the user
@@ -41,40 +44,43 @@ Optional trigger Nodes:
 
 Examples:
 adc0: adc@fffb0000 {
+        #address-cells = <1>;
+        #size-cells = <0>;
         compatible = "atmel,at91sam9260-adc";
         reg = <0xfffb0000 0x100>;
-        interrupts = <20 4>;
-        atmel,adc-channel-base = <0x30>;
+        interrupts = <20 IRQ_TYPE_LEVEL_HIGH 0>;
+        clocks = <&adc_clk>, <&adc_op_clk>;
+        clock-names = "adc_clk", "adc_op_clk";
         atmel,adc-channels-used = <0xff>;
-        atmel,adc-drdy-mask = <0x10000>;
-        atmel,adc-num-channels = <8>;
         atmel,adc-startup-time = <40>;
-        atmel,adc-status-register = <0x1c>;
-        atmel,adc-trigger-register = <0x08>;
-        atmel,adc-use-external;
+        atmel,adc-use-external-triggers;
         atmel,adc-vref = <3300>;
         atmel,adc-res = <8 10>;
         atmel,adc-res-names = "lowres", "highres";
         atmel,adc-use-res = "lowres";
 
         trigger@0 {
+                reg = <0>;
                 trigger-name = "external-rising";
                 trigger-value = <0x1>;
                 trigger-external;
         };
         trigger@1 {
+                reg = <1>;
                 trigger-name = "external-falling";
                 trigger-value = <0x2>;
                 trigger-external;
         };
 
         trigger@2 {
+                reg = <2>;
                 trigger-name = "external-any";
                 trigger-value = <0x3>;
                 trigger-external;
         };
 
         trigger@3 {
+                reg = <3>;
                 trigger-name = "continuous";
                 trigger-value = <0x6>;
         };
diff --git a/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
new file mode 100644
index 000000000000..6bdd21404b57
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/twl4030-madc.txt
@@ -0,0 +1,24 @@
+* TWL4030 Monitoring Analog to Digital Converter (MADC)
+
+The MADC subsystem in the TWL4030 consists of a 10-bit ADC
+combined with a 16-input analog multiplexer.
+
+Required properties:
+  - compatible: Should contain "ti,twl4030-madc".
+  - interrupts: IRQ line for the MADC submodule.
+  - #io-channel-cells: Should be set to <1>.
+
+Optional properties:
+  - ti,system-uses-second-madc-irq: boolean, set if the second madc irq register
+                                    should be used, which is intended to be used
+                                    by Co-Processors (e.g. a modem).
+
+Example:
+
+&twl {
+        madc {
+                compatible = "ti,twl4030-madc";
+                interrupts = <3>;
+                #io-channel-cells = <1>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
new file mode 100644
index 000000000000..dcebff1928e1
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
@@ -0,0 +1,22 @@
+Freescale vf610 Analog to Digital Converter bindings
+
+The devicetree bindings are for the new ADC driver written for
+vf610/i.MX6slx and upward SoCs from Freescale.
+
+Required properties:
+- compatible: Should contain "fsl,vf610-adc"
+- reg: Offset and length of the register set for the device
+- interrupts: Should contain the interrupt for the device
+- clocks: The clock is needed by the ADC controller, ADC clock source is ipg clock.
+- clock-names: Must contain "adc", matching entry in the clocks property.
+- vref-supply: The regulator supply ADC refrence voltage.
+
+Example:
+adc0: adc@4003b000 {
+        compatible = "fsl,vf610-adc";
+        reg = <0x4003b000 0x1000>;
+        interrupts = <0 53 0x04>;
+        clocks = <&clks VF610_CLK_ADC0>;
+        clock-names = "adc";
+        vref-supply = <&reg_vcc_3v3_mcu>;
+};
diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
new file mode 100644
index 000000000000..d9ee909d2b78
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/xilinx-xadc.txt
@@ -0,0 +1,113 @@
+Xilinx XADC device driver
+
+This binding document describes the bindings for both of them since the
+bindings are very similar. The Xilinx XADC is a ADC that can be found in the
+series 7 FPGAs from Xilinx. The XADC has a DRP interface for communication.
+Currently two different frontends for the DRP interface exist. One that is only
+available on the ZYNQ family as a hardmacro in the SoC portion of the ZYNQ. The
+other one is available on all series 7 platforms and is a softmacro with a AXI
+interface. This binding document describes the bindings for both of them since
+the bindings are very similar.
+
+Required properties:
+        - compatible: Should be one of
+                * "xlnx,zynq-xadc-1.00.a": When using the ZYNQ device
+                  configuration interface to interface to the XADC hardmacro.
+                * "xlnx,axi-xadc-1.00.a": When using the axi-xadc pcore to
+                  interface to the XADC hardmacro.
+        - reg: Address and length of the register set for the device
+        - interrupts: Interrupt for the XADC control interface.
+        - clocks: When using the ZYNQ this must be the ZYNQ PCAP clock,
+          when using the AXI-XADC pcore this must be the clock that provides the
+          clock to the AXI bus interface of the core.
+
+Optional properties:
+        - interrupt-parent: phandle to the parent interrupt controller
+        - xlnx,external-mux:
+                * "none": No external multiplexer is used, this is the default
+                  if the property is omitted.
+                * "single": External multiplexer mode is used with one
+                   multiplexer.
+                * "dual": External multiplexer mode is used with two
+                  multiplexers for simultaneous sampling.
+        - xlnx,external-mux-channel: Configures which pair of pins is used to
+          sample data in external mux mode.
+          Valid values for single external multiplexer mode are:
+                0: VP/VN
+                1: VAUXP[0]/VAUXN[0]
+                2: VAUXP[1]/VAUXN[1]
+                ...
+                16: VAUXP[15]/VAUXN[15]
+          Valid values for dual external multiplexer mode are:
+                1: VAUXP[0]/VAUXN[0] - VAUXP[8]/VAUXN[8]
+                2: VAUXP[1]/VAUXN[1] - VAUXP[9]/VAUXN[9]
+                ...
+                8: VAUXP[7]/VAUXN[7] - VAUXP[15]/VAUXN[15]
+
+          This property needs to be present if the device is configured for
+          external multiplexer mode (either single or dual). If the device is
+          not using external multiplexer mode the property is ignored.
+        - xnlx,channels: List of external channels that are connected to the ADC
+          Required properties:
+                * #address-cells: Should be 1.
+                * #size-cells: Should be 0.
+
+          The child nodes of this node represent the external channels which are
+          connected to the ADC. If the property is no present no external
+          channels will be assumed to be connected.
+
+          Each child node represents one channel and has the following
+          properties:
+                Required properties:
+                        * reg: Pair of pins the the channel is connected to.
+                                0: VP/VN
+                                1: VAUXP[0]/VAUXN[0]
+                                2: VAUXP[1]/VAUXN[1]
+                                ...
+                                16: VAUXP[15]/VAUXN[15]
+                          Note each channel number should only be used at most
+                          once.
+                Optional properties:
+                        * xlnx,bipolar: If set the channel is used in bipolar
+                          mode.
+
+
+Examples:
+        xadc@f8007100 {
+                compatible = "xlnx,zynq-xadc-1.00.a";
+                reg = <0xf8007100 0x20>;
+                interrupts = <0 7 4>;
+                interrupt-parent = <&gic>;
+                clocks = <&pcap_clk>;
+
+                xlnx,channels {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        channel@0 {
+                                reg = <0>;
+                        };
+                        channel@1 {
+                                reg = <1>;
+                        };
+                        channel@8 {
+                                reg = <8>;
+                        };
+                };
+        };
+
+        xadc@43200000 {
+                compatible = "xlnx,axi-xadc-1.00.a";
+                reg = <0x43200000 0x1000>;
+                interrupts = <0 53 4>;
+                interrupt-parent = <&gic>;
+                clocks = <&fpga1_clk>;
+
+                xlnx,channels {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        channel@0 {
+                                reg = <0>;
+                                xlnx,bipolar;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/input/clps711x-keypad.txt b/Documentation/devicetree/bindings/input/clps711x-keypad.txt
new file mode 100644
index 000000000000..e68d2bbc6c07
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/clps711x-keypad.txt
@@ -0,0 +1,27 @@
+* Cirrus Logic CLPS711X matrix keypad device tree bindings
+
+Required Properties:
+- compatible:    Shall contain "cirrus,clps711x-keypad".
+- row-gpios:     List of GPIOs used as row lines.
+- poll-interval: Poll interval time in milliseconds.
+- linux,keymap:  The definition can be found at
+                 bindings/input/matrix-keymap.txt.
+
+Optional Properties:
+- autorepeat:    Enable autorepeat feature.
+
+Example:
+        keypad {
+                compatible = "cirrus,ep7312-keypad", "cirrus,clps711x-keypad";
+                autorepeat;
+                poll-interval = <120>;
+                row-gpios = <&porta 0 0>,
+                            <&porta 1 0>;
+
+                linux,keymap = <
+                        MATRIX_KEY(0, 0, KEY_UP)
+                        MATRIX_KEY(0, 1, KEY_DOWN)
+                        MATRIX_KEY(1, 0, KEY_LEFT)
+                        MATRIX_KEY(1, 1, KEY_RIGHT)
+                >;
+        };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
new file mode 100644
index 000000000000..7d8cb92831d7
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
@@ -0,0 +1,89 @@
+Qualcomm PM8xxx PMIC Keypad
+
+PROPERTIES
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: must be one of:
+                    "qcom,pm8058-keypad"
+                    "qcom,pm8921-keypad"
+
+- reg:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: address of keypad control register
+
+- interrupts:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: the first interrupt specifies the key sense interrupt
+                    and the second interrupt specifies the key stuck interrupt.
+                    The format of the specifier is defined by the binding
+                    document describing the node's interrupt parent.
+
+- linux,keymap:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: the linux keymap. More information can be found in
+                    input/matrix-keymap.txt.
+
+- linux,keypad-no-autorepeat:
+        Usage: optional
+        Value type: <bool>
+        Definition: don't enable autorepeat feature.
+
+- linux,keypad-wakeup:
+        Usage: optional
+        Value type: <bool>
+        Definition: use any event on keypad as wakeup event.
+
+- keypad,num-rows:
+        Usage: required
+        Value type: <u32>
+        Definition: number of rows in the keymap. More information can be found
+                    in input/matrix-keymap.txt.
+
+- keypad,num-columns:
+        Usage: required
+        Value type: <u32>
+        Definition: number of columns in the keymap. More information can be
+                    found in input/matrix-keymap.txt.
+
+- debounce:
+        Usage: optional
+        Value type: <u32>
+        Definition: time in microseconds that key must be pressed or release
+                    for key sense interrupt to trigger.
+
+- scan-delay:
+        Usage: optional
+        Value type: <u32>
+        Definition: time in microseconds to pause between successive scans
+                    of the matrix array.
+
+- row-hold:
+        Usage: optional
+        Value type: <u32>
+        Definition: time in nanoseconds to pause between scans of each row in
+                    the matrix array.
+
+EXAMPLE
+
+        keypad@148 {
+                compatible = "qcom,pm8921-keypad";
+                reg = <0x148>;
+                interrupt-parent = <&pmicintc>;
+                interrupts = <74 1>, <75 1>;
+                linux,keymap = <
+                        MATRIX_KEY(0, 0, KEY_VOLUMEUP)
+                        MATRIX_KEY(0, 1, KEY_VOLUMEDOWN)
+                        MATRIX_KEY(0, 2, KEY_CAMERA_FOCUS)
+                        MATRIX_KEY(0, 3, KEY_CAMERA)
+                        >;
+                keypad,num-rows = <1>;
+                keypad,num-columns = <5>;
+                debounce = <15>;
+                scan-delay = <32>;
+                row-hold = <91500>;
+        };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
new file mode 100644
index 000000000000..588536cc96ed
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-pwrkey.txt
@@ -0,0 +1,46 @@
+Qualcomm PM8xxx PMIC Power Key
+
+PROPERTIES
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: must be one of:
+                    "qcom,pm8058-pwrkey"
+                    "qcom,pm8921-pwrkey"
+
+- reg:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: address of power key control register
+
+- interrupts:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: the first interrupt specifies the key release interrupt
+                    and the second interrupt specifies the key press interrupt.
+                    The format of the specifier is defined by the binding
+                    document describing the node's interrupt parent.
+
+- debounce:
+        Usage: optional
+        Value type: <u32>
+        Definition: time in microseconds that key must be pressed or release
+                    for state change interrupt to trigger.
+
+- pull-up:
+        Usage: optional
+        Value type: <empty>
+        Definition: presence of this property indicates that the KPDPWR_N pin
+                    should be configured for pull up.
+
+EXAMPLE
+
+        pwrkey@1c {
+                compatible = "qcom,pm8921-pwrkey";
+                reg = <0x1c>;
+                interrupt-parent = <&pmicintc>;
+                interrupts = <50 1>, <51 1>;
+                debounce = <15625>;
+                pull-up;
+        };
diff --git a/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
new file mode 100644
index 000000000000..4ed467b1e402
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/qcom,pm8xxx-vib.txt
@@ -0,0 +1,22 @@
+Qualcomm PM8xxx PMIC Vibrator
+
+PROPERTIES
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: must be one of:
+                    "qcom,pm8058-vib"
+                    "qcom,pm8921-vib"
+
+- reg:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: address of vibration control register
+
+EXAMPLE
+
+        vibrator@4a {
+                compatible = "qcom,pm8058-vib";
+                reg = <0x4a>;
+        };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
new file mode 100644
index 000000000000..76db96704a60
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.txt
@@ -0,0 +1,55 @@
+FocalTech EDT-FT5x06 Polytouch driver
+=====================================
+
+There are 3 variants of the chip for various touch panel sizes
+FT5206GE1  2.8" .. 3.8"
+FT5306DE4  4.3" .. 7"
+FT5406EE8  7"   .. 8.9"
+
+The software interface is identical for all those chips, so that
+currently there is no need for the driver to distinguish between the
+different chips. Nevertheless distinct compatible strings are used so
+that a distinction can be added if necessary without changing the DT
+bindings.
+
+
+Required properties:
+ - compatible:  "edt,edt-ft5206"
+           or:  "edt,edt-ft5306"
+           or:  "edt,edt-ft5406"
+
+ - reg:         I2C slave address of the chip (0x38)
+ - interrupt-parent: a phandle pointing to the interrupt controller
+                     serving the interrupt for this chip
+ - interrupts:       interrupt specification for the touchdetect
+                     interrupt
+
+Optional properties:
+ - reset-gpios: GPIO specification for the RESET input
+ - wake-gpios:  GPIO specification for the WAKE input
+
+ - pinctrl-names: should be "default"
+ - pinctrl-0:   a phandle pointing to the pin settings for the
+                control gpios
+
+ - threshold:   allows setting the "click"-threshold in the range
+                from 20 to 80.
+
+ - gain:        allows setting the sensitivity in the range from 0 to
+                31. Note that lower values indicate higher
+                sensitivity.
+
+ - offset:      allows setting the edge compensation in the range from
+                0 to 31.
+
+Example:
+        polytouch: edt-ft5x06@38 {
+                compatible = "edt,edt-ft5406", "edt,edt-ft5x06";
+                reg = <0x38>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&edt_ft5x06_pins>;
+                interrupt-parent = <&gpio2>;
+                interrupts = <5 0>;
+                reset-gpios = <&gpio2 6 1>;
+                wake-gpios = <&gpio4 9 0>;
+        };
diff --git a/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
new file mode 100644
index 000000000000..2faf1f1fa39e
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
@@ -0,0 +1,30 @@
+* Neonode infrared touchscreen controller
+
+Required properties:
+- compatible: must be "neonode,zforce"
+- reg: I2C address of the chip
+- interrupts: interrupt to which the chip is connected
+- gpios: gpios the chip is connected to
+  first one is the interrupt gpio and second one the reset gpio
+- x-size: horizontal resolution of touchscreen
+- y-size: vertical resolution of touchscreen
+
+Example:
+
+        i2c@00000000 {
+                /* ... */
+
+                zforce_ts@50 {
+                        compatible = "neonode,zforce";
+                        reg = <0x50>;
+                        interrupts = <2 0>;
+
+                        gpios = <&gpio5 6 0>, /* INT */
+                                <&gpio5 9 0>; /* RST */
+
+                        x-size = <800>;
+                        y-size = <600>;
+                };
+
+                /* ... */
+        };
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
index 32cec4b26cd0..b290ca150d30 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun4i-ic.txt
@@ -2,7 +2,7 @@ Allwinner Sunxi Interrupt Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sun4i-ic"
+- compatible : should be "allwinner,sun4i-a10-ic"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
@@ -11,7 +11,7 @@ Required properties:
 Example:
 
 intc: interrupt-controller {
-        compatible = "allwinner,sun4i-ic";
+        compatible = "allwinner,sun4i-a10-ic";
         reg = <0x01c20400 0x400>;
         interrupt-controller;
         #interrupt-cells = <1>;
diff --git a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
new file mode 100644
index 000000000000..d1c5cdabc3e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
@@ -0,0 +1,27 @@
+Allwinner Sunxi NMI Controller
+==============================
+
+Required properties:
+
+- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
+  "allwinner,sun6i-a31-sc-nmi"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 2. The first cell is the IRQ number, the
+  second cell the trigger type as defined in interrupt.txt in this directory.
+- interrupt-parent: Specifies the parent interrupt controller.
+- interrupts: Specifies the interrupt line (NMI) which is handled by
+  the interrupt controller in the parent controller's notation. This value
+  shall be the NMI.
+
+Example:
+
+sc-nmi-intc@01c00030 {
+        compatible = "allwinner,sun7i-a20-sc-nmi";
+        interrupt-controller;
+        #interrupt-cells = <2>;
+        reg = <0x01c00030 0x0c>;
+        interrupt-parent = <&gic>;
+        interrupts = <0 0 4>;
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
new file mode 100644
index 000000000000..759339c34e4f
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/cirrus,clps711x-intc.txt
@@ -0,0 +1,41 @@
+Cirrus Logic CLPS711X Interrupt Controller
+
+Required properties:
+
+- compatible: Should be "cirrus,clps711x-intc".
+- reg: Specifies base physical address of the registers set.
+- interrupt-controller: Identifies the node as an interrupt controller.
+- #interrupt-cells: Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 1.
+
+The interrupt sources are as follows:
+ID      Name    Description
+---------------------------
+1:      BLINT   Battery low (FIQ)
+3:      MCINT   Media changed (FIQ)
+4:      CSINT   CODEC sound
+5:      EINT1   External 1
+6:      EINT2   External 2
+7:      EINT3   External 3
+8:      TC1OI   TC1 under flow
+9:      TC2OI   TC2 under flow
+10:     RTCMI   RTC compare match
+11:     TINT    64Hz tick
+12:     UTXINT1 UART1 transmit FIFO half empty
+13:     URXINT1 UART1 receive FIFO half full
+14:     UMSINT  UART1 modem status changed
+15:     SSEOTI  SSI1 end of transfer
+16:     KBDINT  Keyboard
+17:     SS2RX   SSI2 receive FIFO half or greater full
+18:     SS2TX   SSI2 transmit FIFO less than half empty
+28:     UTXINT2 UART2 transmit FIFO half empty
+29:     URXINT2 UART2 receive FIFO half full
+32:     DAIINT  DAI interface (FIQ)
+
+Example:
+        intc: interrupt-controller {
+                compatible = "cirrus,clps711x-intc";
+                reg = <0x80000000 0x4000>;
+                interrupt-controller;
+                #interrupt-cells = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index e34c6cdd8ba8..f284b99402bc 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -48,6 +48,12 @@ conditions.
                   from the mmu-masters towards memory) node for this
                   SMMU.
 
+- calxeda,smmu-secure-config-access : Enable proper handling of buggy
+                  implementations that always use secure access to
+                  SMMU configuration registers. In this case non-secure
+                  aliases of secure registers have to be used during
+                  SMMU configuration.
+
 Example:
 
         smmu {
diff --git a/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
new file mode 100644
index 000000000000..42531dc387aa
--- /dev/null
+++ b/Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
@@ -0,0 +1,26 @@
+OMAP2+ IOMMU
+
+Required properties:
+- compatible : Should be one of,
+                "ti,omap2-iommu" for OMAP2/OMAP3 IOMMU instances
+                "ti,omap4-iommu" for OMAP4/OMAP5 IOMMU instances
+                "ti,dra7-iommu" for DRA7xx IOMMU instances
+- ti,hwmods  : Name of the hwmod associated with the IOMMU instance
+- reg        : Address space for the configuration registers
+- interrupts : Interrupt specifier for the IOMMU instance
+
+Optional properties:
+- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
+                    Should be either 8 or 32 (default: 32)
+- ti,iommu-bus-err-back : Indicates the IOMMU instance supports throwing
+                          back a bus error response on MMU faults.
+
+Example:
+        /* OMAP3 ISP MMU */
+        mmu_isp: mmu@480bd400 {
+                compatible = "ti,omap2-iommu";
+                reg = <0x480bd400 0x80>;
+                interrupts = <24>;
+                ti,hwmods = "mmu_isp";
+                ti,#tlb-entries = <8>;
+        };
diff --git a/Documentation/devicetree/bindings/media/img-ir-rev1.txt b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
new file mode 100644
index 000000000000..5434ce61b925
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/img-ir-rev1.txt
@@ -0,0 +1,34 @@
+* ImgTec Infrared (IR) decoder version 1
+
+This binding is for Imagination Technologies' Infrared decoder block,
+specifically major revision 1.
+
+Required properties:
+- compatible:           Should be "img,ir-rev1"
+- reg:                  Physical base address of the controller and length of
+                        memory mapped region.
+- interrupts:           The interrupt specifier to the cpu.
+
+Optional properties:
+- clocks:               List of clock specifiers as described in standard
+                        clock bindings.
+                        Up to 3 clocks may be specified in the following order:
+                        1st:    Core clock (defaults to 32.768KHz if omitted).
+                        2nd:    System side (fast) clock.
+                        3rd:    Power modulation clock.
+- clock-names:          List of clock names corresponding to the clocks
+                        specified in the clocks property.
+                        Accepted clock names are:
+                        "core": Core clock.
+                        "sys":  System clock.
+                        "mod":  Power modulation clock.
+
+Example:
+
+        ir@02006200 {
+                compatible = "img,ir-rev1";
+                reg = <0x02006200 0x100>;
+                interrupts = <29 4>;
+                clocks = <&clk_32khz>;
+                clock-names =  "core";
+        };
diff --git a/Documentation/devicetree/bindings/media/samsung-fimc.txt b/Documentation/devicetree/bindings/media/samsung-fimc.txt
index 96312f6c4c26..922d6f8e74be 100644
--- a/Documentation/devicetree/bindings/media/samsung-fimc.txt
+++ b/Documentation/devicetree/bindings/media/samsung-fimc.txt
@@ -15,11 +15,21 @@ Common 'camera' node
 
 Required properties:
 
-- compatible    : must be "samsung,fimc", "simple-bus"
-- clocks        : list of clock specifiers, corresponding to entries in
-                  the clock-names property;
-- clock-names   : must contain "sclk_cam0", "sclk_cam1", "pxl_async0",
-                  "pxl_async1" entries, matching entries in the clocks property.
+- compatible: must be "samsung,fimc", "simple-bus"
+- clocks: list of clock specifiers, corresponding to entries in
+  the clock-names property;
+- clock-names : must contain "sclk_cam0", "sclk_cam1", "pxl_async0",
+  "pxl_async1" entries, matching entries in the clocks property.
+
+- #clock-cells: from the common clock bindings (../clock/clock-bindings.txt),
+  must be 1. A clock provider is associated with the 'camera' node and it should
+  be referenced by external sensors that use clocks provided by the SoC on
+  CAM_*_CLKOUT pins. The clock specifier cell stores an index of a clock.
+  The indices are 0, 1 for CAM_A_CLKOUT, CAM_B_CLKOUT clocks respectively.
+
+- clock-output-names: from the common clock bindings, should contain names of
+  clocks registered by the camera subsystem corresponding to CAM_A_CLKOUT,
+  CAM_B_CLKOUT output clocks respectively.
 
 The pinctrl bindings defined in ../pinctrl/pinctrl-bindings.txt must be used
 to define a required pinctrl state named "default" and optional pinctrl states:
@@ -32,6 +42,7 @@ way around.
 
 The 'camera' node must include at least one 'fimc' child node.
 
+
 'fimc' device nodes
 -------------------
 
@@ -88,8 +99,8 @@ port nodes specifies data input - 0, 1 indicates input A, B respectively.
 
 Optional properties
 
-- samsung,camclk-out : specifies clock output for remote sensor,
-                       0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
+- samsung,camclk-out (deprecated) : specifies clock output for remote sensor,
+  0 - CAM_A_CLKOUT, 1 - CAM_B_CLKOUT;
 
 Image sensor nodes
 ------------------
@@ -97,8 +108,6 @@ Image sensor nodes
 The sensor device nodes should be added to their control bus controller (e.g.
 I2C0) nodes and linked to a port node in the csis or the parallel-ports node,
 using the common video interfaces bindings, defined in video-interfaces.txt.
-The implementation of this bindings requires clock-frequency property to be
-present in the sensor device nodes.
 
 Example:
 
@@ -114,7 +123,7 @@ Example:
                         vddio-supply = <...>;
 
                         clock-frequency = <24000000>;
-                        clocks = <...>;
+                        clocks = <&camera 1>;
                         clock-names = "mclk";
 
                         port {
@@ -135,7 +144,7 @@ Example:
                         vddio-supply = <...>;
 
                         clock-frequency = <24000000>;
-                        clocks = <...>;
+                        clocks = <&camera 0>;
                         clock-names = "mclk";
 
                         port {
@@ -149,12 +158,17 @@ Example:
 
         camera {
                 compatible = "samsung,fimc", "simple-bus";
-                #address-cells = <1>;
-                #size-cells = <1>;
-                status = "okay";
-
+                clocks = <&clock 132>, <&clock 133>, <&clock 351>,
+                         <&clock 352>;
+                clock-names = "sclk_cam0", "sclk_cam1", "pxl_async0",
+                              "pxl_async1";
+                #clock-cells = <1>;
+                clock-output-names = "cam_a_clkout", "cam_b_clkout";
                 pinctrl-names = "default";
                 pinctrl-0 = <&cam_port_a_clk_active>;
+                status = "okay";
+                #address-cells = <1>;
+                #size-cells = <1>;
 
                 /* parallel camera ports */
                 parallel-ports {
diff --git a/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
new file mode 100644
index 000000000000..2c85c4538a6d
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5c73m3.txt
@@ -0,0 +1,97 @@
+Samsung S5C73M3 8Mp camera ISP
+------------------------------
+
+The S5C73M3 camera ISP supports MIPI CSI-2 and parallel (ITU-R BT.656) video
+data busses. The I2C bus is the main control bus and additionally the SPI bus
+is used, mostly for transferring the firmware to and from the device. Two
+slave device nodes corresponding to these control bus interfaces are required
+and should be placed under respective bus controller nodes.
+
+I2C slave device node
+---------------------
+
+Required properties:
+
+- compatible        : "samsung,s5c73m3";
+- reg               : I2C slave address of the sensor;
+- vdd-int-supply    : digital power supply (1.2V);
+- vdda-supply       : analog power supply (1.2V);
+- vdd-reg-supply    : regulator input power supply (2.8V);
+- vddio-host-supply : host I/O power supply (1.8V to 2.8V);
+- vddio-cis-supply  : CIS I/O power supply (1.2V to 1.8V);
+- vdd-af-supply     : lens power supply (2.8V);
+- xshutdown-gpios   : specifier of GPIO connected to the XSHUTDOWN pin;
+- standby-gpios     : specifier of GPIO connected to the STANDBY pin;
+- clocks            : should contain list of phandle and clock specifier pairs
+                      according to common clock bindings for the clocks described
+                      in the clock-names property;
+- clock-names       : should contain "cis_extclk" entry for the CIS_EXTCLK clock;
+
+Optional properties:
+
+- clock-frequency   : the frequency at which the "cis_extclk" clock should be
+                      configured to operate, in Hz; if this property is not
+                      specified default 24 MHz value will be used.
+
+The common video interfaces bindings (see video-interfaces.txt) should be used
+to specify link from the S5C73M3 to an external image data receiver. The S5C73M3
+device node should contain one 'port' child node with an 'endpoint' subnode for
+this purpose. The data link from a raw image sensor to the S5C73M3 can be
+similarly specified, but it is optional since the S5C73M3 ISP and a raw image
+sensor are usually inseparable and form a hybrid module.
+
+Following properties are valid for the endpoint node(s):
+
+endpoint subnode
+----------------
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+  video-interfaces.txt. This sensor doesn't support data lane remapping
+  and physical lane indexes in subsequent elements of the array should
+  be only consecutive ascending values.
+
+SPI device node
+---------------
+
+Required properties:
+
+- compatible        : "samsung,s5c73m3";
+
+For more details see description of the SPI busses bindings
+(../spi/spi-bus.txt) and bindings of a specific bus controller.
+
+Example:
+
+i2c@138A000000 {
+        ...
+        s5c73m3@3c {
+                compatible = "samsung,s5c73m3";
+                reg = <0x3c>;
+                vdd-int-supply = <&buck9_reg>;
+                vdda-supply = <&ldo17_reg>;
+                vdd-reg-supply = <&cam_io_reg>;
+                vddio-host-supply = <&ldo18_reg>;
+                vddio-cis-supply = <&ldo9_reg>;
+                vdd-af-supply = <&cam_af_reg>;
+                clock-frequency = <24000000>;
+                clocks = <&clk 0>;
+                clock-names = "cis_extclk";
+                reset-gpios = <&gpf1 3 1>;
+                standby-gpios = <&gpm0 1 1>;
+                port {
+                        s5c73m3_ep: endpoint {
+                                remote-endpoint = <&csis0_ep>;
+                                data-lanes = <1 2 3 4>;
+                        };
+                };
+        };
+};
+
+spi@1392000 {
+        ...
+        s5c73m3_spi: s5c73m3@0 {
+                compatible = "samsung,s5c73m3";
+                reg = <0>;
+                ...
+        };
+};
diff --git a/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt
new file mode 100644
index 000000000000..cce01e82f3e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/samsung-s5k6a3.txt
@@ -0,0 +1,33 @@
+Samsung S5K6A3(YX) raw image sensor
+---------------------------------
+
+S5K6A3(YX) is a raw image sensor with MIPI CSI-2 and CCP2 image data interfaces
+and CCI (I2C compatible) control bus.
+
+Required properties:
+
+- compatible    : "samsung,s5k6a3";
+- reg           : I2C slave address of the sensor;
+- svdda-supply  : core voltage supply;
+- svddio-supply : I/O voltage supply;
+- afvdd-supply  : AF (actuator) voltage supply;
+- gpios         : specifier of a GPIO connected to the RESET pin;
+- clocks        : should contain list of phandle and clock specifier pairs
+                  according to common clock bindings for the clocks described
+                  in the clock-names property;
+- clock-names   : should contain "extclk" entry for the sensor's EXTCLK clock;
+
+Optional properties:
+
+- clock-frequency : the frequency at which the "extclk" clock should be
+                    configured to operate, in Hz; if this property is not
+                    specified default 24 MHz value will be used.
+
+The common video interfaces bindings (see video-interfaces.txt) should be
+used to specify link to the image data receiver. The S5K6A3(YX) device
+node should contain one 'port' child node with an 'endpoint' subnode.
+
+Following properties are valid for the endpoint node:
+
+- data-lanes : (optional) specifies MIPI CSI-2 data lanes as covered in
+  video-interfaces.txt.  The sensor supports only one data lane.
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
index d5e370450ac0..d5e370450ac0 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
diff --git a/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
new file mode 100644
index 000000000000..9592717f483f
--- /dev/null
+++ b/Documentation/devicetree/bindings/memory-controllers/ti-aemif.txt
@@ -0,0 +1,210 @@
+* Device tree bindings for Texas instruments AEMIF controller
+
+The Async External Memory Interface (EMIF16/AEMIF) controller is intended to
+provide a glue-less interface to a variety of asynchronous memory devices like
+ASRA M, NOR and NAND memory. A total of 256M bytes of any of these memories
+can be accessed at any given time via four chip selects with 64M byte access
+per chip select. Synchronous memories such as DDR1 SD RAM, SDR SDRAM
+and Mobile SDR are not supported.
+
+Documentation:
+Davinci DM646x - http://www.ti.com/lit/ug/sprueq7c/sprueq7c.pdf
+OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh77a/spruh77a.pdf
+Kestone - http://www.ti.com/lit/ug/sprugz3a/sprugz3a.pdf
+
+Required properties:
+
+- compatible:           "ti,davinci-aemif"
+                        "ti,keystone-aemif"
+                        "ti,da850-aemif"
+
+- reg:                  contains offset/length value for AEMIF control registers
+                        space.
+
+- #address-cells:       Must be 2. The partition number has to be encoded in the
+                        first address cell and it may accept values 0..N-1
+                        (N - total number of partitions). It's recommended to
+                        assign N-1 number for the control partition. The second
+                        cell is the offset into the partition.
+
+- #size-cells:          Must be set to 1.
+
+- ranges:               Contains memory regions. There are two types of
+                        ranges/partitions:
+                        - CS-specific partition/range. If continuous, must be
+                        set up to reflect the memory layout for 4 chipselects,
+                        if not then additional range/partition can be added and
+                        child device can select the proper one.
+                        - control partition which is common for all CS
+                        interfaces.
+
+- clocks:               the clock feeding the controller clock. Required only
+                        if clock tree data present in device tree.
+                        See clock-bindings.txt
+
+- clock-names:          clock name. It has to be "aemif". Required only if clock
+                        tree data present in device tree, in another case don't
+                        use it.
+                        See clock-bindings.txt
+
+- clock-ranges:         Empty property indicating that child nodes can inherit
+                        named clocks. Required only if clock tree data present
+                        in device tree.
+                        See clock-bindings.txt
+
+
+Child chip-select (cs) nodes contain the memory devices nodes connected to
+such as NOR (e.g. cfi-flash) and NAND (ti,davinci-nand, see davinci-nand.txt).
+There might be board specific devices like FPGAs.
+
+Required child cs node properties:
+
+- #address-cells:       Must be 2.
+
+- #size-cells:          Must be 1.
+
+- ranges:               Empty property indicating that child nodes can inherit
+                        memory layout.
+
+- clock-ranges:         Empty property indicating that child nodes can inherit
+                        named clocks. Required only if clock tree data present
+                        in device tree.
+
+- ti,cs-chipselect:     number of chipselect. Indicates on the aemif driver
+                        which chipselect is used for accessing the memory. For
+                        compatibles "ti,davinci-aemif" and "ti,keystone-aemif"
+                        it can be in range [0-3]. For compatible
+                        "ti,da850-aemif" range is [2-5].
+
+Optional child cs node properties:
+
+- ti,cs-bus-width:              width of the asynchronous device's data bus
+                                8 or 16 if not preset 8
+
+- ti,cs-select-strobe-mode:     enable/disable select strobe mode
+                                In select strobe mode chip select behaves as
+                                the strobe and is active only during the strobe
+                                period. If present then enable.
+
+- ti,cs-extended-wait-mode:     enable/disable extended wait mode
+                                if set, the controller monitors the EMIFWAIT pin
+                                mapped to that chip select to determine if the
+                                device wants to extend the strobe period. If
+                                present then enable.
+
+- ti,cs-min-turnaround-ns:      minimum turn around time, ns
+                                Time between the end of one asynchronous memory
+                                access and the start of another asynchronous
+                                memory access. This delay is not incurred
+                                between a read followed by read or a write
+                                followed by a write to same chip select.
+
+- ti,cs-read-setup-ns:          read setup width, ns
+                                Time between the beginning of a memory cycle
+                                and the activation of read strobe.
+                                Minimum value is 1 (0 treated as 1).
+
+- ti,cs-read-strobe-ns:         read strobe width, ns
+                                Time between the activation and deactivation of
+                                the read strobe.
+                                Minimum value is 1 (0 treated as 1).
+
+- ti,cs-read-hold-ns:           read hold width, ns
+                                Time between the deactivation of the read
+                                strobe and the end of the cycle (which may be
+                                either an address change or the deactivation of
+                                the chip select signal.
+                                Minimum value is 1 (0 treated as 1).
+
+- ti,cs-write-setup-ns:         write setup width, ns
+                                Time between the beginning of a memory cycle
+                                and the activation of write strobe.
+                                Minimum value is 1 (0 treated as 1).
+
+- ti,cs-write-strobe-ns:        write strobe width, ns
+                                Time between the activation and deactivation of
+                                the write strobe.
+                                Minimum value is 1 (0 treated as 1).
+
+- ti,cs-write-hold-ns:          write hold width, ns
+                                Time between the deactivation of the write
+                                strobe and the end of the cycle (which may be
+                                either an address change or the deactivation of
+                                the chip select signal.
+                                Minimum value is 1 (0 treated as 1).
+
+If any of the above parameters are absent, current parameter value will be taken
+from the corresponding HW reg.
+
+Example for aemif, davinci nand and nor flash chip select shown below.
+
+memory-controller@21000A00 {
+        compatible = "ti,davinci-aemif";
+        #address-cells = <2>;
+        #size-cells = <1>;
+        clocks = <&clkaemif 0>;
+        clock-names = "aemif";
+        clock-ranges;
+        reg = <0x21000A00 0x00000100>;
+        ranges = <0 0 0x70000000 0x10000000
+                  1 0 0x21000A00 0x00000100>;
+                  /*
+                   * Partition0: CS-specific memory range which is
+                   * implemented as continuous physical memory region
+                   * Partition1: control memory range
+                   */
+
+        nand:cs2 {
+                #address-cells = <2>;
+                #size-cells = <1>;
+                clock-ranges;
+                ranges;
+
+                ti,cs-chipselect = <2>;
+                /* all timings in nanoseconds */
+                ti,cs-min-turnaround-ns = <0>;
+                ti,cs-read-hold-ns = <7>;
+                ti,cs-read-strobe-ns = <42>;
+                ti,cs-read-setup-ns = <14>;
+                ti,cs-write-hold-ns = <7>;
+                ti,cs-write-strobe-ns = <42>;
+                ti,cs-write-setup-ns = <14>;
+
+                nand@0,0x8000000 {
+                        compatible = "ti,davinci-nand";
+                        reg = <0 0x8000000 0x4000000
+                               1 0x0000000 0x0000100>;
+                        /*
+                         * Partition0, offset 0x8000000, size 0x4000000
+                         * Partition1, offset 0x0000000, size 0x0000100
+                         */
+
+                        .. see davinci-nand.txt
+                };
+        };
+
+        nor:cs0 {
+                #address-cells = <2>;
+                #size-cells = <1>;
+                clock-ranges;
+                ranges;
+
+                ti,cs-chipselect = <0>;
+                /* all timings in nanoseconds */
+                ti,cs-min-turnaround-ns = <0>;
+                ti,cs-read-hold-ns = <8>;
+                ti,cs-read-strobe-ns = <40>;
+                ti,cs-read-setup-ns = <14>;
+                ti,cs-write-hold-ns = <7>;
+                ti,cs-write-strobe-ns = <40>;
+                ti,cs-write-setup-ns = <14>;
+                ti,cs-bus-width = <16>;
+
+                flash@0,0x0000000 {
+                        compatible = "cfi-flash";
+                        reg = <0 0x0000000 0x4000000>;
+
+                        ...
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt b/Documentation/devicetree/bindings/mfd/arizona.txt
index 0e295c9d8937..36a0c3d8c726 100644
--- a/Documentation/devicetree/bindings/mfd/arizona.txt
+++ b/Documentation/devicetree/bindings/mfd/arizona.txt
@@ -5,9 +5,10 @@ of analogue I/O.
 
 Required properties:
 
-  - compatible : one of the following chip-specific strings:
-        "wlf,wm5102"
-        "wlf,wm5110"
+  - compatible : One of the following chip-specific strings:
+        "wlf,wm5102"
+        "wlf,wm5110"
+        "wlf,wm8997"
   - reg : I2C slave address when connected using I2C, chip select number when
     using SPI.
 
@@ -25,8 +26,9 @@ Required properties:
   - #gpio-cells : Must be 2. The first cell is the pin number and the
     second cell is used to specify optional parameters (currently unused).
 
-  - AVDD1-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply, CPVDD-supply,
-    SPKVDDL-supply, SPKVDDR-supply : power supplies for the device, as covered
+  - AVDD-supply, DBVDD1-supply, DBVDD2-supply, DBVDD3-supply (wm5102, wm5110),
+    CPVDD-supply, SPKVDDL-supply (wm5102, wm5110), SPKVDDR-supply (wm5102,
+    wm5110), SPKVDD-supply (wm8997) : Power supplies for the device, as covered
     in Documentation/devicetree/bindings/regulator/regulator.txt
 
 Optional properties:
@@ -46,6 +48,7 @@ codec: wm5102@1a {
         compatible = "wlf,wm5102";
         reg = <0x1a>;
         interrupts = <347>;
+        interrupt-controller;
         #interrupt-cells = <2>;
         interrupt-parent = <&gic>;
 
@@ -53,10 +56,10 @@ codec: wm5102@1a {
         #gpio-cells = <2>;
 
         wlf,gpio-defaults = <
-                0x00000000, /* AIF1TXLRCLK */
-                0xffffffff,
-                0xffffffff,
-                0xffffffff,
-                0xffffffff,
+                0x00000000 /* AIF1TXLRCLK */
+                0xffffffff
+                0xffffffff
+                0xffffffff
+                0xffffffff
         >;
 };
diff --git a/Documentation/devicetree/bindings/mfd/bcm590xx.txt b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
new file mode 100644
index 000000000000..1fe30e2b10da
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/bcm590xx.txt
@@ -0,0 +1,37 @@
+-------------------------------
+BCM590xx Power Management Units
+-------------------------------
+
+Required properties:
+- compatible: "brcm,bcm59056"
+- reg: I2C slave address
+- interrupts: interrupt for the PMU. Generic interrupt client node bindings
+  are described in interrupt-controller/interrupts.txt
+
+------------------
+Voltage Regulators
+------------------
+
+Optional child nodes:
+- regulators: container node for regulators following the generic
+  regulator binding in regulator/regulator.txt
+
+  The valid regulator node names for BCM59056 are:
+        rfldo, camldo1, camldo2, simldo1, simldo2, sdldo, sdxldo,
+        mmcldo1, mmcldo2, audldo, micldo, usbldo, vibldo,
+        csr, iosr1, iosr2, msr, sdsr1, sdsr2, vsr
+
+Example:
+        pmu: bcm59056@8 {
+                compatible = "brcm,bcm59056";
+                reg = <0x08>;
+                interrupts = <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>;
+                regulators {
+                        rfldo_reg: rfldo {
+                                regulator-min-microvolt = <1200000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        ...
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/da9055.txt b/Documentation/devicetree/bindings/mfd/da9055.txt
new file mode 100644
index 000000000000..6dab34d34fce
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/da9055.txt
@@ -0,0 +1,72 @@
+* Dialog DA9055 Power Management Integrated Circuit (PMIC)
+
+DA9055 consists of a large and varied group of sub-devices (I2C Only):
+
+Device                   Supply Names    Description
+------                   ------------    -----------
+da9055-gpio             :               : GPIOs
+da9055-regulator        :               : Regulators
+da9055-onkey            :               : On key
+da9055-rtc              :               : RTC
+da9055-hwmon            :               : ADC
+da9055-watchdog         :               : Watchdog
+
+The CODEC device in DA9055 has a separate, configurable I2C address and so
+is instantiated separately from the PMIC.
+
+For details on accompanying CODEC I2C device, see the following:
+Documentation/devicetree/bindings/sound/da9055.txt
+
+======
+
+Required properties:
+- compatible : Should be "dlg,da9055-pmic"
+- reg: Specifies the I2C slave address (defaults to 0x5a but can be modified)
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the IRQs from da9055 are delivered to.
+- interrupts: IRQ line info for da9055 chip.
+- interrupt-controller: da9055 has internal IRQs (has own IRQ domain).
+- #interrupt-cells: Should be 1, is the local IRQ number for da9055.
+
+Sub-nodes:
+- regulators : Contain the regulator nodes. The DA9055 regulators are
+  bound using their names as listed below:
+
+    buck1     : regulator BUCK1
+    buck2     : regulator BUCK2
+    ldo1      : regulator LDO1
+    ldo2      : regulator LDO2
+    ldo3      : regulator LDO3
+    ldo4      : regulator LDO4
+    ldo5      : regulator LDO5
+    ldo6      : regulator LDO6
+
+  The bindings details of individual regulator device can be found in:
+  Documentation/devicetree/bindings/regulator/regulator.txt
+
+
+Example:
+
+        pmic: da9055-pmic@5a {
+                compatible = "dlg,da9055-pmic";
+                reg = <0x5a>;
+                interrupt-parent = <&intc>;
+                interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+                interrupt-controller;
+                #interrupt-cells = <1>;
+
+                regulators {
+                        buck1: BUCK1 {
+                                regulator-min-microvolt = <725000>;
+                                regulator-max-microvolt = <2075000>;
+                        };
+                        buck2: BUCK2 {
+                                regulator-min-microvolt = <925000>;
+                                regulator-max-microvolt = <2500000>;
+                        };
+                        ldo1: LDO1 {
+                                regulator-min-microvolt = <900000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
index b381fa696bf9..4721b2d521e4 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-host.txt
@@ -32,6 +32,29 @@ Optional properties:
 - single-ulpi-bypass: Must be present if the controller contains a single
   ULPI bypass control bit. e.g. OMAP3 silicon <= ES2.1
 
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+  clock-names.
+
+- clock-names: should include:
+  For OMAP3
+  * "usbhost_120m_fck" - 120MHz Functional clock.
+
+  For OMAP4+
+  * "refclk_60m_int" - 60MHz internal reference clock for UTMI clock mux
+  * "refclk_60m_ext_p1" - 60MHz external ref. clock for Port 1's UTMI clock mux.
+  * "refclk_60m_ext_p2" - 60MHz external ref. clock for Port 2's UTMI clock mux
+  * "utmi_p1_gfclk" - Port 1 UTMI clock mux.
+  * "utmi_p2_gfclk" - Port 2 UTMI clock mux.
+  * "usb_host_hs_utmi_p1_clk" - Port 1 UTMI clock gate.
+  * "usb_host_hs_utmi_p2_clk" - Port 2 UTMI clock gate.
+  * "usb_host_hs_utmi_p3_clk" - Port 3 UTMI clock gate.
+  * "usb_host_hs_hsic480m_p1_clk" - Port 1 480MHz HSIC clock gate.
+  * "usb_host_hs_hsic480m_p2_clk" - Port 2 480MHz HSIC clock gate.
+  * "usb_host_hs_hsic480m_p3_clk" - Port 3 480MHz HSIC clock gate.
+  * "usb_host_hs_hsic60m_p1_clk" - Port 1 60MHz HSIC clock gate.
+  * "usb_host_hs_hsic60m_p2_clk" - Port 2 60MHz HSIC clock gate.
+  * "usb_host_hs_hsic60m_p3_clk" - Port 3 60MHz HSIC clock gate.
+
 Required properties if child node exists:
 
 - #address-cells: Must be 1
diff --git a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
index 62fe69724e3b..c58d70437fce 100644
--- a/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
+++ b/Documentation/devicetree/bindings/mfd/omap-usb-tll.txt
@@ -7,6 +7,16 @@ Required properties:
 - interrupts : should contain the TLL module's interrupt
 - ti,hwmod : must contain "usb_tll_hs"
 
+Optional properties:
+
+- clocks: a list of phandles and clock-specifier pairs, one for each entry in
+  clock-names.
+
+- clock-names: should include:
+  * "usb_tll_hs_usb_ch0_clk" - USB TLL channel 0 clock
+  * "usb_tll_hs_usb_ch1_clk" - USB TLL channel 1 clock
+  * "usb_tll_hs_usb_ch2_clk" - USB TLL channel 2 clock
+
 Example:
 
         usbhstll: usbhstll@4a062000 {
diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt
new file mode 100644
index 000000000000..03518dc8b6bd
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/qcom,pm8xxx.txt
@@ -0,0 +1,96 @@
+Qualcomm PM8xxx PMIC multi-function devices
+
+The PM8xxx family of Power Management ICs are used to provide regulated
+voltages and other various functionality to Qualcomm SoCs.
+
+= PROPERTIES
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: must be one of:
+                    "qcom,pm8058"
+                    "qcom,pm8921"
+
+- #address-cells:
+        Usage: required
+        Value type: <u32>
+        Definition: must be 1
+
+- #size-cells:
+        Usage: required
+        Value type: <u32>
+        Definition: must be 0
+
+- interrupts:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: specifies the interrupt that indicates a subdevice
+                    has generated an interrupt (summary interrupt). The
+                    format of the specifier is defined by the binding document
+                    describing the node's interrupt parent.
+
+- #interrupt-cells:
+        Usage: required
+        Value type : <u32>
+        Definition: must be 2. Specifies the number of cells needed to encode
+                    an interrupt source. The 1st cell contains the interrupt
+                    number. The 2nd cell is the trigger type and level flags
+                    encoded as follows:
+
+                        1 = low-to-high edge triggered
+                        2 = high-to-low edge triggered
+                        4 = active high level-sensitive
+                        8 = active low level-sensitive
+
+- interrupt-controller:
+        Usage: required
+        Value type: <empty>
+        Definition: identifies this node as an interrupt controller
+
+= SUBCOMPONENTS
+
+The PMIC contains multiple independent functions, each described in a subnode.
+The below bindings specify the set of valid subnodes.
+
+== Real-Time Clock
+
+- compatible:
+        Usage: required
+        Value type: <string>
+        Definition: must be one of:
+                    "qcom,pm8058-rtc"
+                    "qcom,pm8921-rtc"
+
+- reg:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: single entry specifying the base address of the RTC registers
+
+- interrupts:
+        Usage: required
+        Value type: <prop-encoded-array>
+        Definition: single entry specifying the RTC's alarm interrupt
+
+- allow-set-time:
+        Usage: optional
+        Value type: <empty>
+        Definition: indicates that the setting of RTC time is allowed by
+                    the host CPU
+
+= EXAMPLE
+
+        pmicintc: pmic@0 {
+                compatible = "qcom,pm8921";
+                interrupts = <104 8>;
+                #interrupt-cells = <2>;
+                interrupt-controller;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                rtc@11d {
+                        compatible = "qcom,pm8921-rtc";
+                        reg = <0x11d>;
+                        interrupts = <0x27 0>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/s2mpa01.txt b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
new file mode 100644
index 000000000000..c13d3d8c3947
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/s2mpa01.txt
@@ -0,0 +1,90 @@
+
+* Samsung S2MPA01 Voltage and Current Regulator
+
+The Samsung S2MPA01 is a multi-function device which includes high
+efficiency buck converters including Dual-Phase buck converter, various LDOs,
+and an RTC. It is interfaced to the host controller using an I2C interface.
+Each sub-block is addressed by the host system using different I2C slave
+addresses.
+
+Required properties:
+- compatible: Should be "samsung,s2mpa01-pmic".
+- reg: Specifies the I2C slave address of the PMIC block. It should be 0x66.
+
+Optional properties:
+- interrupt-parent: Specifies the phandle of the interrupt controller to which
+  the interrupts from s2mpa01 are delivered to.
+- interrupts: An interrupt specifier for the sole interrupt generated by the
+  device.
+
+Optional nodes:
+- regulators: The regulators of s2mpa01 that have to be instantiated should be
+  included in a sub-node named 'regulators'. Regulator nodes and constraints
+  included in this sub-node use the standard regulator bindings which are
+  documented elsewhere.
+
+Properties for BUCK regulator nodes:
+- regulator-ramp-delay: ramp delay in uV/us. May be 6250, 12500
+  (default), 25000, or 50000. May be 0 for disabling the ramp delay on
+  BUCK{1,2,3,4}.
+
+ In the absence of the regulator-ramp-delay property, the default ramp
+ delay will be used.
+
+  NOTE: Some BUCKs share the ramp rate setting i.e. same ramp value will be set
+  for a particular group of BUCKs. So provide same regulator-ramp-delay=<value>.
+
+  The following BUCKs share ramp settings:
+  * 1 and 6
+  * 2 and 4
+  * 8, 9, and 10
+
+The following are the names of the regulators that the s2mpa01 PMIC block
+supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
+as per the datasheet of s2mpa01.
+
+        - LDOn
+                  - valid values for n are 1 to 26
+                  - Example: LDO1, LD02, LDO26
+        - BUCKn
+                  - valid values for n are 1 to 10.
+                  - Example: BUCK1, BUCK2, BUCK9
+
+Example:
+
+        s2mpa01_pmic@66 {
+                compatible = "samsung,s2mpa01-pmic";
+                reg = <0x66>;
+
+                regulators {
+                        ldo1_reg: LDO1 {
+                                regulator-name = "VDD_ALIVE";
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <1000000>;
+                        };
+
+                        ldo2_reg: LDO2 {
+                                regulator-name = "VDDQ_MMC2";
+                                regulator-min-microvolt = <2800000>;
+                                regulator-max-microvolt = <2800000>;
+                                regulator-always-on;
+                        };
+
+                        buck1_reg: BUCK1 {
+                                regulator-name = "vdd_mif";
+                                regulator-min-microvolt = <950000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                        };
+
+                        buck2_reg: BUCK2 {
+                                regulator-name = "vdd_arm";
+                                regulator-min-microvolt = <950000>;
+                                regulator-max-microvolt = <1350000>;
+                                regulator-always-on;
+                                regulator-boot-on;
+                                regulator-ramp-delay = <50000>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt b/Documentation/devicetree/bindings/mfd/s2mps11.txt
index 15ee89c3cc7b..802e839b0829 100644
--- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
+++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
@@ -1,5 +1,5 @@
 
-* Samsung S2MPS11 Voltage and Current Regulator
+* Samsung S2MPS11 and S2MPS14 Voltage and Current Regulator
 
 The Samsung S2MPS11 is a multi-function device which includes voltage and
 current regulators, RTC, charger controller and other sub-blocks. It is
@@ -7,7 +7,7 @@ interfaced to the host controller using an I2C interface. Each sub-block is
 addressed by the host system using different I2C slave addresses.
 
 Required properties:
-- compatible: Should be "samsung,s2mps11-pmic".
+- compatible: Should be "samsung,s2mps11-pmic" or "samsung,s2mps14-pmic".
 - reg: Specifies the I2C slave address of the pmic block. It should be 0x66.
 
 Optional properties:
@@ -16,20 +16,25 @@ Optional properties:
 - interrupts: Interrupt specifiers for interrupt sources.
 
 Optional nodes:
-- clocks: s2mps11 provides three(AP/CP/BT) buffered 32.768 KHz outputs, so to
-  register these as clocks with common clock framework instantiate a sub-node
-  named "clocks". It uses the common clock binding documented in :
+- clocks: s2mps11 and s5m8767 provide three(AP/CP/BT) buffered 32.768 KHz
+  outputs, so to register these as clocks with common clock framework
+  instantiate a sub-node named "clocks". It uses the common clock binding
+  documented in :
   [Documentation/devicetree/bindings/clock/clock-bindings.txt]
+  The s2mps14 provides two (AP/BT) buffered 32.768 KHz outputs.
   - #clock-cells: should be 1.
 
   - The following is the list of clocks generated by the controller. Each clock
     is assigned an identifier and client nodes use this identifier to specify
     the clock which they consume.
-    Clock               ID
-    ----------------------
-    32KhzAP             0
-    32KhzCP             1
-    32KhzBT             2
+    Clock               ID           Devices
+    ----------------------------------------------------------
+    32KhzAP             0            S2MPS11, S2MPS14, S5M8767
+    32KhzCP             1            S2MPS11, S5M8767
+    32KhzBT             2            S2MPS11, S2MPS14, S5M8767
+
+  - compatible: Should be one of: "samsung,s2mps11-clk", "samsung,s2mps14-clk",
+                "samsung,s5m8767-clk"
 
 - regulators: The regulators of s2mps11 that have to be instantiated should be
 included in a sub-node named 'regulators'. Regulator nodes included in this
@@ -59,10 +64,14 @@ supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
 as per the datasheet of s2mps11.
 
         - LDOn
-                  - valid values for n are 1 to 38
+                  - valid values for n are:
+                        - S2MPS11: 1 to 38
+                        - S2MPS14: 1 to 25
                   - Example: LDO1, LD02, LDO28
         - BUCKn
-                  - valid values for n are 1 to 10.
+                  - valid values for n are:
+                        - S2MPS11: 1 to 10
+                        - S2MPS14: 1 to 5
                   - Example: BUCK1, BUCK2, BUCK9
 
 Example:
@@ -71,7 +80,8 @@ Example:
                 compatible = "samsung,s2mps11-pmic";
                 reg = <0x66>;
 
-                s2m_osc: clocks{
+                s2m_osc: clocks {
+                        compatible = "samsung,s2mps11-clk";
                         #clock-cells = 1;
                         clock-output-names = "xx", "yy", "zz";
                 };
diff --git a/Documentation/devicetree/bindings/mfd/tps65910.txt b/Documentation/devicetree/bindings/mfd/tps65910.txt
index b4bd98af1cc7..38833e63a59f 100644
--- a/Documentation/devicetree/bindings/mfd/tps65910.txt
+++ b/Documentation/devicetree/bindings/mfd/tps65910.txt
@@ -11,7 +11,7 @@ Required properties:
 - #interrupt-cells: the number of cells to describe an IRQ, this should be 2.
   The first cell is the IRQ number.
   The second cell is the flags, encoded as the trigger masks from
-  Documentation/devicetree/bindings/interrupts.txt
+  Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
 - regulators: This is the list of child nodes that specify the regulator
   initialization data for defined regulators. Not all regulators for the given
   device need to be present. The definition for each of these nodes is defined
diff --git a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
index 68ba37295565..fabdf64a5737 100644
--- a/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
+++ b/Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt
@@ -1,12 +1,12 @@
 Allwinner sunxi-sid
 
 Required properties:
-- compatible: "allwinner,sun4i-sid" or "allwinner,sun7i-a20-sid".
+- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
 - reg: Should contain registers location and length
 
 Example for sun4i:
         sid@01c23800 {
-                compatible = "allwinner,sun4i-sid";
+                compatible = "allwinner,sun4i-a10-sid";
                 reg = <0x01c23800 0x10>
         };
 
diff --git a/Documentation/devicetree/bindings/misc/atmel-ssc.txt b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
index 60960b2755f4..efc98ea1f23d 100644
--- a/Documentation/devicetree/bindings/misc/atmel-ssc.txt
+++ b/Documentation/devicetree/bindings/misc/atmel-ssc.txt
@@ -17,6 +17,14 @@ Required properties for devices compatible with "atmel,at91sam9g45-ssc":
   See Documentation/devicetree/bindings/dma/atmel-dma.txt for details.
 - dma-names: Must be "tx", "rx".
 
+Optional properties:
+  - atmel,clk-from-rk-pin: bool property.
+     - When SSC works in slave mode, according to the hardware design, the
+       clock can get from TK pin, and also can get from RK pin. So, add
+       this parameter to choose where the clock from.
+     - By default the clock is from TK pin, if the clock from RK pin, this
+       property is needed.
+
 Examples:
 - PDC transfer:
 ssc0: ssc@fffbc000 {
diff --git a/Documentation/devicetree/bindings/misc/sram.txt b/Documentation/devicetree/bindings/misc/sram.txt
index 4d0a00e453a8..36cbe5aea990 100644
--- a/Documentation/devicetree/bindings/misc/sram.txt
+++ b/Documentation/devicetree/bindings/misc/sram.txt
@@ -8,9 +8,44 @@ Required properties:
 
 - reg : SRAM iomem address range
 
+Reserving sram areas:
+---------------------
+
+Each child of the sram node specifies a region of reserved memory. Each
+child node should use a 'reg' property to specify a specific range of
+reserved memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node. Unit address (@<address>) should be
+appended to the name.
+
+Required properties in the sram node:
+
+- #address-cells, #size-cells : should use the same values as the root node
+- ranges : standard definition, should translate from local addresses
+           within the sram to bus addresses
+
+Required properties in the area nodes:
+
+- reg : iomem address range, relative to the SRAM range
+
+Optional properties in the area nodes:
+
+- compatible : standard definition, should contain a vendor specific string
+               in the form <vendor>,[<device>-]<usage>
+
 Example:
 
 sram: sram@5c000000 {
         compatible = "mmio-sram";
         reg = <0x5c000000 0x40000>; /* 256 KiB SRAM at address 0x5c000000 */
+
+        #adress-cells = <1>;
+        #size-cells = <1>;
+        ranges = <0 0x5c000000 0x40000>;
+
+        smp-sram@100 {
+                compatible = "socvendor,smp-sram";
+                reg = <0x100 0x50>;
+        };
 };
diff --git a/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
new file mode 100644
index 000000000000..4897bea7e3f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/socfpga-dw-mshc.txt
@@ -0,0 +1,23 @@
+* Altera SOCFPGA specific extensions to the Synopsys Designware Mobile
+  Storage Host Controller
+
+The Synopsys designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsys dw mshc controller properties described
+by synopsys-dw-mshc.txt and the properties used by the Altera SOCFPGA specific
+extensions to the Synopsys Designware Mobile Storage Host Controller.
+
+Required Properties:
+
+* compatible: should be
+        - "altr,socfpga-dw-mshc": for Altera's SOCFPGA platform
+
+Example:
+
+        mmc: dwmmc0@ff704000 {
+                compatible = "altr,socfpga-dw-mshc";
+                reg = <0xff704000 0x1000>;
+                interrupts = <0 129 4>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt
index 03855c8c492a..b53f92e252d4 100644
--- a/Documentation/devicetree/bindings/mtd/nand.txt
+++ b/Documentation/devicetree/bindings/mtd/nand.txt
@@ -5,3 +5,17 @@
   "soft_bch".
 - nand-bus-width : 8 or 16 bus width if not present 8
 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
+
+- nand-ecc-strength: integer representing the number of bits to correct
+                     per ECC step.
+
+- nand-ecc-step-size: integer representing the number of data bytes
+                      that are covered by a single ECC step.
+
+The ECC strength and ECC step size properties define the correction capability
+of a controller. Together, they say a controller can correct "{strength} bit
+errors per {size} bytes".
+
+The interpretation of these parameters is implementation-defined, so not all
+implementations must support all possible combinations. However, implementations
+are encouraged to further specify the value(s) they support.
diff --git a/Documentation/devicetree/bindings/mtd/st-fsm.txt b/Documentation/devicetree/bindings/mtd/st-fsm.txt
new file mode 100644
index 000000000000..c2489391c437
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/st-fsm.txt
@@ -0,0 +1,26 @@
+* ST-Microelectronics SPI FSM Serial (NOR) Flash Controller
+
+Required properties:
+  - compatible : Should be "st,spi-fsm"
+  - reg        : Contains register's location and length.
+  - reg-names  : Should contain the reg names "spi-fsm"
+  - interrupts : The interrupt number
+  - pinctrl-0  : Standard Pinctrl phandle (see: pinctrl/pinctrl-bindings.txt)
+
+Optional properties:
+  - st,syscfg          : Phandle to boot-device system configuration registers
+  - st,boot-device-reg : Address of the aforementioned boot-device register(s)
+  - st,boot-device-spi : Expected boot-device value if booted via this device
+
+Example:
+        spifsm: spifsm@fe902000{
+                compatible         = "st,spi-fsm";
+                reg                =  <0xfe902000 0x1000>;
+                reg-names          = "spi-fsm";
+                pinctrl-0          = <&pinctrl_fsm>;
+                st,syscfg          = <&syscfg_rear>;
+                st,boot-device-reg = <0x958>;
+                st,boot-device-spi = <0x1a>;
+                status = "okay";
+        };
+
diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
index 863d5b8155c7..10640b17c866 100644
--- a/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
+++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-emac.txt
@@ -5,13 +5,9 @@ Required properties:
               "allwinner,sun4i-emac")
 - reg: address and length of the register set for the device.
 - interrupts: interrupt for the device
-- phy: A phandle to a phy node defining the PHY address (as the reg
-  property, a single integer).
+- phy: see ethernet.txt file in the same directory.
 - clocks: A phandle to the reference clock for this device
 
-Optional properties:
-- (local-)mac-address: mac address to be used by this driver
-
 Example:
 
 emac: ethernet@01c0b000 {
diff --git a/Documentation/devicetree/bindings/net/altera_tse.txt b/Documentation/devicetree/bindings/net/altera_tse.txt
new file mode 100644
index 000000000000..a706297998e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/altera_tse.txt
@@ -0,0 +1,114 @@
+* Altera Triple-Speed Ethernet MAC driver (TSE)
+
+Required properties:
+- compatible: Should be "altr,tse-1.0" for legacy SGDMA based TSE, and should
+                be "altr,tse-msgdma-1.0" for the preferred MSGDMA based TSE.
+                ALTR is supported for legacy device trees, but is deprecated.
+                altr should be used for all new designs.
+- reg: Address and length of the register set for the device. It contains
+  the information of registers in the same order as described by reg-names
+- reg-names: Should contain the reg names
+  "control_port": MAC configuration space region
+  "tx_csr":       xDMA Tx dispatcher control and status space region
+  "tx_desc":      MSGDMA Tx dispatcher descriptor space region
+  "rx_csr" :      xDMA Rx dispatcher control and status space region
+  "rx_desc":      MSGDMA Rx dispatcher descriptor space region
+  "rx_resp":      MSGDMA Rx dispatcher response space region
+  "s1":           SGDMA descriptor memory
+- interrupts: Should contain the TSE interrupts and it's mode.
+- interrupt-names: Should contain the interrupt names
+  "rx_irq":       xDMA Rx dispatcher interrupt
+  "tx_irq":       xDMA Tx dispatcher interrupt
+- rx-fifo-depth: MAC receive FIFO buffer depth in bytes
+- tx-fifo-depth: MAC transmit FIFO buffer depth in bytes
+- phy-mode: See ethernet.txt in the same directory.
+- phy-handle: See ethernet.txt in the same directory.
+- phy-addr: See ethernet.txt in the same directory. A configuration should
+                include phy-handle or phy-addr.
+- altr,has-supplementary-unicast:
+                If present, TSE supports additional unicast addresses.
+                Otherwise additional unicast addresses are not supported.
+- altr,has-hash-multicast-filter:
+                If present, TSE supports a hash based multicast filter.
+                Otherwise, hash-based multicast filtering is not supported.
+
+- mdio device tree subnode: When the TSE has a phy connected to its local
+                mdio, there must be device tree subnode with the following
+                required properties:
+
+        - compatible: Must be "altr,tse-mdio".
+        - #address-cells: Must be <1>.
+        - #size-cells: Must be <0>.
+
+        For each phy on the mdio bus, there must be a node with the following
+        fields:
+
+        - reg: phy id used to communicate to phy.
+        - device_type: Must be "ethernet-phy".
+
+Optional properties:
+- local-mac-address: See ethernet.txt in the same directory.
+- max-frame-size: See ethernet.txt in the same directory.
+
+Example:
+
+        tse_sub_0_eth_tse_0: ethernet@0x1,00000000 {
+                compatible = "altr,tse-msgdma-1.0";
+                reg =   <0x00000001 0x00000000 0x00000400>,
+                        <0x00000001 0x00000460 0x00000020>,
+                        <0x00000001 0x00000480 0x00000020>,
+                        <0x00000001 0x000004A0 0x00000008>,
+                        <0x00000001 0x00000400 0x00000020>,
+                        <0x00000001 0x00000420 0x00000020>;
+                reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
+                interrupt-parent = <&hps_0_arm_gic_0>;
+                interrupts = <0 41 4>, <0 40 4>;
+                interrupt-names = "rx_irq", "tx_irq";
+                rx-fifo-depth = <2048>;
+                tx-fifo-depth = <2048>;
+                address-bits = <48>;
+                max-frame-size = <1500>;
+                local-mac-address = [ 00 00 00 00 00 00 ];
+                phy-mode = "gmii";
+                altr,has-supplementary-unicast;
+                altr,has-hash-multicast-filter;
+                phy-handle = <&phy0>;
+                mdio {
+                        compatible = "altr,tse-mdio";
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+                        phy0: ethernet-phy@0 {
+                                reg = <0x0>;
+                                device_type = "ethernet-phy";
+                        };
+
+                        phy1: ethernet-phy@1 {
+                                reg = <0x1>;
+                                device_type = "ethernet-phy";
+                        };
+
+                };
+        };
+
+        tse_sub_1_eth_tse_0: ethernet@0x1,00001000 {
+                compatible = "altr,tse-msgdma-1.0";
+                reg =   <0x00000001 0x00001000 0x00000400>,
+                        <0x00000001 0x00001460 0x00000020>,
+                        <0x00000001 0x00001480 0x00000020>,
+                        <0x00000001 0x000014A0 0x00000008>,
+                        <0x00000001 0x00001400 0x00000020>,
+                        <0x00000001 0x00001420 0x00000020>;
+                reg-names = "control_port", "rx_csr", "rx_desc", "rx_resp", "tx_csr", "tx_desc";
+                interrupt-parent = <&hps_0_arm_gic_0>;
+                interrupts = <0 43 4>, <0 42 4>;
+                interrupt-names = "rx_irq", "tx_irq";
+                rx-fifo-depth = <2048>;
+                tx-fifo-depth = <2048>;
+                address-bits = <48>;
+                max-frame-size = <1500>;
+                local-mac-address = [ 00 00 00 00 00 00 ];
+                phy-mode = "gmii";
+                altr,has-supplementary-unicast;
+                altr,has-hash-multicast-filter;
+                phy-handle = <&phy1>;
+        };
diff --git a/Documentation/devicetree/bindings/net/arc_emac.txt b/Documentation/devicetree/bindings/net/arc_emac.txt
index bcbc3f009158..7fbb027218a1 100644
--- a/Documentation/devicetree/bindings/net/arc_emac.txt
+++ b/Documentation/devicetree/bindings/net/arc_emac.txt
@@ -6,19 +6,12 @@ Required properties:
 - interrupts: Should contain the EMAC interrupts
 - clock-frequency: CPU frequency. It is needed to calculate and set polling
 period of EMAC.
-- max-speed: Maximum supported data-rate in Mbit/s. In some HW configurations
-bandwidth of external memory controller might be a limiting factor. That's why
-it's required to specify which data-rate is supported on current SoC or FPGA.
-For example if only 10 Mbit/s is supported (10BASE-T) set "10". If 100 Mbit/s is
-supported (100BASE-TX) set "100".
-- phy: PHY device attached to the EMAC via MDIO bus
+- max-speed: see ethernet.txt file in the same directory.
+- phy: see ethernet.txt file in the same directory.
 
 Child nodes of the driver are the individual PHY devices connected to the
 MDIO bus. They must have a "reg" property given the PHY address on the MDIO bus.
 
-Optional properties:
-- mac-address: 6 bytes, mac address
-
 Examples:
 
         ethernet@c0fc2000 {
diff --git a/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
new file mode 100644
index 000000000000..f2febb94550e
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/broadcom-bcmgenet.txt
@@ -0,0 +1,121 @@
+* Broadcom BCM7xxx Ethernet Controller (GENET)
+
+Required properties:
+- compatible: should contain one of "brcm,genet-v1", "brcm,genet-v2",
+  "brcm,genet-v3", "brcm,genet-v4".
+- reg: address and length of the register set for the device
+- interrupts: must be two cells, the first cell is the general purpose
+  interrupt line, while the second cell is the interrupt for the ring
+  RX and TX queues operating in ring mode
+- phy-mode: see ethernet.txt file in the same directory
+- #address-cells: should be 1
+- #size-cells: should be 1
+
+Optional properties:
+- clocks: When provided, must be two phandles to the functional clocks nodes
+  of the GENET block. The first phandle is the main GENET clock used during
+  normal operation, while the second phandle is the Wake-on-LAN clock.
+- clock-names: When provided, names of the functional clock phandles, first
+  name should be "enet" and second should be "enet-wol".
+
+- phy-handle: See ethernet.txt file in the same directory; used to describe
+  configurations where a PHY (internal or external) is used.
+
+- fixed-link: When the GENET interface is connected to a MoCA hardware block or
+  when operating in a RGMII to RGMII type of connection, or when the MDIO bus is
+  voluntarily disabled, this property should be used to describe the "fixed link".
+  See Documentation/devicetree/bindings/net/fsl-tsec-phy.txt for information on
+  the property specifics
+
+Required child nodes:
+
+- mdio bus node: this node should always be present regarless of the PHY
+  configuration of the GENET instance
+
+MDIO bus node required properties:
+
+- compatible: should contain one of "brcm,genet-mdio-v1", "brcm,genet-mdio-v2"
+  "brcm,genet-mdio-v3", "brcm,genet-mdio-v4", the version has to match the
+  parent node compatible property (e.g: brcm,genet-v4 pairs with
+  brcm,genet-mdio-v4)
+- reg: address and length relative to the parent node base register address
+- #address-cells: address cell for MDIO bus addressing, should be 1
+- #size-cells: size of the cells for MDIO bus addressing, should be 0
+
+Ethernet PHY node properties:
+
+See Documentation/devicetree/bindings/net/phy.txt for the list of required and
+optional properties.
+
+Internal Gigabit PHY example:
+
+ethernet@f0b60000 {
+        phy-mode = "internal";
+        phy-handle = <&phy1>;
+        mac-address = [ 00 10 18 36 23 1a ];
+        compatible = "brcm,genet-v4";
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        reg = <0xf0b60000 0xfc4c>;
+        interrupts = <0x0 0x14 0x0>, <0x0 0x15 0x0>;
+
+        mdio@e14 {
+                compatible = "brcm,genet-mdio-v4";
+                #address-cells = <0x1>;
+                #size-cells = <0x0>;
+                reg = <0xe14 0x8>;
+
+                phy1: ethernet-phy@1 {
+                        max-speed = <1000>;
+                        reg = <0x1>;
+                        compatible = "brcm,28nm-gphy", "ethernet-phy-ieee802.3-c22";
+                };
+        };
+};
+
+MoCA interface / MAC to MAC example:
+
+ethernet@f0b80000 {
+        phy-mode = "moca";
+        fixed-link = <1 0 1000 0 0>;
+        mac-address = [ 00 10 18 36 24 1a ];
+        compatible = "brcm,genet-v4";
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        reg = <0xf0b80000 0xfc4c>;
+        interrupts = <0x0 0x16 0x0>, <0x0 0x17 0x0>;
+
+        mdio@e14 {
+                compatible = "brcm,genet-mdio-v4";
+                #address-cells = <0x1>;
+                #size-cells = <0x0>;
+                reg = <0xe14 0x8>;
+        };
+};
+
+
+External MDIO-connected Gigabit PHY/switch:
+
+ethernet@f0ba0000 {
+        phy-mode = "rgmii";
+        phy-handle = <&phy0>;
+        mac-address = [ 00 10 18 36 26 1a ];
+        compatible = "brcm,genet-v4";
+        #address-cells = <0x1>;
+        #size-cells = <0x1>;
+        reg = <0xf0ba0000 0xfc4c>;
+        interrupts = <0x0 0x18 0x0>, <0x0 0x19 0x0>;
+
+        mdio@0e14 {
+                compatible = "brcm,genet-mdio-v4";
+                #address-cells = <0x1>;
+                #size-cells = <0x0>;
+                reg = <0xe14 0x8>;
+
+                phy0: ethernet-phy@0 {
+                        max-speed = <1000>;
+                        reg = <0x0>;
+                        compatible = "brcm,bcm53125", "ethernet-phy-ieee802.3-c22";
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt
index f2105a47ec87..b4a6d53fb01a 100644
--- a/Documentation/devicetree/bindings/net/can/sja1000.txt
+++ b/Documentation/devicetree/bindings/net/can/sja1000.txt
@@ -12,6 +12,10 @@ Required properties:
 
 Optional properties:
 
+- reg-io-width : Specify the size (in bytes) of the IO accesses that
+        should be performed on the device.  Valid value is 1, 2 or 4.
+        Default to 1 (8 bits).
+
 - nxp,external-clock-frequency : Frequency of the external oscillator
         clock in Hz. Note that the internal clock frequency used by the
         SJA1000 is half of that value. If not specified, a default value
diff --git a/Documentation/devicetree/bindings/net/cavium-mix.txt b/Documentation/devicetree/bindings/net/cavium-mix.txt
index 5da628db68bf..8d7c3096390f 100644
--- a/Documentation/devicetree/bindings/net/cavium-mix.txt
+++ b/Documentation/devicetree/bindings/net/cavium-mix.txt
@@ -18,12 +18,7 @@ Properties:
 - interrupts: Two interrupt specifiers.  The first is the MIX
   interrupt routing and the second the routing for the AGL interrupts.
 
-- mac-address: Optional, the MAC address to assign to the device.
-
-- local-mac-address: Optional, the MAC address to assign to the device
-  if mac-address is not specified.
-
-- phy-handle: Optional, a phandle for the PHY device connected to this device.
+- phy-handle: Optional, see ethernet.txt file in the same directory.
 
 Example:
         ethernet@1070000100800 {
diff --git a/Documentation/devicetree/bindings/net/cavium-pip.txt b/Documentation/devicetree/bindings/net/cavium-pip.txt
index d4c53ba04b3b..7dbd158810d2 100644
--- a/Documentation/devicetree/bindings/net/cavium-pip.txt
+++ b/Documentation/devicetree/bindings/net/cavium-pip.txt
@@ -35,12 +35,7 @@ Properties for PIP port which is a child the PIP interface:
 
 - reg: The port number within the interface group.
 
-- mac-address: Optional, the MAC address to assign to the device.
-
-- local-mac-address: Optional, the MAC address to assign to the device
-  if mac-address is not specified.
-
-- phy-handle: Optional, a phandle for the PHY device connected to this device.
+- phy-handle: Optional, see ethernet.txt file in the same directory.
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/net/cdns-emac.txt b/Documentation/devicetree/bindings/net/cdns-emac.txt
index 09055c2495f0..abd67c13d344 100644
--- a/Documentation/devicetree/bindings/net/cdns-emac.txt
+++ b/Documentation/devicetree/bindings/net/cdns-emac.txt
@@ -6,11 +6,7 @@ Required properties:
   or the generic form: "cdns,emac".
 - reg: Address and length of the register set for the device
 - interrupts: Should contain macb interrupt
-- phy-mode: String, operation mode of the PHY interface.
-  Supported values are: "mii", "rmii".
-
-Optional properties:
-- local-mac-address: 6 bytes, mac address
+- phy-mode: see ethernet.txt file in the same directory.
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/net/cpsw.txt b/Documentation/devicetree/bindings/net/cpsw.txt
index 05d660e4ac64..ae2b8b7f9c38 100644
--- a/Documentation/devicetree/bindings/net/cpsw.txt
+++ b/Documentation/devicetree/bindings/net/cpsw.txt
@@ -28,9 +28,8 @@ Optional properties:
 Slave Properties:
 Required properties:
 - phy_id                : Specifies slave phy id
-- phy-mode              : The interface between the SoC and the PHY (a string
-                          that of_get_phy_mode() can understand)
-- mac-address           : Specifies slave MAC address
+- phy-mode              : See ethernet.txt file in the same directory
+- mac-address           : See ethernet.txt file in the same directory
 
 Optional properties:
 - dual_emac_res_vlan    : Specifies VID to be used to segregate the ports
diff --git a/Documentation/devicetree/bindings/net/davicom-dm9000.txt b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
index 2d39c990e641..28767ed7c1bd 100644
--- a/Documentation/devicetree/bindings/net/davicom-dm9000.txt
+++ b/Documentation/devicetree/bindings/net/davicom-dm9000.txt
@@ -9,8 +9,6 @@ Required properties:
 - interrupts : interrupt specifier specific to interrupt controller
 
 Optional properties:
-- local-mac-address : A bytestring of 6 bytes specifying Ethernet MAC address
-    to use (from firmware or bootloader)
 - davicom,no-eeprom : Configuration EEPROM is not available
 - davicom,ext-phy : Use external PHY
 
diff --git a/Documentation/devicetree/bindings/net/davinci_emac.txt b/Documentation/devicetree/bindings/net/davinci_emac.txt
index 6e356d15154a..032808843f90 100644
--- a/Documentation/devicetree/bindings/net/davinci_emac.txt
+++ b/Documentation/devicetree/bindings/net/davinci_emac.txt
@@ -17,9 +17,8 @@ Required properties:
                           Miscellaneous Interrupt>
 
 Optional properties:
-- phy-handle: Contains a phandle to an Ethernet PHY.
+- phy-handle: See ethernet.txt file in the same directory.
               If absent, davinci_emac driver defaults to 100/FULL.
-- local-mac-address : 6 bytes, mac address
 - ti,davinci-rmii-en: 1 byte, 1 means use RMII
 - ti,davinci-no-bd-ram: boolean, does EMAC have BD RAM?
 
diff --git a/Documentation/devicetree/bindings/net/ethernet.txt b/Documentation/devicetree/bindings/net/ethernet.txt
new file mode 100644
index 000000000000..9ecd43d8792c
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/ethernet.txt
@@ -0,0 +1,25 @@
+The following properties are common to the Ethernet controllers:
+
+- local-mac-address: array of 6 bytes, specifies the MAC address that was
+  assigned to the network device;
+- mac-address: array of 6 bytes, specifies the MAC address that was last used by
+  the boot program; should be used in cases where the MAC address assigned to
+  the device by the boot program is different from the "local-mac-address"
+  property;
+- max-speed: number, specifies maximum speed in Mbit/s supported by the device;
+- max-frame-size: number, maximum transfer unit (IEEE defined MTU), rather than
+  the maximum frame size (there's contradiction in ePAPR).
+- phy-mode: string, operation mode of the PHY interface; supported values are
+  "mii", "gmii", "sgmii", "tbi", "rev-mii", "rmii", "rgmii", "rgmii-id",
+  "rgmii-rxid", "rgmii-txid", "rtbi", "smii", "xgmii"; this is now a de-facto
+  standard property;
+- phy-connection-type: the same as "phy-mode" property but described in ePAPR;
+- phy-handle: phandle, specifies a reference to a node representing a PHY
+  device; this property is described in ePAPR and so preferred;
+- phy: the same as "phy-handle" property, not recommended for new bindings.
+- phy-device: the same as "phy-handle" property, not recommended for new
+  bindings.
+
+Child nodes of the Ethernet controller are typically the individual PHY devices
+connected via the MDIO bus (sometimes the MDIO bus controller is separate).
+They are described in the phy.txt file in this same directory.
diff --git a/Documentation/devicetree/bindings/net/fsl-fec.txt b/Documentation/devicetree/bindings/net/fsl-fec.txt
index 845ff848d895..6bc84adb10c0 100644
--- a/Documentation/devicetree/bindings/net/fsl-fec.txt
+++ b/Documentation/devicetree/bindings/net/fsl-fec.txt
@@ -4,12 +4,9 @@ Required properties:
 - compatible : Should be "fsl,<soc>-fec"
 - reg : Address and length of the register set for the device
 - interrupts : Should contain fec interrupt
-- phy-mode : String, operation mode of the PHY interface.
-  Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
-  "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+- phy-mode : See ethernet.txt file in the same directory
 
 Optional properties:
-- local-mac-address : 6 bytes, mac address
 - phy-reset-gpios : Should specify the gpio for phy reset
 - phy-reset-duration : Reset duration in milliseconds.  Should present
   only if property "phy-reset-gpios" is available.  Missing the property
diff --git a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
index d2ea4605d078..737cdef4f903 100644
--- a/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
+++ b/Documentation/devicetree/bindings/net/fsl-tsec-phy.txt
@@ -38,22 +38,17 @@ Properties:
   - model : Model of the device.  Can be "TSEC", "eTSEC", or "FEC"
   - compatible : Should be "gianfar"
   - reg : Offset and length of the register set for the device
-  - local-mac-address : List of bytes representing the ethernet address of
-    this controller
   - interrupts : For FEC devices, the first interrupt is the device's
     interrupt.  For TSEC and eTSEC devices, the first interrupt is
     transmit, the second is receive, and the third is error.
-  - phy-handle : The phandle for the PHY connected to this ethernet
-    controller.
+  - phy-handle : See ethernet.txt file in the same directory.
   - fixed-link : <a b c d e> where a is emulated phy id - choose any,
     but unique to the all specified fixed-links, b is duplex - 0 half,
     1 full, c is link speed - d#10/d#100/d#1000, d is pause - 0 no
     pause, 1 pause, e is asym_pause - 0 no asym_pause, 1 asym_pause.
-  - phy-connection-type : a string naming the controller/PHY interface type,
-    i.e., "mii" (default), "rmii", "gmii", "rgmii", "rgmii-id", "sgmii",
-    "tbi", or "rtbi".  This property is only really needed if the connection
-    is of type "rgmii-id", as all other connection types are detected by
-    hardware.
+  - phy-connection-type : See ethernet.txt file in the same directory.
+    This property is only really needed if the connection is of type
+    "rgmii-id", as all other connection types are detected by hardware.
   - fsl,magic-packet : If present, indicates that the hardware supports
     waking up via magic packet.
   - bd-stash : If present, indicates that the hardware supports stashing
diff --git a/Documentation/devicetree/bindings/net/lpc-eth.txt b/Documentation/devicetree/bindings/net/lpc-eth.txt
index 585021acd178..b92e927808b6 100644
--- a/Documentation/devicetree/bindings/net/lpc-eth.txt
+++ b/Documentation/devicetree/bindings/net/lpc-eth.txt
@@ -6,10 +6,9 @@ Required properties:
 - interrupts: Should contain ethernet controller interrupt
 
 Optional properties:
-- phy-mode: String, operation mode of the PHY interface.
-  Supported values are: "mii", "rmii" (default)
+- phy-mode: See ethernet.txt file in the same directory. If the property is
+  absent, "rmii" is assumed.
 - use-iram: Use LPC32xx internal SRAM (IRAM) for DMA buffering
-- local-mac-address : 6 bytes, mac address
 
 Example:
 
diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt
index 70af2ec12b09..aaa696414f57 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -8,16 +8,12 @@ Required properties:
   the Cadence GEM, or the generic form: "cdns,gem".
 - reg: Address and length of the register set for the device
 - interrupts: Should contain macb interrupt
-- phy-mode: String, operation mode of the PHY interface.
-  Supported values are: "mii", "rmii", "gmii", "rgmii".
+- phy-mode: See ethernet.txt file in the same directory.
 - clock-names: Tuple listing input clock names.
         Required elements: 'pclk', 'hclk'
         Optional elements: 'tx_clk'
 - clocks: Phandles to input clocks.
 
-Optional properties:
-- local-mac-address: 6 bytes, mac address
-
 Examples:
 
         macb0: ethernet@fffc4000 {
diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index 859a6fa7569c..750d577e8083 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -4,10 +4,8 @@ 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)
+- phy: See ethernet.txt file in the same directory.
+- phy-mode: See ethernet.txt file in the same directory
 - clocks: a pointer to the reference clock for this device.
 
 Example:
diff --git a/Documentation/devicetree/bindings/net/marvell-orion-net.txt b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
index c233b6114242..bce52b2ec55e 100644
--- a/Documentation/devicetree/bindings/net/marvell-orion-net.txt
+++ b/Documentation/devicetree/bindings/net/marvell-orion-net.txt
@@ -36,7 +36,7 @@ Required port properties:
       "marvell,kirkwood-eth-port".
  - reg: port number relative to ethernet controller, shall be 0, 1, or 2.
  - interrupts: port interrupt.
- - local-mac-address: 6 bytes MAC address.
+ - local-mac-address: See ethernet.txt file in the same directory.
 
 Optional port properties:
  - marvell,tx-queue-size: size of the transmit ring buffer.
@@ -48,7 +48,7 @@ Optional port properties:
 
 and
 
- - phy-handle: phandle reference to ethernet PHY.
+ - phy-handle: See ethernet.txt file in the same directory.
 
 or
 
diff --git a/Documentation/devicetree/bindings/net/micrel-ks8851.txt b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
index 4fc392763611..d54d0cc79487 100644
--- a/Documentation/devicetree/bindings/net/micrel-ks8851.txt
+++ b/Documentation/devicetree/bindings/net/micrel-ks8851.txt
@@ -6,5 +6,4 @@ Required properties:
 - interrupts : interrupt connection
 
 Optional properties:
-- local-mac-address : Ethernet mac address to use
 - vdd-supply:   supply for Ethernet mac
diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt
new file mode 100644
index 000000000000..98a3e61f9ee8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/micrel.txt
@@ -0,0 +1,18 @@
+Micrel PHY properties.
+
+These properties cover the base properties Micrel PHYs.
+
+Optional properties:
+
+ - micrel,led-mode : LED mode value to set for PHYs with configurable LEDs.
+
+              Configure the LED mode with single value. The list of PHYs and
+              the bits that are currently supported:
+
+              KSZ8001: register 0x1e, bits 15..14
+              KSZ8041: register 0x1e, bits 15..14
+              KSZ8021: register 0x1f, bits 5..4
+              KSZ8031: register 0x1f, bits 5..4
+              KSZ8051: register 0x1f, bits 5..4
+
+              See the respective PHY datasheet for the mode values.
diff --git a/Documentation/devicetree/bindings/net/nfc/trf7970a.txt b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
new file mode 100644
index 000000000000..8dd3ef7bc56b
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/nfc/trf7970a.txt
@@ -0,0 +1,34 @@
+* Texas Instruments TRF7970A RFID/NFC/15693 Transceiver
+
+Required properties:
+- compatible: Should be "ti,trf7970a".
+- spi-max-frequency: Maximum SPI frequency (<= 2000000).
+- interrupt-parent: phandle of parent interrupt handler.
+- interrupts: A single interrupt specifier.
+- ti,enable-gpios: Two GPIO entries used for 'EN' and 'EN2' pins on the
+  TRF7970A.
+- vin-supply: Regulator for supply voltage to VIN pin
+
+Optional SoC Specific Properties:
+- pinctrl-names: Contains only one value - "default".
+- pintctrl-0: Specifies the pin control groups used for this controller.
+
+Example (for ARM-based BeagleBone with TRF7970A on SPI1):
+
+&spi1 {
+        status = "okay";
+
+        nfc@0 {
+                compatible = "ti,trf7970a";
+                reg = <0>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&trf7970a_default>;
+                spi-max-frequency = <2000000>;
+                interrupt-parent = <&gpio2>;
+                interrupts = <14 0>;
+                ti,enable-gpios = <&gpio2 2 GPIO_ACTIVE_LOW>,
+                                  <&gpio2 5 GPIO_ACTIVE_LOW>;
+                vin-supply = <&ldo3_reg>;
+                status = "okay";
+        };
+};
diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
index 58307d0931c8..5b8c58903077 100644
--- a/Documentation/devicetree/bindings/net/phy.txt
+++ b/Documentation/devicetree/bindings/net/phy.txt
@@ -21,10 +21,18 @@ Optional Properties:
   elements.
 - max-speed: Maximum PHY supported speed (10, 100, 1000...)
 
+  If the phy's identifier is known then the list may contain an entry
+  of the form: "ethernet-phy-idAAAA.BBBB" where
+     AAAA - The value of the 16 bit Phy Identifier 1 register as
+            4 hex digits. This is the chip vendor OUI bits 3:18
+     BBBB - The value of the 16 bit Phy Identifier 2 register as
+            4 hex digits. This is the chip vendor OUI bits 19:24,
+            followed by 10 bits of a vendor specific ID.
+
 Example:
 
 ethernet-phy@0 {
-        compatible = "ethernet-phy-ieee802.3-c22";
+        compatible = "ethernet-phy-id0141.0e90", "ethernet-phy-ieee802.3-c22";
         interrupt-parent = <40000>;
         interrupts = <35 1>;
         reg = <0>;
diff --git a/Documentation/devicetree/bindings/net/samsung-sxgbe.txt b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
new file mode 100644
index 000000000000..989f6c95cfd5
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/samsung-sxgbe.txt
@@ -0,0 +1,52 @@
+* Samsung 10G Ethernet driver (SXGBE)
+
+Required properties:
+- compatible: Should be "samsung,sxgbe-v2.0a"
+- reg: Address and length of the register set for the device
+- interrupt-parent: Should be the phandle for the interrupt controller
+  that services interrupts for this device
+- interrupts: Should contain the SXGBE interrupts
+  These interrupts are ordered by fixed and follows variable
+  trasmit DMA interrupts, receive DMA interrupts and lpi interrupt.
+  index 0 - this is fixed common interrupt of SXGBE and it is always
+  available.
+  index 1 to 25 - 8 variable trasmit interrupts, variable 16 receive interrupts
+  and 1 optional lpi interrupt.
+- phy-mode: String, operation mode of the PHY interface.
+  Supported values are: "sgmii", "xgmii".
+- samsung,pbl: Integer, Programmable Burst Length.
+  Supported values are 1, 2, 4, 8, 16, or 32.
+- samsung,burst-map: Integer, Program the possible bursts supported by sxgbe
+  This is an interger and represents allowable DMA bursts when fixed burst.
+  Allowable range is 0x01-0x3F. When this field is set fixed burst is enabled.
+  When fixed length is needed for burst mode, it can be set within allowable
+  range.
+
+Optional properties:
+- mac-address: 6 bytes, mac address
+- max-frame-size: Maximum Transfer Unit (IEEE defined MTU), rather
+                  than the maximum frame size.
+
+Example:
+
+        aliases {
+                ethernet0 = <&sxgbe0>;
+        };
+
+        sxgbe0: ethernet@1a040000 {
+                compatible = "samsung,sxgbe-v2.0a";
+                reg = <0 0x1a040000 0 0x10000>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 209 4>, <0 185 4>, <0 186 4>, <0 187 4>,
+                             <0 188 4>, <0 189 4>, <0 190 4>, <0 191 4>,
+                             <0 192 4>, <0 193 4>, <0 194 4>, <0 195 4>,
+                             <0 196 4>, <0 197 4>, <0 198 4>, <0 199 4>,
+                             <0 200 4>, <0 201 4>, <0 202 4>, <0 203 4>,
+                             <0 204 4>, <0 205 4>, <0 206 4>, <0 207 4>,
+                             <0 208 4>, <0 210 4>;
+                samsung,pbl = <0x08>
+                samsung,burst-map = <0x20>
+                mac-address = [ 00 11 22 33 44 55 ]; /* Filled in by U-Boot */
+                max-frame-size = <9000>;
+                phy-mode = "xgmii";
+        };
diff --git a/Documentation/devicetree/bindings/net/sh_eth.txt b/Documentation/devicetree/bindings/net/sh_eth.txt
new file mode 100644
index 000000000000..e7106b50dbdc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/sh_eth.txt
@@ -0,0 +1,55 @@
+* Renesas Electronics SH EtherMAC
+
+This file provides information on what the device node for the SH EtherMAC
+interface contains.
+
+Required properties:
+- compatible: "renesas,gether-r8a7740" if the device is a part of R8A7740 SoC.
+              "renesas,ether-r8a7778"  if the device is a part of R8A7778 SoC.
+              "renesas,ether-r8a7779"  if the device is a part of R8A7779 SoC.
+              "renesas,ether-r8a7790"  if the device is a part of R8A7790 SoC.
+              "renesas,ether-r8a7791"  if the device is a part of R8A7791 SoC.
+              "renesas,ether-r7s72100" if the device is a part of R7S72100 SoC.
+- reg: offset and length of (1) the E-DMAC/feLic register block (required),
+       (2) the TSU register block (optional).
+- interrupts: interrupt specifier for the sole interrupt.
+- phy-mode: see ethernet.txt file in the same directory.
+- phy-handle: see ethernet.txt file in the same directory.
+- #address-cells: number of address cells for the MDIO bus, must be equal to 1.
+- #size-cells: number of size cells on the MDIO bus, must be equal to 0.
+- clocks: clock phandle and specifier pair.
+- pinctrl-0: phandle, referring to a default pin configuration node.
+
+Optional properties:
+- interrupt-parent: the phandle for the interrupt controller that services
+                    interrupts for this device.
+- pinctrl-names: pin configuration state name ("default").
+- renesas,no-ether-link: boolean, specify when a board does not provide a proper
+                         Ether LINK signal.
+- renesas,ether-link-active-low: boolean, specify when the Ether LINK signal is
+                                 active-low instead of normal active-high.
+
+Example (Lager board):
+
+        ethernet@ee700000 {
+                compatible = "renesas,ether-r8a7790";
+                reg = <0 0xee700000 0 0x400>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 162 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&mstp8_clks R8A7790_CLK_ETHER>;
+                phy-mode = "rmii";
+                phy-handle = <&phy1>;
+                pinctrl-0 = <&ether_pins>;
+                pinctrl-names = "default";
+                renesas,ether-link-active-low;
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                phy1: ethernet-phy@1 {
+                        reg = <1>;
+                        interrupt-parent = <&irqc0>;
+                        interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+                        pinctrl-0 = <&phy1_pins>;
+                        pinctrl-names = "default";
+                };
+        };
diff --git a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
index 5a41a8658daa..0f8487b88822 100644
--- a/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
+++ b/Documentation/devicetree/bindings/net/smsc-lan91c111.txt
@@ -6,8 +6,7 @@ Required properties:
 - interrupts : interrupt connection
 
 Optional properties:
-- phy-device : phandle to Ethernet phy
-- local-mac-address : Ethernet mac address to use
+- phy-device : see ethernet.txt file in the same directory
 - reg-io-width : Mask of sizes (in bytes) of the IO accesses that
   are supported on the device.  Valid value for SMSC LAN91c111 are
   1, 2 or 4.  If it's omitted or invalid, the size would be 2 meaning
diff --git a/Documentation/devicetree/bindings/net/smsc911x.txt b/Documentation/devicetree/bindings/net/smsc911x.txt
index adb5b5744ecd..3fed3c124411 100644
--- a/Documentation/devicetree/bindings/net/smsc911x.txt
+++ b/Documentation/devicetree/bindings/net/smsc911x.txt
@@ -6,9 +6,7 @@ Required properties:
 - interrupts : Should contain SMSC LAN interrupt line
 - interrupt-parent : Should be the phandle for the interrupt controller
   that services interrupts for this device
-- phy-mode : String, operation mode of the PHY interface.
-  Supported values are: "mii", "gmii", "sgmii", "tbi", "rmii",
-  "rgmii", "rgmii-id", "rgmii-rxid", "rgmii-txid", "rtbi", "smii".
+- phy-mode : See ethernet.txt file in the same directory
 
 Optional properties:
 - reg-shift : Specify the quantity to shift the register offsets by
@@ -23,7 +21,6 @@ Optional properties:
   external PHY
 - smsc,save-mac-address : Indicates that mac address needs to be saved
   before resetting the controller
-- local-mac-address : 6 bytes, mac address
 
 Examples:
 
diff --git a/Documentation/devicetree/bindings/net/socfpga-dwmac.txt b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
new file mode 100644
index 000000000000..636f0ac4e223
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/socfpga-dwmac.txt
@@ -0,0 +1,27 @@
+Altera SOCFPGA SoC DWMAC controller
+
+This is a variant of the dwmac/stmmac driver an inherits all descriptions
+present in Documentation/devicetree/bindings/net/stmmac.txt.
+
+The device node has additional properties:
+
+Required properties:
+ - compatible   : Should contain "altr,socfpga-stmmac" along with
+                  "snps,dwmac" and any applicable more detailed
+                  designware version numbers documented in stmmac.txt
+ - altr,sysmgr-syscon : Should be the phandle to the system manager node that
+   encompasses the glue register, the register offset, and the register shift.
+
+Example:
+
+gmac0: ethernet@ff700000 {
+        compatible = "altr,socfpga-stmmac", "snps,dwmac-3.70a", "snps,dwmac";
+        altr,sysmgr-syscon = <&sysmgr 0x60 0>;
+        status = "disabled";
+        reg = <0xff700000 0x2000>;
+        interrupts = <0 115 4>;
+        interrupt-names = "macirq";
+        mac-address = [00 00 00 00 00 00];/* Filled in by U-Boot */
+        clocks = <&emac_0_clk>;
+        clocks-names = "stmmaceth";
+};
diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt
index 9d92d42140f2..80c1fb8bfbb8 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -10,8 +10,7 @@ Required properties:
 - interrupt-names: Should contain the interrupt names "macirq"
   "eth_wake_irq" if this interrupt is supported in the "interrupts"
   property
-- phy-mode: String, operation mode of the PHY interface.
-  Supported values are: "mii", "rmii", "gmii", "rgmii".
+- phy-mode: See ethernet.txt file in the same directory.
 - snps,reset-gpio       gpio number for phy reset.
 - snps,reset-active-low boolean flag to indicate if phy reset is active low.
 - snps,reset-delays-us  is triplet of delays
@@ -28,12 +27,14 @@ Required properties:
                                 ignored if force_thresh_dma_mode is set.
 
 Optional properties:
-- mac-address: 6 bytes, mac address
 - resets: Should contain a phandle to the STMMAC reset signal, if any
 - reset-names: Should contain the reset signal name "stmmaceth", if a
         reset phandle is given
-- max-frame-size:       Maximum Transfer Unit (IEEE defined MTU), rather
-                        than the maximum frame size.
+- max-frame-size: See ethernet.txt file in the same directory
+- clocks: If present, the first clock should be the GMAC main clock,
+  further clocks may be specified in derived bindings.
+- clocks-names: One name for each entry in the clocks property, the
+  first one should be "stmmaceth".
 
 Examples:
 
@@ -46,4 +47,6 @@ Examples:
                 mac-address = [000000000000]; /* Filled in by U-Boot */
                 max-frame-size = <3800>;
                 phy-mode = "gmii";
+                clocks = <&clock>;
+                clock-names = "stmmaceth">;
         };
diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
new file mode 100644
index 000000000000..189ae5cad8f7
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wl1251.txt
@@ -0,0 +1,39 @@
+* Texas Instruments wl1251 wireless lan controller
+
+The wl1251 chip can be connected via SPI or via SDIO. This
+document describes the binding for the SPI connected chip.
+
+Required properties:
+- compatible :        Should be "ti,wl1251"
+- reg :               Chip select address of device
+- spi-max-frequency : Maximum SPI clocking speed of device in Hz
+- interrupts :        Should contain interrupt line
+- interrupt-parent :  Should be the phandle for the interrupt controller
+                      that services interrupts for this device
+- vio-supply :        phandle to regulator providing VIO
+- ti,power-gpio :     GPIO connected to chip's PMEN pin
+
+Optional properties:
+- ti,wl1251-has-eeprom : boolean, the wl1251 has an eeprom connected, which
+                         provides configuration data (calibration, MAC, ...)
+- Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
+  for optional SPI connection related properties,
+
+Examples:
+
+&spi1 {
+        wl1251@0 {
+                compatible = "ti,wl1251";
+
+                reg = <0>;
+                spi-max-frequency = <48000000>;
+                spi-cpol;
+                spi-cpha;
+
+                interrupt-parent = <&gpio2>;
+                interrupts = <10 IRQ_TYPE_NONE>; /* gpio line 42 */
+
+                vio-supply = <&vio>;
+                ti,power-gpio = <&gpio3 23 GPIO_ACTIVE_HIGH>; /* 87 */
+        };
+};
diff --git a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
index 24cee06915c9..c300391e8d3e 100644
--- a/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
+++ b/Documentation/devicetree/bindings/pci/nvidia,tegra20-pcie.txt
@@ -42,6 +42,10 @@ Required properties:
     - 0xc2000000: prefetchable memory region
   Please refer to the standard PCI bus binding document for a more detailed
   explanation.
+- #interrupt-cells: Size representation for interrupts (must be 1)
+- interrupt-map-mask and interrupt-map: Standard PCI IRQ mapping properties
+  Please refer to the standard PCI bus binding document for a more detailed
+  explanation.
 - clocks: Must contain an entry for each entry in clock-names.
   See ../clocks/clock-bindings.txt for details.
 - clock-names: Must include the following entries:
@@ -86,6 +90,10 @@ SoC DTSI:
                               0 99 0x04>; /* MSI interrupt */
                 interrupt-names = "intr", "msi";
 
+                #interrupt-cells = <1>;
+                interrupt-map-mask = <0 0 0 0>;
+                interrupt-map = <0 0 0 0 &intc GIC_SPI 98 IRQ_TYPE_LEVEL_HIGH>;
+
                 bus-range = <0x00 0xff>;
                 #address-cells = <3>;
                 #size-cells = <2>;
diff --git a/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
new file mode 100644
index 000000000000..5f3a65a9dd88
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/apm-xgene-phy.txt
@@ -0,0 +1,79 @@
+* APM X-Gene 15Gbps Multi-purpose PHY nodes
+
+PHY nodes are defined to describe on-chip 15Gbps Multi-purpose PHY. Each
+PHY (pair of lanes) has its own node.
+
+Required properties:
+- compatible            : Shall be "apm,xgene-phy".
+- reg                   : PHY memory resource is the SDS PHY access resource.
+- #phy-cells            : Shall be 1 as it expects one argument for setting
+                          the mode of the PHY. Possible values are 0 (SATA),
+                          1 (SGMII), 2 (PCIe), 3 (USB), and 4 (XFI).
+
+Optional properties:
+- status                : Shall be "ok" if enabled or "disabled" if disabled.
+                          Default is "ok".
+- clocks                : Reference to the clock entry.
+- apm,tx-eye-tuning     : Manual control to fine tune the capture of the serial
+                          bit lines from the automatic calibrated position.
+                          Two set of 3-tuple setting for each (up to 3)
+                          supported link speed on the host. Range from 0 to
+                          127 in unit of one bit period. Default is 10.
+- apm,tx-eye-direction  : Eye tuning manual control direction. 0 means sample
+                          data earlier than the nominal sampling point. 1 means
+                          sample data later than the nominal sampling point.
+                          Two set of 3-tuple setting for each (up to 3)
+                          supported link speed on the host. Default is 0.
+- apm,tx-boost-gain     : Frequency boost AC (LSB 3-bit) and DC (2-bit)
+                          gain control. Two set of 3-tuple setting for each
+                          (up to 3) supported link speed on the host. Range is
+                          between 0 to 31 in unit of dB. Default is 3.
+- apm,tx-amplitude      : Amplitude control. Two set of 3-tuple setting for
+                          each (up to 3) supported link speed on the host.
+                          Range is between 0 to 199500 in unit of uV.
+                          Default is 199500 uV.
+- apm,tx-pre-cursor1    : 1st pre-cursor emphasis taps control. Two set of
+                          3-tuple setting for each (up to 3) supported link
+                          speed on the host. Range is 0 to 273000 in unit of
+                          uV. Default is 0.
+- apm,tx-pre-cursor2    : 2st pre-cursor emphasis taps control. Two set of
+                          3-tuple setting for each (up to 3) supported link
+                          speed on the host. Range is 0 to 127400 in unit uV.
+                          Default is 0x0.
+- apm,tx-post-cursor    : Post-cursor emphasis taps control. Two set of
+                          3-tuple setting for Gen1, Gen2, and Gen3. Range is
+                          between 0 to 0x1f in unit of 18.2mV. Default is 0xf.
+- apm,tx-speed          : Tx operating speed. One set of 3-tuple for each
+                          supported link speed on the host.
+                           0 = 1-2Gbps
+                           1 = 2-4Gbps (1st tuple default)
+                           2 = 4-8Gbps
+                           3 = 8-15Gbps (2nd tuple default)
+                           4 = 2.5-4Gbps
+                           5 = 4-5Gbps
+                           6 = 5-6Gbps
+                           7 = 6-16Gbps (3rd tuple default)
+
+NOTE: PHY override parameters are board specific setting.
+
+Example:
+                phy1: phy@1f21a000 {
+                        compatible = "apm,xgene-phy";
+                        reg = <0x0 0x1f21a000 0x0 0x100>;
+                        #phy-cells = <1>;
+                        status = "disabled";
+                };
+
+                phy2: phy@1f22a000 {
+                        compatible = "apm,xgene-phy";
+                        reg = <0x0 0x1f22a000 0x0 0x100>;
+                        #phy-cells = <1>;
+                        status = "ok";
+                };
+
+                phy3: phy@1f23a000 {
+                        compatible = "apm,xgene-phy";
+                        reg = <0x0 0x1f23a000 0x0 0x100>;
+                        #phy-cells = <1>;
+                        status = "ok";
+                };
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa1671e..b422e38946d7 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,97 @@ Required properties:
 - compatible : should be "samsung,exynos5250-dp-video-phy";
 - reg : offset and length of the Display Port PHY register set;
 - #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung S5P/EXYNOS SoC series USB PHY
+-------------------------------------------------
+
+Required properties:
+- compatible : should be one of the listed compatibles:
+        - "samsung,exynos4210-usb2-phy"
+        - "samsung,exynos4x12-usb2-phy"
+        - "samsung,exynos5250-usb2-phy"
+- reg : a list of registers used by phy driver
+        - first and obligatory is the location of phy modules registers
+- samsung,sysreg-phandle - handle to syscon used to control the system registers
+- samsung,pmureg-phandle - handle to syscon used to control PMU registers
+- #phy-cells : from the generic phy bindings, must be 1;
+- clocks and clock-names:
+        - the "phy" clock is required by the phy module, used as a gate
+        - the "ref" clock is used to get the rate of the clock provided to the
+          PHY module
+
+The first phandle argument in the PHY specifier identifies the PHY, its
+meaning is compatible dependent. For the currently supported SoCs (Exynos 4210
+and Exynos 4212) it is as follows:
+  0 - USB device ("device"),
+  1 - USB host ("host"),
+  2 - HSIC0 ("hsic0"),
+  3 - HSIC1 ("hsic1"),
+
+Exynos 4210 and Exynos 4212 use mode switching and require that mode switch
+register is supplied.
+
+Example:
+
+For Exynos 4412 (compatible with Exynos 4212):
+
+usbphy: phy@125b0000 {
+        compatible = "samsung,exynos4x12-usb2-phy";
+        reg = <0x125b0000 0x100>;
+        clocks = <&clock 305>, <&clock 2>;
+        clock-names = "phy", "ref";
+        status = "okay";
+        #phy-cells = <1>;
+        samsung,sysreg-phandle = <&sys_reg>;
+        samsung,pmureg-phandle = <&pmu_reg>;
+};
+
+Then the PHY can be used in other nodes such as:
+
+phy-consumer@12340000 {
+        phys = <&usbphy 2>;
+        phy-names = "phy";
+};
+
+Refer to DT bindings documentation of particular PHY consumer devices for more
+information about required PHYs and the way of specification.
+
+Samsung SATA PHY Controller
+---------------------------
+
+SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
+Each SATA PHY controller should have its own node.
+
+Required properties:
+- compatible        : compatible list, contains "samsung,exynos5250-sata-phy"
+- reg : offset and length of the SATA PHY register set;
+- #phy-cells : must be zero
+- clocks : must be exactly one entry
+- clock-names : must be "sata_phyctrl"
+- samsung,exynos-sataphy-i2c-phandle : a phandle to the I2C device, no arguments
+- samsung,syscon-phandle : a phandle to the PMU system controller, no arguments
+
+Example:
+        sata_phy: sata-phy@12170000 {
+                compatible = "samsung,exynos5250-sata-phy";
+                reg = <0x12170000 0x1ff>;
+                clocks = <&clock 287>;
+                clock-names = "sata_phyctrl";
+                #phy-cells = <0>;
+                samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>;
+                samsung,syscon-phandle = <&pmu_syscon>;
+        };
+
+Device-Tree bindings for sataphy i2c client driver
+--------------------------------------------------
+
+Required properties:
+compatible: Should be "samsung,exynos-sataphy-i2c"
+- reg: I2C address of the sataphy i2c device.
+
+Example:
+
+        sata_phy_i2c:sata-phy@38 {
+                compatible = "samsung,exynos-sataphy-i2c";
+                reg = <0x38>;
+        };
diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
new file mode 100644
index 000000000000..a82361b62015
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
@@ -0,0 +1,26 @@
+Allwinner sun4i USB PHY
+-----------------------
+
+Required properties:
+- compatible : should be one of "allwinner,sun4i-a10-usb-phy",
+  "allwinner,sun5i-a13-usb-phy" or "allwinner,sun7i-a20-usb-phy"
+- reg : a list of offset + length pairs
+- reg-names : "phy_ctrl", "pmu1" and for sun4i or sun7i "pmu2"
+- #phy-cells : from the generic phy bindings, must be 1
+- clocks : phandle + clock specifier for the phy clock
+- clock-names : "usb_phy"
+- resets : a list of phandle + reset specifier pairs
+- reset-names : "usb0_reset", "usb1_reset" and for sun4i or sun7i "usb2_reset"
+
+Example:
+        usbphy: phy@0x01c13400 {
+                #phy-cells = <1>;
+                compatible = "allwinner,sun4i-a10-usb-phy";
+                /* phy base regs, phy1 pmu reg, phy2 pmu reg */
+                reg = <0x01c13400 0x10 0x01c14800 0x4 0x01c1c800 0x4>;
+                reg-names = "phy_ctrl", "pmu1", "pmu2";
+                clocks = <&usb_clk 8>;
+                clock-names = "usb_phy";
+                resets = <&usb_clk 1>, <&usb_clk 2>;
+                reset-names = "usb1_reset", "usb2_reset";
+        };
diff --git a/Documentation/devicetree/bindings/phy/ti-phy.txt b/Documentation/devicetree/bindings/phy/ti-phy.txt
new file mode 100644
index 000000000000..788fb0fa3762
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/ti-phy.txt
@@ -0,0 +1,86 @@
+TI PHY: DT DOCUMENTATION FOR PHYs in TI PLATFORMs
+
+OMAP CONTROL PHY
+
+Required properties:
+ - compatible: Should be one of
+ "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
+ "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
+                        e.g. USB2_PHY on OMAP5.
+ "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
+                        e.g. USB3 PHY and SATA PHY on OMAP5.
+ "ti,control-phy-usb2-dra7" - if it has power down register like USB2 PHY on
+                        DRA7 platform.
+ "ti,control-phy-usb2-am437" - if it has power down register like USB2 PHY on
+                        AM437 platform.
+ - reg : Address and length of the register set for the device. It contains
+   the address of "otghs_control" for control-phy-otghs or "power" register
+   for other types.
+ - reg-names: should be "otghs_control" control-phy-otghs and "power" for
+   other types.
+
+omap_control_usb: omap-control-usb@4a002300 {
+        compatible = "ti,control-phy-otghs";
+        reg = <0x4a00233c 0x4>;
+        reg-names = "otghs_control";
+};
+
+OMAP USB2 PHY
+
+Required properties:
+ - compatible: Should be "ti,omap-usb2"
+ - reg : Address and length of the register set for the device.
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
+
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb2phy@4a0ad080 {
+        compatible = "ti,omap-usb2";
+        reg = <0x4a0ad080 0x58>;
+        ctrl-module = <&omap_control_usb>;
+        #phy-cells = <0>;
+};
+
+TI PIPE3 PHY
+
+Required properties:
+ - compatible: Should be "ti,phy-usb3" or "ti,phy-pipe3-sata".
+   "ti,omap-usb3" is deprecated.
+ - reg : Address and length of the register set for the device.
+ - reg-names: The names of the register addresses corresponding to the registers
+   filled in "reg".
+ - #phy-cells: determine the number of cells that should be given in the
+   phandle while referencing this phy.
+ - clocks: a list of phandles and clock-specifier pairs, one for each entry in
+   clock-names.
+ - clock-names: should include:
+   * "wkupclk" - wakeup clock.
+   * "sysclk" - system clock.
+   * "refclk" - reference clock.
+
+Optional properties:
+ - ctrl-module : phandle of the control module used by PHY driver to power on
+   the PHY.
+
+This is usually a subnode of ocp2scp to which it is connected.
+
+usb3phy@4a084400 {
+        compatible = "ti,phy-usb3";
+        reg = <0x4a084400 0x80>,
+              <0x4a084800 0x64>,
+              <0x4a084c00 0x40>;
+        reg-names = "phy_rx", "phy_tx", "pll_ctrl";
+        ctrl-module = <&omap_control_usb>;
+        #phy-cells = <0>;
+        clocks = <&usb_phy_cm_clk32k>,
+                 <&sys_clkin>,
+                 <&usb_otg_ss_refclk960m>;
+        clock-names =   "wkupclk",
+                        "sysclk",
+                        "refclk";
+};
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
index 01ef408e205f..adda2a8d1d52 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-370-pinctrl.txt
@@ -5,6 +5,7 @@ part and usage.
 
 Required properties:
 - compatible: "marvell,88f6710-pinctrl"
+- reg: register specifier of MPP registers
 
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt
new file mode 100644
index 000000000000..7de0cda4a379
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-375-pinctrl.txt
@@ -0,0 +1,82 @@
+* Marvell Armada 375 SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: "marvell,88f6720-pinctrl"
+- reg: register specifier of MPP registers
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+name          pins     functions
+================================================================================
+mpp0          0        gpio, dev(ad2), spi0(cs1), spi1(cs1)
+mpp1          1        gpio, dev(ad3), spi0(mosi), spi1(mosi)
+mpp2          2        gpio, dev(ad4), ptp(eventreq), led(c0), audio(sdi)
+mpp3          3        gpio, dev(ad5), ptp(triggen), led(p3), audio(mclk)
+mpp4          4        gpio, dev(ad6), spi0(miso), spi1(miso)
+mpp5          5        gpio, dev(ad7), spi0(cs2), spi1(cs2)
+mpp6          6        gpio, dev(ad0), led(p1), audio(rclk)
+mpp7          7        gpio, dev(ad1), ptp(clk), led(p2), audio(extclk)
+mpp8          8        gpio, dev (bootcs), spi0(cs0), spi1(cs0)
+mpp9          9        gpio, nf(wen), spi0(sck), spi1(sck)
+mpp10        10        gpio, nf(ren), dram(vttctrl), led(c1)
+mpp11        11        gpio, dev(a0), led(c2), audio(sdo)
+mpp12        12        gpio, dev(a1), audio(bclk)
+mpp13        13        gpio, dev(readyn), pcie0(rstoutn), pcie1(rstoutn)
+mpp14        14        gpio, i2c0(sda), uart1(txd)
+mpp15        15        gpio, i2c0(sck), uart1(rxd)
+mpp16        16        gpio, uart0(txd)
+mpp17        17        gpio, uart0(rxd)
+mpp18        18        gpio, tdm(intn)
+mpp19        19        gpio, tdm(rstn)
+mpp20        20        gpio, tdm(pclk)
+mpp21        21        gpio, tdm(fsync)
+mpp22        22        gpio, tdm(drx)
+mpp23        23        gpio, tdm(dtx)
+mpp24        24        gpio, led(p0), ge1(rxd0), sd(cmd), uart0(rts)
+mpp25        25        gpio, led(p2), ge1(rxd1), sd(d0), uart0(cts)
+mpp26        26        gpio, pcie0(clkreq), ge1(rxd2), sd(d2), uart1(rts)
+mpp27        27        gpio, pcie1(clkreq), ge1(rxd3), sd(d1), uart1(cts)
+mpp28        28        gpio, led(p3), ge1(txctl), sd(clk)
+mpp29        29        gpio, pcie1(clkreq), ge1(rxclk), sd(d3)
+mpp30        30        gpio, ge1(txd0), spi1(cs0)
+mpp31        31        gpio, ge1(txd1), spi1(mosi)
+mpp32        32        gpio, ge1(txd2), spi1(sck), ptp(triggen)
+mpp33        33        gpio, ge1(txd3), spi1(miso)
+mpp34        34        gpio, ge1(txclkout), spi1(sck)
+mpp35        35        gpio, ge1(rxctl), spi1(cs1), spi0(cs2)
+mpp36        36        gpio, pcie0(clkreq)
+mpp37        37        gpio, pcie0(clkreq), tdm(intn), ge(mdc)
+mpp38        38        gpio, pcie1(clkreq), ge(mdio)
+mpp39        39        gpio, ref(clkout)
+mpp40        40        gpio, uart1(txd)
+mpp41        41        gpio, uart1(rxd)
+mpp42        42        gpio, spi1(cs2), led(c0)
+mpp43        43        gpio, sata0(prsnt), dram(vttctrl)
+mpp44        44        gpio, sata0(prsnt)
+mpp45        45        gpio, spi0(cs2), pcie0(rstoutn)
+mpp46        46        gpio, led(p0), ge0(txd0), ge1(txd0)
+mpp47        47        gpio, led(p1), ge0(txd1), ge1(txd1)
+mpp48        48        gpio, led(p2), ge0(txd2), ge1(txd2)
+mpp49        49        gpio, led(p3), ge0(txd3), ge1(txd3)
+mpp50        50        gpio, led(c0), ge0(rxd0), ge1(rxd0)
+mpp51        51        gpio, led(c1), ge0(rxd1), ge1(rxd1)
+mpp52        52        gpio, led(c2), ge0(rxd2), ge1(rxd2)
+mpp53        53        gpio, pcie1(rstoutn), ge0(rxd3), ge1(rxd3)
+mpp54        54        gpio, pcie0(rstoutn), ge0(rxctl), ge1(rxctl)
+mpp55        55        gpio, ge0(rxclk), ge1(rxclk)
+mpp56        56        gpio, ge0(txclkout), ge1(txclkout)
+mpp57        57        gpio, ge0(txctl), ge1(txctl)
+mpp58        58        gpio, led(c0)
+mpp59        59        gpio, led(c1)
+mpp60        60        gpio, uart1(txd), led(c2)
+mpp61        61        gpio, i2c1(sda), uart1(rxd), spi1(cs2), led(p0)
+mpp62        62        gpio, i2c1(sck), led(p1)
+mpp63        63        gpio, ptp(triggen), led(p2)
+mpp64        64        gpio, dram(vttctrl), led(p3)
+mpp65        65        gpio, sata1(prsnt)
+mpp66        66        gpio, ptp(eventreq), spi1(cs3)
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt
new file mode 100644
index 000000000000..b17c96849fc9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-38x-pinctrl.txt
@@ -0,0 +1,80 @@
+* Marvell Armada 380/385 SoC pinctrl driver for mpp
+
+Please refer to marvell,mvebu-pinctrl.txt in this directory for common binding
+part and usage.
+
+Required properties:
+- compatible: "marvell,88f6810-pinctrl", "marvell,88f6820-pinctrl" or
+  "marvell,88f6828-pinctrl" depending on the specific variant of the
+  SoC being used.
+- reg: register specifier of MPP registers
+
+Available mpp pins/groups and functions:
+Note: brackets (x) are not part of the mpp name for marvell,function and given
+only for more detailed description in this document.
+
+name          pins     functions
+================================================================================
+mpp0          0        gpio, ua0(rxd)
+mpp1          1        gpio, ua0(txd)
+mpp2          2        gpio, i2c0(sck)
+mpp3          3        gpio, i2c0(sda)
+mpp4          4        gpio, ge(mdc), ua1(txd), ua0(rts)
+mpp5          5        gpio, ge(mdio), ua1(rxd), ua0(cts)
+mpp6          6        gpio, ge0(txclkout), ge0(crs), dev(cs3)
+mpp7          7        gpio, ge0(txd0), dev(ad9)
+mpp8          8        gpio, ge0(txd1), dev(ad10)
+mpp9          9        gpio, ge0(txd2), dev(ad11)
+mpp10         10       gpio, ge0(txd3), dev(ad12)
+mpp11         11       gpio, ge0(txctl), dev(ad13)
+mpp12         12       gpio, ge0(rxd0), pcie0(rstout), pcie1(rstout) [1], spi0(cs1), dev(ad14)
+mpp13         13       gpio, ge0(rxd1), pcie0(clkreq), pcie1(clkreq) [1], spi0(cs2), dev(ad15)
+mpp14         14       gpio, ge0(rxd2), ptp(clk), m(vtt_ctrl), spi0(cs3), dev(wen1)
+mpp15         15       gpio, ge0(rxd3), ge(mdc slave), pcie0(rstout), spi0(mosi), pcie1(rstout) [1]
+mpp16         16       gpio, ge0(rxctl), ge(mdio slave), m(decc_err), spi0(miso), pcie0(clkreq)
+mpp17         17       gpio, ge0(rxclk), ptp(clk), ua1(rxd), spi0(sck), sata1(prsnt)
+mpp18         18       gpio, ge0(rxerr), ptp(trig_gen), ua1(txd), spi0(cs0), pcie1(rstout) [1]
+mpp19         19       gpio, ge0(col), ptp(event_req), pcie0(clkreq), sata1(prsnt), ua0(cts)
+mpp20         20       gpio, ge0(txclk), ptp(clk), pcie1(rstout) [1], sata0(prsnt), ua0(rts)
+mpp21         21       gpio, spi0(cs1), ge1(rxd0), sata0(prsnt), sd0(cmd), dev(bootcs)
+mpp22         22       gpio, spi0(mosi), dev(ad0)
+mpp23         23       gpio, spi0(sck), dev(ad2)
+mpp24         24       gpio, spi0(miso), ua0(cts), ua1(rxd), sd0(d4), dev(ready)
+mpp25         25       gpio, spi0(cs0), ua0(rts), ua1(txd), sd0(d5), dev(cs0)
+mpp26         26       gpio, spi0(cs2), i2c1(sck), sd0(d6), dev(cs1)
+mpp27         27       gpio, spi0(cs3), ge1(txclkout), i2c1(sda), sd0(d7), dev(cs2)
+mpp28         28       gpio, ge1(txd0), sd0(clk), dev(ad5)
+mpp29         29       gpio, ge1(txd1), dev(ale0)
+mpp30         30       gpio, ge1(txd2), dev(oen)
+mpp31         31       gpio, ge1(txd3), dev(ale1)
+mpp32         32       gpio, ge1(txctl), dev(wen0)
+mpp33         33       gpio, m(decc_err), dev(ad3)
+mpp34         34       gpio, dev(ad1)
+mpp35         35       gpio, ref(clk_out1), dev(a1)
+mpp36         36       gpio, ptp(trig_gen), dev(a0)
+mpp37         37       gpio, ptp(clk), ge1(rxclk), sd0(d3), dev(ad8)
+mpp38         38       gpio, ptp(event_req), ge1(rxd1), ref(clk_out0), sd0(d0), dev(ad4)
+mpp39         39       gpio, i2c1(sck), ge1(rxd2), ua0(cts), sd0(d1), dev(a2)
+mpp40         40       gpio, i2c1(sda), ge1(rxd3), ua0(rts), sd0(d2), dev(ad6)
+mpp41         41       gpio, ua1(rxd), ge1(rxctl), ua0(cts), spi1(cs3), dev(burst/last)
+mpp42         42       gpio, ua1(txd), ua0(rts), dev(ad7)
+mpp43         43       gpio, pcie0(clkreq), m(vtt_ctrl), m(decc_err), pcie0(rstout), dev(clkout)
+mpp44         44       gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], sata3(prsnt) [3], pcie0(rstout)
+mpp45         45       gpio, ref(clk_out0), pcie0(rstout), pcie1(rstout) [1], pcie2(rstout), pcie3(rstout)
+mpp46         46       gpio, ref(clk_out1), pcie0(rstout), pcie1(rstout) [1], pcie2(rstout), pcie3(rstout)
+mpp47         47       gpio, sata0(prsnt), sata1(prsnt), sata2(prsnt) [2], spi1(cs2), sata3(prsnt) [2]
+mpp48         48       gpio, sata0(prsnt), m(vtt_ctrl), tdm2c(pclk), audio(mclk), sd0(d4)
+mpp49         49       gpio, sata2(prsnt) [2], sata3(prsnt) [2], tdm2c(fsync), audio(lrclk), sd0(d5)
+mpp50         50       gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(drx), audio(extclk), sd0(cmd)
+mpp51         51       gpio, tdm2c(dtx), audio(sdo), m(decc_err)
+mpp52         52       gpio, pcie0(rstout), pcie1(rstout) [1], tdm2c(intn), audio(sdi), sd0(d6)
+mpp53         53       gpio, sata1(prsnt), sata0(prsnt), tdm2c(rstn), audio(bclk), sd0(d7)
+mpp54         54       gpio, sata0(prsnt), sata1(prsnt), pcie0(rstout), pcie1(rstout) [1], sd0(d3)
+mpp55         55       gpio, ua1(cts), ge(mdio), pcie1(clkreq) [1], spi1(cs1), sd0(d0)
+mpp56         56       gpio, ua1(rts), ge(mdc), m(decc_err), spi1(mosi)
+mpp57         57       gpio, spi1(sck), sd0(clk)
+mpp58         58       gpio, pcie1(clkreq) [1], i2c1(sck), pcie2(clkreq), spi1(miso), sd0(d1)
+mpp59         59       gpio, pcie0(rstout), i2c1(sda), pcie1(rstout) [1], spi1(cs0), sd0(d2)
+
+[1]: only available on 88F6820 and 88F6828
+[2]: only available on 88F6828
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
index bfa0a2e5e0cb..373dbccd7ab0 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,armada-xp-pinctrl.txt
@@ -6,6 +6,7 @@ part and usage.
 Required properties:
 - compatible: "marvell,mv78230-pinctrl", "marvell,mv78260-pinctrl",
               "marvell,mv78460-pinctrl"
+- reg: register specifier of MPP registers
 
 This driver supports all Armada XP variants, i.e. mv78230, mv78260, and mv78460.
 
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
index 50ec3512a292..cf52477cc7ee 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,dove-pinctrl.txt
@@ -6,6 +6,7 @@ part and usage.
 Required properties:
 - compatible: "marvell,dove-pinctrl"
 - clocks: (optional) phandle of pdma clock
+- reg: register specifiers of MPP, MPP4, and PMU MPP registers
 
 Available mpp pins/groups and functions:
 Note: brackets (x) are not part of the mpp name for marvell,function and given
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
index 95daf6335c37..730444a9a4de 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,kirkwood-pinctrl.txt
@@ -8,6 +8,7 @@ Required properties:
               "marvell,88f6190-pinctrl", "marvell,88f6192-pinctrl",
               "marvell,88f6281-pinctrl", "marvell,88f6282-pinctrl"
               "marvell,98dx4122-pinctrl"
+- reg: register specifier of MPP registers
 
 This driver supports all kirkwood variants, i.e. 88f6180, 88f619x, and 88f628x.
 It also support the 88f6281-based variant in the 98dx412x Bobcat SoCs.
diff --git a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
index 0a26c3aa4e6d..0c09f4eb2af0 100644
--- a/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/marvell,mvebu-pinctrl.txt
@@ -37,7 +37,7 @@ uart1: serial@12100 {
 
 pinctrl: pinctrl@d0200 {
         compatible = "marvell,dove-pinctrl";
-        reg = <0xd0200 0x20>;
+        reg = <0xd0200 0x14>, <0xd0440 0x04>, <0xd802c 0x08>;
 
         pmx_uart1_sw: pmx-uart1-sw {
                 marvell,pins = "mpp_uart1";
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
index bc0dfdfdb148..66dcaa9efd74 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-single.txt
@@ -63,6 +63,13 @@ Optional properties:
                 /* input, enable bits, disable bits, mask */
                 pinctrl-single,input-schmitt-enable = <0x30 0x40 0 0x70>;
 
+- pinctrl-single,low-power-mode : array of value that are used to configure
+  low power mode of this pin. For some silicons, the low power mode will
+  control the output of the pin when the pad including the pin enter low
+  power mode.
+                /* low power mode value, mask */
+                pinctrl-single,low-power-mode = <0x288 0x388>;
+
 - pinctrl-single,gpio-range : list of value that are used to configure a GPIO
   range. They're value of subnode phandle, pin base in pinctrl device, pin
   number in this range, GPIO function value of this GPIO range.
diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
index 05bf82a07dfd..4bd5be0e5e7d 100644
--- a/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
+++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-st.txt
@@ -11,18 +11,68 @@ Pull Up (PU) are driven by the related PIO block.
 ST pinctrl driver controls PIO multiplexing block and also interacts with
 gpio driver to configure a pin.
 
-Required properties: (PIO multiplexing block)
+GPIO bank can have one of the two possible types of interrupt-wirings.
+
+First type is via irqmux, single interrupt is used by multiple gpio banks. This
+reduces number of overall interrupts numbers required. All these banks belong to
+a single pincontroller.
+                  _________
+                 |         |----> [gpio-bank (n)    ]
+                 |         |----> [gpio-bank (n + 1)]
+        [irqN]-- | irq-mux |----> [gpio-bank (n + 2)]
+                 |         |----> [gpio-bank (...  )]
+                 |_________|----> [gpio-bank (n + 7)]
+
+Second type has a dedicated interrupt per gpio bank.
+
+        [irqN]----> [gpio-bank (n)]
+
+
+Pin controller node:
+Required properties:
 - compatible    : should be "st,<SOC>-<pio-block>-pinctrl"
         like st,stih415-sbc-pinctrl, st,stih415-front-pinctrl and so on.
-- gpio-controller : Indicates this device is a GPIO controller
-- #gpio-cells     : Should be one. The first cell is the pin number.
+- st,syscfg             : Should be a phandle of the syscfg node.
 - st,retime-pin-mask    : Should be mask to specify which pins can be retimed.
         If the property is not present, it is assumed that all the pins in the
         bank are capable of retiming. Retiming is mainly used to improve the
         IO timing margins of external synchronous interfaces.
-- st,bank-name          : Should be a name string for this bank as
-                        specified in datasheet.
-- st,syscfg             : Should be a phandle of the syscfg node.
+- ranges : defines mapping between pin controller node (parent) to gpio-bank
+  node (children).
+
+Optional properties:
+- interrupts    : Interrupt number of the irqmux. If the interrupt is shared
+  with other gpio banks via irqmux.
+  a irqline and gpio banks.
+- reg           : irqmux memory resource. If irqmux is present.
+- reg-names     : irqmux resource should be named as "irqmux".
+
+GPIO controller/bank node.
+Required properties:
+- gpio-controller : Indicates this device is a GPIO controller
+- #gpio-cells     : Should be one. The first cell is the pin number.
+- st,bank-name    : Should be a name string for this bank as specified in
+  datasheet.
+
+Optional properties:
+- interrupts    : Interrupt number for this gpio bank. If there is a dedicated
+  interrupt wired up for this gpio bank.
+
+- interrupt-controller : Indicates this device is a interrupt controller. GPIO
+  bank can be an interrupt controller iff one of the interrupt type either via
+irqmux or a dedicated interrupt per bank is specified.
+
+- #interrupt-cells: the value of this property should be 2.
+     - First Cell: represents the external gpio interrupt number local to the
+       gpio interrupt space of the controller.
+     - Second Cell: flags to identify the type of the interrupt
+       - 1 = rising edge triggered
+       - 2 = falling edge triggered
+       - 3 = rising and falling edge triggered
+       - 4 = high level triggered
+       - 8 = low level triggered
+for related macros look in:
+include/dt-bindings/interrupt-controller/irq.h
 
 Example:
         pin-controller-sbc {
@@ -30,10 +80,17 @@ Example:
                 #size-cells     = <1>;
                 compatible      = "st,stih415-sbc-pinctrl";
                 st,syscfg       = <&syscfg_sbc>;
+                reg             = <0xfe61f080 0x4>;
+                reg-names       = "irqmux";
+                interrupts      = <GIC_SPI 180 IRQ_TYPE_LEVEL_HIGH>;
+                interrupts-names = "irqmux";
                 ranges          = <0 0xfe610000 0x5000>;
+
                 PIO0: gpio@fe610000 {
                         gpio-controller;
                         #gpio-cells     = <1>;
+                        interrupt-controller;
+                        #interrupt-cells = <2>;
                         reg             = <0 0x100>;
                         st,bank-name    = "PIO0";
                 };
@@ -105,6 +162,10 @@ pin-controller {
 
 sdhci0:sdhci@fe810000{
         ...
+        interrupt-parent = <&PIO3>;
+        #interrupt-cells = <2>;
+        interrupts = <3 IRQ_TYPE_LEVEL_HIGH>; /* Interrupt line via PIO3-3 */
+        interrupts-names = "card-detect";
         pinctrl-names = "default";
         pinctrl-0       = <&pinctrl_mmc>;
 };
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
index 4c352be5dd61..9fb89e3f61ea 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8974-pinctrl.txt
@@ -1,7 +1,7 @@
 Qualcomm MSM8974 TLMM block
 
 Required properties:
-- compatible: "qcom,msm8x74-pinctrl"
+- compatible: "qcom,msm8974-pinctrl"
 - reg: Should be the base address and length of the TLMM block.
 - interrupts: Should be the parent IRQ of the TLMM block.
 - interrupt-controller: Marks the device node as an interrupt controller.
@@ -42,14 +42,14 @@ Non-empty subnodes must specify the 'pins' property.
 Note that not all properties are valid for all pins.
 
 
-Valid values for qcom,pins are:
+Valid values for pins are:
   gpio0-gpio145
     Supports mux, bias and drive-strength
 
   sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data
     Supports bias and drive-strength
 
-Valid values for qcom,function are:
+Valid values for function are:
   blsp_i2c2, blsp_i2c6, blsp_i2c11, blsp_spi1, blsp_uart2, blsp_uart8, slimbus
 
   (Note that this is not yet the complete list of functions)
@@ -73,18 +73,18 @@ Example:
 
                 uart2_default: uart2_default {
                         mux {
-                                qcom,pins = "gpio4", "gpio5";
-                                qcom,function = "blsp_uart2";
+                                pins = "gpio4", "gpio5";
+                                function = "blsp_uart2";
                         };
 
                         tx {
-                                qcom,pins = "gpio4";
+                                pins = "gpio4";
                                 drive-strength = <4>;
                                 bias-disable;
                         };
 
                         rx {
-                                qcom,pins = "gpio5";
+                                pins = "gpio5";
                                 drive-strength = <2>;
                                 bias-pull-up;
                         };
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
index 257677de3e6b..2b32783ba821 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt
@@ -16,6 +16,7 @@ Required Properties:
   - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller.
   - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller.
   - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller.
+  - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller.
   - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller.
 
 - reg: Base address of the pin controller hardware module and length of
diff --git a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
index 0347d8350d94..af25e77c0e0c 100644
--- a/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
+++ b/Documentation/devicetree/bindings/power_supply/qnap-poweroff.txt
@@ -6,8 +6,11 @@ Orion5x SoCs. Sending the character 'A', at 19200 baud, tells the
 microcontroller to turn the power off. This driver adds a handler to
 pm_power_off which is called to turn the power off.
 
+Synology NAS devices use a similar scheme, but a different baud rate,
+9600, and a different character, '1'.
+
 Required Properties:
-- compatible: Should be "qnap,power-off"
+- compatible: Should be "qnap,power-off" or "synology,power-off"
 
 - reg: Address and length of the register set for UART1
 - clocks: tclk clock
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt
new file mode 100644
index 000000000000..c41b2187eaa8
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/l2cache.txt
@@ -0,0 +1,23 @@
+Freescale L2 Cache Controller
+
+L2 cache is present in Freescale's QorIQ and QorIQ Qonverge platforms.
+The cache bindings explained below are ePAPR compliant
+
+Required Properties:
+
+- compatible    : Should include "fsl,chip-l2-cache-controller" and "cache"
+                  where chip is the processor (bsc9132, npc8572 etc.)
+- reg           : Address and size of L2 cache controller registers
+- cache-size    : Size of the entire L2 cache
+- interrupts    : Error interrupt of L2 controller
+- cache-line-size : Size of L2 cache lines
+
+Example:
+
+        L2: l2-cache-controller@20000 {
+                compatible = "fsl,bsc9132-l2-cache-controller", "cache";
+                reg = <0x20000 0x1000>;
+                cache-line-size = <32>; // 32 bytes
+                cache-size = <0x40000>; // L2,256K
+                interrupts = <16 2 1 0>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt
new file mode 100644
index 000000000000..f87856faf1ab
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mem-ctrlr.txt
@@ -0,0 +1,27 @@
+Freescale DDR memory controller
+
+Properties:
+
+- compatible    : Should include "fsl,chip-memory-controller" where
+                  chip is the processor (bsc9132, mpc8572 etc.), or
+                  "fsl,qoriq-memory-controller".
+- reg           : Address and size of DDR controller registers
+- interrupts    : Error interrupt of DDR controller
+
+Example 1:
+
+        memory-controller@2000 {
+                compatible = "fsl,bsc9132-memory-controller";
+                reg = <0x2000 0x1000>;
+                interrupts = <16 2 1 8>;
+        };
+
+
+Example 2:
+
+        ddr1: memory-controller@8000 {
+                compatible = "fsl,qoriq-memory-controller-v4.7",
+                                "fsl,qoriq-memory-controller";
+                reg = <0x8000 0x1000>;
+                interrupts = <16 2 1 23>;
+        };
diff --git a/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt b/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt
new file mode 100644
index 000000000000..a183db48f910
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/cirrus,clps711x-pwm.txt
@@ -0,0 +1,16 @@
+* Cirris Logic CLPS711X PWM controller
+
+Required properties:
+- compatible: Shall contain "cirrus,clps711x-pwm".
+- reg: Physical base address and length of the controller's registers.
+- clocks: phandle + clock specifier pair of the PWM reference clock.
+- #pwm-cells: Should be 1. The cell specifies the index of the channel.
+
+Example:
+        pwm: pwm@80000400 {
+                compatible = "cirrus,ep7312-pwm",
+                             "cirrus,clps711x-pwm";
+                reg = <0x80000400 0x4>;
+                clocks = <&clks 8>;
+                #pwm-cells = <1>;
+        };
diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
new file mode 100644
index 000000000000..0bda229a6171
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
@@ -0,0 +1,35 @@
+Freescale FlexTimer Module (FTM) PWM controller
+
+Required properties:
+- compatible: Should be "fsl,vf610-ftm-pwm".
+- reg: Physical base address and length of the controller's registers
+- #pwm-cells: Should be 3. See pwm.txt in this directory for a description of
+  the cells format.
+- clock-names: Should include the following module clock source entries:
+    "ftm_sys" (module clock, also can be used as counter clock),
+    "ftm_ext" (external counter clock),
+    "ftm_fix" (fixed counter clock),
+    "ftm_cnt_clk_en" (external and fixed counter clock enable/disable).
+- clocks: Must contain a phandle and clock specifier for each entry in
+  clock-names, please see clock/clock-bindings.txt for details of the property
+  values.
+- pinctrl-names: Must contain a "default" entry.
+- pinctrl-NNN: One property must exist for each entry in pinctrl-names.
+  See pinctrl/pinctrl-bindings.txt for details of the property values.
+
+
+Example:
+
+pwm0: pwm@40038000 {
+                compatible = "fsl,vf610-ftm-pwm";
+                reg = <0x40038000 0x1000>;
+                #pwm-cells = <3>;
+                clock-names = "ftm_sys", "ftm_ext",
+                                "ftm_fix", "ftm_cnt_clk_en";
+                clocks = <&clks VF610_CLK_FTM0>,
+                        <&clks VF610_CLK_FTM0_EXT_SEL>,
+                        <&clks VF610_CLK_FTM0_FIX_SEL>,
+                        <&clks VF610_CLK_FTM0_EXT_FIX_EN>;
+                pinctrl-names = "default";
+                pinctrl-0 = <&pinctrl_pwm0_1>;
+};
diff --git a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
index 63c659800c03..e5cac1e0ca8a 100644
--- a/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/gpio-regulator.txt
@@ -8,8 +8,12 @@ Required properties:
 Optional properties:
 - enable-gpio           : GPIO to use to enable/disable the regulator.
 - gpios                 : GPIO group used to control voltage.
+- gpios-states          : gpios pin's initial states array. 0: LOW, 1: HIGH.
+                          defualt is LOW if nothing is specified.
 - startup-delay-us      : Startup time in microseconds.
 - enable-active-high    : Polarity of GPIO is active high (default is low).
+- regulator-type        : Specifies what is being regulated, must be either
+                          "voltage" or "current", defaults to current.
 
 Any property defined as part of the core regulator binding defined in
 regulator.txt can also be used.
diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.txt b/Documentation/devicetree/bindings/regulator/pfuze100.txt
index fc989b2e8057..34ef5d16d0f1 100644
--- a/Documentation/devicetree/bindings/regulator/pfuze100.txt
+++ b/Documentation/devicetree/bindings/regulator/pfuze100.txt
@@ -1,7 +1,7 @@
 PFUZE100 family of regulators
 
 Required properties:
-- compatible: "fsl,pfuze100"
+- compatible: "fsl,pfuze100" or "fsl,pfuze200"
 - reg: I2C slave address
 
 Required child node:
@@ -10,11 +10,14 @@ Required child node:
   Documentation/devicetree/bindings/regulator/regulator.txt.
 
   The valid names for regulators are:
+  --PFUZE100
   sw1ab,sw1c,sw2,sw3a,sw3b,sw4,swbst,vsnvs,vrefddr,vgen1~vgen6
+  --PFUZE200
+  sw1ab,sw2,sw3a,sw3b,swbst,vsnvs,vrefddr,vgen1~vgen6
 
 Each regulator is defined using the standard binding for regulators.
 
-Example:
+Example 1: PFUZE100
 
         pmic: pfuze100@08 {
                 compatible = "fsl,pfuze100";
@@ -113,3 +116,92 @@ Example:
                         };
                 };
         };
+
+
+Example 2: PFUZE200
+
+        pmic: pfuze200@08 {
+                compatible = "fsl,pfuze200";
+                reg = <0x08>;
+
+                regulators {
+                        sw1a_reg: sw1ab {
+                                regulator-min-microvolt = <300000>;
+                                regulator-max-microvolt = <1875000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                                regulator-ramp-delay = <6250>;
+                        };
+
+                        sw2_reg: sw2 {
+                                regulator-min-microvolt = <800000>;
+                                regulator-max-microvolt = <3300000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        sw3a_reg: sw3a {
+                                regulator-min-microvolt = <400000>;
+                                regulator-max-microvolt = <1975000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        sw3b_reg: sw3b {
+                                regulator-min-microvolt = <400000>;
+                                regulator-max-microvolt = <1975000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        swbst_reg: swbst {
+                                regulator-min-microvolt = <5000000>;
+                                regulator-max-microvolt = <5150000>;
+                        };
+
+                        snvs_reg: vsnvs {
+                                regulator-min-microvolt = <1000000>;
+                                regulator-max-microvolt = <3000000>;
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        vref_reg: vrefddr {
+                                regulator-boot-on;
+                                regulator-always-on;
+                        };
+
+                        vgen1_reg: vgen1 {
+                                regulator-min-microvolt = <800000>;
+                                regulator-max-microvolt = <1550000>;
+                        };
+
+                        vgen2_reg: vgen2 {
+                                regulator-min-microvolt = <800000>;
+                                regulator-max-microvolt = <1550000>;
+                        };
+
+                        vgen3_reg: vgen3 {
+                                regulator-min-microvolt = <1800000>;
+                                regulator-max-microvolt = <3300000>;
+                        };
+
+                        vgen4_reg: vgen4 {
+                                regulator-min-microvolt = <1800000>;
+                                regulator-max-microvolt = <3300000>;
+                                regulator-always-on;
+                        };
+
+                        vgen5_reg: vgen5 {
+                                regulator-min-microvolt = <1800000>;
+                                regulator-max-microvolt = <3300000>;
+                                regulator-always-on;
+                        };
+
+                        vgen6_reg: vgen6 {
+                                regulator-min-microvolt = <1800000>;
+                                regulator-max-microvolt = <3300000>;
+                                regulator-always-on;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
index fc6b38f035bd..d290988ed975 100644
--- a/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/s5m8767-regulator.txt
@@ -69,13 +69,16 @@ sub-node should be of the format as listed below.
                 };
         };
 The above regulator entries are defined in regulator bindings documentation
-except op_mode description.
+except these properties:
         - op_mode: describes the different operating modes of the LDO's with
                 power mode change in SOC. The different possible values are,
                 0 - always off mode
                 1 - on in normal mode
                 2 - low power mode
                 3 - suspend mode
+        - s5m8767,pmic-ext-control-gpios: (optional) GPIO specifier for one
+                GPIO controlling this regulator (enable/disable); This is
+                valid only for buck9.
 
 The following are the names of the regulators that the s5m8767 pmic block
 supports. Note: The 'n' in LDOn and BUCKn represents the LDO or BUCK number
@@ -148,5 +151,13 @@ Example:
                                 regulator-always-on;
                                 regulator-boot-on;
                         };
+
+                        vemmc_reg: BUCK9 {
+                                regulator-name = "VMEM_VDD_2.8V";
+                                regulator-min-microvolt = <2800000>;
+                                regulator-max-microvolt = <2800000>;
+                                op_mode = <3>; /* Standby Mode */
+                                s5m8767,pmic-ext-control-gpios = <&gpk0 2 0>;
+                        };
                 };
         };
diff --git a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
index 2e57a33e9029..c58db75f959e 100644
--- a/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/ti-abb-regulator.txt
@@ -4,10 +4,14 @@ Required Properties:
 - compatible: Should be one of:
   - "ti,abb-v1" for older SoCs like OMAP3
   - "ti,abb-v2" for newer SoCs like OMAP4, OMAP5
+  - "ti,abb-v3" for a generic definition where setup and control registers are
+     provided (example: DRA7)
 - reg: Address and length of the register set for the device. It contains
   the information of registers in the same order as described by reg-names
 - reg-names: Should contain the reg names
-  - "base-address"      - contains base address of ABB module
+  - "base-address"      - contains base address of ABB module (ti,abb-v1,ti,abb-v2)
+  - "control-address"   - contains control register address of ABB module (ti,abb-v3)
+  - "setup-address"     - contains setup register address of ABB module (ti,abb-v3)
   - "int-address"       - contains address of interrupt register for ABB module
   (also see Optional properties)
 - #address-cell: should be 0
diff --git a/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
new file mode 100644
index 000000000000..3da0ebdba8d9
--- /dev/null
+++ b/Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt
@@ -0,0 +1,133 @@
+*** Reserved memory regions ***
+
+Reserved memory is specified as a node under the /reserved-memory node.
+The operating system shall exclude reserved memory from normal usage
+one can create child nodes describing particular reserved (excluded from
+normal use) memory regions. Such memory regions are usually designed for
+the special usage by various device drivers.
+
+Parameters for each memory region can be encoded into the device tree
+with the following nodes:
+
+/reserved-memory node
+---------------------
+#address-cells, #size-cells (required) - standard definition
+    - Should use the same values as the root node
+ranges (required) - standard definition
+    - Should be empty
+
+/reserved-memory/ child nodes
+-----------------------------
+Each child of the reserved-memory node specifies one or more regions of
+reserved memory. Each child node may either use a 'reg' property to
+specify a specific range of reserved memory, or a 'size' property with
+optional constraints to request a dynamically allocated block of memory.
+
+Following the generic-names recommended practice, node names should
+reflect the purpose of the node (ie. "framebuffer" or "dma-pool"). Unit
+address (@<address>) should be appended to the name if the node is a
+static allocation.
+
+Properties:
+Requires either a) or b) below.
+a) static allocation
+   reg (required) - standard definition
+b) dynamic allocation
+   size (required) - length based on parent's #size-cells
+                   - Size in bytes of memory to reserve.
+   alignment (optional) - length based on parent's #size-cells
+                        - Address boundary for alignment of allocation.
+   alloc-ranges (optional) - prop-encoded-array (address, length pairs).
+                           - Specifies regions of memory that are
+                             acceptable to allocate from.
+
+If both reg and size are present, then the reg property takes precedence
+and size is ignored.
+
+Additional properties:
+compatible (optional) - standard definition
+    - may contain the following strings:
+        - shared-dma-pool: This indicates a region of memory meant to be
+          used as a shared pool of DMA buffers for a set of devices. It can
+          be used by an operating system to instanciate the necessary pool
+          management subsystem if necessary.
+        - vendor specific string in the form <vendor>,[<device>-]<usage>
+no-map (optional) - empty property
+    - Indicates the operating system must not create a virtual mapping
+      of the region as part of its standard mapping of system memory,
+      nor permit speculative access to it under any circumstances other
+      than under the control of the device driver using the region.
+reusable (optional) - empty property
+    - The operating system can use the memory in this region with the
+      limitation that the device driver(s) owning the region need to be
+      able to reclaim it back. Typically that means that the operating
+      system can use that region to store volatile or cached data that
+      can be otherwise regenerated or migrated elsewhere.
+
+Linux implementation note:
+- If a "linux,cma-default" property is present, then Linux will use the
+  region for the default pool of the contiguous memory allocator.
+
+Device node references to reserved memory
+-----------------------------------------
+Regions in the /reserved-memory node may be referenced by other device
+nodes by adding a memory-region property to the device node.
+
+memory-region (optional) - phandle, specifier pairs to children of /reserved-memory
+
+Example
+-------
+This example defines 3 contiguous regions are defined for Linux kernel:
+one default of all device drivers (named linux,cma@72000000 and 64MiB in size),
+one dedicated to the framebuffer device (named framebuffer@78000000, 8MiB), and
+one for multimedia processing (named multimedia-memory@77000000, 64MiB).
+
+/ {
+        #address-cells = <1>;
+        #size-cells = <1>;
+
+        memory {
+                reg = <0x40000000 0x40000000>;
+        };
+
+        reserved-memory {
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ranges;
+
+                /* global autoconfigured region for contiguous allocations */
+                linux,cma {
+                        compatible = "shared-dma-pool";
+                        reusable;
+                        size = <0x4000000>;
+                        alignment = <0x2000>;
+                        linux,cma-default;
+                };
+
+                display_reserved: framebuffer@78000000 {
+                        reg = <0x78000000 0x800000>;
+                };
+
+                multimedia_reserved: multimedia@77000000 {
+                        compatible = "acme,multimedia-memory";
+                        reg = <0x77000000 0x4000000>;
+                };
+        };
+
+        /* ... */
+
+        fb0: video@12300000 {
+                memory-region = <&display_reserved>;
+                /* ... */
+        };
+
+        scaler: scaler@12500000 {
+                memory-region = <&multimedia_reserved>;
+                /* ... */
+        };
+
+        codec: codec@12600000 {
+                memory-region = <&multimedia_reserved>;
+                /* ... */
+        };
+};
diff --git a/Documentation/devicetree/bindings/reset/sirf,rstc.txt b/Documentation/devicetree/bindings/reset/sirf,rstc.txt
new file mode 100644
index 000000000000..0505de742d30
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/sirf,rstc.txt
@@ -0,0 +1,42 @@
+CSR SiRFSoC Reset Controller
+======================================
+
+Please also refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "sirf,prima2-rstc" or "sirf,marco-rstc"
+- reg: should be register base and length as documented in the
+  datasheet
+- #reset-cells: 1, see below
+
+example:
+
+rstc: reset-controller@88010000 {
+        compatible = "sirf,prima2-rstc";
+        reg = <0x88010000 0x1000>;
+        #reset-cells = <1>;
+};
+
+Specifying reset lines connected to IP modules
+==============================================
+
+The reset controller(rstc) manages various reset sources. This module provides
+reset signals for most blocks in system. Those device nodes should specify the
+reset line on the rstc in their resets property, containing a phandle to the
+rstc device node and a RESET_INDEX specifying which module to reset, as described
+in reset.txt.
+
+For SiRFSoC, RESET_INDEX is just reset_bit defined in SW_RST0 and SW_RST1 registers.
+For modules whose rest_bit is in SW_RST0, its RESET_INDEX is 0~31. For modules whose
+rest_bit is in SW_RST1, its RESET_INDEX is 32~63.
+
+example:
+
+vpp@90020000 {
+        compatible = "sirf,prima2-vpp";
+        reg = <0x90020000 0x10000>;
+        interrupts = <31>;
+        clocks = <&clks 35>;
+        resets = <&rstc 6>;
+};
diff --git a/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
new file mode 100644
index 000000000000..5ab26b7e9d35
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
@@ -0,0 +1,47 @@
+STMicroelectronics STi family Sysconfig Peripheral Powerdown Reset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"powerdown" control bits found in the STi family SoC system configuration
+registers. These have been grouped together into a single reset controller
+device for convenience.
+
+The actual action taken when powerdown is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-powerdown"
+        ex: "st,stih415-powerdown", "st,stih416-powerdown"
+- #reset-cells: 1, see below
+
+example:
+
+        powerdown: powerdown-controller {
+                #reset-cells = <1>;
+                compatible = "st,stih415-powerdown";
+        };
+
+
+Specifying powerdown control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the powerdown device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+        usb1: usb@fe200000 {
+                resets  = <&powerdown STIH41X_USB1_POWERDOWN>;
+        };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/Documentation/devicetree/bindings/reset/st,sti-softreset.txt b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
new file mode 100644
index 000000000000..a8d3d3c25ca2
--- /dev/null
+++ b/Documentation/devicetree/bindings/reset/st,sti-softreset.txt
@@ -0,0 +1,46 @@
+STMicroelectronics STi family Sysconfig Peripheral SoftReset Controller
+=============================================================================
+
+This binding describes a reset controller device that is used to enable and
+disable on-chip peripheral controllers such as USB and SATA, using
+"softreset" control bits found in the STi family SoC system configuration
+registers.
+
+The actual action taken when softreset is asserted is hardware dependent.
+However, when asserted it may not be possible to access the hardware's
+registers and after an assert/deassert sequence the hardware's previous state
+may no longer be valid.
+
+Please refer to reset.txt in this directory for common reset
+controller binding usage.
+
+Required properties:
+- compatible: Should be "st,<chip>-softreset" example:
+        "st,stih415-softreset" or "st,stih416-softreset";
+- #reset-cells: 1, see below
+
+example:
+
+        softreset: softreset-controller {
+                #reset-cells = <1>;
+                compatible = "st,stih415-softreset";
+        };
+
+
+Specifying softreset control of devices
+=======================================
+
+Device nodes should specify the reset channel required in their "resets"
+property, containing a phandle to the softreset device node and an
+index specifying which channel to use, as described in reset.txt
+
+example:
+
+        ethernet0{
+                resets                  = <&softreset STIH415_ETH0_SOFTRESET>;
+        };
+
+Macro definitions for the supported reset channels can be found in:
+
+include/dt-bindings/reset-controller/stih415-resets.h
+include/dt-bindings/reset-controller/stih416-resets.h
diff --git a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt
index 7cb9dbf34878..6983aad376c3 100644
--- a/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt
+++ b/Documentation/devicetree/bindings/rtc/sunxi-rtc.txt
@@ -3,7 +3,7 @@
 RTC controller for the Allwinner A10/A20
 
 Required properties:
-- compatible : Should be "allwinner,sun4i-rtc" or "allwinner,sun7i-a20-rtc"
+- compatible : Should be "allwinner,sun4i-a10-rtc" or "allwinner,sun7i-a20-rtc"
 - reg: physical base address of the controller and length of memory mapped
   region.
 - interrupts: IRQ line for the RTC.
@@ -11,7 +11,7 @@ Required properties:
 Example:
 
 rtc: rtc@01c20d00 {
-        compatible = "allwinner,sun4i-rtc";
+        compatible = "allwinner,sun4i-a10-rtc";
         reg = <0x01c20d00 0x20>;
         interrupts = <24>;
 };
diff --git a/Documentation/devicetree/bindings/serial/atmel-usart.txt b/Documentation/devicetree/bindings/serial/atmel-usart.txt
index 9c5d19ac935c..17c1042b2df8 100644
--- a/Documentation/devicetree/bindings/serial/atmel-usart.txt
+++ b/Documentation/devicetree/bindings/serial/atmel-usart.txt
@@ -13,6 +13,8 @@ Required properties:
 Optional properties:
 - atmel,use-dma-rx: use of PDC or DMA for receiving data
 - atmel,use-dma-tx: use of PDC or DMA for transmitting data
+- rts-gpios: specify a GPIO for RTS line. It will use specified PIO instead of the peripheral
+  function pin for the USART RTS feature. If unsure, don't specify this property.
 - add dma bindings for dma transfer:
         - dmas: DMA specifier, consisting of a phandle to DMA controller node,
                 memory peripheral interface and USART DMA channel ID, FIFO configuration.
@@ -33,6 +35,7 @@ Example:
                 clock-names = "usart";
                 atmel,use-dma-rx;
                 atmel,use-dma-tx;
+                rts-gpios = <&pioD 15 0>;
         };
 
 - use DMA:
diff --git a/Documentation/devicetree/bindings/serial/efm32-uart.txt b/Documentation/devicetree/bindings/serial/efm32-uart.txt
index 8e080b893b49..1984bdfbd545 100644
--- a/Documentation/devicetree/bindings/serial/efm32-uart.txt
+++ b/Documentation/devicetree/bindings/serial/efm32-uart.txt
@@ -6,7 +6,7 @@ Required properties:
 - interrupts : Should contain uart interrupt
 
 Optional properties:
-- location : Decides the location of the USART I/O pins.
+- efm32,location : Decides the location of the USART I/O pins.
   Allowed range : [0 .. 5]
   Default: 0
 
@@ -16,5 +16,5 @@ uart@0x4000c400 {
         compatible = "efm32,uart";
         reg = <0x4000c400 0x400>;
         interrupts = <15>;
-        location = <0>;
+        efm32,location = <0>;
 };
diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
index 6fd1dd1638dd..a1d1205d8185 100644
--- a/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
+++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.txt
@@ -4,11 +4,24 @@ Required properties:
 - compatible : Should be "fsl,<soc>-lpuart"
 - reg : Address and length of the register set for the device
 - interrupts : Should contain uart interrupt
+- clocks : phandle + clock specifier pairs, one for each entry in clock-names
+- clock-names : should contain: "ipg" - the uart clock
+
+Optional properties:
+- dmas: A list of two dma specifiers, one for each entry in dma-names.
+- dma-names: should contain "tx" and "rx".
+
+Note: Optional properties for DMA support. Write them both or both not.
 
 Example:
 
 uart0: serial@40027000 {
-               compatible = "fsl,vf610-lpuart";
-               reg = <0x40027000 0x1000>;
-               interrupts = <0 61 0x00>;
-       };
+                compatible = "fsl,vf610-lpuart";
+                reg = <0x40027000 0x1000>;
+                interrupts = <0 61 0x00>;
+                clocks = <&clks VF610_CLK_UART0>;
+                clock-names = "ipg";
+                dmas = <&edma0 0 2>,
+                        <&edma0 0 3>;
+                dma-names = "rx","tx";
+        };
diff --git a/Documentation/devicetree/bindings/serial/maxim,max310x.txt b/Documentation/devicetree/bindings/serial/maxim,max310x.txt
new file mode 100644
index 000000000000..83a919c241b0
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/maxim,max310x.txt
@@ -0,0 +1,36 @@
+* Maxim MAX310X advanced Universal Asynchronous Receiver-Transmitter (UART)
+
+Required properties:
+- compatible: Should be one of the following:
+  - "maxim,max3107" for Maxim MAX3107,
+  - "maxim,max3108" for Maxim MAX3108,
+  - "maxim,max3109" for Maxim MAX3109,
+  - "maxim,max14830" for Maxim MAX14830.
+- reg: SPI chip select number.
+- interrupt-parent: The phandle for the interrupt controller that
+  services interrupts for this IC.
+- interrupts: Specifies the interrupt source of the parent interrupt
+  controller. The format of the interrupt specifier depends on the
+  parent interrupt controller.
+- clocks: phandle to the IC source clock.
+- clock-names: Should be "xtal" if clock is an external crystal or
+  "osc" if an external clock source is used.
+
+Optional properties:
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be two. The first cell is the GPIO number and
+  the second cell is used to specify the GPIO polarity:
+    0 = active high,
+    1 = active low.
+
+Example:
+        max14830: max14830@0 {
+                compatible = "maxim,max14830";
+                reg = <0>;
+                clocks = <&clk20m>;
+                clock-names = "osc";
+                interrupt-parent = <&gpio3>;
+                interrupts = <7 IRQ_TYPE_EDGE_FALLING>;
+                gpio-controller;
+                #gpio-cells = <2>;
+        };
diff --git a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
index f372cf29068d..53e6c175db6c 100644
--- a/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
+++ b/Documentation/devicetree/bindings/serial/renesas,sci-serial.txt
@@ -37,7 +37,7 @@ Example:
         };
 
         scifa0: serial@e6c40000 {
-                compatible = "renesas,scifa-r8a7790", "renesas,scifa-generic";
+                compatible = "renesas,scifa-r8a7790", "renesas,scifa";
                 reg = <0 0xe6c40000 0 64>;
                 interrupt-parent = <&gic>;
                 interrupts = <0 144 IRQ_TYPE_LEVEL_HIGH>;
diff --git a/Documentation/devicetree/bindings/sound/armada-370db-audio.txt b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
new file mode 100644
index 000000000000..bf984d238620
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/armada-370db-audio.txt
@@ -0,0 +1,27 @@
+Device Tree bindings for the Armada 370 DB audio
+================================================
+
+These Device Tree bindings are used to describe the audio complex
+found on the Armada 370 DB platform.
+
+Mandatory properties:
+
+ * compatible: must be "marvell,a370db-audio"
+
+ * marvell,audio-controller: a phandle that points to the audio
+   controller of the Armada 370 SoC.
+
+ * marvell,audio-codec: a set of three phandles that points to:
+
+    1/ the analog audio codec connected to the Armada 370 SoC
+    2/ the S/PDIF transceiver
+    3/ the S/PDIF receiver
+
+Example:
+
+        sound {
+              compatible = "marvell,a370db-audio";
+              marvell,audio-controller = <&audio_controller>;
+              marvell,audio-codec = <&audio_codec &spdif_out &spdif_in>;
+              status = "okay";
+        };
diff --git a/Documentation/devicetree/bindings/sound/cs42xx8.txt b/Documentation/devicetree/bindings/sound/cs42xx8.txt
new file mode 100644
index 000000000000..f631fbca6284
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/cs42xx8.txt
@@ -0,0 +1,28 @@
+CS42448/CS42888 audio CODEC
+
+Required properties:
+
+  - compatible : must contain one of "cirrus,cs42448" and "cirrus,cs42888"
+
+  - reg : the I2C address of the device for I2C
+
+  - clocks : a list of phandles + clock-specifiers, one for each entry in
+    clock-names
+
+  - clock-names : must contain "mclk"
+
+  - VA-supply, VD-supply, VLS-supply, VLC-supply: power supplies for the device,
+    as covered in Documentation/devicetree/bindings/regulator/regulator.txt
+
+Example:
+
+codec: cs42888@48 {
+        compatible = "cirrus,cs42888";
+        reg = <0x48>;
+        clocks = <&codec_mclk 0>;
+        clock-names = "mclk";
+        VA-supply = <&reg_audio>;
+        VD-supply = <&reg_audio>;
+        VLS-supply = <&reg_audio>;
+        VLC-supply = <&reg_audio>;
+};
diff --git a/Documentation/devicetree/bindings/sound/da9055.txt b/Documentation/devicetree/bindings/sound/da9055.txt
new file mode 100644
index 000000000000..ed1b7cc6f249
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/da9055.txt
@@ -0,0 +1,22 @@
+* Dialog DA9055 Audio CODEC
+
+DA9055 provides Audio CODEC support (I2C only).
+
+The Audio CODEC device in DA9055 has it's own I2C address which is configurable,
+so the device is instantiated separately from the PMIC (MFD) device.
+
+For details on accompanying PMIC I2C device, see the following:
+Documentation/devicetree/bindings/mfd/da9055.txt
+
+Required properties:
+
+  - compatible: "dlg,da9055-codec"
+  - reg: Specifies the I2C slave address
+
+
+Example:
+
+        codec: da9055-codec@1a {
+                compatible = "dlg,da9055-codec";
+                reg = <0x1a>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
index 865178d5cdf3..963e100514c2 100644
--- a/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
+++ b/Documentation/devicetree/bindings/sound/davinci-evm-audio.txt
@@ -5,12 +5,19 @@ Required properties:
 - ti,model : The user-visible name of this sound complex.
 - ti,audio-codec : The phandle of the TLV320AIC3x audio codec
 - ti,mcasp-controller : The phandle of the McASP controller
-- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec
 - ti,audio-routing : A list of the connections between audio components.
   Each entry is a pair of strings, the first being the connection's sink,
   the second being the connection's source. Valid names for sources and
   sinks are the codec's pins, and the jacks on the board:
 
+Optional properties:
+- ti,codec-clock-rate : The Codec Clock rate (in Hz) applied to the Codec.
+- clocks : Reference to the master clock
+- clock-names : The clock should be named "mclk"
+- Either codec-clock-rate or the codec-clock reference has to be defined. If
+  the both are defined the driver attempts to set referenced clock to the
+  defined rate and takes the rate from the clock reference.
+
   Board connectors:
 
   * Headphone Jack
diff --git a/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
new file mode 100644
index 000000000000..0d7985c864af
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/eukrea-tlv320.txt
@@ -0,0 +1,21 @@
+Audio complex for Eukrea boards with tlv320aic23 codec.
+
+Required properties:
+- compatible : "eukrea,asoc-tlv320"
+- eukrea,model : The user-visible name of this sound complex.
+- ssi-controller : The phandle of the SSI controller.
+- fsl,mux-int-port : The internal port of the i.MX audio muxer (AUDMUX).
+- fsl,mux-ext-port : The external port of the i.MX audio muxer.
+
+Note: The AUDMUX port numbering should start at 1, which is consistent with
+hardware manual.
+
+Example:
+
+        sound {
+                compatible = "eukrea,asoc-tlv320";
+                eukrea,model = "imx51-eukrea-tlv320aic23";
+                ssi-controller = <&ssi2>;
+                fsl,mux-int-port = <2>;
+                fsl,mux-ext-port = <3>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/fsl,esai.txt b/Documentation/devicetree/bindings/sound/fsl,esai.txt
index d7b99fa637b5..aeb8c4a0b88d 100644
--- a/Documentation/devicetree/bindings/sound/fsl,esai.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,esai.txt
@@ -34,6 +34,10 @@ Required properties:
     that ESAI would work in the synchronous mode, which means all the settings
     for Receiving would be duplicated from Transmition related registers.
 
+  - big-endian : If this property is absent, the native endian mode will
+    be in use as default, or the big endian mode will be in use for all the
+    device registers.
+
 Example:
 
 esai: esai@02024000 {
@@ -46,5 +50,6 @@ esai: esai@02024000 {
         dma-names = "rx", "tx";
         fsl,fifo-depth = <128>;
         fsl,esai-synchronous;
+        big-endian;
         status = "disabled";
 };
diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.txt b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
index f2ae335670f5..3e9e82c8eab3 100644
--- a/Documentation/devicetree/bindings/sound/fsl,spdif.txt
+++ b/Documentation/devicetree/bindings/sound/fsl,spdif.txt
@@ -29,6 +29,10 @@ Required properties:
                         can also be referred to TxClk_Source
                         bit of register SPDIF_STC.
 
+   - big-endian : If this property is absent, the native endian mode will
+   be in use as default, or the big endian mode will be in use for all the
+   device registers.
+
 Example:
 
 spdif: spdif@02004000 {
@@ -50,5 +54,6 @@ spdif: spdif@02004000 {
                 "rxtx5", "rxtx6",
                 "rxtx7";
 
+        big-endian;
         status = "okay";
 };
diff --git a/Documentation/devicetree/bindings/sound/mvebu-audio.txt b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
index f0062c5871b4..cb8c07c81ce4 100644
--- a/Documentation/devicetree/bindings/sound/mvebu-audio.txt
+++ b/Documentation/devicetree/bindings/sound/mvebu-audio.txt
@@ -5,6 +5,7 @@ Required properties:
 - compatible:
   "marvell,kirkwood-audio" for Kirkwood platforms
   "marvell,dove-audio" for Dove platforms
+  "marvell,armada370-audio" for Armada 370 platforms
 
 - reg: physical base address of the controller and length of memory mapped
   region.
diff --git a/Documentation/devicetree/bindings/sound/pcm512x.txt b/Documentation/devicetree/bindings/sound/pcm512x.txt
new file mode 100644
index 000000000000..faff75e64573
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/pcm512x.txt
@@ -0,0 +1,30 @@
+PCM512x audio CODECs
+
+These devices support both I2C and SPI (configured with pin strapping
+on the board).
+
+Required properties:
+
+  - compatible : One of "ti,pcm5121" or "ti,pcm5122"
+
+  - reg : the I2C address of the device for I2C, the chip select
+          number for SPI.
+
+  - AVDD-supply, DVDD-supply, and CPVDD-supply : power supplies for the
+    device, as covered in bindings/regulator/regulator.txt
+
+Optional properties:
+
+  - clocks : A clock specifier for the clock connected as SCLK.  If this
+    is absent the device will be configured to clock from BCLK.
+
+Example:
+
+        pcm5122: pcm5122@4c {
+                compatible = "ti,pcm5122";
+                reg = <0x4c>;
+
+                AVDD-supply = <&reg_3v3_analog>;
+                DVDD-supply = <&reg_1v8>;
+                CPVDD-supply = <&reg_3v3>;
+        };
diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.txt b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
new file mode 100644
index 000000000000..a44e9179faf5
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.txt
@@ -0,0 +1,105 @@
+Renesas R-Car sound
+
+Required properties:
+- compatible                    : "renesas,rcar_sound-gen1" if generation1
+                                  "renesas,rcar_sound-gen2" if generation2
+- reg                           : Should contain the register physical address.
+                                  required register is
+                                   SRU/ADG/SSI      if generation1
+                                   SRU/ADG/SSIU/SSI if generation2
+- rcar_sound,ssi                : Should contain SSI feature.
+                                  The number of SSI subnode should be same as HW.
+                                  see below for detail.
+- rcar_sound,src                : Should contain SRC feature.
+                                  The number of SRC subnode should be same as HW.
+                                  see below for detail.
+- rcar_sound,dai                : DAI contents.
+                                  The number of DAI subnode should be same as HW.
+                                  see below for detail.
+
+SSI subnode properties:
+- interrupts                    : Should contain SSI interrupt for PIO transfer
+- shared-pin                    : if shared clock pin
+
+SRC subnode properties:
+no properties at this point
+
+DAI subnode properties:
+- playback                      : list of playback modules
+- capture                       : list of capture  modules
+
+Example:
+
+rcar_sound: rcar_sound@0xffd90000 {
+        #sound-dai-cells = <1>;
+        compatible = "renesas,rcar_sound-gen2";
+        reg =   <0 0xec500000 0 0x1000>, /* SCU */
+                <0 0xec5a0000 0 0x100>,  /* ADG */
+                <0 0xec540000 0 0x1000>, /* SSIU */
+                <0 0xec541000 0 0x1280>; /* SSI */
+
+        rcar_sound,src {
+                src0: src@0 { };
+                src1: src@1 { };
+                src2: src@2 { };
+                src3: src@3 { };
+                src4: src@4 { };
+                src5: src@5 { };
+                src6: src@6 { };
+                src7: src@7 { };
+                src8: src@8 { };
+                src9: src@9 { };
+        };
+
+        rcar_sound,ssi {
+                ssi0: ssi@0 {
+                        interrupts = <0 370 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi1: ssi@1 {
+                        interrupts = <0 371 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi2: ssi@2 {
+                        interrupts = <0 372 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi3: ssi@3 {
+                        interrupts = <0 373 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi4: ssi@4 {
+                        interrupts = <0 374 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi5: ssi@5 {
+                        interrupts = <0 375 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi6: ssi@6 {
+                        interrupts = <0 376 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi7: ssi@7 {
+                        interrupts = <0 377 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi8: ssi@8 {
+                        interrupts = <0 378 IRQ_TYPE_LEVEL_HIGH>;
+                };
+                ssi9: ssi@9 {
+                        interrupts = <0 379 IRQ_TYPE_LEVEL_HIGH>;
+                };
+        };
+
+        rcar_sound,dai {
+                dai0 {
+                        playback = <&ssi5 &src5>;
+                        capture  = <&ssi6>;
+                };
+                dai1 {
+                        playback = <&ssi3>;
+                };
+                dai2 {
+                        capture  = <&ssi4>;
+                };
+                dai3 {
+                        playback = <&ssi7>;
+                };
+                dai4 {
+                        capture  = <&ssi8>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/sound/simple-card.txt b/Documentation/devicetree/bindings/sound/simple-card.txt
index 19c84df5fffa..131aa2ad7f1a 100644
--- a/Documentation/devicetree/bindings/sound/simple-card.txt
+++ b/Documentation/devicetree/bindings/sound/simple-card.txt
@@ -8,16 +8,26 @@ Required properties:
 
 Optional properties:
 
+- simple-audio-card,name                : User specified audio sound card name, one string
+                                          property.
 - simple-audio-card,format              : CPU/CODEC common audio format.
                                           "i2s", "right_j", "left_j" , "dsp_a"
                                           "dsp_b", "ac97", "pdm", "msb", "lsb"
+- simple-audio-card,widgets             : Please refer to widgets.txt.
 - simple-audio-card,routing             : A list of the connections between audio components.
                                           Each entry is a pair of strings, the first being the
                                           connection's sink, the second being the connection's
                                           source.
+- dai-tdm-slot-num                      : Please refer to tdm-slot.txt.
+- dai-tdm-slot-width                    : Please refer to tdm-slot.txt.
 
 Required subnodes:
 
+- simple-audio-card,dai-link            : container for the CPU and CODEC sub-nodes
+                                          This container may be omitted when the
+                                          card has only one DAI link.
+                                          See the examples.
+
 - simple-audio-card,cpu                 : CPU   sub-node
 - simple-audio-card,codec               : CODEC sub-node
 
@@ -38,15 +48,29 @@ Optional CPU/CODEC subnodes properties:
                                           clock node (= common clock), or "system-clock-frequency"
                                           (if system doens't support common clock)
 
-Example:
+Note:
+ * For 'format', 'frame-master', 'bitclock-master', 'bitclock-inversion' and
+   'frame-inversion', the simple card will use the settings of CODEC for both
+   CPU and CODEC sides as we need to keep the settings identical for both ends
+   of the link.
+
+Example 1 - single DAI link:
 
 sound {
         compatible = "simple-audio-card";
+        simple-audio-card,name = "VF610-Tower-Sound-Card";
         simple-audio-card,format = "left_j";
+        simple-audio-card,widgets =
+                "Microphone", "Microphone Jack",
+                "Headphone", "Headphone Jack",
+                "Speaker", "External Speaker";
         simple-audio-card,routing =
-                "MIC_IN", "Mic Jack",
+                "MIC_IN", "Microphone Jack",
                 "Headphone Jack", "HP_OUT",
-                "Ext Spk", "LINE_OUT";
+                "External Speaker", "LINE_OUT";
+
+        dai-tdm-slot-num = <2>;
+        dai-tdm-slot-width = <8>;
 
         simple-audio-card,cpu {
                 sound-dai = <&sh_fsi2 0>;
@@ -75,3 +99,38 @@ sh_fsi2: sh_fsi2@ec230000 {
         interrupt-parent = <&gic>;
         interrupts = <0 146 0x4>;
 };
+
+Example 2 - many DAI links:
+
+sound {
+        compatible = "simple-audio-card";
+        simple-audio-card,name = "Cubox Audio";
+        simple-audio-card,format = "i2s";
+
+        simple-audio-card,dai-link@0 {          /* I2S - HDMI */
+                simple-audio-card,cpu {
+                        sound-dai = <&audio1 0>;
+                };
+                simple-audio-card,codec {
+                        sound-dai = <&tda998x 0>;
+                };
+        };
+
+        simple-audio-card,dai-link@1 {          /* S/PDIF - HDMI */
+                simple-audio-card,cpu {
+                        sound-dai = <&audio1 1>;
+                };
+                simple-audio-card,codec {
+                        sound-dai = <&tda998x 1>;
+                };
+        };
+
+        simple-audio-card,dai-link@2 {          /* S/PDIF - S/PDIF */
+                simple-audio-card,cpu {
+                        sound-dai = <&audio1 1>;
+                };
+                simple-audio-card,codec {
+                        sound-dai = <&spdif_codec>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/sound/sirf-audio-codec.txt b/Documentation/devicetree/bindings/sound/sirf-audio-codec.txt
new file mode 100644
index 000000000000..062f5ec36f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sirf-audio-codec.txt
@@ -0,0 +1,17 @@
+SiRF internal audio CODEC
+
+Required properties:
+
+  - compatible : "sirf,atlas6-audio-codec" or "sirf,prima2-audio-codec"
+
+  - reg : the register address of the device.
+
+  - clocks: the clock of SiRF internal audio codec
+
+Example:
+
+audiocodec: audiocodec@b0040000 {
+        compatible = "sirf,atlas6-audio-codec";
+        reg = <0xb0040000 0x10000>;
+        clocks = <&clks 27>;
+};
diff --git a/Documentation/devicetree/bindings/sound/sirf-audio-port.txt b/Documentation/devicetree/bindings/sound/sirf-audio-port.txt
new file mode 100644
index 000000000000..1f66de3c8f00
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sirf-audio-port.txt
@@ -0,0 +1,20 @@
+* SiRF SoC audio port
+
+Required properties:
+- compatible: "sirf,audio-port"
+- reg: Base address and size entries:
+- dmas: List of DMA controller phandle and DMA request line ordered pairs.
+- dma-names: Identifier string for each DMA request line in the dmas property.
+  These strings correspond 1:1 with the ordered pairs in dmas.
+
+  One of the DMA channels will be responsible for transmission (should be
+  named "tx") and one for reception (should be named "rx").
+
+Example:
+
+audioport: audioport@b0040000 {
+        compatible = "sirf,audio-port";
+        reg = <0xb0040000 0x10000>;
+        dmas = <&dmac1 3>, <&dmac1 8>;
+        dma-names = "rx", "tx";
+};
diff --git a/Documentation/devicetree/bindings/sound/sirf-audio.txt b/Documentation/devicetree/bindings/sound/sirf-audio.txt
new file mode 100644
index 000000000000..c88882ca3704
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sirf-audio.txt
@@ -0,0 +1,41 @@
+* SiRF atlas6 and prima2 internal audio codec and port based audio setups
+
+Required properties:
+- compatible: "sirf,sirf-audio-card"
+- sirf,audio-platform: phandle for the platform node
+- sirf,audio-codec: phandle for the SiRF internal codec node
+
+Optional properties:
+- hp-pa-gpios: Need to be present if the board need control external
+  headphone amplifier.
+- spk-pa-gpios: Need to be present if the board need control external
+  speaker amplifier.
+- hp-switch-gpios: Need to be present if the board capable to detect jack
+  insertion, removal.
+
+Available audio endpoints for the audio-routing table:
+
+Board connectors:
+ * Headset Stereophone
+ * Ext Spk
+ * Line In
+ * Mic
+
+SiRF internal audio codec pins:
+ * HPOUTL
+ * HPOUTR
+ * SPKOUT
+ * Ext Mic
+ * Mic Bias
+
+Example:
+
+sound {
+                compatible = "sirf,sirf-audio-card";
+                sirf,audio-codec = <&audiocodec>;
+                sirf,audio-platform = <&audioport>;
+                hp-pa-gpios = <&gpio 44 0>;
+                spk-pa-gpios = <&gpio 46 0>;
+                hp-switch-gpios = <&gpio 45 0>;
+};
+
diff --git a/Documentation/devicetree/bindings/sound/tdm-slot.txt b/Documentation/devicetree/bindings/sound/tdm-slot.txt
new file mode 100644
index 000000000000..6a2c84247f91
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tdm-slot.txt
@@ -0,0 +1,20 @@
+TDM slot:
+
+This specifies audio DAI's TDM slot.
+
+TDM slot properties:
+dai-tdm-slot-num : Number of slots in use.
+dai-tdm-slot-width :  Width in bits for each slot.
+
+For instance:
+        dai-tdm-slot-num = <2>;
+        dai-tdm-slot-width = <8>;
+
+And for each spcified driver, there could be one .of_xlate_tdm_slot_mask()
+to specify a explicit mapping of the channels and the slots. If it's absent
+the default snd_soc_of_xlate_tdm_slot_mask() will be used to generating the
+tx and rx masks.
+
+For snd_soc_of_xlate_tdm_slot_mask(), the tx and rx masks will use a 1 bit
+for an active slot as default, and the default active bits are at the LSB of
+the masks.
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
new file mode 100644
index 000000000000..74c66dee3e14
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt
@@ -0,0 +1,61 @@
+Texas Instruments - tlv320aic31xx Codec module
+
+The tlv320aic31xx serial control bus communicates through I2C protocols
+
+Required properties:
+
+- compatible - "string" - One of:
+    "ti,tlv320aic310x" - Generic TLV320AIC31xx with mono speaker amp
+    "ti,tlv320aic311x" - Generic TLV320AIC31xx with stereo speaker amp
+    "ti,tlv320aic3100" - TLV320AIC3100 (mono speaker amp, no MiniDSP)
+    "ti,tlv320aic3110" - TLV320AIC3110 (stereo speaker amp, no MiniDSP)
+    "ti,tlv320aic3120" - TLV320AIC3120 (mono speaker amp, MiniDSP)
+    "ti,tlv320aic3111" - TLV320AIC3111 (stereo speaker amp, MiniDSP)
+
+- reg - <int> -  I2C slave address
+
+
+Optional properties:
+
+- gpio-reset - gpio pin number used for codec reset
+- ai31xx-micbias-vg - MicBias Voltage setting
+        1 or MICBIAS_2_0V - MICBIAS output is powered to 2.0V
+        2 or MICBIAS_2_5V - MICBIAS output is powered to 2.5V
+        3 or MICBIAS_AVDD - MICBIAS output is connected to AVDD
+        If this node is not mentioned or if the value is unknown, then
+        micbias is set to 2.0V.
+- HPVDD-supply, SPRVDD-supply, SPLVDD-supply, AVDD-supply, IOVDD-supply,
+  DVDD-supply : power supplies for the device as covered in
+  Documentation/devicetree/bindings/regulator/regulator.txt
+
+CODEC output pins:
+  * HPL
+  * HPR
+  * SPL, devices with stereo speaker amp
+  * SPR, devices with stereo speaker amp
+  * SPK, devices with mono speaker amp
+  * MICBIAS
+
+CODEC input pins:
+  * MIC1LP
+  * MIC1RP
+  * MIC1LM
+
+The pins can be used in referring sound node's audio-routing property.
+
+Example:
+#include <dt-bindings/sound/tlv320aic31xx-micbias.h>
+
+tlv320aic31xx: tlv320aic31xx@18 {
+        compatible = "ti,tlv320aic311x";
+        reg = <0x18>;
+
+        ai31xx-micbias-vg = <MICBIAS_OFF>;
+
+        HPVDD-supply = <&regulator>;
+        SPRVDD-supply = <&regulator>;
+        SPLVDD-supply = <&regulator>;
+        AVDD-supply = <&regulator>;
+        IOVDD-supply = <&regulator>;
+        DVDD-supply = <&regulator>;
+};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt
new file mode 100644
index 000000000000..5e2741af27be
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt
@@ -0,0 +1,30 @@
+Texas Instruments - tlv320aic32x4 Codec module
+
+The tlv320aic32x4 serial control bus communicates through I2C protocols
+
+Required properties:
+ - compatible: Should be "ti,tlv320aic32x4"
+ - reg: I2C slave address
+ - supply-*: Required supply regulators are:
+    "iov" - digital IO power supply
+    "ldoin" - LDO power supply
+    "dv" - Digital core power supply
+    "av" - Analog core power supply
+    If you supply ldoin, dv and av are optional. Otherwise they are required
+   See regulator/regulator.txt for more information about the detailed binding
+   format.
+
+Optional properties:
+ - reset-gpios: Reset-GPIO phandle with args as described in gpio/gpio.txt
+ - clocks/clock-names: Clock named 'mclk' for the master clock of the codec.
+   See clock/clock-bindings.txt for information about the detailed format.
+
+
+Example:
+
+codec: tlv320aic32x4@18 {
+        compatible = "ti,tlv320aic32x4";
+        reg = <0x18>;
+        clocks = <&clks 201>;
+        clock-names = "mclk";
+};
diff --git a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
index 9d8ea14db490..5e6040c2c2e9 100644
--- a/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
+++ b/Documentation/devicetree/bindings/sound/tlv320aic3x.txt
@@ -6,7 +6,6 @@ Required properties:
 
 - compatible - "string" - One of:
     "ti,tlv320aic3x" - Generic TLV320AIC3x device
-    "ti,tlv320aic32x4" - TLV320AIC32x4
     "ti,tlv320aic33" - TLV320AIC33
     "ti,tlv320aic3007" - TLV320AIC3007
     "ti,tlv320aic3106" - TLV320AIC3106
diff --git a/Documentation/devicetree/bindings/sound/widgets.txt b/Documentation/devicetree/bindings/sound/widgets.txt
new file mode 100644
index 000000000000..b6de5ba3b2de
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/widgets.txt
@@ -0,0 +1,20 @@
+Widgets:
+
+This mainly specifies audio off-codec DAPM widgets.
+
+Each entry is a pair of strings in DT:
+
+        "template-wname", "user-supplied-wname"
+
+The "template-wname" being the template widget name and currently includes:
+"Microphone", "Line", "Headphone" and "Speaker".
+
+The "user-supplied-wname" being the user specified widget name.
+
+For instance:
+        simple-audio-widgets =
+                "Microphone", "Microphone Jack",
+                "Line", "Line In Jack",
+                "Line", "Line Out Jack",
+                "Headphone", "Headphone Jack",
+                "Speaker", "Speaker External";
diff --git a/Documentation/devicetree/bindings/spi/efm32-spi.txt b/Documentation/devicetree/bindings/spi/efm32-spi.txt
index a590ca51be75..8f081c96a4fa 100644
--- a/Documentation/devicetree/bindings/spi/efm32-spi.txt
+++ b/Documentation/devicetree/bindings/spi/efm32-spi.txt
@@ -3,24 +3,24 @@
 Required properties:
 - #address-cells: see spi-bus.txt
 - #size-cells: see spi-bus.txt
-- compatible: should be "efm32,spi"
+- compatible: should be "energymicro,efm32-spi"
 - reg: Offset and length of the register set for the controller
 - interrupts: pair specifying rx and tx irq
 - clocks: phandle to the spi clock
 - cs-gpios: see spi-bus.txt
-- location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values.
+- efm32,location: Value to write to the ROUTE register's LOCATION bitfield to configure the pinmux for the device, see datasheet for values.
 
 Example:
 
 spi1: spi@0x4000c400 { /* USART1 */
         #address-cells = <1>;
         #size-cells = <0>;
-        compatible = "efm32,spi";
+        compatible = "energymicro,efm32-spi";
         reg = <0x4000c400 0x400>;
         interrupts = <15 16>;
         clocks = <&cmu 20>;
         cs-gpios = <&gpio 51 1>; // D3
-        location = <1>;
+        efm32,location = <1>;
         status = "ok";
 
         ks8851@0 {
diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
new file mode 100644
index 000000000000..b82a268f1bd4
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/qcom,spi-qup.txt
@@ -0,0 +1,85 @@
+Qualcomm Universal Peripheral (QUP) Serial Peripheral Interface (SPI)
+
+The QUP core is an AHB slave that provides a common data path (an output FIFO
+and an input FIFO) for serial peripheral interface (SPI) mini-core.
+
+SPI in master mode supports up to 50MHz, up to four chip selects, programmable
+data path from 4 bits to 32 bits and numerous protocol variants.
+
+Required properties:
+- compatible:     Should contain "qcom,spi-qup-v2.1.1" or "qcom,spi-qup-v2.2.1"
+- reg:            Should contain base register location and length
+- interrupts:     Interrupt number used by this controller
+
+- clocks:         Should contain the core clock and the AHB clock.
+- clock-names:    Should be "core" for the core clock and "iface" for the
+                  AHB clock.
+
+- #address-cells: Number of cells required to define a chip select
+                  address on the SPI bus. Should be set to 1.
+- #size-cells:    Should be zero.
+
+Optional properties:
+- spi-max-frequency: Specifies maximum SPI clock frequency,
+                     Units - Hz. Definition as per
+                     Documentation/devicetree/bindings/spi/spi-bus.txt
+
+SPI slave nodes must be children of the SPI master node and can contain
+properties described in Documentation/devicetree/bindings/spi/spi-bus.txt
+
+Example:
+
+        spi_8: spi@f9964000 { /* BLSP2 QUP2 */
+
+                compatible = "qcom,spi-qup-v2";
+                #address-cells = <1>;
+                #size-cells = <0>;
+                reg = <0xf9964000 0x1000>;
+                interrupts = <0 102 0>;
+                spi-max-frequency = <19200000>;
+
+                clocks = <&gcc GCC_BLSP2_QUP2_SPI_APPS_CLK>, <&gcc GCC_BLSP2_AHB_CLK>;
+                clock-names = "core", "iface";
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&spi8_default>;
+
+                device@0 {
+                        compatible = "arm,pl022-dummy";
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        reg = <0>; /* Chip select 0 */
+                        spi-max-frequency = <19200000>;
+                        spi-cpol;
+                };
+
+                device@1 {
+                        compatible = "arm,pl022-dummy";
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        reg = <1>; /* Chip select 1 */
+                        spi-max-frequency = <9600000>;
+                        spi-cpha;
+                };
+
+                device@2 {
+                        compatible = "arm,pl022-dummy";
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        reg = <2>; /* Chip select 2 */
+                        spi-max-frequency = <19200000>;
+                        spi-cpol;
+                        spi-cpha;
+                };
+
+                device@3 {
+                        compatible = "arm,pl022-dummy";
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        reg = <3>; /* Chip select 3 */
+                        spi-max-frequency = <19200000>;
+                        spi-cpol;
+                        spi-cpha;
+                        spi-cs-high;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/spi/sh-hspi.txt b/Documentation/devicetree/bindings/spi/sh-hspi.txt
index 30b57b1c8a13..319bad4af875 100644
--- a/Documentation/devicetree/bindings/spi/sh-hspi.txt
+++ b/Documentation/devicetree/bindings/spi/sh-hspi.txt
@@ -1,7 +1,29 @@
 Renesas HSPI.
 
 Required properties:
-- compatible :  "renesas,hspi"
-- reg : Offset and length of the register set for the device
-- interrupts : interrupt line used by HSPI
+- compatible       : "renesas,hspi-<soctype>", "renesas,hspi" as fallback.
+                     Examples with soctypes are:
+                       - "renesas,hspi-r8a7778" (R-Car M1)
+                       - "renesas,hspi-r8a7779" (R-Car H1)
+- reg              : Offset and length of the register set for the device
+- interrupt-parent : The phandle for the interrupt controller that
+                     services interrupts for this device
+- interrupts       : Interrupt specifier
+- #address-cells   : Must be <1>
+- #size-cells      : Must be <0>
+
+Pinctrl properties might be needed, too.  See
+Documentation/devicetree/bindings/pinctrl/renesas,*.
+
+Example:
+
+        hspi0: spi@fffc7000 {
+                compatible = "renesas,hspi-r8a7778", "renesas,hspi";
+                reg = <0xfffc7000 0x18>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 63 IRQ_TYPE_LEVEL_HIGH>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                status = "disabled";
+        };
 
diff --git a/Documentation/devicetree/bindings/spi/sh-msiof.txt b/Documentation/devicetree/bindings/spi/sh-msiof.txt
index e6222106ca36..f24baf3b6cc1 100644
--- a/Documentation/devicetree/bindings/spi/sh-msiof.txt
+++ b/Documentation/devicetree/bindings/spi/sh-msiof.txt
@@ -1,12 +1,40 @@
 Renesas MSIOF spi controller
 
 Required properties:
-- compatible :  "renesas,sh-msiof" for SuperH or
-                "renesas,sh-mobile-msiof" for SH Mobile series
-- reg : Offset and length of the register set for the device
-- interrupts : interrupt line used by MSIOF
+- compatible           : "renesas,msiof-<soctype>" for SoCs,
+                         "renesas,sh-msiof" for SuperH, or
+                         "renesas,sh-mobile-msiof" for SH Mobile series.
+                         Examples with soctypes are:
+                         "renesas,msiof-r8a7790" (R-Car H2)
+                         "renesas,msiof-r8a7791" (R-Car M2)
+- reg                  : Offset and length of the register set for the device
+- interrupt-parent     : The phandle for the interrupt controller that
+                         services interrupts for this device
+- interrupts           : Interrupt specifier
+- #address-cells       : Must be <1>
+- #size-cells          : Must be <0>
 
 Optional properties:
-- num-cs                : total number of chip-selects
-- renesas,tx-fifo-size  : Overrides the default tx fifo size given in words
-- renesas,rx-fifo-size  : Overrides the default rx fifo size given in words
+- clocks               : Must contain a reference to the functional clock.
+- num-cs               : Total number of chip-selects (default is 1)
+
+Optional properties, deprecated for soctype-specific bindings:
+- renesas,tx-fifo-size : Overrides the default tx fifo size given in words
+                         (default is 64)
+- renesas,rx-fifo-size : Overrides the default rx fifo size given in words
+                         (default is 64, or 256 on R-Car H2 and M2)
+
+Pinctrl properties might be needed, too.  See
+Documentation/devicetree/bindings/pinctrl/renesas,*.
+
+Example:
+
+        msiof0: spi@e6e20000 {
+                compatible = "renesas,msiof-r8a7791";
+                reg = <0 0xe6e20000 0 0x0064>;
+                interrupts = <0 156 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&mstp0_clks R8A7791_CLK_MSIOF0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                status = "disabled";
+        };
diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index a1fb3035a42b..5376de40f10b 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -10,6 +10,7 @@ Required properties:
 - pinctrl-names: must contain a "default" entry.
 - spi-num-chipselects : the number of the chipselect signals.
 - bus-num : the slave chip chipselect signal number.
+- big-endian : if DSPI modudle is big endian, the bool will be set in node.
 Example:
 
 dspi0@4002c000 {
@@ -24,6 +25,7 @@ dspi0@4002c000 {
         bus-num = <0>;
         pinctrl-names = "default";
         pinctrl-0 = <&pinctrl_dspi0_1>;
+        big-endian;
         status = "okay";
 
         sflash: at26df081a@0 {
diff --git a/Documentation/devicetree/bindings/spi/spi-rspi.txt b/Documentation/devicetree/bindings/spi/spi-rspi.txt
new file mode 100644
index 000000000000..d57d82a74054
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-rspi.txt
@@ -0,0 +1,61 @@
+Device tree configuration for Renesas RSPI/QSPI driver
+
+Required properties:
+- compatible       : For Renesas Serial Peripheral Interface on legacy SH:
+                     "renesas,rspi-<soctype>", "renesas,rspi" as fallback.
+                     For Renesas Serial Peripheral Interface on RZ/A1H:
+                     "renesas,rspi-<soctype>", "renesas,rspi-rz" as fallback.
+                     For Quad Serial Peripheral Interface on R-Car Gen2:
+                     "renesas,qspi-<soctype>", "renesas,qspi" as fallback.
+                     Examples with soctypes are:
+                        - "renesas,rspi-sh7757" (SH)
+                        - "renesas,rspi-r7s72100" (RZ/A1H)
+                        - "renesas,qspi-r8a7790" (R-Car H2)
+                        - "renesas,qspi-r8a7791" (R-Car M2)
+- reg              : Address start and address range size of the device
+- interrupts       : A list of interrupt-specifiers, one for each entry in
+                     interrupt-names.
+                     If interrupt-names is not present, an interrupt specifier
+                     for a single muxed interrupt.
+- interrupt-names  : A list of interrupt names. Should contain (if present):
+                       - "error" for SPEI,
+                       - "rx" for SPRI,
+                       - "tx" to SPTI,
+                       - "mux" for a single muxed interrupt.
+- interrupt-parent : The phandle for the interrupt controller that
+                     services interrupts for this device.
+- num-cs           : Number of chip selects. Some RSPI cores have more than 1.
+- #address-cells   : Must be <1>
+- #size-cells      : Must be <0>
+
+Optional properties:
+- clocks           : Must contain a reference to the functional clock.
+
+Pinctrl properties might be needed, too.  See
+Documentation/devicetree/bindings/pinctrl/renesas,*.
+
+Examples:
+
+        spi0: spi@e800c800 {
+                compatible = "renesas,rspi-r7s72100", "renesas,rspi-rz";
+                reg = <0xe800c800 0x24>;
+                interrupts = <0 238 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 239 IRQ_TYPE_LEVEL_HIGH>,
+                             <0 240 IRQ_TYPE_LEVEL_HIGH>;
+                interrupt-names = "error", "rx", "tx";
+                interrupt-parent = <&gic>;
+                num-cs = <1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
+
+        spi: spi@e6b10000 {
+                compatible = "renesas,qspi-r8a7791", "renesas,qspi";
+                reg = <0 0xe6b10000 0 0x2c>;
+                interrupt-parent = <&gic>;
+                interrupts = <0 184 IRQ_TYPE_LEVEL_HIGH>;
+                clocks = <&mstp9_clks R8A7791_CLK_QSPI_MOD>;
+                num-cs = <1>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
diff --git a/Documentation/devicetree/bindings/spi/spi-sun4i.txt b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
new file mode 100644
index 000000000000..de827f5a301e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sun4i.txt
@@ -0,0 +1,24 @@
+Allwinner A10 SPI controller
+
+Required properties:
+- compatible: Should be "allwinner,sun4-a10-spi".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: phandle to the clocks feeding the SPI controller. Two are
+          needed:
+  - "ahb": the gated AHB parent clock
+  - "mod": the parent module clock
+- clock-names: Must contain the clock names described just above
+
+Example:
+
+spi1: spi@01c06000 {
+        compatible = "allwinner,sun4i-a10-spi";
+        reg = <0x01c06000 0x1000>;
+        interrupts = <11>;
+        clocks = <&ahb_gates 21>, <&spi1_clk>;
+        clock-names = "ahb", "mod";
+        status = "disabled";
+        #address-cells = <1>;
+        #size-cells = <0>;
+};
diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
new file mode 100644
index 000000000000..21de73db6a05
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
@@ -0,0 +1,24 @@
+Allwinner A31 SPI controller
+
+Required properties:
+- compatible: Should be "allwinner,sun6i-a31-spi".
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: phandle to the clocks feeding the SPI controller. Two are
+          needed:
+  - "ahb": the gated AHB parent clock
+  - "mod": the parent module clock
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset controller asserting this device in
+          reset
+
+Example:
+
+spi1: spi@01c69000 {
+        compatible = "allwinner,sun6i-a31-spi";
+        reg = <0x01c69000 0x1000>;
+        interrupts = <0 66 4>;
+        clocks = <&ahb1_gates 21>, <&spi1_clk>;
+        clock-names = "ahb", "mod";
+        resets = <&ahb1_rst 21>;
+};
diff --git a/Documentation/devicetree/bindings/spi/spi-xtensa-xtfpga.txt b/Documentation/devicetree/bindings/spi/spi-xtensa-xtfpga.txt
new file mode 100644
index 000000000000..b6ebe2bc7041
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-xtensa-xtfpga.txt
@@ -0,0 +1,9 @@
+Cadence Xtensa XTFPGA platform SPI controller.
+
+This simple SPI master controller is built into xtfpga bitstreams and is used
+to control daughterboard audio codec.
+
+Required properties:
+- compatible: should be "cdns,xtfpga-spi".
+- reg: physical base address of the controller and length of memory mapped
+  region.
diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
new file mode 100644
index 000000000000..715d0998af8e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -0,0 +1,61 @@
+Qualcomm SPMI Controller (PMIC Arbiter)
+
+The SPMI PMIC Arbiter is found on the Snapdragon 800 Series.  It is an SPMI
+controller with wrapping arbitration logic to allow for multiple on-chip
+devices to control a single SPMI master.
+
+The PMIC Arbiter can also act as an interrupt controller, providing interrupts
+to slave devices.
+
+See spmi.txt for the generic SPMI controller binding requirements for child
+nodes.
+
+See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
+generic interrupt controller binding documentation.
+
+Required properties:
+- compatible : should be "qcom,spmi-pmic-arb".
+- reg-names  : must contain:
+     "core" - core registers
+     "intr" - interrupt controller registers
+     "cnfg" - configuration registers
+- reg : address + size pairs describing the PMIC arb register sets; order must
+        correspond with the order of entries in reg-names
+- #address-cells : must be set to 2
+- #size-cells : must be set to 0
+- qcom,ee : indicates the active Execution Environment identifier (0-5)
+- qcom,channel : which of the PMIC Arb provided channels to use for accesses (0-5)
+- interrupts : interrupt list for the PMIC Arb controller, must contain a
+               single interrupt entry for the peripheral interrupt
+- interrupt-names : corresponding interrupt names for the interrupts
+                    listed in the 'interrupts' property, must contain:
+     "periph_irq" - summary interrupt for PMIC peripherals
+- interrupt-controller : boolean indicator that the PMIC arbiter is an interrupt controller
+- #interrupt-cells :  must be set to 4. Interrupts are specified as a 4-tuple:
+    cell 1: slave ID for the requested interrupt (0-15)
+    cell 2: peripheral ID for requested interrupt (0-255)
+    cell 3: the requested peripheral interrupt (0-7)
+    cell 4: interrupt flags indicating level-sense information, as defined in
+            dt-bindings/interrupt-controller/irq.h
+
+Example:
+
+        spmi {
+                compatible = "qcom,spmi-pmic-arb";
+                reg-names = "core", "intr", "cnfg";
+                reg = <0xfc4cf000 0x1000>,
+                      <0xfc4cb000 0x1000>,
+                      <0xfc4ca000 0x1000>;
+
+                interrupt-names = "periph_irq";
+                interrupts = <0 190 0>;
+
+                qcom,ee = <0>;
+                qcom,channel = <0>;
+
+                #address-cells = <2>;
+                #size-cells = <0>;
+
+                interrupt-controller;
+                #interrupt-cells = <4>;
+        };
diff --git a/Documentation/devicetree/bindings/spmi/spmi.txt b/Documentation/devicetree/bindings/spmi/spmi.txt
new file mode 100644
index 000000000000..462a42fb3a1e
--- /dev/null
+++ b/Documentation/devicetree/bindings/spmi/spmi.txt
@@ -0,0 +1,41 @@
+System Power Management Interface (SPMI) Controller
+
+This document defines a generic set of bindings for use by SPMI controllers.  A
+controller is modelled in device tree as a node with zero or more child nodes,
+each representing a unique slave on the bus.
+
+Required properties:
+- #address-cells : must be set to 2
+- #size-cells : must be set to 0
+
+Child nodes:
+
+An SPMI controller node can contain zero or more child nodes representing slave
+devices on the bus.  Child 'reg' properties are specified as an address, type
+pair.  The address must be in the range 0-15 (4 bits).  The type must be one of
+SPMI_USID (0) or SPMI_GSID (1) for Unique Slave ID or Group Slave ID respectively.
+These are the identifiers "statically assigned by the system integrator", as
+per the SPMI spec.
+
+Each child node must have one and only one 'reg' entry of type SPMI_USID.
+
+#include <dt-bindings/spmi/spmi.h>
+
+        spmi@.. {
+                compatible = "...";
+                reg = <...>;
+
+                #address-cells = <2>;
+                #size-cells <0>;
+
+                child@0 {
+                        compatible = "...";
+                        reg = <0 SPMI_USID>;
+                };
+
+                child@7 {
+                        compatible = "...";
+                        reg = <7 SPMI_USID
+                               3 SPMI_GSID>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
index b876d4925a57..3be5ce7a9654 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -1,3 +1,22 @@
+Freescale i.MX DRM master device
+================================
+
+The freescale i.MX DRM master device is a virtual device needed to list all
+IPU or other display interface nodes that comprise the graphics subsystem.
+
+Required properties:
+- compatible: Should be "fsl,imx-display-subsystem"
+- ports: Should contain a list of phandles pointing to display interface ports
+  of IPU devices
+
+example:
+
+display-subsystem {
+        compatible = "fsl,display-subsystem";
+        ports = <&ipu_di0>;
+};
+
+
 Freescale i.MX IPUv3
 ====================
 
@@ -7,18 +26,31 @@ Required properties:
   datasheet
 - interrupts: Should contain sync interrupt and error interrupt,
   in this order.
-- #crtc-cells: 1, See below
 - resets: phandle pointing to the system reset controller and
           reset line index, see reset/fsl,imx-src.txt for details
+Optional properties:
+- port@[0-3]: Port nodes with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
+  Ports 0 and 1 should correspond to CSI0 and CSI1,
+  ports 2 and 3 should correspond to DI0 and DI1, respectively.
 
 example:
 
 ipu: ipu@18000000 {
-        #crtc-cells = <1>;
+        #address-cells = <1>;
+        #size-cells = <0>;
         compatible = "fsl,imx53-ipu";
         reg = <0x18000000 0x080000000>;
         interrupts = <11 10>;
         resets = <&src 2>;
+
+        ipu_di0: port@2 {
+                reg = <2>;
+
+                ipu_di0_disp0: endpoint {
+                        remote-endpoint = <&display_in>;
+                };
+        };
 };
 
 Parallel display support
@@ -26,19 +58,25 @@ Parallel display support
 
 Required properties:
 - compatible: Should be "fsl,imx-parallel-display"
-- crtc: the crtc this display is connected to, see below
 Optional properties:
 - interface_pix_fmt: How this display is connected to the
-  crtc. Currently supported types: "rgb24", "rgb565", "bgr666"
+  display interface. Currently supported types: "rgb24", "rgb565", "bgr666"
 - edid: verbatim EDID data block describing attached display.
 - ddc: phandle describing the i2c bus handling the display data
   channel
+- port: A port node with endpoint definitions as defined in
+  Documentation/devicetree/bindings/media/video-interfaces.txt.
 
 example:
 
 display@di0 {
         compatible = "fsl,imx-parallel-display";
         edid = [edid-data];
-        crtc = <&ipu 0>;
         interface-pix-fmt = "rgb24";
+
+        port {
+                display_in: endpoint {
+                        remote-endpoint = <&ipu_di0_disp0>;
+                };
+        };
 };
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
new file mode 100644
index 000000000000..1b756cf9afb0
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/hdmi.txt
@@ -0,0 +1,58 @@
+Device-Tree bindings for HDMI Transmitter
+
+HDMI Transmitter
+================
+
+The HDMI Transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP
+with accompanying PHY IP.
+
+Required properties:
+ - #address-cells : should be <1>
+ - #size-cells : should be <0>
+ - compatible : should be "fsl,imx6q-hdmi" or "fsl,imx6dl-hdmi".
+ - gpr : should be <&gpr>.
+   The phandle points to the iomuxc-gpr region containing the HDMI
+   multiplexer control register.
+ - clocks, clock-names : phandles to the HDMI iahb and isrf clocks, as described
+   in Documentation/devicetree/bindings/clock/clock-bindings.txt and
+   Documentation/devicetree/bindings/clock/imx6q-clock.txt.
+ - port@[0-4]: Up to four port nodes with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt,
+   corresponding to the four inputs to the HDMI multiplexer.
+
+Optional properties:
+ - ddc-i2c-bus: phandle of an I2C controller used for DDC EDID probing
+
+example:
+
+        gpr: iomuxc-gpr@020e0000 {
+                /* ... */
+        };
+
+        hdmi: hdmi@0120000 {
+                #address-cells = <1>;
+                #size-cells = <0>;
+                compatible = "fsl,imx6q-hdmi";
+                reg = <0x00120000 0x9000>;
+                interrupts = <0 115 0x04>;
+                gpr = <&gpr>;
+                clocks = <&clks 123>, <&clks 124>;
+                clock-names = "iahb", "isfr";
+                ddc-i2c-bus = <&i2c2>;
+
+                port@0 {
+                        reg = <0>;
+
+                        hdmi_mux_0: endpoint {
+                                remote-endpoint = <&ipu1_di0_hdmi>;
+                        };
+                };
+
+                port@1 {
+                        reg = <1>;
+
+                        hdmi_mux_1: endpoint {
+                                remote-endpoint = <&ipu1_di1_hdmi>;
+                        };
+                };
+        };
diff --git a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
index ed9377811ee2..578a1fca366e 100644
--- a/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
+++ b/Documentation/devicetree/bindings/staging/imx-drm/ldb.txt
@@ -50,12 +50,14 @@ have a look at Documentation/devicetree/bindings/video/display-timing.txt.
 
 Required properties:
  - reg : should be <0> or <1>
- - crtcs : a list of phandles with index pointing to the IPU display interfaces
-           that can be used as video source for this channel.
  - fsl,data-mapping : should be "spwg" or "jeida"
                       This describes how the color bits are laid out in the
                       serialized LVDS signal.
  - fsl,data-width : should be <18> or <24>
+ - port: A port node with endpoint definitions as defined in
+   Documentation/devicetree/bindings/media/video-interfaces.txt.
+   On i.MX6, there should be four ports (port@[0-3]) that correspond
+   to the four LVDS multiplexer inputs.
 
 example:
 
@@ -77,23 +79,33 @@ ldb: ldb@53fa8008 {
 
         lvds-channel@0 {
                 reg = <0>;
-                crtcs = <&ipu 0>;
                 fsl,data-mapping = "spwg";
                 fsl,data-width = <24>;
 
                 display-timings {
                         /* ... */
                 };
+
+                port {
+                        lvds0_in: endpoint {
+                                remote-endpoint = <&ipu_di0_lvds0>;
+                        };
+                };
         };
 
         lvds-channel@1 {
                 reg = <1>;
-                crtcs = <&ipu 1>;
                 fsl,data-mapping = "spwg";
                 fsl,data-width = <24>;
 
                 display-timings {
                         /* ... */
                 };
+
+                port {
+                        lvds1_in: endpoint {
+                                remote-endpoint = <&ipu_di1_lvds1>;
+                        };
+                };
         };
 };
diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
index 48aeb7884ed3..5c2e23574ca0 100644
--- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
@@ -2,7 +2,7 @@ Allwinner A1X SoCs Timer Controller
 
 Required properties:
 
-- compatible : should be "allwinner,sun4i-timer"
+- compatible : should be "allwinner,sun4i-a10-timer"
 - reg : Specifies base physical address and size of the registers.
 - interrupts : The interrupt of the first timer
 - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
@@ -10,7 +10,7 @@ Required properties:
 Example:
 
 timer {
-        compatible = "allwinner,sun4i-timer";
+        compatible = "allwinner,sun4i-a10-timer";
         reg = <0x01c20c00 0x400>;
         interrupts = <22>;
         clocks = <&osc>;
diff --git a/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
new file mode 100644
index 000000000000..5fbe361252b4
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/ti,keystone-timer.txt
@@ -0,0 +1,29 @@
+* Device tree bindings for Texas instruments Keystone timer
+
+This document provides bindings for the 64-bit timer in the KeyStone
+architecture devices. The timer can be configured as a general-purpose 64-bit
+timer, dual general-purpose 32-bit timers. When configured as dual 32-bit
+timers, each half can operate in conjunction (chain mode) or independently
+(unchained mode) of each other.
+
+It is global timer is a free running up-counter and can generate interrupt
+when the counter reaches preset counter values.
+
+Documentation:
+http://www.ti.com/lit/ug/sprugv5a/sprugv5a.pdf
+
+Required properties:
+
+- compatible : should be "ti,keystone-timer".
+- reg : specifies base physical address and count of the registers.
+- interrupts : interrupt generated by the timer.
+- clocks : the clock feeding the timer clock.
+
+Example:
+
+timer@22f0000 {
+        compatible = "ti,keystone-timer";
+        reg = <0x022f0000 0x80>;
+        interrupts = <GIC_SPI 110 IRQ_TYPE_EDGE_RISING>;
+        clocks = <&clktimer15>;
+};
diff --git a/Documentation/devicetree/bindings/usb/atmel-usb.txt b/Documentation/devicetree/bindings/usb/atmel-usb.txt
index 55f51af08bc7..bc2222ca3f2a 100644
--- a/Documentation/devicetree/bindings/usb/atmel-usb.txt
+++ b/Documentation/devicetree/bindings/usb/atmel-usb.txt
@@ -57,8 +57,8 @@ Required properties:
  - ep childnode: To specify the number of endpoints and their properties.
 
 Optional properties:
- - atmel,vbus-gpio: If present, specifies a gpio that needs to be
-   activated for the bus to be powered.
+ - atmel,vbus-gpio: If present, specifies a gpio that allows to detect whether
+   vbus is present (USB is connected).
 
 Required child node properties:
  - name: Name of the endpoint.
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
index b4b5b7906c88..a6a32cb7f777 100644
--- a/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-imx.txt
@@ -18,6 +18,7 @@ Optional properties:
 - vbus-supply: regulator for vbus
 - disable-over-current: disable over current detect
 - external-vbus-divider: enables off-chip resistor divider for Vbus
+- maximum-speed: limit the maximum connection speed to "full-speed".
 
 Examples:
 usb@02184000 { /* USB OTG */
@@ -28,4 +29,5 @@ usb@02184000 { /* USB OTG */
         fsl,usbmisc = <&usbmisc 0>;
         disable-over-current;
         external-vbus-divider;
+        maximum-speed = "full-speed";
 };
diff --git a/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt b/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
new file mode 100644
index 000000000000..abbcb2aea38c
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/ci-hdrc-zevio.txt
@@ -0,0 +1,17 @@
+* LSI Zevio USB OTG Controller
+
+Required properties:
+- compatible: Should be "lsi,zevio-usb"
+- reg: Should contain registers location and length
+- interrupts: Should contain controller interrupt
+
+Optional properties:
+- vbus-supply: regulator for vbus
+
+Examples:
+                usb0: usb@b0000000 {
+                        reg = <0xb0000000 0x1000>;
+                        compatible = "lsi,zevio-usb";
+                        interrupts = <8>;
+                        vbus-supply = <&vbus_reg>;
+                };
diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt b/Documentation/devicetree/bindings/usb/dwc3.txt
index e807635f9e1c..471366d6a129 100644
--- a/Documentation/devicetree/bindings/usb/dwc3.txt
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -6,11 +6,13 @@ Required properties:
  - compatible: must be "snps,dwc3"
  - reg : Address and length of the register set for the device
  - interrupts: Interrupts used by the dwc3 controller.
+
+Optional properties:
  - usb-phy : array of phandle for the PHY device.  The first element
    in the array is expected to be a handle to the USB2/HS PHY and
    the second element is expected to be a handle to the USB3/SS PHY
-
-Optional properties:
+ - phys: from the *Generic PHY* bindings
+ - phy-names: from the *Generic PHY* bindings
  - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
 
 This is usually a subnode to DWC3 glue to which it is connected.
diff --git a/Documentation/devicetree/bindings/usb/ehci-omap.txt b/Documentation/devicetree/bindings/usb/ehci-omap.txt
index 485a9a1efa7a..3dc231c832b0 100644
--- a/Documentation/devicetree/bindings/usb/ehci-omap.txt
+++ b/Documentation/devicetree/bindings/usb/ehci-omap.txt
@@ -21,7 +21,7 @@ Documentation/devicetree/bindings/mfd/omap-usb-host.txt
 Example for OMAP4:
 
 usbhsehci: ehci@4a064c00 {
-        compatible = "ti,ehci-omap", "usb-ehci";
+        compatible = "ti,ehci-omap";
         reg = <0x4a064c00 0x400>;
         interrupts = <0 77 0x4>;
 };
diff --git a/Documentation/devicetree/bindings/usb/fsl-usb.txt b/Documentation/devicetree/bindings/usb/fsl-usb.txt
index bd5723f0b67e..4779c029b675 100644
--- a/Documentation/devicetree/bindings/usb/fsl-usb.txt
+++ b/Documentation/devicetree/bindings/usb/fsl-usb.txt
@@ -8,7 +8,9 @@ and additions :
 Required properties :
  - compatible : Should be "fsl-usb2-mph" for multi port host USB
    controllers, or "fsl-usb2-dr" for dual role USB controllers
-   or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121
+   or "fsl,mpc5121-usb2-dr" for dual role USB controllers of MPC5121.
+   Wherever applicable, the IP version of the USB controller should
+   also be mentioned (for eg. fsl-usb2-dr-v2.2 for bsc9132).
  - phy_type : For multi port host USB controllers, should be one of
    "ulpi", or "serial". For dual role USB controllers, should be
    one of "ulpi", "utmi", "utmi_wide", or "serial".
diff --git a/Documentation/devicetree/bindings/usb/mxs-phy.txt b/Documentation/devicetree/bindings/usb/mxs-phy.txt
index 5835b27146ea..cef181a9d8bd 100644
--- a/Documentation/devicetree/bindings/usb/mxs-phy.txt
+++ b/Documentation/devicetree/bindings/usb/mxs-phy.txt
@@ -1,13 +1,19 @@
 * Freescale MXS USB Phy Device
 
 Required properties:
-- compatible: Should be "fsl,imx23-usbphy"
+- compatible: should contain:
+        * "fsl,imx23-usbphy" for imx23 and imx28
+        * "fsl,imx6q-usbphy" for imx6dq and imx6dl
+        * "fsl,imx6sl-usbphy" for imx6sl
+  "fsl,imx23-usbphy" is still a fallback for other strings
 - reg: Should contain registers location and length
 - interrupts: Should contain phy interrupt
+- fsl,anatop: phandle for anatop register, it is only for imx6 SoC series
 
 Example:
 usbphy1: usbphy@020c9000 {
         compatible = "fsl,imx6q-usbphy", "fsl,imx23-usbphy";
         reg = <0x020c9000 0x1000>;
         interrupts = <0 44 0x04>;
+        fsl,anatop = <&anatop>;
 };
diff --git a/Documentation/devicetree/bindings/usb/ohci-omap3.txt b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
index 14ab42812a8e..ce8c47cff6d0 100644
--- a/Documentation/devicetree/bindings/usb/ohci-omap3.txt
+++ b/Documentation/devicetree/bindings/usb/ohci-omap3.txt
@@ -9,7 +9,7 @@ Required properties:
 Example for OMAP4:
 
 usbhsohci: ohci@4a064800 {
-        compatible = "ti,ohci-omap3", "usb-ohci";
+        compatible = "ti,ohci-omap3";
         reg = <0x4a064800 0x400>;
         interrupts = <0 76 0x4>;
 };
diff --git a/Documentation/devicetree/bindings/usb/omap-usb.txt b/Documentation/devicetree/bindings/usb/omap-usb.txt
index c495135115cb..38b2faec4199 100644
--- a/Documentation/devicetree/bindings/usb/omap-usb.txt
+++ b/Documentation/devicetree/bindings/usb/omap-usb.txt
@@ -76,27 +76,3 @@ omap_dwc3 {
         ranges;
 };
 
-OMAP CONTROL USB
-
-Required properties:
- - compatible: Should be one of
- "ti,control-phy-otghs" - if it has otghs_control mailbox register as on OMAP4.
- "ti,control-phy-usb2" - if it has Power down bit in control_dev_conf register
-                        e.g. USB2_PHY on OMAP5.
- "ti,control-phy-pipe3" - if it has DPLL and individual Rx & Tx power control
-                        e.g. USB3 PHY and SATA PHY on OMAP5.
- "ti,control-phy-dra7usb2" - if it has power down register like USB2 PHY on
-                        DRA7 platform.
- "ti,control-phy-am437usb2" - if it has power down register like USB2 PHY on
-                        AM437 platform.
- - reg : Address and length of the register set for the device. It contains
-   the address of "otghs_control" for control-phy-otghs or "power" register
-   for other types.
- - reg-names: should be "otghs_control" control-phy-otghs and "power" for
-   other types.
-
-omap_control_usb: omap-control-usb@4a002300 {
-        compatible = "ti,control-phy-otghs";
-        reg = <0x4a00233c 0x4>;
-        reg-names = "otghs_control";
-};
diff --git a/Documentation/devicetree/bindings/usb/usb-ehci.txt b/Documentation/devicetree/bindings/usb/usb-ehci.txt
index fa18612f757b..ff151ec084c4 100644
--- a/Documentation/devicetree/bindings/usb/usb-ehci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-ehci.txt
@@ -1,19 +1,20 @@
 USB EHCI controllers
 
 Required properties:
-  - compatible : should be "usb-ehci".
+  - compatible : should be "generic-ehci".
   - reg : should contain at least address and length of the standard EHCI
     register set for the device. Optional platform-dependent registers
     (debug-port or other) can be also specified here, but only after
     definition of standard EHCI registers.
   - interrupts : one EHCI interrupt should be described here.
-If device registers are implemented in big endian mode, the device
-node should have "big-endian-regs" property.
-If controller implementation operates with big endian descriptors,
-"big-endian-desc" property should be specified.
-If both big endian registers and descriptors are used by the controller
-implementation, "big-endian" property can be specified instead of having
-both "big-endian-regs" and "big-endian-desc".
+
+Optional properties:
+ - big-endian-regs : boolean, set this for hcds with big-endian registers
+ - big-endian-desc : boolean, set this for hcds with big-endian descriptors
+ - big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
+ - clocks : a list of phandle + clock specifier pairs
+ - phys : phandle + phy specifier pair
+ - phy-names : "usb"
 
 Example (Sequoia 440EPx):
     ehci@e0000300 {
@@ -23,3 +24,13 @@ Example (Sequoia 440EPx):
            reg = <0 e0000300 90 0 e0000390 70>;
            big-endian;
    };
+
+Example (Allwinner sun4i A10 SoC):
+   ehci0: usb@01c14000 {
+           compatible = "allwinner,sun4i-a10-ehci", "generic-ehci";
+           reg = <0x01c14000 0x100>;
+           interrupts = <39>;
+           clocks = <&ahb_gates 1>;
+           phys = <&usbphy 1>;
+           phy-names = "usb";
+   };
diff --git a/Documentation/devicetree/bindings/usb/usb-ohci.txt b/Documentation/devicetree/bindings/usb/usb-ohci.txt
new file mode 100644
index 000000000000..45f67d91e888
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/usb-ohci.txt
@@ -0,0 +1,25 @@
+USB OHCI controllers
+
+Required properties:
+- compatible : "generic-ohci"
+- reg : ohci controller register range (address and length)
+- interrupts : ohci controller interrupt
+
+Optional properties:
+- big-endian-regs : boolean, set this for hcds with big-endian registers
+- big-endian-desc : boolean, set this for hcds with big-endian descriptors
+- big-endian : boolean, for hcds with big-endian-regs + big-endian-desc
+- clocks : a list of phandle + clock specifier pairs
+- phys : phandle + phy specifier pair
+- phy-names : "usb"
+
+Example:
+
+        ohci0: usb@01c14400 {
+                compatible = "allwinner,sun4i-a10-ohci", "generic-ohci";
+                reg = <0x01c14400 0x100>;
+                interrupts = <64>;
+                clocks = <&usb_clk 6>, <&ahb_gates 2>;
+                phys = <&usbphy 1>;
+                phy-names = "usb";
+        };
diff --git a/Documentation/devicetree/bindings/usb/usb-phy.txt b/Documentation/devicetree/bindings/usb/usb-phy.txt
deleted file mode 100644
index c0245c888982..000000000000
--- a/Documentation/devicetree/bindings/usb/usb-phy.txt
+++ /dev/null
@@ -1,48 +0,0 @@
-USB PHY
-
-OMAP USB2 PHY
-
-Required properties:
- - compatible: Should be "ti,omap-usb2"
- - reg : Address and length of the register set for the device.
- - #phy-cells: determine the number of cells that should be given in the
-   phandle while referencing this phy.
-
-Optional properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
-   the PHY.
-
-This is usually a subnode of ocp2scp to which it is connected.
-
-usb2phy@4a0ad080 {
-        compatible = "ti,omap-usb2";
-        reg = <0x4a0ad080 0x58>;
-        ctrl-module = <&omap_control_usb>;
-        #phy-cells = <0>;
-};
-
-OMAP USB3 PHY
-
-Required properties:
- - compatible: Should be "ti,omap-usb3"
- - reg : Address and length of the register set for the device.
- - reg-names: The names of the register addresses corresponding to the registers
-   filled in "reg".
- - #phy-cells: determine the number of cells that should be given in the
-   phandle while referencing this phy.
-
-Optional properties:
- - ctrl-module : phandle of the control module used by PHY driver to power on
-   the PHY.
-
-This is usually a subnode of ocp2scp to which it is connected.
-
-usb3phy@4a084400 {
-        compatible = "ti,omap-usb3";
-        reg = <0x4a084400 0x80>,
-              <0x4a084800 0x64>,
-              <0x4a084c00 0x40>;
-        reg-names = "phy_rx", "phy_tx", "pll_ctrl";
-        ctrl-module = <&omap_control_usb>;
-        #phy-cells = <0>;
-};
diff --git a/Documentation/devicetree/bindings/usb/platform-uhci.txt b/Documentation/devicetree/bindings/usb/usb-uhci.txt
index a4fb0719d157..298133416c97 100644
--- a/Documentation/devicetree/bindings/usb/platform-uhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-uhci.txt
@@ -2,14 +2,14 @@ Generic Platform UHCI Controller
 -----------------------------------------------------
 
 Required properties:
-- compatible : "platform-uhci"
+- compatible : "generic-uhci" (deprecated: "platform-uhci")
 - reg : Should contain 1 register ranges(address and length)
 - interrupts : UHCI controller interrupt
 
 Example:
 
         uhci@d8007b00 {
-                compatible = "platform-uhci";
+                compatible = "generic-uhci";
                 reg = <0xd8007b00 0x200>;
                 interrupts = <43>;
         };
diff --git a/Documentation/devicetree/bindings/usb/usb-xhci.txt b/Documentation/devicetree/bindings/usb/usb-xhci.txt
index 5752df0e17a2..90f8f607d125 100644
--- a/Documentation/devicetree/bindings/usb/usb-xhci.txt
+++ b/Documentation/devicetree/bindings/usb/usb-xhci.txt
@@ -1,14 +1,14 @@
 USB xHCI controllers
 
 Required properties:
-  - compatible: should be "xhci-platform".
+  - compatible: should be "generic-xhci" (deprecated: "xhci-platform").
   - reg: should contain address and length of the standard XHCI
     register set for the device.
   - interrupts: one XHCI interrupt should be described here.
 
 Example:
         usb@f0931000 {
-                compatible = "xhci-platform";
+                compatible = "generic-xhci";
                 reg = <0xf0931000 0x8c8>;
                 interrupts = <0x0 0x4e 0x0>;
         };
diff --git a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt b/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
deleted file mode 100644
index 17b3ad1d97e7..000000000000
--- a/Documentation/devicetree/bindings/usb/via,vt8500-ehci.txt
+++ /dev/null
@@ -1,15 +0,0 @@
-VIA/Wondermedia VT8500 EHCI Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-ehci"
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : ehci controller interrupt
-
-Example:
-
-        ehci@d8007900 {
-                compatible = "via,vt8500-ehci";
-                reg = <0xd8007900 0x200>;
-                interrupts = <43>;
-        };
diff --git a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt b/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
deleted file mode 100644
index 5fb8fd6e250c..000000000000
--- a/Documentation/devicetree/bindings/usb/vt8500-ehci.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-VIA VT8500 and Wondermedia WM8xxx SoC USB controllers.
-
-Required properties:
- - compatible: Should be "via,vt8500-ehci" or "wm,prizm-ehci".
- - reg: Address range of the ehci registers. size should be 0x200
- - interrupts: Should contain the ehci interrupt.
-
-usb: ehci@D8007100 {
-        compatible = "wm,prizm-ehci", "usb-ehci";
-        reg = <0xD8007100 0x200>;
-        interrupts = <1>;
-};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 40ce2df0e0e9..0f01c9bf19c8 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -3,6 +3,7 @@ Device tree binding vendor prefix registry.  Keep list in alphabetical order.
 This isn't an exhaustive list, but you should add new prefixes to it before
 using them to avoid name-space collisions.
 
+abilis  Abilis Systems
 active-semi     Active-Semi International Inc
 ad      Avionic Design GmbH
 adi     Analog Devices, Inc.
@@ -11,14 +12,17 @@ ak	Asahi Kasei Corp.
 allwinner       Allwinner Technology Co., Ltd.
 altr    Altera Corp.
 amcc    Applied Micro Circuits Corporation (APM, formally AMCC)
+amd     Advanced Micro Devices (AMD), Inc.
 amstaos AMS-Taos Inc.
 apm     Applied Micro Circuits Corporation (APM)
 arm     ARM Ltd.
+armadeus        ARMadeus Systems SARL
 atmel   Atmel Corporation
 auo     AU Optronics Corporation
 avago   Avago Technologies
 bosch   Bosch Sensortec GmbH
 brcm    Broadcom Corporation
+calxeda Calxeda
 capella Capella Microsystems, Inc
 cavium  Cavium, Inc.
 cdns    Cadence Design Systems Inc.
@@ -26,18 +30,24 @@ chrp	Common Hardware Reference Platform
 chunghwa        Chunghwa Picture Tubes Ltd.
 cirrus  Cirrus Logic, Inc.
 cortina Cortina Systems, Inc.
+crystalfontz    Crystalfontz America, Inc.
 dallas  Maxim Integrated Products (formerly Dallas Semiconductor)
 davicom DAVICOM Semiconductor, Inc.
+dlink   D-Link Systems, Inc.
 denx    Denx Software Engineering
+dmo     Data Modul AG
 edt     Emerging Display Technologies
 emmicro EM Microelectronic
 epfl    Ecole Polytechnique Fédérale de Lausanne
 epson   Seiko Epson Corp.
 est     ESTeem Wireless Modems
+eukrea  Eukréa Electromatique
 fsl     Freescale Semiconductor
 GEFanuc GE Fanuc Intelligent Platforms Embedded Systems, Inc.
 gef     GE Fanuc Intelligent Platforms Embedded Systems, Inc.
+globalscale     Globalscale Technologies, Inc.
 gmt     Global Mixed-mode Technology, Inc.
+google  Google, Inc.
 gumstix Gumstix, Inc.
 haoyu   Haoyu Microelectronic Co. Ltd.
 hisilicon       Hisilicon Limited.
@@ -46,9 +56,12 @@ hp	Hewlett Packard
 ibm     International Business Machines (IBM)
 idt     Integrated Device Technologies, Inc.
 img     Imagination Technologies Ltd.
+intel   Intel Corporation
 intercontrol    Inter Control Group
 isl     Intersil
 karo    Ka-Ro electronics GmbH
+lacie   LaCie
+lantiq  Lantiq Semiconductor
 lg      LG Corporation
 linux   Linux-specific binding
 lsi     LSI Corp. (LSI Logic)
@@ -56,22 +69,28 @@ marvell	Marvell Technology Group Ltd.
 maxim   Maxim Integrated Products
 microchip       Microchip Technology Inc.
 mosaixtech      Mosaix Technologies, Inc.
+moxa    Moxa
 national        National Semiconductor
 neonode         Neonode Inc.
+netgear NETGEAR
 nintendo        Nintendo
+nokia   Nokia
 nvidia  NVIDIA
 nxp     NXP Semiconductors
 onnn    ON Semiconductor Corp.
+opencores       OpenCores.org
 panasonic       Panasonic Corporation
 phytec  PHYTEC Messtechnik GmbH
 picochip        Picochip Ltd
 powervr PowerVR (deprecated, use img)
 qca     Qualcomm Atheros, Inc.
 qcom    Qualcomm Technologies, Inc
+qnap    QNAP Systems, Inc.
 ralink  Mediatek/Ralink Technology Corp.
 ramtron Ramtron International
 realtek Realtek Semiconductor Corp.
 renesas Renesas Electronics Corporation
+ricoh   Ricoh Co. Ltd.
 rockchip        Fuzhou Rockchip Electronics Co., Ltd
 samsung Samsung Semiconductor
 sbs     Smart Battery System
@@ -79,19 +98,24 @@ schindler	Schindler
 sil     Silicon Image
 silabs  Silicon Laboratories
 simtek
+sii     Seiko Instruments, Inc.
 sirf    SiRF Technology, Inc.
+smsc    Standard Microsystems Corporation
 snps    Synopsys, Inc.
 spansion        Spansion Inc.
 st      STMicroelectronics
 ste     ST-Ericsson
 stericsson      ST-Ericsson
+synology        Synology, Inc.
 ti      Texas Instruments
 tlm     Trusted Logic Mobility
 toshiba Toshiba Corporation
 toumaz  Toumaz
 v3      V3 Semiconductor
 via     VIA Technologies, Inc.
+voipac  Voipac Technologies s.r.o.
 winbond Winbond Electronics corp.
 wlf     Wolfson Microelectronics
 wm      Wondermedia Technologies, Inc.
+xes     Extreme Engineering Solutions (X-ES)
 xlnx    Xilinx
diff --git a/Documentation/devicetree/bindings/video/analog-tv-connector.txt b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
new file mode 100644
index 000000000000..0218fcdc1299
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/analog-tv-connector.txt
@@ -0,0 +1,25 @@
+Analog TV Connector
+===================
+
+Required properties:
+- compatible: "composite-connector" or "svideo-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for TV input
+
+Example
+-------
+
+tv: connector {
+        compatible = "composite-connector";
+        label = "tv";
+
+        port {
+                tv_connector_in: endpoint {
+                        remote-endpoint = <&venc_out>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/dvi-connector.txt b/Documentation/devicetree/bindings/video/dvi-connector.txt
new file mode 100644
index 000000000000..fc53f7c60bc6
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/dvi-connector.txt
@@ -0,0 +1,35 @@
+DVI Connector
+==============
+
+Required properties:
+- compatible: "dvi-connector"
+
+Optional properties:
+- label: a symbolic name for the connector
+- ddc-i2c-bus: phandle to the i2c bus that is connected to DVI DDC
+- analog: the connector has DVI analog pins
+- digital: the connector has DVI digital pins
+- dual-link: the connector has pins for DVI dual-link
+
+Required nodes:
+- Video port for DVI input
+
+Note: One (or both) of 'analog' or 'digital' must be set.
+
+Example
+-------
+
+dvi0: connector@0 {
+        compatible = "dvi-connector";
+        label = "dvi";
+
+        digital;
+
+        ddc-i2c-bus = <&i2c3>;
+
+        port {
+                dvi_connector_in: endpoint {
+                        remote-endpoint = <&tfp410_out>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
index 46da08db186a..0329f60d431e 100644
--- a/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
+++ b/Documentation/devicetree/bindings/video/fsl,imx-fb.txt
@@ -15,8 +15,12 @@ Required nodes:
         - fsl,pcr: LCDC PCR value
 
 Optional properties:
+- lcd-supply: Regulator for LCD supply voltage.
 - fsl,dmacr: DMA Control Register value. This is optional. By default, the
         register is not modified as recommended by the datasheet.
+- fsl,lpccr: Contrast Control Register value. This property provides the
+        default value for the contrast control register.
+        If that property is ommited, the register is zeroed.
 - fsl,lscr1: LCDC Sharp Configuration Register value.
 
 Example:
diff --git a/Documentation/devicetree/bindings/video/hdmi-connector.txt b/Documentation/devicetree/bindings/video/hdmi-connector.txt
new file mode 100644
index 000000000000..ccccc19e2573
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/hdmi-connector.txt
@@ -0,0 +1,28 @@
+HDMI Connector
+==============
+
+Required properties:
+- compatible: "hdmi-connector"
+- type: the HDMI connector type: "a", "b", "c", "d" or "e"
+
+Optional properties:
+- label: a symbolic name for the connector
+
+Required nodes:
+- Video port for HDMI input
+
+Example
+-------
+
+hdmi0: connector@1 {
+        compatible = "hdmi-connector";
+        label = "hdmi";
+
+        type = "a";
+
+        port {
+                hdmi_connector_in: endpoint {
+                        remote-endpoint = <&tpd12s015_out>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/panel-dsi-cm.txt b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
new file mode 100644
index 000000000000..dce48eb9db57
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/panel-dsi-cm.txt
@@ -0,0 +1,29 @@
+Generic MIPI DSI Command Mode Panel
+===================================
+
+Required properties:
+- compatible: "panel-dsi-cm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- reset-gpios: panel reset gpio
+- te-gpios: panel TE gpio
+
+Required nodes:
+- Video port for DSI input
+
+Example
+-------
+
+lcd0: display {
+        compatible = "tpo,taal", "panel-dsi-cm";
+        label = "lcd0";
+
+        reset-gpios = <&gpio4 6 GPIO_ACTIVE_HIGH>;
+
+        port {
+                lcd0_in: endpoint {
+                        remote-endpoint = <&dsi1_out_ep>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/sony,acx565akm.txt b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
new file mode 100644
index 000000000000..e12333280749
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sony,acx565akm.txt
@@ -0,0 +1,30 @@
+Sony ACX565AKM SDI Panel
+========================
+
+Required properties:
+- compatible: "sony,acx565akm"
+
+Optional properties:
+- label: a symbolic name for the panel
+- reset-gpios: panel reset gpio
+
+Required nodes:
+- Video port for SDI input
+
+Example
+-------
+
+acx565akm@2 {
+        compatible = "sony,acx565akm";
+        spi-max-frequency = <6000000>;
+        reg = <2>;
+
+        label = "lcd";
+        reset-gpios = <&gpio3 26 GPIO_ACTIVE_HIGH>; /* 90 */
+
+        port {
+                lcd_in: endpoint {
+                        remote-endpoint = <&sdi_out>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap-dss.txt b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
new file mode 100644
index 000000000000..d5f1a3fe3109
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap-dss.txt
@@ -0,0 +1,211 @@
+Texas Instruments OMAP Display Subsystem
+========================================
+
+Generic Description
+-------------------
+
+This document is a generic description of the OMAP Display Subsystem bindings.
+Binding details for each OMAP SoC version are described in respective binding
+documentation.
+
+The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and
+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but
+the encoder modules vary.
+
+The DSS Core is the parent of the other DSS modules, and manages clock routing,
+integration to the SoC, etc.
+
+DISPC is the display controller, which reads pixels from the memory and outputs
+a RGB pixel stream to encoders.
+
+The encoder modules encode the received RGB pixel stream to a video output like
+HDMI, MIPI DPI, etc.
+
+Video Ports
+-----------
+
+The DSS Core and the encoders have video port outputs. The structure of the
+video ports is described in Documentation/devicetree/bindings/video/video-
+ports.txt, and the properties for the ports and endpoints for each encoder are
+described in the SoC's DSS binding documentation.
+
+The video ports are used to describe the connections to external hardware, like
+panels or external encoders.
+
+Aliases
+-------
+
+The board dts file may define aliases for displays to assign "displayX" style
+name for each display. If no aliases are defined, a semi-random number is used
+for the display.
+
+Example
+-------
+
+A shortened example of the DSS description for OMAP4, with non-relevant parts
+removed, defined in omap4.dtsi:
+
+dss: dss@58000000 {
+        compatible = "ti,omap4-dss";
+        reg = <0x58000000 0x80>;
+        status = "disabled";
+        ti,hwmods = "dss_core";
+        clocks = <&dss_dss_clk>;
+        clock-names = "fck";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        ranges;
+
+        dispc@58001000 {
+                compatible = "ti,omap4-dispc";
+                reg = <0x58001000 0x1000>;
+                interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;
+                ti,hwmods = "dss_dispc";
+                clocks = <&dss_dss_clk>;
+                clock-names = "fck";
+        };
+
+        hdmi: encoder@58006000 {
+                compatible = "ti,omap4-hdmi";
+                reg = <0x58006000 0x200>,
+                      <0x58006200 0x100>,
+                      <0x58006300 0x100>,
+                      <0x58006400 0x1000>;
+                reg-names = "wp", "pll", "phy", "core";
+                interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
+                status = "disabled";
+                ti,hwmods = "dss_hdmi";
+                clocks = <&dss_48mhz_clk>, <&dss_sys_clk>;
+                clock-names = "fck", "sys_clk";
+        };
+};
+
+A shortened example of the board description for OMAP4 Panda board, defined in
+omap4-panda.dts.
+
+The Panda board has a DVI and a HDMI connector, and the board contains a TFP410
+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level
+shifter). The video pipelines for the connectors are formed as follows:
+
+DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector
+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI Connector
+
+/ {
+        aliases {
+                display0 = &dvi0;
+                display1 = &hdmi0;
+        };
+
+        tfp410: encoder@0 {
+                compatible = "ti,tfp410";
+                gpios = <&gpio1 0 GPIO_ACTIVE_LOW>;     /* 0, power-down */
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&tfp410_pins>;
+
+                ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        port@0 {
+                                reg = <0>;
+
+                                tfp410_in: endpoint@0 {
+                                        remote-endpoint = <&dpi_out>;
+                                };
+                        };
+
+                        port@1 {
+                                reg = <1>;
+
+                                tfp410_out: endpoint@0 {
+                                        remote-endpoint = <&dvi_connector_in>;
+                                };
+                        };
+                };
+        };
+
+        dvi0: connector@0 {
+                compatible = "dvi-connector";
+                label = "dvi";
+
+                i2c-bus = <&i2c3>;
+
+                port {
+                        dvi_connector_in: endpoint {
+                                remote-endpoint = <&tfp410_out>;
+                        };
+                };
+        };
+
+        tpd12s015: encoder@1 {
+                compatible = "ti,tpd12s015";
+
+                pinctrl-names = "default";
+                pinctrl-0 = <&tpd12s015_pins>;
+
+                gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,   /* 60, CT CP HPD */
+                        <&gpio2 9 GPIO_ACTIVE_HIGH>,    /* 41, LS OE */
+                        <&gpio2 31 GPIO_ACTIVE_HIGH>;   /* 63, HPD */
+
+                ports {
+                        #address-cells = <1>;
+                        #size-cells = <0>;
+
+                        port@0 {
+                                reg = <0>;
+
+                                tpd12s015_in: endpoint@0 {
+                                        remote-endpoint = <&hdmi_out>;
+                                };
+                        };
+
+                        port@1 {
+                                reg = <1>;
+
+                                tpd12s015_out: endpoint@0 {
+                                        remote-endpoint = <&hdmi_connector_in>;
+                                };
+                        };
+                };
+        };
+
+        hdmi0: connector@1 {
+                compatible = "hdmi-connector";
+                label = "hdmi";
+
+                port {
+                        hdmi_connector_in: endpoint {
+                                remote-endpoint = <&tpd12s015_out>;
+                        };
+                };
+        };
+};
+
+&dss {
+        status = "ok";
+
+        pinctrl-names = "default";
+        pinctrl-0 = <&dss_dpi_pins>;
+
+        port {
+                dpi_out: endpoint {
+                        remote-endpoint = <&tfp410_in>;
+                        data-lines = <24>;
+                };
+        };
+};
+
+&hdmi {
+        status = "ok";
+        vdda-supply = <&vdac>;
+
+        pinctrl-names = "default";
+        pinctrl-0 = <&dss_hdmi_pins>;
+
+        port {
+                hdmi_out: endpoint {
+                        remote-endpoint = <&tpd12s015_in>;
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,omap2-dss.txt b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
new file mode 100644
index 000000000000..fa8bb2ed1170
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap2-dss.txt
@@ -0,0 +1,54 @@
+Texas Instruments OMAP2 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap2-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+
+Optional nodes:
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap2-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap2-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap2-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+
+VENC Endpoint required properties:
+
+Required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
diff --git a/Documentation/devicetree/bindings/video/ti,omap3-dss.txt b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
new file mode 100644
index 000000000000..0023fa4b1328
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap3-dss.txt
@@ -0,0 +1,83 @@
+Texas Instruments OMAP3 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap3-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video ports:
+        - Port 0: DPI output
+        - Port 1: SDI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+SDI Endpoint required properties:
+- datapairs: number of datapairs used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap3-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap3-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap3-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap3-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+  DATA1+, DATA1-, ...
diff --git a/Documentation/devicetree/bindings/video/ti,omap4-dss.txt b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
new file mode 100644
index 000000000000..f85d6fcfa705
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,omap4-dss.txt
@@ -0,0 +1,111 @@
+Texas Instruments OMAP4 Display Subsystem
+=========================================
+
+See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic
+description about OMAP Display Subsystem bindings.
+
+DSS Core
+--------
+
+Required properties:
+- compatible: "ti,omap4-dss"
+- reg: address and length of the register space
+- ti,hwmods: "dss_core"
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Required nodes:
+- DISPC
+
+Optional nodes:
+- DSS Submodules: RFBI, VENC, DSI, HDMI
+- Video port for DPI output
+
+DPI Endpoint required properties:
+- data-lines: number of lines used
+
+
+DISPC
+-----
+
+Required properties:
+- compatible: "ti,omap4-dispc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_dispc"
+- interrupts: the DISPC interrupt
+- clocks: handle to fclk
+- clock-names: "fck"
+
+
+RFBI
+----
+
+Required properties:
+- compatible: "ti,omap4-rfbi"
+- reg: address and length of the register space
+- ti,hwmods: "dss_rfbi"
+- clocks: handles to fclk and iclk
+- clock-names: "fck", "ick"
+
+Optional nodes:
+- Video port for RFBI output
+- RFBI controlled peripherals
+
+
+VENC
+----
+
+Required properties:
+- compatible: "ti,omap4-venc"
+- reg: address and length of the register space
+- ti,hwmods: "dss_venc"
+- vdda-supply: power supply for DAC
+- clocks: handle to fclk
+- clock-names: "fck"
+
+Optional nodes:
+- Video port for VENC output
+
+VENC Endpoint required properties:
+- ti,invert-polarity: invert the polarity of the video signal
+- ti,channels: 1 for composite, 2 for s-video
+
+
+DSI
+---
+
+Required properties:
+- compatible: "ti,omap4-dsi"
+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'
+- reg-names: "proto", "phy", "pll"
+- interrupts: the DSI interrupt line
+- ti,hwmods: "dss_dsi1" or "dss_dsi2"
+- vdd-supply: power supply for DSI
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for DSI output
+- DSI controlled peripherals
+
+DSI Endpoint required properties:
+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,
+  DATA1+, DATA1-, ...
+
+
+HDMI
+----
+
+Required properties:
+- compatible: "ti,omap4-hdmi"
+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',
+       'core'
+- reg-names: "wp", "pll", "phy", "core"
+- interrupts: the HDMI interrupt line
+- ti,hwmods: "dss_hdmi"
+- vdda-supply: vdda power supply
+- clocks: handles to fclk and pll clock
+- clock-names: "fck", "sys_clk"
+
+Optional nodes:
+- Video port for HDMI output
diff --git a/Documentation/devicetree/bindings/video/ti,tfp410.txt b/Documentation/devicetree/bindings/video/ti,tfp410.txt
new file mode 100644
index 000000000000..2cbe32a3d0bb
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tfp410.txt
@@ -0,0 +1,41 @@
+TFP410 DPI to DVI encoder
+=========================
+
+Required properties:
+- compatible: "ti,tfp410"
+
+Optional properties:
+- powerdown-gpios: power-down gpio
+
+Required nodes:
+- Video port 0 for DPI input
+- Video port 1 for DVI output
+
+Example
+-------
+
+tfp410: encoder@0 {
+        compatible = "ti,tfp410";
+        powerdown-gpios = <&twl_gpio 2 GPIO_ACTIVE_LOW>;
+
+        ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                        reg = <0>;
+
+                        tfp410_in: endpoint@0 {
+                                remote-endpoint = <&dpi_out>;
+                        };
+                };
+
+                port@1 {
+                        reg = <1>;
+
+                        tfp410_out: endpoint@0 {
+                                remote-endpoint = <&dvi_connector_in>;
+                        };
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/video/ti,tpd12s015.txt b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
new file mode 100644
index 000000000000..26e6d32e3f20
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/ti,tpd12s015.txt
@@ -0,0 +1,44 @@
+TPD12S015 HDMI level shifter and ESD protection chip
+====================================================
+
+Required properties:
+- compatible: "ti,tpd12s015"
+
+Optional properties:
+- gpios: CT CP HPD, LS OE and HPD gpios
+
+Required nodes:
+- Video port 0 for HDMI input
+- Video port 1 for HDMI output
+
+Example
+-------
+
+tpd12s015: encoder@1 {
+        compatible = "ti,tpd12s015";
+
+        gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>,   /* 60, CT CP HPD */
+                <&gpio2 9 GPIO_ACTIVE_HIGH>,    /* 41, LS OE */
+                <&gpio2 31 GPIO_ACTIVE_HIGH>;   /* 63, HPD */
+
+        ports {
+                #address-cells = <1>;
+                #size-cells = <0>;
+
+                port@0 {
+                        reg = <0>;
+
+                        tpd12s015_in: endpoint@0 {
+                                remote-endpoint = <&hdmi_out>;
+                        };
+                };
+
+                port@1 {
+                        reg = <1>;
+
+                        tpd12s015_out: endpoint@0 {
+                                remote-endpoint = <&hdmi_connector_in>;
+                        };
+                };
+        };
+};
diff --git a/Documentation/devicetree/bindings/watchdog/marvel.txt b/Documentation/devicetree/bindings/watchdog/marvel.txt
index 5dc8d30061ce..de11eb4c121f 100644
--- a/Documentation/devicetree/bindings/watchdog/marvel.txt
+++ b/Documentation/devicetree/bindings/watchdog/marvel.txt
@@ -3,17 +3,24 @@
 Required Properties:
 
 - Compatibility : "marvell,orion-wdt"
-- reg           : Address of the timer registers
+                  "marvell,armada-370-wdt"
+                  "marvell,armada-xp-wdt"
+
+- reg           : Should contain two entries: first one with the
+                  timer control address, second one with the
+                  rstout enable address.
 
 Optional properties:
 
+- interrupts    : Contains the IRQ for watchdog expiration
 - timeout-sec   : Contains the watchdog timeout in seconds
 
 Example:
 
         wdt@20300 {
                 compatible = "marvell,orion-wdt";
-                reg = <0x20300 0x28>;
+                reg = <0x20300 0x28>, <0x20108 0x4>;
+                interrupts = <3>;
                 timeout-sec = <10>;
                 status = "okay";
         };
diff --git a/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
new file mode 100644
index 000000000000..6d63782a7378
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/of-xilinx-wdt.txt
@@ -0,0 +1,23 @@
+Xilinx AXI/PLB soft-core watchdog Device Tree Bindings
+---------------------------------------------------------
+
+Required properties:
+- compatible            : Should be "xlnx,xps-timebase-wdt-1.00.a" or
+                          "xlnx,xps-timebase-wdt-1.01.a".
+- reg                   : Physical base address and size
+
+Optional properties:
+- clock-frequency       : Frequency of clock in Hz
+- xlnx,wdt-enable-once  : 0 - Watchdog can be restarted
+                          1 - Watchdog can be enabled just once
+- xlnx,wdt-interval     : Watchdog timeout interval in 2^<val> clock cycles,
+                          <val> is integer from 8 to 31.
+
+Example:
+axi-timebase-wdt@40100000 {
+        clock-frequency = <50000000>;
+        compatible = "xlnx,xps-timebase-wdt-1.00.a";
+        reg = <0x40100000 0x10000>;
+        xlnx,wdt-enable-once = <0x0>;
+        xlnx,wdt-interval = <0x1b>;
+} ;
diff --git a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
index e39cb266c8f4..b8f75c51453a 100644
--- a/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/sunxi-wdt.txt
@@ -2,13 +2,13 @@ Allwinner SoCs Watchdog timer
 
 Required properties:
 
-- compatible : should be "allwinner,<soc-family>-wdt", the currently supported
-  SoC families being sun4i and sun6i
+- compatible : should be either "allwinner,sun4i-a10-wdt" or
+               "allwinner,sun6i-a31-wdt"
 - reg : Specifies base physical address and size of the registers.
 
 Example:
 
 wdt: watchdog@01c20c90 {
-        compatible = "allwinner,sun4i-wdt";
+        compatible = "allwinner,sun4i-a10-wdt";
         reg = <0x01c20c90 0x10>;
 };
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 5d5ee4c13fa6..d91b8be80b66 100755
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -28,8 +28,8 @@ use IO::Handle;
                 "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
                 "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
                 "lme2510c_s7395_old", "drxk", "drxk_terratec_h5",
-                "drxk_hauppauge_hvr930c", "tda10071", "it9135", "it9137",
-                "drxk_pctv", "drxk_terratec_htc_stick", "sms1xxx_hcw");
+                "drxk_hauppauge_hvr930c", "tda10071", "it9135", "drxk_pctv",
+                "drxk_terratec_htc_stick", "sms1xxx_hcw");
 
 # Check args
 syntax() if (scalar(@ARGV) != 1);
@@ -727,24 +727,6 @@ sub it9135 {
         "$fwfile1 $fwfile2"
 }
 
-sub it9137 {
-    my $url = "http://kworld.server261.com/kworld/CD/ITE_TiVme/V1.00/";
-    my $zipfile = "Driver_V10.323.1.0412.100412.zip";
-    my $hash = "79b597dc648698ed6820845c0c9d0d37";
-    my $tmpdir = tempdir(DIR => "/tmp", CLEANUP => 0);
-    my $drvfile = "Driver_V10.323.1.0412.100412/Data/x86/IT9135BDA.sys";
-    my $fwfile = "dvb-usb-it9137-01.fw";
-
-    checkstandard();
-
-    wgetfile($zipfile, $url . $zipfile);
-    verify($zipfile, $hash);
-    unzip($zipfile, $tmpdir);
-    extract("$tmpdir/$drvfile", 69632, 5731, "$fwfile");
-
-    "$fwfile"
-}
-
 sub tda10071 {
     my $sourcefile = "PCTV_460e_reference.zip";
     my $url = "ftp://ftp.pctvsystems.com/TV/driver/PCTV%2070e%2080e%20100e%20320e%20330e%20800e/";
diff --git a/Documentation/dvb/it9137.txt b/Documentation/dvb/it9137.txt
deleted file mode 100644
index 9e6726eead90..000000000000
--- a/Documentation/dvb/it9137.txt
+++ /dev/null
@@ -1,9 +0,0 @@
-To extract firmware for Kworld UB499-2T (id 1b80:e409) you need to copy the
-following file(s) to this directory.
-
-IT9135BDA.sys Dated Mon 22 Mar 2010 02:20:08 GMT
-
-extract using dd
-dd if=IT9135BDA.sys ibs=1 skip=69632 count=5731 of=dvb-usb-it9137-01.fw
-
-copy to default firmware location.
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index 56c7e936430f..cb4c2cefd45a 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -6,7 +6,7 @@ Written by Doug Thompson <dougthompson@xmission.com>
 7 Dec 2005
 17 Jul 2007     Updated
 
-(c) Mauro Carvalho Chehab <mchehab@redhat.com>
+(c) Mauro Carvalho Chehab
 05 Aug 2009     Nehalem interface
 
 EDAC is maintained and written by:
diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking
index 5b0c083d7c0e..efca5c1bbb10 100644
--- a/Documentation/filesystems/Locking
+++ b/Documentation/filesystems/Locking
@@ -47,6 +47,8 @@ prototypes:
         int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
         int (*rename) (struct inode *, struct dentry *,
                         struct inode *, struct dentry *);
+        int (*rename2) (struct inode *, struct dentry *,
+                        struct inode *, struct dentry *, unsigned int);
         int (*readlink) (struct dentry *, char __user *,int);
         void * (*follow_link) (struct dentry *, struct nameidata *);
         void (*put_link) (struct dentry *, struct nameidata *, void *);
@@ -78,6 +80,7 @@ mkdir:		yes
 unlink:         yes (both)
 rmdir:          yes (both)      (see below)
 rename:         yes (all)       (see below)
+rename2:        yes (all)       (see below)
 readlink:       no
 follow_link:    no
 put_link:       no
@@ -96,7 +99,8 @@ tmpfile:	no
 
         Additionally, ->rmdir(), ->unlink() and ->rename() have ->i_mutex on
 victim.
-        cross-directory ->rename() has (per-superblock) ->s_vfs_rename_sem.
+        cross-directory ->rename() and rename2() has (per-superblock)
+->s_vfs_rename_sem.
 
 See Documentation/filesystems/directory-locking for more detailed discussion
 of the locking scheme for directory operations.
@@ -525,6 +529,7 @@ locking rules:
 open:           yes
 close:          yes
 fault:          yes             can return with page locked
+map_pages:      yes
 page_mkwrite:   yes             can return with page locked
 access:         yes
 
@@ -536,6 +541,15 @@ the page, then ensure it is not already truncated (the page lock will block
 subsequent truncate), and then return with VM_FAULT_LOCKED, and the page
 locked. The VM will unlock the page.
 
+        ->map_pages() is called when VM asks to map easy accessible pages.
+Filesystem should find and map pages associated with offsets from "pgoff"
+till "max_pgoff". ->map_pages() is called with page table locked and must
+not block.  If it's not possible to reach a page without blocking,
+filesystem should skip it. Filesystem should use do_set_pte() to setup
+page table entry. Pointer to entry associated with offset "pgoff" is
+passed in "pte" field in vm_fault structure. Pointers to entries for other
+offsets should be calculated relative to "pte".
+
         ->page_mkwrite() is called when a previously read-only pte is
 about to become writeable. The filesystem again must ensure that there are
 no truncate/invalidate races, and then return with the page locked. If
diff --git a/Documentation/filesystems/affs.txt b/Documentation/filesystems/affs.txt
index 81ac488e3758..71b63c2b9841 100644
--- a/Documentation/filesystems/affs.txt
+++ b/Documentation/filesystems/affs.txt
@@ -49,6 +49,10 @@ mode=mode	Sets the mode flags to the given (octal) value, regardless
                 This is useful since most of the plain AmigaOS files
                 will map to 600.
 
+nofilenametruncate
+                The file system will return an error when filename exceeds
+                standard maximum filename length (30 characters).
+
 reserved=num    Sets the number of reserved blocks at the start of the
                 partition to num. You should never need this option.
                 Default is 2.
@@ -181,9 +185,8 @@ tested, though several hundred MB have been read and written using
 this fs. For a most up-to-date list of bugs please consult
 fs/affs/Changes.
 
-Filenames are truncated to 30 characters without warning (this
-can be changed by setting the compile-time option AFFS_NO_TRUNCATE
-in include/linux/amigaffs.h).
+By default, filenames are truncated to 30 characters without warning.
+'nofilenametruncate' mount option can change that behavior.
 
 Case is ignored by the affs in filename matching, but Linux shells
 do care about the case. Example (with /wb being an affs mounted fs):
diff --git a/Documentation/filesystems/autofs4-mount-control.txt b/Documentation/filesystems/autofs4-mount-control.txt
index 4c95935cbcf4..aff22113a986 100644
--- a/Documentation/filesystems/autofs4-mount-control.txt
+++ b/Documentation/filesystems/autofs4-mount-control.txt
@@ -255,7 +255,7 @@ AUTOFS_DEV_IOCTL_OPENMOUNT and AUTOFS_DEV_IOCTL_CLOSEMOUNT
 
 Obtain and release a file descriptor for an autofs managed mount point
 path. The open call requires an initialized struct autofs_dev_ioctl with
-the the path field set and the size field adjusted appropriately as well
+the path field set and the size field adjusted appropriately as well
 as the arg1 field set to the device number of the autofs mount. The
 device number can be obtained from the mount options shown in
 /proc/mounts. The close call requires an initialized struct
diff --git a/Documentation/filesystems/f2fs.txt b/Documentation/filesystems/f2fs.txt
index b8d284975f0f..25311e113e75 100644
--- a/Documentation/filesystems/f2fs.txt
+++ b/Documentation/filesystems/f2fs.txt
@@ -122,6 +122,10 @@ disable_ext_identify   Disable the extension list configured by mkfs, so f2fs
 inline_xattr           Enable the inline xattrs feature.
 inline_data            Enable the inline data feature: New created small(<~3.4k)
                        files can be written into inode block.
+flush_merge            Merge concurrent cache_flush commands as much as possible
+                       to eliminate redundant command issues. If the underlying
+                       device handles the cache_flush command relatively slowly,
+                       recommend to enable this option.
 
 ================================================================================
 DEBUGFS ENTRIES
@@ -169,9 +173,11 @@ Files in /sys/fs/f2fs/<devname>
 
  reclaim_segments             This parameter controls the number of prefree
                               segments to be reclaimed. If the number of prefree
-                              segments is larger than this number, f2fs tries to
-                              conduct checkpoint to reclaim the prefree segments
-                              to free segments. By default, 100 segments, 200MB.
+                              segments is larger than the number of segments
+                              in the proportion to the percentage over total
+                              volume size, f2fs tries to conduct checkpoint to
+                              reclaim the prefree segments to free segments.
+                              By default, 5% over total # of segments.
 
  max_small_discards           This parameter controls the number of discard
                               commands that consist small blocks less than 2MB.
@@ -195,6 +201,17 @@ Files in /sys/fs/f2fs/<devname>
                               cleaning operations. The default value is 4096
                               which covers 8GB block address range.
 
+ dir_level                    This parameter controls the directory level to
+                              support large directory. If a directory has a
+                              number of files, it can reduce the file lookup
+                              latency by increasing this dir_level value.
+                              Otherwise, it needs to decrease this value to
+                              reduce the space overhead. The default value is 0.
+
+ ram_thresh                   This parameter controls the memory footprint used
+                              by free nids and cached nat entries. By default,
+                              10 is set, which indicates 10 MB / 1 GB RAM.
+
 ================================================================================
 USAGE
 ================================================================================
@@ -444,9 +461,11 @@ The number of blocks and buckets are determined by,
   # of blocks in level #n = |
                             `- 4, Otherwise
 
-                             ,- 2^n, if n < MAX_DIR_HASH_DEPTH / 2,
+                             ,- 2^ (n + dir_level),
+                             |            if n < MAX_DIR_HASH_DEPTH / 2,
   # of buckets in level #n = |
-                             `- 2^((MAX_DIR_HASH_DEPTH / 2) - 1), Otherwise
+                             `- 2^((MAX_DIR_HASH_DEPTH / 2 + dir_level) - 1),
+                                          Otherwise
 
 When F2FS finds a file name in a directory, at first a hash value of the file
 name is calculated. Then, F2FS scans the hash table in level #0 to find the
diff --git a/Documentation/filesystems/hfsplus.txt b/Documentation/filesystems/hfsplus.txt
index af1628a1061c..59f7569fc9ed 100644
--- a/Documentation/filesystems/hfsplus.txt
+++ b/Documentation/filesystems/hfsplus.txt
@@ -56,4 +56,4 @@ References
 
 kernel source:          <file:fs/hfsplus>
 
-Apple Technote 1150     http://developer.apple.com/technotes/tn/tn1150.html
+Apple Technote 1150     https://developer.apple.com/legacy/library/technotes/tn/tn1150.html
diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt
index 06887d46ccf2..41c3d332acc9 100644
--- a/Documentation/filesystems/nilfs2.txt
+++ b/Documentation/filesystems/nilfs2.txt
@@ -25,9 +25,8 @@ available from the following download page.  At least "mkfs.nilfs2",
 cleaner or garbage collector) are required.  Details on the tools are
 described in the man pages included in the package.
 
-Project web page:    http://www.nilfs.org/en/
-Download page:       http://www.nilfs.org/en/download.html
-Git tree web page:   http://www.nilfs.org/git/
+Project web page:    http://nilfs.sourceforge.net/
+Download page:       http://nilfs.sourceforge.net/en/download.html
 List info:           http://vger.kernel.org/vger-lists.html#linux-nilfs
 
 Caveats
@@ -111,6 +110,13 @@ Table of NILFS2 specific ioctls
                                 nilfs_resize utilities and by nilfs_cleanerd
                                 daemon.
 
+ NILFS_IOCTL_SET_SUINFO         Modify segment usage info of requested
+                                segments. This ioctl is used by
+                                nilfs_cleanerd daemon to skip unnecessary
+                                cleaning operation of segments and reduce
+                                performance penalty or wear of flash device
+                                due to redundant move of in-use blocks.
+
  NILFS_IOCTL_GET_SUSTAT         Return segment usage statistics. This ioctl
                                 is used in lssu, nilfs_resize utilities and
                                 by nilfs_cleanerd daemon.
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index 791af8dac065..61947facfc07 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -455,8 +455,6 @@ not have this problem with odd numbers of sectors.
 ChangeLog
 =========
 
-Note, a technical ChangeLog aimed at kernel hackers is in fs/ntfs/ChangeLog.
-
 2.1.30:
         - Fix writev() (it kept writing the first segment over and over again
           instead of moving onto subsequent segments).
diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting
index fe2b7ae6f962..0f3a1390bf00 100644
--- a/Documentation/filesystems/porting
+++ b/Documentation/filesystems/porting
@@ -295,9 +295,9 @@ in the beginning of ->setattr unconditionally.
         ->clear_inode() and ->delete_inode() are gone; ->evict_inode() should
 be used instead.  It gets called whenever the inode is evicted, whether it has
 remaining links or not.  Caller does *not* evict the pagecache or inode-associated
-metadata buffers; getting rid of those is responsibility of method, as it had
-been for ->delete_inode(). Caller makes sure async writeback cannot be running
-for the inode while (or after) ->evict_inode() is called.
+metadata buffers; the method has to use truncate_inode_pages_final() to get rid
+of those. Caller makes sure async writeback cannot be running for the inode while
+(or after) ->evict_inode() is called.
 
         ->drop_inode() returns int now; it's called on final iput() with
 inode->i_lock held and it returns true if filesystems wants the inode to be
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index f00bee144add..8b9cd8eb3f91 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -1648,18 +1648,21 @@ 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
+3.8     /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].
+files have at least three fields -- 'pos', 'flags' and mnt_id. The 'pos'
+represents the current offset of the opened file in decimal form [see lseek(2)
+for details], 'flags' denotes the octal O_xxx mask the file has been
+created with [see open(2) for details] and 'mnt_id' represents mount ID of
+the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo
+for details].
 
 A typical output is
 
         pos:    0
         flags:  0100002
+        mnt_id: 19
 
 The files such as eventfd, fsnotify, signalfd, epoll among the regular pos/flags
 pair provide additional information particular to the objects they represent.
@@ -1668,6 +1671,7 @@ pair provide additional information particular to the objects they represent.
         ~~~~~~~~~~~~~
         pos:    0
         flags:  04002
+        mnt_id: 9
         eventfd-count:  5a
 
         where 'eventfd-count' is hex value of a counter.
@@ -1676,6 +1680,7 @@ pair provide additional information particular to the objects they represent.
         ~~~~~~~~~~~~~~
         pos:    0
         flags:  04002
+        mnt_id: 9
         sigmask:        0000000000000200
 
         where 'sigmask' is hex value of the signal mask associated
@@ -1685,6 +1690,7 @@ pair provide additional information particular to the objects they represent.
         ~~~~~~~~~~~
         pos:    0
         flags:  02
+        mnt_id: 9
         tfd:        5 events:       1d data: ffffffffffffffff
 
         where 'tfd' is a target file descriptor number in decimal form,
@@ -1718,6 +1724,7 @@ pair provide additional information particular to the objects they represent.
 
         pos:    0
         flags:  02
+        mnt_id: 9
         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
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index c53784c119c8..94eb86287bcb 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -347,6 +347,8 @@ struct inode_operations {
         int (*mknod) (struct inode *,struct dentry *,umode_t,dev_t);
         int (*rename) (struct inode *, struct dentry *,
                         struct inode *, struct dentry *);
+        int (*rename2) (struct inode *, struct dentry *,
+                        struct inode *, struct dentry *, unsigned int);
         int (*readlink) (struct dentry *, char __user *,int);
         void * (*follow_link) (struct dentry *, struct nameidata *);
         void (*put_link) (struct dentry *, struct nameidata *, void *);
@@ -414,6 +416,20 @@ otherwise noted.
   rename: called by the rename(2) system call to rename the object to
         have the parent and name given by the second inode and dentry.
 
+  rename2: this has an additional flags argument compared to rename.
+        If no flags are supported by the filesystem then this method
+        need not be implemented.  If some flags are supported then the
+        filesystem must return -EINVAL for any unsupported or unknown
+        flags.  Currently the following flags are implemented:
+        (1) RENAME_NOREPLACE: this flag indicates that if the target
+        of the rename exists the rename should fail with -EEXIST
+        instead of replacing the target.  The VFS already checks for
+        existence, so for local filesystems the RENAME_NOREPLACE
+        implementation is equivalent to plain rename.
+        (2) RENAME_EXCHANGE: exchange source and target.  Both must
+        exist; this is checked by the VFS.  Unlike plain rename,
+        source and target may be of different type.
+
   readlink: called by the readlink(2) system call. Only required if
         you want to support reading symbolic links
 
diff --git a/Documentation/fmc/fmc-write-eeprom.txt b/Documentation/fmc/fmc-write-eeprom.txt
index 44a3bc678bf0..e0a9712156aa 100644
--- a/Documentation/fmc/fmc-write-eeprom.txt
+++ b/Documentation/fmc/fmc-write-eeprom.txt
@@ -9,7 +9,12 @@ Overwriting the EEPROM is not something you should do daily, and it is
 expected to only happen during manufacturing. For this reason, the
 module makes it unlikely for the random user to change a working EEPROM.
 
-The module takes the following measures:
+However, since the EEPROM may include application-specific information
+other than the identification, later versions of this packages added
+write-support through sysfs. See *note Accessing the EEPROM::.
+
+To avoid damaging the EEPROM content, the module takes the following
+measures:
 
    * It accepts a `file=' argument (within /lib/firmware) and if no
      such argument is received, it doesn't write anything to EEPROM
@@ -70,56 +75,24 @@ first time.
         [  132.899872]  fake-fmc: Product name: FmcDelay1ns4cha
 
 
-Writing to the EEPROM
+Accessing the EEPROM
 =====================
 
-Once you have created a binary file for your EEPROM, you can write it
-to the storage medium using the fmc-write-eeprom (See *note
-fmc-write-eeprom::, while relying on a carrier driver.  The procedure
-here shown here uses the SPEC driver
-(`http://www.ohwr.org/projects/spec-sw').
-
-The example assumes no driver is already loaded (actually, I unloaded
-them by hand as everything loads automatically at boot time after you
-installed the modules), and shows kernel messages together with
-commands. Here the prompt is spusa.root# and two SPEC cards are plugged
-in the system.
-
-     spusa.root# insmod fmc.ko
-     spusa.root# insmod spec.ko
-     [13972.382818] spec 0000:02:00.0:  probe for device 0002:0000
-     [13972.392773] spec 0000:02:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes
-     [13972.591388] spec 0000:02:00.0: FPGA programming successful
-     [13972.883011] spec 0000:02:00.0: EEPROM has no FRU information
-     [13972.888719] spec 0000:02:00.0: No device_id filled, using index
-     [13972.894676] spec 0000:02:00.0: No mezzanine_name found
-     [13972.899863] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init
-     [13972.906578] spec 0000:04:00.0:  probe for device 0004:0000
-     [13972.916509] spec 0000:04:00.0: got file "fmc/spec-init.bin", 1484404 (0x16a674) bytes
-     [13973.115096] spec 0000:04:00.0: FPGA programming successful
-     [13973.401798] spec 0000:04:00.0: EEPROM has no FRU information
-     [13973.407474] spec 0000:04:00.0: No device_id filled, using index
-     [13973.413417] spec 0000:04:00.0: No mezzanine_name found
-     [13973.418600] /home/rubini/wip/spec-sw/kernel/spec-gpio.c - spec_gpio_init
-     spusa.root# ls /sys/bus/fmc/devices
-     fmc-0000  fmc-0001
-     spusa.root# insmod fmc-write-eeprom.ko busid=0x0200 file=fdelay-eeprom.bin
-     [14103.966259] spec 0000:02:00.0: Matching an generic driver (no ID)
-     [14103.975519] spec 0000:02:00.0: programming 6155 bytes
-     [14126.373762] spec 0000:02:00.0: write_eeprom: success
-     [14126.378770] spec 0000:04:00.0: Matching an generic driver (no ID)
-     [14126.384903] spec 0000:04:00.0: fmc_write_eeprom: no filename given: not programming
-     [14126.392600] fmc_write_eeprom: probe of fmc-0001 failed with error -2
-
-Reading back the EEPROM
-=======================
-
-In order to read back the binary content of the EEPROM of your
-mezzanine device, the bus creates a read-only sysfs file called eeprom
-for each mezzanine it knows about:
-
-   spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom
-   -r--r--r-- 1 root root 8192 Apr  9 16:53 FmcDelay1ns4cha-f001/eeprom
-   -r--r--r-- 1 root root 8192 Apr  9 17:19 fake-design-for-testing-f002/eeprom
-   -r--r--r-- 1 root root 8192 Apr  9 17:19 fake-design-for-testing-f003/eeprom
-   -r--r--r-- 1 root root 8192 Apr  9 17:19 fmc-f004/eeprom
+The bus creates a sysfs binary file called eeprom for each mezzanine it
+knows about:
+
+        spusa.root# cd /sys/bus/fmc/devices; ls -l */eeprom
+        -r--r--r-- 1 root root 8192 Feb 21 12:30 FmcAdc100m14b4cha-0800/eeprom
+        -r--r--r-- 1 root root 8192 Feb 21 12:30 FmcDelay1ns4cha-0200/eeprom
+        -r--r--r-- 1 root root 8192 Feb 21 12:30 FmcDio5cha-0400/eeprom
+
+Everybody can read the files and the superuser can also modify it, but
+the operation may on the carrier driver, if the carrier is unable to
+access the I2C bus.  For example, the spec driver can access the bus
+only with its golden gateware: after a mezzanine driver reprogrammed
+the FPGA with a custom circuit, the carrier is unable to access the
+EEPROM and returns ENOTSUPP.
+
+An alternative way to write the EEPROM is the mezzanine driver
+fmc-write-eeprom (See *note fmc-write-eeprom::), but the procedure is
+more complex.
diff --git a/Documentation/futex-requeue-pi.txt b/Documentation/futex-requeue-pi.txt
index 9dc1ff4fd536..31b16610c416 100644
--- a/Documentation/futex-requeue-pi.txt
+++ b/Documentation/futex-requeue-pi.txt
@@ -67,7 +67,7 @@ pthread_cond_wait_pi(cond, mutex)
            lock(cond->__data.__lock);
         } while(...)
         unlock(cond->__data.__lock);
-        /* the kernel acquired the the mutex for us */
+        /* the kernel acquired the mutex for us */
 }
 
 pthread_cond_broadcast_pi(cond)
diff --git a/Documentation/gpio/consumer.txt b/Documentation/gpio/consumer.txt
index e42f77d8d4ca..09854fe59307 100644
--- a/Documentation/gpio/consumer.txt
+++ b/Documentation/gpio/consumer.txt
@@ -154,6 +154,7 @@ raw line value:
         void gpiod_set_raw_value(struct gpio_desc *desc, int value)
         int gpiod_get_raw_value_cansleep(const struct gpio_desc *desc)
         void gpiod_set_raw_value_cansleep(struct gpio_desc *desc, int value)
+        int gpiod_direction_output_raw(struct gpio_desc *desc, int value)
 
 The active-low state of a GPIO can also be queried using the following call:
 
diff --git a/Documentation/gpio/driver.txt b/Documentation/gpio/driver.txt
index 9da0bfa74781..f73cc7b5dc85 100644
--- a/Documentation/gpio/driver.txt
+++ b/Documentation/gpio/driver.txt
@@ -62,6 +62,37 @@ Any debugfs dump method should normally ignore signals which haven't been
 requested as GPIOs. They can use gpiochip_is_requested(), which returns either
 NULL or the label associated with that GPIO when it was requested.
 
+
+GPIO drivers providing IRQs
+---------------------------
+It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
+most often cascaded off a parent interrupt controller, and in some special
+cases the GPIO logic is melded with a SoC's primary interrupt controller.
+
+The IRQ portions of the GPIO block are implemented using an irqchip, using
+the header <linux/irq.h>. So basically such a driver is utilizing two sub-
+systems simultaneously: gpio and irq.
+
+It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
+if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
+irq_chip are orthogonal, and offering their services independent of each
+other.
+
+gpiod_to_irq() is just a convenience function to figure out the IRQ for a
+certain GPIO line and should not be relied upon to have been called before
+the IRQ is used.
+
+So always prepare the hardware and make it ready for action in respective
+callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
+been called first.
+
+This orthogonality leads to ambiguities that we need to solve: if there is
+competition inside the subsystem which side is using the resource (a certain
+GPIO line and register for example) it needs to deny certain operations and
+keep track of usage inside of the gpiolib subsystem. This is why the API
+below exists.
+
+
 Locking IRQ usage
 -----------------
 Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
@@ -73,3 +104,7 @@ This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
 is released:
 
         void gpiod_unlock_as_irq(struct gpio_desc *desc)
+
+When implementing an irqchip inside a GPIO driver, these two functions should
+typically be called in the .startup() and .shutdown() callbacks from the
+irqchip.
diff --git a/Documentation/hid/hid-transport.txt b/Documentation/hid/hid-transport.txt
new file mode 100644
index 000000000000..3dcba9fd4a3a
--- /dev/null
+++ b/Documentation/hid/hid-transport.txt
@@ -0,0 +1,317 @@
+                          HID I/O Transport Drivers
+                         ===========================
+
+The HID subsystem is independent of the underlying transport driver. Initially,
+only USB was supported, but other specifications adopted the HID design and
+provided new transport drivers. The kernel includes at least support for USB,
+Bluetooth, I2C and user-space I/O drivers.
+
+1) HID Bus
+==========
+
+The HID subsystem is designed as a bus. Any I/O subsystem may provide HID
+devices and register them with the HID bus. HID core then loads generic device
+drivers on top of it. The transport drivers are responsible of raw data
+transport and device setup/management. HID core is responsible of
+report-parsing, report interpretation and the user-space API. Device specifics
+and quirks are handled by all layers depending on the quirk.
+
+ +-----------+  +-----------+            +-----------+  +-----------+
+ | Device #1 |  | Device #i |            | Device #j |  | Device #k |
+ +-----------+  +-----------+            +-----------+  +-----------+
+          \\      //                              \\      //
+        +------------+                          +------------+
+        | I/O Driver |                          | I/O Driver |
+        +------------+                          +------------+
+              ||                                      ||
+     +------------------+                    +------------------+
+     | Transport Driver |                    | Transport Driver |
+     +------------------+                    +------------------+
+                       \___                ___/
+                           \              /
+                          +----------------+
+                          |    HID Core    |
+                          +----------------+
+                           /  |        |  \
+                          /   |        |   \
+             ____________/    |        |    \_________________
+            /                 |        |                      \
+           /                  |        |                       \
+ +----------------+  +-----------+  +------------------+  +------------------+
+ | Generic Driver |  | MT Driver |  | Custom Driver #1 |  | Custom Driver #2 |
+ +----------------+  +-----------+  +------------------+  +------------------+
+
+Example Drivers:
+  I/O: USB, I2C, Bluetooth-l2cap
+  Transport: USB-HID, I2C-HID, BT-HIDP
+
+Everything below "HID Core" is simplified in this graph as it is only of
+interest to HID device drivers. Transport drivers do not need to know the
+specifics.
+
+1.1) Device Setup
+-----------------
+
+I/O drivers normally provide hotplug detection or device enumeration APIs to the
+transport drivers. Transport drivers use this to find any suitable HID device.
+They allocate HID device objects and register them with HID core. Transport
+drivers are not required to register themselves with HID core. HID core is never
+aware of which transport drivers are available and is not interested in it. It
+is only interested in devices.
+
+Transport drivers attach a constant "struct hid_ll_driver" object with each
+device. Once a device is registered with HID core, the callbacks provided via
+this struct are used by HID core to communicate with the device.
+
+Transport drivers are responsible of detecting device failures and unplugging.
+HID core will operate a device as long as it is registered regardless of any
+device failures. Once transport drivers detect unplug or failure events, they
+must unregister the device from HID core and HID core will stop using the
+provided callbacks.
+
+1.2) Transport Driver Requirements
+----------------------------------
+
+The terms "asynchronous" and "synchronous" in this document describe the
+transmission behavior regarding acknowledgements. An asynchronous channel must
+not perform any synchronous operations like waiting for acknowledgements or
+verifications. Generally, HID calls operating on asynchronous channels must be
+running in atomic-context just fine.
+On the other hand, synchronous channels can be implemented by the transport
+driver in whatever way they like. They might just be the same as asynchronous
+channels, but they can also provide acknowledgement reports, automatic
+retransmission on failure, etc. in a blocking manner. If such functionality is
+required on asynchronous channels, a transport-driver must implement that via
+its own worker threads.
+
+HID core requires transport drivers to follow a given design. A Transport
+driver must provide two bi-directional I/O channels to each HID device. These
+channels must not necessarily be bi-directional in the hardware itself. A
+transport driver might just provide 4 uni-directional channels. Or it might
+multiplex all four on a single physical channel. However, in this document we
+will describe them as two bi-directional channels as they have several
+properties in common.
+
+ - Interrupt Channel (intr): The intr channel is used for asynchronous data
+   reports. No management commands or data acknowledgements are sent on this
+   channel. Any unrequested incoming or outgoing data report must be sent on
+   this channel and is never acknowledged by the remote side. Devices usually
+   send their input events on this channel. Outgoing events are normally
+   not send via intr, except if high throughput is required.
+ - Control Channel (ctrl): The ctrl channel is used for synchronous requests and
+   device management. Unrequested data input events must not be sent on this
+   channel and are normally ignored. Instead, devices only send management
+   events or answers to host requests on this channel.
+   The control-channel is used for direct blocking queries to the device
+   independent of any events on the intr-channel.
+   Outgoing reports are usually sent on the ctrl channel via synchronous
+   SET_REPORT requests.
+
+Communication between devices and HID core is mostly done via HID reports. A
+report can be of one of three types:
+
+ - INPUT Report: Input reports provide data from device to host. This
+   data may include button events, axis events, battery status or more. This
+   data is generated by the device and sent to the host with or without
+   requiring explicit requests. Devices can choose to send data continuously or
+   only on change.
+ - OUTPUT Report: Output reports change device states. They are sent from host
+   to device and may include LED requests, rumble requests or more. Output
+   reports are never sent from device to host, but a host can retrieve their
+   current state.
+   Hosts may choose to send output reports either continuously or only on
+   change.
+ - FEATURE Report: Feature reports are used for specific static device features
+   and never reported spontaneously. A host can read and/or write them to access
+   data like battery-state or device-settings.
+   Feature reports are never sent without requests. A host must explicitly set
+   or retrieve a feature report. This also means, feature reports are never sent
+   on the intr channel as this channel is asynchronous.
+
+INPUT and OUTPUT reports can be sent as pure data reports on the intr channel.
+For INPUT reports this is the usual operational mode. But for OUTPUT reports,
+this is rarely done as OUTPUT reports are normally quite scarce. But devices are
+free to make excessive use of asynchronous OUTPUT reports (for instance, custom
+HID audio speakers make great use of it).
+
+Plain reports must not be sent on the ctrl channel, though. Instead, the ctrl
+channel provides synchronous GET/SET_REPORT requests. Plain reports are only
+allowed on the intr channel and are the only means of data there.
+
+ - GET_REPORT: A GET_REPORT request has a report ID as payload and is sent
+   from host to device. The device must answer with a data report for the
+   requested report ID on the ctrl channel as a synchronous acknowledgement.
+   Only one GET_REPORT request can be pending for each device. This restriction
+   is enforced by HID core as several transport drivers don't allow multiple
+   simultaneous GET_REPORT requests.
+   Note that data reports which are sent as answer to a GET_REPORT request are
+   not handled as generic device events. That is, if a device does not operate
+   in continuous data reporting mode, an answer to GET_REPORT does not replace
+   the raw data report on the intr channel on state change.
+   GET_REPORT is only used by custom HID device drivers to query device state.
+   Normally, HID core caches any device state so this request is not necessary
+   on devices that follow the HID specs except during device initialization to
+   retrieve the current state.
+   GET_REPORT requests can be sent for any of the 3 report types and shall
+   return the current report state of the device. However, OUTPUT reports as
+   payload may be blocked by the underlying transport driver if the
+   specification does not allow them.
+ - SET_REPORT: A SET_REPORT request has a report ID plus data as payload. It is
+   sent from host to device and a device must update it's current report state
+   according to the given data. Any of the 3 report types can be used. However,
+   INPUT reports as payload might be blocked by the underlying transport driver
+   if the specification does not allow them.
+   A device must answer with a synchronous acknowledgement. However, HID core
+   does not require transport drivers to forward this acknowledgement to HID
+   core.
+   Same as for GET_REPORT, only one SET_REPORT can be pending at a time. This
+   restriction is enforced by HID core as some transport drivers do not support
+   multiple synchronous SET_REPORT requests.
+
+Other ctrl-channel requests are supported by USB-HID but are not available
+(or deprecated) in most other transport level specifications:
+
+ - GET/SET_IDLE: Only used by USB-HID and I2C-HID.
+ - GET/SET_PROTOCOL: Not used by HID core.
+ - RESET: Used by I2C-HID, not hooked up in HID core.
+ - SET_POWER: Used by I2C-HID, not hooked up in HID core.
+
+2) HID API
+==========
+
+2.1) Initialization
+-------------------
+
+Transport drivers normally use the following procedure to register a new device
+with HID core:
+
+        struct hid_device *hid;
+        int ret;
+
+        hid = hid_allocate_device();
+        if (IS_ERR(hid)) {
+                ret = PTR_ERR(hid);
+                goto err_<...>;
+        }
+
+        strlcpy(hid->name, <device-name-src>, 127);
+        strlcpy(hid->phys, <device-phys-src>, 63);
+        strlcpy(hid->uniq, <device-uniq-src>, 63);
+
+        hid->ll_driver = &custom_ll_driver;
+        hid->bus = <device-bus>;
+        hid->vendor = <device-vendor>;
+        hid->product = <device-product>;
+        hid->version = <device-version>;
+        hid->country = <device-country>;
+        hid->dev.parent = <pointer-to-parent-device>;
+        hid->driver_data = <transport-driver-data-field>;
+
+        ret = hid_add_device(hid);
+        if (ret)
+                goto err_<...>;
+
+Once hid_add_device() is entered, HID core might use the callbacks provided in
+"custom_ll_driver". Note that fields like "country" can be ignored by underlying
+transport-drivers if not supported.
+
+To unregister a device, use:
+
+        hid_destroy_device(hid);
+
+Once hid_destroy_device() returns, HID core will no longer make use of any
+driver callbacks.
+
+2.2) hid_ll_driver operations
+-----------------------------
+
+The available HID callbacks are:
+ - int (*start) (struct hid_device *hdev)
+   Called from HID device drivers once they want to use the device. Transport
+   drivers can choose to setup their device in this callback. However, normally
+   devices are already set up before transport drivers register them to HID core
+   so this is mostly only used by USB-HID.
+
+ - void (*stop) (struct hid_device *hdev)
+   Called from HID device drivers once they are done with a device. Transport
+   drivers can free any buffers and deinitialize the device. But note that
+   ->start() might be called again if another HID device driver is loaded on the
+   device.
+   Transport drivers are free to ignore it and deinitialize devices after they
+   destroyed them via hid_destroy_device().
+
+ - int (*open) (struct hid_device *hdev)
+   Called from HID device drivers once they are interested in data reports.
+   Usually, while user-space didn't open any input API/etc., device drivers are
+   not interested in device data and transport drivers can put devices asleep.
+   However, once ->open() is called, transport drivers must be ready for I/O.
+   ->open() calls are nested for each client that opens the HID device.
+
+ - void (*close) (struct hid_device *hdev)
+   Called from HID device drivers after ->open() was called but they are no
+   longer interested in device reports. (Usually if user-space closed any input
+   devices of the driver).
+   Transport drivers can put devices asleep and terminate any I/O of all
+   ->open() calls have been followed by a ->close() call. However, ->start() may
+   be called again if the device driver is interested in input reports again.
+
+ - int (*parse) (struct hid_device *hdev)
+   Called once during device setup after ->start() has been called. Transport
+   drivers must read the HID report-descriptor from the device and tell HID core
+   about it via hid_parse_report().
+
+ - int (*power) (struct hid_device *hdev, int level)
+   Called by HID core to give PM hints to transport drivers. Usually this is
+   analogical to the ->open() and ->close() hints and redundant.
+
+ - void (*request) (struct hid_device *hdev, struct hid_report *report,
+                    int reqtype)
+   Send an HID request on the ctrl channel. "report" contains the report that
+   should be sent and "reqtype" the request type. Request-type can be
+   HID_REQ_SET_REPORT or HID_REQ_GET_REPORT.
+   This callback is optional. If not provided, HID core will assemble a raw
+   report following the HID specs and send it via the ->raw_request() callback.
+   The transport driver is free to implement this asynchronously.
+
+ - int (*wait) (struct hid_device *hdev)
+   Used by HID core before calling ->request() again. A transport driver can use
+   it to wait for any pending requests to complete if only one request is
+   allowed at a time.
+
+ - int (*raw_request) (struct hid_device *hdev, unsigned char reportnum,
+                       __u8 *buf, size_t count, unsigned char rtype,
+                       int reqtype)
+   Same as ->request() but provides the report as raw buffer. This request shall
+   be synchronous. A transport driver must not use ->wait() to complete such
+   requests. This request is mandatory and hid core will reject the device if
+   it is missing.
+
+ - int (*output_report) (struct hid_device *hdev, __u8 *buf, size_t len)
+   Send raw output report via intr channel. Used by some HID device drivers
+   which require high throughput for outgoing requests on the intr channel. This
+   must not cause SET_REPORT calls! This must be implemented as asynchronous
+   output report on the intr channel!
+
+ - int (*idle) (struct hid_device *hdev, int report, int idle, int reqtype)
+   Perform SET/GET_IDLE request. Only used by USB-HID, do not implement!
+
+2.3) Data Path
+--------------
+
+Transport drivers are responsible of reading data from I/O devices. They must
+handle any I/O-related state-tracking themselves. HID core does not implement
+protocol handshakes or other management commands which can be required by the
+given HID transport specification.
+
+Every raw data packet read from a device must be fed into HID core via
+hid_input_report(). You must specify the channel-type (intr or ctrl) and report
+type (input/output/feature). Under normal conditions, only input reports are
+provided via this API.
+
+Responses to GET_REPORT requests via ->request() must also be provided via this
+API. Responses to ->raw_request() are synchronous and must be intercepted by the
+transport driver and not passed to hid_input_report().
+Acknowledgements to SET_REPORT requests are not of interest to HID core.
+
+----------------------------------------------------
+Written 2013, David Herrmann <dh.herrmann@gmail.com>
diff --git a/Documentation/hid/uhid.txt b/Documentation/hid/uhid.txt
index dc35a2b75eee..ee6593608c8e 100644
--- a/Documentation/hid/uhid.txt
+++ b/Documentation/hid/uhid.txt
@@ -93,6 +93,11 @@ the request was handled successfully.
   event to the kernel. The payload is of type struct uhid_create_req and
   contains information about your device. You can start I/O now.
 
+  UHID_CREATE2:
+  Same as UHID_CREATE, but the HID report descriptor data (rd_data) is an array
+  inside struct uhid_create2_req, instead of a pointer to a separate array.
+  Enables use from languages that don't support pointers, e.g. Python.
+
   UHID_DESTROY:
   This destroys the internal HID device. No further I/O will be accepted. There
   may still be pending messages that you can receive with read() but no further
@@ -105,6 +110,12 @@ the request was handled successfully.
   contains a data-payload. This is the raw data that you read from your device.
   The kernel will parse the HID reports and react on it.
 
+  UHID_INPUT2:
+  Same as UHID_INPUT, but the data array is the last field of uhid_input2_req.
+  Enables userspace to write only the required bytes to kernel (ev.type +
+  ev.u.input2.size + the part of the data array that matters), instead of
+  the entire struct uhid_input2_req.
+
   UHID_FEATURE_ANSWER:
   If you receive a UHID_FEATURE request you must answer with this request. You
   must copy the "id" field from the request into the answer. Set the "err" field
diff --git a/Documentation/hwmon/adc128d818 b/Documentation/hwmon/adc128d818
new file mode 100644
index 000000000000..39c95004dabc
--- /dev/null
+++ b/Documentation/hwmon/adc128d818
@@ -0,0 +1,47 @@
+Kernel driver adc128d818
+========================
+
+Supported chips:
+  * Texas Instruments ADC818D818
+    Prefix: 'adc818d818'
+    Addresses scanned: I2C 0x1d, 0x1e, 0x1f, 0x2d, 0x2e, 0x2f
+    Datasheet: Publicly available at the TI website
+               http://www.ti.com/
+
+Author: Guenter Roeck
+
+Description
+-----------
+
+This driver implements support for the Texas Instruments ADC128D818.
+It is described as 'ADC System Monitor with Temperature Sensor'.
+
+The ADC128D818 implements one temperature sensor and seven voltage sensors.
+
+Temperatures are measured in degrees Celsius. There is one set of limits.
+When the HOT Temperature Limit is crossed, this will cause an alarm that will
+be reasserted until the temperature drops below the HOT Hysteresis.
+Measurements are guaranteed between -55 and +125 degrees. The temperature
+measurement has a resolution of 0.5 degrees; the limits have a resolution
+of 1 degree.
+
+Voltage sensors (also known as IN sensors) report their values in volts.
+An alarm is triggered if the voltage has crossed a programmable minimum
+or maximum limit. Note that minimum in this case always means 'closest to
+zero'; this is important for negative voltage measurements. All voltage
+inputs can measure voltages between 0 and 2.55 volts, with a resolution
+of 0.625 mV.
+
+If an alarm triggers, it will remain triggered until the hardware register
+is read at least once. This means that the cause for the alarm may
+already have disappeared by the time the alarm is read. The driver
+caches the alarm status for each sensor until it is at least reported
+once, to ensure that alarms are reported to user space.
+
+The ADC128D818 only updates its values approximately once per second;
+reading it more often will do no harm, but will return 'old' values.
+
+In addition to the scanned address list, the chip can also be configured for
+addresses 0x35 to 0x37. Those addresses are not scanned. You have to instantiate
+the driver explicitly if the chip is configured for any of those addresses in
+your system.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 0c1635082c99..fe80e9adebfa 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -2,7 +2,7 @@ Kernel driver it87
 ==================
 
 Supported chips:
-  * IT8603E
+  * IT8603E/IT8623E
     Prefix: 'it8603'
     Addresses scanned: from Super I/O config space (8 I/O ports)
     Datasheet: Not publicly available
@@ -94,9 +94,9 @@ motherboard models.
 Description
 -----------
 
-This driver implements support for the IT8603E, IT8705F, IT8712F, IT8716F,
-IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E, IT8772E,
-IT8782F, IT8783E/F, and SiS950 chips.
+This driver implements support for the IT8603E, IT8623E, IT8705F, IT8712F,
+IT8716F, IT8718F, IT8720F, IT8721F, IT8726F, IT8728F, IT8758E, IT8771E,
+IT8772E, IT8782F, IT8783E/F, and SiS950 chips.
 
 These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
 joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -133,7 +133,7 @@ to userspace applications.
 The IT8728F, IT8771E, and IT8772E are considered compatible with the IT8721F,
 until a datasheet becomes available (hopefully.)
 
-The IT8603E is a custom design, hardware monitoring part is similar to
+The IT8603E/IT8623E is a custom design, hardware monitoring part is similar to
 IT8728F. It only supports 16-bit fan mode, the full speed mode of the
 fan is not supported (value 0 of pwmX_enable).
 
diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp
index 4dfdc8f83633..ee6d30ec1522 100644
--- a/Documentation/hwmon/k10temp
+++ b/Documentation/hwmon/k10temp
@@ -11,8 +11,8 @@ Supported chips:
   Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
 * AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series)
 * AMD Family 14h processors: "Brazos" (C/E/G/Z-Series)
-* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity"
-* AMD Family 16h processors: "Kabini"
+* AMD Family 15h processors: "Bulldozer" (FX-Series), "Trinity", "Kaveri"
+* AMD Family 16h processors: "Kabini", "Mullins"
 
   Prefix: 'k10temp'
   Addresses scanned: PCI space
@@ -46,7 +46,7 @@ Description
 -----------
 
 This driver permits reading of the internal temperature sensor of AMD
-Family 10h/11h/12h/14h/15h processors.
+Family 10h/11h/12h/14h/15h/16h processors.
 
 All these processors have a sensor, but on those for Socket F or AM2+,
 the sensor may return inconsistent values (erratum 319).  The driver
diff --git a/Documentation/hwmon/lm95245 b/Documentation/hwmon/lm95245
index cbd8aeab7124..77eaf2812d25 100644
--- a/Documentation/hwmon/lm95245
+++ b/Documentation/hwmon/lm95245
@@ -24,8 +24,12 @@ is given within a range of -127 to +127.875 degrees. Remote temperatures are
 given within a range of -127 to +255 degrees. Resolution depends on
 temperature input and range.
 
-Each sensor has its own critical limit, but the hysteresis is common to all
-two channels.
+Each sensor has its own critical limit. Additionally, there is a relative
+hysteresis value common to both critical limits. To make life easier to
+user-space applications, two absolute values are exported, one for each
+channel, but these values are of course linked. Only the local hysteresis
+can be set from user-space, and the same delta applies to the remote
+hysteresis.
 
 The lm95245 driver can change its update interval to a fixed set of values.
 It will round up to the next selectable interval. See the datasheet for exact
diff --git a/Documentation/hwmon/ltc2945 b/Documentation/hwmon/ltc2945
new file mode 100644
index 000000000000..f8d0f7f19adb
--- /dev/null
+++ b/Documentation/hwmon/ltc2945
@@ -0,0 +1,84 @@
+Kernel driver ltc2945
+=====================
+
+Supported chips:
+  * Linear Technology LTC2945
+    Prefix: 'ltc2945'
+    Addresses scanned: -
+    Datasheet:
+        http://cds.linear.com/docs/en/datasheet/2945fa.pdf
+
+Author: Guenter Roeck <linux@roeck-us.net>
+
+
+Description
+-----------
+
+The LTC2945  is a rail-to-rail system monitor that measures current, voltage,
+and power consumption.
+
+
+Usage Notes
+-----------
+
+This driver does not probe for LTC2945 devices, since there is no register
+which can be safely used to identify the chip. You will have to instantiate
+the devices explicitly.
+
+Example: the following will load the driver for an LTC2945 at address 0x10
+on I2C bus #1:
+$ modprobe ltc2945
+$ echo ltc2945 0x10 > /sys/bus/i2c/devices/i2c-1/new_device
+
+
+Sysfs entries
+-------------
+
+Voltage readings provided by this driver are reported as obtained from the ADC
+registers. If a set of voltage divider resistors is installed, calculate the
+real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the
+value of the divider resistor against the measured voltage and R2 is the value
+of the divider resistor against Ground.
+
+Current reading provided by this driver is reported as obtained from the ADC
+Current Sense register. The reported value assumes that a 1 mOhm sense resistor
+is installed. If a different sense resistor is installed, calculate the real
+current by dividing the reported value by the sense resistor value in mOhm.
+
+in1_input               VIN voltage (mV). Voltage is measured either at
+                        SENSE+ or VDD pin depending on chip configuration.
+in1_min                 Undervoltage threshold
+in1_max                 Overvoltage threshold
+in1_lowest              Lowest measured voltage
+in1_highest             Highest measured voltage
+in1_reset_history       Write 1 to reset in1 history
+in1_min_alarm           Undervoltage alarm
+in1_max_alarm           Overvoltage alarm
+
+in2_input               ADIN voltage (mV)
+in2_min                 Undervoltage threshold
+in2_max                 Overvoltage threshold
+in2_lowest              Lowest measured voltage
+in2_highest             Highest measured voltage
+in2_reset_history       Write 1 to reset in2 history
+in2_min_alarm           Undervoltage alarm
+in2_max_alarm           Overvoltage alarm
+
+curr1_input             SENSE current (mA)
+curr1_min               Undercurrent threshold
+curr1_max               Overcurrent threshold
+curr1_lowest            Lowest measured current
+curr1_highest           Highest measured current
+curr1_reset_history     Write 1 to reset curr1 history
+curr1_min_alarm         Undercurrent alarm
+curr1_max_alarm         Overcurrent alarm
+
+power1_input            Power (in uW). Power is calculated based on SENSE+/VDD
+                        voltage or ADIN voltage depending on chip configuration.
+power1_min              Low lower threshold
+power1_max              High power threshold
+power1_input_lowest     Historical minimum power use
+power1_input_highest    Historical maximum power use
+power1_reset_history    Write 1 to reset power1 history
+power1_min_alarm        Low power alarm
+power1_max_alarm        High power alarm
diff --git a/Documentation/hwmon/ltc2978 b/Documentation/hwmon/ltc2978
index a0546fc42273..686c078bb0e0 100644
--- a/Documentation/hwmon/ltc2978
+++ b/Documentation/hwmon/ltc2978
@@ -23,6 +23,10 @@ Supported chips:
     Prefix: 'ltc3883'
     Addresses scanned: -
     Datasheet: http://www.linear.com/product/ltc3883
+  * Linear Technology LTM4676
+    Prefix: 'ltm4676'
+    Addresses scanned: -
+    Datasheet: http://www.linear.com/product/ltm4676
 
 Author: Guenter Roeck <linux@roeck-us.net>
 
@@ -33,7 +37,8 @@ Description
 LTC2974 is a quad digital power supply manager. LTC2978 is an octal power supply
 monitor. LTC2977 is a pin compatible replacement for LTC2978. LTC3880 is a dual
 output poly-phase step-down DC/DC controller. LTC3883 is a single phase
-step-down DC/DC controller.
+step-down DC/DC controller. LTM4676 is a dual 13A or single 26A uModule
+regulator.
 
 
 Usage Notes
@@ -75,7 +80,7 @@ in[N]_label		"vout[1-8]".
                         LTC2974: N=2-5
                         LTC2977: N=2-9
                         LTC2978: N=2-9
-                        LTC3880: N=2-3
+                        LTC3880, LTM4676: N=2-3
                         LTC3883: N=2
 in[N]_input             Measured output voltage.
 in[N]_min               Minimum output voltage.
@@ -95,7 +100,7 @@ temp[N]_input		Measured temperature.
                         and temp5 reports the chip temperature.
                         On LTC2977 and LTC2978, only one temperature measurement
                         is supported and reports the chip temperature.
-                        On LTC3880, temp1 and temp2 report external
+                        On LTC3880 and LTM4676, temp1 and temp2 report external
                         temperatures, and temp3 reports the chip temperature.
                         On LTC3883, temp1 reports an external temperature,
                         and temp2 reports the chip temperature.
@@ -123,11 +128,11 @@ power[N]_label		"pout[1-4]".
                         LTC2974: N=1-4
                         LTC2977: Not supported
                         LTC2978: Not supported
-                        LTC3880: N=1-2
+                        LTC3880, LTM4676: N=1-2
                         LTC3883: N=2
 power[N]_input          Measured output power.
 
-curr1_label             "iin". LTC3880 and LTC3883 only.
+curr1_label             "iin". LTC3880, LTC3883, and LTM4676 only.
 curr1_input             Measured input current.
 curr1_max               Maximum input current.
 curr1_max_alarm         Input current high alarm.
@@ -138,7 +143,7 @@ curr[N]_label		"iout[1-4]".
                         LTC2974: N=1-4
                         LTC2977: not supported
                         LTC2978: not supported
-                        LTC3880: N=2-3
+                        LTC3880, LTM4676: N=2-3
                         LTC3883: N=2
 curr[N]_input           Measured output current.
 curr[N]_max             Maximum output current.
diff --git a/Documentation/hwmon/ltc4260 b/Documentation/hwmon/ltc4260
new file mode 100644
index 000000000000..c4ff4ad998b2
--- /dev/null
+++ b/Documentation/hwmon/ltc4260
@@ -0,0 +1,56 @@
+Kernel driver ltc4260
+=====================
+
+Supported chips:
+  * Linear Technology LTC4260
+    Prefix: 'ltc4260'
+    Addresses scanned: -
+    Datasheet:
+        http://cds.linear.com/docs/en/datasheet/4260fc.pdf
+
+Author: Guenter Roeck <linux@roeck-us.net>
+
+
+Description
+-----------
+
+The LTC4260 Hot Swap controller allows a board to be safely inserted
+and removed from a live backplane.
+
+
+Usage Notes
+-----------
+
+This driver does not probe for LTC4260 devices, since there is no register
+which can be safely used to identify the chip. You will have to instantiate
+the devices explicitly.
+
+Example: the following will load the driver for an LTC4260 at address 0x10
+on I2C bus #1:
+$ modprobe ltc4260
+$ echo ltc4260 0x10 > /sys/bus/i2c/devices/i2c-1/new_device
+
+
+Sysfs entries
+-------------
+
+Voltage readings provided by this driver are reported as obtained from the ADC
+registers. If a set of voltage divider resistors is installed, calculate the
+real voltage by multiplying the reported value with (R1+R2)/R2, where R1 is the
+value of the divider resistor against the measured voltage and R2 is the value
+of the divider resistor against Ground.
+
+Current reading provided by this driver is reported as obtained from the ADC
+Current Sense register. The reported value assumes that a 1 mOhm sense resistor
+is installed. If a different sense resistor is installed, calculate the real
+current by dividing the reported value by the sense resistor value in mOhm.
+
+in1_input               SOURCE voltage (mV)
+in1_min_alarm           Undervoltage alarm
+in1_max_alarm           Overvoltage alarm
+
+in2_input               ADIN voltage (mV)
+in2_alarm               Power bad alarm
+
+curr1_input             SENSE current (mA)
+curr1_alarm             SENSE overcurrent alarm
diff --git a/Documentation/input/multi-touch-protocol.txt b/Documentation/input/multi-touch-protocol.txt
index de139b18184a..7b4f59c09ee2 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -372,7 +372,7 @@ simple scheme, which is compatible with earlier usage, is:
 
 Rationale: We have no information about the orientation of the touching
 ellipse, so approximate it with an inscribed circle instead. The tool
-ellipse should align with the the vector (T - C), so the diameter must
+ellipse should align with the vector (T - C), so the diameter must
 increase with distance(T, C). Finally, assume that the touch diameter is
 equal to the tool thickness, and we arrive at the formulas above.
 
diff --git a/Documentation/irqflags-tracing.txt b/Documentation/irqflags-tracing.txt
index 67aa71e73035..f6da05670e16 100644
--- a/Documentation/irqflags-tracing.txt
+++ b/Documentation/irqflags-tracing.txt
@@ -22,13 +22,6 @@ rather straightforward and risk-free manner.
 Architectures that want to support this need to do a couple of
 code-organizational changes first:
 
-- move their irq-flags manipulation code from their asm/system.h header
-  to asm/irqflags.h
-
-- rename local_irq_disable()/etc to raw_local_irq_disable()/etc. so that
-  the linux/irqflags.h code can inject callbacks and can construct the
-  real local_irq_disable()/etc APIs.
-
 - add and enable TRACE_IRQFLAGS_SUPPORT in their arch level Kconfig file
 
 and then a couple of functional changes are needed as well to implement
diff --git a/Documentation/ja_JP/SubmittingPatches b/Documentation/ja_JP/SubmittingPatches
index 97f78dd0c085..5d6ae639bfa0 100644
--- a/Documentation/ja_JP/SubmittingPatches
+++ b/Documentation/ja_JP/SubmittingPatches
@@ -98,11 +98,6 @@ dontdiff ファイルには Linux カーネルのビルドプロセスの過程�
 Quilt:
 http://savannah.nongnu.org/projects/quilt
 
-Andrew Morton's patch scripts:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント
-ツールとして推奨されています(上のリンクを見てください)。
-
 2) パッチに対する説明
 
 パッチの中の変更点に対する技術的な詳細について説明してください。
@@ -695,7 +690,7 @@ gcc においては、マクロと同じくらい軽いです。
 ----------------------
 
 Andrew Morton, "The perfect patch" (tpp).
-  <http://userweb.kernel.org/~akpm/stuff/tpp.txt>
+  <http://www.ozlabs.org/~akpm/stuff/tpp.txt>
 
 Jeff Garzik, "Linux kernel patch submission format".
   <http://linux.yyz.us/patch-format.html>
@@ -707,7 +702,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
   <http://www.kroah.com/log/2006/01/11/>
 
 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
-  <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
+  <https://lkml.org/lkml/2005/7/11/336>
 
 Kernel Documentation/CodingStyle:
   <http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index c420676c6fe3..350f733bf2c7 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -157,6 +157,10 @@ applicable everywhere (see syntax).
     to the build environment (if this is desired, it can be done via
     another symbol).
 
+  - "allnoconfig_y"
+    This declares the symbol as one that should have the value y when
+    using "allnoconfig". Used for symbols that hide other symbols.
+
 Menu dependencies
 -----------------
 
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 7116fda7077f..b6c67d592be5 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -229,8 +229,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         use by PCI
                         Format: <irq>,<irq>...
 
+        acpi_no_auto_serialize  [HW,ACPI]
+                        Disable auto-serialization of AML methods
+                        AML control methods that contain the opcodes to create
+                        named objects will be marked as "Serialized" by the
+                        auto-serialization feature.
+                        This feature is enabled by default.
+                        This option allows to turn off the feature.
+
         acpi_no_auto_ssdt       [HW,ACPI] Disable automatic loading of SSDT
 
+        acpica_no_return_repair [HW, ACPI]
+                        Disable AML predefined validation mechanism
+                        This mechanism can repair the evaluation result to make
+                        the return objects more ACPI specification compliant.
+                        This option is useful for developers to identify the
+                        root cause of an AML interpreter issue when the issue
+                        has something to do with the repair mechanism.
+
         acpi_os_name=   [HW,ACPI] Tell ACPI BIOS the name of the OS
                         Format: To spoof as Windows 98: ="Microsoft Windows"
 
@@ -298,8 +314,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
         acpi_sci=       [HW,ACPI] ACPI System Control Interrupt trigger mode
                         Format: { level | edge | high | low }
 
-        acpi_serialize  [HW,ACPI] force serialization of AML methods
-
         acpi_skip_timer_override [HW,ACPI]
                         Recognize and ignore IRQ0/pin2 Interrupt Override.
                         For broken nForce2 BIOS resulting in XT-PIC timer.
@@ -870,6 +884,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         Enable debug messages at boot time.  See
                         Documentation/dynamic-debug-howto.txt for details.
 
+        early_ioremap_debug [KNL]
+                        Enable debug messages in early_ioremap support. This
+                        is useful for tracking down temporary early mappings
+                        which are not unmapped.
+
         earlycon=       [KNL] Output early console device and options.
                 uart[8250],io,<addr>[,options]
                 uart[8250],mmio,<addr>[,options]
@@ -1011,6 +1030,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         parameter will force ia64_sal_cache_flush to call
                         ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
 
+        forcepae [X86-32]
+                        Forcefully enable Physical Address Extension (PAE).
+                        Many Pentium M systems disable PAE but may have a
+                        functionally usable PAE implementation.
+                        Warning: use of this parameter will taint the kernel
+                        and may cause unknown problems.
+
         ftrace=[tracer]
                         [FTRACE] will set and start the specified tracer
                         as early as possible in order to facilitate early
@@ -2053,8 +2079,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         IOAPICs that may be present in the system.
 
         nokaslr         [X86]
-                        Disable kernel base offset ASLR (Address Space
-                        Layout Randomization) if built into the kernel.
+                        Disable kernel and module base offset ASLR (Address
+                        Space Layout Randomization) if built into the kernel.
 
         noautogroup     Disable scheduler automatic task group creation.
 
@@ -3409,14 +3435,24 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                         of CONFIG_HIGHPTE.
 
         vdso=           [X86,SH]
-                        vdso=2: enable compat VDSO (default with COMPAT_VDSO)
-                        vdso=1: enable VDSO (default)
+                        On X86_32, this is an alias for vdso32=.  Otherwise:
+
+                        vdso=1: enable VDSO (the default)
                         vdso=0: disable VDSO mapping
 
-        vdso32=         [X86]
-                        vdso32=2: enable compat VDSO (default with COMPAT_VDSO)
-                        vdso32=1: enable 32-bit VDSO (default)
-                        vdso32=0: disable 32-bit VDSO mapping
+        vdso32=         [X86] Control the 32-bit vDSO
+                        vdso32=1: enable 32-bit VDSO
+                        vdso32=0 or vdso32=2: disable 32-bit VDSO
+
+                        See the help text for CONFIG_COMPAT_VDSO for more
+                        details.  If CONFIG_COMPAT_VDSO is set, the default is
+                        vdso32=0; otherwise, the default is vdso32=1.
+
+                        For compatibility with older kernels, vdso32=2 is an
+                        alias for vdso32=0.
+
+                        Try vdso32=0 if you encounter an error that says:
+                        dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
 
         vector=         [IA-64,SMP]
                         vector=percpu: enable percpu vector domain
diff --git a/Documentation/kernel-per-CPU-kthreads.txt b/Documentation/kernel-per-CPU-kthreads.txt
index 827104fb9364..f3cd299fcc41 100644
--- a/Documentation/kernel-per-CPU-kthreads.txt
+++ b/Documentation/kernel-per-CPU-kthreads.txt
@@ -162,7 +162,18 @@ Purpose: Execute workqueue requests
 To reduce its OS jitter, do any of the following:
 1.      Run your workload at a real-time priority, which will allow
         preempting the kworker daemons.
-2.      Do any of the following needed to avoid jitter that your
+2.      A given workqueue can be made visible in the sysfs filesystem
+        by passing the WQ_SYSFS to that workqueue's alloc_workqueue().
+        Such a workqueue can be confined to a given subset of the
+        CPUs using the /sys/devices/virtual/workqueue/*/cpumask sysfs
+        files.  The set of WQ_SYSFS workqueues can be displayed using
+        "ls sys/devices/virtual/workqueue".  That said, the workqueues
+        maintainer would like to caution people against indiscriminately
+        sprinkling WQ_SYSFS across all the workqueues.  The reason for
+        caution is that it is easy to add WQ_SYSFS, but because sysfs is
+        part of the formal user/kernel API, it can be nearly impossible
+        to remove it, even if its addition was a mistake.
+3.      Do any of the following needed to avoid jitter that your
         application cannot tolerate:
         a.      Build your kernel with CONFIG_SLUB=y rather than
                 CONFIG_SLAB=y, thus avoiding the slab allocator's periodic
diff --git a/Documentation/kmemcheck.txt b/Documentation/kmemcheck.txt
index 9398a501fdb9..a41bdebbe87b 100644
--- a/Documentation/kmemcheck.txt
+++ b/Documentation/kmemcheck.txt
@@ -541,7 +541,7 @@ initialized. This is the beginning of the struct:
 92         } _sifields;
 93 } siginfo_t;
 
-On 64-bit, the int is 4 bytes long, so it must the the union member that has
+On 64-bit, the int is 4 bytes long, so it must the union member that has
 not been initialized. We can verify this using gdb:
 
         $ gdb vmlinux
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index b6e39739a36d..a7563ec4ea7b 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -11,9 +11,7 @@ with the difference that the orphan objects are not freed but only
 reported via /sys/kernel/debug/kmemleak. A similar method is used by the
 Valgrind tool (memcheck --leak-check) to detect the memory leaks in
 user-space applications.
-
-Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported
-architectures.
+Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze, ppc, mips, s390, metag and tile.
 
 Usage
 -----
@@ -53,7 +51,8 @@ Memory scanning parameters can be modified at run-time by writing to the
                   (default 600, 0 to stop the automatic scanning)
   scan          - trigger a memory scan
   clear         - clear list of current memory leak suspects, done by
-                  marking all current reported unreferenced objects grey
+                  marking all current reported unreferenced objects grey,
+                  or free all kmemleak objects if kmemleak has been disabled.
   dump=<addr>   - dump information about the object found at <addr>
 
 Kmemleak can also be disabled at boot-time by passing "kmemleak=off" on
@@ -68,7 +67,7 @@ Basic Algorithm
 
 The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and
 friends are traced and the pointers, together with additional
-information like size and stack trace, are stored in a prio search tree.
+information like size and stack trace, are stored in a rbtree.
 The corresponding freeing function calls are tracked and the pointers
 removed from the kmemleak data structures.
 
@@ -84,7 +83,7 @@ The scanning algorithm steps:
   1. mark all objects as white (remaining white objects will later be
      considered orphan)
   2. scan the memory starting with the data section and stacks, checking
-     the values against the addresses stored in the prio search tree. If
+     the values against the addresses stored in the rbtree. If
      a pointer to a white object is found, the object is added to the
      gray list
   3. scan the gray objects for matching addresses (some white objects
@@ -120,6 +119,18 @@ Then as usual to get your report with:
 
   # cat /sys/kernel/debug/kmemleak
 
+Freeing kmemleak internal objects
+---------------------------------
+
+To allow access to previosuly found memory leaks after kmemleak has been
+disabled by the user or due to an fatal error, internal kmemleak objects
+won't be freed when kmemleak is disabled, and those objects may occupy
+a large part of physical memory.
+
+In this situation, you may reclaim memory with:
+
+  # echo clear > /sys/kernel/debug/kmemleak
+
 Kmemleak API
 ------------
 
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
index 102dc19c4119..556f951f8626 100644
--- a/Documentation/memory-barriers.txt
+++ b/Documentation/memory-barriers.txt
@@ -608,26 +608,30 @@ as follows:
         b = p;  /* BUG: Compiler can reorder!!! */
         do_something();
 
-The solution is again ACCESS_ONCE(), which preserves the ordering between
-the load from variable 'a' and the store to variable 'b':
+The solution is again ACCESS_ONCE() and barrier(), which preserves the
+ordering between the load from variable 'a' and the store to variable 'b':
 
         q = ACCESS_ONCE(a);
         if (q) {
+                barrier();
                 ACCESS_ONCE(b) = p;
                 do_something();
         } else {
+                barrier();
                 ACCESS_ONCE(b) = p;
                 do_something_else();
         }
 
-You could also use barrier() to prevent the compiler from moving
-the stores to variable 'b', but barrier() would not prevent the
-compiler from proving to itself that a==1 always, so ACCESS_ONCE()
-is also needed.
+The initial ACCESS_ONCE() is required to prevent the compiler from
+proving the value of 'a', and the pair of barrier() invocations are
+required to prevent the compiler from pulling the two identical stores
+to 'b' out from the legs of the "if" statement.
 
 It is important to note that control dependencies absolutely require a
 a conditional.  For example, the following "optimized" version of
-the above example breaks ordering:
+the above example breaks ordering, which is why the barrier() invocations
+are absolutely required if you have identical stores in both legs of
+the "if" statement:
 
         q = ACCESS_ONCE(a);
         ACCESS_ONCE(b) = p;  /* BUG: No ordering vs. load from a!!! */
@@ -643,9 +647,11 @@ It is of course legal for the prior load to be part of the conditional,
 for example, as follows:
 
         if (ACCESS_ONCE(a) > 0) {
+                barrier();
                 ACCESS_ONCE(b) = q / 2;
                 do_something();
         } else {
+                barrier();
                 ACCESS_ONCE(b) = q / 3;
                 do_something_else();
         }
@@ -659,9 +665,11 @@ the needed conditional.  For example:
 
         q = ACCESS_ONCE(a);
         if (q % MAX) {
+                barrier();
                 ACCESS_ONCE(b) = p;
                 do_something();
         } else {
+                barrier();
                 ACCESS_ONCE(b) = p;
                 do_something_else();
         }
@@ -723,8 +731,13 @@ In summary:
       use smb_rmb(), smp_wmb(), or, in the case of prior stores and
       later loads, smp_mb().
 
+  (*) If both legs of the "if" statement begin with identical stores
+      to the same variable, a barrier() statement is required at the
+      beginning of each leg of the "if" statement.
+
   (*) Control dependencies require at least one run-time conditional
-      between the prior load and the subsequent store.  If the compiler
+      between the prior load and the subsequent store, and this
+      conditional must involve the prior load.  If the compiler
       is able to optimize the conditional away, it will have also
       optimized away the ordering.  Careful use of ACCESS_ONCE() can
       help to preserve the needed conditional.
@@ -1249,6 +1262,23 @@ The ACCESS_ONCE() function can prevent any number of optimizations that,
 while perfectly safe in single-threaded code, can be fatal in concurrent
 code.  Here are some examples of these sorts of optimizations:
 
+ (*) The compiler is within its rights to reorder loads and stores
+     to the same variable, and in some cases, the CPU is within its
+     rights to reorder loads to the same variable.  This means that
+     the following code:
+
+        a[0] = x;
+        a[1] = x;
+
+     Might result in an older value of x stored in a[1] than in a[0].
+     Prevent both the compiler and the CPU from doing this as follows:
+
+        a[0] = ACCESS_ONCE(x);
+        a[1] = ACCESS_ONCE(x);
+
+     In short, ACCESS_ONCE() provides cache coherence for accesses from
+     multiple CPUs to a single variable.
+
  (*) The compiler is within its rights to merge successive loads from
      the same variable.  Such merging can cause the compiler to "optimize"
      the following code:
@@ -1371,7 +1401,7 @@ code.  Here are some examples of these sorts of optimizations:
                         process_message(msg);
         }
 
-     There is nothing to prevent the the compiler from transforming
+     There is nothing to prevent the compiler from transforming
      process_level() to the following, in fact, this might well be a
      win for single-threaded code:
 
@@ -1644,12 +1674,12 @@ for each construct.  These operations all imply certain barriers:
      Memory operations issued after the ACQUIRE will be completed after the
      ACQUIRE operation has completed.
 
-     Memory operations issued before the ACQUIRE may be completed after the
-     ACQUIRE operation has completed.  An smp_mb__before_spinlock(), combined
-     with a following ACQUIRE, orders prior loads against subsequent stores and
-     stores and prior stores against subsequent stores.  Note that this is
-     weaker than smp_mb()!  The smp_mb__before_spinlock() primitive is free on
-     many architectures.
+     Memory operations issued before the ACQUIRE may be completed after
+     the ACQUIRE operation has completed.  An smp_mb__before_spinlock(),
+     combined with a following ACQUIRE, orders prior loads against
+     subsequent loads and stores and also orders prior stores against
+     subsequent stores.  Note that this is weaker than smp_mb()!  The
+     smp_mb__before_spinlock() primitive is free on many architectures.
 
  (2) RELEASE operation implication:
 
@@ -1694,24 +1724,21 @@ may occur as:
 
         ACQUIRE M, STORE *B, STORE *A, RELEASE M
 
-This same reordering can of course occur if the lock's ACQUIRE and RELEASE are
-to the same lock variable, but only from the perspective of another CPU not
-holding that lock.
-
-In short, a RELEASE followed by an ACQUIRE may -not- be assumed to be a full
-memory barrier because it is possible for a preceding RELEASE to pass a
-later ACQUIRE from the viewpoint of the CPU, but not from the viewpoint
-of the compiler.  Note that deadlocks cannot be introduced by this
-interchange because if such a deadlock threatened, the RELEASE would
-simply complete.
-
-If it is necessary for a RELEASE-ACQUIRE pair to produce a full barrier, the
-ACQUIRE can be followed by an smp_mb__after_unlock_lock() invocation.  This
-will produce a full barrier if either (a) the RELEASE and the ACQUIRE are
-executed by the same CPU or task, or (b) the RELEASE and ACQUIRE act on the
-same variable.  The smp_mb__after_unlock_lock() primitive is free on many
-architectures.  Without smp_mb__after_unlock_lock(), the critical sections
-corresponding to the RELEASE and the ACQUIRE can cross:
+When the ACQUIRE and RELEASE are a lock acquisition and release,
+respectively, this same reordering can occur if the lock's ACQUIRE and
+RELEASE are to the same lock variable, but only from the perspective of
+another CPU not holding that lock.  In short, a ACQUIRE followed by an
+RELEASE may -not- be assumed to be a full memory barrier.
+
+Similarly, the reverse case of a RELEASE followed by an ACQUIRE does not
+imply a full memory barrier.  If it is necessary for a RELEASE-ACQUIRE
+pair to produce a full barrier, the ACQUIRE can be followed by an
+smp_mb__after_unlock_lock() invocation.  This will produce a full barrier
+if either (a) the RELEASE and the ACQUIRE are executed by the same
+CPU or task, or (b) the RELEASE and ACQUIRE act on the same variable.
+The smp_mb__after_unlock_lock() primitive is free on many architectures.
+Without smp_mb__after_unlock_lock(), the CPU's execution of the critical
+sections corresponding to the RELEASE and the ACQUIRE can cross, so that:
 
         *A = a;
         RELEASE M
@@ -1722,7 +1749,36 @@ could occur as:
 
         ACQUIRE N, STORE *B, STORE *A, RELEASE M
 
-With smp_mb__after_unlock_lock(), they cannot, so that:
+It might appear that this reordering could introduce a deadlock.
+However, this cannot happen because if such a deadlock threatened,
+the RELEASE would simply complete, thereby avoiding the deadlock.
+
+        Why does this work?
+
+        One key point is that we are only talking about the CPU doing
+        the reordering, not the compiler.  If the compiler (or, for
+        that matter, the developer) switched the operations, deadlock
+        -could- occur.
+
+        But suppose the CPU reordered the operations.  In this case,
+        the unlock precedes the lock in the assembly code.  The CPU
+        simply elected to try executing the later lock operation first.
+        If there is a deadlock, this lock operation will simply spin (or
+        try to sleep, but more on that later).  The CPU will eventually
+        execute the unlock operation (which preceded the lock operation
+        in the assembly code), which will unravel the potential deadlock,
+        allowing the lock operation to succeed.
+
+        But what if the lock is a sleeplock?  In that case, the code will
+        try to enter the scheduler, where it will eventually encounter
+        a memory barrier, which will force the earlier unlock operation
+        to complete, again unraveling the deadlock.  There might be
+        a sleep-unlock race, but the locking primitive needs to resolve
+        such races properly in any case.
+
+With smp_mb__after_unlock_lock(), the two critical sections cannot overlap.
+For example, with the following code, the store to *A will always be
+seen by other CPUs before the store to *B:
 
         *A = a;
         RELEASE M
@@ -1730,13 +1786,18 @@ With smp_mb__after_unlock_lock(), they cannot, so that:
         smp_mb__after_unlock_lock();
         *B = b;
 
-will always occur as either of the following:
+The operations will always occur in one of the following orders:
 
-        STORE *A, RELEASE, ACQUIRE, STORE *B
-        STORE *A, ACQUIRE, RELEASE, STORE *B
+        STORE *A, RELEASE, ACQUIRE, smp_mb__after_unlock_lock(), STORE *B
+        STORE *A, ACQUIRE, RELEASE, smp_mb__after_unlock_lock(), STORE *B
+        ACQUIRE, STORE *A, RELEASE, smp_mb__after_unlock_lock(), STORE *B
 
 If the RELEASE and ACQUIRE were instead both operating on the same lock
-variable, only the first of these two alternatives can occur.
+variable, only the first of these alternatives can occur.  In addition,
+the more strongly ordered systems may rule out some of the above orders.
+But in any case, as noted earlier, the smp_mb__after_unlock_lock()
+ensures that the store to *A will always be seen as happening before
+the store to *B.
 
 Locks and semaphores may not provide any guarantee of ordering on UP compiled
 systems, and so cannot be counted on in such a situation to actually achieve
@@ -2757,7 +2818,7 @@ in that order, but, without intervention, the sequence may have almost any
 combination of elements combined or discarded, provided the program's view of
 the world remains consistent.  Note that ACCESS_ONCE() is -not- optional
 in the above example, as there are architectures where a given CPU might
-interchange successive loads to the same location.  On such architectures,
+reorder successive loads to the same location.  On such architectures,
 ACCESS_ONCE() does whatever is necessary to prevent this, for example, on
 Itanium the volatile casts used by ACCESS_ONCE() cause GCC to emit the
 special ld.acq and st.rel instructions that prevent such reordering.
diff --git a/Documentation/module-signing.txt b/Documentation/module-signing.txt
index 2b40e04d3c49..09c2382ad055 100644
--- a/Documentation/module-signing.txt
+++ b/Documentation/module-signing.txt
@@ -53,7 +53,8 @@ This has a number of options available:
 
      If this is off (ie. "permissive"), then modules for which the key is not
      available and modules that are unsigned are permitted, but the kernel will
-     be marked as being tainted.
+     be marked as being tainted, and the concerned modules will be marked as
+     tainted, shown with the character 'E'.
 
      If this is on (ie. "restrictive"), only modules that have a valid
      signature that can be verified by a public key in the kernel's possession
@@ -77,11 +78,11 @@ This has a number of options available:
      This presents a choice of which hash algorithm the installation phase will
      sign the modules with:
 
-        CONFIG_SIG_SHA1         "Sign modules with SHA-1"
-        CONFIG_SIG_SHA224       "Sign modules with SHA-224"
-        CONFIG_SIG_SHA256       "Sign modules with SHA-256"
-        CONFIG_SIG_SHA384       "Sign modules with SHA-384"
-        CONFIG_SIG_SHA512       "Sign modules with SHA-512"
+        CONFIG_MODULE_SIG_SHA1          "Sign modules with SHA-1"
+        CONFIG_MODULE_SIG_SHA224        "Sign modules with SHA-224"
+        CONFIG_MODULE_SIG_SHA256        "Sign modules with SHA-256"
+        CONFIG_MODULE_SIG_SHA384        "Sign modules with SHA-384"
+        CONFIG_MODULE_SIG_SHA512        "Sign modules with SHA-512"
 
      The algorithm selected here will also be built into the kernel (rather
      than being a module) so that modules signed with that algorithm can have
diff --git a/Documentation/networking/altera_tse.txt b/Documentation/networking/altera_tse.txt
new file mode 100644
index 000000000000..3f24df8c6e65
--- /dev/null
+++ b/Documentation/networking/altera_tse.txt
@@ -0,0 +1,263 @@
+       Altera Triple-Speed Ethernet MAC driver
+
+Copyright (C) 2008-2014 Altera Corporation
+
+This is the driver for the Altera Triple-Speed Ethernet (TSE) controllers
+using the SGDMA and MSGDMA soft DMA IP components. The driver uses the
+platform bus to obtain component resources. The designs used to test this
+driver were built for a Cyclone(R) V SOC FPGA board, a Cyclone(R) V FPGA board,
+and tested with ARM and NIOS processor hosts seperately. The anticipated use
+cases are simple communications between an embedded system and an external peer
+for status and simple configuration of the embedded system.
+
+For more information visit www.altera.com and www.rocketboards.org. Support
+forums for the driver may be found on www.rocketboards.org, and a design used
+to test this driver may be found there as well. Support is also available from
+the maintainer of this driver, found in MAINTAINERS.
+
+The Triple-Speed Ethernet, SGDMA, and MSGDMA components are all soft IP
+components that can be assembled and built into an FPGA using the Altera
+Quartus toolchain. Quartus 13.1 and 14.0 were used to build the design that
+this driver was tested against. The sopc2dts tool is used to create the
+device tree for the driver, and may be found at rocketboards.org.
+
+The driver probe function examines the device tree and determines if the
+Triple-Speed Ethernet instance is using an SGDMA or MSGDMA component. The
+probe function then installs the appropriate set of DMA routines to
+initialize, setup transmits, receives, and interrupt handling primitives for
+the respective configurations.
+
+The SGDMA component is to be deprecated in the near future (over the next 1-2
+years as of this writing in early 2014) in favor of the MSGDMA component.
+SGDMA support is included for existing designs and reference in case a
+developer wishes to support their own soft DMA logic and driver support. Any
+new designs should not use the SGDMA.
+
+The SGDMA supports only a single transmit or receive operation at a time, and
+therefore will not perform as well compared to the MSGDMA soft IP. Please
+visit www.altera.com for known, documented SGDMA errata.
+
+Scatter-gather DMA is not supported by the SGDMA or MSGDMA at this time.
+Scatter-gather DMA will be added to a future maintenance update to this
+driver.
+
+Jumbo frames are not supported at this time.
+
+The driver limits PHY operations to 10/100Mbps, and has not yet been fully
+tested for 1Gbps. This support will be added in a future maintenance update.
+
+1) Kernel Configuration
+The kernel configuration option is ALTERA_TSE:
+ Device Drivers ---> Network device support ---> Ethernet driver support --->
+ Altera Triple-Speed Ethernet MAC support (ALTERA_TSE)
+
+2) Driver parameters list:
+        debug: message level (0: no output, 16: all);
+        dma_rx_num: Number of descriptors in the RX list (default is 64);
+        dma_tx_num: Number of descriptors in the TX list (default is 64).
+
+3) Command line options
+Driver parameters can be also passed in command line by using:
+        altera_tse=dma_rx_num:128,dma_tx_num:512
+
+4) Driver information and notes
+
+4.1) Transmit process
+When the driver's transmit routine is called by the kernel, it sets up a
+transmit descriptor by calling the underlying DMA transmit routine (SGDMA or
+MSGDMA), and initites a transmit operation. Once the transmit is complete, an
+interrupt is driven by the transmit DMA logic. The driver handles the transmit
+completion in the context of the interrupt handling chain by recycling
+resource required to send and track the requested transmit operation.
+
+4.2) Receive process
+The driver will post receive buffers to the receive DMA logic during driver
+intialization. Receive buffers may or may not be queued depending upon the
+underlying DMA logic (MSGDMA is able queue receive buffers, SGDMA is not able
+to queue receive buffers to the SGDMA receive logic). When a packet is
+received, the DMA logic generates an interrupt. The driver handles a receive
+interrupt by obtaining the DMA receive logic status, reaping receive
+completions until no more receive completions are available.
+
+4.3) Interrupt Mitigation
+The driver is able to mitigate the number of its DMA interrupts
+using NAPI for receive operations. Interrupt mitigation is not yet supported
+for transmit operations, but will be added in a future maintenance release.
+
+4.4) Ethtool support
+Ethtool is supported. Driver statistics and internal errors can be taken using:
+ethtool -S ethX command. It is possible to dump registers etc.
+
+4.5) PHY Support
+The driver is compatible with PAL to work with PHY and GPHY devices.
+
+4.7) List of source files:
+ o Kconfig
+ o Makefile
+ o altera_tse_main.c: main network device driver
+ o altera_tse_ethtool.c: ethtool support
+ o altera_tse.h: private driver structure and common definitions
+ o altera_msgdma.h: MSGDMA implementation function definitions
+ o altera_sgdma.h: SGDMA implementation function definitions
+ o altera_msgdma.c: MSGDMA implementation
+ o altera_sgdma.c: SGDMA implementation
+ o altera_sgdmahw.h: SGDMA register and descriptor definitions
+ o altera_msgdmahw.h: MSGDMA register and descriptor definitions
+ o altera_utils.c: Driver utility functions
+ o altera_utils.h: Driver utility function definitions
+
+5) Debug Information
+
+The driver exports debug information such as internal statistics,
+debug information, MAC and DMA registers etc.
+
+A user may use the ethtool support to get statistics:
+e.g. using: ethtool -S ethX (that shows the statistics counters)
+or sees the MAC registers: e.g. using: ethtool -d ethX
+
+The developer can also use the "debug" module parameter to get
+further debug information.
+
+6) Statistics Support
+
+The controller and driver support a mix of IEEE standard defined statistics,
+RFC defined statistics, and driver or Altera defined statistics. The four
+specifications containing the standard definitions for these statistics are
+as follows:
+
+ o IEEE 802.3-2012 - IEEE Standard for Ethernet.
+ o RFC 2863 found at http://www.rfc-editor.org/rfc/rfc2863.txt.
+ o RFC 2819 found at http://www.rfc-editor.org/rfc/rfc2819.txt.
+ o Altera Triple Speed Ethernet User Guide, found at http://www.altera.com
+
+The statistics supported by the TSE and the device driver are as follows:
+
+"tx_packets" is equivalent to aFramesTransmittedOK defined in IEEE 802.3-2012,
+Section 5.2.2.1.2. This statistics is the count of frames that are successfully
+transmitted.
+
+"rx_packets" is equivalent to aFramesReceivedOK defined in IEEE 802.3-2012,
+Section 5.2.2.1.5. This statistic is the count of frames that are successfully
+received. This count does not include any error packets such as CRC errors,
+length errors, or alignment errors.
+
+"rx_crc_errors" is equivalent to aFrameCheckSequenceErrors defined in IEEE
+802.3-2012, Section 5.2.2.1.6. This statistic is the count of frames that are
+an integral number of bytes in length and do not pass the CRC test as the frame
+is received.
+
+"rx_align_errors" is equivalent to aAlignmentErrors defined in IEEE 802.3-2012,
+Section 5.2.2.1.7. This statistic is the count of frames that are not an
+integral number of bytes in length and do not pass the CRC test as the frame is
+received.
+
+"tx_bytes" is equivalent to aOctetsTransmittedOK defined in IEEE 802.3-2012,
+Section 5.2.2.1.8. This statistic is the count of data and pad bytes
+successfully transmitted from the interface.
+
+"rx_bytes" is equivalent to aOctetsReceivedOK defined in IEEE 802.3-2012,
+Section 5.2.2.1.14. This statistic is the count of data and pad bytes
+successfully received by the controller.
+
+"tx_pause" is equivalent to aPAUSEMACCtrlFramesTransmitted defined in IEEE
+802.3-2012, Section 30.3.4.2. This statistic is a count of PAUSE frames
+transmitted from the network controller.
+
+"rx_pause" is equivalent to aPAUSEMACCtrlFramesReceived defined in IEEE
+802.3-2012, Section 30.3.4.3. This statistic is a count of PAUSE frames
+received by the network controller.
+
+"rx_errors" is equivalent to ifInErrors defined in RFC 2863. This statistic is
+a count of the number of packets received containing errors that prevented the
+packet from being delivered to a higher level protocol.
+
+"tx_errors" is equivalent to ifOutErrors defined in RFC 2863. This statistic
+is a count of the number of packets that could not be transmitted due to errors.
+
+"rx_unicast" is equivalent to ifInUcastPkts defined in RFC 2863. This
+statistic is a count of the number of packets received that were not addressed
+to the broadcast address or a multicast group.
+
+"rx_multicast" is equivalent to ifInMulticastPkts defined in RFC 2863. This
+statistic is a count of the number of packets received that were addressed to
+a multicast address group.
+
+"rx_broadcast" is equivalent to ifInBroadcastPkts defined in RFC 2863. This
+statistic is a count of the number of packets received that were addressed to
+the broadcast address.
+
+"tx_discards" is equivalent to ifOutDiscards defined in RFC 2863. This
+statistic is the number of outbound packets not transmitted even though an
+error was not detected. An example of a reason this might occur is to free up
+internal buffer space.
+
+"tx_unicast" is equivalent to ifOutUcastPkts defined in RFC 2863. This
+statistic counts the number of packets transmitted that were not addressed to
+a multicast group or broadcast address.
+
+"tx_multicast" is equivalent to ifOutMulticastPkts defined in RFC 2863. This
+statistic counts the number of packets transmitted that were addressed to a
+multicast group.
+
+"tx_broadcast" is equivalent to ifOutBroadcastPkts defined in RFC 2863. This
+statistic counts the number of packets transmitted that were addressed to a
+broadcast address.
+
+"ether_drops" is equivalent to etherStatsDropEvents defined in RFC 2819.
+This statistic counts the number of packets dropped due to lack of internal
+controller resources.
+
+"rx_total_bytes" is equivalent to etherStatsOctets defined in RFC 2819.
+This statistic counts the total number of bytes received by the controller,
+including error and discarded packets.
+
+"rx_total_packets" is equivalent to etherStatsPkts defined in RFC 2819.
+This statistic counts the total number of packets received by the controller,
+including error, discarded, unicast, multicast, and broadcast packets.
+
+"rx_undersize" is equivalent to etherStatsUndersizePkts defined in RFC 2819.
+This statistic counts the number of correctly formed packets received less
+than 64 bytes long.
+
+"rx_oversize" is equivalent to etherStatsOversizePkts defined in RFC 2819.
+This statistic counts the number of correctly formed packets greater than 1518
+bytes long.
+
+"rx_64_bytes" is equivalent to etherStatsPkts64Octets defined in RFC 2819.
+This statistic counts the total number of packets received that were 64 octets
+in length.
+
+"rx_65_127_bytes" is equivalent to etherStatsPkts65to127Octets defined in RFC
+2819. This statistic counts the total number of packets received that were
+between 65 and 127 octets in length inclusive.
+
+"rx_128_255_bytes" is equivalent to etherStatsPkts128to255Octets defined in
+RFC 2819. This statistic is the total number of packets received that were
+between 128 and 255 octets in length inclusive.
+
+"rx_256_511_bytes" is equivalent to etherStatsPkts256to511Octets defined in
+RFC 2819. This statistic is the total number of packets received that were
+between 256 and 511 octets in length inclusive.
+
+"rx_512_1023_bytes" is equivalent to etherStatsPkts512to1023Octets defined in
+RFC 2819. This statistic is the total number of packets received that were
+between 512 and 1023 octets in length inclusive.
+
+"rx_1024_1518_bytes" is equivalent to etherStatsPkts1024to1518Octets define
+in RFC 2819. This statistic is the total number of packets received that were
+between 1024 and 1518 octets in length inclusive.
+
+"rx_gte_1519_bytes" is a statistic defined specific to the behavior of the
+Altera TSE. This statistics counts the number of received good and errored
+frames between the length of 1519 and the maximum frame length configured
+in the frm_length register. See the Altera TSE User Guide for More details.
+
+"rx_jabbers" is equivalent to etherStatsJabbers defined in RFC 2819. This
+statistic is the total number of packets received that were longer than 1518
+octets, and had either a bad CRC with an integral number of octets (CRC Error)
+or a bad CRC with a non-integral number of octets (Alignment Error).
+
+"rx_runts" is equivalent to etherStatsFragments defined in RFC 2819. This
+statistic is the total number of packets received that were less than 64 octets
+in length and had either a bad CRC with an integral number of octets (CRC
+error) or a bad CRC with a non-integral number of octets (Alignment Error).
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index 5cdb22971d19..a383c00392d0 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -270,16 +270,15 @@ arp_ip_target
 arp_validate
 
         Specifies whether or not ARP probes and replies should be
-        validated in the active-backup mode.  This causes the ARP
-        monitor to examine the incoming ARP requests and replies, and
-        only consider a slave to be up if it is receiving the
-        appropriate ARP traffic.
+        validated in any mode that supports arp monitoring, or whether
+        non-ARP traffic should be filtered (disregarded) for link
+        monitoring purposes.
 
         Possible values are:
 
         none or 0
 
-                No validation is performed.  This is the default.
+                No validation or filtering is performed.
 
         active or 1
 
@@ -293,31 +292,68 @@ arp_validate
 
                 Validation is performed for all slaves.
 
-        For the active slave, the validation checks ARP replies to
-        confirm that they were generated by an arp_ip_target.  Since
-        backup slaves do not typically receive these replies, the
-        validation performed for backup slaves is on the ARP request
-        sent out via the active slave.  It is possible that some
-        switch or network configurations may result in situations
-        wherein the backup slaves do not receive the ARP requests; in
-        such a situation, validation of backup slaves must be
-        disabled.
-
-        The validation of ARP requests on backup slaves is mainly
-        helping bonding to decide which slaves are more likely to
-        work in case of the active slave failure, it doesn't really
-        guarantee that the backup slave will work if it's selected
-        as the next active slave.
-
-        This option is useful in network configurations in which
-        multiple bonding hosts are concurrently issuing ARPs to one or
-        more targets beyond a common switch.  Should the link between
-        the switch and target fail (but not the switch itself), the
-        probe traffic generated by the multiple bonding instances will
-        fool the standard ARP monitor into considering the links as
-        still up.  Use of the arp_validate option can resolve this, as
-        the ARP monitor will only consider ARP requests and replies
-        associated with its own instance of bonding.
+        filter or 4
+
+                Filtering is applied to all slaves. No validation is
+                performed.
+
+        filter_active or 5
+
+                Filtering is applied to all slaves, validation is performed
+                only for the active slave.
+
+        filter_backup or 6
+
+                Filtering is applied to all slaves, validation is performed
+                only for backup slaves.
+
+        Validation:
+
+        Enabling validation causes the ARP monitor to examine the incoming
+        ARP requests and replies, and only consider a slave to be up if it
+        is receiving the appropriate ARP traffic.
+
+        For an active slave, the validation checks ARP replies to confirm
+        that they were generated by an arp_ip_target.  Since backup slaves
+        do not typically receive these replies, the validation performed
+        for backup slaves is on the broadcast ARP request sent out via the
+        active slave.  It is possible that some switch or network
+        configurations may result in situations wherein the backup slaves
+        do not receive the ARP requests; in such a situation, validation
+        of backup slaves must be disabled.
+
+        The validation of ARP requests on backup slaves is mainly helping
+        bonding to decide which slaves are more likely to work in case of
+        the active slave failure, it doesn't really guarantee that the
+        backup slave will work if it's selected as the next active slave.
+
+        Validation is useful in network configurations in which multiple
+        bonding hosts are concurrently issuing ARPs to one or more targets
+        beyond a common switch.  Should the link between the switch and
+        target fail (but not the switch itself), the probe traffic
+        generated by the multiple bonding instances will fool the standard
+        ARP monitor into considering the links as still up.  Use of
+        validation can resolve this, as the ARP monitor will only consider
+        ARP requests and replies associated with its own instance of
+        bonding.
+
+        Filtering:
+
+        Enabling filtering causes the ARP monitor to only use incoming ARP
+        packets for link availability purposes.  Arriving packets that are
+        not ARPs are delivered normally, but do not count when determining
+        if a slave is available.
+
+        Filtering operates by only considering the reception of ARP
+        packets (any ARP packet, regardless of source or destination) when
+        determining if a slave has received traffic for link availability
+        purposes.
+
+        Filtering is useful in network configurations in which significant
+        levels of third party broadcast traffic would fool the standard
+        ARP monitor into considering the links as still up.  Use of
+        filtering can resolve this, as only ARP traffic is considered for
+        link availability purposes.
 
         This option was added in bonding version 3.1.0.
 
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 0cbe6ec22d6f..2fa44cbe81b7 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -1017,7 +1017,7 @@ solution for a couple of reasons:
         in case of a bus-off condition after the specified delay time
         in milliseconds. By default it's off.
 
-    "bitrate 125000 sample_point 0.875"
+    "bitrate 125000 sample-point 0.875"
         Shows the real bit-rate in bits/sec and the sample-point in the
         range 0.000..0.999. If the calculation of bit-timing parameters
         is enabled in the kernel (CONFIG_CAN_CALC_BITTIMING=y), the
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index a06b48d2f5cc..81f940f4e884 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -546,6 +546,130 @@ ffffffffa0069c8f + <x>:
 For BPF JIT developers, bpf_jit_disasm, bpf_asm and bpf_dbg provides a useful
 toolchain for developing and testing the kernel's JIT compiler.
 
+BPF kernel internals
+--------------------
+Internally, for the kernel interpreter, a different BPF instruction set
+format with similar underlying principles from BPF described in previous
+paragraphs is being used. However, the instruction set format is modelled
+closer to the underlying architecture to mimic native instruction sets, so
+that a better performance can be achieved (more details later).
+
+It is designed to be JITed with one to one mapping, which can also open up
+the possibility for GCC/LLVM compilers to generate optimized BPF code through
+a BPF backend that performs almost as fast as natively compiled code.
+
+The new instruction set was originally designed with the possible goal in
+mind to write programs in "restricted C" and compile into BPF with a optional
+GCC/LLVM backend, so that it can just-in-time map to modern 64-bit CPUs with
+minimal performance overhead over two steps, that is, C -> BPF -> native code.
+
+Currently, the new format is being used for running user BPF programs, which
+includes seccomp BPF, classic socket filters, cls_bpf traffic classifier,
+team driver's classifier for its load-balancing mode, netfilter's xt_bpf
+extension, PTP dissector/classifier, and much more. They are all internally
+converted by the kernel into the new instruction set representation and run
+in the extended interpreter. For in-kernel handlers, this all works
+transparently by using sk_unattached_filter_create() for setting up the
+filter, resp. sk_unattached_filter_destroy() for destroying it. The macro
+SK_RUN_FILTER(filter, ctx) transparently invokes the right BPF function to
+run the filter. 'filter' is a pointer to struct sk_filter that we got from
+sk_unattached_filter_create(), and 'ctx' the given context (e.g. skb pointer).
+All constraints and restrictions from sk_chk_filter() apply before a
+conversion to the new layout is being done behind the scenes!
+
+Currently, for JITing, the user BPF format is being used and current BPF JIT
+compilers reused whenever possible. In other words, we do not (yet!) perform
+a JIT compilation in the new layout, however, future work will successively
+migrate traditional JIT compilers into the new instruction format as well, so
+that they will profit from the very same benefits. Thus, when speaking about
+JIT in the following, a JIT compiler (TBD) for the new instruction format is
+meant in this context.
+
+Some core changes of the new internal format:
+
+- Number of registers increase from 2 to 10:
+
+  The old format had two registers A and X, and a hidden frame pointer. The
+  new layout extends this to be 10 internal registers and a read-only frame
+  pointer. Since 64-bit CPUs are passing arguments to functions via registers
+  the number of args from BPF program to in-kernel function is restricted
+  to 5 and one register is used to accept return value from an in-kernel
+  function. Natively, x86_64 passes first 6 arguments in registers, aarch64/
+  sparcv9/mips64 have 7 - 8 registers for arguments; x86_64 has 6 callee saved
+  registers, and aarch64/sparcv9/mips64 have 11 or more callee saved registers.
+
+  Therefore, BPF calling convention is defined as:
+
+    * R0        - return value from in-kernel function
+    * R1 - R5   - arguments from BPF program to in-kernel function
+    * R6 - R9   - callee saved registers that in-kernel function will preserve
+    * R10       - read-only frame pointer to access stack
+
+  Thus, all BPF registers map one to one to HW registers on x86_64, aarch64,
+  etc, and BPF calling convention maps directly to ABIs used by the kernel on
+  64-bit architectures.
+
+  On 32-bit architectures JIT may map programs that use only 32-bit arithmetic
+  and may let more complex programs to be interpreted.
+
+  R0 - R5 are scratch registers and BPF program needs spill/fill them if
+  necessary across calls. Note that there is only one BPF program (== one BPF
+  main routine) and it cannot call other BPF functions, it can only call
+  predefined in-kernel functions, though.
+
+- Register width increases from 32-bit to 64-bit:
+
+  Still, the semantics of the original 32-bit ALU operations are preserved
+  via 32-bit subregisters. All BPF registers are 64-bit with 32-bit lower
+  subregisters that zero-extend into 64-bit if they are being written to.
+  That behavior maps directly to x86_64 and arm64 subregister definition, but
+  makes other JITs more difficult.
+
+  32-bit architectures run 64-bit internal BPF programs via interpreter.
+  Their JITs may convert BPF programs that only use 32-bit subregisters into
+  native instruction set and let the rest being interpreted.
+
+  Operation is 64-bit, because on 64-bit architectures, pointers are also
+  64-bit wide, and we want to pass 64-bit values in/out of kernel functions,
+  so 32-bit BPF registers would otherwise require to define register-pair
+  ABI, thus, there won't be able to use a direct BPF register to HW register
+  mapping and JIT would need to do combine/split/move operations for every
+  register in and out of the function, which is complex, bug prone and slow.
+  Another reason is the use of atomic 64-bit counters.
+
+- Conditional jt/jf targets replaced with jt/fall-through:
+
+  While the original design has constructs such as "if (cond) jump_true;
+  else jump_false;", they are being replaced into alternative constructs like
+  "if (cond) jump_true; /* else fall-through */".
+
+- Introduces bpf_call insn and register passing convention for zero overhead
+  calls from/to other kernel functions:
+
+  After a kernel function call, R1 - R5 are reset to unreadable and R0 has a
+  return type of the function. Since R6 - R9 are callee saved, their state is
+  preserved across the call.
+
+Also in the new design, BPF is limited to 4096 insns, which means that any
+program will terminate quickly and will only call a fixed number of kernel
+functions. Original BPF and the new format are two operand instructions,
+which helps to do one-to-one mapping between BPF insn and x86 insn during JIT.
+
+The input context pointer for invoking the interpreter function is generic,
+its content is defined by a specific use case. For seccomp register R1 points
+to seccomp_data, for converted BPF filters R1 points to a skb.
+
+A program, that is translated internally consists of the following elements:
+
+  op:16, jt:8, jf:8, k:32    ==>    op:8, a_reg:4, x_reg:4, off:16, imm:32
+
+Just like the original BPF, the new format runs within a controlled environment,
+is deterministic and the kernel can easily prove that. The safety of the program
+can be determined in two steps: first step does depth-first-search to disallow
+loops and other CFG validation; second step starts from the first insn and
+descends all possible paths. It simulates execution of every insn and observes
+the state change of registers and stack.
+
 Misc
 ----
 
@@ -561,3 +685,4 @@ the underlying architecture.
 
 Jay Schulist <jschlst@samba.org>
 Daniel Borkmann <dborkman@redhat.com>
+Alexei Starovoitov <ast@plumgrid.com>
diff --git a/Documentation/networking/gianfar.txt b/Documentation/networking/gianfar.txt
index ad474ea07d07..ba1daea7f2e4 100644
--- a/Documentation/networking/gianfar.txt
+++ b/Documentation/networking/gianfar.txt
@@ -1,38 +1,8 @@
 The Gianfar Ethernet Driver
-Sysfs File description
 
 Author: Andy Fleming <afleming@freescale.com>
 Updated: 2005-07-28
 
-SYSFS
-
-Several of the features of the gianfar driver are controlled
-through sysfs files.  These are:
-
-bd_stash:
-To stash RX Buffer Descriptors in the L2, echo 'on' or '1' to
-bd_stash, echo 'off' or '0' to disable
-
-rx_stash_len:
-To stash the first n bytes of the packet in L2, echo the number
-of bytes to buf_stash_len.  echo 0 to disable.
-
-WARNING: You could really screw these up if you set them too low or high!
-fifo_threshold:
-To change the number of bytes the controller needs in the
-fifo before it starts transmission, echo the number of bytes to 
-fifo_thresh.  Range should be 0-511.
-
-fifo_starve:
-When the FIFO has less than this many bytes during a transmit, it
-enters starve mode, and increases the priority of TX memory
-transactions.  To change, echo the number of bytes to
-fifo_starve.  Range should be 0-511.
-
-fifo_starve_off:
-Once in starve mode, the FIFO remains there until it has this
-many bytes.  To change, echo the number of bytes to
-fifo_starve_off.  Range should be 0-511.
 
 CHECKSUM OFFLOADING
 
diff --git a/Documentation/networking/igb.txt b/Documentation/networking/igb.txt
index 4ebbd659256f..43d3549366a0 100644
--- a/Documentation/networking/igb.txt
+++ b/Documentation/networking/igb.txt
@@ -36,54 +36,6 @@ Default Value: 0
 This parameter adds support for SR-IOV.  It causes the driver to spawn up to
 max_vfs worth of virtual function.
 
-QueuePairs
-----------
-Valid Range:  0-1
-Default Value:  1 (TX and RX will be paired onto one interrupt vector)
-
-If set to 0, when MSI-X is enabled, the TX and RX will attempt to occupy
-separate vectors.
-
-This option can be overridden to 1 if there are not sufficient interrupts
-available.  This can occur if any combination of RSS, VMDQ, and max_vfs
-results in more than 4 queues being used.
-
-Node
-----
-Valid Range:   0-n
-Default Value: -1 (off)
-
-  0 - n: where n is the number of the NUMA node that should be used to
-         allocate memory for this adapter port.
-  -1: uses the driver default of allocating memory on whichever processor is
-      running insmod/modprobe.
-
-  The Node parameter will allow you to pick which NUMA node you want to have
-  the adapter allocate memory from.  All driver structures, in-memory queues,
-  and receive buffers will be allocated on the node specified.  This parameter
-  is only useful when interrupt affinity is specified, otherwise some portion
-  of the time the interrupt could run on a different core than the memory is
-  allocated on, causing slower memory access and impacting throughput, CPU, or
-  both.
-
-EEE
----
-Valid Range:  0-1
-Default Value: 1 (enabled)
-
-  A link between two EEE-compliant devices will result in periodic bursts of
-  data followed by long periods where in the link is in an idle state. This Low
-  Power Idle (LPI) state is supported in both 1Gbps and 100Mbps link speeds.
-  NOTE: EEE support requires autonegotiation.
-
-DMAC
-----
-Valid Range: 0-1
-Default Value: 1 (enabled)
-  Enables or disables DMA Coalescing feature.
-
-
-
 Additional Configurations
 =========================
 
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index ebf270719402..3544c98401fd 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -48,7 +48,7 @@ The MDIO bus
    time, so it is safe for them to block, waiting for an interrupt to signal
    the operation is complete
  
- 2) A reset function is necessary.  This is used to return the bus to an
+ 2) A reset function is optional.  This is used to return the bus to an
    initialized state.
 
  3) A probe function is needed.  This function should set up anything the bus
@@ -253,16 +253,25 @@ Writing a PHY driver
 
  Each driver consists of a number of function pointers:
 
+   soft_reset: perform a PHY software reset
    config_init: configures PHY into a sane state after a reset.
      For instance, a Davicom PHY requires descrambling disabled.
    probe: Allocate phy->priv, optionally refuse to bind.
    PHY may not have been reset or had fixups run yet.
    suspend/resume: power management
    config_aneg: Changes the speed/duplex/negotiation settings
+   aneg_done: Determines the auto-negotiation result
    read_status: Reads the current speed/duplex/negotiation settings
    ack_interrupt: Clear a pending interrupt
+   did_interrupt: Checks if the PHY generated an interrupt
    config_intr: Enable or disable interrupts
    remove: Does any driver take-down
+   ts_info: Queries about the HW timestamping status
+   hwtstamp: Set the PHY HW timestamping configuration
+   rxtstamp: Requests a receive timestamp at the PHY level for a 'skb'
+   txtsamp: Requests a transmit timestamp at the PHY level for a 'skb'
+   set_wol: Enable Wake-on-LAN at the PHY level
+   get_wol: Get the Wake-on-LAN status at the PHY level
 
  Of these, only config_aneg and read_status are required to be
  assigned by the driver code.  The rest are optional.  Also, it is
diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt
index 5a61a240a652..0e30c7845b2b 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -102,13 +102,18 @@ Examples:
                          The 'minimum' MAC is what you set with dstmac.
 
  pgset "flag [name]"     Set a flag to determine behaviour.  Current flags
-                         are: IPSRC_RND #IP Source is random (between min/max),
-                              IPDST_RND, UDPSRC_RND,
-                              UDPDST_RND, MACSRC_RND, MACDST_RND 
+                         are: IPSRC_RND # IP source is random (between min/max)
+                              IPDST_RND # IP destination is random
+                              UDPSRC_RND, UDPDST_RND,
+                              MACSRC_RND, MACDST_RND
+                              TXSIZE_RND, IPV6,
                               MPLS_RND, VID_RND, SVID_RND
+                              FLOW_SEQ,
                               QUEUE_MAP_RND # queue map random
                               QUEUE_MAP_CPU # queue map mirrors smp_processor_id()
-                              IPSEC # Make IPsec encapsulation for packet
+                              UDPCSUM,
+                              IPSEC # IPsec encapsulation (needs CONFIG_XFRM)
+                              NODE_ALLOC # node specific memory allocation
 
  pgset spi SPI_VALUE     Set specific SA used to transform packet.
 
@@ -233,13 +238,22 @@ udp_dst_max
 
 flag
   IPSRC_RND
-  TXSIZE_RND
   IPDST_RND
   UDPSRC_RND
   UDPDST_RND
   MACSRC_RND
   MACDST_RND
+  TXSIZE_RND
+  IPV6
+  MPLS_RND
+  VID_RND
+  SVID_RND
+  FLOW_SEQ
+  QUEUE_MAP_RND
+  QUEUE_MAP_CPU
+  UDPCSUM
   IPSEC
+  NODE_ALLOC
 
 dst_min
 dst_max
diff --git a/Documentation/networking/rxrpc.txt b/Documentation/networking/rxrpc.txt
index b89bc82eed46..16a924c486bf 100644
--- a/Documentation/networking/rxrpc.txt
+++ b/Documentation/networking/rxrpc.txt
@@ -27,6 +27,8 @@ Contents of this document:
 
  (*) AF_RXRPC kernel interface.
 
+ (*) Configurable parameters.
+
 
 ========
 OVERVIEW
@@ -864,3 +866,82 @@ The kernel interface functions are as follows:
 
      This is used to allocate a null RxRPC key that can be used to indicate
      anonymous security for a particular domain.
+
+
+=======================
+CONFIGURABLE PARAMETERS
+=======================
+
+The RxRPC protocol driver has a number of configurable parameters that can be
+adjusted through sysctls in /proc/net/rxrpc/:
+
+ (*) req_ack_delay
+
+     The amount of time in milliseconds after receiving a packet with the
+     request-ack flag set before we honour the flag and actually send the
+     requested ack.
+
+     Usually the other side won't stop sending packets until the advertised
+     reception window is full (to a maximum of 255 packets), so delaying the
+     ACK permits several packets to be ACK'd in one go.
+
+ (*) soft_ack_delay
+
+     The amount of time in milliseconds after receiving a new packet before we
+     generate a soft-ACK to tell the sender that it doesn't need to resend.
+
+ (*) idle_ack_delay
+
+     The amount of time in milliseconds after all the packets currently in the
+     received queue have been consumed before we generate a hard-ACK to tell
+     the sender it can free its buffers, assuming no other reason occurs that
+     we would send an ACK.
+
+ (*) resend_timeout
+
+     The amount of time in milliseconds after transmitting a packet before we
+     transmit it again, assuming no ACK is received from the receiver telling
+     us they got it.
+
+ (*) max_call_lifetime
+
+     The maximum amount of time in seconds that a call may be in progress
+     before we preemptively kill it.
+
+ (*) dead_call_expiry
+
+     The amount of time in seconds before we remove a dead call from the call
+     list.  Dead calls are kept around for a little while for the purpose of
+     repeating ACK and ABORT packets.
+
+ (*) connection_expiry
+
+     The amount of time in seconds after a connection was last used before we
+     remove it from the connection list.  Whilst a connection is in existence,
+     it serves as a placeholder for negotiated security; when it is deleted,
+     the security must be renegotiated.
+
+ (*) transport_expiry
+
+     The amount of time in seconds after a transport was last used before we
+     remove it from the transport list.  Whilst a transport is in existence, it
+     serves to anchor the peer data and keeps the connection ID counter.
+
+ (*) rxrpc_rx_window_size
+
+     The size of the receive window in packets.  This is the maximum number of
+     unconsumed received packets we're willing to hold in memory for any
+     particular call.
+
+ (*) rxrpc_rx_mtu
+
+     The maximum packet MTU size that we're willing to receive in bytes.  This
+     indicates to the peer whether we're willing to accept jumbo packets.
+
+ (*) rxrpc_rx_jumbo_max
+
+     The maximum number of packets that we're willing to accept in a jumbo
+     packet.  Non-terminal packets in a jumbo packet must contain a four byte
+     header plus exactly 1412 bytes of data.  The terminal packet must contain
+     a four byte header plus any amount of data.  In any event, a jumbo packet
+     may not exceed rxrpc_rx_mtu in size.
diff --git a/Documentation/networking/spider_net.txt b/Documentation/networking/spider_net.txt
index 4b4adb8eb14f..b0b75f8463b3 100644
--- a/Documentation/networking/spider_net.txt
+++ b/Documentation/networking/spider_net.txt
@@ -73,7 +73,7 @@ Thus, in an idle system, the GDACTDPA, tail and head pointers will
 all be pointing at the same descr, which should be "empty". All of the
 other descrs in the ring should be "empty" as well.
 
-The show_rx_chain() routine will print out the the locations of the
+The show_rx_chain() routine will print out the locations of the
 GDACTDPA, tail and head pointers. It will also summarize the contents
 of the ring, starting at the tail pointer, and listing the status
 of the descrs that follow.
diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt
index 7d11bb5dc30a..bdc4c0db51e1 100644
--- a/Documentation/networking/tcp.txt
+++ b/Documentation/networking/tcp.txt
@@ -30,7 +30,7 @@ A congestion control mechanism can be registered through functions in
 tcp_cong.c. The functions used by the congestion control mechanism are
 registered via passing a tcp_congestion_ops struct to
 tcp_register_congestion_control. As a minimum name, ssthresh,
-cong_avoid, min_cwnd must be valid.
+cong_avoid must be valid.
 
 Private data for a congestion control mechanism is stored in tp->ca_priv.
 tcp_ca(tp) returns a pointer to this space.  This is preallocated space - it
diff --git a/Documentation/networking/timestamping.txt b/Documentation/networking/timestamping.txt
index 048c92b487f6..bc3554124903 100644
--- a/Documentation/networking/timestamping.txt
+++ b/Documentation/networking/timestamping.txt
@@ -202,6 +202,9 @@ Time stamps for outgoing packets are to be generated as follows:
   and not free the skb. A driver not supporting hardware time stamping doesn't
   do that. A driver must never touch sk_buff::tstamp! It is used to store
   software generated time stamps by the network subsystem.
+- Driver should call skb_tx_timestamp() as close to passing sk_buff to hardware
+  as possible. skb_tx_timestamp() provides a software time stamp if requested
+  and hardware timestamping is not possible (SKBTX_IN_PROGRESS not set).
 - As soon as the driver has sent the packet and/or obtained a
   hardware time stamp for it, it passes the time stamp back by
   calling skb_hwtstamp_tx() with the original skb, the raw
@@ -212,6 +215,3 @@ Time stamps for outgoing packets are to be generated as follows:
   this would occur at a later time in the processing pipeline than other
   software time stamping and therefore could lead to unexpected deltas
   between time stamps.
-- If the driver did not set the SKBTX_IN_PROGRESS flag (see above), then
-  dev_hard_start_xmit() checks whether software time stamping
-  is wanted as fallback and potentially generates the time stamp.
diff --git a/Documentation/oops-tracing.txt b/Documentation/oops-tracing.txt
index 13032c0140d4..e3155995ddd8 100644
--- a/Documentation/oops-tracing.txt
+++ b/Documentation/oops-tracing.txt
@@ -265,6 +265,9 @@ characters, each representing a particular tainted value.
 
  13: 'O' if an externally-built ("out-of-tree") module has been loaded.
 
+ 14: 'E' if an unsigned module has been loaded in a kernel supporting
+     module signature.
+
 The primary reason for the 'Tainted: ' string is to tell kernel
 debuggers if this is a clean kernel or if anything unusual has
 occurred.  Tainting is permanent: even if an offending module is
diff --git a/Documentation/phy/samsung-usb2.txt b/Documentation/phy/samsung-usb2.txt
new file mode 100644
index 000000000000..ed12d437189d
--- /dev/null
+++ b/Documentation/phy/samsung-usb2.txt
@@ -0,0 +1,135 @@
+.------------------------------------------------------------------------------+
+|                       Samsung USB 2.0 PHY adaptation layer                   |
++-----------------------------------------------------------------------------+'
+
+| 1. Description
++----------------
+
+The architecture of the USB 2.0 PHY module in Samsung SoCs is similar
+among many SoCs. In spite of the similarities it proved difficult to
+create a one driver that would fit all these PHY controllers. Often
+the differences were minor and were found in particular bits of the
+registers of the PHY. In some rare cases the order of register writes or
+the PHY powering up process had to be altered. This adaptation layer is
+a compromise between having separate drivers and having a single driver
+with added support for many special cases.
+
+| 2. Files description
++----------------------
+
+- phy-samsung-usb2.c
+   This is the main file of the adaptation layer. This file contains
+   the probe function and provides two callbacks to the Generic PHY
+   Framework. This two callbacks are used to power on and power off the
+   phy. They carry out the common work that has to be done on all version
+   of the PHY module. Depending on which SoC was chosen they execute SoC
+   specific callbacks. The specific SoC version is selected by choosing
+   the appropriate compatible string. In addition, this file contains
+   struct of_device_id definitions for particular SoCs.
+
+- phy-samsung-usb2.h
+   This is the include file. It declares the structures used by this
+   driver. In addition it should contain extern declarations for
+   structures that describe particular SoCs.
+
+| 3. Supporting SoCs
++--------------------
+
+To support a new SoC a new file should be added to the drivers/phy
+directory. Each SoC's configuration is stored in an instance of the
+struct samsung_usb2_phy_config.
+
+struct samsung_usb2_phy_config {
+        const struct samsung_usb2_common_phy *phys;
+        int (*rate_to_clk)(unsigned long, u32 *);
+        unsigned int num_phys;
+        bool has_mode_switch;
+};
+
+The num_phys is the number of phys handled by the driver. *phys is an
+array that contains the configuration for each phy. The has_mode_switch
+property is a boolean flag that determines whether the SoC has USB host
+and device on a single pair of pins. If so, a special register has to
+be modified to change the internal routing of these pins between a USB
+device or host module.
+
+For example the configuration for Exynos 4210 is following:
+
+const struct samsung_usb2_phy_config exynos4210_usb2_phy_config = {
+        .has_mode_switch        = 0,
+        .num_phys               = EXYNOS4210_NUM_PHYS,
+        .phys                   = exynos4210_phys,
+        .rate_to_clk            = exynos4210_rate_to_clk,
+}
+
+- int (*rate_to_clk)(unsigned long, u32 *)
+        The rate_to_clk callback is to convert the rate of the clock
+        used as the reference clock for the PHY module to the value
+        that should be written in the hardware register.
+
+The exynos4210_phys configuration array is as follows:
+
+static const struct samsung_usb2_common_phy exynos4210_phys[] = {
+        {
+                .label          = "device",
+                .id             = EXYNOS4210_DEVICE,
+                .power_on       = exynos4210_power_on,
+                .power_off      = exynos4210_power_off,
+        },
+        {
+                .label          = "host",
+                .id             = EXYNOS4210_HOST,
+                .power_on       = exynos4210_power_on,
+                .power_off      = exynos4210_power_off,
+        },
+        {
+                .label          = "hsic0",
+                .id             = EXYNOS4210_HSIC0,
+                .power_on       = exynos4210_power_on,
+                .power_off      = exynos4210_power_off,
+        },
+        {
+                .label          = "hsic1",
+                .id             = EXYNOS4210_HSIC1,
+                .power_on       = exynos4210_power_on,
+                .power_off      = exynos4210_power_off,
+        },
+        {},
+};
+
+- int (*power_on)(struct samsung_usb2_phy_instance *);
+- int (*power_off)(struct samsung_usb2_phy_instance *);
+        These two callbacks are used to power on and power off the phy
+        by modifying appropriate registers.
+
+Final change to the driver is adding appropriate compatible value to the
+phy-samsung-usb2.c file. In case of Exynos 4210 the following lines were
+added to the struct of_device_id samsung_usb2_phy_of_match[] array:
+
+#ifdef CONFIG_PHY_EXYNOS4210_USB2
+        {
+                .compatible = "samsung,exynos4210-usb2-phy",
+                .data = &exynos4210_usb2_phy_config,
+        },
+#endif
+
+To add further flexibility to the driver the Kconfig file enables to
+include support for selected SoCs in the compiled driver. The Kconfig
+entry for Exynos 4210 is following:
+
+config PHY_EXYNOS4210_USB2
+        bool "Support for Exynos 4210"
+        depends on PHY_SAMSUNG_USB2
+        depends on CPU_EXYNOS4210
+        help
+          Enable USB PHY support for Exynos 4210. This option requires that
+          Samsung USB 2.0 PHY driver is enabled and means that support for this
+          particular SoC is compiled in the driver. In case of Exynos 4210 four
+          phys are available - device, host, HSCI0 and HSCI1.
+
+The newly created file that supports the new SoC has to be also added to the
+Makefile. In case of Exynos 4210 the added line is following:
+
+obj-$(CONFIG_PHY_EXYNOS4210_USB2)       += phy-exynos4210-usb2.o
+
+After completing these steps the support for the new SoC should be ready.
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index a66c9821b5ce..47d46dff70f7 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -391,7 +391,7 @@ When resuming from freeze, standby or memory sleep, the phases are:
         the resume methods.  This generally involves undoing the actions of the
         preceding suspend_late phase.
 
-    3   The resume methods should bring the the device back to its operating
+    3   The resume methods should bring the device back to its operating
         state, so that it can perform normal I/O.  This generally involves
         undoing the actions of the suspend phase.
 
diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt
index 483632087788..a5da5c7e7128 100644
--- a/Documentation/power/pm_qos_interface.txt
+++ b/Documentation/power/pm_qos_interface.txt
@@ -88,17 +88,19 @@ node.
 
 2. PM QoS per-device latency and flags framework
 
-For each device, there are two lists of PM QoS requests. One is maintained
-along with the aggregated target of latency value and the other is for PM QoS
-flags. Values are updated in response to changes of the request list.
+For each device, there are three lists of PM QoS requests. Two of them are
+maintained along with the aggregated targets of resume latency and active
+state latency tolerance (in microseconds) and the third one is for PM QoS flags.
+Values are updated in response to changes of the request list.
 
-Target latency value is simply the minimum of the request values held in the
-parameter list elements.  The PM QoS flags aggregate value is a gather (bitwise
-OR) of all list elements' values. Two device PM QoS flags are defined currently:
-PM_QOS_FLAG_NO_POWER_OFF and PM_QOS_FLAG_REMOTE_WAKEUP.
+The target values of resume latency and active state latency tolerance are
+simply the minimum of the request values held in the parameter list elements.
+The PM QoS flags aggregate value is a gather (bitwise OR) of all list elements'
+values.  Two device PM QoS flags are defined currently: PM_QOS_FLAG_NO_POWER_OFF
+and PM_QOS_FLAG_REMOTE_WAKEUP.
 
-Note: the aggregated target value is implemented as an atomic variable so that
-reading the aggregated value does not require any locking mechanism.
+Note: The aggregated target values are implemented in such a way that reading
+the aggregated value does not require any locking mechanism.
 
 
 From kernel mode the use of this interface is the following:
@@ -132,19 +134,21 @@ The meaning of the return values is as follows:
         PM_QOS_FLAGS_UNDEFINED: The device's PM QoS structure has not been
                         initialized or the list of requests is empty.
 
-int dev_pm_qos_add_ancestor_request(dev, handle, value)
+int dev_pm_qos_add_ancestor_request(dev, handle, type, value)
 Add a PM QoS request for the first direct ancestor of the given device whose
-power.ignore_children flag is unset.
+power.ignore_children flag is unset (for DEV_PM_QOS_RESUME_LATENCY requests)
+or whose power.set_latency_tolerance callback pointer is not NULL (for
+DEV_PM_QOS_LATENCY_TOLERANCE requests).
 
 int dev_pm_qos_expose_latency_limit(device, value)
-Add a request to the device's PM QoS list of latency constraints and create
-a sysfs attribute pm_qos_resume_latency_us under the device's power directory
-allowing user space to manipulate that request.
+Add a request to the device's PM QoS list of resume latency constraints and
+create a sysfs attribute pm_qos_resume_latency_us under the device's power
+directory allowing user space to manipulate that request.
 
 void dev_pm_qos_hide_latency_limit(device)
 Drop the request added by dev_pm_qos_expose_latency_limit() from the device's
-PM QoS list of latency constraints and remove sysfs attribute pm_qos_resume_latency_us
-from the device's power directory.
+PM QoS list of resume latency constraints and remove sysfs attribute
+pm_qos_resume_latency_us from the device's power directory.
 
 int dev_pm_qos_expose_flags(device, value)
 Add a request to the device's PM QoS list of flags and create sysfs attributes
@@ -163,7 +167,7 @@ a per-device notification tree and a global notification tree.
 int dev_pm_qos_add_notifier(device, notifier):
 Adds a notification callback function for the device.
 The callback is called when the aggregated value of the device constraints list
-is changed.
+is changed (for resume latency device PM QoS only).
 
 int dev_pm_qos_remove_notifier(device, notifier):
 Removes the notification callback function for the device.
@@ -171,14 +175,48 @@ Removes the notification callback function for the device.
 int dev_pm_qos_add_global_notifier(notifier):
 Adds a notification callback function in the global notification tree of the
 framework.
-The callback is called when the aggregated value for any device is changed.
+The callback is called when the aggregated value for any device is changed
+(for resume latency device PM QoS only).
 
 int dev_pm_qos_remove_global_notifier(notifier):
 Removes the notification callback function from the global notification tree
 of the framework.
 
 
-From user mode:
-No API for user space access to the per-device latency constraints is provided
-yet - still under discussion.
-
+Active state latency tolerance
+
+This device PM QoS type is used to support systems in which hardware may switch
+to energy-saving operation modes on the fly.  In those systems, if the operation
+mode chosen by the hardware attempts to save energy in an overly aggressive way,
+it may cause excess latencies to be visible to software, causing it to miss
+certain protocol requirements or target frame or sample rates etc.
+
+If there is a latency tolerance control mechanism for a given device available
+to software, the .set_latency_tolerance callback in that device's dev_pm_info
+structure should be populated.  The routine pointed to by it is should implement
+whatever is necessary to transfer the effective requirement value to the
+hardware.
+
+Whenever the effective latency tolerance changes for the device, its
+.set_latency_tolerance() callback will be executed and the effective value will
+be passed to it.  If that value is negative, which means that the list of
+latency tolerance requirements for the device is empty, the callback is expected
+to switch the underlying hardware latency tolerance control mechanism to an
+autonomous mode if available.  If that value is PM_QOS_LATENCY_ANY, in turn, and
+the hardware supports a special "no requirement" setting, the callback is
+expected to use it.  That allows software to prevent the hardware from
+automatically updating the device's latency tolerance in response to its power
+state changes (e.g. during transitions from D3cold to D0), which generally may
+be done in the autonomous latency tolerance control mode.
+
+If .set_latency_tolerance() is present for the device, sysfs attribute
+pm_qos_latency_tolerance_us will be present in the devivce's power directory.
+Then, user space can use that attribute to specify its latency tolerance
+requirement for the device, if any.  Writing "any" to it means "no requirement,
+but do not let the hardware control latency tolerance" and writing "auto" to it
+allows the hardware to be switched to the autonomous mode if there are no other
+requirements from the kernel side in the device's list.
+
+Kernel code can use the functions described above along with the
+DEV_PM_QOS_LATENCY_TOLERANCE device PM QoS type to add, remove and update
+latency tolerance requirements for devices.
diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt
index b6ce00b2be9a..5f96daf8566a 100644
--- a/Documentation/power/runtime_pm.txt
+++ b/Documentation/power/runtime_pm.txt
@@ -232,7 +232,7 @@ defined in include/linux/pm.h:
       equal to zero); the initial value of it is 1 (i.e. runtime PM is
       initially disabled for all devices)
 
-  unsigned int runtime_error;
+  int runtime_error;
     - if set, there was a fatal error (one of the callbacks returned error code
       as described in Section 2), so the helper funtions will not work until
       this flag is cleared; this is the error code returned by the failing
@@ -401,11 +401,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
   int pm_runtime_disable(struct device *dev);
     - increment the device's 'power.disable_depth' field (if the value of that
       field was previously zero, this prevents subsystem-level runtime PM
-      callbacks from being run for the device), make sure that all of the pending
-      runtime PM operations on the device are either completed or canceled;
-      returns 1 if there was a resume request pending and it was necessary to
-      execute the subsystem-level resume callback for the device to satisfy that
-      request, otherwise 0 is returned
+      callbacks from being run for the device), make sure that all of the
+      pending runtime PM operations on the device are either completed or
+      canceled; returns 1 if there was a resume request pending and it was
+      necessary to execute the subsystem-level resume callback for the device
+      to satisfy that request, otherwise 0 is returned
 
   int pm_runtime_barrier(struct device *dev);
     - check if there's a resume request pending for the device and resume it
@@ -667,11 +667,11 @@ driver/base/power/generic_ops.c:
 
   int pm_generic_runtime_suspend(struct device *dev);
     - invoke the ->runtime_suspend() callback provided by the driver of this
-      device and return its result, or return -EINVAL if not defined
+      device and return its result, or return 0 if not defined
 
   int pm_generic_runtime_resume(struct device *dev);
     - invoke the ->runtime_resume() callback provided by the driver of this
-      device and return its result, or return -EINVAL if not defined
+      device and return its result, or return 0 if not defined
 
   int pm_generic_suspend(struct device *dev);
     - if the device has not been suspended at run time, invoke the ->suspend()
@@ -727,15 +727,12 @@ driver/base/power/generic_ops.c:
   int pm_generic_restore_noirq(struct device *dev);
     - invoke the ->restore_noirq() callback provided by the device's driver
 
-These functions can be assigned to the ->runtime_idle(), ->runtime_suspend(),
+These functions are the defaults used by the PM core, if a subsystem doesn't
+provide its own callbacks for ->runtime_idle(), ->runtime_suspend(),
 ->runtime_resume(), ->suspend(), ->suspend_noirq(), ->resume(),
 ->resume_noirq(), ->freeze(), ->freeze_noirq(), ->thaw(), ->thaw_noirq(),
-->poweroff(), ->poweroff_noirq(), ->restore(), ->restore_noirq() callback
-pointers in the subsystem-level dev_pm_ops structures.
-
-If a subsystem wishes to use all of them at the same time, it can simply assign
-the GENERIC_SUBSYS_PM_OPS macro, defined in include/linux/pm.h, to its
-dev_pm_ops structure pointer.
+->poweroff(), ->poweroff_noirq(), ->restore(), ->restore_noirq() in the
+subsystem-level dev_pm_ops structure.
 
 Device drivers that wish to use the same function as a system suspend, freeze,
 poweroff and runtime suspend callback, and similarly for system resume, thaw,
@@ -873,7 +870,7 @@ Here is a schematic pseudo-code example:
                 foo->is_suspended = 0;
                 pm_runtime_mark_last_busy(&foo->dev);
                 if (foo->num_pending_requests > 0)
-                        foo_process_requests(foo);
+                        foo_process_next_request(foo);
                 unlock(&foo->private_lock);
                 return 0;
         }
diff --git a/Documentation/ptp/testptp.c b/Documentation/ptp/testptp.c
index 4aba0436da65..f1ac2dae999e 100644
--- a/Documentation/ptp/testptp.c
+++ b/Documentation/ptp/testptp.c
@@ -19,6 +19,7 @@
  */
 #include <errno.h>
 #include <fcntl.h>
+#include <inttypes.h>
 #include <math.h>
 #include <signal.h>
 #include <stdio.h>
@@ -120,11 +121,19 @@ static void usage(char *progname)
                 " -i val     index for event/trigger\n"
                 " -k val     measure the time offset between system and phc clock\n"
                 "            for 'val' times (Maximum 25)\n"
+                " -l         list the current pin configuration\n"
+                " -L pin,val configure pin index 'pin' with function 'val'\n"
+                "            the channel index is taken from the '-i' option\n"
+                "            'val' specifies the auxiliary function:\n"
+                "            0 - none\n"
+                "            1 - external time stamp\n"
+                "            2 - periodic output\n"
                 " -p val     enable output with a period of 'val' nanoseconds\n"
                 " -P val     enable or disable (val=1|0) the system clock PPS\n"
                 " -s         set the ptp clock time from the system time\n"
                 " -S         set the system time from the ptp clock time\n"
-                " -t val     shift the ptp clock time by 'val' seconds\n",
+                " -t val     shift the ptp clock time by 'val' seconds\n"
+                " -T val     set the ptp clock time to 'val' seconds\n",
                 progname);
 }
 
@@ -134,6 +143,7 @@ int main(int argc, char *argv[])
         struct ptp_extts_event event;
         struct ptp_extts_request extts_request;
         struct ptp_perout_request perout_request;
+        struct ptp_pin_desc desc;
         struct timespec ts;
         struct timex tx;
 
@@ -156,12 +166,15 @@ int main(int argc, char *argv[])
         int extts = 0;
         int gettime = 0;
         int index = 0;
+        int list_pins = 0;
         int oneshot = 0;
         int pct_offset = 0;
         int n_samples = 0;
         int periodic = 0;
         int perout = -1;
+        int pin_index = -1, pin_func;
         int pps = -1;
+        int seconds = 0;
         int settime = 0;
 
         int64_t t1, t2, tp;
@@ -169,7 +182,7 @@ int main(int argc, char *argv[])
 
         progname = strrchr(argv[0], '/');
         progname = progname ? 1+progname : argv[0];
-        while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:p:P:sSt:v"))) {
+        while (EOF != (c = getopt(argc, argv, "a:A:cd:e:f:ghi:k:lL:p:P:sSt:T:v"))) {
                 switch (c) {
                 case 'a':
                         oneshot = atoi(optarg);
@@ -199,6 +212,16 @@ int main(int argc, char *argv[])
                         pct_offset = 1;
                         n_samples = atoi(optarg);
                         break;
+                case 'l':
+                        list_pins = 1;
+                        break;
+                case 'L':
+                        cnt = sscanf(optarg, "%d,%d", &pin_index, &pin_func);
+                        if (cnt != 2) {
+                                usage(progname);
+                                return -1;
+                        }
+                        break;
                 case 'p':
                         perout = atoi(optarg);
                         break;
@@ -214,6 +237,10 @@ int main(int argc, char *argv[])
                 case 't':
                         adjtime = atoi(optarg);
                         break;
+                case 'T':
+                        settime = 3;
+                        seconds = atoi(optarg);
+                        break;
                 case 'h':
                         usage(progname);
                         return 0;
@@ -245,12 +272,14 @@ int main(int argc, char *argv[])
                                "  %d programmable alarms\n"
                                "  %d external time stamp channels\n"
                                "  %d programmable periodic signals\n"
-                               "  %d pulse per second\n",
+                               "  %d pulse per second\n"
+                               "  %d programmable pins\n",
                                caps.max_adj,
                                caps.n_alarm,
                                caps.n_ext_ts,
                                caps.n_per_out,
-                               caps.pps);
+                               caps.pps,
+                               caps.n_pins);
                 }
         }
 
@@ -304,6 +333,16 @@ int main(int argc, char *argv[])
                 }
         }
 
+        if (settime == 3) {
+                ts.tv_sec = seconds;
+                ts.tv_nsec = 0;
+                if (clock_settime(clkid, &ts)) {
+                        perror("clock_settime");
+                } else {
+                        puts("set time okay");
+                }
+        }
+
         if (extts) {
                 memset(&extts_request, 0, sizeof(extts_request));
                 extts_request.index = index;
@@ -331,6 +370,24 @@ int main(int argc, char *argv[])
                 }
         }
 
+        if (list_pins) {
+                int n_pins = 0;
+                if (ioctl(fd, PTP_CLOCK_GETCAPS, &caps)) {
+                        perror("PTP_CLOCK_GETCAPS");
+                } else {
+                        n_pins = caps.n_pins;
+                }
+                for (i = 0; i < n_pins; i++) {
+                        desc.index = i;
+                        if (ioctl(fd, PTP_PIN_GETFUNC, &desc)) {
+                                perror("PTP_PIN_GETFUNC");
+                                break;
+                        }
+                        printf("name %s index %u func %u chan %u\n",
+                               desc.name, desc.index, desc.func, desc.chan);
+                }
+        }
+
         if (oneshot) {
                 install_handler(SIGALRM, handle_alarm);
                 /* Create a timer. */
@@ -392,6 +449,18 @@ int main(int argc, char *argv[])
                 }
         }
 
+        if (pin_index >= 0) {
+                memset(&desc, 0, sizeof(desc));
+                desc.index = pin_index;
+                desc.func = pin_func;
+                desc.chan = index;
+                if (ioctl(fd, PTP_PIN_SETFUNC, &desc)) {
+                        perror("PTP_PIN_SETFUNC");
+                } else {
+                        puts("set pin function okay");
+                }
+        }
+
         if (pps != -1) {
                 int enable = pps ? 1 : 0;
                 if (ioctl(fd, PTP_ENABLE_PPS, enable)) {
@@ -428,14 +497,14 @@ int main(int argc, char *argv[])
                         interval = t2 - t1;
                         offset = (t2 + t1) / 2 - tp;
 
-                        printf("system time: %ld.%ld\n",
+                        printf("system time: %" PRId64 ".%u\n",
                                 (pct+2*i)->sec, (pct+2*i)->nsec);
-                        printf("phc    time: %ld.%ld\n",
+                        printf("phc    time: %" PRId64 ".%u\n",
                                 (pct+2*i+1)->sec, (pct+2*i+1)->nsec);
-                        printf("system time: %ld.%ld\n",
+                        printf("system time: %" PRId64 ".%u\n",
                                 (pct+2*i+2)->sec, (pct+2*i+2)->nsec);
-                        printf("system/phc clock time offset is %ld ns\n"
-                                "system     clock time delay  is %ld ns\n",
+                        printf("system/phc clock time offset is %" PRId64 " ns\n"
+                               "system     clock time delay  is %" PRId64 " ns\n",
                                 offset, interval);
                 }
 
diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt
index 271438c0617f..47ce9a5336e1 100644
--- a/Documentation/rapidio/sysfs.txt
+++ b/Documentation/rapidio/sysfs.txt
@@ -2,8 +2,8 @@
 
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-1. Device Subdirectories
-------------------------
+1. RapidIO Device Subdirectories
+--------------------------------
 
 For each RapidIO device, the RapidIO subsystem creates files in an individual
 subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>.
@@ -25,8 +25,8 @@ seen by the enumerating host (destID = 1):
 NOTE: An enumerating or discovering endpoint does not create a sysfs entry for
 itself, this is why an endpoint with destID=1 is not shown in the list.
 
-2. Attributes Common for All Devices
-------------------------------------
+2. Attributes Common for All RapidIO Devices
+--------------------------------------------
 
 Each device subdirectory contains the following informational read-only files:
 
@@ -52,16 +52,16 @@ This attribute is similar in behavior to the "config" attribute of PCI devices
 and provides an access to the RapidIO device registers using standard file read
 and write operations.
 
-3. Endpoint Device Attributes
------------------------------
+3. RapidIO Endpoint Device Attributes
+-------------------------------------
 
 Currently Linux RapidIO subsystem does not create any endpoint specific sysfs
 attributes. It is possible that RapidIO master port drivers and endpoint device
 drivers will add their device-specific sysfs attributes but such attributes are
 outside the scope of this document.
 
-4. Switch Device Attributes
----------------------------
+4. RapidIO Switch Device Attributes
+-----------------------------------
 
 RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports
 common and device-specific sysfs attributes for switches. Because switches are
@@ -106,3 +106,53 @@ attribute:
          for that controller always will be 0.
          To initiate RapidIO enumeration/discovery on all available mports
          a user must write '-1' (or RIO_MPORT_ANY) into this attribute file.
+
+
+6. RapidIO Bus Controllers/Ports
+--------------------------------
+
+On-chip RapidIO controllers and PCIe-to-RapidIO bridges (referenced as
+"Master Port" or "mport") are presented in sysfs as the special class of
+devices: "rapidio_port".
+
+The /sys/class/rapidio_port subdirectory contains individual subdirectories
+named as "rapidioN" where N = mport ID registered with RapidIO subsystem.
+
+NOTE: An mport ID is not a RapidIO destination ID assigned to a given local
+mport device.
+
+Each mport device subdirectory in addition to standard entries contains the
+following device-specific attributes:
+
+   port_destid - reports RapidIO destination ID assigned to the given RapidIO
+                 mport device. If value 0xFFFFFFFF is returned this means that
+                 no valid destination ID have been assigned to the mport (yet).
+                 Normally, before enumeration/discovery have been executed only
+                 fabric enumerating mports have a valid destination ID assigned
+                 to them using "hdid=..." rapidio module parameter.
+      sys_size - reports RapidIO common transport system size:
+                   0 = small (8-bit destination ID, max. 256 devices),
+                   1 = large (16-bit destination ID, max. 65536 devices).
+
+After enumeration or discovery was performed for a given mport device,
+the corresponding subdirectory will also contain subdirectories for each
+child RapidIO device connected to the mport. Naming conventions for RapidIO
+devices are described in Section 1 above.
+
+The example below shows mport device subdirectory with several child RapidIO
+devices attached to it.
+
+[rio@rapidio ~]$ ls /sys/class/rapidio_port/rapidio0/ -l
+total 0
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0001
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0004
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:e:0007
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0002
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0003
+drwxr-xr-x 3 root root    0 Feb 11 15:10 00:s:0005
+lrwxrwxrwx 1 root root    0 Feb 11 15:11 device -> ../../../0000:01:00.0
+-r--r--r-- 1 root root 4096 Feb 11 15:11 port_destid
+drwxr-xr-x 2 root root    0 Feb 11 15:11 power
+lrwxrwxrwx 1 root root    0 Feb 11 15:04 subsystem -> ../../../../../../class/rapidio_port
+-r--r--r-- 1 root root 4096 Feb 11 15:11 sys_size
+-rw-r--r-- 1 root root 4096 Feb 11 15:04 uevent
diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt
index 9290de703450..a2f27bbf2cba 100644
--- a/Documentation/scheduler/sched-arch.txt
+++ b/Documentation/scheduler/sched-arch.txt
@@ -8,7 +8,7 @@ Context switch
 By default, the switch_to arch function is called with the runqueue
 locked. This is usually not a problem unless switch_to may need to
 take the runqueue lock. This is usually due to a wake up operation in
-the context switch. See arch/ia64/include/asm/system.h for an example.
+the context switch. See arch/ia64/include/asm/switch_to.h for an example.
 
 To request the scheduler call switch_to with the runqueue unlocked,
 you must `#define __ARCH_WANT_UNLOCKED_CTXSW` in a header file
diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas
index 6edaa65b0818..91ba58ef02d7 100644
--- a/Documentation/scsi/ChangeLog.megaraid_sas
+++ b/Documentation/scsi/ChangeLog.megaraid_sas
@@ -1,3 +1,16 @@
+Release Date    : Mon. Mar 10, 2014 17:00:00 PST 2014 -
+                        (emaild-id:megaraidlinux@lsi.com)
+                        Adam Radford
+                        Kashyap Desai
+                        Sumit Saxena
+Current Version : 06.803.01.00-rc1
+Old Version     : 06.700.06.00-rc1
+    1. Load correct raid context timeout value for multipathing & clustering.
+    2. Fix megasas_ioc_init_fusion to use local stack variable.
+    3. Return leaked MPT frames to MPT command pool.
+    4. Add Dell PowerEdge VRTX SR-IOV VF device support.
+    5. Version and Changelog update.
+-------------------------------------------------------------------------------
 Release Date    : Sat. Aug 31, 2013 17:00:00 PST 2013 -
                         (emaild-id:megaraidlinux@lsi.com)
                         Adam Radford
diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt
index 7a2d30c132e3..5ea996f21d6c 100644
--- a/Documentation/security/Smack.txt
+++ b/Documentation/security/Smack.txt
@@ -3,7 +3,7 @@
     "Good for you, you've decided to clean the elevator!"
     - The Elevator, from Dark Star
 
-Smack is the the Simplified Mandatory Access Control Kernel.
+Smack is the Simplified Mandatory Access Control Kernel.
 Smack is a kernel based implementation of mandatory access
 control that includes simplicity in its primary design goals.
 
diff --git a/Documentation/sgi-visws.txt b/Documentation/sgi-visws.txt
deleted file mode 100644
index 7ff0811ca2ba..000000000000
--- a/Documentation/sgi-visws.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-
-The SGI Visual Workstations (models 320 and 540) are based around
-the Cobalt, Lithium, and Arsenic ASICs.  The Cobalt ASIC is the
-main system ASIC which interfaces the 1-4 IA32 cpus, the memory
-system, and the I/O system in the Lithium ASIC.  The Cobalt ASIC
-also contains the 3D gfx rendering engine which renders to main
-system memory -- part of which is used as the frame buffer which
-is DMA'ed to a video connector using the Arsenic ASIC.  A PIIX4
-chip and NS87307 are used to provide legacy device support (IDE,
-serial, floppy, and parallel).
-
-The Visual Workstation chipset largely conforms to the PC architecture
-with some notable exceptions such as interrupt handling.
diff --git a/Documentation/sound/oss/vwsnd b/Documentation/sound/oss/vwsnd
deleted file mode 100644
index 4c6cbdb3c548..000000000000
--- a/Documentation/sound/oss/vwsnd
+++ /dev/null
@@ -1,293 +0,0 @@
-vwsnd - Sound driver for the Silicon Graphics 320 and 540 Visual
-Workstations' onboard audio.
-
-Copyright 1999 Silicon Graphics, Inc.  All rights reserved.
-
-
-At the time of this writing, March 1999, there are two models of
-Visual Workstation, the 320 and the 540.  This document only describes
-those models.  Future Visual Workstation models may have different
-sound capabilities, and this driver will probably not work on those
-boxes.
-
-The Visual Workstation has an Analog Devices AD1843 "SoundComm" audio
-codec chip.  The AD1843 is accessed through the Cobalt I/O ASIC, also
-known as Lithium.  This driver programs both chips.
-
-==============================================================================
-QUICK CONFIGURATION
-
-        # insmod soundcore
-        # insmod vwsnd
-
-==============================================================================
-I/O CONNECTIONS
-
-On the Visual Workstation, only three of the AD1843 inputs are hooked
-up.  The analog line in jacks are connected to the AD1843's AUX1
-input.  The CD audio lines are connected to the AD1843's AUX2 input.
-The microphone jack is connected to the AD1843's MIC input.  The mic
-jack is mono, but the signal is delivered to both the left and right
-MIC inputs.  You can record in stereo from the mic input, but you will
-get the same signal on both channels (within the limits of A/D
-accuracy).  Full scale on the Line input is +/- 2.0 V.  Full scale on
-the MIC input is 20 dB less, or +/- 0.2 V.
-
-The AD1843's LOUT1 outputs are connected to the Line Out jacks.  The
-AD1843's HPOUT outputs are connected to the speaker/headphone jack.
-LOUT2 is not connected.  Line out's maximum level is +/- 2.0 V peak to
-peak.  The speaker/headphone out's maximum is +/- 4.0 V peak to peak.
-
-The AD1843's PCM input channel and one of its output channels (DAC1)
-are connected to Lithium.  The other output channel (DAC2) is not
-connected.
-
-==============================================================================
-CAPABILITIES
-
-The AD1843 has PCM input and output (Pulse Code Modulation, also known
-as wavetable).  PCM input and output can be mono or stereo in any of
-four formats.  The formats are 16 bit signed and 8 bit unsigned,
-u-Law, and A-Law format.  Any sample rate from 4 KHz to 49 KHz is
-available, in 1 Hz increments.
-
-The AD1843 includes an analog mixer that can mix all three input
-signals (line, mic and CD) into the analog outputs.  The mixer has a
-separate gain control and mute switch for each input.
-
-There are two outputs, line out and speaker/headphone out.  They
-always produce the same signal, and the speaker always has 3 dB more
-gain than the line out.  The speaker/headphone output can be muted,
-but this driver does not export that function.
-
-The hardware can sync audio to the video clock, but this driver does
-not have a way to specify syncing to video.
-
-==============================================================================
-PROGRAMMING
-
-This section explains the API supported by the driver.  Also see the
-Open Sound Programming Guide at http://www.opensound.com/pguide/ .
-This section assumes familiarity with that document.
-
-The driver has two interfaces, an I/O interface and a mixer interface.
-There is no MIDI or sequencer capability.
-
-==============================================================================
-PROGRAMMING PCM I/O
-
-The I/O interface is usually accessed as /dev/audio or /dev/dsp.
-Using the standard Open Sound System (OSS) ioctl calls, the sample
-rate, number of channels, and sample format may be set within the
-limitations described above.  The driver supports triggering.  It also
-supports getting the input and output pointers with one-sample
-accuracy.
-
-The SNDCTL_DSP_GETCAP ioctl returns these capabilities.
-
-        DSP_CAP_DUPLEX - driver supports full duplex.
-
-        DSP_CAP_TRIGGER - driver supports triggering.
-
-        DSP_CAP_REALTIME - values returned by SNDCTL_DSP_GETIPTR
-        and SNDCTL_DSP_GETOPTR are accurate to a few samples.
-
-Memory mapping (mmap) is not implemented.
-
-The driver permits subdivided fragment sizes from 64 to 4096 bytes.
-The number of fragments can be anything from 3 fragments to however
-many fragments fit into 124 kilobytes.  It is up to the user to
-determine how few/small fragments can be used without introducing
-glitches with a given workload.  Linux is not realtime, so we can't
-promise anything.  (sigh...)
-
-When this driver is switched into or out of mu-Law or A-Law mode on
-output, it may produce an audible click.  This is unavoidable.  To
-prevent clicking, use signed 16-bit mode instead, and convert from
-mu-Law or A-Law format in software.
-
-==============================================================================
-PROGRAMMING THE MIXER INTERFACE
-
-The mixer interface is usually accessed as /dev/mixer.  It is accessed
-through ioctls.  The mixer allows the application to control gain or
-mute several audio signal paths, and also allows selection of the
-recording source.
-
-Each of the constants described here can be read using the
-MIXER_READ(SOUND_MIXER_xxx) ioctl.  Those that are not read-only can
-also be written using the MIXER_WRITE(SOUND_MIXER_xxx) ioctl.  In most
-cases, <sys/soundcard.h> defines constants SOUND_MIXER_READ_xxx and
-SOUND_MIXER_WRITE_xxx which work just as well.
-
-SOUND_MIXER_CAPS        Read-only
-
-This is a mask of optional driver capabilities that are implemented.
-This driver's only capability is SOUND_CAP_EXCL_INPUT, which means
-that only one recording source can be active at a time.
-
-SOUND_MIXER_DEVMASK     Read-only
-
-This is a mask of the sound channels.  This driver's channels are PCM,
-LINE, MIC, CD, and RECLEV.
-
-SOUND_MIXER_STEREODEVS  Read-only
-
-This is a mask of which sound channels are capable of stereo.  All
-channels are capable of stereo.  (But see caveat on MIC input in I/O
-CONNECTIONS section above).
-
-SOUND_MIXER_OUTMASK     Read-only
-
-This is a mask of channels that route inputs through to outputs.
-Those are LINE, MIC, and CD.
-
-SOUND_MIXER_RECMASK     Read-only
-
-This is a mask of channels that can be recording sources.  Those are
-PCM, LINE, MIC, CD.
-
-SOUND_MIXER_PCM         Default: 0x5757 (0 dB)
-
-This is the gain control for PCM output.  The left and right channel
-gain are controlled independently.  This gain control has 64 levels,
-which range from -82.5 dB to +12.0 dB in 1.5 dB steps.  Those 64
-levels are mapped onto 100 levels at the ioctl, see below.
-
-SOUND_MIXER_LINE        Default: 0x4a4a (0 dB)
-
-This is the gain control for mixing the Line In source into the
-outputs.  The left and right channel gain are controlled
-independently.  This gain control has 32 levels, which range from
--34.5 dB to +12.0 dB in 1.5 dB steps.  Those 32 levels are mapped onto
-100 levels at the ioctl, see below.
-
-SOUND_MIXER_MIC         Default: 0x4a4a (0 dB)
-
-This is the gain control for mixing the MIC source into the outputs.
-The left and right channel gain are controlled independently.  This
-gain control has 32 levels, which range from -34.5 dB to +12.0 dB in
-1.5 dB steps.  Those 32 levels are mapped onto 100 levels at the
-ioctl, see below.
-
-SOUND_MIXER_CD          Default: 0x4a4a (0 dB)
-
-This is the gain control for mixing the CD audio source into the
-outputs.  The left and right channel gain are controlled
-independently.  This gain control has 32 levels, which range from
--34.5 dB to +12.0 dB in 1.5 dB steps.  Those 32 levels are mapped onto
-100 levels at the ioctl, see below.
-
-SOUND_MIXER_RECLEV       Default: 0 (0 dB)
-
-This is the gain control for PCM input (RECording LEVel).  The left
-and right channel gain are controlled independently.  This gain
-control has 16 levels, which range from 0 dB to +22.5 dB in 1.5 dB
-steps.  Those 16 levels are mapped onto 100 levels at the ioctl, see
-below.
-
-SOUND_MIXER_RECSRC       Default: SOUND_MASK_LINE
-
-This is a mask of currently selected PCM input sources (RECording
-SouRCes).  Because the AD1843 can only have a single recording source
-at a time, only one bit at a time can be set in this mask.  The
-allowable values are SOUND_MASK_PCM, SOUND_MASK_LINE, SOUND_MASK_MIC,
-or SOUND_MASK_CD.  Selecting SOUND_MASK_PCM sets up internal
-resampling which is useful for loopback testing and for hardware
-sample rate conversion.  But software sample rate conversion is
-probably faster, so I don't know how useful that is.
-
-SOUND_MIXER_OUTSRC      DEFAULT: SOUND_MASK_LINE|SOUND_MASK_MIC|SOUND_MASK_CD
-
-This is a mask of sources that are currently passed through to the
-outputs.  Those sources whose bits are not set are muted.
-
-==============================================================================
-GAIN CONTROL
-
-There are five gain controls listed above.  Each has 16, 32, or 64
-steps.  Each control has 1.5 dB of gain per step.  Each control is
-stereo.
-
-The OSS defines the argument to a channel gain ioctl as having two
-components, left and right, each of which ranges from 0 to 100.  The
-two components are packed into the same word, with the left side gain
-in the least significant byte, and the right side gain in the second
-least significant byte.  In C, we would say this.
-
-        #include <assert.h>
-
-        ...
-
-                assert(leftgain >= 0 && leftgain <= 100);
-                assert(rightgain >= 0 && rightgain <= 100);
-                arg = leftgain | rightgain << 8;
-
-So each OSS gain control has 101 steps.  But the hardware has 16, 32,
-or 64 steps.  The hardware steps are spread across the 101 OSS steps
-nearly evenly.  The conversion formulas are like this, given N equals
-16, 32, or 64.
-
-        int round = N/2 - 1;
-        OSS_gain_steps = (hw_gain_steps * 100 + round) / (N - 1);
-        hw_gain_steps = (OSS_gain_steps * (N - 1) + round) / 100;
-
-Here is a snippet of C code that will return the left and right gain
-of any channel in dB.  Pass it one of the predefined gain_desc_t
-structures to access any of the five channels' gains.
-
-        typedef struct gain_desc {
-                float min_gain;
-                float gain_step;
-                int nbits;
-                int chan;
-        } gain_desc_t;
-
-        const gain_desc_t gain_pcm    = { -82.5, 1.5, 6, SOUND_MIXER_PCM    };
-        const gain_desc_t gain_line   = { -34.5, 1.5, 5, SOUND_MIXER_LINE   };
-        const gain_desc_t gain_mic    = { -34.5, 1.5, 5, SOUND_MIXER_MIC    };
-        const gain_desc_t gain_cd     = { -34.5, 1.5, 5, SOUND_MIXER_CD     };
-        const gain_desc_t gain_reclev = {   0.0, 1.5, 4, SOUND_MIXER_RECLEV };
-
-        int get_gain_dB(int fd, const gain_desc_t *gp,
-                        float *left, float *right)
-        {
-                int word;
-                int lg, rg;
-                int mask = (1 << gp->nbits) - 1;
-
-                if (ioctl(fd, MIXER_READ(gp->chan), &word) != 0)
-                        return -1;      /* fail */
-                lg = word & 0xFF;
-                rg = word >> 8 & 0xFF;
-                lg = (lg * mask + mask / 2) / 100;
-                rg = (rg * mask + mask / 2) / 100;
-                *left = gp->min_gain + gp->gain_step * lg;
-                *right = gp->min_gain + gp->gain_step * rg;
-                return 0;
-        }       
-
-And here is the corresponding routine to set a channel's gain in dB.
-
-        int set_gain_dB(int fd, const gain_desc_t *gp, float left, float right)
-        {
-                float max_gain =
-                        gp->min_gain + (1 << gp->nbits) * gp->gain_step;
-                float round = gp->gain_step / 2;
-                int mask = (1 << gp->nbits) - 1;
-                int word;
-                int lg, rg;
-
-                if (left < gp->min_gain || right < gp->min_gain)
-                        return EINVAL;
-                lg = (left - gp->min_gain + round) / gp->gain_step;
-                rg = (right - gp->min_gain + round) / gp->gain_step;
-                if (lg >= (1 << gp->nbits) || rg >= (1 << gp->nbits))
-                        return EINVAL;
-                lg = (100 * lg + mask / 2) / mask;
-                rg = (100 * rg + mask / 2) / mask;
-                word = lg | rg << 8;
-
-                return ioctl(fd, MIXER_WRITE(gp->chan), &word);
-        }
-
diff --git a/Documentation/spi/spidev b/Documentation/spi/spidev
index ed2da5e5b28a..3d14035b1766 100644
--- a/Documentation/spi/spidev
+++ b/Documentation/spi/spidev
@@ -85,6 +85,12 @@ settings for data transfer parameters:
         SPI_MODE_0..SPI_MODE_3; or if you prefer you can combine SPI_CPOL
         (clock polarity, idle high iff this is set) or SPI_CPHA (clock phase,
         sample on trailing edge iff this is set) flags.
+        Note that this request is limited to SPI mode flags that fit in a
+        single byte.
+
+    SPI_IOC_RD_MODE32, SPI_IOC_WR_MODE32 ... pass a pointer to a uin32_t
+        which will return (RD) or assign (WR) the full SPI transfer mode,
+        not limited to the bits that fit in one byte.
 
     SPI_IOC_RD_LSB_FIRST, SPI_IOC_WR_LSB_FIRST ... pass a pointer to a byte
         which will return (RD) or assign (WR) the bit justification used to
diff --git a/Documentation/spi/spidev_fdx.c b/Documentation/spi/spidev_fdx.c
index 36ec0774ca0b..0ea3e51292fc 100644
--- a/Documentation/spi/spidev_fdx.c
+++ b/Documentation/spi/spidev_fdx.c
@@ -78,10 +78,10 @@ static void do_msg(int fd, int len)
 
 static void dumpstat(const char *name, int fd)
 {
-        __u8    mode, lsb, bits;
-        __u32   speed;
+        __u8    lsb, bits;
+        __u32   mode, speed;
 
-        if (ioctl(fd, SPI_IOC_RD_MODE, &mode) < 0) {
+        if (ioctl(fd, SPI_IOC_RD_MODE32, &mode) < 0) {
                 perror("SPI rd_mode");
                 return;
         }
@@ -98,7 +98,7 @@ static void dumpstat(const char *name, int fd)
                 return;
         }
 
-        printf("%s: spi mode %d, %d bits %sper word, %d Hz max\n",
+        printf("%s: spi mode 0x%x, %d bits %sper word, %d Hz max\n",
                 name, mode, bits, lsb ? "(lsb first) " : "", speed);
 }
 
diff --git a/Documentation/spi/spidev_test.c b/Documentation/spi/spidev_test.c
index 16feda901469..3a2f9d59edab 100644
--- a/Documentation/spi/spidev_test.c
+++ b/Documentation/spi/spidev_test.c
@@ -30,7 +30,7 @@ static void pabort(const char *s)
 }
 
 static const char *device = "/dev/spidev1.1";
-static uint8_t mode;
+static uint32_t mode;
 static uint8_t bits = 8;
 static uint32_t speed = 500000;
 static uint16_t delay;
@@ -57,6 +57,21 @@ static void transfer(int fd)
                 .bits_per_word = bits,
         };
 
+        if (mode & SPI_TX_QUAD)
+                tr.tx_nbits = 4;
+        else if (mode & SPI_TX_DUAL)
+                tr.tx_nbits = 2;
+        if (mode & SPI_RX_QUAD)
+                tr.rx_nbits = 4;
+        else if (mode & SPI_RX_DUAL)
+                tr.rx_nbits = 2;
+        if (!(mode & SPI_LOOP)) {
+                if (mode & (SPI_TX_QUAD | SPI_TX_DUAL))
+                        tr.rx_buf = 0;
+                else if (mode & (SPI_RX_QUAD | SPI_RX_DUAL))
+                        tr.tx_buf = 0;
+        }
+
         ret = ioctl(fd, SPI_IOC_MESSAGE(1), &tr);
         if (ret < 1)
                 pabort("can't send spi message");
@@ -81,7 +96,11 @@ static void print_usage(const char *prog)
              "  -O --cpol     clock polarity\n"
              "  -L --lsb      least significant bit first\n"
              "  -C --cs-high  chip select active high\n"
-             "  -3 --3wire    SI/SO signals shared\n");
+             "  -3 --3wire    SI/SO signals shared\n"
+             "  -N --no-cs    no chip select\n"
+             "  -R --ready    slave pulls low to pause\n"
+             "  -2 --dual     dual transfer\n"
+             "  -4 --quad     quad transfer\n");
         exit(1);
 }
 
@@ -101,11 +120,13 @@ static void parse_opts(int argc, char *argv[])
                         { "3wire",   0, 0, '3' },
                         { "no-cs",   0, 0, 'N' },
                         { "ready",   0, 0, 'R' },
+                        { "dual",    0, 0, '2' },
+                        { "quad",    0, 0, '4' },
                         { NULL, 0, 0, 0 },
                 };
                 int c;
 
-                c = getopt_long(argc, argv, "D:s:d:b:lHOLC3NR", lopts, NULL);
+                c = getopt_long(argc, argv, "D:s:d:b:lHOLC3NR24", lopts, NULL);
 
                 if (c == -1)
                         break;
@@ -147,11 +168,23 @@ static void parse_opts(int argc, char *argv[])
                 case 'R':
                         mode |= SPI_READY;
                         break;
+                case '2':
+                        mode |= SPI_TX_DUAL;
+                        break;
+                case '4':
+                        mode |= SPI_TX_QUAD;
+                        break;
                 default:
                         print_usage(argv[0]);
                         break;
                 }
         }
+        if (mode & SPI_LOOP) {
+                if (mode & SPI_TX_DUAL)
+                        mode |= SPI_RX_DUAL;
+                if (mode & SPI_TX_QUAD)
+                        mode |= SPI_RX_QUAD;
+        }
 }
 
 int main(int argc, char *argv[])
@@ -168,11 +201,11 @@ int main(int argc, char *argv[])
         /*
          * spi mode
          */
-        ret = ioctl(fd, SPI_IOC_WR_MODE, &mode);
+        ret = ioctl(fd, SPI_IOC_WR_MODE32, &mode);
         if (ret == -1)
                 pabort("can't set spi mode");
 
-        ret = ioctl(fd, SPI_IOC_RD_MODE, &mode);
+        ret = ioctl(fd, SPI_IOC_RD_MODE32, &mode);
         if (ret == -1)
                 pabort("can't get spi mode");
 
@@ -198,7 +231,7 @@ int main(int argc, char *argv[])
         if (ret == -1)
                 pabort("can't get max speed hz");
 
-        printf("spi mode: %d\n", mode);
+        printf("spi mode: 0x%x\n", mode);
         printf("bits per word: %d\n", bits);
         printf("max speed: %d Hz (%d KHz)\n", speed, speed/1000);
 
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index e55124e7c40c..9886c3d57fc2 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -317,13 +317,15 @@ for more than this value report a warning.
 This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
 
 0: means infinite timeout - no checking done.
+Possible values to set are in range {0..LONG_MAX/HZ}.
 
 ==============================================================
 
-hung_task_warning:
+hung_task_warnings:
 
 The maximum number of warnings to report. During a check interval
-When this value is reached, no more the warnings will be reported.
+if a hung task is detected, this value is decreased by 1.
+When this value reaches 0, no more warnings will be reported.
 This file shows up if CONFIG_DETECT_HUNG_TASK is enabled.
 
 -1: report an infinite number of warnings.
@@ -441,8 +443,7 @@ feature should be disabled. Otherwise, if the system overhead from the
 feature is too high then the rate the kernel samples for NUMA hinting
 faults may be controlled by the numa_balancing_scan_period_min_ms,
 numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms,
-numa_balancing_scan_size_mb, numa_balancing_settle_count sysctls and
-numa_balancing_migrate_deferred.
+numa_balancing_scan_size_mb, and numa_balancing_settle_count sysctls.
 
 ==============================================================
 
@@ -483,13 +484,6 @@ rate for each task.
 numa_balancing_scan_size_mb is how many megabytes worth of pages are
 scanned for a given scan.
 
-numa_balancing_migrate_deferred is how many page migrations get skipped
-unconditionally, after a page migration is skipped because a page is shared
-with other tasks. This reduces page migration overhead, and determines
-how much stronger the "move task near its memory" policy scheduler becomes,
-versus the "move memory near its task" memory management policy, for workloads
-with shared memory.
-
 ==============================================================
 
 osrelease, ostype & version:
@@ -792,6 +786,8 @@ can be ORed together:
 1024 - A module from drivers/staging was loaded.
 2048 - The system is working around a severe firmware bug.
 4096 - An out-of-tree module has been loaded.
+8192 - An unsigned module has been loaded in a kernel supporting module
+       signature.
 
 ==============================================================
 
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index d614a9b6a280..dd9d0e33b443 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -175,18 +175,39 @@ Setting this to zero disables periodic writeback altogether.
 
 drop_caches
 
-Writing to this will cause the kernel to drop clean caches, dentries and
-inodes from memory, causing that memory to become free.
+Writing to this will cause the kernel to drop clean caches, as well as
+reclaimable slab objects like dentries and inodes.  Once dropped, their
+memory becomes free.
 
 To free pagecache:
         echo 1 > /proc/sys/vm/drop_caches
-To free dentries and inodes:
+To free reclaimable slab objects (includes dentries and inodes):
         echo 2 > /proc/sys/vm/drop_caches
-To free pagecache, dentries and inodes:
+To free slab objects and pagecache:
         echo 3 > /proc/sys/vm/drop_caches
 
-As this is a non-destructive operation and dirty objects are not freeable, the
-user should run `sync' first.
+This is a non-destructive operation and will not free any dirty objects.
+To increase the number of objects freed by this operation, the user may run
+`sync' prior to writing to /proc/sys/vm/drop_caches.  This will minimize the
+number of dirty objects on the system and create more candidates to be
+dropped.
+
+This file is not a means to control the growth of the various kernel caches
+(inodes, dentries, pagecache, etc...)  These objects are automatically
+reclaimed by the kernel when memory is needed elsewhere on the system.
+
+Use of this file can cause performance problems.  Since it discards cached
+objects, it may cost a significant amount of I/O and CPU to recreate the
+dropped objects, especially if they were under heavy use.  Because of this,
+use outside of a testing or debugging environment is not recommended.
+
+You may see informational messages in your kernel log when this file is
+used:
+
+        cat (1234): drop_caches: 3
+
+These are informational only.  They do not mean that anything is wrong
+with your system.  To disable them, echo 4 (bit 3) into drop_caches.
 
 ==============================================================
 
diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt
index 3bd33b8dc7c4..21d514ced212 100644
--- a/Documentation/trace/events-power.txt
+++ b/Documentation/trace/events-power.txt
@@ -92,5 +92,5 @@ dev_pm_qos_remove_request          "device=%s type=%s new_value=%d"
 
 The first parameter gives the device name which tries to add/update/remove
 QoS requests.
-The second parameter gives the request type (e.g. "DEV_PM_QOS_LATENCY").
+The second parameter gives the request type (e.g. "DEV_PM_QOS_RESUME_LATENCY").
 The third parameter is value to be added/updated/removed.
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt
index 79fcafc7fd64..3f669b9e8852 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -358,11 +358,8 @@ Every arch has an init callback function.  If you need to do something early on
 to initialize some state, this is the time to do that.  Otherwise, this simple
 function below should be sufficient for most people:
 
-int __init ftrace_dyn_arch_init(void *data)
+int __init ftrace_dyn_arch_init(void)
 {
-        /* return value is done indirectly via data */
-        *(unsigned long *)data = 0;
-
         return 0;
 }
 
diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.txt
index 7d350b496585..ff747b6fa39b 100644
--- a/Documentation/trace/ring-buffer-design.txt
+++ b/Documentation/trace/ring-buffer-design.txt
@@ -683,7 +683,7 @@ against nested writers.
   cmpxchg(tail_page, temp_page, next_page)
 
 The above will update the tail page if it is still pointing to the expected
-page. If this fails, a nested write pushed it forward, the the current write
+page. If this fails, a nested write pushed it forward, the current write
 does not need to push it.
 
 
diff --git a/Documentation/usb/WUSB-Design-overview.txt b/Documentation/usb/WUSB-Design-overview.txt
index 4c5e37939344..1cd07c017cf6 100644
--- a/Documentation/usb/WUSB-Design-overview.txt
+++ b/Documentation/usb/WUSB-Design-overview.txt
@@ -25,7 +25,7 @@ updated content.
     * Design-overview.txt-1.8
 
 This code implements a Ultra Wide Band stack for Linux, as well as
-drivers for the the USB based UWB radio controllers defined in the
+drivers for the USB based UWB radio controllers defined in the
 Wireless USB 1.0 specification (including Wireless USB host controller
 and an Intel WiNET controller).
 
diff --git a/Documentation/video4linux/CARDLIST.bttv b/Documentation/video4linux/CARDLIST.bttv
index f14475011fea..2f6e93597ce0 100644
--- a/Documentation/video4linux/CARDLIST.bttv
+++ b/Documentation/video4linux/CARDLIST.bttv
@@ -163,3 +163,4 @@
 162 -> Adlink MPG24
 163 -> Bt848 Capture 14MHz
 164 -> CyberVision CV06 (SV)
+165 -> Kworld V-Stream Xpert TV PVR878
diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885
index 9f056d512e35..fc009d0ee7d6 100644
--- a/Documentation/video4linux/CARDLIST.cx23885
+++ b/Documentation/video4linux/CARDLIST.cx23885
@@ -31,10 +31,13 @@
  30 -> NetUP Dual DVB-T/C-CI RF                            [1b55:e2e4]
  31 -> Leadtek Winfast PxDVR3200 H XC4000                  [107d:6f39]
  32 -> MPX-885
- 33 -> Mygica X8507                                        [14f1:8502]
+ 33 -> Mygica X8502/X8507 ISDB-T                           [14f1:8502]
  34 -> TerraTec Cinergy T PCIe Dual                        [153b:117e]
  35 -> TeVii S471                                          [d471:9022]
  36 -> Hauppauge WinTV-HVR1255                             [0070:2259]
  37 -> Prof Revolution DVB-S2 8000                         [8000:3034]
  38 -> Hauppauge WinTV-HVR4400                             [0070:c108,0070:c138,0070:c12a,0070:c1f8]
  39 -> AVerTV Hybrid Express Slim HC81R                    [1461:d939]
+ 40 -> TurboSight TBS 6981                                 [6981:8888]
+ 41 -> TurboSight TBS 6980                                 [6980:8888]
+ 42 -> Leadtek Winfast PxPVR2200                           [107d:6f21]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index e81864405102..e085b1243b45 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -57,6 +57,7 @@
  56 -> Pinnacle Hybrid Pro (330e)               (em2882)        [2304:0226]
  57 -> Kworld PlusTV HD Hybrid 330              (em2883)        [eb1a:a316]
  58 -> Compro VideoMate ForYou/Stereo           (em2820/em2840) [185b:2041]
+ 59 -> Pinnacle PCTV HD Mini                    (em2874)        [2304:023f]
  60 -> Hauppauge WinTV HVR 850                  (em2883)        [2040:651f]
  61 -> Pixelview PlayTV Box 4 USB 2.0           (em2820/em2840)
  62 -> Gadmei TVR200                            (em2820/em2840)
@@ -86,3 +87,8 @@
  86 -> PCTV QuatroStick nano (520e)             (em2884)        [2013:0251]
  87 -> Terratec Cinergy HTC USB XS              (em2884)        [0ccd:008e,0ccd:00ac]
  88 -> C3 Tech Digital Duo HDTV/SDTV USB        (em2884)        [1b80:e755]
+ 89 -> Delock 61959                             (em2874)        [1b80:e1cc]
+ 90 -> KWorld USB ATSC TV Stick UB435-Q V2      (em2874)        [1b80:e346]
+ 91 -> SpeedLink Vicious And Devine Laplace webcam (em2765)        [1ae7:9003,1ae7:9004]
+ 92 -> PCTV DVB-S2 Stick (461e)                 (em28178)
+ 93 -> KWorld USB ATSC TV Stick UB435-Q V3      (em2874)        [1b80:e34c]
diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt
index e51f1b5b7324..7d6e160724bd 100644
--- a/Documentation/video4linux/fimc.txt
+++ b/Documentation/video4linux/fimc.txt
@@ -151,9 +151,8 @@ CONFIG_S5P_DEV_FIMC1  \
 CONFIG_S5P_DEV_FIMC2  |    optional
 CONFIG_S5P_DEV_FIMC3  |
 CONFIG_S5P_SETUP_FIMC /
-CONFIG_S5P_SETUP_MIPIPHY \
-CONFIG_S5P_DEV_CSIS0     | optional for MIPI-CSI interface
-CONFIG_S5P_DEV_CSIS1     /
+CONFIG_S5P_DEV_CSIS0  \    optional for MIPI-CSI interface
+CONFIG_S5P_DEV_CSIS1  /
 
 Except that, relevant s5p_device_fimc? should be registered in the machine code
 in addition to a "s5p-fimc-md" platform device to which the media device driver
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index 1e6b6531bbcc..d2ba80bb7af5 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -55,6 +55,7 @@ zc3xx		0458:700f	Genius VideoCam Web V2
 sonixj          0458:7025       Genius Eye 311Q
 sn9c20x         0458:7029       Genius Look 320s
 sonixj          0458:702e       Genius Slim 310 NB
+sn9c20x         0458:7045       Genius Look 1320 V2
 sn9c20x         0458:704a       Genius Slim 1320
 sn9c20x         0458:704c       Genius i-Look 1321
 sn9c20x         045e:00f4       LifeCam VX-6000 (SN9C20x + OV9650)
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 6c4866b49eb5..667a43361706 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -34,6 +34,10 @@ So this framework sets up the basic building blocks that all drivers
 need and this same framework should make it much easier to refactor
 common code into utility functions shared by all drivers.
 
+A good example to look at as a reference is the v4l2-pci-skeleton.c
+source that is available in this directory. It is a skeleton driver for
+a PCI capture card, and demonstrates how to use the V4L2 driver
+framework. It can be used as a template for real PCI video capture driver.
 
 Structure of a driver
 ---------------------
@@ -768,6 +772,7 @@ types exist:
 VFL_TYPE_GRABBER: videoX for video input/output devices
 VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
 VFL_TYPE_RADIO: radioX for radio tuners
+VFL_TYPE_SDR: swradioX for Software Defined Radio tuners
 
 The last argument gives you a certain amount of control over the device
 device node number used (i.e. the X in videoX). Normally you will pass -1
diff --git a/Documentation/video4linux/v4l2-pci-skeleton.c b/Documentation/video4linux/v4l2-pci-skeleton.c
new file mode 100644
index 000000000000..3a1c0d2dafce
--- /dev/null
+++ b/Documentation/video4linux/v4l2-pci-skeleton.c
@@ -0,0 +1,913 @@
+/*
+ * This is a V4L2 PCI Skeleton Driver. It gives an initial skeleton source
+ * for use with other PCI drivers.
+ *
+ * This skeleton PCI driver assumes that the card has an S-Video connector as
+ * input 0 and an HDMI connector as input 1.
+ *
+ * Copyright 2014 Cisco Systems, Inc. and/or its affiliates. All rights reserved.
+ *
+ * This program is free software; you may redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
+ * MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
+ * BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
+ * ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
+ * CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+ * SOFTWARE.
+ */
+
+#include <linux/types.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/init.h>
+#include <linux/kmod.h>
+#include <linux/mutex.h>
+#include <linux/pci.h>
+#include <linux/interrupt.h>
+#include <linux/videodev2.h>
+#include <linux/v4l2-dv-timings.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-dev.h>
+#include <media/v4l2-ioctl.h>
+#include <media/v4l2-dv-timings.h>
+#include <media/v4l2-ctrls.h>
+#include <media/v4l2-event.h>
+#include <media/videobuf2-dma-contig.h>
+
+MODULE_DESCRIPTION("V4L2 PCI Skeleton Driver");
+MODULE_AUTHOR("Hans Verkuil");
+MODULE_LICENSE("GPL v2");
+MODULE_DEVICE_TABLE(pci, skeleton_pci_tbl);
+
+/**
+ * struct skeleton - All internal data for one instance of device
+ * @pdev: PCI device
+ * @v4l2_dev: top-level v4l2 device struct
+ * @vdev: video node structure
+ * @ctrl_handler: control handler structure
+ * @lock: ioctl serialization mutex
+ * @std: current SDTV standard
+ * @timings: current HDTV timings
+ * @format: current pix format
+ * @input: current video input (0 = SDTV, 1 = HDTV)
+ * @queue: vb2 video capture queue
+ * @alloc_ctx: vb2 contiguous DMA context
+ * @qlock: spinlock controlling access to buf_list and sequence
+ * @buf_list: list of buffers queued for DMA
+ * @sequence: frame sequence counter
+ */
+struct skeleton {
+        struct pci_dev *pdev;
+        struct v4l2_device v4l2_dev;
+        struct video_device vdev;
+        struct v4l2_ctrl_handler ctrl_handler;
+        struct mutex lock;
+        v4l2_std_id std;
+        struct v4l2_dv_timings timings;
+        struct v4l2_pix_format format;
+        unsigned input;
+
+        struct vb2_queue queue;
+        struct vb2_alloc_ctx *alloc_ctx;
+
+        spinlock_t qlock;
+        struct list_head buf_list;
+        unsigned int sequence;
+};
+
+struct skel_buffer {
+        struct vb2_buffer vb;
+        struct list_head list;
+};
+
+static inline struct skel_buffer *to_skel_buffer(struct vb2_buffer *vb2)
+{
+        return container_of(vb2, struct skel_buffer, vb);
+}
+
+static const struct pci_device_id skeleton_pci_tbl[] = {
+        /* { PCI_DEVICE(PCI_VENDOR_ID_, PCI_DEVICE_ID_) }, */
+        { 0, }
+};
+
+/*
+ * HDTV: this structure has the capabilities of the HDTV receiver.
+ * It is used to constrain the huge list of possible formats based
+ * upon the hardware capabilities.
+ */
+static const struct v4l2_dv_timings_cap skel_timings_cap = {
+        .type = V4L2_DV_BT_656_1120,
+        /* keep this initialization for compatibility with GCC < 4.4.6 */
+        .reserved = { 0 },
+        V4L2_INIT_BT_TIMINGS(
+                720, 1920,              /* min/max width */
+                480, 1080,              /* min/max height */
+                27000000, 74250000,     /* min/max pixelclock*/
+                V4L2_DV_BT_STD_CEA861,  /* Supported standards */
+                /* capabilities */
+                V4L2_DV_BT_CAP_INTERLACED | V4L2_DV_BT_CAP_PROGRESSIVE
+        )
+};
+
+/*
+ * Supported SDTV standards. This does the same job as skel_timings_cap, but
+ * for standard TV formats.
+ */
+#define SKEL_TVNORMS V4L2_STD_ALL
+
+/*
+ * Interrupt handler: typically interrupts happen after a new frame has been
+ * captured. It is the job of the handler to remove the new frame from the
+ * internal list and give it back to the vb2 framework, updating the sequence
+ * counter and timestamp at the same time.
+ */
+static irqreturn_t skeleton_irq(int irq, void *dev_id)
+{
+#ifdef TODO
+        struct skeleton *skel = dev_id;
+
+        /* handle interrupt */
+
+        /* Once a new frame has been captured, mark it as done like this: */
+        if (captured_new_frame) {
+                ...
+                spin_lock(&skel->qlock);
+                list_del(&new_buf->list);
+                spin_unlock(&skel->qlock);
+                new_buf->vb.v4l2_buf.sequence = skel->sequence++;
+                v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
+                vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE);
+        }
+#endif
+        return IRQ_HANDLED;
+}
+
+/*
+ * Setup the constraints of the queue: besides setting the number of planes
+ * per buffer and the size and allocation context of each plane, it also
+ * checks if sufficient buffers have been allocated. Usually 3 is a good
+ * minimum number: many DMA engines need a minimum of 2 buffers in the
+ * queue and you need to have another available for userspace processing.
+ */
+static int queue_setup(struct vb2_queue *vq, const struct v4l2_format *fmt,
+                       unsigned int *nbuffers, unsigned int *nplanes,
+                       unsigned int sizes[], void *alloc_ctxs[])
+{
+        struct skeleton *skel = vb2_get_drv_priv(vq);
+
+        if (vq->num_buffers + *nbuffers < 3)
+                *nbuffers = 3 - vq->num_buffers;
+
+        if (fmt && fmt->fmt.pix.sizeimage < skel->format.sizeimage)
+                return -EINVAL;
+        *nplanes = 1;
+        sizes[0] = fmt ? fmt->fmt.pix.sizeimage : skel->format.sizeimage;
+        alloc_ctxs[0] = skel->alloc_ctx;
+        return 0;
+}
+
+/*
+ * Prepare the buffer for queueing to the DMA engine: check and set the
+ * payload size and fill in the field. Note: if the format's field is
+ * V4L2_FIELD_ALTERNATE, then vb->v4l2_buf.field should be set in the
+ * interrupt handler since that's usually where you know if the TOP or
+ * BOTTOM field has been captured.
+ */
+static int buffer_prepare(struct vb2_buffer *vb)
+{
+        struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue);
+        unsigned long size = skel->format.sizeimage;
+
+        if (vb2_plane_size(vb, 0) < size) {
+                dev_err(&skel->pdev->dev, "buffer too small (%lu < %lu)\n",
+                         vb2_plane_size(vb, 0), size);
+                return -EINVAL;
+        }
+
+        vb2_set_plane_payload(vb, 0, size);
+        vb->v4l2_buf.field = skel->format.field;
+        return 0;
+}
+
+/*
+ * Queue this buffer to the DMA engine.
+ */
+static void buffer_queue(struct vb2_buffer *vb)
+{
+        struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue);
+        struct skel_buffer *buf = to_skel_buffer(vb);
+        unsigned long flags;
+
+        spin_lock_irqsave(&skel->qlock, flags);
+        list_add_tail(&buf->list, &skel->buf_list);
+
+        /* TODO: Update any DMA pointers if necessary */
+
+        spin_unlock_irqrestore(&skel->qlock, flags);
+}
+
+static void return_all_buffers(struct skeleton *skel,
+                               enum vb2_buffer_state state)
+{
+        struct skel_buffer *buf, *node;
+        unsigned long flags;
+
+        spin_lock_irqsave(&skel->qlock, flags);
+        list_for_each_entry_safe(buf, node, &skel->buf_list, list) {
+                vb2_buffer_done(&buf->vb, state);
+                list_del(&buf->list);
+        }
+        spin_unlock_irqrestore(&skel->qlock, flags);
+}
+
+/*
+ * Start streaming. First check if the minimum number of buffers have been
+ * queued. If not, then return -ENOBUFS and the vb2 framework will call
+ * this function again the next time a buffer has been queued until enough
+ * buffers are available to actually start the DMA engine.
+ */
+static int start_streaming(struct vb2_queue *vq, unsigned int count)
+{
+        struct skeleton *skel = vb2_get_drv_priv(vq);
+        int ret = 0;
+
+        skel->sequence = 0;
+
+        /* TODO: start DMA */
+
+        if (ret) {
+                /*
+                 * In case of an error, return all active buffers to the
+                 * QUEUED state
+                 */
+                return_all_buffers(skel, VB2_BUF_STATE_QUEUED);
+        }
+        return ret;
+}
+
+/*
+ * Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued
+ * and passed on to the vb2 framework marked as STATE_ERROR.
+ */
+static int stop_streaming(struct vb2_queue *vq)
+{
+        struct skeleton *skel = vb2_get_drv_priv(vq);
+
+        /* TODO: stop DMA */
+
+        /* Release all active buffers */
+        return_all_buffers(skel, VB2_BUF_STATE_ERROR);
+        return 0;
+}
+
+/*
+ * The vb2 queue ops. Note that since q->lock is set we can use the standard
+ * vb2_ops_wait_prepare/finish helper functions. If q->lock would be NULL,
+ * then this driver would have to provide these ops.
+ */
+static struct vb2_ops skel_qops = {
+        .queue_setup            = queue_setup,
+        .buf_prepare            = buffer_prepare,
+        .buf_queue              = buffer_queue,
+        .start_streaming        = start_streaming,
+        .stop_streaming         = stop_streaming,
+        .wait_prepare           = vb2_ops_wait_prepare,
+        .wait_finish            = vb2_ops_wait_finish,
+};
+
+/*
+ * Required ioctl querycap. Note that the version field is prefilled with
+ * the version of the kernel.
+ */
+static int skeleton_querycap(struct file *file, void *priv,
+                             struct v4l2_capability *cap)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        strlcpy(cap->driver, KBUILD_MODNAME, sizeof(cap->driver));
+        strlcpy(cap->card, "V4L2 PCI Skeleton", sizeof(cap->card));
+        snprintf(cap->bus_info, sizeof(cap->bus_info), "PCI:%s",
+                 pci_name(skel->pdev));
+        cap->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_READWRITE |
+                           V4L2_CAP_STREAMING;
+        cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+        return 0;
+}
+
+/*
+ * Helper function to check and correct struct v4l2_pix_format. It's used
+ * not only in VIDIOC_TRY/S_FMT, but also elsewhere if changes to the SDTV
+ * standard, HDTV timings or the video input would require updating the
+ * current format.
+ */
+static void skeleton_fill_pix_format(struct skeleton *skel,
+                                     struct v4l2_pix_format *pix)
+{
+        pix->pixelformat = V4L2_PIX_FMT_YUYV;
+        if (skel->input == 0) {
+                /* S-Video input */
+                pix->width = 720;
+                pix->height = (skel->std & V4L2_STD_525_60) ? 480 : 576;
+                pix->field = V4L2_FIELD_INTERLACED;
+                pix->colorspace = V4L2_COLORSPACE_SMPTE170M;
+        } else {
+                /* HDMI input */
+                pix->width = skel->timings.bt.width;
+                pix->height = skel->timings.bt.height;
+                if (skel->timings.bt.interlaced)
+                        pix->field = V4L2_FIELD_INTERLACED;
+                else
+                        pix->field = V4L2_FIELD_NONE;
+                pix->colorspace = V4L2_COLORSPACE_REC709;
+        }
+
+        /*
+         * The YUYV format is four bytes for every two pixels, so bytesperline
+         * is width * 2.
+         */
+        pix->bytesperline = pix->width * 2;
+        pix->sizeimage = pix->bytesperline * pix->height;
+        pix->priv = 0;
+}
+
+static int skeleton_try_fmt_vid_cap(struct file *file, void *priv,
+                                    struct v4l2_format *f)
+{
+        struct skeleton *skel = video_drvdata(file);
+        struct v4l2_pix_format *pix = &f->fmt.pix;
+
+        /*
+         * Due to historical reasons providing try_fmt with an unsupported
+         * pixelformat will return -EINVAL for video receivers. Webcam drivers,
+         * however, will silently correct the pixelformat. Some video capture
+         * applications rely on this behavior...
+         */
+        if (pix->pixelformat != V4L2_PIX_FMT_YUYV)
+                return -EINVAL;
+        skeleton_fill_pix_format(skel, pix);
+        return 0;
+}
+
+static int skeleton_s_fmt_vid_cap(struct file *file, void *priv,
+                                  struct v4l2_format *f)
+{
+        struct skeleton *skel = video_drvdata(file);
+        int ret;
+
+        ret = skeleton_try_fmt_vid_cap(file, priv, f);
+        if (ret)
+                return ret;
+
+        /*
+         * It is not allowed to change the format while buffers for use with
+         * streaming have already been allocated.
+         */
+        if (vb2_is_busy(&skel->queue))
+                return -EBUSY;
+
+        /* TODO: change format */
+        skel->format = f->fmt.pix;
+        return 0;
+}
+
+static int skeleton_g_fmt_vid_cap(struct file *file, void *priv,
+                                  struct v4l2_format *f)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        f->fmt.pix = skel->format;
+        return 0;
+}
+
+static int skeleton_enum_fmt_vid_cap(struct file *file, void *priv,
+                                     struct v4l2_fmtdesc *f)
+{
+        if (f->index != 0)
+                return -EINVAL;
+
+        strlcpy(f->description, "4:2:2, packed, YUYV", sizeof(f->description));
+        f->pixelformat = V4L2_PIX_FMT_YUYV;
+        f->flags = 0;
+        return 0;
+}
+
+static int skeleton_s_std(struct file *file, void *priv, v4l2_std_id std)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* S_STD is not supported on the HDMI input */
+        if (skel->input)
+                return -ENODATA;
+
+        /*
+         * No change, so just return. Some applications call S_STD again after
+         * the buffers for streaming have been set up, so we have to allow for
+         * this behavior.
+         */
+        if (std == skel->std)
+                return 0;
+
+        /*
+         * Changing the standard implies a format change, which is not allowed
+         * while buffers for use with streaming have already been allocated.
+         */
+        if (vb2_is_busy(&skel->queue))
+                return -EBUSY;
+
+        /* TODO: handle changing std */
+
+        skel->std = std;
+
+        /* Update the internal format */
+        skeleton_fill_pix_format(skel, &skel->format);
+        return 0;
+}
+
+static int skeleton_g_std(struct file *file, void *priv, v4l2_std_id *std)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* G_STD is not supported on the HDMI input */
+        if (skel->input)
+                return -ENODATA;
+
+        *std = skel->std;
+        return 0;
+}
+
+/*
+ * Query the current standard as seen by the hardware. This function shall
+ * never actually change the standard, it just detects and reports.
+ * The framework will initially set *std to tvnorms (i.e. the set of
+ * supported standards by this input), and this function should just AND
+ * this value. If there is no signal, then *std should be set to 0.
+ */
+static int skeleton_querystd(struct file *file, void *priv, v4l2_std_id *std)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* QUERY_STD is not supported on the HDMI input */
+        if (skel->input)
+                return -ENODATA;
+
+#ifdef TODO
+        /*
+         * Query currently seen standard. Initial value of *std is
+         * V4L2_STD_ALL. This function should look something like this:
+         */
+        get_signal_info();
+        if (no_signal) {
+                *std = 0;
+                return 0;
+        }
+        /* Use signal information to reduce the number of possible standards */
+        if (signal_has_525_lines)
+                *std &= V4L2_STD_525_60;
+        else
+                *std &= V4L2_STD_625_50;
+#endif
+        return 0;
+}
+
+static int skeleton_s_dv_timings(struct file *file, void *_fh,
+                                 struct v4l2_dv_timings *timings)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* S_DV_TIMINGS is not supported on the S-Video input */
+        if (skel->input == 0)
+                return -ENODATA;
+
+        /* Quick sanity check */
+        if (!v4l2_valid_dv_timings(timings, &skel_timings_cap, NULL, NULL))
+                return -EINVAL;
+
+        /* Check if the timings are part of the CEA-861 timings. */
+        if (!v4l2_find_dv_timings_cap(timings, &skel_timings_cap,
+                                      0, NULL, NULL))
+                return -EINVAL;
+
+        /* Return 0 if the new timings are the same as the current timings. */
+        if (v4l2_match_dv_timings(timings, &skel->timings, 0))
+                return 0;
+
+        /*
+         * Changing the timings implies a format change, which is not allowed
+         * while buffers for use with streaming have already been allocated.
+         */
+        if (vb2_is_busy(&skel->queue))
+                return -EBUSY;
+
+        /* TODO: Configure new timings */
+
+        /* Save timings */
+        skel->timings = *timings;
+
+        /* Update the internal format */
+        skeleton_fill_pix_format(skel, &skel->format);
+        return 0;
+}
+
+static int skeleton_g_dv_timings(struct file *file, void *_fh,
+                                 struct v4l2_dv_timings *timings)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* G_DV_TIMINGS is not supported on the S-Video input */
+        if (skel->input == 0)
+                return -ENODATA;
+
+        *timings = skel->timings;
+        return 0;
+}
+
+static int skeleton_enum_dv_timings(struct file *file, void *_fh,
+                                    struct v4l2_enum_dv_timings *timings)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* ENUM_DV_TIMINGS is not supported on the S-Video input */
+        if (skel->input == 0)
+                return -ENODATA;
+
+        return v4l2_enum_dv_timings_cap(timings, &skel_timings_cap,
+                                        NULL, NULL);
+}
+
+/*
+ * Query the current timings as seen by the hardware. This function shall
+ * never actually change the timings, it just detects and reports.
+ * If no signal is detected, then return -ENOLINK. If the hardware cannot
+ * lock to the signal, then return -ENOLCK. If the signal is out of range
+ * of the capabilities of the system (e.g., it is possible that the receiver
+ * can lock but that the DMA engine it is connected to cannot handle
+ * pixelclocks above a certain frequency), then -ERANGE is returned.
+ */
+static int skeleton_query_dv_timings(struct file *file, void *_fh,
+                                     struct v4l2_dv_timings *timings)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* QUERY_DV_TIMINGS is not supported on the S-Video input */
+        if (skel->input == 0)
+                return -ENODATA;
+
+#ifdef TODO
+        /*
+         * Query currently seen timings. This function should look
+         * something like this:
+         */
+        detect_timings();
+        if (no_signal)
+                return -ENOLINK;
+        if (cannot_lock_to_signal)
+                return -ENOLCK;
+        if (signal_out_of_range_of_capabilities)
+                return -ERANGE;
+
+        /* Useful for debugging */
+        v4l2_print_dv_timings(skel->v4l2_dev.name, "query_dv_timings:",
+                        timings, true);
+#endif
+        return 0;
+}
+
+static int skeleton_dv_timings_cap(struct file *file, void *fh,
+                                   struct v4l2_dv_timings_cap *cap)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        /* DV_TIMINGS_CAP is not supported on the S-Video input */
+        if (skel->input == 0)
+                return -ENODATA;
+        *cap = skel_timings_cap;
+        return 0;
+}
+
+static int skeleton_enum_input(struct file *file, void *priv,
+                               struct v4l2_input *i)
+{
+        if (i->index > 1)
+                return -EINVAL;
+
+        i->type = V4L2_INPUT_TYPE_CAMERA;
+        if (i->index == 0) {
+                i->std = SKEL_TVNORMS;
+                strlcpy(i->name, "S-Video", sizeof(i->name));
+                i->capabilities = V4L2_IN_CAP_STD;
+        } else {
+                i->std = 0;
+                strlcpy(i->name, "HDMI", sizeof(i->name));
+                i->capabilities = V4L2_IN_CAP_DV_TIMINGS;
+        }
+        return 0;
+}
+
+static int skeleton_s_input(struct file *file, void *priv, unsigned int i)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        if (i > 1)
+                return -EINVAL;
+
+        /*
+         * Changing the input implies a format change, which is not allowed
+         * while buffers for use with streaming have already been allocated.
+         */
+        if (vb2_is_busy(&skel->queue))
+                return -EBUSY;
+
+        skel->input = i;
+        /*
+         * Update tvnorms. The tvnorms value is used by the core to implement
+         * VIDIOC_ENUMSTD so it has to be correct. If tvnorms == 0, then
+         * ENUMSTD will return -ENODATA.
+         */
+        skel->vdev.tvnorms = i ? 0 : SKEL_TVNORMS;
+
+        /* Update the internal format */
+        skeleton_fill_pix_format(skel, &skel->format);
+        return 0;
+}
+
+static int skeleton_g_input(struct file *file, void *priv, unsigned int *i)
+{
+        struct skeleton *skel = video_drvdata(file);
+
+        *i = skel->input;
+        return 0;
+}
+
+/* The control handler. */
+static int skeleton_s_ctrl(struct v4l2_ctrl *ctrl)
+{
+        /*struct skeleton *skel =
+                container_of(ctrl->handler, struct skeleton, ctrl_handler);*/
+
+        switch (ctrl->id) {
+        case V4L2_CID_BRIGHTNESS:
+                /* TODO: set brightness to ctrl->val */
+                break;
+        case V4L2_CID_CONTRAST:
+                /* TODO: set contrast to ctrl->val */
+                break;
+        case V4L2_CID_SATURATION:
+                /* TODO: set saturation to ctrl->val */
+                break;
+        case V4L2_CID_HUE:
+                /* TODO: set hue to ctrl->val */
+                break;
+        default:
+                return -EINVAL;
+        }
+        return 0;
+}
+
+/* ------------------------------------------------------------------
+        File operations for the device
+   ------------------------------------------------------------------*/
+
+static const struct v4l2_ctrl_ops skel_ctrl_ops = {
+        .s_ctrl = skeleton_s_ctrl,
+};
+
+/*
+ * The set of all supported ioctls. Note that all the streaming ioctls
+ * use the vb2 helper functions that take care of all the locking and
+ * that also do ownership tracking (i.e. only the filehandle that requested
+ * the buffers can call the streaming ioctls, all other filehandles will
+ * receive -EBUSY if they attempt to call the same streaming ioctls).
+ *
+ * The last three ioctls also use standard helper functions: these implement
+ * standard behavior for drivers with controls.
+ */
+static const struct v4l2_ioctl_ops skel_ioctl_ops = {
+        .vidioc_querycap = skeleton_querycap,
+        .vidioc_try_fmt_vid_cap = skeleton_try_fmt_vid_cap,
+        .vidioc_s_fmt_vid_cap = skeleton_s_fmt_vid_cap,
+        .vidioc_g_fmt_vid_cap = skeleton_g_fmt_vid_cap,
+        .vidioc_enum_fmt_vid_cap = skeleton_enum_fmt_vid_cap,
+
+        .vidioc_g_std = skeleton_g_std,
+        .vidioc_s_std = skeleton_s_std,
+        .vidioc_querystd = skeleton_querystd,
+
+        .vidioc_s_dv_timings = skeleton_s_dv_timings,
+        .vidioc_g_dv_timings = skeleton_g_dv_timings,
+        .vidioc_enum_dv_timings = skeleton_enum_dv_timings,
+        .vidioc_query_dv_timings = skeleton_query_dv_timings,
+        .vidioc_dv_timings_cap = skeleton_dv_timings_cap,
+
+        .vidioc_enum_input = skeleton_enum_input,
+        .vidioc_g_input = skeleton_g_input,
+        .vidioc_s_input = skeleton_s_input,
+
+        .vidioc_reqbufs = vb2_ioctl_reqbufs,
+        .vidioc_create_bufs = vb2_ioctl_create_bufs,
+        .vidioc_querybuf = vb2_ioctl_querybuf,
+        .vidioc_qbuf = vb2_ioctl_qbuf,
+        .vidioc_dqbuf = vb2_ioctl_dqbuf,
+        .vidioc_expbuf = vb2_ioctl_expbuf,
+        .vidioc_streamon = vb2_ioctl_streamon,
+        .vidioc_streamoff = vb2_ioctl_streamoff,
+
+        .vidioc_log_status = v4l2_ctrl_log_status,
+        .vidioc_subscribe_event = v4l2_ctrl_subscribe_event,
+        .vidioc_unsubscribe_event = v4l2_event_unsubscribe,
+};
+
+/*
+ * The set of file operations. Note that all these ops are standard core
+ * helper functions.
+ */
+static const struct v4l2_file_operations skel_fops = {
+        .owner = THIS_MODULE,
+        .open = v4l2_fh_open,
+        .release = vb2_fop_release,
+        .unlocked_ioctl = video_ioctl2,
+        .read = vb2_fop_read,
+        .mmap = vb2_fop_mmap,
+        .poll = vb2_fop_poll,
+};
+
+/*
+ * The initial setup of this device instance. Note that the initial state of
+ * the driver should be complete. So the initial format, standard, timings
+ * and video input should all be initialized to some reasonable value.
+ */
+static int skeleton_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
+{
+        /* The initial timings are chosen to be 720p60. */
+        static const struct v4l2_dv_timings timings_def =
+                V4L2_DV_BT_CEA_1280X720P60;
+        struct skeleton *skel;
+        struct video_device *vdev;
+        struct v4l2_ctrl_handler *hdl;
+        struct vb2_queue *q;
+        int ret;
+
+        /* Enable PCI */
+        ret = pci_enable_device(pdev);
+        if (ret)
+                return ret;
+        ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
+        if (ret) {
+                dev_err(&pdev->dev, "no suitable DMA available.\n");
+                goto disable_pci;
+        }
+
+        /* Allocate a new instance */
+        skel = devm_kzalloc(&pdev->dev, sizeof(struct skeleton), GFP_KERNEL);
+        if (!skel)
+                return -ENOMEM;
+
+        /* Allocate the interrupt */
+        ret = devm_request_irq(&pdev->dev, pdev->irq,
+                               skeleton_irq, 0, KBUILD_MODNAME, skel);
+        if (ret) {
+                dev_err(&pdev->dev, "request_irq failed\n");
+                goto disable_pci;
+        }
+        skel->pdev = pdev;
+
+        /* Fill in the initial format-related settings */
+        skel->timings = timings_def;
+        skel->std = V4L2_STD_625_50;
+        skeleton_fill_pix_format(skel, &skel->format);
+
+        /* Initialize the top-level structure */
+        ret = v4l2_device_register(&pdev->dev, &skel->v4l2_dev);
+        if (ret)
+                goto disable_pci;
+
+        mutex_init(&skel->lock);
+
+        /* Add the controls */
+        hdl = &skel->ctrl_handler;
+        v4l2_ctrl_handler_init(hdl, 4);
+        v4l2_ctrl_new_std(hdl, &skel_ctrl_ops,
+                          V4L2_CID_BRIGHTNESS, 0, 255, 1, 127);
+        v4l2_ctrl_new_std(hdl, &skel_ctrl_ops,
+                          V4L2_CID_CONTRAST, 0, 255, 1, 16);
+        v4l2_ctrl_new_std(hdl, &skel_ctrl_ops,
+                          V4L2_CID_SATURATION, 0, 255, 1, 127);
+        v4l2_ctrl_new_std(hdl, &skel_ctrl_ops,
+                          V4L2_CID_HUE, -128, 127, 1, 0);
+        if (hdl->error) {
+                ret = hdl->error;
+                goto free_hdl;
+        }
+        skel->v4l2_dev.ctrl_handler = hdl;
+
+        /* Initialize the vb2 queue */
+        q = &skel->queue;
+        q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+        q->io_modes = VB2_MMAP | VB2_DMABUF | VB2_READ;
+        q->drv_priv = skel;
+        q->buf_struct_size = sizeof(struct skel_buffer);
+        q->ops = &skel_qops;
+        q->mem_ops = &vb2_dma_contig_memops;
+        q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
+        /*
+         * Assume that this DMA engine needs to have at least two buffers
+         * available before it can be started. The start_streaming() op
+         * won't be called until at least this many buffers are queued up.
+         */
+        q->min_buffers_needed = 2;
+        /*
+         * The serialization lock for the streaming ioctls. This is the same
+         * as the main serialization lock, but if some of the non-streaming
+         * ioctls could take a long time to execute, then you might want to
+         * have a different lock here to prevent VIDIOC_DQBUF from being
+         * blocked while waiting for another action to finish. This is
+         * generally not needed for PCI devices, but USB devices usually do
+         * want a separate lock here.
+         */
+        q->lock = &skel->lock;
+        /*
+         * Since this driver can only do 32-bit DMA we must make sure that
+         * the vb2 core will allocate the buffers in 32-bit DMA memory.
+         */
+        q->gfp_flags = GFP_DMA32;
+        ret = vb2_queue_init(q);
+        if (ret)
+                goto free_hdl;
+
+        skel->alloc_ctx = vb2_dma_contig_init_ctx(&pdev->dev);
+        if (IS_ERR(skel->alloc_ctx)) {
+                dev_err(&pdev->dev, "Can't allocate buffer context");
+                ret = PTR_ERR(skel->alloc_ctx);
+                goto free_hdl;
+        }
+        INIT_LIST_HEAD(&skel->buf_list);
+        spin_lock_init(&skel->qlock);
+
+        /* Initialize the video_device structure */
+        vdev = &skel->vdev;
+        strlcpy(vdev->name, KBUILD_MODNAME, sizeof(vdev->name));
+        /*
+         * There is nothing to clean up, so release is set to an empty release
+         * function. The release callback must be non-NULL.
+         */
+        vdev->release = video_device_release_empty;
+        vdev->fops = &skel_fops,
+        vdev->ioctl_ops = &skel_ioctl_ops,
+        /*
+         * The main serialization lock. All ioctls are serialized by this
+         * lock. Exception: if q->lock is set, then the streaming ioctls
+         * are serialized by that separate lock.
+         */
+        vdev->lock = &skel->lock;
+        vdev->queue = q;
+        vdev->v4l2_dev = &skel->v4l2_dev;
+        /* Supported SDTV standards, if any */
+        vdev->tvnorms = SKEL_TVNORMS;
+        /* If this bit is set, then the v4l2 core will provide the support
+         * for the VIDIOC_G/S_PRIORITY ioctls. This flag will eventually
+         * go away once all drivers have been converted to use struct v4l2_fh.
+         */
+        set_bit(V4L2_FL_USE_FH_PRIO, &vdev->flags);
+        video_set_drvdata(vdev, skel);
+
+        ret = video_register_device(vdev, VFL_TYPE_GRABBER, -1);
+        if (ret)
+                goto free_ctx;
+
+        dev_info(&pdev->dev, "V4L2 PCI Skeleton Driver loaded\n");
+        return 0;
+
+free_ctx:
+        vb2_dma_contig_cleanup_ctx(skel->alloc_ctx);
+free_hdl:
+        v4l2_ctrl_handler_free(&skel->ctrl_handler);
+        v4l2_device_unregister(&skel->v4l2_dev);
+disable_pci:
+        pci_disable_device(pdev);
+        return ret;
+}
+
+static void skeleton_remove(struct pci_dev *pdev)
+{
+        struct v4l2_device *v4l2_dev = pci_get_drvdata(pdev);
+        struct skeleton *skel = container_of(v4l2_dev, struct skeleton, v4l2_dev);
+
+        video_unregister_device(&skel->vdev);
+        v4l2_ctrl_handler_free(&skel->ctrl_handler);
+        vb2_dma_contig_cleanup_ctx(skel->alloc_ctx);
+        v4l2_device_unregister(&skel->v4l2_dev);
+        pci_disable_device(skel->pdev);
+}
+
+static struct pci_driver skeleton_driver = {
+        .name = KBUILD_MODNAME,
+        .probe = skeleton_probe,
+        .remove = skeleton_remove,
+        .id_table = skeleton_pci_tbl,
+};
+
+module_pci_driver(skeleton_driver);
diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 6cd63a9010fb..a9380ba54c8e 100644
--- a/Documentation/virtual/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
@@ -586,8 +586,8 @@ struct kvm_fpu {
 
 4.24 KVM_CREATE_IRQCHIP
 
-Capability: KVM_CAP_IRQCHIP
-Architectures: x86, ia64, ARM, arm64
+Capability: KVM_CAP_IRQCHIP, KVM_CAP_S390_IRQCHIP (s390)
+Architectures: x86, ia64, ARM, arm64, s390
 Type: vm ioctl
 Parameters: none
 Returns: 0 on success, -1 on error
@@ -596,7 +596,10 @@ Creates an interrupt controller model in the kernel.  On x86, creates a virtual
 ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a
 local APIC.  IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23
 only go to the IOAPIC.  On ia64, a IOSAPIC is created. On ARM/arm64, a GIC is
-created.
+created. On s390, a dummy irq routing table is created.
+
+Note that on s390 the KVM_CAP_S390_IRQCHIP vm capability needs to be enabled
+before KVM_CREATE_IRQCHIP can be used.
 
 
 4.25 KVM_IRQ_LINE
@@ -612,6 +615,20 @@ On some architectures it is required that an interrupt controller model has
 been previously created with KVM_CREATE_IRQCHIP.  Note that edge-triggered
 interrupts require the level to be set to 1 and then back to 0.
 
+On real hardware, interrupt pins can be active-low or active-high.  This
+does not matter for the level field of struct kvm_irq_level: 1 always
+means active (asserted), 0 means inactive (deasserted).
+
+x86 allows the operating system to program the interrupt polarity
+(active-low/active-high) for level-triggered interrupts, and KVM used
+to consider the polarity.  However, due to bitrot in the handling of
+active-low interrupts, the above convention is now valid on x86 too.
+This is signaled by KVM_CAP_X86_IOAPIC_POLARITY_IGNORED.  Userspace
+should not present interrupts to the guest as active-low unless this
+capability is present (or unless it is not using the in-kernel irqchip,
+of course).
+
+
 ARM/arm64 can signal an interrupt either at the CPU level, or at the
 in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to
 use PPIs designated for specific cpus.  The irq field is interpreted
@@ -628,7 +645,7 @@ The irq_type field has the following values:
 
 (The irq_id field thus corresponds nicely to the IRQ ID in the ARM GIC specs)
 
-In both cases, level is used to raise/lower the line.
+In both cases, level is used to assert/deassert the line.
 
 struct kvm_irq_level {
         union {
@@ -918,9 +935,9 @@ documentation when it pops into existence).
 
 4.37 KVM_ENABLE_CAP
 
-Capability: KVM_CAP_ENABLE_CAP
+Capability: KVM_CAP_ENABLE_CAP, KVM_CAP_ENABLE_CAP_VM
 Architectures: ppc, s390
-Type: vcpu ioctl
+Type: vcpu ioctl, vm ioctl (with KVM_CAP_ENABLE_CAP_VM)
 Parameters: struct kvm_enable_cap (in)
 Returns: 0 on success; -1 on error
 
@@ -951,6 +968,8 @@ function properly, this is the place to put them.
        __u8  pad[64];
 };
 
+The vcpu ioctl should be used for vcpu-specific capabilities, the vm ioctl
+for vm-wide capabilities.
 
 4.38 KVM_GET_MP_STATE
 
@@ -1320,7 +1339,7 @@ KVM_ASSIGN_DEV_IRQ. Partial deassignment of host or guest IRQ is allowed.
 4.52 KVM_SET_GSI_ROUTING
 
 Capability: KVM_CAP_IRQ_ROUTING
-Architectures: x86 ia64
+Architectures: x86 ia64 s390
 Type: vm ioctl
 Parameters: struct kvm_irq_routing (in)
 Returns: 0 on success, -1 on error
@@ -1343,6 +1362,7 @@ struct kvm_irq_routing_entry {
         union {
                 struct kvm_irq_routing_irqchip irqchip;
                 struct kvm_irq_routing_msi msi;
+                struct kvm_irq_routing_s390_adapter adapter;
                 __u32 pad[8];
         } u;
 };
@@ -1350,6 +1370,7 @@ struct kvm_irq_routing_entry {
 /* gsi routing entry types */
 #define KVM_IRQ_ROUTING_IRQCHIP 1
 #define KVM_IRQ_ROUTING_MSI 2
+#define KVM_IRQ_ROUTING_S390_ADAPTER 3
 
 No flags are specified so far, the corresponding field must be set to zero.
 
@@ -1365,6 +1386,14 @@ struct kvm_irq_routing_msi {
         __u32 pad;
 };
 
+struct kvm_irq_routing_s390_adapter {
+        __u64 ind_addr;
+        __u64 summary_addr;
+        __u64 ind_offset;
+        __u32 summary_offset;
+        __u32 adapter_id;
+};
+
 
 4.53 KVM_ASSIGN_SET_MSIX_NR
 
@@ -1462,7 +1491,7 @@ struct kvm_lapic_state {
         char regs[KVM_APIC_REG_SIZE];
 };
 
-Copies the input argument into the the Local APIC registers.  The data format
+Copies the input argument into the Local APIC registers.  The data format
 and layout are the same as documented in the architecture manual.
 
 
@@ -2566,6 +2595,10 @@ 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.
 
+The 'data' member contains, in its first 'len' bytes, the value as it would
+appear if the VCPU performed a load or store of the appropriate width directly
+to the byte array.
+
 NOTE: For KVM_EXIT_IO, KVM_EXIT_MMIO, KVM_EXIT_OSI, KVM_EXIT_DCR,
       KVM_EXIT_PAPR and KVM_EXIT_EPR the corresponding
 operations are complete (and guest state is consistent) only after userspace
diff --git a/Documentation/virtual/kvm/devices/s390_flic.txt b/Documentation/virtual/kvm/devices/s390_flic.txt
new file mode 100644
index 000000000000..4ceef53164b0
--- /dev/null
+++ b/Documentation/virtual/kvm/devices/s390_flic.txt
@@ -0,0 +1,91 @@
+FLIC (floating interrupt controller)
+====================================
+
+FLIC handles floating (non per-cpu) interrupts, i.e. I/O, service and some
+machine check interruptions. All interrupts are stored in a per-vm list of
+pending interrupts. FLIC performs operations on this list.
+
+Only one FLIC instance may be instantiated.
+
+FLIC provides support to
+- add interrupts (KVM_DEV_FLIC_ENQUEUE)
+- inspect currently pending interrupts (KVM_FLIC_GET_ALL_IRQS)
+- purge all pending floating interrupts (KVM_DEV_FLIC_CLEAR_IRQS)
+- enable/disable for the guest transparent async page faults
+- register and modify adapter interrupt sources (KVM_DEV_FLIC_ADAPTER_*)
+
+Groups:
+  KVM_DEV_FLIC_ENQUEUE
+    Passes a buffer and length into the kernel which are then injected into
+    the list of pending interrupts.
+    attr->addr contains the pointer to the buffer and attr->attr contains
+    the length of the buffer.
+    The format of the data structure kvm_s390_irq as it is copied from userspace
+    is defined in usr/include/linux/kvm.h.
+
+  KVM_DEV_FLIC_GET_ALL_IRQS
+    Copies all floating interrupts into a buffer provided by userspace.
+    When the buffer is too small it returns -ENOMEM, which is the indication
+    for userspace to try again with a bigger buffer.
+    All interrupts remain pending, i.e. are not deleted from the list of
+    currently pending interrupts.
+    attr->addr contains the userspace address of the buffer into which all
+    interrupt data will be copied.
+    attr->attr contains the size of the buffer in bytes.
+
+  KVM_DEV_FLIC_CLEAR_IRQS
+    Simply deletes all elements from the list of currently pending floating
+    interrupts.  No interrupts are injected into the guest.
+
+  KVM_DEV_FLIC_APF_ENABLE
+    Enables async page faults for the guest. So in case of a major page fault
+    the host is allowed to handle this async and continues the guest.
+
+  KVM_DEV_FLIC_APF_DISABLE_WAIT
+    Disables async page faults for the guest and waits until already pending
+    async page faults are done. This is necessary to trigger a completion interrupt
+    for every init interrupt before migrating the interrupt list.
+
+  KVM_DEV_FLIC_ADAPTER_REGISTER
+    Register an I/O adapter interrupt source. Takes a kvm_s390_io_adapter
+    describing the adapter to register:
+
+struct kvm_s390_io_adapter {
+        __u32 id;
+        __u8 isc;
+        __u8 maskable;
+        __u8 swap;
+        __u8 pad;
+};
+
+   id contains the unique id for the adapter, isc the I/O interruption subclass
+   to use, maskable whether this adapter may be masked (interrupts turned off)
+   and swap whether the indicators need to be byte swapped.
+
+
+  KVM_DEV_FLIC_ADAPTER_MODIFY
+    Modifies attributes of an existing I/O adapter interrupt source. Takes
+    a kvm_s390_io_adapter_req specifiying the adapter and the operation:
+
+struct kvm_s390_io_adapter_req {
+        __u32 id;
+        __u8 type;
+        __u8 mask;
+        __u16 pad0;
+        __u64 addr;
+};
+
+    id specifies the adapter and type the operation. The supported operations
+    are:
+
+    KVM_S390_IO_ADAPTER_MASK
+      mask or unmask the adapter, as specified in mask
+
+    KVM_S390_IO_ADAPTER_MAP
+      perform a gmap translation for the guest address provided in addr,
+      pin a userspace page for the translated address and add it to the
+      list of mappings
+
+    KVM_S390_IO_ADAPTER_UNMAP
+      release a userspace page for the translated address specified in addr
+      from the list of mappings
diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt
index a68db7692ee8..744f82f86c58 100644
--- a/Documentation/vm/unevictable-lru.txt
+++ b/Documentation/vm/unevictable-lru.txt
@@ -453,7 +453,7 @@ putback_lru_page() function to add migrated pages back to the LRU.
 mmap(MAP_LOCKED) SYSTEM CALL HANDLING
 -------------------------------------
 
-In addition the the mlock()/mlockall() system calls, an application can request
+In addition the mlock()/mlockall() system calls, an application can request
 that a region of memory be mlocked supplying the MAP_LOCKED flag to the mmap()
 call.  Furthermore, any mmap() call or brk() call that expands the heap by a
 task that has previously called mlockall() with the MCL_FUTURE flag will result
diff --git a/Documentation/w1/masters/ds2490 b/Documentation/w1/masters/ds2490
index 28176def3d6f..3e091151dd80 100644
--- a/Documentation/w1/masters/ds2490
+++ b/Documentation/w1/masters/ds2490
@@ -21,8 +21,6 @@ Notes and limitations.
 - The weak pullup current is a minimum of 0.9mA and maximum of 6.0mA.
 - The 5V strong pullup is supported with a minimum of 5.9mA and a
   maximum of 30.4 mA.  (From DS2490.pdf)
-- While the ds2490 supports a hardware search the code doesn't take
-  advantage of it (in tested case it only returned first device).
 - The hardware will detect when devices are attached to the bus on the
   next bus (reset?) operation, however only a message is printed as
   the core w1 code doesn't make use of the information.  Connecting
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink
index f59a31965d50..927a52cc0519 100644
--- a/Documentation/w1/w1.netlink
+++ b/Documentation/w1/w1.netlink
@@ -5,8 +5,8 @@ Message types.
 =============
 
 There are three types of messages between w1 core and userspace:
-1. Events. They are generated each time new master or slave device
-        found either due to automatic or requested search.
+1. Events. They are generated each time a new master or slave device
+        is found either due to automatic or requested search.
 2. Userspace commands.
 3. Replies to userspace commands.
 
@@ -131,7 +131,7 @@ of the w1_netlink_cmd structure and cn_msg.len will be equal to the sum
 of the sizeof(struct w1_netlink_msg) and sizeof(struct w1_netlink_cmd).
 If reply is generated for master or root command (which do not have
 w1_netlink_cmd attached), reply will contain only cn_msg and w1_netlink_msg
-structires.
+structures.
 
 w1_netlink_msg.status field will carry positive error value
 (EINVAL for example) or zero in case of success.
@@ -160,7 +160,7 @@ procedure is started to select given device.
 Then all requested in w1_netlink_msg operations are performed one by one.
 If command requires reply (like read command) it is sent on command completion.
 
-When all commands (w1_netlink_cmd) are processed muster device is unlocked
+When all commands (w1_netlink_cmd) are processed master device is unlocked
 and next w1_netlink_msg header processing started.
 
 
diff --git a/Documentation/watchdog/watchdog-parameters.txt b/Documentation/watchdog/watchdog-parameters.txt
index f9492fed4104..692791cc674c 100644
--- a/Documentation/watchdog/watchdog-parameters.txt
+++ b/Documentation/watchdog/watchdog-parameters.txt
@@ -150,6 +150,8 @@ nowayout: Disable watchdog shutdown on close
 -------------------------------------------------
 it87_wdt:
 nogameport: Forbid the activation of game port, default=0
+nocir: Forbid the use of CIR (workaround for some buggy setups); set to 1 if
+system resets despite watchdog daemon running, default=0
 exclusive: Watchdog exclusive device open, default=1
 timeout: Watchdog timeout in seconds, default=60
 testmode: Watchdog test mode (1 = no reboot), default=0
@@ -325,6 +327,11 @@ soft_noboot: Softdog action, set to 1 to ignore reboots, 0 to reboot
 stmp3xxx_wdt:
 heartbeat: Watchdog heartbeat period in seconds from 1 to 4194304, default 19
 -------------------------------------------------
+tegra_wdt:
+heartbeat: Watchdog heartbeats in seconds. (default = 120)
+nowayout: Watchdog cannot be stopped once started
+        (default=kernel config parameter)
+-------------------------------------------------
 ts72xx_wdt:
 timeout: Watchdog timeout in seconds. (1 <= timeout <= 8, default=8)
 nowayout: Disable watchdog shutdown on close
diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt
index cb81741d3b0b..a75e3adaa39d 100644
--- a/Documentation/x86/boot.txt
+++ b/Documentation/x86/boot.txt
@@ -182,7 +182,7 @@ Offset	Proto	Name		Meaning
 0226/1  2.02+(3 ext_loader_ver  Extended boot loader version
 0227/1  2.02+(3 ext_loader_type Extended boot loader ID
 0228/4  2.02+   cmd_line_ptr    32-bit pointer to the kernel command line
-022C/4  2.03+   ramdisk_max     Highest legal initrd address
+022C/4  2.03+   initrd_addr_max Highest legal initrd address
 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
@@ -534,7 +534,7 @@ Protocol:	2.02+
   zero, the kernel will assume that your boot loader does not support
   the 2.02+ protocol.
 
-Field name:     ramdisk_max
+Field name:     initrd_addr_max
 Type:           read
 Offset/size:    0x22c/4
 Protocol:       2.03+
diff --git a/Documentation/zh_CN/SubmittingPatches b/Documentation/zh_CN/SubmittingPatches
index be0bd4725062..1d3a10f8746b 100644
--- a/Documentation/zh_CN/SubmittingPatches
+++ b/Documentation/zh_CN/SubmittingPatches
@@ -82,10 +82,6 @@ Documentation/SubmittingDrivers 。
 Quilt:
 http://savannah.nongnu.org/projects/quilt
 
-Andrew Morton 的补丁脚本:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-作为这些脚本的替代，quilt 是值得推荐的补丁管理工具(看上面的链接)。
-
 2)描述你的改动。
 描述你的改动包含的技术细节。
 
@@ -394,7 +390,7 @@ Static inline 函数相比宏来说，是好得多的选择。Static inline 函�
 ----------------
 
 Andrew Morton, "The perfect patch" (tpp).
-  <http://userweb.kernel.org/~akpm/stuff/tpp.txt>
+  <http://www.ozlabs.org/~akpm/stuff/tpp.txt>
 
 Jeff Garzik, "Linux kernel patch submission format".
   <http://linux.yyz.us/patch-format.html>
@@ -406,7 +402,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
   <http://www.kroah.com/log/2006/01/11/>
 
 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
-  <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2>
+  <https://lkml.org/lkml/2005/7/11/336>
 
 Kernel Documentation/CodingStyle:
   <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle>