Re: [RFC PATCH 0/2] eeprom: at25: support Cypress FRAMs without device ID

[Markus Heidelberg <M.Heidelberg@cab.de>]

On Wed, Apr 02, 2025 at 12:49:24PM +0200, Christian Eggers wrote:
> maybe the "EEPROM" protocol used by at24 (I2C) and at25 (SPI) EEPROMs is
> not smart enough to provide really useful detection of device capabilities.
> At least I remember that I2C eeproms of different sizes require a different
> number of bytes for addressing. AFAIK, using a wrong number of addressing bytes
> may accidentally overwrite data on the device. If this is the same for SPI
> eeproms / FRAMs, reliable auto-detection may be impossible or require
> at least knowing the vendor in advance.

The "read device ID" command works without address, so it can be used to
determine the memory size and thus the address length.

If the response to this command is similar for various devices/vendors
(in consideration of the variable length manufacturer ID using the 0x7F
continuation code), auto-detection should be possible without having to
know the manufacturer in advance and without having to interpret it from
the read ID.

But the maximum possible response length increases by one byte with each
new manufacturer bank of up to 126 manufacturers added to the JEDEC ID
list.

> Flash (MTD) devices provide much more powerful methods for enumerating the
> device's geometry/capabilities than eeprom/fram. But even for ONFI there are
> extra tables for vendor/device specific workarounds. I am not sure whether
> adding such stuff for at24/at25 devices is really worth the trouble...

I feel the same that this wouldn't be worth it, but I guess it's
avoidable if further auto-detection should needed by someone.

Markus