linux/drivers/firmware, branch v5.5

Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2020-01-18T20:50:14Z

Pull EFI fixes from Ingo Molnar: "Three EFI fixes: - Fix a slow-boot-scrolling regression but making sure we use WC for EFI earlycon framebuffer mappings on x86 - Fix a mixed EFI mode boot crash - Disable paging explicitly before entering startup_32() in mixed mode bootup" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efistub: Disable paging at mixed mode entry efi/libstub/random: Initialize pointer variables to zero for mixed mode efi/earlycon: Fix write-combine mapping on x86

firmware: tee_bnxt: Fix multiple call to tee_client_close_context

2020-01-06T21:51:37Z

Fix calling multiple tee_client_close_context in case of shm allocation fails. Fixes: 246880958ac9 (“firmware: broadcom: add OP-TEE based BNXT f/w manager”) Signed-off-by: Vikas Gupta Signed-off-by: David S. Miller

efi/libstub/random: Initialize pointer variables to zero for mixed mode

2019-12-25T09:46:06Z

Commit: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") causes the drivers/efi/libstub/random.c code to get used on x86 for the first time. But this code was not written with EFI mixed mode in mind (running a 64 bit kernel on 32 bit EFI firmware), this causes the kernel to crash during early boot when running in mixed mode. The problem is that in mixed mode pointers are 64 bit, but when running on a 32 bit firmware, EFI calls which return a pointer value by reference only fill the lower 32 bits of the passed pointer, leaving the upper 32 bits uninitialized which leads to crashes. This commit fixes this by initializing pointers which are passed by reference to EFI calls to NULL before passing them, so that the upper 32 bits are initialized to 0. Signed-off-by: Hans de Goede Signed-off-by: Ard Biesheuvel Cc: Arvind Sankar Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 0d95981438c3 ("x86: efi/random: Invoke EFI_RNG_PROTOCOL to seed the UEFI RNG table") Link: https://lkml.kernel.org/r/20191224132909.102540-3-ardb@kernel.org Signed-off-by: Ingo Molnar

efi/earlycon: Fix write-combine mapping on x86

2019-12-25T09:46:06Z

On x86, until PAT is initialized, WC translates into UC-. Since we calculate and store pgprot_writecombine(PAGE_KERNEL) when earlycon is initialized, this means we actually use UC- mappings instead of WC mappings, which makes scrolling very slow. Instead store a boolean flag to indicate whether we want to use writeback or write-combine mappings, and recalculate the actual pgprot_t we need on every mapping. Once PAT is initialized, we will start using write-combine mappings, which speeds up the scrolling considerably. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Hans de Goede Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Link: https://lkml.kernel.org/r/20191224132909.102540-2-ardb@kernel.org Signed-off-by: Ingo Molnar

Merge branch 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2019-12-17T18:39:55Z

Pull EFI fixes from Ingo Molnar: "Protect presistent EFI memory reservations from kexec, fix EFIFB early console, EFI stub graphics output fixes and other misc fixes." * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: Don't attempt to map RCI2 config table if it doesn't exist efi/earlycon: Remap entire framebuffer after page initialization efi: Fix efi_loaded_image_t::unload type efi/gop: Fix memory leak in __gop_query32/64() efi/gop: Return EFI_SUCCESS if a usable GOP was found efi/gop: Return EFI_NOT_FOUND if there are no usable GOPs efi/memreserve: Register reservations as 'reserved' in /proc/iomem

efi: Don't attempt to map RCI2 config table if it doesn't exist

2019-12-10T11:13:02Z

Commit: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs") ... added support for a Dell specific UEFI configuration table, but failed to take into account that mapping the table should not be attempted unless the table actually exists. If it doesn't exist, the code usually fails silently unless pr_debug() prints are enabled. However, on 32-bit PAE x86, the splat below is produced due to the attempt to map the placeholder value EFI_INVALID_TABLE_ADDR which we use for non-existing UEFI configuration tables, and which equals ULONG_MAX. memremap attempted on mixed range 0x00000000ffffffff size: 0x1e WARNING: CPU: 1 PID: 1 at kernel/iomem.c:81 memremap+0x1a3/0x1c0 Modules linked in: CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.4.2-smp-mine #1 Hardware name: Hewlett-Packard HP Z400 Workstation/0B4Ch, BIOS 786G3 v03.61 03/05/2018 EIP: memremap+0x1a3/0x1c0 ... Call Trace: ? map_properties+0x473/0x473 ? efi_rci2_sysfs_init+0x2c/0x154 ? map_properties+0x473/0x473 ? do_one_initcall+0x49/0x1d4 ? parse_args+0x1e8/0x2a0 ? do_early_param+0x7a/0x7a ? kernel_init_freeable+0x139/0x1c2 ? rest_init+0x8e/0x8e ? kernel_init+0xd/0xf2 ? ret_from_fork+0x2e/0x38 Fix this by checking whether the table exists before attempting to map it. Reported-by: Richard Narron Tested-by: Richard Narron Signed-off-by: Ard Biesheuvel Cc: linux-efi@vger.kernel.org Fixes: 1c5fecb61255aa12 ("efi: Export Runtime Configuration Interface table to sysfs") Link: https://lkml.kernel.org/r/20191210090945.11501-2-ardb@kernel.org Signed-off-by: Ingo Molnar

treewide: Use sizeof_field() macro

2019-12-09T18:36:44Z

Replace all the occurrences of FIELD_SIZEOF() with sizeof_field() except at places where these are defined. Later patches will remove the unused definition of FIELD_SIZEOF(). This patch is generated using following script: EXCLUDE_FILES="include/linux/stddef.h|include/linux/kernel.h" git grep -l -e "\bFIELD_SIZEOF\b" | while read file; do if [[ "$file" =~ $EXCLUDE_FILES ]]; then continue fi sed -i -e 's/\bFIELD_SIZEOF\b/sizeof_field/g' $file; done Signed-off-by: Pankaj Bharadiya Link: https://lore.kernel.org/r/20190924105839.110713-3-pankaj.laxminarayan.bharadiya@intel.com Co-developed-by: Kees Cook Signed-off-by: Kees Cook Acked-by: David Miller # for net

efi/earlycon: Remap entire framebuffer after page initialization

2019-12-08T11:42:19Z

When commit: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") moved the x86 specific EFI earlyprintk implementation to a shared location, it also tweaked the behaviour. In particular, it dropped a trick with full framebuffer remapping after page initialization, leading to two regressions: 1) very slow scrolling after page initialization, 2) kernel hang when the 'keep_bootcon' command line argument is passed. Putting the tweak back fixes #2 and mitigates #1, i.e., it limits the slow behavior to the early boot stages, presumably due to eliminating heavy map()/unmap() operations per each pixel line on the screen. [ ardb: ensure efifb is unmapped again unless keep_bootcon is in effect. ] [ mingo: speling fixes. ] Signed-off-by: Andy Shevchenko Signed-off-by: Ard Biesheuvel Cc: Arvind Sankar Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Fixes: 69c1f396f25b ("efi/x86: Convert x86 EFI earlyprintk into generic earlycon implementation") Link: https://lkml.kernel.org/r/20191206165542.31469-7-ardb@kernel.org Signed-off-by: Ingo Molnar

efi/gop: Fix memory leak in __gop_query32/64()

2019-12-08T11:42:18Z

efi_graphics_output_protocol::query_mode() returns info in callee-allocated memory which must be freed by the caller, which we aren't doing. We don't actually need to call query_mode() in order to obtain the info for the current graphics mode, which is already there in gop->mode->info, so just access it directly in the setup_gop32/64() functions. Also nothing uses the size of the info structure, so don't update the passed-in size (which is the size of the gop_handle table in bytes) unnecessarily. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-5-ardb@kernel.org Signed-off-by: Ingo Molnar

efi/gop: Return EFI_SUCCESS if a usable GOP was found

2019-12-08T11:42:18Z

If we've found a usable instance of the Graphics Output Protocol (GOP) with a framebuffer, it is possible that one of the later EFI calls fails while checking if any support console output. In this case status may be an EFI error code even though we found a usable GOP. Fix this by explicitly return EFI_SUCCESS if a usable GOP has been located. Signed-off-by: Arvind Sankar Signed-off-by: Ard Biesheuvel Cc: Andy Shevchenko Cc: Bhupesh Sharma Cc: Masayoshi Mizuma Cc: linux-efi@vger.kernel.org Link: https://lkml.kernel.org/r/20191206165542.31469-4-ardb@kernel.org Signed-off-by: Ingo Molnar