* [PATCH v2 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent"
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:12 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot" Laszlo Ersek
` (10 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
This reverts commit 78c41ff519b187d8979cda7074f007a6323f9acd.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
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>
---
ArmVirtPkg/ArmVirtPkg.dec | 10 ++++++++++
ArmVirtPkg/ArmVirtQemu.dsc | 5 +++++
ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 5 +++--
ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 16 +++++-----------
4 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index efe83a383d55..a5ec42166445 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -58,3 +58,13 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
# EFI_VT_100_GUID.
#
gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D}|VOID*|0x00000007
+
+[PcdsFeatureFlag]
+ #
+ # Pure ACPI boot
+ #
+ # Inhibit installation of the FDT as a configuration table if this feature
+ # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
+ # description of the platform, and it is up to the OS to choose.
+ #
+ gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x0000000a
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 0bbbe4a7aa4a..d6b3c0db5530 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -34,6 +34,7 @@ [Defines]
# -D FLAG=VALUE
#
DEFINE SECURE_BOOT_ENABLE = FALSE
+ DEFINE PURE_ACPI_BOOT_ENABLE = FALSE
!include ArmVirtPkg/ArmVirt.dsc.inc
@@ -94,6 +95,10 @@ [PcdsFeatureFlag.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
+!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
+ gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
+!endif
+
[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1
!if $(ARCH) == AARCH64
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
index 9861f41e968b..00017727c32c 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
@@ -37,16 +37,17 @@ [LibraryClasses]
HobLib
UefiBootServicesTableLib
UefiDriverEntryPoint
- UefiLib
[Protocols]
gFdtClientProtocolGuid ## PRODUCES
[Guids]
- gEfiAcpi20TableGuid
gEfiEventReadyToBootGuid
gFdtHobGuid
gFdtTableGuid
+[FeaturePcd]
+ gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
+
[Depex]
TRUE
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
index 21c1074e331c..4cf79f70cb2a 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
@@ -17,11 +17,9 @@
#include <Library/DebugLib.h>
#include <Library/UefiDriverEntryPoint.h>
#include <Library/UefiBootServicesTableLib.h>
-#include <Library/UefiLib.h>
#include <Library/HobLib.h>
#include <libfdt.h>
-#include <Guid/Acpi.h>
#include <Guid/EventGroup.h>
#include <Guid/Fdt.h>
#include <Guid/FdtHob.h>
@@ -318,16 +316,12 @@ OnReadyToBoot (
)
{
EFI_STATUS Status;
- VOID *Table;
- //
- // Only install the FDT as a configuration table if we are not exposing
- // ACPI 2.0 (or later) tables. Note that the legacy ACPI table GUID has
- // no meaning on ARM since we need at least ACPI 5.0 support, and the
- // 64-bit ACPI 2.0 table GUID is mandatory in that case.
- //
- Status = EfiGetSystemConfigurationTable (&gEfiAcpi20TableGuid, &Table);
- if (EFI_ERROR (Status) || Table == NULL) {
+ if (!FeaturePcdGet (PcdPureAcpiBoot)) {
+ //
+ // Only install the FDT as a configuration table if we want to leave it up
+ // to the OS to decide whether it prefers ACPI over DT.
+ //
Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
ASSERT_EFI_ERROR (Status);
}
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent"
2017-03-17 20:47 ` [PATCH v2 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent" Laszlo Ersek
@ 2017-03-22 14:12 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:12 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> This reverts commit 78c41ff519b187d8979cda7074f007a6323f9acd.
>
> We realized that DXE drivers that are independent of AcpiPlatformDxe (that
> is, independent of QEMU's ACPI generation), such as RamDiskDxe and
> BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
> at driver dispatch or even at Ready To Boot.
>
> This makes it unsafe for us to check for ACPI presence in the UEFI system
> config table in a Ready To Boot callback, in order to decide about
> exposing the DT.
>
> 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>
> ---
> ArmVirtPkg/ArmVirtPkg.dec | 10 ++++++++++
> ArmVirtPkg/ArmVirtQemu.dsc | 5 +++++
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 5 +++--
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 16 +++++-----------
> 4 files changed, 23 insertions(+), 13 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index efe83a383d55..a5ec42166445 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -58,3 +58,13 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
> # EFI_VT_100_GUID.
> #
> gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D}|VOID*|0x00000007
> +
> +[PcdsFeatureFlag]
> + #
> + # Pure ACPI boot
> + #
> + # Inhibit installation of the FDT as a configuration table if this feature
> + # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
> + # description of the platform, and it is up to the OS to choose.
> + #
> + gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x0000000a
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 0bbbe4a7aa4a..d6b3c0db5530 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -34,6 +34,7 @@ [Defines]
> # -D FLAG=VALUE
> #
> DEFINE SECURE_BOOT_ENABLE = FALSE
> + DEFINE PURE_ACPI_BOOT_ENABLE = FALSE
>
> !include ArmVirtPkg/ArmVirt.dsc.inc
>
> @@ -94,6 +95,10 @@ [PcdsFeatureFlag.common]
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
>
> +!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
> + gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
> +!endif
> +
> [PcdsFixedAtBuild.common]
> gArmPlatformTokenSpaceGuid.PcdCoreCount|1
> !if $(ARCH) == AARCH64
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> index 9861f41e968b..00017727c32c 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> @@ -37,16 +37,17 @@ [LibraryClasses]
> HobLib
> UefiBootServicesTableLib
> UefiDriverEntryPoint
> - UefiLib
>
> [Protocols]
> gFdtClientProtocolGuid ## PRODUCES
>
> [Guids]
> - gEfiAcpi20TableGuid
> gEfiEventReadyToBootGuid
> gFdtHobGuid
> gFdtTableGuid
>
> +[FeaturePcd]
> + gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
> +
> [Depex]
> TRUE
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> index 21c1074e331c..4cf79f70cb2a 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> @@ -17,11 +17,9 @@
> #include <Library/DebugLib.h>
> #include <Library/UefiDriverEntryPoint.h>
> #include <Library/UefiBootServicesTableLib.h>
> -#include <Library/UefiLib.h>
> #include <Library/HobLib.h>
> #include <libfdt.h>
>
> -#include <Guid/Acpi.h>
> #include <Guid/EventGroup.h>
> #include <Guid/Fdt.h>
> #include <Guid/FdtHob.h>
> @@ -318,16 +316,12 @@ OnReadyToBoot (
> )
> {
> EFI_STATUS Status;
> - VOID *Table;
>
> - //
> - // Only install the FDT as a configuration table if we are not exposing
> - // ACPI 2.0 (or later) tables. Note that the legacy ACPI table GUID has
> - // no meaning on ARM since we need at least ACPI 5.0 support, and the
> - // 64-bit ACPI 2.0 table GUID is mandatory in that case.
> - //
> - Status = EfiGetSystemConfigurationTable (&gEfiAcpi20TableGuid, &Table);
> - if (EFI_ERROR (Status) || Table == NULL) {
> + if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> + //
> + // Only install the FDT as a configuration table if we want to leave it up
> + // to the OS to decide whether it prefers ACPI over DT.
> + //
> Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
> ASSERT_EFI_ERROR (Status);
> }
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot"
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
2017-03-17 20:47 ` [PATCH v2 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent" Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:12 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages Laszlo Ersek
` (9 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
This reverts commit 18f6d4df9ece8b91b86511bcdd1cf7da478c3627.
We realized that DXE drivers that are independent of AcpiPlatformDxe (that
is, independent of QEMU's ACPI generation), such as RamDiskDxe and
BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
at driver dispatch or even at Ready To Boot.
This makes it unsafe for us to check for ACPI presence in the UEFI system
config table in a Ready To Boot callback, in order to decide about
exposing the DT.
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>
---
ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 1 -
ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 49 ++++----------------
2 files changed, 9 insertions(+), 41 deletions(-)
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
index 00017727c32c..3a0cd37040eb 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
@@ -42,7 +42,6 @@ [Protocols]
gFdtClientProtocolGuid ## PRODUCES
[Guids]
- gEfiEventReadyToBootGuid
gFdtHobGuid
gFdtTableGuid
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
index 4cf79f70cb2a..547a29fce62c 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
@@ -20,7 +20,6 @@
#include <Library/HobLib.h>
#include <libfdt.h>
-#include <Guid/EventGroup.h>
#include <Guid/Fdt.h>
#include <Guid/FdtHob.h>
@@ -307,30 +306,6 @@ STATIC FDT_CLIENT_PROTOCOL mFdtClientProtocol = {
GetOrInsertChosenNode,
};
-STATIC
-VOID
-EFIAPI
-OnReadyToBoot (
- EFI_EVENT Event,
- VOID *Context
- )
-{
- EFI_STATUS Status;
-
- if (!FeaturePcdGet (PcdPureAcpiBoot)) {
- //
- // Only install the FDT as a configuration table if we want to leave it up
- // to the OS to decide whether it prefers ACPI over DT.
- //
- Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
- ASSERT_EFI_ERROR (Status);
- }
-
- gBS->CloseEvent (Event);
-}
-
-STATIC EFI_EVENT mReadyToBootEvent;
-
EFI_STATUS
EFIAPI
InitializeFdtClientDxe (
@@ -358,21 +333,15 @@ InitializeFdtClientDxe (
DEBUG ((EFI_D_INFO, "%a: DTB @ 0x%p\n", __FUNCTION__, mDeviceTreeBase));
- Status = gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
- EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
- if (EFI_ERROR (Status)) {
- return Status;
+ if (!FeaturePcdGet (PcdPureAcpiBoot)) {
+ //
+ // Only install the FDT as a configuration table if we want to leave it up
+ // to the OS to decide whether it prefers ACPI over DT.
+ //
+ Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
+ ASSERT_EFI_ERROR (Status);
}
- Status = gBS->CreateEventEx (
- EVT_NOTIFY_SIGNAL,
- TPL_CALLBACK,
- OnReadyToBoot,
- NULL,
- &gEfiEventReadyToBootGuid,
- &mReadyToBootEvent
- );
- ASSERT_EFI_ERROR (Status);
-
- return EFI_SUCCESS;
+ return gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
+ EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
}
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot"
2017-03-17 20:47 ` [PATCH v2 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot" Laszlo Ersek
@ 2017-03-22 14:12 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:12 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> This reverts commit 18f6d4df9ece8b91b86511bcdd1cf7da478c3627.
>
> We realized that DXE drivers that are independent of AcpiPlatformDxe (that
> is, independent of QEMU's ACPI generation), such as RamDiskDxe and
> BootGraphicsResourceTableDxe, may produce and/or manipulate ACPI tables,
> at driver dispatch or even at Ready To Boot.
>
> This makes it unsafe for us to check for ACPI presence in the UEFI system
> config table in a Ready To Boot callback, in order to decide about
> exposing the DT.
>
> 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>
> ---
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 1 -
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 49 ++++----------------
> 2 files changed, 9 insertions(+), 41 deletions(-)
>
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> index 00017727c32c..3a0cd37040eb 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> @@ -42,7 +42,6 @@ [Protocols]
> gFdtClientProtocolGuid ## PRODUCES
>
> [Guids]
> - gEfiEventReadyToBootGuid
> gFdtHobGuid
> gFdtTableGuid
>
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> index 4cf79f70cb2a..547a29fce62c 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> @@ -20,7 +20,6 @@
> #include <Library/HobLib.h>
> #include <libfdt.h>
>
> -#include <Guid/EventGroup.h>
> #include <Guid/Fdt.h>
> #include <Guid/FdtHob.h>
>
> @@ -307,30 +306,6 @@ STATIC FDT_CLIENT_PROTOCOL mFdtClientProtocol = {
> GetOrInsertChosenNode,
> };
>
> -STATIC
> -VOID
> -EFIAPI
> -OnReadyToBoot (
> - EFI_EVENT Event,
> - VOID *Context
> - )
> -{
> - EFI_STATUS Status;
> -
> - if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> - //
> - // Only install the FDT as a configuration table if we want to leave it up
> - // to the OS to decide whether it prefers ACPI over DT.
> - //
> - Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
> - ASSERT_EFI_ERROR (Status);
> - }
> -
> - gBS->CloseEvent (Event);
> -}
> -
> -STATIC EFI_EVENT mReadyToBootEvent;
> -
> EFI_STATUS
> EFIAPI
> InitializeFdtClientDxe (
> @@ -358,21 +333,15 @@ InitializeFdtClientDxe (
>
> DEBUG ((EFI_D_INFO, "%a: DTB @ 0x%p\n", __FUNCTION__, mDeviceTreeBase));
>
> - Status = gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
> - EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
> - if (EFI_ERROR (Status)) {
> - return Status;
> + if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> + //
> + // Only install the FDT as a configuration table if we want to leave it up
> + // to the OS to decide whether it prefers ACPI over DT.
> + //
> + Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
> + ASSERT_EFI_ERROR (Status);
> }
>
> - Status = gBS->CreateEventEx (
> - EVT_NOTIFY_SIGNAL,
> - TPL_CALLBACK,
> - OnReadyToBoot,
> - NULL,
> - &gEfiEventReadyToBootGuid,
> - &mReadyToBootEvent
> - );
> - ASSERT_EFI_ERROR (Status);
> -
> - return EFI_SUCCESS;
> + return gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
> + EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
> }
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
2017-03-17 20:47 ` [PATCH v2 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent" Laszlo Ersek
2017-03-17 20:47 ` [PATCH v2 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot" Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-20 2:16 ` Zeng, Star
2017-03-17 20:47 ` [PATCH v2 04/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly Laszlo Ersek
` (8 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Feng Tian, Hao Wu, Leif Lindholm, Star Zeng
RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback
function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not
found, then informational messages are logged, and the RAM disks are not
published to the (nonexistent) NFIT table.
The logic is fine, but the info messages are not concatenated correctly
from multiple string literals -- the second parts are passed as (unused)
arguments to DEBUG(). Fix the typos.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
index d1dd13a8197b..b2bafc58bb71 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
@@ -74,7 +74,7 @@ RamDiskAcpiCheck (
if (EFI_ERROR (Status)) {
DEBUG ((
EFI_D_INFO,
- "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
+ "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
"unable to publish RAM disks to NFIT.\n"
));
return;
@@ -91,7 +91,7 @@ RamDiskAcpiCheck (
if (EFI_ERROR (Status)) {
DEBUG ((
EFI_D_INFO,
- "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
+ "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
"unable to publish RAM disks to NFIT.\n"
));
mAcpiTableProtocol = NULL;
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-17 20:47 ` [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages Laszlo Ersek
@ 2017-03-20 2:16 ` Zeng, Star
2017-03-20 2:26 ` Tian, Feng
2017-03-20 9:46 ` Laszlo Ersek
0 siblings, 2 replies; 67+ messages in thread
From: Zeng, Star @ 2017-03-20 2:16 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-01
Cc: Ard Biesheuvel, Tian, Feng, Wu, Hao A, Leif Lindholm, Zeng, Star
I am ok with this patch.
Feng and Hao, do you have any comments?
Thanks,
Star
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Saturday, March 18, 2017 4:47 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
Subject: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not found, then informational messages are logged, and the RAM disks are not published to the (nonexistent) NFIT table.
The logic is fine, but the info messages are not concatenated correctly from multiple string literals -- the second parts are passed as (unused) arguments to DEBUG(). Fix the typos.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
index d1dd13a8197b..b2bafc58bb71 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
@@ -74,7 +74,7 @@ RamDiskAcpiCheck (
if (EFI_ERROR (Status)) {
DEBUG ((
EFI_D_INFO,
- "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
+ "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
"unable to publish RAM disks to NFIT.\n"
));
return;
@@ -91,7 +91,7 @@ RamDiskAcpiCheck (
if (EFI_ERROR (Status)) {
DEBUG ((
EFI_D_INFO,
- "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
+ "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
"unable to publish RAM disks to NFIT.\n"
));
mAcpiTableProtocol = NULL;
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-20 2:16 ` Zeng, Star
@ 2017-03-20 2:26 ` Tian, Feng
2017-03-20 2:34 ` Wu, Hao A
2017-03-20 9:46 ` Laszlo Ersek
1 sibling, 1 reply; 67+ messages in thread
From: Tian, Feng @ 2017-03-20 2:26 UTC (permalink / raw)
To: Zeng, Star, Laszlo Ersek, edk2-devel-01
Cc: Ard Biesheuvel, Wu, Hao A, Leif Lindholm, Tian, Feng
Ok to me as well.
Reviewed-by: Feng Tian <feng.tian@intel.com>
Thanks
Feng
-----Original Message-----
From: Zeng, Star
Sent: Monday, March 20, 2017 10:16 AM
To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
Subject: RE: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
I am ok with this patch.
Feng and Hao, do you have any comments?
Thanks,
Star
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Saturday, March 18, 2017 4:47 AM
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
Subject: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not found, then informational messages are logged, and the RAM disks are not published to the (nonexistent) NFIT table.
The logic is fine, but the info messages are not concatenated correctly from multiple string literals -- the second parts are passed as (unused) arguments to DEBUG(). Fix the typos.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
index d1dd13a8197b..b2bafc58bb71 100644
--- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
+++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
@@ -74,7 +74,7 @@ RamDiskAcpiCheck (
if (EFI_ERROR (Status)) {
DEBUG ((
EFI_D_INFO,
- "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
+ "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
"unable to publish RAM disks to NFIT.\n"
));
return;
@@ -91,7 +91,7 @@ RamDiskAcpiCheck (
if (EFI_ERROR (Status)) {
DEBUG ((
EFI_D_INFO,
- "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
+ "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
"unable to publish RAM disks to NFIT.\n"
));
mAcpiTableProtocol = NULL;
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-20 2:26 ` Tian, Feng
@ 2017-03-20 2:34 ` Wu, Hao A
0 siblings, 0 replies; 67+ messages in thread
From: Wu, Hao A @ 2017-03-20 2:34 UTC (permalink / raw)
To: Tian, Feng, Zeng, Star, Laszlo Ersek, edk2-devel-01
Cc: Ard Biesheuvel, Leif Lindholm
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Best Regards,
Hao Wu
> -----Original Message-----
> From: Tian, Feng
> Sent: Monday, March 20, 2017 10:26 AM
> To: Zeng, Star; Laszlo Ersek; edk2-devel-01
> Cc: Ard Biesheuvel; Wu, Hao A; Leif Lindholm; Tian, Feng
> Subject: RE: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal
> catenation in info messages
>
> Ok to me as well.
>
> Reviewed-by: Feng Tian <feng.tian@intel.com>
>
> Thanks
> Feng
>
> -----Original Message-----
> From: Zeng, Star
> Sent: Monday, March 20, 2017 10:16 AM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng
> <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
> Subject: RE: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal
> catenation in info messages
>
> I am ok with this patch.
>
> Feng and Hao, do you have any comments?
>
> Thanks,
> Star
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Saturday, March 18, 2017 4:47 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng
> <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm
> <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
> Subject: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal
> catenation in info messages
>
> RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback function.
> If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not found,
> then informational messages are logged, and the RAM disks are not published
> to the (nonexistent) NFIT table.
>
> The logic is fine, but the info messages are not concatenated correctly from
> multiple string literals -- the second parts are passed as (unused) arguments to
> DEBUG(). Fix the typos.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Feng Tian <feng.tian@intel.com>
> Cc: Hao Wu <hao.a.wu@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Star Zeng <star.zeng@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> index d1dd13a8197b..b2bafc58bb71 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> @@ -74,7 +74,7 @@ RamDiskAcpiCheck (
> if (EFI_ERROR (Status)) {
> DEBUG ((
> EFI_D_INFO,
> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
> "unable to publish RAM disks to NFIT.\n"
> ));
> return;
> @@ -91,7 +91,7 @@ RamDiskAcpiCheck (
> if (EFI_ERROR (Status)) {
> DEBUG ((
> EFI_D_INFO,
> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
> "unable to publish RAM disks to NFIT.\n"
> ));
> mAcpiTableProtocol = NULL;
> --
> 2.9.3
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-20 2:16 ` Zeng, Star
2017-03-20 2:26 ` Tian, Feng
@ 2017-03-20 9:46 ` Laszlo Ersek
2017-03-20 9:57 ` Zeng, Star
1 sibling, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-20 9:46 UTC (permalink / raw)
To: Zeng, Star, edk2-devel-01
Cc: Wu, Hao A, Tian, Feng, Leif Lindholm, Ard Biesheuvel
On 03/20/17 03:16, Zeng, Star wrote:
> I am ok with this patch.
Thanks -- should I add an R-b or A-b in your name?
Thanks
Laszlo
>
> Feng and Hao, do you have any comments?
>
> Thanks,
> Star
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Saturday, March 18, 2017 4:47 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
> Subject: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
>
> RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not found, then informational messages are logged, and the RAM disks are not published to the (nonexistent) NFIT table.
>
> The logic is fine, but the info messages are not concatenated correctly from multiple string literals -- the second parts are passed as (unused) arguments to DEBUG(). Fix the typos.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Feng Tian <feng.tian@intel.com>
> Cc: Hao Wu <hao.a.wu@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Star Zeng <star.zeng@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> index d1dd13a8197b..b2bafc58bb71 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> @@ -74,7 +74,7 @@ RamDiskAcpiCheck (
> if (EFI_ERROR (Status)) {
> DEBUG ((
> EFI_D_INFO,
> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
> "unable to publish RAM disks to NFIT.\n"
> ));
> return;
> @@ -91,7 +91,7 @@ RamDiskAcpiCheck (
> if (EFI_ERROR (Status)) {
> DEBUG ((
> EFI_D_INFO,
> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
> "unable to publish RAM disks to NFIT.\n"
> ));
> mAcpiTableProtocol = NULL;
> --
> 2.9.3
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-20 9:46 ` Laszlo Ersek
@ 2017-03-20 9:57 ` Zeng, Star
2017-03-20 10:10 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Zeng, Star @ 2017-03-20 9:57 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-01
Cc: Wu, Hao A, Tian, Feng, Leif Lindholm, Ard Biesheuvel, Zeng, Star
Yes, please. :)
Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Monday, March 20, 2017 5:46 PM
To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Wu, Hao A <hao.a.wu@intel.com>; Tian, Feng <feng.tian@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
On 03/20/17 03:16, Zeng, Star wrote:
> I am ok with this patch.
Thanks -- should I add an R-b or A-b in your name?
Thanks
Laszlo
>
> Feng and Hao, do you have any comments?
>
> Thanks,
> Star
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Saturday, March 18, 2017 4:47 AM
> To: edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
> Subject: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
>
> RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not found, then informational messages are logged, and the RAM disks are not published to the (nonexistent) NFIT table.
>
> The logic is fine, but the info messages are not concatenated correctly from multiple string literals -- the second parts are passed as (unused) arguments to DEBUG(). Fix the typos.
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Feng Tian <feng.tian@intel.com>
> Cc: Hao Wu <hao.a.wu@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Cc: Star Zeng <star.zeng@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> index d1dd13a8197b..b2bafc58bb71 100644
> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
> @@ -74,7 +74,7 @@ RamDiskAcpiCheck (
> if (EFI_ERROR (Status)) {
> DEBUG ((
> EFI_D_INFO,
> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
> "unable to publish RAM disks to NFIT.\n"
> ));
> return;
> @@ -91,7 +91,7 @@ RamDiskAcpiCheck (
> if (EFI_ERROR (Status)) {
> DEBUG ((
> EFI_D_INFO,
> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
> "unable to publish RAM disks to NFIT.\n"
> ));
> mAcpiTableProtocol = NULL;
> --
> 2.9.3
>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
2017-03-20 9:57 ` Zeng, Star
@ 2017-03-20 10:10 ` Laszlo Ersek
0 siblings, 0 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-20 10:10 UTC (permalink / raw)
To: Zeng, Star, edk2-devel-01
Cc: Wu, Hao A, Tian, Feng, Leif Lindholm, Ard Biesheuvel
On 03/20/17 10:57, Zeng, Star wrote:
> Yes, please. :)
Thank you all; I pushed this one patch in separation, as commit
76874be3d411.
Laszlo
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Monday, March 20, 2017 5:46 PM
> To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Wu, Hao A <hao.a.wu@intel.com>; Tian, Feng <feng.tian@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
>
> On 03/20/17 03:16, Zeng, Star wrote:
>> I am ok with this patch.
>
> Thanks -- should I add an R-b or A-b in your name?
>
> Thanks
> Laszlo
>
>>
>> Feng and Hao, do you have any comments?
>>
>> Thanks,
>> Star
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Saturday, March 18, 2017 4:47 AM
>> To: edk2-devel-01 <edk2-devel@lists.01.org>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Tian, Feng <feng.tian@intel.com>; Wu, Hao A <hao.a.wu@intel.com>; Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>
>> Subject: [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages
>>
>> RamDiskDxe installs the RamDiskAcpiCheck() Ready To Boot callback function. If EFI_ACPI_TABLE_PROTOCOL and/or EFI_ACPI_SDT_PROTOCOL are not found, then informational messages are logged, and the RAM disks are not published to the (nonexistent) NFIT table.
>>
>> The logic is fine, but the info messages are not concatenated correctly from multiple string literals -- the second parts are passed as (unused) arguments to DEBUG(). Fix the typos.
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Feng Tian <feng.tian@intel.com>
>> Cc: Hao Wu <hao.a.wu@intel.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
>> Cc: Star Zeng <star.zeng@intel.com>
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>> MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
>> index d1dd13a8197b..b2bafc58bb71 100644
>> --- a/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
>> +++ b/MdeModulePkg/Universal/Disk/RamDiskDxe/RamDiskDriver.c
>> @@ -74,7 +74,7 @@ RamDiskAcpiCheck (
>> if (EFI_ERROR (Status)) {
>> DEBUG ((
>> EFI_D_INFO,
>> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol,",
>> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Table Protocol, "
>> "unable to publish RAM disks to NFIT.\n"
>> ));
>> return;
>> @@ -91,7 +91,7 @@ RamDiskAcpiCheck (
>> if (EFI_ERROR (Status)) {
>> DEBUG ((
>> EFI_D_INFO,
>> - "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol,",
>> + "RamDiskAcpiCheck: Cannot locate the EFI ACPI Sdt Protocol, "
>> "unable to publish RAM disks to NFIT.\n"
>> ));
>> mAcpiTableProtocol = NULL;
>> --
>> 2.9.3
>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 04/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (2 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 03/12] MdeModulePkg/RamDiskDxe: fix C string literal catenation in info messages Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:13 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library Laszlo Ersek
` (7 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
Because that breaks the (upcoming) ARM (32-bit) build of the driver.
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>
---
ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
index 203946f97bf8..49f9b5d2822a 100644
--- a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
+++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
@@ -73,7 +73,8 @@ GetXenArmAcpiRsdp (
ASSERT (RegSize == 2 * sizeof (UINT64));
RegBase = SwapBytes64(Reg[0]);
- RsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)RegBase;
+ RsdpStructurePtr =
+ (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)(UINTN)RegBase;
if (RsdpStructurePtr && RsdpStructurePtr->Revision >= 2) {
Sum = CalculateSum8 ((CONST UINT8 *)RsdpStructurePtr,
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 04/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly
2017-03-17 20:47 ` [PATCH v2 04/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly Laszlo Ersek
@ 2017-03-22 14:13 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:13 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> Because that breaks the (upcoming) ARM (32-bit) build of the driver.
>
> 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>
> ---
> ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> index 203946f97bf8..49f9b5d2822a 100644
> --- a/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> +++ b/ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.c
> @@ -73,7 +73,8 @@ GetXenArmAcpiRsdp (
> ASSERT (RegSize == 2 * sizeof (UINT64));
>
> RegBase = SwapBytes64(Reg[0]);
> - RsdpStructurePtr = (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)RegBase;
> + RsdpStructurePtr =
> + (EFI_ACPI_2_0_ROOT_SYSTEM_DESCRIPTION_POINTER *)(UINTN)RegBase;
>
> if (RsdpStructurePtr && RsdpStructurePtr->Revision >= 2) {
> Sum = CalculateSum8 ((CONST UINT8 *)RsdpStructurePtr,
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (3 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 04/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-18 15:00 ` Leif Lindholm
` (2 more replies)
2017-03-17 20:47 ` [PATCH v2 06/12] ArmPkg: introduce EDKII Platform Has Device Tree Protocol Laszlo Ersek
` (6 subsequent siblings)
11 siblings, 3 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-17 20:47 ` [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library Laszlo Ersek
@ 2017-03-18 15:00 ` Leif Lindholm
2017-03-20 9:01 ` Laszlo Ersek
2017-03-22 15:01 ` Laszlo Ersek
2017-03-20 2:23 ` Zeng, Star
2017-03-22 16:45 ` Laszlo Ersek
2 siblings, 2 replies; 67+ messages in thread
From: Leif Lindholm @ 2017-03-18 15:00 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Ard Biesheuvel
On Fri, Mar 17, 2017 at 09:47:24PM +0100, Laszlo Ersek wrote:
> 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).
I greatly approve, but since you've already done this generically - is
there any good reason to keep this in ArmPkg?
I am strongly looking to get rid of "things that happen to have been
implemented for ARM" from there and pruning it down to contain only
things that are architecturelly ARM-specific.
MdeModulePkg?
Regards,
Leif
> 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
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-18 15:00 ` Leif Lindholm
@ 2017-03-20 9:01 ` Laszlo Ersek
2017-03-20 11:59 ` Leif Lindholm
2017-03-22 15:01 ` Laszlo Ersek
1 sibling, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-20 9:01 UTC (permalink / raw)
To: Leif Lindholm; +Cc: edk2-devel-01, Ard Biesheuvel, Star Zeng, Feng Tian
On 03/18/17 16:00, Leif Lindholm wrote:
> On Fri, Mar 17, 2017 at 09:47:24PM +0100, Laszlo Ersek wrote:
>> 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).
>
> I greatly approve, but since you've already done this generically - is
> there any good reason to keep this in ArmPkg?
> I am strongly looking to get rid of "things that happen to have been
> implemented for ARM" from there and pruning it down to contain only
> things that are architecturelly ARM-specific.
This patch is not specific to ARM architecturally, but it is specific to
the ARM ecosystem / community. I'm unaware of another platform (that
would affect edk2 ATM anyway) where such a conflict in beliefs has not
been sorted out for years.
The somewhat speculative generality in the naming (i.e., Edkii prefix
rather than Arm) is there only because I understand that DT / libfdt is
used on other platforms as well, and I expect once those see UEFI (and
edk2) enablement & porting, the same DT vs. ACPI conflict in Linux space
will extend to those platforms as well.
IOW, at the moment the patch is specific to ARM, it is not random, but
it could change in the future. And, I wouldn't like to force client
modules to rename the GUID at that time.
> MdeModulePkg?
Not a bad idea, but the point of this approach was to avoid touching
core modules. If we modify MdeModulePkg *logic* (as opposed to the
trivial typo fix elsewhere in this series), then the simplest solution
is to just add a dynamic PCD to MdeModulePkg.dec, which forces
AcpiTableDxe to exit immediately with EFI_ABORTED or EFI_UNSUPPORTED.
As I mentioned earlier, PcdAcpiS3Enable had been introduced very
similarly to this. It controls partial or full functionality of several
DXE drivers:
11a291a4d279 MdeModulePkg: Introduce new PCD PcdAcpiS3Enable
a1726e308903 OvmfPkg: Set PcdAcpiS3Enable according to
QemuFwCfgS3Enabled()
125e09387641 MdeModulePkg S3SaveStateDxe: Consume PcdAcpiS3Enable to
control the code
e96708de8837 IntelFrameworkModulePkg AcpiS3SaveDxe: Consume
PcdAcpiS3Enable to control the code
d2d38610603f MdeModulePkg SmmS3SaveStateDxe: Consume PcdAcpiS3Enable
to control the code
800c02fbe2da MdeModulePkg BootScriptExecutorDxe: Consume
PcdAcpiS3Enable to control the code
ca98f6038294 UefiCpuPkg/CpuS3DataDxe: Consume PcdAcpiS3Enable to
control the code
b10d5ddc0385 UefiCpuPkg/PiSmmCpuDxeSmm: Consume PcdAcpiS3Enable to
control the code
If the AcpiTableDxe maintainers aren't opposed to another dynamic PCD
like PcdAcpiS3Enable -- but in this case for controlling AcpiTableDxe --
then I'm fine with it too.
... I knew that new PCDs in MdeModulePkg needed strong justification, so
I figured I'd try another route first.
Thanks
Laszlo
>
> Regards,
>
> Leif
>
>> 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
>>
>>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-20 9:01 ` Laszlo Ersek
@ 2017-03-20 11:59 ` Leif Lindholm
0 siblings, 0 replies; 67+ messages in thread
From: Leif Lindholm @ 2017-03-20 11:59 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Ard Biesheuvel, Star Zeng, Feng Tian
On Mon, Mar 20, 2017 at 10:01:09AM +0100, Laszlo Ersek wrote:
> >> 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).
> >
> > I greatly approve, but since you've already done this generically - is
> > there any good reason to keep this in ArmPkg?
> > I am strongly looking to get rid of "things that happen to have been
> > implemented for ARM" from there and pruning it down to contain only
> > things that are architecturelly ARM-specific.
>
> This patch is not specific to ARM architecturally, but it is specific to
> the ARM ecosystem / community. I'm unaware of another platform (that
> would affect edk2 ATM anyway) where such a conflict in beliefs has not
> been sorted out for years.
Indeed. However, I have developed a mild allergy towards things that
are not fundamentally ARM-specific, but are treated as such.
It tends to introduce a mental barrier towards code unification and
sharing, since it makes it look like an architecture-specific component.
> The somewhat speculative generality in the naming (i.e., Edkii prefix
> rather than Arm) is there only because I understand that DT / libfdt is
> used on other platforms as well, and I expect once those see UEFI (and
> edk2) enablement & porting, the same DT vs. ACPI conflict in Linux space
> will extend to those platforms as well.
>
> IOW, at the moment the patch is specific to ARM, it is not random, but
> it could change in the future. And, I wouldn't like to force client
> modules to rename the GUID at that time.
Oh, I perfectly agree.
I'm just saying I don't think that a feature only being applicable to
ARM at the current moment should be a barrier for it being introduced
in Mde*Pkg.
> > MdeModulePkg?
>
> Not a bad idea, but the point of this approach was to avoid touching
> core modules. If we modify MdeModulePkg *logic* (as opposed to the
> trivial typo fix elsewhere in this series), then the simplest solution
> is to just add a dynamic PCD to MdeModulePkg.dec, which forces
> AcpiTableDxe to exit immediately with EFI_ABORTED or EFI_UNSUPPORTED.
That actually sounds more palatable to me than this set, which I still
prefer over Ard's solution (I'll expand on my reservations about that
one on the correct thread).
> As I mentioned earlier, PcdAcpiS3Enable had been introduced very
> similarly to this. It controls partial or full functionality of several
> DXE drivers:
>
> 11a291a4d279 MdeModulePkg: Introduce new PCD PcdAcpiS3Enable
> a1726e308903 OvmfPkg: Set PcdAcpiS3Enable according to
> QemuFwCfgS3Enabled()
> 125e09387641 MdeModulePkg S3SaveStateDxe: Consume PcdAcpiS3Enable to
> control the code
> e96708de8837 IntelFrameworkModulePkg AcpiS3SaveDxe: Consume
> PcdAcpiS3Enable to control the code
> d2d38610603f MdeModulePkg SmmS3SaveStateDxe: Consume PcdAcpiS3Enable
> to control the code
> 800c02fbe2da MdeModulePkg BootScriptExecutorDxe: Consume
> PcdAcpiS3Enable to control the code
> ca98f6038294 UefiCpuPkg/CpuS3DataDxe: Consume PcdAcpiS3Enable to
> control the code
> b10d5ddc0385 UefiCpuPkg/PiSmmCpuDxeSmm: Consume PcdAcpiS3Enable to
> control the code
>
> If the AcpiTableDxe maintainers aren't opposed to another dynamic PCD
> like PcdAcpiS3Enable -- but in this case for controlling AcpiTableDxe --
> then I'm fine with it too.
>
> ... I knew that new PCDs in MdeModulePkg needed strong justification, so
> I figured I'd try another route first.
Yes, I understand. But I think it is well motivated here, and the
solution that feels the most UEFI to me.
Regards,
Leif
> Thanks
> Laszlo
>
> >
> > Regards,
> >
> > Leif
> >
> >> 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
> >>
> >>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-18 15:00 ` Leif Lindholm
2017-03-20 9:01 ` Laszlo Ersek
@ 2017-03-22 15:01 ` Laszlo Ersek
2017-03-23 1:41 ` Zeng, Star
1 sibling, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-22 15:01 UTC (permalink / raw)
To: Leif Lindholm, Star Zeng, Feng Tian; +Cc: edk2-devel-01, Ard Biesheuvel
On 03/18/17 16:00, Leif Lindholm wrote:
> On Fri, Mar 17, 2017 at 09:47:24PM +0100, Laszlo Ersek wrote:
>> 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).
>
> I greatly approve, but since you've already done this generically - is
> there any good reason to keep this in ArmPkg?
> I am strongly looking to get rid of "things that happen to have been
> implemented for ARM" from there and pruning it down to contain only
> things that are architecturelly ARM-specific.
>
> MdeModulePkg?
It looks like Ard is okay with this series after all, and you (Leif)
also seem to tolerate it. The question is now if the MdeModulePkg owners
are okay to take this patch for MdeModulePkg.
Star, Feng, can I add the protocol definition and the library instance
in this patch to MdeModulePkg? (We've ruled out the dynamic PCD
discussed previously for AcpiTableDxe, because platforms would have even
greater trouble setting such a PCD than using this protocol.)
Can you guys please give a decisive answer in one or two days?
Thank you,
Laszlo
>
> Regards,
>
> Leif
>
>> 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
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-22 15:01 ` Laszlo Ersek
@ 2017-03-23 1:41 ` Zeng, Star
2017-03-23 9:09 ` Ard Biesheuvel
0 siblings, 1 reply; 67+ messages in thread
From: Zeng, Star @ 2017-03-23 1:41 UTC (permalink / raw)
To: Laszlo Ersek, Leif Lindholm, Tian, Feng
Cc: edk2-devel-01, Ard Biesheuvel, Zeng, Star
I prefer to do not include the protocol definition and the library instance into MdeModulePkg at this moment until they need to be used by multiple platforms/archs.
Thanks,
Star
-----Original Message-----
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Wednesday, March 22, 2017 11:02 PM
To: Leif Lindholm <leif.lindholm@linaro.org>; Zeng, Star <star.zeng@intel.com>; Tian, Feng <feng.tian@intel.com>
Cc: edk2-devel-01 <edk2-devel@lists.01.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
On 03/18/17 16:00, Leif Lindholm wrote:
> On Fri, Mar 17, 2017 at 09:47:24PM +0100, Laszlo Ersek wrote:
>> 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).
>
> I greatly approve, but since you've already done this generically - is
> there any good reason to keep this in ArmPkg?
> I am strongly looking to get rid of "things that happen to have been
> implemented for ARM" from there and pruning it down to contain only
> things that are architecturelly ARM-specific.
>
> MdeModulePkg?
It looks like Ard is okay with this series after all, and you (Leif) also seem to tolerate it. The question is now if the MdeModulePkg owners are okay to take this patch for MdeModulePkg.
Star, Feng, can I add the protocol definition and the library instance in this patch to MdeModulePkg? (We've ruled out the dynamic PCD discussed previously for AcpiTableDxe, because platforms would have even greater trouble setting such a PCD than using this protocol.)
Can you guys please give a decisive answer in one or two days?
Thank you,
Laszlo
>
> Regards,
>
> Leif
>
>> 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|0x00000
>> 001
>>
>> 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
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-23 1:41 ` Zeng, Star
@ 2017-03-23 9:09 ` Ard Biesheuvel
2017-03-24 3:44 ` Zeng, Star
0 siblings, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-23 9:09 UTC (permalink / raw)
To: Zeng, Star, Kinney, Michael D, afish@apple.com
Cc: Laszlo Ersek, Leif Lindholm, Tian, Feng, edk2-devel-01
On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
> I prefer to do not include the protocol definition and the library instance into MdeModulePkg at this moment until they need to be used by multiple platforms/archs.
>
I disagree. Nowhere in the PI or UEFI spec is there any mention (for
any architecture) that ACPI is mandatory. Given that EDK2 is the
reference platform UEFI/PI, and not for ACPI or the PC/x86 platform, I
think it is unreasonable to have lots and lots of PC quirks (i.e.,
allocations below 4 GB) in MdeModulePkg, but then disallow a clean
approach to make ACPI selectable, in a way that is true to the spirit
of PI (i.e., using protocol dependencies)
So I think at least the protocol definitions belong in MdeModulePkg.
Thanks,
Ard.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-23 9:09 ` Ard Biesheuvel
@ 2017-03-24 3:44 ` Zeng, Star
2017-03-24 7:15 ` Ard Biesheuvel
2017-03-24 17:09 ` Laszlo Ersek
0 siblings, 2 replies; 67+ messages in thread
From: Zeng, Star @ 2017-03-24 3:44 UTC (permalink / raw)
To: Ard Biesheuvel, Kinney, Michael D, afish@apple.com
Cc: Tian, Feng, Laszlo Ersek, edk2-devel-01, Leif Lindholm,
Gao, Liming, Zeng, Star
I just think it seems a generic problem.
Some platforms may dynamically determine whether ACPI should be supported or not.
Some platforms may dynamically determine whether SMBIOS should be supported or not.
Some platforms may dynamically determine whether HII should be supported or not.
...
We are thinking whether we can have a generic NULL instance to support all this kind of cases, for example:
1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD point to a depex GUID.
2. Implement a NULL instance DepexLib.
[Defines]
INF_VERSION = 0x00010005
BASE_NAME = DepexLib
FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
MODULE_TYPE = BASE
VERSION_STRING = 1.0
LIBRARY_CLASS = NULL
[Sources]
DepexLib.c
[Packages]
XXXPkg/XXXPkg.dec
[Depex]
PcdDepexGuid
3. Link NULL instance and configure PCD in dsc.
MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
<LibraryClasses>
NULL|XXXPkg/Library/DepexLib/DepexLib.inf
<PcdsFixedAtBuild>
PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
}
MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
<LibraryClasses>
NULL|XXXPkg/Library/DepexLib/DepexLib.inf
<PcdsFixedAtBuild>
PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
}
But current BaseTools does not support the syntax to declare PCD in [Depex] section of inf yet.
Based on the statements above, I have below comments.
1. I agree to add the GUID into MdeModulePkg, but how about using gEdkiiPlatformHasAcpiGuid instead of gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids] section of MdeModulePkg.dec? As Platform can install gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER. And another, no need to add a include file PlatformHasAcpi.h as BaseTools supports to add the GUID definitions to AutoGen files from package dec.
2. You can file bugzilla bug to request BaseTools syntax support to declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib could be finally added into core package MdeModulePkg or even MdePkg (I prefer). Before that, how about implementing the PlatformHasAcpiLib in none core package?
Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel
Sent: Thursday, March 23, 2017 5:09 PM
To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com
Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm <leif.lindholm@linaro.org>
Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
> I prefer to do not include the protocol definition and the library instance into MdeModulePkg at this moment until they need to be used by multiple platforms/archs.
>
I disagree. Nowhere in the PI or UEFI spec is there any mention (for any architecture) that ACPI is mandatory. Given that EDK2 is the reference platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in MdeModulePkg, but then disallow a clean approach to make ACPI selectable, in a way that is true to the spirit of PI (i.e., using protocol dependencies)
So I think at least the protocol definitions belong in MdeModulePkg.
Thanks,
Ard.
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-24 3:44 ` Zeng, Star
@ 2017-03-24 7:15 ` Ard Biesheuvel
2017-03-24 17:10 ` Laszlo Ersek
2017-03-24 17:09 ` Laszlo Ersek
1 sibling, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-24 7:15 UTC (permalink / raw)
To: Zeng, Star
Cc: Kinney, Michael D, afish@apple.com, Tian, Feng, Laszlo Ersek,
edk2-devel-01, Leif Lindholm, Gao, Liming
On 24 March 2017 at 03:44, Zeng, Star <star.zeng@intel.com> wrote:
> I just think it seems a generic problem.
> Some platforms may dynamically determine whether ACPI should be supported or not.
> Some platforms may dynamically determine whether SMBIOS should be supported or not.
> Some platforms may dynamically determine whether HII should be supported or not.
> ...
>
> We are thinking whether we can have a generic NULL instance to support all this kind of cases, for example:
> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD point to a depex GUID.
> 2. Implement a NULL instance DepexLib.
> [Defines]
> INF_VERSION = 0x00010005
> BASE_NAME = DepexLib
> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
> MODULE_TYPE = BASE
> VERSION_STRING = 1.0
> LIBRARY_CLASS = NULL
>
> [Sources]
> DepexLib.c
>
> [Packages]
> XXXPkg/XXXPkg.dec
>
> [Depex]
> PcdDepexGuid
>
> 3. Link NULL instance and configure PCD in dsc.
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
> <LibraryClasses>
> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
> <PcdsFixedAtBuild>
> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
> }
> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
> <LibraryClasses>
> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
> <PcdsFixedAtBuild>
> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
> }
>
> But current BaseTools does not support the syntax to declare PCD in [Depex] section of inf yet.
>
> Based on the statements above, I have below comments.
> 1. I agree to add the GUID into MdeModulePkg, but how about using gEdkiiPlatformHasAcpiGuid instead of gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids] section of MdeModulePkg.dec? As Platform can install gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER. And another, no need to add a include file PlatformHasAcpi.h as BaseTools supports to add the GUID definitions to AutoGen files from package dec.
> 2. You can file bugzilla bug to request BaseTools syntax support to declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib could be finally added into core package MdeModulePkg or even MdePkg (I prefer). Before that, how about implementing the PlatformHasAcpiLib in none core package?
>
Hello Star,
Thanks for taking the time to think about this. It is much appreciated.
I like the generic approach for dynamic dependencies. The more
architectures are supported in UEFI, the more often we are likely to
see the need for such things.
I will let Laszlo speak for himself, as the author of the patches, but
I am perfectly fine with
a) the outline above of how we address this in the long term,
b) taking anything we need for the short term into ArmPkg, and move it
to MdeModulePkg and/or MdePkg later.
Thanks,
Ard.
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-24 7:15 ` Ard Biesheuvel
@ 2017-03-24 17:10 ` Laszlo Ersek
2017-03-24 17:11 ` Ard Biesheuvel
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-24 17:10 UTC (permalink / raw)
To: Ard Biesheuvel, Zeng, Star
Cc: Kinney, Michael D, afish@apple.com, Tian, Feng, edk2-devel-01,
Leif Lindholm, Gao, Liming
On 03/24/17 08:15, Ard Biesheuvel wrote:
> On 24 March 2017 at 03:44, Zeng, Star <star.zeng@intel.com> wrote:
>> I just think it seems a generic problem.
>> Some platforms may dynamically determine whether ACPI should be supported or not.
>> Some platforms may dynamically determine whether SMBIOS should be supported or not.
>> Some platforms may dynamically determine whether HII should be supported or not.
>> ...
>>
>> We are thinking whether we can have a generic NULL instance to support all this kind of cases, for example:
>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD point to a depex GUID.
>> 2. Implement a NULL instance DepexLib.
>> [Defines]
>> INF_VERSION = 0x00010005
>> BASE_NAME = DepexLib
>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>> MODULE_TYPE = BASE
>> VERSION_STRING = 1.0
>> LIBRARY_CLASS = NULL
>>
>> [Sources]
>> DepexLib.c
>>
>> [Packages]
>> XXXPkg/XXXPkg.dec
>>
>> [Depex]
>> PcdDepexGuid
>>
>> 3. Link NULL instance and configure PCD in dsc.
>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>> <LibraryClasses>
>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>> <PcdsFixedAtBuild>
>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>> }
>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>> <LibraryClasses>
>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>> <PcdsFixedAtBuild>
>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>> }
>>
>> But current BaseTools does not support the syntax to declare PCD in [Depex] section of inf yet.
>>
>> Based on the statements above, I have below comments.
>> 1. I agree to add the GUID into MdeModulePkg, but how about using gEdkiiPlatformHasAcpiGuid instead of gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids] section of MdeModulePkg.dec? As Platform can install gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER. And another, no need to add a include file PlatformHasAcpi.h as BaseTools supports to add the GUID definitions to AutoGen files from package dec.
>> 2. You can file bugzilla bug to request BaseTools syntax support to declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib could be finally added into core package MdeModulePkg or even MdePkg (I prefer). Before that, how about implementing the PlatformHasAcpiLib in none core package?
>>
>
> Hello Star,
>
> Thanks for taking the time to think about this. It is much appreciated.
>
> I like the generic approach for dynamic dependencies. The more
> architectures are supported in UEFI, the more often we are likely to
> see the need for such things.
>
> I will let Laszlo speak for himself, as the author of the patches, but
> I am perfectly fine with
> a) the outline above of how we address this in the long term,
> b) taking anything we need for the short term into ArmPkg, and move it
> to MdeModulePkg and/or MdePkg later.
To confirm what Leif requested and what we've since discussed on IRC:
since the Has-Acpi GUID is now going under MdeModulePkg, I'll move the
Has-DeviceTree GUID under EmbeddedPkg.
Thanks
Laszlo
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-24 17:10 ` Laszlo Ersek
@ 2017-03-24 17:11 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-24 17:11 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Zeng, Star, Kinney, Michael D, afish@apple.com, Tian, Feng,
edk2-devel-01, Leif Lindholm, Gao, Liming
On 24 March 2017 at 17:10, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/24/17 08:15, Ard Biesheuvel wrote:
>> On 24 March 2017 at 03:44, Zeng, Star <star.zeng@intel.com> wrote:
>>> I just think it seems a generic problem.
>>> Some platforms may dynamically determine whether ACPI should be supported or not.
>>> Some platforms may dynamically determine whether SMBIOS should be supported or not.
>>> Some platforms may dynamically determine whether HII should be supported or not.
>>> ...
>>>
>>> We are thinking whether we can have a generic NULL instance to support all this kind of cases, for example:
>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD point to a depex GUID.
>>> 2. Implement a NULL instance DepexLib.
>>> [Defines]
>>> INF_VERSION = 0x00010005
>>> BASE_NAME = DepexLib
>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>>> MODULE_TYPE = BASE
>>> VERSION_STRING = 1.0
>>> LIBRARY_CLASS = NULL
>>>
>>> [Sources]
>>> DepexLib.c
>>>
>>> [Packages]
>>> XXXPkg/XXXPkg.dec
>>>
>>> [Depex]
>>> PcdDepexGuid
>>>
>>> 3. Link NULL instance and configure PCD in dsc.
>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>>> <LibraryClasses>
>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>> <PcdsFixedAtBuild>
>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>>> }
>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>>> <LibraryClasses>
>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>> <PcdsFixedAtBuild>
>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>>> }
>>>
>>> But current BaseTools does not support the syntax to declare PCD in [Depex] section of inf yet.
>>>
>>> Based on the statements above, I have below comments.
>>> 1. I agree to add the GUID into MdeModulePkg, but how about using gEdkiiPlatformHasAcpiGuid instead of gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids] section of MdeModulePkg.dec? As Platform can install gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER. And another, no need to add a include file PlatformHasAcpi.h as BaseTools supports to add the GUID definitions to AutoGen files from package dec.
>>> 2. You can file bugzilla bug to request BaseTools syntax support to declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib could be finally added into core package MdeModulePkg or even MdePkg (I prefer). Before that, how about implementing the PlatformHasAcpiLib in none core package?
>>>
>>
>> Hello Star,
>>
>> Thanks for taking the time to think about this. It is much appreciated.
>>
>> I like the generic approach for dynamic dependencies. The more
>> architectures are supported in UEFI, the more often we are likely to
>> see the need for such things.
>>
>> I will let Laszlo speak for himself, as the author of the patches, but
>> I am perfectly fine with
>> a) the outline above of how we address this in the long term,
>> b) taking anything we need for the short term into ArmPkg, and move it
>> to MdeModulePkg and/or MdePkg later.
>
> To confirm what Leif requested and what we've since discussed on IRC:
> since the Has-Acpi GUID is now going under MdeModulePkg, I'll move the
> Has-DeviceTree GUID under EmbeddedPkg.
>
Ack
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-24 3:44 ` Zeng, Star
2017-03-24 7:15 ` Ard Biesheuvel
@ 2017-03-24 17:09 ` Laszlo Ersek
2017-03-27 2:42 ` Gao, Liming
1 sibling, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-24 17:09 UTC (permalink / raw)
To: Zeng, Star, Ard Biesheuvel, Kinney, Michael D, afish@apple.com
Cc: Tian, Feng, edk2-devel-01, Leif Lindholm, Gao, Liming
On 03/24/17 04:44, Zeng, Star wrote:
> I just think it seems a generic problem.
> Some platforms may dynamically determine whether ACPI should be supported or not.
> Some platforms may dynamically determine whether SMBIOS should be supported or not.
> Some platforms may dynamically determine whether HII should be supported or not.
> ...
>
> We are thinking whether we can have a generic NULL instance to support all this kind of cases, for example:
> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD point to a depex GUID.
> 2. Implement a NULL instance DepexLib.
> [Defines]
> INF_VERSION = 0x00010005
> BASE_NAME = DepexLib
> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
> MODULE_TYPE = BASE
> VERSION_STRING = 1.0
> LIBRARY_CLASS = NULL
>
> [Sources]
> DepexLib.c
>
> [Packages]
> XXXPkg/XXXPkg.dec
>
> [Depex]
> PcdDepexGuid
>
> 3. Link NULL instance and configure PCD in dsc.
> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
> <LibraryClasses>
> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
> <PcdsFixedAtBuild>
> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
> }
> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
> <LibraryClasses>
> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
> <PcdsFixedAtBuild>
> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
> }
>
> But current BaseTools does not support the syntax to declare PCD in [Depex] section of inf yet.
>
> Based on the statements above, I have below comments.
> 1. I agree to add the GUID into MdeModulePkg, but how about using
> gEdkiiPlatformHasAcpiGuid instead of
> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
> section of MdeModulePkg.dec? As Platform can install
> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
Sounds reasonable, I'll do this.
> And another, no
> need to add a include file PlatformHasAcpi.h as BaseTools supports to
> add the GUID definitions to AutoGen files from package dec.
I disagree with this. I mean, I *personally* wouldn't mind, but this
would be inconsistent with existing MdeModulePkg practice. For example, see
MdeModulePkg/Include/Guid/TtyTerm.h
Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data
structures associated with it; the header file only has an extern
declaration, and -- importantly -- an array initializer macro called
EFI_TTY_TERM_GUID, which can be used in the following syntax:
STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
So, I think that the GUID header file is required. I will add it in v3.
Once we generalize this idea to the design that you laid out above, we
can perhaps eliminate the header file. But, for now, I think we should
remain consistent with other MdeModulePkg GUID definitions.
> 2. You can file bugzilla bug to request BaseTools syntax support to
> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib
> could be finally added into core package MdeModulePkg or even MdePkg
> (I prefer).
I filed:
https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
> Before that, how about implementing the
> PlatformHasAcpiLib in none core package?
Works for me; I'll split that part off and keep it under ArmPkg.
Thanks
Laszlo
>
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Ard Biesheuvel
> Sent: Thursday, March 23, 2017 5:09 PM
> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com
> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm <leif.lindholm@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>> I prefer to do not include the protocol definition and the library instance into MdeModulePkg at this moment until they need to be used by multiple platforms/archs.
>>
>
> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any architecture) that ACPI is mandatory. Given that EDK2 is the reference platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in MdeModulePkg, but then disallow a clean approach to make ACPI selectable, in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>
> So I think at least the protocol definitions belong in MdeModulePkg.
>
> Thanks,
> Ard.
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-24 17:09 ` Laszlo Ersek
@ 2017-03-27 2:42 ` Gao, Liming
2017-03-27 7:00 ` Ard Biesheuvel
0 siblings, 1 reply; 67+ messages in thread
From: Gao, Liming @ 2017-03-27 2:42 UTC (permalink / raw)
To: Laszlo Ersek, Zeng, Star, Ard Biesheuvel, Kinney, Michael D,
afish@apple.com
Cc: Tian, Feng, edk2-devel-01, Leif Lindholm
Laszlo:
On GUID header file, some header file are here, because they are added before BaseTools supports it. Now, we allow not to add header file if the header file only has GUID value definition.
On GUID C MACRO, we suggest to use GuidCName in every C source code. So, we don't suggest to add it. As you know, some existing header files have GuidCName and GUID Macro. Now, we have no plan to clean up the existing one. But, we expect new added file follows this rule.
Thanks
Liming
>-----Original Message-----
>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>Laszlo Ersek
>Sent: Saturday, March 25, 2017 1:09 AM
>To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
><ard.biesheuvel@linaro.org>; Kinney, Michael D
><michael.d.kinney@intel.com>; afish@apple.com
>Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming <liming.gao@intel.com>;
>edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
><leif.lindholm@linaro.org>
>Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>ACPI Protocol, and plug-in library
>
>On 03/24/17 04:44, Zeng, Star wrote:
>> I just think it seems a generic problem.
>> Some platforms may dynamically determine whether ACPI should be
>supported or not.
>> Some platforms may dynamically determine whether SMBIOS should be
>supported or not.
>> Some platforms may dynamically determine whether HII should be
>supported or not.
>> ...
>>
>> We are thinking whether we can have a generic NULL instance to support all
>this kind of cases, for example:
>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD
>point to a depex GUID.
>> 2. Implement a NULL instance DepexLib.
>> [Defines]
>> INF_VERSION = 0x00010005
>> BASE_NAME = DepexLib
>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>> MODULE_TYPE = BASE
>> VERSION_STRING = 1.0
>> LIBRARY_CLASS = NULL
>>
>> [Sources]
>> DepexLib.c
>>
>> [Packages]
>> XXXPkg/XXXPkg.dec
>>
>> [Depex]
>> PcdDepexGuid
>>
>> 3. Link NULL instance and configure PCD in dsc.
>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>> <LibraryClasses>
>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>> <PcdsFixedAtBuild>
>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>> }
>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>> <LibraryClasses>
>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>> <PcdsFixedAtBuild>
>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>> }
>>
>> But current BaseTools does not support the syntax to declare PCD in [Depex]
>section of inf yet.
>>
>> Based on the statements above, I have below comments.
>
>> 1. I agree to add the GUID into MdeModulePkg, but how about using
>> gEdkiiPlatformHasAcpiGuid instead of
>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
>> section of MdeModulePkg.dec? As Platform can install
>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
>
>Sounds reasonable, I'll do this.
>
>> And another, no
>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
>> add the GUID definitions to AutoGen files from package dec.
>
>I disagree with this. I mean, I *personally* wouldn't mind, but this
>would be inconsistent with existing MdeModulePkg practice. For example,
>see
>
>MdeModulePkg/Include/Guid/TtyTerm.h
>
>Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data
>structures associated with it; the header file only has an extern
>declaration, and -- importantly -- an array initializer macro called
>EFI_TTY_TERM_GUID, which can be used in the following syntax:
>
>STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
>
>So, I think that the GUID header file is required. I will add it in v3.
>
>Once we generalize this idea to the design that you laid out above, we
>can perhaps eliminate the header file. But, for now, I think we should
>remain consistent with other MdeModulePkg GUID definitions.
>
>> 2. You can file bugzilla bug to request BaseTools syntax support to
>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib
>> could be finally added into core package MdeModulePkg or even MdePkg
>> (I prefer).
>
>I filed:
>
>https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
>https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
>
>> Before that, how about implementing the
>> PlatformHasAcpiLib in none core package?
>
>Works for me; I'll split that part off and keep it under ArmPkg.
>
>Thanks
>Laszlo
>
>>
>>
>> Thanks,
>> Star
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>Ard Biesheuvel
>> Sent: Thursday, March 23, 2017 5:09 PM
>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
><michael.d.kinney@intel.com>; afish@apple.com
>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>;
>edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
><leif.lindholm@linaro.org>
>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>ACPI Protocol, and plug-in library
>>
>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>>> I prefer to do not include the protocol definition and the library instance
>into MdeModulePkg at this moment until they need to be used by multiple
>platforms/archs.
>>>
>>
>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any
>architecture) that ACPI is mandatory. Given that EDK2 is the reference
>platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
>unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in
>MdeModulePkg, but then disallow a clean approach to make ACPI selectable,
>in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>>
>> So I think at least the protocol definitions belong in MdeModulePkg.
>>
>> Thanks,
>> Ard.
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>
>_______________________________________________
>edk2-devel mailing list
>edk2-devel@lists.01.org
>https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-27 2:42 ` Gao, Liming
@ 2017-03-27 7:00 ` Ard Biesheuvel
2017-03-27 17:31 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-27 7:00 UTC (permalink / raw)
To: Gao, Liming
Cc: Laszlo Ersek, Zeng, Star, Kinney, Michael D, afish@apple.com,
Tian, Feng, edk2-devel-01, Leif Lindholm
On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
> Laszlo:
> On GUID header file, some header file are here, because they are added before BaseTools supports it. Now, we allow not to add header file if the header file only has GUID value definition.
I have to agree with Laszlo here. The BaseTools support is incomplete,
since it does not add a #define for the GUID to AutoGen.h. This makes
it impossible to initialize static structures containing GUIDs, such
as templates containing vendor device paths.
For instance, the following
typedef struct {
EFI_GUID foo;
} TYPE;
TYPE mFoo {
SOME_GUID
};
is not possible without a Guid/xxx.h include file containing a #define
for SOME_GUID.
> On GUID C MACRO, we suggest to use GuidCName in every C source code. So, we don't suggest to add it. As you know, some existing header files have GuidCName and GUID Macro. Now, we have no plan to clean up the existing one. But, we expect new added file follows this rule.
>
> Thanks
> Liming
>>-----Original Message-----
>>From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>Laszlo Ersek
>>Sent: Saturday, March 25, 2017 1:09 AM
>>To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
>><ard.biesheuvel@linaro.org>; Kinney, Michael D
>><michael.d.kinney@intel.com>; afish@apple.com
>>Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming <liming.gao@intel.com>;
>>edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>><leif.lindholm@linaro.org>
>>Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>>ACPI Protocol, and plug-in library
>>
>>On 03/24/17 04:44, Zeng, Star wrote:
>>> I just think it seems a generic problem.
>>> Some platforms may dynamically determine whether ACPI should be
>>supported or not.
>>> Some platforms may dynamically determine whether SMBIOS should be
>>supported or not.
>>> Some platforms may dynamically determine whether HII should be
>>supported or not.
>>> ...
>>>
>>> We are thinking whether we can have a generic NULL instance to support all
>>this kind of cases, for example:
>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD
>>point to a depex GUID.
>>> 2. Implement a NULL instance DepexLib.
>>> [Defines]
>>> INF_VERSION = 0x00010005
>>> BASE_NAME = DepexLib
>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>>> MODULE_TYPE = BASE
>>> VERSION_STRING = 1.0
>>> LIBRARY_CLASS = NULL
>>>
>>> [Sources]
>>> DepexLib.c
>>>
>>> [Packages]
>>> XXXPkg/XXXPkg.dec
>>>
>>> [Depex]
>>> PcdDepexGuid
>>>
>>> 3. Link NULL instance and configure PCD in dsc.
>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>>> <LibraryClasses>
>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>> <PcdsFixedAtBuild>
>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>>> }
>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>>> <LibraryClasses>
>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>> <PcdsFixedAtBuild>
>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>>> }
>>>
>>> But current BaseTools does not support the syntax to declare PCD in [Depex]
>>section of inf yet.
>>>
>>> Based on the statements above, I have below comments.
>>
>>> 1. I agree to add the GUID into MdeModulePkg, but how about using
>>> gEdkiiPlatformHasAcpiGuid instead of
>>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
>>> section of MdeModulePkg.dec? As Platform can install
>>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
>>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
>>
>>Sounds reasonable, I'll do this.
>>
>>> And another, no
>>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
>>> add the GUID definitions to AutoGen files from package dec.
>>
>>I disagree with this. I mean, I *personally* wouldn't mind, but this
>>would be inconsistent with existing MdeModulePkg practice. For example,
>>see
>>
>>MdeModulePkg/Include/Guid/TtyTerm.h
>>
>>Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data
>>structures associated with it; the header file only has an extern
>>declaration, and -- importantly -- an array initializer macro called
>>EFI_TTY_TERM_GUID, which can be used in the following syntax:
>>
>>STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
>>
>>So, I think that the GUID header file is required. I will add it in v3.
>>
>>Once we generalize this idea to the design that you laid out above, we
>>can perhaps eliminate the header file. But, for now, I think we should
>>remain consistent with other MdeModulePkg GUID definitions.
>>
>>> 2. You can file bugzilla bug to request BaseTools syntax support to
>>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib
>>> could be finally added into core package MdeModulePkg or even MdePkg
>>> (I prefer).
>>
>>I filed:
>>
>>https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
>>https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
>>
>>> Before that, how about implementing the
>>> PlatformHasAcpiLib in none core package?
>>
>>Works for me; I'll split that part off and keep it under ArmPkg.
>>
>>Thanks
>>Laszlo
>>
>>>
>>>
>>> Thanks,
>>> Star
>>> -----Original Message-----
>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>Ard Biesheuvel
>>> Sent: Thursday, March 23, 2017 5:09 PM
>>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>><michael.d.kinney@intel.com>; afish@apple.com
>>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>;
>>edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>><leif.lindholm@linaro.org>
>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>>ACPI Protocol, and plug-in library
>>>
>>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>>>> I prefer to do not include the protocol definition and the library instance
>>into MdeModulePkg at this moment until they need to be used by multiple
>>platforms/archs.
>>>>
>>>
>>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any
>>architecture) that ACPI is mandatory. Given that EDK2 is the reference
>>platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
>>unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in
>>MdeModulePkg, but then disallow a clean approach to make ACPI selectable,
>>in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>>>
>>> So I think at least the protocol definitions belong in MdeModulePkg.
>>>
>>> Thanks,
>>> Ard.
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>
>>
>>_______________________________________________
>>edk2-devel mailing list
>>edk2-devel@lists.01.org
>>https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-27 7:00 ` Ard Biesheuvel
@ 2017-03-27 17:31 ` Laszlo Ersek
2017-03-27 17:45 ` Ard Biesheuvel
2017-03-28 5:25 ` Gao, Liming
0 siblings, 2 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-27 17:31 UTC (permalink / raw)
To: Ard Biesheuvel, Gao, Liming
Cc: Zeng, Star, Kinney, Michael D, afish@apple.com, Tian, Feng,
edk2-devel-01, Leif Lindholm
On 03/27/17 09:00, Ard Biesheuvel wrote:
> On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
>> Laszlo:
>> On GUID header file, some header file are here, because they are added before BaseTools supports it. Now, we allow not to add header file if the header file only has GUID value definition.
>
> I have to agree with Laszlo here. The BaseTools support is incomplete,
> since it does not add a #define for the GUID to AutoGen.h. This makes
> it impossible to initialize static structures containing GUIDs, such
> as templates containing vendor device paths.
>
> For instance, the following
>
> typedef struct {
> EFI_GUID foo;
> } TYPE;
>
> TYPE mFoo {
> SOME_GUID
> };
>
> is not possible without a Guid/xxx.h include file containing a #define
> for SOME_GUID.
I wonder if we can commit this series before end of April.
Or is that too soon? End of May perhaps?
The mind boggles.
Laszlo
>
>> On GUID C MACRO, we suggest to use GuidCName in every C source code. So, we don't suggest to add it. As you know, some existing header files have GuidCName and GUID Macro. Now, we have no plan to clean up the existing one. But, we expect new added file follows this rule.
>>
>> Thanks
>> Liming
>>> -----Original Message-----
>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>> Laszlo Ersek
>>> Sent: Saturday, March 25, 2017 1:09 AM
>>> To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
>>> <ard.biesheuvel@linaro.org>; Kinney, Michael D
>>> <michael.d.kinney@intel.com>; afish@apple.com
>>> Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming <liming.gao@intel.com>;
>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>> <leif.lindholm@linaro.org>
>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>>> ACPI Protocol, and plug-in library
>>>
>>> On 03/24/17 04:44, Zeng, Star wrote:
>>>> I just think it seems a generic problem.
>>>> Some platforms may dynamically determine whether ACPI should be
>>> supported or not.
>>>> Some platforms may dynamically determine whether SMBIOS should be
>>> supported or not.
>>>> Some platforms may dynamically determine whether HII should be
>>> supported or not.
>>>> ...
>>>>
>>>> We are thinking whether we can have a generic NULL instance to support all
>>> this kind of cases, for example:
>>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD
>>> point to a depex GUID.
>>>> 2. Implement a NULL instance DepexLib.
>>>> [Defines]
>>>> INF_VERSION = 0x00010005
>>>> BASE_NAME = DepexLib
>>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>>>> MODULE_TYPE = BASE
>>>> VERSION_STRING = 1.0
>>>> LIBRARY_CLASS = NULL
>>>>
>>>> [Sources]
>>>> DepexLib.c
>>>>
>>>> [Packages]
>>>> XXXPkg/XXXPkg.dec
>>>>
>>>> [Depex]
>>>> PcdDepexGuid
>>>>
>>>> 3. Link NULL instance and configure PCD in dsc.
>>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>>>> <LibraryClasses>
>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>> <PcdsFixedAtBuild>
>>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>>>> }
>>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>>>> <LibraryClasses>
>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>> <PcdsFixedAtBuild>
>>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>>>> }
>>>>
>>>> But current BaseTools does not support the syntax to declare PCD in [Depex]
>>> section of inf yet.
>>>>
>>>> Based on the statements above, I have below comments.
>>>
>>>> 1. I agree to add the GUID into MdeModulePkg, but how about using
>>>> gEdkiiPlatformHasAcpiGuid instead of
>>>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
>>>> section of MdeModulePkg.dec? As Platform can install
>>>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
>>>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
>>>
>>> Sounds reasonable, I'll do this.
>>>
>>>> And another, no
>>>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
>>>> add the GUID definitions to AutoGen files from package dec.
>>>
>>> I disagree with this. I mean, I *personally* wouldn't mind, but this
>>> would be inconsistent with existing MdeModulePkg practice. For example,
>>> see
>>>
>>> MdeModulePkg/Include/Guid/TtyTerm.h
>>>
>>> Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data
>>> structures associated with it; the header file only has an extern
>>> declaration, and -- importantly -- an array initializer macro called
>>> EFI_TTY_TERM_GUID, which can be used in the following syntax:
>>>
>>> STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
>>>
>>> So, I think that the GUID header file is required. I will add it in v3.
>>>
>>> Once we generalize this idea to the design that you laid out above, we
>>> can perhaps eliminate the header file. But, for now, I think we should
>>> remain consistent with other MdeModulePkg GUID definitions.
>>>
>>>> 2. You can file bugzilla bug to request BaseTools syntax support to
>>>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib
>>>> could be finally added into core package MdeModulePkg or even MdePkg
>>>> (I prefer).
>>>
>>> I filed:
>>>
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
>>> https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
>>>
>>>> Before that, how about implementing the
>>>> PlatformHasAcpiLib in none core package?
>>>
>>> Works for me; I'll split that part off and keep it under ArmPkg.
>>>
>>> Thanks
>>> Laszlo
>>>
>>>>
>>>>
>>>> Thanks,
>>>> Star
>>>> -----Original Message-----
>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>> Ard Biesheuvel
>>>> Sent: Thursday, March 23, 2017 5:09 PM
>>>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>;
>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>> <leif.lindholm@linaro.org>
>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>>> ACPI Protocol, and plug-in library
>>>>
>>>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>>>>> I prefer to do not include the protocol definition and the library instance
>>> into MdeModulePkg at this moment until they need to be used by multiple
>>> platforms/archs.
>>>>>
>>>>
>>>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any
>>> architecture) that ACPI is mandatory. Given that EDK2 is the reference
>>> platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
>>> unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in
>>> MdeModulePkg, but then disallow a clean approach to make ACPI selectable,
>>> in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>>>>
>>>> So I think at least the protocol definitions belong in MdeModulePkg.
>>>>
>>>> Thanks,
>>>> Ard.
>>>> _______________________________________________
>>>> edk2-devel mailing list
>>>> edk2-devel@lists.01.org
>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>
>>>
>>> _______________________________________________
>>> edk2-devel mailing list
>>> edk2-devel@lists.01.org
>>> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-27 17:31 ` Laszlo Ersek
@ 2017-03-27 17:45 ` Ard Biesheuvel
2017-03-28 5:25 ` Gao, Liming
1 sibling, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-27 17:45 UTC (permalink / raw)
To: Laszlo Ersek, Kinney, Michael D, afish@apple.com, Leif Lindholm
Cc: Gao, Liming, Zeng, Star, Tian, Feng, edk2-devel-01
On 27 March 2017 at 18:31, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/27/17 09:00, Ard Biesheuvel wrote:
>> On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
>>> Laszlo:
>>> On GUID header file, some header file are here, because they are added before BaseTools supports it. Now, we allow not to add header file if the header file only has GUID value definition.
>>
>> I have to agree with Laszlo here. The BaseTools support is incomplete,
>> since it does not add a #define for the GUID to AutoGen.h. This makes
>> it impossible to initialize static structures containing GUIDs, such
>> as templates containing vendor device paths.
>>
>> For instance, the following
>>
>> typedef struct {
>> EFI_GUID foo;
>> } TYPE;
>>
>> TYPE mFoo {
>> SOME_GUID
>> };
>>
>> is not possible without a Guid/xxx.h include file containing a #define
>> for SOME_GUID.
>
> I wonder if we can commit this series before end of April.
>
> Or is that too soon? End of May perhaps?
>
> The mind boggles.
>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-27 17:31 ` Laszlo Ersek
2017-03-27 17:45 ` Ard Biesheuvel
@ 2017-03-28 5:25 ` Gao, Liming
2017-03-28 7:49 ` Laszlo Ersek
1 sibling, 1 reply; 67+ messages in thread
From: Gao, Liming @ 2017-03-28 5:25 UTC (permalink / raw)
To: Laszlo Ersek, Ard Biesheuvel
Cc: Zeng, Star, Kinney, Michael D, afish@apple.com, Tian, Feng,
edk2-devel-01, Leif Lindholm
Ersek:
I don't want to block your patch. You can still check in Guid header file if you think it is necessary.
Thanks
Liming
> -----Original Message-----
> From: Laszlo Ersek [mailto:lersek@redhat.com]
> Sent: Tuesday, March 28, 2017 1:32 AM
> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Gao, Liming <liming.gao@intel.com>
> Cc: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com; Tian, Feng
> <feng.tian@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm <leif.lindholm@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> On 03/27/17 09:00, Ard Biesheuvel wrote:
> > On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
> >> Laszlo:
> >> On GUID header file, some header file are here, because they are added before BaseTools supports it. Now, we allow not to add
> header file if the header file only has GUID value definition.
> >
> > I have to agree with Laszlo here. The BaseTools support is incomplete,
> > since it does not add a #define for the GUID to AutoGen.h. This makes
> > it impossible to initialize static structures containing GUIDs, such
> > as templates containing vendor device paths.
> >
> > For instance, the following
> >
> > typedef struct {
> > EFI_GUID foo;
> > } TYPE;
> >
> > TYPE mFoo {
> > SOME_GUID
> > };
> >
> > is not possible without a Guid/xxx.h include file containing a #define
> > for SOME_GUID.
>
> I wonder if we can commit this series before end of April.
>
> Or is that too soon? End of May perhaps?
>
> The mind boggles.
>
> Laszlo
>
> >
> >> On GUID C MACRO, we suggest to use GuidCName in every C source code. So, we don't suggest to add it. As you know, some
> existing header files have GuidCName and GUID Macro. Now, we have no plan to clean up the existing one. But, we expect new added
> file follows this rule.
> >>
> >> Thanks
> >> Liming
> >>> -----Original Message-----
> >>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> >>> Laszlo Ersek
> >>> Sent: Saturday, March 25, 2017 1:09 AM
> >>> To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
> >>> <ard.biesheuvel@linaro.org>; Kinney, Michael D
> >>> <michael.d.kinney@intel.com>; afish@apple.com
> >>> Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming <liming.gao@intel.com>;
> >>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
> >>> <leif.lindholm@linaro.org>
> >>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
> >>> ACPI Protocol, and plug-in library
> >>>
> >>> On 03/24/17 04:44, Zeng, Star wrote:
> >>>> I just think it seems a generic problem.
> >>>> Some platforms may dynamically determine whether ACPI should be
> >>> supported or not.
> >>>> Some platforms may dynamically determine whether SMBIOS should be
> >>> supported or not.
> >>>> Some platforms may dynamically determine whether HII should be
> >>> supported or not.
> >>>> ...
> >>>>
> >>>> We are thinking whether we can have a generic NULL instance to support all
> >>> this kind of cases, for example:
> >>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD
> >>> point to a depex GUID.
> >>>> 2. Implement a NULL instance DepexLib.
> >>>> [Defines]
> >>>> INF_VERSION = 0x00010005
> >>>> BASE_NAME = DepexLib
> >>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
> >>>> MODULE_TYPE = BASE
> >>>> VERSION_STRING = 1.0
> >>>> LIBRARY_CLASS = NULL
> >>>>
> >>>> [Sources]
> >>>> DepexLib.c
> >>>>
> >>>> [Packages]
> >>>> XXXPkg/XXXPkg.dec
> >>>>
> >>>> [Depex]
> >>>> PcdDepexGuid
> >>>>
> >>>> 3. Link NULL instance and configure PCD in dsc.
> >>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
> >>>> <LibraryClasses>
> >>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
> >>>> <PcdsFixedAtBuild>
> >>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
> >>>> }
> >>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
> >>>> <LibraryClasses>
> >>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
> >>>> <PcdsFixedAtBuild>
> >>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
> >>>> }
> >>>>
> >>>> But current BaseTools does not support the syntax to declare PCD in [Depex]
> >>> section of inf yet.
> >>>>
> >>>> Based on the statements above, I have below comments.
> >>>
> >>>> 1. I agree to add the GUID into MdeModulePkg, but how about using
> >>>> gEdkiiPlatformHasAcpiGuid instead of
> >>>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
> >>>> section of MdeModulePkg.dec? As Platform can install
> >>>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
> >>>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
> >>>
> >>> Sounds reasonable, I'll do this.
> >>>
> >>>> And another, no
> >>>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
> >>>> add the GUID definitions to AutoGen files from package dec.
> >>>
> >>> I disagree with this. I mean, I *personally* wouldn't mind, but this
> >>> would be inconsistent with existing MdeModulePkg practice. For example,
> >>> see
> >>>
> >>> MdeModulePkg/Include/Guid/TtyTerm.h
> >>>
> >>> Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data
> >>> structures associated with it; the header file only has an extern
> >>> declaration, and -- importantly -- an array initializer macro called
> >>> EFI_TTY_TERM_GUID, which can be used in the following syntax:
> >>>
> >>> STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
> >>>
> >>> So, I think that the GUID header file is required. I will add it in v3.
> >>>
> >>> Once we generalize this idea to the design that you laid out above, we
> >>> can perhaps eliminate the header file. But, for now, I think we should
> >>> remain consistent with other MdeModulePkg GUID definitions.
> >>>
> >>>> 2. You can file bugzilla bug to request BaseTools syntax support to
> >>>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib
> >>>> could be finally added into core package MdeModulePkg or even MdePkg
> >>>> (I prefer).
> >>>
> >>> I filed:
> >>>
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
> >>> https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
> >>>
> >>>> Before that, how about implementing the
> >>>> PlatformHasAcpiLib in none core package?
> >>>
> >>> Works for me; I'll split that part off and keep it under ArmPkg.
> >>>
> >>> Thanks
> >>> Laszlo
> >>>
> >>>>
> >>>>
> >>>> Thanks,
> >>>> Star
> >>>> -----Original Message-----
> >>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> >>> Ard Biesheuvel
> >>>> Sent: Thursday, March 23, 2017 5:09 PM
> >>>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
> >>> <michael.d.kinney@intel.com>; afish@apple.com
> >>>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>;
> >>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
> >>> <leif.lindholm@linaro.org>
> >>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
> >>> ACPI Protocol, and plug-in library
> >>>>
> >>>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
> >>>>> I prefer to do not include the protocol definition and the library instance
> >>> into MdeModulePkg at this moment until they need to be used by multiple
> >>> platforms/archs.
> >>>>>
> >>>>
> >>>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any
> >>> architecture) that ACPI is mandatory. Given that EDK2 is the reference
> >>> platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
> >>> unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in
> >>> MdeModulePkg, but then disallow a clean approach to make ACPI selectable,
> >>> in a way that is true to the spirit of PI (i.e., using protocol dependencies)
> >>>>
> >>>> So I think at least the protocol definitions belong in MdeModulePkg.
> >>>>
> >>>> Thanks,
> >>>> Ard.
> >>>> _______________________________________________
> >>>> edk2-devel mailing list
> >>>> edk2-devel@lists.01.org
> >>>> https://lists.01.org/mailman/listinfo/edk2-devel
> >>>>
> >>>
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-28 5:25 ` Gao, Liming
@ 2017-03-28 7:49 ` Laszlo Ersek
2017-03-29 9:49 ` Gao, Liming
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-28 7:49 UTC (permalink / raw)
To: Gao, Liming, Ard Biesheuvel
Cc: Zeng, Star, Kinney, Michael D, afish@apple.com, Tian, Feng,
edk2-devel-01, Leif Lindholm
On 03/28/17 07:25, Gao, Liming wrote:
> Ersek:
> I don't want to block your patch. You can still check in Guid header file if you think it is necessary.
I don't want to check in without formal MdeModulePkg maintainer
approval. If I check in a patch without formal approval, that will only
lead to chaos. I don't want to circumvent the process; I want the
process to *work*.
If MdeModulePkg maintainers agree with my
[PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID
then they should please give their Reviewed-by for it.
If they disagree with it, they should please explain why.
The specific argument you raised, namely that a BaseTools utility
generates the necessary C language artifacts for GUID use, is not
precise. BaseTools generate *some* artifacts, but they do not generate a
macro that is usable for initializing a GUID object of static storage
duration (= global variable GUID, or a GUID field in a global variable
structure).
This is what the ISO C99 standard says:
6.7.8 Initialization
[...]
Constraints
[...]
4 All the expressions in an initializer for an object that has static
storage duration shall be constant expressions or string literals.
[...]
16 Otherwise, the initializer for an object that has aggregate or
union type shall be a brace-enclosed list of initializers for the
elements or named members.
[...]
20 If the aggregate or union contains elements or members that are
aggregates or unions, these rules apply recursively to the
subaggregates or contained unions. [...]
This is the GUID type definition:
typedef struct {
UINT32 Data1;
UINT16 Data2;
UINT16 Data3;
UINT8 Data4[8];
} GUID;
For this structure, the above standardese implies that we have to
provide integer constant expressions in the initializer.
6.6 Constant expressions
[...]
6 An /integer constant expression/ shall have integer type and shall
only have operands that are integer constants, enumeration
constants, character constants, /sizeof/ expressions whose results
are integer constants, and floating constants that are the
immediate operands of casts. Cast operators in an integer constant
expression shall only convert arithmetic types to integer types,
except as part of an operand to the /sizeof/ operator.
The end result is that "gEdkiiPlatformHasAcpiGuid" is not usable in such
contexts, but the EDKII_PLATFORM_HAS_ACPI_GUID macro is.
If you want, I can file a TianoCore feature request BZ for generating
such macros as well in BaseTools, but for now, I don't think it should
either block my patch noted above, or force me to drop the Guid/ header
file from the patch. Right now, the Guid/ header adds something that is
not available from BaseTools, and I wouldn't like to delay the v3 series
any longer.
Do you agree to the above method? I file a TianoCore Feature Request BZ
for BaseTools, and MdeModulePkg maintainers formally approve the v3
04/12 patch?
(Side point: I think the Guid/ header file has another benefit:
documentation. I don't think we can add the amount of documentation that
is acceptable in a standalone Guid/ header to an in-line comment in the
.DEC file. So, I think that the new rule for not adding Guid/ headers is
immature at this point -- and, worse, I don't recall an open
announcement or discussion about this rule, so that we could have raised
concerns before turning the proposal into an actual rule.)
Thanks
Laszlo
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Tuesday, March 28, 2017 1:32 AM
>> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Gao, Liming <liming.gao@intel.com>
>> Cc: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D <michael.d.kinney@intel.com>; afish@apple.com; Tian, Feng
>> <feng.tian@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm <leif.lindholm@linaro.org>
>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>>
>> On 03/27/17 09:00, Ard Biesheuvel wrote:
>>> On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
>>>> Laszlo:
>>>> On GUID header file, some header file are here, because they are added before BaseTools supports it. Now, we allow not to add
>> header file if the header file only has GUID value definition.
>>>
>>> I have to agree with Laszlo here. The BaseTools support is incomplete,
>>> since it does not add a #define for the GUID to AutoGen.h. This makes
>>> it impossible to initialize static structures containing GUIDs, such
>>> as templates containing vendor device paths.
>>>
>>> For instance, the following
>>>
>>> typedef struct {
>>> EFI_GUID foo;
>>> } TYPE;
>>>
>>> TYPE mFoo {
>>> SOME_GUID
>>> };
>>>
>>> is not possible without a Guid/xxx.h include file containing a #define
>>> for SOME_GUID.
>>
>> I wonder if we can commit this series before end of April.
>>
>> Or is that too soon? End of May perhaps?
>>
>> The mind boggles.
>>
>> Laszlo
>>
>>>
>>>> On GUID C MACRO, we suggest to use GuidCName in every C source code. So, we don't suggest to add it. As you know, some
>> existing header files have GuidCName and GUID Macro. Now, we have no plan to clean up the existing one. But, we expect new added
>> file follows this rule.
>>>>
>>>> Thanks
>>>> Liming
>>>>> -----Original Message-----
>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>>>> Laszlo Ersek
>>>>> Sent: Saturday, March 25, 2017 1:09 AM
>>>>> To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
>>>>> <ard.biesheuvel@linaro.org>; Kinney, Michael D
>>>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>>> Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming <liming.gao@intel.com>;
>>>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>>>> <leif.lindholm@linaro.org>
>>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>>>>> ACPI Protocol, and plug-in library
>>>>>
>>>>> On 03/24/17 04:44, Zeng, Star wrote:
>>>>>> I just think it seems a generic problem.
>>>>>> Some platforms may dynamically determine whether ACPI should be
>>>>> supported or not.
>>>>>> Some platforms may dynamically determine whether SMBIOS should be
>>>>> supported or not.
>>>>>> Some platforms may dynamically determine whether HII should be
>>>>> supported or not.
>>>>>> ...
>>>>>>
>>>>>> We are thinking whether we can have a generic NULL instance to support all
>>>>> this kind of cases, for example:
>>>>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type PCD
>>>>> point to a depex GUID.
>>>>>> 2. Implement a NULL instance DepexLib.
>>>>>> [Defines]
>>>>>> INF_VERSION = 0x00010005
>>>>>> BASE_NAME = DepexLib
>>>>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>>>>>> MODULE_TYPE = BASE
>>>>>> VERSION_STRING = 1.0
>>>>>> LIBRARY_CLASS = NULL
>>>>>>
>>>>>> [Sources]
>>>>>> DepexLib.c
>>>>>>
>>>>>> [Packages]
>>>>>> XXXPkg/XXXPkg.dec
>>>>>>
>>>>>> [Depex]
>>>>>> PcdDepexGuid
>>>>>>
>>>>>> 3. Link NULL instance and configure PCD in dsc.
>>>>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>>>>>> <LibraryClasses>
>>>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>>>> <PcdsFixedAtBuild>
>>>>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>>>>>> }
>>>>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>>>>>> <LibraryClasses>
>>>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>>>> <PcdsFixedAtBuild>
>>>>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>>>>>> }
>>>>>>
>>>>>> But current BaseTools does not support the syntax to declare PCD in [Depex]
>>>>> section of inf yet.
>>>>>>
>>>>>> Based on the statements above, I have below comments.
>>>>>
>>>>>> 1. I agree to add the GUID into MdeModulePkg, but how about using
>>>>>> gEdkiiPlatformHasAcpiGuid instead of
>>>>>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
>>>>>> section of MdeModulePkg.dec? As Platform can install
>>>>>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
>>>>>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
>>>>>
>>>>> Sounds reasonable, I'll do this.
>>>>>
>>>>>> And another, no
>>>>>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
>>>>>> add the GUID definitions to AutoGen files from package dec.
>>>>>
>>>>> I disagree with this. I mean, I *personally* wouldn't mind, but this
>>>>> would be inconsistent with existing MdeModulePkg practice. For example,
>>>>> see
>>>>>
>>>>> MdeModulePkg/Include/Guid/TtyTerm.h
>>>>>
>>>>> Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no data
>>>>> structures associated with it; the header file only has an extern
>>>>> declaration, and -- importantly -- an array initializer macro called
>>>>> EFI_TTY_TERM_GUID, which can be used in the following syntax:
>>>>>
>>>>> STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
>>>>>
>>>>> So, I think that the GUID header file is required. I will add it in v3.
>>>>>
>>>>> Once we generalize this idea to the design that you laid out above, we
>>>>> can perhaps eliminate the header file. But, for now, I think we should
>>>>> remain consistent with other MdeModulePkg GUID definitions.
>>>>>
>>>>>> 2. You can file bugzilla bug to request BaseTools syntax support to
>>>>>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and DepexLib
>>>>>> could be finally added into core package MdeModulePkg or even MdePkg
>>>>>> (I prefer).
>>>>>
>>>>> I filed:
>>>>>
>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
>>>>>
>>>>>> Before that, how about implementing the
>>>>>> PlatformHasAcpiLib in none core package?
>>>>>
>>>>> Works for me; I'll split that part off and keep it under ArmPkg.
>>>>>
>>>>> Thanks
>>>>> Laszlo
>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> Star
>>>>>> -----Original Message-----
>>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>>>>> Ard Biesheuvel
>>>>>> Sent: Thursday, March 23, 2017 5:09 PM
>>>>>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>>>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>>>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek <lersek@redhat.com>;
>>>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>>>> <leif.lindholm@linaro.org>
>>>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>>>>> ACPI Protocol, and plug-in library
>>>>>>
>>>>>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>>>>>>> I prefer to do not include the protocol definition and the library instance
>>>>> into MdeModulePkg at this moment until they need to be used by multiple
>>>>> platforms/archs.
>>>>>>>
>>>>>>
>>>>>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for any
>>>>> architecture) that ACPI is mandatory. Given that EDK2 is the reference
>>>>> platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
>>>>> unreasonable to have lots and lots of PC quirks (i.e., allocations below 4 GB) in
>>>>> MdeModulePkg, but then disallow a clean approach to make ACPI selectable,
>>>>> in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>>>>>>
>>>>>> So I think at least the protocol definitions belong in MdeModulePkg.
>>>>>>
>>>>>> Thanks,
>>>>>> Ard.
>>>>>> _______________________________________________
>>>>>> edk2-devel mailing list
>>>>>> edk2-devel@lists.01.org
>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> edk2-devel mailing list
>>>>> edk2-devel@lists.01.org
>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-28 7:49 ` Laszlo Ersek
@ 2017-03-29 9:49 ` Gao, Liming
2017-03-29 13:03 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Gao, Liming @ 2017-03-29 9:49 UTC (permalink / raw)
To: Laszlo Ersek, Ard Biesheuvel
Cc: Zeng, Star, Kinney, Michael D, afish@apple.com, Tian, Feng,
edk2-devel-01, Leif Lindholm
Laszlo:
I agree GuidCName can't be used to initialize the global variable. If there is such requirement, GUID C MACRO will have to be defined. Then, its header file will be required.
Now, we have no rule to forbid to add the header file if it has no other definitions except for GUID value, and we have no such discussion to define those rules. It is the developer choice to add it or not.
Here, I want to mention that BaseTools has added "extern gGuidCName" into AutoGen header file. The consumer code can directly use gGuidCName without include its header file. If no GUID MACRO usage, its header file is not necessary.
For this case gEdkiiPlatformHasAcpiGuid, I know it will be as protocol dependency. I don't see its GUID C MACRO usage. So, I suggest not to add its header file. This is just my opinion.
For BaseTools enhancement to generated GUID C MACRO in autogen.h, I think it is valuable. To avoid the generated MACRO conflict with the existing MACRO, the generated MACRO will still have "G" prefix, such as gEdkiiPlatformHasAcpiGuid ==> G_EDKII_PLATFORM_HAS_ACPI_GUID.
Thanks
Liming
>-----Original Message-----
>From: Laszlo Ersek [mailto:lersek@redhat.com]
>Sent: Tuesday, March 28, 2017 3:50 PM
>To: Gao, Liming <liming.gao@intel.com>; Ard Biesheuvel
><ard.biesheuvel@linaro.org>
>Cc: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
><michael.d.kinney@intel.com>; afish@apple.com; Tian, Feng
><feng.tian@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif
>Lindholm <leif.lindholm@linaro.org>
>Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>ACPI Protocol, and plug-in library
>
>On 03/28/17 07:25, Gao, Liming wrote:
>> Ersek:
>> I don't want to block your patch. You can still check in Guid header file if you
>think it is necessary.
>
>I don't want to check in without formal MdeModulePkg maintainer
>approval. If I check in a patch without formal approval, that will only
>lead to chaos. I don't want to circumvent the process; I want the
>process to *work*.
>
>If MdeModulePkg maintainers agree with my
>
> [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID
>
>then they should please give their Reviewed-by for it.
>
>If they disagree with it, they should please explain why.
>
>The specific argument you raised, namely that a BaseTools utility
>generates the necessary C language artifacts for GUID use, is not
>precise. BaseTools generate *some* artifacts, but they do not generate a
>macro that is usable for initializing a GUID object of static storage
>duration (= global variable GUID, or a GUID field in a global variable
>structure).
>
>This is what the ISO C99 standard says:
>
> 6.7.8 Initialization
>
> [...]
>
> Constraints
>
> [...]
>
> 4 All the expressions in an initializer for an object that has static
> storage duration shall be constant expressions or string literals.
>
> [...]
>
> 16 Otherwise, the initializer for an object that has aggregate or
> union type shall be a brace-enclosed list of initializers for the
> elements or named members.
>
> [...]
>
> 20 If the aggregate or union contains elements or members that are
> aggregates or unions, these rules apply recursively to the
> subaggregates or contained unions. [...]
>
>This is the GUID type definition:
>
>typedef struct {
> UINT32 Data1;
> UINT16 Data2;
> UINT16 Data3;
> UINT8 Data4[8];
>} GUID;
>
>For this structure, the above standardese implies that we have to
>provide integer constant expressions in the initializer.
>
> 6.6 Constant expressions
>
> [...]
>
> 6 An /integer constant expression/ shall have integer type and shall
> only have operands that are integer constants, enumeration
> constants, character constants, /sizeof/ expressions whose results
> are integer constants, and floating constants that are the
> immediate operands of casts. Cast operators in an integer constant
> expression shall only convert arithmetic types to integer types,
> except as part of an operand to the /sizeof/ operator.
>
>The end result is that "gEdkiiPlatformHasAcpiGuid" is not usable in such
>contexts, but the EDKII_PLATFORM_HAS_ACPI_GUID macro is.
>
>
>If you want, I can file a TianoCore feature request BZ for generating
>such macros as well in BaseTools, but for now, I don't think it should
>either block my patch noted above, or force me to drop the Guid/ header
>file from the patch. Right now, the Guid/ header adds something that is
>not available from BaseTools, and I wouldn't like to delay the v3 series
>any longer.
>
>Do you agree to the above method? I file a TianoCore Feature Request BZ
>for BaseTools, and MdeModulePkg maintainers formally approve the v3
>04/12 patch?
>
>
>(Side point: I think the Guid/ header file has another benefit:
>documentation. I don't think we can add the amount of documentation that
>is acceptable in a standalone Guid/ header to an in-line comment in the
>.DEC file. So, I think that the new rule for not adding Guid/ headers is
>immature at this point -- and, worse, I don't recall an open
>announcement or discussion about this rule, so that we could have raised
>concerns before turning the proposal into an actual rule.)
>
>Thanks
>Laszlo
>
>>> -----Original Message-----
>>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>>> Sent: Tuesday, March 28, 2017 1:32 AM
>>> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Gao, Liming
><liming.gao@intel.com>
>>> Cc: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
><michael.d.kinney@intel.com>; afish@apple.com; Tian, Feng
>>> <feng.tian@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif
>Lindholm <leif.lindholm@linaro.org>
>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>ACPI Protocol, and plug-in library
>>>
>>> On 03/27/17 09:00, Ard Biesheuvel wrote:
>>>> On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
>>>>> Laszlo:
>>>>> On GUID header file, some header file are here, because they are
>added before BaseTools supports it. Now, we allow not to add
>>> header file if the header file only has GUID value definition.
>>>>
>>>> I have to agree with Laszlo here. The BaseTools support is incomplete,
>>>> since it does not add a #define for the GUID to AutoGen.h. This makes
>>>> it impossible to initialize static structures containing GUIDs, such
>>>> as templates containing vendor device paths.
>>>>
>>>> For instance, the following
>>>>
>>>> typedef struct {
>>>> EFI_GUID foo;
>>>> } TYPE;
>>>>
>>>> TYPE mFoo {
>>>> SOME_GUID
>>>> };
>>>>
>>>> is not possible without a Guid/xxx.h include file containing a #define
>>>> for SOME_GUID.
>>>
>>> I wonder if we can commit this series before end of April.
>>>
>>> Or is that too soon? End of May perhaps?
>>>
>>> The mind boggles.
>>>
>>> Laszlo
>>>
>>>>
>>>>> On GUID C MACRO, we suggest to use GuidCName in every C source
>code. So, we don't suggest to add it. As you know, some
>>> existing header files have GuidCName and GUID Macro. Now, we have no
>plan to clean up the existing one. But, we expect new added
>>> file follows this rule.
>>>>>
>>>>> Thanks
>>>>> Liming
>>>>>> -----Original Message-----
>>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
>Of
>>>>>> Laszlo Ersek
>>>>>> Sent: Saturday, March 25, 2017 1:09 AM
>>>>>> To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
>>>>>> <ard.biesheuvel@linaro.org>; Kinney, Michael D
>>>>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>>>> Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming
><liming.gao@intel.com>;
>>>>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>>>>> <leif.lindholm@linaro.org>
>>>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform
>Has
>>>>>> ACPI Protocol, and plug-in library
>>>>>>
>>>>>> On 03/24/17 04:44, Zeng, Star wrote:
>>>>>>> I just think it seems a generic problem.
>>>>>>> Some platforms may dynamically determine whether ACPI should be
>>>>>> supported or not.
>>>>>>> Some platforms may dynamically determine whether SMBIOS should
>be
>>>>>> supported or not.
>>>>>>> Some platforms may dynamically determine whether HII should be
>>>>>> supported or not.
>>>>>>> ...
>>>>>>>
>>>>>>> We are thinking whether we can have a generic NULL instance to
>support all
>>>>>> this kind of cases, for example:
>>>>>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type
>PCD
>>>>>> point to a depex GUID.
>>>>>>> 2. Implement a NULL instance DepexLib.
>>>>>>> [Defines]
>>>>>>> INF_VERSION = 0x00010005
>>>>>>> BASE_NAME = DepexLib
>>>>>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>>>>>>> MODULE_TYPE = BASE
>>>>>>> VERSION_STRING = 1.0
>>>>>>> LIBRARY_CLASS = NULL
>>>>>>>
>>>>>>> [Sources]
>>>>>>> DepexLib.c
>>>>>>>
>>>>>>> [Packages]
>>>>>>> XXXPkg/XXXPkg.dec
>>>>>>>
>>>>>>> [Depex]
>>>>>>> PcdDepexGuid
>>>>>>>
>>>>>>> 3. Link NULL instance and configure PCD in dsc.
>>>>>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>>>>>>> <LibraryClasses>
>>>>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>>>>> <PcdsFixedAtBuild>
>>>>>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>>>>>>> }
>>>>>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>>>>>>> <LibraryClasses>
>>>>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>>>>> <PcdsFixedAtBuild>
>>>>>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>>>>>>> }
>>>>>>>
>>>>>>> But current BaseTools does not support the syntax to declare PCD in
>[Depex]
>>>>>> section of inf yet.
>>>>>>>
>>>>>>> Based on the statements above, I have below comments.
>>>>>>
>>>>>>> 1. I agree to add the GUID into MdeModulePkg, but how about using
>>>>>>> gEdkiiPlatformHasAcpiGuid instead of
>>>>>>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
>>>>>>> section of MdeModulePkg.dec? As Platform can install
>>>>>>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
>>>>>>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
>>>>>>
>>>>>> Sounds reasonable, I'll do this.
>>>>>>
>>>>>>> And another, no
>>>>>>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
>>>>>>> add the GUID definitions to AutoGen files from package dec.
>>>>>>
>>>>>> I disagree with this. I mean, I *personally* wouldn't mind, but this
>>>>>> would be inconsistent with existing MdeModulePkg practice. For
>example,
>>>>>> see
>>>>>>
>>>>>> MdeModulePkg/Include/Guid/TtyTerm.h
>>>>>>
>>>>>> Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no
>data
>>>>>> structures associated with it; the header file only has an extern
>>>>>> declaration, and -- importantly -- an array initializer macro called
>>>>>> EFI_TTY_TERM_GUID, which can be used in the following syntax:
>>>>>>
>>>>>> STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
>>>>>>
>>>>>> So, I think that the GUID header file is required. I will add it in v3.
>>>>>>
>>>>>> Once we generalize this idea to the design that you laid out above, we
>>>>>> can perhaps eliminate the header file. But, for now, I think we should
>>>>>> remain consistent with other MdeModulePkg GUID definitions.
>>>>>>
>>>>>>> 2. You can file bugzilla bug to request BaseTools syntax support to
>>>>>>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and
>DepexLib
>>>>>>> could be finally added into core package MdeModulePkg or even
>MdePkg
>>>>>>> (I prefer).
>>>>>>
>>>>>> I filed:
>>>>>>
>>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
>>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
>>>>>>
>>>>>>> Before that, how about implementing the
>>>>>>> PlatformHasAcpiLib in none core package?
>>>>>>
>>>>>> Works for me; I'll split that part off and keep it under ArmPkg.
>>>>>>
>>>>>> Thanks
>>>>>> Laszlo
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Star
>>>>>>> -----Original Message-----
>>>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
>Behalf Of
>>>>>> Ard Biesheuvel
>>>>>>> Sent: Thursday, March 23, 2017 5:09 PM
>>>>>>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>>>>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>>>>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek
><lersek@redhat.com>;
>>>>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>>>>> <leif.lindholm@linaro.org>
>>>>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII
>Platform Has
>>>>>> ACPI Protocol, and plug-in library
>>>>>>>
>>>>>>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>>>>>>>> I prefer to do not include the protocol definition and the library
>instance
>>>>>> into MdeModulePkg at this moment until they need to be used by
>multiple
>>>>>> platforms/archs.
>>>>>>>>
>>>>>>>
>>>>>>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for
>any
>>>>>> architecture) that ACPI is mandatory. Given that EDK2 is the reference
>>>>>> platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
>>>>>> unreasonable to have lots and lots of PC quirks (i.e., allocations below 4
>GB) in
>>>>>> MdeModulePkg, but then disallow a clean approach to make ACPI
>selectable,
>>>>>> in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>>>>>>>
>>>>>>> So I think at least the protocol definitions belong in MdeModulePkg.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Ard.
>>>>>>> _______________________________________________
>>>>>>> edk2-devel mailing list
>>>>>>> edk2-devel@lists.01.org
>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> edk2-devel mailing list
>>>>>> edk2-devel@lists.01.org
>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-29 9:49 ` Gao, Liming
@ 2017-03-29 13:03 ` Laszlo Ersek
0 siblings, 0 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-29 13:03 UTC (permalink / raw)
To: Gao, Liming, Ard Biesheuvel
Cc: Zeng, Star, Kinney, Michael D, afish@apple.com, Tian, Feng,
edk2-devel-01, Leif Lindholm
On 03/29/17 11:49, Gao, Liming wrote:
> Laszlo:
> I agree GuidCName can't be used to initialize the global variable. If
> there is such requirement, GUID C MACRO will have to be defined.
> Then, its header file will be required.
> Now, we have no rule to forbid to add the header file if it has no
> other definitions except for GUID value, and we have no such
> discussion to define those rules. It is the developer choice to add
> it or not.
> Here, I want to mention that BaseTools has added "extern gGuidCName"
> into AutoGen header file. The consumer code can directly use
> gGuidCName without include its header file. If no GUID MACRO usage,
> its header file is not necessary.
>
> For this case gEdkiiPlatformHasAcpiGuid, I know it will be as
> protocol dependency. I don't see its GUID C MACRO usage. So, I
> suggest not to add its header file. This is just my opinion.
Thank you for explaining the situation.
For now we've moved all of the generic/core patches in this series to
EmbeddedPkg (and the v4 series has been committed). Once Leif returns,
we can perhaps think about moving those GUIDs / lib instances to
MdeModulePkg, and we could agree at that point to drop the Guid/ header.
> For BaseTools enhancement to generated GUID C MACRO in autogen.h, I
> think it is valuable. To avoid the generated MACRO conflict with the
> existing MACRO, the generated MACRO will still have "G" prefix, such
> as gEdkiiPlatformHasAcpiGuid ==> G_EDKII_PLATFORM_HAS_ACPI_GUID.
Thanks -- I filed <https://bugzilla.tianocore.org/show_bug.cgi?id=449>.
I marked it as a whishlist item.
Cheers
Laszlo
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>> Sent: Tuesday, March 28, 2017 3:50 PM
>> To: Gao, Liming <liming.gao@intel.com>; Ard Biesheuvel
>> <ard.biesheuvel@linaro.org>
>> Cc: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; afish@apple.com; Tian, Feng
>> <feng.tian@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif
>> Lindholm <leif.lindholm@linaro.org>
>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>> ACPI Protocol, and plug-in library
>>
>> On 03/28/17 07:25, Gao, Liming wrote:
>>> Ersek:
>>> I don't want to block your patch. You can still check in Guid header file if you
>> think it is necessary.
>>
>> I don't want to check in without formal MdeModulePkg maintainer
>> approval. If I check in a patch without formal approval, that will only
>> lead to chaos. I don't want to circumvent the process; I want the
>> process to *work*.
>>
>> If MdeModulePkg maintainers agree with my
>>
>> [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID
>>
>> then they should please give their Reviewed-by for it.
>>
>> If they disagree with it, they should please explain why.
>>
>> The specific argument you raised, namely that a BaseTools utility
>> generates the necessary C language artifacts for GUID use, is not
>> precise. BaseTools generate *some* artifacts, but they do not generate a
>> macro that is usable for initializing a GUID object of static storage
>> duration (= global variable GUID, or a GUID field in a global variable
>> structure).
>>
>> This is what the ISO C99 standard says:
>>
>> 6.7.8 Initialization
>>
>> [...]
>>
>> Constraints
>>
>> [...]
>>
>> 4 All the expressions in an initializer for an object that has static
>> storage duration shall be constant expressions or string literals.
>>
>> [...]
>>
>> 16 Otherwise, the initializer for an object that has aggregate or
>> union type shall be a brace-enclosed list of initializers for the
>> elements or named members.
>>
>> [...]
>>
>> 20 If the aggregate or union contains elements or members that are
>> aggregates or unions, these rules apply recursively to the
>> subaggregates or contained unions. [...]
>>
>> This is the GUID type definition:
>>
>> typedef struct {
>> UINT32 Data1;
>> UINT16 Data2;
>> UINT16 Data3;
>> UINT8 Data4[8];
>> } GUID;
>>
>> For this structure, the above standardese implies that we have to
>> provide integer constant expressions in the initializer.
>>
>> 6.6 Constant expressions
>>
>> [...]
>>
>> 6 An /integer constant expression/ shall have integer type and shall
>> only have operands that are integer constants, enumeration
>> constants, character constants, /sizeof/ expressions whose results
>> are integer constants, and floating constants that are the
>> immediate operands of casts. Cast operators in an integer constant
>> expression shall only convert arithmetic types to integer types,
>> except as part of an operand to the /sizeof/ operator.
>>
>> The end result is that "gEdkiiPlatformHasAcpiGuid" is not usable in such
>> contexts, but the EDKII_PLATFORM_HAS_ACPI_GUID macro is.
>>
>>
>> If you want, I can file a TianoCore feature request BZ for generating
>> such macros as well in BaseTools, but for now, I don't think it should
>> either block my patch noted above, or force me to drop the Guid/ header
>> file from the patch. Right now, the Guid/ header adds something that is
>> not available from BaseTools, and I wouldn't like to delay the v3 series
>> any longer.
>>
>> Do you agree to the above method? I file a TianoCore Feature Request BZ
>> for BaseTools, and MdeModulePkg maintainers formally approve the v3
>> 04/12 patch?
>>
>>
>> (Side point: I think the Guid/ header file has another benefit:
>> documentation. I don't think we can add the amount of documentation that
>> is acceptable in a standalone Guid/ header to an in-line comment in the
>> .DEC file. So, I think that the new rule for not adding Guid/ headers is
>> immature at this point -- and, worse, I don't recall an open
>> announcement or discussion about this rule, so that we could have raised
>> concerns before turning the proposal into an actual rule.)
>>
>> Thanks
>> Laszlo
>>
>>>> -----Original Message-----
>>>> From: Laszlo Ersek [mailto:lersek@redhat.com]
>>>> Sent: Tuesday, March 28, 2017 1:32 AM
>>>> To: Ard Biesheuvel <ard.biesheuvel@linaro.org>; Gao, Liming
>> <liming.gao@intel.com>
>>>> Cc: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; afish@apple.com; Tian, Feng
>>>> <feng.tian@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Leif
>> Lindholm <leif.lindholm@linaro.org>
>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has
>> ACPI Protocol, and plug-in library
>>>>
>>>> On 03/27/17 09:00, Ard Biesheuvel wrote:
>>>>> On 27 March 2017 at 03:42, Gao, Liming <liming.gao@intel.com> wrote:
>>>>>> Laszlo:
>>>>>> On GUID header file, some header file are here, because they are
>> added before BaseTools supports it. Now, we allow not to add
>>>> header file if the header file only has GUID value definition.
>>>>>
>>>>> I have to agree with Laszlo here. The BaseTools support is incomplete,
>>>>> since it does not add a #define for the GUID to AutoGen.h. This makes
>>>>> it impossible to initialize static structures containing GUIDs, such
>>>>> as templates containing vendor device paths.
>>>>>
>>>>> For instance, the following
>>>>>
>>>>> typedef struct {
>>>>> EFI_GUID foo;
>>>>> } TYPE;
>>>>>
>>>>> TYPE mFoo {
>>>>> SOME_GUID
>>>>> };
>>>>>
>>>>> is not possible without a Guid/xxx.h include file containing a #define
>>>>> for SOME_GUID.
>>>>
>>>> I wonder if we can commit this series before end of April.
>>>>
>>>> Or is that too soon? End of May perhaps?
>>>>
>>>> The mind boggles.
>>>>
>>>> Laszlo
>>>>
>>>>>
>>>>>> On GUID C MACRO, we suggest to use GuidCName in every C source
>> code. So, we don't suggest to add it. As you know, some
>>>> existing header files have GuidCName and GUID Macro. Now, we have no
>> plan to clean up the existing one. But, we expect new added
>>>> file follows this rule.
>>>>>>
>>>>>> Thanks
>>>>>> Liming
>>>>>>> -----Original Message-----
>>>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf
>> Of
>>>>>>> Laszlo Ersek
>>>>>>> Sent: Saturday, March 25, 2017 1:09 AM
>>>>>>> To: Zeng, Star <star.zeng@intel.com>; Ard Biesheuvel
>>>>>>> <ard.biesheuvel@linaro.org>; Kinney, Michael D
>>>>>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>>>>> Cc: Tian, Feng <feng.tian@intel.com>; Gao, Liming
>> <liming.gao@intel.com>;
>>>>>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>>>>>> <leif.lindholm@linaro.org>
>>>>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform
>> Has
>>>>>>> ACPI Protocol, and plug-in library
>>>>>>>
>>>>>>> On 03/24/17 04:44, Zeng, Star wrote:
>>>>>>>> I just think it seems a generic problem.
>>>>>>>> Some platforms may dynamically determine whether ACPI should be
>>>>>>> supported or not.
>>>>>>>> Some platforms may dynamically determine whether SMBIOS should
>> be
>>>>>>> supported or not.
>>>>>>>> Some platforms may dynamically determine whether HII should be
>>>>>>> supported or not.
>>>>>>>> ...
>>>>>>>>
>>>>>>>> We are thinking whether we can have a generic NULL instance to
>> support all
>>>>>>> this kind of cases, for example:
>>>>>>>> 1. Define a FixedAtBuild PCD PcdDepexGuid that will be a VOID* type
>> PCD
>>>>>>> point to a depex GUID.
>>>>>>>> 2. Implement a NULL instance DepexLib.
>>>>>>>> [Defines]
>>>>>>>> INF_VERSION = 0x00010005
>>>>>>>> BASE_NAME = DepexLib
>>>>>>>> FILE_GUID = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
>>>>>>>> MODULE_TYPE = BASE
>>>>>>>> VERSION_STRING = 1.0
>>>>>>>> LIBRARY_CLASS = NULL
>>>>>>>>
>>>>>>>> [Sources]
>>>>>>>> DepexLib.c
>>>>>>>>
>>>>>>>> [Packages]
>>>>>>>> XXXPkg/XXXPkg.dec
>>>>>>>>
>>>>>>>> [Depex]
>>>>>>>> PcdDepexGuid
>>>>>>>>
>>>>>>>> 3. Link NULL instance and configure PCD in dsc.
>>>>>>>> MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>>>>>>>> <LibraryClasses>
>>>>>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>>>>>> <PcdsFixedAtBuild>
>>>>>>>> PcdDepexGuid|gEdkiiPlatformHasAcpiGuid
>>>>>>>> }
>>>>>>>> MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf {
>>>>>>>> <LibraryClasses>
>>>>>>>> NULL|XXXPkg/Library/DepexLib/DepexLib.inf
>>>>>>>> <PcdsFixedAtBuild>
>>>>>>>> PcdDepexGuid|gEdkiiPlatformHasSmbiosGuid
>>>>>>>> }
>>>>>>>>
>>>>>>>> But current BaseTools does not support the syntax to declare PCD in
>> [Depex]
>>>>>>> section of inf yet.
>>>>>>>>
>>>>>>>> Based on the statements above, I have below comments.
>>>>>>>
>>>>>>>> 1. I agree to add the GUID into MdeModulePkg, but how about using
>>>>>>>> gEdkiiPlatformHasAcpiGuid instead of
>>>>>>>> gEdkiiPlatformHasAcpiProtocolGuid and add the GUID into [Guids]
>>>>>>>> section of MdeModulePkg.dec? As Platform can install
>>>>>>>> gEdkiiPlatformHasAcpiGuid PPI to control PEIM and install
>>>>>>>> gEdkiiPlatformHasAcpiGuid PROTOCOL to control DRIVER.
>>>>>>>
>>>>>>> Sounds reasonable, I'll do this.
>>>>>>>
>>>>>>>> And another, no
>>>>>>>> need to add a include file PlatformHasAcpi.h as BaseTools supports to
>>>>>>>> add the GUID definitions to AutoGen files from package dec.
>>>>>>>
>>>>>>> I disagree with this. I mean, I *personally* wouldn't mind, but this
>>>>>>> would be inconsistent with existing MdeModulePkg practice. For
>> example,
>>>>>>> see
>>>>>>>
>>>>>>> MdeModulePkg/Include/Guid/TtyTerm.h
>>>>>>>
>>>>>>> Similarly to the current case, that GUID ("gEfiTtyTermGuid") has no
>> data
>>>>>>> structures associated with it; the header file only has an extern
>>>>>>> declaration, and -- importantly -- an array initializer macro called
>>>>>>> EFI_TTY_TERM_GUID, which can be used in the following syntax:
>>>>>>>
>>>>>>> STATIC CONST EFI_GUID mThisIsMyGuid = EFI_TTY_TERM_GUID;
>>>>>>>
>>>>>>> So, I think that the GUID header file is required. I will add it in v3.
>>>>>>>
>>>>>>> Once we generalize this idea to the design that you laid out above, we
>>>>>>> can perhaps eliminate the header file. But, for now, I think we should
>>>>>>> remain consistent with other MdeModulePkg GUID definitions.
>>>>>>>
>>>>>>>> 2. You can file bugzilla bug to request BaseTools syntax support to
>>>>>>>> declare PCD in [Depex] section of inf. Then PcdDepexGuid and
>> DepexLib
>>>>>>>> could be finally added into core package MdeModulePkg or even
>> MdePkg
>>>>>>>> (I prefer).
>>>>>>>
>>>>>>> I filed:
>>>>>>>
>>>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=443 -- for BaseTools,
>>>>>>> https://bugzilla.tianocore.org/show_bug.cgi?id=444 -- for the INF spec
>>>>>>>
>>>>>>>> Before that, how about implementing the
>>>>>>>> PlatformHasAcpiLib in none core package?
>>>>>>>
>>>>>>> Works for me; I'll split that part off and keep it under ArmPkg.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Laszlo
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Star
>>>>>>>> -----Original Message-----
>>>>>>>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On
>> Behalf Of
>>>>>>> Ard Biesheuvel
>>>>>>>> Sent: Thursday, March 23, 2017 5:09 PM
>>>>>>>> To: Zeng, Star <star.zeng@intel.com>; Kinney, Michael D
>>>>>>> <michael.d.kinney@intel.com>; afish@apple.com
>>>>>>>> Cc: Tian, Feng <feng.tian@intel.com>; Laszlo Ersek
>> <lersek@redhat.com>;
>>>>>>> edk2-devel-01 <edk2-devel@lists.01.org>; Leif Lindholm
>>>>>>> <leif.lindholm@linaro.org>
>>>>>>>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII
>> Platform Has
>>>>>>> ACPI Protocol, and plug-in library
>>>>>>>>
>>>>>>>> On 23 March 2017 at 01:41, Zeng, Star <star.zeng@intel.com> wrote:
>>>>>>>>> I prefer to do not include the protocol definition and the library
>> instance
>>>>>>> into MdeModulePkg at this moment until they need to be used by
>> multiple
>>>>>>> platforms/archs.
>>>>>>>>>
>>>>>>>>
>>>>>>>> I disagree. Nowhere in the PI or UEFI spec is there any mention (for
>> any
>>>>>>> architecture) that ACPI is mandatory. Given that EDK2 is the reference
>>>>>>> platform UEFI/PI, and not for ACPI or the PC/x86 platform, I think it is
>>>>>>> unreasonable to have lots and lots of PC quirks (i.e., allocations below 4
>> GB) in
>>>>>>> MdeModulePkg, but then disallow a clean approach to make ACPI
>> selectable,
>>>>>>> in a way that is true to the spirit of PI (i.e., using protocol dependencies)
>>>>>>>>
>>>>>>>> So I think at least the protocol definitions belong in MdeModulePkg.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Ard.
>>>>>>>> _______________________________________________
>>>>>>>> edk2-devel mailing list
>>>>>>>> edk2-devel@lists.01.org
>>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> edk2-devel mailing list
>>>>>>> edk2-devel@lists.01.org
>>>>>>> https://lists.01.org/mailman/listinfo/edk2-devel
>>>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-17 20:47 ` [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library Laszlo Ersek
2017-03-18 15:00 ` Leif Lindholm
@ 2017-03-20 2:23 ` Zeng, Star
2017-03-20 9:17 ` Laszlo Ersek
2017-03-22 16:45 ` Laszlo Ersek
2 siblings, 1 reply; 67+ messages in thread
From: Zeng, Star @ 2017-03-20 2:23 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-01; +Cc: Leif Lindholm, Ard Biesheuvel, Zeng, Star
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
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-20 2:23 ` Zeng, Star
@ 2017-03-20 9:17 ` Laszlo Ersek
2017-03-20 9:57 ` Zeng, Star
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-20 9:17 UTC (permalink / raw)
To: Zeng, Star, edk2-devel-01; +Cc: Leif Lindholm, Ard Biesheuvel
On 03/20/17 03:23, Zeng, Star wrote:
> 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?
If a library constructor fails, then the client module does not see an
explicit error (or automatic unloading); instead, an assertion failure
is triggered in auto-generated code.
For example, in the
"Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
file, with this series applied, we find:
> VOID
> EFIAPI
> ProcessLibraryConstructorList (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> EFI_STATUS Status;
>
> Status = HobLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = FdtPL011SerialPortLibInitialize ();
> ASSERT_EFI_ERROR (Status);
>
> Status = BaseDebugLibSerialPortConstructor ();
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
> ASSERT_EFI_ERROR (Status);
>
> }
What we could do instead would be a new library class, with an explicit
initialization function. However, for that to work, AcpiTableDxe would
have to be extended with a new library class dependency and a call to
the init function. Additionally, out-of-tree platform DSC files would
have to resolve this library class to the default instance.
Introducing a boolean dynamic PCD for the same would be much simpler
then; the DEC default would cover out-of-tree platform DSCs without any
change in behavior.
In summary, there are two alternatives in my opinion:
(1) If we prefer not to modify MdeModulePkg: stick with this series. The
only update I'd see justified would be to move
gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif
requested.
(2) If we are willing to modify MdeModulePkg for this problem: introduce
a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe
exit early if the PCD is FALSE.
Thanks,
Laszlo
>
> 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
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-20 9:17 ` Laszlo Ersek
@ 2017-03-20 9:57 ` Zeng, Star
2017-03-21 2:27 ` Zeng, Star
0 siblings, 1 reply; 67+ messages in thread
From: Zeng, Star @ 2017-03-20 9:57 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-01, Kinney, Michael D, Yao, Jiewen
Cc: Leif Lindholm, Ard Biesheuvel
Oh got it, returning unsuccessfully in constructor of library does not work. :(
For (1), I definitely have no any comments. :)
For (2), I got no strong reason to support or reject it. We'd better could get comments from Mike and Jiewen.
Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Monday, March 20, 2017 5:18 PM
To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
On 03/20/17 03:23, Zeng, Star wrote:
> 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?
If a library constructor fails, then the client module does not see an explicit error (or automatic unloading); instead, an assertion failure is triggered in auto-generated code.
For example, in the
"Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
file, with this series applied, we find:
> VOID
> EFIAPI
> ProcessLibraryConstructorList (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> EFI_STATUS Status;
>
> Status = HobLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = FdtPL011SerialPortLibInitialize ();
> ASSERT_EFI_ERROR (Status);
>
> Status = BaseDebugLibSerialPortConstructor ();
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
> ASSERT_EFI_ERROR (Status);
>
> }
What we could do instead would be a new library class, with an explicit initialization function. However, for that to work, AcpiTableDxe would have to be extended with a new library class dependency and a call to the init function. Additionally, out-of-tree platform DSC files would have to resolve this library class to the default instance.
Introducing a boolean dynamic PCD for the same would be much simpler then; the DEC default would cover out-of-tree platform DSCs without any change in behavior.
In summary, there are two alternatives in my opinion:
(1) If we prefer not to modify MdeModulePkg: stick with this series. The only update I'd see justified would be to move gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif requested.
(2) If we are willing to modify MdeModulePkg for this problem: introduce a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe exit early if the PCD is FALSE.
Thanks,
Laszlo
>
> 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|0x000000
> 01
>
> 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
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-20 9:57 ` Zeng, Star
@ 2017-03-21 2:27 ` Zeng, Star
2017-03-21 7:10 ` Ard Biesheuvel
2017-03-21 8:37 ` Laszlo Ersek
0 siblings, 2 replies; 67+ messages in thread
From: Zeng, Star @ 2017-03-21 2:27 UTC (permalink / raw)
To: Zeng, Star, Laszlo Ersek, edk2-devel-01, Kinney, Michael D,
Yao, Jiewen
Cc: Leif Lindholm, Ard Biesheuvel
Just an idea.
There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Zeng, Star
Sent: Monday, March 20, 2017 5:57 PM
To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
Oh got it, returning unsuccessfully in constructor of library does not work. :(
For (1), I definitely have no any comments. :) For (2), I got no strong reason to support or reject it. We'd better could get comments from Mike and Jiewen.
Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Monday, March 20, 2017 5:18 PM
To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
On 03/20/17 03:23, Zeng, Star wrote:
> 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?
If a library constructor fails, then the client module does not see an explicit error (or automatic unloading); instead, an assertion failure is triggered in auto-generated code.
For example, in the
"Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
file, with this series applied, we find:
> VOID
> EFIAPI
> ProcessLibraryConstructorList (
> IN EFI_HANDLE ImageHandle,
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> EFI_STATUS Status;
>
> Status = HobLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = FdtPL011SerialPortLibInitialize ();
> ASSERT_EFI_ERROR (Status);
>
> Status = BaseDebugLibSerialPortConstructor ();
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = UefiLibConstructor (ImageHandle, SystemTable);
> ASSERT_EFI_ERROR (Status);
>
> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
> ASSERT_EFI_ERROR (Status);
>
> }
What we could do instead would be a new library class, with an explicit initialization function. However, for that to work, AcpiTableDxe would have to be extended with a new library class dependency and a call to the init function. Additionally, out-of-tree platform DSC files would have to resolve this library class to the default instance.
Introducing a boolean dynamic PCD for the same would be much simpler then; the DEC default would cover out-of-tree platform DSCs without any change in behavior.
In summary, there are two alternatives in my opinion:
(1) If we prefer not to modify MdeModulePkg: stick with this series. The only update I'd see justified would be to move gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif requested.
(2) If we are willing to modify MdeModulePkg for this problem: introduce a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe exit early if the PCD is FALSE.
Thanks,
Laszlo
>
> 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|0x000000
> 01
>
> 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
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 2:27 ` Zeng, Star
@ 2017-03-21 7:10 ` Ard Biesheuvel
2017-03-21 8:43 ` Ard Biesheuvel
2017-03-21 8:37 ` Laszlo Ersek
1 sibling, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-21 7:10 UTC (permalink / raw)
To: Zeng, Star
Cc: Laszlo Ersek, edk2-devel-01, Kinney, Michael D, Yao, Jiewen,
Leif Lindholm
On 21 March 2017 at 02:27, Zeng, Star <star.zeng@intel.com> wrote:
> Just an idea.
>
I llike it!
> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
>
So could we then upgrade the definition so it is possible to use a
dynamic PCD for this?
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Zeng, Star
> Sent: Monday, March 20, 2017 5:57 PM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> Oh got it, returning unsuccessfully in constructor of library does not work. :(
>
> For (1), I definitely have no any comments. :) For (2), I got no strong reason to support or reject it. We'd better could get comments from Mike and Jiewen.
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Monday, March 20, 2017 5:18 PM
> To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> On 03/20/17 03:23, Zeng, Star wrote:
>> 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?
>
> If a library constructor fails, then the client module does not see an explicit error (or automatic unloading); instead, an assertion failure is triggered in auto-generated code.
>
> For example, in the
> "Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
> file, with this series applied, we find:
>
>> VOID
>> EFIAPI
>> ProcessLibraryConstructorList (
>> IN EFI_HANDLE ImageHandle,
>> IN EFI_SYSTEM_TABLE *SystemTable
>> )
>> {
>> EFI_STATUS Status;
>>
>> Status = HobLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = FdtPL011SerialPortLibInitialize ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = BaseDebugLibSerialPortConstructor ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
>> ASSERT_EFI_ERROR (Status);
>>
>> }
>
> What we could do instead would be a new library class, with an explicit initialization function. However, for that to work, AcpiTableDxe would have to be extended with a new library class dependency and a call to the init function. Additionally, out-of-tree platform DSC files would have to resolve this library class to the default instance.
>
> Introducing a boolean dynamic PCD for the same would be much simpler then; the DEC default would cover out-of-tree platform DSCs without any change in behavior.
>
> In summary, there are two alternatives in my opinion:
>
> (1) If we prefer not to modify MdeModulePkg: stick with this series. The only update I'd see justified would be to move gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif requested.
>
> (2) If we are willing to modify MdeModulePkg for this problem: introduce a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe exit early if the PCD is FALSE.
>
> Thanks,
> Laszlo
>
>>
>> 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|0x000000
>> 01
>>
>> 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
>>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 7:10 ` Ard Biesheuvel
@ 2017-03-21 8:43 ` Ard Biesheuvel
2017-03-21 9:02 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-21 8:43 UTC (permalink / raw)
To: Zeng, Star
Cc: Laszlo Ersek, edk2-devel-01, Kinney, Michael D, Yao, Jiewen,
Leif Lindholm
On 21 March 2017 at 07:10, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
> On 21 March 2017 at 02:27, Zeng, Star <star.zeng@intel.com> wrote:
>> Just an idea.
>>
>
> I like it!
>
>> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
>> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
>>
>
> So could we then upgrade the definition so it is possible to use a
> dynamic PCD for this?
>
Oh, and how is the ordering ensured in this case? We need to set the
dynamic PCD at runtime, but obviously before AcpiTableDxe gets a
chance to load. If the only way to achieve this is another NULL class
library, then this is not much of an improvement. Or could we detect
the table-loader node from PEI as well?
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 8:43 ` Ard Biesheuvel
@ 2017-03-21 9:02 ` Laszlo Ersek
2017-03-21 18:00 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-21 9:02 UTC (permalink / raw)
To: Ard Biesheuvel, Zeng, Star
Cc: edk2-devel-01, Kinney, Michael D, Yao, Jiewen, Leif Lindholm
On 03/21/17 09:43, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:10, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 21 March 2017 at 02:27, Zeng, Star <star.zeng@intel.com> wrote:
>>> Just an idea.
>>>
>>
>> I like it!
>>
>>> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
>>> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
>>>
>>
>> So could we then upgrade the definition so it is possible to use a
>> dynamic PCD for this?
>>
>
> Oh, and how is the ordering ensured in this case? We need to set the
> dynamic PCD at runtime, but obviously before AcpiTableDxe gets a
> chance to load. If the only way to achieve this is another NULL class
> library, then this is not much of an improvement.
I've been silently waiting for this to get noticed :)
In the ArmVirtQemu case, the PCD value would be set from fw_cfg. But in
ArmVirtQemu, fw_cfg is not available in PEI, only in DXE, so yes, a NULL
class library would be needed.
In physical firmware (also in the planned "showcase QEMU" case), the
toggle would be exposed by another DXE driver (a platform driver) using
an HII form. Generally such a driver translates an nvvar to a PcdSet in
its entry point, plus registers HII stuff that allows the nvvar to be
toggled interactively in the setup browser, for the next boot. Either
way, the PcdSet would again only happen in DXE.
> Or could we detect
> the table-loader node from PEI as well?
Not at the moment; fw_cfg is currently not available in PEI, in ArmVirtQemu.
ArmVirtQemu's PEI phase executes in-place from pflash. That means no
writeable global variables (unless you make a PEIM, or the PEI library
instance, dependent on the "memory discovered" PPI). Even using just the
MMIO (no DMA) interface to fw_cfg, you'd have to parse the DTB on every
invocation. (No writeable global variables imply you can't pre-parse the
stuff in the library constructor.)
A similar example is
"ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c",
where each serial port write has to re-parse the base address from the DT.
(OVMF is different because OVMF's PEI runs from memory.)
So, whatever you saved on the PcdSet ordering in the DXE phase, you
would triply lose in fw_cfg complexity in PEI. A new PEI library
instance would be necessary for fw_cfg, which would either have to parse
the DT on each invocation, or else depend on permanent PEI RAM
availability (which would be the same (or worse) kind of ordering
restriction that you're trying to avoid in DXE in the first place).
Thanks
Laszlo
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 9:02 ` Laszlo Ersek
@ 2017-03-21 18:00 ` Laszlo Ersek
2017-03-22 14:12 ` Ard Biesheuvel
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-21 18:00 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Zeng, Star, Kinney, Michael D, edk2-devel-01, Yao, Jiewen,
Leif Lindholm
On 03/21/17 10:02, Laszlo Ersek wrote:
> On 03/21/17 09:43, Ard Biesheuvel wrote:
>> On 21 March 2017 at 07:10, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>> On 21 March 2017 at 02:27, Zeng, Star <star.zeng@intel.com> wrote:
>>>> Just an idea.
>>>>
>>>
>>> I like it!
>>>
>>>> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
>>>> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
>>>>
>>>
>>> So could we then upgrade the definition so it is possible to use a
>>> dynamic PCD for this?
>>>
>>
>> Oh, and how is the ordering ensured in this case? We need to set the
>> dynamic PCD at runtime, but obviously before AcpiTableDxe gets a
>> chance to load. If the only way to achieve this is another NULL class
>> library, then this is not much of an improvement.
>
> I've been silently waiting for this to get noticed :)
>
> In the ArmVirtQemu case, the PCD value would be set from fw_cfg. But in
> ArmVirtQemu, fw_cfg is not available in PEI, only in DXE, so yes, a NULL
> class library would be needed.
>
> In physical firmware (also in the planned "showcase QEMU" case), the
> toggle would be exposed by another DXE driver (a platform driver) using
> an HII form. Generally such a driver translates an nvvar to a PcdSet in
> its entry point, plus registers HII stuff that allows the nvvar to be
> toggled interactively in the setup browser, for the next boot. Either
> way, the PcdSet would again only happen in DXE.
>
>> Or could we detect
>> the table-loader node from PEI as well?
>
> Not at the moment; fw_cfg is currently not available in PEI, in ArmVirtQemu.
>
> ArmVirtQemu's PEI phase executes in-place from pflash. That means no
> writeable global variables (unless you make a PEIM, or the PEI library
> instance, dependent on the "memory discovered" PPI). Even using just the
> MMIO (no DMA) interface to fw_cfg, you'd have to parse the DTB on every
> invocation. (No writeable global variables imply you can't pre-parse the
> stuff in the library constructor.)
>
> A similar example is
> "ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c",
> where each serial port write has to re-parse the base address from the DT.
>
> (OVMF is different because OVMF's PEI runs from memory.)
>
> So, whatever you saved on the PcdSet ordering in the DXE phase, you
> would triply lose in fw_cfg complexity in PEI. A new PEI library
> instance would be necessary for fw_cfg, which would either have to parse
> the DT on each invocation, or else depend on permanent PEI RAM
> availability (which would be the same (or worse) kind of ordering
> restriction that you're trying to avoid in DXE in the first place).
So... does that make this patch set (relatively) less "unwieldy" to you?
Thanks,
Laszlo
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 18:00 ` Laszlo Ersek
@ 2017-03-22 14:12 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:12 UTC (permalink / raw)
To: Laszlo Ersek
Cc: Zeng, Star, Kinney, Michael D, edk2-devel-01, Yao, Jiewen,
Leif Lindholm
On 21 March 2017 at 18:00, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/21/17 10:02, Laszlo Ersek wrote:
>> On 03/21/17 09:43, Ard Biesheuvel wrote:
>>> On 21 March 2017 at 07:10, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>>>> On 21 March 2017 at 02:27, Zeng, Star <star.zeng@intel.com> wrote:
>>>>> Just an idea.
>>>>>
>>>>
>>>> I like it!
>>>>
>>>>> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
>>>>> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
>>>>>
>>>>
>>>> So could we then upgrade the definition so it is possible to use a
>>>> dynamic PCD for this?
>>>>
>>>
>>> Oh, and how is the ordering ensured in this case? We need to set the
>>> dynamic PCD at runtime, but obviously before AcpiTableDxe gets a
>>> chance to load. If the only way to achieve this is another NULL class
>>> library, then this is not much of an improvement.
>>
>> I've been silently waiting for this to get noticed :)
>>
>> In the ArmVirtQemu case, the PCD value would be set from fw_cfg. But in
>> ArmVirtQemu, fw_cfg is not available in PEI, only in DXE, so yes, a NULL
>> class library would be needed.
>>
>> In physical firmware (also in the planned "showcase QEMU" case), the
>> toggle would be exposed by another DXE driver (a platform driver) using
>> an HII form. Generally such a driver translates an nvvar to a PcdSet in
>> its entry point, plus registers HII stuff that allows the nvvar to be
>> toggled interactively in the setup browser, for the next boot. Either
>> way, the PcdSet would again only happen in DXE.
>>
>>> Or could we detect
>>> the table-loader node from PEI as well?
>>
>> Not at the moment; fw_cfg is currently not available in PEI, in ArmVirtQemu.
>>
>> ArmVirtQemu's PEI phase executes in-place from pflash. That means no
>> writeable global variables (unless you make a PEIM, or the PEI library
>> instance, dependent on the "memory discovered" PPI). Even using just the
>> MMIO (no DMA) interface to fw_cfg, you'd have to parse the DTB on every
>> invocation. (No writeable global variables imply you can't pre-parse the
>> stuff in the library constructor.)
>>
>> A similar example is
>> "ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c",
>> where each serial port write has to re-parse the base address from the DT.
>>
>> (OVMF is different because OVMF's PEI runs from memory.)
>>
>> So, whatever you saved on the PcdSet ordering in the DXE phase, you
>> would triply lose in fw_cfg complexity in PEI. A new PEI library
>> instance would be necessary for fw_cfg, which would either have to parse
>> the DT on each invocation, or else depend on permanent PEI RAM
>> availability (which would be the same (or worse) kind of ordering
>> restriction that you're trying to avoid in DXE in the first place).
>
> So... does that make this patch set (relatively) less "unwieldy" to you?
>
I suppose, yes :-)
I guess we will never have a perfect solution for this, and using
library classes and protocol dependencies is much preferred over
having to reason about when a dynamic PCD assumes its correct value.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 2:27 ` Zeng, Star
2017-03-21 7:10 ` Ard Biesheuvel
@ 2017-03-21 8:37 ` Laszlo Ersek
2017-03-21 8:41 ` Zeng, Star
1 sibling, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-21 8:37 UTC (permalink / raw)
To: Zeng, Star, edk2-devel-01, Kinney, Michael D, Yao, Jiewen
Cc: Leif Lindholm, Ard Biesheuvel
On 03/21/17 03:27, Zeng, Star wrote:
> Just an idea.
>
> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
Hm, I don't see that:
$ git grep EFI_UNSUPPORTED -- MdeModulePkg/Universal/Acpi/AcpiTableDxe/
[no matches]
Thanks
Laszlo
>
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Zeng, Star
> Sent: Monday, March 20, 2017 5:57 PM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> Oh got it, returning unsuccessfully in constructor of library does not work. :(
>
> For (1), I definitely have no any comments. :) For (2), I got no strong reason to support or reject it. We'd better could get comments from Mike and Jiewen.
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Monday, March 20, 2017 5:18 PM
> To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> On 03/20/17 03:23, Zeng, Star wrote:
>> 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?
>
> If a library constructor fails, then the client module does not see an explicit error (or automatic unloading); instead, an assertion failure is triggered in auto-generated code.
>
> For example, in the
> "Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
> file, with this series applied, we find:
>
>> VOID
>> EFIAPI
>> ProcessLibraryConstructorList (
>> IN EFI_HANDLE ImageHandle,
>> IN EFI_SYSTEM_TABLE *SystemTable
>> )
>> {
>> EFI_STATUS Status;
>>
>> Status = HobLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = FdtPL011SerialPortLibInitialize ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = BaseDebugLibSerialPortConstructor ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
>> ASSERT_EFI_ERROR (Status);
>>
>> }
>
> What we could do instead would be a new library class, with an explicit initialization function. However, for that to work, AcpiTableDxe would have to be extended with a new library class dependency and a call to the init function. Additionally, out-of-tree platform DSC files would have to resolve this library class to the default instance.
>
> Introducing a boolean dynamic PCD for the same would be much simpler then; the DEC default would cover out-of-tree platform DSCs without any change in behavior.
>
> In summary, there are two alternatives in my opinion:
>
> (1) If we prefer not to modify MdeModulePkg: stick with this series. The only update I'd see justified would be to move gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif requested.
>
> (2) If we are willing to modify MdeModulePkg for this problem: introduce a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe exit early if the PCD is FALSE.
>
> Thanks,
> Laszlo
>
>>
>> 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|0x000000
>> 01
>>
>> 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
>>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 8:37 ` Laszlo Ersek
@ 2017-03-21 8:41 ` Zeng, Star
2017-03-21 9:05 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Zeng, Star @ 2017-03-21 8:41 UTC (permalink / raw)
To: Laszlo Ersek, edk2-devel-01, Kinney, Michael D, Yao, Jiewen
Cc: Leif Lindholm, Ard Biesheuvel, Zeng, Star
It is not been implemented yet. Just for our discussion. I should use future tense in the sentence, sorry.
Thanks,
Star
-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
Sent: Tuesday, March 21, 2017 4:38 PM
To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
On 03/21/17 03:27, Zeng, Star wrote:
> Just an idea.
>
> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
Hm, I don't see that:
$ git grep EFI_UNSUPPORTED -- MdeModulePkg/Universal/Acpi/AcpiTableDxe/
[no matches]
Thanks
Laszlo
>
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Zeng, Star
> Sent: Monday, March 20, 2017 5:57 PM
> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01
> <edk2-devel@lists.01.org>; Kinney, Michael D
> <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform
> Has ACPI Protocol, and plug-in library
>
> Oh got it, returning unsuccessfully in constructor of library does not
> work. :(
>
> For (1), I definitely have no any comments. :) For (2), I got no strong reason to support or reject it. We'd better could get comments from Mike and Jiewen.
>
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Monday, March 20, 2017 5:18 PM
> To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01
> <edk2-devel@lists.01.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel
> <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform
> Has ACPI Protocol, and plug-in library
>
> On 03/20/17 03:23, Zeng, Star wrote:
>> 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?
>
> If a library constructor fails, then the client module does not see an explicit error (or automatic unloading); instead, an assertion failure is triggered in auto-generated code.
>
> For example, in the
> "Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
> file, with this series applied, we find:
>
>> VOID
>> EFIAPI
>> ProcessLibraryConstructorList (
>> IN EFI_HANDLE ImageHandle,
>> IN EFI_SYSTEM_TABLE *SystemTable
>> )
>> {
>> EFI_STATUS Status;
>>
>> Status = HobLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = FdtPL011SerialPortLibInitialize ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = BaseDebugLibSerialPortConstructor ();
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = UefiLibConstructor (ImageHandle, SystemTable);
>> ASSERT_EFI_ERROR (Status);
>>
>> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
>> ASSERT_EFI_ERROR (Status);
>>
>> }
>
> What we could do instead would be a new library class, with an explicit initialization function. However, for that to work, AcpiTableDxe would have to be extended with a new library class dependency and a call to the init function. Additionally, out-of-tree platform DSC files would have to resolve this library class to the default instance.
>
> Introducing a boolean dynamic PCD for the same would be much simpler then; the DEC default would cover out-of-tree platform DSCs without any change in behavior.
>
> In summary, there are two alternatives in my opinion:
>
> (1) If we prefer not to modify MdeModulePkg: stick with this series. The only update I'd see justified would be to move gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif requested.
>
> (2) If we are willing to modify MdeModulePkg for this problem: introduce a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe exit early if the PCD is FALSE.
>
> Thanks,
> Laszlo
>
>>
>> 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|0x00000
>> 0
>> 01
>>
>> 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
>>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-21 8:41 ` Zeng, Star
@ 2017-03-21 9:05 ` Laszlo Ersek
0 siblings, 0 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-21 9:05 UTC (permalink / raw)
To: Zeng, Star, edk2-devel-01, Kinney, Michael D, Yao, Jiewen
Cc: Leif Lindholm, Ard Biesheuvel
On 03/21/17 09:41, Zeng, Star wrote:
> It is not been implemented yet. Just for our discussion. I should use future tense in the sentence, sorry.
Ah, I see. Yeah, it makes sense.
(Although it still wouldn't allow us to avoid a NULL class library
plug-in for AcpiTableDxe, for setting the PCD just in time -- the
information source for the PCD is generally available to us only within
the DXE phase, not in PEI.)
Thanks
Laszlo
> Thanks,
> Star
> -----Original Message-----
> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Laszlo Ersek
> Sent: Tuesday, March 21, 2017 4:38 PM
> To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01 <edk2-devel@lists.01.org>; Kinney, Michael D <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
>
> On 03/21/17 03:27, Zeng, Star wrote:
>> Just an idea.
>>
>> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions.
>> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint.
>
> Hm, I don't see that:
>
> $ git grep EFI_UNSUPPORTED -- MdeModulePkg/Universal/Acpi/AcpiTableDxe/
> [no matches]
>
> Thanks
> Laszlo
>
>>
>>
>> Thanks,
>> Star
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>> Zeng, Star
>> Sent: Monday, March 20, 2017 5:57 PM
>> To: Laszlo Ersek <lersek@redhat.com>; edk2-devel-01
>> <edk2-devel@lists.01.org>; Kinney, Michael D
>> <michael.d.kinney@intel.com>; Yao, Jiewen <jiewen.yao@intel.com>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel
>> <ard.biesheuvel@linaro.org>
>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform
>> Has ACPI Protocol, and plug-in library
>>
>> Oh got it, returning unsuccessfully in constructor of library does not
>> work. :(
>>
>> For (1), I definitely have no any comments. :) For (2), I got no strong reason to support or reject it. We'd better could get comments from Mike and Jiewen.
>>
>> Thanks,
>> Star
>> -----Original Message-----
>> From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of
>> Laszlo Ersek
>> Sent: Monday, March 20, 2017 5:18 PM
>> To: Zeng, Star <star.zeng@intel.com>; edk2-devel-01
>> <edk2-devel@lists.01.org>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>; Ard Biesheuvel
>> <ard.biesheuvel@linaro.org>
>> Subject: Re: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform
>> Has ACPI Protocol, and plug-in library
>>
>> On 03/20/17 03:23, Zeng, Star wrote:
>>> 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?
>>
>> If a library constructor fails, then the client module does not see an explicit error (or automatic unloading); instead, an assertion failure is triggered in auto-generated code.
>>
>> For example, in the
>> "Build/ArmVirtQemu-AARCH64/DEBUG_GCC5/AARCH64/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe/DEBUG/AutoGen.c"
>> file, with this series applied, we find:
>>
>>> VOID
>>> EFIAPI
>>> ProcessLibraryConstructorList (
>>> IN EFI_HANDLE ImageHandle,
>>> IN EFI_SYSTEM_TABLE *SystemTable
>>> )
>>> {
>>> EFI_STATUS Status;
>>>
>>> Status = HobLibConstructor (ImageHandle, SystemTable);
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> Status = FdtPL011SerialPortLibInitialize ();
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> Status = BaseDebugLibSerialPortConstructor ();
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> Status = UefiBootServicesTableLibConstructor (ImageHandle, SystemTable);
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> Status = UefiRuntimeServicesTableLibConstructor (ImageHandle, SystemTable);
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> Status = UefiLibConstructor (ImageHandle, SystemTable);
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> Status = PlatformHasAcpiInitialize (); <--------------- constructor of PlatformHasAcpiLib plug-in lib
>>> ASSERT_EFI_ERROR (Status);
>>>
>>> }
>>
>> What we could do instead would be a new library class, with an explicit initialization function. However, for that to work, AcpiTableDxe would have to be extended with a new library class dependency and a call to the init function. Additionally, out-of-tree platform DSC files would have to resolve this library class to the default instance.
>>
>> Introducing a boolean dynamic PCD for the same would be much simpler then; the DEC default would cover out-of-tree platform DSCs without any change in behavior.
>>
>> In summary, there are two alternatives in my opinion:
>>
>> (1) If we prefer not to modify MdeModulePkg: stick with this series. The only update I'd see justified would be to move gEdkiiPlatformHasDeviceTreeProtocolGuid to EmbeddedPkg as Leif requested.
>>
>> (2) If we are willing to modify MdeModulePkg for this problem: introduce a new dynamic PCD such as "PcdAcpiTableEnable", and make AcpiTableDxe exit early if the PCD is FALSE.
>>
>> Thanks,
>> Laszlo
>>
>>>
>>> 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|0x00000
>>> 0
>>> 01
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
2017-03-17 20:47 ` [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library Laszlo Ersek
2017-03-18 15:00 ` Leif Lindholm
2017-03-20 2:23 ` Zeng, Star
@ 2017-03-22 16:45 ` Laszlo Ersek
2 siblings, 0 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-22 16:45 UTC (permalink / raw)
To: Michael Kinney
Cc: edk2-devel-01, Leif Lindholm, Ard Biesheuvel, Star Zeng,
Feng Tian
Mike,
considering time zones and to expedite progress on this series, can you
please offer an opinion whether you would be okay with this one patch
(see full context below) if I posted it for MdeModulePkg, rather than
for ArmPkg?
MdeModulePkg was suggested by Leif.
Thanks!
Laszlo
On 03/17/17 21:47, Laszlo Ersek wrote:
> 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;
> +}
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 06/12] ArmPkg: introduce EDKII Platform Has Device Tree Protocol
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (4 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-18 15:06 ` Leif Lindholm
2017-03-17 20:47 ` [PATCH v2 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe Laszlo Ersek
` (5 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
The presence of this protocol in the DXE protocol database implies that
the platform provides the operating system with a Device Tree-based
hardware description. This is not necessarily mutually exclusive with an
ACPI-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 the same or another platform
driver that owns the Device Tree description of the hardware, and is
responsible for installing it as a system configuration table. Said
FDT-owner driver can wait for the protocol via DEPEX or protocol notify.
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.)
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 | 2 ++
ArmPkg/Include/Protocol/PlatformHasDeviceTree.h | 33 ++++++++++++++++++++
2 files changed, 35 insertions(+)
diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
index 0e49360a386a..1e5cee8d7393 100644
--- a/ArmPkg/ArmPkg.dec
+++ b/ArmPkg/ArmPkg.dec
@@ -55,6 +55,8 @@ [Ppis]
[Protocols]
## Include/Protocol/PlatformHasAcpi.h
gEdkiiPlatformHasAcpiProtocolGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
+ ## Include/Protocol/PlatformHasDeviceTree.h
+ gEdkiiPlatformHasDeviceTreeProtocolGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
[PcdsFeatureFlag.common]
gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x00000001
diff --git a/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h b/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h
new file mode 100644
index 000000000000..a1e588c547e6
--- /dev/null
+++ b/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h
@@ -0,0 +1,33 @@
+/** @file
+ EDKII Platform Has Device Tree Protocol
+
+ The presence of this protocol in the DXE protocol database implies that the
+ platform provides the operating system with a Device Tree-based hardware
+ description. Note that this is not necessarily mutually exclusive with an
+ ACPI-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_DEVICE_TREE_PROTOCOL_H__
+#define __EDKII_PLATFORM_HAS_DEVICE_TREE_PROTOCOL_H__
+
+#define EDKII_PLATFORM_HAS_DEVICE_TREE_PROTOCOL_GUID \
+ { \
+ 0x7ebb920d, 0x1aaf, 0x46d9, \
+ { 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } \
+ }
+
+extern EFI_GUID gEdkiiPlatformHasDeviceTreeProtocolGuid;
+
+#endif
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 06/12] ArmPkg: introduce EDKII Platform Has Device Tree Protocol
2017-03-17 20:47 ` [PATCH v2 06/12] ArmPkg: introduce EDKII Platform Has Device Tree Protocol Laszlo Ersek
@ 2017-03-18 15:06 ` Leif Lindholm
2017-03-20 9:03 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Leif Lindholm @ 2017-03-18 15:06 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Ard Biesheuvel
On Fri, Mar 17, 2017 at 09:47:25PM +0100, Laszlo Ersek wrote:
> The presence of this protocol in the DXE protocol database implies that
> the platform provides the operating system with a Device Tree-based
> hardware description. This is not necessarily mutually exclusive with an
> ACPI-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 the same or another platform
> driver that owns the Device Tree description of the hardware, and is
> responsible for installing it as a system configuration table. Said
> FDT-owner driver can wait for the protocol via DEPEX or protocol notify.
>
> 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.)
Same comment as previous patch, with the exception that if this isn't
a good fit for MdeModulePkg, I'd rather take it in EmbeddedPkg than
ArmPkg.
Regards,
Leif
> 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 | 2 ++
> ArmPkg/Include/Protocol/PlatformHasDeviceTree.h | 33 ++++++++++++++++++++
> 2 files changed, 35 insertions(+)
>
> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
> index 0e49360a386a..1e5cee8d7393 100644
> --- a/ArmPkg/ArmPkg.dec
> +++ b/ArmPkg/ArmPkg.dec
> @@ -55,6 +55,8 @@ [Ppis]
> [Protocols]
> ## Include/Protocol/PlatformHasAcpi.h
> gEdkiiPlatformHasAcpiProtocolGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
> + ## Include/Protocol/PlatformHasDeviceTree.h
> + gEdkiiPlatformHasDeviceTreeProtocolGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>
> [PcdsFeatureFlag.common]
> gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x00000001
> diff --git a/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h b/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h
> new file mode 100644
> index 000000000000..a1e588c547e6
> --- /dev/null
> +++ b/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h
> @@ -0,0 +1,33 @@
> +/** @file
> + EDKII Platform Has Device Tree Protocol
> +
> + The presence of this protocol in the DXE protocol database implies that the
> + platform provides the operating system with a Device Tree-based hardware
> + description. Note that this is not necessarily mutually exclusive with an
> + ACPI-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_DEVICE_TREE_PROTOCOL_H__
> +#define __EDKII_PLATFORM_HAS_DEVICE_TREE_PROTOCOL_H__
> +
> +#define EDKII_PLATFORM_HAS_DEVICE_TREE_PROTOCOL_GUID \
> + { \
> + 0x7ebb920d, 0x1aaf, 0x46d9, \
> + { 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } \
> + }
> +
> +extern EFI_GUID gEdkiiPlatformHasDeviceTreeProtocolGuid;
> +
> +#endif
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 06/12] ArmPkg: introduce EDKII Platform Has Device Tree Protocol
2017-03-18 15:06 ` Leif Lindholm
@ 2017-03-20 9:03 ` Laszlo Ersek
0 siblings, 0 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-20 9:03 UTC (permalink / raw)
To: Leif Lindholm; +Cc: edk2-devel-01, Ard Biesheuvel
On 03/18/17 16:06, Leif Lindholm wrote:
> On Fri, Mar 17, 2017 at 09:47:25PM +0100, Laszlo Ersek wrote:
>> The presence of this protocol in the DXE protocol database implies that
>> the platform provides the operating system with a Device Tree-based
>> hardware description. This is not necessarily mutually exclusive with an
>> ACPI-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 the same or another platform
>> driver that owns the Device Tree description of the hardware, and is
>> responsible for installing it as a system configuration table. Said
>> FDT-owner driver can wait for the protocol via DEPEX or protocol notify.
>>
>> 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.)
>
> Same comment as previous patch, with the exception that if this isn't
> a good fit for MdeModulePkg, I'd rather take it in EmbeddedPkg than
> ArmPkg.
Sure, if we're sticking with this series, I can move the protocol
definition to EmbeddedPkg.
Thanks
Laszlo
>
> Regards,
>
> Leif
>
>> 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 | 2 ++
>> ArmPkg/Include/Protocol/PlatformHasDeviceTree.h | 33 ++++++++++++++++++++
>> 2 files changed, 35 insertions(+)
>>
>> diff --git a/ArmPkg/ArmPkg.dec b/ArmPkg/ArmPkg.dec
>> index 0e49360a386a..1e5cee8d7393 100644
>> --- a/ArmPkg/ArmPkg.dec
>> +++ b/ArmPkg/ArmPkg.dec
>> @@ -55,6 +55,8 @@ [Ppis]
>> [Protocols]
>> ## Include/Protocol/PlatformHasAcpi.h
>> gEdkiiPlatformHasAcpiProtocolGuid = { 0xf0966b41, 0xc23f, 0x41b9, { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } }
>> + ## Include/Protocol/PlatformHasDeviceTree.h
>> + gEdkiiPlatformHasDeviceTreeProtocolGuid = { 0x7ebb920d, 0x1aaf, 0x46d9, { 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } }
>>
>> [PcdsFeatureFlag.common]
>> gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x00000001
>> diff --git a/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h b/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h
>> new file mode 100644
>> index 000000000000..a1e588c547e6
>> --- /dev/null
>> +++ b/ArmPkg/Include/Protocol/PlatformHasDeviceTree.h
>> @@ -0,0 +1,33 @@
>> +/** @file
>> + EDKII Platform Has Device Tree Protocol
>> +
>> + The presence of this protocol in the DXE protocol database implies that the
>> + platform provides the operating system with a Device Tree-based hardware
>> + description. Note that this is not necessarily mutually exclusive with an
>> + ACPI-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_DEVICE_TREE_PROTOCOL_H__
>> +#define __EDKII_PLATFORM_HAS_DEVICE_TREE_PROTOCOL_H__
>> +
>> +#define EDKII_PLATFORM_HAS_DEVICE_TREE_PROTOCOL_GUID \
>> + { \
>> + 0x7ebb920d, 0x1aaf, 0x46d9, \
>> + { 0xb2, 0xaf, 0x54, 0x1e, 0x1d, 0xce, 0x14, 0x8b } \
>> + }
>> +
>> +extern EFI_GUID gEdkiiPlatformHasDeviceTreeProtocolGuid;
>> +
>> +#endif
>> --
>> 2.9.3
>>
>>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (5 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 06/12] ArmPkg: introduce EDKII Platform Has Device Tree Protocol Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:14 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe Laszlo Ersek
` (4 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.
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>
---
ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 47 ++++++++++++
ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 77 ++++++++++++++++++++
2 files changed, 124 insertions(+)
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
new file mode 100644
index 000000000000..7724cf215dda
--- /dev/null
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -0,0 +1,47 @@
+## @file
+# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+# hardware description to the operating system.
+#
+# 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 = PlatformHasAcpiDtDxe
+ FILE_GUID = 9d1dd27f-6d7f-427b-aec4-b62f6279c2f1
+ MODULE_TYPE = DXE_DRIVER
+ VERSION_STRING = 1.0
+ ENTRY_POINT = PlatformHasAcpiDt
+
+[Sources]
+ PlatformHasAcpiDtDxe.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ ArmVirtPkg/ArmVirtPkg.dec
+ MdePkg/MdePkg.dec
+
+[LibraryClasses]
+ BaseLib
+ DebugLib
+ PcdLib
+ UefiBootServicesTableLib
+ UefiDriverEntryPoint
+
+[Protocols]
+ gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
+ gEdkiiPlatformHasDeviceTreeProtocolGuid ## SOMETIMES_PRODUCES
+
+[FeaturePcd]
+ gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
+
+[Depex]
+ TRUE
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
new file mode 100644
index 000000000000..8681f813a6b5
--- /dev/null
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
@@ -0,0 +1,77 @@
+/** @file
+ Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+ hardware description to the operating system.
+
+ 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 <Library/BaseLib.h>
+#include <Library/DebugLib.h>
+#include <Library/PcdLib.h>
+#include <Library/UefiBootServicesTableLib.h>
+#include <Protocol/PlatformHasAcpi.h>
+#include <Protocol/PlatformHasDeviceTree.h>
+
+EFI_STATUS
+EFIAPI
+PlatformHasAcpiDt (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ Status = EFI_SUCCESS;
+
+ //
+ // If we fail to install any of the necessary protocols below, the OS will be
+ // unbootable anyway (due to lacking hardware description), so tolerate no
+ // errors here.
+ //
+ // Always make ACPI available on 64-bit systems.
+ //
+ if (MAX_UINTN == MAX_UINT64) {
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gEdkiiPlatformHasAcpiProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+ if (EFI_ERROR (Status)) {
+ goto Failed;
+ }
+ }
+
+ //
+ // Expose the Device Tree unless PcdPureAcpiBoot is set.
+ //
+ if (!FeaturePcdGet (PcdPureAcpiBoot)) {
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gEdkiiPlatformHasDeviceTreeProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+ if (EFI_ERROR (Status)) {
+ goto Failed;
+ }
+ }
+
+ return Status;
+
+Failed:
+ ASSERT_EFI_ERROR (Status);
+ CpuDeadLoop ();
+ //
+ // Keep compilers happy.
+ //
+ return Status;
+}
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe
2017-03-17 20:47 ` [PATCH v2 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe Laszlo Ersek
@ 2017-03-22 14:14 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:14 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> This driver produces the EDKII Platform Has ACPI and Platform Has Device
> Tree protocols, exactly matching the current ACPI / DT exposure on QEMU,
> according to ARM vs. AARCH64, and (in the latter case) to PcdPureAcpiBoot.
>
> 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>
> ---
> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 47 ++++++++++++
> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 77 ++++++++++++++++++++
> 2 files changed, 124 insertions(+)
>
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> new file mode 100644
> index 000000000000..7724cf215dda
> --- /dev/null
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> @@ -0,0 +1,47 @@
> +## @file
> +# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
> +# hardware description to the operating system.
> +#
> +# 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 = PlatformHasAcpiDtDxe
> + FILE_GUID = 9d1dd27f-6d7f-427b-aec4-b62f6279c2f1
> + MODULE_TYPE = DXE_DRIVER
> + VERSION_STRING = 1.0
> + ENTRY_POINT = PlatformHasAcpiDt
> +
> +[Sources]
> + PlatformHasAcpiDtDxe.c
> +
> +[Packages]
> + ArmPkg/ArmPkg.dec
> + ArmVirtPkg/ArmVirtPkg.dec
> + MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> + BaseLib
> + DebugLib
> + PcdLib
> + UefiBootServicesTableLib
> + UefiDriverEntryPoint
> +
> +[Protocols]
> + gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
> + gEdkiiPlatformHasDeviceTreeProtocolGuid ## SOMETIMES_PRODUCES
> +
> +[FeaturePcd]
> + gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
> +
> +[Depex]
> + TRUE
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> new file mode 100644
> index 000000000000..8681f813a6b5
> --- /dev/null
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> @@ -0,0 +1,77 @@
> +/** @file
> + Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
> + hardware description to the operating system.
> +
> + 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 <Library/BaseLib.h>
> +#include <Library/DebugLib.h>
> +#include <Library/PcdLib.h>
> +#include <Library/UefiBootServicesTableLib.h>
> +#include <Protocol/PlatformHasAcpi.h>
> +#include <Protocol/PlatformHasDeviceTree.h>
> +
> +EFI_STATUS
> +EFIAPI
> +PlatformHasAcpiDt (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + EFI_STATUS Status;
> +
> + Status = EFI_SUCCESS;
> +
> + //
> + // If we fail to install any of the necessary protocols below, the OS will be
> + // unbootable anyway (due to lacking hardware description), so tolerate no
> + // errors here.
> + //
> + // Always make ACPI available on 64-bit systems.
> + //
> + if (MAX_UINTN == MAX_UINT64) {
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gEdkiiPlatformHasAcpiProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + goto Failed;
> + }
> + }
> +
> + //
> + // Expose the Device Tree unless PcdPureAcpiBoot is set.
> + //
> + if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + goto Failed;
> + }
> + }
> +
> + return Status;
> +
> +Failed:
> + ASSERT_EFI_ERROR (Status);
> + CpuDeadLoop ();
> + //
> + // Keep compilers happy.
> + //
> + return Status;
> +}
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (6 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:15 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically Laszlo Ersek
` (3 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
This driver produces the EDKII Platform Has ACPI and Platform Has Device
Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
according to ARM vs. AARCH64. At this point it differs from the QEMU
driver PlatformHasAcpiDtDxe in that this one always installs the DT.
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>
---
ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 43 ++++++++++++
ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c | 72 ++++++++++++++++++++
2 files changed, 115 insertions(+)
diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
new file mode 100644
index 000000000000..e25207832c39
--- /dev/null
+++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
@@ -0,0 +1,43 @@
+## @file
+# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+# hardware description to the operating system.
+#
+# 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 = XenPlatformHasAcpiDtDxe
+ FILE_GUID = 6914c46f-d46e-48dc-9998-8a5f64f02553
+ MODULE_TYPE = DXE_DRIVER
+ VERSION_STRING = 1.0
+ ENTRY_POINT = XenPlatformHasAcpiDt
+
+[Sources]
+ XenPlatformHasAcpiDtDxe.c
+
+[Packages]
+ ArmPkg/ArmPkg.dec
+ ArmVirtPkg/ArmVirtPkg.dec
+ MdePkg/MdePkg.dec
+
+[LibraryClasses]
+ BaseLib
+ DebugLib
+ UefiBootServicesTableLib
+ UefiDriverEntryPoint
+
+[Protocols]
+ gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
+ gEdkiiPlatformHasDeviceTreeProtocolGuid ## PRODUCES
+
+[Depex]
+ TRUE
diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
new file mode 100644
index 000000000000..0c3b1f7c7893
--- /dev/null
+++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
@@ -0,0 +1,72 @@
+/** @file
+ Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
+ hardware description to the operating system.
+
+ 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 <Library/BaseLib.h>
+#include <Library/DebugLib.h>
+#include <Library/UefiBootServicesTableLib.h>
+#include <Protocol/PlatformHasAcpi.h>
+#include <Protocol/PlatformHasDeviceTree.h>
+
+EFI_STATUS
+EFIAPI
+XenPlatformHasAcpiDt (
+ IN EFI_HANDLE ImageHandle,
+ IN EFI_SYSTEM_TABLE *SystemTable
+ )
+{
+ EFI_STATUS Status;
+
+ //
+ // If we fail to install any of the necessary protocols below, the OS will be
+ // unbootable anyway (due to lacking hardware description), so tolerate no
+ // errors here.
+ //
+ // Always make ACPI available on 64-bit systems.
+ //
+ if (MAX_UINTN == MAX_UINT64) {
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gEdkiiPlatformHasAcpiProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+ if (EFI_ERROR (Status)) {
+ goto Failed;
+ }
+ }
+
+ //
+ // Expose the Device Tree unconditionally.
+ //
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gEdkiiPlatformHasDeviceTreeProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+ if (EFI_ERROR (Status)) {
+ goto Failed;
+ }
+
+ return Status;
+
+Failed:
+ ASSERT_EFI_ERROR (Status);
+ CpuDeadLoop ();
+ //
+ // Keep compilers happy.
+ //
+ return Status;
+}
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe
2017-03-17 20:47 ` [PATCH v2 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe Laszlo Ersek
@ 2017-03-22 14:15 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:15 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> This driver produces the EDKII Platform Has ACPI and Platform Has Device
> Tree protocols, exactly matching the current ACPI / DT exposure on Xen,
> according to ARM vs. AARCH64. At this point it differs from the QEMU
> driver PlatformHasAcpiDtDxe in that this one always installs the DT.
>
> 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>
> ---
> ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf | 43 ++++++++++++
> ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c | 72 ++++++++++++++++++++
> 2 files changed, 115 insertions(+)
>
> diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> new file mode 100644
> index 000000000000..e25207832c39
> --- /dev/null
> +++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> @@ -0,0 +1,43 @@
> +## @file
> +# Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
> +# hardware description to the operating system.
> +#
> +# 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 = XenPlatformHasAcpiDtDxe
> + FILE_GUID = 6914c46f-d46e-48dc-9998-8a5f64f02553
> + MODULE_TYPE = DXE_DRIVER
> + VERSION_STRING = 1.0
> + ENTRY_POINT = XenPlatformHasAcpiDt
> +
> +[Sources]
> + XenPlatformHasAcpiDtDxe.c
> +
> +[Packages]
> + ArmPkg/ArmPkg.dec
> + ArmVirtPkg/ArmVirtPkg.dec
> + MdePkg/MdePkg.dec
> +
> +[LibraryClasses]
> + BaseLib
> + DebugLib
> + UefiBootServicesTableLib
> + UefiDriverEntryPoint
> +
> +[Protocols]
> + gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
> + gEdkiiPlatformHasDeviceTreeProtocolGuid ## PRODUCES
> +
> +[Depex]
> + TRUE
> diff --git a/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
> new file mode 100644
> index 000000000000..0c3b1f7c7893
> --- /dev/null
> +++ b/ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.c
> @@ -0,0 +1,72 @@
> +/** @file
> + Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
> + hardware description to the operating system.
> +
> + 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 <Library/BaseLib.h>
> +#include <Library/DebugLib.h>
> +#include <Library/UefiBootServicesTableLib.h>
> +#include <Protocol/PlatformHasAcpi.h>
> +#include <Protocol/PlatformHasDeviceTree.h>
> +
> +EFI_STATUS
> +EFIAPI
> +XenPlatformHasAcpiDt (
> + IN EFI_HANDLE ImageHandle,
> + IN EFI_SYSTEM_TABLE *SystemTable
> + )
> +{
> + EFI_STATUS Status;
> +
> + //
> + // If we fail to install any of the necessary protocols below, the OS will be
> + // unbootable anyway (due to lacking hardware description), so tolerate no
> + // errors here.
> + //
> + // Always make ACPI available on 64-bit systems.
> + //
> + if (MAX_UINTN == MAX_UINT64) {
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gEdkiiPlatformHasAcpiProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + goto Failed;
> + }
> + }
> +
> + //
> + // Expose the Device Tree unconditionally.
> + //
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + goto Failed;
> + }
> +
> + return Status;
> +
> +Failed:
> + ASSERT_EFI_ERROR (Status);
> + CpuDeadLoop ();
> + //
> + // Keep compilers happy.
> + //
> + return Status;
> +}
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (7 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:16 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify Laszlo Ersek
` (2 subsequent siblings)
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
In this patch, AcpiTableDxe, and the dependent (platform-matching) ACPI
table producing DXE drivers are built for 32-bit as well, and the ACPI
protocol / driver chain is enabled dynamically, when appropriate. This is
being done in one larger patch, because ArmVirt.dsc.inc, where
AcpiTableDxe is built, is used by all the platform DSCs.
No change in behavior should be observable after this patch on any
ArmVirtPkg platform.
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>
---
ArmVirtPkg/ArmVirt.dsc.inc | 11 +++++++++--
ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 +-
ArmVirtPkg/ArmVirtXen.dsc | 3 +--
ArmVirtPkg/ArmVirtXen.fdf | 3 ++-
ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 3 ++-
6 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
index f61fd0680612..180b72d1478a 100644
--- a/ArmVirtPkg/ArmVirt.dsc.inc
+++ b/ArmVirtPkg/ArmVirt.dsc.inc
@@ -439,9 +439,16 @@ [Components.common]
gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
}
-[Components.AARCH64]
#
# ACPI Support
#
- MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
+ MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
+ <LibraryClasses>
+ NULL|ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
+ }
+
+[Components.AARCH64]
+ #
+ # EBC support
+ #
MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index d6b3c0db5530..328c2b79994b 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -379,10 +379,10 @@ [Components.common]
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
-[Components.AARCH64]
#
# ACPI Support
#
+ ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
<LibraryClasses>
diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
index 71f16ed192de..bcd2711d4142 100644
--- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
+++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
@@ -368,10 +368,10 @@ [Components.common]
MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
-[Components.AARCH64]
#
# ACPI Support
#
+ ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
<LibraryClasses>
diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
index 3422d1e5d996..90c5ebc6cb96 100644
--- a/ArmVirtPkg/ArmVirtXen.dsc
+++ b/ArmVirtPkg/ArmVirtXen.dsc
@@ -221,6 +221,5 @@ [Components.common]
#
# ACPI support
#
-!if $(ARCH) == AARCH64
+ ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
-!endif
diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
index c997251b12b8..8e41ba1fb448 100644
--- a/ArmVirtPkg/ArmVirtXen.fdf
+++ b/ArmVirtPkg/ArmVirtXen.fdf
@@ -183,10 +183,11 @@ [FV.FvMain]
#
# ACPI support
#
-!if $(ARCH) == AARCH64
+ INF ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
+!if $(ARCH) == AARCH64
#
# EBC support
#
diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
index cc5d12aaefea..440ff7e87a52 100644
--- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
+++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
@@ -140,14 +140,15 @@ [FV.FvMain]
INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
-!if $(ARCH) == AARCH64
#
# ACPI Support
#
+ INF ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
+!if $(ARCH) == AARCH64
#
# EBC support
#
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically
2017-03-17 20:47 ` [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically Laszlo Ersek
@ 2017-03-22 14:16 ` Ard Biesheuvel
2017-03-22 14:54 ` Laszlo Ersek
0 siblings, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:16 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> In this patch, AcpiTableDxe, and the dependent (platform-matching) ACPI
> table producing DXE drivers are built for 32-bit as well,
Why is this?
> and the ACPI
> protocol / driver chain is enabled dynamically, when appropriate. This is
> being done in one larger patch, because ArmVirt.dsc.inc, where
> AcpiTableDxe is built, is used by all the platform DSCs.
>
> No change in behavior should be observable after this patch on any
> ArmVirtPkg platform.
>
> 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>
> ---
> ArmVirtPkg/ArmVirt.dsc.inc | 11 +++++++++--
> ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
> ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 +-
> ArmVirtPkg/ArmVirtXen.dsc | 3 +--
> ArmVirtPkg/ArmVirtXen.fdf | 3 ++-
> ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 3 ++-
> 6 files changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
> index f61fd0680612..180b72d1478a 100644
> --- a/ArmVirtPkg/ArmVirt.dsc.inc
> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
> @@ -439,9 +439,16 @@ [Components.common]
> gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
> }
>
> -[Components.AARCH64]
> #
> # ACPI Support
> #
> - MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> + MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
> + <LibraryClasses>
> + NULL|ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
> + }
> +
> +[Components.AARCH64]
> + #
> + # EBC support
> + #
> MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index d6b3c0db5530..328c2b79994b 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -379,10 +379,10 @@ [Components.common]
> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
> MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>
> -[Components.AARCH64]
> #
> # ACPI Support
> #
> + ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
> <LibraryClasses>
> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> index 71f16ed192de..bcd2711d4142 100644
> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
> @@ -368,10 +368,10 @@ [Components.common]
> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
> MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>
> -[Components.AARCH64]
> #
> # ACPI Support
> #
> + ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
> <LibraryClasses>
> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
> index 3422d1e5d996..90c5ebc6cb96 100644
> --- a/ArmVirtPkg/ArmVirtXen.dsc
> +++ b/ArmVirtPkg/ArmVirtXen.dsc
> @@ -221,6 +221,5 @@ [Components.common]
> #
> # ACPI support
> #
> -!if $(ARCH) == AARCH64
> + ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
> -!endif
> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
> index c997251b12b8..8e41ba1fb448 100644
> --- a/ArmVirtPkg/ArmVirtXen.fdf
> +++ b/ArmVirtPkg/ArmVirtXen.fdf
> @@ -183,10 +183,11 @@ [FV.FvMain]
> #
> # ACPI support
> #
> -!if $(ARCH) == AARCH64
> + INF ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
> INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>
> +!if $(ARCH) == AARCH64
> #
> # EBC support
> #
> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> index cc5d12aaefea..440ff7e87a52 100644
> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
> @@ -140,14 +140,15 @@ [FV.FvMain]
> INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
> INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>
> -!if $(ARCH) == AARCH64
> #
> # ACPI Support
> #
> + INF ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
> INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
> INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
>
> +!if $(ARCH) == AARCH64
> #
> # EBC support
> #
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically
2017-03-22 14:16 ` Ard Biesheuvel
@ 2017-03-22 14:54 ` Laszlo Ersek
2017-03-22 15:05 ` Ard Biesheuvel
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-22 14:54 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: edk2-devel-01, Leif Lindholm
On 03/22/17 15:16, Ard Biesheuvel wrote:
> On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
>> In this patch, AcpiTableDxe, and the dependent (platform-matching) ACPI
>> table producing DXE drivers are built for 32-bit as well,
>
> Why is this?
Purely for uniformity's sake. I wanted to avoid a situation where part
of the restrictions is coded up in the DSC/FDF files, and another part
in the dynamic decision code. I moved all of the thinking into the
dynamic code, and that one will never enable ACPI for 32-bit (dynamically).
If you disagree, I can rework it, but I maintain that it's going to be
more confusing that way.
Thanks,
Laszlo
>
>> and the ACPI
>> protocol / driver chain is enabled dynamically, when appropriate. This is
>> being done in one larger patch, because ArmVirt.dsc.inc, where
>> AcpiTableDxe is built, is used by all the platform DSCs.
>>
>> No change in behavior should be observable after this patch on any
>> ArmVirtPkg platform.
>>
>> 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>
>> ---
>> ArmVirtPkg/ArmVirt.dsc.inc | 11 +++++++++--
>> ArmVirtPkg/ArmVirtQemu.dsc | 2 +-
>> ArmVirtPkg/ArmVirtQemuKernel.dsc | 2 +-
>> ArmVirtPkg/ArmVirtXen.dsc | 3 +--
>> ArmVirtPkg/ArmVirtXen.fdf | 3 ++-
>> ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc | 3 ++-
>> 6 files changed, 16 insertions(+), 8 deletions(-)
>>
>> diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc
>> index f61fd0680612..180b72d1478a 100644
>> --- a/ArmVirtPkg/ArmVirt.dsc.inc
>> +++ b/ArmVirtPkg/ArmVirt.dsc.inc
>> @@ -439,9 +439,16 @@ [Components.common]
>> gEfiMdePkgTokenSpaceGuid.PcdUefiLibMaxPrintBufferSize|8000
>> }
>>
>> -[Components.AARCH64]
>> #
>> # ACPI Support
>> #
>> - MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> + MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf {
>> + <LibraryClasses>
>> + NULL|ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf
>> + }
>> +
>> +[Components.AARCH64]
>> + #
>> + # EBC support
>> + #
>> MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>> index d6b3c0db5530..328c2b79994b 100644
>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>> @@ -379,10 +379,10 @@ [Components.common]
>> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>> MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>>
>> -[Components.AARCH64]
>> #
>> # ACPI Support
>> #
>> + ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>> OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
>> <LibraryClasses>
>> diff --git a/ArmVirtPkg/ArmVirtQemuKernel.dsc b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> index 71f16ed192de..bcd2711d4142 100644
>> --- a/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> +++ b/ArmVirtPkg/ArmVirtQemuKernel.dsc
>> @@ -368,10 +368,10 @@ [Components.common]
>> MdeModulePkg/Bus/Usb/UsbBusDxe/UsbBusDxe.inf
>> MdeModulePkg/Bus/Usb/UsbKbDxe/UsbKbDxe.inf
>>
>> -[Components.AARCH64]
>> #
>> # ACPI Support
>> #
>> + ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>> OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf {
>> <LibraryClasses>
>> diff --git a/ArmVirtPkg/ArmVirtXen.dsc b/ArmVirtPkg/ArmVirtXen.dsc
>> index 3422d1e5d996..90c5ebc6cb96 100644
>> --- a/ArmVirtPkg/ArmVirtXen.dsc
>> +++ b/ArmVirtPkg/ArmVirtXen.dsc
>> @@ -221,6 +221,5 @@ [Components.common]
>> #
>> # ACPI support
>> #
>> -!if $(ARCH) == AARCH64
>> + ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>> -!endif
>> diff --git a/ArmVirtPkg/ArmVirtXen.fdf b/ArmVirtPkg/ArmVirtXen.fdf
>> index c997251b12b8..8e41ba1fb448 100644
>> --- a/ArmVirtPkg/ArmVirtXen.fdf
>> +++ b/ArmVirtPkg/ArmVirtXen.fdf
>> @@ -183,10 +183,11 @@ [FV.FvMain]
>> #
>> # ACPI support
>> #
>> -!if $(ARCH) == AARCH64
>> + INF ArmVirtPkg/XenPlatformHasAcpiDtDxe/XenPlatformHasAcpiDtDxe.inf
>> INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> INF ArmVirtPkg/XenAcpiPlatformDxe/XenAcpiPlatformDxe.inf
>>
>> +!if $(ARCH) == AARCH64
>> #
>> # EBC support
>> #
>> diff --git a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
>> index cc5d12aaefea..440ff7e87a52 100644
>> --- a/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
>> +++ b/ArmVirtPkg/ArmVirtQemuFvMain.fdf.inc
>> @@ -140,14 +140,15 @@ [FV.FvMain]
>> INF MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf
>> INF OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf
>>
>> -!if $(ARCH) == AARCH64
>> #
>> # ACPI Support
>> #
>> + INF ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> INF MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableDxe.inf
>> INF MdeModulePkg/Universal/Acpi/BootGraphicsResourceTableDxe/BootGraphicsResourceTableDxe.inf
>> INF OvmfPkg/AcpiPlatformDxe/QemuFwCfgAcpiPlatformDxe.inf
>>
>> +!if $(ARCH) == AARCH64
>> #
>> # EBC support
>> #
>> --
>> 2.9.3
>>
>>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically
2017-03-22 14:54 ` Laszlo Ersek
@ 2017-03-22 15:05 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 15:05 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 22 March 2017 at 14:54, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/22/17 15:16, Ard Biesheuvel wrote:
>> On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
>>> In this patch, AcpiTableDxe, and the dependent (platform-matching) ACPI
>>> table producing DXE drivers are built for 32-bit as well,
>>
>> Why is this?
>
> Purely for uniformity's sake. I wanted to avoid a situation where part
> of the restrictions is coded up in the DSC/FDF files, and another part
> in the dynamic decision code. I moved all of the thinking into the
> dynamic code, and that one will never enable ACPI for 32-bit (dynamically).
>
If it never enables ACPI for 32-bit, I really don't see the point of
adding those drivers to the build.
> If you disagree, I can rework it, but I maintain that it's going to be
> more confusing that way.
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (8 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:18 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI Laszlo Ersek
2017-03-17 20:47 ` [PATCH v2 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot Laszlo Ersek
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
notification callback. Move the sysconfig table installation from the
entry point function to the callback.
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>
---
ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 5 +-
ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 105 ++++++++++++++++++--
2 files changed, 98 insertions(+), 12 deletions(-)
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
index 3a0cd37040eb..99dcbde59497 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
@@ -25,6 +25,7 @@ [Sources]
FdtClientDxe.c
[Packages]
+ ArmPkg/ArmPkg.dec
ArmVirtPkg/ArmVirtPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
MdeModulePkg/MdeModulePkg.dec
@@ -39,14 +40,12 @@ [LibraryClasses]
UefiDriverEntryPoint
[Protocols]
+ gEdkiiPlatformHasDeviceTreeProtocolGuid ## CONSUMES
gFdtClientProtocolGuid ## PRODUCES
[Guids]
gFdtHobGuid
gFdtTableGuid
-[FeaturePcd]
- gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
-
[Depex]
TRUE
diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
index 547a29fce62c..9dda0d005d61 100644
--- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
+++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
@@ -24,6 +24,7 @@
#include <Guid/FdtHob.h>
#include <Protocol/FdtClient.h>
+#include <Protocol/PlatformHasDeviceTree.h>
STATIC VOID *mDeviceTreeBase;
@@ -306,6 +307,40 @@ STATIC FDT_CLIENT_PROTOCOL mFdtClientProtocol = {
GetOrInsertChosenNode,
};
+STATIC
+VOID
+EFIAPI
+OnPlatformHasDeviceTree (
+ IN EFI_EVENT Event,
+ IN VOID *Context
+ )
+{
+ EFI_STATUS Status;
+ VOID *Interface;
+ VOID *DeviceTreeBase;
+
+ Status = gBS->LocateProtocol (
+ &gEdkiiPlatformHasDeviceTreeProtocolGuid,
+ NULL, // Registration
+ &Interface
+ );
+ if (EFI_ERROR (Status)) {
+ return;
+ }
+
+ DeviceTreeBase = Context;
+ DEBUG ((
+ DEBUG_INFO,
+ "%a: exposing DTB @ 0x%p to OS\n",
+ __FUNCTION__,
+ DeviceTreeBase
+ ));
+ Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
+ ASSERT_EFI_ERROR (Status);
+
+ gBS->CloseEvent (Event);
+}
+
EFI_STATUS
EFIAPI
InitializeFdtClientDxe (
@@ -316,6 +351,8 @@ InitializeFdtClientDxe (
VOID *Hob;
VOID *DeviceTreeBase;
EFI_STATUS Status;
+ EFI_EVENT PlatformHasDeviceTreeEvent;
+ VOID *Registration;
Hob = GetFirstGuidHob (&gFdtHobGuid);
if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) {
@@ -333,15 +370,65 @@ InitializeFdtClientDxe (
DEBUG ((EFI_D_INFO, "%a: DTB @ 0x%p\n", __FUNCTION__, mDeviceTreeBase));
- if (!FeaturePcdGet (PcdPureAcpiBoot)) {
- //
- // Only install the FDT as a configuration table if we want to leave it up
- // to the OS to decide whether it prefers ACPI over DT.
- //
- Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
- ASSERT_EFI_ERROR (Status);
+ //
+ // Register a protocol notify for the EDKII Platform Has Device Tree
+ // Protocol.
+ //
+ Status = gBS->CreateEvent (
+ EVT_NOTIFY_SIGNAL,
+ TPL_CALLBACK,
+ OnPlatformHasDeviceTree,
+ DeviceTreeBase, // Context
+ &PlatformHasDeviceTreeEvent
+ );
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "%a: CreateEvent(): %r\n", __FUNCTION__, Status));
+ return Status;
}
- return gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
- EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
+ Status = gBS->RegisterProtocolNotify (
+ &gEdkiiPlatformHasDeviceTreeProtocolGuid,
+ PlatformHasDeviceTreeEvent,
+ &Registration
+ );
+ if (EFI_ERROR (Status)) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%a: RegisterProtocolNotify(): %r\n",
+ __FUNCTION__,
+ Status
+ ));
+ goto CloseEvent;
+ }
+
+ //
+ // Kick the event; the protocol could be available already.
+ //
+ Status = gBS->SignalEvent (PlatformHasDeviceTreeEvent);
+ if (EFI_ERROR (Status)) {
+ DEBUG ((DEBUG_ERROR, "%a: SignalEvent(): %r\n", __FUNCTION__, Status));
+ goto CloseEvent;
+ }
+
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gFdtClientProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ &mFdtClientProtocol
+ );
+ if (EFI_ERROR (Status)) {
+ DEBUG ((
+ DEBUG_ERROR,
+ "%a: InstallProtocolInterface(): %r\n",
+ __FUNCTION__,
+ Status
+ ));
+ goto CloseEvent;
+ }
+
+ return Status;
+
+CloseEvent:
+ gBS->CloseEvent (PlatformHasDeviceTreeEvent);
+ return Status;
}
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify
2017-03-17 20:47 ` [PATCH v2 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify Laszlo Ersek
@ 2017-03-22 14:18 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:18 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> Replace the dependency on PcdPureAcpiBoot with a Platform Has Device Tree
> notification callback. Move the sysconfig table installation from the
> entry point function to the callback.
>
> 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>
> ---
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 5 +-
> ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 105 ++++++++++++++++++--
> 2 files changed, 98 insertions(+), 12 deletions(-)
>
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> index 3a0cd37040eb..99dcbde59497 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
> @@ -25,6 +25,7 @@ [Sources]
> FdtClientDxe.c
>
> [Packages]
> + ArmPkg/ArmPkg.dec
> ArmVirtPkg/ArmVirtPkg.dec
> EmbeddedPkg/EmbeddedPkg.dec
> MdeModulePkg/MdeModulePkg.dec
> @@ -39,14 +40,12 @@ [LibraryClasses]
> UefiDriverEntryPoint
>
> [Protocols]
> + gEdkiiPlatformHasDeviceTreeProtocolGuid ## CONSUMES
> gFdtClientProtocolGuid ## PRODUCES
>
> [Guids]
> gFdtHobGuid
> gFdtTableGuid
>
> -[FeaturePcd]
> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
> -
> [Depex]
> TRUE
> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> index 547a29fce62c..9dda0d005d61 100644
> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
> @@ -24,6 +24,7 @@
> #include <Guid/FdtHob.h>
>
> #include <Protocol/FdtClient.h>
> +#include <Protocol/PlatformHasDeviceTree.h>
>
> STATIC VOID *mDeviceTreeBase;
>
> @@ -306,6 +307,40 @@ STATIC FDT_CLIENT_PROTOCOL mFdtClientProtocol = {
> GetOrInsertChosenNode,
> };
>
> +STATIC
> +VOID
> +EFIAPI
> +OnPlatformHasDeviceTree (
> + IN EFI_EVENT Event,
> + IN VOID *Context
> + )
> +{
> + EFI_STATUS Status;
> + VOID *Interface;
> + VOID *DeviceTreeBase;
> +
> + Status = gBS->LocateProtocol (
> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> + NULL, // Registration
> + &Interface
> + );
> + if (EFI_ERROR (Status)) {
> + return;
> + }
> +
> + DeviceTreeBase = Context;
> + DEBUG ((
> + DEBUG_INFO,
> + "%a: exposing DTB @ 0x%p to OS\n",
> + __FUNCTION__,
> + DeviceTreeBase
> + ));
> + Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
> + ASSERT_EFI_ERROR (Status);
> +
> + gBS->CloseEvent (Event);
> +}
> +
> EFI_STATUS
> EFIAPI
> InitializeFdtClientDxe (
> @@ -316,6 +351,8 @@ InitializeFdtClientDxe (
> VOID *Hob;
> VOID *DeviceTreeBase;
> EFI_STATUS Status;
> + EFI_EVENT PlatformHasDeviceTreeEvent;
> + VOID *Registration;
>
> Hob = GetFirstGuidHob (&gFdtHobGuid);
> if (Hob == NULL || GET_GUID_HOB_DATA_SIZE (Hob) != sizeof (UINT64)) {
> @@ -333,15 +370,65 @@ InitializeFdtClientDxe (
>
> DEBUG ((EFI_D_INFO, "%a: DTB @ 0x%p\n", __FUNCTION__, mDeviceTreeBase));
>
> - if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> - //
> - // Only install the FDT as a configuration table if we want to leave it up
> - // to the OS to decide whether it prefers ACPI over DT.
> - //
> - Status = gBS->InstallConfigurationTable (&gFdtTableGuid, DeviceTreeBase);
> - ASSERT_EFI_ERROR (Status);
> + //
> + // Register a protocol notify for the EDKII Platform Has Device Tree
> + // Protocol.
> + //
> + Status = gBS->CreateEvent (
> + EVT_NOTIFY_SIGNAL,
> + TPL_CALLBACK,
> + OnPlatformHasDeviceTree,
> + DeviceTreeBase, // Context
> + &PlatformHasDeviceTreeEvent
> + );
> + if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR, "%a: CreateEvent(): %r\n", __FUNCTION__, Status));
> + return Status;
> }
>
> - return gBS->InstallProtocolInterface (&ImageHandle, &gFdtClientProtocolGuid,
> - EFI_NATIVE_INTERFACE, &mFdtClientProtocol);
> + Status = gBS->RegisterProtocolNotify (
> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> + PlatformHasDeviceTreeEvent,
> + &Registration
> + );
> + if (EFI_ERROR (Status)) {
> + DEBUG ((
> + DEBUG_ERROR,
> + "%a: RegisterProtocolNotify(): %r\n",
> + __FUNCTION__,
> + Status
> + ));
> + goto CloseEvent;
> + }
> +
> + //
> + // Kick the event; the protocol could be available already.
> + //
> + Status = gBS->SignalEvent (PlatformHasDeviceTreeEvent);
> + if (EFI_ERROR (Status)) {
> + DEBUG ((DEBUG_ERROR, "%a: SignalEvent(): %r\n", __FUNCTION__, Status));
> + goto CloseEvent;
> + }
> +
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gFdtClientProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + &mFdtClientProtocol
> + );
> + if (EFI_ERROR (Status)) {
> + DEBUG ((
> + DEBUG_ERROR,
> + "%a: InstallProtocolInterface(): %r\n",
> + __FUNCTION__,
> + Status
> + ));
> + goto CloseEvent;
> + }
> +
> + return Status;
> +
> +CloseEvent:
> + gBS->CloseEvent (PlatformHasDeviceTreeEvent);
> + return Status;
> }
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (9 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-17 21:10 ` Ard Biesheuvel
2017-03-22 14:18 ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot Laszlo Ersek
11 siblings, 2 replies; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
the guest. Showing both is never needed (it is actually detrimental to the
adoption of standards, such as SBSA / SBBR).
* Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
> Found FwCfg @ 0x9020008/0x9020000
> Found FwCfg DMA @ 0x9020010
> InstallProtocolInterface: [EdkiiPlatformHasAcpiProtocol] 0
plus the usual messages. Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
before it lists the ACPI tables one by one.
* With "-no-acpi", the firmware logs:
> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
> PlatformHasAcpiDtDxe | InstallProtocolInterface:
> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTreeProtocol] 0
> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
> FdtClientDxe | 0x13FFBF000 to OS
> ...
> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
> DXE_CORE | loaded!!
> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
> DXE_CORE | not loaded!!
> ...
> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
> RamDiskDxe | Table Protocol, unable to publish RAM disks to
> RamDiskDxe | NFIT.
(BootGraphicsResourceTableDxe's ReadyToBoot callback --
InstallBootGraphicsResourceTable() -- handles the lack of
EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138b3c018
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 6 +--
ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 45 ++++++++++++--------
2 files changed, 29 insertions(+), 22 deletions(-)
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
index 7724cf215dda..95a56a10bb5c 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -28,11 +28,12 @@ [Packages]
ArmPkg/ArmPkg.dec
ArmVirtPkg/ArmVirtPkg.dec
MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
BaseLib
DebugLib
- PcdLib
+ QemuFwCfgLib
UefiBootServicesTableLib
UefiDriverEntryPoint
@@ -40,8 +41,5 @@ [Protocols]
gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
gEdkiiPlatformHasDeviceTreeProtocolGuid ## SOMETIMES_PRODUCES
-[FeaturePcd]
- gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
-
[Depex]
TRUE
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
index 8681f813a6b5..46f96401632c 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
@@ -15,7 +15,7 @@
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
-#include <Library/PcdLib.h>
+#include <Library/QemuFwCfgLib.h>
#include <Library/UefiBootServicesTableLib.h>
#include <Protocol/PlatformHasAcpi.h>
#include <Protocol/PlatformHasDeviceTree.h>
@@ -27,18 +27,27 @@ PlatformHasAcpiDt (
IN EFI_SYSTEM_TABLE *SystemTable
)
{
- EFI_STATUS Status;
-
- Status = EFI_SUCCESS;
+ EFI_STATUS Status;
+ FIRMWARE_CONFIG_ITEM FwCfgItem;
+ UINTN FwCfgSize;
//
// If we fail to install any of the necessary protocols below, the OS will be
// unbootable anyway (due to lacking hardware description), so tolerate no
// errors here.
//
- // Always make ACPI available on 64-bit systems.
- //
- if (MAX_UINTN == MAX_UINT64) {
+ if (MAX_UINTN == MAX_UINT64 &&
+ !EFI_ERROR (
+ QemuFwCfgFindFile (
+ "etc/table-loader",
+ &FwCfgItem,
+ &FwCfgSize
+ )
+ )) {
+ //
+ // Only make ACPI available on 64-bit systems, and only if QEMU generates
+ // (a subset of) the ACPI tables.
+ //
Status = gBS->InstallProtocolInterface (
&ImageHandle,
&gEdkiiPlatformHasAcpiProtocolGuid,
@@ -48,21 +57,21 @@ PlatformHasAcpiDt (
if (EFI_ERROR (Status)) {
goto Failed;
}
+
+ return Status;
}
//
- // Expose the Device Tree unless PcdPureAcpiBoot is set.
+ // Expose the Device Tree otherwise.
//
- if (!FeaturePcdGet (PcdPureAcpiBoot)) {
- Status = gBS->InstallProtocolInterface (
- &ImageHandle,
- &gEdkiiPlatformHasDeviceTreeProtocolGuid,
- EFI_NATIVE_INTERFACE,
- NULL
- );
- if (EFI_ERROR (Status)) {
- goto Failed;
- }
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gEdkiiPlatformHasDeviceTreeProtocolGuid,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+ if (EFI_ERROR (Status)) {
+ goto Failed;
}
return Status;
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
2017-03-17 20:47 ` [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI Laszlo Ersek
@ 2017-03-17 21:10 ` Ard Biesheuvel
2017-03-17 21:25 ` Laszlo Ersek
2017-03-22 14:18 ` Ard Biesheuvel
1 sibling, 1 reply; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-17 21:10 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
> the guest. Showing both is never needed (it is actually detrimental to the
> adoption of standards, such as SBSA / SBBR).
>
> * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
>
>> Found FwCfg @ 0x9020008/0x9020000
>> Found FwCfg DMA @ 0x9020010
>> InstallProtocolInterface: [EdkiiPlatformHasAcpiProtocol] 0
>
> plus the usual messages. Later the guest kernel logs
>
>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
Why is there no MEMATTR table in this case? Or was it omitted for brevity?
>
> before it lists the ACPI tables one by one.
>
> * With "-no-acpi", the firmware logs:
>
>> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
>> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
>> PlatformHasAcpiDtDxe | InstallProtocolInterface:
>> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTreeProtocol] 0
>> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
>> FdtClientDxe | 0x13FFBF000 to OS
>> ...
>> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
>> DXE_CORE | loaded!!
>> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
>> DXE_CORE | not loaded!!
>> ...
>> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
>> RamDiskDxe | Table Protocol, unable to publish RAM disks to
>> RamDiskDxe | NFIT.
>
> (BootGraphicsResourceTableDxe's ReadyToBoot callback --
> InstallBootGraphicsResourceTable() -- handles the lack of
> EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
>
>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138b3c018
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
> ---
> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 6 +--
> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 45 ++++++++++++--------
> 2 files changed, 29 insertions(+), 22 deletions(-)
>
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> index 7724cf215dda..95a56a10bb5c 100644
> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> @@ -28,11 +28,12 @@ [Packages]
> ArmPkg/ArmPkg.dec
> ArmVirtPkg/ArmVirtPkg.dec
> MdePkg/MdePkg.dec
> + OvmfPkg/OvmfPkg.dec
>
> [LibraryClasses]
> BaseLib
> DebugLib
> - PcdLib
> + QemuFwCfgLib
> UefiBootServicesTableLib
> UefiDriverEntryPoint
>
> @@ -40,8 +41,5 @@ [Protocols]
> gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
> gEdkiiPlatformHasDeviceTreeProtocolGuid ## SOMETIMES_PRODUCES
>
> -[FeaturePcd]
> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
> -
> [Depex]
> TRUE
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> index 8681f813a6b5..46f96401632c 100644
> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> @@ -15,7 +15,7 @@
>
> #include <Library/BaseLib.h>
> #include <Library/DebugLib.h>
> -#include <Library/PcdLib.h>
> +#include <Library/QemuFwCfgLib.h>
> #include <Library/UefiBootServicesTableLib.h>
> #include <Protocol/PlatformHasAcpi.h>
> #include <Protocol/PlatformHasDeviceTree.h>
> @@ -27,18 +27,27 @@ PlatformHasAcpiDt (
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> - EFI_STATUS Status;
> -
> - Status = EFI_SUCCESS;
> + EFI_STATUS Status;
> + FIRMWARE_CONFIG_ITEM FwCfgItem;
> + UINTN FwCfgSize;
>
> //
> // If we fail to install any of the necessary protocols below, the OS will be
> // unbootable anyway (due to lacking hardware description), so tolerate no
> // errors here.
> //
> - // Always make ACPI available on 64-bit systems.
> - //
> - if (MAX_UINTN == MAX_UINT64) {
> + if (MAX_UINTN == MAX_UINT64 &&
> + !EFI_ERROR (
> + QemuFwCfgFindFile (
> + "etc/table-loader",
> + &FwCfgItem,
> + &FwCfgSize
> + )
> + )) {
> + //
> + // Only make ACPI available on 64-bit systems, and only if QEMU generates
> + // (a subset of) the ACPI tables.
> + //
> Status = gBS->InstallProtocolInterface (
> &ImageHandle,
> &gEdkiiPlatformHasAcpiProtocolGuid,
> @@ -48,21 +57,21 @@ PlatformHasAcpiDt (
> if (EFI_ERROR (Status)) {
> goto Failed;
> }
> +
> + return Status;
> }
>
> //
> - // Expose the Device Tree unless PcdPureAcpiBoot is set.
> + // Expose the Device Tree otherwise.
> //
> - if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> - Status = gBS->InstallProtocolInterface (
> - &ImageHandle,
> - &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> - EFI_NATIVE_INTERFACE,
> - NULL
> - );
> - if (EFI_ERROR (Status)) {
> - goto Failed;
> - }
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + goto Failed;
> }
>
> return Status;
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
2017-03-17 21:10 ` Ard Biesheuvel
@ 2017-03-17 21:25 ` Laszlo Ersek
2017-03-17 21:27 ` Ard Biesheuvel
0 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 21:25 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: edk2-devel-01, Leif Lindholm
On 03/17/17 22:10, Ard Biesheuvel wrote:
> On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
>> This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
>> the guest. Showing both is never needed (it is actually detrimental to the
>> adoption of standards, such as SBSA / SBBR).
>>
>> * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
>>
>>> Found FwCfg @ 0x9020008/0x9020000
>>> Found FwCfg DMA @ 0x9020010
>>> InstallProtocolInterface: [EdkiiPlatformHasAcpiProtocol] 0
>>
>> plus the usual messages. Later the guest kernel logs
>>
>>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
>
> Why is there no MEMATTR table in this case? Or was it omitted for brevity?
I don't have the slightest clue. What is the MEMATTR table?
... Hm, grepping the kernel, it's apparently the memory attributes
table. You added it in the following kernel commit:
a604af075a32 ("efi: Add support for the EFI_MEMORY_ATTRIBUTES_TABLE
config table", 2016-04-25)
and it is part of release v4.7.
Ah, I understand now. I used two kernels (two guests) for testing this,
namely "4.7.7-200.fc24.aarch64" and "4.5.0-15.el7.aarch64".
And, from the logs I collected, the "-no-acpi" log belongs to the Fedora
kernel, which has your MEMATTR patch; while the log without "-no-acpi"
(above) belongs to the RHEL-7.3 kernel, which does *not* have your
MEMATTR patch.
I've now removed "-no-acpi" from the Fedora 24 guest's config, and
repeated the test. It prints:
[ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
MEMATTR=0x13a689018
If you wish (and I don't have to submit a v3 for any other reason), I
can refresh the above line in the commit message.
Thanks!
Laszlo
>
>>
>> before it lists the ACPI tables one by one.
>>
>> * With "-no-acpi", the firmware logs:
>>
>>> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
>>> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
>>> PlatformHasAcpiDtDxe | InstallProtocolInterface:
>>> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTreeProtocol] 0
>>> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
>>> FdtClientDxe | 0x13FFBF000 to OS
>>> ...
>>> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
>>> DXE_CORE | loaded!!
>>> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
>>> DXE_CORE | not loaded!!
>>> ...
>>> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
>>> RamDiskDxe | Table Protocol, unable to publish RAM disks to
>>> RamDiskDxe | NFIT.
>>
>> (BootGraphicsResourceTableDxe's ReadyToBoot callback --
>> InstallBootGraphicsResourceTable() -- handles the lack of
>> EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
>>
>>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138b3c018
>>
>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> Cc: Leif Lindholm <leif.lindholm@linaro.org>
>> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>> ---
>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 6 +--
>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 45 ++++++++++++--------
>> 2 files changed, 29 insertions(+), 22 deletions(-)
>>
>> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> index 7724cf215dda..95a56a10bb5c 100644
>> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>> @@ -28,11 +28,12 @@ [Packages]
>> ArmPkg/ArmPkg.dec
>> ArmVirtPkg/ArmVirtPkg.dec
>> MdePkg/MdePkg.dec
>> + OvmfPkg/OvmfPkg.dec
>>
>> [LibraryClasses]
>> BaseLib
>> DebugLib
>> - PcdLib
>> + QemuFwCfgLib
>> UefiBootServicesTableLib
>> UefiDriverEntryPoint
>>
>> @@ -40,8 +41,5 @@ [Protocols]
>> gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
>> gEdkiiPlatformHasDeviceTreeProtocolGuid ## SOMETIMES_PRODUCES
>>
>> -[FeaturePcd]
>> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
>> -
>> [Depex]
>> TRUE
>> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>> index 8681f813a6b5..46f96401632c 100644
>> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>> @@ -15,7 +15,7 @@
>>
>> #include <Library/BaseLib.h>
>> #include <Library/DebugLib.h>
>> -#include <Library/PcdLib.h>
>> +#include <Library/QemuFwCfgLib.h>
>> #include <Library/UefiBootServicesTableLib.h>
>> #include <Protocol/PlatformHasAcpi.h>
>> #include <Protocol/PlatformHasDeviceTree.h>
>> @@ -27,18 +27,27 @@ PlatformHasAcpiDt (
>> IN EFI_SYSTEM_TABLE *SystemTable
>> )
>> {
>> - EFI_STATUS Status;
>> -
>> - Status = EFI_SUCCESS;
>> + EFI_STATUS Status;
>> + FIRMWARE_CONFIG_ITEM FwCfgItem;
>> + UINTN FwCfgSize;
>>
>> //
>> // If we fail to install any of the necessary protocols below, the OS will be
>> // unbootable anyway (due to lacking hardware description), so tolerate no
>> // errors here.
>> //
>> - // Always make ACPI available on 64-bit systems.
>> - //
>> - if (MAX_UINTN == MAX_UINT64) {
>> + if (MAX_UINTN == MAX_UINT64 &&
>> + !EFI_ERROR (
>> + QemuFwCfgFindFile (
>> + "etc/table-loader",
>> + &FwCfgItem,
>> + &FwCfgSize
>> + )
>> + )) {
>> + //
>> + // Only make ACPI available on 64-bit systems, and only if QEMU generates
>> + // (a subset of) the ACPI tables.
>> + //
>> Status = gBS->InstallProtocolInterface (
>> &ImageHandle,
>> &gEdkiiPlatformHasAcpiProtocolGuid,
>> @@ -48,21 +57,21 @@ PlatformHasAcpiDt (
>> if (EFI_ERROR (Status)) {
>> goto Failed;
>> }
>> +
>> + return Status;
>> }
>>
>> //
>> - // Expose the Device Tree unless PcdPureAcpiBoot is set.
>> + // Expose the Device Tree otherwise.
>> //
>> - if (!FeaturePcdGet (PcdPureAcpiBoot)) {
>> - Status = gBS->InstallProtocolInterface (
>> - &ImageHandle,
>> - &gEdkiiPlatformHasDeviceTreeProtocolGuid,
>> - EFI_NATIVE_INTERFACE,
>> - NULL
>> - );
>> - if (EFI_ERROR (Status)) {
>> - goto Failed;
>> - }
>> + Status = gBS->InstallProtocolInterface (
>> + &ImageHandle,
>> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
>> + EFI_NATIVE_INTERFACE,
>> + NULL
>> + );
>> + if (EFI_ERROR (Status)) {
>> + goto Failed;
>> }
>>
>> return Status;
>> --
>> 2.9.3
>>
>>
^ permalink raw reply [flat|nested] 67+ messages in thread* Re: [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
2017-03-17 21:25 ` Laszlo Ersek
@ 2017-03-17 21:27 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-17 21:27 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 21:25, Laszlo Ersek <lersek@redhat.com> wrote:
> On 03/17/17 22:10, Ard Biesheuvel wrote:
>> On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
>>> This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
>>> the guest. Showing both is never needed (it is actually detrimental to the
>>> adoption of standards, such as SBSA / SBBR).
>>>
>>> * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
>>>
>>>> Found FwCfg @ 0x9020008/0x9020000
>>>> Found FwCfg DMA @ 0x9020010
>>>> InstallProtocolInterface: [EdkiiPlatformHasAcpiProtocol] 0
>>>
>>> plus the usual messages. Later the guest kernel logs
>>>
>>>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
>>
>> Why is there no MEMATTR table in this case? Or was it omitted for brevity?
>
> I don't have the slightest clue. What is the MEMATTR table?
>
> ... Hm, grepping the kernel, it's apparently the memory attributes
> table. You added it in the following kernel commit:
>
> a604af075a32 ("efi: Add support for the EFI_MEMORY_ATTRIBUTES_TABLE
> config table", 2016-04-25)
>
> and it is part of release v4.7.
>
> Ah, I understand now. I used two kernels (two guests) for testing this,
> namely "4.7.7-200.fc24.aarch64" and "4.5.0-15.el7.aarch64".
>
> And, from the logs I collected, the "-no-acpi" log belongs to the Fedora
> kernel, which has your MEMATTR patch; while the log without "-no-acpi"
> (above) belongs to the RHEL-7.3 kernel, which does *not* have your
> MEMATTR patch.
>
> I've now removed "-no-acpi" from the Fedora 24 guest's config, and
> repeated the test. It prints:
>
> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
> MEMATTR=0x13a689018
>
> If you wish (and I don't have to submit a v3 for any other reason), I
> can refresh the above line in the commit message.
>
I was only concerned that these changes would affect whether the table
was published or not. But apparently not. Thanks for double checking.
^ permalink raw reply [flat|nested] 67+ messages in thread
* Re: [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
2017-03-17 20:47 ` [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI Laszlo Ersek
2017-03-17 21:10 ` Ard Biesheuvel
@ 2017-03-22 14:18 ` Ard Biesheuvel
1 sibling, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:18 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> This will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to
> the guest. Showing both is never needed (it is actually detrimental to the
> adoption of standards, such as SBSA / SBBR).
>
> * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe)
>
>> Found FwCfg @ 0x9020008/0x9020000
>> Found FwCfg DMA @ 0x9020010
>> InstallProtocolInterface: [EdkiiPlatformHasAcpiProtocol] 0
>
> plus the usual messages. Later the guest kernel logs
>
>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 ACPI 2.0=0x138440000
>
> before it lists the ACPI tables one by one.
>
> * With "-no-acpi", the firmware logs:
>
>> PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000
>> PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010
>> PlatformHasAcpiDtDxe | InstallProtocolInterface:
>> PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTreeProtocol] 0
>> FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @
>> FdtClientDxe | 0x13FFBF000 to OS
>> ...
>> DXE_CORE | Driver [AcpiTableDxe] was discovered but not
>> DXE_CORE | loaded!!
>> DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but
>> DXE_CORE | not loaded!!
>> ...
>> RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI
>> RamDiskDxe | Table Protocol, unable to publish RAM disks to
>> RamDiskDxe | NFIT.
>
> (BootGraphicsResourceTableDxe's ReadyToBoot callback --
> InstallBootGraphicsResourceTable() -- handles the lack of
> EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs
>
>> [ 0.000000] efi: SMBIOS 3.0=0x13bdb0000 MEMATTR=0x138b3c018
>
> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> Cc: Leif Lindholm <leif.lindholm@linaro.org>
> Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 6 +--
> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 45 ++++++++++++--------
> 2 files changed, 29 insertions(+), 22 deletions(-)
>
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> index 7724cf215dda..95a56a10bb5c 100644
> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
> @@ -28,11 +28,12 @@ [Packages]
> ArmPkg/ArmPkg.dec
> ArmVirtPkg/ArmVirtPkg.dec
> MdePkg/MdePkg.dec
> + OvmfPkg/OvmfPkg.dec
>
> [LibraryClasses]
> BaseLib
> DebugLib
> - PcdLib
> + QemuFwCfgLib
> UefiBootServicesTableLib
> UefiDriverEntryPoint
>
> @@ -40,8 +41,5 @@ [Protocols]
> gEdkiiPlatformHasAcpiProtocolGuid ## SOMETIMES_PRODUCES
> gEdkiiPlatformHasDeviceTreeProtocolGuid ## SOMETIMES_PRODUCES
>
> -[FeaturePcd]
> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
> -
> [Depex]
> TRUE
> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> index 8681f813a6b5..46f96401632c 100644
> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
> @@ -15,7 +15,7 @@
>
> #include <Library/BaseLib.h>
> #include <Library/DebugLib.h>
> -#include <Library/PcdLib.h>
> +#include <Library/QemuFwCfgLib.h>
> #include <Library/UefiBootServicesTableLib.h>
> #include <Protocol/PlatformHasAcpi.h>
> #include <Protocol/PlatformHasDeviceTree.h>
> @@ -27,18 +27,27 @@ PlatformHasAcpiDt (
> IN EFI_SYSTEM_TABLE *SystemTable
> )
> {
> - EFI_STATUS Status;
> -
> - Status = EFI_SUCCESS;
> + EFI_STATUS Status;
> + FIRMWARE_CONFIG_ITEM FwCfgItem;
> + UINTN FwCfgSize;
>
> //
> // If we fail to install any of the necessary protocols below, the OS will be
> // unbootable anyway (due to lacking hardware description), so tolerate no
> // errors here.
> //
> - // Always make ACPI available on 64-bit systems.
> - //
> - if (MAX_UINTN == MAX_UINT64) {
> + if (MAX_UINTN == MAX_UINT64 &&
> + !EFI_ERROR (
> + QemuFwCfgFindFile (
> + "etc/table-loader",
> + &FwCfgItem,
> + &FwCfgSize
> + )
> + )) {
> + //
> + // Only make ACPI available on 64-bit systems, and only if QEMU generates
> + // (a subset of) the ACPI tables.
> + //
> Status = gBS->InstallProtocolInterface (
> &ImageHandle,
> &gEdkiiPlatformHasAcpiProtocolGuid,
> @@ -48,21 +57,21 @@ PlatformHasAcpiDt (
> if (EFI_ERROR (Status)) {
> goto Failed;
> }
> +
> + return Status;
> }
>
> //
> - // Expose the Device Tree unless PcdPureAcpiBoot is set.
> + // Expose the Device Tree otherwise.
> //
> - if (!FeaturePcdGet (PcdPureAcpiBoot)) {
> - Status = gBS->InstallProtocolInterface (
> - &ImageHandle,
> - &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> - EFI_NATIVE_INTERFACE,
> - NULL
> - );
> - if (EFI_ERROR (Status)) {
> - goto Failed;
> - }
> + Status = gBS->InstallProtocolInterface (
> + &ImageHandle,
> + &gEdkiiPlatformHasDeviceTreeProtocolGuid,
> + EFI_NATIVE_INTERFACE,
> + NULL
> + );
> + if (EFI_ERROR (Status)) {
> + goto Failed;
> }
>
> return Status;
> --
> 2.9.3
>
>
^ permalink raw reply [flat|nested] 67+ messages in thread
* [PATCH v2 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot
2017-03-17 20:47 [PATCH v2 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
` (10 preceding siblings ...)
2017-03-17 20:47 ` [PATCH v2 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI Laszlo Ersek
@ 2017-03-17 20:47 ` Laszlo Ersek
2017-03-22 14:19 ` Ard Biesheuvel
11 siblings, 1 reply; 67+ messages in thread
From: Laszlo Ersek @ 2017-03-17 20:47 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel, Leif Lindholm
The build flag and the FeaturePCD have no effect any longer, remove them.
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>
---
ArmVirtPkg/ArmVirtPkg.dec | 10 ----------
ArmVirtPkg/ArmVirtQemu.dsc | 5 -----
2 files changed, 15 deletions(-)
diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
index a5ec42166445..efe83a383d55 100644
--- a/ArmVirtPkg/ArmVirtPkg.dec
+++ b/ArmVirtPkg/ArmVirtPkg.dec
@@ -58,13 +58,3 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
# EFI_VT_100_GUID.
#
gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D}|VOID*|0x00000007
-
-[PcdsFeatureFlag]
- #
- # Pure ACPI boot
- #
- # Inhibit installation of the FDT as a configuration table if this feature
- # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
- # description of the platform, and it is up to the OS to choose.
- #
- gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x0000000a
diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
index 328c2b79994b..88523650e946 100644
--- a/ArmVirtPkg/ArmVirtQemu.dsc
+++ b/ArmVirtPkg/ArmVirtQemu.dsc
@@ -34,7 +34,6 @@ [Defines]
# -D FLAG=VALUE
#
DEFINE SECURE_BOOT_ENABLE = FALSE
- DEFINE PURE_ACPI_BOOT_ENABLE = FALSE
!include ArmVirtPkg/ArmVirt.dsc.inc
@@ -95,10 +94,6 @@ [PcdsFeatureFlag.common]
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
-!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
- gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
-!endif
-
[PcdsFixedAtBuild.common]
gArmPlatformTokenSpaceGuid.PcdCoreCount|1
!if $(ARCH) == AARCH64
--
2.9.3
^ permalink raw reply related [flat|nested] 67+ messages in thread* Re: [PATCH v2 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot
2017-03-17 20:47 ` [PATCH v2 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot Laszlo Ersek
@ 2017-03-22 14:19 ` Ard Biesheuvel
0 siblings, 0 replies; 67+ messages in thread
From: Ard Biesheuvel @ 2017-03-22 14:19 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01, Leif Lindholm
On 17 March 2017 at 20:47, Laszlo Ersek <lersek@redhat.com> wrote:
> The build flag and the FeaturePCD have no effect any longer, remove them.
>
> 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>
> ---
> ArmVirtPkg/ArmVirtPkg.dec | 10 ----------
> ArmVirtPkg/ArmVirtQemu.dsc | 5 -----
> 2 files changed, 15 deletions(-)
>
> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
> index a5ec42166445..efe83a383d55 100644
> --- a/ArmVirtPkg/ArmVirtPkg.dec
> +++ b/ArmVirtPkg/ArmVirtPkg.dec
> @@ -58,13 +58,3 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
> # EFI_VT_100_GUID.
> #
> gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D}|VOID*|0x00000007
> -
> -[PcdsFeatureFlag]
> - #
> - # Pure ACPI boot
> - #
> - # Inhibit installation of the FDT as a configuration table if this feature
> - # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
> - # description of the platform, and it is up to the OS to choose.
> - #
> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x0000000a
> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
> index 328c2b79994b..88523650e946 100644
> --- a/ArmVirtPkg/ArmVirtQemu.dsc
> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
> @@ -34,7 +34,6 @@ [Defines]
> # -D FLAG=VALUE
> #
> DEFINE SECURE_BOOT_ENABLE = FALSE
> - DEFINE PURE_ACPI_BOOT_ENABLE = FALSE
>
> !include ArmVirtPkg/ArmVirt.dsc.inc
>
> @@ -95,10 +94,6 @@ [PcdsFeatureFlag.common]
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
>
> -!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
> -!endif
> -
> [PcdsFixedAtBuild.common]
> gArmPlatformTokenSpaceGuid.PcdCoreCount|1
> !if $(ARCH) == AARCH64
> --
> 2.9.3
>
^ permalink raw reply [flat|nested] 67+ messages in thread