From: matt@codeblueprint.co.uk (Matt Fleming)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 8/8] efi/arm: populate screen_info based on data provided by the UEFI stub
Date: Fri, 18 Mar 2016 11:53:13 +0000 [thread overview]
Message-ID: <20160318115313.GR2619@codeblueprint.co.uk> (raw)
In-Reply-To: <1457588408-19309-9-git-send-email-ard.biesheuvel@linaro.org>
On Thu, 10 Mar, at 12:40:08PM, Ard Biesheuvel wrote:
> Unlike on arm64, where we can simply access the screen_info struct directly,
> ARM requires an intermediate step to get the information discovered by the
> GOP code in the UEFI stub into the screen_info struct.
>
> So retrieve the dedicated config table we invented for this purpose, and
> put its contents into the core kernel's copy of struct screen_info.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm/kernel/efi.c | 24 ++++++++++++++++++++
> drivers/firmware/efi/arm-init.c | 6 +++++
> 2 files changed, 30 insertions(+)
[...]
> diff --git a/drivers/firmware/efi/arm-init.c b/drivers/firmware/efi/arm-init.c
> index eca9b4f826ee..689bf65f8ddf 100644
> --- a/drivers/firmware/efi/arm-init.c
> +++ b/drivers/firmware/efi/arm-init.c
> @@ -112,6 +112,12 @@ static int __init uefi_init(void)
> retval = efi_config_parse_tables(config_tables, efi.systab->nr_tables,
> sizeof(efi_config_table_t), NULL);
>
> + if (IS_ENABLED(CONFIG_ARM)) {
> + extern void efi_find_screen_info(efi_config_table_t *, u32);
> +
> + efi_find_screen_info(config_tables, efi.systab->nr_tables);
> + }
> +
> early_memunmap(config_tables, table_size);
> out:
> early_memunmap(efi.systab, sizeof(efi_system_table_t));
It's unfortunate that this is the first example of putting
arch-specific things in arm-init.c. Is there anyway we can move it out
into arch/arm?
If not, because efi_find_screen_info() uses all standard data types
and function calls, I wouldn't be opposed to just sticking this in
efi_config_parse_tables() like we do for EFI_PROPERTIES_TABLE. It's
certainly nice to have all config table code in one place.
Also, it would save ARM the effort of looping over the config tables
twice.
next prev parent reply other threads:[~2016-03-18 11:53 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-10 5:40 [PATCH 0/8] EFI framebuffer support for ARM and arm64 Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 1/8] efi: make install_configuration_table() boot service usable Ard Biesheuvel
2016-03-18 10:59 ` Matt Fleming
2016-03-18 11:02 ` Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 2/8] efi: libstub: move Graphics Output Protocol handling to generic code Ard Biesheuvel
2016-03-18 11:25 ` Matt Fleming
2016-03-10 5:40 ` [PATCH 3/8] efi/x86: libstub: move to generic GOP code Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 4/8] efi/x86: efifb: move DMI based quirks handling out of generic code Ard Biesheuvel
2016-03-18 10:50 ` Matt Fleming
2016-03-21 13:42 ` Peter Jones
2016-03-10 5:40 ` [PATCH 5/8] efi: efifb: use builtin_platform_driver and drop unused includes Ard Biesheuvel
2016-03-18 10:52 ` Matt Fleming
2016-03-21 13:43 ` Peter Jones
2016-03-10 5:40 ` [PATCH 6/8] efi/arm*: libstub: wire up GOP handling into the ARM UEFI stub Ard Biesheuvel
2016-03-10 8:25 ` Ingo Molnar
2016-03-10 8:36 ` Ard Biesheuvel
2016-03-10 9:03 ` Ingo Molnar
2016-03-10 9:14 ` Ard Biesheuvel
2016-03-10 9:25 ` Ingo Molnar
2016-03-10 10:25 ` Ard Biesheuvel
2016-03-10 14:49 ` Matt Fleming
2016-03-10 14:30 ` Matt Fleming
2016-03-18 11:37 ` Matt Fleming
2016-03-10 5:40 ` [PATCH 7/8] efi/arm*: efifb: expose efifb platform device if GOP is available Ard Biesheuvel
2016-03-10 5:40 ` [PATCH 8/8] efi/arm: populate screen_info based on data provided by the UEFI stub Ard Biesheuvel
2016-03-18 11:53 ` Matt Fleming [this message]
2016-03-18 11:57 ` Ard Biesheuvel
2016-03-10 16:12 ` [PATCH 0/8] EFI framebuffer support for ARM and arm64 Mark Langsdorf
2016-03-10 16:23 ` Ard Biesheuvel
2016-03-11 17:52 ` Alexander Graf
2016-03-11 18:24 ` Ard Biesheuvel
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=20160318115313.GR2619@codeblueprint.co.uk \
--to=matt@codeblueprint.co.uk \
--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).