From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Mon, 15 Aug 2011 18:57:34 +0200
From: Ivan Djelic <ivan.djelic@parrot.com>
To: Artem Bityutskiy <dedekind1@gmail.com>
Subject: Re: GPMI-NAND Status?
Message-ID: <20110815165734.GA18979@parrot.com>
References: <20110805135133.GA26981@pengutronix.de>
	<20110814081139.GD17063@parrot.com>
	<1313425340.8691.34.camel@sauron>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1313425340.8691.34.camel@sauron>
Cc: Koen Beel <koen.beel.barco@gmail.com>, Wolfram Sang <w.sang@pengutronix.de>,
	Huang Shijie <b32955@freescale.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Shawn Guo <shawn.guo@linaro.org>, "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Lothar =?utf-8?Q?Wa=C3=9Fmann?= <LW@KARO-electronics.de>
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 Mon, Aug 15, 2011 at 05:22:13PM +0100, Artem Bityutskiy wrote:
> On Sun, 2011-08-14 at 10:11 +0200, Ivan Djelic wrote:
> > On Fri, Aug 05, 2011 at 02:51:33PM +0100, Wolfram Sang wrote:
> > (...)
> > > 
> > > problem overwriting all-0xff data in NAND [2]
> > > =============================================
> > > 
> > > Although it occured only when writing JFFS2 images so far, this is a generic
> > > issue and needs to be fixed, right?
> > > 
> > > 
> > (...)
> > > [2] http://lists.infradead.org/pipermail/linux-mtd/2011-July/037104.html
> > 
> > As explained in the thread linked above, this issue should be fixed in your
> > flashing tool, _not_ in your driver. The nand device you are using does not
> > support programming pages multiple times in a row; pretending it does in the
> > special all-0xff case is inefficient (you need to detect all-0xff data) and
> > unnecessary (just do not program blank pages !).
> 
> Hmm, isn't it also buggy because if my precious data contains 2KiB of
> 0xFFs (aligned to 2KiB boundary) then I will have no ECC protection for
> this page? Or I miss something?

Ouch, yes you are correct, very good point which I missed :)

Ivan