On Tue, Nov 21, 2023 at 08:30:34PM +0100, Heinrich Schuchardt wrote: > On 11/21/23 20:00, Tom Rini wrote: > > On Tue, Nov 21, 2023 at 04:27:34PM +0100, Heinrich Schuchardt wrote: > > > > > We have two implementations of write_acpi_tables(). One for writing ACPI > > > tables based on ACPI_WRITER() entries another based on copying tables from > > > QEMU. > > > > > > Create a symbol CONFIG_QFW_ACPI that signifies copying ACPI tables from > > > QEMU and use it consistently. > > > > > > Signed-off-by: Heinrich Schuchardt <heinrich.schucha...@canonical.com> > > > --- > > > v2: > > > new patch > > > --- > > > drivers/misc/Kconfig | 7 +++++++ > > > drivers/misc/qfw.c | 4 ++-- > > > lib/acpi/Makefile | 2 +- > > > lib/acpi/acpi_writer.c | 4 ++-- > > > 4 files changed, 12 insertions(+), 5 deletions(-) > > > > I still feel like this is a weird direction to go in and that: > > > diff --git a/lib/acpi/acpi_writer.c b/lib/acpi/acpi_writer.c > > > index 946f90e8e7..9b9fdc190b 100644 > > > --- a/lib/acpi/acpi_writer.c > > > +++ b/lib/acpi/acpi_writer.c > > > @@ -48,7 +48,7 @@ int acpi_write_one(struct acpi_ctx *ctx, const struct > > > acpi_writer *entry) > > > return 0; > > > } > > > -#ifndef CONFIG_QEMU > > > +#ifndef CONFIG_QFW_ACPI > > > static int acpi_write_all(struct acpi_ctx *ctx) > > > { > > > const struct acpi_writer *writer = > > > @@ -115,7 +115,7 @@ ulong acpi_get_rsdp_addr(void) > > > return map_to_sysmem(gd->acpi_ctx->rsdp); > > > } > > > -#endif /* QEMU */ > > > +#endif /* QFW_ACPI */ > > > void acpi_setup_ctx(struct acpi_ctx *ctx, ulong start) > > > { > > > > Will need to be tweaked later on still with some other symbol to denote > > "ACPI tables were passed along on real hardware by $mechanism". But we > > can cross that when we come to it. > > > > QFW is only about QEMU. What I did here is separating the transfer of ACPI > tables from QEMU from the code co-used by the sandbox. Do you think this is > wrong?
This part is right, yes. But I quoted the generic code here and not the QEMU part of the code. > Probably when booting U-Boot via Coreboot we should be able to copy ACPI > tables. But this will not involve QFW. Is there any code, yet, where U-Boot > is picking up ACPI tables from Coreboot? Is there, or should there, or could there be? I don't know the answer there, and is what I'm driving at. And that is.. > In this case you would not set symbol CONFIG_GENERATE_ACPI_TABLES. Do we > really need yet another symbol? Yes, I think a number of our symbols are oddly named, and confusing and we probably do need a new symbol or two. We have platforms which use CONFIG_GENERATE_ACPI_TABLES to mean "allocate and populate ACPI structures" and other platforms to mean "copy ACPI tables someone generated for us and pass them along to the OS". -- Tom
signature.asc
Description: PGP signature