| /openbmc/u-boot/drivers/block/ |
| H A D | Kconfig | 11 A filesystem can be placed in each partition.
28 A filesystem can be placed in each partition.
40 A filesystem can be placed in each partition.
|
| /openbmc/linux/Documentation/devicetree/bindings/hwmon/ |
| H A D | npcm750-pwm-fan.txt | 29 Under fan subnode can be upto 8 child nodes, each child node representing a fan.
35 Required properties for each child node:
46 Optional property for each child node:
|
| /openbmc/linux/Documentation/networking/ |
| H A D | kcm.rst | 47 Similarly, in the receive path, messages are constructed on each TCP socket
54 for each bound TCP socket, this structure holds the state for constructing
238 parallelized). In an application, a KCM socket can be opened for each
250 each received message to a different KCM socket or steering each sent
259 2) Send a group of messages each with a sendmsg call, where all messages
265 same KCM socket during each TCP ready callback. The targeted KCM socket
266 changes at each receive ready callback on the KCM socket. The application
273 the TCP connection. Normally, this will be done by placing each
|
| /openbmc/linux/tools/memory-model/litmus-tests/ |
| H A D | README | 25 between each pairs of reads. In other words, is smp_mb()
27 the order of a pair of writes, where each write is to a different
33 between each pairs of reads. In other words, is anything at all
35 order of a pair of writes, where each write is to a different
54 load-buffering litmus test, where each process reads from one
59 litmus test, where each process reads from one of two variables then
172 each process exactly once, so litmus tests not fitting this description
176 sign ("+"), and one string for each process, separated by plus signs.
187 The strings used to identify the actions carried out by each process are
|
| /openbmc/linux/Documentation/usb/ |
| H A D | gadget_configfs.rst | 18 A gadget is seen by its host as a set of configurations, each of which contains
20 functions, each function representing e.g. a serial connection or a SCSI disk.
25 and which functions each configuration will provide.
62 For each gadget to be created its corresponding directory must be created::
83 for each language, e.g.::
121 for each language, e.g.::
136 The gadget will provide some functions, for each function its corresponding
158 At this moment a number of gadgets is created, each of which has a number of
382 all configurations, and in each configuration it iterates over all
|
| /openbmc/linux/Documentation/devicetree/bindings/sound/ |
| H A D | tdm-slot.txt | 7 dai-tdm-slot-width : Width in bits for each slot.
17 And for each specified driver, there could be one .of_xlate_tdm_slot_mask()
|
| H A D | nvidia,tegra20-ac97.txt | 7 - resets : Must contain an entry for each entry in reset-names.
11 - dmas : Must contain an entry for each entry in clock-names.
|
| /openbmc/linux/Documentation/devicetree/bindings/timer/ |
| H A D | ti,davinci-timer.txt | 6 timers, each half can operate in conjunction (chain mode) or independently
7 (unchained mode) of each other.
|
| /openbmc/linux/Documentation/admin-guide/device-mapper/ |
| H A D | dm-queue-length.rst | 9 Table parameters for each path: [<repeat_count>]
18 Status for each path: <status> <fail-count> <in-flight>
|
| /openbmc/linux/fs/sysfs/ |
| H A D | Kconfig | 12 kernel, such as the devices the kernel has discovered on each bus and
13 which driver each is bound to. sysfs can also be used to tune devices
|
| /openbmc/linux/Documentation/devicetree/bindings/spi/ |
| H A D | spi-img-spfi.txt | 7 - clocks: Must contain an entry for each entry in clock-names.
12 - dmas: Must contain an entry for each entry in dma-names.
|
| /openbmc/linux/Documentation/devicetree/bindings/regulator/ |
| H A D | pv88090.txt | 7 - regulators: A node that houses a sub-node for each regulator within the
9 values listed below. The content of each sub-node is defined by the
|
| /openbmc/qemu/ |
| H A D | LICENSE | 12 with the GNU General Public License, version 2. Hence each source file
23 specific licensing information in each source file.
|
| /openbmc/pldm/libpldmresponder/examples/fru/ |
| H A D | FRU_Master.json | 8 // field is the PLDM entity type for Board and CPU. For each FRU type,
9 // corresponding config JSON's are needed for each record. In the example
|
| /openbmc/linux/Documentation/devicetree/bindings/cpufreq/ |
| H A D | cpufreq-mediatek-hw.yaml | 26 each frequency domain. Each entry corresponds to
27 a register bank for each frequency domain present.
|
| /openbmc/linux/Documentation/devicetree/bindings/dma/ |
| H A D | sprd-dma.txt | 13 - clocks: Should contain a clock specifier for each entry in clock-names.
34 described in the dma.txt file, using a two-cell specifier for each channel.
|
| /openbmc/linux/Documentation/tools/rtla/ |
| H A D | rtla-timerlat.rst | 21 It also provides information for each noise via the **osnoise:** tracepoints.
24 of each tracer event occurrence. For further details, please refer to the
|
| /openbmc/linux/Documentation/devicetree/bindings/clock/ |
| H A D | pistachio-clock.txt | 28 - clocks: Must contain an entry for each clock in clock-names.
57 - clocks: Must contain an entry for each clock in clock-names.
85 - clocks: Must contain an entry for each clock in clock-names.
109 - clocks: Must contain an entry for each clock in clock-names.
|
| /openbmc/linux/Documentation/devicetree/bindings/display/imx/ |
| H A D | ldb.txt | 7 nodes describing each of the two LVDS encoder channels of the bridge.
15 interfaces as input for each LVDS channel.
32 The needed clock numbers for each are documented in
56 limitations, only one input port (port@[0,1]) can be used for each channel
|
| /openbmc/linux/Documentation/hid/ |
| H A D | amd-sfh-hid.rst | 49 sensor data. The layer, which binds each device (AMD SFH HID driver) identifies the device type and
51 each device. Once a device is registered with HID core, the callbacks provided via this struct are
60 on that allocates the DRAM address for each and every sensor and passes it to MP2-PCIe driver. On
61 enumeration of each sensor, client layer fills the HID Descriptor structure and HID input report
|
| /openbmc/linux/Documentation/networking/devlink/ |
| H A D | devlink-health.rst | 26 Device driver creates a "health reporter" per each error/health type.
29 For each registered health reporter a driver can issue error/health reports
31 Device driver can provide specific callbacks for each "health reporter", e.g.:
77 User can access/change each reporter's parameters and driver specific callbacks
|
| /openbmc/linux/Documentation/driver-api/driver-model/ |
| H A D | bus.rst | 56 iterated over, and the match callback is called for each device that
70 The LDM core provides helper functions for iterating over each list::
80 for each device or driver in the list. All list accesses are
82 count on each object in the list is incremented before the callback is
|
| /openbmc/linux/Documentation/block/ |
| H A D | null_blk.rst | 25 All of them have a completion queue for each core in the system.
60 2 Timer: Waits a specific period (completion_nsec) for each IO before
65 Combined with irqmode=2 (timer). The time each completion event must wait.
107 queue for each CPU node in the system.
|
| /openbmc/linux/Documentation/mm/ |
| H A D | multigen_lru.rst | 23 implementations. In the multi-gen LRU, each generation represents a
82 Evictable pages are divided into multiple generations for each
121 and calls ``walk_page_range()`` with each ``mm_struct`` on this list
122 to scan PTEs, and after each iteration, it increments ``max_seq``. For
162 An ``mm_struct`` list is maintained for each memcg, and an
167 ``walk_page_range()`` with each ``mm_struct`` on this list to scan
168 PTEs. When multiple page table walkers iterate the same list, each of
183 Searching the rmap for PTEs mapping each page on an LRU list (to test
220 varying memory pressure. It calculates a moving average for each new
226 since each node and memcg combination has an LRU of folios (see
[all …]
|
| /openbmc/openbmc-test-automation/ipmi/ |
| H A D | test_ipmi_fru_device.robot | 37 [Documentation] Read the FRU device configuration of each device
56 # Compare dbus dictionary each field, with IPMI FRU device fields for each FRU device.
178 # Gets response from FRU data and split each device.
184 # For each device, identify either Board Serial/Product Serial (whichever is available).
198 # Get each device and split field as key and value and append to a dictionary.
210 # Assign serial number as key for main dictionary and a each device detail as value.
225 # Execute DBUS Introspect Command for each device,
227 # if the IPMI FRU key matches the serial number of each device dbus response.
277 # With each IPMI FRU key, get the corresponding valid from dbus dictionary,
279 # validate each dbus field value with IPMI FRU field value.
|