Re: [PATCH net-next v2 7/9] net: stmmac: qcom-ethqos: set initial RGMII link clock to lowest speed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Changing the initial RGMII TX clock to SPEED_10 (2.5 MHz) breaks the hardware DLL lock sequence during 1 Gbps link up, causing a 1-second atomic busy-wait timeout and failing the DLL configuration.
--

commit 36a5f61a268a7a30466d5832cfdaa8bd8c6ffce7
Author: Mohd Ayaan Anwar <mohd.anwar@oss.qualcomm.com>

net: stmmac: qcom-ethqos: set initial RGMII link clock to lowest speed

This commit changes the initial RGMII link clock rate on probe from SPEED_1000
(250 MHz) to SPEED_10 (2.5 MHz) to save power when no PHY link is present.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index a92bf4a6a2dbd..2471871562ed9 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -814,7 +814,7 @@ static int qcom_ethqos_probe(struct platform_device *pdev)
>  				     "Failed to get serdes phy\n");
>  
>  	ethqos_set_clk_tx_rate(ethqos, NULL, plat_dat->phy_interface,
> -			       SPEED_1000);
> +			       SPEED_10);

[Severity: High]
Does this change break the hardware DLL lock sequence during a 1 Gbps link up?

The commit message states that fix_mac_speed updates the rate once a link is
established, but looking at stmmac_mac_link_up(), the STMMAC core invokes the
fix_mac_speed callback before it updates the TX clock rate:

stmmac_mac_link_up() {
    ...
	if (priv->plat->fix_mac_speed)
		priv->plat->fix_mac_speed(priv->plat->bsp_priv, interface,
					  speed, mode);
    [ ... ]
	if (priv->plat->set_clk_tx_rate) {
		ret = priv->plat->set_clk_tx_rate(priv->plat->bsp_priv, ...);
    ...
}

Because the clock is still physically running at 2.5 MHz when
ethqos_fix_mac_speed_rgmii() is called, it attempts to lock the hardware DLL
for 1 Gbps with the incorrect clock speed.

Will this cause ethqos_fix_mac_speed_rgmii() to busy-wait for 1 second in
read_poll_timeout_atomic() and ultimately fail the DLL configuration, breaking
1 Gbps TX connectivity?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260908-shikra_ethernet-v2-0-bbe3389d0652@oss.qualcomm.com?part=7