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

[liao jaime]

Hi Michael


>
> 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.
Ok, got it.
I have a idea, create a member maybe name .check_vendor in spi_nor_manufacturer.
A example, macronix_check_vendor function for checking this IC whether
belong macronix or not.
Each vendor could create their checking function for ID table didn't
include that ID.
Is it ok?
For general data information from RDID(0x9f) command, I prefer
checking 1st byte.
After checking, gigadevice , eon, esmt and macronix could follow this method.
Some vendor with multiple maf ID still could use this function for
checking vendor.
For some special cases like Spansion and Windbond, I think their
function should based on others like vendor space in SFDP.

>
> > 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.
Sorry, after checking, content of RDID 9F seems not a standard.

>
> >> 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.
Got it.
>
> So better include some proprietary tables in your next NOR flashes ;)
In my opinion, this may not a good way because of SFDP is growing up
then proprietary tables may have conflict address in the future.
So that Macronix octal flashes didn't include it now.

>
> -michael

Thanks
Jaime