* [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement
@ 2016-10-15 16:56 Laszlo Ersek
2016-10-15 16:58 ` Ard Biesheuvel
0 siblings, 1 reply; 3+ messages in thread
From: Laszlo Ersek @ 2016-10-15 16:56 UTC (permalink / raw)
To: edk2-devel-01; +Cc: Ard Biesheuvel
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 <ard.biesheuvel@linaro.org>
Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
---
ArmVirtPkg/ArmVirt.dsc.inc | 4 ----
1 file changed, 4 deletions(-)
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
--
2.9.2
^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement
2016-10-15 16:56 [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement Laszlo Ersek
@ 2016-10-15 16:58 ` Ard Biesheuvel
2016-10-15 17:07 ` Laszlo Ersek
0 siblings, 1 reply; 3+ messages in thread
From: Ard Biesheuvel @ 2016-10-15 16:58 UTC (permalink / raw)
To: Laszlo Ersek; +Cc: edk2-devel-01
On 15 October 2016 at 17:56, Laszlo Ersek <lersek@redhat.com> wrote:
> 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 <ard.biesheuvel@linaro.org>
> Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
I always had a suspicion we were missing something here, but I never
got around to tracking it down. Thanks for doing that.
> ---
> ArmVirtPkg/ArmVirt.dsc.inc | 4 ----
> 1 file changed, 4 deletions(-)
>
> 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
> --
> 2.9.2
>
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement
2016-10-15 16:58 ` Ard Biesheuvel
@ 2016-10-15 17:07 ` Laszlo Ersek
0 siblings, 0 replies; 3+ messages in thread
From: Laszlo Ersek @ 2016-10-15 17:07 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: edk2-devel-01
On 10/15/16 18:58, Ard Biesheuvel wrote:
> On 15 October 2016 at 17:56, Laszlo Ersek <lersek@redhat.com> wrote:
>> 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 <ard.biesheuvel@linaro.org>
>> Fixes: 6f5872b1f4013f58c6d2f446d885edd6c8ea6d21
>> Contributed-under: TianoCore Contribution Agreement 1.0
>> Signed-off-by: Laszlo Ersek <lersek@redhat.com>
>
> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Commit 5b54c92a6537.
> I always had a suspicion we were missing something here, but I never
> got around to tracking it down. Thanks for doing that.
It's Saturday evening after all, i.e., when I'm supposed to have fun ;)
Thanks!
Laszlo
>> ---
>> ArmVirtPkg/ArmVirt.dsc.inc | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> 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
>> --
>> 2.9.2
>>
> _______________________________________________
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2016-10-15 17:07 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-10-15 16:56 [PATCH] ArmVirtPkg: undo bogus component name and driver diagnostics disablement Laszlo Ersek
2016-10-15 16:58 ` Ard Biesheuvel
2016-10-15 17:07 ` Laszlo Ersek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox