[PATCH] powerpc: document new interrupt-array property

David Gibson david at gibson.dropbear.id.au
Mon Feb 26 15:16:46 EST 2007


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.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson



More information about the Linuxppc-dev mailing list