From: Conor Dooley <conor@kernel.org>
To: Michael Walle <mwalle@kernel.org>
Cc: "Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Pratyush Yadav" <pratyush@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>,
linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Uwe Kleine-König" <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: Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices
Date: Tue, 4 Jun 2024 18:01:23 +0100 [thread overview]
Message-ID: <20240604-ladylike-gout-6fd6ae992712@spud> (raw)
In-Reply-To: <20240604074231.1874972-1-mwalle@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3554 bytes --]
On Tue, Jun 04, 2024 at 09:42:31AM +0200, Michael Walle wrote:
> 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
The idea here seems okay, but directing people to use the at25 binding,
without actually documenting the replacement compatibles etc is far from
ideal. I think even a wording change that points out that that these
devices need to be documented in that file would be an improvement, the
current wording makes it seem like the works been done.
Until there's a replacement driver, I don't think you could really
expect anyone to move to a new binding anyway.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-06-04 17:01 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 7:42 [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices Michael Walle
2024-06-04 7:45 ` Tudor Ambarus
2024-06-04 8:09 ` Miquel Raynal
2024-06-04 15:31 ` EXTERNAL: " FLAVIO SULIGOI
2024-06-04 17:01 ` Conor Dooley [this message]
2024-06-04 17:42 ` Michael Walle
2024-06-05 17:40 ` Conor Dooley
2024-06-06 12:03 ` Tudor Ambarus
2024-06-05 13:58 ` Thorsten Scherer
2024-06-06 12:14 ` Tudor Ambarus
2024-06-06 12:33 ` Michael Walle
2024-06-21 6:49 ` Alexander Stein
2024-06-21 7:09 ` Michael Walle
2024-06-21 7:48 ` Alexander Stein
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240604-ladylike-gout-6fd6ae992712@spud \
--to=conor@kernel.org \
--cc=andrew@lunn.ch \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=f.suligoi@asem.it \
--cc=kaloz@openwrt.org \
--cc=krzk+dt@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marex@denx.de \
--cc=miquel.raynal@bootlin.com \
--cc=mwalle@kernel.org \
--cc=pratyush@kernel.org \
--cc=richard@nod.at \
--cc=robh@kernel.org \
--cc=t.scherer@eckelmann.de \
--cc=tudor.ambarus@linaro.org \
--cc=u.kleine-koenig@pengutronix.de \
--cc=vigneshr@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox