> On Apr 7, 2026, at 02:47, Jean Delvare <[email protected]> wrote: > > Hi Matthew, > > On Wed, 2026-04-01 at 14:50 -0700, Matthew R. Ochs via dmidecode-devel wrote: >> Include EDSFF slots when displaying slot information. >> >> Signed-off-by: Matthew R. Ochs <[email protected]> >> --- >> dmidecode.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/dmidecode.c b/dmidecode.c >> index 463f12b2748c..cd33ec5458cd 100644 >> --- a/dmidecode.c >> +++ b/dmidecode.c >> @@ -2423,6 +2423,8 @@ static void dmi_slot_information(u8 type, u8 code) >> case 0xC2: /* PCI Express 5 */ >> case 0xC3: /* PCI Express 5 */ >> case 0xC4: /* PCI Express 6+ */ >> + case 0xC5: /* EDSFF E1 */ >> + case 0xC6: /* EDSFF E3 */ >> if (code) >> pr_attr("PCI Express Generation", "%u", code); >> break; > > Thanks for the patch. I originally did not add EDSFF to > dmi_slot_information() because the SMBIOS specification only mentions > PCI Express for that field. It seems a bit strange to report a "PCI > Express Generation" for a non-PCIe slot. And I do not have any example > in my large collection of DMI table dumps where this field is set for > EDSFF slots. > > What led you to believe that this field is relevant to EDSFF slots?
Hi Jean, On NVIDIA Vera Rubin systems I’m seeing the Slot Information field populated for E1.S (EDSFF E1) slots, and since EDSFF is a PCIe-based form factor it seems reasonable to decode and display this as the PCI Express generation when the firmware provides a non-zero value. The SMBIOS 3.9 section 7.10.10 “System Slots — Slot Information” also feels a bit vague here with respect to newer form factors like EDSFF, so I erred on the side of exposing what firmware actually provides. That’s what led me to extend dmi_slot_information() to cover C5/C6 in the same way as other PCIe slot types. -matt
