Re: [PATCH 2/3] board: ti: common: Handle the legacy eeprom address width properly

2022-07-06 Thread Tom Rini
On Fri, Jun 17, 2022 at 01:26:11PM -0500, Nishanth Menon wrote:

> Due to supply chain issues, we are starting to see a mixture of eeprom
> usage including the smaller 7-bit addressing eeproms such as 24c04
> used for eeproms.
> 
> These eeproms don't respond well to 2 byte addressing and fail the
> read operation. We do have a check to ensure that we are reading the
> alternate addressing size, however the valid failure prevents us
> from checking at 1 byte anymore.
> 
> Rectify the same by falling through and depend on header data comparison
> to ensure that we have valid data.
> 
> Signed-off-by: Nishanth Menon 
> Reviewed-by: Tom Rini 

Applied to u-boot/next, thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: [PATCH 2/3] board: ti: common: Handle the legacy eeprom address width properly

2022-06-18 Thread Tom Rini
On Fri, Jun 17, 2022 at 01:26:11PM -0500, Nishanth Menon wrote:

> Due to supply chain issues, we are starting to see a mixture of eeprom
> usage including the smaller 7-bit addressing eeproms such as 24c04
> used for eeproms.
> 
> These eeproms don't respond well to 2 byte addressing and fail the
> read operation. We do have a check to ensure that we are reading the
> alternate addressing size, however the valid failure prevents us
> from checking at 1 byte anymore.
> 
> Rectify the same by falling through and depend on header data comparison
> to ensure that we have valid data.
> 
> Signed-off-by: Nishanth Menon 

Reviewed-by: Tom Rini 

-- 
Tom


signature.asc
Description: PGP signature


[PATCH 2/3] board: ti: common: Handle the legacy eeprom address width properly

2022-06-17 Thread Nishanth Menon
Due to supply chain issues, we are starting to see a mixture of eeprom
usage including the smaller 7-bit addressing eeproms such as 24c04
used for eeproms.

These eeproms don't respond well to 2 byte addressing and fail the
read operation. We do have a check to ensure that we are reading the
alternate addressing size, however the valid failure prevents us
from checking at 1 byte anymore.

Rectify the same by falling through and depend on header data comparison
to ensure that we have valid data.

Signed-off-by: Nishanth Menon 
---
 board/ti/common/board_detect.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/board/ti/common/board_detect.c b/board/ti/common/board_detect.c
index 381cddc00ad1..0806dea11ed5 100644
--- a/board/ti/common/board_detect.c
+++ b/board/ti/common/board_detect.c
@@ -86,7 +86,7 @@ __weak void gpi2c_init(void)
 static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, int dev_addr,
u32 header, u32 size, uint8_t *ep)
 {
-   u32 hdr_read;
+   u32 hdr_read = 0xdeadbeef;
int rc;
 
 #if CONFIG_IS_ENABLED(DM_I2C)
@@ -107,9 +107,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
if (rc)
return rc;
 
-   rc = dm_i2c_read(dev, 0, (uint8_t *)_read, 4);
-   if (rc)
-   return rc;
+   /*
+* Skip checking result here since this could be a valid i2c read fail
+* on some boards that use 1 byte addressing.
+* We must allow for fall through to check the data if 1 byte
+* addressing works
+*/
+   (void)dm_i2c_read(dev, 0, (uint8_t *)_read, 4);
 
/* Corrupted data??? */
if (hdr_read != header) {
@@ -144,9 +148,13 @@ static int __maybe_unused ti_i2c_eeprom_get(int bus_addr, 
int dev_addr,
 */
byte = 2;
 
-   rc = i2c_read(dev_addr, 0x0, byte, (uint8_t *)_read, 4);
-   if (rc)
-   return rc;
+   /*
+* Skip checking result here since this could be a valid i2c read fail
+* on some boards that use 1 byte addressing.
+* We must allow for fall through to check the data if 1 byte
+* addressing works
+*/
+   (void)i2c_read(dev_addr, 0x0, byte, (uint8_t *)_read, 4);
 
/* Corrupted data??? */
if (hdr_read != header) {
-- 
2.31.1