Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

["Zeng, Star" <star.zeng@intel.com>]

Laszlo,

Could the implementation have multiple instances of PlatformHasAcpiLib to return unsuccessfully in the constructor when EFI_ACPI_TABLE_PROTOCOL is not needed? And then eliminate PlatformHasAcpiDtDxe, gEdkiiPlatformHasAcpiProtocolGuid and gEdkiiPlatformHasDeviceTreeProtocolGuid?

Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Saturday, March 18, 2017 4:47 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

The presence of this protocol in the DXE protocol database implies that the platform provides the operating system with an ACPI-based hardware description. This is not necessarily mutually exclusive with a Device Tree-based hardware description. A platform driver is supposed to produce a single instance of the protocol (with NULL contents), if appropriate.

The decision to produce the protocol is platform specific; for example, it could depend on an HII checkbox / underlying non-volatile UEFI variable.

The protocol is meant to be consumed by
"MdeModulePkg/Universal/Acpi/AcpiTableDxe", through the PlatformHasAcpiLib plug-in. By linking this library into AcpiTableDxe via NULL resolution in the platform DSC, the platform makes EFI_ACPI_TABLE_PROTOCOL and (if enabled) EFI_ACPI_SDT_PROTOCOL dependent on the above dynamic decision.

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 protocol is not standard, it is prefixed with EDKII / Edkii, as seen elsewhere in MdeModulePkg and SecurityPkg, for example. (ARM / Arm doesn't look future-proof enough; future UEFI platforms could face the same issue.) 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).

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>
---
 ArmPkg/ArmPkg.dec                                        |  4 ++
 ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf | 40 ++++++++++++++++++++
 ArmPkg/Include/Protocol/PlatformHasAcpi.h                | 34 +++++++++++++++++
 ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c   | 36 ++++++++++++++++++
 4 files changed, 114 insertions(+)

diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec index c4b4da2f95bb..0e49360a386a 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -52,6 +52,10 @@ [Ppis]
   ## Include/Ppi/ArmMpCoreInfo.h
   gArmMpCoreInfoPpiGuid = { 0x6847cc74, 0xe9ec, 0x4f8f, {0xa2, 0x9d, 0xab, 0x44, 0xe7, 0x54, 0xa8, 0xfc} }
 
+[Protocols]
+  ## Include/Protocol/PlatformHasAcpi.h
+  gEdkiiPlatformHasAcpiProtocolGuid =       { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
+
 [PcdsFeatureFlag.common]
   gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x00000001
 
diff --git a/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf b/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
new file mode 100644
index 000000000000..c83da4d8e98a
--- /dev/null
+++ b/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
@@ -0,0 +1,40 @@
+## @file
+# A hook-in library for MdeModulePkg/Universal/Acpi/AcpiTableDxe.
+#
+# Plugging this library instance into AcpiTableDxe makes # 
+EFI_ACPI_TABLE_PROTOCOL and (if enabled) EFI_ACPI_SDT_PROTOCOL depend 
+on the # platform's dynamic decision whether to expose an ACPI-based 
+hardware # description to the operating system.
+#
+# Universal and platform specific DXE drivers that produce ACPI tables 
+depend # on EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL in turn.
+#
+# Copyright (C) 2017, Red Hat, Inc.
+#
+# This program and the accompanying materials are licensed and made 
+available # under the terms and conditions of the BSD License which 
+accompanies this # distribution. The full text of the license may be 
+found at # http://opensource.org/licenses/bsd-license.php
+#
+# THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
+WITHOUT # WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+##
+
+[Defines]
+  INF_VERSION                    = 1.25
+  BASE_NAME                      = PlatformHasAcpiLib
+  FILE_GUID                      = 29beb028-0958-447b-be0a-12229235d77d
+  MODULE_TYPE                    = BASE
+  VERSION_STRING                 = 1.0
+  LIBRARY_CLASS                  = PlatformHasAcpiLib|DXE_DRIVER
+  CONSTRUCTOR                    = PlatformHasAcpiInitialize
+
+[Sources]
+  PlatformHasAcpiLib.c
+
+[Packages]
+  ArmPkg/ArmPkg.dec
+  MdePkg/MdePkg.dec
+
+[Depex]
+  gEdkiiPlatformHasAcpiProtocolGuid
diff --git a/ArmPkg/Include/Protocol/PlatformHasAcpi.h b/ArmPkg/Include/Protocol/PlatformHasAcpi.h
new file mode 100644
index 000000000000..3cd0cfe4515d
--- /dev/null
+++ b/ArmPkg/Include/Protocol/PlatformHasAcpi.h
@@ -0,0 +1,34 @@
+/** @file
+  EDKII Platform Has ACPI Protocol
+
+  The presence of this protocol in the DXE protocol database implies 
+ that the  platform provides the operating system with an ACPI-based 
+ hardware  description. Note that this is not necessarily mutually 
+ exclusive with a  Device Tree-based hardware description. A platform 
+ driver is supposed to  produce a single instance of the protocol (with 
+ NULL contents), if  appropriate.
+
+  Copyright (C) 2017, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made 
+ available  under the terms and conditions of the BSD License that 
+ accompanies this  distribution. The full text of the license may be 
+ found at  http://opensource.org/licenses/bsd-license.php.
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
+WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+
+#ifndef __EDKII_PLATFORM_HAS_ACPI_PROTOCOL_H__
+#define __EDKII_PLATFORM_HAS_ACPI_PROTOCOL_H__
+
+#define EDKII_PLATFORM_HAS_ACPI_PROTOCOL_GUID \
+  { \
+    0xf0966b41, 0xc23f, 0x41b9, \
+    { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } \
+  }
+
+extern EFI_GUID gEdkiiPlatformHasAcpiProtocolGuid;
+
+#endif
diff --git a/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c b/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c
new file mode 100644
index 000000000000..79072da21c2b
--- /dev/null
+++ b/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.c
@@ -0,0 +1,36 @@
+/** @file
+  A hook-in library for MdeModulePkg/Universal/Acpi/AcpiTableDxe.
+
+  Plugging this library instance into AcpiTableDxe makes  
+ EFI_ACPI_TABLE_PROTOCOL and (if enabled) EFI_ACPI_SDT_PROTOCOL depend 
+ on the  platform's dynamic decision whether to expose an ACPI-based 
+ hardware  description to the operating system.
+
+  Universal and platform specific DXE drivers that produce ACPI tables 
+ depend  on EFI_ACPI_TABLE_PROTOCOL / EFI_ACPI_SDT_PROTOCOL in turn.
+
+  Copyright (C) 2017, Red Hat, Inc.
+
+  This program and the accompanying materials are licensed and made 
+ available  under the terms and conditions of the BSD License which 
+ accompanies this  distribution. The full text of the license may be 
+ found at  http://opensource.org/licenses/bsd-license.php
+
+  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, 
+WITHOUT
+  WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
+**/
+
+#include <Base.h>
+
+RETURN_STATUS
+EFIAPI
+PlatformHasAcpiInitialize (
+  VOID
+  )
+{
+  //
+  // Do nothing, just imbue AcpiTableDxe with an
+  // EDKII_PLATFORM_HAS_ACPI_PROTOCOL dependency.
+  //
+  return RETURN_SUCCESS;
+}
--
2.9.3


_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel