linux-kernel - RE: [PATCH v2 0/3] mtd: nand: OMAP: ELM error correction support for BCH ecc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <518397C60809E147AF5323E0420B992E3E9F0484@DBDE01.ent.ti.com>
Date:	Tue, 27 Nov 2012 09:07:00 +0000
From:	"Philip, Avinash" <avinashphilip@...com>
To:	"artem.bityutskiy@...ux.intel.com" <artem.bityutskiy@...ux.intel.com>,
	"ivan.djelic@...rot.com" <ivan.djelic@...rot.com>
CC:	"dwmw2@...radead.org" <dwmw2@...radead.org>,
	"Mohammed, Afzal" <afzal@...com>,
	"tony@...mide.com" <tony@...mide.com>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"rmk+kernel@....linux.org.uk" <rmk+kernel@....linux.org.uk>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	"linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"Nori, Sekhar" <nsekhar@...com>,
	"Hebbar, Gururaja" <gururaja.hebbar@...com>
Subject: RE: [PATCH v2 0/3] mtd: nand: OMAP: ELM error correction support
 for BCH ecc

On Thu, Nov 22, 2012 at 20:06:41, Philip, Avinash wrote:
> On Thu, Nov 22, 2012 at 16:13:52, Artem Bityutskiy wrote:
> > On Wed, 2012-11-21 at 07:01 +0000, Philip, Avinash wrote:
> > > > I am not sure how this dependency has to be handled for this series,
> > > > let me know whether you still want it to be made over l2-mtd?
> > > 
> > > Artem,
> > > 
> > > Is it possible for you to give ack for these patches so that these patches
> > > can go in Tony's tree where Omap-gpmc changes are present?
> > 
> > I would prefer if people like Ivan could take a look at this first.
> 
> Ok.

Ivan/Artem,

Any comments in this patch series?
I hope ELM support can get in 3.8.

> 
> > 
> > Also, I am not sure this is a good idea. Or at least we should agree on
> > some common strategy for bit-flips in the erased areas:
> > 
> > "+ * 1. If page is erased, check with standard ecc vector (ecc vector
> > + * for erased page to find any bit flip). If check fails, bit flip
> > + * is present in erased page. Count the bit flips in erased page and
> > + * if it falls under correctable level, report page with 0xFF and
> > + * update the correctable bit information."
> > 
> 
> Idea here is to make faster scanning of erased page without bit flips.
> For omap nand driver ecc reported by hardware is non-zero and non 0xff.
> So comparing with the standard vector for erased page and skipping error
> correction for erased page without bit flips.
> 
> Strategy for bit flips in erased page bit flips, can be
> 1. Don't make as erased page and mark it as bad.
> 2. Report the erased page with correctable bit flip if it falls under
>    correctable level. Report the page with erased page with correctable
>    errors.
> Is the concern is here with erased page with correctable error?
> I think as error is under correctable level, we still can use the page.
> May be we can think of limiting the check to half of correctable level?
> 
> I would go for option 2, see discussion [1].
>  
> Option 2 adopted in this patch series.
> 
> > Basically, you are working-around JFFS2 limitations.
> > 
> > Do you suggest we do this in all the drivers?
> 
> I am not sure how the situation handled in other drivers.
> This depends on the platforms. This method can be adopted for
> platforms where ecc reported non-zero & non 0xff with erased page.

Any comments?

Thanks
Avinash

> 
> > 
> > If we want to do this, may be we better do this in higher level, common
> > to all drivers?
> > 
> 
> I doubt how we handle in higher level with existing MTD setup.
> Issues I am seeing on implementing at higher layer is
> 1. Calculation of standard ecc vector for erased page.
> 2. Skipping ecc error correction, as currently error correction in
>    .read_page()
>  Can be handled by adding common .read_page() method on certain flag,
>  populated for platform specific.
> 
> 1. http://lists.infradead.org/pipermail/linux-mtd/2011-April/034604.html
> 
> Thanks
> Avinash
> 
> > -- 
> > Best Regards,
> > Artem Bityutskiy
> > 
> 
>