[PATCH 1/3] mtd: spi-nor: handle JEDEC manufacturer bank

[Michael Walle]

Hi,

> JEDEC JEP106 maintains a list of manufacturers IDs, consisting in 7
> bit of information plus 1 parity bit, for a total of 1 Byte. Since the
> number of manufacturers is way larger than this, JEDEC additionally
> defines the continuation code 0x7f to be used as a prefix to the
> actual ID, subdividing IDs in different banks.
>
> This commit handles such manufacturer bank code by introducing a new
> mfr_bank field in flash_info struct. This field is intended to be
> populated when specifying a manufacturer part, and for retro
> compatibility it is assumed to be 1 if omitted.
> Note that this assumption was already implicitly taken, as only a
> couple of the already supported manufacturer parts have the
> continuation code prefixed to the actual ID.
>
> Given the fast expanding pace of JEP106, the read ID operation has
> been expanded to 128 Bytes plus the pre-existing 6 Bytes for the ID
> code, thus supporting up to 128 banks.

Quick remarks without having looked deeper into this patch.

I really don't like issuing a 128byte command for older flashes.  So
maybe we can just stick to the 6 bytes and if that's not enough we
can use the extended format.

I'd like to keep the .id as the primary index. This will now
introduce a mfr_bank, so the unique key will be (mfr_bank,id). Can
we somehow encode the continuation codes into the id itself? E.g.
we know the manufacturer ID is always < 127. Honestly, I'm not sure
this is the way to go as we know flash manufacturers sometimes don't
care. So right now, we just compare the .id with whats returned by
the RDID command without interpreting it.

-michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 297 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20240805/d600c837/attachment.sig>