linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Huang Shijie <b32955@freescale.com>, vikram186@gmail.com
Cc: linux-mtd@lists.infradead.org, dwmw2@infradead.org,
	linux-kernel@vger.kernel.org, dedekind1@gmail.com
Subject: Re: [PATCH v6 05/10 fix] mtd: get the ECC info from the Extended Parameter Page
Date: Sun, 19 May 2013 23:05:57 -0700	[thread overview]
Message-ID: <5199BD45.5090100@gmail.com> (raw)
In-Reply-To: <1369015705-4720-1-git-send-email-b32955@freescale.com>

Hi Huang, Vikram,

On 05/19/2013 07:08 PM, Huang Shijie wrote:
...
> +	/*
> +	 * From section 5.7.2.2, we know that the Extened Param Page is valid
> +	 * when two or more bytes of the signatrue are valid.

s/signatrue/signature

> +	 * So we only check the first two bytes here.
> +	 */
> +	if (strncmp(ep->sig, "EP", 2)) {
> +		pr_debug("The signatrue is invalid.\n");

Ditto.

> +		goto ext_out;
> +	}

What's the reasoning about this whole "only check 2 bytes" thing? I 
understand that this is technically what spec *says* (although you're 
actually not checking the other 5 combinations that are valid: 'ExPx' 
'ExxS' 'xPPx' 'xPxS' 'xxPS'). But *why* does the spec say this? To 
tolerate errors or to tolerate changes in the spec (e.g., new types of 
parameter pages that say 'QPPS' [1], for instance)? The former doesn't 
really sound plausible, since if we're going to have 2 whole bytes of 
errors in the signature, then we really shouldn't trust the whole 
(extended) parameter page. And the latter doesn't really make sense to 
me; any future backwards-compatible modifications should just use the 
same signature string.

Anyway, my point is that there has to be some logic to strictly 
following the letter of the specification. Shortening the check to just 
the 2-byte "EP" string does not actually cover *exactly* what the spec 
might allow (e.g., it doesn't allow "QPPS" [1]). But it also doesn't 
make any sense why we want to check anything besides "EPPS". So my 
natural inclination is to be strict in what we accept (i.e., exactly the 
"EPPS" string) until we find a reason otherwise.

Or, if you're gonna pull the strict compliance card, check all 6 
combinations, not just 1 of them.

Brian

[1] This is a totally made-up example. I do not understand at all why 
ONFI would allow anything besides exactly "EPPS".

  reply	other threads:[~2013-05-20  6:07 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-17  3:17 [PATCH v6 00/10] mtd: add datasheet's ECC information to nand_chip{} Huang Shijie
2013-05-17  3:17 ` [PATCH v6 01/10] " Huang Shijie
2013-05-17  3:17 ` [PATCH v6 02/10] mtd: get the ECC info from the parameter page for ONFI nand Huang Shijie
2013-05-17  3:17 ` [PATCH v6 03/10] mtd: add data structures for Extended Parameter Page Huang Shijie
2013-05-17  3:17 ` [PATCH v6 04/10] mtd: add a helper to get the supported features for ONFI nand Huang Shijie
2013-05-17  3:17 ` [PATCH v6 05/10] mtd: get the ECC info from the Extended Parameter Page Huang Shijie
2013-05-17 17:36   ` Vikram Narayanan
2013-05-20  2:08     ` [PATCH v6 05/10 fix] " Huang Shijie
2013-05-20  6:05       ` Brian Norris [this message]
     [not found]         ` <5199C159.6020401@freescale.com>
     [not found]           ` <CAHwEkO2Wn_jLCS-4-1p6Mks-0q3Dy_kzR-j-xtX_oOAOive2VQ@mail.gmail.com>
2013-05-22  2:15             ` Huang Shijie
2013-05-22  2:28         ` [PATCH v6 05/10 fix2] " Huang Shijie
2013-05-17  3:17 ` [PATCH v6 06/10] mtd: replace the hardcode with the onfi_feature() Huang Shijie
2013-05-17  3:17 ` [PATCH v6 07/10] mtd: add ECC info for nand_flash_dev{} Huang Shijie
2013-05-17  3:17 ` [PATCH v6 08/10] mtd: parse out the ECC info for the full-id nand chips Huang Shijie
2013-05-17  3:17 ` [PATCH v6 09/10] mtd: add the ecc info for some " Huang Shijie
2013-05-17  3:17 ` [PATCH v6 10/10] mtd: gpmi: set the BCH's geometry with the ecc info Huang Shijie
2013-06-25 20:12 ` [PATCH v6 00/10] mtd: add datasheet's ECC information to nand_chip{} Brian Norris
2013-08-08  8:33   ` Huang Shijie
2013-08-08 23:06     ` Brian Norris
2013-08-09  3:58       ` Artem Bityutskiy
2013-08-09  6:00         ` Brian Norris
2013-08-09  7:23           ` Artem Bityutskiy
2013-08-09  7:28             ` Brian Norris
2013-07-05  4:00 ` 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=5199BD45.5090100@gmail.com \
    --to=computersforpeace@gmail.com \
    --cc=b32955@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=vikram186@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).