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 v2 3/8] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus
Date: Tue, 30 Jun 2026 15:24:28 +0000 [thread overview]
Message-ID: <20260630152428.7DBD01F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260629152336.2239826-4-markus.stockhausen@gmx.de>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Medium] The `notify_phy_detach` hook can be invoked on an MDIO bus even if `notify_phy_attach` was never called or failed, leading to unbalanced setup/teardown symmetry.
Pre-existing issues:
- [High] Calling `phy_attach_direct` on an already attached PHY returns `-EBUSY` but incorrectly executes the `phy_detach` error path, destroying the existing valid attachment.
--
commit c461faab1a569fa9ec7dc7cc9fc30615fc89408c
Author: Daniel Golle <daniel@makrotopia.org>
net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus
Some MDIO buses require to program PHY polling registers depending on
the PHY type. Provide two simple hooks in struct mii_bus which are called
right after a PHY has been attached and just before the PHY is going to be
detached.
Link: https://github.com/openwrt/openwrt/pull/21515#discussion_r2714069716
Link: https://lore.kernel.org/netdev/cover.1769053496.git.daniel@makrotopia.org/
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 0615228459ef4..676cbf183350d 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -1876,6 +1876,12 @@ int phy_attach_direct(struct net_device *dev, struct phy_device *phydev,
> if (err)
> goto error;
>
> + if (phydev->mdio.bus->notify_phy_attach) {
> + err = phydev->mdio.bus->notify_phy_attach(phydev);
> + if (err)
> + goto error;
[Severity: High]
This is a pre-existing issue, but calling phy_attach_direct() on an already
attached PHY seems to tear down the existing valid attachment. Earlier in
this function:
if (phydev->attached_dev) {
dev_err(&dev->dev, "PHY already attached\n");
err = -EBUSY;
goto error;
}
Jumping to the error label unconditionally executes phy_detach(), which
clears phydev->attached_dev (the original owner) and severs the
dev->phydev link.
Should this path return an error directly without calling phy_detach()?
> + }
> +
> phy_resume(phydev);
[ ... ]
> @@ -1919,6 +1925,9 @@ void phy_detach(struct phy_device *phydev)
> struct module *ndev_owner = NULL;
> struct mii_bus *bus;
>
> + if (phydev->mdio.bus->notify_phy_detach)
> + phydev->mdio.bus->notify_phy_detach(phydev);
> +
[Severity: Medium]
Will notify_phy_detach() be invoked even if notify_phy_attach() was never
called or failed?
If phy_init_hw() or any other initialization step prior to
notify_phy_attach() fails in phy_attach_direct(), the code jumps to the
error label and calls phy_detach(), which now unconditionally executes
notify_phy_detach().
Could this lead to unbalanced setup/teardown symmetry if a bus driver
assumes notify_phy_detach() is only called after a successful
notify_phy_attach()?
> if (phydev->devlink) {
> device_link_del(phydev->devlink);
> phydev->devlink = NULL;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260629152336.2239826-1-markus.stockhausen@gmx.de?part=3
next prev parent reply other threads:[~2026-06-30 15:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-29 15:23 [PATCH net-next v2 0/8] net: mdio: realtek-rtl9300: Add RTL83xx support Markus Stockhausen
2026-06-29 15:23 ` [PATCH net-next v2 1/8] net: mdio: realtek-rtl9300: Add polling documentation Markus Stockhausen
2026-06-29 16:21 ` Andrew Lunn
2026-06-29 15:23 ` [PATCH net-next v2 2/8] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-06-29 16:28 ` Andrew Lunn
2026-06-29 17:25 ` AW: " Markus Stockhausen
2026-06-29 15:23 ` [PATCH net-next v2 3/8] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus Markus Stockhausen
2026-06-30 15:24 ` sashiko-bot [this message]
2026-06-29 15:23 ` [PATCH net-next v2 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing Markus Stockhausen
2026-06-29 16:38 ` Andrew Lunn
2026-07-03 2:24 ` Chris Packham
2026-06-30 15:24 ` sashiko-bot
2026-06-29 15:23 ` [PATCH net-next v2 5/8] net: mdio: realtek-rtl9300: Add c45 over c22 mitigation Markus Stockhausen
2026-06-29 16:40 ` Andrew Lunn
2026-06-29 17:29 ` AW: " Markus Stockhausen
2026-06-29 15:23 ` [PATCH net-next v2 6/8] net: mdio: realtek-rtl9300: Increase MDIO timeout Markus Stockhausen
2026-06-29 15:23 ` [PATCH net-next v2 7/8] net: mdio: realtek-rtl9300: Add support for RTL838x Markus Stockhausen
2026-06-29 15:23 ` [PATCH net-next v2 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=20260630152428.7DBD01F00A3A@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 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.