Lines Matching full:will
41 document will not discuss those other forms.)
77 LAN"; we will refer to it generically as "remote wakeup". When a
111 kernel will automatically resume the device (autoresume). For the
112 same reason, an autosuspended device will usually have remote wakeup
142 ``control`` file. In 2.6.38 the ``autosuspend`` file will be deprecated
154 whether or not remote wakeup will be enabled when the
181 before the kernel will autosuspend it (the idle-delay
233 then each new USB device will have its autosuspend idle-delay
235 will not be affected.)
237 Setting the initial default idle-delay to -1 will prevent any
264 any widespread programs which will do this; we hope that in the near
265 future device managers such as HAL will take on this added
281 causing the keyboard to do a remote wakeup all right, will nonetheless
283 of them will issue a remote-wakeup request in response to button
286 The kernel will not prevent you from enabling autosuspend on devices
307 negative error code, the suspend will be aborted. Normally
308 the driver will return 0, in which case it must cancel all
319 (although the interfaces will be in the same altsettings as
323 the ``disconnect`` method will be called instead of the ``resume`` or
335 the resume. Later kernels will call the driver's ``disconnect`` method;
368 then the interface is deemed to be busy, and the kernel will not
374 counter. Unbalanced "get"s will remain in effect when a driver is
399 device will generally not yet be in the desired state.
412 The autosuspend attempts mentioned above will often fail for one
476 method; it will return True for internal PM events (autosuspend) and
484 autoresume -- the device semaphore (udev->dev.sem) will be held when a
493 critical section). Holding the device semaphore will block all
494 external PM calls, and the :c:func:`usb_autopm_get_interface` will prevent any
542 host will run a software LPM test for it; if the device
544 supports USB2 hardware LPM, this file will show up and
545 driver will enable hardware LPM for the device. You
553 xHCI host which supports link PM, it will check if U1
556 supports USB3 hardware LPM, USB3 hardware LPM will be
557 enabled for the device and these files will be created.
579 a charging application. In any event a logically off port will lose
590 USB device or driver that misbehaves with system suspend will be
608 power control implementation will block poweroff attempts on that
617 (defaults to 1). If the port is disconnected it will immediately receive a
618 ``ClearPortFeature(PORT_POWER)`` request. Otherwise, it will honor the pm
625 need to unbind the interface drivers before the :c:type:`usb_device` will
631 lost and all attached child-devices will disconnect. A good rule of thumb is
633 ``/sys/module/usbcore`` then unbinding it will interfere with port power
675 if it wants to guarantee that a superspeed port will power-off.
694 '1' the port will remain active/powered regardless of
743 power is off this port will
750 Must be ``auto``, and the port will not
763 Wakeup capable devices will block port poweroff. At