On Mon, Dec 2, 2024 at 4:09 PM Segher Boessenkool
[off-list ref] wrote:

On Mon, Dec 02, 2024 at 08:18:22AM -0600, Rob Herring wrote:

quoted

On Wed, Nov 27, 2024 at 3:47 PM Segher Boessenkool
[off-list ref] wrote:

quoted

On Tue, Nov 26, 2024 at 02:36:32PM +1100, Michael Ellerman wrote:

quoted

Michael Ellerman [off-list ref] writes:

quoted

"Rob Herring (Arm)" [off-list ref] writes:

quoted

While OpenFirmware originally allowed walking parent nodes and default
root values for #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 various old device trees that have been given to me over the
years, and as far as I can tell they all have these properties (some of
them are partial trees so it's hard to be 100% sure).

So LGTM.

Turns out I was wrong.

The warning about #size-cells hits on some powermacs, possible fixup
patch here:

  https://lore.kernel.org/linuxppc-dev/20241126025710.591683-1-mpe@ellerman.id.au/ (local)

The Open Firmware specification is extremely clear that a "missing"
"#size-cells" property means this bus has the default value of 1.

And the default for #address-cells is 2, but yet every architecture
except Sparc has that wrong.

?

Almost all architectures (that run Linux) use 64-bit addressing, both
32-bit and 64-bit architectures.

I'm just telling you what Linux uses for defaults for at least 20 years.

quoted

If I have a node without #size-cells, is the default of 1 used or do
we check parent nodes? My read of the spec would be the former, but
the kernel does the latter.

The former is correct.  The latter makes no sense at all!  The whole
point of the "bus" abstraction is that you get a new addressing domain
there.

I agree, but that's what the kernel does (again, for 20+ years).
Walking the parents is really what I want to get rid of here. My
choices were drop that behavior and see who I break, or add a warning
and see who notices. I went the nicer route of a warning.

Yes, these days you numerically find it most often with PCI sub-domains,
but those are boring.  In most cases you *do* have different adressing
on your child busses, and even if the addressing is the same, addresses
on the child bus are not normally a subset of those on the parent bus.

quoted

quoted

https://www.openfirmware.info/data/docs/of1275.pdf (page 186).

DTC or FDT might want to do things differently, but expecting decades
older stuff to conform to its ill-conceived unnecessarily super wordy
stuff is, well, not a plan that is likely to work very well :-)

That is not the intention. The intention is to identify what doesn't
conform and exclude those systems from this check (or apply a fixup if
that works).

So *always* use the OF definition, at least on OF systems?  Where
everything is meant to conform, but conform to OF, not conform to this
"OF-like-but-very-different-in-crucial-spots" thing :-)

I'm pretty sure there are OF systems that don't conform, so it is not
that simple. There's this comment in of_irq_parse_raw() for example:

        /* Look for this #address-cells. We have to implement the old linux
         * trick of looking for the parent here as some device-trees rely on it
         */

Maybe that's from some system long dropped and we don't need it
anymore. I have no idea. That's what I'm trying to find out with this
patch.

We also don't really have a way to distinguish OF from FDT (where we'd
need to). It is somewhat just by arch, but PPC always passes an FDT to
the kernel for both FDT and OF systems.

Rob