From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5B14BC10F1A for ; Tue, 7 May 2024 14:03:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=OW46u/MB29CSb8GM5hjVBcFEPqMdTdQWCFOSmCt7+gk=; b=swNXBzSU20TkMO QBKygSnC34nkojXCNLhDtVXvnl3/ZUFUNNZUhIl6CWxJmwi+1XzUUUMjbQOoj5P99L0Cd9LW6jJGM f8xMHQZK8XmXV1VBK3NSmV1WxjSMP/XmPW96Q+j+I6lHNA4qPrvUY9Yd7Fj1ZHRdo2vY3B9haIGdG 1O/2DRTvBTqcrE9F2MbULv6z0Cqdq21LXsXwJAhjgCFkHIUnvCkFIdyDhTOLSkOPvAS+Ukig3V2rs qUOhRxk5qM41hQ6PHwcejOFgq/Zd0dHayIoWQqEIQ/tn+yiJYfUtWlDIEaF8LfA3B9mWDK2q1GUZi +T4Pk7yAe3M7DdpIoRTA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1s4LPM-0000000BN0L-0fyz; Tue, 07 May 2024 14:03:04 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1s4LPJ-0000000BMyn-123j for linux-mtd@lists.infradead.org; Tue, 07 May 2024 14:03:03 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id 978B42000A; Tue, 7 May 2024 14:02:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1715090574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cKI7GlnVF7vzPp/kl1uAX4B6WlmM2PiXc58H6Tpvbjw=; b=E4r1i8bYOzJhf5Sasi5cIRU42VYipoxolzO9WnWIkyaJR83FxpDdM2jd+co9I8M1HD9rib 6WjRiX2Nbv847FQZAM9zLdi8EyReUAptAaShBzdXFSFcjkiNyblF9xpnalOPTQWRzjgOST RbgbhtQdK/2VClqmulKWBzLKeMj0H513kmUWkobSHmN2kgrXJdpDY/siWWyjbB0kJseovh XmJaqGv3LlrL9UdDXl9sUvYJgzFtZVCabkggrmC8rJlTm4/IgGo5WqT6KwDuMMaXog8kJb 81CrVn4HrgIEfz3Lz6Eko04UK2S8tINVRE5IoMRmqt9eNOuuJyVPp/0R0oBUVA== Date: Tue, 7 May 2024 16:02:51 +0200 From: Miquel Raynal To: Sascha Hauer Cc: Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] mtd: nand: mxc_nand: support software ECC Message-ID: <20240507160251.7f804eb7@xps-13> In-Reply-To: References: <20240417-mtd-nand-mxc-nand-exec-op-v1-0-d12564fe54e9@pengutronix.de> <20240417-mtd-nand-mxc-nand-exec-op-v1-3-d12564fe54e9@pengutronix.de> <20240506160508.6c60d50f@xps-13> <20240506175106.2ab7c844@xps-13> <20240507094538.745fb5a9@xps-13> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-GND-Sasl: miquel.raynal@bootlin.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240507_070301_853922_911CCA3A X-CRM114-Status: GOOD ( 64.82 ) X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" Errors-To: linux-mtd-bounces+linux-mtd=archiver.kernel.org@lists.infradead.org SGkgU2FzY2hhLAoKPiA+IE5vIG5lZWQsIEkgYmVsaWV2ZSB0aGUgb25seSByZWFzb24gZm9yIGlu dGVybGVhdmluZyBpcyB0aGF0IHlvdXIKPiA+IGhhcmR3YXJlIEVDQyBlbmdpbmUgd29ya3MgbGlr ZSB0aGF0ICh3cml0ZXMgdGhlIEVDQyBieXRlcyBzbGlnaHRseQo+ID4gYWZ0ZXIgZWFjaCBjaHVu ayBvZiBkYXRhKS4gU28gaWYgeW91IGRvbid0IHVzZSBvbi1ob3N0IGhhcmR3YXJlIEVDQywKPiA+ IHlvdSBkb24ndCBuZWVkIHRvIGRlYWwgd2l0aCB0aGlzIGRhdGEgbGF5b3V0LiAgCj4gCj4gUmln aHQsIEkgY291bGQgdXNlIGEgZGlmZmVyZW50IGxheW91dCBmb3Igc29mdHdhcmUgRUNDLiBVc2lu ZyB0aGUgc2FtZQo+IGxheW91dCBmb3IgYm90aCBoYXJkd2FyZSBhbmQgc29mdHdhcmUgRUNDIGlz IGp1c3QgcXVpdGUgY29udmVuaWVudCBhcwo+IHRoZSBzYW1lIG14Y19uYW5kX3JlYWRfcGFnZV9y YXcoKS9teGNfbmFuZF93cml0ZV9wYWdlX3JhdygpIGNvdWxkIGJlCj4gdXNlZCBmb3IgYm90aCBz b2Z0d2FyZSBhbmQgaGFyZHdhcmUgRUNDLgoKSSdtIG5vdCBzdXJlIEkgc2VlIHdoeSBpdCB3b3Vs ZCBiZSBtb3JlIGNvbnZlbmllbnQsIGFzIHlvdSBiYXNpY2FsbHkKZG9uJ3QgbmVlZCB0byBwcm92 aWRlIGFueXRoaW5nIGlmIHlvdSB1c2Ugc29mdHdhcmUgRUNDIGVuZ2luZXMgYmVzaWRlcwphIG1p bmltYWwgZXhlY19vcCgpIGltcGxlbWVudGF0aW9uLiBBbnl3YXksIHRoYXQncyBjbGVhcmx5IG5v dCB0aGUgZ29vZAphcHByb2FjaCBmb3Igc29mdHdhcmUgRUNDOiB0aGUgZW5naW5lIGRlY2lkZXMg d2hlcmUgaXQgd2FudHMgdG8gcHV0IHRoZQpkYXRhLCB0aGVyZSBpcyBqdXN0IG5vIHJlYXNvbiB0 byBjb21wbGV4aWZ5IHRoZSBzb2Z0d2FyZSBsYXlvdXQgKHdoaWNoCmlzIGZyZWUgZnJvbSBhbnkg Y29uc3RyYWludHMpLgoKPiBBbm90aGVyIHRoaW5nIHRoYXQgbWlnaHQgYmUgd29ydGggY29uc2lk ZXJpbmcgaXMgdGhhdCBpZiB3ZSB1c2UKPiBkaWZmZXJlbnQgZnVuY3Rpb25zIGZvciByYXcgcmVh ZC93cml0ZSBwYWdlIGlzIHRoYXQgd2Ugd291bGQgZ2V0Cj4gZGlmZmVyZW50IHZpZXdzIG9uIHRo ZSBzYW1lIHJhdyBwYWdlIGRhdGEgaWYgd2Ugc3dpdGNoIGZyb20gc29mdHdhcmUgdG8KPiBoYXJk d2FyZSBFQ0Mgb3IgdGhlIG90aGVyIHdheSByb3VuZCB3aGljaCBtaWdodCBiZSBjb25mdXNpbmcu CgpEb24ndCB3b3JyeSBhYm91dCB0aGF0OiBpdCdzIGltcG9zc2libGUgdG8gbWFuYWdlLiBEYXRh IGxheW91dCBtaWdodCBiZQpkaWZmZXJlbnQgb2YgY291cnNlLCBidXQgbW9zdCBpbXBvcnRhbnRs eSBvbmNlIHlvdSd2ZSBjaG9zZW4gYW4gRUNDCmNvbmZpZ3VyYXRpb24sIGFueSBhY2Nlc3Mgd2l0 aCBhbm90aGVyIGNvbmZpZ3VyYXRpb24gd2lsbCBzaW1wbHkgZmFpbC4KQW5kIEknbSBub3QganVz dCB0YWxraW5nIGFib3V0IHRoZSBFQ0Mvc3RlcCBzaXplIHBhcmFtZXRlcnMsIGVhY2gKZW5naW5l IGhhcyBpdCdzIG93biBiYXNlIHBvbHlub21pYWwgb24gd2hpY2ggaXQgYmFzZXMgYWxsIGl0cyBp bnRlcm5hbApjYWxjdWxhdGlvbnMsIGFuZCBiZXNpZGVzIHRyeWluZyB2ZXJ5IGhhcmQgdG8gbWlt aWMgeW91ciBoYXJkd2FyZQplbmdpbmUgaW4gc29mdHdhcmUgZm9yIHNvbWUgdmVyeSBnb29kIHJl YXNvbiwgeW91J2xsIG5ldmVyIHdhbnQgdG8gZG8KdGhhdC4gRXNwZWNpYWxseSBzaW5jZSB0aGUg dmVyeSBmaXJzdCByZWFzb24gd2h5IHlvdSB3YW50IHNvZnR3YXJlCnN1cHBvcnQgaXMgdXN1YWxs eSB0byBnbyBiZXlvbmQgeW91ciBoYXJkd2FyZSBlbmdpbmUgY2FwYWJpbGl0aWVzIGluCnRlcm1z IG9mIHN0cmVuZ3RoLgoKSGVyZSBpcyBhIGJsb2cgcG9zdCBhYm91dCBzdWNoIHNpdHVhdGlvbiwg aWYgZGVlbWVkIHVzZWZ1bDoKaHR0cHM6Ly9ib290bGluLmNvbS9ibG9nL3N1cHBvcnRpbmctYS1t aXNiZWhhdmluZy1uYW5kLWVjYy1lbmdpbmUvCgo+ID4gPiBUaGlzIHdvcmtzIGZpbmUgY3VycmVu dGx5LCBidXQgbWVhbnMgdGhhdCBOQU5EX0NNRF9STkRPVVQgY2FuJ3QgYmUgdXNlZC4KPiA+ID4g VXNpbmcgTkFORF9DTURfUk5ET1VUIHRvIHBvc2l0aW9uIHRoZSBjdXJzb3IgYXQgb2Zmc2V0IDUx MmIgZm9yIGV4YW1wbGUKPiA+ID4gZG9lc24ndCBnaXZlIHlvdSB0aGUgc2Vjb25kIHN1YnBhZ2Us IGJ1dCBpbnN0ZWFkIG9vYjAuIFBvc2l0aW9uaW5nIHRoZQo+ID4gPiBjdXJzb3IgYXQgb2Zmc2V0 IDIwNDggZG9lc24ndCBnaXZlIHlvdSB0aGUgc3RhcnQgb2YgT09CLCBidXQgc29tZQo+ID4gPiBw b3NpdGlvbiBpbiB0aGUgbWlkZGxlIG9mIGRhdGEzLgo+ID4gPiAKPiA+ID4gT2ssIE5BTkRfQ01E X1JORE9VVCBjYW4ndCBiZSB1c2VkIGZvciBoYXJkd2FyZSBFQ0MgYW5kIHRoZXJlJ3Mgbm8gd2F5 Cj4gPiA+IGFyb3VuZCBpdC4gRm9yIHNvZnR3YXJlIEVDQyB3ZSBjb3VsZCBjaGFuZ2UgdGhlIG9y Z2FuaXNhdGlvbiBpbiB0aGUgY2hpcAo+ID4gPiB0byBiZSBbMjA0OGIgZGF0YV1bNjRiIG9vYl0u IFdpdGggdGhhdCBOQU5EX0NNRF9STkRPVVQgdGhlbiBjb3VsZCBiZQo+ID4gPiB1c2VkIHdpdGgg c29mdHdhcmUgRUNDLgo+ID4gPiAKPiA+ID4gWW91IHNheSB0aGF0IE5BTkRfQ01EX1JORE9VVCBp cyBhIGJhc2ljIGNvbW1hbmQgdGhhdCBpcyBzdXBwb3J0ZWQgYnkgYWxsCj4gPiA+IGNvbnRyb2xs ZXJzLCBhbmQgeWVzLCBpdCBpcyBhbHNvIHN1cHBvcnRlZCB3aXRoIHRoZSBteGNfbmFuZCBjb250 cm9sbGVyLgo+ID4gPiBZb3UganVzdCBjYW4ndCBjb250cm9sIGhvdyBtYW55IGJ5dGVzIGFyZSB0 cmFuc2ZlcnJlZCBiZXR3ZWVuIHRoZSBOQU5ECj4gPiA+IGNoaXAgYW5kIHRoZSBjb250cm9sbGVy LiBXaGVuIHVzaW5nIE5BTkRfQ01EX1JORE9VVCB0byByZWFkIGEgZmV3IGJ5dGVzCj4gPiA+IGF0 IGEgY2VydGFpbiBwYWdlIG9mZnNldCB3ZSdsbCBlbmQgdXAgcmVhZGluZyA1MTIgYnl0ZXMgZGlz Y2FyZGluZyBtb3N0Cj4gPiA+IG9mIGl0LiBGb3IgdGhlIG5leHQgRUNDIGJsb2NrIHdlIHdvdWxk IG1vdmUgdGhlIGN1cnNvciBmb3J3YXJkIHVzaW5nCj4gPiA+IGFub3RoZXIgTkFORF9DTURfUk5E T1VUIGNvbW1hbmQsIGFnYWluIHJlYWQgNTEyIGJ5dGVzIGFuZCBkaXNjYXJkIG1vc3QKPiA+ID4g aXQgKGFsdG91Z2ggdGhlIGRlc2lyZWQgZGF0YSB3b3VsZCBoYXZlIGJlZW4gaW4gdGhlIGZpcnN0 IHJlYWQgYWxyZWFkeSkuICAKPiA+IAo+ID4gSSdtIG5vdCBzdXJlIHRoZSBjb250cm9sbGVyIGxp bWl0YXRpb25zIGFyZSBzbyBiYWQgaW4gdGhpcyBjYXNlLiBUaGUKPiA+IGNvcmUgaGVscGVycyAo dXNpbmcgdGhlIHNhbWUgZXhhbXBsZSkgd2lsbCBhc2sgZm9yOgo+ID4gLSA1MTJiIGF0IG9mZnNl dCAwCj4gPiAtIDUxMmIgYXQgb2Zmc2V0IDUxMi4uLgo+ID4gLSBhbmQgZmluYWxseSA2NGIgYXQg b2Zmc2V0IDIwNDguCj4gPiBJbiBwcmFjdGljZSBpdCBkb2VzIG5vdCBsb29rIGxpa2UgYSBodWdl IGRyYXdiYWNrPyBJIGRvbid0IHVuZGVyc3RhbmQKPiA+IGluIHdoaWNoIGNhc2Ugc28gbXVjaCBk YXRhIHdvdWxkIGJlIHJlYWQgYW5kIHRoZW4gZGlzY2FyZGVkPyAgCj4gCj4gWWVzLCB5b3UncmUg cmlnaHQuIEkgbWlzcmVhZCB0aGUgY29kZSBhbmQgdGhvdWdodCB0aGUgY29yZSB3b3VsZCByZWFk Cj4gdGhlIEVDQyBzZXBhcmF0ZWx5IGZvciBlYWNoIHN1YnBhZ2UuIEluIGZhY3QgaXQgZG9lc24n dCBkbyBzbywgdGhlIEVDQwo+IGlzIGFsd2F5cyByZWFkIGluIG9uZSBnbyBldmVuIGZvciBtdWx0 aXBsZSBzdWJwYWdlcy4KCiJpbnRlcmxlYXZlZCIgbGF5b3V0cyBhY3R1YWxseSBmb3JjZSB1cyB0 byBwZXJmb3JtIHNvIG11Y2gKc3ViLXJlYWRpbmdzLCB0aGF0J3MgcHJvYmFibHkgb25lIHJlYXNv biB3aHkgdGhlcmUgaXMgbm8gcmVhc29uIHRvIHRyeQp1c2luZyBhbiBpbnRlcmxlYXZlZCBsYXlv dXQgd2l0aCBzb2Z0d2FyZSBFQ0MgZW5naW5lcy4KCj4gPiA+IFNvIEkgdGhpbmsgTkFORF9DTURf Uk5ET1VUIHNob3VsZCByZWFsbHkgYmUgYXZvaWRlZCBmb3IgdGhpcyBjb250cm9sbGVyLAo+ID4g PiBldmVudGhvdWdoIHdlIG1pZ2h0IGJlIGFibGUgdG8gc3VwcG9ydCBpdC4gIAo+ID4gCj4gPiBJ IGFsc28gbWVudGlvbmVkIHRoZSBtb25vbGl0aGljIGFjY2Vzc29ycyB3aGljaCB0cnkgdG8gYXZv aWQgdGhlc2UKPiA+IHJhbmRvbSBjb2x1bW4gY2hhbmdlcy4gWW91IHByb2JhYmx5IHdhbnQgdG8g Y2hlY2sgdGhlbSBvdXQsIHRoZXkgbWlnaHQKPiA+IGp1c3QgYXZvaWQgdGhlIG5lZWQgZm9yIE5B TkRfQ01EX1JORE9VVCBieSBmb3JjaW5nIGZ1bGwgcGFnZSBhY2Nlc3Nlcwo+ID4gZGlyZWN0bHku IFRoZSByZWFzb24gd2h5IHRoZXkgd2VyZSBpbnRyb2R1Y2VkIGlzIG5vdCBleGFjdGx5IG91cgo+ ID4gY3VycmVudCB1c2UgY2FzZSwgYnV0IGl0IGZlZWxzIGxpa2UgdGhleSBtaWdodCBiZSBoYW5k eS4KPiA+IAo+ID4gNjU4YmViNjYzOTYwICgibXRkOiByYXduYW5kOiBFeHBvc2UgbW9ub2xpdGhp YyByZWFkL3dyaXRlX3BhZ2VfcmF3KCkgaGVscGVycyIpCj4gPiAwZTdmNGI2NGVhNDYgKCJtdGQ6 IHJhd25hbmQ6IEFsbG93IGNvbnRyb2xsZXJzIHRvIG92ZXJsb2FkIHNvZnQgRUNDIGhvb2tzIikg IAo+IAo+IFllcywgSSBhbHJlYWR5IG1ha2UgdXNlIG9mIDBlN2Y0YjY0ZWE0Ni4gTXkgcHJvYmxl bSBpcyBvbmx5IHRoZSBlY2MucmVhZF9zdWJwYWdlCj4gaG9vayB3aGljaCBjYW4ndCBiZSBvdmVy d3JpdHRlbiBhbmQgQUZBSUsgdGhpcyBpcyB0aGUgb25seSB3YXkKPiBOQU5EX0NNRF9STkRPVVQg bWlnaHQgYmUgdXNlZCBpbiBteSBjYXNlLgoKSXQgbmVlZHMgdG8gYmUgc3VwcG9ydGVkLCB3ZSBk b24ndCBleHBlY3QgaW4gdGhlIGNvcmUgdGhhdCB0aGlzIGNvbW1hbmQKd2lsbCBub3QgYmUgc3Vw cG9ydGVkLiBUaGVyZSBtYXkgYmUgc29tZSBjb25zdHJhaW50cyBhbmQgbGltaXRhdGlvbnMsCmFu ZCB0aGlzIHdlIGNhbiB3b3JrYXJvdW5kIHRoZW0gc29tZWhvdywgYnV0IHdlIGV4cGVjdCBzdXBw b3J0IGZvcgpOQU5EX0NNRF9STkRPVVQuCgpMb29rIGF0IGFsbCB1c2VycyBvZiBuYW5kX2NoYW5n ZV9yZWFkX2NvbHVtbl9vcCgpLCBOQU5EIG1hbnVmYWN0dXJlcgpkcml2ZXJzIHVzZSBpdCwgamVk ZWMvb25maSBkcml2ZXJzIHVzZSBpdCBhcyB3ZWxsIGluIGNhc2Ugb2YKYml0ZmxpcCBpbiB0aGUg cGFyYW1ldGVyIHBhZ2UsIGFuZCB0aGUgY29yZSBtYXkgd2FudCB0byB1c2UgaXQgKGFsdGhvdWdo CmluIHlvdXIgY2FzZSBJIGRvbid0IHRoaW5rIGl0IGFjdHVhbGx5IGRvZXMgaWYgeW91IGRvbid0 IHRyeSB0byBzdXBwb3J0Cm92ZXIgY29tcGxleCBsYXlvdXRzLCBhcyBzb2Z0d2FyZSBFQ0MgZW5n aW5lcyB3aWxsIGFsd2F5cyByZXF1ZXN0IHRoZQpPT0IgZGF0YSB3aGVyZWFzIHN1YnBhZ2VzIGFy ZSBub3QgdXNlZCBpbiB0aGlzIHNpdHVhdGlvbikuCgo+IEkgdGhpbmsgbXkgZmF2b3VyaXRlIHNv bHV0aW9uIHdvdWxkIGJlIHRvOgo+IAo+IC0gc3RvcmUgZGF0YS9PT0IgaW50ZXJsZWF2ZWQgZm9y IGJvdGggaGFyZHdhcmUgYW5kIHNvZnR3YXJlIEVDQwo+IC0gRm9yIHNvZnR3YXJlIEVDQyB1c2Ug YSBzaW1pbGFyIE9PQiBsYXlvdXQgYXMgdXNlZCB3aXRoIGhhcmR3YXJlCj4gICBFQ0MuIFRoaXMg YWxsb3dzIHVzIHRvIHJlYWQgYSBzdWJwYWdlIGluY2x1ZGluZyBpdHMgRUNDIGRhdGEgaW4KPiAg IGEgc2luZ2xlIHN0ZXAgKGp1c3QgbGlrZSB3aXRoIGhhcmR3YXJlIEVDQyB0aGUgY29udHJvbGxl ciBqdXN0Cj4gICByZWFkcyA1MTJiICsgMTZiIGZvciBlYWNoIHN1YnBhZ2UpCj4gLSBBbGxvdyB0 byBkaXNhYmxlIHN1YnBhZ2UgcmVhZHMgaW4gdGhlIE5BTkQgY29yZQo+IAo+IEFzIGEgZnVydGhl ciBvcHRpbWlzYXRpb24gd2UgY291bGQgbWFrZSBlY2MucmVhZF9zdWJwYWdlIG92ZXJ3cml0YWJs ZQo+IGZvciBlY2MtPmVuZ2luZV90eXBlID09IE5BTkRfRUNDX0VOR0lORV9UWVBFX1NPRlQgJiYg ZWNjLT5hbGdvID09Cj4gTkFORF9FQ0NfQUxHT19CQ0guIFdpdGggdGhlIE9PQiBsYXlvdXQgZGVz Y3JpYmVkIGFib3ZlIHRoYXQgd291bGQgYmUKPiBlYXNpbHkgaW1wbGVtZW50YWJsZSB3aXRoIHRo ZSBteGNfbmFuZCBjb250cm9sbGVyLgo+IAo+IFdoYXQgZG8geW91IHRoaW5rPwoKSSdtIHNvcnJ5 IGJ1dCBJIGZlZWwgbGlrZSBJIG5lZWQgdG8gYW5zd2VyICJubyIgdG8gYWxsIHRocmVlIGl0ZW1z CmFib3ZlLiBJdCB3b3VsZCBiZSB0b3RhbGx5IGJhY2t3YXJkcy4KCj4gSWYgeW91IGluc2lzdCBJ IHdvdWxkIGdvIHRoZSBwYXRoIG9mIG1ha2luZyBOQU5EX0NNRF9STkRPVVQgd29yayBmb3IKPiBz b2Z0d2FyZSBFQ0MsIGFsdGhvdWdoIEkgdGhpbmsgaXQgd291bGQgY2F1c2UgbWUgZXh0cmEgd29y ayB3aXRoIG5vCj4gY2xlYXIgZ2FpbiBmb3IgbWUuCgpZZXMsIHBsZWFzZS4gSSBiZWxpZXZlIHRo aXMgY29tbWFuZCBpcyBub3QgdGhhdCBjb21wbGV4IHRvIGltcGxlbWVudCwKZXZlbiB3aXRoIHN0 cm9uZyAoYW5kIGNsZWFybHkgYWR2ZXJ0aXNlZCkgbGltaXRhdGlvbnMuIEkgaGFkIGEgbG9vayBh dAp5b3VyIGV4ZWNfb3AoKSBpbXBsZW1lbnRhdGlvbiBhbmQgdG8gdGhlIGRhdGFzaGVldCBvZiB0 aGUgaW14MjcsIHRoZQpjb250cm9sbGVyIGNsZWFybHkgc3VwcG9ydHMgQ01EL0FERFIvQ01EL0RB VEFJTiBvcHMuIEl0J3MgdHJ1ZSB0aGF0IHlvdQpjYW4gb25seSByZXF1ZXN0IDE2LCA1MTIgb3Ig NTI4IGJ5dGVzLCBidXQsIHdoeSBub3Q/IEl0IGp1c3QgbmVlZHMKdG8gYmUgY2xlYXJseSBpZGVu dGlmaWVkIHRoYXQgcmVhZGluZyBtb3JlIGRhdGEgaXMgbm90IHN1cHBvcnRlZC4gT25jZQp0aGUg ZGF0YSBpcyBpbiB0aGUgbG9jYWwgU1JBTSB5b3UganVzdCB0YWtlIHdoYXQgeW91IG5lZWQgYW5k IGRvbmUuCkZyb20gYSBwZXJmb3JtYW5jZSBwZXJzcGVjdGl2ZSwgSSBkb24ndCB0aGluayB0aGlz IG9wZXJhdGlvbiB3aWxsIGJlCnVzZWQgb2Z0ZW4sIGF0IGxlYXN0IG5vdCBpbiB0aGUgZmFzdCBw YXRoIChzZWUgYWJvdmUgd2h5KSwgYnV0IHdlIG5lZWQKaXQgZm9yIHRoZSBkcml2ZXIgdG8gd29y ayBwcm9wZXJseSBpbiBhbGwgc2l0dWF0aW9ucy4KClRoZXJlIGlzIHBlcmhhcHMgc29tZXRoaW5n IHRoYXQgaXMgbWlzc2luZyBpbiB5b3VyIGN1cnJlbnQKaW1wbGVtZW50YXRpb24gdGhvdWdoOiB0 aGVyZSBpcyBhIGNoZWNrX29ubHkgYm9vbGVhbiBpbiAtPmV4ZWNfb3AoKQp3aGljaCBtaWdodCBy ZXF1aXJlIGFkZGl0aW9uYWwgaGFuZGxpbmcgc28gdGhhdCB0aGUgY29yZSBkb2VzIG5vdCB0cnkg dG8KcGVyZm9ybSB1bnN1cHBvcnRlZCBvcGVyYXRpb25zLiBZb3UgY2FuIGRvIHRoYXQgZWl0aGVy IG1hbnVhbGx5IGJ5CmNoZWNraW5nIHRoZSBvcHMgZW50aXJlbHkgYnkgaGFuZCBpZiB0aGVyZSBh cmUgb25seSBhIGNvdXBsZSB0aGF0CmNhbm5vdCBiZSBzdXBwb3J0ZWQsIG9yIGxldmVyYWdlIHRo ZSBjb3JlIHBhcnNlciBvdGhlcndpc2UuCgpJbiB0aGlzIGNhc2UgeW91IGNhbiBoYXZlIGEgbG9v ayBhdCB0aGUgdXNlIG9mIHRoZSAic3RydWN0Cm5hbmRfb3BfcGFyc2VyIiBpbiB0aGUgc3Vic3lz dGVtLiBQbGVhc2UgYWxzbyBkb24ndCBoZXNpdGF0ZSB0byB0YWtlCmluc3BpcmF0aW9uIGZyb20g b3RoZXIgZHJpdmVycywgYXMgeW91IG1pZ2h0IG5lZWQgdG8gYWR2ZXJ0aXNlCmxpbWl0YXRpb25z IHN1Y2ggYXMgYSBtYXhpbXVtIG51bWJlciBvZiBjb21tYW5kLCBhZGRyZXNzIG9yCmRhdGEgY3lj bGVzIChpbiB0aGlzIGNhc2UsIDUyOCBvciA1MTIgaWYgaXQncyBlYXNpZXIpLgoKVGhhbmtzLApN aXF1w6hsCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18KTGludXggTVREIGRpc2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZy YWRlYWQub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbXRkLwo= From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from relay7-d.mail.gandi.net (relay7-d.mail.gandi.net [217.70.183.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4F3A115E7EE for ; Tue, 7 May 2024 14:03:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.70.183.200 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715090584; cv=none; b=kHVVECd9/N98fQg9vwWOIBQjaRWrEJT8EozXhZ7bOKkMrFDA8qSLh/1V7r9fZn5GzunavhjJaHFzTnzC34SS/1l4Ah8cG25zgU0RBxfRCdaiK6Y8w57lrG8+dO1oYmTvKDa9StznEsIW6Ek9P/O+V+YitaQCd89ngNHOhoV0Br8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1715090584; c=relaxed/simple; bh=zMgf+YFtkL7wyKeWiQblCBbykN0pGyoBYairoO36Hxc=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=IZ4n59H4OZuWXRzMV61e+ZW4tj6LkCyEn59fW4gE+13PUKxgZ9W/bc2jpHZgADLq5AI9P0NihsAEctk76ohhmVXlf8zrzx1N19A+OzHBRbokbDt0EJnCRNYnyj1IinC9xxaHIfIuIZU/TrJOaCLndzywQaL+z1/hqjqQFMUH24E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=E4r1i8bY; arc=none smtp.client-ip=217.70.183.200 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="E4r1i8bY" Received: by mail.gandi.net (Postfix) with ESMTPSA id 978B42000A; Tue, 7 May 2024 14:02:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1715090574; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=cKI7GlnVF7vzPp/kl1uAX4B6WlmM2PiXc58H6Tpvbjw=; b=E4r1i8bYOzJhf5Sasi5cIRU42VYipoxolzO9WnWIkyaJR83FxpDdM2jd+co9I8M1HD9rib 6WjRiX2Nbv847FQZAM9zLdi8EyReUAptAaShBzdXFSFcjkiNyblF9xpnalOPTQWRzjgOST RbgbhtQdK/2VClqmulKWBzLKeMj0H513kmUWkobSHmN2kgrXJdpDY/siWWyjbB0kJseovh XmJaqGv3LlrL9UdDXl9sUvYJgzFtZVCabkggrmC8rJlTm4/IgGo5WqT6KwDuMMaXog8kJb 81CrVn4HrgIEfz3Lz6Eko04UK2S8tINVRE5IoMRmqt9eNOuuJyVPp/0R0oBUVA== Date: Tue, 7 May 2024 16:02:51 +0200 From: Miquel Raynal To: Sascha Hauer Cc: Richard Weinberger , Vignesh Raghavendra , linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] mtd: nand: mxc_nand: support software ECC Message-ID: <20240507160251.7f804eb7@xps-13> In-Reply-To: References: <20240417-mtd-nand-mxc-nand-exec-op-v1-0-d12564fe54e9@pengutronix.de> <20240417-mtd-nand-mxc-nand-exec-op-v1-3-d12564fe54e9@pengutronix.de> <20240506160508.6c60d50f@xps-13> <20240506175106.2ab7c844@xps-13> <20240507094538.745fb5a9@xps-13> Organization: Bootlin X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; x86_64-pc-linux-gnu) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-GND-Sasl: miquel.raynal@bootlin.com Hi Sascha, > > No need, I believe the only reason for interleaving is that your > > hardware ECC engine works like that (writes the ECC bytes slightly > > after each chunk of data). So if you don't use on-host hardware ECC, > > you don't need to deal with this data layout. =20 >=20 > Right, I could use a different layout for software ECC. Using the same > layout for both hardware and software ECC is just quite convenient as > the same mxc_nand_read_page_raw()/mxc_nand_write_page_raw() could be > used for both software and hardware ECC. I'm not sure I see why it would be more convenient, as you basically don't need to provide anything if you use software ECC engines besides a minimal exec_op() implementation. Anyway, that's clearly not the good approach for software ECC: the engine decides where it wants to put the data, there is just no reason to complexify the software layout (which is free from any constraints). > Another thing that might be worth considering is that if we use > different functions for raw read/write page is that we would get > different views on the same raw page data if we switch from software to > hardware ECC or the other way round which might be confusing. Don't worry about that: it's impossible to manage. Data layout might be different of course, but most importantly once you've chosen an ECC configuration, any access with another configuration will simply fail. And I'm not just talking about the ECC/step size parameters, each engine has it's own base polynomial on which it bases all its internal calculations, and besides trying very hard to mimic your hardware engine in software for some very good reason, you'll never want to do that. Especially since the very first reason why you want software support is usually to go beyond your hardware engine capabilities in terms of strength. Here is a blog post about such situation, if deemed useful: https://bootlin.com/blog/supporting-a-misbehaving-nand-ecc-engine/ > > > This works fine currently, but means that NAND_CMD_RNDOUT can't be us= ed. > > > Using NAND_CMD_RNDOUT to position the cursor at offset 512b for examp= le > > > doesn't give you the second subpage, but instead oob0. Positioning the > > > cursor at offset 2048 doesn't give you the start of OOB, but some > > > position in the middle of data3. > > >=20 > > > Ok, NAND_CMD_RNDOUT can't be used for hardware ECC and there's no way > > > around it. For software ECC we could change the organisation in the c= hip > > > to be [2048b data][64b oob]. With that NAND_CMD_RNDOUT then could be > > > used with software ECC. > > >=20 > > > You say that NAND_CMD_RNDOUT is a basic command that is supported by = all > > > controllers, and yes, it is also supported with the mxc_nand controll= er. > > > You just can't control how many bytes are transferred between the NAND > > > chip and the controller. When using NAND_CMD_RNDOUT to read a few byt= es > > > at a certain page offset we'll end up reading 512 bytes discarding mo= st > > > of it. For the next ECC block we would move the cursor forward using > > > another NAND_CMD_RNDOUT command, again read 512 bytes and discard most > > > it (altough the desired data would have been in the first read alread= y). =20 > >=20 > > I'm not sure the controller limitations are so bad in this case. The > > core helpers (using the same example) will ask for: > > - 512b at offset 0 > > - 512b at offset 512... > > - and finally 64b at offset 2048. > > In practice it does not look like a huge drawback? I don't understand > > in which case so much data would be read and then discarded? =20 >=20 > Yes, you're right. I misread the code and thought the core would read > the ECC separately for each subpage. In fact it doesn't do so, the ECC > is always read in one go even for multiple subpages. "interleaved" layouts actually force us to perform so much sub-readings, that's probably one reason why there is no reason to try using an interleaved layout with software ECC engines. > > > So I think NAND_CMD_RNDOUT should really be avoided for this controll= er, > > > eventhough we might be able to support it. =20 > >=20 > > I also mentioned the monolithic accessors which try to avoid these > > random column changes. You probably want to check them out, they might > > just avoid the need for NAND_CMD_RNDOUT by forcing full page accesses > > directly. The reason why they were introduced is not exactly our > > current use case, but it feels like they might be handy. > >=20 > > 658beb663960 ("mtd: rawnand: Expose monolithic read/write_page_raw() he= lpers") > > 0e7f4b64ea46 ("mtd: rawnand: Allow controllers to overload soft ECC hoo= ks") =20 >=20 > Yes, I already make use of 0e7f4b64ea46. My problem is only the ecc.read_= subpage > hook which can't be overwritten and AFAIK this is the only way > NAND_CMD_RNDOUT might be used in my case. It needs to be supported, we don't expect in the core that this command will not be supported. There may be some constraints and limitations, and this we can workaround them somehow, but we expect support for NAND_CMD_RNDOUT. Look at all users of nand_change_read_column_op(), NAND manufacturer drivers use it, jedec/onfi drivers use it as well in case of bitflip in the parameter page, and the core may want to use it (although in your case I don't think it actually does if you don't try to support over complex layouts, as software ECC engines will always request the OOB data whereas subpages are not used in this situation). > I think my favourite solution would be to: >=20 > - store data/OOB interleaved for both hardware and software ECC > - For software ECC use a similar OOB layout as used with hardware > ECC. This allows us to read a subpage including its ECC data in > a single step (just like with hardware ECC the controller just > reads 512b + 16b for each subpage) > - Allow to disable subpage reads in the NAND core >=20 > As a further optimisation we could make ecc.read_subpage overwritable > for ecc->engine_type =3D=3D NAND_ECC_ENGINE_TYPE_SOFT && ecc->algo =3D=3D > NAND_ECC_ALGO_BCH. With the OOB layout described above that would be > easily implementable with the mxc_nand controller. >=20 > What do you think? I'm sorry but I feel like I need to answer "no" to all three items above. It would be totally backwards. > If you insist I would go the path of making NAND_CMD_RNDOUT work for > software ECC, although I think it would cause me extra work with no > clear gain for me. Yes, please. I believe this command is not that complex to implement, even with strong (and clearly advertised) limitations. I had a look at your exec_op() implementation and to the datasheet of the imx27, the controller clearly supports CMD/ADDR/CMD/DATAIN ops. It's true that you can only request 16, 512 or 528 bytes, but, why not? It just needs to be clearly identified that reading more data is not supported. Once the data is in the local SRAM you just take what you need and done. =46rom a performance perspective, I don't think this operation will be used often, at least not in the fast path (see above why), but we need it for the driver to work properly in all situations. There is perhaps something that is missing in your current implementation though: there is a check_only boolean in ->exec_op() which might require additional handling so that the core does not try to perform unsupported operations. You can do that either manually by checking the ops entirely by hand if there are only a couple that cannot be supported, or leverage the core parser otherwise. In this case you can have a look at the use of the "struct nand_op_parser" in the subsystem. Please also don't hesitate to take inspiration from other drivers, as you might need to advertise limitations such as a maximum number of command, address or data cycles (in this case, 528 or 512 if it's easier). Thanks, Miqu=C3=A8l