Received-SPF: pass (google.com: domain of linux-kernel+bounces-195886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 30 May 2024 22:27:20 +0200
From: Sam Ravnborg <sam@ravnborg.org>
To: "Rob Herring (Arm)" <robh@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>,
	Andreas Larsson <andreas@gaisler.com>, sparclinux@vger.kernel.org,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] of: WARN on using default root node
 #address-cells/#size-cells
Message-ID: <20240530202720.GA1656150@ravnborg.org>
References: <20240530185049.2851617-1-robh@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20240530185049.2851617-1-robh@kernel.org>

Hi Rob.

On Thu, May 30, 2024 at 01:50:48PM -0500, Rob Herring (Arm) wrote:
> While OpenFirmware originally allowed default values of #address-cells
> and #size-cells, FDT has long required explicit values. It's been a
> warning in dtc for the root node since the beginning (2005) and for
> any parent node since 2007. Of course, not all FDT uses dtc, but that
> should be the majority by far. The various extracted OF devicetrees I
> have dating back to the 1990s (various PowerMac, OLPC, PASemi Nemo)
> all have explicit root node properties.
> 
> I have no idea what exists for Sparc, so disabling the warning for it.
> If any other platforms hit the warning, then the warning can be
> disabled for them.
> 
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
> ---
> Sparc folks, If anyone can dump DTs from some Sparc systems it would be
> helpful.

For sparc the format looks much different - see:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/prtconfs.git

This is dumps from the prtconf tool found in Solaris.

Looking at for example t1000 it looks like #size-cells, #address-cells
are used properly.

Looking at the older ss20 I see no use of these.
Looking at sb100 (old sparc64 machine) I see inconsistent use.

My best guess is that sparc32 machines see little to no use of them.
sparc64 use them, but on older machines the usage is inconsistent.

	Sam