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@xxxxxxxxxx>
> ---
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
