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