All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang Shijie <b32955@freescale.com>
To: Brian Norris <computersforpeace@gmail.com>
Cc: linux-mtd@lists.infradead.org,
	Matthieu Castet <matthieu.castet@parrot.com>,
	linux-arm-kernel@lists.infradead.org,
	Florian Fainelli <ffainelli@freebox.fr>
Subject: Re: [PATCH] mtd: fix the wrong check condition
Date: Thu, 16 Feb 2012 11:12:51 +0800	[thread overview]
Message-ID: <4F3C7433.5030306@freescale.com> (raw)
In-Reply-To: <4F3C712A.5060406@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]

Hi,
> (Add Florian and Matthieu)
>
> On 2/15/2012 2:33 AM, Huang Shijie wrote:
>> If we use `||` check condition, many NAND chips which are not
>> ONFI nands have to do the ONFI detection.
>
> Running the ONFI detection on non-ONFI NAND should not, ideally, be a 
> problem. They should fail one or both tests included in the routine: 
> the 'O N F I' string check or the CRC calculation.
NO.

I have Hynix nand in my hand: H27UBG8T2A (page size :8192, oob:448).
It is not an ONFI nand. See the datasheet in the attachment.
But it accidentally can pass the ONFI detection, and get the result : 
page size 4192, oob:96. This is a wrong result.




>
>> Use `&&` here to detect the ONFI NAND when we can not find any type
>> in the nand_flash_ids.
>
> There are many chips whose ID might be in the NAND table but for which 
> it is preferable (or even required) to check by ONFI for one reason or 
> another. For instance, some ONFI chips might use odd-sized OOB that 
> isn't in the ID decoding algorithm.
>
This nand is 32Gb, but we can not parse it out from the id.
I ever want to add a new database which use the all the 8/6 bytes id as key.
It seems it's time to change it now.

Huang Shijie

> The current `||` check is, I think, designed to weed out old 
> small-page NAND only, which define both 'name' and 'pagesize' in the 
> table.
>
> So in short: the current code works as intended.
>
> Brian
>


[-- Attachment #2: h27ubg8t2atr.pdf --]
[-- Type: application/pdf, Size: 1211475 bytes --]

  reply	other threads:[~2012-02-16  3:12 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-15 10:33 [PATCH] mtd: fix the wrong check condition Huang Shijie
2012-02-15 10:33 ` Huang Shijie
2012-02-16  2:59 ` Brian Norris
2012-02-16  2:59   ` Brian Norris
2012-02-16  3:12   ` Huang Shijie [this message]
2012-02-16 11:04     ` Florian Fainelli
2012-02-16 11:04       ` Florian Fainelli
2012-02-17  3:07       ` Huang Shijie
2012-02-17  3:07         ` Huang Shijie
2012-02-17  8:50         ` Florian Fainelli
2012-02-17  8:50           ` Florian Fainelli
2012-02-18  5:43           ` Brian Norris
2012-02-18  5:43             ` Brian Norris
2012-02-16  3:15   ` Huang Shijie
2012-02-16  3:15     ` Huang Shijie
2012-02-16  8:32     ` Brian Norris
2012-02-16  8:32       ` Brian Norris

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=4F3C7433.5030306@freescale.com \
    --to=b32955@freescale.com \
    --cc=computersforpeace@gmail.com \
    --cc=ffainelli@freebox.fr \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.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 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.