158 files changed, 885 insertions, 309 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index f607367e642f..c17cd4bb2290 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -206,8 +206,8 @@ laptops/
        - directory with laptop related info and laptop driver documentation.
 ldm.txt
        - a brief description of LDM (Windows Dynamic Disks).
-leds-class.txt
+leds/
-        - documents LED handling under Linux.
+        - directory with info about LED handling under Linux.
 local_ops.txt
        - semantics and behavior of local atomic operations.
 lockdep-design.txt
diff --git a/Documentation/ABI/testing/sysfs-bus-css b/Documentation/ABI/testing/sysfs-bus-css
index b585ec258a08..2979c40c10e9 100644
--- a/Documentation/ABI/testing/sysfs-bus-css
+++ b/Documentation/ABI/testing/sysfs-bus-css
@@ -29,7 +29,7 @@ Contact:	Cornelia Huck <cornelia.huck@de.ibm.com>
                linux-s390@vger.kernel.org
 Description:    Contains the PIM/PAM/POM values, as reported by the
                channel subsystem when last queried by the common I/O
-                layer (this implies that this attribute is not neccessarily
+                layer (this implies that this attribute is not necessarily
                in sync with the values current in the channel subsystem).
                Note: This is an I/O-subchannel specific attribute.
 Users:          s390-tools, HAL
diff --git a/Documentation/ABI/testing/sysfs-class-led b/Documentation/ABI/testing/sysfs-class-led
index edff6630c805..3646ec85d513 100644
--- a/Documentation/ABI/testing/sysfs-class-led
+++ b/Documentation/ABI/testing/sysfs-class-led
@@ -33,5 +33,5 @@ Contact:	Richard Purdie <rpurdie@rpsys.net>
 Description:
                Invert the LED on/off state. This parameter is specific to
                gpio and backlight triggers. In case of the backlight trigger,
-                it is usefull when driving a LED which is intended to indicate
+                it is useful when driving a LED which is intended to indicate
                a device in a standby like state.
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
index b4c4f158ab9c..3ca3971109bf 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kone
@@ -40,7 +40,7 @@ What:		/sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
 Date:           March 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
-                press of a button. A profile holds informations like button
+                press of a button. A profile holds information like button
                mappings, sensitivity, the colors of the 5 leds and light
                effects.
                When read, these files return the respective profile. The
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
index 00efced73969..326e05452da7 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
@@ -33,7 +33,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_buttons holds informations about button layout.
+                profile_buttons holds information about button layout.
                When written, this file lets one write the respective profile
                buttons back to the mouse. The data has to be 77 bytes long.
                The mouse will reject invalid data.
@@ -47,7 +47,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_buttons holds informations about button layout.
+                profile_buttons holds information about button layout.
                When read, these files return the respective profile buttons.
                The returned data is 77 bytes in size.
                This file is readonly.
@@ -58,7 +58,7 @@ Date:		October 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_settings holds informations like resolution, sensitivity
+                profile_settings holds information like resolution, sensitivity
                and light effects.
                When written, this file lets one write the respective profile
                settings back to the mouse. The data has to be 43 bytes long.
@@ -73,7 +73,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_settings holds informations like resolution, sensitivity
+                profile_settings holds information like resolution, sensitivity
                and light effects.
                When read, these files return the respective profile settings.
                The returned data is 43 bytes in size.
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
index fdfa16f8189b..20f937c9d84f 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
@@ -52,7 +52,7 @@ Date:		January 2011
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_buttons holds informations about button layout.
+                profile_buttons holds information about button layout.
                When written, this file lets one write the respective profile
                buttons back to the mouse. The data has to be 23 bytes long.
                The mouse will reject invalid data.
@@ -66,7 +66,7 @@ Date:		January 2011
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_buttons holds informations about button layout.
+                profile_buttons holds information about button layout.
                When read, these files return the respective profile buttons.
                The returned data is 23 bytes in size.
                This file is readonly.
@@ -77,7 +77,7 @@ Date:		January 2011
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_settings holds informations like resolution, sensitivity
+                profile_settings holds information like resolution, sensitivity
                and light effects.
                When written, this file lets one write the respective profile
                settings back to the mouse. The data has to be 16 bytes long.
@@ -92,7 +92,7 @@ Date:		January 2011
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_settings holds informations like resolution, sensitivity
+                profile_settings holds information like resolution, sensitivity
                and light effects.
                When read, these files return the respective profile settings.
                The returned data is 16 bytes in size.
diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
index 5fab71af3c46..3f8de50e4ff1 100644
--- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
+++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
@@ -39,7 +39,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_settings holds informations like resolution, sensitivity
+                profile_settings holds information like resolution, sensitivity
                and light effects.
                When written, this file lets one write the respective profile
                settings back to the mouse. The data has to be 13 bytes long.
@@ -54,7 +54,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_settings holds informations like resolution, sensitivity
+                profile_settings holds information like resolution, sensitivity
                and light effects.
                When read, these files return the respective profile settings.
                The returned data is 13 bytes in size.
@@ -66,7 +66,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_buttons holds informations about button layout.
+                profile_buttons holds information about button layout.
                When written, this file lets one write the respective profile
                buttons back to the mouse. The data has to be 19 bytes long.
                The mouse will reject invalid data.
@@ -80,7 +80,7 @@ Date:		August 2010
 Contact:        Stefan Achatz <erazor_de@users.sourceforge.net>
 Description:    The mouse can store 5 profiles which can be switched by the
                press of a button. A profile is split in settings and buttons.
-                profile_buttons holds informations about button layout.
+                profile_buttons holds information about button layout.
                When read, these files return the respective profile buttons.
                The returned data is 19 bytes in size.
                This file is readonly.
diff --git a/Documentation/ABI/testing/sysfs-platform-asus-laptop b/Documentation/ABI/testing/sysfs-platform-asus-laptop
index 41ff8ae4dee0..cd9d667c3da2 100644
--- a/Documentation/ABI/testing/sysfs-platform-asus-laptop
+++ b/Documentation/ABI/testing/sysfs-platform-asus-laptop
@@ -27,7 +27,7 @@ KernelVersion:	2.6.20
 Contact:        "Corentin Chary" <corentincj@iksaif.net>
 Description:
                Some models like the W1N have a LED display that can be
-                used to display several informations.
+                used to display several items of information.
                To control the LED display, use the following :
                    echo 0x0T000DDD > /sys/devices/platform/asus_laptop/
                where T control the 3 letters display, and DDD the 3 digits display.
diff --git a/Documentation/DocBook/dvb/dvbproperty.xml b/Documentation/DocBook/dvb/dvbproperty.xml
index 5f57c7ccd4ba..97f397e2fb3a 100644
--- a/Documentation/DocBook/dvb/dvbproperty.xml
+++ b/Documentation/DocBook/dvb/dvbproperty.xml
@@ -40,7 +40,7 @@
                        <para>Central frequency of the channel.</para>
-                        <para>For ISDB-T the channels are usally transmitted with an offset of 143kHz. E.g. a
+                        <para>For ISDB-T the channels are usually transmitted with an offset of 143kHz. E.g. a
                                valid frequncy could be 474143 kHz. The stepping is bound to the bandwidth of
                                the channel which is 6MHz.</para>
diff --git a/Documentation/DocBook/dvb/frontend.xml b/Documentation/DocBook/dvb/frontend.xml
index 78d756de5906..60c6976fb311 100644
--- a/Documentation/DocBook/dvb/frontend.xml
+++ b/Documentation/DocBook/dvb/frontend.xml
@@ -139,7 +139,7 @@ consistently to the DiSEqC commands as described in the DiSEqC spec.</para>
 <section id="frontend_sec_tone">
 <title>SEC continuous tone</title>
-<para>The continous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
+<para>The continuous 22KHz tone is usually used with non-DiSEqC capable LNBs to switch the
 high/low band of a dual-band LNB. When using DiSEqC epuipment this voltage has to
 be switched consistently to the DiSEqC commands as described in the DiSEqC
 spec.</para>
diff --git a/Documentation/DocBook/kernel-locking.tmpl b/Documentation/DocBook/kernel-locking.tmpl
index f66f4df18690..67e7ab41c0a6 100644
--- a/Documentation/DocBook/kernel-locking.tmpl
+++ b/Documentation/DocBook/kernel-locking.tmpl
@@ -1763,7 +1763,7 @@ as it would be on UP.
 There is a furthur optimization possible here: remember our original
 cache code, where there were no reference counts and the caller simply
 held the lock whenever using the object?  This is still possible: if
-you hold the lock, noone can delete the object, so you don't need to
+you hold the lock, no one can delete the object, so you don't need to
 get and put the reference count.
 </para>
diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl
index 8c5411cfeaf0..cdd1bb9aac0d 100644
--- a/Documentation/DocBook/libata.tmpl
+++ b/Documentation/DocBook/libata.tmpl
@@ -1032,7 +1032,7 @@ and other resources, etc.
           <listitem>
           <para>
           This is indicated by ICRC bit in the ERROR register and
-           means that corruption occurred during data transfer.  Upto
+           means that corruption occurred during data transfer.  Up to
           ATA/ATAPI-7, the standard specifies that this bit is only
           applicable to UDMA transfers but ATA/ATAPI-8 draft revision
           1f says that the bit may be applicable to multiword DMA and
@@ -1045,10 +1045,10 @@ and other resources, etc.
           <term>ABRT error during data transfer or on completion</term>
           <listitem>
           <para>
-           Upto ATA/ATAPI-7, the standard specifies that ABRT could be
+           Up to ATA/ATAPI-7, the standard specifies that ABRT could be
           set on ICRC errors and on cases where a device is not able
           to complete a command.  Combined with the fact that MWDMA
-           and PIO transfer errors aren't allowed to use ICRC bit upto
+           and PIO transfer errors aren't allowed to use ICRC bit up to
           ATA/ATAPI-7, it seems to imply that ABRT bit alone could
           indicate tranfer errors.
           </para>
@@ -1122,7 +1122,7 @@ and other resources, etc.
        <para>
        Depending on commands, not all STATUS/ERROR bits are
        applicable.  These non-applicable bits are marked with
-        &quot;na&quot; in the output descriptions but upto ATA/ATAPI-7
+        &quot;na&quot; in the output descriptions but up to ATA/ATAPI-7
        no definition of &quot;na&quot; can be found.  However,
        ATA/ATAPI-8 draft revision 1f describes &quot;N/A&quot; as
        follows.
@@ -1507,7 +1507,7 @@ and other resources, etc.
        <listitem>
        <para>
-        CHS set up with INITIALIZE DEVICE PARAMETERS (seldomly used)
+        CHS set up with INITIALIZE DEVICE PARAMETERS (seldom used)
        </para>
        </listitem>
diff --git a/Documentation/DocBook/mtdnand.tmpl b/Documentation/DocBook/mtdnand.tmpl
index 620eb3f6a90a..6f242d5dee9a 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -485,7 +485,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
                                Reed-Solomon library.
                        </para>
                        <para>
-                                The ECC bytes must be placed immidiately after the data
+                                The ECC bytes must be placed immediately after the data
                                bytes in order to make the syndrome generator work. This
                                is contrary to the usual layout used by software ECC. The
                                separation of data and out of band area is not longer
@@ -629,7 +629,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
                                holds the bad block table. Store a pointer to the pattern  
                                in the pattern field. Further the length of the pattern has to be 
                                stored in len and the offset in the spare area must be given
-                                in the offs member of the nand_bbt_descr stucture. For mirrored
+                                in the offs member of the nand_bbt_descr structure. For mirrored
                                bad block tables different patterns are mandatory.</para></listitem>
                                <listitem><para>Table creation</para>
                                <para>Set the option NAND_BBT_CREATE to enable the table creation
@@ -648,7 +648,7 @@ static void board_select_chip (struct mtd_info *mtd, int chip)
                                <listitem><para>Table version control</para>
                                <para>Set the option NAND_BBT_VERSION to enable the table version control.
                                It's highly recommended to enable this for mirrored tables with write
-                                support. It makes sure that the risk of loosing the bad block
+                                support. It makes sure that the risk of losing the bad block
                                table information is reduced to the loss of the information about the
                                one worn out block which should be marked bad. The version is stored in
                                4 consecutive bytes in the spare area of the device. The position of
@@ -1060,19 +1060,19 @@ data in this page</entry>
 <row>
 <entry>0x3D</entry>
 <entry>ECC byte 21</entry>
-<entry>Error correction code byte 0 of the eigth 256 Bytes of data
+<entry>Error correction code byte 0 of the eighth 256 Bytes of data
 in this page</entry>
 </row>
 <row>
 <entry>0x3E</entry>
 <entry>ECC byte 22</entry>
-<entry>Error correction code byte 1 of the eigth 256 Bytes of data
+<entry>Error correction code byte 1 of the eighth 256 Bytes of data
 in this page</entry>
 </row>
 <row>
 <entry>0x3F</entry>
 <entry>ECC byte 23</entry>
-<entry>Error correction code byte 2 of the eigth 256 Bytes of data
+<entry>Error correction code byte 2 of the eighth 256 Bytes of data
 in this page</entry>
 </row>
 </tbody></tgroup></informaltable>
diff --git a/Documentation/DocBook/regulator.tmpl b/Documentation/DocBook/regulator.tmpl
index 53f4f8d3b810..346e552fa2cc 100644
--- a/Documentation/DocBook/regulator.tmpl
+++ b/Documentation/DocBook/regulator.tmpl
@@ -267,8 +267,8 @@
     <sect1 id="machine-constraint">
       <title>Constraints</title>
       <para>
-         As well as definining the connections the machine interface
+         As well as defining the connections the machine interface
-         also provides constraints definining the operations that
+         also provides constraints defining the operations that
         clients are allowed to perform and the parameters that may be
         set.  This is required since generally regulator devices will
         offer more flexibility than it is safe to use on a given
diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl
index b4665b9c40b0..7c4b514d62b1 100644
--- a/Documentation/DocBook/uio-howto.tmpl
+++ b/Documentation/DocBook/uio-howto.tmpl
@@ -797,7 +797,7 @@ framework to set up sysfs files for this region. Simply leave it alone.
        perform some initialization. After that, your hardware
        starts working and will generate an interrupt as soon
        as it's finished, has some data available, or needs your
-        attention because an error occured.
+        attention because an error occurred.
        </para>
        <para>
        <filename>/dev/uioX</filename> is a read-only file. A
diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl
index af293606fbe3..8d57c1888dca 100644
--- a/Documentation/DocBook/usb.tmpl
+++ b/Documentation/DocBook/usb.tmpl
@@ -690,7 +690,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param)
                    </para><para>
                    This request lets kernel drivers talk to user mode code
                    through filesystem operations even when they don't create
-                    a charactor or block special device.
+                    a character or block special device.
                    It's also been used to do things like ask devices what
                    device special file should be used.
                    Two pre-defined ioctls are used
diff --git a/Documentation/DocBook/v4l/common.xml b/Documentation/DocBook/v4l/common.xml
index dbab79c215c1..9028721438dc 100644
--- a/Documentation/DocBook/v4l/common.xml
+++ b/Documentation/DocBook/v4l/common.xml
@@ -100,7 +100,7 @@ linux-kernel@vger.kernel.org, 2002-11-20. --></para>
      <para>By convention system administrators create various
 character device special files with these major and minor numbers in
-the <filename>/dev</filename> directory. The names recomended for the
+the <filename>/dev</filename> directory. The names recommended for the
 different V4L2 device types are listed in <xref linkend="devices" />.
 </para>
diff --git a/Documentation/DocBook/v4l/controls.xml b/Documentation/DocBook/v4l/controls.xml
index 2fae3e87ce73..a920ee80f640 100644
--- a/Documentation/DocBook/v4l/controls.xml
+++ b/Documentation/DocBook/v4l/controls.xml
@@ -1243,7 +1243,7 @@ values are:</entry>
              </row><row><entry spanname="descr">Mutes the audio when
 capturing. This is not done by muting audio hardware, which can still
 produce a slight hiss, but in the encoder itself, guaranteeing a fixed
-and reproducable audio bitstream. 0 = unmuted, 1 = muted.</entry>
+and reproducible audio bitstream. 0 = unmuted, 1 = muted.</entry>
              </row>
              <row><entry></entry></row>
              <row id="v4l2-mpeg-video-encoding">
diff --git a/Documentation/DocBook/v4l/dev-subdev.xml b/Documentation/DocBook/v4l/dev-subdev.xml
index 21caff6d159b..05c8fefcbcbe 100644
--- a/Documentation/DocBook/v4l/dev-subdev.xml
+++ b/Documentation/DocBook/v4l/dev-subdev.xml
@@ -90,7 +90,7 @@
    processing hardware.</para>
    <figure id="pipeline-scaling">
-      <title>Image Format Negotation on Pipelines</title>
+      <title>Image Format Negotiation on Pipelines</title>
      <mediaobject>
        <imageobject>
          <imagedata fileref="pipeline.pdf" format="PS" />
diff --git a/Documentation/DocBook/v4l/libv4l.xml b/Documentation/DocBook/v4l/libv4l.xml
index c14fc3db2a81..3cb10ec51929 100644
--- a/Documentation/DocBook/v4l/libv4l.xml
+++ b/Documentation/DocBook/v4l/libv4l.xml
@@ -140,7 +140,7 @@ and is not locked sets the cid to the scaled value.
                        <para>int v4l2_get_control(int fd, int cid) -
 This function returns a value of 0 - 65535, scaled to from the actual range
 of the given v4l control id. when the cid does not exist, could not be
-accessed for some reason, or some error occured 0 is returned.
+accessed for some reason, or some error occurred 0 is returned.
 </para></listitem>
 </itemizedlist>
                </section>
diff --git a/Documentation/DocBook/v4l/remote_controllers.xml b/Documentation/DocBook/v4l/remote_controllers.xml
index 3c3b667b28e7..160e464d44b7 100644
--- a/Documentation/DocBook/v4l/remote_controllers.xml
+++ b/Documentation/DocBook/v4l/remote_controllers.xml
@@ -133,7 +133,7 @@ different IR's. Due to that, V4L2 API now specifies a standard for mapping Media
 <row><entry><constant>KEY_LEFT</constant></entry><entry>Left key</entry><entry>LEFT</entry></row>
 <row><entry><constant>KEY_RIGHT</constant></entry><entry>Right key</entry><entry>RIGHT</entry></row>
-<row><entry><emphasis role="bold">Miscelaneous keys</emphasis></entry></row>
+<row><entry><emphasis role="bold">Miscellaneous keys</emphasis></entry></row>
 <row><entry><constant>KEY_DOT</constant></entry><entry>Return a dot</entry><entry>.</entry></row>
 <row><entry><constant>KEY_FN</constant></entry><entry>Select a function</entry><entry>FUNCTION</entry></row>
diff --git a/Documentation/DocBook/writing-an-alsa-driver.tmpl b/Documentation/DocBook/writing-an-alsa-driver.tmpl
index 0ba149de2608..58ced2346e67 100644
--- a/Documentation/DocBook/writing-an-alsa-driver.tmpl
+++ b/Documentation/DocBook/writing-an-alsa-driver.tmpl
@@ -4784,7 +4784,7 @@ struct _snd_pcm_runtime {
        FM registers can be directly accessed through the direct-FM API,
      defined in <filename>&lt;sound/asound_fm.h&gt;</filename>. In
      ALSA native mode, FM registers are accessed through
-      the Hardware-Dependant Device direct-FM extension API, whereas in
+      the Hardware-Dependent Device direct-FM extension API, whereas in
      OSS compatible mode, FM registers can be accessed with the OSS
      direct-FM compatible API in <filename>/dev/dmfmX</filename> device. 
      </para>
diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index dcf7acc720e1..3f5e0b09bed5 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -253,8 +253,8 @@ In constrast, MSI is restricted to a maximum of 32 interrupts (and
 must be a power of two).  In addition, the MSI interrupt vectors must
 be allocated consecutively, so the system may not be able to allocate
 as many vectors for MSI as it could for MSI-X.  On some platforms, MSI
-interrupts must all be targetted at the same set of CPUs whereas MSI-X
+interrupts must all be targeted at the same set of CPUs whereas MSI-X
-interrupts can all be targetted at different CPUs.
+interrupts can all be targeted at different CPUs.
 4.5.2 Spinlocks
diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs
index 26c3b3635d9f..a660d494c8ed 100644
--- a/Documentation/SecurityBugs
+++ b/Documentation/SecurityBugs
@@ -28,7 +28,7 @@ expect these delays to be short, measurable in days, not weeks or months.
 A disclosure date is negotiated by the security team working with the
 bug submitter as well as vendors.  However, the kernel security team
 holds the final say when setting a disclosure date.  The timeframe for
-disclosure is from immediate (esp. if it's already publically known)
+disclosure is from immediate (esp. if it's already publicly known)
 to a few weeks.  As a basic default policy, we expect report date to
 disclosure date to be on the order of 7 days.
diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
index 38d2aab59cac..319baa8b60dd 100644
--- a/Documentation/SubmittingDrivers
+++ b/Documentation/SubmittingDrivers
@@ -101,7 +101,7 @@ PM support:	Since Linux is used on many portable and desktop systems, your
                complete overview of the power management issues related to
                drivers see Documentation/power/devices.txt .
-Control:        In general if there is active maintainance of a driver by
+Control:        In general if there is active maintenance of a driver by
                the author then patches will be redirected to them unless
                they are totally obvious and without need of checking.
                If you want to be the contact and update point for the
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 689e2371095c..e439cd0d3375 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -729,7 +729,7 @@ Linus Torvalds's mail on the canonical patch format:
  <http://lkml.org/lkml/2005/4/7/183>
 Andi Kleen, "On submitting kernel patches"
-  Some strategies to get difficult or controversal changes in.
+  Some strategies to get difficult or controversial changes in.
  http://halobates.de/on-submitting-patches.pdf
 --
diff --git a/Documentation/arm/IXP4xx b/Documentation/arm/IXP4xx
index 133c5fa6c7a1..7b9351f2f555 100644
--- a/Documentation/arm/IXP4xx
+++ b/Documentation/arm/IXP4xx
@@ -36,7 +36,7 @@ Linux currently supports the following features on the IXP4xx chips:
 - Timers (watchdog, OS)
 The following components of the chips are not supported by Linux and
-require the use of Intel's propietary CSR softare:
+require the use of Intel's proprietary CSR softare:
 - USB device interface
 - Network interfaces (HSS, Utopia, NPEs, etc)
@@ -47,7 +47,7 @@ software from:
   http://developer.intel.com/design/network/products/npfamily/ixp425.htm    
-DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPIETARY
+DO NOT POST QUESTIONS TO THE LINUX MAILING LISTS REGARDING THE PROPRIETARY
 SOFTWARE.
 There are several websites that provide directions/pointers on using
diff --git a/Documentation/arm/Samsung-S3C24XX/Suspend.txt b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
index 7edd0e2e6c5b..1ca63b3e5635 100644
--- a/Documentation/arm/Samsung-S3C24XX/Suspend.txt
+++ b/Documentation/arm/Samsung-S3C24XX/Suspend.txt
@@ -116,7 +116,7 @@ Configuration
    Allows the entire memory to be checksummed before and after the
    suspend to see if there has been any corruption of the contents.
-    Note, the time to calculate the CRC is dependant on the CPU speed
+    Note, the time to calculate the CRC is dependent on the CPU speed
    and the size of memory. For an 64Mbyte RAM area on an 200MHz
    S3C2410, this can take approximately 4 seconds to complete.
diff --git a/Documentation/arm/Samsung/GPIO.txt b/Documentation/arm/Samsung/GPIO.txt
index 05850c62abeb..513f2562c1a3 100644
--- a/Documentation/arm/Samsung/GPIO.txt
+++ b/Documentation/arm/Samsung/GPIO.txt
@@ -5,7 +5,7 @@ Introduction
 ------------
 This outlines the Samsung GPIO implementation and the architecture
-specfic calls provided alongisde the drivers/gpio core.
+specific calls provided alongisde the drivers/gpio core.
 S3C24XX (Legacy)
diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt
index 2a7b38c832c7..c6d84cfd2f56 100644
--- a/Documentation/block/biodoc.txt
+++ b/Documentation/block/biodoc.txt
@@ -497,7 +497,7 @@ The scatter gather list is in the form of an array of <page, offset, len>
 entries with their corresponding dma address mappings filled in at the
 appropriate time. As an optimization, contiguous physical pages can be
 covered by a single entry where <page> refers to the first page and <len>
-covers the range of pages (upto 16 contiguous pages could be covered this
+covers the range of pages (up to 16 contiguous pages could be covered this
 way). There is a helper routine (blk_rq_map_sg) which drivers can use to build
 the sg list.
@@ -565,7 +565,7 @@ struct request {
        .
        int tag;        /* command tag associated with request */
        void *special;  /* same as before */
-        char *buffer;   /* valid only for low memory buffers upto
+        char *buffer;   /* valid only for low memory buffers up to
                         current_nr_sectors */
        .
        .
diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt
index cbdfb7d9455b..aedf1bd02fdd 100644
--- a/Documentation/cgroups/cgroups.txt
+++ b/Documentation/cgroups/cgroups.txt
@@ -110,22 +110,22 @@ university server with various users - students, professors, system
 tasks etc. The resource planning for this server could be along the
 following lines:
-       CPU :           Top cpuset
+       CPU :          "Top cpuset"
                       /       \
               CPUSet1         CPUSet2
-                  |              |
+                  |               |
-               (Profs)         (Students)
+               (Professors)    (Students)
               In addition (system tasks) are attached to topcpuset (so
               that they can run anywhere) with a limit of 20%
-       Memory : Professors (50%), students (30%), system (20%)
+       Memory : Professors (50%), Students (30%), system (20%)
-       Disk : Prof (50%), students (30%), system (20%)
+       Disk : Professors (50%), Students (30%), system (20%)
       Network : WWW browsing (20%), Network File System (60%), others (20%)
                               / \
-                       Prof (15%) students (5%)
+               Professors (15%)  students (5%)
 Browsers like Firefox/Lynx go into the WWW network class, while (k)nfsd go
 into NFS network class.
diff --git a/Documentation/cpu-hotplug.txt b/Documentation/cpu-hotplug.txt
index 45d5a217484f..a20bfd415e41 100644
--- a/Documentation/cpu-hotplug.txt
+++ b/Documentation/cpu-hotplug.txt
@@ -196,7 +196,7 @@ the state as 0 when a cpu if offline and 1 when its online.
        #To display the current cpu state.
        #cat /sys/devices/system/cpu/cpuX/online
-Q: Why cant i remove CPU0 on some systems?
+Q: Why can't i remove CPU0 on some systems?
 A: Some architectures may have some special dependency on a certain CPU.
 For e.g in IA64 platforms we have ability to sent platform interrupts to the
diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
index 15174985ad08..d262e22bddec 100644
--- a/Documentation/dell_rbu.txt
+++ b/Documentation/dell_rbu.txt
@@ -62,7 +62,7 @@ image file and then arrange all these packets back to back in to one single
 file.
 This file is then copied to /sys/class/firmware/dell_rbu/data.
 Once this file gets to the driver, the driver extracts packet_size data from
-the file and spreads it accross the physical memory in contiguous packet_sized
+the file and spreads it across the physical memory in contiguous packet_sized
 space.
 This method makes sure that all the packets get to the driver in a single operation.
diff --git a/Documentation/device-mapper/dm-service-time.txt b/Documentation/device-mapper/dm-service-time.txt
index 7d00668e97bb..fb1d4a0cf122 100644
--- a/Documentation/device-mapper/dm-service-time.txt
+++ b/Documentation/device-mapper/dm-service-time.txt
@@ -37,7 +37,7 @@ Algorithm
 =========
 dm-service-time adds the I/O size to 'in-flight-size' when the I/O is
-dispatched and substracts when completed.
+dispatched and subtracts when completed.
 Basically, dm-service-time selects a path having minimum service time
 which is calculated by:
diff --git a/Documentation/devicetree/bindings/fb/sm501fb.txt b/Documentation/devicetree/bindings/fb/sm501fb.txt
index 7d319fba9b5b..9d9f0098092b 100644
--- a/Documentation/devicetree/bindings/fb/sm501fb.txt
+++ b/Documentation/devicetree/bindings/fb/sm501fb.txt
@@ -18,9 +18,9 @@ Optional properties:
 - edid : verbatim EDID data block describing attached display.
  Data from the detailed timing descriptor will be used to
  program the display controller.
- little-endian: availiable on big endian systems, to
+- little-endian: available on big endian systems, to
  set different foreign endian.
- big-endian: availiable on little endian systems, to
+- big-endian: available on little endian systems, to
  set different foreign endian.
 Example for MPC5200:
diff --git a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
index a48b2cadc7f0..00f1f546b32e 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-upm-nand.txt
@@ -15,7 +15,7 @@ Optional properties:
 - gpios : may specify optional GPIOs connected to the Ready-Not-Busy pins
        (R/B#). For multi-chip devices, "n" GPIO definitions are required
        according to the number of chips.
- chip-delay : chip dependent delay for transfering data from array to
+- chip-delay : chip dependent delay for transferring data from array to
        read registers (tR). Required if property "gpios" is not used
        (R/B# pins not connected).
diff --git a/Documentation/devicetree/bindings/net/can/sja1000.txt b/Documentation/devicetree/bindings/net/can/sja1000.txt
index d6d209ded937..c2dbcec0ee31 100644
--- a/Documentation/devicetree/bindings/net/can/sja1000.txt
+++ b/Documentation/devicetree/bindings/net/can/sja1000.txt
@@ -39,7 +39,7 @@ Optional properties:
 - nxp,no-comparator-bypass : Allows to disable the CAN input comperator.
-For futher information, please have a look to the SJA1000 data sheet.
+For further information, please have a look to the SJA1000 data sheet.
 Examples:
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
index 8aa10f45ebe6..4f6145859aab 100644
--- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
+++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt
@@ -199,7 +199,7 @@ EXAMPLE 4
 EXAMPLE 5
        /*
-         * Definition of an error interrupt (interupt type 1).
+         * Definition of an error interrupt (interrupt type 1).
         * SoC interrupt number is 16 and the specific error
         * interrupt bit in the error interrupt summary register
         * is 23.
diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index 55fd2623445b..50619a0720a8 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -138,7 +138,7 @@ and properties to be present. This will be described in detail in
 section III, but, for example, the kernel does not require you to
 create a node for every PCI device in the system. It is a requirement
 to have a node for PCI host bridges in order to provide interrupt
-routing informations and memory/IO ranges, among others. It is also
+routing information and memory/IO ranges, among others. It is also
 recommended to define nodes for on chip devices and other buses that
 don't specifically fit in an existing OF specification. This creates a
 great flexibility in the way the kernel can then probe those and match
@@ -385,7 +385,7 @@ struct boot_param_header {
     among others, by kexec. If you are on an SMP system, this value
     should match the content of the "reg" property of the CPU node in
     the device-tree corresponding to the CPU calling the kernel entry
-     point (see further chapters for more informations on the required
+     point (see further chapters for more information on the required
     device-tree contents)
   - size_dt_strings
@@ -553,7 +553,7 @@ looks like in practice.
 This tree is almost a minimal tree. It pretty much contains the
 minimal set of required nodes and properties to boot a linux kernel;
-that is, some basic model informations at the root, the CPUs, and the
+that is, some basic model information at the root, the CPUs, and the
 physical memory layout.  It also includes misc information passed
 through /chosen, like in this example, the platform type (mandatory)
 and the kernel command line arguments (optional).
diff --git a/Documentation/dvb/README.dvb-usb b/Documentation/dvb/README.dvb-usb
index c8238e44ed6b..c4d963a67d6f 100644
--- a/Documentation/dvb/README.dvb-usb
+++ b/Documentation/dvb/README.dvb-usb
@@ -138,7 +138,7 @@ Hotplug is able to load the driver, when it is needed (because you plugged
 in the device).
 If you want to enable debug output, you have to load the driver manually and
-from withing the dvb-kernel cvs repository.
+from within the dvb-kernel cvs repository.
 first have a look, which debug level are available:
diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt
index 4a0c2b56e690..6c3bda50f7dc 100644
--- a/Documentation/dvb/ci.txt
+++ b/Documentation/dvb/ci.txt
@@ -47,7 +47,7 @@ so on.
 * CI modules that are supported
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The CI module support is largely dependant upon the firmware on the cards
+The CI module support is largely dependent upon the firmware on the cards
 Some cards do support almost all of the available CI modules. There is
 nothing much that can be done in order to make additional CI modules
 working with these cards.
diff --git a/Documentation/dvb/faq.txt b/Documentation/dvb/faq.txt
index 121832e5d899..97b1373f2428 100644
--- a/Documentation/dvb/faq.txt
+++ b/Documentation/dvb/faq.txt
@@ -106,7 +106,7 @@ Some very frequently asked questions about linuxtv-dvb
 5. The dvb_net device doesn't give me any packets at all
        Run tcpdump on the dvb0_0 interface. This sets the interface
-        into promiscous mode so it accepts any packets from the PID
+        into promiscuous mode so it accepts any packets from the PID
        you have configured with the dvbnet utility. Check if there
        are any packets with the IP addr and MAC addr you have
        configured with ifconfig.
diff --git a/Documentation/dvb/udev.txt b/Documentation/dvb/udev.txt
index 68ee224b6aae..412305b7c557 100644
--- a/Documentation/dvb/udev.txt
+++ b/Documentation/dvb/udev.txt
@@ -1,7 +1,7 @@
 The DVB subsystem currently registers to the sysfs subsystem using the
 "class_simple" interface.
-This means that only the basic informations like module loading parameters
+This means that only the basic information like module loading parameters
 are presented through sysfs. Other things that might be interesting are
 currently *not* available.
diff --git a/Documentation/edac.txt b/Documentation/edac.txt
index 9ee774de57cd..249822cde82b 100644
--- a/Documentation/edac.txt
+++ b/Documentation/edac.txt
@@ -311,7 +311,7 @@ Total Correctable Errors count attribute file:
        'ce_noinfo_count'
        This attribute file displays the number of CEs that
-        have occurred wherewith no informations as to which DIMM slot
+        have occurred wherewith no information as to which DIMM slot
        is having errors. Memory is handicapped, but operational,
        yet no information is available to indicate which slot
        the failing memory is in. This count field should be also
@@ -741,7 +741,7 @@ were done at i7core_edac driver. This chapter will cover those differences
   As EDAC API maps the minimum unity is csrows, the driver sequencially
   maps channel/dimm into different csrows.
-   For example, suposing the following layout:
+   For example, supposing the following layout:
        Ch0 phy rd0, wr0 (0x063f4031): 2 ranks, UDIMMs
          dimm 0 1024 Mb offset: 0, bank: 8, rank: 1, row: 0x4000, col: 0x400
          dimm 1 1024 Mb offset: 4, bank: 8, rank: 1, row: 0x4000, col: 0x400
diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt
index f297fc1202ae..38cf0c7b559f 100644
--- a/Documentation/eisa.txt
+++ b/Documentation/eisa.txt
@@ -84,7 +84,7 @@ struct eisa_driver {
 id_table        : an array of NULL terminated EISA id strings,
                  followed by an empty string. Each string can
-                  optionally be paired with a driver-dependant value
+                  optionally be paired with a driver-dependent value
                  (driver_data).
 driver          : a generic driver, such as described in
diff --git a/Documentation/fb/viafb.txt b/Documentation/fb/viafb.txt
index 1a2e8aa3fbb1..444e34b52ae1 100644
--- a/Documentation/fb/viafb.txt
+++ b/Documentation/fb/viafb.txt
@@ -204,7 +204,7 @@ Notes:
    supported_output_devices
-        This read-only file contains a full ',' seperated list containing all
+        This read-only file contains a full ',' separated list containing all
        output devices that could be available on your platform. It is likely
        that not all of those have a connector on your hardware but it should
        provide a good starting point to figure out which of those names match
@@ -225,7 +225,7 @@ Notes:
        This can happen for example if only one (the other) iga is used.
        Writing to these files allows adjusting the output devices during
        runtime. One can add new devices, remove existing ones or switch
-        between igas. Essentially you can write a ',' seperated list of device
+        between igas. Essentially you can write a ',' separated list of device
        names (or a single one) in the same format as the output to those
        files. You can add a '+' or '-' as a prefix allowing simple addition
        and removal of devices. So a prefix '+' adds the devices from your list
diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt
index 274b32d12532..492e81df2968 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -387,26 +387,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
diff --git a/Documentation/filesystems/autofs4-mount-control.txt b/Documentation/filesystems/autofs4-mount-control.txt
index 51986bf08a4d..4c95935cbcf4 100644
--- a/Documentation/filesystems/autofs4-mount-control.txt
+++ b/Documentation/filesystems/autofs4-mount-control.txt
@@ -309,7 +309,7 @@ ioctlfd field set to the descriptor obtained from the open call.
 AUTOFS_DEV_IOCTL_TIMEOUT_CMD
 ----------------------------
-Set the expire timeout for mounts withing an autofs mount point.
+Set the expire timeout for mounts within an autofs mount point.
 The call requires an initialized struct autofs_dev_ioctl with the
 ioctlfd field set to the descriptor obtained from the open call.
diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt
index 1902c57b72ef..a167ab876c35 100644
--- a/Documentation/filesystems/caching/netfs-api.txt
+++ b/Documentation/filesystems/caching/netfs-api.txt
@@ -95,7 +95,7 @@ restraints as possible on how an index is structured and where it is placed in
 the tree.  The netfs can even mix indices and data files at the same level, but
 it's not recommended.
-Each index entry consists of a key of indeterminate length plus some auxilliary
+Each index entry consists of a key of indeterminate length plus some auxiliary
 data, also of indeterminate length.
 There are some limits on indices:
@@ -203,23 +203,23 @@ This has the following fields:
     If the function is absent, a file size of 0 is assumed.
- (6) A function to retrieve auxilliary data from the netfs [optional].
+ (6) A function to retrieve auxiliary data from the netfs [optional].
     This function will be called with the netfs data that was passed to the
-     cookie acquisition function and the maximum length of auxilliary data that
+     cookie acquisition function and the maximum length of auxiliary data that
-     it may provide.  It should write the auxilliary data into the given buffer
+     it may provide.  It should write the auxiliary data into the given buffer
     and return the quantity it wrote.
-     If this function is absent, the auxilliary data length will be set to 0.
+     If this function is absent, the auxiliary data length will be set to 0.
-     The length of the auxilliary data buffer may be dependent on the key
+     The length of the auxiliary data buffer may be dependent on the key
     length.  A netfs mustn't rely on being able to provide more than 400 bytes
     for both.
- (7) A function to check the auxilliary data [optional].
+ (7) A function to check the auxiliary data [optional].
     This function will be called to check that a match found in the cache for
-     this object is valid.  For instance with AFS it could check the auxilliary
+     this object is valid.  For instance with AFS it could check the auxiliary
     data against the data version number returned by the server to determine
     whether the index entry in a cache is still valid.
@@ -232,7 +232,7 @@ This has the following fields:
        (*) FSCACHE_CHECKAUX_NEEDS_UPDATE       - the entry requires update
        (*) FSCACHE_CHECKAUX_OBSOLETE           - the entry should be deleted
-     This function can also be used to extract data from the auxilliary data in
+     This function can also be used to extract data from the auxiliary data in
     the cache and copy it into the netfs's structures.
 (8) A pair of functions to manage contexts for the completion callback
diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt
index fabcb0e00f25..dd57bb6bb390 100644
--- a/Documentation/filesystems/configfs/configfs.txt
+++ b/Documentation/filesystems/configfs/configfs.txt
@@ -409,7 +409,7 @@ As a consequence of this, default_groups cannot be removed directly via
 rmdir(2).  They also are not considered when rmdir(2) on the parent
 group is checking for children.
-[Dependant Subsystems]
+[Dependent Subsystems]
 Sometimes other drivers depend on particular configfs items.  For
 example, ocfs2 mounts depend on a heartbeat region item.  If that
diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt
index 6b050464a90d..c79ec58fd7f6 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -97,7 +97,7 @@ Note: More extensive information for getting started with ext4 can be
 * Inode allocation using large virtual block groups via flex_bg
 * delayed allocation
 * large block (up to pagesize) support
-* efficent new ordered mode in JBD2 and ext4(avoid using buffer head to force
+* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force
  the ordering)
 [1] Filesystems with a block size of 1k may see a limit imposed by the
@@ -106,7 +106,7 @@ directory hash tree having a maximum depth of two.
 2.2 Candidate features for future inclusion
 * Online defrag (patches available but not well tested)
-* reduced mke2fs time via lazy itable initialization in conjuction with
+* reduced mke2fs time via lazy itable initialization in conjunction with
  the uninit_bg feature (capability to do this is available in e2fsprogs
  but a kernel thread to do lazy zeroing of unused inode table blocks
  after filesystem is first mounted is required for safety)
diff --git a/Documentation/filesystems/gfs2-uevents.txt b/Documentation/filesystems/gfs2-uevents.txt
index fd966dc9979a..d81889669293 100644
--- a/Documentation/filesystems/gfs2-uevents.txt
+++ b/Documentation/filesystems/gfs2-uevents.txt
@@ -62,7 +62,7 @@ be fixed.
 The REMOVE uevent is generated at the end of an unsuccessful mount
 or at the end of a umount of the filesystem. All REMOVE uevents will
-have been preceeded by at least an ADD uevent for the same fileystem,
+have been preceded by at least an ADD uevent for the same fileystem,
 and unlike the other uevents is generated automatically by the kernel's
 kobject subsystem.
diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt
index 0b59c0200912..4cda926628aa 100644
--- a/Documentation/filesystems/gfs2.txt
+++ b/Documentation/filesystems/gfs2.txt
@@ -11,7 +11,7 @@ their I/O so file system consistency is maintained.  One of the nifty
 features of GFS is perfect consistency -- changes made to the file system
 on one machine show up immediately on all other machines in the cluster.
-GFS uses interchangable inter-node locking mechanisms, the currently
+GFS uses interchangeable inter-node locking mechanisms, the currently
 supported mechanisms are:
  lock_nolock -- allows gfs to be used as a local file system
diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt
index 933bc66ccff1..791af8dac065 100644
--- a/Documentation/filesystems/ntfs.txt
+++ b/Documentation/filesystems/ntfs.txt
@@ -350,7 +350,7 @@ Note the "Should sync?" parameter "nosync" means that the two mirrors are
 already in sync which will be the case on a clean shutdown of Windows.  If the
 mirrors are not clean, you can specify the "sync" option instead of "nosync"
 and the Device-Mapper driver will then copy the entirety of the "Source Device"
-to the "Target Device" or if you specified multipled target devices to all of
+to the "Target Device" or if you specified multiple target devices to all of
 them.
 Once you have your table, save it in a file somewhere (e.g. /etc/ntfsvolume1),
diff --git a/Documentation/filesystems/ocfs2.txt b/Documentation/filesystems/ocfs2.txt
index 5393e6611691..9ed920a8cd79 100644
--- a/Documentation/filesystems/ocfs2.txt
+++ b/Documentation/filesystems/ocfs2.txt
@@ -80,7 +80,7 @@ user_xattr	(*)	Enables Extended User Attributes.
 nouser_xattr            Disables Extended User Attributes.
 acl                     Enables POSIX Access Control Lists support.
 noacl           (*)     Disables POSIX Access Control Lists support.
-resv_level=2    (*)     Set how agressive allocation reservations will be.
+resv_level=2    (*)     Set how aggressive allocation reservations will be.
                        Valid values are between 0 (reservations off) to 8
                        (maximum space for reservations).
 dir_resv_level= (*)     By default, directory reservations will scale with file
diff --git a/Documentation/filesystems/path-lookup.txt b/Documentation/filesystems/path-lookup.txt
index eb59c8b44be9..3571667c7105 100644
--- a/Documentation/filesystems/path-lookup.txt
+++ b/Documentation/filesystems/path-lookup.txt
@@ -42,7 +42,7 @@ Path walking overview
 A name string specifies a start (root directory, cwd, fd-relative) and a
 sequence of elements (directory entry names), which together refer to a path in
 the namespace. A path is represented as a (dentry, vfsmount) tuple. The name
-elements are sub-strings, seperated by '/'.
+elements are sub-strings, separated by '/'.
 Name lookups will want to find a particular path that a name string refers to
 (usually the final element, or parent of final element). This is done by taking
@@ -354,7 +354,7 @@ vfstest 24185492        4945    708725(2.9%) 1076136(4.4%)     0        2651
 What this shows is that failed rcu-walk lookups, ie. ones that are restarted
 entirely with ref-walk, are quite rare. Even the "vfstest" case which
-specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to excercise
+specifically has concurrent renames/mkdir/rmdir/ creat/unlink/etc to exercise
 such races is not showing a huge amount of restarts.
 Dropping from rcu-walk to ref-walk mean that we have encountered a dentry where
diff --git a/Documentation/filesystems/pohmelfs/network_protocol.txt b/Documentation/filesystems/pohmelfs/network_protocol.txt
index 40ea6c295afb..65e03dd44823 100644
--- a/Documentation/filesystems/pohmelfs/network_protocol.txt
+++ b/Documentation/filesystems/pohmelfs/network_protocol.txt
@@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command
 so one can extend protocol as needed without breaking backward compatibility as long
 as old commands are supported. All string lengths include tail 0 byte.
-All commans are transfered over the network in big-endian. CPU endianess is used at the end peers.
+All commands are transferred over the network in big-endian. CPU endianess is used at the end peers.
 @cmd - command number, which specifies command to be processed. Following
        commands are used currently:
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt
index 23cae6548d3a..b0b814d75ca1 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -543,7 +543,7 @@ just those considered 'most important'.  The new vectors are:
  their statistics are used by kernel developers and interested users to
  determine the occurrence of interrupts of the given type.
-The above IRQ vectors are displayed only when relevent.  For example,
+The above IRQ vectors are displayed only when relevant.  For example,
 the threshold vector does not exist on x86_64 platforms.  Others are
 suppressed when the system is a uniprocessor.  As of this writing, only
 i386 and x86_64 platforms support the new IRQ vector displays.
@@ -1202,7 +1202,7 @@ The columns are:
                       W = can do write operations
                       U = can do unblank
  flags                E = it is enabled
-                       C = it is prefered console
+                       C = it is preferred console
                       B = it is primary boot console
                       p = it is used for printk buffer
                       b = it is not a TTY but a Braille device
@@ -1331,7 +1331,7 @@ NOTICE: /proc/<pid>/oom_adj is deprecated and will be removed, please see
 Documentation/feature-removal-schedule.txt.
 Caveat: when a parent task is selected, the oom killer will sacrifice any first
-generation children with seperate address spaces instead, if possible.  This
+generation children with separate address spaces instead, if possible.  This
 avoids servers and important system daemons from being killed and loses the
 minimal amount of work.
diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt
index 2d78f1911844..d4d41465a0b1 100644
--- a/Documentation/filesystems/squashfs.txt
+++ b/Documentation/filesystems/squashfs.txt
@@ -219,7 +219,7 @@ or if it is stored out of line (in which case the value field stores a
 reference to where the actual value is stored).  This allows large values
 to be stored out of line improving scanning and lookup performance and it
 also allows values to be de-duplicated, the value being stored once, and
-all other occurences holding an out of line reference to that value.
+all other occurrences holding an out of line reference to that value.
 The xattr lists are packed into compressed 8K metadata blocks.
 To reduce overhead in inodes, rather than storing the on-disk
diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt
index f806e50aaa63..597f728e7b4e 100644
--- a/Documentation/filesystems/sysfs.txt
+++ b/Documentation/filesystems/sysfs.txt
@@ -62,7 +62,7 @@ values of the same type.
 Mixing types, expressing multiple lines of data, and doing fancy
 formatting of data is heavily frowned upon. Doing these things may get
-you publically humiliated and your code rewritten without notice. 
+you publicly humiliated and your code rewritten without notice. 
 An attribute definition is simply:
diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt
index 80815ed654cb..21a7dc467bba 100644
--- a/Documentation/filesystems/vfs.txt
+++ b/Documentation/filesystems/vfs.txt
@@ -97,7 +97,7 @@ functions:
 The passed struct file_system_type describes your filesystem. When a
 request is made to mount a filesystem onto a directory in your namespace,
 the VFS will call the appropriate mount() method for the specific
-filesystem.  New vfsmount refering to the tree returned by ->mount()
+filesystem.  New vfsmount referring to the tree returned by ->mount()
 will be attached to the mountpoint, so that when pathname resolution
 reaches the mountpoint it will jump into the root of that vfsmount.
diff --git a/Documentation/filesystems/xfs-delayed-logging-design.txt b/Documentation/filesystems/xfs-delayed-logging-design.txt
index 5282e3e51413..2ce36439c09f 100644
--- a/Documentation/filesystems/xfs-delayed-logging-design.txt
+++ b/Documentation/filesystems/xfs-delayed-logging-design.txt
@@ -42,7 +42,7 @@ the aggregation of all the previous changes currently held only in the log.
 This relogging technique also allows objects to be moved forward in the log so
 that an object being relogged does not prevent the tail of the log from ever
 moving forward.  This can be seen in the table above by the changing
-(increasing) LSN of each subsquent transaction - the LSN is effectively a
+(increasing) LSN of each subsequent transaction - the LSN is effectively a
 direct encoding of the location in the log of the transaction.
 This relogging is also used to implement long-running, multiple-commit
@@ -338,7 +338,7 @@ the same time another transaction modifies the item and inserts the log item
 into the new CIL, then checkpoint transaction commit code cannot use log items
 to store the list of log vectors that need to be written into the transaction.
 Hence log vectors need to be able to be chained together to allow them to be
-detatched from the log items. That is, when the CIL is flushed the memory
+detached from the log items. That is, when the CIL is flushed the memory
 buffer and log vector attached to each log item needs to be attached to the
 checkpoint context so that the log item can be released. In diagrammatic form,
 the CIL would look like this before the flush:
@@ -577,7 +577,7 @@ only becomes unpinned when all the transactions complete and there are no
 pending transactions. Thus the pinning and unpinning of a log item is symmetric
 as there is a 1:1 relationship with transaction commit and log item completion.
-For delayed logging, however, we have an assymetric transaction commit to
+For delayed logging, however, we have an asymmetric transaction commit to
 completion relationship. Every time an object is relogged in the CIL it goes
 through the commit process without a corresponding completion being registered.
 That is, we now have a many-to-one relationship between transaction commit and
@@ -780,7 +780,7 @@ With delayed logging, there are new steps inserted into the life cycle:
 From this, it can be seen that the only life cycle differences between the two
 logging methods are in the middle of the life cycle - they still have the same
 beginning and end and execution constraints. The only differences are in the
-commiting of the log items to the log itself and the completion processing.
+committing of the log items to the log itself and the completion processing.
 Hence delayed logging should not introduce any constraints on log item
 behaviour, allocation or freeing that don't already exist.
diff --git a/Documentation/hwmon/abituguru b/Documentation/hwmon/abituguru
index 5eb3b9d5f0d5..915f32063a26 100644
--- a/Documentation/hwmon/abituguru
+++ b/Documentation/hwmon/abituguru
@@ -78,7 +78,7 @@ motherboards (most modern Abit motherboards).
 The first and second revision of the uGuru chip in reality is a Winbond
 W83L950D in disguise (despite Abit claiming it is "a new microprocessor
-designed by the ABIT Engineers"). Unfortunatly this doesn't help since the
+designed by the ABIT Engineers"). Unfortunately this doesn't help since the
 W83L950D is a generic microcontroller with a custom Abit application running
 on it.
diff --git a/Documentation/hwmon/abituguru-datasheet b/Documentation/hwmon/abituguru-datasheet
index d9251efdcec7..8d2be8a0b1e3 100644
--- a/Documentation/hwmon/abituguru-datasheet
+++ b/Documentation/hwmon/abituguru-datasheet
@@ -5,9 +5,9 @@ First of all, what I know about uGuru is no fact based on any help, hints or
 datasheet from Abit. The data I have got on uGuru have I assembled through
 my weak knowledge in "backwards engineering".
 And just for the record, you may have noticed uGuru isn't a chip developed by
-Abit, as they claim it to be. It's realy just an microprocessor (uC) created by
+Abit, as they claim it to be. It's really just an microprocessor (uC) created by
 Winbond (W83L950D). And no, reading the manual for this specific uC or
-mailing  Windbond for help won't give any usefull data about uGuru, as it is
+mailing  Windbond for help won't give any useful data about uGuru, as it is
 the program inside the uC that is responding to calls.
 Olle Sandberg <ollebull@gmail.com>, 2005-05-25
@@ -41,7 +41,7 @@ later on attached again data-port will hold 0x08, more about this later.
 After wider testing of the Linux kernel driver some variants of the uGuru have
 turned up which will hold 0x00 instead of 0xAC at the CMD port, thus we also
-have to test CMD for two different values. On these uGuru's DATA will initally
+have to test CMD for two different values. On these uGuru's DATA will initially
 hold 0x09 and will only hold 0x08 after reading CMD first, so CMD must be read
 first!
@@ -308,5 +308,5 @@ the voltage / clock programming out, I tried reading and only reading banks
 resulted in a _permanent_ reprogramming of the voltages, luckily I had the
 sensors part configured so that it would shutdown my system on any out of spec
 voltages which proprably safed my computer (after a reboot I managed to
-immediatly enter the bios and reload the defaults). This probably means that
+immediately enter the bios and reload the defaults). This probably means that
 the read/write cycle for the non sensor part is different from the sensor part.
diff --git a/Documentation/hwmon/abituguru3 b/Documentation/hwmon/abituguru3
index fa598aac22fa..a6ccfe4bb6aa 100644
--- a/Documentation/hwmon/abituguru3
+++ b/Documentation/hwmon/abituguru3
@@ -47,7 +47,7 @@ This driver supports the hardware monitoring features of the third revision of
 the Abit uGuru chip, found on recent Abit uGuru featuring motherboards.
 The 3rd revision of the uGuru chip in reality is a Winbond W83L951G.
-Unfortunatly this doesn't help since the W83L951G is a generic microcontroller
+Unfortunately this doesn't help since the W83L951G is a generic microcontroller
 with a custom Abit application running on it.
 Despite Abit not releasing any information regarding the uGuru revision 3,
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 f2d42e8bdf48..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: -
@@ -150,11 +130,11 @@ The following attributes are supported. Limits are read-write; all other
 attributes are read-only.
 inX_input               Measured voltage. From READ_VIN or READ_VOUT register.
-inX_min                 Minumum Voltage.
+inX_min                 Minimum Voltage.
                        From VIN_UV_WARN_LIMIT or VOUT_UV_WARN_LIMIT register.
 inX_max                 Maximum voltage.
                        From VIN_OV_WARN_LIMIT or VOUT_OV_WARN_LIMIT register.
-inX_lcrit               Critical minumum Voltage.
+inX_lcrit               Critical minimum Voltage.
                        From VIN_UV_FAULT_LIMIT or VOUT_UV_FAULT_LIMIT register.
 inX_crit                Critical maximum voltage.
                        From VIN_OV_FAULT_LIMIT or VOUT_OV_FAULT_LIMIT register.
@@ -169,17 +149,19 @@ inX_label		"vin", "vcap", or "voutY"
 currX_input             Measured current. From READ_IIN or READ_IOUT register.
 currX_max               Maximum current.
                        From IIN_OC_WARN_LIMIT or IOUT_OC_WARN_LIMIT register.
-currX_lcrit             Critical minumum output current.
+currX_lcrit             Critical minimum output current.
                        From IOUT_UC_FAULT_LIMIT register.
 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_min               Mimimum temperature. From UT_WARN_LIMIT register.
-tempX_max               Maximum tempererature. From OT_WARN_LIMIT register.
+tempX_max               Maximum temperature. From OT_WARN_LIMIT register.
-tempX_lcrit             Critical low tempererature.
+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_input             Chip temperature
-temp1_min               Mimimum chip tempererature
+temp1_min               Mimimum chip temperature
-temp1_max               Maximum chip tempererature
+temp1_max               Maximum chip temperature
-temp1_crit              Critical chip tempererature
+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/hwmon/sysfs-interface b/Documentation/hwmon/sysfs-interface
index 83a698773ade..8f63c244f1aa 100644
--- a/Documentation/hwmon/sysfs-interface
+++ b/Documentation/hwmon/sysfs-interface
@@ -579,7 +579,7 @@ channel should not be trusted.
 fan[1-*]_fault
 temp[1-*]_fault
                Input fault condition
-                0: no fault occured
+                0: no fault occurred
                1: fault condition
                RO
diff --git a/Documentation/hwmon/w83781d b/Documentation/hwmon/w83781d
index ecbc1e4574b4..129b0a3b555b 100644
--- a/Documentation/hwmon/w83781d
+++ b/Documentation/hwmon/w83781d
@@ -403,7 +403,7 @@ found out the following values do work as a form of coarse pwm:
 0x80 - seems to turn fans off after some time(1-2 minutes)... might be
 some form of auto-fan-control based on temp? hmm (Qfan? this mobo is an
-old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attemp at Qfan
+old ASUS, it isn't marketed as Qfan. Maybe some beta pre-attempt at Qfan
 that was dropped at the BIOS)
 0x81 - off
 0x82 - slightly "on-ner" than off, but my fans do not get to move. I can
diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d
index 5663e491655c..90387c3540f7 100644
--- a/Documentation/hwmon/w83791d
+++ b/Documentation/hwmon/w83791d
@@ -93,7 +93,7 @@ The sysfs interface to the beep bitmask has migrated from the original legacy
 method of a single sysfs beep_mask file to a newer method using multiple
 *_beep files as described in .../Documentation/hwmon/sysfs-interface.
-A similar change has occured for the bitmap corresponding to the alarms. The
+A similar change has occurred for the bitmap corresponding to the alarms. The
 original legacy method used a single sysfs alarms file containing a bitmap
 of triggered alarms. The newer method uses multiple sysfs *_alarm files
 (again following the pattern described in sysfs-interface).
diff --git a/Documentation/i2c/busses/i2c-parport-light b/Documentation/i2c/busses/i2c-parport-light
index bdc9cbb2e0f2..c22ee063e1e5 100644
--- a/Documentation/i2c/busses/i2c-parport-light
+++ b/Documentation/i2c/busses/i2c-parport-light
@@ -4,7 +4,7 @@ Author: Jean Delvare <khali@linux-fr.org>
 This driver is a light version of i2c-parport. It doesn't depend        
 on the parport driver, and uses direct I/O access instead. This might be
-prefered on embedded systems where wasting memory for the clean but heavy
+preferred on embedded systems where wasting memory for the clean but heavy
 parport handling is not an option. The drawback is a reduced portability
 and the impossibility to daisy-chain other parallel port devices.                 
  
diff --git a/Documentation/i2c/busses/i2c-sis96x b/Documentation/i2c/busses/i2c-sis96x
index 70e6a0cc1e15..0b979f3252a4 100644
--- a/Documentation/i2c/busses/i2c-sis96x
+++ b/Documentation/i2c/busses/i2c-sis96x
@@ -35,7 +35,7 @@ or perhaps this...
 (kernel versions later than 2.4.18 may fill in the "Unknown"s)
-If you cant see it please look on quirk_sis_96x_smbus
+If you can't see it please look on quirk_sis_96x_smbus
 (drivers/pci/quirks.c) (also if southbridge detection fails)
 I suspect that this driver could be made to work for the following SiS
diff --git a/Documentation/i2c/busses/i2c-taos-evm b/Documentation/i2c/busses/i2c-taos-evm
index 9146e33be6dd..63f62bcbf592 100644
--- a/Documentation/i2c/busses/i2c-taos-evm
+++ b/Documentation/i2c/busses/i2c-taos-evm
@@ -13,7 +13,7 @@ Currently supported devices are:
 * TAOS TSL2550 EVM
-For addtional information on TAOS products, please see
+For additional information on TAOS products, please see
  http://www.taosinc.com/
diff --git a/Documentation/i2o/README b/Documentation/i2o/README
index 0ebf58c73f54..ee91e2626ff0 100644
--- a/Documentation/i2o/README
+++ b/Documentation/i2o/README
@@ -53,7 +53,7 @@ Symbios Logic (Now LSI)
 BoxHill Corporation
        Loan of initial FibreChannel disk array used for development work.
-European Comission
+European Commission
        Funding the work done by the University of Helsinki
 SysKonnect
diff --git a/Documentation/ia64/aliasing-test.c b/Documentation/ia64/aliasing-test.c
index 3dfb76ca6931..5caa2af33207 100644
--- a/Documentation/ia64/aliasing-test.c
+++ b/Documentation/ia64/aliasing-test.c
@@ -177,7 +177,7 @@ static int scan_rom(char *path, char *file)
                        /*
                         * It's OK if the ROM is unreadable.  Maybe there
-                         * is no ROM, or some other error ocurred.  The
+                         * is no ROM, or some other error occurred.  The
                         * important thing is that no MCA happened.
                         */
                        if (rc > 0)
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/input/joystick-parport.txt b/Documentation/input/joystick-parport.txt
index 1c856f32ff2c..56870c70a796 100644
--- a/Documentation/input/joystick-parport.txt
+++ b/Documentation/input/joystick-parport.txt
@@ -272,7 +272,7 @@ if you want to use gamecon.c.
  Also, the connection is a bit more complex. You'll need a bunch of diodes,
 and one pullup resistor. First, you connect the Directions and the button
-the same as for db9, however with the diodes inbetween.
+the same as for db9, however with the diodes between.
            Diodes
 (pin 2) -----|<|----> Up
diff --git a/Documentation/input/rotary-encoder.txt b/Documentation/input/rotary-encoder.txt
index 8b4129de1d2d..943e8f6f2b15 100644
--- a/Documentation/input/rotary-encoder.txt
+++ b/Documentation/input/rotary-encoder.txt
@@ -46,7 +46,7 @@ c) Falling edge on channel A, channel B in high state
 d) Falling edge on channel B, channel A in low state
        Parking position. If the encoder enters this state, a full transition
-        should have happend, unless it flipped back on half the way. The
+        should have happened, unless it flipped back on half the way. The
        'armed' state tells us about that.
 2. Platform requirements
diff --git a/Documentation/input/walkera0701.txt b/Documentation/input/walkera0701.txt
index 8f4289efc5c4..561385d38482 100644
--- a/Documentation/input/walkera0701.txt
+++ b/Documentation/input/walkera0701.txt
@@ -77,7 +77,7 @@ pulse length:
 24 bin+oct values + 1 bin value = 24*4+1 bits  = 97 bits
-(Warning, pulses on ACK ar inverted by transistor, irq is rised up on sync
+(Warning, pulses on ACK are inverted by transistor, irq is raised up on sync
 to bin change or octal value to bin change).
 Binary data representations:
diff --git a/Documentation/irqflags-tracing.txt b/Documentation/irqflags-tracing.txt
index 6a444877ee0b..67aa71e73035 100644
--- a/Documentation/irqflags-tracing.txt
+++ b/Documentation/irqflags-tracing.txt
@@ -53,5 +53,5 @@ implementation in an architecture: lockdep will detect that and will
 turn itself off. I.e. the lock validator will still be reliable. There
 should be no crashes due to irq-tracing bugs. (except if the assembly
 changes break other code by modifying conditions or registers that
-shouldnt be)
+shouldn't be)
diff --git a/Documentation/isdn/INTERFACE.CAPI b/Documentation/isdn/INTERFACE.CAPI
index 309eb5ed942b..1688b5a1fd77 100644
--- a/Documentation/isdn/INTERFACE.CAPI
+++ b/Documentation/isdn/INTERFACE.CAPI
@@ -240,7 +240,7 @@ Functions capi_cmsg2message() and capi_message2cmsg() are provided to convert
 messages between their transport encoding described in the CAPI 2.0 standard
 and their _cmsg structure representation. Note that capi_cmsg2message() does
 not know or check the size of its destination buffer. The caller must make
-sure it is big enough to accomodate the resulting CAPI message.
+sure it is big enough to accommodate the resulting CAPI message.
 5. Lower Layer Interface Functions
diff --git a/Documentation/kbuild/kbuild.txt b/Documentation/kbuild/kbuild.txt
index f1431d099fce..7c2a89ba674c 100644
--- a/Documentation/kbuild/kbuild.txt
+++ b/Documentation/kbuild/kbuild.txt
@@ -26,11 +26,11 @@ Additional options to the assembler (for built-in and modules).
 AFLAGS_MODULE
 --------------------------------------------------
-Addtional module specific options to use for $(AS).
+Additional module specific options to use for $(AS).
 AFLAGS_KERNEL
 --------------------------------------------------
-Addtional options for $(AS) when used for assembler
+Additional options for $(AS) when used for assembler
 code for code that is compiled as built-in.
 KCFLAGS
@@ -39,12 +39,12 @@ Additional options to the C compiler (for built-in and modules).
 CFLAGS_KERNEL
 --------------------------------------------------
-Addtional options for $(CC) when used to compile
+Additional options for $(CC) when used to compile
 code that is compiled as built-in.
 CFLAGS_MODULE
 --------------------------------------------------
-Addtional module specific options to use for $(CC).
+Additional module specific options to use for $(CC).
 LDFLAGS_MODULE
 --------------------------------------------------
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index c357a31411cd..cc85a9278190 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -699,7 +699,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        ekgdboc=        [X86,KGDB] Allow early kernel console debugging
                        ekgdboc=kbd
-                        This is desgined to be used in conjunction with
+                        This is designed to be used in conjunction with
                        the boot argument: earlyprintk=vga
        edd=            [EDD]
@@ -1832,15 +1832,17 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                                perfmon on Intel CPUs instead of the
                                CPU specific event set.
-        oops=panic      Always panic on oopses. Default is to just kill the process,
+        oops=panic      Always panic on oopses. Default is to just kill the
-                        but there is a small probability of deadlocking the machine.
+                        process, but there is a small probability of
+                        deadlocking the machine.
                        This will also cause panics on machine check exceptions.
                        Useful together with panic=30 to trigger a reboot.
        OSS             [HW,OSS]
                        See Documentation/sound/oss/oss-parameters.txt
-        panic=          [KNL] Kernel behaviour on panic
+        panic=          [KNL] Kernel behaviour on panic: delay <timeout>
+                        seconds before rebooting
                        Format: <timeout>
        parkbd.port=    [HW] Parallel port number the keyboard adapter is
@@ -2343,6 +2345,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        softlockup_panic=
                        [KNL] Should the soft-lockup detector generate panics.
+                        Format: <integer>
        sonypi.*=       [HW] Sony Programmable I/O Control Device driver
                        See Documentation/sonypi.txt
@@ -2475,8 +2478,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
        topology=       [S390]
                        Format: {off | on}
                        Specify if the kernel should make use of the cpu
-                        topology informations if the hardware supports these.
+                        topology information if the hardware supports this.
-                        The scheduler will make use of these informations and
+                        The scheduler will make use of this information and
                        e.g. base its process migration decisions on it.
                        Default is on.
@@ -2529,8 +2532,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
                        reported either.
        unknown_nmi_panic
-                        [X86]
+                        [X86] Cause panic on unknown NMI.
-                        Set unknown_nmi_panic=1 early on boot.
        usbcore.autosuspend=
                        [USB] The autosuspend time delay (in seconds) used
diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt
index 34f6638aa5ac..090e6ee04536 100644
--- a/Documentation/kmemleak.txt
+++ b/Documentation/kmemleak.txt
@@ -11,6 +11,7 @@ with the difference that the orphan objects are not freed but only
 reported via /sys/kernel/debug/kmemleak. A similar method is used by the
 Valgrind tool (memcheck --leak-check) to detect the memory leaks in
 user-space applications.
+Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile.
 Usage
 -----
@@ -178,5 +179,4 @@ block doesn't need to be freed (some cases in the init_call functions),
 the pointer is calculated by other methods than the usual container_of
 macro or the pointer is stored in a location not scanned by kmemleak.
-Page allocations and ioremap are not tracked. Only the ARM and x86
+Page allocations and ioremap are not tracked.
-architectures are currently supported.
diff --git a/Documentation/kvm/mmu.txt b/Documentation/kvm/mmu.txt
index 142cc5136650..f46aa58389ca 100644
--- a/Documentation/kvm/mmu.txt
+++ b/Documentation/kvm/mmu.txt
@@ -23,7 +23,7 @@ The mmu code attempts to satisfy the following requirements:
               and framebuffer-based displays
 - footprint:   keep the amount of pinned kernel memory low (most memory
               should be shrinkable)
- reliablity:  avoid multipage or GFP_ATOMIC allocations
+- reliability:  avoid multipage or GFP_ATOMIC allocations
 Acronyms
 ========
diff --git a/Documentation/kvm/ppc-pv.txt b/Documentation/kvm/ppc-pv.txt
index a7f2244b3be9..3ab969c59046 100644
--- a/Documentation/kvm/ppc-pv.txt
+++ b/Documentation/kvm/ppc-pv.txt
@@ -136,7 +136,7 @@ Patched instructions
 ====================
 The "ld" and "std" instructions are transormed to "lwz" and "stw" instructions
-respectively on 32 bit systems with an added offset of 4 to accomodate for big
+respectively on 32 bit systems with an added offset of 4 to accommodate for big
 endianness.
 The following is a list of mapping the Linux kernel performs when running as
diff --git a/Documentation/kvm/timekeeping.txt b/Documentation/kvm/timekeeping.txt
index 0c5033a58c9e..df8946377cb6 100644
--- a/Documentation/kvm/timekeeping.txt
+++ b/Documentation/kvm/timekeeping.txt
@@ -81,7 +81,7 @@ Mode 0: Single Timeout.   This is a one-shot software timeout that counts down
 when the gate is high (always true for timers 0 and 1).  When the count
 reaches zero, the output goes high.
-Mode 1: Triggered One-shot.  The output is intially set high.  When the gate
+Mode 1: Triggered One-shot.  The output is initially set high.  When the gate
 line is set high, a countdown is initiated (which does not stop if the gate is
 lowered), during which the output is set low.  When the count reaches zero,
 the output goes high.
diff --git a/Documentation/laptops/asus-laptop.txt b/Documentation/laptops/asus-laptop.txt
index c1c5be84e4b1..803e51f6768b 100644
--- a/Documentation/laptops/asus-laptop.txt
+++ b/Documentation/laptops/asus-laptop.txt
@@ -61,7 +61,7 @@ Usage
  Hotkeys are also reported as input keys (like keyboards) you can check
  which key are supported using "xev" under X11.
-  You can get informations on the version of your DSDT table by reading the
+  You can get information on the version of your DSDT table by reading the
  /sys/devices/platform/asus-laptop/infos entry. If you have a question or a
  bug report to do, please include the output of this entry.
@@ -178,7 +178,7 @@ LED display
 -----------
  Some models like the W1N have a LED display that can be used to display
-  several informations.
+  several items of information.
  LED display works for the following models:
    W1000N
diff --git a/Documentation/leds/00-INDEX b/Documentation/leds/00-INDEX
new file mode 100644
index 000000000000..29f481df32c7
--- /dev/null
+++ b/Documentation/leds/00-INDEX
@@ -0,0 +1,8 @@
+leds-class.txt
+        - documents LED handling under Linux.
+leds-lp3944.txt
+        - notes on how to use the leds-lp3944 driver.
+leds-lp5521.txt
+        - notes on how to use the leds-lp5521 driver.
+leds-lp5523.txt
+        - notes on how to use the leds-lp5523 driver.
diff --git a/Documentation/leds-class.txt b/Documentation/leds/leds-class.txt
index 58b266bd1846..4996586e27e8 100644
--- a/Documentation/leds-class.txt
+++ b/Documentation/leds/leds-class.txt
@@ -95,4 +95,3 @@ There are a number of cases where a trigger might only be mappable to a
 particular LED (ACPI?). The addition of triggers provided by the LED driver
 should cover this option and be possible to add without breaking the
 current interface.
diff --git a/Documentation/leds-lp3944.txt b/Documentation/leds/leds-lp3944.txt
index c6eda18b15ef..c6eda18b15ef 100644
--- a/Documentation/leds-lp3944.txt
+++ b/Documentation/leds/leds-lp3944.txt
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/media-framework.txt b/Documentation/media-framework.txt
index fd48add02cb0..76a2087db205 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -194,7 +194,7 @@ each pad.
 Links are represented by a struct media_link instance, defined in
 include/media/media-entity.h. Each entity stores all links originating at or
-targetting any of its pads in a links array. A given link is thus stored
+targeting any of its pads in a links array. A given link is thus stored
 twice, once in the source entity and once in the target entity. The array is
 pre-allocated and grows dynamically as needed.
@@ -348,6 +348,6 @@ a streaming entity. Links that can be modified while streaming must be marked
 with the MEDIA_LNK_FL_DYNAMIC flag.
 If other operations need to be disallowed on streaming entities (such as
-changing entities configuration parameters) drivers can explictly check the
+changing entities configuration parameters) drivers can explicitly check the
 media_entity stream_count field to find out if an entity is streaming. This
 operation must be done with the media_device graph_mutex held.
diff --git a/Documentation/mips/AU1xxx_IDE.README b/Documentation/mips/AU1xxx_IDE.README
index 8ace35ebdcd5..cc887ecfd6eb 100644
--- a/Documentation/mips/AU1xxx_IDE.README
+++ b/Documentation/mips/AU1xxx_IDE.README
@@ -39,13 +39,13 @@ Note: for more information, please refer "AMD Alchemy Au1200/Au1550 IDE
      Interface and Linux Device Driver" Application Note.
-FILES, CONFIGS AND COMPATABILITY
+FILES, CONFIGS AND COMPATIBILITY
 --------------------------------
 Two files are introduced:
  a) 'arch/mips/include/asm/mach-au1x00/au1xxx_ide.h'
-     containes : struct _auide_hwif
+     contains : struct _auide_hwif
                 timing parameters for PIO mode 0/1/2/3/4
                 timing parameters for MWDMA 0/1/2
diff --git a/Documentation/misc-devices/ics932s401 b/Documentation/misc-devices/ics932s401
index 07a739f406d8..bdac67ff6e3f 100644
--- a/Documentation/misc-devices/ics932s401
+++ b/Documentation/misc-devices/ics932s401
@@ -5,7 +5,7 @@ Supported chips:
  * IDT ICS932S401
    Prefix: 'ics932s401'
    Addresses scanned: I2C 0x69
-    Datasheet: Publically available at the IDT website
+    Datasheet: Publicly available at the IDT website
 Author: Darrick J. Wong
diff --git a/Documentation/networking/3c359.txt b/Documentation/networking/3c359.txt
index 4af8071a6d18..dadfe8147ab8 100644
--- a/Documentation/networking/3c359.txt
+++ b/Documentation/networking/3c359.txt
@@ -45,7 +45,7 @@ debugging messages on, that must be done by modified the source code.
 Variable MTU size:
-The driver can handle a MTU size upto either 4500 or 18000 depending upon 
+The driver can handle a MTU size up to either 4500 or 18000 depending upon 
 ring speed.  The driver also changes the size of the receive buffers as part
 of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
 to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
diff --git a/Documentation/networking/README.ipw2200 b/Documentation/networking/README.ipw2200
index 616a8e540b0b..b7658bed4906 100644
--- a/Documentation/networking/README.ipw2200
+++ b/Documentation/networking/README.ipw2200
@@ -256,7 +256,7 @@ You can set the debug level via:
 Where $VALUE would be a number in the case of this sysfs entry.  The 
 input to sysfs files does not have to be a number.  For example, the 
-firmware loader used by hotplug utilizes sysfs entries for transfering 
+firmware loader used by hotplug utilizes sysfs entries for transferring 
 the firmware image from user space into the driver.
 The Intel(R) PRO/Wireless 2915ABG Driver for Linux exposes sysfs entries 
diff --git a/Documentation/networking/batman-adv.txt b/Documentation/networking/batman-adv.txt
index 18afcd8afd51..ee496eb2f4a6 100644
--- a/Documentation/networking/batman-adv.txt
+++ b/Documentation/networking/batman-adv.txt
@@ -72,7 +72,7 @@ folder:
 #  fragmentation    gw_sel_class  vis_mode
-There is a special folder for debugging informations:
+There is a special folder for debugging information:
 #  ls /sys/kernel/debug/batman_adv/bat0/
 #  gateways     socket        transtable_global  vis_data
diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt
index b36e741e94db..e27202bb8d75 100644
--- a/Documentation/networking/bonding.txt
+++ b/Documentation/networking/bonding.txt
@@ -368,7 +368,7 @@ fail_over_mac
                gratuitous ARP is lost, communication may be
                disrupted.
-                When this policy is used in conjuction with the mii
+                When this policy is used in conjunction with the mii
                monitor, devices which assert link up prior to being
                able to actually transmit and receive are particularly
                susceptible to loss of the gratuitous ARP, and an
diff --git a/Documentation/networking/caif/Linux-CAIF.txt b/Documentation/networking/caif/Linux-CAIF.txt
index 7fe7a9a33a4f..e52fd62bef3a 100644
--- a/Documentation/networking/caif/Linux-CAIF.txt
+++ b/Documentation/networking/caif/Linux-CAIF.txt
@@ -136,7 +136,7 @@ The CAIF Protocol implementation contains:
      - CFMUX CAIF Mux layer. Handles multiplexing between multiple
        physical bearers and multiple channels such as VEI, Datagram, etc.
        The MUX keeps track of the existing CAIF Channels and
-        Physical Instances and selects the apropriate instance based
+        Physical Instances and selects the appropriate instance based
        on Channel-Id and Physical-ID.
      - CFFRML CAIF Framing layer. Handles Framing i.e. Frame length
diff --git a/Documentation/networking/caif/spi_porting.txt b/Documentation/networking/caif/spi_porting.txt
index 0cb8cb9098f4..9efd0687dc4c 100644
--- a/Documentation/networking/caif/spi_porting.txt
+++ b/Documentation/networking/caif/spi_porting.txt
@@ -150,7 +150,7 @@ static int sspi_init_xfer(struct cfspi_xfer *xfer, struct cfspi_dev *dev)
 void sspi_sig_xfer(bool xfer, struct cfspi_dev *dev)
 {
        /* If xfer is true then you should assert the SPI_INT to indicate to
-         * the master that you are ready to recieve the data from the master
+         * the master that you are ready to receive the data from the master
         * SPI. If xfer is false then you should de-assert SPI_INT to indicate
         * that the transfer is done.
         */
diff --git a/Documentation/networking/can.txt b/Documentation/networking/can.txt
index 5b04b67ddca2..56ca3b75376e 100644
--- a/Documentation/networking/can.txt
+++ b/Documentation/networking/can.txt
@@ -240,7 +240,7 @@ solution for a couple of reasons:
  the user application using the common CAN filter mechanisms. Inside
  this filter definition the (interested) type of errors may be
  selected. The reception of error frames is disabled by default.
-  The format of the CAN error frame is briefly decribed in the Linux
+  The format of the CAN error frame is briefly described in the Linux
  header file "include/linux/can/error.h".
 4. How to use Socket CAN
diff --git a/Documentation/networking/ieee802154.txt b/Documentation/networking/ieee802154.txt
index 23c995e64032..f41ea2405220 100644
--- a/Documentation/networking/ieee802154.txt
+++ b/Documentation/networking/ieee802154.txt
@@ -9,7 +9,7 @@ The Linux-ZigBee project goal is to provide complete implementation
 of IEEE 802.15.4 / ZigBee / 6LoWPAN protocols. IEEE 802.15.4 is a stack
 of protocols for organizing Low-Rate Wireless Personal Area Networks.
-Currently only IEEE 802.15.4 layer is implemented. We have choosen
+Currently only IEEE 802.15.4 layer is implemented. We have chosen
 to use plain Berkeley socket API, the generic Linux networking stack
 to transfer IEEE 802.15.4 messages and a special protocol over genetlink
 for configuration/management
diff --git a/Documentation/networking/olympic.txt b/Documentation/networking/olympic.txt
index c65a94010ea8..b95b5bf96751 100644
--- a/Documentation/networking/olympic.txt
+++ b/Documentation/networking/olympic.txt
@@ -65,7 +65,7 @@ together.
 Variable MTU size:
-The driver can handle a MTU size upto either 4500 or 18000 depending upon 
+The driver can handle a MTU size up to either 4500 or 18000 depending upon 
 ring speed.  The driver also changes the size of the receive buffers as part
 of the mtu re-sizing, so if you set mtu = 18000, you will need to be able
 to allocate 16 * (sk_buff with 18000 buffer size) call it 18500 bytes per ring 
diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt
index 073894d1c093..4acea6603720 100644
--- a/Documentation/networking/packet_mmap.txt
+++ b/Documentation/networking/packet_mmap.txt
@@ -223,7 +223,7 @@ we will get the following buffer structure:
 A frame can be of any size with the only condition it can fit in a block. A block
 can only hold an integer number of frames, or in other words, a frame cannot 
-be spawned accross two blocks, so there are some details you have to take into 
+be spawned across two blocks, so there are some details you have to take into 
 account when choosing the frame_size. See "Mapping and use of the circular 
 buffer (ring)".
diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt
index 9d4e0f4df5a8..4be0c039edbc 100644
--- a/Documentation/networking/s2io.txt
+++ b/Documentation/networking/s2io.txt
@@ -37,7 +37,7 @@ To associate an interface with a physical adapter use "ethtool -p <ethX>".
 The corresponding adapter's LED will blink multiple times.
 3.      Features supported:
-a. Jumbo frames. Xframe I/II supports MTU upto 9600 bytes,
+a. Jumbo frames. Xframe I/II supports MTU up to 9600 bytes,
 modifiable using ifconfig command.
 b. Offloads. Supports checksum offload(TCP/UDP/IP) on transmit
@@ -49,7 +49,7 @@ significant performance improvement on certain platforms(SGI Altix,
 IBM xSeries).
 d. MSI/MSI-X. Can be enabled on platforms which support this feature
-(IA64, Xeon) resulting in noticeable performance improvement(upto 7%
+(IA64, Xeon) resulting in noticeable performance improvement(up to 7%
 on certain platforms).
 e. Statistics. Comprehensive MAC-level and software statistics displayed
diff --git a/Documentation/networking/tc-actions-env-rules.txt b/Documentation/networking/tc-actions-env-rules.txt
index dcadf6f88e34..70d6cf608251 100644
--- a/Documentation/networking/tc-actions-env-rules.txt
+++ b/Documentation/networking/tc-actions-env-rules.txt
@@ -1,5 +1,5 @@
-The "enviromental" rules for authors of any new tc actions are:
+The "environmental" rules for authors of any new tc actions are:
 1) If you stealeth or borroweth any packet thou shalt be branching
 from the righteous path and thou shalt cloneth.
@@ -20,7 +20,7 @@ this way any action downstream can stomp on the packet.
 3) Dropping packets you don't own is a no-no. You simply return
 TC_ACT_SHOT to the caller and they will drop it.
-The "enviromental" rules for callers of actions (qdiscs etc) are:
+The "environmental" rules for callers of actions (qdiscs etc) are:
 *) Thou art responsible for freeing anything returned as being
 TC_ACT_SHOT/STOLEN/QUEUED. If none of TC_ACT_SHOT/STOLEN/QUEUED is
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index f023ba6bba62..1971bcf48a60 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -367,7 +367,7 @@ Drivers need to be able to handle hardware which has been reset since the
 suspend methods were called, for example by complete reinitialization.
 This may be the hardest part, and the one most protected by NDA'd documents
 and chip errata.  It's simplest if the hardware state hasn't changed since
-the suspend was carried out, but that can't be guaranteed (in fact, it ususally
+the suspend was carried out, but that can't be guaranteed (in fact, it usually
 is not the case).
 Drivers must also be prepared to notice that the device has been removed
diff --git a/Documentation/power/notifiers.txt b/Documentation/power/notifiers.txt
index ae1b7ec07684..cf980709122a 100644
--- a/Documentation/power/notifiers.txt
+++ b/Documentation/power/notifiers.txt
@@ -24,7 +24,7 @@ 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 occured during the
+                        hibernation image or an error occurred during the
                        hibernation.  Device drivers' .resume() callbacks have
                        been executed and tasks have been thawed.
@@ -38,7 +38,7 @@ PM_POST_RESTORE		An error occurred during the hibernation restore.
 PM_SUSPEND_PREPARE      The system is preparing for a suspend.
-PM_POST_SUSPEND         The system has just resumed or an error occured during
+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.
diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt
index cd445582d1f8..5ae70a12c1e2 100644
--- a/Documentation/power/opp.txt
+++ b/Documentation/power/opp.txt
@@ -178,7 +178,7 @@ opp_find_freq_ceil - Search for an available OPP which is *at least* the
                if (!IS_ERR(opp))
                        soc_switch_to_freq_voltage(freq);
                else
-                        /* do something when we cant satisfy the req */
+                        /* do something when we can't satisfy the req */
                /* do other stuff */
         }
diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
index ea718891a665..ac190cf1963e 100644
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -192,7 +192,7 @@ Q: There don't seem to be any generally useful behavioral
 distinctions between SUSPEND and FREEZE.
 A: Doing SUSPEND when you are asked to do FREEZE is always correct,
-but it may be unneccessarily slow. If you want your driver to stay simple,
+but it may be unnecessarily slow. If you want your driver to stay simple,
 slowness may not matter to you. It can always be fixed later.
 For devices like disk it does matter, you do not want to spindown for
@@ -237,7 +237,7 @@ disk. Whole sequence goes like
      running system, user asks for suspend-to-disk
-      user processes are stopped (in common case there are none, but with resume-from-initrd, noone knows)
+      user processes are stopped (in common case there are none, but with resume-from-initrd, no one knows)
      read image from disk
diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt
index 81680f9f5909..1101bee4e822 100644
--- a/Documentation/power/userland-swsusp.txt
+++ b/Documentation/power/userland-swsusp.txt
@@ -98,7 +98,7 @@ SNAPSHOT_S2RAM - suspend to RAM; using this call causes the kernel to
 The device's read() operation can be used to transfer the snapshot image from
 the kernel.  It has the following limitations:
 - you cannot read() more than one virtual memory page at a time
- read()s accross page boundaries are impossible (ie. if ypu read() 1/2 of
+- read()s across page boundaries are impossible (ie. if ypu read() 1/2 of
        a page in the previous call, you will only be able to read()
        _at_ _most_ 1/2 of the page in the next call)
@@ -137,7 +137,7 @@ mechanism and the userland utilities using the interface SHOULD use additional
 means, such as checksums, to ensure the integrity of the snapshot image.
 The suspending and resuming utilities MUST lock themselves in memory,
-preferrably using mlockall(), before calling SNAPSHOT_FREEZE.
+preferably using mlockall(), before calling SNAPSHOT_FREEZE.
 The suspending utility MUST check the value stored by SNAPSHOT_CREATE_IMAGE
 in the memory location pointed to by the last argument of ioctl() and proceed
@@ -147,7 +147,7 @@ in accordance with it:
        (a)     The suspending utility MUST NOT close the snapshot device
                _unless_ the whole suspend procedure is to be cancelled, in
                which case, if the snapshot image has already been saved, the
-                suspending utility SHOULD destroy it, preferrably by zapping
+                suspending utility SHOULD destroy it, preferably by zapping
                its header.  If the suspend is not to be cancelled, the
                system MUST be powered off or rebooted after the snapshot
                image has been saved.
diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt
index 6d8be3468d7d..a730ca5a07f8 100644
--- a/Documentation/powerpc/hvcs.txt
+++ b/Documentation/powerpc/hvcs.txt
@@ -528,7 +528,7 @@ this driver assignment of hotplug added vty-servers may be in a different
 order than how they would be exposed on module load.  Rebooting or
 reloading the module after dynamic addition may result in the /dev/hvcs*
 and vty-server coupling changing if a vty-server adapter was added in a
-slot inbetween two other vty-server adapters.  Refer to the section above
+slot between two other vty-server adapters.  Refer to the section above
 on how to determine which vty-server goes with which /dev/hvcs* node.
 Hint; look at the sysfs "index" attribute for the vty-server.
diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt
index 86f9f74b2b34..efe998becc5b 100644
--- a/Documentation/s390/Debugging390.txt
+++ b/Documentation/s390/Debugging390.txt
@@ -2273,7 +2273,7 @@ IP forwarding is on.
 There is a lot of useful info in here best found by going in & having a look around,
 so I'll take you through some entries I consider important.
-All the processes running on the machine have there own entry defined by
+All the processes running on the machine have their own entry defined by
 /proc/<pid>
 So lets have a look at the init process
 cd /proc/1
diff --git a/Documentation/scheduler/sched-domains.txt b/Documentation/scheduler/sched-domains.txt
index 373ceacc367e..b7ee379b651b 100644
--- a/Documentation/scheduler/sched-domains.txt
+++ b/Documentation/scheduler/sched-domains.txt
@@ -1,8 +1,7 @@
-Each CPU has a "base" scheduling domain (struct sched_domain). These are
+Each CPU has a "base" scheduling domain (struct sched_domain). The domain
-accessed via cpu_sched_domain(i) and this_sched_domain() macros. The domain
 hierarchy is built from these base domains via the ->parent pointer. ->parent
-MUST be NULL terminated, and domain structures should be per-CPU as they
+MUST be NULL terminated, and domain structures should be per-CPU as they are
-are locklessly updated.
+locklessly updated.
 Each scheduling domain spans a number of CPUs (stored in the ->span field).
 A domain's span MUST be a superset of it child's span (this restriction could
@@ -26,11 +25,26 @@ is treated as one entity. The load of a group is defined as the sum of the
 load of each of its member CPUs, and only when the load of a group becomes
 out of balance are tasks moved between groups.
-In kernel/sched.c, rebalance_tick is run periodically on each CPU. This
+In kernel/sched.c, trigger_load_balance() is run periodically on each CPU
-function takes its CPU's base sched domain and checks to see if has reached
+through scheduler_tick(). It raises a softirq after the next regularly scheduled
-its rebalance interval. If so, then it will run load_balance on that domain.
+rebalancing event for the current runqueue has arrived. The actual load
-rebalance_tick then checks the parent sched_domain (if it exists), and the
+balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run
-parent of the parent and so forth.
+in softirq context (SCHED_SOFTIRQ).
+The latter function takes two arguments: the current CPU and whether it was idle
+at the time the scheduler_tick() happened and iterates over all sched domains
+our CPU is on, starting from its base domain and going up the ->parent chain.
+While doing that, it checks to see if the current domain has exhausted its
+rebalance interval. If so, it runs load_balance() on that domain. It then checks
+the parent sched_domain (if it exists), and the parent of the parent and so
+forth.
+Initially, load_balance() finds the busiest group in the current sched domain.
+If it succeeds, it looks for the busiest runqueue of all the CPUs' runqueues in
+that group. If it manages to find such a runqueue, it locks both our initial
+CPU's runqueue and the newly found busiest one and starts moving tasks from it
+to our runqueue. The exact number of tasks amounts to an imbalance previously
+computed while iterating over this sched domain's groups.
 *** Implementing sched domains ***
 The "base" domain will "span" the first level of the hierarchy. In the case
diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc
index 5e83769c6aa9..c56ec99d7b2f 100644
--- a/Documentation/scsi/ChangeLog.lpfc
+++ b/Documentation/scsi/ChangeLog.lpfc
@@ -352,7 +352,7 @@ Changes from 20041229 to 20050110
          lpfc_scsiport.c
        * In remote port changes: no longer nulling target->pnode when
          removing from mapped list. Pnode get nulled when the node is
-          freed (after nodev tmo). This bug was causing i/o recieved in
+          freed (after nodev tmo). This bug was causing i/o received in
          the small window while the device was blocked to be errored w/
          did_no_connect. With the fix, it returns host_busy
          (per the pre-remote port changes).
@@ -530,7 +530,7 @@ Changes from 20041018 to 20041123
          coherent mappings.  Note: There are more consistent mappings
          that are using pci_dma_sync calls. Probably these should be
          removed as well.
-        * Modified lpfc_free_scsi_buf to accomodate all three scsi_buf
+        * Modified lpfc_free_scsi_buf to accommodate all three scsi_buf
          free types to alleviate miscellaneous panics with cable pull
          testing.
        * Set hotplug to default 0 and lpfc_target_remove to not remove
@@ -583,7 +583,7 @@ Changes from 20041018 to 20041123
          included more than once.
        * Replaced "set_current_state(TASK_UNINTERRUPTIBLE);
          schedule_timeout(timeout)" with "msleep(timeout)".
-        * Fixnode was loosing starget when rediscovered. We saw messages
+        * Fixnode was losing starget when rediscovered. We saw messages
          like: lpfc 0000:04:02.0: 0:0263 Cannot block scsi target as a
          result.  Moved starget field into struct lpfc_target which is
          referenced from the node.
@@ -604,7 +604,7 @@ Changes from 20041018 to 20041123
        * Make 3 functions static: lpfc_get_hba_sym_node_name,
          lpfc_intr_prep and lpfc_setup_slim_access.  Move lpfc_intr_prep
          and lpfc_setup_slim_access so they're defined before being used.
-        * Remove an unecessary list_del() in lpfc_hbadisc.c.
+        * Remove an unnecessary list_del() in lpfc_hbadisc.c.
        * Set nlp_state before calling lpfc_nlp_list() since this will
          potentially call fc_target_unblock which may cause a race in
          queuecommand by releasing host_lock.
@@ -753,7 +753,7 @@ Changes from 20040908 to 20040920
        * Changed version number to 8.0.12
        * Removed used #defines: DEFAULT_PCI_LATENCY_CLOCKS and
          PCI_LATENCY_VALUE from lpfc_hw.h.
-        * Changes to accomodate rnid.
+        * Changes to accommodate rnid.
        * Fix RSCN handling so RSCN NS queries only effect NPorts found in
          RSCN data.
        * If we rcv a plogi on a NPort queued up for discovery, clear the
@@ -813,7 +813,7 @@ Changes from 20040908 to 20040920
          counter instead, brd_no isn't reused anymore.  Also some tiny
          whitespace cleanups in surrounding code.
        * Reorder functions in lpfc_els.c to remove need for prototypes.
-        * Removed unsed prototypes from lpfc_crtn.h -
+        * Removed unused prototypes from lpfc_crtn.h -
          lpfc_ip_timeout_handler, lpfc_read_pci and lpfc_revoke.
        * Removed some unused prototypes from lpfc_crtn.h -
          lpfc_scsi_hba_reset, lpfc_scsi_issue_inqsn,
@@ -863,7 +863,7 @@ Changes from 20040823 to 20040908
        * Minimal support for SCSI flat space addressing/volume set
          addressing.  Use 16 bits of LUN address so that flat
          addressing/VSA will work.
-        * Changed 2 occurences of if( 1 != f(x)) to if(f(x) != 1)
+        * Changed 2 occurrences of if( 1 != f(x)) to if(f(x) != 1)
        * Drop include of lpfc_cfgparm.h.
        * Reduce stack usage of lpfc_fdmi_cmd in lpfc_ct.c.
        * Add minimum range checking property to /sys write/store
@@ -1449,7 +1449,7 @@ Changes from 20040402 to 20040409
        * Removed lpfc_els_chk_latt from the lpfc_config_post function.
          lpfc_els_chk_latt will enable the link event interrupts when
          flogi is pending which causes two discovery state machines
-          running parallely.
+          running parallelly.
        * Add pci_disable_device to unload path.
        * Move lpfc_sleep_event from lpfc_fcp.c to lpfc_util_ioctl.c
        * Call dma_map_single() & pci_map_single() directly instead of via
@@ -1590,7 +1590,7 @@ Changes from 20040326 to 20040402
          ELX_WRITE_HS ELX_WRITE_HA ELX_WRITE_CA ELX_READ_HC
          ELX_READ_HS ELX_READ_HA ELX_READ_CA ELX_READ_MB ELX_RESET
          ELX_READ_HBA ELX_INSTANCE ELX_LIP.  Also introduced
-          attribute "set" to be used in conjuction with the above
+          attribute "set" to be used in conjunction with the above
          attributes.
        * Removed DLINK, enque and deque declarations now that clock
          doesn't use them anymore
diff --git a/Documentation/scsi/ChangeLog.megaraid b/Documentation/scsi/ChangeLog.megaraid
index 5e07d320817d..d2052fdbedd2 100644
--- a/Documentation/scsi/ChangeLog.megaraid
+++ b/Documentation/scsi/ChangeLog.megaraid
@@ -168,7 +168,7 @@ Older Version	: 2.20.4.6 (scsi module), 2.20.2.6 (cmm module)
 1.      Sorted out PCI IDs to remove megaraid support overlaps.
        Based on the patch from Daniel, sorted out PCI IDs along with
-        charactor node name change from 'megadev' to 'megadev_legacy' to avoid
+        character node name change from 'megadev' to 'megadev_legacy' to avoid
        conflict.
        ---
        Hopefully we'll be getting the build restriction zapped much sooner, 
diff --git a/Documentation/scsi/ChangeLog.ncr53c8xx b/Documentation/scsi/ChangeLog.ncr53c8xx
index 8b278c10edfd..9288e3d8974a 100644
--- a/Documentation/scsi/ChangeLog.ncr53c8xx
+++ b/Documentation/scsi/ChangeLog.ncr53c8xx
@@ -200,7 +200,7 @@ Sun Feb  14:00 1999 Gerard Roudier (groudier@club-internet.fr)
          By default the driver uses both IRQF_SHARED and IRQF_DISABLED.
          Option 'ncr53c8xx=irqm:0x20' may be used when an IRQ is shared by 
          a 53C8XX adapter and a network board.
-        - Tiny mispelling fixed (ABORT instead of ABRT). Was fortunately 
+        - Tiny misspelling fixed (ABORT instead of ABRT). Was fortunately 
          harmless.
        - Negotiate SYNC data transfers with CCS devices.
diff --git a/Documentation/scsi/ChangeLog.sym53c8xx b/Documentation/scsi/ChangeLog.sym53c8xx
index 02ffbc1e8a84..c1933707d0bc 100644
--- a/Documentation/scsi/ChangeLog.sym53c8xx
+++ b/Documentation/scsi/ChangeLog.sym53c8xx
@@ -457,7 +457,7 @@ Fri Jan  1  20:00 1999 Gerard Roudier (groudier@club-internet.fr)
 Sat Dec 19  21:00 1998 Gerard Roudier (groudier@club-internet.fr)
        * version sym53c8xx-1.0
        - Define some new IO registers for the 896 (istat1, mbox0, mbox1)
-        - Revamp slighly the Symbios NVRAM lay-out based on the excerpt of 
+        - Revamp slightly the Symbios NVRAM lay-out based on the excerpt of 
          the header file I received from Symbios.
        - Check the PCI bus number for the boot order (Using a fast 
          PCI controller behing a PCI-PCI bridge seems sub-optimal).
diff --git a/Documentation/scsi/aha152x.txt b/Documentation/scsi/aha152x.txt
index 29ce6d87e451..94848734ac66 100644
--- a/Documentation/scsi/aha152x.txt
+++ b/Documentation/scsi/aha152x.txt
@@ -124,7 +124,7 @@ in the partition table and therefore every operating system has to know
 the right geometry to be able to interpret it.
 Moreover there are certain limitations to the C/H/S addressing scheme,
-namely the address space is limited to upto 255 heads, upto 63 sectors
+namely the address space is limited to up to 255 heads, up to 63 sectors
 and a maximum of 1023 cylinders.
 The AHA-1522 BIOS calculates the geometry by fixing the number of heads
diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt
index 16e054c9c70b..64ac7093c872 100644
--- a/Documentation/scsi/aic79xx.txt
+++ b/Documentation/scsi/aic79xx.txt
@@ -267,7 +267,7 @@ The following information is available in this file:
              Option: tag_info:{{value[,value...]}[,{value[,value...]}...]}
          Definition: Set the per-target tagged queue depth on a
                      per controller basis.  Both controllers and targets
-                      may be ommitted indicating that they should retain
+                      may be omitted indicating that they should retain
                      the default tag depth.
            Examples: tag_info:{{16,32,32,64,8,8,,32,32,32,32,32,32,32,32,32}
                        On Controller 0
@@ -291,7 +291,7 @@ The following information is available in this file:
                      The rd_strm_bitmask is a 16 bit hex value in which
                      each bit represents a target.  Setting the target's
                      bit to '1' enables read streaming for that
-                      target.  Controllers may be ommitted indicating that
+                      target.  Controllers may be omitted indicating that
                      they should retain the default read streaming setting.
             Example: rd_strm:{0x0041}
                        On Controller 0
@@ -313,7 +313,7 @@ The following information is available in this file:
   -----------------------------------------------------------------
              Option: dv: {value[,value...]}
          Definition: Set Domain Validation Policy on a per-controller basis.
-                      Controllers may be ommitted indicating that
+                      Controllers may be omitted indicating that
                      they should retain the default read streaming setting.
             Example: dv:{-1,0,,1,1,0}
                        On Controller 0 leave DV at its default setting.
@@ -340,7 +340,7 @@ The following information is available in this file:
              Option: precomp: {value[,value...]}
          Definition: Set IO Cell precompensation value on a per-controller
                      basis.
-                      Controllers may be ommitted indicating that
+                      Controllers may be omitted indicating that
                      they should retain the default precompensation setting.
             Example: precomp:{0x1}
                        On Controller 0 set precompensation to 1.
@@ -353,7 +353,7 @@ The following information is available in this file:
   -----------------------------------------------------------------
              Option: slewrate: {value[,value...]}
          Definition: Set IO Cell slew rate on a per-controller basis.
-                      Controllers may be ommitted indicating that
+                      Controllers may be omitted indicating that
                      they should retain the default slew rate setting.
             Example: slewrate:{0x1}
                        On Controller 0 set slew rate to 1.
@@ -366,7 +366,7 @@ The following information is available in this file:
   -----------------------------------------------------------------
              Option: amplitude: {value[,value...]}
          Definition: Set IO Cell signal amplitude on a per-controller basis.
-                      Controllers may be ommitted indicating that
+                      Controllers may be omitted indicating that
                      they should retain the default read streaming setting.
             Example: amplitude:{0x1}
                        On Controller 0 set amplitude to 1.
diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt
index 45d61ad8c6f7..ac41a9fcac77 100644
--- a/Documentation/scsi/ibmmca.txt
+++ b/Documentation/scsi/ibmmca.txt
@@ -303,7 +303,7 @@
   (scb) and calls a local function issue_cmd(), which writes a scb 
   command into subsystem I/O ports. Once the scb command is carried out, 
   the interrupt_handler() is invoked. If a device is determined to be 
-   existant and it has not assigned any ldn, it gets one dynamically.
+   existent and it has not assigned any ldn, it gets one dynamically.
   For this, the whole stuff is done in ibmmca_queuecommand().
   2.6 Abort & Reset Commands
@@ -741,7 +741,7 @@
      some error appeared, else it is undefined. Now, this is fixed. Before
      any SCB command gets queued, the tsb.dev_status is set to 0, so the 
      cmd->result won't screw up Linux higher level drivers.
-   2) The reset-function has slightly improved. This is still planed for 
+   2) The reset-function has slightly improved. This is still planned for 
      abort. During the abort and the reset function, no interrupts are 
      allowed. This is however quite hard to cope with, so the INT-status
      register is read. When the interrupt gets queued, one can find its
diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt
index 032399b16a53..ade046ea7c17 100644
--- a/Documentation/scsi/scsi-changer.txt
+++ b/Documentation/scsi/scsi-changer.txt
@@ -102,7 +102,7 @@ Trouble?
 If you insmod the driver with "insmod debug=1", it will be verbose and
 prints a lot of stuff to the syslog.  Compiling the kernel with
-CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages alot
+CONFIG_SCSI_CONSTANTS=y improves the quality of the error messages a lot
 because the kernel will translate the error codes into human-readable
 strings then.
diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt
index 7acbebb17fa6..6ff16b620d84 100644
--- a/Documentation/scsi/scsi_eh.txt
+++ b/Documentation/scsi/scsi_eh.txt
@@ -290,7 +290,7 @@ scmd->allowed.
        SCSI transports/LLDDs automatically acquire sense data on
        command failures (autosense).  Autosense is recommended for
        performance reasons and as sense information could get out of
-        sync inbetween occurrence of CHECK CONDITION and this action.
+        sync between occurrence of CHECK CONDITION and this action.
        Note that if autosense is not supported, scmd->sense_buffer
        contains invalid sense data when error-completing the scmd
diff --git a/Documentation/scsi/scsi_fc_transport.txt b/Documentation/scsi/scsi_fc_transport.txt
index e00192de4d1c..f79282fc48d7 100644
--- a/Documentation/scsi/scsi_fc_transport.txt
+++ b/Documentation/scsi/scsi_fc_transport.txt
@@ -291,7 +291,7 @@ Transport <-> LLDD Interfaces :
 Vport support by LLDD:
  The LLDD indicates support for vports by supplying a vport_create()
-  function in the transport template.  The presense of this function will
+  function in the transport template.  The presence of this function will
  cause the creation of the new attributes on the fc_host.  As part of
  the physical port completing its initialization relative to the
  transport, it should set the max_npiv_vports attribute to indicate the
diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt
index 6f63b7989679..6af8f7a7770f 100644
--- a/Documentation/scsi/sym53c8xx_2.txt
+++ b/Documentation/scsi/sym53c8xx_2.txt
@@ -285,7 +285,7 @@ from the driver.
 7. Profiling information
-This driver does not provide profiling informations as did its predecessors.
+This driver does not provide profiling information as did its predecessors.
 This feature was not this useful and added complexity to the code. 
 As the driver code got more complex, I have decided to remove everything 
 that didn't seem actually useful.
diff --git a/Documentation/serial/moxa-smartio b/Documentation/serial/moxa-smartio
index d10443918684..5d2a33be0bd8 100644
--- a/Documentation/serial/moxa-smartio
+++ b/Documentation/serial/moxa-smartio
@@ -473,7 +473,7 @@ Content
   spd_normal     Use  38.4kb  when  the application requests 38.4kb.
   spd_cust       Use  the custom divisor to set the speed when  the
                  application requests 38.4kb.
-   divisor        This option set the custom divison.
+   divisor        This option set the custom division.
   baud_base      This option set the base baud rate.
 -----------------------------------------------------------------------------
diff --git a/Documentation/serial/n_gsm.txt b/Documentation/serial/n_gsm.txt
index 397f41a1f153..a5d91126a8f7 100644
--- a/Documentation/serial/n_gsm.txt
+++ b/Documentation/serial/n_gsm.txt
@@ -34,7 +34,7 @@ Major parts of the initialization program :
        /* configure the serial port : speed, flow control ... */
        /* send the AT commands to switch the modem to CMUX mode
-           and check that it's succesful (should return OK) */
+           and check that it's successful (should return OK) */
        write(fd, "AT+CMUX=0\r", 10);
        /* experience showed that some modems need some time before
diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt
index 3c1eddd9fcc7..9822afb6313c 100644
--- a/Documentation/sound/alsa/ALSA-Configuration.txt
+++ b/Documentation/sound/alsa/ALSA-Configuration.txt
@@ -322,7 +322,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
    "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
    or the value stored in the card's EEPROM for cards that have an EEPROM and
    their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
-    be choosen freely from the options enumerated above.
+    be chosen freely from the options enumerated above.
    If dma2 is specified and different from dma1, the card will operate in
    full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
@@ -356,7 +356,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed.
    "port" needs to match the BASE ADDRESS jumper on the card (0x220 or 0x240)
    or the value stored in the card's EEPROM for cards that have an EEPROM and
    their "CONFIG MODE" jumper set to "EEPROM SETTING". The other values can
-    be choosen freely from the options enumerated above.
+    be chosen freely from the options enumerated above.
    If dma2 is specified and different from dma1, the card will operate in
    full-duplex mode. When dma1=3, only dma2=0 is valid and the only way to
@@ -2229,7 +2229,7 @@ Proc interfaces (/proc/asound)
 /proc/asound/card#/pcm#[cp]/oss
 -------------------------------
-  String "erase" - erase all additional informations about OSS applications
+  String "erase" - erase all additional information about OSS applications
  String "<app_name> <fragments> <fragment_size> [<options>]"
   <app_name> - name of application with (higher priority) or without path
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='Synth Capture Volume',index=0
-name='Music Capture Switch',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/sound/oss/AudioExcelDSP16 b/Documentation/sound/oss/AudioExcelDSP16
index c0f08922993b..e0dc0641b480 100644
--- a/Documentation/sound/oss/AudioExcelDSP16
+++ b/Documentation/sound/oss/AudioExcelDSP16
@@ -1,10 +1,10 @@
 Driver
 ------
-Informations about Audio Excel DSP 16 driver can be found in the source
+Information about Audio Excel DSP 16 driver can be found in the source
 file aedsp16.c
 Please, read the head of the source before using it. It contain useful
-informations.
+information.
 Configuration
 -------------
@@ -68,7 +68,7 @@ Sound cards supported
 This driver supports the SC-6000 and SC-6600 based Gallant's sound card.
 It don't support the Audio Excel DSP 16 III (try the SC-6600 code).
 I'm working on the III version of the card: if someone have useful
-informations about it, please let me know.
+information about it, please let me know.
 For all the non-supported audio cards, you have to boot MS-DOS (or WIN95)
 activating the audio card with the MS-DOS device driver, then you have to
 <ctrl>-<alt>-<del> and boot Linux.
diff --git a/Documentation/sound/oss/README.OSS b/Documentation/sound/oss/README.OSS
index c615debbf08d..4be259428a1c 100644
--- a/Documentation/sound/oss/README.OSS
+++ b/Documentation/sound/oss/README.OSS
@@ -1352,7 +1352,7 @@ OSS-mixer.
 The PCM20 contains a radio tuner, which is also controlled by
 ACI. This radio tuner is supported by the ACI driver together with the
 miropcm20.o module. Also the 7-band equalizer is integrated
-(limited by the OSS-design). Developement has started and maybe
+(limited by the OSS-design). Development has started and maybe
 finished for the RDS decoder on this card, too. You will be able to
 read RadioText, the Programme Service name, Programme TYpe and
 others. Even the v4l radio module benefits from it with a refined
diff --git a/Documentation/sound/oss/README.ymfsb b/Documentation/sound/oss/README.ymfsb
index af8a7d3a4e8e..b6b77906b58d 100644
--- a/Documentation/sound/oss/README.ymfsb
+++ b/Documentation/sound/oss/README.ymfsb
@@ -5,7 +5,7 @@ FIRST OF ALL
 ============
  This code references YAMAHA's sample codes and data sheets.
-  I respect and thank for all people they made open the informations
+  I respect and thank for all people they made open the information
  about YMF7xx cards.
  And this codes heavily based on Jeff Garzik <jgarzik@pobox.com>'s
diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx
index 68a4fe3818a1..493dada57372 100644
--- a/Documentation/spi/pxa2xx
+++ b/Documentation/spi/pxa2xx
@@ -143,7 +143,7 @@ configured to use SSPFRM instead.
 NOTE: the SPI driver cannot control the chip select if SSPFRM is used, so the
 chipselect is dropped after each spi_transfer.  Most devices need chip select
 asserted around the complete message.  Use SSPFRM as a GPIO (through cs_control)
-to accomodate these chips.
+to accommodate these chips.
 NSSP SLAVE SAMPLE
diff --git a/Documentation/spi/spi-lm70llp b/Documentation/spi/spi-lm70llp
index 34a9cfd746bd..463f6d01fa15 100644
--- a/Documentation/spi/spi-lm70llp
+++ b/Documentation/spi/spi-lm70llp
@@ -46,7 +46,7 @@ The hardware interfacing on the LM70 LLP eval board is as follows:
 Note that since the LM70 uses a "3-wire" variant of SPI, the SI/SO pin
 is connected to both pin D7 (as Master Out) and Select (as Master In)
-using an arrangment that lets either the parport or the LM70 pull the
+using an arrangement that lets either the parport or the LM70 pull the
 pin low.  This can't be shared with true SPI devices, but other 3-wire
 devices might share the same SI/SO pin.
diff --git a/Documentation/telephony/ixj.txt b/Documentation/telephony/ixj.txt
index 4fb314d51702..db94fb6c5678 100644
--- a/Documentation/telephony/ixj.txt
+++ b/Documentation/telephony/ixj.txt
@@ -51,7 +51,7 @@ be removed to protect the rights of others.
 Specifically, very old Internet PhoneJACK cards have non-standard
 G.723.1 codecs (due to the early nature of the DSPs in those days).
 The auto-conversion code to bring those cards into compliance with
-todays standards is available as a binary only module to those people
+today's standards is available as a binary only module to those people
 needing it.  If you bought your card after 1997 or so, you are OK -
 it's only the very old cards that are affected.
diff --git a/Documentation/trace/ring-buffer-design.txt b/Documentation/trace/ring-buffer-design.txt
index d299ff31df57..7d350b496585 100644
--- a/Documentation/trace/ring-buffer-design.txt
+++ b/Documentation/trace/ring-buffer-design.txt
@@ -237,7 +237,7 @@ with the previous write.
      |written  |
      +---------+
      |written  |
-      +---------+  <--- next positon for write (current commit)
+      +---------+  <--- next position for write (current commit)
      | empty   |
      +---------+
diff --git a/Documentation/video4linux/README.pvrusb2 b/Documentation/video4linux/README.pvrusb2
index a747200fe67c..2137b589276b 100644
--- a/Documentation/video4linux/README.pvrusb2
+++ b/Documentation/video4linux/README.pvrusb2
@@ -172,7 +172,7 @@ Source file list / functional overview:
    to provide a streaming API usable by a read() system call style of
    I/O.  Right now this is the only layer on top of pvrusb2-io.[ch],
    however the underlying architecture here was intended to allow for
-    other styles of I/O to be implemented with additonal modules, like
+    other styles of I/O to be implemented with additional modules, like
    mmap()'ed buffers or something even more exotic.
  pvrusb2-main.c - This is the top level of the driver.  Module level
diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options
index bbe3ed667d91..14c065fa23ef 100644
--- a/Documentation/video4linux/bttv/Insmod-options
+++ b/Documentation/video4linux/bttv/Insmod-options
@@ -1,5 +1,5 @@
-Note: "modinfo <module>" prints various informations about a kernel
+Note: "modinfo <module>" prints various information about a kernel
 module, among them a complete and up-to-date list of insmod options.
 This list tends to be outdated because it is updated manually ...
diff --git a/Documentation/video4linux/bttv/README b/Documentation/video4linux/bttv/README
index 3a367cdb664e..7cbf4fb6cf31 100644
--- a/Documentation/video4linux/bttv/README
+++ b/Documentation/video4linux/bttv/README
@@ -70,7 +70,7 @@ If you have trouble with some specific TV card, try to ask there
 instead of mailing me directly.  The chance that someone with the
 same card listens there is much higher...
-For problems with sound:  There are alot of different systems used
+For problems with sound:  There are a lot of different systems used
 for TV sound all over the world.  And there are also different chips
 which decode the audio signal.  Reports about sound problems ("stereo
 does'nt work") are pretty useless unless you include some details
diff --git a/Documentation/video4linux/bttv/README.freeze b/Documentation/video4linux/bttv/README.freeze
index 4259dccc8287..5eddfa076cfb 100644
--- a/Documentation/video4linux/bttv/README.freeze
+++ b/Documentation/video4linux/bttv/README.freeze
@@ -33,7 +33,7 @@ state is stuck.
 I've seen reports that bttv 0.7.x crashes whereas 0.8.x works rock solid
 for some people.  Thus probably a small buglet left somewhere in bttv
-0.7.x.  I have no idea where exactly, it works stable for me and alot of
+0.7.x.  I have no idea where exactly, it works stable for me and a lot of
 other people.  But in case you have problems with the 0.7.x versions you
 can give 0.8.x a try ...
diff --git a/Documentation/video4linux/bttv/Sound-FAQ b/Documentation/video4linux/bttv/Sound-FAQ
index 1e6328f91083..395f6c6fdd98 100644
--- a/Documentation/video4linux/bttv/Sound-FAQ
+++ b/Documentation/video4linux/bttv/Sound-FAQ
@@ -2,13 +2,13 @@
 bttv and sound mini howto
 =========================
-There are alot of different bt848/849/878/879 based boards available.
+There are a lot of different bt848/849/878/879 based boards available.
 Making video work often is not a big deal, because this is handled
 completely by the bt8xx chip, which is common on all boards.  But
 sound is handled in slightly different ways on each board.
 To handle the grabber boards correctly, there is a array tvcards[] in
-bttv-cards.c, which holds the informations required for each board.
+bttv-cards.c, which holds the information required for each board.
 Sound will work only, if the correct entry is used (for video it often
 makes no difference).  The bttv driver prints a line to the kernel
 log, telling which card type is used.  Like this one:
diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt
index 1247566c4de3..e0cdae491858 100644
--- a/Documentation/video4linux/et61x251.txt
+++ b/Documentation/video4linux/et61x251.txt
@@ -191,10 +191,10 @@ Syntax:         <n>
 Description:    Debugging information level, from 0 to 3:
                0 = none (use carefully)
                1 = critical errors
-                2 = significant informations
+                2 = significant information
                3 = more verbose messages
                Level 3 is useful for testing only, when only one device
-                is used at the same time. It also shows some more informations
+                is used at the same time. It also shows some more information
                about the hardware being detected. This module parameter can be
                changed at runtime thanks to the /sys filesystem interface.
 Default:        2
diff --git a/Documentation/video4linux/pxa_camera.txt b/Documentation/video4linux/pxa_camera.txt
index 4f6d0ca01956..51ed1578b0e8 100644
--- a/Documentation/video4linux/pxa_camera.txt
+++ b/Documentation/video4linux/pxa_camera.txt
@@ -84,12 +84,12 @@ DMA usage
       transfer is not started. On "End Of Frame" interrupt, the irq handler
       starts the DMA chain.
     - capture of one videobuffer
-       The DMA chain starts transfering data into videobuffer RAM pages.
+       The DMA chain starts transferring data into videobuffer RAM pages.
-       When all pages are transfered, the DMA irq is raised on "ENDINTR" status
+       When all pages are transferred, the DMA irq is raised on "ENDINTR" status
     - finishing one videobuffer
       The DMA irq handler marks the videobuffer as "done", and removes it from
       the active running queue
-       Meanwhile, the next videobuffer (if there is one), is transfered by DMA
+       Meanwhile, the next videobuffer (if there is one), is transferred by DMA
     - finishing the last videobuffer
       On the DMA irq of the last videobuffer, the QCI is stopped.
@@ -101,7 +101,7 @@ DMA usage
     This structure is pointed by dma->sg_cpu.
     The descriptors are used as follows :
-      - desc-sg[i]: i-th descriptor, transfering the i-th sg
+      - desc-sg[i]: i-th descriptor, transferring the i-th sg
        element to the video buffer scatter gather
      - finisher: has ddadr=DADDR_STOP, dcmd=ENDIRQEN
      - linker: has ddadr= desc-sg[0] of next video buffer, dcmd=0
diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt
index 73de4050d637..b4f67040403a 100644
--- a/Documentation/video4linux/sn9c102.txt
+++ b/Documentation/video4linux/sn9c102.txt
@@ -214,10 +214,10 @@ Syntax:         <n>
 Description:    Debugging information level, from 0 to 3:
                0 = none (use carefully)
                1 = critical errors
-                2 = significant informations
+                2 = significant information
                3 = more verbose messages
                Level 3 is useful for testing only. It also shows some more
-                informations about the hardware being detected.
+                information about the hardware being detected.
                This parameter can be changed at runtime thanks to the /sys
                filesystem interface.
 Default:        2
diff --git a/Documentation/video4linux/v4l2-framework.txt b/Documentation/video4linux/v4l2-framework.txt
index 3b15608ee070..cf21f7aae976 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -343,7 +343,7 @@ ignored. If you want to check for errors use this:
        err = v4l2_device_call_until_err(v4l2_dev, 0, core, g_chip_ident, &chip);
 Any error except -ENOIOCTLCMD will exit the loop with that error. If no
-errors (except -ENOIOCTLCMD) occured, then 0 is returned.
+errors (except -ENOIOCTLCMD) occurred, then 0 is returned.
 The second argument to both calls is a group ID. If 0, then all subdevs are
 called. If non-zero, then only those whose group ID match that value will
diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt
index 05138e8aea07..9649450f3b90 100644
--- a/Documentation/video4linux/w9968cf.txt
+++ b/Documentation/video4linux/w9968cf.txt
@@ -413,7 +413,7 @@ Syntax:         <n>
 Description:    Debugging information level, from 0 to 6:
                0 = none (use carefully)
                1 = critical errors
-                2 = significant informations
+                2 = significant information
                3 = configuration or general messages
                4 = warnings
                5 = called functions
diff --git a/Documentation/video4linux/zc0301.txt b/Documentation/video4linux/zc0301.txt
index befdfdacdc5b..b41c83cf09f4 100644
--- a/Documentation/video4linux/zc0301.txt
+++ b/Documentation/video4linux/zc0301.txt
@@ -181,10 +181,10 @@ Syntax:         <n>
 Description:    Debugging information level, from 0 to 3:
                0 = none (use carefully)
                1 = critical errors
-                2 = significant informations
+                2 = significant information
                3 = more verbose messages
                Level 3 is useful for testing only, when only one device
-                is used at the same time. It also shows some more informations
+                is used at the same time. It also shows some information
                about the hardware being detected. This module parameter can be
                changed at runtime thanks to the /sys filesystem interface.
 Default:        2
@@ -261,7 +261,7 @@ the fingerprint is: '88E8 F32F 7244 68BA 3958  5D40 99DA 5D2A FCE6 35A4'.
 11. Credits
 ===========
- Informations about the chip internals needed to enable the I2C protocol have
+- Information about the chip internals needed to enable the I2C protocol have
  been taken from the documentation of the ZC030x Video4Linux1 driver written
  by Andrew Birkett <andy@nobugs.org>;
 - The initialization values of the ZC0301 controller connected to the PAS202BCB
diff --git a/Documentation/vm/active_mm.txt b/Documentation/vm/active_mm.txt
index 4ee1f643d897..dbf45817405f 100644
--- a/Documentation/vm/active_mm.txt
+++ b/Documentation/vm/active_mm.txt
@@ -74,7 +74,7 @@ we have a user context", and is generally done by the page fault handler
 and things like that).
 Anyway, I put a pre-patch-2.3.13-1 on ftp.kernel.org just a moment ago,
-because it slightly changes the interfaces to accomodate the alpha (who
+because it slightly changes the interfaces to accommodate the alpha (who
 would have thought it, but the alpha actually ends up having one of the
 ugliest context switch codes - unlike the other architectures where the MM
 and register state is separate, the alpha PALcode joins the two, and you
diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index 457634c1e03e..f8551b3879f8 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -72,7 +72,7 @@ number of huge pages requested.  This is the most reliable method of
 allocating huge pages as memory has not yet become fragmented.
 Some platforms support multiple huge page sizes.  To allocate huge pages
-of a specific size, one must preceed the huge pages boot command parameters
+of a specific size, one must precede the huge pages boot command parameters
 with a huge page size selection parameter "hugepagesz=<size>".  <size> must
 be specified in bytes with optional scale suffix [kKmMgG].  The default huge
 page size may be selected with the "default_hugepagesz=<size>" boot parameter.
diff --git a/Documentation/vm/overcommit-accounting b/Documentation/vm/overcommit-accounting
index 21c7b1f8f32b..706d7ed9d8d2 100644
--- a/Documentation/vm/overcommit-accounting
+++ b/Documentation/vm/overcommit-accounting
@@ -4,7 +4,7 @@ The Linux kernel supports the following overcommit handling modes
                address space are refused. Used for a typical system. It
                ensures a seriously wild allocation fails while allowing
                overcommit to reduce swap usage.  root is allowed to 
-                allocate slighly more memory in this mode. This is the 
+                allocate slightly more memory in this mode. This is the 
                default.
 1       -       Always overcommit. Appropriate for some scientific
diff --git a/Documentation/w1/slaves/w1_ds2423 b/Documentation/w1/slaves/w1_ds2423
index 90a65d23cf59..3f98b505a0ee 100644
--- a/Documentation/w1/slaves/w1_ds2423
+++ b/Documentation/w1/slaves/w1_ds2423
@@ -21,8 +21,8 @@ value and associated ram buffer is outpputed to own line.
 Each lines will contain the values of 42 bytes read from the counter and
 memory page along the crc=YES or NO for indicating whether the read operation
-was successfull and CRC matched.
+was successful and CRC matched.
-If the operation was successfull, there is also in the end of each line
+If the operation was successful, there is also in the end of each line
 a counter value expressed as an integer after c=
 Meaning of 42 bytes represented is following:
@@ -34,7 +34,7 @@ Meaning of 42 bytes represented is following:
 - crc=YES/NO indicating whether read was ok and crc matched
 - c=<int> current counter value
-example from the successfull read:
+example from the successful read:
 00 02 00 00 00 00 00 00 00 6d 38 00 ff ff 00 00 fe ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
 00 02 00 00 00 00 00 00 00 e0 1f 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=2
 00 29 c6 5d 18 00 00 00 00 04 37 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff 00 00 ff ff crc=YES c=408798761
diff --git a/Documentation/w1/w1.netlink b/Documentation/w1/w1.netlink
index 804445f745ed..f59a31965d50 100644
--- a/Documentation/w1/w1.netlink
+++ b/Documentation/w1/w1.netlink
@@ -81,7 +81,7 @@ which will contain list of all registered master ids in the following
 format:
        cn_msg (CN_W1_IDX.CN_W1_VAL as id, len is equal to sizeof(struct
-        w1_netlink_msg) plus number of masters multipled by 4)
+        w1_netlink_msg) plus number of masters multiplied by 4)
        w1_netlink_msg (type: W1_LIST_MASTERS, len is equal to
                number of masters multiplied by 4 (u32 size))
        id0 ... idN
diff --git a/Documentation/watchdog/hpwdt.txt b/Documentation/watchdog/hpwdt.txt
index 9c24d5ffbb06..9488078900e0 100644
--- a/Documentation/watchdog/hpwdt.txt
+++ b/Documentation/watchdog/hpwdt.txt
@@ -8,7 +8,7 @@ Last reviewed: 06/02/2009
 The HP iLO2 NMI Watchdog driver is a kernel module that provides basic
 watchdog functionality and the added benefit of NMI sourcing. Both the
 watchdog functionality and the NMI sourcing capability need to be enabled
- by the user. Remember that the two modes are not dependant on one another.
+ by the user. Remember that the two modes are not dependent on one another.
 A user can have the NMI sourcing without the watchdog timer and vice-versa.
 Watchdog functionality is enabled like any other common watchdog driver. That