Timur Tabi wrote: > On Sat, May 15, 2010 at 9:11 PM, Gerald Van Baren <gvb.ub...@gmail.com> wrote: > >> The code has one pre-existing weakness that bothers me: if there is >> something following the FDT blob, it will get overwritten by the >> increased blob. One way around this would be to malloc() a new memory >> space and move and expand the blob to the new space. The first time >> this was done, the original blob should not be free()ed since it wasn't >> malloc()ed, but the second and subsequent times it should be free()ed. > > But then how does the caller know where the new blob is? When I call > fdt_increase_size(), I pass it the address of a blob that I'm > modifying. After the function returns, my value of 'fdt' is no longer > valid.
Oops, yes, that is a pretty fatal flaw. >> I've added this to your patch, but have *NOT* execution tested it. Does >> this addition (a) make sense and (b) work? > > I was expecting the caller of fdt_increase_size() to know that the > space after the fdt is available. OK. I'll <acked-by> the original patch. The best way to incorporate the patch would be for Kumar (I assume) to pick up the libfdt change with the Freescale change that needs it so that the changes are inherently coordinated. gvb _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
