From: Vikram Narayanan <vikram186@gmail.com>
To: Huang Shijie <b32955@freescale.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: [PATCH v5 06/11] mtd: get the ECC info from the Extended Parameter Page
Date: Wed, 15 May 2013 22:27:51 +0530 [thread overview]
Message-ID: <5193BE8F.6010807@gmail.com> (raw)
In-Reply-To: <1368607232-2210-7-git-send-email-b32955@freescale.com>
On 5/15/2013 2:10 PM, Huang Shijie wrote:
> Since the ONFI 2.1, the onfi spec adds the Extended Parameter Page
> to store the ECC info.
>
> The onfi spec tells us that if the nand chip's recommended ECC codeword
> size is not 512 bytes, then the @ecc_bits is 0xff. The host _SHOULD_ then
Section 3.4.2 also says,
"If a value of 0 is reported then this ECC Information Block is invalid
and should not be used".
Is this taken care anywhere?
> read the Extended ECC information that is part of the extended parameter
> page to retrieve the ECC requirements for this device.
>
> This patch implement the reading of the Extended Parameter Page, and parses
> the sections for ECC type, and get the ECC info from the ECC section.
>
> Tested this patch with Micron MT29F64G08CBABAWP.
>
> Acked-by: Pekon Gupta <pekon@ti.com>
> Signed-off-by: Huang Shijie <b32955@freescale.com>
> ---
> drivers/mtd/nand/nand_base.c | 77 ++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 77 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 15630ef..e98ea69 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -2835,6 +2835,68 @@ static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
> return crc;
> }
>
> +/* Parse the Extended Parameter Page. */
> +static int nand_flash_detect_ext_param_page(struct mtd_info *mtd,
> + struct nand_chip *chip, struct nand_onfi_params *p)
> +{
> + struct onfi_ext_param_page *ep;
> + struct onfi_ext_section *s;
> + struct onfi_ext_ecc_info *ecc;
> + uint8_t *cursor;
> + int len;
> + int ret;
> + int i;
> +
> + len = le16_to_cpu(p->ext_param_page_length) * 16;
> + ep = kmalloc(len, GFP_KERNEL);
> + if (!ep) {
> + ret = -ENOMEM;
> + goto ext_out;
Just return -ENOMEM.
Why do you free the memory when it is not allocated? (Though it doesn't
cause any harm)
> + }
> +
> + /* Send our own NAND_CMD_PARAM. */
> + chip->cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
> +
> + /* Use the Change Read Column command to skip the ONFI param pages. */
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
> + sizeof(*p) * p->num_of_param_pages , -1);
> +
> + /* Read out the Extended Parameter Page. */
> + chip->read_buf(mtd, (uint8_t *)ep, len);
> + if ((onfi_crc16(ONFI_CRC_BASE, ((uint8_t *)ep) + 2, len - 2)
> + != le16_to_cpu(ep->crc)) || strncmp(ep->sig, "EPPS", 4)) {
> + pr_debug("fail in the CRC.\n");
> + ret = -EINVAL;
> + goto ext_out;
> + }
> +
> + /* find the ECC section. */
> + cursor = (uint8_t *)(ep + 1);
> + for (i = 0; i < ONFI_EXT_SECTION_MAX; i++) {
> + s = ep->sections + i;
> + if (s->type == ONFI_SECTION_TYPE_2)
> + break;
> + cursor += s->length * 16;
> + }
> + if (i == ONFI_EXT_SECTION_MAX) {
> + pr_debug("We can not find the ECC section.\n");
> + ret = -EINVAL;
> + goto ext_out;
> + }
> +
> + /* get the info we want. */
> + ecc = (struct onfi_ext_ecc_info *)cursor;
> + chip->ecc_strength = ecc->ecc_bits;
> + chip->ecc_step = 1 << ecc->codeword_size;
> +
> + pr_info("ONFI extended param page detected.\n");
> + return 0;
> +
> +ext_out:
> + kfree(ep);
> + return ret;
> +}
> +
~Vikram
next prev parent reply other threads:[~2013-05-15 16:58 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-15 8:40 [PATCH v5 00/11] mtd: add datasheet's ECC information to nand_chip{} Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 01/11] " Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 12:11 ` Artem Bityutskiy
2013-05-15 12:11 ` Artem Bityutskiy
2013-05-16 2:16 ` Huang Shijie
2013-05-16 2:16 ` Huang Shijie
2013-05-16 7:14 ` Artem Bityutskiy
2013-05-16 7:14 ` Artem Bityutskiy
2013-05-16 8:06 ` Huang Shijie
2013-05-16 8:06 ` Huang Shijie
2013-05-16 9:36 ` Artem Bityutskiy
2013-05-16 9:36 ` Artem Bityutskiy
2013-05-16 10:46 ` Huang Shijie
2013-05-16 10:46 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 02/11] mtd: increase max OOB size to 744 Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 12:12 ` Artem Bityutskiy
2013-05-15 12:12 ` Artem Bityutskiy
2013-05-15 8:40 ` [PATCH v5 03/11] mtd: get the ECC info from the parameter page for ONFI nand Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 17:04 ` Vikram Narayanan
2013-05-16 2:21 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 04/11] mtd: add data structures for Extended Parameter Page Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 05/11] mtd: add a helper to get the supported features for ONFI nand Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 06/11] mtd: get the ECC info from the Extended Parameter Page Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 16:57 ` Vikram Narayanan [this message]
2013-05-16 2:37 ` Huang Shijie
2013-05-16 4:42 ` [PATCH v5 fix] " Huang Shijie
2013-05-16 4:42 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 07/11] mtd: replace the hardcode with the onfi_feature() Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 08/11] mtd: add ECC info for nand_flash_dev{} Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 8:40 ` [PATCH v5 09/11] mtd: parse out the ECC info for the full-id nand chips Huang Shijie
2013-05-15 8:40 ` Huang Shijie
2013-05-15 16:54 ` Vikram Narayanan
2013-05-16 2:40 ` Huang Shijie
2013-05-15 8:54 ` [PATCH v5 10/11] mtd: add the ecc info for some " Huang Shijie
2013-05-15 8:54 ` Huang Shijie
2013-05-15 8:54 ` [PATCH v5 11/11] mtd: gpmi: set the BCH's geometry with the ecc info Huang Shijie
2013-05-15 8:54 ` Huang Shijie
2013-05-15 16:31 ` Vikram Narayanan
2013-05-16 2:46 ` Huang Shijie
2013-05-16 4:49 ` [PATCH v5 fix] " Huang Shijie
2013-05-16 4:49 ` Huang Shijie
2013-05-15 10:05 ` [PATCH v5 00/11] mtd: add datasheet's ECC information to nand_chip{} Artem Bityutskiy
2013-05-15 10:05 ` Artem Bityutskiy
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=5193BE8F.6010807@gmail.com \
--to=vikram186@gmail.com \
--cc=b32955@freescale.com \
--cc=linux-mtd@lists.infradead.org \
/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.