[PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Michael Walle]

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

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Tudor Ambarus]

Acked-by: Tudor Ambarus <tudor.ambarus@linaro.org>

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Miquel Raynal]

Hi Michael,

mwalle@kernel.org wrote on Tue,  4 Jun 2024 09:42:31 +0200:

> 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

Makes sense.

Reviewed-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl

RE: EXTERNAL: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[FLAVIO SULIGOI]

Hi Michael,

...
> ---
> 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.

Good idea, I had already tried a similar Everspin MRAM, the EM0004LXB,
using the at25 driver, and it works fine.

> ---
>  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


Reviewed-by: Flavio Suligoi <f.suligoi@asem.it>


Flavio

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Conor Dooley]

[-- 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 --]

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Michael Walle]

On Tue Jun 4, 2024 at 7:01 PM CEST, Conor Dooley wrote:
> 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.

Fair enough. The driver is already there and it basically works -
Flavio is already using it. It is just, that at the moment you have
to use the (deprecated) "atmel,at25" compatible and you'll have to
specify pagesize etc. That is really hacky, because F/MRAM devices
doesn't have a pagesize.

Anyway, I was already working on the at25 binding but then I've
noticed that the current FRAM binding is really hardcoded to cypress
devices and as mentioned in the commit message, I don't have any
hardware to actually write the proper driver support. Maybe we
should settle on the binding first, i.e.

 compatible = "everspin,mr25", "atmel,at25";
 size = <N>;

vs

 compatible = "everspin,mr25h256"; # no size needed

For reference, the already supported cypress fram has the following:

 compatible = "cypress,fm25", "atmel,at25";
 # no size needed, because the driver will figure it out by reading
 # the ID

Besides that, I would really get some feedback from the three
in-tree users on migrating to the EEPROM driver and thus away from
MTD.

-michael

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Thorsten Scherer]

Hello,

in the past I more actively worked on the ci4x10.  That changed after switching
departments.  Anyway, I thought maybe it's useful if I share my point of view.

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>

You cannot reach Uwe via this address anymore.

IMHO missing in this discussion is 

    kernel@pengutronix.de

, which I added to CC.

> 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.

My vague memory tells me (at least some of) the domain specific applications
running on ci4x10 rely on MTD(block?) devices.  So this change would break
user-space.

> 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.

The ci4x10 is still being used and sold.  Right now I do not have a clear
view on the implications of moving to that driver.  I'd like to invest some
time to sharpen my picture (or find the person that claims responsibility), but
this will propably not happen this week.

Hope this helps.

Best regards
Thorsten

> ---
>  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
> 

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Conor Dooley]

[-- Attachment #1: Type: text/plain, Size: 5208 bytes --]

On Tue, Jun 04, 2024 at 07:42:16PM +0200, Michael Walle wrote:
> On Tue Jun 4, 2024 at 7:01 PM CEST, Conor Dooley wrote:
> > 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.
> 
> Fair enough. The driver is already there and it basically works -
> Flavio is already using it. It is just, that at the moment you have
> to use the (deprecated) "atmel,at25" compatible and you'll have to
> specify pagesize etc. That is really hacky, because F/MRAM devices
> doesn't have a pagesize.
> 
> Anyway, I was already working on the at25 binding but then I've
> noticed that the current FRAM binding is really hardcoded to cypress
> devices and as mentioned in the commit message, I don't have any
> hardware to actually write the proper driver support. Maybe we
> should settle on the binding first, i.e.
> 
>  compatible = "everspin,mr25", "atmel,at25";
>  size = <N>;
> 
> vs
> 
>  compatible = "everspin,mr25h256"; # no size needed

I dunno, I am usually biased to having the more specific compatible
and not needing the extra properties.

> 
> For reference, the already supported cypress fram has the following:
> 
>  compatible = "cypress,fm25", "atmel,at25";
>  # no size needed, because the driver will figure it out by reading
>  # the ID
> 
> Besides that, I would really get some feedback from the three
> in-tree users on migrating to the EEPROM driver and thus away from
> MTD.
> 
> -michael
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Tudor Ambarus]

On 6/5/24 18:40, Conor Dooley wrote:
> On Tue, Jun 04, 2024 at 07:42:16PM +0200, Michael Walle wrote:
>> On Tue Jun 4, 2024 at 7:01 PM CEST, Conor Dooley wrote:
>>> 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.
>>
>> Fair enough. The driver is already there and it basically works -
>> Flavio is already using it. It is just, that at the moment you have
>> to use the (deprecated) "atmel,at25" compatible and you'll have to
>> specify pagesize etc. That is really hacky, because F/MRAM devices
>> doesn't have a pagesize.
>>
>> Anyway, I was already working on the at25 binding but then I've
>> noticed that the current FRAM binding is really hardcoded to cypress
>> devices and as mentioned in the commit message, I don't have any

Takahiro from cc may help with the cypress FRAM testing.

>> hardware to actually write the proper driver support. Maybe we
>> should settle on the binding first, i.e.
>>
>>  compatible = "everspin,mr25", "atmel,at25";
>>  size = <N>;
>>
>> vs
>>
>>  compatible = "everspin,mr25h256"; # no size needed
> 
> I dunno, I am usually biased to having the more specific compatible
> and not needing the extra properties.

I agree with the more specific compatible idea, but we shall aim that
the specific compatible to be generic: "spi-fram" and maybe "spi-mram".
Can it be done?

> 
>>
>> For reference, the already supported cypress fram has the following:
>>
>>  compatible = "cypress,fm25", "atmel,at25";
>>  # no size needed, because the driver will figure it out by reading
>>  # the ID
>>
>> Besides that, I would really get some feedback from the three
>> in-tree users on migrating to the EEPROM driver and thus away from
>> MTD.
>>
>> -michael
>>

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Tudor Ambarus]

On 6/5/24 14:58, Thorsten Scherer wrote:
> Hello,
> 

Hi!

> in the past I more actively worked on the ci4x10.  That changed after switching
> departments.  Anyway, I thought maybe it's useful if I share my point of view.
> 
> 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>
> 
> You cannot reach Uwe via this address anymore.
> 
> IMHO missing in this discussion is 
> 
>     kernel@pengutronix.de
> 
> , which I added to CC.
> 
>> 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.
> 
> My vague memory tells me (at least some of) the domain specific applications
> running on ci4x10 rely on MTD(block?) devices.  So this change would break
> user-space.

it's a possibility, indeed. I assume we don't know for sure, right?
> 
>> 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

if it's not used at all we can remove it entirely.

>> all the users over to the at25 driver.
> 
> The ci4x10 is still being used and sold.  Right now I do not have a clear
> view on the implications of moving to that driver.  I'd like to invest some
> time to sharpen my picture (or find the person that claims responsibility), but
> this will propably not happen this week.
> 

if it's used then we are forced to keep the entry in SPI NOR for
backward compatibility. But we can still deprecate the use and forbid
new support in SPI NOR while directing users to the other driver.

> Hope this helps.
> 
Thanks!
ta

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

Hi,

On Thu Jun 6, 2024 at 2:14 PM CEST, Tudor Ambarus wrote:
> > The ci4x10 is still being used and sold.  Right now I do not have a clear
> > view on the implications of moving to that driver.  I'd like to invest some
> > time to sharpen my picture (or find the person that claims responsibility), but
> > this will propably not happen this week.
> > 
>
> if it's used then we are forced to keep the entry in SPI NOR for
> backward compatibility. But we can still deprecate the use and forbid
> new support in SPI NOR while directing users to the other driver.

As mentioned, this is intended to be the first step towards removal.
And yes, we won't accept any new such devices, but at the same time,
new device trees should refrain from using this compatible, thus the
mark as deprecated.

How to handle boards which are actively using this device is a
different topic. I'm sure there is some kind of deprecation process.
I doubt we are forced to keep that support until the end of the
world :) Maybe some kind of grace period where we nag the user to
switch to a different interface, etc. Not sure.

Any ideas are welcome.

-michael

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Alexander Stein]

Hi everyone,

sorry for being late to the party. I just noticed this discussion while
reading [1].

Am Dienstag, 4. Juni 2024, 09:42:31 CEST schrieb Michael Walle:
> 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.

So instead of spi-nor you want to use at25 for this MRAM devices?
AFAICS at25 is a spi only driver, but spi-nor is a spi-mem driver. So I am
wondering if at25 driver is capable of using QSPI hosts.
Everspin EMxxLXB devices are capable of running in xSPI modes.
Regarding QSPI (DSPI/OSPI as well) I assumed spi-nor is a given, but maybe
I am completely wrong here. Maybe someone could clarify this.

Best regards,
Alexander

[1] https://lore.kernel.org/linux-kernel/20240405100104.480779-1-f.suligoi@asem.it/

> ---
>  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
> 


-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Michael Walle]

[-- Attachment #1: Type: text/plain, Size: 4613 bytes --]

On Fri Jun 21, 2024 at 8:49 AM CEST, Alexander Stein wrote:
> Hi everyone,
>
> sorry for being late to the party. I just noticed this discussion while
> reading [1].
>
> Am Dienstag, 4. Juni 2024, 09:42:31 CEST schrieb Michael Walle:
> > 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.
>
> So instead of spi-nor you want to use at25 for this MRAM devices?

Yes.

> AFAICS at25 is a spi only driver, but spi-nor is a spi-mem driver. So I am
> wondering if at25 driver is capable of using QSPI hosts.

spi-mem support could be added to the at25 driver. But probably
mainly because there are SPI controllers out there which only have
an interface to attach memory (like the FlexSPI from NXP).

> Everspin EMxxLXB devices are capable of running in xSPI modes.
> Regarding QSPI (DSPI/OSPI as well) I assumed spi-nor is a given, but maybe
> I am completely wrong here. Maybe someone could clarify this.

These newer devices should also support the erase command, right? So
they can be a "real" flash. If they support SFDP, the would even be
supported out of the box. The mentioned everspin devices are much
older and behaves more like an EEPROM instead of a flash.

-michael

>
> Best regards,
> Alexander
>
> [1] https://lore.kernel.org/linux-kernel/20240405100104.480779-1-f.suligoi@asem.it/
>
> > ---
> >  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
> > 


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 297 bytes --]

Re: [PATCH] dt-bindings: mtd: spi-nor: deprecate Everspin MRAM devices

[Alexander Stein]

Hi,

removing Uwe from CC as this address bounces.

Am Freitag, 21. Juni 2024, 09:09:56 CEST schrieb Michael Walle:
> On Fri Jun 21, 2024 at 8:49 AM CEST, Alexander Stein wrote:
> > Hi everyone,
> >
> > sorry for being late to the party. I just noticed this discussion while
> > reading [1].
> >
> > Am Dienstag, 4. Juni 2024, 09:42:31 CEST schrieb Michael Walle:
> > > 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.
> >
> > So instead of spi-nor you want to use at25 for this MRAM devices?
> 
> Yes.
> 
> > AFAICS at25 is a spi only driver, but spi-nor is a spi-mem driver. So I am
> > wondering if at25 driver is capable of using QSPI hosts.
> 
> spi-mem support could be added to the at25 driver. But probably
> mainly because there are SPI controllers out there which only have
> an interface to attach memory (like the FlexSPI from NXP).

Yes, FlexSPI is my current area of interest.

> > Everspin EMxxLXB devices are capable of running in xSPI modes.
> > Regarding QSPI (DSPI/OSPI as well) I assumed spi-nor is a given, but maybe
> > I am completely wrong here. Maybe someone could clarify this.
> 
> These newer devices should also support the erase command, right? So
> they can be a "real" flash. If they support SFDP, the would even be
> supported out of the box. The mentioned everspin devices are much
> older and behaves more like an EEPROM instead of a flash.

I see this is about older devices, I got misled by the subject.
The new devices EMxxLX devices do not support SFDP. There are erase commands,
but unless you want to set sectors/whole chip to a defined state, this seems
unneeded, so SPI_NOR_NO_ERASE would be sensible.
I'm wondering if the comment in [1] is still applicable unconditionally, as
there still is a use-case for spi-nor on flexspi.

Best regards,
Alexander

[1] https://lore.kernel.org/linux-kernel/D0C9NCOMI27O.2VW2U3FNFTSPK@kernel.org/
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/