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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <Z-51jz_A73rHq1w9@KAN23-025>
Date: Thu, 3 Apr 2025 11:48:39 +0000
From: Markus Heidelberg <M.Heidelberg@....de>
To: Christian Eggers <ceggers@...i.de>
CC: Arnd Bergmann <arnd@...db.de>, Greg Kroah-Hartman
	<gregkh@...uxfoundation.org>, Rob Herring <robh@...nel.org>, "Krzysztof
 Kozlowski" <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, "Jiri
 Prchal" <jiri.prchal@...ignal.cz>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "devicetree@...r.kernel.org"
	<devicetree@...r.kernel.org>
Subject: Re: [RFC PATCH 0/2] eeprom: at25: support Cypress FRAMs without
 device ID

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