Merge Linus' tree to be be to apply submitted patches to newer code than

current trivial.git base
2014-11-20 14:42:02 +01:00
parent eff264efee fc14f9c127
commit a02001086b
12063 changed files with 593833 additions and 390844 deletions
--- a/.gitignore
+++ b/.gitignore
@@ -34,6 +34,7 @@
 *.gcno
 modules.builtin
 Module.symvers
 *.dwo
 #
 # Top-level generic files
--- a/7
+++ b/7
@@ -1381,6 +1381,9 @@ S: 17 rue Danton
 S: F - 94270 Le Kremlin-Bicêtre
 S: France
 N: Jack Hammer
 D: IBM ServeRAID RAID (ips) driver maintenance
 N: Greg Hankins
 E: gregh@cc.gatech.edu
 D: fixed keyboard driver to separate LED and locking status
@@ -1691,6 +1694,10 @@ S: Reading
 S: RG6 2NU
 S: United Kingdom
 N: Dave Jeffery
 E: dhjeffery@gmail.com
 D: SCSI hacks and IBM ServeRAID RAID driver maintenance
 N: Jakub Jelinek
 E: jakub@redhat.com
 W: http://sunsite.mff.cuni.cz/~jj
--- a/Documentation/.gitignore
+++ b/Documentation/.gitignore
@@ -1,7 +0,0 @@
 filesystems/dnotify_test
 laptops/dslm
 timers/hpet_example
 vm/hugepage-mmap
 vm/hugepage-shm
 vm/map_hugetlb
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -287,6 +287,8 @@ local_ops.txt
 	- semantics and behavior of local atomic operations.
 lockdep-design.txt
 	- documentation on the runtime locking correctness validator.
 locking/
 	- directory with info about kernel locking primitives
 lockstat.txt
 	- info on collecting statistics on locks (and contention).
 lockup-watchdogs.txt
--- a/Documentation/ABI/removed/net_dma
+++ b/Documentation/ABI/removed/net_dma
@@ -0,0 +1,8 @@
 What:		tcp_dma_copybreak sysctl
 Date:		Removed in kernel v3.13
 Contact:	Dan Williams <dan.j.williams@intel.com>
 Description:
 	Formerly the lower limit, in bytes, of the size of socket reads
 	that will be offloaded to a DMA copy engine.  Removed due to
 	coherency issues of the cpu potentially touching the buffers
 	while dma is in flight.
--- a/Documentation/ABI/stable/sysfs-devices-node
+++ b/Documentation/ABI/stable/sysfs-devices-node
@@ -85,14 +85,6 @@ Description:
 		will be compacted. When it completes, memory will be freed
 		into blocks which have as many contiguous pages as possible
 What:		/sys/devices/system/node/nodeX/scan_unevictable_pages
 Date:		October 2008
 Contact:	Lee Schermerhorn <lee.schermerhorn@hp.com>
 Description:
 		When set, it triggers scanning the node's unevictable lists
 		and move any pages that have become evictable onto the respective
 		zone's inactive list. See mm/vmscan.c
 What:		/sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
 Date:		December 2009
 Contact:	Lee Schermerhorn <lee.schermerhorn@hp.com>
--- a/Documentation/ABI/testing/configfs-usb-gadget-uac1
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1
@@ -0,0 +1,12 @@
 What:		/config/usb-gadget/gadget/functions/uac1.name
 Date:		Sep 2014
 KernelVersion:	3.18
 Description:
 		The attributes:
 		audio_buf_size - audio buffer size
 		fn_cap - capture pcm device file name
 		fn_cntl - control device file name
 		fn_play - playback pcm device file name
 		req_buf_size - ISO OUT endpoint request buffer size
 		req_count - ISO OUT endpoint request count
--- a/Documentation/ABI/testing/configfs-usb-gadget-uac2
+++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2
@@ -0,0 +1,12 @@
 What:		/config/usb-gadget/gadget/functions/uac2.name
 Date:		Sep 2014
 KernelVersion:	3.18
 Description:
 		The attributes:
 		c_chmask - capture channel mask
 		c_srate - capture sampling rate
 		c_ssize - capture sample size (bytes)
 		p_chmask - playback channel mask
 		p_srate - playback sampling rate
 		p_ssize - playback sample size (bytes)
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -53,6 +53,14 @@ Description:
 		512 bytes of data.
 What:		/sys/block/<disk>/integrity/device_is_integrity_capable
 Date:		July 2014
 Contact:	Martin K. Petersen <martin.petersen@oracle.com>
 Description:
 		Indicates whether a storage device is capable of storing
 		integrity metadata. Set if the device is T10 PI-capable.
 What:		/sys/block/<disk>/integrity/write_generate
 Date:		June 2008
 Contact:	Martin K. Petersen <martin.petersen@oracle.com>
--- a/Documentation/ABI/testing/sysfs-block-zram
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -77,11 +77,14 @@ What:		/sys/block/zram<id>/notify_free
 Date:		August 2010
 Contact:	Nitin Gupta <ngupta@vflare.org>
 Description:
-		The notify_free file is read-only and specifies the number of
+		The notify_free file is read-only. Depending on device usage
-		swap slot free notifications received by this device. These
+		scenario it may account a) the number of pages freed because
-		notifications are sent to a swap block device when a swap slot
+		of swap slot free notifications or b) the number of pages freed
-		is freed. This statistic is applicable only when this disk is
+		because of REQ_DISCARD requests sent by bio. The former ones
-		being used as a swap disk.
+		are sent to a swap block device when a swap slot is freed, which
 		implies that this disk is being used as a swap disk. The latter
 		ones are sent by filesystem mounted with discard option,
 		whenever some data blocks are getting discarded.
 What:		/sys/block/zram<id>/zero_pages
 Date:		August 2010
@@ -119,3 +122,22 @@ Description:
 		efficiency can be calculated using compr_data_size and this
 		statistic.
 		Unit: bytes
 What:		/sys/block/zram<id>/mem_used_max
 Date:		August 2014
 Contact:	Minchan Kim <minchan@kernel.org>
 Description:
 		The mem_used_max file is read/write and specifies the amount
 		of maximum memory zram have consumed to store compressed data.
 		For resetting the value, you should write "0". Otherwise,
 		you could see -EINVAL.
 		Unit: bytes
 What:		/sys/block/zram<id>/mem_limit
 Date:		August 2014
 Contact:	Minchan Kim <minchan@kernel.org>
 Description:
 		The mem_limit file is read/write and specifies the maximum
 		amount of memory ZRAM can use to store the compressed data.  The
 		limit could be changed in run time and "0" means disable the
 		limit.  No limit is the initial state.  Unit: bytes
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-events
@@ -27,575 +27,62 @@ Description:	Generic performance monitoring events
 		"basename".
-What: 		/sys/devices/cpu/events/PM_1PLUS_PPC_CMPL
+What: /sys/bus/event_source/devices/<pmu>/events/<event>
-		/sys/devices/cpu/events/PM_BRU_FIN
+Date: 2014/02/24
 		/sys/devices/cpu/events/PM_BR_MPRED
 		/sys/devices/cpu/events/PM_CMPLU_STALL
 		/sys/devices/cpu/events/PM_CMPLU_STALL_BRU
 		/sys/devices/cpu/events/PM_CMPLU_STALL_DCACHE_MISS
 		/sys/devices/cpu/events/PM_CMPLU_STALL_DFU
 		/sys/devices/cpu/events/PM_CMPLU_STALL_DIV
 		/sys/devices/cpu/events/PM_CMPLU_STALL_ERAT_MISS
 		/sys/devices/cpu/events/PM_CMPLU_STALL_FXU
 		/sys/devices/cpu/events/PM_CMPLU_STALL_IFU
 		/sys/devices/cpu/events/PM_CMPLU_STALL_LSU
 		/sys/devices/cpu/events/PM_CMPLU_STALL_REJECT
 		/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR
 		/sys/devices/cpu/events/PM_CMPLU_STALL_SCALAR_LONG
 		/sys/devices/cpu/events/PM_CMPLU_STALL_STORE
 		/sys/devices/cpu/events/PM_CMPLU_STALL_THRD
 		/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR
 		/sys/devices/cpu/events/PM_CMPLU_STALL_VECTOR_LONG
 		/sys/devices/cpu/events/PM_CYC
 		/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED
 		/sys/devices/cpu/events/PM_GCT_NOSLOT_BR_MPRED_IC_MISS
 		/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
 		/sys/devices/cpu/events/PM_GCT_NOSLOT_IC_MISS
 		/sys/devices/cpu/events/PM_GRP_CMPL
 		/sys/devices/cpu/events/PM_INST_CMPL
 		/sys/devices/cpu/events/PM_LD_MISS_L1
 		/sys/devices/cpu/events/PM_LD_REF_L1
 		/sys/devices/cpu/events/PM_RUN_CYC
 		/sys/devices/cpu/events/PM_RUN_INST_CMPL
 		/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
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
-		Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
+Description:	Per-pmu performance monitoring events specific to the running system
-Description:	POWER-systems specific performance monitoring events
+		Each file (except for some of those with a '.' in them, '.unit'
 		and '.scale') in the 'events' directory describes a single
 		performance monitoring event supported by the <pmu>. The name
 		of the file is the name of the event.
-		A collection of performance monitoring events that may be
+		File contents:
 		supported by the POWER CPU. These events can be monitored
 		using the 'perf(1)' tool.
-		These events may not be supported by other CPUs.
+			<term>[=<value>][,<term>[=<value>]]...
-		The contents of each file would look like:
+		Where <term> is one of the terms listed under
 		/sys/bus/event_source/devices/<pmu>/format/ and <value> is
 		a number is base-16 format with a '0x' prefix (lowercase only).
 		If a <term> is specified alone (without an assigned value), it
 		is implied that 0x1 is assigned to that <term>.
-			event=0xNNNN
+		Examples (each of these lines would be in a seperate file):
-		where 'N' is a hex digit and the number '0xNNNN' shows the
+			event=0x2abc
-		"raw code" for the perf event identified by the file's
+			event=0x423,inv,cmask=0x3
-		"basename".
+			domain=0x1,offset=0x8,starting_index=0xffff
-		Further, multiple terms like 'event=0xNNNN' can be specified
+		Each of the assignments indicates a value to be assigned to a
-		and separated with comma. All available terms are defined in
+		particular set of bits (as defined by the format file
-		the /sys/bus/event_source/devices/<dev>/format file.
+		corresponding to the <term>) in the perf_event structure passed
 		to the perf_open syscall.
 What: /sys/bus/event_source/devices/<pmu>/events/<event>.unit
 Date: 2014/02/24
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
 Description:	Perf event units
 		A string specifying the English plural numerical unit that <event>
 		(once multiplied by <event>.scale) represents.
 		Example:
 			Joules
 What: /sys/bus/event_source/devices/<pmu>/events/<event>.scale
 Date: 2014/02/24
 Contact:	Linux kernel mailing list <linux-kernel@vger.kernel.org>
 Description:	Perf event scaling factors
 		A string representing a floating point value expressed in
 		scientific notation to be multiplied by the event count
 		recieved from the kernel to match the unit specified in the
 		<event>.unit file.
 		Example:
 			2.3283064365386962890625e-10
 		This is provided to avoid performing floating point arithmetic
 		in the kernel.
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_24x7
@@ -1,6 +1,6 @@
 What:		/sys/bus/event_source/devices/hv_24x7/interface/catalog
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		Provides access to the binary "24x7 catalog" provided by the
 		hypervisor on POWER7 and 8 systems. This catalog lists events
@@ -10,14 +10,14 @@ Description:
 What:		/sys/bus/event_source/devices/hv_24x7/interface/catalog_length
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 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>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		Exposes the "version" field of the 24x7 catalog. This is also
 		extractable from the provided binary "catalog" sysfs entry.
--- a/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
+++ b/Documentation/ABI/testing/sysfs-bus-event_source-devices-hv_gpci
@@ -1,6 +1,6 @@
 What:		/sys/bus/event_source/devices/hv_gpci/interface/collect_privileged
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		'0' if the hypervisor is configured to forbid access to event
 		counters being accumulated by other guests and to physical
@@ -9,35 +9,35 @@ Description:
 What:		/sys/bus/event_source/devices/hv_gpci/interface/ga
 Date:		February 2014
-Contact:	Cody P Schafer <cody@linux.vnet.ibm.com>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 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>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 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>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 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>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 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>
+Contact:	Linux on PowerPC Developer List <linuxppc-dev@lists.ozlabs.org>
 Description:
 		A number indicating the latest version of the gpci interface
 		that the kernel is aware of.
--- a/Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150
+++ b/Documentation/ABI/testing/sysfs-bus-iio-accel-bmc150
@@ -0,0 +1,7 @@
 What:		/sys/bus/iio/devices/triggerX/name = "bmc150_accel-any-motion-devX"
 KernelVersion:	3.17
 Contact:	linux-iio@vger.kernel.org
 Description:
 		The BMC150 accelerometer kernel module provides an additional trigger,
 		which sets driver in a mode, where data is pushed to the buffer
 		only when there is any motion.
--- a/Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160
+++ b/Documentation/ABI/testing/sysfs-bus-iio-gyro-bmg160
@@ -0,0 +1,7 @@
 What:		/sys/bus/iio/devices/triggerX/name = "bmg160-any-motion-devX"
 KernelVersion:	3.17
 Contact:	linux-iio@vger.kernel.org
 Description:
 		The BMG160 gyro kernel module provides an additional trigger,
 		which sets driver in a mode, where data is pushed to the buffer
 		only when there is any motion.
--- a/Documentation/ABI/testing/sysfs-bus-pci
+++ b/Documentation/ABI/testing/sysfs-bus-pci
@@ -65,6 +65,16 @@ Description:
 		force a rescan of all PCI buses in the system, and
 		re-discover previously removed devices.
 What:		/sys/bus/pci/devices/.../msi_bus
 Date:		September 2014
 Contact:	Linux PCI developers <linux-pci@vger.kernel.org>
 Description:
 		Writing a zero value to this attribute disallows MSI and
 		MSI-X for any future drivers of the device.  If the device
 		is a bridge, MSI and MSI-X will be disallowed for future
 		drivers of all child devices under the bridge.  Drivers
 		must be reloaded for the new setting to take effect.
 What:		/sys/bus/pci/devices/.../msi_irqs/
 Date:		September, 2011
 Contact:	Neil Horman <nhorman@tuxdriver.com>
--- a/Documentation/ABI/testing/sysfs-bus-rbd
+++ b/Documentation/ABI/testing/sysfs-bus-rbd
@@ -94,5 +94,5 @@ current_snap
 parent
-	Information identifying the pool, image, and snapshot id for
+	Information identifying the chain of parent images in a layered rbd
-	the parent image in a layered rbd image (format 2 only).
+	image.  Entries are separated by empty lines.
--- a/Documentation/ABI/testing/sysfs-class-cxl
+++ b/Documentation/ABI/testing/sysfs-class-cxl
@@ -0,0 +1,129 @@
 Slave contexts (eg. /sys/class/cxl/afu0.0s):
 What:           /sys/class/cxl/<afu>/irqs_max
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read/write
                Decimal value of maximum number of interrupts that can be
                requested by userspace.  The default on probe is the maximum
                that hardware can support (eg. 2037). Write values will limit
                userspace applications to that many userspace interrupts. Must
                be >= irqs_min.
 What:           /sys/class/cxl/<afu>/irqs_min
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the minimum number of interrupts that
                userspace must request on a CXL_START_WORK ioctl. Userspace may
                omit the num_interrupts field in the START_WORK IOCTL to get
                this minimum automatically.
 What:           /sys/class/cxl/<afu>/mmio_size
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the size of the MMIO space that may be mmaped
                by userspace.
 What:           /sys/class/cxl/<afu>/modes_supported
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                List of the modes this AFU supports. One per line.
                Valid entries are: "dedicated_process" and "afu_directed"
 What:           /sys/class/cxl/<afu>/mode
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read/write
                The current mode the AFU is using. Will be one of the modes
                given in modes_supported. Writing will change the mode
                provided that no user contexts are attached.
 What:           /sys/class/cxl/<afu>/prefault_mode
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read/write
                Set the mode for prefaulting in segments into the segment table
                when performing the START_WORK ioctl. Possible values:
                        none: No prefaulting (default)
                        work_element_descriptor: Treat the work element
                                 descriptor as an effective address and
                                 prefault what it points to.
                        all: all segments process calling START_WORK maps.
 What:           /sys/class/cxl/<afu>/reset
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    write only
                Writing 1 here will reset the AFU provided there are not
                contexts active on the AFU.
 What:           /sys/class/cxl/<afu>/api_version
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the current version of the kernel/user API.
 What:           /sys/class/cxl/<afu>/api_version_com
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the the lowest version of the userspace API
                this this kernel supports.
 Master contexts (eg. /sys/class/cxl/afu0.0m)
 What:           /sys/class/cxl/<afu>m/mmio_size
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the size of the MMIO space that may be mmaped
                by userspace. This includes all slave contexts space also.
 What:           /sys/class/cxl/<afu>m/pp_mmio_len
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the Per Process MMIO space length.
 What:           /sys/class/cxl/<afu>m/pp_mmio_off
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Decimal value of the Per Process MMIO space offset.
 Card info (eg. /sys/class/cxl/card0)
 What:           /sys/class/cxl/<card>/caia_version
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Identifies the CAIA Version the card implements.
 What:           /sys/class/cxl/<card>/psl_version
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Identifies the revision level of the PSL.
 What:           /sys/class/cxl/<card>/base_image
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Identifies the revision level of the base image for devices
                that support loadable PSLs. For FPGAs this field identifies
                the image contained in the on-adapter flash which is loaded
                during the initial program load.
 What:           /sys/class/cxl/<card>/image_loaded
 Date:           September 2014
 Contact:        linuxppc-dev@lists.ozlabs.org
 Description:    read only
                Will return "user" or "factory" depending on the image loaded
                onto the card.
--- a/Documentation/ABI/testing/sysfs-class-leds-gt683r
+++ b/Documentation/ABI/testing/sysfs-class-leds-gt683r
@@ -0,0 +1,16 @@
 What:		/sys/class/leds/<led>/gt683r/mode
 Date:		Jun 2014
 KernelVersion:	3.17
 Contact:	Janne Kanniainen <janne.kanniainen@gmail.com>
 Description:
 		Set the mode of LEDs. You should notice that changing the mode
 		of one LED will update the mode of its two sibling devices as
 		well.
 		0 - normal
 		1 - audio
 		2 - breathing
 		Normal: LEDs are fully on when enabled
 		Audio:  LEDs brightness depends on sound level
 		Breathing: LEDs brightness varies at human breathing rate
--- a/Documentation/ABI/testing/sysfs-class-mtd
+++ b/Documentation/ABI/testing/sysfs-class-mtd
@@ -184,3 +184,41 @@ Description:
 		It will always be a non-negative integer.  In the case of
 		devices lacking any ECC capability, it is 0.
 What:		/sys/class/mtd/mtdX/ecc_failures
 Date:		June 2014
 KernelVersion:	3.17
 Contact:	linux-mtd@lists.infradead.org
 Description:
 		The number of failures reported by this device's ECC. Typically,
 		these failures are associated with failed read operations.
 		It will always be a non-negative integer.  In the case of
 		devices lacking any ECC capability, it is 0.
 What:		/sys/class/mtd/mtdX/corrected_bits
 Date:		June 2014
 KernelVersion:	3.17
 Contact:	linux-mtd@lists.infradead.org
 Description:
 		The number of bits that have been corrected by means of the
 		device's ECC.
 		It will always be a non-negative integer.  In the case of
 		devices lacking any ECC capability, it is 0.
 What:		/sys/class/mtd/mtdX/bad_blocks
 Date:		June 2014
 KernelVersion:	3.17
 Contact:	linux-mtd@lists.infradead.org
 Description:
 		The number of blocks marked as bad, if any, in this partition.
 What:		/sys/class/mtd/mtdX/bbt_blocks
 Date:		June 2014
 KernelVersion:	3.17
 Contact:	linux-mtd@lists.infradead.org
 Description:
 		The number of blocks that are marked as reserved, if any, in
 		this partition. These are typically used to store the in-flash
 		bad block table (BBT).
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -18,3 +18,17 @@ Description:
 		This file is writeable and can be used to set the assumed
 		battery 'full level'. As batteries age, this value has to be
 		amended over time.
 What:		/sys/class/power_supply/max14577-charger/device/fast_charge_timer
 Date:		October 2014
 KernelVersion:	3.18.0
 Contact:	Krzysztof Kozlowski <k.kozlowski@samsung.com>
 Description:
 		This entry shows and sets the maximum time the max14577
 		charger operates in fast-charge mode. When the timer expires
 		the device will terminate fast-charge mode (charging current
 		will drop to 0 A) and will trigger interrupt.
 		Valid values:
 		- 5, 6 or 7 (hours),
 		- 0: disabled.
--- a/Documentation/ABI/testing/sysfs-class-uwb_rc
+++ b/Documentation/ABI/testing/sysfs-class-uwb_rc
@@ -43,6 +43,19 @@ Description:
                Reading returns the currently active channel, or -1 if
                the radio controller is not beaconing.
 What:           /sys/class/uwb_rc/uwbN/ASIE
 Date:           August 2014
 KernelVersion:  3.18
 Contact:        linux-usb@vger.kernel.org
 Description:
                The application-specific information element (ASIE)
                included in this device's beacon, in space separated
                hex octets.
                Reading returns the current ASIE.  Writing replaces
                the current ASIE with the one written.
 What:           /sys/class/uwb_rc/uwbN/scan
 Date:           July 2008
 KernelVersion:  2.6.27
--- a/Documentation/ABI/testing/sysfs-devices-memory
+++ b/Documentation/ABI/testing/sysfs-devices-memory
@@ -61,6 +61,14 @@ Users:		hotplug memory remove tools
 		http://www.ibm.com/developerworks/wikis/display/LinuxP/powerpc-utils
 What:           /sys/devices/system/memory/memoryX/valid_zones
 Date:           July 2014
 Contact:	Zhang Zhen <zhenzhang.zhang@huawei.com>
 Description:
 		The file /sys/devices/system/memory/memoryX/valid_zones	is
 		read-only and is designed to show which zone this memory
 		block can be onlined to.
 What:		/sys/devices/system/memoryX/nodeY
 Date:		October 2009
 Contact:	Linux Memory Management list <linux-mm@kvack.org>
--- a/Documentation/ABI/testing/sysfs-driver-pciback
+++ b/Documentation/ABI/testing/sysfs-driver-pciback
@@ -0,0 +1,13 @@
 What:           /sys/bus/pci/drivers/pciback/quirks
 Date:           Oct 2011
 KernelVersion:  3.1
 Contact:        xen-devel@lists.xenproject.org
 Description:
                If the permissive attribute is set, then writing a string in
                the format of DDDD:BB:DD.F-REG:SIZE:MASK will allow the guest
                to write and read from the PCI device. That is Domain:Bus:
                Device.Function-Register:Size:Mask (Domain is optional).
                For example:
                #echo 00:19.0-E0:2:FF > /sys/bus/pci/drivers/pciback/quirks
                will allow the guest to read and write to the configuration
                register 0x0E.
--- a/Documentation/ABI/testing/sysfs-driver-tegra-fuse
+++ b/Documentation/ABI/testing/sysfs-driver-tegra-fuse
@@ -0,0 +1,11 @@
 What:		/sys/devices/*/<our-device>/fuse
 Date:		February 2014
 Contact:	Peter De Schrijver <pdeschrijver@nvidia.com>
 Description:	read-only access to the efuses on Tegra20, Tegra30, Tegra114
 		and Tegra124 SoC's from NVIDIA. The efuses contain write once
 		data programmed at the factory. The data is layed out in 32bit
 		words in LSB first format. Each bit represents a single value
 		as decoded from the fuse registers. Bits order/assignment
 		exactly matches the HW registers, including any unused bits.
 Users:		any user space application which wants to read the efuses on
 		Tegra SoC's
--- a/Documentation/ABI/testing/sysfs-driver-wacom
+++ b/Documentation/ABI/testing/sysfs-driver-wacom
@@ -1,48 +1,27 @@
-WWhat:		/sys/class/hidraw/hidraw*/device/oled*_img
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed
 Date:		June 2012
 Contact:	linux-bluetooth@vger.kernel.org
 Description:
 		The /sys/class/hidraw/hidraw*/device/oled*_img files control
 		OLED mocro displays on Intuos4 Wireless tablet. Accepted image
 		has to contain 256 bytes (64x32 px 1 bit colour). The format
 		is the same as PBM image 62x32px without header (64 bits per
 		horizontal line, 32 lines). An example of setting OLED No. 0:
 		dd bs=256 count=1 if=img_file of=[path to oled0_img]/oled0_img
 		The attribute is read only and no local copy of the image is
 		stored.
 What:		/sys/class/hidraw/hidraw*/device/speed
 Date:		April 2010
 Kernel Version:	2.6.35
 Contact:	linux-bluetooth@vger.kernel.org
 Description:
-		The /sys/class/hidraw/hidraw*/device/speed file controls
+		The /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/speed file
-		reporting speed of Wacom bluetooth tablet. Reading from
+		controls reporting speed of Wacom bluetooth tablet. Reading
-		this file returns 1 if tablet reports in high speed mode
+		from this file returns 1 if tablet reports in high speed mode
 		or 0 otherwise. Writing to this file one of these values
 		switches reporting speed.
-What:		/sys/class/leds/0005\:056A\:00BD.0001\:selector\:*/
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/led
-Date:		May 2012
+Date:		August 2014
 Kernel Version:	3.5
 Contact:	linux-bluetooth@vger.kernel.org
 Description:
 		LED selector for Intuos4 WL. There are 4 leds, but only one LED
 		can be lit at a time. Max brightness is 127.
 What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/led
 Date:		August 2011
 Contact:	linux-input@vger.kernel.org
 Description:
 		Attribute group for control of the status LEDs and the OLEDs.
 		This attribute group is only available for Intuos 4 M, L,
-		and XL (with LEDs and OLEDs), Intuos 5 (LEDs only), and Cintiq
+		and XL (with LEDs and OLEDs), Intuos 4 WL, Intuos 5 (LEDs only),
-		21UX2 and Cintiq 24HD (LEDs only). Therefore its presence
+		Intuos Pro (LEDs only) and Cintiq 21UX2 and Cintiq 24HD
-		implicitly signifies the presence of said LEDs and OLEDs on the
+		(LEDs only). Therefore its presence implicitly signifies the
-		tablet device.
+		presence of said LEDs and OLEDs on the tablet device.
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status0_luminance
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status0_luminance
-Date:		August 2011
+Date:		August 2014
 Contact:	linux-input@vger.kernel.org
 Description:
 		Writing to this file sets the status LED luminance (1..127)
@@ -50,16 +29,16 @@ Description:
 		button is pressed on the stylus. This luminance level is
 		normally lower than the level when a button is pressed.
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status1_luminance
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status1_luminance
-Date:		August 2011
+Date:		August 2014
 Contact:	linux-input@vger.kernel.org
 Description:
 		Writing to this file sets the status LED luminance (1..127)
 		when the stylus touches the tablet surface, or any button is
 		pressed on the stylus.
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led0_select
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led0_select
-Date:		August 2011
+Date:		August 2014
 Contact:	linux-input@vger.kernel.org
 Description:
 		Writing to this file sets which one of the four (for Intuos 4
@@ -67,23 +46,23 @@ Description:
 		24HD) status LEDs is active (0..3). The other three LEDs on the
 		same side are always inactive.
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/status_led1_select
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/status_led1_select
-Date:		September 2011
+Date:		August 2014
 Contact:	linux-input@vger.kernel.org
 Description:
 		Writing to this file sets which one of the left four (for Cintiq 21UX2
 		and Cintiq 24HD) status LEDs is active (0..3). The other three LEDs on
 		the left are always inactive.
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/buttons_luminance
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/buttons_luminance
-Date:		August 2011
+Date:		August 2014
 Contact:	linux-input@vger.kernel.org
 Description:
 		Writing to this file sets the overall luminance level (0..15)
 		of all eight button OLED displays.
-What:		/sys/bus/usb/devices/<busnum>-<devnum>:<cfg>.<intf>/wacom_led/button<n>_rawimg
+What:		/sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_led/button<n>_rawimg
-Date:		August 2011
+Date:		August 2014
 Contact:	linux-input@vger.kernel.org
 Description:
 		When writing a 1024 byte raw image in Wacom Intuos 4
@@ -93,3 +72,8 @@ Description:
 		byte chunk encodes the image data for two consecutive lines on
 		the display. The low nibble of each byte contains the first
 		line, and the high nibble contains the second line.
 		When the Wacom Intuos 4 is connected over Bluetooth, the
 		image has to contain 256 bytes (64x32 px 1 bit colour).
 		The format is also scrambled, like in the USB mode, and it can
 		be summarized by converting 76543210 into GECA6420.
 					    HGFEDCBA      HFDB7531
--- a/Documentation/ABI/testing/sysfs-fs-f2fs
+++ b/Documentation/ABI/testing/sysfs-fs-f2fs
@@ -44,6 +44,13 @@ Description:
 		 Controls the FS utilization condition for the in-place-update
 		 policies.
 What:		/sys/fs/f2fs/<disk>/min_fsync_blocks
 Date:		September 2014
 Contact:	"Jaegeuk Kim" <jaegeuk@kernel.org>
 Description:
 		 Controls the dirty page count condition for the in-place-update
 		 policies.
 What:		/sys/fs/f2fs/<disk>/max_small_discards
 Date:		November 2013
 Contact:	"Jaegeuk Kim" <jaegeuk.kim@samsung.com>
--- a/Documentation/ABI/testing/sysfs-fs-nilfs2
+++ b/Documentation/ABI/testing/sysfs-fs-nilfs2
@@ -0,0 +1,269 @@
 What:		/sys/fs/nilfs2/features/revision
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show current revision of NILFS file system driver.
 		This value informs about file system revision that
 		driver is ready to support.
 What:		/sys/fs/nilfs2/features/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/features group.
 What:		/sys/fs/nilfs2/<device>/revision
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show NILFS file system revision on volume.
 		This value informs about metadata structures'
 		revision on mounted volume.
 What:		/sys/fs/nilfs2/<device>/blocksize
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show volume's block size in bytes.
 What:		/sys/fs/nilfs2/<device>/device_size
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show volume size in bytes.
 What:		/sys/fs/nilfs2/<device>/free_blocks
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show count of free blocks on volume.
 What:		/sys/fs/nilfs2/<device>/uuid
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show volume's UUID (Universally Unique Identifier).
 What:		/sys/fs/nilfs2/<device>/volume_name
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show volume's label.
 What:		/sys/fs/nilfs2/<device>/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/<device> group.
 What:		/sys/fs/nilfs2/<device>/superblock/sb_write_time
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show last write time of super block in human-readable
 		format.
 What:		/sys/fs/nilfs2/<device>/superblock/sb_write_time_secs
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show last write time of super block in seconds.
 What:		/sys/fs/nilfs2/<device>/superblock/sb_write_count
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show current write count of super block.
 What:		/sys/fs/nilfs2/<device>/superblock/sb_update_frequency
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show/Set interval of periodical update of superblock
 		(in seconds).
 What:		/sys/fs/nilfs2/<device>/superblock/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/<device>/superblock
 		group.
 What:		/sys/fs/nilfs2/<device>/segctor/last_pseg_block
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show start block number of the latest segment.
 What:		/sys/fs/nilfs2/<device>/segctor/last_seg_sequence
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show sequence value of the latest segment.
 What:		/sys/fs/nilfs2/<device>/segctor/last_seg_checkpoint
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show checkpoint number of the latest segment.
 What:		/sys/fs/nilfs2/<device>/segctor/current_seg_sequence
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show segment sequence counter.
 What:		/sys/fs/nilfs2/<device>/segctor/current_last_full_seg
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show index number of the latest full segment.
 What:		/sys/fs/nilfs2/<device>/segctor/next_full_seg
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show index number of the full segment index
 		to be used next.
 What:		/sys/fs/nilfs2/<device>/segctor/next_pseg_offset
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show offset of next partial segment in the current
 		full segment.
 What:		/sys/fs/nilfs2/<device>/segctor/next_checkpoint
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show next checkpoint number.
 What:		/sys/fs/nilfs2/<device>/segctor/last_seg_write_time
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show write time of the last segment in
 		human-readable format.
 What:		/sys/fs/nilfs2/<device>/segctor/last_seg_write_time_secs
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show write time of the last segment in seconds.
 What:		/sys/fs/nilfs2/<device>/segctor/last_nongc_write_time
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show write time of the last segment not for cleaner
 		operation in human-readable format.
 What:		/sys/fs/nilfs2/<device>/segctor/last_nongc_write_time_secs
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show write time of the last segment not for cleaner
 		operation in seconds.
 What:		/sys/fs/nilfs2/<device>/segctor/dirty_data_blocks_count
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of dirty data blocks.
 What:		/sys/fs/nilfs2/<device>/segctor/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/<device>/segctor
 		group.
 What:		/sys/fs/nilfs2/<device>/segments/segments_number
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of segments on a volume.
 What:		/sys/fs/nilfs2/<device>/segments/blocks_per_segment
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of blocks in segment.
 What:		/sys/fs/nilfs2/<device>/segments/clean_segments
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show count of clean segments.
 What:		/sys/fs/nilfs2/<device>/segments/dirty_segments
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show count of dirty segments.
 What:		/sys/fs/nilfs2/<device>/segments/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/<device>/segments
 		group.
 What:		/sys/fs/nilfs2/<device>/checkpoints/checkpoints_number
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of checkpoints on volume.
 What:		/sys/fs/nilfs2/<device>/checkpoints/snapshots_number
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of snapshots on volume.
 What:		/sys/fs/nilfs2/<device>/checkpoints/last_seg_checkpoint
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show checkpoint number of the latest segment.
 What:		/sys/fs/nilfs2/<device>/checkpoints/next_checkpoint
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show next checkpoint number.
 What:		/sys/fs/nilfs2/<device>/checkpoints/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/<device>/checkpoints
 		group.
 What:		/sys/fs/nilfs2/<device>/mounted_snapshots/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe content of /sys/fs/nilfs2/<device>/mounted_snapshots
 		group.
 What:		/sys/fs/nilfs2/<device>/mounted_snapshots/<id>/inodes_count
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of inodes for snapshot.
 What:		/sys/fs/nilfs2/<device>/mounted_snapshots/<id>/blocks_count
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Show number of blocks for snapshot.
 What:		/sys/fs/nilfs2/<device>/mounted_snapshots/<id>/README
 Date:		April 2014
 Contact:	"Vyacheslav Dubeyko" <slava@dubeyko.com>
 Description:
 		Describe attributes of /sys/fs/nilfs2/<device>/mounted_snapshots/<id>
 		group.
--- a/Documentation/ABI/testing/sysfs-fs-xfs
+++ b/Documentation/ABI/testing/sysfs-fs-xfs
@@ -0,0 +1,39 @@
 What:		/sys/fs/xfs/<disk>/log/log_head_lsn
 Date:		July 2014
 KernelVersion:	3.17
 Contact:	xfs@oss.sgi.com
 Description:
 		The log sequence number (LSN) of the current head of the
 		log. The LSN is exported in "cycle:basic block" format.
 Users:		xfstests
 What:		/sys/fs/xfs/<disk>/log/log_tail_lsn
 Date:		July 2014
 KernelVersion:	3.17
 Contact:	xfs@oss.sgi.com
 Description:
 		The log sequence number (LSN) of the current tail of the
 		log. The LSN is exported in "cycle:basic block" format.
 What:		/sys/fs/xfs/<disk>/log/reserve_grant_head
 Date:		July 2014
 KernelVersion:	3.17
 Contact:	xfs@oss.sgi.com
 Description:
 		The current state of the log reserve grant head. It
 		represents the total log reservation of all currently
 		outstanding transactions. The grant head is exported in
 		"cycle:bytes" format.
 Users:		xfstests
 What:		/sys/fs/xfs/<disk>/log/write_grant_head
 Date:		July 2014
 KernelVersion:	3.17
 Contact:	xfs@oss.sgi.com
 Description:
 		The current state of the log write grant head. It
 		represents the total log reservation of all currently
 		oustanding transactions, including regrants due to
 		rolling transactions. The grant head is exported in
 		"cycle:bytes" format.
 Users:		xfstests
--- a/Documentation/ABI/testing/sysfs-ibft
+++ b/Documentation/ABI/testing/sysfs-ibft
@@ -20,4 +20,4 @@ Date:		November 2007
 Contact:	Konrad Rzeszutek <ketuzsezr@darnok.org>
 Description:	The /sys/firmware/ibft/ethernetX directory will contain
 		files that expose the iSCSI Boot Firmware Table NIC data.
-		This can this can the IP address, MAC, and gateway of the NIC.
+		Usually this contains the IP address, MAC, and gateway of the NIC.
--- a/Documentation/DMA-API-HOWTO.txt
+++ b/Documentation/DMA-API-HOWTO.txt
@@ -531,7 +531,7 @@ To map a single region, you do:
 	size_t size = buffer->len;
 	dma_handle = dma_map_single(dev, addr, size, direction);
-	if (dma_mapping_error(dma_handle)) {
+	if (dma_mapping_error(dev, dma_handle)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or
@@ -588,7 +588,7 @@ Specifically:
 	size_t size = buffer->len;
 	dma_handle = dma_map_page(dev, page, offset, size, direction);
-	if (dma_mapping_error(dma_handle)) {
+	if (dma_mapping_error(dev, dma_handle)) {
 		/*
 		 * reduce current DMA mapping usage,
 		 * delay and try again later or
@@ -689,7 +689,7 @@ to use the dma_sync_*() interfaces.
 		dma_addr_t mapping;
 		mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
-		if (dma_mapping_error(dma_handle)) {
+		if (dma_mapping_error(cp->dev, dma_handle)) {
 			/*
 			 * reduce current DMA mapping usage,
 			 * delay and try again later or
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -291,10 +291,9 @@ char *date;</synopsis>
      <title>Device Registration</title>
      <para>
        A number of functions are provided to help with device registration.
-        The functions deal with PCI, USB and platform devices, respectively.
+        The functions deal with PCI and platform devices, respectively.
      </para>
 !Edrivers/gpu/drm/drm_pci.c
 !Edrivers/gpu/drm/drm_usb.c
 !Edrivers/gpu/drm/drm_platform.c
      <para>
        New drivers that no longer rely on the services provided by the
@@ -315,7 +314,7 @@ char *date;</synopsis>
        <function>drm_dev_unregister()</function> followed by a call to
        <function>drm_dev_unref()</function>.
      </para>
-!Edrivers/gpu/drm/drm_stub.c
+!Edrivers/gpu/drm/drm_drv.c
    </sect2>
    <sect2>
      <title>Driver Load</title>
@@ -1610,7 +1609,7 @@ int max_width, max_height;</synopsis>
          The connector is then registered with a call to
          <function>drm_connector_init</function> with a pointer to the connector
          functions and a connector type, and exposed through sysfs with a call to
-          <function>drm_sysfs_connector_add</function>.
+          <function>drm_connector_register</function>.
        </para>
        <para>
          Supported connector types are
@@ -1768,7 +1767,7 @@ int max_width, max_height;</synopsis>
 	(<function>drm_encoder_cleanup</function>) and connectors
 	(<function>drm_connector_cleanup</function>). Furthermore, connectors
 	that have been added to sysfs must be removed by a call to
-	<function>drm_sysfs_connector_remove</function> before calling
+	<function>drm_connector_unregister</function> before calling
 	<function>drm_connector_cleanup</function>.
      </para>
      <para>
@@ -1813,7 +1812,7 @@ void intel_crt_init(struct drm_device *dev)
 	drm_encoder_helper_add(&intel_output->enc, &intel_crt_helper_funcs);
 	drm_connector_helper_add(connector, &intel_crt_connector_helper_funcs);
-	drm_sysfs_connector_add(connector);
+	drm_connector_register(connector);
 }]]></programlisting>
      <para>
        In the example above (taken from the i915 driver), a CRTC, connector and
@@ -2336,6 +2335,12 @@ void intel_crt_init(struct drm_device *dev)
 !Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
 !Iinclude/drm/drm_dp_helper.h
 !Edrivers/gpu/drm/drm_dp_helper.c
    </sect2>
    <sect2>
      <title>Display Port MST Helper Functions Reference</title>
 !Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper
 !Iinclude/drm/drm_dp_mst_helper.h
 !Edrivers/gpu/drm/drm_dp_mst_topology.c
    </sect2>
    <sect2>
      <title>EDID Helper Functions Reference</title>
@@ -2502,7 +2507,7 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >Description/Restrictions</td>
 	</tr>
 	<tr>
-	<td rowspan="20" valign="top" >DRM</td>
+	<td rowspan="21" valign="top" >DRM</td>
 	<td rowspan="2" valign="top" >Generic</td>
 	<td valign="top" >“EDID”</td>
 	<td valign="top" >BLOB | IMMUTABLE</td>
@@ -2633,7 +2638,7 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td rowspan="2" valign="top" >Optional</td>
+	<td rowspan="3" valign="top" >Optional</td>
 	<td valign="top" >“scaling mode”</td>
 	<td valign="top" >ENUM</td>
 	<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
@@ -2641,6 +2646,15 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td valign="top" >"aspect ratio"</td>
 	<td valign="top" >ENUM</td>
 	<td valign="top" >{ "None", "4:3", "16:9" }</td>
 	<td valign="top" >Connector</td>
 	<td valign="top" >DRM property to set aspect ratio from user space app.
 		This enum is made generic to allow addition of custom aspect
 		ratios.</td>
 	</tr>
 	<tr>
 	<td valign="top" >“dirty”</td>
 	<td valign="top" >ENUM | IMMUTABLE</td>
 	<td valign="top" >{ "Off", "On", "Annotate" }</td>
@@ -2649,7 +2663,7 @@ void intel_crt_init(struct drm_device *dev)
 	</tr>
 	<tr>
 	<td rowspan="21" valign="top" >i915</td>
-	<td rowspan="3" valign="top" >Generic</td>
+	<td rowspan="2" valign="top" >Generic</td>
 	<td valign="top" >"Broadcast RGB"</td>
 	<td valign="top" >ENUM</td>
 	<td valign="top" >{ "Automatic", "Full", "Limited 16:235" }</td>
@@ -2664,10 +2678,11 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td valign="top" >Standard name as in DRM</td>
+	<td rowspan="1" valign="top" >Plane</td>
-	<td valign="top" >Standard type as in DRM</td>
+	<td valign="top" >“rotation”</td>
-	<td valign="top" >Standard value as in DRM</td>
+	<td valign="top" >BITMASK</td>
-	<td valign="top" >Standard Object as in DRM</td>
+	<td valign="top" >{ 0, "rotate-0" }, { 2, "rotate-180" }</td>
 	<td valign="top" >Plane</td>
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
@@ -2799,8 +2814,8 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td rowspan="3" valign="top" >CDV gma-500</td>
+	<td rowspan="2" valign="top" >CDV gma-500</td>
-	<td rowspan="3" valign="top" >Generic</td>
+	<td rowspan="2" valign="top" >Generic</td>
 	<td valign="top" >"Broadcast RGB"</td>
 	<td valign="top" >ENUM</td>
 	<td valign="top" >{ “Full”, “Limited 16:235” }</td>
@@ -2815,15 +2830,8 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td valign="top" >Standard name as in DRM</td>
+	<td rowspan="19" valign="top" >Poulsbo</td>
-	<td valign="top" >Standard type as in DRM</td>
+	<td rowspan="1" valign="top" >Generic</td>
 	<td valign="top" >Standard value as in DRM</td>
 	<td valign="top" >Standard Object as in DRM</td>
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td rowspan="20" valign="top" >Poulsbo</td>
 	<td rowspan="2" valign="top" >Generic</td>
 	<td valign="top" >“backlight”</td>
 	<td valign="top" >RANGE</td>
 	<td valign="top" >Min=0, Max=100</td>
@@ -2831,13 +2839,6 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td valign="top" >Standard name as in DRM</td>
 	<td valign="top" >Standard type as in DRM</td>
 	<td valign="top" >Standard value as in DRM</td>
 	<td valign="top" >Standard Object as in DRM</td>
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td rowspan="17" valign="top" >SDVO-TV</td>
 	<td valign="top" >“mode”</td>
 	<td valign="top" >ENUM</td>
@@ -3064,7 +3065,7 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td rowspan="3" valign="top" >i2c/ch7006_drv</td>
+	<td rowspan="2" valign="top" >i2c/ch7006_drv</td>
 	<td valign="top" >Generic</td>
 	<td valign="top" >“scale”</td>
 	<td valign="top" >RANGE</td>
@@ -3073,14 +3074,7 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td rowspan="2" valign="top" >TV</td>
+	<td rowspan="1" valign="top" >TV</td>
 	<td valign="top" >Standard names as in DRM</td>
 	<td valign="top" >Standard types as in DRM</td>
 	<td valign="top" >Standard Values as in DRM</td>
 	<td valign="top" >Standard object as in DRM</td>
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td valign="top" >“mode”</td>
 	<td valign="top" >ENUM</td>
 	<td valign="top" >{ "PAL", "PAL-M","PAL-N"}, ”PAL-Nc"
@@ -3089,7 +3083,7 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td rowspan="16" valign="top" >nouveau</td>
+	<td rowspan="15" valign="top" >nouveau</td>
 	<td rowspan="6" valign="top" >NV10 Overlay</td>
 	<td valign="top" >"colorkey"</td>
 	<td valign="top" >RANGE</td>
@@ -3198,14 +3192,6 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td valign="top" >Generic</td>
 	<td valign="top" >Standard name as in DRM</td>
 	<td valign="top" >Standard type as in DRM</td>
 	<td valign="top" >Standard value as in DRM</td>
 	<td valign="top" >Standard Object as in DRM</td>
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td rowspan="2" valign="top" >omap</td>
 	<td rowspan="2" valign="top" >Generic</td>
 	<td valign="top" >“rotation”</td>
@@ -3236,7 +3222,7 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
-	<td rowspan="10" valign="top" >radeon</td>
+	<td rowspan="9" valign="top" >radeon</td>
 	<td valign="top" >DVI-I</td>
 	<td valign="top" >“coherent”</td>
 	<td valign="top" >RANGE</td>
@@ -3308,14 +3294,6 @@ void intel_crt_init(struct drm_device *dev)
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td valign="top" >Generic</td>
 	<td valign="top" >Standard name as in DRM</td>
 	<td valign="top" >Standard type as in DRM</td>
 	<td valign="top" >Standard value as in DRM</td>
 	<td valign="top" >Standard Object as in DRM</td>
 	<td valign="top" >TBD</td>
 	</tr>
 	<tr>
 	<td rowspan="3" valign="top" >rcar-du</td>
 	<td rowspan="3" valign="top" >Generic</td>
 	<td valign="top" >"alpha"</td>
@@ -3407,6 +3385,13 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
      by scheduling a timer. The delay is accessible through the vblankoffdelay
      module parameter or the <varname>drm_vblank_offdelay</varname> global
      variable and expressed in milliseconds. Its default value is 5000 ms.
      Zero means never disable, and a negative value means disable immediately.
      Drivers may override the behaviour by setting the
      <structname>drm_device</structname>
      <structfield>vblank_disable_immediate</structfield> flag, which when set
      causes vblank interrupts to be disabled immediately regardless of the
      drm_vblank_offdelay value. The flag should only be set if there's a
      properly working hardware vblank counter present.
    </para>
    <para>
      When a vertical blanking interrupt occurs drivers only need to call the
@@ -3421,6 +3406,7 @@ void (*disable_vblank) (struct drm_device *dev, int crtc);</synopsis>
    <sect2>
      <title>Vertical Blanking and Interrupt Handling Functions Reference</title>
 !Edrivers/gpu/drm/drm_irq.c
 !Finclude/drm/drmP.h drm_crtc_vblank_waitqueue
    </sect2>
  </sect1>
@@ -3939,6 +3925,11 @@ int num_ioctls;</synopsis>
 !Pdrivers/gpu/drm/i915/i915_cmd_parser.c batch buffer command parser
 !Idrivers/gpu/drm/i915/i915_cmd_parser.c
      </sect2>
      <sect2>
        <title>Logical Rings, Logical Ring Contexts and Execlists</title>
 !Pdrivers/gpu/drm/i915/intel_lrc.c Logical Rings, Logical Ring Contexts and Execlists
 !Idrivers/gpu/drm/i915/intel_lrc.c
      </sect2>
    </sect1>
  </chapter>
 </part>
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1972,7 +1972,7 @@ machines due to caching.
   <itemizedlist>
    <listitem>
     <para>
-       <filename>Documentation/spinlocks.txt</filename>: 
+       <filename>Documentation/locking/spinlocks.txt</filename>:
       Linus Torvalds' spinlocking tutorial in the kernel sources.
     </para>
    </listitem>
--- a/Documentation/DocBook/media/Makefile
+++ b/Documentation/DocBook/media/Makefile
@@ -25,7 +25,7 @@ GENFILES := $(addprefix $(MEDIA_OBJ_DIR)/, $(MEDIA_TEMP))
 PHONY += cleanmediadocs
 cleanmediadocs:
-	-@rm `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2>/dev/null
+	-@rm -f `find $(MEDIA_OBJ_DIR) -type l` $(GENFILES) $(OBJIMGFILES) 2>/dev/null
 $(obj)/media_api.xml: $(GENFILES) FORCE
--- a/Documentation/DocBook/media/v4l/common.xml
+++ b/Documentation/DocBook/media/v4l/common.xml
@@ -110,7 +110,7 @@ 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>
+(see libmedia_dev in the <ulink url="http://git.linuxtv.org/cgit.cgi/v4l-utils.git/">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>
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2545,6 +2545,40 @@ fields changed from _s32 to _u32.
      </orderedlist>
    </section>
    <section>
      <title>V4L2 in Linux 3.16</title>
      <orderedlist>
        <listitem>
 	  <para>Added event V4L2_EVENT_SOURCE_CHANGE.
 	  </para>
        </listitem>
      </orderedlist>
    </section>
    <section>
      <title>V4L2 in Linux 3.17</title>
      <orderedlist>
        <listitem>
 	  <para>Extended &v4l2-pix-format;. Added format flags.
 	  </para>
        </listitem>
        <listitem>
 	  <para>Added compound control types and &VIDIOC-QUERY-EXT-CTRL;.
 	  </para>
        </listitem>
      </orderedlist>
    </section>
    <section>
      <title>V4L2 in Linux 3.18</title>
      <orderedlist>
 	<listitem>
 	  <para>Added <constant>V4L2_CID_PAN_SPEED</constant> and
 <constant>V4L2_CID_TILT_SPEED</constant> camera controls.</para>
 	</listitem>
      </orderedlist>
    </section>
    <section id="other">
      <title>Relation of V4L2 to other Linux multimedia APIs</title>
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -3965,6 +3965,27 @@ by exposure, white balance or focus controls.</entry>
 	  </row>
 	  <row><entry></entry></row>
 	  <row>
 	    <entry spanname="id"><constant>V4L2_CID_PAN_SPEED</constant>&nbsp;</entry>
 	    <entry>integer</entry>
 	  </row><row><entry spanname="descr">This control turns the
 camera horizontally at the specific speed. The unit is undefined. A
 positive value moves the camera to the right (clockwise when viewed
 from above), a negative value to the left. A value of zero stops the motion
 if one is in progress and has no effect otherwise.</entry>
 	  </row>
 	  <row><entry></entry></row>
 	  <row>
 	    <entry spanname="id"><constant>V4L2_CID_TILT_SPEED</constant>&nbsp;</entry>
 	    <entry>integer</entry>
 	  </row><row><entry spanname="descr">This control turns the
 camera vertically at the specified speed. The unit is undefined. A
 positive value moves the camera up, a negative value down. A value of zero
 stops the motion if one is in progress and has no effect otherwise.</entry>
 	  </row>
 	  <row><entry></entry></row>
 	</tbody>
      </tgroup>
    </table>
@@ -4790,6 +4811,40 @@ interface and may change in the future.</para>
 	    conversion.
 	    </entry>
 	  </row>
 	  <row>
 	    <entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_RED</constant></entry>
 	    <entry>integer</entry>
 	  </row>
 	  <row>
 	    <entry spanname="descr">Test pattern red colour component.
 	    </entry>
 	  </row>
 	  <row>
 	    <entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_GREENR</constant></entry>
 	    <entry>integer</entry>
 	  </row>
 	  <row>
 	    <entry spanname="descr">Test pattern green (next to red)
 	    colour component.
 	    </entry>
 	  </row>
 	  <row>
 	    <entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_BLUE</constant></entry>
 	    <entry>integer</entry>
 	  </row>
 	  <row>
 	    <entry spanname="descr">Test pattern blue colour component.
 	    </entry>
 	  </row>
 	  <row>
 	    <entry spanname="id"><constant>V4L2_CID_TEST_PATTERN_GREENB</constant></entry>
 	    <entry>integer</entry>
 	  </row>
 	  <row>
 	    <entry spanname="descr">Test pattern green (next to blue)
 	    colour component.
 	    </entry>
 	  </row>
 	  <row><entry></entry></row>
 	</tbody>
      </tgroup>
--- a/Documentation/DocBook/media/v4l/func-poll.xml
+++ b/Documentation/DocBook/media/v4l/func-poll.xml
@@ -29,9 +29,12 @@ can suspend execution until the driver has captured data or is ready
 to accept data for output.</para>
    <para>When streaming I/O has been negotiated this function waits
-until a buffer has been filled or displayed and can be dequeued with
+until a buffer has been filled by the capture device and can be dequeued
-the &VIDIOC-DQBUF; ioctl. When buffers are already in the outgoing
+with the &VIDIOC-DQBUF; ioctl. For output devices this function waits
-queue of the driver the function returns immediately.</para>
+until the device is ready to accept a new buffer to be queued up with
 the &VIDIOC-QBUF; ioctl for display. When buffers are already in the outgoing
 queue of the driver (capture) or the incoming queue isn't full (display)
 the function returns immediately.</para>
    <para>On success <function>poll()</function> returns the number of
 file descriptors that have been selected (that is, file descriptors
@@ -44,10 +47,22 @@ Capture devices set the <constant>POLLIN</constant> and
 flags. When the function timed out it returns a value of zero, on
 failure it returns <returnvalue>-1</returnvalue> and the
 <varname>errno</varname> variable is set appropriately. When the
-application did not call &VIDIOC-QBUF; or &VIDIOC-STREAMON; yet the
+application did not call &VIDIOC-STREAMON; the
 <function>poll()</function> function succeeds, but sets the
 <constant>POLLERR</constant> flag in the
-<structfield>revents</structfield> field.</para>
+<structfield>revents</structfield> field. When the
 application has called &VIDIOC-STREAMON; for a capture device but hasn't
 yet called &VIDIOC-QBUF;, the <function>poll()</function> function
 succeeds and sets the <constant>POLLERR</constant> flag in the
 <structfield>revents</structfield> field. For output devices this
 same situation will cause <function>poll()</function> to succeed
 as well, but it sets the <constant>POLLOUT</constant> and
 <constant>POLLWRNORM</constant> flags in the <structfield>revents</structfield>
 field.</para>
    <para>If an event occurred (see &VIDIOC-DQEVENT;) then
 <constant>POLLPRI</constant> will be set in the <structfield>revents</structfield>
 field and <function>poll()</function> will return.</para>
    <para>When use of the <function>read()</function> function has
 been negotiated and the driver does not capture yet, the
@@ -58,10 +73,18 @@ continuously (as opposed to, for example, still images) the function
 may return immediately.</para>
    <para>When use of the <function>write()</function> function has
-been negotiated the <function>poll</function> function just waits
+been negotiated and the driver does not stream yet, the
 <function>poll</function> function starts streaming. When that fails
 it returns a <constant>POLLERR</constant> as above. Otherwise it waits
 until the driver is ready for a non-blocking
 <function>write()</function> call.</para>
    <para>If the caller is only interested in events (just
 <constant>POLLPRI</constant> is set in the <structfield>events</structfield>
 field), then <function>poll()</function> will <emphasis>not</emphasis>
 start streaming if the driver does not stream yet. This makes it
 possible to just poll for events and not for buffers.</para>
    <para>All drivers implementing the <function>read()</function> or
 <function>write()</function> function or streaming I/O must also
 support the <function>poll()</function> function.</para>
--- a/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-packed-rgb.xml
@@ -237,9 +237,9 @@ for a pixel lie next to each other in memory.</para>
 	    <entry>g<subscript>4</subscript></entry>
 	    <entry>g<subscript>3</subscript></entry>
 	  </row>
-	  <row id="V4L2-PIX-FMT-RGB555X">
+	  <row id="V4L2-PIX-FMT-ARGB555X">
-	    <entry><constant>V4L2_PIX_FMT_RGB555X</constant></entry>
+	    <entry><constant>V4L2_PIX_FMT_ARGB555X</constant></entry>
-	    <entry>'RGBQ'</entry>
+	    <entry>'AR15' | (1 &lt;&lt; 31)</entry>
 	    <entry></entry>
 	    <entry>a</entry>
 	    <entry>r<subscript>4</subscript></entry>
@@ -259,6 +259,28 @@ for a pixel lie next to each other in memory.</para>
 	    <entry>b<subscript>1</subscript></entry>
 	    <entry>b<subscript>0</subscript></entry>
 	  </row>
 	  <row id="V4L2-PIX-FMT-XRGB555X">
 	    <entry><constant>V4L2_PIX_FMT_XRGB555X</constant></entry>
 	    <entry>'XR15' | (1 &lt;&lt; 31)</entry>
 	    <entry></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>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>
@@ -464,7 +486,7 @@ for a pixel lie next to each other in memory.</para>
 	  </row>
 	  <row id="V4L2-PIX-FMT-ARGB32">
 	    <entry><constant>V4L2_PIX_FMT_ARGB32</constant></entry>
-	    <entry>'AX24'</entry>
+	    <entry>'BA24'</entry>
 	    <entry></entry>
 	    <entry>a<subscript>7</subscript></entry>
 	    <entry>a<subscript>6</subscript></entry>
@@ -800,6 +822,28 @@ image</title>
 	    <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-BGR32">
 	    <entry><constant>V4L2_PIX_FMT_BGR32</constant></entry>
 	    <entry>'BGR4'</entry>
--- a/Documentation/DocBook/media/v4l/v4l2.xml
+++ b/Documentation/DocBook/media/v4l/v4l2.xml
@@ -152,10 +152,11 @@ structs, ioctls) must be noted in more detail in the history chapter
 applications. -->
      <revision>
-	<revnumber>3.16</revnumber>
+	<revnumber>3.17</revnumber>
-	<date>2014-05-27</date>
+	<date>2014-08-04</date>
-	<authorinitials>lp</authorinitials>
+	<authorinitials>lp, hv</authorinitials>
-	<revremark>Extended &v4l2-pix-format;. Added format flags.
+	<revremark>Extended &v4l2-pix-format;. Added format flags. Added compound control types
 and VIDIOC_QUERY_EXT_CTRL.
 	</revremark>
      </revision>
@@ -538,7 +539,7 @@ and discussions on the V4L mailing list.</revremark>
 </partinfo>
 <title>Video for Linux Two API Specification</title>
- <subtitle>Revision 3.14</subtitle>
+ <subtitle>Revision 3.17</subtitle>
  <chapter id="common">
    &sub-common;
--- a/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-dqevent.xml
@@ -76,21 +76,22 @@
 	    <entry></entry>
 	    <entry>&v4l2-event-vsync;</entry>
            <entry><structfield>vsync</structfield></entry>
-	    <entry>Event data for event V4L2_EVENT_VSYNC.
+	    <entry>Event data for event <constant>V4L2_EVENT_VSYNC</constant>.
            </entry>
 	  </row>
 	  <row>
 	    <entry></entry>
 	    <entry>&v4l2-event-ctrl;</entry>
            <entry><structfield>ctrl</structfield></entry>
-	    <entry>Event data for event V4L2_EVENT_CTRL.
+	    <entry>Event data for event <constant>V4L2_EVENT_CTRL</constant>.
            </entry>
 	  </row>
 	  <row>
 	    <entry></entry>
 	    <entry>&v4l2-event-frame-sync;</entry>
            <entry><structfield>frame_sync</structfield></entry>
-	    <entry>Event data for event V4L2_EVENT_FRAME_SYNC.</entry>
+	    <entry>Event data for event
 	    <constant>V4L2_EVENT_FRAME_SYNC</constant>.</entry>
 	  </row>
 	  <row>
 	    <entry></entry>
--- a/Documentation/DocBook/media/v4l/vidioc-g-edid.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-edid.xml
@@ -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_edid *<parameter>argp</parameter></paramdef>
+	<paramdef>struct v4l2_edid *<parameter>argp</parameter></paramdef>
      </funcprototype>
    </funcsynopsis>
  </refsynopsisdiv>
@@ -124,18 +124,18 @@
 	    maximum number of blocks as defined by the standard). When you set the EDID and
 	    <structfield>blocks</structfield> is 0, then the EDID is disabled or erased.</entry>
 	  </row>
 	  <row>
 	    <entry>__u8&nbsp;*</entry>
 	    <entry><structfield>edid</structfield></entry>
 	    <entry>Pointer to memory that contains the EDID. The minimum size is
 	    <structfield>blocks</structfield>&nbsp;*&nbsp;128.</entry>
 	  </row>
 	  <row>
 	    <entry>__u32</entry>
 	    <entry><structfield>reserved</structfield>[5]</entry>
 	    <entry>Reserved for future extensions. Applications and drivers must
 	    set the array to zero.</entry>
 	  </row>
 	  <row>
 	    <entry>__u8&nbsp;*</entry>
 	    <entry><structfield>edid</structfield></entry>
 	    <entry>Pointer to memory that contains the EDID. The minimum size is
 	    <structfield>blocks</structfield>&nbsp;*&nbsp;128.</entry>
 	  </row>
 	</tbody>
      </tgroup>
    </table>
--- a/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subdev-g-selection.xml
@@ -119,7 +119,7 @@
 	  </row>
 	  <row>
 	    <entry>&v4l2-rect;</entry>
-	    <entry><structfield>rect</structfield></entry>
+	    <entry><structfield>r</structfield></entry>
 	    <entry>Selection rectangle, in pixels.</entry>
 	  </row>
 	  <row>
--- a/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-subscribe-event.xml
@@ -176,7 +176,7 @@
 	  </row>
 	  <row>
 	    <entry><constant>V4L2_EVENT_MOTION_DET</constant></entry>
-	    <entry>5</entry>
+	    <entry>6</entry>
 	    <entry>
 	      <para>Triggered whenever the motion detection state for one or more of the regions
 	      changes. This event has a &v4l2-event-motion-det; associated with it.</para>
--- a/Documentation/DocBook/usb.tmpl
+++ b/Documentation/DocBook/usb.tmpl
@@ -593,7 +593,7 @@ for (;;) {
 	    Each device has one control endpoint (endpoint zero)
 	    which supports a limited RPC style RPC access.
 	    Devices are configured
-	    by khubd (in the kernel) setting a device-wide
+	    by hub_wq (in the kernel) setting a device-wide
 	    <emphasis>configuration</emphasis> that affects things
 	    like power consumption and basic functionality.
 	    The endpoints are part of USB <emphasis>interfaces</emphasis>,
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -2742,7 +2742,9 @@ struct _snd_pcm_runtime {
        <para>
          Another note is that this callback is non-atomic
-        (schedulable). This is important, because the
+        (schedulable) as default, i.e. when no
 	<structfield>nonatomic</structfield> flag set.
 	This is important, because the
        <structfield>trigger</structfield> callback 
        is atomic (non-schedulable). That is, mutexes or any
        schedule-related functions are not available in
@@ -2900,8 +2902,9 @@ struct _snd_pcm_runtime {
        </para>
        <para>
-          As mentioned, this callback is atomic.  You cannot call
+          As mentioned, this callback is atomic as default unless
-	  functions which may sleep.
+	  <structfield>nonatomic</structfield> flag set, and
 	  you cannot call functions which may sleep.
 	  The trigger callback should be as minimal as possible,
 	  just really triggering the DMA.  The other stuff should be
 	  initialized hw_params and prepare callbacks properly
@@ -2936,7 +2939,7 @@ struct _snd_pcm_runtime {
        </para>
        <para>
-          This callback is also atomic.
+          This callback is also atomic as default.
        </para>
      </section>
@@ -2972,7 +2975,7 @@ struct _snd_pcm_runtime {
 	is useful only for such a purpose.
 	</para>
 	<para>
-	  This callback is atomic.
+	  This callback is atomic as default.
 	</para>
      </section>
@@ -3175,6 +3178,21 @@ struct _snd_pcm_runtime {
      called with local interrupts disabled.
      </para>
      <para>
      The recent changes in PCM core code, however, allow all PCM
      operations to be non-atomic.  This assumes that the all caller
      sides are in non-atomic contexts.  For example, the function
      <function>snd_pcm_period_elapsed()</function> is called
      typically from the interrupt handler.  But, if you set up the
      driver to use a threaded interrupt handler, this call can be in
      non-atomic context, too.  In such a case, you can set
      <structfield>nonatomic</structfield> filed of
      <structname>snd_pcm</structname> object after creating it.
      When this flag is set, mutex and rwsem are used internally in
      the PCM core instead of spin and rwlocks, so that you can call
      all PCM functions safely in a non-atomic context.
      </para>
    </section>
    <section id="pcm-interface-constraints">
      <title>Constraints</title>
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -324,7 +324,6 @@ tree, they need to be integration-tested.  For this purpose, a special
 testing repository exists into which virtually all subsystem trees are
 pulled on an almost daily basis:
 	http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
 	http://linux.f-seidel.de/linux-next/pmwiki/
 This way, the -next kernel gives a summary outlook onto what will be
 expected to go into the mainline kernel at the next merge period.
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,3 +1,4 @@
-obj-m := DocBook/ accounting/ auxdisplay/ connector/ \
+subdir-y := accounting arm auxdisplay blackfin connector \
-	filesystems/ filesystems/configfs/ ia64/ laptops/ networking/ \
+	filesystems filesystems ia64 laptops mic misc-devices \
-	pcmcia/ spi/ timers/ watchdog/src/ misc-devices/mei/
+	networking pcmcia prctl ptp spi timers vDSO video4linux \
 	watchdog
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -56,8 +56,20 @@ RCU_STALL_RAT_DELAY
 	two jiffies.  (This is a cpp macro, not a kernel configuration
 	parameter.)
-When a CPU detects that it is stalling, it will print a message similar
+rcupdate.rcu_task_stall_timeout
-to the following:
+
 	This boot/sysfs parameter controls the RCU-tasks stall warning
 	interval.  A value of zero or less suppresses RCU-tasks stall
 	warnings.  A positive value sets the stall-warning interval
 	in jiffies.  An RCU-tasks stall warning starts wtih the line:
 		INFO: rcu_tasks detected stalls on tasks:
 	And continues with the output of sched_show_task() for each
 	task stalling the current RCU-tasks grace period.
 For non-RCU-tasks flavors of RCU, when a CPU detects that it is stalling,
 it will print a message similar to the following:
 INFO: rcu_sched_state detected stall on CPU 5 (t=2500 jiffies)
@@ -174,8 +186,12 @@ o	A CPU looping with preemption disabled.  This condition can
 o	A CPU looping with bottom halves disabled.  This condition can
 	result in RCU-sched and RCU-bh stalls.
-o	For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the kernel
+o	For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
-	without invoking schedule().
+	kernel without invoking schedule().  Note that cond_resched()
 	does not necessarily prevent RCU CPU stall warnings.  Therefore,
 	if the looping in the kernel is really expected and desirable
 	behavior, you might need to replace some of the cond_resched()
 	calls with calls to cond_resched_rcu_qs().
 o	A CPU-bound real-time task in a CONFIG_PREEMPT kernel, which might
 	happen to preempt a low-priority task in the middle of an RCU
@@ -208,11 +224,10 @@ o	A hardware failure.  This is quite unlikely, but has occurred
 	This resulted in a series of RCU CPU stall warnings, eventually
 	leading the realization that the CPU had failed.
-The RCU, RCU-sched, and RCU-bh implementations have CPU stall warning.
+The RCU, RCU-sched, RCU-bh, and RCU-tasks implementations have CPU stall
-SRCU does not have its own CPU stall warnings, but its calls to
+warning.  Note that SRCU does -not- have CPU stall warnings.  Please note
-synchronize_sched() will result in RCU-sched detecting RCU-sched-related
+that RCU only detects CPU stalls when there is a grace period in progress.
-CPU stalls.  Please note that RCU only detects CPU stalls when there is
+No grace period, no CPU stall warnings.
 a grace period in progress.  No grace period, no CPU stall warnings.
 To diagnose the cause of the stall, inspect the stack traces.
 The offending function will usually be near the top of the stack.
--- a/Documentation/RCU/whatisRCU.txt
+++ b/Documentation/RCU/whatisRCU.txt
@@ -818,7 +818,7 @@ RCU pointer/list update:
 	list_add_tail_rcu
 	list_del_rcu
 	list_replace_rcu
-	hlist_add_after_rcu
+	hlist_add_behind_rcu
 	hlist_add_before_rcu
 	hlist_add_head_rcu
 	hlist_del_rcu
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -84,18 +84,42 @@ is another popular alternative.
 2) Describe your changes.
-Describe the technical detail of the change(s) your patch includes.
+Describe your problem.  Whether your patch is a one-line bug fix or
 5000 lines of a new feature, there must be an underlying problem that
 motivated you to do this work.  Convince the reviewer that there is a
 problem worth fixing and that it makes sense for them to read past the
 first paragraph.
-Be as specific as possible.  The WORST descriptions possible include
+Describe user-visible impact.  Straight up crashes and lockups are
-things like "update driver X", "bug fix for driver X", or "this patch
+pretty convincing, but not all bugs are that blatant.  Even if the
-includes updates for subsystem X.  Please apply."
+problem was spotted during code review, describe the impact you think
 it can have on users.  Keep in mind that the majority of Linux
 installations run kernels from secondary stable trees or
 vendor/product-specific trees that cherry-pick only specific patches
 from upstream, so include anything that could help route your change
 downstream: provoking circumstances, excerpts from dmesg, crash
 descriptions, performance regressions, latency spikes, lockups, etc.
 Quantify optimizations and trade-offs.  If you claim improvements in
 performance, memory consumption, stack footprint, or binary size,
 include numbers that back them up.  But also describe non-obvious
 costs.  Optimizations usually aren't free but trade-offs between CPU,
 memory, and readability; or, when it comes to heuristics, between
 different workloads.  Describe the expected downsides of your
 optimization so that the reviewer can weigh costs against benefits.
 Once the problem is established, describe what you are actually doing
 about it in technical detail.  It's important to describe the change
 in plain English for the reviewer to verify that the code is behaving
 as you intend it to.
 The maintainer will thank you if you write your patch description in a
 form which can be easily pulled into Linux's source code management
 system, git, as a "commit log".  See #15, below.
-If your description starts to get long, that's a sign that you probably
+Solve only one problem per patch.  If your description starts to get
-need to split up your patch.  See #3, next.
+long, that's a sign that you probably need to split up your patch.
 See #3, next.
 When you submit or resubmit a patch or patch series, include the
 complete patch description and justification for it.  Don't just
@@ -459,12 +483,10 @@ have been included in the discussion
 14) Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes:
-If this patch fixes a problem reported by somebody else, consider adding a
+The Reported-by tag gives credit to people who find bugs and report them and it
-Reported-by: tag to credit the reporter for their contribution.  Please
+hopefully inspires them to help us again in the future.  Please note that if
-note that this tag should not be added without the reporter's permission,
+the bug was reported in private, then ask for permission first before using the
-especially if the problem was not reported in a public forum.  That said,
+Reported-by tag.
 if we diligently credit our bug reporters, they will, hopefully, be
 inspired to help us again in the future.
 A Tested-by: tag indicates that the patch has been successfully tested (in
 some environment) by the person named.  This tag informs maintainers that
@@ -770,6 +792,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer".
  <http://www.kroah.com/log/linux/maintainer-03.html>
  <http://www.kroah.com/log/linux/maintainer-04.html>
  <http://www.kroah.com/log/linux/maintainer-05.html>
  <http://www.kroah.com/log/linux/maintainer-06.html>
 NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
  <https://lkml.org/lkml/2005/7/11/336>
--- a/Documentation/accounting/Makefile
+++ b/Documentation/accounting/Makefile
@@ -1,6 +1,3 @@
 # kbuild trick to avoid linker error. Can be omitted if a module is built.
 obj- := dummy.o
 # List of programs to build
 hostprogs-y := getdelays
--- a/Documentation/acpi/enumeration.txt
+++ b/Documentation/acpi/enumeration.txt
@@ -312,3 +312,30 @@ a code like this:
 There are also devm_* versions of these functions which release the
 descriptors once the device is released.
 MFD devices
 ~~~~~~~~~~~
 The MFD devices register their children as platform devices. For the child
 devices there needs to be an ACPI handle that they can use to reference
 parts of the ACPI namespace that relate to them. In the Linux MFD subsystem
 we provide two ways:
 	o The children share the parent ACPI handle.
 	o The MFD cell can specify the ACPI id of the device.
 For the first case, the MFD drivers do not need to do anything. The
 resulting child platform device will have its ACPI_COMPANION() set to point
 to the parent device.
 If the ACPI namespace has a device that we can match using an ACPI id,
 the id should be set like:
 	static struct mfd_cell my_subdevice_cell = {
 		.name = "my_subdevice",
 		/* set the resources relative to the parent */
 		.acpi_pnpid = "XYZ0001",
 	};
 The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under
 the MFD device and if found, that ACPI companion device is bound to the
 resulting child platform device.
--- a/Documentation/arm/CCN.txt
+++ b/Documentation/arm/CCN.txt
@@ -0,0 +1,52 @@
 ARM Cache Coherent Network
 ==========================
 CCN-504 is a ring-bus interconnect consisting of 11 crosspoints
 (XPs), with each crosspoint supporting up to two device ports,
 so nodes (devices) 0 and 1 are connected to crosspoint 0,
 nodes 2 and 3 to crosspoint 1 etc.
 PMU (perf) driver
 -----------------
 The CCN driver registers a perf PMU driver, which provides
 description of available events and configuration options
 in sysfs, see /sys/bus/event_source/devices/ccn*.
 The "format" directory describes format of the config, config1
 and config2 fields of the perf_event_attr structure. The "events"
 directory provides configuration templates for all documented
 events, that can be used with perf tool. For example "xp_valid_flit"
 is an equivalent of "type=0x8,event=0x4". Other parameters must be
 explicitly specified. For events originating from device, "node"
 defines its index. All crosspoint events require "xp" (index),
 "port" (device port number) and "vc" (virtual channel ID) and
 "dir" (direction). Watchpoints (special "event" value 0xfe) also
 require comparator values ("cmp_l" and "cmp_h") and "mask", being
 index of the comparator mask.
 Masks are defined separately from the event description
 (due to limited number of the config values) in the "cmp_mask"
 directory, with first 8 configurable by user and additional
 4 hardcoded for the most frequent use cases.
 Cycle counter is described by a "type" value 0xff and does
 not require any other settings.
 Example of perf tool use:
 / # perf list | grep ccn
  ccn/cycles/                                        [Kernel PMU event]
 <...>
  ccn/xp_valid_flit/                                 [Kernel PMU event]
 <...>
 / # perf stat -C 0 -e ccn/cycles/,ccn/xp_valid_flit,xp=1,port=0,vc=1,dir=1/ \
                                                                       sleep 1
 The driver does not support sampling, therefore "perf record" will
 not work. Also notice that only single cpu is being selected
 ("-C 0") - this is because perf framework does not support
 "non-CPU related" counters (yet?) so system-wide session ("-a")
 would try (and in most cases fail) to set up the same event
 per each CPU.
--- a/Documentation/arm/Makefile
+++ b/Documentation/arm/Makefile
@@ -0,0 +1 @@
 subdir-y := SH-Mobile
--- a/Documentation/arm/Marvell/README
+++ b/Documentation/arm/Marvell/README
@@ -53,8 +53,8 @@ Kirkwood family
                Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
  Homepage: http://www.marvell.com/embedded-processors/kirkwood/
  Core: Feroceon ARMv5 compatible
-  Linux kernel mach directory: arch/arm/mach-kirkwood
+  Linux kernel mach directory: arch/arm/mach-mvebu
-  Linux kernel plat directory: arch/arm/plat-orion
+  Linux kernel plat directory: none
 Discovery family
 ----------------
@@ -83,7 +83,9 @@ EBU Armada family
        88F6710
        88F6707
        88F6W11
-    Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
+    Product Brief:   http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
    Hardware Spec:   http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
    Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
  Armada 375 Flavors:
 	88F6720
@@ -100,8 +102,11 @@ EBU Armada family
        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
-
+    Functional Spec: http://www.marvell.com/embedded-processors/armada-xp/assets/ARMADA-XP-Functional-SpecDatasheet.pdf
-  No public datasheet available.
+    Hardware Specs:
      http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
      http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
      http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
  Core: Sheeva ARMv7 compatible
@@ -135,7 +140,9 @@ Dove family (application processor)
                Functional Spec : http://www.marvell.com/application-processors/armada-500/assets/Armada-510-Functional-Spec.pdf
  Homepage: http://www.marvell.com/application-processors/armada-500/
  Core: ARMv7 compatible
-  Directory: arch/arm/mach-dove
+
  Directory: arch/arm/mach-mvebu (DT enabled platforms)
             arch/arm/mach-dove (non-DT enabled platforms)
 PXA 2xx/3xx/93x/95x family
 --------------------------
@@ -253,10 +260,10 @@ Berlin family (Digital Entertainment)
 Long-term plans
 ---------------
- * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ and
+ * Unify the mach-dove/, mach-mv78xx0/, mach-orion5x/ into the
-   mach-kirkwood/ into the mach-mvebu/ to support all SoCs from the
+   mach-mvebu/ to support all SoCs from the Marvell EBU (Engineering
-   Marvell EBU (Engineering Business Unit) in a single mach-<foo>
+   Business Unit) in a single mach-<foo> directory. The plat-orion/
-   directory. The plat-orion/ would therefore disappear.
+   would therefore disappear.
 * Unify the mach-mmp/ and mach-pxa/ into the same mach-pxa
   directory. The plat-pxa/ would therefore disappear.
--- a/Documentation/arm/SH-Mobile/.gitignore
+++ b/Documentation/arm/SH-Mobile/.gitignore
@@ -0,0 +1 @@
 vrl4
--- a/Documentation/arm/SH-Mobile/Makefile
+++ b/Documentation/arm/SH-Mobile/Makefile
@@ -1,8 +1,7 @@
-BIN := vrl4
+# List of programs to build
 hostprogs-y := vrl4
-.PHONY: all
+# Tell kbuild to always build the programs
-all: $(BIN)
+always := $(hostprogs-y)
-.PHONY: clean
+HOSTCFLAGS_vrl4.o += -I$(objtree)/usr/include -I$(srctree)/tools/include
 clean:
 	rm -f *.o $(BIN)
--- a/Documentation/arm/SH-Mobile/vrl4.c
+++ b/Documentation/arm/SH-Mobile/vrl4.c
@@ -34,6 +34,7 @@
 #include <stdint.h>
 #include <stdio.h>
 #include <errno.h>
 #include <tools/endian.h>
 struct hdr {
 	uint32_t magic1;
@@ -77,7 +78,7 @@ struct hdr {
 #define ROUND_UP(x)	((x + ALIGN - 1) & ~(ALIGN - 1))
-ssize_t do_read(int fd, void *buf, size_t count)
+static ssize_t do_read(int fd, void *buf, size_t count)
 {
 	size_t offset = 0;
 	ssize_t l;
@@ -98,7 +99,7 @@ ssize_t do_read(int fd, void *buf, size_t count)
 	return offset;
 }
-ssize_t do_write(int fd, const void *buf, size_t count)
+static ssize_t do_write(int fd, const void *buf, size_t count)
 {
 	size_t offset = 0;
 	ssize_t l;
@@ -117,7 +118,7 @@ ssize_t do_write(int fd, const void *buf, size_t count)
 	return offset;
 }
-ssize_t write_zero(int fd, size_t len)
+static ssize_t write_zero(int fd, size_t len)
 {
 	size_t i = len;
--- a/Documentation/arm/Samsung/Overview.txt
+++ b/Documentation/arm/Samsung/Overview.txt
@@ -13,8 +13,6 @@ Introduction
  - S3C24XX: See Documentation/arm/Samsung-S3C24XX/Overview.txt for full list
  - S3C64XX: S3C6400 and S3C6410
  - S5P6440
  - S5PC100
  - S5PC110 / S5PV210
@@ -34,8 +32,6 @@ Configuration
  A number of configurations are supplied, as there is no current way of
  unifying all the SoCs into one kernel.
  s5p6440_defconfig - S5P6440 specific default configuration
  s5pc100_defconfig - S5PC100 specific default configuration
  s5pc110_defconfig - S5PC110 specific default configuration
  s5pv210_defconfig - S5PV210 specific default configuration
@@ -67,13 +63,6 @@ Layout changes
  where to simplify the include and dependency issues involved with having
  so many different platform directories.
  It was decided to remove plat-s5pc1xx as some of the support was already
  in plat-s5p or plat-samsung, with the S5PC110 support added with S5PV210
  the only user was the S5PC100. The S5PC100 specific items where moved to
  arch/arm/mach-s5pc100.
 Port Contributors
 -----------------
--- a/Documentation/arm/Samsung/clksrc-change-registers.awk
+++ b/Documentation/arm/Samsung/clksrc-change-registers.awk
@@ -68,7 +68,6 @@ BEGIN {
    while (getline line < ARGV[1] > 0) {
 	if (line ~ /\#define.*_MASK/ &&
 	    !(line ~ /S5PC100_EPLL_MASK/) &&
 	    !(line ~ /USB_SIG_MASK/)) {
 	    splitdefine(line, fields)
 	    name = fields[0]
--- a/Documentation/arm64/booting.txt
+++ b/Documentation/arm64/booting.txt
@@ -168,6 +168,14 @@ Before jumping into the kernel, the following conditions must be met:
  the kernel image will be entered must be initialised by software at a
  higher exception level to prevent execution in an UNKNOWN state.
  For systems with a GICv3 interrupt controller:
  - If EL3 is present:
    ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
    ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
  - If the kernel is entered at EL1:
    ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
    ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
 The requirements described above for CPU mode, caches, MMUs, architected
 timers, coherency and system registers apply to all CPUs.  All CPUs must
 enter the kernel in the same exception level.
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -17,7 +17,7 @@ User addresses have bits 63:48 set to 0 while the kernel addresses have
 the same bits set to 1. TTBRx selection is given by bit 63 of the
 virtual address. The swapper_pg_dir contains only kernel (global)
 mappings while the user pgd contains only user (non-global) mappings.
-The swapper_pgd_dir address is written to TTBR1 and never written to
+The swapper_pg_dir address is written to TTBR1 and never written to
 TTBR0.
--- a/Documentation/auxdisplay/Makefile
+++ b/Documentation/auxdisplay/Makefile
@@ -1,6 +1,3 @@
 # kbuild trick to avoid linker error. Can be omitted if a module is built.
 obj- := dummy.o
 # List of programs to build
 hostprogs-y := cfag12864b-example
--- a/Documentation/binfmt_misc.txt
+++ b/Documentation/binfmt_misc.txt
@@ -15,39 +15,50 @@ First you must mount binfmt_misc:
 	mount binfmt_misc -t binfmt_misc /proc/sys/fs/binfmt_misc 
 To actually register a new binary type, you have to set up a string looking like
-:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':' upon
+:name:type:offset:magic:mask:interpreter:flags (where you can choose the ':'
-your needs) and echo it to /proc/sys/fs/binfmt_misc/register.
+upon your needs) and echo it to /proc/sys/fs/binfmt_misc/register.
 Here is what the fields mean:
 - 'name' is an identifier string. A new /proc file will be created with this
-   name below /proc/sys/fs/binfmt_misc
+   name below /proc/sys/fs/binfmt_misc; cannot contain slashes '/' for obvious
   reasons.
 - 'type' is the type of recognition. Give 'M' for magic and 'E' for extension.
 - 'offset' is the offset of the magic/mask in the file, counted in bytes. This
-   defaults to 0 if you omit it (i.e. you write ':name:type::magic...')
+   defaults to 0 if you omit it (i.e. you write ':name:type::magic...'). Ignored
   when using filename extension matching.
 - 'magic' is the byte sequence binfmt_misc is matching for. The magic string
-   may contain hex-encoded characters like \x0a or \xA4. In a shell environment
+   may contain hex-encoded characters like \x0a or \xA4. Note that you must
-   you will have to write \\x0a to prevent the shell from eating your \.
+   escape any NUL bytes; parsing halts at the first one. In a shell environment
   you might have to write \\x0a to prevent the shell from eating your \.
   If you chose filename extension matching, this is the extension to be
   recognised (without the '.', the \x0a specials are not allowed). Extension
-   matching is case sensitive!
+   matching is case sensitive, and slashes '/' are not allowed!
 - 'mask' is an (optional, defaults to all 0xff) mask. You can mask out some
   bits from matching by supplying a string like magic and as long as magic.
-   The mask is anded with the byte sequence of the file.
+   The mask is anded with the byte sequence of the file. Note that you must
   escape any NUL bytes; parsing halts at the first one. Ignored when using
   filename extension matching.
 - 'interpreter' is the program that should be invoked with the binary as first
   argument (specify the full path)
 - 'flags' is an optional field that controls several aspects of the invocation
-   of the interpreter. It is a string of capital letters, each controls a certain
+   of the interpreter. It is a string of capital letters, each controls a
-   aspect. The following flags are supported -
+   certain aspect. The following flags are supported -
-      'P' - preserve-argv[0].  Legacy behavior of binfmt_misc is to overwrite the
+      'P' - preserve-argv[0]. Legacy behavior of binfmt_misc is to overwrite
-            original argv[0] with the full path to the binary.  When this flag is
+            the original argv[0] with the full path to the binary. When this
-            included, binfmt_misc will add an argument to the argument vector for
+            flag is included, binfmt_misc will add an argument to the argument
-            this purpose, thus preserving the original argv[0].
+            vector for this purpose, thus preserving the original argv[0].
            e.g. If your interp is set to /bin/foo and you run `blah` (which is
            in /usr/local/bin), then the kernel will execute /bin/foo with
            argv[] set to ["/bin/foo", "/usr/local/bin/blah", "blah"].  The
            interp has to be aware of this so it can execute /usr/local/bin/blah
            with argv[] set to ["blah"].
      'O' - open-binary. Legacy behavior of binfmt_misc is to pass the full path
            of the binary to the interpreter as an argument. When this flag is
            included, binfmt_misc will open the file for reading and pass its
            descriptor as an argument, instead of the full path, thus allowing
-            the interpreter to execute non-readable binaries. This feature should
+            the interpreter to execute non-readable binaries. This feature
-            be used with care - the interpreter has to be trusted not to emit
+            should be used with care - the interpreter has to be trusted not to
-            the contents of the non-readable binary.
+            emit the contents of the non-readable binary.
      'C' - credentials. Currently, the behavior of binfmt_misc is to calculate
            the credentials and security token of the new process according to
            the interpreter. When this flag is included, these attributes are
@@ -58,7 +69,7 @@ Here is what the fields mean:
 There are some restrictions:
- - the whole register string may not exceed 255 characters
+ - the whole register string may not exceed 1920 characters
 - the magic must reside in the first 128 bytes of the file, i.e.
   offset+size(magic) has to be less than 128
 - the interpreter string may not exceed 127 characters
@@ -110,7 +121,4 @@ passes it the full filename (or the file descriptor) to use.  Using $PATH can
 cause unexpected behaviour and can be a security hazard.
 There is a web page about binfmt_misc at
 http://www.tat.physik.uni-tuebingen.de
 Richard Günther <rguenth@tat.physik.uni-tuebingen.de>
--- a/Documentation/blackfin/Makefile
+++ b/Documentation/blackfin/Makefile
@@ -1,6 +1,3 @@
 ifneq ($(CONFIG_BLACKFIN),)
 obj-m := gptimers-example.o
-
+endif
 all: modules
 modules clean:
 	$(MAKE) -C ../.. SUBDIRS=$(PWD) $@
--- a/Documentation/block/data-integrity.txt
+++ b/Documentation/block/data-integrity.txt
@@ -129,11 +129,11 @@ interface for this is being worked on.
 4.1 BIO
 The data integrity patches add a new field to struct bio when
-CONFIG_BLK_DEV_INTEGRITY is enabled.  bio->bi_integrity is a pointer
+CONFIG_BLK_DEV_INTEGRITY is enabled.  bio_integrity(bio) returns a
-to a struct bip which contains the bio integrity payload.  Essentially
+pointer to a struct bip which contains the bio integrity payload.
-a bip is a trimmed down struct bio which holds a bio_vec containing
+Essentially a bip is a trimmed down struct bio which holds a bio_vec
-the integrity metadata and the required housekeeping information (bvec
+containing the integrity metadata and the required housekeeping
-pool, vector count, etc.)
+information (bvec pool, vector count, etc.)
 A kernel subsystem can enable data integrity protection on a bio by
 calling bio_integrity_alloc(bio).  This will allocate and attach the
@@ -192,16 +192,6 @@ will require extra work due to the application tag.
    supported by the block device.
    int bdev_integrity_enabled(block_device, int rw);
      bdev_integrity_enabled() will return 1 if the block device
      supports integrity metadata transfer for the data direction
      specified in 'rw'.
      bdev_integrity_enabled() honors the write_generate and
      read_verify flags in sysfs and will respond accordingly.
    int bio_integrity_prep(bio);
      To generate IMD for WRITE and to set up buffers for READ, the
@@ -216,36 +206,6 @@ will require extra work due to the application tag.
      bio_integrity_enabled() returned 1.
    int bio_integrity_tag_size(bio);
      If the filesystem wants to use the application tag space it will
      first have to find out how much storage space is available.
      Because tag space is generally limited (usually 2 bytes per
      sector regardless of sector size), the integrity framework
      supports interleaving the information between the sectors in an
      I/O.
      Filesystems can call bio_integrity_tag_size(bio) to find out how
      many bytes of storage are available for that particular bio.
      Another option is bdev_get_tag_size(block_device) which will
      return the number of available bytes per hardware sector.
    int bio_integrity_set_tag(bio, void *tag_buf, len);
      After a successful return from bio_integrity_prep(),
      bio_integrity_set_tag() can be used to attach an opaque tag
      buffer to a bio.  Obviously this only makes sense if the I/O is
      a WRITE.
    int bio_integrity_get_tag(bio, void *tag_buf, len);
      Similarly, at READ I/O completion time the filesystem can
      retrieve the tag buffer using bio_integrity_get_tag().
 5.3 PASSING EXISTING INTEGRITY METADATA
    Filesystems that either generate their own integrity metadata or
@@ -298,8 +258,6 @@ will require extra work due to the application tag.
            .name                   = "STANDARDSBODY-TYPE-VARIANT-CSUM",
            .generate_fn            = my_generate_fn,
       	    .verify_fn              = my_verify_fn,
       	    .get_tag_fn             = my_get_tag_fn,
       	    .set_tag_fn             = my_set_tag_fn,
 	    .tuple_size             = sizeof(struct my_tuple_size),
 	    .tag_size               = <tag bytes per hw sector>,
        };
@@ -321,7 +279,5 @@ will require extra work due to the application tag.
      are available per hardware sector.  For DIF this is either 2 or
      0 depending on the value of the Control Mode Page ATO bit.
      See 6.2 for a description of get_tag_fn and set_tag_fn.
 ----------------------------------------------------------------------
 2007-12-24 Martin K. Petersen <martin.petersen@oracle.com>
--- a/Documentation/blockdev/zram.txt
+++ b/Documentation/blockdev/zram.txt
@@ -74,14 +74,30 @@ 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:
+5) Set memory limit: Optional
 	Set memory limit by writing the value to sysfs node 'mem_limit'.
 	The value can be either in bytes or you can use mem suffixes.
 	In addition, you could change the value in runtime.
 	Examples:
 	    # limit /dev/zram0 with 50MB memory
 	    echo $((50*1024*1024)) > /sys/block/zram0/mem_limit
 	    # Using mem suffixes
 	    echo 256K > /sys/block/zram0/mem_limit
 	    echo 512M > /sys/block/zram0/mem_limit
 	    echo 1G > /sys/block/zram0/mem_limit
 	    # To disable memory limit
 	    echo 0 > /sys/block/zram0/mem_limit
 6) Activate:
 	mkswap /dev/zram0
 	swapon /dev/zram0
 	mkfs.ext4 /dev/zram1
 	mount /dev/zram1 /tmp
-6) Stats:
+7) Stats:
 	Per-device statistics are exported as various nodes under
 	/sys/block/zram<id>/
 		disksize
@@ -95,12 +111,13 @@ size of the disk when not in use so a huge zram is wasteful.
 		orig_data_size
 		compr_data_size
 		mem_used_total
 		mem_used_max
-7) Deactivate:
+8) Deactivate:
 	swapoff /dev/zram0
 	umount /dev/zram1
-8) Reset:
+9) Reset:
 	Write any positive value to 'reset' sysfs node
 	echo 1 > /sys/block/zram0/reset
 	echo 1 > /sys/block/zram1/reset
--- a/Documentation/cgroups/cpusets.txt
+++ b/Documentation/cgroups/cpusets.txt
@@ -345,14 +345,14 @@ the named feature on.
 The implementation is simple.
 Setting the flag 'cpuset.memory_spread_page' turns on a per-process flag
-PF_SPREAD_PAGE for each task that is in that cpuset or subsequently
+PFA_SPREAD_PAGE for each task that is in that cpuset or subsequently
 joins that cpuset.  The page allocation calls for the page cache
-is modified to perform an inline check for this PF_SPREAD_PAGE task
+is modified to perform an inline check for this PFA_SPREAD_PAGE task
 flag, and if set, a call to a new routine cpuset_mem_spread_node()
 returns the node to prefer for the allocation.
 Similarly, setting 'cpuset.memory_spread_slab' turns on the flag
-PF_SPREAD_SLAB, and appropriately marked slab caches will allocate
+PFA_SPREAD_SLAB, and appropriately marked slab caches will allocate
 pages from the node returned by cpuset_mem_spread_node().
 The cpuset_mem_spread_node() routine is also simple.  It uses the
--- a/Documentation/cgroups/memcg_test.txt
+++ b/Documentation/cgroups/memcg_test.txt
@@ -24,64 +24,27 @@ Please note that implementation details can be changed.
   a page/swp_entry may be charged (usage += PAGE_SIZE) at
-	mem_cgroup_charge_anon()
+	mem_cgroup_try_charge()
 	  Called at new page fault and Copy-On-Write.
 	mem_cgroup_try_charge_swapin()
 	  Called at do_swap_page() (page fault on swap entry) and swapoff.
 	  Followed by charge-commit-cancel protocol. (With swap accounting)
 	  At commit, a charge recorded in swap_cgroup is removed.
 	mem_cgroup_charge_file()
 	  Called at add_to_page_cache()
 	mem_cgroup_cache_charge_swapin()
 	  Called at shmem's swapin.
 	mem_cgroup_prepare_migration()
 	  Called before migration. "extra" charge is done and followed by
 	  charge-commit-cancel protocol.
 	  At commit, charge against oldpage or newpage will be committed.
 2. Uncharge
  a page/swp_entry may be uncharged (usage -= PAGE_SIZE) by
-	mem_cgroup_uncharge_page()
+	mem_cgroup_uncharge()
-	  Called when an anonymous page is fully unmapped. I.e., mapcount goes
+	  Called when a page's refcount goes down to 0.
 	  to 0. If the page is SwapCache, uncharge is delayed until
 	  mem_cgroup_uncharge_swapcache().
 	mem_cgroup_uncharge_cache_page()
 	  Called when a page-cache is deleted from radix-tree. If the page is
 	  SwapCache, uncharge is delayed until mem_cgroup_uncharge_swapcache().
 	mem_cgroup_uncharge_swapcache()
 	  Called when SwapCache is removed from radix-tree. The charge itself
 	  is moved to swap_cgroup. (If mem+swap controller is disabled, no
 	  charge to swap occurs.)
 	mem_cgroup_uncharge_swap()
 	  Called when swp_entry's refcnt goes down to 0. A charge against swap
 	  disappears.
 	mem_cgroup_end_migration(old, new)
 	At success of migration old is uncharged (if necessary), a charge
 	to new page is committed. At failure, charge to old page is committed.
 3. charge-commit-cancel
-	In some case, we can't know this "charge" is valid or not at charging
+	Memcg pages are charged in two steps:
-	(because of races).
+		mem_cgroup_try_charge()
-	To handle such case, there are charge-commit-cancel functions.
+		mem_cgroup_commit_charge() or mem_cgroup_cancel_charge()
 		mem_cgroup_try_charge_XXX
 		mem_cgroup_commit_charge_XXX
 		mem_cgroup_cancel_charge_XXX
 	these are used in swap-in and migration.
 	At try_charge(), there are no flags to say "this page is charged".
 	at this point, usage += PAGE_SIZE.
-	At commit(), the function checks the page should be charged or not
+	At commit(), the page is associated with the memcg.
 	and set flags or avoid charging.(usage -= PAGE_SIZE)
 	At cancel(), simply usage -= PAGE_SIZE.
@@ -91,18 +54,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	Anonymous page is newly allocated at
 		  - page fault into MAP_ANONYMOUS mapping.
 		  - Copy-On-Write.
 	It is charged right after it's allocated before doing any page table
 	related operations. Of course, it's uncharged when another page is used
 	for the fault address.
 	At freeing anonymous page (by exit() or munmap()), zap_pte() is called
 	and pages for ptes are freed one by one.(see mm/memory.c). Uncharges
 	are done at page_remove_rmap() when page_mapcount() goes down to 0.
 	Another page freeing is by page-reclaim (vmscan.c) and anonymous
 	pages are swapped out. In this case, the page is marked as
 	PageSwapCache(). uncharge() routine doesn't uncharge the page marked
 	as SwapCache(). It's delayed until __delete_from_swap_cache().
 	4.1 Swap-in.
 	At swap-in, the page is taken from swap-cache. There are 2 cases.
@@ -111,41 +62,6 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	(b) If the SwapCache has been mapped by processes, it has been
 	    charged already.
 	This swap-in is one of the most complicated work. In do_swap_page(),
 	following events occur when pte is unchanged.
 	(1) the page (SwapCache) is looked up.
 	(2) lock_page()
 	(3) try_charge_swapin()
 	(4) reuse_swap_page() (may call delete_swap_cache())
 	(5) commit_charge_swapin()
 	(6) swap_free().
 	Considering following situation for example.
 	(A) The page has not been charged before (2) and reuse_swap_page()
 	    doesn't call delete_from_swap_cache().
 	(B) The page has not been charged before (2) and reuse_swap_page()
 	    calls delete_from_swap_cache().
 	(C) The page has been charged before (2) and reuse_swap_page() doesn't
 	    call delete_from_swap_cache().
 	(D) The page has been charged before (2) and reuse_swap_page() calls
 	    delete_from_swap_cache().
 	    memory.usage/memsw.usage changes to this page/swp_entry will be
 	 Case          (A)      (B)       (C)     (D)
         Event
       Before (2)     0/ 1     0/ 1      1/ 1    1/ 1
          ===========================================
          (3)        +1/+1    +1/+1     +1/+1   +1/+1
          (4)          -       0/ 0       -     -1/ 0
          (5)         0/-1     0/ 0     -1/-1    0/ 0
          (6)          -       0/-1       -      0/-1
          ===========================================
       Result         1/ 1     1/ 1      1/ 1    1/ 1
       In any cases, charges to this page should be 1/ 1.
 	4.2 Swap-out.
 	At swap-out, typical state transition is below.
@@ -158,28 +74,20 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	    swp_entry's refcnt -= 1.
 	At (b), the page is marked as SwapCache and not uncharged.
 	At (d), the page is removed from SwapCache and a charge in page_cgroup
 	is moved to swap_cgroup.
 	Finally, at task exit,
 	(e) zap_pte() is called and swp_entry's refcnt -=1 -> 0.
 	Here, a charge in swap_cgroup disappears.
 5. Page Cache
   	Page Cache is charged at
 	- add_to_page_cache_locked().
 	uncharged at
 	- __remove_from_page_cache().
 	The logic is very clear. (About migration, see below)
 	Note: __remove_from_page_cache() is called by remove_from_page_cache()
 	and __remove_mapping().
 6. Shmem(tmpfs) Page Cache
-	Memcg's charge/uncharge have special handlers of shmem. The best way
+	The best way to understand shmem's page state transition is to read
-	to understand shmem's page state transition is to read mm/shmem.c.
+	mm/shmem.c.
 	But brief explanation of the behavior of memcg around shmem will be
 	helpful to understand the logic.
@@ -192,56 +100,10 @@ Under below explanation, we assume CONFIG_MEM_RES_CTRL_SWAP=y.
 	It's charged when...
 	- A new page is added to shmem's radix-tree.
 	- A swp page is read. (move a charge from swap_cgroup to page_cgroup)
 	It's uncharged when
 	- A page is removed from radix-tree and not SwapCache.
 	- When SwapCache is removed, a charge is moved to swap_cgroup.
 	- When swp_entry's refcnt goes down to 0, a charge in swap_cgroup
 	  disappears.
 7. Page Migration
   	One of the most complicated functions is page-migration-handler.
 	Memcg has 2 routines. Assume that we are migrating a page's contents
 	from OLDPAGE to NEWPAGE.
-	Usual migration logic is..
+	mem_cgroup_migrate()
 	(a) remove the page from LRU.
 	(b) allocate NEWPAGE (migration target)
 	(c) lock by lock_page().
 	(d) unmap all mappings.
 	(e-1) If necessary, replace entry in radix-tree.
 	(e-2) move contents of a page.
 	(f) map all mappings again.
 	(g) pushback the page to LRU.
 	(-) OLDPAGE will be freed.
 	Before (g), memcg should complete all necessary charge/uncharge to
 	NEWPAGE/OLDPAGE.
 	The point is....
 	- If OLDPAGE is anonymous, all charges will be dropped at (d) because
          try_to_unmap() drops all mapcount and the page will not be
 	  SwapCache.
 	- If OLDPAGE is SwapCache, charges will be kept at (g) because
 	  __delete_from_swap_cache() isn't called at (e-1)
 	- If OLDPAGE is page-cache, charges will be kept at (g) because
 	  remove_from_swap_cache() isn't called at (e-1)
 	memcg provides following hooks.
 	- mem_cgroup_prepare_migration(OLDPAGE)
 	  Called after (b) to account a charge (usage += PAGE_SIZE) against
 	  memcg which OLDPAGE belongs to.
        - mem_cgroup_end_migration(OLDPAGE, NEWPAGE)
 	  Called after (f) before (g).
 	  If OLDPAGE is used, commit OLDPAGE again. If OLDPAGE is already
 	  charged, a charge by prepare_migration() is automatically canceled.
 	  If NEWPAGE is used, commit NEWPAGE and uncharge OLDPAGE.
 	  But zap_pte() (by exit or munmap) can be called while migration,
 	  we have to check if OLDPAGE/NEWPAGE is a valid page after commit().
 8. LRU
        Each memcg has its own private LRU. Now, its handling is under global
--- a/Documentation/development-process/2.Process
+++ b/Documentation/development-process/2.Process
@@ -289,10 +289,6 @@ lists when they are assembled; they can be downloaded from:
 	http://www.kernel.org/pub/linux/kernel/next/
 Some information about linux-next has been gathered at:
 	http://linux.f-seidel.de/linux-next/pmwiki/
 Linux-next has become an integral part of the kernel development process;
 all patches merged during a given merge window should really have found
 their way into linux-next some time before the merge window opens.
--- a/Documentation/development-process/8.Conclusion
+++ b/Documentation/development-process/8.Conclusion
@@ -22,10 +22,6 @@ Beyond that, a valuable resource for kernel developers is:
 	http://kernelnewbies.org/
 Information about the linux-next tree gathers at:
 	http://linux.f-seidel.de/linux-next/pmwiki/
 And, of course, one should not forget http://kernel.org/, the definitive
 location for kernel release information.
--- a/Documentation/device-mapper/switch.txt
+++ b/Documentation/device-mapper/switch.txt
@@ -106,6 +106,11 @@ which paths.
    The path number in the range 0 ... (<num_paths> - 1).
    Expressed in hexadecimal (WITHOUT any prefix like 0x).
 R<n>,<m>
    This parameter allows repetitive patterns to be loaded quickly. <n> and <m>
    are hexadecimal numbers. The last <n> mappings are repeated in the next <m>
    slots.
 Status
 ======
@@ -124,3 +129,10 @@ Create a switch device with 64kB region size:
 Set mappings for the first 7 entries to point to devices switch0, switch1,
 switch2, switch0, switch1, switch2, switch1:
    dmsetup message switch 0 set_region_mappings 0:0 :1 :2 :0 :1 :2 :1
 Set repetitive mapping. This command:
    dmsetup message switch 0 set_region_mappings 1000:1 :2 R2,10
 is equivalent to:
    dmsetup message switch 0 set_region_mappings 1000:1 :2 :1 :2 :1 :2 :1 :2 \
 	:1 :2 :1 :2 :1 :2 :1 :2 :1 :2
--- a/Documentation/devicetree/bindings/arm/adapteva.txt
+++ b/Documentation/devicetree/bindings/arm/adapteva.txt
@@ -0,0 +1,7 @@
 Adapteva Platforms Device Tree Bindings
 ---------------------------------------
 Parallella board
 Required root node properties:
    - compatible = "adapteva,parallella";
--- a/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-sdram-edac.txt
@@ -0,0 +1,15 @@
 Altera SOCFPGA SDRAM Error Detection & Correction [EDAC]
 The EDAC accesses a range of registers in the SDRAM controller.
 Required properties:
 - compatible : should contain "altr,sdram-edac";
 - altr,sdr-syscon : phandle of the sdr module
 - interrupts : Should contain the SDRAM ECC IRQ in the
 	appropriate format for the IRQ controller.
 Example:
 	sdramedac {
 		compatible = "altr,sdram-edac";
 		altr,sdr-syscon = <&sdr>;
 		interrupts = <0 39 4>;
 	};
--- a/Documentation/devicetree/bindings/arm/amlogic.txt
+++ b/Documentation/devicetree/bindings/arm/amlogic.txt
@@ -0,0 +1,8 @@
 Amlogic MesonX device tree bindings
 -------------------------------------------
 Boards with the Amlogic Meson6 SoC shall have the following properties:
 Required root node property:
 compatible = "amlogic,meson6";
--- a/Documentation/devicetree/bindings/arm/arm-boards
+++ b/Documentation/devicetree/bindings/arm/arm-boards
@@ -86,3 +86,9 @@ Interrupt controllers:
 	compatible = "arm,versatile-sic";
 	interrupt-controller;
 	#interrupt-cells = <1>;
 Required nodes:
 - core-module: the root node to the Versatile platforms must have
  a core-module with regs and the compatible strings
  "arm,core-module-versatile", "syscon"
--- a/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
+++ b/Documentation/devicetree/bindings/arm/armada-380-mpcore-soc-ctrl.txt
@@ -0,0 +1,14 @@
 Marvell Armada 38x CA9 MPcore SoC Controller
 ============================================
 Required properties:
 - compatible: Should be "marvell,armada-380-mpcore-soc-ctrl".
 - reg: should be the register base and length as documented in the
  datasheet for the CA9 MPcore SoC Control registers
 mpcore-soc-ctrl@20d20 {
 	compatible = "marvell,armada-380-mpcore-soc-ctrl";
 	reg = <0x20d20 0x6c>;
 };
--- a/Documentation/devicetree/bindings/arm/atmel-at91.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-at91.txt
@@ -1,6 +1,43 @@
 Atmel AT91 device tree bindings.
 ================================
 Boards with a SoC of the Atmel AT91 or SMART family shall have the following
 properties:
 Required root node properties:
 compatible: must be one of:
 * "atmel,at91rm9200"
 * "atmel,at91sam9" for SoCs using an ARM926EJ-S core, shall be extended with
   the specific SoC family or compatible:
    o "atmel,at91sam9260"
    o "atmel,at91sam9261"
    o "atmel,at91sam9263"
    o "atmel,at91sam9x5" for the 5 series, shall be extended with the specific
      SoC compatible:
       - "atmel,at91sam9g15"
       - "atmel,at91sam9g25"
       - "atmel,at91sam9g35"
       - "atmel,at91sam9x25"
       - "atmel,at91sam9x35"
    o "atmel,at91sam9g20"
    o "atmel,at91sam9g45"
    o "atmel,at91sam9n12"
    o "atmel,at91sam9rl"
 * "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
   SoC family:
    o "atmel,sama5d3" shall be extended with the specific SoC compatible:
       - "atmel,sama5d31"
       - "atmel,sama5d33"
       - "atmel,sama5d34"
       - "atmel,sama5d35"
       - "atmel,sama5d36"
    o "atmel,sama5d4" shall be extended with the specific SoC compatible:
       - "atmel,sama5d41"
       - "atmel,sama5d42"
       - "atmel,sama5d43"
       - "atmel,sama5d44"
 PIT Timer required properties:
 - compatible: Should be "atmel,at91sam9260-pit"
 - reg: Should contain registers location and length
@@ -61,8 +98,8 @@ RAMC SDRAM/DDR Controller required properties:
 - compatible: Should be "atmel,at91rm9200-sdramc",
 			"atmel,at91sam9260-sdramc",
 			"atmel,at91sam9g45-ddramc",
 			"atmel,sama5d3-ddramc",
 - reg: Should contain registers location and length
  For at91sam9263 and at91sam9g45 you must specify 2 entries.
 Examples:
@@ -71,12 +108,6 @@ Examples:
 		reg = <0xffffe800 0x200>;
 	};
 	ramc0: ramc@ffffe400 {
 		compatible = "atmel,at91sam9g45-ddramc";
 		reg = <0xffffe400 0x200
 		       0xffffe600 0x200>;
 	};
 SHDWC Shutdown Controller
 required properties:
--- a/Documentation/devicetree/bindings/arm/atmel-pmc.txt
+++ b/Documentation/devicetree/bindings/arm/atmel-pmc.txt
@@ -1,7 +1,10 @@
 * Power Management Controller (PMC)
 Required properties:
- compatible: Should be "atmel,at91rm9200-pmc"
+- compatible: Should be "atmel,<chip>-pmc".
 	<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
 	at91sam9x5, sama5d3
 - reg: Should contain PMC registers location and length
 Examples:
--- a/Documentation/devicetree/bindings/arm/bcm/bcm63138.txt
+++ b/Documentation/devicetree/bindings/arm/bcm/bcm63138.txt
@@ -0,0 +1,9 @@
 Broadcom BCM63138 DSL System-on-a-Chip device tree bindings
 -----------------------------------------------------------
 Boards compatible with the BCM63138 DSL System-on-a-Chip should have the
 following properties:
 Required root node property:
 compatible: should be "brcm,bcm63138"
--- a/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method
+++ b/Documentation/devicetree/bindings/arm/bcm/brcm,bcm11351-cpu-method
@@ -0,0 +1,36 @@
 Broadcom Kona Family CPU Enable Method
 --------------------------------------
 This binding defines the enable method used for starting secondary
 CPUs in the following Broadcom SoCs:
  BCM11130, BCM11140, BCM11351, BCM28145, BCM28155, BCM21664
 The enable method is specified by defining the following required
 properties in the "cpus" device tree node:
  - enable-method = "brcm,bcm11351-cpu-method";
  - secondary-boot-reg = <...>;
 The secondary-boot-reg property is a u32 value that specifies the
 physical address of the register used to request the ROM holding pen
 code release a secondary CPU.  The value written to the register is
 formed by encoding the target CPU id into the low bits of the
 physical start address it should jump to.
 Example:
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		enable-method = "brcm,bcm11351-cpu-method";
 		secondary-boot-reg = <0x3500417c>;
 		cpu0: cpu@0 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <0>;
 		};
 		cpu1: cpu@1 {
 			device_type = "cpu";
 			compatible = "arm,cortex-a9";
 			reg = <1>;
 		};
 	};
--- a/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
+++ b/Documentation/devicetree/bindings/arm/brcm-brcmstb.txt
@@ -0,0 +1,95 @@
 ARM Broadcom STB platforms Device Tree Bindings
 -----------------------------------------------
 Boards with Broadcom Brahma15 ARM-based BCMxxxx (generally BCM7xxx variants)
 SoC shall have the following DT organization:
 Required root node properties:
    - compatible: "brcm,bcm<chip_id>", "brcm,brcmstb"
 example:
 / {
    #address-cells = <2>;
    #size-cells = <2>;
    model = "Broadcom STB (bcm7445)";
    compatible = "brcm,bcm7445", "brcm,brcmstb";
 Further, syscon nodes that map platform-specific registers used for general
 system control is required:
    - compatible: "brcm,bcm<chip_id>-sun-top-ctrl", "syscon"
    - compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
    - compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
 example:
    rdb {
        #address-cells = <1>;
        #size-cells = <1>;
        compatible = "simple-bus";
        ranges = <0 0x00 0xf0000000 0x1000000>;
        sun_top_ctrl: syscon@404000 {
            compatible = "brcm,bcm7445-sun-top-ctrl", "syscon";
            reg = <0x404000 0x51c>;
        };
        hif_cpubiuctrl: syscon@3e2400 {
            compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
            reg = <0x3e2400 0x5b4>;
        };
        hif_continuation: syscon@452000 {
            compatible = "brcm,bcm7445-hif-continuation", "syscon";
            reg = <0x452000 0x100>;
        };
    };
 Lastly, nodes that allow for support of SMP initialization and reboot are
 required:
 smpboot
 -------
 Required properties:
    - compatible
        The string "brcm,brcmstb-smpboot".
    - syscon-cpu
        A phandle / integer array property which lets the BSP know the location
        of certain CPU power-on registers.
        The layout of the property is as follows:
            o a phandle to the "hif_cpubiuctrl" syscon node
            o offset to the base CPU power zone register
            o offset to the base CPU reset register
    - syscon-cont
        A phandle pointing to the syscon node which describes the CPU boot
        continuation registers.
            o a phandle to the "hif_continuation" syscon node
 example:
    smpboot {
        compatible = "brcm,brcmstb-smpboot";
        syscon-cpu = <&hif_cpubiuctrl 0x88 0x178>;
        syscon-cont = <&hif_continuation>;
    };
 reboot
 -------
 Required properties
    - compatible
        The string property "brcm,brcmstb-reboot".
    - syscon
        A phandle / integer array that points to the syscon node which describes
        the general system reset registers.
            o a phandle to "sun_top_ctrl"
            o offset to the "reset source enable" register
            o offset to the "software master reset" register
 example:
    reboot {
        compatible = "brcm,brcmstb-reboot";
        syscon = <&sun_top_ctrl 0x304 0x308>;
    };
--- a/Documentation/devicetree/bindings/arm/cavium-thunder.txt
+++ b/Documentation/devicetree/bindings/arm/cavium-thunder.txt
@@ -0,0 +1,10 @@
 Cavium Thunder platform device tree bindings
 --------------------------------------------
 Boards with Cavium's Thunder SoC shall have following properties.
 Root Node
 ---------
 Required root node properties:
  - compatible = "cavium,thunder-88xx";
--- a/Documentation/devicetree/bindings/arm/ccn.txt
+++ b/Documentation/devicetree/bindings/arm/ccn.txt
@@ -0,0 +1,21 @@
 * ARM CCN (Cache Coherent Network)
 Required properties:
 - compatible: (standard compatible string) should be one of:
 	"arm,ccn-504"
 	"arm,ccn-508"
 - reg: (standard registers property) physical address and size
 	(16MB) of the configuration registers block
 - interrupts: (standard interrupt property) single interrupt
 	generated by the control block
 Example:
 	ccn@0x2000000000 {
 		compatible = "arm,ccn-504";
 		reg = <0x20 0x00000000 0 0x1000000>;
 		interrupts = <0 181 4>;
 	};
--- a/Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp
+++ b/Documentation/devicetree/bindings/arm/cpu-enable-method/marvell,berlin-smp
@@ -0,0 +1,41 @@
 ========================================================
 Secondary CPU enable-method "marvell,berlin-smp" binding
 ========================================================
 This document describes the "marvell,berlin-smp" method for enabling secondary
 CPUs. To apply to all CPUs, a single "marvell,berlin-smp" enable method should
 be defined in the "cpus" node.
 Enable method name:	"marvell,berlin-smp"
 Compatible machines:	"marvell,berlin2" and "marvell,berlin2q"
 Compatible CPUs:	"marvell,pj4b" and "arm,cortex-a9"
 Related properties:	(none)
 Note:
 This enable method needs valid nodes compatible with "arm,cortex-a9-scu" and
 "marvell,berlin-cpu-ctrl"[1].
 Example:
 	cpus {
 		#address-cells = <1>;
 		#size-cells = <0>;
 		enable-method = "marvell,berlin-smp";
 		cpu@0 {
 			compatible = "marvell,pj4b";
 			device_type = "cpu";
 			next-level-cache = <&l2>;
 			reg = <0>;
 		};
 		cpu@1 {
 			compatible = "marvell,pj4b";
 			device_type = "cpu";
 			next-level-cache = <&l2>;
 			reg = <1>;
 		};
 	};
 --
 [1] arm/marvell,berlin.txt
--- a/Documentation/devicetree/bindings/arm/cpus.txt
+++ b/Documentation/devicetree/bindings/arm/cpus.txt
@@ -152,7 +152,9 @@ nodes to be present and contain the properties described below.
 			    "arm,cortex-a7"
 			    "arm,cortex-a8"
 			    "arm,cortex-a9"
 			    "arm,cortex-a12"
 			    "arm,cortex-a15"
 			    "arm,cortex-a17"
 			    "arm,cortex-a53"
 			    "arm,cortex-a57"
 			    "arm,cortex-m0"
@@ -163,6 +165,8 @@ nodes to be present and contain the properties described below.
 			    "arm,cortex-r4"
 			    "arm,cortex-r5"
 			    "arm,cortex-r7"
 			    "brcm,brahma-b15"
 			    "cavium,thunder"
 			    "faraday,fa526"
 			    "intel,sa110"
 			    "intel,sa1100"
@@ -184,6 +188,7 @@ nodes to be present and contain the properties described below.
 			  can be one of:
 			    "allwinner,sun6i-a31"
 			    "arm,psci"
 			    "brcm,brahma-b15"
 			    "marvell,armada-375-smp"
 			    "marvell,armada-380-smp"
 			    "marvell,armada-xp-smp"
@@ -215,6 +220,12 @@ nodes to be present and contain the properties described below.
 		Value type: <phandle>
 		Definition: Specifies the ACC[2] node associated with this CPU.
 	- cpu-idle-states
 		Usage: Optional
 		Value type: <prop-encoded-array>
 		Definition:
 			# List of phandles to idle state nodes supported
 			  by this cpu [3].
 Example 1 (dual-cluster big.LITTLE system 32-bit):
@@ -411,3 +422,5 @@ cpus {
 --
 [1] arm/msm/qcom,saw2.txt
 [2] arm/msm/qcom,kpss-acc.txt
 [3] ARM Linux kernel documentation - idle states bindings
    Documentation/devicetree/bindings/arm/idle-states.txt
--- a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
+++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt
@@ -8,6 +8,8 @@ Required Properties:
    * samsung,exynos4210-pd - for exynos4210 type power domain.
 - reg: physical base address of the controller and length of memory mapped
    region.
 - #power-domain-cells: number of cells in power domain specifier;
    must be 0.
 Optional Properties:
 - clocks: List of clock handles. The parent clocks of the input clocks to the
@@ -29,6 +31,7 @@ Example:
 	lcd0: power-domain-lcd0 {
 		compatible = "samsung,exynos4210-pd";
 		reg = <0x10023C00 0x10>;
 		#power-domain-cells = <0>;
 	};
 	mfc_pd: power-domain@10044060 {
@@ -37,12 +40,8 @@ Example:
 		clocks = <&clock CLK_FIN_PLL>, <&clock CLK_MOUT_SW_ACLK333>,
 			<&clock CLK_MOUT_USER_ACLK333>;
 		clock-names = "oscclk", "pclk0", "clk0";
 		#power-domain-cells = <0>;
 	};
-Example of the node using power domain:
+See Documentation/devicetree/bindings/power/power_domain.txt for description
-
+of consumer-side bindings.
 	node {
 		/* ... */
 		samsung,power-domain = <&lcd0>;
 		/* ... */
 	};
--- a/Documentation/devicetree/bindings/arm/geniatech.txt
+++ b/Documentation/devicetree/bindings/arm/geniatech.txt
@@ -0,0 +1,5 @@
 Geniatech platforms device tree bindings
 -------------------------------------------
 Geniatech ATV1200
    - compatible = "geniatech,atv1200"
--- a/Documentation/devicetree/bindings/arm/gic-v3.txt
+++ b/Documentation/devicetree/bindings/arm/gic-v3.txt
@@ -0,0 +1,79 @@
 * ARM Generic Interrupt Controller, version 3
 AArch64 SMP cores are often associated with a GICv3, providing Private
 Peripheral Interrupts (PPI), Shared Peripheral Interrupts (SPI),
 Software Generated Interrupts (SGI), and Locality-specific Peripheral
 Interrupts (LPI).
 Main node required properties:
 - compatible : should at least contain  "arm,gic-v3".
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
  interrupt source. Must be a single cell with a value of at least 3.
  The 1st cell is the interrupt type; 0 for SPI interrupts, 1 for PPI
  interrupts. Other values are reserved for future use.
  The 2nd cell contains the interrupt number for the interrupt type.
  SPI interrupts are in the range [0-987]. PPI interrupts are in the
  range [0-15].
  The 3rd cell is the flags, encoded as follows:
 	bits[3:0] trigger type and level flags.
 		1 = edge triggered
 		4 = level triggered
  Cells 4 and beyond are reserved for future use. When the 1st cell
  has a value of 0 or 1, cells 4 and beyond act as padding, and may be
  ignored. It is recommended that padding cells have a value of 0.
 - reg : Specifies base physical address(s) and size of the GIC
  registers, in the following order:
  - GIC Distributor interface (GICD)
  - GIC Redistributors (GICR), one range per redistributor region
  - GIC CPU interface (GICC)
  - GIC Hypervisor interface (GICH)
  - GIC Virtual CPU interface (GICV)
  GICC, GICH and GICV are optional.
 - interrupts : Interrupt source of the VGIC maintenance interrupt.
 Optional
 - redistributor-stride : If using padding pages, specifies the stride
  of consecutive redistributors. Must be a multiple of 64kB.
 - #redistributor-regions: The number of independent contiguous regions
  occupied by the redistributors. Required if more than one such
  region is present.
 Examples:
 	gic: interrupt-controller@2cf00000 {
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		interrupt-controller;
 		reg = <0x0 0x2f000000 0 0x10000>,	// GICD
 		      <0x0 0x2f100000 0 0x200000>,	// GICR
 		      <0x0 0x2c000000 0 0x2000>,	// GICC
 		      <0x0 0x2c010000 0 0x2000>,	// GICH
 		      <0x0 0x2c020000 0 0x2000>;	// GICV
 		interrupts = <1 9 4>;
 	};
 	gic: interrupt-controller@2c010000 {
 		compatible = "arm,gic-v3";
 		#interrupt-cells = <3>;
 		interrupt-controller;
 		redistributor-stride = <0x0 0x40000>;	// 256kB stride
 		#redistributor-regions = <2>;
 		reg = <0x0 0x2c010000 0 0x10000>,	// GICD
 		      <0x0 0x2d000000 0 0x800000>,	// GICR 1: CPUs 0-31
 		      <0x0 0x2e000000 0 0x800000>;	// GICR 2: CPUs 32-63
 		      <0x0 0x2c040000 0 0x2000>,	// GICC
 		      <0x0 0x2c060000 0 0x2000>,	// GICH
 		      <0x0 0x2c080000 0 0x2000>;	// GICV
 		interrupts = <1 9 4>;
 	};
--- a/Documentation/devicetree/bindings/arm/gic.txt
+++ b/Documentation/devicetree/bindings/arm/gic.txt
@@ -16,6 +16,7 @@ Main node required properties:
 	"arm,cortex-a9-gic"
 	"arm,cortex-a7-gic"
 	"arm,arm11mp-gic"
 	"brcm,brahma-b15-gic"
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
  interrupt source.  The type shall be a <u32> and the value shall be 3.
--- a/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
+++ b/Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
@@ -5,6 +5,11 @@ Hi4511 Board
 Required root node properties:
 	- compatible = "hisilicon,hi3620-hi4511";
 HiP04 D01 Board
 Required root node properties:
 	- compatible = "hisilicon,hip04-d01";
 Hisilicon system controller
 Required properties:
@@ -31,6 +36,17 @@ Example:
 		reboot-offset = <0x4>;
 	};
 -----------------------------------------------------------------------
 Hisilicon CPU controller
 Required properties:
 - compatible : "hisilicon,cpuctrl"
 - reg : Register address and size
 The clock registers and power registers of secondary cores are defined
 in CPU controller, especially in HIX5HD2 SoC.
 -----------------------------------------------------------------------
 PCTRL: Peripheral misc control register
 Required Properties:
@@ -44,3 +60,21 @@ Example:
 		compatible = "hisilicon,pctrl";
 		reg = <0xfca09000 0x1000>;
 	};
 -----------------------------------------------------------------------
 Fabric:
 Required Properties:
 - compatible: "hisilicon,hip04-fabric";
 - reg: Address and size of Fabric
 -----------------------------------------------------------------------
 Bootwrapper boot method (software protocol on SMP):
 Required Properties:
 - compatible: "hisilicon,hip04-bootwrapper";
 - boot-method: Address and size of boot method.
  [0]: bootwrapper physical address
  [1]: bootwrapper size
  [2]: relocation physical address
  [3]: relocation size
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -0,0 +1,679 @@
 ==========================================
 ARM idle states binding description
 ==========================================
 ==========================================
 1 - Introduction
 ==========================================
 ARM systems contain HW capable of managing power consumption dynamically,
 where cores can be put in different low-power states (ranging from simple
 wfi to power gating) according to OS PM policies. The CPU states representing
 the range of dynamic idle states that a processor can enter at run-time, can be
 specified through device tree bindings representing the parameters required
 to enter/exit specific idle states on a given processor.
 According to the Server Base System Architecture document (SBSA, [3]), the
 power states an ARM CPU can be put into are identified by the following list:
 - Running
 - Idle_standby
 - Idle_retention
 - Sleep
 - Off
 The power states described in the SBSA document define the basic CPU states on
 top of which ARM platforms implement power management schemes that allow an OS
 PM implementation to put the processor in different idle states (which include
 states listed above; "off" state is not an idle state since it does not have
 wake-up capabilities, hence it is not considered in this document).
 Idle state parameters (eg entry latency) are platform specific and need to be
 characterized with bindings that provide the required information to OS PM
 code so that it can build the required tables and use them at runtime.
 The device tree binding definition for ARM idle states is the subject of this
 document.
 ===========================================
 2 - idle-states definitions
 ===========================================
 Idle states are characterized for a specific system through a set of
 timing and energy related properties, that underline the HW behaviour
 triggered upon idle states entry and exit.
 The following diagram depicts the CPU execution phases and related timing
 properties required to enter and exit an idle state:
 ..__[EXEC]__|__[PREP]__|__[ENTRY]__|__[IDLE]__|__[EXIT]__|__[EXEC]__..
 	    |          |           |          |          |
 	    |<------ entry ------->|
 	    |       latency        |
 					      |<- exit ->|
 					      |  latency |
 	    |<-------- min-residency -------->|
 		       |<-------  wakeup-latency ------->|
 		Diagram 1: CPU idle state execution phases
 EXEC:	Normal CPU execution.
 PREP:	Preparation phase before committing the hardware to idle mode
 	like cache flushing. This is abortable on pending wake-up
 	event conditions. The abort latency is assumed to be negligible
 	(i.e. less than the ENTRY + EXIT duration). If aborted, CPU
 	goes back to EXEC. This phase is optional. If not abortable,
 	this should be included in the ENTRY phase instead.
 ENTRY:	The hardware is committed to idle mode. This period must run
 	to completion up to IDLE before anything else can happen.
 IDLE:	This is the actual energy-saving idle period. This may last
 	between 0 and infinite time, until a wake-up event occurs.
 EXIT:	Period during which the CPU is brought back to operational
 	mode (EXEC).
 entry-latency: Worst case latency required to enter the idle state. The
 exit-latency may be guaranteed only after entry-latency has passed.
 min-residency: Minimum period, including preparation and entry, for a given
 idle state to be worthwhile energywise.
 wakeup-latency: Maximum delay between the signaling of a wake-up event and the
 CPU being able to execute normal code again. If not specified, this is assumed
 to be entry-latency + exit-latency.
 These timing parameters can be used by an OS in different circumstances.
 An idle CPU requires the expected min-residency time to select the most
 appropriate idle state based on the expected expiry time of the next IRQ
 (ie wake-up) that causes the CPU to return to the EXEC phase.
 An operating system scheduler may need to compute the shortest wake-up delay
 for CPUs in the system by detecting how long will it take to get a CPU out
 of an idle state, eg:
 wakeup-delay = exit-latency + max(entry-latency - (now - entry-timestamp), 0)
 In other words, the scheduler can make its scheduling decision by selecting
 (eg waking-up) the CPU with the shortest wake-up latency.
 The wake-up latency must take into account the entry latency if that period
 has not expired. The abortable nature of the PREP period can be ignored
 if it cannot be relied upon (e.g. the PREP deadline may occur much sooner than
 the worst case since it depends on the CPU operating conditions, ie caches
 state).
 An OS has to reliably probe the wakeup-latency since some devices can enforce
 latency constraints guarantees to work properly, so the OS has to detect the
 worst case wake-up latency it can incur if a CPU is allowed to enter an
 idle state, and possibly to prevent that to guarantee reliable device
 functioning.
 The min-residency time parameter deserves further explanation since it is
 expressed in time units but must factor in energy consumption coefficients.
 The energy consumption of a cpu when it enters a power state can be roughly
 characterised by the following graph:
               |
               |
               |
           e   |
           n   |                                      /---
           e   |                               /------
           r   |                        /------
           g   |                  /-----
           y   |           /------
               |       ----
               |      /|
               |     / |
               |    /  |
               |   /   |
               |  /    |
               | /     |
               |/      |
          -----|-------+----------------------------------
              0|       1                              time(ms)
 		Graph 1: Energy vs time example
 The graph is split in two parts delimited by time 1ms on the X-axis.
 The graph curve with X-axis values = { x | 0 < x < 1ms } has a steep slope
 and denotes the energy costs incurred whilst entering and leaving the idle
 state.
 The graph curve in the area delimited by X-axis values = {x | x > 1ms } has
 shallower slope and essentially represents the energy consumption of the idle
 state.
 min-residency is defined for a given idle state as the minimum expected
 residency time for a state (inclusive of preparation and entry) after
 which choosing that state become the most energy efficient option. A good
 way to visualise this, is by taking the same graph above and comparing some
 states energy consumptions plots.
 For sake of simplicity, let's consider a system with two idle states IDLE1,
 and IDLE2:
          |
          |
          |
          |                                                  /-- IDLE1
       e  |                                              /---
       n  |                                         /----
       e  |                                     /---
       r  |                                /-----/--------- IDLE2
       g  |                    /-------/---------
       y  |        ------------    /---|
          |       /           /----    |
          |      /        /---         |
          |     /    /----             |
          |    / /---                  |
          |   ---                      |
          |  /                         |
          | /                          |
          |/                           |                  time
       ---/----------------------------+------------------------
          |IDLE1-energy < IDLE2-energy | IDLE2-energy < IDLE1-energy
                                       |
                                IDLE2-min-residency
 		Graph 2: idle states min-residency example
 In graph 2 above, that takes into account idle states entry/exit energy
 costs, it is clear that if the idle state residency time (ie time till next
 wake-up IRQ) is less than IDLE2-min-residency, IDLE1 is the better idle state
 choice energywise.
 This is mainly down to the fact that IDLE1 entry/exit energy costs are lower
 than IDLE2.
 However, the lower power consumption (ie shallower energy curve slope) of idle
 state IDLE2 implies that after a suitable time, IDLE2 becomes more energy
 efficient.
 The time at which IDLE2 becomes more energy efficient than IDLE1 (and other
 shallower states in a system with multiple idle states) is defined
 IDLE2-min-residency and corresponds to the time when energy consumption of
 IDLE1 and IDLE2 states breaks even.
 The definitions provided in this section underpin the idle states
 properties specification that is the subject of the following sections.
 ===========================================
 3 - idle-states node
 ===========================================
 ARM processor idle states are defined within the idle-states node, which is
 a direct child of the cpus node [1] and provides a container where the
 processor idle states, defined as device tree nodes, are listed.
 - idle-states node
 	Usage: Optional - On ARM systems, it is a container of processor idle
 			  states nodes. If the system does not provide CPU
 			  power management capabilities or the processor just
 			  supports idle_standby an idle-states node is not
 			  required.
 	Description: idle-states node is a container node, where its
 		     subnodes describe the CPU idle states.
 	Node name must be "idle-states".
 	The idle-states node's parent node must be the cpus node.
 	The idle-states node's child nodes can be:
 	- one or more state nodes
 	Any other configuration is considered invalid.
 	An idle-states node defines the following properties:
 	- entry-method
 		Value type: <stringlist>
 		Usage and definition depend on ARM architecture version.
 			# On ARM v8 64-bit this property is required and must
 			  be one of:
 			   - "psci" (see bindings in [2])
 			# On ARM 32-bit systems this property is optional
 The nodes describing the idle states (state) can only be defined within the
 idle-states node, any other configuration is considered invalid and therefore
 must be ignored.
 ===========================================
 4 - state node
 ===========================================
 A state node represents an idle state description and must be defined as
 follows:
 - state node
 	Description: must be child of the idle-states node
 	The state node name shall follow standard device tree naming
 	rules ([5], 2.2.1 "Node names"), in particular state nodes which
 	are siblings within a single common parent must be given a unique name.
 	The idle state entered by executing the wfi instruction (idle_standby
 	SBSA,[3][4]) is considered standard on all ARM platforms and therefore
 	must not be listed.
 	With the definitions provided above, the following list represents
 	the valid properties for a state node:
 	- compatible
 		Usage: Required
 		Value type: <stringlist>
 		Definition: Must be "arm,idle-state".
 	- local-timer-stop
 		Usage: See definition
 		Value type: <none>
 		Definition: if present the CPU local timer control logic is
 			    lost on state entry, otherwise it is retained.
 	- entry-latency-us
 		Usage: Required
 		Value type: <prop-encoded-array>
 		Definition: u32 value representing worst case latency in
 			    microseconds required to enter the idle state.
 			    The exit-latency-us duration may be guaranteed
 			    only after entry-latency-us has passed.
 	- exit-latency-us
 		Usage: Required
 		Value type: <prop-encoded-array>
 		Definition: u32 value representing worst case latency
 			    in microseconds required to exit the idle state.
 	- min-residency-us
 		Usage: Required
 		Value type: <prop-encoded-array>
 		Definition: u32 value representing minimum residency duration
 			    in microseconds, inclusive of preparation and
 			    entry, for this idle state to be considered
 			    worthwhile energy wise (refer to section 2 of
 			    this document for a complete description).
 	- wakeup-latency-us:
 		Usage: Optional
 		Value type: <prop-encoded-array>
 		Definition: u32 value representing maximum delay between the
 			    signaling of a wake-up event and the CPU being
 			    able to execute normal code again. If omitted,
 			    this is assumed to be equal to:
 				entry-latency-us + exit-latency-us
 			    It is important to supply this value on systems
 			    where the duration of PREP phase (see diagram 1,
 			    section 2) is non-neglibigle.
 			    In such systems entry-latency-us + exit-latency-us
 			    will exceed wakeup-latency-us by this duration.
 	In addition to the properties listed above, a state node may require
 	additional properties specifics to the entry-method defined in the
 	idle-states node, please refer to the entry-method bindings
 	documentation for properties definitions.
 ===========================================
 4 - Examples
 ===========================================
 Example 1 (ARM 64-bit, 16-cpu system, PSCI enable-method):
 cpus {
 	#size-cells = <0>;
 	#address-cells = <2>;
 	CPU0: cpu@0 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x0>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU1: cpu@1 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x1>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU2: cpu@100 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x100>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU3: cpu@101 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x101>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU4: cpu@10000 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x10000>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU5: cpu@10001 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x10001>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU6: cpu@10100 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x10100>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU7: cpu@10101 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a57";
 		reg = <0x0 0x10101>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0
 				   &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU8: cpu@100000000 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x0>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU9: cpu@100000001 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x1>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU10: cpu@100000100 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x100>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU11: cpu@100000101 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x101>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU12: cpu@100010000 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x10000>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU13: cpu@100010001 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x10001>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU14: cpu@100010100 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x10100>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	CPU15: cpu@100010101 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a53";
 		reg = <0x1 0x10101>;
 		enable-method = "psci";
 		cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0
 				   &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>;
 	};
 	idle-states {
 		entry-method = "arm,psci";
 		CPU_RETENTION_0_0: cpu-retention-0-0 {
 			compatible = "arm,idle-state";
 			arm,psci-suspend-param = <0x0010000>;
 			entry-latency-us = <20>;
 			exit-latency-us = <40>;
 			min-residency-us = <80>;
 		};
 		CLUSTER_RETENTION_0: cluster-retention-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			arm,psci-suspend-param = <0x1010000>;
 			entry-latency-us = <50>;
 			exit-latency-us = <100>;
 			min-residency-us = <250>;
 			wakeup-latency-us = <130>;
 		};
 		CPU_SLEEP_0_0: cpu-sleep-0-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			arm,psci-suspend-param = <0x0010000>;
 			entry-latency-us = <250>;
 			exit-latency-us = <500>;
 			min-residency-us = <950>;
 		};
 		CLUSTER_SLEEP_0: cluster-sleep-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			arm,psci-suspend-param = <0x1010000>;
 			entry-latency-us = <600>;
 			exit-latency-us = <1100>;
 			min-residency-us = <2700>;
 			wakeup-latency-us = <1500>;
 		};
 		CPU_RETENTION_1_0: cpu-retention-1-0 {
 			compatible = "arm,idle-state";
 			arm,psci-suspend-param = <0x0010000>;
 			entry-latency-us = <20>;
 			exit-latency-us = <40>;
 			min-residency-us = <90>;
 		};
 		CLUSTER_RETENTION_1: cluster-retention-1 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			arm,psci-suspend-param = <0x1010000>;
 			entry-latency-us = <50>;
 			exit-latency-us = <100>;
 			min-residency-us = <270>;
 			wakeup-latency-us = <100>;
 		};
 		CPU_SLEEP_1_0: cpu-sleep-1-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			arm,psci-suspend-param = <0x0010000>;
 			entry-latency-us = <70>;
 			exit-latency-us = <100>;
 			min-residency-us = <300>;
 			wakeup-latency-us = <150>;
 		};
 		CLUSTER_SLEEP_1: cluster-sleep-1 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			arm,psci-suspend-param = <0x1010000>;
 			entry-latency-us = <500>;
 			exit-latency-us = <1200>;
 			min-residency-us = <3500>;
 			wakeup-latency-us = <1300>;
 		};
 	};
 };
 Example 2 (ARM 32-bit, 8-cpu system, two clusters):
 cpus {
 	#size-cells = <0>;
 	#address-cells = <1>;
 	CPU0: cpu@0 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a15";
 		reg = <0x0>;
 		cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU1: cpu@1 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a15";
 		reg = <0x1>;
 		cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU2: cpu@2 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a15";
 		reg = <0x2>;
 		cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU3: cpu@3 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a15";
 		reg = <0x3>;
 		cpu-idle-states = <&CPU_SLEEP_0_0 &CLUSTER_SLEEP_0>;
 	};
 	CPU4: cpu@100 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a7";
 		reg = <0x100>;
 		cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
 	};
 	CPU5: cpu@101 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a7";
 		reg = <0x101>;
 		cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
 	};
 	CPU6: cpu@102 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a7";
 		reg = <0x102>;
 		cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
 	};
 	CPU7: cpu@103 {
 		device_type = "cpu";
 		compatible = "arm,cortex-a7";
 		reg = <0x103>;
 		cpu-idle-states = <&CPU_SLEEP_1_0 &CLUSTER_SLEEP_1>;
 	};
 	idle-states {
 		CPU_SLEEP_0_0: cpu-sleep-0-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			entry-latency-us = <200>;
 			exit-latency-us = <100>;
 			min-residency-us = <400>;
 			wakeup-latency-us = <250>;
 		};
 		CLUSTER_SLEEP_0: cluster-sleep-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			entry-latency-us = <500>;
 			exit-latency-us = <1500>;
 			min-residency-us = <2500>;
 			wakeup-latency-us = <1700>;
 		};
 		CPU_SLEEP_1_0: cpu-sleep-1-0 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			entry-latency-us = <300>;
 			exit-latency-us = <500>;
 			min-residency-us = <900>;
 			wakeup-latency-us = <600>;
 		};
 		CLUSTER_SLEEP_1: cluster-sleep-1 {
 			compatible = "arm,idle-state";
 			local-timer-stop;
 			entry-latency-us = <800>;
 			exit-latency-us = <2000>;
 			min-residency-us = <6500>;
 			wakeup-latency-us = <2300>;
 		};
 	};
 };
 ===========================================
 5 - References
 ===========================================
 [1] ARM Linux Kernel documentation - CPUs bindings
    Documentation/devicetree/bindings/arm/cpus.txt
 [2] ARM Linux Kernel documentation - PSCI bindings
    Documentation/devicetree/bindings/arm/psci.txt
 [3] ARM Server Base System Architecture (SBSA)
    http://infocenter.arm.com/help/index.jsp
 [4] ARM Architecture Reference Manuals
    http://infocenter.arm.com/help/index.jsp
 [5] ePAPR standard
    https://www.power.org/documentation/epapr-version-1-1/
--- a/Documentation/devicetree/bindings/arm/l2cc.txt
+++ b/Documentation/devicetree/bindings/arm/l2cc.txt
@@ -2,6 +2,10 @@
 ARM cores often have a separate level 2 cache controller. There are various
 implementations of the L2 cache controller with compatible programming models.
 Some of the properties that are just prefixed "cache-*" are taken from section
 3.7.3 of the ePAPR v1.1 specification which can be found at:
 https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf
 The ARM L2 cache representation in the device tree should be done as follows:
 Required properties:
@@ -44,6 +48,12 @@ Optional properties:
  I/O coherent mode. Valid only when the arm,pl310-cache compatible
  string is used.
 - interrupts : 1 combined interrupt.
 - cache-size : specifies the size in bytes of the cache
 - cache-sets : specifies the number of associativity sets of the cache
 - cache-block-size : specifies the size in bytes of a cache block
 - cache-line-size : specifies the size in bytes of a line in the cache,
  if this is not specified, the line size is assumed to be equal to the
  cache block size
 - cache-id-part: cache id part number to be used if it is not present
  on hardware
 - wt-override: If present then L2 is forced to Write through mode
--- a/Documentation/devicetree/bindings/arm/marvell,berlin.txt
+++ b/Documentation/devicetree/bindings/arm/marvell,berlin.txt
@@ -24,6 +24,22 @@ SoC and board used. Currently known SoC compatibles are:
 	...
 }
 * Marvell Berlin CPU control bindings
 CPU control register allows various operations on CPUs, like resetting them
 independently.
 Required properties:
 - compatible: should be "marvell,berlin-cpu-ctrl"
 - reg: address and length of the register set
 Example:
 cpu-ctrl@f7dd0000 {
 	compatible = "marvell,berlin-cpu-ctrl";
 	reg = <0xf7dd0000 0x10000>;
 };
 * Marvell Berlin2 chip control binding
 Marvell Berlin SoCs have a chip control register set providing several
--- a/Documentation/devicetree/bindings/arm/mediatek.txt
+++ b/Documentation/devicetree/bindings/arm/mediatek.txt
@@ -0,0 +1,14 @@
 Mediatek MT6589 Platforms Device Tree Bindings
 Boards with a SoC of the Mediatek MT6589 shall have the following property:
 Required root node property:
 compatible: must contain "mediatek,mt6589"
 Supported boards:
 - bq Aquaris5 smart phone:
    Required root node properties:
      - compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
--- a/Documentation/devicetree/bindings/arm/omap/mpu.txt
+++ b/Documentation/devicetree/bindings/arm/omap/mpu.txt
@@ -10,6 +10,9 @@ Required properties:
 	       Should be "ti,omap5-mpu" for OMAP5
 - ti,hwmods: "mpu"
 Optional properties:
 - sram:	Phandle to the ocmcram node
 Examples:
 - For an OMAP5 SMP system:
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -85,6 +85,18 @@ SoCs:
 - DRA722
  compatible = "ti,dra722", "ti,dra72", "ti,dra7"
 - AM5728
  compatible = "ti,am5728", "ti,dra742", "ti,dra74", "ti,dra7"
 - AM5726
  compatible = "ti,am5726", "ti,dra742", "ti,dra74", "ti,dra7"
 - AM5718
  compatible = "ti,am5718", "ti,dra722", "ti,dra72", "ti,dra7"
 - AM5716
  compatible = "ti,am5716", "ti,dra722", "ti,dra72", "ti,dra7"
 - AM4372
  compatible = "ti,am4372", "ti,am43"
@@ -129,6 +141,9 @@ Boards:
 - AM437x GP EVM
  compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
 - AM437x SK EVM: AM437x StarterKit Evaluation Module
  compatible = "ti,am437x-sk-evm", "ti,am4372", "ti,am43"
 - DRA742 EVM:  Software Development Board for DRA742
  compatible = "ti,dra7-evm", "ti,dra742", "ti,dra74", "ti,dra7"
--- a/Documentation/devicetree/bindings/arm/omap/prcm.txt
+++ b/Documentation/devicetree/bindings/arm/omap/prcm.txt
@@ -0,0 +1,65 @@
 OMAP PRCM bindings
 Power Reset and Clock Manager lists the device clocks and clockdomains under
 a DT hierarchy. Each TI SoC can have multiple PRCM entities listed for it,
 each describing one module and the clock hierarchy under it. see [1] for
 documentation about the individual clock/clockdomain nodes.
 [1] Documentation/devicetree/bindings/clock/ti/*
 Required properties:
 - compatible:	Must be one of:
 		"ti,am3-prcm"
 		"ti,am3-scrm"
 		"ti,am4-prcm"
 		"ti,am4-scrm"
 		"ti,omap2-prcm"
 		"ti,omap2-scrm"
 		"ti,omap3-prm"
 		"ti,omap3-cm"
 		"ti,omap3-scrm"
 		"ti,omap4-cm1"
 		"ti,omap4-prm"
 		"ti,omap4-cm2"
 		"ti,omap4-scrm"
 		"ti,omap5-prm"
 		"ti,omap5-cm-core-aon"
 		"ti,omap5-scrm"
 		"ti,omap5-cm-core"
 		"ti,dra7-prm"
 		"ti,dra7-cm-core-aon"
 		"ti,dra7-cm-core"
 - reg:		Contains PRCM module register address range
 		(base address and length)
 - clocks:	clocks for this module
 - clockdomains:	clockdomains for this module
 Example:
 cm: cm@48004000 {
 	compatible = "ti,omap3-cm";
 	reg = <0x48004000 0x4000>;
 	cm_clocks: clocks {
 		#address-cells = <1>;
 		#size-cells = <0>;
 	};
 	cm_clockdomains: clockdomains {
 	};
 }
 &cm_clocks {
 	omap2_32k_fck: omap_32k_fck {
 		#clock-cells = <0>;
 		compatible = "fixed-clock";
 		clock-frequency = <32768>;
 	};
 };
 &cm_clockdomains {
 	core_l3_clkdm: core_l3_clkdm {
 		compatible = "ti,clockdomain";
 		clocks = <&sdrc_ick>;
 	};
 };
--- a/Documentation/devicetree/bindings/arm/psci.txt
+++ b/Documentation/devicetree/bindings/arm/psci.txt
@@ -50,6 +50,16 @@ Main node optional properties:
 - migrate       : Function ID for MIGRATE operation
 Device tree nodes that require usage of PSCI CPU_SUSPEND function (ie idle
 state nodes, as per bindings in [1]) must specify the following properties:
 - arm,psci-suspend-param
 		Usage: Required for state nodes[1] if the corresponding
                       idle-states node entry-method property is set
                       to "psci".
 		Value type: <u32>
 		Definition: power_state parameter to pass to the PSCI
 			    suspend call.
 Example:
@@ -64,7 +74,6 @@ Case 1: PSCI v0.1 only.
 		migrate		= <0x95c10003>;
 	};
 Case 2: PSCI v0.2 only
 	psci {
@@ -88,3 +97,6 @@ Case 3: PSCI v0.2 and PSCI v0.1.
 		...
 	};
 [1] Kernel documentation - ARM idle states bindings
    Documentation/devicetree/bindings/arm/idle-states.txt
--- a/Show More
+++ b/Show More