On Tue, Nov 29, 2022 at 03:10:12PM +0300, Matwey V. Kornilov wrote:
> вт, 29 нояб. 2022 г. в 09:50, Neha Malcom Francis <n-fran...@ti.com>:
> >
> > EEPROM detection logic in ti_i2c_eeprom_get() involves figuring out
> > whether addressing is 1-byte or 2-byte. There are currently different
> > behaviours seen across boards as documented in commit bf6376642fe8
> > ("board: ti: common: board_detect: Fix EEPROM read quirk"). Adding to
> > the list, we see that there are 2-byte EEPROMs that read properly
> > with 1-byte addressing with no offset.
> >
> > For ti_i2c_eeprom_am6_get where eeprom parse operation is dynamic, the
> > earlier commit d2ab2a2bafd5 ("board: ti: common: board_detect: Fix
> > EEPROM read quirk for AM6 style data") tried to resolve this by running
> > ti_i2c_eeprom_get() twice. However this commit along with its former
> > commit fails on J7 platforms where EEPROM successfully return back the
> > header on 1-byte addressing and continues to do so until an offset is
> > introduced. So the second read incorrectly determines the EEPROM as
> > 1-byte addressing.
> >
> > A more generic solution is introduced here to solve
> > this issue: 1-byte read without offset and 1-byte read with offset. If
> > both passes, it follows 1-byte addressing else we proceed with 2-byte
> > addressing check.
> >
> > Tested on J721E, J7200, DRA7xx, AM64x
>
> I'll try to test this on the AM335x boards I have as soon as possible.I wonder if we should re-factor this code a bit and not have a single ti_i2c_eeprom_get but instead build for whichever sets of quirks a given family of boards has with their EEPROMs. I really worry that we're going to find that this change here breaks yet another different EEPROM than before. -- Tom
signature.asc
Description: PGP signature
