From patchwork Sat Oct 15 16:56:22 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Laszlo Ersek X-Patchwork-Id: 77687 Delivered-To: patch@linaro.org Received: by 10.140.97.247 with SMTP id m110csp775651qge; Sat, 15 Oct 2016 09:56:33 -0700 (PDT) X-Received: by 10.99.254.5 with SMTP id p5mr21975841pgh.124.1476550592918; Sat, 15 Oct 2016 09:56:32 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [2001:19d0:306:5::1]) by mx.google.com with ESMTPS id l18si23291181pfi.186.2016.10.15.09.56.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Oct 2016 09:56:32 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) client-ip=2001:19d0:306:5::1; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 2001:19d0:306:5::1 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 3D22B1A1E3A; Sat, 15 Oct 2016 09:56:32 -0700 (PDT) X-Original-To: edk2-devel@ml01.01.org Delivered-To: edk2-devel@ml01.01.org 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 D5DEA1A1E2F for ; Sat, 15 Oct 2016 09:56:30 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 32B134E4C0; Sat, 15 Oct 2016 16:56:30 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-11.phx2.redhat.com [10.3.116.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9FGuSAn007109; Sat, 15 Oct 2016 12:56:29 -0400 From: Laszlo Ersek To: edk2-devel-01 Date: Sat, 15 Oct 2016 18:56:22 +0200 Message-Id: <20161015165622.21996-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Sat, 15 Oct 2016 16:56:30 +0000 (UTC) Subject: [edk2] [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Ard Biesheuvel MIME-Version: 1.0 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" The entry point function of any UEFI_DRIVER that conforms to the UEFI driver model must install an instance of the EFI_DRIVER_BINDING_PROTOCOL on the image handle. Beyond that, the following protocols are optional: - EFI_COMPONENT_NAME_PROTOCOL - EFI_COMPONENT_NAME2_PROTOCOL - EFI_DRIVER_CONFIGURATION_PROTOCOL - EFI_DRIVER_CONFIGURATION2_PROTOCOL - EFI_DRIVER_DIAGNOSTICS_PROTOCOL - EFI_DRIVER_DIAGNOSTICS2_PROTOCOL The UefiLib functions - EfiLibInstallAllDriverProtocols() - EfiLibInstallAllDriverProtocols2() - EfiLibInstallDriverBindingComponentName2() are convenience helpers for such UEFI_DRIVERs. They simplify the installation of the above protocols. The UefiLib instance in "MdePkg/Library/UefiLib/UefiDriverModel.c" allows platforms to control these functions through the MdePkg feature PCDs - PcdComponentNameDisable - PcdComponentName2Disable - PcdDriverDiagnosticsDisable - PcdDriverDiagnostics2Disable If any of these PCDs are set to TRUE, then the helper functions will not install the corresponding protocol interfaces on the image handle, even if the driver passes in non-NULL protocol interfaces. In other words, at build time, a platform can forcibly prevent all drivers that employ UefiLib from producing these protocols. In ArmVirtPkg, that's what we've been doing forever, for no reason at all. This is why we haven't been seeing component and driver names from the DH, DEVICES, DRIVERS and DEVTREE shell commands, unlike in OvmfPkg. The default value for all these PCDs is FALSE, in "MdePkg/MdePkg.dec". Revert ArmVirtPkg to the sane defaults. This bug dates back to the inception of ArmVirtPkg (called ArmPlatformPkg/ArmVirtualizationPkg at the time). Cc: Ard Biesheuvel Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek --- ArmVirtPkg/ArmVirt.dsc.inc | 4 ---- 1 file changed, 4 deletions(-) -- 2.9.2 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel Reviewed-by: Ard Biesheuvel diff --git a/ArmVirtPkg/ArmVirt.dsc.inc b/ArmVirtPkg/ArmVirt.dsc.inc index c624b3cdbecd..c071988ad8f5 100644 --- a/ArmVirtPkg/ArmVirt.dsc.inc +++ b/ArmVirtPkg/ArmVirt.dsc.inc @@ -254,10 +254,6 @@ [BuildOptions] [PcdsFeatureFlag.common] gEfiMdeModulePkgTokenSpaceGuid.PcdHiiOsRuntimeSupport|FALSE - gEfiMdePkgTokenSpaceGuid.PcdComponentNameDisable|TRUE - gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnosticsDisable|TRUE - gEfiMdePkgTokenSpaceGuid.PcdComponentName2Disable|TRUE - gEfiMdePkgTokenSpaceGuid.PcdDriverDiagnostics2Disable|TRUE # # Control what commands are supported from the UI