On Thu, Aug 31, 2023 at 09:39:52AM +0000, Roman Azarenko wrote:
> > On Mon, 28 Aug 2023 at 02:00, Roman Azarenko
> <roman.azare...@iopsys.eu> wrote:
> > >
> > > On Fri, 2023-08-25 at 12:06 -0600, Simon Glass wrote:
> > > > > @@ -564,9 +564,13 @@ static int fit_extract_data(struct
> > > > > image_tool_params *params, const char *fname)
> > > > > /* Pack the FDT and place the data after it */
> > > > > fdt_pack(fdt);
> > > > >
> > > > > - new_size = fdt_totalsize(fdt);
> > > > > - new_size = ALIGN(new_size, align_size);
> > > > > + unpadded_size = fdt_totalsize(fdt);
> > > > > + new_size = ALIGN(unpadded_size, align_size);
> > > > > fdt_set_totalsize(fdt, new_size);
> > > >
> > > > I didn't know that was allowed...I thought it needed fdt_open_into() ?
> > >
> > > The introduction of fdt_set_totalsize() comes from commit ebfe611be91e
> > > ("mkimage: fit_image: Add option to make fit header align"). The commit
> > > message doesn't describe the choice of this function vs fdt_open_into().
> > >
> > > Personally I'm unable to definitively comment on it. I can only blindly
> > > guess, that because we're only changing the total length of the fdt
> > > struct, and keeping all other fields the same, we don't need to allocate
> > > a new fdt struct with a different size.
> >
> > I am not sure if it would cause problems. I do understand that you
> > didn't write the code. You could copy the people who did (and those
> > that reviewed it) for their input.
> >
>
> @Kever, @Punit, @Tom, could you please comment on this remark by Simon?
> Thank you!I assume that we're given an already well-ordered device tree at this point and so that's why we don't use fdt_open_into to move things and just handle it ourselves at that point in the tool. -- Tom
signature.asc
Description: PGP signature
