{"push_id":735582463,"size":28,"distinct_size":28,"ref":"refs/heads/master","head":"a93130298d51df51b5bda0c547211530b12826d0","before":"53c8704060e9fb4ba5ec2e92a5e6f188a3237ab0","commits":[{"sha":"610c371d1d0f42bc2aebf51d0d7486c088e7455a","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: AcpiS3SaveDxe: prepare for End-of-Dxe callback\n\nWe are preparing for detaching the S3Ready() functionality from the\nEFI_ACPI_S3_SAVE_PROTOCOL.S3Save() protocol member function. Instead, we\nwill hook the same logic to the End-of-Dxe event group.\n\nThe EFI_ACPI_S3_SAVE_PROTOCOL has another member: GetLegacyMemorySize().\nAccording to the documenation,\n\n  This function returns the size of the legacy memory (meaning below 1 MB)\n  that is required during an S3 resume. Before the Framework-based\n  firmware transfers control to the OS, it has to transition from flat\n  mode into real mode in case the OS supplies only a real-mode waking\n  vector. This transition requires a certain amount of legacy memory.\n  After getting the size of legacy memory below, the caller is responsible\n  for allocating the legacy memory below 1 MB according to the size that\n  is returned. The specific implementation of allocating the legacy memory\n  is out of the scope of this specification.\n\nWhen EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() is called, the address of the\nlegacy memory allocated above must be passed to it, in the\nLegacyMemoryAddress parameter.\n\nIn practice however:\n\n- The S3Ready() function ignores the LegacyMemoryAddress completely.\n\n- No code in the edk2 tree calls\n  EFI_ACPI_S3_SAVE_PROTOCOL.GetLegacyMemorySize(), ever.\n\n- All callers of this specific implementation of\n  EFI_ACPI_S3_SAVE_PROTOCOL.S3Save() in the edk2 tree pass a NULL\n  LegacyMemoryAddress:\n\n  BdsLibBootViaBootOption()\n  [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c]\n\nFor this reason, ASSERT() explicitly that LegacyGetS3MemorySize() is never\ncalled, and that the LegacyMemoryAddress parameter is always NULL.\n\nThis fact is important to capture in the code, because in the End-of-Dxe\ncallback, no LegacyMemoryAddress parameter can be taken. So let's make it\nclear that we actually don't even have any use for that parameter.\n\nThis patch ports the identical change from IntelFrameworkModulePkg to\nOvmfPkg.\n\nCc: Jordan Justen <jordan.l.justen@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/610c371d1d0f42bc2aebf51d0d7486c088e7455a"},{"sha":"ebe285a7f2c19d34e6add5b9656036a18d13accb","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: AcpiS3SaveDxe: call S3Ready() at End-of-Dxe\n\nCall S3Ready() whenever the first of the following occurs:\n- a driver signals End-of-Dxe,\n- a driver calls EFI_ACPI_S3_SAVE_PROTOCOL.S3Save().\n\nS3Ready() already contains a static, function scope \"latch\" that causes it\nto exit early when called for the second time or later.\n\n(At the moment, the only platform in the edk2 tree that includes this\ndriver is OvmfPkg. That platform does not signal End-of-Dxe (yet).)\n\nhttp://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146\nSuggested-by: Yao Jiewen <jiewen.yao@intel.com>\nCc: Jordan Justen <jordan.l.justen@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/ebe285a7f2c19d34e6add5b9656036a18d13accb"},{"sha":"dde6feeff5250fd1264e39315f40b917ca5872d5","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: PlatformBdsLib: signal End-of-Dxe event group\n\n(Paraphrasing git commit 9cd7d3c5 / SVN r17713:)\n\nCurrently, OvmfPkg fails to signal the End-of-Dxe event group when\nentering the BDS phase, which results in some loss of functionality, eg.\nvariable reclaim in the variable driver, and the memory region splitting\nin the DXE core that belongs to the properties table feature specified in\nUEFI-2.5.\n\nAs discussed on the edk2-devel mailing list here:\n\nhttp://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16109\n\nit is up to the platform BDS to signal End-of-Dxe, since there may be\nplatform specific ordering constraints with respect to the signalling of\nthe event that are difficult to honor at the generic level.\n\n(OvmfPkg specifics:)\n\n(1) In OvmfPkg, we can't signal End-of-Dxe before PCI enumeration\n    completes. According to the previous patch, that would trigger\n    OvmfPkg/AcpiS3SaveDxe to save S3 state *before* the following chain of\n    action happened:\n\n    - PCI enumeration completes\n    - ACPI tables are installed by OvmfPkg/AcpiPlatformDxe\n    - the FACS table becomes available\n\n    Since OvmfPkg/AcpiS3SaveDxe can only save S3 state once the FACS table\n    is available, we must delay the End-of-Dxe signal until after PCI\n    enumeration completes (ie. root bridges are connected).\n\n(2) Pre-patch, S3Ready() in OvmfPkg/AcpiS3SaveDxe is entered from\n    BdsLibBootViaBootOption()\n    [IntelFrameworkModulePkg/Library/GenericBdsLib/BdsBoot.c].\n\n    After the patch, we enter S3Ready() earlier than that, by signaling\n    End-of-Dxe in PlatformBdsPolicyBehavior(). The timing / location of\n    this new call is correct as well, and the original call (that now\n    becomes the chronologically second call) becomes a no-op: S3Ready() is\n    protected against 2nd and later entries.\n\nCc: Jordan Justen <jordan.l.justen@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/dde6feeff5250fd1264e39315f40b917ca5872d5"},{"sha":"a1114244394073bd4a60b6cd57c2733615f32535","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"IntelFrameworkModulePkg/GenericBdsLib: remove AcpiS3->S3Save() call\n\nThe AcpiS3->S3Save() call needs to occur before the end-of-DXE event\nis signalled. The end-of-DXE event needs to be signalled prior to\ninvoking any UEFI drivers, applications, or connecting consoles.\n\nThis means the call to S3Save() that occurs in BdsLibBootViaBootOption()\nviolates the ordering constraints, and should be removed. Since it is\nthe responsibility of the platform BDS to signal the end-of-DXE event,\nit should also perform the AcpiS3->S3Save() call at an appropriate time.\n\nCommit message update from Laszlo Ersek <lersek@redhat.com>:\n\nFollowing Jiewen Yao's idea in\n\n http://thread.gmane.org/gmane.comp.bios.tianocore.devel/16088/focus=16146\n\nplatforms that\n(1) use this exact instance of GenericBdsLib, *and*\n(2) support S3\n\nshould now collect the S3 state\n(3) in an End-of-Dxe callback in their AcpiS3SaveDxe drivers, *or*\n(4) with an explicit AcpiS3->S3Save() call made to their AcpiS3SaveDxe\n    drivers from their PlatformBdsLib instances.\n\nOvmfPkg, which uses this GenericBdsLib instance, and has its own\nAcpiS3SaveDxe fork, follows (3).\n\nVlv2TbltDevicePkg, which has a GenericBdsLib fork, and uses\nIntelFrameworkModulePkg/Universal/Acpi/AcpiS3SaveDxe, follows (4).\n\nThere are no other platforms in the public edk2 repository that support\nS3.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nReviewed-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Yao, Jiewen <Jiewen.Yao@intel.com>\n[lersek@redhat.com: updated commit message]\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nCc: Jeff Fan <jeff.fan@intel.com>\nCc: Jiewen Yao <Jiewen.Yao@intel.com>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/a1114244394073bd4a60b6cd57c2733615f32535"},{"sha":"e65d7a9017eca0521a63161468e5a0a1b47a3869","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: install DxeSmmReadyToLock in PlatformBdsLib\n\nCurrently we have the following call chain in OVMF:\n\n  PlatformBdsPolicyBehavior()\n                            [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]\n    //\n    // signals End-of-Dxe\n    //\n    OnEndOfDxe()                      [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]\n      S3Ready()                       [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]\n        //\n        // 1. saves S3 state\n        //\n\n        SaveS3BootScript()            [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]\n          //\n          // 2. saves INFO opcode in S3 boot script\n          // 3. installs DxeSmmReadyToLockProtocol\n          //\n\nThe bottom of this call chain was introduced in git commit 5a217a06 (SVN\nr15305, \"OvmfPkg: S3 Suspend: save boot script after ACPI context\"). That\npatch was necessary because there was no other way, due to GenericBdsLib\ncalling S3Save() from BdsLibBootViaBootOption(), to perform the necessary\nsteps in the right order:\n- save S3 system information,\n- save a final (well, only) boot script opcode,\n- signal DxeSmmReadyToLock, closing the boot script, and locking down\n  LockBox and SMM.\n\nThe GenericBdsLib bug has been fixed in the previous patch -- the call in\nBdsLibBootViaBootOption() has been eliminated.\n\nTherefore, hoist the SaveS3BootScript() code, and call, from\nOvmfPkg/AcpiS3SaveDxe, to PlatformBdsLib:\n\n  PlatformBdsPolicyBehavior()\n                            [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]\n    //\n    // signals End-of-Dxe\n    //\n    OnEndOfDxe()                      [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]\n      S3Ready()                       [OvmfPkg/AcpiS3SaveDxe/AcpiS3Save.c]\n        //\n        // 1. saves S3 state\n        //\n\n    <---\n    SaveS3BootScript()      [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]\n      //\n      // 2. saves INFO opcode in S3 boot script\n      // 3. installs DxeSmmReadyToLockProtocol\n      //\n\nThe installation of DxeSmmReadyToLockProtocol belongs with Platform BDS,\nnot AcpiS3SaveDxe, and we can now undo the hack in SVN r15305, without\nupsetting the relative order of the steps.\n\nCc: Jordan Justen <jordan.l.justen@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/e65d7a9017eca0521a63161468e5a0a1b47a3869"},{"sha":"7daafee4bc7d852b30297800105c44aa05116724","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: AcpiS3SaveDxe: drop EFI_ACPI_S3_SAVE_PROTOCOL\n\nAt this point, nothing in the OVMF build calls EFI_ACPI_S3_SAVE_PROTOCOL\nmember functions; simplify the code by dropping this protocol interface.\n\nCc: Jordan Justen <jordan.l.justen@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/7daafee4bc7d852b30297800105c44aa05116724"},{"sha":"7a3635435dcf3db9000483c880bd863a5f3c5294","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: SmbiosPlatformDxe: move IsEntryPointStructureValid() to Xen.c\n\nThis function is only called from Xen.c, so it should be defined in Xen.c\nand have internal linkage (ie. STATIC).\n\nCc: Jordan Justen <jordan.l.justen@intel.com>\nCc: Wei Liu <wei.liu2@citrix.com>\nCc: Gabriel Somlo <somlo@cmu.edu>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Wei Liu <wei.liu2@citrix.com>\nAcked-by: Gabriel Somlo <somlo@cmu.edu>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/7a3635435dcf3db9000483c880bd863a5f3c5294"},{"sha":"8cb1e0d1443eb23bfed8c4a745814bd980e6bf99","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"OvmfPkg: SmbiosPlatformDxe: restrict current Xen code to IA32/X64\n\nThe Xen code in SmbiosPlatformDxe is centered on the informational HOB\nwith GUID gEfiXenInfoGuid, and the address constants\nXEN_SMBIOS_PHYSICAL_ADDRESS=0x000EB000,\nXEN_SMBIOS_PHYSICAL_END=0x000F0000.\n\nThis Xen hand-off mechanism is specific to the IA32 and X64 architectures,\nand it is very unlikely that a future ARM / AARCH64 implementation would\nfollow it. Therefore, sequester the IA32 / X64 specific code from the rest\nof the source, by renaming \"Xen.c\" to \"X86Xen.c\", and adding a\nGetXenSmbiosTables() stub function in \"ArmXen.c\" that returns NULL.\n\n(Those file names are inspired by\n\"OvmfPkg/Library/XenHypercallLib/X86XenHypercall.c\".)\n\nThe call site in SmbiosTablePublishEntry() [SmbiosPlatformDxe.c] is aware\nthat a NULL return value means \"Xen SMBIOS tables not found\", and will\ncontinue to the QEMU tables (for which the retrieval mechanism is shared\nby x86 and Arm).\n\nThis change enables SmbiosPlatformDxe for ARM architectures; update the\nVALID_ARCHITECTURES comment accordingly.\n\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nCc: Jordan Justen <jordan.l.justen@intel.com>\nCc: Wei Liu <wei.liu2@citrix.com>\nCc: Gabriel Somlo <somlo@cmu.edu>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/8cb1e0d1443eb23bfed8c4a745814bd980e6bf99"},{"sha":"4cba8d240f3daddb3a6c109b3443a4c7c84b1a94","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"MdeModulePkg: SmbiosDxe: ARM and AARCH64 are VALID_ARCHITECTURES\n\nThis driver is soon going to be built by ArmVirtPkg/ArmVirtQemu.dsc\n(without any changes). Although VALID_ARCHITECTURES is not used by the\nbuild system (it is just a comment), it is best kept up-to-date for human\nreaders' sake.\n\nCc: Feng Tian <feng.tian@intel.com>\nCc: Elvin Li <elvin.li@intel.com>\nCc: Star Zeng <star.zeng@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Star Zeng <star.zeng@intel.com>\nReviewed-by: Feng Tian <feng.tian@intel.com>\nReviewed-by: Jordan Justen <jordan.l.justen@intel.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/4cba8d240f3daddb3a6c109b3443a4c7c84b1a94"},{"sha":"298b5596dbec7ba9e70b473c60efc6b1f72e5a93","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"ArmVirtPkg: add QemuFwCfgToPcdDxe\n\nMany universal DXE drivers in edk2 can be controlled by setting dynamic\nPCDs. Such a PCD must be set before the consumer DXE driver is dispatched.\n\n(In general we assume that the DXE driver will consume the PCD in its\nentry point, or in the constructor of a library instance it links against.\nIn special cases this requirement can be relaxed a bit, if we know that\nthe DXE driver accesses the PCD only in a protocol member function that it\nexports.)\n\nOn the QEMU platform, the PCD values to be set for the universal drivers\nare frequently derived from fw_cfg files that QEMU exports.\n\nIn OvmfPkg we tend to handle this in the following way:\n\n- For IA32 and X64, OvmfPkg provides a QemuFwCfgLib instance that is\n  usable in PEI.\n\n- In PlatformPei, fw_cfg files can be loaded and transformed to PCD\n  values.\n\n- Any DXE driver is bound to be dispatched after the PEI phase is done.\n\n(In specific cases other ordering solutions might be possible, via Depex\nor protocol notify, etc.)\n\nIn ArmVirtPkg/ArmVirtQemu, things differ a bit:\n\n- We don't have an ArmVirtPkg-specific (\"Platform\") PEIM. This is actually\n  a good thing for now, so let's not introduce one just for this purpose.\n\n- Even if we had such a PEIM, it could not easily access fw_cfg: the MMIO\n  addresses of the fw_cfg device are available only in the DTB that QEMU\n  exports.\n\n  (Accordingly, our QemuFwCfgLib instance is restricted to DXE_DRIVER\n  modules: VirtFdtDxe parses the DTB, stores the fw_cfg addresses in PCDs,\n  and then QemuFwCfgLib's constructor fetches those PCDs.)\n\n  There are some examples in ArmVirtPkg where early code is forced to\n  parse the DTB manually, but those examples are all painful, and our goal\n  here (controlling universal DXE drivers) doesn't justify more of that\n  pain.\n\nTherefore, introduce a separate, minimal DXE driver that is dispatched\nstrictly after VirtFdtDxe (so that it can use QemuFwCfgLib), and strictly\nbefore other DXE drivers (so that it can set dynamic PCDs for them).\nBecause VirtFdtDxe is already ordered with the APRIORI DXE file, it is\nsimplest to do the same for the new driver.\n\nActual fw_cfg files and PCDs shall be accessed in future patches.\n\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/298b5596dbec7ba9e70b473c60efc6b1f72e5a93"},{"sha":"ca4c892c852e0c3167ae7adfe984acde3bee3fff","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"ArmVirtPkg: QemuFwCfgToPcdDxe: set SMBIOS entry point version dynamically\n\n(This patch parallels OvmfPkg commit 37baf06b (SVN r17676).)\n\nPcdSmbiosVersion controls the version number of the SMBIOS entry point\ntable (and other, related things) that the universal\n\"MdeModulePkg/Universal/SmbiosDxe\" driver, providing EFI_SMBIOS_PROTOCOL,\ninstalls.\n\nThe \"virt\" machine type of QEMU generates SMBIOS payload for the firmware\nto install. The payload includes the entry point table (\"anchor\" table).\nOvmfPkg/SmbiosPlatformDxe cannot install the anchor table (because that is\nthe jurisdiction of the generic \"MdeModulePkg/Universal/SmbiosDxe\"\ndriver); however, we can parse the entry point version from QEMU's anchor\ntable, and instruct \"MdeModulePkg/Universal/SmbiosDxe\" to adhere to that\nversion.\n\nAs default for PcdSmbiosVersion we should keep the current 0x0300 value\n(ie. SMBIOS 3.0) from \"MdeModulePkg/MdeModulePkg.dec\"; that spec version\nwas specifically created for ARM / AARCH64 needs.\n\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/ca4c892c852e0c3167ae7adfe984acde3bee3fff"},{"sha":"729669f6ca63525327d4b14f7829e47b7629ed78","author":{"email":"7437296077edea1cb64451c122c4dac071f0cfbc@redhat.com","name":"Laszlo Ersek"},"message":"ArmVirtPkg/ArmVirtQemu: support SMBIOS\n\nThe \"MdeModulePkg/Universal/SmbiosDxe/SmbiosDxe.inf\" driver is generic, it\nprovides EFI_SMBIOS_PROTOCOL.\n\nThe \"OvmfPkg/SmbiosPlatformDxe/SmbiosPlatformDxe.inf\" driver downloads the\nSMBIOS payload from QEMU via fw_cfg.\n\nCc: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>\nReviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/729669f6ca63525327d4b14f7829e47b7629ed78"},{"sha":"cc7f2955cc311a90320081868b08f232e822d0c8","author":{"email":"9ae9c44b775ee9b29f4f502415e02e61a9b1a6a0@cran.org.uk","name":"Bruce Cran"},"message":"NetworkPkg: Fix bug in IpSecImpl.c caused by missing parentheses\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Bruce Cran <bruce@cran.org.uk>\nCc: Siyuan Fu <siyuan.fu@intel.com>\nReviewed-by: Fu Siyuan <siyuan.fu@intel.com>\n[lersek@redhat.com: updated patch based on Siyuan's feedback]\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/cc7f2955cc311a90320081868b08f232e822d0c8"},{"sha":"90add4e4c0b06f3d3a32069d5c60310c1b5db51c","author":{"email":"a613079f0455438b29e28a9c5b9eb3779a81a33a@linaro.org","name":"Leif Lindholm"},"message":"Maintainers.txt: ARM packages maintainer update\n\nRetire Olivier Martin as maintainer, and add in\nArd Biesheuvel as a co-maintainer for the ARM packages.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Leif Lindholm <leif.lindholm@linaro.org>\nReviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nReviewed-by: Olivier Martin <Olivier.martin@arm.com>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/90add4e4c0b06f3d3a32069d5c60310c1b5db51c"},{"sha":"83249140f880c038b8d2133f86f4cdcd0bb5b1ed","author":{"email":"66d3c5fdaeea7ff1f996ad04f2c45e08ab38e2f5@linaro.org","name":"Ard Biesheuvel"},"message":"BaseTools/Common: fix heap overrun in ReadMemoryFileLine ()\n\nReadMemoryFileLine () appends a NULL character to the string\nit returns, but it failed to account for it in the allocation.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>\nReviewed-by: Yingke Liu <yingke.d.liu@intel.com>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/83249140f880c038b8d2133f86f4cdcd0bb5b1ed"},{"sha":"95ca8634f5cced0209241e46c7820c2dd7b29dd8","author":{"email":"91f509c31e98a6df13950454fe51aea543223eaa@intel.com","name":"Jiaxin Wu"},"message":"MdeModulePkg: Remove TransmitReceive() and ActiveChild dependency\n\nFix git 59a8cfd4 (SVN r17869) removes DHCP4.TransmitReceive()and DORA\nprocess dependency, but it updated TransmitReceive() to take the ownership\nof DhcpSb->ActiveChild but never release it. This will break the retransmit\nand lease time out counter of DORA.\nTo fix that, TransmitReceive() doesn't need to be the ActiveChild, and the\ntimer routine should be updated to handle the TransmitReceive specially.\n\nCc: Fu Siyuan <siyuan.fu@intel.com>\nCc: Ye Ting <ting.ye@intel.com>\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Jiaxin Wu <jiaxin.wu@intel.com>\nReviewed-by: Fu Siyuan <siyuan.fu@intel.com>\nReviewed-by: Ye Ting <ting.ye@intel.com>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/95ca8634f5cced0209241e46c7820c2dd7b29dd8"},{"sha":"0e3384188309ebdc81996eb1772451d420579957","author":{"email":"1ed5a37ea7f59966ee72cee136ab89437ba8fc11@intel.com","name":"Zhang Lubo"},"message":"NetworkPkg: Fix the issue EfiPxeBcDhcp() may return wrong status.\n\nif the instance of the EFI DHCP4 protocol driver is in the Dhcp4Bound status\nthat is DHCP configuration has completed, so the Dhcp4->Start FUNC in\nthe PxeBcDhcpDora() will return EFI_ALREADY_STARTED status which lead to\nEfiPxeBcDhcp FUNC not in correspondence with UEFI spec.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Zhang Lubo <lubo.zhang@intel.com>\nReviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>\nReviewed-by: Fu Siyuan <siyuan.fu@intel.com>\nReviewed-by: Ye Ting <ting.ye@intel.com>\n[lersek@redhat.com: updated copyright year as requested by Siyuan]\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/0e3384188309ebdc81996eb1772451d420579957"},{"sha":"ef23b6f7f45b919cb8ceb1b8d96a435d241d30c9","author":{"email":"1ed5a37ea7f59966ee72cee136ab89437ba8fc11@intel.com","name":"Zhang Lubo"},"message":"MdeModulePkg: Fix the issue EfiPxeBcDhcp() may return wrong status.\n\nif the instance of the DHCP4 protocol driver is in the Dhcp4Bound\nstatus that is DHCP configuration has completed, so the Dhcp4->Start\nFUNC in the EfiPxcBcDhcp() will return EFI_ALREADY_STARTED status\nwhich lead to EfiPxeBcDhcp FUNC not in correspondence with UEFI spec.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Zhang Lubo <lubo.zhang@intel.com>\nReviewed-by: Fu Siyuan <siyuan.fu@intel.com>\nReviewed-by: Ye Ting <ting.ye@intel.com>\n[lersek@redhat.com: updated copyright year as Siyuan asked]\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/ef23b6f7f45b919cb8ceb1b8d96a435d241d30c9"},{"sha":"95d8762471d5b22f2f49da8b1164ba9659863862","author":{"email":"be8d29debaaf5173b4b7ecb4ace852732e71f7b9@apple.com","name":"Andrew Fish"},"message":"ShellPkg: Fix bad TimeZone (TZ) conversion.\n\nEFI_UNSPECIFIED_TIMEZONE means display local time. TZ of 0 is UTC.\nThus EFI_UNSPECIFIED_TIMEZONE means ignore TZ, 0 means UTC. When this code is\nfixed to adust file TZ to local TZ you need to preserve\nEFI_UNSPECIFIED_TIMEZONE.\n\nFAT always return EFI_UNSPECIFIED_TIMEZONE.\nModern filesystems, HFS+, NTFS, ext3, etc store time in UTC.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Andrew Fish <afish@apple.com>\nReviewed-by: Jaben Carsey <jaben.carsey@intel.com>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/95d8762471d5b22f2f49da8b1164ba9659863862"},{"sha":"58bd17c38b476e9c3ae1a39f98191630cbd9ece7","author":{"email":"1e8692d8ed8470b17e8ddd7612a0f029768dcb56@intel.com","name":"Dandan Bi"},"message":"MdeModulePkg: Correct the parameter order in match2 sample opcode\n\nThe first parameter of match2 opcode should be the pattern\nand the second one should be the string.\n\nContributed-under: TianoCore Contribution Agreement 1.0\nSigned-off-by: Dandan Bi <dandan.bi@intel.com>\nReviewed-by: Liming Gao <liming.gao@intel.com>\nSigned-off-by: Laszlo Ersek <lersek@redhat.com>","distinct":true,"url":"https://api.github.com/repos/tianocore/edk2-svn-offline/commits/58bd17c38b476e9c3ae1a39f98191630cbd9ece7"}]}