Could the DTS experts look at this?

[Scott Wood]

On Tue, Feb 12, 2008 at 11:36:33AM +1100, David Gibson wrote:
> On Tue, Feb 12, 2008 at 01:21:44AM +0100, Arnd Bergmann wrote:
> > On Tuesday 12 February 2008, David Gibson wrote:
> > > Or to expand.  It's relatively easy now to just include multiple nodes
> > > in the tree and either delete or nop some of them out conditionally
> > > using libfdt.  But the conditional logic should be in the manipulating
> > > agent (u-boot or bootwrapper or whatever), there's no way we're going
> > > to require a conditional expression parser to interpret the device
> > > tree blob itself.
> > 
> > How about making the logic to nop out nodes a little more generic
> > without changes to the binary format?
> > E.g. you could have a "linux,conditional-node" property in the device
> > tree whose value is compared to a HW configuration specific string.
> > In Sean's example, you can have linux,conditional-node="Rev.A" in
> > some nodes and linux,conditional-node="Rev.B" in others, then
> > knock out all devices that have a non-matching linux,conditional-node
> > property, and finally remove the properties themselves before starting
> > the kernel.
> 
> Well, that's basically a u-boot issue.  If they want to do their input
> trees that way, and have helper functions that deal with it...

The actual mechanism that we originially discussed, which Timur later
morphed into conditions-on-nodes, was to have a separate hwoptions node,
under which would be described various hwoptions (jumpers and such) whose
state could be either detected by u-boot or set by environment variable. 
Each hwoption setting would contain a device tree fragment to be merged into
the main device tree.

-Scott