Re: [RFC][PATCH 6/8] Walnut DTS

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

> It could lead someone to the erroneous conclusion that an #address-cells
> other than zero in an interrupt controller that is not a device parent is
> in any way a sane or supported thing to do.

I fail why anyone would ever want to do it though :-)

> It could lead people to write code that doesn't handle the absence of
> #address-cells in such a node properly.

We just need to make mention that it can be absent in the spec, there
shouldn't be that many parsers out there.

> It could lead to flamewars. :-)

Yeah well.

> If there's only one value that could possibly make sense, it *not* being
> the default is crap.

Only for leaf nodes. Other values do make sense for non-leaf nodes.

> The obvious way (which indeed isn't what the suggested algorithm does --
> but the suggested algorithm doesn't do anything sensible) is that if you
> got to the node via an interrupt-parent or interrupt-map, it doesn't use
> #address-cells, and if you got to it by going to the regular device tree
> parent, it does.

Yeah well, that's also somewhat debatable too. You need a #address-cells
to be able to parse an interrupt-map. You can imagine cross-links and
special maps used to handle things like the multiple UICs as David did
in the past. I wouldn't get rid of that flexibility to handle corner
cases that aren't easily represented by the "standard" stuff.

> Pretty much any time you use the unit address in a context other than the
> bus parent, things cease making sense.

I tend to agree.

> There is the ePAPR working group, though.

Yup, true.

Ben.