From: Huang Shijie <shijie8@gmail.com>
To: Marek Vasut <marex@denx.de>
Cc: Huang Shijie <b32955@freescale.com>,
computersforpeace@gmail.com, linux-mtd@lists.infradead.org,
dwmw2@infradead.org, angus.clark@st.com
Subject: Re: [PATCH] mtd: spi-nor: read 6 bytes for the ID
Date: Wed, 16 Apr 2014 00:04:05 +0800 [thread overview]
Message-ID: <20140415160402.GA2926@localhost.localdomain> (raw)
In-Reply-To: <201404151535.05561.marex@denx.de>
On Tue, Apr 15, 2014 at 03:35:05PM +0200, Marek Vasut wrote:
> On Tuesday, April 15, 2014 at 07:22:39 AM, Huang Shijie wrote:
> > On Mon, Apr 14, 2014 at 08:23:47PM +0200, Marek Vasut wrote:
>
> [...]
>
> > > > > I wonder if the ID-bytes wraparound cannot cause us trouble here. For
> > > > > example if we try to detect a SPI NOR which has 5-byte ID code, but
> > > > > in the table, we'd also have a SPI NOR with has a 6-byte code where
> > > > > the last byte of ext-jedec matches the first byte of JEDEC ID , this
> > > > > would actually match on the later.
> > > >
> > > > could you give me detail example?
> > > >
> > > > I feel sorry that i do not quit understand your meaning.
> > >
> > > Imagine two chips with two IDs:
> > > Chip 1 has IDs: 0xf00b42 0x4242f0 and readID[6] returns 0x420bf0f04242
> >
> > It will not return 0x420bf0f04242.
> >
> > The readID[6] should be: f0, 0b, 42, 42, 42, f0.
> >
> > > Chip 2 has IDs: 0xf00b42 0x42f0 and readID[6] returns 0x420bf0f04242
> >
> > the readID[6] should be: f0, 0b, 42, 42, f0, XX.
> >
> > "XX" stands for the sixth byte.
> >
> > The current patch can distinguish these two chips.
> >
> > > This is because in the second chips' case the ID wraps around at 5 bytes.
> > > But chip #1 matches the ID, so if chip #1 is earlier in the list of SPI
> > > NOR flashes, we will get an incorrect detection of that chip.
> >
> > I guess your meaning is that the chip 2 has IDs: 0xf00b42 0x4242
> > and the sixth byte is 0xf0 which wraps the first byte.
>
> Huang, what I meant is that if you read 6 bytes of ID from a chip which wraps
> the READID command output on 5 bytes AND the first and last byte match in the
> table for some 6-byte chip, then this 6-byte chip will be used as a
> configuration for the different 5-byte chip.
Does the chip vendor so silly to produce such chips? :)
>
> 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. Btw: I do not object to add the length field.
thanks
Huang Shijie
next prev parent reply other threads:[~2014-04-15 16:04 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-14 10:09 [PATCH] mtd: spi-nor: read 6 bytes for the ID Huang Shijie
2014-04-14 11:53 ` Marek Vasut
2014-04-14 14:44 ` Huang Shijie
2014-04-14 18:23 ` Marek Vasut
2014-04-15 5:22 ` Huang Shijie
2014-04-15 13:35 ` Marek Vasut
2014-04-15 16:04 ` Huang Shijie [this message]
2014-04-15 18:48 ` Marek Vasut
2014-04-16 1:52 ` Huang Shijie
2014-04-16 10:18 ` Marek Vasut
2014-04-16 13:56 ` Huang Shijie
2014-04-16 23:23 ` Marek Vasut
2014-04-17 4:55 ` Huang Shijie
2014-04-22 8:19 ` Huang Shijie
2014-05-27 1:12 ` Huang Shijie
2014-05-27 15:57 ` Christophe KERELLO
2014-05-28 5:22 ` Huang Shijie
2014-05-28 16:27 ` Christophe KERELLO
2014-05-29 20:58 ` Marek Vasut
2014-05-30 0:49 ` Huang Shijie
2014-06-03 14:23 ` Marek Vasut
2014-08-04 23:24 ` Brian Norris
2014-08-05 0:52 ` Huang Shijie
2014-08-05 7:14 ` Marek Vasut
2014-08-06 0:23 ` Huang Shijie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140415160402.GA2926@localhost.localdomain \
--to=shijie8@gmail.com \
--cc=angus.clark@st.com \
--cc=b32955@freescale.com \
--cc=computersforpeace@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.