From: Simon Horman <horms@kernel.org>
To: maxime.chevallier@bootlin.com
Cc: Simon Horman <horms@kernel.org>,
netdev@vger.kernel.org, andrew@lunn.ch, pabeni@redhat.com,
linux-kernel@vger.kernel.org, nicveronese@gmail.com,
kory.maincent@bootlin.com, f.fainelli@gmail.com,
o.rempel@pengutronix.de, kuba@kernel.org, mwojtas@chromium.org,
daniel@makrotopia.org, davem@davemloft.net,
dimitri.fedrau@liebherr.com, edumazet@google.com,
romain.gantois@bootlin.com, vladimir.oltean@nxp.com,
kabel@kernel.org, christophe.leroy@csgroup.eu,
thomas.petazzoni@bootlin.com, herve.codina@bootlin.com,
linux@armlinux.org.uk, hkallweit1@gmail.com
Subject: Re: [net-next,v3,06/11] net: phy: Represent PHY-less SFP modules with phy_port
Date: Tue, 3 Feb 2026 19:57:10 +0000 [thread overview]
Message-ID: <20260203195710.2176606-1-horms@kernel.org> (raw)
In-Reply-To: <20260201151249.642015-7-maxime.chevallier@bootlin.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
net: phy: Represent PHY-less SFP modules with phy_port
Now that the SFP bus infrastructure notifies when PHY-less modules are
connected, we can create a phy_port to represent it. Instead of letting
the SFP subsystem handle that, the Bus' upstream is in charge of
maintaining that phy_port and register it to the topology, as the
upstream (in this case a phy device) is directly interacting with the
underlying net_device.
Add a phy_caps helper to get the achievable modes on this module based
on what the phy_port representing the bus supports.
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
[ ... ]
> @@ -1609,6 +1613,74 @@ static void phy_sfp_link_down(void *upstream)
> +static int phy_add_sfp_mod_port(struct phy_device *phydev)
> +{
> + const struct sfp_module_caps *caps;
> + struct phy_port *port;
> + int ret = 0;
> +
> + /* Create mod port */
> + port = phy_port_alloc();
> + if (!port)
> + return -ENOMEM;
> +
> + port->active = true;
> +
> + caps = sfp_get_module_caps(phydev->sfp_bus);
> +
> + phy_caps_linkmode_filter_ifaces(port->supported, caps->link_modes,
> + phydev->sfp_bus_port->interfaces);
At line 1638, phy_add_sfp_mod_port() dereferences phydev->sfp_bus_port
without checking for NULL. Can this be NULL here?
Looking at the initialization in phy_sfp_probe(), when sfp_bus_add_upstream()
fails, the error path frees the port but then unconditionally stores it in
phydev->sfp_bus_port:
> @@ -1700,7 +1774,7 @@ static struct phy_port *phy_setup_sfp_port(struct phy_device *phydev)
> static int phy_sfp_probe(struct phy_device *phydev)
> {
> - struct phy_port *port;
> + struct phy_port *port = NULL;
> struct sfp_bus *bus;
> int ret;
>
> @@ -1729,6 +1803,8 @@ static int phy_sfp_probe(struct phy_device *phydev)
> phy_port_destroy(port);
> }
>
> + phydev->sfp_bus_port = port;
> +
> return ret;
> }
If sfp_bus_add_upstream() returns an error at line 1800, the cleanup path at
line 1802 checks 'ret && port', then calls phy_del_port() and
phy_port_destroy() to free the port. However, line 1806 still executes
'phydev->sfp_bus_port = port', which assigns the freed pointer to the
phydev structure.
When phy_sfp_probe() returns an error, probe fails and the PHY device is not
properly initialized. Later, if a PHY-less SFP module is inserted, the SFP
subsystem calls phy_sfp_module_start(), which calls phy_add_sfp_mod_port(),
which dereferences phydev->sfp_bus_port->interfaces at line 1638.
Should the assignment at line 1806 be conditional, or should port be set to
NULL after freeing?
next prev parent reply other threads:[~2026-02-03 19:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-01 15:12 [PATCH net-next v3 00/11] net: phy_port: SFP modules representation and phy_port listing Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 01/11] net: phy: phy_port: Correctly recompute the port's linkmodes Maxime Chevallier
2026-02-03 17:58 ` [net-next,v3,01/11] " Simon Horman
2026-02-03 18:13 ` Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 02/11] net: phy: phy_link_topology: Add a helper for opportunistic alloc Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 03/11] net: phy: phy_link_topology: Track ports in phy_link_topology Maxime Chevallier
2026-02-03 18:02 ` [net-next,v3,03/11] " Simon Horman
2026-02-03 18:11 ` Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 04/11] net: phylink: Register a phy_port for MAC-driven SFP busses Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 05/11] net: phy: Create SFP phy_port before registering usptream Maxime Chevallier
2026-02-03 17:52 ` Simon Horman
2026-02-03 18:09 ` Maxime Chevallier
2026-02-09 16:25 ` Simon Horman
2026-02-03 18:03 ` [net-next,v3,05/11] " Simon Horman
2026-02-03 18:12 ` Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 06/11] net: phy: Represent PHY-less SFP modules with phy_port Maxime Chevallier
2026-02-03 19:57 ` Simon Horman [this message]
2026-02-01 15:12 ` [PATCH net-next v3 07/11] net: phylink: " Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 08/11] net: phy: phy_port: Store information about a MII port's vacant state Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 09/11] net: phy: phy_link_topology: Add a helper to retrieve ports Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 10/11] netlink: specs: Add ethernet port listing with ethtool Maxime Chevallier
2026-02-03 17:55 ` Simon Horman
2026-02-03 18:14 ` Maxime Chevallier
2026-02-01 15:12 ` [PATCH net-next v3 11/11] net: ethtool: Introduce ethtool command to list ports Maxime Chevallier
2026-02-02 7:56 ` [PATCH net-next v3 00/11] net: phy_port: SFP modules representation and phy_port listing Maxime Chevallier
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=20260203195710.2176606-1-horms@kernel.org \
--to=horms@kernel.org \
--cc=andrew@lunn.ch \
--cc=christophe.leroy@csgroup.eu \
--cc=daniel@makrotopia.org \
--cc=davem@davemloft.net \
--cc=dimitri.fedrau@liebherr.com \
--cc=edumazet@google.com \
--cc=f.fainelli@gmail.com \
--cc=herve.codina@bootlin.com \
--cc=hkallweit1@gmail.com \
--cc=kabel@kernel.org \
--cc=kory.maincent@bootlin.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=maxime.chevallier@bootlin.com \
--cc=mwojtas@chromium.org \
--cc=netdev@vger.kernel.org \
--cc=nicveronese@gmail.com \
--cc=o.rempel@pengutronix.de \
--cc=pabeni@redhat.com \
--cc=romain.gantois@bootlin.com \
--cc=thomas.petazzoni@bootlin.com \
--cc=vladimir.oltean@nxp.com \
/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.