Tianocore/edk2.git/DynamicTablesPkg/Drivers, branch dependabot/github_actions/actions/setup-python-7

DynamicTablesPkg: Enable LoongArch64 table generation

2026-07-16T07:10:30+00:00

Add LOONGARCH64 support to DynamicTablesPkg by adding it to the existing common component build list, adding the LoongArch64 DynamicTableManagerDxe source, and enabling the SMBIOS generators used by current LoongArch platforms. Keep DynamicTableFactoryDxe generator registration architecture-specific. The LoongArch64 factory instance links selected NULL generator libraries so their constructors register the generators at runtime. LoongArch64-specific tables can use AcpiRawLib initially and move to dedicated LoongArch64 generators in follow-up patches. Signed-off-by: Dongyan Qian

DynamicTablesPkg: Clear output parameter before callback invocation

2026-06-29T07:45:14+00:00

BuildSmbiosTable() and BuildSmbiosTableEx() callback are called with uninitialized pointers which might contain garbage data. If one of these function fails, the exit handler uses these uninitialized fields. Set these uninitialized pointers in the caller function. Signed-off-by: Pierre Gondois

DynamicTablesPkg: Fix dependency issues with consumed protocols

2026-05-25T11:00:47+00:00

Direct dependency to AcpiTableDxe and was replaced with EfiCreateProtocolNotifyEvent and later the same approach was followed for SmbiosDxe. The callback function is called at least once even if the protocol is not available at the event installation time and in such case module just proceeds to build tables/records and fails due to missing dependency. Handle this situation correctly by not treating AcpiTableProtocol or SmbiosProtocol availability as an error in event callbacks. Signed-off-by: Oleksandr Tymoshenko Fixes: Fixes: a4492241a7 ("DynamicTablesPkg: Move ACPI building & change DEPEX on protocol")

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