Searched full:follows (Results 1 – 25 of 1383) sorted by relevance
12345678910>>...56
| /Linux-v5.4/drivers/staging/greybus/ |
| D | Kconfig | 8 Select this option if you have a device that follows the
17 Select this option if you have a device that follows the
27 Select this option if you have a device that follows the
37 Select this option if you have a device that follows the
47 Select this option if you have a device that follows the
57 Select this option if you have a device that follows the
66 Select this option if you have a device that follows the
75 Select this option if you have a device that follows the
85 Select this option if you have a device that follows the
94 Select this option if you have a device that follows the
[all …]
|
| /Linux-v5.4/arch/x86/include/asm/ |
| D | sigframe.h | 42 /* fp state follows here */
57 /* fp state follows here */
67 /* fp state follows here */
85 /* fp state follows here */
|
| /Linux-v5.4/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.4/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.4/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.4/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.4/Documentation/RCU/ |
| D | listRCU.rst | 29 implementation of audit_filter_task() might be as follows::
53 This means that RCU can be easily applied to the read side, as follows::
78 lock might be used as follows for deletion and insertion::
164 follows (presumably, the field_count is only permitted to decrease,
192 RCU ("read-copy update") its name. The RCU code is as follows::
245 as follows::
276 flag under the spinlock as follows::
|
| D | lockdep-splat.txt | 63 Line 2776 of block/cfq-iosched.c in v3.0-rc5 is as follows:
73 which would permit us to invoke rcu_dereference_protected as follows:
88 add rcu_read_lock() and rcu_read_unlock() as follows:
105 by rcu_access_pointer() as follows:
|
| D | rcubarrier.txt | 35 context might then be as follows:
41 IRQ context. The function p_callback() might be defined as follows:
80 Pseudo-code using rcu_barrier() is as follows:
99 as follows:
203 The original code for rcu_barrier() was as follows:
229 to post an RCU callback, as follows:
251 reaches zero, as follows:
|
| D | rcuref.txt | 47 in this scenario as follows:
83 as follows:
133 delete(), so that el_free() can be subsumed into delete as follows:
|
| /Linux-v5.4/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.4/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.4/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.4/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.4/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.4/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.4/Documentation/driver-api/gpio/ |
| D | board.rst | 140 A lookup table can then be defined as follows, with an empty entry defining its
158 And the table can be added by the board code as follows::
162 The driver controlling "foo.0" will then be able to obtain its GPIOs as follows::
190 And the table can be added to the board code as follows::
|
| /Linux-v5.4/Documentation/bpf/ |
| 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.4/arch/powerpc/include/asm/ |
| D | user.h | 14 * are as follows:
22 * data: The data segment follows next. We use current->end_text to
|
| /Linux-v5.4/Documentation/devicetree/bindings/interrupt-controller/ |
| D | img,meta-intc.txt | 30 Interrupt specifiers consists of 2 cells encoded as follows:
35 encoded as follows:
|
| /Linux-v5.4/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.4/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.4/arch/sh/include/asm/ |
| D | user.h | 11 * linux we use the `trad-core' bfd). The file contents are as follows:
19 * data: The data segment follows next. We use current->end_text to
|
| /Linux-v5.4/Documentation/pcmcia/ |
| D | locking.rst | 69 The "main" struct pcmcia_socket is protected as follows (read-only fields
112 The "main" struct pcmcia_device is protected as follows (read-only fields
|
12345678910>>...56
