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

[Simon Glass]

Hi Walter,

On Thu, 7 Nov 2019 at 06:30, Walter Lozano <walter.lozano at collabora.com> wrote:
>
> Hi Ezequiel,
>
> On 5/11/19 20:30, Ezequiel Garcia wrote:
> > 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 idea behind this patch is to break the dependency of libfdt when it
> is not needed. A specific example of this is found when building SPL
> using OF_PLATDATA, which basically removes DT so there is no sense of
> having libfdt present in SPL. Unfortunately as OF_PLATDATA has little
> support, drivers tend to assume that there is a DT and try to query
> different properties, which of course return no data. In this context,
> the idea is to keep the same behavior but reducing the SPL size, while
> trying to improve drivers.

I actually sent a similar patch in September but never fixed the
problems it caused. I just resent it as a series:

http://patchwork.ozlabs.org/project/uboot/list/?series=141416

[..]

Regards,
Simon