On Thu, Oct 05, 2017 at 10:09:39AM -0500, Rob Herring wrote:
> 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.
Yes, dealing with all assembly is difficult in that case, over in U-Boot
we have 'most' covered with manual labeling but ENTRY/ENDPROC got too
complex. Oh well, I guess it's less of a concern in the kernel.
--
Tom
Attachment:
signature.asc
Description: PGP signature
