[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAL_Jsq+0pX7P70OE8suhCpSsffPcqQffLEUqc3+LSX7ocf-iXg@mail.gmail.com>
Date: Mon, 12 Aug 2024 14:24:21 -0600
From: Rob Herring <robh@...nel.org>
To: Bjorn Andersson <andersson@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Felipe Balbi <balbi@...nel.org>,
Wesley Cheng <quic_wcheng@...cinc.com>, Saravana Kannan <saravanak@...gle.com>,
Thinh Nguyen <Thinh.Nguyen@...opsys.com>, Philipp Zabel <p.zabel@...gutronix.de>,
Konrad Dybcio <konrad.dybcio@...aro.org>, linux-usb@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, Bjorn Andersson <quic_bjorande@...cinc.com>
Subject: Re: [PATCH v2 3/7] of: dynamic: Don't discard children upon node attach
On Sun, Aug 11, 2024 at 9:07 PM Bjorn Andersson <andersson@...nel.org> wrote:
>
> From: Bjorn Andersson <quic_bjorande@...cinc.com>
>
> 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.
> 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@...cinc.com>
> ---
> 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? 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.
This all seems fragile on top of what's already fragile.
Rob
Powered by blists - more mailing lists