5 files changed, 9 insertions, 9 deletions

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.