hello Heinrich,
On Fri, 28 Feb 2025 at 16:23, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
>
> On 28.02.25 11:34, Sughosh Ganu wrote:
> > hi,
> > The logic in efi_install_fdt() is such that with the
> > EFI_FDT_USE_INTERNAL passed as a parameter to the function, the EFI
> > configuration table is first checked to see if a device-tree(DT) has
> > already been installed as the configuration table, and in case a table
> > is found, the function returns without any other changes. However,
> > there might be scenarios where the earlier installed configuration
> > table might not be up-to-date, and in need of modification. One such
> > scenario is that of adding a pmem node to the DT that is to be passed
> > on to the OS. There could thus be a scenario where a DT that is
> > installed as a configuration table does not have the pmem node, or it
> > might have the wrong/stale values for the pmem node. Should there be
> > some logic to indicate that the configuration table needs to be
> > re-installed afresh so that these scenarios can be handled. Thoughts?
> >
> > -sughosh
>
>
> Hello Sughosh,
>
> The logic dates back to
> 6182495e101f ("efi_loader: need either ACPI table or device tree")
>
> There are more scenarios where keeping the prior device-tree may be wrong:
>
> We could have a first boot option specifying a device-tree where the EFI
> binary returns to U-Boot and a second boot option tried afterwards that
> comes without device-tree.
>
> So we should always install a new device-tree.
>
> I wonder if in copy_fdt() we should avoid a memory leak by keeping track
> of a prior allocation by copy_fdt() in a static variable.
Yes, that would have to be handled if we install a new device-tree on
every invocation of efi_install_fdt().
>
> Do you intend to send a patch?
Yes, will take this up. Thanks.
-sughosh
>
> Best regards
>
> Heinrich
