On the sandbox I run:
=> setenv efi_selftest block device
=> bootefi selftest
and see the following output:
** Bad device specification host 0 **
Couldn't find partition host 0:0
Cannot read EFI system partition
Running
=> lsblk
yields
Block Driver Devices
-----------------------------
efi_blk : efiloader 0
ide_blk : <none>
mmc_blk : mmc 2, mmc 1, mmc 0
nvme-blk : <none>
sandbox_host_blk : <none>
scsi_blk : <none>
usb_storage_blk : <none>
virtio-blk : <none>
So a efi_blk device was mistaken for a host device.
I continue with
=> host bind 0 ../sandbox.img
=> ls host 0:1
and get the following output:
13 hello.txt
7 u-boot.txt
2 file(s), 0 dir(s)
This is the content of efiblock 0:1 and not of host 0:1 (sic!).
The uclass of the parent device is irrelevant for the determination of the
uclass of the block device. We must use the uclass stored in the block
device descriptor.
This issue has been raised repeatedly:
[PATCH 1/1] block: fix blk_get_devnum_by_typename()
https://lore.kernel.org/u-boot/[email protected]/
[PATCH 1/1] blk: simplify blk_get_devnum_by_typename()
https://lore.kernel.org/u-boot/[email protected]/
Signed-off-by: Heinrich Schuchardt <[email protected]>
---
drivers/block/blk-uclass.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/block/blk-uclass.c b/drivers/block/blk-uclass.c
index 7d12d5413f..8cb1398624 100644
--- a/drivers/block/blk-uclass.c
+++ b/drivers/block/blk-uclass.c
@@ -133,12 +133,8 @@ struct blk_desc *blk_get_devnum_by_uclass_idname(const
char *uclass_idname, int
if (desc->devnum != devnum)
continue;
- /* Find out the parent device uclass */
- if (device_get_uclass_id(dev->parent) != uclass_id) {
- debug("%s: parent uclass %d, this dev %d\n", __func__,
- device_get_uclass_id(dev->parent), uclass_id);
+ if (desc->uclass_id != uclass_id)
continue;
- }
if (device_probe(dev))
return NULL;
--
2.37.2
