Wolfgang Denk wrote:
Why is this i2c_read() needed or actually useful? Should the error return code from the i2c_write() above not be sufficient indication that the writing failed? If that was the case, then some other parts of the code need fixing.
That's just the way the EEPROM chip works. When it's set into write-protect mode, it cheerfully accepts all of the I2C write commands, and acknowledges them appropriately, but it doesn't actually store the data into the EEPROM. The read-back is the only way I've found to verify that the write has actually occurred.
This patch fixes a real problem with all of our boards that use this EEPROM chip, which is almost all of our 83xx, 85xx, and 86xx boards. Some of our boards would be shipped with EEPROM write-protected. The current code caches the EEPROM contents in memory. After using the "mac save" command, the code would think that the EEPROM was updated. Issuing the "mac read" command again would *not* re-read from the EEPROM, because the code would think that the cached value is up-to-date. The only way you would know if the EEPROM write failed is to reboot the board.