[PATCH net 0/6] net: stmmac: More selftest related fixes

[PATCH net 0/6] net: stmmac: More selftest related fixes

[Maxime Chevallier]

Hello everyone,

This series addresses some (but not all) issues found while running the
ethtool selftest on various stmmac platforms. As a reminder, ethtool
selftest are run with 'ethtool -t ethX', and for stmmac the goal is to test
hardware features and bugs from the IP integration in the platform.

I've been running this on :

 - Altera CycloneV (dwmac-socfpga, dwmac1000 IP, v3.70a)
 - NXP imx8mp (dwmac-imx, dwmac4, v5.10a)
 - Allwinner H2S (dwmac-sun8i, dwmac1000)
 - Amlogic S905X3 (dwmac-meson8b, dwmac1000, v3.70a)
 - STM32mp157a (dwmac-stm32, dwmac4, v4.20a)
 - SiFive JH7110 (dwmac-starfive, dwmac4, v5.20)

Here's the results before this series, noting that some bugs were already
fixed, some are ongoing (cf. the IP proto patch here [1])

[1] : https://lore.kernel.org/netdev/20260825211748.360935-1-maxime.chevallier@bootlin.com/

Tests are OK if return is 0 or -95 (-EOPNOTSUPP), tests are KO otherwise

Test                     imx   socfpga   sun8i   meson8b   stm32 starfive
MAC Loopback              0      0        0        0        0       0
MMC Counters              0      0        -95      -22      0       -22
EEE                       -95    -95      -95      -95      -95     -95
Hash Filter MC            0      0        -95      0        0       0
Perfect Filter UC         0      0        0        0        0       0
MC Filter                 0      0        -95      0        0       0
UC Filter                 0      0        -95      -22      0       0
Flow Control              -110   0        -110     0        0       -110
RSS                       -95    -95      -95      -95      -95     -95
VLAN Filtering            -110   -95      -95      -95      -110    -110
VLAN Filtering (perf)     -110   -95      -95      -95      -110    -110
Double VLAN Filter        -110   -95      -95      -95      -110    -110
Double VLAN Filter (perf) -110   -95      -95      -95      -110    -110
Flexible RX Parser        0      -95      -95      -95      -95     -95
SA Insertion (desc)       0      -95      -95      -95      0       0
SA Replacement (desc)     0      -95      -95      -95      0       0
SA Insertion (reg         0      -95      -95      -95      0       0
SA Replacement (reg)      0      -95      -95      -95      0       0
VLAN TX Insertion         -110   -95      -95      -95      -110    -110
SVLAN TX Insertion        -110   -95      -95      -95      -110    -95
L3 DA Filtering           0      -95      -95      -95      -95     -95
L3 SA Filtering           0      -95      -95      -95      -95     -95
L4 DA TCP Filtering       0      -95      -95      -95      -95     -95
L4 SA TCP Filtering       0      -95      -95      -95      -95     -95
L4 DA UDP Filtering       0      -95      -95      -95      -95     -95
L4 SA UDP Filtering       0      -95      -95      -95      -95     -95
ARP Offload               -95    -95      -95      -95      -110    -110
Jumbo Frame               0      0        0        0        0       0
Multichannel Jumbo        0      -95      -95      -95      -95     -95
Split Header             -95     -95      -95      -95      -95     -95
TBS (ETF Scheduler)      -95     -95      -95      -95      -95     -95

So, only sogfpga is all OK (in all fairness, it doesn't support much)

Several issues :

 - MMC test failing on starfive and meson8b, solved by patch 1
 
MMC counters maintained by the MAC are optional, which one is implemented
depends on how the IP is synthesized. On starfive and meson8b, the counter
used by the selftest to validate the MMC counters feature isn't implemented.

Solved by adding other counters in the validation step, kinda fragile as
this doesn't guarantee this will work on all platforms.

 - Flow control test failing on starfive, imx8mp, sun8i, solved by patch 6
 
Turns out these platforms actually never emit any Pause frame, as they don't
have enough room in their per-queue RX Fifo. They do correctly process RX
Pause frames. The fix isn't to change the advertised pauseparams, as the
pause negotiation process based on MAC capabilities doesn't allow us to
say we "just" support RX pause, so let's just not run the Pause tests if
the RX fifo is too small.

 - UC filter failing on meson8b, fixed by patches 2,3,4 and 5
 
This one is quite the rabbit hole, and is a combination of multiple issues.

 - Unicast filtering uses the same filter (perfect filter) to allow the
   primary MAC address and the secondary addresses (dev->uc) to flow
   through the interface. That means if we have say 64 slots in the
   perfect filter, only 63 can be used for the dev->uc list, as the first
   entry stores the MAC address. If the filter is full, we switch to UC
   promisc mode, were we let all UC frames flow. There's an off-by-one
   error in dwmac1000, dwmac4 and dwxgmac2.
   
 - The selftest itself needs an empty slot in the filter, so it has to
   check that sizeof(dev->uc) is $number_of_slots - 2 (one for primary
   MAC, one for the test). There's an off-by-two error in the selftest.
   
 - This leads to an interesting finding (not addressed by this series) :

   The size of the perfect filter isn't reported by the HW, so it comes
   from firmware (snps,perfect-filter-entries). A lot of platforms don't
   specify that in DT (e.g. imx8mp doesn't, it has 128 entries but the
   driver thinks there's only 1...). I've reached out to Synopsys to
   see if there's some sane default we could use on dwmac4, if anyone
   has a dwmac4 databook I'd appreciate if you could look this up, as I
   don't have access to them, I'm not a vendor... Otherwise, we'll have
   to patch all the .dtsi if we want to avoid going in UC promisc as
   soon as we add an entry in dev->uc.
   
After this series, socfpga, starfive and sun8i are all OK :)
   
Some issues are still out there, the VLAN filtering and tagging fails on
imx8mp and stm32 (so, dwmac4) butI haven't got there yet.

ARP offload doesn't work on stm32mp157a and starfive JH7110 either.

Feel free to look this up if you feel like it,
just let me know so that we don't do work on the same thing :)

Maxime

Maxime Chevallier (6):
  net: stmmac: selftests: Check multiple MMC counters
  net: stmmac: dwmac1000: Account for the primary MAC address for UC
    filtering
  net: stmmac: dwmac4: Account for the primary MAC address for UC
    filtering
  net: stmmac: dwxgmac: Account for the primary MAC address for UC
    filtering
  net: stmmac: selftests: Account for the UC filter list for filtering
    tests
  net: stmmac: selftests: Don't test flow control for small rx fifos

 .../ethernet/stmicro/stmmac/dwmac1000_core.c  |  2 +-
 .../net/ethernet/stmicro/stmmac/dwmac4_core.c |  2 +-
 .../ethernet/stmicro/stmmac/dwxgmac2_core.c   |  2 +-
 .../stmicro/stmmac/stmmac_selftests.c         | 51 +++++++++++++++----
 4 files changed, 44 insertions(+), 13 deletions(-)

-- 
2.55.0

[PATCH net 1/6] net: stmmac: selftests: Check multiple MMC counters

[Maxime Chevallier]

The MMC counters report MAC statistics. Multiple counters can be
enabled when the IP is integrated, however there's no way to know
exactly which ones. Un-implemented counters seem to report 0.

It was found that on StarFive JH7110 and Amlogic SM1, the counter that's
used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering
an MMC selftest failure.

Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use
this counter as well for MMC counter validation.

Note that this doesn't guarantee that we won't encounter the same issue
again if another IP implements yet another set of counters that don't
include that new one.

If the game of whack-a-mole with implemented counters becomes too hard to
maintain, we may simply consider removing the MMC selftest entirely.

Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 .../net/ethernet/stmicro/stmmac/stmmac_selftests.c | 14 ++++++++++----
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index a2b917dd60e5..14db0c0e0ba9 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -395,11 +395,17 @@ static int stmmac_test_mmc(struct stmmac_priv *priv)
 	stmmac_mmc_read(priv, priv->mmcaddr, &final);
 
 	/*
-	 * The number of MMC counters available depends on HW configuration
-	 * so we just use this one to validate the feature. I hope there is
-	 * not a version without this counter.
+	 * The number of MMC counters available depends on HW configuration,
+	 * and there doesn't seem to be a way to enumerate the implemented
+	 * counters.
+	 *
+	 * Let's check a hand-picked set of counters, knowing that :
+	 *  - Starfive JH7110 doesn't implement mmc_tx_framecount_g
+	 *  - Amlogic SM1 doesn't implement any mmc_tx_*
+	 *
 	 */
-	if (final.mmc_tx_framecount_g <= initial.mmc_tx_framecount_g)
+	if (final.mmc_tx_framecount_g <= initial.mmc_tx_framecount_g &&
+	    final.mmc_rx_framecount_gb <= initial.mmc_rx_framecount_gb)
 		return -EINVAL;
 
 	return 0;
-- 
2.55.0

Re: [PATCH net 1/6] net: stmmac: selftests: Check multiple MMC counters

[Andrew Lunn]

On Wed, Aug 26, 2026 at 04:04:53PM +0200, Maxime Chevallier wrote:
> The MMC counters report MAC statistics. Multiple counters can be
> enabled when the IP is integrated, however there's no way to know
> exactly which ones. Un-implemented counters seem to report 0.
> 
> It was found that on StarFive JH7110 and Amlogic SM1, the counter that's
> used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering
> an MMC selftest failure.
> 
> Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use
> this counter as well for MMC counter validation.
> 
> Note that this doesn't guarantee that we won't encounter the same issue
> again if another IP implements yet another set of counters that don't
> include that new one.
> 
> If the game of whack-a-mole with implemented counters becomes too hard to
> maintain, we may simply consider removing the MMC selftest entirely.
> 
> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Seems sensible.

If more moles need whacking, we could consider the value of 0 as
success.

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net 1/6] net: stmmac: selftests: Check multiple MMC counters

[Maxime Chevallier]

Hi,

On 8/26/26 19:14, Andrew Lunn wrote:
> On Wed, Aug 26, 2026 at 04:04:53PM +0200, Maxime Chevallier wrote:
>> The MMC counters report MAC statistics. Multiple counters can be
>> enabled when the IP is integrated, however there's no way to know
>> exactly which ones. Un-implemented counters seem to report 0.
>>
>> It was found that on StarFive JH7110 and Amlogic SM1, the counter that's
>> used by the selftest (mmc_tx_framecount_g) isn't implemented, triggering
>> an MMC selftest failure.
>>
>> Both the above SoCs seem to implement mmc_rx_framecount_gb, let's use
>> this counter as well for MMC counter validation.
>>
>> Note that this doesn't guarantee that we won't encounter the same issue
>> again if another IP implements yet another set of counters that don't
>> include that new one.
>>
>> If the game of whack-a-mole with implemented counters becomes too hard to
>> maintain, we may simply consider removing the MMC selftest entirely.
>>
>> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> 
> Seems sensible.
> 
> If more moles need whacking, we could consider the value of 0 as
> success.

We'd need to see what the values are on platforms that don't implement MMC
counters at all, what the registers read in that case.

Another approach is to bruteforce the selftest and look at all the MMC counters,
passing if any of them changes during the test.

> 
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> 
>     Andrew

Thank you :)

Maxime

[PATCH net 2/6] net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering

[Maxime Chevallier]

The same filter slots are used to store the main MAC address as well as
the address for the unicast filter. Let's account for that when deciding
whether or not to use promisc when programming the UC list in hardware.

Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
index caac85fc08f1..d4ace3924891 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -194,7 +194,7 @@ static void dwmac1000_set_filter(struct mac_device_info *hw,
 	dwmac1000_set_mchash(ioaddr, mc_filter, mcbitslog2);
 
 	/* Handle multiple unicast addresses (perfect filtering) */
-	if (netdev_uc_count(dev) > perfect_addr_number)
+	if (netdev_uc_count(dev) + 1 > perfect_addr_number)
 		/* Switch to promiscuous mode if more than unicast
 		 * addresses are requested than supported by hardware.
 		 */
-- 
2.55.0

Re: [PATCH net 2/6] net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering

[Andrew Lunn]

On Wed, Aug 26, 2026 at 04:04:54PM +0200, Maxime Chevallier wrote:
> The same filter slots are used to store the main MAC address as well as
> the address for the unicast filter. Let's account for that when deciding
> whether or not to use promisc when programming the UC list in hardware.
> 
> Fixes: 47dd7a540b8a ("net: add support for STMicroelectronics Ethernet controllers.")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[PATCH net 3/6] net: stmmac: dwmac4: Account for the primary MAC address for UC filtering

[Maxime Chevallier]

The same filter slots are used to store the main MAC address as well as
the address for the unicast filter. Let's account for that when deciding
whether or not to use promisc when programming the UC list in hardware.

Fixes: 477286b53f55 ("stmmac: add GMAC4 core support")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index c6fcfae27c3d..18b357b257cc 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -521,7 +521,7 @@ static void dwmac4_set_filter(struct mac_device_info *hw,
 	value |= GMAC_PACKET_FILTER_HPF;
 
 	/* Handle multiple unicast addresses */
-	if (netdev_uc_count(dev) > hw->unicast_filter_entries) {
+	if (netdev_uc_count(dev) + 1 > hw->unicast_filter_entries) {
 		/* Switch to promiscuous mode if more than 128 addrs
 		 * are required
 		 */
-- 
2.55.0

Re: [PATCH net 3/6] net: stmmac: dwmac4: Account for the primary MAC address for UC filtering

[Andrew Lunn]

On Wed, Aug 26, 2026 at 04:04:55PM +0200, Maxime Chevallier wrote:
> The same filter slots are used to store the main MAC address as well as
> the address for the unicast filter. Let's account for that when deciding
> whether or not to use promisc when programming the UC list in hardware.
> 
> Fixes: 477286b53f55 ("stmmac: add GMAC4 core support")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[PATCH net 4/6] net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering

[Maxime Chevallier]

The same filter slots are used to store the main MAC address as well as
the address for the unicast filter. Let's account for that when deciding
whether or not to use promisc when programming the UC list in hardware.

Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
index 52054f31376d..fc6ddb51c682 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwxgmac2_core.c
@@ -532,7 +532,7 @@ static void dwxgmac2_set_filter(struct mac_device_info *hw,
 	dwxgmac2_set_mchash(ioaddr, mc_filter, mcbitslog2);
 
 	/* Handle multiple unicast addresses */
-	if (netdev_uc_count(dev) > hw->unicast_filter_entries) {
+	if (netdev_uc_count(dev) + 1 > hw->unicast_filter_entries) {
 		value |= XGMAC_FILTER_PR;
 	} else {
 		struct netdev_hw_addr *ha;
-- 
2.55.0

Re: [PATCH net 4/6] net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering

[Andrew Lunn]

On Wed, Aug 26, 2026 at 04:04:56PM +0200, Maxime Chevallier wrote:
> The same filter slots are used to store the main MAC address as well as
> the address for the unicast filter. Let's account for that when deciding
> whether or not to use promisc when programming the UC list in hardware.
> 
> Fixes: 0efedbf11f07 ("net: stmmac: xgmac: Fix XGMAC selftests")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

[PATCH net 5/6] net: stmmac: selftests: Account for the UC filter list for filtering tests

[Maxime Chevallier]

On dwmac, one of the Unicast filter entries is used to store the local
HW addr. This means that we have to use promisc mode for any kind of
unicast filtering if we only have one slot in our unicast filter.

The number of slots available depends on how the IP is integrated, and
we can't autodiscover how many of these slots we have available, so
the DT property snps,perfect-filter-entries can be used to specify how
many are available.

Most IP variants default to 1 if this isn't specified, which is the case
for the amlogic variants (in this case, S905X3).

The stmmac selftests for UC filtering look if we have enough slots in
the filter to store the dev->uc list, but doesn't account for the
device's own MAC address. The dev->uc list's size we get with
netdev_uc_count() also doesn't account for the HW addr.

As the selftest only requires one available slot, in the case of
single-slot platforms, that means we erroneously consider we have enough
room for the test, when we actually don't, and the filtering test fails.

Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 .../stmicro/stmmac/stmmac_selftests.c         | 21 ++++++++++++++++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 14db0c0e0ba9..ae236a264e74 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -479,6 +479,21 @@ static int stmmac_filter_check(struct stmmac_priv *priv)
 	return -EOPNOTSUPP;
 }
 
+static int stmmac_uc_filter_check(struct stmmac_priv *priv)
+{
+	/* For tests involving the UC filter, we need at least one empty
+	 * slot in the UC filter. The UC filters contains netdev_uc_count() + 1
+	 * entries: The dev->uc list + one entry for the HW address.
+	 *
+	 * Having an empty slot therefore means netdev_uc_count() + 2 entries
+	 * can fit in the filter
+	 */
+	if (netdev_uc_count(priv->dev) + 2 > priv->hw->unicast_filter_entries)
+		return -EOPNOTSUPP;
+
+	return 0;
+}
+
 static bool stmmac_hash_check(struct stmmac_priv *priv, unsigned char *addr)
 {
 	int mc_offset = 32 - priv->hw->mcast_bits_log2;
@@ -570,7 +585,7 @@ static int stmmac_test_pfilt(struct stmmac_priv *priv)
 
 	if (stmmac_filter_check(priv))
 		return -EOPNOTSUPP;
-	if (netdev_uc_count(priv->dev) >= priv->hw->unicast_filter_entries)
+	if (stmmac_uc_filter_check(priv))
 		return -EOPNOTSUPP;
 
 	while (--tries) {
@@ -614,7 +629,7 @@ static int stmmac_test_mcfilt(struct stmmac_priv *priv)
 
 	if (stmmac_filter_check(priv))
 		return -EOPNOTSUPP;
-	if (netdev_uc_count(priv->dev) >= priv->hw->unicast_filter_entries)
+	if (stmmac_uc_filter_check(priv))
 		return -EOPNOTSUPP;
 	if (netdev_mc_count(priv->dev) >= priv->hw->multicast_filter_bins)
 		return -EOPNOTSUPP;
@@ -660,7 +675,7 @@ static int stmmac_test_ucfilt(struct stmmac_priv *priv)
 
 	if (stmmac_filter_check(priv))
 		return -EOPNOTSUPP;
-	if (netdev_uc_count(priv->dev) >= priv->hw->unicast_filter_entries)
+	if (stmmac_uc_filter_check(priv))
 		return -EOPNOTSUPP;
 	if (netdev_mc_count(priv->dev) >= priv->hw->multicast_filter_bins)
 		return -EOPNOTSUPP;
-- 
2.55.0

Re: [PATCH net 5/6] net: stmmac: selftests: Account for the UC filter list for filtering tests

[Andrew Lunn]

On Wed, Aug 26, 2026 at 04:04:57PM +0200, Maxime Chevallier wrote:
> On dwmac, one of the Unicast filter entries is used to store the local
> HW addr. This means that we have to use promisc mode for any kind of
> unicast filtering if we only have one slot in our unicast filter.
> 
> The number of slots available depends on how the IP is integrated, and
> we can't autodiscover how many of these slots we have available, so
> the DT property snps,perfect-filter-entries can be used to specify how
> many are available.
> 
> Most IP variants default to 1 if this isn't specified, which is the case
> for the amlogic variants (in this case, S905X3).

Do you have this hardware? Did you try increasing the DT property to
find out how many slots it actually has?

Maybe a nice little project for a newbie which has some stmmac
hardware. Write some code which adds MAC addresses and reads them back
again. Determine at runtime how many slots there actually are.

> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net 5/6] net: stmmac: selftests: Account for the UC filter list for filtering tests

[Maxime Chevallier]

Hi,

On 8/26/26 20:25, Andrew Lunn wrote:
> On Wed, Aug 26, 2026 at 04:04:57PM +0200, Maxime Chevallier wrote:
>> On dwmac, one of the Unicast filter entries is used to store the local
>> HW addr. This means that we have to use promisc mode for any kind of
>> unicast filtering if we only have one slot in our unicast filter.
>>
>> The number of slots available depends on how the IP is integrated, and
>> we can't autodiscover how many of these slots we have available, so
>> the DT property snps,perfect-filter-entries can be used to specify how
>> many are available.
>>
>> Most IP variants default to 1 if this isn't specified, which is the case
>> for the amlogic variants (in this case, S905X3).
> 
> Do you have this hardware? Did you try increasing the DT property to
> find out how many slots it actually has?

I do have the HW, but I haven't tried figuring the actual number of slots,
there's the same issues on lots of devices actually.

The platform I'm using for that is the Banana Pi M5, not too expensive
(that is, if we compare that with other SBCs)

> Maybe a nice little project for a newbie which has some stmmac
> hardware. Write some code which adds MAC addresses and reads them back
> again. Determine at runtime how many slots there actually are.

Exactly, that thought also crossed my mind, that would be fairly easy to
implement and with a net benefit :)

> 
>> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> 
> Reviewed-by: Andrew Lunn <andrew@lunn.ch>
> 
>     Andrew

Thanks for reviewing all of this,

Maxime

[PATCH net 6/6] net: stmmac: selftests: Don't test flow control for small rx fifos

[Maxime Chevallier]

On dwmac1000, dwmac4 and dwxgmac, we only emit pause frames if there's
at least 4096 bytes in each queue's fifo.

The phylink mac capabilities are still MAC_ASYM_PAUSE | MAC_SYM_PAUSE as
otherwise we won't be able to negotiate 'rx on' pause. ASYM only will
prevent negotiating 'rx off tx on', while SYM only doesn't really
matche the reality (not symmetric if we can only do RX pause).

Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 .../ethernet/stmicro/stmmac/stmmac_selftests.c   | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index ae236a264e74..6372ec7c3f31 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -739,12 +739,24 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
 	u32 rx_cnt = priv->plat->rx_queues_to_use;
 	struct mac_device_info *mac = priv->hw;
 	struct stmmac_test_priv *tpriv;
+	unsigned int rx_fifo_size;
 	unsigned int pkt_count;
 	int i, ret = 0;
 
 	if (!(mac->link.caps & MAC_SYM_PAUSE))
 		return -EOPNOTSUPP;
 
+	rx_fifo_size = priv->plat->rx_fifo_size;
+	if (!rx_fifo_size)
+		rx_fifo_size = priv->dma_cap.rx_fifo_size;
+
+	/* No pause frame is emitted if we don't have at least 4096 bytes per
+	 * queue, except on dwmac100.
+	 */
+	if (priv->plat->core_type != DWMAC_CORE_MAC100 &&
+	    rx_fifo_size / priv->plat->rx_queues_to_use < 4096)
+		return -EOPNOTSUPP;
+
 	tpriv = kzalloc_obj(*tpriv);
 	if (!tpriv)
 		return -ENOMEM;
@@ -758,9 +770,7 @@ static int stmmac_test_flowctrl(struct stmmac_priv *priv)
 	dev_add_pack(&tpriv->pt);
 
 	/* Compute minimum number of packets to make FIFO full */
-	pkt_count = priv->plat->rx_fifo_size;
-	if (!pkt_count)
-		pkt_count = priv->dma_cap.rx_fifo_size;
+	pkt_count = rx_fifo_size;
 	pkt_count /= 1400;
 	pkt_count *= 2;
 
-- 
2.55.0

Re: [PATCH net 6/6] net: stmmac: selftests: Don't test flow control for small rx fifos

[Andrew Lunn]

On Wed, Aug 26, 2026 at 04:04:58PM +0200, Maxime Chevallier wrote:
> On dwmac1000, dwmac4 and dwxgmac, we only emit pause frames if there's
> at least 4096 bytes in each queue's fifo.
> 
> The phylink mac capabilities are still MAC_ASYM_PAUSE | MAC_SYM_PAUSE as
> otherwise we won't be able to negotiate 'rx on' pause. ASYM only will
> prevent negotiating 'rx off tx on', while SYM only doesn't really
> matche the reality (not symmetric if we can only do RX pause).
> 
> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>

Reviewed-by: Andrew Lunn <andrew@lunn.ch>

    Andrew

Re: [PATCH net 0/6] net: stmmac: More selftest related fixes

[Jakub Kicinski]

On Wed, 26 Aug 2026 16:04:52 +0200 Maxime Chevallier wrote:
> This series addresses some (but not all) issues found while running the
> ethtool selftest on various stmmac platforms. As a reminder, ethtool
> selftest are run with 'ethtool -t ethX', and for stmmac the goal is to test
> hardware features and bugs from the IP integration in the platform.

LGTM, please double check if any of the Clashiko complaints are
worthwhile, and if so - follow up:

https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826140500.616466-2-maxime.chevallier@bootlin.com

Re: [PATCH net 0/6] net: stmmac: More selftest related fixes

[Maxime Chevallier]

Hi Jakub,

On 8/27/26 19:53, Jakub Kicinski wrote:
> On Wed, 26 Aug 2026 16:04:52 +0200 Maxime Chevallier wrote:
>> This series addresses some (but not all) issues found while running the
>> ethtool selftest on various stmmac platforms. As a reminder, ethtool
>> selftest are run with 'ethtool -t ethX', and for stmmac the goal is to test
>> hardware features and bugs from the IP integration in the platform.
> 
> LGTM, please double check if any of the Clashiko complaints are
> worthwhile, and if so - follow up:
> 
> https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260826140500.616466-2-maxime.chevallier@bootlin.com

Thanks, the things raised by AI reviews are correct, and I indeed am working
on addressing that. That's follow-up material indeed.

The main thing AI points points about the UC filter is "but won't we hit UC
promisc sooner ?" and the answer is yes absolutely, but it's the right thing
to do.

I've got some information from Synopsys on a way to discover the US filter
list, and the followup is on its way to get proper unicast filtering on
dwmac4, stay tuned :)

Maxime

Re: [PATCH net 0/6] net: stmmac: More selftest related fixes

[Jakub Kicinski]

On Thu, 27 Aug 2026 22:16:18 +0200 Maxime Chevallier wrote:
> The main thing AI points points about the UC filter is "but won't we hit UC
> promisc sooner ?" and the answer is yes absolutely, but it's the right thing
> to do.

Indeed, that false-positive one was very disappointing to see :/
High severity when it's obviously the intent of the patch.
Or maybe the AI knows something we don't know :D

Re: [PATCH net 0/6] net: stmmac: More selftest related fixes

[patchwork-bot+netdevbpf]

Hello:

This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 26 Aug 2026 16:04:52 +0200 you wrote:
> Hello everyone,
> 
> This series addresses some (but not all) issues found while running the
> ethtool selftest on various stmmac platforms. As a reminder, ethtool
> selftest are run with 'ethtool -t ethX', and for stmmac the goal is to test
> hardware features and bugs from the IP integration in the platform.
> 
> [...]

Here is the summary with links:
  - [net,1/6] net: stmmac: selftests: Check multiple MMC counters
    https://git.kernel.org/netdev/net/c/d29b399150b0
  - [net,2/6] net: stmmac: dwmac1000: Account for the primary MAC address for UC filtering
    https://git.kernel.org/netdev/net/c/9698b6da3714
  - [net,3/6] net: stmmac: dwmac4: Account for the primary MAC address for UC filtering
    https://git.kernel.org/netdev/net/c/82187f42c014
  - [net,4/6] net: stmmac: dwxgmac: Account for the primary MAC address for UC filtering
    https://git.kernel.org/netdev/net/c/2739d6f9a2b8
  - [net,5/6] net: stmmac: selftests: Account for the UC filter list for filtering tests
    https://git.kernel.org/netdev/net/c/cd8c3b2752c6
  - [net,6/6] net: stmmac: selftests: Don't test flow control for small rx fifos
    https://git.kernel.org/netdev/net/c/96e8cb5527ce

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html