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

[Timur Tabi <timur@freescale.com>]

Wolfgang Denk wrote:

> I think the places where strcat() is used actually try and make sure
> to have enough room in the target buffer; also, almost all of themn
> appent static strigs with well-known sizes only.
> 
> You talked about inserting user-supplied data of unknown size.

Yes and no.  The data is supplied by the user, but it will also be limited
in size by a compile-time constant.  In this case, the firmware should come
only from Freescale, and the limit is double the size of current firmware,
so that should be enough to handle all situations, now and in the future.

>> I could, for instance, add an lmb parameter to fdt_increase_size(), but this
>> will only apply in instances where the fdt exists inside an lmb. There is no
>> lmb_realloc() function, so the most I can do is return an error if the lmb
>> isn't big enough.
> 
> You could add a lmb_realloc() function...

I'm not sure that would work in the context of the way lmb regions are
currently being used.  reallocating an lmb will probably require moving it
as well, and the caller of lmb_realloc() might not be able to handle updated
pointers.

>> The problem is that by the time the code needs to resize the fdt, it has
>> long since forgotten about the lmb.  We would need to modify
> 
> You could add code so that this information gets stored in a suitable
> way.

You make a lot of statements saying that I can do this and I can do that,
but you provide no examples.  Have you even looked at the code to see what
such a change would require?

I believe that modifying the parameters for fdt_board_setup() is too
intrusive of a change.  So the only available spot where we could put the
lmb pointers is in the bd_t structure.  And my understanding is that this
structure is already too fragile and should not be modified.

>> ft_board_setup() to take an lmb as a parameter, but that would require
>> changes to almost 30 boards!
> 
> There have been changes in the past that required changes to many,
> many more boards.  What exactly is the problem with doing this?

It's not worth it.  It would be easier for me to take the code of
fdt_increase_size() and just copy it into boot_relocate_fdt().

In fact, I think that's what I will do.  I thought I was being polite by
simply re-using an existing function, but I'd rather just copy the code into
boot_relocate_fdt() if it means I don't have to argue with you about it.

-- 
Timur Tabi
Linux kernel developer at Freescale