On 03/12/24 10:16, David Gibson wrote:
On Sat, Nov 16, 2024 at 08:30:23PM +0530, Ayush Singh wrote:
Add tests to verify path reference support in overlays
Signed-off-by: Ayush Singh <ayush@xxxxxxxxxxxxxxx>
---
tests/overlay_overlay.dts | 11 +++++++++++
tests/overlay_overlay_manual_fixups.dts | 26 +++++++++++++++++++++++++-
tests/overlay_overlay_nosugar.dts | 19 +++++++++++++++++++
3 files changed, 55 insertions(+), 1 deletion(-)
diff --git a/tests/overlay_overlay.dts b/tests/overlay_overlay.dts
index c4ef1d47f1f159c5284c8f7282a0232d944ecfd1..18382762eb3d7c26b0f2e507acc3803f38194fb1 100644
--- a/tests/overlay_overlay.dts
+++ b/tests/overlay_overlay.dts
@@ -50,3 +50,14 @@
new-sub-test-property;
};
};
+
+&test {
+ test-patha = &test;
+ test-pathb = &test;
+};
+
+&test {
+ sub-path-test-node {
+ test-path = &test;
+ };
+};
You should test path references combined with other pieces too:
test-pathc = "a string", &test, "another string";
In fact it would even be a good idea to test path references combined
with phandle references.
test-pathd = "a string", <0x1 0x2 &test>, &test;
I have hit a bit of roadblock with the following case:
test-pathe = "a string", &test1, &test2;
Resolving &test1 will make the poffset for &test2 invalid. So do I need
to worry about multiple path references in the same property? I do have
a few ways to deal with this, but maybe I am missing something:
1. Introduce something like `__fixups_path__` where we can use a
different way to store information regarding path references. I am not
too keen on going this way though. If we really need to introduce a new
fixup node, might as well go all the way and have the node work for
phandles as well.
2. Change the resolution algorithm to maybe create an intermediate tree
first from `__fixups__` and resolve each property in reverse order in
the tree. It seems great, until the fact that we cannot use heap comes
into play. Playing with offsets all over the place has not been great in
v2 (lots of bugs), and this will just make it harder.
Again, maybe there is a data structure more suited for our case, or
maybe there is something I missed since I am new to this codebase, so
thought it would be better to discuss it here.
diff --git a/tests/overlay_overlay_manual_fixups.dts b/tests/overlay_overlay_manual_fixups.dts
index a5715b6048acaeebcdab56060040a339d08686a3..c40297aaefaaa6d168e42f864639a05bbbe69f57 100644
--- a/tests/overlay_overlay_manual_fixups.dts
+++ b/tests/overlay_overlay_manual_fixups.dts
@@ -86,6 +86,25 @@
};
};
+ fragment@8 {
+ target = <0xffffffff /*&test*/>;
+
+ __overlay__ {
+ test-patha;
+ test-pathb;
+ };
+ };
+
+ fragment@9 {
+ target = <0xffffffff /*&test*/>;
+
+ __overlay__ {
+ sub-path-test-node {
+ test-path;
+ };
+ };
+ };
+
__fixups__ {
test = "/fragment@0:target:0",
"/fragment@1:target:0",
@@ -95,7 +114,12 @@
"/fragment@5:target:0",
"/fragment@5/__overlay__:test-phandle:0",
"/fragment@6:target:0",
- "/fragment@7:target:0";
+ "/fragment@7:target:0",
+ "/fragment@8:target:0",
+ "/fragment@8/__overlay__:test-patha:0",
+ "/fragment@8/__overlay__:test-pathb:0",
+ "/fragment@9:target:0",
+ "/fragment@9/__overlay__/sub-path-test-node:test-path:0";
};
__local_fixups__ {
fragment@5 {
diff --git a/tests/overlay_overlay_nosugar.dts b/tests/overlay_overlay_nosugar.dts
index b5947e96fb00dcf2c321c9f43e708863053b14b3..7e54ae5f5e7641bdf08626200e9471067b0f7677 100644
--- a/tests/overlay_overlay_nosugar.dts
+++ b/tests/overlay_overlay_nosugar.dts
@@ -83,4 +83,23 @@
};
};
};
+
+ fragment@8 {
+ target = <&test>;
+
+ __overlay__ {
+ test-patha = &test;
+ test-pathb = &test;
+ };
+ };
+
+ fragment@9 {
+ target = <&test>;
+
+ __overlay__ {
+ sub-path-test-node {
+ test-path = &test;
+ };
+ };
+ };
};
Ayush Singh
