Show deleted nodes, props and labels as commented out in output .dts

[bmx666]

Hi, I'm bringing back to life "Device Tree Visualizer"
This project is helpful for our team to analyze complex projects where multiple DTS included and overlayed.

I made a few WORKAROUNDs inside my fork.
But I'm not expert in DT compiler and it's hard to imagine whole picture "how dtc works".

Is it possible to generate compatible DTS which highlight "deleted nodes/props" but when you pass special flag?

[dgibson]

I'm afraid I'm really not sure what you're asking for.

[bmx666]

@dgibson for example, command to generate full annotated final DTS file

cpp -nostdinc -undef -D__DTS__ \
    -x assembler-with-cpp \
    -I ~/linux/include/ -I ~/linux/arch/arm/boot/dts -I ~/linux/scripts/dtc/include-prefixes/ \
    ~/linux/arch/arm64/boot/dts/allwinner/sun50i-h5-bananapi-m2-plus.dts | \
    | dtc -I dts -O dts -f -s -T -T -o - > annotated.dts

Problem 1

dtc put in comment only the latest merged source file for property, but left all source files for nodes. Example:

A.dts

my_node {
    test_A;
};

B.dts

#include "A.dts"
my_node {
    test;
};

C.dts

#include "B.dts"
my_node {
    test;
};

my_node { /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */
    test_A;  /* A.dts:0-0:0-0 */
    test;  /* C.dts:0-0:0-0 */
};  /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */

But I expected "B.dts" for "test" property too, like this:

my_node { /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */
    test_A;  /* A.dts:0-0:0-0 */
    test;  /* B.dts:0-0:0-0, C.dts:0-0:0-0 */
};  /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */

Problem 2

In current version not possible to trace where "/delete-node/" or "/delete-property/" was called. For example:

A.dts

my_node {
    test_A;
};

B.dts

#include "A.dts"
my_node {
    /delete-property/ test_A;
    test_B;
};

C.dts

#include "B.dts"
my_node {
    /delete-property/ test_B;
    test_C;
};

Final version:

my_node { /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */
    test_C;  /* C.dts:0-0:0-0 */
};  /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */

When you analyze 10+ includes and reverse back DTB + overlay to DTS it's hard to trace which file cause a problem after updates.

At the beginning I told to do like this when using annotations:

my_node { /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */
    /* DELETED */ /* test_A; */ /* A.dts:0-0:0-0, B.dts:0-0:0-0 */
    /* DELETED */ /* test_B; */ /* B.dts:0-0:0-0, C.dts:0-0:0-0 */
    test_C;  /* C.dts:0-0:0-0 */
};  /* A.dts:0-0:0-0, B.dts:0-0:0-0, C.dts:0-0:0-0 */

It will be much easy to find a problem with side-effect updates in DTS-files

[dgibson]

Sorry it's taken me so long to respond. I'd actually completely forgotten about the annotation feature, which is why I was confused.

Reviewing properly now.

[bmx666]

Hi @dgibson thanks for your review and comments here

I did refactoring little bit and switch on new dtc flag --show-deleted instead of using annotations here

It still in WIP, because I'm figuring out how reuse deleted flag and avoid use was_deleted...

[dgibson]

Ok, let me know when you have somehting ready for review.

[bmx666]

Hi @dgibson , unfortunately solution without "was_deleted" is much worse and it doesn't cover all cases. It inserts and left nodes and properties, if dtc parse /delete-*/ for non-existing nodes or properties.

[dgibson]

If you need it, you need to describe its sematics, and how it differs from deleted.

[bmx666]

Hi @dgibson sorry for long delay, I replaced was_deleted on comment_deleted.
Difference between deleted and comment_deleted is simple:
if dtc option --comment-deleted is enabled then all nodes, labels and properties unset deleted from true to false and sets comment_deleted as true for output dts.
If during DTS processing with flag --comment-deleted node or property will be set again then commend-deleted sets to false only for current node (not for child elements) or property until next time node, label or property will be deleted.

Example

Stage 1. Create node with sub_node and prop1

node {
    sub_node {
        prop2;
    };
    prop1;
};

Stage 2. Delete node

/delete-node/ node;

...

node { /* DELETED */
    sub_node { /* DELETED */
        prop2; /* DELETED */
    }; /* DELETED */
    prop1; /* DELETED */
}; /* DELETED */

Stage 3. Re-create node with prop1

node {
    prop1;
};

...
node {
    sub_node { /* DELETED */
        prop2; /* DELETED */
    }; /* DELETED */
    prop1;
};

Stage 4. Add sub-node with prop3

node {
    sub_node {
        prop2;
    };
};

...
node {
    sub_node {
        prop2; /* DELETED */
        prop3;
    };
    prop1;
};

Stage 5. Delete sub-node

node {
    /delete-node/ sub_node;
};

...
node {
    sub_node { /* DELETED */
        prop2; /* DELETED */
        prop3; /* DELETED */
    }; /* DELETED */
    prop1;
};