linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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.

  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).