summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2019-09-30Merge tag 'armsoc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC fixes from Olof Johansson: "A few fixes that have trickled in through the merge window: - Video fixes for OMAP due to panel-dpi driver removal - Clock fixes for OMAP that broke no-idle quirks + nfsroot on DRA7 - Fixing arch version on ASpeed ast2500 - Two fixes for reset handling on ARM SCMI" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: ARM: aspeed: ast2500 is ARMv6K reset: reset-scmi: add missing handle initialisation firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset bus: ti-sysc: Remove unpaired sysc_clkdm_deny_idle() ARM: dts: logicpd-som-lv: Fix i2c2 and i2c3 Pin mux ARM: dts: am3517-evm: Fix missing video ARM: dts: logicpd-torpedo-baseboard: Fix missing video ARM: omap2plus_defconfig: Fix missing video bus: ti-sysc: Fix handling of invalid clocks bus: ti-sysc: Fix clock handling for no-idle quirks
2019-09-29Merge tag 'scmi-fixes-5.4' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes ARM SCMI fixes for v5.4 Couple of fixes: one in scmi reset driver initialising missed scmi handle and an other in scmi reset API implementation fixing the assignment of reset state * tag 'scmi-fixes-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: reset: reset-scmi: add missing handle initialisation firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_reset Link: https://lore.kernel.org/r/20190918142139.GA4370@bogus Signed-off-by: Olof Johansson <olof@lixom.net>
2019-09-28Merge branch 'next-lockdown' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security Pull kernel lockdown mode from James Morris: "This is the latest iteration of the kernel lockdown patchset, from Matthew Garrett, David Howells and others. From the original description: This patchset introduces an optional kernel lockdown feature, intended to strengthen the boundary between UID 0 and the kernel. When enabled, various pieces of kernel functionality are restricted. Applications that rely on low-level access to either hardware or the kernel may cease working as a result - therefore this should not be enabled without appropriate evaluation beforehand. The majority of mainstream distributions have been carrying variants of this patchset for many years now, so there's value in providing a doesn't meet every distribution requirement, but gets us much closer to not requiring external patches. There are two major changes since this was last proposed for mainline: - Separating lockdown from EFI secure boot. Background discussion is covered here: https://lwn.net/Articles/751061/ - Implementation as an LSM, with a default stackable lockdown LSM module. This allows the lockdown feature to be policy-driven, rather than encoding an implicit policy within the mechanism. The new locked_down LSM hook is provided to allow LSMs to make a policy decision around whether kernel functionality that would allow tampering with or examining the runtime state of the kernel should be permitted. The included lockdown LSM provides an implementation with a simple policy intended for general purpose use. This policy provides a coarse level of granularity, controllable via the kernel command line: lockdown={integrity|confidentiality} Enable the kernel lockdown feature. If set to integrity, kernel features that allow userland to modify the running kernel are disabled. If set to confidentiality, kernel features that allow userland to extract confidential information from the kernel are also disabled. This may also be controlled via /sys/kernel/security/lockdown and overriden by kernel configuration. New or existing LSMs may implement finer-grained controls of the lockdown features. Refer to the lockdown_reason documentation in include/linux/security.h for details. The lockdown feature has had signficant design feedback and review across many subsystems. This code has been in linux-next for some weeks, with a few fixes applied along the way. Stephen Rothwell noted that commit 9d1f8be5cf42 ("bpf: Restrict bpf when kernel lockdown is in confidentiality mode") is missing a Signed-off-by from its author. Matthew responded that he is providing this under category (c) of the DCO" * 'next-lockdown' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security: (31 commits) kexec: Fix file verification on S390 security: constify some arrays in lockdown LSM lockdown: Print current->comm in restriction messages efi: Restrict efivar_ssdt_load when the kernel is locked down tracefs: Restrict tracefs when the kernel is locked down debugfs: Restrict debugfs when the kernel is locked down kexec: Allow kexec_file() with appropriate IMA policy when locked down lockdown: Lock down perf when in confidentiality mode bpf: Restrict bpf when kernel lockdown is in confidentiality mode lockdown: Lock down tracing and perf kprobes when in confidentiality mode lockdown: Lock down /proc/kcore x86/mmiotrace: Lock down the testmmiotrace module lockdown: Lock down module params that specify hardware parameters (eg. ioport) lockdown: Lock down TIOCSSERIAL lockdown: Prohibit PCMCIA CIS storage when the kernel is locked down acpi: Disable ACPI table override if the kernel is locked down acpi: Ignore acpi_rsdp kernel param when the kernel has been locked down ACPI: Limit access to custom_method when the kernel is locked down x86/msr: Restrict MSR access when the kernel is locked down x86: Lock down IO port access when the kernel is locked down ...
2019-09-22firmware: bcm47xx_nvram: _really_ correct size_t printf formatLinus Torvalds
Commit feb4eb060c3a ("firmware: bcm47xx_nvram: Correct size_t printf format") was wrong, and changed a printout of 'header.len' - which is an u32 type - to use '%zu'. It apparently did pattern matching on the other case, where it printed out 'nvram_len', which is indeed of type 'size_t'. Rather than undoing the change, this just makes it use the variable that the change seemed to expect to be used. Cc: Florian Fainelli <f.fainelli@gmail.com> Cc: Philippe Mathieu-Daudé <f4bug@amsat.org> Cc: Paul Burton <paul.burton@mips.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-09-22Merge tag 'mips_5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linuxLinus Torvalds
Pull MIPS updates from Paul Burton: "Main MIPS changes: - boot_mem_map is removed, providing a nice cleanup made possible by the recent removal of bootmem. - Some fixes to atomics, in general providing compiler barriers for smp_mb__{before,after}_atomic plus fixes specific to Loongson CPUs or MIPS32 systems using cmpxchg64(). - Conversion to the new generic VDSO infrastructure courtesy of Vincenzo Frascino. - Removal of undefined behavior in set_io_port_base(), fixing the behavior of some MIPS kernel configurations when built with recent clang versions. - Initial MIPS32 huge page support, functional on at least Ingenic SoCs. - pte_special() is now supported for some configurations, allowing among other things generic fast GUP to be used. - Miscellaneous fixes & cleanups. And platform specific changes: - Major improvements to Ingenic SoC support from Paul Cercueil, mostly enabled by the inclusion of the new TCU (timer-counter unit) drivers he's spent a very patient year or so working on. Plus some fixes for X1000 SoCs from Zhou Yanjie. - Netgear R6200 v1 systems are now supported by the bcm47xx platform. - DT updates for BMIPS, Lantiq & Microsemi Ocelot systems" * tag 'mips_5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (89 commits) MIPS: Detect bad _PFN_SHIFT values MIPS: Disable pte_special() for MIPS32 with RiXi MIPS: ralink: deactivate PCI support for SOC_MT7621 mips: compat: vdso: Use legacy syscalls as fallback MIPS: Drop Loongson _CACHE_* definitions MIPS: tlbex: Remove cpu_has_local_ebase MIPS: tlbex: Simplify r3k check MIPS: Select R3k-style TLB in Kconfig MIPS: PCI: refactor ioc3 special handling mips: remove ioremap_cachable mips/atomic: Fix smp_mb__{before,after}_atomic() mips/atomic: Fix loongson_llsc_mb() wreckage mips/atomic: Fix cmpxchg64 barriers MIPS: Octeon: remove duplicated include from dma-octeon.c firmware: bcm47xx_nvram: Allow COMPILE_TEST firmware: bcm47xx_nvram: Correct size_t printf format MIPS: Treat Loongson Extensions as ASEs MIPS: Remove dev_err() usage after platform_get_irq() MIPS: dts: mscc: describe the PTP ready interrupt MIPS: dts: mscc: describe the PTP register range ...
2019-09-18Merge tag 'char-misc-5.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc Pull char/misc driver updates from Greg KH: "Here is the big char/misc driver pull request for 5.4-rc1. As has been happening in previous releases, more and more individual driver subsystem trees are ending up in here. Now if that is good or bad I can't tell, but hopefully it makes your life easier as it's more of an aggregation of trees together to one merge point for you. Anyway, lots of stuff in here: - habanalabs driver updates - thunderbolt driver updates - misc driver updates - coresight and intel_th hwtracing driver updates - fpga driver updates - extcon driver updates - some dma driver updates - char driver updates - android binder driver updates - nvmem driver updates - phy driver updates - parport driver fixes - pcmcia driver fix - uio driver updates - w1 driver updates - configfs fixes - other assorted driver updates All of these have been in linux-next for a long time with no reported issues" * tag 'char-misc-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (200 commits) misc: mic: Use PTR_ERR_OR_ZERO rather than its implementation habanalabs: correctly cast variable to __le32 habanalabs: show correct id in error print habanalabs: stop using the acronym KMD habanalabs: display card name as sensors header habanalabs: add uapi to retrieve aggregate H/W events habanalabs: add uapi to retrieve device utilization habanalabs: Make the Coresight timestamp perpetual habanalabs: explicitly set the queue-id enumerated numbers habanalabs: print to kernel log when reset is finished habanalabs: replace __le32_to_cpu with le32_to_cpu habanalabs: replace __cpu_to_le32/64 with cpu_to_le32/64 habanalabs: Handle HW_IP_INFO if device disabled or in reset habanalabs: Expose devices after initialization is done habanalabs: improve security in Debug IOCTL habanalabs: use default structure for user input in Debug IOCTL habanalabs: Add descriptive name to PSOC app status register habanalabs: Add descriptive names to PSOC scratch-pad registers habanalabs: create two char devices per ASIC habanalabs: change device_setup_cdev() to be more generic ...
2019-09-18Merge tag 'driver-core-5.4-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core Pull driver core updates from Greg Kroah-Hartman: "Here is the big driver core update for 5.4-rc1. There was a bit of a churn in here, with a number of core and OF platform patches being added to the tree, and then after much discussion and review and a day-long in-person meeting, they were decided to be reverted and a new set of patches is currently being reviewed on the mailing list. Other than that churn, there are two "persistent" branches in here that other trees will be pulling in as well during the merge window. One branch to add support for drivers to have the driver core automatically add sysfs attribute files when a driver is bound to a device so that the driver doesn't have to manually do it (and then clean it up, as it always gets it wrong). There's another branch in here for generic lookup helpers for the driver core that lots of busses are starting to use. That's the majority of the non-driver-core changes in this patch series. There's also some on-going debugfs file creation cleanup that has been slowly happening over the past few releases, with the goal to hopefully get that done sometime next year. All of these have been in linux-next for a while now with no reported issues" [ Note that the above-mentioned generic lookup helpers branch was already brought in by the LED merge (commit 4feaab05dc1e) that had shared it. Also note that that common branch introduced an i2c bug due to a bad conversion, which got fixed here. - Linus ] * tag 'driver-core-5.4-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core: (49 commits) coccinelle: platform_get_irq: Fix parse error driver-core: add include guard to linux/container.h sysfs: add BIN_ATTR_WO() macro driver core: platform: Export platform_get_irq_optional() hwmon: pwm-fan: Use platform_get_irq_optional() driver core: platform: Introduce platform_get_irq_optional() Revert "driver core: Add support for linking devices during device addition" Revert "driver core: Add edit_links() callback for drivers" Revert "of/platform: Add functional dependency link from DT bindings" Revert "driver core: Add sync_state driver/bus callback" Revert "of/platform: Pause/resume sync state during init and of_platform_populate()" Revert "of/platform: Create device links for all child-supplier depencencies" Revert "of/platform: Don't create device links for default busses" Revert "of/platform: Fix fn definitons for of_link_is_valid() and of_link_property()" Revert "of/platform: Fix device_links_supplier_sync_state_resume() warning" Revert "of/platform: Disable generic device linking code for PowerPC" devcoredump: fix typo in comment devcoredump: use memory_read_from_buffer of/platform: Disable generic device linking code for PowerPC device.h: Fix warnings for mismatched parameter names in comments ...
2019-09-18firmware: arm_scmi: reset: fix reset_state assignment in scmi_domain_resetSudeep Holla
Fix the copy paste typo that incorrectly assigns domain_id with the passed 'state' parameter instead of reset_state. Fixes: 95a15d80aa0d ("firmware: arm_scmi: Add RESET protocol in SCMI v2.0") Reported-by: Etienne Carriere <etienne.carriere@linaro.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-09-16Merge 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: - refactor the EFI config table handling across architectures - add support for the Dell EMC OEM config table - include AER diagnostic output to CPER handling of fatal PCIe errors * 'efi-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi: cper: print AER info of PCIe fatal error efi: Export Runtime Configuration Interface table to sysfs efi: ia64: move SAL systab handling out of generic EFI code efi/x86: move UV_SYSTAB handling into arch/x86 efi: x86: move efi_is_table_address() into arch/x86
2019-09-16Merge tag 'armsoc-drivers' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc Pull ARM SoC driver updates from Arnd Bergmann: "This contains driver changes that are tightly connected to SoC specific code. Aside from smaller cleanups and bug fixes, here is a list of the notable changes. New device drivers: - The Turris Mox router has a new "moxtet" bus driver for its on-board pluggable extension bus. The same platform also gains a firmware driver. - The Samsung Exynos family gains a new Chipid driver exporting using the soc device sysfs interface - A similar socinfo driver for Qualcomm Snapdragon chips. - A firmware driver for the NXP i.MX DSP IPC protocol using shared memory and a mailbox Other changes: - The i.MX reset controller driver now supports the NXP i.MX8MM chip - Amlogic SoC specific drivers gain support for the S905X3 and A311D chips - A rework of the TI Davinci framebuffer driver to allow important cleanups in the platform code - A couple of device drivers for removed ARM SoC platforms are removed. Most of the removals were picked up by other maintainers, this contains whatever was left" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (123 commits) bus: uniphier-system-bus: use devm_platform_ioremap_resource() soc: ti: ti_sci_pm_domains: Add support for exclusive and shared access dt-bindings: ti_sci_pm_domains: Add support for exclusive and shared access firmware: ti_sci: Allow for device shared and exclusive requests bus: imx-weim: remove incorrect __init annotations fbdev: remove w90x900/nuc900 platform drivers spi: remove w90x900 driver net: remove w90p910-ether driver net: remove ks8695 driver firmware: turris-mox-rwtm: Add sysfs documentation firmware: Add Turris Mox rWTM firmware driver dt-bindings: firmware: Document cznic,turris-mox-rwtm binding bus: moxtet: fix unsigned comparison to less than zero bus: moxtet: remove set but not used variable 'dummy' ARM: scoop: Use the right include dt-bindings: power: add Amlogic Everything-Else power domains bindings soc: amlogic: Add support for Everything-Else power domains controller fbdev: da8xx: use resource management for dma fbdev: da8xx-fb: drop a redundant if fbdev: da8xx-fb: use devm_platform_ioremap_resource() ...
2019-09-16Merge tag 'arm64-upstream' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Will Deacon: "Although there isn't tonnes of code in terms of line count, there are a fair few headline features which I've noted both in the tag and also in the merge commits when I pulled everything together. The part I'm most pleased with is that we had 35 contributors this time around, which feels like a big jump from the usual small group of core arm64 arch developers. Hopefully they all enjoyed it so much that they'll continue to contribute, but we'll see. It's probably worth highlighting that we've pulled in a branch from the risc-v folks which moves our CPU topology code out to where it can be shared with others. Summary: - 52-bit virtual addressing in the kernel - New ABI to allow tagged user pointers to be dereferenced by syscalls - Early RNG seeding by the bootloader - Improve robustness of SMP boot - Fix TLB invalidation in light of recent architectural clarifications - Support for i.MX8 DDR PMU - Remove direct LSE instruction patching in favour of static keys - Function error injection using kprobes - Support for the PPTT "thread" flag introduced by ACPI 6.3 - Move PSCI idle code into proper cpuidle driver - Relaxation of implicit I/O memory barriers - Build with RELR relocations when toolchain supports them - Numerous cleanups and non-critical fixes" * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (114 commits) arm64: remove __iounmap arm64: atomics: Use K constraint when toolchain appears to support it arm64: atomics: Undefine internal macros after use arm64: lse: Make ARM64_LSE_ATOMICS depend on JUMP_LABEL arm64: asm: Kill 'asm/atomic_arch.h' arm64: lse: Remove unused 'alt_lse' assembly macro arm64: atomics: Remove atomic_ll_sc compilation unit arm64: avoid using hard-coded registers for LSE atomics arm64: atomics: avoid out-of-line ll/sc atomics arm64: Use correct ll/sc atomic constraints jump_label: Don't warn on __exit jump entries docs/perf: Add documentation for the i.MX8 DDR PMU perf/imx_ddr: Add support for AXI ID filtering arm64: kpti: ensure patched kernel text is fetched from PoU arm64: fix fixmap copy for 16K pages and 48-bit VA perf/smmuv3: Validate groups for global filtering perf/smmuv3: Validate group size arm64: Relax Documentation/arm64/tagged-pointers.rst arm64: kvm: Replace hardcoded '1' with SYS_PAR_EL1_F arm64: mm: Ignore spurious translation faults taken from the kernel ...
2019-09-12Merge tag 'qcom-drivers-for-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/drivers Qualcomm ARM Based Driver Updates for v5.4 * Add AOSS QMP support * Various fixups for Qualcomm SCM * Add socinfo driver * Add SoC serial number attribute and associated APIs * Add SM8150 and SC7180 support in Qualcomm SCM * Fixup max processor count in SMEM * tag 'qcom-drivers-for-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: soc: qcom: aoss: Add AOSS QMP support dt-bindings: soc: qcom: aoss: Add SM8150 and SC7180 support dt-bindings: firmware: scm: Add SM8150 and SC7180 support dt-bindings: firmware: scm: re-order compatible list soc: qcom: smem: Update max processor count soc: qcom: socinfo: Annotate switch cases with fall through soc: qcom: Extend AOSS QMP driver to support resources that are used to wake up the SoC. soc: qcom: socinfo: Expose image information soc: qcom: socinfo: Expose custom attributes soc: qcom: Add socinfo driver base: soc: Export soc_device_register/unregister APIs base: soc: Add serial_number attribute to soc firmware: qcom_scm: Cleanup code in qcom_scm_assign_mem() firmware: qcom_scm: Fix some typos in docs and printks firmware: qcom_scm: Use proper types for dma mappings
2019-09-04firmware: ti_sci: Allow for device shared and exclusive requestsLokesh Vutla
Sysfw provides an option for requesting exclusive access for a device using the flags MSG_FLAG_DEVICE_EXCLUSIVE. If this flag is not used, the device is meant to be shared across hosts. Once a device is requested from a host with this flag set, any request to this device from a different host will be nacked by sysfw. Current tisci driver enables this flag for every device requests. But this may not be true for all the devices. So provide a separate commands in driver for exclusive and shared device requests. Reviewed-by: Nishanth Menon <nm@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04firmware: Add Turris Mox rWTM firmware driverMarek Behún
This adds a driver to communicate with the firmware running on the secure processor of the Turris Mox router, enabling the kernel to retrieve true random numbers from the Entropy Bit Generator and to read some information burned into eFuses when device was manufactured: and to sign messages with the ECDSA private key burned into each Turris Mox device when manufacturing. This also adds support to read other information burned into eFuses: - serial number - board version - MAC addresses - RAM size - ECDSA public key (this is not read directly from eFuses, rather it is computed by the firmware as pair to the burned private key) The source code of the firmware is open source and can be found at https://gitlab.labs.nic.cz/turris/mox-boot-builder/tree/master/wtmi The firmware is also able to, on demand, sign messages with the burned ECDSA private key, but since Linux's akcipher API is not yet stable (and therefore not exposed to userspace via netlink), this functionality is not supported yet. Link: https://lore.kernel.org/r/20190822014318.19478-3-marek.behun@nic.cz Signed-off-by: Marek Behún <marek.behun@nic.cz> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-09-04firmware: add Intel Stratix10 remote system update driverRichard Gong
The Intel Remote System Update (RSU) driver exposes interfaces access through the Intel Service Layer to user space via sysfs interface. The RSU interfaces report and control some of the optional RSU features on Intel Stratix 10 SoC. The RSU feature provides a way for customers to update the boot configuration of a Intel Stratix 10 SoC device with significantly reduced risk of corrupting the bitstream storage and bricking the system. Signed-off-by: Richard Gong <richard.gong@intel.com> Reviewed-by: Alan Tull <atull@kernel.org> Link: https://lore.kernel.org/r/1567516701-26026-3-git-send-email-richard.gong@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04firmware: stratix10-svc: extend svc to support new RSU featuresRichard Gong
Extend Intel Stratix10 service layer driver to support new RSU notify and MAX_RETRY with watchdog event. RSU is used to provide our customers with protection against loading bad bitstream onto their devices when those devices are booting from flash RSU notifies provides users with an API to notify the firmware of the state of hard processor system. To deal with watchdog event, RSU provides a way for user to retry the current running image several times before giving up and starting normal RSU failover flow. Signed-off-by: Richard Gong <richard.gong@intel.com> Reviewed-by: Alan Tull <atull@kernel.org> Link: https://lore.kernel.org/r/1567516701-26026-2-git-send-email-richard.gong@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-04firmware: google: check if size is valid when decoding VPD dataHung-Te Lin
The VPD implementation from Chromium Vital Product Data project used to parse data from untrusted input without checking if the meta data is invalid or corrupted. For example, the size from decoded content may be negative value, or larger than whole input buffer. Such invalid data may cause buffer overflow. To fix that, the size parameters passed to vpd_decode functions should be changed to unsigned integer (u32) type, and the parsing of entry header should be refactored so every size field is correctly verified before starting to decode. Fixes: ad2ac9d5c5e0 ("firmware: Google VPD: import lib_vpd source files") Signed-off-by: Hung-Te Lin <hungte@chromium.org> Cc: stable <stable@vger.kernel.org> Reviewed-by: Guenter Roeck <linux@roeck-us.net> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/20190830022402.214442-1-hungte@chromium.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-09-03Merge tag 'imx-drivers-5.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/drivers i.MX drivers update for 5.4: - A series from Anson Huang to add UID support for i.MX8 SoC and SCU drivers. - A series from Daniel Baluta to add DSP IPC driver for communication between host AP (Linux) and the firmware running on DSP embedded in i.MX8 SoCs. - A small fix for GPCv2 error code printing. - Switch from module_platform_driver_probe() to module_platform_driver() for imx-weim driver, as we need the driver to probe again when device is present later. - Add optional burst clock mode support for imx-weim driver. * tag 'imx-drivers-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: soc: imx: gpcv2: Print the correct error code bus: imx-weim: use module_platform_driver() firmware: imx: Add DSP IPC protocol interface soc: imx-scu: Add SoC UID(unique identifier) support bus: imx-weim: optionally enable burst clock mode firmware: imx: scu-pd: Add IRQSTR_DSP PD range firmware: imx: scu-pd: Add mu13 b side PD range firmware: imx: scu-pd: Rename mu PD range to mu_a soc: imx8: Add i.MX8MM UID(unique identifier) support soc: imx8: Add i.MX8MQ UID(unique identifier) support Link: https://lore.kernel.org/r/20190825153237.28829-1-shawnguo@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-08-26firmware: bcm47xx_nvram: Allow COMPILE_TESTFlorian Fainelli
Allow building building the BCM47xx NVRAM and SPROM drivers using COMPILE_TEST. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@linux-mips.org Cc: joe@perches.com Cc: Rafał Miłecki <zajec5@gmail.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2019-08-26firmware: bcm47xx_nvram: Correct size_t printf formatFlorian Fainelli
When building on a 64-bit host, we will get warnings like those: drivers/firmware/broadcom/bcm47xx_nvram.c:103:3: note: in expansion of macro 'pr_err' pr_err("nvram on flash (%i bytes) is bigger than the reserved space in memory, will just copy the first %i bytes\n", ^~~~~~ drivers/firmware/broadcom/bcm47xx_nvram.c:103:28: note: format string is defined here pr_err("nvram on flash (%i bytes) is bigger than the reserved space in memory, will just copy the first %i bytes\n", ~^ %li Use %zu instead for that purpose. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Paul Burton <paul.burton@mips.com> Cc: linux-mips@linux-mips.org Cc: joe@perches.com Cc: Rafał Miłecki <zajec5@gmail.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2019-08-19efi: Restrict efivar_ssdt_load when the kernel is locked downMatthew Garrett
efivar_ssdt_load allows the kernel to import arbitrary ACPI code from an EFI variable, which gives arbitrary code execution in ring 0. Prevent that when the kernel is locked down. Signed-off-by: Matthew Garrett <mjg59@google.com> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: linux-efi@vger.kernel.org Signed-off-by: James Morris <jmorris@namei.org>
2019-08-18Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fix from Thomas Gleixner: "A single fix for a EFI mixed mode regression caused by recent rework which did not take the firmware bitwidth into account" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: efi-stub: Fix get_efi_config_table on mixed-mode setups
2019-08-12firmware: imx: Add DSP IPC protocol interfaceDaniel Baluta
Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain the Tensilica HiFi4 DSP for advanced pre- and post-audio processing. The communication between Host CPU and DSP firmware is taking place using a shared memory area for message passing and a dedicated Messaging Unit for notifications. DSP IPC protocol offers a doorbell interface using imx-mailbox API. We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a request-reply protocol. Connection 0 (txdb0, rxdb0): - Host writes messasge to shared memory [SHMEM] - Host sends a request [MU] - DSP handles request [SHMEM] - DSP sends reply [MU] Connection 1 (txdb1, rxdb1): - DSP writes a message to shared memory [SHMEM] - DSP sends a request [MU] - Host handles request [SHMEM] - Host sends reply [MU] The protocol interface will be used by a Host client to communicate with the DSP. First client will be the i.MX8 part from Sound Open Firmware infrastructure. The protocol offers the following interface: On Tx: - imx_dsp_ring_doorbell, will be called to notify the DSP that it needs to handle a request. On Rx: - clients need to provide two callbacks: .handle_reply .handle_request - the callbacks will be used by the protocol on notification arrival from DSP. Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com> Reviewed-by: Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-12firmware: arm_scmi: Add RESET protocol in SCMI v2.0Sudeep Holla
SCMIv2.0 adds a new Reset Management Protocol to manage various reset states a given device or domain can enter. Device(s) that can be collectively reset through a common reset signal constitute a reset domain for the firmware. A reset domain can be reset autonomously or explicitly through assertion and de-assertion of the signal. When autonomous reset is chosen, the firmware is responsible for taking the necessary steps to reset the domain and to subsequently bring it out of reset. When explicit reset is chosen, the caller has to specifically assert and then de-assert the reset signal by issuing two separate RESET commands. Add the basic SCMI reset infrastructure that can be used by Linux reset controller driver. Reviewed-by: Peng Fan <peng.fan@nxp.com> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Make use SCMI v2.0 fastchannel for performance protocolSudeep Holla
SCMI v2.0 adds support for "FastChannel" which do not use a message header as they are specialized for a single message. Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET} commands are supported over fastchannels. As they are optional, they need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command. Further {LIMIT,LEVEL}_SET commands can have optional doorbell support. Add support for making use of these fastchannels. Cc: Ionela Voinescu <Ionela.Voinescu@arm.com> Cc: Chris Redpath <Chris.Redpath@arm.com> Cc: Quentin Perret <Quentin.Perret@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add discovery of SCMI v2.0 performance fastchannelsSudeep Holla
SCMI v2.0 adds support for "FastChannel", a lightweight unidirectional channel that is dedicated to a single SCMI message type for controlling a specific platform resource. They do not use a message header as they are specialized for a single message. Only PERFORMANCE_LIMITS_{SET,GET} and PERFORMANCE_LEVEL_{SET,GET} commands are supported over fastchannels. As they are optional, they need to be discovered by PERFORMANCE_DESCRIBE_FASTCHANNEL command. Further {LIMIT,LEVEL}_SET commands can have optional doorbell support. Add support for discovery of these fastchannels. Cc: Ionela Voinescu <Ionela.Voinescu@arm.com> Cc: Chris Redpath <Chris.Redpath@arm.com> Cc: Quentin Perret <Quentin.Perret@arm.com> Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Use {get,put}_unaligned_le{32,64} accessorsSudeep Holla
Instead of type-casting the {tx,rx}.buf all over the place while accessing them to read/write __le{32,64} from/to the firmware, let's use the existing {get,put}_unaligned_le{32,64} accessors to hide all the type cast ugliness. Suggested-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Use asynchronous CLOCK_RATE_SET when possibleSudeep Holla
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum number of pending asynchronous clock rate changes supported by the platform. If it's non-zero, then we should be able to use asynchronous clock rate set for any clocks until the maximum limit is reached. Tracking the current count of pending asynchronous clock set rate requests, we can decide if the incoming/new request for clock set rate can be handled asynchronously or not until the maximum limit is reached. Cc: linux-clk@vger.kernel.org Reviewed-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Drop config flag in clk_ops->rate_setSudeep Holla
CLOCK_PROTOCOL_ATTRIBUTES provides attributes to indicate the maximum number of pending asynchronous clock rate changes supported by the platform. If it's non-zero, then we should be able to use asynchronous clock rate set for any clocks until the maximum limit is reached. In order to add that support, let's drop the config flag passed to clk_ops->rate_set and handle the asynchronous requests dynamically. Cc: Stephen Boyd <sboyd@kernel.org> Cc: linux-clk@vger.kernel.org Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add asynchronous sensor read if it supportsSudeep Holla
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor supports asynchronous read. We can read that flag and use asynchronous reads for any sensors with that attribute set. Let's use the new scmi_do_xfer_with_response to support asynchronous sensor reads. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Drop async flag in sensor_ops->reading_getSudeep Holla
SENSOR_DESCRIPTION_GET provides attributes to indicate if the sensor supports asynchronous read. Ideally we should be able to read that flag and use asynchronous reads for any sensors with that attribute set. In order to add that support, let's drop the async flag passed to sensor_ops->reading_get and dynamically switch between sync and async flags based on the attributes as provided by the firmware. Cc: linux-hwmon@vger.kernel.org Acked-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add support for asynchronous commands and delayed responseSudeep Holla
Messages that are sent to platform, also known as commands and can be: 1. Synchronous commands that block the channel until the requested work has been completed. The platform responds to these commands over the same channel and hence can't be used to send another command until the previous command has completed. 2. Asynchronous commands on the other hand, the platform schedules the requested work to complete later in time and returns almost immediately freeing the channel for new commands. The response indicates the success or failure in the ability to schedule the requested work. When the work has completed, the platform sends an additional delayed response message. Using the same transmit buffer used for sending the asynchronous command even for the delayed response corresponding to it simplifies handling of the delayed response. It's the caller of asynchronous command that is responsible for allocating the completion flag that scmi driver can complete to indicate the arrival of delayed response. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add mechanism to unpack message headersSudeep Holla
In order to identify the message type when a response arrives, we need a mechanism to unpack the message header similar to packing. Let's add one. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Separate out tx buffer handling and prepare to add rxSudeep Holla
Currently we pre-allocate transmit buffers only and use the first free slot in that pre-allocated buffer for transmitting any new message that are generally originated from OS to the platform firmware. Notifications or the delayed responses on the other hand are originated from the platform firmware and consumes by the OS. It's better to have separate and dedicated pre-allocated buffers to handle the notifications. We can still use the transmit buffers for the delayed responses. In addition, let's prepare existing scmi_xfer_{get,put} for acquiring and releasing a slot to identify the right(tx/rx) buffers. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Add receive channel support for notificationsSudeep Holla
With scmi_mbox_chan_setup enabled to identify and setup both Tx and Rx, let's consolidate setting up of both the channels under the function scmi_mbox_txrx_setup. Since some platforms may opt not to support notifications or delayed response, they may not need support for Rx. Hence Rx is optional and failure of setting one up is not considered fatal. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Segregate tx channel handling and prepare to add rxSudeep Holla
The transmit(Tx) channels are specified as the first entry and the receive(Rx) channels are the second entry as per the device tree bindings. Since we currently just support Tx, index 0 is hardcoded at all required callsites. In order to prepare for adding Rx support, let's remove those hardcoded index and add boolean parameter to identify Tx/Rx channels when setting them up. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Reorder some functions to avoid forward declarationsSudeep Holla
Re-shuffling few functions to keep definitions and their usages close. This is also needed to avoid too many unnecessary forward declarations while adding new features(delayed response and notifications). Keeping this separate to avoid mixing up of these trivial change that doesn't affect functionality into the ones that does. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Check if platform has released shmem before usingSudeep Holla
Sometimes platfom may take too long to respond to the command and OS might timeout before platform transfer the ownership of the shared memory region to the OS with the response. Since the mailbox channel associated with the channel is freed and new commands are dispatch on the same channel, OS needs to wait until it gets back the ownership. If not, either OS may end up overwriting the platform response for the last command(which is fine as OS timed out that command) or platform might overwrite the payload for the next command with the response for the old. The latter is problematic as platform may end up interpretting the response as the payload. In order to avoid such race, let's wait until the OS gets back the ownership before we prepare the shared memory with the payload for the next command. Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Use the term 'message' instead of 'command'Sudeep Holla
In preparation to adding support for other two types of messages that SCMI specification mentions, let's replace the term 'command' with the correct term 'message'. As per the specification the messages are of 3 types: commands(synchronous or asynchronous), delayed responses and notifications. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Fix few trivial typos in commentsSudeep Holla
While adding new comments found couple of typos that are better fixed. s/informfation/information/ s/statues/status/ Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Remove extra check for invalid length message responsesSudeep Holla
scmi_xfer_get_init ensures both transmit and receive buffer lengths are within the maximum limits. If receive buffer length is not supplied by the caller, it's set to the maximum limit value. Receive buffer length is never modified after that. So there's no need for the extra check when receive transmit completion for a command essage. Further, if the response header length is greater than the prescribed receive buffer length, the response buffer is truncated to the latter. Reported-by: Jim Quinlan <james.quinlan@broadcom.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12firmware: arm_scmi: Align few names in sensors protocol with SCMI specificationSudeep Holla
Looks like more code developed during the draft versions of the specification slipped through and they don't match the final released version. This seem to have happened only with sensor protocol. Renaming few command and function names here to match exactly with the released version of SCMI specification for ease of maintenance. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2019-08-12efi: cper: print AER info of PCIe fatal errorXiaofei Tan
AER info of PCIe fatal error is not printed in the current driver. Because APEI driver will panic directly for fatal error, and can't run to the place of printing AER info. An example log is as following: {763}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 11 {763}[Hardware Error]: event severity: fatal {763}[Hardware Error]: Error 0, type: fatal {763}[Hardware Error]: section_type: PCIe error {763}[Hardware Error]: port_type: 0, PCIe end point {763}[Hardware Error]: version: 4.0 {763}[Hardware Error]: command: 0x0000, status: 0x0010 {763}[Hardware Error]: device_id: 0000:82:00.0 {763}[Hardware Error]: slot: 0 {763}[Hardware Error]: secondary_bus: 0x00 {763}[Hardware Error]: vendor_id: 0x8086, device_id: 0x10fb {763}[Hardware Error]: class_code: 000002 Kernel panic - not syncing: Fatal hardware error! This issue was imported by the patch, '37448adfc7ce ("aerdrv: Move cper_print_aer() call out of interrupt context")'. To fix this issue, this patch adds print of AER info in cper_print_pcie() for fatal error. Here is the example log after this patch applied: {24}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 10 {24}[Hardware Error]: event severity: fatal {24}[Hardware Error]: Error 0, type: fatal {24}[Hardware Error]: section_type: PCIe error {24}[Hardware Error]: port_type: 0, PCIe end point {24}[Hardware Error]: version: 4.0 {24}[Hardware Error]: command: 0x0546, status: 0x4010 {24}[Hardware Error]: device_id: 0000:01:00.0 {24}[Hardware Error]: slot: 0 {24}[Hardware Error]: secondary_bus: 0x00 {24}[Hardware Error]: vendor_id: 0x15b3, device_id: 0x1019 {24}[Hardware Error]: class_code: 000002 {24}[Hardware Error]: aer_uncor_status: 0x00040000, aer_uncor_mask: 0x00000000 {24}[Hardware Error]: aer_uncor_severity: 0x00062010 {24}[Hardware Error]: TLP Header: 000000c0 01010000 00000001 00000000 Kernel panic - not syncing: Fatal hardware error! Fixes: 37448adfc7ce ("aerdrv: Move cper_print_aer() call out of interrupt context") Signed-off-by: Xiaofei Tan <tanxiaofei@huawei.com> Reviewed-by: James Morse <james.morse@arm.com> [ardb: put parens around terms of && operator] Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-08-12efi-stub: Fix get_efi_config_table on mixed-mode setupsHans de Goede
Fix get_efi_config_table using the wrong structs when booting a 64 bit kernel on 32 bit firmware. Fixes: 82d736ac56d7 ("Abstract out support for locating an EFI config table") Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-By: Matthew Garrett <mjg59@google.com> Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Acked-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-08-12Merge 5.3-rc4 into driver-core-nextGreg Kroah-Hartman
We need the driver core fixes in here as well. Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-09PSCI: cpuidle: Refactor CPU suspend power_state parameter handlingLorenzo Pieralisi
Current PSCI code handles idle state entry through the psci_cpu_suspend_enter() API, that takes an idle state index as a parameter and convert the index into a previously initialized power_state parameter before calling the PSCI.CPU_SUSPEND() with it. This is unwieldly, since it forces the PSCI firmware layer to keep track of power_state parameter for every idle state so that the index->power_state conversion can be made in the PSCI firmware layer instead of the CPUidle driver implementations. Move the power_state handling out of drivers/firmware/psci into the respective ACPI/DT PSCI CPUidle backends and convert the psci_cpu_suspend_enter() API to get the power_state parameter as input, which makes it closer to its firmware interface PSCI.CPU_SUSPEND() API. A notable side effect is that the PSCI ACPI/DT CPUidle backends now can directly handle (and if needed update) power_state parameters before handing them over to the PSCI firmware interface to trigger PSCI.CPU_SUSPEND() calls. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-09ARM: psci: cpuidle: Enable PSCI CPUidle driverLorenzo Pieralisi
Allow selection of the PSCI CPUidle in the kernel by updating the respective Kconfig entry. Remove PSCI callbacks from ARM/ARM64 generic CPU ops to prevent the PSCI idle driver from clashing with the generic ARM CPUidle driver initialization, that relies on CPU ops to initialize and enter idle states. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Cc: Will Deacon <will@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Daniel Lezcano <daniel.lezcano@linaro.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-09drivers: firmware: psci: Decouple checker from generic ARM CPUidleLorenzo Pieralisi
The PSCI checker currently relies on the generic ARM CPUidle infrastructure to enter an idle state, which in turn creates a dependency that is not really needed. The PSCI checker code to test PSCI CPU suspend is built on top of the CPUidle framework and can easily reuse the struct cpuidle_state.enter() function (previously initialized by an idle driver, with a PSCI back-end) to trigger an entry into an idle state, decoupling the PSCI checker from the generic ARM CPUidle infrastructure and simplyfing the code in the process. Convert the PSCI checker suspend entry function to use the struct cpuidle_state.enter() function callback. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> Reviewed-by: Sudeep Holla <sudeep.holla@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Will Deacon <will@kernel.org>
2019-08-08efi: Export Runtime Configuration Interface table to sysfsNarendra K
System firmware advertises the address of the 'Runtime Configuration Interface table version 2 (RCI2)' via an EFI Configuration Table entry. This code retrieves the RCI2 table from the address and exports it to sysfs as a binary attribute 'rci2' under /sys/firmware/efi/tables directory. The approach adopted is similar to the attribute 'DMI' under /sys/firmware/dmi/tables. RCI2 table contains BIOS HII in XML format and is used to populate BIOS setup page in Dell EMC OpenManage Server Administrator tool. The BIOS setup page contains BIOS tokens which can be configured. Signed-off-by: Narendra K <Narendra.K@dell.com> Reviewed-by: Mario Limonciello <mario.limonciello@dell.com> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-08-08efi: ia64: move SAL systab handling out of generic EFI codeArd Biesheuvel
The SAL systab is an Itanium specific EFI configuration table, so move its handling into arch/ia64 where it belongs. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>