50 files changed, 1416 insertions, 604 deletions
diff --git a/Documentation/ABI/testing/sysfs-block-zram b/Documentation/ABI/testing/sysfs-block-zram
new file mode 100644
index 000000000000..c8b3b48ec62c
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-block-zram
@@ -0,0 +1,99 @@
+What:           /sys/block/zram<id>/disksize
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The disksize file is read-write and specifies the disk size
+                which represents the limit on the *uncompressed* worth of data
+                that can be stored in this disk.
+What:           /sys/block/zram<id>/initstate
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The disksize file is read-only and shows the initialization
+                state of the device.
+What:           /sys/block/zram<id>/reset
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The disksize file is write-only and allows resetting the
+                device. The reset operation frees all the memory assocaited
+                with this device.
+What:           /sys/block/zram<id>/num_reads
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The num_reads file is read-only and specifies the number of
+                reads (failed or successful) done on this device.
+What:           /sys/block/zram<id>/num_writes
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The num_writes file is read-only and specifies the number of
+                writes (failed or successful) done on this device.
+What:           /sys/block/zram<id>/invalid_io
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The invalid_io file is read-only and specifies the number of
+                non-page-size-aligned I/O requests issued to this device.
+What:           /sys/block/zram<id>/notify_free
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The notify_free file is read-only and specifies the number of
+                swap slot free notifications received by this device. These
+                notifications are send to a swap block device when a swap slot
+                is freed. This statistic is applicable only when this disk is
+                being used as a swap disk.
+What:           /sys/block/zram<id>/discard
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The discard file is read-only and specifies the number of
+                discard requests received by this device. These requests
+                provide information to block device regarding blocks which are
+                no longer used by filesystem.
+What:           /sys/block/zram<id>/zero_pages
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The zero_pages file is read-only and specifies number of zero
+                filled pages written to this disk. No memory is allocated for
+                such pages.
+What:           /sys/block/zram<id>/orig_data_size
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The orig_data_size file is read-only and specifies uncompressed
+                size of data stored in this disk. This excludes zero-filled
+                pages (zero_pages) since no memory is allocated for them.
+                Unit: bytes
+What:           /sys/block/zram<id>/compr_data_size
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The compr_data_size file is read-only and specifies compressed
+                size of data stored in this disk. So, compression ratio can be
+                calculated using orig_data_size and this statistic.
+                Unit: bytes
+What:           /sys/block/zram<id>/mem_used_total
+Date:           August 2010
+Contact:        Nitin Gupta <ngupta@vflare.org>
+Description:
+                The mem_used_total file is read-only and specifies the amount
+                of memory, including allocator fragmentation and metadata
+                overhead, allocated for this disk. So, allocator space
+                efficiency can be calculated using compr_data_size and this
+                statistic.
+                Unit: bytes
+\ No newline at end of file
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl
index 6ae97157b1c7..be34dcbe0d90 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -250,6 +250,9 @@
 <!ENTITY sub-yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
 <!ENTITY sub-yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
 <!ENTITY sub-yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
+<!ENTITY sub-srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
+<!ENTITY sub-srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
+<!ENTITY sub-y10 SYSTEM "v4l/pixfmt-y10.xml">
 <!ENTITY sub-pixfmt SYSTEM "v4l/pixfmt.xml">
 <!ENTITY sub-cropcap SYSTEM "v4l/vidioc-cropcap.xml">
 <!ENTITY sub-dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
@@ -347,6 +350,9 @@
 <!ENTITY yuv422p SYSTEM "v4l/pixfmt-yuv422p.xml">
 <!ENTITY yuyv SYSTEM "v4l/pixfmt-yuyv.xml">
 <!ENTITY yvyu SYSTEM "v4l/pixfmt-yvyu.xml">
+<!ENTITY srggb10 SYSTEM "v4l/pixfmt-srggb10.xml">
+<!ENTITY srggb8 SYSTEM "v4l/pixfmt-srggb8.xml">
+<!ENTITY y10 SYSTEM "v4l/pixfmt-y10.xml">
 <!ENTITY cropcap SYSTEM "v4l/vidioc-cropcap.xml">
 <!ENTITY dbg-g-register SYSTEM "v4l/vidioc-dbg-g-register.xml">
 <!ENTITY encoder-cmd SYSTEM "v4l/vidioc-encoder-cmd.xml">
diff --git a/Documentation/DocBook/v4l/compat.xml b/Documentation/DocBook/v4l/compat.xml
index 54447f0d0784..c9ce61d981f5 100644
--- a/Documentation/DocBook/v4l/compat.xml
+++ b/Documentation/DocBook/v4l/compat.xml
@@ -21,11 +21,15 @@ API.</para>
      <title>Opening and Closing Devices</title>
      <para>For compatibility reasons the character device file names
-recommended for V4L2 video capture, overlay, radio, teletext and raw
+recommended for V4L2 video capture, overlay, radio and raw
 vbi capture devices did not change from those used by V4L. They are
 listed in <xref linkend="devices" /> and below in <xref
          linkend="v4l-dev" />.</para>
+      <para>The teletext devices (minor range 192-223) have been removed in
+V4L2 and no longer exist. There is no hardware available anymore for handling
+pure teletext. Instead raw or sliced VBI is used.</para>
      <para>The V4L <filename>videodev</filename> module automatically
 assigns minor numbers to drivers in load order, depending on the
 registered device type. We recommend that V4L2 drivers by default
@@ -66,13 +70,6 @@ not compatible with V4L or V4L2.</para> </footnote>,
              <entry>64-127</entry>
            </row>
            <row>
-              <entry>Teletext decoder</entry>
-              <entry><para><filename>/dev/vtx</filename>,
-<filename>/dev/vtx0</filename> to
-<filename>/dev/vtx31</filename></para></entry>
-              <entry>192-223</entry>
-            </row>
-            <row>
              <entry>Raw VBI capture</entry>
              <entry><para><filename>/dev/vbi</filename>,
 <filename>/dev/vbi0</filename> to
@@ -2345,6 +2342,17 @@ more information.</para>
        </listitem>
      </orderedlist>
    </section>
+    <section>
+      <title>V4L2 in Linux 2.6.37</title>
+      <orderedlist>
+        <listitem>
+          <para>Remove the vtx (videotext/teletext) API. This API was no longer
+used and no hardware exists to verify the API. Nor were any userspace applications found
+that used it. It was originally scheduled for removal in 2.6.35.
+          </para>
+        </listitem>
+      </orderedlist>
+    </section>
    <section id="other">
      <title>Relation of V4L2 to other Linux multimedia APIs</title>
diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml
index 8408caaee276..2fae3e87ce73 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -312,10 +312,17 @@ minimum value disables backlight compensation.</entry>
            information and bits 24-31 must be zero.</entry>
          </row>
          <row>
+            <entry><constant>V4L2_CID_ILLUMINATORS_1</constant>
+                <constant>V4L2_CID_ILLUMINATORS_2</constant></entry>
+            <entry>boolean</entry>
+            <entry>Switch on or off the illuminator 1 or 2 of the device
+                (usually a microscope).</entry>
+          </row>
+          <row>
            <entry><constant>V4L2_CID_LASTP1</constant></entry>
            <entry></entry>
            <entry>End of the predefined control IDs (currently
-<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry>
+<constant>V4L2_CID_ILLUMINATORS_2</constant> + 1).</entry>
          </row>
          <row>
            <entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>
@@ -357,9 +364,6 @@ enumerate_menu (void)
              querymenu.index++) {
                if (0 == ioctl (fd, &VIDIOC-QUERYMENU;, &amp;querymenu)) {
                        printf ("  %s\n", querymenu.name);
-                } else {
-                        perror ("VIDIOC_QUERYMENU");
-                        exit (EXIT_FAILURE);
                }
        }
 }
diff --git a/Documentation/DocBook/v4l/dev-rds.xml b/Documentation/DocBook/v4l/dev-rds.xml
index 0869d701b1e5..360d2737e649 100644
--- a/Documentation/DocBook/v4l/dev-rds.xml
+++ b/Documentation/DocBook/v4l/dev-rds.xml
@@ -3,15 +3,16 @@
      <para>The Radio Data System transmits supplementary
 information in binary format, for example the station name or travel
 information, on an inaudible audio subcarrier of a radio program. This
-interface is aimed at devices capable of receiving and decoding RDS
+interface is aimed at devices capable of receiving and/or transmitting RDS
 information.</para>
      <para>For more information see the core RDS standard <xref linkend="en50067" />
 and the RBDS standard <xref linkend="nrsc4" />.</para>
      <para>Note that the RBDS standard as is used in the USA is almost identical
-to the RDS standard. Any RDS decoder can also handle RBDS. Only some of the fields
+to the RDS standard. Any RDS decoder/encoder can also handle RBDS. Only some of the
-have slightly different meanings. See the RBDS standard for more information.</para>
+fields have slightly different meanings. See the RBDS standard for more
+information.</para>
      <para>The RBDS standard also specifies support for MMBS (Modified Mobile Search).
 This is a proprietary format which seems to be discontinued. The RDS interface does not
@@ -21,16 +22,25 @@ be needed, then please contact the linux-media mailing list: &v4l-ml;.</para>
  <section>
    <title>Querying Capabilities</title>
-    <para>Devices supporting the RDS capturing API
+    <para>Devices supporting the RDS capturing API set
-set the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
+the <constant>V4L2_CAP_RDS_CAPTURE</constant> flag in
 the <structfield>capabilities</structfield> field of &v4l2-capability;
-returned by the &VIDIOC-QUERYCAP; ioctl.
+returned by the &VIDIOC-QUERYCAP; ioctl.  Any tuner that supports RDS
-Any tuner that supports RDS will set the
+will set the <constant>V4L2_TUNER_CAP_RDS</constant> flag in
-<constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
+the <structfield>capability</structfield> field of &v4l2-tuner;.  If
-field of &v4l2-tuner;.
+the driver only passes RDS blocks without interpreting the data
-Whether an RDS signal is present can be detected by looking at
+the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be
-the <structfield>rxsubchans</structfield> field of &v4l2-tuner;: the
+set, see <link linkend="reading-rds-data">Reading RDS data</link>.
-<constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data was detected.</para>
+For future use the
+flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> has also been
+defined. However, a driver for a radio tuner with this capability does
+not yet exist, so if you are planning to write such a driver you
+should discuss this on the linux-media mailing list: &v4l-ml;.</para>
+    <para> Whether an RDS signal is present can be detected by looking
+at the <structfield>rxsubchans</structfield> field of &v4l2-tuner;:
+the <constant>V4L2_TUNER_SUB_RDS</constant> will be set if RDS data
+was detected.</para>
    <para>Devices supporting the RDS output API
 set the <constant>V4L2_CAP_RDS_OUTPUT</constant> flag in
@@ -40,16 +50,31 @@ Any modulator that supports RDS will set the
 <constant>V4L2_TUNER_CAP_RDS</constant> flag in the <structfield>capability</structfield>
 field of &v4l2-modulator;.
 In order to enable the RDS transmission one must set the <constant>V4L2_TUNER_SUB_RDS</constant>
-bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.</para>
+bit in the <structfield>txsubchans</structfield> field of &v4l2-modulator;.
+If the driver only passes RDS blocks without interpreting the data
+the <constant>V4L2_TUNER_SUB_RDS_BLOCK_IO</constant> flag has to be set. If the
+tuner is capable of handling RDS entities like program identification codes and radio
+text, the flag <constant>V4L2_TUNER_SUB_RDS_CONTROLS</constant> should be set,
+see <link linkend="writing-rds-data">Writing RDS data</link> and
+<link linkend="fm-tx-controls">FM Transmitter Control Reference</link>.</para>
  </section>
-  <section>
+  <section  id="reading-rds-data">
    <title>Reading RDS data</title>
      <para>RDS data can be read from the radio device
-with the &func-read; function. The data is packed in groups of three bytes,
+with the &func-read; function. The data is packed in groups of three bytes.</para>
+  </section>
+  <section  id="writing-rds-data">
+    <title>Writing RDS data</title>
+      <para>RDS data can be written to the radio device
+with the &func-write; function. The data is packed in groups of three bytes,
 as follows:</para>
+  </section>
+  <section>
    <table frame="none" pgwide="1" id="v4l2-rds-data">
      <title>struct
 <structname>v4l2_rds_data</structname></title>
@@ -111,48 +136,57 @@ as follows:</para>
        <tbody valign="top">
          <row>
            <entry>V4L2_RDS_BLOCK_MSK</entry>
+            <entry> </entry>
            <entry>7</entry>
            <entry>Mask for bits 0-2 to get the block ID.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_A</entry>
+            <entry> </entry>
            <entry>0</entry>
            <entry>Block A.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_B</entry>
+            <entry> </entry>
            <entry>1</entry>
            <entry>Block B.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_C</entry>
+            <entry> </entry>
            <entry>2</entry>
            <entry>Block C.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_D</entry>
+            <entry> </entry>
            <entry>3</entry>
            <entry>Block D.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_C_ALT</entry>
+            <entry> </entry>
            <entry>4</entry>
            <entry>Block C'.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_INVALID</entry>
+            <entry>read-only</entry>
            <entry>7</entry>
            <entry>An invalid block.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_CORRECTED</entry>
+            <entry>read-only</entry>
            <entry>0x40</entry>
            <entry>A bit error was detected but corrected.</entry>
          </row>
          <row>
            <entry>V4L2_RDS_BLOCK_ERROR</entry>
+            <entry>read-only</entry>
            <entry>0x80</entry>
-            <entry>An incorrectable error occurred.</entry>
+            <entry>An uncorrectable error occurred.</entry>
          </row>
        </tbody>
      </tgroup>
diff --git a/Documentation/DocBook/v4l/dev-teletext.xml b/Documentation/DocBook/v4l/dev-teletext.xml
index 76184e8ed618..414b1cfff9f4 100644
--- a/Documentation/DocBook/v4l/dev-teletext.xml
+++ b/Documentation/DocBook/v4l/dev-teletext.xml
@@ -1,35 +1,32 @@
  <title>Teletext Interface</title>
-  <para>This interface aims at devices receiving and demodulating
+  <para>This interface was aimed at devices receiving and demodulating
 Teletext data [<xref linkend="ets300706" />, <xref linkend="itu653" />], evaluating the
 Teletext packages and storing formatted pages in cache memory. Such
 devices are usually implemented as microcontrollers with serial
-interface (I<superscript>2</superscript>C) and can be found on older
+interface (I<superscript>2</superscript>C) and could be found on old
 TV cards, dedicated Teletext decoding cards and home-brew devices
 connected to the PC parallel port.</para>
-  <para>The Teletext API was designed by Martin Buck. It is defined in
+  <para>The Teletext API was designed by Martin Buck. It was defined in
 the kernel header file <filename>linux/videotext.h</filename>, the
 specification is available from <ulink url="ftp://ftp.gwdg.de/pub/linux/misc/videotext/">
 ftp://ftp.gwdg.de/pub/linux/misc/videotext/</ulink>. (Videotext is the name of
-the German public television Teletext service.) Conventional character
+the German public television Teletext service.)</para>
-device file names are <filename>/dev/vtx</filename> and
-<filename>/dev/vttuner</filename>, with device number 83, 0 and 83, 16
-respectively. A similar interface exists for the Philips SAA5249
-Teletext decoder [specification?] with character device file names
-<filename>/dev/tlkN</filename>, device number 102, N.</para>
  <para>Eventually the Teletext API was integrated into the V4L API
 with character device file names <filename>/dev/vtx0</filename> to
 <filename>/dev/vtx31</filename>, device major number 81, minor numbers
-192 to 223. For reference the V4L Teletext API specification is
+192 to 223.</para>
-reproduced here in full: "Teletext interfaces talk the existing VTX
-API." Teletext devices with major number 83 and 102 will be removed in
-Linux 2.6.</para>
-  <para>There are no plans to replace the Teletext API or to integrate
+  <para>However, teletext decoders were quickly replaced by more
-it into V4L2. Please write to the linux-media mailing list: &v4l-ml;
+generic VBI demodulators and those dedicated teletext decoders no longer exist.
-when the need arises.</para>
+For many years the vtx devices were still around, even though nobody used
+them. So the decision was made to finally remove support for the Teletext API in
+kernel 2.6.37.</para>
+  <para>Modern devices all use the <link linkend="raw-vbi">raw</link> or
+<link linkend="sliced">sliced</link> VBI API.</para>
  <!--
 Local Variables:
diff --git a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml
index 26e879231088..4db272b8a0d3 100644
--- a/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml
+++ b/Documentation/DocBook/v4l/pixfmt-packed-rgb.xml
@@ -739,7 +739,7 @@ defined in error. Drivers may interpret them as in <xref
            <entry>b<subscript>1</subscript></entry>
            <entry>b<subscript>0</subscript></entry>
          </row>
-          <row id="V4L2-PIX-FMT-BGR666">
+          <row><!-- id="V4L2-PIX-FMT-BGR666" -->
            <entry><constant>V4L2_PIX_FMT_BGR666</constant></entry>
            <entry>'BGRH'</entry>
            <entry></entry>
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb10.xml b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
new file mode 100644
index 000000000000..7b274092e60c
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb10.xml
@@ -0,0 +1,90 @@
+    <refentry>
+      <refmeta>
+        <refentrytitle>V4L2_PIX_FMT_SRGGB10 ('RG10'),
+         V4L2_PIX_FMT_SGRBG10 ('BA10'),
+         V4L2_PIX_FMT_SGBRG10 ('GB10'),
+         V4L2_PIX_FMT_SBGGR10 ('BG10'),
+         </refentrytitle>
+        &manvol;
+      </refmeta>
+      <refnamediv>
+        <refname id="V4L2-PIX-FMT-SRGGB10"><constant>V4L2_PIX_FMT_SRGGB10</constant></refname>
+        <refname id="V4L2-PIX-FMT-SGRBG10"><constant>V4L2_PIX_FMT_SGRBG10</constant></refname>
+        <refname id="V4L2-PIX-FMT-SGBRG10"><constant>V4L2_PIX_FMT_SGBRG10</constant></refname>
+        <refname id="V4L2-PIX-FMT-SBGGR10"><constant>V4L2_PIX_FMT_SBGGR10</constant></refname>
+        <refpurpose>10-bit Bayer formats expanded to 16 bits</refpurpose>
+      </refnamediv>
+      <refsect1>
+        <title>Description</title>
+        <para>The following four pixel formats are raw sRGB / Bayer formats with
+10 bits per colour. Each colour component is stored in a 16-bit word, with 6
+unused high bits filled with zeros. Each n-pixel row contains n/2 green samples
+and n/2 blue or red samples, with alternating red and blue rows. Bytes are
+stored in memory in little endian order. They are conventionally described
+as GRGR... BGBG..., RGRG... GBGB..., etc. Below is an example of one of these
+formats</para>
+    <example>
+      <title><constant>V4L2_PIX_FMT_SBGGR10</constant> 4 &times; 4
+pixel image</title>
+      <formalpara>
+        <title>Byte Order.</title>
+        <para>Each cell is one byte, high 6 bits in high bytes are 0.
+          <informaltable frame="none">
+            <tgroup cols="5" align="center">
+              <colspec align="left" colwidth="2*" />
+              <tbody valign="top">
+                <row>
+                  <entry>start&nbsp;+&nbsp;0:</entry>
+                  <entry>B<subscript>00low</subscript></entry>
+                  <entry>B<subscript>00high</subscript></entry>
+                  <entry>G<subscript>01low</subscript></entry>
+                  <entry>G<subscript>01high</subscript></entry>
+                  <entry>B<subscript>02low</subscript></entry>
+                  <entry>B<subscript>02high</subscript></entry>
+                  <entry>G<subscript>03low</subscript></entry>
+                  <entry>G<subscript>03high</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;8:</entry>
+                  <entry>G<subscript>10low</subscript></entry>
+                  <entry>G<subscript>10high</subscript></entry>
+                  <entry>R<subscript>11low</subscript></entry>
+                  <entry>R<subscript>11high</subscript></entry>
+                  <entry>G<subscript>12low</subscript></entry>
+                  <entry>G<subscript>12high</subscript></entry>
+                  <entry>R<subscript>13low</subscript></entry>
+                  <entry>R<subscript>13high</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;16:</entry>
+                  <entry>B<subscript>20low</subscript></entry>
+                  <entry>B<subscript>20high</subscript></entry>
+                  <entry>G<subscript>21low</subscript></entry>
+                  <entry>G<subscript>21high</subscript></entry>
+                  <entry>B<subscript>22low</subscript></entry>
+                  <entry>B<subscript>22high</subscript></entry>
+                  <entry>G<subscript>23low</subscript></entry>
+                  <entry>G<subscript>23high</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;24:</entry>
+                  <entry>G<subscript>30low</subscript></entry>
+                  <entry>G<subscript>30high</subscript></entry>
+                  <entry>R<subscript>31low</subscript></entry>
+                  <entry>R<subscript>31high</subscript></entry>
+                  <entry>G<subscript>32low</subscript></entry>
+                  <entry>G<subscript>32high</subscript></entry>
+                  <entry>R<subscript>33low</subscript></entry>
+                  <entry>R<subscript>33high</subscript></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+        </para>
+      </formalpara>
+    </example>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/v4l/pixfmt-srggb8.xml b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
new file mode 100644
index 000000000000..2570e3be3cf1
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-srggb8.xml
@@ -0,0 +1,67 @@
+    <refentry id="V4L2-PIX-FMT-SRGGB8">
+      <refmeta>
+        <refentrytitle>V4L2_PIX_FMT_SRGGB8 ('RGGB')</refentrytitle>
+        &manvol;
+      </refmeta>
+      <refnamediv>
+        <refname><constant>V4L2_PIX_FMT_SRGGB8</constant></refname>
+        <refpurpose>Bayer RGB format</refpurpose>
+      </refnamediv>
+      <refsect1>
+        <title>Description</title>
+        <para>This is commonly the native format of digital cameras,
+reflecting the arrangement of sensors on the CCD device. Only one red,
+green or blue value is given for each pixel. Missing components must
+be interpolated from neighbouring pixels. From left to right the first
+row consists of a red and green value, the second row of a green and
+blue value. This scheme repeats to the right and down for every two
+columns and rows.</para>
+        <example>
+          <title><constant>V4L2_PIX_FMT_SRGGB8</constant> 4 &times; 4
+pixel image</title>
+          <formalpara>
+            <title>Byte Order.</title>
+            <para>Each cell is one byte.
+              <informaltable frame="none">
+                <tgroup cols="5" align="center">
+                  <colspec align="left" colwidth="2*" />
+                  <tbody valign="top">
+                    <row>
+                      <entry>start&nbsp;+&nbsp;0:</entry>
+                      <entry>R<subscript>00</subscript></entry>
+                      <entry>G<subscript>01</subscript></entry>
+                      <entry>R<subscript>02</subscript></entry>
+                      <entry>G<subscript>03</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;4:</entry>
+                      <entry>G<subscript>10</subscript></entry>
+                      <entry>B<subscript>11</subscript></entry>
+                      <entry>G<subscript>12</subscript></entry>
+                      <entry>B<subscript>13</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;8:</entry>
+                      <entry>R<subscript>20</subscript></entry>
+                      <entry>G<subscript>21</subscript></entry>
+                      <entry>R<subscript>22</subscript></entry>
+                      <entry>G<subscript>23</subscript></entry>
+                    </row>
+                    <row>
+                      <entry>start&nbsp;+&nbsp;12:</entry>
+                      <entry>G<subscript>30</subscript></entry>
+                      <entry>B<subscript>31</subscript></entry>
+                      <entry>G<subscript>32</subscript></entry>
+                      <entry>B<subscript>33</subscript></entry>
+                    </row>
+                  </tbody>
+                </tgroup>
+              </informaltable>
+            </para>
+          </formalpara>
+        </example>
+      </refsect1>
+    </refentry>
diff --git a/Documentation/DocBook/v4l/pixfmt-y10.xml b/Documentation/DocBook/v4l/pixfmt-y10.xml
new file mode 100644
index 000000000000..d065043db8d8
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-y10.xml
@@ -0,0 +1,79 @@
+<refentry id="V4L2-PIX-FMT-Y10">
+  <refmeta>
+    <refentrytitle>V4L2_PIX_FMT_Y10 ('Y10 ')</refentrytitle>
+    &manvol;
+  </refmeta>
+  <refnamediv>
+    <refname><constant>V4L2_PIX_FMT_Y10</constant></refname>
+    <refpurpose>Grey-scale image</refpurpose>
+  </refnamediv>
+  <refsect1>
+    <title>Description</title>
+    <para>This is a grey-scale image with a depth of 10 bits per pixel. Pixels
+are stored in 16-bit words with unused high bits padded with 0. The least
+significant byte is stored at lower memory addresses (little-endian).</para>
+    <example>
+      <title><constant>V4L2_PIX_FMT_Y10</constant> 4 &times; 4
+pixel image</title>
+      <formalpara>
+        <title>Byte Order.</title>
+        <para>Each cell is one byte.
+          <informaltable frame="none">
+            <tgroup cols="9" align="center">
+              <colspec align="left" colwidth="2*" />
+              <tbody valign="top">
+                <row>
+                  <entry>start&nbsp;+&nbsp;0:</entry>
+                  <entry>Y'<subscript>00low</subscript></entry>
+                  <entry>Y'<subscript>00high</subscript></entry>
+                  <entry>Y'<subscript>01low</subscript></entry>
+                  <entry>Y'<subscript>01high</subscript></entry>
+                  <entry>Y'<subscript>02low</subscript></entry>
+                  <entry>Y'<subscript>02high</subscript></entry>
+                  <entry>Y'<subscript>03low</subscript></entry>
+                  <entry>Y'<subscript>03high</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;8:</entry>
+                  <entry>Y'<subscript>10low</subscript></entry>
+                  <entry>Y'<subscript>10high</subscript></entry>
+                  <entry>Y'<subscript>11low</subscript></entry>
+                  <entry>Y'<subscript>11high</subscript></entry>
+                  <entry>Y'<subscript>12low</subscript></entry>
+                  <entry>Y'<subscript>12high</subscript></entry>
+                  <entry>Y'<subscript>13low</subscript></entry>
+                  <entry>Y'<subscript>13high</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;16:</entry>
+                  <entry>Y'<subscript>20low</subscript></entry>
+                  <entry>Y'<subscript>20high</subscript></entry>
+                  <entry>Y'<subscript>21low</subscript></entry>
+                  <entry>Y'<subscript>21high</subscript></entry>
+                  <entry>Y'<subscript>22low</subscript></entry>
+                  <entry>Y'<subscript>22high</subscript></entry>
+                  <entry>Y'<subscript>23low</subscript></entry>
+                  <entry>Y'<subscript>23high</subscript></entry>
+                </row>
+                <row>
+                  <entry>start&nbsp;+&nbsp;24:</entry>
+                  <entry>Y'<subscript>30low</subscript></entry>
+                  <entry>Y'<subscript>30high</subscript></entry>
+                  <entry>Y'<subscript>31low</subscript></entry>
+                  <entry>Y'<subscript>31high</subscript></entry>
+                  <entry>Y'<subscript>32low</subscript></entry>
+                  <entry>Y'<subscript>32high</subscript></entry>
+                  <entry>Y'<subscript>33low</subscript></entry>
+                  <entry>Y'<subscript>33high</subscript></entry>
+                </row>
+              </tbody>
+            </tgroup>
+          </informaltable>
+        </para>
+      </formalpara>
+    </example>
+  </refsect1>
+</refentry>
diff --git a/Documentation/DocBook/v4l/pixfmt.xml b/Documentation/DocBook/v4l/pixfmt.xml
index c4ad0a8e42dc..d7c467187095 100644
--- a/Documentation/DocBook/v4l/pixfmt.xml
+++ b/Documentation/DocBook/v4l/pixfmt.xml
@@ -566,7 +566,9 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
    &sub-sbggr8;
    &sub-sgbrg8;
    &sub-sgrbg8;
+    &sub-srggb8;
    &sub-sbggr16;
+    &sub-srggb10;
  </section>
  <section id="yuv-formats">
@@ -589,6 +591,7 @@ information.</para>
    &sub-packed-yuv;
    &sub-grey;
+    &sub-y10;
    &sub-y16;
    &sub-yuyv;
    &sub-uyvy;
@@ -685,6 +688,11 @@ http://www.ivtvdriver.org/</ulink></para><para>The format is documented in the
 kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm12</filename>
 </para></entry>
          </row>
+          <row id="V4L2-PIX-FMT-CPIA1">
+            <entry><constant>V4L2_PIX_FMT_CPIA1</constant></entry>
+            <entry>'CPIA'</entry>
+            <entry>YUV format used by the gspca cpia1 driver.</entry>
+          </row>
          <row id="V4L2-PIX-FMT-SPCA501">
            <entry><constant>V4L2_PIX_FMT_SPCA501</constant></entry>
            <entry>'S501'</entry>
@@ -705,11 +713,6 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
            <entry>'S561'</entry>
            <entry>Compressed GBRG Bayer format used by the gspca driver.</entry>
          </row>
-          <row id="V4L2-PIX-FMT-SGRBG10">
-            <entry><constant>V4L2_PIX_FMT_SGRBG10</constant></entry>
-            <entry>'DA10'</entry>
-            <entry>10 bit raw Bayer, expanded to 16 bits.</entry>
-          </row>
          <row id="V4L2-PIX-FMT-SGRBG10DPCM8">
            <entry><constant>V4L2_PIX_FMT_SGRBG10DPCM8</constant></entry>
            <entry>'DB10'</entry>
@@ -770,6 +773,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
            <entry>'S920'</entry>
            <entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
          </row>
+          <row id="V4L2-PIX-FMT-SN9C2028">
+            <entry><constant>V4L2_PIX_FMT_SN9C2028</constant></entry>
+            <entry>'SONX'</entry>
+            <entry>Compressed GBRG bayer format of the gspca sn9c2028 driver.</entry>
+          </row>
          <row id="V4L2-PIX-FMT-STV0680">
            <entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
            <entry>'S680'</entry>
@@ -787,6 +795,20 @@ http://www.thedirks.org/winnov/</ulink></para></entry>
            <entry>'TM60'</entry>
            <entry><para>Used by Trident tm6000</para></entry>
          </row>
+          <row id="V4L2-PIX-FMT-CIT-YYVYUY">
+            <entry><constant>V4L2_PIX_FMT_CIT_YYVYUY</constant></entry>
+            <entry>'CITV'</entry>
+            <entry><para>Used by xirlink CIT, found at IBM webcams.</para>
+                   <para>Uses one line of Y then 1 line of VYUY</para>
+            </entry>
+          </row>
+          <row id="V4L2-PIX-FMT-KONICA420">
+            <entry><constant>V4L2_PIX_FMT_KONICA420</constant></entry>
+            <entry>'KONI'</entry>
+            <entry><para>Used by Konica webcams.</para>
+                   <para>YUV420 planar in blocks of 256 pixels.</para>
+            </entry>
+          </row>
          <row id="V4L2-PIX-FMT-YYUV">
            <entry><constant>V4L2_PIX_FMT_YYUV</constant></entry>
            <entry>'YYUV'</entry>
diff --git a/Documentation/DocBook/v4l/v4l2.xml b/Documentation/DocBook/v4l/v4l2.xml
index 7c3c098d5d08..839e93e875ae 100644
--- a/Documentation/DocBook/v4l/v4l2.xml
+++ b/Documentation/DocBook/v4l/v4l2.xml
@@ -99,6 +99,7 @@ Remote Controller chapter.</contrib>
      <year>2007</year>
      <year>2008</year>
      <year>2009</year>
+      <year>2010</year>
      <holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
 Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
    </copyright>
@@ -110,10 +111,17 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
      <!-- Put document revisions here, newest first. -->
      <!-- API revisions (changes and additions of defines, enums,
 structs, ioctls) must be noted in more detail in the history chapter
-(compat.sgml), along with the possible impact on existing drivers and
+(compat.xml), along with the possible impact on existing drivers and
 applications. -->
      <revision>
+        <revnumber>2.6.37</revnumber>
+        <date>2010-08-06</date>
+        <authorinitials>hv</authorinitials>
+        <revremark>Removed obsolete vtx (videotext) API.</revremark>
+      </revision>
+      <revision>
        <revnumber>2.6.33</revnumber>
        <date>2009-12-03</date>
        <authorinitials>mk</authorinitials>
diff --git a/Documentation/DocBook/v4l/videodev2.h.xml b/Documentation/DocBook/v4l/videodev2.h.xml
index 865b06d9e679..325b23b6964c 100644
--- a/Documentation/DocBook/v4l/videodev2.h.xml
+++ b/Documentation/DocBook/v4l/videodev2.h.xml
@@ -154,23 +154,13 @@ enum <link linkend="v4l2-buf-type">v4l2_buf_type</link> {
        V4L2_BUF_TYPE_VBI_OUTPUT           = 5,
        V4L2_BUF_TYPE_SLICED_VBI_CAPTURE   = 6,
        V4L2_BUF_TYPE_SLICED_VBI_OUTPUT    = 7,
-#if 1 /*KEEP*/
+#if 1
        /* Experimental */
        V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY = 8,
 #endif
        V4L2_BUF_TYPE_PRIVATE              = 0x80,
 };
-enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> {
-        V4L2_CTRL_TYPE_INTEGER       = 1,
-        V4L2_CTRL_TYPE_BOOLEAN       = 2,
-        V4L2_CTRL_TYPE_MENU          = 3,
-        V4L2_CTRL_TYPE_BUTTON        = 4,
-        V4L2_CTRL_TYPE_INTEGER64     = 5,
-        V4L2_CTRL_TYPE_CTRL_CLASS    = 6,
-        V4L2_CTRL_TYPE_STRING        = 7,
-};
 enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link> {
        V4L2_TUNER_RADIO             = 1,
        V4L2_TUNER_ANALOG_TV         = 2,
@@ -288,6 +278,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 #define <link linkend="V4L2-PIX-FMT-RGB565">V4L2_PIX_FMT_RGB565</link>  v4l2_fourcc('R', 'G', 'B', 'P') /* 16  RGB-5-6-5     */
 #define <link linkend="V4L2-PIX-FMT-RGB555X">V4L2_PIX_FMT_RGB555X</link> v4l2_fourcc('R', 'G', 'B', 'Q') /* 16  RGB-5-5-5 BE  */
 #define <link linkend="V4L2-PIX-FMT-RGB565X">V4L2_PIX_FMT_RGB565X</link> v4l2_fourcc('R', 'G', 'B', 'R') /* 16  RGB-5-6-5 BE  */
+#define <link linkend="V4L2-PIX-FMT-BGR666">V4L2_PIX_FMT_BGR666</link>  v4l2_fourcc('B', 'G', 'R', 'H') /* 18  BGR-6-6-6     */
 #define <link linkend="V4L2-PIX-FMT-BGR24">V4L2_PIX_FMT_BGR24</link>   v4l2_fourcc('B', 'G', 'R', '3') /* 24  BGR-8-8-8     */
 #define <link linkend="V4L2-PIX-FMT-RGB24">V4L2_PIX_FMT_RGB24</link>   v4l2_fourcc('R', 'G', 'B', '3') /* 24  RGB-8-8-8     */
 #define <link linkend="V4L2-PIX-FMT-BGR32">V4L2_PIX_FMT_BGR32</link>   v4l2_fourcc('B', 'G', 'R', '4') /* 32  BGR-8-8-8-8   */
@@ -295,6 +286,9 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 /* Grey formats */
 #define <link linkend="V4L2-PIX-FMT-GREY">V4L2_PIX_FMT_GREY</link>    v4l2_fourcc('G', 'R', 'E', 'Y') /*  8  Greyscale     */
+#define <link linkend="V4L2-PIX-FMT-Y4">V4L2_PIX_FMT_Y4</link>      v4l2_fourcc('Y', '0', '4', ' ') /*  4  Greyscale     */
+#define <link linkend="V4L2-PIX-FMT-Y6">V4L2_PIX_FMT_Y6</link>      v4l2_fourcc('Y', '0', '6', ' ') /*  6  Greyscale     */
+#define <link linkend="V4L2-PIX-FMT-Y10">V4L2_PIX_FMT_Y10</link>     v4l2_fourcc('Y', '1', '0', ' ') /* 10  Greyscale     */
 #define <link linkend="V4L2-PIX-FMT-Y16">V4L2_PIX_FMT_Y16</link>     v4l2_fourcc('Y', '1', '6', ' ') /* 16  Greyscale     */
 /* Palette formats */
@@ -330,7 +324,11 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 #define <link linkend="V4L2-PIX-FMT-SBGGR8">V4L2_PIX_FMT_SBGGR8</link>  v4l2_fourcc('B', 'A', '8', '1') /*  8  BGBG.. GRGR.. */
 #define <link linkend="V4L2-PIX-FMT-SGBRG8">V4L2_PIX_FMT_SGBRG8</link>  v4l2_fourcc('G', 'B', 'R', 'G') /*  8  GBGB.. RGRG.. */
 #define <link linkend="V4L2-PIX-FMT-SGRBG8">V4L2_PIX_FMT_SGRBG8</link>  v4l2_fourcc('G', 'R', 'B', 'G') /*  8  GRGR.. BGBG.. */
-#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10bit raw bayer */
+#define <link linkend="V4L2-PIX-FMT-SRGGB8">V4L2_PIX_FMT_SRGGB8</link>  v4l2_fourcc('R', 'G', 'G', 'B') /*  8  RGRG.. GBGB.. */
+#define <link linkend="V4L2-PIX-FMT-SBGGR10">V4L2_PIX_FMT_SBGGR10</link> v4l2_fourcc('B', 'G', '1', '0') /* 10  BGBG.. GRGR.. */
+#define <link linkend="V4L2-PIX-FMT-SGBRG10">V4L2_PIX_FMT_SGBRG10</link> v4l2_fourcc('G', 'B', '1', '0') /* 10  GBGB.. RGRG.. */
+#define <link linkend="V4L2-PIX-FMT-SGRBG10">V4L2_PIX_FMT_SGRBG10</link> v4l2_fourcc('B', 'A', '1', '0') /* 10  GRGR.. BGBG.. */
+#define <link linkend="V4L2-PIX-FMT-SRGGB10">V4L2_PIX_FMT_SRGGB10</link> v4l2_fourcc('R', 'G', '1', '0') /* 10  RGRG.. GBGB.. */
        /* 10bit raw bayer DPCM compressed to 8 bits */
 #define <link linkend="V4L2-PIX-FMT-SGRBG10DPCM8">V4L2_PIX_FMT_SGRBG10DPCM8</link> v4l2_fourcc('B', 'D', '1', '0')
        /*
@@ -346,6 +344,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 #define <link linkend="V4L2-PIX-FMT-MPEG">V4L2_PIX_FMT_MPEG</link>     v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-1/2/4    */
 /*  Vendor-specific formats   */
+#define <link linkend="V4L2-PIX-FMT-CPIA1">V4L2_PIX_FMT_CPIA1</link>    v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1 YUV */
 #define <link linkend="V4L2-PIX-FMT-WNVA">V4L2_PIX_FMT_WNVA</link>     v4l2_fourcc('W', 'N', 'V', 'A') /* Winnov hw compress */
 #define <link linkend="V4L2-PIX-FMT-SN9C10X">V4L2_PIX_FMT_SN9C10X</link>  v4l2_fourcc('S', '9', '1', '0') /* SN9C10x compression */
 #define <link linkend="V4L2-PIX-FMT-SN9C20X-I420">V4L2_PIX_FMT_SN9C20X_I420</link> v4l2_fourcc('S', '9', '2', '0') /* SN9C20x YUV 4:2:0 */
@@ -358,12 +357,15 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
 #define <link linkend="V4L2-PIX-FMT-SPCA561">V4L2_PIX_FMT_SPCA561</link>  v4l2_fourcc('S', '5', '6', '1') /* compressed GBRG bayer */
 #define <link linkend="V4L2-PIX-FMT-PAC207">V4L2_PIX_FMT_PAC207</link>   v4l2_fourcc('P', '2', '0', '7') /* compressed BGGR bayer */
 #define <link linkend="V4L2-PIX-FMT-MR97310A">V4L2_PIX_FMT_MR97310A</link> v4l2_fourcc('M', '3', '1', '0') /* compressed BGGR bayer */
+#define <link linkend="V4L2-PIX-FMT-SN9C2028">V4L2_PIX_FMT_SN9C2028</link> v4l2_fourcc('S', 'O', 'N', 'X') /* compressed GBRG bayer */
 #define <link linkend="V4L2-PIX-FMT-SQ905C">V4L2_PIX_FMT_SQ905C</link>   v4l2_fourcc('9', '0', '5', 'C') /* compressed RGGB bayer */
 #define <link linkend="V4L2-PIX-FMT-PJPG">V4L2_PIX_FMT_PJPG</link>     v4l2_fourcc('P', 'J', 'P', 'G') /* Pixart 73xx JPEG */
 #define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link>    v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
 #define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link>    v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
-#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link>   v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
 #define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link>  v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
+#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link>   v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
+#define <link linkend="V4L2-PIX-FMT-CIT-YYVYUY">V4L2_PIX_FMT_CIT_YYVYUY</link> v4l2_fourcc('C', 'I', 'T', 'V') /* one line of Y then 1 line of VYUY */
+#define <link linkend="V4L2-PIX-FMT-KONICA420">V4L2_PIX_FMT_KONICA420</link>  v4l2_fourcc('K', 'O', 'N', 'I') /* YUV420 planar in blocks of 256 pixels */
 /*
 *      F O R M A T   E N U M E R A T I O N
@@ -380,7 +382,7 @@ struct <link linkend="v4l2-fmtdesc">v4l2_fmtdesc</link> {
 #define V4L2_FMT_FLAG_COMPRESSED 0x0001
 #define V4L2_FMT_FLAG_EMULATED   0x0002
-#if 1 /*KEEP*/
+#if 1
        /* Experimental Frame Size and frame rate enumeration */
 /*
 *      F R A M E   S I Z E   E N U M E R A T I O N
@@ -544,6 +546,8 @@ struct <link linkend="v4l2-buffer">v4l2_buffer</link> {
 #define V4L2_BUF_FLAG_KEYFRAME  0x0008  /* Image is a keyframe (I-frame) */
 #define V4L2_BUF_FLAG_PFRAME    0x0010  /* Image is a P-frame */
 #define V4L2_BUF_FLAG_BFRAME    0x0020  /* Image is a B-frame */
+/* Buffer is ready, but the data contained within is corrupted. */
+#define V4L2_BUF_FLAG_ERROR     0x0040
 #define V4L2_BUF_FLAG_TIMECODE  0x0100  /* timecode field is valid */
 #define V4L2_BUF_FLAG_INPUT     0x0200  /* input field is valid */
@@ -934,6 +938,16 @@ struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link> {
 #define V4L2_CTRL_ID2CLASS(id)    ((id) &amp; 0x0fff0000UL)
 #define V4L2_CTRL_DRIVER_PRIV(id) (((id) &amp; 0xffff) &gt;= 0x1000)
+enum <link linkend="v4l2-ctrl-type">v4l2_ctrl_type</link> {
+        V4L2_CTRL_TYPE_INTEGER       = 1,
+        V4L2_CTRL_TYPE_BOOLEAN       = 2,
+        V4L2_CTRL_TYPE_MENU          = 3,
+        V4L2_CTRL_TYPE_BUTTON        = 4,
+        V4L2_CTRL_TYPE_INTEGER64     = 5,
+        V4L2_CTRL_TYPE_CTRL_CLASS    = 6,
+        V4L2_CTRL_TYPE_STRING        = 7,
+};
 /*  Used in the VIDIOC_QUERYCTRL ioctl for querying controls */
 struct <link linkend="v4l2-queryctrl">v4l2_queryctrl</link> {
        __u32                id;
@@ -1018,21 +1032,27 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
        V4L2_COLORFX_NONE       = 0,
        V4L2_COLORFX_BW         = 1,
        V4L2_COLORFX_SEPIA      = 2,
-        V4L2_COLORFX_NEGATIVE   = 3,
+        V4L2_COLORFX_NEGATIVE = 3,
-        V4L2_COLORFX_EMBOSS     = 4,
+        V4L2_COLORFX_EMBOSS = 4,
-        V4L2_COLORFX_SKETCH     = 5,
+        V4L2_COLORFX_SKETCH = 5,
-        V4L2_COLORFX_SKY_BLUE   = 6,
+        V4L2_COLORFX_SKY_BLUE = 6,
        V4L2_COLORFX_GRASS_GREEN = 7,
        V4L2_COLORFX_SKIN_WHITEN = 8,
-        V4L2_COLORFX_VIVID      = 9.
+        V4L2_COLORFX_VIVID = 9,
 };
 #define V4L2_CID_AUTOBRIGHTNESS                 (V4L2_CID_BASE+32)
 #define V4L2_CID_BAND_STOP_FILTER               (V4L2_CID_BASE+33)
 #define V4L2_CID_ROTATE                         (V4L2_CID_BASE+34)
 #define V4L2_CID_BG_COLOR                       (V4L2_CID_BASE+35)
+#define V4L2_CID_CHROMA_GAIN                    (V4L2_CID_BASE+36)
+#define V4L2_CID_ILLUMINATORS_1                 (V4L2_CID_BASE+37)
+#define V4L2_CID_ILLUMINATORS_2                 (V4L2_CID_BASE+38)
 /* last CID + 1 */
-#define V4L2_CID_LASTP1                         (V4L2_CID_BASE+36)
+#define V4L2_CID_LASTP1                         (V4L2_CID_BASE+39)
 /*  MPEG-class control IDs defined by V4L2 */
 #define V4L2_CID_MPEG_BASE                      (V4L2_CTRL_CLASS_MPEG | 0x900)
@@ -1349,6 +1369,8 @@ struct <link linkend="v4l2-modulator">v4l2_modulator</link> {
 #define V4L2_TUNER_CAP_SAP              0x0020
 #define V4L2_TUNER_CAP_LANG1            0x0040
 #define V4L2_TUNER_CAP_RDS              0x0080
+#define V4L2_TUNER_CAP_RDS_BLOCK_IO     0x0100
+#define V4L2_TUNER_CAP_RDS_CONTROLS     0x0200
 /*  Flags for the 'rxsubchans' field */
 #define V4L2_TUNER_SUB_MONO             0x0001
@@ -1378,7 +1400,8 @@ struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link> {
        enum <link linkend="v4l2-tuner-type">v4l2_tuner_type</link>  type;
        __u32                 seek_upward;
        __u32                 wrap_around;
-        __u32                 reserved[8];
+        __u32                 spacing;
+        __u32                 reserved[7];
 };
 /*
@@ -1433,7 +1456,7 @@ struct <link linkend="v4l2-audioout">v4l2_audioout</link> {
 *
 *      NOTE: EXPERIMENTAL API
 */
-#if 1 /*KEEP*/
+#if 1
 #define V4L2_ENC_IDX_FRAME_I    (0)
 #define V4L2_ENC_IDX_FRAME_P    (1)
 #define V4L2_ENC_IDX_FRAME_B    (2)
@@ -1626,6 +1649,38 @@ struct <link linkend="v4l2-streamparm">v4l2_streamparm</link> {
 };
 /*
+ *      E V E N T S
+ */
+#define V4L2_EVENT_ALL                          0
+#define V4L2_EVENT_VSYNC                        1
+#define V4L2_EVENT_EOS                          2
+#define V4L2_EVENT_PRIVATE_START                0x08000000
+/* Payload for V4L2_EVENT_VSYNC */
+struct <link linkend="v4l2-event-vsync">v4l2_event_vsync</link> {
+        /* Can be V4L2_FIELD_ANY, _NONE, _TOP or _BOTTOM */
+        __u8 field;
+} __attribute__ ((packed));
+struct <link linkend="v4l2-event">v4l2_event</link> {
+        __u32                           type;
+        union {
+                struct <link linkend="v4l2-event-vsync">v4l2_event_vsync</link> vsync;
+                __u8                    data[64];
+        } u;
+        __u32                           pending;
+        __u32                           sequence;
+        struct timespec                 timestamp;
+        __u32                           reserved[9];
+};
+struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link> {
+        __u32                           type;
+        __u32                           reserved[7];
+};
+/*
 *      A D V A N C E D   D E B U G G I N G
 *
 *      NOTE: EXPERIMENTAL API, NEVER RELY ON THIS IN APPLICATIONS!
@@ -1720,7 +1775,7 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
 #define VIDIOC_G_EXT_CTRLS      _IOWR('V', 71, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
 #define VIDIOC_S_EXT_CTRLS      _IOWR('V', 72, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
 #define VIDIOC_TRY_EXT_CTRLS    _IOWR('V', 73, struct <link linkend="v4l2-ext-controls">v4l2_ext_controls</link>)
-#if 1 /*KEEP*/
+#if 1
 #define VIDIOC_ENUM_FRAMESIZES  _IOWR('V', 74, struct <link linkend="v4l2-frmsizeenum">v4l2_frmsizeenum</link>)
 #define VIDIOC_ENUM_FRAMEINTERVALS _IOWR('V', 75, struct <link linkend="v4l2-frmivalenum">v4l2_frmivalenum</link>)
 #define VIDIOC_G_ENC_INDEX       _IOR('V', 76, struct <link linkend="v4l2-enc-idx">v4l2_enc_idx</link>)
@@ -1728,7 +1783,7 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
 #define VIDIOC_TRY_ENCODER_CMD  _IOWR('V', 78, struct <link linkend="v4l2-encoder-cmd">v4l2_encoder_cmd</link>)
 #endif
-#if 1 /*KEEP*/
+#if 1
 /* Experimental, meant for debugging, testing and internal use.
   Only implemented if CONFIG_VIDEO_ADV_DEBUG is defined.
   You must be root to use these ioctls. Never use these in applications! */
@@ -1747,6 +1802,9 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
 #define VIDIOC_QUERY_DV_PRESET  _IOR('V',  86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
 #define VIDIOC_S_DV_TIMINGS     _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
 #define VIDIOC_G_DV_TIMINGS     _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
+#define VIDIOC_DQEVENT           _IOR('V', 89, struct <link linkend="v4l2-event">v4l2_event</link>)
+#define VIDIOC_SUBSCRIBE_EVENT   _IOW('V', 90, struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link>)
+#define VIDIOC_UNSUBSCRIBE_EVENT _IOW('V', 91, struct <link linkend="v4l2-event-subscription">v4l2_event_subscription</link>)
 /* Reminder: when adding new ioctls please add support for them to
   drivers/media/video/v4l2-compat-ioctl32.c as well! */
diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml
index 3c6784e132f3..d733721a7519 100644
--- a/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml
+++ b/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml
@@ -16,8 +16,7 @@
        <funcdef>int <function>ioctl</function></funcdef>
        <paramdef>int <parameter>fd</parameter></paramdef>
        <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>&v4l2-dv-preset;
+        <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
-*<parameter>argp</parameter></paramdef>
      </funcprototype>
    </funcsynopsis>
  </refsynopsisdiv>
diff --git a/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml
index ecc19576bb8f..d5ec6abf0ce2 100644
--- a/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml
+++ b/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml
@@ -16,8 +16,7 @@
        <funcdef>int <function>ioctl</function></funcdef>
        <paramdef>int <parameter>fd</parameter></paramdef>
        <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>&v4l2-dv-timings;
+        <paramdef>struct v4l2_dv_timings *<parameter>argp</parameter></paramdef>
-*<parameter>argp</parameter></paramdef>
      </funcprototype>
    </funcsynopsis>
  </refsynopsisdiv>
diff --git a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
index 402229ee06f6..d272f7ab91b8 100644
--- a/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
+++ b/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml
@@ -16,7 +16,7 @@ input</refpurpose>
        <funcdef>int <function>ioctl</function></funcdef>
        <paramdef>int <parameter>fd</parameter></paramdef>
        <paramdef>int <parameter>request</parameter></paramdef>
-        <paramdef>&v4l2-dv-preset; *<parameter>argp</parameter></paramdef>
+        <paramdef>struct v4l2_dv_preset *<parameter>argp</parameter></paramdef>
      </funcprototype>
    </funcsynopsis>
  </refsynopsisdiv>
diff --git a/Documentation/DocBook/v4l/vidioc-querycap.xml b/Documentation/DocBook/v4l/vidioc-querycap.xml
index 6ab7e25b31b6..d499da93a450 100644
--- a/Documentation/DocBook/v4l/vidioc-querycap.xml
+++ b/Documentation/DocBook/v4l/vidioc-querycap.xml
@@ -184,7 +184,7 @@ data.</entry>
          <row>
            <entry><constant>V4L2_CAP_RDS_CAPTURE</constant></entry>
            <entry>0x00000100</entry>
-            <entry>The device supports the <link linkend="rds">RDS</link> interface.</entry>
+            <entry>The device supports the <link linkend="rds">RDS</link> capture interface.</entry>
          </row>
          <row>
            <entry><constant>V4L2_CAP_VIDEO_OUTPUT_OVERLAY</constant></entry>
@@ -206,6 +206,11 @@ driver capabilities.</para></footnote></entry>
 hardware frequency seeking.</entry>
          </row>
          <row>
+            <entry><constant>V4L2_CAP_RDS_OUTPUT</constant></entry>
+            <entry>0x00000800</entry>
+            <entry>The device supports the <link linkend="rds">RDS</link> output interface.</entry>
+          </row>
+          <row>
            <entry><constant>V4L2_CAP_TUNER</constant></entry>
            <entry>0x00010000</entry>
            <entry>The device has some sort of tuner to
diff --git a/Documentation/DocBook/v4l/vidioc-queryctrl.xml b/Documentation/DocBook/v4l/vidioc-queryctrl.xml
index 8e0e055ac934..0d5e8283cf32 100644
--- a/Documentation/DocBook/v4l/vidioc-queryctrl.xml
+++ b/Documentation/DocBook/v4l/vidioc-queryctrl.xml
@@ -103,8 +103,12 @@ structure. The driver fills the rest of the structure or returns an
 <structfield>index</structfield> is invalid. Menu items are enumerated
 by calling <constant>VIDIOC_QUERYMENU</constant> with successive
 <structfield>index</structfield> values from &v4l2-queryctrl;
-<structfield>minimum</structfield> (0) to
+<structfield>minimum</structfield> to
-<structfield>maximum</structfield>, inclusive.</para>
+<structfield>maximum</structfield>, inclusive. Note that it is possible
+for <constant>VIDIOC_QUERYMENU</constant> to return an &EINVAL; for some
+indices between <structfield>minimum</structfield> and <structfield>maximum</structfield>.
+In that case that particular menu item is not supported by this driver. Also note that
+the <structfield>minimum</structfield> value is not necessarily 0.</para>
    <para>See also the examples in <xref linkend="control" />.</para>
@@ -139,7 +143,7 @@ string. This information is intended for the user.</entry>
            <entry><structfield>minimum</structfield></entry>
            <entry>Minimum value, inclusive. This field gives a lower
 bound for <constant>V4L2_CTRL_TYPE_INTEGER</constant> controls and the
-lowest valid index (always 0) for <constant>V4L2_CTRL_TYPE_MENU</constant> controls.
+lowest valid index for <constant>V4L2_CTRL_TYPE_MENU</constant> controls.
 For <constant>V4L2_CTRL_TYPE_STRING</constant> controls the minimum value
 gives the minimum length of the string. This length <emphasis>does not include the terminating
 zero</emphasis>. It may not be valid for any other type of control, including
@@ -279,7 +283,7 @@ values which are actually different on the hardware.</entry>
          </row>
          <row>
            <entry><constant>V4L2_CTRL_TYPE_MENU</constant></entry>
-            <entry>0</entry>
+            <entry>&ge; 0</entry>
            <entry>1</entry>
            <entry>N-1</entry>
            <entry>The control has a menu of N choices. The names of
@@ -405,8 +409,10 @@ writing a value will cause the device to carry out a given action
        <term><errorcode>EINVAL</errorcode></term>
        <listitem>
          <para>The &v4l2-queryctrl; <structfield>id</structfield>
-is invalid. The &v4l2-querymenu; <structfield>id</structfield> or
+is invalid. The &v4l2-querymenu; <structfield>id</structfield> is
-<structfield>index</structfield> is invalid.</para>
+invalid or <structfield>index</structfield> is out of range (less than
+<structfield>minimum</structfield> or greater than <structfield>maximum</structfield>)
+or this particular menu item is not supported by the driver.</para>
        </listitem>
      </varlistentry>
      <varlistentry>
diff --git a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml
index 14b3ec7ed75b..c30dcc4232c0 100644
--- a/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml
+++ b/Documentation/DocBook/v4l/vidioc-s-hw-freq-seek.xml
@@ -51,7 +51,8 @@
    <para>Start a hardware frequency seek from the current frequency.
 To do this applications initialize the <structfield>tuner</structfield>,
-<structfield>type</structfield>, <structfield>seek_upward</structfield> and
+<structfield>type</structfield>, <structfield>seek_upward</structfield>,
+<structfield>spacing</structfield> and
 <structfield>wrap_around</structfield> fields, and zero out the
 <structfield>reserved</structfield> array of a &v4l2-hw-freq-seek; and
 call the <constant>VIDIOC_S_HW_FREQ_SEEK</constant> ioctl with a pointer
@@ -89,7 +90,12 @@ field and the &v4l2-tuner; <structfield>index</structfield> field.</entry>
          </row>
          <row>
            <entry>__u32</entry>
-            <entry><structfield>reserved</structfield>[8]</entry>
+            <entry><structfield>spacing</structfield></entry>
+            <entry>If non-zero, defines the hardware seek resolution in Hz. The driver selects the nearest value that is supported by the device. If spacing is zero a reasonable default value is used.</entry>
+          </row>
+          <row>
+            <entry>__u32</entry>
+            <entry><structfield>reserved</structfield>[7]</entry>
            <entry>Reserved for future extensions. Drivers and
            applications must set the array to zero.</entry>
          </row>
diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c
index 6e25c2659e0a..a2976a6de033 100644
--- a/Documentation/accounting/getdelays.c
+++ b/Documentation/accounting/getdelays.c
@@ -21,6 +21,7 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <sys/socket.h>
+#include <sys/wait.h>
 #include <signal.h>
 #include <linux/genetlink.h>
@@ -266,11 +267,13 @@ int main(int argc, char *argv[])
        int containerset = 0;
        char containerpath[1024];
        int cfd = 0;
+        int forking = 0;
+        sigset_t sigset;
        struct msgtemplate msg;
-        while (1) {
+        while (!forking) {
-                c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:");
+                c = getopt(argc, argv, "qdiw:r:m:t:p:vlC:c:");
                if (c < 0)
                        break;
@@ -319,6 +322,28 @@ int main(int argc, char *argv[])
                                err(1, "Invalid pid\n");
                        cmd_type = TASKSTATS_CMD_ATTR_PID;
                        break;
+                case 'c':
+                        /* Block SIGCHLD for sigwait() later */
+                        if (sigemptyset(&sigset) == -1)
+                                err(1, "Failed to empty sigset");
+                        if (sigaddset(&sigset, SIGCHLD))
+                                err(1, "Failed to set sigchld in sigset");
+                        sigprocmask(SIG_BLOCK, &sigset, NULL);
+                        /* fork/exec a child */
+                        tid = fork();
+                        if (tid < 0)
+                                err(1, "Fork failed\n");
+                        if (tid == 0)
+                                if (execvp(argv[optind - 1],
+                                    &argv[optind - 1]) < 0)
+                                        exit(-1);
+                        /* Set the command type and avoid further processing */
+                        cmd_type = TASKSTATS_CMD_ATTR_PID;
+                        forking = 1;
+                        break;
                case 'v':
                        printf("debug on\n");
                        dbg = 1;
@@ -370,6 +395,15 @@ int main(int argc, char *argv[])
                goto err;
        }
+        /*
+         * If we forked a child, wait for it to exit. Cannot use waitpid()
+         * as all the delicious data would be reaped as part of the wait
+         */
+        if (tid && forking) {
+                int sig_received;
+                sigwait(&sigset, &sig_received);
+        }
        if (tid) {
                rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET,
                              cmd_type, &tid, sizeof(__u32));
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index b34823ff1646..190018b0c649 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -18,7 +18,8 @@ CONTENTS:
  1.2 Why are cgroups needed ?
  1.3 How are cgroups implemented ?
  1.4 What does notify_on_release do ?
-  1.5 How do I use cgroups ?
+  1.5 What does clone_children do ?
+  1.6 How do I use cgroups ?
 2. Usage Examples and Syntax
  2.1 Basic Usage
  2.2 Attaching processes
@@ -293,7 +294,16 @@ notify_on_release in the root cgroup at system boot is disabled
 value of their parents notify_on_release setting. The default value of
 a cgroup hierarchy's release_agent path is empty.
-1.5 How do I use cgroups ?
+1.5 What does clone_children do ?
+---------------------------------
+If the clone_children flag is enabled (1) in a cgroup, then all
+cgroups created beneath will call the post_clone callbacks for each
+subsystem of the newly created cgroup. Usually when this callback is
+implemented for a subsystem, it copies the values of the parent
+subsystem, this is the case for the cpuset.
+1.6 How do I use cgroups ?
 --------------------------
 To start a new job that is to be contained within a cgroup, using
diff --git a/Documentation/coccinelle.txt b/Documentation/coccinelle.txt
index cd2b02837066..4a276ea7001c 100644
--- a/Documentation/coccinelle.txt
+++ b/Documentation/coccinelle.txt
@@ -24,6 +24,9 @@ of many distributions, e.g. :
 You can get the latest version released from the Coccinelle homepage at
 http://coccinelle.lip6.fr/
+Information and tips about Coccinelle are also provided on the wiki
+pages at http://cocci.ekstranet.diku.dk/wiki/doku.php
 Once you have it, run the following command:
        ./configure
@@ -41,20 +44,22 @@ A Coccinelle-specific target is defined in the top level
 Makefile. This target is named 'coccicheck' and calls the 'coccicheck'
 front-end in the 'scripts' directory.
-Four modes are defined: report, patch, context, and org. The mode to
+Four modes are defined: patch, report, context, and org. The mode to
 use is specified by setting the MODE variable with 'MODE=<mode>'.
+'patch' proposes a fix, when possible.
 'report' generates a list in the following format:
  file:line:column-column: message
-'patch' proposes a fix, when possible.
 'context' highlights lines of interest and their context in a
 diff-like style.Lines of interest are indicated with '-'.
 'org' generates a report in the Org mode format of Emacs.
-Note that not all semantic patches implement all modes.
+Note that not all semantic patches implement all modes. For easy use
+of Coccinelle, the default mode is "chain" which tries the previous
+modes in the order above until one succeeds.
 To make a report for every semantic patch, run the following command:
@@ -68,9 +73,9 @@ To produce patches, run:
 The coccicheck target applies every semantic patch available in the
-subdirectories of 'scripts/coccinelle' to the entire Linux kernel.
+sub-directories of 'scripts/coccinelle' to the entire Linux kernel.
-For each semantic patch, a changelog message is proposed.  It gives a
+For each semantic patch, a commit message is proposed.  It gives a
 description of the problem being checked by the semantic patch, and
 includes a reference to Coccinelle.
@@ -93,12 +98,35 @@ or
        make coccicheck COCCI=<my_SP.cocci> MODE=report
+ Using Coccinelle on (modified) files
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+To apply Coccinelle on a file basis, instead of a directory basis, the
+following command may be used:
+    make C=1 CHECK="scripts/coccicheck"
+To check only newly edited code, use the value 2 for the C flag, i.e.
+    make C=2 CHECK="scripts/coccicheck"
+This runs every semantic patch in scripts/coccinelle by default. The
+COCCI variable may additionally be used to only apply a single
+semantic patch as shown in the previous section.
+The "chain" mode is the default. You can select another one with the
+MODE variable explained above.
+In this mode, there is no information about semantic patches
+displayed, and no commit message proposed.
 Proposing new semantic patches
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 New semantic patches can be proposed and submitted by kernel
 developers. For sake of clarity, they should be organized in the
-subdirectories of 'scripts/coccinelle/'.
+sub-directories of 'scripts/coccinelle/'.
 Detailed description of the 'report' mode
@@ -111,7 +139,7 @@ Example:
 Running
-        make coccicheck MODE=report COCCI=scripts/coccinelle/err_cast.cocci
+        make coccicheck MODE=report COCCI=scripts/coccinelle/api/err_cast.cocci
 will execute the following part of the SmPL script.
@@ -149,7 +177,7 @@ identified.
 Example:
 Running
-        make coccicheck MODE=patch COCCI=scripts/coccinelle/err_cast.cocci
+        make coccicheck MODE=patch COCCI=scripts/coccinelle/api/err_cast.cocci
 will execute the following part of the SmPL script.
@@ -193,7 +221,7 @@ NOTE: The diff-like output generated is NOT an applicable patch. The
 Example:
 Running
-        make coccicheck MODE=context COCCI=scripts/coccinelle/err_cast.cocci
+        make coccicheck MODE=context COCCI=scripts/coccinelle/api/err_cast.cocci
 will execute the following part of the SmPL script.
@@ -228,7 +256,7 @@ diff -u -p /home/user/linux/crypto/ctr.c /tmp/nothing
 Example:
 Running
-        make coccicheck MODE=org COCCI=scripts/coccinelle/err_cast.cocci
+        make coccicheck MODE=org COCCI=scripts/coccinelle/api/err_cast.cocci
 will execute the following part of the SmPL script.
diff --git a/Documentation/devices.txt b/Documentation/devices.txt
index c58abf1ccc71..eccffe715229 100644
--- a/Documentation/devices.txt
+++ b/Documentation/devices.txt
@@ -1496,9 +1496,6 @@ Your cooperation is appreciated.
                 64 = /dev/radio0       Radio device
                    ...
                127 = /dev/radio63      Radio device
-                192 = /dev/vtx0         Teletext device
-                    ...
-                223 = /dev/vtx31        Teletext device
                224 = /dev/vbi0         Vertical blank interrupt
                    ...
                255 = /dev/vbi31        Vertical blank interrupt
@@ -2520,6 +2517,12 @@ Your cooperation is appreciated.
                  8 = /dev/mmcblk1      Second SD/MMC card
                    ...
+                The start of next SD/MMC card can be configured with
+                CONFIG_MMC_BLOCK_MINORS, or overridden at boot/modprobe
+                time using the mmcblk.perdev_minors option. That would
+                bump the offset between each card to be the configured
+                value instead of the default 8.
 179 char        CCube DVXChip-based PCI products
                  0 = /dev/dvxirq0      First DVX device
                  1 = /dev/dvxirq1      Second DVX device
diff --git a/Documentation/dvb/get_dvb_firmware b/Documentation/dvb/get_dvb_firmware
index 350959f4e41b..59690de8ebfe 100644
--- a/Documentation/dvb/get_dvb_firmware
+++ b/Documentation/dvb/get_dvb_firmware
@@ -26,7 +26,8 @@ use IO::Handle;
                "dec3000s", "vp7041", "dibusb", "nxt2002", "nxt2004",
                "or51211", "or51132_qam", "or51132_vsb", "bluebird",
                "opera1", "cx231xx", "cx18", "cx23885", "pvrusb2", "mpc718",
-                "af9015", "ngene", "az6027");
+                "af9015", "ngene", "az6027", "lme2510_lg", "lme2510c_s7395",
+                "lme2510c_s7395_old");
 # Check args
 syntax() if (scalar(@ARGV) != 1);
@@ -584,6 +585,49 @@ sub az6027{
    $firmware;
 }
+sub lme2510_lg {
+    my $sourcefile = "LMEBDA_DVBS.sys";
+    my $hash = "fc6017ad01e79890a97ec53bea157ed2";
+    my $outfile = "dvb-usb-lme2510-lg.fw";
+    my $hasho = "caa065d5fdbd2c09ad57b399bbf55cad";
+    checkstandard();
+    verify($sourcefile, $hash);
+    extract($sourcefile, 4168, 3841, $outfile);
+    verify($outfile, $hasho);
+    $outfile;
+}
+sub lme2510c_s7395 {
+    my $sourcefile = "US2A0D.sys";
+    my $hash = "b0155a8083fb822a3bd47bc360e74601";
+    my $outfile = "dvb-usb-lme2510c-s7395.fw";
+    my $hasho = "3a3cf1aeebd17b6ddc04cebe131e94cf";
+    checkstandard();
+    verify($sourcefile, $hash);
+    extract($sourcefile, 37248, 3720, $outfile);
+    verify($outfile, $hasho);
+    $outfile;
+}
+sub lme2510c_s7395_old {
+    my $sourcefile = "LMEBDA_DVBS7395C.sys";
+    my $hash = "7572ae0eb9cdf91baabd7c0ba9e09b31";
+    my $outfile = "dvb-usb-lme2510c-s7395.fw";
+    my $hasho = "90430c5b435eb5c6f88fd44a9d950674";
+    checkstandard();
+    verify($sourcefile, $hash);
+    extract($sourcefile, 4208, 3881, $outfile);
+    verify($outfile, $hasho);
+    $outfile;
+}
 # ---------------------------------------------------------------
 # Utilities
diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt
new file mode 100644
index 000000000000..e175784b89bf
--- /dev/null
+++ b/Documentation/dvb/lmedm04.txt
@@ -0,0 +1,58 @@
+To extract firmware for the DM04/QQBOX you need to copy the
+following file(s) to this directory.
+for DM04+/QQBOX LME2510C (Sharp 7395 Tuner)
+-------------------------------------------
+The Sharp 7395 driver can be found in windows/system32/driver
+US2A0D.sys (dated 17 Mar 2009)
+and run
+./get_dvb_firmware lme2510c_s7395
+        will produce
+        dvb-usb-lme2510c-s7395.fw
+An alternative but older firmware can be found on the driver
+disk DVB-S_EN_3.5A in BDADriver/driver
+LMEBDA_DVBS7395C.sys (dated 18 Jan 2008)
+and run
+./get_dvb_firmware lme2510c_s7395_old
+        will produce
+        dvb-usb-lme2510c-s7395.fw
+--------------------------------------------------------------------
+The LG firmware can be found on the driver
+disk DM04+_5.1A[LG] in BDADriver/driver
+for DM04 LME2510 (LG Tuner)
+---------------------------
+LMEBDA_DVBS.sys (dated 13 Nov 2007)
+and run
+./get_dvb_firmware lme2510_lg
+        will produce
+        dvb-usb-lme2510-lg.fw
+Other LG firmware can be extracted manually from US280D.sys
+only found in windows/system32/driver.
+dd if=US280D.sys ibs=1 skip=42616 count=3668 of=dvb-usb-lme2510-lg.fw
+for DM04 LME2510C (LG Tuner)
+---------------------------
+dd if=US280D.sys ibs=1 skip=35200 count=3850 of=dvb-usb-lme2510c-lg.fw
+---------------------------------------------------------------------
+Copy the firmware file(s) to /lib/firmware
diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt
index f3e046a6a987..1a2e8aa3fbb1 100644
--- a/Documentation/fb/viafb.txt
+++ b/Documentation/fb/viafb.txt
@@ -197,6 +197,54 @@ Notes:
       example,
           # fbset -depth 16
+[Configure viafb via /proc]
+---------------------------
+    The following files exist in /proc/viafb
+    supported_output_devices
+        This read-only file contains a full ',' seperated list containing all
+        output devices that could be available on your platform. It is likely
+        that not all of those have a connector on your hardware but it should
+        provide a good starting point to figure out which of those names match
+        a real connector.
+        Example:
+        # cat /proc/viafb/supported_output_devices
+    iga1/output_devices
+    iga2/output_devices
+        These two files are readable and writable. iga1 and iga2 are the two
+        independent units that produce the screen image. Those images can be
+        forwarded to one or more output devices. Reading those files is a way
+        to query which output devices are currently used by an iga.
+        Example:
+        # cat /proc/viafb/iga1/output_devices
+        If there are no output devices printed the output of this iga is lost.
+        This can happen for example if only one (the other) iga is used.
+        Writing to these files allows adjusting the output devices during
+        runtime. One can add new devices, remove existing ones or switch
+        between igas. Essentially you can write a ',' seperated list of device
+        names (or a single one) in the same format as the output to those
+        files. You can add a '+' or '-' as a prefix allowing simple addition
+        and removal of devices. So a prefix '+' adds the devices from your list
+        to the already existing ones, '-' removes the listed devices from the
+        existing ones and if no prefix is given it replaces all existing ones
+        with the listed ones. If you remove devices they are expected to turn
+        off. If you add devices that are already part of the other iga they are
+        removed there and added to the new one.
+        Examples:
+        Add CRT as output device to iga1
+        # echo +CRT > /proc/viafb/iga1/output_devices
+        Remove (turn off) DVP1 and LVDS1 as output devices of iga2
+        # echo -DVP1,LVDS1 > /proc/viafb/iga2/output_devices
+        Replace all iga1 output devices by CRT
+        # echo CRT > /proc/viafb/iga1/output_devices
 [Bootup with viafb]:
 --------------------
    Add the following line to your grub.conf:
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index d2af87ba96e1..d8f36f984faa 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -98,7 +98,7 @@ Who:	Pavel Machek <pavel@ucw.cz>
 ---------------------------
 What:   Video4Linux API 1 ioctls and from Video devices.
-When:   July 2009
+When:   kernel 2.6.38
 Files:  include/linux/videodev.h
 Check:  include/linux/videodev.h
 Why:    V4L1 AP1 was replaced by V4L2 API during migration from 2.4 to 2.6
@@ -116,6 +116,21 @@ Who:	Mauro Carvalho Chehab <mchehab@infradead.org>
 ---------------------------
+What:   Video4Linux obsolete drivers using V4L1 API
+When:   kernel 2.6.38
+Files:  drivers/staging/cpia/* drivers/staging/stradis/*
+Check:  drivers/staging/cpia/cpia.c drivers/staging/stradis/stradis.c
+Why:    There are some drivers still using V4L1 API, despite all efforts we've done
+        to migrate. Those drivers are for obsolete hardware that the old maintainer
+        didn't care (or not have the hardware anymore), and that no other developer
+        could find any hardware to buy. They probably have no practical usage today,
+        and people with such old hardware could probably keep using an older version
+        of the kernel. Those drivers will be moved to staging on 2.6.37 and, if nobody
+        care enough to port and test them with V4L2 API, they'll be removed on 2.6.38.
+Who:    Mauro Carvalho Chehab <mchehab@infradead.org>
+---------------------------
 What:   sys_sysctl
 When:   September 2010
 Option: CONFIG_SYSCTL_SYSCALL
@@ -470,29 +485,6 @@ When:	April 2011
 Why:    Superseded by xt_CT
 Who:    Netfilter developer team <netfilter-devel@vger.kernel.org>
---------------------------
-What:   video4linux /dev/vtx teletext API support
-When:   2.6.35
-Files:  drivers/media/video/saa5246a.c drivers/media/video/saa5249.c
-        include/linux/videotext.h
-Why:    The vtx device nodes have been superseded by vbi device nodes
-        for many years. No applications exist that use the vtx support.
-        Of the two i2c drivers that actually support this API the saa5249
-        has been impossible to use for a year now and no known hardware
-        that supports this device exists. The saa5246a is theoretically
-        supported by the old mxb boards, but it never actually worked.
-        In summary: there is no hardware that can use this API and there
-        are no applications actually implementing this API.
-        The vtx support still reserves minors 192-223 and we would really
-        like to reuse those for upcoming new functionality. In the unlikely
-        event that new hardware appears that wants to use the functionality
-        provided by the vtx API, then that functionality should be build
-        around the sliced VBI API instead.
-Who:    Hans Verkuil <hverkuil@xs4all.nl>
 ----------------------------
 What:   IRQF_DISABLED
@@ -526,6 +518,23 @@ Who:	FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
 ----------------------------
+What:   namespace cgroup (ns_cgroup)
+When:   2.6.38
+Why:    The ns_cgroup leads to some problems:
+        * cgroup creation is out-of-control
+        * cgroup name can conflict when pids are looping
+        * it is not possible to have a single process handling
+        a lot of namespaces without falling in a exponential creation time
+        * we may want to create a namespace without creating a cgroup
+        The ns_cgroup is replaced by a compatibility flag 'clone_children',
+        where a newly created cgroup will copy the parent cgroup values.
+        The userspace has to manually create a cgroup and add a task to
+        the 'tasks' file.
+Who:    Daniel Lezcano <daniel.lezcano@free.fr>
+----------------------------
 What:   iwlwifi disable_hw_scan module parameters
 When:   2.6.40
 Why:    Hareware scan is the prefer method for iwlwifi devices for
diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX
index 4303614b5add..8c624a18f67d 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -96,8 +96,6 @@ seq_file.txt
        - how to use the seq_file API
 sharedsubtree.txt
        - a description of shared subtrees for namespaces.
-smbfs.txt
-        - info on using filesystems with the SMB protocol (Win 3.11 and NT).
 spufs.txt
        - info and mount options for the SPU filesystem used on Cell.
 sysfs-pci.txt
diff --git a/Documentation/filesystems/9p.txt b/Documentation/filesystems/9p.txt
index f9765e8cf086..b22abba78fed 100644
--- a/Documentation/filesystems/9p.txt
+++ b/Documentation/filesystems/9p.txt
@@ -111,7 +111,7 @@ OPTIONS
                This can be used to share devices/named pipes/sockets between
                hosts.  This functionality will be expanded in later versions.
-  access        there are three access modes.
+  access        there are four access modes.
                        user  = if a user tries to access a file on v9fs
                                filesystem for the first time, v9fs sends an
                                attach command (Tattach) for that user.
@@ -120,6 +120,8 @@ OPTIONS
                                the files on the mounted filesystem
                        any   = v9fs does single attach and performs all
                                operations as one user
+                        client = ACL based access check on the 9p client
+                                 side for access validation
  cachetag      cache tag to use the specified persistent cache.
                cache tags for existing cache sessions can be listed at
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index e1def1786e50..6ab9442d7eeb 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -353,6 +353,20 @@ noauto_da_alloc		replacing existing files via patterns such as
                        system crashes before the delayed allocation
                        blocks are forced to disk.
+noinit_itable           Do not initialize any uninitialized inode table
+                        blocks in the background.  This feature may be
+                        used by installation CD's so that the install
+                        process can complete as quickly as possible; the
+                        inode table initialization process would then be
+                        deferred until the next time the  file system
+                        is unmounted.
+init_itable=n           The lazy itable init code will wait n times the
+                        number of milliseconds it took to zero out the
+                        previous block group's inode table.  This
+                        minimizes the impact on the systme performance
+                        while file system's inode table is being initialized.
 discard         Controls whether ext4 should issue discard/TRIM
 nodiscard(*)            commands to the underlying block device when
                        blocks are freed.  This is useful for SSD devices
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index a563b74c7aef..e73df2722ff3 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -136,6 +136,7 @@ Table 1-1: Process specific entries in /proc
 statm          Process memory status information
 status         Process status in human readable form
 wchan          If CONFIG_KALLSYMS is set, a pre-decoded wchan
+ pagemap        Page table
 stack          Report full stack trace, enable via CONFIG_STACKTRACE
 smaps          a extension based on maps, showing the memory consumption of
                each mapping
@@ -370,6 +371,7 @@ Shared_Dirty:          0 kB
 Private_Clean:         0 kB
 Private_Dirty:         0 kB
 Referenced:          892 kB
+Anonymous:             0 kB
 Swap:                  0 kB
 KernelPageSize:        4 kB
 MMUPageSize:           4 kB
@@ -378,9 +380,15 @@ The first of these lines shows the same information as is displayed for the
 mapping in /proc/PID/maps.  The remaining lines show the size of the mapping
 (size), the amount of the mapping that is currently resident in RAM (RSS), the
 process' proportional share of this mapping (PSS), the number of clean and
-dirty shared pages in the mapping, and the number of clean and dirty private
+dirty private pages in the mapping.  Note that even a page which is part of a
-pages in the mapping.  The "Referenced" indicates the amount of memory
+MAP_SHARED mapping, but has only a single pte mapped, i.e.  is currently used
-currently marked as referenced or accessed.
+by only one process, is accounted as private and not as shared.  "Referenced"
+indicates the amount of memory currently marked as referenced or accessed.
+"Anonymous" shows the amount of memory that does not belong to any file.  Even
+a mapping associated with a file may contain anonymous pages: when MAP_PRIVATE
+and a page is modified, the file page is replaced by a private anonymous copy.
+"Swap" shows how much would-be-anonymous memory is also used, but out on
+swap.
 This file is only present if the CONFIG_MMU kernel configuration option is
 enabled.
@@ -397,6 +405,9 @@ To clear the bits for the file mapped pages associated with the process
    > echo 3 > /proc/PID/clear_refs
 Any other value written to /proc/PID/clear_refs will have no effect.
+The /proc/pid/pagemap gives the PFN, which can be used to find the pageflags
+using /proc/kpageflags and number of times a page is mapped using
+/proc/kpagecount. For detailed explanation, see Documentation/vm/pagemap.txt.
 1.2 Kernel data
 ---------------
diff --git a/Documentation/filesystems/smbfs.txt b/Documentation/filesystems/smbfs.txt
deleted file mode 100644
index 194fb0decd2c..000000000000
--- a/Documentation/filesystems/smbfs.txt
+++ /dev/null
@@ -1,8 +0,0 @@
-Smbfs is a filesystem that implements the SMB protocol, which is the
-protocol used by Windows for Workgroups, Windows 95 and Windows NT.
-Smbfs was inspired by Samba, the program written by Andrew Tridgell
-that turns any Unix host into a file server for DOS or Windows clients.
-Smbfs is a SMB client, but uses parts of samba for its operation. For
-more info on samba, including documentation, please go to
-http://www.samba.org/ and then on to your nearest mirror.
diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87
index 8d08bf0d38ed..38425f0f2645 100644
--- a/Documentation/hwmon/it87
+++ b/Documentation/hwmon/it87
@@ -22,6 +22,10 @@ Supported chips:
    Prefix: 'it8720'
    Addresses scanned: from Super I/O config space (8 I/O ports)
    Datasheet: Not publicly available
+  * IT8721F/IT8758E
+    Prefix: 'it8721'
+    Addresses scanned: from Super I/O config space (8 I/O ports)
+    Datasheet: Not publicly available
  * SiS950   [clone of IT8705F]
    Prefix: 'it87'
    Addresses scanned: from Super I/O config space (8 I/O ports)
@@ -67,7 +71,7 @@ Description
 -----------
 This driver implements support for the IT8705F, IT8712F, IT8716F,
-IT8718F, IT8720F, IT8726F and SiS950 chips.
+IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips.
 These chips are 'Super I/O chips', supporting floppy disks, infrared ports,
 joysticks and other miscellaneous stuff. For hardware monitoring, they
@@ -86,14 +90,15 @@ the driver won't notice and report changes in the VID value. The two
 upper VID bits share their pins with voltage inputs (in5 and in6) so you
 can't have both on a given board.
-The IT8716F, IT8718F, IT8720F and later IT8712F revisions have support for
+The IT8716F, IT8718F, IT8720F, IT8721F/IT8758E and later IT8712F revisions
-2 additional fans. The additional fans are supported by the driver.
+have support for 2 additional fans. The additional fans are supported by the
+driver.
-The IT8716F, IT8718F and IT8720F, and late IT8712F and IT8705F also have
+The IT8716F, IT8718F, IT8720F and IT8721F/IT8758E, and late IT8712F and
-optional 16-bit tachometer counters for fans 1 to 3. This is better (no more
+IT8705F also have optional 16-bit tachometer counters for fans 1 to 3. This
-fan clock divider mess) but not compatible with the older chips and
+is better (no more fan clock divider mess) but not compatible with the older
-revisions. The 16-bit tachometer mode is enabled by the driver when one
+chips and revisions. The 16-bit tachometer mode is enabled by the driver when
-of the above chips is detected.
+one of the above chips is detected.
 The IT8726F is just bit enhanced IT8716F with additional hardware
 for AMD power sequencing. Therefore the chip will appear as IT8716F
@@ -115,7 +120,12 @@ alarm is triggered if the voltage has crossed a programmable minimum or
 maximum limit. Note that minimum in this case always means 'closest to
 zero'; this is important for negative voltage measurements. All voltage
 inputs can measure voltages between 0 and 4.08 volts, with a resolution of
-0.016 volt. The battery voltage in8 does not have limit registers.
+0.016 volt (except IT8721F/IT8758E: 0.012 volt.) The battery voltage in8 does
+not have limit registers.
+On the IT8721F/IT8758E, some voltage inputs are internal and scaled inside
+the chip (in7, in8 and optionally in3). The driver handles this transparently
+so user-space doesn't have to care.
 The VID lines (IT8712F/IT8716F/IT8718F/IT8720F) encode the core voltage value:
 the voltage level your processor should work with. This is hardcoded by
diff --git a/Documentation/hwmon/lm85 b/Documentation/hwmon/lm85
index b98e0e0d1910..239258a63c81 100644
--- a/Documentation/hwmon/lm85
+++ b/Documentation/hwmon/lm85
@@ -14,6 +14,10 @@ Supported chips:
    Prefix: 'adt7463'
    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
    Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7463
+  * Analog Devices ADT7468
+    Prefix: 'adt7468'
+    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
+    Datasheet: http://www.onsemi.com/PowerSolutions/product.do?id=ADT7468
  * SMSC EMC6D100, SMSC EMC6D101
    Prefix: 'emc6d100'
    Addresses scanned: I2C 0x2c, 0x2d, 0x2e
@@ -34,7 +38,7 @@ Description
 -----------
 This driver implements support for the National Semiconductor LM85 and
-compatible chips including the Analog Devices ADM1027, ADT7463 and
+compatible chips including the Analog Devices ADM1027, ADT7463, ADT7468 and
 SMSC EMC6D10x chips family.
 The LM85 uses the 2-wire interface compatible with the SMBUS 2.0
@@ -87,14 +91,22 @@ To smooth the response of fans to changes in temperature, the LM85 has an
 optional filter for smoothing temperatures. The ADM1027 has the same
 config option but uses it to rate limit the changes to fan speed instead.
-The ADM1027 and ADT7463 have a 10-bit ADC and can therefore measure
+The ADM1027, ADT7463 and ADT7468 have a 10-bit ADC and can therefore
-temperatures with 0.25 degC resolution. They also provide an offset to the
+measure temperatures with 0.25 degC resolution. They also provide an offset
-temperature readings that is automatically applied during measurement.
+to the temperature readings that is automatically applied during
-This offset can be used to zero out any errors due to traces and placement.
+measurement. This offset can be used to zero out any errors due to traces
-The documentation says that the offset is in 0.25 degC steps, but in
+and placement. The documentation says that the offset is in 0.25 degC
-initial testing of the ADM1027 it was 1.00 degC steps. Analog Devices has
+steps, but in initial testing of the ADM1027 it was 1.00 degC steps. Analog
-confirmed this "bug". The ADT7463 is reported to work as described in the
+Devices has confirmed this "bug". The ADT7463 is reported to work as
-documentation. The current lm85 driver does not show the offset register.
+described in the documentation. The current lm85 driver does not show the
+offset register.
+The ADT7468 has a high-frequency PWM mode, where all PWM outputs are
+driven by a 22.5 kHz clock. This is a global mode, not per-PWM output,
+which means that setting any PWM frequency above 11.3 kHz will switch
+all 3 PWM outputs to a 22.5 kHz frequency. Conversely, setting any PWM
+frequency below 11.3 kHz will switch all 3 PWM outputs to a frequency
+between 10 and 100 Hz, which can then be tuned separately.
 See the vendor datasheets for more information. There is application note
 from National (AN-1260) with some additional information about the LM85.
@@ -125,17 +137,17 @@ datasheet for a complete description of the differences. Other than
 identifying the chip, the driver behaves no differently with regard to
 these two chips. The LM85B is recommended for new designs.
-The ADM1027 and ADT7463 chips have an optional SMBALERT output that can be
+The ADM1027, ADT7463 and ADT7468 chips have an optional SMBALERT output
-used to signal the chipset in case a limit is exceeded or the temperature
+that can be used to signal the chipset in case a limit is exceeded or the
-sensors fail. Individual sensor interrupts can be masked so they won't
+temperature sensors fail. Individual sensor interrupts can be masked so
-trigger SMBALERT. The SMBALERT output if configured replaces one of the other
+they won't trigger SMBALERT. The SMBALERT output if configured replaces one
-functions (PWM2 or IN0). This functionality is not implemented in current
+of the other functions (PWM2 or IN0). This functionality is not implemented
-driver.
+in current driver.
-The ADT7463 also has an optional THERM output/input which can be connected
+The ADT7463 and ADT7468 also have an optional THERM output/input which can
-to the processor PROC_HOT output. If available, the autofan control
+be connected to the processor PROC_HOT output. If available, the autofan
-dynamic Tmin feature can be enabled to keep the system temperature within
+control dynamic Tmin feature can be enabled to keep the system temperature
-spec (just?!) with the least possible fan noise.
+within spec (just?!) with the least possible fan noise.
 Configuration Notes
 -------------------
@@ -201,8 +213,8 @@ the temperatures to compensate for systemic errors in the
 measurements. These features are not currently supported by the lm85
 driver.
-In addition to the ADM1027 features, the ADT7463 also has Tmin control
+In addition to the ADM1027 features, the ADT7463 and ADT7468 also have
-and THERM asserted counts. Automatic Tmin control acts to adjust the
+Tmin control and THERM asserted counts. Automatic Tmin control acts to
-Tmin value to maintain the measured temperature sensor at a specified
+adjust the Tmin value to maintain the measured temperature sensor at a
-temperature. There isn't much documentation on this feature in the
+specified temperature. There isn't much documentation on this feature in
-ADT7463 data sheet. This is not supported by current driver.
+the ADT7463 data sheet. This is not supported by current driver.
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index 6a03dd4bcc94..fa475c0a48a3 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -63,8 +63,8 @@ Supported chips:
    Datasheet: Publicly available at the Maxim website
               http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
  * Maxim MAX6659
-    Prefix: 'max6657'
+    Prefix: 'max6659'
-    Addresses scanned: I2C 0x4c, 0x4d (unsupported 0x4e)
+    Addresses scanned: I2C 0x4c, 0x4d, 0x4e
    Datasheet: Publicly available at the Maxim website
               http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2578
  * Maxim MAX6680
@@ -84,6 +84,21 @@ Supported chips:
    Addresses scanned: I2C 0x4c
    Datasheet: Publicly available at the Maxim website
               http://www.maxim-ic.com/quick_view2.cfm/qv_pk/3500
+  * Maxim MAX6695
+    Prefix: 'max6695'
+    Addresses scanned: I2C 0x18
+    Datasheet: Publicly available at the Maxim website
+               http://www.maxim-ic.com/datasheet/index.mvp/id/4199
+  * Maxim MAX6696
+    Prefix: 'max6695'
+    Addresses scanned: I2C 0x18, 0x19, 0x1a, 0x29, 0x2a, 0x2b,
+                           0x4c, 0x4d and 0x4e
+    Datasheet: Publicly available at the Maxim website
+               http://www.maxim-ic.com/datasheet/index.mvp/id/4199
+  * Winbond/Nuvoton W83L771W/G
+    Prefix: 'w83l771'
+    Addresses scanned: I2C 0x4c
+    Datasheet: No longer available
  * Winbond/Nuvoton W83L771AWG/ASG
    Prefix: 'w83l771'
    Addresses scanned: I2C 0x4c
@@ -101,10 +116,11 @@ well as the temperature of up to one external diode. It is compatible
 with many other devices, many of which are supported by this driver.
 Note that there is no easy way to differentiate between the MAX6657,
-MAX6658 and MAX6659 variants. The extra address and features of the
+MAX6658 and MAX6659 variants. The extra features of the MAX6659 are only
-MAX6659 are not supported by this driver. The MAX6680 and MAX6681 only
+supported by this driver if the chip is located at address 0x4d or 0x4e,
-differ in their pinout, therefore they obviously can't (and don't need to)
+or if the chip type is explicitly selected as max6659.
-be distinguished.
+The MAX6680 and MAX6681 only differ in their pinout, therefore they obviously
+can't (and don't need to) be distinguished.
 The specificity of this family of chipsets over the ADM1021/LM84
 family is that it features critical limits with hysteresis, and an
@@ -151,11 +167,21 @@ MAX6680 and MAX6681:
  * Selectable address
  * Remote sensor type selection
+MAX6695 and MAX6696:
+  * Better local resolution
+  * Selectable address (max6696)
+  * Second critical temperature limit
+  * Two remote sensors
+W83L771W/G
+  * The G variant is lead-free, otherwise similar to the W.
+  * Filter and alert configuration register at 0xBF
+  * Moving average (depending on conversion rate)
 W83L771AWG/ASG
+  * Successor of the W83L771W/G, same features.
  * The AWG and ASG variants only differ in package format.
-  * Filter and alert configuration register at 0xBF
  * Diode ideality factor configuration (remote sensor) at 0xE3
-  * Moving average (depending on conversion rate)
 All temperature values are given in degrees Celsius. Resolution
 is 1.0 degree for the local temperature, 0.125 degree for the remote
diff --git a/Documentation/hwmon/pcf8591 b/Documentation/hwmon/pcf8591
index e76a7892f68e..ac020b3bb7b3 100644
--- a/Documentation/hwmon/pcf8591
+++ b/Documentation/hwmon/pcf8591
@@ -4,7 +4,7 @@ Kernel driver pcf8591
 Supported chips:
  * Philips/NXP PCF8591
    Prefix: 'pcf8591'
-    Addresses scanned: I2C 0x48 - 0x4f
+    Addresses scanned: none
    Datasheet: Publicly available at the NXP website
               http://www.nxp.com/pip/PCF8591_6.html
@@ -58,18 +58,16 @@ Module parameters
 Accessing PCF8591 via /sys interface
 -------------------------------------
-! Be careful !
+The PCF8591 is plainly impossible to detect! Thus the driver won't even
-The PCF8591 is plainly impossible to detect! Stupid chip.
+try. You have to explicitly instantiate the device at the relevant
-So every chip with address in the interval [0x48..0x4f] is
+address (in the interval [0x48..0x4f]) either through platform data, or
-detected as PCF8591. If you have other chips in this address
+using the sysfs interface. See Documentation/i2c/instantiating-devices
-range, the workaround is to load this module after the one
+for details.
-for your others chips.
-On detection (i.e. insmod, modprobe et al.), directories are being
+Directories are being created for each instantiated PCF8591:
-created for each detected PCF8591:
 /sys/bus/i2c/devices/<0>-<1>/
-where <0> is the bus the chip was detected on (e. g. i2c-0)
+where <0> is the bus the chip is connected to (e. g. i2c-0)
 and <1> the chip address ([48..4f])
 Inside these directories, there are such files:
diff --git a/Documentation/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 48ceabedf55d..645699010551 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -309,6 +309,20 @@ temp[1-*]_crit_hyst
                from the critical value.
                RW
+temp[1-*]_emergency
+                Temperature emergency max value, for chips supporting more than
+                two upper temperature limits. Must be equal or greater than
+                corresponding temp_crit values.
+                Unit: millidegree Celsius
+                RW
+temp[1-*]_emergency_hyst
+                Temperature hysteresis value for emergency limit.
+                Unit: millidegree Celsius
+                Must be reported as an absolute temperature, NOT a delta
+                from the emergency value.
+                RW
 temp[1-*]_lcrit Temperature critical min value, typically lower than
                corresponding temp_min values.
                Unit: millidegree Celsius
@@ -505,6 +519,7 @@ fan[1-*]_max_alarm
 temp[1-*]_min_alarm
 temp[1-*]_max_alarm
 temp[1-*]_crit_alarm
+temp[1-*]_emergency_alarm
                Limit alarm
                0: no alarm
                1: alarm
diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt
index 33223ff121d8..63ffd78824d8 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -259,7 +259,7 @@ Code  Seq#(hex)	Include File		Comments
 't'     00-7F   linux/if_ppp.h
 't'     80-8F   linux/isdn_ppp.h
 't'     90      linux/toshiba.h
-'u'     00-1F   linux/smb_fs.h
+'u'     00-1F   linux/smb_fs.h          gone
 'v'     all     linux/videodev.h        conflict!
 'v'     00-1F   linux/ext2_fs.h         conflict!
 'v'     00-1F   linux/fs.h              conflict!
@@ -278,7 +278,6 @@ Code  Seq#(hex)	Include File		Comments
                                        <mailto:oe@port.de>
 'z'     10-4F   drivers/s390/crypto/zcrypt_api.h        conflict!
 0x80    00-1F   linux/fb.h
-0x81    00-1F   linux/videotext.h
 0x88    00-3F   media/ovcamchip.h
 0x89    00-06   arch/x86/include/asm/sockios.h
 0x89    0B-DF   linux/sockios.h
diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt
index b472e4e0ba67..2fe93ca7c77c 100644
--- a/Documentation/kbuild/kconfig-language.txt
+++ b/Documentation/kbuild/kconfig-language.txt
@@ -322,7 +322,8 @@ mainmenu:
        "mainmenu" <prompt>
 This sets the config program's title bar if the config program chooses
-to use it.
+to use it. It should be placed at the top of the configuration, before any
+other statement.
 Kconfig hints
diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt
index c787ae512120..0ef00bd6e54d 100644
--- a/Documentation/kbuild/makefiles.txt
+++ b/Documentation/kbuild/makefiles.txt
@@ -776,6 +776,13 @@ This will delete the directory debian, including all subdirectories.
 Kbuild will assume the directories to be in the same relative path as the
 Makefile if no absolute path is specified (path does not start with '/').
+To exclude certain files from make clean, use the $(no-clean-files) variable.
+This is only a special case used in the top level Kbuild file:
+        Example:
+                #Kbuild
+                no-clean-files := $(bounds-file) $(offsets-file)
 Usually kbuild descends down in subdirectories due to "obj-* := dir/",
 but in the architecture makefiles where the kbuild infrastructure
 is not sufficient this sometimes needs to be explicit.
diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt
index 0767cf69c69e..3fb39e0116b4 100644
--- a/Documentation/kbuild/modules.txt
+++ b/Documentation/kbuild/modules.txt
@@ -1,215 +1,185 @@
+Building External Modules
-In this document you will find information about:
+This document describes how to build an out-of-tree kernel module.
- how to build external modules
- how to make your module use the kbuild infrastructure
- how kbuild will install a kernel
- how to install modules in a non-standard location
 === Table of Contents
        === 1 Introduction
-        === 2 How to build external modules
+        === 2 How to Build External Modules
-           --- 2.1 Building external modules
+           --- 2.1 Command Syntax
-           --- 2.2 Available targets
+           --- 2.2 Options
-           --- 2.3 Available options
+           --- 2.3 Targets
-           --- 2.4 Preparing the kernel tree for module build
+           --- 2.4 Building Separate Files
-           --- 2.5 Building separate files for a module
+        === 3. Creating a Kbuild File for an External Module
-        === 3. Example commands
+           --- 3.1 Shared Makefile
-        === 4. Creating a kbuild file for an external module
+           --- 3.2 Separate Kbuild file and Makefile
-        === 5. Include files
+           --- 3.3 Binary Blobs
-           --- 5.1 How to include files from the kernel include dir
+           --- 3.4 Building Multiple Modules
-           --- 5.2 External modules using an include/ dir
+        === 4. Include Files
-           --- 5.3 External modules using several directories
+           --- 4.1 Kernel Includes
-        === 6. Module installation
+           --- 4.2 Single Subdirectory
-           --- 6.1 INSTALL_MOD_PATH
+           --- 4.3 Several Subdirectories
-           --- 6.2 INSTALL_MOD_DIR
+        === 5. Module Installation
-        === 7. Module versioning & Module.symvers
+           --- 5.1 INSTALL_MOD_PATH
-           --- 7.1 Symbols from the kernel (vmlinux + modules)
+           --- 5.2 INSTALL_MOD_DIR
-           --- 7.2 Symbols and external modules
+        === 6. Module Versioning
-           --- 7.3 Symbols from another external module
+           --- 6.1 Symbols From the Kernel (vmlinux + modules)
-        === 8. Tips & Tricks
+           --- 6.2 Symbols and External Modules
-           --- 8.1 Testing for CONFIG_FOO_BAR
+           --- 6.3 Symbols From Another External Module
+        === 7. Tips & Tricks
+           --- 7.1 Testing for CONFIG_FOO_BAR
 === 1. Introduction
-kbuild includes functionality for building modules both
+"kbuild" is the build system used by the Linux kernel. Modules must use
-within the kernel source tree and outside the kernel source tree.
+kbuild to stay compatible with changes in the build infrastructure and
-The latter is usually referred to as external or "out-of-tree"
+to pick up the right flags to "gcc." Functionality for building modules
-modules and is used both during development and for modules that
+both in-tree and out-of-tree is provided. The method for building
-are not planned to be included in the kernel tree.
+either is similar, and all modules are initially developed and built
+out-of-tree.
-What is covered within this file is mainly information to authors
+Covered in this document is information aimed at developers interested
-of modules. The author of an external module should supply
+in building out-of-tree (or "external") modules. The author of an
-a makefile that hides most of the complexity, so one only has to type
+external module should supply a makefile that hides most of the
-'make' to build the module. A complete example will be presented in
+complexity, so one only has to type "make" to build the module. This is
-chapter 4, "Creating a kbuild file for an external module".
+easily accomplished, and a complete example will be presented in
+section 3.
-=== 2. How to build external modules
+=== 2. How to Build External Modules
-kbuild offers functionality to build external modules, with the
+To build external modules, you must have a prebuilt kernel available
-prerequisite that there is a pre-built kernel available with full source.
+that contains the configuration and header files used in the build.
-A subset of the targets available when building the kernel is available
+Also, the kernel must have been built with modules enabled. If you are
-when building an external module.
+using a distribution kernel, there will be a package for the kernel you
+are running provided by your distribution.
--- 2.1 Building external modules
+An alternative is to use the "make" target "modules_prepare." This will
+make sure the kernel contains the information required. The target
+exists solely as a simple way to prepare a kernel source tree for
+building external modules.
-        Use the following command to build an external module:
+NOTE: "modules_prepare" will not build Module.symvers even if
+CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
+executed to make module versioning work.
-                make -C <path-to-kernel> M=`pwd`
+--- 2.1 Command Syntax
-        For the running kernel use:
+        The command to build an external module is:
-                make -C /lib/modules/`uname -r`/build M=`pwd`
+                $ make -C <path_to_kernel_src> M=$PWD
-        For the above command to succeed, the kernel must have been
+        The kbuild system knows that an external module is being built
-        built with modules enabled.
+        due to the "M=<dir>" option given in the command.
-        To install the modules that were just built:
+        To build against the running kernel use:
-                make -C <path-to-kernel> M=`pwd` modules_install
+                $ make -C /lib/modules/`uname -r`/build M=$PWD
-        More complex examples will be shown later, the above should
+        Then to install the module(s) just built, add the target
-        be enough to get you started.
+        "modules_install" to the command:
--- 2.2 Available targets
+                $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install
-        $KDIR refers to the path to the kernel source top-level directory
+--- 2.2 Options
-        make -C $KDIR M=`pwd`
+        ($KDIR refers to the path of the kernel source directory.)
-                Will build the module(s) located in current directory.
-                All output files will be located in the same directory
-                as the module source.
-                No attempts are made to update the kernel source, and it is
-                a precondition that a successful make has been executed
-                for the kernel.
-        make -C $KDIR M=`pwd` modules
+        make -C $KDIR M=$PWD
-                The modules target is implied when no target is given.
-                Same functionality as if no target was specified.
-                See description above.
-        make -C $KDIR M=`pwd` modules_install
+        -C $KDIR
-                Install the external module(s).
+                The directory where the kernel source is located.
-                Installation default is in /lib/modules/<kernel-version>/extra,
+                "make" will actually change to the specified directory
-                but may be prefixed with INSTALL_MOD_PATH - see separate
+                when executing and will change back when finished.
-                chapter.
-        make -C $KDIR M=`pwd` clean
+        M=$PWD
-                Remove all generated files for the module - the kernel
+                Informs kbuild that an external module is being built.
-                source directory is not modified.
+                The value given to "M" is the absolute path of the
+                directory where the external module (kbuild file) is
+                located.
-        make -C $KDIR M=`pwd` help
+--- 2.3 Targets
-                help will list the available target when building external
-                modules.
--- 2.3 Available options:
+        When building an external module, only a subset of the "make"
+        targets are available.
-        $KDIR refers to the path to the kernel source top-level directory
+        make -C $KDIR M=$PWD [target]
-        make -C $KDIR
+        The default will build the module(s) located in the current
-                Used to specify where to find the kernel source.
+        directory, so a target does not need to be specified. All
-                '$KDIR' represent the directory where the kernel source is.
+        output files will also be generated in this directory. No
-                Make will actually change directory to the specified directory
+        attempts are made to update the kernel source, and it is a
-                when executed but change back when finished.
+        precondition that a successful "make" has been executed for the
+        kernel.
-        make -C $KDIR M=`pwd`
+        modules
-                M= is used to tell kbuild that an external module is
+                The default target for external modules. It has the
-                being built.
+                same functionality as if no target was specified. See
-                The option given to M= is the directory where the external
+                description above.
-                module (kbuild file) is located.
-                When an external module is being built only a subset of the
-                usual targets are available.
-        make -C $KDIR SUBDIRS=`pwd`
+        modules_install
-                Same as M=. The SUBDIRS= syntax is kept for backwards
+                Install the external module(s). The default location is
-                compatibility.
+                /lib/modules/<kernel_release>/extra/, but a prefix may
+                be added with INSTALL_MOD_PATH (discussed in section 5).
--- 2.4 Preparing the kernel tree for module build
+        clean
+                Remove all generated files in the module directory only.
-        To make sure the kernel contains the information required to
+        help
-        build external modules the target 'modules_prepare' must be used.
+                List the available targets for external modules.
-        'modules_prepare' exists solely as a simple way to prepare
-        a kernel source tree for building external modules.
-        Note: modules_prepare will not build Module.symvers even if
-        CONFIG_MODVERSIONS is set. Therefore a full kernel build
-        needs to be executed to make module versioning work.
--- 2.5 Building separate files for a module
+--- 2.4 Building Separate Files
-        It is possible to build single files which are part of a module.
-        This works equally well for the kernel, a module and even for
-        external modules.
-        Examples (module foo.ko, consist of bar.o, baz.o):
-                make -C $KDIR M=`pwd` bar.lst
-                make -C $KDIR M=`pwd` bar.o
-                make -C $KDIR M=`pwd` foo.ko
-                make -C $KDIR M=`pwd` /
-=== 3. Example commands
-This example shows the actual commands to be executed when building
-an external module for the currently running kernel.
-In the example below, the distribution is supposed to use the
-facility to locate output files for a kernel compile in a different
-directory than the kernel source - but the examples will also work
-when the source and the output files are mixed in the same directory.
-# Kernel source
+        It is possible to build single files that are part of a module.
-/lib/modules/<kernel-version>/source -> /usr/src/linux-<version>
+        This works equally well for the kernel, a module, and even for
+        external modules.
-# Output from kernel compile
-/lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up
-Change to the directory where the kbuild file is located and execute
-the following commands to build the module:
-        cd /home/user/src/module
+        Example (The module foo.ko, consist of bar.o and baz.o):
-        make -C /usr/src/`uname -r`/source            \
+                make -C $KDIR M=$PWD bar.lst
-                O=/lib/modules/`uname-r`/build        \
+                make -C $KDIR M=$PWD baz.o
-                M=`pwd`
+                make -C $KDIR M=$PWD foo.ko
+                make -C $KDIR M=$PWD /
-Then, to install the module use the following command:
-        make -C /usr/src/`uname -r`/source            \
+=== 3. Creating a Kbuild File for an External Module
-                O=/lib/modules/`uname-r`/build        \
-                M=`pwd`                               \
-                modules_install
-If you look closely you will see that this is the same command as
+In the last section we saw the command to build a module for the
-listed before - with the directories spelled out.
+running kernel. The module is not actually built, however, because a
+build file is required. Contained in this file will be the name of
+the module(s) being built, along with the list of requisite source
+files. The file may be as simple as a single line:
-The above are rather long commands, and the following chapter
+        obj-m := <module_name>.o
-lists a few tricks to make it all easier.
+The kbuild system will build <module_name>.o from <module_name>.c,
+and, after linking, will result in the kernel module <module_name>.ko.
+The above line can be put in either a "Kbuild" file or a "Makefile."
+When the module is built from multiple sources, an additional line is
+needed listing the files:
-=== 4. Creating a kbuild file for an external module
+        <module_name>-y := <src1>.o <src2>.o ...
-kbuild is the build system for the kernel, and external modules
+NOTE: Further documentation describing the syntax used by kbuild is
-must use kbuild to stay compatible with changes in the build system
+located in Documentation/kbuild/makefiles.txt.
-and to pick up the right flags to gcc etc.
-The kbuild file used as input shall follow the syntax described
+The examples below demonstrate how to create a build file for the
-in Documentation/kbuild/makefiles.txt. This chapter will introduce a few
+module 8123.ko, which is built from the following files:
-more tricks to be used when dealing with external modules.
-In the following a Makefile will be created for a module with the
-following files:
        8123_if.c
        8123_if.h
        8123_pci.c
        8123_bin.o_shipped      <= Binary blob
--- 4.1 Shared Makefile for module and kernel
+--- 3.1 Shared Makefile
-        An external module always includes a wrapper Makefile supporting
+        An external module always includes a wrapper makefile that
-        building the module using 'make' with no arguments.
+        supports building the module using "make" with no arguments.
-        The Makefile provided will most likely include additional
+        This target is not used by kbuild; it is only for convenience.
-        functionality such as test targets etc. and this part shall
+        Additional functionality, such as test targets, can be included
-        be filtered away from kbuild since it may impact kbuild if
+        but should be filtered out from kbuild due to possible name
-        name clashes occurs.
+        clashes.
        Example 1:
                --> filename: Makefile
@@ -219,11 +189,11 @@ following files:
                8123-y := 8123_if.o 8123_pci.o 8123_bin.o
                else
-                # Normal Makefile
+                # normal makefile
+                KDIR ?= /lib/modules/`uname -r`/build
-                KERNELDIR := /lib/modules/`uname -r`/build
+                default:
-                all::
+                        $(MAKE) -C $(KDIR) M=$$PWD
-                        $(MAKE) -C $(KERNELDIR) M=`pwd` $@
                # Module specific targets
                genbin:
@@ -231,15 +201,20 @@ following files:
                endif
-        In example 1, the check for KERNELRELEASE is used to separate
+        The check for KERNELRELEASE is used to separate the two parts
-        the two parts of the Makefile. kbuild will only see the two
+        of the makefile. In the example, kbuild will only see the two
-        assignments whereas make will see everything except the two
+        assignments, whereas "make" will see everything except these
-        kbuild assignments.
+        two assignments. This is due to two passes made on the file:
+        the first pass is by the "make" instance run on the command
+        line; the second pass is by the kbuild system, which is
+        initiated by the parameterized "make" in the default target.
+--- 3.2 Separate Kbuild File and Makefile
-        In recent versions of the kernel, kbuild will look for a file named
+        In newer versions of the kernel, kbuild will first look for a
-        Kbuild and as second option look for a file named Makefile.
+        file named "Kbuild," and only if that is not found, will it
-        Utilising the Kbuild file makes us split up the Makefile in example 1
+        then look for a makefile. Utilizing a "Kbuild" file allows us
-        into two files as shown in example 2:
+        to split up the makefile from example 1 into two files:
        Example 2:
                --> filename: Kbuild
@@ -247,20 +222,21 @@ following files:
                8123-y := 8123_if.o 8123_pci.o 8123_bin.o
                --> filename: Makefile
-                KERNELDIR := /lib/modules/`uname -r`/build
+                KDIR ?= /lib/modules/`uname -r`/build
-                all::
-                        $(MAKE) -C $(KERNELDIR) M=`pwd` $@
+                default:
+                        $(MAKE) -C $(KDIR) M=$$PWD
                # Module specific targets
                genbin:
                        echo "X" > 8123_bin.o_shipped
+        The split in example 2 is questionable due to the simplicity of
+        each file; however, some external modules use makefiles
+        consisting of several hundred lines, and here it really pays
+        off to separate the kbuild part from the rest.
-        In example 2, we are down to two fairly simple files and for simple
+        The next example shows a backward compatible version.
-        files as used in this example the split is questionable. But some
-        external modules use Makefiles of several hundred lines and here it
-        really pays off to separate the kbuild part from the rest.
-        Example 3 shows a backward compatible version.
        Example 3:
                --> filename: Kbuild
@@ -269,13 +245,15 @@ following files:
                --> filename: Makefile
                ifneq ($(KERNELRELEASE),)
+                # kbuild part of makefile
                include Kbuild
                else
-                # Normal Makefile
+                # normal makefile
+                KDIR ?= /lib/modules/`uname -r`/build
-                KERNELDIR := /lib/modules/`uname -r`/build
+                default:
-                all::
+                        $(MAKE) -C $(KDIR) M=$$PWD
-                        $(MAKE) -C $(KERNELDIR) M=`pwd` $@
                # Module specific targets
                genbin:
@@ -283,260 +261,271 @@ following files:
                endif
-        The trick here is to include the Kbuild file from Makefile, so
+        Here the "Kbuild" file is included from the makefile. This
-        if an older version of kbuild picks up the Makefile, the Kbuild
+        allows an older version of kbuild, which only knows of
-        file will be included.
+        makefiles, to be used when the "make" and kbuild parts are
+        split into separate files.
--- 4.2 Binary blobs included in a module
+--- 3.3 Binary Blobs
-        Some external modules needs to include a .o as a blob. kbuild
+        Some external modules need to include an object file as a blob.
-        has support for this, but requires the blob file to be named
+        kbuild has support for this, but requires the blob file to be
-        <filename>_shipped. In our example the blob is named
+        named <filename>_shipped. When the kbuild rules kick in, a copy
-        8123_bin.o_shipped and when the kbuild rules kick in the file
+        of <filename>_shipped is created with _shipped stripped off,
-        8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file
+        giving us <filename>. This shortened filename can be used in
-        with the _shipped part stripped of the filename.
+        the assignment to the module.
-        This allows the 8123_bin.o filename to be used in the assignment to
-        the module.
+        Throughout this section, 8123_bin.o_shipped has been used to
+        build the kernel module 8123.ko; it has been included as
+        8123_bin.o.
-        Example 4:
-                obj-m  := 8123.o
                8123-y := 8123_if.o 8123_pci.o 8123_bin.o
-        In example 4, there is no distinction between the ordinary .c/.h files
+        Although there is no distinction between the ordinary source
-        and the binary file. But kbuild will pick up different rules to create
+        files and the binary file, kbuild will pick up different rules
-        the .o file.
+        when creating the object file for the module.
+--- 3.4 Building Multiple Modules
+        kbuild supports building multiple modules with a single build
+        file. For example, if you wanted to build two modules, foo.ko
+        and bar.ko, the kbuild lines would be:
-=== 5. Include files
+                obj-m := foo.o bar.o
+                foo-y := <foo_srcs>
+                bar-y := <bar_srcs>
-Include files are a necessity when a .c file uses something from other .c
+        It is that simple!
-files (not strictly in the sense of C, but if good programming practice is
-used). Any module that consists of more than one .c file will have a .h file
-for one of the .c files.
- If the .h file only describes a module internal interface, then the .h file
-  shall be placed in the same directory as the .c files.
- If the .h files describe an interface used by other parts of the kernel
-  located in different directories, the .h files shall be located in
-  include/linux/ or other include/ directories as appropriate.
-One exception for this rule is larger subsystems that have their own directory
+=== 4. Include Files
-under include/ such as include/scsi. Another exception is arch-specific
-.h files which are located under include/asm-$(ARCH)/*.
-External modules have a tendency to locate include files in a separate include/
+Within the kernel, header files are kept in standard locations
-directory and therefore need to deal with this in their kbuild file.
+according to the following rule:
--- 5.1 How to include files from the kernel include dir
+        * If the header file only describes the internal interface of a
+          module, then the file is placed in the same directory as the
+          source files.
+        * If the header file describes an interface used by other parts
+          of the kernel that are located in different directories, then
+          the file is placed in include/linux/.
-        When a module needs to include a file from include/linux/, then one
+          NOTE: There are two notable exceptions to this rule: larger
-        just uses:
+          subsystems have their own directory under include/, such as
+          include/scsi; and architecture specific headers are located
+          under arch/$(ARCH)/include/.
-                #include <linux/modules.h>
+--- 4.1 Kernel Includes
-        kbuild will make sure to add options to gcc so the relevant
+        To include a header file located under include/linux/, simply
-        directories are searched.
+        use:
-        Likewise for .h files placed in the same directory as the .c file.
-                #include "8123_if.h"
+                #include <linux/module.h>
-        will do the job.
+        kbuild will add options to "gcc" so the relevant directories
+        are searched.
--- 5.2 External modules using an include/ dir
+--- 4.2 Single Subdirectory
-        External modules often locate their .h files in a separate include/
+        External modules tend to place header files in a separate
-        directory although this is not usual kernel style. When an external
+        include/ directory where their source is located, although this
-        module uses an include/ dir then kbuild needs to be told so.
+        is not the usual kernel style. To inform kbuild of the
-        The trick here is to use either EXTRA_CFLAGS (take effect for all .c
+        directory, use either ccflags-y or CFLAGS_<filename>.o.
-        files) or CFLAGS_$F.o (take effect only for a single file).
-        In our example, if we move 8123_if.h to a subdirectory named include/
+        Using the example from section 3, if we moved 8123_if.h to a
-        the resulting Kbuild file would look like:
+        subdirectory named include, the resulting kbuild file would
+        look like:
                --> filename: Kbuild
-                obj-m  := 8123.o
+                obj-m := 8123.o
-                EXTRA_CFLAGS := -Iinclude
+                ccflags-y := -Iinclude
                8123-y := 8123_if.o 8123_pci.o 8123_bin.o
-        Note that in the assignment there is no space between -I and the path.
+        Note that in the assignment there is no space between -I and
-        This is a kbuild limitation:  there must be no space present.
+        the path. This is a limitation of kbuild: there must be no
+        space present.
--- 5.3 External modules using several directories
+--- 4.3 Several Subdirectories
-        If an external module does not follow the usual kernel style, but
-        decides to spread files over several directories, then kbuild can
-        handle this too.
+        kbuild can handle files that are spread over several directories.
        Consider the following example:
-        |
+        .
-        +- src/complex_main.c
+        |__ src
-        |   +- hal/hardwareif.c
+        |   |__ complex_main.c
-        |   +- hal/include/hardwareif.h
+        |   |__ hal
-        +- include/complex.h
+        |       |__ hardwareif.c
+        |       |__ include
-        To build a single module named complex.ko, we then need the following
+        |           |__ hardwareif.h
+        |__ include
+            |__ complex.h
+        To build the module complex.ko, we then need the following
        kbuild file:
-        Kbuild:
+                --> filename: Kbuild
                obj-m := complex.o
                complex-y := src/complex_main.o
                complex-y += src/hal/hardwareif.o
-                EXTRA_CFLAGS := -I$(src)/include
+                ccflags-y := -I$(src)/include
-                EXTRA_CFLAGS += -I$(src)src/hal/include
+                ccflags-y += -I$(src)/src/hal/include
+        As you can see, kbuild knows how to handle object files located
+        in other directories. The trick is to specify the directory
+        relative to the kbuild file's location. That being said, this
+        is NOT recommended practice.
-        kbuild knows how to handle .o files located in another directory -
+        For the header files, kbuild must be explicitly told where to
-        although this is NOT recommended practice. The syntax is to specify
+        look. When kbuild executes, the current directory is always the
-        the directory relative to the directory where the Kbuild file is
+        root of the kernel tree (the argument to "-C") and therefore an
-        located.
+        absolute path is needed. $(src) provides the absolute path by
+        pointing to the directory where the currently executing kbuild
+        file is located.
-        To find the .h files, we have to explicitly tell kbuild where to look
-        for the .h files. When kbuild executes, the current directory is always
-        the root of the kernel tree (argument to -C) and therefore we have to
-        tell kbuild how to find the .h files using absolute paths.
-        $(src) will specify the absolute path to the directory where the
-        Kbuild file are located when being build as an external module.
-        Therefore -I$(src)/ is used to point out the directory of the Kbuild
-        file and any additional path are just appended.
-=== 6. Module installation
+=== 5. Module Installation
-Modules which are included in the kernel are installed in the directory:
+Modules which are included in the kernel are installed in the
+directory:
-        /lib/modules/$(KERNELRELEASE)/kernel
+        /lib/modules/$(KERNELRELEASE)/kernel/
-External modules are installed in the directory:
+And external modules are installed in:
-        /lib/modules/$(KERNELRELEASE)/extra
+        /lib/modules/$(KERNELRELEASE)/extra/
--- 6.1 INSTALL_MOD_PATH
+--- 5.1 INSTALL_MOD_PATH
-        Above are the default directories, but as always, some level of
+        Above are the default directories but as always some level of
-        customization is possible. One can prefix the path using the variable
+        customization is possible. A prefix can be added to the
-        INSTALL_MOD_PATH:
+        installation path using the variable INSTALL_MOD_PATH:
                $ make INSTALL_MOD_PATH=/frodo modules_install
-                => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel
+                => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/
-        INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the
-        example above, can be specified on the command line when calling make.
-        INSTALL_MOD_PATH has effect both when installing modules included in
-        the kernel as well as when installing external modules.
--- 6.2 INSTALL_MOD_DIR
+        INSTALL_MOD_PATH may be set as an ordinary shell variable or,
+        as shown above, can be specified on the command line when
+        calling "make." This has effect when installing both in-tree
+        and out-of-tree modules.
-        When installing external modules they are by default installed to a
+--- 5.2 INSTALL_MOD_DIR
-        directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
-        to locate modules for a specific functionality in a separate
-        directory. For this purpose, one can use INSTALL_MOD_DIR to specify an
-        alternative name to 'extra'.
-                $ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
+        External modules are by default installed to a directory under
-                        M=`pwd` modules_install
+        /lib/modules/$(KERNELRELEASE)/extra/, but you may wish to
-                => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf
+        locate modules for a specific functionality in a separate
+        directory. For this purpose, use INSTALL_MOD_DIR to specify an
+        alternative name to "extra."
+                $ make INSTALL_MOD_DIR=gandalf -C $KDIR \
+                       M=$PWD modules_install
+                => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/
-=== 7. Module versioning & Module.symvers
-Module versioning is enabled by the CONFIG_MODVERSIONS tag.
+=== 6. Module Versioning
-Module versioning is used as a simple ABI consistency check. The Module
+Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
-versioning creates a CRC value of the full prototype for an exported symbol and
+as a simple ABI consistency check. A CRC value of the full prototype
-when a module is loaded/used then the CRC values contained in the kernel are
+for an exported symbol is created. When a module is loaded/used, the
-compared with similar values in the module. If they are not equal, then the
+CRC values contained in the kernel are compared with similar values in
-kernel refuses to load the module.
+the module; if they are not equal, the kernel refuses to load the
+module.
-Module.symvers contains a list of all exported symbols from a kernel build.
+Module.symvers contains a list of all exported symbols from a kernel
+build.
--- 7.1 Symbols from the kernel (vmlinux + modules)
+--- 6.1 Symbols From the Kernel (vmlinux + modules)
-        During a kernel build, a file named Module.symvers will be generated.
+        During a kernel build, a file named Module.symvers will be
-        Module.symvers contains all exported symbols from the kernel and
+        generated. Module.symvers contains all exported symbols from
-        compiled modules. For each symbols, the corresponding CRC value
+        the kernel and compiled modules. For each symbol, the
-        is stored too.
+        corresponding CRC value is also stored.
        The syntax of the Module.symvers file is:
-                <CRC>       <Symbol>           <module>
+                <CRC>       <Symbol>           <module>
-        Sample:
                0x2d036834  scsi_remove_host   drivers/scsi/scsi_mod
-        For a kernel build without CONFIG_MODVERSIONS enabled, the crc
+        For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
-        would read: 0x00000000
+        would read 0x00000000.
        Module.symvers serves two purposes:
-        1) It lists all exported symbols both from vmlinux and all modules
+        1) It lists all exported symbols from vmlinux and all modules.
-        2) It lists the CRC if CONFIG_MODVERSIONS is enabled
+        2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
--- 7.2 Symbols and external modules
+--- 6.2 Symbols and External Modules
-        When building an external module, the build system needs access to
+        When building an external module, the build system needs access
-        the symbols from the kernel to check if all external symbols are
+        to the symbols from the kernel to check if all external symbols
-        defined. This is done in the MODPOST step and to obtain all
+        are defined. This is done in the MODPOST step. modpost obtains
-        symbols, modpost reads Module.symvers from the kernel.
+        the symbols by reading Module.symvers from the kernel source
-        If a Module.symvers file is present in the directory where
+        tree. If a Module.symvers file is present in the directory
-        the external module is being built, this file will be read too.
+        where the external module is being built, this file will be
-        During the MODPOST step, a new Module.symvers file will be written
+        read too. During the MODPOST step, a new Module.symvers file
-        containing all exported symbols that were not defined in the kernel.
+        will be written containing all exported symbols that were not
+        defined in the kernel.
--- 7.3 Symbols from another external module
+--- 6.3 Symbols From Another External Module
-        Sometimes, an external module uses exported symbols from another
-        external module. Kbuild needs to have full knowledge on all symbols
+        Sometimes, an external module uses exported symbols from
-        to avoid spitting out warnings about undefined symbols.
+        another external module. kbuild needs to have full knowledge of
-        Three solutions exist to let kbuild know all symbols of more than
+        all symbols to avoid spitting out warnings about undefined
-        one external module.
+        symbols. Three solutions exist for this situation.
-        The method with a top-level kbuild file is recommended but may be
-        impractical in certain situations.
+        NOTE: The method with a top-level kbuild file is recommended
+        but may be impractical in certain situations.
-        Use a top-level Kbuild file
-                If you have two modules: 'foo' and 'bar', and 'foo' needs
+        Use a top-level kbuild file
-                symbols from 'bar', then one can use a common top-level kbuild
+                If you have two modules, foo.ko and bar.ko, where
-                file so both modules are compiled in same build.
+                foo.ko needs symbols from bar.ko, you can use a
+                common top-level kbuild file so both modules are
-                Consider following directory layout:
+                compiled in the same build. Consider the following
-                ./foo/ <= contains the foo module
+                directory layout:
-                ./bar/ <= contains the bar module
-                The top-level Kbuild file would then look like:
+                ./foo/ <= contains foo.ko
+                ./bar/ <= contains bar.ko
-                #./Kbuild: (this file may also be named Makefile)
+                The top-level kbuild file would then look like:
+                #./Kbuild (or ./Makefile):
                        obj-y := foo/ bar/
-                Executing:
+                And executing
-                        make -C $KDIR M=`pwd`
+                        $ make -C $KDIR M=$PWD
-                will then do the expected and compile both modules with full
+                will then do the expected and compile both modules with
-                knowledge on symbols from both modules.
+                full knowledge of symbols from either module.
        Use an extra Module.symvers file
-                When an external module is built, a Module.symvers file is
+                When an external module is built, a Module.symvers file
-                generated containing all exported symbols which are not
+                is generated containing all exported symbols which are
-                defined in the kernel.
+                not defined in the kernel. To get access to symbols
-                To get access to symbols from module 'bar', one can copy the
+                from bar.ko, copy the Module.symvers file from the
-                Module.symvers file from the compilation of the 'bar' module
+                compilation of bar.ko to the directory where foo.ko is
-                to the directory where the 'foo' module is built.
+                built. During the module build, kbuild will read the
-                During the module build, kbuild will read the Module.symvers
+                Module.symvers file in the directory of the external
-                file in the directory of the external module and when the
+                module, and when the build is finished, a new
-                build is finished, a new Module.symvers file is created
+                Module.symvers file is created containing the sum of
-                containing the sum of all symbols defined and not part of the
+                all symbols defined and not part of the kernel.
-                kernel.
+        Use "make" variable KBUILD_EXTRA_SYMBOLS
-        Use make variable KBUILD_EXTRA_SYMBOLS in the Makefile
+                If it is impractical to copy Module.symvers from
-                If it is impractical to copy Module.symvers from another
+                another module, you can assign a space separated list
-                module, you can assign a space separated list of files to
+                of files to KBUILD_EXTRA_SYMBOLS in your build file.
-                KBUILD_EXTRA_SYMBOLS in your Makfile. These files will be
+                These files will be loaded by modpost during the
-                loaded by modpost during the initialisation of its symbol
+                initialization of its symbol tables.
-                tables.
-=== 8. Tips & Tricks
+=== 7. Tips & Tricks
--- 8.1 Testing for CONFIG_FOO_BAR
+--- 7.1 Testing for CONFIG_FOO_BAR
-        Modules often need to check for certain CONFIG_ options to decide if
+        Modules often need to check for certain CONFIG_ options to
-        a specific feature shall be included in the module. When kbuild is used
+        decide if a specific feature is included in the module. In
-        this is done by referencing the CONFIG_ variable directly.
+        kbuild this is done by referencing the CONFIG_ variable
+        directly.
                #fs/ext2/Makefile
                obj-$(CONFIG_EXT2_FS) += ext2.o
@@ -544,9 +533,9 @@ Module.symvers contains a list of all exported symbols from a kernel build.
                ext2-y := balloc.o bitmap.o dir.o
                ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o
-        External modules have traditionally used grep to check for specific
+        External modules have traditionally used "grep" to check for
-        CONFIG_ settings directly in .config. This usage is broken.
+        specific CONFIG_ settings directly in .config. This usage is
-        As introduced before, external modules shall use kbuild when building
+        broken. As introduced before, external modules should use
-        and therefore can use the same methods as in-kernel modules when
+        kbuild for building and can therefore use the same methods as
-        testing for CONFIG_ definitions.
+        in-tree modules when testing for CONFIG_ definitions.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4bc2f3c3da5b..ed45e9802aa8 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2175,6 +2175,11 @@ and is between 256 and 4096 characters. It is defined in the file
        reset_devices   [KNL] Force drivers to reset the underlying device
                        during initialization.
+        resource_alloc_from_bottom
+                        Allocate new resources from the beginning of available
+                        space, not the end.  If you need to use this, please
+                        report a bug.
        resume=         [SWSUSP]
                        Specify the partition device for software suspend
diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt
index 88bb71b46da4..9eb1ba52013d 100644
--- a/Documentation/networking/phy.txt
+++ b/Documentation/networking/phy.txt
@@ -177,18 +177,6 @@ Doing it all yourself
 
   A convenience function to print out the PHY status neatly.
- int phy_clear_interrupt(struct phy_device *phydev);
- int phy_config_interrupt(struct phy_device *phydev, u32 interrupts);
-   
-   Clear the PHY's interrupt, and configure which ones are allowed,
-   respectively.  Currently only supports all on, or all off.
- 
- int phy_enable_interrupts(struct phy_device *phydev);
- int phy_disable_interrupts(struct phy_device *phydev);
-   Functions which enable/disable PHY interrupts, clearing them
-   before and after, respectively.
 int phy_start_interrupts(struct phy_device *phydev);
 int phy_stop_interrupts(struct phy_device *phydev);
@@ -213,12 +201,6 @@ Doing it all yourself
   Fills the phydev structure with up-to-date information about the current
   settings in the PHY.
- void phy_sanitize_settings(struct phy_device *phydev)
-   
-   Resolves differences between currently desired settings, and
-   supported settings for the given PHY device.  Does not make
-   the changes in the hardware, though.
 int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd);
 int phy_ethtool_gset(struct phy_device *phydev, struct ethtool_cmd *cmd);
diff --git a/Documentation/sysctl/vm.txt b/Documentation/sysctl/vm.txt
index b606c2c4dd37..30289fab86eb 100644
--- a/Documentation/sysctl/vm.txt
+++ b/Documentation/sysctl/vm.txt
@@ -80,8 +80,10 @@ dirty_background_bytes
 Contains the amount of dirty memory at which the pdflush background writeback
 daemon will start writeback.
-If dirty_background_bytes is written, dirty_background_ratio becomes a function
+Note: dirty_background_bytes is the counterpart of dirty_background_ratio. Only
-of its value (dirty_background_bytes / the amount of dirtyable system memory).
+one of them may be specified at a time. When one sysctl is written it is
+immediately taken into account to evaluate the dirty memory limits and the
+other appears as 0 when read.
 ==============================================================
@@ -97,8 +99,10 @@ dirty_bytes
 Contains the amount of dirty memory at which a process generating disk writes
 will itself start writeback.
-If dirty_bytes is written, dirty_ratio becomes a function of its value
+Note: dirty_bytes is the counterpart of dirty_ratio. Only one of them may be
-(dirty_bytes / the amount of dirtyable system memory).
+specified at a time. When one sysctl is written it is immediately taken into
+account to evaluate the dirty memory limits and the other appears as 0 when
+read.
 Note: the minimum value allowed for dirty_bytes is two pages (in bytes); any
 value lower than this limit will be ignored and the old configuration will be
diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88
index f2510541373b..42517d9121de 100644
--- a/Documentation/video4linux/CARDLIST.cx88
+++ b/Documentation/video4linux/CARDLIST.cx88
@@ -83,3 +83,4 @@
 82 -> WinFast DTV2000 H rev. J                            [107d:6f2b]
 83 -> Prof 7301 DVB-S/S2                                  [b034:3034]
 84 -> Samsung SMT 7020 DVB-S                              [18ac:dc00,18ac:dccd]
+ 85 -> Twinhan VP-1027 DVB-S                               [1822:0023]
diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx
index 5c568757c301..ac2616a62fc3 100644
--- a/Documentation/video4linux/CARDLIST.em28xx
+++ b/Documentation/video4linux/CARDLIST.em28xx
@@ -31,6 +31,7 @@
 30 -> Videology 20K14XUSB USB2.0               (em2820/em2840)
 31 -> Usbgear VD204v9                          (em2821)
 32 -> Supercomp USB 2.0 TV                     (em2821)
+ 33 -> Elgato Video Capture                     (em2860)        [0fd9:0033]
 34 -> Terratec Cinergy A Hybrid XS             (em2860)        [0ccd:004f]
 35 -> Typhoon DVD Maker                        (em2860)
 36 -> NetGMBH Cam                              (em2860)
@@ -45,7 +46,7 @@
 45 -> Pinnacle PCTV DVB-T                      (em2870)
 46 -> Compro, VideoMate U3                     (em2870)        [185b:2870]
 47 -> KWorld DVB-T 305U                        (em2880)        [eb1a:e305]
- 48 -> KWorld DVB-T 310U                        (em2880)        [eb1a:e310]
+ 48 -> KWorld DVB-T 310U                        (em2880)
 49 -> MSI DigiVox A/D                          (em2880)        [eb1a:e310]
 50 -> MSI DigiVox A/D II                       (em2880)        [eb1a:e320]
 51 -> Terratec Hybrid XS Secam                 (em2880)        [0ccd:004c]
diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134
index 4000c29fcfb6..8d9afc7d8014 100644
--- a/Documentation/video4linux/CARDLIST.saa7134
+++ b/Documentation/video4linux/CARDLIST.saa7134
@@ -126,7 +126,7 @@
 125 -> Beholder BeholdTV 409                    [0000:4090]
 126 -> Beholder BeholdTV 505 FM                 [5ace:5050]
 127 -> Beholder BeholdTV 507 FM / BeholdTV 509 FM [5ace:5070,5ace:5090]
-128 -> Beholder BeholdTV Columbus TVFM          [0000:5201]
+128 -> Beholder BeholdTV Columbus TV/FM         [0000:5201]
 129 -> Beholder BeholdTV 607 FM                 [5ace:6070]
 130 -> Beholder BeholdTV M6                     [5ace:6190]
 131 -> Twinhan Hybrid DTV-DVB 3056 PCI          [1822:0022]
diff --git a/Documentation/video4linux/bttv/MAKEDEV b/Documentation/video4linux/bttv/MAKEDEV
index 9d112f7fd5f7..093c0cd18042 100644
--- a/Documentation/video4linux/bttv/MAKEDEV
+++ b/Documentation/video4linux/bttv/MAKEDEV
@@ -19,7 +19,6 @@ function makedev () {
 echo "*** new device names ***"
 makedev video 0
 makedev radio 64
-makedev vtx 192
 makedev vbi 224
 #echo "*** old device names (for compatibility only) ***"
diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt
index 56ba7bba7168..6a562eeeb4cd 100644
--- a/Documentation/video4linux/gspca.txt
+++ b/Documentation/video4linux/gspca.txt
@@ -302,12 +302,14 @@ sonixj		0c45:60fb	Surfer NoName
 sonixj          0c45:60fc       LG-LIC300
 sonixj          0c45:60fe       Microdia Audio
 sonixj          0c45:6100       PC Camera (SN9C128)
+sonixj          0c45:6102       PC Camera (SN9C128)
 sonixj          0c45:610a       PC Camera (SN9C128)
 sonixj          0c45:610b       PC Camera (SN9C128)
 sonixj          0c45:610c       PC Camera (SN9C128)
 sonixj          0c45:610e       PC Camera (SN9C128)
 sonixj          0c45:6128       Microdia/Sonix SNP325
 sonixj          0c45:612a       Avant Camera
+sonixj          0c45:612b       Speed-Link REFLECT2
 sonixj          0c45:612c       Typhoon Rasy Cam 1.3MPix
 sonixj          0c45:6130       Sonix Pccam
 sonixj          0c45:6138       Sn9c120 Mo4000
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index e831aaca66f8..f22f35c271f3 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -44,8 +44,8 @@ All drivers have the following structure:
 2) A way of initializing and commanding sub-devices (if any).
-3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX, /dev/radioX and
+3) Creating V4L2 device nodes (/dev/videoX, /dev/vbiX and /dev/radioX)
-   /dev/vtxX) and keeping track of device-node specific data.
+   and keeping track of device-node specific data.
 4) Filehandle-specific structs containing per-filehandle data;
@@ -192,6 +192,11 @@ You also need a way to go from the low-level struct to v4l2_subdev. For the
 common i2c_client struct the i2c_set_clientdata() call is used to store a
 v4l2_subdev pointer, for other busses you may have to use other methods.
+Bridges might also need to store per-subdev private data, such as a pointer to
+bridge-specific per-subdev private data. The v4l2_subdev structure provides
+host private data for that purpose that can be accessed with
+v4l2_get_subdev_hostdata() and v4l2_set_subdev_hostdata().
 From the bridge driver perspective you load the sub-device module and somehow
 obtain the v4l2_subdev pointer. For i2c devices this is easy: you call
 i2c_get_clientdata(). For other busses something similar needs to be done.
@@ -448,6 +453,10 @@ You should also set these fields:
 - ioctl_ops: if you use the v4l2_ioctl_ops to simplify ioctl maintenance
  (highly recommended to use this and it might become compulsory in the
  future!), then set this to your v4l2_ioctl_ops struct.
+- lock: leave to NULL if you want to do all the locking in the driver.
+  Otherwise you give it a pointer to a struct mutex_lock and before any
+  of the v4l2_file_operations is called this lock will be taken by the
+  core and released afterwards.
 - parent: you only set this if v4l2_device was registered with NULL as
  the parent device struct. This only happens in cases where one hardware
  device has multiple PCI devices that all share the same v4l2_device core.
@@ -464,6 +473,22 @@ If you use v4l2_ioctl_ops, then you should set either .unlocked_ioctl or
 The v4l2_file_operations struct is a subset of file_operations. The main
 difference is that the inode argument is omitted since it is never used.
+v4l2_file_operations and locking
+--------------------------------
+You can set a pointer to a mutex_lock in struct video_device. Usually this
+will be either a top-level mutex or a mutex per device node. If you want
+finer-grained locking then you have to set it to NULL and do you own locking.
+If a lock is specified then all file operations will be serialized on that
+lock. If you use videobuf then you must pass the same lock to the videobuf
+queue initialize function: if videobuf has to wait for a frame to arrive, then
+it will temporarily unlock the lock and relock it afterwards. If your driver
+also waits in the code, then you should do the same to allow other processes
+to access the device node while the first process is waiting for something.
+The implementation of a hotplug disconnect should also take the lock before
+calling v4l2_device_disconnect.
 video_device registration
 -------------------------
@@ -483,7 +508,6 @@ types exist:
 VFL_TYPE_GRABBER: videoX for video input/output devices
 VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
 VFL_TYPE_RADIO: radioX for radio tuners
-VFL_TYPE_VTX: vtxX for teletext devices (deprecated, don't use)
 The last argument gives you a certain amount of control over the device
 device node number used (i.e. the X in videoX). Normally you will pass -1
@@ -547,9 +571,8 @@ from /dev).
 After video_unregister_device() returns no new opens can be done. However,
 in the case of USB devices some application might still have one of these
-device nodes open. So after the unregister all file operations will return
+device nodes open. So after the unregister all file operations (except
-an error as well, except for the ioctl and unlocked_ioctl file operations:
+release, of course) will return an error as well.
-those will still be passed on since some buffer ioctls may still be needed.
 When the last user of the video device node exits, then the vdev->release()
 callback is called and you can do the final cleanup there.