From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Tue, 5 Nov 2013 10:31:56 -0800
From: Brian Norris <computersforpeace@gmail.com>
To: Ezequiel Garcia <ezequiel.garcia@free-electrons.com>
Subject: Re: [PATCH v3 14/28] mtd: nand: pxa3xx: Add driver-specific ECC
 BCH support
Message-ID: <20131105183156.GO20061@ld-irv-0074.broadcom.com>
References: <1383656135-8627-1-git-send-email-ezequiel.garcia@free-electrons.com>
 <1383656135-8627-15-git-send-email-ezequiel.garcia@free-electrons.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1383656135-8627-15-git-send-email-ezequiel.garcia@free-electrons.com>
Cc: Lior Amsalem <alior@marvell.com>,
 Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
 Jason Cooper <jason@lakedaemon.net>, Tawfik Bayouk <tawfik@marvell.com>,
 Daniel Mack <zonque@gmail.com>, Huang Shijie <b32955@freescale.com>,
 linux-mtd@lists.infradead.org,
 Gregory Clement <gregory.clement@free-electrons.com>, Willy Tarreau <w@1wt.eu>,
 linux-arm-kernel@lists.infradead.org
List-Id: Linux MTD discussion mailing list <linux-mtd.lists.infradead.org>
List-Unsubscribe: <http://lists.infradead.org/mailman/options/linux-mtd>,
 <mailto:linux-mtd-request@lists.infradead.org?subject=unsubscribe>
List-Archive: <http://lists.infradead.org/pipermail/linux-mtd/>
List-Post: <mailto:linux-mtd@lists.infradead.org>
List-Help: <mailto:linux-mtd-request@lists.infradead.org?subject=help>
List-Subscribe: <http://lists.infradead.org/mailman/listinfo/linux-mtd>,
 <mailto:linux-mtd-request@lists.infradead.org?subject=subscribe>

On Tue, Nov 05, 2013 at 09:55:21AM -0300, Ezequiel Garcia wrote:
> --- a/drivers/mtd/nand/pxa3xx_nand.c
> +++ b/drivers/mtd/nand/pxa3xx_nand.c
> @@ -1073,6 +1075,43 @@ static int pxa3xx_nand_sensing(struct pxa3xx_nand_info *info)
>  	return -ENODEV;
>  }
>  
> +static int pxa_ecc_init(struct pxa3xx_nand_info *info,
> +			struct nand_ecc_ctrl *ecc,
> +			int strength, int page_size)
> +{
> +	/*
> +	 * We don't use strength here as the PXA variant
> +	 * is used with non-ONFI compliant devices.

Hmm, rather than assuming you never get any relevant 'strength' info
from nand_base, could you check if it is zero and only ignore it if it
is zero? But if it is non-zero, you could at least use it to validate
the strength settings below.

At the same time, I would also caution against fragile ECC determination
methods that can indirectly cause regressions in the future, such as
with Huang's recent GPMI ECC layout regressions. Perhaps you'll want a
DT binding for the ECC strength to future proof this? (Not a
requirement; just a thought.)

> +	 */
> +	if (page_size == 2048) {
> +		ecc->mode = NAND_ECC_HW;
> +		ecc->size = 512;
> +		ecc->strength = 1;

I assume this is actually a 1-bit ECC, not just a dummy value? Note that
the ecc->strength and ecc->size fields are used by nand_base for some
bitflip calculations and are also exposed via sysfs.

> +
> +		info->spare_size = 40;
> +		info->ecc_size = 24;
> +		return 1;
> +
> +	} else if (page_size == 512) {
> +		ecc->mode = NAND_ECC_HW;
> +		ecc->size = 512;
> +		ecc->strength = 1;
> +
> +		info->spare_size = 8;
> +		info->ecc_size = 8;
> +		return 1;
> +	}
> +	return 0;
> +}
> +
> +static int armada370_ecc_init(struct pxa3xx_nand_info *info,
> +			      struct nand_ecc_ctrl *ecc,
> +			      int strength, int page_size)
> +{
> +	/* Unimplemented yet */
> +	return 0;
> +}
> +
>  static int pxa3xx_nand_scan(struct mtd_info *mtd)
>  {
>  	struct pxa3xx_nand_host *host = mtd->priv;

Brian