Re: [PATCH net-next v9 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct

[sashiko-bot@kernel.org]

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

Pre-existing issues:
- [High] In `phylink_create()`, if `phylink_register_sfp()` fails, the function frees `pl` without releasing the GPIO descriptor `pl->link_gpio`.
--

--- Patch [1]: [PATCH net-next v9 01/12] net: phylink: keep and use MAC supported_interfaces in phylink struct ---
commit 34f151721de84035e589a96b730a7b88905f81c9
Author: Christian Marangi <ansuelsmth@gmail.com>

net: phylink: keep and use MAC supported_interfaces in phylink struct

Adds a copy of supported_interfaces to the phylink struct and makes use of
that instead of relying on the phylink_config value. This prepares for
internal PCS handling where a PCS can be added or removed after creation.

> diff --git a/drivers/net/phy/phylink.c b/drivers/net/phy/phylink.c
> index 59dfe35afa54f..3464e3ec56997 100644
> --- a/drivers/net/phy/phylink.c
> +++ b/drivers/net/phy/phylink.c
[ ... ]
> @@ -1867,6 +1872,9 @@ struct phylink *phylink_create(struct phylink_config *config,
>  	mutex_init(&pl->state_mutex);
>  	INIT_WORK(&pl->resolve, phylink_resolve);
>  
> +	phy_interface_copy(pl->supported_interfaces,
> +			   config->supported_interfaces);
> +
>  	pl->config = config;

[Severity: High]
This isn't a bug introduced by this patch, but while reviewing
phylink_create(), I noticed a potential resource leak in its error handling.

If phylink_create() processes a fixed-link configuration that acquires a
GPIO descriptor (pl->link_gpio in phylink_parse_fixedlink()), and then the
subsequent call to phylink_register_sfp() returns an error like
-EPROBE_DEFER, the function frees pl but does not release the pl->link_gpio
descriptor:

drivers/net/phy/phylink.c:phylink_create() {
...
	ret = phylink_register_sfp(pl, fwnode);
	if (ret < 0) {
		kfree(pl);
		return ERR_PTR(ret);
	}
...
}

Does this cause the GPIO descriptor to remain held, preventing subsequent
probe attempts from succeeding since the GPIO request will fail with -EBUSY?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260717065448.1498335-1-ansuelsmth@gmail.com?part=1