EmbeddedPkg: introduce EDKII Platform Has ACPI GUID

The presence of this GUID in the PPI database, and/or in the DXE protocol
database (as dictated by the platform's needs in these firmware phases)
implies that the platform provides the operating system with an ACPI-based
hardware description. This is not necessarily exclusive with other types
of hardware description (for example, a Device Tree-based one).

A platform PEIM and/or DXE driver is supposed to produce a single instance
of the PPI and/or protocol (with NULL contents), if appropriate. The
decision to produce the PPI and/or protocol is platform specific; for
example, in the DXE phase, it could depend on an HII checkbox / underlying
non-volatile UEFI variable.

In the DXE phase, the protocol is meant to be depended-upon by
"MdeModulePkg/Universal/Acpi/AcpiTableDxe", indirectly:

* In the long term, interested platforms will establish this dependency by
  hooking an (upcoming) NULL-class DepexLib instance into AcpiTableDxe in
  their DSC files, pointing DepexLib's DEPEX through a FixedAtBuild PCD to
  the GUID introduced here. (For the prerequisite BaseTools feature, refer
  to <https://bugzilla.tianocore.org/show_bug.cgi?id=443>).

* In the short term, an interested platform may hook a private NULL-class
  library instance (called e.g. "PlatformHasAcpiLib") into AcpiTableDxe.
  Such a library instance would be a specialization of the above described
  generic DepexLib, with the DEPEX open-coded on the GUID introduced here.

Either way, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled)
EFI_ACPI_SDT_PROTOCOL dependent on the platform's dynamic decision to
produce or not to produce a NULL protocol instance with this GUID.

In turn, other (platform and universal) DXE drivers that produce ACPI
tables will wait for EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL, via
DEPEX, protocol notify, or a simple gBS->LocateProtocol() in a "late
enough" callback (such as Ready To Boot).

Because this GUID is not standard, it is prefixed with EDKII / Edkii, as
seen elsewhere in MdeModulePkg and SecurityPkg. In addition, an effort is
made to avoid the phrase "AcpiPlatform", as that belongs to drivers /
libraries that produce platform specific ACPI content (as opposed to
deciding whether the entire firmware will have access to
EFI_ACPI_TABLE_PROTOCOL, or any similar facilities in the PEI phase).

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

diff --git a/EmbeddedPkg/EmbeddedPkg.dec b/EmbeddedPkg/EmbeddedPkg.dec
index 2c2cf41103c282103c2a83ad9a105d0f6ac2e9a3..d078bf794a793bbac6459b3e1b80b7bd853b7299 100644 (file)
--- a/EmbeddedPkg/EmbeddedPkg.dec
+++ b/EmbeddedPkg/EmbeddedPkg.dec
@@ -56,6 +56,9 @@
   gFdtHobGuid   = { 0x16958446, 0x19B7, 0x480B, { 0xB0, 0x47, 0x74, 0x85, 0xAD, 0x3F, 0x71, 0x6D } }\r
   gFdtVariableGuid = { 0x25a4fd4a, 0x9703, 0x4ba9, { 0xa1, 0x90, 0xb7, 0xc8, 0x4e, 0xfb, 0x3e, 0x57 } }\r
 \r
+  ## Include/Guid/PlatformHasAcpi.h\r
+  gEdkiiPlatformHasAcpiGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }\r
+\r
 [Protocols.common]\r
   gHardwareInterruptProtocolGuid =  { 0x2890B3EA, 0x053D, 0x1643, { 0xAD, 0x0C, 0xD6, 0x48, 0x08, 0xDA, 0x3F, 0xF1 } }\r
   gEfiDebugSupportPeriodicCallbackProtocolGuid = { 0x9546e07c, 0x2cbb, 0x4c88, { 0x98, 0x6c, 0xcd, 0x34, 0x10, 0x86, 0xf0, 0x44 } }\r

diff --git a/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h b/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
new file mode 100644 (file)
index 0000000..ad51782
--- /dev/null
+++ b/EmbeddedPkg/Include/Guid/PlatformHasAcpi.h
@@ -0,0 +1,35 @@
+/** @file\r
+  EDKII Platform Has ACPI GUID\r
+\r
+  A NULL protocol instance with this GUID in the DXE protocol database, and/or\r
+  a NULL PPI with this GUID in the PPI database, implies that the platform\r
+  provides the operating system with an ACPI-based hardware description. Note\r
+  that this is not necessarily exclusive with different kinds of hardware\r
+  description (for example, a Device Tree-based one). A platform driver and/or\r
+  PEIM is supposed to produce a single instance of the protocol and/or PPI\r
+  (with NULL contents), if appropriate.\r
+\r
+  Copyright (C) 2017, Red Hat, Inc.\r
+\r
+  This program and the accompanying materials are licensed and made available\r
+  under the terms and conditions of the BSD License that accompanies this\r
+  distribution. The full text of the license may be found at\r
+  http://opensource.org/licenses/bsd-license.php.\r
+\r
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT\r
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.\r
+**/\r
+\r
+\r
+#ifndef __EDKII_PLATFORM_HAS_ACPI_H__\r
+#define __EDKII_PLATFORM_HAS_ACPI_H__\r
+\r
+#define EDKII_PLATFORM_HAS_ACPI_GUID \\r
+  { \\r
+    0xf0966b41, 0xc23f, 0x41b9, \\r
+    { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } \\r
+  }\r
+\r
+extern EFI_GUID gEdkiiPlatformHasAcpiGuid;\r
+\r
+#endif\r