summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)Author
2019-12-20ARM: dts: renesas: Group tuples in interrupt propertiesGeert Uytterhoeven
To improve human readability and enable automatic validation, the tuples in the various properties containing interrupt specifiers should be grouped. While "make dtbs_check" does not impose this yet for the "interrupts" property, it does for the "interrupt-map" property, leading to warnings like: pci@ee090000: interrupt-map:0: [0, 0, 0, 1, 5, 0, 108, 4, 2048, 0, 0, 1, 5, 0, 108, 4, 4096, 0, 0, 2, 5, 0, 108, 4] is too long pci@ee0d0000: interrupt-map:0: [0, 0, 0, 1, 5, 0, 113, 4, 2048, 0, 0, 1, 5, 0, 113, 4, 4096, 0, 0, 2, 5, 0, 113, 4] is too long Fix this by grouping the tuples of the "interrupts" and "interrupt-map" properties using angle brackets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191213164115.3697-4-geert+renesas@glider.be Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
2019-12-20ARM: dts: renesas: Group tuples in regulator-gpio states propertiesGeert Uytterhoeven
To improve human readability and enable automatic validation, the tuples in the "states" properties of device nodes compatible with "regulator-gpio" should be grouped, as reported by "make dtbs_check": $ make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/regulator/gpio-regulator.yaml arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi0: states:0: Additional items are not allowed (1800000, 0 were unexpected) arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi0: states:0: [3300000, 1, 1800000, 0] is too long arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi1: states:0: Additional items are not allowed (1800000, 0 were unexpected) arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi1: states:0: [3300000, 1, 1800000, 0] is too long arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi2: states:0: Additional items are not allowed (1800000, 0 were unexpected) arch/arm/boot/dts/r8a7791-koelsch.dt.yaml: regulator-vccq-sdhi2: states:0: [3300000, 1, 1800000, 0] is too long ... Fix this by grouping the tuples using angle brackets. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191213164115.3697-2-geert+renesas@glider.be Reviewed-by: Ulrich Hecht <uli+renesas@fpond.eu>
2019-12-20ARM: dts: r8a7779: Add device node for ARM global timerGeert Uytterhoeven
Add a device node for the global timer, which is part of the Cortex-A9 MPCore. The global timer can serve as an accurate (4 ns) clock source for scheduling and delay loops. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191211135222.26770-4-geert+renesas@glider.be
2019-12-20ARM: dts: sh73a0: Add device node for ARM global timerGeert Uytterhoeven
Add a device node for the global timer, which is part of the Cortex-A9 MPCore. The global timer can serve as an accurate (3 ns) clock source for scheduling and delay loops. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191211135222.26770-3-geert+renesas@glider.be
2019-12-20ARM: dts: sh73a0: Rename twd clock to periph clockGeert Uytterhoeven
The "TWD" clock is actually the Cortex-A9 MPCore "PERIPHCLK" clock, which not only clocks the private timers and watchdogs (TWD), but also the interrupt controller and global timer. Hence rename it from "twd" to "periph". Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20191211135222.26770-2-geert+renesas@glider.be
2019-12-20riscv: move sifive_l2_cache.c to drivers/socChristoph Hellwig
The sifive_l2_cache.c is in no way related to RISC-V architecture memory management. It is a little stub driver working around the fact that the EDAC maintainers prefer their drivers to be structured in a certain way that doesn't fit the SiFive SOCs. Move the file to drivers/soc and add a Kconfig option for it, as well as the whole drivers/soc boilerplate for CONFIG_SOC_SIFIVE. Fixes: a967a289f169 ("RISC-V: sifive_l2_cache: Add L2 cache controller driver for SiFive SoCs") Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Borislav Petkov <bp@suse.de> [paul.walmsley@sifive.com: keep the MAINTAINERS change specific to the L2$ controller code] Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20riscv: define vmemmap before pfn_to_page callsDavid Abdurachmanov
pfn_to_page & page_to_pfn depend on vmemmap being available before the calls if kernel is configured with CONFIG_SPARSEMEM_VMEMMAP=y. This was caused by NOMMU changes which moved vmemmap definition bellow functions definitions calling pfn_to_page & page_to_pfn. Noticed while compiled 5.5-rc2 kernel for Fedora/RISCV. v2: - Add a comment for vmemmap in source Signed-off-by: David Abdurachmanov <david.abdurachmanov@sifive.com> Fixes: 6bd33e1ece52 ("riscv: add nommu support") Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20riscv: fix scratch register clearing in M-mode.Greentime Hu
This patch fixes that the sscratch register clearing in M-mode. It cleared sscratch register in M-mode, but it should clear mscratch register. That will cause kernel trap if the CPU core doesn't support S-mode when trying to access sscratch. Fixes: 9e80635619b5 ("riscv: clear the instruction cache and all registers when booting") Signed-off-by: Greentime Hu <greentime.hu@sifive.com> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20riscv: Fix use of undefined config option CONFIG_CONFIG_MMUAndreas Schwab
In Kconfig files, config options are written without the CONFIG_ prefix. Fixes: 6bd33e1ece52 ("riscv: add nommu support") Signed-off-by: Andreas Schwab <schwab@suse.de> Reviewed-by: Anup Patel <anup@brainfault.org> Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
2019-12-20x86/cpu: Add Jasper Lake to Intel familyZhang Rui
Japser Lake is an Atom family processor. It uses Tremont cores and is targeted at mobile platforms. Reviewed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2019-12-20ARM: dts: sun9i: Remove useless reset and clock namesMaxime Ripard
The MMC configuration clock controller in the A80 definition has a clock-names and reset-names property, even though the binding for that controller doesn't declare it. Remove it. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-20ARM: dts: sun8i: nanopi-duo2: Fix GPIO regulator state arrayMaxime Ripard
Even though it translates to the same thing down to the binary level, we should have an array of 2 number cells to describe each voltage state, which in turns create a validation warning. Let's fix this. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-20ARM: dts: sunxi: Add missing dmas properties to TCONMaxime Ripard
The TCON binding mandates a dmas phandle to the DMAengine channel used for that controller. However, since it's not used in the driver, some device trees have been missing it. Let's add it. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-20ARM: dts: sun8i: v3s: Remove redundant assigned-clocksMaxime Ripard
The V3s mixer node has an assigned clocks property, while the driver also enforces it. Since assigned-clocks is pretty fragile anyway, let's just remove it. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-20ARM: dts: sun9i: Make sure the USB PHY resources are in the same orderMaxime Ripard
While this is functional, it's a best practice to always have the clocks and reset lines in order, in case we ever need to have compatibility code. Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
2019-12-20crypto: arm64 - Use modern annotations for assembly functionsMark Brown
In an effort to clarify and simplify the annotation of assembly functions in the kernel new macros have been introduced. These replace ENTRY and ENDPROC and also add a new annotation for static functions which previously had no ENTRY equivalent. Update the annotations in the crypto code to the new macros. There are a small number of files imported from OpenSSL where the assembly is generated using perl programs, these are not currently annotated at all and have not been modified. Signed-off-by: Mark Brown <broonie@kernel.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2019-12-19arm64: dts: qcom: sc7180: Add remoteproc enablersSibi Sankar
Add scm, smem, smp2p, aoss-qmp, aoss-cc and pdc-global device nodes to SC7180 SoCs. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20191218143332.29107-1-sibis@codeaurora.org [bjorn: Updated subject] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
2019-12-19arm64: dts: qcom: sm8150: Add cpufreq HW device nodeSibi Sankar
Add cpufreq HW device node to scale 4-Silver/3-Gold/1-Gold+ cores on SM8150 SoCs. Signed-off-by: Sibi Sankar <sibis@codeaurora.org> Link: https://lore.kernel.org/r/20191219120633.20723-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
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>
generated by cgit (git 2.34.1) at 2025-09-24 11:52:04 +0000