Type 40 entries (Additional information) are summarized in section
7.41 as part of the SMBIOS specification.  Save these entries when
decoding the DMI tables.

Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
---
v2:
 * Drop some unneeded variables (LKP robot)
 * Allow any length strings, not just 5 and longer
---
 drivers/firmware/dmi_scan.c | 38 +++++++++++++++++++++++++++++++++++++
 include/linux/dmi.h         |  7 +++++++
 2 files changed, 45 insertions(+)

diff --git a/drivers/firmware/dmi_scan.c b/drivers/firmware/dmi_scan.c
index 80aded4c778bc..ec84fe3935c1e 100644
--- a/drivers/firmware/dmi_scan.c
+++ b/drivers/firmware/dmi_scan.c
@@ -393,6 +393,40 @@ static void __init dmi_save_dev_pciaddr(int instance, int segment, int bus,
 	list_add(&dev->dev.list, &dmi_devices);
 }
 
+static void __init dmi_save_additional(const struct dmi_additional_info *info)
+{
+	const u8 *data;
+	int i;
+
+	if (!info || info->header.length < 5 + info->count * 5)
+		return;
+
+	data = info->entries;
+
+	for (i = 0; i < info->count; i++) {
+		u8 string_num = data[i * 5 + 4];
+		const char *string_ptr;
+		char *value;
+		int len;
+
+		string_ptr = dmi_string_nosave(&info->header, string_num);
+		if (!string_ptr || !*string_ptr)
+			continue;
+
+		len = strlen(string_ptr);
+		if (len == 0)
+			continue;
+
+		value = dmi_alloc(len + 1);
+		if (!value)
+			continue;
+
+		strscpy(value, string_ptr, len + 1);
+
+		dmi_save_one_device(DMI_DEV_TYPE_ADDITIONAL, value);
+	}
+}
+
 static void __init dmi_save_extended_devices(const struct dmi_header *dm)
 {
 	const char *name;
@@ -526,8 +560,12 @@ static void __init dmi_decode(const struct dmi_header *dm, void *dummy)
 	case DMI_ENTRY_IPMI_DEV:
 		dmi_save_ipmi_device(dm);
 		break;
+	case DMI_ENTRY_ADDITIONAL:
+		dmi_save_additional((const struct dmi_additional_info *)dm);
+		break;
 	case DMI_ENTRY_ONBOARD_DEV_EXT:
 		dmi_save_extended_devices(dm);
+		break;
 	}
 }
 
diff --git a/include/linux/dmi.h b/include/linux/dmi.h
index a809b5095c259..3fc3d334b321d 100644
--- a/include/linux/dmi.h
+++ b/include/linux/dmi.h
@@ -24,6 +24,7 @@ enum dmi_device_type {
 	DMI_DEV_TYPE_OEM_STRING = -2,
 	DMI_DEV_TYPE_DEV_ONBOARD = -3,
 	DMI_DEV_TYPE_DEV_SLOT = -4,
+	DMI_DEV_TYPE_ADDITIONAL = -5,
 };
 
 enum dmi_entry_type {
@@ -87,6 +88,12 @@ struct dmi_device {
 	void *device_data;	/* Type specific data */
 };
 
+struct dmi_additional_info {
+	struct dmi_header header;
+	u8 count;
+	u8 entries[];
+} __packed;
+
 #ifdef CONFIG_DMI
 
 struct dmi_dev_onboard {
-- 
2.43.0

On Tue, Dec 16, 2025 at 06:33:50AM -0600, Mario Limonciello (AMD) wrote:
> Type 40 entries (Additional information) are summarized in section
> 7.41 as part of the SMBIOS specification.  Save these entries when
> decoding the DMI tables.
> 

Why can't an interested user just use dmidecode?

Thanks,
Yazen

On 12/17/25 3:03 PM, Yazen Ghannam wrote:
> On Tue, Dec 16, 2025 at 06:33:50AM -0600, Mario Limonciello (AMD) wrote:
>> Type 40 entries (Additional information) are summarized in section
>> 7.41 as part of the SMBIOS specification.  Save these entries when
>> decoding the DMI tables.
>>
> 
> Why can't an interested user just use dmidecode?
> 
> Thanks,
> Yazen

They could.  The reason for doing it in this series is the same reason 
for the one that we did the S5 bit.

It shows up in the logs, you can tie regressions to the AGESA version at 
specifically at the time of the failure if they've done BIOS updates 
since then.

On Wed, Dec 17, 2025 at 03:09:33PM -0600, Mario Limonciello wrote:
> On 12/17/25 3:03 PM, Yazen Ghannam wrote:
> > On Tue, Dec 16, 2025 at 06:33:50AM -0600, Mario Limonciello (AMD) wrote:
> > > Type 40 entries (Additional information) are summarized in section
> > > 7.41 as part of the SMBIOS specification.  Save these entries when
> > > decoding the DMI tables.
> > > 
> > 
> > Why can't an interested user just use dmidecode?
> > 
> > Thanks,
> > Yazen
> 
> They could.  The reason for doing it in this series is the same reason for
> the one that we did the S5 bit.
> 
> It shows up in the logs, you can tie regressions to the AGESA version at
> specifically at the time of the failure if they've done BIOS updates since
> then.

Yes, right. Sorry, I mixed this up with the debugfs patch.

We need to save it here so the init code can find it.

But why do we need a debugfs entry for it?

Thanks,
Yazen

On 12/17/25 3:21 PM, Yazen Ghannam wrote:
> On Wed, Dec 17, 2025 at 03:09:33PM -0600, Mario Limonciello wrote:
>> On 12/17/25 3:03 PM, Yazen Ghannam wrote:
>>> On Tue, Dec 16, 2025 at 06:33:50AM -0600, Mario Limonciello (AMD) wrote:
>>>> Type 40 entries (Additional information) are summarized in section
>>>> 7.41 as part of the SMBIOS specification.  Save these entries when
>>>> decoding the DMI tables.
>>>>
>>>
>>> Why can't an interested user just use dmidecode?
>>>
>>> Thanks,
>>> Yazen
>>
>> They could.  The reason for doing it in this series is the same reason for
>> the one that we did the S5 bit.
>>
>> It shows up in the logs, you can tie regressions to the AGESA version at
>> specifically at the time of the failure if they've done BIOS updates since
>> then.
> 
> Yes, right. Sorry, I mixed this up with the debugfs patch.
> 
> We need to save it here so the init code can find it.
> 
> But why do we need a debugfs entry for it?

Ah.  That one I don't feel strongly about.

I used it when I was getting the series working and it felt like a waste 
to toss.

On Wed, Dec 17, 2025 at 03:23:10PM -0600, Mario Limonciello wrote:
> On 12/17/25 3:21 PM, Yazen Ghannam wrote:
> > On Wed, Dec 17, 2025 at 03:09:33PM -0600, Mario Limonciello wrote:
> > > On 12/17/25 3:03 PM, Yazen Ghannam wrote:
> > > > On Tue, Dec 16, 2025 at 06:33:50AM -0600, Mario Limonciello (AMD) wrote:
> > > > > Type 40 entries (Additional information) are summarized in section
> > > > > 7.41 as part of the SMBIOS specification.  Save these entries when
> > > > > decoding the DMI tables.
> > > > > 
> > > > 
> > > > Why can't an interested user just use dmidecode?
> > > > 
> > > > Thanks,
> > > > Yazen
> > > 
> > > They could.  The reason for doing it in this series is the same reason for
> > > the one that we did the S5 bit.
> > > 
> > > It shows up in the logs, you can tie regressions to the AGESA version at
> > > specifically at the time of the failure if they've done BIOS updates since
> > > then.
> > 
> > Yes, right. Sorry, I mixed this up with the debugfs patch.
> > 
> > We need to save it here so the init code can find it.
> > 
> > But why do we need a debugfs entry for it?
> 
> Ah.  That one I don't feel strongly about.
> 
> I used it when I was getting the series working and it felt like a waste to
> toss.

Oh okay. Yeah, maybe "don't feel strongly about it" is a good reason to
drop it. Just trying to think like a more frugal reviewer. :)

Thanks,
Yazen