linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 08/10] arm64: dmi: Add SMBIOS/DMI support
Date: Tue, 28 Oct 2014 17:18:41 +0100	[thread overview]
Message-ID: <1414513123-20400-9-git-send-email-ard.biesheuvel@linaro.org> (raw)
In-Reply-To: <1414513123-20400-1-git-send-email-ard.biesheuvel@linaro.org>

From: Yi Li <yi.li@linaro.org>

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.

Signed-off-by: Yi Li <yi.li@linaro.org>
Tested-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
A short history of this patch:

v4: Moved call to dmi_scan_machine() to separate core_initcall(), so that it is
    called unconditionally, i.e., even if UEFI fails to initialize. Otherwise,
    any drivers that attempt to consult DMI info for quirks handling start
    spewing errors, as Catalin unfortunately found out after merging (and
    subsequently reverting) this patch for the second time.

v3: Moved call to dmi_scan_machine() into arm64_enter_virtual_mode(). This is
    necessary, because dmi_scan_machine() needs to be called before
    dmi_id_init(), which itself is invoked using an arch_initcall(). DMI depends
    on UEFI on arm64, so it is legal to only invoke dmi_scan_machine() when
    building with UEFI support. However, calling it from
    arm64_enter_virtual_mode() was a mistake, as it could result in
    dmi_scan_machine() not being called at all.

v2: Use efi_lookup_mapped_addr() to obtain the virtual address of the SMBIOS
    structure table instead of calling ioremap_cache(). This seemed a good idea
    at the time, as the UEFI memory map covers those regions, so the virtual
    mapping should be known as well. However, this is only true if the firmware
    has requested a virtual remapping of the region by setting the
    EFI_MEMORY_RUNTIME bit, which Tianocore/EDK2 appears to do, but violates
    the UEFI spec. ("In general, UEFI Configuration Tables loaded at boot time
    (e.g., SMBIOS table) can be contained in memory of type
    EfiRuntimeServicesData (recommended and the system firmware must not request
    a virtual mapping), [...]", section 2.3.6, UEFI spec v2.4B). This version
    was merged into the arm64 for-next/core branch and reverted again per our
    request.
---
 arch/arm64/Kconfig           | 11 +++++++++++
 arch/arm64/include/asm/dmi.h | 31 +++++++++++++++++++++++++++++++
 arch/arm64/kernel/efi.c      | 13 +++++++++++++
 3 files changed, 55 insertions(+)
 create mode 100644 arch/arm64/include/asm/dmi.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d5857e..2c3c2ca6f8bc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -401,6 +401,17 @@ 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"
diff --git a/arch/arm64/include/asm/dmi.h b/arch/arm64/include/asm/dmi.h
new file mode 100644
index 000000000000..69d37d87b159
--- /dev/null
+++ b/arch/arm64/include/asm/dmi.h
@@ -0,0 +1,31 @@
+/*
+ * 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
+
+#include <linux/io.h>
+#include <linux/slab.h>
+
+/*
+ * According to section 2.3.6 of the UEFI spec, the firmware should not
+ * request a virtual mapping for configuration tables such as SMBIOS.
+ * This means we have to map them before use.
+ */
+#define dmi_early_remap(x, l)		ioremap_cache(x, l)
+#define dmi_early_unmap(x, l)		iounmap(x)
+#define dmi_remap(x, l)			ioremap_cache(x, l)
+#define dmi_unmap(x)			iounmap(x)
+#define dmi_alloc(l)			kzalloc(l, GFP_KERNEL)
+
+#endif
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index 558572ef1ea3..9ae5e7918b8f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -11,6 +11,7 @@
  *
  */
 
+#include <linux/dmi.h>
 #include <linux/efi.h>
 #include <linux/export.h>
 #include <linux/memblock.h>
@@ -469,3 +470,15 @@ err_unmap:
 	return -1;
 }
 early_initcall(arm64_enter_virtual_mode);
+
+static int __init arm64_dmi_init(void)
+{
+	/*
+	 * On arm64, DMI depends on UEFI, and dmi_scan_machine() needs to
+	 * be called early because dmi_id_init(), which is an arch_initcall
+	 * itself, depends on dmi_scan_machine() having been called already.
+	 */
+	dmi_scan_machine();
+	return 0;
+}
+core_initcall(arm64_dmi_init);
-- 
1.8.3.2

  parent reply	other threads:[~2014-10-28 16:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-28 16:18 [PATCH v2 00/10] arm64 EFI patches for 3.19 Ard Biesheuvel
2014-10-28 16:18 ` [PATCH v2 01/10] arm64/efi: efistub: jump to 'stext' directly, not through the header Ard Biesheuvel
2014-10-28 16:18 ` [PATCH v2 02/10] arm64/efi: set PE/COFF section alignment to 4 KB Ard Biesheuvel
2014-10-28 16:18 ` [PATCH v2 03/10] arm64/efi: set PE/COFF file alignment to 512 bytes Ard Biesheuvel
2014-10-28 16:18 ` [PATCH v2 04/10] arm64/efi: invert UEFI memory region reservation logic Ard Biesheuvel
2014-10-28 16:47   ` Mark Rutland
2014-10-28 17:08     ` Ard Biesheuvel
2014-10-28 17:28       ` Mark Rutland
2014-10-30  0:28   ` Roy Franz
2014-10-28 16:18 ` [PATCH v2 05/10] arm64/efi: drop redundant set_bit(EFI_CONFIG_TABLES) Ard Biesheuvel
2014-10-28 16:18 ` [PATCH v2 06/10] efi: dmi: add support for SMBIOS 3.0 UEFI configuration table Ard Biesheuvel
2014-11-04 17:20   ` Matt Fleming
2014-10-28 16:18 ` [PATCH v2 07/10] dmi: add support for SMBIOS 3.0 64-bit entry point Ard Biesheuvel
2014-10-29 15:11   ` [PATCH v2] " Ard Biesheuvel
2014-10-29 16:19     ` Leif Lindholm
2014-11-04 17:39   ` [PATCH v2 07/10] " Matt Fleming
2014-10-28 16:18 ` Ard Biesheuvel [this message]
2014-10-29 16:23   ` [PATCH v2 08/10] arm64: dmi: Add SMBIOS/DMI support Leif Lindholm
2014-10-28 16:18 ` [PATCH v2 09/10] arm64: dmi: set DMI string as dump stack arch description Ard Biesheuvel
2014-10-29 14:58   ` Leif Lindholm
2014-10-28 16:18 ` [PATCH v2 10/10] efi: efi-stub: notify on DTB absence Ard Biesheuvel
2014-11-04 17:42   ` Matt Fleming
2014-11-05  7:53 ` [PATCH v2 00/10] arm64 EFI patches for 3.19 Ard Biesheuvel
2014-11-05  9:52   ` Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1414513123-20400-9-git-send-email-ard.biesheuvel@linaro.org \
    --to=ard.biesheuvel@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).