summaryrefslogtreecommitdiffstats
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2017-07-03Merge branch 'efi-core-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI updates from Ingo Molnar: "The main changes in this cycle were: - Rework the EFI capsule loader to allow for workarounds for non-compliant firmware (Ard Biesheuvel) - Implement a capsule loader quirk for Quark X102x (Jan Kiszka) - Enable SMBIOS/DMI support for the ARM architecture (Ard Biesheuvel) - Add CONFIG_EFI_PGT_DUMP=y support for x86-32 and kexec (Sai Praneeth) - Fixes for EFI support for Xen dom0 guests running under x86-64 hosts (Daniel Kiper)" * 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/xen/efi: Initialize only the EFI struct members used by Xen efi: Process the MEMATTR table only if EFI_MEMMAP is enabled efi/arm: Enable DMI/SMBIOS x86/efi: Extend CONFIG_EFI_PGT_DUMP support to x86_32 and kexec as well efi/efi_test: Use memdup_user() helper efi/capsule: Add support for Quark security header efi/capsule-loader: Use page addresses rather than struct page pointers efi/capsule-loader: Redirect calls to efi_capsule_setup_info() via weak alias efi/capsule: Remove NULL test on kmap() efi/capsule-loader: Use a cached copy of the capsule header efi/capsule: Adjust return type of efi_capsule_setup_info() efi/capsule: Clean up pr_err/_info() messages efi/capsule: Remove pr_debug() on ENOMEM or EFAULT efi/capsule: Fix return code on failing kmap/vmap
2017-06-23efi: Process the MEMATTR table only if EFI_MEMMAP is enabledDaniel Kiper
Otherwise e.g. Xen dom0 on x86_64 EFI platforms crashes. In theory we can check EFI_PARAVIRT too, however, EFI_MEMMAP looks more targeted and covers more cases. Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: andrew.cooper3@citrix.com Cc: boris.ostrovsky@oracle.com Cc: jgross@suse.com Cc: linux-efi@vger.kernel.org Cc: matt@codeblueprint.co.uk Cc: stable@vger.kernel.org Cc: xen-devel@lists.xenproject.org Link: http://lkml.kernel.org/r/1498128697-12943-2-git-send-email-daniel.kiper@oracle.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-22trace, ras: add ARM processor error trace eventTyler Baicar
Currently there are trace events for the various RAS errors with the exception of ARM processor type errors. Add a new trace event for such errors so that the user will know when they occur. These trace events are consistent with the ARM processor error section type defined in UEFI 2.6 spec section N.2.4.4. Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org> Acked-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Xie XiuQi <xiexiuqi@huawei.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-06-22efi: print unrecognized CPER sectionTyler Baicar
UEFI spec allows for non-standard section in Common Platform Error Record. This is defined in section N.2.3 of UEFI version 2.5. Currently if the CPER section's type (UUID) does not match with one of the section types that the kernel knows how to parse, the section is skipped. Therefore, user is not able to see such CPER data, for instance, error record of non-standard section. This change prints out the raw data in hex in the dmesg buffer so that non-standard sections are reported to the user. Non-standard section type errors should be reported to the user because these can include errors which are vendor specific. The data length is taken from Error Data length field of Generic Error Data Entry. The following is a sample output from dmesg: Hardware error from APEI Generic Hardware Error Source: 2 It has been corrected by h/w and requires no further action event severity: corrected time: precise 2017-03-15 20:37:35 Error 0, type: corrected section type: unknown, d2e2621c-f936-468d-0d84-15a4ed015c8b section length: 0x238 00000000: 4d415201 4d492031 453a4d45 435f4343 .RAM1 IMEM:ECC_C 00000010: 53515f45 44525f42 00000000 00000000 E_QSB_RD........ 00000020: 00000000 00000000 00000000 00000000 ................ 00000030: 00000000 00000000 01010000 01010000 ................ 00000040: 00000000 00000000 00000005 00000000 ................ 00000050: 01010000 00000000 00000001 00dddd00 ................ ... The raw data from the error can then be decoded using vendor specific tools. Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org> Reviewed-by: James Morse <james.morse@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-06-22efi: parse ARM processor errorTyler Baicar
Add support for ARM Common Platform Error Record (CPER). UEFI 2.6 specification adds support for ARM specific processor error information to be reported as part of the CPER records. This provides more detail on for processor error logs. Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org> Reviewed-by: James Morse <james.morse@arm.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-06-22cper: add timestamp print to CPER status printingTyler Baicar
The ACPI 6.1 spec added a timestamp to the generic error data entry structure. Print the timestamp out when printing out the error information. Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-06-22ras: acpi/apei: cper: add support for generic data v3 structureTyler Baicar
The ACPI 6.1 spec adds a new revision of the generic error data entry structure. Add support to handle the new structure as well as properly verify and iterate through the generic data entries. Signed-off-by: Tyler Baicar <tbaicar@codeaurora.org> CC: Jonathan (Zhixiong) Zhang <zjzhang@codeaurora.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-06-20firmware/ivc: use dma_mapping_errorChristoph Hellwig
DMA_ERROR_CODE is not supposed to be used by drivers. Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Thierry Reding <treding@nvidia.com>
2017-06-18Merge tag 'tegra-for-4.13-firmware' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers firmware: tegra: Changes for v4.13-rc1 This contains a fix for missing semaphore release in error paths as well as a bogus error code return in the BPMP firmware implementation. * tag 'tegra-for-4.13-firmware' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: firmware: tegra: Fix locking bugs in BPMP Signed-off-by: Olof Johansson <olof@lixom.net>
2017-06-18Merge tag 'tegra-for-4.13-soc' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers soc/tegra: Changes for v4.13-rc1 This contains an implementation of generic PM domains for Tegra186, based on the BPMP powergate request. * tag 'tegra-for-4.13-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux: soc/tegra: flowctrl: Fix error handling soc/tegra: bpmp: Implement generic PM domains soc/tegra: bpmp: Update ABI header PM / Domains: Allow overriding the ->xlate() callback Signed-off-by: Olof Johansson <olof@lixom.net>
2017-06-18Merge tag 'scpi-updates-4.13' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers SCPI update for v4.13 Adds support to get DVFS transition latency and OPP for any device whose DVFS are managed by SCPI. This avoids code duplication in both cpufreq and devfreq SCPI drivers. * tag 'scpi-updates-4.13' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: cpufreq: scpi: use new scpi_ops functions to remove duplicate code firmware: arm_scpi: add support to populate OPPs and get transition latency Signed-off-by: Olof Johansson <olof@lixom.net>
2017-06-16Merge branch 'dmi-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging Pull dmi fixes from Jean Delvare. * 'dmi-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jdelvare/staging: firmware: dmi_scan: Check DMI structure length firmware: dmi: Fix permissions of product_family firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error codes firmware: dmi_scan: Look for SMBIOS 3 entry point first
2017-06-15firmware: dmi_scan: Check DMI structure lengthJean Delvare
Before accessing DMI data to record it for later, we should ensure that the DMI structures are large enough to contain the data in question. Signed-off-by: Jean Delvare <jdelvare@suse.de> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org>
2017-06-15firmware: dmi: Fix permissions of product_familyJean Delvare
This is not sensitive information like serial numbers, we can allow all users to read it. Fix odd alignment while we're here. Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: c61872c9833d ("firmware: dmi: Add DMI_PRODUCT_FAMILY identification string") Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Reviewed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org>
2017-06-15firmware: dmi_scan: Make dmi_walk and dmi_walk_early return real error codesAndy Lutomirski
Currently they return -1 on error, which will confuse callers if they try to interpret it as a normal negative error code. Signed-off-by: Andy Lutomirski <luto@kernel.org> Signed-off-by: Darren Hart (VMware) <dvhart@infradead.org> Signed-off-by: Jean Delvare <jdelvare@suse.de>
2017-06-15firmware: dmi_scan: Look for SMBIOS 3 entry point firstJean Delvare
Since version 3.0.0 of the SMBIOS specification, there can be multiple entry points in memory, pointing to one or two DMI tables. If both a 32-bit ("_SM_") entry point and a 64-bit ("_SM3_") entry point are present, the specification requires that the latter points to a table which is a super-set of the table pointed to by the former. Therefore we should give preference to the 64-bit ("_SM3_") entry point. However, currently the code is picking the first valid entry point it finds. Per specification, we should look for a 64-bit ("_SM3_") entry point first, and if we can't find any, look for a 32-bit ("_SM_" or "_DMI_") entry point. Modify the code to do that. Signed-off-by: Jean Delvare <jdelvare@suse.de>
2017-06-14firmware: tegra: Fix locking bugs in BPMPDan Carpenter
There are a bunch of error paths were we don't unlock the bpmp->threaded lock. Also if __tegra_bpmp_channel_write() fails then we returned success instead of an error code. Fixes: 983de5f97169 ("firmware: tegra: Add BPMP support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-06-13soc/tegra: bpmp: Implement generic PM domainsThierry Reding
The BPMP firmware, found on Tegra186 and later, provides an ABI that can be used to enable and disable power to several power partitions in Tegra SoCs. The ABI allows for enumeration of the available power partitions, so the driver can be reused on future generations, provided the BPMP ABI remains stable. Based on work by Stefan Kristiansson <stefank@nvidia.com> and Mikko Perttunen <mperttunen@nvidia.com>. Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-06-12Merge 4.12-rc5 into char-misc-nextGreg Kroah-Hartman
We want the char/misc driver fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-06-11Merge tag 'char-misc-4.12-rc5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver fixes from Greg KH: "Here are some small driver fixes for 4.12-rc5. Nothing major here, just some small bugfixes found by people testing, and a MAINTAINERS file update for the genwqe driver. All have been in linux-next with no reported issues" [ The cxl driver fix came in through the powerpc tree earlier ] * tag 'char-misc-4.12-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: cxl: Avoid double free_irq() for psl,slice interrupts mei: make sysfs modalias format similar as uevent modalias drivers: char: mem: Fix wraparound check to allow mappings up to the end MAINTAINERS: Change maintainer of genwqe driver goldfish_pipe: use GFP_ATOMIC under spin lock firmware: vpd: do not leak kobjects firmware: vpd: avoid potential use-after-free when destroying section firmware: vpd: do not leave freed section attributes to the list
2017-06-09efi: Fix boot panic because of invalid BGRT image addressDave Young
Maniaxx reported a kernel boot crash in the EFI code, which I emulated by using same invalid phys addr in code: BUG: unable to handle kernel paging request at ffffffffff280001 IP: efi_bgrt_init+0xfb/0x153 ... Call Trace: ? bgrt_init+0xbc/0xbc acpi_parse_bgrt+0xe/0x12 acpi_table_parse+0x89/0xb8 acpi_boot_init+0x445/0x4e2 ? acpi_parse_x2apic+0x79/0x79 ? dmi_ignore_irq0_timer_override+0x33/0x33 setup_arch+0xb63/0xc82 ? early_idt_handler_array+0x120/0x120 start_kernel+0xb7/0x443 ? early_idt_handler_array+0x120/0x120 x86_64_start_reservations+0x29/0x2b x86_64_start_kernel+0x154/0x177 secondary_startup_64+0x9f/0x9f There is also a similar bug filed in bugzilla.kernel.org: https://bugzilla.kernel.org/show_bug.cgi?id=195633 The crash is caused by this commit: 7b0a911478c7 efi/x86: Move the EFI BGRT init code to early init code The root cause is the firmware on those machines provides invalid BGRT image addresses. In a kernel before above commit BGRT initializes late and uses ioremap() to map the image address. Ioremap validates the address, if it is not a valid physical address ioremap() just fails and returns. However in current kernel EFI BGRT initializes early and uses early_memremap() which does not validate the image address, and kernel panic happens. According to ACPI spec the BGRT image address should fall into EFI_BOOT_SERVICES_DATA, see the section 5.2.22.4 of below document: http://www.uefi.org/sites/default/files/resources/ACPI_6_1.pdf Fix this issue by validating the image address in efi_bgrt_init(). If the image address does not fall into any EFI_BOOT_SERVICES_DATA areas we just bail out with a warning message. Reported-by: Maniaxx <tripleshiftone@gmail.com> Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code") Link: http://lkml.kernel.org/r/20170609084558.26766-2-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/arm: Enable DMI/SMBIOSArd Biesheuvel
Wire up the existing arm64 support for SMBIOS tables (aka DMI) for ARM as well, by moving the arm64 init code to drivers/firmware/efi/arm-runtime.c (which is shared between ARM and arm64), and adding a asm/dmi.h header to ARM that defines the mapping routines for the firmware tables. This allows userspace to access these tables to discover system information exposed by the firmware. It also sets the hardware name used in crash dumps, e.g.: Unable to handle kernel NULL pointer dereference at virtual address 00000000 pgd = ed3c0000 [00000000] *pgd=bf1f3835 Internal error: Oops: 817 [#1] SMP THUMB2 Modules linked in: CPU: 0 PID: 759 Comm: bash Not tainted 4.10.0-09601-g0e8f38792120-dirty #112 Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 ^^^ NOTE: This does *NOT* enable or encourage the use of DMI quirks, i.e., the the practice of identifying the platform via DMI to decide whether certain workarounds for buggy hardware and/or firmware need to be enabled. This would require the DMI subsystem to be enabled much earlier than we do on ARM, which is non-trivial. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Russell King <rmk+kernel@armlinux.org.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-14-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/efi_test: Use memdup_user() helperGeliang Tang
Use memdup_user() helper instead of open-coding to simplify the code. Signed-off-by: Geliang Tang <geliangtang@gmail.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Ivan Hu <ivan.hu@canonical.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-12-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule: Add support for Quark security headerJan Kiszka
The firmware for Quark X102x prepends a security header to the capsule which is needed to support the mandatory secure boot on this processor. The header can be detected by checking for the "_CSH" signature and - to avoid any GUID conflict - validating its size field to contain the expected value. Then we need to look for the EFI header right after the security header and pass the real header to __efi_capsule_setup_info. To be minimal invasive and maximal safe, the quirk version of efi_capsule_setup_info() is only effective on Quark processors. Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-11-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule-loader: Use page addresses rather than struct page pointersArd Biesheuvel
To give some leeway to code that handles non-standard capsule headers, let's keep an array of page addresses rather than struct page pointers. This gives special implementations of efi_capsule_setup_info() the opportunity to mangle the payload a bit before it is presented to the firmware, without putting any knowledge of the nature of such quirks into the generic code. Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-10-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule-loader: Redirect calls to efi_capsule_setup_info() via weak aliasArd Biesheuvel
To allow platform specific code to hook into the capsule loading routines, indirect calls to efi_capsule_setup_info() via a weak alias of __efi_capsule_setup_info(), allowing platforms to redefine the former but still use the latter. Tested-by: Bryan O'Donoghue <pure.logic@nexus-software.ie> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Matt Fleming <matt@codeblueprint.co.uk> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-9-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule: Remove NULL test on kmap()Fabian Frederick
kmap() can't fail. Signed-off-by: Fabian Frederick <fabf@skynet.be> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Kweh Hock Leong <hock.leong.kweh@intel.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-8-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule-loader: Use a cached copy of the capsule headerArd Biesheuvel
Instead of kmapping the capsule data twice, copy the capsule header into the capsule info struct we keep locally. This is an improvement by itself, but will also enable handling of non-standard header formats more easily. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-7-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule: Adjust return type of efi_capsule_setup_info()Jan Kiszka
We actually expect int at the caller and never return any size information. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-6-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule: Clean up pr_err/_info() messagesJan Kiszka
Avoid __func__, improve the information provided by some of the messages. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-5-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule: Remove pr_debug() on ENOMEM or EFAULTJan Kiszka
Both cases are not worth a debug log message - the error code is telling enough. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-4-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05efi/capsule: Fix return code on failing kmap/vmapJan Kiszka
If kmap or vmap fail, it means we ran out of memory. There are no user-provided addressed involved that would justify EFAULT. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20170602135207.21708-3-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-06-05firmware: arm_scpi: add support to populate OPPs and get transition latencySudeep Holla
Currently only CPU devices use the transition latency and the OPPs populated in the SCPI driver. scpi-cpufreq has logic to handle these. However, even GPU and other users of SCPI DVFS will need the same logic. In order to avoid duplication, this patch adds support to get DVFS transition latency and add all the OPPs to the device using OPP library helper functions. The helper functions added here can be used for any device whose DVFS are managed by SCPI. Also, we also have incorrect dependency on the cluster identifier for the CPUs. It's fundamentally wrong as the domain id need not match the cluster id. This patch gets rid of that dependency by making use of the clock bindings which are already in place. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2017-06-02Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Ingo Molnar: "Misc fixes: - three boot crash fixes for uncommon configurations - silence a boot warning under virtualization - plus a GCC 7 related (harmless) build warning fix" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi/bgrt: Skip efi_bgrt_init() in case of non-EFI boot x86/efi: Correct EFI identity mapping under 'efi=old_map' when KASLR is enabled x86/efi: Disable runtime services on kexec kernel if booted with efi=old_map efi: Remove duplicate 'const' specifiers efi: Don't issue error message when booted under Xen
2017-05-31pstore: Populate pstore record->time fieldKees Cook
The current time will be initially available in the record->time field for all pstore_read() and pstore_write() calls. Backends can either update the field during read(), or use the field during write() instead of fetching time themselves. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-05-31efi-pstore: Refactor erase routineKees Cook
Right now, every pass through the EFI variables during erase would build a copy of the old format variable name. Instead, try each name one time through the EFI variables list. Additionally bump up the buffer size to avoid truncation in pathological cases, and wipe the write name buffer. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-05-29Merge tag 'pinctrl-v4.12-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Here is an overdue pull request for pin control fixes, the most prominent feature is to make Intel Chromebooks (and I suspect any other Cherryview-based Intel thing) happy again, which we really want to see. There is a patch hitting drivers/firmware/* that I was uncertain to who actually manages, but I got Andy Shevchenko's and Dmitry Torokov's review tags on it and I trust them both 100% to do the right thing for Intel platform drivers. Summary: - Make a few Intel Chromebooks with Cherryview DMI firmware work smoothly. - A fix for some bogus allocations in the generic group management code. - Some GPIO descriptor lookup table stubs. Merged through the pin control tree for administrative reasons. - Revert the "bi-directional" and "output-enable" generic properties: we need more discussions around this. It seems other SoCs are using input/output gate enablement and these terms are not correct. - Fix mux and drive strength atomically in the MXS driver. - Fix the SPDIF function on sunxi A83T. - OF table terminators and other small fixes" * tag 'pinctrl-v4.12-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: sunxi: Fix SPDIF function name for A83T pinctrl: mxs: atomically switch mux and drive strength config pinctrl: cherryview: Extend the Chromebook DMI quirk to Intel_Strago systems firmware: dmi: Add DMI_PRODUCT_FAMILY identification string pinctrl: core: Fix warning by removing bogus code gpiolib: Add stubs for gpiod lookup table interface Revert "pinctrl: generic: Add bi-directional and output-enable" pinctrl: cherryview: Add terminate entry for dmi_system_id tables
2017-05-28efi/bgrt: Skip efi_bgrt_init() in case of non-EFI bootDave Young
Sabrina Dubroca reported an early panic: BUG: unable to handle kernel paging request at ffffffffff240001 IP: efi_bgrt_init+0xdc/0x134 [...] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ... which was introduced by: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code") The cause is that on this machine the firmware provides the EFI ACPI BGRT table even on legacy non-EFI bootups - which table should be EFI only. The garbage BGRT data causes the efi_bgrt_init() panic. Add a check to skip efi_bgrt_init() in case non-EFI bootup to work around this firmware bug. Tested-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Dave Young <dyoung@redhat.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: <stable@vger.kernel.org> # v4.11+ Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: 7b0a911478c7 ("efi/x86: Move the EFI BGRT init code to early init code") Link: http://lkml.kernel.org/r/20170526113652.21339-6-matt@codeblueprint.co.uk [ Rewrote the changelog to be more readable. ] Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-28efi: Remove duplicate 'const' specifiersArnd Bergmann
gcc-7 shows these harmless warnings: drivers/firmware/efi/libstub/secureboot.c:19:27: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier] static const efi_char16_t const efi_SecureBoot_name[] = { drivers/firmware/efi/libstub/secureboot.c:22:27: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier] Removing one of the specifiers gives us the expected behavior. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Reviewed-by: David Howells <dhowells@redhat.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Josh Boyer <jwboyer@fedoraproject.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-efi@vger.kernel.org Fixes: de8cb458625c ("efi: Get and store the secure boot status") Link: http://lkml.kernel.org/r/20170526113652.21339-3-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2017-05-27Revert "firmware: vpd: remove platform driver"Dmitry Torokhov
This reverts commit 7975bd4cca05a99aa14964cfa22366ee64da50ad, because VPD relies on driver core to handle deferrals returned by coreboot_table_find(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: remove platform driverDmitry Torokhov
There is no reason why VPD should register platform device and driver, given that we do not use their respective kobjects to attach attributes, nor do we need suspend/resume hooks, or any other features of device core. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: do not clear statically allocated dataDmitry Torokhov
ro_vpd and rw_vpd are static module-scope variables that are guaranteed to be initialized with zeroes, there is no need for explicit memset(). Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: use kasprintf() when forming name of 'raw' attributeDmitry Torokhov
When creating name for the "raw" attribute, let's switch to using kaspeintf() instead of doing it by hand. Also make sure we handle errors. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: use kdtrndup when copying section keyDmitry Torokhov
Instead of open-coding kstrndup with kzalloc + memcpy, let's use the helper. Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: do not leak kobjectsDmitry Torokhov
kobject_del() only unlinks kobject, we need to use kobject_put() to make sure kobject will go away completely. Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: avoid potential use-after-free when destroying sectionDmitry Torokhov
We should not free info->key before we remove sysfs attribute that uses this data as its name. Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: vpd: do not leave freed section attributes to the listDmitry Torokhov
We should only add section attribute to the list of section attributes if we successfully created corresponding sysfs attribute. Fixes: 049a59db34eb ("firmware: Google VPD sysfs driver") Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Reviewed-by: Guenter Roeck <groeck@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-25firmware: google: memconsole: Prevent overrun attack on coreboot consoleJulius Werner
The recent coreboot memory console update (firmware: google: memconsole: Adapt to new coreboot ring buffer format) introduced a small security issue in the driver: The new driver implementation parses the memory console structure again on every access. This is intentional so that additional lines added concurrently by runtime firmware can be read out. However, if an attacker can write to the structure, they could increase the size value to a point where the driver would read potentially sensitive memory areas from outside the original console buffer during the next access. This can be done through /dev/mem, since the console buffer usually resides in firmware-reserved memory that is not covered by STRICT_DEVMEM. This patch resolves that problem by reading the buffer's size value only once during boot (where we can still trust the structure). Other parts of the structure can still be modified at runtime, but the driver's bounds checks make sure that it will never read outside the buffer. Fixes: a5061d028 ("firmware: google: memconsole: Adapt to new coreboot ring buffer format") Signed-off-by: Julius Werner <jwerner@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-05-23firmware: dmi: Add DMI_PRODUCT_FAMILY identification stringMika Westerberg
Sometimes it is more convenient to be able to match a whole family of products, like in case of bunch of Chromebooks based on Intel_Strago to apply a driver quirk instead of quirking each machine one-by-one. This adds support for DMI_PRODUCT_FAMILY identification string and also exports it to the userspace through sysfs attribute just like the existing ones. Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2017-05-22Merge tag 'pstore-v4.12-rc3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull pstore fix from Kees Cook: "Marta noticed another misbehavior in EFI pstore, which this fixes. Hopefully this is the last of the v4.12 fixes for pstore!" * tag 'pstore-v4.12-rc3' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: efi-pstore: Fix write/erase id tracking
generated by cgit v1.2.3 (git 2.25.1) at 2024-09-11 01:07:02 +0000