From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail.free-electrons.com ([62.4.15.54]) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1eORA0-0006SD-Iw for linux-mtd@lists.infradead.org; Mon, 11 Dec 2017 16:42:35 +0000 Date: Mon, 11 Dec 2017 17:41:59 +0100 From: Miquel RAYNAL To: Ezequiel Garcia Cc: Sean =?UTF-8?B?Tnlla2rDpnI=?= , "linux-mtd@lists.infradead.org" , "Kasper Revsbech (KREV)" , Ezequiel Garcia Subject: Re: [BUG] pxa3xx: wait time out when scanning for bb Message-ID: <20171211174159.413b5377@xps13> In-Reply-To: References: <7df7abb5-e666-c999-e449-75762b551ea5@prevas.dk> <20171128140210.34215e19@xps13> <20171128143055.1ff22979@xps13> <20171210151734.7e1aac59@xps13> <20171211141307.6535523c@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 11 Dec 2017 13:08:23 -0300 Ezequiel Garcia wrote: > On 11 December 2017 at 10:13, Miquel RAYNAL > wrote: > > On Mon, 11 Dec 2017 09:30:53 -0300 > > Ezequiel Garcia wrote: > > =20 > >> On 10 December 2017 at 11:17, Miquel RAYNAL > >> wrote: =20 > >> > Hi Ezequiel, > >> > =20 > >> >> >> [ 2.296924] nand: device found, Manufacturer ID: 0x2c, > >> >> >> Chip ID: 0xda [ 2.303311] nand: Micron MT29F2G08ABAEAH4 > >> >> >> [ 2.307334] nand: 256 MiB, SLC, erase size: 128 KiB, page > >> >> >> size: 2048, OOB size: 64 > >> >> >> [ 2.314939] pxa3xx-nand f10d0000.flash: ECC strength 16, > >> >> >> ECC step size 2048 =20 > >> >> > > >> >> > In theory, Marvell NAND flash controller does support 16-bit > >> >> > strength per 512 bytes over 2048 bytes pages. However, this > >> >> > controller driver (pxa3xx_nand) does not. See [1] for the > >> >> > supported configurations. =20 > >> >> > >> >> Why do you say the driver does not support it? =20 > >> > > >> > My reading of the trace was incomplete as it is mentioned that > >> > the 16-bit correction applies on 2kiB chunks (a full page) while > >> > I was referring to 512 bytes chunks. > >> > > >> > Protecting 2kiB pages with BCH algorithm may prevent the flip of > >> > up to 16 bits per page, which may also be seen as 4 bits per 512 > >> > bytes. Asking for 16-bit strength for 512 bytes (configuration I > >> > was referring to) is supported by the controller but simply not > >> > implemented. > >> > > >> > However, below code setting up ecc->strength to 16 while > >> > ecc_stepsize is 512 is, IMHO, wrong. > >> > =20 > >> > >> If you feel there's anything wrong and worth changing in the > >> current driver, please submit a patch. =20 > > > > Somehow I did it last week, by sending the first version of a > > rework :)=20 >=20 > Sure, and I'm happy to see the rework. Thanks! >=20 > However, this driver will still be around, possibly for many years > given vendors using stable kernels. That's right. I won't hesitate to send patches for stable kernels. Cheers, Miqu=C3=A8l