Re: [net-next,v2,09/12] net: phy: phy_port: Store information about a MII port's occupancy

[Jakub Kicinski <kuba@kernel.org>]

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: phy_port: Store information about a MII port's occupancy

This patch adds an "occupied" bitfield to struct phy_port to track
whether an MII port has an SFP module inserted. The field is set in
connect_nophy callbacks and cleared in disconnect_nophy callbacks.

> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 21af1dffa837..bb257e91cdf6 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c

[ ... ]

> @@ -4047,6 +4047,8 @@ static int phylink_sfp_connect_nophy(void *upstream)
>  		}
>  	}
>
> +	pl->sfp_bus_port->occupied = true;

Note that phylink_sfp_connect_nophy() has a NULL check for sfp_bus_port
at the start of the function that returns early if it is NULL.

> +
>  	pl->mod_port = port;
>
>  	return 0;
> @@ -4056,6 +4058,8 @@ static void phylink_sfp_disconnect_nophy(void *upstream)
>  {
>  	struct phylink *pl = upstream;
>
> +	pl->sfp_bus_port->occupied = false;

Can this dereference a NULL pointer? When phylink is created with
PHYLINK_DEV type (rather than PHYLINK_NETDEV), pl->netdev is NULL and
phylink_create_sfp_port() returns early without setting sfp_bus_port.
The callbacks are still registered via sfp_bus_add_upstream(), so when
a PHY-less SFP module is later inserted and removed, this function
would be called with sfp_bus_port being NULL.

The connect function checks for NULL sfp_bus_port, but the disconnect
function does not. Should this have a similar guard?

> +
>  	if (pl->netdev)
>  		phy_link_topo_del_port(pl->netdev, pl->mod_port);