Skip to content

Releases: microsoft/mu_feature_ipmi

v3.0.6

20 Sep 02:39
9768b85
Compare
Choose a tag to compare

What's Changed

  • Initialize the FRB2 watchdog timer in DXE phase if PEI is not supported. @ScottieKuo (#257)
    Change Details
      Initialize the FRB2 watchdog timer in DXE phase if PEI is not supported.

    Description

    PEIM driver support was limited on ARM based project and caused FRB2
    watchdog timer was not enabled.

    Expected Behavior:
    FRB2 watchdog timer should be set correctly based on policy.

    FIX APPLIED:
    Add FRB2 timer running check, if timer is not running and policy is set,
    enable FRB2 watchdog timer.

    For details on how to complete these options and their meaning refer to CONTRIBUTING.md.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Tested with ARM based project and observed the watchdog timer was set
    based on policy setting.

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    
  • update CI branches to release/202405 @apop5 (#253)
    Change Details
      ## Description

    Update the CI branches to release/202405

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    CI

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    

Full Changelog: v3.0.5...v3.0.6

v3.0.5

26 Jul 22:22
253124f
Compare
Choose a tag to compare

What's Changed

  • Add NULL Check to allow IpmiSendCommandInternal flow through avoinding assert as routine does not consider NULL para… @anandakrishnanl (#243)
    Change Details
      ## Description

    IpmiSendCommandInternal did not allow NULL parameter for ResponseData and ResponseDataSize Parameters.

    Expected Behavior:
    NULL can be passed as parameter for some specific IPMI commands.

    FIX APPLIED:
    Allow IpmiSendCommandInternal to allow a NULL parameter as long as ResponseDataSize is zero.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Tested with Oem Specific Ipmi Command. Prior to change, cpu exception occurred. After fix, system was able to continue.

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    

Full Changelog: v3.0.4...v3.0.5

v3.0.4

13 Jul 18:30
0dd1c5b
Compare
Choose a tag to compare

What's Changed

  • IpmiFeaturePkg/IpmiSmbios/GoogleTest/IpmiSmbiosGoogleTest: Fix unit t… @apop5 (#239)
    Change Details
      ## Description

    Unit tests started failing due to compilation errors. This stemmed from a bug fixed in microsoft/mu_basecore#891. Once this bug was fixed, the unit tests starting to be compiled which blocked pipelines.

    For each item, place an "x" in between [ and ] if true. Example: [x].
    (you can also check items in the GitHub UI)

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Local CI.

    Integration Instructions

    N/A




  • Publish BMC Status even on failure from PEI @cfernald (#225)
    Change Details
      ## Description

    Removes the quick returns that cause the BMC Status HOB to not be created during failures in PEI. This allows DXE and MM to check the original init attempt status and fail out quickly if needed.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    N/A

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    
  • Add StackCheckLib Instances to Platform DSC Files @TaylorBeebe (#222)
    Change Details
      ## Description

    An instance of StackCheckLib must be in each DSC to accommodate -fstack-protector and /GS flags.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Tested in pipelines

    Integration Instructions

    N/A

      </blockquote>
      <hr>
    </details>
    

Full Changelog: v3.0.3...v3.0.4

v3.0.3

21 Feb 03:48
52b8d9c
Compare
Choose a tag to compare

What's Changed

  • remove edk2-basetools @Javagedes (#217)
    Change Details
      ## Description

    Removes edk2-basetools from pip-requirements.txt and any usage of it in the CISettings.py. The is done as there are changes in the build tools python source code that are available locally in BaseTools (as is managed by Project Mu) that is not available in edk2-basetools.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Verified the build system continues to use the local python source

    Integration Instructions

    N/A - only effects this repository's CI system.




  • Remove the ACPI device scope link. @Eathonhsu (#212)
    Change Details
      ## Description

    Remove the ACPI device scope link.

    Root cause:

    If the system LPC device is not "PC00.LPC0", this SSDT is invaild.

    It does not need to be put under any device scope, it just need an ASL device in the root path with all the required methods then the IPMI device will be initialized success and show up in device manager.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    IPMC2

    Integration Instructions

    N/A




  • Add protocol for simple access to the IPMI System Event Log @cfernald (#202)
    Change Details
      ## Description

    This pull request creates a DXE module and protocol to allow simple access to the IPMI System Event Log. This protocol is intended to be used by boot loaders, diagnostics tools, and other non-system components to allow less privileged access to the SEL.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Tested on local emulated machine.

    Integration Instructions

    N/A




  • Update pip-requirements.txt @apop5 (#209)
    Change Details
      ## Description

    Updates edk2-pytool-extensions and edk2-pytool-library to work with the latest commit of MU_BASECORE

    For each item, place an "x" in between [ and ] if true. Example: [x].
    (you can also check items in the GitHub UI)

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    N/A

    Integration Instructions

    N/A




  • .git-blame-ignore-revs: Ignore Line Ending and Uncrustify only commits @makubacki (#201)
    Change Details
      ## Description

    Adds commits that only applied Uncrustify formatting or converted
    line endings to a .git-blame-ignore-revs file so they are ignored
    by git blame. This is supported by GitHub:
    https://github.blog/changelog/2022-03-24-ignore-commits-in-the-blame-view-beta/

    This helps clean up git blame by filtering out these changes.

    Note: This file needs to be updated on rebase branches. Processes
    like filter-branch can automatically update relevant SHAs.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    • git blame

    Integration Instructions

    N/A




Full Changelog: v3.0.2...v3.0.3

v3.0.2

10 Jan 19:49
44b6933
Compare
Choose a tag to compare

What's Changed

  • Add BmcAcpiSwChildPolicyProtocol and RedirFruProtocol definition @MarcChen46 (#200)
    Change Details
      # Preface

    Please ensure you have read the contribution docs prior
    to submitting the pull request. In particular,
    pull request guidelines.

    Description

    Add BmcAcpiSwChildPolicyProtocol and RedirFruProtocol definition and header files from edk2platform's IpmiFeaturePkg for compatible build with Intel Platform

    For each item, place an "x" in between [ and ] if true. Example: [x].
    (you can also check items in the GitHub UI)

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Dummy code that does not impact any existed implementation.

    Integration Instructions

    N/A




  • IpmiFeaturePkgPkg: apply cpp uncrustify changes @VivianNK (#197)
    Change Details
      ## Description

    Updating Mu projects to apply uncrusty formatting for Cpp files, config updated upstream in edk2 tianocore/edk2#4957 .

    Config will be updated in mu_basecore microsoft/mu_basecore#609.

    For each item, place an "x" in between [ and ] if true. Example: [x].
    (you can also check items in the GitHub UI)

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Local CI build

    Integration Instructions

    N/A




Full Changelog: v3.0.1...v3.0.2

v3.0.1

05 Dec 23:08
4397be7
Compare
Choose a tag to compare

What's Changed

🐛 Bug Fixes

  • fix multi-part read for ssif @pharlikar (#189)
    Change Details
      ## Description

    this is to fix multi-part read issue explained in this bug #188

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    The change was tested with latest BMC that is spec compliant.

    Integration Instructions

    <Describe how these changes should be integrated. Use N/A if nothing is required.>




Full Changelog: v3.0.0...v3.0.1

v3.0.0

22 Nov 19:29
55983e3
Compare
Choose a tag to compare

What's Changed

  • Align with DxeGenericIpmi to use PcdIpmiCommandTimeoutSeconds @MarcChen46 (#185)
    Change Details
      ## Description

    Align with DxeGenericIpmi to use PcdIpmiCommandTimeoutSeconds to control IPMI cmd timeout.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Verified build and the IPMI cmd timeout can be controlled by PcdIpmiCommandTimeoutSeconds in all phase.

    Integration Instructions

    The default PcdIpmiCommandTimeoutSeconds is still 5 second, Platform is flexible to configure it in DSC file to meet platform requirement.

      </blockquote>
      <hr>
    </details>
    

⚠️ Breaking Changes

  • Replace PlatformPowerRestorePolicyConfigurationLib with PlatformPowerRestorePolicy @shrugupt (#182)
    Change Details
      ## Description

    In IpmiPowerRestorePolicy module, replace PlatformPowerRestorePolicyConfigurationLib with PlatformPowerRestorePolicy policy. Now, the platform specific power restore configuration is read via. PlatformPowerRestorePolicy.PolicyValue instead of GetPowerRestorePolicy API. Default implementation of PlatformPowerRestorePolicy is provided which always returns "no change".

    This simplifies interface to provide platform specific configuration for power restore and reduce the number of libraires.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    This was tested with consumer build pipeline on proprietary platforms.

    Integration Instructions

    1. Remove PlatformPowerRestorePolicyConfigurationLib library implementation in the platform code.
    2. Use PlatformPowerRestorePolicyDefault.inf or introduce platform code to produce PlatformPowerRestorePolicy policy.

🔐 Security Impacting

  • Use New Stack Cookie Library @TaylorBeebe (#184)
    Change Details
      ## Description

    MdePkg/MdeLibs.dsc.inc contains the definitions for the new stack cookie libraries.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Tested on Q35 GCC and MSVC builds

    Integration Instructions

    N/A




Full Changelog: v2.1.0...v3.0.0

v2.1.0

20 Oct 19:37
e4e7783
Compare
Choose a tag to compare

What's Changed

🚀 Features & ✨ Enhancements

  • Make PcdIpmiBmcReadyDelayTimer Eligible for Dynamic PCD since it may get updated in C code based on different scenarios. (ex:Normal, BMC absence, Emulator) @MarcChen46 (#171)
    Change Details
      ## Description

    Change PcdIpmiBmcReadyDelayTimer to Dynamic PCD since it may get updated in C code based on different scenarios. (ex:Normal, BMC absence, Emulator)

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Verified build and host-based unit test.

    Integration Instructions

    N/A




Full Changelog: v2.0.3...v2.1.0

v2.0.3

30 Sep 00:07
430a52f
Compare
Choose a tag to compare

What's Changed

  • Fixed debug log for gEfiEventReadyToBootGuid. @v-joschang (#163)
    Change Details
      ## Description

    Fixed debug log for gEfiEventReadyToBootGuid.

    • Impacts functionality?
      • Functionality - Does the change ultimately impact how firmware functions?
      • Examples: Add a new library, publish a new PPI, update an algorithm, ...
    • Impacts security?
      • Security - Does the change have a direct security impact on an application,
        flow, or firmware?
      • Examples: Crypto algorithm change, buffer overflow fix, parameter
        validation improvement, ...
    • Breaking change?
      • Breaking change - Will anyone consuming this change experience a break
        in build or boot behavior?
      • Examples: Add a new library class, move a module to a different repo, call
        a function in a new library class in a pre-existing module, ...
    • Includes tests?
      • Tests - Does the change include any explicit test code?
      • Examples: Unit tests, integration tests, robot tests, ...
    • Includes documentation?
      • Documentation - Does the change contain explicit documentation additions
        outside direct code modifications (and comments)?
      • Examples: Update readme file, add feature readme file, link to documentation
        on an a separate Web page, ...

    How This Was Tested

    Verified on local platform.

    Integration Instructions

    N/A




Full Changelog: v2.0.2...v2.0.3

v2.0.2

22 Sep 23:42
1dcf79e
Compare
Choose a tag to compare

What's Changed

  • Change IpmiBaseLibNull to BASE library type @cfernald (#160)
    Change Details
      ## Description

    The IpmiBaseLibNull implementation currently restricts its library types and consumes libraries that it does not use. This change cleans up and generalizes the NULL imlementation.

    • Impacts functionality?
    • Impacts security?
    • Breaking change?
    • Includes tests?
    • Includes documentation?

    How This Was Tested

    Local build

    Integration Instructions

    N/A




Full Changelog: v2.0.1...v2.0.2