[PATCH] devicetree: Enable generation of __symbols__ in all dtb files

[Tom Rini]

With support for stacked overlays being part of libfdt it is now
possible and likely that overlays which require __symbols__ will be
applied to the dtb files generated by the kernel.  This is done by
passing -@ to dtc.  This does increase the filesize (and resident memory
usage) based on the number of __symbol__ entries added to match the
contents of the dts.

Cc: Rob Herring <robh+dt@xxxxxxxxxx>
Cc: Frank Rowand <frowand.list@xxxxxxxxx>
Cc: Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx>
Cc: Michal Marek <mmarek@xxxxxxxx>
Cc: Pantelis Antoniou <pantelis.antoniou@xxxxxxxxxxxx>
Cc: devicetree@xxxxxxxxxxxxxxx
Cc: linux-kernel@xxxxxxxxxxxxxxx
CC: linux-kbuild@xxxxxxxxxxxxxxx
Signed-off-by: Tom Rini <trini@xxxxxxxxxxxx>
---
In order for a dtb file to be useful with all types of overlays, it
needs to be generated with the -@ flag passed to dtc so that __symbols__
are generated.  This however is not free, and increases the resulting
dtb file by up to approximately 50% today.  In the current worst case
this is moving from 88KiB to 133KiB.  In talking with Frank about this,
he outlined 3 possible ways (with the 4th option of something else
entirely).

1. Make passing -@ to dtc be dependent upon some CONFIG symbol.
2. In the kernel, if the kernel does not have overlay support, discard
the __symbols__ information that we've been passed.
3. Have the bootloader pass in, or not, __symbols__ information.

This patch is an attempt to implement something between the 3rd option
and a different, 4th option.  Frank was thinking that we might introduce
a new symbol to control generation of __symbol__ information for option
1.  I think this gets the usage backwards and will lead to confusion
among users and developers.

My proposal is that we do not want __symbols__ existence to be dependent
on some part of the kernel configuration for a number of reasons.
First, this is out of step with the rest of how dtbs are created today
and more importantly, thought about.  Today, all dtb content is
independent of CONFIG options.  If you build a dtb from a given kernel
tree, everyone will agree on the result.  This is part of the "contract"
on passing old kernels and new dtb files even.

Second, I think this is out of step with how a lot of overlay usage will
occur.  My thinking is that with maximally useful overlays being
available in mainline, lots of use-cases that we have today that result
in a number of DTS files being included can become just overlays.  This
is true in terms of not only evaluation kits but also when these systems
are turned into custom hardware.  This is even more true for SoM based
systems where a physical widget would be a SoM + carrier overlay +
custom parts overlay.  These cases are going to be resolved with
overlays being applied outside of the kernel.

Signed-off-by: Tom Rini <trini@xxxxxxxxxxxx>
---
 drivers/of/unittest-data/Makefile | 5 -----
 scripts/Makefile.lib              | 3 +++
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/of/unittest-data/Makefile b/drivers/of/unittest-data/Makefile
index 6e00a9c69e58..70731cfe8900 100644
--- a/drivers/of/unittest-data/Makefile
+++ b/drivers/of/unittest-data/Makefile
@@ -11,8 +11,3 @@ targets += overlay_base.dtb overlay_base.dtb.S
 .PRECIOUS: \
 	$(obj)/%.dtb.S \
 	$(obj)/%.dtb
-
-# enable creation of __symbols__ node
-DTC_FLAGS_overlay := -@
-DTC_FLAGS_overlay_bad_phandle := -@
-DTC_FLAGS_overlay_base := -@
diff --git a/scripts/Makefile.lib b/scripts/Makefile.lib
index 58c05e5d9870..a1f4a6b29d75 100644
--- a/scripts/Makefile.lib
+++ b/scripts/Makefile.lib
@@ -293,6 +293,9 @@ DTC_FLAGS += -Wnode_name_chars_strict \
 	-Wproperty_name_chars_strict
 endif
 
+# enable creation of __symbols__ node
+DTC_FLAGS += -@
+
 DTC_FLAGS += $(DTC_FLAGS_$(basetarget))
 
 # Generate an assembly file to wrap the output of the device tree compiler
-- 
1.9.1