summaryrefslogtreecommitdiff
path: root/Documentation/power
diff options
context:
space:
mode:
authorLucas De Marchi <lucas.demarchi@profusion.mobi>2011-03-30 22:57:33 -0300
committerLucas De Marchi <lucas.demarchi@profusion.mobi>2011-03-31 11:26:23 -0300
commit25985edcedea6396277003854657b5f3cb31a628 (patch)
treef026e810210a2ee7290caeb737c23cb6472b7c38 /Documentation/power
parent6aba74f2791287ec407e0f92487a725a25908067 (diff)
Fix common misspellings
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
Diffstat (limited to 'Documentation/power')
-rw-r--r--Documentation/power/devices.txt2
-rw-r--r--Documentation/power/notifiers.txt4
-rw-r--r--Documentation/power/opp.txt2
-rw-r--r--Documentation/power/swsusp.txt4
-rw-r--r--Documentation/power/userland-swsusp.txt6
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.