power management: remove firmware disk mode

/sys/power/disk controls the operating mode of the suspend-to-disk

mechanism. Suspend-to-disk can be handled in several ways. The

greatest distinction is who writes memory to disk - the firmware or

the kernel. If the firmware does it, we assume that it also handles

suspending the system. 

If the kernel does it, then we have three options for putting the system

to sleep - using the platform driver (e.g. ACPI or other PM

registers), powering off the system or rebooting the system (for

testing). The system will support either 'firmware' or 'platform', and

that is known a priori. But, the user may choose 'shutdown' or

'reboot' as alternatives. 

mechanism. Suspend-to-disk can be handled in several ways. We have a

few options for putting the system to sleep - using the platform driver

(e.g. ACPI or other pm_ops), powering off the system or rebooting the

system (for testing).

Additionally, /sys/power/disk can be used to turn on one of the two testing

modes of the suspend-to-disk mechanism: 'testproc' or 'test'.  If the

Reading from this file will display what the mode is currently set

to. Writing to this file will accept one of

       'firmware'

       'platform'

       'platform' (only if the platform supports it)

       'shutdown'

       'reboot'

       'testproc'

       'test'

It will only change to 'firmware' or 'platform' if the system supports

it. 

/sys/power/image_size controls the size of the image created by

the suspend-to-disk mechanism.  It can be written a string

representing a non-negative integer that will be used as an upper

inconvenience, this method requires minimal work by the kernel, since

the firmware will also handle restoring memory contents on resume. 

If the kernel is responsible for persistently saving state, a mechanism

called 'swsusp' (Swap Suspend) is used to write memory contents to

free swap space. swsusp has some restrictive requirements, but should

work in most cases. Some, albeit outdated, documentation can be found

in Documentation/power/swsusp.txt. 

For suspend-to-disk, a mechanism called swsusp called 'swsusp' (Swap

Suspend) is used to write memory contents to free swap space.

swsusp has some restrictive requirements, but should work in most

cases. Some, albeit outdated, documentation can be found in

Documentation/power/swsusp.txt. Alternatively, userspace can do most

of the actual suspend to disk work, see userland-swsusp.txt.

Once memory state is written to disk, the system may either enter a

low-power state (like ACPI S4), or it may simply power down. Powering

be very careful).

Q: What is the difference between "platform", "shutdown" and

"firmware" in /sys/power/disk?

Q: What is the difference between "platform" and "shutdown"?

A:

platform: save state in linux, then tell bios to powerdown and blink

          "suspended led"

firmware: tell bios to save state itself [needs BIOS-specific suspend

	  partition, and has very little to do with swsusp]

"platform" is actually right thing to do, but "shutdown" is most

reliable.

"platform" is actually right thing to do where supported, but

"shutdown" is most reliable (except on ACPI systems).

Q: I do not understand why you have such strong objections to idea of

selective suspend.

modes like "suspend-to-RAM" or "standby".  (Don't write "disk" to the

/sys/power/state file; write "standby" or "mem".)  We've not seen any

hardware that can use these modes through software suspend, although in

theory some systems might support "platform" or "firmware" modes that

won't break the USB connections.

theory some systems might support "platform" modes that won't break the

USB connections.

Remember that it's always a bad idea to unplug a disk drive containing a

mounted filesystem.  That's true even when your system is asleep!  The

/* invalid must be 0 so struct pm_ops initialisers can leave it out */

#define PM_DISK_INVALID		((__force suspend_disk_method_t) 0)

#define	PM_DISK_FIRMWARE	((__force suspend_disk_method_t) 1)

#define	PM_DISK_PLATFORM	((__force suspend_disk_method_t) 2)

#define	PM_DISK_SHUTDOWN	((__force suspend_disk_method_t) 3)

#define	PM_DISK_REBOOT		((__force suspend_disk_method_t) 4)

#define	PM_DISK_TEST		((__force suspend_disk_method_t) 5)

#define	PM_DISK_TESTPROC	((__force suspend_disk_method_t) 6)

#define	PM_DISK_MAX		((__force suspend_disk_method_t) 7)

#define	PM_DISK_PLATFORM	((__force suspend_disk_method_t) 1)

#define	PM_DISK_SHUTDOWN	((__force suspend_disk_method_t) 2)

#define	PM_DISK_REBOOT		((__force suspend_disk_method_t) 3)

#define	PM_DISK_TEST		((__force suspend_disk_method_t) 4)

#define	PM_DISK_TESTPROC	((__force suspend_disk_method_t) 5)

#define	PM_DISK_MAX		((__force suspend_disk_method_t) 6)

/**

 * struct pm_ops - Callbacks for managing platform dependent suspend states.

/**

 *	pm_suspend_disk - The granpappy of hibernation power management.

 *

 *	If we're going through the firmware, then get it over with quickly.

 *

 *	If not, then call swsusp to do its thing, then figure out how

 *	to power down the system.

 */

static const char * const pm_disk_modes[] = {

	[PM_DISK_FIRMWARE]	= "firmware",

	[PM_DISK_PLATFORM]	= "platform",

	[PM_DISK_SHUTDOWN]	= "shutdown",

	[PM_DISK_REBOOT]	= "reboot",

/**

 *	disk - Control suspend-to-disk mode

 *

 *	Suspend-to-disk can be handled in several ways. The greatest

 *	distinction is who writes memory to disk - the firmware or the OS.

 *	If the firmware does it, we assume that it also handles suspending

 *	the system.

 *	If the OS does it, then we have three options for putting the system

 *	to sleep - using the platform driver (e.g. ACPI or other PM registers),

 *	powering off the system or rebooting the system (for testing).

 *	Suspend-to-disk can be handled in several ways. We have a few options

 *	for putting the system to sleep - using the platform driver (e.g. ACPI

 *	or other pm_ops), powering off the system or rebooting the system

 *	(for testing) as well as the two test modes.

 *

 *	The system will support either 'firmware' or 'platform', and that is

 *	known a priori (and encoded in pm_ops). But, the user may choose

 *	'shutdown' or 'reboot' as alternatives.

 *	The system can support 'platform', and that is known a priori (and

 *	encoded in pm_ops). However, the user may choose 'shutdown' or 'reboot'

 *	as alternatives, as well as the test modes 'test' and 'testproc'.

 *

 *	show() will display what the mode is currently set to.

 *	store() will accept one of

 *

 *	'firmware'

 *	'platform'

 *	'shutdown'

 *	'reboot'

 *	'test'

 *	'testproc'

 *

 *	It will only change to 'firmware' or 'platform' if the system

 *	It will only change to 'platform' if the system

 *	supports it (as determined from pm_ops->pm_disk_mode).

 */

	len = p ? p - buf : n;

	mutex_lock(&pm_mutex);

	for (i = PM_DISK_FIRMWARE; i < PM_DISK_MAX; i++) {

	for (i = PM_DISK_PLATFORM; i < PM_DISK_MAX; i++) {

		if (!strncmp(buf, pm_disk_modes[i], len)) {

			mode = i;

			break;