All of lore.kernel.org
 help / color / mirror / Atom feed
From: netdev-bot+sashiko@kernel.org
To: markus.stockhausen@gmx.de
Cc: andrew@lunn.ch, hkallweit1@gmail.com, linux@armlinux.org.uk,
	davem@davemloft.net, edumazet@google.com, kuba@kernel.org,
	pabeni@redhat.com, netdev@vger.kernel.org,
	chris.packham@alliedtelesis.co.nz, robh@kernel.org,
	krzk+dt@kernel.org, conor+dt@kernel.org,
	devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v2 2/3] net: mdio: realtek-rtl9300: Convert "fwnode" left-overs to "of"
Date: Wed, 09 Sep 2026 03:20:11 +0000	[thread overview]
Message-ID: <178892401189.219967.6693494754880026860@kernel.org> (raw)
In-Reply-To: <20260906081946.3499898-3-markus.stockhausen@gmx.de>

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 1 · Medium: 0 · Low: 0

- [High] Non-equivalent API conversion in otto_emdio_probe(): replacing
  `device_for_each_child_node_scoped(dev, child)` with…

--

net: mdio: realtek-rtl9300: Convert "fwnode" left-overs to "of"

This converts the remaining fwnode based property/child-node accesses in
the rtl9300 MDIO driver over to the OF API, and re-indents the
continuation line of otto_emdio_probe_one().

> diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
> index 11d078ef941cd..429321e9114fd 100644
> --- a/drivers/net/mdio/mdio-realtek-rtl9300.c
> +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
> @@ -831,14 +831,14 @@ static void otto_emdio_notify_phy_detach(struct phy_device *phydev)
>  }
>  
>  static int otto_emdio_probe_one(struct device *dev, struct otto_emdio_priv *priv,
> -				 struct fwnode_handle *node)
> +				struct device_node *node)
>  {
>  	struct otto_emdio_chan *chan;
>  	struct mii_bus *bus;
>  	u32 mdio_bus;
>  	int err;
>  
> -	err = fwnode_property_read_u32(node, "reg", &mdio_bus);
> +	err = of_property_read_u32(node, "reg", &mdio_bus);
>  	if (err)
>  		return dev_err_probe(dev, err, "undefined smi bus number\n");
>  
> @@ -865,7 +865,7 @@ static int otto_emdio_probe_one(struct device *dev, struct otto_emdio_priv *priv
>  
>  	snprintf(bus->id, MII_BUS_ID_SIZE, "%s-%d", dev_name(dev), mdio_bus);
>  
> -	err = devm_of_mdiobus_register(dev, bus, to_of_node(node));
> +	err = devm_of_mdiobus_register(dev, bus, node);
>  	if (err)
>  		return dev_err_probe(dev, err, "cannot register MDIO bus\n");
>  
> @@ -1027,7 +1027,7 @@ static int otto_emdio_probe(struct platform_device *pdev)
>  			return dev_err_probe(dev, err, "failed to setup MDIO bus controller\n");
>  	}
>  
> -	device_for_each_child_node_scoped(dev, child) {
> +	for_each_child_of_node_scoped(dev->of_node, child) {

[Severity: High]

Is this iterator swap intended to be behaviour preserving?  The two
iterators differ in whether they honour the DT status property.

The old one dispatched into the OF fwnode ops:

drivers/of/property.c:of_fwnode_get_next_child_node() {
	return of_fwnode_handle(of_get_next_available_child(to_of_node(fwnode),
							    to_of_node(child)));
}

The new one does not filter:

include/linux/of.h
#define for_each_child_of_node_scoped(parent, child) \
	for (struct device_node *child __free(device_node) =		\
	     of_get_next_child(parent, NULL);				\
	     child != NULL;						\
	     child = of_get_next_child(parent, child))

So nodes with status = "disabled" now reach otto_emdio_probe_one().

Does that turn a disabled bus child into a probe failure for the whole
controller?  A disabled mdio-bus@N node still has a valid reg, so it
passes the reg and num_buses checks and ends up in:

	err = devm_of_mdiobus_register(dev, bus, node);
	if (err)
		return dev_err_probe(dev, err, "cannot register MDIO bus\n");

which reaches:

drivers/net/mdio/of_mdio.c:__of_mdiobus_register() {
	/* Do not continue if the node is disabled */
	if (!of_device_is_available(np))
		return -ENODEV;

and otto_emdio_probe() propagates that error immediately:

	for_each_child_of_node_scoped(dev->of_node, child) {
		err = otto_emdio_probe_one(dev, priv, child);
		if (err)
			return err;
	}

Previously the disabled child was skipped and the enabled buses still
came up.

This looks reachable with in-tree DT: arch/mips/boot/dts/realtek/rtl930x.dtsi
ships all four mdio-bus@0..3 children with status = "disabled", so boards
that enable the controller plus only the buses they use would now fail
probe entirely.

There is also a CONFIG_OF_MDIO=n variant of the same concern: the stub
devm_of_mdiobus_register() in include/linux/of_mdio.h forwards to
devm_mdiobus_register() with no availability check, so a DT-disabled bus
would be registered and address-scanned instead.

Finally, the sibling OF walk in the same driver still filters on
availability:

	for_each_available_child_of_node_scoped(ports_dn, port_dn) {

so otto_emdio_map_ports() and the bus enumeration would no longer agree on
which nodes are usable.  Would for_each_available_child_of_node_scoped(dev->of_node, child)
be the equivalent conversion here?

Note this is still present at the end of the series, in otto_emdio_probe()
at e4ad7bb3a35d ("net: mdio: realtek-rtl9300: Support non-default clock
frequency").

>  		err = otto_emdio_probe_one(dev, priv, child);
>  		if (err)
>  			return err;

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260906081946.3499898-1-markus.stockhausen%40gmx.de

  parent reply	other threads:[~2026-09-09  3:20 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-06  8:19 [PATCH net-next v2 0/3] net: mdio: realtek-rtl9300: add bus frequency handling Markus Stockhausen
2026-09-06  8:19 ` [PATCH net-next v2 1/3] dt-bindings: net: realtek,rtl9301-mdio: Add clock-frequency Markus Stockhausen
2026-09-07 17:30   ` Conor Dooley
2026-09-09  3:20   ` netdev-bot+sashiko
2026-09-06  8:19 ` [PATCH net-next v2 2/3] net: mdio: realtek-rtl9300: Convert "fwnode" left-overs to "of" Markus Stockhausen
2026-09-08  0:39   ` Andrew Lunn
2026-09-09  3:20   ` netdev-bot+sashiko [this message]
2026-09-06  8:19 ` [PATCH net-next v2 3/3] net: mdio: realtek-rtl9300: Support non-default clock frequency Markus Stockhausen
2026-09-08  0:41   ` Andrew Lunn
2026-09-09  3:20   ` netdev-bot+sashiko

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=178892401189.219967.6693494754880026860@kernel.org \
    --to=netdev-bot+sashiko@kernel.org \
    --cc=andrew@lunn.ch \
    --cc=chris.packham@alliedtelesis.co.nz \
    --cc=conor+dt@kernel.org \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=kuba@kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=markus.stockhausen@gmx.de \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=robh@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.