Fix common misspellings

Fixes generated by 'codespell' and manually reviewed.

Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>

5 files changed, 9 insertions, 9 deletions

diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index f023ba6bba6..1971bcf48a6 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 ae1b7ec0768..cf980709122 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 cd445582d1f..5ae70a12c1e 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 ea718891a66..ac190cf1963 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 81680f9f590..1101bee4e82 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.