summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2019-12-19arm64: dts: qcom: qcs404: Update the compatible for watchdog timerSai Prakash Ranjan
Update the compatible for QCS404 watchdog timer with proper SoC specific compatible. Signed-off-by: Sai Prakash Ranjan <saiprakash.ranjan@codeaurora.org> Link: https://lore.kernel.org/r/757995875cc12d3f5a8f5fd5659b04653950970a.1576211720.git.saiprakash.ranjan@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-19ARM: dts: exynos: Adjust bus related OPPs to the values correct for ↵Marek Szyprowski
Exynos5422 Odroids Hardkernel's Odroid XU3/XU4/HC1 boards use bootloader, which configures top PLLs to the following values: MPLL: 532MHz, CPLL: 666MHz and DPLL: 600MHz. Adjust all bus related OPPs to the values that are possible to derive from the top PLL configured by the bootloader. Also add a comment for each bus describing which PLL is used for it. The most significant change is the highest rate for wcore bus. It has been increased to 532MHz as this is the value configured initially by the bootloader. Also the voltage for this OPP is changed to match the value set by the bootloader. This patch finally allows the buses to operate on the rates matching the values set for each OPP and fixes the following warnings observed on boot: exynos-bus: new bus device registered: soc:bus_wcore ( 84000 KHz ~ 400000 KHz) exynos-bus: new bus device registered: soc:bus_noc ( 67000 KHz ~ 100000 KHz) exynos-bus: new bus device registered: soc:bus_fsys_apb (100000 KHz ~ 200000 KHz) ... exynos-bus soc:bus_wcore: dev_pm_opp_set_rate: failed to find current OPP for freq 532000000 (-34) exynos-bus soc:bus_noc: dev_pm_opp_set_rate: failed to find current OPP for freq 111000000 (-34) exynos-bus soc:bus_fsys_apb: dev_pm_opp_set_rate: failed to find current OPP for freq 222000000 (-34) The problem with setting incorrect (in some cases much lower) clock rate for the defined OPP were there from the beginning, but went unnoticed because the only way to observe it was to manually check the rate of the respective clocks. The commit 4294a779bd8d ("PM / devfreq: exynos-bus: Convert to use dev_pm_opp_set_rate()") finally revealed it, because it enabled use of the generic code from the OPP framework, which issues the above mentioned warnings. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-12-19ARM: dts: exynos: Move Exynos5420 bus related OPPs to the Odroid boards DTSMarek Szyprowski
Currently the only Exynos5422-based boards that support bus frequency scaling are Hardkernel's Odroid XU3/XU4/HC1. Move the bus related OPPs to the boards DTS, because those OPPs heavily depend on the clock topology and top PLL rates, which are being configured by the board's bootloader. Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Chanwoo Choi <cw00.choi@samsung.com> Reviewed-by: Chanwoo Choi <cw00.choi@samsung.com> Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
2019-12-19RISC-V: Typo fixes in image header and documentation.Atish Patra
There are some typos in boot image header and riscv boot documentation. Fix the typos. Signed-off-by: Atish Patra <atish.patra@wdc.com> Reviewed-by: Palmer Dabbelt <palmerdabbelt@google.com> Link: https://lore.kernel.org/r/20191009010637.9955-1-atish.patra@wdc.com Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-12-19riscv, perf: Add arch specific perf_arch_bpf_user_pt_regsBjörn Töpel
RISC-V was missing a proper perf_arch_bpf_user_pt_regs macro for CONFIG_PERF_EVENT builds. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-10-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Add missing uapi header for BPF_PROG_TYPE_PERF_EVENT programsBjörn Töpel
Add missing uapi header the BPF_PROG_TYPE_PERF_EVENT programs by exporting struct user_regs_struct instead of struct pt_regs which is in-kernel only. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-9-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Optimize callsBjörn Töpel
Instead of using emit_imm() and emit_jalr() which can expand to six instructions, start using jal or auipc+jalr. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-8-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Provide RISC-V specific JIT image alloc/freeBjörn Töpel
This commit makes sure that the JIT images is kept close to the kernel text, so BPF calls can use relative calling with auipc/jalr or jal instead of loading the full 64-bit address and jalr. The BPF JIT image region is 128 MB before the kernel text. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-7-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Optimize BPF tail callsBjörn Töpel
Remove one addi, and instead use the offset part of jalr. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-6-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Add support for far jumps and exitsBjörn Töpel
This commit add support for far (offset > 21b) jumps and exits. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Luke Nelson <lukenels@cs.washington.edu> Link: https://lore.kernel.org/bpf/20191216091343.23260-5-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Add support for far branching when emitting tail callBjörn Töpel
Start use the emit_branch() function in the tail call emitter in order to support far branching. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-4-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Add support for far branchingBjörn Töpel
This commit adds branch relaxation to the BPF JIT, and with that support for far (offset greater than 12b) branching. The branch relaxation requires more than two passes to converge. For most programs it is three passes, but for larger programs it can be more. Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Reviewed-by: Luke Nelson <lukenels@cs.washington.edu> Link: https://lore.kernel.org/bpf/20191216091343.23260-3-bjorn.topel@gmail.com
2019-12-19riscv, bpf: Fix broken BPF tail callsBjörn Töpel
The BPF JIT incorrectly clobbered the a0 register, and did not flag usage of s5 register when BPF stack was being used. Fixes: 2353ecc6f91f ("bpf, riscv: add BPF JIT for RV64G") Signed-off-by: Björn Töpel <bjorn.topel@gmail.com> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20191216091343.23260-2-bjorn.topel@gmail.com
2019-12-19ARC: asm-offsets: remove duplicate entryEugeniy Paltsev
We define 'PT_user_r25' twice in asm-offsets.c It's not a big issue as we define it to the same value, however let's fix it. Signed-off-by: Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
2019-12-18MIPS: BPF: eBPF JIT: check for MIPS ISA compliance in KconfigAlexander Lobakin
It is completely wrong to check for compile-time MIPS ISA revision in the body of bpf_int_jit_compile() as it may lead to get MIPS JIT fully omitted by the CC while the rest system will think that the JIT is actually present and works [1]. We can check if the selected CPU really supports MIPS eBPF JIT at configure time and avoid such situations when kernel can be built without both JIT and interpreter, but with CONFIG_BPF_SYSCALL=y. [1] https://lore.kernel.org/linux-mips/09d713a59665d745e21d021deeaebe0a@dlink.ru/ Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") Cc: <stable@vger.kernel.org> # v5.2+ Signed-off-by: Alexander Lobakin <alobakin@dlink.ru> Signed-off-by: Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Hassan Naveed <hnaveed@wavecomp.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Martin KaFai Lau <kafai@fb.com> Cc: Song Liu <songliubraving@fb.com> Cc: Yonghong Song <yhs@fb.com> Cc: Andrii Nakryiko <andriin@fb.com> Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: netdev@vger.kernel.org Cc: bpf@vger.kernel.org
2019-12-18MIPS: BPF: Disable MIPS32 eBPF JITPaul Burton
Commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") enabled our eBPF JIT for MIPS32 kernels, whereas it has previously only been availailable for MIPS64. It was my understanding at the time that the BPF test suite was passing & JITing a comparable number of tests to our cBPF JIT [1], but it turns out that was not the case. The eBPF JIT has a number of problems on MIPS32: - Most notably various code paths still result in emission of MIPS64 instructions which will cause reserved instruction exceptions & kernel panics when run on MIPS32 CPUs. - The eBPF JIT doesn't account for differences between the O32 ABI used by MIPS32 kernels versus the N64 ABI used by MIPS64 kernels. Notably arguments beyond the first 4 are passed on the stack in O32, and this is entirely unhandled when JITing a BPF_CALL instruction. Stack space must be reserved for arguments even if they all fit in registers, and the callee is free to assume that stack space has been reserved for its use - with the eBPF JIT this is not the case, so calling any function can result in clobbering values on the stack & unpredictable behaviour. Function arguments in eBPF are always 64-bit values which is also entirely unhandled - the JIT still uses a single (32-bit) register per argument. As a result all function arguments are always passed incorrectly when JITing a BPF_CALL instruction, leading to kernel crashes or strange behavior. - The JIT attempts to bail our on use of ALU64 instructions or 64-bit memory access instructions. The code doing this at the start of build_one_insn() incorrectly checks whether BPF_OP() equals BPF_DW, when it should really be checking BPF_SIZE() & only doing so when BPF_CLASS() is one of BPF_{LD,LDX,ST,STX}. This results in false positives that cause more bailouts than intended, and that in turns hides some of the problems described above. - The kernel's cBPF->eBPF translation makes heavy use of 64-bit eBPF instructions that the MIPS32 eBPF JIT bails out on, leading to most cBPF programs not being JITed at all. Until these problems are resolved, revert the enabling of the eBPF JIT on MIPS32 done by commit 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture."). Note that this does not undo the changes made to the eBPF JIT by that commit, since they are a useful starting point to providing MIPS32 support - they're just not nearly complete. [1] https://lore.kernel.org/linux-mips/MWHPR2201MB13583388481F01A422CE7D66D4410@MWHPR2201MB1358.namprd22.prod.outlook.com/ Signed-off-by: Paul Burton <paulburton@kernel.org> Fixes: 716850ab104d ("MIPS: eBPF: Initial eBPF support for MIPS32 architecture.") Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Hassan Naveed <hnaveed@wavecomp.com> Cc: Tony Ambardar <itugrok@yahoo.com> Cc: bpf@vger.kernel.org Cc: netdev@vger.kernel.org Cc: <stable@vger.kernel.org> # v5.2+ Cc: linux-mips@vger.kernel.org Cc: linux-kernel@vger.kernel.org
2019-12-18MIPS: Prevent link failure with kcov instrumentationJouni Hogander
__sanitizer_cov_trace_pc() is not linked in and causing link failure if KCOV_INSTRUMENT is enabled. Fix this by disabling instrumentation for compressed image. Signed-off-by: Jouni Hogander <jouni.hogander@unikie.com> Signed-off-by: Paul Burton <paulburton@kernel.org> Cc: Lukas Bulwahn <lukas.bulwahn@gmail.com> Cc: linux-mips@vger.kernel.org
2019-12-18s390/ftrace: save traced function callerVasily Gorbik
A typical backtrace acquired from ftraced function currently looks like the following (e.g. for "path_openat"): arch_stack_walk+0x15c/0x2d8 stack_trace_save+0x50/0x68 stack_trace_call+0x15a/0x3b8 ftrace_graph_caller+0x0/0x1c 0x3e0007e3c98 <- ftraced function caller (should be do_filp_open+0x7c/0xe8) do_open_execat+0x70/0x1b8 __do_execve_file.isra.0+0x7d8/0x860 __s390x_sys_execve+0x56/0x68 system_call+0xdc/0x2d8 Note random "0x3e0007e3c98" stack value as ftraced function caller. This value causes either imprecise unwinder result or unwinding failure. That "0x3e0007e3c98" comes from r14 of ftraced function stack frame, which it haven't had a chance to initialize since the very first instruction calls ftrace code ("ftrace_caller"). (ftraced function might never save r14 as well). Nevertheless according to s390 ABI any function is called with stack frame allocated for it and r14 contains return address. "ftrace_caller" itself is called with "brasl %r0,ftrace_caller". So, to fix this issue simply always save traced function caller onto ftraced function stack frame. Reported-by: Sven Schnelle <svens@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-18s390/unwind: stop gracefully at user mode pt_regs in irq stackVasily Gorbik
Consider reaching user mode pt_regs at the bottom of irq stack graceful unwinder termination. This is the case when irq/mcck/ext interrupt arrives while in user mode. Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-18s390/purgatory: do not build purgatory with kcov, kasan and friendsChristian Borntraeger
the purgatory must not rely on functions from the "old" kernel, so we must disable kasan and friends. We also need to have a separate copy of string.c as the default does not build memcmp with KASAN. Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-18s390/purgatory: Make sure we fail the build if purgatory has missing symbolsHans de Goede
Since we link purgatory with -r aka we enable "incremental linking" no checks for unresolved symbols are done while linking the purgatory. This commit adds an extra check for unresolved symbols by calling ld without -r before running objcopy to generate purgatory.ro. This will help us catch missing symbols in the purgatory sooner. Note this commit also removes --no-undefined from LDFLAGS_purgatory as that has no effect. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/lkml/20191212205304.191610-1-hdegoede@redhat.com Tested-by: Philipp Rudo <prudo@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-18s390/ftrace: fix endless recursion in function_graph tracerSven Schnelle
The following sequence triggers a kernel stack overflow on s390x: mount -t tracefs tracefs /sys/kernel/tracing cd /sys/kernel/tracing echo function_graph > current_tracer [crash] This is because preempt_count_{add,sub} are in the list of traced functions, which can be demonstrated by: echo preempt_count_add >set_ftrace_filter echo function_graph > current_tracer [crash] The stack overflow happens because get_tod_clock_monotonic() gets called by ftrace but itself calls preempt_{disable,enable}(), which leads to a endless recursion. Fix this by using preempt_{disable,enable}_notrace(). Fixes: 011620688a71 ("s390/time: ensure get_clock_monotonic() returns monotonic values") Signed-off-by: Sven Schnelle <svens@linux.ibm.com> Reviewed-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Vasily Gorbik <gor@linux.ibm.com>
2019-12-18Merge tag 'socfpga_dts_fix_for_v5.5' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into arm/fixes arm64: dts: agilex/stratix10: fix pmu interrupt numbers - Fix incorrect PMU interrupts numbers on the Agilex/Stratix10 platforms * tag 'socfpga_dts_fix_for_v5.5' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux: arm64: dts: agilex/stratix10: fix pmu interrupt numbers Link: https://lore.kernel.org/r/20191218161336.32377-1-dinguyen@kernel.org Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-18arm64: dts: qcom: sc7180: Fix I2C/UART numbers 2, 4, 7, and 9Douglas Anderson
Commit f4a73f5e2633 ("pinctrl: qcom: sc7180: Add new qup functions") has landed which means that we absolutely need to use the proper names for the pinmuxing for I2C/UART numbers 2, 4, 7, and 9. Let's do it. For reference: - If you get only one of this commit and the pinctrl commit then none of I2C/UART 2, 4, 7, and 9 will work. - If you get neither of these commits then I2C 2, 4, 7, and 9 will work but not UART. ...but despite the above it should be fine for this commit to land in the Qualcomm tree because sc7180.dtsi only exists there (it hasn't made it to mainline). Reviewed-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Rajendra Nayak <rnayak@codeaurora.org> Fixes: ba3fc6496366 ("arm64: dts: sc7180: Add qupv3_0 and qupv3_1") Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20191217130352.1.Id8562de45e8441cac34699047e25e7424281e9d4@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-18y2038: sh: remove timeval/timespec usage from headersArnd Bergmann
This header file escaped my earlier cleanups for removing the in-kernel usage of timeval and timespec structs. Replace them with the corresponding __kernel_old_* types. Acked-by: Rich Felker <dalias@libc.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-12-18y2038: sparc: remove use of struct timexArnd Bergmann
'struct timex' is one of the last users of 'struct timeval' and is only referenced in one place in the kernel any more, to convert the user space timex into the kernel-internal version on sparc64, with a different tv_usec member type. As a preparation for hiding the time_t definition and everything using that in the kernel, change the implementation once more to only convert the timeval member, and then enclose the struct definition in an #ifdef. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-12-18um: ubd: use 64-bit time_t where possibleArnd Bergmann
The ubd code suffers from a possible y2038 overflow on 32-bit architectures, both for the cow header and the os_file_modtime() function. Replace time_t with time64_t to extend the ubd_kern side as much as possible. Whether this makes a difference for the user side depends on the host libc implementation that may use either 32-bit or 64-bit time_t. For the cow file format, the header contains an unsigned 32-bit timestamp, which is good until y2106, passing this through a 'long long' gives us a consistent interpretation between 32-bit and 64-bit um kernels. Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-12-18xtensa: ISS: avoid struct timevalArnd Bergmann
'struct timeval' will get removed from the kernel, change the one user in arch/xtensa to avoid referencing it, by using a fixed-length array instead. Acked-by: Max Filippov <jcmvbkbc@gmail.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2019-12-18Merge tag 'kvmarm-fixes-5.5-1' of ↵Paolo Bonzini
git://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into kvm-master KVM/arm fixes for .5.5, take #1 - Fix uninitialised sysreg accessor - Fix handling of demand-paged device mappings - Stop spamming the console on IMPDEF sysregs - Relax mappings of writable memslots - Assorted cleanups
2019-12-18kvm: x86: Host feature SSBD doesn't imply guest feature AMD_SSBDJim Mattson
The host reports support for the synthetic feature X86_FEATURE_SSBD when any of the three following hardware features are set: CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] CPUID.80000008H:EBX.AMD_SSBD[bit 24] CPUID.80000008H:EBX.VIRT_SSBD[bit 25] Either of the first two hardware features implies the existence of the IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does not. Therefore, CPUID.80000008H:EBX.AMD_SSBD[bit 24] should only be set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host. Fixes: 4c6903a0f9d76 ("KVM: x86: fix reporting of AMD speculation bug CPUID leaf") Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Jacob Xu <jacobhxu@google.com> Reviewed-by: Peter Shier <pshier@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: stable@vger.kernel.org Reported-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-18kvm: x86: Host feature SSBD doesn't imply guest feature SPEC_CTRL_SSBDJim Mattson
The host reports support for the synthetic feature X86_FEATURE_SSBD when any of the three following hardware features are set: CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] CPUID.80000008H:EBX.AMD_SSBD[bit 24] CPUID.80000008H:EBX.VIRT_SSBD[bit 25] Either of the first two hardware features implies the existence of the IA32_SPEC_CTRL MSR, but CPUID.80000008H:EBX.VIRT_SSBD[bit 25] does not. Therefore, CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] should only be set in the guest if CPUID.(EAX=7,ECX=0):EDX.SSBD[bit 31] or CPUID.80000008H:EBX.AMD_SSBD[bit 24] is set on the host. Fixes: 0c54914d0c52a ("KVM: x86: use Intel speculation bugs and features as derived in generic x86 code") Signed-off-by: Jim Mattson <jmattson@google.com> Reviewed-by: Jacob Xu <jacobhxu@google.com> Reviewed-by: Peter Shier <pshier@google.com> Cc: Paolo Bonzini <pbonzini@redhat.com> Cc: stable@vger.kernel.org Reported-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-18ARM: dts: zynq: enablement of coresight topologyZumeng Chen
This patch is to build the coresight topology structure of zynq-7000 series according to the docs of coresight and userguide of zynq-7000. Signed-off-by: Zumeng Chen <zumeng.chen@windriver.com> Signed-off-by: Quanyang Wang <quanyang.wang@windriver.com> Reviewed-by: Mathieu Poirier <mathieu.poirier@linaro.org> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
2019-12-18tty/serial: Migrate 8250_fsl to use has_sysrqDmitry Safonov
The SUPPORT_SYSRQ ifdeffery is not nice as: - May create misunderstanding about sizeof(struct uart_port) between different objects - Prevents moving functions from serial_core.h - Reduces readability (well, it's ifdeffery - it's hard to follow) In order to remove SUPPORT_SYSRQ, has_sysrq variable has been added. Initialise it in driver's probe and remove ifdeffery. In contrast to 8250/8250_of, legacy_serial on powerpc does fill (struct plat_serial8250_port). The reason is likely that it's done on device_initcall(), not on probe. So, 8250_core is not yet probed. Propagate value from platform_device on 8250 probe - in case powepc legacy driver it's initialized on initcall, in case 8250_of it will be initialized later on of_platform_serial_setup(). Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Dmitry Safonov <dima@arista.com> Link: https://lore.kernel.org/r/20191213000657.931618-6-dima@arista.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-12-18x86/Kconfig: Correct spelling and punctuationRandy Dunlap
End a sentence with a period (aka full stop) in Kconfig help text. Fix minor NUMA-related Kconfig text: - Use capital letters for NUMA acronym. - Hyphenate Non-Uniform. [ bp: Merge into a single patch. ] Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Borislav Petkov <bp@suse.de> Cc: "H. Peter Anvin" <hpa@zytor.com> Cc: Ingo Molnar <mingo@redhat.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: X86 ML <x86@kernel.org> Link: https://lkml.kernel.org/r/443ed0a8-783d-6c7c-3258-e1c44df03fd7@infradead.org
2019-12-17arm64: dts: msm8998-clamshell: Add pm8005_s1 regulatorJeffrey Hugo
The pm8005_s1 is VDD_GFX, and needs to be on to enable the GPU. This should be hooked up to the GPU CPR, but we don't have support for that yet, so until then, just turn on the regulator and keep it on so that we can focus on basic GPU bringup. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Link: https://lore.kernel.org/r/20191217170249.5280-1-jeffrey.l.hugo@gmail.com Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-17arm64: dts: qcom: sc7180: Add wakeup parent for TLMMMaulik Shah
Specify wakeup parent irqchip for sc7180 TLMM. Reviewed-by: Lina Iyer <ilina@codeaurora.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Cc: devicetree@vger.kernel.org Signed-off-by: Maulik Shah <mkshah@codeaurora.org> Link: https://lore.kernel.org/r/1572419178-5750-3-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-17arm64: dts: qcom: sm8150: Add ADSP, CDSP, MPSS and SLPI remoteprocsSibi Sankar
Add ADSP, CDSP, MPSS and SLPI device tree nodes for SM8150 SoC. Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org> Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20191217092503.10699-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-17arm64: dts: qcom: sc7180: Fix node orderMatthias Kaehlcke
The SC7180 device tree nodes should be ordered by address. Re-shuffle some nodes which currently don't follow this convention. Since we are already moving it add a missing leading zero to the address in the 'reg' property of the 'interrupt-controller@b220000' node. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Douglas Anderson <dianders@chromium.org> Link: https://lore.kernel.org/r/20191212170824.v2.1.I55198466344789267ed1eb5ec555fd890c9fc6e1@changeid Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-17arm64: dts: qcom: msm8998: Fixup uart3 gpio config for bluetoothJeffrey Hugo
It turns out that the wcn3990 can float the gpio lines during bootup, etc which will result in the uart core thinking there is incoming data. This results in the bluetooth stack getting garbage. By applying a bias to match what wcn3990 would drive, the issue is corrected. Signed-off-by: Jeffrey Hugo <jeffrey.l.hugo@gmail.com> Link: https://lore.kernel.org/r/20191021161921.31825-1-jeffrey.l.hugo@gmail.com [bjorn: Moved board specific pinctrl states to the end] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-18KVM: PPC: Book3S HV: Don't do ultravisor calls on systems without ultravisorPaul Mackerras
Commit 22945688acd4 ("KVM: PPC: Book3S HV: Support reset of secure guest") added a call to uv_svm_terminate, which is an ultravisor call, without any check that the guest is a secure guest or even that the system has an ultravisor. On a system without an ultravisor, the ultracall will degenerate to a hypercall, but since we are not in KVM guest context, the hypercall will get treated as a system call, which could have random effects depending on what happens to be in r0, and could also corrupt the current task's kernel stack. Hence this adds a test for the guest being a secure guest before doing uv_svm_terminate(). Fixes: 22945688acd4 ("KVM: PPC: Book3S HV: Support reset of secure guest") Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
2019-12-17ARM: dts: beagle-x15-common: Model 5V0 regulatorKishon Vijay Abraham I
On am57xx-beagle-x15, 5V0 is connected to P16, P17, P18 and P19 connectors. On am57xx-evm, 5V0 regulator is used to get 3V6 regulator which is connected to the COMQ port. Model 5V0 regulator here in order for it to be used in am57xx-evm to model 3V6 regulator. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17ARM: defconfig: u8500: activate cpufreqLinus Walleij
This activates the device tree-based cpufreq driver that Ux500 is using and enables the schedutil and ondemand governors with schedutil as default. This works fine in the setups I have tested. Link: https://lore.kernel.org/r/20191217202648.23206-1-linus.walleij@linaro.org Cc: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-17Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fix from Ingo Molnar: "Fix kexec booting with certain EFI memory map layouts" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage
2019-12-17Merge branch 'timers-urgent-for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull timer fixes from Ingo Molnar: "Add HPET quirks for the Intel 'Coffee Lake H' and 'Ice Lake' platforms" * 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/intel: Disable HPET on Intel Ice Lake platforms x86/intel: Disable HPET on Intel Coffee Lake H platforms
2019-12-17ARM: dts: am571x-idk: Fix gpios property to have the correct gpio numberKishon Vijay Abraham I
commit d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for EP mode") while adding the dt node for EP mode for DRA7 platform, added rc node for am571x-idk and populated gpios property with "gpio3 23". However the GPIO_PCIE_SWRST line is actually connected to "gpio5 18". Fix it here. (The patch adding "gpio3 23" was tested with another am57x board in EP mode which doesn't rely on reset from host). Cc: stable <stable@vger.kernel.org> # 4.14+ Fixes: d23f3839fe97d8dce03d ("ARM: dts: DRA7: Add pcie1 dt node for EP mode") Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17ARM: dts: am57xx-beagle-x15/am57xx-idk: Remove "gpios" for endpoint dt nodesKishon Vijay Abraham I
PERST# line in the PCIE connector is driven by the host mode and not EP mode. The gpios property here is used for driving the PERST# line. Remove gpios property from all endpoint device tree nodes. Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17Merge tag 'ux500-armsoc-v5.6-1' of ↵Olof Johansson
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into arm/dt First set of Ux500 DTS changes for the v5.6 kernel: - Add the GPADC IIO channels - Factor out generic pin configuration - Add the gpio_in_nopull configuration - Tighten up I2C and SPI buses - Clean up some compatibles - Extract a generic DB8500 DTSI - Add HREF520 DTS and the associated DB8520 DTSI - Split TVK R2 and R3 to separate DTSI files * tag 'ux500-armsoc-v5.6-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson: ARM: dts: ux500: Add devicetree for HREF520 ARM: dts: ux500: Split TVK DTSI files in two ARM: dts: ux500: Break out DB8500 DTSI ARM: dts: ux500: Drop pulls on I2C buses ARM: dts: ux500: Use "arm,pl031" compatible for PL031 ARM: dts: ux500: Add "simple-bus" compatible to soc node ARM: dts: ux500: Remove ux500_ prefix from ux500_serial* labels ARM: dts: ux500: Move serial aliases to ste-dbx5x0.dtsi ARM: dts: ux500: Add aliases for I2C and SPI buses ARM: dts: ux500: Disable I2C/SPI buses by default ARM: dts: ux500: nomadik-pinctrl: Add &gpio_in_nopull ARM: dts: ux500: Add pin configs for UART1 CTS/RTS pins ARM: dts: ux500: Add alternative SDI pin configs ARM: dts: ux500: Rename generic pin configs according to pin group ARM: dts: ux500: Move generic pin configs out of ste-href-family-pinctrl.dtsi dt-bindings: arm: Document compatibles for Ux500 boards ARM: dts: ux500: snowball: Remove unused PRCMU cpufreq node ARM: dts: ux500: declare GPADC IIO ADC channels Link: https://lore.kernel.org/r/CACRpkdYfqJ=VXkP3Qm5Lw63AuR=1ChxbUW+Y-nhw5gCX6sYfDw@mail.gmail.com Signed-off-by: Olof Johansson <olof@lixom.net>
2019-12-17ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 bootSuman Anna
The IPU1 MMU has been using common IOMMU pdata quirks defined and used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops plugged in, so that the IPU1 power domain can be restricted to ON state during the boot and active period of the IPU1 remote processor. This eliminates the pre-conditions for the IPU1 boot issue as described in commit afe518400bdb ("iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache"). NOTE: 1. RET is not a valid target power domain state on DRA7 platforms, and IPU power domain is normally programmed for OFF. The IPU1 still fails to boot though, and an unclearable l3_noc error is thrown currently on 4.14 kernel without this fix. This behavior is slightly different from previous 4.9 LTS kernel. 2. The fix is currently applied only to IPU1 on DRA7xx SoC, as the other affected processors on OMAP4/OMAP5/DRA7 are in domains that are not entering RET. IPU2 on DRA7 is in CORE power domain which is only programmed for ON power state. The fix can be easily scaled if these domains do hit RET in the future. 3. The issue was not seen on current DRA7 platforms if any of the DSP remote processors were booted and using one of the GPTimers 5, 6, 7 or 8 on previous 4.9 LTS kernel. This was due to the errata fix for i874 implemented in commit 1cbabcb9807e ("ARM: DRA7: clockdomain: Implement timer workaround for errata i874") which keeps the IPU1 power domain from entering RET when the timers are active. But the timer workaround did not make any difference on 4.14 kernel, and an l3_noc error was seen still without this fix. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17ARM: OMAP2+: omap-iommu.c conversion to ti-syscTero Kristo
Convert omap2 iommu platform code to use ti-sysc instead of legacy omap-device / hwmod interfaces. Signed-off-by: Tero Kristo <t-kristo@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-12-17ARM: OMAP2+: Add workaround for DRA7 DSP MStandby errata i879Suman Anna
Errata Title: i879: DSP MStandby requires CD_EMU in SW_WKUP Description: The DSP requires the internal emulation clock to be actively toggling in order to successfully enter a low power mode via execution of the IDLE instruction and PRCM MStandby/Idle handshake. This assumes that other prerequisites and software sequence are followed. Workaround: The emulation clock to the DSP is free-running anytime CCS is connected via JTAG debugger to the DSP subsystem or when the CD_EMU clock domain is set in SW_WKUP mode. The CD_EMU domain can be set in SW_WKUP mode via the CM_EMU_CLKSTCTRL [1:0]CLKTRCTRL field. Implementation: This patch implements this workaround by denying the HW_AUTO mode for the EMU clockdomain during the power-up of any DSP processor and re-enabling the HW_AUTO mode during the shutdown of the last DSP processor (actually done during the enabling and disabling of the respective DSP MDMA MMUs). Reference counting has to be used to manage the independent sequencing between the multiple DSP processors. This switching is done at runtime rather than a static clockdomain flags value to meet the target power domain state for the EMU power domain during suspend. Note that the DSP MStandby behavior is not consistent across all boards prior to this fix. Please see commit 45f871eec6c0 ("ARM: OMAP2+: Extend DRA7 IPU1 MMU pdata quirks to DSP MDMA MMUs") for details. Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Tony Lindgren <tony@atomide.com>
generated by cgit (git 2.34.1) at 2025-09-23 03:15:27 +0000