summaryrefslogtreecommitdiff
path: root/arch/arm64
AgeCommit message (Collapse)AuthorFilesLines
2019-04-28Merge tag 'samsung-dt64-5.2' of ↵Olof Johansson3-12/+34
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into arm/dt Samsung DTS ARM64 changes for v5.2 1. Use proper clock rates for GSCALER module on TM2 boards. 2. Add clocks for local paths on DECON and GSCALER modules of Exynos5433. 3. Add Slim SecuritySubSystem to Exynos5433. * tag 'samsung-dt64-5.2' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux: arm64: dts: exynos: Add SlimSSS to Exynos5433 arm64: dts: exynos: add DSD/GSD clocks to DECONs and GSCALERs of Exynos5433 arm64: dts: exynos: configure GSCALER related clocks on TM2 Signed-off-by: Olof Johansson <olof@lixom.net>
2019-04-28Merge tag 'renesas-arm64-dt-for-v5.2' of ↵Olof Johansson13-58/+499
https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas into arm/dt Renesas ARM64 Based SoC DT Updates for v5.2 * R-Car Gen3 SoC based Salvator-X and Salvator-XS boards - Add GPIO keys support - Sort rwdt node alphabetically * R-Car H3 (r8a7795), M3-W (r8a7796) and M3-N (r8a77965) SoCs - Use extended audio DMAC register * R-Car M3-W (r8a7796) SoC - Remove unneeded sound #address/size-cells * R-Car M3-N (r8a77965) SoC - Add SSIU support for audio * R-Car E3 (r8a77990) and RZ/G2E (r8a774c0) SoCs - Remove invalid compatible value for CSI40 * R-Car E3 (r8a77990) SoC - Cprrect SPDX license identifier style * R-Car E3 (r8a77990) based Ebisu board - Add BD9571 PMIC with DDR0 backup power config - Correct adv7482 hexadecimal register address - Add GPIO expander * R-Car E3 (r8a77990) based Ebisu and D3 (r8a77995) based Draak boards - Update bootargs to bring them into line with other R-Car Gen3 boards - Enable LVDS1 encoder * R-Car D3 (r8a77995) based Draak board - Correct EthernetAVB phy mode - Enable CAN0 and CAN1 * RZ/G2E (r8a774c0) SoC - Add CANFD support - Correct CPU node style * RZ/G2E (r8a774c0) and RZ/G2M (r8a774a1) SoCs - Add clkp2 clock to CAN nodes * RZ/G2E (r8a774c0) based EK874 board - Add LED, CAN and RTC support * tag 'renesas-arm64-dt-for-v5.2' of https://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (26 commits) arm64: dts: renesas: salvator-common: Add GPIO keys support arm64: dts: renesas: use extended audio dmac register arm64: dts: renesas: r8a77995: draak: Fix EthernetAVB phy mode to rgmii arm64: dts: renesas: salvator-common: Sort node label arm64: dts: renesas: Update Ebisu and Draak bootargs arm64: dts: renesas: r8a774c0: Add clkp2 clock to CAN nodes arm64: dts: renesas: r8a774c0: Add CANFD support arm64: dts: renesas: r8a774a1: Add clkp2 clock to CAN nodes arm64: dts: renesas: ebisu: Add PMIC DDR0 Backup Power config arm64: dts: renesas: r8a77990-ebisu: Add BD9571 PMIC arm64: dts: renesas: r8a77990: Remove invalid compatible value for CSI40 arm64: dts: renesas: r8a774c0: Remove invalid compatible value for CSI40 arm64: dts: renesas: r8a77995: draak: Enable CAN0, CAN1 arm64: dts: renesas: r8a774c0-cat874: Add RWDT support arm64: dts: renesas: ebisu: Enable VIN5 arm64: dts: renesas: r8a774c0-cat874: Add LEDs support arm64: dts: renesas: r8a774c0-cat874: add RTC support arm64: dts: renesas: cat875: Add CAN support arm64: dts: renesas: r8a774c0: Fix cpu nodes style arm64: dts: renesas: r8a77965: add SSIU support for sound ... Signed-off-by: Olof Johansson <olof@lixom.net>
2019-04-28Merge tag 'v5.2-rockchip-dts64-1' of ↵Olof Johansson13-21/+1050
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/dt Core new soc features are hdmi-cec for rk3328, scheduler capacity-values and emmc cleanups for rk3399. New boards are the OrangePi (rk3399) and NanoPi NEO4. Both the OrangePi as well as the NanoPC/Pie family also directly got some additional features added after the boards itself. The Rock960 family (rock960+ficus) got their power-tree cleaned to match the schematics and also got hdmi-audio and their gpu enabled. Mali support also got enabled on the RockPi4 and finally both rk3328-rock64 and rk3328-roc-cc got some additional features. * tag 'v5.2-rockchip-dts64-1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip: (23 commits) arm64: dts: rockchip: Decrease emmc-phy's drive impedance on rk3399-puma arm64: dts: rockchip: Define drive-impedance-ohm for RK3399's emmc-phy. arm64: dts: rockchip: Disable DCMDs on RK3399's eMMC controller. arm64: dts: rockchip: Add nanopi4 ethernet phy arm64: dts: rockchip: Add PWM fan for NanoPC-T4 arm64: dts: rockchip: Add the fusb typec manager to rk3399-orangepi arm64: dts: rockchip: Specify vid supply for the rk3399-orangepi compass (AK09911) arm64: dts: rockchip: Fix clock names and add missing supplies for bluetooth on rk3399-orangepi arm64: dts: rockchip: Add 12V DCIN regulator to rk3399-ficus arm64: dts: rockchip: Rename vcc_sys into vcc5v0_sys on rk3399-rock960 arm64: dts: rockchip: Add Nanopi NEO4 initial support arm64: dts: rockchip: enable hdmi audio out for rk3399-rockpro64 arm64: dts: rockchip: Add support for the Orange Pi RK3399 board. arm64: dts: rockchip: enable mali on rock960 boards arm64: dts: rockchip: enable mali on Rock Pi 4 arm64: dts: rockchip: add rk3328-roc-cc cpu-supply entries for all cpu nodes arm64: dts: rockchip: give some life to the rk3328-roc-cc leds arm64: dts: rockchip: add #sound-dai-cells to HDMI of rk3328 arm64: dts: rockchip: add ir-receiver node on rk3328-rock64 arm64: dts: rockchip: add leds node on rk3328-rock64 ... Signed-off-by: Olof Johansson <olof@lixom.net>
2019-04-28Merge tag 'amlogic-dt64' of ↵Olof Johansson7-0/+378
https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into arm/dt arm64: dts: Amlogic updates for v5.2 Highlights - new board: SEI Robotics 510, based on S905X2 SoC (G12A) - enable more periphearls for S905X2 based boards * tag 'amlogic-dt64' of https://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic: arm64: dts: meson-g12a: Add CMA reserved memory arm64: dts: meson-g12a-x96-max: Enable BT Module arm64: dts: meson-g12a-x96-max: add regulators arm64: dts: meson-g12a-sei510: add regulators arm64: dts: meson-g12a-x96-max: add uart_AO pinctrl arm64: dts: meson-g12a-sei510: add uart_AO pinctrl arm64: dts: meson-g12a-u200: add uart_AO pinctrl arm64: dts: meson: g12a: Add UART A, B & C nodes and pins arm64: dts: meson: g12a: add reset controller arm64: dts: meson: g12a: add uart_ao_a pinctrl arm64: dts: meson: g12a: add pinctrl support controllers arm64: dts: meson: g12a: Add AO Clock + Reset Controller support arm64: dts: meson-gxm-nexbox-a1: Enable USB arm64: dts: meson: g12a: add efuse arm64: dts: meson: g12a: add secure monitor arm64: dts: meson-gxl-s905d-phicomm-n1: add status LED arm64: dts: meson-g12a: Add AO Secure node arm64: dts: Add SEI Robotics SEI510 Board vendor-prefixes: Add prefix for Shenzhen SEI Robotics Co., Ltd Signed-off-by: Olof Johansson <olof@lixom.net>
2019-04-28Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-nextDavid S. Miller4-15/+70
Daniel Borkmann says: ==================== pull-request: bpf-next 2019-04-28 The following pull-request contains BPF updates for your *net-next* tree. The main changes are: 1) Introduce BPF socket local storage map so that BPF programs can store private data they associate with a socket (instead of e.g. separate hash table), from Martin. 2) Add support for bpftool to dump BTF types. This is done through a new `bpftool btf dump` sub-command, from Andrii. 3) Enable BPF-based flow dissector for skb-less eth_get_headlen() calls which was currently not supported since skb was used to lookup netns, from Stanislav. 4) Add an opt-in interface for tracepoints to expose a writable context for attached BPF programs, used here for NBD sockets, from Matt. 5) BPF xadd related arm64 JIT fixes and scalability improvements, from Daniel. 6) Change the skb->protocol for bpf_skb_adjust_room() helper in order to support tunnels such as sit. Add selftests as well, from Willem. 7) Various smaller misc fixes. ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-27bpf, arm64: use more scalable stadd over ldxr / stxr loop in xaddDaniel Borkmann4-9/+71
Since ARMv8.1 supplement introduced LSE atomic instructions back in 2016, lets add support for STADD and use that in favor of LDXR / STXR loop for the XADD mapping if available. STADD is encoded as an alias for LDADD with XZR as the destination register, therefore add LDADD to the instruction encoder along with STADD as special case and use it in the JIT for CPUs that advertise LSE atomics in CPUID register. If immediate offset in the BPF XADD insn is 0, then use dst register directly instead of temporary one. Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-27bpf, arm64: remove prefetch insn in xadd mappingDaniel Borkmann2-7/+0
Prefetch-with-intent-to-write is currently part of the XADD mapping in the AArch64 JIT and follows the kernel's implementation of atomic_add. This may interfere with other threads executing the LDXR/STXR loop, leading to potential starvation and fairness issues. Drop the optional prefetch instruction. Fixes: 85f68fe89832 ("bpf, arm64: implement jiting of BPF_XADD") Reported-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Acked-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2019-04-26Merge tag 'arm64-fixes' of ↵Linus Torvalds2-3/+8
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Catalin Marinas: - keep the tail of an unaligned initrd reserved - adjust ftrace_make_call() to deal with the relative nature of PLTs * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64/module: ftrace: deal with place relative nature of PLTs arm64: mm: Ensure tail of unaligned initrd is reserved
2019-04-26arm64: Always enable ssb vulnerability detectionJeremy Linton2-8/+5
Ensure we are always able to detect whether or not the CPU is affected by SSB, so that we can later advertise this to userspace. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> [will: Use IS_ENABLED instead of #ifdef] Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: add sysfs vulnerability show for spectre-v2Jeremy Linton1-1/+26
Track whether all the cores in the machine are vulnerable to Spectre-v2, and whether all the vulnerable cores have been mitigated. We then expose this information to userspace via sysfs. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: Always enable spectre-v2 vulnerability detectionJeremy Linton1-7/+8
Ensure we are always able to detect whether or not the CPU is affected by Spectre-v2, so that we can later advertise this to userspace. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: Use firmware to detect CPUs that are not affected by Spectre-v2Marc Zyngier1-9/+23
The SMCCC ARCH_WORKAROUND_1 service can indicate that although the firmware knows about the Spectre-v2 mitigation, this particular CPU is not vulnerable, and it is thus not necessary to call the firmware on this CPU. Let's use this information to our benefit. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: Advertise mitigation of Spectre-v2, or lack thereofMarc Zyngier1-53/+56
We currently have a list of CPUs affected by Spectre-v2, for which we check that the firmware implements ARCH_WORKAROUND_1. It turns out that not all firmwares do implement the required mitigation, and that we fail to let the user know about it. Instead, let's slightly revamp our checks, and rely on a whitelist of cores that are known to be non-vulnerable, and let the user know the status of the mitigation in the kernel log. Signed-off-by: Marc Zyngier <marc.zyngier@arm.com> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: add sysfs vulnerability show for meltdownJeremy Linton1-14/+44
We implement page table isolation as a mitigation for meltdown. Report this to userspace via sysfs. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: Add sysfs vulnerability show for spectre-v1Mian Yousaf Kaukab1-0/+6
spectre-v1 has been mitigated and the mitigation is always active. Report this to userspace via sysfs Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: Provide a command line to disable spectre_v2 mitigationJeremy Linton1-0/+13
There are various reasons, such as benchmarking, to disable spectrev2 mitigation on a machine. Provide a command-line option to do so. Signed-off-by: Jeremy Linton <jeremy.linton@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Tested-by: Stefan Wahren <stefan.wahren@i2se.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: futex: Avoid copying out uninitialised stack in failed cmpxchg()Will Deacon1-1/+3
Returning an error code from futex_atomic_cmpxchg_inatomic() indicates that the caller should not make any use of *uval, and should instead act upon on the value of the error code. Although this is implemented correctly in our futex code, we needlessly copy uninitialised stack to *uval in the error case, which can easily be avoided. Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: futex: Bound number of LDXR/STXR loops in FUTEX_WAKE_OPWill Deacon1-21/+34
Our futex implementation makes use of LDXR/STXR loops to perform atomic updates to user memory from atomic context. This can lead to latency problems if we end up spinning around the LL/SC sequence at the expense of doing something useful. Rework our futex atomic operations so that we return -EAGAIN if we fail to update the futex word after 128 attempts. The core futex code will reschedule if necessary and we'll try again later. Cc: <stable@kernel.org> Fixes: 6170a97460db ("arm64: Atomic operations") Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result valueWill Deacon1-8/+8
Rather embarrassingly, our futex() FUTEX_WAKE_OP implementation doesn't explicitly set the return value on the non-faulting path and instead leaves it holding the result of the underlying atomic operation. This means that any FUTEX_WAKE_OP atomic operation which computes a non-zero value will be reported as having failed. Regrettably, I wrote the buggy code back in 2011 and it was upstreamed as part of the initial arm64 support in 2012. The reasons we appear to get away with this are: 1. FUTEX_WAKE_OP is rarely used and therefore doesn't appear to get exercised by futex() test applications 2. If the result of the atomic operation is zero, the system call behaves correctly 3. Prior to version 2.25, the only operation used by GLIBC set the futex to zero, and therefore worked as expected. From 2.25 onwards, FUTEX_WAKE_OP is not used by GLIBC at all. Fix the implementation by ensuring that the return value is either 0 to indicate that the atomic operation completed successfully, or -EFAULT if we encountered a fault when accessing the user mapping. Cc: <stable@kernel.org> Fixes: 6170a97460db ("arm64: Atomic operations") Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-26arm64: dts: msm8998: thermal: Restrict thermal zone name length to under 20Amit Kucheria1-2/+2
The thermal core restricts names of thermal zones to under 20 characters. Fix the names for a couple of msm8998 thermal zones. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-26arm64: dts: msm8998: thermal: Fix number of supported sensorsAmit Kucheria1-1/+1
msm8998 has 22 sensors connected in total, 14 on the 1st controller, 8 on the 2nd controller. Increase the number to allow sensors with ID 12 and 13 to be registered. Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-26arm64: dts: msm8998-mtp: thermal: Remove skin and battery thermal zonesAmit Kucheria1-38/+0
The msm8998-mtp doesn't have TSENS-based sensors wired up for skin and battery thermal zones. TSENS sensors should be common across all boards using the SoC and shouldn't be board-specific as these entries. They also show the following error when trying to read the temperature cat: read error: Invalid argument Remove these board-specific erroneous thermal zones. Fixes: 4449b6f248d9 ("arm64: dts: qcom: msm8998: Add tsens and thermal-zones") Signed-off-by: Amit Kucheria <amit.kucheria@linaro.org> Tested-by: Marc Gonzalez <marc.w.gonzalez@free.fr> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-25arm64: sysreg: Make mrs_s and msr_s macros work with Clang and LTOKees Cook3-19/+38
Clang's integrated assembler does not allow assembly macros defined in one inline asm block using the .macro directive to be used across separate asm blocks. LLVM developers consider this a feature and not a bug, recommending code refactoring: https://bugs.llvm.org/show_bug.cgi?id=19749 As binutils doesn't allow macros to be redefined, this change uses UNDEFINE_MRS_S and UNDEFINE_MSR_S to define corresponding macros in-place and workaround gcc and clang limitations on redefining macros across different assembler blocks. Specifically, the current state after preprocessing looks like this: asm volatile(".macro mXX_s ... .endm"); void f() { asm volatile("mXX_s a, b"); } With GCC, it gives macro redefinition error because sysreg.h is included in multiple source files, and assembler code for all of them is later combined for LTO (I've seen an intermediate file with hundreds of identical definitions). With clang, it gives macro undefined error because clang doesn't allow sharing macros between inline asm statements. I also seem to remember catching another sort of undefined error with GCC due to reordering of macro definition asm statement and generated asm code for function that uses the macro. The solution with defining and undefining for each use, while certainly not elegant, satisfies both GCC and clang, LTO and non-LTO. Co-developed-by: Alex Matveev <alxmtvv@gmail.com> Co-developed-by: Yury Norov <ynorov@caviumnetworks.com> Co-developed-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-24arm64: dts: exynos: Move fixed-clocks out of socKrzysztof Kozlowski2-12/+14
The XXTI fixed-clock is the input to the SoC therefore it should not be inside the soc node. This also fixes DTC W=1 warning: arch/arm64/boot/dts/exynos/exynos7.dtsi:90.17-94.5: Warning (simple_bus_reg): /soc/xxti: missing or empty reg/ranges property While moving, change the name of the xxti node to match the generic type of device (following DeviceTree specification). Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-04-24arm64: dts: exynos: Move pmu and timer nodes out of socKrzysztof Kozlowski2-40/+40
The ARM PMU and ARM architected timer nodes are part of ARM CPU design therefore they should not be inside the soc node. This also fixes DTC W=1 warnings like: arch/arm64/boot/dts/exynos/exynos7.dtsi:472.11-480.5: Warning (simple_bus_reg): /soc/arm-pmu: missing or empty reg/ranges property arch/arm64/boot/dts/exynos/exynos7.dtsi:482.9-492.5: Warning (simple_bus_reg): /soc/timer: missing or empty reg/ranges property Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-04-24arm64: KVM: Avoid isb's by using direct pmxevtyper sysregAndrew Murray1-10/+74
Upon entering or exiting a guest we may modify multiple PMU counters to enable of disable EL0 filtering. We presently do this via the indirect PMXEVTYPER_EL0 system register (where the counter we modify is selected by PMSELR). With this approach it is necessary to order the writes via isb instructions such that we select the correct counter before modifying it. Let's avoid potentially expensive instruction barriers by using the direct PMEVTYPER<n>_EL0 registers instead. As the change to counter type relates only to EL0 filtering we can rely on the implicit instruction barrier which occurs when we transition from EL2 to EL1 on entering the guest. On returning to userspace we can, at the latest, rely on the implicit barrier between EL2 and EL0. We can also depend on the explicit isb in armv8pmu_select_counter to order our write against any other kernel changes by the PMU driver to the type register as a result of preemption. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: KVM: Enable VHE support for :G/:H perf event modifiersAndrew Murray4-4/+98
With VHE different exception levels are used between the host (EL2) and guest (EL1) with a shared exception level for userpace (EL0). We can take advantage of this and use the PMU's exception level filtering to avoid enabling/disabling counters in the world-switch code. Instead we just modify the counter type to include or exclude EL0 at vcpu_{load,put} time. We also ensure that trapped PMU system register writes do not re-enable EL0 when reconfiguring the backing perf events. This approach completely avoids blackout windows seen with !VHE. Suggested-by: Christoffer Dall <christoffer.dall@arm.com> Signed-off-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: KVM: Enable !VHE support for :G/:H perf event modifiersAndrew Murray3-0/+48
Enable/disable event counters as appropriate when entering and exiting the guest to enable support for guest or host only event counting. For both VHE and non-VHE we switch the counters between host/guest at EL2. The PMU may be on when we change which counters are enabled however we avoid adding an isb as we instead rely on existing context synchronisation events: the eret to enter the guest (__guest_enter) and eret in kvm_call_hyp for __kvm_vcpu_run_nvhe on returning. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: arm_pmu: Add !VHE support for exclude_host/exclude_guest attributesAndrew Murray1-7/+36
Add support for the :G and :H attributes in perf by handling the exclude_host/exclude_guest event attributes. We notify KVM of counters that we wish to be enabled or disabled on guest entry/exit and thus defer from starting or stopping events based on their event attributes. With !VHE we switch the counters between host/guest at EL2. We are able to eliminate counters counting host events on the boundaries of guest entry/exit when using :G by filtering out EL2 for exclude_host. When using !exclude_hv there is a small blackout window at the guest entry/exit where host events are not captured. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: KVM: Add accessors to track guest/host only countersAndrew Murray3-1/+63
In order to effeciently switch events_{guest,host} perf counters at guest entry/exit we add bitfields to kvm_cpu_context for guest and host events as well as accessors for updating them. A function is also provided which allows the PMU driver to determine if a counter should start counting when it is enabled. With exclude_host, we may only start counting when entering the guest. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: KVM: Encapsulate kvm_cpu_context in kvm_host_dataAndrew Murray3-7/+13
The virt/arm core allocates a kvm_cpu_context_t percpu, at present this is a typedef to kvm_cpu_context and is used to store host cpu context. The kvm_cpu_context structure is also used elsewhere to hold vcpu context. In order to use the percpu to hold additional future host information we encapsulate kvm_cpu_context in a new structure and rename the typedef and percpu to match. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: arm_pmu: Remove unnecessary isb instructionAndrew Murray1-1/+0
The armv8pmu_enable_event_counter function issues an isb instruction after enabling a pair of counters - this doesn't provide any value and is inconsistent with the armv8pmu_disable_event_counter. In any case armv8pmu_enable_event_counter is always called with the PMU stopped. Starting the PMU with armv8pmu_start results in an isb instruction being issued prior to writing to PMCR_EL0. Let's remove the unnecessary isb instruction. Signed-off-by: Andrew Murray <andrew.murray@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24KVM: arm64: Add capability to advertise ptrauth for guestAmit Daniel Kachhap1-0/+5
This patch advertises the capability of two cpu feature called address pointer authentication and generic pointer authentication. These capabilities depend upon system support for pointer authentication and VHE mode. The current arm64 KVM partially implements pointer authentication and support of address/generic authentication are tied together. However, separate ABI requirements for both of them is added so that any future isolated implementation will not require any ABI changes. Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Christoffer Dall <christoffer.dall@arm.com> Cc: kvmarm@lists.cs.columbia.edu Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24KVM: arm64: Add userspace flag to enable pointer authenticationAmit Daniel Kachhap3-1/+30
Now that the building blocks of pointer authentication are present, lets add userspace flags KVM_ARM_VCPU_PTRAUTH_ADDRESS and KVM_ARM_VCPU_PTRAUTH_GENERIC. These flags will enable pointer authentication for the KVM guest on a per-vcpu basis through the ioctl KVM_ARM_VCPU_INIT. This features will allow the KVM guest to allow the handling of pointer authentication instructions or to treat them as undefined if not set. Necessary documentations are added to reflect the changes done. Reviewed-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <marc.zyngier@arm.com> Cc: Christoffer Dall <christoffer.dall@arm.com> Cc: kvmarm@lists.cs.columbia.edu Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24KVM: arm/arm64: Context-switch ptrauth registersMark Rutland8-18/+236
When pointer authentication is supported, a guest may wish to use it. This patch adds the necessary KVM infrastructure for this to work, with a semi-lazy context switch of the pointer auth state. Pointer authentication feature is only enabled when VHE is built in the kernel and present in the CPU implementation so only VHE code paths are modified. When we schedule a vcpu, we disable guest usage of pointer authentication instructions and accesses to the keys. While these are disabled, we avoid context-switching the keys. When we trap the guest trying to use pointer authentication functionality, we change to eagerly context-switching the keys, and enable the feature. The next time the vcpu is scheduled out/in, we start again. However the host key save is optimized and implemented inside ptrauth instruction/register access trap. Pointer authentication consists of address authentication and generic authentication, and CPUs in a system might have varied support for either. Where support for either feature is not uniform, it is hidden from guests via ID register emulation, as a result of the cpufeature framework in the host. Unfortunately, address authentication and generic authentication cannot be trapped separately, as the architecture provides a single EL2 trap covering both. If we wish to expose one without the other, we cannot prevent a (badly-written) guest from intermittently using a feature which is not uniformly supported (when scheduled on a physical CPU which supports the relevant feature). Hence, this patch expects both type of authentication to be present in a cpu. This switch of key is done from guest enter/exit assembly as preparation for the upcoming in-kernel pointer authentication support. Hence, these key switching routines are not implemented in C code as they may cause pointer authentication key signing error in some situations. Signed-off-by: Mark Rutland <mark.rutland@arm.com> [Only VHE, key switch in full assembly, vcpu_has_ptrauth checks , save host key in ptrauth exception trap] Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com> Reviewed-by: Julien Thierry <julien.thierry@arm.com> Cc: Christoffer Dall <christoffer.dall@arm.com> Cc: kvmarm@lists.cs.columbia.edu [maz: various fixups] Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2019-04-24arm64: dts: rockchip: fix IO domain voltage setting of APIO5 on rockpro64Katsuhiro Suzuki1-1/+1
This patch fixes IO domain voltage setting that is related to audio_gpio3d4a_ms (bit 1) of GRF_IO_VSEL. This is because RockPro64 schematics P.16 says that regulator supplies 3.0V power to APIO5_VDD. So audio_gpio3d4a_ms bit should be clear (means 3.0V). Power domain map is saying different thing (supplies 1.8V) but I believe P.16 is actual connectings. Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Cc: stable@vger.kernel.org Suggested-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Katsuhiro Suzuki <katsuhiro@katsuster.net> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-23Merge tag 'syscalls-5.1' of ↵Linus Torvalds2-1/+9
git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic Pull syscall numbering updates from Arnd Bergmann: "arch: add pidfd and io_uring syscalls everywhere This comes a bit late, but should be in 5.1 anyway: we want the newly added system calls to be synchronized across all architectures in the release. I hope that in the future, any newly added system calls can be added to all architectures at the same time, and tested there while they are in linux-next, avoiding dependencies between the architecture maintainer trees and the tree that contains the new system call" * tag 'syscalls-5.1' of git://git.kernel.org/pub/scm/linux/kernel/git/arnd/asm-generic: arch: add pidfd and io_uring syscalls everywhere
2019-04-23arm64: dts: db820c: Add sound card supportSrinivas Kandagatla4-0/+286
This patch adds support both digital and analog audio on DB820c. This board has HDMI port and 3.5mm audio jack to support both digital and analog audio respectively. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arch: mostly remove <asm/segment.h>Christoph Hellwig1-1/+0
A few architectures use <asm/segment.h> internally, but nothing in common code does. Remove all the empty or almost empty versions of it, including the asm-generic one. Signed-off-by: Christoph Hellwig <hch@lst.de> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-04-23arm64: dts: apq8096-db820c: Add HDMI display supportArchit Taneja2-0/+79
The APQ8096 DB820c platform provides HDMI output. The MDSS block on 8x96 supports a direct HDMI out. Populate the MDSS, MDP and HDMI DT nodes. Also, add the HDMI HPD and DDC pinctrl nodes with the bias and driver strength specified for this platform. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: Add Adreno GPU definitionsJordan Crouse1-0/+86
Add an initial node for the Adreno GPU. Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: qcom: msm8996.dtsi: Add Display nodesArchit Taneja1-0/+120
Signed-off-by: Archit Taneja <architt@codeaurora.org> [Removed instances of mmagic clocks; Use qcom,msm8996-smmu-v2 bindings] Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: msm8996: Add display smmu nodeArchit Taneja1-0/+18
Add device node for display smmu, aka. mdp_smmu. Signed-off-by: Archit Taneja <architt@codeaurora.org> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: msm8996: Add graphics smmu nodeJordan Crouse1-0/+19
Add device node for graphics smmu, aka. adreno_smmu. Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Vivek Gautam <vivek.gautam@codeaurora.org> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: sdm845: Add CPU capacity valuesMatthias Kaehlcke1-0/+8
Specify the relative CPU capacity of all SDM845 AP cores. The values were provided by Qualcomm engineers. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Rajendra Nayak <rnayak@codeaurora.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: sdm845: Add CPU topologyMatthias Kaehlcke1-0/+38
The 8 CPU cores of the SDM845 are organized in two clusters of 4 big ("gold") and 4 little ("silver") cores. Add a cpu-map node to the DT that describes this topology. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: sdm845: Set 'bi_tcxo' as ref clock of the DSI PHYsMatthias Kaehlcke1-4/+6
Add 'bi_tcxo' as ref clock for the DSI PHYs, it was previously hardcoded in the PLL 'driver' for the 10nm PHY. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: qcom: msm8916: Set 'xo_board' as ref clock of the DSI PHYMatthias Kaehlcke1-2/+3
Add 'xo_board' as ref clock for the DSI PHYs, it was previously hardcoded in the PLL 'driver' for the 28nm PHY. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: dts: qcom: pm8998: Use ADC temperature to temp-alarm nodeMatthias Kaehlcke1-0/+2
The temperature information from the temp-alarm block itself is very coarse ("temperature is above/below trip points"). Provide the driver with the die temperature channel of the ADC on the PMIC for more precise readings. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Andy Gross <agross@kernel.org>
2019-04-23arm64: Expose SVE2 features for userspaceDave Martin6-1/+51
This patch provides support for reporting the presence of SVE2 and its optional features to userspace. This will also enable visibility of SVE2 for guests, when KVM support for SVE-enabled guests is available. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-19 04:48:24 +0300