linux-kernel - Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device tree

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <01573262-69a8-44cf-ae02-2e9842c59dde@lunn.ch>
Date: Mon, 27 Oct 2025 13:01:28 +0100
From: Andrew Lunn <andrew@...n.ch>
To: Ryan Chen <ryan_chen@...eedtech.com>
Cc: Arnd Bergmann <arnd@...db.de>, BMC-SW <BMC-SW@...eedtech.com>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>, Joel Stanley <joel@....id.au>,
	Andrew Jeffery <andrew@...econstruct.com.au>,
	Jeremy Kerr <jk@...econstruct.com.au>, Lee Jones <lee@...nel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Bjorn Andersson <bjorn.andersson@....qualcomm.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Nishanth Menon <nm@...com>,
	Nícolas F. R. A. Prado <nfraprado@...labora.com>,
	Taniya Das <quic_tdas@...cinc.com>,
	"Lad, Prabhakar" <prabhakar.mahadev-lad.rj@...renesas.com>,
	Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
	Eric Biggers <ebiggers@...nel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-aspeed@...ts.ozlabs.org" <linux-aspeed@...ts.ozlabs.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC
 device tree

On Mon, Oct 27, 2025 at 02:42:01AM +0000, Ryan Chen wrote:
> > Subject: Re: [PATCH v6 4/6] arm64: dts: aspeed: Add initial AST2700 SoC device
> > tree
> > 
> > > SoC0, referred to as the CPU die, contains a dual-core Cortex-A35
> > > cluster and two Cortex-M4 cores, along with its own clock/reset
> > > domains and high-speed peripheral set.
> > 
> > > SoC1, referred to as the I/O die, contains the Boot MCU and its own
> > > clock/reset domains and low-speed peripheral set, and is responsible
> > > for system boot and control functions.
> > 
> > So is the same .dtsi file shared by both systems? 
> 
> This .dtsi represents the Cortex-A35 view only and is not shared
> with the Cortex-M4 or the Boot MCU side, since they are separate
> 32-bit and 64-bit systems running independent firmware.

DT describes the hardware. The .dtsi file could be shared, you just
need different status = <>; lines in the dtb blob.

> > How do you partition devices
> > so each CPU cluster knows it has exclusive access to which peripherals?
> 
> Before the system is fully brought up, Boot MCU configure hardware 
> controllers handle the resource partitioning to ensure exclusive access.

Are you saying it modifies the .dtb blob and changes some status =
"okay"; to "disabled";?

	Andrew