[PATCH 5/5] PCI fixes for the MPC8641 Rev 2.0 silicon and Rev 1.02hardware

[Jon Loeliger]

On Fri, 2007-05-18 at 12:56, Timur Tabi wrote:
> Scott Wood wrote:
> 
> > That's your model.  Mine involves merging a fragment that corresponds to 
> > an active hwoption, with no complex conditional evaluation or deletion 
> > of anything from the main tree.
> 
> I think my model (which is also Jon's, I think) is easier to read and implement.

Harumph.

> 
> phy-node [ if j22 = on ]
> {
> 	phy-type = 1
> }
> 
> phy-node [ if j22 = off ]
> {
> 	phy-type = 2
> }
> 
> Obviously, j22 can be either on or off, but never both.  If the DTS is coded incorrectly, 
> then it will have problems, but I think that's a fair trade-off for the easier implementation.

First of all, I wanted to get away from the notion of calling
anything a "jumper".  What I said to you was to predicate the
clause based on some arbitrary conditional, not just some "jumper
setting."

Second, I never came anywhere near the syntax above.

Third, I am pretty sure we've always really been talking
about a DTC enhancement to selectively add regions to the
DTB in much the same way as if one had said:

    #if <compile-time-conditional>
        {
            <use this node or property snippet>
        }
    #else
        {
            <use this other snippet>

        }
    #endif

So embedding a full runtime evaluation of conditionals
expressions wasn't really in my suggestion at this time
at all.  I had essentially proposed (to you, Timur) that
we have a predicate clause in the DTS that guarded a the
presence/absence of a node.

And finally, I wasn't sure I was happy with it all yet
in any event, so I hadn't acted on it yet.  I was still
pondering "the right approach here".

Ah well,
jdl