fix unit name warnings on lpc18xx

Add unit name to nvic to remove the following warning:
Warning (unit_address_vs_reg): Node /nv-interrupt-controller has a reg
or ranges property, but no unit name

Also correct the node name to 'interrupt-controller' while changing the line.

Signed-off-by Joachim Eastwood <[email protected]>

Hello Joachim,

Quoted 4 lines · Joachim Eastwood

Add unit name to nvic to remove the following warning:
Warning (unit_address_vs_reg): Node /nv-interrupt-controller has a reg
or ranges property, but no unit name

Quoted 4 lines

Also correct the node name to 'interrupt-controller' while changing the line.

Signed-off-by Joachim Eastwood <[email protected]>

Looks right,

Acked-by Uwe Kleine-K?nig <[email protected]>

Quoted 13 lines · Uwe Kleine-K?nig

Hello Joachim,

Quoted 8 lines · Joachim Eastwood

Add unit name to nvic to remove the following warning:
Warning (unit_address_vs_reg): Node /nv-interrupt-controller has a reg
or ranges property, but no unit name

Also correct the node name to 'interrupt-controller' while changing the line.

Signed-off-by Joachim Eastwood <[email protected]>

Looks right,

Quoted 1 line

Acked-by Uwe Kleine-K?nig <[email protected]>

Thanks, Uwe.

Unless any of the other Cortex-M platform maintainers (added more CCs) has any objections I'll take this through the lpc18xx tree. I will send a pull request to arm-soc with this soon.

Unless any of the other Cortex-M platform maintainers (added more CCs) has any objections I'll take this through the lpc18xx tree. I will send a pull request to arm-soc with this soon.

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

Signed-off-by Joachim Eastwood <[email protected]>

---
 arch/arm/boot/dts/skeleton.dtsi   | 2 +-
 arch/arm/boot/dts/skeleton64.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/boot/dts/skeleton.dtsi +1 -1

index b41d241..a20da0a 100644
@@ -9,5 +9,5 @@
 	#size-cells = <1>;
 	chosen { };
 	aliases { };
-	memory { device_type = "memory"; reg = <0 0>; };
+	memory at 0 { device_type = "memory"; reg = <0 0>; };
 };

arch/arm/boot/dts/skeleton64.dtsi +0 -0

index b5d7f36..6dbe9f9 100644

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

Signed-off-by Joachim Eastwood <[email protected]>

---
 arch/arm/boot/dts/skeleton.dtsi   | 2 +-
 arch/arm/boot/dts/skeleton64.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/boot/dts/skeleton.dtsi +1 -1

index b41d241..a20da0a 100644
@@ -9,5 +9,5 @@
 	#size-cells = <1>;
 	chosen { };
 	aliases { };
-	memory { device_type = "memory"; reg = <0 0>; };
+	memory at 0 { device_type = "memory"; reg = <0 0>; };
 };

arch/arm/boot/dts/skeleton64.dtsi +1 -1

index b5d7f36..6dbe9f9 100644
@@ -9,5 +9,5 @@
 	#size-cells = <2>;
 	chosen { };
 	aliases { };
-	memory { device_type = "memory"; reg = <0 0 0 0>; };
+	memory at 0 { device_type = "memory"; reg = <0 0 0 0>; };
 };

Signature · 6 lines

2.7.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

Quoted 23 lines

Signed-off-by Joachim Eastwood <[email protected]>

---
 arch/arm/boot/dts/skeleton.dtsi   | 2 +-
 arch/arm/boot/dts/skeleton64.dtsi | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

arch/arm/boot/dts/skeleton.dtsi +1 -1

index b41d241..a20da0a 100644
@@ -9,5 +9,5 @@
 	#size-cells = <1>;
 	chosen { };
 	aliases { };
-	memory { device_type = "memory"; reg = <0 0>; };
+	memory at 0 { device_type = "memory"; reg = <0 0>; };
 };

arch/arm/boot/dts/skeleton64.dtsi +0 -0

index b5d7f36..6dbe9f9 100644
@@ -9,5 +9,5 @@
 	#size-cells = <2>;

Quoted 8 lines

arch/arm/boot/dts/skeleton64.dtsi +1 -1

 	chosen { };
 	aliases { };
-	memory { device_type = "memory"; reg = <0 0 0 0>; };
+	memory at 0 { device_type = "memory"; reg = <0 0 0 0>; };
 };

Signature · 1 line

2.7.4

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Quoted 9 lines · Vladimir Zapolskiy

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 7 lines

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Sure. To clarify the above, what I expect that for this case is that the empty memory node would exist in the dts for that particular board, along with a comment, e.g.

        /* The firmware/bootloader for $BOARD fills this in */
        memory {
                device_type = "memory";
                reg = <0 0 0 0>;
        };

That way you can tell at a glance that the lack of memory information in the DT for a board is intentional, and the bootloader still gets the node it expects.

Hi Mark,

Quoted 22 lines · Mark Rutland

Quoted 9 lines · Vladimir Zapolskiy

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 7 lines

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Sure. To clarify the above, what I expect that for this case is that the empty memory node would exist in the dts for that particular board, along with a comment, e.g.

Quoted 5 lines

        /* The firmware/bootloader for $BOARD fills this in */
        memory {
                device_type = "memory";
                reg = <0 0 0 0>;
        };

To avoid the warning with the new dtc this would need to be memory at 0.

Quoted 3 lines

That way you can tell at a glance that the lack of memory information in the DT for a board is intentional, and the bootloader still gets the node it expects.

But this doesn't seem to be a "problem" with any of the DTs in arch/arm/boot as they all defined a memory node.

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

Quoted 25 lines · Joachim Eastwood

Hi Mark,

Quoted 22 lines · Mark Rutland

Quoted 9 lines · Vladimir Zapolskiy

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 7 lines

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Sure. To clarify the above, what I expect that for this case is that the empty memory node would exist in the dts for that particular board, along with a comment, e.g.

Quoted 7 lines

Quoted 5 lines

        /* The firmware/bootloader for $BOARD fills this in */
        memory {
                device_type = "memory";
                reg = <0 0 0 0>;
        };

To avoid the warning with the new dtc this would need to be memory at 0.

Hmm... That's a little sub-optimal in the case that a bootloader is patching this. Presumably a bootloader that needs an existing node won't patch the unit-address to match the reg (which might not start at 0).

I'd rather not have the unit-address than have an incorrect unit-address, though I guess we don't have much of a choice here, unless there's some override we can place in the dts.

Quoted 16 lines

Quoted 3 lines

That way you can tell at a glance that the lack of memory information in the DT for a board is intentional, and the bootloader still gets the node it expects.

But this doesn't seem to be a "problem" with any of the DTs in arch/arm/boot as they all defined a memory node.

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

The above might match reserved-memory nodes; it might be better to check for 'device_type\s*=\s*"memory"'.

I assume that was run after deleting the memory node from the skeletons?

Quoted 10 lines · Mark Rutland

Quoted 9 lines · Joachim Eastwood

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 6 lines

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

The above might match reserved-memory nodes; it might be better to check for 'device_type\s*=\s*"memory"'.

I did check the output of the grep and it looks good. But there are indeed DTs that are missing the 'device_type = "memory"' parameter. Actually; _a lot_ or 438 of 741 to be exact. ugh...

I guess all those should be fixed up before we can remove the memory node from skeleton. :/

Quoted 18 lines · Joachim Eastwood

Quoted 10 lines · Mark Rutland

Quoted 9 lines · Joachim Eastwood

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 6 lines

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

The above might match reserved-memory nodes; it might be better to check for 'device_type\s*=\s*"memory"'.

Quoted 6 lines

I did check the output of the grep and it looks good. But there are indeed DTs that are missing the 'device_type = "memory"' parameter. Actually; _a lot_ or 438 of 741 to be exact. ugh...

I guess all those should be fixed up before we can remove the memory node from skeleton. :/

Ouch, yes. :(

That said, the cahnges don't need to be an atomic operation. We could start adding device_type = "memory" to dts immediately (in as whatever size batches maintainers are happy with), as a duplicate device_type shouldn't be problematic.

When we hit critical mass, we could then remove the skeleton memory nodes, fixing up any remaining fallout.

As for the mechanical changes, it sounds like we need coccinelle for DT.

That, or a laptop, a long flight, and a gin and tonic.

Quoted 26 lines · Mark Rutland

Quoted 18 lines · Joachim Eastwood

Quoted 10 lines · Mark Rutland

Quoted 9 lines · Joachim Eastwood

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 6 lines

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

The above might match reserved-memory nodes; it might be better to check for 'device_type\s*=\s*"memory"'.

Quoted 6 lines

I did check the output of the grep and it looks good. But there are indeed DTs that are missing the 'device_type = "memory"' parameter. Actually; _a lot_ or 438 of 741 to be exact. ugh...

I guess all those should be fixed up before we can remove the memory node from skeleton. :/

Quoted 6 lines

Ouch, yes. :(

That said, the cahnges don't need to be an atomic operation. We could start adding device_type = "memory" to dts immediately (in as whatever size batches maintainers are happy with), as a duplicate device_type shouldn't be problematic.

Yes, that is true.

Quoted 3 lines

When we hit critical mass, we could then remove the skeleton memory nodes, fixing up any remaining fallout.

Quoted 3 lines

As for the mechanical changes, it sounds like we need coccinelle for DT.

That, or a laptop, a long flight, and a gin and tonic.

:-)

I'll see if I can cook up something with awk.

Quoted 40 lines · Joachim Eastwood

Quoted 26 lines · Mark Rutland

Quoted 18 lines · Joachim Eastwood

Quoted 10 lines · Mark Rutland

Quoted 9 lines · Joachim Eastwood

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 6 lines

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

The above might match reserved-memory nodes; it might be better to check for 'device_type\s*=\s*"memory"'.

Quoted 6 lines

I did check the output of the grep and it looks good. But there are indeed DTs that are missing the 'device_type = "memory"' parameter. Actually; _a lot_ or 438 of 741 to be exact. ugh...

I guess all those should be fixed up before we can remove the memory node from skeleton. :/

Quoted 6 lines

Ouch, yes. :(

That said, the cahnges don't need to be an atomic operation. We could start adding device_type = "memory" to dts immediately (in as whatever size batches maintainers are happy with), as a duplicate device_type shouldn't be problematic.

Yes, that is true.

Quoted 3 lines

When we hit critical mass, we could then remove the skeleton memory nodes, fixing up any remaining fallout.

Quoted 7 lines

Quoted 3 lines

As for the mechanical changes, it sounds like we need coccinelle for DT.

That, or a laptop, a long flight, and a gin and tonic.

:-)

I'll see if I can cook up something with awk.

Something like this should do it:
#!/usr/bin/gawk -f

# find arch/arm/boot/dts/ -type f -name *.dts* | xargs
./mem_node_add_dev_type.awk -i inplace
BEGIN { go = 0 }
/[^-]memory ?{/ { go = 1; idx = 0; device_type = 0 }

go == 1 {
        buf[idx++] = $0
        if ($0 ~ /device_type/)
                device_type = 1

        if ($0 ~ /};/) {
                print buf[0]

                if (!device_type) {
                        buf[0] = buf[1]
                        gsub(/[^\t]*/, "", buf[0])
                        buf[0] = buf[0] "device_type = \"memory\";"
                } else {
                        delete buf[0]
                }

                for (i in buf)
                        print buf[i]
                delete buf

                go = 0
                device_type = 0
        }
        next
}

{ print }

Gives me: 249 files changed, 249 insertions(+), 1 deletion(-) on v4.6-rc1.

Running the my check script after this reveals that 83 DTs lack the device_type parameter, but these seem to also lack the memory node as well. Wonder why my script didn't pick up the missing memory node in those... I also doubt that the memory node is set by the boot loader in some of these boards.

regards,
Joachim Eastwood

Quoted 84 lines · Joachim Eastwood

Quoted 40 lines · Joachim Eastwood

Quoted 26 lines · Mark Rutland

Quoted 18 lines · Joachim Eastwood

Quoted 10 lines · Mark Rutland

Quoted 9 lines · Joachim Eastwood

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 6 lines

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

The above might match reserved-memory nodes; it might be better to check for 'device_type\s*=\s*"memory"'.

Quoted 6 lines

I did check the output of the grep and it looks good. But there are indeed DTs that are missing the 'device_type = "memory"' parameter. Actually; _a lot_ or 438 of 741 to be exact. ugh...

I guess all those should be fixed up before we can remove the memory node from skeleton. :/

Quoted 6 lines

Ouch, yes. :(

That said, the cahnges don't need to be an atomic operation. We could start adding device_type = "memory" to dts immediately (in as whatever size batches maintainers are happy with), as a duplicate device_type shouldn't be problematic.

Yes, that is true.

Quoted 3 lines

When we hit critical mass, we could then remove the skeleton memory nodes, fixing up any remaining fallout.

Quoted 7 lines

Quoted 3 lines

As for the mechanical changes, it sounds like we need coccinelle for DT.

That, or a laptop, a long flight, and a gin and tonic.

:-)

I'll see if I can cook up something with awk.

Something like this should do it:
#!/usr/bin/gawk -f

# find arch/arm/boot/dts/ -type f -name *.dts* | xargs
./mem_node_add_dev_type.awk -i inplace
BEGIN { go = 0 }
/[^-]memory ?{/ { go = 1; idx = 0; device_type = 0 }

go == 1 {
        buf[idx++] = $0
        if ($0 ~ /device_type/)
                device_type = 1

        if ($0 ~ /};/) {
                print buf[0]

                if (!device_type) {
                        buf[0] = buf[1]
                        gsub(/[^\t]*/, "", buf[0])
                        buf[0] = buf[0] "device_type = \"memory\";"
                } else {
                        delete buf[0]
                }

                for (i in buf)
                        print buf[i]
                delete buf

                go = 0
                device_type = 0
        }
        next
}

{ print }

Quoted 7 lines

Gives me: 249 files changed, 249 insertions(+), 1 deletion(-) on v4.6-rc1.

Running the my check script after this reveals that 83 DTs lack the device_type parameter, but these seem to also lack the memory node as well. Wonder why my script didn't pick up the missing memory node in those... I also doubt that the memory node is set by the boot loader in some of these boards.

I don't think this script is right. It will not work if the memory node is spread across dtsi files. You would need to compiler everything to dtb and then back to a flat dts file before running thru this script.

I don't see the rest of the series in -next. Is that going to happen soon?

Hi Mark,

Quoted 22 lines · Mark Rutland

Quoted 9 lines · Vladimir Zapolskiy

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 7 lines

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Sure. To clarify the above, what I expect that for this case is that the empty memory node would exist in the dts for that particular board, along with a comment, e.g.

Quoted 5 lines

        /* The firmware/bootloader for $BOARD fills this in */
        memory {
                device_type = "memory";
                reg = <0 0 0 0>;
        };

To avoid the warning with the new dtc this would need to be memory at 0.

Quoted 3 lines

That way you can tell at a glance that the lack of memory information in the DT for a board is intentional, and the bootloader still gets the node it expects.

But this doesn't seem to be a "problem" with any of the DTs in arch/arm/boot as they all defined a memory node.

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

Quoted 25 lines · Joachim Eastwood

Hi Mark,

Quoted 22 lines · Mark Rutland

Quoted 9 lines · Vladimir Zapolskiy

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 7 lines

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Sure. To clarify the above, what I expect that for this case is that the empty memory node would exist in the dts for that particular board, along with a comment, e.g.

Quoted 7 lines

Quoted 5 lines

        /* The firmware/bootloader for $BOARD fills this in */
        memory {
                device_type = "memory";
                reg = <0 0 0 0>;
        };

To avoid the warning with the new dtc this would need to be memory at 0.

Except memory is probably not actually at 0 here. This has come up before and been beaten to death. Bottom line is plain "memory" is allowed, and I plan to add that exception to dtc.

Quoted 17 lines

Quoted 3 lines

That way you can tell at a glance that the lack of memory information in the DT for a board is intentional, and the bootloader still gets the node it expects.

But this doesn't seem to be a "problem" with any of the DTs in arch/arm/boot as they all defined a memory node.

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

Quoted 3 lines

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

You've got to make sure they have 'device_type = "memory";' which they could rely on inheriting.

Quoted 32 lines · Rob Herring

Quoted 31 lines · Joachim Eastwood

Hi Mark,

Quoted 27 lines · Mark Rutland

Quoted 9 lines · Vladimir Zapolskiy

Quoted 8 lines · Mark Rutland

Quoted 3 lines · Joachim Eastwood

Add unit name to memory to remove the following warning:
Warning (unit_address_vs_reg): Node /memory has a reg or ranges
property, but no unit name

If anything, it would be better to get rid of the memory node from the skeleton DTs.

Quoted 7 lines

Quoted 3 lines

For DTs which have a memory node there's no problem, and DTs which expect a bootlaoder to fill things in have a logical place to document that fact.

The only problem I see if DTB is updated on a board but a board bootloader on fix-up is capable to fill a preexisting "/memory" device node in only, otherwise it is not clear why the device node is present in skeleton.dtsi.

Sure. To clarify the above, what I expect that for this case is that the empty memory node would exist in the dts for that particular board, along with a comment, e.g.

        /* The firmware/bootloader for $BOARD fills this in */
        memory {
                device_type = "memory";
                reg = <0 0 0 0>;
        };

Quoted 5 lines

Quoted 1 line

To avoid the warning with the new dtc this would need to be memory at 0.

Except memory is probably not actually at 0 here. This has come up before and been beaten to death. Bottom line is plain "memory" is allowed, and I plan to add that exception to dtc.

Quoted 21 lines

Quoted 20 lines

Quoted 3 lines

That way you can tell at a glance that the lack of memory information in the DT for a board is intentional, and the bootloader still gets the node it expects.

But this doesn't seem to be a "problem" with any of the DTs in arch/arm/boot as they all defined a memory node.

I used the following script to check for the memory node in all built dtb's.
make ARCH=arm CONFIG_OF_ALL_DTBS=y dtbs
for i in $(ls arch/arm/boot/dts/*.dtb); do

         m=$(scripts/dtc/dtc -I dtb -O dts $i | grep -m1 'memory.*{')
         if [ -z "$m" ]; then
                 echo "Missing memory node in $i"
          fi

done

So it should be pretty safe to just remove the memory node entry in the skeleton files. Unless I have missed something with the script above.

Quoted 2 lines

You've got to make sure they have 'device_type = "memory";' which they could rely on inheriting.

BTW, you could add this as a check to dtc and then it will find all the missing ones for you.