summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2019-04-15ARM: dts: am335x: pcm-953: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: osd335x-common: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: osd3358-sm-red: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: nano: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: moxa-uc-8100-me-t: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: moxa-uc-2101: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: moxa-uc-2100-common: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: lxm: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15ARM: dts: am335x: igep0033: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-15arm64: dts: hisilicon: hi3670: Add UFS controller supportManivannan Sadhasivam
Add UFS controller support for HiSilicon HI3670 SoC. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
2019-04-15arch: add pidfd and io_uring syscalls everywhereArnd Bergmann
Add the io_uring and pidfd_send_signal system calls to all architectures. These system calls are designed to handle both native and compat tasks, so all entries are the same across architectures, only arm-compat and the generic tale still use an old format. Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com> (s390) Acked-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-04-15KVM: x86/mmu: Fix an inverted list_empty() check when zapping sptesSean Christopherson
A recently introduced helper for handling zap vs. remote flush incorrectly bails early, effectively leaking defunct shadow pages. Manifests as a slab BUG when exiting KVM due to the shadow pages being alive when their associated cache is destroyed. ========================================================================== BUG kvm_mmu_page_header: Objects remaining in kvm_mmu_page_header on ... -------------------------------------------------------------------------- Disabling lock debugging due to kernel taint INFO: Slab 0x00000000fc436387 objects=26 used=23 fp=0x00000000d023caee ... CPU: 6 PID: 4315 Comm: rmmod Tainted: G B 5.1.0-rc2+ #19 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: dump_stack+0x46/0x5b slab_err+0xad/0xd0 ? on_each_cpu_mask+0x3c/0x50 ? ksm_migrate_page+0x60/0x60 ? on_each_cpu_cond_mask+0x7c/0xa0 ? __kmalloc+0x1ca/0x1e0 __kmem_cache_shutdown+0x13a/0x310 shutdown_cache+0xf/0x130 kmem_cache_destroy+0x1d5/0x200 kvm_mmu_module_exit+0xa/0x30 [kvm] kvm_arch_exit+0x45/0x60 [kvm] kvm_exit+0x6f/0x80 [kvm] vmx_exit+0x1a/0x50 [kvm_intel] __x64_sys_delete_module+0x153/0x1f0 ? exit_to_usermode_loop+0x88/0xc0 do_syscall_64+0x4f/0x100 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Fixes: a21136345cb6f ("KVM: x86/mmu: Split remote_flush+zap case out of kvm_mmu_flush_or_zap()") Signed-off-by: Sean Christopherson <sean.j.christopherson@intel.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-04-15ARM: dts: sun8i: h3: bluetooth for Banana Pi M2 Zero boardAndreas Kemnade
The Banana Pi M2 Zero board has an AP6212 BT+Wifi combo chip with Broadcom internals attached to UART1 and some gpios. This addition is in line with similar boards. Signed-off-by: Andreas Kemnade <andreas@kemnade.info> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-04-15arm64: dts: renesas: r8a77980: Add "renesas,id" to VINJacopo Mondi
Add the "renesas,id" property to VIN nodes in the R-Car V3H R8A77980 device tree. Fixes: 3182aa4e0bf4 ("arm64: dts: renesas: r8a77980: add CSI2/VIN support") Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Reviewed-by: Niklas Söderlund <niklas.soderlund@ragnatech.se> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-15arm64: dts: renesas: r8a77965: Remove reg-names of display nodeTakeshi Kihara
Remove the "reg-names" property from the display node of R-Car Gen3 R8A77965 device tree. No other mainline R-Car Gen3 SoC has that property specified. Fixes: 2f2c71bfc8c5 ("arm64: dts: renesas: r8a77965: Populate the DU instance placeholder") Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com> [reworded commit message, sent upstream] Signed-off-by: Jacopo Mondi <jacopo+renesas@jmondi.org> Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
2019-04-15ARM: dts: sun8i: v40: bananapi-m2-berry: Sort device node dereferences.Pablo Greco
The device node dereferences are out of order, sort them. Signed-off-by: Pablo Greco <pgreco@centosproject.org> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-04-15arm64: dts: allwinner: h6: Add MMC1 pinsOndrej Jirman
MMC1 is used on some H6 boards we want to support. Typical use is 4-bit SDIO interface with a WiFi chip. Add pin definitions for this use case. As this is the only possible configration for mmc1, make it the default one, too. Signed-off-by: Ondrej Jirman <megous@megous.com> Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-04-14x86/speculation: Prevent deadlock on ssb_state::lockThomas Gleixner
Mikhail reported a lockdep splat related to the AMD specific ssb_state lock: CPU0 CPU1 lock(&st->lock); local_irq_disable(); lock(&(&sighand->siglock)->rlock); lock(&st->lock); <Interrupt> lock(&(&sighand->siglock)->rlock); *** DEADLOCK *** The connection between sighand->siglock and st->lock comes through seccomp, which takes st->lock while holding sighand->siglock. Make sure interrupts are disabled when __speculation_ctrl_update() is invoked via prctl() -> speculation_ctrl_update(). Add a lockdep assert to catch future offenders. Fixes: 1f50ddb4f418 ("x86/speculation: Handle HT correctly on AMD") Reported-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Tested-by: Mikhail Gavrilov <mikhail.v.gavrilov@gmail.com> Cc: Thomas Lendacky <thomas.lendacky@amd.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1904141948200.4917@nanos.tec.linutronix.de
2019-04-14ARM: pxa: ssp: Fix "WARNING: invalid free of devm_ allocated data"YueHaibing
Since commit 1c459de1e645 ("ARM: pxa: ssp: use devm_ functions") kfree, iounmap, clk_put etc are not needed anymore in remove path. Fixes: 1c459de1e645 ("ARM: pxa: ssp: use devm_ functions") Signed-off-by: YueHaibing <yuehaibing@huawei.com> [ commit message spelling fix ] Signed-off-by: Robert Jarzmik <robert.jarzmik@free.fr>
2019-04-14s390/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: linux-s390@vger.kernel.org Cc: Heiko Carstens <heiko.carstens@de.ibm.com> Link: https://lkml.kernel.org/r/20190410103644.396788431@linutronix.de
2019-04-14parisc/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com> Cc: Helge Deller <deller@gmx.de> Cc: linux-parisc@vger.kernel.org Link: https://lkml.kernel.org/r/20190410103644.308534788@linutronix.de
2019-04-14arm64/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: linux-arm-kernel@lists.infradead.org Link: https://lkml.kernel.org/r/20190410103644.220247845@linutronix.de
2019-04-14riscv/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: linux-riscv@lists.infradead.org Cc: Palmer Dabbelt <palmer@sifive.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Link: https://lkml.kernel.org/r/20190410103644.131061192@linutronix.de
2019-04-14unicore32/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Guan Xuetao <gxt@pku.edu.cn> Link: https://lkml.kernel.org/r/20190410103644.036077691@linutronix.de
2019-04-14sh/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Rich Felker <dalias@libc.org> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Cc: linux-sh@vger.kernel.org Cc: Simon Horman <horms+renesas@verge.net.au> Link: https://lkml.kernel.org/r/20190410103643.932464393@linutronix.de
2019-04-14arm/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Russell King <linux@armlinux.org.uk> Cc: linux-arm-kernel@lists.infradead.org Link: https://lkml.kernel.org/r/20190410103643.843075256@linutronix.de
2019-04-14x86/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Link: https://lkml.kernel.org/r/20190410103643.750954603@linutronix.de
2019-04-14um/stacktrace: Remove the pointless ULONG_MAX markerThomas Gleixner
Terminating the last trace entry with ULONG_MAX is a completely pointless exercise and none of the consumers can rely on it because it's inconsistently implemented across architectures. In fact quite some of the callers remove the entry and adjust stack_trace.nr_entries afterwards. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Alexander Potapenko <glider@google.com> Cc: Richard Weinberger <richard@nod.at> Cc: linux-um@lists.infradead.org Link: https://lkml.kernel.org/r/20190410103643.662853876@linutronix.de
2019-04-14x86/resctrl: Do not repeat rdtgroup mode initializationXiaochen Shen
When cache allocation is supported and the user creates a new resctrl resource group, the allocations of the new resource group are initialized to all regions that it can possibly use. At this time these regions are all that are shareable by other resource groups as well as regions that are not currently used. The new resource group's mode is also initialized to reflect this initialization and set to "shareable". The new resource group's mode is currently repeatedly initialized within the loop that configures the hardware with the resource group's default allocations. Move the initialization of the resource group's mode outside the hardware configuration loop. The resource group's mode is now initialized only once as the final step to reflect that its configured allocations are "shareable". Fixes: 95f0b77efa57 ("x86/intel_rdt: Initialize new resource group with sane defaults") Signed-off-by: Xiaochen Shen <xiaochen.shen@intel.com> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Fenghua Yu <fenghua.yu@intel.com> Acked-by: Reinette Chatre <reinette.chatre@intel.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: pei.p.jia@intel.com Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Tony Luck <tony.luck@intel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/1554839629-5448-1-git-send-email-xiaochen.shen@intel.com
2019-04-14ARM: s3c64xx: Tidy up handling of regulator GPIO lookupsCharles Keepax
Rather than unconditionally registering the GPIO lookup table only do so for devices that require it. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> [Fixed up to also handle wm5102 and wm5102 reva] Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-04-13Merge tag 'powerpc-5.1-5' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux Pull powerpc fixes from Michael Ellerman: "A minor build fix for 64-bit FLATMEM configs. A fix for a boot failure on 32-bit powermacs. My commit to fix CLOCK_MONOTONIC across Y2038 broke the 32-bit VDSO on 64-bit kernels, ie. compat mode, which is only used on big endian. The rewrite of the SLB code we merged in 4.20 missed the fact that the 0x380 exception is also used with the Radix MMU to report out of range accesses. This could lead to an oops if userspace tried to read from addresses outside the user or kernel range. Thanks to: Aneesh Kumar K.V, Christophe Leroy, Larry Finger, Nicholas Piggin" * tag 'powerpc-5.1-5' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/mm: Define MAX_PHYSMEM_BITS for all 64-bit configs powerpc/64s/radix: Fix radix segment exception handling powerpc/vdso32: fix CLOCK_MONOTONIC on PPC64 powerpc/32: Fix early boot failure with RTAS built-in
2019-04-13Merge tag 'arm64-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux Pull arm64 fixes from Will Deacon: "The main thing is a fix to our FUTEX_WAKE_OP implementation which was unbelievably broken, but did actually work for the one scenario that GLIBC used to use. Summary: - Fix stack unwinding so we ignore user stacks - Fix ftrace module PLT trampoline initialisation checks - Fix terminally broken implementation of FUTEX_WAKE_OP atomics" * tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: arm64: futex: Fix FUTEX_WAKE_OP atomic ops with non-zero result value arm64: backtrace: Don't bother trying to unwind the userspace stack arm64/ftrace: fix inadvertent BUG() in trampoline check
2019-04-12Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Fix typos in user-visible resctrl parameters, and also fix assembly constraint bugs that might result in miscompilation" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/asm: Use stricter assembly constraints in bitops x86/resctrl: Fix typos in the mba_sc mount option
2019-04-12Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "Six kernel side fixes: three related to NMI handling on AMD systems, a race fix, a kexec initialization fix and a PEBS sampling fix" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/core: Fix perf_event_disable_inatomic() race x86/perf/amd: Remove need to check "running" bit in NMI handler x86/perf/amd: Resolve NMI latency issues for active PMCs x86/perf/amd: Resolve race condition when disabling PMC perf/x86/intel: Initialize TFA MSR perf/x86/intel: Fix handling of wakeup_events for multi-entry PEBS
2019-04-12ARM: dts: rockchip: vdd_gpu off in suspend for rk3288-veyronDouglas Anderson
At some point long long ago the downstream GPU driver would crash if we turned the GPU off during suspend. For some context you can see: https://chromium-review.googlesource.com/#/c/215780/5..6/arch/arm/boot/dts/rk3288-pinky-rev2.dts At some point in time not too long after that got fixed. It's unclear why the GPU is left enabled during suspend on the mainline kernel. Everything seems fine if I turn this off, so let's do it. Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-12ARM: dts: rockchip: vcc33_ccd off in suspend for rk3288-veyron-chromebookDouglas Anderson
As per my comments when the device tree for rk3288-veyron-chromebook first landed: > Technically I think vcc33_ccd can be off since we have > 'needs-reset-on-resume' down in the EHCI port (this regulator is for > the USB webcam that's connected to the EHCI port). > > ...but leaving it on for now seems fine until we get suspend/resume > more solid. It's probably about time to do it right. [1] https://lore.kernel.org/linux-arm-kernel/CAD=FV=U37Yx8Mqk75_x05zxonvdc3qRMhqp8TyTDPWGHqSuRqg@mail.gmail.com/ Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Elaine Zhang <zhangqing@rock-chips.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2019-04-12x86/pkeys: Add PKRU value to init_fpstateSebastian Andrzej Siewior
The task's initial PKRU value is set partly for fpu__clear()/ copy_init_pkru_to_fpregs(). It is not part of init_fpstate.xsave and instead it is set explicitly. If the user removes the PKRU state from XSAVE in the signal handler then __fpu__restore_sig() will restore the missing bits from `init_fpstate' and initialize the PKRU value to 0. Add the `init_pkru_value' to `init_fpstate' so it is set to the init value in such a case. In theory copy_init_pkru_to_fpregs() could be removed because restoring the PKRU at return-to-userland should be enough. Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andi Kleen <ak@linux.intel.com> Cc: Andy Lutomirski <luto@kernel.org> Cc: "Chang S. Bae" <chang.seok.bae@intel.com> Cc: Dominik Brodowski <linux@dominikbrodowski.net> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Pavel Tatashin <pasha.tatashin@oracle.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-28-bigeasy@linutronix.de
2019-04-12x86/fpu: Restore regs in copy_fpstate_to_sigframe() in order to use the fastpathSebastian Andrzej Siewior
If a task is scheduled out and receives a signal then it won't be able to take the fastpath because the registers aren't available. The slowpath is more expensive compared to XRSTOR + XSAVE which usually succeeds. Here are some clock_gettime() numbers from a bigger box with AVX512 during bootup: - __fpregs_load_activate() takes 140ns - 350ns. If it was the most recent FPU context on the CPU then the optimisation in __fpregs_load_activate() will skip the load (which was disabled during the test). - copy_fpregs_to_sigframe() takes 200ns - 450ns if it succeeds. On a pagefault it is 1.8us - 3us usually in the 2.6us area. - The slowpath takes 1.5us - 6us. Usually in the 2.6us area. My testcases (including lat_sig) take the fastpath without __fpregs_load_activate(). I expect this to be the majority. Since the slowpath is in the >1us area it makes sense to load the registers and attempt to save them directly. The direct save may fail but should only happen on the first invocation or after fork() while the page is read-only. [ bp: Massage a bit. ] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-27-bigeasy@linutronix.de
2019-04-12Revert "MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices"Paul Burton
Commit e6046b5e69a0 ("MIPS: ralink: fix cpu clock of mt7621 and add dt clk devices") includes a file that doesn't exist, causing build failures... Revert it. References: https://lore.kernel.org/linux-mips/CAJsYDVJvviz8a2oVmb0XL3OB+=Eecu-3kC9T9vsmxpuC_BqDSA@mail.gmail.com/ Signed-off-by: Paul Burton <paul.burton@mips.com>
2019-04-12x86/fpu: Add a fastpath to copy_fpstate_to_sigframe()Sebastian Andrzej Siewior
Try to save the FPU registers directly to the userland stack frame if the CPU holds the FPU registers for the current task. This has to be done with the pagefault disabled because we can't fault (while the FPU registers are locked) and therefore the operation might fail. If it fails try the slowpath which can handle faults. [ bp: Massage a bit. ] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-26-bigeasy@linutronix.de
2019-04-12x86/fpu: Add a fastpath to __fpu__restore_sig()Sebastian Andrzej Siewior
The previous commits refactor the restoration of the FPU registers so that they can be loaded from in-kernel memory. This overhead can be avoided if the load can be performed without a pagefault. Attempt to restore FPU registers by invoking copy_user_to_fpregs_zeroing(). If it fails try the slowpath which can handle pagefaults. [ bp: Add a comment over the fastpath to be able to find one's way around the function. ] Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: Radim Krčmář <rkrcmar@redhat.com> Cc: Rik van Riel <riel@surriel.com> Cc: x86-ml <x86@kernel.org> Link: https://lkml.kernel.org/r/20190403164156.19645-25-bigeasy@linutronix.de
2019-04-12arm64: dts: mt8183: add pinctrl fileZhiyong Tao
This patch adds pinctrl file for mt8183. Signed-off-by: Zhiyong Tao <zhiyong.tao@mediatek.com> Signed-off-by: Erin Lo <erin.lo@mediatek.com> Reviewed-by: Rob Herring <robh@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2019-04-12x86/fpu: Defer FPU state load until return to userspaceRik van Riel
Defer loading of FPU state until return to userspace. This gives the kernel the potential to skip loading FPU state for tasks that stay in kernel mode, or for tasks that end up with repeated invocations of kernel_fpu_begin() & kernel_fpu_end(). The fpregs_lock/unlock() section ensures that the registers remain unchanged. Otherwise a context switch or a bottom half could save the registers to its FPU context and the processor's FPU registers would became random if modified at the same time. KVM swaps the host/guest registers on entry/exit path. This flow has been kept as is. First it ensures that the registers are loaded and then saves the current (host) state before it loads the guest's registers. The swap is done at the very end with disabled interrupts so it should not change anymore before theg guest is entered. The read/save version seems to be cheaper compared to memcpy() in a micro benchmark. Each thread gets TIF_NEED_FPU_LOAD set as part of fork() / fpu__copy(). For kernel threads, this flag gets never cleared which avoids saving / restoring the FPU state for kernel threads and during in-kernel usage of the FPU registers. [ bp: Correct and update commit message and fix checkpatch warnings. s/register/registers/ where it is used in plural. minor comment corrections. remove unused trace_x86_fpu_activate_state() TP. ] Signed-off-by: Rik van Riel <riel@surriel.com> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Borislav Petkov <bp@suse.de> Reviewed-by: Dave Hansen <dave.hansen@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Cc: Andy Lutomirski <luto@kernel.org> Cc: Aubrey Li <aubrey.li@intel.com> Cc: Babu Moger <Babu.Moger@amd.com> Cc: "Chang S. Bae" <chang.seok.bae@intel.com> Cc: Dmitry Safonov <dima@arista.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jann Horn <jannh@google.com> Cc: "Jason A. Donenfeld" <Jason@zx2c4.com> Cc: Joerg Roedel <jroedel@suse.de> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: kvm ML <kvm@vger.kernel.org> Cc: Nicolai Stange <nstange@suse.de> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: "Radim Krčmář" <rkrcmar@redhat.com> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Waiman Long <longman@redhat.com> Cc: x86-ml <x86@kernel.org> Cc: Yi Wang <wang.yi59@zte.com.cn> Link: https://lkml.kernel.org/r/20190403164156.19645-24-bigeasy@linutronix.de
2019-04-12arm64: dts: Using standard CCF interface to set vcodec clkYunfei Dong
Using standard CCF interface to set vdec/venc parent clk and clk rate. Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> Signed-off-by: Qianqian Yan <qianqian.yan@mediatek.com> Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
2019-04-12ARM: dts: dra7: Separate AM57 dtsi filesRoger Quadros
AM5 and DRA7 SoC families have different set of modules in them so the SoC sepecific dtsi files need to be separated. e.g. Some of the major differences between AM576 and DRA76 DRA76x AM576x USB3 x USB4 x ATL x VCP x MLB x ISS x PRU-ICSS1 x PRU-ICSS2 x This patch only deals with disabling USB3, USB4 and ATL for AM57 variants. Signed-off-by: Roger Quadros <rogerq@ti.com> Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12arm64: ptrace: Add function argument access APIMasami Hiramatsu
Add regs_get_argument() which returns N th argument of the function call. On arm64, it supports up to 8th argument. Note that this chooses most probably assignment, in some case it can be incorrect (e.g. passing data structure or floating point etc.) This enables ftrace kprobe events to access kernel function arguments via $argN syntax. Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org> [will: tidied up the comment a bit] Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-12ARM: dts: am335x: icev2: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: evmsk: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: evm: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-04-12ARM: dts: am335x: cm-t335: Replaced register offsets with definesChristina Quast
The defines are taken from dt-bindings/pinctrl/am33xx.h Signed-off-by: Christina Quast <cquast@hanoverdisplays.com> Signed-off-by: Tony Lindgren <tony@atomide.com>