Skip to contentSkip to conversation

efi: clean up Kconfig dependencies on CONFIG_EFI

PATCH In review Ard Biesheuvel 2 participants 2 messages May 28, 2022 – Jun 3, 2022 EFI

lore
Share & tools
lore

Ard Biesheuvel

author maintainer
#0 lore raw

PATCH 1/1 efi: clean up Kconfig dependencies on CONFIG_EFI

Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface.

So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment.

Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86)

Cc Geert Uytterhoeven <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Masahiro Yamada <[email protected]>
---
 drivers/firmware/Makefile    |  3 +-
 drivers/firmware/efi/Kconfig | 52 +++++++++-----------
 2 files changed, 25 insertions(+), 30 deletions(-)
drivers/firmware/Makefile +1 -2
index 4e58cb474a68..dca73826e09a 100644
@@ -31,8 +31,7 @@ obj-y				+= broadcom/
 obj-y				+= cirrus/
 obj-y				+= meson/
 obj-$(CONFIG_GOOGLE_FIRMWARE)	+= google/
-obj-$(CONFIG_EFI)		+= efi/
-obj-$(CONFIG_UEFI_CPER)		+= efi/
+obj-y				+= efi/
 obj-y				+= imx/
 obj-y				+= psci/
 obj-y				+= smccc/
drivers/firmware/efi/Kconfig +24 -28

80 lines not on this page · raw message

Signature · 1 line
2.30.2
Reviewed-by on v1 1/1
#1 lore raw

Hello Ard,

Quoted 13 lines · Ard Biesheuvel

Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface.

So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment.

Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86)

Quoted 5 lines
Cc Geert Uytterhoeven <[email protected]>
Cc Javier Martinez Canillas <[email protected]>
Cc Masahiro Yamada <[email protected]>

---

This makes sense to me.

Signature · 5 lines
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat