[PATCH] powerpc: document new interrupt-array property

[Yoder Stuart-B08248]

> -----Original Message-----
> From: David Gibson [mailto:david at gibson.dropbear.id.au] 
> Sent: Sunday, February 25, 2007 10:17 PM
> To: Benjamin Herrenschmidt
> Cc: Yoder Stuart-B08248; linuxppc-dev at ozlabs.org; paulus at samba.org
> Subject: Re: [PATCH] powerpc: document new interrupt-array property
> 
> On Sat, Feb 24, 2007 at 07:40:59AM +0100, Benjamin 
> Herrenschmidt wrote:
> > On Fri, 2007-02-23 at 12:15 -0700, Yoder Stuart-B08248 wrote:
> > > > I'd rather write it like
> > > > 
> > > > >       interrupts        = < a 4   b 4   0 4   1 4   2 4 >
> > > > >       interrupt-parents = <&UIC0 &UIC0 &UIC1 &UIC1 &UIC1>
> > > > 
> > > 
> > > Segher, with your proposal here of an interrupt-parents property
> > > is this really keeping with the normal OF way of representing
> > > property values?
> > > 
> > > Examples exists where one property tells you how to interpret
> > > or decode another (e.g. #address-cells), but your proposal we
> > > have two distinct properties each with values that together
> > > provide the complete 'value' (interrupt parent + interrupt
> > > specifier).  Is there any precedent for this approach?
> > 
> > Somewhat... interrupt-map and interrupt-map-mask... that 
> sort of thing.
> > 
> > > I think I'd rather see all the information encoded in
> > > one value.
> > 
> > On the other hand, I do quite like keeping with the old 
> principle that
> > having interrupts == having an "interrupts" node.
> 
> That would be nice.  On the other hand, re-using interrupts means that
> it's possible to get a silent misparse of the interrupt information: a
> parser which doesn't understand the new 'interrupt-parents' property
> will encounter the node, see the 'interrupts' property, assume that
> the interrupt parent is the physical parent and, if the
> #interrupt-cells values match up, which is quite possible, assume that
> it has correctly understood the interrupt information.
> 
> This is arguably a worse behaviour than simply having an old-style
> parser see the lack of 'interrupts' property and assume the device has
> no interrupts.

I agree that conceptually this is true.  However, in this particular
case, practically speaking, the only DTS files that would have
this new construct would some new 4xx ones.  If the updates to the
parser
and 4xx board support roughly go in at the same time we shouldn't
have many parser/DTS compatibility issues.

A new property here is really putting some infrastructure in place for
future DTS files.

Stuart