[PATCH] Implements new features for updating existing device tree nodes.
David Gibson
david at gibson.dropbear.id.au
Sat Oct 16 20:05:55 EST 2010
On Sat, Oct 16, 2010 at 02:10:12AM -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:
> > > On Fri, 2010-10-15 at 20:35 -0600, Grant Likely wrote:
[snip]
> > > Ok, so maybe I misunderstood. I thought we had decided that node
> > > modifications would only happen at the top level, but now that I'm
> > > looking back through your examples earlier today, and I see this isn't
> > > true.
> >
> > Um.. that part of the discussion got confusing. I think only allowing
> > the operations (and I still don't think the set implemented here are
> > quite right, though they're close) at the top-level is a better idea.
> >
> > Grant, is there a reason you think we need to have replacement as an
> > option within each tree, rather than a "per-overlay-sheet" option.
>
> Yes, because I need the ability to remove/replace a child of a
> labelled node. Not every node that needs to be manipulated will
> necessarily have a label.
>
> 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.
Ah, I see. This could also be accomplished if we allowed overlays to
be targeted at (label + relative path) which we were talking about
anyway.
--
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 devicetree-discuss
mailing list