[PATCH net v3 0/6] net: stmmac: More selftest-related fixes
Paolo Abeni
pabeni at redhat.com
Tue Sep 15 01:50:19 PDT 2026
On 9/11/26 11:20 PM, Maxime Chevallier wrote:
> Hi everyone,
>
> This is V3 of stmmac selftest fixes, adding a cap on EEE test as the
> timeout can get pretty long, found by Nicolai.
>
> 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
>
> V3:
> - Bail out of the EEE test if LPI is over 5 seconds
>
> V2:
> https://lore.kernel.org/r/20260910151404.976753-1-maxime.chevallier@bootlin.com
> - Snapshot before sending the frame for EEE, in case we immediately
> enter LPI
> - Also return -ETIMEDOUT instead of EINVAL
>
> V1: https://lore.kernel.org/lkml/20260909074740.1247762-1-maxime.chevallier@bootlin.com/
>
> 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 | 121 +++++++++++++++---
> 2 files changed, 114 insertions(+), 27 deletions(-)
It looks like that the possible ETIMEDOUT reported on patch 4/6 is
contradicted by your testing, but the other not pre-existing 'high prio'
findings from clashiko look actionable to me.
/P
More information about the linux-arm-kernel
mailing list