dect
/
linux-2.6
Archived
13
0
Fork 0
Code Releases Activity

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>
This commit is contained in:
Viresh Kumar 2012-01-19 23:22:49 +01:00 committed by Rafael J. Wysocki
parent f581b63aa1
commit 5eb6f9ad96
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
Documentation/power/freezing-of-tasks.txt
View File

@ -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." freezing user threads I don't find really objectionable."
Still, there are kernel threads that may want to be freezable. For example, if 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 a kernel thread that belongs to a device driver accesses the device directly, it
principle needs to know when the device is suspended, so that it doesn't try to in principle needs to know when the device is suspended, so that it doesn't try
access it at that time. However, if the kernel thread is freezable, it will be to access it at that time. However, if the kernel thread is freezable, it will
frozen before the driver's .suspend() callback is executed and it will be 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 thawed after the driver's .resume() callback has run, so it won't be accessing
the device while it's suspended. the device while it's suspended.