Re: [PATCH net-next v13 06/10] net: stmmac: qcom-ethqos: update phy_mode to the resolved interface in mac_finish()

[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.
---
net: stmmac: qcom-ethqos: update phy_mode to the resolved interface in mac_finish()

This patch updates ethqos->phy_mode from the interface argument in
ethqos_mac_finish_serdes() so that it always reflects the last resolved
interface, avoiding a stale value being observed by later
serdes_powerup()/serdes_powerdown() calls when the runtime interface
differs from the DT phy-mode.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> index 47b70b5e706f..9d19203ae4bd 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-qcom-ethqos.c
> @@ -632,6 +632,12 @@ static int ethqos_mac_finish_serdes(struct net_device *ndev, void *priv,
>  	struct qcom_ethqos *ethqos = priv;
>  	int ret = 0;
>  
> +	/* The interface mode is only known once phylink has resolved it and
> +	 * may change at runtime, so keep it in sync for later
> +	 * serdes_powerup()/serdes_powerdown() calls.
> +	 */
> +	ethqos->phy_mode = interface;
> +
>  	qcom_ethqos_set_sgmii_loopback(ethqos, false);

[High]
Is the ordering here safe with respect to qcom_ethqos_set_sgmii_loopback()?

That helper early-returns unless ethqos->phy_mode equals
PHY_INTERFACE_MODE_2500BASEX:

    static void
    qcom_ethqos_set_sgmii_loopback(struct qcom_ethqos *ethqos, bool enable)
    {
            if (!ethqos->needs_sgmii_loopback ||
                ethqos->phy_mode != PHY_INTERFACE_MODE_2500BASEX)
                    return;
            ...
    }

Because ethqos->phy_mode is now overwritten with the freshly resolved
interface before the qcom_ethqos_set_sgmii_loopback(ethqos, false) call,
does that clear-side path still fire when the interface transitions away
from 2500BASE-X?

Consider a needs_sgmii_loopback platform (for example sa8775p) with a DT
phy-mode of 2500BASE-X. At probe time ethqos_clks_config(true) asserts
SGMII_PHY_CNTRL1_SGMII_TX_TO_RX_LOOPBACK_EN in the wrapper while
ethqos->phy_mode is still the DT value 2500BASE-X. If phylink later
resolves the interface to SGMII and calls ethqos_mac_finish_serdes():

    ethqos->phy_mode = interface;                   /* now SGMII */
    qcom_ethqos_set_sgmii_loopback(ethqos, false);  /* early-return */

Does the port then enter SGMII operation with the wrapper TX-to-RX
loopback bit still asserted, which is the exact 2500BASE-X to SGMII
runtime-transition scenario the commit message says it wants to make
work?

Would calling qcom_ethqos_set_sgmii_loopback(ethqos, false) first,
against the old phy_mode, and only then assigning
ethqos->phy_mode = interface avoid this?

The commit message describes the change only in terms of
serdes_powerup()/serdes_powerdown():

    ethqos->phy_mode is read by serdes_powerup() and
    qcom_ethqos_set_sgmii_loopback() to configure the SerDes and its
    wrapper for the correct interface.
    ...
    Update ethqos->phy_mode from the interface argument in
    ethqos_mac_finish_serdes() so that it always reflects the last
    resolved interface.

Should it also mention that the assignment changes what the immediately
following qcom_ethqos_set_sgmii_loopback(ethqos, false) observes?

For reference, this appears to be addressed later in the same series by
commit 8d1efdf990fc ("net: stmmac: qcom-ethqos: fix SGMII loopback not
set on resume after speed change"), which extends the guard in
qcom_ethqos_set_sgmii_loopback() to also match PHY_INTERFACE_MODE_SGMII.
That follow-up commit message frames the fix as a set-side DMA-reset
timeout on resume, but does the same guard change also happen to unbreak
the clear-side path introduced here? If so, would it be worth either
reordering the two statements in this patch or folding the guard update
in ahead of this one to avoid a bisect window where the SGMII wrapper
loopback stays asserted after a 2500BASE-X to SGMII transition?

>  
>  	if (interface == PHY_INTERFACE_MODE_SGMII ||

[ ... ]