On AMD Zen platforms that are running AGESA, there is sometimes
DMI additional string for the AGESA version that can be helpful when
debugging an issue. If this string is found output to kernel logs.
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
---
arch/x86/kernel/cpu/amd.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index c19c4ee74dd1f..8f44439d3f993 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -1,6 +1,7 @@
// SPDX-License-Identifier: GPL-2.0-only
#define pr_fmt(fmt) "x86/amd: " fmt
+#include <linux/dmi.h>
#include <linux/export.h>
#include <linux/bitops.h>
#include <linux/elf.h>
@@ -1406,3 +1407,20 @@ static __init int print_s5_reset_status_mmio(void)
return 0;
}
late_initcall(print_s5_reset_status_mmio);
+
+#ifdef CONFIG_DMI
+static __init int print_agesa_dmi_info(void)
+{
+ const struct dmi_device *dev = NULL;
+
+ while ((dev = dmi_find_device(DMI_DEV_TYPE_ADDITIONAL, NULL, dev))) {
+ if (!strncmp(dev->name, "AGESA", 5)) {
+ pr_info("%s\n", dev->name);
+ break;
+ }
+ }
+
+ return 0;
+}
+late_initcall(print_agesa_dmi_info);
+#endif
--
2.43.0
Hi Mario,
On Tue, 16 Dec 2025 06:33:54 -0600, Mario Limonciello (AMD) wrote:
> On AMD Zen platforms that are running AGESA, there is sometimes
> DMI additional string for the AGESA version that can be helpful when
> debugging an issue. If this string is found output to kernel logs.
This last sentence sounds clumsy.
>
> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> arch/x86/kernel/cpu/amd.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index c19c4ee74dd1f..8f44439d3f993 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> #define pr_fmt(fmt) "x86/amd: " fmt
>
> +#include <linux/dmi.h>
> #include <linux/export.h>
> #include <linux/bitops.h>
> #include <linux/elf.h>
> @@ -1406,3 +1407,20 @@ static __init int print_s5_reset_status_mmio(void)
> return 0;
> }
> late_initcall(print_s5_reset_status_mmio);
> +
> +#ifdef CONFIG_DMI
> +static __init int print_agesa_dmi_info(void)
> +{
> + const struct dmi_device *dev = NULL;
> +
> + while ((dev = dmi_find_device(DMI_DEV_TYPE_ADDITIONAL, NULL, dev))) {
> + if (!strncmp(dev->name, "AGESA", 5)) {
> + pr_info("%s\n", dev->name);
> + break;
> + }
> + }
In theory, type 40 DMI records are supposed to be a temporary
workaround until a new definition makes its way to the SMBIOS
specification. There is supposed to be a field in a standard DMI record
which will hold the same information in the future, at which point
systems will no longer need to provide the additional information entry.
I'm therefore surprised that you look for the AGESA information only in
type 40 and not in the standard DMI type where this piece of
information is supposed to be added in a near future.
So I checked my collection of DMI table dumps to find examples. I found
a number of occurrences of such type 40 entries. And it's a mess, I'm
sorry to say.
Some properly reference the Firmware Information handle (0x000) but
others reference handle 0xFFFF instead (which is invalid). Some
reference offset 0x05 within that record (which corresponds to the
Firmware Version string) while others reference offset 0x00 (which is
invalid). All have a 4-byte data field at the end of the entry, with
value 0x00000000, which is needlessly large.
This really looks like an abuse of DMI type 40. These entries are
supposed to overlay enumerated values in other types. This applies to
numeric fields only, overlaying a string field with another string
field is a technical non-sense.
Not sure what AMD engineers had in mind when implementing this. If they
wanted to mention the AGESA version in the firmware string, they could
have done that in DMI type 0, firmware version string directly.
Alternatively, OEM-specific records can be implemented, where hardware
vendors can store any kind of information they like. OEM strings (type
11) would also have been a valid alternative. Using DMI type 40 was
clearly not the right way to do it.
> +
> + return 0;
> +}
> +late_initcall(print_agesa_dmi_info);
> +#endif
--
Jean Delvare
SUSE L3 Support
On Tue, Dec 16, 2025 at 06:33:54AM -0600, Mario Limonciello (AMD) wrote:
> On AMD Zen platforms that are running AGESA, there is sometimes
> DMI additional string for the AGESA version that can be helpful when
> debugging an issue. If this string is found output to kernel logs.
>
> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> ---
> arch/x86/kernel/cpu/amd.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index c19c4ee74dd1f..8f44439d3f993 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -1,6 +1,7 @@
> // SPDX-License-Identifier: GPL-2.0-only
> #define pr_fmt(fmt) "x86/amd: " fmt
>
> +#include <linux/dmi.h>
> #include <linux/export.h>
> #include <linux/bitops.h>
> #include <linux/elf.h>
> @@ -1406,3 +1407,20 @@ static __init int print_s5_reset_status_mmio(void)
> return 0;
> }
> late_initcall(print_s5_reset_status_mmio);
> +
> +#ifdef CONFIG_DMI
> +static __init int print_agesa_dmi_info(void)
> +{
> + const struct dmi_device *dev = NULL;
> +
> + while ((dev = dmi_find_device(DMI_DEV_TYPE_ADDITIONAL, NULL, dev))) {
> + if (!strncmp(dev->name, "AGESA", 5)) {
> + pr_info("%s\n", dev->name);
> + break;
> + }
> + }
> +
> + return 0;
> +}
> +late_initcall(print_agesa_dmi_info);
> +#endif
>
The Zen check is gone. Is that intentional?
If so, then I think the commit message should be tweaked to not mention
Zen systems specifically.
I don't think this is a problem. I think it's better to keep things
generic, if possible.
Thanks,
Yazen
On 12/17/25 3:18 PM, Yazen Ghannam wrote:
> On Tue, Dec 16, 2025 at 06:33:54AM -0600, Mario Limonciello (AMD) wrote:
>> On AMD Zen platforms that are running AGESA, there is sometimes
>> DMI additional string for the AGESA version that can be helpful when
>> debugging an issue. If this string is found output to kernel logs.
>>
>> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
>> ---
>> arch/x86/kernel/cpu/amd.c | 18 ++++++++++++++++++
>> 1 file changed, 18 insertions(+)
>>
>> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
>> index c19c4ee74dd1f..8f44439d3f993 100644
>> --- a/arch/x86/kernel/cpu/amd.c
>> +++ b/arch/x86/kernel/cpu/amd.c
>> @@ -1,6 +1,7 @@
>> // SPDX-License-Identifier: GPL-2.0-only
>> #define pr_fmt(fmt) "x86/amd: " fmt
>>
>> +#include <linux/dmi.h>
>> #include <linux/export.h>
>> #include <linux/bitops.h>
>> #include <linux/elf.h>
>> @@ -1406,3 +1407,20 @@ static __init int print_s5_reset_status_mmio(void)
>> return 0;
>> }
>> late_initcall(print_s5_reset_status_mmio);
>> +
>> +#ifdef CONFIG_DMI
>> +static __init int print_agesa_dmi_info(void)
>> +{
>> + const struct dmi_device *dev = NULL;
>> +
>> + while ((dev = dmi_find_device(DMI_DEV_TYPE_ADDITIONAL, NULL, dev))) {
>> + if (!strncmp(dev->name, "AGESA", 5)) {
>> + pr_info("%s\n", dev->name);
>> + break;
>> + }
>> + }
>> +
>> + return 0;
>> +}
>> +late_initcall(print_agesa_dmi_info);
>> +#endif
>>
>
> The Zen check is gone. Is that intentional?
>
No it's not, it's a good catch. We don't have an AGESA version in
SMBIOS data on pre-zen hardware.
I'll add in a check like we do for print_s5_reset_status_mmio() for the
next spin.
if (!cpu_feature_enabled(X86_FEATURE_ZEN))
return 0;
> If so, then I think the commit message should be tweaked to not mention
> Zen systems specifically.
>
> I don't think this is a problem. I think it's better to keep things
> generic, if possible.
>
> Thanks,
> Yazen
On Wed, Dec 17, 2025 at 03:21:17PM -0600, Mario Limonciello wrote:
> On 12/17/25 3:18 PM, Yazen Ghannam wrote:
> > On Tue, Dec 16, 2025 at 06:33:54AM -0600, Mario Limonciello (AMD) wrote:
> > > On AMD Zen platforms that are running AGESA, there is sometimes
> > > DMI additional string for the AGESA version that can be helpful when
> > > debugging an issue. If this string is found output to kernel logs.
> > >
> > > Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> > > ---
> > > arch/x86/kernel/cpu/amd.c | 18 ++++++++++++++++++
> > > 1 file changed, 18 insertions(+)
> > >
> > > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > > index c19c4ee74dd1f..8f44439d3f993 100644
> > > --- a/arch/x86/kernel/cpu/amd.c
> > > +++ b/arch/x86/kernel/cpu/amd.c
> > > @@ -1,6 +1,7 @@
> > > // SPDX-License-Identifier: GPL-2.0-only
> > > #define pr_fmt(fmt) "x86/amd: " fmt
> > > +#include <linux/dmi.h>
> > > #include <linux/export.h>
> > > #include <linux/bitops.h>
> > > #include <linux/elf.h>
> > > @@ -1406,3 +1407,20 @@ static __init int print_s5_reset_status_mmio(void)
> > > return 0;
> > > }
> > > late_initcall(print_s5_reset_status_mmio);
> > > +
> > > +#ifdef CONFIG_DMI
> > > +static __init int print_agesa_dmi_info(void)
> > > +{
> > > + const struct dmi_device *dev = NULL;
> > > +
> > > + while ((dev = dmi_find_device(DMI_DEV_TYPE_ADDITIONAL, NULL, dev))) {
> > > + if (!strncmp(dev->name, "AGESA", 5)) {
> > > + pr_info("%s\n", dev->name);
> > > + break;
> > > + }
> > > + }
> > > +
> > > + return 0;
> > > +}
> > > +late_initcall(print_agesa_dmi_info);
> > > +#endif
> > >
> >
> > The Zen check is gone. Is that intentional?
> >
>
> No it's not, it's a good catch. We don't have an AGESA version in SMBIOS
> data on pre-zen hardware.
>
> I'll add in a check like we do for print_s5_reset_status_mmio() for the next
> spin.
>
> if (!cpu_feature_enabled(X86_FEATURE_ZEN))
> return 0;
>
In that case, please consider a wrapper function that checks for Zen and
calls the two functions: AGESA and S5_RESET_STATUS.
Thanks,
Yazen
© 2016 - 2026 Red Hat, Inc.