1 What:		/sys/power/
2 Date:		August 2006
3 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
4 Description:
5 		The /sys/power directory will contain files that will
6 		provide a unified interface to the power management
7 		subsystem.
8 
9 What:		/sys/power/state
10 Date:		November 2016
11 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
12 Description:
13 		The /sys/power/state file controls system sleep states.
14 		Reading from this file returns the available sleep state
15 		labels, which may be "mem" (suspend), "standby" (power-on
16 		suspend), "freeze" (suspend-to-idle) and "disk" (hibernation).
17 
18 		Writing one of the above strings to this file causes the system
19 		to transition into the corresponding state, if available.
20 
21 		See Documentation/admin-guide/pm/sleep-states.rst for more
22 		information.
23 
24 What:		/sys/power/mem_sleep
25 Date:		November 2016
26 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
27 Description:
28 		The /sys/power/mem_sleep file controls the operating mode of
29 		system suspend.  Reading from it returns the available modes
30 		as "s2idle" (always present), "shallow" and "deep" (present if
31 		supported).  The mode that will be used on subsequent attempts
32 		to suspend the system (by writing "mem" to the /sys/power/state
33 		file described above) is enclosed in square brackets.
34 
35 		Writing one of the above strings to this file causes the mode
36 		represented by it to be used on subsequent attempts to suspend
37 		the system.
38 
39 		See Documentation/admin-guide/pm/sleep-states.rst for more
40 		information.
41 
42 What:		/sys/power/disk
43 Date:		September 2006
44 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
45 Description:
46 		The /sys/power/disk file controls the operating mode of the
47 		suspend-to-disk mechanism.  Reading from this file returns
48 		the name of the method by which the system will be put to
49 		sleep on the next suspend.  There are four methods supported:
50 
51 		'firmware' - means that the memory image will be saved to disk
52 		by some firmware, in which case we also assume that the
53 		firmware will handle the system suspend.
54 
55 		'platform' - the memory image will be saved by the kernel and
56 		the system will be put to sleep by the platform driver (e.g.
57 		ACPI or other PM registers).
58 
59 		'shutdown' - the memory image will be saved by the kernel and
60 		the system will be powered off.
61 
62 		'reboot' - the memory image will be saved by the kernel and
63 		the system will be rebooted.
64 
65 		Additionally, /sys/power/disk can be used to turn on one of the
66 		two testing modes of the suspend-to-disk mechanism: 'testproc'
67 		or 'test'.  If the suspend-to-disk mechanism is in the
68 		'testproc' mode, writing 'disk' to /sys/power/state will cause
69 		the kernel to disable nonboot CPUs and freeze tasks, wait for 5
70 		seconds, unfreeze tasks and enable nonboot CPUs.  If it is in
71 		the 'test' mode, writing 'disk' to /sys/power/state will cause
72 		the kernel to disable nonboot CPUs and freeze tasks, shrink
73 		memory, suspend devices, wait for 5 seconds, resume devices,
74 		unfreeze tasks and enable nonboot CPUs.  Then, we are able to
75 		look in the log messages and work out, for example, which code
76 		is being slow and which device drivers are misbehaving.
77 
78 		The suspend-to-disk method may be chosen by writing to this
79 		file one of the accepted strings:
80 
81 		- 'firmware'
82 		- 'platform'
83 		- 'shutdown'
84 		- 'reboot'
85 		- 'testproc'
86 		- 'test'
87 
88 		It will only change to 'firmware' or 'platform' if the system
89 		supports that.
90 
91 What:		/sys/power/image_size
92 Date:		August 2006
93 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
94 Description:
95 		The /sys/power/image_size file controls the size of the image
96 		created by the suspend-to-disk mechanism.  It can be written a
97 		string representing a non-negative integer that will be used
98 		as an upper limit of the image size, in bytes.  The kernel's
99 		suspend-to-disk code will do its best to ensure the image size
100 		will not exceed this number.  However, if it turns out to be
101 		impossible, the kernel will try to suspend anyway using the
102 		smallest image possible.  In particular, if "0" is written to
103 		this file, the suspend image will be as small as possible.
104 
105 		Reading from this file will display the current image size
106 		limit, which is set to around 2/5 of available RAM by default.
107 
108 What:		/sys/power/pm_trace
109 Date:		August 2006
110 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
111 Description:
112 		The /sys/power/pm_trace file controls the code which saves the
113 		last PM event point in the RTC across reboots, so that you can
114 		debug a machine that just hangs during suspend (or more
115 		commonly, during resume).  Namely, the RTC is only used to save
116 		the last PM event point if this file contains '1'.  Initially
117 		it contains '0' which may be changed to '1' by writing a
118 		string representing a nonzero integer into it.
119 
120 		To use this debugging feature you should attempt to suspend
121 		the machine, then reboot it and run::
122 
123 		  dmesg -s 1000000 | grep 'hash matches'
124 
125 		If you do not get any matches (or they appear to be false
126 		positives), it is possible that the last PM event point
127 		referred to a device created by a loadable kernel module.  In
128 		this case cat /sys/power/pm_trace_dev_match (see below) after
129 		your system is started up and the kernel modules are loaded.
130 
131 		CAUTION: Using it will cause your machine's real-time (CMOS)
132 		clock to be set to a random invalid time after a resume.
133 
134 What;		/sys/power/pm_trace_dev_match
135 Date:		October 2010
136 Contact:	James Hogan <jhogan@kernel.org>
137 Description:
138 		The /sys/power/pm_trace_dev_match file contains the name of the
139 		device associated with the last PM event point saved in the RTC
140 		across reboots when pm_trace has been used.  More precisely it
141 		contains the list of current devices (including those
142 		registered by loadable kernel modules since boot) which match
143 		the device hash in the RTC at boot, with a newline after each
144 		one.
145 
146 		The advantage of this file over the hash matches printed to the
147 		kernel log (see /sys/power/pm_trace), is that it includes
148 		devices created after boot by loadable kernel modules.
149 
150 		Due to the small hash size necessary to fit in the RTC, it is
151 		possible that more than one device matches the hash, in which
152 		case further investigation is required to determine which
153 		device is causing the problem.  Note that genuine RTC clock
154 		values (such as when pm_trace has not been used), can still
155 		match a device and output its name here.
156 
157 What:		/sys/power/pm_async
158 Date:		January 2009
159 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
160 Description:
161 		The /sys/power/pm_async file controls the switch allowing the
162 		user space to enable or disable asynchronous suspend and resume
163 		of devices.  If enabled, this feature will cause some device
164 		drivers' suspend and resume callbacks to be executed in parallel
165 		with each other and with the main suspend thread.  It is enabled
166 		if this file contains "1", which is the default.  It may be
167 		disabled by writing "0" to this file, in which case all devices
168 		will be suspended and resumed synchronously.
169 
170 What:		/sys/power/wakeup_count
171 Date:		July 2010
172 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
173 Description:
174 		The /sys/power/wakeup_count file allows user space to put the
175 		system into a sleep state while taking into account the
176 		concurrent arrival of wakeup events.  Reading from it returns
177 		the current number of registered wakeup events and it blocks if
178 		some wakeup events are being processed at the time the file is
179 		read from.  Writing to it will only succeed if the current
180 		number of wakeup events is equal to the written value and, if
181 		successful, will make the kernel abort a subsequent transition
182 		to a sleep state if any wakeup events are reported after the
183 		write has returned.
184 
185 What:		/sys/power/reserved_size
186 Date:		May 2011
187 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
188 Description:
189 		The /sys/power/reserved_size file allows user space to control
190 		the amount of memory reserved for allocations made by device
191 		drivers during the "device freeze" stage of hibernation.  It can
192 		be written a string representing a non-negative integer that
193 		will be used as the amount of memory to reserve for allocations
194 		made by device drivers' "freeze" callbacks, in bytes.
195 
196 		Reading from this file will display the current value, which is
197 		set to 1 MB by default.
198 
199 What:		/sys/power/autosleep
200 Date:		April 2012
201 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
202 Description:
203 		The /sys/power/autosleep file can be written one of the strings
204 		returned by reads from /sys/power/state.  If that happens, a
205 		work item attempting to trigger a transition of the system to
206 		the sleep state represented by that string is queued up.  This
207 		attempt will only succeed if there are no active wakeup sources
208 		in the system at that time.  After every execution, regardless
209 		of whether or not the attempt to put the system to sleep has
210 		succeeded, the work item requeues itself until user space
211 		writes "off" to /sys/power/autosleep.
212 
213 		Reading from this file causes the last string successfully
214 		written to it to be returned.
215 
216 What:		/sys/power/wake_lock
217 Date:		February 2012
218 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
219 Description:
220 		The /sys/power/wake_lock file allows user space to create
221 		wakeup source objects and activate them on demand (if one of
222 		those wakeup sources is active, reads from the
223 		/sys/power/wakeup_count file block or return false).  When a
224 		string without white space is written to /sys/power/wake_lock,
225 		it will be assumed to represent a wakeup source name.  If there
226 		is a wakeup source object with that name, it will be activated
227 		(unless active already).  Otherwise, a new wakeup source object
228 		will be registered, assigned the given name and activated.
229 		If a string written to /sys/power/wake_lock contains white
230 		space, the part of the string preceding the white space will be
231 		regarded as a wakeup source name and handled as descrived above.
232 		The other part of the string will be regarded as a timeout (in
233 		nanoseconds) such that the wakeup source will be automatically
234 		deactivated after it has expired.  The timeout, if present, is
235 		set regardless of the current state of the wakeup source object
236 		in question.
237 
238 		Reads from this file return a string consisting of the names of
239 		wakeup sources created with the help of it that are active at
240 		the moment, separated with spaces.
241 
242 
243 What:		/sys/power/wake_unlock
244 Date:		February 2012
245 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
246 Description:
247 		The /sys/power/wake_unlock file allows user space to deactivate
248 		wakeup sources created with the help of /sys/power/wake_lock.
249 		When a string is written to /sys/power/wake_unlock, it will be
250 		assumed to represent the name of a wakeup source to deactivate.
251 
252 		If a wakeup source object of that name exists and is active at
253 		the moment, it will be deactivated.
254 
255 		Reads from this file return a string consisting of the names of
256 		wakeup sources created with the help of /sys/power/wake_lock
257 		that are inactive at the moment, separated with spaces.
258 
259 What:		/sys/power/pm_print_times
260 Date:		May 2012
261 Contact:	Sameer Nanda <snanda@chromium.org>
262 Description:
263 		The /sys/power/pm_print_times file allows user space to
264 		control whether the time taken by devices to suspend and
265 		resume is printed.  These prints are useful for hunting down
266 		devices that take too long to suspend or resume.
267 
268 		Writing a "1" enables this printing while writing a "0"
269 		disables it.  The default value is "0".  Reading from this file
270 		will display the current value.
271 
272 What:		/sys/power/pm_wakeup_irq
273 Date:		April 2015
274 Contact:	Alexandra Yates <alexandra.yates@linux.intel.org>
275 Description:
276 		The /sys/power/pm_wakeup_irq file reports to user space the IRQ
277 		number of the first wakeup interrupt (that is, the first
278 		interrupt from an IRQ line armed for system wakeup) seen by the
279 		kernel during the most recent system suspend/resume cycle.
280 
281 		This output is useful for system wakeup diagnostics of spurious
282 		wakeup interrupts.
283 
284 What:		/sys/power/pm_debug_messages
285 Date:		July 2017
286 Contact:	Rafael J. Wysocki <rjw@rjwysocki.net>
287 Description:
288 		The /sys/power/pm_debug_messages file controls the printing
289 		of debug messages from the system suspend/hiberbation
290 		infrastructure to the kernel log.
291 
292 		Writing a "1" to this file enables the debug messages and
293 		writing a "0" (default) to it disables them.  Reads from
294 		this file return the current value.
295 
296 What:		/sys/power/resume_offset
297 Date:		April 2018
298 Contact:	Mario Limonciello <mario.limonciello@outlook.com>
299 Description:
300 		This file is used for telling the kernel an offset into a disk
301 		to use when hibernating the system such as with a swap file.
302 
303 		Reads from this file will display the current offset
304 		the kernel will be using on the next hibernation
305 		attempt.
306 
307 		Using this sysfs file will override any values that were
308 		set using the kernel command line for disk offset.
309 
310 What:		/sys/power/suspend_stats
311 Date:		July 2019
312 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
313 Description:
314 		The /sys/power/suspend_stats directory contains suspend related
315 		statistics.
316 
317 What:		/sys/power/suspend_stats/success
318 Date:		July 2019
319 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
320 Description:
321 		The /sys/power/suspend_stats/success file contains the number
322 		of times entering system sleep state succeeded.
323 
324 What:		/sys/power/suspend_stats/fail
325 Date:		July 2019
326 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
327 Description:
328 		The /sys/power/suspend_stats/fail file contains the number
329 		of times entering system sleep state failed.
330 
331 What:		/sys/power/suspend_stats/failed_freeze
332 Date:		July 2019
333 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
334 Description:
335 		The /sys/power/suspend_stats/failed_freeze file contains the
336 		number of times freezing processes failed.
337 
338 What:		/sys/power/suspend_stats/failed_prepare
339 Date:		July 2019
340 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
341 Description:
342 		The /sys/power/suspend_stats/failed_prepare file contains the
343 		number of times preparing all non-sysdev devices for
344 		a system PM transition failed.
345 
346 What:		/sys/power/suspend_stats/failed_resume
347 Date:		July 2019
348 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
349 Description:
350 		The /sys/power/suspend_stats/failed_resume file contains the
351 		number of times executing "resume" callbacks of
352 		non-sysdev devices failed.
353 
354 What:		/sys/power/suspend_stats/failed_resume_early
355 Date:		July 2019
356 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
357 Description:
358 		The /sys/power/suspend_stats/failed_resume_early file contains
359 		the number of times executing "early resume" callbacks
360 		of devices failed.
361 
362 What:		/sys/power/suspend_stats/failed_resume_noirq
363 Date:		July 2019
364 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
365 Description:
366 		The /sys/power/suspend_stats/failed_resume_noirq file contains
367 		the number of times executing "noirq resume" callbacks
368 		of devices failed.
369 
370 What:		/sys/power/suspend_stats/failed_suspend
371 Date:		July 2019
372 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
373 Description:
374 		The /sys/power/suspend_stats/failed_suspend file contains
375 		the number of times executing "suspend" callbacks
376 		of all non-sysdev devices failed.
377 
378 What:		/sys/power/suspend_stats/failed_suspend_late
379 Date:		July 2019
380 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
381 Description:
382 		The /sys/power/suspend_stats/failed_suspend_late file contains
383 		the number of times executing "late suspend" callbacks
384 		of all devices failed.
385 
386 What:		/sys/power/suspend_stats/failed_suspend_noirq
387 Date:		July 2019
388 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
389 Description:
390 		The /sys/power/suspend_stats/failed_suspend_noirq file contains
391 		the number of times executing "noirq suspend" callbacks
392 		of all devices failed.
393 
394 What:		/sys/power/suspend_stats/last_failed_dev
395 Date:		July 2019
396 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
397 Description:
398 		The /sys/power/suspend_stats/last_failed_dev file contains
399 		the last device for which a suspend/resume callback failed.
400 
401 What:		/sys/power/suspend_stats/last_failed_errno
402 Date:		July 2019
403 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
404 Description:
405 		The /sys/power/suspend_stats/last_failed_errno file contains
406 		the errno of the last failed attempt at entering
407 		system sleep state.
408 
409 What:		/sys/power/suspend_stats/last_failed_step
410 Date:		July 2019
411 Contact:	Kalesh Singh <kaleshsingh96@gmail.com>
412 Description:
413 		The /sys/power/suspend_stats/last_failed_step file contains
414 		the last failed step in the suspend/resume path.
415 
416 What:		/sys/power/suspend_stats/last_hw_sleep
417 Date:		June 2023
418 Contact:	Mario Limonciello <mario.limonciello@amd.com>
419 Description:
420 		The /sys/power/suspend_stats/last_hw_sleep file
421 		contains the duration of time spent in a hardware sleep
422 		state in the most recent system suspend-resume cycle.
423 		This number is measured in microseconds.
424 
425 What:		/sys/power/suspend_stats/total_hw_sleep
426 Date:		June 2023
427 Contact:	Mario Limonciello <mario.limonciello@amd.com>
428 Description:
429 		The /sys/power/suspend_stats/total_hw_sleep file
430 		contains the aggregate of time spent in a hardware sleep
431 		state since the kernel was booted. This number
432 		is measured in microseconds.
433 
434 What:		/sys/power/suspend_stats/max_hw_sleep
435 Date:		June 2023
436 Contact:	Mario Limonciello <mario.limonciello@amd.com>
437 Description:
438 		The /sys/power/suspend_stats/max_hw_sleep file
439 		contains the maximum amount of time that the hardware can
440 		report for time spent in a hardware sleep state. When sleep
441 		cycles are longer than this time, the values for
442 		'total_hw_sleep' and 'last_hw_sleep' may not be accurate.
443 		This number is measured in microseconds.
444 
445 What:		/sys/power/sync_on_suspend
446 Date:		October 2019
447 Contact:	Jonas Meurer <jonas@freesources.org>
448 Description:
449 		This file controls whether or not the kernel will sync()
450 		filesystems during system suspend (after freezing user space
451 		and before suspending devices).
452 
453 		Writing a "1" to this file enables the sync() and writing a "0"
454 		disables it.  Reads from the file return the current value.
455 		The default is "1" if the build-time "SUSPEND_SKIP_SYNC" config
456 		flag is unset, or "0" otherwise.
457