From nobody Sat Nov 2 14:38:05 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1489783672285751.2722849263503; Fri, 17 Mar 2017 13:47:52 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 0104580447; Fri, 17 Mar 2017 13:47:48 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 3267380444 for ; Fri, 17 Mar 2017 13:47:46 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A52C7804F2; Fri, 17 Mar 2017 20:47:46 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-70.phx2.redhat.com [10.3.116.70]) by smtp.corp.redhat.com (Postfix) with ESMTP id AE71E17AC2; Fri, 17 Mar 2017 20:47:45 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A52C7804F2 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A52C7804F2 From: Laszlo Ersek To: edk2-devel-01 Date: Fri, 17 Mar 2017 21:47:24 +0100 Message-Id: <20170317204731.31488-6-lersek@redhat.com> In-Reply-To: <20170317204731.31488-1-lersek@redhat.com> References: <20170317204731.31488-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 17 Mar 2017 20:47:46 +0000 (UTC) Subject: [edk2] [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Leif Lindholm , Ard Biesheuvel MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" 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 Cc: Leif Lindholm Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel --- 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 =3D { 0x6847cc74, 0xe9ec, 0x4f8f, {0xa2, 0x9d, 0xa= b, 0x44, 0xe7, 0x54, 0xa8, 0xfc} } =20 +[Protocols] + ## Include/Protocol/PlatformHasAcpi.h + gEdkiiPlatformHasAcpiProtocolGuid =3D { 0xf0966b41, 0xc23f, 0x41b9= , { 0x96, 0x04, 0x0f, 0xf7, 0xe1, 0x11, 0x96, 0x5a } } + [PcdsFeatureFlag.common] gArmTokenSpaceGuid.PcdCpuDxeProduceDebugSupport|FALSE|BOOLEAN|0x00000001 =20 diff --git a/ArmPkg/Library/PlatformHasAcpiLib/PlatformHasAcpiLib.inf b/Arm= Pkg/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 dep= end +# 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 availa= ble +# 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, WI= THOUT +# WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +## + +[Defines] + INF_VERSION =3D 1.25 + BASE_NAME =3D PlatformHasAcpiLib + FILE_GUID =3D 29beb028-0958-447b-be0a-12229235d77d + MODULE_TYPE =3D BASE + VERSION_STRING =3D 1.0 + LIBRARY_CLASS =3D PlatformHasAcpiLib|DXE_DRIVER + CONSTRUCTOR =3D PlatformHasAcpiInitialize + +[Sources] + PlatformHasAcpiLib.c + +[Packages] + ArmPkg/ArmPkg.dec + MdePkg/MdePkg.dec + +[Depex] + gEdkiiPlatformHasAcpiProtocolGuid diff --git a/ArmPkg/Include/Protocol/PlatformHasAcpi.h b/ArmPkg/Include/Pro= tocol/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 availa= ble + 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, WI= THOUT + 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/ArmPk= g/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 dep= end + 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 availa= ble + 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, WI= THOUT + WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED. +**/ + +#include + +RETURN_STATUS +EFIAPI +PlatformHasAcpiInitialize ( + VOID + ) +{ + // + // Do nothing, just imbue AcpiTableDxe with an + // EDKII_PLATFORM_HAS_ACPI_PROTOCOL dependency. + // + return RETURN_SUCCESS; +} --=20 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel