summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorViresh Kumar <viresh.kumar@st.com>2012-01-19 23:22:49 +0100
committerRafael J. Wysocki <rjw@sisk.pl>2012-01-19 23:22:49 +0100
commit5eb6f9ad96967be4e0da55521a253e11b534bd3f (patch)
treee9c71b8e87a0db0d2b2f5eebb25a8dadde04063d
parentf581b63aa1049ac030d6eb6c24e1be1ce2072ae7 (diff)
downloadlinux-3.10-5eb6f9ad96967be4e0da55521a253e11b534bd3f.tar.gz
linux-3.10-5eb6f9ad96967be4e0da55521a253e11b534bd3f.tar.bz2
linux-3.10-5eb6f9ad96967be4e0da55521a253e11b534bd3f.zip
PM / Documentation: Fix minor issue in freezing_of_tasks.txt
In a paragraph, "kernel thread" is mistakenly written as "kernel". Fix this by adding thread after word "kernel". Changes are shown in multiple lines, as they are realigned to 80 col width. Signed-off-by: Viresh Kumar <viresh.kumar@st.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
-rw-r--r--Documentation/power/freezing-of-tasks.txt8
1 files changed, 4 insertions, 4 deletions
diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt
index 6ccb68f68da..ebd7490ef1d 100644
--- a/Documentation/power/freezing-of-tasks.txt
+++ b/Documentation/power/freezing-of-tasks.txt
@@ -120,10 +120,10 @@ So in practice, the 'at all' may become a 'why freeze kernel threads?' and
freezing user threads I don't find really objectionable."
Still, there are kernel threads that may want to be freezable. For example, if
-a kernel that belongs to a device driver accesses the device directly, it in
-principle needs to know when the device is suspended, so that it doesn't try to
-access it at that time. However, if the kernel thread is freezable, it will be
-frozen before the driver's .suspend() callback is executed and it will be
+a kernel thread that belongs to a device driver accesses the device directly, it
+in principle needs to know when the device is suspended, so that it doesn't try
+to access it at that time. However, if the kernel thread is freezable, it will
+be frozen before the driver's .suspend() callback is executed and it will be
thawed after the driver's .resume() callback has run, so it won't be accessing
the device while it's suspended.