The EFI doesn't allow removal of handles, unless all hosted protocols
are cleanly removed. Our efi_delete_handle() is a bit intrusive.
Although it does try to delete protocols before removing a handle,
it doesn't care if that fails. Instead it only returns an error if the
handle is invalid. On top of that none of the callers of that function
check the return code.
So let's rewrite this in a way that fits the EFI spec better. Instead
of forcing the handle removal, gracefully uninstall all the handle
protocols. According to the EFI spec when the last protocol is removed
the handle will be deleted. Also switch all the callers and check the
return code. Some callers can't do anything useful apart from reporting
an error. The disk related functions on the other hand, can prevent a
medium that is being used by EFI from removal.
The only function that doesn't check the result is efi_delete_image().
But that function needs a bigger rework anyway, so we can clean it up in
the future
Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
The devnum value of the blk_desc structure starts from 0,
current efi_bl_create_block_device() function creates
two "efiblk#0" devices for the cases that blk_find_max_devnum()
returns -ENODEV and blk_find_max_devnum() returns 0(one device
found in this case).
This commit uses blk_next_free_devnum() instead of blk_find_max_devnum().
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Avoid EFI_CALL() by using efi_close_protocol().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
We must always call EFI_EXIT() when returning from an EFIAPI function.
Fixes: 05ef48a248 ("efi_driver: EFI block driver")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Move the registration of events for the addition and removal of block
devices to the block device driver. Here we can add a reference to the
EFI Driver Binding protocol as context.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
For handling added and removed block devices we need to register events
which has to be done when the driver is installed.
This patch only creates an empty init function that will be filled with
code later on. The function needs to be called before any EFI block devices
are used. Move the efi_driver_init() call to early init.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
DisconnectController() is based on the open protocol information created
when the driver opens a protocol with BY_CHILD_CONTROLLER or BY_DRIVER.
To create an open protocol information it is required to supply the handle
of the driver as agent handle. This information is available as field
DriverBindingHandle in the driver binding protocol.
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
* Carve out function efi_bl_create_block_device() from efi_bl_bind().
* Add a check for U-Boot devices to efi_bl_bind().
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
If creating the block device fails,
* delete all created objects and references
* close the protocol interface on the controller
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
We currently have an if_type (interface type) and a uclass id. These are
closely related and we don't need to have both.
Drop the if_type values and use the uclass ones instead.
Maintain the existing, subtle, one-way conversion between UCLASS_USB and
UCLASS_MASS_STORAGE for now, and add a comment.
Signed-off-by: Simon Glass <sjg@chromium.org>
UEFI block devices can either mirror U-Boot's internal devices or be
provided by an EFI application like iPXE.
When ConnectController() is invoked for the EFI_BLOCK_IO_PROTOCOL
interface for such an application provided device we create a virtual
U-Boot block device of type "efi_blk".
Currently we do not call ConnectController() when handles for U-Boot's
internal block devices are created. If an EFI application calls
ConnectController() for a handle relating to an internal block device,
we erroneously create an extra "efi_blk" block device.
E.g. the UEFI shell has a command 'connect -r' which calls
ConnectController() for all handles with device path protocol.
In the Supported() method of our EFI_DRIVER_BINDING_PROTOCOL return
EFI_UNSUPPORTED when dealing with an U-Boot internal device.
Reported-by: Etienne Carriere <etienne.carriere@linaro.org>
Fixes: commit 05ef48a248 ("efi_driver: EFI block driver")
Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Reviewed-by: Etienne Carriere <etienne.carriere@linaro.org>
Tested-by: Etienne Carriere <etienne.carriere@linaro.org>
Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
This is a preparation patch to provide the unified method
to access udevice pointer associated with the EFI handle
by adding udevice pointer into struct efi_object.
The patch also introduces a helper function efi_link_dev()
to link the udevice and EFI handle.
The EFI handles of both EFI block io driver implemented in
lib/efi_loader/efi_disk.c and EFI block io driver implemented
as EFI payload can access the udevice pointer in the struct efi_object.
We can use this udevice pointer to get the U-Boot friendly
block device name(e.g. mmc 0:1, nvme 0:1) through EFI handle.
Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Add efi_disk_probe() function.
This function creates an efi_disk object for a raw disk device (UCLASS_BLK)
and additional objects for related partitions (UCLASS_PARTITION).
So this function is expected to be called through driver model's "probe"
interface every time one raw disk device is detected and activated.
We assume that partition devices (UCLASS_PARTITION) have been created
when this function is invoked.
Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
These names are better used for access to devices provided by an EFI
layer. Use EFI_LOADER instead here, since these are only available in
U-Boot's EFI_LOADER layer.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
This code should never have been added as it builds a new feature on top
of legacy code. This has already been improved with the dependency on BLK.
Add a dependency on DM_ETH also, to avoid needing to deal with this old
code.
Boards which want EFI_LOADER should migrate to driver model first.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We use 'priv' for private data but often use 'platdata' for platform data.
We can't really use 'pdata' since that is ambiguous (it could mean private
or platform data).
Rename some of the latter variables to end with 'plat' for consistency.
Signed-off-by: Simon Glass <sjg@chromium.org>
This construct is quite long-winded. In earlier days it made some sense
since auto-allocation was a strange concept. But with driver model now
used pretty universally, we can shorten this to 'auto'. This reduces
verbosity and makes it easier to read.
Coincidentally it also ensures that every declaration is on one line,
thus making dtoc's job easier.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use logging functions instead of printf() and debug().
Change logging messages for uclass creation and destruction to log_debug().
Reported-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
Two files relies on efi_driver.h to include common.h and dm.h which is
incorrect. The former should always be included in a non-host C file and
the latter should be included if driver model is used.
Signed-off-by: Simon Glass <sjg@chromium.org>
At present dm/device.h includes the linux-compatible features. This
requires including linux/compat.h which in turn includes a lot of headers.
One of these is malloc.h which we thus end up including in every file in
U-Boot. Apart from the inefficiency of this, it is problematic for sandbox
which needs to use the system malloc() in some files.
Move the compatibility features into a separate header file.
Signed-off-by: Simon Glass <sjg@chromium.org>
Use the correct protocol in efi_uc_stop() when detaching the driver from
the controller.
Change the block IO unit test for the block device driver to throw an error
instead of a todo if teardown fails.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
The first functions of the UEFI sub-system are invoked before reaching the
U-Boot shell, e.g. efi_set_bootdev(), efi_dp_from_name(),
efi_dp_from_file(). We should be able to print out device paths for
debugging purposes here.
When printing device paths via printf("%pD\n", dp) this invokes functions
defined as EFIAPI. So efi_save_gd() must be called beforehand.
So let's move the efi_save_gd() call to function initr_reloc_global_data(()
in board_r.c.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Stating the function module is sufficient. We don't need file and line
number. Anyway the format code for the line number was incorrect (should
be %d).
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
part_init() is currently called in every DM BLK driver, either
in its bind() or probe() method. However we can use the BLK
uclass driver's post_probe() method to do it automatically.
Update all DM BLK drivers to adopt this change.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Currently the efi block driver uses priv_auto_alloc_size for the
driver data, however that's only available after the device probe
phase. In order to make it accessible in an earlier phase, switch
to use platdata_auto_alloc_size instead.
This patch is the prerequisite for the follow up patch of DM BLK
driver changes to work with EFI loader.
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Convert the function descriptions to Sphinx style.
efi_driver_init() is cCalled by efi_init_obj_list().
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
Set the DM_FLAG_NAME_ALLOCED flag to avoid a memory leak when the block
device is removed.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
As part of the main conversion a few files were missed. These files had
additional whitespace after the '*' and before the SPDX tag and my
previous regex was too strict. This time I did a grep for all SPDX tags
and then filtered out anything that matched the correct styles.
Fixes: 83d290c56f ("SPDX: Convert all of our single license tags to Linux Kernel style")
Reported-by: Heinrich Schuchardt <xypron.debian@gmx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Change the return type of efi_driver_init() to efi_status_t.
efi_driver_init() calls efi_add_driver() which returns an efi_status_t
value. efi_driver_init() should not subject this value to a conversion to
int losing high bits on 64bit systems.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Signed-off-by: Alexander Graf <agraf@suse.de>
This patch provides
* a uclass for EFI drivers
* a EFI driver for block devices
For each EFI driver the uclass
* creates a handle
* adds the driver binding protocol
The uclass provides the bind, start, and stop entry points for the driver
binding protocol.
In bind() and stop() it checks if the controller implements the protocol
supported by the EFI driver. In the start() function it calls the bind()
function of the EFI driver. In the stop() function it destroys the child
controllers.
The EFI block driver binds to controllers implementing the block io
protocol.
When the bind function of the EFI block driver is called it creates a
new U-Boot block device. It installs child handles for all partitions and
installs the simple file protocol on these.
The read and write functions of the EFI block driver delegate calls to the
controller that it is bound to.
A usage example is as following:
U-Boot loads the iPXE snp.efi executable. iPXE connects an iSCSI drive and
exposes a handle with the block IO protocol. It calls ConnectController.
Now the EFI block driver installs the partitions with the simple file
protocol.
iPXE uses the simple file protocol to load Grub or the Linux Kernel.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[agraf: add comment on calloc len]
Signed-off-by: Alexander Graf <agraf@suse.de>
