On Wed, Apr 06, 2022 at 03:08:16PM +0200, Jonathan Cameron wrote: > On Tue, 5 Apr 2022 15:48:05 +0200 > Vincent Whitchurch <vincent.whitchurch@xxxxxxxx> wrote: > I messed around the other day with writing tests for > drivers/staging/iio/cdc/ad7746.c and wasn't "too bad" and was useful for > verifying some refactoring (and identified a possible precision problem > in some integer approximation of floating point calcs) Good to hear! > I'll try and find time to flesh that test set out more in the near future and > post it so you can see how bad my python is. It amused my wife if nothing > else :) > > However a future project is to see if I can use this to hook up the SPDM > attestation stack via mctp over i2c - just because I like to live dangerously :) > > For IIO use more generally we need a sensible path to SPI (and also platform > drivers). I have SPI working now. I was able to do this without patching the kernel by have the Python code emulate an SC18IS602 I2C-SPI bridge which has an existing driver. There is a limitation of 200 bytes per transaction (in the SC18IS602 driver/chip) so not all SPI drivers will work, but many will, and the underlying backend can be changed later without having to change the test cases. I used this to implement a test for drivers/iio/adc/ti-adc084s021.c. Platform devices are going to take more work. I did do some experiments (using arch/um/drivers/virt-pci.c) a while ago but I need to see how well it works with the rest of the framework in place. > For my day job I'd like to mess around with doing PCI devices > as well. The PCI DOE support for example would be nice to run against a > test set that doesn't involve spinning up QEMU. > DOE driver support: > https://lore.kernel.org/all/20220330235920.2800929-1-ira.weiny@xxxxxxxxx/ > > Effort wise, it's similar effort to hacking equivalent in QEMU but with the > obvious advantage of being in tree and simpler for CI systems etc to use. > > It would be nice to only have to use QEMU for complex system CI tests > like the ones we are doing for CXL. > > > > > > I dream of a world where every driver is testable by people with out hardware > > > but I fear it may be a while yet. Hopefully this will get us a little > > > closer! > > > > > > I more or less follow what is going on here (good docs btw in the earlier > > > patch definitely helped). > > > > > > So far I'm thoroughly in favour of road test subject to actually being > > > able to review the tests or getting sufficient support to do so. > > > It's a 'how to scale it' question really... > > > > Would rewriting the framework in C and forcing tests to be written in > > that language mean that maintainers would be able to review tests > > without external support? > > I was wondering that. If we stayed in python I think we'd definitely want > someone to be the 'roadtester/tests' maintainer (or group of maintainers) > and their Ack to be expected for all tests we upstream. Idea being they'd > sanity check correct use of framework and just how bad the python code > us C developers are writing is ;) > > However, we'd still need a good chunk of that 'framework' use review even > if doing this in C. I think this is reasonable, especially for the first tests for each subsystem where there will likely be support code and framework bits missing.
