On Tue, Mar 10, 2015 at 04:01:16PM +0800, Hanjun Guo wrote:
index 0000000..f052e7a
--- /dev/null
+++ b/arch/arm64/kernel/acpi.c
@@ -0,0 +1,101 @@
+/*
+ * ARM64 Specific Low-Level ACPI Boot Support
+ *
+ * Copyright (C) 2013-2014, Linaro Ltd.
+ * Author: Al Stone <al.stone@xxxxxxxxxx>
+ * Author: Graeme Gregory <graeme.gregory@xxxxxxxxxx>
+ * Author: Hanjun Guo <hanjun.guo@xxxxxxxxxx>
+ * Author: Tomasz Nowicki <tomasz.nowicki@xxxxxxxxxx>
+ * Author: Naresh Bhat <naresh.bhat@xxxxxxxxxx>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#define pr_fmt(fmt) "ACPI: " fmt
+
+#include <linux/acpi.h>
+#include <linux/bootmem.h>
+#include <linux/cpumask.h>
+#include <linux/init.h>
+#include <linux/irq.h>
+#include <linux/irqdomain.h>
+#include <linux/memblock.h>
+#include <linux/smp.h>
+
+int acpi_noirq; /* skip ACPI IRQ initialization */
+int acpi_disabled;
+EXPORT_SYMBOL(acpi_disabled);
+
+int acpi_pci_disabled; /* skip ACPI PCI scan and IRQ initialization */
+EXPORT_SYMBOL(acpi_pci_disabled);
+
+/*
+ * __acpi_map_table() will be called before page_init(), so early_ioremap()
+ * or early_memremap() should be called here to for ACPI table mapping.
+ */
+char *__init __acpi_map_table(unsigned long phys, unsigned long size)
+{
+ if (!phys || !size)
Is there a reason to rule out physical address 0x0 ?
No particular reasons, unless some arch/firmware limits, I'm
not sure if we need this check (x86 needs it), I'm CC Leif
to confirm.
Nothing in UEFI explicitly bans using physical address 0 for anything,
and nothing in the architecture reserves it. So I don't think this
check is necessary.