summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2021-10-19arm64: Add HWCAP for self-synchronising virtual counterMarc Zyngier
Since userspace can make use of the CNTVSS_EL0 instruction, expose it via a HWCAP. Suggested-by: Will Deacon <will@kernel.org> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-18-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2021-10-19arm64: Add handling of CNTVCTSS trapsMarc Zyngier
Since CNTVCTSS obey the same control bits as CNTVCT, add the necessary decoding to the hook table. Note that there is no known user of this at the moment. Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-17-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2021-10-19arm64: Add CNT{P,V}CTSS_EL0 alternatives to cnt{p,v}ct_el0Marc Zyngier
CNTPCTSS_EL0 and CNTVCTSS_EL0 are alternatives to the usual CNTPCT_EL0 and CNTVCT_EL0 that do not require a previous ISB to be synchronised (SS stands for Self-Synchronising). Use the ARM64_HAS_ECV capability to control alternative sequences that switch to these low(er)-cost primitives. Note that the counter access in the VDSO is for now left alone until we decide whether we want to allow this. Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-16-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2021-10-19arm64: Add a capability for FEAT_ECVMarc Zyngier
Add a new capability to detect the Enhanced Counter Virtualization feature (FEAT_ECV). Reviewed-by: Oliver Upton <oupton@google.com> Acked-by: Will Deacon <will@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20211017124225.3018098-15-maz@kernel.org Signed-off-by: Will Deacon <will@kernel.org>
2021-10-19Merge branch 'timers/drivers/armv8.6_arch_timer' of ↵Will Deacon
https://git.linaro.org/people/daniel.lezcano/linux into for-next/8.6-timers Pull Arm architected timer driver rework from Marc (via Daniel) so that we can add the Armv8.6 support on top. Link: https://lore.kernel.org/r/d0c55386-2f7f-a940-45bb-d80ae5e0f378@linaro.org * 'timers/drivers/armv8.6_arch_timer' of https://git.linaro.org/people/daniel.lezcano/linux: clocksource/drivers/arch_arm_timer: Move workaround synchronisation around clocksource/drivers/arm_arch_timer: Fix masking for high freq counters clocksource/drivers/arm_arch_timer: Drop unnecessary ISB on CVAL programming clocksource/drivers/arm_arch_timer: Remove any trace of the TVAL programming interface clocksource/drivers/arm_arch_timer: Work around broken CVAL implementations clocksource/drivers/arm_arch_timer: Advertise 56bit timer to the core code clocksource/drivers/arm_arch_timer: Move MMIO timer programming over to CVAL clocksource/drivers/arm_arch_timer: Fix MMIO base address vs callback ordering issue clocksource/drivers/arm_arch_timer: Move drop _tval from erratum function names clocksource/drivers/arm_arch_timer: Move system register timer programming over to CVAL clocksource/drivers/arm_arch_timer: Extend write side of timer register accessors to u64 clocksource/drivers/arm_arch_timer: Drop CNT*_TVAL read accessors clocksource/arm_arch_timer: Add build-time guards for unhandled register accesses
2021-10-19ARM: 9141/1: only warn about XIP address when not compile testingArnd Bergmann
In randconfig builds, we sometimes come across this warning: arm-linux-gnueabi-ld: XIP start address may cause MPU programming issues While this is helpful for actual systems to figure out why it fails, the warning does not provide any benefit for build testing, so guard it in a check for CONFIG_COMPILE_TEST, which is usually set on randconfig builds. Fixes: 216218308cfb ("ARM: 8713/1: NOMMU: Support MPU in XIP configuration") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9139/1: kprobes: fix arch_init_kprobes() prototypeArnd Bergmann
With extra warnings enabled, gcc complains about this function definition: arch/arm/probes/kprobes/core.c: In function 'arch_init_kprobes': arch/arm/probes/kprobes/core.c:465:12: warning: old-style function definition [-Wold-style-definition] 465 | int __init arch_init_kprobes() Link: https://lore.kernel.org/all/20201027093057.c685a14b386acacb3c449e3d@kernel.org/ Fixes: 24ba613c9d6c ("ARM kprobes: core code") Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9138/1: fix link warning with XIP + frame-pointerArnd Bergmann
When frame pointers are used instead of the ARM unwinder, and the kernel is built using clang with an external assembler and CONFIG_XIP_KERNEL, every file produces two warnings like: arm-linux-gnueabi-ld: warning: orphan section `.ARM.extab' from `net/mac802154/util.o' being placed in section `.ARM.extab' arm-linux-gnueabi-ld: warning: orphan section `.ARM.exidx' from `net/mac802154/util.o' being placed in section `.ARM.exidx' The same fix was already merged for the normal (non-XIP) linker script, with a longer description. Fixes: c39866f268f8 ("arm/build: Always handle .ARM.exidx and .ARM.extab sections") Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9134/1: remove duplicate memcpy() definitionArnd Bergmann
Both the decompressor code and the kasan logic try to override the memcpy() and memmove() definitions, which leading to a clash in a KASAN-enabled kernel with XZ decompression: arch/arm/boot/compressed/decompress.c:50:9: error: 'memmove' macro redefined [-Werror,-Wmacro-redefined] #define memmove memmove ^ arch/arm/include/asm/string.h:59:9: note: previous definition is here #define memmove(dst, src, len) __memmove(dst, src, len) ^ arch/arm/boot/compressed/decompress.c:51:9: error: 'memcpy' macro redefined [-Werror,-Wmacro-redefined] #define memcpy memcpy ^ arch/arm/include/asm/string.h:58:9: note: previous definition is here #define memcpy(dst, src, len) __memcpy(dst, src, len) ^ Here we want the set of functions from the decompressor, so undefine the other macros before the override. Link: https://lore.kernel.org/linux-arm-kernel/CACRpkdZYJogU_SN3H9oeVq=zJkRgRT1gDz3xp59gdqWXxw-B=w@mail.gmail.com/ Link: https://lore.kernel.org/lkml/202105091112.F5rmd4By-lkp@intel.com/ Fixes: d6d51a96c7d6 ("ARM: 9014/2: Replace string mem* functions for KASan") Fixes: a7f464f3db93 ("ARM: 7001/2: Wire up support for the XZ decompressor") Reported-by: kernel test robot <lkp@intel.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9133/1: mm: proc-macros: ensure *_tlb_fns are 4B alignedNick Desaulniers
A kernel built with CONFIG_THUMB2_KERNEL=y and using clang as the assembler could generate non-naturally-aligned v7wbi_tlb_fns which results in a boot failure. The original commit adding the macro missed the .align directive on this data. Link: https://github.com/ClangBuiltLinux/linux/issues/1447 Link: https://lore.kernel.org/all/0699da7b-354f-aecc-a62f-e25693209af4@linaro.org/ Debugged-by: Ard Biesheuvel <ardb@kernel.org> Debugged-by: Nathan Chancellor <nathan@kernel.org> Debugged-by: Richard Henderson <richard.henderson@linaro.org> Fixes: 66a625a88174 ("ARM: mm: proc-macros: Add generic proc/cache/tlb struct definition macros") Suggested-by: Ard Biesheuvel <ardb@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9132/1: Fix __get_user_check failure with ARM KASAN imagesLexi Shao
ARM: kasan: Fix __get_user_check failure with kasan In macro __get_user_check defined in arch/arm/include/asm/uaccess.h, error code is store in register int __e(r0). When kasan is enabled, assigning value to kernel address might trigger kasan check, which unexpectedly overwrites r0 and causes undefined behavior on arm kasan images. One example is failure in do_futex and results in process soft lockup. Log: watchdog: BUG: soft lockup - CPU#0 stuck for 62946ms! [rs:main Q:Reg:1151] ... (__asan_store4) from (futex_wait_setup+0xf8/0x2b4) (futex_wait_setup) from (futex_wait+0x138/0x394) (futex_wait) from (do_futex+0x164/0xe40) (do_futex) from (sys_futex_time32+0x178/0x230) (sys_futex_time32) from (ret_fast_syscall+0x0/0x50) The soft lockup happens in function futex_wait_setup. The reason is function get_futex_value_locked always return EINVAL, thus pc jump back to retry label and causes looping. This line in function get_futex_value_locked ret = __get_user(*dest, from); is expanded to *dest = (typeof(*(p))) __r2; , in macro __get_user_check. Writing to pointer dest triggers kasan check and overwrites the return value of __get_user_x function. The assembly code of get_futex_value_locked in kernel/futex.c: ... c01f6dc8: eb0b020e bl c04b7608 <__get_user_4> // "x = (typeof(*(p))) __r2;" triggers kasan check and r0 is overwritten c01f6dCc: e1a00007 mov r0, r7 c01f6dd0: e1a05002 mov r5, r2 c01f6dd4: eb04f1e6 bl c0333574 <__asan_store4> c01f6dd8: e5875000 str r5, [r7] // save ret value of __get_user(*dest, from), which is dest address now c01f6ddc: e1a05000 mov r5, r0 ... // checking return value of __get_user failed c01f6e00: e3550000 cmp r5, #0 ... c01f6e0c: 01a00005 moveq r0, r5 // assign return value to EINVAL c01f6e10: 13e0000d mvnne r0, #13 Return value is the destination address of get_user thus certainly non-zero, so get_futex_value_locked always return EINVAL. Fix it by using a tmp vairable to store the error code before the assignment. This fix has no effects to non-kasan images thanks to compiler optimization. It only affects cases that overwrite r0 due to kasan check. This should fix bug discussed in Link: [1] https://lore.kernel.org/linux-arm-kernel/0ef7c2a5-5d8b-c5e0-63fa-31693fd4495c@gmail.com/ Fixes: 421015713b30 ("ARM: 9017/2: Enable KASan for ARM") Signed-off-by: Lexi Shao <shaolexi@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9125/1: fix incorrect use of get_kernel_nofault()Ard Biesheuvel
Commit 344179fc7ef4 ("ARM: 9106/1: traps: use get_kernel_nofault instead of set_fs()") replaced an occurrence of __get_user() with get_kernel_nofault(), but inverted the sense of the conditional in the process, resulting in no values to be printed at all. I.e., every exception stack now looks like this: Exception stack(0xc18d1fb0 to 0xc18d1ff8) 1fa0: ???????? ???????? ???????? ???????? 1fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? 1fe0: ???????? ???????? ???????? ???????? ???????? ???????? which is rather unhelpful. Fixes: 344179fc7ef4 ("ARM: 9106/1: traps: use get_kernel_nofault instead of set_fs()") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9122/1: select HAVE_FUTEX_CMPXCHGNick Desaulniers
tglx notes: This function [futex_detect_cmpxchg] is only needed when an architecture has to runtime discover whether the CPU supports it or not. ARM has unconditional support for this, so the obvious thing to do is the below. Fixes linkage failure from Clang randconfigs: kernel/futex.o:(.text.fixup+0x5c): relocation truncated to fit: R_ARM_JUMP24 against `.init.text' and boot failures for CONFIG_THUMB2_KERNEL. Link: https://github.com/ClangBuiltLinux/linux/issues/325 Comments from Nick Desaulniers: See-also: 03b8c7b623c8 ("futex: Allow architectures to skip futex_atomic_cmpxchg_inatomic() test") Reported-by: Arnd Bergmann <arnd@arndb.de> Reported-by: Nathan Chancellor <nathan@kernel.org> Suggested-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Cc: stable@vger.kernel.org # v3.14+ Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9131/1: mm: Fix PXN process with LPAE featureWang Kefeng
When user code execution with privilege mode, it will lead to infinite loop in the page fault handler if ARM_LPAE enabled, The issue could be reproduced with "echo EXEC_USERSPACE > /sys/kernel/debug/provoke-crash/DIRECT" As Permission fault shows in ARM spec, IFSR format when using the Short-descriptor translation table format Permission fault: 01101 First level 01111 Second level IFSR format when using the Long-descriptor translation table format Permission fault: 0011LL LL bits indicate levelb. Add is_permission_fault() function to check permission fault and die if permission fault occurred under instruction fault in do_page_fault(). Fixes: 1d4d37159d01 ("ARM: 8235/1: Support for the PXN CPU feature on ARMv7") Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9130/1: mm: Provide die_kernel_fault() helperWang Kefeng
Provide die_kernel_fault() helper to do the kernel fault reporting, which with msg argument, it could report different message in different scenes, and the later patch "ARM: mm: Fix PXN process with LPAE feature" will use it. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9126/1: mm: Kill page table base print in show_pte()Wang Kefeng
Now the show_pts() will dump the virtual (hashed) address of page table base, it is useless, kill it. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9127/1: mm: Cleanup access_error()Wang Kefeng
Now the write fault check in do_page_fault() and access_error() twice, we can cleanup access_error(), and make the fault check and vma flags set into do_page_fault() directly, then pass the vma flags to __do_page_fault. No functional change. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9129/1: mm: Kill task_struct argument for __do_page_fault()Wang Kefeng
The __do_page_fault() won't use task_struct argument, kill it and also use current->mm directly in do_page_fault(). No functional change. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9128/1: mm: Refactor the __do_page_fault()Wang Kefeng
Clean up the multiple goto statements and drops local variable vm_fault_t fault, which will make the __do_page_fault() much more readability. No functional change. Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: imx6: mark OCRAM mapping read-onlyRussell King (Oracle)
iMX6 needs to write some code to OCRAM which resumes the DDR controller after suspend. However, merely using __arm_ioremap_exec() causes the kernel to complain of a W+X mapping. Solve this by using the newly introduced __arm_iomem_set_ro() function to prevent inadvertent or malicious writes to code we may later execute. Tested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: add __arm_iomem_set_ro() to write-protect ioremapped areaRussell King (Oracle)
__arm_iomem_set_ro() marks an ioremapped area read-only. This is intended for use with __arm_ioremap_exec() to allow the kernel to write some code into e.g. SRAM and then write-protect it so the kernel doesn't complain about W+X mappings. Tested-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9124/1: uncompress: Parse "linux,usable-memory-range" DT propertyGeert Uytterhoeven
Add support for parsing the "linux,usable-memory-range" DT property. This property is used to describe the usable memory reserved for the crash dump kernel, and thus makes the memory reservation explicit. If present, Linux no longer needs to mask the program counter, and rely on the "mem=" kernel parameter to obtain the start and size of usable memory. For backwards compatibility, the traditional method to derive the start of memory is still used if "linux,usable-memory-range" is absent. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9123/1: scoop: Drop if with an always false conditionUwe Kleine-König
The remove callback is only called after probe completed successfully. In this case platform_set_drvdata() was called with a non-NULL argument and so !sdev is never true. The motivation for this change is to get rid of non-zero return values for remove callbacks as their only effect is to trigger a runtime warning. See commit e5e1c2097881 ("driver core: platform: Emit a warning if a remove callback returned non-zero") for further details. Link: https://lore.kernel.org/linux-arm-kernel/20210721205450.2173923-1-u.kleine-koenig@pengutronix.de Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19ARM: 9125/1: fix incorrect use of get_kernel_nofault()Ard Biesheuvel
Commit 344179fc7ef4 ("ARM: 9106/1: traps: use get_kernel_nofault instead of set_fs()") replaced an occurrence of __get_user() with get_kernel_nofault(), but inverted the sense of the conditional in the process, resulting in no values to be printed at all. I.e., every exception stack now looks like this: Exception stack(0xc18d1fb0 to 0xc18d1ff8) 1fa0: ???????? ???????? ???????? ???????? 1fc0: ???????? ???????? ???????? ???????? ???????? ???????? ???????? ???????? 1fe0: ???????? ???????? ???????? ???????? ???????? ???????? which is rather unhelpful. Fixes: 344179fc7ef4 ("ARM: 9106/1: traps: use get_kernel_nofault instead of set_fs()") Signed-off-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2021-10-19riscv: dts: sifive: add missing compatible for plicKrzysztof Kozlowski
Add proper compatible for Platform-Level Interrupt Controller to silence dtbs_check warnings: interrupt-controller@c000000: compatible: ['sifive,plic-1.0.0'] is too short Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Link: https://lore.kernel.org/r/20210920130412.145231-2-krzysztof.kozlowski@canonical.com
2021-10-19riscv: dts: microchip: add missing compatibles for clint and plicKrzysztof Kozlowski
The Microchip Icicle kit uses SiFive E51 and U54 cores, so it looks that also Core Local Interruptor and Platform-Level Interrupt Controller are coming from SiFive. Add proper compatibles to silence dtbs_check warnings: clint@2000000: compatible:0: 'sifive,clint0' is not one of ['sifive,fu540-c000-clint', 'canaan,k210-clint'] interrupt-controller@c000000: compatible:0: 'sifive,plic-1.0.0' is not one of ['sifive,fu540-c000-plic', 'canaan,k210-plic'] Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20210920130412.145231-1-krzysztof.kozlowski@canonical.com
2021-10-19riscv: dts: sifive: drop duplicated nodes and properties in sifiveKrzysztof Kozlowski
The DTSI file defines soc node and address/size cells, so there is no point in duplicating it in DTS file. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Link: https://lore.kernel.org/r/20210920130248.145058-3-krzysztof.kozlowski@canonical.com
2021-10-19riscv: dts: sifive: fix Unleashed board compatibleKrzysztof Kozlowski
Add missing sifive,fu540 compatible to fix dtbs_check warnings: arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dt.yaml: /: compatible: 'oneOf' conditional failed, one must be fixed: ['sifive,hifive-unleashed-a00', 'sifive,fu540-c000'] is too short 'sifive,hifive-unleashed-a00' is not one of ['sifive,hifive-unmatched-a00'] 'sifive,fu740-c000' was expected Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Reviewed-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Tested-by: Alexandre Ghiti <alexandre.ghiti@canonical.com> Link: https://lore.kernel.org/r/20210920130248.145058-2-krzysztof.kozlowski@canonical.com
2021-10-19riscv: dts: sifive: use only generic JEDEC SPI NOR flash compatibleKrzysztof Kozlowski
The compatible "issi,is25wp256" is undocumented and instead only a generic jedec,spi-nor should be used (if appropriate). Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20210920130248.145058-1-krzysztof.kozlowski@canonical.com
2021-10-19ARM: dts: s5pv210: add 'chassis-type' propertyKrzysztof Kozlowski
A new 'chassis-type' root node property has recently been approved for the device-tree specification. Add this property for end-user devices (such as laptops, smartphones and tablets) based on Samsung S5Pv210 ARM SoCs. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211017101228.19478-3-krzysztof.kozlowski@canonical.com
2021-10-19ARM: dts: exynos: add 'chassis-type' propertyKrzysztof Kozlowski
A new 'chassis-type' root node property has recently been approved for the device-tree specification. Add this property for end-user devices (such as laptops, smartphones and tablets) based on Samsung Exynos ARM SoCs. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211017101228.19478-2-krzysztof.kozlowski@canonical.com
2021-10-19arm64: dts: exynos: add 'chassis-type' propertyKrzysztof Kozlowski
A new 'chassis-type' root node property has recently been approved for the device-tree specification. Add this property for end-user devices (such as laptops, smartphones and tablets) based on Samsung Exynos ARM64 SoCs. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> Link: https://lore.kernel.org/r/20211017101228.19478-1-krzysztof.kozlowski@canonical.com
2021-10-19Merge branch 'timers/drivers/armv8.6_arch_timer' into timers/drivers/nextDaniel Lezcano
The branch is a stable branch shared with ARM maintainers for the first 13th patches of the series: It is based on v5.14-rc3. As stated by the changelog: " [... ] enabling ARMv8.6 support for timer subsystem, and was prompted by a discussion with Oliver around the fact that an ARMv8.6 implementation must have a 1GHz counter, which leads to a number of things to break in the timer code: - the counter rollover can come pretty quickly as we only advertise a 56bit counter, - the maximum timer delta can be remarkably small, as we use the countdown interface which is limited to 32bit... Thankfully, there is a way out: we can compute the minimal width of the counter based on the guarantees that the architecture gives us, and we can use the 64bit comparator interface instead of the countdown to program the timer. Finally, we start making use of the ARMv8.6 ECV features by switching accesses to the counters to a self-synchronising register, removing the need for an ISB. Hopefully, implementations will *not* just stick an invisible ISB there... A side effect of the switch to CVAL is that XGene-1 breaks. I have added a workaround to keep it alive. I have added Oliver's original patch[0] to the series and tweaked a couple of things. Blame me if I broke anything. The whole things has been tested on Juno (sysreg + MMIO timers), XGene-1 (broken sysreg timers), FVP (FEAT_ECV, CNT*CTSS_EL0). " Link: https://lore.kernel.org/r/20211017124225.3018098-1-maz@kernel.org Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
2021-10-18xtensa: move section symbols to asm/sections.hMax Filippov
Introduce asm/sections.h and move section declarations to this header from setup.c. Assign section symbols char array type uniformly and drop address operator from section symbol references in code. Sort headers in setup.c while at it. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: remove unused variable wmaskMax Filippov
After a cleanup the function show_regs doesn't use variable wmask but still computes it. Drop it. Fixes: 8d7e8240e66c ("[XTENSA] Clean up elf-gregset.") Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: only build windowed register support code when neededMax Filippov
There's no need in window overflow/underflow/alloca exception handlers or window spill code when neither kernel nor userspace support windowed registers. Don't build or link it. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: use register window specific opcodes only when presentMax Filippov
xtensa core may be configured without register windows support, don't use register window specific opcodes in that case. Use window register specific opcodes to initialize hardware or reset core to a known state regardless of the chosen ABI. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: implement call0 ABI support in assemblyMax Filippov
Replace hardcoded register and opcode names with ABI-agnostic macros. Add register save/restore code where necessary. Conditionalize windowed only or call0 only code. Add stack initialization matching _switch_to epilogue to copy_thread. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: definitions for call0 ABIMax Filippov
Add assembly macros for calls, call arguments, preserved registers, function entry and return for windowed and call0 ABIs. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: don't use a12 in __xtensa_copy_user in call0 ABIMax Filippov
a12 is callee-saved register in xtensa call0 ABI, so a function must not change it. The main unaligned copy loop of __xtensa_copy_user uses all low-numbered registers, so a register must be spilled to avoid using a12 as a loop counter. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: don't use a12 in strncpy_userMax Filippov
a12 is callee-saved register in xtensa call0 ABI, so a function must not change it. a10 is not used in this function at all, use it instead of a12 to avoid saving/restoring it. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: use a14 instead of a15 in inline assemblyMax Filippov
a15 is a frame pointer in the call0 xtensa ABI, don't use it explicitly in the inline assembly. Use a14 instead, as it has the same properties as a15 w.r.t. window overflow. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa: move _SimulateUserKernelVectorException out of WindowVectorsMax Filippov
In configurations without window registers support the section .WindowVectors.text may never be linked. _SimulateUserKernelVectorException is a common handler for high priority interrupts, it does not belong in that section anyway. Move it out of that section and mark it as __XTENSA_HANDLER so it gets bundled with other vector helpers. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
2021-10-18xtensa/platforms/iss/simdisk: add error handling support for add_disk()Luis Chamberlain
We never checked for errors on add_disk() as this function returned void. Now that this is fixed, use the shiny new error handling. Signed-off-by: Luis Chamberlain <mcgrof@kernel.org> Acked-by: Max Filippov <jcmvbkbc@gmail.com> Link: https://lore.kernel.org/r/20210927220110.1066271-7-mcgrof@kernel.org Signed-off-by: Jens Axboe <axboe@kernel.dk>
2021-10-18KVM: x86: Expose TSC offset controls to userspaceOliver Upton
To date, VMM-directed TSC synchronization and migration has been a bit messy. KVM has some baked-in heuristics around TSC writes to infer if the VMM is attempting to synchronize. This is problematic, as it depends on host userspace writing to the guest's TSC within 1 second of the last write. A much cleaner approach to configuring the guest's views of the TSC is to simply migrate the TSC offset for every vCPU. Offsets are idempotent, and thus not subject to change depending on when the VMM actually reads/writes values from/to KVM. The VMM can then read the TSC once with KVM_GET_CLOCK to capture a (realtime, host_tsc) pair at the instant when the guest is paused. Cc: David Matlack <dmatlack@google.com> Cc: Sean Christopherson <seanjc@google.com> Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210916181538.968978-8-oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-18KVM: x86: Refactor tsc synchronization codeOliver Upton
Refactor kvm_synchronize_tsc to make a new function that allows callers to specify TSC parameters (offset, value, nanoseconds, etc.) explicitly for the sake of participating in TSC synchronization. Signed-off-by: Oliver Upton <oupton@google.com> Message-Id: <20210916181538.968978-7-oupton@google.com> [Make sure kvm->arch.cur_tsc_generation and vcpu->arch.this_tsc_generation are equal at the end of __kvm_synchronize_tsc, if matched is false. Reported by Maxim Levitsky. - Paolo] Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-18kvm: x86: protect masterclock with a seqcountPaolo Bonzini
Protect the reference point for kvmclock with a seqcount, so that kvmclock updates for all vCPUs can proceed in parallel. Xen runstate updates will also run in parallel and not bounce the kvmclock cacheline. Of the variables that were protected by pvclock_gtod_sync_lock, nr_vcpus_matched_tsc is different because it is updated outside pvclock_update_vm_gtod_copy and read inside it. Therefore, we need to keep it protected by a spinlock. In fact it must now be a raw spinlock, because pvclock_update_vm_gtod_copy, being the write-side of a seqcount, is non-preemptible. Since we already have tsc_write_lock which is a raw spinlock, we can just use tsc_write_lock as the lock that protects the write-side of the seqcount. Co-developed-by: Oliver Upton <oupton@google.com> Message-Id: <20210916181538.968978-6-oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-18KVM: x86: Report host tsc and realtime values in KVM_GET_CLOCKOliver Upton
Handling the migration of TSCs correctly is difficult, in part because Linux does not provide userspace with the ability to retrieve a (TSC, realtime) clock pair for a single instant in time. In lieu of a more convenient facility, KVM can report similar information in the kvm_clock structure. Provide userspace with a host TSC & realtime pair iff the realtime clock is based on the TSC. If userspace provides KVM_SET_CLOCK with a valid realtime value, advance the KVM clock by the amount of elapsed time. Do not step the KVM clock backwards, though, as it is a monotonic oscillator. Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Oliver Upton <oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Message-Id: <20210916181538.968978-5-oupton@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-18KVM: x86: avoid warning with -Wbitwise-instead-of-logicalPaolo Bonzini
This is a new warning in clang top-of-tree (will be clang 14): In file included from arch/x86/kvm/mmu/mmu.c:27: arch/x86/kvm/mmu/spte.h:318:9: error: use of bitwise '|' with boolean operands [-Werror,-Wbitwise-instead-of-logical] return __is_bad_mt_xwr(rsvd_check, spte) | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ || arch/x86/kvm/mmu/spte.h:318:9: note: cast one or both operands to int to silence this warning The code is fine, but change it anyway to shut up this clever clogs of a compiler. Reported-by: torvic9@mailbox.org Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2021-10-18arm64: dts: rockchip: fix resets in tsadc node for rk356xJohan Jonker
In the rockchip_thermal.c driver we now get the resets with a devm_reset_control_array_get() function, so remove the reset-names property as it is no longer needed. Although no longer required in rockchip-thermal.yaml sort tsadc-apb as first item. Signed-off-by: Johan Jonker <jbx6244@gmail.com> Link: https://lore.kernel.org/r/20210930110517.14323-4-jbx6244@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de>