All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Markus Stockhausen" <markus.stockhausen@gmx.de>
Cc: conor+dt@kernel.org, robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH net-next v4 3/8] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus
Date: Fri, 10 Jul 2026 06:42:48 +0000	[thread overview]
Message-ID: <20260710064248.E5CC71F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260709064157.2865063-4-markus.stockhausen@gmx.de>

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

New issues:
- [High] The notify_phy_detach hook is called unconditionally in phy_detach(), even if notify_phy_attach() was never called or previously failed.

Pre-existing issues:
- [High] phy_attach_direct() incorrectly tears down existing legitimate PHY attachments when returning -EBUSY.
--

--- Patch [3]: [PATCH net-next v4 3/8] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus ---
commit 18f2ffc9e99b8190c4b5f1090de719a18f114275
Author: Daniel Golle <daniel@makrotopia.org>

net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus

This commit introduces notify_phy_attach and notify_phy_detach hooks to
struct mii_bus. These hooks allow the MDIO bus driver to perform
initialization and teardown steps when a PHY is attached or 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 I noticed something about the error
handling here and earlier in the function.

If phy_attach_direct() detects the PHY is already attached:

	if (phydev->attached_dev) {
		dev_err(&dev->dev, "PHY already attached\n");
		err = -EBUSY;
		goto error;
	}

The error label unconditionally calls phy_detach().

Will this tear down the active, legitimate attachment state of the original
owner instead of just aborting the current failed attach attempt?

> +	}
> +
>  	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: High]
If phy_attach_direct() fails early and jumps to the error label, it calls
phy_detach(), which completely bypasses notify_phy_attach() but
unconditionally invokes notify_phy_detach().

It also appears that if notify_phy_attach() itself returns an error,
phy_detach() will be called immediately.

Could this cause MDIO bus drivers to receive unbalanced detach events for a
PHY that was never successfully attached? Might this lead to NULL pointer
dereferences or double frees if the bus driver relies on the attach hook
to initialize state?

>  	if (phydev->devlink) {
>  		device_link_del(phydev->devlink);
>  		phydev->devlink = NULL;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709064157.2865063-1-markus.stockhausen@gmx.de?part=3

  reply	other threads:[~2026-07-10  6:42 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-09  6:41 [PATCH net-next v4 0/8] net: mdio: realtek-rtl9300: Add RTL83xx support Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 1/8] dt-bindings: net: realtek,rtl9301-mdio: Add RTL83xx series Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 2/8] net: mdio: realtek-rtl9300: Add polling documentation Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 3/8] net: phy: add (*notify_phy_attach/detach)() hooks to struct mii_bus Markus Stockhausen
2026-07-10  6:42   ` sashiko-bot [this message]
2026-07-09  6:41 ` [PATCH net-next v4 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 5/8] net: mdio: realtek-rtl9300: Add page tracking Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 6/8] net: mdio: realtek-rtl9300: Increase MDIO timeout Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 7/8] net: mdio: realtek-rtl9300: Add support for RTL838x Markus Stockhausen
2026-07-09  6:41 ` [PATCH net-next v4 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=20260710064248.E5CC71F00A3A@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.