Re: [PATCH 1/2] scripts/dtc: add fdt_overlay.c and fdt_addresses.c to sync script

[Rob Herring]

On Thu, Oct 5, 2017 at 9:39 AM, Tom Rini <trini@xxxxxxxxxxxx> wrote:
> On Tue, Oct 03, 2017 at 05:23:28PM -0500, Rob Herring wrote:
>> On Tue, Oct 3, 2017 at 5:04 PM, Tom Rini <trini@xxxxxxxxxxxx> wrote:
>> > On Tue, Oct 03, 2017 at 01:31:17PM -0500, Rob Herring wrote:
>> >
>> >> libfdt has gained some new files. We need to include them in the
>> >> kernel's copy.
>> >>
>> >> Reported-by: Kyle Yan <kyan@xxxxxxxxxxxxxx>
>> >> Signed-off-by: Rob Herring <robh@xxxxxxxxxx>
>> >> ---
>> >>  scripts/dtc/update-dtc-source.sh | 4 +++-
>> >>  1 file changed, 3 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/scripts/dtc/update-dtc-source.sh b/scripts/dtc/update-dtc-source.sh
>> >> index b8ebcc6722d2..f3e5c596050a 100755
>> >> --- a/scripts/dtc/update-dtc-source.sh
>> >> +++ b/scripts/dtc/update-dtc-source.sh
>> >> @@ -34,7 +34,9 @@ DTC_SOURCE="checks.c data.c dtc.c dtc.h flattree.c fstree.c livetree.c srcpos.c
>> >>               srcpos.h treesource.c util.c util.h version_gen.h Makefile.dtc \
>> >>               dtc-lexer.l dtc-parser.y"
>> >>  DTC_GENERATED="dtc-lexer.lex.c dtc-parser.tab.c dtc-parser.tab.h"
>> >> -LIBFDT_SOURCE="Makefile.libfdt fdt.c fdt.h fdt_empty_tree.c fdt_ro.c fdt_rw.c fdt_strerror.c fdt_sw.c fdt_wip.c libfdt.h libfdt_env.h libfdt_internal.h"
>> >> +LIBFDT_SOURCE="Makefile.libfdt fdt.c fdt.h fdt_addresses.c fdt_empty_tree.c \
>> >> +             fdt_overlay.c fdt_ro.c fdt_rw.c fdt_strerror.c fdt_sw.c \
>> >> +             fdt_wip.c libfdt.h libfdt_env.h libfdt_internal.h"
>> >
>> > Should there be a patch #3 to update the kernel libfdt to include these
>> > new files that we're copying in too?  That seems to be the main user
>> > in-tree of the libfdt C files, aside from the 'libfdt' targets under
>> > arch/{arm,powerpc}/boot/  Thanks!
>>
>> Yes, good point. But we can add them when someone wants to use them.
>> Adding them to the build will bloat the kernel because libfdt doesn't
>> get built as a static lib (another problem to solve).
>
> Well, isn't the kernel starting to more widely use
> -ffunction-sections/-fdata-sections/--gc-unused-sections ?

Unfortunately, no. Nico Pitre did some work there, and I think it
helps some but is incomplete because of how some of the kernel's
assembly code works.

Rob