On 11/16/23 19:33, Tom Rini wrote:
On Wed, Nov 15, 2023 at 03:23:50PM +0100, Heinrich Schuchardt wrote:
RISC-V QEMU provides the ACPI tables. We do not need to generate them
ourselves.
Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com>
---
lib/acpi/Makefile | 2 +-
lib/acpi/acpi_writer.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/acpi/Makefile b/lib/acpi/Makefile
index c1c9675b5d..19fa6ac869 100644
--- a/lib/acpi/Makefile
+++ b/lib/acpi/Makefile
@@ -12,7 +12,7 @@ obj-$(CONFIG_$(SPL_)ACPIGEN) += acpi_table.o
obj-y += acpi_writer.o
# With QEMU the ACPI tables come from there, not from U-Boot
-ifndef CONFIG_QEMU
+ifeq ($(CONFIG_QEMU)$(CONFIG_TARGET_QEMU_VIRT),)
The goal here is to say that we have been passed ACPI tables, and not to
generate them, yes? Lets just introduce a symbol which says that and
enable it as needed in both QEMU targets and others as needed please.
These are the conflicting function implementations:
drivers/misc/qfw.c:158:ulong write_acpi_tables(ulong addr)
lib/acpi/acpi_writer.c:72:ulong write_acpi_tables(ulong start_addr)
drivers/misc/Makefile has:
ifdef CONFIG_QFW
obj-y += qfw.o
but inside the driver we find another constraint:
#if defined(CONFIG_GENERATE_ACPI_TABLE) && !defined(CONFIG_SANDBOX)
So probably we should probably have a symbol which is set for
CONFIG_QFW && CONFIG_GENERATE_ACPI_TABLE && !CONFIG_SANDBOX
Maybe call it CONFIG_QFW_ACPI, "Read ACPI tables from QEMU".
Best regards
Heinrich
