summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2020-05-19efi/printf: Drop %n format and L qualifierArvind Sankar
%n is unused and deprecated. The L qualifer is parsed but not actually implemented. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-7-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Optimize for size instead of speedArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-6-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Add a basic printf implementationArvind Sankar
Copy vsprintf from arch/x86/boot/printf.c to get a simple printf implementation. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-5-nivedita@alum.mit.edu [ardb: add some missing braces in if...else clauses] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Buffer output of efi_putsArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Rename efi_[char16_]printk to efi_[char16_]putsArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-19efi/libstub: Include dependencies of efistub.hArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200518190716.751506-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-17tpm: check event log version before reading final eventsLoïc Yhuel
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 <loic.yhuel@gmail.com> Link: https://lore.kernel.org/r/20200512040113.277768-1-loic.yhuel@gmail.com Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Reviewed-by: Jerry Snitselaar <jsnitsel@redhat.com> Reviewed-by: Matthew Garrett <mjg59@google.com> [ardb: warn when final events table is missing or in the wrong format] Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-17efi: Pull up arch-specific prototype efi_systab_show_arch()Benjamin Thiel
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 <b.thiel@posteo.de> Link: https://lore.kernel.org/r/20200516132647.14568-1-b.thiel@posteo.de Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-15Merge tag 'tegra-for-5.8-arm-core' of ↵Arnd Bergmann
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/20200515145311.1580134-10-thierry.reding@gmail.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2020-05-15efi/libstub: Disable Shadow Call StackSami Tolvanen
Shadow stacks are not available in the EFI stub, filter out SCS flags. Suggested-by: James Morse <james.morse@arm.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Will Deacon <will@kernel.org>
2020-05-15firmware: xilinx: Fix an error handling path in 'zynqmp_firmware_probe()'Christophe JAILLET
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 <christophe.jaillet@wanadoo.fr> Reviewed-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/20200510130357.233364-1-christophe.jaillet@wanadoo.fr Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-14efi: cper: Add support for printing Firmware Error Record ReferencePunit Agrawal
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 <punit1.agrawal@toshiba.co.jp> Cc: Ard Biesheuvel <ardb@kernel.org> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Cc: Borislav Petkov <bp@alien8.de> Cc: James Morse <james.morse@arm.com> Cc: linux-acpi@vger.kernel.org Cc: linux-efi@vger.kernel.org Link: https://lore.kernel.org/r/20200512045502.3810339-1-punit1.agrawal@toshiba.co.jp Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-14efi/libstub/x86: Avoid EFI map buffer alloc in allocate_e820()Lenny Szubowicz
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 <lszubowi@redhat.com> Suggested-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-13USB: pci-quirks: Add Raspberry Pi 4 quirkNicolas Saenz Julienne
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/20200505161318.26200-5-nsaenzjulienne@suse.de Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Mathias Nyman <mathias.nyman@linux.intel.com>
2020-05-13firmware: raspberrypi: Introduce vl805 init routineNicolas Saenz Julienne
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/20200505161318.26200-3-nsaenzjulienne@suse.de Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Rob Herring <robh@kernel.org>
2020-05-13dt-bindings: firmware: imx: Move system control into dt-binding headfileDong Aisheng
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 <aisheng.dong@nxp.com> Signed-off-by: Jacky Bai <ping.bai@nxp.com> Signed-off-by: Anson Huang <Anson.Huang@nxp.com> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2020-05-12firmware: qcom_scm-legacy: Replace zero-length array with flexible-arrayGustavo A. R. Silva
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 <jhugo@codeaurora.org> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org> Link: https://lore.kernel.org/r/20200508210805.GA24170@embeddedor Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-05-12efi/earlycon: Fix early printk for wider fontsDave Young
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 <dyoung@redhat.com> Link: https://lore.kernel.org/r/20200412024927.GA6884@dhcp-128-65.nay.redhat.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-11Merge 5.7-rc5 into char-misc-nextGreg Kroah-Hartman
We want the char-misc fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-09gcc-10: mark more functions __init to avoid section mismatch warningsLinus Torvalds
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 <torvalds@linux-foundation.org>
2020-05-07firmware: arm_scmi: fix psci dependencySudeep Holla
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/20200507144905.11397-1-sudeep.holla@arm.com Fixes: 1dc6558062da ("firmware: arm_scmi: Add smc/hvc transport") Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2020-05-06firmware: tf: Different way of L2 cache enabling after LP2 suspendDmitry Osipenko
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 <mirq-linux@rere.qmqm.pl> Tested-by: Michał Mirosław <mirq-linux@rere.qmqm.pl> Tested-by: Jasper Korten <jja2000@gmail.com> Tested-by: David Heidelberg <david@ixit.cz> Tested-by: Peter Geis <pgwipeout@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2020-05-06efi/libstub: Correct comment typosJoe Perches
Fix a couple typos in comments. Signed-off-by: Joe Perches <joe@perches.com> Link: https://lore.kernel.org/r/ec53e67b3ac928922807db3cb1585e911971dadc.1588273612.git.joe@perches.com Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-05efi/libstub: Make efi_printk() input argument const char*Ard Biesheuvel
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 <joe@perches.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-05efi/libstub/x86: Work around LLVM ELF quirk build regressionArd Biesheuvel
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 <ndesaulniers@google.com> Cc: Peter Collingbourne <pcc@google.com> Cc: Sami Tolvanen <samitolvanen@google.com> Reported-by: Arnd Bergmann <arnd@arndb.de> Suggested-by: Fangrui Song <maskray@google.com> Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-05efi/libstub: Fix mixed mode boot issue after macro refactorArvind Sankar
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 <linux@roeck-us.net> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200504150248.62482-1-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-04firmware: arm_sdei: Drop check for /firmware/ node and always register driverSudeep Holla
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 <sudeep.holla@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Cc: James Morse <james.morse@arm.com> Link: https://lore.kernel.org/r/20200422122823.1390-1-sudeep.holla@arm.com Signed-off-by: Will Deacon <will@kernel.org>
2020-05-04firmware: xilinx: Export zynqmp_pm_fpga_{get_status,load}Nathan Chancellor
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 <natechancellor@gmail.com> Reported-by: "kernelci.org bot" <bot@kernelci.org> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Link: https://lore.kernel.org/r/20200502025958.2714249-1-natechancellor@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-05-01efi/libstub: Check return value of efi_parse_optionsArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-12-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Support builtin command lineArvind Sankar
Add support for the x86 CMDLINE_BOOL and CMDLINE_OVERRIDE configuration options. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-11-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Unify initrd loading across architecturesArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-10-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Move command-line initrd loading to efi_mainArvind Sankar
Consolidate the initrd loading in efi_main. The command line options now need to be parsed only once. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-9-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Upgrade ignored dtb= argument message to errorArvind Sankar
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 <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-8-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/tpm: Use efi_err for error messagesArvind Sankar
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-7-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/gop: Use efi_err for error messagesArvind Sankar
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-6-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Use efi_err for error messagesArvind Sankar
Use efi_err instead of bare efi_printk for error messages. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-5-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Move pr_efi/pr_efi_err into efi namespaceArvind Sankar
Rename pr_efi to efi_info and pr_efi_err to efi_err to make it more obvious that they are part of the EFI stub and not generic printk infra. Suggested-by: Joe Perches <joe@perches.com> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-4-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/libstub: Add a helper function to split 64-bit valuesArvind Sankar
In several places 64-bit values need to be split up into two 32-bit fields, in order to be backward-compatible with the old 32-bit ABIs. Instead of open-coding this, add a helper function to set a 64-bit value as two 32-bit fields. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-3-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-05-01efi/x86: Use correct size for boot_paramsArvind Sankar
struct boot_params is only 4096 bytes, not 16384. Fix this by using sizeof(struct boot_params) instead of hardcoding the incorrect value. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Link: https://lore.kernel.org/r/20200430182843.2510180-2-nivedita@alum.mit.edu Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-30efi/libstub: Avoid returning uninitialized data from setup_graphics()Heinrich Schuchardt
Currently, setup_graphics() ignores the return value of efi_setup_gop(). As AllocatePool() does not zero out memory, the screen information table will contain uninitialized data in this case. We should free the screen information table if efi_setup_gop() returns an error code. Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de> Link: https://lore.kernel.org/r/20200426194946.112768-1-xypron.glpk@gmx.de Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
2020-04-28firmware: xilinx: Add sysfs and API to set boot health statusRajan Vaja
Add sysfs interface to set boot health status from user space. Add API used by this interface to communicate with firmware. If PMUFW is compiled with CHECK_HEALTHY_BOOT, it will check the healthy bit on FPD WDT expiration. If healthy bit is set by a user application running in Linux, PMUFW will do APU only restart. If healthy bit is not set during FPD WDT expiration, PMUFW will do system restart. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-26-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Add sysfs to set shutdown scopeRajan Vaja
The Linux shutdown functionality implemented via PSCI system_off does not include an option to set a scope, i.e. which parts of the system to shut down. This patch creates sysfs that allows to set the shutdown scope for the next shutdown request. When the next shutdown is performed, the platform specific portion of PSCI-system_off can use the chosen shutdown scope. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Stefan Krsmanovic <stefan.krsmanovic@aggios.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-25-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Add system shutdown API interfaceRajan Vaja
Add system shutdown API interface which asks firmware to perform system shutdown/restart. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-24-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Add sysfs interfaceRajan Vaja
Add firmware-ggs sysfs interface which provides read/write interface to global storage registers. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com> Signed-off-by: Tejas Patel <tejas.patel@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-23-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Add APIs to read/write GGS/PGGS registersRajan Vaja
Add APIs to read/write PGGS and GGS registers. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-22-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for fpga related APIsRajan Vaja
Use direct function call instead of using eemi ops for fpga related APIs. Also remove eemi ops structure. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-21-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for aes engineRajan Vaja
Use direct function call for aes engine instead of using eemi ops. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-20-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for set_requirementRajan Vaja
Use direct function call instead of using eemi ops for set_requirement. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-19-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for release_nodeRajan Vaja
Use direct function call instead of using eemi ops for release_node. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-18-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-28firmware: xilinx: Remove eemi ops for request_nodeRajan Vaja
Use direct function call instead of using eemi ops for request_node. Signed-off-by: Rajan Vaja <rajan.vaja@xilinx.com> Signed-off-by: Jolly Shah <jolly.shah@xilinx.com> Link: https://lore.kernel.org/r/1587761887-4279-17-git-send-email-jolly.shah@xilinx.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2025-08-03 06:17:19 +0000