On Mon, Aug 12, 2024 at 02:24:21PM -0600, Rob Herring wrote: > On Sun, Aug 11, 2024 at 9:07 PM Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > > > From: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx> > > > > When dynamically modifying DeviceTree it's useful to be able to reparent > > nodes, but of_attach_node() clear the child pointer and hence discards > > any child nodes. > > of_attach_node() is kind of the legacy API. You should be using > changeset API. But I guess you really mean __of_attach_node() here > which both use. > I failed to spot the changeset part of the API, that does indeed look like a more robust solution. I will look into this, thanks. > > Retain the child pointer upon attach, so that the client code doesn't > > need to manually rebuild the tree. > > > > Current users of of_attach_node() either avoids attaching nodes with > > children or explicitly attaches nodes without children, so no impact is > > expected to current users. > > > > Signed-off-by: Bjorn Andersson <quic_bjorande@xxxxxxxxxxx> > > --- > > drivers/of/dynamic.c | 1 - > > 1 file changed, 1 deletion(-) > > > > diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c > > index 110104a936d9..32e1dffd9f96 100644 > > --- a/drivers/of/dynamic.c > > +++ b/drivers/of/dynamic.c > > @@ -221,7 +221,6 @@ static void __of_attach_node(struct device_node *np) > > np->phandle = 0; > > } > > > > - np->child = NULL; > > np->sibling = np->parent->child; > > np->parent->child = np; > > of_node_clear_flag(np, OF_DETACHED); > > Before OF_DETACHED had a clear meaning. Now, are child nodes detached > or not? As far as I understood, the detached node will have children and as I re-attach it, those children will just be leaked. The current (few) clients are then making sure not to detach nodes with cihldren. Perhaps the expectation is that the client will have traversed and detached the children, and will then reattach them here? Or perhaps the intention was to never allow detaching and reattaching a node with children? > If it means not attached to the root tree, then it is > redundant having it per node. If it means parent and sibling aren't > set, then what's the point as we can just check for NULL ptrs. > In practice, my goal is to detach the "ports" node from one parent and attach it to another node, without breaking the graph. In patch 6 this is used as: of_node_detach(child); child->parent = new; of_node_attach(child); > This all seems fragile on top of what's already fragile. > No concerns with that statement, I will start investigate the changeset API. I appreciate any guidance related to reparenting my graph node. > Rob Thank you, Bjorn
