* [PATCH] riscv: dts: spacemit: k1-musepi-pro: add cpu scaling
From: Andre Heider @ 2026-06-14 12:28 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <20260612-shadow-deps-v3-0-2f3ba88611ff@mailbox.org>
Enable CPU DVFS by including the OPP table and wiring the CPU nodes to the
CPU regulator supply.
Signed-off-by: Andre Heider <a.heider@gmail.com>
---
.../riscv/boot/dts/spacemit/k1-musepi-pro.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts b/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
index 0d809e4ad3b1..1b425011f123 100644
--- a/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-musepi-pro.dts
@@ -9,6 +9,7 @@
#include "k1.dtsi"
#include "k1-pinctrl.dtsi"
+#include "k1-opp.dtsi"
/ {
model = "SpacemiT MusePi Pro";
@@ -99,6 +100,38 @@ &combo_phy {
status = "okay";
};
+&cpu_0 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_1 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_2 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_3 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_4 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_5 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_6 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_7 {
+ cpu-supply = <&buck1_0v9>;
+};
+
ð0 {
phy-handle = <&rgmii0>;
phy-mode = "rgmii-id";
@@ -178,7 +211,7 @@ pmic@41 {
dldoin2-supply = <&buck5>;
regulators {
- buck1 {
+ buck1_0v9: buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
--
2.53.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* [GIT PULL] KVM/riscv changes for 7.2
From: Anup Patel @ 2026-06-14 9:49 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Palmer Dabbelt, Paul Walmsley, Andrew Jones, Atish Patra,
KVM RISC-V (KVM/riscv), KVM General, linux-riscv
Hi Paolo,
We have the following KVM RISC-V changes for 7.2:
1) Batch G-stage TLB flushes for GPA range based page table updates
2) Convert HGEI line management to fully per-HART
3) Speed up dirty logging write faults using MMU rwlock and atomic
PTE updates for permission-only changes
4) Use flexible array for APLIC IRQ state
5) FWFT fixes for missing CSR dirty marking and stale feature
exposure to Guest/VM
6) Fix logging enable check on a memslot by using
kvm_slot_dirty_track_enabled()
7) Fixes to avoid skipping valid pages in kvm_riscv_gstage_wp_range()
and kvm_riscv_gstage_unmap_range()
Please pull.
Regards,
Anup
The following changes since commit e7ae89a0c97ce2b68b0983cd01eda67cf373517d:
Linux 7.1-rc5 (2026-05-24 13:48:06 -0700)
are available in the Git repository at:
https://github.com/kvm-riscv/linux.git tags/kvm-riscv-7.2-1
for you to fetch changes up to 52738352a6f29279e15285fcb7b50241ef867e27:
riscv: kvm: Use endian-specific __lelong for NACL shared memory
(2026-06-14 11:09:41 +0530)
----------------------------------------------------------------
KVM/riscv changes for 7.2
- Batch G-stage TLB flushes for GPA range based page table updates
- Convert HGEI line management to fully per-HART
- Fix missing CSR dirty marking when FWFT state updated via ONE_REG
- Fix stale FWFT feature exposure to Guest/VM
- Speed up dirty logging write faults using MMU rwlock and atomic
PTE updates using cmpxchg() for permission-only changes
- Use flexible array for APLIC IRQ state
- Use kvm_slot_dirty_track_enabled() for logging enable check on
a memslot
- Avoid skipping valid pages in kvm_riscv_gstage_wp_range()
- Avoid skipping valid pages in kvm_riscv_gstage_unmap_range()
- Use endian-specific __lelong for NACL shared memory
----------------------------------------------------------------
Guo Ren (Alibaba DAMO Academy) (2):
irqchip/riscv-imsic: Add nr_guest_files in per-HART local config
RISC-V: KVM: AIA: Make HGEI number management fully per-CPU
Inochi Amaoto (1):
RISC-V: KVM: Enhance the logging check for mmu mapping
Jiakai Xu (2):
RISC-V: KVM: Document a TOCTOU race in SBI system suspend handler
RISC-V: KVM: Fix NULL pointer dereference in AIA IMSIC functions
Jinyu Tang (8):
RISC-V: KVM: Batch stage-2 TLB flushes
KVM: riscv: Rely on common MMU notifier locking
KVM: riscv: Use an rwlock for mmu_lock
KVM: riscv: Add a G-stage PTE cmpxchg helper
KVM: riscv: Update G-stage PTE permissions atomically
KVM: riscv: Fast-path dirty logging write faults
KVM: riscv: Check hugetlb block mappings against memslot bounds
KVM: selftests: Add a hugetlb memslot alignment test mode
Mayuresh Chitale (1):
RISC-V: KVM: Fix ebreak self test failure
Qiang Ma (1):
RISC-V: KVM: Fix timer state restore
Rosen Penev (1):
RISC-V: KVM: Use flexible array for APLIC IRQ state
Sean Chang (1):
riscv: kvm: Use endian-specific __lelong for NACL shared memory
Wu Fei (2):
RISC-V: KVM: Fix skip of valid pages in kvm_riscv_gstage_wp_range
RISC-V: KVM: Fix skip of valid pages in kvm_riscv_gstage_unmap_range
Yong-Xuan Wang (5):
KVM: RISC-V: SBI FWFT: Mark vCPU CSRs dirty after setting feature value
KVM: RISC-V: SBI FWFT: Add optional init() callback for hardware probing
KVM: RISC-V: SBI FWFT: Fix stale feature exposure after runtime
extension changes
KVM: riscv: selftests: Refactor ISA and SBI extension sublist macros
KVM: riscv: selftests: Split SBI FWFT into separate
feature-specific sublists
arch/riscv/include/asm/kvm_aia.h | 2 +-
arch/riscv/include/asm/kvm_gstage.h | 10 +-
arch/riscv/include/asm/kvm_host.h | 2 +
arch/riscv/include/asm/kvm_nacl.h | 14 +-
arch/riscv/include/asm/uaccess.h | 2 +-
arch/riscv/kvm/aia.c | 88 +++++----
arch/riscv/kvm/aia_aplic.c | 15 +-
arch/riscv/kvm/aia_device.c | 4 +-
arch/riscv/kvm/aia_imsic.c | 9 +
arch/riscv/kvm/gstage.c | 100 ++++++----
arch/riscv/kvm/main.c | 8 +-
arch/riscv/kvm/mmu.c | 211 ++++++++++++++++++----
arch/riscv/kvm/nacl.c | 2 +-
arch/riscv/kvm/vcpu.c | 1 +
arch/riscv/kvm/vcpu_sbi_fwft.c | 44 ++++-
arch/riscv/kvm/vcpu_sbi_system.c | 14 ++
arch/riscv/kvm/vcpu_timer.c | 2 +-
drivers/irqchip/irq-riscv-imsic-state.c | 9 +-
include/linux/irqchip/riscv-imsic.h | 5 +-
tools/testing/selftests/kvm/kvm_page_table_test.c | 28 ++-
tools/testing/selftests/kvm/riscv/get-reg-list.c | 138 ++++++++------
21 files changed, 499 insertions(+), 209 deletions(-)
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* [PATCH] riscv: dts: spacemit: orangepi-rv2: Add cpu scaling for K1, SoC
From: Vincent Legoll @ 2026-06-14 6:50 UTC (permalink / raw)
To: Shuwei Wu, Rafael J. Wysocki, Viresh Kumar, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree
In-Reply-To: <20260612-shadow-deps-v3-0-2f3ba88611ff@mailbox.org>
[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]
[RESEND] as I cannot see yesterday's
Hello,
I tested (on OrangePi RV2) the attached patch applied over
spacemit/for-next + Shuwei Wu's V3 series.
This is a copy/paste of Shuwei Wu's work, so I don't know
if I can submit this with my SoB or if it should be done
differently, please advise.
Anyways, you can add my:
Tested-by: Vincent Legoll <vincent.legoll@gmail.com> # OrangePi-RV2
To the relevant patches from your series, if that's useful,
because it looks like it is working properly:
On Void linux (musl libc):
uname -a
Linux opirv2 7.1.0-rc1-00043-gb860bca13be4 #14 SMP PREEMPT Sat Jun 13
11:02:13 CEST 2026 riscv64 GNU/Linux
awk --version | head -1
GNU Awk 5.3.2, API 4.0
echo userspace > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo 1600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m0.300s
user 0m0.299s
sys 0m0.001s
echo 1228800 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m0.432s
user 0m0.429s
sys 0m0.004s
echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m0.476s
user 0m0.476s
sys 0m0.001s
echo 819000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m0.582s
user 0m0.581s
sys 0m0.001s
echo 614400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed
time awk 'BEGIN{for(i=0;i<1000000;i++){}}'
real 0m0.778s
user 0m0.773s
sys 0m0.005s
--
Vincent Legoll
[-- Attachment #2: 0001-riscv-dts-spacemit-orangepi-rv2-Add-cpu-scaling-for-.patch --]
[-- Type: text/x-patch, Size: 1660 bytes --]
From 9924789655ae5f4f98e7a5cdc3df3f34e7bfb659 Mon Sep 17 00:00:00 2001
From: Vincent Legoll <vincent.legoll@gmail.com>
Date: Sat, 13 Jun 2026 10:49:34 +0200
Subject: [PATCH] riscv: dts: spacemit: orangepi-rv2: Add cpu scaling for K1
SoC
Enable CPU DVFS on OrangePi RV2
This is a copy/paste from Shuwei Wu's BPI-F3 DTS modifications
Signed-off-by: Vincent Legoll <vincent.legoll@gmail.com>
---
.../boot/dts/spacemit/k1-orangepi-rv2.dts | 35 ++++++++++++++++++-
1 file changed, 34 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
index 7c49bce427f3..62d25f579af6 100644
--- a/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-orangepi-rv2.dts
@@ -8,6 +8,7 @@
#include "k1.dtsi"
#include "k1-pinctrl.dtsi"
+#include "k1-opp.dtsi"
/ {
model = "OrangePi RV2";
@@ -80,6 +81,38 @@ &combo_phy {
status = "okay";
};
+&cpu_0 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_1 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_2 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_3 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_4 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_5 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_6 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_7 {
+ cpu-supply = <&buck1_0v9>;
+};
+
&emmc {
bus-width = <8>;
mmc-hs400-1_8v;
@@ -162,7 +195,7 @@ pmic@41 {
dldoin2-supply = <&buck5>;
regulators {
- buck1 {
+ buck1_0v9: buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
--
2.54.0
[-- Attachment #3: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* Re: [PATCH v1] riscv: kvm: Use endian-specific __lelong for NACL shared memory
From: Anup Patel @ 2026-06-14 6:00 UTC (permalink / raw)
To: Sean Chang
Cc: Palmer Dabbelt, Atish Patra, Paul Walmsley, Albert Ou,
Alexandre Ghiti, kvm, kvm-riscv, linux-riscv, linux-kernel
In-Reply-To: <20260608155252.4292-1-seanwascoding@gmail.com>
On Mon, Jun 8, 2026 at 9:22 PM Sean Chang <seanwascoding@gmail.com> wrote:
>
> When compiling with sparse enabled (C=2), bitwise type warnings are
> triggered in the RISC-V KVM implementation. This occurs because the
> user-space data unboxing macro '__get_user_asm' performs implicit
> casting on restricted types without forcing the compiler's compliance.
>
> Additionally, raw 'unsigned long *' pointers are used to access the
> SBI NACL shared memory, whereas the RISC-V SBI specification mandates
> that these structures must follow little-endian byte ordering.
>
> Fix these by:
> 1. Adding a '__force' cast to '__get_user_asm()' to safely suppress
> implicit cast warnings during user-space data fetching.
> 2. Introducing the '__lelong' type macro, which dynamically resolves to
> '__le32' or '__le64' depending on XLEN, and replacing 'unsigned long *'
> with '__lelong *' to enforce proper compile-time endianness checks.
>
> Signed-off-by: Sean Chang <seanwascoding@gmail.com>
LGTM.
Reviewed-by: Anup Patel <anup@brainfault.org>
Queued this patch for Linux-7.2
Thanks,
Anup
> ---
> arch/riscv/include/asm/kvm_nacl.h | 14 ++++++++------
> arch/riscv/include/asm/uaccess.h | 2 +-
> arch/riscv/kvm/nacl.c | 2 +-
> 3 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/riscv/include/asm/kvm_nacl.h b/arch/riscv/include/asm/kvm_nacl.h
> index 4124d5e06a0f..f45407bcaa26 100644
> --- a/arch/riscv/include/asm/kvm_nacl.h
> +++ b/arch/riscv/include/asm/kvm_nacl.h
> @@ -60,9 +60,11 @@ int kvm_riscv_nacl_init(void);
> #ifdef CONFIG_32BIT
> #define lelong_to_cpu(__x) le32_to_cpu(__x)
> #define cpu_to_lelong(__x) cpu_to_le32(__x)
> +#define __lelong __le32
> #else
> #define lelong_to_cpu(__x) le64_to_cpu(__x)
> #define cpu_to_lelong(__x) cpu_to_le64(__x)
> +#define __lelong __le64
> #endif
>
> #define nacl_shmem() \
> @@ -70,7 +72,7 @@ int kvm_riscv_nacl_init(void);
>
> #define nacl_scratch_read_long(__shmem, __offset) \
> ({ \
> - unsigned long *__p = (__shmem) + \
> + __lelong *__p = (__shmem) + \
> SBI_NACL_SHMEM_SCRATCH_OFFSET + \
> (__offset); \
> lelong_to_cpu(*__p); \
> @@ -78,7 +80,7 @@ int kvm_riscv_nacl_init(void);
>
> #define nacl_scratch_write_long(__shmem, __offset, __val) \
> do { \
> - unsigned long *__p = (__shmem) + \
> + __lelong *__p = (__shmem) + \
> SBI_NACL_SHMEM_SCRATCH_OFFSET + \
> (__offset); \
> *__p = cpu_to_lelong(__val); \
> @@ -87,7 +89,7 @@ do { \
> #define nacl_scratch_write_longs(__shmem, __offset, __array, __count) \
> do { \
> unsigned int __i; \
> - unsigned long *__p = (__shmem) + \
> + __lelong *__p = (__shmem) + \
> SBI_NACL_SHMEM_SCRATCH_OFFSET + \
> (__offset); \
> for (__i = 0; __i < (__count); __i++) \
> @@ -168,7 +170,7 @@ __kvm_riscv_nacl_hfence(__shmem, \
>
> #define nacl_csr_read(__shmem, __csr) \
> ({ \
> - unsigned long *__a = (__shmem) + SBI_NACL_SHMEM_CSR_OFFSET; \
> + __lelong *__a = (__shmem) + SBI_NACL_SHMEM_CSR_OFFSET; \
> lelong_to_cpu(__a[SBI_NACL_SHMEM_CSR_INDEX(__csr)]); \
> })
>
> @@ -176,7 +178,7 @@ __kvm_riscv_nacl_hfence(__shmem, \
> do { \
> void *__s = (__shmem); \
> unsigned int __i = SBI_NACL_SHMEM_CSR_INDEX(__csr); \
> - unsigned long *__a = (__s) + SBI_NACL_SHMEM_CSR_OFFSET; \
> + __lelong *__a = (__s) + SBI_NACL_SHMEM_CSR_OFFSET; \
> u8 *__b = (__s) + SBI_NACL_SHMEM_DBITMAP_OFFSET; \
> __a[__i] = cpu_to_lelong(__val); \
> __b[__i >> 3] |= 1U << (__i & 0x7); \
> @@ -186,7 +188,7 @@ do { \
> ({ \
> void *__s = (__shmem); \
> unsigned int __i = SBI_NACL_SHMEM_CSR_INDEX(__csr); \
> - unsigned long *__a = (__s) + SBI_NACL_SHMEM_CSR_OFFSET; \
> + __lelong *__a = (__s) + SBI_NACL_SHMEM_CSR_OFFSET; \
> u8 *__b = (__s) + SBI_NACL_SHMEM_DBITMAP_OFFSET; \
> unsigned long __r = lelong_to_cpu(__a[__i]); \
> __a[__i] = cpu_to_lelong(__val); \
> diff --git a/arch/riscv/include/asm/uaccess.h b/arch/riscv/include/asm/uaccess.h
> index 11c9886c3b70..5d4ec15584cf 100644
> --- a/arch/riscv/include/asm/uaccess.h
> +++ b/arch/riscv/include/asm/uaccess.h
> @@ -112,7 +112,7 @@ do { \
> _ASM_EXTABLE_UACCESS_ERR(1b, %l2, %0) \
> : "=&r" (__tmp) \
> : "m" (*(ptr)) : : label); \
> - (x) = (__typeof__(x))(unsigned long)__tmp; \
> + (x) = (__force __typeof__(x))(unsigned long)__tmp; \
> } while (0)
> #else /* !CONFIG_CC_HAS_ASM_GOTO_OUTPUT */
> #define __get_user_asm(insn, x, ptr, label) \
> diff --git a/arch/riscv/kvm/nacl.c b/arch/riscv/kvm/nacl.c
> index 08a95ad9ada2..6f9f8963e9dd 100644
> --- a/arch/riscv/kvm/nacl.c
> +++ b/arch/riscv/kvm/nacl.c
> @@ -20,7 +20,7 @@ void __kvm_riscv_nacl_hfence(void *shmem,
> unsigned long page_count)
> {
> int i, ent = -1, try_count = 5;
> - unsigned long *entp;
> + __lelong *entp;
>
> again:
> for (i = 0; i < SBI_NACL_SHMEM_HFENCE_ENTRY_MAX; i++) {
> --
> 2.43.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [GIT PULL] canaan clk changes for 7.2
From: Stephen Boyd @ 2026-06-13 21:52 UTC (permalink / raw)
To: Conor Dooley
Cc: linux-clk, Michael Turquette, conor, Troy Mitchell, Xukai Wang,
linux-riscv
In-Reply-To: <20260602-latitude-unroasted-d88074ae2ebc@spud>
Quoting Conor Dooley (2026-06-02 02:09:42)
> Hey Stephen,
>
> Please pull the addition of a new driver for the Canaan k230 SoC.
>
> It's been on the list for quite a while, with minimal feedback received
> on recent versions, so I figured I'd grab it and send a PR so that I can
> merge the rest of the SoC support for 7.2. It's been in linux-next for
> about two weeks with no issues that I am aware of.
>
> Thanks,
> Conor.
>
>
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/conor/linux.git/ clk-canaan-7.2
>
> for you to fetch changes up to a7b7c7c6c01679efef0fd2f2ca1c5114f303e4f5:
>
> clk: canaan: Add clock driver for Canaan K230 (2026-05-22 17:13:10 +0100)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [GIT PULL] clk: spacemit: Updates for v7.2
From: Stephen Boyd @ 2026-06-13 21:55 UTC (permalink / raw)
To: Yixun Lan
Cc: Yixun Lan, Michael Turquette, Inochi Amaoto, linux-clk, spacemit,
linux-riscv, linux-kernel
In-Reply-To: <20260609052422-KYC4837748@kernel.org>
Quoting Yixun Lan (2026-06-08 22:28:09)
> From: Yixun Lan <dlan@gentoo.org>
>
> Hi Stephen,
>
> Please pull SpacemiT's clock changes for v7.2
> All clock changes are related to PCIe for K3 SoC.
> Hope this isn't too late..
>
> Yixun Lan
>
> The following changes since commit 254f49634ee16a731174d2ae34bc50bd5f45e731:
>
> Linux 7.1-rc1 (2026-04-26 14:19:00 -0700)
>
> are available in the Git repository at:
>
> https://github.com/spacemit-com/linux spacemit-clk-for-7.2-1
>
> for you to fetch changes up to a37c75d7b5bb7f3344b0e639b313ac5ace6244ff:
>
> clk: spacemit: k3: Add PCIe DBI clock (2026-06-02 07:16:59 +0000)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v4 3/3] ARM: dts: sunxi: add support for NetCube Systems OpenNMC (dobermann)
From: Jernej Škrabec @ 2026-06-13 11:04 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai,
Samuel Holland, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Maxime Ripard, Lukas Schmid
Cc: Lukas Schmid, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv
In-Reply-To: <20260606205452.2386930-4-lukas.schmid@netcube.li>
Dne sobota, 6. junij 2026 ob 22:54:43 Srednjeevropski poletni čas je Lukas Schmid napisal(a):
> NetCube Systems OpenNMC is an open replacement for APC SmartSlot Management
> Cards. It is based on the Nagami System-on-Module. It breaks out the
> following interfaces:
>
> - 10/100 Mbps Ethernet
> - USB Type-C OTG using a TUSB320 (usb0)
> - USB Type-C Console Port using a CH340 (uart3)
> - USB Type-A Host with internal CH334 USB-Hub (usb1)
> - MicroSD Slot with Card-Detect (mmc0)
> - WiFi/Bluetooth using the modules built-in ESP32
> - SmartSlot serial interface (uart4)
> - DS3232 RTC with CR1220 Battery Backup
> - Extension connector providing SPI,I2C,USB,CAN,UART for future use.
>
> Signed-off-by: Lukas Schmid <lukas.schmid@netcube.li>
DT Check passes, so:
Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
Best regards,
Jernej
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH net-next v8 3/6] net: stmmac: eic7700: make RGMII delay properties optional
From: Andrew Lunn @ 2026-06-13 7:48 UTC (permalink / raw)
To: Maxime Chevallier
Cc: lizhi2, devicetree, andrew+netdev, davem, edumazet, kuba, robh,
krzk+dt, conor+dt, netdev, pabeni, mcoquelin.stm32,
alexandre.torgue, rmk+kernel, pjw, palmer, aou, alex, linux-riscv,
linux-stm32, linux-arm-kernel, linux-kernel, ningyu, linmin,
pinkesh.vaghela, pritesh.patel, weishangjuan, horms, lee
In-Reply-To: <eaa645fc-be06-4a15-8c2f-6e82129c4715@bootlin.com>
On Wed, Jun 10, 2026 at 10:26:50AM +0200, Maxime Chevallier wrote:
> Hi,
>
> On 6/10/26 03:29, lizhi2@eswincomputing.com wrote:
> > From: Zhi Li <lizhi2@eswincomputing.com>
> >
> > Make rx-internal-delay-ps and tx-internal-delay-ps optional in the
> > EIC7700 DWMAC driver.
> >
> > The driver previously required both properties to be present and would
> > fail probe when they were missing. This restricts valid hardware
> > configurations where RGMII timing is instead provided by the PHY or
> > board design.
> >
> > Update the driver to treat missing delay properties as zero delay,
> > allowing systems without explicit MAC-side delay tuning to operate
> > correctly.
> >
> > This aligns the driver behavior with the updated device tree binding
> > and provides a safe default configuration when MAC-side delay
> > programming is not required.
> >
> > Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> > ---
> > drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c | 6 ------
> > 1 file changed, 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > index 4ac979d874d6..ec99b597aeaf 100644
> > --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-eic7700.c
> > @@ -165,9 +165,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> > dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_RX_ADJ_DELAY;
> > dwc_priv->eth_clk_dly_param |=
> > FIELD_PREP(EIC7700_ETH_RX_ADJ_DELAY, val);
> > - } else {
> > - return dev_err_probe(&pdev->dev, -EINVAL,
> > - "missing required property rx-internal-delay-ps\n");
> > }
> >
> > /* Read tx-internal-delay-ps and update tx_clk delay */
> > @@ -187,9 +184,6 @@ static int eic7700_dwmac_probe(struct platform_device *pdev)
> > dwc_priv->eth_clk_dly_param &= ~EIC7700_ETH_TX_ADJ_DELAY;
> > dwc_priv->eth_clk_dly_param |=
> > FIELD_PREP(EIC7700_ETH_TX_ADJ_DELAY, val);
> > - } else {
> > - return dev_err_probe(&pdev->dev, -EINVAL,
> > - "missing required property tx-internal-delay-ps\n");
> > }
>
> I think then you need to handle RGMII, RGMII_ID, RGMII_RXID and RGMII_TXID,
> by using default delays for these (usually around 2ns), as here all delays
> will be set to 0, regardless of the RGMII mode in use.
No. By default, the MAC adds 0ns delay, and passes the phy-mode to the
PHY. It will then add the 2ns delay. It is possible to use the
tx-internal-delay-ps and rx-internal-delay-ps in the MAC to add small
tuning delays, but not the full 2ns.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/devicetree/bindings/net/ethernet-controller.yaml#L287
Andrew
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH] riscv: hwprobe: Avoid uninitialized read in hwprobe_get_cpus()
From: Nam Cao @ 2026-06-12 21:50 UTC (permalink / raw)
To: Mark Harris, Paul Walmsley, Palmer Dabbelt, Albert Ou
Cc: Alexandre Ghiti, Mark Harris, linux-riscv, linux-kernel
In-Reply-To: <20260612045502.70850-1-mark.hsj@gmail.com>
Mark Harris <mark.hsj@gmail.com> writes:
> When cpusetsize < cpumask_size(), hwprobe_get_cpus() did not fully
> initialize its copy of the cpu mask, which could cause non-deterministic
> results from the riscv_hwprobe syscall on a system with more than 8 CPUs
> when the supplied cpu mask is empty. Address this by fully initializing
> the cpu mask.
>
> Signed-off-by: Mark Harris <mark.hsj@gmail.com>
Reviewed-by: Nam Cao <namcao@linutronix.de>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH] riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
From: Nam Cao @ 2026-06-12 21:23 UTC (permalink / raw)
To: Anirudh Srinivasan, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Andrew Jones
Cc: linux-riscv, linux-kernel, andrew.jones, ganboing,
Anirudh Srinivasan
In-Reply-To: <20260612-vec_unaligned_drop_init-v1-1-df969210ae34@oss.tenstorrent.com>
Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com> writes:
> This function runs within a kthread and need not necessarily finish
> before system finishes boot and free_initmem() unmaps the .init.text
> section. This function makes calls to SBI for probing unaligned access
> speed, and if this is slow for some reason (say some debug prints were
> added to SBI), the kthread can still be running at this point and result
> in an instruction page fault when trying to fetch from the freed region.
...
> Drop __init from its signature so that this doesn't happen.
That should work.
But we should really take a step back and reconsider whether running the
vector access speed probe in a kthread is really a good idea.
We have a problem in the past that the kthread may not complete before
user reads vdso, and user gets incorrect values. That was addressed by
5d15d2ad36b0 ("riscv: hwprobe: Fix stale vDSO data for late-initialized
keys at boot") which complicates things.
And now you discover another issue.
The motivation for using a kthread is to avoid boot time slow down. But
this has been bothering me for quite a while now, because I am not sure
if using kthread really speeds things up. Sooner or later, the kthread
has to run. If it runs before the kernel is done booting, then the boot
is even slower due to overhead of the kthread. If it runs after the
kernel finishes booting, then we run into these kinds of
headache. Unfortunately I do not have a riscv cpu with vector to confirm
my suspicion.
Furthermore, the vector access speed probe takes the same amount of time
as scalar access speed probe. The scalar one is done without any
kthread, and no one ever complained about boot time issue (well, someone
did complain but that has nothing to do with kthread. Their 64-core (?)
system is slower because the probe was done serially, and we switched to
parallel probe and it was fine).
So I think we should really get rid of that kthread entirely, the
headache is not worth. That also allows reverting 5d15d2ad36b0 ("riscv:
hwprobe: Fix stale vDSO data for late-initialized keys at boot"), making
the code simplier.
Below is a patch that has only been tested with qemu. It reverts the
mentioned commit and removes the kthread.
diff --git a/arch/riscv/include/asm/hwprobe.h b/arch/riscv/include/asm/hwprobe.h
index 8c572a464719..2f278c395af9 100644
--- a/arch/riscv/include/asm/hwprobe.h
+++ b/arch/riscv/include/asm/hwprobe.h
@@ -42,11 +42,4 @@ static inline bool riscv_hwprobe_pair_cmp(struct riscv_hwprobe *pair,
return pair->value == other_pair->value;
}
-#ifdef CONFIG_MMU
-void riscv_hwprobe_register_async_probe(void);
-void riscv_hwprobe_complete_async_probe(void);
-#else
-static inline void riscv_hwprobe_register_async_probe(void) {}
-static inline void riscv_hwprobe_complete_async_probe(void) {}
-#endif
#endif
diff --git a/arch/riscv/include/asm/vdso/arch_data.h b/arch/riscv/include/asm/vdso/arch_data.h
index 88b37af55175..da57a3786f7a 100644
--- a/arch/riscv/include/asm/vdso/arch_data.h
+++ b/arch/riscv/include/asm/vdso/arch_data.h
@@ -12,12 +12,6 @@ struct vdso_arch_data {
/* Boolean indicating all CPUs have the same static hwprobe values. */
__u8 homogeneous_cpus;
-
- /*
- * A gate to check and see if the hwprobe data is actually ready, as
- * probing is deferred to avoid boot slowdowns.
- */
- __u8 ready;
};
#endif /* __RISCV_ASM_VDSO_ARCH_DATA_H */
diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
index 0f701ace3bb9..f3ed4fd396fb 100644
--- a/arch/riscv/kernel/sys_hwprobe.c
+++ b/arch/riscv/kernel/sys_hwprobe.c
@@ -5,9 +5,6 @@
* more details.
*/
#include <linux/syscalls.h>
-#include <linux/completion.h>
-#include <linux/atomic.h>
-#include <linux/once.h>
#include <asm/cacheflush.h>
#include <asm/cpufeature.h>
#include <asm/hwprobe.h>
@@ -470,32 +467,28 @@ static int hwprobe_get_cpus(struct riscv_hwprobe __user *pairs,
return 0;
}
-#ifdef CONFIG_MMU
-
-static DECLARE_COMPLETION(boot_probes_done);
-static atomic_t pending_boot_probes = ATOMIC_INIT(1);
-
-void riscv_hwprobe_register_async_probe(void)
+static int do_riscv_hwprobe(struct riscv_hwprobe __user *pairs,
+ size_t pair_count, size_t cpusetsize,
+ unsigned long __user *cpus_user,
+ unsigned int flags)
{
- atomic_inc(&pending_boot_probes);
-}
+ if (flags & RISCV_HWPROBE_WHICH_CPUS)
+ return hwprobe_get_cpus(pairs, pair_count, cpusetsize,
+ cpus_user, flags);
-void riscv_hwprobe_complete_async_probe(void)
-{
- if (atomic_dec_and_test(&pending_boot_probes))
- complete(&boot_probes_done);
+ return hwprobe_get_values(pairs, pair_count, cpusetsize,
+ cpus_user, flags);
}
-static int complete_hwprobe_vdso_data(void)
+#ifdef CONFIG_MMU
+
+static int __init init_hwprobe_vdso_data(void)
{
struct vdso_arch_data *avd = vdso_k_arch_data;
u64 id_bitsmash = 0;
struct riscv_hwprobe pair;
int key;
- if (unlikely(!atomic_dec_and_test(&pending_boot_probes)))
- wait_for_completion(&boot_probes_done);
-
/*
* Initialize vDSO data with the answers for the "all CPUs" case, to
* save a syscall in the common case.
@@ -523,52 +516,13 @@ static int complete_hwprobe_vdso_data(void)
* vDSO should defer to the kernel for exotic cpu masks.
*/
avd->homogeneous_cpus = id_bitsmash != 0 && id_bitsmash != -1;
-
- /*
- * Make sure all the VDSO values are visible before we look at them.
- * This pairs with the implicit "no speculativly visible accesses"
- * barrier in the VDSO hwprobe code.
- */
- smp_wmb();
- avd->ready = true;
- return 0;
-}
-
-static int __init init_hwprobe_vdso_data(void)
-{
- struct vdso_arch_data *avd = vdso_k_arch_data;
-
- /*
- * Prevent the vDSO cached values from being used, as they're not ready
- * yet.
- */
- avd->ready = false;
return 0;
}
arch_initcall_sync(init_hwprobe_vdso_data);
-#else
-
-static int complete_hwprobe_vdso_data(void) { return 0; }
-
#endif /* CONFIG_MMU */
-static int do_riscv_hwprobe(struct riscv_hwprobe __user *pairs,
- size_t pair_count, size_t cpusetsize,
- unsigned long __user *cpus_user,
- unsigned int flags)
-{
- DO_ONCE_SLEEPABLE(complete_hwprobe_vdso_data);
-
- if (flags & RISCV_HWPROBE_WHICH_CPUS)
- return hwprobe_get_cpus(pairs, pair_count, cpusetsize,
- cpus_user, flags);
-
- return hwprobe_get_values(pairs, pair_count, cpusetsize,
- cpus_user, flags);
-}
-
SYSCALL_DEFINE5(riscv_hwprobe, struct riscv_hwprobe __user *, pairs,
size_t, pair_count, size_t, cpusetsize, unsigned long __user *,
cpus, unsigned int, flags)
diff --git a/arch/riscv/kernel/unaligned_access_speed.c b/arch/riscv/kernel/unaligned_access_speed.c
index 70b5e6927620..6a725eee5acd 100644
--- a/arch/riscv/kernel/unaligned_access_speed.c
+++ b/arch/riscv/kernel/unaligned_access_speed.c
@@ -375,19 +375,6 @@ static void check_vector_unaligned_access(struct work_struct *work __always_unus
__free_pages(page, MISALIGNED_BUFFER_ORDER);
}
-/* Measure unaligned access speed on all CPUs present at boot in parallel. */
-static int __init vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
-{
- schedule_on_each_cpu(check_vector_unaligned_access);
- riscv_hwprobe_complete_async_probe();
-
- return 0;
-}
-#else /* CONFIG_RISCV_PROBE_VECTOR_UNALIGNED_ACCESS */
-static int __init vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
-{
- return 0;
-}
#endif
static int riscv_online_cpu_vec(unsigned int cpu)
@@ -474,12 +461,7 @@ static int __init check_unaligned_access_all_cpus(void)
per_cpu(vector_misaligned_access, cpu) = unaligned_vector_speed_param;
} else if (!check_vector_unaligned_access_emulated_all_cpus() &&
IS_ENABLED(CONFIG_RISCV_PROBE_VECTOR_UNALIGNED_ACCESS)) {
- riscv_hwprobe_register_async_probe();
- if (IS_ERR(kthread_run(vec_check_unaligned_access_speed_all_cpus,
- NULL, "vec_check_unaligned_access_speed_all_cpus"))) {
- pr_warn("Failed to create vec_unalign_check kthread\n");
- riscv_hwprobe_complete_async_probe();
- }
+ schedule_on_each_cpu(check_vector_unaligned_access);
}
/*
diff --git a/arch/riscv/kernel/vdso/hwprobe.c b/arch/riscv/kernel/vdso/hwprobe.c
index 8f45500d0a6e..2ddeba6c68dd 100644
--- a/arch/riscv/kernel/vdso/hwprobe.c
+++ b/arch/riscv/kernel/vdso/hwprobe.c
@@ -27,7 +27,7 @@ static int riscv_vdso_get_values(struct riscv_hwprobe *pairs, size_t pair_count,
* homogeneous, then this function can handle requests for arbitrary
* masks.
*/
- if (flags != 0 || (!all_cpus && !avd->homogeneous_cpus) || unlikely(!avd->ready))
+ if ((flags != 0) || (!all_cpus && !avd->homogeneous_cpus))
return riscv_hwprobe(pairs, pair_count, cpusetsize, cpus, flags);
/* This is something we can handle, fill out the pairs. */
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* riscv: Heads up: If 7.1 hangs on boot near "vector unaligned word access speed"
From: Vivian Wang @ 2026-06-12 18:36 UTC (permalink / raw)
To: linux-riscv, linux-kernel
Hi Linux 7.1 on riscv users,
If you get boot hangs and/or panics near where the kernel says:
cpuN: vector unaligned word access speed is 0.01x byte access speed (slow)
Possibly with additional messages such as these:
sbi_trap_error: hart1: trap1: load fault handler failed (error -3)
sbi_trap_error: hart1: trap1: store fault handler failed (error -3)
[ 0.252142] Oops - instruction access fault [#1]
You're likely running into a now exposed OpenSBI stack overrun bug in
misaligned vector access emulation.
As a quick fix, apply this patch to OpenSBI 1.7 or 1.8 to increase the
stack size:
https://lore.kernel.org/opensbi/edbce78c-71a7-41d7-aa81-3fa57241644a@iscas.ac.cn
What happened?
--------------
Commit b69bcb13ed70 ("riscv: misaligned: Make enabling delegation depend
on NONPORTABLE") made it so that the in-kernel misaligned access
emulation handler is disabled for now, since it is very
feature-incomplete and crashes KVM guests, and userspace and kernel
vector users.
However, this means that the firmware emulation is now in use, which
exposed this latent issue. It turns out the vector misaligned access
handler uses a 8192-byte stack buffer, whereas the entire per-hart stack
in OpenSBI defaults to 8192 bytes. This is a straightforward stack
overrun and either crashes OpenSBI or worse, causes it to misbehave and
creating further errors.
Currently, I believe it is the right thing to ask affected users to fix
their OpenSBI, since as far as I can find, no generally available
hardware ships with the affected OpenSBI versions (specifically, 1.7+
with stack size 8192), neither as factory default nor as separately
provided by the vendor. All possible cases I've been able to gather
affect either in-development platforms, or boards where the user has
replaced their firmware to have new OpenSBI (e.g. SpacemiT K1).
What do I do now?
-----------------
Apply that patch and replace your firmware's OpenSBI, probably the same
way you put it there in the first place. If you can't or don't know how,
please get in touch.
If it is convenient for you, I would appreciate if anyone who runs into
this can get in touch with me if you haven't done so. Feedback from
affected users on how to proceed is appreciated.
Also possible check out previous discussions:
- https://lore.kernel.org/linux-riscv/nrvt74qnojaubiwjo37ums4lnclu466hovwrhmtbag6f5uhrql@q6msoe2oto4b/T
- https://lore.kernel.org/opensbi/edbce78c-71a7-41d7-aa81-3fa57241644a@iscas.ac.cn/T
Furthermore, there is work in progress to make the vector misaligned
access handler not to use so much stack, thanks to Bo Gan:
- https://lore.kernel.org/opensbi/20260609060024.706-1-ganboing@gmail.com/
Thanks and with apologies,
Vivian "dramforever" Wang
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH net-next v8 1/6] dt-bindings: ethernet: eswin: relax internal delay model to range-based constraints
From: Rob Herring (Arm) @ 2026-06-12 16:28 UTC (permalink / raw)
To: lizhi2
Cc: pritesh.patel, linux-stm32, devicetree, edumazet,
linux-arm-kernel, pjw, pabeni, weishangjuan, linux-riscv, ningyu,
krzk+dt, pinkesh.vaghela, linux-kernel, alex, andrew+netdev,
alexandre.torgue, kuba, aou, horms, mcoquelin.stm32, conor+dt,
netdev, rmk+kernel, palmer, lee, maxime.chevallier, linmin, davem
In-Reply-To: <20260610012849.874-1-lizhi2@eswincomputing.com>
On Wed, 10 Jun 2026 09:28:49 +0800, lizhi2@eswincomputing.com wrote:
> From: Zhi Li <lizhi2@eswincomputing.com>
>
> Relax internal delay constraints for EIC7700 Ethernet binding.
>
> Replace fixed enumeration of rx-internal-delay-ps and tx-internal-delay-ps
> with a range-based definition (0-2540 ps, 20 ps steps) to reflect actual
> hardware capability.
>
> Mark rx/tx internal delay properties as optional, as they are board-
> specific tuning parameters rather than mandatory configuration.
>
> Update the device tree example to align with the relaxed constraint model
> and remove delay properties from the example to avoid implying they are
> required.
>
> No functional change to existing DT users.
>
> Signed-off-by: Zhi Li <lizhi2@eswincomputing.com>
> ---
> .../bindings/net/eswin,eic7700-eth.yaml | 25 ++++++++++---------
> 1 file changed, 13 insertions(+), 12 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* [PATCH] riscv: drop __init from vec_check_unaligned_access_speed_all_cpus
From: Anirudh Srinivasan @ 2026-06-12 16:24 UTC (permalink / raw)
To: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Andrew Jones
Cc: linux-riscv, linux-kernel, andrew.jones, ganboing,
Anirudh Srinivasan
This function runs within a kthread and need not necessarily finish
before system finishes boot and free_initmem() unmaps the .init.text
section. This function makes calls to SBI for probing unaligned access
speed, and if this is slow for some reason (say some debug prints were
added to SBI), the kthread can still be running at this point and result
in an instruction page fault when trying to fetch from the freed region.
[ 25.642087] Unable to handle kernel paging request at virtual address ffffffff80a04ef8
[ 25.646694] Current vec_check_unali pgtable: 4K pagesize, 48-bit VAs, pgdp=0x00004000316e9000
[ 25.653170] [ffffffff80a04ef8] pgd=000010004be7e401, p4d=000010004be7e401, pud=000010004be7e001, pmd=000010000c3000e3
[ 25.661244] Oops [#1]
[ 25.662997] Modules linked in:
[ 25.665357] CPU: 3 UID: 0 PID: 42 Comm: vec_check_unali Not tainted 7.0.0-tt-blackhole-asrinivasan-00007-g30ff73f18211 #570 PREEMPTLAZY
[ 25.674669] Hardware name: Tenstorrent Blackhole (DT)
[ 25.678545] epc : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.683458] ra : vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.688372] epc : ffffffff80a04ef8 ra : ffffffff80a04ef8 sp : ffff8f8000203e20
[ 25.693874] gp : ffffffff814dc168 tp : ffffaf8001ad9900 t0 : 0000000000000000
[ 25.699401] t1 : fffffffffffffff0 t2 : ffffaf8001ad9a10 s0 : ffff8f8000203e30
[ 25.704912] s1 : ffffaf80018dc780 a0 : 0000000000000000 a1 : 0000000000000002
[ 25.710407] a2 : 00000000000001f0 a3 : 0000000000000018 a4 : 0000000000000000
[ 25.715917] a5 : 0000000000000000 a6 : ffffaf8001c03d98 a7 : ffffaf8001c03e30
[ 25.721419] s2 : ffff8f8000023c98 s3 : ffffaf8001aa1240 s4 : ffffffff80a04ee0
[ 25.726937] s5 : 0000000000000000 s6 : 0000000000000000 s7 : 0000000000000000
[ 25.732450] s8 : 0000000000000000 s9 : 0000000000000000 s10: 0000000000000000
[ 25.737944] s11: 0000000000000000 t3 : 0000000000000002 t4 : 0000000000000402
[ 25.743481] t5 : 0000000000000040 t6 : 0000000000000004 ssp : 0000000000000000
[ 25.749024] status: 0000000200000120 badaddr: ffffffff80a04ef8 cause: 000000000000000c
[ 25.755060] [<ffffffff80a04ef8>] vec_check_unaligned_access_speed_all_cpus+0x18/0x2c
[ 25.760964] [<ffffffff80047a10>] kthread+0xd8/0xfc
[ 25.764660] [<ffffffff80010c48>] ret_from_fork_kernel+0x18/0x1c4
[ 25.769220] [<ffffffff80895fe6>] ret_from_fork_kernel_asm+0x16/0x18
[ 25.774018] Code: cccc cccc cccc cccc cccc cccc cccc cccc cccc cccc (cccc) cccc
Drop __init from its signature so that this doesn't happen.
Fixes: a00e022be531 ("riscv: Annotate unaligned access init functions")
Signed-off-by: Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
Assisted-by: Claude:claude-opus-4-6
---
arch/riscv/kernel/unaligned_access_speed.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/riscv/kernel/unaligned_access_speed.c b/arch/riscv/kernel/unaligned_access_speed.c
index 485ab1d105d36..366baca73dc27 100644
--- a/arch/riscv/kernel/unaligned_access_speed.c
+++ b/arch/riscv/kernel/unaligned_access_speed.c
@@ -325,7 +325,7 @@ static void check_vector_unaligned_access(struct work_struct *work __always_unus
}
/* Measure unaligned access speed on all CPUs present at boot in parallel. */
-static int __init vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
+static int vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
{
schedule_on_each_cpu(check_vector_unaligned_access);
riscv_hwprobe_complete_async_probe();
@@ -333,7 +333,7 @@ static int __init vec_check_unaligned_access_speed_all_cpus(void *unused __alway
return 0;
}
#else /* CONFIG_RISCV_PROBE_VECTOR_UNALIGNED_ACCESS */
-static int __init vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
+static int vec_check_unaligned_access_speed_all_cpus(void *unused __always_unused)
{
return 0;
}
---
base-commit: 863f9b49d618e02e3ecadeb89ebd39064ba8c2fd
change-id: 20260612-vec_unaligned_drop_init-c7af506a375e
Best regards,
--
Anirudh Srinivasan <asrinivasan@oss.tenstorrent.com>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* RE: [PATCH RFC 0/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Michael Kelley @ 2026-06-12 15:51 UTC (permalink / raw)
To: Jinjie Ruan, catalin.marinas@arm.com, will@kernel.org,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20260611133809.3854977-1-ruanjinjie@huawei.com>
From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
>
> Support for parallel secondary CPU bringup is already utilized by x86,
> MIPS, and RISC-V. This patch brings this capability to the arm64
> architecture.
>
> Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST to avoid primary SMT threads
> to boot first constraint.
>
> And Add a 'cpu' parameter to update_cpu_boot_status() to allow updating the
> boot status at a per-CPU granularity during parallel bringup.
>
> Rework the global `secondary_data` accessed during early boot into
> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
> enabling the early boot code in head.S to resolve each secondary CPU's
> logical ID concurrently.
I tested the series on an ARM64 VM running on Hyper-V in the Azure cloud.
Tested with 16 vCPUs in the VM and with 96 vCPUs in the VM. No issues.
I mainly wanted to make sure nothing expected happened with Hyper-V as
the host.
With 96 vCPUs, the secondary CPU startup time drops from ~140 milliseconds
to ~130 milliseconds. That improvement is not as dramatic as you saw on
QEMU, so I presume the difference is due to the hypervisor implementation
of the PSCI calls.
Tested-by: Michael Kelley <mhklinux@outlook.com>
>
> Jinjie Ruan (3):
> cpu/hotplug: Introduce CONFIG_PARALLEL_SMT_PRIMARY_FIRST
> arm64: smp: Pass CPU ID to update_cpu_boot_status()
> arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
>
> arch/Kconfig | 4 ++++
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/smp.h | 14 +++++++++++---
> arch/arm64/kernel/cpufeature.c | 2 +-
> arch/arm64/kernel/head.S | 23 ++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 35 ++++++++++++++++++++++++++++++----
> arch/arm64/mm/context.c | 2 +-
> arch/mips/Kconfig | 1 +
> arch/riscv/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> kernel/cpu.c | 6 +++++-
> 11 files changed, 80 insertions(+), 10 deletions(-)
>
> --
> 2.34.1
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* RE: [PATCH RFC 3/3] arm64: Add HOTPLUG_PARALLEL support for secondary CPUs
From: Michael Kelley @ 2026-06-12 15:45 UTC (permalink / raw)
To: Jinjie Ruan, catalin.marinas@arm.com, will@kernel.org,
tsbogend@alpha.franken.de, pjw@kernel.org, palmer@dabbelt.com,
aou@eecs.berkeley.edu, alex@ghiti.fr, tglx@kernel.org,
mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com,
hpa@zytor.com, peterz@infradead.org, kees@kernel.org,
nathan@kernel.org, linusw@kernel.org, ojeda@kernel.org,
david.kaplan@amd.com, lukas.bulwahn@redhat.com,
ryan.roberts@arm.com, maz@kernel.org, timothy.hayes@arm.com,
lpieralisi@kernel.org, thuth@redhat.com, oupton@kernel.org,
yeoreum.yun@arm.com, miko.lenczewski@arm.com, broonie@kernel.org,
kevin.brodsky@arm.com, james.clark@linaro.org, tabba@google.com,
mrigendra.chaubey@gmail.com, arnd@arndb.de,
anshuman.khandual@arm.com, x86@kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-mips@vger.kernel.org,
linux-riscv@lists.infradead.org
In-Reply-To: <20260611133809.3854977-4-ruanjinjie@huawei.com>
From: Jinjie Ruan <ruanjinjie@huawei.com> Sent: Thursday, June 11, 2026 6:38 AM
>
> Support for parallel secondary CPU bringup is already utilized by x86,
> MIPS, and RISC-V. This patch brings this capability to the arm64
> architecture.
>
> Rework the global `secondary_data` accessed during early boot into
> a per-CPU array. This array maps logical CPU IDs to MPIDR_EL1 values,
> enabling the early boot code in head.S to resolve each secondary CPU's
> logical ID concurrently.
>
> To fully enable HOTPLUG_PARALLEL, this patch implements:
> 1) An arm64-specific arch_cpuhp_kick_ap_alive() handler.
> 2) Callbacks to cpuhp_ap_sync_alive() inside secondary_start_kernel().
>
> Successfully tested on QEMU ARM64 virt machine (KVM on, 128 vCPUs).
>
> | test kernel | secondary CPUs boot time |
> | --------------------- | -------------------- |
> | Without this patch | 155.672 |
> | cpuhp.parallel=0 | 62.897 |
> | cpuhp.parallel=1 | 166.703 |
The last two rows seem mixed up. I would expect parallel=0 to
result in a longer boot time.
Michael
>
> Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
> ---
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/smp.h | 8 ++++++++
> arch/arm64/kernel/head.S | 23 +++++++++++++++++++++++
> arch/arm64/kernel/smp.c | 27 +++++++++++++++++++++++++++
> 4 files changed, 59 insertions(+)
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v3 00/11] kdump: reduce vmcore size and capture time
From: Rob Herring @ 2026-06-12 14:42 UTC (permalink / raw)
To: Wandun Chen
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, saravanak, akpm, bhe,
rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260527032917.3385849-1-chenwandun1@gmail.com>
On Wed, May 27, 2026 at 11:29:06AM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> On SoCs that carve out large firmware-owned reserved memory (GPU
> firmware, DSP, modem, camera ISP, NPU, ...), kdump currently dumps
> those carveouts as part of system RAM even though their contents are
> firmware state that is not useful for kernel crash analysis.
>
> This series introduces an opt-in 'dumpable' flag [1] on struct
> reserved_mem and uses it to filter the elfcorehdr PT_LOAD ranges on
> DT-based architectures (arm64, riscv, loongarch). By default reserved
> regions are treated as non-dumpable; CMA regions are explicitly opted
> in because their pages are returned to the buddy allocator and may
> carry key crash-analysis data.
>
> The series is organized as follows:
> Patches 1-3: Pre-existing fixes and a small prep change.
> Patches 4-5: Restructure to allow appending /memreserve/ entries.
> Patches 6-7: Add a dumpable flag and append /memreserve/ entries.
> Patch 8: Add generic kdump helpers.
> Patches 9-11: Wire the helpers into arm64, riscv and loongarch kdump
> elfcorehdr preparation.
>
> v2 --> v3:
> 1. Fix out-of-bounds issue if device tree lacks /reserved-memory node.[2]
> 2. Fix UAF issue when alloc_reserved_mem_array() fails.
> 3. Add some prepare patches.
>
> v1 --> v2:
> 1. v1 added an opt-out DT property ('linux,no-dump'). Per Rob's
> feedback [1], v2 drop that property and exclude reserve memory
> by default.
> 2. Split some prepared patches from the original patches.
> 3. Address coding-style comments on patch 5 from Rob.
>
> [1] https://lore.kernel.org/lkml/20260506144542.GA2072596-robh@kernel.org/
> [2] https://sashiko.dev/#/patchset/20260520091844.592753-1-chenwandun%40lixiang.com?part=4
>
> Wandun Chen (11):
> of: reserved_mem: handle NULL name in of_reserved_mem_lookup()
> of: reserved_mem: zero total_reserved_mem_cnt if no valid
> /reserved-memory entry
I applied these 2 for 7.2.
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v3 05/11] of: reserved_mem: split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late()
From: Rob Herring @ 2026-06-12 14:41 UTC (permalink / raw)
To: Wandun Chen
Cc: linux-arm-kernel, linux-kernel, loongarch, linux-riscv,
devicetree, kexec, iommu, zhaomeijing, catalin.marinas, will,
chenhuacai, kernel, pjw, palmer, aou, alex, saravanak, akpm, bhe,
rppt, pasha.tatashin, pratyush, ruirui.yang, m.szyprowski,
robin.murphy, quic_obabatun
In-Reply-To: <20260527032917.3385849-6-chenwandun1@gmail.com>
On Wed, May 27, 2026 at 11:29:11AM +0800, Wandun Chen wrote:
> From: Wandun Chen <chenwandun@lixiang.com>
>
> Prepare for storing /memreserve/ entries in the reserved_mem array.
> alloc_reserved_mem_array is skipped if the device tree lacks a
> /reserved-memory node, pointer 'reserved_mem' continues to reference
> the reserved_mem_array which lives in __initdata, storing
> /memreserve/ entries into reserved_mem_array would result in metadata
> loss, and an out-of-bounds memory access will occur if the device
> tree contains more than MAX_RESERVED_REGIONS /memreserve/ entries.
>
> So split alloc_reserved_mem_array() from fdt_scan_reserved_mem_late(),
> and call alloc_reserved_mem_array() whether or not there is a
> /reserved-memory node.
>
> No functional change.
> The actual /memreserve/ population is added in a follow-up patch.
>
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>
> ---
> drivers/of/fdt.c | 7 +++++--
> drivers/of/of_private.h | 1 +
> drivers/of/of_reserved_mem.c | 6 +-----
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index 82f7327c59ea..83a2a474831e 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1284,8 +1284,11 @@ void __init unflatten_device_tree(void)
> {
> void *fdt = initial_boot_params;
>
> - /* Save the statically-placed regions in the reserved_mem array */
> - fdt_scan_reserved_mem_late();
> + /* Attempt dynamic allocation of a new reserved_mem array */
> + if (fdt && alloc_reserved_mem_array()) {
> + /* Save the statically-placed regions in the reserved_mem array */
> + fdt_scan_reserved_mem_late();
Can we make this just:
alloc_reserved_mem_array();
fdt_scan_reserved_mem_late();
We already check !fdt in fdt_scan_reserved_mem_late().
Rob
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH] mm/page_table_check: do not track special (PFN-mapped) PTEs
From: Thomas Weißschuh @ 2026-06-12 14:24 UTC (permalink / raw)
To: Andrey Smirnov
Cc: pasha.tatashin, akpm, linux-mm, linux-kernel, linux-riscv, pjw,
palmer, aou, alex, syzbot+2b5fe617654be3d8848b, Thomas Gleixner,
Andrei Vagin, Andy Lutomirski, Vincenzo Frascino, stable
In-Reply-To: <20260608155758.1220420-1-andrey.smirnov@siderolabs.com>
On Mon, Jun 08, 2026 at 07:57:58PM +0400, Andrey Smirnov wrote:
> The vDSO data store ("[vvar]") special mapping is created as a VM_PFNMAP
> mapping and its pages are installed into userspace with vmf_insert_pfn(),
> which produces special PTEs (pte_special()). On x86 and arm64 (and riscv)
> pte_user_accessible_page() only tests the PRESENT/USER bits and does not
> exclude special PTEs, so page_table_check accounts these PFN mappings in
> the per-page anon/file map counters even though they are not rmap-managed
> pages (vm_normal_page() returns NULL for them).
>
> Most of these data pages live in the kernel image and are never freed, so
> the stray accounting is invisible. The time-namespace VVAR page is the
> exception: it is a real alloc_page() page that is released with
> __free_page() in free_time_ns() when the last task of a time namespace
> exits. Across the map / unmap / vdso_join_timens() zap transitions the
> special-PTE accounting is not balanced for this page, so a non-zero
> file_map_count survives to the free path and trips:
>
> kernel BUG at mm/page_table_check.c:143!
> __page_table_check_zero+0xfb/0x130
> __free_frozen_pages+0x52f/0x650
> free_time_ns+0x85/0xc0
> free_nsproxy+0x7f/0x130
> do_exit+0x313/0xa60
> do_group_exit+0x77/0x90
>
> This is reliably reproducible on x86_64 and arm64 under heavy container/CI
> churn that rapidly creates and destroys time namespaces (CLONE_NEWTIME via
> runc / docker-init / tini), and was independently reported by syzbot on
> riscv. It only manifests when CONFIG_PAGE_TABLE_CHECK is active.
>
> Special PTEs have no struct-page rmap semantics and must never have been
> tracked by page table check. Skip them in both the set and clear paths so
> the counters stay balanced (always zero) for PFN-mapped pages, regardless
> of how the architecture defines pte_user_accessible_page(). pte_special()
> is available generically (it is a no-op returning false on architectures
> without ARCH_HAS_PTE_SPECIAL), so this is a single, arch-independent fix.
>
> Note that the v7.0 generic vDSO datastore rework in commit 05988dba1179
> ("vdso/datastore: Allocate data pages dynamically") incidentally avoids
> the problem by switching the mapping to VM_MIXEDMAP + vmf_insert_page()
> with balanced struct-page accounting. This patch fixes the still-affected
> VM_PFNMAP path used by 6.18.y and earlier, and additionally makes
> page_table_check robust against any future PFN-mapped user pages.
>
> Fixes: df4e817b7108 ("mm: page table check")
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Cc: Andrei Vagin <avagin@gmail.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>
> Reported-by: syzbot+2b5fe617654be3d8848b@syzkaller.appspotmail.com
> Closes: https://github.com/siderolabs/talos/issues/13496
> Cc: stable@vger.kernel.org
> Signed-off-by: Andrey Smirnov <andrey.smirnov@siderolabs.com>
> ---
> mm/page_table_check.c | 13 ++++++++++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/mm/page_table_check.c b/mm/page_table_check.c
> index 4eeca782b888..ee492d5389b9 100644
> --- a/mm/page_table_check.c
> +++ b/mm/page_table_check.c
> @@ -150,9 +150,16 @@ void __page_table_check_pte_clear(struct mm_struct *mm, pte_t pte)
> if (&init_mm == mm)
> return;
>
> - if (pte_user_accessible_page(pte)) {
> + /*
> + * PFN-mapped (special) PTEs - e.g. the vDSO/time-namespace "[vvar]"
> + * mapping installed via vmf_insert_pfn() - are not rmap-managed and
> + * must not be tracked here. Tracking them can leave a non-zero map
> + * count on a struct page that is later freed (the time namespace VVAR
> + * page in free_time_ns()), tripping the BUG_ON() in
> + * __page_table_check_zero().
As this comment mentioning the [vvar] pages is already stale, IMO this should
not be mentioned specifically. It is also not clear to me why this only happens
now and where the non-zero map count comes from.
> + */
> + if (pte_user_accessible_page(pte) && !pte_special(pte))
> page_table_check_clear(pte_pfn(pte), PAGE_SIZE >> PAGE_SHIFT);
> - }
> }
> EXPORT_SYMBOL(__page_table_check_pte_clear);
>
> @@ -205,7 +212,7 @@ void __page_table_check_ptes_set(struct mm_struct *mm, pte_t *ptep, pte_t pte,
>
> for (i = 0; i < nr; i++)
> __page_table_check_pte_clear(mm, ptep_get(ptep + i));
> - if (pte_user_accessible_page(pte))
> + if (pte_user_accessible_page(pte) && !pte_special(pte))
> page_table_check_set(pte_pfn(pte), nr, pte_write(pte));
> }
> EXPORT_SYMBOL(__page_table_check_ptes_set);
> --
> 2.53.0
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v4 05/16] riscv: Add Zicclsm to cpufeature and hwprobe
From: Jesse Taube @ 2026-06-12 13:51 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Jesse Taube, Conor Dooley, Charlie Jenkins, Andrew Jones,
Andy Chiu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-5-3f01a2449488@gmail.com>
On Thu, Jun 11, 2026 at 4:14 PM Guodong Xu <docular.xu@gmail.com> wrote:
>
> From: Jesse Taube <jesse@rivosinc.com>
>
> Zicclsm requires misaligned support for all regular load and store
> instructions, both scalar and vector, but not AMOs or other
> specialized forms of memory access, to main memory regions with both
> the cacheability and coherence PMAs, as defined in the profiles spec.
> Even though mandated, misaligned loads and stores might execute
> extremely slowly. Standard software distributions should assume their
> existence only for correctness, not for performance.
>
> Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Andy Chiu <andy.chiu@sifive.com>
> Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
> Tested-by: Charlie Jenkins <charlie@rivosinc.com>
> Signed-off-by: Jesse Taube <jesse@rivosinc.com>
Thanks for the update! Just an fyi email has changed to
jtaubepe@redhat.com though.
No need to change the signoff though.
Thanks,
Jesse Taube
> [Rebased, rewrote doc text, minor commit message revisions]
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
>
> ---
> v4: No change.
> v3:
> - Move the hwprobe.rst entry to the IMA_EXT_1 section so its
> documentation matches the IMA_EXT_1 bit it was allocated in v2
> (Sashiko, agreed by Andrew).
> v2:
> - Rebased onto v7.1-rc2; moved ZICCLSM to IMA_EXT_1 and
> allocated a new bit for it
> ---
> Documentation/arch/riscv/hwprobe.rst | 4 ++++
> arch/riscv/include/asm/hwcap.h | 1 +
> arch/riscv/include/uapi/asm/hwprobe.h | 1 +
> arch/riscv/kernel/cpufeature.c | 1 +
> arch/riscv/kernel/sys_hwprobe.c | 1 +
> 5 files changed, 8 insertions(+)
>
> diff --git a/Documentation/arch/riscv/hwprobe.rst b/Documentation/arch/riscv/hwprobe.rst
> index d9928641deb99..49d9fb68632d0 100644
> --- a/Documentation/arch/riscv/hwprobe.rst
> +++ b/Documentation/arch/riscv/hwprobe.rst
> @@ -401,3 +401,7 @@ The following keys are defined:
> as defined in version 1.0 of the RISC-V Control-flow Integrity (CFI)
> extensions specification, ratified in commit 302a2d45c243
> ("Update build-pdf.yml") of riscv-cfi.
> +
> + * :c:macro:`RISCV_HWPROBE_EXT_ZICCLSM`: The Zicclsm extension is supported,
> + as defined in the RISC-V Profiles specification starting from commit
> + b1d80660 ("Updated to ratified state.")
> diff --git a/arch/riscv/include/asm/hwcap.h b/arch/riscv/include/asm/hwcap.h
> index 44bf8c7d8acc5..e8f4a7dd96a93 100644
> --- a/arch/riscv/include/asm/hwcap.h
> +++ b/arch/riscv/include/asm/hwcap.h
> @@ -112,6 +112,7 @@
> #define RISCV_ISA_EXT_ZCLSD 103
> #define RISCV_ISA_EXT_ZICFILP 104
> #define RISCV_ISA_EXT_ZICFISS 105
> +#define RISCV_ISA_EXT_ZICCLSM 106
>
> #define RISCV_ISA_EXT_XLINUXENVCFG 127
>
> diff --git a/arch/riscv/include/uapi/asm/hwprobe.h b/arch/riscv/include/uapi/asm/hwprobe.h
> index 9139edba0aecb..6819df159c51e 100644
> --- a/arch/riscv/include/uapi/asm/hwprobe.h
> +++ b/arch/riscv/include/uapi/asm/hwprobe.h
> @@ -116,6 +116,7 @@ struct riscv_hwprobe {
> #define RISCV_HWPROBE_KEY_ZICBOP_BLOCK_SIZE 15
> #define RISCV_HWPROBE_KEY_IMA_EXT_1 16
> #define RISCV_HWPROBE_EXT_ZICFISS (1ULL << 0)
> +#define RISCV_HWPROBE_EXT_ZICCLSM (1ULL << 1)
>
> /* Increase RISCV_HWPROBE_MAX_KEY when adding items. */
>
> diff --git a/arch/riscv/kernel/cpufeature.c b/arch/riscv/kernel/cpufeature.c
> index 686dde3ce3b98..1fb595581adcf 100644
> --- a/arch/riscv/kernel/cpufeature.c
> +++ b/arch/riscv/kernel/cpufeature.c
> @@ -502,6 +502,7 @@ const struct riscv_isa_ext_data riscv_isa_ext[] = {
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicbom, RISCV_ISA_EXT_ZICBOM, riscv_xlinuxenvcfg_exts, riscv_ext_zicbom_validate),
> __RISCV_ISA_EXT_DATA_VALIDATE(zicbop, RISCV_ISA_EXT_ZICBOP, riscv_ext_zicbop_validate),
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicboz, RISCV_ISA_EXT_ZICBOZ, riscv_xlinuxenvcfg_exts, riscv_ext_zicboz_validate),
> + __RISCV_ISA_EXT_DATA(zicclsm, RISCV_ISA_EXT_ZICCLSM),
> __RISCV_ISA_EXT_DATA(ziccrse, RISCV_ISA_EXT_ZICCRSE),
> __RISCV_ISA_EXT_SUPERSET_VALIDATE(zicfilp, RISCV_ISA_EXT_ZICFILP, riscv_xlinuxenvcfg_exts,
> riscv_cfilp_validate),
> diff --git a/arch/riscv/kernel/sys_hwprobe.c b/arch/riscv/kernel/sys_hwprobe.c
> index f8f68ba781b45..9cf62266f1890 100644
> --- a/arch/riscv/kernel/sys_hwprobe.c
> +++ b/arch/riscv/kernel/sys_hwprobe.c
> @@ -205,6 +205,7 @@ static void hwprobe_isa_ext1(struct riscv_hwprobe *pair,
> * in the hart_isa bitmap, are made.
> */
> EXT_KEY(isainfo->isa, ZICFISS, pair->value, missing);
> + EXT_KEY(isainfo->isa, ZICCLSM, pair->value, missing);
> }
>
> /* Now turn off reporting features if any CPU is missing it. */
>
> --
> 2.43.0
>
>
> _______________________________________________
> linux-riscv mailing list
> linux-riscv@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-riscv
>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* [PATCH v3 2/2] riscv: dts: spacemit: Add cpu scaling for K1 SoC
From: Shuwei Wu @ 2026-06-12 9:51 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260612-shadow-deps-v3-0-2f3ba88611ff@mailbox.org>
Use one shared CPU OPP table for all CPUs and add CPU clock properties
for the two CPU clock clusters.
Enable CPU DVFS on Banana Pi BPI-F3 by including the OPP table and
wiring the CPU nodes to the CPU regulator supply.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v3:
- Use one shared CPU OPP table for all CPUs
Changes in v2:
- Add k1-opp.dtsi with OPP tables for both CPU clusters
- Assign CPU supplies and include OPP table for Banana Pi BPI-F3
---
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 ++++++++++++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 70 +++++++++++++++++++++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 +++
3 files changed, 112 insertions(+), 1 deletion(-)
diff --git a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
index 444c3b1e6f44..81ab5f70176b 100644
--- a/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
+++ b/arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts
@@ -5,6 +5,7 @@
#include "k1.dtsi"
#include "k1-pinctrl.dtsi"
+#include "k1-opp.dtsi"
/ {
model = "Banana Pi BPI-F3";
@@ -86,6 +87,38 @@ &combo_phy {
status = "okay";
};
+&cpu_0 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_1 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_2 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_3 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_4 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_5 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_6 {
+ cpu-supply = <&buck1_0v9>;
+};
+
+&cpu_7 {
+ cpu-supply = <&buck1_0v9>;
+};
+
&emmc {
bus-width = <8>;
mmc-hs400-1_8v;
@@ -201,7 +234,7 @@ pmic@41 {
dldoin2-supply = <&buck5>;
regulators {
- buck1 {
+ buck1_0v9: buck1 {
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <3450000>;
regulator-ramp-delay = <5000>;
diff --git a/arch/riscv/boot/dts/spacemit/k1-opp.dtsi b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
new file mode 100644
index 000000000000..3627812e1344
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k1-opp.dtsi
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/ {
+ cpu_opp_table: opp-table-cpu {
+ compatible = "operating-points-v2";
+ opp-shared;
+
+ opp-614400000 {
+ opp-hz = /bits/ 64 <614400000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-819000000 {
+ opp-hz = /bits/ 64 <819000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1228800000 {
+ opp-hz = /bits/ 64 <1228800000>;
+ opp-microvolt = <950000>;
+ clock-latency-ns = <200000>;
+ };
+
+ opp-1600000000 {
+ opp-hz = /bits/ 64 <1600000000>;
+ opp-microvolt = <1050000>;
+ clock-latency-ns = <200000>;
+ };
+ };
+};
+
+&cpu_0 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_1 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_2 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_3 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_4 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_5 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_6 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
+
+&cpu_7 {
+ operating-points-v2 = <&cpu_opp_table>;
+};
diff --git a/arch/riscv/boot/dts/spacemit/k1.dtsi b/arch/riscv/boot/dts/spacemit/k1.dtsi
index 529ec68e9c23..bdd109b81730 100644
--- a/arch/riscv/boot/dts/spacemit/k1.dtsi
+++ b/arch/riscv/boot/dts/spacemit/k1.dtsi
@@ -54,6 +54,7 @@ cpu_0: cpu@0 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <0>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -84,6 +85,7 @@ cpu_1: cpu@1 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <1>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -114,6 +116,7 @@ cpu_2: cpu@2 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <2>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -144,6 +147,7 @@ cpu_3: cpu@3 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <3>;
+ clocks = <&syscon_apmu CLK_CPU_C0_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -174,6 +178,7 @@ cpu_4: cpu@4 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <4>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -204,6 +209,7 @@ cpu_5: cpu@5 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <5>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -234,6 +240,7 @@ cpu_6: cpu@6 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <6>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
@@ -264,6 +271,7 @@ cpu_7: cpu@7 {
compatible = "spacemit,x60", "riscv";
device_type = "cpu";
reg = <7>;
+ clocks = <&syscon_apmu CLK_CPU_C1_CORE>;
riscv,isa = "rv64imafdcbv_zicbom_zicbop_zicboz_zicntr_zicond_zicsr_zifencei_zihintpause_zihpm_zfh_zba_zbb_zbc_zbs_zkt_zvfh_zvkt_sscofpmf_sstc_svinval_svnapot_svpbmt";
riscv,isa-base = "rv64i";
riscv,isa-extensions = "i", "m", "a", "f", "d", "c", "b", "v", "zicbom",
--
2.53.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* [PATCH v3 1/2] cpufreq: spacemit: Add K1 cpufreq driver
From: Shuwei Wu @ 2026-06-12 9:51 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
In-Reply-To: <20260612-shadow-deps-v3-0-2f3ba88611ff@mailbox.org>
K1 has two CPU cluster clocks but one shared CPU voltage rail. Use one
cpufreq policy for all CPUs, let the OPP core handle the shared regulator
and the cluster0 clock, and update the cluster1 clock explicitly.
Block spacemit,k1 from cpufreq-dt probing when OPP v2 nodes are present,
as K1 needs the dedicated driver for safe transitions.
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v3:
- Add a K1-specific cpufreq driver for the shared-rail, dual-clock topology
- Add spacemit,k1 to the cpufreq-dt blocklist
---
drivers/cpufreq/Kconfig | 4 +
drivers/cpufreq/Kconfig.riscv | 15 ++
drivers/cpufreq/Makefile | 3 +
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
drivers/cpufreq/spacemit-k1-cpufreq.c | 251 ++++++++++++++++++++++++++++++++++
5 files changed, 275 insertions(+)
diff --git a/drivers/cpufreq/Kconfig b/drivers/cpufreq/Kconfig
index 78702a08364f..19bbd1bd2f36 100644
--- a/drivers/cpufreq/Kconfig
+++ b/drivers/cpufreq/Kconfig
@@ -259,6 +259,10 @@ endif
source "drivers/cpufreq/Kconfig.arm"
+if RISCV
+source "drivers/cpufreq/Kconfig.riscv"
+endif
+
if PPC32 || PPC64
source "drivers/cpufreq/Kconfig.powerpc"
endif
diff --git a/drivers/cpufreq/Kconfig.riscv b/drivers/cpufreq/Kconfig.riscv
new file mode 100644
index 000000000000..3d5b59fbcd4c
--- /dev/null
+++ b/drivers/cpufreq/Kconfig.riscv
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0-only
+#
+# RISC-V CPU Frequency scaling drivers
+#
+
+config RISCV_SPACEMIT_K1_CPUFREQ
+ tristate "SpacemiT K1 CPUFreq driver"
+ depends on ARCH_SPACEMIT || COMPILE_TEST
+ depends on OF && COMMON_CLK
+ select PM_OPP
+ help
+ Enable CPU frequency scaling for SpacemiT K1 SoC.
+ K1 has two CPU cluster clocks and one shared CPU voltage rail.
+ The driver keeps all CPUs in one policy and updates both cluster
+ clocks with the shared OPP transition.
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 385c9fcc65c6..9680f420e824 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -89,6 +89,9 @@ obj-$(CONFIG_ARM_TEGRA194_CPUFREQ) += tegra194-cpufreq.o
obj-$(CONFIG_ARM_TI_CPUFREQ) += ti-cpufreq.o
obj-$(CONFIG_ARM_VEXPRESS_SPC_CPUFREQ) += vexpress-spc-cpufreq.o
+##################################################################################
+# RISC-V SoC drivers
+obj-$(CONFIG_RISCV_SPACEMIT_K1_CPUFREQ) += spacemit-k1-cpufreq.o
##################################################################################
# PowerPC platform drivers
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c b/drivers/cpufreq/cpufreq-dt-platdev.c
index 25fd3b191b7e..69bbe739a627 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -185,6 +185,8 @@ static const struct of_device_id blocklist[] __initconst = {
{ .compatible = "qcom,sm8550", },
{ .compatible = "qcom,sm8650", },
+ { .compatible = "spacemit,k1", },
+
{ .compatible = "st,stih407", },
{ .compatible = "st,stih410", },
{ .compatible = "st,stih418", },
diff --git a/drivers/cpufreq/spacemit-k1-cpufreq.c b/drivers/cpufreq/spacemit-k1-cpufreq.c
new file mode 100644
index 000000000000..631897eb8022
--- /dev/null
+++ b/drivers/cpufreq/spacemit-k1-cpufreq.c
@@ -0,0 +1,251 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * CPU frequency scaling driver for SpacemiT K1 SoC.
+ *
+ * Copyright (c) 2026 Shuwei Wu <shuwei.wu@mailbox.org>
+ */
+
+#include <linux/clk.h>
+#include <linux/cpu.h>
+#include <linux/cpufreq.h>
+#include <linux/cpumask.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/pm_opp.h>
+#include <linux/platform_device.h>
+#include <linux/slab.h>
+
+struct k1_cpufreq_priv {
+ struct device *cpu_dev;
+ struct clk *cluster0_clk;
+ struct clk *cluster1_clk;
+ struct cpufreq_frequency_table *freq_table;
+ cpumask_var_t cpus;
+ int opp_token;
+};
+
+static struct platform_device *k1_cpufreq_pdev;
+
+static int k1_cpufreq_set_target(struct cpufreq_policy *policy,
+ unsigned int index)
+{
+ struct k1_cpufreq_priv *priv = policy->driver_data;
+ unsigned long old_freq = policy->cur * 1000UL;
+ unsigned long new_freq = policy->freq_table[index].frequency * 1000UL;
+ int ret;
+
+ if (!old_freq)
+ old_freq = clk_get_rate(priv->cluster0_clk);
+
+ if (new_freq > old_freq) {
+ ret = dev_pm_opp_set_rate(priv->cpu_dev, new_freq);
+ if (ret)
+ return ret;
+
+ ret = clk_set_rate(priv->cluster1_clk, new_freq);
+ if (ret)
+ dev_pm_opp_set_rate(priv->cpu_dev, old_freq);
+
+ return ret;
+ }
+
+ ret = clk_set_rate(priv->cluster1_clk, new_freq);
+ if (ret)
+ return ret;
+
+ ret = dev_pm_opp_set_rate(priv->cpu_dev, new_freq);
+ if (ret)
+ clk_set_rate(priv->cluster1_clk, old_freq);
+
+ return ret;
+}
+
+static int k1_cpufreq_init_policy(struct cpufreq_policy *policy)
+{
+ struct k1_cpufreq_priv *priv = cpufreq_get_driver_data();
+ unsigned int transition_latency;
+
+ cpumask_copy(policy->cpus, priv->cpus);
+ policy->clk = priv->cluster0_clk;
+ policy->freq_table = priv->freq_table;
+ policy->driver_data = priv;
+ policy->dvfs_possible_from_any_cpu = true;
+
+ transition_latency = dev_pm_opp_get_max_transition_latency(priv->cpu_dev);
+ if (!transition_latency)
+ transition_latency = CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS;
+ policy->cpuinfo.transition_latency = transition_latency;
+
+ return 0;
+}
+
+static struct cpufreq_driver k1_cpufreq_driver = {
+ .flags = CPUFREQ_NEED_INITIAL_FREQ_CHECK | CPUFREQ_IS_COOLING_DEV,
+ .verify = cpufreq_generic_frequency_table_verify,
+ .target_index = k1_cpufreq_set_target,
+ .get = cpufreq_generic_get,
+ .init = k1_cpufreq_init_policy,
+ .register_em = cpufreq_register_em_with_opp,
+ .name = "k1-cpufreq",
+};
+
+static int k1_cpufreq_probe(struct platform_device *pdev)
+{
+ struct k1_cpufreq_priv *priv;
+ struct device *cpu4_dev;
+ static const char * const reg_names[] = { "cpu", NULL };
+ int cpu, ret;
+
+ priv = kzalloc_obj(*priv);
+ if (!priv)
+ return -ENOMEM;
+
+ if (!zalloc_cpumask_var(&priv->cpus, GFP_KERNEL)) {
+ ret = -ENOMEM;
+ goto free_data;
+ }
+
+ priv->cpu_dev = get_cpu_device(0);
+ cpu4_dev = get_cpu_device(4);
+ if (!priv->cpu_dev || !cpu4_dev) {
+ ret = -EPROBE_DEFER;
+ goto free_cpumask;
+ }
+
+ for_each_present_cpu(cpu)
+ cpumask_set_cpu(cpu, priv->cpus);
+
+ priv->cluster0_clk = clk_get(priv->cpu_dev, NULL);
+ if (IS_ERR(priv->cluster0_clk)) {
+ ret = PTR_ERR(priv->cluster0_clk);
+ dev_err_probe(priv->cpu_dev, ret, "failed to get cluster0 clock\n");
+ goto free_cpumask;
+ }
+
+ priv->cluster1_clk = clk_get(cpu4_dev, NULL);
+ if (IS_ERR(priv->cluster1_clk)) {
+ ret = PTR_ERR(priv->cluster1_clk);
+ dev_err_probe(cpu4_dev, ret, "failed to get cluster1 clock\n");
+ goto put_clk_c0;
+ }
+
+ priv->opp_token = dev_pm_opp_set_regulators(priv->cpu_dev, reg_names);
+ if (priv->opp_token < 0) {
+ ret = priv->opp_token;
+ dev_err_probe(priv->cpu_dev, ret, "failed to set regulators\n");
+ goto put_clk_c1;
+ }
+
+ ret = dev_pm_opp_of_cpumask_add_table(priv->cpus);
+ if (ret) {
+ dev_err_probe(priv->cpu_dev, ret, "failed to add OPP table\n");
+ goto put_opp_regulators;
+ }
+
+ ret = dev_pm_opp_get_opp_count(priv->cpu_dev);
+ if (ret <= 0) {
+ dev_err(priv->cpu_dev, "OPP table can't be empty\n");
+ ret = -ENODEV;
+ goto remove_opp_table;
+ }
+
+ ret = dev_pm_opp_init_cpufreq_table(priv->cpu_dev, &priv->freq_table);
+ if (ret) {
+ dev_err(priv->cpu_dev, "failed to init cpufreq table: %d\n", ret);
+ goto remove_opp_table;
+ }
+
+ k1_cpufreq_driver.driver_data = priv;
+ ret = cpufreq_register_driver(&k1_cpufreq_driver);
+ if (ret)
+ goto free_freq_table;
+
+ platform_set_drvdata(pdev, priv);
+
+ return 0;
+
+free_freq_table:
+ k1_cpufreq_driver.driver_data = NULL;
+ dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &priv->freq_table);
+remove_opp_table:
+ dev_pm_opp_of_cpumask_remove_table(priv->cpus);
+put_opp_regulators:
+ dev_pm_opp_put_regulators(priv->opp_token);
+put_clk_c1:
+ clk_put(priv->cluster1_clk);
+put_clk_c0:
+ clk_put(priv->cluster0_clk);
+free_cpumask:
+ free_cpumask_var(priv->cpus);
+free_data:
+ kfree(priv);
+
+ return ret;
+}
+
+static void k1_cpufreq_remove(struct platform_device *pdev)
+{
+ struct k1_cpufreq_priv *priv = platform_get_drvdata(pdev);
+
+ if (!priv)
+ return;
+
+ cpufreq_unregister_driver(&k1_cpufreq_driver);
+ k1_cpufreq_driver.driver_data = NULL;
+ dev_pm_opp_free_cpufreq_table(priv->cpu_dev, &priv->freq_table);
+ dev_pm_opp_of_cpumask_remove_table(priv->cpus);
+ dev_pm_opp_put_regulators(priv->opp_token);
+ clk_put(priv->cluster1_clk);
+ clk_put(priv->cluster0_clk);
+ free_cpumask_var(priv->cpus);
+ kfree(priv);
+}
+
+static struct platform_driver k1_cpufreq_platdrv = {
+ .probe = k1_cpufreq_probe,
+ .remove = k1_cpufreq_remove,
+ .driver = {
+ .name = "spacemit-k1-cpufreq",
+ },
+};
+
+static const struct of_device_id k1_cpufreq_match_list[] __initconst = {
+ { .compatible = "spacemit,k1" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, k1_cpufreq_match_list);
+
+/*
+ * K1 has no dedicated cpufreq controller device. Register a logical platform
+ * device so clock/regulator dependencies can defer probe.
+ */
+static int __init k1_cpufreq_init(void)
+{
+ int ret;
+
+ if (!of_machine_device_match(k1_cpufreq_match_list))
+ return -ENODEV;
+
+ ret = platform_driver_register(&k1_cpufreq_platdrv);
+ if (ret)
+ return ret;
+
+ k1_cpufreq_pdev = platform_device_register_simple("spacemit-k1-cpufreq", -1, NULL, 0);
+ ret = PTR_ERR_OR_ZERO(k1_cpufreq_pdev);
+ if (ret)
+ platform_driver_unregister(&k1_cpufreq_platdrv);
+
+ return ret;
+}
+module_init(k1_cpufreq_init);
+
+static void __exit k1_cpufreq_exit(void)
+{
+ platform_device_unregister(k1_cpufreq_pdev);
+ platform_driver_unregister(&k1_cpufreq_platdrv);
+}
+module_exit(k1_cpufreq_exit);
+
+MODULE_DESCRIPTION("SpacemiT K1 CPUFreq driver");
+MODULE_AUTHOR("Shuwei Wu <shuwei.wu@mailbox.org>");
+MODULE_LICENSE("GPL");
--
2.53.0
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* [PATCH v3 0/2] cpufreq: spacemit: Add cpufreq support for K1 SoC
From: Shuwei Wu @ 2026-06-12 9:51 UTC (permalink / raw)
To: Rafael J. Wysocki, Viresh Kumar, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, Yixun Lan, Yixun Lan
Cc: linux-pm, linux-kernel, linux-riscv, spacemit, devicetree,
Shuwei Wu
This series enables CPU frequency scaling for the SpacemiT K1 SoC.
K1 has two CPU cluster clocks but one shared CPU voltage rail. Add a
small K1-specific cpufreq driver so the two clocks and the shared OPP
transition can be handled together.
Tested on Banana Pi BPI-F3. The system boots with all eight CPUs online,
the K1 cpufreq driver registers one policy for CPUs 0-7, and both CPU
cluster clocks follow the selected cpufreq rate.
~ # cat /sys/devices/system/cpu/online
0-7
~ # ls /sys/devices/system/cpu/cpufreq
policy0
~ # cat /sys/devices/system/cpu/cpufreq/policy0/affected_cpus
0 1 2 3 4 5 6 7
~ # cat /sys/devices/system/cpu/cpufreq/policy0/scaling_available_frequencies
614400 819000 1000000 1228800 1600000
With the userspace governor:
----------------------------------------------------------------------------
Frequency | scaling_cur | cpu_c0_core | cpu_c1_core | Real | User
(kHz) | (kHz) | (Hz) | (Hz) | (s) | (s)
-------------+-------------+-------------+-------------+---------+----------
1,600,000 | 1,600,000 | 1600000000 | 1600000000 | 1.80s | 1.80s
1,228,800 | 1,228,800 | 1228800000 | 1228800000 | 2.33s | 2.33s
1,000,000 | 1,000,000 | 1000000000 | 1000000000 | 2.88s | 2.87s
819,000 | 819,000 | 819200000 | 819200000 | 3.53s | 3.52s
614,400 | 614,400 | 614400000 | 614400000 | 4.72s | 4.72s
----------------------------------------------------------------------------
Signed-off-by: Shuwei Wu <shuwei.wu@mailbox.org>
---
Changes in v3:
- Add a K1-specific cpufreq driver for the shared-rail, dual-clock topology
- Use one shared CPU OPP table and one cpufreq policy for all CPUs
- Link to v2: https://lore.kernel.org/r/20260410-shadow-deps-v2-0-4e16b8c0f60e@mailbox.org
Changes in v2:
- Move OPP tables to dedicated k1-opp.dtsi
- Enable OPP only on BPI-F3 with cpu-supply present
- Link to v1: https://lore.kernel.org/r/20260308-shadow-deps-v1-0-0ceb5c7c07eb@mailbox.org
---
Shuwei Wu (2):
cpufreq: spacemit: Add K1 cpufreq driver
riscv: dts: spacemit: Add cpu scaling for K1 SoC
arch/riscv/boot/dts/spacemit/k1-bananapi-f3.dts | 35 +++-
arch/riscv/boot/dts/spacemit/k1-opp.dtsi | 70 +++++++
arch/riscv/boot/dts/spacemit/k1.dtsi | 8 +
drivers/cpufreq/Kconfig | 4 +
drivers/cpufreq/Kconfig.riscv | 15 ++
drivers/cpufreq/Makefile | 3 +
drivers/cpufreq/cpufreq-dt-platdev.c | 2 +
drivers/cpufreq/spacemit-k1-cpufreq.c | 251 ++++++++++++++++++++++++
8 files changed, 387 insertions(+), 1 deletion(-)
---
base-commit: 5164e95565d3fd508ca8a95351323f5716dfb695
change-id: 20260307-shadow-deps-3582a78aa756
prerequisite-patch-id: 154bd4f720ce5065d58b988de8f273207b44572e
prerequisite-message-id: <20260206-spacemit-p1-v4-0-8f695d93811e@riscstar.com>
prerequisite-patch-id: 5da3e75b18291a5540d4f66d7a0600fb8975ef62
prerequisite-patch-id: bcf41917414ecef8cf743095d130f6004c32f6a5
prerequisite-patch-id: cfe3800f8c791ec4c63e070af9628e88e0fc31b9
prerequisite-message-id: <20260305-k1-clk-fix-v1-1-abca85d6e266@mailbox.org>
prerequisite-patch-id: 7c7fb9f87dba019ece4c97c45750349a7cd28f3a
Best regards,
--
Shuwei Wu <shuwei.wu@mailbox.org>
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v4 09/16] riscv: Add Zic64b to cpufeature and hwprobe
From: Conor Dooley @ 2026-06-12 8:41 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Qingwei Hu
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-9-3f01a2449488@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1604 bytes --]
On Thu, Jun 11, 2026 at 04:12:46PM -0400, Guodong Xu wrote:
> From: Qingwei Hu <qingwei.hu@bytedance.com>
>
> Zic64b mandates 64-byte naturally aligned cache blocks and is a
> mandatory extension of the RVA22 and RVA23 profiles. Allocate a
> RISCV_ISA_EXT_ZIC64B id, parse "zic64b" from the ISA string with a
> validate callback that requires each cbom/cbop/cboz cache block size to
> be 64 bytes when it is present, and export it through hwprobe.
>
> Link: https://lists.riscv.org/g/tech-unprivileged/topic/question_about_zic64b_and/119631059
> Signed-off-by: Qingwei Hu <qingwei.hu@bytedance.com>
> Co-developed-by: Guodong Xu <docular.xu@gmail.com>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
> +static int riscv_ext_zic64b_validate(const struct riscv_isa_ext_data *data,
> + const unsigned long *isa_bitmap)
> +{
> + /*
> + * Zic64b mandates 64-byte naturally aligned cache blocks; cross-check the
> + * cbom/cbop/cboz block-size (when declared) device-tree properties to
> + * avoid inconsistency.
> + */
> + if ((riscv_cbom_block_size && riscv_cbom_block_size != 64) ||
> + (riscv_cbop_block_size && riscv_cbop_block_size != 64) ||
> + (riscv_cboz_block_size && riscv_cboz_block_size != 64)) {
> + pr_err("Zic64b detected in ISA string, disabling as a CBO block size is not 64 bytes\n");
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
I'm inclined to object to this, but we don't have validation on ACPI
stuff to be able to mandate that people fill in the rhct entries.
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
* Re: [PATCH v4 08/16] dt-bindings: riscv: Add Zic64b extension description
From: Conor Dooley @ 2026-06-12 8:23 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-8-3f01a2449488@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4032 bytes --]
On Thu, Jun 11, 2026 at 04:12:45PM -0400, Guodong Xu wrote:
> Zic64b mandates that cache blocks are 64 bytes in size and naturally
> aligned in the address space. It is a mandatory extension of both the
> RVA22 (U64/S64) and RVA23 (U64/S64) profiles, ratified with RISC-V
> Profiles Version 1.0.
>
> Document it so it can be described in the riscv,isa-extensions property,
> alongside the related Zicbom/Zicbop/Zicboz cache-block extensions. Since
> Zic64b fixes the cache block size at 64 bytes, also add a schema check
^^
Not that it matters, but there's an extra space here.
> requiring any present cbom/cbop/cboz block size to be 64.
>
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
> ---
> v4: Insert zic64b at its sorted position (before zicbom).
> Update the commit message.
> v3: New patch.
> ---
> .../devicetree/bindings/riscv/extensions.yaml | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
> index 5ffc40d599c02..1c24999beb59e 100644
> --- a/Documentation/devicetree/bindings/riscv/extensions.yaml
> +++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
> @@ -494,6 +494,12 @@ properties:
> in commit 64074bc ("Update version numbers for Zfh/Zfinx") of
> riscv-isa-manual.
>
> + - const: zic64b
> + description:
> + The standard Zic64b extension for 64-byte naturally aligned cache
> + blocks, as ratified in RISC-V Profiles Version 1.0, with commit
> + b1d806605f87 ("Updated to ratified state.")
> +
> - const: zicbom
> description:
> The standard Zicbom extension for base cache management operations as
> @@ -1142,6 +1148,20 @@ allOf:
> not:
> contains:
> const: zilsd
> + # Zic64b mandates 64-byte naturally aligned cache blocks
> + - if:
> + properties:
> + riscv,isa-extensions:
> + contains:
> + const: zic64b
> + then:
> + properties:
> + riscv,cbom-block-size:
> + const: 64
> + riscv,cbop-block-size:
> + const: 64
> + riscv,cboz-block-size:
> + const: 64
I think we also need to have
diff --git a/Documentation/devicetree/bindings/riscv/extensions.yaml b/Documentation/devicetree/bindings/riscv/extensions.yaml
index 1c24999beb59e..bbd442cfbd904 100644
--- a/Documentation/devicetree/bindings/riscv/extensions.yaml
+++ b/Documentation/devicetree/bindings/riscv/extensions.yaml
@@ -1162,6 +1162,32 @@ allOf:
const: 64
riscv,cboz-block-size:
const: 64
+ # All three Zicbo* extensions require their block size property as there's no
+ # default.
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zicbom
+ then:
+ required:
+ - riscv,cbom-block-size
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zicbop
+ then:
+ required:
+ - riscv,cbop-block-size
+ - if:
+ properties:
+ riscv,isa-extensions:
+ contains:
+ const: zicboz
+ then:
+ required:
+ - riscv,cboz-block-size
additionalProperties: true
...
because I don't think there's a warning generated at present* if someone
does "zicbom" + "zic64b" and doesn't have a riscv,cbom-block-size property,
only if they have one and it isn't 64. I think the former is a bigger
problem than the latter.
Probably needs to be an additional patch, because it has value whether
or not we permit zic64b.
pwbot: cr
Cheers,
Conor.
*: the kernel will warn at runtime, but nothing in dtbs_check etc.
>
> additionalProperties: true
> ...
>
> --
> 2.43.0
>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply related
* Re: [PATCH v4 07/16] riscv: Add B to hwcap and hwprobe
From: Conor Dooley @ 2026-06-12 8:12 UTC (permalink / raw)
To: Guodong Xu
Cc: Jonathan Corbet, Shuah Khan, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Zong Li, Deepak Gupta, Anup Patel,
Atish Patra, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Yixun Lan, Chen Wang, Inochi Amaoto, linux-doc, linux-riscv,
linux-kernel, kvm, kvm-riscv, Paul Walmsley, Conor Dooley,
devicetree, spacemit, sophgo, linux-kselftest, Palmer Dabbelt,
Andrew Jones
In-Reply-To: <20260611-rva23u64-hwprobe-v2-v4-7-3f01a2449488@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 613 bytes --]
On Thu, Jun 11, 2026 at 04:12:44PM -0400, Guodong Xu wrote:
> From: Andrew Jones <andrew.jones@oss.qualcomm.com>
>
> Add B to hwcap and ensure when B is present that Zba, Zbb, and Zbs
> are all set. Also expose B via hwprobe (RISCV_HWPROBE_EXT_B in
> RISCV_HWPROBE_KEY_IMA_EXT_1) so that userspace can probe B directly,
> mirroring the F/D/C/V pattern where each is reported via both hwcap
> and hwprobe.
>
> Signed-off-by: Andrew Jones <andrew.jones@oss.qualcomm.com>
> [Add B to hwprobe]
> Signed-off-by: Guodong Xu <docular.xu@gmail.com>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
^ permalink raw reply
page: next (older)
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox