[REBASE & FF]AdvLogger: Add Dynamic HW Port Error Level Filtering

[os-d]

Description

This adds partial responsibility of the C AdvLoggerHdwPortLib to Patina. That lib in the C code allows for abstracting the hw port logged to, which is already provided by the SerialIO interface in Patina. However, that lib also allows for dynamic hw port error level filtering, which Patina does not currently provide.

This PR adds an optional callback for platforms to provide an opportunity to dynamically set the hw port error level.

This originally targeted the major branch in: #1759 but feedback there gave an approach to avoid a breaking change.

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

How This Was Tested

On a platform with the existing SerialIO initialization and another platform with a custom HW port trait.

Integration Instructions

This is not a breaking change, but platforms may now introduce a custom callback, e.g.

fn platform_hw_print_level(hw_print_level: u32) -> u32 {
   if platform_debug_port_enabled() {
      hw_print_level
   } else {
      0
   }
}

static LOGGER: AdvancedLogger<UartNull> = AdvancedLogger::new(
   Format::Standard,
   &[],
   log::LevelFilter::Info,
   UartNull {},
).with_hw_print_level_override_callback(platform_hw_print_level);

[patina-automation]

✅ QEMU Validation Passed

All QEMU validation jobs completed successfully.

Note: Q35 is only built on Windows hosts (QEMU boot is disabled due to a QEMU vfat issue).

Workflow run: https://github.com/OpenDevicePartnership/patina/actions/runs/33894217197

Boot Time to EFI Shell

Platform	Elapsed
ArmVirt (Linux Host)	23.4s
Q35 (Linux Host)	26.2s

Dependencies

Repository	Ref
patina	1120550
patina-dxe-core-qemu	d2b4d6a
patina-fw-patcher	c28ab7d
patina-qemu firmware	v4.0.5
patina-qemu build script	a8b6551

This comment was automatically generated by the Patina QEMU PR Validation Post workflow.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[os-d]

@cfernald @joschock @Javagedes I have updated this to just be the callback and leaving the SerialIO trait to be the hw port abstraction. If we want to revisit a write only trait for that, we can do that in a separate PR. Let me know your thoughts.