summaryrefslogtreecommitdiff
path: root/arch/riscv
AgeCommit message (Collapse)AuthorFilesLines
2023-08-16riscv: kdump: Implement crashkernel=X,[high,low]Chen Jiahao2-7/+91
On riscv, the current crash kernel allocation logic is trying to allocate within 32bit addressible memory region by default, if failed, try to allocate without 4G restriction. In need of saving DMA zone memory while allocating a relatively large crash kernel region, allocating the reserved memory top down in high memory, without overlapping the DMA zone, is a mature solution. Here introduce the parameter option crashkernel=X,[high,low]. One can reserve the crash kernel from high memory above DMA zone range by explicitly passing "crashkernel=X,high"; or reserve a memory range below 4G with "crashkernel=X,low". Signed-off-by: Chen Jiahao <chenjiahao16@huawei.com> Acked-by: Guo Ren <guoren@kernel.org> Acked-by: Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20230726175000.2536220-2-chenjiahao16@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kprobes: simulate c.beqz and c.bnezNam Cao3-2/+48
kprobes currently rejects instruction c.beqz and c.bnez. Implement them. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/1d879dba4e4ee9a82e27625d6483b5c9cfed684f.1690704360.git.namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kprobes: simulate c.jr and c.jalr instructionsNam Cao3-2/+41
kprobes currently rejects c.jr and c.jalr instructions. Implement them. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/db8b7787e9208654cca50484f68334f412be2ea9.1690704360.git.namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: kprobes: simulate c.j instructionNam Cao3-1/+27
kprobes currently rejects c.j instruction. Implement it. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Link: https://lore.kernel.org/r/6ef76cd9984b8015826649d13f870f8ac45a2d0d.1690704360.git.namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: Handle zicsr/zifencei issue between gcc and binutilsMingzheng Xing2-14/+26
Binutils-2.38 and GCC-12.1.0 bumped[0][1] the default ISA spec to the newer 20191213 version which moves some instructions from the I extension to the Zicsr and Zifencei extensions. So if one of the binutils and GCC exceeds that version, we should explicitly specifying Zicsr and Zifencei via -march to cope with the new changes. but this only occurs when binutils >= 2.36 and GCC >= 11.1.0. It's a different story when binutils < 2.36. binutils-2.36 supports the Zifencei extension[2] and splits Zifencei and Zicsr from I[3]. GCC-11.1.0 is particular[4] because it add support Zicsr and Zifencei extension for -march. binutils-2.35 does not support the Zifencei extension, and does not need to specify Zicsr and Zifencei when working with GCC >= 12.1.0. To make our lives easier, let's relax the check to binutils >= 2.36 in CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. For the other two cases, where clang < 17 or GCC < 11.1.0, we will deal with them in CONFIG_TOOLCHAIN_NEEDS_OLD_ISA_SPEC. For more information, please refer to: commit 6df2a016c0c8 ("riscv: fix build with binutils 2.38") commit e89c2e815e76 ("riscv: Handle zicsr/zifencei issues between clang and binutils") Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc [0] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd [1] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=5a1b31e1e1cee6e9f1c92abff59cdcfff0dddf30 [2] Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=729a53530e86972d1143553a415db34e6e01d5d2 [3] Link: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b03be74bad08c382da47e048007a78fa3fb4ef49 [4] Link: https://lore.kernel.org/all/20230308220842.1231003-1-conor@kernel.org Link: https://lore.kernel.org/all/20230223220546.52879-1-conor@kernel.org Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Acked-by: Guo Ren <guoren@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Mingzheng Xing <xingmingzheng@iscas.ac.cn> Link: https://lore.kernel.org/r/20230809165648.21071-1-xingmingzheng@iscas.ac.cn Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: uaccess: Return the number of bytes effectively not copiedAlexandre Ghiti1-4/+7
It was reported that the riscv kernel hangs while executing the test in [1]. Indeed, the test hangs when trying to write a buffer to a file. The problem is that the riscv implementation of raw_copy_from_user() does not return the correct number of bytes not written when an exception happens and is fixed up, instead it always returns the initial size to copy, even if some bytes were actually copied. generic_perform_write() pre-faults the user pages and bails out if nothing can be written, otherwise it will access the userspace buffer: here the riscv implementation keeps returning it was not able to copy any byte though the pre-faulting indicates otherwise. So generic_perform_write() keeps retrying to access the user memory and ends up in an infinite loop. Note that before the commit mentioned in [1] that introduced this regression, it worked because generic_perform_write() would bail out if only one byte could not be written. So fix this by returning the number of bytes effectively not written in __asm_copy_[to|from]_user() and __clear_user(), as it is expected. Link: https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/ [1] Fixes: ebcbd75e3962 ("riscv: Fix the bug in memory access fixup code") Reported-by: Bo YU <tsu.yubo@gmail.com> Closes: https://lore.kernel.org/linux-riscv/20230309151841.bomov6hq3ybyp42a@debian/#t Reported-by: Aurelien Jarno <aurelien@aurel32.net> Closes: https://lore.kernel.org/linux-riscv/ZNOnCakhwIeue3yr@aurel32.net/ Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Tested-by: Aurelien Jarno <aurelien@aurel32.net> Reviewed-by: Aurelien Jarno <aurelien@aurel32.net> Link: https://lore.kernel.org/r/20230811150604.1621784-1-alexghiti@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: stack: Fixup independent softirq stack for CONFIG_FRAME_POINTER=nGuo Ren1-0/+3
The independent softirq stack uses s0 to save & restore sp, but s0 would be corrupted when CONFIG_FRAME_POINTER=n. So add s0 in the clobber list to fix the problem. Fixes: dd69d07a5a6c ("riscv: stack: Support HAVE_SOFTIRQ_ON_OWN_STACK") Cc: stable@vger.kernel.org Reported-by: Zhangjin Wu <falcon@tinylab.org> Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Tested-by: Drew Fustini <dfustini@baylibre.com> Link: https://lore.kernel.org/r/20230716001506.3506041-3-guoren@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: stack: Fixup independent irq stack for CONFIG_FRAME_POINTER=nGuo Ren1-0/+3
The independent irq stack uses s0 to save & restore sp, but s0 would be corrupted when CONFIG_FRAME_POINTER=n. So add s0 in the clobber list to fix the problem. Fixes: 163e76cc6ef4 ("riscv: stack: Support HAVE_IRQ_EXIT_ON_IRQ_STACK") Cc: stable@vger.kernel.org Reported-by: Zhangjin Wu <falcon@tinylab.org> Signed-off-by: Guo Ren <guoren@linux.alibaba.com> Signed-off-by: Guo Ren <guoren@kernel.org> Tested-by: Drew Fustini <dfustini@baylibre.com> Link: https://lore.kernel.org/r/20230716001506.3506041-2-guoren@kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: correct riscv_insn_is_c_jr() and riscv_insn_is_c_jalr()Nam Cao1-2/+13
The instructions c.jr and c.jalr must have rs1 != 0, but riscv_insn_is_c_jr() and riscv_insn_is_c_jalr() do not check for this. So, riscv_insn_is_c_jr() can match a reserved encoding, while riscv_insn_is_c_jalr() can match the c.ebreak instruction. Rewrite them with check for rs1 != 0. Signed-off-by: Nam Cao <namcaov@gmail.com> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com> Fixes: ec5f90877516 ("RISC-V: Move riscv_insn_is_* macros into a common header") Link: https://lore.kernel.org/r/20230731183925.152145-1-namcaov@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-16riscv: entry: set a0 = -ENOSYS only when syscall != -1Celeste Liu1-3/+3
When we test seccomp with 6.4 kernel, we found errno has wrong value. If we deny NETLINK_AUDIT with EAFNOSUPPORT, after f0bddf50586d, we will get ENOSYS instead. We got same result with commit 9c2598d43510 ("riscv: entry: Save a0 prior syscall_enter_from_user_mode()"). After analysing code, we think that regs->a0 = -ENOSYS should only be executed when syscall != -1. In __seccomp_filter, when seccomp rejected this syscall with specified errno, they will set a0 to return number as syscall ABI, and then return -1. This return number is finally pass as return number of syscall_enter_from_user_mode, and then is compared with NR_syscalls after converted to ulong (so it will be ULONG_MAX). The condition syscall < NR_syscalls will always be false, so regs->a0 = -ENOSYS is always executed. It covered a0 set by seccomp, so we always get ENOSYS when match seccomp RET_ERRNO rule. Fixes: f0bddf50586d ("riscv: entry: Convert to generic entry") Reported-by: Felix Yan <felixonmars@archlinux.org> Co-developed-by: Ruizhe Pan <c141028@gmail.com> Signed-off-by: Ruizhe Pan <c141028@gmail.com> Co-developed-by: Shiqi Zhang <shiqi@isrc.iscas.ac.cn> Signed-off-by: Shiqi Zhang <shiqi@isrc.iscas.ac.cn> Signed-off-by: Celeste Liu <CoelacanthusHex@gmail.com> Tested-by: Felix Yan <felixonmars@archlinux.org> Tested-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Reviewed-by: Björn Töpel <bjorn@rivosinc.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20230801141607.435192-1-CoelacanthusHex@gmail.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-15riscv: dts: starfive: fix jh7110 qspi sort orderConor Dooley1-19/+19
Emil pointed out that "13010000 sorts after 12070000". Reshuffle the entries to be in-order. Reported-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-15Merge tag 'sunxi-dt-for-6.6-2' of ↵Arnd Bergmann1-0/+34
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt - Add D1 CAN controller nodes * tag 'sunxi-dt-for-6.6-2' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: riscv: dts: allwinner: d1: Add CAN controller nodes Link: https://lore.kernel.org/r/ZNjRV0kJ7v7+DAH5@wens.tw Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-08-15Merge tag 'riscv-dt-for-v6.6' of ↵Arnd Bergmann6-2/+872
https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux into soc/dt RISC-V Devicetrees for v6.6 StarFive: There's only StarFive stuff this time around, starting with some bindings to get clock ID defines out of the binding headers. Getting these (and the syscon bindings) in unblocked a swathe of stuff sitting on the list. Added are: new clock controllers and sycons, ethernet support, thermal sensors, USB and PCIe PHYs, hwrng, mmc and a few more besides for the VisionFive v2. The original VisionFive and BeagleV Starlight got some the thermal sensor support too, as that is supported by the same driver. These changes make the board actually usable with something other than an initramfs. Overlay support by way of the -@ flag set during dtb building, is added also. Signed-off-by: Conor Dooley <conor.dooley@microchip.com> * tag 'riscv-dt-for-v6.6' of https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux: (26 commits) riscv: dts: starfive: jh7110: Fix GMAC configuration riscv: dts: starfive - Add hwrng node for JH7110 SoC riscv: dts: starfive - Add crypto and DMA node for JH7110 riscv: dts: starfive: Add mmc nodes on VisionFive 2 board riscv: dts: starfive: enable DCDC1&ALDO4 node in axp15060 riscv: dts: starfive: Add QSPI controller node for StarFive JH7110 SoC riscv: dts: starfive: jh7110: add the node and pins configuration for tdm riscv: dts: starfive: jh7110: add dma controller node riscv: dts: starfive: Add spi node and pins configuration riscv: dts: starfive: Add USB dts node for JH7110 riscv: dts: starfive: Add USB and PCIe PHY nodes for JH7110 riscv: dts: starfive: jh7110: Add temperature sensor node and thermal-zones riscv: dts: starfive: jh7100: Add temperature sensor node and thermal-zones riscv: dts: starfive: visionfive 2: Add configuration of gmac and phy riscv: dts: starfive: jh7110: Add ethernet device nodes riscv: dts: starfive: jh7110: Add PLL clocks source in SYSCRG node riscv: dts: starfive: jh7110: Add syscon nodes riscv: dts: starfive: jh7110: Add STGCRG/ISPCRG/VOUTCRG nodes riscv: dts: starfive: jh7110: Add DVP and HDMI TX pixel external clocks dt-bindings: clock: Add StarFive JH7110 Video-Output clock and reset generator ... Link: https://lore.kernel.org/r/20230813-naturist-fragment-ac7d10c453ba@spud Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-08-13riscv: dts: starfive: jh7110: Fix GMAC configurationSamin Guo1-4/+4
Fixed configuration to improve the speed of TCP RX. Before: # iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.1.4, port 47604 [ 5] local 192.168.1.3 port 5201 connected to 192.168.1.4 port 47612 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 36.3 MBytes 305 Mbits/sec [ 5] 1.00-2.00 sec 35.6 MBytes 299 Mbits/sec [ 5] 2.00-3.00 sec 36.5 MBytes 306 Mbits/sec [ 5] 3.00-4.00 sec 36.5 MBytes 306 Mbits/sec [ 5] 4.00-5.00 sec 35.7 MBytes 300 Mbits/sec [ 5] 5.00-6.00 sec 35.4 MBytes 297 Mbits/sec [ 5] 6.00-7.00 sec 37.1 MBytes 311 Mbits/sec [ 5] 7.00-8.00 sec 35.6 MBytes 298 Mbits/sec [ 5] 8.00-9.00 sec 36.4 MBytes 305 Mbits/sec [ 5] 9.00-10.00 sec 36.3 MBytes 304 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 361 MBytes 303 Mbits/sec receiver After: # iperf3 -s ----------------------------------------------------------- Server listening on 5201 (test #1) ----------------------------------------------------------- Accepted connection from 192.168.1.4, port 47710 [ 5] local 192.168.1.3 port 5201 connected to 192.168.1.4 port 47720 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 932 Mbits/sec [ 5] 1.00-2.00 sec 111 MBytes 934 Mbits/sec [ 5] 2.00-3.00 sec 111 MBytes 934 Mbits/sec [ 5] 3.00-4.00 sec 111 MBytes 934 Mbits/sec [ 5] 4.00-5.00 sec 111 MBytes 934 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 935 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 934 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 935 Mbits/sec [ 5] 8.00-9.00 sec 111 MBytes 934 Mbits/sec [ 5] 9.00-10.00 sec 111 MBytes 934 Mbits/sec [ 5] 10.00-10.00 sec 167 KBytes 933 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.09 GBytes 934 Mbits/sec receiver Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Samin Guo <samin.guo@starfivetech.com> Fixes: 1ff166c97972 ("riscv: dts: starfive: jh7110: Add ethernet device nodes") Reviewed-by: Emil Renner Berthing <emil.renner.berthing@canonical.com> [conor: converted to decimal per emil's request] Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-13riscv: dts: allwinner: d1: Add CAN controller nodesJohn Watts1-0/+34
The Allwinner D1, T113 provide two CAN controllers that are variants of the R40 controller. I have tested support for these controllers on two boards: - A Lichee Panel RV 86 Panel running a D1 chip - A Mango Pi MQ Dual running a T113-s3 chip Both of these fully support both CAN controllers. Signed-off-by: John Watts <contact@jookia.org> Link: https://lore.kernel.org/r/20230807191952.2019208-1-contact@jookia.org Signed-off-by: Chen-Yu Tsai <wens@csie.org>
2023-08-12Merge tag 'sunxi-dt-for-6.6-1' of ↵Arnd Bergmann1-0/+10
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into soc/dt - Add D1 GPADC node - Introduce support for OrangePi Zero 3 SBC - Enable DT overlay support for Allwinner H3 boards * tag 'sunxi-dt-for-6.6-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: arm: dts: Enable device-tree overlay support for sun8i-h3 pi devices arm64: dts: allwinner: h616: Add OrangePi Zero 3 board support dt-bindings: arm: sunxi: document Orange Pi Zero 3 board name arm64: dts: allwinner: h616: Split Orange Pi Zero 2 DT riscv: dts: allwinner: d1: Add GPADC node Link: https://lore.kernel.org/r/20230806180546.GA127039@jernej-laptop Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-08-12Merge tag 'renesas-dts-for-v6.6-tag1' of ↵Arnd Bergmann1-0/+2
git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into soc/dt Renesas DTS updates for v6.6 - Add Clocked Serial Interface (CSI) support for the RZ/V2M SoC, - Add PMIC, RTC, and PWM support for the RZ/G2L, RZ/G2LC, and RZ/V2L SMARC EVK development boards, - Add PWM (MTU3a) support for the RZ/G2UL and RZ/Five SoCs, - Add External interrupt (INTC-EX) support for the R-Car S4-8 SoC, - Add LED support for the Spider development board, - Miscellaneous fixes and improvements. * tag 'renesas-dts-for-v6.6-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel: arm64: dts: renesas: spider-cpu: Add GP LEDs arm64: dts: renesas: r8a779f0: Add INTC-EX node arm64: dts: renesas: rzg2ul-smarc: Add support for enabling MTU3 arm64: dts: renesas: r9a07g043: Add MTU3a node ARM dts: renesas: armadillo800eva: Switch to enable-gpios arm64: dts: renesas: rzg2lc-smarc-som: Enable PMIC and built-in RTC arm64: dts: renesas: rzg2lc-smarc-som: Add PHY interrupt support for ETH0 riscv: dts: renesas: Clean up dtbs_check W=1 warning due to empty phy node arm64: dts: renesas: rzg2lc-smarc: Add support for enabling MTU3 arm64: dts: renesas: rzg2l-smarc: Add support for enabling MTU3 arm64: dts: renesas: Add missing space before { ARM: dts: renesas: Add missing space before { arm64: dts: renesas: Minor whitespace cleanup around '=' arm64: dts: renesas: rzg2l-smarc-som: Enable PMIC and built-in RTC arm64: dts: renesas: r9a09g011: Add CSI nodes arm64: dts: renesas: rzg2l: Fix txdv-skew-psec typos arm64: dts: renesas: rzg2l: Update overfow/underflow IRQ names for MTU3 channels Link: https://lore.kernel.org/r/cover.1690545144.git.geert+renesas@glider.be Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2023-08-11Merge tag 'riscv-for-linus-6.5-rc6' of ↵Linus Torvalds9-21/+35
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - Fixes for a pair of kexec_file_load() failures - A fix to ensure the direct mapping is PMD-aligned - A fix for CPU feature detection on SMP=n - The MMIO ordering fences have been strengthened to ensure ordering WRT delay() - Fixes for a pair of -Wmissing-variable-declarations warnings - A fix to avoid PUD mappings in vmap on sv39 - flush_cache_vmap() now flushes the TLB to avoid issues on systems that cache invalid mappings * tag 'riscv-for-linus-6.5-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: riscv: Implement flush_cache_vmap() riscv: Do not allow vmap pud mappings for 3-level page table riscv: mm: fix 2 instances of -Wmissing-variable-declarations riscv,mmio: Fix readX()-to-delay() ordering riscv: Fix CPU feature detection with SMP disabled riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping riscv/kexec: load initrd high in available memory riscv/kexec: handle R_RISCV_CALL_PLT relocation type
2023-08-11Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/netJakub Kicinski3-3/+5
Cross-merge networking fixes after downstream PR. No conflicts. Adjacent changes: drivers/net/ethernet/intel/igc/igc_main.c 06b412589eef ("igc: Add lock to safeguard global Qbv variables") d3750076d464 ("igc: Add TransmissionOverrun counter") drivers/net/ethernet/microsoft/mana/mana_en.c a7dfeda6fdec ("net: mana: Fix MANA VF unload when hardware is unresponsive") a9ca9f9ceff3 ("page_pool: split types and declarations from page_pool.h") 92272ec4107e ("eth: add missing xdp.h includes in drivers") net/mptcp/protocol.h 511b90e39250 ("mptcp: fix disconnect vs accept race") b8dc6d6ce931 ("mptcp: fix rcv buffer auto-tuning") tools/testing/selftests/net/mptcp/mptcp_join.sh c8c101ae390a ("selftests: mptcp: join: fix 'implicit EP' test") 03668c65d153 ("selftests: mptcp: join: rework detailed report") Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2023-08-10riscv: Implement flush_cache_vmap()Alexandre Ghiti1-0/+4
The RISC-V kernel needs a sfence.vma after a page table modification: we used to rely on the vmalloc fault handling to emit an sfence.vma, but commit 7d3332be011e ("riscv: mm: Pre-allocate PGD entries for vmalloc/modules area") got rid of this path for 64-bit kernels, so now we need to explicitly emit a sfence.vma in flush_cache_vmap(). Note that we don't need to implement flush_cache_vunmap() as the generic code should emit a flush tlb after unmapping a vmalloc region. Fixes: 7d3332be011e ("riscv: mm: Pre-allocate PGD entries for vmalloc/modules area") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230725132246.817726-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-10riscv: Do not allow vmap pud mappings for 3-level page tableAlexandre Ghiti1-1/+3
The vmalloc_fault() path was removed and to avoid syncing the vmalloc PGD mappings, they are now preallocated. But if the kernel can use a PUD mapping (which in sv39 is actually a PGD mapping) for large vmalloc allocation, it will free the current unused preallocated PGD mapping and install a new leaf one. Since there is no sync anymore, some page tables lack this new mapping and that triggers a panic. So only allow PUD mappings for sv48 and sv57. Fixes: 7d3332be011e ("riscv: mm: Pre-allocate PGD entries for vmalloc/modules area") Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Link: https://lore.kernel.org/r/20230808130709.1502614-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-09riscv: dts: starfive - Add hwrng node for JH7110 SoCJia Jie Ho1-0/+10
Add hardware rng controller node for StarFive JH7110 SoC. Co-developed-by: Jenny Zhang <jenny.zhang@starfivetech.com> Signed-off-by: Jenny Zhang <jenny.zhang@starfivetech.com> Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-09riscv: dts: starfive - Add crypto and DMA node for JH7110Jia Jie Ho1-0/+27
Add hardware crypto module and dedicated dma controller node to StarFive JH7110 SoC. Co-developed-by: Huan Feng <huan.feng@starfivetech.com> Signed-off-by: Huan Feng <huan.feng@starfivetech.com> Signed-off-by: Jia Jie Ho <jiajie.ho@starfivetech.com> Acked-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-09riscv: dts: starfive: Add mmc nodes on VisionFive 2 boardWilliam Qiu2-0/+128
Add the mmc nodes for the StarFive JH7110 SoC. Set mmc0 node to emmc and set mmc1 node to sd. Signed-off-by: William Qiu <william.qiu@starfivetech.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-09riscv: dts: starfive: enable DCDC1&ALDO4 node in axp15060William Qiu1-0/+16
Enable DCDC1 node for vmmc-supply and enable ALDO4 node for vqmmc-supply. Signed-off-by: William Qiu <william.qiu@starfivetech.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-09KVM: riscv: Add KVM_GET_REG_LIST API supportHaibo Xu3-0/+387
KVM_GET_REG_LIST API will return all registers that are available to KVM_GET/SET_ONE_REG APIs. It's very useful to identify some platform regression issue during VM migration. Since this API was already supported on arm64, it is straightforward to enable it on riscv with similar code structure. Signed-off-by: Haibo Xu <haibo1.xu@intel.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-09riscv: mm: fix 2 instances of -Wmissing-variable-declarationsNick Desaulniers3-5/+7
I'm looking to enable -Wmissing-variable-declarations behind W=1. 0day bot spotted the following instance in ARCH=riscv builds: arch/riscv/mm/init.c:276:7: warning: no previous extern declaration for non-static variable 'trampoline_pg_dir' [-Wmissing-variable-declarations] 276 | pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss; | ^ arch/riscv/mm/init.c:276:1: note: declare 'static' if the variable is not intended to be used outside of this translation unit 276 | pgd_t trampoline_pg_dir[PTRS_PER_PGD] __page_aligned_bss; | ^ arch/riscv/mm/init.c:279:7: warning: no previous extern declaration for non-static variable 'early_pg_dir' [-Wmissing-variable-declarations] 279 | pgd_t early_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE); | ^ arch/riscv/mm/init.c:279:1: note: declare 'static' if the variable is not intended to be used outside of this translation unit 279 | pgd_t early_pg_dir[PTRS_PER_PGD] __initdata __aligned(PAGE_SIZE); | ^ These symbols are referenced by more than one translation unit, so make sure they're both declared and include the correct header for their declarations. Finally, sort the list of includes to help keep them tidy. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/llvm/202308081000.tTL1ElTr-lkp@intel.com/ Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20230808-riscv_static-v2-1-2a1e2d2c7a4f@google.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-09riscv,mmio: Fix readX()-to-delay() orderingAndrea Parri1-8/+8
Section 2.1 of the Platform Specification [1] states: Unless otherwise specified by a given I/O device, I/O devices are on ordering channel 0 (i.e., they are point-to-point strongly ordered). which is not sufficient to guarantee that a readX() by a hart completes before a subsequent delay() on the same hart (cf. memory-barriers.txt, "Kernel I/O barrier effects"). Set the I(nput) bit in __io_ar() to restore the ordering, align inline comments. [1] https://github.com/riscv/riscv-platform-specs Signed-off-by: Andrea Parri <parri.andrea@gmail.com> Link: https://lore.kernel.org/r/20230803042738.5937-1-parri.andrea@gmail.com Fixes: fab957c11efe ("RISC-V: Atomic and Locking Code") Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-09riscv: Fix CPU feature detection with SMP disabledSamuel Holland2-5/+5
commit 914d6f44fc50 ("RISC-V: only iterate over possible CPUs in ISA string parser") changed riscv_fill_hwcap() from iterating over CPU DT nodes to iterating over logical CPU IDs. Since this function runs long before cpu_dev_init() creates CPU devices, it hits the fallback path in of_cpu_device_node_get(), which itself iterates over the DT nodes, searching for a node with the requested CPU ID. (Incidentally, this makes riscv_fill_hwcap() now take quadratic time.) riscv_fill_hwcap() passes a logical CPU ID to of_cpu_device_node_get(), which uses the arch_match_cpu_phys_id() hook to translate the logical ID to a physical ID as found in the DT. arch_match_cpu_phys_id() has a generic weak definition, and RISC-V provides a strong definition using cpuid_to_hartid_map(). However, the RISC-V specific implementation is located in arch/riscv/kernel/smp.c, and that file is only compiled when SMP is enabled. As a result, when SMP is disabled, the generic definition is used, and riscv_isa gets initialized based on the ISA string of hart 0, not the boot hart. On FU740, this means has_fpu() returns false, and userspace crashes when trying to use floating-point instructions. Fix this by moving arch_match_cpu_phys_id() to a file which is always compiled. Fixes: 70114560b285 ("RISC-V: Add RISC-V specific arch_match_cpu_phys_id") Fixes: 914d6f44fc50 ("RISC-V: only iterate over possible CPUs in ISA string parser") Reported-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Samuel Holland <samuel.holland@sifive.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20230803012608.3540081-1-samuel.holland@sifive.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-08RISC-V: KVM: Improve vector save/restore functionsAndrew Jones3-35/+23
Make two nonfunctional changes to the vector get/set vector reg functions and their supporting function for simplification and readability. The first is to not pass KVM_REG_RISCV_VECTOR, but rather integrate it directly into the masking. The second is to rename reg_val to reg_addr where and address is used instead of a value. Also opportunistically touch up some of the code formatting for a third nonfunctional change. Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Reviewed-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: Improve vector save/restore errorsAndrew Jones1-27/+33
kvm_riscv_vcpu_(get/set)_reg_vector() now returns ENOENT if V is not available, EINVAL if reg type is not of VECTOR type, and any error that might be thrown by kvm_riscv_vcpu_vreg_addr(). Signed-off-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: avoid EBUSY when writing the same isa_ext valDaniel Henrique Barboza1-0/+3
riscv_vcpu_set_isa_ext_single() will prevent any write of isa_ext regs if the vcpu already started spinning. But if there's no extension state (enabled/disabled) made by the userspace, there's no need to -EBUSY out - we can treat the operation as a no-op. zicbom/zicboz_block_size, ISA config reg and mvendorid/march/mimpid already works in a more permissive manner w.r.t userspace writes being a no-op, so let's do the same with isa_ext writes. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: avoid EBUSY when writing the same machine ID valDaniel Henrique Barboza1-0/+6
Right now we do not allow any write in mvendorid/marchid/mimpid if the vcpu already started, preventing these regs to be changed. However, if userspace doesn't change them, an alternative is to consider the reg write a no-op and avoid erroring out altogether. Userpace can then be oblivious about KVM internals if no changes were intended in the first place. Allow the same form of 'lazy writing' that registers such as zicbom/zicboz_block_size supports: avoid erroring out if userspace makes no changes in mvendorid/marchid/mimpid during reg write. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: avoid EBUSY when writing same ISA valDaniel Henrique Barboza1-0/+7
kvm_riscv_vcpu_set_reg_config() will return -EBUSY if the ISA config reg is being written after the VCPU ran at least once. The same restriction isn't placed in kvm_riscv_vcpu_get_reg_config(), so there's a chance that we'll -EBUSY out on an ISA config reg write even if the userspace intended no changes to it. We'll allow the same form of 'lazy writing' that registers such as zicbom/zicboz_block_size supports: avoid erroring out if userspace made no changes to the ISA config reg. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: use EBUSY when !vcpu->arch.ran_atleast_onceDaniel Henrique Barboza1-2/+2
vcpu_set_reg_config() and vcpu_set_reg_isa_ext() is throwing an EOPNOTSUPP error when !vcpu->arch.ran_atleast_once. In similar cases we're throwing an EBUSY error, like in mvendorid/marchid/mimpid set_reg(). EOPNOTSUPP has a conotation of finality. EBUSY is more adequate in this case since its a condition/error related to the vcpu lifecycle. Change these EOPNOTSUPP instances to EBUSY. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: do not EOPNOTSUPP in set KVM_REG_RISCV_TIMER_REGDaniel Henrique Barboza1-1/+2
The KVM_REG_RISCV_TIMER_REG can be read via get_one_reg(). But trying to write anything in this reg via set_one_reg() results in an EOPNOTSUPP. Change the API to behave like cbom_block_size: instead of always erroring out with EOPNOTSUPP, allow userspace to write the same value (riscv_timebase) back, throwing an EINVAL if a different value is attempted. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: do not EOPNOTSUPP in set_one_reg() zicbo(m|z)Daniel Henrique Barboza1-2/+10
zicbom_block_size and zicboz_block_size have a peculiar API: they can be read via get_one_reg() but any write will return a EOPNOTSUPP. It makes sense to return a 'not supported' error since both values can't be changed, but as far as userspace goes they're regs that are throwing the same EOPNOTSUPP error even if they were read beforehand via get_one_reg(), even if the same read value is being written back. EOPNOTSUPP is also returned even if ZICBOM/ZICBOZ aren't enabled in the host. Change both to work more like their counterparts in get_one_reg() and return -ENOENT if their respective extensions aren't available. After that, check if the userspace is written a valid value (i.e. the host value). Throw an -EINVAL if that's not case, let it slide otherwise. This allows both regs to be read/written by userspace in a 'lazy' manner, as long as the userspace doesn't change the reg vals. Suggested-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: use ENOENT in *_one_reg() when extension is unavailableDaniel Henrique Barboza1-3/+3
Following a similar logic as the previous patch let's minimize the EINVAL usage in *_one_reg() APIs by using ENOENT when an extension that implements the reg is not available. For consistency we're also replacing an EOPNOTSUPP instance that should be an ENOENT since it's an "extension is not available" error. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: return ENOENT in *_one_reg() when reg is unknownDaniel Henrique Barboza5-37/+39
get_one_reg() and set_one_reg() are returning EINVAL errors for almost everything: if a reg doesn't exist, if a reg ID is malformatted, if the associated CPU extension that implements the reg isn't present in the host, and for set_one_reg() if the value being written is invalid. This isn't wrong according to the existing KVM API docs (EINVAL can be used when there's no such register) but adding more ENOENT instances will make easier for userspace to understand what went wrong. Existing userspaces can be affected by this error code change. We checked a few. As of current upstream code, crosvm doesn't check for any particular errno code when using kvm_(get|set)_one_reg(). Neither does QEMU. rust-vmm doesn't have kvm-riscv support yet. Thus we have a good chance of changing these error codes now while the KVM RISC-V ecosystem is still new, minimizing user impact. Change all get_one_reg() and set_one_reg() implementations to return -ENOENT at all "no such register" cases. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: provide UAPI for host SATP modeDaniel Henrique Barboza3-0/+10
KVM userspaces need to be aware of the host SATP to allow them to advertise it back to the guest OS. Since this information is used to build the guest FDT we can't wait for the SATP reg to be readable. We just need to read the SATP mode, thus we can use the existing 'satp_mode' global that represents the SATP reg with MODE set and both ASID and PPN cleared. E.g. for a 32 bit host running with sv32 satp_mode is 0x80000000, for a 64 bit host running sv57 satp_mode is 0xa000000000000000, and so on. Add a new userspace virtual config register 'satp_mode' to allow userspace to read the current SATP mode the host is using with GET_ONE_REG API before spinning the vcpu. 'satp_mode' can't be changed via KVM, so SET_ONE_REG is allowed as long as userspace writes the existing 'satp_mode'. Signed-off-by: Daniel Henrique Barboza <dbarboza@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: Sort ISA extensions alphabetically in ONE_REG interfaceAnup Patel1-6/+7
Let us sort isa extensions alphabetically in kvm_isa_ext_arr[] and kvm_riscv_vcpu_isa_disable_allowed() so that future insertions are more predictable. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: Allow Zicntr, Zicsr, Zifencei, and Zihpm for Guest/VMAnup Patel2-0/+12
We extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable Zicntr, Zicsr, Zifencei, and Zihpm extensions for Guest/VM. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: Allow Zba and Zbs extensions for Guest/VMAnup Patel2-0/+6
We extend the KVM ISA extension ONE_REG interface to allow KVM user space to detect and enable Zba and Zbs extensions for Guest/VM. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: Extend ONE_REG to enable/disable multiple ISA extensionsAnup Patel2-29/+133
Currently, the ISA extension ONE_REG interface only allows enabling or disabling one extension at a time. To improve this, we extend the ISA extension ONE_REG interface (similar to SBI extension ONE_REG interface) so that KVM user space can enable/disable multiple extensions in one ioctl. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-08RISC-V: KVM: Factor-out ONE_REG related code to its own source fileAnup Patel4-528/+556
The VCPU ONE_REG interface has grown over time and it will continue to grow with new ISA extensions and other features. Let us move all ONE_REG related code to its own source file so that vcpu.c only focuses only on high-level VCPU functions. Signed-off-by: Anup Patel <apatel@ventanamicro.com> Reviewed-by: Andrew Jones <ajones@ventanamicro.com> Signed-off-by: Anup Patel <anup@brainfault.org>
2023-08-07Revert "riscv: dts: allwinner: d1: Add CAN controller nodes"Marc Kleine-Budde1-30/+0
It turned out the dtsi changes were not quite ready, revert them for now. This reverts commit 6ea1ad888f5900953a21853e709fa499fdfcb317. Link: https://lore.kernel.org/all/2690764.mvXUDI8C0e@jernej-laptop Suggested-by: Jernej Škrabec <jernej.skrabec@gmail.com> Link: https://lore.kernel.org/all/20230807-riscv-allwinner-d1-revert-can-controller-nodes-v1-1-eb3f70b435d9@pengutronix.de Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
2023-08-05riscv: dts: starfive: Add QSPI controller node for StarFive JH7110 SoCWilliam Qiu2-0/+55
Add the quad spi controller node for the StarFive JH7110 SoC. Co-developed-by: Ziv Xu <ziv.xu@starfivetech.com> Signed-off-by: Ziv Xu <ziv.xu@starfivetech.com> Signed-off-by: William Qiu <william.qiu@starfivetech.com> Reviewed-by: Hal Feng <hal.feng@starfivetech.com> Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
2023-08-05Merge tag 'riscv-for-linus-6.5-rc5' of ↵Linus Torvalds3-3/+5
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux Pull RISC-V fixes from Palmer Dabbelt: - A pair of fixes for build-related failures in the selftests - A fix for a sparse warning in acpi_os_ioremap() - A fix to restore the kernel PA offset in vmcoreinfo, to fix crash handling * tag 'riscv-for-linus-6.5-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux: Documentation: kdump: Add va_kernel_pa_offset for RISCV64 riscv: Export va_kernel_pa_offset in vmcoreinfo RISC-V: ACPI: Fix acpi_os_ioremap to return iomem address selftests: riscv: Fix compilation error with vstate_exec_nolibc.c selftests/riscv: fix potential build failure during the "emit_tests" step
2023-08-04riscv: Start of DRAM should at least be aligned on PMD size for the direct ↵Alexandre Ghiti1-1/+6
mapping So that we do not end up mapping the whole linear mapping using 4K pages, which is slow at boot time, and also very likely at runtime. So make sure we align the start of DRAM on a PMD boundary. Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Reported-by: Song Shuai <suagrfillet@gmail.com> Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") Tested-by: Song Shuai <suagrfillet@gmail.com> Link: https://lore.kernel.org/r/20230704121837.248976-1-alexghiti@rivosinc.com Cc: stable@vger.kernel.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-08-04Merge patch series "RISC-V: Fix a few kexec_file_load(2) failures"Palmer Dabbelt1-1/+2
Petr Tesarik <petrtesarik@huaweicloud.com> says: From: Petr Tesarik <petr.tesarik.ext@huawei.com> The kexec_file_load(2) syscall does not work at least in some kernel builds. For details see the relevant section in this blog post: https://sigillatum.tesarici.cz/2023-07-21-state-of-riscv64-kdump.html This patch series handles an additional relocation types, removes the need to implement a Global Offset Table (GOT) for the purgatory and fixes the placement of initrd. * b4-shazam-merge: riscv/kexec: load initrd high in available memory riscv/kexec: handle R_RISCV_CALL_PLT relocation type Link: https://lore.kernel.org/r/cover.1690365011.git.petr.tesarik.ext@huawei.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>