aboutsummaryrefslogtreecommitdiffstats
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2021-12-08KVM: Let/force architectures to deal with arch specific memslot dataSean Christopherson11-37/+56
Pass the "old" slot to kvm_arch_prepare_memory_region() and force arch code to handle propagating arch specific data from "new" to "old" when necessary. This is a baby step towards dynamically allocating "new" from the get go, and is a (very) minor performance boost on x86 due to not unnecessarily copying arch data. For PPC HV, copy the rmap in the !CREATE and !DELETE paths, i.e. for MOVE and FLAGS_ONLY. This is functionally a nop as the previous behavior would overwrite the pointer for CREATE, and eventually discard/ignore it for DELETE. For x86, copy the arch data only for FLAGS_ONLY changes. Unlike PPC HV, x86 needs to reallocate arch data in the MOVE case as the size of x86's allocations depend on the alignment of the memslot's gfn. Opportunistically tweak kvm_arch_prepare_memory_region()'s param order to match the "commit" prototype. Signed-off-by: Sean Christopherson <seanjc@google.com> Reviewed-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> [mss: add missing RISCV kvm_arch_prepare_memory_region() change] Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com> Message-Id: <67dea5f11bbcfd71e3da5986f11e87f5dd4013f9.1638817639.git.maciej.szmigiero@oracle.com>
2021-12-08KVM: Use 'unsigned long' as kvm_for_each_vcpu()'s indexMarc Zyngier37-97/+110
Everywhere we use kvm_for_each_vpcu(), we use an int as the vcpu index. Unfortunately, we're about to move rework the iterator, which requires this to be upgrade to an unsigned long. Let's bite the bullet and repaint all of it in one go. Signed-off-by: Marc Zyngier <maz@kernel.org> Message-Id: <20211116160403.4074052-7-maz@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08KVM: s390: Use kvm_get_vcpu() instead of open-coded accessMarc Zyngier1-3/+5
As we are about to change the way vcpus are allocated, mandate the use of kvm_get_vcpu() instead of open-coding the access. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Message-Id: <20211116160403.4074052-4-maz@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08KVM: mips: Use kvm_get_vcpu() instead of open-coded accessMarc Zyngier2-3/+3
As we are about to change the way vcpus are allocated, mandate the use of kvm_get_vcpu() instead of open-coding the access. Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Message-Id: <20211116160403.4074052-3-maz@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08KVM: Move wiping of the kvm->vcpus array to common codeMarc Zyngier6-72/+6
All architectures have similar loops iterating over the vcpus, freeing one vcpu at a time, and eventually wiping the reference off the vcpus array. They are also inconsistently taking the kvm->lock mutex when wiping the references from the array. Make this code common, which will simplify further changes. The locking is dropped altogether, as this should only be called when there is no further references on the kvm structure. Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Marc Zyngier <maz@kernel.org> Message-Id: <20211116160403.4074052-2-maz@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08KVM: MMU: update comment on the number of page role combinationsPaolo Bonzini1-12/+18
Fix the number of bits in the role, and simplify the explanation of why several bits or combinations of bits are redundant. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-12-08ARM: dts: sun8i: r40: add node for CAN controllerEvgeny Boger1-0/+19
Allwinner R40 (also known as A40i, T3, V40) has a CAN controller. The controller is the same as in earlier A10 and A20 SoCs, but needs reset line to be deasserted before use. This patch adds a CAN node and the corresponding pinctrl descriptions. Link: https://lore.kernel.org/all/20211122104616.537156-4-boger@wirenboard.com Signed-off-by: Evgeny Boger <boger@wirenboard.com> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2021-12-08csky: fix typo of fpu config macroKelly Devilliv1-2/+2
Fix typo which will cause fpe and privilege exception error. Signed-off-by: Kelly Devilliv <kelly.devilliv@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
2021-12-07arm64: dts: apple: t8103: Mark PCIe PERST# polarity active low in DTMarc Zyngier1-3/+4
As the name indicates, PERST# is active low. Fix the DT description to match the HW behaviour. Fixes: ff2a8d91d80c ("arm64: apple: Add PCIe node") Link: https://lore.kernel.org/r/20211123180636.80558-3-maz@kernel.org Signed-off-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Luca Ceresoli <luca@lucaceresoli.net> Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Acked-by: Arnd Bergmann <arnd@arndb.de>
2021-12-07arm: ioremap: Remove unused ARM-specific function pci_ioremap_io()Pali Rohár2-13/+0
This function is not used by any driver anymore. So completely remove it. Link: https://lore.kernel.org/r/20211124154116.916-6-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-12-07arm: ioremap: Replace pci_ioremap_io() usage by pci_remap_iospace()Pali Rohár4-8/+21
Replace all usage of ARM specific pci_ioremap_io() function by standard PCI core API function pci_remap_iospace() in all drivers and ARM mach code. Link: https://lore.kernel.org/r/20211124154116.916-5-pali@kernel.org Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk> Reviewed-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2021-12-07arm64: defconfig: Enable R-Car S4-8Yoshihiro Shimoda1-0/+1
Enable the Renesas R-Car S4-8 (R8A779F0) SoC in the ARM64 defconfig. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20211201073308.1003945-15-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-12-07arm64: dts: renesas: Add Renesas Spider boards supportYoshihiro Shimoda3-0/+60
Initial support for the Renesas Spider CPU and BreakOut boards. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Tested-by: Takehito Nakamura <takehito.nakamura.nx@renesas.com> Link: https://lore.kernel.org/r/20211201073308.1003945-14-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-12-07arm64: dts: renesas: Add Renesas R8A779F0 SoC supportYoshihiro Shimoda1-0/+121
Add initial support for the Renesas R8A779F0 (R-Car S4-8) SoC. Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Link: https://lore.kernel.org/r/20211201073308.1003945-13-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-12-07arm64: dts: renesas: Fix thermal bindingsKieran Bingham9-28/+28
The binding node names for the thermal zones are not successfully validated by the dt-schemas. Fix the validation by changing from sensor-thermalN or thermal-sensor-N to sensorN-thermal. Provide node labels of the form sensorN_thermal to ensure consistency with the other platform implementations. Signed-off-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Link: https://lore.kernel.org/r/20211104224033.3997504-1-kieran.bingham+renesas@ideasonboard.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
2021-12-07arm64: dts: apple: t8103: Remove PCIe max-link-speed propertiesHector Martin1-3/+0
The driver doesn't support these, they shouldn't be in the SoC include anyway, and we're now configuring this in the bootloader instead. This also solves the j274 1G/10G Ethernet variant discrepancy, since that will now be configured properly based on the dynamic ADT property. Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2021-12-07locking: Allow to include asm/spinlock_types.h from linux/spinlock_types_raw.hSebastian Andrzej Siewior12-12/+12
The printk header file includes ratelimit_types.h for its __ratelimit() based usage. It is required for the static initializer used in printk_ratelimited(). It uses a raw_spinlock_t and includes the spinlock_types.h. PREEMPT_RT substitutes spinlock_t with a rtmutex based implementation and so its spinlock_t implmentation (provided by spinlock_rt.h) includes rtmutex.h and atomic.h which leads to recursive includes where defines are missing. By including only the raw_spinlock_t defines it avoids the atomic.h related includes at this stage. An example on powerpc: | CALL scripts/atomic/check-atomics.sh |In file included from include/linux/bug.h:5, | from include/linux/page-flags.h:10, | from kernel/bounds.c:10: |arch/powerpc/include/asm/page_32.h: In function ‘clear_page’: |arch/powerpc/include/asm/bug.h:87:4: error: implicit declaration of function â=80=98__WARNâ=80=99 [-Werror=3Dimplicit-function-declaration] | 87 | __WARN(); \ | | ^~~~~~ |arch/powerpc/include/asm/page_32.h:48:2: note: in expansion of macro ‘WARN_ONâ€=99 | 48 | WARN_ON((unsigned long)addr & (L1_CACHE_BYTES - 1)); | | ^~~~~~~ |arch/powerpc/include/asm/bug.h:58:17: error: invalid application of ‘sizeofâ€=99 to incomplete type ‘struct bug_entryâ€=99 | 58 | "i" (sizeof(struct bug_entry)), \ | | ^~~~~~ |arch/powerpc/include/asm/bug.h:89:3: note: in expansion of macro ‘BUG_ENTRYâ€=99 | 89 | BUG_ENTRY(PPC_TLNEI " %4, 0", \ | | ^~~~~~~~~ |arch/powerpc/include/asm/page_32.h:48:2: note: in expansion of macro ‘WARN_ONâ€=99 | 48 | WARN_ON((unsigned long)addr & (L1_CACHE_BYTES - 1)); | | ^~~~~~~ |In file included from arch/powerpc/include/asm/ptrace.h:298, | from arch/powerpc/include/asm/hw_irq.h:12, | from arch/powerpc/include/asm/irqflags.h:12, | from include/linux/irqflags.h:16, | from include/asm-generic/cmpxchg-local.h:6, | from arch/powerpc/include/asm/cmpxchg.h:526, | from arch/powerpc/include/asm/atomic.h:11, | from include/linux/atomic.h:7, | from include/linux/rwbase_rt.h:6, | from include/linux/rwlock_types.h:55, | from include/linux/spinlock_types.h:74, | from include/linux/ratelimit_types.h:7, | from include/linux/printk.h:10, | from include/asm-generic/bug.h:22, | from arch/powerpc/include/asm/bug.h:109, | from include/linux/bug.h:5, | from include/linux/page-flags.h:10, | from kernel/bounds.c:10: |include/linux/thread_info.h: In function â=80=98copy_overflowâ=80=99: |include/linux/thread_info.h:210:2: error: implicit declaration of function â=80=98WARNâ=80=99 [-Werror=3Dimplicit-function-declaration] | 210 | WARN(1, "Buffer overflow detected (%d < %lu)!\n", size, count); | | ^~~~ The WARN / BUG include pulls in printk.h and then ptrace.h expects WARN (from bug.h) which is not yet complete. Even hw_irq.h has WARN_ON() statements. On POWERPC64 there are missing atomic64 defines while building 32bit VDSO: | VDSO32C arch/powerpc/kernel/vdso32/vgettimeofday.o |In file included from include/linux/atomic.h:80, | from include/linux/rwbase_rt.h:6, | from include/linux/rwlock_types.h:55, | from include/linux/spinlock_types.h:74, | from include/linux/ratelimit_types.h:7, | from include/linux/printk.h:10, | from include/linux/kernel.h:19, | from arch/powerpc/include/asm/page.h:11, | from arch/powerpc/include/asm/vdso/gettimeofday.h:5, | from include/vdso/datapage.h:137, | from lib/vdso/gettimeofday.c:5, | from <command-line>: |include/linux/atomic-arch-fallback.h: In function ‘arch_atomic64_incâ€=99: |include/linux/atomic-arch-fallback.h:1447:2: error: implicit declaration of function ‘arch_atomic64_add’; did you mean ‘arch_atomic_add’? [-Werror=3Dimpl |icit-function-declaration] | 1447 | arch_atomic64_add(1, v); | | ^~~~~~~~~~~~~~~~~ | | arch_atomic_add The generic fallback is not included, atomics itself are not used. If kernel.h does not include printk.h then it comes later from the bug.h include. Allow asm/spinlock_types.h to be included from linux/spinlock_types_raw.h. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20211129174654.668506-12-bigeasy@linutronix.de
2021-12-07x86/mm: Include spinlock_t definition in pgtable.Sebastian Andrzej Siewior1-0/+1
This header file provides forward declartion for pgd_lock but does not include the header defining its type. This works since the definition of spinlock_t is usually included somehow via printk. By trying to avoid recursive includes on PREEMPT_RT I avoided the loop in printk and as a consequnce kernel/intel.c failed to compile due to missing type definition. Include the needed definition for spinlock_t. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Link: https://lkml.kernel.org/r/20211129174654.668506-11-bigeasy@linutronix.de
2021-12-07arm64: dts: ti: k3-am642-evm/sk: Add support for main domain mcan nodes in EVM and disable them on SKAswath Govindraju2-0/+48
AM642 EVM has two CAN connecters brought out from the two MCAN instances in the main domain through transceivers. Add device tree nodes for transceivers and set the required properties in the mcan device tree nodes, in EVM device tree file. On AM642 SK there are no connectors brought out for CAN. Therefore, disable the mcan device tree nodes in the SK device tree file. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-7-a-govindraju@ti.com
2021-12-07arm64: dts: ti: k3-am64-main: Add support for MCANAswath Govindraju1-0/+28
Add Support for two MCAN controllers present on the am64x SOC. Both support classic CAN messages as well as CAN-FD. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-6-a-govindraju@ti.com
2021-12-07arm64: dts: ti: k3-j721e-common-proc-board: Add support for mcu and main mcan nodesFaiz Abbas1-0/+155
Add four MCAN nodes present on the common processor board and set a maximum data rate of 5 Mbps. Disable all other nodes as they are not brought out on the common processor board. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-5-a-govindraju@ti.com
2021-12-07arm64: dts: ti: k3-j721e: Add support for MCAN nodesFaiz Abbas2-0/+224
Add support for 14 MCAN controllers in main domain and 2 MCAN controllers present in mcu domain. All the MCAN controllers support classic CAN messages as well as CAN_FD messages. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-4-a-govindraju@ti.com
2021-12-07arm64: dts: ti: am654-base-board/am65-iot2050-common: Disable mcan nodesAswath Govindraju2-0/+16
AM654 base board and iot platforms do not have mcan instances pinned out. Therefore, disable all the mcan instances. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-3-a-govindraju@ti.com
2021-12-07arm64: dts: ti: k3-am65-mcu: Add Support for MCANFaiz Abbas1-0/+30
Add Support for two MCAN controllers present on the am65x SOC. Both support classic CAN messages as well as CAN-FD. Signed-off-by: Faiz Abbas <faiz_abbas@ti.com> Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Reviewed-by: Apurva Nandan <a-nandan@ti.com> Link: https://lore.kernel.org/r/20211122134159.29936-2-a-govindraju@ti.com
2021-12-07Merge branch kvm-arm64/misc-5.17 into kvmarm-master/nextMarc Zyngier4-2/+4
* kvm-arm64/misc-5.17: : . : - Add minimal support for ARMv8.7's PMU extension : - Constify kvm_io_gic_ops : - Drop kvm_is_transparent_hugepage() prototype : . KVM: Drop stale kvm_is_transparent_hugepage() declaration KVM: arm64: Constify kvm_io_gic_ops KVM: arm64: Add minimal handling for the ARMv8.7 PMU Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-12-07Merge branch kvm-arm64/hyp-header-split into kvmarm-master/nextMarc Zyngier11-63/+109
* kvm-arm64/hyp-header-split: : . : Tidy up the header file usage for the nvhe hyp object so : that header files under arch/arm64/kvm/hyp/include are not : included by host code running at EL1. : . KVM: arm64: Move host EL1 code out of hyp/ directory KVM: arm64: Generate hyp_constants.h for the host arm64: Add missing include of asm/cpufeature.h to asm/mmu.h Signed-off-by: Marc Zyngier <maz@kernel.org>
2021-12-07arm64: dts: apple: t8103: Expose PCI node for the WiFi MAC addressMark Kettenis1-0/+6
Expose the PCI node corresponding to the WiFi device and give it a 'local-mac-address' property. The bootloader will update it (m1n1 already has the required feature). Signed-off-by: Mark Kettenis <kettenis@openbsd.org> Acked-by: Marc Zyngier <maz@kernel.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2021-12-07arm64: dts: apple: t8103: Add UART2Hector Martin2-0/+17
This UART is connected to the debug port of the WLAN module. It is mostly useless, but makes for a good test case for runtime-pm without having to unbind the console from the main system UART. Reviewed-by: Mark Kettenis <kettenis@openbsd.org> Signed-off-by: Hector Martin <marcan@marcan.st>
2021-12-07arm64: dts: apple: t8103: Add PMGR nodesHector Martin2-0/+1165
This adds the two PMGR nodes and all known power state subnodes. Since there are a large number of them, let's put them in a separate file to include. Reviewed-by: Sven Peter <sven@svenpeter.dev> Signed-off-by: Hector Martin <marcan@marcan.st>
2021-12-07ARM: dts: aspeed: add device tree for YADRO VEGMAN BMCAndrei Kartashev5-1/+873
YADRO VEGMAN is x86 based servers family with ASPEED AST2500-based BMC. Currently there are three models: * VEGMAN N110 * VEGMAN S220/320 * VEGMAN R120/220 The dts files provides configuration for BMC system. Signed-off-by: Andrei Kartashev <a.kartashev@yadro.com> Link: https://lore.kernel.org/r/20211119120057.12118-3-a.kartashev@yadro.com Reviewed-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Joel Stanley <joel@jms.id.au>
2021-12-06Merge tag 'efi-urgent-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efiLinus Torvalds2-1/+3
Pull EFI fix from Ard Biesheuvel: "Ensure that the EFI memory map resides in encrypted memory even after it has been reallocated" * tag 'efi-urgent-for-v5.16' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi: x86/sme: Explicitly map new EFI memmap table as encrypted
2021-12-06arm64: mte: DC {GVA,GZVA} shouldn't be used when DCZID_EL0.DZP == 1Reiji Watanabe2-4/+12
Currently, mte_set_mem_tag_range() and mte_zero_clear_page_tags() use DC {GVA,GZVA} unconditionally. But, they should make sure that DCZID_EL0.DZP, which indicates whether or not use of those instructions is prohibited, is zero when using those instructions. Use ST{G,ZG,Z2G} instead when DCZID_EL0.DZP == 1. Fixes: 013bb59dbb7c ("arm64: mte: handle tags zeroing at page allocation time") Fixes: 3d0cca0b02ac ("kasan: speed up mte_set_mem_tag_range") Signed-off-by: Reiji Watanabe <reijiw@google.com> Link: https://lore.kernel.org/r/20211206004736.1520989-3-reijiw@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-06arm64: clear_page() shouldn't use DC ZVA when DCZID_EL0.DZP == 1Reiji Watanabe1-0/+10
Currently, clear_page() uses DC ZVA instruction unconditionally. But it should make sure that DCZID_EL0.DZP, which indicates whether or not use of DC ZVA instruction is prohibited, is zero when using the instruction. Use STNP instead when DCZID_EL0.DZP == 1. Fixes: f27bb139c387 ("arm64: Miscellaneous library functions") Signed-off-by: Reiji Watanabe <reijiw@google.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Link: https://lore.kernel.org/r/20211206004736.1520989-2-reijiw@google.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-06arm64: extable: remove unused ex_handler_t definitionJisheng Zhang1-3/+0
The ex_handler_t type was introduced in commit d6e2cc564775 ("arm64: extable: add `type` and `data` fields"), but has never been used, and is unnecessary. Remove it. Signed-off-by: Jisheng Zhang <jszhang@kernel.org> Acked-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20211119124608.3f03380b@xhacker Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-06arm64: entry: Use SDEI event constantsFlorian Fainelli1-2/+4
Use SDEI_EV_FAILED instead of open coding the 1 to make it clearer how SDEI_EVENT_COMPLETE vs. SDEI_EVENT_COMPLETE_AND_RESUME is selected. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Link: https://lore.kernel.org/r/20211118201811.2974922-1-f.fainelli@gmail.com Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-06arm64: Simplify checking for populated DTRob Herring1-21/+14
Use of the of_scan_flat_dt() function predates libfdt and is discouraged as libfdt provides a nicer set of APIs. Rework dt_scan_depth1_nodes to use libfdt calls directly, and rename it to dt_is_stub() to reflect exactly what it checking. Cc: Will Deacon <will@kernel.org> Signed-off-by: Rob Herring <robh@kernel.org> Reviewed-by: Mark Rutland <mark.rutland@arm.com> Link: https://lore.kernel.org/r/20211029144055.2365814-1-robh@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-06arm64/kvm: Fix bitrotted comment for SVE handling in handle_exit.cMark Brown1-1/+4
The comment on the SVE trap handler in handle_exit.c says that it is a placeholder until we support SVE in guests which we now do for both VHE and nVHE cases so we really shouldn't get here in any sort of standard case. Update the comment to be less immediately incorrect, the handling of such a situation is correct. Signed-off-by: Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20211025163232.3502052-1-broonie@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2021-12-06s390/nmi: add missing __pa/__va address conversion of extended save areaHeiko Carstens3-7/+7
Add missing __pa/__va address conversion of machine check extended save area designation, which is an absolute address. Note: this currently doesn't fix a real bug, since virtual addresses are indentical to physical ones. Reported-by: Vineeth Vijayan <vneethv@linux.ibm.com> Tested-by: Vineeth Vijayan <vneethv@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/qdio: clarify logical vs absolute in QIB's kerneldocJulian Wiedmann1-2/+2
qib.isliba and qib.osliba are actually logical addresses, and this is also how the relevant code sets up these fields. Fix up the documentation. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Alexandra Winter <wintera@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/pci: use physical addresses in DMA tablesNiklas Schnelle3-27/+30
The entries in the DMA translation tables for our IOMMU must specify physical addresses of either the next level table or the final page to be mapped for DMA. Currently however the code simply passes the virtual addresses of both. On the other hand we still need to walk the tables via their virtual addresses so we need to do a phys_to_virt() when setting the entries and a virt_to_phys() when getting them. Similarly when passing the I/O translation anchor to the hardware we must also specify its physical address. As the DMA and IOMMU APIs we are implementing already use the correct phys_addr_t type for the address to be mapped let's also thread this through instead of treating it as just an unsigned long. Note: this currently doesn't fix a real bug, since virtual addresses are indentical to physical ones. Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/pci: use phys_to_virt() for AIBVs/DIBVsNiklas Schnelle1-3/+3
The adapter and directed interrupt bit vectors need to be referenced in the FIB with their physical not their virtual address. So use virt_to_phys() as approrpiate. Note: this currently doesn't fix a real bug, since virtual addresses are indentical to physical ones. Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Niklas Schnelle <schnelle@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/qdio: split do_QDIO()Julian Wiedmann1-5/+6
The callers know what type of queue they want to work with. Introduce type-specific variants to add buffers on an {Input,Output} queue, so that we can avoid some function parameters and the de-muxing into type-specific hot paths. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/qdio: split qdio_inspect_queue()Julian Wiedmann1-3/+4
The callers know what type of queue they want to inspect. Introduce type-specific variants to inspect an {Input,Output} queue, so that we can avoid one function parameter and some conditional branches in the hot paths. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/qdio: clarify handler logic for qdio_handle_activate_check()Julian Wiedmann1-1/+1
qdio_handle_activate_check() tries to re-use one of the queue-specific handlers to report that the ACTIVATE ccw has been terminated. But the logic to select that handler is overly complex - in practice both qdio drivers have at least one Input Queue, so we never take the other paths. Make things more obvious by removing this unused code, and clearly spelling out that we re-use the Input Handler for generic error reporting. This also paves the way for a world without queue-specific error handlers. Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/qdio: remove QDIO_SBAL_SIZE macroJulian Wiedmann1-1/+0
It's unused, and duplicates sizeof(struct qdio_buffer). Signed-off-by: Julian Wiedmann <jwi@linux.ibm.com> Reviewed-by: Benjamin Block <bblock@linux.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06s390/crypto: add SIMD implementation for ChaCha20Patrick Steuer7-0/+1142
Add an implementation of the ChaCha20 stream cipher (see e.g. RFC 7539) that makes use of z13's vector instruction set extension. The original implementation is by Andy Polyakov which is adapted for kernel use. Four to six blocks are processed in parallel resulting in a performance gain for inputs >= 256 bytes. chacha20-generic 1 operation in 622 cycles (256 bytes) 1 operation in 2346 cycles (1024 bytes) chacha20-s390 1 operation in 218 cycles (256 bytes) 1 operation in 647 cycles (1024 bytes) Cc: Andy Polyakov <appro@openssl.org> Reviewed-by: Harald Freudenberger <freude@de.ibm.com> Signed-off-by: Patrick Steuer <patrick.steuer@de.ibm.com> Signed-off-by: Heiko Carstens <hca@linux.ibm.com>
2021-12-06ARM: v7m: enable support for IRQ stacksArd Biesheuvel2-3/+15
Enable support for IRQ stacks on !MMU, and add the code to the IRQ entry path to switch to the IRQ stack if not running from it already. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-12-06ARM: implement THREAD_INFO_IN_TASK for uniprocessor systemsArd Biesheuvel12-92/+116
On UP systems, only a single task can be 'current' at the same time, which means we can use a global variable to track it. This means we can also enable THREAD_INFO_IN_TASK for those systems, as in that case, thread_info is accessed via current rather than the other way around, removing the need to store thread_info at the base of the task stack. This, in turn, permits us to enable IRQ stacks and vmap'ed stacks on UP systems as well. To partially mitigate the performance overhead of this arrangement, use a ADD/ADD/LDR sequence with the appropriate PC-relative group relocations to load the value of current when needed. This means that accessing current will still only require a single load as before, avoiding the need for a literal to carry the address of the global variable in each function. However, accessing thread_info will now require this load as well. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-12-06ARM: smp: defer TPIDRURO update for SMP v6 configurations tooArd Biesheuvel2-7/+17
Defer TPIDURO updates for user space until exit also for CPU_V6+SMP configurations so that we can decide at runtime whether to use it to carry the current pointer, provided that we are running on a CPU that actually implements this register. This is needed for THREAD_INFO_IN_TASK support for UP systems, which requires that all SMP capable systems use the TPIDRURO based access to 'current' as the only remaining alternative will be a global variable which only works on UP. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M
2021-12-06ARM: use TLS register for 'current' on !SMP as wellArd Biesheuvel1-1/+1
Enable the use of the TLS register to hold the 'current' pointer also on non-SMP configurations that target v6k or later CPUs. This will permit the use of THREAD_INFO_IN_TASK as well as IRQ stacks and vmap'ed stacks for such configurations. Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Nicolas Pitre <nico@fluxnic.net> Acked-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Tested-by: Marc Zyngier <maz@kernel.org> Tested-by: Vladimir Murzin <vladimir.murzin@arm.com> # ARMv7M