aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2020-03-25firmware: psci: Replace cpu_up/down() with add/remove_cpu()Qais Yousef1-2/+2
The core device API performs extra housekeeping bits that are missing from directly calling cpu_up/down(). See commit a6717c01ddc2 ("powerpc/rtas: use device model APIs and serialization during LPM") for an example description of what might go wrong. This also prepares to make cpu_up/down a private interface of the CPU subsystem. Signed-off-by: Qais Yousef <[email protected]> Signed-off-by: Thomas Gleixner <[email protected]> Cc: Lorenzo Pieralisi <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-03-24firmware: xilinx: Add DLL reset supportManish Narani1-0/+1
SD DLL resets are required for some of the operations on ZynqMP platform. Add DLL reset support in ZynqMP firmware driver for SD DLL reset. Signed-off-by: Manish Narani <[email protected]> Acked-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-03-24firmware: xilinx: Add ZynqMP Tap Delay setup ioctl to the valid listManish Narani1-0/+1
The Tap Delay setup ioctl was not added to valid list due to which it may fail to set Tap Delays for SD. This patch fixes the same. Signed-off-by: Manish Narani <[email protected]> Acked-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ulf Hansson <[email protected]>
2020-03-23firmware: dmi: Add macro SMBIOS_ENTRY_POINT_SCAN_STARTTiezhu Yang1-1/+5
Use SMBIOS_ENTRY_POINT_SCAN_START instead of 0xF0000, because other archtecture maybe use a special start address such as 0xFFFE000 for Loongson platform. Signed-off-by: Tiezhu Yang <[email protected]> Reviewed-by: Jean Delvare <[email protected]> Signed-off-by: Thomas Bogendoerfer <[email protected]>
2020-03-23Merge 5.6-rc7 into char-misc-nextGreg Kroah-Hartman1-9/+23
We need the char/misc driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-21Merge branch 'linus' into locking/kcsan, to pick up fixesIngo Molnar5-16/+57
Signed-off-by: Ingo Molnar <[email protected]>
2020-03-21Merge branch 'x86/kdump' into locking/kcsan, to resolve conflictsIngo Molnar45-2126/+2119
Conflicts: arch/x86/purgatory/Makefile Signed-off-by: Ingo Molnar <[email protected]>
2020-03-20platform/x86: touchscreen_dmi: Add EFI embedded firmware info supportHans de Goede1-0/+3
Sofar we have been unable to get permission from the vendors to put the firmware for touchscreens listed in touchscreen_dmi in linux-firmware. Some of the tablets with such a touchscreen have a touchscreen driver, and thus a copy of the firmware, as part of their EFI code. This commit adds the necessary info for the new EFI embedded-firmware code to extract these firmwares, making the touchscreen work OOTB without the user needing to manually add the firmware. Acked-by: Andy Shevchenko <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-20Merge tag 'stable-shared-branch-for-driver-tree' of ↵Greg Kroah-Hartman4-0/+210
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into driver-core-next Ard writes: Stable shared branch between EFI and driver tree Stable shared branch to ease the integration of Hans's series to support device firmware loaded from EFI boot service memory regions. [PATCH v12 00/10] efi/firmware/platform-x86: Add EFI embedded fw support https://lore.kernel.org/linux-efi/[email protected]/ * tag 'stable-shared-branch-for-driver-tree' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: efi: Add embedded peripheral firmware support efi: Export boot-services code and data as debugfs-blobs
2020-03-18firmware: imx: add COMPILE_TEST supportAnson Huang1-2/+2
Add COMPILE_TEST support to i.MX SCU drivers for better compile testing coverage. Signed-off-by: Anson Huang <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-18firmware: stratix10-svc: add the compatible value for intel agilexRichard Gong1-0/+1
Add the compatible property value so we can reuse Intel Stratix10 Service Layer driver on Intel Agilex SoC platform. Signed-off-by: Richard Gong <[email protected]> Acked-by: Moritz Fischer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-18firmware: intel_stratix10_service: add depend on agilexRichard Gong1-1/+1
Add depend on Agilex for Intel Agilex SoC platform. Signed-off-by: Richard Gong <[email protected]> Acked-by: Moritz Fischer <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-16firmware: imx: add COMPILE_TEST for IMX_SCU driverAnson Huang1-1/+1
Add COMPILE_TEST support to IMX_SCU driver for better compile testing coverage. Any driver depending on IMX_SCU shouldn't have COMPILE_TEST though. Signed-off-by: Anson Huang <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-03-15Merge tag 'efi-urgent-2020-03-15' of ↵Linus Torvalds1-9/+23
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Thomas Gleixner: "Two EFI fixes: - Prevent a race and buffer overflow in the sysfs efivars interface which causes kernel memory corruption. - Add the missing NULL pointer checks in efivar_store_raw()" * tag 'efi-urgent-2020-03-15' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Add a sanity check to efivar_store_raw() efi: Fix a race and a buffer overflow while reading efivars via sysfs
2020-03-10firmware: imx: scu-pd: add power domain for I2C and INTMUX in CM40 SSJoakim Zhang1-0/+4
Add power domain for I2C and INTMUX in CM40 SS. Signed-off-by: Joakim Zhang <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-03-09arm64: zynqmp: Make zynqmp_firmware driver optionalTejas Patel1-0/+2
Make zynqmp_firmware driver as optional to disable it, if user don't want to use default zynqmp firmware interface. Signed-off-by: Tejas Patel <[email protected]> Signed-off-by: Jolly Shah <[email protected]> Signed-off-by: Michal Simek <[email protected]>
2020-03-09Merge 5.6-rc5 into driver-core-nextGreg Kroah-Hartman4-7/+34
We need the driver core and debugfs changes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-08Merge tag 'armsoc-fixes' of ↵Linus Torvalds3-5/+32
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "We've been accruing these for a couple of weeks, so the batch is a bit bigger than usual. Largest delta is due to a led-bl driver that is added -- there was a miscommunication before the merge window and the driver didn't make it in. Due to this, the platforms needing it regressed. At this point, it seemed easier to add the new driver than unwind the changes. Besides that, there are a handful of various fixes: - AMD tee memory leak fix - A handful of fixlets for i.MX SCU communication - A few maintainers woke up and realized DEBUG_FS had been missing for a while, so a few updates of that. ... and the usual collection of smaller fixes to various platforms" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (37 commits) ARM: socfpga_defconfig: Add back DEBUG_FS arm64: dts: socfpga: agilex: Fix gmac compatible ARM: bcm2835_defconfig: Explicitly restore CONFIG_DEBUG_FS arm64: dts: meson: fix gxm-khadas-vim2 wifi arm64: dts: meson-sm1-sei610: add missing interrupt-names ARM: meson: Drop unneeded select of COMMON_CLK ARM: dts: bcm2711: Add pcie0 alias ARM: dts: bcm283x: Add missing properties to the PWR LED tee: amdtee: fix memory leak in amdtee_open_session() ARM: OMAP2+: Fix compile if CONFIG_HAVE_ARM_SMCCC is not set arm: dts: dra76x: Fix mmc3 max-frequency ARM: dts: dra7: Add "dma-ranges" property to PCIe RC DT nodes bus: ti-sysc: Fix 1-wire reset quirk ARM: dts: r8a7779: Remove deprecated "renesas, rcar-sata" compatible value soc: imx-scu: Align imx sc msg structs to 4 firmware: imx: Align imx_sc_msg_req_cpu_start to 4 firmware: imx: scu-pd: Align imx sc msg structs to 4 firmware: imx: misc: Align imx sc msg structs to 4 firmware: imx: scu: Ensure sequential TX ARM: dts: imx7-colibri: Fix frequency for sd/mmc ...
2020-03-08efi/x86: Fix cast of image argumentArvind Sankar1-1/+1
handle_protocol() expects void **, not void *. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/libstub/x86: Use ULONG_MAX as upper bound for all allocationsArd Biesheuvel1-13/+4
The header flag XLF_CAN_BE_LOADED_ABOVE_4G will inform us whether allocations above 4 GiB for kernel, command line, etc are permitted, so we take it into account when calling efi_allocate_pages() etc. However, CONFIG_EFI_STUB implies CONFIG_RELOCATABLE, and so the flag is guaranteed to be set on x86_64 builds, whereas i386 builds are guaranteed to run under firmware that will not allocate above 4 GB in the first place. So drop the check, and just pass ULONG_MAX as the upper bound for all allocations. Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi: Fix a mistype in comments mentioning efivar_entry_iter_begin()Vladis Dronov2-2/+2
Signed-off-by: Vladis Dronov <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/libstub: Avoid linking libstub/lib-ksyms.o into vmlinuxMasahiro Yamada1-1/+1
drivers/firmware/efi/libstub/Makefile builds a static library, which is not linked into the main vmlinux target in the ordinary way [arm64], or at all [ARM, x86]. Since commit: 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably") any Makefile using lib-y generates lib-ksyms.o which is linked into vmlinux. In this case, the following garbage object is linked into vmlinux. drivers/firmware/efi/libstub/lib-ksyms.o We do not want to follow the default linking rules for static libraries built under libstub/ so using subdir-y instead of obj-y is the correct way to descend into this directory. Signed-off-by: Masahiro Yamada <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> [ardb: update commit log to clarify that arm64 deviates in this respect] Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/x86: Ignore the memory attributes table on i386Ard Biesheuvel1-1/+1
Commit: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE initialization common across all architectures") moved the call to efi_memattr_init() from ARM specific to the generic EFI init code, in order to be able to apply the restricted permissions described in that table on x86 as well. We never enabled this feature fully on i386, and so mapping and reserving this table is pointless. However, due to the early call to memblock_reserve(), the memory bookkeeping gets confused to the point where it produces the splat below when we try to map the memory later on: ------------[ cut here ]------------ ioremap on RAM at 0x3f251000 - 0x3fa1afff WARNING: CPU: 0 PID: 0 at arch/x86/mm/ioremap.c:166 __ioremap_caller ... Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.20.0 #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015 EIP: __ioremap_caller.constprop.0+0x249/0x260 Code: 90 0f b7 05 4e 38 40 de 09 45 e0 e9 09 ff ff ff 90 8d 45 ec c6 05 ... EAX: 00000029 EBX: 00000000 ECX: de59c228 EDX: 00000001 ESI: 3f250fff EDI: 00000000 EBP: de3edf20 ESP: de3edee0 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00200296 CR0: 80050033 CR2: ffd17000 CR3: 1e58c000 CR4: 00040690 Call Trace: ioremap_cache+0xd/0x10 ? old_map_region+0x72/0x9d old_map_region+0x72/0x9d efi_map_region+0x8/0xa efi_enter_virtual_mode+0x260/0x43b start_kernel+0x329/0x3aa i386_start_kernel+0xa7/0xab startup_32_smp+0x164/0x168 ---[ end trace e15ccf6b9f356833 ]--- Let's work around this by disregarding the memory attributes table altogether on i386, which does not result in a loss of functionality or protection, given that we never consumed the contents. Fixes: 3a6b6c6fb23667fa ("efi: Make EFI_MEMORY_ATTRIBUTES_TABLE ... ") Tested-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/x86: Don't relocate the kernel unless necessaryArvind Sankar1-3/+30
Add alignment slack to the PE image size, so that we can realign the decompression buffer within the space allocated for the image. Only relocate the kernel if it has been loaded at an unsuitable address: - Below LOAD_PHYSICAL_ADDR, or - Above 64T for 64-bit and 512MiB for 32-bit For 32-bit, the upper limit is conservative, but the exact limit can be difficult to calculate. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/x86: Decompress at start of PE image load addressArvind Sankar1-3/+14
When booted via PE loader, define image_offset to hold the offset of startup_32() from the start of the PE image, and use it as the start of the decompression buffer. [ mingo: Fixed the grammar in the comments. ] Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/libstub/x86: Deal with exit() boot service returningArd Biesheuvel1-1/+2
Even though it is uncommon, there are cases where the Exit() EFI boot service might return, e.g., when we were booted via the EFI handover protocol from OVMF and the kernel image was specified on the command line, in which case Exit() attempts to terminate the boot manager, which is not an EFI application itself. So let's drop into an infinite loop instead of randomly executing code that isn't expecting it. Tested-by: Nathan Chancellor <[email protected]> # build Signed-off-by: Ard Biesheuvel <[email protected]> [ardb: put 'hlt' in deadloop] Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi/x86: Avoid using code32_startArvind Sankar1-5/+5
code32_start is meant for 16-bit real-mode bootloaders to inform the kernel where the 32-bit protected mode code starts. Nothing in the protected mode kernel except the EFI stub uses it. efi_main() currently returns boot_params, with code32_start set inside it to tell efi_stub_entry() where startup_32 is located. Since it was invoked by efi_stub_entry() in the first place, boot_params is already known. Return the address of startup_32 instead. This will allow a 64-bit kernel to live above 4Gb, for example, and it's cleaner as well. Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08Merge branch 'efi/urgent' into efi/core, to pick up fixesIngo Molnar2-11/+25
Signed-off-by: Ingo Molnar <[email protected]>
2020-03-08efi: Add a sanity check to efivar_store_raw()Vladis Dronov1-0/+3
Add a sanity check to efivar_store_raw() the same way efivar_{attr,size,data}_read() and efivar_show_raw() have it. Signed-off-by: Vladis Dronov <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08efi: Fix a race and a buffer overflow while reading efivars via sysfsVladis Dronov1-9/+20
There is a race and a buffer overflow corrupting a kernel memory while reading an EFI variable with a size more than 1024 bytes via the older sysfs method. This happens because accessing struct efi_variable in efivar_{attr,size,data}_read() and friends is not protected from a concurrent access leading to a kernel memory corruption and, at best, to a crash. The race scenario is the following: CPU0: CPU1: efivar_attr_read() var->DataSize = 1024; efivar_entry_get(... &var->DataSize) down_interruptible(&efivars_lock) efivar_attr_read() // same EFI var var->DataSize = 1024; efivar_entry_get(... &var->DataSize) down_interruptible(&efivars_lock) virt_efi_get_variable() // returns EFI_BUFFER_TOO_SMALL but // var->DataSize is set to a real // var size more than 1024 bytes up(&efivars_lock) virt_efi_get_variable() // called with var->DataSize set // to a real var size, returns // successfully and overwrites // a 1024-bytes kernel buffer up(&efivars_lock) This can be reproduced by concurrent reading of an EFI variable which size is more than 1024 bytes: ts# for cpu in $(seq 0 $(nproc --ignore=1)); do ( taskset -c $cpu \ cat /sys/firmware/efi/vars/KEKDefault*/size & ) ; done Fix this by using a local variable for a var's data buffer size so it does not get overwritten. Fixes: e14ab23dde12b80d ("efivars: efivar_entry API") Reported-by: Bob Sanders <[email protected]> and the LTP testsuite Signed-off-by: Vladis Dronov <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-03-08Merge tag 'efi-next' of ↵Ingo Molnar4-0/+210
git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/core More EFI updates for v5.7 - Incorporate a stable branch with the EFI pieces of Hans's work on loading device firmware from EFI boot service memory regions Signed-off-by: Ingo Molnar <[email protected]>
2020-03-04efi/arm: Start using fw_devlink_get_flags()Saravana Kannan1-1/+1
The fw_devlink_get_flags() provides the right flags to use when creating mandatory device links derived from information provided by the firmware. So, use that. Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Saravana Kannan <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-03-03efi: Add embedded peripheral firmware supportHans de Goede3-0/+153
Just like with PCI options ROMs, which we save in the setup_efi_pci* functions from arch/x86/boot/compressed/eboot.c, the EFI code / ROM itself sometimes may contain data which is useful/necessary for peripheral drivers to have access to. Specifically the EFI code may contain an embedded copy of firmware which needs to be (re)loaded into the peripheral. Normally such firmware would be part of linux-firmware, but in some cases this is not feasible, for 2 reasons: 1) The firmware is customized for a specific use-case of the chipset / use with a specific hardware model, so we cannot have a single firmware file for the chipset. E.g. touchscreen controller firmwares are compiled specifically for the hardware model they are used with, as they are calibrated for a specific model digitizer. 2) Despite repeated attempts we have failed to get permission to redistribute the firmware. This is especially a problem with customized firmwares, these get created by the chip vendor for a specific ODM and the copyright may partially belong with the ODM, so the chip vendor cannot give a blanket permission to distribute these. This commit adds support for finding peripheral firmware embedded in the EFI code and makes the found firmware available through the new efi_get_embedded_fw() function. Support for loading these firmwares through the standard firmware loading mechanism is added in a follow-up commit in this patch-series. Note we check the EFI_BOOT_SERVICES_CODE for embedded firmware near the end of start_kernel(), just before calling rest_init(), this is on purpose because the typical EFI_BOOT_SERVICES_CODE memory-segment is too large for early_memremap(), so the check must be done after mm_init(). This relies on EFI_BOOT_SERVICES_CODE not being free-ed until efi_free_boot_services() is called, which means that this will only work on x86 for now. Reported-by: Dave Olsthoorn <[email protected]> Suggested-by: Peter Jones <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-03-03efi: Export boot-services code and data as debugfs-blobsHans de Goede1-0/+57
Sometimes it is useful to be able to dump the efi boot-services code and data. This commit adds these as debugfs-blobs to /sys/kernel/debug/efi, but only if efi=debug is passed on the kernel-commandline as this requires not freeing those memory-regions, which costs 20+ MB of RAM. Reviewed-by: Greg Kroah-Hartman <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Hans de Goede <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-29efi: Mark all EFI runtime services as unsupported on non-EFI bootArd Biesheuvel1-3/+3
Recent changes to the way we deal with EFI runtime services that are marked as unsupported by the firmware resulted in a regression for non-EFI boot. The problem is that all EFI runtime services are marked as available by default, and any non-NULL checks on the EFI service function pointers (which will be non-NULL even for runtime services that are unsupported on an EFI boot) were replaced with checks against the mask stored in efi.runtime_supported_mask. When doing a non-EFI boot, this check against the mask will return a false positive, given the fact that all runtime services are marked as enabled by default. Since we dropped the non-NULL check of the runtime service function pointer in favor of the mask check, we will now unconditionally dereference the function pointer, even if it is NULL, and go boom. So let's ensure that the mask reflects reality on a non-EFI boot, which is that all EFI runtime services are unsupported. Reported-by: David Hildenbrand <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: Heinrich Schuchardt <[email protected]> Cc: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected]
2020-02-29efi: Don't shadow 'i' in efi_config_parse_tables()Heinrich Schuchardt1-1/+0
Shadowing variables is generally frowned upon. Let's simply reuse the existing loop counter 'i' instead of shadowing it. Signed-off-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Tom Lendacky <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-02-29efi/x86: Add RNG seed EFI table to unencrypted mapping checkTom Lendacky1-8/+10
When booting with SME active, EFI tables must be mapped unencrypted since they were built by UEFI in unencrypted memory. Update the list of tables to be checked during early_memremap() processing to account for the EFI RNG seed table. Signed-off-by: Tom Lendacky <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Cc: David Hildenbrand <[email protected]> Cc: Heinrich Schuchardt <[email protected]> Link: https://lore.kernel.org/r/b64385fc13e5d7ad4b459216524f138e7879234f.1582662842.git.thomas.lendacky@amd.com Link: https://lore.kernel.org/r/[email protected]
2020-02-28firmware: xilinx: Add ZynqMP aes API for AES functionalityKalyani Akula1-0/+25
Add ZynqMP firmware AES API to perform encryption/decryption of given data. Signed-off-by: Kalyani Akula <[email protected]> Acked-by: Michal Simek <[email protected]> Signed-off-by: Herbert Xu <[email protected]>
2020-02-27firmware: arm_sdei: clean up sdei_event_create()Liguang Zhang1-9/+3
Function sdei_event_find() is always called in sdei_event_create(), but it is already called in sdei_event_register(). This code is trying to avoid a double-create of the same event, which can't happen as we still hold the sdei_events_lock. We can remove this needless sdei_event_find() call. Signed-off-by: Liguang Zhang <[email protected]> [expanded commit message] Signed-off-by: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2020-02-27firmware: arm_sdei: Use cpus_read_lock() to avoid races with cpuhpJames Morse1-12/+14
SDEI has private events that need registering and enabling on each CPU. CPUs can come and go while we are trying to do this. SDEI tries to avoid these problems by setting the reregister flag before the register call, so any CPUs that come online register the event too. Sticking plaster like this doesn't work, as if the register call fails, a CPU that subsequently comes online will register the event before reregister is cleared. Take cpus_read_lock() around the register and enable calls. We don't want surprise CPUs to do the wrong thing if they race with these calls failing. Signed-off-by: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2020-02-27firmware: arm_sdei: fix possible double-lock on hibernate error pathLiguang Zhang1-6/+13
We call sdei_reregister_event() with sdei_list_lock held, if the register fails we call sdei_event_destroy() which also acquires sdei_list_lock thus creating A-A deadlock. Add '_llocked' to sdei_reregister_event(), to indicate the list lock is held, and add a _llocked variant of sdei_event_destroy(). Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states") Signed-off-by: Liguang Zhang <[email protected]> [expanded subject, added wrappers instead of duplicating contents] Signed-off-by: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2020-02-27firmware: arm_sdei: fix double-lock on hibernate with shared eventsJames Morse1-17/+15
SDEI has private events that must be registered on each CPU. When CPUs come and go they must re-register and re-enable their private events. Each event has flags to indicate whether this should happen to protect against an event being registered on a CPU coming online, while all the others are unregistering the event. These flags are protected by the sdei_list_lock spinlock, because the cpuhp callbacks can't take the mutex. Hibernate needs to unregister all events, but keep the in-memory re-register and re-enable as they are. sdei_unregister_shared() takes the spinlock to walk the list, then calls _sdei_event_unregister() on each shared event. _sdei_event_unregister() tries to take the same spinlock to update re-register and re-enable. This doesn't go so well. Push the re-register and re-enable updates out to their callers. sdei_unregister_shared() doesn't want these values updated, so doesn't need to do anything. This also fixes shared events getting lost over hibernate as this path made them look unregistered. Fixes: da351827240e ("firmware: arm_sdei: Add support for CPU and system power states") Reported-by: Liguang Zhang <[email protected]> Signed-off-by: James Morse <[email protected]> Signed-off-by: Catalin Marinas <[email protected]>
2020-02-26efi: READ_ONCE rng seed size before munmapJason A. Donenfeld1-2/+2
This function is consistent with using size instead of seed->size (except for one place that this patch fixes), but it reads seed->size without using READ_ONCE, which means the compiler might still do something unwanted. So, this commit simply adds the READ_ONCE wrapper. Fixes: 636259880a7e ("efi: Add support for seeding the RNG from a UEFI ...") Signed-off-by: Jason A. Donenfeld <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ingo Molnar <[email protected]> Cc: [email protected] Cc: Ingo Molnar <[email protected]> Cc: Thomas Gleixner <[email protected]> Link: https://lore.kernel.org/r/[email protected] Link: https://lore.kernel.org/r/[email protected]
2020-02-25x86/*/Makefile: Use -fno-asynchronous-unwind-tables to suppress .eh_frame ↵Arvind Sankar1-1/+2
sections While discussing a patch to discard .eh_frame from the compressed vmlinux using the linker script, Fangrui Song pointed out [1] that these sections shouldn't exist in the first place because arch/x86/Makefile uses -fno-asynchronous-unwind-tables. It turns out this is because the Makefiles used to build the compressed kernel redefine KBUILD_CFLAGS, dropping this flag. Add the flag to the Makefile for the compressed kernel, as well as the EFI stub Makefile to fix this. Also add the flag to boot/Makefile and realmode/rm/Makefile so that the kernel's boot code (boot/setup.elf) and realmode trampoline (realmode/rm/realmode.elf) won't be compiled with .eh_frame sections, since their linker scripts also just discard them. [1] https://lore.kernel.org/lkml/[email protected]/ Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Arvind Sankar <[email protected]> Signed-off-by: Borislav Petkov <[email protected]> Reviewed-by: Nathan Chancellor <[email protected]> Reviewed-by: Nick Desaulniers <[email protected]> Reviewed-by: Kees Cook <[email protected]> Tested-by: Nathan Chancellor <[email protected]> Link: https://lkml.kernel.org/r/[email protected]
2020-02-24firmware: imx: Align imx_sc_msg_req_cpu_start to 4Leonard Crestez1-1/+1
The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y. Fix by marking with __aligned(4). Fixes: d90bf296ae18 ("firmware: imx: Add support to start/stop a CPU") Signed-off-by: Leonard Crestez <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-02-24firmware: imx: scu-pd: Align imx sc msg structs to 4Leonard Crestez1-1/+1
The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y. Fix by marking with __aligned(4). Fixes: c800cd7824bd ("firmware: imx: add SCU power domain driver") Signed-off-by: Leonard Crestez <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-02-24firmware: imx: misc: Align imx sc msg structs to 4Leonard Crestez1-3/+3
The imx SC api strongly assumes that messages are composed out of 4-bytes words but some of our message structs have odd sizeofs. This produces many oopses with CONFIG_KASAN=y: BUG: KASAN: stack-out-of-bounds in imx_mu_send_data+0x108/0x1f0 It shouldn't cause an issues in normal use because these structs are always allocated on the stack. Fixes: 15e1f2bc8b3b ("firmware: imx: add misc svc support") Signed-off-by: Leonard Crestez <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-02-24firmware: imx: scu: Ensure sequential TXLeonard Crestez1-0/+27
SCU requires that all messages words are written sequentially but linux MU driver implements multiple independent channels for each register so ordering between different channels must be ensured by SCU API interface. Wait for tx_done before every send to ensure that no queueing happens at the mailbox channel level. Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support") Signed-off-by: Leonard Crestez <[email protected]> Cc: <[email protected]> Reviewed-by: Peng Fan <[email protected]> Reviewed-by:: Oleksij Rempel <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-02-23efi: Use EFI ResetSystem only when availableArd Biesheuvel1-2/+2
Do not attempt to call EFI ResetSystem if the runtime supported mask tells us it is no longer functional at OS runtime. Signed-off-by: Ard Biesheuvel <[email protected]>
2020-02-23efi: Register EFI rtc platform device only when availableArd Biesheuvel1-0/+3
Drop the separate driver that registers the EFI rtc on all EFI systems that have runtime services available, and instead, move the registration into the core EFI code, and make it conditional on whether the actual time related services are available. Acked-by: Alexandre Belloni <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.