[RFC PATCH] board: ti: common: board_detect: Fix EEPROM read quirk for 2-byte

[Tom Rini]

On Wed, Nov 30, 2022 at 06:38:43PM +0300, Matwey V. Kornilov wrote:
> ср, 30 нояб. 2022 г. в 18:36, Robert Nelson <robertcnelson at gmail.com>:
> >
> > > >>> 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.
> > > >
> > >
> > > Yes that does make sense... considering a new behavior of EEPROM keeps
> > > showing up. I will try refactoring the logic that way.
> >
> > Due to part shorages, sadly the BeagleBone AI64 (J721E) has both 1byte
> > and 2byte eeproms in user hands today..
> >
> > While I think most other previous designs have stuck with one type of
> > eeprom throughout their production life.  So just one big outlier that
> > I personally know of..
> 
> As was mentioned during the work on bf6376642fe8 ("board: ti: common:
> board_detect: Fix EEPROM read quirk"), BeagleBone Black produced by
> different companies has different kinds of EEPROMs.

I guess at this point before trying to refactor it's worth confirming
that we do have the case of boards that aren't still having some part of
the family produced, and so we can refactor the code in to "safe for
legacy boards" and "can't be sure if it's 1byte or 2byte".  And then if
it's worth doing the split anyhow, sigh.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20221130/fef45f5e/attachment.sig>