On 2013-02-23 15:40, Andreas Färber wrote: > Am 23.02.2013 15:29, schrieb Jan Kiszka: >> On 2013-02-23 15:08, Andreas Färber wrote: >>> Am 23.02.2013 15:02, schrieb Jan Kiszka: >>>> Will address the QOM changes, but I need to check back with >>>> $customer regarding test suite efforts. >>> >>> Thanks. My concern here is in particular that this device is not >>> added to any machine, so it gets no implicit testing. Nor does >>> the commit message or cover letter specify with which command >>> line and guest it has been tested. > >> The device is target-agnostic, naturally. We use it with >> versatilepb. > >>> Whether all code paths actually get test coverage is less >>> relevant to me than a smoke test to assure my QOM refactorings >>> don't break anything. :) > >> Even that is not trivial. Unless something in the guest actively >> pokes the device, nothing will happen. > >> To make a useful basic test, you need to enable the device in the >> guest (echo <type> <addr> > /sys/bus/i2c/devices/i2c-0/new_device), >> read from it (/sys/.../eeprom) and compare the result against the >> expected content. Writing/write-protection tests would make some >> sense, too. > >> I will have to look closer at what the test infrastructure provides >> in this regard - and if the target kernel is already supporting >> AT24. > > qtest does not use any Linux kernel at all, instead it uses direct > PIO/MMIO wrapped in libqos helper functions. You can directly initiate > transfers to the device at address X and assert that the received data > matches your expectations. E.g., reading zero data or writing some > 0x42 test data and reading it back. Cf. tests/tmp105-test.c.
OK, even worse then. This one is already better tested against existing driver stacks (some master + at24) than rewriting them. Jan
signature.asc
Description: OpenPGP digital signature
