Re: [PATCH 3/9] arm64: dts: imx8ulp: Correct SRAM node address and size to cover full SSRAM P2

[Frank Li <Frank.li@oss.nxp.com>]

On Wed, Jul 15, 2026 at 12:47:36PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The `ranges` property of the `sram` node and the `scmi_buf` child node were not updated to match the newly expanded SRAM `reg` region.
> --
>
> --- Patch [3]: [PATCH 3/9] arm64: dts: imx8ulp: Correct SRAM node address and size to cover full SSRAM P2 ---
> commit e7f90a5991db01135d232289fb75ec4528de4fca
> Author: Peng Fan <peng.fan@nxp.com>
>
> arm64: dts: imx8ulp: Correct SRAM node address and size to cover full SSRAM P2
>
> The SSRAM P2 partition starts at 0x22010000 with a size of 64 KB.
> The previous node only mapped the last 4 KB (0x2201f000, 0x1000) which
> was used for the SCMI shared memory buffer. Update the base address and
> size to cover the full P2 region so it can also serve as a general
> purpose SRAM pool.
>
> > diff --git a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > --- a/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > +++ b/arch/arm64/boot/dts/freescale/imx8ulp.dtsi
> > @@ -154,9 +154,9 @@ sosc: clock-sosc {
> >  		#clock-cells = <0>;
> >  	};
> >
> > -	sram@2201f000 {
> > +	sram@22010000 {
> >  		compatible = "mmio-sram";
> > -		reg = <0x0 0x2201f000 0x0 0x1000>;
> > +		reg = <0x0 0x22010000 0x0 0x10000>;
> >
> >  		#address-cells = <1>;
> >  		#size-cells = <1>;
> >  		ranges = <0 0x0 0x2201f000 0x1000>;
> >
> >  		scmi_buf: scmi-sram-section@0 {
> >  			compatible = "arm,scmi-shmem";
> >  			reg = <0x0 0x400>;
> >  		};
>
> [Severity: Medium]
> Since the reg property was expanded to cover the full 64KB region starting
> at 0x22010000, should the ranges property and the scmi_buf node also be
> updated to match?
>
> Right now, ranges still only maps the last 4KB (0x2201f000). Any new child
> nodes attempting to use the lower 60KB (0x22010000 to 0x2201efff) as a
> general-purpose pool will fail to resolve their addresses.
>
> Also, if ranges is updated to map from the new 0x22010000 base, wouldn't
> the scmi_buf child node offset need to be updated to 0xf000 to maintain
> its previous absolute address?

Is it true? look like make sense?

Frank
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260715-imx8ulp-dts-v1-0-19651358b599@nxp.com?part=3