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

[Walter Lozano]

Hi Simon,

On 7/11/19 13:42, Simon Glass wrote:
> 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


Thanks for pointing to this patchset, it looks like the approach I was 
looking for to overcome the the issue with libfdt and other dependencies 
in a proper way. I'll try to use your same approach in other drivers.


>
> [..]
>
> Regards,
> Simon


Regards,


Walter