> 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. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
