From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: barebox@lists.infradead.org
Cc: has@pengutronix.de, Ahmad Fatoum <a.fatoum@pengutronix.de>
Subject: [PATCH 3/3] block: efi: allow disabling /dev/usbdiskX renaming
Date: Thu, 30 Jun 2022 14:40:35 +0200 [thread overview]
Message-ID: <20220630124035.4019644-3-a.fatoum@pengutronix.de> (raw)
In-Reply-To: <20220630124035.4019644-1-a.fatoum@pengutronix.de>
Some buggy UEFI implementations have been observed to not set
EFI_USB_IO protocol on handles that were instantiated from
USB mass storage. This leads to confusing behavior when barebox
uses /dev/usbdisk for some USB sticks and doesn't for some others.
The proper behavior is not relying on the UEFI and instead check
e.g. GUID of the boot disk image:
if [ "$bootsource" = usb ]; then
mydisk = /dev/usbdisk${bootsource_instance}
else
mydisk = /dev/disk${bootsource_instance}
fi
devlookup -v bootdiskguid $mydisk guid
if [ "$bootdiskguid" = "my-guid" ]; then
boot ${mydisk}.1
else
boot boochooser
fi
When going that way, the renaming to usbdisk is just annoying,
so allow disabling it to simplify scripting.
Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
---
drivers/block/Kconfig | 21 +++++++++++++++++++++
drivers/block/Makefile | 2 +-
drivers/block/efi-block-io.c | 3 ++-
3 files changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig
index 68a11438dcf3..625e81a4ec97 100644
--- a/drivers/block/Kconfig
+++ b/drivers/block/Kconfig
@@ -5,3 +5,24 @@ config VIRTIO_BLK
help
This is the virtual block driver for virtio. It can be used with
QEMU based VMMs (like KVM or Xen).
+
+config EFI_BLK
+ bool "EFI block I/O driver"
+ default y
+ depends on EFI_BOOTUP
+
+config EFI_BLK_SEPARATE_USBDISK
+ bool "rename USB devices to /dev/usbdiskX"
+ default y
+ depends on EFI_BLK
+ help
+ EFI block devices will be normally called /dev/diskX. Setting this
+ option will cause block devices instantiated from handles with a
+ EFI_USB_IO protocol to be called /dev/usbdiskX instead. Note that
+ some buggy UEFI implementations have been observed to not do this
+ consistently for all USB mass storage. If you need to absolutely
+ be sure your boot device is a USB mass storage device and you can't
+ fix your UEFI, consider disabling this options and setting a GUID
+ for your disk and checking against it with
+
+ devlookup -v $bootguid /dev/disk$bootsource_instance guid
diff --git a/drivers/block/Makefile b/drivers/block/Makefile
index c50bdc1d02bd..a4e14a559cf7 100644
--- a/drivers/block/Makefile
+++ b/drivers/block/Makefile
@@ -1,3 +1,3 @@
# SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_EFI_BOOTUP) += efi-block-io.o
+obj-$(CONFIG_EFI_BLK) += efi-block-io.o
obj-$(CONFIG_VIRTIO_BLK) += virtio_blk.o
diff --git a/drivers/block/efi-block-io.c b/drivers/block/efi-block-io.c
index 086afb378ab4..120e4d8f1ad2 100644
--- a/drivers/block/efi-block-io.c
+++ b/drivers/block/efi-block-io.c
@@ -140,7 +140,8 @@ static void efi_bio_print_info(struct device_d *dev)
static bool is_bio_usbdev(struct efi_device *efidev)
{
- return efi_device_has_guid(efidev, EFI_USB_IO_PROTOCOL_GUID);
+ return IS_ENABLED(CONFIG_EFI_BLK_SEPARATE_USBDISK) &&
+ efi_device_has_guid(efidev, EFI_USB_IO_PROTOCOL_GUID);
}
static int efi_bio_probe(struct efi_device *efidev)
--
2.30.2
next prev parent reply other threads:[~2022-06-30 12:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-30 12:40 [PATCH 1/3] partitions: efi: register guid device parameter for disk GUID Ahmad Fatoum
2022-06-30 12:40 ` [PATCH 2/3] commands: implement devlookup to find device behind device file Ahmad Fatoum
2022-06-30 15:26 ` Michael Olbrich
2022-07-01 5:24 ` Ahmad Fatoum
2022-07-05 7:45 ` Sascha Hauer
2022-07-05 7:48 ` Ahmad Fatoum
2022-06-30 12:40 ` Ahmad Fatoum [this message]
2022-06-30 13:26 ` [PATCH] fixup! commands: implement new devlookup command Ahmad Fatoum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220630124035.4019644-3-a.fatoum@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=has@pengutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox