[RFC] Interrupt mapping documentation

[Segher Boessenkool]

>> I haven't specified that it _should_ be called interrupt- 
>> controller, but
>> it's generally called that way at least on chrp/pSeries and I think
>> there's an OF recommended practices RFC that says something around  
>> those
>> lines, so I changed the examples to reflect that.
>
> If there's precedence for it, it's fine with me.  I was just  
> curious about why it changed.  Personally, I'd rather see it as  
> "pic", because that's more specific, and it's the actual device  
> name, but it's not keeping me up at night.....

I'll just say that _I_ care :-)

>> In addition,
>> the default-to-parent thing is something I'll remove from the spec  
>> and
>> write that the absence of the property is undefined I think. We'll  
>> keep
>> the current behaviour in linux for now though.
>
> That also works for me.  I'd rather have to specify more stuff in  
> the tree and have it be crystal clear how it's interpreted and  
> used.  So, is this true for just #address-cells, or does it affect  
> #size-cells as well?

#size-cells defaults to 1, it isn't inherited either.  So same story.

>>>> The additions in the patch specify new requirements that don't seem
>>>> to match up with the statement above.  In the new patch, #address-
>>>> cells is listed as a required node for interrupt-controller nodes,
>>>> there's no mention of inheritance from a parent,
>>>
>>> Inheritance from the parent does not exist, in real OF.  Absence of
>>> #address-cells means "default to 2".  This needs to be fixed in DTC.
>>
>> Yes. Except that I will probably not do the "default to 2". The  
>> kernel
>> doesn't do it and there might still be things relying on the old
>> (broken) linux behaviour. Thus I'll probably spec it as undefined.
>
> Sounds good.  The dtc should probably throw an error (or at least a  
> warning) on this, so the trees get fixed.  I think I'd prefer to  
> see an error - that will keep this problem from propagating any  
> further.

Error please...  If the new DTC spec will require it, it should
be an error.

>>> Just *require* #address-cells for everything with addressable sub- 
>>> nodes,
>>> at least in DTC.  Doesn't cost much, and no confusion anymore.
>>
>> Yes. We should do that.
>
> I agree 100%.

No dissenters anywhere?  Please?  Can't we have a fight?

>> In the case of interrupt controllers/nexus, #address-cells is not for
>> addressable sub-nodes though but for defining the format of unit
>> interrupt specifiers for interrupt-childs which aren't necessary sub
>> nodes... confusing heh ?
>
> Um, yeah :)  I think with a little clarification it will be fine,  
> though.

As long as your interrupt tree is a) completely independent of your bus
tree (and then, only in most cases), or b) completely follows the bus  
tree.

Sigh.

On almost all platforms, this shouldn't cause any real problems, though.


Segher