[U-Boot] [PATCH v2 2/7] efi_loader: implement multiple event support

[Simon Glass]

Hi,

On 28 July 2017 at 04:45, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
> On 07/28/2017 06:19 AM, Simon Glass wrote:
>> Hi,
>>
>> On 18 July 2017 at 12:17, Heinrich Schuchardt <xypron.glpk at gmx.de> wrote:
>>> Up to now the boot time supported only a single event.
>>> This patch now allows four events.
>>>
>>> Signed-off-by: Heinrich Schuchardt <xypron.glpk at gmx.de>
>>> ---
>>> v2
>>>         add TPL constants
>>>         consider multiple events in efi_wait_for_event
>>>         move notification to new function efi_signal_event
>>> ---
>>>  include/efi_api.h             |  13 ++-
>>>  include/efi_loader.h          |  24 ++++++
>>>  lib/efi_loader/efi_boottime.c | 195 ++++++++++++++++++++++++++++--------------
>>>  3 files changed, 168 insertions(+), 64 deletions(-)
>>
>> Could this use driver model for the events? There is a notify method
>> which could be a device operation.
>>
>> Regards,
>> Simon
>>
> UEFI events can be signaled between different parts of an UEFI
> application. This does not necessarily involve any drivers.
>
> So I think this is not the right place to apply the driver model.
>
> If you would like to move more UEFI coding to the driver model you could
> think about the UEFI device drivers (network, graphical output, console,
> file system). Having all UEFI device drivers in one uclass might be an
> interesting direction. Can you provide a design suggestion or patches?

Perhaps we could start with just the console since it is simple.

One idea is to have a UEFI device as a child of the serial device, in
a single UCLASS_EFI as you suggest. Then you can iterate through
devices in that uclass to find those which are children of a serial
port device (UCLASS_SERIAL).

I suspect that would allow the ad-hoc UEFI data structures to not be
needed. Instead, information could be returned 'on the fly' by looking
up DM data structures.

I have proposed this a few times. I worry that the direction the code
is taking is leading to an unnecessary fork between UEFI support and
the rest of U-Boot, which is moving to driver model. If this can be
resolved, then it will be easier to adjust things now than later.

Regards,
Simon