Searched full:tree (Results 1 – 25 of 1177) sorted by relevance
12345678910>>...48
| /Documentation/devicetree/ |
| D | of_unittest.rst | 4 Open Firmware Device Tree Unittest
13 is attached to the live tree dynamically, independent of the machine's
23 from the unflattened device tree data structure. This interface is used by
30 The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
32 drivers/of/unittest.c. Currently, following Device Tree Source Include files
62 Un-flattened device tree structure:
64 Un-flattened device tree consists of connected device_node(s) in form of a tree
67 // following struct members are used to construct the tree
76 Figure 1, describes a generic structure of machine's un-flattened device tree
78 ``*parent``, that is used to traverse the tree in the reverse direction. So, at
[all …]
|
| D | changesets.rst | 8 in the live tree in such a way that either the full set of changes
10 through applying the changeset, then the tree will be rolled back to the
14 When a changeset is applied, all of the changes get applied to the tree
16 receiver sees a complete and consistent state of the tree when it
23 2. A number of DT tree change calls, of_changeset_attach_node(),
26 a set of changes. No changes to the active tree are made at this point.
30 3. of_changeset_apply() - Apply the changes to the tree. Either the
31 entire changeset will get applied, or if there is an error the tree will
|
| D | dynamic-resolution-notes.rst | 4 Device Tree Dynamic Resolver Notes
8 Device Tree resolver, residing in drivers/of/resolver.c
13 The resolver is given as an input an arbitrary tree compiled with the
19 1. Get the maximum device tree phandle value from the live tree + 1.
20 2. Adjust all the local phandles of the tree to resolve by that amount.
24 in the live tree. This is the label used to tag the node.
|
| D | usage-model.rst | 4 Linux and the Device Tree
7 The Linux usage model for device tree data
11 This article describes how Linux uses the device tree. An overview of
12 the device tree data format can be found on the device tree usage page
17 The "Open Firmware Device Tree", or simply Device Tree (DT), is a data
23 Structurally, the DT is a tree, or acyclic graph with named nodes, and
26 links from one node to another outside of the natural tree structure.
29 is defined for how data should appear in the tree to describe typical
48 Device Tree to discover the topology of the hardware at runtime, and
54 Device Tree.
[all …]
|
| /Documentation/ABI/testing/ |
| D | sysfs-devices | 5 The /sys/devices tree contains a snapshot of the
6 internal state of the kernel device tree. Devices will
9 devices within this tree will change.
11 Please do not rely on the format of this tree because of
13 the tree, please use the /sys/class structure and rely
15 within the /sys/devices tree of the individual devices.
17 devices being added and removed from this tree to find
|
| D | sysfs-firmware-ofw | 5 When using OpenFirmware or a Flattened Device Tree to enumerate
6 hardware, the device tree structure will be exposed in this
9 It is possible for multiple device-tree directories to exist.
10 Some device drivers use a separate detached device tree which
11 have no attachment to the system tree and will appear in a
15 path directly, but instead should follow /proc/device-tree
19 The /proc/device-tree symlink replaces the devicetree /proc
24 hierarchy of directories, one per device tree node. The
28 binary data from the device tree.
42 /sys/firmware/device-tree is deliberate: FDT is also used
|
| /Documentation/powerpc/ |
| D | bootwrapper.rst | 29 tree). This image embeds a device tree blob inside
30 the image. The boot wrapper, kernel and device tree
34 tree before jumping into the kernel.
40 which populates the embedded device tree with data
47 dtbImage.%: Similar to zImage, except device tree blob is embedded
53 interface for passing a device tree directly.
67 a device tree blob. This image is a flat binary that
71 the embedded device tree for all information.
75 tree blob inside the image.
81 a device tree to the kernel at boot. If using an older
[all …]
|
| /Documentation/sh/ |
| D | booting.rst | 6 Device-tree compatible SH bootloaders are expected to provide the physical
7 address of the device tree blob in r4. Since legacy bootloaders did not
11 that does not use device tree. Support for the latter is being phased out
12 in favor of device tree.
|
| /Documentation/filesystems/ |
| D | fsverity.rst | 22 causes the filesystem to build a Merkle tree for the file and persist
26 automatically verified against the file's Merkle tree. Reads of any
31 tree root hash) that fs-verity is enforcing for the file. This ioctl
102 This structure contains the parameters of the Merkle tree to build for
108 use for the Merkle tree, such as FS_VERITY_HASH_ALG_SHA256. See
110 - ``block_size`` must be the Merkle tree block size. Currently, this
128 FS_IOC_ENABLE_VERITY causes the filesystem to build a Merkle tree for
140 stable while the Merkle tree is being built over it.)
183 a Merkle tree and is different from a traditional full-file digest.
252 Merkle tree. The blocks are returned in order from the root level
[all …]
|
| D | sharedsubtree.rst | 186 To begin with, the administrator can mark the entire mount tree
216 If the entire mount tree is visible at multiple locations, then
388 propagates to. A new propagation tree containing 'C1',..,'Cn' is
389 created. This propagation tree is identical to the propagation tree of
397 propagates to. A new propagation tree is set containing all new mounts
399 propagation tree for 'B'.
405 'B' propagates to. A new propagation tree containing the new mounts
406 'C','C1',.. 'Cn' is created. This propagation tree is identical to the
407 propagation tree for 'B'. And finally the mount 'C' and its peer group
437 replicates all the mounts in the tree belonging to the specified mount.
[all …]
|
| /Documentation/devicetree/bindings/iio/ |
| D | common.yaml | 14 This document defines device tree properties common to several iio
15 sensors. It doesn't constitue a device tree binding specification by itself but
16 is meant to be referenced by device tree bindings.
18 When referenced from sensor tree bindings the properties defined in this
19 document are defined as follows. The sensor tree bindings are responsible for
|
| /Documentation/filesystems/ext4/ |
| D | ifork.rst | 43 Extent Tree
47 tree. Under the old scheme, allocating a contiguous run of 1,000 blocks
56 Extents are arranged as a tree. Each node of the tree begins with a
60 points to a block containing more nodes in the extent tree. If the node
63 point to the file's data blocks. The root node of the extent tree is
67 The extent tree header is recorded in ``struct ext4_extent_header``,
93 - Depth of this extent node in the extent tree. 0 = this extent node
95 extent nodes. The extent tree can be at most 5 levels deep: a logical
101 - Generation of the tree. (Used by Lustre, but not standard ext4).
103 Internal nodes of the extent tree, also known as index nodes, are
[all …]
|
| D | verity.rst | 7 Merkle tree based hashing for individual readonly files. Most of
17 - The Merkle tree, as documented in
19 <fsverity_merkle_tree>`, with the tree levels stored in order from
20 root to leaf, and the tree blocks within each level stored in their
|
| /Documentation/devicetree/bindings/display/bridge/ |
| D | dw_hdmi.txt | 4 This document defines device tree properties for the Synopsys DesignWare HDMI
5 TX Encoder (DWC HDMI TX). It doesn't constitue a device tree binding
7 device tree bindings.
9 When referenced from platform device tree bindings the properties defined in
10 this document are defined as follows. The platform device tree bindings are
|
| D | snps,dw-mipi-dsi.yaml | 13 This document defines device tree properties for the Synopsys DesignWare MIPI
14 DSI host controller. It doesn't constitue a device tree binding specification
15 by itself but is meant to be referenced by platform-specific device tree
18 When referenced from platform device tree bindings the properties defined in
19 this document are defined as follows. The platform device tree bindings are
|
| /Documentation/ABI/stable/ |
| D | sysfs-devices | 7 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
9 Any device associated with a device-tree node will have
15 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
22 Contact: Device Tree mailing list <devicetree@vger.kernel.org>
|
| /Documentation/devicetree/bindings/fpga/ |
| D | fpga-region.txt | 1 FPGA Region Device Tree Binding
11 - Device Tree Examples
19 the Device Tree. FPGA Regions provide a way to program FPGAs under device tree
22 This device tree binding document hits some of the high points of FPGA usage and
68 device tree.
114 4. The Device Tree overlay is accepted into the live tree.
124 FPGA Regions represent FPGA's and FPGA PR regions in the device tree. An FPGA
133 The intended use is that a Device Tree overlay (DTO) can be used to reprogram an
136 An FPGA Region that exists in the live Device Tree reflects the current state.
137 If the live tree shows a "firmware-name" property or child nodes under a FPGA
[all …]
|
| /Documentation/power/powercap/ |
| D | dtpm.rst | 36 The DTPM is a tree representation describing the power constraints
39 The nodes of the tree are a virtual description aggregating the power
42 The leaves of the tree are the real power manageable devices.
64 When the nodes are inserted in the tree, their power characteristics are propagated to the parents::
90 …xample, if we set a power limitation of 3200mW at the 'SoC' root node, the resulting tree will be::
167 power constraints tree.
170 allocate and link the different nodes of the tree.
175 already existing tree at boot time.
186 The nodes of the DTPM tree are described with dtpm structure. The
200 If a device has its power characteristics changing, then the tree must
[all …]
|
| /Documentation/vm/ |
| D | ksm.rst | 25 tree.
28 the node of the stable tree that represents such KSM page points to a
30 KSM page points to the stable tree node.
33 the stable tree. The tree node becomes a "chain" that links one or
42 This way the stable tree lookup computational complexity is unaffected
45 stable tree itself.
|
| /Documentation/core-api/ |
| D | rbtree.rst | 12 Red-black trees are a type of self-balancing binary search tree, used for
21 three rotations, respectively, to balance the tree), with slightly slower
31 red-black tree. Virtual memory areas (VMAs) are tracked with red-black
52 tree implementations. Instead of using pointers to separate rb_node and data
55 users are expected to write their own tree search and insert functions
62 Data nodes in an rbtree tree are structures containing a struct rb_node member::
81 Writing a search function for your tree is fairly straightforward: start at the
109 Inserting data in the tree involves first searching for the place to insert the
110 new node, then inserting the node and rebalancing ("recoloring") the tree.
136 /* Add new node and rebalance tree. */
[all …]
|
| D | generic-radix-tree.rst | 5 .. kernel-doc:: include/linux/generic-radix-tree.h
8 generic radix tree functions
11 .. kernel-doc:: include/linux/generic-radix-tree.h
|
| /Documentation/devicetree/bindings/ata/ |
| D | pata-common.yaml | 13 This document defines device tree properties common to most Parallel
15 It doesn't constitue a device tree binding specification by itself but is
16 meant to be referenced by device tree bindings.
18 The PATA (IDE) controller-specific device tree bindings are responsible for
|
| D | sata-common.yaml | 13 This document defines device tree properties common to most Serial
14 AT attachment (SATA) storage devices. It doesn't constitute a device tree
16 tree bindings.
18 The SATA controller-specific device tree bindings are responsible for
|
| /Documentation/maintainer/ |
| D | rebasing-and-merging.rst | 50 tree and built on it; modifying your tree will create pain for them. If
64 exceptions, for example, a broken commit in a tree like this should be
67 - Do not reparent a tree without a good reason to do so. Just being on a
123 merge, say *why* the merge is being done. For a lower-level tree, "why" is
132 history into your tree, you cannot rebase that branch, even if you
153 also obscure problems with the development process in your tree; they can
160 Even then, you should not back merge a tree above your immediate upstream
161 tree; if a higher-level back merge is really required, the upstream tree
187 Another reason for doing merges of upstream or another subsystem tree is to
189 sometimes a cross-merge with another tree is the best way to resolve them;
[all …]
|
| /Documentation/arm/ |
| D | microchip.rst | 185 Device Tree for AT91 SoCs and boards
187 All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
191 Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
193 any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
194 the same source tree.
201 - SoCs Device Tree Source Include files are named after the official name of
203 - Device Tree Source Include files (.dtsi) are used to collect common nodes that can be
208 - board Device Tree Source files (.dts) are prefixed by the string "at91-" so
|
12345678910>>...48