Lines Matching +full:device +full:- +full:tree
1 .. SPDX-License-Identifier: GPL-2.0
13 is attached to the live tree dynamically, independent of the machine's
18 (1) Documentation/devicetree/usage-model.rst
22 provided to device driver developers to fetch the device information..etc.
23 from the unflattened device tree data structure. This interface is used by
24 most of the device drivers in various use cases.
45 from 'scripts/dtc/of_unittest_expect --help'.
48 3. Test-data
51 The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains
55 drivers/of/unittest-data/tests-*.dtsi
57 for the Device Tree Source Include files (.dtsi) included in testcases.dts.
79 -------------------------
81 Un-flattened device tree structure:
83 Un-flattened device tree consists of connected device_node(s) in form of a tree
86 // following struct members are used to construct the tree
95 Figure 1, describes a generic structure of machine's un-flattened device tree
97 ``*parent``, that is used to traverse the tree in the reverse direction. So, at
104 child1 -> sibling2 -> sibling3 -> sibling4 -> null
108 | | child31 -> sibling32 -> null
112 | child21 -> sibling22 -> sibling23 -> null
116 child11 -> sibling12 -> sibling13 -> sibling14 -> null
120 null null child131 -> null
124 Figure 1: Generic structure of un-flattened device tree
128 machine's device tree (if present). So, when selftest_data_add() is called,
129 at first it reads the flattened device tree data linked into the kernel image
132 __dtb_testcases_begin - address marking the start of test data blob
133 __dtb_testcases_end - address marking the end of test data blob
136 blob. And finally, if the machine's device tree (i.e live tree) is present,
137 then it attaches the unflattened test data tree to the live tree, else it
138 attaches itself as a live device tree.
141 live tree as explained below. To explain the same, the test data tree described
142 in Figure 2 is attached to the live tree described in Figure 1::
146 testcase-data
148 test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null
150 test-child01 null null null
153 Figure 2: Example test data tree to be attached to live tree.
155 According to the scenario above, the live tree is already present so it isn't
160 given parent in live tree. But, if parent already has a child then the new node
162 data node is attached to the live tree above (Figure 1), the final structure is
167 testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null
170 | | child31 -> sibling32 -> null
174 | child21 -> sibling22 -> sibling23 -> null
178 child11 -> sibling12 -> sibling13 -> sibling14 -> null
182 child131 -> null
185 -----------------------------------------------------------------------
189 testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null
193 test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null
195 null null null test-child01
198 Figure 3: Live device tree structure after attaching the testcase-data.
201 Astute readers would have noticed that test-child0 node becomes the last
203 test-child0 the test-sibling1 is attached that pushes the child node
204 (i.e. test-child0) to become a sibling and makes itself a child node,
208 already present in the live tree), then the node isn't attached rather its
209 properties are updated to the live tree's node by calling the function
214 ---------------------------
217 order to remove the device nodes attached initially (first the leaf nodes are
219 whole tree). selftest_data_remove() calls detach_node_and_children() that uses
220 of_detach_node() to detach the nodes from the live device tree.