From 91a55b13d6dc09293cc7745c823eef0553d1c4dd Mon Sep 17 00:00:00 2001 From: Viresh Kumar Date: Thu, 19 Jan 2012 23:22:49 +0100 Subject: [PATCH] --- yaml --- r: 286629 b: refs/heads/master c: 5eb6f9ad96967be4e0da55521a253e11b534bd3f h: refs/heads/master i: 286627: 2ba2d4f9f059926763e11115c0278b525ba8f081 v: v3 --- [refs] | 2 +- trunk/Documentation/power/freezing-of-tasks.txt | 8 ++++---- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/[refs] b/[refs] index d727503cd492..ed26a51a9508 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: f581b63aa1049ac030d6eb6c24e1be1ce2072ae7 +refs/heads/master: 5eb6f9ad96967be4e0da55521a253e11b534bd3f diff --git a/trunk/Documentation/power/freezing-of-tasks.txt b/trunk/Documentation/power/freezing-of-tasks.txt index 6ccb68f68da6..ebd7490ef1df 100644 --- a/trunk/Documentation/power/freezing-of-tasks.txt +++ b/trunk/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.