From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755196AbcAWW4y (ORCPT ); Sat, 23 Jan 2016 17:56:54 -0500 Received: from mail-pf0-f180.google.com ([209.85.192.180]:36752 "EHLO mail-pf0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754760AbcAWW4v (ORCPT ); Sat, 23 Jan 2016 17:56:51 -0500 Date: Sat, 23 Jan 2016 14:56:46 -0800 From: Brian Norris To: Han Xu Cc: shijie.huang@arm.com, dwmw2@infradead.org, boris.brezillon@free-electrons.com, fabio.estevam@freescale.com, hofrat@osadl.org, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, vinod.koul@intel.com, dan.j.williams@intel.com, dmaengine@vger.kernel.org Subject: Re: [PATCH v8 4/7] mtd: nand: gpmi: may use minimum required ecc for 744 oobsize NAND Message-ID: <20160123225646.GH24744@localhost> References: <1449096466-18064-1-git-send-email-b45815@freescale.com> <1449096466-18064-5-git-send-email-b45815@freescale.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1449096466-18064-5-git-send-email-b45815@freescale.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Dec 02, 2015 at 04:47:43PM -0600, Han Xu wrote: > By default NAND driver will choose the highest ecc strength that oob > could contain, in this case, for some 8K+744 NAND flash, the ecc > strength will be up to 52bit, which beyonds the i.MX6QDL BCH capability > (40bit). > > This patch allows the NAND driver try to use minimum required ecc > strength if it failed to use the highest ecc, even without explicitly > claiming "fsl,use-minimum-ecc" in dts. > > Signed-off-by: Han Xu Pushed this one to l2-mtd.git/next too. Would it help to implement support for the "nand-ecc-step-size" and "nand-ecc-strength" properties sometime? That would be more maintainable, as it's more specific. What if you need a little stronger than the minimum ECC? You also are relying on not changing the default behavior of the driver, for the "legacy" ECC calculation still. That ties your hands a bit. Brian