Hi Björn, > This is the i2c-controller in the ARTPEC-6 system. The driver itself is not > yet upstreamed. Thanks for the info. > My line of though here was that the previous code used a flag called > "first_write" to keep track of which part of the write is the address. With > 16 bit addresses we need to keep track of both the first and the second > write, thus a variable that keeps track of which write it is (first, second, > third, etc..), thus the name "write_nbr". What would be a better name, > "write_cnt", "initial_write_cnt"? Ah, 'nbr' is not an acronym and simply stands for 'number'. I understood what the variable does, but not the name. I'd prefer 'idx_write_cnt' but 'initial_write_cnt' is OK, too. > > until Tuesday. What kind of tests did you perform? > > > The use case we have is to have this code running on one system and > load the virtual eeprom with a static file. Then another system will > read this data over i2c. This scenario is the one we tested the most. > During development I also tested to connect this device to another i2c > port on the same system and cat files to the entries in /sys in both > directions and verify that they are the same. I have not run any > extensive test-suit that tested every possible combinations of read > and write commands. I don't think we need to test every possible combination, but focus on the stuff you changed. Reading the above, I think plain reading/writing various files has been tested and works fine. One new thing which could happen now is that for a 16 bit address pointer, only 8 bit get sent before a repeated start switches to reading data. This can be easily simulated with the 'i2ctransfer' tool from i2c-utils. TBH, I have no idea how real EEPROMs react to this situation. Our driver currently uses the pointer with only 8 bits fed and the upper 8 bits being 0. This could be valid. Do you have a real EEPROM to check against? Regards, Wolfram
Attachment:
signature.asc
Description: PGP signature
