kernel/arch/arm/include/asm/efi.h, branch linux-6.2.y

efi: libstub: Move screen_info handling to common code

2022-11-09T11:42:02Z

Currently, arm64, RISC-V and LoongArch rely on the fact that struct screen_info can be accessed directly, due to the fact that the EFI stub and the core kernel are part of the same image. This will change after a future patch, so let's ensure that the screen_info handling is able to deal with this, by adopting the arm32 approach of passing it as a configuration table. While at it, switch to ACPI reclaim memory to hold the screen_info data, which is more appropriate for this kind of allocation. Signed-off-by: Ard Biesheuvel

efi/arm: libstub: move ARM specific code out of generic routines

2022-09-27T11:26:16Z

Move some code that is only reachable when IS_ENABLED(CONFIG_ARM) into the ARM EFI arch code. Cc: Russell King Signed-off-by: Ard Biesheuvel

efi: Simplify arch_efi_call_virt() macro

2022-06-28T18:13:09Z

Currently, the arch_efi_call_virt() assumes all users of it will have defined a type 'efi_##f##_t' to make use of it. Simplify the arch_efi_call_virt() macro by eliminating the explicit need for efi_##f##_t type for every user of this macro. Signed-off-by: Sudeep Holla Acked-by: Russell King (Oracle) [ardb: apply Sudeep's ARM fix to i686, Loongarch and RISC-V too] Signed-off-by: Ard Biesheuvel

efi: Move efifb_setup_from_dmi() prototype from arch headers

2021-12-13T14:07:16Z

Commit 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") made the Generic System Framebuffers (sysfb) driver able to be built on non-x86 architectures. But it left the efifb_setup_from_dmi() function prototype declaration in the architecture specific headers. This could lead to the following compiler warning as reported by the kernel test robot: drivers/firmware/efi/sysfb_efi.c:70:6: warning: no previous prototype for function 'efifb_setup_from_dmi' [-Wmissing-prototypes] void efifb_setup_from_dmi(struct screen_info *si, const char *opt) ^ drivers/firmware/efi/sysfb_efi.c:70:1: note: declare 'static' if the function is not intended to be used outside of this translation unit void efifb_setup_from_dmi(struct screen_info *si, const char *opt) Fixes: 8633ef82f101 ("drivers/firmware: consolidate EFI framebuffer setup for all arches") Reported-by: kernel test robot Cc: # 5.15.x Signed-off-by: Javier Martinez Canillas Acked-by: Thomas Zimmermann Link: https://lore.kernel.org/r/20211126001333.555514-1-javierm@redhat.com Signed-off-by: Ard Biesheuvel

drivers/firmware: consolidate EFI framebuffer setup for all arches

2021-07-21T10:04:56Z

The register_gop_device() function registers an "efi-framebuffer" platform device to match against the efifb driver, to have an early framebuffer for EFI platforms. But there is already support to do exactly the same by the Generic System Framebuffers (sysfb) driver. This used to be only for X86 but it has been moved to drivers/firmware and could be reused by other architectures. Also, besides supporting registering an "efi-framebuffer", this driver can register a "simple-framebuffer" allowing to use the siple{fb,drm} drivers on non-X86 EFI platforms. For example, on aarch64 these drivers can only be used with DT and doesn't have code to register a "simple-frambuffer" platform device when booting with EFI. For these reasons, let's remove the register_gop_device() duplicated code and instead move the platform specific logic that's there to sysfb driver. Signed-off-by: Javier Martinez Canillas Acked-by: Borislav Petkov Acked-by: Daniel Vetter Signed-off-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20210625131359.1804394-1-javierm@redhat.com

efi: arm: force use of unsigned type for EFI_PHYS_ALIGN

2020-12-14T15:25:06Z

Ensure that EFI_PHYS_ALIGN is an unsigned type, to prevent spurious warnings from the type checks in the definition of the max() macro. Link: https://lore.kernel.org/linux-efi/20201213151306.73558-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel

efi: stub: get rid of efi_get_max_fdt_addr()

2020-12-09T07:37:27Z

Now that ARM started following the example of arm64 and RISC-V, and no longer imposes any restrictions on the placement of the FDT in memory at boot, we no longer need per-arch implementations of efi_get_max_fdt_addr() to factor out the differences. So get rid of it. Signed-off-by: Ard Biesheuvel Reviewed-by: Atish Patra Link: https://lore.kernel.org/r/20201029134901.9773-1-ardb@kernel.org

efi: arm: reduce minimum alignment of uncompressed kernel

2020-12-09T07:37:27Z

Now that we reduced the minimum relative alignment between PHYS_OFFSET and PAGE_OFFSET to 2 MiB, we can take this into account when allocating memory for the decompressed kernel when booting via EFI. This minimizes the amount of unusable memory we may end up with due to the base of DRAM being occupied by firmware. Signed-off-by: Ard Biesheuvel

efi: capsule: clean scatter-gather entries from the D-cache

2020-12-09T07:37:27Z

Scatter-gather lists passed to UpdateCapsule() should be cleaned from the D-cache to ensure that they are visible to the CPU after a warm reboot before the MMU is enabled. On ARM and arm64 systems, this implies a D-cache clean by virtual address to the point of coherency. However, due to the fact that the firmware itself is not able to map physical addresses back to virtual addresses when running under the OS, this must be done by the caller. Signed-off-by: Ard Biesheuvel

efi/libstub: arm32: Base FDT and initrd placement on image address

2020-09-16T15:53:42Z

The way we use the base of DRAM in the EFI stub is problematic as it is ill defined what the base of DRAM actually means. There are some restrictions on the placement of FDT and initrd which are defined in terms of dram_base, but given that the placement of the kernel in memory is what defines these boundaries (as on ARM, this is where the linear region starts), it is better to use the image address in these cases, and disregard dram_base altogether. Reviewed-by: Maxim Uvarov Tested-by: Maxim Uvarov Signed-off-by: Ard Biesheuvel