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 3A4F8C433EF for ; Wed, 2 Feb 2022 10:57:56 +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=B8KW8d/hwkthv6evZqVY2tkjwKH/ukRjsiy7ivS8Uc4=; b=a+lM8bsyb+V8kh DJNv4mtlJ6ftPd8z6uqwO0/XNjy0IsqDtmraJFtmNsTX3cTir6OZMOkVZiKnD7j8Rp6RHCVYoq0zL 7sU/NjhF3/i2lUoTabpshKmkPu8K/RKAMv2QzHcmm26TDShREJWlS14kgDeQ2XhMYu0h2F7Ln66Ky KP4cxh+bLseOXjEpjKR2r7gxrNHshVQGaDorjPY6YXHGy4iIztWCGV5GJuLlH0TdXDn/Kh4BmFa5h FlkHj884dNaU3ROhIBpj1Q0PUMVe00qSQdCUl8jd2QnQATxfS1Zi/5VAcPQ8uENd2dBrTN2KLTjQb u8l7q498nhRLRMRyLvXA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFDKN-00Eyjw-I7; Wed, 02 Feb 2022 10:57:31 +0000 Received: from relay6-d.mail.gandi.net ([217.70.183.198]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nFDKK-00EyiM-C0 for linux-mtd@lists.infradead.org; Wed, 02 Feb 2022 10:57:30 +0000 Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 3B0A0C0009; Wed, 2 Feb 2022 10:57:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1643799444; 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=JA/sZXpu8XHNvzUk8TEDPhep6Z0mt6Duy6phBKTReYU=; b=TX5doXrF/JBQ54Tc79wsM5qT3CZrwggUxoF/xgbHc9hJEhDSdCns/YfQ8HiExBZNVEFESV SKeuvCG/acR14pAlV7SyBD1ARPkCO28KgmjdqRbAvkdfezkKtb43pPajsogLUXqdWvLvnJ biW4noF3zmpE+YGVm7Nmidp/v/fEq4gZqdIPQncBzX3LQpvJdsZiruGQRNXrJ9gWJAEaiC 6MbuxMj/j8XoI5vDv1Elpn1lWS8olUBTYJxlszPQL8OzhugfJLkGDWNRCV2iSfFHPqVKq1 g/VPHDrWPa8w2QVlsOWK7U+W1LpFnhOAJxeArbCUA2d+OuqnMprDQJ/z5J6cCA== Date: Wed, 2 Feb 2022 11:57:20 +0100 From: Miquel Raynal To: Christophe Kerello Cc: Pratyush Yadav , , , , , , , , , , Tudor Ambarus Subject: Re: [PATCH v2 4/4] mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios property Message-ID: <20220202115720.741a0139@xps13> In-Reply-To: References: <20220131095755.8981-1-christophe.kerello@foss.st.com> <20220131095755.8981-5-christophe.kerello@foss.st.com> <20220131144309.0ffe7cc8@xps13> <20220201104727.7xvcyexf3yucegcb@ti.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220202_025728_694502_97857E59 X-CRM114-Status: GOOD ( 45.31 ) 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 SGkgQ2hyaXN0b3BoZSwKCmNocmlzdG9waGUua2VyZWxsb0Bmb3NzLnN0LmNvbSB3cm90ZSBvbiBX ZWQsIDIgRmViIDIwMjIgMTE6NDQ6MzEgKzAxMDA6Cgo+IEhpLAo+IAo+IE9uIDIvMS8yMiAxMTo0 NywgUHJhdHl1c2ggWWFkYXYgd3JvdGU6Cj4gPiBPbiAzMS8wMS8yMiAwMjo0M1BNLCBNaXF1ZWwg UmF5bmFsIHdyb3RlOiAgCj4gPj4gSGkgVmlnbmVzaCwgVHVkb3J5LCBQcmF0eXVzaCwKPiA+Pgo+ ID4+ICsgVHVkb3IgYW5kIFByYXR5dXNoCj4gPj4KPiA+PiBjaHJpc3RvcGhlLmtlcmVsbG9AZm9z cy5zdC5jb20gd3JvdGUgb24gTW9uLCAzMSBKYW4gMjAyMiAxMDo1Nzo1NSArMDEwMDoKPiA+PiAg Cj4gPj4+IFdwLWdwaW9zIHByb3BlcnR5IGNhbiBiZSB1c2VkIG9uIE5WTUVNIG5vZGVzIGFuZCB0 aGUgc2FtZSBwcm9wZXJ0eSBjYW4KPiA+Pj4gYmUgYWxzbyB1c2VkIG9uIE1URCBOQU5EIG5vZGVz LiBJbiBjYXNlIG9mIHRoZSB3cC1ncGlvcyBwcm9wZXJ0eSBpcwo+ID4+PiBkZWZpbmVkIGF0IE5B TkQgbGV2ZWwgbm9kZSwgdGhlIEdQSU8gbWFuYWdlbWVudCBpcyBkb25lIGF0IE5BTkQgZHJpdmVy Cj4gPj4+IGxldmVsLiBXcml0ZSBwcm90ZWN0IGlzIGRpc2FibGVkIHdoZW4gdGhlIGRyaXZlciBp cyBwcm9iZWQgb3IgcmVzdW1lZAo+ID4+PiBhbmQgaXMgZW5hYmxlZCB3aGVuIHRoZSBkcml2ZXIg aXMgcmVsZWFzZWQgb3Igc3VzcGVuZGVkLgo+ID4+Pgo+ID4+PiBXaGVuIG5vIHBhcnRpdGlvbnMg YXJlIGRlZmluZWQgaW4gdGhlIE5BTkQgRFQgbm9kZSwgdGhlbiB0aGUgTkFORCBEVCBub2RlCj4g Pj4+IHdpbGwgYmUgcGFzc2VkIHRvIE5WTUVNIGZyYW1ld29yay4gSWYgd3AtZ3Bpb3MgcHJvcGVy dHkgaXMgZGVmaW5lZCBpbgo+ID4+PiB0aGlzIG5vZGUsIHRoZSBHUElPIHJlc291cmNlIGlzIHRh a2VuIHR3aWNlIGFuZCB0aGUgTkFORCBjb250cm9sbGVyCj4gPj4+IGRyaXZlciBmYWlscyB0byBw cm9iZS4KPiA+Pj4KPiA+Pj4gQSBuZXcgQm9vbGVhbiBmbGFnIG5hbWVkIHNraXBfd3BfZ3BpbyBo YXMgYmVlbiBhZGRlZCBpbiBudm1lbV9jb25maWcuCj4gPj4+IEluIGNhc2Ugc2tpcF93cF9ncGlv IGlzIHNldCwgaXQgbWVhbnMgdGhhdCB0aGUgR1BJTyBpcyBoYW5kbGVkIGJ5IHRoZQo+ID4+PiBw cm92aWRlci4gTGV0cyBzZXQgdGhpcyBmbGFnIGluIE1URCBsYXllciB0byBhdm9pZCB0aGUgY29u ZmxpY3Qgb24KPiA+Pj4gd3BfZ3Bpb3MgcHJvcGVydHkuCj4gPj4+Cj4gPj4+IFNpZ25lZC1vZmYt Ynk6IENocmlzdG9waGUgS2VyZWxsbyA8Y2hyaXN0b3BoZS5rZXJlbGxvQGZvc3Muc3QuY29tPgo+ ID4+PiAtLS0KPiA+Pj4gICBkcml2ZXJzL210ZC9tdGRjb3JlLmMgfCAyICsrCj4gPj4+ICAgMSBm aWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKQo+ID4+Pgo+ID4+PiBkaWZmIC0tZ2l0IGEvZHJp dmVycy9tdGQvbXRkY29yZS5jIGIvZHJpdmVycy9tdGQvbXRkY29yZS5jCj4gPj4+IGluZGV4IDcw ZjQ5MmRjZTE1OC4uZTZkMjUxNTk0ZGVmIDEwMDY0NAo+ID4+PiAtLS0gYS9kcml2ZXJzL210ZC9t dGRjb3JlLmMKPiA+Pj4gKysrIGIvZHJpdmVycy9tdGQvbXRkY29yZS5jCj4gPj4+IEBAIC01NDYs NiArNTQ2LDcgQEAgc3RhdGljIGludCBtdGRfbnZtZW1fYWRkKHN0cnVjdCBtdGRfaW5mbyAqbXRk KQo+ID4+PiAgIAljb25maWcuc3RyaWRlID0gMTsKPiA+Pj4gICAJY29uZmlnLnJlYWRfb25seSA9 IHRydWU7Cj4gPj4+ICAgCWNvbmZpZy5yb290X29ubHkgPSB0cnVlOwo+ID4+PiArCWNvbmZpZy5z a2lwX3dwX2dwaW8gPSB0cnVlOwo+ID4+PiAgIAljb25maWcubm9fb2Zfbm9kZSA9ICFvZl9kZXZp Y2VfaXNfY29tcGF0aWJsZShub2RlLCAibnZtZW0tY2VsbHMiKTsKPiA+Pj4gICAJY29uZmlnLnBy aXYgPSBtdGQ7ICAKPiA+Pj4gICA+Pj4gQEAgLTgzMyw2ICs4MzQsNyBAQCBzdGF0aWMgc3RydWN0 IG52bWVtX2RldmljZSAqbXRkX290cF9udm1lbV9yZWdpc3RlcihzdHJ1Y3QgbXRkX2luZm8gKm10 ZCwgIAo+ID4+PiAgIAljb25maWcub3duZXIgPSBUSElTX01PRFVMRTsKPiA+Pj4gICAJY29uZmln LnR5cGUgPSBOVk1FTV9UWVBFX09UUDsKPiA+Pj4gICAJY29uZmlnLnJvb3Rfb25seSA9IHRydWU7 Cj4gPj4+ICsJY29uZmlnLnNraXBfd3BfZ3BpbyA9IHRydWU7Cj4gPj4+ICAgCWNvbmZpZy5yZWdf cmVhZCA9IHJlZ19yZWFkOwo+ID4+PiAgIAljb25maWcuc2l6ZSA9IHNpemU7Cj4gPj4+ICAgCWNv bmZpZy5vZl9ub2RlID0gbnA7ICAKPiA+Pgo+ID4+IFRMRFI6IFRoZXJlIGlzIGEgY29uZmxpY3Qg YmV0d2VlbiBNVEQgYW5kIE5WTUVNLCB3aG8gc2hvdWxkIGhhbmRsZSB0aGUKPiA+PiBXUCBwaW4g d2hlbiB0aGVyZSBpcyBvbmU/IEF0IGxlYXN0IGZvciByYXcgTkFORCBkZXZpY2VzLCBJIGRvbid0 IHdhbnQKPiA+PiB0aGUgTlZNRU0gY29yZSB0byBoYW5kbGUgdGhlIHdwIHBpbi4gU28gd2UndmUg aW50cm9kdWNlZCB0aGlzCj4gPj4gc2tpcF93cF9ncGlvIG52bWVtIGNvbmZpZyBvcHRpb24uIEJ1 dCB0aGVyZSBhcmUgdHdvIHBsYWNlcyB3aGVyZSB0aGlzCj4gPj4gYm9vbGVhbiBjYW4gYmUgc2V0 IGFuZCBvbmUgb2YgdGhlc2UgaXMgZm9yIG90cCByZWdpb25zIChzZWUgYWJvdmUpLiBJbgo+ID4+ IHRoaXMgY2FzZSwgSSBkb24ndCBrbm93IGlmIGl0IGlzIHNhZmUgb3IgaWYgQ0ZJL1NQSS1OT1Ig cmVseSBvbiB0aGUKPiA+PiBudm1lbSBwcm90ZWN0aW9uLiBQbGVhc2UgdGVsbCB1cyBpZiB5b3Ug dGhpbmsgdGhpcyBpcyBmaW5lIGZvciB5b3UuICAKPiA+IAo+ID4gV2h5IGRvZXMgTlZNRU0gdG91 Y2ggaGFyZHdhcmUgd3JpdGUgcHJvdGVjdGlvbiBpbiB0aGUgZmlyc3QgcGxhY2U/IFRoZQo+ID4g cHVycG9zZSBvZiB0aGUgZnJhbWV3b3JrIGlzIHRvIHByb3ZpZGUgYSB3YXkgdG8gcmV0cmlldmUg Y29uZmlnIHN0b3JlZAo+ID4gaW4gbWVtb3J5LiBJdCBoYXMgbm8gYnVzaW5lc3MgZGVhbGluZyB3 aXRoIGRldGFpbHMgb2YgdGhlIGNoaXAgbGlrZSB0aGUKPiA+IFdQIGxpbmUuIFRoYXQgc2hvdWxk IGJlIE1URCdzIGpvYiAod2hpY2ggaXQgc2hvdWxkIGRlbGVnYXRlIHRvIFNQSSBOT1IsCj4gPiBT UEkgTkFORCwgZXRjLikuIElmIHlvdSB3YW50IHRvIHdyaXRlIHByb3RlY3QgYSBjZWxsIHRoZW4g ZG8gaXQgaW4KPiA+IHNvZnR3YXJlLiBJIGRvbid0IHNlZSB3aHkgTlZNRU0gc2hvdWxkIGJlIGRl YWxpbmcgd2l0aCBoYXJkd2FyZSBkaXJlY3RseQo+ID4gYXQgYWxsLgo+ID4gCj4gPiBUaGF0IGlz IG15IG1lbnRhbCBtb2RlbCBvZiBob3cgdGhpbmdzIF9zaG91bGRfIHdvcmsuIEkgaGF2ZSBub3Qg c3BlbnQKPiA+IG11Y2ggdGltZSBkaWdnaW5nIGludG8gaG93IHRoaW5ncyBhY3R1YWxseSB3b3Jr IGN1cnJlbnRseS4KPiA+ICAgCj4gCj4gV3AtZ3Bpb3MgcHJvcGVydHkgbWFuYWdlbWVudCB3YXMg YWRkZWQgaW4gTVZNRU0gZnJhbWV3b3JrIGluIEphbnVhcnkgMjAyMCA9PiBzaGExOiAyYTEyN2Rh NDYxYTlkOGQ5Nzc4MmQ2ZTgyYjIyNzA0MTM5M2ViNGQyCj4gIgo+ICAgICAgbnZtZW06IGFkZCBz dXBwb3J0IGZvciB0aGUgd3JpdGUtcHJvdGVjdCBwaW4KClBlcmhhcHMgdGhpcyBjb3VsZCBiZSBw b2ludGVkIGFzIHBhcnQgb2YgYSBGaXhlcyB0YWcsIGJlY2F1c2UgdGhpcwptaWdodCBhY3R1YWxs eSBicmVhayBvdGhlciB1c2VycyB3aGljaCB3ZSBoYXZlbid0IG5vdGljZWQgeWV0LgoKPiAKPiAg ICAgIFRoZSB3cml0ZS1wcm90ZWN0IHBpbiBoYW5kbGluZyBsb29rcyBsaWtlIGEgc3RhbmRhcmQg cHJvcGVydHkgdGhhdAo+ICAgICAgY291bGQgYmVuZWZpdCBvdGhlciB1c2VycyBpZiBhdmFpbGFi bGUgaW4gdGhlIGNvcmUgbnZtZW0gZnJhbWV3b3JrLgo+IAo+ICAgICAgSW5zdGVhZCBvZiBtb2Rp ZnlpbmcgYWxsIHRoZSBtZW1vcnkgZHJpdmVycyB0byBjaGVjayB0aGlzIHBpbiwgbWFrZQo+ICAg ICAgdGhlIE5WTUVNIHN1YnN5c3RlbSBjaGVjayBpZiB0aGUgd3JpdGUtcHJvdGVjdCBHUElPIGJl aW5nIHBhc3NlZAo+ICAgICAgdGhyb3VnaCB0aGUgbnZtZW1fY29uZmlnIG9yIGRlZmluZWQgaW4g dGhlIGRldmljZSB0cmVlIGFuZCBwdWxsIGl0Cj4gICAgICBsb3cgd2hlbmV2ZXIgd3JpdGluZyB0 byB0aGUgbWVtb3J5Lgo+ICIKPiAKPiBBbmQgdGhpcyBtb2RpZmljYXRpb24gd2FzIGRvbmUgZm9y IEVFUFJPTXMgZmxhc2hlcyA9PiBzaGExOiAxYzg5MDc0YmY4NTA2OGQxYjg2ZjJlMGYwYzIxMTBm ZGQ5YjgzYzlmCj4gIgo+ICAgICAgZWVwcm9tOiBhdDI0OiByZW1vdmUgdGhlIHdyaXRlLXByb3Rl Y3QgcGluIHN1cHBvcnQKPiAKPiAgICAgIE5WTUVNIGZyYW1ld29yayBpcyBhbiBpbnRlcmZhY2Ug Zm9yIHRoZSBhdDI0IEVFUFJPTXMgYXMgd2VsbCBhcyBmb3IKPiAgICAgIG90aGVyIGRyaXZlcnMs IGluc3RlYWQgb2YgcGFzc2luZyB0aGUgd3AtZ3Bpb3Mgb3ZlciB0aGUgZGlmZmVyZW50Cj4gICAg ICBkcml2ZXJzIGVhY2ggdGltZSwgaXQgd291bGQgYmUgYmV0dGVyIHRvIHBhc3MgaXQgb3ZlciB0 aGUgTlZNRU0KPiAgICAgIHN1YnN5c3RlbSBvbmNlIGFuZCBmb3IgYWxsLgo+IAo+ICAgICAgUmVt b3ZpbmcgdGhlIHN1cHBvcnQgZm9yIHRoZSB3cml0ZS1wcm90ZWN0IHBpbiBhZnRlciBhZGRpbmcg aXQgdG8KPiAgICAgIHRoZSBOVk1FTSBzdWJzeXN0ZW0uCj4gIgo+IAo+IEN1cnJlbnQgTlZNRU0g ZnJhbWV3b3JrIGltcGxlbWVudGF0aW9uIHRvZ2dsZXMgdGhlIFdQIEdQSU8gd2hlbiByZWdfd3Jp dGUgbnZtZW1fY29uZmlnIEFQSSBpcyBkZWZpbmVkLiBJbiBjYXNlIG9mIE1URCBmcmFtZXdvcmss IHJlZ193cml0ZSBpcyBub3QgZGVmaW5lZCBpbiBudm1lbV9jb25maWcuCj4gCj4gQmFzZWQgb24g dGhlIGNvbW1lbnRzIG1hZGUsIGl0IHNlZW1zIHRoYXQgd2UgYWxzbyBhZ3JlZSB0aGF0IHRoaXMg d3JpdGUgcHJvdGVjdGlvbiBzaG91bGQgYmUgaGFuZGxlZCBieSBNVEQgc3Vic3lzdGVtcyBvciBh c3NvY2lhdGVkIGRyaXZlcnMgYW5kIG5vdCBieSBNVk1FTiBmcmFtZXdvcmsgZm9yIE1URCB1c2Ug Y2FzZXMuCj4gCj4gVGhlIHByb3Bvc2FsIGltcGxlbWVudGF0aW9uIHNob3VsZCBzb2x2ZSB0aGlz IGNvbmZsaWN0IGZvciBNVEQgZnJhbWV3b3JrIHdpdGhvdXQgYnJlYWtpbmcgYW55dGhpbmcgZm9y IG90aGVycyBOVk1FTSB1c2VycyAoRUVQUk9NcyBmbGFzaGVzIGZvciBleGFtcGxlKS4KCkknbSBu b3Qgc3VyZSBuZWl0aGVyIHdoeSBFRVBST00gZmxhc2hlcyBkZWNpZGVkIHRvIGRlbGVnYXRlIHRo ZQp3cCBoYW5kbGluZyB0byBOVk1FTSwgYnV0IGluIGFueSBjYXNlIHdlIGRvbid0IHdhbnQgaXQg dG8gYmUKaGFuZGxlZCBhdCBOVk1FTSBsZXZlbCBpbiB0aGUgY2FzZSBvZiBNVEQsIHNvIHlvdXIg c2VyaWVzIGxvb2tzIGZpbmUgdG8KbWUuCgo+IAo+IFJlZ2FyZHMsCj4gQ2hyaXN0b3BoZSBLZXJl bGxvLgo+IAo+IAoKClRoYW5rcywKTWlxdcOobAoKX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4IE1URCBkaXNjdXNzaW9uIG1haWxpbmcg bGlzdApodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4LW10 ZC8K 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DA26EC433F5 for ; Wed, 2 Feb 2022 10:57:27 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238900AbiBBK51 (ORCPT ); Wed, 2 Feb 2022 05:57:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49642 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230095AbiBBK50 (ORCPT ); Wed, 2 Feb 2022 05:57:26 -0500 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [IPv6:2001:4b98:dc4:8::226]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2B8D8C061714; Wed, 2 Feb 2022 02:57:26 -0800 (PST) Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 3B0A0C0009; Wed, 2 Feb 2022 10:57:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1643799444; 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=JA/sZXpu8XHNvzUk8TEDPhep6Z0mt6Duy6phBKTReYU=; b=TX5doXrF/JBQ54Tc79wsM5qT3CZrwggUxoF/xgbHc9hJEhDSdCns/YfQ8HiExBZNVEFESV SKeuvCG/acR14pAlV7SyBD1ARPkCO28KgmjdqRbAvkdfezkKtb43pPajsogLUXqdWvLvnJ biW4noF3zmpE+YGVm7Nmidp/v/fEq4gZqdIPQncBzX3LQpvJdsZiruGQRNXrJ9gWJAEaiC 6MbuxMj/j8XoI5vDv1Elpn1lWS8olUBTYJxlszPQL8OzhugfJLkGDWNRCV2iSfFHPqVKq1 g/VPHDrWPa8w2QVlsOWK7U+W1LpFnhOAJxeArbCUA2d+OuqnMprDQJ/z5J6cCA== Date: Wed, 2 Feb 2022 11:57:20 +0100 From: Miquel Raynal To: Christophe Kerello Cc: Pratyush Yadav , , , , , , , , , , Tudor Ambarus Subject: Re: [PATCH v2 4/4] mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios property Message-ID: <20220202115720.741a0139@xps13> In-Reply-To: References: <20220131095755.8981-1-christophe.kerello@foss.st.com> <20220131095755.8981-5-christophe.kerello@foss.st.com> <20220131144309.0ffe7cc8@xps13> <20220201104727.7xvcyexf3yucegcb@ti.com> Organization: Bootlin X-Mailer: Claws Mail 3.17.7 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Hi Christophe, christophe.kerello@foss.st.com wrote on Wed, 2 Feb 2022 11:44:31 +0100: > Hi, >=20 > On 2/1/22 11:47, Pratyush Yadav wrote: > > On 31/01/22 02:43PM, Miquel Raynal wrote: =20 > >> Hi Vignesh, Tudory, Pratyush, > >> > >> + Tudor and Pratyush > >> > >> christophe.kerello@foss.st.com wrote on Mon, 31 Jan 2022 10:57:55 +010= 0: > >> =20 > >>> Wp-gpios property can be used on NVMEM nodes and the same property can > >>> be also used on MTD NAND nodes. In case of the wp-gpios property is > >>> defined at NAND level node, the GPIO management is done at NAND driver > >>> level. Write protect is disabled when the driver is probed or resumed > >>> and is enabled when the driver is released or suspended. > >>> > >>> When no partitions are defined in the NAND DT node, then the NAND DT = node > >>> will be passed to NVMEM framework. If wp-gpios property is defined in > >>> this node, the GPIO resource is taken twice and the NAND controller > >>> driver fails to probe. > >>> > >>> A new Boolean flag named skip_wp_gpio has been added in nvmem_config. > >>> In case skip_wp_gpio is set, it means that the GPIO is handled by the > >>> provider. Lets set this flag in MTD layer to avoid the conflict on > >>> wp_gpios property. > >>> > >>> Signed-off-by: Christophe Kerello > >>> --- > >>> drivers/mtd/mtdcore.c | 2 ++ > >>> 1 file changed, 2 insertions(+) > >>> > >>> diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c > >>> index 70f492dce158..e6d251594def 100644 > >>> --- a/drivers/mtd/mtdcore.c > >>> +++ b/drivers/mtd/mtdcore.c > >>> @@ -546,6 +546,7 @@ static int mtd_nvmem_add(struct mtd_info *mtd) > >>> config.stride =3D 1; > >>> config.read_only =3D true; > >>> config.root_only =3D true; > >>> + config.skip_wp_gpio =3D true; > >>> config.no_of_node =3D !of_device_is_compatible(node, "nvmem-cells"= ); > >>> config.priv =3D mtd; =20 > >>> >>> @@ -833,6 +834,7 @@ static struct nvmem_device *mtd_otp_nvmem_r= egister(struct mtd_info *mtd, =20 > >>> config.owner =3D THIS_MODULE; > >>> config.type =3D NVMEM_TYPE_OTP; > >>> config.root_only =3D true; > >>> + config.skip_wp_gpio =3D true; > >>> config.reg_read =3D reg_read; > >>> config.size =3D size; > >>> config.of_node =3D np; =20 > >> > >> TLDR: There is a conflict between MTD and NVMEM, who should handle the > >> WP pin when there is one? At least for raw NAND devices, I don't want > >> the NVMEM core to handle the wp pin. So we've introduced this > >> skip_wp_gpio nvmem config option. But there are two places where this > >> boolean can be set and one of these is for otp regions (see above). In > >> this case, I don't know if it is safe or if CFI/SPI-NOR rely on the > >> nvmem protection. Please tell us if you think this is fine for you. =20 > >=20 > > Why does NVMEM touch hardware write protection in the first place? The > > purpose of the framework is to provide a way to retrieve config stored > > in memory. It has no business dealing with details of the chip like the > > WP line. That should be MTD's job (which it should delegate to SPI NOR, > > SPI NAND, etc.). If you want to write protect a cell then do it in > > software. I don't see why NVMEM should be dealing with hardware directly > > at all. > >=20 > > That is my mental model of how things _should_ work. I have not spent > > much time digging into how things actually work currently. > > =20 >=20 > Wp-gpios property management was added in MVMEM framework in January 2020= =3D> sha1: 2a127da461a9d8d97782d6e82b227041393eb4d2 > " > nvmem: add support for the write-protect pin Perhaps this could be pointed as part of a Fixes tag, because this might actually break other users which we haven't noticed yet. >=20 > The write-protect pin handling looks like a standard property that > could benefit other users if available in the core nvmem framework. >=20 > Instead of modifying all the memory drivers to check this pin, make > the NVMEM subsystem check if the write-protect GPIO being passed > through the nvmem_config or defined in the device tree and pull it > low whenever writing to the memory. > " >=20 > And this modification was done for EEPROMs flashes =3D> sha1: 1c89074bf85= 068d1b86f2e0f0c2110fdd9b83c9f > " > eeprom: at24: remove the write-protect pin support >=20 > NVMEM framework is an interface for the at24 EEPROMs as well as for > other drivers, instead of passing the wp-gpios over the different > drivers each time, it would be better to pass it over the NVMEM > subsystem once and for all. >=20 > Removing the support for the write-protect pin after adding it to > the NVMEM subsystem. > " >=20 > Current NVMEM framework implementation toggles the WP GPIO when reg_write= nvmem_config API is defined. In case of MTD framework, reg_write is not de= fined in nvmem_config. >=20 > Based on the comments made, it seems that we also agree that this write p= rotection should be handled by MTD subsystems or associated drivers and not= by MVMEN framework for MTD use cases. >=20 > The proposal implementation should solve this conflict for MTD framework = without breaking anything for others NVMEM users (EEPROMs flashes for examp= le). I'm not sure neither why EEPROM flashes decided to delegate the wp handling to NVMEM, but in any case we don't want it to be handled at NVMEM level in the case of MTD, so your series looks fine to me. >=20 > Regards, > Christophe Kerello. >=20 >=20 Thanks, Miqu=C3=A8l