arm64: dmi: Add SMBIOS/DMI support

PATCH RESEND Superseded Ard Biesheuvel 4 participants 9 messages Jul 11, 2014 – Jul 22, 2014 arm64

lore

Share & tools

lore

Ard Biesheuvel

author

2014-07-11 11:46 UTC #0 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

From: Yi Li <[email protected]>

SMbios is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like.

This has been tested by dmidecode and lshw tools.

Signed-off-by Yi Li <[email protected]>

Signed-off-by Ard Biesheuvel <[email protected]>

---
Changes since previous version:
- changed double inclusion guard to arm64 flavour
- use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
- do a sanity check on the size of the requested mapping

 arch/arm64/Kconfig           | 10 ++++++++++
 arch/arm64/include/asm/dmi.h | 41 +++++++++++++++++++++++++++++++++++++++++
 arch/arm64/kernel/setup.c    |  2 ++
 3 files changed, 53 insertions(+)
 create mode 100644 arch/arm64/include/asm/dmi.h

arch/arm64/Kconfig +10 -0

index a474de346be6..560996c4a172 100644
@@ -307,6 +307,16 @@ config EFI
 	  allow the kernel to be booted as an EFI application. This
 	  is only useful on systems that have UEFI firmware.
 
+config DMI
+	bool "Enable support for SMBIOS (DMI) tables"
+	depends on EFI
+	default y
+	help
+	  This enables SMBIOS/DMI feature for systems.
+
+	  This option is only useful on systems that have UEFI firmware.
+	  However, even with this option, the resultant kernel should
+	  continue to boot on existing non-UEFI platforms.
 endmenu
 
 menu "Userspace binary formats"

arch/arm64/include/asm/dmi.h new file +41 -0

41 lines not on this page · raw message

arch/arm64/kernel/setup.c +2 -0

index 46d1125571f6..4075e46282b1 100644
@@ -43,6 +43,7 @@
 #include <linux/of_fdt.h>
 #include <linux/of_platform.h>
 #include <linux/efi.h>
+#include <linux/dmi.h>
 
 #include <asm/fixmap.h>
 #include <asm/cputype.h>

@@ -413,6 +414,7 @@ void __init setup_arch(char **cmdline_p)
 static int __init arm64_device_init(void)
 {
 	of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
+	dmi_scan_machine();
 	return 0;
 }
 arch_initcall_sync(arm64_device_init);

Signature · 1 line

1.8.3.2

Will Deacon

2014-07-14 13:36 UTC #1 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

Quoted 8 lines · Ard Biesheuvel

From: Yi Li <[email protected]>
SMbios is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like.
This has been tested by dmidecode and lshw tools.

Quoted 7 lines

Signed-off-by Yi Li <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
---
Changes since previous version:
- changed double inclusion guard to arm64 flavour
- use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
- do a sanity check on the size of the requested mapping

Technically, this patch looks fine to me:

Reviewed-by Will Deacon <[email protected]>

It would be good if somebody with a relevant platform could confirm that it works/is useful though.

Will

Ard Biesheuvel

author

2014-07-14 13:57 UTC #2 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

Quoted 17 lines · Will Deacon

Quoted 8 lines · Ard Biesheuvel
From: Yi Li <[email protected]>
SMbios is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like.
This has been tested by dmidecode and lshw tools.
Quoted 7 lines
Signed-off-by Yi Li <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
---
Changes since previous version:
- changed double inclusion guard to arm64 flavour
- use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
- do a sanity check on the size of the requested mapping

Quoted 4 lines

Technically, this patch looks fine to me:
Reviewed-by Will Deacon <[email protected]>

Thanks.

Quoted 3 lines

It would be good if somebody with a relevant platform could confirm that it works/is useful though.

The usefulness has been debated here a couple of times before:
Grant's take on it is here
http://marc.info/?l=linux-arm-kernel&m=140206407411522&w=2

As to whether it works: I have asked Yi to retest this version of the patch with lshw and dmidecode
@Yi: could you please share your findings here?

Signature · 1 line

Ard.

Ard Biesheuvel

author

2014-07-20 10:25 UTC #3 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

Quoted 18 lines · Ard Biesheuvel

Quoted 17 lines · Will Deacon
Quoted 15 lines · Ard Biesheuvel
From: Yi Li <[email protected]>
SMbios is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like.
This has been tested by dmidecode and lshw tools.
Signed-off-by Yi Li <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
---
Changes since previous version:
- changed double inclusion guard to arm64 flavour
- use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
- do a sanity check on the size of the requested mapping

Quoted 4 lines

Quoted 4 lines
Technically, this patch looks fine to me:
Reviewed-by Will Deacon <[email protected]>

Hello Catalin,

This has been tested by Yi on FVP and Juno.
Are you ok to take this?

Signature · 1 line

Ard.

Quoted 15 lines

Thanks.
Quoted 3 lines
It would be good if somebody with a relevant platform could confirm that it works/is useful though.
The usefulness has been debated here a couple of times before:
Grant's take on it is here
http://marc.info/?l=linux-arm-kernel&m=140206407411522&w=2
As to whether it works: I have asked Yi to retest this version of the patch with lshw and dmidecode
@Yi: could you please share your findings here?

Will Deacon

2014-07-21 08:48 UTC #4 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

Quoted 21 lines · Ard Biesheuvel

Quoted 20 lines · Ard Biesheuvel
Quoted 19 lines · Will Deacon
Quoted 8 lines · Ard Biesheuvel
From: Yi Li <[email protected]>
SMbios is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like.
This has been tested by dmidecode and lshw tools.
Quoted 7 lines
Signed-off-by Yi Li <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
---
Changes since previous version:
- changed double inclusion guard to arm64 flavour
- use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
- do a sanity check on the size of the requested mapping
Technically, this patch looks fine to me:

Quoted 7 lines

Quoted 2 lines
Quoted 2 lines
Reviewed-by Will Deacon <[email protected]>
Hello Catalin,
This has been tested by Yi on FVP and Juno.
Are you ok to take this?

Out of interest, how did you test it on Juno? I tried but got some messages about missing/invalid DMI data or something similar. Leif reckons I need some tricked out firmware for the FVP to get something working, but even then the information is apparently bogus.

Will

liyi 00215672

2014-07-22 01:16 UTC #5 lore raw

Hi Will,

You need to add the SMBIOS support in UEFI on JUNO ,then you will get some proper information from DMI driver.

Thanks!

-----????-----
???: Will Deacon [mailto:will.deacon at arm.com]
????: 2014?7?21? 16:48
???: Ard Biesheuvel
??: Catalin Marinas; yi.li at linaro.org; liyi 00215672; grant.likely at linaro.org; leif.lindholm at linaro.org; linux-arm-kernel at lists.infradead.org; Mark Rutland ??: Re: [PATCH resend v2] arm64: dmi: Add SMBIOS/DMI support

Quoted 21 lines · Ard Biesheuvel

Quoted 20 lines · Ard Biesheuvel
Quoted 19 lines · Will Deacon
Quoted 8 lines · Ard Biesheuvel
From: Yi Li <[email protected]>
SMbios is important for server hardware vendors. It implements a spec for providing descriptive information about the platform. Things like serial numbers, physical layout of the ports, build configuration data, and the like.
This has been tested by dmidecode and lshw tools.
Quoted 7 lines
Signed-off-by Yi Li <[email protected]>
Signed-off-by Ard Biesheuvel <[email protected]>
---
Changes since previous version:
- changed double inclusion guard to arm64 flavour
- use kzalloc(GFP_KERNEL) as GFP_ATOMIC is not needed
- do a sanity check on the size of the requested mapping
Technically, this patch looks fine to me:

Quoted 7 lines

Quoted 2 lines
Quoted 2 lines
Reviewed-by Will Deacon <[email protected]>
Hello Catalin,
This has been tested by Yi on FVP and Juno.
Are you ok to take this?

Will

Catalin Marinas

maintainer

2014-07-21 10:03 UTC #6 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

In reply to Ard Biesheuvel

Ard,

I have some technical questions below before merging this patch.

Quoted 3 lines · Ard Biesheuvel

arch/arm64/include/asm/dmi.h new file +0 -0
@@ -0,0 +1,41 @@

[...]

arch/arm64/include/asm/dmi.h line 22

Quoted 3 lines

arch/arm64/include/asm/dmi.h new file +3 -0

+static inline void __iomem *dmi_remap(u64 phys, u64 size)
+{
+	void __iomem *p = efi_lookup_mapped_addr(phys);

When are dmi_remap/dmi_early_remap() called? A quick grep through the kernel shows that it is at least called once from dmi_scan_machine(). The latter is a device_initcall() in this patch. However, the comments for efi_lookup_mapped_addr() state that it should only be called between efi_enter_virtual_mode and efi_free_boot_services. The latter is invoked from an early_initcall(). Could you please clarify which part is wrong here?

Quoted 7 lines

arch/arm64/include/asm/dmi.h new file +7 -0

+
+	/*
+	 * If the mapping spans multiple pages, do a minimal check to ensure
+	 * that the mapping returned by efi_lookup_mapped_addr() covers the
+	 * whole requested range (but ignore potential holes)
+	 */
+	if ((phys & ~PAGE_MASK) + size > PAGE_SIZE

arch/arm64/include/asm/dmi.h line 39

Quoted 10 lines

arch/arm64/include/asm/dmi.h new file +10 -0

+	    && (p + size - 1) != efi_lookup_mapped_addr(phys + size - 1))
+		return NULL;
+	return p;
+}
+
+/* Reuse existing UEFI mappings for DMI */
+#define dmi_alloc(l)			kzalloc(l, GFP_KERNEL)
+#define dmi_early_remap(x, l)		dmi_remap(x, l)
+#define dmi_early_unmap(x, l)
+#define dmi_unmap(x)

Same questions as above, when are these functions called? Can we not just use early_ioremap/ioremap like x86?

Signature · 1 line

Catalin

Ard Biesheuvel

author

2014-07-21 10:18 UTC #7 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

Quoted 9 lines · Catalin Marinas

Ard,
I have some technical questions below before merging this patch.
Quoted 3 lines · Ard Biesheuvel
arch/arm64/include/asm/dmi.h new file +0 -0
@@ -0,0 +1,41 @@
[...]

Quoted 12 lines

arch/arm64/include/asm/dmi.h line 22
Quoted 3 lines
arch/arm64/include/asm/dmi.h new file +3 -0
+static inline void __iomem *dmi_remap(u64 phys, u64 size)
+{
+     void __iomem *p = efi_lookup_mapped_addr(phys);
When are dmi_remap/dmi_early_remap() called? A quick grep through the kernel shows that it is at least called once from dmi_scan_machine(). The latter is a device_initcall() in this patch. However, the comments for efi_lookup_mapped_addr() state that it should only be called between efi_enter_virtual_mode and efi_free_boot_services. The latter is invoked from an early_initcall(). Could you please clarify which part is wrong here?

The comment about efi_lookup_mapped_addr() is wrong. Those mappings are always available.
As the comment is in shared code, I will propose a patch to Matt Fleming to clarify it.

Quoted 12 lines

arch/arm64/include/asm/dmi.h new file +12 -0

+
+     /*
+      * If the mapping spans multiple pages, do a minimal check to ensure
+      * that the mapping returned by efi_lookup_mapped_addr() covers the
+      * whole requested range (but ignore potential holes)
+      */
+     if ((phys & ~PAGE_MASK) + size > PAGE_SIZE
+         && (p + size - 1) != efi_lookup_mapped_addr(phys + size - 1))
+             return NULL;
+     return p;
+}
+

Quoted 9 lines

arch/arm64/include/asm/dmi.h line 39
Quoted 5 lines
arch/arm64/include/asm/dmi.h new file +5 -0
+/* Reuse existing UEFI mappings for DMI */
+#define dmi_alloc(l)                 kzalloc(l, GFP_KERNEL)
+#define dmi_early_remap(x, l)                dmi_remap(x, l)
+#define dmi_early_unmap(x, l)
+#define dmi_unmap(x)
Same questions as above, when are these functions called? Can we not just use early_ioremap/ioremap like x86?

x86 uses DMI for quirks handling, so there the call to dmi_scan_machine() needs to occur very early, hence the early versions of map/unmap.
In our case, DMI/SMBIOS is UEFI only and not executed early, so we can just reuse the mappings that have already been set up for UEFI by arm64_enter_virtual_mode().

Signature · 1 line

Ard.

Catalin Marinas

maintainer

2014-07-21 10:38 UTC #8 lore raw

PATCH RESEND v2 1/1 arm64: dmi: Add SMBIOS/DMI support

Quoted 18 lines · Ard Biesheuvel

Quoted 5 lines · Catalin Marinas
Quoted 3 lines · Ard Biesheuvel
arch/arm64/include/asm/dmi.h new file +0 -0
@@ -0,0 +1,41 @@
[...]
Quoted 11 lines
arch/arm64/include/asm/dmi.h line 22
Quoted 3 lines
arch/arm64/include/asm/dmi.h new file +3 -0
+static inline void __iomem *dmi_remap(u64 phys, u64 size)
+{
+     void __iomem *p = efi_lookup_mapped_addr(phys);
When are dmi_remap/dmi_early_remap() called? A quick grep through the kernel shows that it is at least called once from dmi_scan_machine(). The latter is a device_initcall() in this patch. However, the comments for efi_lookup_mapped_addr() state that it should only be called between efi_enter_virtual_mode and efi_free_boot_services. The latter is invoked from an early_initcall(). Could you please clarify which part is wrong here?

Quoted 4 lines

The comment about efi_lookup_mapped_addr() is wrong. Those mappings are always available.
As the comment is in shared code, I will propose a patch to Matt Fleming to clarify it.

Thanks for the clarification. I'll merge this patch as is.

Signature · 1 line

Catalin