Re: [PATCH net-next 4/8] net: mdio: realtek-rtl9300: Configure hardware polling during probing

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardware polling mitigation is bypassed by deferred, asynchronous, or late PHY driver probing.
--

commit f401bbac0c9ccd3010cafd736b0916dccaad8dca
Author: Markus Stockhausen <markus.stockhausen@gmx.de>

net: mdio: realtek-rtl9300: Configure hardware polling during probing

This patch provides helpers to enable or disable hardware polling for a
specific port. It uses these to temporarily disable hardware polling during
MDIO bus probing to prevent interference with complex PHY initialization
sequences, re-enabling it afterwards.

> diff --git a/drivers/net/mdio/mdio-realtek-rtl9300.c b/drivers/net/mdio/mdio-realtek-rtl9300.c
> index c3a9eeca31540..a7fd075947b67 100644
> --- a/drivers/net/mdio/mdio-realtek-rtl9300.c
> +++ b/drivers/net/mdio/mdio-realtek-rtl9300.c

[ ... ]

> @@ -750,6 +759,13 @@ static int otto_emdio_probe(struct platform_device *pdev)
>  	if (IS_ERR(priv->regmap))
>  		return PTR_ERR(priv->regmap);
>  
> +	/* Avoid issues with complex firmware loads. */
> +	for (port = 0; port < priv->info->num_ports; port++) {
> +		err = otto_emdio_set_port_polling(priv, port, false);
> +		if (err)
> +			return err;
> +	}
> +
>  	platform_set_drvdata(pdev, priv);
>  
>  	err = otto_emdio_map_ports(dev);

[ ... ]

> @@ -772,6 +788,12 @@ static int otto_emdio_probe(struct platform_device *pdev)
>  			return err;
>  	}
>  
> +	for_each_set_bit(port, priv->valid_ports, priv->info->num_ports) {
> +		err = otto_emdio_set_port_polling(priv, port, true);
> +		if (err)
> +			return err;
> +	}
> +

[Severity: Medium]
Could this hardware polling mitigation be bypassed if a PHY driver defers
probing or loads asynchronously?

The mitigation temporarily disables polling across the MDIO bus registration
and re-enables it here unconditionally. Since PHY devices are registered as
children of the MDIO bus, they might bind to their drivers asynchronously,
return -EPROBE_DEFER, or be bound later via sysfs.

If that happens, wouldn't the PHY initialize while the hardware polling is
already re-enabled, potentially causing the interference this patch is trying
to avoid?

>  	return 0;
>  }

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