From: Tom Rini <trini@konsulko.com>
To: u-boot@lists.denx.de
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Subject: [PATCHv2 3/6] efi_loader: Depend on BLK
Date: Tue, 14 Jan 2025 19:22:10 -0600 [thread overview]
Message-ID: <20250115012322.215243-4-trini@konsulko.com> (raw)
In-Reply-To: <20250115012322.215243-1-trini@konsulko.com>
In reworking the BLK usage in Kconfig, I found there's a few issues with
EFI_LOADER=y and BLK=n. In general, we can easily say that
lib/efi_loader/efi_file.c also should only be built with CONFIG_BLK.
That however leaves the bootmgr code, eficonfig code and then parts of
efi_device_path.c, efi_boottime.c and efi_setup.c which functionally
depend on BLK. While these calls can be if'd out, I'm unsure if the
result is usable. So rather than leave that buildable and imply that it
is, I'm leaving that combination non-buildable and commenting that
EFI_LOADER depends on BLK in the Kconfig currently.
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
Changes in v2:
- None.
---
lib/efi_loader/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/efi_loader/Kconfig b/lib/efi_loader/Kconfig
index c46ffe3a9d89..798dced475e0 100644
--- a/lib/efi_loader/Kconfig
+++ b/lib/efi_loader/Kconfig
@@ -8,13 +8,14 @@ config EFI_LOADER
SYS_CPU = armv7 || \
SYS_CPU = armv8) || \
X86 || RISCV || SANDBOX)
+ # We have not fully removed the requirement for some block device
+ depends on BLK
# We need EFI_STUB_64BIT to be set on x86_64 with EFI_STUB
depends on !EFI_STUB || !X86_64 || EFI_STUB_64BIT
# We need EFI_STUB_32BIT to be set on x86_32 with EFI_STUB
depends on !EFI_STUB || !X86 || X86_64 || EFI_STUB_32BIT
depends on !EFI_APP
default y if !ARM || SYS_CPU = armv7 || SYS_CPU = armv8
- select BLK
select CHARSET
# We need to send DM events, dynamically, in the EFI block driver
select DM_EVENT
--
2.43.0
next prev parent reply other threads:[~2025-01-15 1:23 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-20 22:22 [PATCH 0/6] Rework the BLK symbol usage in Kconfig Tom Rini
2024-12-20 22:22 ` [PATCH 1/6] drivers/mmc/Kconfig: Remove extraneous BLK dependencies Tom Rini
2024-12-22 23:49 ` Jaehoon Chung
2025-01-14 13:25 ` Quentin Schulz
2025-01-14 16:58 ` Tom Rini
2024-12-20 22:22 ` [PATCH 2/6] drivers/mmc/Kconfig: Make DM_MMC a hidden symbol Tom Rini
2024-12-23 18:26 ` Peter Robinson
2025-01-14 13:43 ` Quentin Schulz
2025-01-14 16:58 ` Tom Rini
2024-12-20 22:22 ` [PATCH 3/6] efi_loader: Depend on BLK Tom Rini
2024-12-20 22:50 ` Heinrich Schuchardt
2024-12-20 22:22 ` [PATCH 4/6] blk: Make block subsystems select BLK Tom Rini
2024-12-23 18:31 ` Peter Robinson
2024-12-23 18:53 ` Tom Rini
2025-01-14 13:45 ` Quentin Schulz
2025-01-14 16:58 ` Tom Rini
2025-01-15 17:38 ` Quentin Schulz
2024-12-20 22:22 ` [PATCH 5/6] mtd: Correct dependency of BLK Tom Rini
2024-12-23 18:27 ` Peter Robinson
2025-01-14 13:46 ` Quentin Schulz
2024-12-20 22:22 ` [PATCH 6/6] block: Remove "select BLK" from non-block drivers Tom Rini
2024-12-23 18:26 ` Peter Robinson
2025-01-14 13:53 ` Quentin Schulz
2025-01-14 16:59 ` Tom Rini
2025-01-15 17:49 ` Quentin Schulz
2025-01-15 20:20 ` Tom Rini
2025-01-16 9:21 ` Quentin Schulz
2025-01-16 14:33 ` Tom Rini
2025-01-15 1:22 ` [PATCHv2 0/6] Rework the BLK symbol usage in Kconfig Tom Rini
2025-01-15 1:22 ` [PATCHv2 1/6] drivers/mmc/Kconfig: Remove extraneous BLK dependencies Tom Rini
2025-01-15 1:22 ` [PATCHv2 2/6] drivers/mmc/Kconfig: Make DM_MMC a hidden symbol Tom Rini
2025-01-15 1:22 ` Tom Rini [this message]
2025-01-15 1:22 ` [PATCHv2 4/6] blk: Make block subsystems select BLK Tom Rini
2025-01-15 17:51 ` Quentin Schulz
2025-01-15 18:28 ` Tom Rini
2025-01-15 1:22 ` [PATCHv2 5/6] mtd: Correct dependency of BLK Tom Rini
2025-01-15 1:22 ` [PATCHv2 6/6] block: Remove "select BLK" from non-block drivers Tom Rini
2025-01-21 4:49 ` [PATCHv2 0/6] Rework the BLK symbol usage in Kconfig Tom Rini
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=20250115012322.215243-4-trini@konsulko.com \
--to=trini@konsulko.com \
--cc=u-boot@lists.denx.de \
--cc=xypron.glpk@gmx.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