From: Greg KH <greg@kroah.com>
To: linux-kernel@vger.kernel.org
Cc: David Brownell <david-b@pacbell.net>,
Greg Kroah-Hartman <gregkh@suse.de>
Subject: [PATCH 14/22] [PATCH] remove duplication from Documentation/power/devices.txt
Date: Wed, 21 Jun 2006 12:45:57 -0700 [thread overview]
Message-ID: <11509192081167-git-send-email-greg@kroah.com> (raw)
In-Reply-To: <11509192043044-git-send-email-greg@kroah.com>
From: David Brownell <david-b@pacbell.net>
Remove a chunk of duplicated documentation text.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
---
Documentation/power/devices.txt | 90 ---------------------------------------
1 files changed, 0 insertions(+), 90 deletions(-)
diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt
index f987afe..fba1e05 100644
--- a/Documentation/power/devices.txt
+++ b/Documentation/power/devices.txt
@@ -135,96 +135,6 @@ # NOTIFICATION -- pretty much same as ON
FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from
scratch. That probably means stop accepting upstream requests, the
-actual policy of what to do with them beeing specific to a given
-driver. It's acceptable for a network driver to just drop packets
-while a block driver is expected to block the queue so no request is
-lost. (Use IDE as an example on how to do that). FREEZE requires no
-power state change, and it's expected for drivers to be able to
-quickly transition back to operating state.
-
-SUSPEND -- like FREEZE, but also put hardware into low-power state. If
-there's need to distinguish several levels of sleep, additional flag
-is probably best way to do that.
-
-Transitions are only from a resumed state to a suspended state, never
-between 2 suspended states. (ON -> FREEZE or ON -> SUSPEND can happen,
-FREEZE -> SUSPEND or SUSPEND -> FREEZE can not).
-
-All events are:
-
-[NOTE NOTE NOTE: If you are driver author, you should not care; you
-should only look at event, and ignore flags.]
-
-#Prepare for suspend -- userland is still running but we are going to
-#enter suspend state. This gives drivers chance to load firmware from
-#disk and store it in memory, or do other activities taht require
-#operating userland, ability to kmalloc GFP_KERNEL, etc... All of these
-#are forbiden once the suspend dance is started.. event = ON, flags =
-#PREPARE_TO_SUSPEND
-
-Apm standby -- prepare for APM event. Quiesce devices to make life
-easier for APM BIOS. event = FREEZE, flags = APM_STANDBY
-
-Apm suspend -- same as APM_STANDBY, but it we should probably avoid
-spinning down disks. event = FREEZE, flags = APM_SUSPEND
-
-System halt, reboot -- quiesce devices to make life easier for BIOS. event
-= FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT
-
-System shutdown -- at least disks need to be spun down, or data may be
-lost. Quiesce devices, just to make life easier for BIOS. event =
-FREEZE, flags = SYSTEM_SHUTDOWN
-
-Kexec -- turn off DMAs and put hardware into some state where new
-kernel can take over. event = FREEZE, flags = KEXEC
-
-Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake
-may need to be enabled on some devices. This actually has at least 3
-subtypes, system can reboot, enter S4 and enter S5 at the end of
-swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT,
-SYSTEM_SHUTDOWN, SYSTEM_S4
-
-Suspend to ram -- put devices into low power state. event = SUSPEND,
-flags = SUSPEND_TO_RAM
-
-Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put
-devices into low power mode, but you must be able to reinitialize
-device from scratch in resume method. This has two flavors, its done
-once on suspending kernel, once on resuming kernel. event = FREEZE,
-flags = DURING_SUSPEND or DURING_RESUME
-
-Device detach requested from /sys -- deinitialize device; proably same as
-SYSTEM_SHUTDOWN, I do not understand this one too much. probably event
-= FREEZE, flags = DEV_DETACH.
-
-#These are not really events sent:
-#
-#System fully on -- device is working normally; this is probably never
-#passed to suspend() method... event = ON, flags = 0
-#
-#Ready after resume -- userland is now running, again. Time to free any
-#memory you ate during prepare to suspend... event = ON, flags =
-#READY_AFTER_RESUME
-#
-
-
-pm_message_t meaning
-
-pm_message_t has two fields. event ("major"), and flags. If driver
-does not know event code, it aborts the request, returning error. Some
-drivers may need to deal with special cases based on the actual type
-of suspend operation being done at the system level. This is why
-there are flags.
-
-Event codes are:
-
-ON -- no need to do anything except special cases like broken
-HW.
-
-# NOTIFICATION -- pretty much same as ON?
-
-FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from
-scratch. That probably means stop accepting upstream requests, the
actual policy of what to do with them being specific to a given
driver. It's acceptable for a network driver to just drop packets
while a block driver is expected to block the queue so no request is
--
1.4.0
next prev parent reply other threads:[~2006-06-21 19:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-21 19:45 [GIT PATCH] Driver Core patches for 2.6.17 Greg KH
2006-06-21 19:45 ` [PATCH 1/22] [PATCH] kobject: make people pay attention to kobject_add errors Greg KH
2006-06-21 19:45 ` [PATCH 2/22] [PATCH] Add kernel<->userspace ABI stability documentation Greg KH
2006-06-21 19:45 ` [PATCH 3/22] [PATCH] CCISS: add device symlink to the block cciss block devices in sysfs Greg KH
2006-06-21 19:45 ` [PATCH 4/22] [PATCH] Driver core: bus device event delay Greg KH
2006-06-21 19:45 ` [PATCH 5/22] [PATCH] TTY: return class device pointer from tty_register_device() Greg KH
2006-06-21 19:45 ` [PATCH 6/22] [PATCH] i4l gigaset: move sysfs entry to tty class device Greg KH
2006-06-21 19:45 ` [PATCH 7/22] [PATCH] Driver core: class_device_add needs error checks Greg KH
2006-06-21 19:45 ` [PATCH 8/22] [PATCH] Driver Core: CONFIG_DEBUG_PM covers drivers/base/power too Greg KH
2006-06-21 19:45 ` [PATCH 9/22] [PATCH] platform_bus learns about modalias Greg KH
2006-06-21 19:45 ` [PATCH 10/22] [PATCH] Driver Core: remove unused exports Greg KH
2006-06-21 19:45 ` [PATCH 11/22] [PATCH] Driver Core: Allow sysdev_class have attributes Greg KH
2006-06-21 19:45 ` [PATCH 12/22] [PATCH] Driver Core: Fix platform_device_add to use device_add Greg KH
2006-06-21 19:45 ` [PATCH 13/22] [PATCH] Driver Core: Add /sys/hypervisor when needed Greg KH
2006-06-21 19:45 ` Greg KH [this message]
2006-06-21 19:45 ` [PATCH 15/22] [PATCH] Driver core: PM_DEBUG device suspend() messages become informative Greg KH
2006-06-21 19:45 ` [PATCH 16/22] [PATCH] firmware_class: s/semaphores/mutexes Greg KH
2006-06-21 19:46 ` [PATCH 17/22] [PATCH] Driver core: change make_class_name() to take kobjects Greg KH
2006-06-21 19:46 ` [PATCH 18/22] [PATCH] Driver core: allow struct device to have a dev_t Greg KH
2006-06-21 19:46 ` [PATCH 19/22] [PATCH] Driver core: add generic "subsystem" link to all devices Greg KH
2006-06-21 19:46 ` [PATCH 20/22] [PATCH] Driver core: add proper symlinks for devices Greg KH
2006-06-21 19:46 ` [PATCH 21/22] [PATCH] Driver Core: Make dev_info and friends print the bus name if there is no driver Greg KH
2006-06-21 19:46 ` [PATCH 22/22] [PATCH] Driver model: add ISA bus Greg KH
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=11509192081167-git-send-email-greg@kroah.com \
--to=greg@kroah.com \
--cc=david-b@pacbell.net \
--cc=gregkh@suse.de \
--cc=linux-kernel@vger.kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox