Dynamictables: Add SMBIOS dispatcher and generators #510

gmahadevan · 2025-01-27T22:22:41Z

v2 of this PR.
Dropped the 3 generators.
Dropped the commit to add a new namespace.
Dropped the extra commit to define an extern call (not needed)

Commits included:
DynamicTablesPkg: Split the ACPI and SMBIOS table generators
DynamicTablesPkg: Add SMBIOS table generation
MdePkg/SmBios.h: Add New definition for Invalid Handle
DynamicTablesPkg: Add Ordered dispatch support for SMBIOS tables
DynamicTablesPkg: Update SMBIOS dispatcher dependency table
DynamicTablesPkg: Add SMBIOS table dispatcher
DynamicTablesPkg: Define a SMBIOS Structure/Table type

v1
Initial set of changes to add support for SMBIOS table generation that has the mods to the DynamicTablesPkg framework to install SMBIOS tables and 3 SMBIOS table generators for Type 16/17/19

DynamicTablesPkg: Smbios Memory Array Mapped Address (Type 19)
DynamicTablesPkg: Smbios Physical Memory Array (Type 16)
DynamicTablesPkg: Smbios Memory Device (Type 17)
DynamicTablesPkg: Introduce new namespace for SMBIOS Objects
DynamicTablesPkg: Split the ACPI and SMBIOS table generators
DynamicTablesPkg: Add SMBIOS table generation
DynamicTablesPkg: Add Ordered dispatch support for SMBIOS tables
DynamicTablesPkg: Update SMBIOS dispatcher dependency table
DynamicTablesPkg: Add extern call to build SMBIOS table
DynamicTablesPkg: Add SMBIOS table dispatcher
DynamicTablesPkg: Define a SMBIOS Structure/Table type
DynamicTablesPkg: SmbiosStringLib: Add new helper macro

sarah-walker-arm · 2025-02-19T13:33:22Z

DynamicTablesPkg/Include/ConfigurationManagerObject.h

  EObjNameSpaceArm,               ///< ARM Objects Namespace
-  EObjNameSpaceOem = 0xF,         ///< OEM Objects Namespace
+  EObjNameSpaceOem    = 0xF,      ///< OEM Objects Namespace
+  EObjNameSpaceSmbios,            ///< SMBIOS Objects Namespace


CM_OBJECT_ID name space ID (as defined at the top of this file) is 4 bits wide. So this addition causes an overflow.

Will change this.

sarah-walker-arm · 2025-02-19T13:34:03Z

DynamicTablesPkg/Include/Library/SmbiosStringTableLib.h

+  @param [IN]   Str       Pointer to the string
+  @param [OUT]  StrRef    The string field reference of the added string
+**/
+#define STRING_TABLE_ADD_STRING(StrTable, String, StringRef)              \


This macro isn't used anywhere in this patchset.

You are right, this patchset doesn't include the generators that use this macro.
I will drop it from the patchset and bring it back when I introduce the other generators (type3/13 etc).

samimujawar · 2025-03-07T11:11:53Z

@gmahadevan Thanks a lot for driving this effort and for this patch series.
Other than the last 3 patches in the series i.e. the generators, I have reviewed the rest of the patches. I think it would be best to review the generators once we have concluded the discussion about the introduction of the new SMBIOS Object namespace. Please see my inputs as to why I think we should not introduce a new SMBIOS object namespace. If we need to distinguish SMBIOS specific objects, it would be best to add comments to the arch common objects.

DynamicTablesPkg/Include/SmbiosNameSpaceObjects.h

samimujawar · 2025-02-06T09:14:37Z

DynamicTablesPkg/Include/ConfigurationManagerObject.h

  EObjNameSpaceArm,               ///< ARM Objects Namespace
-  EObjNameSpaceOem = 0xF,         ///< OEM Objects Namespace
+  EObjNameSpaceOem    = 0xF,      ///< OEM Objects Namespace
+  EObjNameSpaceSmbios,            ///< SMBIOS Objects Namespace


I think we should not introduce a new namespace. Can we use EObjNameSpaceArchCommon instead?

The reason for this is that we do not want duplication of information between some common ACPI and SMBIOS objects.

A good example is the information required for generating Type4 and Type7 SMBIOS tables. Most of the information therein is already available with the CM objects that we have defined for supporting PPTT table generation.
I understand that there is some additional information required for Type4 and Type7, but that can be added to the existing CM objects wherever necessary. These additional fields can remain unpopulated should
an implementation desire only ACPI tables.

Ok, that makes sense.

samimujawar · 2025-02-06T09:18:11Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/SmbiosTableBuilder.c

    }
  }

-  DEBUG ((DEBUG_ERROR, "%a: Returning %r\n", __FUNCTION__, Status));


Maybe these logs could be changed to DEBUG_VERBOSE. Also these log changes should be a separate patch.

Sorry about that, this was an accident.

MdePkg/Include/IndustryStandard/SmBios.h

samimujawar · 2025-02-06T13:55:53Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

            ETableGeneratorNameSpaceStd,        \
            TableId                             \
            )
+#define MAX_SMBIOS_HANDLES  (255)


Should we introduce a PCD PcdMaxSmbiosHandles to configure this? If so, please add a note to indicate that a large value may degrade the performance.

Sure, I can do that.

samimujawar · 2025-03-07T10:13:51Z

DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/SmbiosTableFactory/SmbiosTableFactory.c

+/** Add a new entry to the SMBIOS table Map.
+
+  @param [in]  Smbios         SMBIOS Protocol pointer.
+  @param [in]  SmbiosHandle   SMBIOS Handle to be added, if the value SMBIOS_HANDLE_PI_RESERVED


I think the documentation for the SmbiosHandle parameter is out of sync with the code. Also, do we need a pointer to the SMBIOS handle?

If the intention is that we might need to extend the functionality to generate the handle in this function and return, then please add a comment to that effect. Then again the order of invocation of the table installation and handle generation would need to change in BuildXXX functions.
Which brings us back to should we support the handle generation in this function in the first place?

acknowledged. This was a vestige of the initial implementation.
No, this code isn't meant to generate new handles, your code that setup the dispatcher ensures that any dependency between tables is taken care of.

samimujawar · 2025-03-07T10:27:50Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.c

-  IN  EFI_SYSTEM_TABLE  *SystemTable
+STATIC
+VOID
+AcpiTableProtocolReady (


Should this be part of another patch (may be before this patch)?
Also can you explain why we need this notification? Can we not use the DEPEX dependency to dispatch?
Or is this required to satisfy the dispatch for a use case wherein only ACPI tables are present and SMBIOS support is not provided ?

Also can we keep the code from line 1186 to 1237 as part of the original DynamicTableManagerDxeInitialize() ?
I see that should not need changing, right?
Furthermore, the same code is again repeated in SmbiosProtocolReady(), see line 1281 to 1332.

Correct, in systems that don't do ACPI but only SMBIOS the driver won't get dispatched and the SMBIOS tables don't get installed hence the move toward notification and not just DEPEX.
I can remove this from this patch and introduce the Protocol notification and split in the next patch in the series.
DynamicTablesPkg: Split the ACPI and SMBIOS table generators

Are you ok with splitting the ACPI and SMBIOS table generators into their own files? Or would you rather just have everything in DynamicTablesManagerDxe.c ?
@samimujawar

DynamicTablesPkg/Include/SmbiosTableGenerator.h

samimujawar · 2025-03-07T10:40:53Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+  if there is a generator for that table that hasn't been called yet.
+
+  @param [in]  Smbios         Pointer to the SMBIOS protocol.
+  @param [in]  SmbiosHandle   Pointer to an SMBIOS handle (either generated by


Please see my comment in SmbiosTableFactory::AddSmbiosHandle()

acknowledged

samimujawar · 2025-03-07T10:51:56Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+  @return  SMBIOS handle of the table associated with SmbiosTableId and
+           CmObjectToken if found. Otherwise, returns 0xFFFF.
+**/
+typedef UINT16 (EFIAPI *EDKII_DYNAMIC_TABLE_FACTORY_SMBIOS_TABLE_GET_HANDLE_EX)(


Should we use SMBIOS_HANDLE as the return type? If so please also update the implementation.

acknowledged

gmahadevan · 2025-03-12T00:04:26Z

@gmahadevan Thanks a lot for driving this effort and for this patch series. Other than the last 3 patches in the series i.e. the generators, I have reviewed the rest of the patches. I think it would be best to review the generators once we have concluded the discussion about the introduction of the new SMBIOS Object namespace. Please see my inputs as to why I think we should not introduce a new SMBIOS object namespace. If we need to distinguish SMBIOS specific objects, it would be best to add comments to the arch common objects.

Thanks for the review @samimujawar , please have a look at the latest push and let me know, I have dropped the generator patches and the patch for adding a new namespace.

samimujawar · 2025-04-03T12:43:48Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.c

  if (EFI_ERROR (Status)) {
    ASSERT_EFI_ERROR (Status);
-    return Status;
+    return;


I think this should be
return Status;

samimujawar · 2025-04-03T12:47:13Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.c

+             &SmbiosTableInfo,
+             &SmbiosTableCount
+             );
+  if (EFI_ERROR (Status)) {


I think this condition should be modified to

if (EFI_ERROR (Status)) { if (Status != EFI_NOT_FOUND)) { // If the SMBIOS table list is not found the platform may not be publishing SMBIOS tables // Log a warning and return success. DEBUG (( DEBUG_WARNING, "WARNING: Failed to get SMBIOS table List. Status = %r\n", Status)); Status = EFI_SUCCESS; } else { DEBUG (( DEBUG_ERROR, "ERROR: Failed to get SMBIOS Table List. Status = %r\n", Status )); } return Status; }

The if (Status != EFI_NOT_FOUND)) test looks to be backwards? From the comment, we want to be warning and returning success if the table list is not found and returning the error otherwise, but the code is doing the opposite.

samimujawar · 2025-04-03T14:44:45Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

 **/
 typedef EFI_STATUS (*SMBIOS_TABLE_GENERATOR_BUILD_TABLE) (
  IN  CONST SMBIOS_TABLE_GENERATOR                        *Generator,
+  IN  CONST EDKII_DYNAMIC_TABLE_FACTORY_PROTOCOL  *CONST  TableFactoryProtocol,


CmObjToken is not documented.

samimujawar · 2025-04-03T14:45:17Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

 **/
 typedef EFI_STATUS (*SMBIOS_TABLE_GENERATOR_FREE_TABLE) (
  IN  CONST SMBIOS_TABLE_GENERATOR                        *Generator,
+  IN  CONST EDKII_DYNAMIC_TABLE_FACTORY_PROTOCOL  *CONST  TableFactoryProtocol,


Please update the documentation for this parameter.

samimujawar · 2025-04-03T14:46:19Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+**/
+typedef EFI_STATUS (*SMBIOS_TABLE_GENERATOR_BUILD_TABLEEX) (
+  IN  CONST SMBIOS_TABLE_GENERATOR                         *Generator,
+  IN  CONST EDKII_DYNAMIC_TABLE_FACTORY_PROTOCOL   *CONST  TableFactoryProtocol,


Please update the documentation for the function pointer parameters. Same for the other function pointers below.

samimujawar · 2025-04-03T14:52:28Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/DynamicTableManagerDxe.c

+  EFI_EVENT  AcpiEvent;
+  EFI_EVENT  SmbiosEvent;
+
+  AcpiEvent = EfiCreateProtocolNotifyEvent (


I think it would be good to also explain in the commit message why the Protocol Notify messages are being used.

pierregondois

I think it would be nice to run the CI on the patches, but this is would be only to clean some small bits. Otherwise the structure looks good to me

pierregondois · 2025-04-03T12:51:14Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/SmbiosTableDispatcher.c

+/**
+  Initialise the SMBIOS table dispatcher.
+
+  @param SmbiosTableInfo  Pointer to the list of SMBIOS tables to be installed.


NIT: missing @param [in]

pierregondois · 2025-04-03T12:58:12Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/SmbiosTableDispatcher.h

+                                is less than the Object size for the
+                                requested object.
+**/
+extern


Does it have be extern ?

I think extern can be dropped.

pierregondois · 2025-04-03T13:00:07Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/SmbiosTableDispatcher.c

+
+  Found = FALSE;
+
+  // Update the dospatcher state to dispatched.


dispatcher

pierregondois · 2025-04-03T13:23:43Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/SmbiosTableDispatcher.c

+  // for installation and update the dispatcher status.
+  for (Index = 0; Index < SmbiosTableCount; Index++) {
+    TableType = SmbiosTableInfo[Index].TableType;
+    ASSERT (mSmBiosDispatcher[TableType].State != StPresent);


Would it be possible to add an ASSERT for

TableType < MAX_SMBIOS_TABLES

pierregondois · 2025-04-03T13:28:21Z

DynamicTablesPkg/Drivers/DynamicTableManagerDxe/SmbiosTableDispatcher.c

+  // First dispatch the default ordered SMBIOS tables
+  for (Index = 0; Index < SmbiosTableCount; Index++) {
+    TableType = SmbiosTableInfo[Index].TableType;
+    if (mSmBiosDispatcher[TableType].Order != OrderDef) {


Should assert that TableType < MAX_SMBIOS_TABLES. Same comment for InitSmbiosTableDispatcher()

I have addressed all the feedback for the first 4 patches in this series and generated a PR at #513. If PR#513[https://github.com//pull/513] looks good then we can merge that in the staging branch.
Once @gmahadevan has addressed the remaining changes in this PR, we can merge this PR as well.

Also note, I have aligned the dynamictables-reorg branch with tianocore/edk2/master branch.

Dynamic Tables Framework currently supports Arm Architecture. This patch introduces a new staging branch for Dynamic Tables Framework to: - Reorganise the code to streamline adoption by other architectures - Introduce Dynamic Tables support for RISC-V architecture - Integrate Dynamic SMBIOS support. The description is in the Readme.md file. Please create the following branches: 1. edk2-staging Repo URL: https://github.com/tianocore/edk2-staging.git Branch Name: dynamictables-reorg 2. edk2-platforms Repo URL: https://github.com/tianocore/edk2-platforms.git Branch Name: devel-dynamictables-reorg Signed-off-by: Sami Mujawar <[email protected]> Reviewed-by: Laszlo Ersek <[email protected]> Reviewed-by: Leif Lindholm <[email protected]>

SMBIOS Structure Types 0 through 127 (7Fh) are reserved for and defined by the SMBIOS specification. Types 128 through 256 (80h to FFh) are available for system and OEM-specific information. Therefore, define a new type 'SMBIOS_TABLE_TYPE' that represents a SMBIOS structure type and include it in the definition of CM_STD_OBJ_SMBIOS_TABLE_INFO. Acked-by: Abner Chang <[email protected]> Signed-off-by: Sami Mujawar <[email protected]> Cc: Alexei Fedorov <[email protected]> Cc: Pierre Gondois <[email protected]> Cc: Girish Mahadevan <[email protected]> Cc: Jeff Brasen <[email protected]> Cc: Ashish Singhal <[email protected]> Cc: Nick Ramirez <[email protected]> Cc: William Watson <[email protected]> Cc: Abner Chang <[email protected]> Cc: Samer El-Haj-Mahmoud <[email protected]> Cc: Jose Marinho <[email protected]>

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 <[email protected]> Cc: Alexei Fedorov <[email protected]> Cc: Pierre Gondois <[email protected]> Cc: Girish Mahadevan <[email protected]> Cc: Jeff Brasen <[email protected]> Cc: Ashish Singhal <[email protected]> Cc: Nick Ramirez <[email protected]> Cc: William Watson <[email protected]> Cc: Abner Chang <[email protected]> Cc: Samer El-Haj-Mahmoud <[email protected]> Cc: Jose Marinho <[email protected]>

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 <[email protected]> Cc: Alexei Fedorov <[email protected]> Cc: Pierre Gondois <[email protected]> Cc: Girish Mahadevan <[email protected]> Cc: Jeff Brasen <[email protected]> Cc: Ashish Singhal <[email protected]> Cc: Nick Ramirez <[email protected]> Cc: William Watson <[email protected]> Cc: Abner Chang <[email protected]> Cc: Samer El-Haj-Mahmoud <[email protected]> Cc: Jose Marinho <[email protected]>

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 <[email protected]> Cc: Alexei Fedorov <[email protected]> Cc: Pierre Gondois <[email protected]> Cc: Girish Mahadevan <[email protected]> Cc: Jeff Brasen <[email protected]> Cc: Ashish Singhal <[email protected]> Cc: Nick Ramirez <[email protected]> Cc: William Watson <[email protected]> Cc: Abner Chang <[email protected]> Cc: Samer El-Haj-Mahmoud <[email protected]> Cc: Jose Marinho <[email protected]>

Add a new definition for invalid or non-existent handle. Signed-off-by: Girish Mahadevan <[email protected]>

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 <[email protected]>

There are 2 changes in this commit: 1. Use ProtocolNotify Event for generating the SMBIOS and ACPI tables and don't include the ACPI or SMBIOS protocols 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 SMBIOS and ACPI table generators into their own files. Signed-off-by: Girish Mahadevan <[email protected]>

gmahadevan · 2025-04-14T21:00:21Z

@gmahadevan Thanks a lot for driving this effort and for this patch series. Other than the last 3 patches in the series i.e. the generators, I have reviewed the rest of the patches. I think it would be best to review the generators once we have concluded the discussion about the introduction of the new SMBIOS Object namespace. Please see my inputs as to why I think we should not introduce a new SMBIOS object namespace. If we need to distinguish SMBIOS specific objects, it would be best to add comments to the arch common objects.

Thanks for the review @samimujawar , please have a look at the latest push and let me know, I have dropped the generator patches and the patch for adding a new namespace.

Hello @samimujawar @pierregondois
I've pushed this PR again after rebasing to the latest on the dyanmictables-reorg branch. It is down to 3 commits. Let me know what you think. Thanks for merging your changes for the Dispatcher.
Thanks
Girish

sarah-walker-arm · 2025-04-15T09:17:54Z

Is there any specific reason why splitting the table generators is the final commit? It feels messy to add the SMBIOS generator then to immediately move it in the next commit. Moving the ACPI table generator out of DynamicTableManagerDxe.c as the first commit then adding the SMBIOS generator feels a neater approach.

sarah-walker-arm · 2025-04-15T09:20:03Z

DynamicTablesPkg/Drivers/DynamicTableFactoryDxe/SmbiosTableFactory/SmbiosTableFactory.c

+  @param [in]  GeneratorId    Smbios Table Generator Id.
+
+  @retval EFI_SUCCESS               Successfully added/generated the handle.
+  @retval EFI_OUT_OF_RESOURCESNULL  Failure to add/generate the handle.


Typo: "EFI_OUT_OF_RESOURCESNULL".

sarah-walker-arm · 2025-04-15T09:34:36Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+  @param [in]  CmObjectToken    The CM Object token used to generate the SMBIOS
+                                record.
+
+  @retval EFI_SUCCESS           Success.


Return value documentation is incorrect; this function is returning a pointer.

sarah-walker-arm · 2025-04-15T09:35:18Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+  @param [in]  CmObjectToken   Token of the CM_OBJECT used to build the SMBIOS Table.
+
+  @return  SMBIOS handle of the table associated with SmbiosTableId and
+           CmObjectToken if found. Otherwise, returns 0xFFFF.


Should be Otherwise, returns SMBIOS_HANDLE_INVALID.?

sarah-walker-arm · 2025-04-15T09:35:59Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+  @param [in]  CmObjectToken   Token of the CM_OBJECT used to build the SMBIOS Table.
+
+  @return  SMBIOS handle of the table associated with SmbiosTableId and
+           CmObjectToken if found. Otherwise, returns 0xFFFF.


Should be Otherwise, returns SMBIOS_HANDLE_INVALID.?

sarah-walker-arm · 2025-04-15T09:36:30Z

DynamicTablesPkg/Include/SmbiosTableGenerator.h

+  @param [in]  CmObjectToken    The CM Object token used to generate the SMBIOS
+                                record.
+
+  @retval EFI_SUCCESS           Success.


Return value documentation is incorrect; this function is returning a pointer.

samimujawar · 2025-04-15T11:38:05Z

@gmahadevan I will fixup the above feedback and merge the changes shortly.

samimujawar · 2025-04-16T15:34:05Z

@gmahadevan I have pushed the changes on the staging branch.

samimujawar · 2025-04-24T12:33:21Z

Coming this PR as the changes have been merged at https://github.com/tianocore/edk2-staging/commits/dynamictables-reorg/

sarah-walker-arm reviewed Feb 19, 2025

View reviewed changes

gmahadevan force-pushed the dynamictables-reorg-upto19 branch from 58f8eb2 to 777b9c1 Compare February 19, 2025 17:35

samimujawar reviewed Mar 7, 2025

View reviewed changes

gmahadevan force-pushed the dynamictables-reorg-upto19 branch from 777b9c1 to 0a568f5 Compare March 11, 2025 23:33

samimujawar requested a review from pierregondois April 3, 2025 12:21

samimujawar reviewed Apr 3, 2025

View reviewed changes

pierregondois reviewed Apr 4, 2025

View reviewed changes

samimujawar force-pushed the dynamictables-reorg branch from 0a6087a to e4140a5 Compare April 8, 2025 13:50

samimujawar mentioned this pull request Apr 8, 2025

2406 smbios dispatcher v3 #513

Merged

gmahadevan force-pushed the dynamictables-reorg-upto19 branch 3 times, most recently from f1cc78e to f862e52 Compare April 9, 2025 01:08

samimujawar and others added 8 commits April 9, 2025 16:35

MdePkg/SmBios.h: Add New definition for Invalid Handle

7762b0b

Add a new definition for invalid or non-existent handle. Signed-off-by: Girish Mahadevan <[email protected]>

gmahadevan force-pushed the dynamictables-reorg-upto19 branch from f862e52 to defe05e Compare April 9, 2025 20:46

sarah-walker-arm reviewed Apr 15, 2025

View reviewed changes

samimujawar force-pushed the dynamictables-reorg branch 2 times, most recently from 22c9da5 to 2d1c8e7 Compare April 16, 2025 15:30

samimujawar closed this Apr 24, 2025

Dynamictables: Add SMBIOS dispatcher and generators #510

Dynamictables: Add SMBIOS dispatcher and generators #510

Uh oh!

Conversation

gmahadevan commented Jan 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

samimujawar commented Mar 7, 2025

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gmahadevan Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gmahadevan commented Mar 12, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pierregondois left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

gmahadevan commented Jan 27, 2025 •

edited

Loading

gmahadevan Mar 11, 2025 •

edited

Loading

samimujawar Apr 8, 2025 •

edited

Loading