All of lore.kernel.org
 help / color / mirror / Atom feed
From: Brian Norris <computersforpeace@gmail.com>
To: Huang Shijie <b32955@freescale.com>
Cc: dedekind1@gmail.com, dwmw2@infradead.org, akinobu.mita@gmail.com,
	matthieu.castet@parrot.com, linux-mtd@lists.infradead.org,
	Huang Shijie <shijie8@gmail.com>
Subject: Re: [PATCH v2 1/9] mtd: nand: rename the cellinfo to bits_per_cell
Date: Fri, 23 Aug 2013 22:49:13 -0700	[thread overview]
Message-ID: <20130824054913.GA32074@brian-ubuntu> (raw)
In-Reply-To: <1376879478-22128-2-git-send-email-b32955@freescale.com>

On Mon, Aug 19, 2013 at 10:31:10AM +0800, Huang Shijie wrote:
> From: Huang Shijie <shijie8@gmail.com>
> 
> The @cellinfo fields contains unused information, such as write caching,
> internal chip numbering, etc. But we only use it to check the SLC or MLC.
> 
> This patch tries to make it more clear and simple, renames the @cellinfo
> to @bits_per_cell.
> 
> In order to avoiding the bisect issue, this patch also does the following
> changes:
>   (0) add a macro NAND_CI_CELLTYPE_SHIFT to avoid the hardcode.
> 
>   (1) add a helper to check the SLC : nand_is_slc()
> 
>   (2) add a helper to parse out the cell type : nand_get_bits_per_cell()
> 
>   (3) parse out the cell type for legacy nand chips and extended-ID
>       chips, and the full-id nand chips.
> 
> Signed-off-by: Huang Shijie <shijie8@gmail.com>
> Signed-off-by: Huang Shijie <b32955@freescale.com>

Did you really want two signed-off-by lines? :)

> ---
>  drivers/mtd/nand/denali.c    |    2 +-
>  drivers/mtd/nand/nand_base.c |   28 ++++++++++++++++++----------
>  include/linux/mtd/nand.h     |   14 ++++++++++++--
>  3 files changed, 31 insertions(+), 13 deletions(-)

[...]

> diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
> index 7ed4841..567cbcd 100644
> --- a/drivers/mtd/nand/nand_base.c
> +++ b/drivers/mtd/nand/nand_base.c
> @@ -3077,6 +3077,15 @@ static int nand_id_len(u8 *id_data, int arrlen)
>  	return arrlen;
>  }
>  
> +static int nand_get_bits_per_cell(u8 data)

Maybe make the parameter name 'cellinfo' to make it clearer? And maybe
a short comment to say that it extracts this information from the 3rd
byte of the extended ID de-facto standard?

> +{
> +	int bits;
> +
> +	bits = data & NAND_CI_CELLTYPE_MSK;
> +	bits >>= NAND_CI_CELLTYPE_SHIFT;
> +	return bits + 1;
> +}
> +
>  /*
>   * Many new NAND share similar device ID codes, which represent the size of the
>   * chip. The rest of the parameters must be decoded according to generic or

[...]

> @@ -3224,6 +3232,7 @@ static void nand_decode_id(struct mtd_info *mtd, struct nand_chip *chip,
>  	mtd->oobsize = mtd->writesize / 32;
>  	*busw = type->options & NAND_BUSWIDTH_16;
>  
> +	chip->bits_per_cell = nand_get_bits_per_cell(id_data[2]);

This is wrong. The NAND covered by nand_decode_id() do not have an
extended ID, so the third ID byte is not meaningful. But all of these
should be SLC, so just:

	/* All legacy ID NAND are small-page, SLC */
	chip->bits_per_cell = 1;

This also highlights the problem I was alluding to if we were to try to
maintain the whole cellinfo field for all NAND; we never guaranteed that
the other bitfields of cellinfo were consistent for extended ID vs.
legacy ID NAND. For legacy ID NAND, cellinfo was always 0, and I don't
know off the top of my head whether 0 makes sense for all the other
bitfields within cellinfo.

>  	/*
>  	 * Check for Spansion/AMD ID + repeating 5th, 6th byte since
>  	 * some Spansion chips have erasesize that conflicts with size

[...]

The rest of the patch looks good. Thanks for doing this!

Brian

  reply	other threads:[~2013-08-24  5:49 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-19  2:31 [PATCH v2 0/9] About the SLC/MLC Huang Shijie
2013-08-19  2:31 ` [PATCH v2 1/9] mtd: nand: rename the cellinfo to bits_per_cell Huang Shijie
2013-08-24  5:49   ` Brian Norris [this message]
2013-08-25  3:52     ` Huang Shijie
2013-08-19  2:31 ` [PATCH v2 2/9] mtd: set the cell information for ONFI nand Huang Shijie
2013-08-19  2:31 ` [PATCH v2 3/9] mtd: print out the cell information for nand chip Huang Shijie
2013-08-24  5:58   ` Brian Norris
2013-08-24 21:02     ` Ezequiel Garcia
2013-08-25 16:04       ` Huang Shijie
2013-08-19  2:31 ` [PATCH v2 4/9] mtd: gpmi: rewrite the gpmi_ecc_write_oob() to support the jffs2 Huang Shijie
2013-08-24  6:19   ` Brian Norris
2013-08-24 19:18     ` Huang Shijie
2013-08-24  7:17       ` Brian Norris
2013-08-19  2:31 ` [PATCH v2 5/9] mtd: add more comment for MTD_NANDFLASH/MTD_MLCNANDFLASH Huang Shijie
2013-08-19  2:31 ` [PATCH v2 6/9] mtd: fix the wrong mtd->type for nand chip Huang Shijie
2013-08-19  2:31 ` [PATCH v2 7/9] jffs2: init the ret with -EINVAL Huang Shijie
2013-08-24  6:37   ` Brian Norris
2013-08-25  4:00     ` Huang Shijie
2013-08-19  2:31 ` [PATCH v2 8/9] mtd: add MTD_MLCNANDFLASH case for mtd_type_show() Huang Shijie
2013-08-19  2:31 ` [PATCH v2 9/9] mtd: add a helper to detect the nand type Huang Shijie
2013-08-19  8:59 ` [PATCH v2 append] mtd: mtd-abi: " Huang Shijie
2013-08-20  5:32   ` [PATCH append fix] " 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=20130824054913.GA32074@brian-ubuntu \
    --to=computersforpeace@gmail.com \
    --cc=akinobu.mita@gmail.com \
    --cc=b32955@freescale.com \
    --cc=dedekind1@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=matthieu.castet@parrot.com \
    --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 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.