From: sashiko-bot@kernel.org
To: "Markus Stockhausen" <markus.stockhausen@gmx.de>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v6 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing
Date: Sat, 25 Jul 2026 05:56:55 +0000 [thread overview]
Message-ID: <20260725055655.E89991F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260724055611.1008577-5-markus.stockhausen@gmx.de>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `phy_poll` bitmap is declared and updated but never read, making it dead state-tracking code.
--
--- Patch [4]: [PATCH net-next v6 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing ---
commit 36d18db7d9886e2eab892060b1cf7964f32514e4
Author: Markus Stockhausen <markus.stockhausen@gmx.de>
net: mdio: realtek-rtl9300: Configure hardware polling during probing
This commit toggles hardware polling for the Realtek Otto switches during
initialization and PHY attach/detach. This helps avoid conflicts with
probing and firmware loading sequences.
Link: https://lore.kernel.org/netdev/680696024a8648535ce6dee771fe4de67802e0e8.1769053496.git.daniel@makrotopia.org/
> diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
> index 3dee5bff41349..4b70aaeb8c3b3 100644
> --- a/drivers/net/mdio/mdio-realtek-rtl9300.c
> +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c
[ ... ]
> @@ -200,6 +202,7 @@ struct otto_emdio_priv {
> const struct otto_emdio_info *info;
> struct regmap *regmap;
> struct mutex lock; /* protect HW access */
> + DECLARE_BITMAP(phy_poll, MAX_PORTS);
[Severity: Low]
Is this phy_poll bitmap actually needed?
It looks like this field is updated when ports are attached and detached,
but it doesn't appear to be read anywhere in the driver. Could we remove it
entirely to simplify the state tracking?
[ ... ]
> @@ -582,6 +592,44 @@ static int otto_emdio_9310_setup_controller(struct otto_emdio_priv *priv)
> return 0;
> }
>
> +static int otto_emdio_notify_phy_attach(struct phy_device *phydev)
> +{
[ ... ]
> + scoped_guard(mutex, &priv->lock) {
> + ret = otto_emdio_set_port_polling(priv, port, true);
> + if (!ret)
> + __set_bit(port, priv->phy_poll);
> + }
[Severity: Low]
If the bitmap is unread, can this __set_bit() update be dropped?
[ ... ]
> +static void otto_emdio_notify_phy_detach(struct phy_device *phydev)
> +{
[ ... ]
> + scoped_guard(mutex, &priv->lock) {
> + ret = otto_emdio_set_port_polling(priv, port, false);
> + if (!ret)
> + __clear_bit(port, priv->phy_poll);
> + }
[Severity: Low]
Similarly, this __clear_bit() update could also be removed if the bitmap
is dead state-tracking code.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260724055611.1008577-1-markus.stockhausen@gmx.de?part=4
next prev parent reply other threads:[~2026-07-25 5:56 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-24 5:56 [PATCH net-next v6 0/8] net: mdio: realtek-rtl9300: Add RTL83xx support Markus Stockhausen
2026-07-24 5:56 ` [PATCH net-next v6 1/8] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series Markus Stockhausen
2026-07-24 5:56 ` [PATCH net-next v6 2/8] net: mdio: realtek-rtl9300: Add polling documentation Markus Stockhausen
2026-07-24 5:56 ` [PATCH net-next v6 3/8] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus Markus Stockhausen
2026-07-25 5:56 ` sashiko-bot
2026-07-24 5:56 ` [PATCH net-next v6 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing Markus Stockhausen
2026-07-25 5:56 ` sashiko-bot [this message]
2026-07-24 5:56 ` [PATCH net-next v6 5/8] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-07-24 5:56 ` [PATCH net-next v6 6/8] net: mdio: realtek-rtl9300: Increase MDIO timeout Markus Stockhausen
2026-07-24 5:56 ` [PATCH net-next v6 7/8] net: mdio: realtek-rtl9300: Add support for RTL838x Markus Stockhausen
2026-07-24 5:56 ` [PATCH net-next v6 8/8] net: mdio: realtek-rtl9300: Add support for RTL839x Markus Stockhausen
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=20260725055655.E89991F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=markus.stockhausen@gmx.de \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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