On 09/18/2017 12:59 AM, Simon Glass wrote: > This function repeats data structures provided by driver model. They are > only created once so can be stale if the EFI loader is called twice (e.g. > for testing or on boot failure). > > Add a TODO to address this. It should be possible to attach EFI devices > and data structures to driver-model devices and avoid having a parallel > set of data structures. > > Signed-off-by: Simon Glass <s...@chromium.org> > --- > > cmd/bootefi.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/cmd/bootefi.c b/cmd/bootefi.c > index 9aa588eb1b..ee07733e3e 100644 > --- a/cmd/bootefi.c > +++ b/cmd/bootefi.c > @@ -109,6 +109,10 @@ static struct efi_object bootefi_device_obj = { > /** > * efi_init_obj_list() - Initialize and populate EFI object list > * > + * TODO(s...@chromium.org): Move this to a dynamic list based on driver > model, > + * so that it does not need to be created before running EFI applications > + * and updates when devices change. > + *
I am not quite sure if by dynamic list you refer to linker generated lists or to hot plugging. The UEFI spec 2.7 has a chapter on "Hot-Plug Events". This would add a lot of complexity. I do not think that we currently need it. The object list also gets new entries created by the EFI application via calling InstallMultipleProtocolInterfaces of InstallProtocolInterface with *handle == NULL. > * @return 0 if OK, -ve on error (in which case it prints a message) > */ > static int efi_init_obj_list(void) > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot