Merge tag 'kvm-s390-next-4.9-1' of...

todo_include_todos = False

primary_domain = 'C'

highlight_language = 'C'

highlight_language = 'guess'

# -- Options for HTML output ----------------------------------------------

implemented in this driver.

Specification of the chip can be found here:

ftp:///pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf

ftp:///pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf

ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/BMC-Teutates_Specification_V1.21.pdf

ftp://ftp.ts.fujitsu.com/pub/Mainboard-OEM-Sales/Services/Software&Tools/Linux_SystemMonitoring&Watchdog&GPIO/Fujitsu_mainboards-1-Sensors_HowTo-en-US.pdf

Cross-referencing from reStructuredText

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

.. highlight:: none

To cross-reference the functions and types defined in the kernel-doc comments

from reStructuredText documents, please use the `Sphinx C Domain`_

references. For example::

Function documentation

----------------------

.. highlight:: c

The general format of a function and function-like macro kernel-doc comment is::

  /**

Converting DocBook to Sphinx

----------------------------

.. highlight:: none

Over time, we expect all of the documents under ``Documentation/DocBook`` to be

converted to Sphinx and reStructuredText. For most DocBook XML documents, a good

enough solution is to use the simple ``Documentation/sphinx/tmplcvt`` script,

Again, if you find the offending module(s), it(they) must be unloaded every time

before hibernation, and please report the problem with it(them).

c) Advanced debugging

c) Using the "test_resume" hibernation option

/sys/power/disk generally tells the kernel what to do after creating a

hibernation image.  One of the available options is "test_resume" which

causes the just created image to be used for immediate restoration.  Namely,

after doing:

# echo test_resume > /sys/power/disk

# echo disk > /sys/power/state

a hibernation image will be created and a resume from it will be triggered

immediately without involving the platform firmware in any way.

That test can be used to check if failures to resume from hibernation are

related to bad interactions with the platform firmware.  That is, if the above

works every time, but resume from actual hibernation does not work or is

unreliable, the platform firmware may be responsible for the failures.

On architectures and platforms that support using different kernels to restore

hibernation images (that is, the kernel used to read the image from storage and

load it into memory is different from the one included in the image) or support

kernel address space randomization, it also can be used to check if failures

to resume may be related to the differences between the restore and image

kernels.

d) Advanced debugging

In case that hibernation does not work on your system even in the minimal

configuration and compiling more drivers as modules is not practical or some

Power Management Interface

The power management subsystem provides a unified sysfs interface to 

userspace, regardless of what architecture or platform one is

running. The interface exists in /sys/power/ directory (assuming sysfs

is mounted at /sys). 

/sys/power/state controls system power state. Reading from this file

returns what states are supported, which is hard-coded to 'freeze',

'standby' (Power-On Suspend), 'mem' (Suspend-to-RAM), and 'disk'

(Suspend-to-Disk). 

Writing to this file one of those strings causes the system to

transition into that state. Please see the file

Documentation/power/states.txt for a description of each of those

states.

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

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 suspend_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

suspend-to-disk mechanism is in the 'testproc' mode, writing 'disk' to

/sys/power/state will cause the kernel to disable nonboot CPUs and freeze

tasks, wait for 5 seconds, unfreeze tasks and enable nonboot CPUs.  If it is

in the 'test' mode, writing 'disk' to /sys/power/state will cause the kernel

to disable nonboot CPUs and freeze tasks, shrink memory, suspend devices, wait

for 5 seconds, resume devices, unfreeze tasks and enable nonboot CPUs.  Then,

we are able to look in the log messages and work out, for example, which code

is being slow and which device drivers are misbehaving.

Reading from this file will display all supported modes and the currently

selected one in brackets, for example

	[shutdown] reboot test testproc

Writing to this file will accept one of

       'platform' (only if the platform supports it)

       'shutdown'

       'reboot'

       'testproc'

       'test'

/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

limit of the image size, in bytes.  The suspend-to-disk mechanism will

do its best to ensure the image size will not exceed that number.  However,

if this turns out to be impossible, it will try to suspend anyway using the

smallest image possible.  In particular, if "0" is written to this file, the

suspend image will be as small as possible.

Reading from this file will display the current image size limit, which

is set to 2/5 of available RAM by default.

/sys/power/pm_trace controls the code which saves the last PM event point in

the RTC across reboots, so that you can debug a machine that just hangs

during suspend (or more commonly, during resume).  Namely, the RTC is only

used to save the last PM event point if this file contains '1'.  Initially it

contains '0' which may be changed to '1' by writing a string representing a

nonzero integer into it.

To use this debugging feature you should attempt to suspend the machine, then

reboot it and run

	dmesg -s 1000000 | grep 'hash matches'

CAUTION: Using it will cause your machine's real-time (CMOS) clock to be

set to a random invalid time after a resume.

Power Management Interface for System Sleep

Copyright (c) 2016 Intel Corp., Rafael J. Wysocki <rafael.j.wysocki@intel.com>

The power management subsystem provides userspace with a unified sysfs interface

for system sleep regardless of the underlying system architecture or platform.

The interface is located in the /sys/power/ directory (assuming that sysfs is

mounted at /sys).

/sys/power/state is the system sleep state control file.

Reading from it returns a list of supported sleep states, encoded as:

'freeze' (Suspend-to-Idle)

'standby' (Power-On Suspend)

'mem' (Suspend-to-RAM)

'disk' (Suspend-to-Disk)

Suspend-to-Idle is always supported.  Suspend-to-Disk is always supported

too as long the kernel has been configured to support hibernation at all

(ie. CONFIG_HIBERNATION is set in the kernel configuration file).  Support

for Suspend-to-RAM and Power-On Suspend depends on the capabilities of the

platform.

If one of the strings listed in /sys/power/state is written to it, the system

will attempt to transition into the corresponding sleep state.  Refer to

Documentation/power/states.txt for a description of each of those states.

/sys/power/disk controls the operating mode of hibernation (Suspend-to-Disk).

Specifically, it tells the kernel what to do after creating a hibernation image.

Reading from it returns a list of supported options encoded as:

'platform' (put the system into sleep using a platform-provided method)

'shutdown' (shut the system down)

'reboot' (reboot the system)

'suspend' (trigger a Suspend-to-RAM transition)

'test_resume' (resume-after-hibernation test mode)

The currently selected option is printed in square brackets.

The 'platform' option is only available if the platform provides a special

mechanism to put the system to sleep after creating a hibernation image (ACPI

does that, for example).  The 'suspend' option is available if Suspend-to-RAM

is supported.  Refer to Documentation/power/basic_pm_debugging.txt for the

description of the 'test_resume' option.

To select an option, write the string representing it to /sys/power/disk.

/sys/power/image_size controls the size of hibernation images.

It can be written a string representing a non-negative integer that will be

used as a best-effort upper limit of the image size, in bytes.  The hibernation

core will do its best to ensure that the image size will not exceed that number.

However, if that turns out to be impossible to achieve, a hibernation image will

still be created and its size will be as small as possible.  In particular,

writing '0' to this file will enforce hibernation images to be as small as

possible.

Reading from this file returns the current image size limit, which is set to

around 2/5 of available RAM by default.

/sys/power/pm_trace controls the PM trace mechanism saving the last suspend

or resume event point in the RTC across reboots.

It helps to debug hard lockups or reboots due to device driver failures that

occur during system suspend or resume (which is more common) more effectively.

If /sys/power/pm_trace contains '1', the fingerprint of each suspend/resume

event point in turn will be stored in the RTC memory (overwriting the actual

RTC information), so it will survive a system crash if one occurs right after

storing it and it can be used later to identify the driver that caused the crash

to happen (see Documentation/power/s2ram.txt for more information).

Initially it contains '0' which may be changed to '1' by writing a string

representing a nonzero integer into it.