From: "zhangzekun (A)" <zhangzekun11@huawei.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Oleksij Rempel <o.rempel@pengutronix.de>, <robh@kernel.org>,
<saravanak@google.com>, <justin.chen@broadcom.com>,
<florian.fainelli@broadcom.com>, <andrew+netdev@lunn.ch>,
<kuba@kernel.org>, <kory.maincent@bootlin.com>,
<jacopo+renesas@jmondi.org>,
<kieran.bingham+renesas@ideasonboard.com>, <maddy@linux.ibm.com>,
<mpe@ellerman.id.au>, <npiggin@gmail.com>, <olteanv@gmail.com>,
<davem@davemloft.net>, <taras.chornyi@plvision.eu>,
<edumazet@google.com>, <pabeni@redhat.com>,
<sudeep.holla@arm.com>, <cristian.marussi@arm.com>,
<arm-scmi@vger.kernel.org>, <linuxppc-dev@lists.ozlabs.org>,
<linux-media@vger.kernel.org>, <netdev@vger.kernel.org>,
<devicetree@vger.kernel.org>, <chenjun102@huawei.com>
Subject: Re: [PATCH 1/9] of: Add warpper function of_find_node_by_name_balanced()
Date: Mon, 10 Feb 2025 14:47:28 +0800 [thread overview]
Message-ID: <c48952c7-716c-4302-949c-2c66ea102a3e@huawei.com> (raw)
In-Reply-To: <20250207153722.GA24886@pendragon.ideasonboard.com>
Hi, Laurent,
> I think we all agree that of_find_node_by_name() is miused, and that it
> shows the API isn't optimal. What we have different opinions on is how
> to make the API less error-prone. I think adding a new
> of_find_node_by_name_balanced() function works around the issue and
> doesn't improve the situation much, I would argue it makes things even
> more confusing.
>
> We have only 20 calls to of_find_node_by_name() with a non-NULL first
> argument in v6.14-rc1:
>
> arch/powerpc/platforms/chrp/pci.c: rtas = of_find_node_by_name (root, "rtas");
>
> The 'root' variable here is the result of a call to
> 'of_find_node_by_path("/")', so I think we could pass a null pointer
> instead to simplify things.
>
> arch/powerpc/platforms/powermac/pic.c: slave = of_find_node_by_name(master, "mac-io");
>
> Here I believe of_find_node_by_name() is called to find a *child* node
> of 'master'. of_find_node_by_name() is the wrong function for that.
>
> arch/sparc/kernel/leon_kernel.c: np = of_find_node_by_name(rootnp, "GAISLER_IRQMP");
> arch/sparc/kernel/leon_kernel.c: np = of_find_node_by_name(rootnp, "01_00d");
> arch/sparc/kernel/leon_kernel.c: np = of_find_node_by_name(nnp, "GAISLER_GPTIMER");
> arch/sparc/kernel/leon_kernel.c: np = of_find_node_by_name(nnp, "01_011");
>
> Here too the code seems to be looking for child nodes only (but I
> couldn't find a DT example or binding in-tree, so I'm not entirely
> sure).
>
> drivers/clk/ti/clk.c: return of_find_node_by_name(from, tmp);
>
> Usage here seems correct, the reference-count decrement is intended.
>
> drivers/media/i2c/max9286.c: i2c_mux = of_find_node_by_name(dev->of_node, "i2c-mux");
> drivers/media/platform/qcom/venus/core.c: enp = of_find_node_by_name(dev->of_node, node_name);
> drivers/net/dsa/bcm_sf2.c: ports = of_find_node_by_name(dn, "ports");
> drivers/net/dsa/hirschmann/hellcreek_ptp.c: leds = of_find_node_by_name(hellcreek->dev->of_node, "leds");
> drivers/net/ethernet/broadcom/asp2/bcmasp.c: ports_node = of_find_node_by_name(dev->of_node, "ethernet-ports");
> drivers/net/ethernet/marvell/prestera/prestera_main.c: ports = of_find_node_by_name(sw->np, "ports");
> drivers/net/pse-pd/tps23881.c: channels_node = of_find_node_by_name(priv->np, "channels");
> drivers/regulator/scmi-regulator.c: np = of_find_node_by_name(handle->dev->of_node, "regulators");
> drivers/regulator/tps6594-regulator.c: np = of_find_node_by_name(tps->dev->of_node, multi_regs[multi].supply_name);
>
> Incorrect usage, as far as I understand all those drivers are looking
> for child nodes only.
>
> drivers/of/unittest.c: found = of_find_node_by_name(nd->overlay, "test-unittest16");
> drivers/of/unittest.c: found = of_find_node_by_name(nd->overlay, "test-unittest17");
> drivers/of/unittest.c: found = of_find_node_by_name(nd->overlay, "test-unittest18");
> drivers/of/unittest.c: found = of_find_node_by_name(nd->overlay, "test-unittest19");
>
> Here too I think only child nodes are meant to be considered.
>
> of_find_node_by_name() is very much misused as most callers want to find
> child nodes, while of_find_node_by_name() will walk the whole DT from a
> given starting point.
>
> I think the right fix here is to
>
> - Replace of_find_node_by_name(root, ...) with
> of_find_node_by_name(NULL, ...) in arch/powerpc/platforms/chrp/pci.c
> (if my understanding of the code is correct).
For arch/powerpc/platforms/chrp/pci.c, noticing that there is a comment
in setup_peg2():
/* keep the reference to the root node */
It might can not be convert to of_find_node_by_name(NULL, ...), and the
origin use of of_find_node_by_name() put the ref count which want to be
kept.
>
> - Replace of_find_node_by_name() with of_get_child_by_name() in callers
> that need to search immediate children only (I expected that to be the
> majority of the above call sites)
Since there is no enough information about these DT nodes, it would take
time to prove if it is OK to make such convert.
>
> - If there are other callers that need to find indirect children,
> introduce a new of_get_child_by_name_recursive() function.
>
> At that point, the only remaining caller of of_find_node_by_name()
> (beside its usage in the for_each_node_by_name() macro) will be
> drivers/clk/ti/clk.c, which uses the function correctly.
>
> I'm tempted to then rename of_find_node_by_name() to
> __of_find_node_by_name() to indicate it's an internal function not meant
> to be called except in special cases. It could all be renamed to
> __of_find_next_node_by_name() to make its behaviour clearer.
>
The actual code logic of of_find_node_by_name() is more suitable to be
used in a loop.So,rename of_find_node_by_name() to
__of_find_next_node_by_name() seems to be a good idea.
Best regards,
Zekun
next prev parent reply other threads:[~2025-02-10 6:47 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-07 1:31 [PATCH 0/9] Add wrapper function of_find_node_by_name_balanced() Zhang Zekun
2025-02-07 1:31 ` [PATCH 1/9] of: Add warpper " Zhang Zekun
2025-02-07 8:24 ` Oleksij Rempel
2025-02-07 8:57 ` Laurent Pinchart
2025-02-07 11:28 ` zhangzekun (A)
2025-02-07 15:37 ` Laurent Pinchart
2025-02-08 4:18 ` Dan Carpenter
2025-04-25 15:30 ` Dan Carpenter
2025-04-25 17:07 ` Laurent Pinchart
2025-06-10 19:39 ` Andy Shevchenko
2025-06-10 20:03 ` Laurent Pinchart
2025-06-10 20:17 ` Andy Shevchenko
2025-02-10 6:47 ` zhangzekun (A) [this message]
2025-02-10 10:03 ` Laurent Pinchart
2025-02-11 11:26 ` zhangzekun (A)
2025-02-11 11:43 ` Laurent Pinchart
2025-02-11 14:15 ` Rob Herring
2025-02-12 5:47 ` Krzysztof Kozlowski
2025-02-07 1:31 ` [PATCH 2/9] net: bcmasp: Add missing of_node_get() before of_find_node_by_name() Zhang Zekun
2025-02-12 5:52 ` Krzysztof Kozlowski
2025-02-12 6:50 ` zhangzekun (A)
2025-02-07 1:31 ` [PATCH 3/9] net: pse-pd: " Zhang Zekun
2025-02-07 1:31 ` [PATCH 4/9] media: max9286: Use of_find_node_by_name_balanced() to find device_node Zhang Zekun
2025-02-07 1:31 ` [PATCH 5/9] powerpc: " Zhang Zekun
2025-02-07 1:31 ` [PATCH 6/9] net: dsa: " Zhang Zekun
2025-02-07 1:31 ` [PATCH 7/9] net: dsa: hellcreek: " Zhang Zekun
2025-02-07 1:31 ` [PATCH 8/9] net: prestera: " Zhang Zekun
2025-02-07 1:31 ` [PATCH 9/9] regulator: scmi: " Zhang Zekun
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c48952c7-716c-4302-949c-2c66ea102a3e@huawei.com \
--to=zhangzekun11@huawei.com \
--cc=andrew+netdev@lunn.ch \
--cc=arm-scmi@vger.kernel.org \
--cc=chenjun102@huawei.com \
--cc=cristian.marussi@arm.com \
--cc=davem@davemloft.net \
--cc=devicetree@vger.kernel.org \
--cc=edumazet@google.com \
--cc=florian.fainelli@broadcom.com \
--cc=jacopo+renesas@jmondi.org \
--cc=justin.chen@broadcom.com \
--cc=kieran.bingham+renesas@ideasonboard.com \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=netdev@vger.kernel.org \
--cc=npiggin@gmail.com \
--cc=o.rempel@pengutronix.de \
--cc=olteanv@gmail.com \
--cc=pabeni@redhat.com \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=sudeep.holla@arm.com \
--cc=taras.chornyi@plvision.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox