user/sven/linux.git/drivers/firmware/efi, branch v5.19.3

Merge tag 'platform-drivers-x86-v5.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86

2022-07-15T17:12:22Z

Pull x86 platform driver fixes from Hans de Goede: "Highlights: - Fix brightness key events getting reported twice on some Dells. Regression caused by recent Panasonic hotkey fixes - Fix poweroff no longer working on some devices regression caused by recent poweroff handler rework - Mark new (in 5.19) Intel IFS driver as broken, because of some issues surrounding the userspace (sysfs) API which need to be cleared up - Some hardware-id / quirk additions" * tag 'platform-drivers-x86-v5.19-4' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: ACPI: video: Fix acpi_video_handles_brightness_key_presses() platform/x86: intel_atomisp2_led: Also turn off the always-on camera LED on the Asus T100TAF platform/x86/intel/ifs: Mark as BROKEN platform/x86: asus-wmi: Add key mappings efi: Fix efi_power_off() not being run before acpi_power_off() when necessary platform/x86: x86-android-tablets: Fix Lenovo Yoga Tablet 2 830/1050 poweroff again platform/x86: gigabyte-wmi: add support for B660I AORUS PRO DDR4 platform/x86/amd/pmc: Add new platform support platform/x86/amd/pmc: Add new acpi id for PMC controller

efi: Fix efi_power_off() not being run before acpi_power_off() when necessary

2022-07-10T15:41:06Z

Commit 98f30d0ecf79 ("ACPI: power: Switch to sys-off handler API") switched the ACPI sleep code from directly setting the old global pm_power_off handler to using the new register_sys_off_handler() mechanism with a priority of SYS_OFF_PRIO_FIRMWARE. This is a problem when the old global pm_power_off handler would later be overwritten, such as done by the late_initcall(efi_shutdown_init): if (efi_poweroff_required()) pm_power_off = efi_power_off; The old global pm_power_off handler gets run with a priority of SYS_OFF_PRIO_DEFAULT which is lower then SYS_OFF_PRIO_FIRMWARE, causing acpi_power_off() to run first, changing the behavior from before the ACPI sleep code switched to the new register_sys_off_handler(). Switch the registering of efi_power_off over to register_sys_off_handler() with a priority of SYS_OFF_PRIO_FIRMWARE + 1 so that it will run before acpi_power_off() as before. Note since the new sys-off-handler code will try all handlers in priority order, there is no more need for the EFI code to store and call the original pm_power_off handler. Fixes: 98f30d0ecf79 ("ACPI: power: Switch to sys-off handler API") Cc: Dmitry Osipenko Signed-off-by: Hans de Goede Acked-by: Ard Biesheuvel Link: https://lore.kernel.org/r/20220708131412.81078-3-hdegoede@redhat.com

efi: sysfb_efi: remove unnecessary include

2022-06-21T16:11:43Z

Nothing defined in the header is used by drivers/firmware/efi/sysfb_efi.c but also, including it can lead to build errors when built on arches that don't have an asm/efi.h header file. This can happen for example if a driver that is built when COMPILE_TEST is enabled selects the SYSFB symbol, e.g. on powerpc with allyesconfig: drivers/firmware/efi/sysfb_efi.c:29:10: fatal error: asm/efi.h: No such file or directory 29 | #include | ^~~~~~~~~~~ Reported-by: Stephen Rothwell Signed-off-by: Javier Martinez Canillas Signed-off-by: Ard Biesheuvel

Merge tag 'efi-next-for-v5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi

2022-06-03T20:39:30Z

Pull more EFI updates from Ard Biesheuvel: "Follow-up tweaks for EFI changes - they mostly address issues introduced this merge window, except for Heinrich's patch: - fix new DXE service invocations for mixed mode - use correct Kconfig symbol when setting PE header flag - clean up the drivers/firmware/efi Kconfig dependencies so that features that depend on CONFIG_EFI are hidden from the UI when the symbol is not enabled. Also included is a RISC-V bugfix from Heinrich to avoid read-write mappings of read-only firmware regions in the EFI page tables" * tag 'efi-next-for-v5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: clean up Kconfig dependencies on CONFIG_EFI efi/x86: libstub: Make DXE calls mixed mode safe efi: x86: Fix config name for setting the NX-compatibility flag in the PE header riscv: read-only pages should not be writable

efi: clean up Kconfig dependencies on CONFIG_EFI

2022-06-01T12:08:13Z

Geert reports that the new option CONFIG_EFI_DISABLE_RUNTIME is user visible even when EFI support is disabled, which is unnecessary and clutters the Kconfig interface. So let's move this option into the existing Kconfig submenu that already depends on CONFIG_EFI, and while at it, give some other options the same treatment. Also clean up a small wart where the efi/ subdirectory is listed twice. Let's just list it unconditionally so that both EFI and UEFI_CPER based pieces will be built independently (the latter only depends on the former on !X86) Signed-off-by: Ard Biesheuvel

efi/x86: libstub: Make DXE calls mixed mode safe

2022-06-01T12:08:12Z

The newly added DXE calls use 64-bit quantities, which means we need to marshall them explicitly when running in mixed mode. Currently, we get away without it because we just bail when GetMemorySpaceDescriptor() fails, which is guaranteed to happen due to the function argument mixup. Let's fix this properly, though, by defining the macros that describe how to marshall the arguments. While at it, drop an incorrect cast on a status variable. Signed-off-by: Ard Biesheuvel

Merge tag 'edac_updates_for_v5.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras

2022-05-24T00:34:20Z

Pull EDAC updates from Borislav Petkov: - Switch ghes_edac to use the CPER error reporting routines and simplify the code considerably this way - Rip out the silly edac_align_ptr() contraption which was computing the size of the private structures of each driver and thus allowing for a one-shot memory allocation. This was clearly unnecessary and confusing so switch to simple and boring kmalloc* calls. - Last but not least, the usual garden variety of fixes, cleanups and improvements all over EDAC land * tag 'edac_updates_for_v5.19_rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras: EDAC/xgene: Fix typo processsors -> processors EDAC/i5100: Remove unused inline function i5100_nrecmema_dm_buf_id() EDAC: Use kcalloc() EDAC/ghes: Change ghes_hw from global to static EDAC/armada_xp: Use devm_platform_ioremap_resource() EDAC/synopsys: Add a SPDX identifier EDAC/synopsys: Add driver support for i.MX platforms EDAC/dmc520: Don't print an error for each unconfigured interrupt line EDAC/mc: Get rid of edac_align_ptr() EDAC/device: Sanitize edac_device_alloc_ctl_info() definition EDAC/device: Get rid of the silly one-shot memory allocation in edac_device_alloc_ctl_info() EDAC/pci: Get rid of the silly one-shot memory allocation in edac_pci_alloc_ctl_info() EDAC/mc: Get rid of silly one-shot struct allocation in edac_mc_alloc() efi/cper: Reformat CPER memory error location to more readable EDAC/ghes: Unify CPER memory error location reporting efi/cper: Add a cper_mem_err_status_str() to decode error description powerpc/85xx: Remove fsl,85... bindings

riscv/efi_stub: Add support for RISCV_EFI_BOOT_PROTOCOL

2022-05-19T08:22:17Z

Add support for getting the boot hart ID from the Linux EFI stub using RISCV_EFI_BOOT_PROTOCOL. This method is preferred over the existing DT based approach since it works irrespective of DT or ACPI. The specification of the protocol is hosted at: https://github.com/riscv-non-isa/riscv-uefi Signed-off-by: Sunil V L Acked-by: Palmer Dabbelt Reviewed-by: Heinrich Schuchardt Link: https://lore.kernel.org/r/20220519051512.136724-2-sunilvl@ventanamicro.com [ardb: minor tweaks for coding style and whitespace] Signed-off-by: Ard Biesheuvel

efi: stub: prefer mirrored memory for randomized allocations

2022-05-06T07:51:22Z

If the system exposes memory regions with the EFI_MORE_RELIABLE attribute, it is implied that it is intended to be used for allocations that are relatively important, such as the kernel's static image. Since efi_random_alloc() is mostly (only) used for allocating space for the kernel image, let's update it to take this into account, and disregard all memory without the EFI_MORE_RELIABLE attribute if there is sufficient memory available that does have this attribute. Note that this change only affects booting with randomization enabled. In other cases, the EFI stub runs the kernel image in place unless its placement is unsuitable for some reason (i.e., misaligned, or its BSS overlaps with another allocation), and it is left to the bootloader to ensure that the kernel was loaded into EFI_MORE_RELIABLE memory if this is desired. Signed-off-by: Ard Biesheuvel Reviewed-by: Kefeng Wang

efi/arm64: libstub: run image in place if randomized by the loader

2022-05-03T13:31:29Z

If the loader has already placed the EFI kernel image randomly in physical memory, and indicates having done so by installing the 'fixed placement' protocol onto the image handle, don't bother randomizing the placement again in the EFI stub. Signed-off-by: Ard Biesheuvel