aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2020-03-08csky: Implement ftrace with regsGuo Ren6-0/+123
This patch implements FTRACE_WITH_REGS for csky, which allows a traced function's arguments (and some other registers) to be captured into a struct pt_regs, allowing these to be inspected and/or modified. Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
2020-03-08csky: Add support for restartable sequenceGuo Ren3-1/+8
Copied and adapted from vincent's patch, but modified for csky. ref: https://lore.kernel.org/linux-riscv/1572919114-3886-3-git-send-email-vincent.chen@sifive.com/raw Add calls to rseq_signal_deliver(), rseq_handle_notify_resume() and rseq_syscall() to introduce RSEQ support. 1. Call the rseq_handle_notify_resume() function on return to userspace if TIF_NOTIFY_RESUME thread flag is set. 2. Call the rseq_signal_deliver() function to fixup on the pre-signal frame when a signal is delivered on top of a restartable sequence critical section. 3. Check that system calls are not invoked from within rseq critical sections by invoking rseq_signal() from ret_from_syscall(). With CONFIG_DEBUG_RSEQ, such behavior results in termination of the process with SIGSEGV. Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
2020-03-08csky: Implement ptrace regs and stack APIGuo Ren3-0/+145
Needed for kprobes support. Copied and adapted from Patrick's patch, but it has been modified for csky's pt_regs. ref: https://lore.kernel.org/linux-riscv/1572919114-3886-2-git-send-email-vincent.chen@sifive.com/raw Signed-off-by: Guo Ren <ren_guo@c-sky.com> Cc: Patrick Staehlin <me@packi.ch>
2020-03-08csky: Fixup init_fpu compile warning with __initGuo Ren3-6/+5
WARNING: vmlinux.o(.text+0x2366): Section mismatch in reference from the function csky_start_secondary() to the function .init.text:init_fpu() The function csky_start_secondary() references the function __init init_fpu(). This is often because csky_start_secondary lacks a __init annotation or the annotation of init_fpu is wrong. Reported-by: Lu Chongzhi <chongzhi.lcz@alibaba-inc.com> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
2020-03-08ARM: orion5x: ts78xx: Remove unneeded variable retXu Wang1-2/+1
Remove unneeded variable ret used to store return value,just return 0. Signed-off-by: Xu Wang <vulab@iscas.ac.cn> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-08ARM: orion5x: Drop unneeded select of PCI_DOMAINS_GENERICGeert Uytterhoeven1-2/+0
Support for Marvell Orion SoCs depends on ARCH_MULTI_V5, and thus on ARCH_MULTIPLATFORM. As the latter selects GENERIC_CLOCKEVENTS and USE_OF, there is no need for ARCH_ORION5X and ARCH_ORION5X_DT to select any of them. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Andrew Lunn <andrew@lunn.ch> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com> Cc: Gregory Clement <gregory.clement@bootlin.com> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2020-03-08x86/apic/vector: Force interupt handler invocation to irq contextThomas Gleixner1-0/+6
Sathyanarayanan reported that the PCI-E AER error injection mechanism can result in a NULL pointer dereference in apic_ack_edge(): BUG: unable to handle kernel NULL pointer dereference at 0000000000000078 RIP: 0010:apic_ack_edge+0x1e/0x40 Call Trace: handle_edge_irq+0x7d/0x1e0 generic_handle_irq+0x27/0x30 aer_inject_write+0x53a/0x720 It crashes in irq_complete_move() which dereferences get_irq_regs() which is obviously NULL when this is called from non interrupt context. Of course the pointer could be checked, but that just papers over the real issue. Invoking the low level interrupt handling mechanism from random code can wreckage the fragile interrupt affinity mechanism of x86 as interrupts can only be moved in interrupt context or with special care when a CPU goes offline and the move has to be enforced. In the best case this triggers the warning in the MSI affinity setter, but if the call happens on the correct CPU it just corrupts state and might prevent further interrupt delivery for the affected device. Mark the APIC interrupts as unsuitable for being invoked in random contexts. This prevents the AER injection from proliferating the wreckage, but that's less broken than the current state of affairs and more correct than just papering over the problem by sprinkling random checks all over the place and silently corrupting state. Reported-by: sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/20200306130623.684591280@linutronix.de
2020-03-08efi/x86: Preserve %ebx correctly in efi_set_virtual_address_map()Ard Biesheuvel1-1/+1
Commit: 59f2a619a2db8611 ("efi: Add 'runtime' pointer to struct efi") modified the assembler routine called by efi_set_virtual_address_map(), to grab the 'runtime' EFI service pointer while running with paging disabled (which is tricky to do in C code) After the change, register %ebx is not restored correctly, resulting in all kinds of weird behavior, so fix that. Reported-by: Guenter Roeck <linux@roeck-us.net> Tested-by: Guenter Roeck <linux@roeck-us.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200304133515.15035-1-ardb@kernel.org Link: https://lore.kernel.org/r/20200308080859.21568-22-ardb@kernel.org
2020-03-08efi/x86: Don't relocate the kernel unless necessaryArvind Sankar1-10/+6
Add alignment slack to the PE image size, so that we can realign the decompression buffer within the space allocated for the image. Only relocate the kernel if it has been loaded at an unsuitable address: - Below LOAD_PHYSICAL_ADDR, or - Above 64T for 64-bit and 512MiB for 32-bit For 32-bit, the upper limit is conservative, but the exact limit can be difficult to calculate. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-6-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-20-ardb@kernel.org
2020-03-08efi/x86: Remove extra headroom for setup blockArvind Sankar1-2/+26
The following commit: 223e3ee56f77 ("efi/x86: add headroom to decompressor BSS to account for setup block") added headroom to the PE image to account for the setup block, which wasn't used for the decompression buffer. Now that the decompression buffer is located at the start of the image, and includes the setup block, this is no longer required. Add a check to make sure that the head section of the compressed kernel won't overwrite itself while relocating. This is only for future-proofing as with current limits on the setup and the actual size of the head section, this can never happen. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-5-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-19-ardb@kernel.org
2020-03-08efi/x86: Add kernel preferred address to PE headerArvind Sankar1-2/+4
Store the kernel's link address as ImageBase in the PE header. Note that the PE specification requires the ImageBase to be 64k aligned. The preferred address should almost always satisfy that, except for 32-bit kernel if the configuration has been customized. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-4-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-18-ardb@kernel.org
2020-03-08efi/x86: Decompress at start of PE image load addressArvind Sankar2-3/+56
When booted via PE loader, define image_offset to hold the offset of startup_32() from the start of the PE image, and use it as the start of the decompression buffer. [ mingo: Fixed the grammar in the comments. ] Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-3-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-17-ardb@kernel.org
2020-03-08x86/boot/compressed/32: Save the output address instead of recalculating itArvind Sankar1-13/+12
In preparation for being able to decompress into a buffer starting at a different address than startup_32, save the calculated output address instead of recalculating it later. We now keep track of three addresses: %edx: startup_32 as we were loaded by bootloader %ebx: new location of compressed kernel %ebp: start of decompression buffer Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200303221205.4048668-2-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-16-ardb@kernel.org
2020-03-08x86/boot: Use unsigned comparison for addressesArvind Sankar2-3/+3
The load address is compared with LOAD_PHYSICAL_ADDR using a signed comparison currently (using jge instruction). When loading a 64-bit kernel using the new efi32_pe_entry() point added by: 97aa276579b2 ("efi/x86: Add true mixed mode entry point into .compat section") using Qemu with -m 3072, the firmware actually loads us above 2Gb, resulting in a very early crash. Use the JAE instruction to perform a unsigned comparison instead, as physical addresses should be considered unsigned. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200301230436.2246909-6-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-14-ardb@kernel.org
2020-03-08efi/x86: Avoid using code32_startArvind Sankar3-5/+3
code32_start is meant for 16-bit real-mode bootloaders to inform the kernel where the 32-bit protected mode code starts. Nothing in the protected mode kernel except the EFI stub uses it. efi_main() currently returns boot_params, with code32_start set inside it to tell efi_stub_entry() where startup_32 is located. Since it was invoked by efi_stub_entry() in the first place, boot_params is already known. Return the address of startup_32 instead. This will allow a 64-bit kernel to live above 4Gb, for example, and it's cleaner as well. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200301230436.2246909-5-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-13-ardb@kernel.org
2020-03-08efi/x86: Make efi32_pe_entry() more readableArvind Sankar1-17/+40
Set up a proper frame pointer in efi32_pe_entry() so that it's easier to calculate offsets for arguments. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200301230436.2246909-4-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-12-ardb@kernel.org
2020-03-08efi/x86: Respect 32-bit ABI in efi32_pe_entry()Arvind Sankar1-0/+4
verify_cpu() clobbers BX and DI. In case we have to return error, we need to preserve them to respect the 32-bit calling convention. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200301230436.2246909-3-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-11-ardb@kernel.org
2020-03-08efi/x86: Annotate the LOADED_IMAGE_PROTOCOL_GUID with SYM_DATAArvind Sankar1-3/+6
Use SYM_DATA*() macros to annotate this constant, and explicitly align it to 4-byte boundary. Use lower-case for hexadecimal data. Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20200301230436.2246909-2-nivedita@alum.mit.edu Link: https://lore.kernel.org/r/20200308080859.21568-10-ardb@kernel.org
2020-03-08Merge branch 'efi/urgent' into efi/core, to pick up fixesIngo Molnar47-281/+382
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-03-08Merge tag 'efi-next' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi into efi/coreIngo Molnar2-0/+6
More EFI updates for v5.7 - Incorporate a stable branch with the EFI pieces of Hans's work on loading device firmware from EFI boot service memory regions Signed-off-by: Ingo Molnar <mingo@kernel.org>
2020-03-07ARM: dts: keystone-k2g-evm: add HDMI video supportJyri Sarha1-0/+101
Add DT nodes for HDMI video support for K2G EVM. The HDMI uses SiI9022 DPI as HDMI encoder. The DSS DPI is connected to SiI9022 HDMI encoder's video input and encoder's output goes to HDMI connector. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-03-07ARM: dts: keystone-k2g: Add DSS nodeJyri Sarha1-0/+22
Add DT node for DSS. K2G has DSS version 6. Keystone family DSS are somewhat different compered to the old OMAP family DSSes and the binding looks different too. Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by: Jyri Sarha <jsarha@ti.com> Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
2020-03-07Merge tag 's390-5.6-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linuxLinus Torvalds2-2/+8
Pull s390 fixes from Vasily Gorbik: - Fix panic in gup_fast on large pud by providing an implementation of pud_write. This has been overlooked during migration to common gup code. - Fix unexpected write combining on PCI stores. * tag 's390-5.6-5' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux: s390/pci: Fix unexpected write combine on resource s390/mm: fix panic in gup_fast on large pud
2020-03-07Merge tag 'powerpc-5.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds4-6/+18
Pull powerpc fixes from Michael Ellerman: "Some more powerpc fixes for 5.6: - One fix for a recent regression to our breakpoint/watchpoint code. - Another fix for our KUAP support, this time a missing annotation in a rarely used path in signal handling. - A fix for our handling of a CPU feature that effects the PMU, when booting guests in some configurations. - A minor fix to our linker script to explicitly include the .BTF section. Thanks to: Christophe Leroy, Desnes A. Nunes do Rosario, Leonardo Bras, Naveen N. Rao, Ravi Bangoria, Stefan Berger" * tag 'powerpc-5.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm: Fix missing KUAP disable in flush_coherent_icache() powerpc: fix hardware PMU exception bug on PowerVM compatibility mode systems powerpc: Include .BTF section powerpc/watchpoint: Don't call dar_within_range() for Book3S
2020-03-07MIPS: DTS: CI20: fix interrupt for pcf8563 RTCH. Nikolaus Schaller1-1/+4
Interrupts should not be specified by interrupt line but by gpio parent and reference. Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes") Cc: stable@vger.kernel.org Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-03-07MIPS: DTS: CI20: fix PMU definitions for ACT8600H. Nikolaus Schaller1-15/+24
There is a ACT8600 on the CI20 board and the bindings of the ACT8865 driver have changed without updating the CI20 device tree. Therefore the PMU can not be probed successfully and is running in power-on reset state. Fix DT to match the latest act8865-regulator bindings. Fixes: 73f2b940474d ("MIPS: CI20: DTS: Add I2C nodes") Cc: stable@vger.kernel.org Signed-off-by: H. Nikolaus Schaller <hns@goldelico.com> Reviewed-by: Paul Cercueil <paul@crapouillou.net> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
2020-03-06um: reject unsupported coalescing paramsJakub Kicinski1-0/+1
Set ethtool_ops->supported_coalesce_params to let the core reject unsupported coalescing parameters. This driver did not previously reject unsupported parameters. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-06arm64: dts: ls1043a: FMan erratum A050385Madalin Bucur1-0/+2
The LS1043A SoC is affected by the A050385 erratum stating that FMAN DMA read or writes under heavy traffic load may cause FMAN internal resource leak thus stopping further packet processing. Signed-off-by: Madalin Bucur <madalin.bucur@nxp.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2020-03-06arm64: dts: qcom: db845c: add Low speed expansion i2c and spi nodesSrinivas Kandagatla1-0/+34
This patch adds support UART0, I2C0, I2C1 and SPI0 available on Low Speed expansion connector. Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20200305145344.14670-5-srinivas.kandagatla@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-06arm64: dts: qcom: apq8016-sbc: Remove wrong regulator supplyLoic Poulain1-1/+0
As specified in the smd-rpm-regulator binding and confirmed by the pm8616 device specification, there is no vdd_l5. l5 vdd comes from vdd_l4_l5_l6. Fix that (though it does not cause any issue since the supply is not requested). Signed-off-by: Loic Poulain <loic.poulain@linaro.org> Link: https://lore.kernel.org/r/1583516368-29593-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2020-03-06Merge tag 'riscv-for-linus-5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linuxLinus Torvalds11-53/+65
Pull RISC-V fixes from Palmer Dabbelt: "This contains a handful of fixes that I would like to target for 5.6: - A pair of fixes to module loading, which we hope solve the last of the issues with module text being loaded too sparsely for our call relocations. - A Kconfig fix that disallows selecting memory models not supported by NOMMU. - A series of Kconfig updates to ease selecting the drivers necessary to run on QEMU's virt platform. - DTS updates for SiFive's HiFive Unleashed. - A fix to our seccomp support that avoids mangling restartable syscalls" * tag 'riscv-for-linus-5.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: fix seccomp reject syscall code path riscv: dts: Add GPIO reboot method to HiFive Unleashed DTS file RISC-V: Select Goldfish RTC driver for QEMU virt machine RISC-V: Select SYSCON Reboot and Poweroff for QEMU virt machine RISC-V: Enable QEMU virt machine support in defconfigs RISC-V: Add kconfig option for QEMU virt machine riscv: Fix range looking for kernel image memblock riscv: Force flat memory model with no-mmu riscv: Change code model of module to medany to improve data accessing riscv: avoid the PIC offset of static percpu data in module beyond 2G limits
2020-03-06ARM: omap2plus_defconfig: Enable ext4 security for setcapTony Lindgren1-0/+1
Enable ext4 security for setcap. Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linuxLinus Torvalds1-5/+15
Pull arm64 fixes from Will Deacon: "Here are another three arm64 fixes for 5.6, all pretty minor. Main thing is fixing a silly bug in the fsl_imx8_ddr PMU driver where we would zero the counters when disabling them. - Fix misreporting of ASID limit when KPTI is enabled - Fix busted NULL pointer checks for GICC structure in ACPI PMU code - Avoid nobbling the "fsl_imx8_ddr" PMU counters when disabling them" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: context: Fix ASID limit in boot messages drivers/perf: arm_pmu_acpi: Fix incorrect checking of gicc pointer drivers/perf: fsl_imx8_ddr: Correct the CLEAR bit definition
2020-03-06arm64: dts: rockchip: Add initial support for Pinebook ProTobias Schramm2-0/+1097
This commit adds initial dt support for the rk3399 based Pinebook Pro. Signed-off-by: Tobias Schramm <t.schramm@manjaro.org> Link: https://lore.kernel.org/r/20200304213023.689983-3-t.schramm@manjaro.org Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2020-03-06arm64: use activity monitors for frequency invarianceIonela Voinescu3-0/+193
The Frequency Invariance Engine (FIE) is providing a frequency scaling correction factor that helps achieve more accurate load-tracking. So far, for arm and arm64 platforms, this scale factor has been obtained based on the ratio between the current frequency and the maximum supported frequency recorded by the cpufreq policy. The setting of this scale factor is triggered from cpufreq drivers by calling arch_set_freq_scale. The current frequency used in computation is the frequency requested by a governor, but it may not be the frequency that was implemented by the platform. This correction factor can also be obtained using a core counter and a constant counter to get information on the performance (frequency based only) obtained in a period of time. This will more accurately reflect the actual current frequency of the CPU, compared with the alternative implementation that reflects the request of a performance level from the OS. Therefore, implement arch_scale_freq_tick to use activity monitors, if present, for the computation of the frequency scale factor. The use of AMU counters depends on: - CONFIG_ARM64_AMU_EXTN - depents on the AMU extension being present - CONFIG_CPU_FREQ - the current frequency obtained using counter information is divided by the maximum frequency obtained from the cpufreq policy. While it is possible to have a combination of CPUs in the system with and without support for activity monitors, the use of counters for frequency invariance is only enabled for a CPU if all related CPUs (CPUs in the same frequency domain) support and have enabled the core and constant activity monitor counters. In this way, there is a clear separation between the policies for which arch_set_freq_scale (cpufreq based FIE) is used, and the policies for which arch_scale_freq_tick (counter based FIE) is used to set the frequency scale factor. For this purpose, a late_initcall_sync is registered to trigger validation work for policies that will enable or disable the use of AMU counters for frequency invariance. If CONFIG_CPU_FREQ is not defined, the use of counters is enabled on all CPUs only if all possible CPUs correctly support the necessary counters. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Sudeep Holla <sudeep.holla@arm.com> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-06arm64/kvm: disable access to AMU registers from kvm guestsIonela Voinescu3-3/+105
Access to the AMU counters should be disabled by default in kvm guests, as information from the counters might reveal activity in other guests or activity on the host. Therefore, disable access to AMU registers from EL0 and EL1 in kvm guests by: - Hiding the presence of the extension in the feature register (SYS_ID_AA64PFR0_EL1) on the VCPU. - Disabling access to the AMU registers before switching to the guest. - Trapping accesses and injecting an undefined instruction into the guest. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Acked-by: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Julien Thierry <julien.thierry.kdev@gmail.com> Cc: James Morse <james.morse@arm.com> Cc: Marc Zyngier <maz@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-06arm64: trap to EL1 accesses to AMU counters from EL0Ionela Voinescu2-0/+13
The activity monitors extension is an optional extension introduced by the ARMv8.4 CPU architecture. In order to access the activity monitors counters safely, if desired, the kernel should detect the presence of the extension through the feature register, and mediate the access. Therefore, disable direct accesses to activity monitors counters from EL0 (userspace) and trap them to EL1 (kernel). To be noted that the ARM64_AMU_EXTN kernel config does not have an effect on this code. Given that the amuserenr_el0 resets to an UNKNOWN value, setting the trap of EL0 accesses to EL1 is always attempted for safety and security considerations. Therefore firmware should still ensure accesses to AMU registers are not trapped in EL2/EL3 as this code cannot be bypassed if the CPU implements the Activity Monitors Unit. Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by: James Morse <james.morse@arm.com> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Steve Capper <steve.capper@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-06arm64: add support for the AMU extension v1Ionela Voinescu5-1/+138
The activity monitors extension is an optional extension introduced by the ARMv8.4 CPU architecture. This implements basic support for version 1 of the activity monitors architecture, AMUv1. This support includes: - Extension detection on each CPU (boot, secondary, hotplugged) - Register interface for AMU aarch64 registers Signed-off-by: Ionela Voinescu <ionela.voinescu@arm.com> Reviewed-by: Valentin Schneider <valentin.schneider@arm.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Marc Zyngier <maz@kernel.org> Cc: Suzuki K Poulose <suzuki.poulose@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2020-03-06ARM: OMAP2+: Drop legacy platform data for dra7 edmaTony Lindgren2-91/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: OMAP2+: Drop legacy platform data for am3 and am4 edmaTony Lindgren7-138/+0
We can now probe devices with ti-sysc interconnect driver and dts data. Let's drop the related platform data and custom ti,hwmods dts property. As we're just dropping data, and the early platform data init is based on the custom ti,hwmods property, we want to drop both the platform data and ti,hwmods property in a single patch. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for dra7 tptc1Tony Lindgren1-5/+16
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for dra7 tptc0Tony Lindgren1-5/+16
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for dra7 tpccTony Lindgren1-18/+29
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am4 tptc2Tony Lindgren1-5/+21
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am4 tptc1Tony Lindgren1-5/+21
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am4 tptc0Tony Lindgren1-5/+21
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am4 tpccTony Lindgren1-14/+25
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am3 tptc2Tony Lindgren1-5/+21
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am3 tptc1Tony Lindgren1-5/+21
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2020-03-06ARM: dts: Configure interconnect target module for am3 tptc0Tony Lindgren1-5/+21
We can now probe devices with device tree only configuration using ti-sysc interconnect target module driver. Let's configure the module, but keep the legacy "ti,hwmods" peroperty to avoid new boot time warnings. The legacy property will be removed in later patches together with the legacy platform data. Let's also correct the custom node name to use generic node name dma. Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>