Tianocore/edk2.git/DynamicTablesPkg/Drivers, branch dependabot/github_actions/actions/github-script-9

DynamicTablesPkg: Replace include guards with #pragma once

2026-02-23T21:01:28+00:00

Replace traditional `#ifndef`/`#define`/`#endif` include guards with `#pragma` once. `#pragma once` is a widely supported preprocessor directive that prevents header files from being included multiple times. It is supported by all toolchains used to build edk2: GCC, Clang/LLVM, and MSVC. Compared to macro-based include guards, `#pragma once`: - Eliminates the risk of macro name collisions or copy/paste errors where two headers inadvertently use the same guard macro. - Eliminate inconsistency in the way include guard macros are named (e.g., some files use `__FILE_H__`, others use `FILE_H_`, etc.). - Reduces boilerplate (three lines replaced by one). - Avoids polluting the macro namespace with guard symbols. - Can improve build times as the preprocessor can skip re-opening the file entirely, rather than re-reading it to find the matching `#endif` ("multiple-include optimization"). - Note that some compilers may already optimize traditional include guards, by recognzining the idiomatic pattern. This change is made acknowledging that overall portability of the code will technically be reduced, as `#pragma once` is not part of the C/C++ standards. However, this is considered acceptable given: 1. edk2 already defines a subset of supported compilers in BaseTools/Conf/tools_def.template, all of which have supported `#pragma once` for over two decades. 2. There have been concerns raised to the project about inconsistent include guard naming and potential macro collisions. Approximate compiler support dates: - MSVC: Supported since Visual C++ 4.2 (1996) - GCC: Supported since 3.4 (2004) (http://gnu.ist.utl.pt/software/gcc/gcc-3.4/changes.html) - Clang (LLVM based): Since initial release in 2007 Signed-off-by: Michael Kubacki

DynamicTablesPkg/DynamicTableManagerDxe: Add RISC-V support

2025-12-02T20:52:41+00:00

Add RISC-V-specific mAcpiVerifyTables entries to enable verification of RISC-V ACPI tables during Dynamic Table Manager execution. This ensures that RISC-V ACPI tables such as MADT, RHCT, and others are properly validated and integrated at runtime. Signed-off-by: Sunil V L

DynamicTablesPkg: DynamicTableManagerDxe: Fix NULL pointer dereference

2025-09-30T08:27:48+00:00

BuildAndInstallMultipleSmbiosTables() can dereference a NULL pointer if the SMBIOS table builder returns a NULL CmObjToken array. Signed-off-by: Sarah Walker

DynamicTablesPkg: Add SMBIOS table generation

2025-09-30T08:27:48+00:00

Add the SMBIOS Table generator code to the DynamicTablesPkg. This change includes adding new logic to the DynamicTableManager to process and add SMBIOS tables and augmenting the existing SMBIOS Factory generator to include installing multiple SMBIOS tables. Signed-off-by: Girish Mahadevan

DynamicTablesPkg: Move ACPI building & change DEPEX on protocol

2025-09-30T08:27:48+00:00

In preparation to introduce Dynamic SMBIOS support the following 2 changes are required: 1. Use ProtocolNotify Event for generating the ACPI tables and don't include the ACPI protocol in the Depex section for DynamicTableManagerDxe Driver. This is because if a platforms doesn't do ACPI based boot or if doesn't want to install SMBIOS tables we still want the DynamicTableManager to be dispatched to install the SMBIOS or ACPI tables respectively. 2. Split the logic for building the ACPI tables to a separate file. Signed-off-by: Girish Mahadevan

DynamicTablesPkg: Add Ordered dispatch support for SMBIOS tables

2025-09-30T08:27:48+00:00

Some SMBIOS tables do not have a fixed dependency and can depend on any other SMBIOS tables. Therefore, the SMBIOS dispatcher cannot define a fixed sequence for dispatching these tables. A possible solution is to defer the dispatch of such SMBIOS tables towards the end, assuming that the dependent SMBIOS tables would have been dispatched by then. Therefore, introduce a dispatch order attribute such that SMBIOS tables that have a fixed dependency sequence are configured as Default Ordered, and the SMBIOS tables that do not have a fixed dependency have an Order attribute specifying an Order Level. An Order Level is used to sequence the dispatch of Ordered SMBIOS tables. The Default Ordered SMBIOS tables are dispatched first and a dependency walk is performed to dispatch the dependent tables by iterating through the SMBIOS_TABLE_DISPATCHER.Dependency[]. Once all Default ordered SMBIOS tables have been dispatched, the Ordered SMBIOS tables would be scheduled for dispatch in increasing order as of the Order Level, e.g. OrderL1, OrderL2, ... Note: The dispatcher does not perform a dependency walk for the Ordered SMBIOS tables as the expectation is that the dependent SMBIOS tables would be already dispatched. A top level dispatch function DispatchSmbiosTables() has been introduced to schedule the dispatch of Default Ordered and Ordered SMBIOS tables. Signed-off-by: Sami Mujawar Cc: Alexei Fedorov Cc: Pierre Gondois Cc: Girish Mahadevan Cc: Jeff Brasen Cc: Ashish Singhal Cc: Nick Ramirez Cc: William Watson Cc: Abner Chang Cc: Samer El-Haj-Mahmoud Cc: Jose Marinho

DynamicTablesPkg: Update SMBIOS dispatcher dependency table

2025-09-30T08:27:48+00:00

Update the SMBIOS table dispatcher dependency table to add the table dependencies for SMBIOS table Type 19, Type 20, Type 27, Type 35 and Type 37. The SMBIOS table Type 35 can have dependency on 6 other SMBIOS tables. Therefore, increase the MAX_SMBIOS_DEPENDENCY to 6, and also update the SMBIOS table dispatcher table accordingly. Signed-off-by: Sami Mujawar Cc: Alexei Fedorov Cc: Pierre Gondois Cc: Girish Mahadevan Cc: Jeff Brasen Cc: Ashish Singhal Cc: Nick Ramirez Cc: William Watson Cc: Abner Chang Cc: Samer El-Haj-Mahmoud Cc: Jose Marinho

DynamicTablesPkg: Add SMBIOS table dispatcher

2025-09-30T08:27:48+00:00

Some SMBIOS structure/table fields have dependency on other SMBIOS structures/tables. These dependencies are established using handles pointing to the dependent tables. A SMBIOS table handle can be obtained by either installing a SMBIOS table or by allocating a handle, which requires complex management to avoid any clashes. Obtaining a SMBIOS handle by installation requires that the dependent table is installed before the parent SMBIOS table can be installed. Therefore, introduce a SMBIOS table dispatcher that walks the SMBIOS dependency list and schedules the dependent tables to be installed before the parent table is installed. Signed-off-by: Sami Mujawar Cc: Alexei Fedorov Cc: Pierre Gondois Cc: Girish Mahadevan Cc: Jeff Brasen Cc: Ashish Singhal Cc: Nick Ramirez Cc: William Watson Cc: Abner Chang Cc: Samer El-Haj-Mahmoud Cc: Jose Marinho

DynamicTablesPkg: Drop ARM32 Support

2025-09-25T22:04:10+00:00

edk2 is dropping support for the ARM32 architecture. This commit removes ARM32 code from DynamicTablesPkg. This also drops irrelevant VALID_ARCHITECTURES comments from infs that are not arch specific. Signed-off-by: Oliver Smith-Denny

DynamicTablesPkg: Drop IA32 support

2025-09-22T18:24:48+00:00

All DynamicTablesPkg libraries and drivers execute in the DXE phase, where both AMD and Intel platforms operate in X64 (64-bit) mode. Therefore, IA32 (32-bit) support is no longer required for DynamicTablesPkg. Signed-off-by: Abdul Lateef Attar