[PATCH 1/3] mtd: spi-nor: handle JEDEC manufacturer bank
A. Zini
alessandro.zini at siemens.com
Wed Aug 7 06:37:40 PDT 2024
> > 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.
>
> 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 agree that there may be better solutions than this. The idea for this
patch was indeed to gather some of them and trigger a discussion.
The question I have here is how can we determine when it's "enough"?
> 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.
Even though the manufacturer bank is technically not part of the ID as
per JEDEC standard, it's still a piece of information needed to
correctly identify a chip and avoid collisions.
Therefore, my opinion is that it should be part of the unique key,
whether encoded in the id itself or in a different field.
One other possibility could be, when needed, to add two bytes to the id
field, them being one continuation code and one multiplier factor
indicating how many continuation codes are present for this
manufacturer. The absence of the leading continuation code would
(obviously) be assumed as bank 1.
The spi_nor_match_id() function should of course be adapted to handle
this additional information, but we would not have to add an additional
mfr_bank field.
--
Alessandro
More information about the linux-mtd
mailing list