[U-Boot] [RFC PATCH] dm: core: Remove libfdt dependency when unnecessary

[Ezequiel Garcia]

On Tue, 5 Nov 2019 at 15:12, Walter Lozano <walter.lozano at collabora.com> wrote:
>
> Hi Ezequiel,
>
> On 5/11/19 13:56, Ezequiel Garcia wrote:
> > Hello Walter,
> >
> > Thanks for the patch.
> >
> > On Tue, 5 Nov 2019 at 12:27, Walter Lozano <walter.lozano at collabora.com> wrote:
> >> The support of libfdt should only be needed when OF_CONTROL
> >> is enabled and OF_PLATDATA is not, as in other cases there is no
> >> DT file to query.
> >>
> >> This patch fixes this dependency allowing to save some space.
> >>
> > Can you add some more information about the space saving?
>
>
> Sure, I will add some additional information about the static footprint.
> However according to my understanding the impact depends on how well
> different drivers supports features like OF_PLATDATA. For instance, in
> my current configuration it saves 2 KB.
>

Not sure I follow you. This patch adds a condition which adds/removes code
based on some conditions. So, it should depend on the arch, but otherwise
the reduction is an invariant as it just depend on the size of the
code that is being
added/removed. Or am I missing something?

>
> > The ./scripts/bloat-o-meter will help you get some info
> > on static footprint.
>
>
> Thanks for your suggestion. I think you are pointing to a script found
> in the Linux kernel, right?

Ah, yes. I have this script imported on my U-Boot repo, so I assumed
it was here as well.

> I also think it could be useful to have a
> deep understanding on how the static footprint of some .o files changes,
> but it won't give us much information about the end result of the binary
> image, which is affected by the dependencies and compiler/linker
> optimizations. Is this correct?
>

Normally, bloat-o-meter gives you a rough idea and allows you to
weigh code complexity vs. size reduction.

>
> >> Signed-off-by: Walter Lozano <walter.lozano at collabora.com>
> >> ---
> >>   drivers/core/ofnode.c | 132 +++++++++++++++++++++++++++++++++++++--
> >>   include/dm/read.h     | 141 ++++++++++++++++++++++++++++++++++++++++++
> >>   2 files changed, 267 insertions(+), 6 deletions(-)
> >>
> > You should try to avoid adding #ifdefery to the code. Normally,
> > the way to ifdef code is by having this in a header:
> >
> > #ifdef CONFIG_FOO
> > int foo_feature_optional(struct foo *priv);
> > #else
> > static inline int foo_feature_optional(struct foo *priv)
> > {
> >          return 0;
> > }
> > #endif
> >
> > The user of foo_feature_optional shouldn't be bothered with
> > FOO being enabled or not. Pushing ifdefs away from .c to .h
> > is a common pattern, well described in a classic old article:
> >
> > http://www.literateprogramming.com/ifdefs.pdf
> >
> > Do you think you can try to rework the patch to reduce its impact
> > as much as possible?
>
>
> Thanks for your review and your suggestions, I will be happy to rework
> this to improve it.
>
>
> The intention of this RFC is to get some feedback about if this is
> something worth to be added and if this is the right approach. The use
> of OF_PLATDATA is quite limited as it needs drivers to support it, which
> will probably be a long process. Enabling it but having some drivers to
> query DT properties has no sense and requires additional dependencies,
> like libfdt.
>
> Also I think it should be possible to remove some extra components but
> it will require extra work to avoid break some configurations.
>

It's always good to shave off bytes, specially in SPL -- not so much
in proper U-Boot, right?

BTW, what is the motivation of this patch: which platform are you
working on, and
how is it size constrained?

Thanks,
Ezequiel