From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Thu, 14 Jan 2016 02:41:39 +0100
Subject: [U-Boot] [PATCH 07/10] mtd: nand: s3c: Add missing correction
	and select_chip functions
In-Reply-To: <1414536308.23458.116.camel@snotra.buserror.net>
References: <1413045778-5690-1-git-send-email-marex@denx.de>
 <1413045778-5690-7-git-send-email-marex@denx.de>
 <1414536308.23458.116.camel@snotra.buserror.net>
Message-ID: <201601140241.39961.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Tuesday, October 28, 2014 at 11:45:08 PM, Scott Wood wrote:
> On Sat, 2014-10-11 at 18:42 +0200, Marek Vasut wrote:
> > +	/* sometimes people do not think about using the ECC, so check
> > +	 * to see if we have an 0xff,0xff,0xff read ECC and then ignore
> > +	 * the error, on the assumption that this is an un-eccd page.
> > +	 */
> 
> Eww.  I suppose I won't argue too loudly if Linux is doing the same
> thing, but what if it's a corrupted blank page, or the ECC just happened
> to turn out as all 0xff?  It seems like there should at least be a
> warning the first time this happens, and ideally it should be
> configurable.
> 
> > +	if (read_ecc[0] == 0xff && read_ecc[1] == 0xff && read_ecc[2] == 0xff
> > +	    /*&& info->platform->ignore_unset_ecc*/)
> > 
> >  		return 0;
> 
> So it looks like it is configurable in Linux, but you've commented it
> out here.
> 
> > @@ -221,6 +298,8 @@ int board_nand_init(struct nand_chip *nand)
> > 
> >  	nand->dev_ready = s3c24x0_dev_ready;
> > 
> > +	nand->chip_delay = 50;
> 
> I'm not sure how this is related to the changes described in the
> changelog...

Can you collect the MTD patches which are applicable at least and drop this one?

Best regards,
Marek Vasut