Re: [PATCH] mtd: spi-nor: read 6 bytes for the ID

Marek Vasut
2014-04-16T11:04:08Z

On Wednesday, April 16, 2014 at 03:52:03 AM, Huang Shijie wrote:

[...]

> > > Does the chip vendor so silly to produce such chips? :)
> >
> > I don't quite understand the meaning of this sentence, but the approach
> > where we try heuristics doesn't scale.
>
> If two chips share the same jedec_id, it means the two chips are produced
> from the same chip vendor, such as 0x012018 means the chip is from
> Spansion.
>
> If two chips share the same 5 bytes ID, the two chips definitely are
> produced from the same vendor.
>
> So my meaning is the case what are you mentioned will _not_ exit in the
> real world. Spansion will not so silly.

You do have an awful amount of trust for those things. I am better of with
"better safe than sorry".

> > > > This code should be future-proof, but if we keep adding such special
> > > > cases, we will end up with false matches sooner or later anyway I'm
> > > >
> > > > afraid.
> > > >
> > > > What do you say we add the READID length field into the table ?
> > >
> > > If we add the length field into the table, we have to sort the table by
> > > some kind of order.
> >
> > Why, please elaborate.
>
> pleas see:
> http://lists.infradead.org/pipermail/linux-mtd/2013-December/050670.html

Sorry, but this really doesn't answer my question. It's only a matter of
correctly implementing the matching function to find a proper match.

Can we get insight on this from the others please ?

> If you are interested in this issue, please give us a patch.
> What I want is making the kernel can support the s25fl128s as soon as
> possible.

Perfect, I'd prefer to support it as correctly as possible.

Best regards,
Marek Vasut