Hello Eugen, Am 07.05.2020 um 10:53 schrieb Eugen Hristev:
Because of this commit : 5ae84860b0 ("misc: i2c_eeprom: verify that the chip is functional at probe()") at probe time, each eeprom is tested for read at offset 0.The Atmel AT24MAC402 eeprom has different mapping. One i2c slave address is used for the lower 0x80 bytes and another i2c slave address is used for the upper 0x80 bytes. Because of this basically the i2c master sees 2 different slaves. We need the upper bytes because we read the unique MAC address from this EEPROM area. However this implies that our slave address will return error on reads from address 0x0 to 0x80. To solve this, implemented an offset field inside platform data that is by default 0 (as it is used now), but can be changed in the compatible table. The probe function will now read at this offset and use it, instead of blindly checking offset 0. This will fix the regression noticed on these EEPROMs since the commit abovementioned that introduces the probe failed issue. Signed-off-by: Eugen Hristev <[email protected]> --- Please disregard patch [PATCH] misc: i2c_eeprom: implement different probe test eeprom offset as that patch was mistakenly done on an older u-boot version. This v2 patch applies correctly on u-boot/master Changes in v2: - adapt to latest changes in driver. v1 was done on u-boot 2020.01 accidentaly. drivers/misc/i2c_eeprom.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)
Applied to u-boot-i2c master Thanks! May we should rethink and look at what linux do, but as it fixes a bug it is ok for me. bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: [email protected]
