[edk2-devel] [PATCH v1 0/1] Update IASL extdep for CI

2020-09-11 Thread Matthew Carlson 
From: Matthew Carlson 

Currently EDK2 has an external dependency to download the IASL compiler.
This updates that nuget stream with a much more current version produced
by a pipeline that runs regularly. Feel free to check out the repo here:

https://dev.azure.com/projectmu/_git/acpica

To reiterate, this only affects CI and should not affect platforms unless
they are explictly using the 'cibuild' scope.

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Cc: Sean Brogan 
Cc: devel@edk2.groups.io

Matthew Carlson (1):
  BaseTools: update IASL extdep to more modern version

 BaseTools/Bin/iasl_ext_dep.yaml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

-- 
2.28.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65198): https://edk2.groups.io/g/devel/message/65198
Mute This Topic: https://groups.io/mt/76788779/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH v1 1/1] BaseTools: update IASL extdep to more modern version

2020-09-11 Thread Matthew Carlson 
From: Matthew Carlson 

The IASL extdep is used for CI only and a recent fork of the ACPICA
repo was made to make nuget builds more regular and easier to audit.
https://dev.azure.com/projectmu/_git/acpica

Cc: Bob Feng 
Cc: Liming Gao 
Cc: Yuwei Chen 
Cc: Sean Brogan 
Cc: devel@edk2.groups.io

Signed-off-by: Matthew Carlson 
---
 BaseTools/Bin/iasl_ext_dep.yaml | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/BaseTools/Bin/iasl_ext_dep.yaml b/BaseTools/Bin/iasl_ext_dep.yaml
index 1d81e89cf3a6..ea2bc315d184 100644
--- a/BaseTools/Bin/iasl_ext_dep.yaml
+++ b/BaseTools/Bin/iasl_ext_dep.yaml
@@ -14,8 +14,8 @@
   "id": "iasl-ci-1",
   "scope": "cibuild",
   "type": "nuget",
-  "name": "iasl",
-  "source": "https://api.nuget.org/v3/index.json;,
-  "version": "20190215.0.0",
+  "name": "edk2-acpica-iasl",
+  "source": 
"https://pkgs.dev.azure.com/projectmu/acpica/_packaging/mu_iasl/nuget/v3/index.json;,
+  "version": "20200717.0.0",
   "flags": ["set_path", "host_specific"]
 }
-- 
2.28.0.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65199): https://edk2.groups.io/g/devel/message/65199
Mute This Topic: https://groups.io/mt/76788780/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] Platform/RaspberryPi4: Correct thermal offset

2020-09-11 Thread Jeremy Linton 

Hi,
On 9/11/20 1:13 PM, Pete Batard wrote:
It might be worth sourcing public documentation, if you have any, 
indicating where these numeric values ultimately come from (the offset 
for absolute zero is easy to figure out, but the rest, not so much).


I'm only privy to things that can be found with a google search.

So at the moment I'm not aware of proper first party documentation on 
the thermal sensor.


So 
https://elixir.bootlin.com/linux/v5.9-rc4/source/arch/arm/boot/dts/bcm2711.dtsi#L413 
gives us the base+slope values (410040, 487). Given the linux the units 
are in 1/1000h C, the remainder of the calculation is to adjust to 1/10th K.


There is also 
https://www.raspberrypi.org/documentation/hardware/raspberrypi/frequency-management.md


There is also a bit of documentation around "temp_limit"

https://www.raspberrypi.org/documentation/configuration/config-txt/overclocking.md

Which names 80-85C as the region that the cores should be throttled and 
some other thermal recommendations.


Finally, various mentions of the AVS (beyond the official document 
naming the int, but not the base address despite it being in the DT) in 
commit messages/etc help to clarify things, but none are particularly 
helpful on their own.





Apart from that:

On 2020.09.10 00:11, Jeremy Linton wrote:

The current mainline DT indicates that the thermal offset
on the rpi is 410040 rather than the 419949 being used.
This means our temp calculation is offset nearly 10C higher
when running in ACPI mode vs DT.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl

index 2b9e8211cf..d116f965e1 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -269,7 +269,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", 
"RPI", 2)

    Field (TEMS, DWordAcc, NoLock, Preserve) {

  TMPS, 32

    }

-  return (((419949 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

+  return (((410040 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

  }

  Method (_SCP, 3) { }   // receive cooling policy 
from OS





Reviewed-by: Pete Batard 



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65197): https://edk2.groups.io/g/devel/message/65197
Mute This Topic: https://groups.io/mt/76744696/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH] UefiCpuPkg/RegisterCpuFeaturesLib: Support MpServices2 only case.

2020-09-11 Thread Ni, Ray 
A rough check in phone. Why inf file is not changed?


发件人: Dong, Eric 
发送时间: Friday, September 11, 2020 10:31:32 AM
收件人: Chiu, Chasel ; devel@edk2.groups.io 

抄送: Chiu, Chasel ; Ni, Ray ; Laszlo 
Ersek ; Kumar, Rahul1 ; Desimone, 
Nathaniel L 
主题: RE: [PATCH] UefiCpuPkg/RegisterCpuFeaturesLib: Support MpServices2 only 
case.

Reviewed-by: Eric Dong 

-Original Message-
From: Chasel Chiu 
Sent: Thursday, September 10, 2020 5:03 PM
To: devel@edk2.groups.io
Cc: Chiu, Chasel ; Dong, Eric ; Ni, 
Ray ; Laszlo Ersek ; Kumar, Rahul1 
; Desimone, Nathaniel L 
Subject: [PATCH] UefiCpuPkg/RegisterCpuFeaturesLib: Support MpServices2 only 
case.

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

MpServices Ppi can be replaced by MpServices2 Ppi and MpServices2 Ppi is 
mandatory for RegisterCpuFeaturesLib functionality, basing on this we can drop 
MpServices Ppi usage from the library and the constraint that both Ppis must be 
installed.

Cc: Eric Dong 
Cc: Ray Ni 
Cc: Laszlo Ersek 
Cc: Rahul Kumar 
Cc: Nate DeSimone 
Signed-off-by: Chasel Chiu 
---
 UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c | 61 
+++--
 UefiCpuPkg/Library/RegisterCpuFeaturesLib/RegisterCpuFeatures.h   |  6 
+++---
 2 files changed, 26 insertions(+), 41 deletions(-)

diff --git 
a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c 
b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c
index 64768f7a74..4e558e9fee 100644
--- a/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLib.c
+++ b/UefiCpuPkg/Library/RegisterCpuFeaturesLib/PeiRegisterCpuFeaturesLi
+++ b.c
@@ -1,7 +1,7 @@
 /** @file
   CPU Register Table Library functions.

-  Copyright (c) 2016 - 2019, Intel Corporation. All rights reserved.
+  Copyright (c) 2016 - 2020, Intel Corporation. All rights
+ reserved.
   SPDX-License-Identifier: BSD-2-Clause-Patent

 **/
@@ -11,7 +11,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 

 #include "RegisterCpuFeatures.h"
@@ -75,10 +74,10 @@ GetMpService (
   MP_SERVICESMpService;

   //
-  // Get MP Services Protocol
+  // Get MP Services2 Ppi
   //
   Status = PeiServicesLocatePpi (
- ,
+ ,
  0,
  NULL,
  (VOID **)
@@ -100,17 +99,17 @@ GetProcessorIndex (
   )
 {
   EFI_STATUS Status;
-  EFI_PEI_MP_SERVICES_PPI*CpuMpPpi;
+  EDKII_PEI_MP_SERVICES2_PPI *CpuMp2Ppi;
   UINTN  ProcessorIndex;

-  CpuMpPpi = CpuFeaturesData->MpService.Ppi;
+  CpuMp2Ppi = CpuFeaturesData->MpService.Ppi;

   //
   // For two reasons which use NULL for WhoAmI:
   // 1. This function will be called by APs and AP should not use PeiServices 
Table
   // 2. Check WhoAmI implementation, this parameter will not be used.
   //
-  Status = CpuMpPpi->WhoAmI(NULL, CpuMpPpi, );
+  Status = CpuMp2Ppi->WhoAmI (CpuMp2Ppi, );
   ASSERT_EFI_ERROR (Status);
   return ProcessorIndex;
 }
@@ -131,16 +130,15 @@ GetProcessorInformation (
   OUT EFI_PROCESSOR_INFORMATION*ProcessorInfoBuffer
   )
 {
-  EFI_PEI_MP_SERVICES_PPI*CpuMpPpi;
+  EDKII_PEI_MP_SERVICES2_PPI *CpuMp2Ppi;
   EFI_STATUS Status;
   CPU_FEATURES_DATA  *CpuFeaturesData;

   CpuFeaturesData = GetCpuFeaturesData ();
-  CpuMpPpi = CpuFeaturesData->MpService.Ppi;
+  CpuMp2Ppi = CpuFeaturesData->MpService.Ppi;

-  Status = CpuMpPpi->GetProcessorInfo (
-   GetPeiServicesTablePointer(),
-   CpuMpPpi,
+  Status = CpuMp2Ppi->GetProcessorInfo (
+   CpuMp2Ppi,
ProcessorNumber,
ProcessorInfoBuffer
);
@@ -162,18 +160,17 @@ StartupAllAPsWorker (
   )
 {
   EFI_STATUS   Status;
-  EFI_PEI_MP_SERVICES_PPI  *CpuMpPpi;
+  EDKII_PEI_MP_SERVICES2_PPI   *CpuMp2Ppi;
   CPU_FEATURES_DATA*CpuFeaturesData;

   CpuFeaturesData = GetCpuFeaturesData ();
-  CpuMpPpi = CpuFeaturesData->MpService.Ppi;
+  CpuMp2Ppi = CpuFeaturesData->MpService.Ppi;

   //
   // Wakeup all APs for data collection.
   //
-  Status = CpuMpPpi->StartupAllAPs (
- GetPeiServicesTablePointer (),
- CpuMpPpi,
+  Status = CpuMp2Ppi->StartupAllAPs (
+ CpuMp2Ppi,
  Procedure,
  FALSE,
  0,
@@ -203,17 +200,7 @@ StartupAllCPUsWorker (
   //
   // Get MP Services2 Ppi
   //
-  Status = PeiServicesLocatePpi (
- ,
- 0,
- NULL,
- (VOID **)
- );
-  ASSERT_EFI_ERROR (Status);
-
-  //
-  // Wakeup all APs for data collection.
-  //
+  CpuMp2Ppi = CpuFeaturesData->MpService.Ppi;
   Status = CpuMp2Ppi->StartupAllCPUs (
  CpuMp2Ppi,
  Procedure,
@@ -234,18 +221,17 @@ SwitchNewBsp (
   )
 {
   EFI_STATUS   Status;

Re: [edk2-devel] [PATCH] Platform/RaspberryPi4: Correct thermal offset

2020-09-11 Thread Pete Batard 
It might be worth sourcing public documentation, if you have any, 
indicating where these numeric values ultimately come from (the offset 
for absolute zero is easy to figure out, but the rest, not so much).


Apart from that:

On 2020.09.10 00:11, Jeremy Linton wrote:

The current mainline DT indicates that the thermal offset
on the rpi is 410040 rather than the 419949 being used.
This means our temp calculation is offset nearly 10C higher
when running in ACPI mode vs DT.

Signed-off-by: Jeremy Linton 
---
  Platform/RaspberryPi/AcpiTables/Dsdt.asl | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Platform/RaspberryPi/AcpiTables/Dsdt.asl 
b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
index 2b9e8211cf..d116f965e1 100644
--- a/Platform/RaspberryPi/AcpiTables/Dsdt.asl
+++ b/Platform/RaspberryPi/AcpiTables/Dsdt.asl
@@ -269,7 +269,7 @@ DefinitionBlock ("Dsdt.aml", "DSDT", 5, "RPIFDN", "RPI", 2)
Field (TEMS, DWordAcc, NoLock, Preserve) {

  TMPS, 32

}

-  return (((419949 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

+  return (((410040 - ((TMPS & 0x3ff) * 487)) / 100) + 2732);

  }

  Method (_SCP, 3) { }   // receive cooling policy from OS

  



Reviewed-by: Pete Batard 

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65195): https://edk2.groups.io/g/devel/message/65195
Mute This Topic: https://groups.io/mt/76744696/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] uefi-sct/SctPkg: Correct issue with memory protection enabled.

2020-09-11 Thread Jeff Brasen 
On systems with memory protection enabled the modification of local
function initialization data results in permission issue. Make a copy of
data prior to modification.

Signed-off-by: Jeff Brasen 
---
 .../UnicodeCollationBBTestFunction.c  | 38 ++-
 .../UnicodeCollation2BBTestFunction.c | 38 ++-
 2 files changed, 42 insertions(+), 34 deletions(-)

diff --git 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation/BlackBoxTest/UnicodeCollationBBTestFunction.c
 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation/BlackBoxTest/UnicodeCollationBBTestFunction.c
index 6fa11e6c..e0b4c1d9 100644
--- 
a/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation/BlackBoxTest/UnicodeCollationBBTestFunction.c
+++ 
b/uefi-sct/SctPkg/TestCase/UEFI/EFI/Protocol/UnicodeCollation/BlackBoxTest/UnicodeCollationBBTestFunction.c
@@ -25,7 +25,7 @@ Abstract:
 --*/

 

 

-#include "SctLib.h"
+#include "SctLib.h"

 #include "UnicodeCollationBBTestMain.h"

 

 

@@ -337,6 +337,7 @@ BBTestStrLwrFunctionAutoTest (
 };

 

   CHAR16   TestDataSav[MAX_SIZE_OF_STRING + 1];

+  CHAR16   TestDataRw[MAX_SIZE_OF_STRING + 1];

 

 

 

@@ -368,14 +369,15 @@ BBTestStrLwrFunctionAutoTest (
 //

 // Backup current test data

 //

+CopyUnicodeString (TestDataRw, TestData[Index]);

 CopyUnicodeString (TestDataSav, TestData[Index]);

 

 //

 // For each test data, test the StrLwr functionality.

 //

-UnicodeCollation->StrLwr (UnicodeCollation, TestData[Index]);

+UnicodeCollation->StrLwr (UnicodeCollation, TestDataRw);

 

-if (CheckStrLwr (TestDataSav, TestData[Index])) {

+if (CheckStrLwr (TestDataSav, TestDataRw)) {

   AssertionType = EFI_TEST_ASSERTION_PASSED;

 } else {

   AssertionType = EFI_TEST_ASSERTION_FAILED;

@@ -390,15 +392,15 @@ BBTestStrLwrFunctionAutoTest (
__FILE__,

(UINTN)__LINE__,

TestDataSav,

-   TestData[Index]

+   TestDataRw

);

 

 

-CopyUnicodeString (TestDataSav, TestData[Index]);

-UnicodeCollation->StrUpr (UnicodeCollation, TestData[Index]);

-UnicodeCollation->StrLwr (UnicodeCollation, TestData[Index]);

+CopyUnicodeString (TestDataSav, TestDataRw);

+UnicodeCollation->StrUpr (UnicodeCollation, TestDataRw);

+UnicodeCollation->StrLwr (UnicodeCollation, TestDataRw);

 

-if (CheckStrEql (TestDataSav, TestData[Index])) {

+if (CheckStrEql (TestDataSav, TestDataRw)) {

   AssertionType = EFI_TEST_ASSERTION_PASSED;

 } else {

   AssertionType = EFI_TEST_ASSERTION_FAILED;

@@ -413,7 +415,7 @@ BBTestStrLwrFunctionAutoTest (
__FILE__,

(UINTN)__LINE__,

TestDataSav,

-   TestData[Index]

+   TestDataRw

);

   };

 

@@ -458,6 +460,7 @@ BBTestStrUprFunctionAutoTest (
 };

 

   CHAR16   TestDataSav[MAX_SIZE_OF_STRING + 1];

+  CHAR16   TestDataRw[MAX_SIZE_OF_STRING + 1];

 

 

 

@@ -490,13 +493,14 @@ BBTestStrUprFunctionAutoTest (
 // Backup current test data

 //

 CopyUnicodeString (TestDataSav, TestData[Index]);

+CopyUnicodeString (TestDataRw, TestData[Index]);

 

 //

 // For each test data, test the StrUpr functionality.

 //

-UnicodeCollation->StrUpr (UnicodeCollation, TestData[Index]);

+UnicodeCollation->StrUpr (UnicodeCollation, TestDataRw);

 

-if (CheckStrUpr (TestDataSav, TestData[Index])) {

+if (CheckStrUpr (TestDataSav, TestDataRw)) {

   AssertionType = EFI_TEST_ASSERTION_PASSED;

 } else {

   AssertionType = EFI_TEST_ASSERTION_FAILED;

@@ -511,14 +515,14 @@ BBTestStrUprFunctionAutoTest (
__FILE__,

(UINTN)__LINE__,

TestDataSav,

-   TestData[Index]

+   TestDataRw

);

 

-CopyUnicodeString (TestDataSav, TestData[Index]);

-UnicodeCollation->StrLwr (UnicodeCollation, TestData[Index]);

-UnicodeCollation->StrUpr (UnicodeCollation, TestData[Index]);

+CopyUnicodeString (TestDataSav, TestDataRw);

+UnicodeCollation->StrLwr (UnicodeCollation, TestDataRw);

+UnicodeCollation->StrUpr (UnicodeCollation, TestDataRw);

 

-if (CheckStrEql (TestDataSav, TestData[Index])) {

+if (CheckStrEql (TestDataSav, TestDataRw)) {

   AssertionType = EFI_TEST_ASSERTION_PASSED;

 } else {

   AssertionType = EFI_TEST_ASSERTION_FAILED;

@@ -533,7 +537,7 @@ BBTestStrUprFunctionAutoTest (
__FILE__,

(UINTN)__LINE__,

TestDataSav,

-   TestData[Index]

+

[edk2-devel] [PATCH] MdeModulePkg/NonDiscoverablePciDeviceDxe: Add NULL pointer check

2020-09-11 Thread Jeff Brasen 
Add check for NULL HostAddress in AllocateBuffer as required by UEFI
specification.

Signed-off-by: Jeff Brasen 
---
 .../NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c 
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
index a40c1a9593..363c4a765b 100644
--- 
a/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
+++ 
b/MdeModulePkg/Bus/Pci/NonDiscoverablePciDeviceDxe/NonDiscoverablePciDeviceIo.c
@@ -856,6 +856,10 @@ CoherentPciIoAllocateBuffer (
 return EFI_UNSUPPORTED;

   }

 

+  if (HostAddress == NULL) {

+return EFI_INVALID_PARAMETER;

+  }

+

   if ((MemoryType != EfiBootServicesData) &&

   (MemoryType != EfiRuntimeServicesData)) {

 return EFI_INVALID_PARAMETER;

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65193): https://edk2.groups.io/g/devel/message/65193
Mute This Topic: https://groups.io/mt/76784482/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[edk2-devel] [PATCH] MdeModulePkg/HiiDatabase: Do not modify CONST string

2020-09-11 Thread Jeff Brasen 
Update function behavior to not modify the incoming string that is
marked as CONST in the prototype.

Signed-off-by: Jeff Brasen 
---
 .../Universal/HiiDatabaseDxe/ConfigRouting.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c 
b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
index 2cad6d29f4..d492b769d5 100644
--- a/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
+++ b/MdeModulePkg/Universal/HiiDatabaseDxe/ConfigRouting.c
@@ -5497,7 +5497,6 @@ HiiBlockToConfig (
   UINTN   Index;

   UINT8   *TemBuffer;

   CHAR16  *TemString;

-  CHAR16  TemChar;

 

   TmpBuffer = NULL;

 

@@ -5564,10 +5563,13 @@ HiiBlockToConfig (
   //

   // Copy  and an additional '&' to 

   //

-  TemChar = *StringPtr;

-  *StringPtr = '\0';

-  AppendToMultiString(Config, ConfigRequest);

-  *StringPtr = TemChar;

+  TemString = AllocateCopyPool (sizeof (CHAR16) * (StringPtr - ConfigRequest + 
1), ConfigRequest);

+  if (TemString == NULL) {

+return EFI_OUT_OF_RESOURCES;

+  }

+  TemString[StringPtr - ConfigRequest] = '\0';

+  AppendToMultiString(Config, TemString);

+  FreePool (TemString);

 

   //

   // Parse each  if exists

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65192): https://edk2.groups.io/g/devel/message/65192
Mute This Topic: https://groups.io/mt/76784317/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v11 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

2020-09-11 Thread Vladimir Olovyannikov via groups.io 
> -Original Message-
> From: Laszlo Ersek 
> Sent: Friday, September 11, 2020 12:20 AM
> To: Vladimir Olovyannikov ;
> devel@edk2.groups.io
> Cc: Zhichao Gao ; Maciej Rabeda
> ; Jiaxin Wu ; Siyuan
> Fu ; Ray Ni ; Liming Gao
> ; Nd ; Samer El-Haj-Mahmoud
> 
> Subject: Re: [PATCH v11 0/1] ShellPkg/DynamicCommand: add
> HttpDynamicCommand
>
> On 09/10/20 22:33, Vladimir Olovyannikov wrote:
> > Hi Laszlo,
> >
> >> -Original Message-
> >> From: Laszlo Ersek 
> >> Sent: Wednesday, September 9, 2020 11:33 PM
>
> >>> PATCH v11 changes:
> >>> Address comments from Laszlo:
> >>>   - use TimeBaseLib.h header to get rid of duplicated constants;
> >>>   - explicitly return UINT32 in EfiTimeToEpoch().
> >>
> >> to be clear, I explicitly *disagree* with returning UINT32 from
> >> EfiTimeToEpoch().
> >>
> >> I'm not "demanding" (or even suggesting) that you update the
> >> EfiTimeToEpoch() implementation in this patch to return UINTN, but
> >> I'd like to be very clear that, IMO, for EfiTimeToEpoch() to suffer
> >> from a year 2106 problem on 64-bit systems too, is bad design. So
> >> please don't list the UINT32 return type as my suggestion -- that's
> >> the exact opposite of what I'd actually suggest.
>
> > Sorry, I must have misunderstood. Do you want me to resubmit the
> > patch? I am open to ideas.
>
> Ideally:
>
> - change the return type of EfiTimeToEpoch() to UNITN
>
> - drop the final UINT32 cast from EfiTimeToEpoch()
>
> - change the type of ElapsedSeconds to UINTN
>
> - change the expression
>
> ElapsedSeconds > 1 ? ElapsedSeconds : 1
>
>   to
>
> ElapsedSeconds > 1 ? (UINT64)ElapsedSeconds : 1
>
> - print the expression mentioned above with the format specifier %Lu
I see. Basically, it is PATCH v10. I just wanted to reuse TimeBaseLib.h
constants in PATCH v11.

>
> *BUT*. These are really just small details. It would be OK to fix these up
> later,
> incrementally. Where I see a real problem is the lack of timely feedback
> from
> the ShellPkg maintainers.
Agreed. Hopefully, it can be reviewed sometime soon.

Thank you,
Vladimir
>
> Laszlo

-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65191): https://edk2.groups.io/g/devel/message/65191
Mute This Topic: https://groups.io/mt/76739443/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy feature

2020-09-11 Thread Laszlo Ersek 
On 09/11/20 17:18, Bret Barkelew wrote:
> 11 Days to go. I will single out an email every day…
> 
>  
> 
> Jian, today is your day.
> How’s it going? Life good? Yeah, I know. Things are crazy here, too.
> Seattle is covered in smoke.
> You know what would brighten things up, though? A nice “reviewed 
> byâ€.

I think we should discuss the review / maintenance status of core
subsystems in edk2 on the next stewards' call (in October).

A maintainer has power to block contributions by simply doing nothing.
Because of this, maintainership is a big responsibility, and
responsiveness is critical. If there is regularly no maintainer
feedback, then the affected subsystem should be considered orphaned,
and/or new co-maintainers should be added. It is not pleasant, but it
does occur over time. In particular, with a fine-grained
"Maintainers.txt", it's possible to assign reviewership / maintenance to
feature areas / groups of subsystems.

The edk2 project has to decide whether it encourages / values
contributions, or if it prefers contributors to fork and go their own
way. We should be clear and open about this. Whoever is willing to pony
up the resources needed for maintenance gets to be maintainer. Maybe not
in the orginal project but in a fork; but that's not a huge difference
from this perspective -- over time, the old project can wither and the
fork can take over.

I'm not sure if that was the original intent with Project Mu, but when
Project Mu was launched (as I perceived it), the edk2-devel list used to
be *way* more lively than it is now. Displacing upstream edk2 looked
unthinkable -- and like a really bad idea -- back then. But now this
list, if it's not dead, smells funny.

I would support adding Microsoft engineers as reviewers to core
subsystems. We could do that gradually. And until we switch over to
github.com completely, I'd be happy to help with merging patch sets for
core subsystems that have been reviewed. (Assuming the project does not
want to hand out more push access rights, in the time remaining until we
switch over to github.com.)

Bret, I'm really sorry it's taking so long; I know first hand it's
maddening. I'm especially embarrassed, on behalf of the project, because
there have been several Microsoft contributions lately, all using the
mailing list based workflow correctly and natively -- and such efforts
*deserve* timely feedback from maintainers.

Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65190): https://edk2.groups.io/g/devel/message/65190
Mute This Topic: https://groups.io/mt/75057702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy feature

2020-09-11 Thread Bret Barkelew via groups.io 
11 Days to go. I will single out an email every day…

Jian, today is your day.
How’s it going? Life good? Yeah, I know. Things are crazy here, too. Seattle is 
covered in smoke.
You know what would brighten things up, though? A nice “reviewed by”.

- Bret

From: Bret Barkelew via groups.io
Sent: Tuesday, September 8, 2020 3:20 PM
To: devel@edk2.groups.io; 
b...@corthon.com
Cc: Yao, Jiewen; Zhang, Chao 
B; Wang, Jian J; 
Wu, Hao A; liming.gao; 
Justen, Jordan L; Laszlo 
Ersek; Ard Biesheuvel; 
Andrew Fish; Ni, Ray; 
liming.gao
Subject: [EXTERNAL] Re: [edk2-devel] [PATCH v6 00/14] Add the VariablePolicy 
feature

Now that 2008 is labelled and everyone can take a breather… I still need 
reviews on the following patches (v7)…
Patch(es) 01, 02, 03,06,09,10,11,12,13,14

As such, the following email addresses may or may not be subscribed to 
CatFacts™ within the next 14 days if I get no responses:
Cc: Jian J Wang 
Cc: Hao A Wu 
Cc: Liming Gao 
Cc: Jordan Justen 
Cc: Andrew Fish 
Cc: Ray Ni 
Cc: Jiewen Yao 
Cc: Chao Zhang 

May God have mercy on your inboxes.

- Bret




-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65189): https://edk2.groups.io/g/devel/message/65189
Mute This Topic: https://groups.io/mt/75057702/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 2/2] Silicon/SiFive: Error handling for locating firmware context

2020-09-11 Thread Daniel Schaefer 

On 9/8/20 1:48 PM, Abner Chang wrote:

Add error handling in CreateU54E51CoreProcessorSpecificDataHob ()
when opensbi firmware context can't be located.

Signed-off-by: Abner Chang 
Cc: Daniel Schaefer 
Cc: Leif Lindholm 
---
  .../SiFive/U54/Library/PeiCoreInfoHobLib/CoreInfoHob.c   | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/Silicon/SiFive/U54/Library/PeiCoreInfoHobLib/CoreInfoHob.c 
b/Silicon/SiFive/U54/Library/PeiCoreInfoHobLib/CoreInfoHob.c
index edeabf028f..ea947a9d28 100644
--- a/Silicon/SiFive/U54/Library/PeiCoreInfoHobLib/CoreInfoHob.c
+++ b/Silicon/SiFive/U54/Library/PeiCoreInfoHobLib/CoreInfoHob.c
@@ -38,7 +38,7 @@
  
@return EFI_SUCCESS The PEIM initialized successfully.

EFI_UNSUPPORTED HART is ignored by platform.
-
+  EFI_NOT_FOUND   Processor specific data hob is not available.
  **/
  EFI_STATUS
  EFIAPI
@@ -64,9 +64,14 @@ CreateU54E51CoreProcessorSpecificDataHob (
  return EFI_INVALID_PARAMETER;
}
  
+  FirmwareContext = NULL;

Status = SbiGetFirmwareContext ();
ASSERT_EFI_ERROR (Status);
-  DEBUG ((DEBUG_INFO, "Firmware Context is at 0x%x.\n", FirmwareContext));
+  if (EFI_ERROR (Status) || FirmwareContext == NULL) {


The assert should already catch this, right? Especially if we fix the return 
value for
SbiGetFirmwareContext we don't also need to check the pointer.
I'd say: Let's fix the return value (like your other patch) and remove assert,
as well as the null-check here.


+DEBUG ((DEBUG_ERROR, "Failed to get the pointer of 
EFI_RISCV_OPENSBI_FIRMWARE_CONTEXT of hart %d\n", HartId));
+return Status;
+  }
+  DEBUG((DEBUG_INFO, "Firmware Context is at 0x%x.\n", FirmwareContext));
FirmwareContextHartSpecific = FirmwareContext->HartSpecific[HartId];
DEBUG ((DEBUG_INFO, "Firmware Context Hart specific is at 0x%x.\n", 
FirmwareContextHartSpecific));
if (FirmwareContextHartSpecific == NULL) {



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65188): https://edk2.groups.io/g/devel/message/65188
Mute This Topic: https://groups.io/mt/76703529/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [edk2-platforms][PATCH 1/2] ProcessorPkg/RiscVEdk2SbiLib: Error handling for locating firmware context

2020-09-11 Thread Daniel Schaefer 

Oh no, what did I do here... I don't return proper error codes at all in this 
file.
I forgot to revise this after the initial implementation.
So, good change but we should do that for all functions in this file.
I'll do that on Monday.

On 9/8/20 1:48 PM, Abner Chang wrote:

Return EFI_NOT_FOUND if opensbi firmware context can not be
located using SBI call.

Signed-off-by: Abner Chang 
Cc: Daniel Schaefer 
Cc: Leif Lindholm 
---
  .../ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c   | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git 
a/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c 
b/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c
index 0df505d267..64c30b950d 100644
--- a/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c
+++ b/Silicon/RISC-V/ProcessorPkg/Library/RiscVEdk2SbiLib/RiscVEdk2SbiLib.c
@@ -851,6 +851,8 @@ SbiGetMscratchHartid (
  
@param[out] FirmwareContext  The firmware context pointer.

@retval EFI_SUCCESS  The operation succeeds.
+  @retval EFI_NOT_FOUNDFailed to get the pointer of 
EFI_RISCV_OPENSBI_FIRMWARE_CONTEXT.
+
  **/
  EFI_STATUS
  EFIAPI
@@ -866,8 +868,9 @@ SbiGetFirmwareContext (
  ScratchSpace = (SBI_SCRATCH *)Ret.Value;
  SbiPlatform = (SBI_PLATFORM *)sbi_platform_ptr(ScratchSpace);
  *FirmwareContext = (EFI_RISCV_OPENSBI_FIRMWARE_CONTEXT 
*)SbiPlatform->firmware_context;
+  } else {
+return EFI_NOT_FOUND;
}
-
return EFI_SUCCESS;
  }
  



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65187): https://edk2.groups.io/g/devel/message/65187
Mute This Topic: https://groups.io/mt/76703528/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH v11 0/1] ShellPkg/DynamicCommand: add HttpDynamicCommand

2020-09-11 Thread Laszlo Ersek 
On 09/10/20 22:33, Vladimir Olovyannikov wrote:
> Hi Laszlo,
>
>> -Original Message-
>> From: Laszlo Ersek 
>> Sent: Wednesday, September 9, 2020 11:33 PM

>>> PATCH v11 changes:
>>> Address comments from Laszlo:
>>>   - use TimeBaseLib.h header to get rid of duplicated constants;
>>>   - explicitly return UINT32 in EfiTimeToEpoch().
>>
>> to be clear, I explicitly *disagree* with returning UINT32 from
>> EfiTimeToEpoch().
>>
>> I'm not "demanding" (or even suggesting) that you update the
>> EfiTimeToEpoch() implementation in this patch to return UINTN, but
>> I'd like to be very clear that, IMO, for EfiTimeToEpoch() to suffer
>> from a year 2106 problem on 64-bit systems too, is bad design. So
>> please don't list the UINT32 return type as my suggestion -- that's
>> the exact opposite of what I'd actually suggest.

> Sorry, I must have misunderstood. Do you want me to resubmit the
> patch? I am open to ideas.

Ideally:

- change the return type of EfiTimeToEpoch() to UNITN

- drop the final UINT32 cast from EfiTimeToEpoch()

- change the type of ElapsedSeconds to UINTN

- change the expression

ElapsedSeconds > 1 ? ElapsedSeconds : 1

  to

ElapsedSeconds > 1 ? (UINT64)ElapsedSeconds : 1

- print the expression mentioned above with the format specifier %Lu

*BUT*. These are really just small details. It would be OK to fix these
up later, incrementally. Where I see a real problem is the lack of
timely feedback from the ShellPkg maintainers.

Laszlo


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65186): https://edk2.groups.io/g/devel/message/65186
Mute This Topic: https://groups.io/mt/76739443/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [edk2-devel] [PATCH EDK2 v1 1/1] EmulatorPkg:Change DEC_VERSION to DEC_SPECIFICATION

2020-09-11 Thread Laszlo Ersek 
On 09/11/20 03:49, Wenyi Xie wrote:
> edk2 DEC specification document only knows about DEC_SPECIFICATION,
> so using DEC_VERSION in [Defines] section in EmulatorPkg.dec is not
> correct.
> 
> Cc: Jordan Justen 
> Cc: Andrew Fish 
> Cc: Ray Ni 
> Signed-off-by: Wenyi Xie 
> ---
>  EmulatorPkg/EmulatorPkg.dec | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/EmulatorPkg/EmulatorPkg.dec b/EmulatorPkg/EmulatorPkg.dec
> index 90a8d2a8681a..064f963c72c6 100644
> --- a/EmulatorPkg/EmulatorPkg.dec
> +++ b/EmulatorPkg/EmulatorPkg.dec
> @@ -11,7 +11,7 @@
>  ##
>  
>  [Defines]
> -  DEC_VERSION= 0x00010005
> +  DEC_SPECIFICATION  = 0x00010005
>PACKAGE_NAME   = EmulatorPkg
>PACKAGE_GUID   = 36E48BD7-7D92-5A47-A2CD-513F072E3300
>PACKAGE_VERSION= 0.1
> 

Reviewed-by: Laszlo Ersek 


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.

View/Reply Online (#65185): https://edk2.groups.io/g/devel/message/65185
Mute This Topic: https://groups.io/mt/76771244/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub  [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-