65 files changed, 2023 insertions, 491 deletions

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index c17cd4bb2290..1b777b960492 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -328,8 +328,6 @@ sysrq.txt
         - info on the magic SysRq key.
 telephony/
         - directory with info on telephony (e.g. voice over IP) support.
-uml/
-        - directory with information about User Mode Linux.
 unicode.txt
         - info on the Unicode character/font mapping used in Linux.
 unshare.txt
diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
index 7564e88bfa43..e7be75b96e4b 100644
--- a/Documentation/ABI/testing/sysfs-devices-system-cpu
+++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
@@ -183,21 +183,21 @@ Description:	Discover and change clock speed of CPUs
                 to learn how to control the knobs.
 
 
-What:      /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
-Date:      August 2008
+What:           /sys/devices/system/cpu/cpu*/cache/index3/cache_disable_{0,1}
+Date:           August 2008
 KernelVersion:  2.6.27
-Contact:        mark.langsdorf@amd.com
-Description:    These files exist in every cpu's cache index directories.
-                There are currently 2 cache_disable_# files in each
-                directory.  Reading from these files on a supported
-                processor will return that cache disable index value
-                for that processor and node.  Writing to one of these
-                files will cause the specificed cache index to be disabled.
-
-                Currently, only AMD Family 10h Processors support cache index
-                disable, and only for their L3 caches.  See the BIOS and
-                Kernel Developer's Guide at
-                http://support.amd.com/us/Embedded_TechDocs/31116-Public-GH-BKDG_3-28_5-28-09.pdf       
-                for formatting information and other details on the
-                cache index disable.
-Users:    joachim.deguara@amd.com
+Contact:        discuss@x86-64.org
+Description:    Disable L3 cache indices
+
+                These files exist in every CPU's cache/index3 directory. Each
+                cache_disable_{0,1} file corresponds to one disable slot which
+                can be used to disable a cache index. Reading from these files
+                on a processor with this functionality will return the currently
+                disabled index for that node. There is one L3 structure per
+                node, or per internal node on MCM machines. Writing a valid
+                index to one of these files will cause the specificed cache
+                index to be disabled.
+
+                All AMD processors with L3 caches provide this functionality.
+                For details, see BKDGs at
+                http://developer.amd.com/documentation/guides/Pages/default.aspx
diff --git a/Documentation/ABI/testing/sysfs-firmware-dmi b/Documentation/ABI/testing/sysfs-firmware-dmi
index ba9da9503c23..c78f9ab01e56 100644
--- a/Documentation/ABI/testing/sysfs-firmware-dmi
+++ b/Documentation/ABI/testing/sysfs-firmware-dmi
@@ -14,14 +14,15 @@ Description:
 
                 DMI is structured as a large table of entries, where
                 each entry has a common header indicating the type and
-                length of the entry, as well as 'handle' that is
-                supposed to be unique amongst all entries.
+                length of the entry, as well as a firmware-provided
+                'handle' that is supposed to be unique amongst all
+                entries.
 
                 Some entries are required by the specification, but many
                 others are optional.  In general though, users should
                 never expect to find a specific entry type on their
                 system unless they know for certain what their firmware
-                is doing.  Machine to machine will vary.
+                is doing.  Machine to machine experiences will vary.
 
                 Multiple entries of the same type are allowed.  In order
                 to handle these duplicate entry types, each entry is
@@ -67,25 +68,24 @@ Description:
                           and the two terminating nul characters.
                 type    : The type of the entry.  This value is the same
                           as found in the directory name.  It indicates
-                          how the rest of the entry should be
-                          interpreted.
+                          how the rest of the entry should be interpreted.
                 instance: The instance ordinal of the entry for the
                           given type.  This value is the same as found
                           in the parent directory name.
-                position: The position of the entry within the entirety
-                          of the entirety.
+                position: The ordinal position (zero-based) of the entry
+                          within the entirety of the DMI entry table.
 
                 === Entry Specialization ===
 
                 Some entry types may have other information available in
-                sysfs.
+                sysfs.  Not all types are specialized.
 
                 --- Type 15 - System Event Log ---
 
                 This entry allows the firmware to export a log of
                 events the system has taken.  This information is
                 typically backed by nvram, but the implementation
-                details are abstracted by this table.  This entries data
+                details are abstracted by this table.  This entry's data
                 is exported in the directory:
 
                 /sys/firmware/dmi/entries/15-0/system_event_log
diff --git a/Documentation/ABI/testing/sysfs-firmware-gsmi b/Documentation/ABI/testing/sysfs-firmware-gsmi
new file mode 100644
index 000000000000..0faa0aaf4b6a
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-gsmi
@@ -0,0 +1,58 @@
+What:           /sys/firmware/gsmi
+Date:           March 2011
+Contact:        Mike Waychison <mikew@google.com>
+Description:
+                Some servers used internally at Google have firmware
+                that provides callback functionality via explicit SMI
+                triggers.  Some of the callbacks are similar to those
+                provided by the EFI runtime services page, but due to
+                historical reasons this different entry-point has been
+                used.
+
+                The gsmi driver implements the kernel's abstraction for
+                these firmware callbacks.  Currently, this functionality
+                is limited to handling the system event log and getting
+                access to EFI-style variables stored in nvram.
+
+                Layout:
+
+                /sys/firmware/gsmi/vars:
+
+                        This directory has the same layout (and
+                        underlying implementation as /sys/firmware/efi/vars.
+                        See Documentation/ABI/*/sysfs-firmware-efi-vars
+                        for more information on how to interact with
+                        this structure.
+
+                /sys/firmware/gsmi/append_to_eventlog - write-only:
+
+                        This file takes a binary blob and passes it onto
+                        the firmware to be timestamped and appended to
+                        the system eventlog.  The binary format is
+                        interpreted by the firmware and may change from
+                        platform to platform.  The only kernel-enforced
+                        requirement is that the blob be prefixed with a
+                        32bit host-endian type used as part of the
+                        firmware call.
+
+                /sys/firmware/gsmi/clear_config - write-only:
+
+                        Writing any value to this file will cause the
+                        entire firmware configuration to be reset to
+                        "factory defaults".  Callers should assume that
+                        a reboot is required for the configuration to be
+                        cleared.
+
+                /sys/firmware/gsmi/clear_eventlog - write-only:
+
+                        This file is used to clear out a portion/the
+                        whole of the system event log.  Values written
+                        should be values between 1 and 100 inclusive (in
+                        ASCII) representing the fraction of the log to
+                        clear.  Not all platforms support fractional
+                        clearing though, and this writes to this file
+                        will error out if the firmware doesn't like your
+                        submitted fraction.
+
+                        Callers should assume that a reboot is needed
+                        for this operation to complete.
diff --git a/Documentation/ABI/testing/sysfs-firmware-log b/Documentation/ABI/testing/sysfs-firmware-log
new file mode 100644
index 000000000000..9b58e7c5365f
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-firmware-log
@@ -0,0 +1,7 @@
+What:           /sys/firmware/log
+Date:           February 2011
+Contact:        Mike Waychison <mikew@google.com>
+Description:
+                The /sys/firmware/log is a binary file that represents a
+                read-only copy of the firmware's log if one is
+                available.
diff --git a/Documentation/ABI/testing/sysfs-kernel-fscaps b/Documentation/ABI/testing/sysfs-kernel-fscaps
new file mode 100644
index 000000000000..50a3033b5e15
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-kernel-fscaps
@@ -0,0 +1,8 @@
+What:           /sys/kernel/fscaps
+Date:           February 2011
+KernelVersion:  2.6.38
+Contact:        Ludwig Nussel <ludwig.nussel@suse.de>
+Description
+                Shows whether file system capabilities are honored
+                when executing a binary
+
diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power
index 194ca446ac28..b464d12761ba 100644
--- a/Documentation/ABI/testing/sysfs-power
+++ b/Documentation/ABI/testing/sysfs-power
@@ -158,3 +158,17 @@ Description:
                 successful, will make the kernel abort a subsequent transition
                 to a sleep state if any wakeup events are reported after the
                 write has returned.
+
+What:           /sys/power/reserved_size
+Date:           May 2011
+Contact:        Rafael J. Wysocki <rjw@sisk.pl>
+Description:
+                The /sys/power/reserved_size file allows user space to control
+                the amount of memory reserved for allocations made by device
+                drivers during the "device freeze" stage of hibernation.  It can
+                be written a string representing a non-negative integer that
+                will be used as the amount of memory to reserve for allocations
+                made by device drivers' "freeze" callbacks, in bytes.
+
+                Reading from this file will display the current value, which is
+                set to 1 MB by default.
diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl
index 36f63d4a0a06..b638e50cf8f6 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -96,10 +96,10 @@ X!Iinclude/linux/kobject.h
 
   <chapter id="devdrivers">
      <title>Device drivers infrastructure</title>
+     <sect1><title>The Basic Device Driver-Model Structures </title>
+!Iinclude/linux/device.h
+     </sect1>
      <sect1><title>Device Drivers Base</title>
-<!--
-X!Iinclude/linux/device.h
--->
 !Edrivers/base/driver.c
 !Edrivers/base/core.c
 !Edrivers/base/class.c
diff --git a/Documentation/DocBook/genericirq.tmpl b/Documentation/DocBook/genericirq.tmpl
index fb10fd08c05c..b3422341d65c 100644
--- a/Documentation/DocBook/genericirq.tmpl
+++ b/Documentation/DocBook/genericirq.tmpl
@@ -191,8 +191,8 @@
         <para>
         Whenever an interrupt triggers, the lowlevel arch code calls into
         the generic interrupt code by calling desc->handle_irq().
-        This highlevel IRQ handling function only uses desc->chip primitives
-        referenced by the assigned chip descriptor structure.
+        This highlevel IRQ handling function only uses desc->irq_data.chip
+        primitives referenced by the assigned chip descriptor structure.
         </para>
     </sect1>
     <sect1 id="Highlevel_Driver_API">
@@ -206,11 +206,11 @@
           <listitem><para>enable_irq()</para></listitem>
           <listitem><para>disable_irq_nosync() (SMP only)</para></listitem>
           <listitem><para>synchronize_irq() (SMP only)</para></listitem>
-          <listitem><para>set_irq_type()</para></listitem>
-          <listitem><para>set_irq_wake()</para></listitem>
-          <listitem><para>set_irq_data()</para></listitem>
-          <listitem><para>set_irq_chip()</para></listitem>
-          <listitem><para>set_irq_chip_data()</para></listitem>
+          <listitem><para>irq_set_irq_type()</para></listitem>
+          <listitem><para>irq_set_irq_wake()</para></listitem>
+          <listitem><para>irq_set_handler_data()</para></listitem>
+          <listitem><para>irq_set_chip()</para></listitem>
+          <listitem><para>irq_set_chip_data()</para></listitem>
           </itemizedlist>
           See the autogenerated function documentation for details.
         </para>
@@ -225,6 +225,8 @@
           <listitem><para>handle_fasteoi_irq</para></listitem>
           <listitem><para>handle_simple_irq</para></listitem>
           <listitem><para>handle_percpu_irq</para></listitem>
+          <listitem><para>handle_edge_eoi_irq</para></listitem>
+          <listitem><para>handle_bad_irq</para></listitem>
           </itemizedlist>
           The interrupt flow handlers (either predefined or architecture
           specific) are assigned to specific interrupts by the architecture
@@ -241,13 +243,13 @@
                 <programlisting>
 default_enable(struct irq_data *data)
 {
-        desc->chip->irq_unmask(data);
+        desc->irq_data.chip->irq_unmask(data);
 }
 
 default_disable(struct irq_data *data)
 {
         if (!delay_disable(data))
-                desc->chip->irq_mask(data);
+                desc->irq_data.chip->irq_mask(data);
 }
 
 default_ack(struct irq_data *data)
@@ -284,9 +286,9 @@ noop(struct irq_data *data))
                 <para>
                 The following control flow is implemented (simplified excerpt):
                 <programlisting>
-desc->chip->irq_mask();
-handle_IRQ_event(desc->action);
-desc->chip->irq_unmask();
+desc->irq_data.chip->irq_mask_ack();
+handle_irq_event(desc->action);
+desc->irq_data.chip->irq_unmask();
                 </programlisting>
                 </para>
             </sect3>
@@ -300,8 +302,8 @@ desc->chip->irq_unmask();
                 <para>
                 The following control flow is implemented (simplified excerpt):
                 <programlisting>
-handle_IRQ_event(desc->action);
-desc->chip->irq_eoi();
+handle_irq_event(desc->action);
+desc->irq_data.chip->irq_eoi();
                 </programlisting>
                 </para>
             </sect3>
@@ -315,17 +317,17 @@ desc->chip->irq_eoi();
                 The following control flow is implemented (simplified excerpt):
                 <programlisting>
 if (desc->status &amp; running) {
-        desc->chip->irq_mask();
+        desc->irq_data.chip->irq_mask_ack();
         desc->status |= pending | masked;
         return;
 }
-desc->chip->irq_ack();
+desc->irq_data.chip->irq_ack();
 desc->status |= running;
 do {
         if (desc->status &amp; masked)
-                desc->chip->irq_unmask();
+                desc->irq_data.chip->irq_unmask();
         desc->status &amp;= ~pending;
-        handle_IRQ_event(desc->action);
+        handle_irq_event(desc->action);
 } while (status &amp; pending);
 desc->status &amp;= ~running;
                 </programlisting>
@@ -344,7 +346,7 @@ desc->status &amp;= ~running;
                 <para>
                 The following control flow is implemented (simplified excerpt):
                 <programlisting>
-handle_IRQ_event(desc->action);
+handle_irq_event(desc->action);
                 </programlisting>
                 </para>
             </sect3>
@@ -362,12 +364,29 @@ handle_IRQ_event(desc->action);
                 <para>
                 The following control flow is implemented (simplified excerpt):
                 <programlisting>
-handle_IRQ_event(desc->action);
-if (desc->chip->irq_eoi)
-        desc->chip->irq_eoi();
+if (desc->irq_data.chip->irq_ack)
+        desc->irq_data.chip->irq_ack();
+handle_irq_event(desc->action);
+if (desc->irq_data.chip->irq_eoi)
+        desc->irq_data.chip->irq_eoi();
                 </programlisting>
                 </para>
             </sect3>
+            <sect3 id="EOI_Edge_IRQ_flow_handler">
+                <title>EOI Edge IRQ flow handler</title>
+                <para>
+                handle_edge_eoi_irq provides an abnomination of the edge
+                handler which is solely used to tame a badly wreckaged
+                irq controller on powerpc/cell.
+                </para>
+            </sect3>
+            <sect3 id="BAD_IRQ_flow_handler">
+                <title>Bad IRQ flow handler</title>
+                <para>
+                handle_bad_irq is used for spurious interrupts which
+                have no real handler assigned..
+                </para>
+            </sect3>
         </sect2>
         <sect2 id="Quirks_and_optimizations">
         <title>Quirks and optimizations</title>
@@ -410,6 +429,7 @@ if (desc->chip->irq_eoi)
           <listitem><para>irq_mask_ack() - Optional, recommended for performance</para></listitem>
           <listitem><para>irq_mask()</para></listitem>
           <listitem><para>irq_unmask()</para></listitem>
+          <listitem><para>irq_eoi() - Optional, required for eoi flow handlers</para></listitem>
           <listitem><para>irq_retrigger() - Optional</para></listitem>
           <listitem><para>irq_set_type() - Optional</para></listitem>
           <listitem><para>irq_set_wake() - Optional</para></listitem>
@@ -424,32 +444,24 @@ if (desc->chip->irq_eoi)
   <chapter id="doirq">
      <title>__do_IRQ entry point</title>
      <para>
-        The original implementation __do_IRQ() is an alternative entry
-        point for all types of interrupts.
+        The original implementation __do_IRQ() was an alternative entry
+        point for all types of interrupts. It not longer exists.
      </para>
      <para>
         This handler turned out to be not suitable for all
         interrupt hardware and was therefore reimplemented with split
-        functionality for egde/level/simple/percpu interrupts. This is not
+        functionality for edge/level/simple/percpu interrupts. This is not
         only a functional optimization. It also shortens code paths for
         interrupts.
       </para>
-      <para>
-        To make use of the split implementation, replace the call to
-        __do_IRQ by a call to desc->handle_irq() and associate
-        the appropriate handler function to desc->handle_irq().
-        In most cases the generic handler implementations should
-        be sufficient.
-     </para>
   </chapter>
 
   <chapter id="locking">
      <title>Locking on SMP</title>
      <para>
         The locking of chip registers is up to the architecture that
-        defines the chip primitives. There is a chip->lock field that can be used
-        for serialization, but the generic layer does not touch it. The per-irq
-        structure is protected via desc->lock, by the generic layer.
+        defines the chip primitives. The per-irq structure is
+        protected via desc->lock, by the generic layer.
      </para>
   </chapter>
   <chapter id="structs">
diff --git a/Documentation/DocBook/media-entities.tmpl b/Documentation/DocBook/media-entities.tmpl
index 5d259c632cdf..fea63b45471a 100644
--- a/Documentation/DocBook/media-entities.tmpl
+++ b/Documentation/DocBook/media-entities.tmpl
@@ -294,6 +294,7 @@
 <!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-y12 SYSTEM "v4l/pixfmt-y12.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">
diff --git a/Documentation/DocBook/v4l/media-ioc-setup-link.xml b/Documentation/DocBook/v4l/media-ioc-setup-link.xml
index 2331e76ded17..cec97af4dab4 100644
--- a/Documentation/DocBook/v4l/media-ioc-setup-link.xml
+++ b/Documentation/DocBook/v4l/media-ioc-setup-link.xml
@@ -34,7 +34,7 @@
       <varlistentry>
         <term><parameter>request</parameter></term>
         <listitem>
-          <para>MEDIA_IOC_ENUM_LINKS</para>
+          <para>MEDIA_IOC_SETUP_LINK</para>
         </listitem>
       </varlistentry>
       <varlistentry>
diff --git a/Documentation/DocBook/v4l/pixfmt-y12.xml b/Documentation/DocBook/v4l/pixfmt-y12.xml
new file mode 100644
index 000000000000..ff417b858cc9
--- /dev/null
+++ b/Documentation/DocBook/v4l/pixfmt-y12.xml
@@ -0,0 +1,79 @@
+<refentry id="V4L2-PIX-FMT-Y12">
+  <refmeta>
+    <refentrytitle>V4L2_PIX_FMT_Y12 ('Y12 ')</refentrytitle>
+    &manvol;
+  </refmeta>
+  <refnamediv>
+    <refname><constant>V4L2_PIX_FMT_Y12</constant></refname>
+    <refpurpose>Grey-scale image</refpurpose>
+  </refnamediv>
+  <refsect1>
+    <title>Description</title>
+
+    <para>This is a grey-scale image with a depth of 12 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_Y12</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 c6fdcbbd1b41..40af4beb48b9 100644
--- a/Documentation/DocBook/v4l/pixfmt.xml
+++ b/Documentation/DocBook/v4l/pixfmt.xml
@@ -696,6 +696,7 @@ information.</para>
     &sub-packed-yuv;
     &sub-grey;
     &sub-y10;
+    &sub-y12;
     &sub-y16;
     &sub-yuyv;
     &sub-uyvy;
diff --git a/Documentation/DocBook/v4l/subdev-formats.xml b/Documentation/DocBook/v4l/subdev-formats.xml
index 7041127d6dfc..d7ccd25edcc1 100644
--- a/Documentation/DocBook/v4l/subdev-formats.xml
+++ b/Documentation/DocBook/v4l/subdev-formats.xml
@@ -456,6 +456,23 @@
               <entry>b<subscript>1</subscript></entry>
               <entry>b<subscript>0</subscript></entry>
             </row>
+            <row id="V4L2-MBUS-FMT-SGBRG8-1X8">
+              <entry>V4L2_MBUS_FMT_SGBRG8_1X8</entry>
+              <entry>0x3013</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>g<subscript>7</subscript></entry>
+              <entry>g<subscript>6</subscript></entry>
+              <entry>g<subscript>5</subscript></entry>
+              <entry>g<subscript>4</subscript></entry>
+              <entry>g<subscript>3</subscript></entry>
+              <entry>g<subscript>2</subscript></entry>
+              <entry>g<subscript>1</subscript></entry>
+              <entry>g<subscript>0</subscript></entry>
+            </row>
             <row id="V4L2-MBUS-FMT-SGRBG8-1X8">
               <entry>V4L2_MBUS_FMT_SGRBG8_1X8</entry>
               <entry>0x3002</entry>
@@ -473,6 +490,23 @@
               <entry>g<subscript>1</subscript></entry>
               <entry>g<subscript>0</subscript></entry>
             </row>
+            <row id="V4L2-MBUS-FMT-SRGGB8-1X8">
+              <entry>V4L2_MBUS_FMT_SRGGB8_1X8</entry>
+              <entry>0x3014</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>r<subscript>7</subscript></entry>
+              <entry>r<subscript>6</subscript></entry>
+              <entry>r<subscript>5</subscript></entry>
+              <entry>r<subscript>4</subscript></entry>
+              <entry>r<subscript>3</subscript></entry>
+              <entry>r<subscript>2</subscript></entry>
+              <entry>r<subscript>1</subscript></entry>
+              <entry>r<subscript>0</subscript></entry>
+            </row>
             <row id="V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8">
               <entry>V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8</entry>
               <entry>0x300b</entry>
@@ -2159,6 +2193,31 @@
               <entry>u<subscript>1</subscript></entry>
               <entry>u<subscript>0</subscript></entry>
             </row>
+            <row id="V4L2-MBUS-FMT-Y12-1X12">
+              <entry>V4L2_MBUS_FMT_Y12_1X12</entry>
+              <entry>0x2013</entry>
+              <entry></entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>-</entry>
+              <entry>y<subscript>11</subscript></entry>
+              <entry>y<subscript>10</subscript></entry>
+              <entry>y<subscript>9</subscript></entry>
+              <entry>y<subscript>8</subscript></entry>
+              <entry>y<subscript>7</subscript></entry>
+              <entry>y<subscript>6</subscript></entry>
+              <entry>y<subscript>5</subscript></entry>
+              <entry>y<subscript>4</subscript></entry>
+              <entry>y<subscript>3</subscript></entry>
+              <entry>y<subscript>2</subscript></entry>
+              <entry>y<subscript>1</subscript></entry>
+              <entry>y<subscript>0</subscript></entry>
+            </row>
             <row id="V4L2-MBUS-FMT-UYVY8-1X16">
               <entry>V4L2_MBUS_FMT_UYVY8_1X16</entry>
               <entry>0x200f</entry>
diff --git a/Documentation/RCU/00-INDEX b/Documentation/RCU/00-INDEX
index 71b6f500ddb9..1d7a885761f5 100644
--- a/Documentation/RCU/00-INDEX
+++ b/Documentation/RCU/00-INDEX
@@ -21,7 +21,7 @@ rcu.txt
 RTFP.txt
         - List of RCU papers (bibliography) going back to 1980.
 stallwarn.txt
-        - RCU CPU stall warnings (CONFIG_RCU_CPU_STALL_DETECTOR)
+        - RCU CPU stall warnings (module parameter rcu_cpu_stall_suppress)
 torture.txt
         - RCU Torture Test Operation (CONFIG_RCU_TORTURE_TEST)
 trace.txt
diff --git a/Documentation/RCU/stallwarn.txt b/Documentation/RCU/stallwarn.txt
index 862c08ef1fde..4e959208f736 100644
--- a/Documentation/RCU/stallwarn.txt
+++ b/Documentation/RCU/stallwarn.txt
@@ -1,22 +1,25 @@
 Using RCU's CPU Stall Detector
 
-The CONFIG_RCU_CPU_STALL_DETECTOR kernel config parameter enables
-RCU's CPU stall detector, which detects conditions that unduly delay
-RCU grace periods.  The stall detector's idea of what constitutes
-"unduly delayed" is controlled by a set of C preprocessor macros:
+The rcu_cpu_stall_suppress module parameter enables RCU's CPU stall
+detector, which detects conditions that unduly delay RCU grace periods.
+This module parameter enables CPU stall detection by default, but
+may be overridden via boot-time parameter or at runtime via sysfs.
+The stall detector's idea of what constitutes "unduly delayed" is
+controlled by a set of kernel configuration variables and cpp macros:
 
-RCU_SECONDS_TILL_STALL_CHECK
+CONFIG_RCU_CPU_STALL_TIMEOUT
 
-        This macro defines the period of time that RCU will wait from
-        the beginning of a grace period until it issues an RCU CPU
-        stall warning.  This time period is normally ten seconds.
+        This kernel configuration parameter defines the period of time
+        that RCU will wait from the beginning of a grace period until it
+        issues an RCU CPU stall warning.  This time period is normally
+        ten seconds.
 
 RCU_SECONDS_TILL_STALL_RECHECK
 
         This macro defines the period of time that RCU will wait after
         issuing a stall warning until it issues another stall warning
-        for the same stall.  This time period is normally set to thirty
-        seconds.
+        for the same stall.  This time period is normally set to three
+        times the check interval plus thirty seconds.
 
 RCU_STALL_RAT_DELAY
 
diff --git a/Documentation/RCU/trace.txt b/Documentation/RCU/trace.txt
index 6a8c73f55b80..c078ad48f7a1 100644
--- a/Documentation/RCU/trace.txt
+++ b/Documentation/RCU/trace.txt
@@ -10,34 +10,46 @@ for rcutree and next for rcutiny.
 
 CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
 
-These implementations of RCU provides five debugfs files under the
-top-level directory RCU: rcu/rcudata (which displays fields in struct
-rcu_data), rcu/rcudata.csv (which is a .csv spreadsheet version of
-rcu/rcudata), rcu/rcugp (which displays grace-period counters),
-rcu/rcuhier (which displays the struct rcu_node hierarchy), and
-rcu/rcu_pending (which displays counts of the reasons that the
-rcu_pending() function decided that there was core RCU work to do).
+These implementations of RCU provides several debugfs files under the
+top-level directory "rcu":
+
+rcu/rcudata:
+        Displays fields in struct rcu_data.
+rcu/rcudata.csv:
+        Comma-separated values spreadsheet version of rcudata.
+rcu/rcugp:
+        Displays grace-period counters.
+rcu/rcuhier:
+        Displays the struct rcu_node hierarchy.
+rcu/rcu_pending:
+        Displays counts of the reasons rcu_pending() decided that RCU had
+        work to do.
+rcu/rcutorture:
+        Displays rcutorture test progress.
+rcu/rcuboost:
+        Displays RCU boosting statistics.  Only present if
+        CONFIG_RCU_BOOST=y.
 
 The output of "cat rcu/rcudata" looks as follows:
 
 rcu_sched:
-  0 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=10951/1 dn=0 df=1101 of=0 ri=36 ql=0 b=10
-  1 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=16117/1 dn=0 df=1015 of=0 ri=0 ql=0 b=10
-  2 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1445/1 dn=0 df=1839 of=0 ri=0 ql=0 b=10
-  3 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=6681/1 dn=0 df=1545 of=0 ri=0 ql=0 b=10
-  4 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=1003/1 dn=0 df=1992 of=0 ri=0 ql=0 b=10
-  5 c=17829 g=17830 pq=1 pqc=17829 qp=1 dt=3887/1 dn=0 df=3331 of=0 ri=4 ql=2 b=10
-  6 c=17829 g=17829 pq=1 pqc=17829 qp=0 dt=859/1 dn=0 df=3224 of=0 ri=0 ql=0 b=10
-  7 c=17829 g=17830 pq=0 pqc=17829 qp=1 dt=3761/1 dn=0 df=1818 of=0 ri=0 ql=2 b=10
+  0 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=545/1/0 df=50 of=0 ri=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
+  1 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=967/1/0 df=58 of=0 ri=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
+  2 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1081/1/0 df=175 of=0 ri=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
+  3 c=20942 g=20943 pq=1 pqc=20942 qp=1 dt=1846/0/0 df=404 of=0 ri=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
+  4 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=369/1/0 df=83 of=0 ri=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
+  5 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=381/1/0 df=64 of=0 ri=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
+  6 c=20972 g=20973 pq=1 pqc=20972 qp=0 dt=1037/1/0 df=183 of=0 ri=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
+  7 c=20897 g=20897 pq=1 pqc=20896 qp=0 dt=1572/0/0 df=382 of=0 ri=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
 rcu_bh:
-  0 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=10951/1 dn=0 df=0 of=0 ri=0 ql=0 b=10
-  1 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=16117/1 dn=0 df=13 of=0 ri=0 ql=0 b=10
-  2 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1445/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
-  3 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=6681/1 dn=0 df=9 of=0 ri=0 ql=0 b=10
-  4 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=1003/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
-  5 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3887/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
-  6 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=859/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
-  7 c=-275 g=-275 pq=1 pqc=-275 qp=0 dt=3761/1 dn=0 df=15 of=0 ri=0 ql=0 b=10
+  0 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=545/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
+  1 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=967/1/0 df=3 of=0 ri=1 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
+  2 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1081/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
+  3 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1846/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
+  4 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=369/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
+  5 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=381/1/0 df=4 of=0 ri=1 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
+  6 c=1480 g=1480 pq=1 pqc=1479 qp=0 dt=1037/1/0 df=6 of=0 ri=1 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
+  7 c=1474 g=1474 pq=1 pqc=1473 qp=0 dt=1572/0/0 df=8 of=0 ri=1 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
 
 The first section lists the rcu_data structures for rcu_sched, the second
 for rcu_bh.  Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
@@ -52,17 +64,18 @@ o	The number at the beginning of each line is the CPU number.
         substantially larger than the number of actual CPUs.
 
 o       "c" is the count of grace periods that this CPU believes have
-        completed.  CPUs in dynticks idle mode may lag quite a ways
-        behind, for example, CPU 4 under "rcu_sched" above, which has
-        slept through the past 25 RCU grace periods.  It is not unusual
-        to see CPUs lagging by thousands of grace periods.
+        completed.  Offlined CPUs and CPUs in dynticks idle mode may
+        lag quite a ways behind, for example, CPU 6 under "rcu_sched"
+        above, which has been offline through not quite 40,000 RCU grace
+        periods.  It is not unusual to see CPUs lagging by thousands of
+        grace periods.
 
 o       "g" is the count of grace periods that this CPU believes have
-        started.  Again, CPUs in dynticks idle mode may lag behind.
-        If the "c" and "g" values are equal, this CPU has already
-        reported a quiescent state for the last RCU grace period that
-        it is aware of, otherwise, the CPU believes that it owes RCU a
-        quiescent state.
+        started.  Again, offlined CPUs and CPUs in dynticks idle mode
+        may lag behind.  If the "c" and "g" values are equal, this CPU
+        has already reported a quiescent state for the last RCU grace
+        period that it is aware of, otherwise, the CPU believes that it
+        owes RCU a quiescent state.
 
 o       "pq" indicates that this CPU has passed through a quiescent state
         for the current grace period.  It is possible for "pq" to be
@@ -81,7 +94,8 @@ o	"pqc" indicates which grace period the last-observed quiescent
         the next grace period!
 
 o       "qp" indicates that RCU still expects a quiescent state from
-        this CPU.
+        this CPU.  Offlined CPUs and CPUs in dyntick idle mode might
+        well have qp=1, which is OK: RCU is still ignoring them.
 
 o       "dt" is the current value of the dyntick counter that is incremented
         when entering or leaving dynticks idle state, either by the
@@ -108,7 +122,7 @@ o	"df" is the number of times that some other CPU has forced a
 
 o       "of" is the number of times that some other CPU has forced a
         quiescent state on behalf of this CPU due to this CPU being
-        offline.  In a perfect world, this might neve happen, but it
+        offline.  In a perfect world, this might never happen, but it
         turns out that offlining and onlining a CPU can take several grace
         periods, and so there is likely to be an extended period of time
         when RCU believes that the CPU is online when it really is not.
@@ -125,6 +139,62 @@ o	"ql" is the number of RCU callbacks currently residing on
         of what state they are in (new, waiting for grace period to
         start, waiting for grace period to end, ready to invoke).
 
+o       "qs" gives an indication of the state of the callback queue
+        with four characters:
+
+        "N"     Indicates that there are callbacks queued that are not
+                ready to be handled by the next grace period, and thus
+                will be handled by the grace period following the next
+                one.
+
+        "R"     Indicates that there are callbacks queued that are
+                ready to be handled by the next grace period.
+
+        "W"     Indicates that there are callbacks queued that are
+                waiting on the current grace period.
+
+        "D"     Indicates that there are callbacks queued that have
+                already been handled by a prior grace period, and are
+                thus waiting to be invoked.  Note that callbacks in
+                the process of being invoked are not counted here.
+                Callbacks in the process of being invoked are those
+                that have been removed from the rcu_data structures
+                queues by rcu_do_batch(), but which have not yet been
+                invoked.
+
+        If there are no callbacks in a given one of the above states,
+        the corresponding character is replaced by ".".
+
+o       "kt" is the per-CPU kernel-thread state.  The digit preceding
+        the first slash is zero if there is no work pending and 1
+        otherwise.  The character between the first pair of slashes is
+        as follows:
+
+        "S"     The kernel thread is stopped, in other words, all
+                CPUs corresponding to this rcu_node structure are
+                offline.
+
+        "R"     The kernel thread is running.
+
+        "W"     The kernel thread is waiting because there is no work
+                for it to do.
+
+        "O"     The kernel thread is waiting because it has been
+                forced off of its designated CPU or because its
+                ->cpus_allowed mask permits it to run on other than
+                its designated CPU.
+
+        "Y"     The kernel thread is yielding to avoid hogging CPU.
+
+        "?"     Unknown value, indicates a bug.
+
+        The number after the final slash is the CPU that the kthread
+        is actually running on.
+
+o       "ktl" is the low-order 16 bits (in hexadecimal) of the count of
+        the number of times that this CPU's per-CPU kthread has gone
+        through its loop servicing invoke_rcu_cpu_kthread() requests.
+
 o       "b" is the batch limit for this CPU.  If more than this number
         of RCU callbacks is ready to invoke, then the remainder will
         be deferred.
@@ -174,14 +244,14 @@ o	"gpnum" is the number of grace periods that have started.  It is
 The output of "cat rcu/rcuhier" looks as follows, with very long lines:
 
 c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
-1/1 .>. 0:127 ^0    
-3/3 .>. 0:35 ^0    0/0 .>. 36:71 ^1    0/0 .>. 72:107 ^2    0/0 .>. 108:127 ^3    
-3/3f .>. 0:5 ^0    2/3 .>. 6:11 ^1    0/0 .>. 12:17 ^2    0/0 .>. 18:23 ^3    0/0 .>. 24:29 ^4    0/0 .>. 30:35 ^5    0/0 .>. 36:41 ^0    0/0 .>. 42:47 ^1    0/0 .>. 48:53 ^2    0/0 .>. 54:59 ^3    0/0 .>. 60:65 ^4    0/0 .>. 66:71 ^5    0/0 .>. 72:77 ^0    0/0 .>. 78:83 ^1    0/0 .>. 84:89 ^2    0/0 .>. 90:95 ^3    0/0 .>. 96:101 ^4    0/0 .>. 102:107 ^5    0/0 .>. 108:113 ^0    0/0 .>. 114:119 ^1    0/0 .>. 120:125 ^2    0/0 .>. 126:127 ^3    
+1/1 ..>. 0:127 ^0
+3/3 ..>. 0:35 ^0    0/0 ..>. 36:71 ^1    0/0 ..>. 72:107 ^2    0/0 ..>. 108:127 ^3
+3/3f ..>. 0:5 ^0    2/3 ..>. 6:11 ^1    0/0 ..>. 12:17 ^2    0/0 ..>. 18:23 ^3    0/0 ..>. 24:29 ^4    0/0 ..>. 30:35 ^5    0/0 ..>. 36:41 ^0    0/0 ..>. 42:47 ^1    0/0 ..>. 48:53 ^2    0/0 ..>. 54:59 ^3    0/0 ..>. 60:65 ^4    0/0 ..>. 66:71 ^5    0/0 ..>. 72:77 ^0    0/0 ..>. 78:83 ^1    0/0 ..>. 84:89 ^2    0/0 ..>. 90:95 ^3    0/0 ..>. 96:101 ^4    0/0 ..>. 102:107 ^5    0/0 ..>. 108:113 ^0    0/0 ..>. 114:119 ^1    0/0 ..>. 120:125 ^2    0/0 ..>. 126:127 ^3
 rcu_bh:
 c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
-0/1 .>. 0:127 ^0    
-0/3 .>. 0:35 ^0    0/0 .>. 36:71 ^1    0/0 .>. 72:107 ^2    0/0 .>. 108:127 ^3    
-0/3f .>. 0:5 ^0    0/3 .>. 6:11 ^1    0/0 .>. 12:17 ^2    0/0 .>. 18:23 ^3    0/0 .>. 24:29 ^4    0/0 .>. 30:35 ^5    0/0 .>. 36:41 ^0    0/0 .>. 42:47 ^1    0/0 .>. 48:53 ^2    0/0 .>. 54:59 ^3    0/0 .>. 60:65 ^4    0/0 .>. 66:71 ^5    0/0 .>. 72:77 ^0    0/0 .>. 78:83 ^1    0/0 .>. 84:89 ^2    0/0 .>. 90:95 ^3    0/0 .>. 96:101 ^4    0/0 .>. 102:107 ^5    0/0 .>. 108:113 ^0    0/0 .>. 114:119 ^1    0/0 .>. 120:125 ^2    0/0 .>. 126:127 ^3
+0/1 ..>. 0:127 ^0
+0/3 ..>. 0:35 ^0    0/0 ..>. 36:71 ^1    0/0 ..>. 72:107 ^2    0/0 ..>. 108:127 ^3
+0/3f ..>. 0:5 ^0    0/3 ..>. 6:11 ^1    0/0 ..>. 12:17 ^2    0/0 ..>. 18:23 ^3    0/0 ..>. 24:29 ^4    0/0 ..>. 30:35 ^5    0/0 ..>. 36:41 ^0    0/0 ..>. 42:47 ^1    0/0 ..>. 48:53 ^2    0/0 ..>. 54:59 ^3    0/0 ..>. 60:65 ^4    0/0 ..>. 66:71 ^5    0/0 ..>. 72:77 ^0    0/0 ..>. 78:83 ^1    0/0 ..>. 84:89 ^2    0/0 ..>. 90:95 ^3    0/0 ..>. 96:101 ^4    0/0 ..>. 102:107 ^5    0/0 ..>. 108:113 ^0    0/0 ..>. 114:119 ^1    0/0 ..>. 120:125 ^2    0/0 ..>. 126:127 ^3
 
 This is once again split into "rcu_sched" and "rcu_bh" portions,
 and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
@@ -240,13 +310,20 @@ o	Each element of the form "1/1 0:127 ^0" represents one struct
                 current grace period.
 
         o       The characters separated by the ">" indicate the state
-                of the blocked-tasks lists.  A "T" preceding the ">"
+                of the blocked-tasks lists.  A "G" preceding the ">"
                 indicates that at least one task blocked in an RCU
                 read-side critical section blocks the current grace
-                period, while a "." preceding the ">" indicates otherwise.
-                The character following the ">" indicates similarly for
-                the next grace period.  A "T" should appear in this
-                field only for rcu-preempt.
+                period, while a "E" preceding the ">" indicates that
+                at least one task blocked in an RCU read-side critical
+                section blocks the current expedited grace period.
+                A "T" character following the ">" indicates that at
+                least one task is blocked within an RCU read-side
+                critical section, regardless of whether any current
+                grace period (expedited or normal) is inconvenienced.
+                A "." character appears if the corresponding condition
+                does not hold, so that "..>." indicates that no tasks
+                are blocked.  In contrast, "GE>T" indicates maximal
+                inconvenience from blocked tasks.
 
         o       The numbers separated by the ":" are the range of CPUs
                 served by this struct rcu_node.  This can be helpful
@@ -328,6 +405,113 @@ o	"nn" is the number of times that this CPU needed nothing.  Alert
         is due to short-circuit evaluation in rcu_pending().
 
 
+The output of "cat rcu/rcutorture" looks as follows:
+
+rcutorture test sequence: 0 (test in progress)
+rcutorture update version number: 615
+
+The first line shows the number of rcutorture tests that have completed
+since boot.  If a test is currently running, the "(test in progress)"
+string will appear as shown above.  The second line shows the number of
+update cycles that the current test has started, or zero if there is
+no test in progress.
+
+
+The output of "cat rcu/rcuboost" looks as follows:
+
+0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
+     balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16
+6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
+     balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6
+
+This information is output only for rcu_preempt.  Each two-line entry
+corresponds to a leaf rcu_node strcuture.  The fields are as follows:
+
+o       "n:m" is the CPU-number range for the corresponding two-line
+        entry.  In the sample output above, the first entry covers
+        CPUs zero through five and the second entry covers CPUs 6
+        and 7.
+
+o       "tasks=TNEB" gives the state of the various segments of the
+        rnp->blocked_tasks list:
+
+        "T"     This indicates that there are some tasks that blocked
+                while running on one of the corresponding CPUs while
+                in an RCU read-side critical section.
+
+        "N"     This indicates that some of the blocked tasks are preventing
+                the current normal (non-expedited) grace period from
+                completing.
+
+        "E"     This indicates that some of the blocked tasks are preventing
+                the current expedited grace period from completing.
+
+        "B"     This indicates that some of the blocked tasks are in
+                need of RCU priority boosting.
+
+        Each character is replaced with "." if the corresponding
+        condition does not hold.
+
+o       "kt" is the state of the RCU priority-boosting kernel
+        thread associated with the corresponding rcu_node structure.
+        The state can be one of the following:
+
+        "S"     The kernel thread is stopped, in other words, all
+                CPUs corresponding to this rcu_node structure are
+                offline.
+
+        "R"     The kernel thread is running.
+
+        "W"     The kernel thread is waiting because there is no work
+                for it to do.
+
+        "Y"     The kernel thread is yielding to avoid hogging CPU.
+
+        "?"     Unknown value, indicates a bug.
+
+o       "ntb" is the number of tasks boosted.
+
+o       "neb" is the number of tasks boosted in order to complete an
+        expedited grace period.
+
+o       "nnb" is the number of tasks boosted in order to complete a
+        normal (non-expedited) grace period.  When boosting a task
+        that was blocking both an expedited and a normal grace period,
+        it is counted against the expedited total above.
+
+o       "j" is the low-order 16 bits of the jiffies counter in
+        hexadecimal.
+
+o       "bt" is the low-order 16 bits of the value that the jiffies
+        counter will have when we next start boosting, assuming that
+        the current grace period does not end beforehand.  This is
+        also in hexadecimal.
+
+o       "balk: nt" counts the number of times we didn't boost (in
+        other words, we balked) even though it was time to boost because
+        there were no blocked tasks to boost.  This situation occurs
+        when there is one blocked task on one rcu_node structure and
+        none on some other rcu_node structure.
+
+o       "egt" counts the number of times we balked because although
+        there were blocked tasks, none of them were blocking the
+        current grace period, whether expedited or otherwise.
+
+o       "bt" counts the number of times we balked because boosting
+        had already been initiated for the current grace period.
+
+o       "nb" counts the number of times we balked because there
+        was at least one task blocking the current non-expedited grace
+        period that never had blocked.  If it is already running, it
+        just won't help to boost its priority!
+
+o       "ny" counts the number of times we balked because it was
+        not yet time to start boosting.
+
+o       "nos" counts the number of times we balked for other
+        reasons, e.g., the grace period ended first.
+
+
 CONFIG_TINY_RCU and CONFIG_TINY_PREEMPT_RCU debugfs Files and Formats
 
 These implementations of RCU provides a single debugfs file under the
@@ -394,9 +578,9 @@ o	"neb" is the number of expedited grace periods that have had
 o       "nnb" is the number of normal grace periods that have had
         to resort to RCU priority boosting since boot.
 
-o       "j" is the low-order 12 bits of the jiffies counter in hexadecimal.
+o       "j" is the low-order 16 bits of the jiffies counter in hexadecimal.
 
-o       "bt" is the low-order 12 bits of the value that the jiffies counter
+o       "bt" is the low-order 16 bits of the value that the jiffies counter
         will have at the next time that boosting is scheduled to begin.
 
 o       In the line beginning with "normal balk", the fields are as follows:
diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index b6ed61c95856..7c163477fcd8 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -52,8 +52,10 @@ Brief summary of control files.
  tasks                           # attach a task(thread) and show list of threads
  cgroup.procs                    # show list of processes
  cgroup.event_control            # an interface for event_fd()
- memory.usage_in_bytes           # show current memory(RSS+Cache) usage.
- memory.memsw.usage_in_bytes     # show current memory+Swap usage
+ memory.usage_in_bytes           # show current res_counter usage for memory
+                                 (See 5.5 for details)
+ memory.memsw.usage_in_bytes     # show current res_counter usage for memory+Swap
+                                 (See 5.5 for details)
  memory.limit_in_bytes           # set/show limit of memory usage
  memory.memsw.limit_in_bytes     # set/show limit of memory+Swap usage
  memory.failcnt                  # show the number of memory usage hits limits
@@ -453,6 +455,15 @@ memory under it will be reclaimed.
 You can reset failcnt by writing 0 to failcnt file.
 # echo 0 > .../memory.failcnt
 
+5.5 usage_in_bytes
+
+For efficiency, as other kernel components, memory cgroup uses some optimization
+to avoid unnecessary cacheline false sharing. usage_in_bytes is affected by the
+method and doesn't show 'exact' value of memory(and swap) usage, it's an fuzz
+value for efficient access. (Of course, when necessary, it's synchronized.)
+If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP)
+value in memory.stat(see 5.2).
+
 6. Hierarchy support
 
 The memory controller supports a deep hierarchy and hierarchical accounting.
diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
new file mode 100755
index 000000000000..1a729f089866
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt
@@ -0,0 +1,61 @@
+CAN Device Tree Bindings
+------------------------
+2011 Freescale Semiconductor, Inc.
+
+fsl,flexcan-v1.0 nodes
+-----------------------
+In addition to the required compatible-, reg- and interrupt-properties, you can
+also specify which clock source shall be used for the controller.
+
+CPI Clock- Can Protocol Interface Clock
+        This CLK_SRC bit of CTRL(control register) selects the clock source to
+        the CAN Protocol Interface(CPI) to be either the peripheral clock
+        (driven by the PLL) or the crystal oscillator clock. The selected clock
+        is the one fed to the prescaler to generate the Serial Clock (Sclock).
+        The PRESDIV field of CTRL(control register) controls a prescaler that
+        generates the Serial Clock (Sclock), whose period defines the
+        time quantum used to compose the CAN waveform.
+
+Can Engine Clock Source
+        There are two sources for CAN clock
+        - Platform Clock  It represents the bus clock
+        - Oscillator Clock
+
+        Peripheral Clock (PLL)
+        --------------
+                     |
+                    ---------                 -------------
+                    |       |CPI Clock        | Prescaler |       Sclock
+                    |       |---------------->| (1.. 256) |------------>
+                    ---------                 -------------
+                     |  |
+        --------------  ---------------------CLK_SRC
+        Oscillator Clock
+
+- fsl,flexcan-clock-source : CAN Engine Clock Source.This property selects
+                             the peripheral clock. PLL clock is fed to the
+                             prescaler to generate the Serial Clock (Sclock).
+                             Valid values are "oscillator" and "platform"
+                             "oscillator": CAN engine clock source is oscillator clock.
+                             "platform" The CAN engine clock source is the bus clock
+                             (platform clock).
+
+- fsl,flexcan-clock-divider : for the reference and system clock, an additional
+                              clock divider can be specified.
+- clock-frequency: frequency required to calculate the bitrate for FlexCAN.
+
+Note:
+        - v1.0 of flexcan-v1.0 represent the IP block version for P1010 SOC.
+        - P1010 does not have oscillator as the Clock Source.So the default
+          Clock Source is platform clock.
+Examples:
+
+        can0@1c000 {
+                compatible = "fsl,flexcan-v1.0";
+                reg = <0x1c000 0x1000>;
+                interrupts = <48 0x2>;
+                interrupt-parent = <&mpic>;
+                fsl,flexcan-clock-source = "platform";
+                fsl,flexcan-clock-divider = <2>;
+                clock-frequency = <fixed by u-boot>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
new file mode 100644
index 000000000000..939a26d541f6
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/ifc.txt
@@ -0,0 +1,76 @@
+Integrated Flash Controller
+
+Properties:
+- name : Should be ifc
+- compatible : should contain "fsl,ifc". The version of the integrated
+               flash controller can be found in the IFC_REV register at
+               offset zero.
+
+- #address-cells : Should be either two or three.  The first cell is the
+                   chipselect number, and the remaining cells are the
+                   offset into the chipselect.
+- #size-cells : Either one or two, depending on how large each chipselect
+                can be.
+- reg : Offset and length of the register set for the device
+- interrupts : IFC has two interrupts. The first one is the "common"
+               interrupt(CM_EVTER_STAT), and second is the NAND interrupt
+               (NAND_EVTER_STAT).
+
+- ranges : Each range corresponds to a single chipselect, and covers
+           the entire access window as configured.
+
+Child device nodes describe the devices connected to IFC such as NOR (e.g.
+cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices
+like FPGAs, CPLDs, etc.
+
+Example:
+
+        ifc@ffe1e000 {
+                compatible = "fsl,ifc", "simple-bus";
+                #address-cells = <2>;
+                #size-cells = <1>;
+                reg = <0x0 0xffe1e000 0 0x2000>;
+                interrupts = <16 2 19 2>;
+
+                /* NOR, NAND Flashes and CPLD on board */
+                ranges = <0x0 0x0 0x0 0xee000000 0x02000000
+                          0x1 0x0 0x0 0xffa00000 0x00010000
+                          0x3 0x0 0x0 0xffb00000 0x00020000>;
+
+                flash@0,0 {
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        compatible = "cfi-flash";
+                        reg = <0x0 0x0 0x2000000>;
+                        bank-width = <2>;
+                        device-width = <1>;
+
+                        partition@0 {
+                                /* 32MB for user data */
+                                reg = <0x0 0x02000000>;
+                                label = "NOR Data";
+                        };
+                };
+
+                flash@1,0 {
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        compatible = "fsl,ifc-nand";
+                        reg = <0x1 0x0 0x10000>;
+
+                        partition@0 {
+                                /* This location must not be altered  */
+                                /* 1MB for u-boot Bootloader Image */
+                                reg = <0x0 0x00100000>;
+                                label = "NAND U-Boot Image";
+                                read-only;
+                        };
+                };
+
+                cpld@3,0 {
+                        #address-cells = <1>;
+                        #size-cells = <1>;
+                        compatible = "fsl,p1010rdb-cpld";
+                        reg = <0x3 0x0 0x000001f>;
+                };
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt
new file mode 100644
index 000000000000..df41958140e8
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-timer.txt
@@ -0,0 +1,38 @@
+* Freescale MPIC timers
+
+Required properties:
+- compatible: "fsl,mpic-global-timer"
+
+- reg : Contains two regions.  The first is the main timer register bank
+  (GTCCRxx, GTBCRxx, GTVPRxx, GTDRxx).  The second is the timer control
+  register (TCRx) for the group.
+
+- fsl,available-ranges: use <start count> style section to define which
+  timer interrupts can be used.  This property is optional; without this,
+  all timers within the group can be used.
+
+- interrupts: one interrupt per timer in the group, in order, starting
+  with timer zero.  If timer-available-ranges is present, only the
+  interrupts that correspond to available timers shall be present.
+
+Example:
+        /* Note that this requires #interrupt-cells to be 4 */
+        timer0: timer@41100 {
+                compatible = "fsl,mpic-global-timer";
+                reg = <0x41100 0x100 0x41300 4>;
+
+                /* Another AMP partition is using timers 0 and 1 */
+                fsl,available-ranges = <2 2>;
+
+                interrupts = <2 0 3 0
+                              3 0 3 0>;
+        };
+
+        timer1: timer@42100 {
+                compatible = "fsl,mpic-global-timer";
+                reg = <0x42100 0x100 0x42300 4>;
+                interrupts = <4 0 3 0
+                              5 0 3 0
+                              6 0 3 0
+                              7 0 3 0>;
+        };
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
index 4f6145859aab..2cf38bd841fd 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
@@ -190,7 +190,7 @@ EXAMPLE 4
          */
         timer0: timer@41100 {
                 compatible = "fsl,mpic-global-timer";
-                reg = <0x41100 0x100>;
+                reg = <0x41100 0x100 0x41300 4>;
                 interrupts = <0 0 3 0
                               1 0 3 0
                               2 0 3 0
diff --git a/Documentation/driver-model/bus.txt b/Documentation/driver-model/bus.txt
index 5001b7511626..6754b2df8aa1 100644
--- a/Documentation/driver-model/bus.txt
+++ b/Documentation/driver-model/bus.txt
@@ -3,24 +3,7 @@ Bus Types
 
 Definition
 ~~~~~~~~~~
-
-struct bus_type {
-        char                    * name;
-
-        struct subsystem        subsys;
-        struct kset             drivers;
-        struct kset             devices;
-
-        struct bus_attribute    * bus_attrs;
-        struct device_attribute * dev_attrs;
-        struct driver_attribute * drv_attrs;
-
-        int             (*match)(struct device * dev, struct device_driver * drv);
-        int             (*hotplug) (struct device *dev, char **envp, 
-                                    int num_envp, char *buffer, int buffer_size);
-        int             (*suspend)(struct device * dev, pm_message_t state);
-        int             (*resume)(struct device * dev);
-};
+See the kerneldoc for the struct bus_type.
 
 int bus_register(struct bus_type * bus);
 
diff --git a/Documentation/driver-model/class.txt b/Documentation/driver-model/class.txt
index 548505f14aa4..1fefc480a80b 100644
--- a/Documentation/driver-model/class.txt
+++ b/Documentation/driver-model/class.txt
@@ -27,22 +27,7 @@ The device class structure looks like:
 typedef int (*devclass_add)(struct device *);
 typedef void (*devclass_remove)(struct device *);
 
-struct device_class {
-        char                    * name;
-        rwlock_t                lock;
-        u32                     devnum;
-        struct list_head        node;
-
-        struct list_head        drivers;
-        struct list_head        intf_list;
-
-        struct driver_dir_entry dir;
-        struct driver_dir_entry device_dir;
-        struct driver_dir_entry driver_dir;
-
-        devclass_add            add_device;
-        devclass_remove         remove_device;
-};
+See the kerneldoc for the struct class.
 
 A typical device class definition would look like: 
 
diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt
index a124f3126b0d..b2ff42685bcb 100644
--- a/Documentation/driver-model/device.txt
+++ b/Documentation/driver-model/device.txt
@@ -2,96 +2,7 @@
 The Basic Device Structure
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-struct device {
-        struct list_head g_list;
-        struct list_head node;
-        struct list_head bus_list;
-        struct list_head driver_list;
-        struct list_head intf_list;
-        struct list_head children;
-        struct device   * parent;
-
-        char    name[DEVICE_NAME_SIZE];
-        char    bus_id[BUS_ID_SIZE];
-
-        spinlock_t      lock;
-        atomic_t        refcount;
-
-        struct bus_type * bus;
-        struct driver_dir_entry dir;
-
-        u32             class_num;
-
-        struct device_driver *driver;
-        void            *driver_data;
-        void            *platform_data;
-
-        u32             current_state;
-        unsigned char *saved_state;
-
-        void    (*release)(struct device * dev);
-};
-
-Fields 
-~~~~~~
-g_list: Node in the global device list.
-
-node:   Node in device's parent's children list.
-
-bus_list: Node in device's bus's devices list.
-
-driver_list:   Node in device's driver's devices list.
-
-intf_list:     List of intf_data. There is one structure allocated for
-               each interface that the device supports.
-
-children:      List of child devices.
-
-parent:        *** FIXME ***
-
-name:          ASCII description of device. 
-               Example: " 3Com Corporation 3c905 100BaseTX [Boomerang]"
-
-bus_id:        ASCII representation of device's bus position. This 
-               field should be a name unique across all devices on the
-               bus type the device belongs to. 
-
-               Example: PCI bus_ids are in the form of
-               <bus number>:<slot number>.<function number> 
-               This name is unique across all PCI devices in the system.
-
-lock:          Spinlock for the device. 
-
-refcount:      Reference count on the device.
-
-bus:           Pointer to struct bus_type that device belongs to.
-
-dir:           Device's sysfs directory.
-
-class_num:     Class-enumerated value of the device.
-
-driver:        Pointer to struct device_driver that controls the device.
-
-driver_data:   Driver-specific data.
-
-platform_data: Platform data specific to the device.
-
-               Example:  for devices on custom boards, as typical of embedded
-               and SOC based hardware, Linux often uses platform_data to point
-               to board-specific structures describing devices and how they
-               are wired.  That can include what ports are available, chip
-               variants, which GPIO pins act in what additional roles, and so
-               on.  This shrinks the "Board Support Packages" (BSPs) and
-               minimizes board-specific #ifdefs in drivers.
-
-current_state: Current power state of the device.
-
-saved_state:   Pointer to saved state of the device. This is usable by
-               the device driver controlling the device.
-
-release:       Callback to free the device after all references have 
-               gone away. This should be set by the allocator of the 
-               device (i.e. the bus driver that discovered the device).
+See the kerneldoc for the struct device.
 
 
 Programming Interface
diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt
index d2cd6fb8ba9e..4421135826a2 100644
--- a/Documentation/driver-model/driver.txt
+++ b/Documentation/driver-model/driver.txt
@@ -1,23 +1,7 @@
 
 Device Drivers
 
-struct device_driver {
-        char                    * name;
-        struct bus_type         * bus;
-
-        struct completion       unloaded;
-        struct kobject          kobj;
-        list_t                  devices;
-
-        struct module           *owner;
-
-        int     (*probe)        (struct device * dev);
-        int     (*remove)       (struct device * dev);
-
-        int     (*suspend)      (struct device * dev, pm_message_t state);
-        int     (*resume)       (struct device * dev);
-};
-
+See the kerneldoc for the struct device_driver.
 
 
 Allocation
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 46679e48967a..4cba260e3059 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -376,26 +376,6 @@ Who:	Tejun Heo <tj@kernel.org>
 
 ----------------------------
 
-What:   Support for lcd_switch and display_get in asus-laptop driver
-When:   March 2010
-Why:    These two features use non-standard interfaces. There are the
-        only features that really need multiple path to guess what's
-        the right method name on a specific laptop.
-
-        Removing them will allow to remove a lot of code an significantly
-        clean the drivers.
-
-        This will affect the backlight code which won't be able to know
-        if the backlight is on or off. The platform display file will also be
-        write only (like the one in eeepc-laptop).
-
-        This should'nt affect a lot of user because they usually know
-        when their display is on or off.
-
-Who:    Corentin Chary <corentin.chary@gmail.com>
-
-----------------------------
-
 What:   sysfs-class-rfkill state file
 When:   Feb 2014
 Files:  net/rfkill/core.c
@@ -459,14 +439,6 @@ Who:	Thomas Gleixner <tglx@linutronix.de>
 
 ----------------------------
 
-What:   The acpi_sleep=s4_nonvs command line option
-When:   2.6.37
-Files:  arch/x86/kernel/acpi/sleep.c
-Why:    superseded by acpi_sleep=nonvs
-Who:    Rafael J. Wysocki <rjw@sisk.pl>
-
-----------------------------
-
 What:   PCI DMA unmap state API
 When:   August 2012
 Why:    PCI DMA unmap state API (include/linux/pci-dma.h) was replaced
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index b0b814d75ca1..60740e8ecb37 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -836,7 +836,6 @@ Provides counts of softirq handlers serviced since boot time, for each cpu.
  TASKLET:          0          0          0        290
    SCHED:      27035      26983      26971      26746
  HRTIMER:          0          0          0          0
-     RCU:       1678       1769       2178       2250
 
 
 1.3 IDE devices in /proc/ide
diff --git a/Documentation/flexible-arrays.txt b/Documentation/flexible-arrays.txt
index cb8a3a00cc92..df904aec9904 100644
--- a/Documentation/flexible-arrays.txt
+++ b/Documentation/flexible-arrays.txt
@@ -66,10 +66,10 @@ trick is to ensure that any needed memory allocations are done before
 entering atomic context, using:
 
     int flex_array_prealloc(struct flex_array *array, unsigned int start,
-                            unsigned int end, gfp_t flags);
+                            unsigned int nr_elements, gfp_t flags);
 
 This function will ensure that memory for the elements indexed in the range
-defined by start and end has been allocated.  Thereafter, a
+defined by start and nr_elements has been allocated.  Thereafter, a
 flex_array_put() call on an element in that range is guaranteed not to
 block.
 
diff --git a/Documentation/hwmon/adm1021 b/Documentation/hwmon/adm1021
index 03d02bfb3df1..02ad96cf9b2b 100644
--- a/Documentation/hwmon/adm1021
+++ b/Documentation/hwmon/adm1021
@@ -14,10 +14,6 @@ Supported chips:
     Prefix: 'gl523sm'
     Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
     Datasheet:
-  * Intel Xeon Processor
-    Prefix: - any other - may require 'force_adm1021' parameter
-    Addresses scanned: none
-    Datasheet: Publicly available at Intel website
   * Maxim MAX1617
     Prefix: 'max1617'
     Addresses scanned: I2C 0x18 - 0x1a, 0x29 - 0x2b, 0x4c - 0x4e
@@ -91,21 +87,27 @@ will do no harm, but will return 'old' values. It is possible to make
 ADM1021-clones do faster measurements, but there is really no good reason
 for that.
 
-Xeon support
-------------
 
-Some Xeon processors have real max1617, adm1021, or compatible chips
-within them, with two temperature sensors.
+Netburst-based Xeon support
+---------------------------
 
-Other Xeons have chips with only one sensor.
+Some Xeon processors based on the Netburst (early Pentium 4, from 2001 to
+2003) microarchitecture had real MAX1617, ADM1021, or compatible chips
+within them, with two temperature sensors. Other Xeon processors of this
+era (with 400 MHz FSB) had chips with only one temperature sensor.
 
-If you have a Xeon, and the adm1021 module loads, and both temperatures
-appear valid, then things are good.
+If you have such an old Xeon, and you get two valid temperatures when
+loading the adm1021 module, then things are good.
 
-If the adm1021 module doesn't load, you should try this:
-        modprobe adm1021 force_adm1021=BUS,ADDRESS
-        ADDRESS can only be 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e.
+If nothing happens when loading the adm1021 module, and you are certain
+that your specific Xeon processor model includes compatible sensors, you
+will have to explicitly instantiate the sensor chips from user-space. See
+method 4 in Documentation/i2c/instantiating-devices. Possible slave
+addresses are 0x18, 0x1a, 0x29, 0x2b, 0x4c, or 0x4e. It is likely that
+only temp2 will be correct and temp1 will have to be ignored.
 
-If you have dual Xeons you may have appear to have two separate
-adm1021-compatible chips, or two single-temperature sensors, at distinct
-addresses.
+Previous generations of the Xeon processor (based on Pentium II/III)
+didn't have these sensors. Next generations of Xeon processors (533 MHz
+FSB and faster) lost them, until the Core-based generation which
+introduced integrated digital thermal sensors. These are supported by
+the coretemp driver.
diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90
index fa475c0a48a3..f3efd18e87f4 100644
--- a/Documentation/hwmon/lm90
+++ b/Documentation/hwmon/lm90
@@ -32,6 +32,16 @@ Supported chips:
     Addresses scanned: I2C 0x4c and 0x4d
     Datasheet: Publicly available at the ON Semiconductor website
                http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461
+  * Analog Devices ADT7461A
+    Prefix: 'adt7461a'
+    Addresses scanned: I2C 0x4c and 0x4d
+    Datasheet: Publicly available at the ON Semiconductor website
+               http://www.onsemi.com/PowerSolutions/product.do?id=ADT7461A
+  * ON Semiconductor NCT1008
+    Prefix: 'nct1008'
+    Addresses scanned: I2C 0x4c and 0x4d
+    Datasheet: Publicly available at the ON Semiconductor website
+               http://www.onsemi.com/PowerSolutions/product.do?id=NCT1008
   * Maxim MAX6646
     Prefix: 'max6646'
     Addresses scanned: I2C 0x4d
@@ -149,7 +159,7 @@ ADM1032:
   * ALERT is triggered by open remote sensor.
   * SMBus PEC support for Write Byte and Receive Byte transactions.
 
-ADT7461:
+ADT7461, ADT7461A, NCT1008:
   * Extended temperature range (breaks compatibility)
   * Lower resolution for remote temperature
 
@@ -195,9 +205,9 @@ are exported, one for each channel, but these values are of course linked.
 Only the local hysteresis can be set from user-space, and the same delta
 applies to the remote hysteresis.
 
-The lm90 driver will not update its values more frequently than every
-other second; reading them more often will do no harm, but will return
-'old' values.
+The lm90 driver will not update its values more frequently than configured with
+the update_interval attribute; reading them more often will do no harm, but will
+return 'old' values.
 
 SMBus Alert Support
 -------------------
@@ -205,11 +215,12 @@ SMBus Alert Support
 This driver has basic support for SMBus alert. When an alert is received,
 the status register is read and the faulty temperature channel is logged.
 
-The Analog Devices chips (ADM1032 and ADT7461) do not implement the SMBus
-alert protocol properly so additional care is needed: the ALERT output is
-disabled when an alert is received, and is re-enabled only when the alarm
-is gone. Otherwise the chip would block alerts from other chips in the bus
-as long as the alarm is active.
+The Analog Devices chips (ADM1032, ADT7461 and ADT7461A) and ON
+Semiconductor chips (NCT1008) do not implement the SMBus alert protocol
+properly so additional care is needed: the ALERT output is disabled when
+an alert is received, and is re-enabled only when the alarm is gone.
+Otherwise the chip would block alerts from other chips in the bus as long
+as the alarm is active.
 
 PEC Support
 -----------
diff --git a/Documentation/hwmon/max16064 b/Documentation/hwmon/max16064
new file mode 100644
index 000000000000..41728999e142
--- /dev/null
+++ b/Documentation/hwmon/max16064
@@ -0,0 +1,62 @@
+Kernel driver max16064
+======================
+
+Supported chips:
+  * Maxim MAX16064
+    Prefix: 'max16064'
+    Addresses scanned: -
+    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
+
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+
+
+Description
+-----------
+
+This driver supports hardware montoring for Maxim MAX16064 Quad Power-Supply
+Controller with Active-Voltage Output Control and PMBus Interface.
+
+The driver is a client driver to the core PMBus driver.
+Please see Documentation/hwmon/pmbus for details on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+
+in[1-4]_label           "vout[1-4]"
+in[1-4]_input           Measured voltage. From READ_VOUT register.
+in[1-4]_min             Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in[1-4]_max             Maximum voltage. From VOUT_OV_WARN_LIMIT register.
+in[1-4]_lcrit           Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in[1-4]_crit            Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
+in[1-4]_min_alarm       Voltage low alarm. From VOLTAGE_UV_WARNING status.
+in[1-4]_max_alarm       Voltage high alarm. From VOLTAGE_OV_WARNING status.
+in[1-4]_lcrit_alarm     Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
+in[1-4]_crit_alarm      Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
+
+temp1_input             Measured temperature. From READ_TEMPERATURE_1 register.
+temp1_max               Maximum temperature. From OT_WARN_LIMIT register.
+temp1_crit              Critical high temperature. From OT_FAULT_LIMIT register.
+temp1_max_alarm         Chip temperature high alarm. Set by comparing
+                        READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
+                        status is set.
+temp1_crit_alarm        Chip temperature critical high alarm. Set by comparing
+                        READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
+                        status is set.
diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440
new file mode 100644
index 000000000000..6c525dd07d59
--- /dev/null
+++ b/Documentation/hwmon/max34440
@@ -0,0 +1,79 @@
+Kernel driver max34440
+======================
+
+Supported chips:
+  * Maxim MAX34440
+    Prefixes: 'max34440'
+    Addresses scanned: -
+    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
+  * Maxim MAX34441
+    PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
+    Prefixes: 'max34441'
+    Addresses scanned: -
+    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
+
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+
+
+Description
+-----------
+
+This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel
+Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager
+and Intelligent Fan Controller.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus for details on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+
+in[1-6]_label           "vout[1-6]".
+in[1-6]_input           Measured voltage. From READ_VOUT register.
+in[1-6]_min             Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in[1-6]_max             Maximum voltage. From VOUT_OV_WARN_LIMIT register.
+in[1-6]_lcrit           Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in[1-6]_crit            Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
+in[1-6]_min_alarm       Voltage low alarm. From VOLTAGE_UV_WARNING status.
+in[1-6]_max_alarm       Voltage high alarm. From VOLTAGE_OV_WARNING status.
+in[1-6]_lcrit_alarm     Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
+in[1-6]_crit_alarm      Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
+
+curr[1-6]_label         "iout[1-6]".
+curr[1-6]_input         Measured current. From READ_IOUT register.
+curr[1-6]_max           Maximum current. From IOUT_OC_WARN_LIMIT register.
+curr[1-6]_crit          Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
+curr[1-6]_max_alarm     Current high alarm. From IOUT_OC_WARNING status.
+curr[1-6]_crit_alarm    Current critical high alarm. From IOUT_OC_FAULT status.
+
+                        in6 and curr6 attributes only exist for MAX34440.
+
+temp[1-8]_input         Measured temperatures. From READ_TEMPERATURE_1 register.
+                        temp1 is the chip's internal temperature. temp2..temp5
+                        are remote I2C temperature sensors. For MAX34441, temp6
+                        is a remote thermal-diode sensor. For MAX34440, temp6..8
+                        are remote I2C temperature sensors.
+temp[1-8]_max           Maximum temperature. From OT_WARN_LIMIT register.
+temp[1-8]_crit          Critical high temperature. From OT_FAULT_LIMIT register.
+temp[1-8]_max_alarm     Temperature high alarm.
+temp[1-8]_crit_alarm    Temperature critical high alarm.
+
+                        temp7 and temp8 attributes only exist for MAX34440.
diff --git a/Documentation/hwmon/max8688 b/Documentation/hwmon/max8688
new file mode 100644
index 000000000000..0ddd3a412030
--- /dev/null
+++ b/Documentation/hwmon/max8688
@@ -0,0 +1,69 @@
+Kernel driver max8688
+=====================
+
+Supported chips:
+  * Maxim MAX8688
+    Prefix: 'max8688'
+    Addresses scanned: -
+    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
+
+Author: Guenter Roeck <guenter.roeck@ericsson.com>
+
+
+Description
+-----------
+
+This driver supports hardware montoring for Maxim MAX8688 Digital Power-Supply
+Controller/Monitor with PMBus Interface.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus for details on PMBus client drivers.
+
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate the
+devices explicitly. Please see Documentation/i2c/instantiating-devices for
+details.
+
+
+Platform data support
+---------------------
+
+The driver supports standard PMBus driver platform data.
+
+
+Sysfs entries
+-------------
+
+The following attributes are supported. Limits are read-write; all other
+attributes are read-only.
+
+in1_label               "vout1"
+in1_input               Measured voltage. From READ_VOUT register.
+in1_min                 Minumum Voltage. From VOUT_UV_WARN_LIMIT register.
+in1_max                 Maximum voltage. From VOUT_OV_WARN_LIMIT register.
+in1_lcrit               Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register.
+in1_crit                Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register.
+in1_min_alarm           Voltage low alarm. From VOLTAGE_UV_WARNING status.
+in1_max_alarm           Voltage high alarm. From VOLTAGE_OV_WARNING status.
+in1_lcrit_alarm         Voltage critical low alarm. From VOLTAGE_UV_FAULT status.
+in1_crit_alarm          Voltage critical high alarm. From VOLTAGE_OV_FAULT status.
+
+curr1_label             "iout1"
+curr1_input             Measured current. From READ_IOUT register.
+curr1_max               Maximum current. From IOUT_OC_WARN_LIMIT register.
+curr1_crit              Critical maximum current. From IOUT_OC_FAULT_LIMIT register.
+curr1_max_alarm         Current high alarm. From IOUT_OC_WARN_LIMIT register.
+curr1_crit_alarm        Current critical high alarm. From IOUT_OC_FAULT status.
+
+temp1_input             Measured temperature. From READ_TEMPERATURE_1 register.
+temp1_max               Maximum temperature. From OT_WARN_LIMIT register.
+temp1_crit              Critical high temperature. From OT_FAULT_LIMIT register.
+temp1_max_alarm         Chip temperature high alarm. Set by comparing
+                        READ_TEMPERATURE_1 with OT_WARN_LIMIT if TEMP_OT_WARNING
+                        status is set.
+temp1_crit_alarm        Chip temperature critical high alarm. Set by comparing
+                        READ_TEMPERATURE_1 with OT_FAULT_LIMIT if TEMP_OT_FAULT
+                        status is set.
diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus
index dc4933e96344..5e462fc7f99b 100644
--- a/Documentation/hwmon/pmbus
+++ b/Documentation/hwmon/pmbus
@@ -13,26 +13,6 @@ Supported chips:
     Prefix: 'ltc2978'
     Addresses scanned: -
     Datasheet: http://cds.linear.com/docs/Datasheet/2978fa.pdf
-  * Maxim MAX16064
-    Quad Power-Supply Controller
-    Prefix: 'max16064'
-    Addresses scanned: -
-    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX16064.pdf
-  * Maxim MAX34440
-    PMBus 6-Channel Power-Supply Manager
-    Prefixes: 'max34440'
-    Addresses scanned: -
-    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34440.pdf
-  * Maxim MAX34441
-    PMBus 5-Channel Power-Supply Manager and Intelligent Fan Controller
-    Prefixes: 'max34441'
-    Addresses scanned: -
-    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf
-  * Maxim MAX8688
-    Digital Power-Supply Controller/Monitor
-    Prefix: 'max8688'
-    Addresses scanned: -
-    Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX8688.pdf
   * Generic PMBus devices
     Prefix: 'pmbus'
     Addresses scanned: -
@@ -175,11 +155,13 @@ currX_crit		Critical maximum current.
                         From IIN_OC_FAULT_LIMIT or IOUT_OC_FAULT_LIMIT register.
 currX_alarm             Current high alarm.
                         From IIN_OC_WARNING or IOUT_OC_WARNING status.
+currX_max_alarm         Current high alarm.
+                        From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT status.
 currX_lcrit_alarm       Output current critical low alarm.
                         From IOUT_UC_FAULT status.
 currX_crit_alarm        Current critical high alarm.
                         From IIN_OC_FAULT or IOUT_OC_FAULT status.
-currX_label             "iin" or "vinY"
+currX_label             "iin" or "ioutY"
 
 powerX_input            Measured power. From READ_PIN or READ_POUT register.
 powerX_cap              Output power cap. From POUT_MAX register.
@@ -193,13 +175,13 @@ powerX_crit_alarm	Output power critical high alarm.
                         From POUT_OP_FAULT status.
 powerX_label            "pin" or "poutY"
 
-tempX_input             Measured tempererature.
+tempX_input             Measured temperature.
                         From READ_TEMPERATURE_X register.
-tempX_min               Mimimum tempererature. From UT_WARN_LIMIT register.
-tempX_max               Maximum tempererature. From OT_WARN_LIMIT register.
-tempX_lcrit             Critical low tempererature.
+tempX_min               Mimimum temperature. From UT_WARN_LIMIT register.
+tempX_max               Maximum temperature. From OT_WARN_LIMIT register.
+tempX_lcrit             Critical low temperature.
                         From UT_FAULT_LIMIT register.
-tempX_crit              Critical high tempererature.
+tempX_crit              Critical high temperature.
                         From OT_FAULT_LIMIT register.
 tempX_min_alarm         Chip temperature low alarm. Set by comparing
                         READ_TEMPERATURE_X with UT_WARN_LIMIT if
diff --git a/Documentation/hwmon/smm665 b/Documentation/hwmon/smm665
index 3820fc9ca52d..59e316140542 100644
--- a/Documentation/hwmon/smm665
+++ b/Documentation/hwmon/smm665
@@ -150,8 +150,8 @@ in8_crit_alarm		Channel F critical alarm
 in9_crit_alarm          AIN1 critical alarm
 in10_crit_alarm         AIN2 critical alarm
 
-temp1_input             Chip tempererature
-temp1_min               Mimimum chip tempererature
-temp1_max               Maximum chip tempererature
-temp1_crit              Critical chip tempererature
+temp1_input             Chip temperature
+temp1_min               Mimimum chip temperature
+temp1_max               Maximum chip temperature
+temp1_crit              Critical chip temperature
 temp1_crit_alarm        Temperature critical alarm
diff --git a/Documentation/hwmon/submitting-patches b/Documentation/hwmon/submitting-patches
new file mode 100644
index 000000000000..86f42e8e9e49
--- /dev/null
+++ b/Documentation/hwmon/submitting-patches
@@ -0,0 +1,109 @@
+        How to Get Your Patch Accepted Into the Hwmon Subsystem
+        -------------------------------------------------------
+
+This text is is a collection of suggestions for people writing patches or
+drivers for the hwmon subsystem. Following these suggestions will greatly
+increase the chances of your change being accepted.
+
+
+1. General
+----------
+
+* It should be unnecessary to mention, but please read and follow
+    Documentation/SubmitChecklist
+    Documentation/SubmittingDrivers
+    Documentation/SubmittingPatches
+    Documentation/CodingStyle
+
+* If your patch generates checkpatch warnings, please refrain from explanations
+  such as "I don't like that coding style". Keep in mind that each unnecessary
+  warning helps hiding a real problem. If you don't like the kernel coding
+  style, don't write kernel drivers.
+
+* Please test your patch thoroughly. We are not your test group.
+  Sometimes a patch can not or not completely be tested because of missing
+  hardware. In such cases, you should test-build the code on at least one
+  architecture. If run-time testing was not achieved, it should be written
+  explicitly below the patch header.
+
+* If your patch (or the driver) is affected by configuration options such as
+  CONFIG_SMP or CONFIG_HOTPLUG, make sure it compiles for all configuration
+  variants.
+
+
+2. Adding functionality to existing drivers
+-------------------------------------------
+
+* Make sure the documentation in Documentation/hwmon/<driver_name> is up to
+  date.
+
+* Make sure the information in Kconfig is up to date.
+
+* If the added functionality requires some cleanup or structural changes, split
+  your patch into a cleanup part and the actual addition. This makes it easier
+  to review your changes, and to bisect any resulting problems.
+
+* Never mix bug fixes, cleanup, and functional enhancements in a single patch.
+
+
+3. New drivers
+--------------
+
+* Running your patch or driver file(s) through checkpatch does not mean its
+  formatting is clean. If unsure about formatting in your new driver, run it
+  through Lindent. Lindent is not perfect, and you may have to do some minor
+  cleanup, but it is a good start.
+
+* Consider adding yourself to MAINTAINERS.
+
+* Document the driver in Documentation/hwmon/<driver_name>.
+
+* Add the driver to Kconfig and Makefile in alphabetical order.
+
+* Make sure that all dependencies are listed in Kconfig. For new drivers, it
+  is most likely prudent to add a dependency on EXPERIMENTAL.
+
+* Avoid forward declarations if you can. Rearrange the code if necessary.
+
+* Avoid calculations in macros and macro-generated functions. While such macros
+  may save a line or so in the source, it obfuscates the code and makes code
+  review more difficult. It may also result in code which is more complicated
+  than necessary. Use inline functions or just regular functions instead.
+
+* If the driver has a detect function, make sure it is silent. Debug messages
+  and messages printed after a successful detection are acceptable, but it
+  must not print messages such as "Chip XXX not found/supported".
+
+  Keep in mind that the detect function will run for all drivers supporting an
+  address if a chip is detected on that address. Unnecessary messages will just
+  pollute the kernel log and not provide any value.
+
+* Provide a detect function if and only if a chip can be detected reliably.
+
+* Avoid writing to chip registers in the detect function. If you have to write,
+  only do it after you have already gathered enough data to be certain that the
+  detection is going to be successful.
+
+  Keep in mind that the chip might not be what your driver believes it is, and
+  writing to it might cause a bad misconfiguration.
+
+* Make sure there are no race conditions in the probe function. Specifically,
+  completely initialize your chip first, then create sysfs entries and register
+  with the hwmon subsystem.
+
+* Do not provide support for deprecated sysfs attributes.
+
+* Do not create non-standard attributes unless really needed. If you have to use
+  non-standard attributes, or you believe you do, discuss it on the mailing list
+  first. Either case, provide a detailed explanation why you need the
+  non-standard attribute(s).
+  Standard attributes are specified in Documentation/hwmon/sysfs-interface.
+
+* When deciding which sysfs attributes to support, look at the chip's
+  capabilities. While we do not expect your driver to support everything the
+  chip may offer, it should at least support all limits and alarms.
+
+* Last but not least, please check if a driver for your chip already exists
+  before starting to write a new driver. Especially for temperature sensors,
+  new chips are often variants of previously released chips. In some cases,
+  a presumably new chip may simply have been relabeled.
diff --git a/Documentation/input/event-codes.txt b/Documentation/input/event-codes.txt
new file mode 100644
index 000000000000..23fcb05175be
--- /dev/null
+++ b/Documentation/input/event-codes.txt
@@ -0,0 +1,262 @@
+The input protocol uses a map of types and codes to express input device values
+to userspace. This document describes the types and codes and how and when they
+may be used.
+
+A single hardware event generates multiple input events. Each input event
+contains the new value of a single data item. A special event type, EV_SYN, is
+used to separate input events into packets of input data changes occurring at
+the same moment in time. In the following, the term "event" refers to a single
+input event encompassing a type, code, and value.
+
+The input protocol is a stateful protocol. Events are emitted only when values
+of event codes have changed. However, the state is maintained within the Linux
+input subsystem; drivers do not need to maintain the state and may attempt to
+emit unchanged values without harm. Userspace may obtain the current state of
+event code values using the EVIOCG* ioctls defined in linux/input.h. The event
+reports supported by a device are also provided by sysfs in
+class/input/event*/device/capabilities/, and the properties of a device are
+provided in class/input/event*/device/properties.
+
+Types:
+==========
+Types are groupings of codes under a logical input construct. Each type has a
+set of applicable codes to be used in generating events. See the Codes section
+for details on valid codes for each type.
+
+* EV_SYN:
+  - Used as markers to separate events. Events may be separated in time or in
+    space, such as with the multitouch protocol.
+
+* EV_KEY:
+  - Used to describe state changes of keyboards, buttons, or other key-like
+    devices.
+
+* EV_REL:
+  - Used to describe relative axis value changes, e.g. moving the mouse 5 units
+    to the left.
+
+* EV_ABS:
+  - Used to describe absolute axis value changes, e.g. describing the
+    coordinates of a touch on a touchscreen.
+
+* EV_MSC:
+  - Used to describe miscellaneous input data that do not fit into other types.
+
+* EV_SW:
+  - Used to describe binary state input switches.
+
+* EV_LED:
+  - Used to turn LEDs on devices on and off.
+
+* EV_SND:
+  - Used to output sound to devices.
+
+* EV_REP:
+  - Used for autorepeating devices.
+
+* EV_FF:
+  - Used to send force feedback commands to an input device.
+
+* EV_PWR:
+  - A special type for power button and switch input.
+
+* EV_FF_STATUS:
+  - Used to receive force feedback device status.
+
+Codes:
+==========
+Codes define the precise type of event.
+
+EV_SYN:
+----------
+EV_SYN event values are undefined. Their usage is defined only by when they are
+sent in the evdev event stream.
+
+* SYN_REPORT:
+  - Used to synchronize and separate events into packets of input data changes
+    occurring at the same moment in time. For example, motion of a mouse may set
+    the REL_X and REL_Y values for one motion, then emit a SYN_REPORT. The next
+    motion will emit more REL_X and REL_Y values and send another SYN_REPORT.
+
+* SYN_CONFIG:
+  - TBD
+
+* SYN_MT_REPORT:
+  - Used to synchronize and separate touch events. See the
+    multi-touch-protocol.txt document for more information.
+
+* SYN_DROPPED:
+  - Used to indicate buffer overrun in the evdev client's event queue.
+    Client should ignore all events up to and including next SYN_REPORT
+    event and query the device (using EVIOCG* ioctls) to obtain its
+    current state.
+
+EV_KEY:
+----------
+EV_KEY events take the form KEY_<name> or BTN_<name>. For example, KEY_A is used
+to represent the 'A' key on a keyboard. When a key is depressed, an event with
+the key's code is emitted with value 1. When the key is released, an event is
+emitted with value 0. Some hardware send events when a key is repeated. These
+events have a value of 2. In general, KEY_<name> is used for keyboard keys, and
+BTN_<name> is used for other types of momentary switch events.
+
+A few EV_KEY codes have special meanings:
+
+* BTN_TOOL_<name>:
+  - These codes are used in conjunction with input trackpads, tablets, and
+    touchscreens. These devices may be used with fingers, pens, or other tools.
+    When an event occurs and a tool is used, the corresponding BTN_TOOL_<name>
+    code should be set to a value of 1. When the tool is no longer interacting
+    with the input device, the BTN_TOOL_<name> code should be reset to 0. All
+    trackpads, tablets, and touchscreens should use at least one BTN_TOOL_<name>
+    code when events are generated.
+
+* BTN_TOUCH:
+    BTN_TOUCH is used for touch contact. While an input tool is determined to be
+    within meaningful physical contact, the value of this property must be set
+    to 1. Meaningful physical contact may mean any contact, or it may mean
+    contact conditioned by an implementation defined property. For example, a
+    touchpad may set the value to 1 only when the touch pressure rises above a
+    certain value. BTN_TOUCH may be combined with BTN_TOOL_<name> codes. For
+    example, a pen tablet may set BTN_TOOL_PEN to 1 and BTN_TOUCH to 0 while the
+    pen is hovering over but not touching the tablet surface.
+
+Note: For appropriate function of the legacy mousedev emulation driver,
+BTN_TOUCH must be the first evdev code emitted in a synchronization frame.
+
+Note: Historically a touch device with BTN_TOOL_FINGER and BTN_TOUCH was
+interpreted as a touchpad by userspace, while a similar device without
+BTN_TOOL_FINGER was interpreted as a touchscreen. For backwards compatibility
+with current userspace it is recommended to follow this distinction. In the
+future, this distinction will be deprecated and the device properties ioctl
+EVIOCGPROP, defined in linux/input.h, will be used to convey the device type.
+
+* BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, BTN_TOOL_QUADTAP:
+  - These codes denote one, two, three, and four finger interaction on a
+    trackpad or touchscreen. For example, if the user uses two fingers and moves
+    them on the touchpad in an effort to scroll content on screen,
+    BTN_TOOL_DOUBLETAP should be set to value 1 for the duration of the motion.
+    Note that all BTN_TOOL_<name> codes and the BTN_TOUCH code are orthogonal in
+    purpose. A trackpad event generated by finger touches should generate events
+    for one code from each group. At most only one of these BTN_TOOL_<name>
+    codes should have a value of 1 during any synchronization frame.
+
+Note: Historically some drivers emitted multiple of the finger count codes with
+a value of 1 in the same synchronization frame. This usage is deprecated.
+
+Note: In multitouch drivers, the input_mt_report_finger_count() function should
+be used to emit these codes. Please see multi-touch-protocol.txt for details.
+
+EV_REL:
+----------
+EV_REL events describe relative changes in a property. For example, a mouse may
+move to the left by a certain number of units, but its absolute position in
+space is unknown. If the absolute position is known, EV_ABS codes should be used
+instead of EV_REL codes.
+
+A few EV_REL codes have special meanings:
+
+* REL_WHEEL, REL_HWHEEL:
+  - These codes are used for vertical and horizontal scroll wheels,
+    respectively.
+
+EV_ABS:
+----------
+EV_ABS events describe absolute changes in a property. For example, a touchpad
+may emit coordinates for a touch location.
+
+A few EV_ABS codes have special meanings:
+
+* ABS_DISTANCE:
+  - Used to describe the distance of a tool from an interaction surface. This
+    event should only be emitted while the tool is hovering, meaning in close
+    proximity of the device and while the value of the BTN_TOUCH code is 0. If
+    the input device may be used freely in three dimensions, consider ABS_Z
+    instead.
+
+* ABS_MT_<name>:
+  - Used to describe multitouch input events. Please see
+    multi-touch-protocol.txt for details.
+
+EV_SW:
+----------
+EV_SW events describe stateful binary switches. For example, the SW_LID code is
+used to denote when a laptop lid is closed.
+
+Upon binding to a device or resuming from suspend, a driver must report
+the current switch state. This ensures that the device, kernel, and userspace
+state is in sync.
+
+Upon resume, if the switch state is the same as before suspend, then the input
+subsystem will filter out the duplicate switch state reports. The driver does
+not need to keep the state of the switch at any time.
+
+EV_MSC:
+----------
+EV_MSC events are used for input and output events that do not fall under other
+categories.
+
+EV_LED:
+----------
+EV_LED events are used for input and output to set and query the state of
+various LEDs on devices.
+
+EV_REP:
+----------
+EV_REP events are used for specifying autorepeating events.
+
+EV_SND:
+----------
+EV_SND events are used for sending sound commands to simple sound output
+devices.
+
+EV_FF:
+----------
+EV_FF events are used to initialize a force feedback capable device and to cause
+such device to feedback.
+
+EV_PWR:
+----------
+EV_PWR events are a special type of event used specifically for power
+mangement. Its usage is not well defined. To be addressed later.
+
+Guidelines:
+==========
+The guidelines below ensure proper single-touch and multi-finger functionality.
+For multi-touch functionality, see the multi-touch-protocol.txt document for
+more information.
+
+Mice:
+----------
+REL_{X,Y} must be reported when the mouse moves. BTN_LEFT must be used to report
+the primary button press. BTN_{MIDDLE,RIGHT,4,5,etc.} should be used to report
+further buttons of the device. REL_WHEEL and REL_HWHEEL should be used to report
+scroll wheel events where available.
+
+Touchscreens:
+----------
+ABS_{X,Y} must be reported with the location of the touch. BTN_TOUCH must be
+used to report when a touch is active on the screen.
+BTN_{MOUSE,LEFT,MIDDLE,RIGHT} must not be reported as the result of touch
+contact. BTN_TOOL_<name> events should be reported where possible.
+
+Trackpads:
+----------
+Legacy trackpads that only provide relative position information must report
+events like mice described above.
+
+Trackpads that provide absolute touch position must report ABS_{X,Y} for the
+location of the touch. BTN_TOUCH should be used to report when a touch is active
+on the trackpad. Where multi-finger support is available, BTN_TOOL_<name> should
+be used to report the number of touches active on the trackpad.
+
+Tablets:
+----------
+BTN_TOOL_<name> events must be reported when a stylus or other tool is active on
+the tablet. ABS_{X,Y} must be reported with the location of the tool. BTN_TOUCH
+should be used to report when the tool is in contact with the tablet.
+BTN_{STYLUS,STYLUS2} should be used to report buttons on the tool itself. Any
+button may be used for buttons on the tablet except BTN_{MOUSE,LEFT}.
+BTN_{0,1,2,etc} are good generic codes for unlabeled buttons. Do not use
+meaningful buttons, like BTN_FORWARD, unless the button is labeled for that
+purpose on the device.
diff --git a/Documentation/ja_JP/HOWTO b/Documentation/ja_JP/HOWTO
index b63301a03811..050d37fe6d40 100644
--- a/Documentation/ja_JP/HOWTO
+++ b/Documentation/ja_JP/HOWTO
@@ -11,14 +11,14 @@ for non English (read: Japanese) speakers and is not intended as a
 fork. So if you have any comments or updates for this file, please try
 to update the original English file first.
 
-Last Updated: 2008/10/24
+Last Updated: 2011/03/31
 ==================================
 これは、
-linux-2.6.28/Documentation/HOWTO
+linux-2.6.38/Documentation/HOWTO
 の和訳です。
 
 翻訳団体： JF プロジェクト < http://www.linux.or.jp/JF/ >
-翻訳日： 2008/10/24
+翻訳日： 2011/3/28
 翻訳者： Tsugikazu Shibata <tshibata at ab dot jp dot nec dot com>
 校正者： 松倉さん <nbh--mats at nifty dot com>
          小林 雅典さん (Masanori Kobayasi) <zap03216 at nifty dot ne dot jp>
@@ -256,8 +256,8 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン�
   - メインの 2.6.x カーネルツリー
   - 2.6.x.y -stable カーネルツリー
   - 2.6.x -git カーネルパッチ
-  - 2.6.x -mm カーネルパッチ
   - サブシステム毎のカーネルツリーとパッチ
+  - 統合テストのための 2.6.x -next カーネルツリー
 
 2.6.x カーネルツリー
 -----------------
@@ -268,9 +268,9 @@ Linux カーネルの開発プロセスは現在幾つかの異なるメイン�
 
   - 新しいカーネルがリリースされた直後に、2週間の特別期間が設けられ、
     この期間中に、メンテナ達は Linus に大きな差分を送ることができます。
-    このような差分は通常 -mm カーネルに数週間含まれてきたパッチです。
+    このような差分は通常 -next カーネルに数週間含まれてきたパッチです。
     大きな変更は git(カーネルのソース管理ツール、詳細は
-    http://git.or.cz/  参照) を使って送るのが好ましいやり方ですが、パッ
+    http://git-scm.com/  参照) を使って送るのが好ましいやり方ですが、パッ
     チファイルの形式のまま送るのでも十分です。
 
   - 2週間後、-rc1 カーネルがリリースされ、この後にはカーネル全体の安定
@@ -333,86 +333,44 @@ git リポジトリで管理されているLinus のカーネルツリーの毎�
 れは -rc カーネルと比べて、パッチが大丈夫かどうかも確認しないで自動的
 に生成されるので、より実験的です。
 
-2.6.x -mm カーネルパッチ
-------------------------
-
-Andrew Morton によってリリースされる実験的なカーネルパッチ群です。
-Andrew は個別のサブシステムカーネルツリーとパッチを全て集めてきて
-linux-kernel メーリングリストで収集された多数のパッチと同時に一つにま
-とめます。
-このツリーは新機能とパッチが検証される場となります。ある期間の間パッチ
-が -mm に入って価値を証明されたら、Andrew やサブシステムメンテナが、
-メインラインへ入れるように Linus にプッシュします。
-
-メインカーネルツリーに含めるために Linus に送る前に、すべての新しいパッ
-チが -mm ツリーでテストされることが強く推奨されています。マージウィン
-ドウが開く前に -mm ツリーに現れなかったパッチはメインラインにマージさ
-れることは困難になります。
-
-これらのカーネルは安定して動作すべきシステムとして使うのには適切ではあ
-りませんし、カーネルブランチの中でももっとも動作にリスクが高いものです。
-
-もしあなたが、カーネル開発プロセスの支援をしたいと思っているのであれば、
-どうぞこれらのカーネルリリースをテストに使ってみて、そしてもし問題があ
-れば、またもし全てが正しく動作したとしても、linux-kernel メーリングリ
-ストにフィードバックを提供してください。
-
-すべての他の実験的パッチに加えて、これらのカーネルは通常リリース時点で
-メインラインの -git カーネルに含まれる全ての変更も含んでいます。
-
--mm カーネルは決まったスケジュールではリリースされません、しかし通常幾
-つかの -mm カーネル (1 から 3 が普通）が各-rc カーネルの間にリリースさ
-れます。
-
 サブシステム毎のカーネルツリーとパッチ
 -------------------------------------------
 
-カーネルの様々な領域で何が起きているかを見られるようにするため、多くの
-カーネルサブシステム開発者は彼らの開発ツリーを公開しています。これらの
-ツリーは説明したように -mm カーネルリリースに入れ込まれます。
-
-以下はさまざまなカーネルツリーの中のいくつかのリスト-
-
-  git ツリー-
-    - Kbuild の開発ツリー、Sam Ravnborg <sam@ravnborg.org>
-        git.kernel.org:/pub/scm/linux/kernel/git/sam/kbuild.git
-
-    - ACPI の開発ツリー、 Len Brown <len.brown@intel.com>
-        git.kernel.org:/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git
-
-    - Block の開発ツリー、Jens Axboe <axboe@suse.de>
-        git.kernel.org:/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git
-
-    - DRM の開発ツリー、Dave Airlie <airlied@linux.ie>
-        git.kernel.org:/pub/scm/linux/kernel/git/airlied/drm-2.6.git
-
-    - ia64 の開発ツリー、Tony Luck <tony.luck@intel.com>
-        git.kernel.org:/pub/scm/linux/kernel/git/aegl/linux-2.6.git
-
-    - infiniband, Roland Dreier <rolandd@cisco.com>
-        git.kernel.org:/pub/scm/linux/kernel/git/roland/infiniband.git
-
-    - libata, Jeff Garzik <jgarzik@pobox.com>
-        git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
-
-    - ネットワークドライバ, Jeff Garzik <jgarzik@pobox.com>
-        git.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
-
-    - pcmcia, Dominik Brodowski <linux@dominikbrodowski.net>
-        git.kernel.org:/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git
-
-    - SCSI, James Bottomley <James.Bottomley@hansenpartnership.com>
-        git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
-
-    - x86, Ingo Molnar <mingo@elte.hu>
-        git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
-
-  quilt ツリー-
-    - USB, ドライバコアと I2C, Greg Kroah-Hartman <gregkh@suse.de>
-        kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
+それぞれのカーネルサブシステムのメンテナ達は --- そして多くのカーネル
+サブシステムの開発者達も --- 各自の最新の開発状況をソースリポジトリに
+公開しています。そのため、自分とは異なる領域のカーネルで何が起きている
+かを他の人が見られるようになっています。開発が早く進んでいる領域では、
+開発者は自身の投稿がどのサブシステムカーネルツリーを元にしているか質問
+されるので、その投稿とすでに進行中の他の作業との衝突が避けられます。
+
+大部分のこれらのリポジトリは git ツリーです。しかしその他の SCM や
+quilt シリーズとして公開されているパッチキューも使われています。これら
+のサブシステムリポジトリのアドレスは MAINTAINERS ファイルにリストされ
+ています。これらの多くは http://git.kernel.org/ で参照することができま
+す。
 
-  その他のカーネルツリーは http://git.kernel.org/ と MAINTAINERS ファ
-  イルに一覧表があります。
+提案されたパッチがこのようなサブシステムツリーにコミットされる前に、メー
+リングリストで事前にレビューにかけられます（以下の対応するセクションを
+参照）。いくつかのカーネルサブシステムでは、このレビューは patchwork
+というツールによって追跡されます。Patchwork は web インターフェイスに
+よってパッチ投稿の表示、パッチへのコメント付けや改訂などができ、そして
+メンテナはパッチに対して、レビュー中、受付済み、拒否というようなマーク
+をつけることができます。大部分のこれらの patchwork のサイトは
+http://patchwork.kernel.org/ でリストされています。
+
+統合テストのための 2.6.x -next カーネルツリー
+---------------------------------------------
+
+サブシステムツリーの更新内容がメインラインの 2.6.x ツリーにマージされ
+る前に、それらは統合テストされる必要があります。この目的のため、実質的
+に全サブシステムツリーからほぼ毎日プルされてできる特別なテスト用のリ
+ポジトリが存在します-
+       http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
+       http://linux.f-seidel.de/linux-next/pmwiki/
+
+このやり方によって、-next カーネルは次のマージ機会でどんなものがメイン
+ラインカーネルにマージされるか、おおまかなの展望を提供します。-next 
+カーネルの実行テストを行う冒険好きなテスターは大いに歓迎されます
 
 バグレポート
 -------------
@@ -673,10 +631,9 @@ Linux カーネルコミュニティは、一度に大量のコードの塊を�
 じところからスタートしたのですから。
 
 Paolo Ciarrocchi に感謝、彼は彼の書いた "Development Process"
-(http://linux.tar.bz/articles/2.6-development_process)セクショ
-ンをこのテキストの原型にすることを許可してくれました。
-Rundy Dunlap と Gerrit Huizenga はメーリングリストでやるべきこととやっ
-てはいけないことのリストを提供してくれました。
+(http://lwn.net/Articles/94386/) セクションをこのテキストの原型にする
+ことを許可してくれました。Rundy Dunlap と Gerrit Huizenga はメーリング
+リストでやるべきこととやってはいけないことのリストを提供してくれました。
 以下の人々のレビュー、コメント、貢献に感謝。
 Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
 Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index cc85a9278190..c603ef7b0568 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -245,7 +245,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
 
         acpi_sleep=     [HW,ACPI] Sleep options
                         Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
-                                  old_ordering, s4_nonvs, sci_force_enable }
+                                  old_ordering, nonvs, sci_force_enable }
                         See Documentation/power/video.txt for information on
                         s3_bios and s3_mode.
                         s3_beep is for debugging; it makes the PC's speaker beep
@@ -1664,6 +1664,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                         noexec=on: enable non-executable mappings (default)
                         noexec=off: disable non-executable mappings
 
+        nosmep          [X86]
+                        Disable SMEP (Supervisor Mode Execution Protection)
+                        even if it is supported by processor.
+
         noexec32        [X86-64]
                         This affects only 32-bit executables.
                         noexec32=on: enable non-executable mappings (default)
diff --git a/Documentation/md.txt b/Documentation/md.txt
index a81c7b4790f2..2366b1c8cf19 100644
--- a/Documentation/md.txt
+++ b/Documentation/md.txt
@@ -552,6 +552,16 @@ also have
      within the array where IO will be blocked.  This is currently
      only supported for raid4/5/6.
 
+   sync_min
+   sync_max
+     The two values, given as numbers of sectors, indicate a range
+     withing the array where 'check'/'repair' will operate. Must be
+     a multiple of chunk_size. When it reaches "sync_max" it will
+     pause, rather than complete.
+     You can use 'select' or 'poll' on "sync_completed" to wait for
+     that number to reach sync_max.  Then you can either increase
+     "sync_max", or can write 'idle' to "sync_action".
+
 
 Each active md device may also have attributes specific to the
 personality module that manages it.
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index 1971bcf48a60..88880839ece4 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -279,11 +279,15 @@ When the system goes into the standby or memory sleep state, the phases are:
         time.)  Unlike the other suspend-related phases, during the prepare
         phase the device tree is traversed top-down.
 
-        The prepare phase uses only a bus callback.  After the callback method
-        returns, no new children may be registered below the device.  The method
-        may also prepare the device or driver in some way for the upcoming
-        system power transition, but it should not put the device into a
-        low-power state.
+        In addition to that, if device drivers need to allocate additional
+        memory to be able to hadle device suspend correctly, that should be
+        done in the prepare phase.
+
+        After the prepare callback method returns, no new children may be
+        registered below the device.  The method may also prepare the device or
+        driver in some way for the upcoming system power transition (for
+        example, by allocating additional memory required for this purpose), but
+        it should not put the device into a low-power state.
 
     2.  The suspend methods should quiesce the device to stop it from performing
         I/O.  They also may save the device registers and put it into the
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt
index cf980709122a..c2a4a346c0d9 100644
--- a/Documentation/power/notifiers.txt
+++ b/Documentation/power/notifiers.txt
@@ -1,46 +1,41 @@
 Suspend notifiers
-        (C) 2007 Rafael J. Wysocki <rjw@sisk.pl>, GPL
-
-There are some operations that device drivers may want to carry out in their
-.suspend() routines, but shouldn't, because they can cause the hibernation or
-suspend to fail. For example, a driver may want to allocate a substantial amount
-of memory (like 50 MB) in .suspend(), but that shouldn't be done after the
-swsusp's memory shrinker has run.
-
-Also, there may be some operations, that subsystems want to carry out before a
-hibernation/suspend or after a restore/resume, requiring the system to be fully
-functional, so the drivers' .suspend() and .resume() routines are not suitable
-for this purpose.  For example, device drivers may want to upload firmware to
-their devices after a restore from a hibernation image, but they cannot do it by
-calling request_firmware() from their .resume() routines (user land processes
-are frozen at this point).  The solution may be to load the firmware into
-memory before processes are frozen and upload it from there in the .resume()
-routine.  Of course, a hibernation notifier may be used for this purpose.
-
-The subsystems that have such needs can register suspend notifiers that will be
-called upon the following events by the suspend core:
+        (C) 2007-2011 Rafael J. Wysocki <rjw@sisk.pl>, GPL
+
+There are some operations that subsystems or drivers may want to carry out
+before hibernation/suspend or after restore/resume, but they require the system
+to be fully functional, so the drivers' and subsystems' .suspend() and .resume()
+or even .prepare() and .complete() callbacks are not suitable for this purpose.
+For example, device drivers may want to upload firmware to their devices after
+resume/restore, but they cannot do it by calling request_firmware() from their
+.resume() or .complete() routines (user land processes are frozen at these
+points).  The solution may be to load the firmware into memory before processes
+are frozen and upload it from there in the .resume() routine.
+A suspend/hibernation notifier may be used for this purpose.
+
+The subsystems or drivers having such needs can register suspend notifiers that
+will be called upon the following events by the PM core:
 
 PM_HIBERNATION_PREPARE  The system is going to hibernate or suspend, tasks will
                         be frozen immediately.
 
 PM_POST_HIBERNATION     The system memory state has been restored from a
-                        hibernation image or an error occurred during the
-                        hibernation.  Device drivers' .resume() callbacks have
+                        hibernation image or an error occurred during
+                        hibernation.  Device drivers' restore callbacks have
                         been executed and tasks have been thawed.
 
 PM_RESTORE_PREPARE      The system is going to restore a hibernation image.
-                        If all goes well the restored kernel will issue a
+                        If all goes well, the restored kernel will issue a
                         PM_POST_HIBERNATION notification.
 
-PM_POST_RESTORE         An error occurred during the hibernation restore.
-                        Device drivers' .resume() callbacks have been executed
+PM_POST_RESTORE         An error occurred during restore from hibernation.
+                        Device drivers' restore callbacks have been executed
                         and tasks have been thawed.
 
-PM_SUSPEND_PREPARE      The system is preparing for a suspend.
+PM_SUSPEND_PREPARE      The system is preparing for suspend.
 
 PM_POST_SUSPEND         The system has just resumed or an error occurred during
-                        the suspend.    Device drivers' .resume() callbacks have
-                        been executed and tasks have been thawed.
+                        suspend.  Device drivers' resume callbacks have been
+                        executed and tasks have been thawed.
 
 It is generally assumed that whatever the notifiers do for
 PM_HIBERNATION_PREPARE, should be undone for PM_POST_HIBERNATION.  Analogously,
diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx
index 9e15b4f9cd28..19e7cd4bba66 100644
--- a/Documentation/scsi/LICENSE.qla2xxx
+++ b/Documentation/scsi/LICENSE.qla2xxx
@@ -1,11 +1,11 @@
-Copyright (c)  2003-2005 QLogic Corporation
-QLogic Linux Fibre Channel HBA Driver
+Copyright (c) 2003-2011 QLogic Corporation
+QLogic Linux/ESX Fibre Channel HBA Driver
 
-This program includes a device driver for Linux 2.6 that may be
+This program includes a device driver for Linux 2.6/ESX that may be
 distributed with QLogic hardware specific firmware binary file.
 You may modify and redistribute the device driver code under the
-GNU General Public License as published by the Free Software
-Foundation (version 2 or a later version).
+GNU General Public License (a copy of which is attached hereto as
+Exhibit A) published by the Free Software Foundation (version 2).
 
 You may redistribute the hardware specific firmware binary file
 under the following terms:
@@ -43,3 +43,285 @@ OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT,
 TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN
 ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN
 COMBINATION WITH THIS PROGRAM.
+
+
+EXHIBIT A
+
+                    GNU GENERAL PUBLIC LICENSE
+                       Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.
+ 51 Franklin Street, Fifth Floor, Boston, MA  02110-1301  USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+                            Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Lesser General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+                    GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in exchange for a fee.
+
+  2. You may modify your copy or copies of the Program or any portion
+of it, thus forming a work based on the Program, and copy and
+distribute such modifications or work under the terms of Section 1
+above, provided that you also meet all of these conditions:
+
+    a) You must cause the modified files to carry prominent notices
+    stating that you changed the files and the date of any change.
+
+    b) You must cause any work that you distribute or publish, that in
+    whole or in part contains or is derived from the Program or any
+    part thereof, to be licensed as a whole at no charge to all third
+    parties under the terms of this License.
+
+    c) If the modified program normally reads commands interactively
+    when run, you must cause it, when started running for such
+    interactive use in the most ordinary way, to print or display an
+    announcement including an appropriate copyright notice and a
+    notice that there is no warranty (or else, saying that you provide
+    a warranty) and that users may redistribute the program under
+    these conditions, and telling the user how to view a copy of this
+    License.  (Exception: if the Program itself is interactive but
+    does not normally print such an announcement, your work based on
+    the Program is not required to print an announcement.)
+
+These requirements apply to the modified work as a whole.  If
+identifiable sections of that work are not derived from the Program,
+and can be reasonably considered independent and separate works in
+themselves, then this License, and its terms, do not apply to those
+sections when you distribute them as separate works.  But when you
+distribute the same sections as part of a whole which is a work based
+on the Program, the distribution of the whole must be on the terms of
+this License, whose permissions for other licensees extend to the
+entire whole, and thus to each and every part regardless of who wrote it.
+
+Thus, it is not the intent of this section to claim rights or contest
+your rights to work written entirely by you; rather, the intent is to
+exercise the right to control the distribution of derivative or
+collective works based on the Program.
+
+In addition, mere aggregation of another work not based on the Program
+with the Program (or with a work based on the Program) on a volume of
+a storage or distribution medium does not bring the other work under
+the scope of this License.
+
+  3. You may copy and distribute the Program (or a work based on it,
+under Section 2) in object code or executable form under the terms of
+Sections 1 and 2 above provided that you also do one of the following:
+
+    a) Accompany it with the complete corresponding machine-readable
+    source code, which must be distributed under the terms of Sections
+    1 and 2 above on a medium customarily used for software interchange; or,
+
+    b) Accompany it with a written offer, valid for at least three
+    years, to give any third party, for a charge no more than your
+    cost of physically performing source distribution, a complete
+    machine-readable copy of the corresponding source code, to be
+    distributed under the terms of Sections 1 and 2 above on a medium
+    customarily used for software interchange; or,
+
+    c) Accompany it with the information you received as to the offer
+    to distribute corresponding source code.  (This alternative is
+    allowed only for noncommercial distribution and only if you
+    received the program in object code or executable form with such
+    an offer, in accord with Subsection b above.)
+
+The source code for a work means the preferred form of the work for
+making modifications to it.  For an executable work, complete source
+code means all the source code for all modules it contains, plus any
+associated interface definition files, plus the scripts used to
+control compilation and installation of the executable.  However, as a
+special exception, the source code distributed need not include
+anything that is normally distributed (in either source or binary
+form) with the major components (compiler, kernel, and so on) of the
+operating system on which the executable runs, unless that component
+itself accompanies the executable.
+
+If distribution of executable or object code is made by offering
+access to copy from a designated place, then offering equivalent
+access to copy the source code from the same place counts as
+distribution of the source code, even though third parties are not
+compelled to copy the source along with the object code.
+
+  4. You may not copy, modify, sublicense, or distribute the Program
+except as expressly provided under this License.  Any attempt
+otherwise to copy, modify, sublicense or distribute the Program is
+void, and will automatically terminate your rights under this License.
+However, parties who have received copies, or rights, from you under
+this License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
+  5. You are not required to accept this License, since you have not
+signed it.  However, nothing else grants you permission to modify or
+distribute the Program or its derivative works.  These actions are
+prohibited by law if you do not accept this License.  Therefore, by
+modifying or distributing the Program (or any work based on the
+Program), you indicate your acceptance of this License to do so, and
+all its terms and conditions for copying, distributing or modifying
+the Program or works based on it.
+
+  6. Each time you redistribute the Program (or any work based on the
+Program), the recipient automatically receives a license from the
+original licensor to copy, distribute or modify the Program subject to
+these terms and conditions.  You may not impose any further
+restrictions on the recipients' exercise of the rights granted herein.
+You are not responsible for enforcing compliance by third parties to
+this License.
+
+  7. If, as a consequence of a court judgment or allegation of patent
+infringement or for any other reason (not limited to patent issues),
+conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot
+distribute so as to satisfy simultaneously your obligations under this
+License and any other pertinent obligations, then as a consequence you
+may not distribute the Program at all.  For example, if a patent
+license would not permit royalty-free redistribution of the Program by
+all those who receive copies directly or indirectly through you, then
+the only way you could satisfy both it and this License would be to
+refrain entirely from distribution of the Program.
+
+If any portion of this section is held invalid or unenforceable under
+any particular circumstance, the balance of the section is intended to
+apply and the section as a whole is intended to apply in other
+circumstances.
+
+It is not the purpose of this section to induce you to infringe any
+patents or other property right claims or to contest validity of any
+such claims; this section has the sole purpose of protecting the
+integrity of the free software distribution system, which is
+implemented by public license practices.  Many people have made
+generous contributions to the wide range of software distributed
+through that system in reliance on consistent application of that
+system; it is up to the author/donor to decide if he or she is willing
+to distribute software through any other system and a licensee cannot
+impose that choice.
+
+This section is intended to make thoroughly clear what is believed to
+be a consequence of the rest of this License.
+
+  8. If the distribution and/or use of the Program is restricted in
+certain countries either by patents or by copyrighted interfaces, the
+original copyright holder who places the Program under this License
+may add an explicit geographical distribution limitation excluding
+those countries, so that distribution is permitted only in or among
+countries not thus excluded.  In such case, this License incorporates
+the limitation as if written in the body of this License.
+
+  9. The Free Software Foundation may publish revised and/or new versions
+of the General Public License from time to time.  Such new versions will
+be similar in spirit to the present version, but may differ in detail to
+address new problems or concerns.
+
+Each version is given a distinguishing version number.  If the Program
+specifies a version number of this License which applies to it and "any
+later version", you have the option of following the terms and conditions
+either of that version or of any later version published by the Free
+Software Foundation.  If the Program does not specify a version number of
+this License, you may choose any version ever published by the Free Software
+Foundation.
+
+  10. If you wish to incorporate parts of the Program into other free
+programs whose distribution conditions are different, write to the author
+to ask for permission.  For software which is copyrighted by the Free
+Software Foundation, write to the Free Software Foundation; we sometimes
+make exceptions for this.  Our decision will be guided by the two goals
+of preserving the free status of all derivatives of our free software and
+of promoting the sharing and reuse of software generally.
+
+                            NO WARRANTY
+
+  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
+FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
+OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
+PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
+OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
+TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
+PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
+REPAIR OR CORRECTION.
+
+  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
+REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
+OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
+TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
+YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
+POSSIBILITY OF SUCH DAMAGES.
diff --git a/Documentation/sound/alsa/SB-Live-mixer.txt b/Documentation/sound/alsa/SB-Live-mixer.txt
index f5639d40521d..f4b5988f450c 100644
--- a/Documentation/sound/alsa/SB-Live-mixer.txt
+++ b/Documentation/sound/alsa/SB-Live-mixer.txt
@@ -87,14 +87,14 @@ accumulator. ALSA uses accumulators 0 and 1 for left and right PCM.
 The result is forwarded to the ADC capture FIFO (thus to the standard capture
 PCM device).
 
-name='Music Playback Volume',index=0
+name='Synth Playback Volume',index=0
 
 This control is used to attenuate samples for left and right MIDI FX-bus
 accumulators. ALSA uses accumulators 4 and 5 for left and right MIDI samples.
 The result samples are forwarded to the front DAC PCM slots of the AC97 codec.
 
-name='Music Capture Volume',index=0
-name='Music Capture Switch',index=0
+name='Synth Capture Volume',index=0
+name='Synth Capture Switch',index=0
 
 These controls are used to attenuate samples for left and right MIDI FX-bus
 accumulator. ALSA uses accumulators 4 and 5 for left and right PCM.
diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt
index 6d27ab8d6e9f..c83bd6b4e6e8 100644
--- a/Documentation/trace/kprobetrace.txt
+++ b/Documentation/trace/kprobetrace.txt
@@ -120,7 +120,6 @@ format:
         field:unsigned char common_flags;       offset:2;       size:1; signed:0;
         field:unsigned char common_preempt_count;       offset:3; size:1;signed:0;
         field:int common_pid;   offset:4;       size:4; signed:1;
-        field:int common_lock_depth;    offset:8;       size:4; signed:1;
 
         field:unsigned long __probe_ip; offset:12;      size:4; signed:0;
         field:int __probe_nargs;        offset:16;      size:4; signed:1;
diff --git a/Documentation/video4linux/sh_mobile_ceu_camera.txt b/Documentation/video4linux/sh_mobile_ceu_camera.txt
index cb47e723af74..1e96ce6e2d2f 100644
--- a/Documentation/video4linux/sh_mobile_ceu_camera.txt
+++ b/Documentation/video4linux/sh_mobile_ceu_camera.txt
@@ -37,7 +37,7 @@ Generic scaling / cropping scheme
 -1'-
 
 In the above chart minuses and slashes represent "real" data amounts, points and
-accents represent "useful" data, basically, CEU scaled amd cropped output,
+accents represent "useful" data, basically, CEU scaled and cropped output,
 mapped back onto the client's source plane.
 
 Such a configuration can be produced by user requests:
@@ -65,7 +65,7 @@ Do not touch input rectangle - it is already optimal.
 
 1. Calculate current sensor scales:
 
-        scale_s = ((3') - (3)) / ((2') - (2))
+        scale_s = ((2') - (2)) / ((3') - (3))
 
 2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
 current sensor scales onto input window - this is user S_CROP:
@@ -80,7 +80,7 @@ window:
 4. Calculate sensor output window by applying combined scales to real input
 window:
 
-        width_s_out = ((2') - (2)) / scale_comb
+        width_s_out = ((7') - (7)) = ((2') - (2)) / scale_comb
 
 5. Apply iterative sensor S_FMT for sensor output window.
 
diff --git a/Documentation/virtual/00-INDEX b/Documentation/virtual/00-INDEX
new file mode 100644
index 000000000000..fe0251c4cfb7
--- /dev/null
+++ b/Documentation/virtual/00-INDEX
@@ -0,0 +1,10 @@
+Virtualization support in the Linux kernel.
+
+00-INDEX
+        - this file.
+kvm/
+        - Kernel Virtual Machine.  See also http://linux-kvm.org
+lguest/
+        - Extremely simple hypervisor for experimental/educational use.
+uml/
+        - User Mode Linux, builds/runs Linux kernel as a userspace program.
diff --git a/Documentation/kvm/api.txt b/Documentation/virtual/kvm/api.txt
index 9bef4e4cec50..9bef4e4cec50 100644
--- a/Documentation/kvm/api.txt
+++ b/Documentation/virtual/kvm/api.txt
diff --git a/Documentation/kvm/cpuid.txt b/Documentation/virtual/kvm/cpuid.txt
index 882068538c9c..882068538c9c 100644
--- a/Documentation/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
diff --git a/Documentation/kvm/locking.txt b/Documentation/virtual/kvm/locking.txt
index 3b4cd3bf5631..3b4cd3bf5631 100644
--- a/Documentation/kvm/locking.txt
+++ b/Documentation/virtual/kvm/locking.txt
diff --git a/Documentation/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt
index f46aa58389ca..f46aa58389ca 100644
--- a/Documentation/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
diff --git a/Documentation/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt
index d079aed27e03..d079aed27e03 100644
--- a/Documentation/kvm/msr.txt
+++ b/Documentation/virtual/kvm/msr.txt
diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt
index 3ab969c59046..3ab969c59046 100644
--- a/Documentation/kvm/ppc-pv.txt
+++ b/Documentation/virtual/kvm/ppc-pv.txt
diff --git a/Documentation/kvm/review-checklist.txt b/Documentation/virtual/kvm/review-checklist.txt
index 730475ae1b8d..a850986ed684 100644
--- a/Documentation/kvm/review-checklist.txt
+++ b/Documentation/virtual/kvm/review-checklist.txt
@@ -7,7 +7,7 @@ Review checklist for kvm patches
 2.  Patches should be against kvm.git master branch.
 
 3.  If the patch introduces or modifies a new userspace API:
-    - the API must be documented in Documentation/kvm/api.txt
+    - the API must be documented in Documentation/virtual/kvm/api.txt
     - the API must be discoverable using KVM_CHECK_EXTENSION
 
 4.  New state must include support for save/restore.
diff --git a/Documentation/kvm/timekeeping.txt b/Documentation/virtual/kvm/timekeeping.txt
index df8946377cb6..df8946377cb6 100644
--- a/Documentation/kvm/timekeeping.txt
+++ b/Documentation/virtual/kvm/timekeeping.txt
diff --git a/Documentation/lguest/.gitignore b/Documentation/virtual/lguest/.gitignore
index 115587fd5f65..115587fd5f65 100644
--- a/Documentation/lguest/.gitignore
+++ b/Documentation/virtual/lguest/.gitignore
diff --git a/Documentation/lguest/Makefile b/Documentation/virtual/lguest/Makefile
index bebac6b4f332..bebac6b4f332 100644
--- a/Documentation/lguest/Makefile
+++ b/Documentation/virtual/lguest/Makefile
diff --git a/Documentation/lguest/extract b/Documentation/virtual/lguest/extract
index 7730bb6e4b94..7730bb6e4b94 100644
--- a/Documentation/lguest/extract
+++ b/Documentation/virtual/lguest/extract
diff --git a/Documentation/lguest/lguest.c b/Documentation/virtual/lguest/lguest.c
index d9da7e148538..d9da7e148538 100644
--- a/Documentation/lguest/lguest.c
+++ b/Documentation/virtual/lguest/lguest.c
diff --git a/Documentation/lguest/lguest.txt b/Documentation/virtual/lguest/lguest.txt
index dad99978a6a8..bff0c554485d 100644
--- a/Documentation/lguest/lguest.txt
+++ b/Documentation/virtual/lguest/lguest.txt
@@ -74,7 +74,8 @@ Running Lguest:
 
 - Run an lguest as root:
 
-      Documentation/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 --block=rootfile root=/dev/vda
+      Documentation/virtual/lguest/lguest 64 vmlinux --tunnet=192.168.19.1 \
+        --block=rootfile root=/dev/vda
 
    Explanation:
     64: the amount of memory to use, in MB.
diff --git a/Documentation/uml/UserModeLinux-HOWTO.txt b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
index 9b7e1904db1c..9b7e1904db1c 100644
--- a/Documentation/uml/UserModeLinux-HOWTO.txt
+++ b/Documentation/virtual/uml/UserModeLinux-HOWTO.txt
diff --git a/Documentation/workqueue.txt b/Documentation/workqueue.txt
index 01c513fac40e..a0b577de918f 100644
--- a/Documentation/workqueue.txt
+++ b/Documentation/workqueue.txt
@@ -12,6 +12,7 @@ CONTENTS
 4. Application Programming Interface (API)
 5. Example Execution Scenarios
 6. Guidelines
+7. Debugging
 
 
 1. Introduction
@@ -379,3 +380,42 @@ If q1 has WQ_CPU_INTENSIVE set,
 * Unless work items are expected to consume a huge amount of CPU
   cycles, using a bound wq is usually beneficial due to the increased
   level of locality in wq operations and work item execution.
+
+
+7. Debugging
+
+Because the work functions are executed by generic worker threads
+there are a few tricks needed to shed some light on misbehaving
+workqueue users.
+
+Worker threads show up in the process list as:
+
+root      5671  0.0  0.0      0     0 ?        S    12:07   0:00 [kworker/0:1]
+root      5672  0.0  0.0      0     0 ?        S    12:07   0:00 [kworker/1:2]
+root      5673  0.0  0.0      0     0 ?        S    12:12   0:00 [kworker/0:0]
+root      5674  0.0  0.0      0     0 ?        S    12:13   0:00 [kworker/1:0]
+
+If kworkers are going crazy (using too much cpu), there are two types
+of possible problems:
+
+        1. Something beeing scheduled in rapid succession
+        2. A single work item that consumes lots of cpu cycles
+
+The first one can be tracked using tracing:
+
+        $ echo workqueue:workqueue_queue_work > /sys/kernel/debug/tracing/set_event
+        $ cat /sys/kernel/debug/tracing/trace_pipe > out.txt
+        (wait a few secs)
+        ^C
+
+If something is busy looping on work queueing, it would be dominating
+the output and the offender can be determined with the work item
+function.
+
+For the second type of problems it should be possible to just check
+the stack trace of the offending worker thread.
+
+        $ cat /proc/THE_OFFENDING_KWORKER/stack
+
+The work item's function should be trivially visible in the stack
+trace.
diff --git a/Documentation/x86/x86_64/boot-options.txt b/Documentation/x86/x86_64/boot-options.txt
index 092e596a1301..c54b4f503e2a 100644
--- a/Documentation/x86/x86_64/boot-options.txt
+++ b/Documentation/x86/x86_64/boot-options.txt
@@ -206,7 +206,7 @@ IOMMU (input/output memory management unit)
       (e.g. because you have < 3 GB memory).
       Kernel boot message: "PCI-DMA: Disabling IOMMU"
 
-   2. <arch/x86_64/kernel/pci-gart.c>: AMD GART based hardware IOMMU.
+   2. <arch/x86/kernel/amd_gart_64.c>: AMD GART based hardware IOMMU.
       Kernel boot message: "PCI-DMA: using GART IOMMU"
 
    3. <arch/x86_64/kernel/pci-swiotlb.c> : Software IOMMU implementation. Used
diff --git a/Documentation/zh_CN/email-clients.txt b/Documentation/zh_CN/email-clients.txt
new file mode 100644
index 000000000000..5d65e323d060
--- /dev/null
+++ b/Documentation/zh_CN/email-clients.txt
@@ -0,0 +1,210 @@
+锘?Chinese translated version of Documentation/email-clients.txt
+
+If you have any comment or update to the content, please contact the
+original document maintainer directly.  However, if you have a problem
+communicating in English you can also ask the Chinese maintainer for
+help.  Contact the Chinese maintainer if this translation is outdated
+or if there is a problem with the translation.
+
+Chinese maintainer: Harry Wei <harryxiyou@gmail.com>
+---------------------------------------------------------------------
+Documentation/email-clients.txt ???涓????缈昏??
+
+濡??????宠??璁烘????存?版???????????瀹癸??璇风?存?ヨ??绯诲?????妗ｇ??缁存?よ?????濡????浣?浣跨?ㄨ?辨??
+浜ゆ???????伴?剧??璇?锛?涔????浠ュ??涓???????缁存?よ??姹???┿??濡???????缈昏????存?颁???????舵?????缈?
+璇?瀛???ㄩ??棰?锛?璇疯??绯讳腑??????缁存?よ?????
+
+涓???????缁存?よ??锛? 璐惧??濞?  Harry Wei <harryxiyou@gmail.com>
+涓???????缈昏?????锛? 璐惧??濞?  Harry Wei <harryxiyou@gmail.com>
+涓?????????¤?????锛? Yinglin Luan <synmyth@gmail.com>
+                Xiaochen Wang <wangxiaochen0@gmail.com>
+                yaxinsn <yaxinsn@163.com>
+
+浠ヤ??涓烘?ｆ??
+---------------------------------------------------------------------
+
+Linux???浠跺?㈡?风?????缃?淇℃??
+======================================================================
+
+?????????缃?
+----------------------------------------------------------------------
+Linux?????歌ˉ涓???????杩????浠惰?????浜ょ??锛????濂芥??琛ヤ??浣?涓洪??浠朵????????宓?????????????浜?缁存?よ??
+??ユ?堕??浠讹??浣???????浠剁?????瀹规?煎??搴?璇ユ??"text/plain"?????惰??锛????浠朵????????涓?璧???????锛?
+???涓鸿??浼?浣胯ˉ涓????寮???ㄩ?ㄥ????ㄨ??璁鸿??绋?涓???????寰???伴?俱??
+
+??ㄦ?ュ?????Linux?????歌ˉ涓???????浠跺?㈡?风????ㄥ?????琛ヤ????跺??璇ュ??浜?????????????濮???舵?????渚?濡?锛?
+浠?浠?涓???芥?瑰?????????????ゅ?惰〃绗???????绌烘?硷???????虫????ㄦ??涓?琛????寮?澶存?????缁?灏俱??
+
+涓?瑕????杩?"format=flowed"妯″????????琛ヤ?????杩???蜂??寮?璧蜂?????棰????浠ュ?????瀹崇?????琛????
+
+涓?瑕?璁╀????????浠跺?㈡?风??杩?琛??????ㄦ?㈣?????杩???蜂??浼???村??浣????琛ヤ?????
+
+???浠跺?㈡?风??涓???芥?瑰???????????瀛?绗????缂??????瑰?????瑕??????????琛ヤ???????芥??ASCII??????UTF-8缂??????瑰??锛?
+濡????浣?浣跨??UTF-8缂??????瑰???????????浠讹????ｄ??浣?灏?浼???垮??涓?浜??????藉????????瀛?绗???????棰????
+
+???浠跺?㈡?风??搴?璇ュ舰???骞朵??淇???? References: ?????? In-Reply-To: ???棰?锛???ｄ??
+???浠惰??棰?灏变??浼?涓???????
+
+澶???剁??甯?(?????????璐寸??甯?)???甯镐????界?ㄤ??琛ヤ??锛????涓哄?惰〃绗?浼?杞????涓虹┖??笺??浣跨??xclipboard, xclip
+??????xcutsel涔?璁稿??浠ワ??浣???????濂芥??璇?涓?涓?????????垮??浣跨?ㄥ????剁??甯????
+
+涓?瑕???ㄤ娇???PGP/GPG缃插????????浠朵腑??????琛ヤ?????杩???蜂??浣垮??寰?澶???????涓???借?诲??????????ㄤ??浣????琛ヤ?????
+锛?杩?涓????棰?搴?璇ユ?????浠ヤ慨澶????锛?
+
+??ㄧ???????搁??浠跺??琛ㄥ?????琛ヤ??涔????锛?缁????宸卞?????涓?涓?琛ヤ?????涓?涓???????涓绘??锛?淇?瀛???ユ?跺?扮??
+???浠讹??灏?琛ヤ?????'patch'??戒护???涓?锛?濡??????????浜?锛????缁??????搁??浠跺??琛ㄥ????????
+
+
+涓?浜????浠跺?㈡?风?????绀?
+----------------------------------------------------------------------
+杩????缁???轰??浜?璇?缁????MUA???缃????绀猴?????浠ョ?ㄤ??缁?Linux?????稿?????琛ヤ?????杩?浜?骞朵???????虫??
+?????????杞?浠跺?????缃???荤?????
+
+璇存??锛?
+TUI = 浠ユ?????涓哄?虹???????ㄦ?锋?ュ??
+GUI = ??惧舰?????㈢?ㄦ?锋?ュ??
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Alpine (TUI)
+
+???缃????椤癸??
+???"Sending Preferences"??ㄥ??锛?
+
+- "Do Not Send Flowed Text"蹇?椤诲?????
+- "Strip Whitespace Before Sending"蹇?椤诲?抽??
+
+褰???????浠舵?讹????????搴?璇ユ?惧?ㄨˉ涓?浼???虹?扮????版?癸????跺?????涓?CTRL-R缁???????锛?浣挎??瀹????
+琛ヤ?????浠跺????ュ?伴??浠朵腑???
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Evolution (GUI)
+
+涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ??
+
+褰??????╅??浠堕??椤癸??Preformat
+  浠?Format->Heading->Preformatted (Ctrl-7)??????宸ュ?锋??
+
+??跺??浣跨??锛?
+  Insert->Text File... (Alt-n x)?????ヨˉ涓????浠躲??
+
+浣?杩????浠?"diff -Nru old.c new.c | xclip"锛???????Preformat锛???跺??浣跨?ㄤ腑??撮??杩?琛?绮?甯????
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Kmail (GUI)
+
+涓?浜?寮????????????????浣跨?ㄥ????????琛ヤ?????
+
+榛?璁よ?剧疆涓?涓?HTML??煎??????????????锛?涓?瑕??????ㄥ?????
+
+褰?涔????涓?灏????浠剁????跺??锛???ㄩ??椤逛?????涓?瑕??????╄????ㄦ?㈣????????涓????缂虹?瑰氨???浣???ㄩ??浠朵腑杈???ョ??浠讳????????
+??戒??浼?琚??????ㄦ?㈣??锛????姝や??蹇?椤诲?ㄥ?????琛ヤ??涔?????????ㄦ?㈣????????绠?????????规??灏辨???????ㄨ????ㄦ?㈣????ヤ功??????浠讹??
+??跺?????瀹?淇?瀛?涓鸿??绋裤??涓????浣???ㄨ??绋夸腑???娆℃??寮?瀹?锛?瀹?宸茬????ㄩ?ㄨ????ㄦ?㈣??浜?锛???ｄ??浣???????浠惰?界?舵病???
+?????╄????ㄦ?㈣??锛?浣????杩?涓?浼?澶卞?诲凡???????????ㄦ?㈣?????
+
+??ㄩ??浠剁??搴????锛??????ヨˉ涓?涔????锛???句??甯哥?ㄧ??琛ヤ??瀹????绗?锛?涓?涓?杩?瀛????(---)???
+
+??跺?????"Message"????????＄??锛??????╂????ユ??浠讹????ョ????????浣????琛ヤ?????浠躲??杩????涓?涓?棰?澶???????椤癸??浣????浠?
+???杩?瀹????缃?浣???????浠跺缓绔?宸ュ?锋????????锛?杩????浠ュ甫涓?"insert file"??炬?????
+
+浣????浠ュ????ㄥ?伴??杩?GPG???璁伴??浠讹??浣???????宓?琛ヤ?????濂戒??瑕?浣跨??GPG???璁板??浠????浣?涓哄??宓??????????绛惧??琛ヤ??锛?
+褰?浠?GPG涓???????7浣?缂??????朵??浣夸??浠?????????村??澶???????
+
+濡????浣????瑕?浠ラ??浠剁??褰㈠????????琛ヤ??锛???ｄ??灏卞?抽????瑰?婚??浠讹????跺?????涓?灞???э??绐????"Suggest automatic
+display"锛?杩???峰??宓????浠舵?村?规??璁╄?昏???????般??
+
+褰?浣?瑕?淇?瀛?灏?瑕?????????????宓???????琛ヤ??锛?浣????浠ヤ??娑???????琛ㄧ????奸????╁?????琛ヤ????????浠讹????跺????冲?婚?????
+"save as"???浣????浠ヤ娇??ㄤ??涓?娌℃????存?圭????????琛ヤ????????浠讹??濡????瀹????浠ユ?ｇ‘???褰㈠??缁???????褰?浣?姝ｇ????ㄥ??
+???宸辩??绐???ｄ??涓?瀵????锛???ｆ?舵病??????椤瑰??浠ヤ??瀛????浠?--宸茬?????涓?涓?杩???风??bug琚?姹???ュ?颁??kmail???bugzilla
+骞朵??甯????杩?灏?浼?琚?澶??????????浠舵??浠ュ?????瀵规??涓???ㄦ?峰??璇诲???????????琚?淇?瀛????锛????浠ュ?????浣???虫?????浠跺????跺?板?朵????版?癸??
+浣?涓?寰?涓????浠?浠????????????逛负缁?????????翠?????璇汇??
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Lotus Notes (GUI)
+
+涓?瑕?浣跨?ㄥ?????
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Mutt (TUI)
+
+寰?澶?Linux寮????浜哄??浣跨??mutt瀹㈡?风??锛????浠ヨ?????瀹????瀹?宸ヤ????????甯告??浜????
+
+Mutt涓????甯?缂?杈????锛????浠ヤ??绠′??浣跨?ㄤ??涔?缂?杈???ㄩ?戒??搴?璇ュ甫????????ㄦ??琛????澶у????扮??杈???ㄩ?藉甫???
+涓?涓?"insert file"???椤癸??瀹????浠ラ??杩?涓???瑰?????浠跺??瀹圭????瑰???????ユ??浠躲??
+
+'vim'浣?涓?mutt???缂?杈????锛?
+  set editor="vi"
+
+  濡????浣跨??xclip锛???插?ヤ互涓???戒护
+  :set paste
+  ???涓????涔??????????shift-insert??????浣跨??
+  :r filename
+
+濡??????宠?????琛ヤ??浣?涓哄??宓??????????
+(a)ttach宸ヤ?????寰?濂斤??涓?甯????"set paste"???
+
+???缃????椤癸??
+瀹?搴?璇ヤ互榛?璁よ?剧疆???褰㈠??宸ヤ?????
+??惰??锛????"send_charset"璁剧疆涓?"us-ascii::utf-8"涔????涓?涓?涓???????涓绘?????
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Pine (TUI)
+
+Pine杩???绘??涓?浜?绌烘?煎????????棰?锛?浣????杩?浜???板?ㄥ??璇ラ?借??淇?澶?浜????
+
+濡???????浠ワ??璇蜂娇???alpine(pine???缁ф?胯??)
+
+???缃????椤癸??
+- ???杩?????????????瑕?娑???ゆ??绋???????
+- "no-strip-whitespace-before-send"???椤逛????????瑕???????
+
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Sylpheed (GUI)
+
+- ???宓??????????浠ュ??濂界??宸ヤ??锛???????浣跨?ㄩ??浠讹?????
+- ???璁镐娇??ㄥ????ㄧ??缂?杈???ㄣ??
+- 瀵逛?????褰?杈?澶???堕??甯告?????
+- 濡???????杩?non-SSL杩???ワ?????娉?浣跨??TLS SMTP?????????
+- ??ㄧ?????绐???ｄ腑???涓?涓?寰??????ㄧ??ruler bar???
+- 缁???板?????涓?娣诲????板??灏变??浼?姝ｇ‘???浜?瑙ｆ?剧ず??????
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Thunderbird (GUI)
+
+榛?璁ゆ????典??锛?thunderbird寰?瀹规??????????????锛?浣????杩????涓?浜???规?????浠ュ己??跺?????寰???村ソ???
+
+- ??ㄧ?ㄦ?峰????疯?剧疆???锛?缁???????瀵诲??锛?涓?瑕???????"Compose messages in HTML format"???
+
+- 缂?杈?浣????Thunderbird???缃?璁剧疆??ヤ娇瀹?涓?瑕????琛?浣跨??锛?user_pref("mailnews.wraplength", 0);
+
+- 缂?杈?浣????Thunderbird???缃?璁剧疆锛?浣垮??涓?瑕?浣跨??"format=flowed"??煎??锛?user_pref("mailnews.
+  send_plaintext_flowed", false);
+
+- 浣????瑕?浣?Thunderbird???涓洪???????煎????瑰??锛?
+  濡????榛?璁ゆ????典??浣?涔??????????HTML??煎??锛???ｄ?????寰???俱??浠?浠?浠????棰???????涓????妗?涓???????"Preformat"??煎?????
+  濡????榛?璁ゆ????典??浣?涔??????????????????煎??锛?浣?涓?寰????瀹???逛负HTML??煎??锛?浠?浠?浣?涓轰??娆℃?х??锛???ヤ功?????扮??娑????锛?
+  ??跺??寮哄?朵娇瀹??????版???????煎??锛???????瀹?灏变?????琛????瑕?瀹???板??锛???ㄥ??淇＄????炬??涓?浣跨??shift?????ヤ娇瀹????涓?HTML
+  ??煎??锛???跺?????棰???????涓????妗?涓???????"Preformat"??煎?????
+
+- ???璁镐娇??ㄥ????ㄧ??缂?杈????锛?
+  ???瀵?Thunderbird???琛ヤ?????绠?????????规??灏辨??浣跨?ㄤ??涓?"external editor"??╁??锛???跺??浣跨?ㄤ????????娆㈢??
+  $EDITOR??ヨ?诲???????????骞惰ˉ涓???版?????涓????瑕?瀹???板??锛????浠ヤ??杞藉苟涓?瀹?瑁?杩?涓???╁??锛???跺??娣诲??涓?涓?浣跨?ㄥ?????
+  ??????View->Toolbars->Customize...??????褰?浣?涔????淇℃???????跺??浠?浠???瑰?诲??灏卞??浠ヤ?????
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+TkRat (GUI)
+
+???浠ヤ娇??ㄥ?????浣跨??"Insert file..."??????澶???ㄧ??缂?杈???ㄣ??
+
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Gmail (Web GUI)
+
+涓?瑕?浣跨?ㄥ????????琛ヤ?????
+
+Gmail缃?椤靛?㈡?风???????ㄥ?版????惰〃绗?杞????涓虹┖??笺??
+
+??界?跺?惰〃绗?杞????涓虹┖??奸??棰????浠ヨ??澶???ㄧ??杈???ㄨВ??筹???????跺??杩?浼?浣跨?ㄥ??杞???㈣?????姣?琛???????涓?78涓?瀛?绗????
+
+???涓?涓????棰????Gmail杩?浼????浠讳??涓????ASCII???瀛?绗????淇℃????逛负base64缂???????瀹????涓?瑗垮????????娆ф床浜虹?????瀛????
+
+                                ###