linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: Marek Vasut <marex@denx.de>
Cc: linux-mtd@lists.infradead.org, computersforpeace@gmail.com,
	Huang Shijie <shijie8@gmail.com>,
	dwmw2@infradead.org, angus.clark@st.com
Subject: Re: [PATCH] mtd: spi-nor: read 6 bytes for the ID
Date: Thu, 17 Apr 2014 12:55:34 +0800	[thread overview]
Message-ID: <20140417045532.GA29495@localhost> (raw)
In-Reply-To: <201404170123.31700.marex@denx.de>

On Thu, Apr 17, 2014 at 01:23:31AM +0200, Marek Vasut wrote:
> On Wednesday, April 16, 2014 at 03:56:43 PM, Huang Shijie wrote:
> > On Wed, Apr 16, 2014 at 12:18:28PM +0200, Marek Vasut wrote:
> > > 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".
> > 
> > okay.
> > 
> > > > > > > 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.htm
> > > > l
> > > 
> > > 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.
> > 
> > wait for your patch.
> 
> Please keep the discussion professional and avoid threats.
> 
Please do not make mistake about me. :) it is not a threat.

If add the readid length field to the table, i will implement nearly the
same code as Clark did. I thought You have a better idea maybe.



thanks
Huang Shijie

  reply	other threads:[~2014-04-17  5:51 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
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 [this message]
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=20140417045532.GA29495@localhost \
    --to=b32955@freescale.com \
    --cc=angus.clark@st.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=marex@denx.de \
    --cc=shijie8@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).