Re: [PATCH v3 2/5] mtd: spi-nor: core: Hook manufacture by checking first byte ID

From: Michael Walle <mwalle@kernel.org>
To: liao jaime <jaimeliao.tw@gmail.com>
Cc: linux-mtd@lists.infradead.org, tudor.ambarus@linaro.org,
	pratyush@kernel.org, miquel.raynal@bootlin.com,
	leoyu@mxic.com.tw, JaimeLiao <jaimeliao@mxic.com.tw>
Subject: Re: [PATCH v3 2/5] mtd: spi-nor: core: Hook manufacture by checking first byte ID
Date: Thu, 10 Aug 2023 09:27:39 +0200	[thread overview]
Message-ID: <92234e4c5aca657a966d7c4d9d5f219a@kernel.org> (raw)
In-Reply-To: <CAAQoYR=JQVd3iqfCYKjvkbFSGVWJRX1xFni6CsNht9prhuQ1EA@mail.gmail.com>

Hi,

>> This won't work beacuse the manufacturer id is not always
>> one byte long, think of continuation codes. In fact, as the
>> flash_info table is of now, we cannot even rely on the
>> continuation codes, but we have to always check for the
>> complete id_len, i.e. there is at least one hack where
>> the id is reversed and the manufacturer is the last byte,
>> iirc. some oddball cypress mram chip.
> According JEDEC standard, 1st byte is manufacture ID.
> I check id table, "cy15x104q" with multi manufacture ID in
> later bytes by RDID command(9F).

Yes the currently supported cy15x104q is broken.. but nevertheless
it's there. Also some spansion flashes uses winbond manufacturer
ids.

> Maybe some old flash didn't follow this but I think it isn't
> a high percentage.
> Most of all and new product are follow JEDEC.

Have a look at JEP106 (mine is JEP106BC) and you'll see all the
manufacturer IDs defined by JEDEC and you'll see that except
for the first 127, all others are multibyte vendor IDs starting
with continuation codes.

And it seems that the command RDID 9F is not covered in any
JEDEC standard. At least I haven't found anything. If you know
where that command is defined, please let me know.

>> If you want to get the correct manufacturer for spi-nor-generic,
>> you should extract it from the SFDP tables. It seems that the
>> BFPT don't include a manufacturer id, but if there are proprietary
>> tables, you *might* use that id. I say might, because it only works
>> with one byte manufacturer ids, no continuation codes... *sigh*
> 
> Unfortunately, Macronix didn't include proprietary tables in SFDP for
> octal flashes and as I understanding proprietary table is not a 
> stardard.
> So that content and address are not identical each vendor, it will need
> a manufacturer fixups for reading.

Yes thats by definition not a standard, *but* the header with the
manufacturer id *is* standard.

So better include some proprietary tables in your next NOR flashes ;)

-michael

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/