summaryrefslogtreecommitdiff
path: root/drivers/firmware
AgeCommit message (Collapse)Author
2016-05-04efi: Expose non-blocking set_variable() wrapper to efivarsArd Biesheuvel
commit 9c6672ac9c91f7eb1ec436be1442b8c26d098e55 upstream. Commit 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable() operation") implemented a non-blocking alternative for the UEFI SetVariable() invocation performed by efivars, since it may occur in atomic context. However, this version of the function was never exposed via the efivars struct, so the non-blocking versions was not actually callable. Fix that. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.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 Fixes: 6d80dba1c9fe ("efi: Provide a non-blocking SetVariable() operation") Link: http://lkml.kernel.org/r/1454364428-494-2-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-05-04efi: Fix out-of-bounds read in variable_matches()Laszlo Ersek
commit 630ba0cc7a6dbafbdee43795617c872b35cde1b4 upstream. The variable_matches() function can currently read "var_name[len]", for example when: - var_name[0] == 'a', - len == 1 - match_name points to the NUL-terminated string "ab". This function is supposed to accept "var_name" inputs that are not NUL-terminated (hence the "len" parameter"). Document the function, and access "var_name[*match]" only if "*match" is smaller than "len". Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Laszlo Ersek <lersek@redhat.com> Cc: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@coreos.com> Cc: Jason Andryuk <jandryuk@gmail.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Link: http://thread.gmane.org/gmane.comp.freedesktop.xorg.drivers.intel/86906 Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03efi: Add pstore variables to the deletion whitelistMatt Fleming
commit e246eb568bc4cbbdd8a30a3c11151ff9b7ca7312 upstream. Laszlo explains why this is a good idea, 'This is because the pstore filesystem can be backed by UEFI variables, and (for example) a crash might dump the last kilobytes of the dmesg into a number of pstore entries, each entry backed by a separate UEFI variable in the above GUID namespace, and with a variable name according to the above pattern. Please see "drivers/firmware/efi/efi-pstore.c". While this patch series will not prevent the user from deleting those UEFI variables via the pstore filesystem (i.e., deleting a pstore fs entry will continue to delete the backing UEFI variable), I think it would be nice to preserve the possibility for the sysadmin to delete Linux-created UEFI variables that carry portions of the crash log, *without* having to mount the pstore filesystem.' There's also no chance of causing machines to become bricked by deleting these variables, which is the whole purpose of excluding things from the whitelist. Use the LINUX_EFI_CRASH_GUID guid and a wildcard '*' for the match so that we don't have to update the string in the future if new variable name formats are created for crash dump variables. Reported-by: Laszlo Ersek <lersek@redhat.com> Acked-by: Peter Jones <pjones@redhat.com> Tested-by: Peter Jones <pjones@redhat.com> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: "Lee, Chun-Yi" <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03efi: Make efivarfs entries immutable by defaultPeter Jones
commit ed8b0de5a33d2a2557dce7f9429dca8cb5bc5879 upstream. "rm -rf" is bricking some peoples' laptops because of variables being used to store non-reinitializable firmware driver data that's required to POST the hardware. These are 100% bugs, and they need to be fixed, but in the mean time it shouldn't be easy to *accidentally* brick machines. We have to have delete working, and picking which variables do and don't work for deletion is quite intractable, so instead make everything immutable by default (except for a whitelist), and make tools that aren't quite so broad-spectrum unset the immutable flag. Signed-off-by: Peter Jones <pjones@redhat.com> Tested-by: Lee, Chun-Yi <jlee@suse.com> Acked-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03efi: Make our variable validation list include the guidPeter Jones
commit 8282f5d9c17fe15a9e658c06e3f343efae1a2a2f upstream. All the variables in this list so far are defined to be in the global namespace in the UEFI spec, so this just further ensures we're validating the variables we think we are. Including the guid for entries will become more important in future patches when we decide whether or not to allow deletion of variables based on presence in this list. Signed-off-by: Peter Jones <pjones@redhat.com> Tested-by: Lee, Chun-Yi <jlee@suse.com> Acked-by: Matthew Garrett <mjg59@coreos.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03efi: Do variable name validation tests in utf8Peter Jones
commit 3dcb1f55dfc7631695e69df4a0d589ce5274bd07 upstream. Actually translate from ucs2 to utf8 before doing the test, and then test against our other utf8 data, instead of fudging it. Signed-off-by: Peter Jones <pjones@redhat.com> Acked-by: Matthew Garrett <mjg59@coreos.com> Tested-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-03efi: Use ucs2_as_utf8 in efivarfs instead of open coding a bad versionPeter Jones
commit e0d64e6a880e64545ad7d55786aa84ab76bac475 upstream. Translate EFI's UCS-2 variable names to UTF-8 instead of just assuming all variable names fit in ASCII. Signed-off-by: Peter Jones <pjones@redhat.com> Acked-by: Matthew Garrett <mjg59@coreos.com> Tested-by: Lee, Chun-Yi <jlee@suse.com> Signed-off-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-08firmware: dmi_scan: Fix UUID endianness for SMBIOS >= 2.6Andrea Arcangeli
The dmi_ver wasn't updated correctly before the dmi_decode method run to save the uuid. That resulted in "dmidecode -s system-uuid" and /sys/class/dmi/id/product_uuid disagreeing. The latter was buggy and this fixes it. Reported-by: Federico Simoncelli <fsimonce@redhat.com> Fixes: 9f9c9cbb6057 ("drivers/firmware/dmi_scan.c: fetch dmi version from SMBIOS if it exists") Fixes: 79bae42d51a5 ("dmi_scan: refactor dmi_scan_machine(), {smbios,dmi}_present()") Signed-off-by: Andrea Arcangeli <aarcange@redhat.com> Signed-off-by: Jean Delvare <jdelvare@suse.de>
2015-11-10Merge tag 'armsoc-drivers' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC driver updates from Olof Johansson: "As we've enabled multiplatform kernels on ARM, and greatly done away with the contents under arch/arm/mach-*, there's still need for SoC-related drivers to go somewhere. Many of them go in through other driver trees, but we still have drivers/soc to hold some of the "doesn't fit anywhere" lowlevel code that might be shared between ARM and ARM64 (or just in general makes sense to not have under the architecture directory). This branch contains mostly such code: - Drivers for qualcomm SoCs for SMEM, SMD and SMD-RPM, used to communicate with power management blocks on these SoCs for use by clock, regulator and bus frequency drivers. - Allwinner Reduced Serial Bus driver, again used to communicate with PMICs. - Drivers for ARM's SCPI (System Control Processor). Not to be confused with PSCI (Power State Coordination Interface). SCPI is used to communicate with the assistant embedded cores doing power management, and we have yet to see how many of them will implement this for their hardware vs abstracting in other ways (or not at all like in the past). - To make confusion between SCPI and PSCI more likely, this release also includes an update of PSCI to interface version 1.0. - Rockchip support for power domains. - A driver to talk to the firmware on Raspberry Pi" * tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (57 commits) soc: qcom: smd-rpm: Correct size of outgoing message bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus bus: sunxi-rsb: Add Allwinner Reduced Serial Bus (RSB) controller bindings ARM: bcm2835: add mutual inclusion protection drivers: psci: make PSCI 1.0 functions initialization version dependent dt-bindings: Correct paths in Rockchip power domains binding document soc: rockchip: power-domain: don't try to print the clock name in error case soc: qcom/smem: add HWSPINLOCK dependency clk: berlin: add cpuclk ARM: berlin: dts: add CLKID_CPU for BG2Q ARM: bcm2835: Add the Raspberry Pi firmware driver soc: qcom: smem: Move RPM message ram out of smem DT node soc: qcom: smd-rpm: Correct the active vs sleep state flagging soc: qcom: smd: delete unneeded of_node_put firmware: qcom-scm: build for correct architecture level soc: qcom: smd: Correct SMEM items for upper channels qcom-scm: add missing prototype for qcom_scm_is_available() qcom-scm: fix endianess issue in __qcom_scm_is_call_available soc: qcom: smd: Reject send of too big packets soc: qcom: smd: Handle big endian CPUs ...
2015-11-05Merge tag 'please-pull-pstore' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux Pull pstore updates from Tony Luck: "Half dozen small cleanups plus change to allow pstore backend drivers to be unloaded" * tag 'please-pull-pstore' of git://git.kernel.org/pub/scm/linux/kernel/git/aegl/linux: pstore: fix code comment to match code efi-pstore: fix kernel-doc argument name pstore: Fix return type of pstore_is_mounted() pstore: add pstore unregister pstore: add a helper function pstore_register_kmsg pstore: add vmalloc error check
2015-11-04Merge tag 'arm64-upstream' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 updates from Catalin Marinas: - "genirq: Introduce generic irq migration for cpu hotunplugged" patch merged from tip/irq/for-arm to allow the arm64-specific part to be upstreamed via the arm64 tree - CPU feature detection reworked to cope with heterogeneous systems where CPUs may not have exactly the same features. The features reported by the kernel via internal data structures or ELF_HWCAP are delayed until all the CPUs are up (and before user space starts) - Support for 16KB pages, with the additional bonus of a 36-bit VA space, though the latter only depending on EXPERT - Implement native {relaxed, acquire, release} atomics for arm64 - New ASID allocation algorithm which avoids IPI on roll-over, together with TLB invalidation optimisations (using local vs global where feasible) - KASan support for arm64 - EFI_STUB clean-up and isolation for the kernel proper (required by KASan) - copy_{to,from,in}_user optimisations (sharing the memcpy template) - perf: moving arm64 to the arm32/64 shared PMU framework - L1_CACHE_BYTES increased to 128 to accommodate Cavium hardware - Support for the contiguous PTE hint on kernel mapping (16 consecutive entries may be able to use a single TLB entry) - Generic CONFIG_HZ now used on arm64 - defconfig updates * tag 'arm64-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (91 commits) arm64/efi: fix libstub build under CONFIG_MODVERSIONS ARM64: Enable multi-core scheduler support by default arm64/efi: move arm64 specific stub C code to libstub arm64: page-align sections for DEBUG_RODATA arm64: Fix build with CONFIG_ZONE_DMA=n arm64: Fix compat register mappings arm64: Increase the max granular size arm64: remove bogus TASK_SIZE_64 check arm64: make Timer Interrupt Frequency selectable arm64/mm: use PAGE_ALIGNED instead of IS_ALIGNED arm64: cachetype: fix definitions of ICACHEF_* flags arm64: cpufeature: declare enable_cpu_capabilities as static genirq: Make the cpuhotplug migration code less noisy arm64: Constify hwcap name string arrays arm64/kvm: Make use of the system wide safe values arm64/debug: Make use of the system wide safe value arm64: Move FP/ASIMD hwcap handling to common code arm64/HWCAP: Use system wide safe values arm64/capabilities: Make use of system wide safe value arm64: Delay cpu feature capability checks ...
2015-11-02efi-pstore: fix kernel-doc argument nameGeliang Tang
The first argument name in the kernel-doc argument list for efi_pstore_scan_sysfs_enter() was slightly off. Fix it for the kernel doc. Signed-off-by: Geliang Tang <geliangtang@163.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
2015-11-02arm64/efi: fix libstub build under CONFIG_MODVERSIONSArd Biesheuvel
Now that we strictly forbid absolute relocations in libstub code, make sure that we don't emit any when CONFIG_MODVERSIONS is enabled, by stripping the kcrctab sections from the object file. This fixes a build problem under CONFIG_MODVERSIONS=y. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-10-30arm64/efi: move arm64 specific stub C code to libstubArd Biesheuvel
Now that we added special handling to the C files in libstub, move the one remaining arm64 specific EFI stub C file to libstub as well, so that it gets the same treatment. This should prevent future changes from resulting in binaries that may execute incorrectly in UEFI context. With efi-entry.S the only remaining EFI stub source file under arch/arm64, we can also simplify the Makefile logic somewhat. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt@codeblueprint.co.uk> Tested-by: Jeremy Linton <jeremy.linton@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-10-28efi: Fix warning of int-to-pointer-cast on x86 32-bit buildsTaku Izumi
Commit: 0f96a99dab36 ("efi: Add "efi_fake_mem" boot option") introduced the following warning message: drivers/firmware/efi/fake_mem.c:186:20: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] new_memmap_phy was defined as a u64 value and cast to void*, causing a int-to-pointer-cast warning on x86 32-bit builds. However, since the void* type is inappropriate for a physical address, the definition of struct efi_memory_map::phys_map has been changed to phys_addr_t in the previous patch, and so the cast can be dropped entirely. This patch also changes the type of the "new_memmap_phy" variable from "u64" to "phys_addr_t" to align with the types of memblock_alloc() and struct efi_memory_map::phys_map. Reported-by: Ingo Molnar <mingo@kernel.org> Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> [ Removed void* cast, updated commit log] 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: kamezawa.hiroyu@jp.fujitsu.com Cc: linux-efi@vger.kernel.org Cc: matt.fleming@intel.com Link: http://lkml.kernel.org/r/1445593697-1342-2-git-send-email-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-28efi: Use correct type for struct efi_memory_map::phys_mapArd Biesheuvel
We have been getting away with using a void* for the physical address of the UEFI memory map, since, even on 32-bit platforms with 64-bit physical addresses, no truncation takes place if the memory map has been allocated by the firmware (which only uses 1:1 virtually addressable memory), which is usually the case. However, commit: 0f96a99dab36 ("efi: Add "efi_fake_mem" boot option") adds code that clones and modifies the UEFI memory map, and the clone may live above 4 GB on 32-bit platforms. This means our use of void* for struct efi_memory_map::phys_map has graduated from 'incorrect but working' to 'incorrect and broken', and we need to fix it. So redefine struct efi_memory_map::phys_map as phys_addr_t, and get rid of a bunch of casts that are now unneeded. 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: izumi.taku@jp.fujitsu.com Cc: kamezawa.hiroyu@jp.fujitsu.com Cc: linux-efi@vger.kernel.org Cc: matt.fleming@intel.com Link: http://lkml.kernel.org/r/1445593697-1342-1-git-send-email-ard.biesheuvel@linaro.org Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-26Merge tag 'arm/soc/for-4.4/rpi-drivers' of ↵Olof Johansson
https://github.com/Broadcom/stblinux into next/drivers This pull request contains the Raspberry Pi firmware driver, for communicating with the VPU which has exclusive control of some of the peripherals. Eric adds the actual firmware driver and Alexander fixes the header file which was missing include guards. * tag 'arm/soc/for-4.4/rpi-drivers' of https://github.com/Broadcom/stblinux: ARM: bcm2835: add mutual inclusion protection ARM: bcm2835: Add the Raspberry Pi firmware driver Signed-off-by: Olof Johansson <olof@lixom.net>
2015-10-23Merge branch 'drivers/psci2' into next/driversOlof Johansson
* drivers/psci2: drivers: psci: make PSCI 1.0 functions initialization version dependent Signed-off-by: Olof Johansson <olof@lixom.net>
2015-10-23drivers: psci: make PSCI 1.0 functions initialization version dependentLorenzo Pieralisi
The PSCI specifications [1] and the SMC calling convention mandate that unimplemented functions ids must return NOT_SUPPORTED (0xffffffff) if a function id is called but it is not implemented. Consequently, PSCI 1.0 function ids that require the 1.0 PSCI_FEATURES call to be initialized: CPU_SUSPEND (psci_init_cpu_suspend()) SYSTEM_SUSPEND (psci_init_system_suspend()) call the PSCI_FEATURES function id independently of the detected PSCI firmware version, since, if the PSCI_FEATURES function id is not implemented, it must return NOT_SUPPORTED according to the PSCI specifications, causing the initialization functions to fail as expected. Some existing PSCI implementations (ie Qemu PSCI emulation), do not comply with the SMC calling convention and fail if function ids that are not implemented are called from the OS, causing boot failures. To solve this issue, this patch adds code that checks the PSCI firmware version before calling PSCI 1.0 initialization functions so that the OS makes sure that it is calling 1.0 functions only if the firmware version detected is 1.0 or greater, therefore avoiding PSCI calls that are bound to fail and might cause system boot failures owing to non-compliant PSCI firmware implementations. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Mark Rutland <mark.rutland@arm.com> Tested-by: Kevin Hilman <khilman@kernel.org> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2015-10-22Merge tag 'firmware/psci-1.0' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux into next/drivers This pull request contains patches that enable PSCI 1.0 firmware features for arm/arm64 platforms: - Lorenzo Pieralisi adds support for the PSCI_FEATURES call, manages various 1.0 specifications updates (power state id and functions return values) and provides PSCI v1.0 DT bindings - Sudeep Holla implements PSCI v1.0 system suspend support to enable PSCI based suspend-to-RAM * tag 'firmware/psci-1.0' of git://git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux: drivers: firmware: psci: add system suspend support drivers: firmware: psci: define more generic PSCI_FN_NATIVE macro drivers: firmware: psci: add PSCI v1.0 DT bindings drivers: firmware: psci: add extended stateid power_state support drivers: firmware: psci: add PSCI_FEATURES call drivers: firmware: psci: move power_state handling to generic code drivers: firmware: psci: add INVALID_ADDRESS return value Signed-off-by: Olof Johansson <olof@lixom.net>
2015-10-15Merge tag 'qcom-soc-for-4.4' of git://codeaurora.org/quic/kernel/agross-msm ↵Arnd Bergmann
into next/drivers Pull "Qualcomm ARM Based SoC Updates for 4.4" from Andy Gross: * Implement id_table driver matching in SMD * Avoid NULL pointer exception on remove of SMEM * Reorder SMEM/SMD configs * Make qcom_smem_get() return a pointer * Handle big endian CPUs correctly in SMEM * Represent SMD channel layout in structures * Use __iowrite32_copy() in SMD * Remove use of VLAIs in SMD * Handle big endian CPUs correctly in SMD/RPM * Handle big endian CPUs corretly in SMD * Reject sending SMD packets that are too large * Fix endianness issue in SCM __qcom_scm_is_call_available * Add missing prototype for qcom_scm_is_available() * Correct SMEM items for upper channels * Use architecture level to build SCM correctly * Delete unneeded of_node_put in SMD * Correct active/slep state flagging in SMD/RPM * Move RPM message ram out of SMEM DT node * tag 'qcom-soc-for-4.4' of git://codeaurora.org/quic/kernel/agross-msm: soc: qcom: smem: Move RPM message ram out of smem DT node soc: qcom: smd-rpm: Correct the active vs sleep state flagging soc: qcom: smd: delete unneeded of_node_put firmware: qcom-scm: build for correct architecture level soc: qcom: smd: Correct SMEM items for upper channels qcom-scm: add missing prototype for qcom_scm_is_available() qcom-scm: fix endianess issue in __qcom_scm_is_call_available soc: qcom: smd: Reject send of too big packets soc: qcom: smd: Handle big endian CPUs soc: qcom: smd_rpm: Handle big endian CPUs soc: qcom: smd: Remove use of VLAIS soc: qcom: smd: Use __iowrite32_copy() instead of open-coding it soc: qcom: smd: Represent channel layout in structures soc: qcom: smem: Handle big endian CPUs soc: qcom: Make qcom_smem_get() return a pointer soc: qcom: Reorder SMEM/SMD configs soc: qcom: smem: Avoid NULL pointer exception on remove soc: qcom: smd: Implement id_table driver matching
2015-10-14ARM: bcm2835: Add the Raspberry Pi firmware driverEric Anholt
This gives us a function for making mailbox property channel requests of the firmware, which is most notable in that it will let us get and set clock rates. Signed-off-by: Eric Anholt <eric@anholt.net> Acked-by: Stephen Warren <swarren@wwwdotorg.org>
2015-10-14firmware: qcom-scm: build for correct architecture levelArnd Bergmann
The ".arch_extension sec" directive is only available on ARMv6 or higher, so if we enable the SCM driver while building a kernel for an older CPU, we get a build error: /tmp/ccUyhMOY.s:130: Error: selected processor does not support ARM mode `smc #0' /tmp/ccUyhMOY.s:216: Error: selected processor does not support ARM mode `smc #0' /tmp/ccUyhMOY.s:373: Error: selected processor does not support ARM mode `smc #0' make[4]: *** [drivers/firmware/qcom_scm-32.o] Error 1 This changes the Makefile so we pass the ARMv7 architecture level both for the check and for the actual compilation of the scm driver. Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Andy Gross <agross@codeaurora.org>
2015-10-14qcom-scm: fix endianess issue in __qcom_scm_is_call_availableRob Clark
Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Stephen Boyd <sboyd@codeaurora.org> Signed-off-by: Andy Gross <agross@codeaurora.org>
2015-10-14Merge tag 'arm-scpi-for-v4.4' of ↵Arnd Bergmann
git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into next/drivers Merge "ARM System Control and Power Interface(SCPI) support" from Sudeep Holla It adds support for the following features provided by SCP firmware using different subsystems in Linux: 1. SCPI mailbox protocol driver which using mailbox framework 2. Clocks provided by SCP using clock framework 3. CPU DVFS(cpufreq) using existing arm-big-little driver 4. SCPI based sensors including temperature sensors * tag 'arm-scpi-for-v4.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux: hwmon: Support thermal zones registration for SCP temperature sensors hwmon: Support sensors exported via ARM SCP interface firmware: arm_scpi: Extend to support sensors Documentation: add DT bindings for ARM SCPI sensors cpufreq: arm_big_little: add SCPI interface driver clk: scpi: add support for cpufreq virtual device clk: add support for clocks provided by SCP(System Control Processor) firmware: add support for ARM System Control and Power Interface(SCPI) protocol Documentation: add DT binding for ARM System Control and Power Interface(SCPI) protocol
2015-10-14Merge tag 'efi-next' of ↵Ingo Molnar
git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi into core/efi Pull v4.4 EFI updates from Matt Fleming: - Make the EFI System Resource Table (ESRT) driver explicitly non-modular by ripping out the module_* code since Kconfig doesn't allow it to be built as a module anyway. (Paul Gortmaker) - Make the x86 efi=debug kernel parameter, which enables EFI debug code and output, generic and usable by arm64. (Leif Lindholm) - Add support to the x86 EFI boot stub for 64-bit Graphics Output Protocol frame buffer addresses. (Matt Fleming) - Detect when the UEFI v2.5 EFI_PROPERTIES_TABLE feature is enabled in the firmware and set an efi.flags bit so the kernel knows when it can apply more strict runtime mapping attributes - Ard Biesheuvel - Auto-load the efi-pstore module on EFI systems, just like we currently do for the efivars module. (Ben Hutchings) - Add "efi_fake_mem" kernel parameter which allows the system's EFI memory map to be updated with additional attributes for specific memory ranges. This is useful for testing the kernel code that handles the EFI_MEMORY_MORE_RELIABLE memmap bit even if your firmware doesn't include support. (Taku Izumi) Note: there is a semantic conflict between the following two commits: 8a53554e12e9 ("x86/efi: Fix multiple GOP device support") ae2ee627dc87 ("efifb: Add support for 64-bit frame buffer addresses") I fixed up the interaction in the merge commit, changing the type of current_fb_base from u32 to u64. Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-14Merge branch 'x86/urgent' into core/efi, to pick up a pending EFI fixIngo Molnar
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-12arm64: add KASAN supportAndrey Ryabinin
This patch adds arch specific code for kernel address sanitizer (see Documentation/kasan.txt). 1/8 of kernel addresses reserved for shadow memory. There was no big enough hole for this, so virtual addresses for shadow were stolen from vmalloc area. At early boot stage the whole shadow region populated with just one physical page (kasan_zero_page). Later, this page reused as readonly zero shadow for some memory that KASan currently don't track (vmalloc). After mapping the physical memory, pages for shadow memory are allocated and mapped. Functions like memset/memmove/memcpy do a lot of memory accesses. If bad pointer passed to one of these function it is important to catch this. Compiler's instrumentation cannot do this since these functions are written in assembly. KASan replaces memory functions with manually instrumented variants. Original functions declared as weak symbols so strong definitions in mm/kasan/kasan.c could replace them. Original functions have aliases with '__' prefix in name, so we could call non-instrumented variant if needed. Some files built without kasan instrumentation (e.g. mm/slub.c). Original mem* function replaced (via #define) with prefixed variants to disable memory access checks for such files. Signed-off-by: Andrey Ryabinin <ryabinin.a.a@gmail.com> Tested-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-10-12arm64/efi: isolate EFI stub from the kernel properArd Biesheuvel
Since arm64 does not use a builtin decompressor, the EFI stub is built into the kernel proper. So far, this has been working fine, but actually, since the stub is in fact a PE/COFF relocatable binary that is executed at an unknown offset in the 1:1 mapping provided by the UEFI firmware, we should not be seamlessly sharing code with the kernel proper, which is a position dependent executable linked at a high virtual offset. So instead, separate the contents of libstub and its dependencies, by putting them into their own namespace by prefixing all of its symbols with __efistub. This way, we have tight control over what parts of the kernel proper are referenced by the stub. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-10-12arm64/efi: remove /chosen/linux, uefi-stub-kern-ver DT propertyArd Biesheuvel
With the stub to kernel interface being promoted to a proper interface so that other agents than the stub can boot the kernel proper in EFI mode, we can remove the linux,uefi-stub-kern-ver field, considering that its original purpose was to prevent this from happening in the first place. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Matt Fleming <matt.fleming@intel.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2015-10-12efi: Add "efi_fake_mem" boot optionTaku Izumi
This patch introduces new boot option named "efi_fake_mem". By specifying this parameter, you can add arbitrary attribute to specific memory range. This is useful for debugging of Address Range Mirroring feature. For example, if "efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000" is specified, the original (firmware provided) EFI memmap will be updated so that the specified memory regions have EFI_MEMORY_MORE_RELIABLE attribute (0x10000): <original> efi: mem36: [Conventional Memory| | | | | | |WB|WT|WC|UC] range=[0x0000000100000000-0x00000020a0000000) (129536MB) <updated> efi: mem36: [Conventional Memory| |MR| | | | |WB|WT|WC|UC] range=[0x0000000100000000-0x0000000180000000) (2048MB) efi: mem37: [Conventional Memory| | | | | | |WB|WT|WC|UC] range=[0x0000000180000000-0x00000010a0000000) (61952MB) efi: mem38: [Conventional Memory| |MR| | | | |WB|WT|WC|UC] range=[0x00000010a0000000-0x0000001120000000) (2048MB) efi: mem39: [Conventional Memory| | | | | | |WB|WT|WC|UC] range=[0x0000001120000000-0x00000020a0000000) (63488MB) And you will find that the following message is output: efi: Memory: 4096M/131455M mirrored memory Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Xishi Qiu <qiuxishi@huawei.com> Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12efi: Auto-load the efi-pstore moduleBen Hutchings
efi-pstore should be auto-loaded on EFI systems, same as efivars. Signed-off-by: Ben Hutchings <ben@decadent.org.uk> Cc: Matthew Garrett <mjg59@srcf.ucam.org> Cc: Lee, Chun-Yi <jlee@suse.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12efi: Introduce EFI_NX_PE_DATA bit and set it from properties tableArd Biesheuvel
UEFI v2.5 introduces a runtime memory protection feature that splits PE/COFF runtime images into separate code and data regions. Since this may require special handling by the OS, allocate a EFI_xxx bit to keep track of whether this feature is currently active or not. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12efi: Add support for UEFIv2.5 Properties tableArd Biesheuvel
Version 2.5 of the UEFI spec introduces a new configuration table called the 'EFI Properties table'. Currently, it is only used to convey whether the Memory Protection feature is enabled, which splits PE/COFF images into separate code and data memory regions. Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Dave Young <dyoung@redhat.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12efi: Add EFI_MEMORY_MORE_RELIABLE support to efi_md_typeattr_format()Taku Izumi
UEFI spec 2.5 introduces new Memory Attribute Definition named EFI_MEMORY_MORE_RELIABLE. This patch adds this new attribute support to efi_md_typeattr_format(). Signed-off-by: Taku Izumi <izumi.taku@jp.fujitsu.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Xishi Qiu <qiuxishi@huawei.com> Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12efi/arm64: Clean up efi_get_fdt_params() interfaceLeif Lindholm
As we now have a common debug infrastructure between core and arm64 efi, drop the bit of the interface passing verbose output flags around. Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Mark Salter <msalter@redhat.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12efi/x86: Move efi=debug option parsing to coreLeif Lindholm
fed6cefe3b6e ("x86/efi: Add a "debug" option to the efi= cmdline") adds the DBG flag, but does so for x86 only. Move this early param parsing to core code. Signed-off-by: Leif Lindholm <leif.lindholm@linaro.org> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Mark Salter <msalter@redhat.com> Cc: Borislav Petkov <bp@suse.de> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-12drivers/firmware: Make efi/esrt.c driver explicitly non-modularPaul Gortmaker
The Kconfig for this driver is currently hidden with: config EFI_ESRT bool ...meaning that it currently is not being built as a module by anyone. Lets remove the modular code that is essentially orphaned, so that when reading the driver there is no doubt it is builtin-only. Since module_init translates to device_initcall in the non-modular case, the init ordering remains unchanged with this commit. We leave some tags like MODULE_AUTHOR for documentation purposes. We don't replace module.h with init.h since the file already has that. Cc: Peter Jones <pjones@redhat.com> Cc: linux-efi@vger.kernel.org Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Matt Fleming <matt.fleming@intel.com>
2015-10-11efi: Use the generic efi.memmap instead of 'memmap'Matt Fleming
Guenter reports that commit: 7bf793115dd9 ("efi, x86: Rearrange efi_mem_attributes()") breaks the IA64 compilation with the following error: drivers/built-in.o: In function `efi_mem_attributes': (.text+0xde962): undefined reference to `memmap' Instead of using the (rather poorly named) global variable 'memmap' which doesn't exist on IA64, use efi.memmap which points to the 'memmap' object on x86 and arm64 and which is NULL for IA64. The fact that efi.memmap is NULL for IA64 is OK because IA64 provides its own implementation of efi_mem_attributes(). Reported-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jonathan Zhang <zjzhang@codeaurora.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephen Rothwell <sfr@canb.auug.org.au> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@gmail.com> Cc: Tony Luck <tony.luck@intel.com> Link: http://lkml.kernel.org/r/20151003222607.GA2682@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-10-09firmware: arm_scpi: Extend to support sensorsPunit Agrawal
ARM System Control Processor (SCP) provides an API to query and use the sensors available in the system. Extend the SCPI driver to support sensor messages. Signed-off-by: Punit Agrawal <punit.agrawal@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com>
2015-10-02drivers: firmware: psci: add system suspend supportSudeep Holla
PSCI v1.0 introduces a new API called PSCI_SYSTEM_SUSPEND. This API provides the mechanism by which the calling OS can request entry into the deepest possible system sleep state. It meets all the necessary preconditions for entering suspend to RAM state in Linux. This patch adds support for PSCI_SYSTEM_SUSPEND in psci firmware and registers a psci system suspend operation to implement the suspend-to-RAM(s2r) in a generic way on all the platforms implementing PSCI. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2015-10-02drivers: firmware: psci: define more generic PSCI_FN_NATIVE macroSudeep Holla
This patch replaces the definition and usage of PSCI_0_2_FN_NATIVE with the new and more generic macro PSCI_FN_NATIVE that can be used with any version. This will be useful for the new features introduced in PSCIv1.0 and for any future revisions. Cc: Mark Rutland <mark.rutland@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2015-10-02drivers: firmware: psci: add PSCI v1.0 DT bindingsLorenzo Pieralisi
PSCI 1.0 is designed to be fully compliant to the PSCI 0.2 specification, with minor differences that are described in the PSCI specification. In particular, PSCI v1.0 augments the specification with a new power_state format (extended stateid - probeable through the PSCI_FEATURES call), changes some function return codes and functions usage requirements wrt PSCI 0.2. These changes mean that 1.0 vs 0.2 compliancy should be enforced through a DT compatible string that allows firmware to specify 1.0 only compliancy so that older kernels are prevented from using PSCI 1.0 FW implementations in a non-compatible way (eg by calling a 1.0 FW implementation and expecting 0.2 behaviour). This patch adds PSCI 1.0 DT bindings and related compatible string. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Cc: Mark Rutland <mark.rutland@arm.com>
2015-10-02drivers: firmware: psci: add extended stateid power_state supportLorenzo Pieralisi
PSCI v1.0 augmented the power_state parameter format specification (extended stateid) and introduced a way to probe it through the PSCI_FEATURES interface. This patch implements code that detects the power_state format at run-time through the PSCI_FEATURES interface, so that the power_state argument can be properly detected and validated in the kernel according to the information provided through firmware. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Cc: Mark Rutland <mark.rutland@arm.com>
2015-10-02drivers: firmware: psci: add PSCI_FEATURES callLorenzo Pieralisi
PSCI v1.0 introduces a PSCI_FEATURES call that allows to probe for features related to a specific function identifier. This patch adds PSCI_FEATURES support to the PSCI firmware layer. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Cc: Mark Rutland <mark.rutland@arm.com>
2015-10-02drivers: firmware: psci: move power_state handling to generic codeLorenzo Pieralisi
Functions implemented on arm64 to check if a power_state parameter is valid and if the power_state implies context loss are not arm64 specific and should be moved to generic code so that they can be reused on arm systems too. This patch moves the functions handling the power_state parameter to generic PSCI firmware layer code. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Tested-by: Jisheng Zhang <jszhang@marvell.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Mark Rutland <mark.rutland@arm.com>
2015-10-02drivers: firmware: psci: add INVALID_ADDRESS return valueLorenzo Pieralisi
PSCI 1.0 introduces the INVALID_ADDRESS return value for functions that take an address as input parameter (eg CPU_SUSPEND). This patch adds INVALID_ADDRESS return value to kernel code and updates the PSCI to linux error conversion to take it into account. The kernel error value associated to INVALID_ADDRESS is set to the error returned when the PSCI error code is INVALID_PARAMETERS to comply with current call sites expected return value, given that the kernel at present has no use for the additional error information reported. Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Tested-by: Jisheng Zhang <jszhang@marvell.com>
2015-10-01arm64/efi: Fix boot crash by not padding between EFI_MEMORY_RUNTIME regionsArd Biesheuvel
The new Properties Table feature introduced in UEFIv2.5 may split memory regions that cover PE/COFF memory images into separate code and data regions. Since these regions only differ in the type (runtime code vs runtime data) and the permission bits, but not in the memory type attributes (UC/WC/WT/WB), the spec does not require them to be aligned to 64 KB. Since the relative offset of PE/COFF .text and .data segments cannot be changed on the fly, this means that we can no longer pad out those regions to be mappable using 64 KB pages. Unfortunately, there is no annotation in the UEFI memory map that identifies data regions that were split off from a code region, so we must apply this logic to all adjacent runtime regions whose attributes only differ in the permission bits. So instead of rounding each memory region to 64 KB alignment at both ends, only round down regions that are not directly preceded by another runtime region with the same type attributes. Since the UEFI spec does not mandate that the memory map be sorted, this means we also need to sort it first. Note that this change will result in all EFI_MEMORY_RUNTIME regions whose start addresses are not aligned to the OS page size to be mapped with executable permissions (i.e., on kernels compiled with 64 KB pages). However, since these mappings are only active during the time that UEFI Runtime Services are being invoked, the window for abuse is rather small. Tested-by: Mark Salter <msalter@redhat.com> Tested-by: Mark Rutland <mark.rutland@arm.com> [UEFI 2.4 only] Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Signed-off-by: Matt Fleming <matt.fleming@intel.com> Reviewed-by: Mark Salter <msalter@redhat.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Cc: <stable@vger.kernel.org> # v4.0+ Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-kernel@vger.kernel.org Link: http://lkml.kernel.org/r/1443218539-7610-3-git-send-email-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-09-28firmware: add support for ARM System Control and Power Interface(SCPI) protocolSudeep Holla
This patch adds support for System Control and Power Interface (SCPI) Message Protocol used between the Application Cores(AP) and the System Control Processor(SCP). The MHU peripheral provides a mechanism for inter-processor communication between SCP's M3 processor and AP. SCP offers control and management of the core/cluster power states, various power domain DVFS including the core/cluster, certain system clocks configuration, thermal sensors and many others. This protocol driver provides interface for all the client drivers using SCPI to make use of the features offered by the SCP. Signed-off-by: Sudeep Holla <sudeep.holla@arm.com> Reviewed-by: Jon Medhurst (Tixy) <tixy@linaro.org> Cc: Jassi Brar <jassisinghbrar@gmail.com> Cc: Liviu Dudau <Liviu.Dudau@arm.com> Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
2015-09-27Merge tag 'armsoc-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc Pull ARM SoC fixes from Olof Johansson: "Our first real batch of fixes this release cycle. Nothing really concerning, and diffstat is a bit inflated due to some DT contents moving around on STi platforms. There's a collection of them here: - A fixup for a build breakage that hits on arm64 allmodconfig in QCOM SCM firmware drivers - MMC fixes for OMAP that had quite a bit of breakage this merge window. - Misc build/warning fixes on PXA and OMAP - A couple of minor fixes for Beagleboard X15 which is now starting to see a few more users in the wild" * tag 'armsoc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (31 commits) ARM: sti: dt: adapt DT to fix probe/bind issues in DRM driver ARM: dts: fix omap2+ address translation for pbias firmware: qcom: scm: Add function stubs for ARM64 ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2 ARM: omap2plus_defconfig: enable GPIO_PCA953X ARM: dts: omap5-uevm.dts: fix i2c5 pinctrl offsets ARM: OMAP2+: AM43XX: Enable autoidle for clks in am43xx_init_late ARM: dts: am57xx-beagle-x15: Update Phy supplies ARM: pxa: balloon3: Fix build error ARM: dts: Fixup model name for HP t410 dts ARM: dts: DRA7: fix a typo in ethernet ARM: omap2plus_defconfig: make PCF857x built-in ARM: dts: Use ti,pbias compatible string for pbias ARM: OMAP5: Cleanup options for SoC only build ARM: DRA7: Select missing options for SoC only build ARM: OMAP2+: board-generic: Remove stale of_irq macros ARM: OMAP4+: PM: erratum is used by OMAP5 and DRA7 as well ARM: dts: omap3-igep: Move eth IRQ pinmux to IGEPv2 common dtsi ARM: dts: am57xx-beagle-x15: Add wakeup irq for mcp79410 ARM: dts: am335x-phycore-som: Fix mpu voltage ...