[RFC][PATCH 6/8] Walnut DTS

[Scott Wood]

On Wed, Jul 18, 2007 at 07:25:57AM +1000, Benjamin Herrenschmidt wrote:
> > > which is why I tend to prefer having it
> > > explicitely in the interrupt controller node :-)
> > 
> > Which is simply incorrect.
> 
> It's absolutely not. Please, stop that moronic pin-head behaviour and
> find me a single case where that would actually be a problem of any sort
> or form.

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.

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

It could lead to flamewars. :-)

> > You mean, the magic default values you used for #address-cells
> > and #size-cells?  That was simply a bug, someone forgot to read
> > the documentation...
> 
> No, defaults are crap, period.

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

> See above. Besides, as I said, default values are crap. And no, it's not
> obvious which nodes define a physical address space or not, at least not
> for a generic parser.

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.

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

> > In some areas, perhaps.  And it would be nice to bring those
> > areas to the attention of the working group, instead of just
> > to complain.
> 
> The working group is dead and some of the ex members of it expressed
> their lack of interest in pursuing these matters.

There is the ePAPR working group, though.

-Scott