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

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.