All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Ronan Dalton <Ronan.Dalton@alliedtelesis.co.nz>
Cc: Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	 Miquel Raynal <miquel.raynal@bootlin.com>,
	 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, 3 Jul 2026 07:45:56 +0200 (CEST)	[thread overview]
Message-ID: <183302295.10735.1783057556804.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <a86e2233c6ea01b1dcefb8c7f7f582725a25b5e5.camel@alliedtelesis.co.nz>

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

Thanks,
//richard

WARNING: multiple messages have this Message-ID (diff)
From: Richard Weinberger <richard@nod.at>
To: Ronan Dalton <Ronan.Dalton@alliedtelesis.co.nz>
Cc: Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	 Miquel Raynal <miquel.raynal@bootlin.com>,
	 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, 3 Jul 2026 07:45:56 +0200 (CEST)	[thread overview]
Message-ID: <183302295.10735.1783057556804.JavaMail.zimbra@nod.at> (raw)
In-Reply-To: <a86e2233c6ea01b1dcefb8c7f7f582725a25b5e5.camel@alliedtelesis.co.nz>

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

Thanks,
//richard

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

  reply	other threads:[~2026-07-03  5:46 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-26  2:21 [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support" Ronan Dalton
2026-06-26  2:21 ` Ronan Dalton
2026-06-26  2:21 ` [PATCH v2 2/3] mtd: spi-nor: fujitsu: Convert to new flash_info format Ronan Dalton
2026-06-26  2:21   ` Ronan Dalton
2026-06-26  2:21 ` [PATCH v2 3/3] mtd: spi-nor: fujitsu: Add support for MB85RS4MTY chip Ronan Dalton
2026-06-26  2:21   ` Ronan Dalton
2026-07-01  8:05   ` Michael Walle
2026-07-01  8:05     ` Michael Walle
2026-07-01 23:48     ` Ronan Dalton
2026-07-01 23:48       ` Ronan Dalton
2026-06-30  7:47 ` [PATCH v2 1/3] Revert "mtd: spi-nor: remove Fujitsu MB85RS1MT support" Takahiro.Kuwano
2026-06-30  7:47   ` Takahiro.Kuwano
2026-06-30 21:05   ` Chris Packham
2026-06-30 21:05     ` Chris Packham
2026-07-01  1:10     ` Takahiro.Kuwano
2026-07-01  1:10       ` Takahiro.Kuwano
2026-07-01  2:08       ` Ronan Dalton
2026-07-01  2:08         ` Ronan Dalton
2026-07-01  8:12         ` Michael Walle
2026-07-01  8:12           ` Michael Walle
2026-07-01 23:42           ` Ronan Dalton
2026-07-01 23:42             ` Ronan Dalton
2026-07-01  9:49         ` Takahiro.Kuwano
2026-07-01  9:49           ` Takahiro.Kuwano
2026-07-02  1:21           ` Ronan Dalton
2026-07-02  1:21             ` Ronan Dalton
2026-07-02  2:41             ` Takahiro.Kuwano
2026-07-02  2:41               ` Takahiro.Kuwano
2026-07-02  3:06               ` Chris Packham
2026-07-02  3:06                 ` Chris Packham
2026-07-02  5:39                 ` Richard Weinberger
2026-07-02  5:39                   ` Richard Weinberger
2026-07-02 23:48                   ` Ronan Dalton
2026-07-02 23:48                     ` Ronan Dalton
2026-07-03  5:45                     ` Richard Weinberger [this message]
2026-07-03  5:45                       ` Richard Weinberger
2026-07-03 10:15                       ` Miquel Raynal
2026-07-03 10:15                         ` Miquel Raynal
2026-07-05 22:12                         ` Ronan Dalton
2026-07-05 22:12                           ` Ronan Dalton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=183302295.10735.1783057556804.JavaMail.zimbra@nod.at \
    --to=richard@nod.at \
    --cc=Aryan.Srivastava@alliedtelesis.co.nz \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=Ronan.Dalton@alliedtelesis.co.nz \
    --cc=Takahiro.Kuwano@infineon.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=miquel.raynal@bootlin.com \
    --cc=mwalle@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.