47 files changed, 1205 insertions, 56 deletions
diff --git a/Documentation/ABI/testing/sysfs-block b/Documentation/ABI/testing/sysfs-block
index c1eb41cb9876..279da08f7541 100644
--- a/Documentation/ABI/testing/sysfs-block
+++ b/Documentation/ABI/testing/sysfs-block
@@ -206,3 +206,17 @@ Description:
                when a discarded area is read the discard_zeroes_data
                parameter will be set to one. Otherwise it will be 0 and
                the result of reading a discarded area is undefined.
+What:           /sys/block/<disk>/queue/write_same_max_bytes
+Date:           January 2012
+Contact:        Martin K. Petersen <martin.petersen@oracle.com>
+Description:
+                Some devices support a write same operation in which a
+                single data block can be written to a range of several
+                contiguous blocks on storage. This can be used to wipe
+                areas on disk or to initialize drives in a RAID
+                configuration. write_same_max_bytes indicates how many
+                bytes can be written in a single write same command. If
+                write_same_max_bytes is 0, write same is not supported
+                by the device.
diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml
index c6ae4c9d0e0c..4fdf6b562d1c 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2582,6 +2582,10 @@ ioctls.</para>
        <listitem>
          <para>Support for frequency band enumeration: &VIDIOC-ENUM-FREQ-BANDS; ioctl.</para>
        </listitem>
+        <listitem>
+          <para>Vendor and device specific media bus pixel formats.
+            <xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
+        </listitem>
      </itemizedlist>
    </section>
diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml
index 272a5f718509..7fe5be1d3bbb 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -1586,7 +1586,6 @@ frame counter of the frame that is currently displayed (decoded). This value is
 the decoder is started.</entry>
              </row>
              <row><entry></entry></row>
              <row>
                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_DECODER_SLICE_INTERFACE</constant>&nbsp;</entry>
@@ -2270,6 +2269,14 @@ Applicable to the MPEG1, MPEG2, MPEG4 encoders.</entry>
              </row>
              <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-vbv-delay">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_VBV_DELAY</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row><row><entry spanname="descr">Sets the initial delay in milliseconds for
+VBV buffer control.</entry>
+              </row>
+              <row><entry></entry></row>
              <row>
                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_CPB_SIZE</constant>&nbsp;</entry>
                <entry>integer</entry>
@@ -2334,6 +2341,265 @@ Applicable to the MPEG4 decoder.</entry>
              </row><row><entry spanname="descr">vop_time_increment value for MPEG4. Applicable to the MPEG4 encoder.</entry>
              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FRAME_PACKING</constant>&nbsp;</entry>
+                <entry>boolean</entry>
+              </row>
+              <row><entry spanname="descr">Enable generation of frame packing supplemental enhancement information in the encoded bitstream.
+The frame packing SEI message contains the arrangement of L and R planes for 3D viewing. Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_CURRENT_FRAME_0</constant>&nbsp;</entry>
+                <entry>boolean</entry>
+              </row>
+              <row><entry spanname="descr">Sets current frame as frame0 in frame packing SEI.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-h264-sei-fp-arrangement-type">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE</constant>&nbsp;</entry>
+                <entry>enum&nbsp;v4l2_mpeg_video_h264_sei_fp_arrangement_type</entry>
+              </row>
+              <row><entry spanname="descr">Frame packing arrangement type for H264 SEI.
+Applicable to the H264 encoder.
+Possible values are:</entry>
+              </row>
+              <row>
+                <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_CHEKERBOARD</constant>&nbsp;</entry>
+                      <entry>Pixels are alternatively from L and R.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_COLUMN</constant>&nbsp;</entry>
+                      <entry>L and R are interlaced by column.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_ROW</constant>&nbsp;</entry>
+                      <entry>L and R are interlaced by row.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_SIDE_BY_SIDE</constant>&nbsp;</entry>
+                      <entry>L is on the left, R on the right.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TOP_BOTTOM</constant>&nbsp;</entry>
+                      <entry>L is on top, R on bottom.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_SEI_FP_ARRANGEMENT_TYPE_TEMPORAL</constant>&nbsp;</entry>
+                      <entry>One view per frame.</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO</constant>&nbsp;</entry>
+                <entry>boolean</entry>
+              </row>
+              <row><entry spanname="descr">Enables flexible macroblock ordering in the encoded bitstream. It is a technique
+used for restructuring the ordering of macroblocks in pictures. Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-h264-fmo-map-type">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_MAP_TYPE</constant>&nbsp;</entry>
+                <entry>enum&nbsp;v4l2_mpeg_video_h264_fmo_map_type</entry>
+              </row>
+              <row><entry spanname="descr">When using FMO, the map type divides the image in different scan patterns of macroblocks.
+Applicable to the H264 encoder.
+Possible values are:</entry>
+              </row>
+              <row>
+                <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_INTERLEAVED_SLICES</constant>&nbsp;</entry>
+                      <entry>Slices are interleaved one after other with macroblocks in run length order.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_SCATTERED_SLICES</constant>&nbsp;</entry>
+                      <entry>Scatters the macroblocks based on a mathematical function known to both encoder and decoder.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_FOREGROUND_WITH_LEFT_OVER</constant>&nbsp;</entry>
+                      <entry>Macroblocks arranged in rectangular areas or regions of interest.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_BOX_OUT</constant>&nbsp;</entry>
+                      <entry>Slice groups grow in a cyclic way from centre to outwards.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_RASTER_SCAN</constant>&nbsp;</entry>
+                      <entry>Slice groups grow in raster scan pattern from left to right.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_WIPE_SCAN</constant>&nbsp;</entry>
+                      <entry>Slice groups grow in wipe scan pattern from top to bottom.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_MAP_TYPE_EXPLICIT</constant>&nbsp;</entry>
+                      <entry>User defined map type.</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_SLICE_GROUP</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row>
+              <row><entry spanname="descr">Number of slice groups in FMO.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-h264-fmo-change-direction">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_DIRECTION</constant>&nbsp;</entry>
+                <entry>enum&nbsp;v4l2_mpeg_video_h264_fmo_change_dir</entry>
+              </row>
+              <row><entry spanname="descr">Specifies a direction of the slice group change for raster and wipe maps.
+Applicable to the H264 encoder.
+Possible values are:</entry>
+              </row>
+              <row>
+                <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_RIGHT</constant>&nbsp;</entry>
+                      <entry>Raster scan or wipe right.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_FMO_CHANGE_DIR_LEFT</constant>&nbsp;</entry>
+                      <entry>Reverse raster scan or wipe left.</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_CHANGE_RATE</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row>
+              <row><entry spanname="descr">Specifies the size of the first slice group for raster and wipe map.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_FMO_RUN_LENGTH</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row>
+              <row><entry spanname="descr">Specifies the number of consecutive macroblocks for the interleaved map.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO</constant>&nbsp;</entry>
+                <entry>boolean</entry>
+              </row>
+              <row><entry spanname="descr">Enables arbitrary slice ordering in encoded bitstream.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_ASO_SLICE_ORDER</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row><row><entry spanname="descr">Specifies the slice order in ASO. Applicable to the H264 encoder.
+The supplied 32-bit integer is interpreted as follows (bit
+0 = least significant bit):</entry>
+              </row>
+              <row>
+                <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry>Bit 0:15</entry>
+                      <entry>Slice ID</entry>
+                    </row>
+                    <row>
+                      <entry>Bit 16:32</entry>
+                      <entry>Slice position or order</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING</constant>&nbsp;</entry>
+                <entry>boolean</entry>
+              </row>
+              <row><entry spanname="descr">Enables H264 hierarchical coding.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row id="v4l2-mpeg-video-h264-hierarchical-coding-type">
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_TYPE</constant>&nbsp;</entry>
+                <entry>enum&nbsp;v4l2_mpeg_video_h264_hierarchical_coding_type</entry>
+              </row>
+              <row><entry spanname="descr">Specifies the hierarchical coding type.
+Applicable to the H264 encoder.
+Possible values are:</entry>
+              </row>
+              <row>
+                <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_B</constant>&nbsp;</entry>
+                      <entry>Hierarchical B coding.</entry>
+                    </row>
+                    <row>
+                      <entry><constant>V4L2_MPEG_VIDEO_H264_HIERARCHICAL_CODING_P</constant>&nbsp;</entry>
+                      <entry>Hierarchical P coding.</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row>
+              <row><entry spanname="descr">Specifies the number of hierarchical coding layers.
+Applicable to the H264 encoder.</entry>
+              </row>
+              <row><entry></entry></row>
+              <row>
+                <entry spanname="id"><constant>V4L2_CID_MPEG_VIDEO_H264_HIERARCHICAL_CODING_LAYER_QP</constant>&nbsp;</entry>
+                <entry>integer</entry>
+              </row><row><entry spanname="descr">Specifies a user defined QP for each layer. Applicable to the H264 encoder.
+The supplied 32-bit integer is interpreted as follows (bit
+0 = least significant bit):</entry>
+              </row>
+              <row>
+                <entrytbl spanname="descr" cols="2">
+                  <tbody valign="top">
+                    <row>
+                      <entry>Bit 0:15</entry>
+                      <entry>QP value</entry>
+                    </row>
+                    <row>
+                      <entry>Bit 16:32</entry>
+                      <entry>Layer number</entry>
+                    </row>
+                  </tbody>
+                </entrytbl>
+              </row>
            </tbody>
          </tgroup>
        </table>
@@ -4267,6 +4533,16 @@ interface and may change in the future.</para>
            pixels / second.
            </entry>
          </row>
+          <row>
+            <entry spanname="id"><constant>V4L2_CID_TEST_PATTERN</constant></entry>
+            <entry>menu</entry>
+          </row>
+          <row id="v4l2-test-pattern">
+            <entry spanname="descr"> Some capture/display/sensor devices have
+            the capability to generate test pattern images. These hardware
+            specific test patterns can be used to test if a device is working
+            properly.</entry>
+          </row>
          <row><entry></entry></row>
        </tbody>
      </tgroup>
diff --git a/Documentation/DocBook/media/v4l/io.xml b/Documentation/DocBook/media/v4l/io.xml
index 97f785add841..b5d1cbdc558b 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -677,8 +677,10 @@ memory, set by the application. See <xref linkend="userp" /> for details.
            <entry><structfield>length</structfield></entry>
            <entry></entry>
            <entry>Size of the buffer (not the payload) in bytes for the
-            single-planar API. For the multi-planar API should contain the
+            single-planar API. For the multi-planar API the application sets
-            number of elements in the <structfield>planes</structfield> array.
+            this to the number of elements in the <structfield>planes</structfield>
+            array. The driver will fill in the actual number of valid elements in
+            that array.
            </entry>
          </row>
          <row>
diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
index 5274c24d11e0..a990b34d911a 100644
--- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
@@ -1,11 +1,13 @@
-    <refentry id="V4L2-PIX-FMT-NV12M">
+    <refentry>
      <refmeta>
-        <refentrytitle>V4L2_PIX_FMT_NV12M ('NM12')</refentrytitle>
+        <refentrytitle>V4L2_PIX_FMT_NV12M ('NM12'), V4L2_PIX_FMT_NV21M ('NM21'), V4L2_PIX_FMT_NV12MT_16X16</refentrytitle>
        &manvol;
      </refmeta>
      <refnamediv>
-        <refname> <constant>V4L2_PIX_FMT_NV12M</constant></refname>
+        <refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
-        <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> with planes
+        <refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
+        <refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
+        <refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
          non contiguous in memory. </refpurpose>
      </refnamediv>
      <refsect1>
@@ -22,7 +24,12 @@ The CbCr plane is the same width, in bytes, as the Y plane (and of the image),
 but is half as tall in pixels. Each CbCr pair belongs to four pixels. For example,
 Cb<subscript>0</subscript>/Cr<subscript>0</subscript> belongs to
 Y'<subscript>00</subscript>, Y'<subscript>01</subscript>,
-Y'<subscript>10</subscript>, Y'<subscript>11</subscript>. </para>
+Y'<subscript>10</subscript>, Y'<subscript>11</subscript>.
+<constant>V4L2_PIX_FMT_NV12MT_16X16</constant> is the tiled version of
+<constant>V4L2_PIX_FMT_NV12M</constant> with 16x16 macroblock tiles. Here pixels
+are arranged in 16x16 2D tiles and tiles are arranged in linear order in memory.
+<constant>V4L2_PIX_FMT_NV21M</constant> is the same as <constant>V4L2_PIX_FMT_NV12M</constant>
+except the Cb and Cr bytes are swapped, the CrCb plane starts with a Cr byte.</para>
        <para><constant>V4L2_PIX_FMT_NV12M</constant> is intended to be
 used only in drivers and applications that support the multi-planar API,
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml b/Documentation/DocBook/media/v4l/pixfmt.xml
index 1ddbfabe3195..bf94f417592c 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -758,6 +758,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
                <entry>'AVC1'</entry>
                <entry>H264 video elementary stream without start codes.</entry>
          </row>
+          <row id="V4L2-PIX-FMT-H264-MVC">
+                <entry><constant>V4L2_PIX_FMT_H264_MVC</constant></entry>
+                <entry>'MVC'</entry>
+                <entry>H264 MVC video elementary stream.</entry>
+          </row>
          <row id="V4L2-PIX-FMT-H263">
                <entry><constant>V4L2_PIX_FMT_H263</constant></entry>
                <entry>'H263'</entry>
@@ -793,6 +798,11 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
                <entry>'VC1L'</entry>
                <entry>VC1, SMPTE 421M Annex L compliant stream.</entry>
          </row>
+          <row id="V4L2-PIX-FMT-VP8">
+                <entry><constant>V4L2_PIX_FMT_VP8</constant></entry>
+                <entry>'VP8'</entry>
+                <entry>VP8 video elementary stream.</entry>
+          </row>
        </tbody>
      </tgroup>
    </table>
@@ -996,6 +1006,34 @@ the other bits are set to 0.</entry>
            <entry>Old 6-bit greyscale format. Only the most significant 6 bits of each byte are used,
 the other bits are set to 0.</entry>
          </row>
+          <row id="V4L2-PIX-FMT-S5C-UYVY-JPG">
+            <entry><constant>V4L2_PIX_FMT_S5C_UYVY_JPG</constant></entry>
+            <entry>'S5CI'</entry>
+            <entry>Two-planar format used by Samsung S5C73MX cameras. The
+first plane contains interleaved JPEG and UYVY image data, followed by meta data
+in form of an array of offsets to the UYVY data blocks. The actual pointer array
+follows immediately the interleaved JPEG/UYVY data, the number of entries in
+this array equals the height of the UYVY image. Each entry is a 4-byte unsigned
+integer in big endian order and it's an offset to a single pixel line of the
+UYVY image. The first plane can start either with JPEG or UYVY data chunk. The
+size of a single UYVY block equals the UYVY image's width multiplied by 2. The
+size of a JPEG chunk depends on the image and can vary with each line.
+<para>The second plane, at an offset of 4084 bytes, contains a 4-byte offset to
+the pointer array in the first plane. This offset is followed by a 4-byte value
+indicating size of the pointer array. All numbers in the second plane are also
+in big endian order. Remaining data in the second plane is undefined. The
+information in the second plane allows to easily find location of the pointer
+array, which can be different for each frame. The size of the pointer array is
+constant for given UYVY image height.</para>
+<para>In order to extract UYVY and JPEG frames an application can initially set
+a data pointer to the start of first plane and then add an offset from the first
+entry of the pointers table. Such a pointer indicates start of an UYVY image
+pixel line. Whole UYVY line can be copied to a separate buffer. These steps
+should be repeated for each line, i.e. the number of entries in the pointer
+array. Anything what's in between the UYVY lines is JPEG data and should be
+concatenated to form the JPEG stream. </para>
+</entry>
+          </row>
        </tbody>
      </tgroup>
    </table>
diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml
index 49c532ebbbbe..a0a936455fae 100644
--- a/Documentation/DocBook/media/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/media/v4l/subdev-formats.xml
@@ -2565,5 +2565,49 @@
        </tgroup>
      </table>
    </section>
+    <section id="v4l2-mbus-vendor-spec-fmts">
+      <title>Vendor and Device Specific Formats</title>
+      <note>
+        <title>Experimental</title>
+        <para>This is an <link linkend="experimental">experimental</link>
+interface and may change in the future.</para>
+      </note>
+      <para>This section lists complex data formats that are either vendor or
+        device specific.
+      </para>
+      <para>The following table lists the existing vendor and device specific
+        formats.</para>
+      <table pgwide="0" frame="none" id="v4l2-mbus-pixelcode-vendor-specific">
+        <title>Vendor and device specific formats</title>
+        <tgroup cols="3">
+          <colspec colname="id" align="left" />
+          <colspec colname="code" align="left"/>
+          <colspec colname="remarks" align="left"/>
+          <thead>
+            <row>
+              <entry>Identifier</entry>
+              <entry>Code</entry>
+              <entry>Comments</entry>
+            </row>
+          </thead>
+          <tbody valign="top">
+            <row id="V4L2-MBUS-FMT-S5C-UYVY-JPEG-1X8">
+              <entry>V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8</entry>
+              <entry>0x5001</entry>
+              <entry>
+                Interleaved raw UYVY and JPEG image format with embedded
+                meta-data used by Samsung S3C73MX camera sensors.
+              </entry>
+            </row>
+          </tbody>
+        </tgroup>
+      </table>
+    </section>
  </section>
 </section>
diff --git a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
index 6a821a65a5ae..2d37abefce13 100644
--- a/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-qbuf.xml
@@ -121,8 +121,7 @@ remaining fields or returns an error code. The driver may also set
 field. It indicates a non-critical (recoverable) streaming error. In such case
 the application may continue as normal, but should be aware that data in the
 dequeued buffer might be corrupted. When using the multi-planar API, the
-planes array does not have to be passed; the <structfield>m.planes</structfield>
+planes array must be passed in as well.</para>
-member must be set to NULL in that case.</para>
    <para>By default <constant>VIDIOC_DQBUF</constant> blocks when no
 buffer is in the outgoing queue. When the
diff --git a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml
index 6e414d7b6df7..a597155c052d 100644
--- a/Documentation/DocBook/media/v4l/vidioc-querybuf.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-querybuf.xml
@@ -48,8 +48,8 @@
  <refsect1>
    <title>Description</title>
-    <para>This ioctl is part of the <link linkend="mmap">memory
+    <para>This ioctl is part of the <link linkend="mmap">streaming
-mapping</link> I/O method. It can be used to query the status of a
+</link> I/O method. It can be used to query the status of a
 buffer at any time after buffers have been allocated with the
 &VIDIOC-REQBUFS; ioctl.</para>
@@ -71,6 +71,7 @@ the structure.</para>
    <para>In the <structfield>flags</structfield> field the
 <constant>V4L2_BUF_FLAG_MAPPED</constant>,
+<constant>V4L2_BUF_FLAG_PREPARED</constant>,
 <constant>V4L2_BUF_FLAG_QUEUED</constant> and
 <constant>V4L2_BUF_FLAG_DONE</constant> flags will be valid. The
 <structfield>memory</structfield> field will be set to the current
@@ -79,8 +80,10 @@ contains the offset of the buffer from the start of the device memory,
 the <structfield>length</structfield> field its size. For the multi-planar API,
 fields <structfield>m.mem_offset</structfield> and
 <structfield>length</structfield> in the <structfield>m.planes</structfield>
-array elements will be used instead. The driver may or may not set the remaining
+array elements will be used instead and the <structfield>length</structfield>
-fields and flags, they are meaningless in this context.</para>
+field of &v4l2-buffer; is set to the number of filled-in array elements.
+The driver may or may not set the remaining fields and flags, they are
+meaningless in this context.</para>
    <para>The <structname>v4l2_buffer</structname> structure is
    specified in <xref linkend="buffer" />.</para>
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index e0aedb7a7827..fe122d6e686f 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -1216,8 +1216,6 @@ in this page</entry>
 #define NAND_BBT_LASTBLOCK      0x00000010
 /* The bbt is at the given page, else we must scan for the bbt */
 #define NAND_BBT_ABSPAGE        0x00000020
-/* The bbt is at the given page, else we must scan for the bbt */
-#define NAND_BBT_SEARCH         0x00000040
 /* bbt is stored per chip on multichip devices */
 #define NAND_BBT_PERCHIP        0x00000080
 /* bbt has a version counter at offset veroffs */
diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting
index a341d87d276e..0c1f475fdf36 100644
--- a/Documentation/arm/Booting
+++ b/Documentation/arm/Booting
@@ -154,13 +154,33 @@ In either case, the following conditions must be met:
 - CPU mode
  All forms of interrupts must be disabled (IRQs and FIQs)
-  The CPU must be in SVC mode.  (A special exception exists for Angel)
+  For CPUs which do not include the ARM virtualization extensions, the
+  CPU must be in SVC mode.  (A special exception exists for Angel)
+  CPUs which include support for the virtualization extensions can be
+  entered in HYP mode in order to enable the kernel to make full use of
+  these extensions.  This is the recommended boot method for such CPUs,
+  unless the virtualisations are already in use by a pre-installed
+  hypervisor.
+  If the kernel is not entered in HYP mode for any reason, it must be
+  entered in SVC mode.
 - Caches, MMUs
  The MMU must be off.
  Instruction cache may be on or off.
  Data cache must be off.
+  If the kernel is entered in HYP mode, the above requirements apply to
+  the HYP mode configuration in addition to the ordinary PL1 (privileged
+  kernel modes) configuration.  In addition, all traps into the
+  hypervisor must be disabled, and PL1 access must be granted for all
+  peripherals and CPU resources for which this is architecturally
+  possible.  Except for entering in HYP mode, the system configuration
+  should be such that a kernel which does not include support for the
+  virtualization extensions can boot correctly without extra help.
 - The boot loader is expected to call the kernel image by jumping
  directly to the first instruction of the kernel image.
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index e418dc0a7086..8df5e8e6dceb 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -465,7 +465,6 @@ struct bio {
       bio_end_io_t     *bi_end_io;  /* bi_end_io (bio) */
       atomic_t         bi_cnt;      /* pin count: free when it hits zero */
       void             *bi_private;
-       bio_destructor_t *bi_destructor; /* bi_destructor (bio) */
 };
 With this multipage bio design:
@@ -647,10 +646,6 @@ for a non-clone bio. There are the 6 pools setup for different size biovecs,
 so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the
 given size from these slabs.
-The bi_destructor() routine takes into account the possibility of the bio
-having originated from a different source (see later discussions on
-n/w to block transfers and kvec_cb)
 The bio_get() routine may be used to hold an extra reference on a bio prior
 to i/o submission, if the bio fields are likely to be accessed after the
 i/o is issued (since the bio may otherwise get freed in case i/o completion
diff --git a/Documentation/devicetree/bindings/arm/davinci/nand.txt b/Documentation/devicetree/bindings/arm/davinci/nand.txt
new file mode 100644
index 000000000000..e37241f1fdd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/davinci/nand.txt
@@ -0,0 +1,51 @@
+* Texas Instruments Davinci NAND
+This file provides information, what the device node for the
+davinci nand interface contain.
+Required properties:
+- compatible: "ti,davinci-nand";
+- reg : contain 2 offset/length values:
+        - offset and length for the access window
+        - offset and length for accessing the aemif control registers
+- ti,davinci-chipselect: Indicates on the davinci_nand driver which
+                         chipselect is used for accessing the nand.
+Recommended properties :
+- ti,davinci-mask-ale: mask for ale
+- ti,davinci-mask-cle: mask for cle
+- ti,davinci-mask-chipsel: mask for chipselect
+- ti,davinci-ecc-mode: ECC mode valid values for davinci driver:
+                - "none"
+                - "soft"
+                - "hw"
+- ti,davinci-ecc-bits: used ECC bits, currently supported 1 or 4.
+- ti,davinci-nand-buswidth: buswidth 8 or 16
+- ti,davinci-nand-use-bbt: use flash based bad block table support.
+Example (enbw_cmc board):
+aemif@60000000 {
+        compatible = "ti,davinci-aemif";
+        #address-cells = <2>;
+        #size-cells = <1>;
+        reg = <0x68000000 0x80000>;
+        ranges = <2 0 0x60000000 0x02000000
+                  3 0 0x62000000 0x02000000
+                  4 0 0x64000000 0x02000000
+                  5 0 0x66000000 0x02000000
+                  6 0 0x68000000 0x02000000>;
+        nand@3,0 {
+                compatible = "ti,davinci-nand";
+                reg = <3 0x0 0x807ff
+                        6 0x0 0x8000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                ti,davinci-chipselect = <1>;
+                ti,davinci-mask-ale = <0>;
+                ti,davinci-mask-cle = <0>;
+                ti,davinci-mask-chipsel = <0>;
+                ti,davinci-ecc-mode = "hw";
+                ti,davinci-ecc-bits = <4>;
+                ti,davinci-nand-use-bbt;
+        };
+};
diff --git a/Documentation/devicetree/bindings/i2c/atmel-i2c.txt b/Documentation/devicetree/bindings/i2c/atmel-i2c.txt
new file mode 100644
index 000000000000..b689a0d9441c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/atmel-i2c.txt
@@ -0,0 +1,30 @@
+I2C for Atmel platforms
+Required properties :
+- compatible : Must be "atmel,at91rm9200-i2c", "atmel,at91sam9261-i2c",
+     "atmel,at91sam9260-i2c", "atmel,at91sam9g20-i2c", "atmel,at91sam9g10-i2c"
+     or "atmel,at91sam9x5-i2c"
+- reg: physical base address of the controller and length of memory mapped
+     region.
+- interrupts: interrupt number to the cpu.
+- #address-cells = <1>;
+- #size-cells = <0>;
+Optional properties:
+- Child nodes conforming to i2c bus binding
+Examples :
+i2c0: i2c@fff84000 {
+        compatible = "atmel,at91sam9g20-i2c";
+        reg = <0xfff84000 0x100>;
+        interrupts = <12 4 6>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        24c512@50 {
+                compatible = "24c512";
+                reg = <0x50>;
+                pagesize = <128>;
+        }
+}
diff --git a/Documentation/devicetree/bindings/i2c/davinci.txt b/Documentation/devicetree/bindings/i2c/davinci.txt
new file mode 100644
index 000000000000..2dc935b4113d
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/davinci.txt
@@ -0,0 +1,28 @@
+* Texas Instruments Davinci I2C
+This file provides information, what the device node for the
+davinci i2c interface contain.
+Required properties:
+- compatible: "ti,davinci-i2c";
+- reg : Offset and length of the register set for the device
+Recommended properties :
+- interrupts : standard interrupt property.
+- clock-frequency : desired I2C bus clock frequency in Hz.
+Example (enbw_cmc board):
+        i2c@1c22000 {
+                compatible = "ti,davinci-i2c";
+                reg = <0x22000 0x1000>;
+                clock-frequency = <100000>;
+                interrupts = <15>;
+                interrupt-parent = <&intc>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+                dtt@48 {
+                        compatible = "national,lm75";
+                        reg = <0x48>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
index 30ac3a0557f7..7a3fe9e5f4cb 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-mxs.txt
@@ -6,6 +6,7 @@ Required properties:
 - interrupts: Should contain ERROR and DMA interrupts
 - clock-frequency: Desired I2C bus clock frequency in Hz.
                   Only 100000Hz and 400000Hz modes are supported.
+- fsl,i2c-dma-channel: APBX DMA channel for the I2C
 Examples:
@@ -16,4 +17,5 @@ i2c0: i2c@80058000 {
        reg = <0x80058000 2000>;
        interrupts = <111 68>;
        clock-frequency = <100000>;
+        fsl,i2c-dma-channel = <6>;
 };
diff --git a/Documentation/devicetree/bindings/i2c/nomadik.txt b/Documentation/devicetree/bindings/i2c/nomadik.txt
new file mode 100644
index 000000000000..72065b0ff680
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/nomadik.txt
@@ -0,0 +1,23 @@
+I2C for Nomadik based systems
+Required (non-standard) properties:
+ - Nil
+Recommended (non-standard) properties:
+ - clock-frequency : Maximum bus clock frequency for the device
+Optional (non-standard) properties:
+ - Nil
+Example :
+i2c@80004000 {
+        compatible = "stericsson,db8500-i2c", "st,nomadik-i2c";
+        reg = <0x80004000 0x1000>;
+        interrupts = <0 21 0x4>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        v-i2c-supply = <&db8500_vape_reg>;
+        clock-frequency = <400000>;
+};
diff --git a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
index 548892c08c59..7da578d72123 100644
--- a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+++ b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
@@ -7,7 +7,7 @@ as "armctrl" in the SoC documentation, hence naming of this binding.
 Required properties:
- compatible : should be "brcm,bcm2835-armctrl-ic.txt"
+- compatible : should be "brcm,bcm2835-armctrl-ic"
 - reg : Specifies base physical address and size of the registers.
 - interrupt-controller : Identifies the node as an interrupt controller
 - #interrupt-cells : Specifies the number of cells needed to encode an
diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
new file mode 100644
index 000000000000..0a85c70cd30a
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
@@ -0,0 +1,68 @@
+* Atmel High Speed MultiMedia Card Interface
+This controller on atmel products provides an interface for MMC, SD and SDIO
+types of memory cards.
+This file documents differences between the core properties described
+by mmc.txt and the properties used by the atmel-mci driver.
+1) MCI node
+Required properties:
+- compatible: should be "atmel,hsmci"
+- #address-cells: should be one. The cell is the slot id.
+- #size-cells: should be zero.
+- at least one slot node
+The node contains child nodes for each slot that the platform uses
+Example MCI node:
+mmc0: mmc@f0008000 {
+        compatible = "atmel,hsmci";
+        reg = <0xf0008000 0x600>;
+        interrupts = <12 4>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        [ child node definitions...]
+};
+2) slot nodes
+Required properties:
+- reg: should contain the slot id.
+- bus-width: number of data lines connected to the controller
+Optional properties:
+- cd-gpios: specify GPIOs for card detection
+- cd-inverted: invert the value of external card detect gpio line
+- wp-gpios: specify GPIOs for write protection
+Example slot node:
+slot@0 {
+        reg = <0>;
+        bus-width = <4>;
+        cd-gpios = <&pioD 15 0>
+        cd-inverted;
+};
+Example full MCI node:
+mmc0: mmc@f0008000 {
+        compatible = "atmel,hsmci";
+        reg = <0xf0008000 0x600>;
+        interrupts = <12 4>;
+        #address-cells = <1>;
+        #size-cells = <0>;
+        slot@0 {
+                reg = <0>;
+                bus-width = <4>;
+                cd-gpios = <&pioD 15 0>
+                cd-inverted;
+        };
+        slot@1 {
+                reg = <1>;
+                bus-width = <4>;
+        };
+};
diff --git a/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
new file mode 100644
index 000000000000..792768953330
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/exynos-dw-mshc.txt
@@ -0,0 +1,87 @@
+* Samsung Exynos specific extensions to the Synopsis Designware Mobile
+  Storage Host Controller
+The Synopsis designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core Synopsis dw mshc controller properties described
+by synposis-dw-mshc.txt and the properties used by the Samsung Exynos specific
+extensions to the Synopsis Designware Mobile Storage Host Controller.
+Required Properties:
+* compatible: should be
+        - "samsung,exynos4210-dw-mshc": for controllers with Samsung Exynos4210
+          specific extentions.
+        - "samsung,exynos4412-dw-mshc": for controllers with Samsung Exynos4412
+          specific extentions.
+        - "samsung,exynos5250-dw-mshc": for controllers with Samsung Exynos5250
+          specific extentions.
+* samsung,dw-mshc-ciu-div: Specifies the divider value for the card interface
+  unit (ciu) clock. This property is applicable only for Exynos5 SoC's and
+  ignored for Exynos4 SoC's. The valid range of divider value is 0 to 7.
+* samsung,dw-mshc-sdr-timing: Specifies the value of CIU clock phase shift value
+  in transmit mode and CIU clock phase shift value in receive mode for single
+  data rate mode operation. Refer notes below for the order of the cells and the
+  valid values.
+* samsung,dw-mshc-ddr-timing: Specifies the value of CUI clock phase shift value
+  in transmit mode and CIU clock phase shift value in receive mode for double
+  data rate mode operation. Refer notes below for the order of the cells and the
+  valid values.
+  Notes for the sdr-timing and ddr-timing values:
+    The order of the cells should be
+      - First Cell: CIU clock phase shift value for tx mode.
+      - Second Cell: CIU clock phase shift value for rx mode.
+    Valid values for SDR and DDR CIU clock timing for Exynos5250:
+      - valid value for tx phase shift and rx phase shift is 0 to 7.
+      - when CIU clock divider value is set to 3, all possible 8 phase shift
+        values can be used.
+      - if CIU clock divider value is 0 (that is divide by 1), both tx and rx
+        phase shift clocks should be 0.
+Required properties for a slot:
+* gpios: specifies a list of gpios used for command, clock and data bus. The
+  first gpio is the command line and the second gpio is the clock line. The
+  rest of the gpios (depending on the bus-width property) are the data lines in
+  no particular order. The format of the gpio specifier depends on the gpio
+  controller.
+Example:
+  The MSHC controller node can be split into two portions, SoC specific and
+  board specific portions as listed below.
+        dwmmc0@12200000 {
+                compatible = "samsung,exynos5250-dw-mshc";
+                reg = <0x12200000 0x1000>;
+                interrupts = <0 75 0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
+        dwmmc0@12200000 {
+                num-slots = <1>;
+                supports-highspeed;
+                broken-cd;
+                fifo-depth = <0x80>;
+                card-detect-delay = <200>;
+                samsung,dw-mshc-ciu-div = <3>;
+                samsung,dw-mshc-sdr-timing = <2 3>;
+                samsung,dw-mshc-ddr-timing = <1 2>;
+                slot@0 {
+                        reg = <0>;
+                        bus-width = <8>;
+                        gpios = <&gpc0 0 2 0 3>, <&gpc0 1 2 0 3>,
+                                <&gpc1 0 2 3 3>, <&gpc1 1 2 3 3>,
+                                <&gpc1 2 2 3 3>, <&gpc1 3 2 3 3>,
+                                <&gpc0 3 2 3 3>, <&gpc0 4 2 3 3>,
+                                <&gpc0 5 2 3 3>, <&gpc0 6 2 3 3>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt b/Documentation/devicetree/bindings/mmc/mmc.txt
index 8a6811f4a02f..8e2e0ba2f486 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -9,12 +9,17 @@ Interpreted by the OF core:
 Required properties:
 - bus-width: Number of data lines, can be <1>, <4>, or <8>
+Card detection:
+If no property below is supplied, standard SDHCI card detect is used.
+Only one of the properties in this section should be supplied:
+  - broken-cd: There is no card detection available; polling must be used.
+  - cd-gpios: Specify GPIOs for card detection, see gpio binding
+  - non-removable: non-removable slot (like eMMC); assume always present.
 Optional properties:
- cd-gpios: Specify GPIOs for card detection, see gpio binding
 - wp-gpios: Specify GPIOs for write protection, see gpio binding
 - cd-inverted: when present, polarity on the cd gpio line is inverted
 - wp-inverted: when present, polarity on the wp gpio line is inverted
- non-removable: non-removable slot (like eMMC)
 - max-frequency: maximum operating clock frequency
 Example:
diff --git a/Documentation/devicetree/bindings/mmc/pxa-mmc.txt b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
new file mode 100644
index 000000000000..b7025de7dced
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/pxa-mmc.txt
@@ -0,0 +1,25 @@
+* PXA MMC drivers
+Driver bindings for the PXA MCI (MMC/SDIO) interfaces
+Required properties:
+- compatible: Should be "marvell,pxa-mmc".
+- vmmc-supply: A regulator for VMMC
+Optional properties:
+- marvell,detect-delay-ms: sets the detection delay timeout in ms.
+- marvell,gpio-power: GPIO spec for the card power enable pin
+This file documents differences between the core properties in mmc.txt
+and the properties used by the pxa-mmc driver.
+Examples:
+mmc0: mmc@41100000 {
+        compatible = "marvell,pxa-mmc";
+        reg = <0x41100000 0x1000>;
+        interrupts = <23>;
+        cd-gpios = <&gpio 23 0>;
+        wp-gpios = <&gpio 24 0>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
new file mode 100644
index 000000000000..630a7d7f4718
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/samsung-sdhci.txt
@@ -0,0 +1,53 @@
+* Samsung's SDHCI Controller device tree bindings
+Samsung's SDHCI controller is used as a connectivity interface with external
+MMC, SD and eMMC storage mediums. This file documents differences between the
+core mmc properties described by mmc.txt and the properties used by the
+Samsung implmentation of the SDHCI controller.
+Note: The mmc core bindings documentation states that if none of the core
+card-detect bindings are used, then the standard sdhci card detect mechanism
+is used. The Samsung's SDHCI controller bindings extends this as listed below.
+[A] The property "samsung,cd-pinmux-gpio" can be used as stated in the
+    "Optional Board Specific Properties" section below.
+[B] If core card-detect bindings and "samsung,cd-pinmux-gpio" property
+    is not specified, it is assumed that there is no card detection
+    mechanism used.
+Required SoC Specific Properties:
+- compatible: should be one of the following
+  - "samsung,s3c6410-sdhci": For controllers compatible with s3c6410 sdhci
+    controller.
+  - "samsung,exynos4210-sdhci": For controllers compatible with Exynos4 sdhci
+    controller.
+Required Board Specific Properties:
+- gpios: Should specify the gpios used for clock, command and data lines. The
+  gpio specifier format depends on the gpio controller.
+Optional Board Specific Properties:
+- samsung,cd-pinmux-gpio: Specifies the card detect line that is routed
+  through a pinmux to the card-detect pin of the card slot. This property
+  should be used only if none of the mmc core card-detect properties are
+  used.
+Example:
+        sdhci@12530000 {
+                compatible = "samsung,exynos4210-sdhci";
+                reg = <0x12530000 0x100>;
+                interrupts = <0 75 0>;
+                bus-width = <4>;
+                cd-gpios = <&gpk2 2 2 3 3>;
+                gpios = <&gpk2 0 2 0 3>,  /* clock line */
+                        <&gpk2 1 2 0 3>,  /* command line */
+                        <&gpk2 3 2 3 3>,  /* data line 0 */
+                        <&gpk2 4 2 3 3>,  /* data line 1 */
+                        <&gpk2 5 2 3 3>,  /* data line 2 */
+                        <&gpk2 6 2 3 3>;  /* data line 3 */
+        };
+        Note: This example shows both SoC specific and board specific properties
+        in a single device node. The properties can be actually be seperated
+        into SoC specific node and board specific node.
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-dove.txt b/Documentation/devicetree/bindings/mmc/sdhci-dove.txt
new file mode 100644
index 000000000000..ae9aab9abcd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-dove.txt
@@ -0,0 +1,14 @@
+* Marvell sdhci-dove controller
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-pxav2 and sdhci-pxav3 drivers.
+- compatible: Should be "marvell,dove-sdhci".
+Example:
+sdio0: sdio@92000 {
+        compatible = "marvell,dove-sdhci";
+        reg = <0x92000 0x100>;
+        interrupts = <35>;
+};
diff --git a/Documentation/devicetree/bindings/mmc/sdhci-spear.txt b/Documentation/devicetree/bindings/mmc/sdhci-spear.txt
new file mode 100644
index 000000000000..fd3643e7e467
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/sdhci-spear.txt
@@ -0,0 +1,18 @@
+* SPEAr SDHCI Controller
+This file documents differences between the core properties in mmc.txt
+and the properties used by the sdhci-spear driver.
+Required properties:
+- compatible: "st,spear300-sdhci"
+Optional properties:
+- cd-gpios: card detect gpio, with zero flags.
+Example:
+        sdhci@fc000000 {
+                compatible = "st,spear300-sdhci";
+                reg = <0xfc000000 0x1000>;
+                cd-gpios = <&gpio0 6 0>;
+        };
diff --git a/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
new file mode 100644
index 000000000000..06cd32d08052
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/synposis-dw-mshc.txt
@@ -0,0 +1,79 @@
+* Synopsis Designware Mobile Storage Host Controller
+The Synopsis designware mobile storage host controller is used to interface
+a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
+differences between the core mmc properties described by mmc.txt and the
+properties used by the Synopsis Designware Mobile Storage Host Controller.
+Required Properties:
+* compatible: should be
+        - snps,dw-mshc: for controllers compliant with synopsis dw-mshc.
+* #address-cells: should be 1.
+* #size-cells: should be 0.
+# Slots: The slot specific information are contained within child-nodes with
+  each child-node representing a supported slot. There should be atleast one
+  child node representing a card slot. The name of the child node representing
+  the slot is recommended to be slot@n where n is the unique number of the slot
+  connnected to the controller. The following are optional properties which
+  can be included in the slot child node.
+        * reg: specifies the physical slot number. The valid values of this
+          property is 0 to (num-slots -1), where num-slots is the value
+          specified by the num-slots property.
+        * bus-width: as documented in mmc core bindings.
+        * wp-gpios: specifies the write protect gpio line. The format of the
+          gpio specifier depends on the gpio controller. If the write-protect
+          line is not available, this property is optional.
+Optional properties:
+* num-slots: specifies the number of slots supported by the controller.
+  The number of physical slots actually used could be equal or less than the
+  value specified by num-slots. If this property is not specified, the value
+  of num-slot property is assumed to be 1.
+* fifo-depth: The maximum size of the tx/rx fifo's. If this property is not
+  specified, the default value of the fifo size is determined from the
+  controller registers.
+* card-detect-delay: Delay in milli-seconds before detecting card after card
+  insert event. The default value is 0.
+* supports-highspeed: Enables support for high speed cards (upto 50MHz)
+* broken-cd: as documented in mmc core bindings.
+Aliases:
+- All the MSHC controller nodes should be represented in the aliases node using
+  the following format 'mshc{n}' where n is a unique number for the alias.
+Example:
+The MSHC controller node can be split into two portions, SoC specific and
+board specific portions as listed below.
+        dwmmc0@12200000 {
+                compatible = "snps,dw-mshc";
+                reg = <0x12200000 0x1000>;
+                interrupts = <0 75 0>;
+                #address-cells = <1>;
+                #size-cells = <0>;
+        };
+        dwmmc0@12200000 {
+                num-slots = <1>;
+                supports-highspeed;
+                broken-cd;
+                fifo-depth = <0x80>;
+                card-detect-delay = <200>;
+                slot@0 {
+                        reg = <0>;
+                        bus-width = <8>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/mtd/atmel-nand.txt b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
index a20069502f5a..d555421ea49f 100644
--- a/Documentation/devicetree/bindings/mtd/atmel-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/atmel-nand.txt
@@ -3,7 +3,9 @@ Atmel NAND flash
 Required properties:
 - compatible : "atmel,at91rm9200-nand".
 - reg : should specify localbus address and size used for the chip,
-        and if availlable the ECC.
+        and hardware ECC controller if available.
+        If the hardware ECC is PMECC, it should contain address and size for
+        PMECC, PMECC Error Location controller and ROM which has lookup tables.
 - atmel,nand-addr-offset : offset for the address latch.
 - atmel,nand-cmd-offset : offset for the command latch.
 - #address-cells, #size-cells : Must be present if the device has sub-nodes
@@ -16,6 +18,15 @@ Optional properties:
 - nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
  Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
  "soft_bch".
+- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware.
+  Only supported by at91sam9x5 or later sam9 product.
+- atmel,pmecc-cap : error correct capability for Programmable Multibit ECC
+  Controller. Supported values are: 2, 4, 8, 12, 24.
+- atmel,pmecc-sector-size : sector size for ECC computation. Supported values
+  are: 512, 1024.
+- atmel,pmecc-lookup-table-offset : includes two offsets of lookup table in ROM
+  for different sector size. First one is for sector size 512, the next is for
+  sector size 1024.
 - nand-bus-width : 8 or 16 bus width if not present 8
 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
@@ -39,3 +50,30 @@ nand0: nand@40000000,0 {
                ...
        };
 };
+/* for PMECC supported chips */
+nand0: nand@40000000 {
+        compatible = "atmel,at91rm9200-nand";
+        #address-cells = <1>;
+        #size-cells = <1>;
+        reg = < 0x40000000 0x10000000   /* bus addr & size */
+                0xffffe000 0x00000600   /* PMECC addr & size */
+                0xffffe600 0x00000200   /* PMECC ERRLOC addr & size */
+                0x00100000 0x00100000   /* ROM addr & size */
+                >;
+        atmel,nand-addr-offset = <21>;  /* ale */
+        atmel,nand-cmd-offset = <22>;   /* cle */
+        nand-on-flash-bbt;
+        nand-ecc-mode = "hw";
+        atmel,has-pmecc;        /* enable PMECC */
+        atmel,pmecc-cap = <2>;
+        atmel,pmecc-sector-size = <512>;
+        atmel,pmecc-lookup-table-offset = <0x8000 0x10000>;
+        gpios = <&pioD 5 0      /* rdy */
+                 &pioD 4 0      /* nce */
+                 0              /* cd */
+                >;
+        partition@0 {
+                ...
+        };
+};
diff --git a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
index 1a5bbd346d22..3fb3f9015365 100644
--- a/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/gpmi-nand.txt
@@ -12,6 +12,10 @@ Required properties:
  - interrupt-names : The interrupt names "gpmi-dma", "bch";
  - fsl,gpmi-dma-channel : Should contain the dma channel it uses.
+Optional properties:
+  - nand-on-flash-bbt: boolean to enable on flash bbt option if not
+                       present false
 The device tree may optionally contain sub-nodes describing partitions of the
 address space. See partition.txt for more detail.
diff --git a/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt b/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt
new file mode 100644
index 000000000000..d0a37252eb22
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/lpc32xx-mlc.txt
@@ -0,0 +1,50 @@
+NXP LPC32xx SoC NAND MLC controller
+Required properties:
+- compatible: "nxp,lpc3220-mlc"
+- reg: Address and size of the controller
+- interrupts: The NAND interrupt specification
+- gpios: GPIO specification for NAND write protect
+The following required properties are very controller specific. See the LPC32xx
+User Manual 7.5.14 MLC NAND Timing Register (the values here are specified in
+Hz, to make them independent of actual clock speed and to provide for good
+accuracy:)
+- nxp,tcea_delay: TCEA_DELAY
+- nxp,busy_delay: BUSY_DELAY
+- nxp,nand_ta: NAND_TA
+- nxp,rd_high: RD_HIGH
+- nxp,rd_low: RD_LOW
+- nxp,wr_high: WR_HIGH
+- nxp,wr_low: WR_LOW
+Optional subnodes:
+- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt
+Example:
+        mlc: flash@200A8000 {
+                compatible = "nxp,lpc3220-mlc";
+                reg = <0x200A8000 0x11000>;
+                interrupts = <11 0>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                nxp,tcea-delay = <333333333>;
+                nxp,busy-delay = <10000000>;
+                nxp,nand-ta = <18181818>;
+                nxp,rd-high = <31250000>;
+                nxp,rd-low = <45454545>;
+                nxp,wr-high = <40000000>;
+                nxp,wr-low = <83333333>;
+                gpios = <&gpio 5 19 1>; /* GPO_P3 19, active low */
+                mtd0@00000000 {
+                        label = "boot";
+                        reg = <0x00000000 0x00064000>;
+                        read-only;
+                };
+                ...
+        };
diff --git a/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt b/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt
new file mode 100644
index 000000000000..d94edc0fc554
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/lpc32xx-slc.txt
@@ -0,0 +1,52 @@
+NXP LPC32xx SoC NAND SLC controller
+Required properties:
+- compatible: "nxp,lpc3220-slc"
+- reg: Address and size of the controller
+- nand-on-flash-bbt: Use bad block table on flash
+- gpios: GPIO specification for NAND write protect
+The following required properties are very controller specific. See the LPC32xx
+User Manual:
+- nxp,wdr-clks: Delay before Ready signal is tested on write (W_RDY)
+- nxp,rdr-clks: Delay before Ready signal is tested on read (R_RDY)
+(The following values are specified in Hz, to make them independent of actual
+clock speed:)
+- nxp,wwidth: Write pulse width (W_WIDTH)
+- nxp,whold: Write hold time (W_HOLD)
+- nxp,wsetup: Write setup time (W_SETUP)
+- nxp,rwidth: Read pulse width (R_WIDTH)
+- nxp,rhold: Read hold time (R_HOLD)
+- nxp,rsetup: Read setup time (R_SETUP)
+Optional subnodes:
+- Partitions, see Documentation/devicetree/bindings/mtd/partition.txt
+Example:
+        slc: flash@20020000 {
+                compatible = "nxp,lpc3220-slc";
+                reg = <0x20020000 0x1000>;
+                #address-cells = <1>;
+                #size-cells = <1>;
+                nxp,wdr-clks = <14>;
+                nxp,wwidth = <40000000>;
+                nxp,whold = <100000000>;
+                nxp,wsetup = <100000000>;
+                nxp,rdr-clks = <14>;
+                nxp,rwidth = <40000000>;
+                nxp,rhold = <66666666>;
+                nxp,rsetup = <100000000>;
+                nand-on-flash-bbt;
+                gpios = <&gpio 5 19 1>; /* GPO_P3 19, active low */
+                mtd0@00000000 {
+                        label = "phy3250-boot";
+                        reg = <0x00000000 0x00064000>;
+                        read-only;
+                };
+                ...
+        };
diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
index a63c2bd7de2b..94de19b8f16b 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt
@@ -16,6 +16,13 @@ file systems on embedded devices.
 - #address-cells, #size-cells : Must be present if the device has
   sub-nodes representing partitions (see below).  In this case
   both #address-cells and #size-cells must be equal to 1.
+ - no-unaligned-direct-access: boolean to disable the default direct
+   mapping of the flash.
+   On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause
+   problems with JFFS2 usage, as the local bus (LPB) doesn't support
+   unaligned accesses as implemented in the JFFS2 code via memcpy().
+   By defining "no-unaligned-direct-access", the flash will not be
+   exposed directly to the MTD users (e.g. JFFS2) any more.
 For JEDEC compatible devices, the following additional properties
 are defined:
diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
new file mode 100644
index 000000000000..8522bfbccfd7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -0,0 +1,17 @@
+Freescale i.MX PWM controller
+Required properties:
+- compatible: should be "fsl,<soc>-pwm"
+- reg: physical base address and length of the controller's registers
+- #pwm-cells: should be 2.  The first cell specifies the per-chip index
+  of the PWM to use and the second cell is the period in nanoseconds.
+- interrupts: The interrupt for the pwm controller
+Example:
+pwm1: pwm@53fb4000 {
+        #pwm-cells = <2>;
+        compatible = "fsl,imx53-pwm", "fsl,imx27-pwm";
+        reg = <0x53fb4000 0x4000>;
+        interrupts = <61>;
+};
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
index 11963e4d6bc4..9e3f8f1d46a2 100644
--- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: should be "fsl,imx23-pwm"
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the duty cycle in nanoseconds.
+  of the PWM to use and the second cell is the period in nanoseconds.
 - fsl,pwm-number: the number of PWM devices
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
index bbbeedb4ec05..01438ecd6628 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
@@ -7,7 +7,7 @@ Required properties:
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
  first cell specifies the per-chip index of the PWM to use and the second
-  cell is the duty cycle in nanoseconds.
+  cell is the period in nanoseconds.
 Example:
diff --git a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt
index 2de21c2acf55..844bd5fbd04c 100644
--- a/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt
+++ b/Documentation/devicetree/bindings/timer/brcm,bcm2835-system-timer.txt
@@ -7,7 +7,7 @@ free running counter values, and generates an interrupt.
 Required properties:
- compatible : should be "brcm,bcm2835-system-timer.txt"
+- compatible : should be "brcm,bcm2835-system-timer"
 - reg : Specifies base physical address and size of the registers.
 - interrupts : A list of 4 interrupt sinks; one per timer channel.
 - clock-frequency : The frequency of the clock that drives the counter, in Hz.
diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt
index 950856bd2e39..43cff70465ab 100644
--- a/Documentation/driver-model/devres.txt
+++ b/Documentation/driver-model/devres.txt
@@ -284,3 +284,7 @@ CLOCK
 PINCTRL
  devm_pinctrl_get()
  devm_pinctrl_put()
+PWM
+  devm_pwm_get()
+  devm_pwm_put()
diff --git a/Documentation/filesystems/nfs/nfs.txt b/Documentation/filesystems/nfs/nfs.txt
index f50f26ce6cd0..f2571c8bef74 100644
--- a/Documentation/filesystems/nfs/nfs.txt
+++ b/Documentation/filesystems/nfs/nfs.txt
@@ -12,9 +12,47 @@ and work is in progress on adding support for minor version 1 of the NFSv4
 protocol.
 The purpose of this document is to provide information on some of the
-upcall interfaces that are used in order to provide the NFS client with
+special features of the NFS client that can be configured by system
-some of the information that it requires in order to fully comply with
+administrators.
-the NFS spec.
+The nfs4_unique_id parameter
+============================
+NFSv4 requires clients to identify themselves to servers with a unique
+string.  File open and lock state shared between one client and one server
+is associated with this identity.  To support robust NFSv4 state recovery
+and transparent state migration, this identity string must not change
+across client reboots.
+Without any other intervention, the Linux client uses a string that contains
+the local system's node name.  System administrators, however, often do not
+take care to ensure that node names are fully qualified and do not change
+over the lifetime of a client system.  Node names can have other
+administrative requirements that require particular behavior that does not
+work well as part of an nfs_client_id4 string.
+The nfs.nfs4_unique_id boot parameter specifies a unique string that can be
+used instead of a system's node name when an NFS client identifies itself to
+a server.  Thus, if the system's node name is not unique, or it changes, its
+nfs.nfs4_unique_id stays the same, preventing collision with other clients
+or loss of state during NFS reboot recovery or transparent state migration.
+The nfs.nfs4_unique_id string is typically a UUID, though it can contain
+anything that is believed to be unique across all NFS clients.  An
+nfs4_unique_id string should be chosen when a client system is installed,
+just as a system's root file system gets a fresh UUID in its label at
+install time.
+The string should remain fixed for the lifetime of the client.  It can be
+changed safely if care is taken that the client shuts down cleanly and all
+outstanding NFSv4 state has expired, to prevent loss of NFSv4 state.
+This string can be stored in an NFS client's grub.conf, or it can be provided
+via a net boot facility such as PXE.  It may also be specified as an nfs.ko
+module parameter.  Specifying a uniquifier string is not support for NFS
+clients running in containers.
 The DNS resolver
 ================
diff --git a/Documentation/hwmon/da9052 b/Documentation/hwmon/da9052
index ef898553638e..5bc51346b689 100644
--- a/Documentation/hwmon/da9052
+++ b/Documentation/hwmon/da9052
@@ -56,6 +56,6 @@ The junction temperature is calculated:
 The junction temperature attribute is supported by the driver.
 The battery temperature is calculated:
-        Degree Celcius = 1 / (t1 + 1/298)- 273
+        Degree Celsius = 1 / (t1 + 1/298)- 273
 where t1 = (1/B)* ln(( ADCval * 2.5)/(R25*ITBAT*255))
 Default values of R25, B, ITBAT are 10e3, 3380 and 50e-6 respectively.
diff --git a/Documentation/hwmon/max1619 b/Documentation/hwmon/max1619
index d6f8d9cd7d7f..e6d87398cc8f 100644
--- a/Documentation/hwmon/max1619
+++ b/Documentation/hwmon/max1619
@@ -9,7 +9,7 @@ Supported chips:
               http://pdfserv.maxim-ic.com/en/ds/MAX1619.pdf
 Authors:
-        Alexey Fisher <fishor@mail.ru>,
+        Oleksij Rempel <bug-track@fisher-privat.net>,
        Jean Delvare <khali@linux-fr.org>
 Description
diff --git a/Documentation/hwmon/twl4030-madc-hwmon b/Documentation/hwmon/twl4030-madc-hwmon
index ef7984317cec..c3a3a5be10ad 100644
--- a/Documentation/hwmon/twl4030-madc-hwmon
+++ b/Documentation/hwmon/twl4030-madc-hwmon
@@ -41,5 +41,5 @@ Channel Signal
 The Sysfs nodes will represent the voltage in the units of mV,
 the temperature channel shows the converted temperature in
-degree celcius. The Battery charging current channel represents
+degree Celsius. The Battery charging current channel represents
 battery charging current in mA.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index f777fa96243d..e2ed3360b708 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1730,6 +1730,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        will be autodetected by the client, and it will fall
                        back to using the idmapper.
                        To turn off this behaviour, set the value to '0'.
+        nfs.nfs4_unique_id=
+                        [NFS4] Specify an additional fixed unique ident-
+                        ification string that NFSv4 clients can insert into
+                        their nfs_client_id4 string.  This is typically a
+                        UUID that is generated at system install time.
        nfs.send_implementation_id =
                        [NFSv4.1] Send client implementation identification
diff --git a/Documentation/leds/leds-lp5523.txt b/Documentation/leds/leds-lp5523.txt
index fad2feb8b7ce..c2743f59f9ac 100644
--- a/Documentation/leds/leds-lp5523.txt
+++ b/Documentation/leds/leds-lp5523.txt
@@ -10,8 +10,22 @@ Contact: Samu Onkalo (samu.p.onkalo-at-nokia.com)
 Description
 -----------
 LP5523 can drive up to 9 channels. Leds can be controlled directly via
-the led class control interface. Channels have generic names:
+the led class control interface.
-lp5523:channelx where x is 0...8
+The name of each channel is configurable in the platform data - name and label.
+There are three options to make the channel name.
+a) Define the 'name' in the platform data
+To make specific channel name, then use 'name' platform data.
+/sys/class/leds/R1               (name: 'R1')
+/sys/class/leds/B1               (name: 'B1')
+b) Use the 'label' with no 'name' field
+For one device name with channel number, then use 'label'.
+/sys/class/leds/RGB:channelN     (label: 'RGB', N: 0 ~ 8)
+c) Default
+If both fields are NULL, 'lp5523' is used by default.
+/sys/class/leds/lp5523:channelN  (N: 0 ~ 8)
 The chip provides 3 engines. Each engine can control channels without
 interaction from the main CPU. Details of the micro engine code can be found
@@ -46,12 +60,13 @@ Note - chan_nr can have values between 0 and 8.
 static struct lp5523_led_config lp5523_led_config[] = {
        {
+                .name           = "D1",
                .chan_nr        = 0,
                .led_current    = 50,
                .max_current    = 130,
        },
 ...
-        }, {
+        {
                .chan_nr        = 8,
                .led_current    = 50,
                .max_current    = 130,
diff --git a/Documentation/percpu-rw-semaphore.txt b/Documentation/percpu-rw-semaphore.txt
new file mode 100644
index 000000000000..7d3c82431909
--- /dev/null
+++ b/Documentation/percpu-rw-semaphore.txt
@@ -0,0 +1,27 @@
+Percpu rw semaphores
+--------------------
+Percpu rw semaphores is a new read-write semaphore design that is
+optimized for locking for reading.
+The problem with traditional read-write semaphores is that when multiple
+cores take the lock for reading, the cache line containing the semaphore
+is bouncing between L1 caches of the cores, causing performance
+degradation.
+Locking for reading is very fast, it uses RCU and it avoids any atomic
+instruction in the lock and unlock path. On the other hand, locking for
+writing is very expensive, it calls synchronize_rcu() that can take
+hundreds of milliseconds.
+The lock is declared with "struct percpu_rw_semaphore" type.
+The lock is initialized percpu_init_rwsem, it returns 0 on success and
+-ENOMEM on allocation failure.
+The lock must be freed with percpu_free_rwsem to avoid memory leak.
+The lock is locked for read with percpu_down_read, percpu_up_read and
+for write with percpu_down_write, percpu_up_write.
+The idea of using RCU for optimized rw-lock was introduced by
+Eric Dumazet <eric.dumazet@gmail.com>.
+The code was written by Mikulas Patocka <mpatocka@redhat.com>
diff --git a/Documentation/pwm.txt b/Documentation/pwm.txt
index 554290ebab94..7d2b4c9b544b 100644
--- a/Documentation/pwm.txt
+++ b/Documentation/pwm.txt
@@ -36,7 +36,8 @@ Legacy users can request a PWM device using pwm_request() and free it
 after usage with pwm_free().
 New users should use the pwm_get() function and pass to it the consumer
-device or a consumer name. pwm_put() is used to free the PWM device.
+device or a consumer name. pwm_put() is used to free the PWM device. Managed
+variants of these functions, devm_pwm_get() and devm_pwm_put(), also exist.
 After being requested a PWM has to be configured using:
diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py
index a78879b01f09..3fe0d812dcec 100755
--- a/Documentation/target/tcm_mod_builder.py
+++ b/Documentation/target/tcm_mod_builder.py
@@ -402,8 +402,6 @@ def tcm_mod_build_configfs(proto_ident, fabric_mod_dir_var, fabric_mod_name):
        buf += "        .queue_data_in                  = " + fabric_mod_name + "_queue_data_in,\n"
        buf += "        .queue_status                   = " + fabric_mod_name + "_queue_status,\n"
        buf += "        .queue_tm_rsp                   = " + fabric_mod_name + "_queue_tm_rsp,\n"
-        buf += "        .get_fabric_sense_len           = " + fabric_mod_name + "_get_fabric_sense_len,\n"
-        buf += "        .set_fabric_sense_len           = " + fabric_mod_name + "_set_fabric_sense_len,\n"
        buf += "        .is_state_remove                = " + fabric_mod_name + "_is_state_remove,\n"
        buf += "        /*\n"
        buf += "         * Setup function pointers for generic logic in target_core_fabric_configfs.c\n"
@@ -906,20 +904,6 @@ def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name):
                        buf += "}\n\n"
                        bufi += "int " + fabric_mod_name + "_queue_tm_rsp(struct se_cmd *);\n"
-                if re.search('get_fabric_sense_len\)\(', fo):
-                        buf += "u16 " + fabric_mod_name + "_get_fabric_sense_len(void)\n"
-                        buf += "{\n"
-                        buf += "        return 0;\n"
-                        buf += "}\n\n"
-                        bufi += "u16 " + fabric_mod_name + "_get_fabric_sense_len(void);\n"
-                if re.search('set_fabric_sense_len\)\(', fo):
-                        buf += "u16 " + fabric_mod_name + "_set_fabric_sense_len(struct se_cmd *se_cmd, u32 sense_length)\n"
-                        buf += "{\n"
-                        buf += "        return 0;\n"
-                        buf += "}\n\n"
-                        bufi += "u16 " + fabric_mod_name + "_set_fabric_sense_len(struct se_cmd *, u32);\n"
                if re.search('is_state_remove\)\(', fo):
                        buf += "int " + fabric_mod_name + "_is_state_remove(struct se_cmd *se_cmd)\n"
                        buf += "{\n"
diff --git a/Documentation/video4linux/v4l2-controls.txt b/Documentation/video4linux/v4l2-controls.txt
index 54270df99d5c..cfe52c798d74 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -136,11 +136,25 @@ Or alternatively for integer menu controls, by calling v4l2_ctrl_new_int_menu:
                        const struct v4l2_ctrl_ops *ops,
                        u32 id, s32 max, s32 def, const s64 *qmenu_int);
+Standard menu controls with a driver specific menu are added by calling
+v4l2_ctrl_new_std_menu_items:
+        struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
+                struct v4l2_ctrl_handler *hdl,
+                const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
+                s32 skip_mask, s32 def, const char * const *qmenu);
 These functions are typically called right after the v4l2_ctrl_handler_init:
        static const s64 exp_bias_qmenu[] = {
               -2, -1, 0, 1, 2
        };
+        static const char * const test_pattern[] = {
+                "Disabled",
+                "Vertical Bars",
+                "Solid Black",
+                "Solid White",
+        };
        v4l2_ctrl_handler_init(&foo->ctrl_handler, nr_of_controls);
        v4l2_ctrl_new_std(&foo->ctrl_handler, &foo_ctrl_ops,
@@ -156,6 +170,9 @@ These functions are typically called right after the v4l2_ctrl_handler_init:
                        ARRAY_SIZE(exp_bias_qmenu) - 1,
                        ARRAY_SIZE(exp_bias_qmenu) / 2 - 1,
                        exp_bias_qmenu);
+        v4l2_ctrl_new_std_menu_items(&foo->ctrl_handler, &foo_ctrl_ops,
+                        V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0,
+                        0, test_pattern);
        ...
        if (foo->ctrl_handler.error) {
                int err = foo->ctrl_handler.error;
@@ -185,6 +202,13 @@ v4l2_ctrl_new_std_menu in that it doesn't have the mask argument and takes
 as the last argument an array of signed 64-bit integers that form an exact
 menu item list.
+The v4l2_ctrl_new_std_menu_items function is very similar to
+v4l2_ctrl_new_std_menu but takes an extra parameter qmenu, which is the driver
+specific menu for an otherwise standard menu control. A good example for this
+control is the test pattern control for capture/display/sensors devices that
+have the capability to generate test patterns. These test patterns are hardware
+specific, so the contents of the menu will vary from device to device.
 Note that if something fails, the function will return NULL or an error and
 set ctrl_handler->error to the error code. If ctrl_handler->error was already
 set, then it will just return and do nothing. This is also true for
diff --git a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
index 77dfecf4e2d6..a5f8436753e7 100644
--- a/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
+++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
@@ -3591,7 +3591,7 @@
  Looking at the source shows that the fault happened during a call to
-  copy_to_user to copy the data into the kernel:
+  copy_from_user to copy the data into the kernel:
       107             count -= chars;