On 9/3/26 18:51, Andrew Lunn wrote:
> Nice. Did you give the liburing tests a quick smoke test? I had to bump liburing on my BR setup, I managed to get it to run, but it wasn't easy :/ I've started an effort to run the kselftests on my fleet of random devices, trying various ways of interconnecting them with one another. This will be needed for the ethtool tests. I'm generating my rootfs with buildroot on all my boards, so I'm slowly getting a list of options to enable for proper kselftest runs. Focusing only on drivers/net/hw, all the kselftests that tests the local device have no trouble running once you get the proper list dependencies installed. (one example, some tests will grep through include/linux/ethtool.h, so you need kernel headers on the rootfs) I've already found some drivers bugs here and there with that, for example mvpp2 fails the RSS kselftests (wonder who wrote that...) But then there's the kselftests that require a peer, and here it's another story. Some tests, when using the SSH remote type, will scp a small binary on the peer and use that binary for testing (sending specially crafted frames, etc.) Just in the drivers/net/hw tests, we have : drivers/net/hw/csum.py drivers/net/hw/devmem_lib.py drivers/net/hw/gro_hw.py drivers/net/hw/iou-zcrx.py drivers/net/hw/nk_qlease.py Thing is, what I have is a mixed bag of arm, aarch64, a few riscv, x86 and even ppc32 in there, so as you can guess, scp'ing an arm binary on a riscv peer doesn't work as one expects... took me a while to figure this out :( My setup is quite extreme but even for day to day development, I suspect most devs are directly connecting their embedded board to their x86 host for testing. We could expand the remote_ssh logic to probe the peer, and raise a skip if it's a different arch than the dut. Or better, have the DUT check if the peer doesn't already have the tool in question, i.e. the kselftest "package" is also installed there. > > I get the feeling not many Embedded people run the self tests, if > basic things like cross compilation does not work, and native 32bit > builds spits out 1000s of warnings. Indeed... my idea for stmmac is to grab as many random stmmac boards as I can to get a good sample of glue drivers + PHYs, and run the kselftest on them (hopefully one day feeding that into NIPA). I can already tell the simple kselftests run well when cross-compiled on arm, aarch64 and riscv but the interop issue needs resolving. Then it's a matter of adding a lot more tests. Hopefully this will give enough experience on what's to solve so that everyone else can do it as well... Maxime
