linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Marek Vasut <marex@denx.de>
To: Huang Shijie <shijie8@gmail.com>
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: Thu, 17 Apr 2014 01:23:31 +0200	[thread overview]
Message-ID: <201404170123.31700.marex@denx.de> (raw)
In-Reply-To: <20140416135640.GA1869@localhost.localdomain>

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.

Thank you

Best regards,
Marek Vasut

  reply	other threads:[~2014-04-16 23:41 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 [this message]
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=201404170123.31700.marex@denx.de \
    --to=marex@denx.de \
    --cc=angus.clark@st.com \
    --cc=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --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).