Lines Matching full:may
55 leave the low-power state. This feature may be enabled or disabled
57 Ethernet drivers the ioctl interface used by ethtool may also be used
58 for this purpose); enabling it may cost some power usage, but let the
63 Devices may also be put into low-power states while the system is
68 device is on, it may be necessary to carry out some bus-specific
70 states at run time may require special handling during system-wide power
82 have been put into low-power states (at runtime), the effect may be very similar
89 drivers are no longer accepted. A given bus or platform may have different
193 wakeup" used by runtime power management, although it may be supported by the
196 they should be put into the full-power state. Those interrupts may or may not
267 In particular, this means that a device registration may fail if the parent of
311 The PM domain, type, class and bus callbacks may in turn invoke device- or
330 devices may be unregistered at any time.] Unlike the other
334 After the ``->prepare`` callback method returns, no new children may be
335 registered below the device. The method may also prepare the device or
343 prepare callback can be used to indicate to the PM core that it may
373 into account and it may only return a positive value from its own
378 performing I/O. They also may save the device registers and put it into
380 on, and they may enable wakeup events.
415 runtime PM may already have performed some or all of these steps.]
460 Note, however, that new children may be registered below the device as
465 number, the device may have been left in runtime suspend throughout the
468 ``resume_early``, ``resume`` phases of system resume may have been
471 suspend if necessary. [For example, it may need to queue up a runtime
476 the preceding ``->prepare`` and special actions may be required
483 However, the details here may again be platform-specific. For example,
491 This may be the hardest part, and the one most protected by NDA'd documents
495 that may not be the case (and usually isn't for ACPI-defined system sleep
505 These callbacks may return an error value, but the PM core will ignore such
530 generate IRQs or DMA, and they may need to save the values of device
600 in resuming from hibernation. In fact, the restore kernel may be completely
640 of the device may be different from the state remembered from the ``freeze``,
641 ``freeze_late`` and ``freeze_noirq`` phases. The device may even need to be
654 To handle these cases, subsystems and device drivers may register power
673 PCI device may not perform DMA or issue IRQs, and any wakeup events it
682 Some details here may be platform-specific. Systems may have devices that
688 Moreover, the specific actions taken may depend on the target system state.
705 property is often referred to as a power domain. A power domain may also be
729 Devices may be defined as IRQ-safe which indicates to the PM core that their
730 runtime PM callbacks may be invoked with disabled interrupts (see
757 In some cases the decision may be made at the subsystem level while in other
758 cases the device driver may be left to decide. In some cases it may be
776 suspend upfront in their ``->suspend`` callbacks, but that may not be really
780 :c:func:`dev_pm_set_driver_flags` helper. That also may cause middle-layer code
789 callbacks, if present, may still be invoked during the subsequent system-wide
790 resume transition and the device's runtime power management status may be set
810 devices will actually be left in suspend may depend on their state before the
817 indicate to the PM core if the device may be left in suspend by setting its