Hi,
On 28 July 2017 at 04:45, Heinrich Schuchardt xypron.glpk@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@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@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