Re: [PATCH 1/3] riscv: dts: spacemit: Add cpu scaling for Milk-V Jupiter

From: Yixun Lan <dlan@kernel.org>
To: sashiko-reviews@lists.linux.dev, linux-kernel@vger.kernel.org,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Shuwei Wu <shuwei.wu@mailbox.org>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"open list:RISC-V SPACEMIT SoC Support"
	<linux-riscv@lists.infradead.org>,
	"open list:RISC-V SPACEMIT SoC Support"
	<spacemit@lists.linux.dev>
Subject: Re: [PATCH 1/3] riscv: dts: spacemit: Add cpu scaling for Milk-V Jupiter
Date: Wed, 29 Jul 2026 09:54:29 +0000	[thread overview]
Message-ID: <20260729095429-GKH76518@kernel.org> (raw)
In-Reply-To: <amnJsOiWSfuBR1ps@aurel32.net>

Hi Aurelien,

On 11:36 Wed 29 Jul     , Aurelien Jarno wrote:
> Hi,
> 
> On 2026-07-28 21:19, sashiko-bot@kernel.org wrote:
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > 
> > Pre-existing issues:
> > - [High] This problem wasn't introduced by this patch, but wiring it up to cpufreq makes it a serious hardware safety risk: the CPU supply regulator (`buck1_0v9`) has an overly permissive maximum voltage constraint of 3.45V, which could physically damage the CPU.
> > --
> > 
> > --- Patch [1]: [PATCH 1/3] riscv: dts: spacemit: Add cpu scaling for Milk-V Jupiter ---
> > commit 4e25fb96470d1ad37415e03a27de699ef1f0da26
> > Author: Aurelien Jarno <aurelien@aurel32.net>
> > 
> > riscv: dts: spacemit: Add cpu scaling for Milk-V Jupiter
> > 
> > This commit enables CPU DVFS on the Milk-V Jupiter board by including the OPP
> > tables and wiring the CPU nodes to the CPU regulator supply.
> > 
> > > diff --git a/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts b/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts
> > > index b61f5995ec771..3c16d0c20050e 100644
> > > --- a/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts
> > > +++ b/arch/riscv/boot/dts/spacemit/k1-milkv-jupiter.dts
> > [ ... ]
> > > @@ -107,6 +108,38 @@ &combo_phy {
> > >  	status = "okay";
> > >  };
> > >  
> > > +&cpu_0 {
> > > +	cpu-supply = <&buck1_0v9>;
> > > +};
> > [ ... ]
> > > @@ -209,7 +242,7 @@ pmic@41 {
> > >  		dldoin2-supply = <&buck5>;
> > >  
> > >  		regulators {
> > > -			buck1 {
> > > +			buck1_0v9: buck1 {
> > >  				regulator-min-microvolt = <500000>;
> > >  				regulator-max-microvolt = <3450000>;
> > 
> > [Severity: High]
> > This is a pre-existing issue, but by wiring up the CPU supply for cpufreq in 
> > this patch, does it introduce a severe hardware safety risk?
> > 
> > The buck1_0v9 regulator retains a very permissive maximum voltage constraint 
> > of 3.45V. Because the safe physical limit for the CPU is 1.05V (as defined in 
> > k1-opp.dtsi), could this permanently damage the hardware if a kernel bug, opp 
> > misconfiguration, or privileged userspace requests a higher voltage up to the 
> > board-defined maximum?
> > 
> > Should the board-level constraint be clamped to the safe physical limits of 
> > the CPU (e.g., 1050000 microvolts) to prevent the regulator from supplying a 
> > destructive voltage?
> 
> This looks like a valid point. Yixun, I believe the commit a5d7000e1a17 
> ("riscv: dts: spacemit: Add cpu scaling for K1 SoC") should be drop from 
> your tree until this is fixed, or at least it should not be pushed to 
> v7.3 if the regulator issue is not fixed.
> 
Instead of dropping this patch, I'd like to get it fixed in tree, I don't want
to hold on this patch, it's generally tested

> I'll try to submit a patchset fixing that.
> 
Yes, please, I think we still have time to get it in for v7.3

-- 
Yixun Lan (dlan)