[PATCH v2] misc: i2c_eeprom: implement different probe test eeprom offset

[Heiko Schocher]

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 <eugen.hristev at microchip.com>
> ---
> 
> 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: hs at denx.de