summaryrefslogtreecommitdiff
path: root/arch/riscv
AgeCommit message (Collapse)Author
2025-07-23riscv: dts: sophgo: sg2044: add pmu configurationInochi Amaoto
Add PMU configuration for the cpu of sg2044, which is the V2 version of C920. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Tested-by: Han Gao <rabenda.cn@gmail.com> Link: https://lore.kernel.org/r/20250703003844.84617-1-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: add ziccrse extensionHan Gao
sg2044 support ziccrse extension. Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://lore.kernel.org/r/0889174f2e013e095b94940614f4a0a6e614b09c.1751858054.git.rabenda.cn@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: add zfh for sg2042Han Gao
sg2042 support Zfh ISA extension [1]. Link: https://occ-oss-prod.oss-cn-hangzhou.aliyuncs.com/resource//1737721869472/%E7%8E%84%E9%93%81C910%E4%B8%8EC920R1S6%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C%28xrvm%29_20250124.pdf [1] Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/bcaf5684c614959f49a9770bf3cd41096cee5fe6.1751698574.git.rabenda.cn@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: add ziccrse for sg2042Han Gao
sg2042 support Ziccrse ISA extension [1]. Link: https://lore.kernel.org/all/20241103145153.105097-12-alexghiti@rivosinc.com/ [1] Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/859df9a05e1693fec9bd2c7dcf14415bb15230bd.1751698574.git.rabenda.cn@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: Add xtheadvector to the sg2042 devicetreeHan Gao
The sg2042 SoCs support xtheadvector [1] so it can be included in the devicetree. Also include vlenb for the cpu. And set vlenb=16 [2]. This can be tested by passing the "mitigations=off" kernel parameter. Link: https://lore.kernel.org/linux-riscv/20241113-xtheadvector-v11-4-236c22791ef9@rivosinc.com/ [1] Link: https://lore.kernel.org/linux-riscv/aCO44SAoS2kIP61r@ghost/ [2] Signed-off-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Inochi Amaoto <inochiama@gmail.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/915bef0530dee6c8bc0ae473837a4bd6786fa4fb.1751698574.git.rabenda.cn@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: add PCIe device support for SG2044Inochi Amaoto
Add PCIe device node for SG2044 and configuration for Sophgo SRD3-10. Link: https://lore.kernel.org/r/20250618015851.272188-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: add MSI device support for SG2044Inochi Amaoto
Add MSI device tree node for SG2044. Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/20250618015851.272188-2-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: add reset configuration for Sophgo CV1800 series SoCInochi Amaoto
Add known reset configuration for existed device. Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20250617070144.1149926-5-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: add reset generator for Sophgo CV1800 series SoCInochi Amaoto
Add reset generator node for all CV18XX series SoC. Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Tested-by: Junhui Liu <junhui.liu@pigmoral.tech> Tested-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Link: https://lore.kernel.org/r/20250617070144.1149926-4-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add missing riscv,cbop-block-size propertyInochi Amaoto
The kernel complains no "riscv,cbop-block-size" and disables the Zicbop extension. Add the missing property to keep it functional. Fixes: ae5bac370ed4 ("riscv: dts: sophgo: Add initial device tree of Sophgo SRD3-10") Link: https://lore.kernel.org/r/20250613074513.1683624-1-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: add pwm controller for SG2044Longbin Li
Add pwm device node for SG2044. Signed-off-by: Longbin Li <looong.bin@gmail.com> Reviewed-by: Chen Wang <unicorn_wang@outlook.com> Link: https://lore.kernel.org/r/20250608232836.784737-12-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: add SG2044 SPI NOR controller driverLongbin Li
Add SPI NOR device node for SG2044. Signed-off-by: Longbin Li <looong.bin@gmail.com> Link: https://lore.kernel.org/r/20250608232836.784737-11-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add pinctrl deviceInochi Amaoto
Add pinctrl DT node and configuration for SG2044. Link: https://lore.kernel.org/r/20250608232836.784737-10-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add ethernet control deviceInochi Amaoto
Add ethernet control node for sg2044. Link: https://lore.kernel.org/r/20250608232836.784737-9-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sophgo-srd3-10: add HWMON MCU deviceInochi Amaoto
Add MCU devicetree node for Sophgo SRD3-10 board. This is used to provide SUSP function for the board. Link: https://lore.kernel.org/r/20250608232836.784737-8-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add MMC controller deviceInochi Amaoto
Add emmc controller and sd controller DT node for SG2044. Link: https://lore.kernel.org/r/20250608232836.784737-7-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: add DMA controller deviceInochi Amaoto
The DMA controller of SG2044 is a standard Synopsys IP, which is already supported by the kernel. Add DMA controller DT node for SG2044. Link: https://lore.kernel.org/r/20250608232836.784737-6-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add I2C deviceInochi Amaoto
The I2C controller of SG2044 is a standard Synopsys IP, with one the ref clock is need. Add I2C DT node for SG2044 SoC. Link: https://lore.kernel.org/r/20250608232836.784737-5-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add GPIO deviceInochi Amaoto
The GPIO controller is a standard Synopsys IP, which is already supported by the kernel. Add GPIO DT node for SG2044 SoC. Link: https://lore.kernel.org/r/20250608232836.784737-4-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add clock controller deviceInochi Amaoto
Add clock controller and pll clock node for sg2044. Link: https://lore.kernel.org/r/20250608232836.784737-3-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: sg2044: Add system controller deviceInochi Amaoto
The TOP system controller device is necessary for the SG2044 clock controller. Add it to the SoC device tree. Link: https://lore.kernel.org/r/20250608232836.784737-2-inochiama@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-23riscv: dts: sophgo: cv18xx: Add RTCSYS device nodeAlexander Sverdlin
Add the RTCSYS MFD node: in Cvitek CV18xx and its successors RTC Subsystem is quite advanced and provides SoC power management functions as well. The SoC family also contains DW8051 block (Intel 8051 compatible CPU core) and an associated SRAM. The corresponding control registers are mapped into RTCSYS address space as well. Link: https://github.com/sophgo/sophgo-doc/tree/main/SG200X/TRM Signed-off-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Reviewed-by: Inochi Amaoto <inochiama@gmail.com> Link: https://lore.kernel.org/r/20250513203128.620731-1-alexander.sverdlin@gmail.com Signed-off-by: Inochi Amaoto <inochiama@gmail.com> Signed-off-by: Chen Wang <unicorn_wang@outlook.com> Signed-off-by: Chen Wang <wangchen20@iscas.ac.cn>
2025-07-22tracing: Remove redundant config HAVE_FTRACE_MCOUNT_RECORDSteven Rostedt
Ftrace is tightly coupled with architecture specific code because it requires the use of trampolines written in assembly. This means that when a new feature or optimization is made, it must be done for all architectures. To simplify the approach, CONFIG_HAVE_FTRACE_* configs are added to denote which architecture has the new enhancement so that other architectures can still function until they too have been updated. The CONFIG_HAVE_FTRACE_MCOUNT was added to help simplify the DYNAMIC_FTRACE work, but now every architecture that implements DYNAMIC_FTRACE also has HAVE_FTRACE_MCOUNT set too, making it redundant with the HAVE_DYNAMIC_FTRACE. Remove the HAVE_FTRACE_MCOUNT config and use DYNAMIC_FTRACE directly where applicable. Link: https://lore.kernel.org/all/20250703154916.48e3ada7@gandalf.local.home/ Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Link: https://lore.kernel.org/20250704104838.27a18690@gandalf.local.home Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
2025-07-23riscv/bug: Add ARCH_WARN_ASM macro for BUG/WARN asm code sharing with RustFUJITA Tomonori
Add new ARCH_WARN_ASM macro for BUG/WARN assembly code sharing with Rust to avoid the duplication. No functional changes. Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com> Signed-off-by: FUJITA Tomonori <fujita.tomonori@gmail.com> Link: https://lore.kernel.org/r/20250502094537.231725-3-fujita.tomonori@gmail.com [ Remove ending newline in `ARCH_WARN_ASM` content to be closer to the original. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-07-22Merge tag 'thead-dt-for-v6.17' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux into soc/dt T-HEAD Devicetrees for v6.17 There are several additions for the T-Head TH1520 SoC: - Add PVT node for thermal sensor which works with the existing Moortec MR75203 driver. - Add "gpu-clkgen" reset property to the AON node which allows the power domain driver to detect the capability to power sequence the GPU. All of these patches have been tested in linux-next. Signed-off-by: Drew Fustini <fustini@kernel.org> * tag 'thead-dt-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/fustini/linux: riscv: dts: thead: Add PVT node riscv: dts: thead: th1520: Add GPU clkgen reset to AON node Link: https://lore.kernel.org/r/aHtnwthmTpfkIBMr@x1 Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-22Merge tag 'riscv-config-for-v6.17' of ↵Arnd Bergmann
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/defconfig RISC-V soc defconfig for v6.17 spacemit: Enable sdhci and pwm drivers for the k1 soc in defconfig, the former as a builtin and the latter a module. starfive: Remove a no-longer required config for the starfive sound driver. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-config-for-v6.17' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: riscv: defconfig: spacemit: enable sdhci driver for K1 SoC riscv: defconfig: Enable PWM support for SpacemiT K1 SoC riscv: defconfig: Remove CONFIG_SND_SOC_STARFIVE=m Link: https://lore.kernel.org/r/20250716-defrost-regime-20a55ed925ad@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-22Merge tag 'spacemit-dt-for-6.17-1' of https://github.com/spacemit-com/linux ↵Arnd Bergmann
into soc/dt RISC-V SpacemiT DT changes for 6.17 - Add DMA translation buses - Add PWM support - Add Reset support - Add eMMC node * tag 'spacemit-dt-for-6.17-1' of https://github.com/spacemit-com/linux: riscv: dts: spacemit: Move eMMC under storage-bus for K1 riscv: dts: spacemit: Move UARTs under dma-bus for K1 riscv: dts: spacemit: Add DMA translation buses for K1 riscv: dts: spacemit: add pwm14_1 pinctrl setting riscv: dts: spacemit: add PWM support for K1 SoC riscv: dts: spacemit: add reset support for the K1 SoC dt-bindings: soc: spacemit: define spacemit,k1-ccu resets riscv: dts: spacemit: enable eMMC for K1 SoC Link: https://lore.kernel.org/r/20250715014214-GYA540030@gentoo Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-21stackleak: Rename STACKLEAK to KSTACK_ERASEKees Cook
In preparation for adding Clang sanitizer coverage stack depth tracking that can support stack depth callbacks: - Add the new top-level CONFIG_KSTACK_ERASE option which will be implemented either with the stackleak GCC plugin, or with the Clang stack depth callback support. - Rename CONFIG_GCC_PLUGIN_STACKLEAK as needed to CONFIG_KSTACK_ERASE, but keep it for anything specific to the GCC plugin itself. - Rename all exposed "STACKLEAK" names and files to "KSTACK_ERASE" (named for what it does rather than what it protects against), but leave as many of the internals alone as possible to avoid even more churn. While here, also split "prev_lowest_stack" into CONFIG_KSTACK_ERASE_METRICS, since that's the only place it is referenced from. Suggested-by: Ingo Molnar <mingo@kernel.org> Link: https://lore.kernel.org/r/20250717232519.2984886-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-21riscv: defconfig: enable Andes SoCBen Zong-You Xie
Enable Andes SoC config in defconfig to allow the default upstream kernel to boot on Voyager board. Acked-by: Conor Dooley <conor.dooley@microchip.com> Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Link: https://lore.kernel.org/r/20250711133025.2192404-9-ben717@andestech.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-21riscv: dts: andes: add Voyager board device treeBen Zong-You Xie
Introduce the device tree support for Voyager development board. Currently only support booting into console with only uart, other features will be added later. Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Link: https://lore.kernel.org/r/20250711133025.2192404-8-ben717@andestech.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-21riscv: dts: andes: add QiLai SoC device treeBen Zong-You Xie
Introduce the initial device tree support for the Andes QiLai SoC. For further information, you can refer to [1]. [1] https://www.andestech.com/en/products-solutions/andeshape-platforms/qilai-chip/ Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Link: https://lore.kernel.org/r/20250711133025.2192404-7-ben717@andestech.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-21riscv: add Andes SoC family Kconfig supportBen Zong-You Xie
The first SoC in the Andes series is QiLai. It includes a high-performance quad-core RISC-V AX45MP cluster and one NX27V vector processor. For further information, refer to [1]. [1] https://www.andestech.com/en/products-solutions/andeshape-platforms/qilai-chip/ Signed-off-by: Ben Zong-You Xie <ben717@andestech.com> Link: https://lore.kernel.org/r/20250711133025.2192404-2-ben717@andestech.com Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-07-19riscv: optimize gcd() performance on RISC-V without Zbb extensionKuan-Wei Chiu
The binary GCD implementation uses FFS (find first set), which benefits from hardware support for the ctz instruction, provided by the Zbb extension on RISC-V. Without Zbb, this results in slower software-emulated behavior. Previously, RISC-V always used the binary GCD, regardless of actual hardware support. This patch improves runtime efficiency by disabling the efficient_ffs_key static branch when Zbb is either not enabled in the kernel (config) or not supported on the executing CPU. This selects the odd-even GCD implementation, which is faster in the absence of efficient FFS. This change ensures the most suitable GCD algorithm is chosen dynamically based on actual hardware capabilities. Link: https://lkml.kernel.org/r/20250606134758.1308400-4-visitorckw@gmail.com Co-developed-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Ching-Chun (Jim) Huang <jserv@ccns.ncku.edu.tw> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-19riscv: optimize gcd() code size when CONFIG_RISCV_ISA_ZBB is disabledKuan-Wei Chiu
The binary GCD implementation depends on efficient ffs(), which on RISC-V requires hardware support for the Zbb extension. When CONFIG_RISCV_ISA_ZBB is not enabled, the kernel will never use binary GCD, as runtime logic will always fall back to the odd-even implementation. To avoid compiling unused code and reduce code size, select CONFIG_CPU_NO_EFFICIENT_FFS when CONFIG_RISCV_ISA_ZBB is not set. $ ./scripts/bloat-o-meter ./lib/math/gcd.o.old ./lib/math/gcd.o.new add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-274 (-274) Function old new delta gcd 360 86 -274 Total: Before=384, After=110, chg -71.35% Link: https://lkml.kernel.org/r/20250606134758.1308400-3-visitorckw@gmail.com Co-developed-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com> Acked-by: Alexandre Ghiti <alexghiti@rivosinc.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Ching-Chun (Jim) Huang <jserv@ccns.ncku.edu.tw> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-19Add a new optional ",cma" suffix to the crashkernel= command line optionJiri Bohac
Patch series "kdump: crashkernel reservation from CMA", v5. This series implements a way to reserve additional crash kernel memory using CMA. Currently, all the memory for the crash kernel is not usable by the 1st (production) kernel. It is also unmapped so that it can't be corrupted by the fault that will eventually trigger the crash. This makes sense for the memory actually used by the kexec-loaded crash kernel image and initrd and the data prepared during the load (vmcoreinfo, ...). However, the reserved space needs to be much larger than that to provide enough run-time memory for the crash kernel and the kdump userspace. Estimating the amount of memory to reserve is difficult. Being too careful makes kdump likely to end in OOM, being too generous takes even more memory from the production system. Also, the reservation only allows reserving a single contiguous block (or two with the "low" suffix). I've seen systems where this fails because the physical memory is fragmented. By reserving additional crashkernel memory from CMA, the main crashkernel reservation can be just large enough to fit the kernel and initrd image, minimizing the memory taken away from the production system. Most of the run-time memory for the crash kernel will be memory previously available to userspace in the production system. As this memory is no longer wasted, the reservation can be done with a generous margin, making kdump more reliable. Kernel memory that we need to preserve for dumping is normally not allocated from CMA, unless it is explicitly allocated as movable. Currently this is only the case for memory ballooning and zswap. Such movable memory will be missing from the vmcore. User data is typically not dumped by makedumpfile. When dumping of user data is intended this new CMA reservation cannot be used. There are five patches in this series: The first adds a new ",cma" suffix to the recenly introduced generic crashkernel parsing code. parse_crashkernel() takes one more argument to store the cma reservation size. The second patch implements reserve_crashkernel_cma() which performs the reservation. If the requested size is not available in a single range, multiple smaller ranges will be reserved. The third patch updates Documentation/, explicitly mentioning the potential DMA corruption of the CMA-reserved memory. The fourth patch adds a short delay before booting the kdump kernel, allowing pending DMA transfers to finish. The fifth patch enables the functionality for x86 as a proof of concept. There are just three things every arch needs to do: - call reserve_crashkernel_cma() - include the CMA-reserved ranges in the physical memory map - exclude the CMA-reserved ranges from the memory available through /proc/vmcore by excluding them from the vmcoreinfo PT_LOAD ranges. Adding other architectures is easy and I can do that as soon as this series is merged. With this series applied, specifying crashkernel=100M craskhernel=1G,cma on the command line will make a standard crashkernel reservation of 100M, where kexec will load the kernel and initrd. An additional 1G will be reserved from CMA, still usable by the production system. The crash kernel will have 1.1G memory available. The 100M can be reliably predicted based on the size of the kernel and initrd. The new cma suffix is completely optional. When no crashkernel=size,cma is specified, everything works as before. This patch (of 5): Add a new cma_size parameter to parse_crashkernel(). When not NULL, call __parse_crashkernel to parse the CMA reservation size from "crashkernel=size,cma" and store it in cma_size. Set cma_size to NULL in all calls to parse_crashkernel(). Link: https://lkml.kernel.org/r/aEqnxxfLZMllMC8I@dwarf.suse.cz Link: https://lkml.kernel.org/r/aEqoQckgoTQNULnh@dwarf.suse.cz Signed-off-by: Jiri Bohac <jbohac@suse.cz> Cc: Baoquan He <bhe@redhat.com> Cc: Dave Young <dyoung@redhat.com> Cc: Donald Dutile <ddutile@redhat.com> Cc: Michal Hocko <mhocko@suse.cz> Cc: Philipp Rudo <prudo@redhat.com> Cc: Pingfan Liu <piliu@redhat.com> Cc: Tao Liu <ltao@redhat.com> Cc: Vivek Goyal <vgoyal@redhat.com> Cc: David Hildenbrand <david@redhat.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-18Merge tag 'riscv-for-linus-6.16-rc7' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - Three fixes for unnecessary spew: an ACPI CPPC boot-time debug message, the link-time warnings for R_RISCV_NONE in binaries, and some compile-time warnings in __put_user_nocheck - A fix for a race during text patching - Interrupts are no longer disabled during exception handling - A fix for a missing sign extension in the misaligned load handler - A fix to avoid static ftrace being selected in Kconfig, as we have moved to dynamic ftrace * tag 'riscv-for-linus-6.16-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheck riscv: Stop supporting static ftrace riscv: traps_misaligned: properly sign extend value in misaligned load handler riscv: Enable interrupt during exception handling riscv: ftrace: Properly acquire text_mutex to fix a race condition ACPI: RISC-V: Remove unnecessary CPPC debug message riscv: Stop considering R_RISCV_NONE as bad relocations
2025-07-16riscv: uaccess: Fix -Wuninitialized and -Wshadow in __put_user_nocheckNathan Chancellor
After a recent change in clang to strengthen uninitialized warnings [1], there is a warning from val being uninitialized in __put_user_nocheck when called from futex_put_value(): kernel/futex/futex.h:326:18: warning: variable 'val' is uninitialized when used within its own initialization [-Wuninitialized] 326 | unsafe_put_user(val, to, Efault); | ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:464:21: note: expanded from macro 'unsafe_put_user' 464 | __put_user_nocheck(x, (ptr), label) | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~ arch/riscv/include/asm/uaccess.h:314:36: note: expanded from macro '__put_user_nocheck' 314 | __inttype(x) val = (__inttype(x))x; \ | ~~~ ^ While not on by default, -Wshadow flags the same mistake: kernel/futex/futex.h:326:2: warning: declaration shadows a local variable [-Wshadow] 326 | unsafe_put_user(val, to, Efault); | ^ arch/riscv/include/asm/uaccess.h:464:2: note: expanded from macro 'unsafe_put_user' 464 | __put_user_nocheck(x, (ptr), label) | ^ arch/riscv/include/asm/uaccess.h:314:16: note: expanded from macro '__put_user_nocheck' 314 | __inttype(x) val = (__inttype(x))x; \ | ^ kernel/futex/futex.h:320:48: note: previous declaration is here 320 | static __always_inline int futex_put_value(u32 val, u32 __user *to) | ^ Use a three underscore prefix for the val variable in __put_user_nocheck to avoid clashing with either val or __val, which are both used within the put_user macros, clearing up all warnings. Closes: https://github.com/ClangBuiltLinux/linux/issues/2109 Fixes: ca1a66cdd685 ("riscv: uaccess: do not do misaligned accesses in get/put_user()") Link: https://github.com/llvm/llvm-project/commit/2464313eef01c5b1edf0eccf57a32cdee01472c7 [1] Signed-off-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250715-riscv-uaccess-fix-self-init-val-v1-1-82b8e911f120@kernel.org Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: Stop supporting static ftraceAlexandre Ghiti
Now that DYNAMIC_FTRACE was introduced, there is no need to support static ftrace as it is way less performant. This simplifies the code and prevents build failures as reported by kernel test robot when !DYNAMIC_FTRACE. Also make sure that FUNCTION_TRACER can only be selected if DYNAMIC_FTRACE is supported (we have a dependency on the toolchain). Co-developed-by: chenmiao <chenmiao.ku@gmail.com> Signed-off-by: chenmiao <chenmiao.ku@gmail.com> Fixes: b2137c3b6d7a ("riscv: ftrace: prepare ftrace for atomic code patching") Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506191949.o3SMu8Zn-lkp@intel.com/ Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250716-dev-alex-static_ftrace-v1-1-ba5d2b6fc9c0@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: traps_misaligned: properly sign extend value in misaligned load handlerAndreas Schwab
Add missing cast to signed long. Signed-off-by: Andreas Schwab <schwab@suse.de> Fixes: 956d705dd279 ("riscv: Unaligned load/store handling for M_MODE") Tested-by: Clément Léger <cleger@rivosinc.com> Link: https://lore.kernel.org/r/mvmikk0goil.fsf@suse.de Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: Enable interrupt during exception handlingNam Cao
force_sig_fault() takes a spinlock, which is a sleeping lock with CONFIG_PREEMPT_RT=y. However, exception handling calls force_sig_fault() with interrupt disabled, causing a sleeping in atomic context warning. This can be reproduced using userspace programs such as: int main() { asm ("ebreak"); } or int main() { asm ("unimp"); } There is no reason that interrupt must be disabled while handling exceptions from userspace. Enable interrupt while handling user exceptions. This also has the added benefit of avoiding unnecessary delays in interrupt handling. Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Suggested-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> Signed-off-by: Nam Cao <namcao@linutronix.de> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250625085630.3649485-1-namcao@linutronix.de Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: dts: starfive: jh7110-common: add status power led nodeE Shattow
Add status power led node for StarFive VisionFive2 and variant boards. Signed-off-by: E Shattow <e@freeshell.de> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-07-16riscv: dts: starfive: jh7110-milkv-mars sort propertiesE Shattow
Improve style with node property order sort of common properties before vendor prefixes Signed-off-by: E Shattow <e@freeshell.de> Acked-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2025-07-16riscv: ftrace: Properly acquire text_mutex to fix a race conditionAlexandre Ghiti
As reported by lockdep, some patching was done without acquiring text_mutex, so there could be a race when mapping the page to patch since we use the same fixmap entry. Reported-by: Han Gao <rabenda.cn@gmail.com> Reported-by: Vivian Wang <wangruikang@iscas.ac.cn> Reported-by: Yao Zi <ziyao@disroot.org> Closes: https://lore.kernel.org/linux-riscv/aGODMpq7TGINddzM@pie.lan/ Tested-by: Yao Zi <ziyao@disroot.org> Tested-by: Han Gao <rabenda.cn@gmail.com> Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20250711-alex-fixes-v2-1-d85a5438da6c@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-16riscv: Stop considering R_RISCV_NONE as bad relocationsAlexandre Ghiti
Even though those relocations should not be present in the final vmlinux, there are a lot of them. And since those relocations are considered "bad", they flood the compilation output which may hide some legitimate bad relocations. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Tested-by: Ron Economos <re@w6rz.net> Link: https://lore.kernel.org/r/20250710-dev-alex-riscv_none_bad_relocs_v1-v1-1-758f2fcc6e75@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
2025-07-14riscv: ptrace: Use USER_REGSET_NOTE_TYPE() to specify regset note namesDave Martin
Instead of having the core code guess the note name for each regset, use USER_REGSET_NOTE_TYPE() to pick the correct name from elf.h. Signed-off-by: Dave Martin <Dave.Martin@arm.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Oleg Nesterov <oleg@redhat.com> Cc: Kees Cook <kees@kernel.org> Cc: Akihiko Odaki <akihiko.odaki@daynix.com> Cc: linux-riscv@lists.infradead.org Reviewed-by: Akihiko Odaki <odaki@rsg.ci.i.u-tokyo.ac.jp> Link: https://lore.kernel.org/r/20250701135616.29630-17-Dave.Martin@arm.com Signed-off-by: Kees Cook <kees@kernel.org>
2025-07-11RISC-V: KVM: Move HGEI[E|P] CSR access to IMSIC virtualizationAnup Patel
Currently, the common AIA functions kvm_riscv_vcpu_aia_has_interrupts() and kvm_riscv_aia_wakeon_hgei() lookup HGEI line using an array of VCPU pointers before accessing HGEI[E|P] CSR which is slow and prone to race conditions because there is a separate per-hart lock for the VCPU pointer array and a separate per-VCPU rwlock for IMSIC VS-file (including HGEI line) used by the VCPU. Due to these race conditions, it is observed on QEMU RISC-V host that Guest VCPUs sleep in WFI and never wakeup even with interrupt pending in the IMSIC VS-file because VCPUs were waiting for HGEI wakeup on the wrong host CPU. The IMSIC virtualization already keeps track of the HGEI line and the associated IMSIC VS-file used by each VCPU so move the HGEI[E|P] CSR access to IMSIC virtualization so that costly HGEI line lookup can be avoided and likelihood of race-conditions when updating HGEI[E|P] CSR is also reduced. Reviewed-by: Atish Patra <atishp@rivosinc.com> Tested-by: Atish Patra <atishp@rivosinc.com> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Fixes: 3385339296d1 ("RISC-V: KVM: Use IMSIC guest files when available") Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://lore.kernel.org/r/20250707035345.17494-3-apatel@ventanamicro.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-07-11RISC-V: KVM: Disable vstimecmp before exiting to user-spaceAnup Patel
If VS-timer expires when no VCPU running on a host CPU then WFI executed by such host CPU will be effective NOP resulting in no power savings. This is as-per RISC-V Privileged specificaiton which says: "WFI is also required to resume execution for locally enabled interrupts pending at any privilege level, regardless of the global interrupt enable at each privilege level." To address the above issue, vstimecmp CSR must be set to -1UL over here when VCPU is scheduled-out or exits to user space. Reviewed-by: Atish Patra <atishp@rivosinc.com> Tested-by: Atish Patra <atishp@rivosinc.com> Tested-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Fixes: 8f5cb44b1bae ("RISC-V: KVM: Support sstc extension") Fixes: cea8896bd936 ("RISC-V: KVM: Fix kvm_riscv_vcpu_timer_pending() for Sstc") Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Closes: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2112578 Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Nutty Liu <liujingqi@lanxincomputing.com> Link: https://lore.kernel.org/r/20250707035345.17494-2-apatel@ventanamicro.com Signed-off-by: Anup Patel <anup@brainfault.org>
2025-07-09mm/ptdump: take the memory hotplug lock inside ptdump_walk_pgd()Anshuman Khandual
Memory hot remove unmaps and tears down various kernel page table regions as required. The ptdump code can race with concurrent modifications of the kernel page tables. When leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. But when intermediate levels of kernel page table are freed, the dump code will continue to use memory that has been freed and potentially reallocated for another purpose. In such cases, the ptdump code may dereference bogus addresses, leading to a number of potential problems. To avoid the above mentioned race condition, platforms such as arm64, riscv and s390 take memory hotplug lock, while dumping kernel page table via the sysfs interface /sys/kernel/debug/kernel_page_tables. Similar race condition exists while checking for pages that might have been marked W+X via /sys/kernel/debug/kernel_page_tables/check_wx_pages which in turn calls ptdump_check_wx(). Instead of solving this race condition again, let's just move the memory hotplug lock inside generic ptdump_check_wx() which will benefit both the scenarios. Drop get_online_mems() and put_online_mems() combination from all existing platform ptdump code paths. Link: https://lkml.kernel.org/r/20250620052427.2092093-1-anshuman.khandual@arm.com Fixes: bbd6ec605c0f ("arm64/mm: Enable memory hot remove") Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> Acked-by: David Hildenbrand <david@redhat.com> Reviewed-by: Dev Jain <dev.jain@arm.com> Acked-by: Alexander Gordeev <agordeev@linux.ibm.com> [s390] Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will@kernel.org> Cc: Ryan Roberts <ryan.roberts@arm.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Alexander Gordeev <agordeev@linux.ibm.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: Christian Borntraeger <borntraeger@linux.ibm.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-09mm: remove devmap related functions and page table bitsAlistair Popple
Now that DAX and all other reference counts to ZONE_DEVICE pages are managed normally there is no need for the special devmap PTE/PMD/PUD page table bits. So drop all references to these, freeing up a software defined page table bit on architectures supporting it. Link: https://lkml.kernel.org/r/6389398c32cc9daa3dfcaa9f79c7972525d310ce.1750323463.git-series.apopple@nvidia.com Signed-off-by: Alistair Popple <apopple@nvidia.com> Acked-by: Will Deacon <will@kernel.org> # arm64 Acked-by: David Hildenbrand <david@redhat.com> Suggested-by: Chunyan Zhang <zhang.lyra@gmail.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Jason Gunthorpe <jgg@nvidia.com> Cc: Balbir Singh <balbirs@nvidia.com> Cc: Björn Töpel <bjorn@kernel.org> Cc: Christoph Hellwig <hch@lst.de> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Deepak Gupta <debug@rivosinc.com> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com> Cc: Inki Dae <m.szyprowski@samsung.com> Cc: John Groves <john@groves.net> Cc: John Hubbard <jhubbard@nvidia.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Cc: Matthew Wilcox (Oracle) <willy@infradead.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2025-07-09mm/pagewalk: split walk_page_range_novma() into kernel/user partsLorenzo Stoakes
walk_page_range_novma() is rather confusing - it supports two modes, one used often, the other used only for debugging. The first mode is the common case of traversal of kernel page tables, which is what nearly all callers use this for. Secondly it provides an unusual debugging interface that allows for the traversal of page tables in a userland range of memory even for that memory which is not described by a VMA. It is far from certain that such page tables should even exist, but perhaps this is precisely why it is useful as a debugging mechanism. As a result, this is utilised by ptdump only. Historically, things were reversed - ptdump was the only user, and other parts of the kernel evolved to use the kernel page table walking here. Since we have some complicated and confusing locking rules for the novma case, it makes sense to separate the two usages into their own functions. Doing this also provide self-documentation as to the intent of the caller - are they doing something rather unusual or are they simply doing a standard kernel page table walk? We therefore establish two separate functions - walk_page_range_debug() for this single usage, and walk_kernel_page_table_range() for general kernel page table walking. The walk_page_range_debug() function is currently used to traverse both userland and kernel mappings, so we maintain this and in the case of kernel mappings being traversed, we have walk_page_range_debug() invoke walk_kernel_page_table_range() internally. We additionally make walk_page_range_debug() internal to mm. Link: https://lkml.kernel.org/r/20250605135104.90720-1-lorenzo.stoakes@oracle.com Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Acked-by: Qi Zheng <zhengqi.arch@bytedance.com> Reviewed-by: Oscar Salvador <osalvador@suse.de> Reviewed-by: Suren Baghdasaryan <surenb@google.com> Reviewed-by: Vlastimil Babka <vbabka@suse.cz> Acked-by: David Hildenbrand <david@redhat.com> Cc: Albert Ou <aou@eecs.berkeley.edu> Cc: Alexandre Ghiti <alex@ghiti.fr> Cc: Barry Song <baohua@kernel.org> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Jann Horn <jannh@google.com> Cc: Jonas Bonn <jonas@southpole.se> Cc: Liam Howlett <liam.howlett@oracle.com> Cc: Michal Hocko <mhocko@suse.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Palmer Dabbelt <palmer@dabbelt.com> Cc: Paul Walmsley <paul.walmsley@sifive.com> Cc: Stafford Horne <shorne@gmail.com> Cc: Stefan Kristiansson <stefan.kristiansson@saunalahti.fi> Cc: WANG Xuerui <kernel@xen0n.name> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>