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

From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Richard Weinberger <richard@nod.at>
Cc: Ronan Dalton <Ronan.Dalton@alliedtelesis.co.nz>,
	 Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	 Takahiro Kuwano <Takahiro.Kuwano@infineon.com>,
	 pratyush <pratyush@kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	 Vignesh Raghavendra <vigneshr@ti.com>,
	 linux-mtd <linux-mtd@lists.infradead.org>,
	 Aryan Srivastava <Aryan.Srivastava@alliedtelesis.co.nz>,
	 Michael Walle <mwalle@kernel.org>
Subject: Re: [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support"
Date: Fri, 03 Jul 2026 12:15:54 +0200	[thread overview]
Message-ID: <87wlvcnztx.fsf@bootlin.com> (raw)
In-Reply-To: <183302295.10735.1783057556804.JavaMail.zimbra@nod.at> (Richard Weinberger's message of "Fri, 3 Jul 2026 07:45:56 +0200 (CEST)")

On 03/07/2026 at 07:45:56 +02, Richard Weinberger <richard@nod.at> wrote:

> ----- Ursprüngliche Mail -----
>> Von: "Ronan Dalton" <Ronan.Dalton@alliedtelesis.co.nz>
>> On Thu, 2026-07-02 at 07:39 +0200, Richard Weinberger wrote:
>>> Do you really need (POSIX) file system semantics?
>>> You could partition the FRAM into cells and then work with them.
>>> e.g. Just dd into it and erase it when needed...
>>> Maybe the NVMEM cells mechanism needs some polishing but this sounds
>>> reasonable to me.
>> 
>> Yes, that could work for secrets storage. However we also store
>> persistent logs and DHCP leases on this flash to minimize read/writes
>> on the main flash, and this data is stored as files of varying lengths.
>> A filesystem provides the most straightforward way of storing this data
>> for us.
>
> But the storage (FRAM) you chose is not suitable for any real filesystem.
> In a previous mail you said you use ext2 on it.
> I have a hard time to see how using ext2 on top of mtdblock on an FRAM
> does not end in a disaster.
>
>> That's not to say we couldn't develop some system of using the nvmem
>> device as a backend for this data. This may be something we look at in
>> the future.
>
> Maybe FUSE can help with building a super simple filesystem which provides
> just enough to fulfill your use case.

The NVMEM cells mechanism is very flexible now with layouts. We do have
support for ONIE Type-Length-Variable tables as well as an example of
support for the environment variables in U-Boot. If you format very
slightly your data you can very easily expose automatically one cell per
information with a rather simple NVMEM layout driver and consume it this
way.

Thanks,
Miquèl