Hi, On 28 July 2017 at 04:45, Heinrich Schuchardt <xypron.g...@gmx.de> wrote: > On 07/28/2017 06:19 AM, Simon Glass wrote: >> Hi, >> >> On 18 July 2017 at 12:17, Heinrich Schuchardt <xypron.g...@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.g...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot