public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: Laszlo Ersek <lersek@redhat.com>
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: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library
Date: Mon, 20 Mar 2017 10:17:38 +0100	[thread overview]
Message-ID: <e8e241e4-98da-0965-10c9-932c3a4a6a7e@redhat.com> (raw)
In-Reply-To: <0C09AFA07DD0434D9E2A0C6AEB0483103B835B4B@shsmsx102.ccr.corp.intel.com>

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
>



  reply	other threads:[~2017-03-20  9:17 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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-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
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
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
2017-03-20  9:57       ` Zeng, Star
2017-03-20 10:10         ` Laszlo Ersek
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
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-20 11:59       ` Leif Lindholm
2017-03-22 15:01     ` Laszlo Ersek
2017-03-23  1:41       ` Zeng, Star
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:10               ` Laszlo Ersek
2017-03-24 17:11                 ` Ard Biesheuvel
2017-03-24 17:09             ` Laszlo Ersek
2017-03-27  2:42               ` Gao, Liming
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
2017-03-28  7:49                       ` Laszlo Ersek
2017-03-29  9:49                         ` Gao, Liming
2017-03-29 13:03                           ` Laszlo Ersek
2017-03-20  2:23   ` Zeng, Star
2017-03-20  9:17     ` Laszlo Ersek [this message]
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:43             ` Ard Biesheuvel
2017-03-21  9:02               ` Laszlo Ersek
2017-03-21 18:00                 ` Laszlo Ersek
2017-03-22 14:12                   ` Ard Biesheuvel
2017-03-21  8:37           ` Laszlo Ersek
2017-03-21  8:41             ` Zeng, Star
2017-03-21  9:05               ` Laszlo Ersek
2017-03-22 16:45   ` Laszlo Ersek
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
2017-03-17 20:47 ` [PATCH v2 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe Laszlo Ersek
2017-03-22 14:14   ` Ard Biesheuvel
2017-03-17 20:47 ` [PATCH v2 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe 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
2017-03-22 14:16   ` Ard Biesheuvel
2017-03-22 14:54     ` Laszlo Ersek
2017-03-22 15:05       ` Ard Biesheuvel
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
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-17 21:27       ` 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
2017-03-22 14:19   ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e8e241e4-98da-0965-10c9-932c3a4a6a7e@redhat.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox