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 C421CC433F5 for ; Thu, 17 Feb 2022 08:51:06 +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=eE0PAcBdjm7vJg8cDF/DX+feO62fRAaKTVs4FWvvuE8=; b=LIySU2pghvWH90 v/ePTO/T62EEq+2YARxUeHTXDgnuF3W1gYCuuY1HY86jcoJMKg3eqOYgWLw9Bve+VBcQF1U727Ed+ lu3mA9MPh/BVmTo69hHaDxWGi6eSx1VjJLY635Z/RjlfngvnJqGO2rRM3xtlip4CQOaYRl349zu0T SSQFk899pj2Czv6gN0e1uEs4G3sbrgt29hSOzXON0BHYYsE0gSx+bHwxkYbc4uY+RSLcIjige84OR J1fsspsW7SDvE16nDO7VgF7vR/CNSxn+h/hZE1uZixZaNLJZgIuiDXdAsUUvwj4bsYepV5yVJ+N/T ZYKWEHR8aIdD3q/+jceg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKcUr-009awD-2h; Thu, 17 Feb 2022 08:50:41 +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 1nKcSk-009ZpS-1u for linux-mtd@lists.infradead.org; Thu, 17 Feb 2022 08:48:32 +0000 Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 8A1A3C0003; Thu, 17 Feb 2022 08:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1645087704; 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=Bkwv3ADXYTR6oqmLTt5vm/dXewEtDiujJ4xXuyIbJ7c=; b=V4pi27X+WUd5r213i03Yup6cBs1UF+AKK0i2TOOuw1wS0AeTlrrWmsfBFUbBS6RpncfXlH KuByUSoQ91BOJsN3atyoshfp19oA/59SlxTxxgeh2lqW9DVkKBTQr/G9//Tlup4PhFhfxK q20dZd2DY0F0vCi48CwTgasC5Jewy2Wu58jqiBMrSeAHjNChy8h0jDyaBYODjPMh1042G+ GD26I3VR3NSL0c9gxY4U9Pnb+UoWnEj/bexTsiQH2x0XA8TFMXJXYdybtw2NnrUvOR28EL JaJkmU7cclpkvqYfTlxHcy7gdbALryG6dbheKr7uMbIdNC+BS33yyq4mCqTF4g== Date: Thu, 17 Feb 2022 09:48:19 +0100 From: Miquel Raynal To: Srinivas Kandagatla Cc: Christophe Kerello , Pratyush Yadav , richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, devicetree@vger.kernel.org, chenshumin86@sina.com, Tudor Ambarus , Khouloud Touil , Linus Walleij , Bartosz Golaszewski Subject: Re: [PATCH v2 4/4] mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios property Message-ID: <20220217094819.2548a25e@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> <20220202115327.53oqg5n7tx6b6q7u@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-20220217_004830_513539_280D971A X-CRM114-Status: GOOD ( 54.73 ) 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 SGkgU3Jpbml2YXMsCgpzcmluaXZhcy5rYW5kYWdhdGxhQGxpbmFyby5vcmcgd3JvdGUgb24gV2Vk LCAxNiBGZWIgMjAyMiAwOToyNDoyOSArMDAwMDoKCj4gT24gMTYvMDIvMjAyMiAwODo0NiwgQ2hy aXN0b3BoZSBLZXJlbGxvIHdyb3RlOgo+ID4gSGkgTWlxdWVsLCBQcmF0eXVzaCwgU3Jpbml2YXMs Cj4gPiAKPiA+IE9uIDIvMi8yMiAxMjo1MywgUHJhdHl1c2ggWWFkYXYgd3JvdGU6ICAKPiA+PiAr IEtob3Vsb3VkLCBMaW51cywgQmFydG9zego+ID4+Cj4gPj4gT24gMDIvMDIvMjIgMTE6NDRBTSwg Q2hyaXN0b3BoZSBLZXJlbGxvIHdyb3RlOiAgCj4gPj4+IEhpLAo+ID4+Pgo+ID4+PiBPbiAyLzEv MjIgMTE6NDcsIFByYXR5dXNoIFlhZGF2IHdyb3RlOiAgCj4gPj4+PiBPbiAzMS8wMS8yMiAwMjo0 M1BNLCBNaXF1ZWwgUmF5bmFsIHdyb3RlOiAgCj4gPj4+Pj4gSGkgVmlnbmVzaCwgVHVkb3J5LCBQ cmF0eXVzaCwKPiA+Pj4+Pgo+ID4+Pj4+ICsgVHVkb3IgYW5kIFByYXR5dXNoCj4gPj4+Pj4KPiA+ Pj4+PiBjaHJpc3RvcGhlLmtlcmVsbG9AZm9zcy5zdC5jb20gd3JvdGUgb24gTW9uLCAzMSBKYW4g MjAyMiAxMDo1Nzo1NSA+Pj4+PiArMDEwMDoKPiA+Pj4+PiAgCj4gPj4+Pj4+IFdwLWdwaW9zIHBy b3BlcnR5IGNhbiBiZSB1c2VkIG9uIE5WTUVNIG5vZGVzIGFuZCB0aGUgc2FtZSBwcm9wZXJ0eSA+ Pj4+Pj4gY2FuCj4gPj4+Pj4+IGJlIGFsc28gdXNlZCBvbiBNVEQgTkFORCBub2Rlcy4gSW4gY2Fz ZSBvZiB0aGUgd3AtZ3Bpb3MgcHJvcGVydHkgaXMKPiA+Pj4+Pj4gZGVmaW5lZCBhdCBOQU5EIGxl dmVsIG5vZGUsIHRoZSBHUElPIG1hbmFnZW1lbnQgaXMgZG9uZSBhdCBOQU5EID4+Pj4+PiBkcml2 ZXIKPiA+Pj4+Pj4gbGV2ZWwuIFdyaXRlIHByb3RlY3QgaXMgZGlzYWJsZWQgd2hlbiB0aGUgZHJp dmVyIGlzIHByb2JlZCBvciByZXN1bWVkCj4gPj4+Pj4+IGFuZCBpcyBlbmFibGVkIHdoZW4gdGhl IGRyaXZlciBpcyByZWxlYXNlZCBvciBzdXNwZW5kZWQuCj4gPj4+Pj4+Cj4gPj4+Pj4+IFdoZW4g bm8gcGFydGl0aW9ucyBhcmUgZGVmaW5lZCBpbiB0aGUgTkFORCBEVCBub2RlLCB0aGVuIHRoZSBO QU5EID4+Pj4+PiBEVCBub2RlCj4gPj4+Pj4+IHdpbGwgYmUgcGFzc2VkIHRvIE5WTUVNIGZyYW1l d29yay4gSWYgd3AtZ3Bpb3MgcHJvcGVydHkgaXMgZGVmaW5lZCBpbgo+ID4+Pj4+PiB0aGlzIG5v ZGUsIHRoZSBHUElPIHJlc291cmNlIGlzIHRha2VuIHR3aWNlIGFuZCB0aGUgTkFORCBjb250cm9s bGVyCj4gPj4+Pj4+IGRyaXZlciBmYWlscyB0byBwcm9iZS4KPiA+Pj4+Pj4KPiA+Pj4+Pj4gQSBu ZXcgQm9vbGVhbiBmbGFnIG5hbWVkIHNraXBfd3BfZ3BpbyBoYXMgYmVlbiBhZGRlZCBpbiBudm1l bV9jb25maWcuCj4gPj4+Pj4+IEluIGNhc2Ugc2tpcF93cF9ncGlvIGlzIHNldCwgaXQgbWVhbnMg dGhhdCB0aGUgR1BJTyBpcyBoYW5kbGVkIGJ5IHRoZQo+ID4+Pj4+PiBwcm92aWRlci4gTGV0cyBz ZXQgdGhpcyBmbGFnIGluIE1URCBsYXllciB0byBhdm9pZCB0aGUgY29uZmxpY3Qgb24KPiA+Pj4+ Pj4gd3BfZ3Bpb3MgcHJvcGVydHkuCj4gPj4+Pj4+Cj4gPj4+Pj4+IFNpZ25lZC1vZmYtYnk6IENo cmlzdG9waGUgS2VyZWxsbyA8Y2hyaXN0b3BoZS5rZXJlbGxvQGZvc3Muc3QuY29tPgo+ID4+Pj4+ PiAtLS0KPiA+Pj4+Pj4gwqDCoCBkcml2ZXJzL210ZC9tdGRjb3JlLmMgfCAyICsrCj4gPj4+Pj4+ IMKgwqAgMSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKQo+ID4+Pj4+Pgo+ID4+Pj4+PiBk aWZmIC0tZ2l0IGEvZHJpdmVycy9tdGQvbXRkY29yZS5jIGIvZHJpdmVycy9tdGQvbXRkY29yZS5j Cj4gPj4+Pj4+IGluZGV4IDcwZjQ5MmRjZTE1OC4uZTZkMjUxNTk0ZGVmIDEwMDY0NAo+ID4+Pj4+ PiAtLS0gYS9kcml2ZXJzL210ZC9tdGRjb3JlLmMKPiA+Pj4+Pj4gKysrIGIvZHJpdmVycy9tdGQv bXRkY29yZS5jCj4gPj4+Pj4+IEBAIC01NDYsNiArNTQ2LDcgQEAgc3RhdGljIGludCBtdGRfbnZt ZW1fYWRkKHN0cnVjdCBtdGRfaW5mbyAqbXRkKQo+ID4+Pj4+PiDCoMKgwqDCoMKgwqAgY29uZmln LnN0cmlkZSA9IDE7Cj4gPj4+Pj4+IMKgwqDCoMKgwqDCoCBjb25maWcucmVhZF9vbmx5ID0gdHJ1 ZTsKPiA+Pj4+Pj4gwqDCoMKgwqDCoMKgIGNvbmZpZy5yb290X29ubHkgPSB0cnVlOwo+ID4+Pj4+ PiArwqDCoMKgIGNvbmZpZy5za2lwX3dwX2dwaW8gPSB0cnVlOwo+ID4+Pj4+PiDCoMKgwqDCoMKg wqAgY29uZmlnLm5vX29mX25vZGUgPSAhb2ZfZGV2aWNlX2lzX2NvbXBhdGlibGUobm9kZSwgPj4+ Pj4+ICJudm1lbS1jZWxscyIpOwo+ID4+Pj4+PiDCoMKgwqDCoMKgwqAgY29uZmlnLnByaXYgPSBt dGQ7Cj4gPj4+Pj4+IEBAIC04MzMsNiArODM0LDcgQEAgc3RhdGljIHN0cnVjdCBudm1lbV9kZXZp Y2UgPj4+Pj4+ICptdGRfb3RwX252bWVtX3JlZ2lzdGVyKHN0cnVjdCBtdGRfaW5mbyAqbXRkLAo+ ID4+Pj4+PiDCoMKgwqDCoMKgwqAgY29uZmlnLm93bmVyID0gVEhJU19NT0RVTEU7Cj4gPj4+Pj4+ IMKgwqDCoMKgwqDCoCBjb25maWcudHlwZSA9IE5WTUVNX1RZUEVfT1RQOwo+ID4+Pj4+PiDCoMKg wqDCoMKgwqAgY29uZmlnLnJvb3Rfb25seSA9IHRydWU7Cj4gPj4+Pj4+ICvCoMKgwqAgY29uZmln LnNraXBfd3BfZ3BpbyA9IHRydWU7Cj4gPj4+Pj4+IMKgwqDCoMKgwqDCoCBjb25maWcucmVnX3Jl YWQgPSByZWdfcmVhZDsKPiA+Pj4+Pj4gwqDCoMKgwqDCoMKgIGNvbmZpZy5zaXplID0gc2l6ZTsK PiA+Pj4+Pj4gwqDCoMKgwqDCoMKgIGNvbmZpZy5vZl9ub2RlID0gbnA7ICAKPiA+Pj4+Pgo+ID4+ Pj4+IFRMRFI6IFRoZXJlIGlzIGEgY29uZmxpY3QgYmV0d2VlbiBNVEQgYW5kIE5WTUVNLCB3aG8g c2hvdWxkIGhhbmRsZSB0aGUKPiA+Pj4+PiBXUCBwaW4gd2hlbiB0aGVyZSBpcyBvbmU/IEF0IGxl YXN0IGZvciByYXcgTkFORCBkZXZpY2VzLCBJIGRvbid0IHdhbnQKPiA+Pj4+PiB0aGUgTlZNRU0g Y29yZSB0byBoYW5kbGUgdGhlIHdwIHBpbi4gU28gd2UndmUgaW50cm9kdWNlZCB0aGlzCj4gPj4+ Pj4gc2tpcF93cF9ncGlvIG52bWVtIGNvbmZpZyBvcHRpb24uIEJ1dCB0aGVyZSBhcmUgdHdvIHBs YWNlcyB3aGVyZSB0aGlzCj4gPj4+Pj4gYm9vbGVhbiBjYW4gYmUgc2V0IGFuZCBvbmUgb2YgdGhl c2UgaXMgZm9yIG90cCByZWdpb25zIChzZWUgYWJvdmUpLiBJbgo+ID4+Pj4+IHRoaXMgY2FzZSwg SSBkb24ndCBrbm93IGlmIGl0IGlzIHNhZmUgb3IgaWYgQ0ZJL1NQSS1OT1IgcmVseSBvbiB0aGUK PiA+Pj4+PiBudm1lbSBwcm90ZWN0aW9uLiBQbGVhc2UgdGVsbCB1cyBpZiB5b3UgdGhpbmsgdGhp cyBpcyBmaW5lIGZvciB5b3UuICAKPiA+Pj4+Cj4gPj4+PiBXaHkgZG9lcyBOVk1FTSB0b3VjaCBo YXJkd2FyZSB3cml0ZSBwcm90ZWN0aW9uIGluIHRoZSBmaXJzdCBwbGFjZT8gVGhlCj4gPj4+PiBw dXJwb3NlIG9mIHRoZSBmcmFtZXdvcmsgaXMgdG8gcHJvdmlkZSBhIHdheSB0byByZXRyaWV2ZSBj b25maWcgc3RvcmVkCj4gPj4+PiBpbiBtZW1vcnkuIEl0IGhhcyBubyBidXNpbmVzcyBkZWFsaW5n IHdpdGggZGV0YWlscyBvZiB0aGUgY2hpcCBsaWtlIHRoZQo+ID4+Pj4gV1AgbGluZS4gVGhhdCBz aG91bGQgYmUgTVREJ3Mgam9iICh3aGljaCBpdCBzaG91bGQgZGVsZWdhdGUgdG8gU1BJIE5PUiwK PiA+Pj4+IFNQSSBOQU5ELCBldGMuKS4gSWYgeW91IHdhbnQgdG8gd3JpdGUgcHJvdGVjdCBhIGNl bGwgdGhlbiBkbyBpdCBpbgo+ID4+Pj4gc29mdHdhcmUuIEkgZG9uJ3Qgc2VlIHdoeSBOVk1FTSBz aG91bGQgYmUgZGVhbGluZyB3aXRoIGhhcmR3YXJlID4+Pj4gZGlyZWN0bHkKPiA+Pj4+IGF0IGFs bC4KPiA+Pj4+Cj4gPj4+PiBUaGF0IGlzIG15IG1lbnRhbCBtb2RlbCBvZiBob3cgdGhpbmdzIF9z aG91bGRfIHdvcmsuIEkgaGF2ZSBub3Qgc3BlbnQKPiA+Pj4+IG11Y2ggdGltZSBkaWdnaW5nIGlu dG8gaG93IHRoaW5ncyBhY3R1YWxseSB3b3JrIGN1cnJlbnRseS4KPiA+Pj4+ICAKPiA+Pj4KPiA+ Pj4gV3AtZ3Bpb3MgcHJvcGVydHkgbWFuYWdlbWVudCB3YXMgYWRkZWQgaW4gTVZNRU0gZnJhbWV3 b3JrIGluIEphbnVhcnkgPj4+IDIwMjAgPT4KPiA+Pj4gc2hhMTogMmExMjdkYTQ2MWE5ZDhkOTc3 ODJkNmU4MmIyMjcwNDEzOTNlYjRkMgo+ID4+PiAiCj4gPj4+IMKgwqDCoMKgIG52bWVtOiBhZGQg c3VwcG9ydCBmb3IgdGhlIHdyaXRlLXByb3RlY3QgcGluCj4gPj4+Cj4gPj4+IMKgwqDCoMKgIFRo ZSB3cml0ZS1wcm90ZWN0IHBpbiBoYW5kbGluZyBsb29rcyBsaWtlIGEgc3RhbmRhcmQgcHJvcGVy dHkgdGhhdAo+ID4+PiDCoMKgwqDCoCBjb3VsZCBiZW5lZml0IG90aGVyIHVzZXJzIGlmIGF2YWls YWJsZSBpbiB0aGUgY29yZSBudm1lbSBmcmFtZXdvcmsuCj4gPj4+Cj4gPj4+IMKgwqDCoMKgIElu c3RlYWQgb2YgbW9kaWZ5aW5nIGFsbCB0aGUgbWVtb3J5IGRyaXZlcnMgdG8gY2hlY2sgdGhpcyBw aW4sIG1ha2UKPiA+Pj4gwqDCoMKgwqAgdGhlIE5WTUVNIHN1YnN5c3RlbSBjaGVjayBpZiB0aGUg d3JpdGUtcHJvdGVjdCBHUElPIGJlaW5nIHBhc3NlZAo+ID4+PiDCoMKgwqDCoCB0aHJvdWdoIHRo ZSBudm1lbV9jb25maWcgb3IgZGVmaW5lZCBpbiB0aGUgZGV2aWNlIHRyZWUgYW5kIHB1bGwgaXQK PiA+Pj4gwqDCoMKgwqAgbG93IHdoZW5ldmVyIHdyaXRpbmcgdG8gdGhlIG1lbW9yeS4KPiA+Pj4g Igo+ID4+Pgo+ID4+PiBBbmQgdGhpcyBtb2RpZmljYXRpb24gd2FzIGRvbmUgZm9yIEVFUFJPTXMg Zmxhc2hlcyA9PiBzaGExOgo+ID4+PiAxYzg5MDc0YmY4NTA2OGQxYjg2ZjJlMGYwYzIxMTBmZGQ5 YjgzYzlmCj4gPj4+ICIKPiA+Pj4gwqDCoMKgwqAgZWVwcm9tOiBhdDI0OiByZW1vdmUgdGhlIHdy aXRlLXByb3RlY3QgcGluIHN1cHBvcnQKPiA+Pj4KPiA+Pj4gwqDCoMKgwqAgTlZNRU0gZnJhbWV3 b3JrIGlzIGFuIGludGVyZmFjZSBmb3IgdGhlIGF0MjQgRUVQUk9NcyBhcyB3ZWxsIGFzIGZvcgo+ ID4+PiDCoMKgwqDCoCBvdGhlciBkcml2ZXJzLCBpbnN0ZWFkIG9mIHBhc3NpbmcgdGhlIHdwLWdw aW9zIG92ZXIgdGhlIGRpZmZlcmVudAo+ID4+PiDCoMKgwqDCoCBkcml2ZXJzIGVhY2ggdGltZSwg aXQgd291bGQgYmUgYmV0dGVyIHRvIHBhc3MgaXQgb3ZlciB0aGUgTlZNRU0KPiA+Pj4gwqDCoMKg wqAgc3Vic3lzdGVtIG9uY2UgYW5kIGZvciBhbGwuCj4gPj4+Cj4gPj4+IMKgwqDCoMKgIFJlbW92 aW5nIHRoZSBzdXBwb3J0IGZvciB0aGUgd3JpdGUtcHJvdGVjdCBwaW4gYWZ0ZXIgYWRkaW5nIGl0 IHRvCj4gPj4+IMKgwqDCoMKgIHRoZSBOVk1FTSBzdWJzeXN0ZW0uCj4gPj4+ICIKPiA+Pj4KPiA+ Pj4gQ3VycmVudCBOVk1FTSBmcmFtZXdvcmsgaW1wbGVtZW50YXRpb24gdG9nZ2xlcyB0aGUgV1Ag R1BJTyB3aGVuID4+PiByZWdfd3JpdGUKPiA+Pj4gbnZtZW1fY29uZmlnIEFQSSBpcyBkZWZpbmVk LiBJbiBjYXNlIG9mIE1URCBmcmFtZXdvcmssIHJlZ193cml0ZSBpcyBub3QKPiA+Pj4gZGVmaW5l ZCBpbiBudm1lbV9jb25maWcuICAKPiA+Pgo+ID4+IFRoYW5rcyBmb3IgZGlnZ2luZyB0aGVzZSB1 cC4gSSB0aGluayB0aGlzIHdhcyB0aGUgd3JvbmcgZGVjaXNpb24gdG8KPiA+PiBtYWtlLiBOVk1F TSBzaG91bGQganVzdCBwcm92aWRlIHRoZSBBUElzIGZvciBoYW5kbGluZyByZWFkL3dyaXRlLCBh bmQKPiA+PiBsZWF2ZSB0aGUgcmVzdCB0byB0aGUgZHJpdmVycy4KPiA+Pgo+ID4+IEl0IG1pZ2h0 IGJlIGNvbnZlbmllbnQgZm9yIHNvbWUgZHJpdmVycyB0byBwdXQgdGhlIFdQIEdQSU8gaGFuZGxp bmcgdG8KPiA+PiBOVk1FTSBjb3JlIGJ1dCBJIGp1c3QgZG9uJ3QgdGhpbmsgaXQgaXMgdGhlIGpv YiBvZiB0aGUgZnJhbWV3b3JrIHRvIGRlYWwKPiA+PiB3aXRoIHRoaXMsIGFuZCBpdCBqdXN0IGRv ZXMgbm90IGtub3cgZW5vdWdoIGFib3V0IHRoZSBkZXZpY2UgdG8gZGVhbAo+ID4+IHdpdGggY29y cmVjdGx5IGFuZCBjb21wbGV0ZWx5IGFueXdheS4gRm9yIGV4YW1wbGUsIHdwLWdwaW8gaXMgb25s eSBvbmUKPiA+PiBvZiB0aGUgd2F5cyB0byB3cml0ZSBwcm90ZWN0IGEgY2hpcC4gU1BJIE5PUiBm bGFzaGVzIGhhdmUgYSBXUCMgcGluIHRoYXQKPiA+PiBpcyBvZnRlbiB0b2dnbGVkIHZpYSB0aGUg U1BJIGNvbnRyb2xsZXIuIFRoZXJlIGNvdWxkIGFsc28gYmUgcmVnaXN0ZXJzCj4gPj4gdGhhdCBk byB0aGUgd3JpdGUgcHJvdGVjdGlvbi4KPiA+Pgo+ID4+IE9uZSB3b3VsZCBoYXZlIHRvIG1ha2Ug c3Ryb25nIGp1c3RpZmljYXRpb25zIGZvciBtYWtpbmcgbnZtZW0gZGlyZWN0bHkKPiA+PiBkZWFs IHdpdGggaGFyZHdhcmUgbGV2ZWwgZGV0YWlscyB0byBjb252aW5jZSBtZSBpdCBpcyBhIGdvb2Qg aWRlYS4gSU1ITwo+ID4+IGlmIEFUMjQgRUVQUk9NIGlzIHRoZSBvbmx5IGRyaXZlciByZWx5aW5n IG9uIHRoaXMgYXMgb2Ygbm93IHRoZW4gd2UKPiA+PiBzaG91bGQganVzdCByZXZlcnQgdGhlIHBh dGNoZXMgYW5kIG5vdCBoYXZlIHRvIGRlYWwgd2l0aCB0aGUKPiA+PiBza2lwX3dwX2dwaW8gaGFj a2VyeS4KPiA+PiAgCj4gPiAKPiA+IEJhc2VkIG9uIHRoZcKgIGJpbmRpbmdzIGRvY3VtZW50YXRp b24sIEFUMjQgRUVQUk9NIGRyaXZlciBpcyBub3QgdGhlIG9ubHkKPiA+IGRyaXZlciByZWx5aW5n IG9uIHRoaXMgaW1wbGVtZW50YXRpb24uIEF0IGxlYXN0LCBBVDI1IEVFUFJPTSBkcml2ZXIgd2ls bAo+ID4gaGF2ZSB0byBiZSBtb2RpZmllZCB0byBoYW5kbGUgdGhlIFdyaXRlIFByb3RlY3QgbWFu YWdlbWVudCwgYW5kIHRoZXJlIGlzCj4gPiBwcm9iYWJseSBvdGhlcnMgZHJpdmVycyByZWx5aW5n IG9uIHRoaXMgaW1wbGVtZW50YXRpb24uCj4gPiAKPiA+IFNvLCBzaG91bGQgd2Uga2VlcCB0aGUg bGVnYWN5IGFuZCBhcHBseSB0aGUgcHJvcG9zYWwgcGF0Y2ggdG8gZml4IHRoaXMKPiA+IGNvbmZs aWN0IChJIGNhbiBzZW5kIGEgVjMgd2l0aCBhIGZpeGVzIHRhZyBvbiBwYXRjaCAzIGFuZCA0IGFz Cj4gPiByZWNvbW1lbmRlZCBieSBNaXF1ZWwpPwo+ID4gT3Igc2hvdWxkIHdlIHJldmVydCB0aGUg V3JpdGUgUHJvdGVjdCBtYW5hZ2VtZW50IGluIE5WTUVNIGZyYW1ld29yawo+ID4gYnV0IGluIHRo aXMgY2FzZSBJIHdpbGwgbm90IGJlIGFibGUgdG8gaGFuZGxlIHN1Y2ggbW9kaWZpY2F0aW9ucyAo SSBhbQo+ID4gbm90IGFibGUgdG8gdGVzdCB0aG9zZSBkcml2ZXJzKS4gIAo+IAo+IEZpcnN0bHkg c29ycnkgZm9yIHN1Y2ggYSBsb25nIGRlbGF5IHRvIHJlcGx5IHRoaXMgdGhyZWFkIGFzIEkgd2Fz IGluIHRyYXZlbC4KPiAKPiBJIGFncmVlIHdpdGggY29tbWVudHMgZnJvbSBQcmF0eXVzaCBidXQg SSBzZWUgbm8gaGFybSBpbiBoYW5kbGluZyBzaW1wbGUgdXNlY2FzZXMgb2Ygd3JpdGUtcHJvdGVj dCBncGlvIGluIG52bWVtIGNvcmUuIEluIGZhY3Qgd3AtZ3Bpb3MgYW5kIHJlYWQtb25seSBhcmUg cGFydCBvZiBudm1lbSBwcm92aWRlciBiaW5kaW5ncy4KPiAKPiBCdXQgdXNlY2FzZXMgbGlrZSB0 aGUgb25lcyBkZXNjcmliZWQgaW4gdGhpcyBwYXRjaCBzZXJpZXMgd2hpY2ggZG8gbm90IHdhbnQg bnZtZW0gY29yZSB0byBkZWFsIHdpdGggdGhpcyBwaW4gc2hvdWxkIHNldCB0aGlzIG5ldyBmbGFn LiBJIHRoaW5rIHRoaXMgaXMgYSBiYWxhbmNlZCBjaG9pY2UuCj4gCj4gcmV2ZXJ0aW5nIHRoZSB3 cC1ncGlvIHBhdGNoIGlzIGdvaW5nIHRvIGJyZWFrIG90aGVyIHByb3ZpZGVycyB0aGF0IGFyZSB1 c2luZyB0aGlzIGJpbmRpbmdzLgoKSSBhbSBhbHdheXMgcHV6emxlZCB3aGVuIHRoZSBjb21tdW5p dHkgZGVlcGx5IGNhcmVzIGFib3V0IG5vbi1tYWlubGluZQpkcml2ZXJzLgoKT24gb25lIHNpZGUg SSBjYW4gdW5kZXJzdGFuZCB0aGF0IGNyZWF0aW5nIGEgJ2dyYWItdGhlLXdwLWxpbmUnCmZsYWcg d291bGQgaW1tZWRpYXRlbHkgYnJlYWsgYWxsIGV4dGVybmFsIHVzZXJzIGJ1dCB0aGlzIGlzLCBh cwpyZXBvcnRlZCBieSBQcmF0eXVzaCwgdGhlIG1vcmUgbG9naWNhbCBhcHByb2FjaCBJTUhPLiBI b3dldmVyIHdlIG1pZ2h0CnBvc3NpYmx5IG1pc3Mgc2l0dWF0aW9ucyB3aGVyZSB0aGUgZmxhZyBp cyBuZWNlc3NhcnkgYW5kIGJyZWFrIHRoZXNlCmRldmljZXMuCgpPdGhlcndpc2UgdGhlICdpZ25v cmUtd3AnIGZsYWcgaXMgbW9yZSBjb25zZXJ2YXRpdmUsIGl0IGRvZXMgbm90CmJyZWFrIHRoZSBl eGlzdGluZyB1c2VycyBidXQgd291bGQganVzdCBhZGRyZXNzIHRoZSBNVEQgY2FzZSBmb3Igbm93 LCB3ZQptaWdodCBoYXZlIG90aGVyIGluLXRyZWUgc3Vic3lzdGVtIHRoYXQgYXJlIGFmZmVjdGVk LgoKSSdtIGZpbmUgZWl0aGVyIHdheSBUQkggOi0pIEkgd291bGQganVzdCBsaWtlIHRoaXMgcGF0 Y2hzZXQgdG8gZ28gaW4KdGhyb3VnaCB0aGUgbmV4dCBtZXJnZSB3aW5kb3cuCgpUaGFua3MsCk1p cXXDqGwKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXwpMaW51eCBNVEQgZGlzY3Vzc2lvbiBtYWlsaW5nIGxpc3QKaHR0cDovL2xpc3RzLmluZnJh ZGVhZC5vcmcvbWFpbG1hbi9saXN0aW5mby9saW51eC1tdGQvCg== 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 74AFAC433EF for ; Thu, 17 Feb 2022 08:48:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237997AbiBQIsm (ORCPT ); Thu, 17 Feb 2022 03:48:42 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:43692 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235672AbiBQIsm (ORCPT ); Thu, 17 Feb 2022 03:48:42 -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 9A47E2A2286; Thu, 17 Feb 2022 00:48:26 -0800 (PST) Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 8A1A3C0003; Thu, 17 Feb 2022 08:48:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1645087704; 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=Bkwv3ADXYTR6oqmLTt5vm/dXewEtDiujJ4xXuyIbJ7c=; b=V4pi27X+WUd5r213i03Yup6cBs1UF+AKK0i2TOOuw1wS0AeTlrrWmsfBFUbBS6RpncfXlH KuByUSoQ91BOJsN3atyoshfp19oA/59SlxTxxgeh2lqW9DVkKBTQr/G9//Tlup4PhFhfxK q20dZd2DY0F0vCi48CwTgasC5Jewy2Wu58jqiBMrSeAHjNChy8h0jDyaBYODjPMh1042G+ GD26I3VR3NSL0c9gxY4U9Pnb+UoWnEj/bexTsiQH2x0XA8TFMXJXYdybtw2NnrUvOR28EL JaJkmU7cclpkvqYfTlxHcy7gdbALryG6dbheKr7uMbIdNC+BS33yyq4mCqTF4g== Date: Thu, 17 Feb 2022 09:48:19 +0100 From: Miquel Raynal To: Srinivas Kandagatla Cc: Christophe Kerello , Pratyush Yadav , richard@nod.at, vigneshr@ti.com, robh+dt@kernel.org, linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com, devicetree@vger.kernel.org, chenshumin86@sina.com, Tudor Ambarus , Khouloud Touil , Linus Walleij , Bartosz Golaszewski Subject: Re: [PATCH v2 4/4] mtd: core: Fix a conflict between MTD and NVMEM on wp-gpios property Message-ID: <20220217094819.2548a25e@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> <20220202115327.53oqg5n7tx6b6q7u@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 Srinivas, srinivas.kandagatla@linaro.org wrote on Wed, 16 Feb 2022 09:24:29 +0000: > On 16/02/2022 08:46, Christophe Kerello wrote: > > Hi Miquel, Pratyush, Srinivas, > >=20 > > On 2/2/22 12:53, Pratyush Yadav wrote: =20 > >> + Khouloud, Linus, Bartosz > >> > >> On 02/02/22 11:44AM, Christophe Kerello wrote: =20 > >>> Hi, > >>> > >>> On 2/1/22 11:47, Pratyush Yadav wrote: =20 > >>>> 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 >= >>>> +0100: > >>>>> =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 resu= med > >>>>>> 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_conf= ig. > >>>>>> 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 > >>>>>> --- > >>>>>> =C2=A0=C2=A0 drivers/mtd/mtdcore.c | 2 ++ > >>>>>> =C2=A0=C2=A0 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) > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.stride =3D 1; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.read_only =3D true; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.root_only =3D true; > >>>>>> +=C2=A0=C2=A0=C2=A0 config.skip_wp_gpio =3D true; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.no_of_node =3D !of_dev= ice_is_compatible(node, >>>>>> "nvmem-cells"); > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.priv =3D mtd; > >>>>>> @@ -833,6 +834,7 @@ static struct nvmem_device >>>>>> *mtd_otp_nvm= em_register(struct mtd_info *mtd, > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.owner =3D THIS_MODULE; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.type =3D NVMEM_TYPE_OT= P; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.root_only =3D true; > >>>>>> +=C2=A0=C2=A0=C2=A0 config.skip_wp_gpio =3D true; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.reg_read =3D reg_read; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 config.size =3D size; > >>>>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 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 wa= nt > >>>>> 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 th= is > >>>>> 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 > >>>> > >>>> Why does NVMEM touch hardware write protection in the first place? T= he > >>>> purpose of the framework is to provide a way to retrieve config stor= ed > >>>> 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 N= OR, > >>>> 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. > >>>> > >>>> That is my mental model of how things _should_ work. I have not spent > >>>> much time digging into how things actually work currently. > >>>> =20 > >>> > >>> Wp-gpios property management was added in MVMEM framework in January = >>> 2020 =3D> > >>> sha1: 2a127da461a9d8d97782d6e82b227041393eb4d2 > >>> " > >>> =C2=A0=C2=A0=C2=A0=C2=A0 nvmem: add support for the write-protect pin > >>> > >>> =C2=A0=C2=A0=C2=A0=C2=A0 The write-protect pin handling looks like a = standard property that > >>> =C2=A0=C2=A0=C2=A0=C2=A0 could benefit other users if available in th= e core nvmem framework. > >>> > >>> =C2=A0=C2=A0=C2=A0=C2=A0 Instead of modifying all the memory drivers = to check this pin, make > >>> =C2=A0=C2=A0=C2=A0=C2=A0 the NVMEM subsystem check if the write-prote= ct GPIO being passed > >>> =C2=A0=C2=A0=C2=A0=C2=A0 through the nvmem_config or defined in the d= evice tree and pull it > >>> =C2=A0=C2=A0=C2=A0=C2=A0 low whenever writing to the memory. > >>> " > >>> > >>> And this modification was done for EEPROMs flashes =3D> sha1: > >>> 1c89074bf85068d1b86f2e0f0c2110fdd9b83c9f > >>> " > >>> =C2=A0=C2=A0=C2=A0=C2=A0 eeprom: at24: remove the write-protect pin s= upport > >>> > >>> =C2=A0=C2=A0=C2=A0=C2=A0 NVMEM framework is an interface for the at24= EEPROMs as well as for > >>> =C2=A0=C2=A0=C2=A0=C2=A0 other drivers, instead of passing the wp-gpi= os over the different > >>> =C2=A0=C2=A0=C2=A0=C2=A0 drivers each time, it would be better to pas= s it over the NVMEM > >>> =C2=A0=C2=A0=C2=A0=C2=A0 subsystem once and for all. > >>> > >>> =C2=A0=C2=A0=C2=A0=C2=A0 Removing the support for the write-protect p= in after adding it to > >>> =C2=A0=C2=A0=C2=A0=C2=A0 the NVMEM subsystem. > >>> " > >>> > >>> Current NVMEM framework implementation toggles the WP GPIO when >>> r= eg_write > >>> nvmem_config API is defined. In case of MTD framework, reg_write is n= ot > >>> defined in nvmem_config. =20 > >> > >> Thanks for digging these up. I think this was the wrong decision to > >> make. NVMEM should just provide the APIs for handling read/write, and > >> leave the rest to the drivers. > >> > >> It might be convenient for some drivers to put the WP GPIO handling to > >> NVMEM core but I just don't think it is the job of the framework to de= al > >> with this, and it just does not know enough about the device to deal > >> with correctly and completely anyway. For example, wp-gpio is only one > >> of the ways to write protect a chip. SPI NOR flashes have a WP# pin th= at > >> is often toggled via the SPI controller. There could also be registers > >> that do the write protection. > >> > >> One would have to make strong justifications for making nvmem directly > >> deal with hardware level details to convince me it is a good idea. IMHO > >> if AT24 EEPROM is the only driver relying on this as of now then we > >> should just revert the patches and not have to deal with the > >> skip_wp_gpio hackery. > >> =20 > >=20 > > Based on the=C2=A0 bindings documentation, AT24 EEPROM driver is not th= e only > > driver relying on this implementation. At least, AT25 EEPROM driver will > > have to be modified to handle the Write Protect management, and there is > > probably others drivers relying on this implementation. > >=20 > > So, should we keep the legacy and apply the proposal patch to fix this > > conflict (I can send a V3 with a fixes tag on patch 3 and 4 as > > recommended by Miquel)? > > Or should we revert the Write Protect management in NVMEM framework > > but in this case I will not be able to handle such modifications (I am > > not able to test those drivers). =20 >=20 > Firstly sorry for such a long delay to reply this thread as I was in trav= el. >=20 > I agree with comments from Pratyush but I see no harm in handling simple = usecases of write-protect gpio in nvmem core. In fact wp-gpios and read-onl= y are part of nvmem provider bindings. >=20 > But usecases like the ones described in this patch series which do not wa= nt nvmem core to deal with this pin should set this new flag. I think this = is a balanced choice. >=20 > reverting the wp-gpio patch is going to break other providers that are us= ing this bindings. I am always puzzled when the community deeply cares about non-mainline drivers. On one side I can understand that creating a 'grab-the-wp-line' flag would immediately break all external users but this is, as reported by Pratyush, the more logical approach IMHO. However we might possibly miss situations where the flag is necessary and break these devices. Otherwise the 'ignore-wp' flag is more conservative, it does not break the existing users but would just address the MTD case for now, we might have other in-tree subsystem that are affected. I'm fine either way TBH :-) I would just like this patchset to go in through the next merge window. Thanks, Miqu=C3=A8l