All of lore.kernel.org
 help / color / mirror / Atom feed
From: <Takahiro.Kuwano@infineon.com>
To: <ronan.dalton@alliedtelesis.co.nz>
Cc: <Aryan.Srivastava@alliedtelesis.co.nz>,
	<Chris.Packham@alliedtelesis.co.nz>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	<miquel.raynal@bootlin.com>, <mwalle@kernel.org>,
	<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, 1 Jul 2026 09:49:07 +0000	[thread overview]
Message-ID: <490fc98b2996487fba3abd62176bb1dd@infineon.com> (raw)
In-Reply-To: <20260701020856.217664-1-ronan.dalton@alliedtelesis.co.nz>

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/

WARNING: multiple messages have this Message-ID (diff)
From: <Takahiro.Kuwano@infineon.com>
To: <ronan.dalton@alliedtelesis.co.nz>
Cc: <Aryan.Srivastava@alliedtelesis.co.nz>,
	<Chris.Packham@alliedtelesis.co.nz>,
	<linux-kernel@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
	<miquel.raynal@bootlin.com>, <mwalle@kernel.org>,
	<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, 1 Jul 2026 09:49:07 +0000	[thread overview]
Message-ID: <490fc98b2996487fba3abd62176bb1dd@infineon.com> (raw)
In-Reply-To: <20260701020856.217664-1-ronan.dalton@alliedtelesis.co.nz>

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.


  parent reply	other threads:[~2026-07-01  9:49 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 [this message]
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
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=490fc98b2996487fba3abd62176bb1dd@infineon.com \
    --to=takahiro.kuwano@infineon.com \
    --cc=Aryan.Srivastava@alliedtelesis.co.nz \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --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=richard@nod.at \
    --cc=ronan.dalton@alliedtelesis.co.nz \
    --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.