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

liao jaime jaimeliao.tw at gmail.com
Mon Aug 14 01:24:54 PDT 2023


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?
>
> Honestly, I'm against adding that vendor discovery stuff to the
> generic nor driver. What's the use case of it? You can just
> read the ID from userspace and a tool there can decide which
> flash it is.
Most of information could get by parsing SFDP.
We hope that highest protocol(8D-8D-8D) could used without adding IDs.
Because of octal_dtr function is still reply on mafacturer hook function.
So that vendor discovery could make up deficiency.

>
> -michael
Thanks
Jaime



More information about the linux-mtd mailing list