All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Linux PM list <linux-pm@vger.kernel.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Randy Dunlap <rdunlap@xenotime.net>
Subject: [PATCH 2/3] PM / Sleep: Correct inaccurate information in devices.txt
Date: Sun, 20 Nov 2011 01:56:01 +0100	[thread overview]
Message-ID: <201111200156.02161.rjw@sisk.pl> (raw)
In-Reply-To: <201111200153.40224.rjw@sisk.pl>

From: Rafael J. Wysocki <rjw@sisk.pl>

The documentation file Documentation/power/devices.txt contains some
information that isn't correct any more due to code modifications
made after that file had been created (or updated last time).  Fix
this.

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
---
 Documentation/power/devices.txt |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)

Index: linux/Documentation/power/devices.txt
===================================================================
--- linux.orig/Documentation/power/devices.txt
+++ linux/Documentation/power/devices.txt
@@ -250,7 +250,7 @@ for every device before the next phase b
 support all these callbacks and not all drivers use all the callbacks.  The
 various phases always run after tasks have been frozen and before they are
 unfrozen.  Furthermore, the *_noirq phases run at a time when IRQ handlers have
-been disabled (except for those marked with the IRQ_WAKEUP flag).
+been disabled (except for those marked with the IRQF_NO_SUSPEND flag).
 
 All phases use PM domain, bus, type, or class callbacks (that is, methods
 defined in dev->pm_domain->ops, dev->bus->pm, dev->type->pm, or dev->class->pm).
@@ -295,9 +295,8 @@ When the system goes into the standby or
 
 	After the prepare callback method returns, no new children may be
 	registered below the device.  The method may also prepare the device or
-	driver in some way for the upcoming system power transition (for
-	example, by allocating additional memory required for this purpose), but
-	it should not put the device into a low-power state.
+	driver in some way for the upcoming system power transition, but it
+	should not put the device into a low-power state.
 
     2.	The suspend methods should quiesce the device to stop it from performing
 	I/O.  They also may save the device registers and put it into the


  parent reply	other threads:[~2011-11-20  0:55 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-20  0:53 [PATCH 0/3] PM: Documentation updates Rafael J. Wysocki
2011-11-20  0:54 ` [PATCH 1/3] PM / Domains: Document how PM domains are used by the PM core Rafael J. Wysocki
2011-11-20  0:56 ` Rafael J. Wysocki [this message]
2011-11-20  0:56 ` [PATCH 3/3] PM / Runtime: Make documentation follow the new behavior of irq_safe Rafael J. Wysocki
2011-11-20 10:13 ` [PATCH 4] Rafael J. Wysocki
2011-11-20 23:38 ` [PATCH 5] PM: Update comments describing device power management callbacks Rafael J. Wysocki
2011-11-21  2:56   ` Alan Stern
2011-11-21 20:02     ` Rafael J. Wysocki
2011-11-21 21:03       ` Alan Stern
2011-11-21 21:23         ` Rafael J. Wysocki
2011-11-21 21:49           ` Alan Stern
2011-11-21 21:57             ` Rafael J. Wysocki
2011-11-21 22:23               ` Alan Stern
2011-11-21 22:33                 ` Rafael J. Wysocki
2011-11-22 15:57                   ` Alan Stern
2011-11-22 20:47                     ` Rafael J. Wysocki
2011-11-22 21:02                       ` Alan Stern
2011-11-22 23:40                         ` Rafael J. Wysocki
2011-11-23 16:28                           ` Alan Stern
2011-11-23 20:01                             ` Rafael J. Wysocki
2011-11-22  3:36   ` Ming Lei
2011-11-22 20:41     ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201111200156.02161.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rdunlap@xenotime.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.