[PATCH v2 1/7] acpi: Kconfig symbol CONFIG_QFW_ACPI

[Tom Rini]

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.schuchardt at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20231121/badff473/attachment.sig>