From: Eugen Hristev <eugen.hristev@microchip.com>
To: u-boot@lists.denx.de
Subject: [PATCH v2] misc: i2c_eeprom: implement different probe test eeprom offset
Date: Thu, 7 May 2020 11:53:18 +0300 [thread overview]
Message-ID: <20200507085318.559418-1-eugen.hristev@microchip.com> (raw)
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@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(-)
diff --git a/drivers/misc/i2c_eeprom.c b/drivers/misc/i2c_eeprom.c
index ef5f103c98..32a1b20856 100644
--- a/drivers/misc/i2c_eeprom.c
+++ b/drivers/misc/i2c_eeprom.c
@@ -17,6 +17,7 @@ struct i2c_eeprom_drv_data {
u32 pagesize; /* page size in bytes */
u32 addr_offset_mask; /* bits in addr used for offset overflow */
u32 offset_len; /* size in bytes of offset */
+ u32 start_offset; /* valid start offset inside memory, by default 0 */
};
int i2c_eeprom_read(struct udevice *dev, int offset, uint8_t *buf, int size)
@@ -147,7 +148,11 @@ static int i2c_eeprom_std_probe(struct udevice *dev)
i2c_set_chip_addr_offset_mask(dev, data->addr_offset_mask);
/* Verify that the chip is functional */
- ret = i2c_eeprom_read(dev, 0, &test_byte, 1);
+ /*
+ * Not all eeproms start from offset 0. Valid offset is available
+ * in the platform data struct.
+ */
+ ret = i2c_eeprom_read(dev, data->start_offset, &test_byte, 1);
if (ret)
return -ENODEV;
@@ -215,6 +220,7 @@ static const struct i2c_eeprom_drv_data atmel24mac402_data = {
.pagesize = 16,
.addr_offset_mask = 0,
.offset_len = 1,
+ .start_offset = 0x80,
};
static const struct i2c_eeprom_drv_data atmel24c32_data = {
--
2.25.1
next reply other threads:[~2020-05-07 8:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-07 8:53 Eugen Hristev [this message]
2020-05-07 10:35 ` [PATCH v2] misc: i2c_eeprom: implement different probe test eeprom offset Heiko Schocher
2020-05-07 15:02 ` Baruch Siach
2020-05-07 15:08 ` Eugen.Hristev at microchip.com
2020-05-28 3:59 ` Heiko Schocher
2020-05-28 4:25 ` Eugen.Hristev at microchip.com
2020-05-30 3:49 ` Heiko Schocher
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200507085318.559418-1-eugen.hristev@microchip.com \
--to=eugen.hristev@microchip.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox