[U-Boot] libfdt: make fdt_increase_size() available to everyone

[Timur Tabi]

On Tue, May 18, 2010 at 5:20 PM, Wolfgang Denk <wd at denx.de> wrote:

>> And again, the point *I* am trying to make is that it's okay to put the onus
>> of that check on the *caller* of fdt_increase_size(), and not on
>> fdt_increase_size() itself.
>
> OK. I have no problem with that. I am just missing this other part of
> the required changes in your patch.

I'm not ready to submit any code that calls fdt_increase_size() yet.
I'm just trying to create the infrastructure here so that I can be
sure that my in-house code is correct.  If this patch is rejected
because there's a better way to increase the size of an fdt, then I
need to know that *now*.

>> But that is only meaningful if the fdt is allocated via an lmb, which is not
>> true in case #2.  In case #2, there is no allocation of memory, so there's
>> no way to know within fdt_increase_size()!
>
> Maybe. But there is still case #1, where we have a real problem, and I
> will not accept your patch without seing this problem properly
> addressed.

And I said that we'll handle this by setting a new value of
CONFIG_SYS_FDT_PAD.  This will ensure that the initial memory
allocation is large enough.

Technically speaking, even without my patch we already have the
problem that bothers you.  When boot_relocate_fdt() allocates the LMB,
it gives it an additional buffer of 12KB.  There's nothing stopping
some code from calling fdt_setprop() and/or fdt_add_subnode()  a
thousand times, which will cause the fdt to grow outside of the
allocated area.

-- 
Timur Tabi
Linux kernel developer at Freescale