[edk2] [RFC] Plan to delete ShellBinPkg from edk2/master

[Bi, Dandan]

Hi All,

ShellBinPkg is the remaining binary package in Edk2 repo.  We plan to delete 
ShellBinPkg from edk2/master, and keep source ShellPkg only in edk2 repo.
Before the deletion, I will update the existing consumers in Edk2 and 
Edk2Platforms to use ShellPkg directly.

If you have any concern please raise here before mid-April . If there is no 
concern, I will create patches for this task after mid-April.

Bugzilla for this task:
https://bugzilla.tianocore.org/show_bug.cgi?id=1675


Thanks,
Dandan
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix LoadImage/StartImage status code rep.

[Bi, Dandan]

Hi Laszlo,

Thanks for helping fix it.
Reviewed-by: Bi Dandan 


Thanks,
Dandan
> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Thursday, February 21, 2019 6:41 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Wu, Hao A ;
> Wang, Jian J ; Ni, Ray ; Sean
> Brogan ; Zeng, Star 
> Subject: [PATCH v3 1/5] MdeModulePkg/UefiBootManagerLib: fix
> LoadImage/StartImage status code rep.
> 
> In the EFI_RETURN_STATUS_EXTENDED_DATA structure from PI-1.7, there
> may be padding between the DataHeader and ReturnStatus members. The
> REPORT_STATUS_CODE_EX() macro starts populating the structure
> immediately after DataHeader, therefore the source data must provide for
> the padding.
> 
> Extract the BmReportLoadFailure() function from EfiBootManagerBoot(),
> prepare a zero padding (if any) in a temporary
> EFI_RETURN_STATUS_EXTENDED_DATA object, and fix the
> REPORT_STATUS_CODE_EX() macro invocation.
> 
> Cc: Dandan Bi 
> Cc: Hao Wu 
> Cc: Jian J Wang 
> Cc: Ray Ni 
> Cc: Sean Brogan 
> Cc: Star Zeng 
> Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1539
> Fixes: c2cf8720a5aad74230767a1f11bade2d86de3745
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Laszlo Ersek 
> ---
> 
> Notes:
> v3:
> 
> - rename BmReportImageFailure() to BmReportLoadFailure() [Ray]
> 
> - eliminate PaddingStart and PaddingSize; zero out the full ExtendedData
>   struct [Ray]
> 
> - don't pick up Ard's R-b due to the change above being functional in
>   nature
> 
> v2:
> - new in v2
> 
>  MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h |  1 +
>  MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c | 65
> ++--
>  2 files changed, 48 insertions(+), 18 deletions(-)
> 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> index 978fbff966f6..0fef63fceedf 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/InternalBm.h
> @@ -51,6 +51,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY
> KIND, EITHER EXPRESS OR IMPLIED.
>  #include   #include 
> #include 
> +#include 
>  #include 
> 
>  #include 
> diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> index 9be1633b7480..02ff354ef6a3 100644
> --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> @@ -1667,6 +1667,51 @@ BmIsBootManagerMenuFilePath (
>return FALSE;
>  }
> 
> +/**
> +  Report status code with EFI_RETURN_STATUS_EXTENDED_DATA about
> +LoadImage() or
> +  StartImage() failure.
> +
> +  @param[in] ErrorCode  An Error Code in the Software Class, DXE Boot
> +Service Driver Subclass. ErrorCode will be used 
> to
> +compose the Value parameter for status code
> +reporting. Must be one of
> +EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR and
> +EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED.
> +
> +  @param[in] FailureStatus  The failure status returned by the boot service
> +that should be reported.
> +**/
> +VOID
> +BmReportLoadFailure (
> +  IN UINT32 ErrorCode,
> +  IN EFI_STATUS FailureStatus
> +  )
> +{
> +  EFI_RETURN_STATUS_EXTENDED_DATA ExtendedData;
> +
> +  if (!ReportErrorCodeEnabled ()) {
> +return;
> +  }
> +
> +  ASSERT (
> +(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR) ||
> +(ErrorCode == EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
> +);
> +
> +  ZeroMem (, sizeof (ExtendedData));
> + ExtendedData.ReturnStatus = FailureStatus;
> +
> +  REPORT_STATUS_CODE_EX (
> +(EFI_ERROR_CODE | EFI_ERROR_MINOR),
> +(EFI_SOFTWARE_DXE_BS_DRIVER | ErrorCode),
> +0,
> +NULL,
> +NULL,
> + + 1,
> +sizeof (ExtendedData) - sizeof (ExtendedData.DataHeader)
> +);
> +}
> +
>  /**
>Attempt to boot the EFI boot option. This routine sets L"BootCurent" and
>also signals the EFI ready to boot event. If the device path for the option
> @@ -1822,15 +1867,7 @@ EfiBootManagerBoot (
>//
>// Report Status Code with the failure status to indicate that the 
> failure to
> load boot option
>//
> -  REPORT_STATUS_CODE_EX (
> -EFI_ERROR_CODE | EFI_ERROR_MINOR,
> -(EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
> -0,
> -NULL,
> -

Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when fail to load/start boot option

[Bi, Dandan]

Hi Laszlo,

Thanks for catching this issue.
I am sorry that I didn't consider the alignment issue when working on this 
patch.


Thanks,
Dandan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Wednesday, February 20, 2019 9:19 AM
> To: Bi, Dandan 
> Cc: Wu, Hao A ; Ni, Ray ; edk2-
> de...@lists.01.org
> Subject: Re: [edk2] [patch 2/2] MdeModulePkg/BmBoot: Report status when
> fail to load/start boot option
> 
> Hi Dandan,
> 
> On 02/15/19 09:51, Dandan Bi wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1398
> >
> > According to PI1.7 Spec, report extended data describing an EFI_STATUS
> > return value along with EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR
> and
> > EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED status code when fail to load
> or
> > start boot option image.
> >
> > Cc: Jian J Wang 
> > Cc: Hao Wu 
> > Cc: Ruiyu Ni 
> > Cc: Laszlo Ersek 
> > Cc: Sean Brogan 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Dandan Bi 
> > ---
> >  .../Library/UefiBootManagerLib/BmBoot.c   | 22 ++-
> >  1 file changed, 16 insertions(+), 6 deletions(-)
> >
> > diff --git a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > index 6444fb43eb..9be1633b74 100644
> > --- a/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > +++ b/MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c
> > @@ -1818,15 +1818,20 @@ EfiBootManagerBoot (
> >FreePool (FilePath);
> >  }
> >
> >  if (EFI_ERROR (Status)) {
> >//
> > -  // Report Status Code to indicate that the failure to load boot 
> > option
> > +  // Report Status Code with the failure status to indicate that
> > + the failure to load boot option
> >//
> > -  REPORT_STATUS_CODE (
> > +  REPORT_STATUS_CODE_EX (
> >  EFI_ERROR_CODE | EFI_ERROR_MINOR,
> > -(EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR)
> > +(EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_LOAD_ERROR),
> > +0,
> > +NULL,
> > +NULL,
> > +,
> > +sizeof (EFI_STATUS)
> >  );
> >BootOption->Status = Status;
> >//
> >// Destroy the RAM disk
> >//
> > @@ -1902,15 +1907,20 @@ EfiBootManagerBoot (
> >Status = gBS->StartImage (ImageHandle, >ExitDataSize,
> >ExitData);
> >DEBUG ((DEBUG_INFO | DEBUG_LOAD, "Image Return Status = %r\n",
> Status));
> >BootOption->Status = Status;
> >if (EFI_ERROR (Status)) {
> >  //
> > -// Report Status Code to indicate that boot failure
> > +// Report Status Code with the failure status to indicate that
> > + boot failure
> >  //
> > -REPORT_STATUS_CODE (
> > +REPORT_STATUS_CODE_EX (
> >EFI_ERROR_CODE | EFI_ERROR_MINOR,
> > -  (EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED)
> > +  (EFI_SOFTWARE_DXE_BS_DRIVER |
> EFI_SW_DXE_BS_EC_BOOT_OPTION_FAILED),
> > +  0,
> > +  NULL,
> > +  NULL,
> > +  ,
> > +  sizeof (EFI_STATUS)
> >);
> >}
> >PERF_END_EX (gImageHandle, "BdsAttempt", NULL, 0, (UINT32)
> > OptionNumber);
> >
> >//
> >
> 
> Unfortunately, this patch is not good; we made a mistake here.
> 
> Consider the EFI_RETURN_STATUS_EXTENDED_DATA structure, added in
> patch
> #1:
> 
> > typedef struct {
> >   ///
> >   /// The data header identifying the data:
> >   /// DataHeader.HeaderSize should be sizeof(EFI_STATUS_CODE_DATA),
> >   /// DataHeader.Size should be
> sizeof(EFI_RETURN_STATUS_EXTENDED_DATA) - HeaderSize,
> >   /// DataHeader.Type should be EFI_STATUS_CODE_SPECIFIC_DATA_GUID.
> >   ///
> >   EFI_STATUS_CODE_DATA DataHeader;
> >   ///
> >   /// The EFI_STATUS return value of the service or function whose failure
> triggered the
> >   /// reporting of the status code (generally an error code or a debug 
> > code).
> >   ///
> >   EFI_STATUS   ReturnStatus;
> > } EFI_RETURN_STATUS_EXTENDED_DATA;
> 
> According to the UEFI spec, unless specified otherwise, structure members
> are aligned naturally.
> 
> And, the PI spec references the UEFI spec with regard to data types.
> 
> Accordingly, when this structure is 

Re: [edk2] [patch V2] MdeModulePkg/ReportStatusCodeLib: Avoid using AllocatePool if possible

[Bi, Dandan]

> -Original Message-
> From: Zeng, Star
> Sent: Friday, February 15, 2019 5:25 PM
> To: Bi, Dandan ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Michael Turner
> ; Max Knutsen
> ; Gao, Liming ; Zeng,
> Star 
> Subject: RE: [edk2] [patch V2] MdeModulePkg/ReportStatusCodeLib: Avoid
> using AllocatePool if possible
> 
> After applying the patch, the author is Max and the Signed-off-by is Dandan,
> is it expected?
> 
> And the code below is better to be into the else condition (stack buffer is 
> not
> enough), right?
 Thanks for the comments.
  Yes, I agree. V3 patch has been sent for review. 

   Thanks,
   Dandan
> 
>   if (gBS == NULL || gBS->AllocatePool == NULL || gBS->FreePool == NULL) {
> return EFI_UNSUPPORTED;
>   }
> 
>   //
>   // Retrieve the current TPL
>   //
>   Tpl = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>   gBS->RestoreTPL (Tpl);
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Dandan Bi
> Sent: Thursday, February 14, 2019 10:39 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Michael Turner
> ; Max Knutsen
> ; Gao, Liming 
> Subject: [edk2] [patch V2] MdeModulePkg/ReportStatusCodeLib: Avoid
> using AllocatePool if possible
> 
> From: Max Knutsen 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1114
> 
> V2:  simplify the code logic.
> update
> if (!mHaveExitedBootServices &&
>   (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer)) {
>   gBS->FreePool (StatusCodeData);
> }
> to
> if (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer) {
>   gBS->FreePool (StatusCodeData);
> }
> 
> When report status code with ExtendedData data, and the extended data
> can fit in the local static buffer, there is no need to use AllocatePool to 
> hold
> the ExtendedData data.
> 
> This patch is just to do the enhancement to avoid using AllocatePool.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Michael Turner 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c | 9 +++--
>   .../RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c  | 9 +++--
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> b/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> index b28dc5c3bb..c88be5a1a3 100644
> ---
> a/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> +++
> b/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> @@ -505,13 +505,18 @@ ReportStatusCodeEx (
>//
>Tpl = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>gBS->RestoreTPL (Tpl);
> 
>StatusCodeData = NULL;
> -  if (Tpl <= TPL_NOTIFY) {
> +  if (ExtendedDataSize <= (MAX_EXTENDED_DATA_SIZE - sizeof
> + (EFI_STATUS_CODE_DATA))) {
>  //
> -// Allocate space for the Status Code Header and its buffer
> +// Use Buffer instead of allocating if possible.
> +//
> +StatusCodeData = (EFI_STATUS_CODE_DATA *)Buffer;  } else if (Tpl <=
> + TPL_NOTIFY){
> +//
> +// If Buffer is not big enough, allocate space for the Status Code
> + Header and its buffer
>  //
>  gBS->AllocatePool (EfiBootServicesData, sizeof (EFI_STATUS_CODE_DATA)
> + ExtendedDataSize, (VOID **));
>}
> 
>if (StatusCodeData == NULL) {
> diff --git
> a/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> odeLib.c
> b/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> odeLib.c
> index b73103517a..75e2f88ad2 100644
> ---
> a/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> odeLib.c
> +++
> b/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> od
> +++ eLib.c
> @@ -635,11 +635,14 @@ ReportStatusCodeEx (
>if (mHaveExitedBootServices) {
>  if (sizeof (EFI_STATUS_CODE_DATA) + ExtendedDataSize >
> MAX_EXTENDED_DATA_SIZE) {
>return EFI_OUT_OF_RESOURCES;
>  }
>  StatusCodeData = (EFI_STATUS_CODE_DATA *) StatusCodeBuffer;
> -  } else  {
> +  } else if (sizeof (EFI_STATUS_CODE_DATA) + ExtendedDataSize >
> MAX_EXTENDED_DATA_SIZE) {
> +//
> +// Only use AllocatePool for larger ExtendedData.
> +//
>  if (gBS == NULL || gBS->AllocatePool == NULL || gBS->FreePool == NULL) {
>return EFI_UNSUPPORTED;
>  }
> 
>  //
> @@ -648,10 +651,12 @@ ReportStatusCodeEx (
>  StatusCodeData = NULL;
>  gBS->AllocatePool (EfiBootServicesD

Re: [edk2] [patch V2] MdeModulePkg/ReportStatusCodeLib: Avoid using AllocatePool if possible

[Bi, Dandan]

This patch is also available at
 
https://github.com/dandanbi/edk2/commit/e5c432b2d5083c0bbadbf773d460a9c22d36b267


Thanks,
Dandan
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Dandan Bi
> Sent: Thursday, February 14, 2019 10:39 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Michael Turner
> ; Max Knutsen
> ; Gao, Liming 
> Subject: [edk2] [patch V2] MdeModulePkg/ReportStatusCodeLib: Avoid
> using AllocatePool if possible
> 
> From: Max Knutsen 
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1114
> 
> V2:  simplify the code logic.
> update
> if (!mHaveExitedBootServices &&
>   (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer)) {
>   gBS->FreePool (StatusCodeData);
> }
> to
> if (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer) {
>   gBS->FreePool (StatusCodeData);
> }
> 
> When report status code with ExtendedData data, and the extended data
> can fit in the local static buffer, there is no need to use AllocatePool to 
> hold
> the ExtendedData data.
> 
> This patch is just to do the enhancement to avoid using AllocatePool.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Michael Turner 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c | 9 +++--
>   .../RuntimeDxeReportStatusCodeLib/ReportStatusCodeLib.c  | 9 +++--
>  2 files changed, 14 insertions(+), 4 deletions(-)
> 
> diff --git
> a/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> b/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> index b28dc5c3bb..c88be5a1a3 100644
> ---
> a/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> +++
> b/MdeModulePkg/Library/DxeReportStatusCodeLib/ReportStatusCodeLib.c
> @@ -505,13 +505,18 @@ ReportStatusCodeEx (
>//
>Tpl = gBS->RaiseTPL (TPL_HIGH_LEVEL);
>gBS->RestoreTPL (Tpl);
> 
>StatusCodeData = NULL;
> -  if (Tpl <= TPL_NOTIFY) {
> +  if (ExtendedDataSize <= (MAX_EXTENDED_DATA_SIZE - sizeof
> + (EFI_STATUS_CODE_DATA))) {
>  //
> -// Allocate space for the Status Code Header and its buffer
> +// Use Buffer instead of allocating if possible.
> +//
> +StatusCodeData = (EFI_STATUS_CODE_DATA *)Buffer;  } else if (Tpl <=
> + TPL_NOTIFY){
> +//
> +// If Buffer is not big enough, allocate space for the Status Code
> + Header and its buffer
>  //
>  gBS->AllocatePool (EfiBootServicesData, sizeof (EFI_STATUS_CODE_DATA)
> + ExtendedDataSize, (VOID **));
>}
> 
>if (StatusCodeData == NULL) {
> diff --git
> a/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> odeLib.c
> b/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> odeLib.c
> index b73103517a..75e2f88ad2 100644
> ---
> a/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> odeLib.c
> +++
> b/MdeModulePkg/Library/RuntimeDxeReportStatusCodeLib/ReportStatusC
> od
> +++ eLib.c
> @@ -635,11 +635,14 @@ ReportStatusCodeEx (
>if (mHaveExitedBootServices) {
>  if (sizeof (EFI_STATUS_CODE_DATA) + ExtendedDataSize >
> MAX_EXTENDED_DATA_SIZE) {
>return EFI_OUT_OF_RESOURCES;
>  }
>  StatusCodeData = (EFI_STATUS_CODE_DATA *) StatusCodeBuffer;
> -  } else  {
> +  } else if (sizeof (EFI_STATUS_CODE_DATA) + ExtendedDataSize >
> MAX_EXTENDED_DATA_SIZE) {
> +//
> +// Only use AllocatePool for larger ExtendedData.
> +//
>  if (gBS == NULL || gBS->AllocatePool == NULL || gBS->FreePool == NULL) {
>return EFI_UNSUPPORTED;
>  }
> 
>  //
> @@ -648,10 +651,12 @@ ReportStatusCodeEx (
>  StatusCodeData = NULL;
>  gBS->AllocatePool (EfiBootServicesData, sizeof (EFI_STATUS_CODE_DATA)
> + ExtendedDataSize, (VOID **));
>  if (StatusCodeData == NULL) {
>return EFI_OUT_OF_RESOURCES;
>  }
> +  } else {
> +StatusCodeData = (EFI_STATUS_CODE_DATA *) StatusCodeBuffer;
>}
> 
>//
>// Fill in the extended data header
>//
> @@ -678,11 +683,11 @@ ReportStatusCodeEx (
>Status = InternalReportStatusCode (Type, Value, Instance, CallerId,
> StatusCodeData);
> 
>//
>// Free the allocated buffer
>//
> -  if (!mHaveExitedBootServices) {
> +  if (StatusCodeData != (EFI_STATUS_CODE_DATA *) StatusCodeBuffer) {
>  gBS->FreePool (StatusCodeData);
>}
> 
>return Status;
>  }
> --
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 01/14] OvmfPkg/MptScsiDxe: Create empty driver

[Bi, Dandan]

Hi Nikita,

I have one comment here, could you help to verify this patch series with VS 
tool chain build before commit the patches?


Thanks,
Dandan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Nikita Leshenko
> Sent: Thursday, January 31, 2019 6:07 PM
> To: edk2-devel@lists.01.org
> Cc: liran.a...@oracle.com
> Subject: [edk2] [PATCH 01/14] OvmfPkg/MptScsiDxe: Create empty driver
> 
> In preparation for implementing LSI Fusion MPT SCSI devices, create a basic
> scaffolding for a driver.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Nikita Leshenko 
> Reviewed-by: Konrad Rzeszutek Wilk 
> Reviewed-by: Aaron Young 
> Reviewed-by: Liran Alon 
> ---
>  OvmfPkg/MptScsiDxe/MptScsi.c  | 30 
>  OvmfPkg/MptScsiDxe/MptScsiDxe.inf | 33
> +++
>  OvmfPkg/OvmfPkgIa32.dsc   |  1 +
>  OvmfPkg/OvmfPkgIa32.fdf   |  1 +
>  OvmfPkg/OvmfPkgIa32X64.dsc|  1 +
>  OvmfPkg/OvmfPkgIa32X64.fdf|  1 +
>  OvmfPkg/OvmfPkgX64.dsc|  1 +
>  OvmfPkg/OvmfPkgX64.fdf|  1 +
>  8 files changed, 69 insertions(+)
>  create mode 100644 OvmfPkg/MptScsiDxe/MptScsi.c  create mode 100644
> OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> 
> diff --git a/OvmfPkg/MptScsiDxe/MptScsi.c
> b/OvmfPkg/MptScsiDxe/MptScsi.c new file mode 100644 index
> 00..73a693741d
> --- /dev/null
> +++ b/OvmfPkg/MptScsiDxe/MptScsi.c
> @@ -0,0 +1,30 @@
> +/** @file
> +
> +  This driver produces Extended SCSI Pass Thru Protocol instances for
> + LSI Fusion MPT SCSI devices.
> +
> +  Copyright (C) 2018, Oracle and/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.
> +
> +**/
> +
> +//
> +// Entry Point
> +//
> +
> +EFI_STATUS
> +EFIAPI
> +MptScsiEntryPoint (
> +  IN EFI_HANDLE   ImageHandle,
> +  IN EFI_SYSTEM_TABLE *SystemTable
> +  )
> +{
> +  return EFI_UNSUPPORTED;
> +}
> diff --git a/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> new file mode 100644
> index 00..c558d78034
> --- /dev/null
> +++ b/OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> @@ -0,0 +1,33 @@
> +## @file
> +# This driver produces Extended SCSI Pass Thru Protocol instances for #
> +LSI Fusion MPT SCSI devices.
> +#
> +# Copyright (C) 2018, Oracle and/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.
> +#
> +##
> +
> +[Defines]
> +  INF_VERSION= 0x00010005
> +  BASE_NAME  = MptScsiDxe
> +  FILE_GUID  = 2B3DB5DD-B315-4961-8454-0AFF3C811B19
> +  MODULE_TYPE= UEFI_DRIVER
> +  VERSION_STRING = 1.0
> +  ENTRY_POINT= MptScsiEntryPoint
> +
> +[Sources]
> +  MptScsi.c
> +
> +[Packages]
> +  MdePkg/MdePkg.dec
> +  OvmfPkg/OvmfPkg.dec
> +
> +[LibraryClasses]
> +  UefiDriverEntryPoint
> diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index
> aee19b75d7..52458859b6 100644
> --- a/OvmfPkg/OvmfPkgIa32.dsc
> +++ b/OvmfPkg/OvmfPkgIa32.dsc
> @@ -708,6 +708,7 @@
>OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>OvmfPkg/XenBusDxe/XenBusDxe.inf
>OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
>MdeModulePkg/Universal/WatchdogTimerDxe/WatchdogTimer.inf
> 
> MdeModulePkg/Universal/MonotonicCounterRuntimeDxe/MonotonicCoun
> terRuntimeDxe.inf
>MdeModulePkg/Universal/CapsuleRuntimeDxe/CapsuleRuntimeDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32.fdf b/OvmfPkg/OvmfPkgIa32.fdf index
> e013099136..73e36636e0 100644
> --- a/OvmfPkg/OvmfPkgIa32.fdf
> +++ b/OvmfPkg/OvmfPkgIa32.fdf
> @@ -233,6 +233,7 @@ INF  OvmfPkg/VirtioRngDxe/VirtioRng.inf
>  INF  OvmfPkg/XenIoPciDxe/XenIoPciDxe.inf
>  INF  OvmfPkg/XenBusDxe/XenBusDxe.inf
>  INF  OvmfPkg/XenPvBlkDxe/XenPvBlkDxe.inf
> +INF  OvmfPkg/MptScsiDxe/MptScsiDxe.inf
> 
>  !if $(SECURE_BOOT_ENABLE) == TRUE
>INF
> SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfi
> gDxe.inf
> diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
> index 90cbd8e341..d8ea2addb2 100644
> --- a/OvmfPkg/OvmfPkgIa32X64.dsc
> +++ 

Re: [edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if reloc info is invalid

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan
> -Original Message-
> From: Hsueh, Hong-chihX
> Sent: Wednesday, January 30, 2019 9:20 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> ; Bi, Dandan ; Laszlo Ersek
> 
> Subject: [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if reloc info
> is invalid
> 
> Skip runtime relocation for PE images that provide invalid relocation
> infomation (ex: RelocDir->Size = 0) to fix a hang observed while booting
> Windows.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Neo Hsueh 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> Cc: Laszlo Ersek 
> ---
>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 30
> --
>  1 file changed, 20 insertions(+), 10 deletions(-)
> 
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> index 1bd079ad6a..e2c62e1932 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> @@ -1002,7 +1002,7 @@ PeCoffLoaderRelocateImage (
>  
> RelocDir->VirtualAddress + RelocDir-
> >Size - 1,
>  
> TeStrippedOffset
>  
> );
> -if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd <
> RelocBase) {
> +if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN)
> + RelocBaseEnd < (UINTN) RelocBase) {
>ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
>return RETURN_LOAD_ERROR;
>  }
> @@ -1022,7 +1022,7 @@ PeCoffLoaderRelocateImage (
>  // Run the relocation information and apply the fixups
>  //
>  FixupData = ImageContext->FixupData;
> -while (RelocBase < RelocBaseEnd) {
> +while ((UINTN) RelocBase < (UINTN) RelocBaseEnd) {
> 
>Reloc = (UINT16 *) ((CHAR8 *) RelocBase + sizeof
> (EFI_IMAGE_BASE_RELOCATION));
>//
> @@ -1051,7 +1051,7 @@ PeCoffLoaderRelocateImage (
>//
>// Run this relocation record
>//
> -  while (Reloc < RelocEnd) {
> +  while ((UINTN) Reloc < (UINTN) RelocEnd) {
>  Fixup = PeCoffLoaderImageAddress (ImageContext, RelocBase-
> >VirtualAddress + (*Reloc & 0xFFF), TeStrippedOffset);
>  if (Fixup == NULL) {
>ImageContext->ImageError = IMAGE_ERROR_FAILED_RELOCATION;
> @@ -1739,13 +1739,23 @@ PeCoffLoaderRelocateImageForRuntime (
>// is present in the image. You have to check the NumberOfRvaAndSizes in
>// the optional header to verify a desired directory entry is there.
>//
> +  RelocBase = NULL;
> +  RelocBaseEnd = NULL;
>if (NumberOfRvaAndSizes > EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC) {
>  RelocDir  = DataDirectory + EFI_IMAGE_DIRECTORY_ENTRY_BASERELOC;
> -RelocBase = (EFI_IMAGE_BASE_RELOCATION *)
> PeCoffLoaderImageAddress (, RelocDir->VirtualAddress, 0);
> -RelocBaseEnd  = (EFI_IMAGE_BASE_RELOCATION *)
> PeCoffLoaderImageAddress (,
> -
> RelocDir->VirtualAddress + RelocDir-
> >Size - 1,
> -0
> -
> );
> +if ((RelocDir != NULL) && (RelocDir->Size > 0)) {
> +  RelocBase = (EFI_IMAGE_BASE_RELOCATION *)
> PeCoffLoaderImageAddress (, RelocDir->VirtualAddress, 0);
> +  RelocBaseEnd  = (EFI_IMAGE_BASE_RELOCATION *)
> PeCoffLoaderImageAddress (,
> + 
>  RelocDir->VirtualAddress + RelocDir-
> >Size - 1,
> + 
>  0
> + 
>  );
> +}
> +if (RelocBase == NULL || RelocBaseEnd == NULL || (UINTN) RelocBaseEnd
> < (UINTN) RelocBase) {
> +  //
> +  // relocation block is not valid, just return
> +  //
> +  return;
> +}
>} else {
>  //
>  // Cannot find relocations, cannot continue to relocate the image, ASSERT
> for this invalid image.
> @@ -1769,7 +1779,7 @@ PeCoffLoaderRelocateImageForRuntime (
>  //
>  FixupData = RelocationData;
>  RelocBaseOrig = RelocBase;
> -while (RelocBase < RelocBaseEnd) {
> +while ((UINTN) RelocB

Re: [edk2] [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if relocation info is invalid.

[Bi, Dandan]

Hi Neo,

Thank you very much for the patch.

Some minor comments
1) Besides the skip check in this patch, could you help to add additional  
check for RelocDir->Size before calling PeCoffLoaderImageAddress to calculate 
the RelocBase and RelocBaseEnd?
Since when RelocDir->Size==0, we can just return, don't need to do the 
calculation.

2) Please use the PatchCheck.py in edk2\BaseTools\Scripts to check the patch 
format before committing  the patch.
Can refer following link for more info:
https://github.com/tianocore/tianocore.github.io/wiki/Commit-Message-Format


Thanks,
Dandan

> -Original Message-
> From: Hsueh, Hong-chihX
> Sent: Tuesday, January 29, 2019 2:41 AM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D ; Gao, Liming
> ; Bi, Dandan ; Laszlo Ersek
> 
> Subject: [PATCH] MdePkg/BasePeCoffLib: skip runtime relocation if
> relocation info is invalid.
> 
> Skip runtime relocation for PE images that provide invalid relocation
> infomation
> (ex: RelocDir->Size = 0) to fix a hang observed while booting Windows.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> 
> Signed-off-by: Neo Hsueh 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Cc: Dandan Bi 
> Cc: Laszlo Ersek 
> ---
>  MdePkg/Library/BasePeCoffLib/BasePeCoff.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> index 1bd079ad6a..f01c691dea 100644
> --- a/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> +++ b/MdePkg/Library/BasePeCoffLib/BasePeCoff.c
> @@ -1746,6 +1746,12 @@ PeCoffLoaderRelocateImageForRuntime (
>  
> RelocDir->VirtualAddress + RelocDir-
> >Size - 1,
>  0
>  
> );
> +if (RelocBase == NULL || RelocBaseEnd == NULL || RelocBaseEnd <
> RelocBase) {
> +  //
> +  // relocation block is not valid, just return
> +  //
> +  return;
> +}
>} else {
>  //
>  // Cannot find relocations, cannot continue to relocate the image, ASSERT
> for this invalid image.
> --
> 2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/MdeModulePkg.dsc: ignore standalone MM modules for EBC or XCODE5

[Bi, Dandan]

Reviewed-by: Bi Dandan 


Thanks,
Dandan

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Ard Biesheuvel
> Sent: Friday, January 25, 2019 4:12 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Gao, Liming 
> Subject: [edk2] [PATCH] MdeModulePkg/MdeModulePkg.dsc: ignore
> standalone MM modules for EBC or XCODE5
> 
> The newly added standalone MM versions of the FTW and variable runtime
> drivers were included in MdeModulePkg.dsc to get test coverage when
> building the package from its own .dsc, but the resulting modules are non-
> functional since they incorporate some dummy libraries.
> 
> Dandan reports that these modules don't build cleanly when using the EBC or
> XCODE5 compilers, so given the above, let's just ignore them in this case.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Ard Biesheuvel 
> ---
>  MdeModulePkg/MdeModulePkg.dsc | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.dsc
> b/MdeModulePkg/MdeModulePkg.dsc index 93eaf4b404a1..55eca4d74c04
> 100644
> --- a/MdeModulePkg/MdeModulePkg.dsc
> +++ b/MdeModulePkg/MdeModulePkg.dsc
> @@ -426,9 +426,6 @@ [Components]
>MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.inf
>MdeModulePkg/Library/DxeCapsuleLibFmp/DxeRuntimeCapsuleLib.inf
> 
> -
> MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStanda
> loneMm.inf
> -
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> -
>  [Components.IA32, Components.X64, Components.AARCH64]
>MdeModulePkg/Universal/EbcDxe/EbcDxe.inf
>MdeModulePkg/Universal/EbcDxe/EbcDebugger.inf
> @@ -442,6 +439,11 @@ [Components.IA32, Components.X64,
> Components.ARM, Components.AARCH64]
> 
> NULL|MdeModulePkg/Library/DxeCrc32GuidedSectionExtractLib/DxeCrc32G
> uidedSectionExtractLib.inf
>}
> 
> +!if $(TOOL_CHAIN_TAG) != "XCODE5"
> +
> +MdeModulePkg/Universal/FaultTolerantWriteDxe/FaultTolerantWriteStan
> dalo
> +neMm.inf
> +
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> +!endif
> +
>  [Components.IA32, Components.X64, Components.Ebc]
> 
> MdeModulePkg/Universal/Variable/EmuRuntimeDxe/EmuVariableRuntime
> Dxe.inf
> 
> --
> 2.17.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg VariableStandaloneMm: Add PcdEmuVariableNvModeEnable in inf

[Bi, Dandan]

Reviewed-by: Bi Dandan 


Thanks,
Dandan
> -Original Message-
> From: Zeng, Star
> Sent: Friday, January 25, 2019 9:23 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star ; Wang, Jian J ;
> Wu, Hao A ; Ard Biesheuvel
> ; Bi, Dandan 
> Subject: [PATCH] MdeModulePkg VariableStandaloneMm: Add
> PcdEmuVariableNvModeEnable in inf
> 
> It was missed in 7cd69959463ac9c761163ed8e8a93907b68e70da when
> rebasing the patches after 688b2cad7b712493f2cf8b6948ab795545e13961
> added VariableStandaloneMm.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Cc: Ard Biesheuvel 
> Cc: Dandan Bi 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Star Zeng 
> ---
> 
> MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.inf
> | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.i
> nf
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.
> inf
> index efb84ed87832..07436d3cb6ae 100644
> ---
> a/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.i
> nf
> +++
> b/MdeModulePkg/Universal/Variable/RuntimeDxe/VariableStandaloneMm.
> in
> +++ f
> @@ -18,7 +18,7 @@
>  #  may not be modified without authorization. If platform fails to protect
> these resources,  #  the authentication service provided in this driver will 
> be
> broken, and the behavior is undefined.
>  #
> -# Copyright (c) 2010 - 2016, Intel Corporation. All rights reserved.
> +# Copyright (c) 2010 - 2019, Intel Corporation. All rights
> +reserved.
>  # Copyright (c) 2018, Linaro, Ltd. All rights reserved.  # This program 
> and
> the accompanying materials  # are licensed and made available under the
> terms and conditions of the BSD License @@ -127,6 +127,8 @@ [FixedPcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdMaxUserNvVariableSpaceSize
> ## CONSUMES
> 
> gEfiMdeModulePkgTokenSpaceGuid.PcdBoottimeReservedNvVariableSpace
> Size  ## CONSUMES
>gEfiMdeModulePkgTokenSpaceGuid.PcdReclaimVariableSpaceAtEndOfDxe
> ## CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvModeEnable
> ## SOMETIMES_CONSUMES
> +  gEfiMdeModulePkgTokenSpaceGuid.PcdEmuVariableNvStoreReserved
> ## SOMETIMES_CONSUMES
> 
>  [FeaturePcd]
>gEfiMdeModulePkgTokenSpaceGuid.PcdVariableCollectStatistics##
> CONSUMES  # statistic the information of variable.
> --
> 2.13.3.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Unable to boot Linux with master EDK2

[Bi, Dandan]

Hi Julien Grall

I have committed the fix patch. 
https://github.com/tianocore/edk2/commit/eb76b76218d5bac867414e2ff6dd09c6e7c700dd

Please trying the latest EDK2 master.


Thanks,
Dandan 

> -Original Message-
> From: Julien Grall [mailto:julien.gr...@arm.com]
> Sent: Saturday, January 19, 2019 2:30 AM
> To: edk2-devel-01 ; Bi, Dandan
> ; Gao, Liming 
> Cc: Leif Lindholm ; Ard Biesheuvel
> ; Laszlo Ersek ; Kinney,
> Michael D ; xen-devel  de...@lists.xenproject.org>
> Subject: Unable to boot Linux with master EDK2
> 
> Hi all,
> 
> I am trying to boot a Xen guest using the latest EDK2 master (cce9d76358
> "BaseTools: Allow empty value for HiiPcd in Dsc"), GRUB and Linux 5.0-rc2.
> 
> The last code executed by Linux is when installing the virtual address map in
> the EFI stub and then it seems to get stuck. I don't have much information
> from the console:
> 
> InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7E041040
> Loading driver at 0x00068C7 EntryPoint=0x00069D65664 Loading driver at
> 0x00068C7 EntryPoint=0x00069D65664
> InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DF6AB18
> ProtectUefiImageCommon - 0x7E041040
>   - 0x68C7 - 0x02006000
> SetUefiImageMemoryAttributes - 0x68C7 -
> 0x1000 (0x4008) SetUefiImageMemoryAttributes
> - 0x68C71000 - 0x011CD000 (0x00020008)
> SetUefiImageMemoryAttributes - 0x69E3E000 -
> 0x00E38000 (0x4008) EFI stub: Booting Linux Kernel...
> EFI stub: Using DTB from configuration table EFI stub: Exiting boot services
> and installing virtual address map...
> XenBus: Set state to 5
> XenBus: Set state to 5, done
> XenPvBlk: waiting backend state 5, current: 4
> XenStore: Watch event 7E957398
> XenBus: Set state to 6
> XenBus: Set state to 6, done
> XenPvBlk: waiting backend state 6, current: 5
> XenStore: Watch event 7E957398
> XenBus: Set state to 1
> XenBus: Set state to 1, done
> Xen GrantTable, removing 38003
> Xen GrantTable, removing 38002
> Xen GrantTable, removing 38001
> Xen GrantTable, removing 38000
> SetUefiImageMemoryAttributes - 0x7F36 -
> 0x0004 (0x0008) SetUefiImageMemoryAttributes
> - 0x7BFF - 0x0004 (0x0008)
> SetUefiImageMemoryAttributes - 0x7BFA -
> 0x0004 (0x0008) SetUefiImageMemoryAttributes
> - 0x7BF0 - 0x0004 (0x0008)
> SetUefiImageMemoryAttributes - 0x7BE6 -
> 0x0004 (0x0008) SetUefiImageMemoryAttributes
> - 0x7BDC - 0x0004 (0x0008)
> 
> The bisector pointed to the following commit:
> 
> commit 2f4a5a9f4c17ed88aaa3114d1e161e42cb80a9bf
> Author: Dandan Bi 
> Date:   Thu Jan 3 15:31:23 2019 +0800
> 
> MdePkg/BasePeCoffLib: Add more check for relocation data
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1426
> 
> V2:
> (1) Add NULL pointer check for the input parameters
> (2) Add check for the "Adjust" value before applying fix ups.
> 
> In function PeCoffLoaderRelocateImageForRuntime, it doesn't
> do much check when do relocation. For API level consideration,
> it's not safe enough.
> So this patch is to replace the same code logic with function
> PeCoffLoaderImageAddress which will cover more validation.
> 
> Cc: Michael D Kinney 
> Cc: Liming Gao 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> Reviewed-by: Liming Gao 
> 
> Any ideas what could have gone wrong?
> 
> Best regards,
> 
> --
> Julien Grall
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RESEND PATCH v2 2/6] efi_loader: Initial HII database protocols

[Bi, Dandan]

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Leif Lindholm
> Sent: Tuesday, January 08, 2019 5:51 PM
> To: Laszlo Ersek 
> Cc: Ni, Ray ; tr...@konsulko.com; AKASHI Takahiro
> ; Wu, Hao A ; Heinrich
> Schuchardt ; edk2-devel@lists.01.org; Alexander
> Graf ; Gao, Liming ; u-
> b...@lists.denx.de; robdcl...@gmail.com; Kinney, Michael D
> ; Zeng, Star 
> Subject: Re: [edk2] [RESEND PATCH v2 2/6] efi_loader: Initial HII database
> protocols
> 
> MdePkg/MdeModulePkg maintainers - any comments?
> 
> On Tue, Jan 08, 2019 at 01:28:00AM +0100, Laszlo Ersek wrote:
> > On 01/07/19 20:22, Leif Lindholm wrote:
> > > On Mon, Jan 07, 2019 at 07:29:47PM +0100, Laszlo Ersek wrote:
> >
> > >> The UEFI spec (v2.7) explicitly requires EFI_GUID to be 64-bit
> > >> aligned, unless specified otherwise. See in "Table 5. Common UEFI Data
> Types":
> > >>
> > >>   EFI_GUID -- 128-bit buffer containing a unique identifier value.
> > >>   Unless otherwise specified, aligned on a 64-bit
> > >>   boundary.
> > >
> > > Indeed.
> > >
> > >> Whether edk2 satisfies that, and if so, how (by chance / by general
> > >> build flags), I don't know. The code says,
> > >>
> > >> ///
> > >> /// 128 bit buffer containing a unique identifier value.
> > >> /// Unless otherwise specified, aligned on a 64 bit boundary.
> > >> ///
> > >> typedef struct {
> > >>   UINT32  Data1;
> > >>   UINT16  Data2;
> > >>   UINT16  Data3;
> > >>   UINT8   Data4[8];
> > >> } GUID;
> > >>
> > >> I think there may have been an expectation in
> "MdePkg/Include/Base.h"
> > >> that the supported compilers would automatically ensure the
> > >> specified alignment, given the structure definition.
> > >
> > > But that would be expecting things not only not guaranteed by C, but
> > > something there is no semantic information suggesting would be
> > > useful for the compiler to do above. [...]
> >
> > Agreed. I'm not saying the edk2 code is right, just guessing why the
> > code might look like it does. This would not be the first silent
> > assumption, I think.
> >
> > Anyhow, I think it would be better to change the code than the spec.
> 
> Of course it would be better to change the code than the spec.
> 
> But as Ard points out off-thread, doing (as a hack, with gcc)
> 
> diff --git a/MdePkg/Include/Uefi/UefiBaseType.h
> b/MdePkg/Include/Uefi/UefiBaseType.h
> index 8c9d571eb1..75409f3460 100644
> --- a/MdePkg/Include/Uefi/UefiBaseType.h
> +++ b/MdePkg/Include/Uefi/UefiBaseType.h
> @@ -26,7 +26,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF
> ANY KIND, EITHER EXPRESS OR IMPLIED.
>  ///
>  /// 128-bit buffer containing a unique identifier value.
>  ///
> -typedef GUID  EFI_GUID;
> +typedef GUID  EFI_GUID __attribute__((aligned (8)));
>  ///
>  /// Function return status for EFI API.
>  ///
> 
> breaks Linux boot on ARM (32-bit), since it inserts 32-bits of padding
> between ConfigurationTable entries in the system table. So I don't see how
> that can realistically be fixed in the EDK2 codebase.
> 
> And with things like the EFI_HII_KEYBOARD_LAYOUT struct, if there has ever
> been compatibility between EDK2 and commercial BIOSes, then that struct
> has always been treated as packed (not just 32-bit aligned GUIDs), and the
> spec just needs to reflect reality. If there hasn't, then indeed the code
> change here would be trivial.

The structure definitions in Include/Uefi/UefiInternalFormRepresentation.h 
mainly describe the binary encoding of the different package types. And 
EFI_HII_KEYBOARD_LAYOUT struct is for the Keyboard Layout Package. 
Describing  the *binary encoding* of the different package type, so I think we 
should treat them as packed and it also should be the reason why they are 
packed now.  Maybe we can reflect this more clear in Spec.

> 
> (Adding Liming as well, since we're now discussing MdePkg also.)
> 
> Yes, this discussion belongs on USWG (UEFI specification working group
> mailing list), but I want to hear some comment from the package
> maintainers first.
> 
> Either way, I see a bunch of new SCT tests coming up.
> 
> /
> Leif
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT build failure

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan
> -Original Message-
> From: Wu, Hao A
> Sent: Friday, January 4, 2019 10:42 AM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Bi, Dandan ;
> Wang, Jian J ; Ni, Ray 
> Subject: [PATCH] MdeModulePkg/SdMmcPciHcDxe: Fix VS2015 IA32 NOOPT
> build failure
> 
> REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1425
> 
> This commit will resolve the VS2015 IA32 NOOPT build failure within
> SdMmcPciHcDxe.
> 
> More specifically, this commit will use BaseLib API RShiftU64() to perform
> right-shift operations for UINT64 type operators.
> 
> Cc: Dandan Bi 
> Cc: Jian J Wang 
> Cc: Ruiyu Ni 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Hao Wu 
> ---
>  MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> index 6086720fa1..5aec8c6992 100644
> --- a/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> +++ b/MdeModulePkg/Bus/Pci/SdMmcPciHcDxe/SdMmcPciHci.c
> @@ -1505,7 +1505,7 @@ BuildAdmaDescTable (
>  Trb->Adma32Desc[Index].Valid = 1;
>  Trb->Adma32Desc[Index].Act   = 2;
>  if (DataLength26) {
> -  Trb->Adma32Desc[Index].UpperLength = (UINT16)(Remaining >> 16);
> +  Trb->Adma32Desc[Index].UpperLength = (UINT16)RShiftU64
> + (Remaining, 16);
>  }
>  Trb->Adma32Desc[Index].LowerLength = (UINT16)(Remaining &
> MAX_UINT16);
>  Trb->Adma32Desc[Index].Address = (UINT32)Address; @@ -1524,11
> +1524,11 @@ BuildAdmaDescTable (
>  Trb->Adma64Desc[Index].Valid = 1;
>  Trb->Adma64Desc[Index].Act   = 2;
>  if (DataLength26) {
> -  Trb->Adma64Desc[Index].UpperLength  = (UINT16)(Remaining >> 16);
> +  Trb->Adma64Desc[Index].UpperLength  = (UINT16)RShiftU64
> + (Remaining, 16);
>  }
>  Trb->Adma64Desc[Index].LowerLength  = (UINT16)(Remaining &
> MAX_UINT16);
>  Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64
> + (Address, 32);
>  break;
>} else {
>  Trb->Adma64Desc[Index].Valid = 1; @@ -1538,7 +1538,7 @@
> BuildAdmaDescTable (
>  }
>  Trb->Adma64Desc[Index].LowerLength  = 0;
>  Trb->Adma64Desc[Index].LowerAddress = (UINT32)Address;
> -Trb->Adma64Desc[Index].UpperAddress = (UINT32)(Address >> 32);
> +Trb->Adma64Desc[Index].UpperAddress = (UINT32)RShiftU64
> + (Address, 32);
>}
>  }
> 
> --
> 2.12.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/NonDiscoverable: Use compare operator for comparison

[Bi, Dandan]

Hi Star,

Thank you for your suggestion. 
I will send a new patch with your suggestion.


Thanks,
Dandan

> -Original Message-
> From: Zeng, Star
> Sent: Tuesday, January 1, 2019 9:17 PM
> To: Bi, Dandan ; edk2-devel@lists.01.org
> Cc: Wu, Hao A ; Vladimir Olovyannikov
> ; Ard Biesheuvel
> ; Zeng, Star 
> Subject: RE: [edk2] [patch] MdeModulePkg/NonDiscoverable: Use compare
> operator for comparison
> 
>   if (Attributes) {
>   if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) {
> return EFI_UNSUPPORTED;
>   }
> }
> 
> If ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) is TRUE, the
> Attributes must be not 0.
> So " if (Attributes " could be removed.
> 
> BTW: This code block has indentation problem.
> 
> 
> With them handled, Reviewed-by: Star Zeng 
> 
> 
> Thanks,
> Star
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Dandan Bi
> Sent: Friday, December 28, 2018 4:54 PM
> To: edk2-devel@lists.01.org
> Cc: Wu, Hao A 
> Subject: [edk2] [patch] MdeModulePkg/NonDiscoverable: Use compare
> operator for comparison
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1422
> 
> According to EDK II C Coding Standards Specification, Non-Boolean
> comparisons must use a compare operator.
> This patch is to update the code to follow EDKII coding style.
> 
> Cc: Jian J Wang 
> Cc: Hao Wu 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  .../NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c| 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> index f0d3472ea5..a0fe3b9ffa 100644
> ---
> a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> PciDeviceIo.c
> +++
> b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverable
> Pc
> +++ iDeviceIo.c
> @@ -1274,11 +1274,11 @@ PciIoAttributes (
>#define DEV_SUPPORTED_ATTRIBUTES \
>  (EFI_PCI_DEVICE_ENABLE |
> EFI_PCI_IO_ATTRIBUTE_DUAL_ADDRESS_CYCLE)
> 
>Dev = NON_DISCOVERABLE_PCI_DEVICE_FROM_PCI_IO(This);
> 
> -  if (Attributes) {
> +  if (Attributes != 0) {
>if ((Attributes & (~(DEV_SUPPORTED_ATTRIBUTES))) != 0) {
>  return EFI_UNSUPPORTED;
>}
>  }
> 
> --
> 2.18.0.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] ModuleWriteGuide: Add notes to define library instance module type

[Bi, Dandan]

Hi Liming,

Some minor comments inline.

Thanks,
Dandan

> -Original Message-
> From: Gao, Liming
> Sent: Wednesday, December 5, 2018 11:59 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan 
> Subject: [Patch] ModuleWriteGuide: Add notes to define library instance
> module type
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=834
> If the library instance supports the cross module types PEIM, UEFI_DIRVER,
> DXE_DRIVER. Its module type can be PEIM or UEFI_DRIVER or DXE_DRIVER.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Bi Dandan 
> ---
>  3_module_development/31_what_is_an_edk_ii_module.md | 2 ++
>  3_module_development/32_creating_a_module.md| 5 +
>  2 files changed, 7 insertions(+)
> 
> diff --git a/3_module_development/31_what_is_an_edk_ii_module.md
> b/3_module_development/31_what_is_an_edk_ii_module.md
> index ace8d53..9f0fe8d 100644
> --- a/3_module_development/31_what_is_an_edk_ii_module.md
> +++ b/3_module_development/31_what_is_an_edk_ii_module.md
> @@ -78,6 +78,8 @@ EDK II defines many module types. The module type is
> used to:
>example, a PEIM/DXE_DRIVER type module can have "depex" section in .efi
>binary image; a UEFI_DRIVER can have .ui or .ver section in .efi binary 
> image;
> 
> +* Indicate EntryPoint() or Constructor() API for different types of modules.
How about  "Indicate different prototypes of EntryPoint() or Constructor() API 
for different types of modules"?
> +
>  * Indicate the suitable library instance for different types of modules. A
>library instance will point out what module types are supported in INF 
> file.
> 
> diff --git a/3_module_development/32_creating_a_module.md
> b/3_module_development/32_creating_a_module.md
> index 65a4ac7..325156f 100644
> --- a/3_module_development/32_creating_a_module.md
> +++ b/3_module_development/32_creating_a_module.md
> @@ -197,6 +197,11 @@ instance:
>DebugLib
>  ```
> 
> +Note: if the library supports the cross module types PEIM, UEFI_DIRVER,
> DXE_DRIVER.
> +Its module type can be PEIM or UEFI_DRIVER or DXE_DRIVER. If it has the
> +library constructor, its module type must be BASE. BASE type library
> +constructor has no the input parameter that can link to the cross driver
> types.
How about "BASE type library constructor has no input parameter that can be 
linked to any type of cross driver"?

If  you agree the updates, please update them before commit, not require V2 
patch.
> +
>  ### 3.2.3 Adding a Package Dependency
> 
>  The [Packages] section of the INF file describes all packages dependencies of
> --
> 2.13.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, November 29, 2018 9:18 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Zeng, Star 
> Subject: [Patch] MdeModulePkg: Correct PCD name in MdeModulePkg.uni
> 
> https://bugzilla.tianocore.org/show_bug.cgi?id=1363
> New PCD PcdVpdBaseAddress64 is added in MdeModulePkg.dec.
> Its string token in MdeModulePkg.uni should match to its name.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Bi Dandan 
> Cc: Star Zeng 
> ---
>  MdeModulePkg/MdeModulePkg.uni | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/MdeModulePkg.uni
> b/MdeModulePkg/MdeModulePkg.uni index 9b1766b36a..c754d7bb15
> 100644
> --- a/MdeModulePkg/MdeModulePkg.uni
> +++ b/MdeModulePkg/MdeModulePkg.uni
> @@ -1261,9 +1261,9 @@
>   
>  "On TRUE, the string FPDT
> record will be used to store every performance entry.\n"
>   
>  "On FALSE, the different
> FPDT record will be used to store the different performance entries."
> 
> -#string
> STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_PROMPT
> #language en-US "64bit VPD base address"
> +#string
> STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_PROMPT
> #language en-US "64bit VPD base address"
> 
> -#string
> STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress_HELP
> #language en-US "VPD type PCD allows a developer to point to an absolute
> physical address PcdVpdBaseAddress64"
> +#string
> STR_gEfiMdeModulePkgTokenSpaceGuid_PcdVpdBaseAddress64_HELP
> #language en-US "VPD type PCD allows a developer to point to an absolute
> physical address PcdVpdBaseAddress64"
>   
>   "to store PCD value. It will be
> DynamicExDefault only."
>   
>   "It is used to set VPD region base
> address. So, it can't be DynamicExVpd PCD. Its value is"
>   
>   "required to be accessed in PcdDxe
> driver entry point. So, its value must be set in PEI phase."
> --
> 2.13.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] Revert "MdeModulePkg/DisplayEngine: Remove useless NULL ptr check for NewPos"

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan

> -Original Message-
> From: Gao, Liming
> Sent: Saturday, November 10, 2018 10:16 PM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan 
> Subject: [Patch] Revert "MdeModulePkg/DisplayEngine: Remove useless
> NULL ptr check for NewPos"
> 
> This reverts commit 8cd4e734ccdfbc961c72aeaa8dbd3f5154171f9b.
> 
> It is not a real bug fix. It should not be pushed after Hard Feature Freeze 
> for
> edk2-stable201811 tag.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Liming Gao 
> Cc: Dandan Bi 
> ---
>  MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> index 44f087fe01..7390f954b6 100644
> --- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> +++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
> @@ -2882,7 +2882,6 @@ UiDisplayMenu (
>//
>ControlFlag = CfUpdateHelpString;
> 
> -  ASSERT (NewPos != NULL);
>UpdateHighlightMenuInfo(NewPos, TopOfScreen, SkipValue);
> 
>if (SkipHighLight) {
> @@ -2911,7 +2910,7 @@ UiDisplayMenu (
>  Temp2 = 0;
>}
> 
> -  if (MenuOption == NULL || NewPos != >Link) {
> +  if (NewPos != NULL && (MenuOption == NULL || NewPos !=
> + >Link)) {
>  if (MenuOption != NULL) {
>//
>// Remove the old highlight menu.
> --
> 2.13.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdePkg: Fix incorrect check for DisplayOnly text format in AcpiEx

[Bi, Dandan]

Hi Stewards and package maintainers:

Since this is a clear bug.  And the risk for this release is small.
So I plan to push this patch before edk2-stable201811 tag is created.

If you have any concern, please raise here. 


Thanks,
Dandan

> -Original Message-
> From: Gao, Liming
> Sent: Thursday, November 8, 2018 9:56 PM
> To: Bi, Dandan ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Kinney, Michael D
> 
> Subject: RE: [patch] MdePkg: Fix incorrect check for DisplayOnly text format
> in AcpiEx
> 
> Reviewed-by: Liming Gao 
> 
> > -----Original Message-
> > From: Bi, Dandan
> > Sent: Thursday, November 8, 2018 9:50 PM
> > To: edk2-devel@lists.01.org
> > Cc: Ni, Ruiyu ; Kinney, Michael D
> > ; Gao, Liming 
> > Subject: [patch] MdePkg: Fix incorrect check for DisplayOnly text
> > format in AcpiEx
> >
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1312
> >
> > Text format for AcpiEx device path in UEFI Spec:
> > AcpiEx(HID,CID,UID,HIDSTR,CIDSTR,UIDSTR)
> > AcpiEx(HID|HIDSTR,(CID|CIDSTR,UID|UIDSTR))(Display Only)
> >
> > When convert device path to text for ACPI device path, current code
> > check AllowShortcuts parameter to convert the device path to
> > DisplayOnly text format(shorter text
> > representation) by mistake.
> > It should check DisplayOnly parameter.
> >
> > This commit is to fix this issue.
> >
> > Cc: Ruiyu Ni 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Dandan Bi 
> > ---
> >  MdePkg/Library/UefiDevicePathLib/DevicePathToText.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > index cdcdb3623a..97d279eeb2 100644
> > --- a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > @@ -495,11 +495,11 @@ DevPathToTextAcpiEx (
> >  CIDText,
> >  UIDStr
> > );
> >  }
> >} else {
> > -if (AllowShortcuts) {
> > +if (DisplayOnly) {
> >//
> >// display only
> >//
> >if (AcpiEx->HID == 0) {
> >  UefiDevicePathLibCatPrint (Str, L"AcpiEx(%a,", HIDStr);
> > --
> > 2.18.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: correct one coding style

[Bi, Dandan]

Reviewed-by: Bi Dandan 

Thanks,
Dandan

> -Original Message-
> From: Wang, Jian J
> Sent: Saturday, October 27, 2018 10:13 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Zeng, Star 
> Subject: [PATCH] MdeModulePkg/Core: correct one coding style
> 
> REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1284
> 
> Non-Boolean comparisons should use a compare operator (==, !=, >, < >=, <=)
> 
> Cc: Dandan Bi 
> Cc: Star Zeng 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  MdeModulePkg/Core/Dxe/Mem/HeapGuard.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> index 521e0d7b2a..9f89df8d8f 100644
> --- a/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> +++ b/MdeModulePkg/Core/Dxe/Mem/HeapGuard.c
> @@ -1559,7 +1559,7 @@ PromoteGuardedFreePages (
>  }
>}
> 
> -  if (AvailablePages) {
> +  if (AvailablePages != 0) {
>  DEBUG ((DEBUG_INFO, "Promoted pages: %lX (%lx)\r\n", Start,
> (UINT64)AvailablePages));
>  ClearGuardedMemoryBits (Start, AvailablePages);
> 
> --
> 2.19.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure convention for checkbox

[Bi, Dandan]

> -Original Message-
> From: Ni, Ruiyu
> Sent: Tuesday, October 9, 2018 10:07 AM
> To: Laszlo Ersek ; Bi, Dandan ;
> edk2-devel@lists.01.org
> Cc: Gao, Liming ; Zeng, Star 
> Subject: Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure
> convention for checkbox
> 
> On 10/8/2018 11:15 PM, Laszlo Ersek wrote:
> > On 10/08/18 16:32, Bi, Dandan wrote:
> >>>
> >>> what were the practical consequences (symptoms) of this issue? Did
> >>> some checkboxes not work? (I'm asking because SecureBootConfigDxe
> >>> uses some
> >>> checkboxes.)
> >>
> >> 1.  The bug is in function "UpdateDefaultSettingInFormPackage()" which is
> to update the default setting of some HII Questions in the IFR binary data. So
> it only has impact when platform overrides default setting in HII VarStore
> through DynamicHii PCD setting in Platform DSC file. If platform doesn't
> override default setting, it has no impact.
> >>
> >> 2. The implementation updates the "Flags" filed in the EFI_IFR_CHECKBOX
> structure to update the default setting of checkbox.
> >> If using "IfrCheckBox  = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);" when
> wants to update the " Flags" filed in checkbox, but in fact it will update the
> opcode binary data(opcode binary length) behind checkbox binary.
> >> And then it will cause Browser can't parse the IFR binary data correctly.
> And then the possible symptom is that some HII Question and forms may be
> not parsed and then cannot be shown.
> >
> > Thanks! I've copied this into the BZ.
> 
> Has this patch been pushed? If not, maybe you could also copy the above
> description in the commit message.
> A commit message that describes what to be fixed is more meaningful.

Not yet. And I will copy the description in the commit message before push the 
patch.
> 
> >
> > Laszlo
> > ___
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel
> >
> 
> 
> --
> Thanks,
> Ray
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 1/5] MdePkg: Correct the string expression of UTF8 vendor device path

[Bi, Dandan]

Hi Laszlo,

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Laszlo Ersek
> Sent: Monday, October 08, 2018 7:55 PM
> To: Bi, Dandan ; edk2-devel@lists.01.org
> Cc: Ni, Ruiyu ; Kinney, Michael D
> ; Gao, Liming 
> Subject: Re: [edk2] [patch 1/5] MdePkg: Correct the string expression of
> UTF8 vendor device path
> 
> Hi Dandan,
> 
> On 10/08/18 05:31, Dandan Bi wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1225
> >
> > According to UEFI spec, the string expression of UTF8 vendor device
> > node should be displayed as: VenUtf8(). Current code display it as:
> > VenUft8() by mistake when convert device path node to text.
> >
> > This commit is to fix this bug.
> >
> > Cc: Ruiyu Ni 
> > Cc: Michael D Kinney 
> > Cc: Liming Gao 
> > Contributed-under: TianoCore Contribution Agreement 1.0
> > Signed-off-by: Dandan Bi 
> > ---
> >  MdePkg/Library/UefiDevicePathLib/DevicePathToText.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > index 7d8d304f6f..85f5e97131 100644
> > --- a/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > +++ b/MdePkg/Library/UefiDevicePathLib/DevicePathToText.c
> > @@ -193,11 +193,11 @@ DevPathToTextVendor (
> >  return ;
> >} else if (CompareGuid (>Guid, )) {
> >  UefiDevicePathLibCatPrint (Str, L"VenVt100Plus()");
> >  return ;
> >} else if (CompareGuid (>Guid, )) {
> > -UefiDevicePathLibCatPrint (Str, L"VenUft8()");
> > +UefiDevicePathLibCatPrint (Str, L"VenUtf8()");
> >  return ;
> >} else if (CompareGuid (>Guid, )) {
> >  FlowControlMap = (((UART_FLOW_CONTROL_DEVICE_PATH *)
> Vendor)->FlowControlMap);
> >  switch (FlowControlMap & 0x0003) {
> >  case 0:
> >
> 
> it makes sense to send a set of patches that are correlated in some fashion,
> even if they individually address different BZs and don't form a coherent
> "feature" or larger "bugfix". However, even in such cases, please send a
> common cover letter (0/5 in this case). Seeing a unified diffstat, and a few
> intro words (about the common theme of the patch
> set) is helpful.
> 
> (no need to repost, just for the future)
> 
Thanks for the reminder, I will pay more attention in the future.

Thanks,
Dandan

> Thanks
> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure convention for checkbox

[Bi, Dandan]

Hi Laszlo,

> -Original Message-
> From: Laszlo Ersek [mailto:ler...@redhat.com]
> Sent: Monday, October 08, 2018 8:19 PM
> To: Bi, Dandan ; edk2-devel@lists.01.org
> Cc: Zeng, Star ; Gao, Liming 
> Subject: Re: [edk2] [patch] MdeModulePkg/HiiDB: Fix incorrect structure
> convention for checkbox
> 
> Hi Dandan,
> 
> On 10/08/18 03:29, Dandan Bi wrote:
> > REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1224
> >
> > When covert IFR binary to EFI_IFR_CHECKBOX structure, Current code has
> > following incorrect code logic:
> > IfrCheckBox = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1); The correct one
> > should be:
> > IfrCheckBox = (EFI_IFR_CHECKBOX *) IfrOpHdr;
> >
> > This patch is to fix this bug.
> >
> > Cc: Liming Gao 
> > Cc: Star Zeng 
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Dandan Bi 
> > ---
> >  MdeModulePkg/Universal/HiiDatabaseDxe/Database.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> > b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> > index 45448c5198..664687796f 100644
> > --- a/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> > +++ b/MdeModulePkg/Universal/HiiDatabaseDxe/Database.c
> > @@ -896,11 +896,11 @@ UpdateDefaultSettingInFormPackage (
> >break;
> >  case EFI_IFR_CHECKBOX_OP:
> >IfrScope = IfrOpHdr->Scope;
> >IfrQuestionType  = IfrOpHdr->OpCode;
> >IfrQuestionHdr   = (EFI_IFR_QUESTION_HEADER *) (IfrOpHdr + 1);
> > -  IfrCheckBox  = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);
> > +  IfrCheckBox  = (EFI_IFR_CHECKBOX *) IfrOpHdr;
> >EfiVarStoreIndex = IsEfiVarStoreQuestion (IfrQuestionHdr,
> EfiVarStoreList, EfiVarStoreNumber);
> >Width= sizeof (BOOLEAN);
> >if (EfiVarStoreIndex < EfiVarStoreNumber) {
> >  for (Index = 0; Index < DefaultIdNumber; Index ++) {
> >if (DefaultIdList[Index] == EFI_HII_DEFAULT_CLASS_STANDARD)
> > {
> >
> 
> what were the practical consequences (symptoms) of this issue? Did some
> checkboxes not work? (I'm asking because SecureBootConfigDxe uses some
> checkboxes.)

1.  The bug is in function "UpdateDefaultSettingInFormPackage()" which is to 
update the default setting of some HII Questions in the IFR binary data. So it 
only has impact when platform overrides default setting in HII VarStore through 
DynamicHii PCD setting in Platform DSC file. If platform doesn't override 
default setting, it has no impact.

2. The implementation updates the "Flags" filed in the EFI_IFR_CHECKBOX 
structure to update the default setting of checkbox.
If using "IfrCheckBox  = (EFI_IFR_CHECKBOX *) (IfrOpHdr + 1);" when wants 
to update the " Flags" filed in checkbox, but in fact it will update the opcode 
binary data(opcode binary length) behind checkbox binary. 
And then it will cause Browser can't parse the IFR binary data correctly. And 
then the possible symptom is that some HII Question and forms may be not parsed 
and then cannot be shown.


Thanks,
Dandan

> 
> Thanks,
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 0/2] Correct comments to align with the input parameter.

[Bi, Dandan]

Reviewed-by: Dandan  Bi


Thanks,
Dandan

-Original Message-
From: Wu, Jiaxin 
Sent: Monday, October 8, 2018 11:03 AM
To: edk2-devel@lists.01.org
Cc: Carsey, Jaben ; Fu, Siyuan ; 
Ye, Ting ; Bi, Dandan ; Wu, Jiaxin 

Subject: [Patch 0/2] Correct comments to align with the input parameter.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1230

Cc: Carsey Jaben 
Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Bi Dandan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 

Jiaxin Wu (2):
  NetworkPkg/UefiPxeBcDxe: Correct comments to align with the input
parameter.
  ShellPkg/TftpDynamicCommand: Correct comments to align with the input
parameter.

 NetworkPkg/UefiPxeBcDxe/PxeBcMtftp.c  | 11 ++-
 NetworkPkg/UefiPxeBcDxe/PxeBcMtftp.h  |  5 -
 ShellPkg/DynamicCommand/TftpDynamicCommand/Tftp.c |  2 ++
 3 files changed, 16 insertions(+), 2 deletions(-)

-- 
2.17.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg/Tcp4Dxe: Remove the trailing white space in one line.

[Bi, Dandan]

Reviewed-by: Dandan  Bi

Thanks,
Dandan

-Original Message-
From: Wu, Jiaxin 
Sent: Monday, October 8, 2018 11:08 AM
To: edk2-devel@lists.01.org
Cc: Fu, Siyuan ; Ye, Ting ; Bi, Dandan 
; Wu, Jiaxin 
Subject: [Patch] MdeModulePkg/Tcp4Dxe: Remove the trailing white space in one 
line.

Cc: Fu Siyuan 
Cc: Ye Ting 
Cc: Bi Dandan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf 
b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
index fb7f4f8502..7c0504770b 100644
--- a/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
+++ b/MdeModulePkg/Universal/Network/Tcp4Dxe/Tcp4Dxe.inf
@@ -1,17 +1,17 @@
 ## @file
 #  This module produces EFI TCPv4 Protocol and EFI TCPv4 Service Binding 
Protocol.
 #
 #  This module produces EFI TCPv4(Transmission Control Protocol version 4) 
Protocol -#  upon EFI IPv4 Protocol, to provide basic TCPv4 I/O services. This 
driver only 
+#  upon EFI IPv4 Protocol, to provide basic TCPv4 I/O services. This 
+driver only
 #  supports IPv4 network stack.
 #
 #  Notes:
 #  1) This driver can't co-work with the TcpDxe driver in NetworkPkg.
-#  2) This driver might have some issues that have been fixed in the TcpDxe 
driver 
+#  2) This driver might have some issues that have been fixed in the 
+TcpDxe driver
 # in NetworkPkg.
-#  3) This driver supports fewer features than the TcpDxe driver in NetworkPkg 
(e.g. IPv6, 
+#  3) This driver supports fewer features than the TcpDxe driver in 
+NetworkPkg (e.g. IPv6,
 # TCP Cancel function).
 #  4) TcpDxe driver in NetworkPkg is recommended for use instead of this one 
even though
 # both of them can be used.
 #
 #  Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
--
2.17.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h: Change to DOS format file.

[Bi, Dandan]

Reviewed-by: Dandan Bi 


Thanks,
Dandan
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Eric Dong
> Sent: Saturday, September 29, 2018 9:38 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan ; Laszlo Ersek 
> Subject: [edk2] [Patch]
> UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h: Change to DOS
> format file.
> 
> Follow EDKII coding style, change file format to dos style.
> 
> BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1213
> 
> Cc: Dandan Bi 
> Cc: Laszlo Ersek 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Eric Dong 
> ---
>  UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h | 544
> +++---
>  1 file changed, 272 insertions(+), 272 deletions(-)
> 
> diff --git a/UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h
> b/UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h
> index d050464b7f..64f3e14db3 100644
> --- a/UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h
> +++ b/UefiCpuPkg/Include/Register/Msr/GoldmontPlusMsr.h
> @@ -1,272 +1,272 @@
> -/** @file
> -  MSR Defintions for Intel Atom processors based on the Goldmont Plus
> microarchitecture.
> -
> -  Provides defines for Machine Specific Registers(MSR) indexes. Data
> structures
> -  are provided for MSRs that contain one or more bit fields.  If the MSR
> value
> -  returned is a single 32-bit or 64-bit value, then a data structure is not
> -  provided for that MSR.
> -
> -  Copyright (c) 2018, Intel Corporation. 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.
> -
> -  @par Specification Reference:
> -  Intel(R) 64 and IA-32 Architectures Software Developer's Manual, Volume
> 4,
> -  May 2018, Volume 4: Model-Specific-Registers (MSR)
> -
> -**/
> -
> -#ifndef __GOLDMONT_PLUS_MSR_H__
> -#define __GOLDMONT_PLUS_MSR_H__
> -
> -#include 
> -
> -/**
> -  Is Intel Atom processors based on the Goldmont plus microarchitecture?
> -
> -  @param   DisplayFamily  Display Family ID
> -  @param   DisplayModel   Display Model ID
> -
> -  @retval  TRUE   Yes, it is.
> -  @retval  FALSE  No, it isn't.
> -**/
> -#define IS_GOLDMONT_PLUS_PROCESSOR(DisplayFamily, DisplayModel) \
> -  (DisplayFamily == 0x06 && \
> -   (\
> -DisplayModel == 0x7A\
> -)   \
> -   )
> -
> -/**
> -  Core. (R/W) See Table 2-2. See Section 18.6.2.4, "Processor Event Based
> -  Sampling (PEBS).".
> -
> -  @param  ECX  MSR_GOLDMONT_PLUS_PEBS_ENABLE (0x03F1)
> -  @param  EAX  Lower 32-bits of MSR value.
> -   Described by the type
> MSR_GOLDMONT_PLUS_PEBS_ENABLE_REGISTER.
> -  @param  EDX  Upper 32-bits of MSR value.
> -   Described by the type
> MSR_GOLDMONT_PLUS_PEBS_ENABLE_REGISTER.
> -
> -  Example usage
> -  @code
> -  MSR_GOLDMONT_PLUS_PEBS_ENABLE_REGISTER  Msr;
> -
> -  Msr.Uint64 = AsmReadMsr64 (MSR_GOLDMONT_PLUS_PEBS_ENABLE);
> -  AsmWriteMsr64 (MSR_GOLDMONT_PLUS_PEBS_ENABLE, Msr.Uint64);
> -  @endcode
> -**/
> -#define MSR_GOLDMONT_PLUS_PEBS_ENABLE0x03F1
> -
> -/**
> -  MSR information returned for MSR index
> #MSR_GOLDMONT_PLUS_PEBS_ENABLE -**/ -typedef union {
> -  ///
> -  /// Individual bit fields
> -  ///
> -  struct {
> -///
> -/// [Bit 0] Enable PEBS trigger and recording for the programmed event
> -/// (precise or otherwise) on IA32_PMC0.
> -///
> -UINT32  Fix_Me_1:1;
> -///
> -/// [Bit 1] Enable PEBS trigger and recording for the programmed event
> -/// (precise or otherwise) on IA32_PMC1.
> -///
> -UINT32  Fix_Me_2:1;
> -///
> -/// [Bit 2] Enable PEBS trigger and recording for the programmed event
> -/// (precise or otherwise) on IA32_PMC2.
> -///
> -UINT32  Fix_Me_3:1;
> -///
> -/// [Bit 3] Enable PEBS trigger and recording for the programmed event
> -/// (precise or otherwise) on IA32_PMC3.
> -///
> -UINT32  Fix_Me_4:1;
> -UINT32  Reserved1:28;
> -///
> -/// [Bit 32] Enable PEBS trigger and recording for IA32_FIXED_CTR0.
> -///
> -UINT32  Fix_Me_5:1;
> -///
> -/// [Bit 33] Enable PEBS trigger and recording for IA32_

Re: [edk2] [Patch] MdeModulePkg/Ip4Dxe: Refine the coding style.

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Wu, Jiaxin 
Sent: Monday, September 17, 2018 11:14 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan ; Bi, Dandan 
; Wu, Jiaxin 
Subject: [Patch] MdeModulePkg/Ip4Dxe: Refine the coding style.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1180
Remove the trailing white spaces.

Cc: Ye Ting 
Cc: Fu Siyuan 
Cc: Bi Dandan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Wu Jiaxin 
---
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c 
b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
index b1af5294fb..4cb3b32688 100644
--- a/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
+++ b/MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c
@@ -673,13 +673,13 @@ Ip4ConfigProtocol (
 
 //
 // Add a route to this connected network in the instance route table.
 //
 Ip4AddRoute (
-  IpInstance->RouteTable, 
-  Ip & Netmask, 
-  Netmask, 
+  IpInstance->RouteTable,
+  Ip & Netmask,
+  Netmask,
   IP4_ALLZERO_ADDRESS
   );
   } else {
 //
 // Use the default address. Check the state.
-- 
2.17.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Performance enabling of Event handler

[Bi, Dandan]

Hi,

DP tool will filter some entries in which the time duration < 1ms by default.
And you can  use the" dp -t 0  "to dump all the Perf entries.
Then to double check whether the entry you care exists or not.


Thanks,
Dandan
-Original Message-
From: prabin ca [mailto:prabinc...@gmail.com] 
Sent: Friday, September 7, 2018 11:57 PM
To: Bi, Dandan 
Cc: Laszlo Ersek ; edk2-devel@lists.01.org; af...@apple.com
Subject: Re: [edk2] Performance enabling of Event handler

Hi 

Yes it is included in same module (both event handler and function handler), 
and I’m not perf_start and perf_end only two times (one is by event handler and 
one is by normal function handler).

And I’m trying to print result using DP.efi, it shows entry for normal function.

> On 07-Sep-2018, at 8:46 AM, Bi, Dandan  wrote:
> 
> Hi Prabin,
> 
> The Performance logging for the normal functions handlers and event handlers 
> should be the same.
> Are the normal function calls and the event handler function calls you tested 
> in the same module?
> If not, please double check to make sure the performance library instance 
> used correctly for each module.
> 
> 
> Thanks,
> Dandan
> 
> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> prabin ca
> Sent: Friday, September 7, 2018 10:30 AM
> To: Laszlo Ersek 
> Cc: Bi, Dandan ; edk2-devel@lists.01.org; 
> af...@apple.com
> Subject: Re: [edk2] Performance enabling of Event handler
> 
> Hi,
> PerformancePkg is not working with event handlers, but it’s working with 
> normal functions handlers. 
> 
>>> On 06-Sep-2018, at 3:28 PM, Laszlo Ersek  wrote:
>>> 
>>> On 09/06/18 08:10, prabin ca wrote:
>>> Hi Team,
>>> 
>>> I’m used edk2 PerformancePkg for profiling cpu execution time taken by a 
>>> event handler. Event is created successfully and event handler is also 
>>> called successfully, but I can capture the performance of this event 
>>> handler with PerformancePkg (by using perf_start and perf_end check 
>>> points). This PerformancePkg is working fine with normal function calls.
>> 
>> Do you mean "can not", instead of "can"? (Sorry, I don't understand.)
>> 
>>> 
>>> Please help me to enable PerformancePkg action on event handler also.
>>> 
>> 
>> Hmmm, even with the suggested typo correction, I wouldn't know what 
>> to suggest. Sorry!
>> 
>> Laszlo
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ECC reported issues

[Bi, Dandan]

Reviewed-by: Dandan Bi 


Thanks,
Dandan

-Original Message-
From: Wang, Jian J 
Sent: Saturday, September 8, 2018 11:24 AM
To: edk2-devel ; edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: RE: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ECC reported issues

Forgot to mention the BZ info:

https://bugzilla.tianocore.org/show_bug.cgi?id=1160

Regards,
Jian

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org]
> Sent: Saturday, September 08, 2018 10:22 AM
> To: edk2-devel@lists.01.org
> Cc: Bi, Dandan 
> Subject: [edk2] [PATCH] UefiCpuPkg/CpuDxe: fix ECC reported issues
> 
> There're two parameters which have different name in comment and prototype.
> 
> Cc: Dandan Bi 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Jian J Wang 
> ---
>  UefiCpuPkg/CpuDxe/CpuDxe.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/UefiCpuPkg/CpuDxe/CpuDxe.h b/UefiCpuPkg/CpuDxe/CpuDxe.h 
> index 7d65e39e90..064ea05bba 100644
> --- a/UefiCpuPkg/CpuDxe/CpuDxe.h
> +++ b/UefiCpuPkg/CpuDxe/CpuDxe.h
> @@ -291,7 +291,7 @@ RefreshGcdMemoryAttributesFromPaging (  VOID  
> EFIAPI  DebugExceptionHandler (
> -  IN EFI_EXCEPTION_TYPE   InterruptType,
> +  IN EFI_EXCEPTION_TYPE   ExceptionType,
>IN EFI_SYSTEM_CONTEXT   SystemContext
>);
> 
> @@ -307,7 +307,7 @@ DebugExceptionHandler (  VOID  EFIAPI  
> PageFaultExceptionHandler (
> -  IN EFI_EXCEPTION_TYPE   InterruptType,
> +  IN EFI_EXCEPTION_TYPE   ExceptionType,
>IN EFI_SYSTEM_CONTEXT   SystemContext
>);
> 
> --
> 2.16.2.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] SecurityPkg: HashLib: Change dos format

[Bi, Dandan]

Reviewed-by: Dandan Bi 
One minor comment that please remove the additional " Signed-off-by: Zhang, 
Chao B ",
which can't pass the PatchCheck script.

Thanks,
Dandan

-Original Message-
From: Zhang, Chao B 
Sent: Friday, September 7, 2018 4:50 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan ; Zhang, Chao B 
Subject: [Patch] SecurityPkg: HashLib: Change dos format

Change file format to DOS

Cc: Bi Dandan 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Zhang Chao B 
Signed-off-by: Zhang, Chao B 
---
 .../HashInstanceLibSha384/HashInstanceLibSha384.c  | 310 ++---
 .../HashInstanceLibSha384.inf  |  90 +++---
 .../HashInstanceLibSha384.uni  |  42 +--
 .../HashInstanceLibSha512/HashInstanceLibSha512.c  | 308 ++--
 .../HashInstanceLibSha512.inf  |  90 +++---
 .../HashInstanceLibSha512.uni  |  42 +--
 6 files changed, 441 insertions(+), 441 deletions(-)

diff --git a/SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.c 
b/SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.c
index 54bc687425..c750273bdc 100644
--- a/SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.c
+++ b/SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.c
@@ -1,155 +1,155 @@
-/** @file
-  This library is BaseCrypto SHA384 hash instance.
-  It can be registered to BaseCrypto router, to serve as hash engine.
-
-Copyright (c) 2018, Intel Corporation. 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.
-
-**/
-
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include  -#include 
-
-/**
-  The function set SHA384 to digest list.
-
-  @param DigestList   digest list
-  @param Sha384Digest SHA384 digest
-**/
-VOID
-Tpm2SetSha384ToDigestList (
-  IN TPML_DIGEST_VALUES *DigestList,
-  IN UINT8  *Sha384Digest
-  )
-{
-  DigestList->count = 1;
-  DigestList->digests[0].hashAlg = TPM_ALG_SHA384;
-  CopyMem (
-DigestList->digests[0].digest.sha384,
-Sha384Digest,
-SHA384_DIGEST_SIZE
-);
-}
-
-/**
-  Start hash sequence.
-
-  @param HashHandle Hash handle.
-
-  @retval EFI_SUCCESS  Hash sequence start and HandleHandle returned.
-  @retval EFI_OUT_OF_RESOURCES No enough resource to start hash.
-**/
-EFI_STATUS
-EFIAPI
-Sha384HashInit (
-  OUT HASH_HANDLE*HashHandle
-  )
-{
-  VOID *Sha384Ctx;
-  UINTNCtxSize;
-
-  CtxSize = Sha384GetContextSize ();
-  Sha384Ctx = AllocatePool (CtxSize);
-  ASSERT (Sha384Ctx != NULL);
-
-  Sha384Init (Sha384Ctx);
-
-  *HashHandle = (HASH_HANDLE)Sha384Ctx;
-
-  return EFI_SUCCESS;
-}
-
-/**
-  Update hash sequence data.
-
-  @param HashHandleHash handle.
-  @param DataToHashData to be hashed.
-  @param DataToHashLen Data size.
-
-  @retval EFI_SUCCESS Hash sequence updated.
-**/
-EFI_STATUS
-EFIAPI
-Sha384HashUpdate (
-  IN HASH_HANDLEHashHandle,
-  IN VOID   *DataToHash,
-  IN UINTN  DataToHashLen
-  )
-{
-  VOID *Sha384Ctx;
-
-  Sha384Ctx = (VOID *)HashHandle;
-  Sha384Update (Sha384Ctx, DataToHash, DataToHashLen);
-
-  return EFI_SUCCESS;
-}
-
-/**
-  Complete hash sequence complete.
-
-  @param HashHandleHash handle.
-  @param DigestListDigest list.
-
-  @retval EFI_SUCCESS Hash sequence complete and DigestList is returned.
-**/
-EFI_STATUS
-EFIAPI
-Sha384HashFinal (
-  IN HASH_HANDLE HashHandle,
-  OUT TPML_DIGEST_VALUES *DigestList
-  )
-{
-  UINT8 Digest[SHA384_DIGEST_SIZE];
-  VOID  *Sha384Ctx;
-
-  Sha384Ctx = (VOID *)HashHandle;
-  Sha384Final (Sha384Ctx, Digest);
-
-  FreePool (Sha384Ctx);
-
-  Tpm2SetSha384ToDigestList (DigestList, Digest);
-
-  return EFI_SUCCESS;
-}
-
-HASH_INTERFACE  mSha384InternalHashInstance = {
-  HASH_ALGORITHM_SHA384_GUID,
-  Sha384HashInit,
-  Sha384HashUpdate,
-  Sha384HashFinal,
-};
-
-/**
-  The function register SHA384 instance.
-  
-  @retval EFI_SUCCESS   SHA384 instance is registered, or system dose not 
surpport registr SHA384 instance
-**/
-EFI_STATUS
-EFIAPI
-HashInstanceLibSha384Constructor (
-  VOID
-  )
-{
-  EFI_STATUS  Status;
-
-  Status = RegisterHashInterfaceLib ();
-  if ((Status == EFI_SUCCESS) || (Status == EFI_UNSUPPORTED)) {
-//
-// Unsupported means platform policy does not need this instance enabled.
-//
-return EFI_SUCCESS;
-  }
-  return Status;
-}
\ No newline at end of file
+/** @file
+  This library is BaseCrypto SHA384 hash instance.
+  It can be registered to BaseCrypto router, to serve as hash engine.
+
+Copyrigh

Re: [edk2] [PATCH] UefiCpuPkg/PeiCpuException: Fix coding style issue

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Friday, September 7, 2018 6:13 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: [PATCH] UefiCpuPkg/PeiCpuException: Fix coding style issue

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Dandan Bi 
---
 UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
index 5dd8423d2f..8f4d5b5e0a 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/PeiCpuException.c
@@ -45,7 +45,7 @@ GetExceptionHandlerData (
 
   AsmReadIdtr ();
   IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)IdtDescriptor.Base;
-  
+
   Exception0StubHeader = (EXCEPTION0_STUB_HEADER *)ArchGetIdtHandler 
([0]);
   return Exception0StubHeader->ExceptionHandlerData;
 }
@@ -57,7 +57,7 @@ GetExceptionHandlerData (
   exception handler data. The new allocated memory layout follows structure 
EXCEPTION0_STUB_HEADER.
   The code assumes that all processors uses the same exception handler for #0 
exception.
 
-  @param  pointer to exception handler data.
+  @param ExceptionHandlerData  pointer to exception handler data.
 **/
 VOID
 SetExceptionHandlerData (
@@ -73,7 +73,7 @@ SetExceptionHandlerData (
   //
   AsmReadIdtr ();
   IdtTable = (IA32_IDT_GATE_DESCRIPTOR *)IdtDescriptor.Base;
-  
+
   Exception0StubHeader = AllocatePool (sizeof (*Exception0StubHeader));
   ASSERT (Exception0StubHeader != NULL);
   CopyMem (
-- 
2.16.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] Performance enabling of Event handler

[Bi, Dandan]

Hi Prabin,

The Performance logging for the normal functions handlers and event handlers 
should be the same.
Are the normal function calls and the event handler function calls you tested 
in the same module?
If not, please double check to make sure the performance library instance used 
correctly for each module.


Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of prabin ca
Sent: Friday, September 7, 2018 10:30 AM
To: Laszlo Ersek 
Cc: Bi, Dandan ; edk2-devel@lists.01.org; af...@apple.com
Subject: Re: [edk2] Performance enabling of Event handler

Hi,
PerformancePkg is not working with event handlers, but it’s working with normal 
functions handlers. 

> On 06-Sep-2018, at 3:28 PM, Laszlo Ersek  wrote:
> 
>> On 09/06/18 08:10, prabin ca wrote:
>> Hi Team,
>> 
>> I’m used edk2 PerformancePkg for profiling cpu execution time taken by a 
>> event handler. Event is created successfully and event handler is also 
>> called successfully, but I can capture the performance of this event handler 
>> with PerformancePkg (by using perf_start and perf_end check points). This 
>> PerformancePkg is working fine with normal function calls.
> 
> Do you mean "can not", instead of "can"? (Sorry, I don't understand.)
> 
>> 
>> Please help me to enable PerformancePkg action on event handler also.
>> 
> 
> Hmmm, even with the suggested typo correction, I wouldn't know what to 
> suggest. Sorry!
> 
> Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg: Remove trailing white space

[Bi, Dandan]

Reviewed-by: Dandan Bi 


Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Wednesday, September 5, 2018 10:01 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Bi, Dandan ; Gao, 
Liming ; Wang, Jian J ; Fu, Siyuan 
; Wu, Jiaxin 
Subject: [PATCH] MdeModulePkg: Remove trailing white space

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1144

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Cc: Siyuan Fu 
Cc: Jiaxin Wu 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Pei/Ppi/Ppi.c|  4 +--
 MdeModulePkg/Include/Library/NetLib.h  |  2 +-
 .../Library/DxeCapsuleLibFmp/DxeCapsuleLib.c   |  2 +-
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c |  4 +--
 MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c|  2 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4If.c  | 14 +-
 MdeModulePkg/Universal/Network/Ip4Dxe/Ip4Impl.c| 30 +++---
 7 files changed, 29 insertions(+), 29 deletions(-)

diff --git a/MdeModulePkg/Core/Pei/Ppi/Ppi.c b/MdeModulePkg/Core/Pei/Ppi/Ppi.c 
index d8ba2dd42b59..6f03858b8a94 100644
--- a/MdeModulePkg/Core/Pei/Ppi/Ppi.c
+++ b/MdeModulePkg/Core/Pei/Ppi/Ppi.c
@@ -143,7 +143,7 @@ ConvertPointerInRanges (
 
   Migrate Single PPI Pointer from the temporary memory to PEI installed memory.
 
-  @param SecCoreData Points to a data structure containing SEC to PEI 
handoff data, such as the size 
+  @param SecCoreData Points to a data structure containing SEC to PEI 
handoff data, such as the size
  and location of temporary RAM, the stack location and 
the BFV location.
   @param PrivateData Pointer to PeiCore's private data structure.
   @param PpiPointer  Pointer to Ppi
@@ -179,7 +179,7 @@ ConvertSinglePpiPointer (
 
   Migrate PPI Pointers from the temporary memory to PEI installed memory.
 
-  @param SecCoreData Points to a data structure containing SEC to PEI 
handoff data, such as the size 
+  @param SecCoreData Points to a data structure containing SEC to PEI 
handoff data, such as the size
  and location of temporary RAM, the stack location and 
the BFV location.
   @param PrivateData Pointer to PeiCore's private data structure.
 
diff --git a/MdeModulePkg/Include/Library/NetLib.h 
b/MdeModulePkg/Include/Library/NetLib.h
index b7ef99c7b568..09779739213e 100644
--- a/MdeModulePkg/Include/Library/NetLib.h
+++ b/MdeModulePkg/Include/Library/NetLib.h
@@ -424,7 +424,7 @@ NetGetIpClass (
   except when the originator is one of the endpoints of a point-to-point link 
with a 31-bit
   mask (RFC3021), or a 32bit NetMask (all 0xFF) is used for special network 
environment (e.g.
   PPP link).
-  
+
   @param[in]  IpThe IP to check against.
   @param[in]  NetMask   The mask of the IP.
 
diff --git a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c 
b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
index 91c6849a4658..20fd29a3a87f 100644
--- a/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
+++ b/MdeModulePkg/Library/DxeCapsuleLibFmp/DxeCapsuleLib.c
@@ -765,7 +765,7 @@ GetFmpHandleBufferByType (
 MatchedHandleBuffer[MatchedNumberOfHandles] = HandleBuffer[Index];
   }
   if (MatchedResetRequiredBuffer != NULL) {
-MatchedResetRequiredBuffer[MatchedNumberOfHandles] = 
(((TempFmpImageInfo->AttributesSupported & 
+MatchedResetRequiredBuffer[MatchedNumberOfHandles] = 
+ (((TempFmpImageInfo->AttributesSupported &
  
IMAGE_ATTRIBUTE_RESET_REQUIRED) != 0) &&
  
((TempFmpImageInfo->AttributesSetting &
  
IMAGE_ATTRIBUTE_RESET_REQUIRED) != 0)); diff --git 
a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c 
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index 63f4724062e9..9e3ea2490928 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -656,7 +656,7 @@ NetGetIpClass (
   except when the originator is one of the endpoints of a point-to-point link 
with a 31-bit
   mask (RFC3021), or a 32bit NetMask (all 0xFF) is used for special network 
environment (e.g.
   PPP link).
-  
+
   @param[in]  IpThe IP to check against.
   @param[in]  NetMask   The mask of the IP.
 
@@ -671,7 +671,7 @@ NetIp4IsUnicast (
   )
 {
   INTN   MaskLength;
-  
+
   ASSERT (NetMask != 0);
 
   if (Ip == 0 || IP4_IS_LOCAL_BROADCAST (Ip)) { diff --git 
a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c 
b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
index 219059760e97..129e90ca11b4 100644
--- a/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
+++ b/MdeModulePkg/Universal/EsrtFmpDxe/EsrtFmp.c
@@ -296,7 +296,7 @@ CreateFmpBasedEsrt (
 
   Table->

Re: [edk2] [PATCH] MdeModulePkg PeiCore: Fix VS2012 build failure

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan
-Original Message-
From: Zeng, Star 
Sent: Tuesday, September 4, 2018 9:18 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Bi, Dandan ; Gao, 
Liming ; Wang, Jian J 
Subject: [PATCH] MdeModulePkg PeiCore: Fix VS2012 build failure

fwvol.c(1572) : warning C4701: potentially uninitialized local variable 
'Status' used

The build failure is caused by
0e042d0ad76157ac9bad17bb4e1ff2919ca0d8f4 for
https://bugzilla.tianocore.org/show_bug.cgi?id=1131

This patch initializes Status to fix the build failure.

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Jian J Wang 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Core/Pei/FwVol/FwVol.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/Pei/FwVol/FwVol.c 
b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
index 7ea503a10fb5..5629c9a1ce20 100644
--- a/MdeModulePkg/Core/Pei/FwVol/FwVol.c
+++ b/MdeModulePkg/Core/Pei/FwVol/FwVol.c
@@ -1412,6 +1412,8 @@ ProcessFvFile (
   ParentFvHandle = ParentFvCoreHandle->FvHandle;
   ParentFvPpi= ParentFvCoreHandle->FvPpi;
 
+  Status = EFI_SUCCESS;
+
   //
   // Find FvImage(s) in FvFile
   //
--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] EmulatorPkg/PlatformBmLib: Fix GCC build failure

[Bi, Dandan]

Reviewed-by: Dandan Bi 


Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, September 3, 2018 10:24 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: [PATCH] EmulatorPkg/PlatformBmLib: Fix GCC build failure

Some local variables are initialized but never used.
GCC complains about that. The patch fixes this issue.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Dandan Bi 
---
 EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c 
b/EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c
index 5b39776..b07226f 100644
--- a/EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c
+++ b/EmulatorPkg/Library/PlatformBmLib/PlatformBmMemoryTest.c
@@ -41,26 +41,15 @@ PlatformBootManagerMemoryTest (
   EFI_GENERIC_MEMORY_TEST_PROTOCOL  *GenMemoryTest;
   UINT64TestedMemorySize;
   UINT64TotalMemorySize;
-  UINT64PreviousValue;
   BOOLEAN   ErrorOut;
   BOOLEAN   TestAbort;
   EFI_INPUT_KEY Key;
-  CHAR16*StrTotalMemory;
-  CHAR16*Pos;
-  UINTN StrTotalMemorySize;
 
   ReturnStatus = EFI_SUCCESS;
   ZeroMem (, sizeof (EFI_INPUT_KEY));
 
-  StrTotalMemorySize = 128;
-  Pos = AllocateZeroPool (StrTotalMemorySize);
-  ASSERT (Pos != NULL);
-
-  StrTotalMemory= Pos;
-
   TestedMemorySize  = 0;
   TotalMemorySize   = 0;
-  PreviousValue = 0;
   ErrorOut  = FALSE;
   TestAbort = FALSE;
 
@@ -72,7 +61,6 @@ PlatformBootManagerMemoryTest (
   (VOID **) 
   );
   if (EFI_ERROR (Status)) {
-FreePool (Pos);
 return EFI_SUCCESS;
   }
 
@@ -89,7 +77,6 @@ PlatformBootManagerMemoryTest (
 // do the test, and then the status of EFI_NO_MEDIA will be returned by
 // "MemoryTestInit". So it does not need to test memory again, just return.
 //
-FreePool (Pos);
 return EFI_SUCCESS;
   }
 
@@ -128,6 +115,5 @@ PlatformBootManagerMemoryTest (
 Done:
   DEBUG ((DEBUG_INFO, "%d bytes of system memory tested OK\r\n", 
TotalMemorySize));
 
-  FreePool (Pos);
   return ReturnStatus;
 }
-- 
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2 2/2] MdeModulePkg: Update SMBIOS PCDs to 3.2.0

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Thursday, August 23, 2018 11:36 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Gao, Liming ; Bi, 
Dandan ; Kinney, Michael D 
Subject: [PATCH V2 2/2] MdeModulePkg: Update SMBIOS PCDs to 3.2.0

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1099

Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/MdeModulePkg.dec | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MdeModulePkg/MdeModulePkg.dec b/MdeModulePkg/MdeModulePkg.dec 
index 6a6d9660edc2..261da61c18a2 100644
--- a/MdeModulePkg/MdeModulePkg.dec
+++ b/MdeModulePkg/MdeModulePkg.dec
@@ -1763,11 +1763,11 @@ [PcdsFixedAtBuild, PcdsPatchableInModule, PcdsDynamic, 
PcdsDynamicEx]
 
   ## SMBIOS version.
   # @Prompt SMBIOS version.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0301|UINT16|0x00010055
+  
+ gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosVersion|0x0302|UINT16|0x000100
+ 55
 
   ## SMBIOS Docrev field in SMBIOS 3.0 (64-bit) Entry Point Structure.
   # @Prompt SMBIOS Docrev field in SMBIOS 3.0 (64-bit) Entry Point Structure.
-  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x1|UINT8|0x0001006A
+  gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0|UINT8|0x0001006A
 
   ## SMBIOS produce method.
   #  BIT0 set indicates 32-bit entry point and table are produced.
--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH V2 1/2] MdePkg SmBios.h: Add SMBIOS 3.2.0 definitions

[Bi, Dandan]

Hi Star,

One minor comment:
How about update 
+  UINT8 MemoryTechnology;   ///< 
MEMORY_DEVICE_TECHNOLOGY
To 
+  UINT8 MemoryTechnology;   ///< The 
enumeration value from MEMORY_DEVICE_TECHNOLOGY.
In order to keep consistent with current comments style.

With this update, Reviewed-by: Dandan Bi 


Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Thursday, August 23, 2018 11:36 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Gao, Liming ; Bi, 
Dandan ; Kinney, Michael D 
Subject: [PATCH V2 1/2] MdePkg SmBios.h: Add SMBIOS 3.2.0 definitions

REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1099

Add SMBIOS 3.2.0 definitions according to 
www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.2.0.pdf.

Processor Information (Type 4):
- SMBIOSCR00163: add socket LGA2066
- SMBIOSCR00173: add Intel Core i9
- SMBIOSCR00176: add new processor sockets Port Connector Information (Type 8):
- SMBIOSCR00168: add USB Type-C
System Slots (Type 9):
- SMBIOSCR00164: add "unavailable" to current usage field
- SMBIOSCR00167: add support for PCIe bifurcation Memory Device (Type 17):
- SMBIOSCR00162: add support for NVDIMMs
- SMBIOSCR00166: extend support for NVDIMMs and add support for logical memory 
type
- SMBIOSCR00172: rename "Configured Memory Clock Speed" to "Configured Memory 
Speed"
- SMBIOSCR00174: add new memory technology value (Intel Persistent Memory, 3D 
XPoint) IPMI Device Information (Type 38):
- SMBIOSCR00171: add SSIF
Management Controller Host Interface (Type 42)
- SMBIOSCR00175: fix structure data parsing issue

V2: Add missing update to MISC_PORT_TYPE and SMBIOS_TABLE_TYPE9.

Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Michael D Kinney 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdePkg/Include/IndustryStandard/SmBios.h | 155 ---
 1 file changed, 120 insertions(+), 35 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/SmBios.h 
b/MdePkg/Include/IndustryStandard/SmBios.h
index 5d0442873dfc..61e2f9421f97 100644
--- a/MdePkg/Include/IndustryStandard/SmBios.h
+++ b/MdePkg/Include/IndustryStandard/SmBios.h
@@ -1,5 +1,5 @@
 /** @file
-  Industry Standard Definitions of SMBIOS Table Specification v3.1.1.
+  Industry Standard Definitions of SMBIOS Table Specification v3.2.0.
 
 Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
 (C) Copyright 2015-2017 Hewlett Packard Enterprise Development LP @@ 
-685,6 +685,7 @@ typedef enum {
   ProcessorFamilyzArchitecture  = 0xCC,
   ProcessorFamilyIntelCoreI5= 0xCD,
   ProcessorFamilyIntelCoreI3= 0xCE,
+  ProcessorFamilyIntelCoreI9= 0xCF,
   ProcessorFamilyViaC7M = 0xD2,
   ProcessorFamilyViaC7D = 0xD3,
   ProcessorFamilyViaC7  = 0xD4,
@@ -806,7 +807,11 @@ typedef enum {
   ProcessorUpgradeSocketBGA1515   = 0x35,
   ProcessorUpgradeSocketLGA3647_1 = 0x36,
   ProcessorUpgradeSocketSP3   = 0x37,
-  ProcessorUpgradeSocketSP3r2 = 0x38
+  ProcessorUpgradeSocketSP3r2 = 0x38,
+  ProcessorUpgradeSocketLGA2066   = 0x39,
+  ProcessorUpgradeSocketBGA1392   = 0x3A,
+  ProcessorUpgradeSocketBGA1510   = 0x3B,
+  ProcessorUpgradeSocketBGA1528   = 0x3C
 } PROCESSOR_UPGRADE;
 
 ///
@@ -1159,6 +1164,7 @@ typedef enum {
   PortConnectorTypeBNC= 0x20,
   PortConnectorType1394   = 0x21,
   PortConnectorTypeSasSata= 0x22,
+  PortConnectorTypeUsbTypeC   = 0x23,
   PortConnectorTypePC98   = 0xA0,
   PortConnectorTypePC98Hireso = 0xA1,
   PortConnectorTypePCH98  = 0xA2,
@@ -1205,6 +1211,8 @@ typedef enum {
   PortTypeNetworkPort   = 0x1F,
   PortTypeSata  = 0x20,
   PortTypeSas   = 0x21,
+  PortTypeMfdp  = 0x22, ///< Multi-Function Display Port
+  PortTypeThunderbolt   = 0x23,
   PortType8251Compatible= 0xA0,
   PortType8251FifoCompatible= 0xA1,
   PortTypeOther = 0xFF
@@ -1314,10 +1322,11 @@ typedef enum {
 /// System Slots - Current Usage.
 ///
 typedef enum {
-  SlotUsageOther = 0x01,
-  SlotUsageUnknown   = 0x02,
-  SlotUsageAvailable = 0x03,
-  SlotUsageInUse = 0x04
+  SlotUsageOther= 0x01,
+  SlotUsageUnknown  = 0x02,
+  SlotUsageAvailable= 0x03,
+  SlotUsageInUse= 0x04,
+  SlotUsageUnavailable  = 0x05
 } MISC_SLOT_USAGE;
 
 ///
@@ -1350,10 +1359,21 @@ typedef struct {
   UINT8  PmeSignalSupported  :1;
   UINT8  HotPlugDevicesSupported :1;
   UINT8  SmbusSignalSupported:1;
-  UINT8  Reserved:5;  ///< Set to 0.
+  UINT8  BifurcationSupported:1;
+  UINT8  Reserved:4;  ///< Set to 0.
 } MISC_SLOT_CHARACTERISTICS2;
 
 ///
+/// System Slots - Peer Segment/B

Re: [edk2] [PATCH] ShellPkg/acpi: Fix XCODE5 X64 build failure

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, August 6, 2018 2:30 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: [PATCH] ShellPkg/acpi: Fix XCODE5 X64 build failure

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Dandan Bi 
---
 ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c | 2 +-  
ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
index cca25fcce9..5b25c66f40 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Fadt/FadtPars
+++ er.c
@@ -33,7 +33,7 @@ STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
 /**
   Get the ACPI XSDT header info.
 **/
-CONST ACPI_DESCRIPTION_HEADER_INFO* CONST
+CONST ACPI_DESCRIPTION_HEADER_INFO *
 EFIAPI
 GetAcpiXsdtHeaderInfo (
   VOID
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c
index a5e1412484..5fa28338ef 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtPars
+++ er.c
@@ -32,7 +32,7 @@ STATIC CONST ACPI_PARSER XsdtParser[] = {
 /**
   Get the ACPI XSDT header info.
 **/
-CONST ACPI_DESCRIPTION_HEADER_INFO* CONST
+CONST ACPI_DESCRIPTION_HEADER_INFO *
 EFIAPI
 GetAcpiXsdtHeaderInfo (
   VOID
--
2.16.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] PerformancePkg on multiple platform -

[Bi, Dandan]

Hi Prabin,

Here is a simple introduction of current performance infrastructure in latest 
Edk2 code base.
Hope it can have some help when you enable it.
https://github.com/dandanbi/edk2/wiki/Performance-Infrastructure


Thanks,
Dandan
 
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of prabin ca
Sent: Saturday, August 04, 2018 1:20 PM
To: Andrew Fish 
Cc: edk2-devel ; Laszlo Ersek 
Subject: Re: [edk2] PerformancePkg on multiple platform -

Hi Andrew,

I have already enabled that PCD in my DSC file, because of that its working in 
some platform.

What I'm doing is building my DP.efi and DXE driver from that dsc file and 
testing it from UEFI shell.

thanks for your help as well.

On Sat, Aug 4, 2018 at 12:08 AM, Andrew Fish  wrote:

> Prabin,
>
> There is a PCD setting to configure performance collection.
>
> PCDs are defined in the .DEC file and it looks like the default is 
> zero and that means disabled.
> MdePkg/MdePkg.dec
> ...
>   ## The mask is used to control PerformanceLib behavior.
>   #  BIT0 - Enable Performance Measurement.
>   # @Prompt Performance Measurement Property.
>   # @Expression  0x8002 | (gEfiMdePkgTokenSpaceGuid.
> PcdPerformanceLibraryPropertyMask & 0xFE) == 0
>   gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyM
> ask|0|UINT8|0x0009
>
> If you search the code you will see some platforms enabling 
> performance measurement in their DSC files.
>
> /Volumes/Case/UDK2018(vUDK2018)>git grep gEfiMdePkgTokenSpaceGuid.
> PcdPerformanceLibraryPropertyMask -- *.dsc
> BeagleBoardPkg/BeagleBoardPkg.dsc:272:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|1
> EmbeddedPkg/EmbeddedPkg.dsc:175:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0
> QuarkPlatformPkg/Quark.dsc:373:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x1
> QuarkPlatformPkg/Quark.dsc:376:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x00
> QuarkPlatformPkg/QuarkMin.dsc:334:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x1
> QuarkPlatformPkg/QuarkMin.dsc:337:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x00
> Vlv2TbltDevicePkg/PlatformPkgGccX64.dsc:682:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x1
> Vlv2TbltDevicePkg/PlatformPkgIA32.dsc:682:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x1
> Vlv2TbltDevicePkg/PlatformPkgX64.dsc:682:
> *gEfiMdePkgTokenSpaceGuid.PcdPerformanceLibraryPropertyMask*|0x1
>
> So I'd check that 1st. If that does not work I recommend adding 
> -report-file=build.log to your build command. You can look at the 
> given driver/app you care about and see what the PCD settings are and 
> which instance of the PerformanceLib got linked.
>
> Thanks,
>
> Andrew Fish
>
> On Aug 3, 2018, at 11:17 AM, Laszlo Ersek  wrote:
>
> Hi Prabin,
>
> On 08/03/18 09:29, prabin ca wrote:
>
> Hi Team,
>
> I’m new to uefi and edk. Currently I’m trying to get performance of my 
> dxe driver using PerformancePkg of EDK source code.
>
> I’m using perf_start and perf_end T respected check points, it’s hot 
> build and tested well in 2/3 platform. It’s giving proper response.
>
> But when I’m Checking with multiple platform, in some of platforms 
> it’s not working and got hang in uefi she’ll itself.
>
> Please help me to resolve asap, it will be really helpful.
>
>
> I can only give you some hints, because thus far I have also failed to 
> figure out how performance measurements should be enabled for a 
> platform from scratch.
>
> Earlier I thought that an interested platform should include modules 
> from PerformancePkg. I got some good results that way; however:
>
> - it wouldn't work for AARCH64, and so I filed  
> 
>
> - ultimately PerformancePkg was removed in commit 922c1e94e4bb  
> completely. (And for that reason I now closed TianoCore#679 as
>  WONTFIX.)
>
> Commit 922c1e94e4bb doesn't really give pointers for enabling 
> performance measurements in a platform -- it refers the user to the DP 
> shell command instead of the standalone DP application, but that's 
> only for displaying the stats, not for recording them.
>
> One document where I found information is the Intel whitepaper
>
>  A Tour Beyond BIOS
>  Implementing Profiling in with EDK II
>
> (just google it). "Part III – Performance Profile" is relevant.
>
> The first section of that talks about enabling ACPI FPDT (ACPI 
> Firmware Performance Data Table) support in edk2, for exposing 
> firmware performance data to the OS. Again, that's not about *recording* the 
> stats.
>
> The second section of the same chapter seems to describe how stats can 
> be recorded however. AIUI, the DXE Core can provide the 
> PERFORMANCE[_EX] protocols, if the DxeCorePerformanceLib instance is 
> linked into it by the platform DSC file. In turn DXE modules can send 
> measurements to the protocol via the PerformanceLib APIs / 

Re: [edk2] [PATCH] MdePkg FirmwareManagement.h: Fix code style issue

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, July 30, 2018 5:45 PM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Bi, Dandan 
; Gao, Liming ; Zeng, Star 
; Chen, Hesheng 
Subject: [edk2] [PATCH] MdePkg FirmwareManagement.h: Fix code style issue

Cc: Michael D Kinney 
Cc: Liming Gao 
Cc: Dandan Bi 
Cc: Hess Chen 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdePkg/Include/Protocol/FirmwareManagement.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdePkg/Include/Protocol/FirmwareManagement.h 
b/MdePkg/Include/Protocol/FirmwareManagement.h
index 7c8f1ce65ded..fdd5a7f2a34c 100644
--- a/MdePkg/Include/Protocol/FirmwareManagement.h
+++ b/MdePkg/Include/Protocol/FirmwareManagement.h
@@ -317,11 +317,11 @@ EFI_STATUS
   This function allows a copy of the current firmware image to be created and 
saved.
   The saved copy could later been used, for example, in firmware image 
recovery or rollback.
 
-  @param[in]  This   A pointer to the 
EFI_FIRMWARE_MANAGEMENT_PROTOCOL instance.
-  @param[in]  ImageIndex A unique number identifying the firmware 
image(s) within the device.
+  @param[in]  This   A pointer to the 
EFI_FIRMWARE_MANAGEMENT_PROTOCOL instance.
+  @param[in]  ImageIndex A unique number identifying the firmware 
image(s) within the device.
  The number is between 1 and DescriptorCount.
-  @param[out] Image  Points to the buffer where the current image 
is copied to.
-  @param[out] ImageSize  On entry, points to the size of the buffer 
pointed to by Image, in bytes.
+  @param[in, out] Image  Points to the buffer where the current image 
is copied to.
+  @param[in, out] ImageSize  On entry, points to the size of the buffer 
pointed to by Image, in bytes.
  On return, points to the length of the image, 
in bytes.
 
   @retval EFI_SUCCESSThe device was successfully updated with the 
new image.
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 3/4] ShellPkg/UefiShellAcpiViewCommandLib: Fix VS build failure

[Bi, Dandan]

Hi Alexei,

I didn't notice your patch before.  So I create this patch along with others  
to fix all  the build issues.
And your patch which fix the build error seems not commit to edk2 code base.
When do you plan to commit it?

Hi all,
Please review other patches in this series and ignore this one.
Sorry for any inconvenience.


Thanks,
Dandan

From: Alexei Fedorov [mailto:alexei.fedo...@arm.com]
Sent: Monday, July 30, 2018 4:28 PM
To: Bi, Dandan ; edk2-devel@lists.01.org
Cc: Ni, Ruiyu ; Carsey, Jaben 
Subject: Re: [patch 3/4] ShellPkg/UefiShellAcpiViewCommandLib: Fix VS build 
failure


Dandan,



What is the reason for providing this patch addressing the same issues which 
were fixed by already reviewed patch sent on 13 July?

See thread for

https://lists.01.org/pipermail/edk2-devel/2018-July/027139.html


Alexei


From: Dandan Bi mailto:dandan...@intel.com>>
Sent: 30 July 2018 03:27:02
To: edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
Cc: Alexei Fedorov; Ruiyu Ni; Jaben Carsey
Subject: [patch 3/4] ShellPkg/UefiShellAcpiViewCommandLib: Fix VS build failure

Fix following warnings:
1.
xxx\GtdtParser.c(179): warning C4244:
'=': conversion from 'UINT32' to 'UINT16', possible loss of data
xxx\GtdtParser.c(180): warning C4244:
'-=': conversion from 'UINT32' to 'UINT16', possible loss of data
xxx\GtdtParser.c(196): warning C4244:
'-=': conversion from 'UINT32' to 'UINT16', possible loss of data

2.
xxx\XsdtParser.c(99): warning C4457:
declaration of 'Ptr' hides function parameter

cc: Alexei Fedorov mailto:alexei.fedo...@arm.com>>
cc: Ruiyu Ni mailto:ruiyu...@intel.com>>
cc: Jaben Carsey mailto:jaben.car...@intel.com>>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi mailto:dandan...@intel.com>>
---
 .../UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c|  6 +++---
 .../UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c| 12 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
index 3a3cee948a..d5671081da 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Gtdt/GtdtParser.c
@@ -174,12 +174,12 @@ DumpGTBlock (
  "GT Block",
  Ptr,
  Length,
  PARSER_PARAMS (GtBlockParser)
  );
-  GTBlockTimerLength = (*GtBlockLength - Offset) / (*GtBlockTimerCount);
-  Length -= Offset;
+  GTBlockTimerLength = (*GtBlockLength - (UINT16)Offset) / 
(UINT16)(*GtBlockTimerCount);
+  Length -= (UINT16)Offset;

   if (*GtBlockTimerCount != 0) {
 Ptr += (*GtBlockTimerOffset);
 Index = 0;
 while ((Index < (*GtBlockTimerCount)) && (Length >= GTBlockTimerLength)) {
@@ -191,11 +191,11 @@ DumpGTBlock (
  GTBlockTimerLength,
  PARSER_PARAMS (GtBlockTimerParser)
  );
   // Increment by GT Block Timer structure size
   Ptr += Offset;
-  Length -= Offset;
+  Length -= (UINT16)Offset;
   Index++;
 }

 if (Length != 0) {
   IncrementErrorCount ();
diff --git 
a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c
index 99521cd67a..341a61b8fb 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/Parsers/Xsdt/XsdtParser.c
@@ -63,10 +63,11 @@ ParseAcpiXsdt (
   UINT32Offset;
   UINT32TableOffset;
   UINT64*   TablePointer;
   UINTN EntryIndex;
   CHAR16Buffer[32];
+  UINT8*Pointer;

   // Parse the ACPI header to get the length
   ParseAcpi (
 FALSE,
 0,
@@ -94,30 +95,29 @@ ParseAcpiXsdt (
   CONST UINT32* Signature;
   CONST UINT32* Length;
   CONST UINT8*  Revision;

   if ((UINT64*)(UINTN)(*TablePointer) != NULL) {
-UINT8*  Ptr;

 ParseAcpiHeader (
   (UINT8*)(UINTN)(*TablePointer),
   ,
   ,
   
   );

-Ptr = (UINT8*)Signature;
+Pointer = (UINT8*)Signature;

 UnicodeSPrint (
   Buffer,
   sizeof (Buffer),
   L"Entry[%d] - %c%c%c%c",
   EntryIndex++,
-  Ptr[0],
-  Ptr[1],
-  Ptr[2],
-  Ptr[3]
+  Pointer[0],
+  Pointer[1],
+  Pointer[2],
+  Pointer[3]
   );
   } else {
 UnicodeSPrint (
   Buffer,
   sizeof (Buffer),
--
2.14.3.windows.1
IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do 

Re: [edk2] [Patch] SecurityPkgDSC: Fix 2 DSC build error

[Bi, Dandan]

Reviewed-by: Dandan Bi 


Thanks,
Dandan

-Original Message-
From: Zhang, Chao B 
Sent: Saturday, July 28, 2018 1:35 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: [Patch] SecurityPkgDSC: Fix 2 DSC build error

Error is caused by SHA384/SHA512 hash lib change in.

Cc: Bi Dandan 
Contributed-under: TianoCore Contribution Agreement 1.1

Signed-off-by: Zhang, Chao B 
---
 SecurityPkg/SecurityPkg.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/SecurityPkg/SecurityPkg.dsc b/SecurityPkg/SecurityPkg.dsc index 
a705cdcf72..68a2953162 100644
--- a/SecurityPkg/SecurityPkg.dsc
+++ b/SecurityPkg/SecurityPkg.dsc
@@ -217,12 +217,12 @@
   #
   # TPM2
   #
   SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha1.inf
   SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha256.inf
-  SecurityPkg/Library/HashInstanceLibSha1/HashInstanceLibSha384.inf
-  SecurityPkg/Library/HashInstanceLibSha256/HashInstanceLibSha512.inf
+  SecurityPkg/Library/HashInstanceLibSha384/HashInstanceLibSha384.inf
+  SecurityPkg/Library/HashInstanceLibSha512/HashInstanceLibSha512.inf
 
   SecurityPkg/Tcg/Tcg2Config/Tcg2ConfigPei.inf {
 
   
Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibDTpm/Tpm12DeviceLibDTpm.inf
   Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2DeviceLibDTpm.inf
--
2.16.2.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/6] MdeModulePkg CapsuleApp: Fix VS2012 build failure caused by 5410502

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Thursday, July 26, 2018 6:17 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star ; Yao, Jiewen ; Bi, 
Dandan 
Subject: [PATCH 1/6] MdeModulePkg CapsuleApp: Fix VS2012 build failure caused 
by 5410502

The build failure is like below.
xxx\CapsuleApp.c(868) : error C2275: 'EFI_GUID' :
  illegal use of this type as an expression
xxx/UefiBaseType.h(29) : see declaration of 'EFI_GUID'
xxx\CapsuleApp.c(868) : error C2146: syntax error :
  missing ';' before identifier 'ImageTypeId'
xxx\CapsuleApp.c(868) : error C2065: 'ImageTypeId' : undeclared identifier
xxx\CapsuleApp.c(869) : error C2275: 'UINTN' :
  illegal use of this type as an expression
xxx\ProcessorBind.h(224) : see declaration of 'UINTN'
xxx\CapsuleApp.c(869) : error C2146: syntax error :
  missing ';' before identifier 'ImageIndex'
xxx\CapsuleApp.c(869) : error C2065: 'ImageIndex' : undeclared identifier

Cc: Jiewen Yao 
Cc: Dandan Bi 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Application/CapsuleApp/CapsuleApp.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c 
b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
index df5de91ef524..95aa20760560 100644
--- a/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
+++ b/MdeModulePkg/Application/CapsuleApp/CapsuleApp.c
@@ -809,14 +809,16 @@ UefiMain (
   UINTN FileSize[MAX_CAPSULE_NUM];
   VOID  *CapsuleBuffer[MAX_CAPSULE_NUM];
   EFI_CAPSULE_BLOCK_DESCRIPTOR  *BlockDescriptors;
-  EFI_CAPSULE_HEADER *CapsuleHeaderArray[MAX_CAPSULE_NUM + 1];
-  UINT64 MaxCapsuleSize;
-  EFI_RESET_TYPE ResetType;
-  BOOLEANNeedReset;
-  BOOLEANNoReset;
-  CHAR16 *CapsuleName;
-  UINTN  CapsuleNum;
-  UINTN  Index;
+  EFI_CAPSULE_HEADER*CapsuleHeaderArray[MAX_CAPSULE_NUM + 1];
+  UINT64MaxCapsuleSize;
+  EFI_RESET_TYPEResetType;
+  BOOLEAN   NeedReset;
+  BOOLEAN   NoReset;
+  CHAR16*CapsuleName;
+  UINTN CapsuleNum;
+  UINTN Index;
+  EFI_GUID  ImageTypeId;
+  UINTN ImageIndex;
 
   Status = GetArg();
   if (EFI_ERROR(Status)) {
@@ -865,8 +867,6 @@ UefiMain (
   return EFI_UNSUPPORTED;
 }
 
-EFI_GUID  ImageTypeId;
-UINTN ImageIndex;
 //
 // FMP->GetImage()
 //
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] UefiCpuPkg/MpInitLib: Fix VS2012 build failure

[Bi, Dandan]

Sure.
I will add the comments before commit it.

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Thursday, July 19, 2018 8:04 PM
To: Bi, Dandan ; edk2-devel@lists.01.org
Cc: Dong, Eric 
Subject: Re: [edk2] [patch] UefiCpuPkg/MpInitLib: Fix VS2012 build failure

Hi Dandan,

On 07/19/18 06:50, Dandan Bi wrote:
> Cc: Eric Dong 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi 
> ---
>  UefiCpuPkg/Library/MpInitLib/Microcode.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/UefiCpuPkg/Library/MpInitLib/Microcode.c 
> b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> index efda143e67..9726172fbd 100644
> --- a/UefiCpuPkg/Library/MpInitLib/Microcode.c
> +++ b/UefiCpuPkg/Library/MpInitLib/Microcode.c
> @@ -61,10 +61,12 @@ MicrocodeDetect (
>VOID*MicrocodeData;
>MSR_IA32_PLATFORM_ID_REGISTER   PlatformIdMsr;
>UINT32  ProcessorFlags;
>UINT32  ThreadId;
>  
> +  ProcessorFlags = 0;
> +
>if (CpuMpData->MicrocodePatchRegionSize == 0) {
>  //
>  // There is no microcode patches
>  //
>  return;
> 

can you please add the comment from

  https://bugzilla.tianocore.org/show_bug.cgi?id=607

namely:

  //
  // set ProcessorFlags to suppress incorrect compiler/analyzer warnings
  //
  ProcessorFlags = 0;

Thanks!
Laszlo
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/1] MdeModulePkg/DisplayEngineDxe: Fix small InitializeDisplayEngine leak

[Bi, Dandan]

Reviewed-by: Dandan Bi 


Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Thomas 
Palmer
Sent: Wednesday, July 4, 2018 12:46 AM
To: edk2-devel@lists.01.org
Cc: Dong, Eric ; Zeng, Star 
Subject: [edk2] [PATCH 1/1] MdeModulePkg/DisplayEngineDxe: Fix small 
InitializeDisplayEngine leak

After calling RegisterHotKey, the allocated memory in NewString should be freed.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer 
---
 MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c 
b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
index f2eac4d3fece..7390f954b67f 100644
--- a/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
+++ b/MdeModulePkg/Universal/DisplayEngineDxe/FormDisplay.c
@@ -4221,11 +4221,13 @@ InitializeDisplayEngine (
 NewString = HiiGetString (gHiiHandle, STRING_TOKEN 
(FUNCTION_TEN_STRING), NULL);
 ASSERT (NewString != NULL);
 FormBrowserEx2->RegisterHotKey (, BROWSER_ACTION_SUBMIT, 0, 
NewString);
+FreePool (NewString);
 
 HotKey.ScanCode   = SCAN_F9;
 NewString = HiiGetString (gHiiHandle, STRING_TOKEN 
(FUNCTION_NINE_STRING), NULL);
 ASSERT (NewString != NULL);
 FormBrowserEx2->RegisterHotKey (, BROWSER_ACTION_DEFAULT, 
EFI_HII_DEFAULT_CLASS_STANDARD, NewString);
+FreePool (NewString);
   }
 
   return EFI_SUCCESS;
--
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg SataControllerDxe: Use compare logic in if condition

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, July 2, 2018 5:42 PM
To: edk2-devel@lists.01.org
Cc: Wu, Hao A ; Bi, Dandan ; Zeng, 
Star 
Subject: [edk2] [PATCH] MdeModulePkg SataControllerDxe: Use compare logic in if 
condition

Use compare logic in if condition to fix ECC issue.
It is caused by aa4240edff41034d709938a15b42cf4fd3214386.

Cc: Hao Wu 
Cc: Dandan Bi 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c 
b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
index d47e918f5757..d3af4c626ef5 100644
--- a/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
+++ b/MdeModulePkg/Bus/Pci/SataControllerDxe/SataController.c
@@ -483,7 +483,7 @@ SataControllerStart (
 }
 MaxPortNumber = 31;
 while (MaxPortNumber > 0) {
-  if (Data32 & (1 << MaxPortNumber)) {
+  if ((Data32 & (UINT32) (1 << MaxPortNumber)) != 0) {
 break;
   }
   MaxPortNumber--;
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg Variable: Add/Correct GetHobVariableStore para description

[Bi, Dandan]

Reviewed-by:  Dandan Bi 

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Monday, July 2, 2018 4:57 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan ; Gao, Liming ; Zeng, 
Star 
Subject: [edk2] [PATCH] MdeModulePkg Variable: Add/Correct GetHobVariableStore 
para description

It is caused by 09808bd39b0c76559354253639766458ec24da79.

Cc: Liming Gao 
Cc: Dandan Bi 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng 
---
 MdeModulePkg/Universal/Variable/Pei/Variable.c| 3 +++
 MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Variable/Pei/Variable.c 
b/MdeModulePkg/Universal/Variable/Pei/Variable.c
index d75a13e2b079..96a52f23d1c1 100644
--- a/MdeModulePkg/Universal/Variable/Pei/Variable.c
+++ b/MdeModulePkg/Universal/Variable/Pei/Variable.c
@@ -498,6 +498,9 @@ CompareWithValidVariable (
 /**
   Get HOB variable store.
 
+  @param[out] StoreInfo Return the store info.
+  @param[out] VariableStoreHeader   Return variable store header.
+
 **/
 VOID
 GetHobVariableStore (
diff --git a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c 
b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
index 42b0bfda570d..1ea2f84dda68 100644
--- a/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
+++ b/MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c
@@ -4173,7 +4173,7 @@ ConvertNormalVarStorageToAuthVarStorage (
 /**
   Get HOB variable store.
 
-  @param[out] VariableGuid  NV variable store signature.
+  @param[in] VariableGuid   NV variable store signature.
 
   @retval EFI_SUCCESS   Function successfully executed.
   @retval EFI_OUT_OF_RESOURCES  Fail to allocate enough memory resource.
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] ShellPkg/dp: Correct case of included file

[Bi, Dandan]

Reviewed-by: Dandan Bi 
Thanks for helping fix it.


Thanks,
Dandan
-Original Message-
From: dann frazier [mailto:da...@debian.org] 
Sent: Wednesday, June 27, 2018 6:05 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan ; Gao, Liming ; Ni, 
Ruiyu 
Subject: [PATCH] ShellPkg/dp: Correct case of included file

Cc: Dandan Bi 
Cc: Liming Gao 
Cc: Ruiyu Ni 
Fixes: f45dd2dd4f1d6fab4bb62bfd5f4e71cb7849897d
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: dann frazier 
---
 ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h 
b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
index 96bc89db8d..0e6e9422ef 100644
--- a/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
+++ b/ShellPkg/DynamicCommand/DpDynamicCommand/Dp.h
@@ -41,7 +41,7 @@
 #include 
 #include 
 #include  -#include 
+#include 
 
 extern EFI_HANDLE mDpHiiHandle;
 
--
2.18.0

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/AtaAtapiPassThru: Fix VS2010/VS2012 build failure

[Bi, Dandan]

Reviewed-by: Dandan Bi 

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, June 11, 2018 10:37 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan 
Subject: [PATCH] MdeModulePkg/AtaAtapiPassThru: Fix VS2010/VS2012 build failure

The patch doesn't have functionality impact. It is just to make
VS2010/VS2012 happy.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni 
Cc: Dandan Bi 
---
 MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c 
b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
index 1bae1e8e0c..5da5018345 100644
--- a/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
+++ b/MdeModulePkg/Bus/Ata/AtaAtapiPassThru/AhciMode.c
@@ -2381,7 +2381,7 @@ AhciEnableDevSlp (
 //
 // Assume DEVSLP TIMING VARIABLES is not supported if the Identify Device 
Data log (30h, 8) fails
 //
-DevSlpTiming.Supported = 0;
+ZeroMem (, sizeof (DevSlpTiming));
   } else {
 CopyMem (, [48], sizeof (DevSlpTiming));
 DEBUG ((DEBUG_INFO, "DevSlpTiming: Supported(%d), Deto(%d), Madt(%d)\n",
-- 
2.16.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 2/2] ShellPkg/UefiShellAcpiViewCommandLib: Fix ECC issues

[Bi, Dandan]

Hi Alexei,

Current in the Edk2 implementation, the guard macros in the include header 
files start with underscore and end with underscore.  And the number of 
underscore usually used here is one or two.

And the check tool (ECC) also follow above rule to do the check. So it will 
report error for the ACPIPARSER_H_ 
So do you agree to keep the changes in the patch or update it to_ ACPIPARSER_H_ 
for alignment consideration firstly?

Then there is another topic, we need to make the Check Tool align with CSS, we 
may enhance the check tool or update the Spec.

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Alexei 
Fedorov
Sent: Tuesday, June 05, 2018 5:13 PM
To: Bi, Dandan ; edk2-devel@lists.01.org
Cc: Carsey, Jaben ; Ni, Ruiyu 
Subject: Re: [edk2] [patch 2/2] ShellPkg/UefiShellAcpiViewCommandLib: Fix ECC 
issues

Hi Dandan Bi,


Your patch contains a number of modifications like the one below:

-#ifndef ACPIPARSER_H_
-#define ACPIPARSER_H_
+#ifndef __ACPIPARSER_H__
+#define __ACPIPARSER_H__


which violate CCS

"3.3.2 Include Files"

"4.3.5.4 The names of guard macros shall end with an underscore character."

and the given examples.


Alexei


From: edk2-devel  on behalf of Dandan Bi 

Sent: 05 June 2018 09:33
To: edk2-devel@lists.01.org
Cc: Jaben Carsey; Ruiyu Ni
Subject: [edk2] [patch 2/2] ShellPkg/UefiShellAcpiViewCommandLib: Fix ECC issues

1. Separate variable definition and initialization.
2. Make the variable naming following Edk2 rule.
Naming convention of local variable:
a.First character should be upper case.
b.Must contain lower case characters.
c.No white space characters.

Cc: Sami Mujawar 
Cc: Evan Lloyd 
Cc: Sami Mujawar 
Cc: Evan Lloyd 
Cc: Jaben Carsey 
Cc: Ruiyu Ni 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi 
---
 .../UefiShellAcpiViewCommandLib/AcpiParser.c   | 44 ++--
 .../UefiShellAcpiViewCommandLib/AcpiParser.h   |  6 +--
 .../UefiShellAcpiViewCommandLib/AcpiTableParser.c  | 50 +--  
.../UefiShellAcpiViewCommandLib/AcpiTableParser.h  |  6 +--  
.../Library/UefiShellAcpiViewCommandLib/AcpiView.c | 58 ++  
.../Library/UefiShellAcpiViewCommandLib/AcpiView.h | 16 +++---
 .../Parsers/Dbg2/Dbg2Parser.c  |  5 +-
 .../Parsers/Gtdt/GtdtParser.c  |  5 +-
 .../Parsers/Iort/IortParser.c  | 26 +-
 .../Parsers/Madt/MadtParser.c  |  4 +-
 .../Parsers/Rsdp/RsdpParser.c  | 10 +++-
 .../Parsers/Slit/SlitParser.c  | 44 
 .../Parsers/Spcr/SpcrParser.c  | 10 +++-
 .../Parsers/Srat/SratParser.c  | 21 +---
 .../UefiShellAcpiViewCommandLib.c  |  5 +-
 .../UefiShellAcpiViewCommandLib.h  |  6 +--
 .../UefiShellAcpiViewCommandLib.inf|  3 ++
 17 files changed, 190 insertions(+), 129 deletions(-)

diff --git a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c 
b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
index 088575d0144..6d3bc451acd 100644
--- a/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
+++ b/ShellPkg/Library/UefiShellAcpiViewCommandLib/AcpiParser.c
@@ -19,10 +19,19 @@

 STATIC UINT32   gIndent;
 STATIC UINT32   mTableErrorCount;
 STATIC UINT32   mTableWarningCount;

+STATIC ACPI_DESCRIPTION_HEADER_INFO AcpiHdrInfo;
+
+/**
+  An ACPI_PARSER array describing the ACPI header.
+**/
+STATIC CONST ACPI_PARSER AcpiHeaderParser[] = {
+  PARSE_ACPI_HEADER ()
+};
+
 /**
   This function resets the ACPI table error counter to Zero.
 **/
 VOID
 ResetErrorCount (
@@ -112,14 +121,17 @@ VerifyChecksum (
   IN BOOLEAN Log,
   IN UINT8*  Ptr,
   IN UINT32  Length
   )
 {
-  UINTN ByteCount = 0;
-  UINT8 Checksum = 0;
+  UINTN ByteCount;
+  UINT8 Checksum;
   UINTN OriginalAttribute;

+  ByteCount = 0;
+  Checksum = 0;
+
   while (ByteCount < Length) {
 Checksum += *(Ptr++);
 ByteCount++;
   }

@@ -164,15 +176,18 @@ EFIAPI
 DumpRaw (
   IN UINT8* Ptr,
   IN UINT32 Length
   )
 {
-  UINTN ByteCount = 0;
+  UINTN ByteCount;
   UINTN PartLineChars;
-  UINTN AsciiBufferIndex = 0;
+  UINTN AsciiBufferIndex;
   CHAR8 AsciiBuffer[17];

+  ByteCount = 0;
+  AsciiBufferIndex = 0;
+
   Print (L"Address  : 0x%p\n", Ptr);
   Print (L"Length   : %d\n", Length);

   while (ByteCount < Length) {
 if ((ByteCount & 0x0F) == 0) {
@@ -275,11 +290,14 @@ DumpUint64 (
   )
 {
   // Some fields are not aligned and this causes alignment faults
   // on ARM platforms if the compiler generates LDRD instructions.
   // Perform word access so that LDRD instructions are not generated.
-  UINT64 Val = *(UINT32*)(Ptr + sizeof (UINT32));
+  UINT64 Val;
+
+  Val = *(UINT32*)(Ptr + sizeof (UINT32));
+
   Val <<= 32;
   Val |= *(UIN

Re: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages

[Bi, Dandan]

Hi Star,

Yes. You are right. mAcpiBootPerformanceTable->Header.Length will be updated 
accordingly. We can get the real table length.
Currently there are some contents in the table are not updated, just use the 
value in the memory.
Previously the memory value is zero.  But without ZeroMem(), the value may be 
non-zero. That's the difference. It may impact the code to parse the table.

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Friday, May 25, 2018 10:45 AM
To: Bi, Dandan <dandan...@intel.com>; Ard Biesheuvel 
<ard.biesheu...@linaro.org>; Laszlo Ersek <ler...@redhat.com>
Cc: Dong, Eric <eric.d...@intel.com>; edk2-devel@lists.01.org; Gao, Liming 
<liming@intel.com>; Leif Lindholm <leif.lindh...@linaro.org>; Kinney, 
Michael D <michael.d.kin...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use 
AllocatePeiAccessiblePages

mAcpiBootPerformanceTable->Header.Length could reflect the real table length, 
right?
When the padding (from the PCD) memory is used, 
mAcpiBootPerformanceTable->Header.Length will be updated accordingly.
If that is the case, it seems safe without ZeroMem.
Anyway it needs to be verified.


But, to be simple, I do not object to have ZeroMem to be equivalent with 
previous code.



Thanks,
Star
-Original Message-
From: Bi, Dandan
Sent: Friday, May 25, 2018 10:01 AM
To: Ard Biesheuvel <ard.biesheu...@linaro.org>; Laszlo Ersek <ler...@redhat.com>
Cc: Dong, Eric <eric.d...@intel.com>; edk2-devel@lists.01.org; Gao, Liming 
<liming@intel.com>; Leif Lindholm <leif.lindh...@linaro.org>; Kinney, 
Michael D <michael.d.kin...@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use 
AllocatePeiAccessiblePages

Hi Ard,

Thank you very much for helping fix this issue.

And for ZeroMem(), it should be added back.
Because after the memory is allocated, the optional padding (from the PCD) 
memory will be used directly. 
If ZeoMem() is dropped, then some contents in the padding memory will not be 
zero. Thus will impact the tool to parse the contents.

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, May 24, 2018 8:54 PM
To: Laszlo Ersek <ler...@redhat.com>
Cc: Dong, Eric <eric.d...@intel.com>; edk2-devel@lists.01.org; Gao, Liming 
<liming@intel.com>; Bi, Dandan <dandan...@intel.com>; Leif Lindholm 
<leif.lindh...@linaro.org>; Kinney, Michael D <michael.d.kin...@intel.com>; 
Zeng, Star <star.z...@intel.com>
Subject: Re: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use 
AllocatePeiAccessiblePages

On 24 May 2018 at 14:49, Laszlo Ersek <ler...@redhat.com> wrote:
> On 05/24/18 11:09, Ard Biesheuvel wrote:
>> Replace the call to and implementation of the function
>> FpdtAllocateReservedMemoryBelow4G() with a call to 
>> AllocatePeiAccessiblePages, which boils down to the same on X64, but 
>> does not crash non-X64 systems that lack memory below 4 GB.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>> Note that the ZeroMem() call is dropped, but it is redundant anyway, 
>> given that the subsequent CopyMem() call supersedes it immediately.
>
> I'm not sure the ZeroMem() is redundant. The allocation size -- before 
> rounding up to full pages -- is computed like this:
>
>   BootPerformanceDataSize = sizeof (BOOT_PERFORMANCE_TABLE) + 
> mPerformanceLength + PcdGet32 (PcdExtFpdtBootRecordPadSize);
>   if (SmmCommData != NULL && SmmBootRecordData != NULL) {
> BootPerformanceDataSize += SmmBootRecordDataSize;
>   }
>
> ZeroMem() covers all of the above, but the CopyMem() calls don't seem to 
> cover the optional padding (from the PCD).
>
> I'm unsure if that matters, of course.
>

You're quite right. I'm not sure how I missed that.

In any case, I can add back the ZeroMem () quite easily after the single 
invocation of AllocatePeiAccessiblePages() that I am adding in this file.

> The patch looks good to me otherwise.
>
> Thanks
> Laszlo
>
>
>>
>>  MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c |
>> 45 ++--
>>  1 file changed, 4 insertions(+), 41 deletions(-)
>>
>> diff --git
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> index 71d624fc9ce9..b1f09710b65c 100644
>> ---
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> +++ b/MdeModulePkg/Li

Re: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages

[Bi, Dandan]

Hi Ard,

Thank you very much for helping fix this issue.

And for ZeroMem(), it should be added back.
Because after the memory is allocated, the optional padding (from the PCD) 
memory will be used directly. 
If ZeoMem() is dropped, then some contents in the padding memory will not be 
zero. Thus will impact the tool to parse the contents.

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Ard 
Biesheuvel
Sent: Thursday, May 24, 2018 8:54 PM
To: Laszlo Ersek <ler...@redhat.com>
Cc: Dong, Eric <eric.d...@intel.com>; edk2-devel@lists.01.org; Gao, Liming 
<liming....@intel.com>; Bi, Dandan <dandan...@intel.com>; Leif Lindholm 
<leif.lindh...@linaro.org>; Kinney, Michael D <michael.d.kin...@intel.com>; 
Zeng, Star <star.z...@intel.com>
Subject: Re: [edk2] [PATCH v2 4/5] MdeModulePkg/DxeCorePerformanceLib: use 
AllocatePeiAccessiblePages

On 24 May 2018 at 14:49, Laszlo Ersek <ler...@redhat.com> wrote:
> On 05/24/18 11:09, Ard Biesheuvel wrote:
>> Replace the call to and implementation of the function
>> FpdtAllocateReservedMemoryBelow4G() with a call to 
>> AllocatePeiAccessiblePages, which boils down to the same on X64, but 
>> does not crash non-X64 systems that lack memory below 4 GB.
>>
>> Contributed-under: TianoCore Contribution Agreement 1.1
>> Signed-off-by: Ard Biesheuvel <ard.biesheu...@linaro.org>
>> ---
>> Note that the ZeroMem() call is dropped, but it is redundant anyway, 
>> given that the subsequent CopyMem() call supersedes it immediately.
>
> I'm not sure the ZeroMem() is redundant. The allocation size -- before 
> rounding up to full pages -- is computed like this:
>
>   BootPerformanceDataSize = sizeof (BOOT_PERFORMANCE_TABLE) + 
> mPerformanceLength + PcdGet32 (PcdExtFpdtBootRecordPadSize);
>   if (SmmCommData != NULL && SmmBootRecordData != NULL) {
> BootPerformanceDataSize += SmmBootRecordDataSize;
>   }
>
> ZeroMem() covers all of the above, but the CopyMem() calls don't seem to 
> cover the optional padding (from the PCD).
>
> I'm unsure if that matters, of course.
>

You're quite right. I'm not sure how I missed that.

In any case, I can add back the ZeroMem () quite easily after the single 
invocation of AllocatePeiAccessiblePages() that I am adding in this file.

> The patch looks good to me otherwise.
>
> Thanks
> Laszlo
>
>
>>
>>  MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c | 
>> 45 ++--
>>  1 file changed, 4 insertions(+), 41 deletions(-)
>>
>> diff --git 
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
>> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> index 71d624fc9ce9..b1f09710b65c 100644
>> --- 
>> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
>> +++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLi
>> +++ b.c
>> @@ -165,46 +165,6 @@ IsKnownID (
>>}
>>  }
>>
>> -/**
>> -  Allocate EfiReservedMemoryType below 4G memory address.
>> -
>> -  This function allocates EfiReservedMemoryType below 4G memory address.
>> -
>> -  @param[in]  Size   Size of memory to allocate.
>> -
>> -  @return Allocated address for output.
>> -
>> -**/
>> -VOID *
>> -FpdtAllocateReservedMemoryBelow4G (
>> -  IN UINTN   Size
>> -  )
>> -{
>> -  UINTN Pages;
>> -  EFI_PHYSICAL_ADDRESS  Address;
>> -  EFI_STATUSStatus;
>> -  VOID  *Buffer;
>> -
>> -  Buffer  = NULL;
>> -  Pages   = EFI_SIZE_TO_PAGES (Size);
>> -  Address = 0x;
>> -
>> -  Status = gBS->AllocatePages (
>> -  AllocateMaxAddress,
>> -  EfiReservedMemoryType,
>> -  Pages,
>> -  
>> -  );
>> -  ASSERT_EFI_ERROR (Status);
>> -
>> -  if (!EFI_ERROR (Status)) {
>> -Buffer = (VOID *) (UINTN) Address;
>> -ZeroMem (Buffer, Size);
>> -  }
>> -
>> -  return Buffer;
>> -}
>> -
>>  /**
>>Allocate buffer for Boot Performance table.
>>
>> @@ -348,7 +308,10 @@ AllocateBootPerformanceTable (
>>  //
>>  // Fail to allocate at specified address, continue to allocate at any 
>> address.
>>  //
>> -mAcpiBootPerformanceTable = (BOOT_PERFORMANCE_TABLE *) 
>> FpdtAllocateReservedMemoryBelow4G (BootPerformanceDataSize);
>> +mAcpiBootPerformanceTable = (BOOT_PERFORMANCE_TABLE 

Re: [edk2] [Patch 2/2] MdePkg/TcgStorage*.h: Fix ECC reported issues.

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

And these changes are in SecurityPkg not MdePkg.
Please update the package name in the subject of the patch before commit.


Thanks,
Dandan

-Original Message-
From: Dong, Eric 
Sent: Tuesday, May 22, 2018 1:51 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>
Subject: [Patch 2/2] MdePkg/TcgStorage*.h: Fix ECC reported issues.

Cc: Dandan Bi <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.d...@intel.com>
---
 SecurityPkg/Include/Library/TcgStorageCoreLib.h|  2 +-
 SecurityPkg/Include/Library/TcgStorageOpalLib.h| 12 ++--
 SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalUtil.c |  2 +-
 3 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/SecurityPkg/Include/Library/TcgStorageCoreLib.h 
b/SecurityPkg/Include/Library/TcgStorageCoreLib.h
index 97f9a9f968..6e178c968f 100644
--- a/SecurityPkg/Include/Library/TcgStorageCoreLib.h
+++ b/SecurityPkg/Include/Library/TcgStorageCoreLib.h
@@ -2,7 +2,7 @@
   Public API for the Tcg Core library to perform the lowest level TCG Data 
encoding.
   
   (TCG Storage Architecture Core Specification, Version 2.01, Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-architecture-core-specification/)
+  
https://trustedcomputinggroup.org/tcg-storage-architecture-core-specification/)
 
   Check http://trustedcomputinggroup.org for latest specification updates.
 
diff --git a/SecurityPkg/Include/Library/TcgStorageOpalLib.h 
b/SecurityPkg/Include/Library/TcgStorageOpalLib.h
index b3092eb5cd..33f8fee183 100644
--- a/SecurityPkg/Include/Library/TcgStorageOpalLib.h
+++ b/SecurityPkg/Include/Library/TcgStorageOpalLib.h
@@ -2,22 +2,22 @@
   Public API for Opal Core library.
 
   (TCG Storage Architecture Core Specification, Version 2.01, Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-architecture-core-specification/
+  
https://trustedcomputinggroup.org/tcg-storage-architecture-core-specification/
 
   Storage Work Group Storage Security Subsystem Class: Pyrite, Version 1.00 
Final, Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-pyrite/
+  
https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-pyrite/
 
   Storage Work Group Storage Security Subsystem Class: Opal, Version 2.01 
Final, Revision 1.00,
-  
@https://trustedcomputinggroup.org/storage-work-group-storage-security-subsystem-class-opal/
+  
https://trustedcomputinggroup.org/storage-work-group-storage-security-subsystem-class-opal/
 
   TCG Storage Security Subsystem Class: Opalite Version 1.00 Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-opalite/
+  
https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-opalite/
 
   TCG Storage Feature Set: Block SID Authentication, Version 1.00 Final, 
Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-feature-set-block-sid-authentication-specification/
+  
https://trustedcomputinggroup.org/tcg-storage-feature-set-block-sid-authentication-specification/
 
   TCG Storage Opal SSC Feature Set: PSID Version 1.00, Revision 1.00,
-  @https://trustedcomputinggroup.org/tcg-storage-opal-feature-set-psid/)
+  https://trustedcomputinggroup.org/tcg-storage-opal-feature-set-psid/)
 
   Check http://trustedcomputinggroup.org for latest specification updates.
 
diff --git a/SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalUtil.c 
b/SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalUtil.c
index a8bf3a9160..ca8e7fbbdf 100644
--- a/SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalUtil.c
+++ b/SecurityPkg/Library/TcgStorageOpalLib/TcgStorageOpalUtil.c
@@ -981,7 +981,7 @@ OpalUtilGetActiveDataRemovalMechanism (
 /**
   Calculate the estimated time.
 
-  @param[in]  IsMinite   Whether the input time value is 
minute type or second type.
+  @param[in]  IsMinute   Whether the input time value is 
minute type or second type.
   @param[in]  Time   The input time value.
 
 **/
-- 
2.15.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch 1/2] MdePkg/TcgStorage*.h: Fixed ECC reported issues.

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Dong, Eric 
Sent: Tuesday, May 22, 2018 1:51 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>
Subject: [Patch 1/2] MdePkg/TcgStorage*.h: Fixed ECC reported issues.

Cc: Dandan Bi <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.d...@intel.com>
---
 MdePkg/Include/IndustryStandard/TcgStorageCore.h | 2 +-  
MdePkg/Include/IndustryStandard/TcgStorageOpal.h | 8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/MdePkg/Include/IndustryStandard/TcgStorageCore.h 
b/MdePkg/Include/IndustryStandard/TcgStorageCore.h
index ab121722ba..0b2852e92d 100644
--- a/MdePkg/Include/IndustryStandard/TcgStorageCore.h
+++ b/MdePkg/Include/IndustryStandard/TcgStorageCore.h
@@ -2,7 +2,7 @@
   TCG defined values and structures.
 
   (TCG Storage Architecture Core Specification, Version 2.01, Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-architecture-core-specification/)
+  
+ https://trustedcomputinggroup.org/tcg-storage-architecture-core-specif
+ ication/)
 
   Check http://trustedcomputinggroup.org for latest specification updates.
 
diff --git a/MdePkg/Include/IndustryStandard/TcgStorageOpal.h 
b/MdePkg/Include/IndustryStandard/TcgStorageOpal.h
index ace7309cee..e8f313c3d3 100644
--- a/MdePkg/Include/IndustryStandard/TcgStorageOpal.h
+++ b/MdePkg/Include/IndustryStandard/TcgStorageOpal.h
@@ -2,16 +2,16 @@
   Opal Specification defined values and structures.
 
   (TCG Storage Architecture Core Specification, Version 2.01, Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-architecture-core-specification/
+  
+ https://trustedcomputinggroup.org/tcg-storage-architecture-core-specif
+ ication/
 
   Storage Work Group Storage Security Subsystem Class: Pyrite, Version 1.00 
Final, Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-pyrite/
+  
+ https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class
+ -pyrite/
 
   Storage Work Group Storage Security Subsystem Class: Opal, Version 2.01 
Final, Revision 1.00,
-  
@https://trustedcomputinggroup.org/storage-work-group-storage-security-subsystem-class-opal/
+  
+ https://trustedcomputinggroup.org/storage-work-group-storage-security-
+ subsystem-class-opal/
 
   TCG Storage Security Subsystem Class: Opalite Version 1.00 Revision 1.00,
-  
@https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class-opalite/)
+  
+ https://trustedcomputinggroup.org/tcg-storage-security-subsystem-class
+ -opalite/)
 
   Check http://trustedcomputinggroup.org for latest specification updates.
 
--
2.15.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 3/8] MdeModulePkg/DxeCorePerformanceLib:Track FPDT record in DXE phase

[Bi, Dandan]

Sorry for the delayed response.

The allocated  performance table ( below 4G ) is to save the boot performance 
data in normal boot and S3 phase.
PEIM FirmwarePerformancePei will get the address of the performance table and 
update the performance date of S3 phase to the table.
The address need to be handled in PEI phase(32bit), that's the main reason why 
we allocate it below 4G.


Thanks,
Dandan

-Original Message-
From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org] 
Sent: Wednesday, May 2, 2018 12:27 AM
To: Bi, Dandan <dandan...@intel.com>; Leif Lindholm <leif.lindh...@linaro.org>
Cc: edk2-devel@lists.01.org; Zeng, Star <star.z...@intel.com>; Gao, Liming 
<liming@intel.com>; Matt Sealey <n...@bakuhatsu.net>
Subject: Re: [edk2] [PATCH v2 3/8] MdeModulePkg/DxeCorePerformanceLib:Track 
FPDT record in DXE phase

On 30 January 2018 at 14:53, Dandan Bi <dandan...@intel.com> wrote:
> V2:
> Update DxecorePerformanceLib to report the boot performance table
> address instead of records contents.
>
> Updated to convert Pref entry to FPDT record in DXE phase and then
> allocate boot performance table to save the record and report
> the address of boot performance table to FirmwarePerformanceDxe.
>
> Cc: Liming Gao <liming@intel.com>
> Cc: Star Zeng <star.z...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  .../DxeCorePerformanceLib/DxeCorePerformanceLib.c  | 1389 
> +++-
>  .../DxeCorePerformanceLib.inf  |   20 +-
>  .../DxeCorePerformanceLibInternal.h|   17 +-
>  3 files changed, 1108 insertions(+), 318 deletions(-)
>
> diff --git 
> a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c 
> b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> index 7c0e207..c6f8a16 100644
> --- a/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> +++ b/MdeModulePkg/Library/DxeCorePerformanceLib/DxeCorePerformanceLib.c
> @@ -8,11 +8,11 @@
>which are consumed by DxePerformanceLib to logging performance data in DXE 
> phase.
>
>This library is mainly used by DxeCore to start performance logging to 
> ensure that
>Performance Protocol is installed at the very beginning of DXE phase.
>
> -Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
> +Copyright (c) 2006 - 2018, Intel Corporation. All rights reserved.
>  (C) Copyright 2016 Hewlett Packard Enterprise Development LP
>  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
> @@ -23,27 +23,65 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
> EXPRESS OR IMPLIED.
>  **/
>
>
>  #include "DxeCorePerformanceLibInternal.h"
>
> -
>  //
> -// The data structure to hold global performance data.
> +// Data for FPDT performance records.
>  //
> -GAUGE_DATA_HEADER*mGaugeData;
> +#define SMM_BOOT_RECORD_COMM_SIZE (OFFSET_OF (EFI_SMM_COMMUNICATE_HEADER, 
> Data) + sizeof(SMM_BOOT_RECORD_COMMUNICATE))
> +#define STRING_SIZE (EDKII_STRING_EVENT_RECORD_NAME_LENGTH * 
> sizeof (CHAR8))
> +#define MAX_RECORD_SIZE (sizeof (DYNAMIC_STRING_EVENT_RECORD) + 
> STRING_SIZE)
> +#define FIRMWARE_RECORD_BUFFER  0x1
> +#define CACHE_HANDLE_GUID_COUNT 0x1000
> +
> +BOOT_PERFORMANCE_TABLE  *mAcpiBootPerformanceTable = NULL;
> +BOOT_PERFORMANCE_TABLE  mBootPerformanceTableTemplate = {
> +  {
> +EFI_ACPI_5_0_FPDT_BOOT_PERFORMANCE_TABLE_SIGNATURE,
> +sizeof (BOOT_PERFORMANCE_TABLE)
> +  },
> +  {
> +{
> +  EFI_ACPI_5_0_FPDT_RUNTIME_RECORD_TYPE_FIRMWARE_BASIC_BOOT,// Type
> +  sizeof (EFI_ACPI_5_0_FPDT_FIRMWARE_BASIC_BOOT_RECORD),// Length
> +  EFI_ACPI_5_0_FPDT_RUNTIME_RECORD_REVISION_FIRMWARE_BASIC_BOOT // 
> Revision
> +},
> +0,  // Reserved
> +//
> +// These values will be updated at runtime.
> +//
> +0,  // ResetEnd
> +0,  // OsLoaderLoadImageStart
> +0,  // OsLoaderStartImageStart
> +0,  // ExitBootServicesEntry
> +0   // ExitBootServicesExit
> +  }
> +};
>
> -//
> -// The current maximum number of logging entries. If current number of
> -// entries exceeds this value, it will re-allocate a larger array and
> -// migration the old data to the larger array.
> -//
> -UINT32   mMaxGaugeRecords;
> +typedef struct {
> +  EFI_HANDLEHandle;
> +  CHAR8 NameString[EDKII_

Re: [edk2] [patch v2] BaseTools/VfrCompile: Avoid using uninitialized pointer

[Bi, Dandan]

Hi Ray,

Thanks for your suggestion. But we have committed this patch yesterday. :(
I will pay more attention to the commit message in the future work.


Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, May 10, 2018 11:34 AM
To: Gary Lin <g...@suse.com>; Bi, Dandan <dandan...@intel.com>
Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Gao, Liming 
<liming@intel.com>
Subject: RE: [edk2] [patch v2] BaseTools/VfrCompile: Avoid using uninitialized 
pointer

Dandan,
Can you describe the build failure met by Gary Lin in final commit message?
The current commit message is not very clear about which issue it may fix.

Thanks/Ray

> -Original Message-
> From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Gary 
> Lin
> Sent: Wednesday, May 9, 2018 4:20 PM
> To: Bi, Dandan <dandan...@intel.com>
> Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Gao, 
> Liming <liming@intel.com>
> Subject: Re: [edk2] [patch v2] BaseTools/VfrCompile: Avoid using 
> uninitialized pointer
> 
> On Wed, May 09, 2018 at 01:02:11PM +0800, Dandan Bi wrote:
> > V2:
> > Add function _INIT_OPHDR_COND () for variable initialization.
> > Make code logic more clean.
> >
> > Previously _CLEAR_SAVED_OPHDR () is used for variable 
> > initialization, and we updated it to clean memory.
> > But _CLEAR_SAVED_OPHDR () is still called for variable initialization.
> > This will cause uninitialized pointer will be checked to free and 
> > cause unexpected issue.
> >
> > This patch is to add new function for variable initialization and 
> > keep _CLEAR_SAVED_OPHDR () to clean memory which is aligned with its 
> > function name.
> >
> This patch fixes the build errors I had :)
> 
> Tested-by: Gary Lin <g...@suse.com>
> 
> > Cc: Eric Dong <eric.d...@intel.com>
> > Cc: Liming Gao <liming@intel.com>
> > Cc: Gary Lin <g...@suse.com>
> > Contributed-under: TianoCore Contribution Agreement 1.1
> > Signed-off-by: Dandan Bi <dandan...@intel.com>
> > ---
> >  BaseTools/Source/C/VfrCompile/VfrSyntax.g | 23
> > ---
> >  1 file changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> > b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> > index 4b0a43606ea..84dd2c3ed3f 100644
> > --- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> > +++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> > @@ -4084,11 +4084,19 @@ vfrStatementInvalidSaveRestoreDefaults :
> >
> >  //
> >  // Root expression extension function called by other function.
> >  //
> >  vfrStatementExpression [UINT32 RootLevel, UINT32 ExpOpCount = 0] :
> > -  << if ($RootLevel == 0) {mCIfrOpHdrIndex ++; if (mCIfrOpHdrIndex 
> > >=
> > MAX_IFR_EXPRESSION_DEPTH) _PCATCH
> (VFR_RETURN_INVALID_PARAMETER, 0,
> > "The depth of expression exceeds the max supported level 8!"); 
> > _CLEAR_SAVED_OPHDR ();} >>
> > +   <<
> > +  if ($RootLevel 
> > == 0) {
> > +
> > mCIfrOpHdrIndex ++;
> > +if 
> > + (mCIfrOpHdrIndex >=
> MAX_IFR_EXPRESSION_DEPTH) {
> > +  
> > + _PCATCH
> (VFR_RETURN_INVALID_PARAMETER, 0, "The depth of expression exceeds the 
> max supported level 8!");
> > +}
> > +
> > _INIT_OPHDR_COND ();
> > +  }
> > +   >>
> >andTerm[$RootLevel, $ExpOpCount]
> >(
> >  L:OR andTerm[$RootLevel, $ExpOpCount]  << $ExpOpCount++;
> CIfrOr OObj(L->getLine()); >>
> >)*
> > << @@ 
> > -4988,10
> > +4996,11 @@ private:
> >CIfrOpHeader *  mCIfrOpHdr[MAX_IFR_EXPRESSION_DEPTH];
> >UINT32  mCIfrOpHdrLineNo[MAX_IFR_EXPRESSION_DEPTH];
> >UINT8   mCIfrOpHdrIndex;
> >VOID_SAVE_OPHDR_COND (IN CIfrOpHeader &, IN BOOLEAN,
> UINT32 LineNo = 0);
> >VOID_CLEAR_SAVED_OPHDR (VOID);
> > +  VOID_INIT_OPHD

Re: [edk2] [patch] BaseTools/VfrCompile: Avoid using uninitialized pointer

[Bi, Dandan]

Thanks for your test work. 
I have created a V2 patch which make the code logic more clean. Would you mind 
to try the V2 patch in your environment?


Thanks,
Dandan

-Original Message-
From: Gary Lin [mailto:g...@suse.com] 
Sent: Wednesday, May 9, 2018 10:32 AM
To: Bi, Dandan <dandan...@intel.com>
Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Gao, Liming 
<liming@intel.com>
Subject: Re: [edk2] [patch] BaseTools/VfrCompile: Avoid using uninitialized 
pointer

On Tue, May 08, 2018 at 07:46:19PM +0800, Dandan Bi wrote:
> _CLEAR_SAVED_OPHDR () is used for initialize the variables.
> We should not update it to free memory.
> It will cause some pointer used before initialization.
> This patch is to fix this issue.
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  BaseTools/Source/C/VfrCompile/VfrSyntax.g | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g 
> b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> index 4b0a43606ea..cc042ab4307 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> +++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> @@ -4103,12 +4103,15 @@ vfrStatementExpression [UINT32 RootLevel, UINT32 
> ExpOpCount = 0] :
>}
>  }
>}
>
>if ($RootLevel == 
> 0) {
> -
> _CLEAR_SAVED_OPHDR ();
> -mCIfrOpHdrIndex 
> --;
> +if 
> (mCIfrOpHdr[mCIfrOpHdrIndex] != NULL) {
> +  delete 
> mCIfrOpHdr[mCIfrOpHdrIndex];
> +  
> mCIfrOpHdr[mCIfrOpHdrIndex] = NULL;
> +}

> + 
> + mCIfrOpHdrIndex --;
An extra space was added.

>}
> >>
>;
>  
>  //
> @@ -5082,14 +5085,11 @@ EfiVfrParser::_SAVE_OPHDR_COND (  VOID  
> EfiVfrParser::_CLEAR_SAVED_OPHDR (
>VOID
>)
>  {
> -  if (mCIfrOpHdr[mCIfrOpHdrIndex] != NULL) {
> -delete mCIfrOpHdr[mCIfrOpHdrIndex];
> -mCIfrOpHdr[mCIfrOpHdrIndex] = NULL;
> -  }
> +  mCIfrOpHdr[mCIfrOpHdrIndex]   = NULL;
>mCIfrOpHdrLineNo[mCIfrOpHdrIndex] = 0;  }
>  
>  BOOLEAN
>  EfiVfrParser::_SET_SAVED_OPHDR_SCOPE (
> --
I applied the patch and triggered the rebuild of ovmf. It's now built on all 
versions and arch.

Thanks for fixing it.

Tested-by: Gary Lin <g...@suse.com>

> 2.14.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
> 
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 1/2] BaseTools/VfrCompile:Fix memory leak issues

[Bi, Dandan]

Yes. We have submitted patch to fix it. Sorry for the inconvenience.

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Gary Lin
Sent: Tuesday, May 8, 2018 5:46 PM
To: Bi, Dandan <dandan...@intel.com>
Cc: edk2-devel@lists.01.org; Dong, Eric <eric.d...@intel.com>; Gao, Liming 
<liming@intel.com>
Subject: Re: [edk2] [patch 1/2] BaseTools/VfrCompile:Fix memory leak issues

On Tue, Apr 10, 2018 at 03:54:46PM +0800, Dandan Bi wrote:
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  BaseTools/Source/C/VfrCompile/VfrSyntax.g | 32 
> ++-
>  1 file changed, 31 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g 
> b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> index d48072a8adf..4b0a43606ea 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> +++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
Hi Dandan,

I encountered a build error with our build service:

[  197s] "VfrCompile" -l -n --string-db 
/home/abuild/rpmbuild/BUILD/ovmf-2018+git1525681922.053cd183c9f2/Build/OvmfX64/DEBUG_GCC5/X64/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/OUTPUT/BootMaintenanceManagerUiLibStrDefs.hpk
 --output-directory 
/home/abuild/rpmbuild/BUILD/ovmf-2018+git1525681922.053cd183c9f2/Build/OvmfX64/DEBUG_GCC5/X64/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/DEBUG/.
 
/home/abuild/rpmbuild/BUILD/ovmf-2018+git1525681922.053cd183c9f2/Build/OvmfX64/DEBUG_GCC5/X64/MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootMaintenanceManagerUiLib/OUTPUT/BootMaintenanceManager.i
[  197s] *** Error in 
`/home/abuild/rpmbuild/BUILD/ovmf-2018+git1525681922.053cd183c9f2/BaseTools/Source/C/bin/VfrCompile':
 free(): invalid pointer: 0xbabababababababa ***

If I reverted the following change, the package can be built again.

> @@ -5055,11 +5082,14 @@ EfiVfrParser::_SAVE_OPHDR_COND (  VOID  
> EfiVfrParser::_CLEAR_SAVED_OPHDR (
>VOID
>)
>  {
> -  mCIfrOpHdr[mCIfrOpHdrIndex]   = NULL;
> +  if (mCIfrOpHdr[mCIfrOpHdrIndex] != NULL) {
> +delete mCIfrOpHdr[mCIfrOpHdrIndex];
> +mCIfrOpHdr[mCIfrOpHdrIndex] = NULL;
> +  }
>mCIfrOpHdrLineNo[mCIfrOpHdrIndex] = 0;  }
>  
>  BOOLEAN
>  EfiVfrParser::_SET_SAVED_OPHDR_SCOPE (

I have no clue now and it happened all the time.

Would you mind to check the code?

Thanks,

Gary Lin
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/8] IntelFrameworkModulePkg/LegacyBootMaintUiLib: Update RouteConfig function

[Bi, Dandan]

Thanks for the updating. These changes make sense.
Reviewed-by: Dandan Bi <dandan...@intel.com>  for this patch series.

But the Spec seems not to be clear enough.
When looking into details about the "progress" parameter in EFI HII 
Configuration Routing Protocol and  EFI_HII_CONFIG_ACCESS_PROTOCOL.

Description of "progress" parameter in ExtractConfig() in UEFI 2.7 Spec:
Progress
On return, points to a character in the Request string. Points to the string's 
null terminator if request was successful. Points to the most recent '&' before 
the first failing name / value pair (or the beginning of the string if the 
failure is in the first name / value pair) if the request was not successful

EFI_NOT_FOUND
A configuration element matching the routing data is not found. Progress set to 
the first character in the routing header.


Description of "progress" parameter in RouteConfig () in UEFI 2.7 Spec:
Progress
a pointer to a string filled in with the offset of the most recent '&' before 
the first failing name / value pair (or the beginning of the string if the 
failure is in the first name / value pair) or the terminating NULL if all was 
successful.

EFI_NOT_FOUND
Target for the specified routing data was not found.

Compared with ExtractConfig(), the description of "Progress" parameter in 
RouteConfig()  is not very clear. 
We think an ECR is nice to have to clarify them. What do you think?


Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Thomas 
Palmer
Sent: Thursday, April 19, 2018 4:32 AM
To: edk2-devel@lists.01.org
Cc: nickle.w...@hpe.com; Gao, Liming <liming@intel.com>
Subject: [edk2] [PATCH 1/8] IntelFrameworkModulePkg/LegacyBootMaintUiLib: 
Update RouteConfig function

According to UEFI spec, the RouteConfig protocol function should populate the 
Progress pointer with an address inside Configuration.  This patch ensures that 
these functions are compliant when EFI_NOT_FOUND is returned.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Thomas Palmer <thomas.pal...@hpe.com>
---
 .../Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c   | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c 
b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
index a4828b7130c7..3092184ab760 100644
--- a/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMaintUi.c
+++ b/IntelFrameworkModulePkg/Library/LegacyBootMaintUiLib/LegacyBootMai
+++ ntUi.c
@@ -2,6 +2,7 @@
   Legacy Boot Maintainence UI implementation.
 
 Copyright (c) 2004 - 2016, Intel Corporation. All rights reserved.
+(C) Copyright 2018 Hewlett Packard Enterprise Development LP
 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 @@ -563,6 +564,8 @@ 
LegacyBootOptionRouteConfig (
 return EFI_INVALID_PARAMETER;
   }
 
+  *Progress = Configuration;
+
   //
   // Check routing data in .
   // Note: there is no name for Name/Value storage, only GUID will be checked
--
2.7.4

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add "extern" keyword for "gPatchxxx"

[Bi, Dandan]

Thanks Laszlo for the detailed description.
I will communicate will ECC owner to see whether ECC tool can be enhanced for 
these issues firstly. 
Thank you all.

Regards,
Dandan
-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Friday, April 13, 2018 1:51 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; Bi, Dandan 
<dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>
Subject: Re: [edk2] [patch] UefiCpuPkg/PiSmmCpuDxeSmm: Add "extern" keyword for 
"gPatchxxx"

On 04/12/18 18:47, Kinney, Michael D wrote:
> Laszlo,
> 
> I think I would rather see the ECC tool fixed.

I didn't dare suggest that, but I agree it's a superior solution. When I tried 
ECC last time, I was surprised how powerful it was, so if it recognized even 
this case, that would certainly fit its quality :)

Thanks!
Laszlo

> 
> Mike
> 
>> -Original Message-
>> From: edk2-devel [mailto:edk2-devel-
>> boun...@lists.01.org] On Behalf Of Laszlo Ersek
>> Sent: Thursday, April 12, 2018 2:34 AM
>> To: Bi, Dandan <dandan...@intel.com>; edk2- de...@lists.01.org
>> Cc: Dong, Eric <eric.d...@intel.com>
>> Subject: Re: [edk2] [patch] UefiCpuPkg/PiSmmCpuDxeSmm:
>> Add "extern" keyword for "gPatchxxx"
>>
>> Hello Dandan,
>>
>> On 04/12/18 10:50, Dandan Bi wrote:
>>> Background description:
>>> In SmmProfileInternal.h, ECC check tool report an
>> issue at line 103.
>>> Detailed ECC Error info:Variable definition appears
>> in header file.
>>> Include files should contain only public or only
>> private data and
>>> cannot contain code or define data variables
>>>
>>> ECC report similar issues in PiSmmCpuDxeSmm.h.
>>>
>>> Then we review all the new introduced "gPatchxxx",
>> since they have
>>> been defined in the nasm file, we can add "extern"
>> keyword for them
>>> in the C source or header files.
>>>
>>> Cc: Eric Dong <eric.d...@intel.com>
>>> Cc: Laszlo Ersek <ler...@redhat.com>
>>> Contributed-under: TianoCore Contribution Agreement
>> 1.1
>>> Signed-off-by: Dandan Bi <dandan...@intel.com>
>>> ---
>>>  UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.h | 8
>> 
>>>  UefiCpuPkg/PiSmmCpuDxeSmm/SmmProfileInternal.h | 2
>> +-
>>>  UefiCpuPkg/PiSmmCpuDxeSmm/SmramSaveState.c | 6
>> +++---
>>>  UefiCpuPkg/PiSmmCpuDxeSmm/X64/Semaphore.c  | 4
>> ++--
>>>  4 files changed, 10 insertions(+), 10 deletions(-)
>>
>> This is a bug (a false positive) in the ECC tool. The following
>> declaration:
>>
>>> X86_ASSEMBLY_PATCH_LABELgPatchSmmCr0;
>>
>> does not declare an *object* (a variable). Instead, it declares a
>> *function* (and not a pointer to a function!), because (from
>> "MdePkg/Include/Library/BaseLib.h"):
>>
>>> ///
>>> /// Type definition for representing labels in NASM
>> source code that allow for
>>> /// the patching of immediate operands of IA32 and
>> X64 instructions.
>>> ///
>>> /// While the type is technically defined as a
>> function type (note: not a
>>> /// pointer-to-function type), such labels in NASM
>> source code never stand for
>>> /// actual functions, and identifiers declared with
>> this function type should
>>> /// never be called. This is also why the EFIAPI
>> calling convention specifier
>>> /// is missing from the typedef, and why the typedef
>> does not follow the usual
>>> /// edk2 coding style for function (or pointer-to-
>> function) typedefs. The VOID
>>> /// return type and the VOID argument list are merely
>> artifacts.
>>> ///
>>> typedef VOID (X86_ASSEMBLY_PATCH_LABEL) (VOID);
>>
>> That is, when you see
>>
>>> X86_ASSEMBLY_PATCH_LABELgPatchSmmCr0;
>>
>> That is identical to the following function
>> declaration:
>>
>>> VOID gPatchSmmCr0 (VOID);
>>
>> Now, the ISO C99 standard says:
>>
>>> 6.2.2 Linkages of identifiers
>>>
>>> [...]
>>>
>>>   5 If the declaration of an identifier for a
>> function has no
>>> storage-class specifier, its linkage is
>> determined exactly as if
>>> it were declared with the storage-class specifier
>> /extern/. [...]
>>
>> Thus, the report from ECC is a false positive.
>>
>> I don't mind the patch (the changes don't make any difference at the 
>> C-language level, see the spec above); however, the commit message 
>> should be 100% clear that the patch works around a limitation with 
>> the ECC tool.
>>
>> Can you please submit v2 with an updated commit message?
>>
>> Thanks!
>> Laszlo
>> ___
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Bi, Dandan]

Good suggestion. Thanks Star.
 I will cover them in V2 patches.

Thanks,
Dandan
-Original Message-
From: Zeng, Star 
Sent: Thursday, April 12, 2018 2:03 PM
To: Bi, Dandan <dandan...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>; Zeng, 
Star <star.z...@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

If the cases can be listed completely, then it will be better to also add them 
in the comments for the two GUIDs, then consumer can easily know them.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Bi, 
Dandan
Sent: Thursday, April 12, 2018 11:47 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao, 
Liming <liming@intel.com>
Subject: Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Hi all,

All setup menu enter/exit cases includes:
a.  UiApp entry point is called and then setup menu is shown
(enter setup menu) 
b.  User select Continue menu in setup menu to exit.
(exit setup menu)
c.  User select Reset menu in setup page to leave exit. 
(exit setup menu)
d.  User boot from file to exit setup page. 
   (exit setup menu)
e.  Exit from boot from file and return to UiApp.   
(enter setup menu)
f.  User boot from boot manager to exit setup page. 
 (exit setup menu)
g.Exit the boot option in boot manager and return to UiApp. 
   (enter setup menu)

I didn't describe it in details in the commit messages.  I am sorry that if it 
make you confused.
I will add them in the commit messages of V2 patches.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan
Sent: Thursday, April 12, 2018 11:17 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>; Bi, 
Dandan <dandan...@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Hi Mike,

We can't move the enter/exit event signaling into the FormBrowwer SendForm() 
function.

Because we can't decide whether enter/exit setup through SendForm() is called 
or not.  Some examples:

1. SendForm() is not called when exit setup menu and re-enter setup menu. Such 
as, SendForm() is only called when enter front page firstly. But when  go to 
Boot Manager menu to select an option to boot and exit setup menu, then exit 
the option and return to setup menu, SendForm() is not called in this case.

2. SendForm () may be also called more than one time even if we don't  leave 
setup menu. Such as, if we want to add an boot option in setup menu, when 
choose file to add boot option, SendForm() will be called to show files. But we 
don't  think we leave setup menu in this case.

So if we signal setup enter/exit event in SendForm(), may cause less/more 
notifications. Which is not a correct behavior.


Thanks,
Dandan

-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 12, 2018 9:44 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Dandan Bi,

Is it possible to move the enter/exit event signaling into the FormBrowwer 
SendForm() function?  The current patch set adds these signal calls in all the 
places that
SendForm() is called and if one of these is missed, a notification will be 
missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
> enter/exit setup menu
> 
> These changes are to support notify callbacks when enter/exit setup 
> menu, since some driver may need to hook setup enter/exit points to do 
> something.
> 
> We will signal setup enter/exit events for all setup menu enter/exit 
> cases.Then the module which pay attention to these events can execute 
> the callback.
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contributi

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Bi, Dandan]

There is no need to update UEFI spec, just implementation related. It has no 
impact to the modules which do not care these two events.

Thanks,
Dandan

-Original Message-
From: Tim Lewis [mailto:tim.le...@insyde.com] 
Sent: Thursday, April 12, 2018 11:49 AM
To: Bi, Dandan <dandan...@intel.com>; Kinney, Michael D 
<michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

This is starting to sound like something that requires a UEFI spec update.
Tim

-Original Message-
From: edk2-devel <edk2-devel-boun...@lists.01.org> On Behalf Of Bi, Dandan
Sent: Wednesday, April 11, 2018 8:47 PM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao, 
Liming <liming@intel.com>
Subject: Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Hi all,

All setup menu enter/exit cases includes:
a.  UiApp entry point is called and then setup menu is shown
(enter setup menu) 
b.  User select Continue menu in setup menu to exit.
(exit setup menu)
c.  User select Reset menu in setup page to leave exit.
(exit setup menu)
d.  User boot from file to exit setup page.
(exit setup menu)
e.  Exit from boot from file and return to UiApp.
(enter setup menu)
f.  User boot from boot manager to exit setup page.
(exit setup menu)
g.Exit the boot option in boot manager and return to UiApp.
(enter setup menu)

I didn't describe it in details in the commit messages.  I am sorry that if it 
make you confused.
I will add them in the commit messages of V2 patches.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan
Sent: Thursday, April 12, 2018 11:17 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>; Bi, 
Dandan <dandan...@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Hi Mike,

We can't move the enter/exit event signaling into the FormBrowwer SendForm() 
function.

Because we can't decide whether enter/exit setup through SendForm() is called 
or not.  Some examples:

1. SendForm() is not called when exit setup menu and re-enter setup menu.
Such as, SendForm() is only called when enter front page firstly. But when go 
to Boot Manager menu to select an option to boot and exit setup menu, then exit 
the option and return to setup menu, SendForm() is not called in this case.

2. SendForm () may be also called more than one time even if we don't  leave 
setup menu. Such as, if we want to add an boot option in setup menu, when 
choose file to add boot option, SendForm() will be called to show files. But we 
don't  think we leave setup menu in this case.

So if we signal setup enter/exit event in SendForm(), may cause less/more 
notifications. Which is not a correct behavior.


Thanks,
Dandan

-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 12, 2018 9:44 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Dandan Bi,

Is it possible to move the enter/exit event signaling into the FormBrowwer
SendForm() function?  The current patch set adds these signal calls in all the 
places that
SendForm() is called and if one of these is missed, a notification will be 
missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
> enter/exit setup menu
> 
> These changes are to support notify callbacks when enter/exit setup 
> menu, since some driver may need to hook setup enter/exit points to do 
> something.
> 
> We will signal setup enter/exit events for all setup menu enter/exit 
> cases.Then the module which pay attention to these events can execute 
> the callback.
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> 
> Dandan Bi (3):
>   MdeModulePkg/UiApp: Signal event when enter/exit setup menu
>   MdeModulePkg/BMMUiLib: Signal event when enter/exit setup menu
>   MdeMod

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Bi, Dandan]

Hi all,

All setup menu enter/exit cases includes:
a.  UiApp entry point is called and then setup menu is shown
(enter setup menu) 
b.  User select Continue menu in setup menu to exit.
(exit setup menu)
c.  User select Reset menu in setup page to leave exit. 
(exit setup menu)
d.  User boot from file to exit setup page. 
   (exit setup menu)
e.  Exit from boot from file and return to UiApp.   
(enter setup menu)
f.  User boot from boot manager to exit setup page. 
 (exit setup menu)
g.Exit the boot option in boot manager and return to UiApp. 
   (enter setup menu)

I didn't describe it in details in the commit messages.  I am sorry that if it 
make you confused.
I will add them in the commit messages of V2 patches.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan 
Sent: Thursday, April 12, 2018 11:17 AM
To: Kinney, Michael D <michael.d.kin...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming....@intel.com>; Bi, 
Dandan <dandan...@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Hi Mike,

We can't move the enter/exit event signaling into the FormBrowwer SendForm() 
function.

Because we can't decide whether enter/exit setup through SendForm() is called 
or not.  Some examples:

1. SendForm() is not called when exit setup menu and re-enter setup menu. Such 
as, SendForm() is only called when enter front page firstly. But when  go to 
Boot Manager menu to select an option to boot and exit setup menu, then exit 
the option and return to setup menu, SendForm() is not called in this case.

2. SendForm () may be also called more than one time even if we don't  leave 
setup menu. Such as, if we want to add an boot option in setup menu, when 
choose file to add boot option, SendForm() will be called to show files. But we 
don't  think we leave setup menu in this case.

So if we signal setup enter/exit event in SendForm(), may cause less/more 
notifications. Which is not a correct behavior.


Thanks,
Dandan

-Original Message-
From: Kinney, Michael D
Sent: Thursday, April 12, 2018 9:44 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Dandan Bi,

Is it possible to move the enter/exit event signaling into the FormBrowwer 
SendForm() function?  The current patch set adds these signal calls in all the 
places that
SendForm() is called and if one of these is missed, a notification will be 
missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
> enter/exit setup menu
> 
> These changes are to support notify callbacks when enter/exit setup 
> menu, since some driver may need to hook setup enter/exit points to do 
> something.
> 
> We will signal setup enter/exit events for all setup menu enter/exit 
> cases.Then the module which pay attention to these events can execute 
> the callback.
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> 
> Dandan Bi (3):
>   MdeModulePkg/UiApp: Signal event when enter/exit setup menu
>   MdeModulePkg/BMMUiLib: Signal event when enter/exit setup menu
>   MdeModulePkg/BMUiLib: Signal event when enter/exit setup menu
> 
>  MdeModulePkg/Application/UiApp/FrontPage.c
> | 4 +++-
> 
> MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupp
> ort.c | 3 ++-
>  MdeModulePkg/Application/UiApp/UiApp.inf
> | 4 +++-
> 
> .../BootMaintenanceManagerUiLib/BootMaintenanceManagerUi
> Lib.inf   | 4 +++-
> 
> MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOpt
> ion.c | 8 +++-
>  MdeModulePkg/Library/BootManagerUiLib/BootManager.c
> | 7 ++-
> 
> MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.i
> nf| 4 +++-
>  MdeModulePkg/MdeModulePkg.dec
> | 6 ++
>  8 files changed, 33 insertions(+), 7 deletions(-)
> 
> --
> 2.14.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when enter/exit setup menu

[Bi, Dandan]

Hi Mike,

We can't move the enter/exit event signaling into the FormBrowwer SendForm() 
function.

Because we can't decide whether enter/exit setup through SendForm() is called 
or not.  Some examples:

1. SendForm() is not called when exit setup menu and re-enter setup menu. Such 
as, SendForm() is only called when enter front page firstly. But when  go to 
Boot Manager menu to select an option to boot and exit setup menu, then exit 
the option and return to setup menu, SendForm() is not called in this case.

2. SendForm () may be also called more than one time even if we don't  leave 
setup menu. Such as, if we want to add an boot option in setup menu, when 
choose file to add boot option, SendForm() will be called to show files. But we 
don't  think we leave setup menu in this case.

So if we signal setup enter/exit event in SendForm(), may cause less/more 
notifications. Which is not a correct behavior.


Thanks,
Dandan

-Original Message-
From: Kinney, Michael D 
Sent: Thursday, April 12, 2018 9:44 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org; Kinney, Michael 
D <michael.d.kin...@intel.com>
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
enter/exit setup menu

Dandan Bi,

Is it possible to move the enter/exit event signaling into the FormBrowwer 
SendForm() function?  The current patch set adds these signal calls in all the 
places that
SendForm() is called and if one of these is missed, a notification will be 
missed.

Mike

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-
> boun...@lists.01.org] On Behalf Of Dandan Bi
> Sent: Wednesday, April 11, 2018 6:32 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [patch 0/3] MdeModulePkg/UiApp: Signal event when 
> enter/exit setup menu
> 
> These changes are to support notify callbacks when enter/exit setup 
> menu, since some driver may need to hook setup enter/exit points to do 
> something.
> 
> We will signal setup enter/exit events for all setup menu enter/exit 
> cases.Then the module which pay attention to these events can execute 
> the callback.
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming....@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> 
> Dandan Bi (3):
>   MdeModulePkg/UiApp: Signal event when enter/exit setup menu
>   MdeModulePkg/BMMUiLib: Signal event when enter/exit setup menu
>   MdeModulePkg/BMUiLib: Signal event when enter/exit setup menu
> 
>  MdeModulePkg/Application/UiApp/FrontPage.c
> | 4 +++-
> 
> MdeModulePkg/Application/UiApp/FrontPageCustomizedUiSupp
> ort.c | 3 ++-
>  MdeModulePkg/Application/UiApp/UiApp.inf
> | 4 +++-
> 
> .../BootMaintenanceManagerUiLib/BootMaintenanceManagerUi
> Lib.inf   | 4 +++-
> 
> MdeModulePkg/Library/BootMaintenanceManagerUiLib/BootOpt
> ion.c | 8 +++-
>  MdeModulePkg/Library/BootManagerUiLib/BootManager.c
> | 7 ++-
> 
> MdeModulePkg/Library/BootManagerUiLib/BootManagerUiLib.i
> nf| 4 +++-
>  MdeModulePkg/MdeModulePkg.dec
> | 6 ++
>  8 files changed, 33 insertions(+), 7 deletions(-)
> 
> --
> 2.14.3.windows.1
> 
> ___
> edk2-devel mailing list
> edk2-devel@lists.01.org
> https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Gcd: Suppress incorrect compiler/analyzer warnings

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Sunday, April 8, 2018 9:29 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Bi, Dandan <dandan...@intel.com>; Yao, 
Jiewen <jiewen@intel.com>; Kinney, Michael D <michael.d.kin...@intel.com>
Subject: [PATCH] MdeModulePkg/Gcd: Suppress incorrect compiler/analyzer warnings

It is caused by 0c9f2cb10b7ddec56a3440e77219fd3ab1725e5c
and false positive.
Initialize CpuArchAttributes to suppress incorrect compiler/analyzer warnings.

Cc: Dandan Bi <dandan...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Cc: Michael D Kinney <michael.d.kin...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.z...@intel.com>
---
 MdeModulePkg/Core/Dxe/Gcd/Gcd.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c 
index 31ddf9c3bb51..e17e98230b79 100644
--- a/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
+++ b/MdeModulePkg/Core/Dxe/Gcd/Gcd.c
@@ -3,7 +3,7 @@
   The GCD services are used to manage the memory and I/O regions that
   are accessible to the CPU that is executing the DXE core.
 
-Copyright (c) 2006 - 2017, Intel Corporation. All rights reserved.
+Copyright (c) 2006 - 2018, Intel Corporation. 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 @@ -866,6 +866,10 
@@ CoreConvertSpace (
   }
   ASSERT (TopEntry != NULL && BottomEntry != NULL);
 
+  //
+  // Initialize CpuArchAttributes to suppress incorrect compiler/analyzer 
warnings.
+  //
+  CpuArchAttributes = 0;
   if (Operation == GCD_SET_ATTRIBUTES_MEMORY_OPERATION) {
 //
 // Call CPU Arch Protocol to attempt to set attributes on the range
--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdePkg BaseStackCheckLib: Correct style of file header

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Liming 
Gao
Sent: Friday, March 16, 2018 9:09 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>
Subject: [edk2] [Patch] MdePkg BaseStackCheckLib: Correct style of file header

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming@intel.com>
Cc: Michael Kinney <michael.d.kin...@intel.com>
---
 MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c 
b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c
index ebb387fee5..7c27c73e23 100644
--- a/MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c
+++ b/MdePkg/Library/BaseStackCheckLib/BaseStackCheckNull.c
@@ -1,4 +1,5 @@
-/*++
+/** @file
+ This file is purely empty as a work around for BaseStackCheck to pass MSVC 
build.
 
  Copyright (c) 2018, Intel Corporation. All rights reserved.
  This program and the accompanying materials @@ -9,10 +10,6 @@
  THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
  WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
 
-Abstract:
-
-  This file is purely empty as a work around for BaseStackCheck to pass MSVC 
build.
-
 **/
 
 extern int __BaseStackCheckNull;
--
2.11.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/5] MdePkg/SPI: Change function definitions to match their descriptions.

[Bi, Dandan]

Hi Marvin,

Thank you very much for your contribution. Could you hold this patch series?  
Since current SPI header files follow PI1.6 spec.
For this case, we should submit an ECR to update the PI spec firstly. After the 
ECR has been approved by PIWG, then we can send patch to update them. 
Since you have found a lot of missing/incorrect parts in the SPI part of PI 
Spec. Could you help to submit an ECR to update them?


Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
Häuser
Sent: Wednesday, February 28, 2018 12:49 AM
To: edk2-devel@lists.01.org
Cc: Kinney, Michael D ; Gao, Liming 

Subject: [edk2] [PATCH 1/5] MdePkg/SPI: Change function definitions to match 
their descriptions.

The PI specification is not continuous with function headers and descriptions 
for the SPI protocols. Correct and comment these mistakes.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser 
---
 MdePkg/Include/Protocol/SpiConfiguration.h | 12 
 MdePkg/Include/Protocol/SpiHc.h| 14 +-
 MdePkg/Include/Protocol/SpiIo.h| 15 ++-
 3 files changed, 27 insertions(+), 14 deletions(-)

diff --git a/MdePkg/Include/Protocol/SpiConfiguration.h 
b/MdePkg/Include/Protocol/SpiConfiguration.h
index c0df183ec7f0..c36a809f4232 100644
--- a/MdePkg/Include/Protocol/SpiConfiguration.h
+++ b/MdePkg/Include/Protocol/SpiConfiguration.h
@@ -1,7 +1,7 @@
 /** @file
   This file defines the SPI Configuration Protocol.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2018, Intel Corporation. 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 @@ -65,6 +65,10 @@ EFI_STATUS
   IN BOOLEAN   PinValue
   );
 
+//
+// Note: In the PI specification, ClockHz is decorated as only 'IN', which is
+//   not conforming to the parameter description.
+//
 /**
   Set up the clock generator to produce the correct clock frequency, phase and
   polarity for a SPI chip.
@@ -78,7 +82,7 @@ EFI_STATUS
 ClockPhase and ClockPolarity fields. The routine
 also has access to the names for the SPI bus and
 chip which can be used during debugging.
-  @param[in] ClockHzPointer to the requested clock frequency. The clock
+  @param[in,out] ClockHzPointer to the requested clock frequency. The clock
 generator will choose a supported clock frequency
 which is less then or equal to this value.
 Specify zero to turn the clock generator off.
@@ -92,8 +96,8 @@ EFI_STATUS
 **/
 typedef EFI_STATUS
 (EFIAPI *EFI_SPI_CLOCK) (
-  IN CONST EFI_SPI_PERIPHERAL  *SpiPeripheral,
-  IN UINT32*ClockHz
+  IN CONST EFI_SPI_PERIPHERAL  *SpiPeripheral,
+  IN OUT UINT32*ClockHz
   );
 
 ///
diff --git a/MdePkg/Include/Protocol/SpiHc.h b/MdePkg/Include/Protocol/SpiHc.h 
index 12fe5d2dce0a..71c75431e4e8 100644
--- a/MdePkg/Include/Protocol/SpiHc.h
+++ b/MdePkg/Include/Protocol/SpiHc.h
@@ -1,7 +1,7 @@
 /** @file
   This file defines the SPI Host Controller Protocol.
 
-  Copyright (c) 2017, Intel Corporation. All rights reserved.
+  Copyright (c) 2017 - 2018, Intel Corporation. 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 @@ -66,6 +66,10 @@ typedef EFI_STATUS
   IN BOOLEANPinValue
   );
 
+//
+// Note: In the PI specification, ClockHz is decorated as only 'IN', which is
+//   not conforming to the parameter description.
+//
 /**
   Set up the clock generator to produce the correct clock frequency, phase and
   polarity for a SPI chip.
@@ -80,7 +84,7 @@ typedef EFI_STATUS
 ClockPhase and ClockPolarity fields. The routine
 also has access to the names for the SPI bus and
 chip which can be used during debugging.
-  @param[in] ClockHzPointer to the requested clock frequency. The SPI
+  @param[in,out] ClockHzPointer to the requested clock frequency. The SPI
 host controller will choose a supported clock
 frequency which is less then or equal to this
 value. Specify zero to turn the clock generator @@ 
-94,9 +98,9 @@ typedef EFI_STATUS  **/  typedef EFI_STATUS  (EFIAPI 
*EFI_SPI_HC_PROTOCOL_CLOCK) (
-  IN CONST EFI_SPI_HC_PROTOCOL  *This,
-  IN 

Re: [edk2] [PATCH v2 0/7] Remove the useless pref codes

[Bi, Dandan]

Thank you star. I will update them before committing the patches.

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Friday, February 9, 2018 4:31 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao, 
Liming <liming@intel.com>; Laszlo Ersek <ler...@redhat.com>; Wei, David 
<david@intel.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH v2 0/7] Remove the useless pref codes

Hi Dandan,

Two minor comments, with them handled, Reviewed-by: Star Zeng 
<star.z...@intel.com> to the patch series. :) 1. Put the first patch to the 
last patch as it is to remove the definition and should be done at last.
2. Fix typo 'pref' to 'perf', and 'new new' to 'new'.


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan Bi
Sent: Friday, February 9, 2018 4:05 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao, 
Liming <liming@intel.com>; Laszlo Ersek <ler...@redhat.com>; Zeng, Star 
<star.z...@intel.com>; Wei, David <david@intel.com>
Subject: [edk2] [PATCH v2 0/7] Remove the useless pref codes

V2:
a. Remove defintions related to old perf code and clean all useless perf codes 
in edk2 code base.
b.Update commit message.

Our new performance infrastructure (edk2 trunk commit hash value:
SHA-1: 73fef64f14d1b97ae9bd4705df3becc022391eba ~
SHA-1: 115eae650bfd2be2c2bc37360f4a755065e774c4) can support to dump 
performance date form ACPI table in OS. So we can remove the old pref code to 
write performance data to OS and related definitions.

Cc: Star Zeng <star.z...@intel.com>
Cc: Liming Gao <liming@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: David Wei <david@intel.com>
Cc: Mang Guo <mang@intel.com>
Dandan Bi (7):
  MdeModulePkg/Performance.h: Remove the useless definition
  UefiCpuPkg/S3Resume: Remove useless pref code
  MdeModulePkg/BdsDxe: Remove useless Pref Code
  MdeModulePkg/UefiBootManagerLib: Remove the useless pref codes
  IntelFrameworkModulePkg/BdsDxe: Remove the useless Perf codes
  IntelFrameworkModulePkg/GenericBdsLib: Remove the useless Perf codes
  Vlv2TbltDevicePkg/Override/GenericBdsLib:Remove useless Perf code

 .../Library/GenericBdsLib/BdsBoot.c|  29 +-
 .../Library/GenericBdsLib/GenericBdsLib.inf|   4 +-
 .../Library/GenericBdsLib/InternalBdsLib.h |  19 +-
 .../Library/GenericBdsLib/Performance.c| 313 --
 IntelFrameworkModulePkg/Universal/BdsDxe/Bds.h |   3 +-
 .../Universal/BdsDxe/BdsDxe.inf|   3 +-
 .../Universal/BdsDxe/BdsEntry.c|  57 +---
 MdeModulePkg/Include/Guid/Performance.h|  27 +-
 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  27 +-
 .../Library/UefiBootManagerLib/BmPerformance.c | 317 --
 .../Library/UefiBootManagerLib/InternalBm.h|  17 -
 .../UefiBootManagerLib/UefiBootManagerLib.inf  |   4 +-
 MdeModulePkg/Universal/BdsDxe/Bds.h|   3 +-
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |   3 +-
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |  57 +---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 131 
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |   3 +-
 .../Library/GenericBdsLib/BdsBoot.c|  29 +-
 .../Library/GenericBdsLib/GenericBdsLib.inf|   4 +-
 .../Library/GenericBdsLib/InternalBdsLib.h |  19 +-
 .../Library/GenericBdsLib/Performance.c| 358 -
 21 files changed, 90 insertions(+), 1337 deletions(-)  delete mode 100644 
IntelFrameworkModulePkg/Library/GenericBdsLib/Performance.c
 delete mode 100644 MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c
 delete mode 100644 
Vlv2TbltDevicePkg/Override/IntelFrameworkModulePkg/Library/GenericBdsLib/Performance.c

--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/PciBusDxe: Fix VS2012 build failure

[Bi, Dandan]

Hi Laszlo,

Thanks for your comments. I will update the commit message. 


Regards,
Dandan

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, February 7, 2018 4:17 PM
To: Zeng, Star <star.z...@intel.com>; Bi, Dandan <dandan...@intel.com>; 
edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>
Subject: Re: [patch] MdeModulePkg/PciBusDxe: Fix VS2012 build failure

On 02/07/18 02:44, Zeng, Star wrote:
> Reviewed-by: Star Zeng <star.z...@intel.com>
> 
> Cc Laszlo.

Thanks!

> You can add similar comment like 1ea53108f6c1010a00a828d1d59ea28934025415 as 
> recommended by https://bugzilla.tianocore.org/show_bug.cgi?id=607.

Yes, that would be nice.

The patch looks correct. Dandan, can you please add the following to the commit 
message too:


Both reads (dereferences) of "PciRootBridgeIo" in
PciBusDriverBindingStart() are only reached if "gFullEnumeration" is TRUE on 
entry *and* we successfully open the EfiPciRootBridgeIoProtocol interface.


With that:

Reviewed-by: Laszlo Ersek <ler...@redhat.com>

Thanks!
Laszlo


> Thanks,
> Star
> -Original Message-
> From: Bi, Dandan
> Sent: Wednesday, February 7, 2018 9:31 AM
> To: edk2-devel@lists.01.org
> Cc: Zeng, Star <star.z...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [patch] MdeModulePkg/PciBusDxe: Fix VS2012 build failure
> 
> Initialize local variable to suppress warning C4703:
> potentially uninitialized local pointer variable.
> 
> Cc: Star Zeng <star.z...@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c 
> b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> index c48e3bb..13221b9 100644
> --- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> +++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
> @@ -242,10 +242,12 @@ PciBusDriverBindingStart (  {
>EFI_STATUS  Status;
>EFI_DEVICE_PATH_PROTOCOL*ParentDevicePath;
>EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciRootBridgeIo;
>  
> +  PciRootBridgeIo = NULL;
> +
>//
>// Check RemainingDevicePath validation
>//
>if (RemainingDevicePath != NULL) {
>  //
> --
> 1.9.5.msysgit.1
> 

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/PciBusDxe: Fix VS2012 build failure

[Bi, Dandan]

Thank you star. I will add comment before commit the patch. 


Regards,
Dandan
-Original Message-
From: Zeng, Star 
Sent: Wednesday, February 7, 2018 9:45 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek (ler...@redhat.com) 
<ler...@redhat.com>; Zeng, Star <star.z...@intel.com>
Subject: RE: [patch] MdeModulePkg/PciBusDxe: Fix VS2012 build failure

Reviewed-by: Star Zeng <star.z...@intel.com>

Cc Laszlo.

You can add similar comment like 1ea53108f6c1010a00a828d1d59ea28934025415 as 
recommended by https://bugzilla.tianocore.org/show_bug.cgi?id=607.

Thanks,
Star
-----Original Message-
From: Bi, Dandan 
Sent: Wednesday, February 7, 2018 9:31 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
Subject: [patch] MdeModulePkg/PciBusDxe: Fix VS2012 build failure

Initialize local variable to suppress warning C4703:
potentially uninitialized local pointer variable.

Cc: Star Zeng <star.z...@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan...@intel.com>
---
 MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c 
b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
index c48e3bb..13221b9 100644
--- a/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
+++ b/MdeModulePkg/Bus/Pci/PciBusDxe/PciBus.c
@@ -242,10 +242,12 @@ PciBusDriverBindingStart (  {
   EFI_STATUS  Status;
   EFI_DEVICE_PATH_PROTOCOL*ParentDevicePath;
   EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL *PciRootBridgeIo;
 
+  PciRootBridgeIo = NULL;
+
   //
   // Check RemainingDevicePath validation
   //
   if (RemainingDevicePath != NULL) {
 //
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] SecurityPkg: Add UNI string for 2 PCDs

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Zhang, 
Chao B
Sent: Saturday, February 3, 2018 11:12 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Zhang, Chao B <chao.b.zh...@intel.com>
Subject: [edk2] [PATCH] SecurityPkg: Add UNI string for 2 PCDs

Add prompt & help string for PcdTpm2CurrentIrqNum, PcdTpm2PossibleIrqNumBuf

Cc: Dandan Bi <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Chao Zhang <chao.b.zh...@intel.com>
---
 SecurityPkg/SecurityPkg.uni | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/SecurityPkg/SecurityPkg.uni b/SecurityPkg/SecurityPkg.uni index 
1263516..aaf7726 100644
--- a/SecurityPkg/SecurityPkg.uni
+++ b/SecurityPkg/SecurityPkg.uni
@@ -5,7 +5,7 @@
 // It also provides the definitions(including PPIs/PROTOCOLs/GUIDs and library 
classes)  // and libraries instances, which are used for those features.
 //
-// Copyright (c) 2009 - 2017, Intel Corporation. All rights reserved.
+// Copyright (c) 2009 - 2018, Intel Corporation. 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.
@@ -238,3 +238,12 @@

 "To support configuring from setup page, this PCD can be DynamicHii type 
and map to a setup option.\n"

 "For example, map to TCG2_VERSION.Tpm2AcpiTableRev to be configured by 
Tcg2ConfigDxe driver.\n"

 
"gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev|L\"TCG2_VERSION\"|gTcg2ConfigFormSetGuid|0x8|3|NV,BS"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdTpm2CurrentIrqNum_PROMPT  
#language en-US "Current TPM2 device interrupt number"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdTpm2CurrentIrqNum_HELP  #language 
en-US "This PCD defines current TPM2 device interrupt number reported by _CRS. 
If set to 0, interrupt is disabled."
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdTpm2PossibleIrqNumBuf_PROMPT  
#language en-US "Possible TPM2 device interrupt number buffer"
+
+#string STR_gEfiSecurityPkgTokenSpaceGuid_PcdTpm2PossibleIrqNumBuf_HELP  
#language en-US "This PCD defines possible TPM2 interrupt number in a platform 
reported by _PRS control method.\n"
+   
  "If PcdTpm2CurrentIrqNum set to 0, _PRS will not report any possible 
TPM2 interrupt numbers."
\ No newline at end of file
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch 0/3] Remove the useless pref codes

[Bi, Dandan]

Hi Star,

I am not sure. Since these definitions are still used in other packages such as 
Intelframeworkmodulepkg. If we want to remove them, we must clean up all the 
old perf related codes in Edk2 code base to avoid build block issues.


Thanks,
Dandan
-Original Message-
From: Zeng, Star 
Sent: Thursday, January 25, 2018 12:59 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Laszlo Ersek <ler...@redhat.com>; Dong, 
Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>; Zeng, Star 
<star.z...@intel.com>
Subject: RE: [edk2] [patch 0/3] Remove the useless pref codes

Could we also remove the related definitions in 
MdeModulePkg\Include\Guid\Performance.h?

//
// The data structure for performance data in ACPI memory.
//
#define PERFORMANCE_SIGNATURE   SIGNATURE_32 ('P', 'e', 'r', 'f')
#define PERF_TOKEN_SIZE 28
#define PERF_TOKEN_LENGTH   (PERF_TOKEN_SIZE - 1)
#define PERF_PEI_ENTRY_MAX_NUM  50
#define PERF_DATA_MAX_LENGTH0x4000

typedef struct {
  CHAR8   Token[PERF_TOKEN_SIZE];
  UINT32  Duration;
} PERF_DATA;

typedef struct {
  UINT64BootToOs;
  UINT64S3Resume;
  UINT32S3EntryNum;
  PERF_DATA S3Entry[PERF_PEI_ENTRY_MAX_NUM];
  UINT64CpuFreq;
  UINT64BDSRaw;
  UINT32Count;
  UINT32Signiture;
} PERF_HEADER;


Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan Bi
Sent: Wednesday, January 24, 2018 4:02 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Zeng, Star <star.z...@intel.com>; Laszlo 
Ersek <ler...@redhat.com>; Dong, Eric <eric.d...@intel.com>; Gao, Liming 
<liming@intel.com>
Subject: [edk2] [patch 0/3] Remove the useless pref codes

Our new performance infrastructure can support to dump performance date form 
ACPI table in OS. So we can remove the old pref code to write performance data 
to OS.

Cc: Eric Dong <eric.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Cc: Liming Gao <liming@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Dandan Bi (3):
  UefiCpuPkg/S3Resume: Remove useless pref code
  MdeModulePkg/BdsDxe: Remove useless Pref Code
  MdeModulePkg/UefiBootManagerLib: Remove the useless pref codes

 MdeModulePkg/Library/UefiBootManagerLib/BmBoot.c   |  30 +-
 .../Library/UefiBootManagerLib/BmPerformance.c | 317 -
 .../Library/UefiBootManagerLib/InternalBm.h|   1 -
 .../UefiBootManagerLib/UefiBootManagerLib.inf  |   4 +-
 MdeModulePkg/Universal/BdsDxe/Bds.h|   3 +-
 MdeModulePkg/Universal/BdsDxe/BdsDxe.inf   |   3 +-
 MdeModulePkg/Universal/BdsDxe/BdsEntry.c   |  57 +---
 UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c  | 131 -
 .../Universal/Acpi/S3Resume2Pei/S3Resume2Pei.inf   |   3 +-
 9 files changed, 32 insertions(+), 517 deletions(-)  delete mode 100644 
MdeModulePkg/Library/UefiBootManagerLib/BmPerformance.c

--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase

[Bi, Dandan]

Hi Laszlo,

Thank you for your comments.

Yes. The PERF_INMODULE_START_ID macro is from "ExtendedFirmwarePerformance.h" 
which is added in the new performance infrastructure patches([ mail subject: 
patch 0/8] Update EDKII Performance infrastructure based on ACPI FPDT table). 
That is the dependency I mean.

I will send V2 of this patch and the patch which remove Pref code after "new 
performance infrastructure" patches have been committed . Then I will refine 
the commit message of these two patches, add commit  hash value of "new 
performance infrastructure" patches if I need to reference it. 

Thanks,
Dandan

-Original Message-
From: Laszlo Ersek [mailto:ler...@redhat.com] 
Sent: Wednesday, January 24, 2018 11:45 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: Re: [patch] UefiCpuPkg/S3Resume: Add more perf enrty for S3 phase

On 01/24/18 08:59, Dandan Bi wrote:
> Add more perf entry to hook BootScriptDonePpi/EndOfPeiPpi/ 
> EndOfS3Resume.
> 
> Notes: This patch depends on the new performance infrastructure.

Since this statement is going into the commit log, please be more specific 
about the "new performance infrastructure" (TianoCore BZ or commit hashes etc).

Also, how is the dependency established? For example, OVMF uses 
BasePerformanceLibNull; so I think it will see no changes.

Do you mean the PERF_INMODULE_START_ID macro, from 
"ExtendedFirmwarePerformance.h"? Ah, that's not committed yet. In this case, 
please add a reference to the mailing list message (subject and archive URL) 
that adds it.

(Actually, the best solution is to reference the TianoCore BZ, and then add the 
mailing list URL for each patch set submission to the TianoCore BZ.)

> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Laszlo Ersek <ler...@redhat.com>
> Cc: Liming Gao <liming....@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c | 15 
> ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c 
> b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> index b597ac7..d7d2a4d 100644
> --- a/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> +++ b/UefiCpuPkg/Universal/Acpi/S3Resume2Pei/S3Resume.c
> @@ -2,11 +2,11 @@
>This module produces the EFI_PEI_S3_RESUME2_PPI.
>This module works with StandAloneBootScriptExecutor to S3 resume to OS.
>This module will execute the boot script saved during last boot and after 
> that,
>control is passed to OS waking up handler.
>  
> -  Copyright (c) 2006 - 2017, Intel Corporation. All rights 
> reserved.
> +  Copyright (c) 2006 - 2018, Intel Corporation. All rights 
> + reserved.
>Copyright (c) 2017, AMD Incorporated. 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 @@ 
> -21,10 +21,11 @@  #include 
>  
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> @@ -551,13 +552,17 @@ S3ResumeBootOs (
>PERF_END (NULL, "ScriptExec", NULL, 0);
>  
>//
>// Install BootScriptDonePpi
>//
> +  PERF_START_EX (NULL, "BootScriptDonePpi", NULL, 0, 
> + PERF_INMODULE_START_ID);
> +

My question here is not really specific to this patch, but I guess asking it 
this time is just as good as any other time:

- Why do we pass NULL for Module, rather than gEfiCallerBaseName?

- We already have START and END calls for the performance measurement; why do 
we use different Identifier values for the records added?

(These questions are more for my education than about possible issues in the 
patch.)

Thanks!
Laszlo


>Status = PeiServicesInstallPpi ();
>ASSERT_EFI_ERROR (Status);
>  
> +  PERF_END_EX (NULL, "BootScriptDonePpi", NULL, 0, 
> + PERF_INMODULE_END_ID);
> +
>//
>// Get ACPI Table Address
>//
>Facs = (EFI_ACPI_4_0_FIRMWARE_ACPI_CONTROL_STRUCTURE *) ((UINTN) 
> (AcpiS3Context->AcpiFacsTable));
>  
> @@ -576,18 +581,26 @@ S3ResumeBootOs (
>}
>  
>//
>// Install EndOfPeiPpi
>//
> +  PERF_START_EX (NULL, "EndOfPeiPpi", NULL, 0, 
> + PERF_INMODULE_START_ID);
> +
>Status = PeiServicesInstallPpi ();
>ASSERT_EFI_ERROR (Status);
>  
> +  PERF_END_EX (NULL, "EndOfPeiPpi", NULL, 0, PERF_INMODULE_END_ID);
> +
>   

Re: [edk2] VFR validation of IP address and iSCSI IQN

[Bi, Dandan]

Hi,

(1) If you want the string can only be set with the one in STR_STRING_CHECK, 
you can add  following codes within the string opcode: 

   inconsistentif prompt = STRING_TOKEN(STR_INVALID_IQN),
   pushthis != stringref(STRING_TOKEN(STR_STRING_CHECK))
   endif;

(2) If you want the string only cannot be set with the one in STR_STRING_CHECK, 
you can add following codes within the string opcode:

   inconsistentif prompt = STRING_TOKEN(STR_INVALID_IQN),
   pushthis == stringref(STRING_TOKEN(STR_STRING_CHECK))
   endif;

For more examples you can refer to the vfr file in: 
edk2\MdeModulePkg\Universal\DriverSampleDxe\ Vfr.vfr.


Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Atul 
Gupta
Sent: Thursday, January 11, 2018 2:52 PM
To: edk2-devel@lists.01.org
Subject: [edk2] VFR validation of IP address and iSCSI IQN

Hi,

I want to validate IP address and iSCSI IQN within the vfr form. Want to avoid 
callback hence removed the INTERACTIVE flags, tried few things but none seems 
to work except for input length check, how to validate the input buffer.

Eg:

string  name= iqn,
varid   = UD_CONFIG_IFR_NVDATA.InitiatorName,
prompt  = STRING_TOKEN(STR_ISCSI_CONFIG_INIT_NAME),
help= STRING_TOKEN(STR_ISCSI_CONFIG_INIT_NAME_HELP),
flags   = 0,
key = KEY_INITIATOR_NAME2,
minsize = 8,
maxsize = ISCSI_NAME_IFR_MAX_SIZE,
 inconsistentif prompt = 
STRING_TOKEN(STR_INVALID_IQN),
 NOT
 pushthis != 
stringref(STRING_TOKEN(STR_STRING_CHECK))
 endif
endstring;

also tried
span (flags = LAST_NON_MATCH, pushthis, 
stringref(STRING_TOKEN(STR_STRING_CHECK)), 0) != 0, but did not help.

Any reference to validate the input buffer?

Thanks
Atul
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] UefiCpuPkg/MpInitLib: fix 32-bit build error

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: Wang, Jian J 
Sent: Thursday, January 11, 2018 9:02 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Laszlo 
Ersek <ler...@redhat.com>
Subject: [PATCH] UefiCpuPkg/MpInitLib: fix 32-bit build error

Cc: Dandan Bi <dandan...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 UefiCpuPkg/Library/MpInitLib/DxeMpLib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c 
b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
index e832c16eca..d2bcef53d6 100644
--- a/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/DxeMpLib.c
@@ -326,7 +326,7 @@ InitMpGlobalData (
 CpuInfoInHob = (CPU_INFO_IN_HOB *)(UINTN)CpuMpData->CpuInfoInHob;
 for (Index = 0; Index < CpuMpData->CpuCount; ++Index) {
   if (CpuInfoInHob != NULL && CpuInfoInHob[Index].ApTopOfStack != 0) {
-StackBase = CpuInfoInHob[Index].ApTopOfStack - 
CpuMpData->CpuApStackSize;
+StackBase = (UINTN)CpuInfoInHob[Index].ApTopOfStack - 
CpuMpData->CpuApStackSize;
   } else {
 StackBase = CpuMpData->Buffer + Index * CpuMpData->CpuApStackSize;
   }
-- 
2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [Patch] MdeModulePkg/NetLib: Refine coding style for API NetLibDetectMediaWaitTimeout

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: Wang, Fan 
Sent: Monday, December 25, 2017 10:46 AM
To: edk2-devel@lists.01.org
Cc: Wang, Fan <fan.w...@intel.com>; Bi, Dandan <dandan...@intel.com>
Subject: [Patch] MdeModulePkg/NetLib: Refine coding style for API 
NetLibDetectMediaWaitTimeout

From: Wang Fan <fan.w...@intel.com>

Cc: Dandan Bi <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wang Fan <fan.w...@intel.com>
---
 MdeModulePkg/Library/DxeNetLib/DxeNetLib.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c 
b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
index d75cca2..26a80a7 100644
--- a/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
+++ b/MdeModulePkg/Library/DxeNetLib/DxeNetLib.c
@@ -2526,11 +2526,10 @@ Exit:
 MediaState pointer is NULL.
   @retval EFI_DEVICE_ERROR  A device error occurred.
   @retval EFI_TIMEOUT   Network is connecting but timeout.
 
 **/
-
 EFI_STATUS
 EFIAPI
 NetLibDetectMediaWaitTimeout (
   IN  EFI_HANDLEServiceHandle,
   IN  UINT64Timeout,
@@ -2571,11 +2570,11 @@ NetLibDetectMediaWaitTimeout (
   if (EFI_ERROR (Status)) {
 
 MediaPresent = TRUE;
 Status = NetLibDetectMedia (ServiceHandle, );
 if (!EFI_ERROR (Status)) {
-  if (MediaPresent == TRUE) {
+  if (MediaPresent) {
 *MediaState = EFI_SUCCESS;
   } else {
 *MediaState = EFI_NO_MEDIA;
   }
 }
@@ -2612,11 +2611,11 @@ NetLibDetectMediaWaitTimeout (
   // If gEfiAdapterInfoMediaStateGuid is not supported, call 
NetLibDetectMedia to get media state!
   //
   MediaPresent = TRUE;
   Status = NetLibDetectMedia (ServiceHandle, );
   if (!EFI_ERROR (Status)) {
-if (MediaPresent == TRUE) {
+if (MediaPresent) {
   *MediaState = EFI_SUCCESS;
 } else {
   *MediaState = EFI_NO_MEDIA;
 }
   }
-- 
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 2/4] MdeModulePkg/Core: Coding style clean-up

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: Wang, Jian J 
Sent: Monday, December 25, 2017 9:07 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Zeng, Star <star.z...@intel.com>; Dong, 
Eric <eric.d...@intel.com>
Subject: [PATCH 2/4] MdeModulePkg/Core: Coding style clean-up

Cc: Dandan Bi <dandan...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c 
b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
index bbdfa2bb8e..d7a86c0d30 100644
--- a/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
+++ b/MdeModulePkg/Core/DxeIplPeim/X64/VirtualMemory.c
@@ -126,6 +126,11 @@ EnableExecuteDisableBit (
   The function will check if page table entry should be splitted to smaller
   granularity.
 
+  @param Address  Physical memory address.
+  @param Size Size of the given physical memory.
+  @param StackBaseBase address of stack.
+  @param StackSizeSize of stack.
+
   @retval TRUE  Page table should be split.
   @retval FALSE Page table should not be split.
 **/
-- 
2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 4/4] UefiCpuPkg: Update code to use new structure field names

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: Wang, Jian J 
Sent: Monday, December 25, 2017 9:07 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Laszlo 
Ersek <ler...@redhat.com>
Subject: [PATCH 4/4] UefiCpuPkg: Update code to use new structure field names

Due to coding style fix of the structure definition in BaseLib.h, all code 
referencing those structure must be updated accordingly.

Cc: Dandan Bi <dandan...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 .../Ia32/ArchExceptionHandler.c| 24 +++---
 .../X64/ArchExceptionHandler.c |  6 +++---
 UefiCpuPkg/Library/MpInitLib/MpLib.c   |  2 +-
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
index 6ac8549839..4e89b0470f 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/Ia32/ArchExceptionHandle
+++ r.c
@@ -216,7 +216,7 @@ ArchSetupExcpetionStack (
   TssDesc->Bits.BaseLow= (UINT16)TssBase;
   TssDesc->Bits.BaseMid= (UINT8)(TssBase >> 16);
   TssDesc->Bits.Type   = IA32_GDT_TYPE_TSS;
-  TssDesc->Bits.P  = 1;
+  TssDesc->Bits.Present= 1;
   TssDesc->Bits.LimitHigh  = 0;
   TssDesc->Bits.BaseHigh   = (UINT8)(TssBase >> 24);
 
@@ -240,7 +240,7 @@ ArchSetupExcpetionStack (
 TssDesc->Bits.BaseLow   = (UINT16)TssBase;
 TssDesc->Bits.BaseMid   = (UINT8)(TssBase >> 16);
 TssDesc->Bits.Type  = IA32_GDT_TYPE_TSS;
-TssDesc->Bits.P = 1;
+TssDesc->Bits.Present   = 1;
 TssDesc->Bits.LimitHigh = 0;
 TssDesc->Bits.BaseHigh  = (UINT8)(TssBase >> 24);
 
@@ -253,17 +253,17 @@ ArchSetupExcpetionStack (
   continue;
 }
 
-Tss->EIP= (UINT32)(TemplateMap.ExceptionStart
+Tss->Eip= (UINT32)(TemplateMap.ExceptionStart
+ Vector * TemplateMap.ExceptionStubHeaderSize);
-Tss->EFLAGS = 0x2;
-Tss->ESP= StackTop;
-Tss->CR3= AsmReadCr3 ();
-Tss->ES = AsmReadEs ();
-Tss->CS = AsmReadCs ();
-Tss->SS = AsmReadSs ();
-Tss->DS = AsmReadDs ();
-Tss->FS = AsmReadFs ();
-Tss->GS = AsmReadGs ();
+Tss->Eflags = 0x2;
+Tss->Esp= StackTop;
+Tss->Cr3= AsmReadCr3 ();
+Tss->Es = AsmReadEs ();
+Tss->Cs = AsmReadCs ();
+Tss->Ss = AsmReadSs ();
+Tss->Ds = AsmReadDs ();
+Tss->Fs = AsmReadFs ();
+Tss->Gs = AsmReadGs ();
 
 StackTop   -= StackSwitchData->Ia32.KnownGoodStackSize;
 
diff --git 
a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c 
b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
index 1dcf4277de..4d52b4eb0e 100644
--- a/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler.c
+++ b/UefiCpuPkg/Library/CpuExceptionHandlerLib/X64/ArchExceptionHandler
+++ .c
@@ -186,7 +186,7 @@ ArchSetupExcpetionStack (
   //
   TssDesc = StackSwitchData->X64.ExceptionTssDesc;
   Tss = StackSwitchData->X64.ExceptionTss;
-  if (StackSwitchData->X64.StackSwitchExceptionNumber > ARRAY_SIZE (Tss->IST)) 
{
+  if (StackSwitchData->X64.StackSwitchExceptionNumber > ARRAY_SIZE 
+ (Tss->Ist)) {
 return EFI_INVALID_PARAMETER;
   }
 
@@ -221,7 +221,7 @@ ArchSetupExcpetionStack (
   TssDesc->Bits.BaseLow= (UINT16)TssBase;
   TssDesc->Bits.BaseMidl   = (UINT8)(TssBase >> 16);
   TssDesc->Bits.Type   = IA32_GDT_TYPE_TSS;
-  TssDesc->Bits.P  = 1;
+  TssDesc->Bits.Present= 1;
   TssDesc->Bits.LimitHigh  = 0;
   TssDesc->Bits.BaseMidh   = (UINT8)(TssBase >> 24);
   TssDesc->Bits.BaseHigh   = (UINT32)(TssBase >> 32);
@@ -236,7 +236,7 @@ ArchSetupExcpetionStack (
 //
 // Fixup IST
 //
-Tss->IST[Index] = StackTop;
+Tss->Ist[Index] = StackTop;
 StackTop -= StackSwitchData->X64.KnownGoodStackSize;
 
 //
diff --git a/UefiCpuPkg/Library/MpInitLib/MpLib.c 
b/UefiCpuPkg/Library/MpInitLib/MpLib.c
index 0c2058a7b0..da1a43c430 100644
--- a/UefiCpuPkg/Library/MpInitLib/MpLib.c
+++ b/UefiCpuPkg/Library/MpInitLib/MpLib.c
@@ -243,7 +243,7 @@ RestoreVolatileRegisters (
   VolatileRegisters->Tr < VolatileRegisters->Gdtr.Limit) {
 Tss = (IA32_TSS_DESCRIPTOR *)(VolatileRegisters->Gdtr.Base +
   VolatileRegisters->Tr);
-if (Tss->Bits.P == 1

Re: [edk2] [PATCH 3/4] UefiCpuPkg/UefiCpuPkg.uni: Add missing string definition for new PCDs

[Bi, Dandan]

Hi Jian,

Could you add the "string" keyword before the string token when you commit the 
patch. You can refer to other codes in the uni file.
With this update, Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: Wang, Jian J 
Sent: Monday, December 25, 2017 9:07 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Laszlo 
Ersek <ler...@redhat.com>
Subject: [PATCH 3/4] UefiCpuPkg/UefiCpuPkg.uni: Add missing string definition 
for new PCDs

Cc: Dandan Bi <dandan...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Laszlo Ersek <ler...@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 UefiCpuPkg/UefiCpuPkg.uni | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/UefiCpuPkg/UefiCpuPkg.uni b/UefiCpuPkg/UefiCpuPkg.uni index 
a7073b10c8..6fcfc6e7f2 100644
--- a/UefiCpuPkg/UefiCpuPkg.uni
+++ b/UefiCpuPkg/UefiCpuPkg.uni
@@ -230,5 +230,17 @@

 "Processor trace is enabled through set BIT44(CPU_FEATURE_PROC_TRACE) 
in PcdCpuFeaturesSetting.\n"

 "This PCD is ignored if CPU processor trace is disabled.\n"

 "Default value is 0 which means single range output scheme will be 
used if CPU processor trace is enabled.\n"
-   
 "0 - Single Range output scheme.\n"

-   
 "1 - ToPA(Table of physical address) scheme.\n"
\ No newline at end of file
+   
 "0 - Single Range output scheme.\n"
+   
 "1 - ToPA(Table of physical address) scheme.\n"
+
+#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuStackSwitchExceptionList_PROMPT  
#language en-US "Specify exception vectors which need switching stack."
+
+#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuStackSwitchExceptionList_HELP  #language 
en-US "List of exception vectors which need switching stack.\n"
+   
 "This PCD will only take into effect if PcdCpuStackGuard is enabled.n"
+   
 "By default exception #DD(8), #PF(14) are supported.n"
+
+#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuKnownGoodStackSize_PROMPT  #language 
en-US "Specify size of good stack of exception which need switching stack."
+
+#STR_gUefiCpuPkgTokenSpaceGuid_PcdCpuKnownGoodStackSize_HELP  #language en-US 
"Size of good stack for an exception.\n"
+  
"This PCD will only take into effect if PcdCpuStackGuard is enabled.\n"
+
--
2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH 1/4] MdePkg/BaseLib.h: Coding style clean-up

[Bi, Dandan]

Hi Jian,

This patch is fine. 
Could you help to add a period(.) for  following function description when you 
commit the patch? Thanks!
/**
  Load given selector into TR register   // Add a period(.) here, or ECC tool 
will report an error here.

  @param[in] Selector Task segment selector
**/
VOID
EFIAPI
AsmWriteTr (
  IN UINT16 Selector
  ); 

With this update, Reviewed-by: Dandan Bi <dandan...@intel.com>

Regards,
Dandan
-Original Message-
From: Wang, Jian J 
Sent: Monday, December 25, 2017 9:07 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Zeng, Star <star.z...@intel.com>; Dong, 
Eric <eric.d...@intel.com>
Subject: [PATCH 1/4] MdePkg/BaseLib.h: Coding style clean-up

Cc: Dandan Bi <dandan...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 MdePkg/Include/Library/BaseLib.h | 72 
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/MdePkg/Include/Library/BaseLib.h b/MdePkg/Include/Library/BaseLib.h
index 2b98af4cd1..f51079aeb1 100644
--- a/MdePkg/Include/Library/BaseLib.h
+++ b/MdePkg/Include/Library/BaseLib.h
@@ -6672,41 +6672,41 @@ typedef union {
 typedef struct {
   UINT16PreviousTaskLink;
   UINT16Reserved_2;
-  UINT32ESP0;
-  UINT16SS0;
+  UINT32Esp0;
+  UINT16Ss0;
   UINT16Reserved_10;
-  UINT32ESP1;
-  UINT16SS1;
+  UINT32Esp1;
+  UINT16Ss1;
   UINT16Reserved_18;
-  UINT32ESP2;
-  UINT16SS2;
+  UINT32Esp2;
+  UINT16Ss2;
   UINT16Reserved_26;
-  UINT32CR3;
-  UINT32EIP;
-  UINT32EFLAGS;
-  UINT32EAX;
-  UINT32ECX;
-  UINT32EDX;
-  UINT32EBX;
-  UINT32ESP;
-  UINT32EBP;
-  UINT32ESI;
-  UINT32EDI;
-  UINT16ES;
+  UINT32Cr3;
+  UINT32Eip;
+  UINT32Eflags;
+  UINT32Eax;
+  UINT32Ecx;
+  UINT32Edx;
+  UINT32Ebx;
+  UINT32Esp;
+  UINT32Ebp;
+  UINT32Esi;
+  UINT32Edi;
+  UINT16Es;
   UINT16Reserved_74;
-  UINT16CS;
+  UINT16Cs;
   UINT16Reserved_78;
-  UINT16SS;
+  UINT16Ss;
   UINT16Reserved_82;
-  UINT16DS;
+  UINT16Ds;
   UINT16Reserved_86;
-  UINT16FS;
+  UINT16Fs;
   UINT16Reserved_90;
-  UINT16GS;
+  UINT16Gs;
   UINT16Reserved_94;
   UINT16LDTSegmentSelector;
   UINT16Reserved_98;
-  UINT16T;
+  UINT16Tflag;
   UINT16IOMapBaseAddress;
 } IA32_TASK_STATE_SEGMENT;
 
@@ -6717,12 +6717,12 @@ typedef union {
 UINT32  BaseMid:8;  ///< Base Address  23..16
 UINT32  Type:4; ///< Type (1 0 B 1)
 UINT32  Reserved_43:1;  ///< 0
-UINT32  DPL:2;  ///< Descriptor Privilege Level
-UINT32  P:1;///< Segment Present
+UINT32  Dpl:2;  ///< Descriptor Privilege Level
+UINT32  Present:1;  ///< Segment Present
 UINT32  LimitHigh:4;///< Segment Limit 19..16
-UINT32  AVL:1;  ///< Available for use by system software
+UINT32  Avl:1;  ///< Available for use by system software
 UINT32  Reserved_52:2;  ///< 0 0
-UINT32  G:1;///< Granularity
+UINT32  Granularity:1;  ///< Granularity
 UINT32  BaseHigh:8; ///< Base Address 31..24
   } Bits;
   UINT64  Uint64;
@@ -6757,11 +6757,11 @@ typedef union {
 //
 typedef struct {
   UINT32Reserved_0;
-  UINT64RSP0;
-  UINT64RSP1;
-  UINT64RSP2;
+  UINT64Rsp0;
+  UINT64Rsp1;
+  UINT64Rsp2;
   UINT64Reserved_28;
-  UINT64IST[7];
+  UINT64Ist[7];
   UINT64Reserved_92;
   UINT16Reserved_100;
   UINT16IOMapBaseAddress;
@@ -6774,12 +6774,12 @@ typedef union {
 UINT32  BaseMidl:8; ///< Base Address  23..16
 UINT32  Type:4; ///< Type (1 0 B 1)
 UINT32  Reserved_43:1;  ///< 0
-UINT32  DPL:2;  ///< Descriptor Privilege Level
-UINT32  P:1;///< Segment Present
+UINT32  Dpl:2;  ///< Descriptor Privilege Level
+UINT32  Present:1;  ///< Segment Present
 UINT32  LimitHigh:4;///< Segment Limit 19..16
-UINT32  AVL:1;  ///< Available for use by system software
+UINT32  Avl:1;  ///< Available for use by system software
 UINT32  Reserved_52:2;  ///< 0 0
-UINT32  G:1;///< Granularity
+UINT32  Granularity:1;  ///< Granularity
 UINT32  BaseMidh:8; ///< Base Address  31..24
 UINT32  BaseHigh:32;///< Base Address  63..32
 UINT32  Reserved_96:32; ///< Reserved
-- 
2.15.1.windows.2

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg PiSmmIpl: Add missing update to the prototype

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Tuesday, December 12, 2017 4:16 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Bi, Dandan <dandan...@intel.com>; Yao, 
Jiewen <jiewen@intel.com>
Subject: [PATCH] MdeModulePkg PiSmmIpl: Add missing update to the prototype

It is missing to update the prototype of SmmCommunicationCommunicate() in 
d1632f694be027dee87dd18fa8172d674221face.

This patch is to add it.

Cc: Dandan Bi <dandan...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.z...@intel.com>
---
 MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c | 24 +---
 1 file changed, 17 insertions(+), 7 deletions(-)

diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c 
b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
index 31d2c9e45e1f..a7663ca291c4 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c
@@ -90,20 +90,30 @@ SmmBase2GetSmstLocation (
   be called in physical mode prior to SetVirtualAddressMap() and in virtual 
mode 
   after SetVirtualAddressMap().
 
-  @param[in] ThisThe EFI_SMM_COMMUNICATION_PROTOCOL 
instance.
-  @param[in, out] CommBuffer  A pointer to the buffer to convey into 
SMRAM.
-  @param[in, out] CommSizeThe size of the data buffer being passed 
in.On exit, the size of data
- being returned. Zero if the handler does 
not wish to reply with any data.
+  @param[in] ThisThe EFI_SMM_COMMUNICATION_PROTOCOL instance.
+  @param[in, out] CommBuffer A pointer to the buffer to convey into SMRAM.
+  @param[in, out] CommSize   The size of the data buffer being passed in. 
On exit, the size of data
+ being returned. Zero if the handler does not 
wish to reply with any data.
+ This parameter is optional and may be NULL.
+
+  @retval EFI_SUCCESSThe message was successfully posted.
+  @retval EFI_INVALID_PARAMETER  The CommBuffer was NULL.
+  @retval EFI_BAD_BUFFER_SIZEThe buffer is too large for the MM 
implementation.
+ If this error is returned, the MessageLength 
field
+ in the CommBuffer header or the integer 
pointed by
+ CommSize, are updated to reflect the maximum 
payload
+ size the implementation can accommodate.
+  @retval EFI_ACCESS_DENIED  The CommunicateBuffer parameter or CommSize 
parameter,
+ if not omitted, are in address range that 
cannot be
+ accessed by the MM environment.
 
-  @retval EFI_SUCCESSThe message was successfully posted.
-  @retval EFI_INVALID_PARAMETER  The CommBuffer was NULL.
 **/
 EFI_STATUS
 EFIAPI
 SmmCommunicationCommunicate (
   IN CONST EFI_SMM_COMMUNICATION_PROTOCOL  *This,
   IN OUT VOID  *CommBuffer,
-  IN OUT UINTN *CommSize
+  IN OUT UINTN *CommSize OPTIONAL
   );
 
 /**
--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it more generic

[Bi, Dandan]

Hi Pankaj Bansal,

Current  SPI header files follow PI 1.6 Spec, if you find any issue in PI spec, 
current process is to raise them to PIWG for discussion firstly, then PIWG will 
discuss the issue and decide whether update the spec, at last update the code 
if needed.


Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Leif 
Lindholm
Sent: Thursday, December 7, 2017 10:49 PM
To: Pankaj Bansal 
Cc: Kinney, Michael D ; edk2-devel@lists.01.org; 
Gao, Liming 
Subject: Re: [edk2] [RFC] MdePkg/Spi : Modify SPI Protocol strctures to make it 
more generic

Adding MdePkg maintainers: Mike and Liming.

Please always cc package maintainers (listed in Maintainers.txt).

/
Leif

On Thu, Dec 07, 2017 at 02:05:19PM +0530, Pankaj Bansal wrote:
> Issue_1: Currenty SPI IO and SPI HC protocol strcture is not equipped 
> to handle all type of SPI commands e.g. QuadIo Read Command (0xEBh) in 
> spansion flash S25FS512S will not work.
> 
> Cause: Currenty SPI protocol describes a SPI transaction as 
> combination of data and address and command, which would all be 
> transmitted on same data bus (1 or 2 or 4).
> 
> BUT when we have a case in which command is send one single data bus 
> and address and data is sent one 4 data bus (like 0xEB in spansion), 
> then this will not work with current strcture.
> 
> Fix: Instead of making a single transaction, we can specify a group of 
> transactions (called packet, terminology borrowed from I2c Protocol) 
> in which each transaction specifies the data width, frequency, delay 
> and read/write info.
> 
> Issue_2: Specify additional data about SPI transaction (i.e. 
> transaction is of type cmd, address, data, dummy etc). some 
> controllers need this info to communicate with SPI peripheral. others can 
> ignore this info.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Pankaj Bansal 
> ---
>  MdePkg/Include/Protocol/SpiHc.h |  15 +-  
> MdePkg/Include/Protocol/SpiIo.h | 250 --
>  2 files changed, 104 insertions(+), 161 deletions(-)
> 
> diff --git a/MdePkg/Include/Protocol/SpiHc.h 
> b/MdePkg/Include/Protocol/SpiHc.h index 12fe5d2..65964bc 100644
> --- a/MdePkg/Include/Protocol/SpiHc.h
> +++ b/MdePkg/Include/Protocol/SpiHc.h
> @@ -110,8 +110,11 @@ typedef EFI_STATUS
>status.
>  
>@param[in] ThisPointer to an EFI_SPI_HC_PROTOCOL structure.
> -  @param[in] BusTransaction  Pointer to a EFI_SPI_BUS_ TRANSACTION containing
> - the description of the SPI transaction to 
> perform.
> +  @param[in] SpiPeripheral   The address of an EFI_SPI_PERIPHERAL data 
> structure
> + describing the SPI peripheral from(to) which
> + read(write) transactions to be performed.
> +  @param[in] RequestPacket   Pointer to a EFI_SPI_REQUEST_PACKET containing
> + the description of the SPI transactions to 
> perform.
>  
>@retval EFI_SUCCESS  The transaction completed successfully
>@retval EFI_BAD_BUFFER_SIZE  The BusTransaction->WriteBytes value 
> is invalid, @@ -124,7 +127,8 @@ typedef EFI_STATUS  typedef EFI_STATUS  
> (EFIAPI *EFI_SPI_HC_PROTOCOL_TRANSACTION) (
>IN CONST EFI_SPI_HC_PROTOCOL  *This,
> -  IN EFI_SPI_BUS_TRANSACTION*BusTransaction
> +  IN CONST EFI_SPI_PERIPHERAL   *SpiPeripheral;
> +  IN EFI_SPI_REQUEST_PACKET *RequestPacket
>);
>  
>  ///
> @@ -135,7 +139,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>/// Host control attributes, may have zero or more of the following set:
>/// * HC_SUPPORTS_WRITE_ONLY_OPERATIONS
>/// * HC_SUPPORTS_READ_ONLY_OPERATIONS
> -  /// * HC_SUPPORTS_WRITE_THEN_READ_OPERATIONS
>/// * HC_TX_FRAME_IN_MOST_SIGNIFICANT_BITS
>///   - The SPI host controller requires the transmit frame to be in most
>/// significant bits instead of least significant bits.The host driver
> @@ -149,10 +152,6 @@ struct _EFI_SPI_HC_PROTOCOL {
>///   - The SPI controller supports a 2 - bit data bus
>/// * HC_SUPPORTS_4_B1T_DATA_BUS_WIDTH
>///   - The SPI controller supports a 4 - bit data bus
> -  /// * HC_TRANSFER_SIZE_INCLUDES_OPCODE
> -  ///   - Transfer size includes the opcode byte
> -  /// * HC_TRANSFER_SIZE_INCLUDES_ADDRESS
> -  ///   - Transfer size includes the 3 address bytes
>/// The SPI host controller must support full - duplex (receive while
>/// sending) operation.The SPI host controller must support a 1 - bit bus
>/// width.
> diff --git a/MdePkg/Include/Protocol/SpiIo.h 
> b/MdePkg/Include/Protocol/SpiIo.h index 43e8045..507abb5 100644
> --- a/MdePkg/Include/Protocol/SpiIo.h
> +++ b/MdePkg/Include/Protocol/SpiIo.h
> @@ -27,147 +27,33 @@ typedef struct _EFI_SPI_IO_PROTOCOL 
> EFI_SPI_IO_PROTOCOL;  /// Note: The UEFI PI 1.6 specification does not 
> specify 

Re: [edk2] [PATCH] IntelSiliconPkg: Update MicrocodeUpdate build path in dsc

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Friday, December 1, 2017 9:20 AM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Bi, Dandan <dandan...@intel.com>; Yao, 
Jiewen <jiewen@intel.com>
Subject: [PATCH] IntelSiliconPkg: Update MicrocodeUpdate build path in dsc

That was missed in 43e12eeac8b125165b8a93c3501925a8893544ef.

Cc: Dandan Bi <dandan...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.z...@intel.com>
---
 IntelSiliconPkg/IntelSiliconPkg.dsc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/IntelSiliconPkg/IntelSiliconPkg.dsc 
b/IntelSiliconPkg/IntelSiliconPkg.dsc
index e3043f82228e..790870e2f1de 100644
--- a/IntelSiliconPkg/IntelSiliconPkg.dsc
+++ b/IntelSiliconPkg/IntelSiliconPkg.dsc
@@ -39,7 +39,7 @@ [LibraryClasses]
   
PerformanceLib|MdePkg/Library/BasePerformanceLibNull/BasePerformanceLibNull.inf
   SerialPortLib|MdePkg/Library/BaseSerialPortLibNull/BaseSerialPortLibNull.inf
   
CacheMaintenanceLib|MdePkg/Library/BaseCacheMaintenanceLib/BaseCacheMaintenanceLib.inf
-  
MicrocodeFlashAccessLib|UefiCpuPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.inf
+  
MicrocodeFlashAccessLib|IntelSiliconPkg/Feature/Capsule/Library/MicrocodeFlashAccessLibNull/MicrocodeFlashAccessLibNull.inf
 
 [LibraryClasses.common.PEIM]
   PeimEntryPoint|MdePkg/Library/PeimEntryPoint/PeimEntryPoint.inf
@@ -84,7 +84,7 @@ [Components]
   IntelSiliconPkg/Feature/VTd/IntelVTdPmrPei/IntelVTdPmrPei.inf
   IntelSiliconPkg/Feature/VTd/PlatformVTdSampleDxe/PlatformVTdSampleDxe.inf
   
IntelSiliconPkg/Feature/VTd/PlatformVTdInfoSamplePei/PlatformVTdInfoSamplePei.inf
-  UefiCpuPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdateDxe.inf
+  IntelSiliconPkg/Feature/Capsule/MicrocodeUpdateDxe/MicrocodeUpdateDxe.inf
 
 [BuildOptions]
   *_*_*_CC_FLAGS = -D DISABLE_NEW_DEPRECATED_INTERFACES
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg/Core: Add missing header files into inf

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Jian J 
Wang
Sent: Thursday, November 23, 2017 9:19 AM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Dong, Eric <eric.d...@intel.com>; Zeng, 
Star <star.z...@intel.com>
Subject: [edk2] [PATCH] MdeModulePkg/Core: Add missing header files into inf

The coding style requires that header files must be also added in module's inf 
file, as long as they're included by c files. This patch will fix this issue.

Cc: Dandan Bi <dandan...@intel.com>
Cc: Star Zeng <star.z...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 MdeModulePkg/Core/Dxe/DxeMain.inf | 1 +
 MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf | 1 +
 2 files changed, 2 insertions(+)

diff --git a/MdeModulePkg/Core/Dxe/DxeMain.inf 
b/MdeModulePkg/Core/Dxe/DxeMain.inf
index f2155fcab1..7334780326 100644
--- a/MdeModulePkg/Core/Dxe/DxeMain.inf
+++ b/MdeModulePkg/Core/Dxe/DxeMain.inf
@@ -57,6 +57,7 @@
   Mem/Imem.h
   Mem/MemoryProfileRecord.c
   Mem/HeapGuard.c
+  Mem/HeapGuard.h
   FwVolBlock/FwVolBlock.c
   FwVolBlock/FwVolBlock.h
   FwVol/FwVolWrite.c
diff --git a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf 
b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
index 1583641887..01d706d0e3 100644
--- a/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
+++ b/MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf
@@ -41,6 +41,7 @@
   MemoryAttributesTable.c
   SmiHandlerProfile.c
   HeapGuard.c
+  HeapGuard.h
 
 [Packages]
   MdePkg/MdePkg.dec
--
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v3 3/3] IntelFrameworkModulePkg: Fix misuses of AllocateCopyPool

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Wang, Jian J 
Sent: Wednesday, November 8, 2017 10:12 AM
To: edk2-devel@lists.01.org
Cc: Gao, Liming <liming@intel.com>; Bi, Dandan <dandan...@intel.com>
Subject: [PATCH v3 3/3] IntelFrameworkModulePkg: Fix misuses of AllocateCopyPool

> v3:
>No updates.

> v2:
> a. Use ReallocatePool instead of allocating then copying wherever 
> applicable

AllocateCopyPool(AllocationSize, *Buffer) will copy "AllocationSize" bytes of 
memory from old "Buffer" to new allocated one. If "AllocationSize" is bigger 
than size of "Buffer", heap memory overflow occurs during copy.

One solution is to allocate pool first then copy the necessary bytes to new 
memory. Another is using ReallocatePool instead if old buffer will be freed on 
spot.

Cc: Liming Gao <liming@intel.com>
Cc: Bi Dandan <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.w...@intel.com>
---
 .../Universal/BdsDxe/DeviceMngr/DeviceManager.c| 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git 
a/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c 
b/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c
index 125c49db5e..5103c7e5d1 100644
--- a/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.c
+++ b/IntelFrameworkModulePkg/Universal/BdsDxe/DeviceMngr/DeviceManager.
+++ c
@@ -480,7 +480,11 @@ AddIdToMacDeviceList (
   } else {
 mMacDeviceList.MaxListLen += MAX_MAC_ADDRESS_NODE_LIST_LEN;
 if (mMacDeviceList.CurListLen != 0) {
-  TempDeviceList = (MENU_INFO_ITEM *)AllocateCopyPool (sizeof 
(MENU_INFO_ITEM) * mMacDeviceList.MaxListLen, (VOID *)mMacDeviceList.NodeList);
+  TempDeviceList = ReallocatePool (
+ sizeof (MENU_INFO_ITEM) * mMacDeviceList.CurListLen,
+ sizeof (MENU_INFO_ITEM) * mMacDeviceList.MaxListLen,
+ mMacDeviceList.NodeList
+ );
 } else {
   TempDeviceList = (MENU_INFO_ITEM *)AllocatePool (sizeof (MENU_INFO_ITEM) 
* mMacDeviceList.MaxListLen);
 }
@@ -491,10 +495,6 @@ AddIdToMacDeviceList (
 TempDeviceList[mMacDeviceList.CurListLen].PromptId = PromptId;  
 TempDeviceList[mMacDeviceList.CurListLen].QuestionId = (EFI_QUESTION_ID) 
(mMacDeviceList.CurListLen + NETWORK_DEVICE_LIST_KEY_OFFSET);
 
-if (mMacDeviceList.CurListLen > 0) {
-  FreePool(mMacDeviceList.NodeList);
-}
-
 mMacDeviceList.NodeList = TempDeviceList;
   }
   mMacDeviceList.CurListLen ++;
--
2.14.1.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg VarCheckHiiLib: Fix typo "0x02%x" to be "0x%02x"

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Monday, November 6, 2017 8:51 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Bi, Dandan <dandan...@intel.com>; Yao, 
Jiewen <jiewen@intel.com>
Subject: [PATCH] MdeModulePkg VarCheckHiiLib: Fix typo "0x02%x" to be "0x%02x"

Cc: Dandan Bi <dandan...@intel.com>
Cc: Jiewen Yao <jiewen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.z...@intel.com>
---
 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c 
b/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
index f018c87ba199..2c3b9eb8e4c9 100644
--- a/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
+++ b/MdeModulePkg/Library/VarCheckHiiLib/VarCheckHiiGen.c
@@ -147,8 +147,8 @@ DumpHiiPackage (
 IfrEfiVarStore = (EFI_IFR_VARSTORE_EFI *) IfrOpCodeHeader;
 if (IfrEfiVarStore->Header.Length >= sizeof 
(EFI_IFR_VARSTORE_EFI)) {
   DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->OpCode - 0x%02x 
(%a)\n", IfrOpCodeHeader->OpCode, IfrOpCodeToStr (IfrOpCodeHeader->OpCode)));
-  DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Length - 0x02%x\n", 
IfrOpCodeHeader->Length));
-  DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Scope  - 0x02%x\n", 
IfrOpCodeHeader->Scope));
+  DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Length - 0x%02x\n", 
IfrOpCodeHeader->Length));
+  DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Scope  - 0x%02x\n", 
IfrOpCodeHeader->Scope));
   DEBUG ((EFI_D_INFO, "  Guid   - %g\n", 
>Guid));
   DEBUG ((EFI_D_INFO, "  VarStoreId - 0x%04x\n", 
IfrEfiVarStore->VarStoreId));
   DEBUG ((EFI_D_INFO, "  Size   - 0x%04x\n", 
IfrEfiVarStore->Size));
@@ -162,8 +162,8 @@ DumpHiiPackage (
   case EFI_IFR_NUMERIC_OP:
   case EFI_IFR_ORDERED_LIST_OP:
 DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->OpCode - 0x%02x (%a)\n", 
IfrOpCodeHeader->OpCode, IfrOpCodeToStr (IfrOpCodeHeader->OpCode)));
-DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Length - 0x02%x\n", 
IfrOpCodeHeader->Length));
-DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Scope  - 0x02%x\n", 
IfrOpCodeHeader->Scope));
+DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Length - 0x%02x\n", 
IfrOpCodeHeader->Length));
+DEBUG ((EFI_D_INFO, "IfrOpCodeHeader->Scope  - 0x%02x\n", 
IfrOpCodeHeader->Scope));
 DEBUG ((EFI_D_INFO, "  Prompt   - 0x%04x\n", 
((EFI_IFR_ONE_OF *) IfrOpCodeHeader)->Question.Header.Prompt));
 DEBUG ((EFI_D_INFO, "  Help - 0x%04x\n", 
((EFI_IFR_ONE_OF *) IfrOpCodeHeader)->Question.Header.Help));
 DEBUG ((EFI_D_INFO, "  QuestionId   - 0x%04x\n", 
((EFI_IFR_ONE_OF *) IfrOpCodeHeader)->Question.QuestionId));
-- 
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [patch] MdeModulePkg/VarCheckHii: Enhance VarCheckHiiLib to support bit check

[Bi, Dandan]

Hi Star,

Thanks for your comments.

Yes, you are right. I will update the patch based on your comments.

Regards,
Dandan

-Original Message-
From: Zeng, Star 
Sent: Friday, November 3, 2017 2:04 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>; Zeng, 
Star <star.z...@intel.com>
Subject: RE: [patch] MdeModulePkg/VarCheckHii: Enhance VarCheckHiiLib to 
support bit check

Hi Dandan,

1. Could we reuse VarOffset/StorageWidth to store bit level info when 
BitFieldStore = TRUE? Then we can avoid adding 
VarOffsetBitLevel/StorageWidthBitLevel to reduce the final VarCheckBinSize, and 
it can be also aligned with HiiDatabase that is using VarOffset to store bit 
level info when gEdkiiIfrBitVarstoreGuid guid opcode is present, right?

2. Please increase VAR_CHECK_HII_REVISION since we will update the structure 
definitions.

3. How about to update
"Bit VarStoreInfo (bit level)" to be "VarStoreInfo (bit level)"?
"Bit VarOffset(Bit level)" to be "VarOffset(Bit level)"?
"Bit StorageWidth(Bit level) " to be "StorageWidth(Bit level)"?

4.  How about to update "oneof", "checkbox", "numeric" and "orderedlist" in 
comments to be consistent with "OneOf", "CheckBox", "Numeric" and "OrderedList"?


Thanks,
Star
-Original Message-
From: Bi, Dandan
Sent: Friday, October 27, 2017 3:25 PM
To: edk2-devel@lists.01.org
Cc: Zeng, Star <star.z...@intel.com>; Dong, Eric <eric.d...@intel.com>; Gao, 
Liming <liming@intel.com>
Subject: [patch] MdeModulePkg/VarCheckHii: Enhance VarCheckHiiLib to support 
bit check

VarCheckHiiLib check the value set to storage based on the possible value 
listed in the vfr file. Since we have enhanced vfr to support Question value 
stored in bit field, so now enhance VarCheckHiiLib to support bit field check.

Cc: Star Zeng <star.z...@intel.com>
Cc: Eric Dong <eric.d...@intel.com>
Cc: Liming Gao <liming@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan...@intel.com>
---
 .../VarCheckHiiLib/InternalVarCheckStructure.h |  17 +-
 MdeModulePkg/Library/VarCheckHiiLib/VarCheckHii.h  |   4 +-
 .../Library/VarCheckHiiLib/VarCheckHiiGen.c| 259 +++--
 .../Library/VarCheckHiiLib/VarCheckHiiLib.inf  |   5 +-
 .../VarCheckHiiLib/VarCheckHiiLibNullClass.c   |  92 ++--
 5 files changed, 291 insertions(+), 86 deletions(-)

diff --git a/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h 
b/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h
index a9faed4..b32dd4e 100644
--- a/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h
+++ b/MdeModulePkg/Library/VarCheckHiiLib/InternalVarCheckStructure.h
@@ -1,9 +1,9 @@
 /** @file
   Internal structure for Var Check Hii.
 
-Copyright (c) 2015, Intel Corporation. All rights reserved.
+Copyright (c) 2015 - 2017, Intel Corporation. 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
 
@@ -40,41 +40,56 @@ typedef struct {
 typedef struct {
   UINT8 OpCode;
   UINT8 Length; // Length include this header
   UINT16VarOffset;
   UINT8 StorageWidth;
+  UINT16VarOffsetBitLevel;
+  UINT8 StorageWidthBitLevel;
+  BOOLEAN   BitFieldStore; // Whether the Question is stored in bit 
field
 } VAR_CHECK_HII_QUESTION_HEADER;
 
 typedef struct {
   UINT8 OpCode;
   UINT8 Length; // Length include this header
   UINT16VarOffset;
   UINT8 StorageWidth;
+  UINT16VarOffsetBitLevel;
+  UINT8 StorageWidthBitLevel;
+  BOOLEAN   BitFieldStore; // Whether the Question is stored in bit 
field
 //UINTx   Data[]; // x = UINT8/UINT16/UINT32/UINT64;
 } VAR_CHECK_HII_QUESTION_ONEOF;
 
 typedef struct {
   UINT8 OpCode;
   UINT8 Length; // Length include this header
   UINT16VarOffset;
   UINT8 StorageWidth;
+  UINT16VarOffsetBitLevel;
+  UINT8 StorageWidthBitLevel;
+  BOOLEAN   BitFieldStore; // Whether the Question is stored in bit 
field
 } VAR_CHECK_HII_QUESTION_CHECKBOX;
 
 typedef struct {
   UINT8 OpCode;
   UINT8 Length; // Length include this header
   UINT16VarOffset;
   UINT8 StorageWidth;
+  UINT16VarOffsetBitLevel;
+  UINT8 StorageWidthBitLevel;
+  BOOLEAN   BitFieldStore; // Whether the Question is stored in bi

Re: [edk2] [PATCH v2] MdePkg: Add definitions for the SPI protocols introduced in PI 1.6.

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

Thank you,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Marvin 
Häuser
Sent: Tuesday, October 31, 2017 8:12 AM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Bi, Dandan <dandan...@intel.com>; Kinney, 
Michael D <michael.d.kin...@intel.com>; Gao, Liming <liming@intel.com>
Subject: [edk2] [PATCH v2] MdePkg: Add definitions for the SPI protocols 
introduced in PI 1.6.

This commit adds header files for the SPI protocols introduced in the
UEFI PI 1.6 specification, as well as their GUIDs to MdePkg.dec.

EFI_SPI_TRANSACTION_TYPE assumes an enum with its members ordered the
way they are listed in the specification, as there are no values given
explicitely.
EFI_LEGACY_SPI_CONTROLLER_GUID assumes the character 'l' used in the
specification was meant to be '1'.

V2:
- Fixed LegacySpiFlash.h's header guard.
- Fixed LegacySpiSmmController's GUID name.
- Removed EFI_SPI_NOR_FLASH_PROTOCOL_LF_READ_DATA as it's unused.
- Added the missing SpiSmmNorFlash header.
- Fixed all file endings to be CRLF.
- Removed trailing whitespaces.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
---
 MdePkg/Include/Protocol/LegacySpiController.h| 265 ++
 MdePkg/Include/Protocol/LegacySpiFlash.h | 201 ++
 MdePkg/Include/Protocol/LegacySpiSmmController.h |  36 +++
 MdePkg/Include/Protocol/LegacySpiSmmFlash.h  |  36 +++
 MdePkg/Include/Protocol/SpiConfiguration.h   | 293 
 MdePkg/Include/Protocol/SpiHc.h  | 194 +
 MdePkg/Include/Protocol/SpiIo.h  | 292 +++
 MdePkg/Include/Protocol/SpiNorFlash.h| 262 +
 MdePkg/Include/Protocol/SpiSmmConfiguration.h|  36 +++
 MdePkg/Include/Protocol/SpiSmmHc.h   |  36 +++
 MdePkg/Include/Protocol/SpiSmmNorFlash.h |  36 +++
 MdePkg/MdePkg.dec|  34 +++
 12 files changed, 1721 insertions(+)

diff --git a/MdePkg/Include/Protocol/LegacySpiController.h 
b/MdePkg/Include/Protocol/LegacySpiController.h
new file mode 100644
index ..7f6b07ec42e9
--- /dev/null
+++ b/MdePkg/Include/Protocol/LegacySpiController.h
@@ -0,0 +1,265 @@
+/** @file
+  This file defines the Legacy SPI Controller Protocol.
+
+  Copyright (c) 2017, Intel Corporation. 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.
+
+  @par Revision Reference:
+This Protocol was introduced in UEFI PI Specification 1.6.
+
+**/
+
+#ifndef __LEGACY_SPI_CONTROLLER_PROTOCOL_H__
+#define __LEGACY_SPI_CONTROLLER_PROTOCOL_H__
+
+///
+/// Note: The UEFI PI 1.6 specification uses the character 'l' in the GUID
+///   definition. This definition assumes it was supposed to be '1'.
+///
+/// Global ID for the Legacy SPI Controller Protocol
+///
+#define EFI_LEGACY_SPI_CONTROLLER_GUID  \
+  { 0x39136fc7, 0x1a11, 0x49de, \
+{ 0xbf, 0x35, 0x0e, 0x78, 0xdd, 0xb5, 0x24, 0xfc }}
+
+typedef
+struct _EFI_LEGACY_SPI_CONTROLLER_PROTOCOL
+EFI_LEGACY_SPI_CONTROLLER_PROTOCOL;
+
+/**
+  Set the erase block opcode.
+
+  This routine must be called at or below TPL_NOTIFY.
+  The menu table contains SPI transaction opcodes which are accessible after
+  the legacy SPI flash controller's configuration is locked. The board layer
+  specifies the erase block size for the SPI NOR flash part. The SPI NOR flash
+  peripheral driver selects the erase block opcode which matches the erase
+  block size and uses this API to load the opcode into the opcode menu table.
+
+  @param[in] This  Pointer to an EFI_LEGACY_SPI_CONTROLLER_PROTOCOL
+   structure.
+  @param[in] EraseBlockOpcode  Erase block opcode to be placed into the opcode
+   menu table.
+
+  @retval EFI_SUCCESS   The opcode menu table was updated
+  @retval EFI_ACCESS_ERROR  The SPI controller is locked
+
+**/
+typedef EFI_STATUS
+(EFIAPI *EFI_LEGACY_SPI_CONTROLLER_PROTOCOL_ERASE_BLOCK_OPCODE) (
+  IN CONST EFI_LEGACY_SPI_CONTROLLER_PROTOCOL  *This,
+  IN UINT8 EraseBlockOpcode
+  );
+
+/**
+  Set the write status prefix opcode.
+
+  This routine must be called at or below TPL_NOTIFY.
+  The prefix table contains SPI transaction write prefix opcodes which are
+  accessible after the legacy SPI flash controller's configuration is locked.
+  The board layer specifies the write

Re: [edk2] [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

[Bi, Dandan]

Reviewed-by: Bi Dandan <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: Chen, Chen A 
Sent: Tuesday, October 10, 2017 10:09 AM
To: edk2-devel@lists.01.org
Cc: Chen, Chen A <chen.a.c...@intel.com>; Bi, Dandan <dandan...@intel.com>; 
Zhang, Chao B <chao.b.zh...@intel.com>
Subject: [PATCH] SecurityPkg/SecureBootConfigImpl.c: Fix coding style issue.

Fix coding style issue.

Cc: Bi Dandan <dandan...@intel.com>
Cc: Zhang Chao <chao.b.zh...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: chenc2 <chen.a.c...@intel.com>
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c | 30 +++---
 .../SecureBootConfigDxe/SecureBootConfigImpl.h | 14 +-
 2 files changed, 22 insertions(+), 22 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index 457e020ece..3e5012e21b 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
+++ nfigImpl.c
@@ -3098,11 +3098,11 @@ DeleteSignatureEx (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -3149,7 +3149,7 @@ DeleteSignatureEx (
 
   RemainingSize = VariableDataSize;
   ListWalker = (EFI_SIGNATURE_LIST *)(VariableData);
-  if (DelType == DELETE_SIGNATURE_LIST_ALL) {
+  if (DelType == Delete_Signature_List_All) {
 VariableDataSize = 0;
   } else {
 while ((RemainingSize > 0) && (RemainingSize >= 
ListWalker->SignatureListSize) && ListIndex < PrivateData->ListIndex) { @@ 
-3161,7 +3161,7 @@ DeleteSignatureEx (
   ListIndex++;
 }
 
-if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType == 
DELETE_SIGNATURE_LIST_ONE) {
+if (CheckedCount == SIGNATURE_DATA_COUNTS (ListWalker) || DelType 
+ == Delete_Signature_List_One) {
   RemainingSize -= ListWalker->SignatureListSize;
   ListWalker = (EFI_SIGNATURE_LIST *)((UINT8 *)ListWalker + 
ListWalker->SignatureListSize);
 } else {
@@ -3685,13 +3685,13 @@ LoadSignatureList (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
 DstFormId = FORMID_SECURE_BOOT_DB_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
 DstFormId = FORMID_SECURE_BOOT_DBX_OPTION_FORM;
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
 DstFormId = FORMID_SECURE_BOOT_DBT_OPTION_FORM;
   } else {
@@ -4216,11 +4216,11 @@ LoadSignatureData (
 goto ON_EXIT;
   }
 
-  if (PrivateData->VariableName == VARIABLE_DB) {
+  if (PrivateData->VariableName == Variable_DB) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE);
-  } else if (PrivateData->VariableName == VARIABLE_DBX) {
+  } else if (PrivateData->VariableName == Variable_DBX) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE1);
-  } else if (PrivateData->VariableName == VARIABLE_DBT) {
+  } else if (PrivateData->VariableName == Variable_DBT) {
 UnicodeSPrint (VariableName, 100, EFI_IMAGE_SECURITY_DATABASE2);
   } else {
 goto ON_EXIT;
@@ -4618,7 +4618,7 @@ SecureBootCallback (
 // From DBX option to the level-1 form, display signature list.
 //
 case KEY_VALUE_FROM_DBX_TO_LIST_FORM:
-  Private->VariableName = VARIABLE_DBX;
+  Private->VariableName = Variable_DBX;
   LoadSignatureList (
 Private,
 LABEL_SIGNATURE_LIST_START,
@@ -4640,7 +4640,7 @@ SecureBootCallback (
   );
 
   if (Key.UnicodeChar == L'Y' || Key.UnicodeChar == L'y') {
-DeleteSignatureEx (Private, DELETE_SIGNATURE_LIST_ALL, 
IfrNvData->CheckedDataCount);
+DeleteSignatureEx (Private, Delete_Signature_List_All, 
+ IfrNvData->CheckedDataCount);
   }
 
   LoadSignatureList (
@@ -4664,7 +4664,7 @@ SecureBootCallback (
   );
 
   if (K

Re: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols introduced in UEFI PI 1.6.

[Bi, Dandan]

Hi Marvin,

I have reviewed the remaining parts.
Here are the comments:
1. There is a typo in LegacySpiFlash.h
Typo:
#ifndef __SPI_CONFIGURATION_PROTOCOL_H__
#define __SPI_CONFIGURATION_PROTOCOL_H__
   The token __SPI_CONFIGURATION_PROTOCOL_H__ in LegacySpiFlash.h in duplicated 
with the one in SpiConfiguration.h, please update it.

2.  The type EFI_SPI_NOR_FLASH_PROTOCOL_LF_READ_DATA in SpiNorFlash.h is not 
used,  and it's also not defined in Spec, we may remove it.
  (1)typedef
   EFI_STATUS
   (EFIAPI *EFI_SPI_NOR_FLASH_PROTOCOL_LF_READ_DATA) (
 IN  CONST EFI_SPI_NOR_FLASH_PROTOCOL  *This,
 IN  UINT32FlashAddress,
 IN  UINT32LengthInBytes,
 OUT UINT8 *Buffer
 );
   ///
   /// Low frequency read data from the SPI flash.
   /// 
   EFI_SPI_NOR_FLASH_PROTOCOL_READ_DATALfReadData;

3. You could use patch check tool in BaseTools/Scripts/PatchCheck.py to verify 
the format of your updates.


Thanks,
Dandan

-Original Message-
From: Bi, Dandan 
Sent: Friday, September 15, 2017 4:22 PM
To: Ni, Ruiyu <ruiyu...@intel.com>; Marvin Häuser <marvin.haeu...@outlook.com>; 
edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming 
<liming@intel.com>
Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols 
introduced in UEFI PI 1.6.

Hi Marvin,

Thank you for your contribution. I am reviewing this patch now. Currently I 
just take a look at the SMM SPI part and find:

1. There is a typo in LegacySpiSmmController.h
The definition should be EFI_LEGACY_SPI_SMM_CONTROLLER_GUID, not 
EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID.
Typo:
#define EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID  \
  { 0x62331b78, 0xd8d0, 0x4c8c, \
{ 0x8c, 0xcb, 0xd2, 0x7d, 0xfe, 0x32, 0xdb, 0x9b }}
And it should  be:
#define EFI_LEGACY_SPI_SMM_CONTROLLER_GUID \
{ 0x62331b78, 0xd8d0, 0x4c8c, { 0x8c, 0xcb, 0xd2, 0x7d, \ 0xfe, 0x32, 0xdb, 
0x9b }}

2. EFI_SPI_SMM_NOR_FLASH_PROTOCOL definition seems to be missing.

I will review the remaining part. It may take some time. Sorry for the delay in 
my response

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, September 7, 2017 3:13 PM
To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming 
<liming@intel.com>; Bi, Dandan <dandan...@intel.com>
Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols 
introduced in UEFI PI 1.6.

Marvin,
Thank you for your contribution. We will need some time to review the 
definitions against PI Spec.
If there is a need to post V2, it might be better to separate the header files 
in different groups.
For example, LegacySpi group, SPI group, SMM SPI group.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Wednesday, September 6, 2017 5:21 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>
> Subject: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> This commit adds header files for the SPI protocols introduced in the
> UEFI PI 1.6 specification, as well as their GUIDs to MdePkg.dec.
> 
> EFI_SPI_TRANSACTION_TYPE assumes an enum with its members ordered
> the
> way they are listed in the specification, as there are no values given
> explicitely.
> EFI_LEGACY_SPI_CONTROLLER_GUID assumes the character 'l' used in the
> specification was meant to be '1'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> ---
>  MdePkg/Include/Protocol/LegacySpiController.h| 265
> ++
>  MdePkg/Include/Protocol/LegacySpiFlash.h | 201 ++
>  MdePkg/Include/Protocol/LegacySpiSmmController.h |  36 +++
>  MdePkg/Include/Protocol/LegacySpiSmmFlash.h  |  36 +++
>  MdePkg/Include/Protocol/SpiConfiguration.h   | 293
> 
>  MdePkg/Include/Protocol/SpiHc.h  | 194 +
>  MdePkg/Include/Protocol/SpiIo.h  | 292 +++
>  MdePkg/Include/Protocol/SpiNorFlash.h| 289
> +++
>  MdePkg/Include/Protocol/SpiSmmConfiguration.h|  36 +++
>  MdePkg/Include/Protocol/SpiSmmHc.h   |  36 +++
>  MdePkg/MdePkg.dec|  31 +++
>  11 files changed, 1709 insertions(+)
> 
> diff --git a/MdePkg/Include/Protocol/LegacySpiController.h
> b/MdePkg/Include/Protocol/LegacySpiController.h
> new file mode 100644
> index ..2d36eaefc0ee
> --- /dev/null
> +++ b/MdeP

Re: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols introduced in UEFI PI 1.6.

[Bi, Dandan]

Hi Marvin,

Thank you for your contribution. I am reviewing this patch now. Currently I 
just take a look at the SMM SPI part and find:

1. There is a typo in LegacySpiSmmController.h
The definition should be EFI_LEGACY_SPI_SMM_CONTROLLER_GUID, not 
EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID.
Typo:
#define EFI_LEGACY_SPI_SMM_FLASH_PROTOCOL_GUID  \
  { 0x62331b78, 0xd8d0, 0x4c8c, \
{ 0x8c, 0xcb, 0xd2, 0x7d, 0xfe, 0x32, 0xdb, 0x9b }}
And it should  be:
#define EFI_LEGACY_SPI_SMM_CONTROLLER_GUID \
{ 0x62331b78, 0xd8d0, 0x4c8c, { 0x8c, 0xcb, 0xd2, 0x7d, \ 0xfe, 0x32, 0xdb, 
0x9b }}

2. EFI_SPI_SMM_NOR_FLASH_PROTOCOL definition seems to be missing.

I will review the remaining part. It may take some time. Sorry for the delay in 
my response

Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Thursday, September 7, 2017 3:13 PM
To: Marvin Häuser <marvin.haeu...@outlook.com>; edk2-devel@lists.01.org
Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming 
<liming....@intel.com>; Bi, Dandan <dandan...@intel.com>
Subject: RE: [PATCH v1] MdePkg: Add definitions for the SPI protocols 
introduced in UEFI PI 1.6.

Marvin,
Thank you for your contribution. We will need some time to review the 
definitions against PI Spec.
If there is a need to post V2, it might be better to separate the header files 
in different groups.
For example, LegacySpi group, SPI group, SMM SPI group.

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of
> Marvin Häuser
> Sent: Wednesday, September 6, 2017 5:21 PM
> To: edk2-devel@lists.01.org
> Cc: Kinney, Michael D <michael.d.kin...@intel.com>; Gao, Liming
> <liming@intel.com>
> Subject: [edk2] [PATCH v1] MdePkg: Add definitions for the SPI protocols
> introduced in UEFI PI 1.6.
> 
> This commit adds header files for the SPI protocols introduced in the
> UEFI PI 1.6 specification, as well as their GUIDs to MdePkg.dec.
> 
> EFI_SPI_TRANSACTION_TYPE assumes an enum with its members ordered
> the
> way they are listed in the specification, as there are no values given
> explicitely.
> EFI_LEGACY_SPI_CONTROLLER_GUID assumes the character 'l' used in the
> specification was meant to be '1'.
> 
> Contributed-under: TianoCore Contribution Agreement 1.1
> Signed-off-by: Marvin Haeuser <marvin.haeu...@outlook.com>
> ---
>  MdePkg/Include/Protocol/LegacySpiController.h| 265
> ++
>  MdePkg/Include/Protocol/LegacySpiFlash.h | 201 ++
>  MdePkg/Include/Protocol/LegacySpiSmmController.h |  36 +++
>  MdePkg/Include/Protocol/LegacySpiSmmFlash.h  |  36 +++
>  MdePkg/Include/Protocol/SpiConfiguration.h   | 293
> 
>  MdePkg/Include/Protocol/SpiHc.h  | 194 +
>  MdePkg/Include/Protocol/SpiIo.h  | 292 +++
>  MdePkg/Include/Protocol/SpiNorFlash.h| 289
> +++
>  MdePkg/Include/Protocol/SpiSmmConfiguration.h|  36 +++
>  MdePkg/Include/Protocol/SpiSmmHc.h   |  36 +++
>  MdePkg/MdePkg.dec|  31 +++
>  11 files changed, 1709 insertions(+)
> 
> diff --git a/MdePkg/Include/Protocol/LegacySpiController.h
> b/MdePkg/Include/Protocol/LegacySpiController.h
> new file mode 100644
> index ..2d36eaefc0ee
> --- /dev/null
> +++ b/MdePkg/Include/Protocol/LegacySpiController.h
> @@ -0,0 +1,265 @@
> +/** @file
> +  This file defines the Legacy SPI Controller Protocol.
> +
> +  Copyright (c) 2017, Intel Corporation. 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.
> +
> +  @par Revision Reference:
> +This Protocol was introduced in UEFI PI Specification 1.6.
> +
> +**/
> +
> +#ifndef __LEGACY_SPI_CONTROLLER_PROTOCOL_H__
> +#define __LEGACY_SPI_CONTROLLER_PROTOCOL_H__
> +
> +///
> +/// Note: The UEFI PI 1.6 specification uses the character 'l' in the GUID
> +///   definition. This definition assumes it was supposed to be '1'.
> +///
> +/// Global ID for the Legacy SPI Controller Protocol
> +///
> +#define EFI_LEGACY_SPI_CONTROLLER_GUID  \
> +  { 0x39136fc7, 0x1a11, 0x49de, \
> +{ 0xbf, 0x35, 0x0e, 0x78, 0xdd, 0xb5, 0x24, 0xfc }}
> +
> +typedef
> +struct _EFI_LEGACY_SPI_CONTROLLER_PROTOCOL
> +EFI_

Re: [edk2] [PATCH 4/5] MdeModulePkg/PartitionDxe: don't divide 64-bit values with C operators

[Bi, Dandan]

Hi Laszlo,

When do you plan to push this patch? IA32 build is blocked for this issue now.

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Laszlo 
Ersek
Sent: Sunday, September 10, 2017 8:13 AM
To: edk2-devel-01 
Cc: Ni, Ruiyu ; Dong, Eric ; Zeng, 
Star ; Ard Biesheuvel 
Subject: [edk2] [PATCH 4/5] MdeModulePkg/PartitionDxe: don't divide 64-bit 
values with C operators

In edk2, the division and shifting of 64-bit values are forbidden with 
C-language operators, because the compiler may generate intrinsic calls for 
them.

For example, clang-3.8 emits a call to "__umoddi3" for

  UDF_LOGICAL_SECTOR_SIZE % Media->BlockSize

in PartitionInstallUdfChildHandles(), if PartitionDxe is built for IA32, which 
then fails to link.

UDF_LOGICAL_SECTOR_SIZE has type UINT64, while EFI_BLOCK_IO_MEDIA.BlockSize has 
type UINT32(). Replace the % operator with a DivU64x32Remainder() call.

Cc: Ard Biesheuvel 
Cc: Eric Dong 
Cc: Paulo Alcantara 
Cc: Ruiyu Ni 
Cc: Star Zeng 
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek 
---
 MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c 
b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
index c1d44809bfd2..c491ef25f47e 100644
--- a/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
+++ b/MdeModulePkg/Universal/Disk/PartitionDxe/Udf.c
@@ -234,10 +234,11 @@ PartitionInstallUdfChildHandles (
   IN  EFI_BLOCK_IO_PROTOCOL*BlockIo,
   IN  EFI_BLOCK_IO2_PROTOCOL   *BlockIo2,
   IN  EFI_DEVICE_PATH_PROTOCOL *DevicePath
   )
 {
+  UINT32   RemainderByMediaBlockSize;
   EFI_STATUS   Status;
   EFI_BLOCK_IO_MEDIA   *Media;
   EFI_DEVICE_PATH_PROTOCOL *DevicePathNode;
   EFI_GUID *VendorDefinedGuid;
   EFI_GUID UdfDevPathGuid = EFI_UDF_DEVICE_PATH_GUID;
@@ -246,11 +247,16 @@ PartitionInstallUdfChildHandles (
   Media = BlockIo->Media;
 
   //
   // Check if UDF logical block size is multiple of underlying device block 
size
   //
-  if ((UDF_LOGICAL_SECTOR_SIZE % Media->BlockSize) != 0 ||
+  DivU64x32Remainder (
+UDF_LOGICAL_SECTOR_SIZE,   // Dividend
+Media->BlockSize,  // Divisor
+ // Remainder
+);
+  if (RemainderByMediaBlockSize != 0 ||
   Media->BlockSize > UDF_LOGICAL_SECTOR_SIZE) {
 return EFI_NOT_FOUND;
   }
 
   DevicePathNode = DevicePath;
--
2.14.1.3.gb7cf6e02401b


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HiiSetToDefaults behavior

[Bi, Dandan]

Hi Wim Vervoorn,

Yes, it's correct for some Questions like oneof, numeric, if they don't have 
default value, this call will  take first option value, minimum value as their 
default value. But for Question like String opcode, if it doesn't have default, 
the value of this question will be untouched with this call.

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wim 
Vervoorn
Sent: Friday, August 25, 2017 5:08 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Subject: Re: [edk2] HiiSetToDefaults behavior

Hello Dandan,

Thanks for the clarification.

So I assume there is no way that will cause this call to leave certain fields 
as they are. Is this correct?


Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED 
RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF 
YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER 
BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS 
MESSAGE AND ALL COPIES." 




-Original Message-
From: Bi, Dandan [mailto:dandan...@intel.com] 
Sent: Friday, August 25, 2017 10:57 AM
To: Wim Vervoorn <wvervo...@eltan.com>; edk2-devel@lists.01.org
Subject: RE: HiiSetToDefaults behavior

Hi Wim Vervoorn,

Current behavior of HiiSetToDefaults():
1. For Question has the specified type default value, will set the default 
value to storage for the Question.
2. For Question without the specified type default,  other type default value 
can be shared.(such as: standard default doesn't exit, but Manufacturing 
Default exits, Manufacturing Default value can
 be shared with standard default)
3. For Question without any types of default value, current implementation will 
(a) set first option value as the default value of oneof
(b) set minimum value as the default value of numeric
 


Thanks,
Dandan
  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wim 
Vervoorn
Sent: Friday, August 25, 2017 4:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] HiiSetToDefaults behavior

Hello,

I have a question about the expect behavior of HiiSetToDefaults(). So far I 
haven't been able to find a clear definition of what this should do.

What I expect is that this call would only touch the items that have a default 
defined. So what I would think is that Test2OfValue below would become 1 and 
Test1OfValue would be untouched as long as it's value is either 0 or 1 and 
become 1 if this is not the case.

What seems to happen is that for Test1OfValue the first item is used as the 
default.

oneof name = Test1OneOf,   // Define reference name 
for Question
  varid   = lIfrNVData.Test1OfValue,  
// Use "DataStructure.Member" to reference Buffer Storage
  prompt  = STRING_TOKEN(STR_TEST1_PROMPT),
  help= STRING_TOKEN(STR_TEST1_HELP),
  //
  // Define an option (EFI_IFR_ONE_OF_OPTION)
  //
  option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = 0;
  option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 0; endoneof;

oneof name = Test2OneOf,   // Define reference name 
for Question
  varid   = lIfrNVData.Test2OfValue,  
// Use "DataStructure.Member" to reference Buffer Storage
  prompt  = STRING_TOKEN(STR_TEST2_PROMPT),
  help= STRING_TOKEN(STR_TEST2_HELP),
  //
  // Define an option (EFI_IFR_ONE_OF_OPTION)
  //
  option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = DEFAULT;
  option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 0; endoneof;


Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@eltan.com
W : http://www.eltan.com<http://www.eltan.com/>
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED 
RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF 
YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER 
BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS 
MESSAGE AND ALL COPIES."



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HiiSetToDefaults behavior

[Bi, Dandan]

Hi Wim Vervoorn,

Current behavior of HiiSetToDefaults():
1. For Question has the specified type default value, will set the default 
value to storage for the Question.
2. For Question without the specified type default,  other type default value 
can be shared.(such as: standard default doesn't exit, but Manufacturing 
Default exits, Manufacturing Default value can
 be shared with standard default)
3. For Question without any types of default value, current implementation will 
(a) set first option value as the default value of oneof
(b) set minimum value as the default value of numeric
 


Thanks,
Dandan
  

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wim 
Vervoorn
Sent: Friday, August 25, 2017 4:13 PM
To: edk2-devel@lists.01.org
Subject: [edk2] HiiSetToDefaults behavior

Hello,

I have a question about the expect behavior of HiiSetToDefaults(). So far I 
haven't been able to find a clear definition of what this should do.

What I expect is that this call would only touch the items that have a default 
defined. So what I would think is that Test2OfValue below would become 1 and 
Test1OfValue would be untouched as long as it's value is either 0 or 1 and 
become 1 if this is not the case.

What seems to happen is that for Test1OfValue the first item is used as the 
default.

oneof name = Test1OneOf,   // Define reference name 
for Question
  varid   = lIfrNVData.Test1OfValue,  
// Use "DataStructure.Member" to reference Buffer Storage
  prompt  = STRING_TOKEN(STR_TEST1_PROMPT),
  help= STRING_TOKEN(STR_TEST1_HELP),
  //
  // Define an option (EFI_IFR_ONE_OF_OPTION)
  //
  option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = 0;
  option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 0; endoneof;

oneof name = Test2OneOf,   // Define reference name 
for Question
  varid   = lIfrNVData.Test2OfValue,  
// Use "DataStructure.Member" to reference Buffer Storage
  prompt  = STRING_TOKEN(STR_TEST2_PROMPT),
  help= STRING_TOKEN(STR_TEST2_HELP),
  //
  // Define an option (EFI_IFR_ONE_OF_OPTION)
  //
  option text = STRING_TOKEN(STR_ENABLE), value = 1, flags = DEFAULT;
  option text = STRING_TOKEN(STR_DISABLE), value = 0, flags = 0; endoneof;


Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED 
RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF 
YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER 
BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS 
MESSAGE AND ALL COPIES."



___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] HiiValidateSettings issue with string item

[Bi, Dandan]

Hi Wim Vervoorn,

Thanks for reporting this issue. It's a bug of current code and your solution 
can fix it correctly. 
But when the storage is NameValueType, for string opcode, current code also 
calculate the string length incorrectly, the length should not include the 
trailing terminator and storage name. 
So could you help to file a bug on bugzilla and then we can fix these issues?
https://bugzilla.tianocore.org/

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Wim 
Vervoorn
Sent: Thursday, August 24, 2017 2:59 PM
To: edk2-devel@lists.01.org
Subject: [edk2] HiiValidateSettings issue with string item

Hello,

I am running into an issue with HiiValidateSettings (); when my VFR contains a 
string item that is filled with a string of maximum length. In this case the 
validation returns an error because it thinks the string is too long.

During the validation ValidateQuestionFromVfr (); checks if the stringlength is 
valid. The issue is that this uses the "maxsize" value * 2 from the VFR. It 
does this using the StrSize function which includes the trailing terminator. 
This is of course correct. The maxsize from the VFR indicates only the amount 
of characters excluding the terminator.

As a quickfix I changed the ValidateQuestionFromVfr () to take this into 
account but I am doubting if this is the correct solution. Can you shed some 
light here?

Below is the fragment where I see this issue:

//
// Get Offset/Width by Question header and OneOf Flags
//
Offset = IfrString->Question.VarStoreInfo.VarOffset;
//
// Check whether this question is in current block array.
//
if (!BlockArrayCheck (CurrentBlockArray, Offset, Width)) {
  //
  // This question is not in the current configuration string. Skip 
it.
  //
  break;
}
//
// Check this var question is in the var storage
//
if ((Offset + Width) > VarStoreData.Size) {
  //
  // This question exceeds the var store size.
  //
  return EFI_INVALID_PARAMETER;
}

//
// Check current string length is less than maxsize
//
// Please note we subtract sizeof(CHAR16) here because the StrSize 
returns the length including the terminator
// while we specify the length in characters in the VFR!
//
ORG -> // if ( (StrSize ((CHAR16 *) (VarBuffer + Offset)) > 
Width) {
CHANGED->if ( (StrSize ((CHAR16 *) (VarBuffer + Offset)) - 
sizeof(CHAR16)) > Width) {
  return EFI_INVALID_PARAMETER;
}
  }
  break;
Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@eltan.com
W : http://www.eltan.com
"THIS MESSAGE CONTAINS CONFIDENTIAL INFORMATION. UNLESS YOU ARE THE INTENDED 
RECIPIENT OF THIS MESSAGE, ANY USE OF THIS MESSAGE IS STRICTLY PROHIBITED. IF 
YOU HAVE RECEIVED THIS MESSAGE IN ERROR, PLEASE IMMEDIATELY NOTIFY THE SENDER 
BY TELEPHONE +31-(0)73-5944664 OR REPLY EMAIL, AND IMMEDIATELY DELETE THIS 
MESSAGE AND ALL COPIES."


___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] How to add images to HiiDatabase.

[Bi, Dandan]

When the driver is loaded, LoadImage() installs EFI_HII_PACKAGE_LIST_PROTOCOL on
the image handle if the image contains HII resource. 
So you can get the image package list through HiiPackageListProtocol,
And then add the image package list to HII database through NewPackageList API 
in Database Protocol.

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Amit 
kumar
Sent: Wednesday, August 9, 2017 1:29 AM
To: Zhu, Yonghong 
Cc: edk2-devel@lists.01.org
Subject: Re: [edk2] How to add images to HiiDatabase.


i refered edk2/MdeModulePkg/Logo but the problem is how to pass logo.bmp to 
hiidatabase ?
Amit
On Aug 8, 2017, at 7:20 PM, Zhu, Yonghong 
> wrote:

The IMAGE_TOKEN should be used in the source file.
You can refer  edk2/MdeModulePkg/Logo

Best Regards,
Zhu Yonghong


-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Amit 
kumar
Sent: Tuesday, August 08, 2017 8:31 PM
To: edk2-devel@lists.01.org
Subject: [edk2] How to add images to HiiDatabase.


Hi ,

Can somebody tell me how to add images to hiidatabase . I have image.png file 
and a image.idf file.
Is there something than has to be done during compilation ? like Vfr ?
can i use HiiAddPackages ?

Thanks And Regards
Amit Kumar

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH] MdeModulePkg ResetSystem: Update the comments of ResetSystem()

[Bi, Dandan]

Star, thanks for detecting that. Reviewed-by: Dandan Bi <dandan...@intel.com>

Thanks,
Dandan

-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Star Zeng
Sent: Thursday, June 29, 2017 10:45 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Bi, Dandan <dandan...@intel.com>; Zeng, 
Star <star.z...@intel.com>
Subject: [edk2] [PATCH] MdeModulePkg ResetSystem: Update the comments of 
ResetSystem()

Update the comments of ResetSystem() that was missed by
37078045d717 and 28426918f0ea.

Cc: Ruiyu Ni <ruiyu...@intel.com>
Cc: Dandan Bi <dandan...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.z...@intel.com>
---
 MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c |  3 +++  
MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h | 10 +-
 2 files changed, 12 insertions(+), 1 deletion(-)

diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
index f61e65e151ab..ba839eef39b2 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.c
@@ -95,6 +95,9 @@ DoS3 (
 valid if ResetStatus is something other than 
EFI_SUCCESS
 unless the ResetType is 
EfiResetPlatformSpecific
 where a minimum amount of ResetData is always 
required.
+For a ResetType of EfiResetPlatformSpecific 
the data buffer
+also starts with a Null-terminated string that 
is followed
+by an EFI_GUID that describes the specific 
type of reset to perform.
 **/
 VOID
 EFIAPI
diff --git a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h 
b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
index c3a2a7f1279a..e007d118e53f 100644
--- a/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
+++ b/MdeModulePkg/Universal/ResetSystemRuntimeDxe/ResetSystem.h
@@ -56,10 +56,18 @@ InitializeResetSystem (
 
   @param[in] ResetType  The type of reset to perform.
   @param[in] ResetStatusThe status code for the reset.
-  @param[in] DataSize   The size, in bytes, of WatchdogData.
+  @param[in] DataSize   The size, in bytes, of ResetData.
   @param[in] ResetData  For a ResetType of EfiResetCold, EfiResetWarm, 
or
 EfiResetShutdown the data buffer starts with a 
Null-terminated
 string, optionally followed by additional 
binary data.
+The string is a description that the caller 
may use to further
+indicate the reason for the system reset. 
ResetData is only
+valid if ResetStatus is something other than 
EFI_SUCCESS
+unless the ResetType is 
EfiResetPlatformSpecific
+where a minimum amount of ResetData is always 
required.
+For a ResetType of EfiResetPlatformSpecific 
the data buffer
+also starts with a Null-terminated string that 
is followed
+by an EFI_GUID that describes the specific 
type of reset to perform.
 
 **/
 VOID
--
2.7.0.windows.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [PATCH v2 4/8] MdePkg/HiiImageDecoder.h: Remove the unnecessary comments

[Bi, Dandan]

Yes. I will remove it before checking in the codes. Thanks.

Regards,
Dandan
-Original Message-
From: Zeng, Star 
Sent: Monday, June 19, 2017 12:55 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Gao, Liming <liming@intel.com>; Zeng, 
Star <star.z...@intel.com>
Subject: RE: [edk2] [PATCH v2 4/8] MdePkg/HiiImageDecoder.h: Remove the 
unnecessary comments

Just found below comments in MdePkg.dec, should it be removed also?

  ##
  ## In UEFI 2.6 spec,this guid value is duplicate with
  ## EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID. Now update this guid value to
  ## avoid the duplicate guid issue. So its value is not consistent with
  ## UEFI spec definition now. We have proposed to update UEFI spec to
  ## use this new guid. After new spec released, we will remove this
  ## comments.
  ##

Thanks,
Star
-Original Message-
From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of Dandan Bi
Sent: Monday, June 19, 2017 12:46 PM
To: edk2-devel@lists.01.org
Cc: Ni, Ruiyu <ruiyu...@intel.com>; Gao, Liming <liming@intel.com>
Subject: [edk2] [PATCH v2 4/8] MdePkg/HiiImageDecoder.h: Remove the unnecessary 
comments

Cc: Liming Gao <liming@intel.com>
Cc: Ruiyu Ni <ruiyu...@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Dandan Bi <dandan...@intel.com>
---
 MdePkg/Include/Protocol/HiiImageDecoder.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/MdePkg/Include/Protocol/HiiImageDecoder.h 
b/MdePkg/Include/Protocol/HiiImageDecoder.h
index 48a1a97..34eb5e1 100644
--- a/MdePkg/Include/Protocol/HiiImageDecoder.h
+++ b/MdePkg/Include/Protocol/HiiImageDecoder.h
@@ -16,19 +16,10 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER 
EXPRESS OR IMPLIED.
 #ifndef __HII_IMAGE_DECODER_H__
 #define __HII_IMAGE_DECODER_H__
 
 #include 
 
-
-//
-// In UEFI 2.6 spec,this guid value is duplicate with -// 
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL_GUID. Now update this guid value to -// avoid 
the duplicate guid issue. So its value is not consistent with -// UEFI spec 
definition now. We have proposed to update UEFI spec to -// use this new guid. 
After new spec released, we will remove this -// comments.
-//
 #define EFI_HII_IMAGE_DECODER_PROTOCOL_GUID \
   {0x9e66f251, 0x727c, 0x418c, { 0xbf, 0xd6, 0xc2, 0xb4, 0x25, 0x28, 0x18, 
0xea }}
 
 
 #define EFI_HII_IMAGE_DECODER_NAME_JPEG_GUID \
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel
___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Re: [edk2] [RFC v2 1/2] BaseTool/VfrCompile: Support Union type in VFR

[Bi, Dandan]

Hi Ray,

Thanks for your comments! Yes, we also can avoid using member variable.

Based on my understanding, we can parse value to sub-statement.
So when parsing a Struct/Union type, it  can pass this info to its member 
fields , then we can detect whether current Data Type is Struct or Union.
In this case, we need to update all the definitions of the dataStructField and 
related functions.

If we add member variable/ global variable, we can keep the definition of the 
dataStructField same as before, no need to consider whether  they are members
Of a Struct or Union in the parsing  part. When calculating the TotalSize of 
current  Data Type , we can know the Data Type according to the member 
variable/ global variable.

I am ok to update the codes to avoid adding new member variable and will send 
new patches.

Liming/Eric, do you have any comments for this ?


Thanks,
Dandan

-Original Message-
From: Ni, Ruiyu 
Sent: Monday, June 5, 2017 2:49 PM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [RFC v2 1/2] BaseTool/VfrCompile: Support Union type in VFR

Dandan,
Is it possible to avoid adding IsUnion member variable?
I remember .G syntax supports passing value to sub-statement.
In this case, can you use: vfrDataStructFields [IsUnion]?

Thanks/Ray

> -Original Message-----
> From: Bi, Dandan
> Sent: Monday, June 5, 2017 12:31 PM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>; Ni, Ruiyu <ruiyu...@intel.com>
> Subject: [RFC v2 1/2] BaseTool/VfrCompile: Support Union type in VFR
> 
> V2: Update VfrCompiler to use member variable instead of global 
> varable to indicate whether current date type is Union.
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Cc: Ruiyu Ni <ruiyu...@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  BaseTools/Source/C/VfrCompile/VfrSyntax.g   | 19 ++-
>  BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp | 16 ++--
>  BaseTools/Source/C/VfrCompile/VfrUtilityLib.h   |  3 ++-
>  3 files changed, 34 insertions(+), 4 deletions(-)
> 
> diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> index 406dbc5..9e1212a 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> +++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> @@ -155,10 +155,11 @@ VfrParserStart (
>  #token Label("label")   "label"
>  #token Timeout("timeout")   "timeout"
>  #token Inventory("inventory")   "inventory"
>  #token NonNvDataMap("_NON_NV_DATA_MAP") "_NON_NV_DATA_MAP"
>  #token Struct("struct") "struct"
> +#token Union("union")   "union"
>  #token Boolean("BOOLEAN")   "BOOLEAN"
>  #token Uint64("UINT64") "UINT64"
>  #token Uint32("UINT32") "UINT32"
>  #token Uint16("UINT16") "UINT16"
>  #token Char16("CHAR16") "CHAR16"
> @@ -270,10 +271,11 @@ vfrProgram > [UINT8 Return] :
>   mConstantOnlyInExpression = FALSE;
>>>
>(
>vfrPragmaPackDefinition
>  | vfrDataStructDefinition
> +| vfrDataUnionDefinition
>)*
>vfrFormSetDefinition
><< $Return = mParserStatus; >>
>;
> 
> @@ -318,12 +320,27 @@ vfrPragmaPackDefinition :
>  | pragmaPackNumber
>}
>"\)"
>;
> 
> +  vfrDataUnionDefinition :
> +  { TypeDef } Union<<
> gCVfrVarDataTypeDB.DeclareDataTypeBegin (TRUE); >>
> +  { NonNvDataMap }
> +  {
> +N1:StringIdentifier <<
> _PCATCH(gCVfrVarDataTypeDB.SetNewTypeName (N1->getText()), N1); >>
> +  }
> +  OpenBrace
> +vfrDataStructFields
> +  CloseBrace
> +  {
> +N2:StringIdentifier <<
> _PCATCH(gCVfrVarDataTypeDB.SetNewTypeName (N2->getText()), N2); >>
> +  }
> +  ";"   << 
> gCVfrVarDataTypeDB.DeclareDataTypeEnd
> ();>>
> +  ;
> +
>  vfrDataStructDefinition :
> -  { TypeDef } Struct<<
> gCVfrVarDataType

Re: [edk2] [RFC 1/2] BaseTool/VfrCompile: Support Union type in VFR

[Bi, Dandan]

Hi Ray,

I can update the logic in VfrCompiler to avoid using gUnionTypeStructure. New 
patches will send out.
Thanks for your comments.

Regards,
Dandan


-Original Message-
From: Ni, Ruiyu 
Sent: Monday, June 5, 2017 10:35 AM
To: Bi, Dandan <dandan...@intel.com>; edk2-devel@lists.01.org
Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming <liming@intel.com>
Subject: RE: [edk2] [RFC 1/2] BaseTool/VfrCompile: Support Union type in VFR

Dandan,
Can you avoid using gUnionTypeStructure?

Thanks/Ray

> -Original Message-
> From: edk2-devel [mailto:edk2-devel-boun...@lists.01.org] On Behalf Of 
> Dandan Bi
> Sent: Monday, June 5, 2017 10:13 AM
> To: edk2-devel@lists.01.org
> Cc: Dong, Eric <eric.d...@intel.com>; Gao, Liming 
> <liming@intel.com>
> Subject: [edk2] [RFC 1/2] BaseTool/VfrCompile: Support Union type in 
> VFR
> 
> Cc: Eric Dong <eric.d...@intel.com>
> Cc: Liming Gao <liming@intel.com>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Dandan Bi <dandan...@intel.com>
> ---
>  BaseTools/Source/C/VfrCompile/VfrSyntax.g   | 17 +
>  BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp | 13 -
>  BaseTools/Source/C/VfrCompile/VfrUtilityLib.h   |  1 +
>  3 files changed, 30 insertions(+), 1 deletion(-)
> 
> diff --git a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> index 406dbc5..bd8457d 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> +++ b/BaseTools/Source/C/VfrCompile/VfrSyntax.g
> @@ -155,10 +155,11 @@ VfrParserStart (
>  #token Label("label")   "label"
>  #token Timeout("timeout")   "timeout"
>  #token Inventory("inventory")   "inventory"
>  #token NonNvDataMap("_NON_NV_DATA_MAP") "_NON_NV_DATA_MAP"
>  #token Struct("struct") "struct"
> +#token Union("union")   "union"
>  #token Boolean("BOOLEAN")   "BOOLEAN"
>  #token Uint64("UINT64") "UINT64"
>  #token Uint32("UINT32") "UINT32"
>  #token Uint16("UINT16") "UINT16"
>  #token Char16("CHAR16") "CHAR16"
> @@ -270,10 +271,11 @@ vfrProgram > [UINT8 Return] :
>   mConstantOnlyInExpression = FALSE;
>>>
>(
>vfrPragmaPackDefinition
>  | vfrDataStructDefinition
> +| vfrDataUnionDefinition
>)*
>vfrFormSetDefinition
><< $Return = mParserStatus; >>
>;
> 
> @@ -318,10 +320,25 @@ vfrPragmaPackDefinition :
>  | pragmaPackNumber
>}
>"\)"
>;
> 
> +  vfrDataUnionDefinition :
> +  { TypeDef } Union<< gUnionTypeStructure = 
> TRUE;
> gCVfrVarDataTypeDB.DeclareDataTypeBegin (); >>
> +  { NonNvDataMap }
> +  {
> +N1:StringIdentifier <<
> _PCATCH(gCVfrVarDataTypeDB.SetNewTypeName (N1->getText()), N1); >>
> +  }
> +  OpenBrace
> +vfrDataStructFields
> +  CloseBrace
> +  {
> +N2:StringIdentifier <<
> _PCATCH(gCVfrVarDataTypeDB.SetNewTypeName (N2->getText()), N2); >>
> +  }
> +  ";"   << 
> gCVfrVarDataTypeDB.DeclareDataTypeEnd ();
> gUnionTypeStructure = FALSE;>>
> +  ;
> +
>  vfrDataStructDefinition :
>{ TypeDef } Struct<<
> gCVfrVarDataTypeDB.DeclareDataTypeBegin (); >>
>{ NonNvDataMap }
>{
>  N1:StringIdentifier <<
> _PCATCH(gCVfrVarDataTypeDB.SetNewTypeName (N1->getText()), N1); >> 
> diff --git a/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> b/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> index 2f97975..b392476 100644
> --- a/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> +++ b/BaseTools/Source/C/VfrCompile/VfrUtilityLib.cpp
> @@ -1018,12 +1018,14 @@ CVfrVarDataTypeDB::DataTypeAddField (  {
>SVfrDataField   *pNewField  = NULL;
>SVfrDataType*pFieldType = NULL;
>SVfrDataField   *pTmp;
>UINT32  Align;
> +  UINT32  MaxDataTypeSize;
> 
>CHECK_ERROR_RETURN (GetDataType (TypeName, ), 
> VFR_RETURN_SUCCESS);
> +  MaxDataTypeSize = mNewDataType->mTotalSize;
> 
>if (strlen (FieldName) >= MA

Re: [edk2] [PATCH] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile comment

[Bi, Dandan]

Reviewed-by: Dandan Bi <dandan...@intel.com>

-Original Message-
From: Zhang, Chao B 
Sent: Thursday, April 6, 2017 3:21 PM
To: edk2-devel@lists.01.org
Cc: Bi, Dandan <dandan...@intel.com>; Zhang, Chao B <chao.b.zh...@intel.com>
Subject: [PATCH] SecurityPkg: SecureBootConfigDxe: Update CloseEnrolledFile 
comment

Update function CloseEnrolledFile comment introduced in 
4de754e15fec9c94ce7677904efd0022c211721b

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zh...@intel.com>
---
 .../SecureBootConfigDxe/SecureBootConfigImpl.c| 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c 
b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
index b124c21..2eaf246 100644
--- 
a/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootConfigImpl.c
+++ b/SecurityPkg/VariableAuthenticated/SecureBootConfigDxe/SecureBootCo
+++ nfigImpl.c
@@ -98,15 +98,11 @@ SECUREBOOT_CONFIG_PRIVATE_DATA  *gSecureBootPrivateData = 
NULL;
 
 /**
   This code cleans up enrolled file by closing file & free related resources 
attached to
-  enrolled file
+  enrolled file.
 
-  @param[in] FileSuffixThe suffix of the input certificate file
-
-  @retvalTRUE   It's a DER-encoded certificate.
-  @retvalFALSE  It's NOT a DER-encoded certificate.
+  @param[in] FileContextFileContext cached in SecureBootConfig 
driver
 
 **/
-
 VOID
 CloseEnrolledFile(
   IN SECUREBOOT_FILE_CONTEXT *FileContext
--
1.9.5.msysgit.1

___
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel