Hi Heinrich, On Thu, 16 Nov 2023 at 12:43, Heinrich Schuchardt <heinrich.schucha...@canonical.com> wrote: > > 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".
Yes that sounds good. Regards, Simon
