linux-kernel - Re: [PATCH v2 1/5] dt-bindings: sram: sunxi-sram: Add A523 compatible

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: <20250428134435.76e19d29@donnerap.manchester.arm.com>
Date: Mon, 28 Apr 2025 13:44:35 +0100
From: Andre Przywara <andre.przywara@....com>
To: Yixun Lan <dlan@...too.org>, Krzysztof Kozlowski <krzk@...nel.org>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Chen-Yu Tsai <wens@...e.org>, Jernej
 Skrabec <jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>,
 Maxime Ripard <mripard@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
 <pabeni@...hat.com>, Corentin Labbe <clabbe.montjoie@...il.com>,
 <devicetree@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
 <linux-sunxi@...ts.linux.dev>, <linux-kernel@...r.kernel.org>,
 <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 1/5] dt-bindings: sram: sunxi-sram: Add A523
 compatible

On Mon, 28 Apr 2025 12:21:56 +0000
Yixun Lan <dlan@...too.org> wrote:

> Hi Krzysztof,
> 
> On 09:21 Mon 28 Apr     , Krzysztof Kozlowski wrote:
> > On Thu, Apr 24, 2025 at 06:08:39PM GMT, Yixun Lan wrote:  
> > > The Allwinner A523 family of SoCs have their "system control" registers
> > > compatible to the A64 SoC, so add the new SoC specific compatible string.
> > > 
> > > Reviewed-by: Andre Przywara <andre.przywara@....com>
> > > Signed-off-by: Yixun Lan <dlan@...too.org>
> > > ---
> > >  .../devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml     | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
> > > index a7236f7db4ec34d44c4e2268f76281ef8ed83189..e7f7cf72719ea884d48fff69620467ff2834913b 100644
> > > --- a/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
> > > +++ b/Documentation/devicetree/bindings/sram/allwinner,sun4i-a10-system-control.yaml
> > > @@ -50,6 +50,7 @@ properties:
> > >            - enum:
> > >                - allwinner,sun50i-a100-system-control
> > >                - allwinner,sun50i-h6-system-control
> > > +              - allwinner,sun55i-a523-system-control
> > >            - const: allwinner,sun50i-a64-system-control  
> > 
> > No update for the children (sram)?
> >   
> No, I don't think there is sub node for sram
> From address map of A527, there is total 4KB size space of
> this section which unlikely has sram available.

That's something else, though. This system controller here *also* contains
a register to switch access to SRAM blocks between the CPU and the devices.
The actual SRAM blocks are somewhere else (hence the empty ranges;
property), check the H616 for instance:
	syscon: syscon@...0000 {
		compatible = "allwinner,sun50i-h616-system-control";
		reg = <0x03000000 0x1000>;
		#address-cells = <1>;
		#size-cells = <1>;
		ranges;

		sram_c: sram@...00 {
			compatible = "mmio-sram";
			reg = <0x00028000 0x30000>;

Krzysztof, we haven't worked out the SRAM regions yet, we typically add
them only when we need them. I think the display engine is a prominent
user, and support for that is quite a bit out at the moment.

From a compatibility standpoint it should be fine to leave this empty for
now, if I am not mistaken?

Cheers,
Andre

> but I do see some BROM/SRAM space from 0x0000 0000 - 0x0006 3FFF ..
> (which should not be relavant to this patch series..)
>