Patch 1/2 looks fine, but 2/2 reverts the following commit:
==========================
commit 41751659d0650c4effdd598f26febba39aeaf082
Author: Andrei Gherzan <[email protected]>
Date: Mon Aug 22 19:55:10 2022 +0200
efi.cfg: Drop ACPI dependency
On X86 this will have no impact as CONFIG_ACPI is enabled by default. On
the other hand, ARM64 would be affected as they don't have the same
default. The defconfig for arm64 recommends CONFIG_ACPI and this patch
follows this recommendation in the qemuarm64 bsp configuration to fix
ACPI-only EFI boots on this arch.
arm (32bit) would also be unaffected as there is no ACPI support there
at all. And this unconditional drop (CONFIG_ACPI) will actually fix a
configuration warning when enabling EFI on a arm (32bit) machine:
[INFO]: config 'CONFIG_ACPI' was set, but it wasn't assignable, check
(parent) dependencies
Signed-off-by: Andrei Gherzan <[email protected]>
Signed-off-by: Bruce Ashfield <[email protected]>
diff --git a/bsp/qemuarm64/qemuarm64.cfg b/bsp/qemuarm64/qemuarm64.cfg
index ef8d3ed023d..03fdc58cccf 100644
--- a/bsp/qemuarm64/qemuarm64.cfg
+++ b/bsp/qemuarm64/qemuarm64.cfg
@@ -32,3 +32,10 @@ CONFIG_RTC_DRV_PL031=y
# PCI configs, needed for virtio-rng (and others)
CONFIG_PCI=y
CONFIG_PCI_HOST_GENERIC=y
+
+# arm64 defconfig suggests CONFIG_ACPI as default because it won't be
enabled
+# with CONFIG_EFI - even though ACPI-only ARM64 EFI boots would break
+# otherwise. We also do the same here as a sane default.
+CONFIG_ARCH_SUPPORTS_ACPI=y
+CONFIG_ACPI=y
+
diff --git a/cfg/efi.cfg b/cfg/efi.cfg
index d3dfd603dc5..d729cbe9fc7 100644
--- a/cfg/efi.cfg
+++ b/cfg/efi.cfg
@@ -3,7 +3,6 @@
# Dependencies
CONFIG_PCI=y
-CONFIG_ACPI=y
# Enable basic EFI support
CONFIG_EFI=y
===============
So what's the right path ? We could potentially declare the option
non-hardware so the warning doesn't come back. More BSPs may need
to have the option added to them, if we are seeing boot issues. But
constantly adding an option to many BSPs does indicate that it could
be enabled in a more generic place.
We could also create an edk2 fragment, and just have it include
efi and add this option ? And then BSPs we want to support edk2
could include that ? That at least gets us some abstraction and
assigns a meaningful name to the feature we are trying to enable.
Bruce
In message: [yocto-kernel-cache][master/yocto-6.1 PATCH 2/2] efi: add ACPI
enablement
on 28/02/2023 Jon Mason wrote:
> CONFIG_ACPI is needed for qemuarm and qemuarm64 kernels to boot edk2.
> Since this is only needed for edk2, add this to the efi config fragment.
>
> Signed-off-by: Jon Mason <[email protected]>
> ---
> cfg/efi.cfg | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/cfg/efi.cfg b/cfg/efi.cfg
> index d729cbe9fc78..482e622bce97 100644
> --- a/cfg/efi.cfg
> +++ b/cfg/efi.cfg
> @@ -8,3 +8,6 @@ CONFIG_PCI=y
> CONFIG_EFI=y
> CONFIG_EFI_STUB=y
> CONFIG_EFIVAR_FS=y
> +
> +# While you can do EFI with device tree, the vast majority do ACPI
> +CONFIG_ACPI=y
> --
> 2.30.2
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#12190):
https://lists.yoctoproject.org/g/linux-yocto/message/12190
Mute This Topic: https://lists.yoctoproject.org/mt/97296889/21656
Group Owner: [email protected]
Unsubscribe:
https://lists.yoctoproject.org/g/linux-yocto/leave/6687884/21656/624485779/xyzzy
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
