On 2013-02-23 15:08, Andreas Färber wrote: > Am 23.02.2013 15:02, schrieb Jan Kiszka: >> On 2013-02-23 14:12, Andreas Färber wrote: >>> Am 22.02.2013 21:39, schrieb Jan Kiszka: >>>> Rebased over current master, resolved new reports of >>>> checkpatch. >>> >>> This doesn't really take all developments in master into >>> account, comments on 2/2. > >> Yeah, that happens if such patches wait too long for being applied >> (3 months). 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. Jan
signature.asc
Description: OpenPGP digital signature
