summaryrefslogtreecommitdiff
path: root/arch
AgeCommit message (Collapse)AuthorFilesLines
2023-07-19sh: hd64461: Handle virq offset for offchip IRQ base and HD64461 IRQArtur Rojek2-3/+3
commit 7c28a35e19fafa1d3b367bcd3ec4021427a9397b upstream. A recent change to start counting SuperH IRQ #s from 16 breaks support for the Hitachi HD64461 companion chip. Move the offchip IRQ base and HD64461 IRQ # by 16 in order to accommodate for the new virq numbering rules. Fixes: a8ac2961148e ("sh: Avoid using IRQ0 on SH3 and SH4") Signed-off-by: Artur Rojek <contact@artur-rojek.eu> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230710233132.69734-1-contact@artur-rojek.eu Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19sh: mach-dreamcast: Handle virq offset in cascaded IRQ demuxGeert Uytterhoeven1-3/+3
commit 3d20f7a6eb76afdf9d4ad9cb864c2e2da9c38e1f upstream. Take into account the virq offset when translating cascaded interrupts. Fixes: a8ac2961148e8c72 ("sh: Avoid using IRQ0 on SH3 and SH4") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/7d0cb246c9f1cd24bb1f637ec5cb67e799a4c3b8.1688908227.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19sh: mach-highlander: Handle virq offset in cascaded IRL demuxGeert Uytterhoeven1-2/+2
commit a2601b8d8f077368c6d113b4d496559415c6d495 upstream. Take into account the virq offset when translating cascaded IRL interrupts. Fixes: a8ac2961148e8c72 ("sh: Avoid using IRQ0 on SH3 and SH4") Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/4fcb0d08a2b372431c41e04312742dc9e41e1be4.1688908186.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19sh: mach-r2d: Handle virq offset in cascaded IRL demuxGeert Uytterhoeven1-2/+2
commit ab8aa4f0956d2e0fb8344deadb823ef743581795 upstream. When booting rts7751r2dplus_defconfig on QEMU, the system hangs due to an interrupt storm on IRQ 20. IRQ 20 aka event 0x280 is a cascaded IRL interrupt, which maps to IRQ_VOYAGER, the interrupt used by the Silicon Motion SM501 multimedia companion chip. As rts7751r2d_irq_demux() does not take into account the new virq offset, the interrupt is no longer translated, leading to an unhandled interrupt. Fix this by taking into account the virq offset when translating cascaded IRL interrupts. Fixes: a8ac2961148e8c72 ("sh: Avoid using IRQ0 on SH3 and SH4") Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/r/fbfea3ad-d327-4ad5-ac9c-648c7ca3fe1f@roeck-us.net Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://lore.kernel.org/r/2c99d5df41c40691f6c407b7b6a040d406bc81ac.1688901306.git.geert+renesas@glider.be Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19LoongArch: Include KBUILD_CPPFLAGS in CHECKFLAGS invocationWANG Xuerui1-1/+1
commit 5ddc7a3794ddd3470635ebd325fa1dffea5b18c0 upstream. This is a port of commit 08f6554ff90e ("mips: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation") to arch/loongarch, for fixing cross-compilation of Linux/LoongArch with Clang, where previously the `--target` flag would no longer be present for the CHECKFLAGS cc invocation leading to build failure. Reported-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://github.com/ClangBuiltLinux/linux/issues/1787#issuecomment-1608306002 Signed-off-by: WANG Xuerui <git@xen0n.name> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19powerpc/vdso: Include CLANG_FLAGS explicitly in ldflags-yNathan Chancellor1-1/+1
commit a7e5eb53bf9b800d086e2ebcfebd9a3bb16bd1b0 upstream. A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to KBUILD_CPPFLAGS so that '--target' is available while preprocessing. When that occurs, the following error appears when building the compat PowerPC vDSO: clang: error: unsupported option '-mbig-endian' for target 'x86_64-pc-linux-gnu' make[3]: *** [.../arch/powerpc/kernel/vdso/Makefile:76: arch/powerpc/kernel/vdso/vdso32.so.dbg] Error 1 Explicitly add CLANG_FLAGS to ldflags-y, so that '--target' will always be present. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19mips: Include KBUILD_CPPFLAGS in CHECKFLAGS invocationNathan Chancellor1-1/+1
commit 08f6554ff90ef189e6b8f0303e57005bddfdd6a7 upstream. A future change will move CLANG_FLAGS from KBUILD_{A,C}FLAGS to KBUILD_CPPFLAGS so that '--target' is available while preprocessing. When that occurs, the following error appears when building ARCH=mips with clang (tip of tree error shown): clang: error: unsupported option '-mabi=' for target 'x86_64-pc-linux-gnu' Add KBUILD_CPPFLAGS in the CHECKFLAGS invocation to keep everything working after the move. Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19ARM: orion5x: fix d2net gpio initializationArnd Bergmann2-0/+9
commit f8ef1233939495c405a9faa4bd1ae7d3f581bae4 upstream. The DT version of this board has a custom file with the gpio device. However, it does nothing because the d2net_init() has no caller or prototype: arch/arm/mach-orion5x/board-d2net.c:101:13: error: no previous prototype for 'd2net_init' Call it from the board-dt file as intended. Fixes: 94b0bd366e36 ("ARM: orion5x: convert d2net to Device Tree") Reviewed-by: Andrew Lunn <andrew@lunn.ch> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230516153109.514251-10-arnd@kernel.org Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19ARM: dts: qcom: ipq4019: fix broken NAND controller properties overrideKrzysztof Kozlowski3-15/+15
commit edcbdd57de499305e2a3737d4a73fe387f71d84c upstream. After renaming NAND controller node name from "qpic-nand" to "nand-controller", the board DTS/DTSI also have to be updated: Warning (unit_address_vs_reg): /soc/qpic-nand@79b0000: node has a unit name, but no reg or ranges property Cc: <stable@vger.kernel.org> Fixes: 9e1e00f18afc ("ARM: dts: qcom: Fix node name for NAND controller node") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Manivannan Sadhasivam <mani@kernel.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230420072811.36947-1-krzysztof.kozlowski@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19ARM: dts: qcom: msm8660: Fix regulator node namesLinus Walleij1-2/+2
commit a0f19091d4f5bbe97485592257b88007eb5b1998 upstream. commit 04715461abf7 altered the node names in a DTSI file used by qcom-apq8060-dragonboard.dts breaking the board. Align the node names in the DTS file and the board boots again. Cc: stable@vger.kernel.org Fixes: 85055a1eecc1 ("ARM: dts: qcom-msm8660: align RPM regulators node name with bindings") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230414135747.34994-1-linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19um: Use HOST_DIR for mrproperKees Cook1-1/+1
commit a5a319ec2c2236bb96d147c16196d2f1f3799301 upstream. When HEADER_ARCH was introduced, the MRPROPER_FILES (then MRPROPER_DIRS) list wasn't adjusted, leaving SUBARCH as part of the path argument. This resulted in the "mrproper" target not cleaning up arch/x86/... when SUBARCH was specified. Since HOST_DIR is arch/$(HEADER_ARCH), use it instead to get the correct path. Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Azeem Shaikh <azeemshaikh38@gmail.com> Cc: linux-um@lists.infradead.org Fixes: 7bbe7204e937 ("um: merge Makefile-{i386,x86_64}") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230606222442.never.807-kees@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19arm64/signal: Restore TPIDR2 register rather than memory stateMark Brown1-1/+1
commit 616cb2f4b141852cac3dfffe8354c8bf19e9999d upstream. Currently when restoring the TPIDR2 signal context we set the new value from the signal frame in the thread data structure but not the register, following the pattern for the rest of the data we are restoring. This does not work in the case of TPIDR2, the register always has the value for the current task. This means that either we return to userspace and ignore the new value or we context switch and save the register value on top of the newly restored value. Load the value from the signal context into the register instead. Fixes: 39e54499280f ("arm64/signal: Include TPIDR2 in the signal context") Signed-off-by: Mark Brown <broonie@kernel.org> Cc: <stable@vger.kernel.org> # 6.3.x Link: https://lore.kernel.org/r/20230621-arm64-fix-tpidr2-signal-restore-v2-1-c8e8fcc10302@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-19sh: dma: Fix DMA channel offset calculationArtur Rojek1-13/+24
[ Upstream commit e82e47584847129a20b8c9f4a1dcde09374fb0e0 ] Various SoCs of the SH3, SH4 and SH4A family, which use this driver, feature a differing number of DMA channels, which can be distributed between up to two DMAC modules. The existing implementation fails to correctly accommodate for all those variations, resulting in wrong channel offset calculations and leading to kernel panics. Rewrite dma_base_addr() in order to properly calculate channel offsets in a DMAC module. Fix dmaor_read_reg() and dmaor_write_reg(), so that the correct DMAC module base is selected for the DMAOR register. Fixes: 7f47c7189b3e8f19 ("sh: dma: More legacy cpu dma chainsawing.") Signed-off-by: Artur Rojek <contact@artur-rojek.eu> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230527164452.64797-2-contact@artur-rojek.eu Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19risc-v: Fix order of IPI enablement vs RCU startupMarc Zyngier1-2/+3
[ Upstream commit 6259f3443c6a376aa077816ac92e9ddeb0817d09 ] Conor reports that risc-v tries to enable IPIs before telling the core code to enable RCU. With the introduction of the mapple tree as a backing store for the irq descriptors, this results in a very shouty boot sequence, as RCU is legitimately upset. Restore some sanity by moving the risc_ipi_enable() call after notify_cpu_starting(), which explicitly enables RCU on the calling CPU. Fixes: 832f15f42646 ("RISC-V: Treat IPIs as normal Linux IRQs") Reported-by: Conor Dooley <conor@kernel.org> Signed-off-by: Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/r/20230703-dupe-frying-79ae2ccf94eb@spud Cc: Anup Patel <apatel@ventanamicro.com> Cc: Palmer Dabbelt <palmer@rivosinc.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Tested-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230703183126.1567625-1-maz@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19riscv: move memblock_allow_resize() after linear mapping is readyWoody Zhang1-1/+3
[ Upstream commit 85fadc0d04119c2fe4a20287767ab904c6d21ba1 ] The initial memblock metadata is accessed from kernel image mapping. The regions arrays need to "reallocated" from memblock and accessed through linear mapping to cover more memblock regions. So the resizing should not be allowed until linear mapping is ready. Note that there are memblock allocations when building linear mapping. This patch is similar to 24cc61d8cb5a ("arm64: memblock: don't permit memblock resizing until linear mapping is up"). In following log, many memblock regions are reserved before create_linear_mapping_page_table(). And then it triggered reallocation of memblock.reserved.regions and memcpy the old array in kernel image mapping to the new array in linear mapping which caused a page fault. [ 0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6 [ 0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000 [ 0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae [ 0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c [ 0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128 [ 0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff] [ 0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000 [ 0.000000] Oops [#1] [ 0.000000] Modules linked in: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66 [ 0.000000] Hardware name: riscv-virtio,qemu (DT) [ 0.000000] epc : __memcpy+0x60/0xf8 [ 0.000000] ra : memblock_double_array+0x192/0x248 [ 0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0 [ 0.000000] gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000 [ 0.000000] t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60 [ 0.000000] s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8 [ 0.000000] a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000 [ 0.000000] a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000 [ 0.000000] s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00 [ 0.000000] s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000 [ 0.000000] s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000 [ 0.000000] s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000 [ 0.000000] t5 : 000000008f003000 t6 : ff600000ffffd000 [ 0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f [ 0.000000] [<ffffffff8081d214>] __memcpy+0x60/0xf8 [ 0.000000] [<ffffffff80a3e1a2>] memblock_add_range.isra.14+0x12c/0x162 [ 0.000000] [<ffffffff80a3e36a>] memblock_reserve+0x6e/0x8c [ 0.000000] [<ffffffff80a123fc>] memblock_alloc_range_nid+0xb8/0x128 [ 0.000000] [<ffffffff80a1256a>] memblock_phys_alloc_range+0x5e/0x6a [ 0.000000] [<ffffffff80a04732>] alloc_pmd_fixmap+0x14/0x1c [ 0.000000] [<ffffffff80a0475a>] alloc_p4d_fixmap+0xc/0x14 [ 0.000000] [<ffffffff80a04a36>] create_pgd_mapping+0x98/0x17c [ 0.000000] [<ffffffff80a04e9e>] create_linear_mapping_range.constprop.10+0xe4/0x112 [ 0.000000] [<ffffffff80a05bb8>] paging_init+0x3ec/0x5ae [ 0.000000] [<ffffffff80a03354>] setup_arch+0xb2/0x576 [ 0.000000] [<ffffffff80a00726>] start_kernel+0x72/0x57e [ 0.000000] Code: b303 0285 b383 0305 be03 0385 be83 0405 bf03 0485 (b023) 00ef [ 0.000000] ---[ end trace 0000000000000000 ]--- [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task! [ 0.000000] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]--- Fixes: 671f9a3e2e24 ("RISC-V: Setup initial page tables in two stages") Signed-off-by: Woody Zhang <woodylab@foxmail.com> Tested-by: Song Shuai <songshuaishuai@tinylab.org> Link: https://lore.kernel.org/r/tencent_FBB94CE615C5CCE7701CD39C15CCE0EE9706@qq.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc: dts: turris1x.dts: Fix PCIe MEM size for pci2 nodePali Rohár1-3/+3
[ Upstream commit abaa02fc944f2f9f2c2e1925ddaceaf35c48528c ] Freescale PCIe controllers on their PCIe Root Ports do not have any mappable PCI BAR allocate from PCIe MEM. Information about 1MB window on BAR0 of PCIe Root Port was misleading because Freescale PCIe controllers have at BAR0 position different register PEXCSRBAR, and kernel correctly skipts BAR0 for these Freescale PCIe Root Ports. So update comment about P2020 PCIe Root Port and decrease PCIe MEM size required for PCIe controller (pci2 node) on which is on-board xHCI controller. lspci confirms that on P2020 PCIe Root Port is no PCI BAR and /proc/iomem sees that only c0000000-c000ffff and c0010000-c0011fff ranges are used. Fixes: 54c15ec3b738 ("powerpc: dts: Add DTS file for CZ.NIC Turris 1.x routers") Signed-off-by: Pali Rohár <pali@kernel.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230505172818.18416-1-pali@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc: allow PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=yRandy Dunlap1-1/+1
[ Upstream commit 39f49684036d24af800ff194c33c7b2653c591d7 ] In a randconfig with CONFIG_SERIAL_CPM=m and CONFIG_PPC_EARLY_DEBUG_CPM=y, there is a build error: ERROR: modpost: "udbg_putc" [drivers/tty/serial/cpm_uart/cpm_uart.ko] undefined! Prevent the build error by allowing PPC_EARLY_DEBUG_CPM only when SERIAL_CPM=y. Fixes: c374e00e17f1 ("[POWERPC] Add early debug console for CPM serial ports.") Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Pali Rohár <pali@kernel.org> Reviewed-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230701054714.30512-1-rdunlap@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19KVM: s390/diag: fix racy access of physical cpu number in diag 9c handlerChristian Borntraeger1-3/+5
[ Upstream commit 0bc380beb78aa352eadbc21d934dd9606fcee808 ] We do check for target CPU == -1, but this might change at the time we are going to use it. Hold the physical target CPU in a local variable to avoid out-of-bound accesses to the cpu arrays. Cc: Pierre Morel <pmorel@linux.ibm.com> Fixes: 87e28a15c42c ("KVM: s390: diag9c (directed yield) forwarding") Reported-by: Marc Hartmayer <mhartmay@linux.ibm.com> Reviewed-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Pierre Morel <pmorel@linux.ibm.com> Signed-off-by: Christian Borntraeger <borntraeger@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19KVM: s390: vsie: fix the length of APCB bitmapPierre Morel1-2/+4
[ Upstream commit 246be7d2720ea9a795b576067ecc5e5c7a1e7848 ] bit_and() uses the count of bits as the woking length. Fix the previous implementation and effectively use the right bitmap size. Fixes: 19fd83a64718 ("KVM: s390: vsie: allow CRYCB FORMAT-1") Fixes: 56019f9aca22 ("KVM: s390: vsie: Allow CRYCB FORMAT-2") Signed-off-by: Pierre Morel <pmorel@linux.ibm.com> Reviewed-by: Janosch Frank <frankja@linux.ibm.com> Link: https://lore.kernel.org/kvm/20230511094719.9691-1-pmorel@linux.ibm.com/ Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19KVM: s390: fix KVM_S390_GET_CMMA_BITS for GFNs in memslot holesNico Boehr1-0/+4
[ Upstream commit 285cff4c0454340a4dc53f46e67f2cb1c293bd74 ] The KVM_S390_GET_CMMA_BITS ioctl may return incorrect values when userspace specifies a start_gfn outside of memslots. This can occur when a VM has multiple memslots with a hole in between: +-----+----------+--------+--------+ | ... | Slot N-1 | <hole> | Slot N | +-----+----------+--------+--------+ ^ ^ ^ ^ | | | | GFN A A+B | | A+B+C | A+B+C+D When userspace specifies a GFN in [A+B, A+B+C), it would expect to get the CMMA values of the first dirty page in Slot N. However, userspace may get a start_gfn of A+B+C+D with a count of 0, hence completely skipping over any dirty pages in slot N. The error is in kvm_s390_next_dirty_cmma(), which assumes gfn_to_memslot_approx() will return the memslot _below_ the specified GFN when the specified GFN lies outside a memslot. In reality it may return either the memslot below or above the specified GFN. When a memslot above the specified GFN is returned this happens: - ofs is calculated, but since the memslot's base_gfn is larger than the specified cur_gfn, ofs will underflow to a huge number. - ofs is passed to find_next_bit(). Since ofs will exceed the memslot's number of pages, the number of pages in the memslot is returned, completely skipping over all bits in the memslot userspace would be interested in. Fix this by resetting ofs to zero when a memslot _above_ cur_gfn is returned (cur_gfn < ms->base_gfn). Signed-off-by: Nico Boehr <nrb@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots") Message-Id: <20230324145424.293889-2-nrb@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Signed-off-by: Janosch Frank <frankja@linux.ibm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19sh: Avoid using IRQ0 on SH3 and SH4Sergey Shtylyov5-6/+6
[ Upstream commit a8ac2961148e8c720dc760f2e06627cd5c55a154 ] IRQ0 is no longer returned by platform_get_irq() and its ilk -- they now return -EINVAL instead. However, the kernel code supporting SH3/4-based SoCs still maps the IRQ #s starting at 0 -- modify that code to start the IRQ #s from 16 instead. The patch should mostly affect the AP-SH4A-3A/AP-SH4AD-0A boards as they indeed are using IRQ0 for the SMSC911x compatible Ethernet chip. Fixes: ce753ad1549c ("platform: finally disallow IRQ0 in platform_get_irq() and its ilk") Signed-off-by: Sergey Shtylyov <s.shtylyov@omp.ru> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/71105dbf-cdb0-72e1-f9eb-eeda8e321696@omp.ru Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19sh: j2: Use ioremap() to translate device tree address into kernel memoryJohn Paul Adrian Glaubitz1-1/+1
[ Upstream commit bc9d1f0cecd2407cfb2364a7d4be2f52d1d46a9d ] Addresses the following warning when building j2_defconfig: arch/sh/kernel/cpu/sh2/probe.c: In function 'scan_cache': arch/sh/kernel/cpu/sh2/probe.c:24:16: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] 24 | j2_ccr_base = (u32 __iomem *)of_flat_dt_translate_address(node); | Fixes: 5a846abad07f ("sh: add support for J-Core J2 processor") Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Tested-by: Rob Landley <rob@landley.net> Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Link: https://lore.kernel.org/r/20230503125746.331835-1-glaubitz@physik.fu-berlin.de Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19x86/efi: Make efi_set_virtual_address_map IBT safeThomas Gleixner1-3/+3
[ Upstream commit 0303c9729afc4094ef53e552b7b8cff7436028d6 ] Niklāvs reported a boot regression on an Alderlake machine and bisected it to commit 9df9d2f0471b ("init: Invoke arch_cpu_finalize_init() earlier"). By moving the invocation of arch_cpu_finalize_init() further down he identified that efi_enter_virtual_mode() is the function which causes the boot hang. The main difference of the earlier invocation is that the boot CPU is already fully initialized and mitigations and alternatives are applied. But the only really interesting change turned out to be IBT, which is now enabled before efi_enter_virtual_mode(). "ibt=off" on the kernel command line cured the problem. Inspection of the involved calls in efi_enter_virtual_mode() unearthed that efi_set_virtual_address_map() is the only place in the kernel which invokes an EFI call without the IBT safe wrapper. This went obviously unnoticed so far as IBT was enabled later. Use arch_efi_call_virt() instead of efi_call() to cure that. Fixes: fe379fa4d199 ("x86/ibt: Disable IBT around firmware") Fixes: 9df9d2f0471b ("init: Invoke arch_cpu_finalize_init() earlier") Reported-by: Niklāvs Koļesņikovs <pinkflames.linux@gmail.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Ard Biesheuvel <ardb@kernel.org> Link: https://bugzilla.kernel.org/show_bug.cgi?id=217602 Link: https://lore.kernel.org/r/87jzvm12q0.ffs@tglx Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: sme: Use STR P to clear FFR context field in streaming SVE modeWill Deacon1-3/+3
[ Upstream commit 893b24181b4c4bf1fa2841b1ed192e5413a97cb1 ] The FFR is a predicate register which can vary between 16 and 256 bits in size depending upon the configured vector length. When saving the SVE state in streaming SVE mode, the FFR register is inaccessible and so commit 9f5848665788 ("arm64/sve: Make access to FFR optional") simply clears the FFR field of the in-memory context structure. Unfortunately, it achieves this using an unconditional 8-byte store and so if the SME vector length is anything other than 64 bytes in size we will either fail to clear the entire field or, worse, we will corrupt memory immediately following the structure. This has led to intermittent kfence splats in CI [1] and can trigger kmalloc Redzone corruption messages when running the 'fp-stress' kselftest: | ============================================================================= | BUG kmalloc-1k (Not tainted): kmalloc Redzone overwritten | ----------------------------------------------------------------------------- | | 0xffff000809bf1e22-0xffff000809bf1e27 @offset=7714. First byte 0x0 instead of 0xcc | Allocated in do_sme_acc+0x9c/0x220 age=2613 cpu=1 pid=531 | __kmalloc+0x8c/0xcc | do_sme_acc+0x9c/0x220 | ... Replace the 8-byte store with a store of a predicate register which has been zero-initialised with PFALSE, ensuring that the entire field is cleared in memory. [1] https://lore.kernel.org/r/CA+G9fYtU7HsV0R0dp4XEH5xXHSJFw8KyDf5VQrLLfMxWfxQkag@mail.gmail.com Cc: Mark Brown <broonie@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Naresh Kamboju <naresh.kamboju@linaro.org> Fixes: 9f5848665788 ("arm64/sve: Make access to FFR optional") Reported-by: Linux Kernel Functional Testing <lkft@linaro.org> Signed-off-by: Will Deacon <will@kernel.org> Reviewed-by: Mark Brown <broonie@kernel.org> Tested-by: Anders Roxell <anders.roxell@linaro.org> Link: https://lore.kernel.org/r/20230628155605.22296-1-will@kernel.org Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19ARC: define ASM_NL and __ALIGN(_STR) outside #ifdef __ASSEMBLY__ guardMasahiro Yamada1-4/+4
[ Upstream commit 92e2921eeafdfca9acd9b83f07d2b7ca099bac24 ] ASM_NL is useful not only in *.S files but also in .c files for using inline assembler in C code. On ARC, however, ASM_NL is evaluated inconsistently. It is expanded to a backquote (`) in *.S files, but a semicolon (;) in *.c files because arch/arc/include/asm/linkage.h defines it inside #ifdef __ASSEMBLY__, so the definition for C code falls back to the default value defined in include/linux/linkage.h. If ASM_NL is used in inline assembler in .c files, it will result in wrong assembly code because a semicolon is not an instruction separator, but the start of a comment for ARC. Move ASM_NL (also __ALIGN and __ALIGN_STR) out of the #ifdef. Fixes: 9df62f054406 ("arch: use ASM_NL instead of ';' for assembler new line character in the macro") Fixes: 8d92e992a785 ("ARC: define __ALIGN_STR and __ALIGN symbols for ARC") Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19riscv: hibernate: remove WARN_ON in save_processor_stateSong Shuai1-1/+0
[ Upstream commit 91afbaafd6b1f1846520efd2b158066a25a1a316 ] During hibernation or restoration, freeze_secondary_cpus checks num_online_cpus via BUG_ON, and the subsequent save_processor_state also does the checking with WARN_ON. In the case of CONFIG_PM_SLEEP_SMP=n, freeze_secondary_cpus is not defined, but the sole possible condition to disable CONFIG_PM_SLEEP_SMP is !SMP where num_online_cpus is always 1. We also don't have to check it in save_processor_state. So remove the unnecessary checking in save_processor_state. Fixes: c0317210012e ("RISC-V: Add arch functions to support hibernation/suspend-to-disk") Signed-off-by: Song Shuai <songshuaishuai@tinylab.org> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230609075049.2651723-4-songshuaishuai@tinylab.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc/mm/dax: Fix the condition when checking if altmap vmemap can ↵Aneesh Kumar K.V1-1/+1
cross-boundary [ Upstream commit c8eebc4a99f15280654f23e914e746c40a516e50 ] Without this fix, the last subsection vmemmap can end up in memory even if the namespace is created with -M mem and has sufficient space in the altmap area. Fixes: cf387d9644d8 ("libnvdimm/altmap: Track namespace boundaries in altmap") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com <mailto:sachinp@linux.ibm.com>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230616110826.344417-6-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc/book3s64/mm: Fix DirectMap stats in /proc/meminfoAneesh Kumar K.V1-12/+22
[ Upstream commit 0da90af431abc3f497a38ec9ef6e43b0d0dabe80 ] On memory unplug reduce DirectMap page count correctly. root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M: 115343360 kB DirectMap1G: 0 kB Before fix: root@ubuntu-guest:# ndctl disable-namespace all disabled 1 namespace root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M: 115343360 kB DirectMap1G: 0 kB After fix: root@ubuntu-guest:# ndctl disable-namespace all disabled 1 namespace root@ubuntu-guest:# grep Direct /proc/meminfo DirectMap4k: 0 kB DirectMap64k: 0 kB DirectMap2M: 104857600 kB DirectMap1G: 0 kB Fixes: a2dc009afa9a ("powerpc/mm/book3s/radix: Add mapping statistics") Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com <mailto:sachinp@linux.ibm.com>> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230616110826.344417-4-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19riscv: uprobes: Restore thread.bad_causeTiezhu Yang1-0/+2
[ Upstream commit 58b1294dd1d65bb62f08dddbf418f954210c2057 ] thread.bad_cause is saved in arch_uprobe_pre_xol(), it should be restored in arch_uprobe_{post,abort}_xol() accordingly, otherwise the save operation is meaningless, this change is similar with x86 and powerpc. Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Acked-by: Oleg Nesterov <oleg@redhat.com> Reviewed-by: Guo Ren <guoren@kernel.org> Fixes: 74784081aac8 ("riscv: Add uprobes supported") Link: https://lore.kernel.org/r/1682214146-3756-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19riscv: hibernation: Remove duplicate call of suspend_restore_csrsSong Shuai1-1/+0
[ Upstream commit c6399b893043a5bb634de8677362f96684f1c0c8 ] The suspend_restore_csrs is called in both __hibernate_cpu_resume and the `else` of subsequent swsusp_arch_suspend. Removing the first call makes both suspend_{save,restore}_csrs left in swsusp_arch_suspend for clean code. Fixes: c0317210012e ("RISC-V: Add arch functions to support hibernation/suspend-to-disk") Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: JeeHeng Sia <jeeheng.sia@starfivetech.com> Signed-off-by: Song Shuai <songshuaishuai@tinylab.org> Link: https://lore.kernel.org/r/20230522025020.285042-1-songshuaishuai@tinylab.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc: update ppc_save_regs to save current r1 in pt_regsAditya Gupta1-3/+3
[ Upstream commit b684c09f09e7a6af3794d4233ef785819e72db79 ] ppc_save_regs() skips one stack frame while saving the CPU register states. Instead of saving current R1, it pulls the previous stack frame pointer. When vmcores caused by direct panic call (such as `echo c > /proc/sysrq-trigger`), are debugged with gdb, gdb fails to show the backtrace correctly. On further analysis, it was found that it was because of mismatch between r1 and NIP. GDB uses NIP to get current function symbol and uses corresponding debug info of that function to unwind previous frames, but due to the mismatching r1 and NIP, the unwinding does not work, and it fails to unwind to the 2nd frame and hence does not show the backtrace. GDB backtrace with vmcore of kernel without this patch: --------- (gdb) bt #0 0xc0000000002a53e8 in crash_setup_regs (oldregs=<optimized out>, newregs=0xc000000004f8f8d8) at ./arch/powerpc/include/asm/kexec.h:69 #1 __crash_kexec (regs=<optimized out>) at kernel/kexec_core.c:974 #2 0x0000000000000063 in ?? () #3 0xc000000003579320 in ?? () --------- Further analysis revealed that the mismatch occurred because "ppc_save_regs" was saving the previous stack's SP instead of the current r1. This patch fixes this by storing current r1 in the saved pt_regs. GDB backtrace with vmcore of patched kernel: -------- (gdb) bt #0 0xc0000000002a53e8 in crash_setup_regs (oldregs=0x0, newregs=0xc00000000670b8d8) at ./arch/powerpc/include/asm/kexec.h:69 #1 __crash_kexec (regs=regs@entry=0x0) at kernel/kexec_core.c:974 #2 0xc000000000168918 in panic (fmt=fmt@entry=0xc000000001654a60 "sysrq triggered crash\n") at kernel/panic.c:358 #3 0xc000000000b735f8 in sysrq_handle_crash (key=<optimized out>) at drivers/tty/sysrq.c:155 #4 0xc000000000b742cc in __handle_sysrq (key=key@entry=99, check_mask=check_mask@entry=false) at drivers/tty/sysrq.c:602 #5 0xc000000000b7506c in write_sysrq_trigger (file=<optimized out>, buf=<optimized out>, count=2, ppos=<optimized out>) at drivers/tty/sysrq.c:1163 #6 0xc00000000069a7bc in pde_write (ppos=<optimized out>, count=<optimized out>, buf=<optimized out>, file=<optimized out>, pde=0xc00000000362cb40) at fs/proc/inode.c:340 #7 proc_reg_write (file=<optimized out>, buf=<optimized out>, count=<optimized out>, ppos=<optimized out>) at fs/proc/inode.c:352 #8 0xc0000000005b3bbc in vfs_write (file=file@entry=0xc000000006aa6b00, buf=buf@entry=0x61f498b4f60 <error: Cannot access memory at address 0x61f498b4f60>, count=count@entry=2, pos=pos@entry=0xc00000000670bda0) at fs/read_write.c:582 #9 0xc0000000005b4264 in ksys_write (fd=<optimized out>, buf=0x61f498b4f60 <error: Cannot access memory at address 0x61f498b4f60>, count=2) at fs/read_write.c:637 #10 0xc00000000002ea2c in system_call_exception (regs=0xc00000000670be80, r0=<optimized out>) at arch/powerpc/kernel/syscall.c:171 #11 0xc00000000000c270 in system_call_vectored_common () at arch/powerpc/kernel/interrupt_64.S:192 -------- Nick adds: So this now saves regs as though it was an interrupt taken in the caller, at the instruction after the call to ppc_save_regs, whereas previously the NIP was there, but R1 came from the caller's caller and that mismatch is what causes gdb's dwarf unwinder to go haywire. Signed-off-by: Aditya Gupta <adityag@linux.ibm.com> Fixes: d16a58f8854b1 ("powerpc: Improve ppc_save_regs()") Reivewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230615091047.90433-1-adityag@linux.ibm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc/powernv/sriov: perform null check on iov before dereferencing iovColin Ian King1-3/+3
[ Upstream commit f4f913c980bc6abe0ccfe88fe3909c125afe4a2d ] Currently pointer iov is being dereferenced before the null check of iov which can lead to null pointer dereference errors. Fix this by moving the iov null check before the dereferencing. Detected using cppcheck static analysis: linux/arch/powerpc/platforms/powernv/pci-sriov.c:597:12: warning: Either the condition '!iov' is redundant or there is possible null pointer dereference: iov. [nullPointerRedundantCheck] num_vfs = iov->num_vfs; ^ Fixes: 052da31d45fc ("powerpc/powernv/sriov: De-indent setup and teardown") Signed-off-by: Colin Ian King <colin.i.king@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230608095849.1147969-1-colin.i.king@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc/64s: Fix VAS mm use after freeNicholas Piggin2-2/+2
[ Upstream commit b4bda59b47879cce38a6ec5a01cd3cac702b5331 ] The refcount on mm is dropped before the coprocessor is detached. Reported-by: Sachin Sant <sachinp@linux.ibm.com> Fixes: 7bc6f71bdff5f ("powerpc/vas: Define and use common vas_window struct") Fixes: b22f2d88e435c ("powerpc/pseries/vas: Integrate API with open/close windows") Signed-off-by: Nicholas Piggin <npiggin@gmail.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/20230607101024.14559-1-npiggin@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc/signal32: Force inlining of __unsafe_save_user_regs() and ↵Christophe Leroy1-6/+9
save_tm_user_regs_unsafe() [ Upstream commit a03b1a0b19398a47489fdcef02ec19c2ba05a15d ] Looking at generated code for handle_signal32() shows calls to a function called __unsafe_save_user_regs.constprop.0 while user access is open. And that __unsafe_save_user_regs.constprop.0 function has two nops at the begining, allowing it to be traced, which is unexpected during user access open window. The solution could be to mark __unsafe_save_user_regs() no trace, but to be on the safe side the most efficient is to flag it __always_inline as already done for function __unsafe_restore_general_regs(). The function is relatively small and only called twice, so the size increase will remain in the noise. Do the same with save_tm_user_regs_unsafe() as it may suffer the same issue. Fixes: ef75e7318294 ("powerpc/signal32: Transform save_user_regs() and save_tm_user_regs() in 'unsafe' version") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/7e469c8f01860a69c1ada3ca6a5e2aa65f0f74b2.1685955220.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19powerpc/interrupt: Don't read MSR from interrupt_exit_kernel_prepare()Christophe Leroy1-2/+1
[ Upstream commit 0eb089a72fda3f7969e6277804bde75dc1474a14 ] A disassembly of interrupt_exit_kernel_prepare() shows a useless read of MSR register. This is shown by r9 being re-used immediately without doing anything with the value read. c000e0e0: 60 00 00 00 nop c000e0e4: 7d 3a c2 a6 mfmd_ap r9 c000e0e8: 7d 20 00 a6 mfmsr r9 c000e0ec: 7c 51 13 a6 mtspr 81,r2 c000e0f0: 81 3f 00 84 lwz r9,132(r31) c000e0f4: 71 29 80 00 andi. r9,r9,32768 This is due to the use of local_irq_save(). The flags read by local_irq_save() are never used, use local_irq_disable() instead. Fixes: 13799748b957 ("powerpc/64: use interrupt restart table to speed up return from interrupt") Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu> Reviewed-by: Nicholas Piggin <npiggin@gmail.com> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/df36c6205ab64326fb1b991993c82057e92ace2f.1685955214.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19ARM: dts: lan966x: kontron-d10: fix SPI CSMichael Walle1-1/+7
[ Upstream commit fcb79ee3f0b15ed15f35eca5f24e952fdced9c61 ] The pinctrl node was missing which change the pin mux to GPIO mode. Add it so we don't have to rely on the bootloader to set the correct mode. Fixes: 79d83b3a458e ("ARM: dts: lan966x: add basic Kontron KSwitch D10 support") Signed-off-by: Michael Walle <mwalle@kernel.org> Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230616-feature-d10-dt-cleanups-v1-2-50dd0452b8fe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19ARM: dts: lan966x: kontron-d10: fix board resetMichael Walle1-0/+8
[ Upstream commit bfcd5714f6424c03e385e0e9296dcd69855cfea7 ] The pinctrl node was missing which change the pin mux to GPIO mode. Add it. Fixes: 79d83b3a458e ("ARM: dts: lan966x: add basic Kontron KSwitch D10 support") Signed-off-by: Michael Walle <mwalle@kernel.org> [claudiu.beznea: moved pinctrl-* bindings after compatible] Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com> Link: https://lore.kernel.org/r/20230616-feature-d10-dt-cleanups-v1-1-50dd0452b8fe@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: mt7986: increase bl2 partition on NAND of Bananapi R3Daniel Golle1-3/+3
[ Upstream commit 3bfbff9b461e3506dfb5b2904e8c15a0aea39e07 ] The bootrom burned into the MT7986 SoC will try multiple locations on the SPI-NAND flash to load bl2 in case the bl2 image located at the the previously attempted offset is corrupt. Use 0x100000 instead of 0x80000 as partition size for bl2 on SPI-NAND, allowing for up to four redundant copies of bl2 (typically sized a bit less than 0x40000). Fixes: 8e01fb15b8157 ("arm64: dts: mt7986: add Bananapi R3") Signed-off-by: Daniel Golle <daniel@makrotopia.org> Link: https://lore.kernel.org/r/ZH9UGF99RgzrHZ88@makrotopia.org Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: mediatek: mt8192: Fix CPUs capacity-dmips-mhzNícolas F. R. A. Prado1-4/+4
[ Upstream commit a4366b5695c984b8a3fc8b31de9e758c8f6d1aed ] The capacity-dmips-mhz parameter was miscalculated: this SoC runs the first (Cortex-A55) cluster at a maximum of 2000MHz and the second (Cortex-A76) cluster at a maximum of 2200MHz. In order to calculate the right capacity-dmips-mhz, the following test was performed: 1. CPUFREQ governor was set to 'performance' on both clusters 2. Ran dhrystone with 500000000 iterations for 10 times on each cluster 3. Calculated the mean result for each cluster 4. Calculated DMIPS/MHz: dmips_mhz = dmips_per_second / cpu_mhz 5. Scaled results to 1024: result_c0 = dmips_mhz_c0 / dmips_mhz_c1 * 1024 The mean results for this SoC are: Cluster 0 (LITTLE): 12016411 Dhry/s Cluster 1 (BIG): 31702034 Dhry/s The calculated scaled results are: Cluster 0: 426.953226899238 (rounded to 427) Cluster 1: 1024 Fixes: 48489980e27e ("arm64: dts: Add Mediatek SoC MT8192 and evaluation board dts and Makefile") Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230602183515.3778780-1-nfraprado@collabora.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: mediatek: Add cpufreq nodes for MT8192Allen-KH Cheng1-0/+14
[ Upstream commit 9d498cce9298a71e3896e2d1aee24a1a4c531d81 ] Add the cpufreq nodes for MT8192 SoC. Signed-off-by: Allen-KH Cheng <allen-kh.cheng@mediatek.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Tested-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://lore.kernel.org/r/20230317061944.15434-1-allen-kh.cheng@mediatek.com Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com> Stable-dep-of: a4366b5695c9 ("arm64: dts: mediatek: mt8192: Fix CPUs capacity-dmips-mhz") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: ti: k3-am69-sk: Fix main_i2c0 aliasNishanth Menon1-1/+1
[ Upstream commit b38c6ced4ec5b3f6260ff6cc2b71e8a3d8c897d7 ] main_i2c0 is aliased as i2c0 which creates a problem for u-boot R5 SPL attempting to reuse the same definition in the common board detection logic as it looks for the first i2c instance as the bus on which to detect the eeprom to understand the board variant involved. Switch main_i2c0 to i2c3 alias allowing us to introduce wkup_i2c0 and potentially space for mcu_i2c instances in the gap for follow on patches. Fixes: 635fb18ba008 ("arch: arm64: dts: Add support for AM69 Starter Kit") Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20230602214937.2349545-5-nm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: ti: k3-j784s4: Fix wakeup pinmux range and pinctrl node offsetsThejasvi Konduru2-16/+43
[ Upstream commit 14462bd0b247d05070d48d0f02eb7ca2680ab7bd ] The wkup_pmx register region in j784s4 has multiple non-addressable regions, hence the existing wkup_pmx region is split as follows to avoid the non-addressable regions. The pinctrl node offsets are also corrected as per the newly split wkup_pmx* nodes. wkup_pmx0 -> 13 pins (WKUP_PADCONFIG 0 - 12) wkup_pmx1 -> 11 pins (WKUP_PADCONFIG 14 - 24) wkup_pmx2 -> 72 pins (WKUP_PADCONFIG 26 - 97) wkup_pmx3 -> 1 pin (WKUP_PADCONFIG 100) Fixes: 4664ebd8346a ("arm64: dts: ti: Add initial support for J784S4 SoC") Signed-off-by: Thejasvi Konduru <t-konduru@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20230503083143.32369-1-t-konduru@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: ti: k3-j784s4-evm: Fix main_i2c0 aliasNishanth Menon1-1/+1
[ Upstream commit c10a9df30e3401bd5a5ee43f1afd6c2b2ca75ad7 ] main_i2c0 is aliased as i2c0 which creates a problem for u-boot R5 SPL attempting to reuse the same definition in the common board detection logic as it looks for the first i2c instance as the bus on which to detect the eeprom to understand the board variant involved. Switch main_i2c0 to i2c3 alias allowing us to introduce wkup_i2c0 and potentially space for mcu_i2c instances in the gap for follow on patches. Fixes: e20a06aca5c9 ("arm64: dts: ti: Add support for J784S4 EVM board") Signed-off-by: Nishanth Menon <nm@ti.com> Reviewed-by: Udit Kumar <u-kumar1@ti.com> Link: https://lore.kernel.org/r/20230602214937.2349545-2-nm@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: ti: k3-j721e-beagleboneai64: Fix mailbox node statusAndrew Davis1-0/+5
[ Upstream commit 155e7635ed1f3814d94d12556a3a0fed41d05b76 ] Mailbox nodes are now disabled by default. The BeagleBoard AI64 DT addition went in at around the same time and must have missed that change so the mailboxes are not re-enabled. Do that here. Fixes: fae14a1cb8dd ("arm64: dts: ti: Add k3-j721e-beagleboneai64") Signed-off-by: Andrew Davis <afd@ti.com> Reviewed-by: Nishanth Menon <nm@ti.com> Link: https://lore.kernel.org/r/20230515172137.474626-1-afd@ti.com Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: qcom: sm8550: Add missing interconnect path to USB HCAbel Vesa1-0/+4
[ Upstream commit 11a1397bbf69e408223bb691858a0fcd295a8f76 ] The USB HC node is missing the interconnect paths, so add them. Fixes: 7f7e5c1b037f ("arm64: dts: qcom: sm8550: Add USB PHYs and controller nodes") Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230601103817.4066446-1-abel.vesa@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: qcom: sm8250-edo: Panel framebuffer is 2.5k instead of 4kMarijn Suijten1-3/+4
[ Upstream commit 223ce29c8b7e5b00f01a68387aabeefd77d97f06 ] The framebuffer configuration for edo pdx203, written in edo dtsi (which is overwritten in pdx206 dts for its smaller panel) has to use a 1096x2560 configuration as this is what the panel (and framebuffer area) has been initialized to. Downstream userspace also has access to (and uses) this 2.5k mode by default, and only switches the panel to 4k when requested. This is similar to commit be8de06dc397 ("arm64: dts: qcom: sm8150-kumano: Panel framebuffer is 2.5k instead of 4k") which fixed the same for the previous generation Sony platform. Fixes: 69cdb97ef652 ("arm64: dts: qcom: sm8250: Add support for SONY Xperia 1 II / 5 II (Edo platform)") Signed-off-by: Marijn Suijten <marijn.suijten@somainline.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230606211418.587676-1-marijn.suijten@somainline.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: qcom: sm8550: Flush RSC sleep & wake votesKonrad Dybcio1-0/+1
[ Upstream commit 4b2c7ac8e469ab7f92e50c34ad4012a77e79d078 ] The rpmh driver will cache sleep and wake votes until the cluster power-domain is about to enter idle, to avoid unnecessary writes. So associate the apps_rsc with the cluster pd, so that it can be notified about this event. Without this, only AMC votes are being commited. Fixes: ffc50b2d3828 ("arm64: dts: qcom: Add base SM8550 dtsi") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531-topic-rsc-v1-8-b4a985f57b8b@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: qcom: sdm845: Flush RSC sleep & wake votesKonrad Dybcio1-0/+1
[ Upstream commit 91e83140b5dd5598fbcfada3ee1f8b2b410c3731 ] The rpmh driver will cache sleep and wake votes until the cluster power-domain is about to enter idle, to avoid unnecessary writes. So associate the apps_rsc with the cluster pd, so that it can be notified about this event. Without this, only AMC votes are being commited. Fixes: c83545d95376 ("arm64: dts: sdm845: Add rpmh-rsc node") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531-topic-rsc-v1-6-b4a985f57b8b@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: qcom: sdm670: Flush RSC sleep & wake votesKonrad Dybcio1-0/+1
[ Upstream commit 7b04cbd81b0e60c5151a310e7b730dc4a951a211 ] The rpmh driver will cache sleep and wake votes until the cluster power-domain is about to enter idle, to avoid unnecessary writes. So associate the apps_rsc with the cluster pd, so that it can be notified about this event. Without this, only AMC votes are being commited. Fixes: 07c8ded6e373 ("arm64: dts: qcom: add sdm670 and pixel 3a device trees") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531-topic-rsc-v1-5-b4a985f57b8b@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19arm64: dts: qcom: qdu1000: Flush RSC sleep & wake votesKonrad Dybcio1-0/+1
[ Upstream commit ab033e7846f91953244d0626b28ce66412b813b3 ] The rpmh driver will cache sleep and wake votes until the cluster power-domain is about to enter idle, to avoid unnecessary writes. So associate the apps_rsc with the cluster pd, so that it can be notified about this event. Without this, only AMC votes are being commited. Fixes: 6bd20c54b589 ("arm64: dts: qcom: Add base QDU1000/QRU1000 DTSIs") Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Bjorn Andersson <andersson@kernel.org> Link: https://lore.kernel.org/r/20230531-topic-rsc-v1-3-b4a985f57b8b@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-11 16:51:24 +0300