v2023020001.1.1

What's Changed

• MsGraphicsPkg/FrameBufferMemDrawLib: Fix function declaration mismatch @makubacki (#282)
  
  Change Details

    ## Description

  Fixes the following issues with GetGraphicsInfo().

  1. Removes EFIAPI. This is an internal function to the library
     implementation and the explicit calling convention is not needed.
     In turn, this makes the function prototype in the C files match
     the header file.
  2. Add an include guard to the local library header file.

  Resolves the following GCC warning:

  MsGraphicsPkg/Library/FrameBufferMemDrawLib/FrameBufferMemDrawLib.h:16:1:
  warning: type of ‘GetGraphicsInfo’ does not match original declaration [-Wlto-type-mismatch]
  16 | GetGraphicsInfo (
  | ^

  • 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

  CI build.

  Integration Instructions

  N/A
  

  
  

  ---

  
  

🐛 Bug Fixes

• PcBdsPkg: Fix previous CodeQL change (51c7dc2) @kenlautner (#280)
  
  Change Details

    ## Description

  Fixes a previous CodeQL fix (51c7dc2) that was checking for NULL return values. In this case a NULL return value is valid so instead of returning a bogus boot option let the function continue.

  • 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 Physical hardware devices to confirm boot. Also confirmed CodeQL passes.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

• Add a check on the `PcdAdvancedFileLoggerFlush` for exit boot services @kuqin12 (#277)
  
  Change Details

    ## Description

  The definition of PcdAdvancedFileLoggerFlush mentioned this should be a bitmask for both exit boot services and ready to boot. However, the bit for exit boot services was ignored and a callback was registered regardless of the setting.

  This change adds a check to honor the PCD setting and removed the duplicated definition from package dec file.

  • 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 change was tested on Q35 platform and booted to Windows.

  Integration Instructions

  N/A

    </blockquote>
    <hr>
  </details>
  

Full Changelog: v2023020001.1.0...v2023020001.1.1