Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753426AbbEHVnj (ORCPT ); Fri, 8 May 2015 17:43:39 -0400 Received: from a.ns.miles-group.at ([95.130.255.143]:65275 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753264AbbEHVni (ORCPT ); Fri, 8 May 2015 17:43:38 -0400 Message-ID: <554D2E05.8060806@nod.at> Date: Fri, 08 May 2015 23:43:33 +0200 From: Richard Weinberger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Brian Norris , Ben Shelton CC: punnaiah choudary kalluri , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , David Woodhouse , Punnaiah Choudary Kalluri , Boris Brezillon Subject: Re: [PATCH 1/3] mtd: nand: Add on-die ECC support References: <1427292151-3835-1-git-send-email-richard@nod.at> <1427292151-3835-2-git-send-email-richard@nod.at> <20150427213558.GA22780@bshelton-desktop> <553EB5E4.3050309@nod.at> <20150427232353.GD32500@ld-irv-0074> <20150428032213.GI19571@brian-ubuntu> <20150508212632.GA7167@bshelton-desktop> <20150508213947.GF32500@ld-irv-0074> In-Reply-To: <20150508213947.GF32500@ld-irv-0074> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2626 Lines: 61 Am 08.05.2015 um 23:39 schrieb Brian Norris: > On Fri, May 08, 2015 at 04:26:32PM -0500, Ben Shelton wrote: >> On 04/27, Brian Norris wrote: >>> On Tue, Apr 28, 2015 at 08:18:12AM +0530, punnaiah choudary kalluri wrote: >>>> On Tue, Apr 28, 2015 at 4:53 AM, Brian Norris >>>> wrote: >>>>> On Tue, Apr 28, 2015 at 12:19:16AM +0200, Richard Weinberger wrote: >>>>>> Oh, I thought every driver has to implement that function. ;-\ >>>>> >>>>> Nope. >>>>> >>>>>> But you're right there is a corner case. >>>>> >>>>> And it's not the only one! Right now, there's no guarantee even that >>>>> read_buf() returns raw data, unmodified by the SoC's controller. Plenty >>>>> of drivers actually have HW-enabled ECC turned on by default, and so >>>>> they override the chip->ecc.read_page() (and sometimes >>>>> chip->ecc.read_page_raw() functions, if we're lucky) with something >>>>> that pokes the appropriate hardware instead. I expect anything >>>>> comprehensive here is probably going to have to utilize >>>>> chip->ecc.read_page_raw(), at least if it's provided by the hardware >>>>> driver. >>>> >>>> Yes, overriding the chip->ecc.read_page_raw would solve this. >>> >>> I'm actually suggesting that (in this patch set, for on-die ECC >>> support), maybe we *shouldn't* override chip->ecc.read_page_raw() and >>> leave that to be defined by the driver, and then on-die ECC support >>> should be added in a way that just calls chip->ecc.read_page_raw(). This >>> should work for any driver that already properly supports the raw >>> callbacks. >>> >> >> Hi Richard et al, >> >> I'm guessing it's probably too late for the on-die ECC stuff to land in >> 4.2 at this point. > > Not technically. We've got several weeks (approx 5 to 6?) before 4.1 is > released. 4.2 material should be getting finalized by a week or so > before the merge window (i.e., 4 to 5 weeks from now). > >> Is there anything I can do to help this along >> (testing, etc.)? > > This is going to need to get rewritten. I'm not sure if Richard is going > to tackle this again, as he hasn't responded to the points I brought up. > (Note that Richard is not the first to have tried to implement this, > without initial success.) I'm definitely willing to take the challenge. But as I'm currently very busy with non-MTD stuff I had no time to address your comments. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/