Lines Matching +full:in +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
23 from the unflattened device tree data structure. This interface is used by
24 most of the device drivers in various use cases.
41 The EXPECT messages result in very noisy console messages that are difficult
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
52 the test data required for executing the unit tests automated in
53 drivers/of/unittest.c. Currently, following Device Tree Source Include files
54 (.dtsi) are included in testcases.dts::
56 drivers/of/unittest-data/tests-interrupts.dtsi
57 drivers/of/unittest-data/tests-platform.dtsi
58 drivers/of/unittest-data/tests-phandle.dtsi
59 drivers/of/unittest-data/tests-match.dtsi
81 -------------------------
83 Un-flattened device tree structure:
85 Un-flattened device tree consists of connected device_node(s) in form of a tree
88 // following struct members are used to construct the tree
97 Figure 1, describes a generic structure of machine's un-flattened device tree
99 ``*parent``, that is used to traverse the tree in the reverse direction. So, at
106 child1 -> sibling2 -> sibling3 -> sibling4 -> null
110 | | child31 -> sibling32 -> null
114 | child21 -> sibling22 -> sibling23 -> null
118 child11 -> sibling12 -> sibling13 -> sibling14 -> null
122 null null child131 -> null
126 Figure 1: Generic structure of un-flattened device tree
130 machine's device tree (if present). So, when selftest_data_add() is called,
131 at first it reads the flattened device tree data linked into the kernel image
134 __dtb_testcases_begin - address marking the start of test data blob
135 __dtb_testcases_end - address marking the end of test data blob
138 blob. And finally, if the machine's device tree (i.e live tree) is present,
139 then it attaches the unflattened test data tree to the live tree, else it
140 attaches itself as a live device tree.
143 live tree as explained below. To explain the same, the test data tree described
144 in Figure 2 is attached to the live tree described in Figure 1::
148 testcase-data
150 test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null
152 test-child01 null null null
155 Figure 2: Example test data tree to be attached to live tree.
157 According to the scenario above, the live tree is already present so it isn't
161 In the function of_attach_node(), the new node is attached as the child of the
162 given parent in live tree. But, if parent already has a child then the new node
164 data node is attached to the live tree above (Figure 1), the final structure is
165 as shown in Figure 3::
169 testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null
172 | | child31 -> sibling32 -> null
176 | child21 -> sibling22 -> sibling23 -> null
180 child11 -> sibling12 -> sibling13 -> sibling14 -> null
184 child131 -> null
187 -----------------------------------------------------------------------
191 testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null
195 test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null
197 null null null test-child01
200 Figure 3: Live device tree structure after attaching the testcase-data.
203 Astute readers would have noticed that test-child0 node becomes the last
205 test-child0 the test-sibling1 is attached that pushes the child node
206 (i.e. test-child0) to become a sibling and makes itself a child node,
210 already present in the live tree), then the node isn't attached rather its
211 properties are updated to the live tree's node by calling the function
216 ---------------------------
218 Once the test case execution is complete, selftest_data_remove is called in
221 whole tree). selftest_data_remove() calls detach_node_and_children() that uses
222 of_detach_node() to detach the nodes from the live device tree.