linux-kernel - Re: [PATCH v3 5/5] riscv: dts: thead: Add reset controllers of more subsystems for TH1520

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aQDIVJNX0fOTbp7p@pie>
Date: Tue, 28 Oct 2025 13:42:44 +0000
From: Yao Zi <ziyao@...root.org>
To: Drew Fustini <fustini@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
	Albert Ou <aou@...s.berkeley.edu>,
	Michal Wilczynski <m.wilczynski@...sung.com>,
	Alexandre Ghiti <alex@...ti.fr>, devicetree@...r.kernel.org,
	Han Gao <gaohan@...as.ac.cn>, Han Gao <rabenda.cn@...il.com>,
	linux-kernel@...r.kernel.org, Guo Ren <guoren@...nel.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	linux-riscv@...ts.infradead.org, Fu Wei <wefu@...hat.com>
Subject: Re: [PATCH v3 5/5] riscv: dts: thead: Add reset controllers of more
 subsystems for TH1520

On Mon, Oct 27, 2025 at 11:56:15AM +0000, Drew Fustini wrote:
> On Tue, Oct 14, 2025 at 01:10:32PM +0000, Yao Zi wrote:
> > Describe reset controllers for VI, MISC, AP, DSP and AO subsystems. The
> > one for AO subsystem is marked as reserved, since it may be used by AON
> > firmware.
> > 
> > Signed-off-by: Yao Zi <ziyao@...root.org>
> > ---
> >  arch/riscv/boot/dts/thead/th1520.dtsi | 37 +++++++++++++++++++++++++++
> >  1 file changed, 37 insertions(+)
> > 
> > diff --git a/arch/riscv/boot/dts/thead/th1520.dtsi b/arch/riscv/boot/dts/thead/th1520.dtsi
> > index e680d1a7c821..15d64eaea89f 100644
> > --- a/arch/riscv/boot/dts/thead/th1520.dtsi
> > +++ b/arch/riscv/boot/dts/thead/th1520.dtsi
> > @@ -277,6 +277,12 @@ clint: timer@...c000000 {
> >  					      <&cpu3_intc 3>, <&cpu3_intc 7>;
> >  		};
> >  
> > +		rst_vi: reset-controller@...4040100 {
> > +			compatible = "thead,th1520-reset-vi";
> > +			reg = <0xff 0xe4040100 0x0 0x8>;
> 
> Is this intentional so that the first VI_SUBSYS register, VISYS_SW_RST
> at offset 0x100, will have an offset of 0 from the thead,th1520-reset-vi
> reg in the driver?

Yes, it's intentional for both VI and DSP subsystem. As you could see,
excluding these TEE-only shadows, the first reset-related register in
VI_SUBSYS is at offset 0x100. For DSP subsystem, it's at offset 0x28
(and is the only reset-related register).

I want to keep the first 0x100 bytes in VI_SUBSYS, and first 0x24 bytes
in DSP_SUBSYS free, because they're clock-related registers, and should
be reserved for clock driver introduced in the future.

In TH1520 SoC, only AON and AP subsystems have strictly separated reset
and clock register regions. For all other subsystems like VI, VO, VP,
MISC and DSP, reset and clock registers tightly follow each other, but
they don't interleave.

This series follows the way in which VO clock/reset controllers are
modeled in devicetree, where the subsystem region is split into two
nodes, one for clock and one for reset. This will lead to less regular
address/size values like what you noticed, as the registers do stay very
close.

> [snip]
> > +		rst_dsp: reset-controller@...f040028 {
> > +			compatible = "thead,th1520-reset-dsp";
> > +			reg = <0xff 0xef040028 0x0 0x4>;
> 
> Similar to rst_vi, is this intentional so that the first register,
> DSPSYS_SW_RST at offset 0x28, will have an offset of 0 in the driver?
> 
> Thanks,
> Drew

Best regards,
Yao Zi