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

From: "Michael Walle" <mwalle@kernel.org>
To: "Ronan Dalton" <ronan.dalton@alliedtelesis.co.nz>,
	<takahiro.kuwano@infineon.com>
Cc: <Aryan.Srivastava@alliedtelesis.co.nz>,
	<Chris.Packham@alliedtelesis.co.nz>,
	<Ronan.Dalton@alliedtelesis.co.nz>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	<miquel.raynal@bootlin.com>, <pratyush@kernel.org>,
	<richard@nod.at>, <vigneshr@ti.com>
Subject: Re: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"
Date: Wed, 01 Jul 2026 10:12:25 +0200	[thread overview]
Message-ID: <DJN30JTAW4NY.28G7HNY6QS299@kernel.org> (raw)
In-Reply-To: <20260701020856.217664-1-ronan.dalton@alliedtelesis.co.nz>

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