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

[liao jaime]

Hi Michael , Tudor


>
> 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.

For this part, have any ideas?
We hope that we could do something for reducing reliability of ID table.
It will be good if new flashes could get all features without comparing flash id
on ID tables.

>
> >
> > -michael
> Thanks
> Jaime

Thanks
Jaime