On Fri, Jun 17, 2022 at 02:19:57PM -0500, Nishanth Menon wrote: > On 14:50-20220617, Tom Rini wrote: > > On Fri, Jun 17, 2022 at 01:26:10PM -0500, Nishanth Menon wrote: > > > > > The eeprom data area is much bigger than the data we intend to store, > > > however, with bad programming, we might end up reading bad records over > > > and over till we run out of eeprom space. instead just exit when 10 > > > consecutive records are read. > > > > > > Signed-off-by: Nishanth Menon <n...@ti.com> > > > > Why not just stop at the first bad record? Otherwise 10 seems like a > > Because it could be just a couple of bad ones where the header.len > does'nt match up with record data. Some folks use a spreadsheet to > generate the records, some manually and some script it up - so, > attempting to get the best possible success chance while warning > invalid data to get people to fix things made sense. > > > fine, small, arbitrary number. If it's not arbitrary but number of > > total records, do we already enum the total number of records or > > something where we could say that we tried to read all possible records, > > everyone was bad, stop? > > It is arbitrary small value - for all practical purposes, we have 6 > types of records atm in u-boot, even looking ahead, we have'nt had > more than that I know of (I think display, camera and few other misc > types got added). The structure however, is by design flexible > with the END_LIST marker denoting the last record - and depending on > the eeprom size, you could theoretically have a large variation. > > Considering this is attempting to recover from bad programming, the > chances are better when attempting a few more entries, but I dont > think going aggressive with a single record or conservative (as it is > right now) in scanning the entire eeprom is necessary. That leaves us > with some sort of practical number.
OK, thanks for explaining. Reviewed-by: Tom Rini <tr...@konsulko.com> -- Tom
signature.asc
Description: PGP signature
