> Very good idea to use a slave to send the Host-Notify command to the host > for testing. Later on, for SMBus-Alert, a GPIO can be used to loop it back > to the tested master to verify that SMBus-Alert is working fine. Glad you like it! Yes, SMBusAlert is the next addition planned. > What you implemented is the "remote" side which I understood is meant to > replace a "real" device for those features which are not that common. Correct. > Shouldn't we also have the "master" side loopback test driver as well to > work with this test slave driver ? Yes, ultimately we want that. But for this first draft, I simply triggered with 'i2cset' and checked debug prints plus debugfs for desired outcome. > For example for the Host-Notify that master side loopback test driver would > perform the request_irq allowing it to be called back when the slave test > driver sends the host-notify command. > In case of SMBus-Alert, that would be implementing the .alert function that > would be called when the SMBus-Alert is received .. Exactly. I am simply focussed on the remote side for now because I am curious if it works at all. And what other parts need fixing, e.g. the I2C core patch I sent a few minutes ago. > With that the whole loop can be automatically tested. This kind of stuff > can of course be enhanced to a LOT of cases .... basically something similar > to spi-loopback driver for example except that in case of i2c it needs 2 > I2C controllers instead of one for the SPI. This is my ultimate goal, too: scriptable tests for I2C mastes. Basic functionality can be tested with a simple device, say an EEPROM. But the rare stuff needs something like this testunit.
Attachment:
signature.asc
Description: PGP signature
