| /Documentation/leds/ |
| D | ledtrig-transient.rst | 7 specifying how long a state to be on, and the second for how long the state
9 in on state, followed by a delay_off value that specifies how long the LED
10 should stay in off state. The on and off cycle repeats until the trigger
12 features that require an on or off state to be held just once and then stay in
13 the original state forever.
16 set a timer to hold a state, however when user space application crashes or
18 state permanently.
27 class device, the LED state does not change.
30 trigger will be called, and LED state is changed to LED_OFF.
32 Driver suspend changes the LED state to LED_OFF and resume doesn't change
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-class-led-trigger-netdev | 26 Signal the link state of the named network device.
28 If set to 0 (default), the LED's normal state is off.
30 If set to 1, the LED's normal state reflects the link state
32 Setting this value also immediately changes the LED state.
83 Signal the link speed state of 10Mbps of the named network device.
85 If set to 0 (default), the LED's normal state is off.
87 If set to 1, the LED's normal state reflects the link state
89 Setting this value also immediately changes the LED state.
98 Signal the link speed state of 100Mbps of the named network device.
100 If set to 0 (default), the LED's normal state is off.
[all …]
|
| D | sysfs-class-android_usb | 3 What: /sys/class/android_usb/<android_device>/state
7 The state of the USB connection. This attribute is likely
8 redundant with the /sys/class/UDC/state attribute, and should
10 Change on the state will also generate uevent KOBJ_CHANGE on
11 the port with the new state included in the message as
12 "USB_STATE=<STATE>". Note this is not the correct usage of
|
| D | sysfs-class-extcon | 31 What: /sys/class/extcon/.../state
35 The /sys/class/extcon/.../state shows and stores the cable
44 # cat state
54 In order to update the state of an extcon device, enter a hex
55 state number starting with 0x::
57 # echo 0xHEX > state
59 This updates the whole state of the extcon device.
63 It is recommended to use this "global" state interface if
64 you need to set the value atomically. The later state
75 What: /sys/class/extcon/.../cable.X/state
[all …]
|
| D | sysfs-class-remoteproc | 10 stopped (using /sys/class/remoteproc/.../state) and write a new filename.
12 What: /sys/class/remoteproc/.../state
15 Description: Remote processor state
17 Reports the state of the remote processor, which will be one of:
30 "running" is the normal state of an available remote processor
36 unknown state.
38 Writing this file controls the state of the remote processor.
47 transition to "running" state.
50 return it to the "offline" state.
60 up the usage in modifying the 'firmware' or 'state' files.
[all …]
|
| /Documentation/devicetree/bindings/powerpc/opal/ |
| D | power-mgt.txt | 10 Typically each idle state has the following associated properties:
12 - name: The name of the idle state as defined by the firmware.
15 extent of state-loss, whether timebase is stopped on this
18 - exit-latency: The latency involved in transitioning the state of the
22 this idle state in order to accrue power-savings
29 provides the value of that property for the idle state associated with
33 "ibm,cpu-idle-state-names" and "ibm,cpu-idle-state-flags" are
37 - ibm,cpu-idle-state-names:
40 - ibm,cpu-idle-state-flags:
49 0x00010000 /* This is a nap state (POWER7,POWER8) */
[all …]
|
| /Documentation/livepatch/ |
| D | system-state.rst | 2 System State Changes
14 change the system behavior or state so that it is no longer safe to
19 This is where the livepatch system state tracking gets useful. It
22 - store data needed to manipulate and restore the system state
28 1. Livepatch system state API
31 The state of the system might get modified either by several livepatch callbacks
35 Each modified state is described by struct klp_state, see
46 - Non-zero number used to identify the affected system state.
50 - Number describing the variant of the system state change that
53 The state can be manipulated using two functions:
[all …]
|
| /Documentation/core-api/ |
| D | cpu_hotplug.rst | 112 off (0) state. To logically shutdown CPU4::
135 at state ``CPUHP_OFFLINE``. This includes:
151 CPU hotplug state machine
154 CPU hotplug uses a trivial state machine with a linear state space from
155 CPUHP_OFFLINE to CPUHP_ONLINE. Each state has a startup and a teardown
159 the state CPUHP_ONLINE is reached. They can also be invoked when the
160 callbacks of a state are set up or an instance is added to a multi-instance
161 state.
164 order sequentially until the state CPUHP_OFFLINE is reached. They can also
165 be invoked when the callbacks of a state are removed or an instance is
[all …]
|
| D | entry.rst | 4 All transitions between execution domains require state updates which are
5 subject to strict ordering constraints. State updates are required for the
23 watching. In addition, many architectures must save and restore register state,
52 restrictions and is useful to protect e.g. state switching which would
56 state transitions must run with interrupts disabled.
62 after establishing low-level architecture-specific state and stack frames. This
82 establishes state in the following order:
95 that it invokes exit_to_user_mode() which again handles the state
120 The state operations have the same ordering.
138 exit handling is slightly different. RCU state is only updated when the
[all …]
|
| /Documentation/admin-guide/cgroup-v1/ |
| D | freezer-subsystem.rst | 16 quiescent state. Once the tasks are quiescent another task can
58 cgroup has its own state (self-state) and the state inherited from the
59 parent (parent-state). Iff both states are THAWED, the cgroup is
64 * freezer.state: Read-write.
66 When read, returns the effective state of the cgroup - "THAWED",
70 FREEZING cgroup transitions into FROZEN state when all tasks
76 When written, sets the self-state of the cgroup. Two values are
78 if not already freezing, enters FREEZING state along with all its
81 If THAWED is written, the self-state of the cgroup is changed to
82 THAWED. Note that the effective state may not change to THAWED if
[all …]
|
| /Documentation/arch/arm/ |
| D | cluster-pm-race-avoidance.rst | 48 Each cluster and CPU is assigned a state, as follows:
71 The CPU or cluster has committed to moving to the UP state.
77 level. A CPU in this state is not necessarily being used
82 state. It may be part way through the process of teardown and
87 The CPU states are described in the "CPU state" section, below.
89 Each cluster is also assigned a state, but it is necessary to split the
90 state value into two parts (the "cluster" state and "inbound" state) and
92 CPUs in the cluster simultaneously modifying the state. The cluster-
93 level states are described in the "Cluster state" section.
96 discussion, the state names are given a `CPU_` prefix for the CPU states,
[all …]
|
| /Documentation/devicetree/bindings/regulator/ |
| D | rohm,bd71815-regulator.yaml | 52 GPIO used to control ldo4 state (when ldo4 is controlled by GPIO).
56 PMIC "RUN" state voltage in uV when PMIC HW states are used. See
58 regulator should be disabled at RUN state.
65 Whether to keep regulator enabled at "SNVS" state or not.
66 0 means regulator should be disabled at SNVS state, non zero voltage
69 state (from which the PMIC transitioned to SNVS).
76 PMIC "SUSPEND" state voltage in uV when PMIC HW states are used. See
78 regulator should be disabled at SUSPEND state.
85 PMIC "LPSR" state voltage in uV when PMIC HW states are used. See
87 regulator should be disabled at LPSR state.
[all …]
|
| /Documentation/devicetree/bindings/power/ |
| D | domain-idle-state.yaml | 4 $id: http://devicetree.org/schemas/power/domain-idle-state.yaml#
13 A domain idle state node represents the state parameters that will be used to
14 select the state when there are no active components in the PM domain.
25 Each state node represents a domain idle state description.
29 const: domain-idle-state
34 state. Note that, the exit-latency-us duration may be guaranteed only
40 state.
45 state will yield power benefits, after overcoming the overhead while
46 entering the idle state.
70 compatible = "domain-idle-state";
|
| /Documentation/devicetree/bindings/mux/ |
| D | mux-controller.yaml | 19 A mux controller provides a number of states to its consumers, and the state
28 specifier using the '#mux-control-cells' or '#mux-state-cells' property.
29 The value of '#mux-state-cells' will always be one greater than the value
32 Optionally, mux controller nodes can also specify the state the mux should
33 have when it is idle. The idle-state property is used for this. If the
34 idle-state is not present, the mux controller is typically left as is when
36 idle-state property is an array with one idle state for each mux controller.
42 state for a mux controller with a higher index.
45 multiplexer. Using this disconnected high-impedance state as the idle state
46 is indicated with idle state (-2).
[all …]
|
| /Documentation/device-mapper/ |
| D | dm-bow.txt | 5 data that is overwritten. The changes can then be committed by a simple state
9 dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.
10 It is only possible to go from state 0 (initial state) to state 1, and then from
11 state 1 to state 2.
13 State 0: dm_bow collects all trims to the device and assumes that these mark
16 FITRIM ioctl on the file system then switch to state 1. These trims are not
19 State 1: All writes to the device cause the underlying data to be backed up to
22 without dm_bow, so the device is always in a good final state. The exception is
24 we are in this state and to allow rollback. See below for all details. If there
27 State 2: The transition to state 2 triggers replacing the special sector 0 with
[all …]
|
| /Documentation/admin-guide/pm/ |
| D | sleep-states.rst | 35 working state), such that the processors can spend time in their deepest idle
38 The system is woken up from this state by in-band interrupts, so theoretically
39 any devices that can cause interrupts to be generated in the working state can
42 This state can be used on platforms without support for :ref:`standby <standby>`
52 This state, if supported, offers moderate, but real, energy savings, while
53 providing a relatively straightforward transition back to the working state. No
54 operating state is lost (the system core logic retains power), so the system can
60 are suspended during transitions into this state. For this reason, it should
62 the resume latency will generally be greater than for that state.
64 The set of devices that can wake up the system from this state usually is
[all …]
|
| D | strategies.rst | 20 designated devices, triggering a transition to the ``working state`` in which
22 is affected by the state changes, this strategy is referred to as the
25 The other strategy, referred to as the :doc:`working-state power management
26 <working-state>`, is based on adjusting the power states of individual hardware
27 components of the system, as needed, in the working state. In consequence, if
28 this strategy is in use, the working state of the system usually does not
41 state from the physical system configuration and power draw perspective, but
43 for the same system in a sleep state. However, transitions from sleep states
44 back to the working state can only be started by a limited set of devices, so
45 typically the system can spend much more time in a sleep state than it can be
[all …]
|
| D | cpuidle.rst | 44 enter an idle state, that applies to the processor as a whole.
52 enter an idle state, that applies to the core that asked for it in the first
57 remaining core asks the processor to enter an idle state, that may trigger it
58 to put the whole larger unit into an idle state which also will affect the
69 time management perspective and if the processor is asked to enter an idle state
72 core also have asked the processor to enter an idle state. In that situation,
73 the core may be put into an idle state individually or a larger unit containing
74 it may be put into an idle state as a whole (if the other cores within the
106 idle states, or there is not enough time to spend in an idle state before the
119 idle time management subsystem called ``CPUIdle`` to select an idle state for
[all …]
|
| /Documentation/networking/ |
| D | xfrm_proc.rst | 32 No state is found
47 State is expired
50 State has mismatch option
54 State is invalid
71 State hasn't been fully acquired before use
77 …State direction mismatch (lookup found an output state on the input path, expected input or no dir…
91 No state is found
104 State is expired
116 State is invalid, perhaps expired
119 …State direction mismatch (lookup found an input state on the output path, expected output or no di…
|
| D | operstates.rst | 11 Linux distinguishes between administrative and operational state of an
12 interface. Administrative state is the result of "ip link set dev
19 to be performed before user data can be transferred. Operational state
23 influence operational state. To accommodate this, operational state is
25 a RFC2863 compatible state that is derived from these flags, a policy,
32 Both admin and operational state can be queried via the netlink
37 These values contain interface state:
43 Interface is in RFC2863 operational state UP or UNKNOWN. This is for
56 contains RFC2863 state of the interface in numeric representation:
59 Interface is in unknown state, neither driver nor userspace has set
[all …]
|
| /Documentation/trace/ |
| D | events-power.rst | 8 - Power state switch which reports events related to suspend (S-states),
18 1. Power state switch events
28 cpu_idle "state=%lu cpu_id=%lu"
29 cpu_frequency "state=%lu cpu_id=%lu"
36 machine_suspend "state=%lu"
39 Note: the value of '-1' or '4294967295' for state means an exit from the current state,
41 enters the idle state 4, while trace_cpu_idle(PWR_EVENT_EXIT, smp_processor_id())
42 means that the system exits the previous idle state.
44 The event which has 'state=4294967295' in the trace is very important to the user
45 space tools which are using it to detect the end of the current state, and so to
[all …]
|
| /Documentation/firmware-guide/acpi/ |
| D | acpi-lid.rst | 14 Platforms containing lids convey lid state (open/close) to OSPMs
16 Notify(lid_device, 0x80) to notify the OSPMs whenever the lid state has
18 report the "current" state of the lid as either "opened" or "closed".
30 The _LID control method is described to return the "current" lid state.
32 the lid state upon the last lid notification instead of returning the lid
33 state upon the last _LID evaluation. There won't be difference when the
37 There are platforms always return "closed" as initial lid state.
39 Restrictions of the lid state change notifications
42 There are buggy AML tables never notifying when the lid device state is
45 state is changed to "closed". The "closed" notification is normally used to
[all …]
|
| /Documentation/input/devices/ |
| D | rotary-encoder.rst | 16 a stable state with both outputs high (half-period mode) and some have
17 a stable state in all steps (quarter-period mode).
46 Events / state machine
49 In half-period mode, state a) and c) above are used to determine the
50 rotational direction based on the last stable state. Events are reported in
51 states b) and d) given that the new stable state is different from the last
56 a) Rising edge on channel A, channel B in low state
57 This state is used to recognize a clockwise turn
59 b) Rising edge on channel B, channel A in high state
60 When entering this state, the encoder is put into 'armed' state,
[all …]
|
| /Documentation/devicetree/bindings/pinctrl/ |
| D | pinctrl-bindings.txt | 4 such as pull-up/down, tri-state, drive-strength etc are designated as pin
15 need to reconfigure pins at run-time, for example to tri-state pins when the
21 for client device device tree nodes to map those state names to the pin
25 For example, a pin controller may set up its own "active" state when the
35 For each client device individually, every pin state is assigned an integer
36 ID. These numbers start at 0, and are contiguous. For each state ID, a unique
37 property exists to define the pin configuration. Each state may also be
42 defined in its device tree node, and whether to define the set of state
43 IDs that must be provided, or whether to define the set of state names that
51 controllers may be configured, or so that a state may be built
[all …]
|
| /Documentation/translations/zh_CN/core-api/ |
| D | cpu_hotplug.rst | 352 * cpuhp_setup_state(state, name, startup, teardown)
353 * cpuhp_setup_state_nocalls(state, name, startup, teardown)
354 * cpuhp_setup_state_cpuslocked(state, name, startup, teardown)
355 * cpuhp_setup_state_nocalls_cpuslocked(state, name, startup, teardown)
362 * cpuhp_setup_state_multi(state, name, startup, teardown)
429 * cpuhp_remove_state(state)
430 * cpuhp_remove_state_nocalls(state)
431 * cpuhp_remove_state_nocalls_cpuslocked(state)
432 * cpuhp_remove_multi_state(state)
458 * cpuhp_state_add_instance(state, node)
[all …]
|