Re: [PATCH net-next 1/2] net: stmmac: Don't use PHY loopback for selftests

[Oleksij Rempel <o.rempel@pengutronix.de>]

On Tue, Jul 28, 2026 at 05:57:26PM +0200, Maxime Chevallier wrote:
> Stmmac selftests validate the internal behaviour of the various IPs,
> using local loopback. The current logic is relies on PHY-side local
> loopback if a PHY is attached, with a fallback to MAC loopback
> otherwise.
> 
> However, PHY loopback is currently fragile especially for stmmac that
> may require RXC to be provided from the PHY. Some PHYs shutdown RXC
> while in loopback, while others will report carrier off when in local
> loopback. This also fails when using SFP setup with a module that embeds
> a PHY, that may also fail to enter loopback.
> 
> MAC loopback is done at the GMII level on dwmac, allowing the internal
> to be just as meaningful as PHY-loopback testing.
> 
> Let's simplify stmmac selftests by only relying on MAC-side local
> loopback, which makes the selftests runnable on a wider HW variety.
> 
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>  .../stmicro/stmmac/stmmac_selftests.c         | 112 ++----------------
>  1 file changed, 9 insertions(+), 103 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> index 29e824bd90ca..c0e5dee86451 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> @@ -374,25 +374,6 @@ static int stmmac_test_mac_loopback(struct stmmac_priv *priv)
>  	return __stmmac_test_loopback(priv, &attr);
>  }
>  
> -static int stmmac_test_phy_loopback(struct stmmac_priv *priv)
> -{
> -	struct stmmac_packet_attrs attr = { };
> -	int ret;
> -
> -	if (!priv->dev->phydev)
> -		return -EOPNOTSUPP;
> -
> -	ret = phy_loopback(priv->dev->phydev, true, 0);
> -	if (ret)
> -		return ret;
> -
> -	attr.dst = priv->dev->dev_addr;
> -	ret = __stmmac_test_loopback(priv, &attr);
> -
> -	phy_loopback(priv->dev->phydev, false, 0);
> -	return ret;
> -}
> -
>  static int stmmac_test_mmc(struct stmmac_priv *priv)
>  {
>  	struct stmmac_counters initial, final;
> @@ -1815,10 +1796,6 @@ static int stmmac_test_tbs(struct stmmac_priv *priv)
>  	return ret;
>  }
>  
> -#define STMMAC_LOOPBACK_NONE	0
> -#define STMMAC_LOOPBACK_MAC	1
> -#define STMMAC_LOOPBACK_PHY	2
> -
>  static const struct stmmac_test {
>  	char name[ETH_GSTRING_LEN];
>  	int lb;
> @@ -1826,131 +1803,96 @@ static const struct stmmac_test {
>  } stmmac_selftests[] = {
>  	{
>  		.name = "MAC Loopback               ",
> -		.lb = STMMAC_LOOPBACK_MAC,
>  		.fn = stmmac_test_mac_loopback,
> -	}, {
> -		.name = "PHY Loopback               ",
> -		.lb = STMMAC_LOOPBACK_NONE, /* Test will handle it */
> -		.fn = stmmac_test_phy_loopback,
>  	}, {
>  		.name = "MMC Counters               ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_mmc,
>  	}, {
>  		.name = "EEE                        ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_eee,

Hm, not sure this test can be properly executed in all conditions.
We do not support forced LPI mode from phylink perspective, and it is
not forced by the tests. If it passes, only by accident if link partner
local system and link partner advertise the EEE support. 

>  	}, {
>  		.name = "Hash Filter MC             ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_hfilt,
>  	}, {
>  		.name = "Perfect Filter UC          ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_pfilt,
>  	}, {
>  		.name = "MC Filter                  ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_mcfilt,
>  	}, {
>  		.name = "UC Filter                  ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_ucfilt,
>  	}, {
>  		.name = "Flow Control               ",
> -		.lb = STMMAC_LOOPBACK_PHY,
>  		.fn = stmmac_test_flowctrl,

Interesting test, it will be cool to have it in generic form. Probably
most of them, but it will be a lot of work.

So, yes - most of this tests do not relay on the PHY, instead - on some
kind of running link configuration. But this tests seems to not enforce
needed link configuration before and after patches - correct?

Best Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |