Received-SPF: pass (google.com: domain of linux-kernel+bounces-200173-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
From: Michael Walle <mwalle@kernel.org>
To: Tudor Ambarus <tudor.ambarus@linaro.org>,
	Pratyush Yadav <pratyush@kernel.org>,
	Michael Walle <mwalle@kernel.org>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Richard Weinberger <richard@nod.at>,
	Vignesh Raghavendra <vigneshr@ti.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>
Cc: linux-mtd@lists.infradead.org,
	devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	=?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>,
	Thorsten Scherer <t.scherer@eckelmann.de>,
	Marek Vasut <marex@denx.de>,
	Imre Kaloz <kaloz@openwrt.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Flavio Suligoi <f.suligoi@asem.it>
Subject: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices
Date: Tue,  4 Jun 2024 09:42:31 +0200
Message-Id: <20240604074231.1874972-1-mwalle@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

These devices are more like an AT25 compatible EEPROM instead of
flashes. Like an EEPROM the user doesn't need to explicitly erase the
memory, nor are there sectors or pages. Thus, instead of the SPI-NOR
(flash) driver, one should instead use the at25 EEPROM driver.

Signed-off-by: Michael Walle <mwalle@kernel.org>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Thorsten Scherer <t.scherer@eckelmann.de>
Cc: Marek Vasut <marex@denx.de>
Cc: Imre Kaloz <kaloz@openwrt.org>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: Flavio Suligoi <f.suligoi@asem.it>
---
The referenced binding only supports the true AT25 compatible EEPROMs
where you have to specify additional properties like size and page size
or cypress FRAM devices where all the properties are discovered by the
driver. I don't have the actual hardware, therefore I can't work on a
proper driver and binding. But I really want to deprecate the use of
these EEPROM like devices in SPI-NOR. So as a first step, mark the
devices in the DT bindings as deprecated.

There are three in-tree users of this. I hope I've CCed all the relevant
people. With the switch to the at25 driver also comes a user-space
facing change: there is no more MTD device. Instead there is an "eeprom"
file in /sys now, just like for every other EEPROM.

Marek already expressed, that the sps1 dts can likely be removed
altogether. I'd like to hear from the other board DTS maintainers if
they seem some problems moving to the EEPROM interface - or maybe that
device isn't used at all anyway. So in the end, we can hopefully move
all the users over to the at25 driver.
---
 Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
index 6e3afb42926e..2dccb6b049ea 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml
@@ -21,7 +21,6 @@ properties:
               (m25p(40|80|16|32|64|128)|\
               n25q(32b|064|128a11|128a13|256a|512a|164k)))|\
               atmel,at25df(321a|641|081a)|\
-              everspin,mr25h(10|40|128|256)|\
               (mxicy|macronix),mx25l(4005a|1606e|6405d|8005|12805d|25635e)|\
               (mxicy|macronix),mx25u(4033|4035)|\
               (spansion,)?s25fl(128s|256s1|512s|008k|064k|164k)|\
@@ -42,6 +41,14 @@ properties:
               - spansion,s25fs512s
           - const: jedec,spi-nor
       - const: jedec,spi-nor
+
+      # Deprecated bindings
+      - items:
+          - pattern: "^everspin,mr25h(10|40|128|256)$"
+          - const: jedec,spi-nor
+        description:
+          Deprecated binding, use Documentation/devicetree/bindings/eeprom/at25.yaml.
+        deprecated: true
     description:
       SPI NOR flashes compatible with the JEDEC SFDP standard or which may be
       identified with the READ ID opcode (0x9F) do not deserve a specific
-- 
2.39.2