linux.git/arch/arm/include/asm/efi.h, branch for-next

efi/arm: Disable LPAE PAN when calling EFI runtime services

2024-06-15T08:25:02+00:00

EFI runtime services are remapped into the lower 1 GiB of virtual
address space at boot, so they are guaranteed to be able to co-exist
with the kernel virtual mappings without the need to allocate space for
them in the kernel's vmalloc region, which is rather small.

This means those mappings are covered by TTBR0 when LPAE PAN is enabled,
and so 'user' access must be enabled while such calls are in progress.

Reviewed-by: Linus Walleij 
Signed-off-by: Ard Biesheuvel

efi: Discover BTI support in runtime services regions

2023-02-04T08:19:02+00:00

Add the generic plumbing to detect whether or not the runtime code
regions were constructed with BTI/IBT landing pads by the firmware,
permitting the OS to enable enforcement when mapping these regions into
the OS's address space.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Kees Cook

efi: libstub: Move screen_info handling to common code

2022-11-09T11:42:02+00:00

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:16+00:00

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:09+00:00

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:16+00:00

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:56+00:00

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:06+00:00

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:27+00:00

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:27+00:00

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