Re: [Qemu-devel] [PATCH v2 0/2] i2c: Add AT24Cxx EEPROM model

[Jan Kiszka]

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