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 3/3] net: mdio: realtek-rtl9300: Support non-default clock frequency
Date: Wed, 09 Sep 2026 03:20:13 +0000 [thread overview]
Message-ID: <178892401327.219967.6510304373643539035@kernel.org> (raw)
In-Reply-To: <20260906081946.3499898-4-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] RTL839x: a device tree that is fully valid against
realtek,rtl9301-mdio.yaml can make the entire MDIO controller fail to…
--
net: mdio: realtek-rtl9300: Support non-default clock frequency
This adds a per-family set_bus_frequency() callback so the MDC clock of
the Realtek Otto MDIO controllers can be selected from the device tree
via clock-frequency, defaulting to 2.5 MHz. RTL839x only has a single
global frequency field, so the driver caches the first programmed value
and rejects a second bus asking for something else.
> diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
> index 429321e9114fd..8edb0ba0bcdd1 100644
> --- a/drivers/net/mdio/mdio-realtek-rtl9300.c
> +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
[ ... ]
> @@ -749,6 +768,40 @@ static int otto_emdio_8380_setup_controller(struct otto_emdio_priv *priv)
> return regmap_set_bits(priv->regmap, RTL8380_SMI_GLB_CTRL, RTL8380_SMI_PHY_PATCH_DONE);
> }
>
> +static int otto_emdio_8390_set_bus_frequency(struct mii_bus *bus, u32 freq)
> +{
> + struct otto_emdio_priv *priv = otto_emdio_bus_to_priv(bus);
> + u32 val;
> + int err;
> +
> + if (freq != 1250000 && freq != 2500000 && freq != 5000000)
> + return -EINVAL;
> + if (priv->global_freq)
> + return freq == priv->global_freq ? 0 : -EINVAL;
> +
> + val = FIELD_PREP(RTL8390_SMI_FREQ_SEL, freq / 2500000);
> + err = regmap_update_bits(priv->regmap, RTL8390_SMI_GLB_CTRL, RTL8390_SMI_FREQ_SEL, val);
> + if (!err)
> + priv->global_freq = freq;
> +
> + return err;
> +}
[Severity: High]
Can a device tree that is valid against realtek,rtl9301-mdio.yaml make the
whole RTL839x controller fail to probe here?
The binding describes clock-frequency as an independent per-bus property of
each mdio-bus@N child, with an implicit default:
Documentation/devicetree/bindings/net/realtek,rtl9301-mdio.yaml
clock-frequency:
default: 2500000
and the realtek,rtl8391-mdio / rtl8392-mdio / rtl8393-mdio conditional only
restricts the allowed values per child bus:
clock-frequency:
enum: [1250000, 2500000, 5000000]
There is nothing in the schema requiring the two RTL839x child buses to name
the same frequency, so the natural way to express "set the shared field to
5 MHz" is:
mdio-bus@0 {
reg = <0>;
clock-frequency = <5000000>;
...
};
mdio-bus@1 {
reg = <1>;
...
};
Because otto_emdio_probe_one() substitutes the default before calling the
callback:
if (of_property_read_u32(node, "clock-frequency", &freq))
freq = 2500000;
an absent property is indistinguishable from an explicit 2.5 MHz request.
Doesn't that mean the second bus reaches
otto_emdio_8390_set_bus_frequency() with freq = 2500000 while
priv->global_freq is already 5000000, and
if (priv->global_freq)
return freq == priv->global_freq ? 0 : -EINVAL;
returns -EINVAL for a device tree that never asked for two different
frequencies? The reverse node ordering fails the same way.
otto_emdio_probe() aborts on the first failing child:
for_each_child_of_node_scoped(dev->of_node, child) {
err = otto_emdio_probe_one(dev, priv, child);
if (err)
return err;
}
so no MDIO bus is registered at all and none of the PHYs behind the switch
are reachable. The message "cannot set frequency 2500000 for MDIO bus 1"
also does not point at anything the device tree actually contains.
Would it make sense to either express the RTL839x restriction in the binding
(a controller level property or a dedicated conditional/schema), or to treat
an absent per-bus clock-frequency as "no constraint" instead of an explicit
2.5 MHz request, so that a schema legal device tree keeps probing?
> +
> static int otto_emdio_9300_set_bus_frequency(struct mii_bus *bus, u32 freq)
[ ... ]
> @@ -865,6 +933,13 @@ 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);
>
> + if (of_property_read_u32(node, "clock-frequency", &freq))
> + freq = 2500000;
> + err = priv->info->set_bus_frequency(bus, freq);
> + if (err)
> + return dev_err_probe(dev, err, "cannot set frequency %u for MDIO bus %d\n",
> + freq, mdio_bus);
> +
> err = devm_of_mdiobus_register(dev, bus, node);
> if (err)
> return dev_err_probe(dev, err, "cannot register MDIO bus\n");
[ ... ]
--
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260906081946.3499898-1-markus.stockhausen%40gmx.de
prev 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
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 [this message]
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=178892401327.219967.6510304373643539035@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.