Searched full:follows (Results 1 – 25 of 1201) sorted by relevance
12345678910>>...49
| /Linux-v5.10/drivers/staging/greybus/ |
| D | Kconfig | 8 Select this option if you have a device that follows the
29 Select this option if you have a device that follows the
39 Select this option if you have a device that follows the
49 Select this option if you have a device that follows the
59 Select this option if you have a device that follows the
69 Select this option if you have a device that follows the
78 Select this option if you have a device that follows the
87 Select this option if you have a device that follows the
97 Select this option if you have a device that follows the
106 Select this option if you have a device that follows the
[all …]
|
| /Linux-v5.10/arch/x86/include/asm/ |
| D | sigframe.h | 38 /* fp state follows here */
53 /* fp state follows here */
63 /* fp state follows here */
81 /* fp state follows here */
|
| /Linux-v5.10/Documentation/devicetree/bindings/display/panel/ |
| D | lvds.yaml | 49 LVDS data mappings are defined as follows.
52 [VESA] specifications. Data are transferred as follows on 3 LVDS lanes.
63 specifications. Data are transferred as follows on 4 LVDS lanes.
75 Data are transferred as follows on 4 LVDS lanes.
86 Control signals are mapped as follows.
|
| /Linux-v5.10/Documentation/devicetree/bindings/soc/bcm/ |
| D | brcm,bcm2835-pm.txt | 17 - #reset-cells: Should be 1. This property follows the reset controller
19 - #power-domain-cells: Should be 1. This property follows the power domain
26 system power. This node follows the power controller bindings[3].
|
| /Linux-v5.10/drivers/gpu/drm/gma500/ |
| D | oaktrail.h | 77 u16 Panel_Backlight_Inverter_Descriptor;/* 16 bits, as follows */
81 /*16 bits, Defined as follows: */
106 u16 Panel_Backlight_Inverter_Descriptor;/*16 bits, as follows*/
111 /*16 bits, Defined as follows: */
147 union { /*8 bits,Defined as follows: */
164 union { /*8 bits,Defined as follows: */
|
| /Linux-v5.10/tools/perf/Documentation/ |
| D | jitdump-specification.txt | 48 The flags currently defined are as follows:
53 …ollowed by records. Each record starts with a fixed size header describing the record that follows.
55 The record header is specified in order as follows:
126 The debug_entry describes the source line information. It is defined as follows in order:
164 The EH Frame header follows the Linux Standard Base (LSB) specification as described in the documen…
167 The EH Frame follows the LSB specicfication as described in the document at https://refspecs.linuxb…
|
| /Linux-v5.10/Documentation/devicetree/bindings/scsi/ |
| D | hisilicon-sas.txt | 6 - compatible : value should be as follows:
22 sources; the interrupts are ordered in 3 groups, as follows:
35 Fatal interrupts : the fatal interrupts are ordered as follows:
39 the interrupts are ordered in 3 groups, as follows:
|
| /Linux-v5.10/Documentation/RCU/ |
| D | rcubarrier.rst | 38 context might then be as follows::
44 IRQ context. The function p_callback() might be defined as follows::
85 Pseudo-code using rcu_barrier() is as follows:
104 as follows::
214 The original code for rcu_barrier() was as follows::
240 to post an RCU callback, as follows::
262 reaches zero, as follows::
|
| D | lockdep-splat.rst | 68 Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows::
78 which would permit us to invoke rcu_dereference_protected as follows::
93 add rcu_read_lock() and rcu_read_unlock() as follows::
110 by rcu_access_pointer() as follows::
|
| D | listRCU.rst | 78 implementation of ``audit_filter_task()`` might be as follows::
102 This means that RCU can be easily applied to the read side, as follows::
127 might be used as follows for deletion and insertion::
212 if it did, the reader-writer-locked code to do so might look as follows
241 RCU (*read-copy update*) its name. The RCU code is as follows::
305 audit_entry structure, and modify ``audit_filter_task()`` as follows::
336 spinlock as follows::
|
| /Linux-v5.10/Documentation/devicetree/bindings/input/ |
| D | iqs269a.yaml | 47 Specifies the power mode during suspend as follows:
172 Specifies the inductive sensing excitation frequency as follows (paren-
189 long-term average) of an associated channel as follows:
274 Specifies the capacitance to be added to the channel as follows:
291 sensing as follows:
302 Specifies the channel's sensing mode as follows:
314 Specifies the channel's sensing frequency as follows (parenthesized
330 Specifies the channel's ATI mode as follows:
|
| /Linux-v5.10/include/linux/sunrpc/ |
| D | rpc_rdma.h | 135 * Pointer to the XDR position that follows the encoded RDMA segment
154 * Pointer to the XDR position that follows the encoded Read segment
172 * Pointer to the XDR item that follows the RDMA segment
191 * Pointer to the XDR item that follows the Read segment
|
| /Linux-v5.10/Documentation/bpf/ |
| D | s390.rst | 36 Once on Debian, the build prerequisites can be installed as follows::
62 Latest Clang targeting BPF can be installed as follows::
130 The virtual machine can be started as follows::
153 need to be mounted as follows::
|
| D | prog_flow_dissector.rst | 98 The takeaway here is as follows: BPF flow dissector program can be called with
108 ``flow_keys->flags`` might contain optional input flags that work as follows:
129 The reference implementation is organized as follows:
|
| /Linux-v5.10/arch/powerpc/kernel/ptrace/ |
| D | ptrace-tm.c | 80 * The userspace interface buffer layout is as follows.
127 * The userspace interface buffer layout is as follows.
221 * The userspace interface buffer layout is as follows.
265 * FPR registers. The userspace interface buffer layout is as follows.
333 * layout is as follows.
384 * layout is as follows.
462 * The userspace interface buffer layout is as follows.
505 * FPR registers. The userspace interface buffer layout is as follows.
565 * The userspace interface buffer layout is as follows.
607 * The userspace interface buffer layout is as follows.
|
| /Linux-v5.10/drivers/clk/sunxi/ |
| D | clk-sun9i-core.c | 19 * PLL4 rate is calculated as follows
95 * GT rate is calculated as follows
150 * AHB rate is calculated as follows
230 * APB1 rate is calculated as follows
|
| /Linux-v5.10/Documentation/devicetree/bindings/gpio/ |
| D | sodaville.txt | 13 The interrupt specifier consists of two cells encoded as follows:
15 - <2nd cell>: The level-sense information, encoded as follows:
|
| D | gpio-axp209.txt | 3 This driver follows the usual GPIO bindings found in
6 This driver follows the usual pinctrl bindings found in
|
| /Linux-v5.10/Documentation/hwmon/ |
| D | hwmon-kernel-api.rst | 116 The hwmon_chip_info structure looks as follows::
156 defined as follows::
233 The remaining declarations are as follows.
247 is defined in include/linux/hwmon.h. Definition prefixes are as follows.
266 and return values for those functions are as follows::
377 variable, which is defined as follows::
|
| /Linux-v5.10/tools/lib/subcmd/ |
| D | run-command.h | 25 * - Specify -1 to have a pipe allocated as follows:
32 * - Specify > 0 to set a channel to a particular FD as follows:
|
| /Linux-v5.10/Documentation/kbuild/ |
| D | kconfig-macro-language.rst | 14 can write a makefile like follows::
24 and handles as if the source file were input like follows::
156 to make "info" function print " hello", you can write like follows::
241 Instead, you can do like follows so that any function call is statically
|
| /Linux-v5.10/Documentation/driver-api/gpio/ |
| D | board.rst | 145 A lookup table can then be defined as follows, with an empty entry defining its
163 And the table can be added by the board code as follows::
167 The driver controlling "foo.0" will then be able to obtain its GPIOs as follows::
195 And the table can be added to the board code as follows::
|
| /Linux-v5.10/arch/alpha/include/asm/ |
| D | user.h | 15 * are as follows:
23 * data: The data segment follows next. We use current->end_text to
|
| /Linux-v5.10/Documentation/sound/soc/ |
| D | pops-clicks.rst | 23 shutdown and follows some basic rules:-
38 ADC until all the pops have occurred. This follows similar power rules to
|
| /Linux-v5.10/arch/powerpc/include/asm/ |
| D | user.h | 14 * are as follows:
22 * data: The data segment follows next. We use current->end_text to
|
12345678910>>...49
