Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

[claus.fabig]

From: Claus Fabig <claus.fabig@emerson.com>
Date: Thu, 18 Jul 2024 09:53:36 +0200
Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

The Everspin EM008LXB MRAM has 8Mb and is populated on a custom board
using Microchip's PCI12000 spi host controller running on low 30MHz clock.
According to Everspin Read Fast (0xb) command below 60MHz is neither
specified and nor tested. Test shows that using Read Fast (0xb) will
result in reading inconsistent data in this setup but writing is fine, so
only supporting Read (0x3) command should be acceptable for the moment.
The device is JEDEC compatible (JESD251 and JESD251-1) but not able to
provide SFDP information.

For spec v3.2 refer to www.everspin.com/file/158315/download.

Successfully tested according to
www.kernel.org/doc/html/latest/driver-api/mtd/spi-nor.html:

cat /sys/bus/spi/devices/spi-EMR5555\:00/spi-nor/partname
em008lxb

cat /sys/bus/spi/devices/spi-EMR5555\:00/spi-nor/manufacturer
everspin

cat /sys/kernel/debug/spi-nor/spi-EMR5555\:00/capabilities
Supported read modes by the flash
 1S-1S-1S
  opcode        0x03
  mode cycles   0
  dummy cycles  0

Supported page program modes by the flash
 1S-1S-1S
  opcode        0x02

cat /sys/kernel/debug/spi-nor/spi-EMR5555\:00/params
name            em008lxb
id              (null)
size            1.00 MiB
write size      1
page size       256
address nbytes  3
flags           HAS_SR_TB | HAS_16BIT_SR | HAS_4BIT_BP | HAS_SR_BP3_BIT6

opcodes
 read           0x03
  dummy cycles  0
 erase          0xd8
 program        0x02
 8D extension   none

protocols
 read           1S-1S-1S
 write          1S-1S-1S
 register       1S-1S-1S

erase commands
 d8 (1.00 MiB) [0]
 c7 (1.00 MiB)

sector map
 region (in hex)   | erase mask | overlaid
 ------------------+------------+----------
 00000000-000fffff |     [0   ] | no

cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00020000 "spi-EMR1010:00"
mtd1: 00100000 00100000 "spi-EMR5555:00"

mtd_debug info /dev/mtd1
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_NORFLASH
mtd.size = 1048576 (1M)
mtd.erasesize = 1048576 (1M)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0

dd if=/dev/urandom of=spi_test bs=1M count=1
mtd_debug erase /dev/mtd1 0 1048576
mtd_debug read /dev/mtd1 0 1048576 spi_read
Copied 1048576 bytes from address 0x00000000 in flash to spi_read
hexdump spi_read
0000000 ffff ffff ffff ffff ffff ffff ffff ffff
*
0100000
sha256sum spi_read
f5fb04aa5b882706b9309e885f19477261336ef76a150c3b4d3489dfac3953ec  spi_read
mtd_debug write /dev/mtd1 0 1048576 spi_test
Copied 1048576 bytes from spi_test to address 0x00000000 in flash
mtd_debug read /dev/mtd1 0 1048576 spi_read
Copied 1048576 bytes from address 0x00000000 in flash to spi_read
sha256sum spi*
cf9a1f3f4089602d194d67d1a918a574a5ca1d9aa71d391a661818c1f0ee1aab  spi_read
cf9a1f3f4089602d194d67d1a918a574a5ca1d9aa71d391a661818c1f0ee1aab  spi_test

Signed-off-by: claus.fabig@emerson.com
---
 drivers/mtd/spi-nor/core.c     | 2 +-
 drivers/mtd/spi-nor/everspin.c | 5 +++++
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index e0c4efc424f4..95267d9e8b65 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -3713,7 +3713,7 @@ static const struct spi_device_id spi_nor_dev_ids[] = {
 	{ "mr25h256" }, /* 256 Kib, 40 MHz */
 	{ "mr25h10" },  /*   1 Mib, 40 MHz */
 	{ "mr25h40" },  /*   4 Mib, 40 MHz */
-
+	{ "em008lxb" }, /*   8 Mib, 133 MHz */
 	{ },
 };
 MODULE_DEVICE_TABLE(spi, spi_nor_dev_ids);
diff --git a/drivers/mtd/spi-nor/everspin.c b/drivers/mtd/spi-nor/everspin.c
index add37104d673..c1f004c39c1c 100644
--- a/drivers/mtd/spi-nor/everspin.c
+++ b/drivers/mtd/spi-nor/everspin.c
@@ -31,6 +31,11 @@ static const struct flash_info everspin_nor_parts[] = {
 		.size = SZ_512K,
 		.sector_size = SZ_512K,
 		.flags = SPI_NOR_NO_ERASE,
+	}, {
+		.name = "em008lxb",
+		.size = SZ_1M,
+		.sector_size = SZ_1M,
+		.flags = SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP | SPI_NOR_BP3_SR_BIT6,
 	}
 };
 
-- 
2.45.2

Re: Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

[Michael Walle]

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

Hi,

There is something odd with your mail client, maybe have a look at
git send-email.

Also we usually push back on the MRAM devices and refer the users to
the at25 driver. But as this doesn't use the NO_ERASE flag.. I'll
let Tudor and Pratyush decide.

> From: Claus Fabig <claus.fabig@emerson.com>
> Date: Thu, 18 Jul 2024 09:53:36 +0200
> Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB
>
> The Everspin EM008LXB MRAM has 8Mb and is populated on a custom board
> using Microchip's PCI12000 spi host controller running on low 30MHz clock.
> According to Everspin Read Fast (0xb) command below 60MHz is neither
> specified and nor tested. Test shows that using Read Fast (0xb) will
> result in reading inconsistent data in this setup but writing is fine, so
> only supporting Read (0x3) command should be acceptable for the moment.

This is really odd. Is there an explanation for that? Usually, fast
read will just add dummy cycles in between. Also the datasheet just
mentions a "maximum frequency" which actually makes sense. Do the
dummy cycles for our fast read operation match the number of dummy
cycles in your device?

> The device is JEDEC compatible (JESD251 and JESD251-1) but not able to
> provide SFDP information.

There is no SFDP data for this chip is it? But it has a READ_ID
command.

> For spec v3.2 refer to www.everspin.com/file/158315/download.

Please as a "Link:" tag just before your SoB.

> Successfully tested according to
> www.kernel.org/doc/html/latest/driver-api/mtd/spi-nor.html:

Great thanks, this should go below the "---" line.

> cat /sys/bus/spi/devices/spi-EMR5555\:00/spi-nor/partname
> em008lxb
>
> cat /sys/bus/spi/devices/spi-EMR5555\:00/spi-nor/manufacturer
> everspin
>
> cat /sys/kernel/debug/spi-nor/spi-EMR5555\:00/capabilities
> Supported read modes by the flash
>  1S-1S-1S
>   opcode        0x03
>   mode cycles   0
>   dummy cycles  0
>
> Supported page program modes by the flash
>  1S-1S-1S
>   opcode        0x02
>
> cat /sys/kernel/debug/spi-nor/spi-EMR5555\:00/params
> name            em008lxb
> id              (null)
> size            1.00 MiB
> write size      1
> page size       256
> address nbytes  3
> flags           HAS_SR_TB | HAS_16BIT_SR | HAS_4BIT_BP | HAS_SR_BP3_BIT6
>
> opcodes
>  read           0x03
>   dummy cycles  0
>  erase          0xd8
>  program        0x02
>  8D extension   none
>
> protocols
>  read           1S-1S-1S
>  write          1S-1S-1S
>  register       1S-1S-1S
>
> erase commands
>  d8 (1.00 MiB) [0]
>  c7 (1.00 MiB)
>
> sector map
>  region (in hex)   | erase mask | overlaid
>  ------------------+------------+----------
>  00000000-000fffff |     [0   ] | no
>
> cat /proc/mtd
> dev:    size   erasesize  name
> mtd0: 00020000 00020000 "spi-EMR1010:00"
> mtd1: 00100000 00100000 "spi-EMR5555:00"
>
> mtd_debug info /dev/mtd1
> mtd.type = MTD_NORFLASH
> mtd.flags = MTD_CAP_NORFLASH
> mtd.size = 1048576 (1M)
> mtd.erasesize = 1048576 (1M)
> mtd.writesize = 1
> mtd.oobsize = 0
> regions = 0
>
> dd if=/dev/urandom of=spi_test bs=1M count=1
> mtd_debug erase /dev/mtd1 0 1048576
> mtd_debug read /dev/mtd1 0 1048576 spi_read
> Copied 1048576 bytes from address 0x00000000 in flash to spi_read
> hexdump spi_read
> 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
> *
> 0100000
> sha256sum spi_read
> f5fb04aa5b882706b9309e885f19477261336ef76a150c3b4d3489dfac3953ec  spi_read
> mtd_debug write /dev/mtd1 0 1048576 spi_test
> Copied 1048576 bytes from spi_test to address 0x00000000 in flash
> mtd_debug read /dev/mtd1 0 1048576 spi_read
> Copied 1048576 bytes from address 0x00000000 in flash to spi_read
> sha256sum spi*
> cf9a1f3f4089602d194d67d1a918a574a5ca1d9aa71d391a661818c1f0ee1aab  spi_read
> cf9a1f3f4089602d194d67d1a918a574a5ca1d9aa71d391a661818c1f0ee1aab  spi_test
>
> Signed-off-by: claus.fabig@emerson.com
> ---
>  drivers/mtd/spi-nor/core.c     | 2 +-
>  drivers/mtd/spi-nor/everspin.c | 5 +++++
>  2 files changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index e0c4efc424f4..95267d9e8b65 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -3713,7 +3713,7 @@ static const struct spi_device_id spi_nor_dev_ids[] = {
>  	{ "mr25h256" }, /* 256 Kib, 40 MHz */
>  	{ "mr25h10" },  /*   1 Mib, 40 MHz */
>  	{ "mr25h40" },  /*   4 Mib, 40 MHz */
> -
> +	{ "em008lxb" }, /*   8 Mib, 133 MHz */

Nope. No new spi_device_ids. See also below.

>  	{ },
>  };
>  MODULE_DEVICE_TABLE(spi, spi_nor_dev_ids);
> diff --git a/drivers/mtd/spi-nor/everspin.c b/drivers/mtd/spi-nor/everspin.c
> index add37104d673..c1f004c39c1c 100644
> --- a/drivers/mtd/spi-nor/everspin.c
> +++ b/drivers/mtd/spi-nor/everspin.c
> @@ -31,6 +31,11 @@ static const struct flash_info everspin_nor_parts[] = {
>  		.size = SZ_512K,
>  		.sector_size = SZ_512K,
>  		.flags = SPI_NOR_NO_ERASE,
> +	}, {
> +		.name = "em008lxb",

Drop the name, but add the corresponding ".id" property. Then, this
entry will be fetched automatically. In your DT you use the generic
compatible.

> +		.size = SZ_1M,
> +		.sector_size = SZ_1M,

This is odd. The sector size is 64kB.

> +		.flags = SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP | SPI_NOR_BP3_SR_BIT6,
>  	}
>  };
>  

-michael

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

Re: Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

[claus.fabig]

> Hi,
Hi Michael, thanks for your response resp. advices and apologies for the late response.
> 
> There is something odd with your mail client, maybe have a look at
> git send-email.
Unfortunately I am only able to send/receive email from my windows machine and 
therefore have some challenges within our company infrastructure.
I still try to find the best way to get the formatting correct.
> 
> Also we usually push back on the MRAM devices and refer the users to
> the at25 driver. But as this doesn't use the NO_ERASE flag.. I'll
> let Tudor and Pratyush decide.
I am aware that using at25 driver works but have the task to integrate that in mtd
since another used MRAM Everspin flash MR25H10 on our board is also accessed 
in that way and already part of the mainline. That will lead to confusion on user side.
> 
> > From: Claus Fabig <claus.fabig@emerson.com>
> > Date: Thu, 18 Jul 2024 09:53:36 +0200
> > Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB
> >
> > The Everspin EM008LXB MRAM has 8Mb and is populated on a custom
> board
> > using Microchip's PCI12000 spi host controller running on low 30MHz clock.
> > According to Everspin Read Fast (0xb) command below 60MHz is neither
> > specified and nor tested. Test shows that using Read Fast (0xb) will
> > result in reading inconsistent data in this setup but writing is fine, so
> > only supporting Read (0x3) command should be acceptable for the moment.
> 
> This is really odd. Is there an explanation for that? Usually, fast
> read will just add dummy cycles in between. Also the datasheet just
> mentions a "maximum frequency" which actually makes sense. Do the
> dummy cycles for our fast read operation match the number of dummy
> cycles in your device?
> 
Yes, at first I configured the chip with 8 dummy cycles to match with platform
dummy cycles with the result of reading inconsistent data. 
The answer from Everspin product engineering was:
"Read fast has only been tested down to 66 Mhz. If you are only running at 30 Mhz, 
you should be using the Read command instead. Read Fast is designed for Higher 
speed operation". Unfortunately no more explanation.
> > The device is JEDEC compatible (JESD251 and JESD251-1) but not able to
> > provide SFDP information.
> 
> There is no SFDP data for this chip is it? But it has a READ_ID
> command.
For my understanding reading SFDP works with command 0x5A which is not 
supported, reading ID is command 0x9F and supported. I don't understand your point.
Maybe you could give me a hint to better understand.
> 
> > For spec v3.2 refer to www.everspin.com/file/158315/download.
> 
> Please as a "Link:" tag just before your SoB.
Thanks, I will do in the future.
> 
> > Successfully tested according to
> > www.kernel.org/doc/html/latest/driver-api/mtd/spi-nor.html:
> 
> Great thanks, this should go below the "---" line.
Thanks, I will do in the future.
> 
> > cat /sys/bus/spi/devices/spi-EMR5555\:00/spi-nor/partname
> > em008lxb
> >
> > cat /sys/bus/spi/devices/spi-EMR5555\:00/spi-nor/manufacturer
> > everspin
> >
> > cat /sys/kernel/debug/spi-nor/spi-EMR5555\:00/capabilities
> > Supported read modes by the flash
> >  1S-1S-1S
> >   opcode        0x03
> >   mode cycles   0
> >   dummy cycles  0
> >
> > Supported page program modes by the flash
> >  1S-1S-1S
> >   opcode        0x02
> >
> > cat /sys/kernel/debug/spi-nor/spi-EMR5555\:00/params
> > name            em008lxb
> > id              (null)
> > size            1.00 MiB
> > write size      1
> > page size       256
> > address nbytes  3
> > flags           HAS_SR_TB | HAS_16BIT_SR | HAS_4BIT_BP | HAS_SR_BP3_BIT6
> >
> > opcodes
> >  read           0x03
> >   dummy cycles  0
> >  erase          0xd8
> >  program        0x02
> >  8D extension   none
> >
> > protocols
> >  read           1S-1S-1S
> >  write          1S-1S-1S
> >  register       1S-1S-1S
> >
> > erase commands
> >  d8 (1.00 MiB) [0]
> >  c7 (1.00 MiB)
> >
> > sector map
> >  region (in hex)   | erase mask | overlaid
> >  ------------------+------------+----------
> >  00000000-000fffff |     [0   ] | no
> >
> > cat /proc/mtd
> > dev:    size   erasesize  name
> > mtd0: 00020000 00020000 "spi-EMR1010:00"
> > mtd1: 00100000 00100000 "spi-EMR5555:00"
> >
> > mtd_debug info /dev/mtd1
> > mtd.type = MTD_NORFLASH
> > mtd.flags = MTD_CAP_NORFLASH
> > mtd.size = 1048576 (1M)
> > mtd.erasesize = 1048576 (1M)
> > mtd.writesize = 1
> > mtd.oobsize = 0
> > regions = 0
> >
> > dd if=/dev/urandom of=spi_test bs=1M count=1
> > mtd_debug erase /dev/mtd1 0 1048576
> > mtd_debug read /dev/mtd1 0 1048576 spi_read
> > Copied 1048576 bytes from address 0x00000000 in flash to spi_read
> > hexdump spi_read
> > 0000000 ffff ffff ffff ffff ffff ffff ffff ffff
> > *
> > 0100000
> > sha256sum spi_read
> >
> f5fb04aa5b882706b9309e885f19477261336ef76a150c3b4d3489dfac3953
> ec  spi_read
> > mtd_debug write /dev/mtd1 0 1048576 spi_test
> > Copied 1048576 bytes from spi_test to address 0x00000000 in flash
> > mtd_debug read /dev/mtd1 0 1048576 spi_read
> > Copied 1048576 bytes from address 0x00000000 in flash to spi_read
> > sha256sum spi*
> >
> cf9a1f3f4089602d194d67d1a918a574a5ca1d9aa71d391a661818c1f0ee1a
> ab  spi_read
> >
> cf9a1f3f4089602d194d67d1a918a574a5ca1d9aa71d391a661818c1f0ee1a
> ab  spi_test
> >
> > Signed-off-by: claus.fabig@emerson.com
> > ---
> >  drivers/mtd/spi-nor/core.c     | 2 +-
> >  drivers/mtd/spi-nor/everspin.c | 5 +++++
> >  2 files changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> > index e0c4efc424f4..95267d9e8b65 100644
> > --- a/drivers/mtd/spi-nor/core.c
> > +++ b/drivers/mtd/spi-nor/core.c
> > @@ -3713,7 +3713,7 @@ static const struct spi_device_id
> spi_nor_dev_ids[] = {
> >  	{ "mr25h256" }, /* 256 Kib, 40 MHz */
> >  	{ "mr25h10" },  /*   1 Mib, 40 MHz */
> >  	{ "mr25h40" },  /*   4 Mib, 40 MHz */
> > -
> > +	{ "em008lxb" }, /*   8 Mib, 133 MHz */
> 
> Nope. No new spi_device_ids. See also below.
> 
> >  	{ },
> >  };
> >  MODULE_DEVICE_TABLE(spi, spi_nor_dev_ids);
> > diff --git a/drivers/mtd/spi-nor/everspin.c b/drivers/mtd/spi-nor/everspin.c
> > index add37104d673..c1f004c39c1c 100644
> > --- a/drivers/mtd/spi-nor/everspin.c
> > +++ b/drivers/mtd/spi-nor/everspin.c
> > @@ -31,6 +31,11 @@ static const struct flash_info everspin_nor_parts[] = {
> >  		.size = SZ_512K,
> >  		.sector_size = SZ_512K,
> >  		.flags = SPI_NOR_NO_ERASE,
> > +	}, {
> > +		.name = "em008lxb",
> 
> Drop the name, but add the corresponding ".id" property. Then, this
> entry will be fetched automatically. In your DT you use the generic
> compatible.
> 
> > +		.size = SZ_1M,
> > +		.sector_size = SZ_1M,
> 
> This is odd. The sector size is 64kB.
> 
> > +		.flags = SPI_NOR_HAS_TB | SPI_NOR_4BIT_BP |
> SPI_NOR_BP3_SR_BIT6,
> >  	}
> >  };
> >
> 
> -michael
Thanks, Claus

Re: Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

[Michael Walle]

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

Hi,

On Fri Jul 26, 2024 at 2:04 PM CEST, claus.fabig wrote:
> > Hi,
> Hi Michael, thanks for your response resp. advices and apologies for the late response.
> > 
> > There is something odd with your mail client, maybe have a look at
> > git send-email.
> Unfortunately I am only able to send/receive email from my windows machine and 
> therefore have some challenges within our company infrastructure.
> I still try to find the best way to get the formatting correct.

In that case you can also have a look at:
https://b4.docs.kernel.org/en/latest/contributor/send.html

> > Also we usually push back on the MRAM devices and refer the users to
> > the at25 driver. But as this doesn't use the NO_ERASE flag.. I'll
> > let Tudor and Pratyush decide.
> I am aware that using at25 driver works but have the task to integrate that in mtd
> since another used MRAM Everspin flash MR25H10 on our board is also accessed 
> in that way and already part of the mainline. That will lead to confusion on user side.

I suggest that you'll look into evaluating and converting your
existing boards to nvmem (which is the interface at25 exposes)
instead.

The MTD maintainers agreed that new fram/mram won't likely be added
anymore. As I said, this patch might be an exception, because you
are actually emulating a flash device (because you *don't* have the
NO_ERASE flag). Otherwise, the m/fram are more like an EEPROM and
thus should use the at25 driver.

> > > From: Claus Fabig <claus.fabig@emerson.com>
> > > Date: Thu, 18 Jul 2024 09:53:36 +0200
> > > Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB
> > >
> > > The Everspin EM008LXB MRAM has 8Mb and is populated on a custom
> > board
> > > using Microchip's PCI12000 spi host controller running on low 30MHz clock.
> > > According to Everspin Read Fast (0xb) command below 60MHz is neither
> > > specified and nor tested. Test shows that using Read Fast (0xb) will
> > > result in reading inconsistent data in this setup but writing is fine, so
> > > only supporting Read (0x3) command should be acceptable for the moment.
> > 
> > This is really odd. Is there an explanation for that? Usually, fast
> > read will just add dummy cycles in between. Also the datasheet just
> > mentions a "maximum frequency" which actually makes sense. Do the
> > dummy cycles for our fast read operation match the number of dummy
> > cycles in your device?
> > 
> Yes, at first I configured the chip with 8 dummy cycles to match with platform
> dummy cycles with the result of reading inconsistent data. 
> The answer from Everspin product engineering was:
> "Read fast has only been tested down to 66 Mhz. If you are only running at 30 Mhz, 
> you should be using the Read command instead. Read Fast is designed for Higher 
> speed operation". Unfortunately no more explanation.

I guess you cannot use it with at least 66MHz?

> > > The device is JEDEC compatible (JESD251 and JESD251-1) but not able to
> > > provide SFDP information.
> > 
> > There is no SFDP data for this chip is it? But it has a READ_ID
> > command.
> For my understanding reading SFDP works with command 0x5A which is not 
> supported, reading ID is command 0x9F and supported. I don't understand your point.
> Maybe you could give me a hint to better understand.

Please see my comments on the code in my first reply. You basically
don't probe the driver by the name, but by it's ID.

-michael

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

Re: Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin EM008LXB

[claus.fabig]

> Hi,
> 
> On Fri Jul 26, 2024 at 2:04 PM CEST, claus.fabig wrote:
> > > Hi,
> > Hi Michael, thanks for your response resp. advices and apologies for the late
> response.
> > >
> > > There is something odd with your mail client, maybe have a look at
> > > git send-email.
> > Unfortunately I am only able to send/receive email from my windows
> > machine and therefore have some challenges within our company
> infrastructure.
> > I still try to find the best way to get the formatting correct.
> 
> In that case you can also have a look at:
> https://b4.docs.kernel.org/en/latest/contributor/send.html

Thanks, I looked into it but have problem with our smtp server since it 
requests a password, even with smtpauth=none in .gitconfig. I will clone my
Linux target repo to Windows virtual machine and use git send-email
instead since there no password is requested.

> 
> > > Also we usually push back on the MRAM devices and refer the users to
> > > the at25 driver. But as this doesn't use the NO_ERASE flag.. I'll
> > > let Tudor and Pratyush decide.
> > I am aware that using at25 driver works but have the task to integrate
> > that in mtd since another used MRAM Everspin flash MR25H10 on our
> > board is also accessed in that way and already part of the mainline. That will
> lead to confusion on user side.
> 
> I suggest that you'll look into evaluating and converting your existing boards to
> nvmem (which is the interface at25 exposes) instead.

My problem is that we have two MRAMs on our board configuration - both 
from Everspin (MR25H10 and EM008LX). The first is accessible via /dev/mtd 
and already part of mainline. The second should also be be accessible via this 
interface so this is why mtd is more preferred than nvmem interface. I noticed
that the first MRAM with /dev/mtd is also existing in nvmem but only as read-only.

> 
> The MTD maintainers agreed that new fram/mram won't likely be added
> anymore. As I said, this patch might be an exception, because you are actually
> emulating a flash device (because you *don't* have the NO_ERASE flag).
> Otherwise, the m/fram are more like an EEPROM and thus should use the at25
> driver.
> 
> > > > From: Claus Fabig <claus.fabig@emerson.com>
> > > > Date: Thu, 18 Jul 2024 09:53:36 +0200
> > > > Subject: [PATCH] mtd: spi-nor: add support for MRAM Everspin
> > > > EM008LXB
> > > >
> > > > The Everspin EM008LXB MRAM has 8Mb and is populated on a custom
> > > board
> > > > using Microchip's PCI12000 spi host controller running on low 30MHz
> clock.
> > > > According to Everspin Read Fast (0xb) command below 60MHz is
> > > > neither specified and nor tested. Test shows that using Read Fast
> > > > (0xb) will result in reading inconsistent data in this setup but
> > > > writing is fine, so only supporting Read (0x3) command should be
> acceptable for the moment.
> > >
> > > This is really odd. Is there an explanation for that? Usually, fast
> > > read will just add dummy cycles in between. Also the datasheet just
> > > mentions a "maximum frequency" which actually makes sense. Do the
> > > dummy cycles for our fast read operation match the number of dummy
> > > cycles in your device?
> > >
> > Yes, at first I configured the chip with 8 dummy cycles to match with
> > platform dummy cycles with the result of reading inconsistent data.
> > The answer from Everspin product engineering was:
> > "Read fast has only been tested down to 66 Mhz. If you are only
> > running at 30 Mhz, you should be using the Read command instead. Read
> > Fast is designed for Higher speed operation". Unfortunately no more
> explanation.
> 
> I guess you cannot use it with at least 66MHz?

Unfortunately not, it's limited by hardware design.

> 
> > > > The device is JEDEC compatible (JESD251 and JESD251-1) but not
> > > > able to provide SFDP information.
> > >
> > > There is no SFDP data for this chip is it? But it has a READ_ID
> > > command.
> > For my understanding reading SFDP works with command 0x5A which is not
> > supported, reading ID is command 0x9F and supported. I don't understand
> your point.
> > Maybe you could give me a hint to better understand.
> 
> Please see my comments on the code in my first reply. You basically don't
> probe the driver by the name, but by it's ID.

Understood, changed this accordingly and will send Patch v2 
(via git send-email hopefully).

> 
> -michael
Best regards, Claus