Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755421AbeAHEHI (ORCPT + 1 other); Sun, 7 Jan 2018 23:07:08 -0500 Received: from gate2.alliedtelesis.co.nz ([202.36.163.20]:49850 "EHLO gate2.alliedtelesis.co.nz" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754987AbeAHEHH (ORCPT ); Sun, 7 Jan 2018 23:07:07 -0500 From: Chris Packham To: Ezequiel Garcia , Miquel RAYNAL CC: Ezequiel Garcia , Boris Brezillon , Richard Weinberger , David Woodhouse , Brian Norris , Marek Vasut , "Cyrille Pitchen" , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Kalyan Kinthada Subject: Re: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants Thread-Topic: [PATCHv4 1/1] mtd: nand: pxa3xx: Set FORCE_CSX bit to ARMADA370 variants Thread-Index: AQHTerIkP8EUaYVnQU2YsCVBtLeZYw== Date: Mon, 8 Jan 2018 04:06:59 +0000 Message-ID: <62666eec18c24419bcb9379f33776ba1@svr-chch-ex1.atlnz.lc> References: <20171221231904.21140-1-chris.packham@alliedtelesis.co.nz> <20171221231904.21140-2-chris.packham@alliedtelesis.co.nz> <20171222165308.10f2fe15@xps13> Accept-Language: en-NZ, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:df5:b000:22:3a2c:4aff:fe70:2b02] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Return-Path: On 08/01/18 11:35, Chris Packham wrote: > Hi Miquel, Ezequiel, > > On 23/12/17 05:56, Ezequiel Garcia wrote: >> On 22 December 2017 at 12:53, Miquel RAYNAL >> wrote: >>> Hello Chris, >>> >>> On Fri, 22 Dec 2017 12:19:04 +1300 >>> Chris Packham wrote: >>> >>>> From: Kalyan Kinthada >>>> >>>> The Armada-370 based SoCs support arbitration between the NAND Flash >>>> interface and NOR (i.e. devbus) on the same chip select. However there >>>> are two guidelines that must be followed to avoid data corruption in >>>> this scenario. >>> >>> Sorry to bother you again with that but, do you actually face any >>> issue/data corruption with this scenario? >>> >> >> Indeed. We need a description of a real world problem this patch is fixing. >> > > I totally agree. The Marvell FAE used words like "data corruption" hence > my re-newed interest in this. I had hoped these patches would pique the > interest of someone from Marvell's engineering team with some more info > on how the data corruption exhibits. > > I've been running some of the mtd-utils tests on my hardware and haven't > detected any failures yet. > > I think the key would be to be doing interleaved accesses between nand > and the parallel device. I've just kicked off something I think should > do this on my hardware but I'm unsure as to how long I should wait for > an issue to present itself. > > I'll leave it running for as long as I can today. If I find a failure > I'll report back otherwise we can leave this patch for the mailing list > archives waiting for an issue to be seen. > I've been running my test for several hours an no obvious problem has presented itself so I'm happy to leave it there until such time as a problem is observed or Marvell provide a reproduction.