On Tue, May 18, 2010 at 5:20 PM, Wolfgang Denk <w...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot