aboutsummaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)AuthorFilesLines
2020-05-20firmware: arm_sdei: Document the motivation behind these set_fs() callsJames Morse1-0/+8
The SDEI handler save/restores the addr_limit using set_fs(). It isn't very clear why. The reason is to mirror the arch code's entry assembly. The arch code does this because perf may access user-space, and inheriting the addr_limit may be a problem. Add a comment explaining why this is here. Suggested-by: Christoph Hellwig <[email protected]> Signed-off-by: James Morse <[email protected]> Link: https://bugs.chromium.org/p/project-zero/issues/detail?id=822 Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-05-20firmware: arm_sdei: remove unused interfacesChristoph Hellwig1-4/+0
The export symbols to register/unregister and enable/disable events aren't used upstream, remove them. [ dropped the parts of Christoph's patch that made the API static too ] Signed-off-by: Christoph Hellwig <[email protected]> Signed-off-by: James Morse <[email protected]> Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-05-20firmware: arm_sdei: Put the SDEI table after using itHanjun Guo1-0/+2
The acpi_get_table() should be coupled with acpi_put_table() if the mapped table is not used for runtime after the initialization to release the table mapping, put the SDEI table after using it. Signed-off-by: Hanjun Guo <[email protected]> Signed-off-by: James Morse <[email protected]> Link: https://lore.kernel.org/linux-arm-kernel/[email protected]/ Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-05-20firmware: imx: scu: Fix possible memory leak in imx_scu_probe()Wei Yongjun1-0/+1
'chan_name' is malloced in imx_scu_probe() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support") Signed-off-by: Wei Yongjun <[email protected]> Reviewed-by: Dong Aisheng <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-05-19ARM: decompressor: run decompressor in place if loaded via UEFIArd Biesheuvel1-39/+6
The decompressor can load from anywhere in memory, and the only reason the EFI stub code relocates it is to ensure it appears within the first 128 MiB of memory, so that the uncompressed kernel ends up at the right offset in memory. We can short circuit this, and simply jump into the decompressor startup code at the point where it knows where the base of memory lives. This also means there is no need to disable the MMU and caches, create new page tables and re-enable them. Signed-off-by: Ard Biesheuvel <[email protected]> Reviewed-by: Nicolas Pitre <[email protected]>
2020-05-19efi/printf: Turn vsprintf into vsnprintfArvind Sankar2-18/+30
Implement vsnprintf instead of vsprintf to avoid the possibility of a buffer overflow. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Abort on invalid formatArvind Sankar1-6/+8
If we get an invalid conversion specifier, bail out instead of trying to fix it up. The format string likely has a typo or assumed we support something that we don't, in either case the remaining arguments won't match up with the remaining format string. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Refactor code to consolidate padding and outputArvind Sankar1-126/+148
Consolidate the actual output of the formatted text into one place. Fix a couple of edge cases: 1. If 0 is printed with a precision of 0, the printf specification says that nothing should be output, with one exception (2b). 2. The specification for octal alternate format (%#o) adds the leading zero not as a prefix as the 0x for hexadecimal is, but by increasing the precision if necessary to add the zero. This means that a. %#.2o turns 8 into "010", but 1 into "01" rather than "001". b. %#.o prints 0 as "0" rather than "", unlike the situation for decimal, hexadecimal and regular octal format, which all output an empty string. Reduce the space allocated for printing a number to the maximum actually required (22 bytes for a 64-bit number in octal), instead of the 66 bytes previously allocated. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Handle null string inputArvind Sankar1-0/+5
Print "(null)" for 's' if the input is a NULL pointer. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Factor out integer argument retrievalArvind Sankar1-33/+33
Factor out the code to get the correct type of numeric argument into a helper function. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Factor out width/precision parsingArvind Sankar1-21/+40
Factor out the width/precision parsing into a helper function. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Merge 'p' with the integer formatsArvind Sankar1-14/+8
Treat 'p' as a hexadecimal integer with precision equal to the number of digits in void *. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Fix minor bug in precision handlingArvind Sankar1-2/+4
A negative precision should be ignored completely, and the presence of a valid precision should turn off the 0 flag. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Factor out flags parsing and handle '%' earlierArvind Sankar1-25/+31
Move flags parsing code out into a helper function. The '%%' case can be handled up front: it is not allowed to have flags, width etc. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Add 64-bit and 8-bit integer supportArvind Sankar1-27/+143
Support 'll' qualifier for long long by copying the decimal printing code from lib/vsprintf.c. For simplicity, the 32-bit code is used on 64-bit architectures as well. Support 'hh' qualifier for signed/unsigned char type integers. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/printf: Drop %n format and L qualifierArvind Sankar1-12/+2
%n is unused and deprecated. The L qualifer is parsed but not actually implemented. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/libstub: Optimize for size instead of speedArvind Sankar1-2/+2
Reclaim the bloat from the addition of printf by optimizing the stub for size. With gcc 9, the text size of the stub is: ARCH before +printf -Os arm 35197 37889 34638 arm64 34883 38159 34479 i386 18571 21657 17025 x86_64 25677 29328 22144 Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/libstub: Add a basic printf implementationArvind Sankar4-1/+320
Copy vsprintf from arch/x86/boot/printf.c to get a simple printf implementation. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] [ardb: add some missing braces in if...else clauses] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/libstub: Buffer output of efi_putsArvind Sankar1-6/+13
Use a buffer to convert the string to UTF-16. This will reduce the number of firmware calls required to print the string from one per character to one per string in most cases. Cast the input char to unsigned char before converting to efi_char16_t to avoid sign-extension in case there are any non-ASCII characters in the input. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/libstub: Rename efi_[char16_]printk to efi_[char16_]putsArvind Sankar3-16/+16
These functions do not support formatting, unlike printk. Rename them to puts to make that clear. Move the implementations of these two functions next to each other. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-19efi/libstub: Include dependencies of efistub.hArvind Sankar1-0/+5
Add #include directives for include files that efistub.h depends on, instead of relying on them having been included by the C source files prior to efistub.h. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-17tpm: check event log version before reading final eventsLoïc Yhuel2-3/+7
This fixes the boot issues since 5.3 on several Dell models when the TPM is enabled. Depending on the exact grub binary, booting the kernel would freeze early, or just report an error parsing the final events log. We get an event log in the SHA-1 format, which doesn't have a tcg_efi_specid_event_head in the first event, and there is a final events table which doesn't match the crypto agile format. __calc_tpm2_event_size reads bad "count" and "efispecid->num_algs", and either fails, or loops long enough for the machine to be appear frozen. So we now only parse the final events table, which is per the spec always supposed to be in the crypto agile format, when we got a event log in this format. Fixes: c46f3405692de ("tpm: Reserve the TPM final events table") Fixes: 166a2809d65b2 ("tpm: Don't duplicate events from the final event log in the TCG2 log") Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1779611 Signed-off-by: Loïc Yhuel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Reviewed-by: Javier Martinez Canillas <[email protected]> Reviewed-by: Jerry Snitselaar <[email protected]> Reviewed-by: Matthew Garrett <[email protected]> [ardb: warn when final events table is missing or in the wrong format] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-17efi: Pull up arch-specific prototype efi_systab_show_arch()Benjamin Thiel1-4/+1
Pull up arch-specific prototype efi_systab_show_arch() in order to fix a -Wmissing-prototypes warning: arch/x86/platform/efi/efi.c:957:7: warning: no previous prototype for ‘efi_systab_show_arch’ [-Wmissing-prototypes] char *efi_systab_show_arch(char *str) Signed-off-by: Benjamin Thiel <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-15Merge tag 'tegra-for-5.8-arm-core' of ↵Arnd Bergmann2-8/+22
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/soc ARM: tegra: Core changes for v5.8-rc1 This contains core changes needed for the CPU frequency scaling and CPU idle drivers on Tegra20 and Tegra30. * tag 'tegra-for-5.8-arm-core' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: ARM: tegra: Create tegra20-cpufreq platform device on Tegra30 ARM: tegra: Don't enable PLLX while resuming from LP1 on Tegra30 ARM: tegra: Switch CPU to PLLP on resume from LP1 on Tegra30/114/124 ARM: tegra: Correct PL310 Auxiliary Control Register initialization ARM: tegra: Do not fully reinitialize L2 on resume ARM: tegra: Initialize r0 register for firmware wake-up firmware: tf: Different way of L2 cache enabling after LP2 suspend firmware: tegra: Make BPMP a regular driver Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Arnd Bergmann <[email protected]>
2020-05-15efi/libstub: Disable Shadow Call StackSami Tolvanen1-0/+3
Shadow stacks are not available in the EFI stub, filter out SCS flags. Suggested-by: James Morse <[email protected]> Signed-off-by: Sami Tolvanen <[email protected]> Reviewed-by: Kees Cook <[email protected]> Acked-by: Ard Biesheuvel <[email protected]> Signed-off-by: Will Deacon <[email protected]>
2020-05-15firmware: xilinx: Fix an error handling path in 'zynqmp_firmware_probe()'Christophe JAILLET1-2/+2
If 'mfd_add_devices()' fails, we must undo 'zynqmp_pm_api_debugfs_init()' otherwise some debugfs directory and files will be left. Just move the call to 'zynqmp_pm_api_debugfs_init()' a few lines below to fix the issue. Fixes: e23d9c6d0d49 ("drivers: soc: xilinx: Add ZynqMP power domain driver") Signed-off-by: Christophe JAILLET <[email protected]> Reviewed-by: Jolly Shah <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-14efi: cper: Add support for printing Firmware Error Record ReferencePunit Agrawal1-0/+62
While debugging a boot failure, the following unknown error record was seen in the boot logs. <...> BERT: Error records from previous boot: [Hardware Error]: event severity: fatal [Hardware Error]: Error 0, type: fatal [Hardware Error]: section type: unknown, 81212a96-09ed-4996-9471-8d729c8e69ed [Hardware Error]: section length: 0x290 [Hardware Error]: 00000000: 00000001 00000000 00000000 00020002 ................ [Hardware Error]: 00000010: 00020002 0000001f 00000320 00000000 ........ ....... [Hardware Error]: 00000020: 00000000 00000000 00000000 00000000 ................ [Hardware Error]: 00000030: 00000000 00000000 00000000 00000000 ................ <...> On further investigation, it was found that the error record with UUID (81212a96-09ed-4996-9471-8d729c8e69ed) has been defined in the UEFI Specification at least since v2.4 and has recently had additional fields defined in v2.7 Section N.2.10 Firmware Error Record Reference. Add support for parsing and printing the defined fields to give users a chance to figure out what went wrong. Signed-off-by: Punit Agrawal <[email protected]> Cc: Ard Biesheuvel <[email protected]> Cc: "Rafael J. Wysocki" <[email protected]> Cc: Borislav Petkov <[email protected]> Cc: James Morse <[email protected]> Cc: [email protected] Cc: [email protected] Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-14efi/libstub/x86: Avoid EFI map buffer alloc in allocate_e820()Lenny Szubowicz3-17/+22
In allocate_e820(), call the EFI get_memory_map() service directly instead of indirectly via efi_get_memory_map(). This avoids allocation of a buffer and return of the full EFI memory map, which is not needed here and would otherwise need to be freed. Routine allocate_e820() only needs to know how many EFI memory descriptors there are in the map to allocate an adequately sized e820ext buffer, if it's needed. Note that since efi_get_memory_map() returns a memory map buffer sized with extra headroom, allocate_e820() now needs to explicitly factor that into the e820ext size calculation. Signed-off-by: Lenny Szubowicz <[email protected]> Suggested-by: Ard Biesheuvel <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-13USB: pci-quirks: Add Raspberry Pi 4 quirkNicolas Saenz Julienne1-1/+2
On the Raspberry Pi 4, after a PCI reset, VL805's firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's VideoCore. Inform VideoCore that VL805 was just reset. Also, as this creates a dependency between USB_PCI and VideoCore's firmware interface, and since USB_PCI can't be set as a module neither this can. Reflect that on the firmware interface Kconfg. Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]> Acked-by: Mathias Nyman <[email protected]>
2020-05-13firmware: raspberrypi: Introduce vl805 init routineNicolas Saenz Julienne1-0/+61
The Raspberry Pi 4 gets its USB functionality from VL805, a PCIe chip that implements xHCI. After a PCI reset, VL805's firmware may either be loaded directly from an EEPROM or, if not present, by the SoC's co-processor, VideoCore. RPi4's VideoCore OS contains both the non public firmware load logic and the VL805 firmware blob. The function this patch introduces triggers the aforementioned process. Link: https://lore.kernel.org/r/[email protected] Tested-by: Stefan Wahren <[email protected]> Tested-by: Stefan Wahren <[email protected]> Signed-off-by: Nicolas Saenz Julienne <[email protected]> Signed-off-by: Lorenzo Pieralisi <[email protected]> Reviewed-by: Rob Herring <[email protected]>
2020-05-13dt-bindings: firmware: imx: Move system control into dt-binding headfileDong Aisheng1-1/+0
i.MX8 SoCs DTS file needs system control macro definitions, so move them into dt-binding headfile, then include/linux/firmware/imx/types.h can be removed and those drivers using it should be changed accordingly. Signed-off-by: Dong Aisheng <[email protected]> Signed-off-by: Jacky Bai <[email protected]> Signed-off-by: Anson Huang <[email protected]> Signed-off-by: Shawn Guo <[email protected]>
2020-05-12firmware: qcom_scm-legacy: Replace zero-length array with flexible-arrayGustavo A. R. Silva1-1/+1
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99: struct foo { int stuff; struct boo array[]; }; By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on. Also, notice that, dynamic memory allocations won't be affected by this change: "Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1] sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues. This issue was found with the help of Coccinelle. [1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html [2] https://github.com/KSPP/linux/issues/21 [3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour") Reviewed-by: Jeffrey Hugo <[email protected]> Signed-off-by: Gustavo A. R. Silva <[email protected]> Link: https://lore.kernel.org/r/20200508210805.GA24170@embeddedor Signed-off-by: Bjorn Andersson <[email protected]>
2020-05-12efi/earlycon: Fix early printk for wider fontsDave Young1-6/+8
When I play with terminus fonts I noticed the efi early printk does not work because the earlycon code assumes font width is 8. Here add the code to adapt with larger fonts. Tested with all kinds of kernel built-in fonts on my laptop. Also tested with a local draft patch for 14x28 !bold terminus font. Signed-off-by: Dave Young <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-11Merge 5.7-rc5 into char-misc-nextGreg Kroah-Hartman1-1/+1
We want the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-09gcc-10: mark more functions __init to avoid section mismatch warningsLinus Torvalds1-1/+1
It seems that for whatever reason, gcc-10 ends up not inlining a couple of functions that used to be inlined before. Even if they only have one single callsite - it looks like gcc may have decided that the code was unlikely, and not worth inlining. The code generation difference is harmless, but caused a few new section mismatch errors, since the (now no longer inlined) function wasn't in the __init section, but called other init functions: Section mismatch in reference from the function kexec_free_initrd() to the function .init.text:free_initrd_mem() Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memremap() Section mismatch in reference from the function tpm2_calc_event_log_size() to the function .init.text:early_memunmap() So add the appropriate __init annotation to make modpost not complain. In both cases there were trivially just a single callsite from another __init function. Signed-off-by: Linus Torvalds <[email protected]>
2020-05-07firmware: arm_scmi: fix psci dependencySudeep Holla2-2/+2
When CONFIG_ARM_PSCI_FW is disabled but CONFIG_HAVE_ARM_SMCCC is enabled, arm-scmi runs into a link failure: arm-linux-gnueabi-ld: drivers/firmware/arm_scmi/smc.o: in function `smc_send_message': smc.c:(.text+0x200): undefined reference to `arm_smccc_1_1_get_conduit' Change from HAVE_ARM_SMCCC to ARM_PSCI_FW config dependency for now. We rely on PSCI bindings anyways for the conduit and this should be fine. Link: https://lore.kernel.org/r/[email protected] Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Signed-off-by: Sudeep Holla <[email protected]>
2020-05-06firmware: tf: Different way of L2 cache enabling after LP2 suspendDmitry Osipenko1-2/+19
ASUS TF300T device may not work properly if firmware is asked to fully re-initialize L2 cache after resume from LP2 suspend. The downstream kernel of TF300T uses different opcode to enable cache after resuming from LP2, this opcode also works fine on Nexus 7 and Ouya devices. Supposedly, this may be needed by an older firmware versions. Reported-by: Michał Mirosław <[email protected]> Tested-by: Michał Mirosław <[email protected]> Tested-by: Jasper Korten <[email protected]> Tested-by: David Heidelberg <[email protected]> Tested-by: Peter Geis <[email protected]> Signed-off-by: Dmitry Osipenko <[email protected]> Signed-off-by: Thierry Reding <[email protected]>
2020-05-06efi/libstub: Correct comment typosJoe Perches2-2/+2
Fix a couple typos in comments. Signed-off-by: Joe Perches <[email protected]> Link: https://lore.kernel.org/r/ec53e67b3ac928922807db3cb1585e911971dadc.1588273612.git.joe@perches.com Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-05efi/libstub: Make efi_printk() input argument const char*Ard Biesheuvel2-13/+8
To help the compiler figure out that efi_printk() will not modify the string it is given, make the input argument type const char*. While at it, simplify the implementation as well. Suggested-by: Joe Perches <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-05efi/libstub/x86: Work around LLVM ELF quirk build regressionArd Biesheuvel1-0/+1
When building the x86 EFI stub with Clang, the libstub Makefile rules that manipulate the ELF object files may throw an error like: STUBCPY drivers/firmware/efi/libstub/efi-stub-helper.stub.o strip: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 objcopy: drivers/firmware/efi/libstub/efi-stub-helper.stub.o: Failed to find link section for section 10 This is the result of a LLVM feature [0] where symbol references are stored in a LLVM specific .llvm_addrsig section in a non-transparent way, causing generic ELF tools such as strip or objcopy to choke on them. So force the compiler not to emit these sections, by passing the appropriate command line option. [0] https://sourceware.org/bugzilla/show_bug.cgi?id=23817 Cc: Nick Desaulniers <[email protected]> Cc: Peter Collingbourne <[email protected]> Cc: Sami Tolvanen <[email protected]> Reported-by: Arnd Bergmann <[email protected]> Suggested-by: Fangrui Song <[email protected]> Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-05efi/libstub: Fix mixed mode boot issue after macro refactorArvind Sankar1-10/+4
Commit 22090f84bc3f ("efi/libstub: unify EFI call wrappers for non-x86") refactored the macros that are used to provide wrappers for mixed-mode calls on x86, allowing us to boot a 64-bit kernel on 32-bit firmware. Unfortunately, this broke mixed mode boot due to the fact that efi_is_native() is not a macro on x86. All of these macros should go together, so rather than testing each one to see if it is defined, condition the generic macro definitions on a new ARCH_HAS_EFISTUB_WRAPPERS, and remove the wrapper definitions on x86 as well if CONFIG_EFI_MIXED is not enabled. Fixes: 22090f84bc3f ("efi/libstub: unify EFI call wrappers for non-x86") Reported-by: Guenter Roeck <[email protected]> Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-04firmware: arm_sdei: Drop check for /firmware/ node and always register driverSudeep Holla1-25/+12
As with most of the drivers, let us register this driver unconditionally by dropping the checks for presence of firmware nodes(DT) or entries(ACPI). Further, as mentioned in the commit acafce48b07b ("firmware: arm_sdei: Fix DT platform device creation"), the core takes care of creation of platform device when the appropriate device node is found and probe is called accordingly. Let us check only for the presence of ACPI firmware entry before creating the platform device and flag warning if we fail. Signed-off-by: Sudeep Holla <[email protected]> Reviewed-by: James Morse <[email protected]> Cc: James Morse <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Will Deacon <[email protected]>
2020-05-04firmware: xilinx: Export zynqmp_pm_fpga_{get_status,load}Nathan Chancellor1-0/+2
When building arm64 allmodconfig: ERROR: modpost: "zynqmp_pm_fpga_load" [drivers/fpga/zynqmp-fpga.ko] undefined! ERROR: modpost: "zynqmp_pm_fpga_get_status" [drivers/fpga/zynqmp-fpga.ko] undefined! These functions were added to drivers/fpga/zynqmp-fpga.c but not exported so the module build breaks. Export them so that they can be used in modules properly. Fixes: 4db8180ffe7c ("firmware: xilinx: Remove eemi ops for fpga related APIs") Signed-off-by: Nathan Chancellor <[email protected]> Reported-by: "kernelci.org bot" <[email protected]> Reported-by: Stephen Rothwell <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Greg Kroah-Hartman <[email protected]>
2020-05-01efi/libstub: Check return value of efi_parse_optionsArvind Sankar2-8/+27
efi_parse_options can fail if it is unable to allocate space for a copy of the command line. Check the return value to make sure it succeeded. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/x86: Support builtin command lineArvind Sankar1-4/+8
Add support for the x86 CMDLINE_BOOL and CMDLINE_OVERRIDE configuration options. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/libstub: Unify initrd loading across architecturesArvind Sankar4-40/+52
Factor out the initrd loading into a common function that can be called both from the generic efi-stub.c and the x86-specific x86-stub.c. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/x86: Move command-line initrd loading to efi_mainArvind Sankar1-39/+25
Consolidate the initrd loading in efi_main. The command line options now need to be parsed only once. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/libstub: Upgrade ignored dtb= argument message to errorArvind Sankar1-1/+1
Use efi_err if we ignore a command-line dtb= argument, so that it shows up even on a quiet boot. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/tpm: Use efi_err for error messagesArvind Sankar1-1/+1
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>
2020-05-01efi/gop: Use efi_err for error messagesArvind Sankar1-5/+5
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Ard Biesheuvel <[email protected]>