Hi Heinrich,
On 17 September 2017 at 22:47, Heinrich Schuchardt <xypron.g...@gmx.de> wrote:
> 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.
Here I am referring to what I see as duplicate device tables, brought
in from driver model. I am wondering if we can make the EFI info come
from the driver-model directly.
Regards,
Simon
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
