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

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

[Maxime Chevallier]

Hi everyone,

This is another round of stmmac selftest fixes, mostly about the selftests
themselves but a few things were discovered w.r.t MTU and buffer size
handling, see patch 5.

I've continued expanding the test devices I'm running this on, more devices
should come in the future. With this series, _almost_ everything is
green, except for some flow control stuff that is either a false positive
or a real thing that needs investigating.

After this is merged, I consider the selftests to be now reliable enough
to run them nightly on every stmmac series that's sent, and I'll be requiring
clean selftests for new glue drivers.

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)
 - Motorcomm YT8061 (PCIe, dwmac-motorcomm, dwmac4)
 - Qualcomm IPQ8064 (dwmac-ipq806x, dwmac1000)

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

Before the series :

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

ARP offload's still there as this was a net-next patch and I've ran these
checks on the net tree.

Jumbo frame tests on dwmac1000 started failing after :

commit 23680bf5f8c6 ("net: stmmac: restore NET_IP_ALIGN in the RX DMA offset")

This commit is OK though, it just made the selftest reveal the cracks
hiding beneath the surface of MTU/bufsz handling.

After this series :

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

ARP can be ignored, and Flow control needs some more attention, but
we're getting there :)

Thanks,

Maxime

Maxime Chevallier (6):
  net: stmmac: selftests: Support running selftests on DSA conduits
  net: stmmac: selftests: Validate EEE based on the actual LPI timer
    value
  net: stmmac: selftests: Check the dev->features for S-TAG offload
    testing
  net: stmmac: selftests: Capture all packets for vlan checks
  net: stmmac: size the RX buffers from the frame length, not the MTU
  net: stmmac: selftests: Account for alignment shift on dwmac1000 for
    Jumbo test

 .../net/ethernet/stmicro/stmmac/stmmac_main.c |  20 ++--
 .../stmicro/stmmac/stmmac_selftests.c         | 110 +++++++++++++++---
 2 files changed, 102 insertions(+), 28 deletions(-)

-- 
2.55.0

[PATCH net 6/6] net: stmmac: selftests: Account for alignment shift on dwmac1000 for Jumbo test

[Maxime Chevallier]

On dwmac1000, we currently only support single-descriptor frames. The
Jumbo test started failing when NET_IP_ALIGN was added to align the IP
header, as this tests tries to send the biggest possible frame.

On dwmac1000 the DMA transfer is aligned on 4-bytes, so adding a 2-byte
shift at the start-of-buffer address means it takes a whole extra 4-byte
DMA burst to receive the Jumbo packet, causing it to spill over the next
descriptor.

This doesn't seem to happen on dwmac4 and xgmac that appear to correctly
handle unaligned xfers (only tested on dwmac4)

Let's account for that in the Jumbo test, reduce the size of our big
packet by the align size.

Fixes: 23680bf5f8c6 ("net: stmmac: restore NET_IP_ALIGN in the RX DMA offset")
Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
index 2fc0badb65a7..ffc58c210d0d 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
@@ -1768,6 +1768,9 @@ static int __stmmac_test_jumbo(struct stmmac_priv *priv, u16 queue)
 	struct stmmac_packet_attrs attr = { };
 	int size = priv->dma_conf.dma_buf_sz;
 
+	if (!dwmac_is_xmac(priv->plat->core_type))
+		size -= NET_IP_ALIGN;
+
 	attr.dst = priv->dev->dev_addr;
 	attr.max_size = size - ETH_FCS_LEN;
 	attr.queue_mapping = queue;
-- 
2.55.0

Re: [PATCH net 2/6] net: stmmac: selftests: Validate EEE based on the actual LPI timer value

[Nicolai Buchwitz]

Hi Maxime

On 9.9.2026 09:47, Maxime Chevallier wrote:
> The EEE selftest is a 2-step test :
>  - It validates that we enter in LPI mode with the
>    irq_tx_path_in_lpi_mode_n counter
>  - It then validates that we exit LPI when sending a frame, with the
>    irq_tx_path_exit_lpi_mode_n counter.
> 
> The current state of the test lacks 2 main things :
> 
>  - We don't know exactly when was the previous frame sent (it's from 
> the
>    previous selftest)
> 
>  - The timeout is hardcoded, while the LPI is entered after a
>    user-configurable delay. On top of that, the timeout loop uses a
>    pre-decrement iterator (--retries) that actually only iterate nine
>    times, so 900ms while the default LPI value is 1 second.
> 
> Let's therefore make it more deterministic :
> 
>  - Send a frame at the beginning of the test
>  - Wait for more than the lpi timer value, we timeout after about twice
>    the value,
>  - Then send another frame, and verify that we do go out of LPI, also
>    with a timeout.
> 
> Note that the test's goal isn't to validate the LPI timer value itself,
> only that we enter/leave LPI mode.
> 
> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>  .../stmicro/stmmac/stmmac_selftests.c         | 33 ++++++++++++++-----
>  1 file changed, 25 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> index 6503678b646e..4564b9f29194 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c

> [...]

> -	memcpy(initial, &priv->xstats, sizeof(*initial));
> -
> +	/* Send a frame, then wait to enter LPI */
>  	ret = stmmac_test_mac_loopback(priv);
>  	if (ret)
>  		goto out_free_final;
> 
> +	max_duration = usecs_to_jiffies(2 * priv->tx_lpi_timer);
> +
> +	memcpy(initial, &priv->xstats, sizeof(*initial));

Is the LPI entry already counted here? AFAIU with tx-lpi-timer=0 on 
dwmac4 the
MAC goes directly into LPI after the frame, before 
stmmac_test_mac_loopback()
returns. The loop below would time out although LPI is working.

Snapshot before the first frame, and take a second snapshot right before
the second loopback for the exit check?

> [...]

> +	memcpy(final, &priv->xstats, sizeof(*final));
>  	if (final->irq_tx_path_exit_lpi_mode_n <=
>  	    initial->irq_tx_path_exit_lpi_mode_n) {
>  		ret = -EINVAL;

nit: -ETIMEDOUT here as well, to match the entry check?

Thanks
Nicolai

Re: [PATCH net 2/6] net: stmmac: selftests: Validate EEE based on the actual LPI timer value

[Maxime Chevallier]

Hi,

On 9/9/26 13:32, Nicolai Buchwitz wrote:
> Hi Maxime
> 
> On 9.9.2026 09:47, Maxime Chevallier wrote:
>> The EEE selftest is a 2-step test :
>>  - It validates that we enter in LPI mode with the
>>    irq_tx_path_in_lpi_mode_n counter
>>  - It then validates that we exit LPI when sending a frame, with the
>>    irq_tx_path_exit_lpi_mode_n counter.
>>
>> The current state of the test lacks 2 main things :
>>
>>  - We don't know exactly when was the previous frame sent (it's from the
>>    previous selftest)
>>
>>  - The timeout is hardcoded, while the LPI is entered after a
>>    user-configurable delay. On top of that, the timeout loop uses a
>>    pre-decrement iterator (--retries) that actually only iterate nine
>>    times, so 900ms while the default LPI value is 1 second.
>>
>> Let's therefore make it more deterministic :
>>
>>  - Send a frame at the beginning of the test
>>  - Wait for more than the lpi timer value, we timeout after about twice
>>    the value,
>>  - Then send another frame, and verify that we do go out of LPI, also
>>    with a timeout.
>>
>> Note that the test's goal isn't to validate the LPI timer value itself,
>> only that we enter/leave LPI mode.
>>
>> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> ---
>>  .../stmicro/stmmac/stmmac_selftests.c         | 33 ++++++++++++++-----
>>  1 file changed, 25 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
>> index 6503678b646e..4564b9f29194 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> 
>> [...]
> 
>> -    memcpy(initial, &priv->xstats, sizeof(*initial));
>> -
>> +    /* Send a frame, then wait to enter LPI */
>>      ret = stmmac_test_mac_loopback(priv);
>>      if (ret)
>>          goto out_free_final;
>>
>> +    max_duration = usecs_to_jiffies(2 * priv->tx_lpi_timer);
>> +
>> +    memcpy(initial, &priv->xstats, sizeof(*initial));
> 
> Is the LPI entry already counted here? AFAIU with tx-lpi-timer=0 on dwmac4 the
> MAC goes directly into LPI after the frame, before stmmac_test_mac_loopback()
> returns. The loop below would time out although LPI is working.

hmmm this is a good point ! I'll test and send a V2 :)

> 
> Snapshot before the first frame, and take a second snapshot right before
> the second loopback for the exit check?
> 
>> [...]
> 
>> +    memcpy(final, &priv->xstats, sizeof(*final));
>>      if (final->irq_tx_path_exit_lpi_mode_n <=
>>          initial->irq_tx_path_exit_lpi_mode_n) {
>>          ret = -EINVAL;
> 
> nit: -ETIMEDOUT here as well, to match the entry check?

This is the old behaviour, if we don't entry we timeout, if we did enter but
don't record an exit event this is an error, it kinda makes sense to me no ?

Thanks for looking at this,

Maxime

Re: [PATCH net 2/6] net: stmmac: selftests: Validate EEE based on the actual LPI timer value

[Maxime Chevallier]

Hi,

On 9/9/26 13:32, Nicolai Buchwitz wrote:
> Hi Maxime
> 
> On 9.9.2026 09:47, Maxime Chevallier wrote:
>> The EEE selftest is a 2-step test :
>>  - It validates that we enter in LPI mode with the
>>    irq_tx_path_in_lpi_mode_n counter
>>  - It then validates that we exit LPI when sending a frame, with the
>>    irq_tx_path_exit_lpi_mode_n counter.
>>
>> The current state of the test lacks 2 main things :
>>
>>  - We don't know exactly when was the previous frame sent (it's from the
>>    previous selftest)
>>
>>  - The timeout is hardcoded, while the LPI is entered after a
>>    user-configurable delay. On top of that, the timeout loop uses a
>>    pre-decrement iterator (--retries) that actually only iterate nine
>>    times, so 900ms while the default LPI value is 1 second.
>>
>> Let's therefore make it more deterministic :
>>
>>  - Send a frame at the beginning of the test
>>  - Wait for more than the lpi timer value, we timeout after about twice
>>    the value,
>>  - Then send another frame, and verify that we do go out of LPI, also
>>    with a timeout.
>>
>> Note that the test's goal isn't to validate the LPI timer value itself,
>> only that we enter/leave LPI mode.
>>
>> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> ---
>>  .../stmicro/stmmac/stmmac_selftests.c         | 33 ++++++++++++++-----
>>  1 file changed, 25 insertions(+), 8 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
>> index 6503678b646e..4564b9f29194 100644
>> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_selftests.c
> 
>> [...]
> 
>> -    memcpy(initial, &priv->xstats, sizeof(*initial));
>> -
>> +    /* Send a frame, then wait to enter LPI */
>>      ret = stmmac_test_mac_loopback(priv);
>>      if (ret)
>>          goto out_free_final;
>>
>> +    max_duration = usecs_to_jiffies(2 * priv->tx_lpi_timer);
>> +
>> +    memcpy(initial, &priv->xstats, sizeof(*initial));
> 
> Is the LPI entry already counted here? AFAIU with tx-lpi-timer=0 on dwmac4 the
> MAC goes directly into LPI after the frame, before stmmac_test_mac_loopback()
> returns. The loop below would time out although LPI is working.
> 
> Snapshot before the first frame, and take a second snapshot right before
> the second loopback for the exit check?
> 
>> [...]
> 
>> +    memcpy(final, &priv->xstats, sizeof(*final));
>>      if (final->irq_tx_path_exit_lpi_mode_n <=
>>          initial->irq_tx_path_exit_lpi_mode_n) {
>>          ret = -EINVAL;
> 
> nit: -ETIMEDOUT here as well, to match the entry check?

I ended up changing my mind and following you call here, V2 is incoming,
hopefully with all the patches this time :)

Maxime

> 
> Thanks
> Nicolai

Re: [PATCH net 2/6] net: stmmac: selftests: Validate EEE based on the actual LPI timer value

[Nicolai Buchwitz]

On 9.9.2026 09:47, Maxime Chevallier wrote:
> The EEE selftest is a 2-step test :
>  - It validates that we enter in LPI mode with the
>    irq_tx_path_in_lpi_mode_n counter
>  - It then validates that we exit LPI when sending a frame, with the
>    irq_tx_path_exit_lpi_mode_n counter.
> 
> The current state of the test lacks 2 main things :
> 
>  - We don't know exactly when was the previous frame sent (it's from 
> the
>    previous selftest)
> 
>  - The timeout is hardcoded, while the LPI is entered after a
>    user-configurable delay. On top of that, the timeout loop uses a
>    pre-decrement iterator (--retries) that actually only iterate nine
>    times, so 900ms while the default LPI value is 1 second.
> 
> Let's therefore make it more deterministic :
> 
>  - Send a frame at the beginning of the test
>  - Wait for more than the lpi timer value, we timeout after about twice
>    the value,
>  - Then send another frame, and verify that we do go out of LPI, also
>    with a timeout.
> 
> Note that the test's goal isn't to validate the LPI timer value itself,
> only that we enter/leave LPI mode.
> 
> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---

> [...]

Forget to mention in my last comment:
The series seems to be broken. I can't find patch 3 and also the cover
letter is missing on lore and my inbox?

Nicolai

Re: [PATCH net 2/6] net: stmmac: selftests: Validate EEE based on the actual LPI timer value

[Maxime Chevallier]

On 9/9/26 13:40, Nicolai Buchwitz wrote:
> On 9.9.2026 09:47, Maxime Chevallier wrote:
>> The EEE selftest is a 2-step test :
>>  - It validates that we enter in LPI mode with the
>>    irq_tx_path_in_lpi_mode_n counter
>>  - It then validates that we exit LPI when sending a frame, with the
>>    irq_tx_path_exit_lpi_mode_n counter.
>>
>> The current state of the test lacks 2 main things :
>>
>>  - We don't know exactly when was the previous frame sent (it's from the
>>    previous selftest)
>>
>>  - The timeout is hardcoded, while the LPI is entered after a
>>    user-configurable delay. On top of that, the timeout loop uses a
>>    pre-decrement iterator (--retries) that actually only iterate nine
>>    times, so 900ms while the default LPI value is 1 second.
>>
>> Let's therefore make it more deterministic :
>>
>>  - Send a frame at the beginning of the test
>>  - Wait for more than the lpi timer value, we timeout after about twice
>>    the value,
>>  - Then send another frame, and verify that we do go out of LPI, also
>>    with a timeout.
>>
>> Note that the test's goal isn't to validate the LPI timer value itself,
>> only that we enter/leave LPI mode.
>>
>> Fixes: 091810dbded9 ("net: stmmac: Introduce selftests support")
>> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
>> ---
> 
>> [...]
> 
> Forget to mention in my last comment:
> The series seems to be broken. I can't find patch 3 and also the cover
> letter is missing on lore and my inbox?

Huh that's strange indeed, it's on lkml but not netdev@ ?

https://lore.kernel.org/lkml/20260909074740.1247762-1-maxime.chevallier@bootlin.com/

meh I'll resend if need be

Maxime

> 
> Nicolai