Re: [edk2-devel] [PATCH v3 1/4] ArmPkg: Replace CoreId and ClusterId with Mpidr in ARM_CORE_INFO struct

2022-02-04 Thread Rebecca Cran 

On 1/31/22 04:42, Ard Biesheuvel wrote:


On Mon, 31 Jan 2022 at 00:22, Ard Biesheuvel  wrote:

I've had a stab at refactoring this code. Branch can be found here:
https://github.com/ardbiesheuvel/edk2/tree/armpkg-mpservicesdxe-refactor


OK, I've did some more work on this, and ended up with a branch that
builds and runs correctly on Raspberry Pi 4. Note that it requires
cache maintenance in the test app as well, or the ApFunction() routine
may be sitting in the cache on the BSP, and the AP will branch to who
knows where.


Thanks. I'll do some testing on my end and review the changes.
I did notice thatDmaLib is missing from ArmPkg/ArmPkg.dsc. -- Rebecca Cran


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86398): https://edk2.groups.io/g/devel/message/86398
Mute This Topic: https://groups.io/mt/87760630/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 7/8] PciHostBridgeDxe: Extend service to get base addresses before allocation

2022-02-04 Thread Ojeda Leon, Nicolas via groups.io 
Hi Gerd, 

> Hmm, so you are hiding the #define here to avoid updating 
> Protocol/PciHostBridgeResourceAllocation.h ...
> 
> I suspect if this can't be implemented in the pci enumerator alone there is 
> just no way around actually extending uefi protocols.  But it's also not 
> fully clear to me why you need this new "partial" state.
> Wouldn't you know either nothing or both base + size for a resource?
>

Yes you are right, the current status is we have nothing and after the 
resources are allocated we have base and size. However, the allocation happens 
after CreateResourceMap is called, this function is the one that iterates over 
all resources of all devices under a root bridges and places them in a root 
bridge relative offset to then calculate the length of the resources required 
for that specific root bridge. For the pre-populated BARs I retrieve the Base 
Address of the Root Bridge before placing the resources at the root bridge 
relative offset so that I can translate the BAR address (set by the host) into 
an offset. That's why I created this patch to retrieve only the base address 
before the root bridge resource map is created, submitted and allocated.

> Also: Maybe split this series into two?  One for the host-provided bridges, 
> and another for the pre-populated bars?  So the former can already be merged 
> while the later is still sorted?

Yes I will do that.

> take care,
>   Gerd


Thanks,

Nicolas



Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86396): https://edk2.groups.io/g/devel/message/86396
Mute This Topic: https://groups.io/mt/88893097/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v4 7/8] PciHostBridgeDxe: Extend service to get base addresses before allocation

2022-02-04 Thread Ojeda Leon, Nicolas via groups.io 
Hi Gerd,

> Also: Maybe split this series into two?  One for the host-provided bridges, 
> and another for the pre-populated bars?  So the former can already be merged 
> while the later is still sorted?

Is it already possible for someone to merge the first 5 patches or should I 
submit a new revision with the 5 patches alone?

Best regards,

Nicolas




Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Jonathan Weiss
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879





-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86397): https://edk2.groups.io/g/devel/message/86397
Mute This Topic: https://groups.io/mt/88893097/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v2 1/1] OvmfPkg/VmgExitLib: Fix uninitialized variable warning with XCODE5

2022-02-04 Thread Rebecca Cran 
XCODE5 reported the following warning:

OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c:1895:12: note:
uninitialized use occurs here
   Compacted
   ^

Initialize the 'Compacted' variable to fix the warning.

Signed-off-by: Rebecca Cran 
---
 OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c 
b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
index a40a31f7c275..ccb1300690fa 100644
--- a/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
+++ b/OvmfPkg/Library/VmgExitLib/VmgExitVcHandler.c
@@ -1872,6 +1872,7 @@ GetCpuidFw (
 UINT32 XSaveSize;
 
 XssMsr.Uint64 = 0;
+Compacted = 0;
 if (EcxIn == 1) {
   /*
* The PPR and APM aren't clear on what size should be encoded in
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86395): https://edk2.groups.io/g/devel/message/86395
Mute This Topic: https://groups.io/mt/88915973/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 1/1] BaseTools: Update CLANG{35,38}_WARNING_OVERRIDES to ignore unused vars

2022-02-04 Thread Michael D Kinney 
Reviewed-by: Michael D Kinney 

Mike

> -Original Message-
> From: devel@edk2.groups.io  On Behalf Of Rebecca Cran
> Sent: Friday, February 4, 2022 11:51 AM
> To: devel@edk2.groups.io; Feng, Bob C ; Gao, Liming 
> ; Chen, Christine
> ; Kinney, Michael D ; 
> Andrew Fish 
> Cc: Rebecca Cran 
> Subject: [edk2-devel] [PATCH 1/1] BaseTools: Update 
> CLANG{35,38}_WARNING_OVERRIDES to ignore unused vars
> 
> Building with the CLANG35 and CLANG38 toolset fails because of variables
> which are set but not otherwise used in the RELEASE build.
> 
> GCC added -Wno-unused-but-set-variable back in 2016, and later added
> -Wno-unused-const-variable. Add those to CLANG35_WARNING_OVERRIDES and
> CLANG38_WARNING_OVERRIDES.
> 
> Signed-off-by: Rebecca Cran 
> ---
>  BaseTools/Conf/tools_def.template | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/BaseTools/Conf/tools_def.template 
> b/BaseTools/Conf/tools_def.template
> index 2e6b382ab623..e839e8602a0b 100755
> --- a/BaseTools/Conf/tools_def.template
> +++ b/BaseTools/Conf/tools_def.template
> @@ -2496,7 +2496,7 @@ RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z 
> common-page-size=0x20
>  DEFINE CLANG35_ARM_TARGET= -target arm-linux-gnueabi
>  DEFINE CLANG35_AARCH64_TARGET= -target aarch64-linux-gnu
> 
> -DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-
> range-compare -Wno-empty-body -Wno-unknown-warning-option
> +DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-
> range-compare -Wno-empty-body -Wno-unknown-warning-option 
> -Wno-unused-but-set-variable -Wno-unused-const-variable
>  DEFINE CLANG35_ARM_CC_FLAGS  = DEF(GCC_ARM_CC_FLAGS) 
> DEF(CLANG35_ARM_TARGET) DEF(CLANG35_WARNING_OVERRIDES)
>  DEFINE CLANG35_AARCH64_CC_FLAGS  = DEF(GCC_AARCH64_CC_FLAGS) 
> DEF(CLANG35_AARCH64_TARGET) -mcmodel=small
> DEF(CLANG35_WARNING_OVERRIDES)
> 
> @@ -2566,7 +2566,7 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
>  DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
>  DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
> 
> -DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-
> range-compare -Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
> -Wno-unknown-warning-option
> +DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
> -Wno-tautological-compare -Wno-tautological-constant-out-of-
> range-compare -Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
> -Wno-unknown-warning-option -Wno-unused-but-set-variable
> -Wno-unused-const-variable
>  DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) 
> DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-
> bitfields -Wno-address -Wno-shift-negative-value -Wno-unknown-pragmas 
> -Wno-incompatible-library-redeclaration -fno-
> asynchronous-unwind-tables -mno-sse -mno-mmx -msoft-float -mno-implicit-float 
>  -ftrap-
> function=undefined_behavior_has_been_optimized_away_by_clang -funsigned-char 
> -fno-ms-extensions -Wno-null-dereference
> 
>  ###
> --
> 2.34.1
> 
> 
> 
> 
> 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86393): https://edk2.groups.io/g/devel/message/86393
Mute This Topic: https://groups.io/mt/88915148/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH 1/1] BaseTools: Update CLANG{35,38}_WARNING_OVERRIDES to ignore unused vars

2022-02-04 Thread Rebecca Cran 
Building with the CLANG35 and CLANG38 toolset fails because of variables
which are set but not otherwise used in the RELEASE build.

GCC added -Wno-unused-but-set-variable back in 2016, and later added
-Wno-unused-const-variable. Add those to CLANG35_WARNING_OVERRIDES and
CLANG38_WARNING_OVERRIDES.

Signed-off-by: Rebecca Cran 
---
 BaseTools/Conf/tools_def.template | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/BaseTools/Conf/tools_def.template 
b/BaseTools/Conf/tools_def.template
index 2e6b382ab623..e839e8602a0b 100755
--- a/BaseTools/Conf/tools_def.template
+++ b/BaseTools/Conf/tools_def.template
@@ -2496,7 +2496,7 @@ RELEASE_GCC5_AARCH64_DLINK_XIPFLAGS = -z 
common-page-size=0x20
 DEFINE CLANG35_ARM_TARGET= -target arm-linux-gnueabi
 DEFINE CLANG35_AARCH64_TARGET= -target aarch64-linux-gnu
 
-DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body -Wno-unknown-warning-option
+DEFINE CLANG35_WARNING_OVERRIDES = -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body -Wno-unknown-warning-option -Wno-unused-but-set-variable 
-Wno-unused-const-variable
 DEFINE CLANG35_ARM_CC_FLAGS  = DEF(GCC_ARM_CC_FLAGS) 
DEF(CLANG35_ARM_TARGET) DEF(CLANG35_WARNING_OVERRIDES)
 DEFINE CLANG35_AARCH64_CC_FLAGS  = DEF(GCC_AARCH64_CC_FLAGS) 
DEF(CLANG35_AARCH64_TARGET) -mcmodel=small DEF(CLANG35_WARNING_OVERRIDES)
 
@@ -2566,7 +2566,7 @@ DEFINE CLANG38_X64_PREFIX   = ENV(CLANG38_BIN)
 DEFINE CLANG38_IA32_TARGET  = -target i686-pc-linux-gnu
 DEFINE CLANG38_X64_TARGET   = -target x86_64-pc-linux-gnu
 
-DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
-Wno-unknown-warning-option
+DEFINE CLANG38_WARNING_OVERRIDES= -Wno-parentheses-equality 
-Wno-tautological-compare -Wno-tautological-constant-out-of-range-compare 
-Wno-empty-body -Wno-unused-const-variable -Wno-varargs 
-Wno-unknown-warning-option -Wno-unused-but-set-variable 
-Wno-unused-const-variable
 DEFINE CLANG38_ALL_CC_FLAGS = DEF(GCC48_ALL_CC_FLAGS) 
DEF(CLANG38_WARNING_OVERRIDES) -fno-stack-protector -mms-bitfields -Wno-address 
-Wno-shift-negative-value -Wno-unknown-pragmas 
-Wno-incompatible-library-redeclaration -fno-asynchronous-unwind-tables 
-mno-sse -mno-mmx -msoft-float -mno-implicit-float  
-ftrap-function=undefined_behavior_has_been_optimized_away_by_clang 
-funsigned-char -fno-ms-extensions -Wno-null-dereference
 
 ###
-- 
2.34.1



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86392): https://edk2.groups.io/g/devel/message/86392
Mute This Topic: https://groups.io/mt/88915148/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files of RISC-V processor package

2022-02-04 Thread Abner Chang 
BTW Mike,
Can Core CI on edk2 repo allow the modules referred in the DSC/FDF (e.g., 
OvmgRiscV64.dsc) to stay in edk2-platform?

Abner


From: Kinney, Michael D 
Sent: Saturday, January 22, 2022 1:37 AM
To: Chang, Abner (HPS SW/FW Technologist) ; Leif Lindholm 
; devel@edk2.groups.io ; Ni, Ray 
; Kinney, Michael D 
Cc: Andrew Fish ; Sami Mujawar 
Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files 
of RISC-V processor package


I would recommend adding the Platform DSC required to run RISC-V with QEMU to 
OvmfPkg so it can be part of CI for edk2 repo so any change to edk2 that is 
used by RISC-V can be verified by build and boot to shell.



I would like to see the ArmVirtPkg merged into OvmfPkg too so OvmfPkg providse 
FW build for all support CPU Archs running through QEMU to support edk2 CI that 
can build and boot to shell in an Azure Pipelines agent.



Mike



From: Chang, Abner (HPS SW/FW Technologist) 
Sent: Friday, January 21, 2022 9:13 AM
To: Kinney, Michael D ; Leif Lindholm 
; devel@edk2.groups.io; Ni, Ray 
Cc: Andrew Fish ; Sami Mujawar 
Subject: Re: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files 
of RISC-V processor package



Ok Mike and Leif,

Another question regarding to the location of RISC-V Virtual package for QEMU. 
What is the location and package you think RISC-V or other processor 
architectures should stay with?



Thanks

Abner



From: Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Sent: Saturday, January 15, 2022 12:21 AM
To: Chang, Abner (HPS SW/FW Technologist) 
mailto:abner.ch...@hpe.com>>; Leif Lindholm 
mailto:l...@nuviainc.com>>; 
devel@edk2.groups.io 
mailto:devel@edk2.groups.io>>; Ni, Ray 
mailto:ray...@intel.com>>; Kinney, Michael D 
mailto:michael.d.kin...@intel.com>>
Cc: Andrew Fish mailto:af...@apple.com>>; Sami Mujawar 
mailto:sami.muja...@arm.com>>
Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header files 
of RISC-V processor package



Hi Abner,

We already have a package for common platform content in the edk2 repo.
This is the MdeModulePkg.

However, the number of common platform features added to the MdeModulePkg over
time has made this a very large package, and this can be measured by how 
complex the
Maintainer.txt rules are for this package.

The revised approach is to create feature packages that platforms can add
if their platform requires that specific feature category.  Examples are
NetworkPkg, SecurityPkg, FmpDevicePkg, FatPkg, RedfishPkg, SourceLevelDebugPkg.

Instead of adding another generic package such as CommonPlatformPkg, I
would prefer to see the libs/modules either added to existing packages
that match the feature category, or create new feature packages if
there is a new feature category.

We also try to limit the edk2 repo to components that are directly related
the UEFI/PI specifications and are not Si/Platform specific.  Si/Platform
specific features go into the edk2-platforms repo.  An example of a generic
feature in the edk2-platforms repo is Features/Ext4.  The UEFI spec only
specifies FAT for UEFI boot from file system.

There are a number of other feature packages in edk2-platforms in the
Features directory, so you should review those as well to see if there
is natural landing zone for any of your components.

Mike


> -Original Message-
> From: Chang, Abner (HPS SW/FW Technologist) 
> mailto:abner.ch...@hpe.com>>
> Sent: Friday, January 14, 2022 3:15 AM
> To: Kinney, Michael D 
> mailto:michael.d.kin...@intel.com>>; Leif 
> Lindholm mailto:l...@nuviainc.com>>; 
> devel@edk2.groups.io; Ni, Ray
> mailto:ray...@intel.com>>
> Cc: Andrew Fish mailto:af...@apple.com>>; Sami Mujawar 
> mailto:sami.muja...@arm.com>>
> Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header 
> files of RISC-V processor package
>
>
>
> > -Original Message-
> > From: Kinney, Michael D 
> > mailto:michael.d.kin...@intel.com>>
> > Sent: Friday, January 14, 2022 12:38 AM
> > To: Chang, Abner (HPS SW/FW Technologist) 
> > mailto:abner.ch...@hpe.com>>; Leif
> > Lindholm mailto:l...@nuviainc.com>>; 
> > devel@edk2.groups.io; Ni, Ray
> > mailto:ray...@intel.com>>; Kinney, Michael D 
> > mailto:michael.d.kin...@intel.com>>
> > Cc: Andrew Fish mailto:af...@apple.com>>; Sami Mujawar
> > mailto:sami.muja...@arm.com>>
> > Subject: RE: [edk2-devel] [PATCH 01/79] ProcessorPkg/Include: Add header
> > files of RISC-V processor package
> >
> > Hi Abner,
> >
> > General recommendations included below.  Of course each
> > lib/modules/include needs to be reviewed and the
> > best location selected.  I am aware that there are components in edk2 that
> > do not follow these general
> > recommendations.  This is due to content that was added before these
> > recommendations were established
> > and we have work to do to get

Re: [edk2-devel] OvmfPkg VmgExitLib fails to build with CLANG38 (clang 13.0.0)

2022-02-04 Thread Brijesh Singh via groups.io 


On 2/2/22 6:16 PM, Rebecca Cran wrote:
> On 2/2/22 14:16, Lendacky, Thomas via groups.io wrote:
>> This looks like the same error that XCODE5 was complaining about. The
>> patch was submitted by Brijesh, but some CI failure occurred. I'm not
>> sure how that is possible from a one line patch like that, maybe it
>> has something to do with the file in general, excluding the patch?
>
> No, the patch is wrong: Uncrustify wants the equals signs to line up.
>
>  XssMsr.Uint64 = 0;
> +    Compacted = FALSE;
>
>
> Should be:
>
>  XssMsr.Uint64 = 0;
> +    Compacted = FALSE;
>
>
I am a bit occupied with kernel work right now, so feel free to send the
patch. Otherwise, I will get the patch out on Monday or Tuesday.

-Brijesh



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86390): https://edk2.groups.io/g/devel/message/86390
Mute This Topic: https://groups.io/mt/88869092/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] IntelFsp2WrapperPkg: Make GetFspm(s)UpdDataAddress reusable

2022-02-04 Thread Kuo, Ted 
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=3821
Moved GetFspmUpdDataAddress and GetFspsUpdDataAddress to FspWrapperApiLib
so that they can be consumed by other drivers.

Signed-off-by: Ted Kuo 
---
 .../FspmWrapperPeim/FspmWrapperPeim.c  | 18 ---
 .../FspmWrapperPeim/FspmWrapperPeim.inf|  2 --
 .../FspsWrapperPeim/FspsWrapperPeim.c  | 18 ---
 .../FspsWrapperPeim/FspsWrapperPeim.inf|  2 --
 .../Include/Library/FspWrapperApiLib.h | 22 +
 .../BaseFspWrapperApiLib/BaseFspWrapperApiLib.inf  |  5 +++
 .../BaseFspWrapperApiLib/FspWrapperApiLib.c| 36 ++
 7 files changed, 63 insertions(+), 40 deletions(-)

diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
index b0c6b2f8a6..d119f0b710 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.c
@@ -38,24 +38,6 @@
 
 extern EFI_GUID  gFspHobGuid;
 
-/**
-  Get the FSP M UPD Data address
-
-  @return FSP-M UPD Data Address
-**/
-
-UINTN
-GetFspmUpdDataAddress (
-  VOID
-  )
-{
-  if (PcdGet64 (PcdFspmUpdDataAddress64) != 0) {
-return (UINTN) PcdGet64 (PcdFspmUpdDataAddress64);
-  } else {
-return (UINTN) PcdGet32 (PcdFspmUpdDataAddress);
-  }
-}
-
 /**
   Call FspMemoryInit API.
 
diff --git a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf 
b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
index 5d0e021401..95317fb70d 100644
--- a/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspmWrapperPeim/FspmWrapperPeim.inf
@@ -56,11 +56,9 @@
 
 [Pcd]
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress   ## CONSUMES
-  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection  ## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFsptBaseAddress   ## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspMeasurementConfig  ## CONSUMES
-  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress64  ## CONSUMES
 
 [Sources]
   FspmWrapperPeim.c
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
index fadadd40e6..d34de97c1b 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.c
@@ -181,24 +181,6 @@ FspSiliconInitDoneGetFspHobList (
   }
 }
 
-/**
-  Get the FSP S UPD Data address
-
-  @return FSP-S UPD Data Address
-**/
-
-UINTN
-GetFspsUpdDataAddress (
-  VOID
-  )
-{
-  if (PcdGet64 (PcdFspsUpdDataAddress64) != 0) {
-return (UINTN) PcdGet64 (PcdFspsUpdDataAddress64);
-  } else {
-return (UINTN) PcdGet32 (PcdFspsUpdDataAddress);
-  }
-}
-
 /**
   This function is for FSP dispatch mode to perform post FSP-S process.
 
diff --git a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf 
b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
index da0049a654..50d33d0e0e 100644
--- a/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
+++ b/IntelFsp2WrapperPkg/FspsWrapperPeim/FspsWrapperPeim.inf
@@ -65,10 +65,8 @@
 
 [Pcd]
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspsBaseAddress   ## CONSUMES
-  gIntelFsp2WrapperTokenSpaceGuid.PcdFspsUpdDataAddress## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspModeSelection  ## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspMeasurementConfig  ## CONSUMES
-  gIntelFsp2WrapperTokenSpaceGuid.PcdFspsUpdDataAddress64  ## CONSUMES
 
 [Guids]
   gFspHobGuid   ## CONSUMES ## HOB
diff --git a/IntelFsp2WrapperPkg/Include/Library/FspWrapperApiLib.h 
b/IntelFsp2WrapperPkg/Include/Library/FspWrapperApiLib.h
index d38582d3e5..4ae42ff180 100644
--- a/IntelFsp2WrapperPkg/Include/Library/FspWrapperApiLib.h
+++ b/IntelFsp2WrapperPkg/Include/Library/FspWrapperApiLib.h
@@ -11,6 +11,28 @@
 
 #include 
 
+/**
+  Get the FSP M UPD Data address
+
+  @return FSP-M UPD Data Address
+**/
+UINTN
+EFIAPI
+GetFspmUpdDataAddress (
+  VOID
+  );
+
+/**
+  Get the FSP S UPD Data address
+
+  @return FSP-S UPD Data Address
+**/
+UINTN
+EFIAPI
+GetFspsUpdDataAddress (
+  VOID
+  );
+
 /**
   Find FSP header pointer.
 
diff --git 
a/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/BaseFspWrapperApiLib.inf 
b/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/BaseFspWrapperApiLib.inf
index 1e348b539f..82496eb300 100644
--- a/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/BaseFspWrapperApiLib.inf
+++ b/IntelFsp2WrapperPkg/Library/BaseFspWrapperApiLib/BaseFspWrapperApiLib.inf
@@ -63,3 +63,8 @@
 [Pcd]
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspmBaseAddress  ## CONSUMES
   gIntelFsp2WrapperTokenSpaceGuid.PcdFspsBaseAddress  ## CONSUMES
+  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress## CONSUMES
+  gIntelFsp2WrapperTokenSpaceGuid.PcdFspmUpdDataAddress64  ## CONSUMES
+

Re: [edk2-devel] [PATCH v4 7/8] PciHostBridgeDxe: Extend service to get base addresses before allocation

2022-02-04 Thread Gerd Hoffmann 
  Hi,

> -if (ResStatus == EFI_RESOURCE_SATISFIED) {
> +if ((ResStatus == EFI_RESOURCE_SATISFIED) ||
> +(ResStatus == PCI_RESOURCE_PARTIAL))
> +{

> +++ b/MdeModulePkg/Include/Library/PciResourceLib.h
> @@ -0,0 +1,20 @@
> +/** @file
> +  Pci resource library consumed by PciBusDxe and PciHostBridgeDxe drivers to
> +  share non-UEFI spec artefacts used in both drivers
> +
> +  Copyright 2022 Amazon.com, Inc. or its affiliates. All Rights Reserved.
> +
> +  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.
> + **/
> +#ifndef __PCI_RESOURCE_LIB_H__
> +#define __PCI_RESOURCE_LIB_H__
> +
> +#define PCI_RESOURCE_PARTIAL  0xFFFDULL
> +
> +#endif

Hmm, so you are hiding the #define here to avoid updating
Protocol/PciHostBridgeResourceAllocation.h ...

I suspect if this can't be implemented in the pci enumerator alone
there is just no way around actually extending uefi protocols.  But it's
also not fully clear to me why you need this new "partial" state.
Wouldn't you know either nothing or both base + size for a resource?

Also: Maybe split this series into two?  One for the host-provided
bridges, and another for the pre-populated bars?  So the former can
already be merged while the later is still sorted?

take care,
  Gerd



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#86388): https://edk2.groups.io/g/devel/message/86388
Mute This Topic: https://groups.io/mt/88893097/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-