[PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Ronan Dalton]

This reverts commit d9cd5c9a6fe26d544551cfaa94fb0abc50c0b895.

The commit that removed support for this chip claimed that the at25
driver was the correct driver to use for this chip. However, the at25
driver exposes the chip as an NVMEM device, not a MTD device, so it's
not a suitable replacement for users that want to mount a file system
over the chip.

Revert the change that removed support for the MB85RS1MT FRAM chip.

Signed-off-by: Ronan Dalton <ronan.dalton@alliedtelesis.co.nz>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
---
Changes in v2:
- No changes

 drivers/mtd/spi-nor/Makefile  |  1 +
 drivers/mtd/spi-nor/core.c    |  1 +
 drivers/mtd/spi-nor/core.h    |  1 +
 drivers/mtd/spi-nor/fujitsu.c | 21 +++++++++++++++++++++
 4 files changed, 24 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/fujitsu.c

diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index 5dd9c35f6b6f..9216a5a29a2b 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -5,6 +5,7 @@ spi-nor-objs			+= atmel.o
 spi-nor-objs			+= eon.o
 spi-nor-objs			+= esmt.o
 spi-nor-objs			+= everspin.o
+spi-nor-objs			+= fujitsu.o
 spi-nor-objs			+= gigadevice.o
 spi-nor-objs			+= intel.o
 spi-nor-objs			+= issi.o
diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
index ccf4396cdcd0..d5ebbfd3fa7f 100644
--- a/drivers/mtd/spi-nor/core.c
+++ b/drivers/mtd/spi-nor/core.c
@@ -2009,6 +2009,7 @@ static const struct spi_nor_manufacturer *manufacturers[] = {
 	&spi_nor_eon,
 	&spi_nor_esmt,
 	&spi_nor_everspin,
+	&spi_nor_fujitsu,
 	&spi_nor_gigadevice,
 	&spi_nor_intel,
 	&spi_nor_issi,
diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
index ba2d1a862c9d..a4d906e6d07d 100644
--- a/drivers/mtd/spi-nor/core.h
+++ b/drivers/mtd/spi-nor/core.h
@@ -606,6 +606,7 @@ extern const struct spi_nor_manufacturer spi_nor_atmel;
 extern const struct spi_nor_manufacturer spi_nor_eon;
 extern const struct spi_nor_manufacturer spi_nor_esmt;
 extern const struct spi_nor_manufacturer spi_nor_everspin;
+extern const struct spi_nor_manufacturer spi_nor_fujitsu;
 extern const struct spi_nor_manufacturer spi_nor_gigadevice;
 extern const struct spi_nor_manufacturer spi_nor_intel;
 extern const struct spi_nor_manufacturer spi_nor_issi;
diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
new file mode 100644
index 000000000000..69cffc5c73ef
--- /dev/null
+++ b/drivers/mtd/spi-nor/fujitsu.c
@@ -0,0 +1,21 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2005, Intec Automation Inc.
+ * Copyright (C) 2014, Freescale Semiconductor, Inc.
+ */
+
+#include <linux/mtd/spi-nor.h>
+
+#include "core.h"
+
+static const struct flash_info fujitsu_nor_parts[] = {
+	/* Fujitsu */
+	{ "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1)
+		FLAGS(SPI_NOR_NO_ERASE) },
+};
+
+const struct spi_nor_manufacturer spi_nor_fujitsu = {
+	.name = "fujitsu",
+	.parts = fujitsu_nor_parts,
+	.nparts = ARRAY_SIZE(fujitsu_nor_parts),
+};
-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 2/3] mtd: spi-nor: fujitsu: Convert to new flash_info format

[Ronan Dalton]

The previous patch reverted a commit, and in doing so added a flash_info
table which still used the old format. flash_info tables are defined
differently now, so the code requires an amendment.

Fix up the fujitsu_nor_parts array to use the correct format. Also
remove the unnecessary "Fujitsu" comment and specify sector_size for
consistency with other flash_info tables.

Signed-off-by: Ronan Dalton <ronan.dalton@alliedtelesis.co.nz>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
---
Changes in v2:
- No changes

 drivers/mtd/spi-nor/fujitsu.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
index 69cffc5c73ef..3777c80251c5 100644
--- a/drivers/mtd/spi-nor/fujitsu.c
+++ b/drivers/mtd/spi-nor/fujitsu.c
@@ -9,9 +9,13 @@
 #include "core.h"
 
 static const struct flash_info fujitsu_nor_parts[] = {
-	/* Fujitsu */
-	{ "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1)
-		FLAGS(SPI_NOR_NO_ERASE) },
+	{
+		.id = SNOR_ID(0x04, 0x7f, 0x27),
+		.name = "mb85rs1mt",
+		.size = SZ_128K,
+		.sector_size = SZ_128K,
+		.flags = SPI_NOR_NO_ERASE,
+	}
 };
 
 const struct spi_nor_manufacturer spi_nor_fujitsu = {
-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

[PATCH v2 3/3] mtd: spi-nor: fujitsu: Add support for MB85RS4MTY chip

[Ronan Dalton]

The MB85RS4MTY chip is similar to the MB85RS1MT chip, but it has a
higher capacity and can handle higher temperatures. Compared to the
MB85RS1MT chip, this chip has an expanded set of opcodes which allow
control over power-saving modes, access to a special sector data area,
and reading of the unique ID and serial number. However, since the
spi-nor subsystem doesn't support these extended abilities, they are not
taken advantage of here.

Add support for this chip by adding an entry to the fujitsu_nor_parts
table.

Signed-off-by: Ronan Dalton <ronan.dalton@alliedtelesis.co.nz>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
Cc: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
---
Changes in v2:
- Fix the debug information below missing some lines because of leading
  '#' symbols in the original patch notes

This flash is populated on the Allied Telesis x950GEN2 board and was
tested at 40 MHz using the armada-380 (CN9130) SPI controller.

$ cat /sys/bus/spi/devices/spi1.2/spi-nor/partname
mb85rs4mty
$ cat /sys/bus/spi/devices/spi1.2/spi-nor/jedec_id
047f49
$ cat /sys/bus/spi/devices/spi1.2/spi-nor/manufacturer
fujitsu
$ xxd -p /sys/bus/spi/devices/spi1.2/spi-nor/sfdp
xxd: /sys/bus/spi/devices/spi1.2/spi-nor/sfdp: No such file or directory
^ Expected since SFDP isn't used (flash size is hard-coded)

$ cat /sys/kernel/debug/spi-nor/spi1.2/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/spi1.2/params
name            mb85rs4mty
id              04 7f 49 0b ff ff
size            512 KiB
write size      1
page size       256
address nbytes  3
flags           HAS_16BIT_SR

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 (512 KiB) [0]
 c7 (512 KiB)

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

$ dd if=/dev/urandom of=./spi_test bs=1K count=512
512+0 records in
512+0 records out
524288 bytes (512.0KB) copied, 0.723481 seconds, 707.7KB/s
$ mtd_debug erase /dev/mtd5 0 524288
MEMERASE: Unknown error 524
^ 524 is ENOTSUPP which is expected because of SPI_NOR_NO_ERASE flag
$ mtd_debug read /dev/mtd5 0 524288 spi_read
Copied 524288 bytes from address 0x00000000 in flash to spi_read
$ hexdump spi_read | head
0000000 da13 14ec beac 3864 78cb a48b 29a7 1edc
0000010 446e 772a f20a bcd1 9edb 8b40 bcf5 544c
0000020 3152 63a1 3081 bcb6 852f 06da f19a 284d
0000030 1655 4d58 62d7 bd42 90fb 7921 0be8 3ee7
0000040 3e78 c995 ba19 4f10 09bc b67c d7da aff7
0000050 e6f9 0691 a5a8 a40e 9a5d bfef 652e ba36
0000060 60f6 3ecf dfdb 32cb b4b8 b7b4 a0f8 d307
0000070 19d7 456b 1f35 296c 7e85 7fbc d1ff b1cf
0000080 28f9 06dd 55df 1f7a 1309 50f3 e30b 14c2
0000090 3638 6c9b dee0 3101 9b11 e03c 9a01 c0bd
^ just leftover data
$ openssl dgst -sha256 -r spi_read
722489d44edaccfda786c82c63037ae90733998e02d81e985db54588b229ee83 *spi_read
$ mtd_debug write /dev/mtd5 0 524288 spi_test
Copied 524288 bytes from spi_test to address 0x00000000 in flash
$ mtd_debug read /dev/mtd5 0 524288 spi_read
Copied 524288 bytes from address 0x00000000 in flash to spi_read
$ openssl dgst -sha256 -r spi*
343037c927f0dcdf1ae42d51730d316103aca620e701ab9762440d403c057312 *spi_read
343037c927f0dcdf1ae42d51730d316103aca620e701ab9762440d403c057312 *spi_test

$ mtd_debug info /dev/mtd5
mtd.type = MTD_NORFLASH
mtd.flags = MTD_CAP_RAM
mtd.size = 524288 (512K)
mtd.erasesize = 524288 (512K)
mtd.writesize = 1
mtd.oobsize = 0
regions = 0

 drivers/mtd/spi-nor/fujitsu.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
index 3777c80251c5..32d5404b7402 100644
--- a/drivers/mtd/spi-nor/fujitsu.c
+++ b/drivers/mtd/spi-nor/fujitsu.c
@@ -15,6 +15,12 @@ static const struct flash_info fujitsu_nor_parts[] = {
 		.size = SZ_128K,
 		.sector_size = SZ_128K,
 		.flags = SPI_NOR_NO_ERASE,
+	}, {
+		.id = SNOR_ID(0x04, 0x7f, 0x49),
+		.name = "mb85rs4mty",
+		.size = SZ_512K,
+		.sector_size = SZ_512K,
+		.flags = SPI_NOR_NO_ERASE
 	}
 };
 
-- 
2.54.0


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Takahiro.Kuwano]

Hi,

> This reverts commit d9cd5c9a6fe26d544551cfaa94fb0abc50c0b895.
> 
> The commit that removed support for this chip claimed that the at25
> driver was the correct driver to use for this chip. However, the at25
> driver exposes the chip as an NVMEM device, not a MTD device, so it's
> not a suitable replacement for users that want to mount a file system
> over the chip.
> 

What file system do you use?
The size of FRAM chips (hundreds of KB) sounds too small for file
systems.

> Revert the change that removed support for the MB85RS1MT FRAM chip.
> 
> Signed-off-by: Ronan Dalton <ronan.dalton@alliedtelesis.co.nz>
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-mtd@lists.infradead.org
> Cc: Pratyush Yadav <pratyush@kernel.org>
> Cc: Michael Walle <mwalle@kernel.org>
> Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
> Cc: Miquel Raynal <miquel.raynal@bootlin.com>
> Cc: Richard Weinberger <richard@nod.at>
> Cc: Vignesh Raghavendra <vigneshr@ti.com>
> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
> Cc: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
> ---
> Changes in v2:
> - No changes
> 
>  drivers/mtd/spi-nor/Makefile  |  1 +
>  drivers/mtd/spi-nor/core.c    |  1 +
>  drivers/mtd/spi-nor/core.h    |  1 +
>  drivers/mtd/spi-nor/fujitsu.c | 21 +++++++++++++++++++++
>  4 files changed, 24 insertions(+)
>  create mode 100644 drivers/mtd/spi-nor/fujitsu.c
> 
> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> index 5dd9c35f6b6f..9216a5a29a2b 100644
> --- a/drivers/mtd/spi-nor/Makefile
> +++ b/drivers/mtd/spi-nor/Makefile
> @@ -5,6 +5,7 @@ spi-nor-objs                    += atmel.o
>  spi-nor-objs                   += eon.o
>  spi-nor-objs                   += esmt.o
>  spi-nor-objs                   += everspin.o
> +spi-nor-objs                   += fujitsu.o
>  spi-nor-objs                   += gigadevice.o
>  spi-nor-objs                   += intel.o
>  spi-nor-objs                   += issi.o
> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> index ccf4396cdcd0..d5ebbfd3fa7f 100644
> --- a/drivers/mtd/spi-nor/core.c
> +++ b/drivers/mtd/spi-nor/core.c
> @@ -2009,6 +2009,7 @@ static const struct spi_nor_manufacturer *manufacturers[] = {
>         &spi_nor_eon,
>         &spi_nor_esmt,
>         &spi_nor_everspin,
> +       &spi_nor_fujitsu,
>         &spi_nor_gigadevice,
>         &spi_nor_intel,
>         &spi_nor_issi,
> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> index ba2d1a862c9d..a4d906e6d07d 100644
> --- a/drivers/mtd/spi-nor/core.h
> +++ b/drivers/mtd/spi-nor/core.h
> @@ -606,6 +606,7 @@ extern const struct spi_nor_manufacturer spi_nor_atmel;
>  extern const struct spi_nor_manufacturer spi_nor_eon;
>  extern const struct spi_nor_manufacturer spi_nor_esmt;
>  extern const struct spi_nor_manufacturer spi_nor_everspin;
> +extern const struct spi_nor_manufacturer spi_nor_fujitsu;
>  extern const struct spi_nor_manufacturer spi_nor_gigadevice;
>  extern const struct spi_nor_manufacturer spi_nor_intel;
>  extern const struct spi_nor_manufacturer spi_nor_issi;
> diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
> new file mode 100644
> index 000000000000..69cffc5c73ef
> --- /dev/null
> +++ b/drivers/mtd/spi-nor/fujitsu.c
> @@ -0,0 +1,21 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2005, Intec Automation Inc.
> + * Copyright (C) 2014, Freescale Semiconductor, Inc.
> + */
> +
> +#include <linux/mtd/spi-nor.h>
> +
> +#include "core.h"
> +
> +static const struct flash_info fujitsu_nor_parts[] = {
> +       /* Fujitsu */
> +       { "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1)
> +               FLAGS(SPI_NOR_NO_ERASE) },
> +};
> +
> +const struct spi_nor_manufacturer spi_nor_fujitsu = {
> +       .name = "fujitsu",
> +       .parts = fujitsu_nor_parts,
> +       .nparts = ARRAY_SIZE(fujitsu_nor_parts),
> +};
> --
> 2.54.0

Thanks,
Takahiro


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Chris Packham]

Hi Takahiro,

On 30/06/2026 19:47, Takahiro.Kuwano@infineon.com wrote:
> Hi,
>
>> This reverts commit d9cd5c9a6fe26d544551cfaa94fb0abc50c0b895.
>>
>> The commit that removed support for this chip claimed that the at25
>> driver was the correct driver to use for this chip. However, the at25
>> driver exposes the chip as an NVMEM device, not a MTD device, so it's
>> not a suitable replacement for users that want to mount a file system
>> over the chip.
>>
> What file system do you use?
> The size of FRAM chips (hundreds of KB) sounds too small for file
> systems.

We're using ext2. Technically we want this for the MB85RS4MT which is 
added in patch 3 of this series.

The use is for a small amount of additional storage separate to the main 
system NAND flash for some small "critical" files that we don't want to 
lose. We've been using devices like the mchp23lcv1024 and mr25h40 on 
other products for some time.

>> Revert the change that removed support for the MB85RS1MT FRAM chip.
>>
>> Signed-off-by: Ronan Dalton <ronan.dalton@alliedtelesis.co.nz>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-mtd@lists.infradead.org
>> Cc: Pratyush Yadav <pratyush@kernel.org>
>> Cc: Michael Walle <mwalle@kernel.org>
>> Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
>> Cc: Miquel Raynal <miquel.raynal@bootlin.com>
>> Cc: Richard Weinberger <richard@nod.at>
>> Cc: Vignesh Raghavendra <vigneshr@ti.com>
>> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
>> Cc: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
>> ---
>> Changes in v2:
>> - No changes
>>
>>   drivers/mtd/spi-nor/Makefile  |  1 +
>>   drivers/mtd/spi-nor/core.c    |  1 +
>>   drivers/mtd/spi-nor/core.h    |  1 +
>>   drivers/mtd/spi-nor/fujitsu.c | 21 +++++++++++++++++++++
>>   4 files changed, 24 insertions(+)
>>   create mode 100644 drivers/mtd/spi-nor/fujitsu.c
>>
>> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
>> index 5dd9c35f6b6f..9216a5a29a2b 100644
>> --- a/drivers/mtd/spi-nor/Makefile
>> +++ b/drivers/mtd/spi-nor/Makefile
>> @@ -5,6 +5,7 @@ spi-nor-objs                    += atmel.o
>>   spi-nor-objs                   += eon.o
>>   spi-nor-objs                   += esmt.o
>>   spi-nor-objs                   += everspin.o
>> +spi-nor-objs                   += fujitsu.o
>>   spi-nor-objs                   += gigadevice.o
>>   spi-nor-objs                   += intel.o
>>   spi-nor-objs                   += issi.o
>> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
>> index ccf4396cdcd0..d5ebbfd3fa7f 100644
>> --- a/drivers/mtd/spi-nor/core.c
>> +++ b/drivers/mtd/spi-nor/core.c
>> @@ -2009,6 +2009,7 @@ static const struct spi_nor_manufacturer *manufacturers[] = {
>>          &spi_nor_eon,
>>          &spi_nor_esmt,
>>          &spi_nor_everspin,
>> +       &spi_nor_fujitsu,
>>          &spi_nor_gigadevice,
>>          &spi_nor_intel,
>>          &spi_nor_issi,
>> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
>> index ba2d1a862c9d..a4d906e6d07d 100644
>> --- a/drivers/mtd/spi-nor/core.h
>> +++ b/drivers/mtd/spi-nor/core.h
>> @@ -606,6 +606,7 @@ extern const struct spi_nor_manufacturer spi_nor_atmel;
>>   extern const struct spi_nor_manufacturer spi_nor_eon;
>>   extern const struct spi_nor_manufacturer spi_nor_esmt;
>>   extern const struct spi_nor_manufacturer spi_nor_everspin;
>> +extern const struct spi_nor_manufacturer spi_nor_fujitsu;
>>   extern const struct spi_nor_manufacturer spi_nor_gigadevice;
>>   extern const struct spi_nor_manufacturer spi_nor_intel;
>>   extern const struct spi_nor_manufacturer spi_nor_issi;
>> diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
>> new file mode 100644
>> index 000000000000..69cffc5c73ef
>> --- /dev/null
>> +++ b/drivers/mtd/spi-nor/fujitsu.c
>> @@ -0,0 +1,21 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * Copyright (C) 2005, Intec Automation Inc.
>> + * Copyright (C) 2014, Freescale Semiconductor, Inc.
>> + */
>> +
>> +#include <linux/mtd/spi-nor.h>
>> +
>> +#include "core.h"
>> +
>> +static const struct flash_info fujitsu_nor_parts[] = {
>> +       /* Fujitsu */
>> +       { "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1)
>> +               FLAGS(SPI_NOR_NO_ERASE) },
>> +};
>> +
>> +const struct spi_nor_manufacturer spi_nor_fujitsu = {
>> +       .name = "fujitsu",
>> +       .parts = fujitsu_nor_parts,
>> +       .nparts = ARRAY_SIZE(fujitsu_nor_parts),
>> +};
>> --
>> 2.54.0
> Thanks,
> Takahiro
>
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Takahiro.Kuwano]

Hi,

> Hi Takahiro,
> 
> On 30/06/2026 19:47, Takahiro.Kuwano@infineon.com wrote:
> > Hi,
> >
> >> This reverts commit d9cd5c9a6fe26d544551cfaa94fb0abc50c0b895.
> >>
> >> The commit that removed support for this chip claimed that the at25
> >> driver was the correct driver to use for this chip. However, the at25
> >> driver exposes the chip as an NVMEM device, not a MTD device, so it's
> >> not a suitable replacement for users that want to mount a file system
> >> over the chip.
> >>
> > What file system do you use?
> > The size of FRAM chips (hundreds of KB) sounds too small for file
> > systems.
> 
> We're using ext2. Technically we want this for the MB85RS4MT which is
> added in patch 3 of this series.
> 
We don't add any FRAM chips in SPI-NOR...

> The use is for a small amount of additional storage separate to the main
> system NAND flash for some small "critical" files that we don't want to
> lose. We've been using devices like the mchp23lcv1024 and mr25h40 on
> other products for some time.
> 
For that use, how about using tmpfs with NVMEM backup?

> >> Revert the change that removed support for the MB85RS1MT FRAM chip.
> >>
> >> Signed-off-by: Ronan Dalton <ronan.dalton@alliedtelesis.co.nz>
> >> Cc: linux-kernel@vger.kernel.org
> >> Cc: linux-mtd@lists.infradead.org
> >> Cc: Pratyush Yadav <pratyush@kernel.org>
> >> Cc: Michael Walle <mwalle@kernel.org>
> >> Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
> >> Cc: Miquel Raynal <miquel.raynal@bootlin.com>
> >> Cc: Richard Weinberger <richard@nod.at>
> >> Cc: Vignesh Raghavendra <vigneshr@ti.com>
> >> Cc: Chris Packham <chris.packham@alliedtelesis.co.nz>
> >> Cc: Aryan Srivastava <aryan.srivastava@alliedtelesis.co.nz>
> >> ---
> >> Changes in v2:
> >> - No changes
> >>
> >>   drivers/mtd/spi-nor/Makefile  |  1 +
> >>   drivers/mtd/spi-nor/core.c    |  1 +
> >>   drivers/mtd/spi-nor/core.h    |  1 +
> >>   drivers/mtd/spi-nor/fujitsu.c | 21 +++++++++++++++++++++
> >>   4 files changed, 24 insertions(+)
> >>   create mode 100644 drivers/mtd/spi-nor/fujitsu.c
> >>
> >> diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
> >> index 5dd9c35f6b6f..9216a5a29a2b 100644
> >> --- a/drivers/mtd/spi-nor/Makefile
> >> +++ b/drivers/mtd/spi-nor/Makefile
> >> @@ -5,6 +5,7 @@ spi-nor-objs                    += atmel.o
> >>   spi-nor-objs                   += eon.o
> >>   spi-nor-objs                   += esmt.o
> >>   spi-nor-objs                   += everspin.o
> >> +spi-nor-objs                   += fujitsu.o
> >>   spi-nor-objs                   += gigadevice.o
> >>   spi-nor-objs                   += intel.o
> >>   spi-nor-objs                   += issi.o
> >> diff --git a/drivers/mtd/spi-nor/core.c b/drivers/mtd/spi-nor/core.c
> >> index ccf4396cdcd0..d5ebbfd3fa7f 100644
> >> --- a/drivers/mtd/spi-nor/core.c
> >> +++ b/drivers/mtd/spi-nor/core.c
> >> @@ -2009,6 +2009,7 @@ static const struct spi_nor_manufacturer *manufacturers[] = {
> >>          &spi_nor_eon,
> >>          &spi_nor_esmt,
> >>          &spi_nor_everspin,
> >> +       &spi_nor_fujitsu,
> >>          &spi_nor_gigadevice,
> >>          &spi_nor_intel,
> >>          &spi_nor_issi,
> >> diff --git a/drivers/mtd/spi-nor/core.h b/drivers/mtd/spi-nor/core.h
> >> index ba2d1a862c9d..a4d906e6d07d 100644
> >> --- a/drivers/mtd/spi-nor/core.h
> >> +++ b/drivers/mtd/spi-nor/core.h
> >> @@ -606,6 +606,7 @@ extern const struct spi_nor_manufacturer spi_nor_atmel;
> >>   extern const struct spi_nor_manufacturer spi_nor_eon;
> >>   extern const struct spi_nor_manufacturer spi_nor_esmt;
> >>   extern const struct spi_nor_manufacturer spi_nor_everspin;
> >> +extern const struct spi_nor_manufacturer spi_nor_fujitsu;
> >>   extern const struct spi_nor_manufacturer spi_nor_gigadevice;
> >>   extern const struct spi_nor_manufacturer spi_nor_intel;
> >>   extern const struct spi_nor_manufacturer spi_nor_issi;
> >> diff --git a/drivers/mtd/spi-nor/fujitsu.c b/drivers/mtd/spi-nor/fujitsu.c
> >> new file mode 100644
> >> index 000000000000..69cffc5c73ef
> >> --- /dev/null
> >> +++ b/drivers/mtd/spi-nor/fujitsu.c
> >> @@ -0,0 +1,21 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +/*
> >> + * Copyright (C) 2005, Intec Automation Inc.
> >> + * Copyright (C) 2014, Freescale Semiconductor, Inc.
> >> + */
> >> +
> >> +#include <linux/mtd/spi-nor.h>
> >> +
> >> +#include "core.h"
> >> +
> >> +static const struct flash_info fujitsu_nor_parts[] = {
> >> +       /* Fujitsu */
> >> +       { "mb85rs1mt", INFO(0x047f27, 0, 128 * 1024, 1)
> >> +               FLAGS(SPI_NOR_NO_ERASE) },
> >> +};
> >> +
> >> +const struct spi_nor_manufacturer spi_nor_fujitsu = {
> >> +       .name = "fujitsu",
> >> +       .parts = fujitsu_nor_parts,
> >> +       .nparts = ARRAY_SIZE(fujitsu_nor_parts),
> >> +};
> >> --
> >> 2.54.0
> > Thanks,
> > Takahiro
> >
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Ronan Dalton]

Hi Takahiro,

> We don't add any FRAM chips in SPI-NOR...

The SPI-NOR subsystem has support for the cy15x104q chips, which are
FRAM chips. There is also support for Everspin MRAM chips, which are
comparible to FRAM (and are also of small size).

Because of this, we thought there was precident to add support for this
chip. I was under the impression that the opcodes used to interact with
the chip had a greater significance than the underlying technology used,
and this chip fits in with the other spi-nor chips based on that. Feel
free to correct me if I'm wrong here.

> > The use is for a small amount of additional storage separate to the main
> > system NAND flash for some small "critical" files that we don't want to
> > lose. We've been using devices like the mchp23lcv1024 and mr25h40 on
> > other products for some time.
> > 
> For that use, how about using tmpfs with NVMEM backup?

Could you elaborate on this? I'm familiar with tmpfs but not with using
NVMEM as a backup for it. Is there some method of syncing a tmpfs to
NVMEM that the kernel provides?

Thanks,
Ronan.

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 3/3] mtd: spi-nor: fujitsu: Add support for MB85RS4MTY chip

[Michael Walle]

[-- Attachment #1.1: Type: text/plain, Size: 1252 bytes --]

Hi,

On Fri Jun 26, 2026 at 4:21 AM CEST, Ronan Dalton wrote:
> The MB85RS4MTY chip is similar to the MB85RS1MT chip, but it has a
> higher capacity and can handle higher temperatures. Compared to the
> MB85RS1MT chip, this chip has an expanded set of opcodes which allow
> control over power-saving modes, access to a special sector data area,
> and reading of the unique ID and serial number. However, since the
> spi-nor subsystem doesn't support these extended abilities, they are not
> taken advantage of here.

I'm sorry, but we don't accept any new parts, which clearly emulates
an EEPROM and has no concept of erase blocks (or don't even emulate
the erase opcode). I understand, that it was very convenient to have
a block device. But I want to move away from that NO_ERASE hack and
having two different drivers for the same hardware device.

Maybe someone in the loop has an idea how to move forward regarding
the filesystem issue.

..

> +	}, {
> +		.id = SNOR_ID(0x04, 0x7f, 0x49),
> +		.name = "mb85rs4mty",

We dropped adding names of the flashes for new parts, because of
notorious id reuse.

-michael

> +		.size = SZ_512K,
> +		.sector_size = SZ_512K,
> +		.flags = SPI_NOR_NO_ERASE
>  	}
>  };
>  

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

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Michael Walle]

[-- Attachment #1.1: Type: text/plain, Size: 1748 bytes --]

On Wed Jul 1, 2026 at 4:08 AM CEST, Ronan Dalton wrote:
> Hi Takahiro,
>
>> We don't add any FRAM chips in SPI-NOR...
>
> The SPI-NOR subsystem has support for the cy15x104q chips, which are
> FRAM chips. There is also support for Everspin MRAM chips, which are
> comparible to FRAM (and are also of small size).

Yeah, these are mostly old parts, (except for the newer cypress thing, which
was a mistake to add). But there is little we can do, but to
eventually remove them in the future when it's likely no boards are
using them anymore. Thus, we don't want to add newer parts to this
list and make it even harder for us to get rid of these.

> Because of this, we thought there was precident to add support for this
> chip. I was under the impression that the opcodes used to interact with
> the chip had a greater significance than the underlying technology used,
> and this chip fits in with the other spi-nor chips based on that. Feel
> free to correct me if I'm wrong here.

I'd argue, if they really wanted to emulate a flash device, they
would have added an (emulated) erase opcode. Without it, it behaves
like an EEPROM which has byte granularity access.

-michael

>> > The use is for a small amount of additional storage separate to the main
>> > system NAND flash for some small "critical" files that we don't want to
>> > lose. We've been using devices like the mchp23lcv1024 and mr25h40 on
>> > other products for some time.
>> > 
>> For that use, how about using tmpfs with NVMEM backup?
>
> Could you elaborate on this? I'm familiar with tmpfs but not with using
> NVMEM as a backup for it. Is there some method of syncing a tmpfs to
> NVMEM that the kernel provides?
>
> Thanks,
> Ronan.


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

[-- Attachment #2: Type: text/plain, Size: 144 bytes --]

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

RE: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"

[Takahiro.Kuwano]

Hi Ronan,

> Hi Takahiro,
> 
> > We don't add any FRAM chips in SPI-NOR...
> 
> The SPI-NOR subsystem has support for the cy15x104q chips, which are
> FRAM chips. There is also support for Everspin MRAM chips, which are
> comparible to FRAM (and are also of small size).
> 
> Because of this, we thought there was precident to add support for this
> chip. I was under the impression that the opcodes used to interact with
> the chip had a greater significance than the underlying technology used,
> and this chip fits in with the other spi-nor chips based on that. Feel
> free to correct me if I'm wrong here.
> 
> > > The use is for a small amount of additional storage separate to the main
> > > system NAND flash for some small "critical" files that we don't want to
> > > lose. We've been using devices like the mchp23lcv1024 and mr25h40 on
> > > other products for some time.
> > >
> > For that use, how about using tmpfs with NVMEM backup?
> 
> Could you elaborate on this? I'm familiar with tmpfs but not with using
> NVMEM as a backup for it. Is there some method of syncing a tmpfs to
> NVMEM that the kernel provides?
> 
I didn't mean any kernel features, but we can dump tmpfs contents
from/to FRAM chip (exposed as NVMEM device) by 'dd'. Doesn't it meet
your system's requirement?

> Thanks,
> Ronan.


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/