Re: [PATCH v2] of: WARN on deprecated #address-cells/#size-cells handling

[Segher Boessenkool <segher@kernel.crashing.org>]

On Mon, Dec 02, 2024 at 08:18:22AM -0600, Rob Herring wrote:
> On Wed, Nov 27, 2024 at 3:47 PM Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Tue, Nov 26, 2024 at 02:36:32PM +1100, Michael Ellerman wrote:
> > > Michael Ellerman <mpe@ellerman.id.au> writes:
> > > > "Rob Herring (Arm)" <robh@kernel.org> writes:
> > > >> 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/
> >
> > 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.

> 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.

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.

> > 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 :-)


Segher