1 .. _usb-power-management:
2
3 Power Management for USB
4 ~~~~~~~~~~~~~~~~~~~~~~~~
5
6 :Author: Alan Stern <stern@rowland.harvard.edu>
7 :Date: Last-updated: February 2014
8
9 ..
10 Contents:
11 ---------
12 * What is Power Management?
13 * What is Remote Wakeup?
14 * When is a USB device idle?
15 * Forms of dynamic PM
16 * The user interface for dynamic PM
17 * Changing the default idle-delay time
18 * Warnings
19 * The driver interface for Power Manag
20 * The driver interface for autosuspend
21 * Other parts of the driver interface
22 * Mutual exclusion
23 * Interaction between dynamic PM and s
24 * xHCI hardware link PM
25 * USB Port Power Control
26 * User Interface for Port Power Contro
27 * Suggested Userspace Port Power Polic
28
29
30 What is Power Management?
31 -------------------------
32
33 Power Management (PM) is the practice of savin
34 parts of a computer system when they aren't be
35 component is ``suspended`` it is in a nonfunct
36 might even be turned off completely. A suspen
37 ``resumed`` (returned to a functional full-pow
38 needs to use it. (There also are forms of PM
39 placed in a less functional but still usable s
40 suspended; an example would be reducing the CP
41 document will not discuss those other forms.)
42
43 When the parts being suspended include the CPU
44 the system, we speak of it as a "system suspen
45 device is turned off while the system as a who
46 call it a "dynamic suspend" (also known as a "
47 "selective suspend"). This document concentra
48 dynamic PM is implemented in the USB subsystem
49 covered to some extent (see ``Documentation/po
50 information about system PM).
51
52 System PM support is present only if the kerne
53 ``CONFIG_SUSPEND`` or ``CONFIG_HIBERNATION`` e
54
55 for USB is present whenever
56 the kernel was built with ``CONFIG_PM`` enable
57
58 [Historically, dynamic PM support for USB was
59 kernel had been built with ``CONFIG_USB_SUSPEN
60 ``CONFIG_PM_RUNTIME``). Starting with the 3.1
61 support for USB was present whenever the kerne
62 ``CONFIG_PM_RUNTIME`` enabled. The ``CONFIG_U
63 eliminated.]
64
65
66 What is Remote Wakeup?
67 ----------------------
68
69 When a device has been suspended, it generally
70 the computer tells it to. Likewise, if the en
71 suspended, it generally doesn't resume until t
72 by pressing a power button or opening the cove
73
74 However some devices have the capability of re
75 asking the kernel to resume them, or even tell
76 to resume. This capability goes by several na
77 LAN"; we will refer to it generically as "remo
78 device is enabled for remote wakeup and it is
79 itself (or send a request to be resumed) in re
80 event. Examples include a suspended keyboard
81 pressed, or a suspended USB hub resuming when
82
83
84 When is a USB device idle?
85 --------------------------
86
87 A device is idle whenever the kernel thinks it
88 anything important and thus is a candidate for
89 exact definition depends on the device's drive
90 to declare that a device isn't idle even when
91 communication taking place. (For example, a h
92 unless all the devices plugged into that hub a
93 In addition, a device isn't considered idle so
94 its usbfs file open, whether or not any I/O is
95
96 If a USB device has no driver, its usbfs file
97 being accessed through sysfs, then it definite
98
99
100 Forms of dynamic PM
101 -------------------
102
103 Dynamic suspends occur when the kernel decides
104 device. This is called ``autosuspend`` for sh
105 won't be autosuspended unless it has been idle
106 of time, the so-called idle-delay time.
107
108 Of course, nothing the kernel does on its own
109 prevent the computer or its devices from worki
110 device has been autosuspended and a program tr
111 kernel will automatically resume the device (a
112 same reason, an autosuspended device will usua
113 enabled, if the device supports remote wakeup.
114
115 It is worth mentioning that many USB drivers d
116 autosuspend. In fact, at the time of this wri
117 only drivers which do support it are the hub d
118 usblp, usblcd, and usb-skeleton (which doesn't
119 non-supporting driver is bound to a device, th
120 autosuspended. In effect, the kernel pretends
121 idle.
122
123 We can categorize power management events in t
124 external and internal. External events are th
125 agent outside the USB stack: system suspend/re
126 userspace), manual dynamic resume (also trigge
127 remote wakeup (triggered by the device). Inte
128 triggered within the USB stack: autosuspend an
129 all dynamic suspend events are internal; exter
130 allowed to issue dynamic suspends.
131
132
133 The user interface for dynamic PM
134 ---------------------------------
135
136 The user interface for controlling dynamic PM
137 subdirectory of each USB device's sysfs direct
138 ``/sys/bus/usb/devices/.../power/`` where "...
139 relevant attribute files are: wakeup, control,
140 ``autosuspend_delay_ms``. (There may also be
141 file was deprecated as of the 2.6.35 kernel an
142 ``control`` file. In 2.6.38 the ``autosuspend
143 and replaced by the ``autosuspend_delay_ms`` f
144 is that the newer file expresses the delay in
145 older file uses seconds. Confusingly, both fi
146 but only ``autosuspend`` works.)
147
148 ``power/wakeup``
149
150 This file is empty if the devi
151 remote wakeup. Otherwise the
152 word ``enabled`` or the word `
153 write those words to the file.
154 whether or not remote wakeup w
155 device is next suspended. (If
156 while the device is suspended,
157 effect until the following sus
158
159 ``power/control``
160
161 This file contains one of two
162 You can write those words to t
163 device's setting.
164
165 - ``on`` means that the device
166 autosuspend is not allowed.
167 suspends are still allowed.)
168
169 - ``auto`` is the normal state
170 allowed to autosuspend and a
171
172 (In kernels up to 2.6.32, you
173 ``suspend``, meaning that the
174 suspended and autoresume was n
175 setting is no longer supported
176
177 ``power/autosuspend_delay_ms``
178
179 This file contains an integer
180 number of milliseconds the dev
181 before the kernel will autosus
182 time). The default is 2000.
183 as soon as the device becomes
184 values mean never to autosuspe
185 number to the file to change t
186 idle-delay time.
187
188 Writing ``-1`` to ``power/autosuspend_delay_ms
189 ``power/control`` do essentially the same thin
190 device from being autosuspended. Yes, this is
191 API.
192
193 (In 2.6.21 writing ``0`` to ``power/autosuspen
194 from being autosuspended; the behavior was cha
195 ``power/autosuspend`` attribute did not exist
196 ``power/level`` attribute did not exist prior
197 was added in 2.6.34, and ``power/autosuspend_d
198 2.6.37 but did not become functional until 2.6
199
200
201 Changing the default idle-delay time
202 ------------------------------------
203
204 The default autosuspend idle-delay time (in se
205 a module parameter in usbcore. You can specif
206 is loaded. For example, to set it to 5 second
207 do::
208
209 modprobe usbcore autosuspend=5
210
211 Equivalently, you could add to a configuration
212 a line saying::
213
214 options usbcore autosuspend=5
215
216 Some distributions load the usbcore module ver
217 process, by means of a program or script runni
218 image. To alter the parameter value you would
219 image.
220
221 If usbcore is compiled into the kernel rather
222 module, you can add::
223
224 usbcore.autosuspend=5
225
226 to the kernel's boot command line.
227
228 Finally, the parameter value can be changed wh
229 running. If you do::
230
231 echo 5 >/sys/module/usbcore/parameters
232
233 then each new USB device will have its autosus
234 initialized to 5. (The idle-delay values for
235 will not be affected.)
236
237 Setting the initial default idle-delay to -1 w
238 autosuspend of any USB device. This has the b
239 then to enable autosuspend for selected device
240
241
242 Warnings
243 --------
244
245 The USB specification states that all USB devi
246 management. Nevertheless, the sad fact is tha
247 support it very well. You can suspend them al
248 try to resume them they disconnect themselves
249 they stop working entirely. This seems to be
250 among printers and scanners, but plenty of oth
251 the same deficiency.
252
253 For this reason, by default the kernel disable
254 ``power/control`` attribute is initialized to
255 than hubs. Hubs, at least, appear to be reaso
256 this regard.
257
258 (In 2.6.21 and 2.6.22 this wasn't the case. A
259 by default for almost all USB devices. A numb
260 problems as a result.)
261
262 This means that non-hub devices won't be autos
263 or a program explicitly enables it. As of thi
264 any widespread programs which will do this; we
265 future device managers such as HAL will take o
266 responsibility. In the meantime you can alway
267 necessary operations by hand or add them to a
268 also change the idle-delay time; 2 seconds is
269 every device.
270
271 If a driver knows that its device has proper s
272 it can enable autosuspend all by itself. For
273 driver for a laptop's webcam might do this (in
274 do), since these devices are rarely used and s
275 autosuspended.
276
277 Sometimes it turns out that even when a device
278 autosuspend there are still problems. For exa
279 which manages keyboards and mice, has autosusp
280 a number of keyboards show that typing on a su
281 causing the keyboard to do a remote wakeup all
282 frequently result in lost keystrokes. Tests w
283 of them will issue a remote-wakeup request in
284 presses but not to motion, and some in respons
285
286 The kernel will not prevent you from enabling
287 that can't handle it. It is even possible in
288 device by suspending it at the wrong time. (H
289 possible.) Take care.
290
291
292 The driver interface for Power Management
293 -----------------------------------------
294
295 The requirements for a USB driver to support e
296 are pretty modest; the driver need only define
297
298 .suspend
299 .resume
300 .reset_resume
301
302 methods in its :c:type:`usb_driver` structure,
303 is optional. The methods' jobs are quite simp
304
305 - The ``suspend`` method is called to wa
306 device is going to be suspended. If t
307 negative error code, the suspend will
308 the driver will return 0, in which cas
309 outstanding URBs (:c:func:`usb_kill_ur
310
311 - The ``resume`` method is called to tel
312 device has been resumed and the driver
313 operation. URBs may once more be subm
314
315 - The ``reset_resume`` method is called
316 the device has been resumed and it als
317 The driver should redo any necessary d
318 since the device has probably lost mos
319 (although the interfaces will be in th
320 before the suspend).
321
322 If the device is disconnected or powered down
323 the ``disconnect`` method will be called inste
324 ``reset_resume`` method. This is also quite l
325 waking up from hibernation, as many systems do
326 current to the USB host controllers during hib
327 possible to work around the hibernation-forces
328 using the USB Persist facility.)
329
330 The ``reset_resume`` method is used by the USB
331 :ref:`usb-persist`) and it can also be used un
332 circumstances when ``CONFIG_USB_PERSIST`` is n
333 device is reset during a resume and the driver
334 ``reset_resume`` method, the driver won't rece
335 the resume. Later kernels will call the drive
336 2.6.23 doesn't do this.
337
338 USB drivers are bound to interfaces, so their
339 methods get called when the interfaces are sus
340 principle one might want to suspend some inter
341 force the drivers for those interface to stop
342 suspending the other interfaces. The USB core
343 interfaces are suspended when the device itsel
344 interfaces are resumed when the device is resu
345 to suspend or resume some but not all of a dev
346 closest you can come is to unbind the interfac
347
348
349 The driver interface for autosuspend and autor
350 ----------------------------------------------
351
352 To support autosuspend and autoresume, a drive
353 three of the methods listed above. In additio
354 that it supports autosuspend by setting the ``
355 in its usb_driver structure. It is then respo
356 USB core whenever one of its interfaces become
357 driver does so by calling these six functions:
358
359 int usb_autopm_get_interface(struct u
360 void usb_autopm_put_interface(struct u
361 int usb_autopm_get_interface_async(st
362 void usb_autopm_put_interface_async(st
363 void usb_autopm_get_interface_no_resum
364 void usb_autopm_put_interface_no_suspe
365
366 The functions work by maintaining a usage coun
367 usb_interface's embedded device structure. Wh
368 then the interface is deemed to be busy, and t
369 autosuspend the interface's device. When the
370 then the interface is considered to be idle, a
371 autosuspend the device.
372
373 Drivers must be careful to balance their overa
374 counter. Unbalanced "get"s will remain in eff
375 unbound from its interface, preventing the dev
376 runtime suspend should the interface be bound
377 the other hand, drivers are allowed to achieve
378 the ``usb_autopm_*`` functions even after thei
379 has returned -- say from within a work-queue r
380 retain an active reference to the interface (v
381 ``usb_put_intf``).
382
383 Drivers using the async routines are responsib
384 synchronization and mutual exclusion.
385
386 :c:func:`usb_autopm_get_interface` inc
387 does an autoresume if the device is su
388 autoresume fails, the counter is decre
389
390 :c:func:`usb_autopm_put_interface` dec
391 attempts an autosuspend if the new val
392
393 :c:func:`usb_autopm_get_interface_asyn
394 :c:func:`usb_autopm_put_interface_asyn
395 their non-async counterparts. The big
396 use a workqueue to do the resume or su
397 jobs. As a result they can be called
398 such as an URB's completion handler, b
399 device will generally not yet be in th
400
401 :c:func:`usb_autopm_get_interface_no_r
402 :c:func:`usb_autopm_put_interface_no_s
403 decrement the usage counter; they do n
404 an autoresume or an autosuspend. Henc
405 an atomic context.
406
407 The simplest usage pattern is that a driver ca
408 :c:func:`usb_autopm_get_interface` in its open
409 :c:func:`usb_autopm_put_interface` in its clos
410 patterns are possible.
411
412 The autosuspend attempts mentioned above will
413 reason or another. For example, the ``power/c
414 set to ``on``, or another interface in the sam
415 idle. This is perfectly normal. If the reaso
416 the device hasn't been idle for long enough, a
417 carry out the operation automatically when the
418 has expired.
419
420 Autoresume attempts also can fail, although fa
421 the device is no longer present or operating p
422 autosuspend, there's no idle-delay for an auto
423
424
425 Other parts of the driver interface
426 -----------------------------------
427
428 Drivers can enable autosuspend for their devic
429
430 usb_enable_autosuspend(struct usb_devi
431
432 in their :c:func:`probe` routine, if they know
433 suspending and resuming correctly. This is ex
434 writing ``auto`` to the device's ``power/contr
435 drivers can disable autosuspend by calling::
436
437 usb_disable_autosuspend(struct usb_dev
438
439 This is exactly the same as writing ``on`` to
440
441 Sometimes a driver needs to make sure that rem
442 during autosuspend. For example, there's not
443 autosuspending a keyboard if the user can't ca
444 remote wakeup by typing on it. If the driver
445 ``intf->needs_remote_wakeup`` to 1, the kernel
446 device if remote wakeup isn't available. (If
447 autosuspended, though, setting this flag won't
448 autoresume it. Normally a driver would set th
449 method, at which time the device is guaranteed
450 autosuspended.)
451
452 If a driver does its I/O asynchronously in int
453 should call :c:func:`usb_autopm_get_interface_
454 :c:func:`usb_autopm_put_interface_async` when
455 it receives an input event, it should call::
456
457 usb_mark_last_busy(struct usb_device *
458
459 in the event handler. This tells the PM core
460 busy and therefore the next autosuspend idle-d
461 be pushed back. Many of the usb_autopm_* rout
462 so drivers need to worry only when interrupt-d
463
464 Asynchronous operation is always subject to ra
465 driver may call the :c:func:`usb_autopm_get_in
466 when the core has just finished deciding the d
467 long enough but not yet gotten around to calli
468 method. The ``suspend`` method must be respon
469 the I/O request routine and the URB completion
470 cause autosuspends to fail with -EBUSY if the
471 device.
472
473 External suspend calls should never be allowed
474 only autosuspend calls. The driver can tell t
475 the :c:func:`PMSG_IS_AUTO` macro to the messag
476 method; it will return True for internal PM ev
477 False for external PM events.
478
479
480 Mutual exclusion
481 ----------------
482
483 For external events -- but not necessarily for
484 autoresume -- the device semaphore (udev->dev.
485 ``suspend`` or ``resume`` method is called. T
486 suspend/resume events are mutually exclusive w
487 ``disconnect``, ``pre_reset``, and ``post_rese
488 this is true of autosuspend/autoresume events
489
490 If a driver wants to block all suspend/resume
491 critical section, the best way is to lock the
492 :c:func:`usb_autopm_get_interface` (and do the
493 critical section). Holding the device semapho
494 external PM calls, and the :c:func:`usb_autopm
495 internal PM calls, even if it fails. (Exercis
496
497
498 Interaction between dynamic PM and system PM
499 --------------------------------------------
500
501 Dynamic power management and system power mana
502 a couple of ways.
503
504 Firstly, a device may already be autosuspended
505 occurs. Since system suspends are supposed to
506 possible, the device should remain suspended f
507 resume. But this theory may not work out well
508 the kernel's behavior in this regard has chang
509 policy is to resume all devices during a syste
510 handle their own runtime suspends afterward.
511
512 Secondly, a dynamic power-management event may
513 suspend is underway. The window for this is s
514 suspends don't take long (a few seconds usuall
515 For example, a suspended device may send a rem
516 the system is suspending. The remote wakeup m
517 cause the system suspend to abort. If the rem
518 succeed, it may still remain active and thus c
519 resume as soon as the system suspend is comple
520 wakeup may fail and get lost. Which outcome o
521 and on the hardware and firmware design.
522
523
524 xHCI hardware link PM
525 ---------------------
526
527 xHCI host controller provides hardware link po
528 (xHCI 1.0 feature) and usb3.0 devices which su
529 enabling hardware LPM, the host can automatica
530 lower power state(L1 for usb2.0 devices, or U1
531 which state device can enter and resume very q
532
533 The user interface for controlling hardware LP
534 ``power/`` subdirectory of each USB device's s
535 ``/sys/bus/usb/devices/.../power/`` where "...
536 relevant attribute files are ``usb2_hardware_l
537
538 ``power/usb2_hardware_lpm``
539
540 When a USB2 device which suppo
541 xHCI host root hub which suppo
542 host will run a software LPM t
543 enters L1 state and resume suc
544 supports USB2 hardware LPM, th
545 driver will enable hardware LP
546 can write y/Y/1 or n/N/0 to th
547 USB2 hardware LPM manually. Th
548
549 ``power/usb3_hardware_lpm_u1``
550 ``power/usb3_hardware_lpm_u2``
551
552 When a USB 3.0 lpm-capable dev
553 xHCI host which supports link
554 and U2 exit latencies have bee
555 descriptor; if the check is pa
556 supports USB3 hardware LPM, US
557 enabled for the device and the
558 The files hold a string value
559 indicating whether or not USB3
560 is enabled for the device.
561
562 USB Port Power Control
563 ----------------------
564
565 In addition to suspending endpoint devices and
566 controlled link power management, the USB subs
567 capability to disable power to ports under som
568 controlled through ``Set/ClearPortFeature(PORT
569 In the case of a root or platform-internal hub
570 driver translates ``PORT_POWER`` requests into
571 method calls to set the port power state. For
572 Linux Plumbers Conference 2012 slides [#f1]_ a
573
574 Upon receiving a ``ClearPortFeature(PORT_POWER
575 logically off, and may trigger the actual loss
576 VBUS may be maintained in the case where a hub
577 a shared power well causing power to remain un
578 are turned off. VBUS may also be maintained b
579 a charging application. In any event a logica
580 connection with its device, not respond to hot
581 respond to remote wakeup events.
582
583 .. warning::
584
585 turning off a port may result in the inabil
586 Please see "User Interface for Port Power C
587
588 As far as the effect on the device itself it i
589 goes through during system suspend, i.e. the p
590 USB device or driver that misbehaves with syst
591 similarly affected by a port power cycle event
592 implementation shares the same device recovery
593 quirks) as the system resume path for the hub.
594
595 .. [#f1]
596
597 http://dl.dropbox.com/u/96820575/sarah-sharp
598
599 .. [#f2]
600
601 http://linuxplumbers.ubicast.tv/videos/usb-p
602
603 .. [#f3]
604
605 USB 3.1 Section 10.12
606
607 wakeup note: if a device is configured to se
608 power control implementation will block powe
609 port.
610
611
612 User Interface for Port Power Control
613 -------------------------------------
614
615 The port power control mechanism uses the PM r
616 requested by clearing the ``power/pm_qos_no_po
617 (defaults to 1). If the port is disconnected
618 ``ClearPortFeature(PORT_POWER)`` request. Oth
619 runtime rules and require the attached child d
620 suspended. This mechanism is dependent on the
621 switching in its hub descriptor (wHubCharacter
622 mode field).
623
624 Note, some interface devices/drivers do not su
625 need to unbind the interface drivers before th
626 suspend. An unbound interface device is suspe
627 be careful to unbind interface drivers, not th
628 device. Also, leave hub interface drivers bou
629 device (not interface) is unbound the kernel i
630 device. If a hub interface driver is unbound,
631 lost and all attached child-devices will disco
632 that if the 'driver/module' link for a device
633 ``/sys/module/usbcore`` then unbinding it will
634 control.
635
636 Example of the relevant files for port power c
637 these files are relative to a usb hub device (
638
639 prefix=/sys/devices/pci0000:00/0000:00:14
640
641 attached child device +
642 hub port device + |
643 hub interface device + | |
644 v v v
645 $prefix/3-1:1.0/3-1-port1/de
646
647 $prefix/3-1:1.0/3-1-port1/power/pm_qos_no
648 $prefix/3-1:1.0/3-1-port1/device/power/co
649 $prefix/3-1:1.0/3-1-port1/device/3-1.1:<i
650 $prefix/3-1:1.0/3-1-port1/device/3-1.1:<i
651 ...
652 $prefix/3-1:1.0/3-1-port1/device/3-1.1:<i
653
654 In addition to these files some ports may have
655 another hub. The expectation is that all supe
656 hi-speed peer::
657
658 $prefix/3-1:1.0/3-1-port1/peer -> ../../../.
659 ../../../../usb2/2-1/2-1:1.0/2-1-port1/peer
660
661 Distinct from 'companion ports', or 'ehci/xhci
662 peer ports are simply the hi-speed and supersp
663 are combined into a single usb3 connector. Pe
664 ancestor XHCI device.
665
666 While a superspeed port is powered off a devic
667 connection and attempt to connect to the hi-sp
668 implementation takes steps to prevent this:
669
670 1. Port suspend is sequenced to guarantee that
671 before their superspeed peer is permitted t
672 that the setting ``pm_qos_no_power_off`` to
673 not cause the port to power-off until its h
674 runtime suspend state. Userspace must take
675 if it wants to guarantee that a superspeed
676
677 2. Port resume is sequenced to force a supersp
678 highspeed peer.
679
680 3. Port resume always triggers an attached chi
681 power session is lost the device may have b
682 Resuming the child device when the parent p
683 states and clamps the maximum port power cy
684 child device can suspend (autosuspend-delay
685 latency).
686
687 Sysfs files relevant for port power control:
688
689 ``<hubdev-portX>/power/pm_qos_no_power
690 This writable flag controls th
691 Once all children and descenda
692 port may suspend/poweroff prov
693 pm_qos_no_power_off is '0'. I
694 '1' the port will remain activ
695 the stats of descendants. Def
696
697 ``<hubdev-portX>/power/runtime_status`
698 This file reflects whether the
699 or 'suspended' (logically off)
700 userspace whether VBUS is stil
701
702 ``<hubdev-portX>/connect_type``:
703 An advisory read-only flag to
704 location and connection type o
705 one of four values 'hotplug',
706 and 'unknown'. All values, be
707 platform firmware.
708
709 ``hotplug`` indicates an exter
710 port on the platform. Typical
711 to keep such a port powered to
712 connection events.
713
714 ``hardwired`` refers to a port
715 connectable. Examples are inte
716 bluetooth that can be disconne
717 switch or a port with a hardwi
718 expected to be safe to allow t
719 provided pm_qos_no_power_off i
720 switch that gates connections.
721 for the device to be connected
722 powering off, or to activate t
723 connection via a switch.
724
725 ``not used`` refers to an inte
726 to never have a device connect
727 empty internal ports, or ports
728 exposed on a platform. Consid
729 powered-off at all times.
730
731 ``unknown`` means platform fir
732 information for this port. Mo
733 external hub ports which shoul
734 for policy decisions.
735
736 .. note::
737
738 - since we are relying
739 information correct,
740 be missing or wrong.
741
742 - Take care in clearin
743 power is off this po
744 not respond to new c
745
746 Once a child device is attached additi
747 applied before the port is allowed to
748
749 ``<child>/power/control``:
750 Must be ``auto``, and the port
751 power down until ``<child>/pow
752 reflects the 'suspended' state
753 value is controlled by child d
754
755 ``<child>/power/persist``:
756 This defaults to ``1`` for mos
757 kernel can persist the device'
758 power session loss (suspend /
759 this value is ``0`` (quirky de
760 disabled.
761
762 ``<child>/driver/unbind``:
763 Wakeup capable devices will bl
764 this time the only mechanism t
765 wakeup-capability for an inter
766 its driver.
767
768 Summary of poweroff pre-requisite settings rel
769
770 echo 0 > power/pm_qos_no_power_off
771 echo 0 > peer/power/pm_qos_no_power_of
772 echo auto > power/control # this is th
773 echo auto > <child>/power/control
774 echo 1 > <child>/power/persist # this
775
776 Suggested Userspace Port Power Policy
777 -------------------------------------
778
779 As noted above userspace needs to be careful a
780 ports are enabled for poweroff.
781
782 The default configuration is that all ports st
783 ``power/pm_qos_no_power_off`` set to ``1`` cau
784 active.
785
786 Given confidence in the platform firmware's de
787 (ACPI _PLD record for a port populates 'connec
788 clear pm_qos_no_power_off for all 'not used' p
789 done for 'hardwired' ports provided poweroff i
790 connection switch for the port.
791
792 A more aggressive userspace policy is to enabl
793 all ports (set ``<hubdev-portX>/power/pm_qos_n
794 some external factor indicates the user has st
795 system. For example, a distro may want to ena
796 ports when the screen blanks, and re-power the
797 active. Smart phones and tablets may want to
798 the user pushes the power button.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.