On Tue, May 18, 2010 at 5:20 PM, Wolfgang Denk wd@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.