From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Leif Lindholm <leif.lindholm@linaro.org>,
linux-kernel@vger.kernel.org, grant.likely@secretlab.ca,
linux-efi@vger.kernel.org, linux@arm.linux.org.uk,
patches@linaro.org, Will Deacon <will.deacon@arm.com>,
roy.franz@linaro.org, matt.fleming@intel.com, msalter@redhat.com
Subject: Re: [PATCH v4 4/5] arm: Add [U]EFI runtime services support
Date: Mon, 13 Jan 2014 19:43:09 +0100 [thread overview]
Message-ID: <201401131943.10352.arnd@arndb.de> (raw)
In-Reply-To: <1389445524-30623-5-git-send-email-leif.lindholm@linaro.org>
On Saturday 11 January 2014, Leif Lindholm wrote:
> This patch implements basic support for UEFI runtime services in the
> ARM architecture - a requirement for using efibootmgr to read and update
> the system boot configuration.
>
> It uses the generic configuration table scanning to populate ACPI and
> SMBIOS pointers.
As far as I'm concerned there are no plans to have ACPI support on ARM32,
so I wonder what the code to populate the ACPI tables is about. Can
you clarify this?
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 78a79a6a..1ab24cc 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1853,6 +1853,20 @@ config EARLY_IOREMAP
> the same virtual memory range as kmap so all early mappings must
> be unapped before paging_init() is called.
>
> +config EFI
> + bool "UEFI runtime service support"
> + depends on OF && !CPU_BIG_ENDIAN
What is the dependency on !CPU_BIG_ENDIAN? We try hard to have
all kernel code support both big-endian and little-endian, and
I'm guessing there is a significant overlap between the people
that want UEFI support and those that want big-endian kernels.
> +struct efi_memory_map memmap;
"memmap" is not a good name for a global identifier, particularly because
it's easily confused with the well-known "mem_map" array. This
wants namespace prefix like you other variable, or a "static" tag,
preferably both.
> +/*
> + * This function switches the UEFI runtime services to virtual mode.
> + * This operation must be performed only once in the system's lifetime,
> + * including any kecec calls.
kexec
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index fa7d950..afaeb85 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -664,7 +664,7 @@ extern int __init efi_setup_pcdp_console(char *);
> #define EFI_64BIT 5 /* Is the firmware 64-bit? */
>
> #ifdef CONFIG_EFI
> -# ifdef CONFIG_X86
> +# if defined(CONFIG_X86) || defined(CONFIG_ARM)
> extern int efi_enabled(int facility);
> # else
> static inline int efi_enabled(int facility)
Maybe better #ifndef CONFIG_IA64? It seems that is the odd one out and
all possible future architectures would be like x86 and ARM.
Arnd
next prev parent reply other threads:[~2014-01-13 18:43 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-11 13:05 [PATCH v4 0/5] arm: add UEFI runtime services support Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 1/5] arm: break part of __soft_restart out into separate function Leif Lindholm
2014-01-22 11:09 ` Will Deacon
2014-01-11 13:05 ` [PATCH v4 2/5] arm: add new asm macro update_sctlr Leif Lindholm
2014-01-22 11:20 ` Will Deacon
2014-01-29 18:28 ` Leif Lindholm
2014-01-29 19:27 ` Will Deacon
2014-01-29 20:58 ` Mark Salter
2014-01-30 13:12 ` Leif Lindholm
2014-02-03 10:34 ` Will Deacon
2014-02-03 15:55 ` Leif Lindholm
2014-02-03 16:00 ` Will Deacon
2014-02-03 16:20 ` Rob Herring
2014-02-03 16:46 ` Leif Lindholm
2014-02-03 16:57 ` Will Deacon
2014-02-03 18:15 ` Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 3/5] Documentation: arm: add UEFI support documentation Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 4/5] arm: Add [U]EFI runtime services support Leif Lindholm
2014-01-13 15:40 ` Matt Fleming
2014-01-13 18:43 ` Arnd Bergmann [this message]
2014-01-13 20:01 ` Leif Lindholm
2014-01-14 6:52 ` Arnd Bergmann
2014-01-14 11:44 ` Leif Lindholm
2014-01-14 13:26 ` Arnd Bergmann
2014-01-14 15:25 ` Leif Lindholm
2014-01-11 13:05 ` [PATCH v4 5/5] init: efi: arm: enable (U)EFI runtime services on arm Leif Lindholm
2014-01-13 18:29 ` Arnd Bergmann
2014-01-13 18:57 ` Leif Lindholm
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=201401131943.10352.arnd@arndb.de \
--to=arnd@arndb.de \
--cc=grant.likely@secretlab.ca \
--cc=leif.lindholm@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-efi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=matt.fleming@intel.com \
--cc=msalter@redhat.com \
--cc=patches@linaro.org \
--cc=roy.franz@linaro.org \
--cc=will.deacon@arm.com \
/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