[ANN] stmmac enters the Netdev CI

[ANN] stmmac enters the Netdev CI

[Maxime Chevallier]

Hi everyone,

It's my pleasure to inform you that the stmmac driver now has a runner
that feeds into the Netdev CI. It runs in a lab I maintain, and the results
are hosted by Bootlin, accessible here :

https://netdevci.bootlin.com/stmmac/results.json

What that means is that now contributions will be subject to CI
validation, by having the kernel selftests run on real hardware.

Results are already aggregated in the patchwork contest, and can also
be found here :

https://netdev.bots.linux.dev/devices.html
https://netdev.bots.linux.dev/status.html

As stmmac is an off-the-shelf IP from Synopsys and is integrated in a lot
of different platforms out there, the CI currently runs on 9 different
boards that include the following SoCs :

 - Starfive JH7110, riscV, dwmac 5.20 (rgmii-id w/ YT8531 PHY)
 - LoongSon 2K0300, Loongarch, dwmac 3.70a (rgmii-id w/ YT8531 PHY)
 - Amlogic S905X, arm64, dwmac 3.70a (rgmii-txid w/ RTL8211F PHY)
 - Rockchip RK3566, arm64, dwmac4.20a (rgmii-id w/ RTL8211F PHY)
 - Altera AgileX5, arm64, dwxgmac 2.10 (rgmii-id w/ KSZ9031 PHY)
 - Altera cycloneV, arm, dwmac 3.70a (rgmii-id w/ KSZ9031 PHY)
 - ST stm32mp157a, arm, dwmac 4.20a (rgmii-id </ RTL8211F PHY)
 - Allwinner A20, arm, dwmac1000 (rgmii-id w/ RTL8211E PHY)
 - Allwinner H2+, arm, Allwinner specific version (mii w/ internal PHY)
 
On top of that, there's a Motorcomm PCIe card with dwmac 5.20 that's
connected to the JH7110 board, also running the tests.

Coming-up is NXP imx8mp, ST stm32mp2 and Ingenic X1000 (MIPS board) that
will be running these tests in a near future. I will also include another
CycloneV setup with SFP and the Lynx PCS.

If you're interested in getting your HW in that CI, I have some room to
spare to host a few more boards, if it's relevant, feel free to contact
me.

This setup is cruelly lacking DWXGMAC IPs (only one now, and it's 1G only),
as well as stmmac boards that use a PCS. Only Lynx will get coverage with
the CycloneV board, there's no XPCS boards yet in the lab even though
it's quite an active area today.

The tests that are run are the tests in :

 - tools/testing/selftests/drivers/net
 - tools/testing/selftests/drivers/net/hw

Not all the tests are currently running, as some of them do not pass
cleanly on stmmac, either because of driver issues, or because the
selftest itself doesn't properly run on the boards.

The following tests are excluded :

  - drivers/net:napi_threaded.py
  - drivers/net:ring_reconfig.py
  - drivers/net/hw:rss_ctx.py
  - drivers/net/hw:xsk_reconfig.py
  - drivers/net/hw:xdp_features.py
  - drivers/net/hw:irq.py
  - drivers/net/hw:tso.py
  - drivers/net/hw:toeplitz.py
  - drivers/net/hw:rss_api.py
  - drivers/net/hw:rss_drv.py
  - drivers/net/hw:rss_flow_label.py
  - drivers/net/hw:nk_qlease.py
  - drivers/net:stats.py
  - drivers/net/hw:csum.py
  - drivers/net/hw:uso.py 
  - drivers/net/hw:nic_timestamp.py
  - drivers/net:xdp.py
  - drivers/net:gro_hw.py
  - drivers/net:gro_lro.py
  - drivers/net:gro_sw.py
  - drivers/net/hw:vlan.py
  - drivers/net/hw:devmem.py
  - drivers/net/hw:nk_devmem.py
  - drivers/net/hw:userns_devmem.py
  - drivers/net/hw:nk_netns.py
  - drivers/net:psp.py
  - drivers/net:macsec.py
  - drivers/net:netpoll_basic.py
  - drivers/net:ping.py
  - drivers/net/hw:ethtool.sh
  - drivers/net/hw:ethtool_extended_state.sh
  - drivers/net/hw:hw_stats_l3.sh
  - drivers/net/hw:hw_stats_l3_gre.sh

This list will likely shrink down in the near future, as the driver gets
cleaned-up, but also as the selftests themselves get adjusted to run on
less capable HW. Hopefully we can get the XDP/XSK tests online soon, as
there's a lot of activity in this area currently.

A few of these exclusions also result from the lab itself not supporting
some features (e.g. macsec or psp).

Note that there's also a secondary CI that runs a few test that aren't
covered by the kselftests, it's not much and doesn't get the same amount
of attention as the NetdevCI runner, but still it's useful for aggregated
results of the "ethtool -t" selftests runs :

https://minimaxwell.github.io/stmmac-ci/

Special thanks to Matthieu Baerts, Jakub and Andrew who helped a lot in
setting this CI up, and to Bootlin for hosting the results.

And of course, thank you to all stmmac contributors, this is the busiest
driver in net and we've seen a lot of efforts lately fixing bugs all over
the place, getting better PCS handling, better XDP/XSK support, better
TC support and overall multi-queue improvements, multi-buff mode, proper
MTU change and suspend/resume error handling, cleaner VLAN support...

Let's hope this CI can help making bigger reworks without the fear of
breaking other people's setup :)

Maxime

Re: [ANN] stmmac enters the Netdev CI

[Hangbin Liu]

Hi Maxime,
On Tue, Oct 20, 2026 at 11:07:16AM +0200, Maxime Chevallier wrote:
> Hi everyone,
> 
> It's my pleasure to inform you that the stmmac driver now has a runner
> that feeds into the Netdev CI. It runs in a lab I maintain, and the results
> are hosted by Bootlin, accessible here :
> 
> https://netdevci.bootlin.com/stmmac/results.json
> 
> What that means is that now contributions will be subject to CI
> validation, by having the kernel selftests run on real hardware.
> 
> Results are already aggregated in the patchwork contest, and can also
> be found here :
> 
> https://netdev.bots.linux.dev/devices.html
> https://netdev.bots.linux.dev/status.html

Thanks for your update!

> 
> As stmmac is an off-the-shelf IP from Synopsys and is integrated in a lot
> of different platforms out there, the CI currently runs on 9 different
> boards that include the following SoCs :
> 
>  - Starfive JH7110, riscV, dwmac 5.20 (rgmii-id w/ YT8531 PHY)
>  - LoongSon 2K0300, Loongarch, dwmac 3.70a (rgmii-id w/ YT8531 PHY)
>  - Amlogic S905X, arm64, dwmac 3.70a (rgmii-txid w/ RTL8211F PHY)
>  - Rockchip RK3566, arm64, dwmac4.20a (rgmii-id w/ RTL8211F PHY)
>  - Altera AgileX5, arm64, dwxgmac 2.10 (rgmii-id w/ KSZ9031 PHY)
>  - Altera cycloneV, arm, dwmac 3.70a (rgmii-id w/ KSZ9031 PHY)
>  - ST stm32mp157a, arm, dwmac 4.20a (rgmii-id </ RTL8211F PHY)
>  - Allwinner A20, arm, dwmac1000 (rgmii-id w/ RTL8211E PHY)
>  - Allwinner H2+, arm, Allwinner specific version (mii w/ internal PHY)


I’m curious about how our lab is maintained. Do we stick to a single distro
across all machines, or reinstall systems periodically? And how are
reinstalls done, manually or via BMC?

Also, do we run all selftests via virtme-ng or docker? Does virtme-ng support
all the architectures?

Thanks
Hangbin

Re: [ANN] stmmac enters the Netdev CI

[Maxime Chevallier]

On 10/21/26 03:49, Hangbin Liu wrote:
> Hi Maxime,
> On Tue, Oct 20, 2026 at 11:07:16AM +0200, Maxime Chevallier wrote:
>> Hi everyone,
>>
>> It's my pleasure to inform you that the stmmac driver now has a runner
>> that feeds into the Netdev CI. It runs in a lab I maintain, and the results
>> are hosted by Bootlin, accessible here :
>>
>> https://netdevci.bootlin.com/stmmac/results.json
>>
>> What that means is that now contributions will be subject to CI
>> validation, by having the kernel selftests run on real hardware.
>>
>> Results are already aggregated in the patchwork contest, and can also
>> be found here :
>>
>> https://netdev.bots.linux.dev/devices.html
>> https://netdev.bots.linux.dev/status.html
> 
> Thanks for your update!
> 
>>
>> As stmmac is an off-the-shelf IP from Synopsys and is integrated in a lot
>> of different platforms out there, the CI currently runs on 9 different
>> boards that include the following SoCs :
>>
>>  - Starfive JH7110, riscV, dwmac 5.20 (rgmii-id w/ YT8531 PHY)
>>  - LoongSon 2K0300, Loongarch, dwmac 3.70a (rgmii-id w/ YT8531 PHY)
>>  - Amlogic S905X, arm64, dwmac 3.70a (rgmii-txid w/ RTL8211F PHY)
>>  - Rockchip RK3566, arm64, dwmac4.20a (rgmii-id w/ RTL8211F PHY)
>>  - Altera AgileX5, arm64, dwxgmac 2.10 (rgmii-id w/ KSZ9031 PHY)
>>  - Altera cycloneV, arm, dwmac 3.70a (rgmii-id w/ KSZ9031 PHY)
>>  - ST stm32mp157a, arm, dwmac 4.20a (rgmii-id </ RTL8211F PHY)
>>  - Allwinner A20, arm, dwmac1000 (rgmii-id w/ RTL8211E PHY)
>>  - Allwinner H2+, arm, Allwinner specific version (mii w/ internal PHY)
> 
> 
> I’m curious about how our lab is maintained. Do we stick to a single distro
> across all machines, or reinstall systems periodically?
> And how are > reinstalls done, manually or via BMC?
> 
> Also, do we run all selftests via virtme-ng or docker? Does virtme-ng support
> all the architectures?

Tests are run baremetal on the hardware directly. All the SoCs mentionned above
are on single-board computers, devkits, or just some products out there that
have the right HW.

We're talking embedded devices here, so there's no BMC at all :)

The distro used is based on Buildroot, a build-system similar to Yocto, I can share
the configs if need be. It allows me to generate small images fast, that that
work on the plethora of CPU archs the lab has.

All the boards in the lab are booting an initramfs image through the network, and
the whole test session runs in it. Using a pure ram-stored rootfs allows bringing
the network down afterwards, while the tests are running. It also allows easily
updating the rootfs running on the boards when a new selftest get added for example.

All the boards are controlled through dedicated relays for power. As we're dealing
with embedded devices that consume only a few watts, it's only a matter of switching
some low-level DC voltages on/off (5V/12V/24V). I have a few mains-powered boards, also
controlled through relays.

The whole lab is managed via labgrid + some custom software on top of that to manage
the jobs, the builds, reporting results, etc.

I'd say, this setup is quite different to ones used for server-class HW, but the
whole thing runs on very simple hardware, cheap to acquire and run.

To give you an idea, the build machine I'm using is based on Intel Core Ultra 9 185H,
a laptop-class 22-core CPU that's in a NUC, and this is more than enough to build
kernels/rootfs for 10+ boards every 8 hours, with lots of time to spare :)

Maxime