netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: "zhangzekun (A)" <zhangzekun11@huawei.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 12:03:07 +0200	[thread overview]
Message-ID: <20250210100307.GA2966@pendragon.ideasonboard.com> (raw)
In-Reply-To: <c48952c7-716c-4302-949c-2c66ea102a3e@huawei.com>

Hi Zekun,

On Mon, Feb 10, 2025 at 02:47:28PM +0800, zhangzekun (A) wrote:
> > 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.

But the reference is dropped by of_find_node_by_name(). Unless I'm
missing something, dropping the lien

	struct device_node *root = of_find_node_by_path("/");

and changing

	rtas = of_find_node_by_name (root, "rtas");

to

	rtas = of_find_node_by_name (NULL, "rtas");

will not change the behaviour of the code.

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

It will take a bit of time, yes. I'm afraid time is needed to improve
things :-) In most cases, as DT bindings are available, it shouldn't be
very difficult.

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

-- 
Regards,

Laurent Pinchart

  reply	other threads:[~2025-02-10 10:03 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)
2025-02-10 10:03           ` Laurent Pinchart [this message]
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=20250210100307.GA2966@pendragon.ideasonboard.com \
    --to=laurent.pinchart@ideasonboard.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=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 \
    --cc=zhangzekun11@huawei.com \
    /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;
as well as URLs for NNTP newsgroup(s).