arm64: dmi: Add SMBIOS/DMI support
PATCH RESEND 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.
---
Resending on behalf of Yi.
Please consider for 3.17.
Regards,
Ard.
arch/arm64/Kconfig | 10 ++++++++++ arch/arm64/include/asm/dmi.h | 28 ++++++++++++++++++++++++++++ arch/arm64/kernel/setup.c | 2 ++ 3 files changed, 40 insertions(+) create mode 100644 arch/arm64/include/asm/dmi.h
arch/arm64/Kconfig +10 -0
@@ -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 +28 -0
@@ -0,0 +1,28 @@ +/* +* arch/arm64/include/asm/dmi.h +* +* Copyright (C) 2013 Linaro Limited. +* Written by: Yi Li (yi.li at linaro.org) +* +* based on arch/ia64/include/asm/dmi.h +* +* This file is subject to the terms and conditions of the GNU General Public +* License. See the file "COPYING" in the main directory of this archive +* for more details. +*/ + + +#ifndef _ASM_DMI_H +#define _ASM_DMI_H 1 + +#include <linux/slab.h> +#include <linux/efi.h> + +/* Use efi mappings for DMI */ +#define dmi_early_remap (x, l) efi_lookup_mapped_addr(x) +#define dmi_early_unmap (x, l) +#define dmi_remap (x, l) efi_lookup_mapped_addr(x) +#define dmi_unmap (x) +#define dmi_alloc (l) kzalloc(l, GFP_ATOMIC) + +#endif
arch/arm64/kernel/setup.c +2 -0
@@ -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
PATCH RESEND 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 8 lines
Signed-off-by Yi Li <[email protected]>[ardb: whitespace, commit log tweaks]Signed-off-by Ard Biesheuvel <[email protected]>---
Resending on behalf of Yi.
Please consider for 3.17.
Ping?
Quoted 84 lines
arch/arm64/Kconfig | 10 ++++++++++ arch/arm64/include/asm/dmi.h | 28 ++++++++++++++++++++++++++++ arch/arm64/kernel/setup.c | 2 ++ 3 files changed, 40 insertions(+) create mode 100644 arch/arm64/include/asm/dmi.harch/arm64/Kconfig +10
-0@@ -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 +28
-0@@ -0,0 +1,28 @@ +/* +* arch/arm64/include/asm/dmi.h +* +* Copyright (C) 2013 Linaro Limited. +* Written by: Yi Li (yi.li at linaro.org) +* +* based on arch/ia64/include/asm/dmi.h +* +* This file is subject to the terms and conditions of the GNU General Public +* License. See the file "COPYING" in the main directory of this archive +* for more details. +*/ + + +#ifndef _ASM_DMI_H +#define _ASM_DMI_H 1 + +#include <linux/slab.h> +#include <linux/efi.h> + +/* Use efi mappings for DMI */ +#define dmi_early_remap (x, l) efi_lookup_mapped_addr(x) +#define dmi_early_unmap (x, l) +#define dmi_remap (x, l) efi_lookup_mapped_addr(x) +#define dmi_unmap (x) +#define dmi_alloc (l) kzalloc(l, GFP_ATOMIC) + +#endif arch/arm64/kernel/setup.c +2
-1@@ -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); --1.8.3.2
PATCH RESEND 1/1 arm64: dmi: Add SMBIOS/DMI support
Quoted 14 lines · Ard Biesheuvel
Quoted 13 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]>[ardb: whitespace, commit log tweaks]Signed-off-by Ard Biesheuvel <[email protected]>---
Quoted 5 lines
Quoted 3 lines
Resending on behalf of Yi.
Please consider for 3.17.Ping?
Not sure what this does, but I can review it on a superficial level :)
Quoted 14 lines
Quoted 14 lines
arch/arm64/include/asm/dmi.h new file +8
-0@@ -0,0 +1,28 @@ +/* +* arch/arm64/include/asm/dmi.h +* +* Copyright (C) 2013 Linaro Limited. +* Written by: Yi Li (yi.li at linaro.org) +* +* based on arch/ia64/include/asm/dmi.h +*
Quoted 8 lines
arch/arm64/include/asm/dmi.h line 16
Quoted 8 lines
arch/arm64/include/asm/dmi.h new file +8
-0+* This file is subject to the terms and conditions of the GNU General Public +* License. See the file "COPYING" in the main directory of this archive +* for more details. +*/ + + +#ifndef _ASM_DMI_H +#define _ASM_DMI_H 1
You don't need the 1 here (copied from ia64?). Also, please try to follow the existing style for arm64 and use __ASM_DMI_H.
Quoted 5 lines
arch/arm64/include/asm/dmi.h line 22
Quoted 5 lines
arch/arm64/include/asm/dmi.h new file +5
-0+#include <linux/slab.h> +#include <linux/efi.h> + +/* Use efi mappings for DMI */ +#define dmi_early_remap (x, l) efi_lookup_mapped_addr(x)
Throwing away the length doesn't feel right, especially since the efi map *does* have a size field.
Quoted 2 lines
arch/arm64/include/asm/dmi.h line 24
Quoted 2 lines
arch/arm64/include/asm/dmi.h new file +2
-0+#define dmi_early_unmap (x, l) +#define dmi_remap (x, l) efi_lookup_mapped_addr(x)
How do we guarantee that we don't call these after efi_free_boot_services? (it would be good to enforce that somehow).
Quoted 2 lines
arch/arm64/include/asm/dmi.h line 26
Quoted 2 lines
arch/arm64/include/asm/dmi.h new file +2
-0+#define dmi_unmap (x) +#define dmi_alloc (l) kzalloc(l, GFP_ATOMIC)
Why does this have to be atomic?
Will
PATCH RESEND 1/1 arm64: dmi: Add SMBIOS/DMI support
Quoted 15 lines · Will Deacon
Quoted 14 lines · Ard Biesheuvel
Quoted 13 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]>[ardb: whitespace, commit log tweaks]Signed-off-by Ard Biesheuvel <[email protected]>---
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Resending on behalf of Yi.
Please consider for 3.17.Ping?
Not sure what this does, but I can review it on a superficial level :)
Thanks.
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
arch/arm64/include/asm/dmi.h new file +11
-0@@ -0,0 +1,28 @@ +/* +* arch/arm64/include/asm/dmi.h +* +* Copyright (C) 2013 Linaro Limited. +* Written by: Yi Li (yi.li at linaro.org) +* +* based on arch/ia64/include/asm/dmi.h +* +* This file is subject to the terms and conditions of the GNU General Public +* License. See the file "COPYING" in the main directory of this archive +* for more details.
Quoted 9 lines
Quoted 5 lines
arch/arm64/include/asm/dmi.h line 16
Quoted 5 lines
arch/arm64/include/asm/dmi.h new file +5
-0+*/ + + +#ifndef _ASM_DMI_H +#define _ASM_DMI_H 1You don't need the 1 here (copied from ia64?). Also, please try to follow the existing style for arm64 and use
__ASM_DMI_H.
Yes, copy/paste from ia64. Will fix it up.
Quoted 9 lines
Quoted 5 lines
arch/arm64/include/asm/dmi.h line 22
Quoted 5 lines
arch/arm64/include/asm/dmi.h new file +5
-0+#include <linux/slab.h> +#include <linux/efi.h> + +/* Use efi mappings for DMI */ +#define dmi_early_remap (x, l) efi_lookup_mapped_addr(x)Throwing away the length doesn't feel right, especially since the efi map *does* have a size field.
The thing to realize here is that, instead of doing actual ioremap() or early_ioremap() calls, we just reuse an existing EFI mapping here. (On x86, DMI/SMBIOS and EFI are not as tightly coupled, whereas on arm64, the former implies the latter). So would you prefer some kind of test against the size of the mapping before doing that?
Quoted 6 lines
Quoted 2 lines
arch/arm64/include/asm/dmi.h line 24
Quoted 2 lines
arch/arm64/include/asm/dmi.h new file +2
-0+#define dmi_early_unmap (x, l) +#define dmi_remap (x, l) efi_lookup_mapped_addr(x)How do we guarantee that we don't call these after
efi_free_boot_services? (it would be good to enforce that somehow).
That is also an x86-ism, unfortunately. In our case, efi_lookup_mapped_addr() can be called at any time. The comment next to the definition of efi_lookup_mapped_addr() is in shared code, and should probably be updated to reflect this.
Quoted 5 lines
Quoted 2 lines
arch/arm64/include/asm/dmi.h line 26
Quoted 2 lines
arch/arm64/include/asm/dmi.h new file +2
-0+#define dmi_unmap (x) +#define dmi_alloc (l) kzalloc(l, GFP_ATOMIC)Why does this have to be atomic?
Also copy/paste from ia64. GFP_KERNEL should be fine here
Signature · 1 line
Ard.
PATCH RESEND 1/1 arm64: dmi: Add SMBIOS/DMI support
Quoted 12 lines · Ard Biesheuvel
Quoted 10 lines · Will Deacon
Quoted 5 lines · Ard Biesheuvel
arch/arm64/include/asm/dmi.h line 22
Quoted 5 lines
arch/arm64/include/asm/dmi.h new file +5
-0+#include <linux/slab.h> +#include <linux/efi.h> + +/* Use efi mappings for DMI */ +#define dmi_early_remap (x, l) efi_lookup_mapped_addr(x)Throwing away the length doesn't feel right, especially since the efi map *does* have a size field.
Quoted 5 lines
The thing to realize here is that, instead of doing actual
ioremap()orearly_ioremap()calls, we just reuse an existing EFI mapping here. (On x86, DMI/SMBIOS and EFI are not as tightly coupled, whereas on arm64, the former implies the latter). So would you prefer some kind of test against the size of the mapping before doing that?
Yeah, might not be a bad idea. Even if the thing happens to work by construction, we still have an API that takes a size, so checking it's what we have mapped sounds sensible.
Will
PATCH RESEND 1/1 arm64: dmi: Add SMBIOS/DMI support
Quoted 19 lines · Will Deacon
Quoted 12 lines · Ard Biesheuvel
Quoted 10 lines · Will Deacon
Quoted 5 lines · Ard Biesheuvel
arch/arm64/include/asm/dmi.h line 22
Quoted 5 lines
arch/arm64/include/asm/dmi.h new file +5
-0+#include <linux/slab.h> +#include <linux/efi.h> + +/* Use efi mappings for DMI */ +#define dmi_early_remap (x, l) efi_lookup_mapped_addr(x)Throwing away the length doesn't feel right, especially since the efi map *does* have a size field.
Quoted 5 lines
The thing to realize here is that, instead of doing actual
ioremap()orearly_ioremap()calls, we just reuse an existing EFI mapping here. (On x86, DMI/SMBIOS and EFI are not as tightly coupled, whereas on arm64, the former implies the latter). So would you prefer some kind of test against the size of the mapping before doing that?
Quoted 4 lines
Yeah, might not be a bad idea. Even if the thing happens to work by construction, we still have an API that takes a size, so checking it's what we have mapped sounds sensible.
So unless anyone objects, I am going to take a shortcut here and just check whether
efi_lookup_mapped_addr(phys) + len -1 == efi_lookup_mapped_addr(phys + len -1)
This doesn't check whether there are holes in the mapping, but anything more would imply creating a new function like efi_lookup_mapped_addr() that does take a size and iterates over all mappings in between.
Signature · 1 line
Ard.