[PATCH] Implements new features for updating existing device tree nodes.

[David Gibson]

On Mon, Oct 18, 2010 at 10:01:15AM -0600, Grant Likely wrote:
> On Mon, Oct 18, 2010 at 11:11:35AM +1100, David Gibson wrote:
> > On Sat, Oct 16, 2010 at 12:32:17PM -0600, Grant Likely wrote:
> > > On Sat, Oct 16, 2010 at 06:45:47AM -0700, John Bonesio wrote:
> > > > On Sat, 2010-10-16 at 02:10 -0600, Grant Likely wrote:
> > > > > On Sat, Oct 16, 2010 at 05:47:44PM +1100, David Gibson wrote:
> > > > > > On Fri, Oct 15, 2010 at 08:21:17PM -0700, John Bonesio wrote:
> > [snip]
> > > > > For example; I could have a labelled spi bus node with child nodes for
> > > > > each of the spi devices.  I want to be able to remove/replace the
> > > > > child nodes without having to label them first.
> > > > > 
> > > > > g.
> > > > 
> > > > Why not just add the label to the node you need first?
> > > 
> > > That may not be possible and/or desirable.  For instance, when the
> > > tree is extracted from /proc.  Or if the base tree in stored in the
> > > kernel source and an external tool is modifying it for a specific
> > > purpose (when unable to patch the kernel tree).  Or for generated
> > > device trees from the Xilinx toolchain for FPGAs.  Modifying the
> > > source data isn't always an option.
> > 
> > You can apply your overlays by path in this case..
> 
> Right, but my argument is that in this case it is a useful syntax to
> be able to delve deep into the tree, or deeper off of a label and
> delete nodes within it.  And it is actually a really simple thing to
> implement cleanly (as shown in the patch I posted).

Oh, it's perfectly easy to implement, yes.  It's the step up in
complexity of the mental model required that concerns me about it (now
each overlay in the stack can have some "transparent" and some
"opaque" parts).

-- 
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